Scripting Azure VM build tasks: static IP addresses, BGInfo and anti-malware extensions

Following on from yesterday’s blog post with a pile of PowerShell to build a multiple-NIC VM in Azure, here are some more snippets of PowerShell to carry out a few build-related activities.

Setting a static IP address on a NIC

$RGName = Read-Host "Resource Group"
$VNICName = Read-Host "vNIC Name"
$VNIC=Get-AzureRmNetworkInterface -Name $VNICName -ResourceGroupName $RGName
$VNIC.IpConfigurations[0].PrivateIpAllocationMethod = "Static"
Set-AzureRmNetworkInterface -NetworkInterface $VNIC

Installing BGInfo

$RGName = Read-Host "Resource Group"
$VMName = Read-Host "Virtual Machine Name"
$Location = Read-Host "Region/Location"
Set-AzureRmVMExtension -ExtensionName BGInfo -Publisher Microsoft.Compute -Version 2.1 -ExtensionType BGInfo -Location $Location -ResourceGroupName $RGName -VMName $VMName

Installing Microsoft Antimalware

This one is a little more difficult – the script is a development of Mitesh Chauhan’s work entitled Installing Microsoft Anti Virus Extension to Azure Resource Manager VM using Set-AzureRmVMExtension

It’s worth reading Mitesh’s post for more background on the Microsoft Anti Virus Extension (IaaS Antimalware) and also taking a look at the Security Health in the Azure Portal (currently in preview), which will highlight VMs that have no protection (amongst other things).

Mitesh’s script uses a simple settings string, or for more complex configuration, it reads from a file. I tried to use a more complex setting and it just resulted in PowerShell errors, suggesting this wasn’t proper JSON (it isn’t):

$AntiMalwareSettings = @{
"AntimalwareEnabled" = $true;
"RealtimeProtectionEnabled" = $true;
"ScheduledScanSettings" = @{
"isEnabled" = $true;
"day" = 1;
"time" = 180;
"scanType" = "Full"
"Exclusions" = @{
"Extensions" = ".mdf;.ldf;.ndf;.bak;.trn;";
"Paths" = "D:\\Logs;E:\\Databases;C:\\Program Files\\Microsoft SQL Server\\MSSQL\\FTDATA";
"Processes" = "SQLServr.exe;ReportingServicesService.exe;MSMDSrv.exe"

Set-AzureRmVMExtension : Error reading JObject from JsonReader. Current JsonReader item is not an object: Null. Path”, line 1, position 4.

If I use the JSON form it’s no better:

$AntiMalwareSettings = {
"AntimalwareEnabled": true,
"RealtimeProtectionEnabled": true,
"ScheduledScanSettings": {
"isEnabled": true,
"day": 1,
"time": 180,
"scanType": "Full"
"Exclusions": {
"Extensions": ".mdf;.ldf;.ndf;.bak;.trn",
"Paths": "D:\\Logs;E:\\Databases;C:\\Program Files\\Microsoft SQL Server\\MSSQL\\FTDATA",
"Processes": "SQLServr.exe;ReportingServicesService.exe;MSMDSrv.exe"

Set-AzureRmVMExtension : Unexpected character encountered while parsing value: S. Path ”, line 0, position 0.

So the actual script I used is below:

# Install Microsoft AntiMalware client on an ARM based Azure VM
# Check note at the end to be able to open up the SCEP antimalware console on the server if there are problems.
# Author – Mitesh Chauhan – (updated by Mark Wilson -
# For Powershell 1.0.1 and above
# See

# Log in with credentials for subscription
# Login-AzureRmAccount

# Select your subscription if required (or default will be used)
# Select-AzureRmSubscription -SubscriptionId "Your Sub ID here"

$RGName = Read-Host "Resource Group"
$VMName = Read-Host "Virtual Machine Name"
$Location = Read-Host "Region/Location"

# Use this (-SettingString) for simple setup
# $AntiMalwareSettings = ‘{ "AntimalwareEnabled": true,"RealtimeProtectionEnabled": true}’;

# Use this (-SettingString) to configure from JSON file
$AntiMalwareSettings = Get-Content ‘.\MSAVConfig.json’ -Raw

$allVersions= (Get-AzureRmVMExtensionImage -Location $location -PublisherName "Microsoft.Azure.Security" -Type "IaaSAntimalware").Version
$typeHandlerVer = $allVersions[($allVersions.count)–1]
$typeHandlerVerMjandMn = $typeHandlerVer.split(".")
$typeHandlerVerMjandMn = $typeHandlerVerMjandMn[0] + "." + $typeHandlerVerMjandMn[1]

Write-Host "Installing Microsoft AntiMalware version" $typeHandlerVerMjandMn "to" $vmName "in" $RGName "("$location ")"
Write-Host "Configuration:"

# Specify for -SettingString parameter here which option you want, simple $settingsstring or $MSAVConfigfile to sue json file.
Set-AzureRmVMExtension -ResourceGroupName $RGName -VMName $vmName -Name "IaaSAntimalware" -Publisher "Microsoft.Azure.Security" -ExtensionType "IaaSAntimalware" -TypeHandlerVersion $typeHandlerVerMjandMn -SettingString $AntiMalwareSettings -Location $location

# To remove the AntiMalware extension
# Remove-AzureRmVMExtension -ResourceGroupName $resourceGroupName -VMName $vmName -Name "IaaSAntimalware"

# If you have error saying Admin has restricted this app, Navigate to “C:\Program Files\Microsoft Security Client”
# Run "C:\Program Files\Microsoft Security Client\ConfigSecurityPolicy.exe cleanuppolicy.xml"
# Or simply drag the cleanuppolicy.xml file above onto the ConfigSecurityPolicy.exe to sort it and you should be in.

The MSAVconfig.json file contains the JSON version of the Anti-Malware settings:

"AntimalwareEnabled": true,
"RealtimeProtectionEnabled": true,
"ScheduledScanSettings": {
"isEnabled": true,
"day": 1,
"time": 180,
"scanType": "Full"
"Exclusions": {
"Extensions": ".mdf;.ldf;.ndf;.bak;.trn",
"Paths": "D:\\Logs;E:\\Databases;C:\\Program Files\\Microsoft SQL Server\\MSSQL\\FTDATA",
"Processes": "SQLServr.exe;ReportingServicesService.exe;MSMDSrv.exe"

Building a multiple NIC VM in Azure

I recently found myself in the situation where I wanted to build a virtual machine in Microsoft Azure (Resource Manager) with multiple network interface cards (vNICs). This isn’t available from the portal, but it is possible from the command line.

My colleague Leo D’Arcy pointed me to Samir Farhat’s blog post on how to create a multiple NIC Azure virtual machine (ARM). Samir has posted his script on the TechNet Gallery but I made a few tweaks in my version:

$VMName = Read-Host "Virtual Machine Name"
$RGName = Read-Host "Resource Group where to deploy the VM"
$Region = Read-Host "Region/Location"
$SAName = Read-Host "Storage Account Name"
$VMSize = Read-Host "Virtual Machine Size"
$AvailabilitySet = Read-Host "Availability Set ID (use Get-AzureRMAvailabilitySet to find this)"
$VNETName = Read-Host "Virtual Network Name"
$Subnet01Name = Read-Host "Subnet 01 Name"
$Subnet02Name = Read-Host "Subnet 02 Name"
$cred=Get-Credential -Message "Name and password for the local Administrator account"
# Getting the Network
$VNET = Get-AzureRMvirtualNetwork | where {$_.Name -eq $VNETName}
$SUBNET01 = Get-AzureRmVirtualNetworkSubnetConfig -Name $Subnet01Name -VirtualNetwork $VNET
$SUBNET02 = Get-AzureRmVirtualNetworkSubnetConfig -Name $Subnet02Name -VirtualNetwork $VNET
# Create the NICs
$NIC01Name = $VMName+'-NIC-01'
$NIC02Name = $VMName+'-NIC-02'
Write-Host "Creating" $NIC01Name
$VNIC01 = New-AzureRmNetworkInterface -Name $NIC01Name -ResourceGroupName $RGName -Location $Region -SubnetId $SUBNET01.Id
Write-Host "Creating" $NIC02Name
$VNIC02 = New-AzureRmNetworkInterface -Name $NIC02Name -ResourceGroupName $RGName -Location $Region -SubnetId $SUBNET02.Id
# Create the VM config
Write-Host "Creating the VM Configuration"
$VM = New-AzureRmVMConfig -VMName $VMName -VMSize $VMSize -AvailabilitySetId $AvailabilitySet
Write-Host " - Setting the operating system"
$VM = Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate
Write-Host " - Setting the source image"
$VM = Set-AzureRmVMSourceImage -VM $vm -PublisherName $pubName -Offer $offerName -Skus $skuName -Version "latest"
#Adding the VNICs to the config, you should always choose a Primary NIC
Write-Host " - Adding vNIC 1"
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $VNIC01.Id -Primary
Write-Host " - Adding vNIC 2"
$VM = Add-AzureRmVMNetworkInterface -VM $VM -Id $VNIC02.Id
# Specify the OS disk name and create the VM
Write-Host " - Getting the storage account details"
$SA = Get-AzureRmStorageAccount | where { $_.StorageAccountName -eq $SAName}
$OSDiskUri = $SA.PrimaryEndpoints.Blob.ToString() + "vhds/" + $vmName+"-OSDisk.vhd"
Write-Host " - Setting up the OS disk"
$VM = Set-AzureRmVMOSDisk -VM $VM -Name $DiskName -VhdUri $osDiskUri -CreateOption fromImage
Write-Host "Creating the virtual machine"
New-AzureRmVM -ResourceGroupName $RGName -Location $Region -VM $VM

Upgraded Azure support for Enterprise Agreement customers

I recently found myself in a situation where I tried to log a support request on my customer’s Microsoft Azure subscription, only to find that they didn’t have any eligible support agreements in place.

You'll need to buy a support plan before you can submit a technical support request

That seemed strange, as from 1 May 2016, Microsoft is offering a 12-month support upgrade to all customers that have or intend to buy Microsoft Azure services on an Enterprise Agreement (EA), except those customers with a Premier support contract.

Digging a little deeper, I found that:

“Microsoft will begin upgrade for existing Azure customers on Enterprise Agreement on May 1, 2016, and plans to complete the upgrades by September 30, 2016. New customers will be upgraded within 30 days of account activation. Customers will be notified by email upon being upgraded. For more information, please talk with your account manager or contact EA Azure Support through the Enterprise Portal”

But, the Enterprise Agreement Support Offer page that contains this information is subtitled: “to activate, contact your Microsoft account team”, so I contacted my customer’s account team.  Initially, they said that the customer needed to contact their Microsoft Licensing Solution Provider (LSP), who were equally confused, but I pushed a little harder and the account team investigated further, before arranging the necessary support.

So, if you’re an EA customer and you can’t wait until September to get an upgrade to your Azure support agreements, it may just be worth a chat with your Microsoft account team.

Short takes: deleting Bitlinks; backing up and restoring Sticky Notes; accessing cmdlets after installing Azure PowerShell

Another collection of short notes to add to my digital memory…

Deleting links

Every now and again, I spot some spam links in my Twitter feed – usually prefixed [delicious]. That suggests to me that there is an issue in Delicious or in Twitterfeed (the increasingly unreliable service I use to read certain RSS feeds and tweet on my behalf) and, despite password resets (passwords are so insecure) it still happens.

A few days ago I spotted some of these spam links still in my links (the link shortener behind my links, who also own Twitterfeed) and I wanted to permanently remove them.

Unfortunately, according to the “how do I delete a Bitlink” knowledge base article – you can’t.

Where does Windows store Sticky Notes?

Last Friday (the 13th) I wrote about saving my work before my PC was rebuilt

One thing I forgot about was the plethora of Sticky Notes on my desktop so, today, I was searching for advice on where to find them (in my backup) so I could restore.

It turns out that Sticky Notes are stored in user profiles, under %appdata%\Microsoft\Sticky Notes, in a file called StickyNotes.snt. Be aware though, that the folder is not created until the Sticky Notes application has been run at least once. Restoring my old notes was as easy as:

  1. Run the Sticky Notes desktop application in Windows.
  2. Close Sticky Notes.
  3. Overwrite the StickyNotes.snt file with a previous copy.
  4. Re-open Sticky Notes.

Azure PowerShell installation requires a restart (or explicit loading of modules)

This week has involved a fair amount of restoring tools/settings to a rebuilt PC (did I mention that mine died in a heap last Friday? If only the hardware and software were supplied by the same vendor – oh they are!). After installing the Azure PowerShell package from the SCCM Software Center, I found that cmdlets returned errors like:

Get-AzureRmResource : The term ‘Get-AzureRmResource’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

After some RTFMing, I found this:

This can be corrected by restarting the machine or importing the cmdlets from C:\Program Files\WindowsPowerShell\Modules\Azure\XXXX\ as following (where XXXX is the version of PowerShell installed[)]: import-module "C:\Program Files\WindowsPowerShell\Modules\Azure\XXXX\azure.psd1" import-module "C:\Program Files\WindowsPowerShell\Modules\Azure\XXXX\expressroute\expressroute.psd1"

Reset the password for a Windows virtual machine in Azure

Imagine the scenario: you have a virtual machine running in Azure but something’s gone wrong and you don’t have Administrative credentials to log in to Windows. That’s a more common occurrence than you might expect but there is a workaround: in Azure there an option to reset the local administrator password.

Unfortunately, that capability hasn’t been implemented yet in the management portal for Azure Resource Manager but it is available in Microsoft Azure PowerShell.

Reset Password - Coming Soon

I found the following commands worked for me (based on a blog post by Dan Patrick), resetting the built-in administrator account for the defined server in the defined Resource Group to be called DisabledAdmin (after which it won’t be disabled any more but after unlocking the server and creating an alternative administrator, the built in account can be disabled again) with a GUID for the password:

$rgName = "Example-Resource-Group"
$vmName = "SERVERxxx"
$extName = "VMAccessAgent"
$userName = "DisabledAdmin"
$password = [guid]::newguid()
$location = "westeurope"
Set-AzureRmVMAccessExtension -ResourceGroupName $rgName -VMName $vmName -Name $extName -UserName $userName -Password $password -Location $location

(of course, you’ll need to take a note of that GUID if you want to log in to the account!).

The VM Access Extension can be called anything you like (the MSDN reference for Set-AzureRmVMAccessExtension gives more information); however, as noted in the Microsoft Azure documentation (How to reset the Remote Desktop service or its login password in a Windows VM):

“You can reset remote access to your VM by using either Set-AzureRmVMExtension or Set-AzureRmVMAccessExtension

“Both commands add a new named VM access agent to the virtual machine. At any point, a VM can have only a single VM access agent. To set the VM access agent properties successfully, remove the access agent set previously by using either Remove-AzureRmVMAccessExtension or Remove-AzureRmVMExtension. Starting from Azure PowerShell version 1.2.2, you can avoid this step when using Set-AzureRmVMExtension with a -ForceRerun option. When using -ForceRerun, make sure to use the same name for the VM access agent as set by the previous command.”

So, by using a known name for the VM Access Extension (VMAccessAgent), I can avoid potential issues later.

Extending Azure network security with a Barracuda NextGeneration F-Series firewall

I’ve been working on a project to move a customer’s IT infrastructure and application services to the cloud – in this case Microsoft Azure and Office 365.

Azure allows the creation of sophisticated virtual networks with multiple virtual networks, subnets, load balancers, network security groups (NSGs), VPN connections over the public Internet or using a dedicated MPLS link. It also operates with high levels of security (more details in the Microsoft Trust Center).

My customer is a public sector organization and had some specific security requirements that needed a greater level of monitoring of traffic between subnets than we could provide with Network Security Groups alone – essentially the ability to perform logging and to provide application-level awareness. The customer’s security team were keen that it should be possible to identify malicious activity and we confirmed that NSGs have minimal monitoring without any deep packet inspection.

So, in this case, we needed to turn to a network virtual appliance (NVA) solution. The Azure Marketplace has a variety of NVAs, including products from major player like Checkpoint, Cisco, Fortinet, F5 networks, Sophos, etc. The one we selected though (partly from technical requirements, and partly based on advice from Microsoft) was the Barracuda NextGeneration F-Series firewall.

I’m no network architect, but from my position in the world of Microsoft technology, just needing a network solution that could provide the flexibility, reliability and security that my customer needed, the Barracuda solution looks pretty outstanding. We’ve got an advanced firewall with Intrusion Detection System, VPN concentrator and proxy server – all in a single appliance running in Azure under a bring your own licence arrangement.

There’s a great video from Microsoft Channel 9 and Barracuda, talking about the NextGeneration F-Series firewalls, including some of the capabilities available if we put another device on-premises for VPN failback, etc. Well worth a look if you’re considering implementing an IaaS (or indeed PaaS) solution on Azure.

Short takes: ADFS certificate expiry; Azure Authenticator setup on Windows Phone; checking if a MSOL tenant name exists

Some more snippets of randomness pulled together to make a blog post…

ADFS certificate expiry

One of my colleagues spotted this in a customer’s Office 365 tenant recently:

Office 365 - Renew your certificates

Thankfully, it wasn’t one we were managing… but I did feel the need to flag it to the incumbent service provider. If this happens to you, my colleague Gavin Morrison (@GavinMorrison) flagged a potentially useful blog post from Jack Stromberg about renewing ADFS Certificates.

Azure Authenticator Setup on Windows Phone

Whilst setting up additional authentication for Office 365 (in effect, Azure AD MFA) I found that I couldn’t add an account until the Windows Phone Azure Authentication app had enabled push notifications. Despite repeatedly enabling it in Settings, completing setup of the account needed a phone reboot, at which point it was ready for me to scan a QR code and continue.  Even then the option to allow notifications doesn’t seem to stick!

Checking if a Microsoft Online Services tenant name exists

My colleague Gareth Larter found a neat trick this week for checking if a Microsoft Online Services (MSOL) tenant exists (e.g. for Office 365).

Gareth’s advice is to browse to and, if you get an error, it should show “No service namespace named ‘’ was found in the data store” at the bottom right meaning that the tenant name is available:

On the other hand, if you get a bunch of XML data returned, then that tenant already exists.

Why Microsoft customers don’t need to worry about EU-US Safe Harbour/Harbor

When European Courts judged the 15-year-old EU-US Safe Harbour/Harbor treaty to be invalid last October, Internet news sites started to report how terrible this was for EU companies placing data into cloud services offered (mostly) by American companies. For some, that may be true, but that assumes Safe Harbour is the only protection in place.

This week, IT news sites are at it again. The Register (the tabloid newspaper of IT news sites) has an article titled Safe Harbor 2.0: US-Europe talks on privacy go down to the wire but the actual URI belies a much more dramatic title of “Safe Harbor countdown to Armageddon”. Sensationalist at best, some might even say irresponsible.

I’m no lawyer but, for my customers, who are implementing Microsoft cloud services, there seems to be nothing to worry about and I’ll explain why in this blog post. Of course, Microsoft is just one of many cloud services providers – and for others there may be valid concerns.

The United States Export.Gov website currently displays the following text regarding Safe Harbor:

“On October 6, 2015, the European Court of Justice issued a judgment declaring as ‘invalid’ the European Commission’s Decision 2000/520/EC of 26 July 2000 ‘on the adequacy of the protection provided by the safe harbour privacy principles and related frequently asked questions issued by the US Department of Commerce.’

In the current rapidly changing environment, the Department of Commerce will continue to administer the Safe Harbor program, including processing submissions for self-certification to the Safe Harbor Framework. If you have questions, please contact the European Commission, the appropriate European national data protection authority, or legal counsel.”

EU Model Clauses trump Safe Harbour

Microsoft President and Chief Legal Officer, Brad Smith, issued a statement on 6 October 2015. Quoting from that article:

“For Microsoft’s enterprise cloud customers, we believe the clear answer is that yes they can continue to transfer data by relying on additional steps and legal safeguards we have put in place. This includes additional and stringent privacy protections and Microsoft’s compliance with the EU Model Clauses, which enable customers to move data between the EU and other places – including the United States – even in the absence of the Safe Harbor. Both the ruling and comments by the European Commission recognized these types of steps earlier today.

Microsoft’s cloud services including Azure Core Services, Office 365, Dynamics CRM Online and Microsoft Intune all comply with the EU Model Clauses and hence are covered in this way.”

There’s also a follow-on post which talks in general terms about the wider issues and privacy beliefs but the key point is that Microsoft offers EU Model Clauses within its contracts, which go beyond Safe Harbour. Microsoft also has an FAQ on the EU Model Clauses that is worth a read.

Quoting again from the 6 October 2015 statement:

“We wanted to make sure all of our enterprise cloud customers receive this benefit so, beginning last year, we included compliance with the EU Model Clauses as a standard part of the contracts for our major enterprise cloud services with every customer. Microsoft cloud customers don’t need to do anything else to be covered in this way.”

That suggests to me that customers who have signed up to Azure Core Services, Office 365, Dynamics CRM Online or Intune since early 2014 already have greater privacy protection than was afforded by Safe Harbour – and that protection meets the EU’s current requirements. In short, Microsoft customers don’t need to worry about Safe Harbor (sic).

Windows 10 Enterprise domain join options

When running Windows 10 setup from enterprise media, one of the options presented is to choose how you’ll connect Windows to your organisation.

  • Join Azure AD
  • Join a domain

You might ask, “where’s the option to just continue as normal and stay in a workgroup?” (as a non-domain-joined PC) but the explanatory text helps:

  • Join Azure AD if your organisation uses Office 365 or other business services from Microsoft.
  • If you plan to join the PC to a domain, a local account is created and then you can join a domain as in previous Windows OSes once setup is complete.

The “join a domain” option doesn’t actually join a domain at all – indeed, once you’ve elected to join a domain you can switch to signing in with a Microsoft account (and gain the benefits of settings being synchronised between PCs) as well as adding a workplace or school account (signing in to Office 365, for example), changing sign-in options, joining/leaving a domain and/or joining/leaving Azure AD (for administrators to manage the PC in line with policy).

Windows 10 - Accounts - Your Accounts

Windows 10 - Accounts - Signin Options

Windows 10 - Accounts - Work Access

Overview of Azure AD synchronisation

Over the last few months, I’ve had the opportunity to work with a number of directories that are synchronised from on-premises Active Directory (AD) to Azure AD (AAD) – the directory service behind Office 365, Azure, Dynamics, Intune and other business-focused Microsoft online services.

I’ve learned a few things along the way (like that AAD synchronisation servers are disposable and shouldn’t be re-configured to sync with a different directory, as well as some steps for troubleshooting missing objects) but I thought I’d group a few more points together in this post.

DirSync -> AAD Sync -> AAD Connect

There have been various versions of what’s essentially the same tool (a customised implementation of Microsoft Identity Manager, previously known as Forefront Identity Manager and Microsoft Identity Integration Server – indeed the Synchronisation Manager is still named miisclient.exe) and Paul Wooldridge does a great job of summarising the current situation in his blog post for risual.

These days, there are very few reasons not to be using the latest version – Azure AD Connect – which massively simplifies the process of configuring the underlying Azure AD Synchronisation Services as well as including a number of optional preview features for new functionality. The one caveat is that it needs Windows Server 2012 or later.

Hardware, software and service accounts

Whilst there’s no reason a physical machine couldn’t be used, all of the Azure AD synchronisation servers I’ve worked on have been virtual.  The machine will require the following specification:

  • Windows Server 2008 or later (standalone or domain joined).
  • Microsoft .Net framework version 4.5.1.
  • PowerShell (v3 or later).
  • Local administrator privileges to install the software.
  • Unauthenticated Internet access (over port 443) to the Office 365 servers.
  • A regular user account to connect to AD and read the attributes for objects to be synchronised. This must be able to log on as a service and it will also need to be granted the following permissions in order to write back password hashes (for same sign on):
    • Replicating Directory Changes.
    • Replicating Directory Changes All.

Older versions of the tool allowed the administrator to define an account in the cloud whereas AAD Connect asks for credentials and creates its own service account (with a display name of On-Premises Directory Synchronization Service Account and an user name of Also, unlike previous versions the account is set with a password that will not expire (the PasswordNeverExpires and PasswordResetNotRequiredDuringActivate attributes are both set to $true).

Tools and commands

Azure AD Connect is based on the Azure AD Synchronization Services framework which itself is evolved from Microsoft Identity Manager (formerly Forefront Identity Manager, Microsoft Identity Lifecycle Manager, Microsoft Identity Integration Server, Microsoft Metadirectory Server and Zoomit Via before that!). Not surprisingly, the underlying tools are the same ones used for these products!

  • The main tool is the Synchronization Service Manager (miisclient.exe), which is used to monitor synchronisation as well as to adjust the scope of synchronisation (more on that in a moment)
  • There’s also a Rules Editor (which I leave alone – indeed, directly editing the rules is not supported for AAD Connect)
  • A scheduled task is also created that runs the synchronisation process every 3 hours by default (you may want to reduce the timeout on this to avoid issues with long-running syncs too).
  • It’s possible to force a synchronisation from the command line. This can also be done from the Synchronization Service Manager or from Task Scheduler but the command line is easy! Simply run directorysyncclientcmd.exe delta (from an PowerShell session running as Administrator) or directorysyncclientcmd.exe initial to force a full synchronisation.

As for Powershell cmdlets, the documentation on the ADSync PowerShell module is pretty poor. I managed to extract a list of commands and their syntax but there’s no meaningful help text (at least not that I’ve found). I’ve also seen that the DirSync information on the synced attributes is better than the AAD Sync information (which warns it will be archived soon) and I haven’t found the equivalent AAD Connect information!

What gets synchronised?

For many organisations, not all of the directory needs to be synchronised. It’s possible to filter synchronisation by domain, organizational unit (OU), group membership, or directory attribute. Of these, group membership is generally only used in test (it quickly becomes tiresome to add users to a group to ensure that they are synced to the cloud) and OU filtering is the most common form I’ve seen. It’s also worth noting that the group membership option is new with Azure AD Connect and previous versions of the tool didn’t allow this.

Also note that, if the scope of synchronisation is changed, a full synchronisation is required as a delta will not pick up the new filtering arrangements.

Further reading