Tied together with a service manager business service
Jimmy Martin (901) 227-8209 From: [email protected] [mailto:[email protected]] On Behalf Of Marcum, John Sent: Friday, January 08, 2016 10:57 AM To: [email protected] Subject: RE: [mssms] Patching servers with SCCM Sounds like a job for SCORCH. ________________________________ John Marcum MCITP, MCTS, MCSA Desktop Architect Bradley Arant Boult Cummings LLP ________________________________ [cid:[email protected]] From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Russ Sent: Wednesday, January 6, 2016 4:46 PM To: mssms <[email protected]<mailto:[email protected]>> Subject: Re: [mssms] Patching servers with SCCM Thanks for all the comments and suggestions. It would be nice if things were sort of moving in SCCM like they are in SCOM where you start to define the application, rather than the individual servers as much. So I could define the "Sharepoint" group for example, and I would be able to put all the servers in that group. Then it would have the intelligence when patching or whatever, to patch servers in certain order, at a certain time. Or if there is software you want to push to one server, it knows that if that server needs to be rebooted, it needs to boot these other two servers (or restart services, etc). At a previous place, we would use startup scripts that if a particular server got rebooted, it would reboot app tier servers because of that. But it would be nice if you had almost the concept of a task sequence across servers... maybe that's what Orchestrator is for... I unfortunately don't have as much experience with that. On Wed, Jan 6, 2016 at 7:55 AM, Sherry Kissinger <[email protected]<mailto:[email protected]>> wrote: We have several different server teams, and each have their own ways of doing things. In 1 case; where there is literally a tech for each server (those servers run something super critical, so those servers get 1:1 attention), patches are deployed to them "with no deadline"; and the techs interactively login, and select patches to install, and reboot when they can do so. Do I think it could be automated? yes. but those people are paranoid. :) We have another team which pretty much has everything scripted; ADR's + Maintenance windows on 10 or so collections (I think it's a mash-up of timezone and function, to split up install and boot times). They just monitor that it's going as expected via reports emailed to them from SSRS. I don't think they've been in the actual console in months... and another team in between--but that's because the strange things they have to support; often they have to "skip" a particular type of update and/or do more rigorous testing, so they have an ADR... but then have to usually tweak what's inside it. They still use Maint. Windows; but are more hands-on in the console with what's in the Software Update Group. But that's the beauty of ConfigMgr: you can be 100% human touch, or the extreme opposite, with everything automated. It just depends what your needs are. On Wednesday, January 6, 2016 8:46 AM, "Mote, Todd" <[email protected]<mailto:[email protected]>> wrote: We’ve been patching about 400 servers for a number of years that range from domain controllers to exchange, SQL, and everything in between. The TL;DR is “Maintenance Windows are your friend.” We have about 100 collections that are nothing more than maintenance window collections that servers get put in. I don’t admin all of them so the local admin lets us know what window they want and the server goes into that collection. Nothing is deployed to these collections, they only apply MW’s. We have separate collections where things get advertised to, like Software Updates. Each deployment has its own settings about whether to ignore or respect maintenance windows. Every deployment is always set to be available as soon as possible and deadline as soon as possible if it’s set to respect maintenance windows. Then, at the MW time, it patches and reboots. Our exchange 2010 environment is about 30 servers, CAS’s start patching on Thursday mornings and the mailboxes patch on Sunday mornings, the rest are scattered around between them and their windows don’t overlap. Domain controllers patch one a night over a week. If servers have clusters or some failover requirement we work with the server admin to set up automated processes to occur 10 minutes before the window begins to move resources from node to node to facilitate patching. We do this for failover clusters and FSMO roles on DC’s. If you have services that are resilient, and Microsoft doesn’t break anything with bad patches, patching servers is pretty easy, not much different than clients, to be honest. In fact, if you give clients maintenance windows too it works out great, everybody knows when their computers will reboot, but that’s another discussion. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Duncan McAlynn Sent: Wednesday, January 6, 2016 3:46 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] Patching servers with SCCM I have just a little experience in this… ;-) Honestly, I would strongly recommend taking a look at Infront’s OPAS solution that can make this almost a no-brainer. It really does help remove all the pain points you’ve talked about addressing. You can learn more at: http://www.infrontconsulting.com/opas [cid:[email protected]] Duncan McAlynn, Sr. Solutions Specialist, Americas HEAT Software M: +1.512.391.9111<tel:%2B1.512.391.9111> | [email protected]<mailto:[email protected]> HEAT Software<http://www.heatsoftware.com/> | 490 N McCarthy Blvd. Suite 100 | Milpitas, CA 95035 Ask me<mailto:[email protected]?subject=Why%20are%20you%20THE%20leader%20in%203rd%20party%20patching%20for%20Microsoft%20System%20Center?> why we’re THE leader in 3rd party patch management for System Center From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Russ Sent: Tuesday, January 05, 2016 5:00 PM To: mssms Subject: [mssms] Patching servers with SCCM We've been patching our servers with WSUS up until this point, but we'd like to move over to SCCM. I wanted to get an idea on how people are handling their 2 and 3 tier applications? Currently we have a number of different windows to patch the SQL servers, then app tier, then web tier or whatever. But what I am hoping is to make things a bit more well defined (and to start building collections for various applications and that sort of thing.) Do you suppress reboots on servers, and then send out a script for rebooting? Do you make maintenance schedules which would cause reboots in certain order? Do you patch or reboot manually? What sorts of methodologies do you deploy? It would be nice to put a process and methodology in place so that it's not reinventing the wheel for every individual group of servers. We don't currently have SCCM in place for servers, so that's all new as well. So we sort of have a unique opportunity to start fresh. Would appreciate any feedback or ideas you have give me. Thanks, Russ ________________________________ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. 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...
