What is required to decommission the last on-prem Exchange server?

[Chris Parker]

We run in a hybrid deployment. The on-prem mailboxes are all former employees. We have an address policy that creates multiple alias addresses for mailboxes. We don't have any public folders.

I really want to get rid of this VM. It takes up a lot of storage and generally does nothing.

I presume the following tasks will be required before I can even really think about turning this VM off:

1. Do something with those mailboxes.

I'm not sure what though but surely it involves whether the business needs them to continue to receive mail or not. Past that it's (a) Take one last backup? (b) Migrate them to Office 365? (c) ???

2. Build a PowerShell script that will add all the needed aliases to a new mailbox.

Is this true or is there an Exchange Online alternative?

What is the current guidance for this?

Thank you!

[#2 · Accepted solution]

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... 🙂

[#3]

Yeah, I've seen this before. I was hoping there were new practices out there. 😐 At Ignite, about three years ago, someone from the Exchange team, in a end-of-day Q&A, answered my question around this and said that they had guidance coming to achieve such a thing but nothing has materialized yet.

What about orgs that never had Exchange but do have on-prem AD and now use Office 365+Exchange Online?

And another question I have is, if you'll indulge me, what role does Exchange play if all active mailboxes are online? Why exactly do I still need Exchange?

[#4]

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.

[#5]

Microsoft announced plans to change this at Ignite 2017.  Review Jeff Kizner's session - jump to 54:13 where hybrid recipient management is discussed.  I've not heard any further developments yet.  

[#6]

FYI - Jeff Kizner is speaking again at Ignite 2018 and looks like he will provide an update during his session based on the agenda:

"Establishing an Exchange hybrid setup and configuring your tenant are some of the first steps in moving to Exchange Online. This process often gets bogged down in politics, competing priorities with other teams, and general configuration minutia. Fear no more! Learn how you, the messaging admin, can move to Exchange Online without talking to your network admin. Blocked by your pesky security team on the requirements for publishing Exchange? Come learn how you can mitigate their concerns. Come see the changes we’re making to the Exchange hybrid architecture and how we’re simplifying the process of moving to Exchange Online."

https://myignite.microsoft.com/sessions/65633?source=sessions

[#7]

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.

[#8]

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.

[#9]

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. 

[#10]

@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.

[#11]

Yes, i know this is not supported, that's why i said that i hope this will change. Because it seems impractical to use Exchange Online but having to keep/install standalone Exchange to do managing. 

[#12]

Btw, recently i had a support ticket because of a mysterious smtp address in our contacts which was tied to some missing mailbox. Support helped with this without i think even asking whether we have on prem Exchange. I don't remember them asking about it at all. Well, maybe our tickets so far didn't require it.