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

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


Since the release of the series of the Troubleshooting synchronization with Windows Azure Active Directory (WAAD), I have received a couple of messages from readers about the series and I decided to add one more article to this series to cover more advanced filtering scenarios.

Filtering using the UPN…

As part of the process to synchronize with Windows Azure Active Directory (WAAD), a valid UPN that matches the domain that is configured in Azure/Office365 must be configured on-premises as well. The reason behind that requirement is that Microsoft Azure services requires the username using UPN format ([email protected] for example) although there is a way around using alternate login IDs, the UPN change is the most commonly deployed nowadays.

Using alternate login IDs allows the administrator to use a different attributes however it requires more manual steps to change the synchronization process on the Synchronization Services Managers clients and also on the ADFS (in case single sign-on is in use), and more validation when using different cloud services.

For this article, we are using a single domain called apatricio.local and for test purposes, our domain created in Windows Azure Active Directory is The first step before enabling synchronization is to create the UPN using Active Directory Domain and Trusts as shown in the Figure 01.

Figure 01

After doing that we can select the UPN for any given user using Active Directory Users and Computers or Exchange Admin Center (ECP). In our article, we are going to start with 3 (three) accounts: user01, user02 and user03 however, only user01 has the UPN assigned, all remaining accounts are using @apatricio.local, as shown in Figure 02. The cmdlet used in the example is listed below.

Get-Mailbox –OrganizationalUnit ‘domain.local/OU’ | ft Name,UserPrincipalName,PrimarySMTPAddress -AutoSize

We are synchronizing just one Organization Unit (we went over this process in the second article of this series) and the Organization Unit for this article is called Corporate Users.

Figure 02

In order to avoid synchronization errors with all accounts that are defined as @apatricio.local we can create a filter to remove such accounts from the synchronization process. That gives the administrator a lot of flexibility when implementing the synchronization with Windows Azure Active Directory, the administrator could enable OU filter (in this case just the accounts that belong to the Corporate Users Organization Unit) and on top of that only the accounts that are configured with UPN will be synchronized. By doing that we can resolve a good chunk of synchronization errors that show up when those filters are not in place.

In order to enable this filter, we need to open the miisclient, which can be found in the Windows Azure Active Directory folder. In the new Synchronization Service Manager (FIM 2010), click on Management Agents, and right-click on Active Directory Connector (which is the connector related to the on-premises environment) and click on Properties, as shown in Figure 03.

Figure 03

In the Properties page. Click on Configure Connector Filter and on the right side, select user. All existent filters that came with the Directory Synchronization tool are listed (Figure 04) in this section. By looking at the existent filters, we will start realizing why the SystemMailbox, Support and other standard accounts never show up in the Windows Azure Active Directory. Click on New.

Figure 04

In the Filter for user page, select userPrincipalName from Data source attribute and then select contains and type in the UPN of the internal domain (in our case apatriciolocal). To complete the process click on Add condition and click OK (Figure 05).

Figure 05

The administrator can wait for the replication or force based on the second article of this series using the Start-OnlineCoexistenceSync cmdlet. Either way the results will be the same, all accounts synchronized with the Windows Azure Active Directory are shown in Figure 06. Only the accounts that do not contain apatricio.local on their UPN were synchronized.

Figure 06

How about my service and any other special group of accounts?

Some environments have all their service accounts (for this exercise we will use service accounts but you can apply the same logic for any group of accounts) in a separate Organization Unit. If the environment is configured that way, then it is just matter of removing such OU(s) from the filtering like the example shown in the second article of this series. However, some companies have service accounts all over the place and in that scenario we can take advantage of similar filtering techniques to remove those accounts from the synchronization process.

The best approach is to identify a common attribute or pattern among all the group of accounts that you want to filter from the replication. A good way to start your research is enabling the Advanced Features in Active Directory Users and Computers and then checking the Attribute Editor tab of your accounts

If the company has a standard, for instance, all service accounts start with svc then it is much easier to match the pattern in a filter. In the example below, the administrator identified that the attribute sAMAccountName always started with svc. (Figure 07)

Figure 07

In order to remove the service accounts from the synchronization on this current scenario, we just need to add one more filter and use the attribute name that was identified in the previous step, and the string (in this case starts with and svc. in the value field), as shown in Figure 08.

Figure 08

The result of that addition is a new rule right underneath the previous creation to filter the invalid UPN (Figure 09).

Figure 09

We can perform a simple test by creating a service account and making sure that it has (we want to avoid having that account being filtered by the userPrincipalName instead of the sAMAccountname attribute) and then synchronize the directories, the account creation and the results are shown in Figure 10.

Figure 10

We can use the same concept to filter several other type of accounts that the administrator does not want to replicate to the Windows Azure Active Directory.

Managing the Synchronization Service Manager operations…

This is a small hint but sometimes can help during a troubleshooting process. Using Synchronization Service Manager under Operations section, we will have all operations listed with start, end, profile and status for each one of them, as shown in Figure 11.

Figure 11

In some scenarios, the administrator may want to perform a change and then run the synchronization but by default, all previous runs are listed. The administrator can always track the start and end time to make sure which profile ran, however to avoid overseeing an item some administrators prefer to run and see only what happened on that moment especially when a series of runs are running in a matter of minutes/seconds as part of the troubleshooting process.

In order to do that, click on Actions and then on Clear Runs. In the new window, there is an option to save it before removing it (Save runs before cleaning them), click on OK and the result is the image on the right on Figure 12 where we have a clean Operations tab to work on.

Figure 12

Now, having a clear Operations tab makes it easier to troubleshoot the tasks because the administrator knows for sure that all tasks listed are using the new changes. There is nothing wrong in keeping all the operations log, but sometimes a clear view helps to narrow down the issue and keep the focus only on the tasks that are related to the issue.


I will not say this is the “new” final article of this series because we may go back to add more articles to this series, and the focus will be to provide tools and hints to improve our synchronization between on-premises and Windows Azure Active Directory.

In this fourth article we used a more advanced filtering to remove invalid UPNs and specific group of accounts (in the case of this article was service accounts) from the synchronization with Windows Azure Active Directory.

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

Leave a Comment

Your email address will not be published.

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

Scroll to Top