In reference your first point, we now copy paste a collection query into a query to check what the change does or put it into a temp collection. Once confirmed, we paste the update into the live collection.
A summary dialogue that pops up when you create or edit a collection or advert that's tied to each other which shows you the targets ... Would be good. ---- Scent form may moo boil. Police doughnut excerpt Annie breathe city. On 20 May 2014 18:53, "Miller, Todd" <[email protected]> wrote: For me, there are two things that would help tremendously. First, I would like the option of automatically marking deployments/advertisements as disabled any time an underlying collection query was modified. This would prevent you from accidentally expanding a collection when you did not know/understand the consequences. If the collection query is changed, you need to evaluate how the membership changed prior to the advertisement being valid again for that modified collection. This has happened to me a few times. I always try to disable advertisements prior to modifying their underlying collections, but sometimes there are domino effects and it is not always clear what collections feed into others. Or maybe there are multiple adverts to the same collections that you aren’t necessarily thinking about. Second, I would like there to be a site-wide dashboard that as the Grand Poobah of SCCM, I could look at and see every pending deployment/advertisement. What package is being deployed, to what collection, and how many clients are affected. This is important not just from protecting from oopsies, but for resource contention too. I would like to see what other kinds of large deployments are scheduled for a timeframe before deploying or permitting others to be scheduled. Right now, there is no good way for me to look in SCCM and see what “stuff” is going to happen in the next 6 hours, 7 days etc. This can get complicated…. Somehow the dashboard would need to take into account the way collections update on schedules. There would need to be a way to tell what is going to happen when the collection updates at a certain time. I don’t know how to explain that very well… This is where most of my problems have occurred. Let’s say I have a collection of “Machines eligible for Software X” I have another collection called “Machines that need Software X” and it has as a limit collection “Machines eligible for Software X” “Machines that need software X” is set to refresh membership daily at 9:00PM. There is a standing mandatory advertisement for Software X that occurs in the distant past. When you look in the collection for “Machines that need software X” it should be mostly empty. Machines that need the software have installed it and then they are out of scope for the collection query. During the day, someone modifies the limiter collection incorrectly. That mistake is not evident until 9:00PM when the “Machines that need software X” refreshes on schedule and the software starts to deploy immediately. It would be difficult to see that that was going to happen. There would need to be some way to compute that the limiter collection was updated and that the Software X collection was going to be flooded with new members at 9:00PM. I hope that’s not too rambly and is understandable about the scenario that give me concern. I really think there is limited times when software is deployed to the wrong collection. For me it is standing advertisements that are deployed to a collection and then that collection gets modified or the limiting collection gets modified. So really the mistakes come from unintentionally expanding collections. From: [email protected] [mailto:[email protected]] On Behalf Of Aaron Czechowski Sent: Tuesday, May 20, 2014 11:51 AM To: [email protected] Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything Thanks all for the discussion. This is kind of how our internal debate proceeds every time it comes up…there’s really no bullet proof way to block this, but I don’t think that should be the intent. I’m a big proponent of a good default with control. For every scenario in which it should be blocked there are probably as many to have it on. One more comment – in R2 we now have the Check Readiness step (which can also be achieved in previous versions through MDT integration and the Validate step) to at least fail a deployment to a server (or vice versa). We’re also looking at ways to potentially improve upon this in the future. Aaron p.s. as always, none of the above is committed future work – just ideas in my head. :) From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of elsalvoz Sent: Tuesday, May 20, 2014 8:56 AM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything I don't think taking the ability to do something like deploying to "All System" collection would fix the issue because there other ways to re-create them such as a bad WQL that adds all systems. How about step in the TS to verify critical systems such as DCs, DNS, DHCPs, and others? I guess this can be accomplished right now though a script to identify these roles on a server How about a mandatory pop-up window with a timer (hint: powershell deployment toolkit) on the client only critical infra systems? How about a touch file that pauses the deployment like Johan does, use web services and/or orchestrator to send and email, receive a response and create the file? How about a SCCM deployment tab where critical windows roles (DC, DNS, etc..) like OS selection in the "requirement tab" of a program? Default is set to skip those critical roles unless selected. There are hundreds of innovative ways that can be provided currently to prevent such critical infra systems from getting imaged improperly at 'run-time'. On Tue, May 20, 2014 at 6:36 AM, Sherry Kissinger <[email protected]<mailto:[email protected]>> wrote: For all the reasons mentioned... it's really, really difficult to engineer against "oopsies" and/or just plain unfamiliarity with the tool... but you have full rights to everything (or close to everything). "Most" things can be prevented with good RBA design, training, and not just having had a 16 hour work day. But it's hard to engineer against little or no training, full rights to everything, and a long work day. All or any combination of those can turn a 5 second lack or attention to detail into a "oops". Note it may be possible to engineer something using SCORCH and status filter rules... but you have to be careful about licensing then. If you read the fine print of the Scorch licensing... it was meant for orchestrating server actions. and the way Microsoft interpreted it was that if you did something based on status filter rules from CM and sending instructions back to CM; you are "affecting a client"--i.e., potentially every single client in CM that you have. So pony up the $ for the expensive licensing for every single client. You may be able to negotiate something; but be aware of that if you are looking at status filter rule triggers and automation via scorch. It could end up costing you more than if you sent your people to training instead! Sherry Kissinger On Tuesday, May 20, 2014 8:18 AM, Ben Glenz <[email protected]<mailto:[email protected]>> wrote: Haha this reminds me on the first User Account Control Prompts i got.. :) You’re absolutely right, there is no 100% protection. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Stephen Murley Sent: Dienstag, 20. Mai 2014 14:51 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything Hmm, I’m pretty sure I could still mess things up even with that :) Yes? Click. Are you sure? Absolutely. Really? Yes. Oops. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jimmy Martin Sent: 20 May 2014 13:46 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything Maybe if there was an OS delivery require multiple admin logon to accomplish? Or deployment greater than certain % of env require same? As you say, it’s pretty tough to eliminate the opportunity to screw up. Jimmy Martin (901) 227-8209<tel:%28901%29%20227-8209> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ben Glenz Sent: Tuesday, May 20, 2014 2:26 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything I think there are several ways of improvement to prevent issues like this. In my opinion the All Systems collection shouldn’t be allowed in Deployments (all kinds) However, you will never ever prevent issues. E.g. I create my own All Sys collections, Membership Rule include All Systems. Same collection but without limitations. What about an RBAC feature limiting a User to a specific number of deployments. UserA is only allowed to deploy to a maximum of 50 machines? From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Aaron Czechowski Sent: Dienstag, 20. Mai 2014 03:08 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything We actually have several DCRs in a similar vein. Everything from what Damon suggests, to blocking deployments to “All Systems,” or blocking deployments to similarly large collections. Probably others that just aren’t occurring to me as well. Not saying we have any definite plans to do anything, just that it’s on our radar. Aaron From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Johns, Damon (DoJ) Sent: Monday, May 19, 2014 3:10 PM To: '[email protected]<mailto:[email protected]>' Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything Perhaps Microsoft need to introduce some form of change management control within Configuration Manager with respect to the Task Sequence Deployment types (or even all deployments really since an application or package can also cause problems when deployed to say all systems when you didn’t intend it to) – similar to what they have done with Advanced Group Policy Management available to those with SA. I’m sure there have been more of this that has happened – it’s just not been made public knowledge. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mote, Todd Sent: Tuesday, 20 May 2014 7:40 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything True, there’s always a bigger fish, but at least with RBA while you might be able to do it to yourself, you wouldn’t be able to do it to the SCCM server and EVERY machine in your enterprise, domain controllers and exchange servers included. No, those users wouldn’t be relieved that only their machines were ruined, but management might like to know that not EVERY machine was ruined, or could be ruined. If you can’t completely mitigate a risk, which in this case you can’t, contain it as best you can. Even the bigger fish shouldn’t be using the same account they used to install SCCM with. Sherry said it a couple of years ago, even the Full Administrators should scope themselves out of seeing All Systems. I think she put it somewhere along the lines of “…never open the console as god…” or something similar. If they were still using 2007… well, not much you can do there besides child primaries for security boundaries. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Miller, Todd Sent: Monday, May 19, 2014 1:23 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything RBA can only mitigate the scope of affected machines. So what if the damage were limited only to the machines you have rights to? Do you think your users would be relieved to find out only their machines were ruined? Remember, there is always someone else higher up in the hierarchy that can do more damage than you can. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mote, Todd Sent: Monday, May 19, 2014 12:49 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything RBA can help further here too. if folks can’t see the all systems collection, they can’t deploy to it either… From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Matt Wilkinson Sent: Monday, May 19, 2014 7:34 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything In 2012/SP1/R2 you do have to go through several screens to deploy a required OSD TS. Picking the All systems Computer collection is probably what happened. I only have access to test collections. I only deploy available applications for testing. From: Bruce Hethcote [mailto:[email protected]] Sent: 19 May 2014 12:29 To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything +1 It’s easy enough to put a condition at the beginning that would prevent a desktop OS TS from executing on a server OS. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Wallace Sent: Saturday, May 17, 2014 10:39 AM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything Or I guess that people could use the features which exist in the product such as security scopes and security roles. They could also do things like run a check via WMI or TSVs that a system is valid to have the TS run on it. On 17 May 2014, at 15:35, "Miller, Todd" <[email protected]<mailto:[email protected]>> wrote: This happens enough that you have to start wondering if the software could be improved in some way to help prevent it. Maybe there should be alerts or limits or a wizard that summarizes any change that affects a deployment or target collection. Like when you click OK, maybe there would be a "This change will result in NNNN systems receiving Package/Application "YYYYYYYY" with a mandatory time of 12:20AM" or something like that. The trouble is, you would need to do that every time you modify a collection too and that takes some computational time. - maybe that is computer in the background and you get this warning when you enable the deployment? Wouldn't it be nice if there was an option to create all deployments as disabled and then you had to enable them, and when enabling them you could see or were told how many systems are affected. You could also automatically disable advertisements when the underlying collection query was modified. So the advertisement would need to be reenabled after reviewing how that change affected the deployment. You know how your DVR shows what programs are going to be recorded over the next couple of days/weeks? Wouldn't it be great if SCCM showed a list like that of pending packages, deadlines, the target collection, the number of affected machines, and the time? With these kinds of events, there definitely is an established need to make the SCCM product harder to make unintentional blunders and easier to see what it is doing/going to do and when. Often with these kinds of things there is a long chain of events that lead to an unanticipated result. The worst part is that those machines that were ruined over night, SCCM probably "knew" it was going to happen all day long and could have warned the Admin if there was just a interface that computed what advertisements were pending, how many machines are affected etc.... I certainly would get more use from something like that than being able to manage iOS/MacOS/Linux/AntiVirus definitions/Android Apps/etc. Maybe SCCM v.Next can focus on doing core competencies better rather than extending the product into areas few care about. I dunno, I just don't think all or even half the blame falls on the guy that clicked "OK." I certainly feel a great deal of empathy for him. While this has never happened to me, it has sometimes been a recurring theme in bad dreams/nightmares. From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of JONES, RICK J [[email protected]<mailto:[email protected]>] Sent: Friday, May 16, 2014 5:33 PM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything EVERY person in IT has an OCM (Oh Crap Moment) that they remember or changed them. If a new tech haven't had their OCM yet, I tend to lock down access and not trust because the OCM has a higher chance of happen in my environment. And yes, I had my OCM, it changed how I add logging and build a back out to my scripts. Rick J. Jones Wireless from AT&T Domestic Desktop Application Management D: (425) 288-6240<tel:%28425%29%20288-6240> C: (206) 419-1104<tel:%28206%29%20419-1104> From: Murray, Mike<mailto:[email protected]> Sent: 5/16/2014 4:22 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Emory IT accidentally deploys Windows 7 to everything Wow.... ouch. So there's an opening at Emory? -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of William Jackson Sent: Friday, May 16, 2014 12:32 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] Emory IT accidentally deploys Windows 7 to everything I'm thankful that I do not work over there. "A Windows 7 deployment image was accidentally sent to all Windows machines, including laptops, desktops, and even servers. This image started with a repartition / reformat set of tasks. As soon as the accident was discovered, the SCCM server was powered off – however, by that time, the SCCM server itself had been repartitioned and reformatted." http://it.emory.edu/windows7-incident/ William Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. DISCLAIMER: This is a PRIVATE AND CONFIDENTIAL message for the ordinary user of this email address. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 1E to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. _____________________________________________________________________ This email has been scanned by the MessageLabs Email Security System on behalf of Leeds College of Building. For more information please visit http://www.symanteccloud.com/ _____________________________________________________________________ _____________________________________________________________________ This email has been scanned by the MessageLabs Email Security System on behalf of Leeds College of Building. For more information please visit http://www.symanteccloud.com/ _____________________________________________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. CONFIDENTIALITY NOTICE AND DISCLAIMER The information in this transmission may be confidential and/or protected by legal professional privilege, and is intended only for the person or persons to whom it is addressed. If you are not such a person, you are warned that any disclosure, copying or dissemination of the information is unauthorised. If you have received the transmission in error, please immediately contact this office by telephone, fax or email, to inform us of the error and to enable arrangements to be made for the destruction of the transmission, or its return at our cost. No liability is accepted for any unauthorised use of the information contained in this transmission. This message and any files transmitted with it may contain legally privileged, confidential, or proprietary information. If you are not the intended recipient of this message, you are not permitted to use, copy, or forward it, in whole or in part without the express consent of the sender. Please notify the sender of the error by reply email, disregard the foregoing messages, and delete it immediately. P Please consider the environment before printing this email... [Image removed by sender.]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, Plymouth University accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. Plymouth University does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form. ________________________________ Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you. ________________________________ ________________________________ [http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass> This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, Plymouth University accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. Plymouth University does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
