I have currently ran into an issue that our SCCM server needs to be rebuilt. SO what we have done is virtualized there server in its current state so that it is still running. I am about to rebuild the server. Is there a way that I can restore our current sccm enviroment using the same site code and a different server name? Our current sccm is down and barely functioning. I also want to move the SQL database to a remote server (so the backups will backup our database as well and avoid this issue) Any thoughts?"You can't fix stupid!"

In addition to what Torsten it's not required to use any backup mechanism outside of SCCM to backup the SCCM database because restoring from any backup created outside of SCCM is unsupported and likely won't work. Moving SQL off the box is asking for headaches. Keep it local. John Marcum | http://myitforum.com/cs2/blogs/jmarcum |

Best Practices is to keep SQL local. http://technet.microsoft.com/en-ca/library/bb735870.aspx, but if you do move it remotely expect to add 5-10 days to the project to get this setup correctly. http://www.enhansoft.com/

The reason I wanted to move the database off the local box was to avoid the problem we just had. Currently our backup's were not backing up the SCCM Backups and the database. (I am taking over for someone so I cant tell you just yet how the backups were setup) . Had our backups been backing up the database as they should I could just rebuild it and restore from a backup. Currently, the only backup I have is a bad backup. So currently I could probably get our old SCCM up temp (after I get some space on the drive to recover it) is there a way to replicate the settings to a new site easily? I am thinking it would probably be best just to start over and not bring over the bad setting but we have a rather large site and a lot of packages I guess its a catch 22"You can't fix stupid!"

Not knowing your environment, I can't say which would really be the best choice for you. Based on your comments, my guess is that you might be better off starting fresh: new servername, new site code, and deal with the unfortunate need to re-create any packages. You'd know the configuration was done as you expect (because you did it). Chasing down bad config from a bad restore would (in my opinion) be a lot of frustration.Standardize. Simplify. Automate.