First and foremost, you need an on-premises Exchange Management Server, Microsoft even provide a free key to license it. If you're moving away from on-premises Exchange then this isn't such an issue, but if you're moving to Exchange Online and haven't had Exchange on-premises before this means you need to plan for the deployment of an on-premises Exchange Management Server. Why? You simply won't be able to fully manage your objects in the Exchange Administrative Center in Office 365 with directory synchronisation in place. Instead you add email addresses, or enable external access to distribution lists by making that change on-premises. Directory synchronisation via AADConnect then replicates that change. You can get around it - but you won't be supported!
So when I engage a customer what are the high level actions I check for? Here's my definitive list.
Check if directory synchronisation has been enabled in Office 365
The first is rather easy to check for, you simply check in the Office 365 Admin Centre, if it's already in place then we need to understand if it's actually being used - we can check for synchronised user and group objects, or if it's not in use, understand who's turned it on and where they may have got to. Beware that if you disable directory synchronisation it can take up to 72 hours to disable! I have verified this from disabling the feature in tenants, I have seen anything between 12-60 hours.
Gather data on Active Directory Domain Controller OS Version
So why do we need this? If we plan to utilise features like password synchronisation, and we plan to home the AADConnect agent on a Domain Controller then we need to ensure they are Windows Server 2008 OS or above. Further, it needs to be a writeable Domain Controller, and there's also pre-requisites for features like password write-back. You can see the check list here.
Gather data on Active Directory Domain and Forest functional levels
If we are planning on introducing an Exchange 2016 management server - some bearing on Forest and Domain functional levels will need to be understood.
Password write-back to on-premises only requires DFL/FFL of Windows 2003, but Windows 2008 Domain Controllers with SP2, however if you are planning on having an Exchange 2016 management server with CU3 or later, then you must have DFL/FFL of at least Windows 2008.
This means that you may find you need to upgrade your on-premises Active Directory to get the features you need. This could be as easy as upping your DFL/FFL levels, to having to actually introduce new Domain Controllers to be able to achieve this.
Gather data on Active Directory sites
I gather data on Active Directory sites to help understand the network topology. Where's the best place to house AADConnect? Which location? Where are the most users homed? Does the customer require a staging AADConnect server - if so which location would be the best to home it?
Gather data on Active Directory Unique Principal Name (UPN) utilisation
I see a lot of customers still utilising .local domains, or domains that have no bearing on their actual routable domains in Office 365. The best move forward is to have the on-premises users have the same UPN as the desired sign in for Office 365. So if the user on-premises is email@example.com and they have a cloud user account of firstname.lastname@example.org, there's a planning excercise here to understand what domains are in Office 365 and what UPN suffixes need to be added to Active Directory. We then plan the change to update on-premises to email@example.com
Number of Objects in Active Directory
We gather the number of objects in Active Directory not so much as an excercise for any limits in Azure AD (there's an initial 150k object limit which can be removed for Office 365 subscriptions), but for SQL licensing for AADConnect, if it's over 100,000 objects we need to be looking at using SQL Standard or above - rather than the free version SQL Express version that is auto-installed with AADConnect otherwise.
AD Replication Health
Checking the health of your AD goes without saying - you need a healthy AD without replication issues to ensure all necessary replications occur and are synchronised to Azure AD. Fix and resolve any issues you find! There's no point replicating to Azure AD if your own intersite and/or intrasite replication is broken!
Check for Deployment of Exchange
If the customer is coming from Exchange and migrating to Exchange Online, this isn't so hard to immediately check and ratify. However, what if the customer has come from Notes, Zimbra - or even a hosted exchange platform or resource forest model?
To be in a supported state you need an Exchange Management Server on-premises. Sensibilities dictate this would be an Exchange 2016 or possibly 2013 management server. This will give the customer the best possible experience in a unified UI and Powershell cmdlet experience across both on-premises Exchange and Exchange Online.
One of the things I have encountered countless times is the incorrect removal of Exchange Server from on-premises. One customer had three Exchange 2003 Servers that were simply turned off, removed from the racking and disposed of - and on-premises Exchange was classified as removed. Upon performing discovery, it became clear this needed correct removal - and further investigation showed nearly every long standing employee still logically had a mailbox!
Check Exchange Version
Following on from checking for previous Exchange deployments, it's important to understand the version of Exchange currently on-premises and the steps needed to put an Exchange 2016/2016 Management Server in-place. As well as the previously mentioned similar management experience you also do not have to worry about upgrading the management server anytime soon - where for example if you had an Exchange 2010 management server, this is going to fall out of supportability long before Exchange 2016.
Check for Mailboxes on-premises
Checking for mailboxes on-premises, when all users are known to be in Exchange Online will require clean-up of the on-premises mailboxes prior to implementing directory synchronisation. It can be done afterwards, but it will likely get forgotten about or missed.
Check for Mail Enabled Users
When planning for the Exchange management server, ultimately all your synchronised users will be Mail Enabled users - this is so they show up in the on-premises Exchange Administrative Center and you can easily modify the Exchange attributes - allowing Azure ADConnect to synchronise them to Azure AD and subsequently your EXO tenant.
Check for Mail Enabled Distribution Groups
Are you planning on synchronising your on-premises distribution lists, or will you be utilising Cloud only? Or will you decide to only synchronise certain ones for security management, and implement Office 365 Groups in your Exchange Online deployment?
Most of this comes down to what you understand, or help the customer understand, what they are ultimately trying to achieve. If the customer is already in Exchange Online and you see a completely different set of security and distribution groups on-premises to what's in Office 365 - you may recommend to the client to just synchronise users.
Check Accepted Domains in Office 365
Are all domains verified in Office 365? Is anything unnecessary or incorrect? Ratify the list here as this will have a bearing on what you assign to on-premises.
Check Accepted Domains
When deploying the Exchange management server ensure you understand the Accepted Domains in Office 365 - you'll need to add these in the on-premises deployment so you can easily additional SMTP addresses to objects.
Check if directory synchronisation has been enabled in Office 365
If Directory Synchronisation is already in place, this will allow you to plan clean-up activties or additional actions, or allow you to disable it whilst you made a more solid action plan to perform directory synchronisation for the tenant. Beware it can take up to 72 hours to disable this!
Validate recommended AADConnect server configuration
So what does the customer actually want when synchronising their on-premises identities to Office 365? Does the customer want just object synchronisation? Does the customer want password synchronisation also? You will find most customers will benefit greatly when their on-premises username AND password also accesses their Office 365 resources. A unified password is a must. However understand if your customer has any compliance or regulatory requirements - or just has cold feet about Azure AD holding the password hash for all their user accounts.
If password synchronsation utilising the password hash doesn't work for them - steer them down the route of pass through authentication. This will allow for a unified username and password experience but push the authentication of the user back to their on-premises Domain Controllers. It's a much simpler story to tell and ultimately implement than ADFS.
You can also understand your customers availability requirements, is one AADConnect implementation sufficient or would they also desire a server in 'standby' mode, ready to take over (manually I might add at this stage), if the primary server suffers downtime for an extended period of time or cannot be recovered?
Proxy Server usage
Does the customer force all server traffic through a proxy? If so you need to understand this. Does the proxy for example require authentication? If it does you will have to configure web.config files on the server that will home AADConnect to ensure a succesfull deployment.
IDFix is a Microsoft tool that will parse user and group objects and report if they have issues that would require clean-up prior to being able to succesfully synchronise. It will pick up on the aforementioned UPN issue - but it's also good for trailing spaces, or objects with duplicate attributes - for example a UPN or proxy address.
I hope this goes some way to helping you as a consultant, IT admin or inquisitive Office 365 customer on the steps you should be going through to succesfully deploy directory synchronisation for your on-premises Active Directory and Office 365 tenant.
This should provide you the absolute best and reasoned approach to deploying it, capturing any issues in the planning stages, and providing a nice easy and best practice approach to the deployment.
Good post. I only miss authentication type. PTA, ADFS, Pass Hash.
That's a good point Rommel. I left PTA and AADSSO out as they were in preview.
I'll make a part 2 and cover ADFS, password hash, PTA and AADSSO. Thank you!
Post a Comment