Quantcast
Channel: THWACK: Message List
Viewing all articles
Browse latest Browse all 20616

Re: Best Practices for "Catching up a Windows Environment" for patches.

$
0
0


I'll try to give some insight into your questions based on my years with a large corporation where I was both a Network and an Exchange Administrator and my work with Patch Manager since I've been with SolarWinds.  These are just a few of what I'd consider best practices with the limited understanding of your environment.  You'll probably have to tweak a few.  Others may offer their own "nuggets" of information, so I'd recommend listening to everyone and deciding what's best for your organization.

Do you use GPO's to let WSUS handle any updating?

Yes.  If you have Active Directory and you have a logical breakdown of your Organizational Units, then by all means use GPO's to handle pushing these settings.  Of course for those non-domain-joined systems, you'll have to do something slightly less different (I'll speak to that more later.)

Do you exclusively use SPM and always schedule your installs?

Not necessarily.  For workstations, I've always been a fan of just letting them patch on their own (on whatever schedule you decide) and holding back a VM or two of your standard image that you can use for testing prior to pushing patch approval out to everyone.  I'm going to bundle the server talk into the next question.

What about machines that need extra care such as Exchange, where you can't just let all CAS/HUB and Mailbox servers go off at once?

For Servers, I'm much more of a fan of the "Download, but let me choose when to install" option.  This is especially true for things like Exchange Servers which now compile some information during the installation process.  I see this as doing two things: 1) it cuts down on the time necessary to download patches and 2) it requires manual intervention on behalf of someone who can then properly test said system when the patching is complete.  Specifically regarding Exchange Servers, I'm a huge fan of this because some of your configuration changes (changes to the .config files or OWA pages for example) can be erradicated by some patches.  Having a knowledgable person on the hook for handling this always made sense to me.

Do you approve all needed updates including superseded updates?

This one can be a little "off" at times since Microsoft does occassionally remove specific patches for one reason or another.  I'm happier with making sure that there are Automatic Approval (WSUS) rules for Security, Critical, Update Roll-ups, and Definition Updates (your mileage may vary).  This way if I have something at the next sync that is needed, I've got it ready for my computers.

 

Overall, I'm a personal fan of approving anything that is at the top of the "supersedence" path (either the most recent version of a patch or something that doesn't have a supersedence marker) and denying anything that's been superceded.  The new version of WSUS (2012 R2) has a nice cleanup feature that you can run with PowerShell to clean-up the updates that have already been superseded.

 

Get-WSusServer-Namewsus.server.domain.local-UseSSL-Port8531 | Invoke-WsusServerCleanup-DeclineExpiredUpdates -DeclineSupersededUpdates -CleanupObsoleteComputers -CleanupObsoleteUpdates -CleanupUnneededContentFiles

 

I run the above daily (some time after my daily sync is scheduled) which also does some general housekeeping with regard to disk space.  This can also be done for earlier versions of WSUS via the COM Object, but I don't have that code handy at the moment (sorry).

 

If you want to get everything ready for a catch-up process, you can approve everything, wait for it to download, and then clean up unnecessary updates.  This will cause significant bandwidth and disk consumption, but is an option.

What do you do about machines that aren't in your domain, but you still have to patch them?

I use the Windows Update Local Policy Management from within Patch Manager to configure them with settings that "match" those that I use for domain-joined machines.  That way everything reports back.  You can also "tweak" the policy so that they fall into a different group when they report back to the WSUS server by editing the "client-side targeting" entry and giving it a name like "Non-Domain" or something like that.

 

Like I said, this is just my 2 cents - take any or all of it as you like.

 

--KMSigma


Viewing all articles
Browse latest Browse all 20616

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>