Fixing an OSD “oops”
There is a story that goes around PFE circles and that I have told myself so many times I’m starting to wonder if it is true or legend. The story is about a SCCM admin who is testing a failing Win7 deployment against his test machines with OSD and is so tired and frustrated that he kicks off another test run and heads home only to get a call from his boss shortly there after. The boss wonders why his machine is about to run an OS deployment and the admin then realizes he mistakenly targeted the “Al Systems” collection and not “All Test Systems” collection. Seeing as how his SCCM environment managed both workstations and servers this is super bad so he goes rushing back to fix things and a call comes in to PFE on what is the fastest way to stop an OSD deployment in progress.
True or not, there are lessons to be learned from this story and I tend to share them to help folks be careful in their OS deployments. Here are some points to consider so that this never happens to you (or you can stop it if it does)
- Never name test collections anything like a production collection! Name them something obvious like “TEST---MY TEST OSD MACHINES”
- Avoid mandatory OS deployments when doing testing. You should be able to validate almost all your test scenarios with a user initiated deployment. The last step would be to do it with a mandatory advertisement, if necessary.
- Connect to each DP and rename the folder with the OS WIM file in it. If they can’t reach the WIM they can’t proceed. Doing the same for the WinPE WIM may also be useful. You can rename back once the crisis is over and avoid copying that large file out to DPs again had you deleted it.
- Disable the TS advertisement to stop machines from getting it that haven’t already updated their policy.