Distributed File System for Simpler File Storage
An Active Directory Distributed File System (AD DFS) role is an often overlooked yet extremely valuable tool that any organization should seriously consider utilizing. It’s built right into any Windows Server OS and can be deployed with relatively little effort. As a role in Windows Server it needs only to be turned on through your server role management window. The real power, and work, comes when you start to fold your current file systems into this new DFS structure. Users can access multiple folders, stored on multiple servers, throughout your network from one easy-to-access namespace.
Benefits of a Distributed File System
- Easier for End Users – With DFS, your users no longer need to remember “H:” drives and “V:” drives and what goes where. All folders and file servers can be referenced under one virtual DFS Namespace simplifying the terminology when delivering instructions on how to find business documents and data.
- Easier to Manage – With a simplified snap-in management tool, configuring and managing your DFS is easier than you think.
- Simplified Role-Based Provisioning – With less of a dependency on drive associations based on user job roles you can simplify your new user/moved user provisioning. Rather than discovering who needs what drives you need only worry about who needs what security groups that govern access to the folders for their job.
- Reduce Network Load – With AD DFS replication you can make data global. Allowing your users’ machines to dynamically locate the closest DFS source for the files they wish to view.
- Reduce Overall IT Workload – DFS allows you to cleanup your login scripts, reduce the time it takes for machines to process to GPO’s, and eliminate user’s drives from becoming “disconnected” causing service desk calls.
Access multiple folders, stored on multiple servers, throughout your network, from one easy-to-access namespace.
Most organizations struggle with the idea of how to implement a Distributed File System. While every IT environment is different, it’s definitely worth the time and effort in the end. The following is an example of a recent project and how a Distributed File System was used.
Our client had a typical, segmented file system within their environment. Lots of servers spread across 4 different major sites serving up files to the entire organization. I was called in to do an SCCM implementation so I initially performed an assessment of the basics: Active Directory, Software Shares, Sites and Services, etc… Upon looking at their software files for application deployment I realized the perfect storm. 5 separate servers, utilizing different methods of replication, on distributed hardware (both physical and virtual), on distributed storage systems (array/non-array, redundant/non-redundant, backed-up/non-backed-up) and all in major need of de-duplication as each server had a vastly different set of data. They didn’t think this was the case but after discovery they were shocked to find that it was so.
Simplified Rollout Procedure
With the discovery done, I worked on a basic list of steps to perform in order to get them over to a Distributed File System.
- Lock down all write permissions. Put the data into a frozen state to stop any more drift.
- Develop a new standard for folder structure, naming conventions, file life-cycle, and a migration plan.
- Implement new storage spaces on the NetAPPs and build the AD DFS folder structure.
- Migrate data to new structure and instruct IT on new location, processes, and procedures.
- Decommission old file locations.
The project had massive success and was accepted with rave reviews from management and the teams involved. It reduced the overall footprint from the deduplication, allowed for some antiquated systems to be removed from the infrastructure and brought everything into the organization’s new standard for equipment and storage.
We learned, from this project, that we wouldn’t be able to move all the data into the Distributed File System at one time. But, with strategic planning, team buy-in, and some positive supporters, we were able to encourage a rapid adoption. By targeting organizational units one at a time, we were able to work closely with them to build a schedule that worked for them.
For further technical information I suggest the following sources.