Update information Guide updated 2018/08/13 Software Update management is not the simplest SCCM tasks. Over the years, we trained many SCCM administrator using a simple approach and deployment strategy. We finally decided to create this complete SCCM Software Update Management Guide. This guide is a best-practice guide on how to plan, configure, manage and deploy software updates with SCCM. This guide aims to help SCCM administrator understand the basic concept of each part of the patch management process.
This guide does not explain. There are other ways of doing software update management in SCCM, this document describes a typical case that can be used in any organization as a good starting point. It’s impossible to cover every organization needs and requirements in a single guide.
Im assuming most everyone here has SCCM in their environment, but do you use it for patch deployment? How do you use it / what is your policy? If not, why did you stick with WSUS?
What is your environment like? Dont have to be super explicit with your answer, I am just curious how different everyone is. In my time as a consultant, I find that most companies and schools and government offices either dont know how to patch period, are afraid of SCCM, use it almost as a sort of novelty, or poke at it in a test bed but still continue with their WSUS practices.
Never encountered a client that had it running efficiently when I joined, would say your observations are very common. I have been following this best practices guide: To summarize, patch groups software update packages are broken up by year to stay under the 1000 update per deployment rule: 2003-2010, 2011-2012, 2013, and 2014 2nd Wednesday of month ADR runs to create a new software update group package with all updates released within past 30 days. It automatically creates everything, but I have it set to come out disabled. A human can review the patches to determine if needed prior to enabling the deployment to a group of internal it testers.
At end of week if all went well deployment is advertised to a 'patch tuesday test group' which contains power users from every department. The following week the updates are advertised to the entire company. (servers excluded, as they are handled by a different group process) At the end of the year I manually roll patch tuesday groups packages into one yearly deployment (2014 in this case). I only patch servers here and we've got 2 pre-prod environments and a single prod environment.
The schedule looks like: Patch Tuesday happens. We have a meeting about the patches where everyone agrees/disagrees on the approval of patches.
Usually runs less than an hour. Later that week - I'll update my Update Groups. Usually it involves cleaning out superseded updates from the older groups and adding the new updates to the rollup groups.
All of 2014 (Add new updates, clean out superseded stuff). 2003-2010 (clean out superseded stuff). 2011-2013 (clean out superseded stuff). All updates for Server2003 (Add new updates, clean out superseded stuff). Aaytha ezhuthu.
All updates for Server2008 (Add new updates, clean out superseded stuff). All updates for Server2008R2 (Add new updates, clean out superseded stuff). All updates for Server2012 (Add new updates, clean out superseded stuff) Right now we're in the middle of a 'getting systems caught up', so I've been deploying the 2 groups, 2003-2010 and 2011-2013, here and there as I can. In a normal month I'll only be deploying the 2014 update group and the rollup as needed. Instead of using OSD and offline image servicing we've got a 'staging' collection that all new machines are added to and the rollup groups are deployed to that so they can get patched up after the OS is installed. It's a fight I've been fighting for quite a while:/ Back to schedule 8 days after Patch Tuesday: Pre-Prod environment #1 gets patched. 15 days after Patch Tuesday: Pre-Prod environment #2 gets patched.
25 days after Patch Tuesday: Prod environment gets patched. 2nd Saturday of the month after Prod systems get patched: Messaging systems get patched. It's over-complicated and a result of managers with only the faintest understanding making decisions. That's the million dollar question - how do I do it LOL The team I work with, for intents and purposes, is me, my boss (technical lead), and another Senior Engineer.
I got brought on as 'the SCCM guy' but lucky for me the other 2 guys have enough knowledge about it to help out. As far as the time consuming stuff goes, I just got a junior guy a few weeks ago and he's started working through the backlog of applications to be packaged. My best advice if you're in a position to start designing a solution - if the plan is to use SCCM fully, you'll want to make sure there are several people mostly dedicated to just that. I've found that a pair of overworked people (this is IT afterall) can get the job done. If you want it done right, you'll need a team.
'A team of people for just one application?!' Is usually the response, but if you call out everything - Updates/Antivirus management/Operating System Deployment/Application Deployment/Hardware Inventory/Software Inventory/Baseline Management/Client management - and evangelize SCCM not so much as just another application but more of a management layer, you'll get a better response from management when trying to staff. I was mostly asking how you would structure the update process if you had free reigns, instead of how the company does it now. You had expressed that you felt it was over complicated.
I work with about 15 different SCCM environments off and on already. Some smaller environments are managed by myself and another guy in occasional ad-hoc support haha.
Then there are some bigger companies that I work with who have a whole SCCM team, which is really nice to see. Im just trying to get an idea of how everyone does things and why, and what they see wrong with it, to perhaps see if I can apply those perspectives to other environments. Usually the IT dept is either too small and way over worked, or too big, and somewhat lazy. (some skilled and some not) I prefer the lazy and smart because they seem to be happier and they work smarter rather than harder. I usually breathe a sigh of relief when I find that the folks Im working with have requisite knowledge, otherwise it's throwing spaghetti at a wall for a week till we get moving. We're making progress to getting it my way by getting all systems caught up. Once they're caught up I'll maintain 5 Software Update Groups every month.
1 that contains this year's updates and the other 4 each will be dedicated to each server OS from 2003-2012. The only new deployments that will occur each month will be the Current Year Software Updates group to each of the 2 pre-prod, the messaging systems, and the single prod maint window.
A grand total of 8 deployments per month (we do 2 maint windows for each environment). That will significantly reduce the prep time for patching as well as simplify reporting. Then between me and my new junior guy we should be able to tackle the rest of the workload pretty regularly. We're managing about 2,500 servers, 50apps, and only a couple versions of Windows (no linux). Much more than that and I'd say we'd need another guy if I want to keep having any reddit time;). When I came in patching hadn't been done in over 2 years and I had never even touched SCCM 2007. Currently I have one update list for all Security Patches for Servers.
Patches are always 1 month behind to give a month to test on all dev/test boxes. Week 2 is Dev Boxes Week 3 is Phase 1 Week 4 is Phase 2 Week 1 is Phase 3 The phases are just a collections consisting of an equal amount of servers. Servers that need to be rebooted together I.e. A vApp or a cluster are in the same collection. We have a manual phase which always have the patches presented and that's for specials servers, SQL, exchange, etc Workstations were updated by doing all security patches from 2010, then 2011, then 2012, then 2013, and now every two months we update workstations and they also are 1 month behind.
Sccm Patch Deployment Best Practices
Power users who test patches have patches applied in the months normal workstations don't get updates. We reboot about 120 servers weekly and 3500 workstations everyone other month. Required a lot of giving and very little taking but it's getting done. Can't wait for 2012 R2 which will make my life easier. We have kind of a mixed bag. When I went to work for my company 3.5 years ago there was no patching being done period.
Environment was XP, office and server 2003. The patches regularly broke the custom GP applications when they were applied. While we still can't do XP or the few server 03 machines we have left. I started rolling out office 2010, windows 7, office 2010 from day one and applying security and critical patches to them.
Any others have to be approved. We are a 5 person IT department for 1300 people. We have a medium environment, 3800 desktops, and need to spread delivery of patches out so as to not impact all areas, or too many machines in the same area, at once. The best way I thought up to do that was to utilize maintenance windows on machine collections. I created 5 maintenance window collections, say Monday 1AM - 4AM, and each gets a random group of machines.
I used the SCCM machine guid to randomize distribution, so monday all machines with a SCCM guid ending in 0 or 9 gets updates. I have an automatic deployment rule in SCCM that downloads and deploys the patch tuesday patches to a test group, in our case the entire IS department(they are a vocal group that run most of the applications our end users run so if problems arise i'll know). After a full week of our test group running the patches they get deployed out to all of the maintenance window collections.
For this I have been using the Coretech software update manager. It makes creating the deployments quick and I know they are all always created the same way.
Hi, I'm looking into Software Updates and wondering if the 'best' method for managing them through ADRs has changed since the release of SCCM CB? Previous I have seen the most recommended method was detailed in the links below. Basically you separate by year and not by product. You would have Software Update Groups (SUGs) for each year which cover OS and Office, etc. Fxpansion.
(one for Servers and one for Workstations). Making sure that each SUG is limited to under 1000 updates. I understand you can use just one Deployment Package but it's recommended to break this up by year as well.
Another method I encountered was making use of the 'Required =1' in the ADR and adding to an existing SUG but I imagine that after some time the SUG would go over the 1000 limit anyway and you'd have to separate it. Also what Classifications do people use, Critical Updates and Security Updates only or add Update Rollups and Updates as well? Don't the Updates/Update Rollup classifications cause issues with IE upgrading to a new version and breaking apps?
Best is in the eye of the beholder and entirely dependent upon your requirements, expectations, environment, and constraints. I do not like the first method you noted above because is causes manual work, clutter, and is more complex in general. It also increases overhead on the clients if they must maintain and report on compliance for updates that can't possibly be applicable to them.
I also don't like the second method as it's a reactionary approach that will miss updates needed by clients right now like those deployed during OSD. My preferred method is a single ADR for each product or product group; e.g., Windows 7, Windows 10, Office, or all Windows servers. These ADRs use the same update group each month instead of creating new ones and the ADRs create or update one or more deployments for each software update group. Each ADR then runs monthly. The only potential short-fall is that you don't know exactly when an update was deployed, however, that's generally not vital info. Instead, knowing the month an update was released is a better guide. As far as which classifications, that's up to you and your security department.
With the new servicing process in Win 10 and Win 7, there really isn't much of a choice anymore though. Jason @jasonsandys.
Best is in the eye of the beholder and entirely dependent upon your requirements, expectations, environment, and constraints. I do not like the first method you noted above because is causes manual work, clutter, and is more complex in general. It also increases overhead on the clients if they must maintain and report on compliance for updates that can't possibly be applicable to them. I also don't like the second method as it's a reactionary approach that will miss updates needed by clients right now like those deployed during OSD. My preferred method is a single ADR for each product or product group; e.g., Windows 7, Windows 10, Office, or all Windows servers.
These ADRs use the same update group each month instead of creating new ones and the ADRs create or update one or more deployments for each software update group. Each ADR then runs monthly. The only potential short-fall is that you don't know exactly when an update was deployed, however, that's generally not vital info.
Instead, knowing the month an update was released is a better guide. As far as which classifications, that's up to you and your security department. With the new servicing process in Win 10 and Win 7, there really isn't much of a choice anymore though. Jason @jasonsandys. Thanks Jason, I agree with those drawbacks.
Lots of maintenance in the first method for sure which isn't good to leave clients with, not so bad if you're the one managing the environment. I guess you target your deployments at individual collections (one for Win7, one for Win8) although i know you can just target all workstations and it's not really an issue. Don't you ever reach the 1000 point mark in your SUGs with that approach? I checked Win7 and I can see it's only at 500 odd while Office 2010+2013+2016 is about the same so probably not an issue I read that a downside with your method is that it created a bigger CPU overhead 'I also learned that every time the ADR runs it automatically changes the content in your software update group! Do that every Patch Tuesday and your clients have to once again parse or scan that update group which (again) can hit your CPUs pretty hard' Another downside might be when checking compliance you have to check against more SUGs rather than just one. A plus would be that it's quicker to remove products once they are decommissioned.
Your clients are going to scan against the WSUS catalog regardless of what's deployed via a SUG and evaluate everything that's deployed to them. So at worst you're talking deployment/policy churn. Is there really a client resource hit on that? You're correct about checking multiple SUGs but the solution is to just stop trying to use SUGs. If you want to know if a client is compliant then you really want everything that's deployed or applicable.
If you want to know how the newly released patches are doing base it on the update's released or modified date. I've been playing with re-using SUGs as Jason describes and one thing to keep in mind is your rollout schedule.
My org takes over 4 weeks to fully roll out to production which means that in this model you need to double the ADR/SUGs and schedule them to alternate months. Jason, When you create your ADRs/SUGs for each Product, Win7, Win10, etc, do you do either:. deploy them to a collection which contains all workstations or. Create collections for each product and deploy to those? I would guess you do option 2 as option 1 would have your previous statement apply to it.' It also increases overhead on the clients if they must maintain and report on compliance for updates that can't possibly be applicable to them' If you use option 2 do you then create a test colleciton for each product as well or just one workstationtest/phase 1 collection and deploy all ADRs to there? Also, do you create a ADR/SUG for each Office version just the one to cover all versions?
Many thanks again.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |