Dfsutil.exe Location

[Edco Haglund]

Ineeded to help diagnose a client computer and I needed the dfsutil.exe tool, this tool is only available in the RSAT package. Usually no problems, just install it. But this time I needed to run dfsutil.exe without installing it on the client. So I copied the executable file and tried to run it.. Well.. This is what happened:

Oddly, when I changed the path to the FileExists rule to C:\Windows\System32\fc.exe as a test, all machines detect the rule properly. I did this after making the other rules, so I know that new rules do work if it does not have to do with dfsutil. I do not know why this happens.

I haven't tested it. But I see a "dfsutil.exe" in c:\windows\system32 only, not in the c:\windows\syswow64. The "fc.exe" file exists in both system32 and syswow64 directories, hence the different results you are getting.

I think it's quite time that Dell starts distributing a 64bit AMPAgent. We no longer have 32bit systems at our company, and we have to think about these stupid workarounds all the time when configuring scripts and rules and so on.

Example : run powershell/vbs scripts that need to write in the 64bit registry. Because they are called by the 32bit agent, they will run in a 32bit context, unless you explicitly use the cscript/wscript/powershell.exe from the sysnative directory. If the agent were 64bit, these files and inventory rules would run in the right context all the time.

Are you forcing an update after setting up the rule with FileExists(C:\Windows\System32\dfsutil.exe)? Machines will only run the rule at the time of updating their inventory so if you aren't forcing an update or waiting for a long enough time that machines check in then you won't see the field populate in the inventory.

Another option to manage DFS is to use DFSUTIL.EXE, which is a command line tool. There are many options and you can perform almost any DFS-related activity, from creating a namespace to adding links to exporting the entire configuration to troubleshooting. This can be very handy for automating tasks by writing scripts or batch files. DFSUTIL.EXE is an in-box tool in Windows Server 2008.

If the above connection tests are successful, determine whether a valid DFSN referral is returned to the client after it accesses the namespace. You can do this by viewing the referral cache (also known as the PKT cache) by using the DFSUtil.exe /pktinfo command

By default, DFSN stores NetBIOS names for root servers. DFSN can also be configured to use DNS names for environments without WINS servers. For more information, click the underlined link to view the article in the Microsoft Knowledge Base:

Even when connectivity and name resolution are functioning correctly, DFS configuration problems may cause the error to occur on a client. DFS relies on up-to-date DFS configuration data, correctly configured service settings, and Active Directory site configuration.

First, verify that the DFS service is started on all domain controllers and on DFS namespace/root servers. If the service is started in all locations, make sure that no DFS-related errors are reported in the system event logs of the servers.

It is also worth checking you do not have any general networking issues on the server you are connecting from and also that there are no firewall rules or Group Policies blocking File and Printer Sharing!

It is recommended that one of the first things that you determine when tracking an access-related issue with DFS is the name of the underlying shared folder that the client has been referred to. In Windows 2000, there is a shell extension to Windows Explorer for precisely this purpose. When you right-click a folder that is in the DFS namespace, there is a DFS tab available in the Properties window. From the DFS tab, you can see which shared folder you are referencing for the DFS link. In addition, you can see the list of replicas that refer to the DFS link, so you can disconnect from one replica and select another. Finally, you can also refresh the referral cache for the specified DFS link. This makes the client obtain a new referral for the link from the DFS server.

With this you can check the configuration of the domain controllers on your DFS Server. It verifies that the DFS Namespace service is running on all the DCs and its Startup Type is set to Automatic, checks for the support of site-costed referrals for NETLOGON and SYSVOL and verifies the consistency of site association by hostname and IP address on each DC.

DFS lacks a central feature important for a collaborative environment where inter-office file servers are mirrored and data is shared: File Locking. Without integrated file locking, using DFS to mirror file servers exposes live documents to version conflicts. For example, if a colleague in Office A can open and edit a document at the same time that a colleague in Office B is working on the same document, then DFS will only save the changes made by the person closing the file last.

In terms of NetBios, the default behavior of DFS is to use NetBIOS names for all target servers in the namespace. This allows clients that support NetBios only name resolution to locate and connect to targets in a DFS namespace. Administrators can use NetBIOS names when specifying target names and those exact paths are added to the DFS metadata. For example, an administrator can specify a target \\dacmt\Users, where dacmt is the NetBIOS name of a server whose DNS or FQDN name is dacmt.local

You could blow away the whole DFS share and start fresh. That should fix the problem. Of course, if you run into errors deleting it, you might have to forcefully delete it, then use dfsutil.exe to clean up the left over registry entries.

The only DFS whitepapers I have seen are available from Microsoft or ITpapers.com, there may be more out there, but ITpapers is a good place to start (free registration req). I have not seen domain spanning specific articles, but I also haven't seen anything that would prevent your DFS from spanning parent/child domains.

How is your DNS namespace configured? All vanilla (AD integrated, KCC defined replication, etc.)? Or do you have any custom configurations there as well? Are you able to connect to the server\share from the remote directly (circumvention of the dfs namespace)?

A great way to troubleshoot is to check sysvol for your domain/subddomain. \\company.com\sysvol, \\branch.company.com\sysvol. What user groups do you have setup on your DFS root? Domain Users, Authenticated Users, or a custom group setup? For many issues, the sysvol and the dfs are a great comparison for troubleshooting, since they operate in a very similar manner. Permissions are generally important. I would give the root of the DFS authenticated users and domain users as a troubleshooting step, then work outwards. Establish as general permissions as you can on the dfs root. Make sure your file folder permissions are all in sync as well at every link location.

A. The DFS client has a list of known domains that is used to determine whether a Universal Naming Convention (UNC) path is a domain-based DFS root. If the first part of the UNC path matches a known domain name that the client has in this list, the path is assumed to be a domain-based DFS path. This list of known domains contains all domains in the client's forest and all domains trusted by the client's domain or forest. The default buffer for the list of known domains is 4 kilobytes (KB) (approximately 2,000 characters).

If the list of known domains exceeds 56 KB, DFS puts as many domains in the cache as it can until the cache reaches 56 KB. DFS then writes an entry with the ID 14536 in the system event log in Event Viewer to notify you of this issue.

When populating the cache, DFS gives preference to local and explicitly trusted domains by filling the cache with their names first. Consequently, by creating explicit trust relationships with domains that host important DFS namespaces, you can minimize the possibility that those domain names might be dropped from the list that is returned to the client.

Important: To make sure that clients can access link targets in other trusted domains or trusted forests, you must use DNS names for all link targets and configure DFS to use fully qualified domain names in referrals. For more information, see How to Configure DFS to Use Fully Qualified Domain Names in Referrals.

A. Yes, if you are a member of the Enterprise Admins group, you can configure FRS replication on a DFS link whose targets are in different domains in the same forest. If you are not a member of the Enterprise Admins group, permissions must be configured as follows:

If any of these permissions are not configured correctly, you will get an Access Denied message when you try to enable replication by using the Configure Replication Wizard in the Distributed File System snap-in.

The objective of this post is to provide a low cost high availability Disaster Recovery solution for Microsoft file services. Generally hosting the File Service on a Microsoft failover cluster is sufficient enough to provide high availability of user data. However, for an organization whose data availability is business critical or are using a VDI solution where user profile/data are stored on file servers, the file service should be available even if the cluster itself is offline due to a disaster in the datacenter.

In this scenario, we will require a two node windows failover cluster in production as well as disaster recovery sites to host the file service. Each cluster will be connected to their respective local SAN storage within their sites.

Shared folder configured on a Client Access Point will be used as a target folder for DFS Namespace. Since the Client Access Point can withstand cluster node failure, the Shared folder will be available even one of the cluster node is offline for maintenance.

We need to take this scenario to a further stage where the service can be available even when the whole production datacenter is down. A multi-site cluster (geo cluster) using SAN replication would be very expensive in terms of license cost and complexity in implementation. By tweaking the built-in replication feature (DFS-R) in Windows server Operating System, the above requirement can be achieved without any additional cost.

3a8082e126