I have been working on an issue for one of my clients where they have migrated email from an on-premise Exchange server to Microsoft Office 365. The migration was handled using a third party migration tool to synchronise email content into their Office 365 tenant, something that didn’t go smoothly and not wholly relevant to this posting. The major thing that wasn’t fully setup was the synchronisation between their existing on-premise Active Directory and their 365 tenant and users struggled initially with passwords that were not in sync between the two platforms. One thing that did happen however was that the Exchange server was decommissioned and any Exchange attributes removed from the Active Directory user accounts.

Looking into this I started by upgrading the installed version of DirSync to the latest release from Microsoft (click here) which automatically detected the previous installation and upgraded it to the latest release. As described in upgrade guide I completed the initial configuration and provided the following to the wizard:

• Office 365 administrative login,
• my Active Directory details,
• the fact that it is not a hybrid deployment (remember Exchange has already been uninstalled),
• that I wanted to sync passwords and
• to not perform an initial sync (I need to troubleshoot what hasn’t been working).

I opened the not so easy to find Synchronisation Service Manager (C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell) and checked the configuration of the data to be synchronised.

We are synchronising our users based on their location in Active Directory and have created two Organisational Units (OUs) under two separate User OUs within our directory only one of these has been selected at this stage.

The user was showing up and the synchronisation log was showing success messages. I updated the Department attribute for the user within Active Directory and forced a sync to office 365, no errors reported in the Sync Manager and the Office 365 user was updated correctly. This seemed so simple so I informed my client we would enable the changes this week and everything would go back to one password and, apart from the shortcoming of Microsoft Outlook not participating with the Single Sign-On that the rest of Office does, users would be happy.

Or so I thought until I came to actually enable the remainder of the users…

I opened Synchronisation Service Manger, browsed to Management Agents and edited the Active Directory Connector, edited the Containers I wanted to sync and clicked OK only to be given the message:

Join/Protection validation error
‘publicFolder’ is no longer listed in the list of selected object classes

Googling didn’t come up with much more than this forum post (https://social.technet.microsoft.com/Forums/en-US/f3cfc3f1-4dac-4f33-b036-399e6c57fd10/dirsync-joinprotection-validation-error?forum=ilm2) which was unanswered at the time.

Looking through the options I found that under Select Object Type the publicFolder wasn’t listed so after clicking Show All, scrolling down a long way I enabled it and was able to save the update configuration

First hurdle out the way I moved a user into my new OU and forced another synchronisation… which failed

Clicking on the error I was redirected to a Microsoft KB article (KB2647098). Reading through the article I knew there were no duplicate accounts either locally in my AD domain or in the 365 tenant so I started to look into the proxyaddresses to see if Exchange had left something in place when it was removed from the network. When I looked in ADSIEdit at the user in question I found there were no proxyaddresses listed at all:

Checking the one synchronised user I noticed that they did have the proxy addresses listed so I added them manually in the format

SMTP:Firstname.Surname@domain.com
smtp:samAccountName@domain.com

Saving this and re-running the sync gave me a success, my user was now showing as synchronised with Office 365. I added another couple of users but this time, when I synchronised I received a different error message

I checked the accounts were enabled both in Office 365 and in Active Directory, restarted the DirSync service to no avail. After looking at this and a handful of other users I could see that this was going to take a while to complete manually so needed to automate this in some way. Rather than spend some time researching how to write the appropriate PowerShell commands to complete this change I switched to my trusty friend ADModify.net (https://admodify.codeplex.com/)which I have used many times in the past to update attributes in bulk within Active Directory.

For those of you that haven’t used it ADModify.net is a very competent tool at modifying the attributes of a number of AD objects in bulk.

Extract the contents of the download and run the executable then click on Modify Attributes when prompted

Select your Domain and preferred Domain Controller from the menu on the left, click the green icon and then browse to your OU to modify.

Click on Add to List at the bottom to add the discovered objects, select the ones you wish to modify and click on Next

On the email addresses tab choose Add SMTP Address and enter the email address in the format you want to use. Set Primary and update the General tab as well then click Go.

At this stage the tool will update the AD attributes for the list of objects selected earlier, output a popup with the status of any failures as well as write an XML based log file to the directory the executable ran from. Review any errors and then continue to add any other addresses

Here I have added an address that matches their UPN login to match the configuration I can see for my Office 365 users.

Now that these have been run against all the AD accounts that need to synchronise I restarted the DirSync services once more and completed my sync without issues.

The conclusion from all this is to make sure that everything is in place to synchronise your Active Directory and Office 365 tenant *before* decommissioning Exchange but also that if you are in this situation that you make use of tools such as ADModify.net to save the hassle of editing all the records by hand.