Directory synchronization preparation
Applies to: Office 365 Deployment Guide for Enterprises
Topic Last Modified: 2013-04-08
Provisioning users with directory synchronization requires more planning and preparation than simply managing your organizational accounts directly in Office 365. The additional planning and preparation tasks are required to ensure that your on-premises directory syncs properly to the Windows Azure AD. The added benefits to your organization include the following:
-
Reducing the administrative programs in your organization
-
Enabling single sign-on scenarios
-
Automating account changes
For more information about the advantages of using directory synchronization, see Directory synchronization roadmap.
Before you install and begin the sync of your directory, you need to clean up your directory. We will outline the specific areas in your directory that need to be cleaned up.
Warning: |
|---|
| If Active Directory cleanup isn’t performed before the deployment process, there can be a significant negative effect on the directory synchronization and deployment process. It could take days, or even weeks, to iterate through the cycle of directory syncing, identifying syncing errors, and re-syncing. |
In your organization’s on-premises Active Directory forest, do the following clean-up tasks:
-
Ensure each user who will be assigned Office 365 service offerings has a valid and unique email address in the proxyAddresses attribute. Remove any duplicate values in the proxyAddresses attribute and the userPrincipalName attribute that exists in your forest.
-
Populate the following user attributes:
- givenName
- sn (surname)
- displayName
- givenName
-
For optimal use of the GAL, be sure the information in the following attributes is correct:
-
Job Title
-
Department
-
Office
-
Office Phone
-
Mobile Phone
-
Fax Number
-
Street Address
-
City
-
State or Province
-
Zip or Postal Code
-
Country or Region
-
Job Title
Successful directory synchronization between your on-premises Active Directory environment directory and Office 365 requires that your on-premises directory objects and attributes are properly prepared. For example, you need to ensure that specific characters aren’t used in certain Active Directory objects and aren’t used in attributes that are synchronized with the Office 365 environment. These objects and attributes include:
- userPrincipalName
-
The userPrincipalName attribute must be in the Internet-style logon format where the user name is followed by the symbol @ and a domain name; for example, user@contoso.com.
-
Maximum number of characters for the user name that is in front of the at sign (@): 64
-
Maximum number of characters for the domain name following the at sign (@): 256
-
Invalid characters: ! # $ % & \ * + - / = ? ^ _` { | } ~ < > ( )`
-
The @ character is required in each userPrincipalName value.
-
The @ character cannot be the first character in each userPrincipalName value.
-
The user name cannot end with a period (.), an ampersand (&), a space, or an at sign (@).
-
The user name cannot have any spaces.
-
Routable domains must be used; for example, local or internal cannot be used.
-
Unicode is converted to underscore characters.
- userPrincipalName cannot contain any duplicate values in the forest.
-
The userPrincipalName attribute must be in the Internet-style logon format where the user name is followed by the symbol @ and a domain name; for example, user@contoso.com.
- sAMAccountName
-
Maximum number of characters: 20
-
Invalid Active Directory characters: !#\$%\^&\{\}\\{`~"",\\/\[\]:@<>\+=;\?\*
-
If a user has an invalid sAMAccountName attribute but has a valid userPrincipalName attribute, the user account is created in Office 365.
-
If both sAMAccountName and userPrincipalName are invalid, the on-premises Active Directory userPrincipalName attribute must be updated.
-
Maximum number of characters: 20
- proxyAddresses
-
Multi-value attribute
-
Maximum number of characters: 256
-
Invalid characters: \)\(;><\]\[\\,
Important: All Simple Mail Transport Protocol (SMTP) addresses should comply with email messaging standards. If duplicate or unwanted addresses exist, see the Help topic Removing duplicate and unwanted proxy addresses in Exchange.
-
Multi-value attribute
- givenName & sn (surname)
-
Maximum number of characters: 64
-
Unexpected characters: ?@\+
-
Maximum number of characters: 64
- displayName
-
Maximum number of characters: 256
-
Unexpected characters: ?@\+
-
Maximum number of characters: 256
- mailNickname (Exchange alias)
-
Maximum number of characters: 64
-
Invalid characters: ""\\\[\]:><; a space
-
Maximum number of characters: 64
- mail
-
Maximum number of characters: 256
-
Invalid characters: [! #$ %&*+ / = ? ^ ` { }]
-
Duplicate values: The mail attribute cannot contain any duplicate values.
-
Maximum number of characters: 256
It’s required that the targetAddress attribute (for example, SMTP:tom@contoso.com) that’s populated for the user must appear in the Exchange Online GAL. In third-party messaging migration scenarios, this would require the Exchange schema extension for the on-premises directory. The Exchange schema extension would also add other useful attributes to manage Office 365 objects that are populated by using the Directory Synchronization tool from on-premises. For example, the msExchHideFromAddressLists attribute to manage hidden mailboxes or distribution groups would be added. For more information, see Third-party mail migration to Office 365 – fixes and tips..
Active Directory Domain Services are designed to allow the end users in your organization to sign in to your directory by using either sAMAccountName or userPrincipalName. Similarly, end users can sign in to Office 365 applications by using the user principal name (UPN) of their Office 365 user ID. Directory synchronization attempts to create new users in Windows Azure AD by using the same UPN that’s in your on-premises directory. The UPN is formatted like an email address. In Office 365, the UPN is the default attribute that’s used to generate the email address. It’s easy to get userPrincipalName (on-premise and in Windows Azure AD) and the primary email address in proxyAddresses set to different values. When they are set to different values, there can be confusion for administrators and end users.
It’s best to align these attributes to reduce confusion. To meet the requirements of single sign-on with AD FS 2.0, you need to ensure that the UPNs in Windows Azure AD and your on-premises Active Directory match and are using a valid domain namespace.
You may need to add an alternative UPN suffix to associate the user’s corporate credentials with the Office 365 environment. A UPN suffix is the part of a UPN to the right of the @ character. UPNs that are used for single sign-on can contain letters, numbers, periods, dashes, and underscores, but no other types of characters.
For more information on how to add an alternative UPN suffix to Active Directory Domain Services, see Prepare for directory synchronization
If you’ve not yet set up Active Directory synchronization, you can skip this task and go to the next section.
If you’ve already set up Active Directory synchronization, the user’s UPN for Office 365 may not match the user’s on-premises UPN that’s defined in your on-premises directory service. This can occur when a user was assigned a license before the domain was verified. To remedy this issue, use Windows PowerShell to update a user’s UPN to ensure that their Office 365 UPN matches their corporate user name and domain. If you are updating the UPN in the on-premises directory service and would like it to sync with the Windows Azure AD identity, you need to remove the user’s license in Office 365 prior to making the changes on-premises.
After you’ve completed Active Directory clean-up, you can go ahead with the steps to install and configure the Windows Azure Active Directory Sync Tool. For information on the installation and configuration, see Configure directory synchronization.

Warning: