For those of us that have used System Center Configuration Manager for years know that sometimes accidents happen. A task sequence is horribly misconfigured, the wrong Collection is chosen, a button is clicked too quickly, and all of a sudden all the disk drives in all the computers and servers in the organization are running FDISK.

You think I'm kidding?

In 2012, HP consultants, working at Australia's CommBank, took down the entire organization with a Task Sequence that formatted the disks of 9,000 PCs and 490 servers (including domain controllers). The repair took a couple weeks and brought so much worldwide news attention that HP's CEO, Meg Whitman, had to make a special, unplanned trip to Australia to help calm everyone down and apologize to retain CommBank as a client. I'm sure part of that apology involved monetary promises, but still…

So, you think this was a single, isolated and unique case? Not a chance.

In May of this year, a similar event happened to Emory University. In Emory's case, the university's IT department was in the midst of a Windows 7 rollout, trying to beat the Windows XP end of life deadline. Instead of targeting just those computers that needed the Windows 7 upgrade, the ConfigMgr admins dropped the upgrade on the ALL Computers Collection. This resulted in Windows 7 being delivered to every computer in the organization, including laptops, desktop, and servers. Can you imagine rolling into the office the next morning and seeing servers completely wiped of data and booting into a Windows 7 screen?

And, these two are just the reported events from those unlucky enough for their woes to go public. It happens a lot more than you realize.

In the past, when ConfigMgr was called Systems Management Server (SMS), many joked that 'SMS' actually stood for 'Slow Moving Software' because software delivery (and other file transport functions) was like watching a pot boil. It was excruciatingly slow. End-users would request a software installation, the admin would package it up and send it on its way, and then the end-user would call back in 20 minutes and ask, "Hey, did you forget me?" You'd say, "No. It's just slow getting there. Just be patient." A couple hours later and the phone would ring again from the same, impatient user and the process would start all over again. If it was a critical installation, sometimes the admin would just have to skip SMS altogether and run to the user's desk and install it for them, manually.

Times have changed and Microsoft has greatly improved its endpoint management application. The improved infrastructure now allows for much quicker communications between processes, services, and clients computer and devices. But, even since the early days of the product, admins wanted to be able to halt operations should something go awry. In the new improved model, a minor oversight can cause serious problems, as shown in the examples of CommBank and Emory University.

Fortunately, for those long-time ConfigMgr folks who have been demanding an "all stop" button for years, can now breathe a sigh of relief. Included in a gaggle of new features incorporated in OneSite 4.0, Adaptiva's latest version of its popular ConfigMgr integration suite, is a new feature called: WAN Pause/Resume. Essentially, this is the "big red button" that ConfigMgr admins have been asking for.

WAN Pause/Resume enables admins to stop all ConfigMgr-generated WAN traffic instantly. Later on, you can choose to resume everything just as it was, but better yet, you can halt operations long enough to make adjustments, completely eliminating the accidental delivery problem. If only HP and Emory would've had access to this.

There's many other new features and functions included in OneSite 4.0, but, for many, the CYOA option, alone, is probably worth the price of the entire product.

You can read more about OneSite and get a free eval from Adaptiva's web site here: http://www.adaptiva.com/onesite/

OneSite Overview from Adaptiva on Vimeo.