I’m finding that a lot of my posts are based on things that I repeatedly have to rehash over and over again in other places – Reddit, tech forums, Twitter. This is no exception.
I keep seeing people ask about managing updates in an enterprise environment. With that in mind, I decided that writing some high-level “This is how we do it” documentation on our current Windows Updates (as that’s what I’m responsible for along with two others) would be a good idea.
I can’t take credit for this plan – this was a team effort, with most of the work around this process/procedure being done by a colleague of mine. Mad kudos to him for getting this pushed through in a government environment, where changes can take weeks/months years and Windows Updates are seen as evil server-destroying things that are purposefully out to break things.
Reasons behind updating
So, with that in mind, we can look at how you can convince your organisation that performing regular Windows Updates is a good thing. The following reasons can be used:
- Security concerns – not applying these updates can mean that the systems are vulnerable to attack because critical and security updates are not being applied
- Supportability – Microsoft will, without a doubt, ensure you have updated your machine prior to performing any support on it. If you haven’t updated it (and most of the time, this will also included either the latest CU rollup or service pack), they quite possibly won’t give you assistance until you do. There is a good chance that if you’re having an issue because your machine isn’t updated, the overdue updates may actually help fix the problem.
- Ability to audit – controlling servers through a patching tool (such as WSUS or SCCM) gives you the ability to inventory your systems, whether they’re in a domain or not. If they want updates, they’ll need to be attached to the whatever update system you use. This is incredibly helpful in being able to keep an accurate list of servers.
I’m sure there are others that will be specific to your organisation/company, but these three appear to be universal for all.
How is the deployment structured
Another part of the equation is how you structure the deployment of your updates in such a large environment. If you only have a small number of servers, deploying updates may be a quick thing, you may be able to get them all done in one week.
If you’re in a larger enterprise environment, like I am, this may not be feasible. We have our deployment structured in the following way:
- Development environment – Windows Updates are applied the week the updates are released (2nd week of the month)
- Test environment – Windows Updates are applied to our Test environment the week after the Development environment (3rd week of the month) and after the Development environment servers have been tested with the new updates
- Production envornment – Windows Updates are applied to our Production environment the week after the Test environment (4th week of the month) and after the Test environment servers have been tested with the new updates
It is somewhat cumbersome, but it means that everything is being updated monthly and everything is being tested to ensure there are no issues moving further in different environments. This has definitely come in handy – we have had some updates that were pulled prior to production for causing issues in our Development or Testing environments.
Exceptions do happen – for example the critical security update that was required for Domain Controllers – and these need to be handled. We also have a process now to allow us to push these updates out as quickly as physically possible so that these extremely critical updates are deployed asap. These do go through development and testing, however at a much faster pace.
In order to ensure that all your servers are being updated, you need to ensure they can speak to your update server. In our situation, this is our WSUS servers. Rather than punching holes through our firewall, we have multiple WSUS servers located in different network zones so that all of our servers can pull down their updates.
Our WSUS servers are configured with downstream servers – one primary server that connects to Microsoft and other servers that retrieve their updates from this primary server. This ensure that all updates can be approved/unapproved and all computer groups can be managed from a single source.
Controlling via GPO
Our Windows Update are controlled via AD groups and GPO – this allows us to schedule the updates, to let people know “Your server will be going down at this time on this day”. Due to the large number of servers we have, it’s not feasible for us to attempt to update all servers on the one day, they need to be spread across the entire week. This is particularly advantageous in the case of clusters, so that the entire cluster is not going down at one time.
So that’s Windows Updates, from a very high level. Hopefully useful to others who are in an environment where they need to start implementing this!