> Looks like most of my problems are due to the anonymous access issue on the
> virtual directories. Most clients are now reporting connections to the wsus
> server and I have turned the SUS site back on. I still have a few
> workstations and one server that is stating it has not communicated yet, not
> sure why but will try to figure it out.
> Have you guys ever ran the WSUS server cleanup wizard before to remove old
> updates and such, does it work?
>
> Thanks for the respones
>
> "Lawrence Garvin (MVP)" wrote:
>
> > "kcramman" <kcramman[ at ]discussions.microsoft.com> wrote in message
> > news:19FF12AC-6AAD-47C4-AA5C-9B32D57D745A[ at ]microsoft.com...
> > > My server clients and XP clients are not reporting in after upgrade.
> > > Should
> > > the SUS web site be stopped after the upgrade?
> >
> > [a] WSUS 3 cannot be installed on a machine with SUS 1.0 still installed, so
> > probably we should first confirm that SUS is, or is not, still installed.
> >
> > [b] If SUS is still installed, and the Default Web Site is *stopped*, and
> > you were running WSUS 2.0 on port 80, and the upgrade forced WSUS 3.0 back
> > to port 8530 -- and the DWS is still *stopped* -- this will be problematic
> > for downlevel machines that have never used WSUS 2.0. It will be irrelevant
> > for active WSUS 2.0 clients.
> >
> > > Is it needed anymore?
> >
> > It's still "needed" in the sense that the WSUS 3.0 Health Monitoring
> > software expects to see a functional selfupdate site on port 80. If it's not
> > there the server complains.
> >
> > > It runs
> > > on port 80 and the WSUS administration is running on 8530. Do you need any
> > > logs to look at?
> >
> > Looking at the Client Diagnostic Tool you posted:
> >
> > >Checking Connection to WSUS/SUS Server
> > > WUServer =
http://xxxxx:8530> > > WUStatusServer =
http://xxxxxxx:8530> > > UseWuServer is enabled. . . . . . . . . . . . . . . . . PASS
> > >
> > >VerifyWUServerURL() failed with hr=0x800710dd
> >
> > It's been a really long time since I saw a 0x800710dd error. Generally it's
> > associated with a security flaw. On Windows XP systems it's sometimes
> > associated with a defective security descriptor. This command will repair
> > that on the WinXP machines, if that's the cause:
> >
> > SC sdset wuauserv
> > D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
> >
> >
> > The other cause has been traced to misconfigured group memberships and/or
> > permissions on the WSUS Server, which, in turn, can be caused by a number of
> > things. The most common are:
> > [a] Anonymous access is not properly enabled on the virtual server,
> > selfupdate, and clientwebservice virtual directories.
> > [b] Promoting an IIS machine to a DC; or demoting an IIS machine -- thus
> > breaking the IUSR_MACHINENAME account permissions and group memberships.
> > [c] The NTAUTHORITY\Authenticated Users group is not a member of the
> > BUILTIN\Users group.
> > [d] Trailing slashes on the configured URL which produce a defective
> > webpath to the desired resource.
> > [e] Disabling of administrative shares.
> >
> >
> >
> > --
> > Lawrence Garvin, M.S., MCTS, MCP
> > Independent WSUS Evangelist
> > MVP-Software Distribution (2005-2007)
> >
https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E> >
> > Everything you need for WSUS is at
> >
http://www.microsoft.com/wsus> >
> > And, almost everything else is at
> >
http://wsusinfo.onsitechsolutions.com> > .....
> >
> >
> >
> >