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.
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.
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).
Speaking of patience the provisioning process of Azure Domain Services takes about an hour.
Have a dedicated subnet for Azure AD Domain services to avoid any connectivity issues that may occur with NSGs/firewalls.
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.
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
Select Storage. If the VBoxGuestAdditions CD/DVD is attached then remove it.
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)
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.
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;
On a Domain Controller | Open ADSI Edit
Connect to the Configuration naming context
Delete CN=Microsoft Exchange and CN=Microsoft Exchange Autodiscover
Connect to the Default naming context
Under the root OU delete OU=Microsoft Exchange Security Groups and CN=Microsoft Exchange System Objects
Open Active Directory Users and Computers
Select the Users OU
Delete the following:
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.
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;
Remove the Azure VM public IP address
Disable IPv6 on the NIC
Set the IPv4 DNS suffix to point to your domain. If a public address is being used it will be set to reddog.microsoft.com by default.
Once done the installation could proceed and Active Directory was contactable.
Originally posted in Lucian’s blog over at lucian.blog.
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.
Create DC on Azure and confirm VNET to VNET connectivity
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
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 http://support.microsoft.com/kb/2803748
1. Create the WSFCCluster:
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: 10.0.1.4) to unused IP. I used 10.0.1.103 for SEVNET and 192.168.1.110 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
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 Securables, Grant: 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
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.
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.
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.
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 10.0.0.1 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.
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.
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).
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 10.4.3.4. 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 192.168.0.1
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:
Setup TMG IPsec with a supported configuration
Modify TMG network rule and access rule
Make sure the TMG server has hotfix KB2523881 installed
Change the TMG network card MTU to 1350
Disable RPC strict compliance and restart TMG firewall service
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.
Remote VPN gateway IP address: enter the Azure Virtual Network gateway provided earlier
Local VPN gateway IP address: enter the TMG external IP address
Use pre-shared key for authentication: Enter Shared Key provided earlier
Remote address ranges: Leave the Azure IP address and enter the Azure network range created earlier for example 10.4.0.0 to 10.4.255.255
Network rule: Create a route relationship and add other networks if required
Access rule: Create an access rule and select ‘All outbound traffic’
Address ranges: Leave the external interface and add the internal network ranges that need to communicate over the VPN
Create the VPN and edit
Under Connection / IPsec Settings ensure the following is set:
Encryption algorithm: AES128
Integrity algorithm: SHA1
Diffie-Hellman group: Group 2 (1024 bit)
Authenticate and generate a new key: 28800 seconds
Encryption algorithm: AES128
Integrity algorithm: SHA1
Session key / Generate a new key every: Both enabled
Use Perfect Forward Secrecy (PFS): Not selected
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.
Modify the Network rule under Networking / Network Rules and add ‘Internal’ to the source network and ‘Azure’ to the destination network
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.
Open an administrative command prompt
Run to show interfaces
netsh interface ipv4 show interface
Set external interface MTU
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:
Right click the Access rule, select ‘Configure RPC protocol’ and uncheck ‘Enforce strict RPC compliance’
Edit the System policy ‘Firewall Policy / All Tasks / System Policy / Edit System Policy / Authentication Services / Active Directory’ and uncheck ‘Enforce strict RPC compliance’
Apply the TMG configuration and wait for it to sync
Important:The next step will disconnect all TMG sessions including VPN, RDP, ActiveSync, OWA etc. so should be performed out of hours
Restart the ‘Microsoft Forefront TMG Firewall service
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.