Public relations is a key concern in the world of SMS administration. Lord knows we are blamed enough for problems we don't cause. By focusing on the quality of the products that we deliver we can help to improve our customer's opinion of our work. Maintaining the proper balance of planning and testing is one way to improve the quality of your work. This article covers project planning and the use of testing labs for SMS projects.
In general, any project you are working on should have a written plan in place. This provides several benefits to you: it will help to keep you focused and enable you to more easily share your plan with coworkers and management. Management is more likely to "buy into" a written plan, and if they do, the plan can then serve to protect you. Written plans also allow you to look back and build on the success and/or failures of a project.
Formal plans should include an overview, general approach, scope of work, testing plan, implementation plan, implementation team, schedule, budget and a completion summary. Here's a brief description of each:
An overview is a very general description of your project. This may include background, reasons for the project and what you want to accomplish.
The general approach should be a detailed description of how you are going to accomplish the goals of the project.
Scope of the work should include all the systems and staff that will be affected by the implementation your project.
The testing plan is a very detailed outline of the "what" you will test and why you will test it. There should also be a detailed description of your test environment.
An implementation plan is a detailed plan describing how you will implement your product. The implementation team is anyone that has involvement with the implementation of the product.
The schedule should include dates for all items within your plan. Be as realistic as possible, so you don't have to change the schedule. It's good PR.
The budget should include all expenses necessary for your plan.
Don't forget (or skip) the completion summary. The summary can be extremely valuable for future reference. Here you want to include a description of the outcome of this project. It's important to include both positive and negative results. This will allow you to repeat the things that went right and change the things that didn't.
Some items that need a formal project plan could include SMS add-on components, adding new sites, service pack upgrades, server rebuilds and product evaluations. Large software distributions should be treated like projects. I don't see the need for a formal plan, but some sort of written plan should be crafted. It's in your best interest.
Acquiring an SMS testing environment, isolated from production, is invaluable. The need for testing many aspects of SMS is critical and should be an ongoing process. By having a dedicated testing lab you won't be as tempted to skip the testing process. This lab can be as simple as 1 primary server, 1 secondary sever and a few clients.
When I think of critical areas that require testing before release into an existing SMS production environment, a few areas come to mind: software distribution, service packs, component configuration changes and troubleshooting. Let's hit the "high points" of these issues.
Software distribution is a bit different than the others because at most organizations it's an ongoing task. When first beginning the process of creating packages, I would suggest using an isolated test environment. (It can be pretty easy to accidentally send a package to the entire company.) While in the test environment, try to get a pattern down for distributing software in production. Then document the pattern. After getting a feel for it, then move into production but stick to your pattern.
For company-wide distributions I suggest creating a test group at each site. Push to this group and require them to e-mail you indicating any problems (or a response that there were no problems). Many of the problems that have occurred for me were failures due to the way the new program interacted with existing programs. By giving your test group a few days to respond before pushing to your entire organization, these types of problems can be discovered, and hopefully, reported.
SMS Service packs are nothing like service packs for other Microsoft products. SMS Servers need to be upgraded in a specific order. Client access points and login points (NT domain controllers) will be upgraded automatically. Clients will update themselves, sucking down 5 to 15 MB of data from a CAP and requiring multiple reboots. Don't go completely on what other admins are posting on news groups and forums. These are excellent resources for finding pitfalls that others have run into, but they should definitely not be considered "the Gospel". You can 't be sure what exactly will happen unless run the upgrade in a close simulation of your production environment.
Component configuration changes can do some unexpected things. If you don't believe me just browse TechNet for awhile. Windows Networking Login Installation Method is a good example of this. Let's say I wanted to see what checking the "Modify Login Scripts" box would do. The outcome wouldn't be pretty if I tried it in production. Users would immediately begin running smsls.bat, even dial-up users, and it would only get worse from there.
Troubleshooting is pretty self-explanatory. A lab can give you the ability to recreate problems and try solutions without disrupting your users.