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!


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

  1. tom January 12, 2016 / 2:29 am

    What happens when migrating from an SBS server? Surely your not expected to buy an exchange server license just so you can use Dirsync..

    • AMVargas January 28, 2016 / 2:03 am

      Hi Tom, you are entitled to an Exchange on premises license if you have an Office 365 subscription with Exchange online. It’s your call to decide if you want to use Exchange management tools or just AD tools to manage the synced objects. In an SBS case I would not keep the SBS server and would build an Exchange for management.

      • Tom January 28, 2016 / 2:07 am

        You are only entitled for this if you are on an Enterprise Office 365 Licensing.
        “You can request a Hybrid Edition product key if all the following conditions apply to you:
        You have an existing, non-trial, Office 365 Enterprise subscription”

        So this still does not help Small Business Customers on Business Premium Licensing!


      • AMVargas January 28, 2016 / 2:41 am

        That’s right I guess Microsoft wrongly assumes that small business subscriptions are in general not using AAD Sync, which is not true at all. For sure getting an Exchange on premises license is not the way you would go, so i just suggest you extend the AD schema on premises to the latest version of Exchange, to make sure you have all the latest attributes, and manage everything from the AD tools.
        Extending the schema does not require a license or installing Exchange.

  2. Neil February 22, 2016 / 8:32 pm

    Great post!

    Regarding your highlighted scenario with no existing Exchange on-premises – I’m trying to find guidance for the initial setup/configuration of the Exchange sever. Before reading your post I spoke with O365 support; they advised me against your suggested setup due to “what can go wrong on many levels”. Instead they said I could manage the Exchange attributes using the Attributes tab in ADUC. I couldn’t understand why that would be supported and ADSI would not, and now I’m even less sure it would be supported based on the information in the technet article that you referenced.

    After my interaction with Microsoft I’d given up with this approach. But reading your post (which I wish I’d found earlier) has brought this configuration scenario back into consideration.

    What would you advise in an environment with 500+ existing mailboxes, currently without AD sync, but AD sync soon to be implemented? O365 support said that to manage mailboxes in this scenario I would need to add users in the exchange console as mail users (not mailboxes), and map the target addresses to the addresses. Does this sound right to you?


    • AMVargas April 7, 2016 / 12:01 pm

      Hi Neil,

      first of all sorry about the delay on responding. First of all you can use ADUC and ADSI to manage the users, but, it’s not supported, or at all recommended. I do know that many companies manage their synced users via ADUC, and move away from having Exchange servers on premises. My blog post was more about the recommended approach.
      Secondly about the recommendation from Office 365 support on how to add the users on premises, they are 50% right: If you have Office 365 cloud users and you are going to introduce Directory Sync in the mix, you need to create mail users on premises, so that you can SMTP match them with the ones on Office 365 (the alternative is not to use the Exchange console to do it, but you will need the SMTP address added to the on premises users on a manual way), and once you put Directory Sync in place the users in Office 365 will be converted to Synced. But you don’t need to have target addresses on those on premises mail users. From what you described you never had a Hybrid scenario, so target addresses on the format are not necessary.

      Hope that helps.


  3. pcamis April 6, 2016 / 1:36 pm

    Thank you very much for the informative post! I’ve been searching for info on this for days and this was one of the clearer explanations. Hopefully you can help to answer the related question I have.

    We performed a cutover migration from our local Exchange 2013 server to O365 about 6 months ago. In the time since, I have had our local Exchange server powered down and been able to manage O365 and create new users without trouble (by using Attribute Editor within ADUC). Based on your post, I don’t believe that I can decommission the local server in the standard manner because that would remove the Exchange specific attributes. But is there a way I can lighten the storage load of the existing Exchange server? I am happy to leave it powered down and forget about it, but it’s utilizing over half a terabyte (sizeable for a smaller business). It sounds dirty, but could I simply delete the VM and allow AD to believe that it continues to exist?


    • AMVargas April 7, 2016 / 11:55 am

      Hi Dan,
      removing the Exchange Server will not remove Exchange specific attributes. The Active Directory Schema has those attributes and if you remove the Exchange Server they will remain there.
      As you should know Exchange on Office 365 is constantly being updated which means that at some point you might need new attributes on premises that can only be added by extending the schema to new Exchange versions.
      As for your question about how to delete the server, you can do a clean uninstall if you want to, and I actually recommend you to go down that route, if you think that using the ADUC is good enough for you to continue to manage those Exchange objects.


      Antonio Vargas

      • pcamis April 7, 2016 / 3:53 pm

        Thanks very much for the quick response, Antonio! In prepping to remove the server, the first step I need to take is “Get-user | disable-mailbox”. I get the following warning:

        “Disabling mailbox “MailboxName” will remove the Exchange properties from the Active Directory user object and mark the mailbox in the database for removal. If the mailbox has an archive or remote archive, the archive will also be marked for removal. In the case of remote archives, this action is permanent. You can’t reconnect this user to the remote archive again.”

        This more than anything is what has held me up from decommissioning the server. Do you have any thoughts on whether this would be removing any properties required by O365 or whether this is just deleting properties related to the local installation of Exchange?



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s