Dave Wright" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
Can you give me some background on the interrelationships here?
Are you the primary WSUS Administrator? Do you not have access to the WSUS
I'm really intrigued that you'd have to "request access" to these logs! :-/
Also, if access to the logs requires a special request -- we may have
significant issues performing diagnostics and testing trying to identify the
cause of this issue. (And you allude to this by indicating how "locked down"
this server is.)
It might not have been deleted. It could also be the victim of an ACL
change, a filesystem move, or other *controlled* activities which result in
a change being made that functionally hides the file from the Update
Services service. It might have been moved into a tree that's causing an
invalid ACL inheritance. If that server really is locked down as tight as it
seems, then it should be trivial for that System Administrator to identify
when that file first appeared on the server and when it "disappeared" (or
where it actually is at this moment).
That would definitely be a proxy issue, I'd think. The proxy may not be
properly assuming a default port of 80; or may be appending the wrong port
number onto the URL as it passed it through. Basic point, though, the HTTP
specification says all HTTP listeners should respond on port 80 if/when the
port number is not specified, so if the proxy is messing with that -- it's
either a misconfiguration of the proxy server, or the proxy server is not
fully protocol compliant.
If it's not causing any problems now, and removing it does, then I'd say
leave it alone. I can't say that I remember any direct issues caused by the
suffix, but I do know there's a reason I started recommending removing the
:80 suffix. I probably should review my Sent Items archive and see if I can
refresh my memory on why I started doing that.
Well.. maybe you have a good reason here -- it has a dysfunctional WUAgent
and cannot be maintained in a 'secure' state. ;-)
There was an issue a few weeks (months? time runs all together these days)
ago, where the WUAgent was "seeing" updates that weren't suppose to be seen.
A 'fix' for that issue was supposed to be released, and once the issue was
acknowledged and we determined the issue was benign, I went on to other
issues. It may be that this is related to that 'bug', and it's not actually
been fixed (or you might not have the fix). Let me do some research on that
issue and see what came of it.
Make sure the server does not have any pending downloads, if the 'reset'
command creates new download requests, that they're actually executed.
That *could* be causing some miscommunication (and misreported status)
between the two systems.
AHHH!!!... Something you need to be aware of. It's a natural behavior of
Group Policy. Moving a machine out of the "WSUS" OU, and into an 'SCCM" OU
will *not* deactivate the WSUS configuration, unless the policy settings
have been explicitly disabled (or modified) by the "SCCM" OU. I would
suggest verifying that all of the policy differentials between those two OUs
are being handled as expected.
It's really two different client-side scenarios, and is also dependent upon
whether WSUS is being used as the SUP for SCCM. I'm still learning the
SCCM/WSUS scenario, so