I finally pulled the plug on our last Exchange 2013 box last month. Not gonna lie—it felt like retiring an old workhorse. If you’ve been running Exchange 2013 in production, you know it’s been stable (mostly), but with support officially over, it was time to move on. I figured I’d share how I approached the decommissioning process—what worked, what didn’t, and a few things I wish I’d double-checked before hitting uninstall.
Why I Took This On
We’d already moved mailboxes and services to Exchange 2019 over the past year. The 2013 server was just sitting there, quietly handling Autodiscover and a few legacy app connections. I’d been putting off the final cleanup because, well, you never want to be the one who breaks mail flow on a Friday afternoon. But with patching cycles getting tighter and support gone, it was time.
Step-by-Step: What I Did (and What I Checked Twice)
1. Inventory Everything That Talks to Exchange
Before touching anything, I made a list of all the apps and services that still pinged Exchange 2013. This included backup tools, scanners, and a couple of dusty line-of-business apps that still used SMTP relay. I reached out to vendors where needed—some had patches for 2019, others just needed a config tweak.
Tip: Don’t assume your dev team updated their SMTP configs. I found one app still pointing to the 2013 IP even though the hostname had been updated months ago.
2. Double-Check the Namespaces
I ran through all the virtual directories—Outlook Anywhere, OWA, EWS, Autodiscover—and made sure the DNS records and SSL certs were pointing to the new 2019 servers. We reused the same namespaces, so I didn’t need to request a new cert, which was a relief.
If you’re changing namespaces, just be ready to update your certs and client configs. That part can get messy fast if you miss a SAN entry.
3. SCP Cleanup
This one’s easy to overlook. I ran:
Get-ExchangeServer | Where-Object {$_.AdminDisplayVersion -like "Version 15.0*" -and $_.IsClientAccessServer -eq $true} | Get-ClientAccessService | Format-Table Name, FQDN, AutoDiscoverServiceInternalUri -AutoSize
That gave me the internal Autodiscover SCPs still pointing to the 2013 box. I updated them to the 2019 server using Set-ClientAccessService. If you skip this, internal Outlook clients might still try to talk to the decommissioned server.
4. Uninstall Time
Once I was confident everything had moved over, I ran appwiz.cpl on the 2013 box and kicked off the uninstall. It took about 15 minutes. No drama, no errors. Just a quiet farewell.
Side note: I’ve seen uninstall hang before if arbitration mailboxes weren’t moved. This time, I’d already cleared those out weeks earlier.
What Caught Me Off Guard
- One of our monitoring tools still had a hardcoded reference to the 2013 server’s FQDN. It didn’t break anything, but it threw alerts for days until I updated the config.
- I forgot to remove the old server from a couple of load balancer pools. That led to some weird behavior with OWA redirects until I cleaned it up.
Lessons Learned
- Always check SCPs. Seriously.
- Don’t trust DNS alone—check the actual client behavior.
- Give yourself a rollback plan. I had a snapshot ready just in case, though I didn’t need it.
Final Thoughts
Decommissioning Exchange 2013 isn’t rocket science, but it’s easy to miss a step that causes ripple effects later. Take your time, document everything, and don’t rush the uninstall just because the server looks idle.
If you’ve recently gone through this—or are planning to—what tripped you up? Did you run into any weird client behavior post-removal?
Drop a comment or ping me if you’ve got a horror story or a clever trick. Always happy to swap notes.
