Tips for Building SMS Test Servers
October 15, 2001
by Dana Daugherty
Sometimes, in order for you to recreate a problem in a test lab, the environment must mirror your production servers. If you've read many SMS Q articles from Microsoft you will get my drift. Hopefully, this article will help you to better accomplish your testing goals.
Here is an example; let's say we are trying to determine how our production environment is treating inventory from traveling laptop users. By traveling I mean to other SMS sites within one organization. Let's also say I have applied hot fix Q281107 to my production machines. (If Q281107 isn't applied to the test environment you're going to see a world of difference.) Production servers will insert inventory very nicely. Test servers will rebel (Check the link for more details about the Q; I also have a couple of articles on this site about it.).
In order to really see how a SMS server is going to react in a given situation you must get the test environment as close as possible to the production machines. There are a couple of ways to approach this. You can attempt to backup the production server then restore it to the test server. Or you can build the test server, paying close attention to each detail. Below I'll list a few tips for each method.
Restore the Production Server to a Test Box
While this method is a bit tricky, it will provide a sure method to take a snapshot of a server in production, move it to test and start whacking on it. If your server is going to be placed into a domain with a name other than the production domain you've got to do some "hacking". Below are some notes to help you with this.First, you will have to deal with a security issue. Before backing up the Site Server you will want to trust the test domain, create an account in the test domain with Full SMS permissions. Then grant all permissions to this account on the Server you are going to back up. You can now close the trust. If you use backup software like ArcServe or Backup Exec, disable all SMS and SQL services first. Perform the backup. Restore the server to the test box, be sure to include the registry and overwrite files with the same name.
Here are the registry locations and accounts you will need to edit:
Build a Server from Scratch
This approach can give you the same results. It's tedious in a different way. It will require you to go through each configuration on the production server and apply it to the test server. Applications, including service packs and hot fixes, need to be applied in the same order as the production server. Once the box is a twin of your production server be sure to disable the SMS and SQL services and get a backup. This method will be much easier to rebuild the test server after a testing scenario is complete, but you will have to apply any configuration changes and/or software updates to your backup.
It may seem like "overkill" for you to spend so much time on your test server. Using one of these approaches will help you to deliver a quality product. You will have the full story on a SP or hot fix before applying it. You will also be more likely to find solutions to SMS problems you are having in your enterprise.