Microsoft patching schedules for Windows Servers

Posted on 2014-10-17
Last Modified: 2016-03-23
can some one throw light of patching monthly vs quarterly pros and cons?  
what best suits for what kind of environment?
what are best practices with respective to timelines and phase wise deployments?
Question by:Good
LVL 35

Expert Comment

by:Seth Simmons
ID: 40387467
sometimes company policy or regulation will define this
i've been in places where patches will be installed the following month; october patches installed in november, november patches in december, etc.  another place will immediately install to dev systems right after patch tuesday and if no issues, will push to prod the following couple weeks.  both were regulated by either SEC or PCI compliance.

the only down side to patching so quickly is that once in a while something might break from a patch so you have to weigh that also
LVL 25

Expert Comment

by:Mohammed Khawaja
ID: 40387820
If you have test environment then test patches in that environment first.  We patch quarterly and we ensure to do it in the middle of the month when month-end processing is not happening.  We also use Tenable Security Center (Nessus based) to scan for patches and performing a risk assessment.  If the risk is high then we do an out of schedule patching to resolve potential critical issues (i.e. if there is an IIS critical patch but our web servers are not accessible over the Internet then the risk is low and we patch quarterly).

Author Comment

ID: 40416240
any other additional thots on this patching schedules? what is industry best practices, did gartner released what is the percentage of firms doing monthly/quarterly patching etc...need additional information
Guide to Performance: Optimization & Monitoring

Nowadays, monitoring is a mixture of tools, systems, and codes—making it a very complex process. And with this complexity, comes variables for failure. Get DZone’s new Guide to Performance to learn how to proactively find these variables and solve them before a disruption occurs.

LVL 39

Expert Comment

by:Aaron Tomosky
ID: 40417811
Every patch risks a problem and rollback procedure so the more often you do it, the more time you are spending. The hardest part for me is knowing if something broke right after a patch as sometimes it's not obvious. Knowing if something is broken and having a way to roll back are the two most important things IMO.
LVL 20

Assisted Solution

compdigit44 earned 250 total points
ID: 40418190
I work for a large company with 800+ servers and tight regulations. We patch are servers as follows.

1) All Test and Dev servers are patched the 2nd week of each month when patch come out.  All servers are then tested and validated.

2) On the 4th week of each month we patch ~100 of our most critical servers.

3) During the following weeks we patch the reaming servers in batch of 150 -200 .So there is always a constant flow of patch being deployed and in our environment a staff member has to be onsite in the server room while patches are deployed via SCCM incase a server has problems because our downtime windows is very small.
LVL 26

Accepted Solution

Leon Fester earned 250 total points
ID: 40421314
As mentioned by the first poster...your patching schedule should be based on your regulatory requirements. If you are working in heavily regulated/audited environment then there are already guidelines that dictate the frequency of patching.

In PCI DSS(Payment Card Industry Data Security Standard), for example, they require you to apply critical patches within 30 days of the patch being released.
However, this does not overrule the requirement that you only apply patches that are needed. Even then, we had critical systems that we only patched every 3 months due to the amount of work required to failover to the backup systems.

Apply updates on a needs only basis.

One of the common misconceptions about Microsoft updates is that they are mandatory and/or urgent.

All updates, regardless of their type (whether they are service packs, hotfixes or security patches), are to be applied on an "as-needed" basis. They need to be evaluated individually and treated as important optional updates.

Especially with security patches, the expectation is that it must be an urgent issue and must be deployed quickly. Without trying to detract from the urgency, security patches are very much a relative update; for example, customers using solely Windows NT4 can ignore a patch for a security vulnerability in Windows 2000. However, if the issue is relevant and does plug a security hole, then it should be evaluated urgently.

Only when it addresses or fixes an issue being experienced by the customer should it be considered. Of course, it still needs to be evaluated before being installed.

These links are Microsoft best practices for how to manage updates, but Microsoft does not stipulate when to patch other than "As needed. After evaluation and testing of the patch. When system downtime will be least impacting on your organization"

Check out the document published by the  (United States) DHS National Cyber Security Division Control Systems Security Program entitled: Recommended Practice for Patch
Management of Control Systems

It also only talks about the patching process and controls but not the frequency.

Regarding frequency; if it's not specified by any regulations then you can patch when you need or can manage it. You need to take a risk-based approach and decide how impacted your organization would be if you patched every month. Can your support team manage it? Is your systems critically affected by the patch release?

Featured Post

Best Practices: Disaster Recovery Testing

Besides backup, any IT division should have a disaster recovery plan. You will find a few tips below relating to the development of such a plan and to what issues one should pay special attention in the course of backup planning.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The recent Microsoft changes on update philosophy for Windows pre-10 and their impact on existing WSUS implementations.
Restoring deleted objects in Active Directory has been a standard feature in Active Directory for many years, yet some admins may not know what is available.
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
This tutorial will walk an individual through setting the global and backup job media overwrite and protection periods in Backup Exec 2012. Log onto the Backup Exec Central Administration Server. Examine the services. If all or most of them are stop…

697 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question