SCCM 2007 - Possible Corrupt DB After VM Crash - How Easy Would Migration to New VM Be?

Hello All -

Our company's SCCM 2007 server was set up a couple of months ago by a 3rd party.  This 3rd party installed SCCM onto an empty Windows 2008 R2 server, then added a few collections.  

There was a mistake, though.  The server that they installed it on was the wrong one.  The hardware used was supposed to be our new VM ESX server.  Therefore, I did a P2V comversion of the SCCM server to a new VM and it seems to work perfectly.

Long story short, our ESX server which hosted the new VM took a dive due to hardware being incompatible.  After working a while with VMWare, I had no choice but to restore the SCCM VM from the P2V backup which I had created 2 weeks earlier.  Since that backup, I had already installed clients, but not really used the SCCM server yet.  We have yet to deploy software (other than the SCCM client) or use it in production.

I did my best to bring the backup back up to speed, but it still seems to act quirky sometimes.  I can't shake the feeling that the DB may be corrupted because of all that's happened.

With that in mind, I wanted to post and see how difficult it would be to reinstall SCCM onto a brand new VM.  In the current installation, I located and backed up the Site Settings to a file, but don't know what the easiest and safest path is to do this, if it even should be done, or if I'm getting myself into a huge project.  Also, what about the client installations?  If after the migration, I rename the new VM with the same hostname will they just jump on over without pause?

Here are some stats from our current SCCM server:
- Collections (about 20) were set up by the 3rd party
- Clients have been pushed via GPO for remote sites and WMI for local ones
- No software has been set up to be distributed
- There are 4 other dist points with just a couple of roles each assigned.
- WSUS has been installed on the server and populated in SCCM, but is not currently managing current workstations nor packages been created

The Site Status is green across the board, but after installing some clients via WMI, I refreshed the "ALL Systems" collection which applied a small hourglass to the icon.  3 Days later, it's still there no matter what I do.

I guess one of the first questions is do I create a new VM, add it as a chile, then transfer roles to it or just start with a fresh one and restore from export?  Remember - one of the main reasons is that the database may be corrupt so I don't want to risk moving the corruption over.

Who is Participating?
fr0nkConnect With a Mentor Commented:
the easiest and (at the same time) safest way to solve your problem is:

1. configure the: "Backup ConfigMgr Site Server" Task in "Site Maintenance".
Put the Backup anywhere you want. It doesn't matter. Easiest way is: Local Drive on Site Server.
Don't even bother with schedule settings, just click OK.
This triggers the task manually (therefore: don't worry about schedule settings! ;-)

Copy the destination of the backup to a safe place.

2. Document the following things:
Installation location of SCCM
Location of your DPs (it's a share name called SMSPKG[driveletter-on-which-the-DP-resides]. Backup This!
Location of your SMSSIG-Folder (usually C:\ as long as you didn't configure the "Software distribution" settings (Drive letter). Backup This!
SMS_[Your_Sitecode] DB Name and instance (The DB is already included in the backup!)
Servername and FQDN
Every Site System with its settings (Distribution Point, Management Point, etc...)

3. Do the following things:
Take away the network connectivity from the SCCM Server
Install a NEW SCCM Server on a NEW Machine using the SAME site code
Install the previously installed roles with the same settings you documented
Start the ConfigMgr Site Repair Wizard
Restore the site including the DB
Copy the SMSPKG and SMSSIG folders back

net stop sms_site_component_manager && net stop sms_executive && net start sms_site_component_manager

Open in new window

=> When everything's correct, this will also start the SMS_EXECUTIVE-Service.

Hope That helps :-)
I forgot to say: Ensure the new machine has full access permissions on the "System Management" Container in AD (if you extended your schema)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.