Scary Auto Updates issue with WSUS

This started off in general queries but I've since tracked it down to the
Autoupdates service. I have a user population of about 400 all of who
receive updates via WSUS. In the last few months I've started receiving
calls of users complaining of lack of network connectivity and sound issues.
On investigation, amongst others, their server service, workstation, windows
audio and browser services have stopped. Each time after a reboot the
services start, then after a minute or two, stop. If I disable their
Autoupdates service, the problem does not occur.

If I reenable the service, within two minutes the services stop but
interestingly, updates then appear, almost as if the BITS service has somehow
become 'blocked' whilst attempting to download updates and sunk the other
services. This 'fix' however is only temporary as the affected pcs repeat
the behaviour the next time updates are released.

As a further note all the PCs are set to reboot via GPO on the Sunday at 3am
follwoing the updates to complete the install of any outstanding updates. I
am a little worried that if a PC is switched off for the 3am reboot that it
may attempt to reboot when the PC is switched on, causing perhaps the
services to stop?

Anyway any help or pointers gratefully received.

Forwarded to microsoft.public.windows.server.update_services newsgroup via
crosspost.
--
~Robear Dyer (PA Bear)
MS MVP-Windows (IE, OE, Security, Shell/User)

Heckler1974 wrote:
> This started off in general queries but I've since tracked it down to the
> Autoupdates service. I have a user population of about 400 all of who
> receive updates via WSUS. In the last few months I've started receiving
> calls of users complaining of lack of network connectivity and sound
> issues.
> On investigation, amongst others, their server service, workstation,
> windows
> audio and browser services have stopped. Each time after a reboot the
> services start, then after a minute or two, stop. If I disable their
> Autoupdates service, the problem does not occur.
>
> If I reenable the service, within two minutes the services stop but
> interestingly, updates then appear, almost as if the BITS service has
> somehow become 'blocked' whilst attempting to download updates and sunk
> the
> other services. This 'fix' however is only temporary as the affected pcs
> repeat the behaviour the next time updates are released.
>
> As a further note all the PCs are set to reboot via GPO on the Sunday at
> 3am
> follwoing the updates to complete the install of any outstanding updates.
> I
> am a little worried that if a PC is switched off for the 3am reboot that
> it
> may attempt to reboot when the PC is switched on, causing perhaps the
> services to stop?
>
> Anyway any help or pointers gratefully received.

> Heckler1974 wrote:

Let's work with the easy question first....

>I am a little worried that if a PC is switched off for the 3am reboot that
>it may attempt to reboot when the PC is switched on, causing perhaps the
>services to stop?

You can prevent this from happening by disabling the policy setting
"Reschedule automatic updates scheduled installations". By default, this
policy when "Not Configured", will allow updates to be installed at the next
powerup following a missed scheduled installation. The delay time is one
minute. You can enable the policy and set the delay from 1 to 30 minutes.

Or, what you want -- you can disable the policy which will completely
prevent the installation of updates at a power on event.

WARNING: Since you are only doing WEEKLY scheduled installations, this
presents a risk factor. I would strongly encourage you to configure any
policy with this setting disabled to use DAILY scheduled installations.

> In the last few months I've started receiving calls of users complaining
> of lack of network connectivity and sound issues.

First... are you distributing driver updates via WSUS? If so, (and a bad
idea for several reasons I'll be happy to get into later), its' entirely
possible you've installed a defective driver to these systems.

>On investigation, amongst others, their server service, workstation,
>windows
>audio and browser services have stopped. Each time after a reboot the
>services start, then after a minute or two, stop. If I disable their
>Autoupdates service, the problem does not occur.

>If I reenable the service, within two minutes the services stop but
>interestingly, updates then appear, almost as if the BITS service has
>somehow become 'blocked' whilst attempting to download updates and sunk the
>other services. This 'fix' however is only temporary as the affected pcs
>repeat the behaviour the next time updates are released.

Most interesting. Check one of these systems and see what the Memory and CPU
consumpting of the svchost.exe process is during one of these situations. It
may be that you're simply experiencing and describing an issue we know
about, albeit in a different manner of explanation. (Most, if not all of
those services you're experiencing issue with run in the same SYSTEM
svchost.exe process as Automatic Updates.)

If you do identify the svchost.exe issue, it may be tied to a known issue
with the MSI.DLL -- see this KB article for more information and a hotfix:

http://support.microsoft.com/kb/916089


--
Lawrence Garvin, M.S., MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....

"Lawrence Garvin (MVP)" wrote:

> > Heckler1974 wrote:
>
> Let's work with the easy question first....
>
> >I am a little worried that if a PC is switched off for the 3am reboot that
> >it may attempt to reboot when the PC is switched on, causing perhaps the
> >services to stop?
>
> You can prevent this from happening by disabling the policy setting
> "Reschedule automatic updates scheduled installations". By default, this
> policy when "Not Configured", will allow updates to be installed at the next
> powerup following a missed scheduled installation. The delay time is one
> minute. You can enable the policy and set the delay from 1 to 30 minutes.
>
> Or, what you want -- you can disable the policy which will completely
> prevent the installation of updates at a power on event.
>
> WARNING: Since you are only doing WEEKLY scheduled installations, this
> presents a risk factor. I would strongly encourage you to configure any
> policy with this setting disabled to use DAILY scheduled installations.
>
> > In the last few months I've started receiving calls of users complaining
> > of lack of network connectivity and sound issues.
>
> First... are you distributing driver updates via WSUS? If so, (and a bad
> idea for several reasons I'll be happy to get into later), its' entirely
> possible you've installed a defective driver to these systems.
>
> >On investigation, amongst others, their server service, workstation,
> >windows
> >audio and browser services have stopped. Each time after a reboot the
> >services start, then after a minute or two, stop. If I disable their
> >Autoupdates service, the problem does not occur.
>
> >If I reenable the service, within two minutes the services stop but
> >interestingly, updates then appear, almost as if the BITS service has
> >somehow become 'blocked' whilst attempting to download updates and sunk the
> >other services. This 'fix' however is only temporary as the affected pcs
> >repeat the behaviour the next time updates are released.
>
> Most interesting. Check one of these systems and see what the Memory and CPU
> consumpting of the svchost.exe process is during one of these situations. It
> may be that you're simply experiencing and describing an issue we know
> about, albeit in a different manner of explanation. (Most, if not all of
> those services you're experiencing issue with run in the same SYSTEM
> svchost.exe process as Automatic Updates.)
>
> If you do identify the svchost.exe issue, it may be tied to a known issue
> with the MSI.DLL -- see this KB article for more information and a hotfix:
>
> http://support.microsoft.com/kb/916089
>
>
> --
> Lawrence Garvin, M.S., MVP-Software Distribution
> Everything you need for WSUS is at
> http://technet2.microsoft.com/window...s/default.mspx
> And, everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....


Okay:

1. I was aware of the mechanism for the reboots, I was more concerned that
the mechanism is 'misfiring' and attempting to shut the PC down on the
startup, this appears on reflection to be a spurious conclusion.

2.I have seen the 100% CPU utilisation on SVCHost associated with
Auto-Updates on the forums but until yesterday didn't associated it with our
issue (our problem doesn't present this symptom). However bizarely yesterday
I came across one doing exactly as you describe that I temporarily resolved
by disabling Auto Updates. I can only assume that the two issues are tied up
with SVCHOST and Auto Updates but are presenting as different symptoms.

3. Thanks for pointing me to the hotfix, I'm slightly disturbed that it
isn't a publically available hotfix but one that has to be 'applied for' to
Microsoft Support Services. If this is a known issue and this is indeed the
fix for it, why isn't it being pushed out via the updates?

"Heckler1974" wrote:

> 3. Thanks for pointing me to the hotfix, I'm slightly disturbed that it
> isn't a publically available hotfix but one that has to be 'applied for' to
> Microsoft Support Services. If this is a known issue and this is indeed the
> fix for it, why isn't it being pushed out via the updates?

Well unfortunately the fix for the Svchost problem whilst It may resolve the
100% CPU hogging problem didn't fix my services stopping problem.

"Heckler1974" <> wrote in message
newsE229998-DDC7-4B20-AD2F-...

> 3. Thanks for pointing me to the hotfix, I'm slightly disturbed that it
> isn't a publically available hotfix but one that has to be 'applied for'
> to
> Microsoft Support Services. If this is a known issue and this is indeed
> the
> fix for it, why isn't it being pushed out via the updates?

HOTFIXes have NEVER been "generally available", and have ALWAYS required a
telephone call to MSS (sic) (aka PSS, now known as CSS), but recently have
become available via email request using a web-based form on the CSS site.

The specific reason for the call or email is to register the recipients.
HOTFIXes have not been regression tested and DO have the possibility of
introducing new bugs or breaking existing features. It is for this specific
reason that Microsoft tracks ALL recipients of HOTFIXes. Until a HOTFIX has
been fully regression tested, it will not be made generally available.


--
Lawrence Garvin, M.S., MVP-Software Distribution
Everything you need for WSUS is at
http://technet2.microsoft.com/window...s/default.mspx
And, everything else is at
http://wsusinfo.onsitechsolutions.com
.....