Have you ever wanted to add a Log Analytics workspace to multiple Microsoft Monitoring Agent (MMA)'s before?

Maybe you are setting up Windows Defender or wanting to redirect to collect event or performance logs.

This little quick script will help get you started on automating adding a Log Analytics workspace to the MMA agent, even through a proxy.

Note: It is recommended to have the latest MMA Agent installed, this is not compatible with SCOM 2012 R2 agents, but the latest agent is supported by SCOM.

<#

    Author: Luke Murray (Luke.Geek.NZ)
    Version: 0.1
    Version History:

    Purpose: Add an MMA agent to a Log Analytics workspace using a proxy with no user authentication.
    Notes:
    Find more options about the MMA Agent Object:
    #$healthServiceSettings = New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg'
    #$proxyMethod = $healthServiceSettings | Get-Member -Name 'SetProxyInfo'

    If script is being published by Configuration as a package, create a Command Line installer:
    "%Windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe" -ExecutionPolicy Bypass -Command  .\Add_LogAnalyticsWorkspace.ps1

    If the proxy requires authentication, then the following null entries need to be replaced with user,password: $mma.SetProxyInfo("$proxy","$null","$null"). If you aren't using a proxy then you can remove the entire mma.SetProxyInfo line.

    Location: https://github.com/lukemurraynz/PowerOfTheShell/blob/master/OperationsMgr/Add_LogAnalyticsWorkspace.ps1
#>

$workspaceId = "INSERTLOGANALYTICSWORKSPACEIDHERE"
$workspaceKey = "INSERTLOGANALYTICSWORKSPACEKEY"
$proxy = 'ProxyIP:PORT'
$mma = New-Object -ComObject 'AgentConfigManager.MgmtSvcCfg'
$mma.AddCloudWorkspace($workspaceId, $workspaceKey)
$mma.SetProxyInfo("$proxy","$null","$null")
$mma.ReloadConfiguration()

By default, Azure Web Apps are unloaded if they are idle for a set period of time (20 minutes). This way, the system can conserve resources.

The downside is that the response to the first request after the web app is unloaded is longer, as the Web App has to load into memory and present itself, which could lead to a bad user experience.

To ensure that the Azure App Service Web App is running and always available to respond to incoming HTTP(S) requests, can be set the "Always On" configuration feature to "On".

Overview​

By setting the "Always On" feature of the App Service Web App to “On”, will ensure that Azure will always keep an instance of the Web App running at all times. This way when a user/client hits the Azure Front Door endpoint, the back-end Web App will always be ready to respond to that request without timing out. This will ensure the application is always available even during times of low usage or inactivity. Azure will continuously ping the website to keep the website alive.

Enabling "Always On" keeps your Apps always loaded, even when there is no traffic. It’s required for example when using continuous Web Jobs or for Web Jobs that are triggered using a CRON expression, this feature is similar to the Internet Information Services (IIS) idle time-out property.

Disabling "Always On" makes your Apps unloaded if they are idle for a set period of time. This way, the system can conserve resources. This is the reason “Always On” is set as disabled by default.

You need a minimum of Basic and Standard App Service Tiers to enable "Always On"

Having "Always On" off or on does not affect your billing or pricing, the Azure App Service billing is done at the App Service Plan level, which is charged per hour that the App Service Plan exists and is running, this is charged whether you have a WebApp or its set to "Always On" or not.

Configure Always On​

Note: Any changes to applications settings and connection strings could restart your application, so make sure that you schedule this during a period you can have an intermittent outage.

1. Log in to the Azure Portal
2. Find your App Service and open it
3. In the left hand Blade, under Configuration, select General Settings
4. Navigate down to Platform Settings and click 'On' to Always On
5. Click Save

Configure Always On through Azure Policy​

The Azure policy below, contains a set of 3 policies which used in combination should ensure that your web app is always on. Since the alwaysOn property is optional in the ARM deployment, a combination of 3 policies are required to ensure true compliance in the environment.

• Web App Always On Policy

References​

For more information about the "Always On" feature please see the documentation below:

• Azure Web Sites adds Always On
• Application performance FAQs for Web Apps in Azure

By default, the timezone in Microsoft Azure defaults to UTC (Universal Coordinated Time) as a standard, as a universal and consistent timezone, this makes sense - however when troubleshooting issues or attempting to schedule jobs, having the time in UTC may add additional confusion. An Azure WebApp is no exception to UTC as a standard, however, this can be changed.

As I am in 'New Zealand', I will be setting my WebApp (which is hosted in Australia East) to NZ time from UTC.

I will be using a Windows-based App Service, for this article.

Find the Timezone​

The Azure App Service uses the same naming standard as Windows.

1. To find the correct name, run the following PowerShell snippet on a Windows PC:

   Get-ChildItem -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones' | Select-Object PSChildName
   

This will list all the compatible Timezone names, because I am in New Zealand, I now know that: 'New Zealand Standard Time' is the correct syntax.

For future reference, I have exported the list of compatible timezones into a CSV file below:

• Export of Timezones

Set the Timezone​

Making a change to the Application Settings, which includes setting the Timezone will restart the WebApp app pool, so make sure this is scheduled at a time it is acceptable for an intermittent outage.

1. Log in to the Azure Portal
2. Find your Azure WebApp and open it up
3. On the left-hand side Blade, underneath Settings, click on Configuration
4. Click on + New Application Setting
5. Type in the following Key/Value pair: WEBSITE_TIME_ZONE | New Zealand Standard Time
6. Click Ok
7. Click Save to confirm and save the change.

Test the Timezone​

1. Log in to the Azure Portal
2. Find your Azure WebApp and open it up
3. On the left-hand side Blade, underneath Development Tools, click on Console
4. Type the following into the console:

• Time
• Date

These commands can help you confirm, that the Date and Time now your Timezone, the Azure WebApp logs etc will now be updated to use your timezone.

The PowerShell App Deployment Toolkit provides a set of functions to perform common application deployment tasks and to interact with the user during deployment. It simplifies the complex scripting challenges of deploying applications in the enterprise, provides a consistent deployment experience and improves installation success rates.

Although the PowerShell App Deployment Toolkit, makes application installation a lot more visible and gives your users more control over how and when the Application is installed, due to some technical limitations, you can't run the PowerShell App Deployment Toolkit, directly from the Datto RMM package store.

This is a brief article, intended to help other people who may be using the App Deployment Toolkit with Datto RMM.

#This is the name of the zip file in the component. Make sure that the PowerShell App Deployment Toolkit is zipped.
$ZipFile = "DesktopSOE.zip"
#This will create a folder called: C:\Temp (these folders can be changed to suit your requirements)
Mkdir c:\Temp -Force
#This will create a folder called: C:\Temp\DesktopSOE\ (these folders can be changed to suit your requirements)
Mkdir C:\Temp\DesktopSOE\ -Force
#This will then copy your PowerShellAppDeployment Toolkit to a folder, outside of the CentraStage Packagestore location. 
Copy-Item -Path "$ZipFile" -Destination "C:\Temp\$ZipFile" -Recurse
$DestinationFolder = $ZipFile.Split(".")[0]
#This will then extract your PowerShell App Deployment Toolkit and run it.
Expand-Archive -Path "c:\temp\$ZipFile" -DestinationPath "C:\Temp\DesktopSOE\" -Force
Invoke-Command { c:\temp\DesktopSOE\Deploy-Application.exe }

Note: You may also need to navigate to: AppDeployToolkitConfig.xml, and change the: <Toolkit_RequireAdmin> attribute to False, to avoid issues with UAC (User Access Control).

I also ran my component as:

• Only Run when the user is logged in
• Only run if User has Administrator rights

Cloudflare offers many capabilities; one of the capabilities it offers is SSL offloading and CNAME flattening.

When setting up an Azure Web App using default settings, it is set up using HTTP, not HTTPS, so we will set the WebApp to your custom domain, then use Cloudflare to protect traffic from your user's browsers to Cloudflare, then encrypt traffic from Cloudflare to your website.

We will go through both setups, with the result being full end-to-end encryption of your Azure WebApp using Cloudflare and your custom domain.

Using Cloudflare without a backend Certificate

Using Cloudflare with a backend Certificate

By default, Azure WebApps have a wildcard cert for the following domains:

• *.azurewebsites.net
• With Subject alternative names for:
• *.scm.azurewebsites.net
• *.azure-mobile.net
• *.scm.azure-mobile.net
• *.sso.azurewebsites.net

This certificate allows you to use HTTPS using the default azurewebsites URL, which gets created when you create your Azure WebApp and is completely managed by Microsoft and the Azure ecosystem. Still, if you want to use your own Custom Domain, then these certificates won't work.

Prerequisites​

• Azure WebApp (supports Custom Domain SSL support, Custom Domains/SSL support are available from ‘B1’ plans and upwards.)
• Cloudflare account (can be free)
• Domain (an actual custom domain to use for your website that is already setup to use Cloudflare nameservers)
• PfxCreator

Add a Custom Domain to your Azure WebApp using Cloudflare​

1. Login into the Azure Portal
2. Navigate to your App Service.
3. Underneath Settings on the left-hand side blade of the App Settings, look for Custom Domains and select it.
4. Click on ‘Add Custom Domain’.
5. type in your custom domain (in my example, I am using a domain I own called: badasscloud.com)
6. Select Validate; you will have a similar seen to me below; select CNAME.
7. Now we need to validate that you are the one who owns the domains and can use it for your WebApp, so we will need to create some records to verify that you own the domain and redirect the website to the Azure Websites.
8. Login to Cloudflare
9. Select SSL/TLS and make sure that ‘Flexible’ SSL has been selected.
10. Select DNS Note: You may need to remove any A records for ‘www’ or the root domain ‘@’ you have set; please make sure you have a reference to them in case you need to roll back any changes because we will be redirecting the main URL to an Azure DNS alias, we will be using Cloudflare CNAME flattening at the root level, so anyone going to ‘badasscloud.com’ will be redirected to the Azure WebApp.
11. You can also use the txt record to validate the domain and do some reconfiguration without changing the domain and redirecting traffic ahead of your change to avoid downtime.
12. Add in the records to Cloudflare (please note that verification will fail if Cloudflare proxy is turned on, so make sure that the proxy status is set to DNS only)
13. Navigate back to the Azure Portal.
14. Click on Validate again and select CNAME.
15. Hostname availability and Domain ownership should be both green.
16. Add Custom Domain.
17. If they are still Red, wait a few minutes for Cloudflare to replicate the changes across its Networks and Azure to clear any server-side caching, verification can fail if you try to verify straight away.
18. Now that Domain verification has been completed navigate Cloudflare and enable the Cloudflare proxy for your root domain and www record.
19. Navigate and test your website. Now that the domain has been added to the Azure WebApp and Cloudflare proxy has been enabled, your website will now have a certificate supplied by Cloudflare. You have now set up Flexible SSL traffic to your website, so traffic between users’ browsers to Cloudflare is now encrypted.

Update your WebApp to support ‘Full’ end-to-end using Cloudflare origin certificate​

Adding your domain to Cloudflare was only the first part of the puzzle; although traffic between the browser and Cloudflare is now encrypted, traffic between Cloudflare and your WebApp is not; to encrypt this traffic, we are going to use the Cloudflare origin certificate.

Cloudflare Origin Certificates are free SSL certificates issued by Cloudflare for installation on your origin server to facilitate end-to-end encryption for your visitors using HTTPS. Once deployed, they are compatible with the Strict SSL mode. By default, newly generated certificates are valid for 15 years, but you can change this to 7 days.

1. Log in to Cloudflare
2. Click on SSL/TLS
3. Click on Origin Server
4. Click on Create Certificate
5. Verify that the Private Key Type is RSA (2048)
6. Make sure that the Hostnames you want to be covered under the origin cert is covered.
7. Verify certificate validity, in my example, and I am going with 15 years; remember to keep this certificate validated and updated.
8. Click Create
9. Cloudflare will now generate your Origin certificate and Private key (save these somewhere secure, the private key will not be shown again).
10. Now we need to create a certificate PFX file to upload to the Azure WebApp, run PfxCreator.exe (see Prerequisites for download link)
11. Paste the Origin Certificate into the: Certificate (PEM)
12. Paste the Private Key into the Private Key (PEM)
13. Type in a password for the certificate
14. Click Save PFX… and save your certificate.
15. Login into the Azure Portal
16. Navigate to your App Service.
17. Underneath Settings on the left-hand side blade of the App Settings, look for Custom Domains and select it.
18. You should see the SSL state of your domain as ‘Not Secure’, and under SSL Binding, you will have an option to Add Binding, click on Add Binding.
19. Select your Custom Domain and click Upload PFX Certificate
20. Click File and browse for your certificate.
21. Type in the password you entered PFXCreator earlier.
22. Click on Upload.
23. Once uploaded, select your Custom Domain.
24. Select the Cloudflare Origin Certificate
25. Make sure the TLS/SSL type is: SNI SSL and click Add Binding.
26. The SSL State of your Custom Domain should now have been changed to Secure.
27. Click on HTTPS Only Note: You may see constant redirect issues with your website until the following Cloudflare changes have been made.
28. Login to Cloudflare
29. Select SSL/TLS and make sure that ‘Full (Strict)’ has been selected.
30. Give it 30 seconds to a minute to take effect, and you have now successfully encrypted traffic end-to-end on your website, from the browser to Cloudflare and from Cloudflare to your Azure WebApp.

#ProTip - If you want to be more secure, you can look into blocking access to your website from Cloudflare and a few select IPs for testing only to avoid traffic from bypassing Cloudflare and going to the azure websites URL.