Multiple names for one computer - Consolidate your SMB file servers without breaking UNC paths
Overview
This blog post covers a few different ways to consolidate multiple SMB file servers and keep exposing the consolidated file shares under the old share paths.
Scenario
Let’s say you currently have 3 file servers named file1.contoso.local, file2.contoso.local and file3.contoso.local and you want to consolidate them into a single Windows Server computer called cfile.contoso.local. It’s simple enough to use a tool like ROBOCOPY or the File Server Migration Tool (FSMT) to copy your shares and files over to the new box.
You can get additional information about FSMT at the Microsoft File Server Migration Toolkit web page. You can also check my blog post: Microsoft File Server Migration Toolkit 1.2 available as a free download.
The problem here is that users and applications will be unable to use the old server names, like \\file1\Orders\Order1.doc. After the consolidation, that path needs to be changed to use the new server name, like \\cfile\Orders\Order1.doc. However, there are ways to avoid this issue and show the shares under the old names, allowing the old UNC paths to continue to work unchanged.
Option 1: Static entries in DNS
If you use static DNS entries for your file servers, it’s easy enough to simply update the DNS entries for the old file servers (after your old servers are retired), pointing to the IP address of the new server.This means that you would have multiple DNS “A” records (A stands for address) all pointing to the same IP address, which point to the new server.
This is a simple enough solution if you use static DNS entries. You can use the DNS Management MMC to edit the zone, or you can use the DNSCMD command line tool. For instance, assuming your DNS server is at dc1.contoso.local and the IP address of the cfile.contoso.local computer is 192.168.1.11, you could use:
DNSCMD dc1.contoso.local /RecordAdd contoso.local File1 A 192.168.1.11
DNSCMD dc1.contoso.local /RecordAdd contoso.local File2 A 192.168.1.11
DNSCMD dc1.contoso.local /RecordAdd contoso.local File3 A 192.168.1.11
You can find more information about this at the TechNet page about hot to Add a host (A or AAAA) resource record to a zone.
Please note that this option will not work with Kerberos authentication, so this is not a recommended solution.
Option 2: Alternate Computer Names and Dynamic DNS
Another way to do this, if you are running Windows Server, is to add alternate computer names to your new server (after your old servers are retired). This can be done easily by using the NETDOM COMPUTERNAME command.
This command, which works only for Windows Server, allows you to add more names to a computer, in addition to its primary names. You can see details on how to use the command at the TechNet page about Netdom Computername.
For instance, if the domain in the scenario example is contoso.local and the full FQDN for the file server was CFILE.contoso.local, you could add the other names with:
NETDOM COMPUTERNAME cfile /ADD file1.contoso.local
NETDOM COMPUTERNAME cfile /ADD file2.contoso.local
NETDOM COMPUTERNAME cfile /ADD file2.contoso.local
IPCONFIG /registerdns
The last command makes sure the alternate names are properly registered with your DNS server, where other computers in the domain will find it. To check all the names of the computer, primary and alternate, you can use the command:
NETDOM COMPUTERNAME cfile /ENUM
The information about the alternate computer names are kept in the registry, as shown at the TechNet page on DNS Registry Entries.
Option 3: DFS Consolidation Roots
While these first 2 options can preserve the old UNC paths, they do change the original behavior of the 3 file servers. Each one of the 3 used to have a specific set of file shares, but the resulting consolidated file server and each of the three alternate names will have a single set which merges all the original shares.
This might actually be a side effect you welcome or at least can tolerate, but maybe you are required to preserve the exact original behavior, with each of the original names showing a precise subset of the shares. This might be especially troublesome if there were different shares by the same name on the three original servers. Merging them might bring additional trouble, even conflicting file paths.
You can overcome this by using a feature called DFS called consolidation roots. This feature in DFS-Namespaces allows you to map each of the many server names to specific namespaces. This way you can configure exactly what shares should show under each old name. In our case, in addition to having DNS point file1, file2 and file3 to the address of cfile, you would create three namespaces called \\cfile\#file1, \\cfile\#file2 and \\cfile\#file3 and populate them with the right links to the location of your shares.
The FSMT includes a Consolidation Root Wizard that facilitates creating these special types of standalone namespaces. You can get the toolkit from the download page for the Microsoft File Server Migration Toolkit 1.2. You can also learn to how create the consolidation roots manually at the support page about the Distributed File System update to support consolidation roots in Windows Server 2003.
Option 4: Virtual Machines
Another method that’s becoming increasingly popular is using virtualization to consolidate your file servers. Instead of using a new single file server, you create a new single server running Hyper-V with 3 virtual machines each running a file server. In that case, you can preserve the original names (and even the same IP addresses) without having to keep the old hardware around. While that might lead to more machines to manage, that will make your migration much simpler.
System Center Virtual Machine Manager includes the tools to migrate your physical machines to virtual machines (commonly referred to as P2V). For details, see the TechNet page on P2V: Converting Physical Computers to Virtual Machines in VMM. You can also add Failover Clustering to make your virtual machines highly available.
Option 5: Failover Clusters
Speaking of high availability, you have another option using Windows Server Failover Clusters. Consolidated file servers usually can use the extra availability, since you do end up with “many eggs on the same basket”. The process was greatly simplified in Windows Server 2008 and forward, and you can find on Technet a Failover Cluster Step-by-Step Guide: Configuring a Two-Node File Server Failover Cluster
Clustered file servers are created in a way that includes assigning a specific name and IP address to each file service or cluster group. You can use that ability to create multiple names, each with a specific set of shares, potentially mimicking the original configuration of your old file servers.
Starting in Windows Server 2008, file shares are scoped to a specific name, so you naturally get the different sets of shares associated with their specific name, even if they are hosted on the same cluster node. This is explained in detail in this blog post about File Share 'Scoping' in Windows Server 2008 Failover Clusters.
Option 6: Scoped Shares
Speaking of scoped shares, they are another way to address the issue of having different shares depending on the name used to get to the file server. These would work on a standalone file server (not clustered). However, there are no command-line tools or GUI tools to create scoped shares on a standalone file server.
If you are a developer, you might be willing to try create these scoped shares yourself calling the NetShareAdd function. In that case, you need to use level 503. See the remarks on the link for additional information, including the need to use the NetServerTransportAddEx function.
Conclusion
I hope this post has helped you understand your options for consolidating your file servers and keep your old UNC paths in the process. As usual, you should test any procedures in a test environment before deploying it in production. Now let's get started with the planning for those consolidation projects.
Comments
- Anonymous
January 01, 2003
Multiple Names for a File and Print Server Running Windows Server 2008 R2 - Anonymous
June 05, 2010
The comment has been removed - Anonymous
June 09, 2010
Nice post! I was writing about the same subject but youdid it quicker and better!BTW, you should mention that when using option 2, the NETDOM command will also ake care of registering the appropriater Service Principal Names in AD so you won't break Kerberos authentication working this way while with option 1, you'll have to register them manually. - Anonymous
June 27, 2010
HelloAs far as I know you need to do it in order to make option 1 and 2 working :support.microsoft.com/.../926642Laurent - Anonymous
May 04, 2016
Option #1 did not work for me on newer 2012 servers. It refused the connection. Had to use NETDOM method, otherwise the server will not allow it in. - Anonymous
March 05, 2017
The comment has been removed - Anonymous
September 02, 2017
Please note that option 1 is not working with SMB3