|
|
we have 1 main WSUS server and 5 replica WSUS servers in branchs. we have set
up net masking and round robin, which is working, but the issue is the
clients are showing up in correct WSUS server according to subnet but also
they keep reappearing in the main server. I delete them out and a few days
later they show up again in the unassigned group again. doesd anyone have any
ideas on this?
cheers
AM
|
|
"AM" <AM[ at ]discussions.microsoft.com> wrote in message
news:57598CC9-0D39-45BA-983B-15E39F025AF8[ at ]microsoft.com...
[Quoted Text] > we have 1 main WSUS server and 5 replica WSUS servers in branchs. we have
> set
> up net masking and round robin, which is working, but the issue is the
> clients are showing up in correct WSUS server according to subnet but also
> they keep reappearing in the main server. I delete them out and a few days
> later they show up again in the unassigned group again. doesd anyone have
> any
> ideas on this?
How many branches do you have? How many IP Subnets?
One of the issues with netmasking is that the only time you're guaranteed to
get the same server is when the server and the (DNS) client are on the same
IP subnet.
If you have remote sites on IP Subnets that do not have local WSUS Servers,
then the IP Address returned from the DNS query will be random, and would
account for clients appearing in the main server.
The other possibility is that you have conflicting policies and the URL of
the WSUS Server is flip-flopping between the remote name and the main server
name. If this is the case, you'll be able to see these URL changes logged in
the %windir%\WindowsUpdate.log file.
--
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
|
|
Lawrence,
will take at look at those logs. but each branch has its own subnet and WSUS
server.
the main server was teh WSUS server for everyone before but then we rolled
out the replica servers in each branch.
cheers
AM
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "AM" <AM[ at ]discussions.microsoft.com> wrote in message > news:57598CC9-0D39-45BA-983B-15E39F025AF8[ at ]microsoft.com... > > we have 1 main WSUS server and 5 replica WSUS servers in branchs. we have > > set > > up net masking and round robin, which is working, but the issue is the > > clients are showing up in correct WSUS server according to subnet but also > > they keep reappearing in the main server. I delete them out and a few days > > later they show up again in the unassigned group again. doesd anyone have > > any > > ideas on this? > > How many branches do you have? How many IP Subnets? > > One of the issues with netmasking is that the only time you're guaranteed to > get the same server is when the server and the (DNS) client are on the same > IP subnet. > > If you have remote sites on IP Subnets that do not have local WSUS Servers, > then the IP Address returned from the DNS query will be random, and would > account for clients appearing in the main server. > > The other possibility is that you have conflicting policies and the URL of > the WSUS Server is flip-flopping between the remote name and the main server > name. If this is the case, you'll be able to see these URL changes logged in > the %windir%\WindowsUpdate.log file. > > > > -- > 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> > |
|
"AM" <AM[ at ]discussions.microsoft.com> wrote in message
news:A054F941-5BFD-4D96-84CC-F54B7DA20606[ at ]microsoft.com...
[Quoted Text] > Lawrence,
> will take at look at those logs. but each branch has its own subnet and
> WSUS
> server.
> the main server was teh WSUS server for everyone before but then we rolled
> out the replica servers in each branch.
Hmmm. given that... I would also verify that those clients actually did get
the correct policy applied,
and that there aren't any duplicate policy objects defined that would be
providing conflicting URLs.
In this instance two likely possibilities would be an OU GPO and a SITE GPO
conflicting,
or a Domain GPO (originally used when there was one server) and the newer
SITE/OU GPOs.
--
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
|
|
Hay Lawerence,
have been all over the GPO's and its not that. i will say the main server
used to be the only WSUS server for all branchs, then we added remote servers
to each branch, do you think this might have soemthing to do with it? maybe
they are in its database somewhere or teh clients database? i delete them all
out and sure enough the next day they are back in there, not every client
though just some.
cheers
AM
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "AM" <AM[ at ]discussions.microsoft.com> wrote in message > news:A054F941-5BFD-4D96-84CC-F54B7DA20606[ at ]microsoft.com... > > Lawrence, > > will take at look at those logs. but each branch has its own subnet and > > WSUS > > server. > > the main server was teh WSUS server for everyone before but then we rolled > > out the replica servers in each branch. > > Hmmm. given that... I would also verify that those clients actually did get > the correct policy applied, > and that there aren't any duplicate policy objects defined that would be > providing conflicting URLs. > > In this instance two likely possibilities would be an OU GPO and a SITE GPO > conflicting, > or a Domain GPO (originally used when there was one server) and the newer > SITE/OU GPOs. > > -- > 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> > |
|
"AM" <AM[ at ]discussions.microsoft.com> wrote in message
news:90FA6753-7BFF-4084-9F75-844A199F5F17[ at ]microsoft.com...
[Quoted Text] > Hay Lawerence,
>
> have been all over the GPO's and its not that. i will say the main server
> used to be the only WSUS server for all branchs, then we added remote
> servers
> to each branch, do you think this might have soemthing to do with it?
> maybe
> they are in its database somewhere or teh clients database? i delete them
> all
> out and sure enough the next day they are back in there, not every client
> though just some.
The presence of clients reappearing in the master server are explained by
one simple fact.
Somehow those clients are getting the master server's URL set in their
policy.
How this is happening is the issue to be investigated and remediated.
The most likely cause of this, despite what you've (not) found in your
reviews, is an errant policy configuration.
However, this could also be caused by an errant =DNS= configuration. If the
client has the correct URL, but that hostname is returning the wrong IP
Address (the IP Address of the master server), the master server *will*
service the client if your master server is not configured to use host
headers.
(i.e. a WSUS Server will service any client requesting resources from
http://*/clientwebservice/client.asmx if the webserver is configured to
listen on All IP Addresses and no specific host header. WSUS does not check
the IP Address or hostname/FQDN contained in the HTTP request.)
In either event, running the Client Diagnostic Tool should give you
sufficient information to isolate the issue and cause.
The %windir%\WindowsUpdate.log may also contain sufficient information, but
it's much easier to get from the CDT.
--
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
|
|
Hay Lawerance,
all good stuff, but maybe we are doing somthing wrong in our net masking? in
the DNS we have A records for each WSUS server ie wsus.domain.com.au
192.168.4.100 wsus.domain.com.au 192.168.5.100 etc for each subnet.
we have 1 GPO for the whole domain that says go to wsus.domian.com.au for
your updates and round robin is ticked
are we doing it right?
do we have to set up host headers for on each wsus server for WSUS?
is this how you would do it?
we dont really want a GPO for each branch because user move to differnet
branchs with there laptops to work and attend meetings once or twice a month.
cheers
AM
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "AM" <AM[ at ]discussions.microsoft.com> wrote in message > news:90FA6753-7BFF-4084-9F75-844A199F5F17[ at ]microsoft.com... > > Hay Lawerence, > > > > have been all over the GPO's and its not that. i will say the main server > > used to be the only WSUS server for all branchs, then we added remote > > servers > > to each branch, do you think this might have soemthing to do with it? > > maybe > > they are in its database somewhere or teh clients database? i delete them > > all > > out and sure enough the next day they are back in there, not every client > > though just some. > > The presence of clients reappearing in the master server are explained by > one simple fact. > > Somehow those clients are getting the master server's URL set in their > policy. > > How this is happening is the issue to be investigated and remediated. > > The most likely cause of this, despite what you've (not) found in your > reviews, is an errant policy configuration. > > However, this could also be caused by an errant =DNS= configuration. If the > client has the correct URL, but that hostname is returning the wrong IP > Address (the IP Address of the master server), the master server *will* > service the client if your master server is not configured to use host > headers. > > (i.e. a WSUS Server will service any client requesting resources from > http://*/clientwebservice/client.asmx if the webserver is configured to > listen on All IP Addresses and no specific host header. WSUS does not check > the IP Address or hostname/FQDN contained in the HTTP request.) > > In either event, running the Client Diagnostic Tool should give you > sufficient information to isolate the issue and cause. > The %windir%\WindowsUpdate.log may also contain sufficient information, but > it's much easier to get from the CDT. > > -- > 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> > |
|
"AM" <AM[ at ]discussions.microsoft.com> wrote in message
news:3CC57636-4771-41BE-86C2-5546F1D2DFAC[ at ]microsoft.com...
[Quoted Text] > Hay Lawerance,
>
> all good stuff, but maybe we are doing somthing wrong in our net masking?
> in
> the DNS we have A records for each WSUS server ie wsus.domain.com.au
> 192.168.4.100 wsus.domain.com.au 192.168.5.100 etc for each subnet.
> we have 1 GPO for the whole domain that says go to wsus.domian.com.au for
> your updates and round robin is ticked
> are we doing it right?
That's a valid configuration. Have you verified that all clients are
properly (and always) picking up the correct IP Address?
> do we have to set up host headers for on each wsus server for WSUS?
No.
> is this how you would do it?
It's the simplest way, provided that you do have a WSUS Server in *every*
configured subnet.
> we dont really want a GPO for each branch because user move to differnet
> branchs with there laptops to work and attend meetings once or twice a
> month.
Which is exactly the right reason to be using round-robin/netmasking. :-)
Although, one might argue that "..once or twice a month.." is not likely to
significantly impact the maintenance of those mobile PCs (any more than
they're taken home and powered off every weekend).
The key is to verify that those clients appearing on the master server are
continually obtaining the correct *local* IP Address from DNS.
--
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
|
|
well thats the problemthe clients are geeting the correct ip address MOST of
teh tiem but everynow and then, and teh clients chnage as well, they get the
mian wsus server, so they are not continually obtaining the correct wsus
address.
the clients them selfs are getting there ip address correct.
AM
"Lawrence Garvin (MVP)" wrote:
[Quoted Text] > "AM" <AM[ at ]discussions.microsoft.com> wrote in message > news:3CC57636-4771-41BE-86C2-5546F1D2DFAC[ at ]microsoft.com... > > Hay Lawerance, > > > > all good stuff, but maybe we are doing somthing wrong in our net masking? > > in > > the DNS we have A records for each WSUS server ie wsus.domain.com.au > > 192.168.4.100 wsus.domain.com.au 192.168.5.100 etc for each subnet. > > we have 1 GPO for the whole domain that says go to wsus.domian.com.au for > > your updates and round robin is ticked > > are we doing it right? > > That's a valid configuration. Have you verified that all clients are > properly (and always) picking up the correct IP Address? > > > do we have to set up host headers for on each wsus server for WSUS? > > No. > > > is this how you would do it? > > It's the simplest way, provided that you do have a WSUS Server in *every* > configured subnet. > > > we dont really want a GPO for each branch because user move to differnet > > branchs with there laptops to work and attend meetings once or twice a > > month. > > Which is exactly the right reason to be using round-robin/netmasking. :-) > > > Although, one might argue that "..once or twice a month.." is not likely to > significantly impact the maintenance of those mobile PCs (any more than > they're taken home and powered off every weekend). > > The key is to verify that those clients appearing on the master server are > continually obtaining the correct *local* IP Address from DNS. > > > -- > 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> > |
|
"AM" <AM[ at ]discussions.microsoft.com> wrote in message
news:6F73269D-4A4F-4697-868E-C9BA66422AFF[ at ]microsoft.com...
[Quoted Text] >> The key is to verify that those clients appearing on the master server
>> are
>> continually obtaining the correct *local* IP Address from DNS.
> well thats the problemthe clients are geeting the correct ip address MOST
> of
> teh tiem but everynow and then, and teh clients chnage as well, they get
> the
> mian wsus server, so they are not continually obtaining the correct wsus
> address.
> the clients them selfs are getting there ip address correct.
Then either you have something misconfigured in your DNS
RoundRobin/Netmasking,
or you have a subnet that does not have a WSUS Server on that subnet
(configured in DNS).
This could also happen if you've misconfigured an A record for one of the
replica WSUS Servers.
--
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
|
|
On Fri, 21 Nov 2008 00:00:33 -0600, "Lawrence Garvin \(MVP\)"
<lawrence[ at ]news.postalias> wrote:
[Quoted Text] >"AM" <AM[ at ]discussions.microsoft.com> wrote in message
>news:6F73269D-4A4F-4697-868E-C9BA66422AFF[ at ]microsoft.com...
>
>>> The key is to verify that those clients appearing on the master server
>>> are
>>> continually obtaining the correct *local* IP Address from DNS.
>
>> well thats the problemthe clients are geeting the correct ip address MOST
>> of
>> teh tiem but everynow and then, and teh clients chnage as well, they get
>> the
>> mian wsus server, so they are not continually obtaining the correct wsus
>> address.
>> the clients them selfs are getting there ip address correct.
>
>Then either you have something misconfigured in your DNS
>RoundRobin/Netmasking,
>or you have a subnet that does not have a WSUS Server on that subnet
>(configured in DNS).
>
>This could also happen if you've misconfigured an A record for one of the
I understand the DNS server side off how all this works but I don't know how the
client behaves. When the client contacts the DNS servers it sends a request to
the first server and then a couple of seconds later sends the request to the
remaining servers. It accepts the first answer it receives.
When the DNS client gets its answer list it presumable attempts to contact the
first listed but how does it use the remaining IPs in the list of answers.
I set up a little test and tried to open a non existing web server from IE 8
having created 2 A records pointing to different IPs (same class C subnet)
It seem (netmon trace) that an ARP gets issued to the first address and then
again around 9 seconds later. After 24 seconds an arp is issued for the second
IP address listed.
So if for some reason the local WSUS server is slow the client could be heading
off to one of the other listed IPs. I wonder how long WUAUCLT will wait before
switching to the next listed IP.
>replica WSUS Servers.
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.
|
|
"DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message
news:04vfi41gg5ci5r7s17iu13lltbmle34jhs[ at ]4ax.com...
[Quoted Text] >>> well thats the problemthe clients are geeting the correct ip address
>>> MOST
>>> of
>>> teh tiem but everynow and then, and teh clients chnage as well, they get
>>> the
>>> mian wsus server, so they are not continually obtaining the correct wsus
>>> address.
>>> the clients them selfs are getting there ip address correct.
>>
>>Then either you have something misconfigured in your DNS
>>RoundRobin/Netmasking,
>>or you have a subnet that does not have a WSUS Server on that subnet
>>(configured in DNS).
>>
>>This could also happen if you've misconfigured an A record for one of the
>
> I understand the DNS server side off how all this works but I don't know
> how the
> client behaves.
The client behavior really has little to do with the situation. In fact,
nothing is different in the client behavior than it would be in any other
name resolution scenario. The client sends a request to the DNS Server to
return *the* IP Address of the hostname.
The DNS Server applies the intelligence to the request.
If Netmask Ordering is enabled (which it is by default), and *multiple* 'A'
records exist for the hostname, then the DNS Server first checks the IP
Subnet and Subnet Mask of the requesting client. If one of the configured
'A' records exists in the subnet of the client, then that IP Address is
always returned. If multiple 'A' records exist in the subnet of the client,
then those 'A' records will be RoundRobined to the clients on that subnet.
If there is not an 'A' record with an IP Address in the subnet of the
requesting client, then "RoundRobin" kicks in on all available 'A' records
and the DNS Server returns any one of the IP Addresses listed in the
multiple 'A' records.
One other note here... Netmask Ordering is also dependent upon the subnet
mask. If you've misconfigured the subnet mask and the IP Address of the WSUS
Server does not exist within the calculated subnet of the client making the
request, then there is no guarantee that DNS will return the IP Address of
the machine at the same site. This is another possible failure point in the
O.P.'s scenario.
> When the client contacts the DNS servers it sends a request to
> the first server and then a couple of seconds later sends the request to
> the
> remaining servers. It accepts the first answer it receives.
It only sends the request to the alternate server *IF* the first server
completely fails to respond to the client request for service. Otherwise,
the alternate servers are never part of the process.
> When the DNS client gets its answer list it presumable attempts to contact
> the
> first listed but how does it use the remaining IPs in the list of answers.
It doesn't. The DNS Server only returns *one* IP Address ever.
> I set up a little test and tried to open a non existing web server from IE
> 8
> having created 2 A records pointing to different IPs (same class C subnet)
> It seem (netmon trace) that an ARP gets issued to the first address and
> then
> again around 9 seconds later. After 24 seconds an arp is issued for the
> second
> IP address listed.
This test is somewhat inconclusive since you've not fully replicated the
needed testing environment. And, since you set up the NETMON trace, you
ought to also be looking at port 53 (DNS) traffic. The likely reason an ARP
request was transmitted for the second IP Address is because the first IP
Address was totally nonresponsive, and =IE= resubmitted the hostname
resolution request. Also, since you configured both IP Addresses on the same
subnet, Netmask Ordering was never a factor. In this instance *both*
addresses are in the same subnet as the client, so RoundRobin kicked in
using only the IP Addresses from the client's subnet. (If a third address on
another subnet had an 'A' record, it would have been ignored.) DNS sent the
first IP Address, which the client attempted to get service from. The
service request failed. (No web server respondent.) The "client" (likely,
IE8) then submitted a second DNS request, and got the other address (as a
result of RoundRobin management of the available responses to the client).
Configure the first IP Address on a real web server that responds, and the
second address on another subnet (doesn't even matter if the IP Address is
actually active). Ensure Netmask Ordering is enabled (it is, by default),
and now issue web requests to that hostname. Now, in this instance, the DNS
server will return the first, and only the first, IP Address (on the local
subnet) all day long, and you'll never see a DNS resolution to the IP
Address on another subnet.
Leave the web server address on the full 255.255.255.0 netmask, and change
the client netmask to indicate it's on a subnet (255.255.255.240), and now
watch DNS return both IP Addresses, RoundRobin, because neither 'A' record
is now on the subnet of the requesting client.
> So if for some reason the local WSUS server is slow the client could be
> heading
> off to one of the other listed IPs.
*NO*. :-)
> I wonder how long WUAUCLT will wait before switching to the next listed
> IP.
> replica WSUS Servers.
WUAUCLT won't wait at all. If the WUA is pointed toward a non-existent web
server, or a non-responsive web server, or is merely the victim of a timeout
from an impaired-response web server, the WUA will log an 0x80072EFD error
code (Cannot Connect) in the WindowsUpdate.log.
--
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
|
|
Lawrence, Dave,
I have been over and over my DNS round robin and netmask is ticked on all
WSUS servers. The IP address for each one in DNS is correct.
The theory on the machines being moved can’t be the answer, because it
happens to PC's that have not been moved for months/years.
I believe there must be some error in WSUS that is causing this.
Cheers
AM
"DaveMills" wrote:
[Quoted Text] > On Sun, 23 Nov 2008 15:22:00 -0600, "Lawrence Garvin \(MVP\)"
> <lawrence[ at ]news.postalias> wrote:
>
> >"DaveMills" <DaveMills[ at ]newsgroup.nospam> wrote in message
> >news:nj2ii49bclcbe1sou746j5ajp0omarmnpe[ at ]4ax.com...
> >
> >>>Also, since you configured both IP Addresses on the same
> >>>subnet, Netmask Ordering was never a factor. In this instance *both*
> >>>addresses are in the same subnet as the client, so RoundRobin kicked in
> >>>using only the IP Addresses from the client's subnet. (If a third address
> >>>on
> >>>another subnet had an 'A' record, it would have been ignored.)
> >
> >> No, it is included in the DNS response but listed after the local subnet A
> >> records.
> >
> >I went back and reviewed my understanding of Netmask Ordering and
> >RoundRobin. I am incorrect in my original statements of the behavior of the
> >DNS Server, and now have re-edified myself. The DNS Server will always
> >return all available records; however, the *ordering* of the records is what
> >is managed. Thank you for the encouragement to re-check my own
> >understanding.
> >
> > With Netmask Ordering, the IP Address(es) on the client's subnet will
> >always be returned at the top of the list.
> >
> > With RoundRobin, the remainder of the addresses will be rotated in order
> >to vary the IP Address contained at the top of the list.
> >
> >However, part of the key here is how the *application* responds to the
> >availability of multiple IP Addresses.
> This was the last question in my first post
>
> >Also relevant is the fact that most
> >applications will respond from *cached* information, so unless those 'A'
> >records have extremely short TTLs, a client may continue to use the same IP
> >Address, even when the intent is for the client's traffic to rotate among
> >server-side resources.
> Round-robin has always had the limitation that it would only load spread to
> different clients and could never take account of actual "loading"
>
> > In addition, whether the application is programmed to
> >deal with multiple available IP Addresses is a key point.
> >In the case of IE, intended to access public web servers, I would expect it
> >to try every IP Address in the return.
> >
> >In the case of the Windows Update Agent, which is designed to work in an
> >environment with *one* WSUS Server (in fact, having a client report to
> >multiple WSUS Servers is fundamentally unreliable as you cannot then trust
> >the reporting data provided as being current or accurate), I would expect
> >the WUA to ignore anything except the first address.
> That is what I observe happening.
>
> >
> >If this is *not* the case, this could account for the issues observed by
> >AM's environment; but, I would have also expected to have seen this quirk a
> >lot sooner, since many organizations have been using Netmask
> >Ordering/RoundRobin to deal with site-specific WSUS Servers for the past
> >three years, and this is the first time we've seen a scenario where a client
> >is obtaining incorrect IP Address(es).
> >
> >There are a couple of other possibilities that can be at work here. Once is
> >that one or more of the DNS Servers has inadvertently had Netmask Ordering
> >disabled, causing it to return an IP Address at the top of the list that is
> >not on the client's subnet.
> Agreed
> >
> >Another point here, related to AM's statement that these client systems are
> >sometimes short-lived at one site or another, combined with the question of
> >TTLs on the 'A' records, is the very strong possibility that client's are
> >retaining the IP Address (in cache) of an off-site WSUS Server. I hadn't
> >considered this possiblity, previously, but now that I've been forced into
> >"Advanced DNS Operations" mentality (TYVM, Dave! <g>)...
> >
> >Consider the scenario where a notebook user travels to the corporate office
> >(or any other non-home site). While there, the WUA kicks in a regularly
> >scheduled detection. Having no IP Address in cache for the configured
> >hostname (or the TTL of the existing cached record has expired), the
> >notebook (WUA) issues a hostname resolution request, and pursuant to rules
> >of Netmask Ordering, receives the IP Address of the *current* subnet hosting
> >the notebook (not the IP Address of the notebook's intended "home" server).
> >Now, consider also, that the TTL of the 'A' record is greater than the
> >scheduled detection interval of the WUA.
> >
> >Keep in mind, also, that there's a known 'defect' in the Windows resolver
> >that causes it to retain IP Address(es) of non-responsive hosts. This is
> >why, sometimes, we must manually run 'ipconfig /flushdns' cache to get those
> >bad entries out of the cache and get the *real* address. Where I've
> >typically encountered this is Outlook when organizations have configured
> >both internal and external addresses for the Exchange server -- or where the
> >Exchange server improperly uses the same hostname and/or domain name both
> >internally and externally. When an externally active Outlook client attempts
> >to resolve the hostname of the Exchange server (typically before the VPN
> >connection is established), and a valid external address is obtained (and
> >then cached) from external DNS servers, and then a VPN connection is
> >established -- Outlook continues to use the cached external (non-responsive)
> >address instead of the internal address. Of course, there are *several*
> >flaws at work in this scenario -- the use of a domain name on both sides of
> >the firewall, the use of a hostname on both sides of the firewall, opening
> >Outlook before establishing the VPN connection, not configuring sufficiently
> >short TTLs on external IP Address resources, not configuring sufficiently
> >long TTLs on internal IP Address resources.... and I digress
> >significantly -- but the point being that there are numerous variables in
> >DNS that can adversely impact the reliable function of a complex system.
> >
> >Returning to our WSUS scenario...
> >
> >The default TTL of a Windows AD integrated 'A' record is 1 hour, and the
> >default detection is 22 hours. Under default conditions, the WUA is going to
> >intiiate a hostname resolution request at every detection event -- and the
> >result will be based on where that system is physically located when the
> >detection event occurs. Because a detection/reporting event is "sticky" --
> >the computer entries in the WSUS database are not self-cleaning, so once
> >populated, they'll stay there until manually removed, or purged by executing
> >the SCW.
> >
> >It's even more complicated, if the default detection has been reset to
> >something shorter and/or the default TTL of a LAN-based 'A' record has been
> >extended, because now the client system will continue to use that cached IP
> >Address of the (now) 'off-site' WSUS Server. It's not an unreasonable
> >scenario at all that a DNS Administrator might reconfigure the default TTL
> >in an AD integrated (internal) zone, given that most LAN-based resources
> >have very static lifetimes and there's no real reason to encourage all of
> >that excess DNS traffic re-resolving IP Addresses on an hourly basis. The
> >problem is, doing so can wreak havoc on a situations such as this -- where a
> >notebook is routinely moving from site to site -- and may not be able to
> >obtain the necessary site-specific IP Address because there's still one
> >cached with an unexpired TTL.
> >
> >Regardless of whether this is the case or not, a good best practice is to
> >ensure that the TTLs of the 'A' records involved in WSUS RoundRobin
> >configurations are shorter than the configured default detection interval,
> >but long enough to avoid unnecessary re-resolution requests during a typical
> >detect/report/download/report session.
> >
> >It should be pointed out that even with these "improvements" in the
> >configuration of DNS, the risk of a highly mobile worker's system reporting
> >to the wrong WSUS Server is still a likely possibility. This is an inherent
> >detractor from using RoundRobin to provide resolution for site-specific WSUS
> >Servers. Even site-policies have this potential risk, since the site-policy
> >would also cause the highly mobile system to detect/report to the non-home
> >server. In such scenarios with highly mobile workforces, the best solution
> >may well be fixed site-specific hostnames and separate OUs for those highly
> >mobile systems -- to ensure they're always communicating with the *assigned*
> >WSUS Server.
>
> Yes there are many possibilities including the client behavior if moved between
> subnet's while asleep/hibernating and the nic cable is connected before wake-up.
> --
> Dave Mills
> There are 10 types of people, those that understand binary and those that don't.
>
|
|
AM wrote:
[Quoted Text] > we have 1 main WSUS server and 5 replica WSUS servers in branchs. we have set
> up net masking and round robin, which is working, but the issue is the
> clients are showing up in correct WSUS server according to subnet but also
> they keep reappearing in the main server. I delete them out and a few days
> later they show up again in the unassigned group again. doesd anyone have any
> ideas on this?
Do you have "Roll up status from replica downstream servers" configured on the
main server? (This lives under "Reporting Rollup" in Options.)
Harry.
|
|
harry,
yes we do
cheers
AM
"Harry Johnston [MVP]" wrote:
[Quoted Text] > AM wrote:
>
> > we have 1 main WSUS server and 5 replica WSUS servers in branchs. we have set
> > up net masking and round robin, which is working, but the issue is the
> > clients are showing up in correct WSUS server according to subnet but also
> > they keep reappearing in the main server. I delete them out and a few days
> > later they show up again in the unassigned group again. doesd anyone have any
> > ideas on this?
>
> Do you have "Roll up status from replica downstream servers" configured on the
> main server? (This lives under "Reporting Rollup" in Options.)
>
> Harry.
>
|
|
AM wrote:
[Quoted Text] > yes we do
Then I think this behaviour is expected. By definition, roll-up reporting means
that the main server sees all the clients, not just the ones connected directly
to it.
Harry.
>>> we have 1 main WSUS server and 5 replica WSUS servers in branchs. we have set
>>> up net masking and round robin, which is working, but the issue is the
>>> clients are showing up in correct WSUS server according to subnet but also
>>> they keep reappearing in the main server. I delete them out and a few days
>>> later they show up again in the unassigned group again. doesd anyone have any
>>> ideas on this?
>> Do you have "Roll up status from replica downstream servers" configured on the
>> main server? (This lives under "Reporting Rollup" in Options.)
|
|
Harry,
by turning it off, what will happen? IE what will we lose?
cheers
AM
"Harry Johnston [MVP]" wrote:
[Quoted Text] > AM wrote:
>
> > yes we do
>
> Then I think this behaviour is expected. By definition, roll-up reporting means
> that the main server sees all the clients, not just the ones connected directly
> to it.
>
> Harry.
>
> >>> we have 1 main WSUS server and 5 replica WSUS servers in branchs. we have set
> >>> up net masking and round robin, which is working, but the issue is the
> >>> clients are showing up in correct WSUS server according to subnet but also
> >>> they keep reappearing in the main server. I delete them out and a few days
> >>> later they show up again in the unassigned group again. doesd anyone have any
> >>> ideas on this?
>
> >> Do you have "Roll up status from replica downstream servers" configured on the
> >> main server? (This lives under "Reporting Rollup" in Options.)
>
|
|
AM wrote:
[Quoted Text] > by turning it off, what will happen? IE what will we lose?
You'll have to look at each server individually to determine the status of the
clients on that server, instead of being able to look at the main server and see
everything.
Harry.
|
|
|