Any way to schedule updates once a month?

Options are only to do once a week

Any way to schedule updates once a month?

Well, if you only approve them once a month.. then the client systems will only get *one* opportunity each month to install those updates.

If you don't approve updates multiple times per month, there will be no updates for the client systems to install.

But, to your specific question -- there is no way to schedule updates on a monthly installation basis. The presumption with scheduled installations is that you want updates installed as soon as possible after they are available. It would do no good to have a scheduled installation date on the 20th of the month, if a critical update (or a zero-day security exploit fix) was released on the 22nd!

Perhaps part of the conversation here should be an evaluation and understanding of why you want to schedule updates once-per-month? This is not typical "best practice" in the realm of patch management.

Any way to schedule updates once a month?

Well, if you only approve them once a month.. then the client systems will only get *one* opportunity each month to install those updates.

If you don't approve updates multiple times per month, there will be no updates for the client systems to install.

But, to your specific question -- there is no way to schedule updates on a monthly installation basis. The presumption with scheduled installations is that you want updates installed as soon as possible after they are available. It would do no good to have a scheduled installation date on the 20th of the month, if a critical update (or a zero-day security exploit fix) was released on the 22nd!

Perhaps part of the conversation here should be an evaluation and understanding of why you want to schedule updates once-per-month? This is not typical "best practice" in the realm of patch manag

Best practice isn't always practical.

You shouldn't be required to approve critical updates.

Correct me if I'm wrong.

Best practice isn't always practical.

Granted.

You shouldn't be required to approve critical updates.

You're not.

Correct me if I'm wrong.

First I need to understand what your

Just arguing Microsoft's presumption. I think they should work on improving this.

I suspect the "presumptions" are yours, not Microsoft's.

The functionality of WSUS was based on several years of actual patch managment practices -- practices that long pre-date the existence of Automatic Updates or Windows Update.

The fundamental princple of patch management -- dating all the way back to mainframes and minicomputers of the 1960s:

• identify patches that are available
• identify patches that are applicable
• identify patches that are needed
• install only those patches that are necessary

The operation of WSUS is fully compliant and compatible with that philosphy of operation.

• Identify patches that are available -- review the synchronization logs, update lists, and KB894199.
• Identify patches that are applicable -- review the associated MSRC bulletins and KB articles, and note the computer systems that report updates as NotInstalled (vs NotApplicable or Installed).
• Identify patches that are needed -- this is the HUMAN portion of the process. Whether updates are needed on a system is a decision that a patch administrator must make based upon what the identified defect is, what the patch remediates, what the potential side effects of the patch might be, and what the risk factors for not applying the patch are.
• Install those patches that are necessary -- implemented by building a target group in WSUS and approving the update for installation to that target group.

Now... recent developments in the realm of security has, in fact, created a scenario in which 99% of Security Updates almost automatically fall into the "are necessary" group, but the rest of the updates released in other categories: Critical Updates, Updates, Update Rollups, Feature Packs, Service Packs do not. (Although it is true that Microsoft support policies eventually mandate the installation of service packs.)

The O.P. is looking for a solution to restrict systems to only installing updates once-per-month, rather than the available configuration option of once-per-week. Aside from such a restrictive policy being IMNSHO a "bad idea", it can be implemented through properly applying the above practices. One simply chooses the correct time period to "install those patches that are necessary" and properly monitors that process to ensure that ALL desired patches are, in fact, installed on the ONE DAY in which that installation is desired/authorized.

If the installation fails, the remediation is as simple as removing the approval for the update until the next "monthly" cycle comes around again.

Of course, that's where the risk management question comes into play. Can you afford to not install an update for a whole month simply because it did not install on the "one day" you set aside for doing that -- maybe so; maybe not!

I would argue that a functional solution is not "one day per month" but a "specified day of the week", and maintenance periods should be reserved on a set day/time of every week. Just because they are reserved does not mean they have to be used. When I was a DBA, I had a scheduled maintenance period every Thursday from 9pm-11pm. I rarely used more than one per month, but it sure was useful knowing I had alternatives if I needed them. And to that point, the WUAgent policy settings allow for a "specified day of the week" installation event to be configured.

But then, comes the other point -- such critical systems should not have their update installed via a scheduled event -- they should be installed in a supervised console session by a human systems administrator. And to that point, the correct configuration is not AUOptions='4' with a scheduled installation day/time, but rather AUOptions='3' (or '2') and a sysAdmin logging onto the console during that ONE day per month that scheduled maintenance is perm

In our case, we do patching for our various clients, and with SLA's we can only patch and reboot servers once per month (on a sunday). So, we just need to make sure we dont approve any updates until a few days prior to the last Sunday of the month

Exactly.

And to be specific, it only requires that you approve the updates after the scheduled installation time of the Sunday prior to the authorized Sunday maintenance period. Updates detected/downloaded anytime after that week-prior time will be held on the client and scheduled for installation on the following Sunday.

Hello,

I don't know if you re still facing the problem for scheduling updates once a month, but it happens that I ran into same troubles and decided to take an other approach than the validation process.

I decided that I wanted to decide exactly when to install updates on my servers and so I developped a tool that let me chose once for all on which day of the month I install the updates (I work in a datacenter with many services offered to the clients).

With it, I can run schedules like :

30 2 * * 0#3 : run every 3rd sunday of the month at 2:30AM

05 2 20 * * : run every 20th of the month at 2:05AM

I went further in the developement and now I can specify a particular proxy/wsus server for each server and some other options.

I hope it will help people facing the same planning problem we both had :)

Contact me if you need more information !

The name of the tool is vbWSUS and you can find it here : http://sourceforge.net/projects/vbwsus/

Set monthly WSUS update schedules with GPOs

Example:

Say you have 200 servers that are non-production test servers and 1000 servers that are production servers. You want to patch non-production servers on the first Sunday of the month and production servers on the second Sunday of the month.

Create 2 groups in wsus. One group for production servers and one group for test servers.

Create 3 GPOs and 2 security groups in Active directory.

WSUS GPO 1 In this GPO, set wsus settings as desired setting clients to download only mode.

Apply WSUS GOP 1 to authenticated users meaning it will apply to all computers in scope. All your servers will now be set to download wsus updates but not install them.

WSUS GPO  2 : This is for Non-production servers. Set this GPO with the same settings as GPO number one except set the clients to download and install patches on Sunday morning at 6:00am

Apply this GPO WSUS GPO  2 to an AD group that only contains non-production servers as members (remove authenticated users) set the GPO to disable

WSUS GPO number 3: This is for Production servers. Set this GPO with the same settings as GPO number one except set the clients to download and install patches on Sunday morning at 6:00am

Apply WSUS GPO number 3 to an AD group that only contains production servers as members (remove authenticated users) set the GPO to disabled

Prior to the first Sunday of the month (Wednesday for example) release patches to your non production wsus clients group from the wsus server.

On the same day In GPMC deny access to WSUS GOP 1  for members of the AD group containing non-production servers as members and enable WSUS GPO  2 This will set all non-production servers to install patches on Sunday at 6:00am Do this on the same day you release patches to non-production servers in WSUS. The settings change from download only to download and install should apply across the domain in a few hours.

On Monday disable WSUS GPO number 2 and remove the deny permission to WUSU GPO 1 for the non-production AD group This will reset the non-production servers group clients back to download only mode. The settings change from download and install to download only should apply across the domain in a few hours.

Repeat the process for the production servers using  WSUS GPO 3 on the Wednesday before production patching.

Once the GPOs and groups are setup the entire process takes about 15 min of Admin work per month on Wednesdays and Mondays.

The biggest issue is that the servers need to be rebooted after you first add them to the security groups in order to be able to apply the GPOs that are targeted based on security group membership.

I want to do them once a month too because I just ran into my first issue with running VMs. 

We have 100 Windows 8 VMs running on 2 Hyper-V servers in a cluster. Well last Tuesday WSUS approved new updates and we used to push them down, auto install and prompt for a reboot at 9AM. Worked great on standalone computers. However on VMs once users started to reboot - it created a huge boot storm that took almost 4 hours for it to calm down. The biggest problem was the computer shut down to install updates, rebooted to install updates and shut down again to apply those updates and started back up clean after installation. Thats 4 boot cycles per 100 VMs. My users were NOT happy. So now the best I can do is schedule them to start Friday at 9PM so that it happens over the weekend. I now want to only install updates once a month. YIKES! 

Could you please let me know exactly how to configure it and run that vbwsus?

Is that hard to be configured, and where should I run that script?

Thanks

Moe

I think there is far to much generalization on this issue. That is great if you were able to have a weekly schedules maintenance window. You completely miss the point though, not everyone has that option. Try working in the medical field. Ever worked for a small CLIA laboratory? Ever been waiting to find out a serious health diagnosis? These labs tend to be staffed 24/7/365. They have analyzers that run all day and night transmitting data back to LIS software on servers. Server reboots are a serious thing. Heck just trying to move a network jack can turn into a whole day ordeal. Many of these labs are severely underfunded and have far to many HIPAA requirements imposed that has driven up cost of operations dramatically. So with funds already short the ability to have redundant HA systems isn't possible (Microsoft, Oracle, LIS, etc licensing becomes crazy in the order of 1/2mill).

I'd say it is very presumptuous to think all business can operate as you outlined. Especially when this honestly wouldn't be difficult to extend WSUS to provide more control. Third parties have done it.

The best you can do with WSUS by default is only approve when you actually plan to allow a reboot. That bothers me. So I have to go through the list all at once? What if I inspect available updates as they come in (say once a week) but not approve for install yet? Is there no way to "mark" these updates so you don't forget which you want to "approve" and push out? You can't approve them or they get installed and potentially restart a server.

It doesn't do any good to be dogmatic about how things have to be done. What users need is important. They need more flexibility than what is currently offered in WSUS.

Meanwhile I have Linux boxes that haven't restarted in years, yet get fully patched.