Schedule WSUS update install/reboot monthly?

I am looking to utilize WSUS for installing updates for end-user work stations and servers.
I had a few questions I was hoping people here could help advise me on:

1. Can WSUS updates be scheduled to install on the servers and workstations on the last or second-to-last Saturday of the month? How could you schedule that because I only show in Group Policy the option to pick a day out of the week, as if weekly-basis is my only option...?

2. For reboots, can it be done so when they are installed on Saturday, the reboot is forced? Most users wouldn't be logged in on a saturday so we'd just remind them to save their work if they forget to log off.

3. Only other question I can thin of would be for those users who leave computer off on weekends and boot up Monday, would WSUS hit them up on Monday since they missed updates on Saturday, and what is the end-user experience going to be like with that? any warning messages or can they go into an indefinite deferral by postponing?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DonNetwork AdministratorCommented:
Look over

Managing the WSUS Automatic Updates Client Download, Install, and Reboot Behavior with Group Policy
Hypercat (Deb)Commented:
1.  The way we manage this is to approve updates manually on the day we want them installed.  That controls the timing because, of course, unapproved updates will never be installed.

2.  The reboot will always happen automatically unless you configure the group policy to prevent reboots when a user is logged on.  If you configure the policy that way, then the next time the user logs off or reboots, the workstation will install the updates and reboot automatically at the next update time scheduled by the group policy.  For example, if the scheduled time is at 3AM (which is what we use), the likelihood is that no one will be logged on unless your users are in the habit of leaving their workstations logged on overnight.  The trick with using a 3AM time is that you have to train your users to log off but not shut down their workstation overnight.  This can be difficult if habits are ingrained to shut down workstations overnight.

3.  If the workstation is turned off at the scheduled update time, it will wait until the next scheduled time to install updates and reboot.  So if it's always turned off at that time it will never update. One way to mitigate this is to use the group policy setting to "Allow Automatic Updates immediate installation."  This will install any updates immediately that don't interrupt Windows services and will complete the installation upon the next restart if a reboot is required (assuming you've told it to prevent restarting if a user is logged on).

The article posted above gives a very complete explanation of all of the options in the group policy section for Windows Updates and how they work together.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
garryshapeAuthor Commented:
Ok so by waiting until the next scheduled time, does that mean a week later at the same time? Or the very next day at the same time? If update scheduled for Saturday at 3am, but system's shut off, will it wait until the next Saturday at 3am, or Sunday at 3am?
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

Hypercat (Deb)Commented:
It depends on how you schedule it.  So, if you schedule it for 3AM every day, it will check at 3AM every day.  If you schedule it for only a certain day or days of the week, it will only check on those days. It checks EVERY scheduled day at 3AM regardless of whether there are any updates to install.  So, once the updates are approved by you in the WSUS console, the workstation will get the updates at the next scheduled check-in time. If it's shut down at that time, then it will check again (provided it's turned on) the next scheduled day at that time.
garryshapeAuthor Commented:
Oh ok so it sounds like then, if we want them installed on Saturday the 20th, or as close to Saturday the 20th as possible, then we'd need to:
1. Manually "approve" updates in WSUS on Friday the 19th
2. Have GPO set to install every day at 3am
3. Hope all the computers are up on Saturday at 3am, and let them get updates.
4. If they were off, then WSUS will attempt to install every next day at 3am until they're compliant.

then repeat the next month...
Hypercat (Deb)Commented:
Yes - that's the way I'd recommend doing it.  We also send out an email reminder to users in the mid-afternoon of the day that we approve the updates - i.e., "Remember today is update day; please log off and leave your workstation on overnight" or something like that.  That way, at least 90% of the users will normally remember NOT to shut down overnight, if that is their regular habit.
garryshapeAuthor Commented:
Ok cool, then for picking different dates for workstations vs servers, I'm assuming separate GPOs would need to be created.
And now that I think about that, I'm wondering if 2 separate WSUS servers would be work, for more granular control over scheduling?
This is until we get SCCM, of course.
Hypercat (Deb)Commented:
Yes, I would have different GPOs for workstations and servers.  Personally, I like to manage server updates much more closely, and in fact although I distribute them through WSUS, I set the policy to auto download and notify for installation.  Then I double-check all of the scheduled updates that have been downloaded to each server before I actually tell it to install them; and this way I can control when they are restarted as well.  However, I don't have a huge number of servers at any one site, so that might be unmanageable depending on your requirements.

If you have a very large number of servers and workstations to manage, you may want to think about 2 separate WSUS servers.  If you want to be able to schedule installation of updates for different groups of servers separately, you can also create different groups within WSUS and then put the servers in those groups. Then you can match those groups with your policies, if you need that level of control, such that you know what the parameters are in the group policy for each server group that you're managing.  Also, when you approve updates, you can approve them just for a certain group. This is the best you can do with plain ole WSUS.
garryshapeAuthor Commented:
Ok great ,thank you, definitely more than enough to get me where I need to go.
garryshapeAuthor Commented:
Also hey, what about manually synchronizing WSUS instead of manually approving updates, in order to control the auto installation? Or would that be a bad idea?
Hypercat (Deb)Commented:
I'm not sure how well that would work.  The thing about synchronizing WSUS is that it is done on a scheduled basis and is unattended.  Normally if it's done on a regular schedule, it runs pretty fast. However, I've never tried setting it up so that the synch is done manually, although I would think that if there are a lot of updates it might take a long time to synchronize.  It certainly wouldn't hurt to experiment with it if you have the time and inclination.  

Also, keep in mind that synching WSUS doesn't actually download the updates themselves, it just synchs a list of needed/required updates.  So, you'd also have to set it up for automatic approval so that the updates are approved after WSUS is synched and you can skip the manual approval step.
garryshapeAuthor Commented:
Ok cool thank you

I'm considering now the following option, having a test environment and a production environment, configured for Test environment to be updated on the 2nd Saturday of the month, then Production to get updated on the 3rd Saturday of the month

I guess the only way to get test server environment and production server environment updated on the weekends, a week apart, would be to approve updates manually on Saturday in the afternoon sometime, and then have Test environment scheduled to install Sunday morning at 3am, and then have production environment scheduled to install on Saturday at 3am.
This means Test environment would get updates first, and then since 3am Saturday schedule for production servers was before the approval, it would wait until the next Saturday before installing to them.
garryshapeAuthor Commented:
Can I not just approve updates for one group, let them install at Saturday at 3am, and then approve the same updates for the next group a few days later, so that they would then install updates at 3am the following Saturday?
That way both can have GPO set to install updates at 3am on Saturday, but I can separate which Saturday by approving the updates separately for the groups accordingly.
Hypercat (Deb)Commented:
Yes, I had posted a comment suggesting that before I saw your second comment. You could do it either way, but personally I would do the approval by groups.
garryshapeAuthor Commented:
Ok thanks

Sorry but follow-up question based on what we have so far.

With the manual updates approach, when I approve updates for a group, what if I just set the deadline to the specified Saturday for that group?

Would that mean if GPO is configured to not restart if a user's logged in, that the server would still restart if it's on or passed the deadline?
Hypercat (Deb)Commented:
To my knowledge (I've never used them), this isn't the way deadlines work. However, I found a thread that explains it somewhat, and the conclusion is that this isn't going to do what you want it to do.  The relevant comment, I think, from that thread is:

"Deadlines establish LAST ACCEPTABLE installation time -- the time at which nothing else can be done on that server until the update is installed AND the server is rebooted. Furthermore, a reboot triggered by a deadline-initiated installation is a MANDATORY reboot - you cannot delay/defer that reboot."

To read the entire thread:
garryshapeAuthor Commented:
That's what I am thinking. If we specify the deadline, we want the computer to reboot as close to the deadline.

The problem with allowing user to defer/delay a reboot is that they can do so indefinitely as long as they remained logged in to their computers. Unless there's a workaround to that? Unless I am wrong?
Hypercat (Deb)Commented:
The only workaround would be not to use the GPO setting that prevents reboots when  a user is logged on, and that could leave you with some really PO'd users if their computer reboots overnight and they hadn't saved their work.

I do think that having the reminders pop up about every 10 or 20 minutes is annoying enough that most people will go ahead and restart at the end of the day just so they don't keep getting the popups.  There are always a few who don't go along with the program.  To be honest what I usually do with those is sneak in remotely after they leave work and manually restart the computer, if it's been a really long time and I want to make sure that critical updates are fully installed.
garryshapeAuthor Commented:
Ah ok

And so for the deadline, that means if we have GPO set for user to reboot ordered themselves, that they can only do so until the deadline hits, and the deadline will ensure they are updated and rebooted without depending on the logged in user to click reboot?
Hypercat (Deb)Commented:
Yes, it appears that is what the article is saying.  I've never used that particular setting, so I'd be cautious and test on a few machines to see how it operates.  According to the article it can be unpredictable and may cause an unexpected reboot. Definitely not something you'd want to do on servers at any rate!
garryshapeAuthor Commented:
Here's an update schedule I've come up with. Assuming I can iron out WSUS and implement the technical side to meet the schedule, what do you think?

wsus schedule
Hypercat (Deb)Commented:
Okay, so you have 2 groups of users - a test group and a production group. On the servers, are you using 2 groups also?  It looks like it - two different Saturday/Sunday passes on the servers. It looks like a very reasonable schedule and leaning toward the cautious side which is good.

One thing I should mention, since you don't seem to have used WSUS before, is that there are sometimes updates that fail to install on workstations or servers due to conflicts arising because there are multiple updates to the same files.  This happens most often, in my experience, when you're distributing .NET updates along with OS updates.  So, there are times when it will require 2 restarts to finish the complete cycle of updates, and there may be times when you need to troubleshoot update failures manually. I usually have to do at least one or two post-update passes through the WSUS console to troubleshoot errors and make sure all workstations and servers were restarted successfully.
garryshapeAuthor Commented:
Ok interesting, I will keep that in mind. Hopefully it gets better.

Looking at this schedule I'm now wondering if it's best to do Saturday/Sunday, that way I can at least have some free time Saturday not worrying about update issues. heh.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.