Coconut is a regional airline that is headquartered in Cyprus with branch offices located in several cities throughout Europe.
Until now Coconut has utilised an on-premises Microsoft Exchange server solution to provide email for all employees. Coconut has also extensively utilised public folders to provide an archive facility for various distribution groups.
Coconut are planning to migrate all of their mail services to the cloud, hoping to benefit from the advantages that Exchange Online could potentially bring them.
Coconut have decided to migrate to a hybrid Exchange 2016 scenario.
Once all data has been migrated, Coconut plans to decommission all the older Exchange servers. They will keep a single Exchange 2016 server to provide a supported method to manage Exchange Online. This Exchange 2016 server will also be used to relay mail from several in-house applications.
After completing the migration, Coconut would like to continue to utilise a synchronised identity model (with password synchronisation) via the Azure AD Connect tool.
During one of the planning sessions, a question was asked about whether Azure AD Connect could be installed on the same server as Exchange.
While it’s a bit uncommon to see Azure AD Connect and Exchange installed on the same server, there is no technical reason to stop you from doing so.
It might even make sense in your environment because you would have less virtual machines to license and manage.
There are a small number of reasons that you might want to keep Azure AD Connect and Exchange separate but none of these are compelling:
- After you create a hybrid deployment, you are obligated to keep both components (Exchange and Azure AD Connect) up to date. Updates to these components are released on a different schedule. This differing schedule by itself is not an issue because you usually want to reduce risk by keeping the number of changes that you perform at any one time to a minimum. However, when you want to perform an update to either component, you may need to schedule an outage for both of them.
- There is a small chance that the requirements needed by either component may change in the future so they are not compatible.
- You may want to keep servers that provide identity management functionality separate from servers that provide mail functionality. This could be because of administrative boundaries (different people administering different types of servers), ease of monitoring, ease of troubleshooting and increased security.