I have recently needed to decommission Exchange on several 2011 Small Business Servers.

This is generally not recommended as it can easily break some of the functionality of the SBS.

However, in several cases I have dealt with, the client’s mail has been migrated to a Hosted Exchange platform or to Office 365 and Exchange was no longer required. Additionally disk space was running low and Exchange was an easy-ish target for reclaiming space and allowing the SBS to continue running for a few more months before decommissioning.

It is generally considered best practice to simply disable all the Exchange services until the SBS is fully decommissioned and I would highly recommend this if at all possible.

That said, the following is what I have found was required to decommission Exchange with minimal breakage.

(As stated the following is not supported or recommended so proceed at your own risk! I HIGHLY recommend taking a full restorable backup before continuing)

Initial Decommissioning

To go through the initial steps of the Exchange decommissioning, the blog post by ITProMentor was very helpful.

After running Exchange Management Shell as Administrator the following commands can be entered, answering prompts with “A” for ALL.

# Remove the default Public folders
Get-PublicFolder "\" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Recurse -ErrorAction:SilentlyContinue

# Remove the system Public folders
Get-PublicFolder "\Non_Ipm_Subtree" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Recurse -ErrorAction:SilentlyContinue

# Remove all Offline Address Books
Get-OfflineAddressBook | Remove-OfflineAddressBook

# Remove all send connectors
Get-SendConnector | Remove-SendConnector

# Remove the Public Folder database (May fail, see below)
Get-PublicFolderDatabase | Remove-PublicFolderDatabase

# Remove arbitration mailboxes
Get-Mailbox -Arbitration | Disable-Mailbox -Arbitration -DisableLastArbitrationMailboxAllowed

# Remove all mailboxes
Get-Mailbox | Disable-Mailbox

# Remove default Public folders
Get-PublicFolder "\" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Recurse -ErrorAction:SilentlyContinue
 
# Remove system Public folders
Get-PublicFolder "\Non_Ipm_Subtree" -Recurse -ResultSize:Unlimited | Remove-PublicFolder -Recurse -ErrorAction:SilentlyContinue
 
# Remove Offline Address Book
Get-OfflineAddressBook | Remove-OfflineAddressBook
 
# Remove send connectors
Get-SendConnector | Remove-SendConnector
 
# Remove Public Folder database
Get-PublicFolderDatabase | Remove-PublicFolderDatabase
 
# Remove arbitration mailboxes (SBS 2011/Exchange 2010 Only)
Get-Mailbox -Arbitration | Disable-Mailbox -Arbitration -DisableLastArbitrationMailboxAllowed
 
# Remove mailboxes
Get-Mailbox | Disable-Mailbox

At this stage Exchange should be fairly bare.

Resolving public folder database removal failure

However, in all cases I have dealt with, the commands to remove the public folder database failed with the following or similar:

The public folder database "SERVER\Second Storage Group\Public Folder Database" contains folder replicas. Before deleting the public folder database, remove the folders or move the replicas to another public folder database.

The post by Todd Nelson was very helpful in this regard as ADSIedit was needed to remove the public folder database.

Using ADSIedit can be very dangerous, so for the second time, proceed at your own risk.

IN ADSIedit I browsed to the following location:

CN=Configuration > CN=Services > CN=Microsoft Exchange > CN=First Organization > CN=Administrative Groups > CN=Exchange Administrative Group (FYDIBOHF23SPDLT) > CN=Servers > CN=SERVER > CN=Information Store > CN=Second Storage Group > CN=Public Folder Database

Under this location I deleted the object for the public folder database.

In one case I also had to browse through the Exchange Administrative Group and remove another reference to a previous Public Folder Database that had not been correctly removed.

Uninstall Exchange

Having done this I was able to uninstall Exchange as follows:

In an elevated command prompt, browse to the Exchange BIN folder and run the setup in uninstall mode:

cd “C:\Program Files\Microsoft\Exchange Server\v14\Bin”
setup.com /mode:uninstall

If all went well, this will run through some checks and then proceed to uninstall Exchange.

In one case I needed to kill a process that was locking some of the files and then re-run the setup in uninstall mode.

At this stage I would highly recommend a reboot.

This is where most guides I have found stop, and in some cases this is fine.

However, I have found that if Remote Web Workplace was used for remote access to a terminal server or PC’s this functionality is now likely to be broken.

Examining the event logs will likely show errors as follows:

The Module DLL C:\Program Files\Microsoft\Exchange Server\V14\Bin\kerbauth.dll failed to load.  The data is the error.

Kerbauth Error

After some searching I found an article by Wayne Small at sbsfaq which was very helpful.

Resolve kerbauth.dll errors

The solution is as following:

Open notepad as administrator and use File > Open to open the applicationHost.config file in the following directory. C:\Windows\System32\inetsrv\config

Inetsrv Config

Use the find feature to find the line containing Kerbauth and remove the entire line.

KerbAuth File

Save and close the file then run iisreset in an elevated command prompt.

This should resolve the Kerberos errors in the event logs.

However, the remote desktop gateway is likely to still be broken.

Fix Remote Desktop Gateway

After a lot of research into Exchange, IIS, Remote Desktop and RPC I was able to find the following solution.

Open IIS Manager and navigate to the Default Website, right click on “rpc” and click explore.

IIS RPC

This should take you to: C:\Windows\System32\RpcProxy

In this location there will be a web.config file which will contain multiple references to Exchange files which are no longer in place.

Simply deleting this web.config file in it’s entirety and issuing another iisreset in an administrative command prompt should restore the Remote Desktop Gateway functionality to working order.

I have not encountered any further issues caused by the removal of Exchange in this manner.

Hopefully this post has been helpful and has saved you the hours of google I had to go through.