In a previous blog, I showed how ADSync can be monitored, in this entry we will look at some of the methods to resolve or lessen the amount of bad data requests that are sent to by ADSync to the CPSM API.

Limit the amount of bad attempts for a request

By default if a request fails for any reason, the ADSync client will attempt to resend the request until it succeeds. This can cause a spam like effect to the API.

In ADsync v11 and above, there is an option of setting the maximum amount of retries that the ADSync client will send the change. If the amount is reached it will disregard the change and will wait for the next change on the user to send a sync.

Sign onto a DC with ADSync.
Go to the ADSync install directory (default C:\Program Files\AD Sync)
Open ADSync.exe.config in Notepad
Search for UploadMaxErrors
Change value from 0 (unlimited) to 3
Save the file.
Repeat for all servers that have the ADSync client installed.

Within the ADSync logs or event viewer, it will display the following error message if a user sync attempt exceeded the maximum amount of errors.
DefaultSource   Error      2              Failed to upload user ‘syncuser’: The user will not be updated as the maximum number of retries (3) has been exceeded   2014-08-12 23:51:31Z

Common errors

These are common errors that can been seen in the ADSync log. The logs are located in the \logs directory of ADSync and can be zipped for easier transport if you log a support case.
All servers  with the ADsync client installed should be checked, as their logs are independent of each other.

Password complexity

A requirement of the ADSync client is that the customers AD password policy is the same or more complex than the CPSM AD. This is to ensure that a user’s password stays in sync and will not have validation issues.

Example:

DefaultSource   Error      2              Failed to upload user ‘syncuser’ because Failed to update user ‘syncuser’: The minimum password length is 7 characters                2014-08-12 23:51:26Z

Solution:

To resolve the single user update the user in the customer AD with a complex password, for a complete solution provide the customer with your requirements and get them to their password complexity requirements.

User stuck in pending state

Sometimes a user can get stuck in the pending state (orange) due to the previous provisioning request not completing due to the restarting of the provisioning server or some other reason causing it not to fail but not complete.

Example:

Processing object ‘syncuser’ in current state ????????? with status of InProgress

Solution:

It is common to see this message in the logs, however if a user is sitting with in for 5-10 minutes and other user requests are going through they could be in a stuck state.

To resolve, open the CPSM UI, go to the customer, find the user.
The user should have a orange status symbol next to them, if so expand the user.
Click on Reset Status
Accept the prompt
This will set the status to unknown (blue), and ADSync will then attempt to resend the request and change the status to green (unless the retry limit has been reached)

Domain does not belong to the customer

When syncing email addresses or syncing by userPrincipalName, the customer needs to have the domain registered against them in CPSM.

Example:

Failed to upload user ‘syncuser’ because Failed to update user ‘syncuser’: User eMail domain ‘test.loca’ does not belong to a customer

Solution:

You can remove the email address from the user in the customers AD or add the domain the customer in CPSM.

Conclusion

Hopefully this will give you some guidance on solving some of the more common ADSync issues.