What is everyone's patching process?
Sccm Software Updates Best Practices
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.
Best practices for deploying software updates
Looking for advice on how to optimize this software update process.
I need to update several versions of MS Office for all end user machines and server. I have been doing this in a variety of ways, but want to clean it up with best practices.
Scenario 1: Download all office patches into a single deployment package (repo), bundle all the downloaded patches into a software update group, deploy the software update group twice - once to a device collection containing all end user systems (with it's own maintenance window), and once to a device collection containing all servers (with it's own maintenance window)
Scenario 2: Download all office patches into a single deployment package (repo), bundle all the downloaded patches into a software update group, deploy the software update group to a device collection that contains all end user systems and all servers in two sub-device collections (each with their own maintenance window).
Which is better, and why? I like the simplicity of scenario 2, but imagine it's harder to track and maintain windows in the future
Applies to: System Center Configuration Manager (Current Branch)
This article includes best practices for software updates in Configuration Manager. The information is sorted into best practices for initial installation and for ongoing operations.
Installation best practices
Use the following best practices when you install software updates in Configuration Manager.
Use a shared WSUS database for software update points
When you install more than one software update point at a primary site, use the same WSUS database for each software update point in the same Active Directory forest. If you share the same database, it significantly mitigates, but doesn't completely eliminate, the client and the network performance impact that you might experience when clients switch to a new software update point. A delta scan still occurs when a client switches to a new software update point that shares a database with the old software update point, but the scan is much smaller than it would be if the WSUS server has its own database. For more information about software update point switching, see Software update point switching.
Important
Also share the local WSUS content folders when you use a shared WSUS database for software update points.
For more information on sharing the WSUS database, see the following blog posts:
When Configuration Manager and WSUS use the same SQL Server, configure one to use a named instance and the other to use the default instance
When the Configuration Manager and WSUS databases share the same instance of SQL Server, you can't easily determine the resource usage between the two applications. Use different SQL Server instances for Configuration Manager and WSUS. This configuration makes it easier to troubleshoot and diagnose resource usage issues that might occur for each application.
Specify the 'Store updates locally' setting
When you install WSUS, select the setting to Store updates locally. This setting causes WSUS to download the license terms that are associated with software updates. It downloads the terms during the synchronization process and stores them on the local hard drive for the WSUS server. If you don't select this setting, client computers might fail compliance scans for software updates that have license terms. The WSUS Synchronization Manager component of the software update point verifies that this setting is enabled every 60 minutes, by default.
Software Deployment Sccm
Operational Best Practices
Use the following best practices when you use software updates:
Limit software updates to 1000 in a single software update deployment
Limit the number of software updates to 1000 in each software update deployment. When you create an automatic deployment rule, verify that the specified criteria doesn't result in more than 1000 software updates. If you manually deploy software updates, don't select more than 1000 updates.
Create a new software update group each time an ADR runs for 'Patch Tuesday' and for general deployments
There's a limit of 1000 software updates in a deployment. When you create an automatic deployment rule (ADR), you specify whether to use an existing update group or create a new update group each time the rule runs. If you specify criteria in an ADR that results in multiple software updates, and the rule runs on a recurring schedule, create a new software update group each time the rule runs. This behavior prevents the deployment from surpassing the limit of 1000 software updates per deployment.
Use an existing software update group for ADRs for Endpoint Protection definition updates
When you use an ADR to deploy Endpoint Protection definition updates on a frequent basis, always use an existing software update group. Otherwise, the ADR potentially creates hundreds of software update groups over time. Definition update publishers typically set definition updates to expire when they're superseded by four newer updates. Therefore, the software update group that's created by the ADR never contains more than four definition updates for the publisher: one active, and three superseded.
See Also
Download lagu hijau daun suara ku berharap mp3. The important thing here is to create a non-mandatory deployment, so that the updates are delivered to the server and sit waiting to be installed.
1) by criticality, and functionality
2) via SCCM
3) manually install (especially clusters)
4) I , by default, have test servers of 'all' our application servers (e.g. CRM, POS, apache website) by default. Ironically for MS infrastructure servers , we have none (e.g. domain controllers, dhcp,etc), but for security patches, update one and see what happens. If really worried, as they are VMs can clone off to a sandpit and test
5)anything you add can muck things up, that's why you have test environments and a test plan.
6) As they come from Microsoft. Service packs are treated differently.
I do not rush out and patch the servers on Patch Tuesday. I monitor a number of mailing lists and forums to see what, if anything is going wrong.
Each patch is assessed for risk.
As an example, if a IE patch was released by MS, that fixed an issue with people browsing websites (malware downloaded to their PC), I would release it ASAP to desktops and citrix/RDS servers (basically servers people browse the web from) but not to all servers right away, as it may of been released in a hurry