|
|
I work at an Educational institution and have a narrow window in which to
install updates. The reason for this window is we have an application much
like Windows SteadyState installed, which prevents changes made to a PC from
becoming permanent as they are wiped when rebooted.
As such, we have a period overnight (1hr 15mins) when clients turn off this
application to install updates, update their antivirus and run scripts that
we use to make alterations.
Updates are scheduled in this period but occasionally we find that updates
have been downloaded from our WSUS and installed out of this period. After
they have finished installing, the PC reboots, wipes the changes, starts up,
tries to install updates again, reboots, wipes...........it's a vicous circle
until the period comes around again or we manually disable the wiping
application.
I believe this leads to 3 possiblities
1. The updates are not finishing during the this period, and so when the
period ends, the update process is locked into the PC.
2.The updates are downloaded, but the installation is delayed for some
reason, and again the update process ends up getting locked into the PC.
3. The WSUS server/client is forcing an update out of the scheduled period
for some reason, but I believe this to be unlikely.
We use GPO's to set the update schdule. They have been chacked and are all
correct. We often find that this occurs after we reimage the PC's, which lead
us to believe that perhaps the image was old and required a lot for patches
and was therefore running over the time period. However we have since
deployed a resonably upto date image (updates wise), where all it needed were
some IE7 patches which would take 5 minutes max to install. The network in
this area is 100Mbps, so they shouldn't struggle to download the patches int
time. The problem occured again, and has left us scratching our heads!
Also, as an after thoguht, when MS release their monthly set of updates,
which can be quite a few and large, we never get this problem. You'd think
this would potentially be the worst time as all PC's would be postentially
downloading a lot of updates, thus swampin the network, thus taking a long
time to download them, thus running over the time allowed to do this.
Any ideas?
Cheers,
Matt
|
|
If you can post the portion of a windowsupdate.log from a time when this
happens it should help.
One thing to keep in mind is that the updates don't download to the client
at install time, they download at random times durring the day and wait on
the machine for the install time to hit.
How often does this software reset the machines back to the original state?
How does it know what state to fall back to?
I'm wondering if it's an issue where because of the wipe it appears to the
au client that it missed the install time.
Eddie Bowers
Security Support
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
|
|
[Quoted Text] > If you can post the portion of a windowsupdate.log from a time when this
> happens it should help.
The update is log is on the client, as the client resets after a reboot the
windowsupdate.log is wiped :(
> One thing to keep in mind is that the updates don't download to the client
> at install time, they download at random times durring the day and wait on
> the machine for the install time to hit.
> How often does this software reset the machines back to the original state?
Everytime the Machine is restarted appart from during the epriod when this
application is effectively switched off. When this occurs, it reboots first
to reset the PC to it orginal state and then switches itself off, to remove
any nasties before it becomes vulnerable.
> How does it know what state to fall back to?
I'm really not sure. It's a black art! All i know is it works extremly well
and has kept 1000 machines virus free and unhacked for several years.
> I'm wondering if it's an issue where because of the wipe it appears to the
> au client that it missed the install time.
The AU is scheduled to occur during the period in which the application
mentioned above is switched off. Even a large download and update should
complete in 1hr 15mins from a WSUS ona 100Mbps network. As the update should
have finished before the application is reactivated, upon reactivation the
application will see the new state as the one it should fall back to, not the
state previous to the updates.
Cheers,
Matt
|
|
=?Utf-8?B?TWF0dCBXYXRzb24=?= <MattWatson[ at ]discussions.microsoft.com>
wrote in news:914F20AD-C23D-4CDB-915F-8134281DA03D[ at ]microsoft.com:
[Quoted Text] >
>
>> If you can post the portion of a windowsupdate.log from a time when
>> this happens it should help.
>
> The update is log is on the client, as the client resets after a
> reboot the windowsupdate.log is wiped :(
>
>> One thing to keep in mind is that the updates don't download to the
>> client at install time, they download at random times durring the day
>> and wait on the machine for the install time to hit.
>> How often does this software reset the machines back to the original
>> state?
>
> Everytime the Machine is restarted appart from during the epriod when
> this application is effectively switched off. When this occurs, it
> reboots first to reset the PC to it orginal state and then switches
> itself off, to remove any nasties before it becomes vulnerable.
>
>> How does it know what state to fall back to?
>
> I'm really not sure. It's a black art! All i know is it works extremly
> well and has kept 1000 machines virus free and unhacked for several
> years.
>
>> I'm wondering if it's an issue where because of the wipe it appears
>> to the au client that it missed the install time.
>
> The AU is scheduled to occur during the period in which the
> application mentioned above is switched off. Even a large download and
> update should complete in 1hr 15mins from a WSUS ona 100Mbps network.
> As the update should have finished before the application is
> reactivated, upon reactivation the application will see the new state
> as the one it should fall back to, not the state previous to the
> updates.
>
And there lies the flaw in your logic.
The updates are downloaded to the clients upon detection. The are APPLIED
at a specified time.
A detection occurs one of three ways:
1- At client power on
2- When a wuauclt /detectnow command is executed
3- every X hours (configured in GPO) +/- a random offset.
When updates are detected as needed, they are pulled by the client using
BITS.
They will sit there until install time.
Have you looked at using GPOs to lock down the clients?
> Cheers,
>
> Matt
>
|
|
[Quoted Text] >
> >
> >
> >> If you can post the portion of a windowsupdate.log from a time when
> >> this happens it should help.
> >
> > The update is log is on the client, as the client resets after a
> > reboot the windowsupdate.log is wiped :(
> >
> >> One thing to keep in mind is that the updates don't download to the
> >> client at install time, they download at random times durring the day
> >> and wait on the machine for the install time to hit.
> >> How often does this software reset the machines back to the original
> >> state?
> >
> > Everytime the Machine is restarted appart from during the epriod when
> > this application is effectively switched off. When this occurs, it
> > reboots first to reset the PC to it orginal state and then switches
> > itself off, to remove any nasties before it becomes vulnerable.
> >
> >> How does it know what state to fall back to?
> >
> > I'm really not sure. It's a black art! All i know is it works extremly
> > well and has kept 1000 machines virus free and unhacked for several
> > years.
> >
> >> I'm wondering if it's an issue where because of the wipe it appears
> >> to the au client that it missed the install time.
> >
> > The AU is scheduled to occur during the period in which the
> > application mentioned above is switched off. Even a large download and
> > update should complete in 1hr 15mins from a WSUS ona 100Mbps network.
> > As the update should have finished before the application is
> > reactivated, upon reactivation the application will see the new state
> > as the one it should fall back to, not the state previous to the
> > updates.
> >
>
> And there lies the flaw in your logic.
>
> The updates are downloaded to the clients upon detection. The are APPLIED
> at a specified time.
>
> A detection occurs one of three ways:
> 1- At client power on
> 2- When a wuauclt /detectnow command is executed
> 3- every X hours (configured in GPO) +/- a random offset.
>
> When updates are detected as needed, they are pulled by the client using
> BITS.
> They will sit there until install time.
>
> Have you looked at using GPOs to lock down the clients?
We do use GPO's to set the installation time to occur during the period when
the application is switched off. Otherwise it would be madness :)
Cheers,
Matt
|
|
Your comment about when the updates download to the client is very
interesting. It appears that Matt (and my problem also) is that we need to
force the download during a specific time period. I have a larger window to
operate, but there are certain time periods during the day when WSUS
shouldn't be downloading. I know there is a way to force the updates to
install at a certain time, but can we control when the downloads take place?
"Eddie Bowers [MSFT]" wrote:
[Quoted Text] > If you can post the portion of a windowsupdate.log from a time when this
> happens it should help.
>
> One thing to keep in mind is that the updates don't download to the client
> at install time, they download at random times durring the day and wait on
> the machine for the install time to hit.
> How often does this software reset the machines back to the original state?
> How does it know what state to fall back to?
> I'm wondering if it's an issue where because of the wipe it appears to the
> au client that it missed the install time.
>
> Eddie Bowers
> Security Support
> Microsoft Corporation
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
|
|
"Matt Watson" <MattWatson[ at ]discussions.microsoft.com> wrote in message
news:914F20AD-C23D-4CDB-915F-8134281DA03D[ at ]microsoft.com...
[Quoted Text] >> If you can post the portion of a windowsupdate.log from a time when this
>> happens it should help.
>
> The update is log is on the client, as the client resets after a reboot
> the
> windowsupdate.log is wiped :(
That's a real problem!
And will continue to be a problem even if you get this thing working
correctly, as that file will be continuously updated as the WUA runs
quasi-random detection and reporting events, and if your utility cleans
files just because they were modified, you'll *never* have a usable history
of events on these systems.
I would suggest adding a shutdown script to your machine to offload those
(and probably other critical) log files to a network server somewhere.
>> How does it know what state to fall back to?
>
> I'm really not sure. It's a black art! All i know is it works extremly
> well
> and has kept 1000 machines virus free and unhacked for several years.
Given your postings here, and the already observed issue with deleting
critical system logfiles, I would take exception to your characterization
that "... it works extremely well".
I'm also quite surprised at the "black art" response for a utility running
on machines you're responsible for. If I were in that situation, I'd want to
be intimately familiar with how a machine mucked with my installations
before I turned it loose.
Otherwise.. here's a hint for an alternative methodology that's a gazillion
times safer: Use Virtual PC 2007 with UNDO disks for your training
environments. Leave the host operating system locked down and inaccessible
to the students. Run all student activities in a Virtual Machine, which can
be rolled back when you want to roll it back, not at every single bloody
restart -- which, in my mind, makes properly managing such machines
virtually impossible (as you may now be experiencing).
>> I'm wondering if it's an issue where because of the wipe it appears to
>> the
>> au client that it missed the install time.
>
> The AU is scheduled to occur during the period in which the application
> mentioned above is switched off. Even a large download and update should
> complete in 1hr 15mins from a WSUS ona 100Mbps network.
Except that the *download* doesn't occur during the scheduled event, it
occurs throughout the entire day, according to whenever the detection was
performed. Thus, it's entirely possible, nay *probable* that:
[a] Some reboot during the middle of the day is wiping out the full
download of the update package, which means it's not there during the
scheduled installation.
[b] Some reboot during the middle of the day is wiping out the partial
download of the update package, which means the download event starts over,
and is not completed by the time of the scheduled installation.
Having tossed this back and forth, I'm going to offer a pretty generic
statement pertaining to this situation:
Windows Server Update Services is not compatible with, nor functional
in, your chosen operational environment
and *scripting* as Harry has suggested is going to be your only viable
option for getting updates installed during a scheduled event.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
One option for you would be to adjust the BITS settings via Group
Policy. This is found in Computer Configuration>Administrative
Templates>Network>Background Intelligent Transfer Service. Set the BITS
transfer rate at 0 during the time you don't want the updates to
download and allow it to use all available bandwidth during your
maintenance window.
Unless you have a massive amount of updates to download or slow links it
shouldn't take too much time to get those patches downloaded, especially
if the computer is just sitting idle.
Benny wrote:
[Quoted Text] > Your comment about when the updates download to the client is very
> interesting. It appears that Matt (and my problem also) is that we need to
> force the download during a specific time period. I have a larger window to
> operate, but there are certain time periods during the day when WSUS
> shouldn't be downloading. I know there is a way to force the updates to
> install at a certain time, but can we control when the downloads take place?
>
> "Eddie Bowers [MSFT]" wrote:
>
>> If you can post the portion of a windowsupdate.log from a time when this
>> happens it should help.
>>
>> One thing to keep in mind is that the updates don't download to the client
>> at install time, they download at random times durring the day and wait on
>> the machine for the install time to hit.
>> How often does this software reset the machines back to the original state?
>> How does it know what state to fall back to?
>> I'm wondering if it's an issue where because of the wipe it appears to the
>> au client that it missed the install time.
>>
>> Eddie Bowers
>> Security Support
>> Microsoft Corporation
>>
>> This posting is provided "AS IS" with no warranties, and confers no rights.
>>
>>
|
|
They key here is that the updates DONT download durring this time you set
in the GPO. They start durring a random time durring the day unless you
force a detection. And even then, when you force this detection and the
download starts, it's done by BITS(Background Intelligent Transfer Service)
, which is designed to do this relatively slowly to prevent impacting your
bandwidth with all the downloads.
I think a scripted solution may be best in your case, but i'm not sure the
best way to ensure that BITS will download the updates durring your window.
Eddie Bowers
Security Support
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
|
|
"Benny" <Benny[ at ]discussions.microsoft.com> wrote in message
news:F3D9CD1B-ABCC-4983-A2D5-1CDB1FBC943D[ at ]microsoft.com...
[Quoted Text] > Your comment about when the updates download to the client is very
> interesting. It appears that Matt (and my problem also) is that we need to
> force the download during a specific time period. I have a larger window
> to
> operate, but there are certain time periods during the day when WSUS
> shouldn't be downloading. I know there is a way to force the updates to
> install at a certain time, but can we control when the downloads take
> place?
You can... but be cautioned that having a gazillion computers all trying to
download from the same server, at the same time block, could be detrimental
to the performance of your server, and ultimately result in *no* client
being updated. You'll probably have to use a beefed up server (extra disk
speed capacity, extra network bandwidth) to provide this service.
Having said that, configure the policy setting "Maximum network bandwidth
that BITS uses" in
Computer Configuration | Administrative Templates | Network | Background
Intelligent Transfer Service
Essentially what you want to do is restrict BITS so that it can only
transfer data during your specified time frame, by setting "Limit BITS
transfer rate" to the period of time of your maintenance window will be. Set
"At all other times ... Limit BITS transfer rate" to =zero=.
Also, you'll have to adjust your maintenance windows (or no-reboot window,
as in Matt's case) to wrap around the scheduled installation time. It's
still required that the download be completed prior to the start of the
scheduled installation event, or the update will not be installed.
--
Lawrence Garvin, M.S., MCTS, MCP
Independent WSUS Evangelist
MVP-Software Distribution (2005-2007)
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E
Everything you need for WSUS is at
http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....
|
|
Thank you. I'll give that a try. Right now I've broken something and the
clients aren't downloading at all. They are checking into the server, but
none are downloading updates. That is the subject of another thread so I
won't ask about it here.
"Wade Godfrey" wrote:
[Quoted Text] > One option for you would be to adjust the BITS settings via Group
> Policy. This is found in Computer Configuration>Administrative
> Templates>Network>Background Intelligent Transfer Service. Set the BITS
> transfer rate at 0 during the time you don't want the updates to
> download and allow it to use all available bandwidth during your
> maintenance window.
> Unless you have a massive amount of updates to download or slow links it
> shouldn't take too much time to get those patches downloaded, especially
> if the computer is just sitting idle.
>
> Benny wrote:
> > Your comment about when the updates download to the client is very
> > interesting. It appears that Matt (and my problem also) is that we need to
> > force the download during a specific time period. I have a larger window to
> > operate, but there are certain time periods during the day when WSUS
> > shouldn't be downloading. I know there is a way to force the updates to
> > install at a certain time, but can we control when the downloads take place?
> >
> > "Eddie Bowers [MSFT]" wrote:
> >
> >> If you can post the portion of a windowsupdate.log from a time when this
> >> happens it should help.
> >>
> >> One thing to keep in mind is that the updates don't download to the client
> >> at install time, they download at random times durring the day and wait on
> >> the machine for the install time to hit.
> >> How often does this software reset the machines back to the original state?
> >> How does it know what state to fall back to?
> >> I'm wondering if it's an issue where because of the wipe it appears to the
> >> au client that it missed the install time.
> >>
> >> Eddie Bowers
> >> Security Support
> >> Microsoft Corporation
> >>
> >> This posting is provided "AS IS" with no warranties, and confers no rights.
> >>
> >>
>
|
|
Unfortunately, I have a fairly old and slow server. It barely meets the
requirements for WSUS. However, after hours I have a very fast network and
about 12 hours in order to update approximately 75 client computers and 6
servers. That should provide sufficient bandwidth and capability to download
most updates. If something like W2K Sp4 or XP SP1 comes along, I may need to
divide the computers into groups and update them over several days.
I'm faced with a decree from upper management that absolutely no updates
will be sent out during business hours....
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "Benny" <Benny[ at ]discussions.microsoft.com> wrote in message > news:F3D9CD1B-ABCC-4983-A2D5-1CDB1FBC943D[ at ]microsoft.com... > > Your comment about when the updates download to the client is very > > interesting. It appears that Matt (and my problem also) is that we need to > > force the download during a specific time period. I have a larger window > > to > > operate, but there are certain time periods during the day when WSUS > > shouldn't be downloading. I know there is a way to force the updates to > > install at a certain time, but can we control when the downloads take > > place? > > You can... but be cautioned that having a gazillion computers all trying to > download from the same server, at the same time block, could be detrimental > to the performance of your server, and ultimately result in *no* client > being updated. You'll probably have to use a beefed up server (extra disk > speed capacity, extra network bandwidth) to provide this service. > > Having said that, configure the policy setting "Maximum network bandwidth > that BITS uses" in > Computer Configuration | Administrative Templates | Network | Background > Intelligent Transfer Service > > Essentially what you want to do is restrict BITS so that it can only > transfer data during your specified time frame, by setting "Limit BITS > transfer rate" to the period of time of your maintenance window will be. Set > "At all other times ... Limit BITS transfer rate" to =zero=. > > Also, you'll have to adjust your maintenance windows (or no-reboot window, > as in Matt's case) to wrap around the scheduled installation time. It's > still required that the download be completed prior to the start of the > scheduled installation event, or the update will not be installed. > > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) > https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E> > Everything you need for WSUS is at > http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx> > And, almost everything else is at > http://wsusinfo.onsitechsolutions.com> ..... > > > |
|
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "Matt Watson" <MattWatson[ at ]discussions.microsoft.com> wrote in message
> news:914F20AD-C23D-4CDB-915F-8134281DA03D[ at ]microsoft.com...
>
> >> If you can post the portion of a windowsupdate.log from a time when this
> >> happens it should help.
> >
> > The update is log is on the client, as the client resets after a reboot
> > the
> > windowsupdate.log is wiped :(
>
> That's a real problem!
>
> And will continue to be a problem even if you get this thing working
> correctly, as that file will be continuously updated as the WUA runs
> quasi-random detection and reporting events, and if your utility cleans
> files just because they were modified, you'll *never* have a usable history
> of events on these systems.
>
> I would suggest adding a shutdown script to your machine to offload those
> (and probably other critical) log files to a network server somewhere.
Ok Mr. Knowitall, I assume you've read all the posts in this thread
throughly and have based you replies upon all of them since you're a "WSUS
Evangelist" and wouldn't miss a trick in order to uphold this lofty and nobel
position.
Since this is the case it baffles me somewhat to see your reply. Clearly if
the updates are attempted during a locked down period a restart would kill
the affor mentioned update log. However, when the update occurs during an
unlocked period (the 1hr 15min slot or thorugh a manual disabling of the
application), the updates would complete and the log would becreated/updated.
However I believe the Asher_N was asking me for a log whilst the continual
rebooting problem was occuring as clearly once a PC has been unlocked and the
updates have been installed the "a time when this [problem] happens" has
passed. If it would be helpful to still post the contents of this log, I
would be happy to do so, and all you have to do it politely point out that
maybe I've missed the point and request it. Rather than bashing the methods
of fellow professionals that you really don't have any knowledge or
experience of.
> >> How does it know what state to fall back to?
> >
> > I'm really not sure. It's a black art! All i know is it works extremly
> > well
> > and has kept 1000 machines virus free and unhacked for several years.
>
> Given your postings here, and the already observed issue with deleting
> critical system logfiles, I would take exception to your characterization
> that "... it works extremely well".
>
> I'm also quite surprised at the "black art" response for a utility running
> on machines you're responsible for. If I were in that situation, I'd want to
> be intimately familiar with how a machine mucked with my installations
> before I turned it loose.
It's a black art because it is third party software and they want to keep
their methods secret so that hackers find it more difficult to circumvent
this method of security. At our best guess, our team believes that the
application keps a record of all the changes on the HDD on bit by bit basis,
returning modified files to their original state at the point of locking and
deleteing new files at somepoint during startup as a hard reset doesn't seem
to prevent the rolling back of changes. But I didn't really think that this
was particularly useful information.
> Otherwise.. here's a hint for an alternative methodology that's a gazillion
> times safer: Use Virtual PC 2007 with UNDO disks for your training
> environments. Leave the host operating system locked down and inaccessible
> to the students. Run all student activities in a Virtual Machine, which can
> be rolled back when you want to roll it back, not at every single bloody
> restart -- which, in my mind, makes properly managing such machines
> virtually impossible (as you may now be experiencing).
Please don't swear, it's not inspiring to the those asking for help and it's
not becoming of an "Evangelist", what ever their field of expertise. Our PC's
very rarely restart more than twice a day (Once to unlock and lock again. We
keep logs of shutdowns and startups on a seperate server. Which leads to the
question, can you force the update log to be stored remotely? Hence it would
be immune to restarts during locked periods)
We're a bit hesitant about using virtual technology. Partly because our
current client's/server's hardware is not up to the job for servicing this
software locally/remotely and we don't have a huge pot of money to buy a
server capable of serving 1000+ PC's.
I agree that this would be a less aggressive form of security and safer in
regards to successful installation of updates. However, because our
univeristy is on a very high speed connection to the outside world, people
are continually trying to hack us to use us as file stores and students are
continually trying to install downloading software. This coupled with a user
base of several thousands which is infiltrated with malicious and IT
illiterate individuals leads to unprotected images becoming corrupetd, slow
and difficult for the vast majority of well meaning users to use. Therefore
we use this locking application to maintain the integrity of the PC's so that
we provide a consistent, stable and efficient service. Yes, I know it sounds
like management spiel, but it's actually what we aim for.
> >> I'm wondering if it's an issue where because of the wipe it appears to
> >> the
> >> au client that it missed the install time.
> >
> > The AU is scheduled to occur during the period in which the application
> > mentioned above is switched off. Even a large download and update should
> > complete in 1hr 15mins from a WSUS ona 100Mbps network.
>
> Except that the *download* doesn't occur during the scheduled event, it
> occurs throughout the entire day, according to whenever the detection was
> performed. Thus, it's entirely possible, nay *probable* that:
> [a] Some reboot during the middle of the day is wiping out the full
> download of the update package, which means it's not there during the
> scheduled installation.
> [b] Some reboot during the middle of the day is wiping out the partial
> download of the update package, which means the download event starts over,
> and is not completed by the time of the scheduled installation.
I actually like this comment, helpful and not totally patronising.
I agree, the reboots would wipe the downloaded patches. With this in mind,
when a client boots into it unlocked state, would it then redownload the
patches straight away? If it had previously completed the download, would the
Client try to download all the patches again, or would the client or the WSUS
be of the opinion that the updates were availble on the client for install,
rightly or wrongly?
Sorry to have produced a grumpy reply, but I really find it hard when spoken
to in a patronising manner which suggests I'm ignorant/naive in someway. I
post here because I don't have time to spend hours ceaselessly testing. We
peobably could figure it out our selves, but the wealth of knowledge here is
very helpful and speeds up the time to a fix. We don't post here because we
are naive or ignoranrt and therefore would like to be treated as such and *I*
dont *need* every *important* word *stressed* in *a* sentance *because* it's
*just* plain *irritating*
Thankyou to everyone for your very helpful comments so far, including those
that have rubbed me up the wrong way. They are all very much appreciated :)
Cheers,
Matt
|
|
Matt Watson wrote:
[Quoted Text] > It's a black art because it is third party software and they want to keep
> their methods secret so that hackers find it more difficult to circumvent
> this method of security. At our best guess, our team believes that the
> application keps a record of all the changes on the HDD on bit by bit basis,
> returning modified files to their original state at the point of locking and
> deleteing new files at somepoint during startup as a hard reset doesn't seem
> to prevent the rolling back of changes.
More likely the changes are being written to a separate area, with the software
keeping track of which sectors have changed. This methodology means discarding
the changes is trivial.
Anyway ... you are likely running into trouble because when the machines comes
up in the locked mode WSUS sees itself as having missed a scheduled
installation, so tries to perform it straight away. I believe this would only
happen if one or more updates were downloaded (but not installed) during the
unlocked period.
I'd suggest you reconfigure the Windows Update settings on the client to use
option 1, detect but do not download or install updates. This should prevent
patches being installed while the machines are up. Then you can use a script to
download and install updates while the machine is unlocked.
> I agree, the reboots would wipe the downloaded patches. With this in mind,
> when a client boots into it unlocked state, would it then redownload the
> patches straight away? If it had previously completed the download, would the
> Client try to download all the patches again, or would the client or the WSUS
> be of the opinion that the updates were availble on the client for install,
> rightly or wrongly?
Any activity during the locked period would have no effect on the behaviour
during the unlocked period, because everything is kept on the client and is
being discarded. It is probably easiest to pretend that the machine was
switched off between unlocked periods and consider how WSUS behaves on machines
that are only on briefly once a day ... I suppose it would start the download,
or the install if it had downloaded the previous day, nearly straight away.
I have a fully scripted install process for the machines in our teaching labs.
One of the very last steps is to update from WSUS so that I don't need to script
every update. I use the following VBScript, which may suit your purposes.
It installs all the currently applicable patches from the WSUS server. There is
no prompting or other confirmation. Oh, and it's never been tested with WSUS 3,
though I don't expect any problems.
There are other scripts available on the web which perform similar functions if
this one doesn't suit your precise needs.
' Written in 2007 by Harry Johnston, University of Waikato, New Zealand.
' This code has been placed in the public domain. It may be freely
' used, modified, and distributed. However it is provided with no
' warranty, either express or implied.
'
' Exit Codes:
' 0 = scripting failure
' 1 = error obtaining or installing updates
' 2 = installation successful, no further updates to install
' 3 = reboot needed; rerun script after reboot
'
' Note that exit code 0 has to indicate failure because that is what
' is returned if a scripting error is raised.
'
Set updateSession = CreateObject("Microsoft.Update.Session")
Set updateSearcher = updateSession.CreateUpdateSearcher()
Set updateDownloader = updateSession.CreateUpdateDownloader()
Set updateInstaller = updateSession.CreateUpdateInstaller()
Do
WScript.Echo
WScript.Echo "Searching for approved updates ..."
WScript.Echo
Set updateSearch = updateSearcher.Search("IsInstalled=0")
If updateSearch.ResultCode <> 2 Then
WScript.Echo "Search failed with result code", updateSearch.ResultCode
WScript.Quit 1
End If
If updateSearch.Updates.Count = 0 Then
WScript.Echo "There are no updates to install."
WScript.Quit 2
End If
Set updateList = updateSearch.Updates
For I = 0 to updateSearch.Updates.Count - 1
Set update = updateList.Item(I)
WScript.Echo "Update found:", update.Title
Next
WScript.Echo
updateDownloader.Updates = updateList
updateDownloader.Priority = 3
Set downloadResult = updateDownloader.Download()
If downloadResult.ResultCode <> 2 Then
WScript.Echo "Download failed with result code", downloadResult.ResultCode
WScript.Echo
WScript.Quit 1
End If
WScript.Echo "Download complete. Installing updates ..."
WScript.Echo
updateInstaller.Updates = updateList
Set installationResult = updateInstaller.Install()
If installationResult.ResultCode <> 2 Then
WScript.Echo "Installation failed with result code",
installationResult.ResultCode
For I = 0 to updateList.Count - 1
Set updateInstallationResult = installationResult.GetUpdateResult(I)
WScript.Echo "Result for " & updateList.Item(I).Title & " is " &
installationResult.GetUpdateResult(I).ResultCode
Next
WScript.Quit 1
End If
If installationResult.RebootRequired Then
WScript.Echo "The system must be rebooted to complete installation."
WScript.Quit 3
End If
WScript.Echo "Installation complete."
Loop
|
|
I wrote:
[Quoted Text] > I'd suggest you reconfigure the Windows Update settings on the client to
> use option 1, detect but do not download or install updates.
Oops, that should have been option 2.
Harry.
|
|
"Harry Johnston" wrote:
[Quoted Text] > I wrote:
>
> > I'd suggest you reconfigure the Windows Update settings on the client to
> > use option 1, detect but do not download or install updates.
>
> Oops, that should have been option 2.
>
> Harry.
>
|
|
"Harry Johnston" wrote:
[Quoted Text] > I wrote:
>
> > I'd suggest you reconfigure the Windows Update settings on the client to
> > use option 1, detect but do not download or install updates.
>
> Oops, that should have been option 2.
>
> Harry.
>
Thanks very much Harry. The script is excellent and may well sort out our
sorrows :) Hopefully I'll remeber to update the thread should this fix our
problem :)
Cheers,
Matt
|
|
|