In this blog post I am going to review the upgrade process of Dirsync to the new AAD-Connect. The March 2015 preview now makes it possible to perform an in-place upgrade from Dirsync to AAD-Connect. This entire process took 30 minutes for me in my lab environment, but your performance and time may vary because I am running a small environment on SSD hard disks =).

Important: You must read the “Azure AD Connect Public Preview 2 Readme” file – there are too many requirements and prerequisites in that Readme file to summarize in this blog post, so please do not skip that reading.

I also recommend reading the “New Sync features in Azure AD Connect Public Preview 2.docx”

You can download the AAD-Connect March Preview, Readme file, and the New Sync Features document from the Connect site here:
https://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=53949

After the prerequisites are installed, AAD-Connect detects Dirsync and will now upgrade it in-place:

Next, I am prompted to enter my Azure AD Administrator Credentials

Lastly, I am ready to click Install. I recommend unchecking the box to start synchronizing after install. You can always start it manually later when you are ready.

This part of the wizard took about 10 minutes to uninstall Dirsync and install AAD-Connect.

Next, I clicked on the icon on the desktop “Azure AD Connect”

I then signed in.

I then type in an Enterprise Admin account

If I want to connect to an additional forest, I can do that here:

Next, I select that I want to enable password writeback. You will notice that user, group and device writeback are greyed out and not selectable. This is because we have not yet run the AD preparation steps necessary to enable those features. See the bottom of this blog post for details on enabling those features.

And one last confirmation by clicking Install

And one last confirmation that the installation was successful

Enabling User, Group and Device Writeback

In the readme file, it describes the powershell commands to run that will enable this enhanced functionality.

For group writeback, your on-prem Exchange server must be running Exchange 2013 CU8. Also, the default Sync Rules will not add the address book attribute. Find the value from your Exchange server and add this as a custom attribute flow.

The Initialize-ADSyncDomainJoinedComputerSync Function will initialize your Active Directory forest to sync Windows 10 domain joined computers to Azure AD. This function will need to be run on each forest to allow Windows 10 computers to authenticate against ADRS.

The Initialize-ADSyncDeviceWriteBack Function will initialize your Active Directory forest for write-back of device objects from Azure AD to your Active Directory. It will also set up the necessary permissions on the AD Connector account. This only needs to be run on one forest even if AzureADConnect is being installed on multiple forests.

Note: I received errors when running this command.

The Initialize-ADSyncGroupWriteBack Function will initialize your Active Directory forest for write-back of group objects from Azure AD to your Active Directory. It will grant permissions to an AD Connector account for modifying objects in a pre-existing group WirteBack container. Please use this same container for Group WriteBack when you run the wizard. This function only needs to be run in one forest.

I created a new organizational unit for these objects called “CloudUsersAndGroups”

Initialize-ADSyncGroupWriteBack -GroupWriteBackContainerDN “OU=CloudUsersAndGroups,DC=thecloudtechnologist,DC=com”

The Initialize-ADSyncUserWriteBack Function will initialize your Active Directory forest for write-back of user objects from Azure AD to your Active Directory. The users will be created with a random password so you have to reset the password in ADDS for the user to actually be able to login.

Initialize-ADSyncUserWriteBack –UserWriteBackContainerDN “OU=CloudUsersAndGroups,DC=thecloudtechnologist,DC=com”

Note: The Azure AD Premium feature password writeback does not work for users configured for user writeback. In other words, if you have a cloud identity, and that user is synced to the on-premises AD, then the password writeback feature will not update the newly created on-prem AD account version of the cloud identity user. I assume it would still reset the cloud identity portion.

After running these commands, I went back to the wizard but the options were still greyed out. This may be because my AD Schema is not running Exchange 2013 CU8, so I will update my schema and then update this blog post after that is done.

Next, read how to configure Azure AD Password Write-back on MSDN (I recommend reading all seven (7) articles under ‘Password Management’
https://msdn.microsoft.com/en-us/library/azure/dn510386.aspx

In the Azure AD Tenant, I enabled the toggle “USERS ENABLED FOR PASSWORD RESET”

And when I scroll down, I now see that Password write back service status is ‘Configured’

What does the user experience look like for self service password reset?

Typically, the user will click on the “Can’t access your account” link below the Office 365 sign-in page at http://portal.office.com

Otherwise, they can also bookmark directly to the self-service password reset page:
https://passwordreset.microsoftonline.com

They will be prompted to authenticate with text message, email or phone call. You can configure which of these options you want the user to enter. The user can also register for self service password reset and populate this contact information in advance, or an administrator can pre-populate it (again, please read the MSDN articles above for more details).