Forum Discussion
What is required to decommission the last on-prem Exchange server?
Follow the official guidance here: https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx?f=255&MSPPError=-2147217396
Pay special attention to the discussion around DirSync - if you decide to keep DirSync, you have to keep the Exchange box for management purposes if you want to stay in supported configuration.
As to what to do with the remaining mailboxes, it's up to you. Just don't "store" them as PSTs... :)
You need it for management purposes - the only supported method for managing Exchange related objects and attributes are the Exchange tools. And yes, it's a very common question/complaint, last years Ignite also resulted in us hearing some promises around it, but nothing has changed so far.
We had an on-prem Exchange 2013 a year or so ago. With a help of our partners we have switched to hybrid mode and then migrated all mailboxes to Exchange Online. After that on-prem version was uninstalled (deprovisioned). The only thing we have to manage so far is adding main and alias addresses, which can be done via Attributes editor in AD. Shared and rooms mailboxes are created in EO directly, permissions also are managed via EO. Maybe our needs are modest, but so far i haven't encountered a task requiring an on-prem installation just to manage things.
- I understand it is possible to do what you did, but I don’t recommend it for others.
The reason why Attribute Editor / ADSIEdit is not recommended is because it doesn’t perform validation that the values you entered are not duplicated with other objects or have at least one SMTP (uppercase) and not two, or sometimes people forget to add “smtp:” in front of the email address.
Another issue is how to enable archiving on a mailbox - it changes the recipient type value.
Let’s say you leave your organization at some point - is this leaving them in the best supportability? This is not a dig at you personally - it is just something I would be concerned with if I was the IT Manager.If everything is well documented (as it should), someone leaving an organization is not a problem. Managing your own on-prem Exchange is a more complex task requiring expertise and time and more vulnerable to employees leaving. We used outsourced on-prem Exchange and it was still challenging with experts managing it (especially with updates breaking it). As our agreement came to end, we would have to purchase (maybe it's free for this), install and maintain our own Exchange just to manage a few things. We also want to move to cloud only eventually. So it wasn't feasible for us. One has to follow procedures not to create duplicates, and even if created, it will produce sync errors and they will give insight that something has to be fixed. Already had an issue with duplicated alias. It was a minute fix. As i've said our requirements are simple. Maybe some tasks do require Exchange (you mentioned archiving) or some orgs already have it installed in their environment and are used to work with it, but it sounds like an overkill solution for me (it also might be some admins don't want to let it go). So, i hope MS will come up with a supported scenario without it.
wroot it's not about what's "possible", but what's "supported". If you know what you are doing, you will be perfectly fine with managing things via ADUC/PowerShell or even the old school command-line tools, but if you run into any issues, Microsoft will simply deny you support. I know a lot of organizations that never had Exchange (moved from Lotus Notes for example), and they often choose to simply extend the AD schema with the Exchange attributes and continue managing the objects using the AD tools. Again, it's perfectly doable, but not a "supported configuration", so you are on your own if something happens.
