Office 365: Some quick notes on the end of support for Dirsync and Azure AD Sync

Earlier this week Microsoft announced the end of support for the legacy Microsoft Dirsync and Microsoft Azure AD Sync tools. Millions of customers out there use one of those two tools, or the new Microsoft Azure AD Connect, to sync their users, groups, passwords, etc, from their On-Premises Active Directory to the Azure AD.

After quite a few name changes, it looks like the Azure AD Connect major version is here to stay, and now it’s time to end support to the two older major versions, and make sure that all of them are updated and replaced with the AD Connect.

If you haven’t done it already, it’s time to read the Microsoft announcement, and to start planning that upgrade.

Now let’s take the key points of the Microsoft announcement:

  • In April 13th 2016 Microsoft announced the deprecation of both Dirsync and Azure AD Sync
  • The end of support for both versions of the sync tool was planned to be April 13th 2017. That date is now official with the announcement this week and in that day the official support to those tools is gone
  • Azure AD will stop accepting connections from both tools in December 31st 2017

The most relevant thing to take into account is that, either you upgrade those instances, or they will stop working by the end of this year.

Now that you are probably more than convinced to update your instance(s) for your customers or your infrastructure, let’s bullet point some thoughts to have into account when planning the upgrade:

  • Make sure you read the official Microsoft document to upgrade Dirsync to Azure AD Connect
  • Or make sure you read the official Microsoft document to upgrade Azure AD Sync to Azure AD Connect
  • You can only do in place upgrade from Azure AD Sync to AD Connect or from an old to a more recent version of AD Connect. In place upgrades from Dirsync are not supported
  • Microsoft describes the migration done with a parallel server, to replace the existing, as “Swing migration”
  • On a standard Dirsync or AD Sync instance, there’s nothing that you need to backup and restore in the new version. The new Azure AD Connect instance will do a fresh full sync after the installation. That full sync will bring all data from the local and the Azure AD. Replacing a Dirsync or an AD Sync instance should not require restoring data
  • The only exception to the above statement is when you have some type of filtering. Filtering can be done at the AD OU, Domain or attribute level. In those cases you need to make sure you replicate the filtering you have in place, into the new instance.
  • To learn more about Dirsync filtering click here.
  • To learn more about AD Sync and AD Connect filtering click here.
  • If you are not doing an in place upgrade, you need to be aware that the “downtime” on your sync instance has impact in creating new account and replicating changes to the existing ones (that includes password changes, if you have password sync enabled)

And that’s it. As simple as that. Start downloading the AD Connect version and it’s upgrade time! πŸ™‚

Let me know if you have questions.


Office 365 AADSync Password Sync failed: Event 611 System.MissingMethodException

Just recently I installed the Microsoft Azure Active Directory Sync, and faced a strange issue: Password Sync was not working. When a password was updated on premises, those changes were not being replicated to Office 365. I was installing AADSync on a Windows 2008 R2 Operating system.

The Microsoft Azure Active Directory Sync tool event ID’s, that you can see on your server event viewer, are actually very good and make the job of troubleshooting the tool much easier. There is a Microsoft support article on how to troubleshoot AADSync that has all the event ID’s and if you’re having problems with the tool you should definitely have a look into it.

On my scenario, I went to the event viewer and immediately detected the event ID 611, that was stating that the Password Sync was failing for my internal domain, as shown below:


I started trying to understand why, and here’s what I looked at:

  • I had no firewalls between the AADSync Server and the AD Domain controllers
  • Both servers were on the same subnet and with the local firewall disabled
  • AADSync was communicating with the Domain Controllers and all other tasks were working, except the Password Sync feature

So there was no way that this was about networking. So I circled back to the prerequisites of AADSync and found out what the problem was:

I had installed Microsoft .Net Framework 4.5, and it actually was good enough to allow me to install AADSync, and you can actually find a lot of guides out there that state that the 4.5 version is good enough, but when you’re installing on a Windows 2008 R2 it’s not, and I needed to install Microsoft .Net Framework 4.5.1.

Once I upgraded the .Net Framework to 4.5.1 everything started to work.

Office 365 and Dirsync: Why should you have at least one Exchange Server on-premises

For those of you involved in Office 365 migrations, the following question should sound familiar:

“Once all users are on Office 365, can we decommission all Exchange on-premises servers?”

When facing such question it’s good to have an official and clear answer from Microsoft, and that is the reason I am writing this post. A few days ago Microsoft published an excellent article on Technet, describing several scenarios and explaining when should you keep an Exchange Server on premises: “How and when to decommission your on-premises Exchange Servers in a hybrid deployment”

I highly recommend that you read the entire article, to better understand the several scenarios, but I will give you also my personal insight on this.

Although the article refers specifically to hybrid deployments, the dilemma of keeping on-premises Exchange servers or not, also applies to other scenarios, such as cutover or staged migrations, migrations from Notes or GMail, etc. Let’s consider the following example:

You are migrating from Google Mail to Office 365 (excellent decision btw πŸ™‚ ), you never had Exchange on-premises. Using the same password on-premises and on Office 365 is a requirement, so you install Dirsync, configure your Office 365 tenant, use MigrationWiz to migrate all your mailbox data from Google Mail to Office 365 (another excellent decision), change your DNS records to Office 365, and start using the service.

Do you need an Exchange on-premises? Yes.. you should have one.

Why? Because you have Dirsync and your objects are being synced from on-premises to Office 365.

What challenges will you face if you don’t have an Exchange on-premises?

Several, and it will depend on two factors. The first thing you need is toΒ have your active directory schema on-premises extended for Exchange. Meaning that if you cannot edit the Exchange attributes off an object, on Office 365, because that object is being synced from the on-premises AD, you will need those attributes to exist on the on-premises AD so that you can edit them there. Makes sense? Have a look at this article describing one of the issues you might face. The second thing you need is a supported way to edit those attributes on premises. Probably some of you thought “Why can’t i use ADSIEdit to edit those attributes on premises?”. Well the answer is simple: It’s NOT SUPPORTED!

In the Microsoft article you can read this:

“The question of whether a third-party management tool or ADSIEDIT can be used is often asked. The answer is you can use them, but they are not supported. The Exchange Management Console, the Exchange Administration Center (EAC), and the Exchange Management Shell are the only supported tools that are available to manage Exchange recipients and objects.”

So there’s your reason to have an Exchange on-premises. Microsoft describes several scenarios on the article, for you to better understand what your requirements are. But basically it all comes down to:

Is Dirsync a requirement? If yes then you need Exchange on-premises.

Is ADFS a requirement? If yes then you also need dirsync, so same answer as above.

The key here is to understand if the Office 365 objects depend and are synced from the on-premises Active Directory, and if they are you need to have your on-premises Active Directory extended and you need to have a supported tool to edit those objects on-premises. It’s as simple as that! πŸ™‚

The article also describes how to disable dirsync, if it’s not a requirement anymore, and with it you can also remove all your Exchange on-premises server.

What about the Exchange on-premises Server license? Do you need one?

Well if the following conditions apply you can request an Exchange Hybrid Server product key, with no additional costs:

  • You have an existing, non-trial, Office 365 Enterprise subscription
  • You currently do not have a licensed Exchange 2013 or Exchange 2010 SP3 server in your on-premises organization.
  • You will not host any on-premises mailboxes on the Exchange 2013 or Exchange 2010 SP3 server on which you apply the Hybrid Edition product key.

See this article for more details.

To summarize this post, the official answer from Microsoft, on when and why to keep Exchange servers on-premises after moving to Office 365, is an excellent resource you can use, provided that you fully understand the reasons behind it.

Hope this post was helpful! Thanks!

Office 365: Quick tip to list users with “” UPN due to invalid on premises configuration

Imagine this scenario: You are doing a migration to Office 365, with Microsoft Dirsync, but you’re not the one preparing the on premises Active Directory. Someone else is doing that work and dedicated to the local AD.

You tell them that all users to be activated on Office 365 need to have a vanity domain as their User Principal Name (e.g They prepare the Active Directory, you install and configure Dirsync and you do the initial sync. Now you want to make sure that no user got the username due to an invalid configuration on premises.

Note: If the UPN of the user on premises has a domain that is not validated on Office 365, the username on 365 will be the

What should you do? Well, in those cases what i do is, i list all the * usernames, export it into a .csv file, and send it to the Active Directory team for validation. The question should be: “Do any of the listed users need to be activated on Office 365, and therefore need the UPN fixed on premises?”

To build that list is quite simple. First you need to open the Windows Azure Active Directory Module for Windows Powershell, and connect to your tenant, by running the following cmdlets:

$msolcred = get-credential
connect-msolservice -credential $msolcred

See detailed instructions here.

Once connected, to get a list of all the users with an * username, run the following cmdlet:

Get-MsolUser |where-object {$_.UserPrincipalName -like "*"}

The output of the cmdlet above should be:


If you want to know the total number of users with the * username, run the following cmdlet:

(Get-MsolUser |where-object {$_.UserPrincipalName -like "*"}).count

The output of the cmdlet above should be:


Now, to export those users to a .csv file, run the following cmdlet:

Get-MsolUser |where-object {$_.UserPrincipalName -like "*"} | Select-Object Userprincipalname, Displayname, Islicensed | Export-Csv C:\Test\UsersWrongUPN.csv -NoTypeInformation

You will get a csv file, like the one shown below:


On the .csv file you will probably see users like the tenant admin, or service accounts. The tenant admin is a cloud user and doesn’t need to have the username fixed on the on premises Active Directory. The service accounts might be irrelevant also, and to prevent them from showing on Office 365 your solution would be to use OU based filtering on Dirsync. See here how.

All you have to do now is send the .csv file to your Active Directory administrators and have them validate the users that need fixing, the users you can/should filter to exclude from being synced to 365, and the users you can ignore and keep them with an * username.

Again this is particularly useful when you’re not the one preparing the Active Directory for your Office 365 deployment.