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)
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.
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 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:
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.
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:
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:
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.
Use the find feature to find the line containing
Kerbauth and remove the entire line.
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.
This should take you to:
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.