How can SCCM Admins Immediately Stop Accidental Deployments

2
Can SCCM Admins Undo Accidental Deployments Guide

We have been hearing loads of stories about SCCM causing accidental deployments, reimaging desktop, laptops, and servers. Can SCCM admin undo accidental deployments? In this post, we will see how SCCM admins can undo accidental deployments without causing any impact. But the fact is SCCM itself can’t cause inadvertent deployments rather SCCM Admins can be a cause for this kind of unfortunate situations. There are loads of incidents where SCCM admin came to know that he/she made a mistake and he wanted to undo the changes. Yes, he/she can undo the changes, but the bigger question is whether this will help to stop the deployments?

SCCM is a very powerful tool, and these broad powers of SCCM should be used with loads of care. SCCM admins can take actions to stop the accidental deployments. The exclusive list of actions which SCCM Admins can take in case of accidental deployments is explained by Shaun Cassells in the following post “How to Stop SCCM Advertisements with Immediate Effect“. SCCM evolved very well, and we can have Role-Based Access Control (RBAC) to provide proper controls to admins and not to give anyone more power which is not required for their role. The accidental deployments of applications, packages and deployments to users and devices could cause a big impact to the organizations.

How can SCCM Admins Immediately Stop Accidental Deployments 1The bigger question is Can SCCM Admins undo accidental deployments? Do they have any out of box controls in SCCM to STOP the deployment they initiated by mistakenly? My answer to that question is NO. SCCM is still missing that big RED button to stop all the initiated deployments. Natively, SCCM / ConfigMgr doesn’t have any mechanism to stop the package replication or traffic over the WAN immediately. However, we can have some workarounds to stop the SCCM WAN traffic.

Apart from accidental deployments of applications, packages, and task sequences, the accidental distribution of packages to larger group SCCM DPs can also cause big impacts in your organization. I have a bad experience with this personally. SCCM admins can easily undo the accidental deployments and distribution of packages without going through the tedious process which is explained in the above post.

Only Adaptiva OneSite gives SCCM admins a real-time dashboard with a detailed display of in-progress ConfigMgr WAN transfers, plus live control to reprioritize, pause/resume or cancel them. Admins can use the LiveFlow dashboard to move an urgent delivery, such as a security fix, to the top of the queue to instantly begin delivering it worldwide. In-progress jobs are paused and later resumed automatically. LiveFlow also reveals where content is stored in the peer-to-peer network, worldwide. More details about this feature in the following post “Datasheet: Content Visibility and Control with OneSite“.

How can SCCM Admins Immediately Stop Accidental Deployments 2WAN Pause/Resume (make this mainly about LiveFlow, but the big red button is considered part of it now) Adaptiva OneSite lets administrators instantly pause/resume all SCCM WAN traffic by pushing a button. If a rollout needs to be stopped for any reason (e.g., it contains an error or virus) before it gets deployed on hundreds of thousands of systems, this “big red button” immediately halts all network activity worldwide. Never before have administrators had the power to stop all content delivery in its tracks globally!

How can SCCM Admins Immediately Stop Accidental Deployments 3

2 COMMENTS

  1. The design of SCCM over the years hasn’t helped. There should be separate permissions to enable adding records to a collection vs creating a query (especially when the default query adds ALL machines to a collection)…

  2. Hi Anoop,

    There are a couple of extra things that can be done now with some of the newer features offered by current branch CM2012 in addition to the options presented in Shaun’s good but arguably now in need of updating article (after all it dates back to SCCM 2007 and predates CM2012 CB capabilities).

    You now have the ability to force a policy update on all currently online systems within the console via the client notification right click option. That would allow you do modify the deployment to say expired, or set a requirement on the deployment type to an OS you don’t use or a memory requirement that no device will have, or a dependency app that isn’t deployable… anything that means no device will be able to run it. Then all you do is force the policy update notification to all online systems.

    That allows you to still report on where the errant application did install before you were able to halt it. It will also stop it as fast as policy can get out and does not rely on clients refreshing policy. It also means you don’t have to utterly break what is probably otherwise a reasonable application that would be just fine to deploy only so long as correctly targeted and does not involve doing nasty things to your DPs that may take time to recover from.

    Of course it wont help you if an msiexec has already downloaded and been triggered and is in the act of installing, but then none of the other options helps you when you get that far. You could possibly force a reboot (after all there are right click console tools that will do it for an entire collection)but that would be something I would only consider in an extreme emergency and may cause more damage to systems than allowing the install to complete and then uninstall it again afterwards. Still not a big red button by the client notification mechanism could get you out of a hole about as quickly as is possible without breaking the infrastructure to do it.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.