We are about to start deploying applications via DFS heavily, but noticed an odd thing today:
Clients in the same site and subnet as a DFS host are consistently referred to that local server for the necessary files.
Clients in the same site but a different subnet as a DFS host are consistently referred to a remote server for the necessary files.
For example, when a client and DFS server are both in the 172.22.22.0/24 subnet, the client always gets its files from that server. When the client is the 172.22.23.0/24 subnet (and both the 172.22.22.0/24 and 172.22.23.0/24 subnets are in the same site), the client always gets its files from another server.
Each DFS host is across the WAN, so we obviously don't want to pull application installation files across the WAN.
So far I have verified:
1. Each subnet in ADS&S is associated with the expected site
2. The 'bridge all site links' option is enable for the IP Inter-Site Transport.
3. I have a mix of Windows 2000 and 2003 servers acting as DFS hosts.
Do I have to ensure that the HKLM\system\CurrentControlSet\Control\LSA\restrictanonymous is not set to 2 on the Windows 2000 DFS hosts? This is happening in sites with a Windows 2003 server in them.
I have tried to enable the /insite option with DFSutil. This works for every site except for one. That one site has the DFS file on a member server instead of directly on the domain controller.
I could easily move the DFS host to the domain controller itself at this site, enable the /insite option, and be done, but my concern is why the default DFS referral mechanism does not seem to be working as expected. Should I be worried about a larger underlying problem with our Active Directory infrastructure?
Robb
Clients in the same site and subnet as a DFS host are consistently referred to that local server for the necessary files.
Clients in the same site but a different subnet as a DFS host are consistently referred to a remote server for the necessary files.
For example, when a client and DFS server are both in the 172.22.22.0/24 subnet, the client always gets its files from that server. When the client is the 172.22.23.0/24 subnet (and both the 172.22.22.0/24 and 172.22.23.0/24 subnets are in the same site), the client always gets its files from another server.
Each DFS host is across the WAN, so we obviously don't want to pull application installation files across the WAN.
So far I have verified:
1. Each subnet in ADS&S is associated with the expected site
2. The 'bridge all site links' option is enable for the IP Inter-Site Transport.
3. I have a mix of Windows 2000 and 2003 servers acting as DFS hosts.
Do I have to ensure that the HKLM\system\CurrentControlSet\Control\LSA\restrictanonymous is not set to 2 on the Windows 2000 DFS hosts? This is happening in sites with a Windows 2003 server in them.
I have tried to enable the /insite option with DFSutil. This works for every site except for one. That one site has the DFS file on a member server instead of directly on the domain controller.
I could easily move the DFS host to the domain controller itself at this site, enable the /insite option, and be done, but my concern is why the default DFS referral mechanism does not seem to be working as expected. Should I be worried about a larger underlying problem with our Active Directory infrastructure?
Robb