Hi everyone, Lee Stevens here. Sometimes, we have deadlines. The root word of deadlines? DEAD. This being said, I've been asked many times how packages can be tested in a quick manner without the added overhead of System Center Configuration Manager 2007 (ConfigMgr).
The goal here is to make a specific, measurable, and predictable process from software distribution. However, the client shouldn't play a role here.
Before moving forward, why would we remove ConfigMgr 2007 from the equation?
- First and foremost, we want to make sure the package and program works. We want to know if the icons appear correctly to the user. The main reason for this? An exit code of 0 (success) means nothing if the program crashes on load from the user.
- Secondly, the process by which we are testing here is not concerning itself with Config Manager client health or functionality. We can assume that the client functions will all work, as they do in production with other packages. This is a method meant to speed up the process and remove other elements from the equation.
What about the environment?
- This is actually simple, and for anyone who knows me, less is more.
- Always recommended is a virtual environment, since snapshots and undo disks are one of the greatest of all technologies.
- The environment does not require any servers, especially ConfigMgr ones. The only systems needed are of the same OS and build that will be members of collections that your advertisement will be targeted to.
- To add to the last point, if a program is to run on 10,000 clients and only 118 of them may be different, test to the biggest audience first. The other 118 clients can be tested and/or fixed later. You run a greater risk of breaking a package and program for the majority by trying to mod it for the 118 than letting 9,882 successful installs through.
An example:
You have a corporate image running Windows 7. You would lay down the image to a virtual machine, create a snapshot, and then you are ready to go. You are not out to test anomalies, but the base.
The Process:
This is how ConfigMgr 2007 runs a package. Here are the steps that you can use to test the package:
- Create a snapshot
Don't need to explain why here.
- Copy the Package to the local disk.
ConfigMgr copies this package to the CCM cache, but anywhere on the local drive is fine.
- Log in as the SYSTEM account.
The SYSTEM account is used for software installs so a useful tool for testing in the administrator context is psexec.exe. PSExec can be found in the PSTools suite from SysInternals. A simple "psexec -s cmd.exe" will bring up a command window. When you do a "whoami" (may not work on some OSs), you will see the security context by which the command prompt is running (in this case, the system account). Task Manager also will show cmd.exe in the SYSTEM context.
- From the command prompt, change to the folder that holds the downloaded package.
- Run the exact command line from the package and program you're desiring (with arguments).
Optionally, I would also look for logs that that the installer you are running leaves behind. It's always good to have an install log, so I recommend adding this argument to the command line once you've tested the original.
- Wait for program completion and test.
- Revert to your snapshot, prepare for the next program.
- Rinse and repeat
Some tips
Of course this list is not all inclusive but here are some things to look out for:
If the program has been running for an unusually long time, it could be that the program is waiting at a prompt. ConfigMgr has a program run-time limitation of 120 minutes by default, after which it will time out. From the command line without the ConfigMgr client? Indefinitely, so it’ll run until you stop the process.
Make sure to spot test the app once it installs. You want to be sure that the icons appear where you want them, the program delivers the functionality you're looking for, etc. Again, a successful install doesn't mean the app won't crash when a user brings it up.
Examine the logs to make sure no errors are being generated or if something comes up (or doesn't) unexpectedly.
In Conclusion
This is a very quick way to test packages to make sure they are ready for production in ConfigMgr 2007. You will most certainly have more time to add value to the testing by leaving out ConfigMgr and testing the actual end user experience. I could dare to say you'll have more time to test more packages as well.
Happy testing!
Lee Stevens (Config Manager, OS Deployment) | Microsoft Corporation
App-V Team blog: http://blogs.technet.com/appv/
AVIcode Team blog: http://blogs.technet.com/b/avicode
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
OOB Support Team blog: http://blogs.technet.com/oob/
Opalis Team blog: http://blogs.technet.com/opalis
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
SCMDM Support Team blog: http://blogs.technet.com/mdm/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/
