We are a mid-sized company wanting to get our server situation to a point where we can take a given server ("server1") down at will for maintenance (or in the event of its crashing) and still have the data automatically accessible to users on at least one other server ("server2").

Is Microsoft's DFS (distributed file system) a good way to do this?

Are there other options that might make more sense than the DFS route?

Our bottom line is we don't want data to become unavailable to users should the server crash, or should its performance suddenly deteriorate; and we want the freedom to take a server down during business hours for maintenance, replacement, etc.

It's an awesome way to go I think. The only issue is the bandwidth usage starting it up. If you own Windows Server, you have the ability to do this. It was recommended to me by a few third party network audit companies as well.

DFS is the way to go. If you just use DFS-Namespaces with DFS-Replication, that will work the way you want it to. If you need users to be able to access the files in the event that one server is down then you will need to use them both. Namespaces will allow for the auto-routing to the proper server and Replication will allow for the files to be located on multiple servers in case one is down.

There are actually a few caveats to think about is using DFS Replication and making all replication point active targets.

If the DFS targets will be in the same site (same local network), consider disabling one of the target servers and managing it manually. Otherwise you may encounter issues with contention on file usage. If the DFS target server are in seperate sites then this isn't as big of an issue but still can be a issue.

For example, we had instances where users were connected to two seperate servers (dfs targets) in the same site and they opened a shared excel or access file then made updates, the last write 'won' and the first user that saved lost their data.

That said, even in th same site, you can just manually manage which targets are enabled to still give you the end effect of an HA configuration with replicated fle stores. Although duplicating local storage has a cost, it's generally significantly cheaper than shared storage and clustering since generally clustering requires more expensive OS SKUs and a SAN architecture.

Tony6900, Keeping data on a NAS device doesn't solve the single point of failure issue.

Something to watch with DFS - if you keep two copies live and available of a document(s) that change frequently then both can can (and in my experience, do) change at the same time and one set of changes gets lost - can cause hell for users. This is even more the case if you have multiple sites

Keep only one copy online but you can quickly switch servers if the live box goes down - will save much grief - I still have the scars...

If the DFS targets will be in the same site (same local network), consider disabling one of the target servers and managing it manually. Otherwise you may encounter issues with contention on file usage. If the DFS target server are in seperate sites then this isn't as big of an issue but still can be a issue.

For example, we had instances where users were connected to two seperate servers (dfs targets) in the same site and they opened a shared excel or access file then made updates, the last write 'won' and the first user that saved lost their data.

That said, even in th same site, you can just manually manage which targets are enabled to still give you the end effect of an HA configuration with replicated fle stores without the expense associated with shared storage and clustering.

Tony6900, Keeping data on a NAS device doesn't solve the single point of failure issue.

True, it doesn't address the single point of failure for the DATA. My interpretation of the OP was that he was concerned about maintenance on "server1" and "server2". Are the servers in question dedicated file servers? If so, then my response really doesn't make much sense and I stand corrected.

My experience with DFS was similar to what you described above in your example. The biggest factor with scrapping it was one of our applications (Revit) that actually knew which physical server it was opening a file from, and would not open a file correctly if the file/share was on the other server. Even if the drive was mapped to \\company.com\share. In the end it wasn't worth the hassle or the slowness, much less the whining from the users.