User Group Session next month

Next months User Group session will be on Microsoft’s HDInsight in Azure, presented by Microsoft.  If you are currently interested in Big Data, then this is the session for you.

Dates to be confirmed.  The technical level of this session will be 300.

Please add comments for any items that you wish you have covered in this session.

eg. Power BI for Office 365, data analytics, migration, DataZen, Hadoop.


Look forward to seeing you then.

Aaron @AaronW2003


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


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, 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 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 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


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

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

Successfully updated ‘’ 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



Identity: Office 365 SMTP softmatch in action

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

What do you do if you have ‘In Cloud’ identities that you wish to link to a managed Active Directory user accounts?  You can perform a smtp softmatch as described in this Microsoft article here.

Before we give this a go, let’s look at why you need to be a Domain Administrator and a Schema admin.

The installer affects these security groups:

  • Schema Admins
  • Enterprise Admins
  • Cert Publishers
  • Domain Admins
  • Account Operators
  • Print Operators
  • Administrators (domain local)
  • Server Operators
  • Backup Operators

DC: It installs an Active Directory Group called MSOL_AD_Sync_RichCoexistence.  Inside the group it adds a user that it creates called MSOL_XXXX. (I have 2 as i didn’t uninstall a previous DirSync install, it can be deleted)

MSOL properties

DirSync: After opening the Miisclient, to change the OU filters, select the Management Agents, right click Active Directory Connector, properties, Configure Directory Partitions, Containers, remove the MSOL user account and enter your own FIMAdmin credentials (these are not replacing the MSOL account).  You can see here that I have filtered out unnecessary OU’s from my Active Directory syncing (only selecting the test OU).


Let’s look at my new ‘In Cloud’ user in Bruce Wayne in Office 365.



Here you can see his email address of

email address

DC: Back in Active Directory I have a new user.  I want this Active Directory password and UPN to be the same in Office 365 linking the 2 accounts.

New User

DC: After the user account is created, add the email address to the mail properties (username/email address from Office 365) Active Directory User object (exchange does not need to be installed and no schema extensions are required).

add email

Now we are set up and ready for a sync.


DirSync: This error shouldn’t be ignored as the sync did fail.  There are 2 reasons a manual sync would be failing.  You turned the DirSync services off, or you are not in the FIMAdmins group.  Also I could not open the miisclient as below.


DirSync: After adding my user to the FIMAdmins group, and logging off and on I could proceed with the sync.

local admin

DirSync: Here you can see the successful ‘1 Add’, and you can drill down and see the synced user that was written (Bruce Wayne).


Now let’s check the user in Office 365.


We can see the user is now ‘Synced with Active Directory’.  Bruce’s username and password is now exactly the same as On Prem (you may need to change your AD UPN’s to a publicly routable domain name, i skipped this step in my lab).

This should be implemented with caution and after testing.  Doubling the identities in Office 365 would not be a good situation to be in.


“That’s great but my ‘In Cloud’ identities are completely different to my Active Directory user accounts.”

Let’s link 2 different user accounts together.  My new ‘In Cloud’ user is Able Alf.  He has an email address of


I have added a new user called Barry Black.  I have added the email address to Barry’s Active Directory user account.


Here you can see Barry’s user accounts UPN.  This is different to Able’s Office 365 UPN.


I started another sync.  Now you can see that the Office 365 user account has changed display names and password.  The username is the only thing that remains the same.  This can also be verified through PowerShell.



Any comments are welcome!


Azure and Office 365- One big ecosystem

Here is my recent article “Azure and Office 365- One big ecosystem” published in the @MSAU Microsoft TechNet newsletter.