WSUS Deadlines in Multiple Timezones
Alan Burchill
Can anyone confirm that if you set a deadline on a patch in WSUS that the
deadline time will apply realitve to the server... not the client the patch
is being installed on.
Example. WSUS Master Server in GMT +10 time zone has a patch approve with a
deadline for 12:00pm and a workstation in the GMT +8 time zone that points to
that server installs the patch set with the deadline at 10:00am.
This seems to be very confusing behaviour as I know that control panel
option to install the patch at a specific time is relative to the time zone
the computer is set to not the time zone of the server.
Lawrence Garvin [MVP]
news:9076CB37-28B6-4C96...@microsoft.com...
> Hi...
>
> Can anyone confirm that if you set a deadline on a patch in WSUS that the
> deadline time will apply realitve to the server... not the client the
> patch
> is being installed on.
I can tell you this is definitively not true.
ALL installation and action times are controlled by the WIndows Update Agent
and relative to LOCAL time on the machine where the installation is
occuring.
If you set a deadline at noon, that will be noon LOCAL time -- around the
world. 24 possible installation events as the earth rotates past the sun
that day.
> Example. WSUS Master Server in GMT +10 time zone has a patch approve with
> a
> deadline for 12:00pm and a workstation in the GMT +8 time zone that points
> to
> that server installs the patch set with the deadline at 10:00am.
Installation will occur at 12:00pm in the GMT+8 time zone.
--
Lawrence Garvin, M.S., MCTS, MCP
Senior Data Architect, APQC, Houston, Texas
MVP - Software Distribution (2005-2007)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
Alan Burchill
Thanks for the reply but i can absoutly confirm that this deadline seems to
be relative to the Master server... Below are the event log of the server:
GMT +8 time zone...
Event Type: Information
Event Source: Windows Update Agent
Event Category: Installation
Event ID: 18
Date: 14/12/2007
Time: 11:46:22 AM
User: N/A
Computer: AUPERAP5
Description:
Installation Ready: The following updates are downloaded and ready for
installation. This computer is currently scheduled to install these updates
on Friday, 14 December 2007 at 11:00 AM:
- Security Update for Windows Server 2003 (KB943460)
And then we changed the time zone of the computer to GMT +12 and refreshed
Auto Update:
Event Type: Information
Event Source: Windows Update Agent
Event Category: Installation
Event ID: 18
Date: 14/12/2007
Time: 12:40:36 PM
User: N/A
Computer: AUPERAP5
Description:
Installation Ready: The following updates are downloaded and ready for
installation. This computer is currently scheduled to install these updates
on Friday, 14 December 2007 at 3:00 PM:
- Security Update for Windows Server 2003 (KB943460)
As you can see the instal time of the patch has changed so that it would
reboot at the same relative time as to the Master server which is in the
GMT+10 timezone.
This is not good as we will need to setup 24 different WSUS groups for
setting deadlines on different timezones.
Lawrence Garvin [MVP]
> GMT +8 time zone...
> Installation Ready: The following updates are downloaded and ready for
> installation. This computer is currently scheduled to install these
> updates
> on Friday, 14 December 2007 at 11:00 AM:
> - Security Update for Windows Server 2003 (KB943460)
> And then we changed the time zone of the computer to GMT +12 and refreshed
> Auto Update:
> Installation Ready: The following updates are downloaded and ready for
> installation. This computer is currently scheduled to install these
> updates
> on Friday, 14 December 2007 at 3:00 PM:
> - Security Update for Windows Server 2003 (KB943460)
Changing the time zone *AFTER* the update has been downloaded and scheduled
will definitely result in a change of the scheduled installation time.
Everything WSUS and WUA do internally are based in GMT. If you change the
LOCAL time zone, all references based on GMT offsets that have already been
scheduled will also shift.
A more appropriate test would be:
[a] Configure machine 'A' in one time zone.
[b] Configure machine 'B' in another time zone.
(Note: The machines can be physically next to one another; they could
even be VMs running on the same host instance of VP2007 or VS2005.)
[c] Point both machines to the SAME WSUS Server.
[d] Observe the installation times scheduled on each client machine.
I believe you'll see that all events scheduled (with or without deadlines)
occur in the client's timezone, based on the *value* configured at the
server.
e.g.
[1] If you configure a scheduled installation time for 3am via Group
Policy -- installation will *always* be at 3am LOCAL time at each client
system.
[2] If you configure a deadline for noon via an update approval --
installation will occur at the next available local installation time, or at
noon LOCAL time at each client system
Alan Burchill
different timezone are rebooting at the same time. One is GMT+10 and the
other is GMT+8.
One thing to point out is that that the GMT+8 (client) has daylight saving
enabled and the GMT+10 (Master Server) does not have daylight savings
enabled....
Alan Burchill
rebooting the server at the same time no matter the timezone.... Whatever i
do i cannot get server in different time zone patching at different times
when i have only set one deadline.
Lawrence Garvin [MVP]
>I have done some more test with out daylight savings and this it is still
> rebooting the server at the same time no matter the timezone.... Whatever
> i
> do i cannot get server in different time zone patching at different times
> when i have only set one deadline.
>
> "Alan Burchill" wrote:
>
>> I have tested you senario and both server sitting next to each other in
>> two
>> different timezone are rebooting at the same time. One is GMT+10 and the
>> other is GMT+8.
>>
>> One thing to point out is that that the GMT+8 (client) has daylight
>> saving
>> enabled and the GMT+10 (Master Server) does not have daylight savings
>> enabled....
Let me ask another question.. is this deadline *expired* == i.e. in the
past.
Or is this deadline in the future... not yet reached?
![Harry Johnston [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjWpkBAPqvc839nzAtvH7xG03OwcxExyoyKpBgg3G7rKJeLEHQ=s40-c)
Harry Johnston [MVP]
> This is not good as we will need to setup 24 different WSUS groups for
> setting deadlines on different timezones.
This suggests that you are not using the deadline functionality in the way in
which it is intended. (If there is a point beyond which it is too dangerous to
allow systems to remain unpatched, it stands to reason that point must be
reached simultaneously in all time zones.)
What are you actually trying to achieve? There may be another way of doing it.
Harry.
Alan Burchill
on the local time of that server. Lawrence tells me that deadlines are
applied to computer based on the time zone of that computer. So i am trying
to find out why we are not seeing this behaviour... or get confirmation that
deadline patches are applied to server based on the time of the master wsus
server... We can work around this but it would require setting approvals for
24 different timezones...
DevilsPGD
Burchill <AlanBu...@discussions.microsoft.com> wrote:
>I am trying to confirm that patch deadline will be applied to servers based
>on the local time of that server. Lawrence tells me that deadlines are
>applied to computer based on the time zone of that computer. So i am trying
>to find out why we are not seeing this behaviour... or get confirmation that
>deadline patches are applied to server based on the time of the master wsus
>server... We can work around this but it would require setting approvals for
>24 different timezones...
First off, do you actually have servers in all 24 timezones?
DevilsPGD
[MVP]" <ha...@scms.waikato.ac.nz> wrote:
>Alan Burchill wrote:
>
>> This is not good as we will need to setup 24 different WSUS groups for
>> setting deadlines on different timezones.
>
>This suggests that you are not using the deadline functionality in the way in
>which it is intended. (If there is a point beyond which it is too dangerous to
>allow systems to remain unpatched, it stands to reason that point must be
>reached simultaneously in all time zones.)
Yes and no -- The goal may be to set a deadline of "between close of
business December 17th and start of business December 18th", preferably
between 6pm and 7pm so that the in-town admins aren't sleeping when
something breaks.
(Consider a company that runs 8am-5pm, M-F, and cannot tolerate outages
during that time, but absolutely needs a high risk patch pushed even if
users forget to logout, no one is around to reboot servers, etc)
Deadlines, as I understand it, could accommodate that situation, whereas
not all patches would be worth pushing in such a fashion (but you still
wouldn't leave most unapproved, so you can't use the group policy
installation options)
That being said, unless you have literally thousands of servers
distributed across all 24 (or more, actually) timezones, you could
probably simplify substantially by grouping servers into one of a small
number of groups.
Harry Johnston [MVP]
>> What are you actually trying to achieve? There may be another way of doing
>> it.
> I am trying to confirm that patch deadline will be applied to servers based
> on the local time of that server.
Let me rephrase the question - why were you trying to use deadlines in the first
place?
Harry.
Harry Johnston [MVP]
>> This suggests that you are not using the deadline functionality in the way in
>> which it is intended. (If there is a point beyond which it is too dangerous to
>> allow systems to remain unpatched, it stands to reason that point must be
>> reached simultaneously in all time zones.)
>
> Yes and no -- The goal may be to set a deadline of "between close of
> business December 17th and start of business December 18th", preferably
> between 6pm and 7pm so that the in-town admins aren't sleeping when
> something breaks.
>
> (Consider a company that runs 8am-5pm, M-F, and cannot tolerate outages
> during that time, but absolutely needs a high risk patch pushed even if
> users forget to logout, no one is around to reboot servers, etc)
OK, that's certainly a credible scenario in which deadlines might be used, and
obviously you'd want to set them based on local time. Thanks; I never did
understand what the durn things were for. :-)
Harry.
Alan Burchill
But for this example lets just concentrate on APAC region... We cover New
Zeland to Perth which means we need to arrange patching for 4 difference time
zones. NZ is 4 hours ahead of Perth and as such we cannot patch NZ server at
the same time as Perth. We use deadline as a method of forceing out patches
at a predetermined time to a region so we dont have to individually logon to
every server and apply the patches and then reboot the server... (we do still
do checks on the serers after they have patched but this is far less work).
So i want to be able to set a outage window which is the same time (locally)
for each time zone. Normally this means i would have one WSUS group called
"Servers APAC" and then i would simply set the deadline on the patches on
that WSUS group and any sub groups would just inherit the approvals and
deadline.
However to achieve patching at the same local time it looks like i will need
to set the approval on four seperate sub group under "Servers APAC" (e.g.
NZST 8pm, AEST 10pm, ADST 9pm, WDST 12pm) so that all the servers will reboot
at the same local time. As you can see this makes patch approval far more
complicated and i would like to be able to set a deadline once and have that
deadline applied to the server as per local time of the machine not local
time of the WSUS master server.
Either way i just need confirmation that the behaviour i am seeing is infact
correct and that i am not dealing with some of issue.
DevilsPGD
[MVP]" <ha...@scms.waikato.ac.nz> wrote:
In practice, I'd be just as happy with a "force immediate installation"
flag -- That's about all I actually do with the deadline functionality.
But in a larger corporation, I can see the utility of more
functionality.
Harry Johnston [MVP]
> [...] We use deadline as a method of forceing out patches at a predetermined
> time to a region so we dont have to individually logon to every server and
> apply the patches and then reboot the server... (we do still do checks on the
> serers after they have patched but this is far less work).
Why don't you use the group policy settings to determine the installation time?
(I'm sure you have a reason, I'm just curious as to what it is.)
Another option you may want to consider is using scripting to install the
patches; this approach gives you a bit more flexibility.
<http://www.scms.waikato.ac.nz/~harry/wsusupdate.vbs>
> Either way i just need confirmation that the behaviour i am seeing is infact
> correct and that i am not dealing with some of issue.
This doesn't appear to be documented, so I guess one could argue that whatever
behaviour is observed is the correct behaviour. That doesn't mean it won't
change in the future, mind you.
Unfortunately with the end of the year approaching I don't think I'll have time
to try the experiment myself. But I can't imagine any reason why this would
only affect your installation.
Harry.
DevilsPGD
[MVP]" <ha...@scms.waikato.ac.nz> wrote:
>Alan Burchill wrote:
>
>> [...] We use deadline as a method of forceing out patches at a predetermined
>> time to a region so we dont have to individually logon to every server and
>> apply the patches and then reboot the server... (we do still do checks on the
>> serers after they have patched but this is far less work).
>
>Why don't you use the group policy settings to determine the installation time?
> (I'm sure you have a reason, I'm just curious as to what it is.)
Not all patches are deserving of a scheduled reboot, but you may still
want to approve them anyway.
>Another option you may want to consider is using scripting to install the
>patches; this approach gives you a bit more flexibility.
>
><http://www.scms.waikato.ac.nz/~harry/wsusupdate.vbs>
This sounds like the way to go.
Alan Burchill
patches that can be pushed out via WSUS. We want to move from an every patch
manually installed model to a automaticlly install all mandated patch model.
However we still want the option to push out patches via WSUS but not force
the install automatilly.
But it would still be nice to distribute patches using WSUS but not force
the install at the same time to allow a more gradual and managed install when
needed. (e.g. IE7 or .Net Framework 3.0).
Thanks for you help.
Alan
Harry Johnston [MVP]
> As we are a big company we have internally mandated patches and optional
> patches that can be pushed out via WSUS. We want to move from an every patch
> manually installed model to a automaticlly install all mandated patch model.
> However we still want the option to push out patches via WSUS but not force
> the install automatilly.
OK. That makes sense; thanks for explaining and sorry it took so long for me to
get my head around it!
If you find that deadlines aren't an ideal solution, do consider using the
scripting approach. That way, you're only limited by the capabilities of your
programmers. :-)
Harry.