ConfigMgr: SUP\WSUS communications failure

Came across an SMS Admin today with an interesting problem. He has WSUS\SUP + all the other gubbings all on the one box, nothing really out of the norm and yet he gets Status Message ID 6701 followed by 6703 exactly 5 minutes later (the timeout value) in his WSYNCMGR log when attempting to get WSUS to SYNC with Microsoft Updates. Really he should be seeing 6701 followed by 6704 (recalling from memory here!) and 6701 means that the Sync is initialising and 6704 that it is in progress.

Odd thing is, if you remove the FQDN for the Site server (role wizard) the problem disappears. I could have left it like that, but didn't want too as it's etched in stone that supplying an FQDN for the Site server is good working practice. Well, it is.

Anyway, I discovered that if you add the Site servers FQDN to the Site servers Internet Explorer Trust Sites then add the FQDN back in to the Site server, it all slots in to place and performs the Sync successfully.

Now am not too sure of the root cause here, this in my eyes is a work-around and as its not a documented step I'm assuming not that many of you are actually experiencing this issue. If you've seen this, getting this, this fixed it for you then let me know!

On the subject of SUP\WSUS i've seen some real funny (well not so funny, maybe strange is a better word!) things happening, nearly all of which has been related to a non-standard "environment". And then i've seen SUP\WSUS go on (install), sync and bring down updates without any hiccups.

If you are experiencing SUP\WSUS issues then go back to step 1, analyse your environment and try to determine what is putting SUP\WSUS nose out of joint, as the product does work, first time, even if you follow the instructions verbatim Big Smile

  • I could be caused by the IE Enhanced Security Configuration. Depending on your IE configuration, the Internet or Local Intranet options are too restrictive

  • Yeah it has to be that, and should be easy to reproduce. I'll tinker and see, if there is one, what setting causes this.

    I now think adding the FQDN in to trusted sites isn't a work-around, if you consider that if IE Enhanced Security is on and the settings that stop the SUP working may need to remain in-place to obey corporate policy.