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 isa way! Using the below PowerShell line, the OU is displayed:
When starting a pilot for Hybrid Azure AD join, it can be useful to keep track of the number of devices that currently are already Hybrid Azure AD joined.
The most straight-forward way to do so is within the GUI of the Azure AD portal:
However, when used for reporting or other reasons, a scripted solution often is a better fit. The below PowerShell snippet returns all devices that are:
Known in Azure AD
Joined in a local domain
Running Windows 10
A requirement to run this script is being connected to Azure AD by using Connect-AzureAD for instance.
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
}else
{
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"
Recently, I got a question from a customer to list all users that already enrolled in Azure MFA (through, for example, the url https://aka.ms/mfasetup.
The following PowerShell code lists all non-disabled users that already enrolled in Azure MFA:
When configuring this on my home tenant, I received the following error:
All usual suspects were covered: the correct licenses were assigned, password writeback was configured and showed up in the portal as working, so no issues there. When opening the SSPR section in the Azure Portal, the following error was shown:
Digging into the Event Viewer on the Azure AD Connect Server revealed the error: The password could not be updated because the management agent credentials were denied access.
Following best practices from Microsoft, the account that was configured in the Azure AD Connect management agent did not have elevated permissions, and therefore did not have the possiblity to reset passwords.
Assigning delegated permissions to reset the password of the OU containing the synced users, solved the issue.
