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.




How to Migrate a VM from one Azure Subscription to another

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

In Azure On Tenant 1 Power off the VM (this VM was not Sysprep’d or anything else)

Note end points, disks, VM size and any other settings


Download and install Azure Management Studio

Connect to the 2 Azure subscriptions.

In Azure Management Studio Drag and drop the VHD to the new destination.  It says ‘Move’ but the original VHD stayed in my testing.


Back in Azure On Tenant 2, go to Virtual Machines, Disks, and select create

Give the disk/s a name and select the VHD.  Ensure that OS disks have OS checked box selected.


Create a new VM, select from Gallery, select “MY DISKS”, and create the VM as required.

creating vm

I entered a new Username and Password, but the original credentials stayed on the VM (because I didn’t Sysprep the VM).

Attach any additional disks if required.  Ensure that you leave Host Cache Preference to NONE for these additional disks.

Power on the VM.

Download the RDP connection short cut

Log in.

Missed TechEd? Get the best content condensed from the Virtualization Stream.

At TechEd last week there were 4 sessions on Hyper-V 2012 R2.  This jam packed User Group session will condense these into 1 session.  Giving you the best parts in the shortest time. This weeks session will demo the great new features in R2 and also 3 different migration scenarios and strategies.    We will also talk about zero downtime upgrades, HA considerations, and utilize the copy clusters feature.  There will be prizes on offer.

Register here