Azure AD Connect Group WriteBack

Groups writeback enables customers to leverage cloud groups for their hybrid needs. If you use the Microsoft 365 Groups feature, then you can have these groups represented in your on-premises Active Directory. This option is only available if you have Exchange present in your on-premises Active Directory.

It takes your M365 Cloud groups and recreates them on-premises, in a configurable target OU.

Enabling or disabling this feature is fairly easy, and is wonderfully explained here. However, when migrating towards another server or version of AAD Connect, finding out in what OU the groups are / have to be stored is not that transparent.

Fortunately, there is a way! Using the below PowerShell line, the OU is displayed:

Get-ADSyncGlobalSettings |Select -ExpandProperty Parameters |Where {$_.Name -eq "Microsoft.GroupWriteBack.Container"}

If Group WriteBack is not enabled, the results of the above command will be empty. When it is enabled, it will show the OU in the value attribute:

Run AAD Connect Sync & Monitor Status

Depending on the size of an AD environment (and more specifically, the number and location of objects that are in scope to be synced), a delta sync can take anywhere between a couple of seconds and significantly longer.

Checking if a sync currently is running is possible using a couple of methods. When sticking to PowerShell, the following commands can be utilized:

Start-AdSyncSyncCycle: running this command interactively when a sync is running will result in an “in your face” error message similar to the following:

Get-AdSyncScheduler: this command outputs the configuration settings of the sync process and also includes the state, wether or not it is running:

While all of the above are usable, they are not that user friendly, and require a user to retry the command in order to know *when* sync has been completed.

The below PowerShell code (let’s not call it a script, shall we?) does the following things:

  • Checks if a sync process currently is running
  • If not, starts a delta sync
  • Notifies the user / admin when the delta sync is finished
# verify if ADSync module is loaded, and if not, load it.
$module = Get-Module "ADsync"
if ($module -eq $null)
Import-Module AdSync
    Write-Host "ADSync Module already loaded"

# verify if a sync is currently running. If not, start a delta sync
$sync = Get-AdSyncScheduler

if ($sync.SyncCycleInProgress -eq $False)
Start-AdSyncSyncCycle -Policytype "Delta" |Out-Null

# periodically test if sync is running until it's... not running anymore
do {
    Write-Host "Azure AD Connect Sync Cycle in Progress..." -ForegroundColor "Yellow"
    $sync = Get-AdSyncScheduler
} until ($sync.SyncCycleInProgress -eq $False)

Write-Host "Azure AD Connect Sync Cycle is finished." -ForegroundColor "Green"

Selecting the right Subscription in PowerShell

When your organization has multiple Azure Subscriptions and you are entitled to work with them, selecting the correct subscription becomes an important thing to do.

Different approaches exist. I will have a look at the two most straight forward ones.

Using an argument to Connect-AzAccount

Connect-AzAccount holds specific attributes than can help you, namely SubscriptionName or SubscriptionId. If you know the Subscription name you want to connect to, issuing the following command directly connects to the correct subscription, after which you can start scripting:

Connect-AzAccount -SubscriptionName "Microsoft Partner Network"

To check to which subscription is linked, the command Get-AzContext can be issued.

Switching to another subscription in an active session

Switching to another Azure Subscription in an active session is also possible. This can be achieved by issuing the following command:

Set-AzContext -Subscription <subscription name> or <subscription id>

Useful PowerShell references



Almost one year ago, the new Az Powershell module was released. The major change compared to the “older” AzureRM module is the fact that it is built on the .NET standard libraries, making it cross-platform compatible.
In addition, the nomenclature has been adjusted. AzureRM has been shorted to “Az”. No major updates or new features will be developed for the AzureRM module.

If you are late to the game, now is the time to start adjusting your scripts. December 2020 is announced as the date also bugs and security fixes won’t be published anymore, rendering the module not suitable for production anymore.

It is not recommended to run the AzureRM module and the Az module side-by-side. However, while you are re-authoring your scripts, luckily Microsoft offers you a “co-existence” method without requiring conflicting modules.. By issuing the commandlet Enable-AzureRMAlias , aliases will be created.

After using Enable-AzureRMAlias, the number of usable commands increases significantly:

If you want to enable the legacy commandlets for the localmachine, the “-Scope” parameter will help you out:

Useful PowerShell references