Werbung: SecurityConsole.de verwaltet Ihre Computer mit Security Essentails aus der Cloud!
30 Tage kostenfrei testen und 20% Rabatt für Ihre Bestellung mit Promocode: WBF2685582
(Promocode gültig bis 31.12.2011)

Group:  English: Windows Server » microsoft.public.windows.server.update_services
Thread: WebServices Failures -WSUS 2.x to 3.x. Changing from 8530 back to

HTVi
TV Discussion Newsgroups

WebServices Failures -WSUS 2.x to 3.x. Changing from 8530 back to
Fred Luhm 6/21/2007 8:43:01 PM
Hello -
Our Windows Update Server originally started as SUS 1.x
We then upgraded to WSUS 2.x.. and then to WSUS 2.x SP1.

Last week, we upgraded to WSUS 3.x The upgrade had no problems.
But, we noticed that after the upgrade, the clients were no longer checking
the update server, and many event viewer logs showed errors for Windows
update, related to not finding the Update Server, etc.

I determined this issue was due to all the clients accessing the update
server via TCP Port 80. But, the upgrade had installed the WSUS 3.x under
the TCP Port 8530, (even though our old WSUS 2.x was running on Port 80.
I found that the original default IIS web site was still set to TCP 80, but
this site was disabled. A 2nd site existed, called WSUS Administration Site.
It used to be set to use TCP 80, but the upgrade changed it to use 8530.
So, here is what I did:

Changed the WSUS Admin Website TCP Port from 8530 to 80.
I then used the WSUSUtil program with the customwebsite parameter of
'False'. This confirmed the change to TCP 80.

Now, all the clients happily get the updates again, and are reporting status
from what I can tell. However, on the actual WSUS server event viewer
application log, I now have a continuous set of 5 errors. The errors began
after the port change.

The errors are that I have Web Services failures for all the main Virtual
Directories
ClientWebService - Web Services Failure
DssAuthWebService - Web Services Failure
ReportingWebService - Web Services Failure
ServerSyncWebService - Web Services Failure
SimpleAuthWebService - Web Services Failure

I can repeat this error every time I do a WSUSUtil healthcheck. Can anyone
tell me what other areas I have to fix, related to the TCP Port change from
8530 to 80, that are affecting these web services?
Thank you.

Re: WebServices Failures -WSUS 2.x to 3.x. Changing from 8530 back to
"Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 6/22/2007 4:47:44 AM
"Fred Luhm" <FredLuhm[ at ]discussions.microsoft.com> wrote in message
news:5BFEC10B-DA27-4C42-B567-78B7BA9DC2EB[ at ]microsoft.com...
[Quoted Text]
> Hello -
> Our Windows Update Server originally started as SUS 1.x
> We then upgraded to WSUS 2.x.. and then to WSUS 2.x SP1.
>
> Last week, we upgraded to WSUS 3.x The upgrade had no problems.
> But, we noticed that after the upgrade, the clients were no longer
> checking
> the update server, and many event viewer logs showed errors for Windows
> update, related to not finding the Update Server, etc.
>
> I determined this issue was due to all the clients accessing the update
> server via TCP Port 80. But, the upgrade had installed the WSUS 3.x under
> the TCP Port 8530,

Yep, yep, yep... this is a (now) known, but as of yet, not *documented*
issue, caused (quite honestly) by failing to follow the necessary
prerequisites in the WSUS 3.0 release notes, but also properly following the
incomplete SUS-to-WSUS Migration Guide.

I'm working with the WSUS team to try to get a permanent, documented
solution.

In the meantime, here's what happened.

[a] You upgraded from SUS 1.0 to WSUS 2.0. Remnants of SUS 1.0 were left
behind in the Default Web Site after the upgrade/migration to WSUS 2.0. Not
running the SUS uninstallation leaves these remnants in place. Running the
SUS uninstallation breaks the WSUS 2 installation (by removing the
/selfupdate virtual directory), which has to be manually repaired. (It's
this uninstallation of SUS and the required manual repair of /selfupdate
that is not documented.)

[b] WSUS 3.0 *CANNOT* be installed on a SUS 1.0 server.

[c] The WSUS 3.0 installer sees remnants of SUS 1.0 in the Default Web Site
(or in some other fashion determines that the DWS is not suitable for WSUS
3.0 installation), thus "converts" the WSUS 2.0 installation to WSUS 3.0 on
the alternate virtual server (port 8530), and, apparently (though I've not
yet tested this actual scenario for empirical results), fails to inform the
installation administrator that this change has taken place.

[d] Your existing policy still points to port 80 and WSUS 3.0 ain't there.


> I found that the original default IIS web site was still set to TCP 80,
> but
> this site was disabled. A 2nd site existed, called WSUS Administration
> Site.
> It used to be set to use TCP 80, but the upgrade changed it to use 8530.

Ahh.. yes... the natural outgrowth of the SUS-to-WSUS migration, and the
specific details omitted from the overview discussed above.

With SUS installed on the Default Web Site, WSUS 2.0 had to be installed to
the alternate virtual server (port 8530). But, then, the SUS-to-WSUS
migration guide instructs the installation admin to:
[a] STOP the Default Web Site (effectively disabling the SUS server
installation).
[b] Change the port number of the new alternate virtual server from port
80 to port 8530.

Sadly, and unfortunately, especially now in light of the limitations with
the WSUS 3.0 installation on former SUS 1.0 systems, this is problematic,
because the SUS-to-WSUS Migration Guide fails to instruct the WSUS admin on
how to properly =uninstall= SUS 1.0 after the migration is complete.

So, in this scenario, the WSUS 3.0 cannot find a usable Default Web Site on
port 80, so it assumes it has no other option: It installs WSUS 3.0 on the
alternate virtual server and reverts the port number to port 8530. And, as
noted, apparently doesn't properly inform the WSUS3 Admin of this radical
change in configuration.


> Changed the WSUS Admin Website TCP Port from 8530 to 80.
> I then used the WSUSUtil program with the customwebsite parameter of
> 'False'. This confirmed the change to TCP 80.

This is one way to repair the issue, but, as you are observing, not the most
successful.


> Now, all the clients happily get the updates again, and are reporting
> status
> from what I can tell. However, on the actual WSUS server event viewer
> application log, I now have a continuous set of 5 errors. The errors
> began
> after the port change.
>
> The errors are that I have Web Services failures for all the main Virtual
> Directories
> ClientWebService - Web Services Failure
> DssAuthWebService - Web Services Failure
> ReportingWebService - Web Services Failure
> ServerSyncWebService - Web Services Failure
> SimpleAuthWebService - Web Services Failure

Yep... because the Server Health monitoring subsystem of WSUS is still
trying to ping these resources on the port 8530 virtual server.


> I can repeat this error every time I do a WSUSUtil healthcheck. Can
> anyone
> tell me what other areas I have to fix, related to the TCP Port change
> from
> 8530 to 80, that are affecting these web services?

Here's the *correct* way to upgrade WSUS 2.0 to WSUS 3.0 in this scenario
(although, it's pretty worthless in hindsight from here).

[1] Uninstall WSUS 2.0, keeping the database and content.
[2] START the Default Website, temporarily reenabiling SUS 1.0, but making
it accessible to the uninstaller.
[3] UNINSTALL Software Update Services 1.0.
[4] Install WSUS 3.0, which will:
[a] Install WSUS 3.0 to the Default Web Site (now that SUS 1.0 has
been cleared out).
[b] Migrate the existing WSUS 2.0 WMSDE database to the Windows
Internal Database.
[c] Link to the existing content store.


From your scenario right now, with a dysfunctional, but installed, WSUS 3.0,
you should perform the same steps above, except that step [1] now becomes:
[1] Uninstall WSUS 3.0, keeping the database and content.

and step [4][b] will have already been performed, so the installer will
simply reattach to the already available WSSU3 database.

In the process of reinstalling WSUS 3.0, all of the health monitoring
configs will be reset to the correct virtual server.
--
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://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....


Re: WebServices Failures -WSUS 2.x to 3.x. Changing from 8530 bac
Fred Luhm 6/23/2007 1:19:05 AM
Thank you. Now that was a good, and thorough answer. I appreciate it.

So, your feelings are that the WSUS functionality is working properly,
except for just the Health monitoring function? If so, that's no so bad for
the moment I suppose. Do you know of any way to change the port that the
health monitor is looking at?

Otherwise, if I go the route of removal, and reload, since I already have
the 3.x running, is there much involved in reattaching the database, and the
existing configurations? Also, should I remove the 2nd website, and go back
to the default web site as TCP 80, etc.?


"Lawrence Garvin (MVP)" wrote:

[Quoted Text]
> "Fred Luhm" <FredLuhm[ at ]discussions.microsoft.com> wrote in message
> news:5BFEC10B-DA27-4C42-B567-78B7BA9DC2EB[ at ]microsoft.com...
> > Hello -
> > Our Windows Update Server originally started as SUS 1.x
> > We then upgraded to WSUS 2.x.. and then to WSUS 2.x SP1.
> >
> > Last week, we upgraded to WSUS 3.x The upgrade had no problems.
> > But, we noticed that after the upgrade, the clients were no longer
> > checking
> > the update server, and many event viewer logs showed errors for Windows
> > update, related to not finding the Update Server, etc.
> >
> > I determined this issue was due to all the clients accessing the update
> > server via TCP Port 80. But, the upgrade had installed the WSUS 3.x under
> > the TCP Port 8530,
>
> Yep, yep, yep... this is a (now) known, but as of yet, not *documented*
> issue, caused (quite honestly) by failing to follow the necessary
> prerequisites in the WSUS 3.0 release notes, but also properly following the
> incomplete SUS-to-WSUS Migration Guide.
>
> I'm working with the WSUS team to try to get a permanent, documented
> solution.
>
> In the meantime, here's what happened.
>
> [a] You upgraded from SUS 1.0 to WSUS 2.0. Remnants of SUS 1.0 were left
> behind in the Default Web Site after the upgrade/migration to WSUS 2.0. Not
> running the SUS uninstallation leaves these remnants in place. Running the
> SUS uninstallation breaks the WSUS 2 installation (by removing the
> /selfupdate virtual directory), which has to be manually repaired. (It's
> this uninstallation of SUS and the required manual repair of /selfupdate
> that is not documented.)
>
> [b] WSUS 3.0 *CANNOT* be installed on a SUS 1.0 server.
>
> [c] The WSUS 3.0 installer sees remnants of SUS 1.0 in the Default Web Site
> (or in some other fashion determines that the DWS is not suitable for WSUS
> 3.0 installation), thus "converts" the WSUS 2.0 installation to WSUS 3.0 on
> the alternate virtual server (port 8530), and, apparently (though I've not
> yet tested this actual scenario for empirical results), fails to inform the
> installation administrator that this change has taken place.
>
> [d] Your existing policy still points to port 80 and WSUS 3.0 ain't there.
>
>
> > I found that the original default IIS web site was still set to TCP 80,
> > but
> > this site was disabled. A 2nd site existed, called WSUS Administration
> > Site.
> > It used to be set to use TCP 80, but the upgrade changed it to use 8530.
>
> Ahh.. yes... the natural outgrowth of the SUS-to-WSUS migration, and the
> specific details omitted from the overview discussed above.
>
> With SUS installed on the Default Web Site, WSUS 2.0 had to be installed to
> the alternate virtual server (port 8530). But, then, the SUS-to-WSUS
> migration guide instructs the installation admin to:
> [a] STOP the Default Web Site (effectively disabling the SUS server
> installation).
> [b] Change the port number of the new alternate virtual server from port
> 80 to port 8530.
>
> Sadly, and unfortunately, especially now in light of the limitations with
> the WSUS 3.0 installation on former SUS 1.0 systems, this is problematic,
> because the SUS-to-WSUS Migration Guide fails to instruct the WSUS admin on
> how to properly =uninstall= SUS 1.0 after the migration is complete.
>
> So, in this scenario, the WSUS 3.0 cannot find a usable Default Web Site on
> port 80, so it assumes it has no other option: It installs WSUS 3.0 on the
> alternate virtual server and reverts the port number to port 8530. And, as
> noted, apparently doesn't properly inform the WSUS3 Admin of this radical
> change in configuration.
>
>
> > Changed the WSUS Admin Website TCP Port from 8530 to 80.
> > I then used the WSUSUtil program with the customwebsite parameter of
> > 'False'. This confirmed the change to TCP 80.
>
> This is one way to repair the issue, but, as you are observing, not the most
> successful.
>
>
> > Now, all the clients happily get the updates again, and are reporting
> > status
> > from what I can tell. However, on the actual WSUS server event viewer
> > application log, I now have a continuous set of 5 errors. The errors
> > began
> > after the port change.
> >
> > The errors are that I have Web Services failures for all the main Virtual
> > Directories
> > ClientWebService - Web Services Failure
> > DssAuthWebService - Web Services Failure
> > ReportingWebService - Web Services Failure
> > ServerSyncWebService - Web Services Failure
> > SimpleAuthWebService - Web Services Failure
>
> Yep... because the Server Health monitoring subsystem of WSUS is still
> trying to ping these resources on the port 8530 virtual server.
>
>
> > I can repeat this error every time I do a WSUSUtil healthcheck. Can
> > anyone
> > tell me what other areas I have to fix, related to the TCP Port change
> > from
> > 8530 to 80, that are affecting these web services?
>
> Here's the *correct* way to upgrade WSUS 2.0 to WSUS 3.0 in this scenario
> (although, it's pretty worthless in hindsight from here).
>
> [1] Uninstall WSUS 2.0, keeping the database and content.
> [2] START the Default Website, temporarily reenabiling SUS 1.0, but making
> it accessible to the uninstaller.
> [3] UNINSTALL Software Update Services 1.0.
> [4] Install WSUS 3.0, which will:
> [a] Install WSUS 3.0 to the Default Web Site (now that SUS 1.0 has
> been cleared out).
> [b] Migrate the existing WSUS 2.0 WMSDE database to the Windows
> Internal Database.
> [c] Link to the existing content store.
>
>
> From your scenario right now, with a dysfunctional, but installed, WSUS 3.0,
> you should perform the same steps above, except that step [1] now becomes:
> [1] Uninstall WSUS 3.0, keeping the database and content.
>
> and step [4][b] will have already been performed, so the installer will
> simply reattach to the already available WSSU3 database.
>
> In the process of reinstalling WSUS 3.0, all of the health monitoring
> configs will be reset to the correct virtual server.
> --
> 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://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx
>
> And, almost everything else is at
> http://wsusinfo.onsitechsolutions.com
> .....
>
>
>
Re: WebServices Failures -WSUS 2.x to 3.x. Changing from 8530 bac
"Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 6/23/2007 2:52:04 PM
"Fred Luhm" <FredLuhm[ at ]discussions.microsoft.com> wrote in message
news:E7A518AB-9484-4B14-89DD-4FA133F196AC[ at ]microsoft.com...

[Quoted Text]
> So, your feelings are that the WSUS functionality is working properly,
> except for just the Health monitoring function?

That appears to be the case, and I know of no reason why the remediation
steps you took would not provide a functioning WSUS environment, except for
health monitoring services.

> If so, that's no so bad for the moment I suppose.

I'm not entirely knowledgable about what downstream ramifications may or may
not exist as a result of logged dysfunctions by the health monitoring
system. (e.g. does it disable other functionality because it thinks
something 'upstream' is not working). I've not yet had time to dig into this
new feature of WSUS 3.0 in depth.

> Do you know of any way to change the port that the health monitor is
> looking at?

I do not, but I am looking into it. My gut feeling is that it's maintained
in the database.


> Otherwise, if I go the route of removal, and reload, since I already have
> the 3.x running, is there much involved in reattaching the database, and
> the
> existing configurations?

No, it's fully automatic and the installation utility takes case of
*everything*.

> Also, should I remove the 2nd website, and go back
> to the default web site as TCP 80, etc.?

That really depends. WSUS 2.0 originally installed on the alternate site
because SUS 1.0 was on the DWS, and the intent was to migrate data, so both
had to be running side-by-side.

The fundamental flaw comes in that the Migration Guide describes how to kill
off the Default Web Site and reset the alternate virtual server to port 80
(which was the easiest, albeit, in hindsight, not the best way to disable
SUS 1.0).

The procedure I outlined will actually cause WSUS 3.0 to be installed on the
Default Web Site, as the uninstall of WSUS 3.0 will remove the alternate
server, and the uninstall of SUS 1.0 will remove SUS 1.0 from the DWS,
leaving it fully available for the reinstallation of WSUS 3.0.



--
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://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx

And, almost everything else is at
http://wsusinfo.onsitechsolutions.com
.....



Home | Search | Terms | Imprint Contact
Newsgroups Reader - provided by WiredBox.Net
Suche nach Orten, Städten, Postleitzahlen, Vorwahlen, Kfz-Kennzeichen