Office 365: Directory synchronization and object attributes…
For many Office 365 customers directory synchronization is the primary method of populating their Office 365 tenant with users, groups, and contacts. The directory synchronization process allows for the centralized management of these objects.
In the service customers taking advantage of Exchange Online through Office 365 actually have two directory representations. Objects managed with directory synchronization are replicated to the Azure Active Directory. This directory serves as the centralized repository for Office 365 objects. The directory synchronization process is responsible for mapping on premises Active Directory attributes to the Azure Active Directory. Each object within the on premises active directory has a wide array of attributes that are configurable on the object. The directory synchronization service is configured to map these attributes to attributes within the Azure Active Directory.
Attributes of objects within the on premises Active Directory are generally managed by either Active Directory Users and Computers or the Exchange Management tools. In some special circumstances tools like ADSIEdit can be utilized to process attribute changes. When an object is changed within the directory administrators can view the synchronization of those changes through the MIISClient on the Directory Synchronization server.
In this example I have changed an object on premises by adding City.
In the MIISConsole we can see the object change detected and subsequently the attribute updated in the Azure Active Directory. The original CITY attribute was NULL and has now been populated with the value “Charlotte”.
Using the Azure Active Directory module we can see the results of this change with get-MSOLUser.
PS C:\> Get-MsolUser -UserPrincipalName DevUser@domain.com | fl userprincipalname,city
UserPrincipalName : DevUser@domain.com
City : Charlotte
The list of attributes that are synchronized from On-Premises to the Azure Active Directory is documented at this location:
https://support.microsoft.com/kb/2256198
The second directory representation for the object is present within the Exchange Online directory. When an object has been assigned an Exchange license, a service provisioning process is responsible for extending this object into the Exchange Online directory and subsequently providing a mailbox. This provisioning process is also responsible to monitor for changes and ensure those changes are reflected within the Exchange Online object. For example, if you look at the mailbox associated with our test user you will now see that city has been populated with a value of “Charlotte” where previously it was NULL.
PS C:\> Get-Recipient -Identity DevUser@domain.com | fl name,city
Name : Dev User
City : Charlotte
The attributes that are replicated from the Azure Active Directory to the Exchange Online directory are not necessarily the same as those replicated from the On-Premises Active Directory to the Azure Active Directory. Currently there is no list of attributes that replicate between Azure Active Directory and Exchange Online.
In most instances no issues arise from this difference in directory synchronization. There are though some circumstances where this can cause an issue. Let us explore an example.
An administrator has decided that on-premises an address list would exist that displays all recipient objects where the Company attribute is populated with a given value. The address list allows for you to specify that any recipient that contains company=X will be included in the address list. This effectively allows the administrator to set company on users, distribution groups, and contacts and have them appear in the same address list.
The directory synchronization metaverse, by default, does not sync the company attribute on objects of type group. Notice in the below example that company is not included.
Using the add attribute button Company is added as an attribute that is synchronized for groups.
By default company is not an attribute of a group when edited via Active Directory Users and computers or through the Exchange Management Tools.
To achieve this result the administrator uses the attribute editor of Active Directory Users and Computers (or ADSIEdit) to set the company attribute on the distribution group.
When reviewing the directory synchronization logs we can observe the object is replicated with the attribute company populated.
After waiting a period of time it was noted that the same address list in Exchange Online did not contain the group objects. This would be considered by design – Company is not an expected attribute of a distribution group. Although the Azure Active Directory did in this case allow for the attribute to be successfully synchronized from on premises the Exchange Online provisioning process is not configured to detect this attribute and replicate it to Exchange online.
In this case the administrator needed to switch to an attribute that is replicated, for example custom attribute 1. There should be no expectation that attributes that are not default on an object on-premises will be replicated into Exchange Online although they may be replicated to the Azure Active Directory.
Comments
- Anonymous
January 01, 2003
@TurboMCP...
Gotta keep you coming back...
TIMMCMIC - Anonymous
February 02, 2015
Thanks
the joy of "the cloud"
3 posts in one day
ill have to skip work:)