Key Differences between Essentials Dashboard Azure AD Integration and Azure AD Connect
Windows Server Essentials Dashboard allows you to connect your on-premises domain to Azure Active Directory and Office 365. Arguably the best feature of this mechanism is similar to the primary benefit provided by Azure AD Connect or DirSync–the ability to sync local passwords into the Microsoft Cloud.*
But we need to understand something–the Essentials Dashboard integration is not the same as Azure AD Connect or DirSync. They are altogether different technologies, and they should not be blended together. In the screenshots below, you can see that from the point of view of the Office 365 Admin portal, Active Directory synchronization is not enabled, but the Essentials Dashboard integration is.
Let us explain a few key differences here briefly.
The Essentials Azure AD integration is not a Directory Synchronization
By default, Azure AD Connect will synchronize everything from your local Active Directory into an Azure Active Directory tenant in the cloud. And I mean everything. All of your accounts, and the attributes associated with those accounts (you can even sync extended/custom attributes if you want to). By contrast, Windows Server Essentials will not sync all of your attributes. Only certain types of information can be written into the cloud from the Dashboard: simple properties like account names, aliases, group memberships, passwords and account status (active, disabled, removed).
In a true Directory Synchronization scenario, if you make any changes to in-scope AD accounts that reside on-premises, then those changes will be reflected in the cloud upon the next sync (configurable down to 30 minutes currently). It doesn’t work that way in Windows Server Essentials. Sync is not performed on a schedule–instead information is written into the cloud only when you explicitly tell the Essentials Dashboard to do something.
For example, if you add an alias address to a mail-enabled account, Essentials does not update the proxyAddresses attribute in your local Active Directory and then perform a sync from there; instead, it simply writes these addresses directly into Exchange Online right when you edit them through the Essentials Dashboard.
Similarly when you add user accounts, deactivate them, change passwords and so on–the changes happen immediately, because there is no scheduled sync like you might expect with Azure AD Connect; instead it is just writing the information live into your Microsoft Online tenancy. Therefore, changes you make on-premises are going to be reflected instantly in the cloud.
With Azure AD Connect, you can also choose to enable OU or attribute filtering in order to control which accounts you decide to sync, or indeed, whether to sync certain attributes at all. Therefore, it is important to remember that the Windows Server Essentials Dashboard does not give you the ability to filter by attributes or OU–instead you enable Microsoft Cloud accounts on a per-user basis. Basically, if the integration is enabled, then you either have a Microsoft Cloud account associated with your on-premises account, or you do not. You will notice that it is still possible to create an on-premises account that does not have an associated cloud account, and vice-versa.
So… what are the drawbacks of the Essentials Experience integration?
For most SMB’s, there won’t really be any. In fact, it is rather nice to be able to make a change through the Dashboard and know that it will just take effect immediately both on-premises and in the cloud. Whereas with Azure AD Connect, you may find yourself waiting for a replication to happen, or forcing a manual sync with PowerShell after making certain changes.
Here I must highlight something that could be annoying, or at least confusing, to first-time Essentials administrators. Certain changes that you need to have reflected in both on-premises and cloud-enabled accounts can be made either in the Dashboard, or through traditional tools such Active Directory Users & Computers, while others can only be done successfully through the Dashboard. For example, I can change a password through either method, and the change will be available immediately on-premises and online. But deactivating an account, if I want the deactivation to take place for both, will require using the Essentials Dashboard.
For this reason, I usually just recommend that admins make all changes through the Essentials Dashboard, and avoid using the legacy tools, unless they they know what they are doing, and have good reason to do so.
Why you might want to use Azure AD Connect
If you plan to implement ADFS for single sign-on, for example, or enable password write-back, then you’ll want to disable the Microsoft Cloud services integration in the Essentials Dashboard, and just use Azure AD Connect instead. This will also allow you to utilize attribute filtering, and sync extended and custom attributes into the cloud, instead of just the most common ones, exposed through the Dashboard interface.
It is important to choose the tool which best aligns with your business objectives. For most of my clients, I usually recommend forgoing the Essentials Dashboard integration in favor of the more robust Azure AD Connect tool, but if all you’re looking for is ease of management and reliable password synchronization, then the Essentials Dashboard is a great option to have.
Footnote:
*If you want to peek under the hood a little more to see how Windows Server Essentials password synchronization works, open the Group Policy Management console from Administrative Tools and check out the GPO that it put in place. No such mechanism is necessary with Azure AD Connect, which uses a background service to sync directory information instead.
Comments (32)
This was exactly what i was looking for. Thanks Mate!
So, I have followed the instructions to setup the server essentials role, but with Azure AD connect installed. You mention above to disable the Microsoft Cloud services integration in the Essentials Dashboard, but how do I do that and doesn’t that just break trying to use the Essentials Dashboard and manage Exchange Online from on-prem? I’m just have a hard time finding this combination of setup other than this other post that is short on details at the end. I did try to disable the GPO and my dashboard services say N/A next to both AD Azure and Office 365 and my Essentials Email Service keeps stopping. https://community.spiceworks.com/how_to/122295-so-you-have-finished-your-office-365-exhange-cutover-migration-now-what-do-you-do-about-user-managment
Hi Mark, So this article’s purpose is to draw out the differences between two different solutions. Use either the Essentials Dashboard with Online Integrations turned on, OR use Azure AD Connect, in which case you should use an on-premises Exchange server for hybrid management. Technically MS does not support using ADSI edit or any third party tools to manage Exchange Online users/mailboxes. Either of the two solutions mentioned here are supported, however, they are mutually exclusive. If you enable Azure AD Connect, it is not supported to also use the Essentials Dashboard integration.
I was more or less following this How To as we used a 3rd party tool to do a cutover migration. It does sound like you were stating that it was possible to blend the two solutions as well.
https://community.spiceworks.com/how_to/122295-so-you-have-finished-your-office-365-exhange-cutover-migration-now-what-do-you-do-about-user-managment
Thanks, I’ll be sure to update the language to ensure that it is clear these solutions should not be blended, as they really are quite different, and manage changes differently as well. I would assume some of the changes would not even be possible through the Essentials Dashboard, since it would fail when attempting to write certain changes into the Office 365 tenant, when those attributes are locked for editing in the cloud (since the source of authority would be on-prem AD if using Azure AD Connect). It would be looking to the synchronization tool for it’s “authoritative” data, not the Essentials Dashboard integration.
Great article Alex, I’m new to Essentials and this has been helpful. Would you comment on this Microsoft document https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-prerequisites that states ‘ that states ‘Azure AD Connect cannot be installed on Small Business Server or Windows Server Essentials. The server must be using Windows Server standard or better.’? Your insight would be greatly appreciated.
Yes, this is accurate. I have never attempted install of Azure AD Connect on one of these versions of Windows Server, so I am not sure of the technical reason they recommend against it. However, in a migration path from SBS, you would install Exchange 2013 or 2016 (and possibly the Azure AD Connect tool) onto a member server such as Windows Server 2012 R2 Standard or 2016 Standard. Also, you would NOT use the Essentials online integration with Azure AD Connect exporting from the same directory. You would do one or the other only since they function very differently.
Interesting article, thanks. I’ve noticed even in Windows Server 2016 Standard that one can install and enable the Server Essentials dashboard. I’m going to do so within a test lab setup and see what sort of integrations with it and Azure AD connect are possible.
Thanks for the comment! I have quite a few other posts on this myself.
No doubt you’ve mentioned this somewhere, but it’s worth knowing that changes made to user properties in the cloud will be undone by the Essentials sync (I haven’t tested this in 2016 though):
https://support.microsoft.com/en-us/help/2992846/properties-of-office-365-users-revert-to-their-original-values-when-you-re-running-windows-server-essentials
Yes, this is a good point, Rick. Similarly when using Azure AD Connect for “true” Directory Synchronization, the source of authority is seen as on-premise AD, not Azure AD. And in fact, in that configuration, some things will be locked so that they can ONLY be edited on-premises (like adding secondary / alias email addresses). Whereas, with the Essentials Dashboard integration, the tenant is not aware of the local directory (from the perspective of the tenant, you are still in a “cloud-only” scenario without Directory Synchronization), so this can be particularly confusing to some people. Thanks for the contribution!
Thanks for this! Any insights or guidance on moving from Azure AD Connect to Windows Essentials? I’m trying to simplify the user management process to get it out of IT’s hands for the basics, but now I have them both on and its causing issues. Is there a migration path?
Yes, there is a migration path! See this article.
The word “simplify” reminded me to mention one thing that I haven’t seen discussed here, and that is when joining a PC to an Essentials/Essentials Experience domain via the browser, a “Connector” is installed to the PC. This Connector, which sounds innocent enough, installs a whole lot:
https://technet.microsoft.com/en-us/windows-server-docs/essentials/use/get-connected-in-windows-server-essentials?f=255&MSPPError=-2147217396#BKMK_5
This enables a raft of things that companies may or may not want (for instance, I really only care about Essentials’ Office 365 connectivity features, which are unrelated to the Connector AFAIK, and much less about what the Connector can do for PCs), but I mention it because the Internet is filled with years and years of threads about Connector breaking when the OS is upgraded. Believe it or not, this continues to this day with Win10 1703, which continues the policy of uninstalling the Connector as part of the upgrade.
Given MS’s recently-stated intentions of issuing major upgrades (full-build installs) of Win10 twice a year, this means that twice a year, poor admins–if using the Connector in the first place–will need to reinstall it on each PC. I’ve seen some threads recommending that you actually uninstall it before the upgrade, and then reinstall it afterwards. Etc. There are variations on any number of issues over the years.
So, this end of the equation is anything but simplified. I’d love to hear your thoughts on this, in particular, any repercussions of joining PCs to the domain manually (clearly, you lose some features, like PC backups).
Yep, there are some things to be aware of if you’re using the entire stack of products built-in to Essentials. If you just want the Azure AD / Office 365 integration, then you do not have to use the connector at all. The main reasons for the connector are: Anywhere Access (RDP to your PC from outside the network), and PC Backup (which in my opinion is fairly useless these days if your machines are setup correctly–with no local data). Honestly we have less and less clients requiring these features as time moves forward. For example I tend to deploy more laptops than desktops, more OneDrive for Business than redirected folders. If they want Remote Desktop, then I could just deploy the RDS role onto another VM (I usually deploy Standard anyway nowadays). But if you want all the “goodies” in Essentials that integrate with the PC’s, then it is just like anything else you deploy into the environment–another thing to watch over, to maintain. For 99% of deployments I do these days, I’m typically not adding that complication, and just joining PC’s manually–they will function like any other domain-joined PC.
That’s really interesting, since in my travels around the Internet it seemed like everyone using Essentials was using the Connector. Apparently not! The more I read about the Connector, the less I could understand why it was so ubiquitous..
We feel the same way about the extra features. Pretty much a “no” right down the line for me, with the possible exception of the Health one, but there are other things (like Lansweeper free) that probably do a lot of that anyway–and without any client complications at all.
That is good to know about Connector. My initial reason for going down this path was to centrally manage Windows Backup to my NAS – i’m amazed how hard this is to handle without resorting to a 3rd party. Good to know its quite fragile and I should probably stick to 3rd parties who are somehow more reliable at backing up than the people who actually created the OS….
I took a brief look at Azure Backup but its another “looks good on paper but is thoroughly confusing and overly complex in action” that is common with Azure.
What Microsoft provides “out of the box” with Windows Backup and the like certainly leaves something to be desired. I do not rely on this for any of my clients, and I agree a third party backup does seem like the best option still. I am hoping that the Azure Backup continues to evolve.
Another interesting free option is Microsoft Azure Backup Server (MABS), which would require a separate piece of hardware that could run a Windows OS and this software, which is basically a “free” version of System Center Data Protection manager. Honestly this hardware could be like a “tiny” desktop computer even, with iSCSI access to a NAS for storage. MABS allows you to backup to disk (the MABS server itself), and also send the backup data into an Azure storage account. This is a little better because you can centralize management of the backup and get it offsite, whereas the MARS agent (setting up Azure Backup individually on servers & computers) really has no central management.
Thanks! I will have to check it out some time.
I jumped the gun and just went ahead and tried connecting this to Azure AD and O365. Except I was already using Azure AD Connect and things went south in a hurry. Essentially it changed all my O365 accounts from @domain.com to @domain.onmicrosoft.com and prevented everyone from logging in! This was no easy fix and involved a powershell script to rename the UPN inside O365. This then broke the AzureADConnect and that took more time to fix. But I’ve disconnected Essentials and AADC is now working again.
I’d like to try again as the Essentials Dashboard for user management is much more inline with my use case than AADC sync is. However, that was not a fun few hours.
Yes, as I mention in the article, these two should not be used together. Another thing: when you go to setup Azure AD Connect, the best practice is to update the UPN suffix on-premises for all user accounts to match the email domain (e.g. domain.com vs. domain.local). These instructions are in my articles on how to setup for a hybrid migration also. Sounds like everything is working w/ AADC now, in this case.
I read your other article too late :) I may try again. I did have AADC working with my domain suffix set appropriately to domain.com for all accounts. However, at some point the Essentials install changed every account in AD to the domain.local suffix in addition to messing up the O365 domain to the onmicrosoft.com one. It was very busy changing everything behind the scenes with very little input from me. I can’t tell if it was the “Integrate with Azure Active Directory” feature or “Integrate with Microsoft Office 365” feature that did the damage, or perhaps the combination of the two.
THANK YOU for taking the time to write this article and sharing your experience! This is exactly what I was wanting to know and should be required reading, if not a link right on the Dashboard/Desktop of a new Windows Essentials install. :)
Thanks for the really informative article. Would using AADC allow me to have multiple Essentials servers integrate with AzureAD/Office 365 authentication in a single tenant account? In my scenario I have a client with three offices. One already has Essentials 2012, the other two are currently messy workgroups that I’d like to convert to Essentials 2016 ADs so I can apply local group policies, and unify authentication with their Office 365 user accounts. I look forward to your reply.
I would not do that. Technically there is a supported topology where you can have multiple AD forests syncing to a single tenant, but the trick is to use a single AADC sync server that has access to all of the forests. The goal in this scenario is to have each individual user represented only once, but the architecture required for this would be fairly complex.
What would be much easier, from the sounds of your situation, is to simply have one AD forest. Meaning you would have VPN tunnels between the locations, and user accounts for everyone in all the offices in that one AD domain. Then you coudl sync everyone from a single domain controller or member server in that domain. If you convert to Windows Standard, you would even be able to create AD “sites” and deploy DC’s at the remote offices, although for very small companies this may not be necessary, as long as those remote offices can access the “HQ” server over the VPN.
I was wondering if you could answer this question: I have an Exchange 2013 server and have performed a cutover migration to Office 365. Since then I have installed a new server with the Essentials Experience installed and it is integrated with Office 365. I now want to remove the Exchange server entirely. Do I have to convert the mailboxes to mail enabled users like you have to do with AD Connect or can I just disable all mailboxes? Thanks!
The important thing to remember with Essentials is that there is no synchronization taking place. You are actually in a cloud-only scenario from 365’s perspective, so if you manipulate or even delete proxyAddresses attributes on-premises, they are not really synchronized anyway, so there should be no impact from simply uninstalling Exchange (which removes those attributes). When you link on-prem users to cloud users, and then make edits to user names or for example add aliases, the tool is actually writing the changes live into the tenancy, rather than writing the values on premises and then syncing them. So you can blow away Exchange completely without impact to the cloud users.
I set up Essentials following this guide which is great! I linked up the accounts to the tenant counter-part and users were prompted to change their password at next login, however it seems that Office 365 didn’t sync this change as the Office 365 password remains different from what the user just changed it to. any ideas?
Have you checked to see if disabling/re-enabling the Azure AD / Office 365 integrations has any impact? Also, did you check the Essentials logs?
Hi Alex,
We seem to be having an issues with changing passwords within AD and them syncing with Azure. We have 2 DC’s and a separate member server running the essentials experience role, all server 2016. Changing passwords through the essentials console works, however when changing an expired password through AD, this isn’t reflected in Azure/O365.
Any thoughts?
Use Azure AD Connect instead, its way better.
Hi,
We have a customer that has a single 365 tenant with an essentials servers at each of their individual sites. Would we be able to use the essentials dashboard to sync the site-specific users to 365? I.e bob works at essentials server “site1” and John works at essentials server “site2”. If each server only syncs its own users and they are all unique, would this be supported? I am guessing not but would really help us out if it was possible.
It sounds unlikely to work. I believe that you can only sync a single instance of the Essentials dashboard to any given Azure AD tenant.