Preventing Operating System Deployment On Servers And Other Critical Client Systems

An uncharacteristically short one from me today; although normality will soon be resumed!

There isn't usually much scope for catastrophe in the daily workings of ConfigMgr and very few companies I know of would consider it a business critical application. It is, however, often used to manage servers and even desktops that are running business critical applications. Despite the small scope for things to go horrendously wrong, any collection containing all systems can do just that. A mis-advertised Task Sequence or a poorly written collection query can suddenly target your entire environment with an Operating System Deployment.

 The use of mandatory advertisements can exacerbate the situation. Best practice would be to not use them at all for deploying operating systems, but that's not realistic for real life scenarios and when you require zero touch installation there's no way round it.

 The upshot of this is that you, as a ConfigMgr administrator, need to be very careful when creating the collections, task sequences and advertisements for deploying operating systems in your environment.

 Maintenance windows offer a certain amount of protection, but they are not infallible. User initiated advertisements, from the Run Advertised Programs applet do not honour maintenance windows as it is assumed that user interaction implies awareness and forethought of the actions being carried out.

 

 

 

 Creating a maintenance window for a collection 

Secondly, it's easy and quite feasible for an advertisement to be set up to ignore maintenance windows, and the task sequence will carry on its merry way.

 Ignoring maintenance windows during deployment

 

Third, but less likely, it is the possibility of a maintenance window clashing with the erroneous deployment and allowing the task sequence to continue. This possibility can be addressed by having a second maintenance window to disallow operating system deployments all of the time.

 

 

 Limiting a Maintenance Window to OSD Task Sequences Only

 

But again we loop back to the first situation where user interaction will allow the task sequence to continue regardless!

So what can we do? Good processes are the best defence. Some companies have a tiered system where those who create programs, collections and task sequences do not have the requisite permissions in the console to create advertisements. Instead they submit a request and a second administrator is able to review the collection and task sequence before creating the advertisement.

 There is still always more we can do. A belt and braces approach if you will.

By using Task Sequence Variables and logic we can protect critical clients such as servers from the day to day desktop deployments that might be undertaken in the same environment.

 The first step is to create a collection variable against the collection of resources we wish to protect.

 

 

Creating a Collection Variable

 

Setting a Collection Variable

Now update our existing task sequences to check for the presence of the variable. Do this by creating a new group with the rest of the task sequence nested within it and set logic to only allow the Task Sequence to run if OSDAllowed is not equal to FALSE.

 

 

 

Adding task sequence logic to prevent unexpected rebuilds.

Now whenever a client within the specified collection tries to run the task sequence it will gracefully close out without damaging the current install. This will be the case regardless of maintenance windows, advertisement type and even for user initiated execution. As long as the variable is set at the collection and the logic is present the client will be protected.

What if I want to re-image a machine? I hear you ask, either create a collection of target machines you wish to re-image, although this opens you up to all the issues I discussed above, thus bringing the value of this process into serious question

Personally I would opt for the scenario of individually allowing clients to run task sequences. To do this set a variable on the client object in the console which will override that set at the collection level.

 

Creating a variable on the client

Don't forget to remove the client variable once the required rebuild has taken place.

I'm not offering this as a golden scenario that prevents undesired rebuilds outright; it's by no means infallible. At the end of the day, the onus is always on the ConfigMgr administrator to implement processes to ultimately prevent this from happening. That doesn't mean, however, that there aren't different tools you can use to reduce the risk, and this should hopefully reduce the potential of catastrophe!

 

If you do implement this my last word of advice would be to not forget to ensure any new task sequences you create have the necessary logic to protect your valuable machines!

 

Ok, not quite as short as i promised but that was before i got trigger happy with the snipping tool

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

This post was contributed by Rob York, a Premier Field Engineer with Microsoft Premier Field Engineering, UK.

Comments

• Anonymous
  May 06, 2013
  Nice!