|
|
We have just installed and are currently testing WSUS 3.0 in a educational
facility. We are experiencing several of the issues listed in these
newsgroups. We have a limited amount of time to deploy updates to several
labs. The WSUS is fighting us but, works correctly about 20% of the time. The
WSUS server has all the updates downloaded and I am trying to find a way to
either force feed from WSUS to client updates or manually install from WSUS
to client from the client. The latter would work fine but, I can only see
cabs avaialble. Is there a way to do the a manual client update going from
client to WSUS? I have over 1500 systems to address and I am trying to
conserve Internet bandwidth for others that are still working. Can this be
done?
Duggan
|
|
I have a very similar issue. I also work at an Educational institution and
have a narrow window in which to install updates. The reason for this window
is slightly different as 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!
Any ideas?
Cheers,
Matt
"Duggan 59" wrote:
[Quoted Text] > We have just installed and are currently testing WSUS 3.0 in a educational
> facility. We are experiencing several of the issues listed in these
> newsgroups. We have a limited amount of time to deploy updates to several
> labs. The WSUS is fighting us but, works correctly about 20% of the time. The
> WSUS server has all the updates downloaded and I am trying to find a way to
> either force feed from WSUS to client updates or manually install from WSUS
> to client from the client. The latter would work fine but, I can only see
> cabs avaialble. Is there a way to do the a manual client update going from
> client to WSUS? I have over 1500 systems to address and I am trying to
> conserve Internet bandwidth for others that are still working. Can this be
> done?
>
> Duggan
|
|
Matt Watson wrote:
[Quoted Text] > I have a very similar issue. I also work at an Educational institution and
> have a narrow window in which to install updates. The reason for this window
> is slightly different as 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.
I suggest you turn off scheduled installation and instead run a script to
download and install updates from WSUS as part of the overnight process; this
should give you more control over the process.
Harry.
|
|
"Matt Watson" <Matt Watson[ at ]discussions.microsoft.com> wrote in message
news:C0F34A87-496E-4677-BECB-CA8E1794A679[ at ]microsoft.com...
[Quoted Text] > The reason for this window
> is slightly different as 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.
There are only *two* possible ways this could happen:
[a] A deadline has been configured on the update forcing it to install prior
to the scheduled installation event.
[b] Users (students?) are initiating the installation of the update during
their regular use period. This would be possible due to a (critical, for
your environment) misconfiguration. The good news is that proper policy
settings can totally prevent user interaction with this process.
> 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.
Yep.
> 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.
#2 could happen if the machines were powered down during the scheduled
installation event, and then a power up cause the initiation of an
installation as a result of the missed scheduled event. This can be
prevented by disabling the policy "Reschedule automatic updates scheduled
installations", which will let installations only happen during the
/scheduled/ event time period.
#3 is a bit more likely, but would be only a function of a deadline being
configured (as noted above).
The most likely scenario is that your students have admin privileges and are
initiating (interactively) the installation of the updates, which, of
course, is being rolled back after the reboot, which, as you noted, is then
triggering a new detection (the updates are already downloaded), followed
immediately by a notification area prompt that "updates are ready to be
installed".
To remedy this situation, enable the policy setting "Remove access to use
all Windows Update features" in combination with disabling "Reschedule
Automatic Updates scheduled installations", which will force the only
possible installation scenario to be the configured policy time period.
--
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
.....
>
|
|
"Harry Johnston" <harry[ at ]scms.waikato.ac.nz> wrote in message
news:%23uB4O3ouHHA.536[ at ]TK2MSFTNGP06.phx.gbl...
[Quoted Text] > Matt Watson wrote:
>
>> I have a very similar issue. I also work at an Educational institution
>> and have a narrow window in which to install updates. The reason for this
>> window is slightly different as 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.
>
> I suggest you turn off scheduled installation and instead run a script to
> download and install updates from WSUS as part of the overnight process;
> this should give you more control over the process.
The only down-side to this solution that I see is the possibility that with
X number of machines all hitting the WSUS server simultaneously, you may not
successfully get all content downloaded and installed in a 75 minute window.
Of course, alternate solutions involve extending the window and/or
staggering the windows across the several machines affected.
--
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
.....
|
|
|