Using DFS for Software Installationby Mitch Tulloch, author of Windows Server Hacks
The Distributed File System (DFS) component of Windows Server 2003 is a powerful tool that can ease the task of deploying and maintaining applications using Group Policy's Software Installation feature. DFS allows you to create a virtual tree of shared folders that maps to actual shared folders located on different servers throughout your enterprise. From the perspective of ordinary users, DFS makes all shared folders appear to be located on a single shared volume, making it easier for them to find resources on the network. And from an administrator's perspective, DFS eliminates the worry of having to relocate shared resources when volumes fill up on file servers, something that can create headaches when applications are deployed using Group Policy.
Here's a simple example to illustrate the kind of problem that can arise and how DFS can easily help resolve the situation. Say you have a midsize company of 250 users and you've deployed Microsoft Office using the Software Installation feature of Group Policy. Typically this means you've run Setup.exe for Office in administrative install mode using the
/a switch, which unpacks the .cab files for Office into a shared folder you specify; for example, a share named OfficeInstallFiles on file server TEST220. Then you create a new Group Policy object (GPO) and configure a Software Installation policy that assigns the Windows Installer Package (.msi file) for Office to the computer accounts residing in some organizational unit (see Figure 1). The next time users whose computers reside in that OU restart their machine, Office will be installed on their computer automatically. As Gregor (the character played by Stellan Skarsgard) said in the movie Ronin with Robert De Niro, "So far, so good."
Figure 1. Software policy to deploy Office without DFS
Everything is working fine until one day you need to deploy a Service Pack for your Office installation. Because you performed an administrative install of the Office files onto \\TEST220\OfficeInstallFiles, you can simply integrate the Service Pack onto the original Office install files, and then the next time the users reboot their machine, the Service Pack will be applied. But when you try to integrate your Service Pack onto \\TEST220\OfficeInstallFiles, you suddenly discover that there's not enough room left on the volume where this shared folder is located. So you create a new shared folder on a different file server that has more room on one of its data volumes, and you move your Office distribution point to this new shared folder. Then you open your Office installation GPO and try to edit your existing Software Installation policy to point to the new share instead of the old one; with consternation, you discover that this is not possible. All you can do is delete your old software installation policy and create a new one. Unfortunately, deleting your old policy means that the next time your users reboot their machine, Office will first be uninstalled before it is reinstalled from the new distribution point. Not only will this take more time, but users will also lose their current customization settings for Office and will complain loudly.
How could you have avoided this conundrum? By using DFS, of course! Before you deploy Office (or any other software) using Group Policy, create a new DFS root on your network and create a DFS link to the shared folder from which you are going to deploy Office; in the above scenario, this is \\TEST220\OfficeInstallFiles. For example, to create a domain-based DFS root for the forest2.com domain, you would open the DFS console and right-click on the root node to start the New Root Wizard. Then proceed through the wizard, selecting the domain root option and specifying the server that will host your DFS root. Type a name for your root and a description (Figure 2), and finish the wizard by specifying a shared folder for your new DFS root. A good tip here is to create a new hidden share ahead of time for your DFS root. This can be done by appending
$ to the share name; that way, users won't be able to browse the DFS root directly using My Network Places.
Figure 2. Creating a new DFS root named \\forest2.com\Resources$
Once you've created your new DFS root, you can create a new DFS link that maps to your \\TEST220\OfficeInstallFiles share. To do this, right-click on your new DFS root in the DFS console and select New Link, and then specify a name for the link and the UNC path to the existing share (Figure 3).
Figure 4 shows the resulting DFS root with a DFS link under it to the Office install files.
Figure 3. Mapping a DFS link to the Office install share
Figure 4. DFS name space for installing Office
Now open your Office installation GPO and create a new Software Installation policy that maps to the virtual DFS path to the Office install folder. This virtual path will be \\forest2.com\Resources$\Office, and the resulting policy is shown in Figure 5.
Figure 5. Software policy to install Office using DFS
Now if you run out of disk space on the volume where your OfficeInstallFiles share is located, you can create a new share on a different volume (or even a different file server), move your Office files there, and update your DFS link to point to the new shared folder. To do this, right-click on your DFS link and select New Target, and then specify the UNC path to the new Office install share. Do not configure DFS replication, however, since you've already moved the Office files manually. Then delete your old target, and your DFS link is updated to the new location.
Now, from the perspective of your clients, the Office installation files will still be in the same (virtual) location, because they are referenced using DFS referrals instead of direct UNC paths. In other words, you can continue to use your existing Software Installation policy for upgrading and maintaining software that has already been installed on your clients.
Final Tips: For a more detailed walk-through on how to set up DFS, see this article by my colleague Andrew Tabona on WindowsNetworking.com. And for tips on creating MSI packages for deploying custom applications using Group Policy, see this article and other articles by me on the same site.
Return to the Windows DevCenter.