Best Practices for Deploying and Managing the Windows Azure Active Directory Sync Tool

Best Practices for Deploying and Managing the Windows Azure Active Directory Sync Tool

The objective of this article is to provide you with a list of best practices for deploying and managing the Windows Azure Active Directory Sync Tool.

 



Password Sync from Windows 2003 Domain Controller may result in errors with Description like "Recovery Task Failed."

 

Certain customers with Windows 2003 Domain Controllers running DirSync versions lower than 6411.0000 have reported an error with EventId=611 and Description like the following:

Password synchronization failed for domain: <domain name here>. Details:

Microsoft.Online.PasswordSynchronization.SynchronizationManagerException: Recovery task failed. ---> Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: RPC Error 8439 : The distinguished name specified for this replication operation is invalid. There was an error calling _IDL_DRSGetNCChanges.

We have investigated and resolved this issue.  We have resolved this issue in latest version of the DirSync client (version 6411.0009).  Please download and install this new DirSync version.

↑ Back to top

 


Directory Sync tool Hybrid Deployment may not writeback all attributes

 

The latest version of the DirSync client (version 6385.0027) has a known issue where the PublicDelegates attribute is not written back from Azure Active Directory to your on-premises Active Directory when you have enabled Hybrid Deployment mode.  The DirSync and Exchange Online teams are investigating this issue and will provide an update/resolution as soon as possible.

NOTE: If you are upgrading to this version from a previous version of DirSync, we recommend waiting until an update is released to minimize the work required to mitigate and resolve this issue.

↑ Back to top

 


Set of Supported Operating Systems for Directory Sync tool has been updated

The set of Supported OSes that the Directory Sync tool (DirSync) can be installed on has been updated for version 1.0.6385.0012 (released 5/31/2013).

The Directory Sync tool must be installed on one of the following Server OSes:

  • Windows Server 2008 SP1 or higher*
  • Windows Server 2008 R2 SP1 or higher
  • Windows Server 2012 or higher

 

 Important
The Directory Sync tool is supported on Windows Server 2008 SP1 and higher. However, the Password Sync feature will not function correctly if the Directory Sync tool is installed on an OS older than Windows Server 2008 R2 SP1 (Windows Server 2008 R2 SP1 itself is supported). See the Best Practice entry below for more information on this.
Product documentation (http://technet.microsoft.com/en-us/library/jj151831.aspx) will be updated shortly to reflect this.

 

↑ Back to top

 


Password Sync: Operating System Requirements For Password Synchronization

The Password Sync feature of the Directory Sync tool will not work correctly if Directory Sync tool is deployed on an OS older than Windows Server 2008 R2 SP1.

The exception text that indicates this is a problem is as follows:

Password synchronization failed for domain: <your domain here>.
Details:

System.IO.FileLoadException: A procedure imported by 'Microsoft.Online.PasswordSynchronization.Cryptography.dll' could not be loaded.

To resolve this issue, install the Directory Sync tool on a supported Windows Server OS.

 

↑ Back to top

 


Password Sync: Activate Synced Users feature may cause synced password to be lost

Administrators that use the Activate Synced Users feature in the administrative portals (Office 365, Azure) may notice that user passwords are reset as part of the licensing process.  This is a known issue and the fix is being released shortly.

Instead of using the Activate Synced Users feature, administrators should simply assign a license to the user (click on the user, then select the License tab) rather than using the Activate Synced Users feature.

To resolve this issue, have the user change their password in the on-premises environment to synchronize their password to the cloud again.  Or have the user change their cloud password to match their on-premise password.  The next time the user changes their on-prem password, it will be synched to the cloud.
 

↑ Back to top

 


Object deletions in Azure AD during a Full Sync may not be automatically recovered

This behavior applies to Directory Sync tool version 1.0.6385.0012 and higher.

If a Global Administrator uses the Remove-MsolUser/Remove-MsolGroup/Remove-MsolContact commandlet to manually delete an object in Azure Active Directory while their DirSync appliance is running a full sync, that object may not be automatically recovered/re-provisioned during the next sync run. 

This is expected behavior.

To have DirSync recover the object, simply "touch" (update an innocuous attribute) in your on-premises Active Directory and this will recover/re-provision your object on the next sync cycle.

↑ Back to top

 


Administrators may notice a High Volume of events with ID=6941 during Sync Runs

With Directory Sync tool version 1.0.6385.0012 and higher, administrators may notice a large volume of Error-level entries in the event log during Sync runs. These entries have the following details:  

  • Source=FIMSynchronizationService
  • Event ID=6941

The Description generally starts with "ECMA2 MA export run caused an error."

This is expected behavior.

Prior to this version of the Directory Sync tool, these events were suppressed by the tool. The new version of the synchronization engine now logs this information to the event log. This is the same set of information that is sent to the Technical Notification Contact via email.

 

↑ Back to top


Installation of the Directory Sync tool using SQL Server on a different machine may fail if the SQL Native Client is not installed

The installation of the Windows Azure Active Directory Sync tool on a different server using SQL Server may fail if the SQL Native Client is not installed.

The typical error message is:
"Forefront Identity Manager Synchronization Service -- Forefront Identity Manager Synchronization Service requires a running instance of Microsoft SQL Server 2008 SP1 or better.
Install the correct SQL Server version and make sure the service is running before installing Forefront Identity Manager Synchronization Service."

This happens because the SQL Native Client is required for the Directory Sync tool to be successfully installed.
To resolve this issue, install the Microsoft SQL Server Native Client component (available as part of the Microsoft SQL Server 2008 R2 Feature Pack) and attempt to install the Directory Sync tool again.

 

↑ Back to top

 


Installation of the Directory Sync tool may fail on a machine with the Sign-In Assistant already installed

Installation of the Windows Azure Active Directory Sync tool may fail if the Microsoft Online Services Sign-In Assistant component is already installed.
Typical error messages include:
You receive a message during directory synchronization installation: “The Microsoft Online Services Sign-in Assistant service installation returned FAIL. See the event logs for more detailed information”.
Event log entries indicating an error during installation of the Sign-In Assistant: “The Microsoft Online Services Sign-in Assistant service installation returned error code 1603”
“Microsoft Online Services Sign-in Assistant -- Error 1316. A network error occurred while attempting to read from the file: C:\Program Files\Microsoft Online Directory Sync\msoidcli_64.msi”.

To resolve this issue, install the Microsoft Online Service Directory Sync tool on a machine that does not already have the Microsoft Online Services Sign-In Assistant installed on it.

↑ Back to top

 


You cannot modify an existing installation of the Directory Sync tool to sync to a different Azure Active Directory tenant

When you sign up for Azure Active Directory, you are provisioned a tenant.
This tenant is a container that holds all the information for you.

When you configure the Directory Sync tool and specify the global administrator account (via the Configuration Wizard, or Windows PowerShell cmdlets), the Directory Sync tool is configured to connect to that tenant.
Subsequently, the tool synchronizes on-premises information into your respective tenant in Azure Active Directory.

If you have signed up for other tenants within the Azure Active Directory service, you cannot run the Configuration Wizard again and specify the global administrator account for a different Azure Active Directory tenant.
Instead, you must deploy a new instance of the Directory Sync tool, specifying the global administrator account for the second tenant.

↑ Back to top

 


Active Directory Objects with more than 400 values in a multi-valued attribute will not sync

When using Active Directory synchronization with Azure Active Directory, any object that has more than 1,000 attributes in a multi-valued attribute will fail to sync, and the customer will see an error indicating the object has exceeded the allowed attributes in a multi-valued attribute. Typically this issue arises with the proxyAddresses attribute, though the same would apply for any other multi-valued attribute; for example, otherTelephone. To fix this error, remove some of the values of the object in your on-premises Active Directory. You cannot remove these extra values in the Azure Active Directory directory.

↑ Back to top

 


Configuration Wizard F1 key doesn't work at first on Windows Server 2008

When you run the Windows Azure Active Directory Sync tool Configuration Wizard for the first time on a Windows Server 2008 machine, you will get an error ("Run As - not supported") if you click the F1 shortcut key on any wizard page.

To use the F1 keys to access Help, log off of the machine and then log back on, at which point the F1 shortcut key for Help should work properly.
To access the Configuration Wizard Help topics directly, see Active Directory synchronization: Roadmap, Microsoft Online Services Credentials, or Active Directory Credentials.

↑ Back to top

 


Modifying a user’s Active Directory group membership may impact Exchange hybrid deployment functionality

If your company has enabled Exchange hybrid deployment as part of the Active Directory synchronization configuration, users that are added to some Active Directory security groups before their Exchange hybrid deployment configuration is successfully written back to their on-premises Active Directory will not have access to those features until the procedure documented below is executed.

The affected security groups are:

  • Schema Admins
  • Enterprise Admins
  • Cert Publishers
  • Domain Admins
  • Account Operators
  • Print Operators
  • Administrators (domain local)
  • Server Operators
  • Backup Operators

To resolve this issue, you should use the dsacls tool to reprovision the MSOL_AD_Sync_RichCoexistence account permissions to the AdminSDHolder object in your local Active Directory forest.

To modify the AdminSDHolder container, do the following:

1. Download and install the Windows Server 2003 Service Pack 1 (SP1) Support Tools.Dsacls.exe is available as part of the Windows Support Tools. For more information, see article 89277 in the Microsoft Knowledge Base.

2. Run the following commands:

  • dsacls CN=AdminSDHolder,CN=System,DC=<mydomain>,DC=com /G
  • MSOL_AD_SYNC_RICHCOEXISTENCE:WP;"MSExchArchiveStatus"
  • dsacls CN=AdminSDHolder,CN=System,DC=<mydomain>,DC=com /G
  • MSOL_AD_SYNC_RICHCOEXISTENCE:WP;" MSExchBlockedSendersHash"
  • dsacls CN=AdminSDHolder,CN=System,DC=<mydomain>,DC=com /G
  • MSOL_AD_SYNC_RICHCOEXISTENCE:WP;" MSExchSafeRecipientsHash"
  • dsacls CN=AdminSDHolder,CN=System,DC=<mydomain>,DC=com /G
  • MSOL_AD_SYNC_RICHCOEXISTENCE:WP;" MSExchSafeSendersHash"
  • dsacls CN=AdminSDHolder,CN=System,DC=<mydomain>,DC=com /G
  • MSOL_AD_SYNC_RICHCOEXISTENCE:WP;" MSExchUCVoiceMailSettings"
  • dsacls CN=AdminSDHolder,CN=System,DC=<mydomain>,DC=com /G
  • MSOL_AD_SYNC_RICHCOEXISTENCE:WP;" ProxyAddresses"

↑ Back to top

 


Objects deleted after initial full synchronization may count towards customer's directory synchronization object limit

Objects that were once present in the customer's on-premise Active Directory and synchronized to Azure Active Directory via Active Directory synchronization, and then deleted, may still contribute towards your Azure Active Directory object limit for a period of up to 30 days.

If the sum of these deleted objects and the remaining active objects is greater than your object limit, you may continue to receive notifications informing you that you have exceeded your object limit even though the object no longer appears in the on-premise Active Directory or in the Azure Active Directory directory.

For help with this issue, contact Azure Active Directory Support.

↑ Back to top

 


Directory Synchronization and Azure Active Directory object limits

All customers of Azure Active Directory and Office 365 have a default object limit of 50,000 objects (users, mail-enabled contacts, and groups) by default.  This limit determines how many objects you can create in your tenant.  Objects can be created using DirSync, Powershell or the GRAPH API.  Wwhen you verify your first domain, this object limit is automatically increased to 300,000 objects.  Each tenant is only granted one increase.

If you have verified a domain and need to synchronize more than 300,000 objects OR you do not have any domains to verify, and need to synchronize more than 50,000 objects, you will need to contact Azure Active Directory Support to request an increase to your object quota limit.

↑ Back to top


Leave a Comment
  • Please add 2 and 3 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Sort by: Published Date | Most Recent | Most Useful
Comments
  • Jono Luk (MSFT) edited Revision 29. Comment: Note about Windows 2003 DC issue ("Recovery Task Failed.")

Page 1 of 1 (1 items)
Wikis - Comment List
Sort by: Published Date | Most Recent | Most Useful
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
Comments
  • Revision: edited tags

  • Jono Luk (MSFT) edited Revision 29. Comment: Note about Windows 2003 DC issue ("Recovery Task Failed.")

  • Hi there - Brilliant article. I wanted to know if we can look at updating onlinehelp.microsoft.com/.../jj159544.aspx which seems to imply that only SQL 2008 R2 can be used to host WAAD DirSync database. Secondly, the SQL Native Client requirements- If we can explicitly mention what versions are supported.    

Page 1 of 1 (3 items)