In the second year of my internship, I killed 90 computers (the only three labs in our school). By killed, I am talking full Blue Screen of Death that didn’t go away from a reboot. Each machine has to be manually reimaged. Worse, I had to reimage them with Ghost…
That hectic morning taught me two important things when it comes to testing. It would take a few more years for me to learn from two other common mistakes. Here are the four things that might save your job:
1. Create a Test Machine and Use Snapshots
Any modern machine can run a VM or two on it! With Windows 8, you even get Hyper-V natively built-in. This means that you can have a virtual machine setup in 30 minutes (at the most). This VM should mimic your production environment as closely as possible.
Whenever you are making a change in Group Policy that will affect security or the user interface, you should test it on the VM first. Doing this will let you catch the most common problems with new changes without hurting any production machines!
Not sure where to start? A while back, we wrote a Hyper-V guide for Windows 8. You can check it out here.
2. Have Test Users for Each User Scope
Speaking of User Interface changes, do you have test users for each user scope in your environment? For example, I support students, teachers, and administrators. By having a user created that mimics each scope, I can test changes more broadly to ensure a certain section of users aren’t impacted.
Because student accounts are more restrictive than teacher accounts, I can see if a User Interface change still effects them in the way that I intend. If you are concerned about the security of these accounts, you can use this script to automatically populate the Logon to Workstations attribute.
3. Setup a Sample Environment
This one is arguably the most important because it is often overlooked. We tend to make the jump from our test environment to wide spread deployment when pushing out new settings. What is needed is a middle ground, a kind of testing environment that has production use. To achieve this, create two security groups named:
- Sample Environment: Computers
- Sample Environment: Users
Populate each with a cross-spectrum of your full production environment. Try to include a computer/user from each department or section in your organization. When you are deploying settings or making changes, use these groups to bridge the gap between your testing and full use.
Your users probably know their software better than you do. When an update is deployed, they can detect smaller issue that would normally be overlooked. For me, if the software runs – it is working. It doesn’t mean that there aren’t issues though. You will probably want to ask for volunteers to your sample group first before drafting employees into your service.
4. Get a Second Set of Eyes
Anytime you are making a large or automated change, get a second person in on the action. This person might catch an issue that you’ve overlooked or spot a way to improve what you are doing.
I can’t tell you the number of problems that I’ve avoided by having a coworker check a script/deployment first. Often, it is hard to see the forest (fire) when you are in the trees. Because a coworker got to see it any changes before, you also get to share blame with them if things go south. 🙂
What are your suggestions?
These four tips have saved my job many of times! By setting up a virtual environment with test users, you can avoid common issues that your staff would immediately notice. By using a sample environment, difficult and insidious issues will be caught before becoming wide spread. Finally, having a coworker check with you on major changes will eliminate close-sighted errors.
What other practices do you use to cut down on IT-made mistakes? Do you make use of change control mechanisms? What issues have you caused (I’ve shared mine)?
Those are my three tips that will make your