Best Practices: Windows File Server Consolidation (Part 1 of 2)

Consolidation is seen as a top priority by most IT directors, but understanding of storage consolidation as it relates to file servers is low. In the first in a two-part discussion, we explore the benefits and obstacles of server consolidation projects, and explore the impact on users.

Windows file servers are often viewed as convenient storage systems at the workgroup and departmental levels. Historically, each organizational unit bought additional servers as the need for more storage grew, but found that keeping up with the storage management needs (data backup and recovery, disk and volume maintenance) wasn't easy. The total number of Windows file and print servers across an enterprise can far exceed that of Exchange, SQL Server, or Web servers.

Reducing the Total
Cost of Ownership

Reduce hardware costs

  • Fewer servers
  • Fewer storage arrays
  • Improve storage utilization
  • Fewer switch ports

Reduce software costs
  • Fewer Windows server licenses
  • Fewer backup software licenses

Reduce management costs
  • Unreliable backup/recovery on
    underpowered, legacy NT servers
  • Many servers to backup
  • Many servers to apply service
    packs and upgrades
  • More data to backup/restore as
    storage needs grow
  • Backup/recovery problems when
    user data is stored on desktop/laptop
  • High availability and disaster

The demands on the IT staffs are increasing, which increases the value of centrally managed file servers. A three-year economic downturn has made server and storage consolidation even more attractive. Also, as Microsoft is ending support for NT 4.0, enterprises are looking to migrate off NT 4.0. This means they need to collapse hundreds of decentralized Windows file servers into a few high-performance NAS file servers, NAS gateways, or Windows Server 2003 file servers.

Who Benefits Most?

IT operational costs have a direct impact on the bottom line of a business. The financial benefits, such as reducing capital expenditures and improving management efficiency, are driving investment decisions (see sidebar).

By relocating servers to fewer sites, reducing the number of servers, and merging data on to fewer servers and centralized storage devices, the hardware savings alone are significant. Servers with direct-attached storage are typically wasting as much as 70 percent of disk space: consolidations vastly improve the storage utilization rate and reduce the total storage capacity requirements.

By dramatically reducing the number of servers, the software savings are also significant from Windows server operating system and backup software licensing costs.

Lastly, analyst reports indicate that storage management expenses are three to five times an organization's capital expenditures. Simplifying the infrastructure reduces management overhead and complexity, making the total cost of ownership lower and improving ROI.

Applying data center management procedures to centralized storage management brings additional benefits: high availability and performance. Creating network home directories and shares provides a highly reliable and consistent backup strategy for users, and simplifies the user life-cycle management as each employee enters and exits a company or moves to another department. Capacity on demand becomes viable with the centralized storage-sharing model, eliminating the hidden costs associated with unmanaged storage and improving IT service levels.

Before Consolidation
Click to enlarge

Why Is This So Hard?

Migrating from legacy NT file servers and consolidating data to a new storage architecture takes considerable planning, and reconfiguration impacts users and applications. Corporate-wide Windows consolidation efforts could take a few years to complete.

Unlike one-to-one upgrades, consolidations are many-to-few upgrades that typically involve restructuring the Windows domain security. When upgrading from NT 4.0 domains and Windows 2000 mixed mode domains to Active Directory native mode domains, security groups that are no longer supported (such as local groups( need to migrate to domain local groups. Resetting permissions on files and folders, commonly known as “re-ACLing,” can be error-prone and time-consuming, especially when there are a large number of files, folders, and groups. Moving user and group accounts affect the permissions on resources originally granted to the source account, and references to moved accounts must be updated on all ACLs on resources across the entire network.

In addition to migrating data and associated security settings from the source servers to the destination servers, users and applications need to be switched from accessing the current environment to the new environment. Network shares accessed by drive mapped letters and UNC paths must be updated.

After Consolidation
Click to enlarge

As enterprises move from legacy Windows clients to Active Directory, many IT organizations choose to implement domain-based DFS to eliminate the need to reconfigure clients whenever share locations change. Microsoft recently enhanced DFS to remove the barrier to adoption, allowing clients to benefit from location transparency without converting the existing UNC namespace to the new DFS namespace. This enhancement greatly reduces the pain of migrating to the DFS namespace and facilitates file server consolidation.

Introducing new layers of infrastructure to support future requirements (such as Active Directory and DFS), while simplifying the existing infrastructure through consolidation have far-reaching implications. The number of Windows file servers installed corporate-wide is typically in the hundreds, and moving user and departmental shares into a consolidated environment affect client access to services in the tens of thousands.

Consolidation Strategy -- Minimizing User Impact

The overriding goal of implementing a complex consolidation project should be to minimize user impact while achieving the organization's business objectives.

Microsoft publishes excellent planning and implementation guides that are specific to consolidating and migrating file servers from NT 4.0. The process flow chart shows three key steps:

  1. Plan for consolidation and migration
  2. Establish the consolidated environment
  3. Migrate to the consolidated environment

As discussed in these documents, the third step disrupts client (users and server applications) access to services. Access to data at the old location must be restricted while moving the shares content, and then clients need to be reconfigured to access data at the new location. Coordinating these tasks to be completed during the scheduled maintenance window becomes challenging when there are multiple file servers to consolidate and the project affects many users.

Conventional file replication tools do not copy open files, so the destination shares content is not synchronized with the source. Tools that can perform differential copies only copy closed files that have changed since the previous run and repeat the process, but do not completely mirror the source shares content. Access to the source shares must be disabled until the final “delta” copy is completed.

After updating the permissions and attributes associated with shares, folders, and files, the original security identifiers (SID) need to be translated to migrate local groups. The translation rules depend on the design of the consolidated environment’s share structure and its domain architecture. Improper SID translation, including omission, will prevent users and applications from being able to access data at the new location.

The last major steps involve switching clients from accessing data at the old location to the new location. When shares are migrated, the UNC paths of the migrated files and folders change. Any users and applications that reference these UNC paths directly or indirectly through mapped drive letters (such as login scripts, user profiles, network places, shortcuts, application and OLE links) will be affected. Establishing a DFS root server enabled for consolidation roots enables retaining the legacy UNC namespace while transitioning to the DFS namespace, so that reconfiguration of users and applications is unnecessary.

Updates to DFS links do not take effect until the client cache is updated, so some users and applications will be accessing the old location during the transition period while others will be accessing the new location. If the source shares are disabled during this period, client access will be disrupted. Ability to synchronize changes between the source and destination bi-directionally will provide a grace period for changes to take effect and smooth out the transition.

In order to avoid lengthy downtime issues, these share migration activities must be coordinated in the proper sequence.