Thursday, February 9, 2017

Securing RD Gateway with MFA using the new NPS Extension for Azure MFA!

Back in 2014 I co-authored an article together with Kristin Griffin on how to secure RD Gateway with Azure MFA. This article was based on putting an Azure MFA Server (previously Phone Factor) in place in your on-premises environment (or Azure IaaS) to act as the MFA Server and enforce Multifactor Authentication for all session coming through RD Gateway. You can get the article here: Step By Step – Using Windows Server 2012 R2 RD Gateway with Azure Multifactor Authentication. Although this is a great solution and I have successfully implemented this for various customers, the big downside has always been the mandatory MFA Server. As part of the setup, a server in your Active Directory had to be installed running the Azure MFA Server component to be able to inject Azure MFA into the login sequence. Not only did you have to install and maintain this MFA Server, synching and managing users (and in most cases you would set up 2 servers to be HA), the other downside was that this was yet another MFA Provider for your end user. MFA server comes with a self-service portal to allow users to do their own enrollment and it can leverage the same Azure Authenticator App. However, if your end users used Azure MFA to secure e.g. Office365 or other SaaS services, that would be a different MFA provider, with a different Self Service signup sequence etc.

Introducing the NPS Extension for Azure MFA
So what has changed? A few days ago Microsoft announced the availability of the Azure MFA Extension for NPS (preview)! Read about the announcement where Alex Simons, Director of Program Management of the Microsoft Identity Division and Yossi Banai, Program Manager on the Azure Active Directory team talk about this new (preview) feature here:

Azure AD News: Azure MFA cloud based protection for on-premises VPNs is now in public preview!

Although the article specifically talks about securing a VPN, I figured the same would apply to secure Remote Desktop Gateway. And it turned out it does! In my lab I was able to successfully secure RD Gateway with Azure MFA using this new Extension for NPS! In this article I want to take you through the setup process and show the end result.


There are a few prerequisites to use the NPS extension for Azure MFA, these are:

- License
For this to work you obviously need a license for Azure MFA. This is included with Azure AD Premium, EM+S, or it can be based on an Azure MFA subscription

- NPS Server
A Server is needed where the NPS role is installed. This needs to be at least Windows Server 2008 R2 SP1 and can be combined with other roles, however it cannot be combined with the RD Gateway role itself.

- Libraries
The below two libraries are needed on the NPS server, although Microsoft Guidance says the NPS Extension installer performs those installations if they are not in place, it doesn’t. Be sure to download and install these components prior to installing the NPS Extension.

1 Microsoft Visual Studio 2013 C++ Redistributable (X64)
2 Microsoft Azure Active Directory Module for Windows PowerShell version 1.1.166

- Azure Active Directory

Obviously Azure Active Directory has to be in place and users who need access, need to have been enabled to use MFA.


As mentioned in the introduction, I have written an article on securing RD Gateway with Azure MFA Server before. As you read though the installation & configuration process, you’ll see similarities with this article. That is not a coincidence, the same basic principles of RD Gateway, RD CAP, Radius Client, Remote Radius Servers et cetera all also apply on this setup.

Installing and configuring AAD & AAD Sync
Note, if you already have AAD & AAD Sync in place you can obviously skip this paragraph.
First things first, you need Azure Active Directory as a prerequisite. I won’t go over the entire process of setting up ADDS and AAD because there are many guides out there that explain this process very well. Basically you create a new AAD using the Azure Classic portal (or PowerShell), similar to below.

With AAD in place, you can then start to sync your users from an on premises ADDS (or like in my case one that is running on Azure IaaS). To manage the AAD you can already use the New Azure Portal as shown below, although do be aware that this feature is still in preview in this portal. You can also use this portal to get a link to the most recent version or Microsoft Azure Active Directory Connect that you need to be able to sync users from ADDS to AAD.

Again, I won’t go into great detail explaining the installation & best practices of installing AAD Connect, if you need detailed guidance on that part, check Connect Active Directory with Azure Active Directory. Basically what you do is run the installer on a server that is part of your ADDS domain and the only thing you will have to provide are the credentials of an AAD account and an ADDS connect with the appropriate permissions to access both domains.

Once you have successfully finished the setup of AAD Connect and the initial synchronization took place, the portal will reflect this as shown below.

With the initial synchronization complete, you can now start to assign Azure MFA to your users. To do this, open the All Users section in the Azure Portal and click on the Multi-Factor Authentication link.

That will take you to the Azure MFA Management Portal. In the screenshot below you can see the steps to enable and enforce Azure MFA for my test user called rdstestmfa.

Installing and configuring the NPS Extension for Azure MFA
Now that we have AAD and AAD Sync in place, lets drill down into the actual installation of the NPS Extension for Azure MFA! The first step is to download the latest version of the installer, which can be found here: NPS Extension for Azure MFA.

The NPS Extension needs to be installed on a (virtual) server that is part of the ADDS domain and that is able to reach the RD Gateway. In my case I used an ou-of-the-box Windows Server 2016 VM in Azure IaaS, but it can be anything from Windows Server 2008 R2 SP1 or above. Before installing the Extension, 3 other requirements need to be place.

1. The NPS Server role needs to be installed. Open Server Manager and add the role called Network Policy and Access Services.

2. The library Microsoft Visual Studio 2013 C++ Redistributable (X64) needs to be installed. Microsoft documentation says this library is installed automatically as part of the NPS Extension installer, the current Preview version does however not do this yet. You can get the download here

3. The Microsoft Azure Active Directory Module for Windows PowerShell version 1.1.166 needs to be installed. Again, Microsoft documentation says this module is installed automatically as part of the NPS Extension installer, but the current Preview version does not do this yet. You can get that download here

Now that we have the prerequisites in place, we can start the NPS Extension installer. The setup is very straight forward, just hit Install and wait for the process to finish.

After the installation is finished, the Extension components are placed in the folder C:\Program Files\Microsoft\AzureMfa\

Now open a new PowerShell Prompt (with elevated permissions) and change the directory to C:\Program Files\Microsoft\AzureMfa\Config and run the PowerShell script called AzureMfaNpsExtnConfigSetup.ps1. The output should look similar to below.

While the PowerShell Script runs it will prompt you for the ID of your Azure AD tenant, you can find that in the Azure Portal, in the properties of your AAD domain.

The PowerShell script will prompt you to authenticate to AAD with appropriate permissions. The PowerShell script then performs the following actions (source).

- Create a self-signed certificate.
- Associate the public key of the certificate to the service principal on Azure AD.
- Store the cert in the local machine cert store.
- Grant access to the certificate’s private key to Network User.
- Restart the NPS.

This completes the installation of the NPS Extension. The final step is to connect RD Gateway to this NPS Extension to get Azure MFA into the authentication process.

It’s important to realize that installing the NPS Extension causes all authentications processed by this NPS server to go through Azure MFA. There is now way to make exceptions for specific users.

Configuring RD Gateway
With the installation of the NPS Extension complete, it’s now time to configure RD Gateway. As mentioned before, this process is very similar to what Kristin Griffin and I explained here. The first step is to configure RD Gateway to use a Central Server running NPS. To do so, open RD Gateway Manager, right click the server name, and select Properties. Now select the RD CAP Store tab, select the Central Server running NPS option and enter the IP address of the NPS Server where you previously installed the NPS Extension. Also provide a shared key and store this somewhere safe.

Now open NPS on the RD Gateway Server (not on the NPS Server that contains the NPS Extension, we’ll do that later).

Open the Remote RADIUS Server Groups and open the TS GATEWAY SERVER GROUP. Enter the IP Address of the NPS Server running the extension as a RADIUS Server, edit it and make sure the timeout settings match what is shown below.

Now go to the RADIUS clients tab and create a new radius client with a friendly name, the IP address of the NPS Server running the Extension and enter the same shared secret you used before.

Next, we need to configure two Connection Request Policies in NPS, one to forward requests to the Remote RADIUS Server Group (which is set to forward to NPS server running the extension), and the other to receive requests coming from MFA server (to be handled locally).

The easiest way to do this is to use the existing policy that was created when you created an RD CAP in RD Gateway. In NPS, expand the Policies section in the left side of the screen and then select Connection Request Policies. You should see a policy already created there, called TS GATEWAY AUTHORIZATION POLICY. Copy that Policy twice and rename those copies to “MFA Server Request No Forward” and “MFA Server Request Forward”.

Now edit the MFA Server Request No Forward and set the following settings, where Client IPv4 Address is the IP Address of the NPS Server running the NPS Extension. Make sure you also enable this policy.

Now edit the MFA Server Request Forward and set the following settings, so that this rule forwards to the TS SERVER GATEWAY GROUP. Again, make sure you also enable this policy.clip_image027[4]

And lastly, disable existing TS GATEWAY AUTHORIZATION POLICY, and set the processing order of the rules as shown below.

Configuring NPS Server
It’s now time to configure the NPS Server running the extension to make sure it can send and receive RADIUS requests too. Open NPS on the NPS Server (not on the RD Gateway Server we did that before).

Open the Remote RADIUS Server Groups and create a new group called RDGW. Enter the IP Address of the RD Gateway as a RADIUS Server, edit it and make sure the timeout settings match what is shown below.

Now go to the RADIUS clients tab and create a new radius client with a friendly name, the IP address of the RD Gateway Server and enter the shared secret you used before.

Go to the Connection Request Policies tab and create a new Policy called To RDGW and use the source Remote Desktop Gateway. Set the condition to Virtual (VPN) and configure it to forward requests to the Remote Radius Group called RDGW that we created before. Make sure the policy is enabled. Below is was the Policy should look like.

Create another Policy called From RDGW and again use the source Remote Desktop Gateway. Set the condition to Client IPv4 Address and enter the IP address of the RD Gateway server. Configure it to handle request locally. Make sure the policy is enabled. Below is was the Policy should look like.

Preparing the user account for Azure MFA
Since our test user called is new to the organization, we first need to make sure that our test user is successfully configured to use Azure MFA. If your users are already configured for Azure MFA, you can obviously skip this step.

An easy way to do this is to logon to and sign in with the account. Since our test account was enforced to use Azure MFA, the portal will prompt us to configure MFA before we can continue. Click Set it up now to start that process.clip_image038[4]

In this case I chose Mobile App as the authentication method, downloaded the Azure Authenticator App for iOS and used that to scan the QR image on the portal. The Azure Authenticator App is available for Android, iOS of Windows Phone.clip_image040[4]

Click Done. To complete the verification, Azure MFA will now send an MFA request to the configured phone number of the user account.

The user account is now ready to use for our RD Gateway setup! If you want more detailed information on the Azure MFA Service, you can find that here: What is Azure Multi-Factor Authentication?

Testing the functionality
It’s now finally time to take a look at the end result!

You can basically use any RDP Client that has support for RD Gateway. For this scenario we’ll use the RD Web Access page. We log on to RD Web Access with our account and open the Desktop. In this case we used a Full Desktop Scenario, but these could also have been RemoteApps. The RDP Client will be launched showing the state Initiating Remote Connections.clip_image044[4]

A few seconds later, the NPS Extension will be triggered to send Azure MFA a request to prompt our user for two-factor authentication.

After pressing Verify on the Phone and without the user having to interact with the computer, the status changes to Loading the virtual machine.

And the desktop is then launched.

The end result is a great and seamless experience for the end user. Similar to using Azure MFA Server, but this time NPS directly contacting Azure MFA! This is a great improvement!

When troubleshooting this setup, there are several Eventlogs that could come in handy.

The RD Gateway role logs event in the location:
Application and Services Logs > Microsoft > Windows > Terminal Services Gateway
Below is an example of the event that shows that end user met the requirements of the RD CAP.

The NPS Service role logs event in the location:
Custom Views > Server Roles > Network Policy and Access Services
Below is an example of NPS Granting access to a user. You can also check the Windows Security log for Auditing events.

And finally, the NPS Extension role logs event in the location:
Application and Services Logs > Microsoft > AzureMfa

Additionally, you can also use the Azure MFA Portal to create reports on the usage of Azure MFA.

This article ended up to become >2500 words, but I hope you find it valuable. To reiterate on what is explained in the instruction; MFA Server is this is a great solution. The big downside however has always been the mandatory MFA Server, and in most cases you would set up 2 of them to be HA. The other downside is that this was yet another MFA Provider for your end user. With the introduction of the NPS Extension for Azure MFA these downsides are now gone! You can now secure your RDS environment with Azure MFA without the need for MFA Server and a separate MFA Provider. I really believe this is a game changer not only for this scenario, but also for all other scenarios like VPN’s, websites et cetera where Azure MFA Server is currently in place. Great job by Microsoft and looking forward to this Extension becoming GA!

Tuesday, January 17, 2017

Creating a 100 RDSH Server RDS Deployment in Azure IaaS using ARM/JSON

If you have been following this blog you will have noticed the series on using Azure Resource Manager to perform an automated deployment of Remote Desktop Services in Azure IaaS. If not, here are links to the previous eight articles to get you up to speed: article1, article2, article3, article4, article5, article6, article7, article8.
clip_image002This article continues the story, but this time it’s different. In my continuous mission on improving the JSON script and sharing my journey here, I decided to take the JSON script to another level and push it to deploy a 100 RDSH Server deployment in Azure IaaS. And so I did. Along the way, I sacrificed 140 EUR worth of MSDN Azure Credits to accomplish this, but it was worth the fun! In this article I would like to share the outcome and also share the issues and limitations I ran into.

Getting started
If you have been reading my other articles in this series, you’ll remember that part the JSON script I discussed in there touches on the ‘Copy’ parameter and corresponding ‘CopyIndex()’ function. This is key to deploying multiple Azure Resources of the same type in a fast way. To reiterate on that, the Copy parameter in an Azure Resource is used to specify that you want ARM to deploy an Azure Resource multiple times. As per example below, we use the Copy parameter to deploy an RDSH server in Azure IaaS multiple times by specifying a value in the parameter numberOfRdshInstances.
"copy": {
  "name": "[concat(parameters('RDSHHostNamePrefix'),'vm-loop')]",
  "count": "[parameters('numberOfRdshInstances')]"
And throughout the rest of the declaration of the Azure Resource, we can use the function ‘CopyIndex()’ to refer to the specific created resource. To provide a few example of that, below we use the ‘CopyIndex()’ function to create a unique name for the Virtual Machine.
"name": "[concat(parameters('RDSHHostNamePrefix'),'0', copyindex(1))]",
And to create a matching Hostname Virtual Machine.
"computerName": "[concat(parameters('RDSHHostNamePrefix'),'0', copyindex(1))]",
And also to create a matching reference in the depends on section, pointing to the connected Virtual Network Adapter.
"[concat('Microsoft.Network/networkInterfaces/', parameters('RDSHHostNamePrefix'),'0', copyindex(1), parameters('NetworkAdapterNamePostFix'))]"
Based on the information above the first step would be to provide the parameter 'numberOfRdshInstances' with the desired number. In this case I performed this by simply modifying the corresponding this parameter in the azuredeploy.parameters.json file to 100.

If we would then kick of this deployment in an average Azure Subscription, it will most likely fail. In most cases the error would be something similar to below.

Operation results in exceeding quota limits of Core. Maximum allowed: 40, Current in use: 5, additional requested 208This is because Azure sets limitations to various resources to prevent you from accidentially deploying resources you did not intend to, leading to what they call a ‘billshock’.

The additionally requested number of 208 cores is the sum of:
- 2 RD Connection Broker Servers of type Standard_D2 (2 Cores)
- 2 RD Gateway / Web Access Servers Standard_D2 (2 Cores)
- 100 RD Session Host Servers Standard_D2 (2 Cores)

The steps to work arround this limitation are easy. Log on to the Azure Portal, and click on ‘New support request’

Follow the steps and create a new support request to raise the Core limit. In this case I chose the safe side and created a request to raise the limit to 250 cores.

In most cases the limit will be raised within 24 hours, and you’ll receive a notification from Microsoft Support to confirm this as shown below.

Now that we have 250 cores available for D-series VM’s we can kick off the deployment. On a side note, keep in mind that the subnet you select to use has enough free DHCP IP addresses. Or, in case you’re using fixed IP adresses like I do in my script, make sure you use a starting IP that results in enough space to host 100 IP addresses. The way I approached this is by starting with .60 as last octet of the IP address of the first RDSH NIC and then using the CopyIndex() function to create unique IP addresses ending with .61, .62 et cetera. The code below shows how this works.
"ipConfigurations": [
    "name": "[parameters('NetworkAdapterIPConfigName')]",
    "properties": {
      "privateIPAllocationMethod": "[parameters('NetworkAdapterIPAllocationMethod')]",
      "PrivateIpAddress": "[concat(parameters('InternalIPAddressPrefix/24'),`
    "subnet": {
      "id": "[variables('subnet-id')]"

Kicking off the deployment
At this stage we’re ready to kick the tires of this deployment for the first time. Running a 100+ Server deployment from ARM is a phenomenal sight. Literally within seconds of the launch of the deployment hundreds or resources are being created in Azure. Below is what the first few seconds looked like from the Visual Studio output.clip_image012

Within a minute, 100 Virtual Network Adapters were created and Virtual Machines were
pinning up.

And soon after the Virtual Machines were created, each would run their own Custom Extension to add itself to the existing Active Directory Domain. In the screenshot below, 81 RDSH Server have already been added.

So far so good. A limitation I then ran into however, was inside the process of creating the RDS deployment itself. If you remember from previous articles, we use a Custom Script Extension that launches a PowerShell script on the RD Connection Broker server. This script is, amongst other things, responsible for creating the initial RDS deployment and adding the RDSH Servers to that deployment. Below is the sniped of that PowerShell script where the RDS deployment is created.
#Create the basic RDS Deployment
$scriptreateBasicDeployment = {
    param($ConnectionBroker1, $Gateway1, $SessionHost1)
    import-module RemoteDesktop
    New-RDSessionDeployment -ConnectionBroker $ConnectionBroker1 -WebAccessServer $Gateway1 -SessionHost $SessionHosts

The CmdLet New-RDSessionDeployment accepts a parameter called ‘SessionHost’. This parameter allows you to specify a single RD Session Host server or, as in my example, an array of multiple RD Session Host servers. In this case, the script constructed an array consisting of 100 RD Session Host servers. It is at this point where I ran into a limitation. The New-RDSessionDeployment did not like the fact that I passed an array of 100 servers. The CmdLet seemed to hang and did not output anything. I left it running for about an hour and then decided to cancel the deployment and redesign this part of the script.

I now tried a different approach. Instead of passing an array of 100 servers in the New-RDSessionDeployment, I passed the first RDSH server only. Followed by that statement I used a for..each loop holding the Add-RDServer Cmdlet that can be used to add a single RDSH Server to an existing deployment.
Add-RDServer -Server $SessionHost -Role RDS-RD-SERVER -ConnectionBroker $ConnectionBroker

And although this approach worked, the process was very slow. On average, the Add-RDServer Cmdlet seemed to take ~2 minutes which would result in >200 minutes to complete this process.

I now took the Add-RDServer out of the script again, and instead of running that command sequential for each RD Session Host from the RD Connection Broker Custom Extension, I created a Custom Extension for the RD Session Host servers. The result is that each RD Session Host server would then add itself to the existing deployment and Session Collection, a far more effective approach.

Upon rerunning the deployment again (while also watching the Azure Credits go down fast) this approach seemed to be working really well! RD Session Host servers started adding themselves relatively quickly. This time it completed successfully!

Below is a screenshot of the deployment in process where each RDSH Server runs its own Custom Extension.

The end result is an RDS Deployment consisting of 108 RDS server rolesclip_image020

With 100 RDSH Servers into a single Session Collection.

This concludes the journey. The end conclusion is that yes you can create a 100 RDSH server automated RDS deployment using JSON and ARM. Although it’s most likely not a very common scenario, it was interesting to see what challenges and limitation we would face deploying that many servers in an automated way and a fun exercise. Being able to provision this many servers in such a short period of time really is one of the many powers behind Microsoft Azure. It truly is a very powerful and flexible Cloud platform.

Tuesday, January 3, 2017

Azure Resource Manager and JSON templates to deploy RDS in Azure IaaS – Part 8 Defender & BGinfo

This article is part 8 in a series of articles on deploying RDS in Azure IaaS using ARM & JSON Templates. Here is a quick overview of previous articles on this topic.

1. Full HA RDS 2016 deployment in Azure IaaS in < 30 minutes, Azure Resource Manager
2. RDS on Azure IaaS using ARM & JSON part 2 – demo at Microsoft Ignite!
3. Video of Ignite session showing RDS on Azure IaaS deployment using ARM/JSON
4. Windows Server 2016 GA available in Azure! – used it to deploy RDS on Azure IaaS!
5. Azure Resource Manager and JSON templates to deploy RDS in Azure IaaS – Part 5
6. Azure Resource Manager and JSON templates to deploy RDS in Azure IaaS – Part 6 RD

7. Azure Resource Manager and JSON templates to deploy RDS in Azure IaaS – Part 7 RD Web Access customization

In this part of the series, we’ll add both Microsoft Antimalware for Azure Virtual Machines (Defender) and BGInfo to the deployment.

If you’re not familiar with one of these tools, here is a brief introduction.

What is Microsoft Antimalware for Azure Virtual Machines?
Microsoft Antimalware for Azure Virtual Machines is a real-time protection capability that helps identify and remove viruses, spyware, and other malicious software, with configurable alerts when known malicious or unwanted software attempts to install itself or run on your system.

What is BGInfo?
BGinfo is a small but very powerful Sysinternals tool that automatically displays relevant information about a Windows computer on the desktop's background, such as the computer name, IP address, service pack version, and more.

Using ARM to deploy Microsoft Antimalware for Azure Virtual Machines (Defender)Let’s start with adding Microsoft Antimalware for Azure Virtual Machines, which we’ll refer to as Defender in this blog post. When running a Virtual Machine in Azure IaaS, Defender can be installed as an extension on top of a Virtual Machine, including specific exclusions you might want to have.

To easily add Defender to Virtual Machines that we’re running for our RDS deployment we’re using the extension called IaaSAntimalware. The JSON code to add the Defender extension to our VM’s looks like below. Basically we create a new VirtualMachine Extension and set ‘IaaSAntimalware’ as the type. Using the settings section, we can then further define the custom settings. In this case we define whether or not real time protection is enabled, and what type of periodic scan is performed. Furthermore, we define the file type extensions, paths and processes we want Defender to exclude. clip_image004

To be able to define different exclusions for the different RDS roles, we define separate exclusion parameters for each role type. To accomplish this, we introduce the following parameters for each role type.

And the following parameters are shared across all role types to define the scan schedules.

When running the ARM template, we can define all of the parameters to customize the usage of Defender to our needs. By default, the periodic scan is scheduled weekly at midnight performing a quick scan but this can obviously be modified at will.

As you can see we can also enable or disable real time protection per role. And we can configure a semicolon separate list of exclusions to exclude paths, processes en file extentions. The exclusions are important to configure to not run into any unnecessary performance issues after deploying Defender. For example, for the RD Gateway role I added the following exclusions, a mix of common exclusions like the logs & databases of the SoftwareDistribution folder, eventlogs and IIS log files. %windir%\SoftwareDistribution\Datastore\Datastore.edb%windir%\SoftwareDistribution\Datastore\Logs\Res*.log%windir%\SoftwareDistribution\Datastore\Logs\Edb*.jrs%windir%\SoftwareDistribution\Datastore\Logs\Edb.chk%windir%\SoftwareDistribution\Datastore\Logs\Tmp.edb%windir%\Security\Database\*.edb%windir%\Security\Database\*.sdb%windir%\Security\Database\*.log%windir%\Security\Database\*.chk%windir%\Security\Database\*.jrs%allusersprofile%\NTUser.pol%Systemroot%\System32\GroupPolicy\Registry.polC:\inetpub\logs\LogFiles\W3SVC1\*.log%SystemRoot%\System32\Winevt\Logs\*.evtx%SystemRoot%\SYSTEM32\Logfiles\*.logFor the RD Session Host role, it’s also important to take a close look at exclusion, especially because these are the servers that will host active user sessions. Common exclusions for the RD Session Host role are e.g. the Printer Spooler, the winlogon process, etc.

After completion, the Azure Portal shows a defender extension object per virtual machine.clip_image012

And when logging on to one of the created Virtual Machines, in this example one of the RD Gateway Servers, we can see that Defender is running with real time protection enabled.clip_image014

And we can confirm that the exclusions we defined in our JSON parameters files are correctly configured as well.

Using ARM to deploy Sysinternals BGInfoLet’s now look at the second addition in this blog post, BGInfo. If you’re managing multiple different servers for your organization or maybe even for multiple organizations, I’m sure you’re familiar with BGInfo. BGInfo allows you to display details like IP addresses, hostname, bootime etc. about the Virtual Machine you’re currently connected to. It’s a great tool that has been out there for many years. Of course you can manually download and install the BGInfo tool on all your servers, but since we’re doing an entire deployment based on Azure Resource Manager, let’s use ARM for this deployment as well.

Installing BGInfo from ARM is actually much easier than you might expect. There is a BGInfo Extension that you can directly reference from ARM. You create a new resource of type extentions and provide ‘BGInfo’ in the type in the properties. We do this for each of the loops of Virtual Machines we’re creating (hence the copyindex function in the name) and that’s basically it.

Alter completion the Azure Portal shows the various BGInfo resources.clip_image020

And when logging in on one of the servers we can see the result, BGInfo is there!

ARM Extensions like Defender and BgInfo add even more power to Virtual Machines running in Azure IaaS. These are just 2 examples of extensions that I thought would make sense to add to existing RDS deployment, but there are many more out there.

This concludes part 8 in a series of articles on deploying RDS in Azure IaaS using ARM & JSON Templates.