Azure AD Domain Services

I recently had what I thought was a rather unique requirement from a customer.
The requirement was to build Azure IaaS virtual machines and have them joined to a managed domain, while also being able to authenticate to the virtual machines using Azure AD credentials.
The answer is Azure AD Domain Services!
Azure AD Domain Services provides managed domain services such as domain join, group policy and Kerberos/NTLM authentication without the need for you to deploy and  manage domain controllers in the cloud. For more information see
It is not without its limitations though, main things to call out is that configuring domain trusts and applying schema extensions is not possible with Azure AD Domain Services. For a full list of limitations see:
Unfortunately at this point in time you cannot use ARM templates to configure Azure AD Domain Services so you are limited to the Azure Portal or PowerShell. I am not going to bore you with the details of the deployment steps as it is quite simple and you can easily follow the steps supplied in the Microsoft documentation:
What I would like to do is point out the following learnings that I discovered during my deployment.

  1. In order to utilise Azure AD credentials that are synchronised from on-premises, synchronisation of NTLM/Kerberos credential hashes must be enabled in Azure AD Connect, this is not enabled by default.
  2. If there is any cloud-only user accounts, all users who need to use Azure AD Domain Services must change their passwords after Azure AD Domain Services is provisioned. The password change process causes the credential hashes for Kerberos and NTLM authentication to be generated in Azure AD.
  3. Once a cloud-only user account has changed their password, you will need to wait for a minimum of 20 minutes before you will be able to use Azure AD Domain Services (this got me as I was impatient).
  4. Speaking of patience the provisioning process of Azure Domain Services takes about an hour.
  5. Have a dedicated subnet for Azure AD Domain services to avoid any connectivity issues that may occur with NSGs/firewalls.
  6. You can only have one managed domain connected to your Azure Active Directory.

That’s it, hopefully this helped you get a better understanding of Azure AD Domain Services and assists with a smooth deployment.

Migrating VirtualBox VDI Virtual Machines to Azure


Over the years I’ve transitioned through a number of laptops and for whatever reason they never fully get put out to pasture. Two specific laptops are used semi-regularly for functions associated with a few virtual machines they hold. Over the last 10 years or so, I’ve been a big proponent of VirtualBox. It’s footprint and functionality aligned with my needs. The downside these days is needing to sometimes carry two laptops just to use an application or two contained inside a Virtual Machine on VirtualBox.
It’s 2017 and time to get with the times. Dedicate an evening of working through the process of migrating those VM’s.
DISCLAIMER and CONSIDERATIONS Keep in mind that if you are migrating legacy operating systems, you’ll need a method to remote into them once they are in Azure. Check the configuration of them before  you convert and migrate them. Do they have firewalls? Is the network interface on the VM configured for dynamic or static addressing? Do the VM have remote access configured, VNC, RDP, SSH. As they are also likely to be less secure my process below includes a Network Security Group as part of the Azure Resource Group with no rules specified. You’ll need to add some inbound rules for the method you’ll be using to remote into your Virtual Machine. And I STRONGLY suggest locking those rules down to a single host or home subnet.

The VM Conversion Process

This blog post covers the migration of a Windows Virtual Machine in VDI format from VirtualBox on SUSE Linux to Azure.

  • With the VM Started un-install the VBox Guest Additions from the virtual machine


  • Shutdown the VM
  • In VirtualBox Manager select the VM and Settings
    1. Select Storage. If the VBoxGuestAdditions CD/DVD is attached then remove it.
    2. Take note of the VM’s disk(s) location (WinXPv2.vdi in my case) and naming. Mine just had a single hard disk. You’ll need the path for the conversion utility.



  • Virtual Box includes a utility named vboxmanage. We can use that to convert the VM virtual hard disk from VDI to VHD format. Simply run vboxmanage clonehd –format VHD –variant Fixed
    • You will need to make sure you have enough space on your laptop hard disk for the VHD which will be about the same size as your VDI Hard Disk
      • If you don’t on Linux you’ll get a slightly cryptic message like
        • Could not create the clone medium (VERR_EOF)
        • VBOX_E_FILE_ERROR (0x80bb0004)
      • the –variant Fixed switch is not shown in the virtual disk conversion screenshot (three images further down the page). One of my other VM’s was Dynamic. Size needs to be Fixed for the VHD to be associated with a VM in Azure
      • Below shows determining an existing disk that is Dynamic and needs to be converted to Fixed


  • Below shows determining an existing disk that is Fixed and doesn’t need to be converted


  • Converting the VDI virtual disk to VHD


Preparing our Azure Environment for our new Virtual Machine

  • Whilst the conversion was taking place I logged into the Azure Portal and created a new Resource Group for my VM to go into. I also created a new Storage Account in that Resource Group to put the VM’s VHD into. Basically I’m keeping these specific individual VM’s that serve a very specific purpose in their own little compartment.


  • Using the fantastic Azure Storage Explorer which works on Linux, Mac and Windows I created a Blob Container in my newly created Storage Account named vhds.


Upload the Converted Virtual Hard Disk

  • By now my virtual disk had converted. Using the Azure Storage Explorer I uploaded my converted virtual disk. NOTE Make sure you have the ‘upload vhd/vhdx files as Page Blobs’ selected. 

For a couple of other VM’s I wrote a little PowerShell script to upload the VHD’s to blob storage.

Create the Azure VM

The following script follows on from the Resource Group, Storage Account and the Virtual Machine Virtual Disk we created and uploaded to Azure and creates the VM to attached to the virtual disk.
All the variables are up front, we create the Network Security Group, Subnet and Virtual Network. Then the Public IP and Network Interface. Finally we define the details for the VM with the networking and the uploaded VHD before creating the VM.

And we’re done. VM created and started.
Happy days and good bye to a number of old laptops.

Exchange Server 2016 in Azure

I recently worked on a project where I had to install Exchange Server 2016 on an Azure VM and I chose a D2 sized Azure VM (2 cores, 7GB RAM) thinking that will suffice, well that was a big mistake.
The installation made it to the last step before a warning appeared informing me that the server is low on memory resources and eventually terminated the installation, leaving it incomplete.
Let this be a warning to the rest of you, choose a D3 or above sized Azure VM to save yourself a whole lot of agony.
To try and salvage the Exchange install I attempted to re-run the installation as it detects an incomplete installation and tries to pick up where it failed previously, this did not work.
I then tried to uninstall Exchange completely by running command: “Setup.exe /mode:Uninstall /IAcceptExchangeServerLicenseTerms”. This also did not work as it was trying to uninstall an Exchange role that never got installed, this left me one option manually remove Exchange from Active Directory and rebuild the Azure VM. 
To remove the Exchange organisation from Active Directory I had to complete the following steps;

  1. On a Domain Controller | Open ADSI Edit
  2. Connect to the Configuration naming contextconfig-naming-context
  3. Expand Services
  4. Delete CN=Microsoft Exchange and CN=Microsoft Exchange Autodiscoverconfig-exchange-objects
  5. Connect to the Default naming contextdefault-naming-context
  6. Under the root OU delete OU=Microsoft Exchange Security Groups and CN=Microsoft Exchange System Objects delete-exchange-objects
  7. Open Active Directory Users and Computers
  8. Select the Users OU
  9. Delete the following:
    • DiscoverySearchMailbox{GUID}
    • Exchange Online-ApplicationAccount
    • Migration.GUID
    • SystemMailbox{GUID}ad-exchange-objects

After Exchange was completely removed from Active Directory and my Azure VM was rebuilt with a D3 size I could successfully install Exchange Server 2016.

Exchange Server 2016 install error: “Active Directory could not be contacted”

I recently worked on a project where I had to install Exchange Server 2016 on an Azure VM and received error “Active Directory could not be contacted”.
To resolve the issue, I had to complete the following steps;

  1. Remove the Azure VM public IP address
  2. Disable IPv6 on the NICipv6-disabled
  3. Set the IPv4 DNS suffix to point to your domain. If a public address is being used it will be set to by default.dns-suffix

Once done the installation could proceed and Active Directory was contactable.

Microsoft Azure Pricing Calculator

Originally posted in Lucian’s blog over at

Whether you’re wanting to deploy a new workload in Microsoft Azure, wanting to extend an existing workload via a hybrid scenario or like me wanting to use Azure outside of work to gain more knowledge and experience, the pay-as-you-go charge model can often times intimidate and even deter many from using a cloud service like Azure. From a lab or dev point of view, it is all well and good to dabble in Azure at the various tiers of engagement, but at the end of the day you could be left with a credit card bill allot larger than expected. Enter the Microsoft Azure Pricing Calculator where you can accurately estimate your potential usage for any given service.


Read More

Highly Available SQL 2012 across Azure VNET (Part 2)

Part 1 can be found here.

In this Part 2 we will discuss:

  • Create DC on Azure and confirm VNET to VNET connectivity
  • SQL VMs
  • Configure WSFC and lastly configure AAG

DC and Connectivity VNET to VNET

First thing first, we need VMs for the Domain Controller (DC) and SQL Server 2012. I will use my script below to create few VMs

I created 2 DC , one on each VNET: AZSEDC001 and AZUSDC001
I registered both as DNS on Azure. The next step , allow ICMP on wf.msc as we are going to test ping on both servers.




Great. Now we have confirmed the connectivity between both DC and connectivity between SEVNET and USVNET.


Created 2 SQL VMs ( AZSEDB001 and AZSEDB002) under one Cloud Service (AZSEDB) on Azure-Backend Subnet of SEVNET . Domain Joined both SQL server

Configure WSFC

For this scenario, I created three extra accounts on AD:

1. kloud\kloudinstall – for failover cluster and AG. Give permission Allow for Read all properties and Create Computer Objects via AD. Assign Local Admin permission on both SQL Servers 

2. kloud\svcsql1 and kloud\svcsql2

Next part, Add Failover Clustering feature on both servers and install the HotFix for Windows 2012 cluster-based node

1. Create the WSFC Cluster:


2. Create multi – node cluster on azsedc001 (Add all VMs using Wizard and the Wizard will smart enough to detect multi-subnet) and do not choose require support from Microsoft for this cluster.


3. Configure Quorum File Share Witness on other machines. I configure it on SEVNET DC
4. Change the cluster IP address (WSFC will use azsedc001 IP: to unused IP. I used for SEVNET and for USVNET
5. Bring the cluster online:
You can test failover to USVNET by using PowerShell command below:

Click here for more details regarding multi-subnet WSFC

Configure AAG

1. Launch wf.msc to allow firewall inbound rules (All SQL Servers). Program: %ProgramFiles%\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Binn\sqlservr.exe
2. Enable AlwaysOn Availability Group (all SQL servers): Launch SQL Server Configuration Wizard SQL Server Services SQL Server (MSSQLSERVER) > Tick Enable AlwaysOn Availability Group > Restart the Services



3.  Launch SQL Server Management Studio.  Add new Security Login for NTAuthority\System , go to SecurablesGrant: Alter any availability group, connect SQL, view server state and installer account with SysAdmin Server Role.


4. Change the SQL Service Account from NTService\MSSQLSERVER. In this case: svc_sql1 for AZSEDB001 and svc_sql2, svcsql3 for AZSEDB002 and AZUSDB001



AAG Steps:

1. Attach extra disk on AZSEDB001, Format the drive and Create a folder : backup on AZSEDB001. Share backup folder as below:



2. Go to AZSEDB001, Run SQL Management Studio and create new Database: kloud1.

3. Take a full backup of the database: Right click kloud1 database > Tasks Back Up. Remove the default destination to \\azsedb001\backup\kloud1.bak



4. Do the Transactional Backup: Use the same destination file path

5. Restore the full and transactional log backups on azsedb002 and azusdb001. On SQL Server Management Studio (SSMS), Right click databases and select restore database. Click Device and Add Backup Media, Backup File location: \\azsedb001\backup. Choose the backup database: kloud1.bak


6. Click Options and select Restore with No Recovery in Recovery State and then click Ok to restore the database


7. Now the fun stuff, We will run AAG Wizard: Right click the AlwaysOn High Availability on SSMS and follow the wizard


8. In AAG WIzard Specify Replica session, follow instructions as follow:

What we have here: Two replicas – one (AZSEDB002) in SEVNET and one (AZUSDB001) in USVNET. The details configuration:


Note: AZUSDB001 configured with Asynchronous data replication since AZUSDB001 hosted hundreds of miles away from Southeast Asia data centre, latency will hurt the performances.

9. In the Select Initial Data Synchronization page, select Join only and click Next since we have done backup and restore operations which is recommended as best practice especially for enterprise database

10. Follow the wizard, typical click – click – next. Igone the listener configuration warning. Finish.

The AAG dashboard by now:


More details can be found here.

Configure the Listener:

Next we will create the AAG listener:

1. Create load-balanced Azure VM endpoints for each Azure VM

2. Install KB2854082 for Windows Server 2008R2 and Windows Server 2012 cluster nodes.

3. Open the firewall ports to allow inbound rules Ports: 59999 specified earlier on Step 1.

4. Create the AG listener:
Open Failover Cluster Manager > Expand the AAG cluster name > Roles >
Right click the AG name and select Add Resource > Client Access Point




Click the Resources tab right click the listener > Properties > Note the IP Address Name and Network Name

Get the Cloud Service VIP on both SEVNET and USVNET. Run the script below on AZSEDB001

Once completed:


Create a dependency on the listener name resource. Right click the Availability Group and click Properties:


Launch SSMS > Go to AlwaysOn High Availability > Availability Groups > AAG Listener Name > Properties and specify Port: 1433

And that’s it. We have Highly Available SQL 2012 AAG across Azure VNET

Follow this link for more details how to configure AlwaysOn in Azure.



Windows Azure Virtual Machine Domain Provisioning with PowerShell

Windows Azure Virtual Machines preview allows persistent Virtual Machines which retain the same private addresses on reboot. This means that Active Directory can easily run in Azure without worry of the Domain Controller IP changing. This also means that Virtual Machines running in Azure that can be joined to your on-premise Active Directory using a site-to-site IPsec VPN. The Azure VMs then act like a branch network with full connectivity. I covered setting up TMG 2010 as a VPN endpoint (instead of using Cisco or Juniper hardware devices) for Windows Azure Virtual Network in a previous post.

This post covers PowerShell provisioning of the first Azure Domain Controller and provisioning of subsequent domain joined member servers.

Install Azure PowerShell Cmdlets

Download the Azure PowerShell Cmdlets from the Azure download site. Follow the Getting Started with Windows Azure PowerShell steps to prepare PowerShell and authenticate.

VM Creation Documentation

The official New-AzureVM instructions do not contain all the commands needed for adding a server to the Azure Virtual Network and defining the subnet. Michael Washam has created two comprehensive blogs on PowerShell provisioning – Automating Windows Azure Virtual Machines with PowerShell and Connecting Windows Azure Virtual Machines with PowerShell but I wanted to cover off these two specific tasks as I required some other settings. An important thing to note is that Azure OS drives have write caching enabled. Microsoft recommend for Active Directory that you add a second drive which will be a ‘Data Disk’ and the Active Directory NTDS database and SYSVOL should be placed on the new drive which will have write caching disabled. This would apply equally for SQL and other transactional stores. More information is available here.

Install the First Domain Controller in Azure

A one off task I had to run was to set the Azure Subscription. We have two subscriptions so this may not be required for everyone.

Set-AzureSubscription -SubscriptionName “Kloud Solutions” -CurrentStorageAccount “kloudazurestorage”

The Azure PowerShell cmdlets are a bit different to PowerShell for Exchange, Lync and ActiveDirectory. Instead of having options on a command like I would expect e.g. new-AzureVM –Name DC –DNS etc., you have to build up the configuration line by line. All of the commands below can be done as one long line as seen in the examples above but I prefer to assign variables up top and then it is easy to see what needs to be modified when provisioning new servers.

Below are the commands for provisioning the first Domain Controller. This sets the primary DNS to be the local server with a secondary of the on-premise Domain Controller. We are specifying the name, base .vhd image, the instance size, second disk, DNS, local password, affinity group, Virtual Network and subnet.

Select-AzureSubscription “Kloud Solutions”

$VmName = “AzureTestDC01”

$Image = ‘MSFT__Win2K8R2SP1-120612-1520-121206-01-en-us-30GB.vhd’

$InstanceSize = “Small”

$Disk2Size = “10”

$Disk2Label = “SysvolDisk”

$DnsLocal = New-AzureDns -Name ‘AzureDC01’ -IPAddress ‘’

$DnsOnPrem = New-AzureDns -Name ‘OnPremDC01’ -IPAddress ‘’

$Password = ‘xxxxxxxxxxxx’

$AffinityGroup = “KloudAffinityGroup”

$VirtualNetwork = “KloudAzureNetwork”

$Subnet = “BackEndSubnet”

New-AzureVMConfig -Name $Vmname -ImageName $Image -InstanceSize $InstanceSize |

    Add-AzureProvisioningConfig -Windows -Password $Password |

    Set-AzureSubnet $Subnet |

    Add-AzureDataDisk -CreateNew -DiskSizeInGB $Disk2Size -DiskLabel $Disk2Label -LUN 0 |

    New-AzureVM -ServiceName $VmName -AffinityGroup $AffinityGroup -DnsSettings $DnsLocal,$DnsOnPrem -VNetName $VirtualNetwork

The provisioning script takes about a minute to run and around 5 minutes later the new Azure DC can be logged into and joined to the on-premise domain.

Provision Domain Joined Servers in Azure

The following commands provision a server that automatically joins the domain. It also includes the second data disk but that is not needed, just remove the ‘Add-AzureDataDisk line. This VM will use the Azure Domain Controller for primary DNS and the on-premise DNS as a secondary.

Select-AzureSubscription “Kloud Solutions”

$VmName = “AzureLync01”

$Image = ‘MSFT__Win2K8R2SP1-120612-1520-121206-01-en-us-30GB.vhd’

$InstanceSize = “Small”

$Disk2Size = “30”

$Disk2Label = “Lync”

$Domain = “Kloud”

$DomainDNS = “”

$DomainUserName = “svc_azure”

$DnsAzure = New-AzureDns -Name ‘AzureDC01’ -IPAddress ‘’

$DnsOnPrem = New-AzureDns -Name ‘OnPremDC01’ -IPAddress ‘’

$Password = ‘xxxxxxxxxxxx’

$AffinityGroup = “KloudAffinityGroup”

$VirtualNetwork = “KloudAzureNetwork”

$Subnet = “BackEndSubnet”

New-AzureVMConfig -Name $Vmname -ImageName $Image -InstanceSize $InstanceSize |

    Add-AzureProvisioningConfig -WindowsDomain -Password $Password -Domain $Domain -DomainPassword $Password -DomainUserName $DomainUserName -JoinDomain $DomainDNS |

    Set-AzureSubnet $Subnet |

    Add-AzureDataDisk -CreateNew -DiskSizeInGB $Disk2Size -DiskLabel $Disk2Label -LUN 0 |

    New-AzureVM -ServiceName $VmName -AffinityGroup $AffinityGroup -DnsSettings $DnsAzure,$DnsOnPrem -VNetName $VirtualNetwork

A few minutes later the server is joined to the domain and you can login with your on-premise domain account. To provision more Virtual Machines, all that is needed is to change the $VmName variable (and remove the second disk if not needed).

Windows Azure Virtual Network VPN with TMG 2010

Microsoft announced Windows Azure Virtual Network and Windows Azure Virtual Machines in June 2012 to provide IaaS ‘Hybrid Cloud’ functionality.

What this allows is persistent Virtual Machines (which retain the same private addresses) running in Azure that can be joined to your on-premise Active Directory using a site-to-site IPsec VPN. The Azure VMs then act like a branch network with full connectivity and you can add Domain Controllers in the Azure Virtual Network.

This is still a preview release and Microsoft currently only support specific Cisco and Juniper devices that have been tested. The VPN Devices for Virtual Network page explains that other devices may work as long as they support the following:

  • VPN device must have a public facing IPv4 address
  • VPN device must support IKEv1
  • Establish IPsec Security Associations in Tunnel mode
  • VPN device must support NAT-T
  • VPN device must support AES 128-bit encryption function, SHA-1 hashing function, and Diffie-Hellman Perfect Forward Secrecy in “Group 2” mode
  • VPN device must fragment packets before encapsulating with the VPN headers

TMG 2010 does support these requirements but getting full connectivity working has proven to be harder than expected. Hopefully this post will save others a lot of time.

Create Azure Virtual Network and Start Gateway

The first step is to create the Azure Virtual Network and Microsoft have a good tutorial explaining it here.

If you will be deploying Active Directory into your Virtual Network, you cannot use Azure DNS and will need to provide details for your AD DNS. More information is available here.

The first VM deployed to each subnet will get the .4 address for example For the DNS question (step 6 in the tutorial) enter the .4 address for your subnet and also add an on-premise DNS server for example

It is important to note that once you have created the Virtual Network and deployed a Virtual Machine the configuration cannot be modified, other than adding subnets. Hopefully this is something that will be available once these services are out of beta.

Starting the gateway can take a long time. I haven’t seen any documentation on how it works, but I suspect it is spinning up a VM in the background to act as the Azure VPN endpoint. Once the gateway is created, take note the IP address and Shared Key and we can move on to the TMG configuration.

Create TMG IPsec site-to-site VPN

During the setup of the TMG VPN I had a few times where I thought I had it working only to hit another stumbling block. The summary of the things I needed to change are:

  1. Setup TMG IPsec with a supported configuration
  2. Modify TMG network rule and access rule
  3. Make sure the TMG server has hotfix KB2523881 installed
  4. Change the TMG network card MTU to 1350
  5. Disable RPC strict compliance and restart TMG firewall service

IPsec Configuration

I used the content of this massive MSDN forum post to create the IPsec site-to-site VPN and get traffic flowing with the TMG configuration information coming from David Cervigon.

  1. Remote Access Policy (VPN) / Remote Sites / Create VPN Site-to-Site Connection
  2. Choose ‘IP Security protocol (IPsec) tunnel mode
  3. Remote VPN gateway IP address: enter the Azure Virtual Network gateway provided earlier
  4. Local VPN gateway IP address: enter the TMG external IP address
  5. Use pre-shared key for authentication: Enter Shared Key provided earlier
  6. Remote address ranges: Leave the Azure IP address and enter the Azure network range created earlier for example to
  7. Network rule: Create a route relationship and add other networks if required
  8. Access rule: Create an access rule and select ‘All outbound traffic’
  9. Address ranges: Leave the external interface and add the internal network ranges that need to communicate over the VPN
  10. Create the VPN and edit
  11. Under Connection / IPsec Settings ensure the following is set:
    1. Phase I
      1. Encryption algorithm: AES128
      2. Integrity algorithm: SHA1
      3. Diffie-Hellman group: Group 2 (1024 bit)
      4. Authenticate and generate a new key: 28800 seconds
    2. Phase II
      1. Encryption algorithm: AES128
      2. Integrity algorithm: SHA1
      3. Session key / Generate a new key every: Both enabled
      4. Kbytes: 102400000
      5. Seconds: 3600
      6. Use Perfect Forward Secrecy (PFS): Not selected
      7. Diffie-Hellman group: N/A

Below is the TMG IPsec configuration.

TMG Network and Access Rules

The automatically created Network Rule and Access Rule allow only one way initiated traffic.

  1. Modify the Network rule under Networking / Network Rules and add ‘Internal’ to the source network and ‘Azure’ to the destination network
  2. Modify the Access rule under Firewall Policy and add ‘Internal’ to the source network and ‘Azure’ to the destination network

Below is the TMG configuration.

TMG Server Hotfix KB2523881

At this point I could see the VPN connect:

However no traffic was flowing. I was running TMG 2010 SP 1 Software Update 1 and after installing hotfix KB2523881 the VPN worked. I tried to install the hotfix on another TMG server with SP 2 and all Windows Updates and it said it was not needed. This may be included in TMG 2010 SP 2 or as part of another update from Windows Update. (Update 26 July: tcpip.sys and fwpkclnt.sys are updated by Windows hotfix KB2582281 and MS12-032 KB2688338 )

TMG Network Card MTU

At this point I could add my first virtual machine, join it to the domain but could not get AD to replicate from on-premise to Azure. The issue was the MTU on the external network card on TMG which was mentioned somewhere in the MSDN forum above. The MTU needs to be set to 1350 to account for the IPsec overhead and the default is 1500.

  1. Open an administrative command prompt
  2. Run to show interfaces
    1. netsh interface ipv4 show interface
  3. Set external interface MTU
    1. netsh interface ipv4 set interface “EXT” MTU=1350

Below is a screenshot of the change.


Disable RPC Strict Compliance and Restart TMG Firewall Service

Almost there. The issue I faced now was that my Virtual Machine Domain Controller could not use any DCOM RPC services like certificate self-enrolment and opening the Certificate Authority MMC. TMG blocks all non endpoint mapper RPC traffic like DCOM – more information is available here. I tried disabling RPC strict compliance, changing the DCOM port and creating a custom rule as shown here but it did not work. I eventually tried to disable the RPC filter completely in System / Application Filters which, although drastic, did work. The reason it worked is because it forces a restart of the TMG Firewall service which it turns out is all that was needed to apply the previous configuration changes. I re-enabled the RPC filter and set the DCOM back to standard ports and from my testing the following is needed:

  1. Right click the Access rule, select ‘Configure RPC protocol’ and uncheck ‘Enforce strict RPC compliance’
  2. Edit the System policy ‘Firewall Policy / All Tasks / System Policy / Edit System Policy / Authentication Services / Active Directory’ and uncheck ‘Enforce strict RPC compliance’
  3. Apply the TMG configuration and wait for it to sync
  4. Important:The next step will disconnect all TMG sessions including VPN, RDP, ActiveSync, OWA etc. so should be performed out of hours
    1. Restart the ‘Microsoft Forefront TMG Firewall service

It Works!

That should be all that is needed. Not particularly hard but getting all the information and testing took a long time. I hope that this helps somebody and prevents a lot of wasted time.

The next blog will cover PowerShell provisioning the first Domain Controller in Azure so that it can join the on-premise domain and adding other domain joined machines.

Follow ...+

Kloud Blog - Follow