Jan 09 2018 02:32 PM
Hello,
I currently have a scenario where there is a Hybrid Exchange environment with 1 server. All my mailboxes have been migrated online.
I would like to completely remove dependency on local AD and I do not care about AD synchronization.
How do I "tell" the O365 tenant not function on it's own so that I can manage 100% from 365 Administration?
I do understand that my MX and other DNS records will need to be changed.
Are there any solid guides out there on decommissioning the on premise exchange server. I want to do this with the least impact on users.
Thanks,
Keith
Nov 15 2018 10:23 PM
This question rises every now and then. For short: you don't NEED an exchange server, attributes can be edited in ADUC as described in this message thread. After all, there are organizations which have never had an Exchange server and are running Office 365 (as I do).
AFAIK only thing you'll loose is email policies.
Nov 15 2018 10:33 PM
Nov 15 2018 11:54 PM
Email policies (automatically assign addresses) is a feature only available in on-prem Exchange. I would like to see this feature also in EOL - at least for pure-cloud environment. Anyways, if you remove on-prem Exchange server, you will loose the email policies feature.
Nov 16 2018 12:02 AM
Nov 16 2018 12:28 AM
@Nestori Syynimaa if you never had Exchange on-premises is something different because your AD objects don't have the exchange attributes and your AD doesn't have the exchange Schema.
If you had Exchange Server in your on-premises AD then your AD objects have exchange attributes. That means that you are going to have conflicts if you don't follow the best practices regarding a hybrid exchange environment.
Nov 16 2018 12:45 AM
Sure @Spiros Karampinis, it is a bit different but in practice that is irrelevant. Basically all you need is proxyAddresses attribute, which is included "normal" AD schema.
Again, you do not NEED an on-prem Exchange server - although this is not "supported" by Microsoft.
Nov 16 2018 12:56 AM
@Nestori Syynimaa thank you for your reply.
How can you guarantee that the additional proxyAddress doesn't already exist,
or if the mailNickname that you set isn't occupied by another user?
Worth for you the whole pre-check workload the time and your energy to avoid having one more virtual machine with 2 vCPU and 4GB vRAM and an Exchange instance installed?
Nov 16 2018 05:09 AM
Good point @Spiros Karampinis.
In Office 365/Azure AD all email addresses are unique. If you add an email address in on-prem AD already used by someone in Azure AD, you'll have a synchronization error and you can fix it. So, if you have a clear policy how you form your email addresses (firstname.lastname, etc.) this really isn't an issue.
Nov 16 2018 05:43 AM
@Keith Caines do you still have any considerations/questions regarding Exchange hybrid ?
Nov 19 2018 04:52 AM
Hi Spikar,
thanks for your clarification.
Regardless, I've since removed the on-prem Exchange last Friday and haven't yet experienced any issues.
I'll keep using the AD attribute editor to modify email addresses. Since we're talking about 28 mailboxes in total, I should be able to handle it without creating any conflicts.
Should I encounter any insurmountable problems, I guess I can always simply add an Exchange server back to our domain.
Regards,
Dominik
Nov 21 2018 02:27 AM - edited Nov 21 2018 02:32 AM
@Dominik Wagner exactly!
I don't think you are going to face any problems/issues/difficulties if you know what are you doing, which I think so :)
But you are definitely right, if you encounter any insurmountable problems you can easily install an Exchange Server an check the problems from Exchange sight.
Just keep in mind after the installation of an Exchange server the Active Directory SCP is going to be updated/created and the outlook clients on domain-joined computers will try to connect to the on-premises Exchange server in the autodiscovery process to locate the mailbox of the user. After the installation set the Service Connection Point to $null
Get-ClientAccessServer -Identity $NAME$ | Set-ClientAccessServer -AutoDiscoverServiceInternalUri $null
Have a nice day
Nov 30 2018 07:55 AM
Hi Guys,
Did you ever consider finishing the hybrid installation off.
Uninstalling exchange.
Uninstalling the adsync tool , stopping the sync at cloud level. Then just reset the password sync tool up using smtp matching?
This method would then be supported? As your not continueing with a hybrid.
Jan 07 2019 11:07 AM - edited Jan 07 2019 11:16 AM
I have a scenario somewhat similar. All mailboxes, DL's, and contacts are in the cloud. I'm using AADSync to sync passwords to Azure AD. All email management is done in the cloud, nothing in on-prem Exchange. What's the need to keep the on-prem Exchange other than Microsoft's "Because I said so"?
Some replies say that it's minimal, but it's more than that. It's an OS license, it's patch management, it's still uses resources, still needs to be backed up. There is still a lot of maintaining there. I want the on-prem gone since it's not being used.
Also, we don't use AD FS and all DNS records, MX, autodiscover, cname, etc, have been pointed to O365.
Jan 07 2019 11:18 AM
Jan 07 2019 11:22 AM
We don't edit any of the attributes. And all management is done in the cloud. All I need AADSync for password sync so I don't have to manage another password system.
I'm trying to grasp why in my environment I still need Exchange outside of Microsoft saying I do. If AADSync handles the password sync to Azure AD, no attributes are modified, and all management is done in the cloud, I see no further use for the on-prem Exchange.
Jan 07 2019 11:31 AM
Jan 07 2019 11:35 AM
After creating an AD user, we wait until the account has synced to the cloud, then add the email address in the cloud. We don't add the email address using ADU&C or on-prem Exchange ECP. In fact, we don't even use the on-prem Exchange ECP anymore. This is where the difficulty in grasping the concept if keeping the on-prem Exchange is coming in. AS previously mentioned, ALL email management is now done in the cloud, nothing is done on-prem.
Jan 07 2019 11:44 AM
Jan 08 2019 12:03 AM
@BrianSmith wrote:I have a scenario somewhat similar. All mailboxes, DL's, and contacts are in the cloud. I'm using AADSync to sync passwords to Azure AD. All email management is done in the cloud, nothing in on-prem Exchange. What's the need to keep the on-prem Exchange other than Microsoft's "Because I said so"?
Some replies say that it's minimal, but it's more than that. It's an OS license, it's patch management, it's still uses resources, still needs to be backed up. There is still a lot of maintaining there. I want the on-prem gone since it's not being used.
Also, we don't use AD FS and all DNS records, MX, autodiscover, cname, etc, have been pointed to O365.
I can only say that, so far, about 2 months into the transition I don't miss the on-premise Exchange server at all.
I've gotten used to simply managing our AD accounts using the attribute editor and syncing everything using AAD.
Of course, I don't know how things might eventually evolve over those next few years..maybe there'll be indeed a server-side change on Microsoft's part which would eventually require an on-premise Exchange server for necessary AD schema additions..but I'll cross that bridge when I come to it.
Like you said, keeping an on-premise Exchange around, even if just for management purposes, is just too much of a hassle and completely negates the primary motivation of moving everything to the cloud in the first place.
I really hope Microsoft corrects their stance on this particular issue, it really is quite bewildering.
Jan 08 2019 06:09 AM
Being that I still have an on-prem Exchange server, I have not had the need to edit any attributes. Without the on-prem, what attributes are needing to be edited?