Staged Delivery of SCCM Packages
I'm looking for a best practice for deploying mandatory assignment SCCM applications in a staged fashion. The main goal is to catch exceptions missed in testing before the application borks every computer in the enterprise.
We have created collections starting with a small group of testing computers and IT dept then adding more computers to each subsequent collection. I like the idea of creating advertisements for each collection and setting the assignment time so each one starts a few hours after the previous. This does make the reporting a bit harder, checking and reconciling logs from each advertisement. The other method I'm considering is one advertisment in which we change the target collection every few hours. This has the disadvantage of not being able to schedule the entire deployment in advance. It does provide a single log file for the entire deployment.
Before VBSCAB suggest we do a better job of testing our packages, we don't manage the configuration of all our clients so there is some risk of a configuration unknown to us causing an exception in a package that was thoroughly tested. I'm interested if anyone knows of any caveats creating many advertisements that overlap somewhat in the target computers or changing the target collection on an active advertisement.
Answers (2)
You could consider putting these installs in a Task Sequence. for each "install software" task you can then set the sequence to quit on failure. Only requirement is that the SCCM programs for the packages that you want to use don't allow interaction with the user during install, since otherwise you will not be able to use them in a task sequence at all.
This way of working would ensure that a failure in one of your packages stops the installation process, at which point you could do the necessary troubleshooting.
Comments:
-
If I understand what you propose, each step of the task sequence would advertise the same package but to a different collection? I'm not sure how I would do this. - rlinhartpdx 12 years ago
-
No, wait, I might not be getting what you want to do entirely. I think you mean a staged install as in, one package to install to an ever increasing number of clients for as long as nothing goes wrong? I was thinking about installing a number of packages to clients, but to only keep installing new packages as long as the previous ones finish successfully..
Let me get back to you on this one :) - pjgeutjens 12 years ago
I'm wondering if your issue is not more in the realm of correct package behavior rather than SCCM deployment strategy...
To be honest, the statement that failed installs could "bork every computer in the enterprise" means that your packages themselves do not handle failure correctly. While I absolutely am in favor of pilot testing, it should never be the case that a failed package installation could cause such irreparable damage to the machines that it would keep you from getting the install finished successfully after some troubleshooting.
Piloting is always gonna be a bit of a 'hands on' activity, but imo, after a successful technical validation of a package that includes rollback behavior, and a pilot, you should be able to trust in the fact that subsequent installs will either succeed, or if they fail, will not break target machines. Key factor also is to have as representative a pilot group as possible, so as to cover a large number of scenarios.
For populating pilot rollouts your techniques seem ok to me, maybe you could consider putting pilot machines in a separate group in AD and using dynamic collections for your distributions, populating them based on AD group membership. To me it does not seem like a good practice to link the pilot and main rollouts together in too tightly a fashion. They are different steps in a rollout process that SHOULD have some time between them.
as always, this is just my 2c ofc
PJ