Synchronizing Custom AD Attributes to Office 365 - Part 2

This blog is the 2nd in a 3 part series on synchronizing and working with custom AD attributes in Office 365. In this post we continue with showing you how to retrieve attributes in Office 365 using PowerShell.

• Part 1 is here: Step 1 - Configure AD Connect to Synchronize Custom Attributes.

PowerShell can be used to both verify that your custom attributes have actually been synchronized to Office 365, and it can be used to actually accomplish things with those attributes, like having them sync'ed to your user profile in SharePoint Online (but that's for another article).

Step 2 - Retrieve Attributes in Office 365 Using PowerShell

Once we have custom attributes synchronizing to Office 365 using AD Connect, we would naturally want to use to verify that the attributes have successfully sync'ed.  As well, we would naturally use PowerShell to do this. However, there are some important concepts that we first need to understand to do this.

1. To access user accounts in Azure AD within Office 365, we typically use the Windows Azure Active Directory Module for Windows PowerShell.

• Follow the instructions here to Install this Azure Active Directory PowerShell module.  
• When running the PowerShell module, always right mouse click and select Run As Administrator.
• The Azure AD cmdlets you would use to retrieve a user's attributes are;

connect-msolservice (provide your global administrator credentials when prompted)

get-msoluser -userprincipalname <a user's UPN> | select *

• This will return a pre-defined set of 59 attributes for the user, however it will NOT return all of the attributes associated with the user account.  For example, it will NOT return any of the extension attributes.  You can see a list of the attributes that are retrieved here: get-msoluser.

2. To retrieve additional attributes or the extension attributes associated with the user's Azure AD account, you must use the Exchange Online PowerShell module.

• To use Exchange Online cmdlets for a user account, that user account MUST have an Exchange Online mailbox, which means they MUST be licensed for Exchange Online.  If a user is not licensed for Exchange Online, the sync process still synchronizes the attributes correctly for that user.  However, the limitation here is that you will not be able to call the Exchange Online cmdlets for that user - you can still call get-msoluser as described above to get that subset of attributes.
• To connect to the Exchange Online PowerShell module, you can use the following:

$sUserName = Read-Host "Enter an administrator username" 

$sPassword = Read-Host "Enter an administrator password" -AsSecureString

$credential = New-Object System.Management.Automation.PsCredential($sUserName,$sPassword)

$exchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "https://outlook.office365.com/powershell-liveid/" -Credential $credential -Authentication "Basic" –AllowRedirection

Import-PSSession $exchangeSession

• In order to retrieve additional attributes about a user, and more specifically retrieve the extension attributes, you can call either get-mailbox or get-recipient as follows.  

get-mailbox <a user's email address> | select *

get-recipient <a user's email address> | select *

You can use either one of these cmdlets, and you can get more information about these here: get-mailbox and get-recipient.

• With either of these cmdlets you'll notice that you get a lot more attributes returned.  In particular you get customAttribute1, customAttribute2 ...customAttribute15.  These map directly to the following attributes in your on premise AD environment: extensionAttribute1, extensionAttribute2 ...extensionAttribute15.  Their purpose is to provide some built in attributes with which clients can use custom attributes in on premise AD without editing the actual AD schema.

• As you can see, the name of an attribute in Azure AD is often slightly different from the corresponding name of the attribute in on premise AD.

3. When testing retrieval of extension attributes for a user, ensure that you're calling the cmdlets for a user account that has actually values in those extension attributes in your on premise AD.  I know it sounds simple, but many times I've seen people say 'my attributes are not sync'ing' only to find out that the user they're testing didn't actually have values in those attributes in AD.

4. You'll notice that with any of the preceding PowerShell cmdlets shown, the custom AD attributes you've configured AD Connect to synchronize are not shown.  We can see the built-in extension attributes, but not any custom attributes.  

• Unfortunately, there currently is no Office 365 workload that will consume or work with these attributes.  Not even the PowerShell cmdlets currently available will access or retrieve these custom attributes.
• It is however possible to work with the Microsoft Graph API to retrieve these custom attribute values.  Microsoft has published a Quick Start Guide for the Graph API if you wish to use that.
• The custom attribute from your on premise AD is actually published to Azure AD with a name that looks like the following:

extension_<application GUID>_<custom attribute name>

You can see the custom attribute name that is being synchronized to Office 365 for your custom attributes if you use the MIISCLIENT application (available at C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe on the AD Connect server) to watch the synchronization process and review the actual updates made.  Remember, do not try to execute the sync or modify any sync settings through the MIISCLIENT application.  Only use the AD Connect configuration wizard for any sync configuration.

Part 3 in this series can be found here: Step 3 - Customize AD Connect Synchronization Rules.