Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've implemented SCCM 2012 in my environment and have been trying to get all endpoints caught up on their updates. The previous management for some odd reason thought patching computers was not high priority. I'm wondering how some of you SCCM experts would approach this situation: You have just set-up SCCM 2012 and your endpoints may not have been patched in over year! I've created Software Update groups for each piece of software that shows needs updates when I check online such as Visual Studio 2008, Office 2010, Windows patches, etc. I have deployed the Software Update groups to a test collection consisting of all healthy clients.

The problem is my endpoints are not getting all the updates. They receive some and then stop. I would say that 50% of the patches have been applied. I try to do the Software update scan and still they do not see the updates when I know they are in the Software Update group and have been downloaded. Should I break these update groups down smaller into groups by date. Currently, I have an update group called All Office 2010 Updates. This was made by doing a search and filtering by product=office2010, superseded =no, and expired =no.

Should I break the updates out into groups by date, by every quarter since the product was released? I'm not finding any clear information on this topic. I have been using the SCCM 2012 unleashed book.

share|improve this question

1 Answer 1

up vote 3 down vote accepted

I'm still in the process of implementing SCCM 2012, but I've done some research on this topic to come up with a good plan for implementing software updates.

First, there is a finite limit for the number of patches you can include in a single deployment. I think with 2012 it was increased to 1000, so that's generally not going to be a concern. Though, I believe there are still some drawbacks to having a very large number of patches - every time you make a change to the deployment (adding new patches), there's a lot more processing that has to happen to re-evaluate compliance. Unless you have a TON of patches, or a lot of clients (50,000-100,000+), I think it will be negligible.

That said, this is my plan. It's somewhat specific to my environment, but I think it can apply to most environments.

  1. Have one large deployment containing all patches for all products that are included on your standard image (if your image was fully patched as of Feb 2013, only include the patches that are actually necessary).
  2. Every month, create two new update group deployments: one for all critical patches, and one for all non-critical patches. That way, our QA department can test them independently, and focus on releasing the critical patches first.
  3. Every 6 months to a year, update the base image WIM source file to include all patches released in that time period.
    • Move the 6 months of patches into the 'base' patch deployment group.

One thing to note - if you weren't already aware, SCCM only downloads the updates that are applicable to each computer - even if you have one deployment with 150 patches, it will only copy down the files and install the patches that are needed. With this approach, we should be able to keep our systems fully patched, and keep the image up to date so it doesn't take an additional 45 minutes to image a machine.

Also note, we aren't patching servers, and we have a fairly standardized environment. If we had multiple images / operating systems to support, I might make a few changes to the above plan (multiple "baseline" patch groups, one per image).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.