If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Windows XP Pro WINS mixups
Hi Everyone,
I hope that this question hasn't already been asked and answered. I haven't been able to find anything, so here goes... We run a Windows 2000 network with mainly Windows 2000 workstations. DHCP, DNS, and Secondary WINS are provided by SERVER1. Primary WINS and Secondary DNS are provided by SERVER2. We are experiencing a problem where Windows XP Professional workstations list the WINS servers in the wrong order after boot. Basically when the machine gets it's DHCP information, it lists SERVER1 as Primary WINS server and SERVER2 as secondary. In the WINS database some entries for the PC are in SERVER1's database, and some are in the database of SERVER2. After about 30 minutes the workstation sorts itself out an shows that SERVER2 is the Primary WINS server, and the WINS database shows all records registered on SERVER2. We are having some name resolution problems with these XP machines during this period of time. If anyone has seen this before and/or knows of a resolution I would really appreciate it. If at all possible please CC replies to email as well. Thank you, Robert |
Ads |
#2
|
|||
|
|||
Windows XP Pro WINS mixups
"Robert Isaac" wrote in message
news:T7bSb.31225$P51.11115@clgrps12... Hi Everyone, I hope that this question hasn't already been asked and answered. I haven't been able to find anything, so here goes... We run a Windows 2000 network with mainly Windows 2000 workstations. DHCP, DNS, and Secondary WINS are provided by SERVER1. Primary WINS and Secondary DNS are provided by SERVER2. We are experiencing a problem where Windows XP Professional workstations list the WINS servers in the wrong order after boot. Basically when the machine gets it's DHCP information, it lists SERVER1 as Primary WINS server and SERVER2 as secondary. In the WINS database some entries for the PC are in SERVER1's database, and some are in the database of SERVER2. After about 30 minutes the workstation sorts itself out an shows that SERVER2 is the Primary WINS server, and the WINS database shows all records registered on SERVER2. We are having some name resolution problems with these XP machines during this period of time. If anyone has seen this before and/or knows of a resolution I would really appreciate it. If at all possible please CC replies to email as well. Thank you, Robert I don't know what is causing the problem, and I have seen similar oddities with NT4. ( statically assigned NT4 SP6a server; Pri and Sec WINS specified in Network Control Panel; but IPCONFIG lists them in reverse order. I never did run a sniff to determine which was lying - IPCONFIG or the Control Panel. ) Nonetheless, here's some general suggestions: 1) With WINS, less is more. By that, I mean that the fewer WINS servers you can manage with, the better. You need to look at your network topology to determine how many servers are required, where they should be, and how the replication should work. As a general rule, I'd put one WINS server in each remote location ( connected by a slow WAN link ). Then 2 WINS servers in central office, one as a 'hub' server for all the others to replicate to,, and one user-facing in central office. Each workstation points to local WINS as primary, and the central 'hub' as secondary. Each remote location server push-pull replicates with only the hub machine. This way, all machines get fast local registration and name resolution, and over time, each outlying subnet WINS server updates the central hub. The central hub then pushes the merged database back out to all the outlying WINS servers. Having the hub machine as secondary provides a degree of fault tollerance, so that if a local server goes down, user workstations continue to register / query but at a slower speed across the WAN. So in your situation, do you have remote subnets? How many clients are you serving? If you have a single small site, consider whether you really need 2 WINS servers. In a win2k network, WINS traffic is usually lowish if DNS is working. 2) Are your WINS servers replication partners with each other? If a machine registers with the 'wrong' server, they ought to replicate between themselves. -- Best Regards, Ron Lowe MS-MVP Windows Networking |
#3
|
|||
|
|||
Windows XP Pro WINS mixups
Hi Ron,
Thanks for the quick reply. After some more investigation, I have determined that Windows 2000 Professional suffers the same problem. If NT4 also has this problem, maybe it is a feature. The WINS entries are spread across both servers, so something is going very wrong. In answer to your questions: 1a) Yes I have remote subnets. 42 of them. They are all connected via relatively high-speed WAN links. 1b) There are approximately 550 workstations in the network 1c) Most workstations are 2000, so you are correct our WINS traffic is quite low. 2) Yes the servers replicate with each other. After time the data sorts itself out, however the initial delay in sorting out the name registrations does cause problems. The two servers that host DNS/WINS are relatively powerful and we have not seen any excessive load. Network, disk, and processor are all within an acceptable range. Both servers are on the same network (with the majority of clients.. about 200) connected at gigabit through various switches. We have about 3 remote WINS servers that all replicate with the primary WINS server, and the clients are setup in the method you described. We do not appear to be having any replication problems with WINS itself. One of my coworkers mentioned finding an article on this problem with NT4 and said that it was to be corrected with a service pack. When (if) we locate the article I will compare and post on what I can find. Thank you for your time and information. I will verify our settings based on your suggestions. Robert "Ron Lowe" wrote in message ... "Robert Isaac" wrote in message news:T7bSb.31225$P51.11115@clgrps12... SNIP I don't know what is causing the problem, and I have seen similar oddities with NT4. ( statically assigned NT4 SP6a server; Pri and Sec WINS specified in Network Control Panel; but IPCONFIG lists them in reverse order. I never did run a sniff to determine which was lying - IPCONFIG or the Control Panel. ) Nonetheless, here's some general suggestions: 1) With WINS, less is more. By that, I mean that the fewer WINS servers you can manage with, the better. You need to look at your network topology to determine how many servers are required, where they should be, and how the replication should work. As a general rule, I'd put one WINS server in each remote location ( connected by a slow WAN link ). Then 2 WINS servers in central office, one as a 'hub' server for all the others to replicate to,, and one user-facing in central office. Each workstation points to local WINS as primary, and the central 'hub' as secondary. Each remote location server push-pull replicates with only the hub machine. This way, all machines get fast local registration and name resolution, and over time, each outlying subnet WINS server updates the central hub. The central hub then pushes the merged database back out to all the outlying WINS servers. Having the hub machine as secondary provides a degree of fault tollerance, so that if a local server goes down, user workstations continue to register / query but at a slower speed across the WAN. So in your situation, do you have remote subnets? How many clients are you serving? If you have a single small site, consider whether you really need 2 WINS servers. In a win2k network, WINS traffic is usually lowish if DNS is working. 2) Are your WINS servers replication partners with each other? If a machine registers with the 'wrong' server, they ought to replicate between themselves. -- Best Regards, Ron Lowe MS-MVP Windows Networking |
#4
|
|||
|
|||
Windows XP Pro WINS mixups
The reason for the client flip flopping the WIns server is that it tried to
contact the primary at some point and did not recieve a timely response. It then tried the secondary, got a response and change the order. Your issue appears to me as a Wins replication problem. If Client A registers with Wins B, its registration should be replicated and show up in all replication partners. Are you getting any event log messages about Wins replication on the Wins servers? -- Thanks, Marc Reynolds Microsoft Technical Support This posting is provided "AS IS" with no warranties, and confers no rights. "Robert Isaac" wrote in message news:VEgSb.32394$P51.18741@clgrps12... Hi Ron, Thanks for the quick reply. After some more investigation, I have determined that Windows 2000 Professional suffers the same problem. If NT4 also has this problem, maybe it is a feature. The WINS entries are spread across both servers, so something is going very wrong. In answer to your questions: 1a) Yes I have remote subnets. 42 of them. They are all connected via relatively high-speed WAN links. 1b) There are approximately 550 workstations in the network 1c) Most workstations are 2000, so you are correct our WINS traffic is quite low. 2) Yes the servers replicate with each other. After time the data sorts itself out, however the initial delay in sorting out the name registrations does cause problems. The two servers that host DNS/WINS are relatively powerful and we have not seen any excessive load. Network, disk, and processor are all within an acceptable range. Both servers are on the same network (with the majority of clients.. about 200) connected at gigabit through various switches. We have about 3 remote WINS servers that all replicate with the primary WINS server, and the clients are setup in the method you described. We do not appear to be having any replication problems with WINS itself. One of my coworkers mentioned finding an article on this problem with NT4 and said that it was to be corrected with a service pack. When (if) we locate the article I will compare and post on what I can find. Thank you for your time and information. I will verify our settings based on your suggestions. Robert "Ron Lowe" wrote in message ... "Robert Isaac" wrote in message news:T7bSb.31225$P51.11115@clgrps12... SNIP I don't know what is causing the problem, and I have seen similar oddities with NT4. ( statically assigned NT4 SP6a server; Pri and Sec WINS specified in Network Control Panel; but IPCONFIG lists them in reverse order. I never did run a sniff to determine which was lying - IPCONFIG or the Control Panel. ) Nonetheless, here's some general suggestions: 1) With WINS, less is more. By that, I mean that the fewer WINS servers you can manage with, the better. You need to look at your network topology to determine how many servers are required, where they should be, and how the replication should work. As a general rule, I'd put one WINS server in each remote location ( connected by a slow WAN link ). Then 2 WINS servers in central office, one as a 'hub' server for all the others to replicate to,, and one user-facing in central office. Each workstation points to local WINS as primary, and the central 'hub' as secondary. Each remote location server push-pull replicates with only the hub machine. This way, all machines get fast local registration and name resolution, and over time, each outlying subnet WINS server updates the central hub. The central hub then pushes the merged database back out to all the outlying WINS servers. Having the hub machine as secondary provides a degree of fault tollerance, so that if a local server goes down, user workstations continue to register / query but at a slower speed across the WAN. So in your situation, do you have remote subnets? How many clients are you serving? If you have a single small site, consider whether you really need 2 WINS servers. In a win2k network, WINS traffic is usually lowish if DNS is working. 2) Are your WINS servers replication partners with each other? If a machine registers with the 'wrong' server, they ought to replicate between themselves. -- Best Regards, Ron Lowe MS-MVP Windows Networking |
#5
|
|||
|
|||
Windows XP Pro WINS mixups
Hi Marc,
Here are the errors (Information Notices, not errors) that I am getting. This one seems to be a standard 'couldn't find what the client is looking for' error: Event Type: Information Event Source: Wins Event Category: None Event ID: 4141 Date: 30/01/2004 Time: 8:59:54 AM User: N/A Computer: AD2 Description: WINS pulled records from a WINS while doing Pull replication. The partner's address and the owner's address whose records were pulled are given in the data section (second and third DWORD respectively). The number of records pulled is the fourth DWORD. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 00000609 00000000 c0a8632a 00000001 And this one looks like a 'replication occurred': Event Type: Information Event Source: Wins Event Category: None Event ID: 4141 Date: 30/01/2004 Time: 8:59:54 AM User: N/A Computer: xxx Description: WINS pulled records from a WINS while doing Pull replication. The partner's address and the owner's address whose records were pulled are given in the data section (second and third DWORD respectively). The number of records pulled is the fourth DWORD. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 00000609 00000000 c0a8632a 00000001 The replication is showing up on WINSA after time. But initially some records appear with WINSA as owner, and some appear with WINSB as owner. Basically one computer will have half of its records owned by one WINS server, and the other half owned by another WINS server. Eventually everything sorts itself out and all the records end up being owned by WINSA. Robert "Marc Reynolds [MSFT]" wrote in message ... The reason for the client flip flopping the WIns server is that it tried to contact the primary at some point and did not recieve a timely response. It then tried the secondary, got a response and change the order. Your issue appears to me as a Wins replication problem. If Client A registers with Wins B, its registration should be replicated and show up in all replication partners. Are you getting any event log messages about Wins replication on the Wins servers? -- Thanks, Marc Reynolds Microsoft Technical Support This posting is provided "AS IS" with no warranties, and confers no rights. SNIP |
Thread Tools | |
Display Modes | |
|
|