We recently made the mistake of visualizing our MOM 2005 database server (as part of the preparation for SCOM) and have suffered many long and sleepless nights since. The MOM database is probably one of the most disk intensive database scenarios one can think of, and it simply does not work well in a virtualized environment.
So, on my return from Tech-Ed (I never promised I would never mentioned it again *grin*), I made the decision to migrate the OnePoint database back to a physical server – especially as running the MOM and SCOM components on the same hardware is a supported configuration.
This is actually a fairly easy process, and is clearly outlined in this article. This is what you do:
Step 1: Prepare the Operating system and SQL components as per your best practice. This server should not contain any historic MOM components, so a clean install is suggested.
Step 2: Install the MOM database components. Be sure to use the same Management group name as your current implementation.
Step 3: Stop the MOM service on ALL your management servers, as well as the MOM to MOM product connector service.
Step 4: Make a full backup of your current OnePoint database, as well as the Master and MSDB databases (you don’t need the last two for this process, but you will need them if you want to do a full restore). Copy your backup files to the new server.
Step 5: On the new server, restore the OnePoint backup, and confirm that the permissions on the database are correct. Update the registry (according to the linked article) and start the MOM services on your management servers.
You may need a reboot on the management servers after the change – our one server was fine, but on the other, the console would only work after a reboot.
Some points to consider:
- While the MOM services are stopped on your management server, the queues on the agents will start filling up. You may want to, as a temporary measure, increase the agent cache before starting the migration process. This will save you some heartache in the long run.
- If you are not migrating your reporting services, you will need to update your groom jobs to run across from the one server to the other, otherwise your database will fill up.
I am in the process of migrating our reporting database, and will report back once this is done 🙂