Brute Force Uninstall of Management Group

I recently had a case where we needed to rebuild a lab environment.  The customer did not want to wipe the servers clean for this, and just wanted to uninstall the server roles and database to start with a pristine Management Group.  However, when they attempted to uninstall the Root Management Server, they ran into issues.  The uninstall continued to get interrupted and the RMS services continued to run after all attempts.

This is the procedure we used to force an uninstall of the RMS.  This method has not been tested by the product team, which makes it unsupported, and is intended to be a last resort.  As always, having recent backups of everything is highly recommended before doing any sort of configuration change.  Also, I do not mention anything about the Agent installations in this walkthrough.  If you have many Agents currently reporting the this Management Group, include this in your decommissioning plan.  This might be a process of uninstalling the Agents manually or via the Operations Console before following these steps.

One last note before outlining the process.  Although this process seems to work just fine, I would not recommend this in a production environment.  If you are having these sort of problems rebuilding a production environment, it might be better to take the time and wipe any problem server by reinstalling the operating system.  Otherwise you’ll have that lingering thought, just knowing that we basically ripped SCOM off the box before reinstalling.  But, that’s just personal preference and peace of mind…

Update:  We published an updated cleanup tool on 11-16-2010, which can be downloaded here.

The process

Stop all three System Center Operations Manager services; Health Service, Config Service and SDK Service.

Download MSIZAP and copy to a location on the RMS computer. Find the product code, which is a GUID that is required for the MSIZAP product code switch.  This can be found by opening the registry and navigating to: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall With the Uninstall key highlighted, click on Edit > Find, and look for the string System Center Operations Manager.  Open the UninstallString string value, and copy the GUID.  Include the squiggly brackets.  Open a command prompt and run the program as follows: msizap.exe t [product code] Wait until this process has completed.  Shouldn’t be more than a minute or two. I have only use this process on an R2 installation.  I assume this will work fine on SP1 or RTM as well, which will probably include a different product code.

Delete the SCOM program files, usually located under “%ProgramFiles%\System Center Operations Manager 2007”. If some files under the root do not delete, this is okay.  We received access denied dialogs in our process.  But we were able to delete all other contained folders and files.

Open the registry and navigate to: HKLM\System\CurrentControlSet\Services Delete the following registry entries: omcfg omsdk healthservice opsmgr* MOMConnector

Reboot computer.

I only had an RMS in this particular MG, so didn't need to run through this procedure on any other MS's or GW's.  If you happen to have MS’s or GW’s that will not uninstall gracefully, the process should be fairly similar.

Now you should be able to uninstall System Center Operations Manager from the computer hosting the operational database.  Use Add/Remove programs first to uninstall the program files, and then delete the OperationsManager database.  After the database has been deleted, proceed to install the new Management Group as outlined in the installation guide.

Hope this helps!