WSUS Settings for Servers

[Jobos]

We currently use WSUS for updates and I was wondering what other schools who use WSUS how they install updates. At the moment we have the servers WSUS GP settings set to

 

Configure Automatic Updates: 2 Notify for download and auto install

Enable client-side targeting: Servers

No auto-restart with logged on users for scheduled automatic updates installations: Enabled

Specify intranet Microsoft update service location: http://:8530

 

This means I need each month to install updates but what I want is to have each server install and restart automatically overnight but not all at the same time.

 

What settings would I need to achieve this please?

[supportman]

WSUS feels very old these days, we got rid and just set auto updates on all machines now. Seems to work well.

[6Foot2]

When I was using WSUS, I didn't install new updates straight away - I had a delay (about 2 or 3 weeks, I think) to allow for 'bad' updates and the problems they might bring.

[msi_school]

From an operational POV I would love to leave a couple of weeks for patches to mature but I have to have all patches installed either 7 or 14 days after their release dependent on system for security. Which hasn't caused an issues since Print nightmare.

[Net_Man]

I have the same opinion as 6Foot2 in that i never install the updates straight away. I also very selective about which updates to install so having the servers auto install and restart would be my nightmare.

[Jobos]

I have the same opinion as 6Foot2 in that i never install the updates straight away. I also very selective about which updates to install so having the servers auto install and restart would be my nightmare.

 

But in using WSUS I approve the updates first so I have complete control on what gets installed.

[36Degrees]

I have the same opinion as 6Foot2 in that i never install the updates straight away. I also very selective about which updates to install so having the servers auto install and restart would be my nightmare.

 

^^^ Exactly this!

 

WSUS for clients, direct download and very careful \ selective install on the servers.

[Olliedawg]

WSUS feels very old these days, we got rid and just set auto updates on all machines now. Seems to work well.

 

We do the same, retired WSUS server earlier this year. Auto updates for all workstations. Download only on servers.

[Koldov]

This is a tricky one, so I'm watching this thread with interest... because I have never fully worked out how to have this set exactly as I want it.

 

I don't let anything install an update automatically, so I give it a couple of weeks and release as I see fit.

 

Some of our VMs run Defender due to needing to keep them quite slim and low on resource use (the hosts run Sophos).

 

I have tried different settings and had disastrous results with servers randomly rebooting (and sometimes the odd VM not restarting), but with other settings they won't even install the Defender definitions even when 'Approved for Install'...

 

As for the OP I would say if you have 'complete control' over releasing updates in WSUS, then you could set the servers to 'check, download and install' automatically and set a small check for updates time.

 

The only way you might fine grain it any further and have servers installing updates and restarting, could be to have different servers in different OUs with different times set in the update GPOs.

 

Also if you could separate them in WSUS release the updates with different deadlines...?

 

I have looked at it many times and ended up going round in circles with all the possibilities!

[filteringtech]

I'm old school too. We're not paid to be Microsoft's beta testers. Once the updates are proven stable, they they go in.

[dmj]

Same. Nobody in their right mind trusts microsoft patches.

[Koldov]

*Grabs the popcorn and waits for the WUfB lot to arrive*

[pete]

We still use WSUS (I don't yet have a better dashboard for easily verifying patch compliance across the trust) with a 2-week patch deadline for clients and servers.

 

Servers are patched in 3 waves (WSUS groups).

 

• Test VMs and/or not-user-facing. Downtime doesn't affect production, so we can test patches anytime.
  
• Redundant services (DCs, DHCP (assuming N+1 in a failover/HA), etc). Can be rebooted and patched in the working day provided the patches have been tested
  
• Things that hold user data. Needs a known-good nightly backup done before patching and can only be rebooted 00:00 > 05:00.
  

 

Once patches are released to servers, they install and reboot according to their "active hours" setting.

[Will.B]

*Grabs the popcorn and waits for the WUfB lot to arrive*

 

Don't tempt me!

But I have had great experiences with it across a 7-site Trust and other single schools - highly recommend!

[jthompson]

*Grabs the popcorn and waits for the WUfB lot to arrive*

 

WUfB isn't really geared to servers. Machines running Windows Server won't appear in the stats, for instance.

 

Azure Update Manager would be the server equivalent of WUfB. That will give you dashboard reports for checking compliance and what updates are pending, etc. You can either schedule auto-installations via that, do them manually, or some combination of both (e.g. autoinstall definition updates each night, autoinstall critical updates each weekend, and leave everything else to be done manually).

 

I gave up ages ago with holding updates back on servers. Even when still using WSUS, it was auto-approve for critical and security updates, with a 7-day deadline and a weekend install window. At which point there's no real need to point servers at WSUS any more.

 

Regarding having different auto-install/restart schedules for different servers, that could be achieved using GPOs targeting different servers as required (regardless of whether they're being pointed at WSUS or not).

[penfold]

In my last place we deployed updated in 3 waves. Servers had their update settings applied via GPP config based on AD groups (this allowed us to control legacy servers also) to specify the hour/day/week of install. To apply different update times, each server was a member of different AD groups and had to be in an Hour/Day/Week group. There was a scheduled task running also to change the update status to download only except for the week of installation. Then it would change to download and install. This prevented the server trying to re-install the updates if it failed outside of the maintenance window. Pretty sure all of this can be done with "active hours" if you don't need to keep legacy servers running.

 

Majority of our settings were applied via registry following the info under Configuring Automatic Updates by editing the registry - https://learn.microsoft.com/en-us/windows/deployment/update/waas-wu-settings

 

Updates were approved each week but this could have been auto approved based on the design. Only reason it was done manually was because management were scared based on some "outages" due to updates rebooting a server outside of planned downtime as this had happened when they had a different team looking after updates.