AAD Connect: Custom AAD Attributes & Scheduler PowerShell

Following on from the posts from my esteemed colleagues: Lucian and Josh, I thought I’d post my experiences working with the latest version (v1.1.110.0) specifically two areas:

1. Working with the AAD Connect Scheduler, that is now based in Powershell and whose configuration is now stored in AAD, using the ‘Set-ADSyncScheduler’ commands
2. Working with ‘extension Attributes’ using Directory Extensions feature of AAD Connect

Both of these features are new to the latest version of AAD Connect.

Working with new AAD Connect Scheduler (PowerShell ‘Set’ and ‘Get’ commands)

The official Microsoft link to working with the ‘Set-ADSyncScheduler’ command can be found here.  I thought I’d expand my workings with this utility as a few of the commands cannot be set (even though they’re exposed using the ‘Get-ADSyncScheduler’ command).

Previous versions of AAD Connect used the in-built Windows Server Task Scheduler to execute the AAD Connect EXE which triggered the Synchronization Service to run on its (previously default) schedule of 3 hours.  For example, to disable the schedule previously, it was generally accepted to ‘disable’ the Task Scheduler job itself.

With the move to PowerShell (and the storage of the AAD Connect schedule in Azure AD), the commands to disable or enable the schedule are now PowerShell commands.

To verify the settings of the AAD Connect Scheduler, type:

Get-ADSyncScheduler

The above picture tells us:

1. The AAD Connect server is in ‘Staging mode’ and will not export into the local AD or cloud AAD directories
2. The ‘SyncCycleEnabled’ value is ‘False’ meaning the Synchronization Service is effectively disabled unless you run a manual sync process (and you can find those instructions in Lucian‘s post)
3. The server will cycle every 30 minutes (which is the default value), and that value has not been overwritten by a ‘customized’ sync cycle (the ‘customized’ value is blank which means an administrator has not run the command at all).

If the ‘SyncCycleEnabled’ value is set to ‘False’, this tells us that the scheduler will not run unless you initiate a manual AAD Connect ‘delta’ or ‘initial’ cycle yourself

• To enable the schedule, type:

Set-ADSyncScheduler -SyncCycleEnabled $True

• To disable the schedule, type:

Set-ADSyncScheduler -SyncCycleEnabled $False

Another parameter settings that can be modified with ‘Set-ADSyncScheduler’ is:

• Change the next automated sync cycle to be a ‘Delta’ cycle:

Set-ADSyncScheduler -NextSyncCyclePolicyType Delta

• Change the next automated sync cycle to be a ‘Full Import’ (referred to as ‘Initial’) cycle:

The start time setting which I was trying to customize for a customer (i.e.’NextSyncCycleStartTimeInUTC’) does not seem to be possible to be modified (at least in this version):

Since the default schedule is 30 minutes (down from 3 hours), this isn’t as critical a setting so at this stage you’ll have to advise your customers or management that the start time cannot be modified.  My customer previously had the 3 hour cycle starting ‘on the hour’ to line up with other identity management processes which executed at specific times during the day.

You are also prevented from moving the Server out of or into Staging Mode (ie. ‘StagingModeEnabled’ from ‘True’ to ‘False’ or reverse):

Like previous versions, you will need to run the AAD Connect wizard to modify this setting:

If you try to set a time that’s quicker than ‘every 30 minutes’ using the command:

Set-ADSyncScheduler -CustomizedSyncCycleInterval 00:25:00

It will list it as a ‘customized’ value, but it will not change the ‘effective’ time ie. it will not run at every 25 minutes and the ‘allowed’ value will not change from 30 minutes.

Working with ‘extensionAttributes’ using Directory Extensions’ feature of AAD Connect

The article which explains the AAD Connect ‘Directory Extensions’ feature can be found here.

This feature provides the ability to specify custom attributes (sometimes called ‘extended’ attributes) that a customer (or app) has modified into the schema of their local Active Directory.

In this example, a customer requested to copy 3 custom attributes and 1 ‘extensionAttribute’ into Azure AD (which is part of the default AD Schema) so they could be accessed by the Graph API:

NOTE: For privacy and security reasons, for the picture above, I’ve hidden the company name from the start of two of the attributes.

However, according to Microsoft representatives who I am working with, currently the limitation is:

• Extension attributes 1-15 are not exposed in the Graph API as yet.

So we should expect to see the local AD extensionAttribute3 exposed to the Graph API as:

‘extension_AppClientID_extensionAttribute3’

The others would be named:

‘extension_AppClientID_division’

‘extension_AppClientID_OrgUnitCode’

‘extension_AppClientID_Status’