2016 Essentials Integration: Azure AD & Office 365
This post is part of a series on the Microsoft Cloud Services integrations that are included with Windows Server 2016 Essentials Experience.
To begin we will connect our local on-premises Windows Essentials Experience Server to the Microsoft cloud by enabling the Azure Active Directory and Office 365 integrations. Please note that this is very different from using Azure AD Connect or “full” Directory Synchronization.
Finally, we will add some users from our on-premises Active Directory to Office 365 (and vice-versa)! There are four basic methods for adding/managing users with this integration:
- Add brand new user accounts from the Essentials Dashboard
- Add Microsoft cloud accounts to existing on-premises users
- Import existing Microsoft cloud accounts to the on-premises domain
- Assign existing on-premises users to existing Microsoft cloud accounts
Before you continue with this step, be sure you have obtained an Office 365 subscription and at least verified your domain in the Office 365 portal.
Enable the integrations
From the Server Essentials Dashboard Home, choose Services from the left pane and Office 365 from the middle pane. Click the link to Integrate With Office 365 on the far right. This will also enable the Azure Active Directory integration at the same time.
A wizard will step you through the process. You will use your Office 365 administrator account to connect to your Microsoft Azure AD tenant; it may ask you to acknowledge that strong passwords will be enabled, and then after a short waiting period you’ll be done.
Managing user accounts with the Dashboard
Great! Now let’s try adding some users. First, check out the Office 365 portal. Navigate to the Admin console, and click Users –> Active Users on the left.
In this example, we only have one user so far–the global administrator for the Office 365 tenant. If you have setup an Azure subscription, you might also be able to login to the Azure Service Management portal and verify the accounts showing up in there also.
Method 1 – Add brand new user accounts from the Essentials Dashboard
Now return to your Essentials Dashboard and from the Home / Setup screen, and select Add user accounts.
Name the account, assign a password. As you continue through the wizard, make sure you assign the “real” domain name (instead of the “onmicrosoft.com” one). You will also have the opportunity to assign Office 365 licenses and set permissions / access for the Windows Server Essentials resources.
Now, let’s return to the Office 365 portal and refresh our view.
Ah-ha! Test User shows up correctly. What about Azure AD in Azure Service Management portal?
Well, that’s just slick!
Method 2: Add Microsoft cloud accounts to existing on-premises users
But what if you have pre-existing users on-premises and need to assign new Office 365 accounts to them? Easy! You can import them in bulk right from the Essentials Dashboard. Go to the Users tab and find the link on the right to Add Microsoft Cloud Accounts.
Select any accounts that you’d like to add, assign licenses, and so on.
Note that these users will be prompted to reset their passwords (on-premises) on next login–the new passwords will be immediately synced to Office 365. Be sure to alert them in advance of making this change!
Check out the Office 365 Admin portal to confirm they appear.
Method 3: Import existing Microsoft cloud accounts to the on-premises domain
You might also have pre-existing accounts in Office 365 that need to be provisioned on-premises in the Active Directory domain. For example, perhaps the users are coming from a Workgroup with Office 365. This too is possible by selecting the option to Import accounts from Microsoft Cloud service.
Select the accounts you want to import.
Do not fly past this last screen! As you can see, in this case the password is actually reset for the user immediately–you can click the link to view the password(s) in a text file. Once again, users will need to login on-premises first in order to change passwords before being able to get back into their Office 365 accounts. Be sure to communicate this change to them in advance.
Method 4: Assign existing on-premises users to existing Microsoft cloud accounts
There is no way to do this operation in bulk–it must be completed one user at a time. From Users, click on each user, then click Assign a Microsoft Cloud Account. Simply choose the option to Assign an existing Microsoft Cloud Services account to this user account. Note: users will be required to reset their passwords on next login, which will trigger a sync of the new password to the cloud.
Conclusions
We have now covered how to connect Windows Server 2016 Essentials to Azure Active Directory and Office 365, as well as the four primary methods of adding users from the Essentials Dashboard–creating them together from scratch, importing existing user accounts from a local domain, importing accounts originally created in Office 365, and finally matching up pre-existing on-premises accounts to separate corresponding cloud accounts.
Coming up, we will continue exploring the Office 365 integration features such as the Dashboard management capabilities for Exchange Active Sync policies and SharePoint libraries. Then we will proceed with connecting to other online services such Microsoft Intune, Azure Backup and Azure Virtual Network. We have plenty to explore, stay tuned!
Comments (37)
Thanks very much for this. Just started using Server 2016 Essentials and this was a great easy-to-use guide.
Thank you so much for this !!
Was searching for a long time about Windows 2016 Essentials integration with Office 365.
Is it possible to bypass or change the strong password policy requirement? Could I agree to it initially but after the Tenant admin has been configured, then change it back in the GPO and on Azure if needed? Our users will not be too happy about strong passwords even though I know it is important.
Also, since the password sync doesn’t happen until they change their password, could I change the passwords for them from AD to avoid confusing them? I’m trying to configure password sync for existing and future users without them being involved. Most of my users are very low-tech to say the least.
Thank you for your effort on these articles.
First, yes you can also just reset the passwords in AD yourself after linking the accounts. Second, technically yes, you can disable the strong password requirement using PowerShell when connected to your tenant: Get-MsolUser | Set-MsolUser -StrongPasswordRequired $false
However, based on the landscape today, I would recommend against that, and in fact, maybe even consider adding Multifactor Auth. Users have to get used to it; that’s the world we live in. Remind them that password leaks/hacks are very common these days, and that the statistics out there are just too scary to ignore. Don’t be low-hanging fruit, don’t become a statistic. The Internet is a world-sized neighborhood full of criminals trying to get at your data / assets / money. Don’t make it easy for them.
Yes, the admin can change the PW back, thereby taking the burden/confusion away from the user, but is there a way to stop the reset in the first place (strong password policy is fine with us, but the reset is a separate thing), at least with Method 4?
Even if PWs are set not to expire, it still occurs. I don’t quite follow why MS doesn’t simply check to see if the AD PW = ADD PW. If so, skip PW reset. That they might be different is the reason they’re resetting in the first place, right? I might be misunderstanding this.
Thanks
This is a pretty good question, but the truth of it is that MS cannot check whether the AD pw = AAD pw, since the passwords are stored as a non-reversible hash in both locations, most likely using different ciphers (so the hashes most likely would not match anyway). Essentials is also different than Azure AD Connect, which hashes the on-prem hash and sends it to AAD as a different hash yet. I am pretty sure that what is happening in the Essentials Integration is nothing quite as magical as all of that–I believe in this case it simply connects via PowerShell to the MSOL tenancy and writes in whatever you are telling it at the time. So the only way for Essentials to guarantee they are the same is if it is manually entered on-prem (and the same is entered in MSOL by the integration).
OK, that would make sense then, I hadn’t thought of that angle. So the best MS could do would allow you to decline the reset, but that would probably open the door for admins shooting themselves in the feet.
Hello Alex.
I did not see the panel ‘Get started’ in the dashboard.
I know it was visible during installation.
Since what time it was not visible anymore I did not know.
Did you have a clue how I can get it back or start the AD Azure integration via cli?
Kind regards
I’ve never seen it “disappear” before. If that were to happen to me, I think I would just close the Dashboard (or even reboot), then go back in. The first screen that appears should be the “Home” tab / Get Started, and the items listed there should be Setup, Services and so on. If you are brought to a different screen when booting up the Dashboard, you must live in the twilight zone.
Thank you for the great explanation!
If a user changes the password localy, it syncs to 0365 perfectly.
But the sync does not work if the user changes the pw in o365. Should the pw sync work also when changing in the cloud?
Thank you!
No, it is a one-way sync only from the on-premises environment to the cloud. However, if you have an Azure AD Premium subscription, you use Azure AD Connect, and enable password write-back. Check out this blog, for example.
Hi there :)
technically, you can’t – the problem is, that ad connect does not support Essentials Server.. so no way for pw-writeback :(
Correct, AD Connect should be on Server Standard or Datacenter, not Essentials.
Some users not showing up in “Distribution Groups” in Windows 2016 Essentials Dashboard (even though they are there in the office365 portal). Also same users’ profile returns error “No proper license can be found. Check your subscription and try again.” This error appears in the properties for that user under the Distribution Groups tab. This is also random, about 11 users out of 25 have this problem. I have enough licenses for entire company. Lastly, I recently upgraded to a new server and OS. Server 2016. Previous server was SBS2011. So I’m wondering if there is some SBS junk still attached to these users causing the problem. Thanks in advance.
Where I have run into this before, it has been a while, maybe three or four years ago with 2012 R2, the fix was either removing (take a break) and later re-adding the 365 license from the on-prem integration… or it was actually removing the local account, and re-creating, re-linking again to the existing cloud user. This is testing my memory but I think I tried both of these things, and one of them worked… Not sure if it is the same issue/cause that you are seeing now with 2016, but might be worth a try. Start with the less impactful (removing/readding cloud license). User may or may not notice this change, depending on when it is done. Also, have you checked the Essentials logs: C:\ProgramData\Microsoft\Windows Server\Logs?
Great guide to linking Essentials 2016 to O365.
However, when I imported the users, it imported all of my group mail boxes as users and I’m now over the 25 user limit.
I don’t consider a group mailbox to be a user and I doubt MS does either (?????).
How should I approach group mailboxes?
Thanks,
Dave
Do not assign licenses to any accounts that you intend to merely be “shared” mailboxes. You can also go into the EAC in Exchange Online and click the mailbox, and from there you can actually convert them to shared mailboxes (shared mailboxes do not require a license).
Hi Alex, this guide is great. Thanks so much!
For step #4: Does the forced password change only happen from the PC side? I’m going to set this up and we don’t always have all of our people in the office each day. Will it cause problems with their existing phone/tablet setup? Or does it just wait until they do an AD-authenticated login to force them to change password?
Correct, it is flipping the flag to force user to change login (on the local AD). So the next time they sign into the local network it will require them to change.
This guide makes it sound easy but I get in Server Essentials 2016 “An unknown error occured” after a long wait.
There doesnt even seem to be further information.
Make sure you’re fully patched, and check the google for solutions to that error. Otherwise, consider using Azure AD Connect instead.
Hello Alex,
I was in the process of migrating sbs 2011 to Windows Server essentials 2016. I migrating all my users to exchange online, setup their accounts with the alternative UPN name of mydomain.com and assigned licenses to the accounts in 365. I installed AD connect and synced users from active directory and then migrated mailboxes. Everything was work fine until I added the essentials box and integrated Office 365 and Azure directory. After a little while Essentials and Office 365 reverted the account names back to .local and changed the email default addresses back to [email protected]. If I go into Active Directory on premises and change each account back to the UPN .com name it syncs with Office 365, but after while goes back to .local again. What is causing this and do you have any suggestion on how to remedy it. Your help is greatly appreciated.
Steve
Note: you cannot use the Azure AD Connect tool and the Essentials tool at the same time. They are separate, and can only be used independent of each other. Most customers go with AD Connect, I think the Essentials integration is becoming less favored, even among very small businesses (however AD Connect is not officially supported on Essentials–Standard is required).
Hi! Great tutorial. I have a question you may help.
I need to connect a server 2012r2 essentials with office365 but in my case I need syncronize some users in the on prem server that the username is diferent from the office365 accounts that are alredy created
The method 4 works in this scenario? Can I syncronize accounts that belongs to each other but have diferent usernames?
Worth trying I suppose–though I always have my UPN match email address, etc.
I have found that if the administrator account used in the first steps has MFA activated on their 365 / Azure account… the authentication fails. When I deactivate MFA on the admin account then all is well.
Does anyone know how to overcome this?
Thank you for providing this tutorial. I thought I was going to have to upgrade a customers new Dell Server to Standard Edition, but this worked for me. I never use any of the Essentials dashboards and other features and only go with this version of Windows to save the customer a bit on CALS. In this case, I had already added the “routable” UPN to Domains and Trusts and all of our AD accounts matched the Office 365 account with first initial, last name. I am not positive if I made my life easier with these steps.
Hi Alex,
Windows Essential 2016 doesn’t support install Azure AD Connect, is there any way we can still install Azure AD Connect with Essential Server 2016?
You would need to have a member server that is joined to the domain running standard edition.
Thanks Alex, Will Windows 10 joined to Domain will work?
No. Check out the pre-reqs: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites
If I add a user in the dashboard who does NOT have an Office 365 licence does it still create the user in O365 just as an unlicensed user?
Right, but you shouldn’t use this solution anymore. Use Azure AD Connect only.
Hi Alex,
Great article, as always. I done this in with Windows 2012 with no issues. We just installed a new server running Windows 2016, however when I ran the wizard, I enter our Office365 global account, but I continue to get the same error message.”there was an issue configuring the integration ” I’ve done some research and have follow some advise to delete the “BecEndPointAddress key” as suggested by https://www.mirazon.com/windows-essentials-server-office-365-integration-breaks-windows-update/ with no luck. Have you seen this and can you point me where i can find a solution.
Thanks
You should no longer use the Essentials integration. They are simply not developing this, and it breaks frequently. Go to Azure AD Connect.
but using Azure AD Connect means you need an onsite exchange server, or to use Attribute editor to make simple permission or alias changes doesn’t it? Such a shame it takes away the ability to manage email properties in the cloud.
Yes that is correct, and the old essentials stuff is no longer something I recommend. So that is also not an option.