Resurrecting a Zombie Exchange Server: Bypassing IIS to Extract a Legacy PST

Every MSP engineer who has inherited a post-migration environment has met the Zombie Server.

The story is always the same. Someone successfully migrated the mailboxes to Microsoft 365, killed the core Exchange services in services.msc to reclaim RAM for the hypervisor cluster, maybe uninstalled IIS, and closed the ticket. Clean enough. Except they never ran the Exchange uninstaller. Never removed it from Active Directory. The server just sat there - disabled, dormant, and invisible - collecting dust in the VMware or Hyper-V inventory until the day Legal submits a priority-one ticket.

We need the mailbox data for a terminated employee. The account was never synced to M365.

Now you are standing in front of a machine that has been in a medically induced coma for three years, and you need something that lives inside it.

Here is how you get it out.

The Problem: The WinRM 403 Trap

The first thing you do is remote in, click the Exchange Management Shell shortcut, and get a wall of red text:

Connecting to remote server EXCH01.contoso.local failed with the following
error message: The WinRM client received an HTTP status code of 403 from
the remote WS-Management service.

All Exchange management is handled via Remote PowerShell, and that dependency on IIS is significant - Remote PowerShell requests are sent via HTTP and use IIS as the connection mechanism. IIS works with WinRM and the WSMan protocol to initiate the session. Which means when someone killed the World Wide Web Publishing Service, or left IIS intact but misconfigured, the management layer went with it.

The most common trigger is "Require SSL" being enabled on the PowerShell virtual directory. The Exchange Management Tools connect over port 80, not 443. If Require SSL is set and a connection is attempted on port 80, IIS returns a 403 indicating SSL is required.

You could spend the afternoon rebuilding virtual directories, chasing expired certificates, and running iisreset until your eyes glaze over. Or you can skip IIS entirely.

Before You Touch Anything: The RBAC Tax

There is a prerequisite that will burn you if you do not handle it first, and it does not get mentioned enough.

The account you are using must have the Mailbox Import Export role assigned. This is an RBAC permission that is entirely separate from file system permissions on the target folder. It is not assigned to anyone by default - not to Domain Admins, not to Exchange Organization Admins. If you skip this, your export command will fail late in the process, after you have already done the hard work of mounting the database.

Assign it now, before you start any services:

New-ManagementRoleAssignment -Role "Mailbox Import Export" -User "youradminaccount"

The Bypass: Direct Snap-in Injection

If you are locked out of the normal remote PowerShell path, you can directly load the Exchange Management Shell snap-in to regain access. Microsoft's own documentation flags this as an "otherwise highly discouraged method." Noted. In this context, it is the right tool. Open an elevated standard Windows PowerShell window - not the broken EMS shortcut - and inject the Exchange binaries directly from the local disk:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

If the prompt returns cleanly with no errors, you have bypassed IIS. The Exchange cmdlets are now loaded into your session. Run Get-Mailbox to confirm. If it returns results instead of an "unrecognized command" error, you are in.

Now check the database status:

Get-MailboxDatabaseCopyStatus

It will show ServiceDown. You have the commands. The zombie is still asleep.

The Resurrection: Waking Dependencies in Order

To physically read the .edb database file and package it into a PST, Exchange needs three services running. The order matters. Skip a step and the next one fails.

Step 1: The Information Store

The Microsoft Exchange Information Store (MSExchangeIS) is the database engine. Nothing else works without it.

Set-Service MSExchangeIS -StartupType Manual
Start-Service MSExchangeIS

Step 2: Active Manager

Do not attempt to mount the database yet. It will fail.

Even on a standalone server with no DAG in sight, the Replication service hosts the Standalone Active Manager that handles all mount and dismount requests. The mount command goes to Active Manager first. Active Manager checks its conditions and then issues the request to the Information Store. No Replication service means no Active Manager means no mount. Period.

Set-Service MSExchangeRepl -StartupType Manual
Start-Service MSExchangeRepl

Now mount the database and confirm it took:

Get-MailboxDatabase | Mount-Database
Get-MailboxDatabase -Status | Select Name, Mounted

Staging the Export: The UNC Path is Not Optional

Mailbox exports must target a UNC network share. The Exchange Trusted Subsystem security group requires Read/Write permission to that share. This is not a suggestion. Even if you are exporting to the local C: drive, you must reference it via UNC path. If the share does not have the correct permissions, you will get errors when you try to export.

The typical mistake is targeting a desktop path or a local folder without sharing it. Exchange processes export jobs under the Exchange Trusted Subsystem computer account. That account cannot traverse C:\Users. It will fail immediately with an access denied error.

Set it up correctly the first time:

1. Create C:\PSTExport at the root of the drive.
2. Share the folder - name the share PSTExport.
3. On both the Share Permissions tab and the NTFS Security tab, grant Exchange Trusted Subsystem explicit Read/Write access.

Before you fire the export command, confirm the exact mailbox alias. Do not guess. A typo here results in an object-not-found error, and you will not know which part of the command is wrong:

Get-Mailbox *jdoe* | Select-Object DisplayName, Alias

The Final Dependency: The Mailbox Replication Service

With the alias confirmed and the UNC path ready, run the export:

New-MailboxExportRequest -Mailbox "jdoe" -FilePath "\\EXCH01\PSTExport\jdoe.pst"

If the server has been heavily disabled, this fails with a TCP error 10061 - connection actively refused.

The Information Store mounts the database. But the Mailbox Replication Service (MRS) is what actually packages the data into a PST file and moves it. When exporting a PST using New-MailboxExportRequest, a UNC path is a mandatory parameter, but MRS must be running to process the job at all. If MRS is disabled, there is nothing listening to accept the work order.

Wake it:

Set-Service MSExchangeMailboxReplication -StartupType Manual
Start-Service MSExchangeMailboxReplication

On a cold server that has been disabled for years, give MRS 30-60 seconds to fully bind before you proceed. Do not guess at whether it is ready, check it:

Get-Service MSExchangeMailboxReplication | Select Status, StartType

When Status shows Running, re-run the export command. It executes silently, returns you to a blank prompt, and queues the job in the background.

Validation and Cleanup

The export runs asynchronously. Monitor it:

Get-MailboxExportRequest | Get-MailboxExportRequestStatistics

Cycle this until the status flips from InProgress to Completed. Once it does, pull the PST to your secure external storage.

Then put the server back to sleep. Exchange consumes a serious amount of RAM and presents an attack surface that has no business being live in your environment once you have what you came for. Clean the export queue and shut everything down:

Get-MailboxExportRequest -Status Completed | Remove-MailboxExportRequest -Confirm:$false

Stop-Service MSExchangeMailboxReplication, MSExchangeRepl, MSExchangeIS -Force
Set-Service MSExchangeMailboxReplication, MSExchangeRepl, MSExchangeIS -StartupType Disabled

What You Actually Fixed Today (and What You Did Not)

You extracted the data. That is real. The ticket is closed, Legal has what it needs, and you did not spend four hours fighting IIS.

But the server is still there. The Exchange metadata is still embedded in Active Directory, which means your environment is still carrying the weight of an installation that serves no purpose. Uninstalling Exchange removes critical information from Active Directory, which is exactly why you should run the uninstaller properly rather than just disabling services and walking away. The right uninstall process removes the Exchange objects cleanly and closes the book.

What was done to this server, disabling services, leaving the AD objects intact, never running the uninstaller. . .is the thing that created this problem in the first place. The next engineer to inherit this environment deserves better than another zombie.

Plan the proper decommission. Do it right.