locked
Using SCCM 2012 to Patch 'New Servers' RRS feed

  • Question

  • I am looking for some help concerning patching new servers (95% VM) via SCCM 2012 R2. SCCM has recently been rolled out for the purpose of monthly patching of all Production servers (800+).  WSUS  has been used to patch servers and Windows Update have been used to update 'new servers' thus far as WSUS does not appear to offer "all" needed updates on new servers.

    The VM images/templates (50+) are currently not consistent in the patch levels across the server platforms (2003-2012 R2) that are used in production.   They would like me to download all the patches to SCCM to make them available for new server
    deployments.  As opposed to downloading hundreds of unnecessary patches, I have recommended getting all the images consistent in the current patch levels and maintaining a once a year cycle in patching images; thus making SCCM responsible for up to a year of patching for the new servers. 

    I am looking for ways to keep this manageable for both the VM Team the SCCM Admin. I have considered ADRs but I would prefer not to bog down the Deployments.  I would like to see/maintain 1 Deployment for new servers if possible.  The ADR design for monthly patching is already complex in order to meet the requirements of server patching.  I am open to additional thoughts please.

    I am looking for ways in which others have handled new server patching via SCCM.  I don't want to make more work for them in building/maintaining images but I am concerned about downloading and maintaining a large number of unnecessary patches for the 'what-if' scenarios. 

    I would appreciate your thoughts and suggestions.

    Thank you.




    • Edited by AMRDC Monday, October 13, 2014 3:30 PM
    Monday, October 13, 2014 3:28 PM

Answers

  • I typically include and recommend deploying everything for in scope OSes -- you just never know when a patch will be required or an admin will uninstall something important . I've never ever included Itanium updates though -- those are easy enough to filter out. Ultimately, disk space is cheap and bandwidth usage is simply a one time cost so if those are limiting factors, you may need to adjust your expectations.

    Keeping images up to date is important for two reason: security and time. If you are deploying an unpatched image that's a huge potential security risk. And patched images take much less time to deploy than deploying an unpatched image and then patching it.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Daniel JiSun Wednesday, October 15, 2014 2:08 AM
    • Marked as answer by Daniel JiSun Tuesday, October 21, 2014 5:18 AM
    Monday, October 13, 2014 5:52 PM

All replies

  • "but I am concerned about downloading and maintaining a large number of unnecessary patches for the 'what-if' scenarios. "

    Why? What's your concern based on?


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Monday, October 13, 2014 4:12 PM
  • In looking at the current environment, (filtering out Itanium), there are over 750 patches that are currently not required.  But with the request, these too would be downloaded.  Just giving consideration to data space (unnecessary usage) and network traffic as it is shared across all DPs.

    So, in your experience, do you find companies downloading all patches (needed or not)  for all supported platforms? 

    Where do you find image maintenance (patching) becoming part of the overall patch strategy?

    Thanks for taking the time to help.

    Monday, October 13, 2014 4:28 PM
  • I typically include and recommend deploying everything for in scope OSes -- you just never know when a patch will be required or an admin will uninstall something important . I've never ever included Itanium updates though -- those are easy enough to filter out. Ultimately, disk space is cheap and bandwidth usage is simply a one time cost so if those are limiting factors, you may need to adjust your expectations.

    Keeping images up to date is important for two reason: security and time. If you are deploying an unpatched image that's a huge potential security risk. And patched images take much less time to deploy than deploying an unpatched image and then patching it.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Daniel JiSun Wednesday, October 15, 2014 2:08 AM
    • Marked as answer by Daniel JiSun Tuesday, October 21, 2014 5:18 AM
    Monday, October 13, 2014 5:52 PM
  • Thank you for your feedback.
    Tuesday, October 14, 2014 5:21 PM
  • You could built your server images once a month, with the newest updates added to them then. You might also consider using offline servicing feature of ConfigMgr to add some of the updates to your .wims prior the deployment. And of course, you could add "Install Updates" -step to your server deployment task sequence and that way the needed updates would be installed for the OS during the deployment. I'm assuming, you're also using ConfigMgr to deploy your servers?

    Tuesday, October 14, 2014 8:58 PM