WSUS Client Error  0x80072efd

JustinMcAllister
JustinMcAllister used Ask the Experts™
on
Customer is recieveing following errors on all workstations trying to access local WSUS replica server.

WARNING: Send failed with hr = 80072efd.
WARNING: SendRequest failed with hr = 80072efd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
+ Last proxy send request failed with hr = 0x80072EFD, HTTP status code = 0
+ Caller provided credentials = No
+ Impersonate flags = 0
+ Possible authorization schemes used =
WARNING: GetAuthorizationCookie failure, error = 0x80072EFD, soap client error = 5, soap error code = 0, HTTP status code = 200
WARNING: Failed to initialize Simple Targeting Cookie: 0x80072efd
WARNING: PopulateAuthCookies failed: 0x80072efd
WARNING: RefreshCookie failed: 0x80072efd
WARNING: RefreshPTState failed: 0x80072efd
WARNING: PTError: 0x80072efd
WARNING: Reporter failed to upload events with hr = 80072efd.


-Verified ISA Firewall rule to ensure port 8530 and 8531 are allowed
-Verified DNS to ensure WSUS resolves to the wsus server.
-Verified GPO's to ensure they were accepting GPO that directs workstations to point to http://wsus:8530 for updates
-Performed wuauclt.exe /resetauthorization /detectnow; /detectnow /updatenow; and /reportnow commands from command prompt.
-Verified all WSUS folder permissions were set properly.

Customer reports no changes were made to system. This began affecting all clients on same day approx 3 weeks ago.

My next thoughts would be to modify the GPO to try and access the WSUS server via IP instead of DNS. Also possibly reinstall WUA on one of the workstations to see if this corrects the issue.

Anyone else have any recommendations for troubleshooting steps?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Professional Troublemaker^h^h^h^h^hshooter
Commented:
> -Verified DNS to ensure WSUS resolves to the wsus server.
[...]
> My next thoughts would be to modify the GPO to try and access the WSUS server via IP instead of DNS


If DNS is confirmed working, I'd advise against it.  But if you did try it, and it made a difference, it would say DNS wasn't working.

Confirm that you can access something like
http://wsus:8530/selfupdate/wuident.cab
You don't need to download or extract... just confirm that IIS makes the file available to you.  Confirm that WSUS is really using 8530.

Are you able to get into the WSUS console on the server?

What version of WSUS are you running?  I ask because it seems to me, there was a patch on workstations from a while ago (year+) which prevented workstations from talking to the WSUS server until the WSUS server was patched.  I'd perform a server cleanup within the console, and make certain you are patched to at least WSUS 3.0 sp2.  (And I think there are even post SP2 patches necessary to work with the latest clients.)

Author

Commented:
Razmus thanks for the response.

I had the user attempt to access the following and both failed. I then had the user replace wsus with the actual server IP address and this also failed which tells me its not a DNS issue.

http://wsus:8530/selfupdate/wuident.cab
http://wsus:8530/SimpleAuthWebService/SimpleAuth.asmx

We are able to access the update services console. Server version is 3.2.7600.226 Client wuaueng.dll is 7.4.7600.226.  I am aware of the issue were clients could not check into server KB2720211. This patch has been applied to the server. Normally when i see an issue with this patch I receive the following error code in windowsupdate.log 0x800B0001.

When Customer attempts to access http://wsus:8530 he is prompted for a username and password This to me sounds like permissions issue.

I did find the following from one of my manuals.

0x80072EFD-This error relates to WSUS configured with SSL. Validate the certificate chains
on the server and ensure the WSUS server’s certificate is trusted. Also, ensure FIPS-140
compliant algorithms are disabled on the WSUS server, as they do not appear to be supported by the WU clients.

I am going to have the customer perform the following.

1.In Control Panel, click Administrative Tools, and then double-click Local Security Policy.
2.In Local Security Settings, expand Local Policies, and then click Security Options.
3.Under Policy in the right pane, double-click System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing, and then click Disabled.

Please let me know if you have any additional ideas.

Author

Commented:
Customer verified FIPS was disabled.

I am now looking at possible IIS>Website>WSUS Administrator Directory security issue.
11/26 Forrester Webinar: Savings for Enterprise

How can your organization benefit from savings just by replacing your legacy backup solutions with Acronis' #CyberProtection? Join Forrester's Joe Branca and Ryan Davis from Acronis live as they explain how you can too.

Rich WeisslerProfessional Troublemaker^h^h^h^h^hshooter
Commented:
My first thought was that the certificate bound on the IIS server had expired, but all the links you've provided have been http rather than https, so I assume that wasn't it.  You should be able to check the binding on the website.  (Although in 2003, it'll just be looking at the certificate on the website under Directory Security -> View Certificate.)

Author

Commented:
Thanks for all the help. I am not sure of the exact solution but something that was done during this process corrected the issue after a reboot. I hate when this happens and I dont clearly know what the fix is incase it occurs again.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial