AADSync / AADConnect default Domain Controller

I came across an odd situation recently whereby my AADConnect installation had decided to communicate with a Domain Controller which was in another site, across an Active Directory replication link with a 180 minute replication interval. This was no good for my customer as they made their AD changes on the site local to AADConnect, so I decided to remedy this by forcing AADConnect to communicate with a particular DC. This can be useful for many reasons, and you can actually set a list of ‘preferred Domain Controllers’ to allow for fault tolerance.

To do this, go into the Synchronisation Service, head on over to the Connectors tab and find your Active Directory Domain Services Connector. The below example is synchronising multiple AD Forests. Once you’ve selected your domain, you can see which Domain Controller is currently in use by checking the ‘Connection Status’ area (shown in the central area of the below screenshot).

Synchronisation Service

To change the Domain Controller in use, go to the Properties tab for your domain (on the right hand ‘Actions’ pane). Go into the ‘Configure Directory Partitions’ tab and you will see a handy tick box entitled ‘Only use preferred domain controllers’.

AADConnect - Directory Partitions

Place a checkmark in this box, and a window will appear, allowing you to enter your shortlist of Domain Controllers.

AADConnect - Preferred DCs

Once you’ve entered your preferred DCs, OK your way out of these windows and hey presto, you are done! It’s a nice and easy task to perform, but not one I’ve seen documented online before.

Thanks for reading!

Azure Active Directory Sync – AAD Connect Disaster Recovery and High Availability

I just wanted to write and tell you all about a fantastic new feature built into the AAD Connect tool. It’s name is ‘Staging Mode’ and it has a dual purpose; a) it allows you to have a server which is essentially on standby, and b) it can be used just as it’s name suggests, in a kind of test mode where you can see what is being imported before it all gets sent off to Azure AD.

In real life it would be utilised thus:

Customer A has a functional installation of AAD Sync / AAD Connect which is synchronising objects and attributes between Azure Active Directory and the On Premise Active Directory. They then build an AAD Connect server in their DR datacentre (or wherever they fancy), and during the initial configuration, enable ‘Staging Mode’. Apart from this setting, they configure it just like their existing, live AAD Sync / AAD Connect server. They even leave the scheduled task enabled and running. All of a sudden, DR strikes, and the live AAD Sync / AAD Connect server goes offline forevermore, cast into the computer graveyard in the sky. Rather than restore the server from backup, they simply log into their second AAD Connect server and disable ‘Staging Mode’. This server then starts synchronising with Azure Active Directory in earnest, without having to miss a beat.

What Staging Mode does is very simple. It acts just like a functional AAD Connect installation, except for the fact that it exports nothing to Azure Active Directory or your on premise Active Directory. It also does not perform any password sync or password write-back functions. The metaverse is fully populated and ready to start exporting data, giving you the easiest possible way to have a server on standby. Unfortunately there is no replication between your two synchronisation servers, so any configuration changes need to be replicated manually, but this is another step to making AAD Connect fully HA, which is becoming much more desirable as Azure Active Directory gains traction.

AADConnect Staging Mode

Modify AADSync Default Schedule

When using the AADSync tool to synchronise your Active Directory environment with Azure Active Directory (AAD), the default schedule for an incremental sync is 3 hours. This is done using a Scheduled Task. There are many reasons why you may want to change this schedule; maybe you have a high rate of change in your AD environment and you need a 1 hour sync to keep Office 365 up to date, or it might be that you have such a slow rate of change in your AD environment that you only want to sync your identities once every few days. It is worth mentioning that Password Synchronisation does not follow this schedule and is done immediately following a change of password, so this shouldn’t play a part in your decision to modify any scheduling of sync tasks.

Whatever your reasons, you are likely to become a little befuddled when trying to modify the regularity of your scheduled task. If you go into Task Scheduler, find the Azure AD Sync task and go into Properties, you can change the frequency of the task to make it run more or less often. However when you try to save the task it will ask you for the password of the account under which the task runs, the name of which looks something like ‘AAD_a6a4cefedc741’. It uses a random hex code at the end of the name so this could be slightly different to the example I’m using.

Modify AADSync Schedule

This account is used to run the AADSync service, is the account used to access the MIIS client database, and also to run the Scheduled Task. It is a local account which is created during the initial installation of AADSync, and the password is randomly generated. It may be tempting to change the password of this account, but please don’t. I have only come across this happening twice but both times have involved the internal database becoming completely inaccessible, meaning that the service simply won’t start, even with correct credentials.

If you really must change the frequency of your sync, create a new Scheduled Task and configure it to run the following application:

“C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCMD.exe”

Ensure the Task is running with the highest possible priveleges and configure the task to use a user account which is a member of the following groups:

  • ADSyncAdmins
  • ADSyncBrowse
  • ADSyncOperators
  • ADSyncPasswordSet

This new task will run under whatever schedule you fancy, and for good measure you can disable the original task if you’d like. When dealing with default configuration items in any piece of software, I would always recommend creating cloned configurations rather than modifying the default, as it gives you a way to back out of changes and allows you to compare old with new.

Synchronised User not Provisioned in Lync Online

Today I came across an issue with Lync Online during an implementation of Office 365. We synchronised the user accounts and password hashes using AADSync and applied E3 licenses to a few test users in the IT team. Their testing was successful with the exception of Lync Online, which they could not login to with their synchronised @contoso.com account. The error returned to them was as follows:

Lync couldn't find a Lync Server for contoso.com. There might be an issue with the Domain Name System (DNS) configuration for your domain. Please contact your support team.

Lync Online DNS Error

I tested using my own testuser@contoso.com account and could successfully login to Lync Online internally and externally, which showed me that the DNS records were created correctly. After looking at the firewall logs it appeared that the DNS name lyncdiscoverinternal.contoso.com was being unsuccessfully looked up. This DNS record is used for On Premise Lync installations. I also noted that in the Office 365 Lync Admin centre, the user had not been provisioned.

After quizzing the customer, we discovered that a proof of concept Lync server had been installed a while back and enabled for a few test users in the IT department. This server was not properly decommissioned so AD attributes still existed for these test users. In order to get Lync Online to provision the accounts we had to go into ADSIEdit and clear the following attributes so that they were empty:


We then ran a delta sync and hey presto, our user accounts were provisioned in Lync Online and the users could successfully login. The error message we initially given was fairly misleading, but this just shows you how important proper decommissioning is when it comes to essential services like Lync and Exchange.

Modify UPN to match Primary SMTP address


You may have read a previous blog I wrote in which I explained a new feature in AADSync which allows you to use the Primary SMTP address as a username in Office 365, therefore allowing you to leave the UPN value unchanged. However this method is not without it’s problems, and during a recent Hybrid Deployment of Office 365 it was decided to instead change the UPN prefix and suffix to match the users Primary SMTP address.

The risk to be aware of here is that if one of your LOB applications or a Service Account is using the UPN for authentication, you will break authentication for this app/service.The customer in question was confident that this wasn’t the case, but just to be sure we changed the UPN for a few test users prior to rolling this change out.

To clarify, the users Pre-Windows 2000 and UPN logon prefixes were firstinitialsurname, for example, ECoates, whereas the Primary SMTP address was firstname.lastname@contoso.com, for example, Emily.coates@contoso.com. We wanted users to be able to login to Office 365 using their ’email address’, so we decided to change all UPNs to match. There are 2 commands that could be used to accomplish this. The end result of the commands was that the users UPN would be changed from ddixon@contoso.local to Emily.coates@contoso.com. We also only wanted to change to be made to user accounts with a Primary SMTP address specified.


Either of the two below commands can be run to achieve this goal. However, before either of these commands are run, it is important to make sure that the UPN suffix you wish to be populated exists in AD Domains and Trusts. To do this, open AD Domains & Trusts, and right click on Properties.


Then enter the required domain, such as contoso.com and click Add and Apply. This makes the alternate UPN suffix available for use in the domain.

Alternate UPN Suffix

The below commands need to be run from an elevated Exchange Management Shell prompt. It is up to you which to run.

Command 1

This command finds all users who have a Primary SMTP address and then sets the UPN to be identical to this. It will ignore any user who does not have a Primary SMTP Address.

$users = Get-User | Where {-Not [string]::IsNullOrEmpty($_.WindowsEmailAddress) } 
$users | ForEach {Set-User –Identity $_.Guid.ToString() –UserPrincipalName $_.WindowsEmailAddress.ToString()}

I found this command to be a little hit or miss, but this may be due to the size of the user base I was working with.

Command 2

This command finds all users who have the specified UPN suffix (such as a non-routable suffix like contoso.local) and changes their UPN to match their Primary SMTP address. If a user has no Primary SMTP address, it will not change the properties of that user.

$users = Get-User –Filter {(UserPrincipalName –like '*@contoso.local')} 
$users | ForEach {Set-User –Identity $_.Guid.ToString() –UserPrincipalName $_.WindowsEmailAddress.ToString()}

My personal preference is to use Command 2 as I had the most success with it, however I would love to hear your feedback on which one worked best for you!

Once you have run the command you can then use the following command to discover if any users were not successfully modified:

Get-User –Filter {(UserPrincipalName –like '*@contoso.local')}


I have also used the following command after having some problems with command 2 on Exchange 2013 (errors regarding the filter expression):

$mbxs = Get-Mailbox | Where {$_.UserPrincipalName -like '@contoso.local'}
$mbxs | ForEach {Set-User –Identity $_.Guid.ToString() –UserPrincipalName $_.WindowsEmailAddress.ToString()}


Purge a user account from Office 365

Today I made a mistake and accidentally linked together a standalone Office 365 account with an account synchronised from Active Directory. The ‘in cloud’ user became linked to the AD account and became ‘synchronised with Active Directory’. This wouldn’t usually be a problem and is done by design if the two UPNs match each other. My main problem was that the ‘in cloud’ user already had a mailbox, and so did the user in AD. This leads to a split-brain scenario whereby both systems believe to be hosting the mailbox. As I was about to configure a Hybrid Deployment, this is not a good thing.

Luckily the Office 365 account did not hold any required information in Exchange Online or SharePoint/OneDrive. In order to clean up the objects I moved the affected user into an OU which was not being synchronised and then performed a delta sync. This moved the object in Office 365 into the Deleted Users container. A deleted user in Office 365 remains in this container for 30 days before it is removed, however I did not have the luxury of waiting this long.

In order to purge the user account from Office 365 completely, I went into Office 365 powershell and ran the following command:

Remove-MsolUser -UserPrincipalName username@domain.com –RemoveFromRecycleBin –Force

This purges the item from the Deleted Users container. In Active Directory, I then moved the user object back into it’s original OU, and forced a sync. This provisioned a new user in Office 365. When applying the license to said user, I was correctly informed that the on premise mailbox had not been migrated to Exchange Online. Success!

Allow login to Azure AD/Office 365 using Primary SMTP address

The new Directory Synchronisation tool from Microsoft, AAD Sync, went into General Availability a few weeks back. This new tool is toting new features such as Password Write-back, AD Attribute Filtering and multi-forest synchronisation. All in all it is a great replacement to the now defunct DirSync product.

One issue which AAD Sync allows you to solve is the use of UPNs for usernames in Azure Active Directory. A UPN appears as if it is an email address, and often AD user accounts have different UPNs to their Primary SMTP addresses. This can cause confusion for users who expect to be able to login using their email address, just like they would in any cloud service out there. You could change the users UPN to match this, however in some situations this is not possible, either due to existing applications which use the UPN or due to Security policies which do not permit internet routable UPN suffixes.

Before I explain how this works, I must say that this process should only be done on initial synchronisation as you could cause issues if you change this parameter on existing Azure AD instances. More information on the limitations and risks of doing this can be found here: http://social.technet.microsoft.com/wiki/contents/articles/24096.dirsync-using-alternate-login-ids-with-azure-active-directory.aspx

When you configure AAD Sync, you can select which username your AAD users receive based on particular AD attributes, for example, the Primary SMTP address. This allows us to give users with strange/non-conformed AD usernames (such as 17047dd) a useable and memorable AAD username which is the same as their Primary SMTP address (David.Dixon). This configuration is performed in the User Matching section of the configuration, and you must change the userPrincipalName attribute to use the mail attribute.

UPN Matching in AAD Sync

If your organisation is planning to use ADFS, this poses a problem as the authentication is performed on premise, and your users cannot authenticate using their SMTP address if their UPN is different! To get around this, we can configure ADFS to use the mail attribute for authentication, as per the article below.


There are a couple of issues with this concept of user provisioning and authentication in Office 365, particularly when hybrid deployments are in use. The first is that when users authenticate against ADFS internally using IWA, the UPN will be the authentication mechanism. For domain joined machines this is not a problem (as long as the ADFS hostname eg. sts.doubledit.co.uk is added to Trusted Sites in IE) however if a machine is non domain joined or outside of the internal LAN, the user will receive 2 authentication prompts, one against Exchange Autodiscover (using the UPN) and another to Office 365 once the Autodiscover redirection has taken place (using the Primary SMTP). The second issue is that ActiveSync devices cannot support double authentications and will need to be manually reconfigured to use outlook.office365.com when the users mailbox is moved.

For these reasons it is generally good practice to only implement this solution for migrations with no autodiscover redirection in place, such as pure Office 365 or cutover/staged migrations. It can be successfully used with either AADSync/DirSync w/ Password Sync or ADFS.

Quite often, a users UPN will be different from their Primary SMTP address, and this is a way to allow your Azure AD users to login using their Primary SMTP address without changing the User Principal Name, reducing confusion for the users and creating a more consistent experience.