# Issues getting Windows 7 PC to show in WSUS



## paulr24 (Mar 24, 2007)

I installed WSUS version 3.2.7600.226 on Windows Server 2003 SBS SP2 per a guide from Microsoft and I am having issues getting a Windows 7 64 bit client to show in the list of computers in WSUS on the server. I have only been able to try this with the one Windows 7 client so far, and will be trying it with other computers as soon as I have a chance when they aren't being used.

When I go to Windows Update and click the button to download updates, it gives an error of "code 80244019: Windows Update encountered an unknown error."

This is what I found in my WindowsUpdate.log:

2011-10-20	14:19:30:103 992	158c	AU	Triggering AU detection through DetectNow API
2011-10-20	14:19:30:103 992	158c	AU	Triggering Online detection (interactive)
2011-10-20	14:19:30:113 992	141c	AU	#############
2011-10-20	14:19:30:113 992	141c	AU	## START ## AU: Search for updates
2011-10-20	14:19:30:113 992	141c	AU	#########
2011-10-20	14:19:30:123 992	141c	AU	<<## SUBMITTED ## AU: Search for updates [CallId = {E355AAFE-F076-4F38-B299-3F6280835640}]
2011-10-20	14:19:30:123 992	14b0	Agent	*************
2011-10-20	14:19:30:123 992	14b0	Agent	** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2011-10-20	14:19:30:123 992	14b0	Agent	*********
2011-10-20	14:19:30:123 992	14b0	Agent * Online = Yes; Ignore download priority = No
2011-10-20	14:19:30:123 992	14b0	Agent * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
2011-10-20	14:19:30:123 992	14b0	Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
2011-10-20	14:19:30:123 992	14b0	Agent * Search Scope = {Machine}
2011-10-20	14:19:30:173 992	14b0	Setup	Checking for agent SelfUpdate
2011-10-20	14:19:30:183 992	14b0	Setup	Client version: Core: 7.5.7601.17514 Aux: 7.5.7601.17514
2011-10-20	14:19:30:183 992	14b0	Misc	Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
2011-10-20	14:19:30:193 992	14b0	Misc Microsoft signed: Yes
2011-10-20	14:19:30:203 992	14b0	Misc	Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
2011-10-20	14:19:30:203 992	14b0	Misc Microsoft signed: Yes
2011-10-20	14:19:30:203 992	14b0	Misc	Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
2011-10-20	14:19:30:213 992	14b0	Misc Microsoft signed: Yes
2011-10-20	14:19:30:343 992	14b0	Misc	Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
2011-10-20	14:19:30:343 992	14b0	Misc Microsoft signed: Yes
2011-10-20	14:19:30:373 992	14b0	Setup	Determining whether a new setup handler needs to be downloaded
2011-10-20	14:19:30:373 992	14b0	Setup	SelfUpdate handler is not found. It will be downloaded
2011-10-20	14:19:30:373 992	14b0	Setup	Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.4.7600.226"
2011-10-20	14:19:31:153 992	14b0	Setup	Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~amd64~~7.4.7600.226" is not applicable
2011-10-20	14:19:31:153 992	14b0	Setup	Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.4.7600.226"
2011-10-20	14:19:31:163 992	14b0	Setup	Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~amd64~~7.4.7600.226" is not applicable
2011-10-20	14:19:31:173 992	14b0	Setup	Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.4.7600.226"
2011-10-20	14:19:31:183 992	14b0	Setup	Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~amd64~~7.4.7600.226" is not applicable
2011-10-20	14:19:31:183 992	14b0	Setup	SelfUpdate check completed. SelfUpdate is NOT required.
2011-10-20	14:19:31:233 992	14b0	PT	+++++++++++ PT: Synchronizing server updates +++++++++++
2011-10-20	14:19:31:233 992	14b0	PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://FQDN/ClientWebService/client.asmx
2011-10-20	14:19:31:233 992	14b0	PT	WARNING: GetConfig failure, error = 0x80244019, soap client error = 10, soap error code = 0, HTTP status code = 404
2011-10-20	14:19:31:233 992	14b0	PT	WARNING: PTError: 0x80244019
2011-10-20	14:19:31:233 992	14b0	PT	WARNING:GetConfig_WithRecovery failed: 0x80244019
2011-10-20	14:19:31:233 992	14b0	PT	WARNING: RefreshConfig failed: 0x80244019
2011-10-20	14:19:31:233 992	14b0	PT	WARNING: RefreshPTState failed: 0x80244019
2011-10-20	14:19:31:233 992	14b0	PT	WARNING: Sync of Updates: 0x80244019
2011-10-20	14:19:31:233 992	14b0	PT	WARNING: SyncServerUpdatesInternal failed: 0x80244019
2011-10-20	14:19:31:233 992	14b0	Agent * WARNING: Failed to synchronize, error = 0x80244019
2011-10-20	14:19:31:233 992	14b0	Agent * WARNING: Exit code = 0x80244019
2011-10-20	14:19:31:233 992	14b0	Agent	*********
2011-10-20	14:19:31:233 992	14b0	Agent	** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2011-10-20	14:19:31:233 992	14b0	Agent	*************
2011-10-20	14:19:31:233 992	14b0	Agent	WARNING: WU client failed Searching for update with error 0x80244019
2011-10-20	14:19:31:243 992	16d0	AU	>>## RESUMED ## AU: Search for updates [CallId = {E355AAFE-F076-4F38-B299-3F6280835640}]
2011-10-20	14:19:31:243 992	16d0	AU # WARNING: Search callback failed, result = 0x80244019
2011-10-20	14:19:31:243 992	16d0	AU # WARNING: Failed to find updates with error code 80244019
2011-10-20	14:19:31:243 992	16d0	AU	#########
2011-10-20	14:19:31:243 992	16d0	AU	## END ## AU: Search for updates [CallId = {E355AAFE-F076-4F38-B299-3F6280835640}]
2011-10-20	14:19:31:243 992	16d0	AU	#############
2011-10-20	14:19:31:243 992	16d0	AU	Successfully wrote event for AU health state:0
2011-10-20	14:19:31:243 992	16d0	AU	AU setting next detection timeout to 2011-10-20 23:19:31
2011-10-20	14:19:31:243 992	16d0	AU	Successfully wrote event for AU health state:0
2011-10-20	14:19:31:243 992	16d0	AU	Successfully wrote event for AU health state:0

Anyone have any ideas? Thanks in advance!


----------



## mvirata (Feb 17, 2011)

I actually just built a WSUS 3.0 SP2 on a Windows 2008 Standard server on Monday. My Win 7 x64 clients are showing up fine. Did you use a Computer Configuration GPO to point to your WSUS server?


----------



## Rockn (Jul 29, 2001)

I am having issues with the sysinternals utility Psloggedin identifying Windows 7 computers as well. I thin the utility issue is with not being able to read the current user key in the remote registry. Maybe WSUS is having the same issue.


----------



## mvirata (Feb 17, 2011)

Rockn, I got my psloggedon to work on win7 x64 bit machines. I thought maybe I needed to run the command prompt as administrator, but it worked even without it.

Paulr24, Actually I found my first win7 x64 machine that does not connect to our WSUS. I tried to access the hidden share \\comptuername\c$ and it did not work. This machine has got to have some elevated security. See if you can access the hidden share, and while you are at it, see if you can manage it remotely. (right click computer > manage > right click computer management > Connect to another comptuer....)

I'm going to stop by this users machine in a bit to check the networks settings. It pings so network discover is on, but I would bet file and printer sharing is off. I would think this might be necessary for WSUS. I'll let you know what the end result is.


----------



## paulr24 (Mar 24, 2007)

mvirata, I am able to access \\comptuername\c$, I can also manage it remotely, and file and printing sharing is enabled. I did use a computer configuration GPO to point to the server (Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location). 

One thing that I should add is that when I tried to refresh the group policy using the "gpudate /force" command it failed, so I checked the C:\Windows\SYSVOL\domain\Policies folder and the folder for that policy did not exist. I didn't understand why it wasn't there, so I ended up setting up another policy that was identical to the one that had the folder missing, then just created a folder for the policy that's folder did not exist and copied the contents from the new one into it so I could get around the error. Not sure if this may have something to do with the server not seeing the client, but I thought I should put it out there in case what I did was something that could have messed things up further.


----------



## Rockn (Jul 29, 2001)

Did you check for the sysvol directory on the server or the workstation? It is never on a workstation, but should be accessible from any workstation on the domain controller. Go to the search bar and enter \\servername\sysvol

You should have access. GPUPDATE can fail for any number of reasons.


----------



## paulr24 (Mar 24, 2007)

Rockn said:


> Did you check for the sysvol directory on the server or the workstation? It is never on a workstation, but should be accessible from any workstation on the domain controller. Go to the search bar and enter \\servername\sysvol
> 
> You should have access. GPUPDATE can fail for any number of reasons.


I checked it on the server. I forget what the exact error message was but it basically said that there was a file it was looking for under a policy ID that is in the sysvol folder that wasn't there for some reason. Once I created the folder and copied the files that belong inside it from a different policy the gpupdate command succeeded, but the client still doesn't show on the server in WSUS.


----------



## mvirata (Feb 17, 2011)

When you do a gpresult, is your gpo being applied? For windows 7 you have to open your command prompt as administrator, and the command is:

gpresult /r

My output looks like this



> Applied Group Policy Objects
> -----------------------------
> Default Domain Policy
> WSUS_GPO


----------



## paulr24 (Mar 24, 2007)

When I run "gpresult /r" I get this, which is correct:

Applied Group Policy Objects
-----------------------------
Default Domain Policy
Windows Server Update Services


----------



## mvirata (Feb 17, 2011)

Well that one machine that I was having trouble with, is still not working. He had File and Printer Sharing off and I turned it on but that didn't help. Out of 5 Win7 x64 workstation, only one is not working. I'll let you know if I come across anything.


----------



## paulr24 (Mar 24, 2007)

Thanks a lot for trying to help me fix this. I actually was having an issue were I was trying to check for new Windows updates on a different server and it was hanging, and I got this error: 

"Windows could not search for new updates. Error(s) found: Code 80244019." 

I was searching through some forums looking for a fix for it, and I ended up coming across someone who said to try this:

1.Run mmc->File->Add/Remove Snap-in->Find "Group Policy Object Editor"->Add->Local machine->Finish->OK

2.Set the Computer Configuration->Administrative Templates->Windows Components->Windows Update "specify intranet Microsoft update service location" as not configured.

It resolved the issue and Windows Update stopped hanging. I then ran the "gpupdate /force" command from the Windows 7 client and it showed up in WSUS.


----------



## mvirata (Feb 17, 2011)

This sort of strengthens my theory that you might have a GPO problem. If you manually change the local GPO on the client, then you are manually adding your wsus server. Your WSUS GPO should already contain this setting. In reality you are not going to change every single local GPO for every single Windows 7 workstation you have. That is the whole point of GPOs right?

Your WSUS GPO should contain this setting (I'll change the company to MyCompany) so you don't need to fuss with the local GPO.

Specify intranet Microsoft update service location Enabled 
Set the intranet update service for detecting updates: http://wsus.mycompany.com 
Set the intranet statistics server: http://wsus.mycompany.com
(example: http://IntranetUpd01)

I was under the impression this was already set. If it is set this way and your Windows 7 boxes are not getting the GPO, because you manually added it to the local policy, it tells me your WSUS server is fine but your Windows 7 machine is not applying the GPO. In your past posts you aren't showing any errors so from my standpoint it seems like you don't have the setting.

Sure it will work now but if you deploy 100 of these guys, then get ready to change 100 local policies or script out a registry change. You might want to dig around a little more. Good luck!


----------



## paulr24 (Mar 24, 2007)

I actually did set up my WSUS GPO that way. I'm not sure why the Windows 7 machine didn't apply the GPO either. I still haven't gotten around to checking some non-Windows 7 computers, so I'll try that and see what happens.


----------

