A second look at Azure AD Connect Public Preview 2

Before viewing this post please refer back to my following articles if you require a base understanding of Microsoft Azure ADConnect and the features available.

  • I first posted on AADConnect and AADSync back in August last year.
  • I also presented on Cloud Identities at TechEd Melbourne and Sydney last year here.

This post will focus on what is new and what has changed.

As posted by Alex Simons (Azure AD Director) the Microsoft Azure ADConnect preview 2 was released earlier this year. I downloaded Azure AD Connect Public Preview Download from here. I started the installer and was presented with the screen to install the services. Note: I could have specified a SQL server if my Domain was large enough to warrant this (Microsoft recommends this for over 50,000 + users). I could specift a Service Account if that was a company requirement. I could also select import settings if I had a previous configuration that I wanted to apply to this ADSync server.  I left all options unselected and selected install.


The next option was to specifiy what I wanted to install, ADSync or SSO. I selected ADSync.


I then entered my Azure Global Admin credentials. The installer now creates and assigns a service account within Azure AD with the minimum permissions that it requires, which is a great improvement. I then entered my On-Premises credentials (this also creates a service account).


The following option allows for Group Based filtering.  I noted that you can only specify 1 group here which may suit some customers who do not wish to use OU based filtering. Microsoft added this option with the intention of pilot and evaluations of Azure AD and Office 365.  I selected ‘Synchronise all users and devices’.


Here I specify that a user is represented only once across all directories.


Here you can change your user attribute mappings.  This may be required if you are using for example Shibboleth for SSO or if you have some other customised requirements.


Optional features can be modified later, so don’t be overwhelmed by the amount of options.  You can re-run the wizard to make changes later if you need.

  • Exchange Hybrid- For an Exchange Hybrid migration to Office 365.
  • Azure AD attributes- if you only want to sync a smaller set of user attributes.
  • Password writeback- change a password in Azure AD and it writes back to On-Premises and verifies the On-Premises password policy.
  • User writeback- A user created in Azure AD is created in On-Premises AD.
  • Group writeback- Groups in Office 365 will be written back to your On-Premises Exchange forest.
  • Device Sync- Allows for Windows 10 computers enrolled with Intune or directly with Azure AD to sync to On-Premises AD. (we are seeing the start of managing a Windows-as-a-Service subscription model). This is called ‘Cloud registered Devices’. NOTE: This requires a 2012 R2 schema.
  • Directory extension- Use this if you want to sync a unique attribute to Azure AD, eg. a custom Linux attribute, or an Employee ID (currently limitations apply to certian values and characters).


The screenshot below is for Azure AD attributes.  So in my example I will not be using CRM so I remove the syncing of these attributes.


Below we have the option to remove attributes from being Synced.  Eg. An organisation may have extended their schema and used “extensionAttribute’s”. Perhaps these contain sensitive information, the administrator can simply uncheck these attributes so they are not synced.


Here we confirm which On-Premise destination we want to use for User writeback. Select the Users OU. Note: you can add/merge many domains to the one Azure AD subscription, so Write-Back destination is required. 


Here I ticked the box to start a sync after install.


Here you can see I have run the miisclient and can see that 60 objects have been synced automatically.


Here was can easily see errors. My user account had an error because AD and AAD had the exact same display name of aaron.whittaker. For this test environment I will ignore this error.


Next in Azure AD I create a new user called CloudUser1


Back on my Sync server I selected connectors at the top, then selected my Azure AD and run a ‘Full Synchronization’.


Below you can see the event for the CloudUser1 being synced to On-Premises.


Here we can verify that the user has been synced.  You can see I have applied an On-Premises group membership permission to a Cloud User.


To view my post on upgrading to AADConnect GA from Beta see my post here.

To get started refer to the following articles:

Post by Alex Simons

And follow these twitter handles:

@askariel  @Alex_A_Simons

To start planning for your business transformation you can deploy and test these features all from within your Microsoft Azure subscription.  If you don’t have a Microsoft Azure subscription you can take a trial here.

Aaron Whittaker

profile pic


Installing and Running Azure Active Directory Sync AADSync Beta 3

Created by Aaron Whittaker.  Not to be reproduced without prior permission.

Ingredients Required: AADSync MicrosoftAzureActiveDirectoryConnect.msi installer from the BETA program (using version 3.7.1224), Domain Controller, Office 365 subscription, Azure, 2 Windows 2012 R2 domain joined servers, Public trusted certificate and a valid domain.

Time: A few hours.

My deployment is not complete and requires further work or your input.  I will mention that my virtual machines are running in another Azure subscription (which is a supported configuration see my TechNet article on the topic here).  I will investigate if something is blocking here (endpoints inbound and outbound.) 

The first time I tried this exercise I did not have a public trusted certificate.  I tried a Self Signed certificate but it did not work (Azure documentation says that it should).  So I purchased a domain, so I could a valid public certificate.

My existing environment consisted of a DC and a DirSync server.  I simply turned off the DirSync server and created a new server called AADSync and a WebAppProxy.  This normally leaves the sync’ed users populated in your Azure AD.  This was not an issue for me as the new DirSync server will take over, or I could have manually removed the now ‘In Cloud’ users.  I installed DirSync just via running the new AADSync DirectorySyncTool.exe installer (just using the default SQLExpress) and just configured and installed DirSync.  This was because I didnt have the certificate.

I ran the MicrosoftAzureActiveDirectoryConnect.msi installer on my server named AADSync.  The installer is only 976kb so it downloading all files as required.

Installing DirSync


The installer now installs the pre-requirements if required which is a nice feature!

  • .NET 3.5
  • SQL Express LocalDB
  • Azure Active Directory Sync Services
  • Sign-in Assistant
  • AAD Connector
  • Azure Active Directory module for Windows PowerShell

2 3

After going away and making an Azure subscription for my Office 365 tenant, here I entered my Office 365 public domain verified administrator account adminuser@brisbanecloud.net


Here I chose Customize.


I selected single AD forest.


I selected Single Sign On.


Entered my local Domain Admin credentials.


Error: Here is where I ran into my first issue.  I only had a .cer file, once I made a self signed .pxf I still could not proceed.  

I pressed back several times and proceeded with Express settings.

9 10 express 11 12

After this new Installer I was able to go in and configure DirSync as described in my previous post here.  The DirSync configuration wizard ran as normal and as expected.  The location to administer dirsync changes is in the location shown below.  This is still no DirSync app showing on the desktop or under programs.

21 22

 Installing SSO

Here are the steps for SSO configuration.

I went away and purchased brisbanecloud.net, then created a free public trusted certificate.  Then I re-ran the Azure AD Connect Preview shortcut located on my desktop for a second time.  Here you can see that my Office 365 credentials (now also Azure creds) were required.  If you go into the installer and press back a few times as you can see it saves your settings (only for that install session).  I selected Continue, entered my Active Directory credentials, next.


Here I browse and select my Public Trusted certificate.  It must be in PFX format.  I enter my password.  From the drop down I select the URL.

Error: Subject name must have www.  I went and renamed my pfx file and reloaded it to fix this issue.

I selected next, then I added my AADSync server which will become my ADFS federation server, next

34 after pfx password  36

Then I selected my Web Application Proxy server,

Error: Here I had to enable PSRemoting on the WebAppPrxy server via PowerShell.

Then I selected next.


Then I entered my same Domain Admin credentials (Enterprise admin was required), next.  Then I selected Create a group Managed Service Account for me and next.

40 41

Then from the drop down I had this error.

Error:  The domain needed www. in it.

I went to Azure as it mentions ‘Azure’ in the error and verified http://www.brisbanecloud.net under domains in Active Directory (WAAD) as shown below.

43 44

Back on the installer there was no update to my latest change.  I went and removed the domain from Azure and then added http://www.brisbanecloud.net within Office 365 domains.  Immediately after a press of previous and then next on the installer, I was able to see the correct address of www.brisbanecloud.net.


After reviewing the options I also selected Configure password hash.  The installer started and things looked good.

46 47

Then I received another error.

Error: Can’t remotely install Active Directory PowerShell.

After getting the same error a few times, I ran the following on WebAppProxy, DC, and AADSync servers.

Administrative PowerShell: set-WSManQuickConfig

Administrative PowerShell: winrm QuickConfig

Administrative PowerShell: enable-psremoting -force 

48 error 49 powershell commands

Then I selected retry to attempt the install again.

Error:  An error occurred while executing the ‘Convert-MsolDomainToFederated’ command. Microsoft.Online.Administration.Automation.DomainNotRootException —> Microsoft.Online.Identity.Federation.Powershell.FederationException  ……  The task ‘Create AAD Trust’ has failed.

So them I though I will just run this command manually with an Administrative PowerShell.

PS C:\> Convert-MsolDomainFederated -DomainName brisbanecloud.net

50 51

Then I got a new error

Error: This was a credential issue since the user account is now syncing.  I needed to change the credentials so I closed it and went to re-run the installer again (as there was no back button).


So I re-ran the Azure AD Connect (Preview)

Error: An error occurred while executing the ‘Update-MsolFederatedDomain’

I thought I should try to manually run this command in PowerShell.

PS C:\> Update-MsolFederatedDomain -domainname:brisbanecloud.net

Successfully updated ‘brisbanecloud.net’ domain.

As you can see below I am still getting an issue.  I have not had another chance to try a different workaround as yet 95% completed…



Thoughts and Comments