Hey, I have a DFS-R implementation in place. Some Files are located on a server in our corporate office and some are located at our branch office. Clients access the main DFS namespace via a network drive (W:) which is mapped to "domain.local" (sec.local) (see Picture 1 ). -SERVER2 and SERVER3 are in our corporate office -PSERVER2 is in our Branch office When on a client machine in our branch office, I right click the W: drive and select properties and browse to the DFS tab. Under the referral list the active server is SERVER2, which is located in our corporate office. This poses a problem when the WAN link goes down and then they can't access their W: drive because they can't contact SERVER2. How can I get the mapped drive on the client machines in our branch office to refer to the correct server (PSERVER2).? Additional information: There are several folders within the DFS namespace. (see Picture 2 ) 2 of 7 folders are located in the branch office and it refers these folders correct server (PSERVER2). I apologize if my description is confusing. Please let me know if I need to make any clarifications. Thanks for your help! Picture 1 Picture 2

Hello Caleb_S,Thank you for posting here.From your description, it seems that there are 3 DFS member servers geographically located in 2 differentsites.Based on the research, there are 2 methods we can use to make the domain clients computer refer to the server in their own sites.Method1. We can take use of Least Expensive Target Selection method for the domain clients in the remote office to select the DFS root referral (PSERVER2) within its own site. 1. You may consider referring to the following document to create site and IP subnet object in Active Directory, with these settings, the domain client will prefer to select the DFS root referral within its own site. Creating a Site Designhttp://technet.microsoft.com/en-us/library/cc736820.aspx a. Create 2 sites objects in the Active Directory Sites and Servicesb. Please bind the IP address of the DFS domain clients and DFS member servers accordingly in the corresponding site object.Reference: How DFS works (part: Least Expensive Target Selection)http://technet.microsoft.com/en-us/library/cc782417.aspx 2. Besides, a referral is an ordered list of targets that a client computer receives from a domain controller or namespace server when the user accesses a namespace root or folder with targets in the namespace. After the client receives the referral, the client attempts to access the first target in the list; if the target is not available, the client attempts to access the next target. Targets in the client's site are always listed first in a referral. Targets outside of the client's site are listed according to the ordering method. Please use the following procedure to set the ordering method on the namespace root.To set the ordering method for targets in namespace root referralsA. Click Start, point to Administrative Tools, and then click DFS Management.B. In the console tree, under the Namespaces node, right-click a namespace, and then click Properties.C. On the Referrals tab, select an ordering method (Lowest cost) Please note: the folders with targets inherit the ordering method from the namespace root. However, for the 2 of the 7 DFS folders in the remote site office (PSERVER2), you can override the ordering method by using the following procedure in the DFS management console. Therefore, these 2 folders will be referred to the server in the remote site office (PSERVER2) To set the ordering method for targets in folder referrals A. Click Start, point to Administrative Tools, and then click DFS Management. B. In the console tree, under the Namespaces node, right-click a folder with targets, and then click Properties. C. On the Referrals tab, select the Exclude targets outside of the client's site check box. Reference: Set the ordering method for targets in referrals http://technet.microsoft.com/en-us/library/cc783327(WS.10).aspx Referral propertieshttp://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx 3. To make the above the setting take into effect, please flush DFS cache on the domain client because they might have access the DFS namespace before and already cached the DFS root referral locally. a. install Windows Server 2003 Service Pack 1 Support Tools on a client and run the following command to flush DFS cache: Download: Windows Server 2003 Service Pack 1 Support Toolshttp://support.microsoft.com/kb/892777 b. Then manually clear the referral cache by using Dfsutil.exe with the /pktflush parameter. Dfsutil /pktflush Method2. The simple method is that you can set Active DFS root after the domain clients access the DFS namespace via mapped network drive successfully. You can simply select \\PSERVER2\HOME and then click "Set Active" within properties of the DFS namespace. For more reference about Windows Server 2003 R2 DFS namespace, you may check the following KB article Description of the Distributed File System (DFS) Management snap-in in Windows Server 2003 R2 http://support.microsoft.com/default.aspx/kb/915146 Hope it can be helpful. This posting is provided "AS IS" with no warranties, and confers no rights.

Hello Caleb_S, I want to see if the information provided was helpful. Please keep us posted on your progress and let us know if you have any additional questions or concerns. We are looking forward to your response. This posting is provided "AS IS" with no warranties, and confers no rights.

Hey David, Thanks for your detailed response. I took Friday off and have been playing catch up today in the office. I apologize for the delayed response. I have reviewed your response and have several comments and questions I will list: Method 1: - Active directory sites have been setup and configured prior to this problem. We are good to go there. To set the ordering method for targets in namespace root referrals - 2 of the 7 Folders are referred to PSERVER2, the correct server. However, The problem occurs when the W: drive is not accessible. The user first has to access the W: drive before they can see W:/pdxcasework/. If the W: drive can't be accessed because it is referring to a server in another office and the WAN link is down then they can't access anything, including the 2 folders that are stored in their office. All of this is to say that I don't believe changing settings on the 2 is where the problem lies. It appear that we need to make sure the W: Drive is referring to the local server. -I did make several changes. 1. I went into the DFS Management and under namespaces right clicked our name space and selected properties, clicked the referrals tab and changed the ordering method to "Exclude targets outside of the client's site." I changed these settings at the namspace level and not the folder level. Unfortunatly, this didn't seem to have any affect on anything. 2. I also checked "Clients fail back to preferred targets" thinking they may have once referred to the wrong server and had not switched back. This didn't seem to have any affect either. I'll check back tomorrow to see if anything may have flushed it self out overnight. Method 2: - I have attempted this but the settings do not stick upon restart. :( - I supposed I could change the logon scripts for users in this off so that they the W: drive to \\pserver2\home (their branch office server) but I still feel like that is a work around and not solving the problem. It may even bring up more problems if users then travel between offices like they do frequently. Do you have any other suggestions based on my response? Thanks for your help David, It is much appreciated! Caleb

Hello Caleb,Is PSERVER2Domain Controller? If so try to edit registry key for PSERVER2 to include HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs "PreferLogonDC" dword:value of 1. This should force users to look for dfs first from PSERVER2. And if PSERVER2 is not a domain controller,then thesuggestion I might say is that of using a script, maybe logon script, to force users to use DFS shares based on their subnets.Hope this helps.Isaac Oben MCITP:EA, MCSE

Hi Caleb_S, Thanks for your reply. Based on the further research on the issue, I agree with what Isaac have suggested. Action plan: If the PSERVER2 is a domain controller, please consider adding the PreferLogonDC registry entry to the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dfs registry subkey on the domain controller, set the value of the PreferLogonDC registry entry to 1. A. To add the PreferLogonDC registry entry and set the PreferLogonDC registry entry to 1, please follow these steps: 1. Click Start, click Run, type regedit in the Open box, and then click OK. 2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dfs 3. On the Edit menu, point to New, and then click DWORD Value.. 4. Type PreferLogonDC, and then press ENTER. 5. On the Edit menu, click Modify. 6. In the Value data box, type 1, and then click OK 7. Quit Registry Editor. B. Then please install the following update on that server. An update for Windows Server 2003 and Windows 2000 Server makes it possible to put the logon server at the top of the DFS referrals list http://support.microsoft.com/default.aspx/kb/831201 c. Restart the domain controller to monitor if it will be helpful. If PSERVER2 is not a domain controller, you may consider forcing users to use DFS shares based on their subnets by using log script. Hope the information will be helpful.This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks for the responses gentlemen! PSERVER2 is indeed a Domain Controller. I have modified the registry entry like you suggested. I have scheduled the server to perform a reboot tonight, because I cannot take it down in the middle of the work day. I also attempted to install the hotfix mentioned, but it said that there was no need because the service pack on the server was already up to date. I will check back in tomorrow and let you know how things turn out. Thanks Isaac! Thanks David!

Good Morning! I rebooted the server last night after making the registry changes. Unfortunately the client workstations are still referring to SERVER2 instead of PSERER2. I have rebooted the workstations. Do you have any other ideas? Thanks! Caleb

Hello Caleb, Either have one of the client reboot their workstation and see if it changes or ask them to do a dfsutil /PktFlush /purgemupcache Also check to see which DC the client is using for authentication by typing this at command promptand hit enter. set logonserver Client should show PSERVER2 as logon server if not, then post back either wayIsaac Oben MCITP:EA, MCSE

Hey Isaac, I did as you said, however, the purgemupcache command returns "Unrecognized opiton "purgemupCache" I enter in: dfsutil /purgemupcache What is the proper usage of this? Also, I did run the set logonserver and it does show PSERVER2 as the logon server.

I can perform the dfsutil /purgemupcache on PSERVER2, but I cannot do it on this specific client. I will try another client.

I tried the dfsutil /purgemupcache command on another client after a fresh install of the support tools and I get the same message.

Ok I realized that the the Windows XP Support Tools package does not include the purgemupcache command in it. I downloaded the Server 2003 SP2 Support tools, installed them on the client and was then able to run the command. However, this did not change anything. The W: drive is still referring to SERVER2. :(

Hi Caleb_S,Could you please run the following command line on the client to display the cached target referrals and active target?Dfsutil /pktinfoIf possible, please post back the result here.Then to clear the referral cache, please run the following command line on the client.Dfsutil /pktflushAfterwards, you may try rebooting the client computer and test to see if the W: drive will be referred to right server.For more information about DFSUTIL, please see the following document.Dfsutil Remarkshttp://technet.microsoft.com/en-us/library/cc779494(WS.10).aspx Hope it works. This posting is provided "AS IS" with no warranties, and confers no rights.

Hey David, So last night I did some experimenting. I took SERVER2 offline to see how the clients would react. They automatically and quickly switched their referral of the W: drive to PSERVER2. As soon as PSERVER2 came back online, the W: drive would switch back to referring to SERVER2. (See Pictures Below) Client Info while SERVER2 is Online Client Info while SERVER2 is Offline I did run and as you said the dfsutil /pktflush cmd. I have also been doing this throughout the troubleshooting process I do not know why this is occurring. The good thing is that the clients are switching automatically back and forth between referrals. However, I do not know if this is causing any unnecessary network traffic. Ideally I would like to resolve the root problem, however, maybe I won't be able to. Thanks!!! P.S I am on vacation next week, so I apologize in advance.

Hello Caleb,Hope we can get this resolve before your next week vacation..Please post a complete ipconfig /all from Server2, Pserver2, and a WinXP client on PServer2 site. If you wish and for security reason, you can omit the domain part..Isaac Oben MCITP:EA, MCSE

Hi Caleb_S, Thank you for the reply. Based on the research, the reason why the clients switches automatically back and forth between referrals is because Clients fail back to preferred targets is enabled, which wont cause any unnecessary network traffic in a well-designed domain and site. For your reference, here is a good blog which describe the detailed information about Client failback behavior. How client failback works in DFS Namespaces http://blogs.technet.com/filecab/archive/2006/03/27/423269.aspx Before we go any further, I'd like to explain the Default DFS Target Selection method. By default, DFS places target servers in the referral in the following order: Targets in the same site as the client are listed in random order at the top of the referral. Targets outside of the clients site are listed in random order. Example of Client and Target Sites Please Note: Out-of-date or mis-configured site information can cause DFS to sort referrals incorrectly. Using the previous figure as an example, when default target selection is enabled, DFS places the target servers in the referral in the following order: Default Referral Order If no same-site target servers are available, the client computer is referred to a random target server no matter how expensive the connection is or how distant the target is. This is the default DFS behavior. According to your test result, the clients are always referred to the DFS server in the remote site. It indicates that the system recognizes the remote server and the problematic clients are in the same site. I understand that you have a good site definition. I still suggest that you double check to ensure that Sites object is created and the IP address of the DFS client is associated with the appropriate site. Steps: 1. Create a new site object in Active Directory Sites and Service. 2. Ensure that remote site is linked to other sites with site links as appropriate. 3. Add subnets for the Remote site to the Subnets container. 4. Move the existing domain controller PSERVER2 into that new Remote site. If the problem still continues, we may need to collect the following information for further research. 1. Please collect the MPSReport of all domain controllers and a problematic client. Microsoft Product Support's Reporting Tools (MPSRPT_DirSvc.EXE) http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en 2. Reproduce this issue and then run the following command to export the DFS cache information on the client: Dfsutil /pktinfo >c:\dfspkt.txt 3. Collect the AD site reports. To get the AD Site report, please use the following steps: Site Report: ========== a. On DC, click Start -> Run, type REPLMON and click OK. b. Right click Monitored Server, click Add Monitored Server. Select Search the directory for the server to add and click Next. Select the local DC, and click Finish. c. After the Server node is expanded in the left panel, right click the server node, select Generate Status Report, select a file name in the Save As box, for example, DC1.txt and click Save, then select all the option in the Report Options box, and click OK. d. Repeat the steps b and step c to connect and generate report for the other DCs. Email the files to me. 4. Capture a network monitor trace on client while reproducing the issue. Download: Microsoft Network Monitor 3.2 http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en a. Enable the Capture Filter "IPv4.Address == <ip of the client>" and start capture. b. Restart one of clients to reproduce the issue. c. Stop capture and save to *.cap file. How to use Network Monitor to capture network traffic http://support.microsoft.com/kb/812953 Please send me the report, the network trace and the log file via tfwst@microsoft.com I appreciate your time and effort. We hope the issue will be resolved soon.This posting is provided "AS IS" with no warranties, and confers no rights.

Isaac Here is the ipconfig info. David, I'm wrapping as many things up as I can today before I leave. I will probably not have time to perform all the things in your post. I will return to this probably on the 29th. I really appreciate the assistance both of you have given me!!

Hello Caleb_b, Hope you have a good vacation. :-) Thank you for collecting the ipconfig output; however, due to the complexity of this issue, we cannot identify the root cause with them. When you come back, I suggest that you perform the steps in my previous reply and collect the information required if the problem continues. It is always our pleasure to be of help. This posting is provided "AS IS" with no warranties, and confers no rights.

OK, well I got back last week from vacation. I had a great time Road Tripping though California and seeing Yosemite National Park... Wow! It was great! I'm been busy playing catch up in the office but I'm going to get back into this within the next several days as time permits. Thanks for your patience guys.

Hi Caleb_S, I am glad to hear that you had a great trip. :-) I understand that you will be busy these days. Anyway, when you have time to work on this issue, please collect the required information, including MPSReport, dfspkt.txt, site configuration information and network monitor logs. They are very important for us to perform further research on this issue.This posting is provided "AS IS" with no warranties, and confers no rights.

Alright, I have several questions before I dive in about the following steps: Steps: 1. Create a new site object in Active Directory Sites and Service. 2. Ensure that remote site is linked to other sites with site links as appropriate. 3. Add subnets for the Remote site to the Subnets container. 4. Move the existing domain controller PSERVER2 into that new Remote site. Is there any side effects that the users may experience from moveing the DC into a new site? Do I need to do anythign in addition to these steps? I just want to be prepared ahead of time. Thanks!

Alright, I have several questions before I dive in about the following steps: Steps: 1. Create a new site object in Active Directory Sites and Service. 2. Ensure that remote site is linked to other sites with site links as appropriate. 3. Add subnets for the Remote site to the Subnets container. 4. Move the existing domain controller PSERVER2 into that new Remote site. Is there any side effects that the users may experience from moveing the DC into a new site? Do I need to do anythign in addition to these steps? I just want to be prepared ahead of time. Thanks! Hi Caleb_S, Thanks for the reply. When trying to determine site boundaries, we should configure sites so that it can reflect the physical structure of your network. Use connectivity between network segments to determine where we should locate site boundaries. In general, areas of the network that are connected with fast connections should all be part of the same site, unless you have specific requirements for controlling replication or the logon process. I just recommend you move the DC PSERVER2 object into the remote site container in Active Directory Sites and Services. Before perform this action, you may need to create a new site object, and create a subnet object which binding the IP address scope to include the domain clients in that remote site. This is for help the domain client to locate the DC in their site. If you select not to place a domain controller at a remote location, users may experience slow logon and authentication to network resources. Moreover, the decision to establish a separate site may come down to the user experience and the available bandwidth. If you have fast connections between siteswhich should be dedicated and redundantyou may not want to establish a separate site for the remote business location. If you have limited bandwidth between business locations and want to maintain the user experience, you may want to establish a separate site and place domain controllers and possibly other network resources at the site. This speeds up the logon and authentication process and allows you to better control the network traffic between sites. For your reference, I have also included the following link which introduces how to design a site topology: This posting is provided "AS IS" with no warranties, and confers no rights. Overview of Designing a Site Topology http://technet.microsoft.com/en-us/library/cc780415.aspx Hope this information can be helpful for you.

Hey David, Thanks for your response. Maybe I should clarify some things. We already do have 2 sites setup with the appropriate subnets configured. The DC Servers are located in their respective site. You are now asking me to create a new site and subnet and then move the DC Server into the new site. You are asking me to do this to insure everything is setup properly. Is this accurate? If so, can I configure the new site to have the same subnet and perform this change without any affect? There are many devices on the network and to create a new subnet would be a lot of work. The reason I ask all these questions is because I want to prevent this from affecting the users in this office.

Hi Caleb_S, Thank you for the reply. Since you have already setup 2 sites with mapping their subnets in Active Directory Sites and Services, I think you don't need to create a new site if the current site information has already represents your company network topology. As you mentioned that "The DC Servers are located in their respective site", in this situation, you just may need to check if the PSERVER2 object has been moved into that Site/Server container, which represents that remote site location in Active Directory Sites and Services. If not, you may simply perform this action without creating a site. To have a better understanding on your network configuration and active directory site topology, we may need to collect the following information as I mentioned in my previous reply. These logs and report are very important for us to help you and give you specific information on how to troubleshoot the issue. 1. Please collect the AD site reports. To get the AD Site report, please use the following steps: a. On DC, click Start -> Run, type REPLMON and click OK. b. Right click Monitored Server, click Add Monitored Server. Select Search the directory for the server to add and click Next. Select the local DC, and click Finish. c. After the Server node is expanded in the left panel, right click the server node, select Generate Status Report, select a file name in the Save As box, for example, DC1.txt and click Save, then select all the option in the Report Options box, and click OK. d. Repeat the steps b and step c to connect and generate report for the other DCs. Email the files to me. 2. Please collect the MPSReport of all domain controllers and a problematic client. Microsoft Product Support's Reporting Tools (MPSRPT_DirSvc.EXE) http://www.microsoft.com/downloads/details.aspx?FamilyID=CEBF3C7C-7CA5-408F-88B7-F9C79B7306C0&displaylang=en 3. Reproduce this issue and then run the following command to export the DFS cache information on the client: Dfsutil /pktinfo >c:\dfspkt.txt 4. Capture a network monitor trace on client while reproducing the issue. Download: Microsoft Network Monitor 3.2 http://www.microsoft.com/downloads/details.aspx?FamilyID=f4db40af-1e08-4a21-a26b-ec2f4dc4190d&DisplayLang=en a. Enable the Capture Filter "IPv4.Address == <ip of the client>" and start capture. b. Restart one of clients to reproduce the issue. c. Stop capture and save to *.cap file. For more reference: How to use Network Monitor to capture network traffic http://support.microsoft.com/kb/812953 Please send me the report, the network trace and the log files via tfwst@microsoft.com We are looking forward to your mail. Thanks for the co-operation.

Hi Caleb_S,I'm just want to know if you have had an opportunity to gather the requested information. If anything is unclear or you encountered any difficulties, please dont hesitate to let me know.I look forward to hearing from you.This posting is provided "AS IS" with no warranties, and confers no rights.

I have not as of yet. Thank you for your patience and persistence. I'm the sole IT guy for our company of 60 and at the moment this is what Microsoft would call "Non Mission Critical" :) I'm not giving up, I just need to wait for the time to invest. Thanks David!

Sigh, I've given up on this. I simply do not have the time to troubleshoot this matter. The matter has also turned into a secondary issue, meaning, that if their internet goes down they are referred to the correct server to access the W: Drive. This was not what was occuring originally. While I would like the W: drive to refer to the local server all the time, this isn't actually causing a problem for the time being. Somewhere in the middle of this post things started to work 90% correctly, I'm happy with that. I appreciate all of your help in this matter and apologize for my absence the past month. Thank you for all your help! Caleb