Fileserving very often is a much underestimated part of Terminal Server environments. Improperly configured fileserving components can wreak havoc on your performance. In this two-part article we will explore fileserving in Terminal Server environments and how you can make sure that you get the best performance out if it.

Introduction

Fileserving has been around just as long as Windows has. In fact, fileserving is one of the main reasons why we started to create networks in the first place back in the day: to share information and resources. Well, sharing files is a perfect example of this. Of course, fileserving has come a long way since the beginning but the basics are still the same, something that is illustrated in the names that Microsoft still uses today for their fileserving components: lanmanserver and lanmanworkstation. Lanman, LAN Manager, dates all the way back to when Microsoft did OS/2 and was first designed to provide connectivity between DOS and OS/2 Clients and OS/2 LAN Servers.

Fileserving Basics

Fileserving in Windows and other environments, such as Novell, are a classic example of a Client-Server mechanism. In Windows, the client side is almost always enabled since networking (authenticating over a network) without it is next to impossible. The client side is, not surprisingly, the "client for Microsoft networks". The corresponding Windows service is the "workstation service".

As for the server-side: all you have to do to become a file server is, well, share a file. My mom can do that (in fact she does). Heck, any old Windows 3.51 workstation can be a File server. Depending on your version of Windows, enabling "file and printer sharing" or something similar is all you need to do to make your server is a file server. The corresponding Windows service is the "server service".

This is one of the main reasons why the importance of fileserving is underestimated: it's so easy and there's no "guidance" (no configuration wizards, documentation or anything of the like). Usually when you gear up a server Microsoft provides more than enough guidance. For example, if you're setting up a DNS Server, Windows helps you out with wizards and all kinds of help files and documentation.

This isn't the case with fileserving.

So, on the one hand it is very easy to "create" a file server but on the other hand there is an obvious lack of relevant documentation and configuration/tuning tools. As an added bonus, a file server is almost always present in any Windows network.

All this together is a potential recipe for disaster.

Shared Folders Snap-in

When you share a file it shows up in one of the few tools that Windows has for managing file servers: the "Shared Folders" snap-in.

This is a screenshot of a dummy file server that I set up. There are no shares defined except for the default ones. If you want to, you can read more about these default shares and how to disable them here. I'm sure that the amount of shares you have on your company file server is much more. Probably when you go to check them out, you'll find some shares that aren't even supposed to be there (any more). That's a security risk right there, but that's a whole different story.

The "Sessions" section tells you which users have how many sessions to your file server, how long they've had those sessions and how long ago that session was active (idle time).

Finally, the "open files" section, really gives an idea of the load that the file server has. Here, all open files are listed. Go ahead and take a look. If you have an environment has a decent amount of shares and drive mappings then you'll see quite some action going on in this window. This window tends to get cluttered very soon if there a lot of open files. Also notice the "# Locks" column. This is particularly interesting if you're troubleshooting files that cannot be opened anymore because they're in use.

More Fileserving

Maybe you're thinking, what's the whole fuss about? You might say, on average my users write something to their home drive perhaps 10 times a day. And maybe they create 2 files in their departmental directory per day. This is where a common misconception is.

There's a lot more to fileserving than just plain file shares. A lot more. For example:

Profiles
If you use roaming or mandatory profiles located on your file server, every single time a user logs on or off a terminal server or a workstation, data is being copied back and forth between the file server and the terminal server/workstation. Especially when your roaming profiles are large, this can severely strain your file server.

Application (Configuration) Files
You would think that by now all applications would have evolved into applications that write their configuration data to the registry. Unfortunately there's still a truckload of applications out there that store their settings in .ini files. That's bad. It gets even worse when these configuration files are stored on a network share. The bits really start hitting the fan when that particular application polls that .ini file once every five seconds. For example (older versions of) Lotus Notes are notorious for doing this. Also be on the lookout for files like application cache files or files with similar functions. In fact, be on the lookout for all files that are accessed excessively, no matter if it's read or write.

Folder Redirection
Introduced in Windows 2000, folder redirection enables you to redirect certain profile folders like My Documents, Desktop and Start Menu, Application Data and others, to a network share. My Documents is generally redirected to a file share for obvious reasons. However, you should carefully consider if you really want to redirect any other folders. Especially redirecting Application Data could increase the load on your file server tremendously. This is because modern applications store just about everything they cannot store in the registry, in the Application Data folder. If for every read or write the application has to traverse the network to the file server you can imagine what this will do to your performance.

Printers
It isn't called "file and printer sharing" for nothing. Yes, printers are accessed via the same mechanism as files are (actually the redirector handles a lot more tasks but that's beyond the scope of this article). So when you thought it would be a good idea to make the company file server double as a print server, maybe it wasn't. Although it's not uncommon to have both the file server and print server role on the same server, remember that a decent sized network printing can severely strain your server. Specifically spooling activities, depending on the size and frequency of print jobs, can put quite a load on your file server.

The Terminal Server Factor
When you put these factors all together it's much easier to see why a File server could be a bottleneck. Imagine every user has their roaming profile, home directory, several shares, remote application configuration files and redirected application data. 

Now apply the Terminal server factor: multiply the resources that the user requires by the number of users on that particular Terminal Server. When you do this, it becomes more obvious why most of the performance issues relating to fileserving aren't with the server but with the client. The client in this case is the Terminal Server. Sometimes even a Windows server operating system (by default) isn't geared up to handle these kinds of loads.

Conclusion

In this article we have taken a look at what fileserving for Terminal Server environments is comprised of and why it can become a bottleneck.

In part two of this series we'll discuss what you can do to determine if you have fileserving performance problems and what you can do to solve these problems.

This article was previously published at MSTerminalServices.org.