Essential Windows Server 2008 R2 Features for Managing Your File Server Infrastructure

One of the first articles I wrote for Windows IT Pro—“Let’s Get Organized: File Server Basics” (InstantDoc ID 95354)—discussed some time-tested methods for getting the most out of your file server. If your data is scattered all over your network, or your file system security is all over the place, or your folder structure is a mess, that article provides some good ideas for organizing your file server. Now that Windows Server 2008 R2 has been out in the wild for some time, I thought I’d revisit this topic, update it for Microsoft’s newest OS, and talk about some of the great tools you can use for migration and file-server management.

 

First, Migrate!

Before you can even get started using your new Server 2008 R2 server, you need to migrate your data from the old server. Don’t underestimate this process. I’m always surprised by how many administrators don’t take the time to plan their migration. Many servers have hundreds of gigabytes—if not terabytes—of data that can take a long time to copy from one server to another. If you use drive mappings (most companies do), you’ll need to change them to reflect the new file server name (unless you name it the same as the old server). You also need to consider that many users have created their own shortcuts to the UNC path (\\Server\Share), and that you’ll invalidate all their links if you change the name of the file server. These are just some of the challenges you’ll face when your shiny new server arrives on your front doorstep.

Fortunately, you don’t have to go it alone. The File Server Migration Toolkit (FSMT) is a free Microsoft tool that helps you migrate any Microsoft file server to Server 2008. You can find it at www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b. The FSMT comes in both 32-bit and 64-bit versions, so be sure to download the correct file. After you download the 1.3MB file, you’re ready to test it in your lab. I highly recommend kicking the tires on a non-production server before going for broke on something as important as your company’s files.

The application walks you through the complete migration process, from setting up shares on the new server to ensuring that all the data has been copied before going live. It even shuts down the old file shares when the time is right. Figure 1 shows you what this process looks like.

 

 

 

One extremely cool FSMT feature is the Distributed File System (DFS) Consolidation Root, which lets your users continue to use their old UNC paths even after the old server is long gone. For a walkthrough of a sample migration, check out the sidebar "A Simple File Server Migration."

Who’s Using the Storage?

In the past, setting up a file server meant one thing: “Build it, and they will fill it up.” The same is true today. Users will still manage to take all the space on the server if you let them. Unfortunately, you have no real idea of the types of files that are stored on your drives. To get that “look” into your file server that you’ve always wanted, check out the File Server Resource Manager (FSRM).

In just a few minutes, you can have reports about exactly the kind of data that’s stored on the file server—for example, what kind of files (e.g., documents, movies, music), where the data is located, and who owns the data. A few examples of the built-in HTML-based reports are Duplicate Files, Large Files, Least Recently Accessed Files, Most Recently Accessed Files, and Files by Owner. Figure 2 shows an example of the kind of reports that you can generate.

 

 

 

For example, to generate a report on duplicate files, you'd walk through these steps:

1. Open FSRM.
2. Right-click Storage Report Management, and choose Generate Reports Now. (You can schedule this procedure by choosing Schedule a New Report Task.)
3. Add the folder or partition that you want to analyze.
4. Click Duplicate Files.
5. Choose the report format that you want (e.g., DHTML, HTML, XML, CSV, Text).
6. Click OK to generate the report.

The report is neatly laid out, displaying the duplicate files in descending order with the larger offenders at the top of the page.

FSRM also lets you set quotas. And unlike Windows Server 2003’s Disk Quota feature, Server 2008 R2’s implementation lets you set quotas on individual folders instead of the entire volume. The settings are pretty granular, including distinctions for hard and soft limits. Setting a hard limit prevents the user from using more space than he or she is allowed. A soft limit is only a “warning” and doesn’t actually prevent the user from using more spaced than allocated. Multiple notification methods—including email, event log entry, custom report, and a script of your choice—keep you informed about the quota status. The quota section is by far the easiest area of FSRM to understand and configure: You simply click Quotas in FSRM, choose Create Quota, enter in the path (either an entire volume or a specific folder), select a predefined quota template, and click Create. If the built-in Quota Templates don't meet your needs, you can create your own in the Quota Template area.

Another new feature worth mentioning is File Screening Management, which lets you block certain types of files from being stored in a specific folder. For example, the marketing department probably has a business case for storing movies and videos on its departmental folder. Other departments, however, might not have that same business need, and preventing them from storing such large files on the server can save gigabytes of space. Server 2008 R2 comes with 11 predefined, built-in File Groups, but you can create your own if the file type you want to block isn’t listed. Some of the built-in File Groups are Audio and Video Files (37 file types), Executable Files (20 file types), and Image Files (18 file types). Figure 3 shows a few of the provided File Screen Templates.

 

 

 

The FSRM installation process is quick and easy—once you find the silly thing. You install the application from Server Manager, Role Services near the bottom of the page. (Don’t confuse Role Services with Roles at the top of the screen.) When the installation is complete, you can find the Microsoft Management Console (MMC) FSRM snap-in under Administrative tools.

How Important Is the Data?

All files have levels of importance, and some need to be handled a certain way. Unfortunately, the only ways to differentiate between files have been the file type (by extension) and the date they were last accessed. This limitation severely affects your ability to manage files based on their actual usage. Wouldn’t it be nice if you could ensure that files with personal data were stored on an encrypted drive? Wouldn’t you love to ensure that your most important files are stored on high-availability storage?

The answer lies in Server 2008 R2’s File Classification Infrastructure (FCI) The FCI process isn’t exactly intuitive, but once you’ve played with it for a while, it starts to make sense.

The first step is to create one or more Classification Properties. These can be confusing the first time you set them up, but essentially they’re the “tag” you’ll place on a file. For example, I can set a level of Confidentiality as either Low, Medium, or High.

Next, you create a rule that defines exactly what each level of Confidentiality means. In my hypothetical example, I want to make sure that all files dealing with NASA’s Space Shuttle are kept secure. So, I can create a rule that marks any file containing the word “shuttle” as Confidential; High.

The final step in this simple example is to create a task that acts on the files that fall within a Classification Rule. I can create a task that moves files that are Confidential; High (those with the word “shuttle” within the text of the file) to a more secure location. You could set up a similar process for files that contain the United States Social Security Number (SSN), or even for files that haven’t been accessed for a specified amount of time.

Moving the file is just one of the actions that can be taken on a file that meets the classification criteria—as long as you’re versed in scripting. The plan is that Microsoft and even third-party vendors (e.g., SAN manufacturers) can tap into the FCI API. In the meantime, you’re a bit limited.

 

Clean Up that Clutter!

Access Based Enumeration (ABE) is a relatively new technology in the Microsoft world, but it’s one that’s been around for quite a while. I can still see the puzzled look of those Novell administrators when I told them that my users could see (but not access) folders that they didn’t have permissions to. It wasn’t until a special out-of-band download for Windows 2003 that this feature came to Windows file servers.

What exactly is ABE? In short, ABE hides folders that users don’t have at least Read access to. Figures 4 and 5 show a simple before-and-after example of how ABE can clean up your file server and make it easier for your users to navigate through Windows Explorer.

 

 

 

 

ABE was available for Windows 2003 only via a separate download. But Server 2008 includes ABE and is ready to go out of the box. You don’t have to download it, install it, or even enable it. Folders that are shared are ABE-enabled by default. If you decide that you don’t want to use ABE on a particular folder, you can disable it on a share-by-share basis in Server Manager. Once Server Manager is open, expand Roles, File Services, Share and Storage Management. Choose the share for which you want to disable ABE, right-click it, and choose Properties. Click Advanced, then clear the Enable access-based enumeration check box.

 

Go Forth and Organize!

You’d think that serving up files would be the least of our worries in today’s high-tech server rooms. But as data stores get bigger and regulations get tighter, we need to learn to use the built-in tools that can make our jobs easier. If you know of a server that’s completely disorganized, try the techniques I discussed in the first article, then enhance what you offer your users by using these new, powerful Server 2008 R2 features.

 

A Simple File Server Migration

Your first step in a file server migration would be to set up the DFS Consolidation Root:

1. Rename the source (old) file server. Microsoft recommends adding _ret to the end of the server name, but an underscore isn't a legal hostname character. To keep it simple, I recommend adding a –r to the end of the server name. Do this over a weekend when nobody will need the server.
2. Start the DFS Consolidation Root Wizard.
3. Enter the name of a standalone DFS server.
4. Enter the name of the folder that will hold the root folder (e.g., C:\Roots).
5. Enter the original name of the old file server and the name of the new file server.
6. Read the dialog boxes, and click Next through the rest of the wizard.

When a user tries to connect to \\oldfileserver\share, he or she will be sent to \\oldfileserver-r\share

If you get halfway through and realize that you've misconfigured the DFS Consolidation Root (trust me, it’s easy to do), you’ll need to use the Dfsconsolidate command:

dfsconsolidate /DeleteRoot /OriginalName

After the DFS Consolidation Root has been configured, you’re ready to migrate from the old server to the new server. Simply start the Microsoft File Server Migration Wizard.

1. Select New to start a new migration project.
2. Enter a name and location to save the project (keep the defaults if you wish).
3. Enter the name of the DFS root server that you used to create the DFS Consolidation Root.
4. Choose the source server. (The server you renamed with an -r at the end should be listed here.)
5. Enter a location where you want the new shared folders to reside. You can choose the root of a data drive.
6. You’re now ready to start the migration process. Begin by choosing the share(s) that you want to migrate.
7. After the migration wizard verifies the settings, the next step is to copy the files from the old server to the new server. The migration tool takes care of this step for you, but be mindful of the amount of data that you have. If you have hundreds of terabytes of data, you probably shouldn’t start this process on a Sunday night.
8. When the data has been copied, you’re ready to finalize the process. The old shares will be disabled on the old file server, so be sure you’re ready before proceeding.
9. As soon as the process is final, you can shut off the old file server.

Now, when users connect to the old server's UNC path, they'll be automatically connected to the new file server. To the user, everything looks perfectly normal; only you will know about your sleight of hand.

I've found the DFS consolidation feature a bit finicky, so again, be sure to test it before trying it in a real migration. You don’t want to find out the night of the migration that some obscure feature isn’t working for you or your specific situation.