Troubleshooting roaming client WSUS config - DNS?
-
10 aprilie 2012 13:11
We have a global WSUS install working well. One problem with it is when a laptop/client goes from one office to another, and doesn't get updates because the client is trying to contact their home office WSUS server.
There is a rather elegant solution for this from Microsoft, the 'roaming client' set up. http://technet.microsoft.com/en-us/library/cc708563(v=ws.10).aspx It's set up as advised, round robin and netmask ordering are active.
I'm testing it at the moment (in 4 OUs), am trying to get it to work. The 3 test OUs are called IRL, HTI & PAK.
The IRL subnet has a WSUS-SERVER at 192.168.0.89, but workstations in that office are in IPs 192.168.3.X and 192.168.4.X How can I set up the roaming client config so that clients in 192.168.3/4 know to speak to the WSUS-SERVER at 192.168.0.39 ?
It's simpler in the other subnets - HTI & PAK have a WSUS-SERVER in the same subnet as the clients.
Many computers which are currently based in the IRL office are reporting into the PAK WSUS-SERVER; I know from the machine names that they are based in IRL (and not actually roaming clients), and they are obvious in the admin console because they come up with IP unknown. (whereas actual roaming clients have a local IP)
I suspect that this problem is more of a DNS/Networking issue, but can anyone advise me where to start, please?
- Editat de Eoin Ryan 19 aprilie 2012 11:34
Toate mesajele
-
11 aprilie 2012 01:38
One thing to try is to PING the IRL WSUS server from one of the workstations on the 10.1.3. or 10.1.4 subnets.
If you get a PING reply, then at least you know the network connectivity is OK. If you don't get a reply, try to ping the Fully Qualified Domain Name (FQDN) of the WSUS server. e.g. something like : ping IRLWSUS.mycorp.com (or whatever your relevant names for the server and domain are)
If the first ping (without the FQDN) and the second one (with FQDN) works, then you probably have a DNS issue. Get the network specialist to check it out, or you could work around the issue by specifying the FQDN on the PCs (Group Policy may be the best way).
If neither ping works, there is some other network issue, maybe a firewall configuration.
Ian Broadbent
-
11 aprilie 2012 03:41Moderator
The IRL subnet has a WSUS-SERVER at 10.1.0.39, but workstations in that office are in IPs 10.1.3.X and 10.1.4.X How can I set up the roaming client config so that clients in 10.1.3/4 know to speak to the WSUS-SERVER at 10.1.0.39 ?
You cannot, and that is the fundamental limitation of DNS Round-Robin and NetMask Ordering -- there must be an actual resource in every subnet, otherwise the assignment is random from all resources available.
What you can do in this scenario is create a second alias that points only to the server at 10.1.0.39, and assign that alias directly to the clients in the '3' and '4' subnets, which will ensure that those clients without a local server, will always use that specific WSUS server for updates.
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin -
12 aprilie 2012 14:25
Thank you Lawrence (again!)
I've done this, and I'm afraid to say that the IRL computers are still appearing in the consoles of the WSUS servers in the other subnets. Initially, I thought this was just because the IP alias was taking a little time to bed down, but now I'm starting to have doubts that we set it up correctly.
We have two DNS A records for the .3 and .4 subnets for wsus-server, and those IPs are aliases for the WSUS server I want those clients to speak to - 192.168.0.89
When I ping -a the alias 192.168.3.189 I get a reply from the hostname of 192.168.0.89
So, my clients in the .3 & .4 subnets have a WSUS server in the same subnet, which the DC is returning when queried for that hostname. So, why would the IRL clients still be appearing in other consoles?
I'm a little out of my depth when it comes to resolving this.
---------------------------------------
C:\Users\eoin.ryan>ping -a 192.168.3.189
Pinging <hostnameofcorrectwsus-server>.contoso.net [192.168.3.189] with 32 bytes of data:
Reply from 192.168.3.189: bytes=32 time<1ms TTL=128
C:\Users\eoin.ryan>ping -a wsus-server
Pinging wsus-server.contoso.net [192.168.3.189] with 32 bytes of data:
Reply from 192.168.3.189: bytes=32 time<1ms TTL=128
- Editat de Eoin Ryan 19 aprilie 2012 11:37
-
13 aprilie 2012 00:59Moderator
Computers are not automatically deleted from the WSUS server just because they start talking to another WSUS server. The key is not that the computers are there, but whether the Last Reported Date for that computer entrys reflect that communication is still taking place.
If it is, then you need to review the WindowsUpdate.log of that client and determine what it is configured to talk to.
If not, then delete the computer entry from that server, and you're done.
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin- Editat de Lawrence GarvinMVP, Moderator 13 aprilie 2012 01:00
-
13 aprilie 2012 12:38
A few times now, I've deleted IRL computers from a non-IRL WSUS server, but they keep re-appearing in some of them.
I guess this is a network problem, something to do with the roaming client setup isn't done quite right.
Lawrence - would you be in a position to help us to resolve it as a short contract? Perhaps you could contact me on eoin.ryan [at] concern.net ? I've tried mailing you at a onsite address, but perhaps I had the wrong one.
thx
-
14 aprilie 2012 16:43Moderator
To be honest, I barely have enough time to keep up with this forum now; and my (new) employer may also have restrictions, but these type of issues are almost always easily resolved -- once the cause is identified. Email me the complete WindowsUpdate.log from one of those systems and I'll take a look at what's happening.Lawrence - would you be in a position to help us to resolve it as a short contract?
I've tried mailing you at a onsite address
I will recheck that mailbox and reply to you from there.Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin -
15 aprilie 2012 03:11
perhaps an alternate method might be to use GPP targeting by IP range?
You could use the approaches mentioned in these articles, to apply a WUserver setting via GPP:
http://blogs.technet.com/b/askds/archive/2011/06/13/target-group-policy-preferences-by-container-not-but-group.aspxjust a thought, but it might require a bit of effort that it worth it in the longer run for you?
Don
-
16 aprilie 2012 12:40
Thanks Don, I'm reading through those articles. First impression is that making those changes would be a much larger project than I'm taking on at the moment, but certainly an improvement to consider for the future. We will be doing a large AD overhaul later in the year, or early next year when we move to AD08, and that might be the time for taking that approach.
For now, it feels like I am tantilisingly close to getting roaming client working, I just maybe have a DNS problem to solve - something with the Netmask Ordering setup. Once I get that fixed and the clients are reporting in correctly, then I'll be in great shape!
I have checked netmask ordering on both of our DNS servers, and it is enabled.
By the way - I have posted in the Networking forum with this question.
- Editat de Eoin Ryan 16 aprilie 2012 14:54
-
17 aprilie 2012 08:45
Hi Eoin,
other suggestions (perhaps no less effort than my earlier):
- renumber/readdress the WSUS server in IRL (put it into your client network or consider a /23 for it?)
- renumber/readdress the clients in IRL
- re-slice the subnets in IRL
- re-zone the IRL namespace within DNS
- implement a DNS in IRL which would have a different A record, and serve IRL clients from that DNS (this statement assumes an awful lot about your network)some of these may not make any sense, given your topology.
it's also a little confusing that your other post in the networking forum refers to B class private numbering (perhaps you have anonomised in a different way?), so my suggestions may not be as useful as I thought...Don
-
17 aprilie 2012 08:54
Hi Eoin,
other suggestions (perhaps no less effort than my earlier):
- renumber/readdress the WSUS server in IRL (put it into your client network or consider a /23 for it?)
- renumber/readdress the clients in IRL
- re-slice the subnets in IRL
- re-zone the IRL namespace within DNS
- implement a DNS in IRL which would have a different A record, and serve IRL clients from that DNS (this statement assumes an awful lot about your network)some of these may not make any sense, given your topology.
it's also a little confusing that your other post in the networking forum refers to B class private numbering (perhaps you have anonomised in a different way?), so my suggestions may not be as useful as I thought...
Don
Thanks Don, much appreciated.
All in all, I think what makes the most sense in this situation for me would be to setup a new WSUS server in the 3 subnet, as a replica child of the parent in .0 subnet.
I can configure a virtual slice far quicker than I can learn and troubleshoot this DNS issue, and while it's not as satisfying a solution, I think in the interests of progress it's the best option. Many thanks to you all for the help.
-
19 aprilie 2012 11:28
Unfortunately, this problem is still happening.
I have a WSUS server set up in the .3 subnet to serve those clients, and over 100 of them have reported in. But still, clients from that subnet are also reporting into the Admin consoles in remote sites.
For example, a new WSUS server that was just brought online this morning, in Kenya, has a few local clients and 3 machines from the .3 subnet. They don't have IPs, it just says 'unknown', but I know from the machine name that they are on the .3 subnet.
I'll have to review Don's suggestions with our DNS/network specialists and see if they have capacity to try one of them. Any other ideas?
-
17 mai 2012 09:49
Hi all,
We are still experiencing this problem.
In summary - we have a WSUS server in each subnet, but still the clients from one particualuar subnet are appearing in consoles all over the world. As above, our WSUS/DNS is set up as per the Roaming Client instructions, but it's clearly not set up correctly or completely, because it's not working. Clients in the IRL subnet are reporting to other WSUS boxes.
I am eager to get it resolved and would be in a position to offer it as a piece of work to someone. If you would be able to solve this, please contact me. My email is eoin.ryan [ at ] concern.net
-
25 mai 2012 12:11 This is fixed now.
We have a web filter in place and requests were coming into it for the IIS WSUS site (using a hostname as per the roaming client setup in the link above).
When the web filter asked the DNS server for the IP of that hostname, the DNS server sent back an ordered list of IPs, with the local one in the same subnet at the top of the list. Normal netmask ordering, that the typical Windows clients will understand to mean 'talk to the IP at the top of the list, it's in your subnet'.
Our web filter didn't respect netmask ordering (even though it's vendors say it does) and it was directing those requests all over the world to various WSUS servers, randomly picking from the list of IPs. It's been fixed by editing the equivalent of the hosts file on the web filter to direct all requests for that hostname to a specific IP on this subnet.
Thanks for the help all.- Marcat ca răspuns de Lawrence GarvinMVP, Moderator 26 mai 2012 00:45
-
26 mai 2012 00:48Moderator
Our web filter didn't respect netmask ordering (even though it's vendors say it does) and it was directing those requests all over the world to various WSUS servers, randomly picking from the list of IPs. It's been fixed by editing the equivalent of the hosts file on the web filter to direct all requests for that hostname to a specific IP on this subnet.
Thank you for posting the resolution back to the forum, Eoin. I would have never considered that scenario as a possible cause -- but it's on my list now. :-)Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
Microsoft MVP - Software Distribution (2005-2012)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
.png)
