Preface

So DirSync is a thing of the past now. It’s deprecated but it’s supposed to keep working. For us, it didn’t. Password sync just never occured, so when a new colleague arrived at our office needing a new account I was basically forced to upgrade to the newcomer dubbed Azure AD Connect, or Azure Active Directory Connection. Let me show you how it went (spoiler: it worked). You probably want to keep the DirSync guide also open coz I’ll refer to it quite a lot.

Preparation

You can’t do an in-place upgrade as of Azure AD Connect Preview 1. So the first thing you need to do is uninstall Windows Azure Active Directory Sync via Control Panel.

You can also safely remove the MSOL_ user from AD, it won’t be needed anymore. If you wanna play it safe, you might as well just disable it.

Setup

Download AD Connect and install it. After that, run the configuration wizard. It should be a no brainer, especially after all the struggles with DirSync, but here’s a detailed guide, just in case.

Again, at the end of the wizard make sure to uncheck Start the synchronization process as soon as the initial configuration completes.

With AD Connect we still have the Synchronization Service Manager except it’s been relocated to %ProgramFiles%\Microsoft Azure AD Sync\UIShell\miisclient.exe. You probably want to have a shortcut for this… anyway, let’s start it.

Looks pretty much the same as before. Now you probably want to set up OU level filtering, so select the on-premises AD connector and open its properties, then select Configure Directory Partitions.

Now click on Containers… after which it’ll ask for your admin credentials. This is a change in behavior because DirSync used to generate the MSOL_ user and you had to reset its password, but now you can forget about that hassle.

Now you can select the OUs you want to sync.

Unlike with DirSync (Start-OnlineCoexistenceSync), now you can start manual syncing via the Task Scheduler. Open it and find a job called Azure AD Sync Scheduler.

You may have to enable it, then just run it. Then you may get 2 new errors in the DirSync logs (see the previous post about finding those). One says:

The following password changes are no longer eligible for retry and will be purge from the retry queue

This is because AD Connect has already cached these entries from AD but haven’t synced them to Azure just yet. Then you set up OU level filtering and these entries fell out of scope. There’s not much you need or could do about these so let’s move on. The other one reads like this:

Unexpected:: Cookie should not be null/empty for delta import.

This isn’t really saying much. At all. After some time another entry pops out, but this time it’s a warning and it’s a lot more helpful:

The management agent completed run profile “Delta Import” with a delta import or delta synchronization step type. The rules configuration has changed since the last full import or full synchronization. To ensure the updated rules are applied to all objects, a run with step type of full import or full synchronization should be completed.

Alright, so fire up SSM again, find the Azure connector, then run it with the Full Import profile.

Then do the same with the Full Synchronization profile, too.

Once it finishes, finally you get your objects synced to Azure.

Might as well check out the objects if you wish.

And now, at last, that precious password change event happens!

The new colleague is happy because he got his new password, and I’m happy coz password sync works again.

End of story 🙂