Sign up for Office 365
Learn more about Office 365
However, it’s strongly recommended that you maintain at least one Exchange server so that you have access to Exchange System Manager (Exchange 2003) or Exchange Management Console/Exchange Management Shell (Exchange 2007 and Exchange 2010) to manage mail-related attributes on the on-premises MEUs.
I want Single Sign On. But, I have to keep an on premise server? Really? What happens if I decommission my on-premise Exchange? What would I lose - why does the article advise against it?
Thanks for the feedback.
Thanks for Steven's response in this thread.
1. Only when Dirsync turned off you can then manage MEUs with ECP (Exchange Control Panel). With DirSyn turned on, ECP is limited for use (This is a by design behavior).
2. Turning of on-premise Exchange server won't cause any potential issues with your online mailbox. In fact, after the migration, the on-premise Exchange server is not in use any more.
From my understanding, you are performing cutover migration and deploying Single Sign-on, you get a bit confused about the statement of retaining on-premise Exchange server. Am I correct?
According to the guide, the on-premise Exchange server is recommended to be retained to manage the mail-related attributes on the on-premises MEUs, which includes mail enabled users and mail-enabled objects, such as Distribution Groups. For with the Directory synchronization turned on, we are not able to manage the mail enabled users and objects with Office 365 portal or Exchange Control Panel (ECP), but we need to manage our mail-enabled users and objects with local environment.
If you have any other questions, please feel free to post them in this thread.
So, if we wanted single sign on after the migration and also to decommission our on premise exchange server - how would we accomplish that? Is there a workaround?
According to the statement, it's optional to maintain one Exchange server after the Cutover migration and SSO deployment, the server is used to manage the mail enabled users (MEU) for your tenant. In other words, you will still be able to decommission the on premise Exchange servers, that wouldn't affect the SSO (Single Sign-on) functionality. Therefore, I think no workaround is needed here.
If I misunderstood anything, please let me know.
How is thing going? Do you need any further assistance?
I'm still confused as to why the documentation states to keep an on premise exchange server. Yes, it says its optional - but it also says its suggested. I need to know *why* it is suggested. Why do I need it? Why do they suggest it? What is the purpose? Do I really need the on premise exchange to manage my users after the migration? Seems counter intuitive - I am going to a hosted solution, but I need to keep an on premise exchange server afterwards?
For the SSO functionality, we must deploy Dirync, therefore we need retain the on-premise Dirysync server.
Then, though we can decommission all the Exchange servers (this will not cost any loss of Exchange Online functionality), it’s a better choice to keep an on-premise Exchange server along with the Dirsync server. The on-premise Exchange server plays no real roles but managing the MEUs.
In fact, with the SSO functionality, we need to deploy on-premise ADFS servers, therefore, we are using a federated solution other than hosted solution.
How are you? Just checking to make sure my above information is helpful. If you have any further questions, please feel free to respond.
Well, first... just to clarify.. does MEU mean any user in my domain that use email through exchange?
So, what happens if I don't have the on premise exchange server to manage my MEU's? How would I add new MEU's and modify existing MEU's? Are the docs saying that if I remove the on premise exchange server, I cannot add or delete MEU's?
MEU is short for Mail-enabled user objects, which are users that have an external mailbox.
In a Dirsync deployed environment, without the on-premise Exchange server, we need to de-activate Dirsync to manage the MEUs, but we will not able to manage them with Exchange Online control panel directly.
For you reference:
Manage directory synchronization
Thanks. I think that I am understanding, but to clarify:
1. I am worried that by decommissioning the on premise exchange server, it will remove AD attributes that will get replicated to Exchange Online (via dirsync) and cause problems. Or dirsync will see that certain attributes were removed from my MEU's and cause issues. Can you confirm this will not happen?
2. Why do I need to disable dirsync to manage my MEU's? If the on premise AD is mastered to O365, why wouldn't I be able to make changes onsite. Shouldn't dirSync pick them up and push to Exchange Online?
1, Decommissioning the on-premise Exchange server will not change any AD attribute, therefore no changes will be replicated to Exchange Online.
2, We can manage Mailbox enabled users through on premise AD and changes will push to cloud. However we are not able to manage Mail enabled user objects through on premise AD, this is why we are recommended to keep at least one on premise Exchange server (to manage MEUs).
For # 2.... I'm confused. In the first sentence you say that I can manage Mailbox enabled users via on premise AD, then in the second sentence you say I can't manage MEU's via on premise AD. Are MEU's different than Mailbox enabled users? (maybe some subtle difference that I am missing)
Also, what does disabling dirsync have to do with managing the MEU's (or Mailbox enabled Users)?
Mail-enabled user objects are users that have an external mailbox. Mailbox-enabled user objects are users that have an Exchange Online mailbox.
You can manage Mailbox-enabled user through local AD, however you can't manage Mail-enabled user objects (GAL) through AD.
1. Why do I have to turn of dirsync?
2. Is the Mail Enabled user object issue you speak of the same issue that is due to the displayname attribute (which can be worked around by using ADUC in advanced mode)?
But besides all that.... I'm still not 100% clear on the impact of removing all my Exchange servers after I've moved everyone to O365 with SSO enabled. In other words, what issues can I expect? Is is just the issue of not being able to sync security groups because they will be missing the displayname attribute? Or is there more to it?