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

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

Using filtering with Directory Synchronization Tool

If we have an organized and well-structured Active Directory (Figure 01) using Organization Units and having the objects placed properly on those OUs then we can take advantage of the filtering to replicate just a few locations/object from the on-premises Active Directory to the Windows Azure Active Directory (WAAD).

A good example is the structure below where for each Country we will have a designated folder for Groups, Users, Contacts and so forth.

Image
Figure 01

The filtering helps when we want to control which OUs will be synchronized and to avoid some objects that should not be synchronized in the first place. A good example is shown in Figure 02. In the previous article we finished the wizard and we synchronized using the default settings. The results can be seen in the Office365 portal where we have several objects that should not be in the Office365 (administrator accounts of some OU, Exchange Health Mailboxes and so forth).

Image
Figure 02

The filtering process is simple, the first step is to open the Synchronization Service Manager (FIM 2010 client) and this time we will click on the Management Agents area (Figure 03). We will have two entries, the first one (Windows Azure Active Directory Connector) is related to the WAAD side, and the second one labeled as Active Directory Connector which is related to our on-premises Active Directory. Double click on Active Directory Connector.

Image
Figure 03

In the new window click on Configure Directory Partitions item on the left, and then click on Containers on the right side (Figure 04)

Image
Figure 04

A new window will ask for credentials, remove the existent username for a user with administrative rights and its password and then click on OK.

The next window will have the Default Name Context partition listed (Figure 05). We are going to select only the OUs that contain mailboxes, contacts and groups that we want to replicate to the WAAD. Click on OK to confirm the changes.

Image
Figure 05

We can synchronize using the Start-OnlineCoexistenceSync however this process will not remove the objects previously synchronized from the WAAD. After filtering the OUs, we need to force the synchronization which brings us to our next topic of this article: synchronization!

Performing a Full Synchronization

We learned in the first article of this series about the tools available, and one of them was the DirSyncConfigShell and that from there we can run the Start-OnlineCoexistenceSync to start a synchronization (Figure 06). This process will synchronize only the changes and under the hood (Figure 07) it will run a Delta Import Delta Syncon each side and an Export on the WAAD side.

Image
Figure 06

Image
Figure 07

In some circumstances like the filtering that we started at the beginning of this article, a full synchronization is required to remove objects that are no longer being synchronized from the WAAD. In Figure 08 we have the list of some users that were replicated before the filtering took place.

Image
Figure 08

We can perform a full synchronization in two different ways, the more traditional way used in the previous version of the Synchronization Tool is changing the value of FullSyncNeeded to 1 using Registry Editor and running the same Start-OnlineCoexistenceSync and that will trigger a Full Import Sync followed by an Export. The key can be found at HKEY_Local_Machine\SOFTWARE\Microsoft\MSOLCoexistence

In order to check the current value, we can run the following cmdlet (Figure 09):

Get-ItemProperty –Path ‘hklm:\Software\Microsoft\MSOLCoexistence’ –Name FullSyncNeeded

Image
Figure 09

Then change the value to 1, by running the cmdlet below (Figure 10) and after that check again using the previous cmdlet to see if the attribute was properly changed.

Set-ItemProperty –Path ‘hklm:\Software\Microsoft\MSOLCoexistence’ –Name FullSyncNeeded –Value 1

Image
Figure 10

After running the synchronization, the FullSyncNeed parameter is automatically reset to 0.

Another way to perform the full synchronization is using a hint posted here at MSExchange.org by the fellow MVP Henrik Walther using the following switch with Start-OnlineCoexistenceSync –FullSync and it will do the same thing.

After performing the full synchronization, we can validate that all entries that were in the WAAD were removed because their original OUs are no longer members of the replication due to our filtering changes. (Figure 11).

Image
Figure 11

Since we have a trial account that was just created, we can check the deleted users (Figure 12) and all objects that were removed from the WAAD as part of the full synchronization are there. We cannot delete them from the Office365 console however we can do that using PowerShell which will look at in the third article of this series.

Image
Figure 12

Understanding the Status of an object in the WAAD

It is a basic concept but it is important to be mentioned, when we look at the users and groups in the Office365 console we will see the status column having two values: In cloud and Synced with Active Directory as shown in Figure 13.

Image
Figure 13

What difference does it make? Well for starters, the ones with status In cloud are present in the cloud and that is okay for the admin account and service account that we created in the cloud, and those objects can be deleted just fine.

On the other hand, objects with the status of Synced with Active Directory cannot be deleted from the Office365 console. They must be removed from on-premises Active Directory and wait for the replication to take place.

When the object is deleted from on-premises Active Directory, then it will show up on the deleted users tab of the Office365 console and its status will change to In Cloud which means that they can be deleted for good. If we want to do that, we need to use Windows Azure Active Directory Module for Windows PowerShell

Setting the Synchronization account Password to never expire

By default, all accounts created in the cloud will have their password expired in 90 days which is reasonable for regular accounts, however we created a service account to synchronize our on-premises Active Directory to WAAD and that account should be configured to never expire.

Note:
When using Active Directory synchronization the password expiration policy does not apply to the users that have the status “Synced with Active Directory”.

In order to change the service account, open the Windows Azure Active Directory Module for Windows PowerShell, and use the following steps:

  1. Run Connect-MSOLService and type in the admin credentials in Office365
  2. Find the service account using Get-MSOLUser –UserPrincipalName <account>@<domain (first cmdlet of Figure 14)
  3. Configure the desired account to never expire using the Set-MSOLUser –UserPrincipalName <account>@<domain> -PasswordNeverExpires $True (second cmdlet in Figure 14)

Image
Figure 14

Conclusion

In this second article of our series, we went over the process of defining which Organization Units will have their objects replicated to the Windows Azure Active Directory and a few additional hints about full synchronization and how to configure the service account to avoid password expiration.

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.

Scroll to Top