The most common reasons I have seen for uninstalling Office Communications Server 2007 from an environment are typically to remove a pre-release beta version or test deployment, or to start from scratch after a botched deployment. In either scenario it’s often desired to completely remove all aspects of OCS and start fresh. This approach is often started by simply uninstalling the OCS components from the Front-End server, and doing so will generate this alert:
If ‘Yes’ is chosen and all other component removed, then the Active Directory forest and domain(s) will still contain remnants of OCS and promptly beginning a new installation in the same forest will probably lead to even more problems then before. There is a little more to it than just running the Add/Remove Programs wizard.
Supported Uninstall Path
The correct order of steps to completely uninstall OCS 2007 are:
- Deactivate Servers
- Uninstall Software Components
- Unprep Domain and Forest
Each registered server component (e.g. Standard Edition Front-End, Edge, Web Components, Mediation) can be deactivated by using either the Management Console or the LCSCmd.exe command utility.
The simplest way is to use the console and navigate to the menu shown below:
But if the server components have already been uninstalled and the console is therefor also removed, then the command line must be used. Since the server files have been removed then the LCSCmd.exe command must be run from the setupi386 directory of the OCS installation files. The OCS 2007 Administration Guide contains all of the documented switches and examples required to deactivate and unprep components, but here are some examples for removing common components.
|Deactivate Standard Edition Server||lcscmd.exe /Server /Role:SE /Action:Deactivate /Force|
|Deactivate Enterprise Edition Server||lcscmd.exe /Server /Role:EE /Action:Deactivate /Force|
|Deactivate Consolidated Edge Server||lcscmd.exe /Server /Role:AP /Components:AP,DP,MR /Action:Deactivate /Force|
|Deactivate Proxy Server||lcscmd.exe /Server /Role:Proxy /Action:Deactivate /Force|
|Deactivate WorkGroupProxy Server||lcscmd.exe /Server /Role:WorkGroupProxy /Action:Deactivate /Force|
|Deactivate Web Components Server||lcscmd.exe /Web /Action:Deactivate /Force|
|Deactivate Mediation Server||lcscmd.exe /MedServer /Action:Deactivate /Force|
If the original server has been completely removed from the domain, then issuing the command from another server requires a slightly different format in order to specify the desired AD object:
lcscmd.exe /Server:ocs1.schertz.lab /Action:Deactivate /Role:SE /Refdomain:schertz.lab
If removing an Enterprise Edition server than the pool will need to also be removed. Current version pools can be removed using the Remove Pool option in the management tools, or by using lcscmd. Previous version pool need to be removed by the lcscmd.
lcscmd.exe /Forest:schertz.lab /Action:RemovePool /PoolName:Pool1 [/Keepdb] [/Force]
For the truly paranoid, I’d recommend using the /KEEPDB switch when using /FORCE so that the back-end databases are left alone. Then you can use the SQL Management tools to manually detach and delete the databases within SQL. Although it’s not normally possible to have different pools pointing to the same SQL serverinstancedatabase, a misconfigured system could potentially be pointing to the wrong location. If somehow a failed pool installation referenced the same back-end database path as a working pool then this process could accidentally attempt to remove the in-use production pool. That would be extremely bad. But if there is no migrated version of OCS in use and there is no importance placed on the SQL databases, then leave out the /KEEPDB switch to wipe the databases.
After deactivating all components then uninstall each program on the server(s).
When removing the Standard Edition Server component, uncheck the option to "Keep the user database" to have the local SQL database files deleted by the process. The folders will still reside on the local disk (by default C:LC Data and C:LC Log) but will be empty.
Unprepping the Forest
The final steps are to remove the related configuration information in Active Directory. Note that the Schema extensions created by the original SchemaPrep step can not be removed, but if the eventual goal is to reinstall OCS then this present no problems. The Schema extensions are generic and contain no instance-specific configuration information. By unprepping the Domain and Forest, all configuration information will be removed.
lcscmd.exe /Domain:schertz.lab /Action:DomainUnPrep
lcscmd.exe /Forest:schertz.lab /Action:ForestUnprep
After allowing for any AD replication to fully complete, a new installation of OCS can be started. I’d recommend using a new, unique servername for the second go-around just to be on the safe side.