Dfsutil.exe Download

[Gerald Weiß]

Oddlywhen 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.

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.

I needed 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:

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.

If both targets are enabled, there is a chance that users start writing into different locations overriding the target priority, this causes DFS Replication service to encounter conflicting data and sharing violations.

Disabling one of the folder targets leaves only one target enabled in the namespace ensuring that the users will always hit on that folder target, the other target folder will not have any SMB sessions established from end users.

In ideal working condition, users are always connected to the shared target on production site, the data will be replicated to the shared folder in DR site through DFS-Replication configuration. If the production datacenter is down, the target share in DR site needs to be enabled and whenever users access the folder in the DFS namespace, they will be redirected to the active target share in DR site.

The enabling of standby target share can be automated using File Services Management Pack for Operations Manager to have a smooth and automatic failover of namespace folder. The File Services Management Pack for Operations Manager, monitors the status of production Target Share and through a remediation task, it enables the standby target share automatically.

As per the above mentioned Microsoft support policy for a DFS-R and DFS-N deployment, even if you enable only one folder target at a time, configuring one namespace folder to have multiple folder targets is not supported. In such case, just delete the secondary folder target (do not delete replication) and use dfsutil.exe target add command to create link to the secondary folder target.

About Jayachandran PK

My passion is for Microsoft technologies and how if properly implemented, they can provide actual value for an organization especially in the field of infrastructure, virtualization and system monitoring.I work for the biggest Microsoft partner in Kuwait, specialized in project consultation and implementation services for enterprise clients.When I'm not at work, I try to contribute back through a charitable organization dedicated to prompting cultural values of Kerala. In my free time, I dabble in gardening and am also an avid solar power aficionado.

3a8082e126