I'm Robert Marshall, director and principle consultant at SMSMarshall Ltd, who's specialism is in the Microsoft System Center 2012 Configuration Manager product and all of its dependent products, covering all aspects from Architecture, Implementation, Migration to Break-Fix.
I've been in front of computers for over 30 years now, with my roots in programming 8 bit computers, I've taken an often exciting journey which has led to becoming an expert in an enterprise product. I consider my career as starting 17 years ago, when I began my first serious role as a deployment engineer. I've seen 8 bit through to 64 bit, the rise and refinement of the interface we take for granted now, the rise of the Internet from land-line based modem access for the few, to the powerful broadband connections we have today for the masses, I saw mobile phones come into existence, and I've seen Microsoft evolve from more than a handful of employees to the company it is now, while pretty much tinkering with every OS they have released, as well as seeing an industry that has evolved around those humble beginnings to become what we have today. I'm a keen technical puzzle solver, I love to solve gnarly problems around my area of specialism. And, I love to share when I have time. I hope you enjoy the blog.
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.