Troubleshooting synchronization with Windows Azure Active Directory (WAAD) (Part 3)

If you would like to read the other parts in this article series please go to:


In the first two articles of this series, we have seen how to install the built-in tools to troubleshoot filtering and synchronization. At this point in the game we have all the basic requirements to perform troubleshooting of the synchronization process.

Using filtering in Office365 to find out bad UPN on-premises

In some situations we may end-up having some accounts being synchronized and the username will show up in WAAD (Windows Azure Active Directory) with the default domain name (Figure 01). In our case this is [email protected].

Figure 01

If you have few users then it’s a piece of cake to identify the problematic ones, however, how do we manage to find problems when we have several hundreds of users? There are a couple of ways, the simplest is using the filter feature on the Office365 console. Logged on Office365, click the users and groups item, and then click the filter icon, and finally New View (Figure 02).

Figure 02

On the new filter wizard, define a name and select the domain, in our case the domain will be, click save and after that the filter is ready to be used. (Figure 03)

Figure 03

Now on the main page, click the filter icon again and select the filter that we have just created from the list. Here we have all accounts that we need to do some work on your on-premises Active Directory (Figure 04).

Figure 04

So, what is the solution for accounts that show up with the default domain name in Office365? Usually the UPN for the account is not correct in Active Directory (Figure 05), just change it to the right UPN (in my case and wait for the next replication cycle to check the results.

Figure 05

Troubleshooting some synchronization issues…

The first step is to be aware that we have an error. We can look at the Application area of the Event Viewer and we will have some warnings when a new error occurs. The errors/warnings will have the FIMSynchronizationService as source and their Event IDs can be 0 or 6100, however it is always good to check all warnings.

My preferred method is using the Synchronization Service Manager (miisclient), where we can track the error down to its first appearance on our environment based on past runs.

The scenario that we are going to test here will help you fix some common issues, however the most important thing is to show you how to get the information to start troubleshooting.

Bear in mind that an error message can be applied to several different errors and at the end our analysis, validation, comparison with existent objects and finally testing will be the key to fix the issue.

Issue #01 – AttributeValueMustBeUnique (simple)

Every time that we click an item in the Operations area we will have more details at the bottom of the screen in two frames (Figure 06). They are really helpful because they provide statistics and detailed information of any selected operation listed above.

Figure 06

In the example above we have the Export operation completed with some errors based on the Status column. If we click on that specific operation, we will have at the bottom right side two columns: Export Errors and Error(s) we can start looking around to find the issue. The first column will scare you away because it is the Distinguished Name, however let’s observe the error in the second column AttributeValueMustBeUnique. It seems to be the case where we have an attribute that is being shared among two or more objects.

Click on the AttributeValueMustBeUnique (Figure 07), and in the initial window we have some information such as the first time that it occurred, how many times and so forth. Click Detail… and we will have another window with the error information (the window on the right side of the same Figure 07) and we can see clearly which SMTP address is the culprit for the issue.

Figure 07

Now that we have some evidence of the issue and a suspect, we can start researching our Active Directory. The first step is to search the SMTP address info provided by the tool (Figure 08) and the result shows up two objects, jackpot!

Figure 08

Open both objects and try to find the inconsistency. In the scenario below (true story!), the Security Groups had their owner information added to the description and e-mail filed in Active Directory. In this case, the simple solution is to remove the E-mail information from the group, after all it is not even a mail-enabled object and wait or run synchronization.

Figure 09

Issue #02 – IdentityDataValidationFailed

We have an error like the one shown in Figure 10. Unfortunately, this error message does not pin point the account with the issue on the detailed information, however we know that is related to the attribute [username] and that is a good start.

Figure 10

Remember, that we have two columns at the bottom where the first one is more towards the object and the second one is about the error. We already checked the second column in Figure 10 above, and now it’s time to check the link in the first column. On the Export in Progress tab we will find information about the object that is responsible for the error (Figure 11).

Figure 11

Hercule Poirot will be pleased of our power of observation. Our job is to go to the account in Active Directory Users and Computers and check the username attribute (Figure 12). The issue is that there is a space in the username, correct that and in the next synchronization cycle that error message is gone.

Figure 12

Issue #03: AttributeValueMustBeUnique (more advanced)

In the first issue of this article we found out that the e-mail field in Active Directory was messed up with some Groups and in this new issue we get the same error message (Figure 13). However, this one will have a different outcome and we will need to go a little bit deeper to find the issue. Based on the error message the e-mail [email protected] is duplicated somewhere in our Active Directory.

Figure 13

We perform a search in Active Directory Users and Computers and the result is a single entry (Figure 14). Interesting… the problem is that the issue lies in the multi-valued field proxyaddresses and that field is not used for this type of search.

Figure 14

A good way to find who is using the same Active Directory Users and Computers is the find feature, however let’s click Custom Search at the top, and then type in the LDAP query replacing the e-mail address in Figure 15 for the SMTP provided in the error message.

At this time we will get two entries which means that we narrowed down the issue to just two accounts instead of the entire Active Directory.

Figure 15

The best way to fix the issue is comparing the two entries. We can do that by placing both Active Directory users’ properties side by side and click the Attribute Editor tab and we will edit the value for proxyAddresses. Now that we have the visual of both objects it is easy to pin point the issue: the user arg05 somehow has an additional SMTP address that is the same of the user arg04.

Based on the name of the users it is clear that arg05 should not have such entry there, so our task is just to remove it, wait for the on-premises Active Directory replication to take place and in the next replication the issue will be resolved.

Figure 16

Issue #04: When my user was synchronized with the WAAD?

That is not even an issue but sometimes I get this question from customers. They want to know if the user that was just created was part of the last synchronization cycle.

Depending of the size of your Active Directory and your patience to seek through the entries, you can always go to the Export task listed in the Operations area, and on the left side below we will have the statistics. If there is a number then there is a link to retrieve more information, click on it.

The first window will be the DistinguishedName which does not help at all in this scenario, however double click on it and since that is a new user it is expected that the column Old Value will be empty but in the New Value column we will have the info of the user that was just synchronized to WAAD.

If the last user created was arg07, then for sure he was synchronized to Windows Azure Active Directory.

Figure 17

What is the synchronization frequency? Can I change it?

By default is every 3 hours and in order to change it, we need to open the file called Microsoft.Online.DirSync.Scheduler.exe.Config located in the C:\Program Files\Windows Azure Active Directory Sync and change the value for the key SyncTimeInterval (Figure 18).

Figure 18

The last step is to restart the service called Windows Azure Active Directory Sync Service to apply the new settings (Figure 19).

Figure 19


In this final article of our series about troubleshooting between on-premises Active Directory and Windows Azure Active Directory we validated some scenarios and troubleshooting steps to fix issues.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top