>>I don't think adding more steps or manual checks to process is the right answer. Especially in a world where business is clamouring for more agility and speed, rather than more bureaucracy in the name of risk management.
I'm going to disagree with you, Ken. Yes, it is possible to break any process, if you choose to be perverse enough or negligent enough, but checks and balances are there because the alternative are worse. I'll bet that the people who might have clamoured for more speed and agility at Emory are likely to be somewhat more subdued this week, because they lost a lot more than they gained. The reason we generally require two people to launch the nuclear weapons rather than one person is that the penalty for doing it hastily far outweighs the penalty from having two people involved in the process. The system has just enough checks and balances when you can definitively blame one or more parties for negligence or malicious intent for subverting the protection systems. If "that could have happened to anyone" then there's too much slackness in the process, or the business risk is pretty low and therefore doesn't warrant the extra work. I think it is pretty safe to say that you never ever want your SCCM system to send itself a package that turns it into a Windows 7 machine, so that check needed to be in place, at the very least. *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> *Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market...* On Sun, May 18, 2014 at 10:17 PM, Ken Schaefer <[email protected]> wrote: > Personally, I don't think any of these things will help. > > > > When creating a change record, the exact steps to be followed are > documented. If someone either: > > a) Creates the wrong documentation, and it's approved by CAB > > b) Creates the right documentation, but someone either fat fingers > or doesn't read the doco > > Then creating these extra steps is just process inflation. > > > > I don't think adding more steps or manual checks to process is the right > answer. Especially in a world where business is clamouring for more agility > and speed, rather than more bureaucracy in the name of risk management. > > > > If you look at the stuff coming out of CEB or Gartner, we need things like > leaner processes, cross-skilled teams better able to understand > implications across multiple towers, orchestration/automation tied to > process and bunch of other things I don't remember off the top-of-my-head. > > > > Cheers > > Ken > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *CESAR.ABREG0 > *Sent:* Monday, 19 May 2014 12:07 PM > > *To:* [email protected] > *Subject:* Re: [NTSysADM] A Windows 7 image was deployed to EVERYTHING. > > > > Verify the number of clients in collection before using to deploy a TS to > it? Verify that the dynamic collection being use contains the intended > clients? Verify that the 'all system' collection is not a target? > > There could be more but a couple of that I can think of. > > > > Most this situations happen by human errors and inexperienced as well. I > think HP consulting did it at a bank a couple of years ago and some that > colleagues have shared with me that happened in a USA government branch. > I've been doing imaging over 10 years and I never do mandatory deployments > to populated collections, only to empty ones and I add clients manually or > have a process to do so. > > > > This got me thinking of steps that can be taken or be part of a TS to > prevent this type of situation up to an extend, can't never be prevented > completely. > > > > 1. Put a step that verify DCs and other critical infrastructure systems > and have human click yes before moving forward or fail if no response. > > 2. Creat web service/orchestrator to send email or a type of notification > to a group before continuing. Automated. > > 3. What I've used in the past. Create an empty collection, deploy TS to it > as mandatory, add required systems manually or by script from a list. Limit > who can add systems and the type of client, like no DCs or SCCM systems. > > > Cesar A. > > Meaning is NOT in words, but inside people! Dr. Myles Munroe > > My iPad takes half the blame for misspells. > > > On May 18, 2014, at 5:31 PM, Ken Schaefer <[email protected]> wrote: > > I'm assuming someone clicked the wrong button (i.e. "Finished", when > they should've clicked "Cancel"). How does "process verification" (how do > you define this?) help? > > > > Cheers > > Ken > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *Rankin, James R > *Sent:* Monday, 19 May 2014 2:59 AM > *To:* [email protected] > *Subject:* Re: [NTSysADM] A Windows 7 image was deployed to EVERYTHING. > > > > I think I may use this as an example in an article about the importance of > process verification. > > Sent from my (new!) BlackBerry, which may make me an antiques dealer, but > it's reliable as hell for email delivery :-) > ------------------------------ > > *From: *"Andrew S. Baker" <[email protected]> > > *Sender: *[email protected] > > *Date: *Sun, 18 May 2014 12:55:37 -0400 > > *To: *ntsysadm<[email protected]> > > *ReplyTo: *[email protected] > > *Subject: *Re: [NTSysADM] A Windows 7 image was deployed to EVERYTHING. > > > > Automation leads to relaxation... > > ...unless something goes horribly wrong. > > > > > > > > *ASB **http://XeeMe.com/AndrewBaker* <http://xeeme.com/AndrewBaker> > *Providing Virtual CIO Services (IT Operations & Information Security) for > the SMB market...* > > > > > > On Fri, May 16, 2014 at 10:40 PM, Richard Stovall <[email protected]> > wrote: > > Wowzers. That's just incredible. > > On May 16, 2014 8:14 PM, "Kennedy, Jim" <[email protected]> > wrote: > > So SCCM sent win 7 to everything, including servers. > > > > http://it.emory.edu/windows7-incident/ > > > > > >
