I get a lot of questions regarding Office 365, Directory Synchronization from an on-premises Active Directory and decommissioning Exchange servers on-premises. A lot of customers want an Active Directory on-premises, they want Mailboxes in Office 365 and they don’t want an Exchange server on-premises anymore.
So the question is basically “Can we decommission our Exchange servers after moving to Office 365?”
It is an easy question with an easy answer, and the answer is “No, you cannot decommission your last Exchange server on-premises”. Let me explain why.
Source of authority
In an earlier blogpost I already discussed the three types of Identities:
- Cloud Identities.
- Synced Identities.
- Federated Identities.
With Directory Synchronization (through Azure AD Connect) in place we’re talking about Synced Identities or Federated Identities. Important to note is that the Source of Authority, which means where the identities are managed, is the on-premises Active Directory. Account are created and managed on-premises and not in the cloud. This is also true for properties of the accounts.
Suppose we have the following situation. There’s an Active Directory environment, no Exchange servers on-premises and there’s an AADConnect server for replication purposes to Azure Active Directory as shown in the following picture.
Figure 1. Azure AD Connect is synchronizing user accounts to Office 365.
The internal domain is Exchangelabs.local, the external domain Exchangelabs.nl is only verified in Office 365 and set as the default domain. In the on-premises Active Directory there’s an OU=Accounts where objects are in various OU’s like OU=Groups, OU=Users, OU=Contacts etc.
Figure 2. User accounts in Active Directory Users and Computers. Please note the different settings in the E-mail Address column.
The installation of Azure AD Connect automatically detects that there’s no Exchange server installed (the Active Directory Schema is not even prepared, so it’s truly a green-field Active Directory) and thus the Exchange Hybrid option is not available in the setup application:
Figure 3. Azure AD Connect is configured with Password hash synchronization
The only option that’s selected is the Password hash synchronization. The Organizational Unit OU=Accounts as mentioned before is the only OU that’s selected for object replication, so after finishing the setup application and the initial synchronization the user account will appear in the Microsoft Online Portal.
When the Office 365 (E3) licenses are assigned to the replicated user accounts, one strange thing is visible. The user account is exactly as expected, i.e. firstname.lastname@example.org, but the primary SMTP address does not reflect this, and is actually based on the tenant name, i.e. email@example.com as shown in the following screenshot.
Figure 4. User’s email address is set incorrectly. The tenant email address is set as primary SMTP address.
When you want to change the email address from the tenant email address to the regular email address you’ll see the following warning:
Figure 5. It is not possible to change the user’s primary SMTP address
The Set as Primary button is greyed out, so it’s not possible to change the email address.
When you try this in the Exchange Admin Center (in Exchange Online) it doesn’t work either and you get the following error message:
The operation on mailbox “Bram Wesselius” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’, ‘EmailAddresses’, can’t be performed on the object ‘Bram Wesselius’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
Figure 6. An error message about ‘write scope’ is shown when the user’s Email address is changed.
Now it gets interesting. Have a closer look at Figure 2. You will see that user BWesselius does not have an email address set in Active Directory, but user Ahaverkamp does have an email address. This is not an Exchange email address (since Exchange is not installed on-premises, Active Directory doesn’t have the Exchange schema changes applied, it really is a green-field Active Directory) but the email address is set in Active Directory Users and Computers.
Figure 7. The user’s Email address is set in Active Directory Users and Computers.
When the Email address is set using Active Directory Users and Computers it is synchronized correctly to Office 365 and used in Exchange Online as the user’s primary Email address.
So, now we know how to set the primary Email address when the user is provisioned in the on-premises Active Directory. Despite the fact the user now has the correct primary Email address, it is still not possible to change the user’s Email address in the Office 365 portal or Exchange (online) Admin Center.
This behavior is caused by the fact that the account in this scenario is a Synced Account. The source of authority is the on-premises Active Directory, and this is where all changes need to be made. Once changed the new settings are synchronized to Office 365.
So, to change the primary Email address for user BWesselius it’s a matter of adding the Email address to the mail property in Active Directory users and computers and wait for synchronization to happen (or force directory synchronization). If you want to change an Email address, for example for user AHaverkamp you can just change the mail property of the user in Active Directory Users and Computers.
So, now we know how to create a user in the on-premises Active Directory and have the Exchange Online primary Email address set correctly. In my next blog I’ll talk more about an on-premises Exchange server.
13 thoughts on “Office 365 Directory Synchronization without Exchange server”
It is possible but not supported by Microsoft. Editing users and mail addresses is done via ADUC/ADSIEDIT with mail & proxyaddress attribute. Also managing groups as admin and users that are manager of a group lose this functionality cause the ECP (management tool) is gone.
In this specific scenario it’s not possible (yet) since Active Directory does not have any Exchange attributes (which is typical after a Groupwise or Notes migration). My next blogs will cover that, but due to some unforeseen ‘undocumented features’ in Exchange Online it takes a bit longer than anticipated 😉
Cool, will you also cover the soft & hard-match and the “msExchRecipientTypeDetails” & “msExchRemoteRecipientType” scenario’s?
Not in the two posts I have in draft, but mail your wishlist to my email address: ‘feedback’ at ‘jaapwesselius.com’ 🙂
Thank you for the nice write ups.
Just to clarify on your post, about how we feel about implementing Office 365 ADDConnect and no exchange presence.
Some companies move from managed mail as you have mentioned and that’s when we get this scenario. Some companies may also be on managed AD and so applying the Exchange attributes is not an option.
We want to sync users and defiantly want SSO. So we are able to implement AADConnect, The attributes used to set the mail and proxyaddresses are included in a Green filed AD. As Office 365 consultants editing Attribute’s of users accounts is bread & butter so not really an issue.
So I don’t see the shortfall here, the service desk will have to manage Addresses in the users attributes and then contacts, DL’s and shared mailboxes are created and managed in Office 365 along with administering mail flow permissions.
AADConnect is not going to change away from the default Mail and porxyaddress attributes so no worry there either. People just need to remember to set them. If there is a problem Office 365 may tell us its not supported and not help us. My experience when passing a problem over to MS support that I cant fix never goes far anyway.
What have I missed and why should I not implement this solution?
The ‘problem’ is in the non-supported by Microsoft. Now, for you and me that’s not a problem because we can solve most issues, as you already pointed out. The same is for the ADSI Edit (or anything else) solution, again you and I know how to deal with that, but the average customer doesn’t, and I preferably don’t want my customers to fiddle around with ADSI Edit 🙂
But other than that it works like a charm.
Okay perfect, was just checking someone had not found a show stopper feature that couldn’t be used when someone does not have an extended schema and running AADConnect.
Remember for my scenarios, I cant have extended schema with a hosted AD. So client can just use attribute editor for those attributes (mail,porxy) no need for ADSI.
What is ” a Green filed AD.” ?
Green-field? A brand new deployment, without any applications yet
Sorry, was trying to point out you spelt ‘field’ wrong.
Great article, BTW
So, I have the necessary field in Attribute Editor in ADUC – ProxyAddresses. All mailboxes have been migrated. Public Folders moved over. Mail is flowing as it should.
Will decommissioning Exchange 2010 remove this field from ADUC? What steps should I take to Decommission 2010? (I do not mind working on Distro Groups in 365)
You should remove the hybrid configuration, which involves a couple of manual steps with Exchange 2010. After that you can uninstall Exchange 2010. Please be aware that this is still not a supported scenario, and managing Exchange Online use ADSI Edit on-premises can be challenging 🙂