A few weeks ago, I wrote a blog post here covering how to deploy Azure Active Directory Connect 1.1. Due to popular demand, today I'm going to circle back and review some of the advanced configurations of AAD Connect as well as some troubleshooting tips to cover you in case you run into a hitch with your AAD Connect deployment.
Since there is a lot to cover, and I have limited space in which to do it, I’m not going to go super deep into each of these topics. Instead I’m going to give you a high-level overview. I’ll try to link to resources where you can get more information on each topic as appropriate, and you can reach out to me via the comments below or on Twitter if you’d like me to answer any specific questions.
There are a number of reasons why an organization may want to sync a subset of Active Directory attributes into Azure Active Directory. AD attribute filtering can be used in conjunction with account filtering, or it can be implemented by itself.
The first reason you might want to set up attribute filtering would be in the instance of a service that is deployed on-premises in a way that might cause problems with your Office 365 tenant. If, for instance, your organization wants to move Exchange into Office 365 but you have a deployment of SharePoint that includes customizations that may cause problems in Office 365, you can configure attribute filtering to keep your SharePoint-related account attributes from being copied into Azure AD.
Another reason an organization might choose to implement attribute filtering is security. Organizations may choose to synchronize only the absolute minimum required information with Microsoft, and if your organization is not implementing Skype for Business, you may decide not to synchronize the Active Directory attributes for Skype for Business.
Finally, it’s possible your organization has multiple Office 365 tenants and you want to set up specific Office 365 services in one tenant but not another. While this is certainly going to be a rare corner case, I can imagine that someone is going to want to try this configuration.
Configuring attribute filtering can be done via the Customize synchronization options menu.
On the optional features menu, select the Azure AD app and attribute filtering check box.
From there, you will have the option to choose which applications you synchronize information for.
Or you can specify specific Active Directory attributes you do or do not want to synchronize on the next screen.
I would advise against going so far as to filter out specific attributes unless you are really sure you know what you’re doing.
In larger organizations, it may not be necessary to sync all user accounts into Office 365. Maybe only a subset of users will be migrated into Office 365 or maybe you want to filter out service accounts. Whatever the reason, there are three main options for how to prevent groups of accounts from syncing into Office 365: domain filtering, OU filtering, and attribute filtering.
I’m not going to have space in this blog post to go through the details of all that filtering. There is a series of posts of my site that covers all the details. Here is additional information on Azure AD Connect 1.1 Filtering.
The function of AAD connect does not really demand complex HA or DR features. AAD Connect takes user accounts, and maybe passwords, from your on-premises Active Directory and copies them into Azure Active Directory. If your AAD Connect server goes down, you don’t lose any data or very much functionality. There really isn’t any need for a high availability configuration for AAD Connect.
AAD Connect does give you the option to set up a server in staging mode. Staging mode allows you to setup a “spare” AAD Connect server as a hot stand-by. If your primary AAD Connect server goes down with some unrecoverable error, you can activate your stand-by AAD Connect server to take over.
This may not be a productive use of time or resources if you have a default deployment of AAD Connect, as it’s pretty quick and easy to standup a new server. If, however, you’ve made a bunch of customizations or the sort we are talking about in this blog post, it might be wise to pre-stage a second AAD Connect server that you can put into production quickly in the event your primary server becomes unrecoverable.
To configure an AAD Connect server in staging mode after it has been deployed, select Configure staging mode from the additional tasks menu.
Clicking through that wizard is pretty self-explanatory, so I’m not going to take a lot of space here going through it. To convert the server to an active AAD Connect version, just re-run the configure staging mode wizard and uncheck the box to enable staging mode.
Starting with version 1.1 AAD Connect has an auto upgrade feature. Personally I am a little conflicted about this feature, so at this point I would recommend you exercise caution while using it.
Auto upgrade is only enabled for AAD Connect if you do a default deployment. In fact, you cannot currently enable auto upgrade if you do any form of customization in the setup wizard.
If you do deploy AAD Connect with the default settings, then auto upgrade will be turned on. If you’d like to verify if auto upgrade is turned on, you can use the following PowerShell command on your AAD Connect server
Get-ADSyncAutoUpgrade
As you can see in the screenshot below, I have auto upgrade turned on for this lab AAD Connect server.
As of this writing, Microsoft is tightly controlling the automatic upgrade rollouts for AAD Connect. If your AAD Connect server is set to auto upgrade, but see you are still a version (or multiple versions) back, fear not — you’ll be upgrade eventually.
Should you want to turn off auto upgrade, you can run the following command:
Set-ADSyncAutoUpgrade Disabled
After deploying AAD Connect, sometime we will find some accounts are not synchronized into Azure AD. Often these errors can be identified and resolved by the IDFix tool.
IDFix will query your on-premises Active Directory and identify a number of different configuration errors that will prevent user accounts and groups from being synchronized into Office 365. IDFix can also resolve this error by changing conflicting attributes to new values. While this can be a time saver, it is a features that should be used only with extreme caution.
I recommend you run IDFix before deploying AAD Connect. Doing so can highlight any potential problem areas in your Active Directory account configurations, and give you a little extra time to sort them out.
By default, only the person who does the install of AAD Connect will have rights to manage the installed AAD Connect server and sync engine. To configure additional administrators, add those accounts to the ADSyncAdmins group.
It’s important to remember that AAD Connect does absolutely nothing to assist with licensing your users once their accounts are copied into Azure AD. You still need to go into the Azure or Office 365 portal and manage the licensing yourself. In large organizations, this can be a considerable undertaking.
Additionally, fellow MCM/MVP Chris Goosen provides helpful information on getting you started on a PowerShell-based automation solution for your Office 365 licensing tasks.
There are a couple of additional configuration options that I’m not going to have space here to cover today: using AAD Connect to configure AD FS, and using AAD Connect to support multi-forest configurations. We’ll save those for a future blog post, but feel free to ask questions below or reach out to me on Twitter @MCSMLab.