I'm Rob Marshall, a consultant who specialises in the Microsoft System Center Configuration Manager product. I like to share, i do so by blogging and helping out when I can in the MS SMS newsgroups and participating in the ConfigMgr MVP program.
I was awarded and joined the program in 2009. It'd be an understatement to say it has to be one of the best experiences an IT engineer can have, if they really enjoy specialising in a product.
My biggest weapon for troubleshooting is, my formidable knowledge, no, only joking, you, the community. I find if I cannot answer a question, then I can usually find the answer from using Bing\Google, pouring over the documentation, and if that doesn't work, tinkering in mine or someone elses virtual lab.
The blogs pretty much about ConfigMgr, but it is also a platform for me to express my random urges to display something I've stumbled across, and that I imagine would entertain you or what not as equally as it did me.
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
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.