WSUS shield doesn't show, but "install updates and shut down" does

Mr. Bill

Limp Gawd
Joined
Mar 13, 2003
Messages
274
Hi all,

First off, I'm a sys-admin for a DoD testing lab. Our computers are hardened/locked down pretty well, and some things just don't work like they used to.

We are in a closed netowrk environment, and there is a WSUS server off-site that provides our updates.

Some of our computers, the later ones I've had to harden recently, don't show the "WSUS Shield" All they show is the "Install updates and shut down" option. Just to be clear though, my windows updates DO work, just don't get the update shield on the taskbar.

I'm 99% certian it's my fault. The only computers that do this are ones I've hardened lately, which means there's a change to my procedures (registry, group policy or security policy) that makes this happen. The problem is, I can't find WHAT I'm doing wrong.

Can anyone shed some light onto my issue? Thanks!
 
I'm facing a similar problem. However I also removed the "install updates and shutdown" option from being displayed. My updates are set to "download but let me choose when to install"

Since I also don't have the wsus shield, I have no way of forcing the updates to install.

I'd be interested to know where that GPO is that is in charge of displaying the shield.
 
If the user does not have proper permissions on the box, the option to install will not show up. Same thing with the GPO that the WSUS Admin set. Do you have access to that GPO? Although if it is only effecting you, that does not make sense. The GPO should re-apply any screwed up reg settings upon a logging back into the domain.
 
We aren't in a domain environment and all used accounts are administrator accounts.
 
User Config -> Admin Templates -> Windows Components -> Windows Update -> "Enable Windows Update Notifications" maybe?

The policy specifies which notifications may still be displayed to a user when the “Remove access to use all Windows Update features” policy is enabled. When both policies are enabled you can configure one of the following notification options:

0 = Do not show any notifications

This setting will remove all access to Windows Update features and no notifications will be shown.

1 = Show restart required notifications

This setting will show notifications about restarts that are required to complete an installation.

Note: If this policy is disabled or not configured then no notifications will be given to the user when the “Remove access to use all Windows Update features” policy is enabled. This policy has no effect if the “Remove access to use all Windows Update features” policy is disabled or not configured.
 
I've seen this before. Make sure that no other users are logged on to the box via RDP. Not sure if it's the same under XP, but on my 2003 boxes if a uses was logged in to the console and I logged in via RDP session to patch, I would never see the shield. I had to kick the user off the console, then it would pop up. If it doesn't, I think you can force it by c:\windows\system32\wuauclt.exe /updatenow.
 
I've seen this before. Make sure that no other users are logged on to the box via RDP. Not sure if it's the same under XP, but on my 2003 boxes if a uses was logged in to the console and I logged in via RDP session to patch, I would never see the shield. I had to kick the user off the console, then it would pop up. If it doesn't, I think you can force it by c:\windows\system32\wuauclt.exe /updatenow.

unless the government hacks their XP boxes to allow simultaneous logins, I don't think that would be the issue :p

since you can either be RDP'ed into the box, or logged on locally. Not both.
 
Which part of the DoD? DISA?

I guess I'm curious what exactly you did. Were you following a particular STIG? Assuming the automatic updates service is actually started, then I'd be checking the GPOs or worse... were there any manual registry key changes?
 
unless the government hacks their XP boxes to allow simultaneous logins, I don't think that would be the issue :p

since you can either be RDP'ed into the box, or logged on locally. Not both.

Right, but in this case it didn't matter - if a user with admin rights was on the console OR in an RDP session, disconnected or not, i t wouldn't show up as it was already prompting in the other admin session.

You're right in that XP won't allow multiple connections, but it does support multiple users logged on at a time. Only one can be active.

It can't hurt to check, unless users aren't logging in to the boxes via RDP.
 
I know this won't be too helpful, but there is another service that needs to be running to display that shield. I can't, for the life of me remember what it is, but I'll look it up when I get home.

Essentially, there is a user component that needs to be running, and if the service is stopped it can't instantiate it.

Check your c:\windows\windowsupdate.log for FATAL: CAUClienht::Launch Failed, if you see it that's probably what's going on. A good bit of googling would probably turn it up as well.
 
Which part of the DoD? DISA?

I guess I'm curious what exactly you did. Were you following a particular STIG? Assuming the automatic updates service is actually started, then I'd be checking the GPOs or worse... were there any manual registry key changes?

First, thanks for all the responses guys, I really appreciate it.

There are about 120 registry key changes made to the system. It's just a .reg file, but I use DISA's gold disk and eEye's retina to make the systems complaint to the bullshit requirements and put every modification into the .reg file.

I reallllllly wish I could publish the damn registry file, but I'm not allowed to :-(
 
It's probably the "Allow non-administrators to receive update notifications" GP setting. By default non-admins don't get the update shield popup. You should be able to set it with this reg key as well:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
DWORD - ElevateNonAdmins 1
 
bump - still having this issue and I have some time to figure it out :)

Anything I can post to give some ideas/help?
 
was it neither of the group policy settings that have been noted in this thread?

I read through the thread again, and did not see where you acknowledged those settings and replied with whether or not they were set.
 
was it neither of the group policy settings that have been noted in this thread?

I read through the thread again, and did not see where you acknowledged those settings and replied with whether or not they were set.

No, I have changed and verified the group policy settings a dozen times.

I looked at the windowsupdate.log file and found this error consistently right after each other:

Warning: GetUserTokenFromSessionID failed with 800704dd

Warning: AU found no suitable session to launch client in


I AM a local administrator.

I looked on another system with the same issue, and the same warning.

I looked on a system with a working AU Client and this warning did not exist.
 
Last edited:
Well after enough googling, I fixed it!!

There's a microsoft KB article on a semi-related subject, and here's the fix:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Notify\SensLogn]
"DLLName"="WlNotify.dll"
"Lock"="SensLockEvent"
"Logon"="SensLogonEvent"
"Logoff"="SensLogoffEvent"
"Safe"=dword:00000001
"MaxWait"=dword:00000258
"StartScreenSaver"="SensStartScreenSaverEvent"
"StopScreenSaver"="SensStopScreenSaverEvent"
"Startup"="SensStartupEvent"
"Shutdown"="SensShutdownEvent"
"StartShell"="SensStartShellEvent"
"PostShell"="SensPostShellEvent"
"Disconnect"="SensDisconnectEvent"
"Reconnect"="SensReconnectEvent"
"Unlock"="SensUnlockEvent"
"Impersonate"=dword:00000001
"Asynchronous"=dword:00000001


The computers had NONE of these entries.
 
interesting... will have to keep this in mind if I come across it.

something in your hardening process removing that for some reason?
 
Here's the KB article if anyone is interested, can't say I've ever seen this before, which is surprising considering how many weird WSUS problems I've dealt with over the years. :)
http://support.microsoft.com/?kbid=910341

I see this mentioned a lot in relation to malware/viruses, so probably not the best sign to find them missing.
 
Back
Top