|
|
I have a WSUS 3.0 "Master" server installed on a Windows 2003 server.
I have several branches that I want to have their own WSUS servers and
be downstream / replica servers from this master server. The issue I'm
having is that some of the branches only have Windows 2000 servers..
Being that you can't install WSUS 3.0 on Windows 2000 I've had to
install WSUS 2.0.. The WSUS 2.0 server is showing up as a downstream
server when I connect to the console of my master 3.0 server but it's
mode is set as "unknown" and it's not providing any roll up status.
The 2.0 server is able to synchronize from the 3.0 server. When I try
to add the 2.0 server to the master 3.0 console I get "Cannot connect
to "SERVERNAME". The server may be using another port or different
Secure Sockets Layer setting."
I'm not using SSL and I'm using the default port 80.. Any ideas??
Thanks much!
|
|
On Oct 9, 9:03 am, tbird2340 <tbird2...[ at ]gmail.com> wrote:
[Quoted Text] > I have a WSUS 3.0 "Master" server installed on a Windows 2003 server.
> I have several branches that I want to have their own WSUS servers and
> be downstream / replica servers from this master server. The issue I'm
> having is that some of the branches only have Windows 2000 servers..
>
> Being that you can't install WSUS 3.0 on Windows 2000 I've had to
> install WSUS 2.0.. The WSUS 2.0 server is showing up as a downstream
> server when I connect to the console of my master 3.0 server but it's
> mode is set as "unknown" and it's not providing any roll up status.
>
> The 2.0 server is able to synchronize from the 3.0 server. When I try
> to add the 2.0 server to the master 3.0 console I get "Cannot connect
> to "SERVERNAME". The server may be using another port or different
> Secure Sockets Layer setting."
>
> I'm not using SSL and I'm using the default port 80.. Any ideas??
>
> Thanks much!
No one has any ideas?
|
|
"tbird2340" <tbird2340[ at ]gmail.com> wrote in message
news:7d4b4678-1fc0-4027-b152-6f4880d5064e[ at ]v13g2000pro.googlegroups.com...
On Oct 9, 9:03 am, tbird2340 <tbird2...[ at ]gmail.com> wrote:
[Quoted Text] > I have a WSUS 3.0 "Master" server installed on a Windows 2003 server.
> I have several branches that I want to have their own WSUS servers and
> be downstream / replica servers from this master server. The issue I'm
> having is that some of the branches only have Windows 2000 servers..
>
> Being that you can't install WSUS 3.0 on Windows 2000 I've had to
> install WSUS 2.0.. The WSUS 2.0 server is showing up as a downstream
> server when I connect to the console of my master 3.0 server but it's
> mode is set as "unknown" and it's not providing any roll up status.
>
> The 2.0 server is able to synchronize from the 3.0 server. When I try
> to add the 2.0 server to the master 3.0 console I get "Cannot connect
> to "SERVERNAME". The server may be using another port or different
> Secure Sockets Layer setting."
>
> I'm not using SSL and I'm using the default port 80.. Any ideas??
>
> Thanks much!
No one has any ideas?
I originally replied to this on 10/9, but apparently the Microsoft news
servers have relapsed into their state of unreliability where Vista/WinMail
and Communities-enabled is concerned. I've disabled the "Communities"
feature from my Vista/WinMail, and hopefully that will resolve the recent
issue with large number of my posts not appearing on the server.
Here is the text of that original reply from 10/9:
================================================
You've pretty much hit the limits of th[is] configuration.
1. WSUS 2.0 did not support native reporting rollup. That was an unsupported
'add-on' package as part of the "API Samples and Tools" kit for WSUS 2.0.
I'm not even sure if that package will actually talk to a WSUS 3.0 server.
2. WSUS 2.0 used a WEB-based interface, the MMC was introduced with WSUS
3.0, so you're not going to be able to manage the WSUS 2.0 servers from the
MMC.
My *best* and *strongest* recommendation is to make the investment to
upgrade those Windows 2000 servers to Windows 2003 -- or retire them
completely.
As for your remote WSUS servers, in general, unless you've got a large
number of clients with a very narrow pipe (i.e. < 5kb/sec of throughput per
device), or the remote sites are global and have different languages and/or
locales, my recommendation would be to abandon the idea of a remote WSUS
Server regardless of what platforms are available, and have those remote
clients synchronize from and report directly to your corporate WSUS 3.0
server.
Even if you had a Windows 2003 server to install WSUS 3.0 on at a remote
site, the headache of administering and managing a remote WSUS Server is not
worth the effort if it's not *needed* -- and the only times I can think of
when it would be *needed* is in the two mentioned circumstances -- an
inordinate number of clients on a narrow pipeline, or a remote site with a
different language/locale than the main office.
--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
|
|
Thanks for the reply.. So your saying you would have 750+ workstations
all pull updates from one WSUS server? That to me sounds like it would
cause a lot of issues, no? If a couple of 20-30 mb updates get
approved and then 750 clients are all trying to pull it around the
same time I would think the network would suffer. We have at least a
T1 to all our branches.
What is the headache? There really is no administering.. They are
downstream / replicas. They get all the approvals from the master and
rollup the reporting. (except the WSUS 2 servers - ARGH!).
I appreciate your advice and look forward to your reply.
Thanks
|
|
"tbird2340" <tbird2340[ at ]gmail.com> wrote in message
news:f7dc0e74-1bbd-481b-a6b4-250127d2ec2f[ at ]g17g2000prg.googlegroups.com...
[Quoted Text] > Thanks for the reply.. So your saying you would have 750+ workstations
> all pull updates from one WSUS server?
If you have 750 workstations on a pipe > 750 * 5kb/sec == 3.5mb/sec then
unequivocally I'd say Yes.
> That to me sounds like it would
> cause a lot of issues, no? If a couple of 20-30 mb updates get
> approved and then 750 clients are all trying to pull it around the
> same time I would think the network would suffer. We have at least a
> T1 to all our branches.
Well, first, the likelihood of a 20-30mb update is pretty thin. Even if one
did exist, you'd know about it long before you approved the update, because
you would have discovered the size of the update during testing.
Furthermore, I would hope you don't have 750 clients all in one target
group, so it would be relatively trivial to spread out that download across
the 750 clients by staging the group approvals.
Finaly, most significant, all 750 clients wouldn't be downloading at the
same time. They'd be downloading across a 22-hour period (at least) -- and,
ideally, over a *weekend*, not during business hours.
But still assuming your 30mb update...let's take a look at that: A 30mb
update across a 1.5mbit/sec connection takes about (30mb*8bits=240mbits)/1.5
= 160 seconds to complete, about 2.7 minutes. That's about 34 hours of
realtime to transport the content -- it's be a lot easier, though, if only
375 of them were doing it at a time, though. (375 [ at ]2.7 mins/ea is ~17
hours -- you'd actually have <100% bandwidth utilization on the T-1).
Working from the other direction, 2.7 minutes per transfer in 22 hours means
you'll saturate the T-1 at about 485 clients (assuming maximum throughput [ at ]
1.544mbit/sec). YMMV. Beyond 485 clients, they'll all still download, they
just won't get the full bandwidth available to them, and the download time
per PC will increase. How much it increases is a mathematical problem I'll
leave alone at the moment.
Now, given that scenario, were I to feel the need that installing a remote
WSUS Server is a GOOD decision (and there's definitely merit in doing so),
then I probably ought to be equally well prepared to install the *correct*
solution, which would be WSUS 3.0 on Windows Server 2003. There's absolutely
NO point in compromising one borderline scenario (substituting 100%
saturation for 34 hours of weekend time maybe once per year) with another
(trying to maintain an unsupported application [WSUS 2.0] on an unsupported
operating system [Windows 2000]).
The good news, though, is that the first solution costs significant less
money as it doesn't require hardware, hardware maintenance, or systems
administration on an unsupported, eight-year-old operating system -- at a
remote site.
Furthermore, the first scenario MIGHT happen... maybe a few times a year at
most, if it does... and is easily managable IF it does happen; the second
scenario is an every-month nightmare that will only continue to get worse as
time progresses -- until, ultimately, it forces you into the "correct
solution" anyway.
> What is the headache? There really is no administering.. They are
> downstream / replicas. They get all the approvals from the master and
> rollup the reporting. (except the WSUS 2 servers - ARGH!).
:-)))
Even if they were WSUS 3 replicas, don't kid yourself that the server, or
the service, is maintenance free.
[a] Replicas still require filesystem maintenance.
[b] Replicas still have databases, and database services.
[c] Unless you'd be interested in re-cloning an entire replica filesystem
across your T-1,
replicas also need backups.
--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
|
|
|