When Microsoft released Windows 95 nearly ten years ago, it included a brand new feature called the Windows Briefcase that would allow mobile users to carry cached copies of networked files with them as they traveled and then resynchronize those files at a later time. In Windows 2000, Microsoft enhanced the Briefcase feature and changed its name to Offline Files. In keeping with tradition, Microsoft has made changes to Offline Files in Windows Server 2003. Here's what's new.
The benefits of Offline Files
The basic idea behind offline files is that Windows keeps track of which files your users use the most often. When a user accesses such a file, Windows creates a local copy of the file on the user's hard drive. Traditionally, this feature has always been used in one form or another by business travelers, and for good reason.
There are two main problems with file access that always seem to plague business travelers, and offline files solve both of them. The first of these two problems is showing up at a meeting only to realize that you have forgotten to copy a critical file to your laptop. Obviously, offline file caching solves this problem because Windows caches recently used files and any files that you have specifically requested to be cached.
The other big problem that business travelers frequently face is that even if they do manage to remember to copy all of the files that they need to the hard drive on their laptop, they still have to remember to update the files on the corporate network if they make modifications to the local copies of the files while away from the office. This problem is also solved by offline file caching because when a mobile user reattaches to the network, Windows automatically compares cached files against files on the server. If a local file has been updated more recently than the version stored on the server, then the server is automatically updated with the most recent version of the file, freeing the user from having to remember to do this manually.
OK, so offline file caching can obviously be beneficial to mobile users, but what does offline file caching do for the rest of us? More than you might think actually. Implementing offline file caching on desktop workstations can dramatically increase your network's performance and reliability.
Let's look at the reliability factor first. Imagine that a user logs onto the network and uses Microsoft Word to open a file. Assuming that the folder containing the file is set to allow offline caching, the file is copied to the user's local hard drive at the time when the user opens the file. Now, imagine that the user is happily working on the document and one of the interns accidentally trips over a bunch of cords in the server room, taking the server containing the file offline.
The user working on the Word document can continue to work normally. The user might notice an icon in the taskbar indicating that they are working offline, but it is possible that the user might be oblivious to the crash. When the server comes back online then the workstations are automatically synched with the server and any files that have been modified since the server went down are overwritten with the new versions.
Keep in mind that the more recent versions of Microsoft Word do background saves that are designed to help users to recover their work in the event that a server goes down on them. However, Word's automatic document recovery feature, although helpful, is not perfect. I have always felt that it is much better to use automatic document recovery as a last line of defense rather than as a first line of defense, and with offline caching in place, your users may never have to rely on automatic document recovery.
OK, so offline caching helps those who are in the middle of working on a document when the server goes down, but it gets better. Imagine that our fictitious user finishes editing the Word document and is ready to move onto something else, but the server is still down. The user could easily edit another document as long as it is something that was recently used or has been requested to always be available offline. This is possible because the offline cache can store multiple documents.
It is even possible for the user to create a brand new document and save it to a network share. The share is visible to the user even though the server containing the share is down, because some of the share's contents have been cached. When the user saves the document, the document is saved locally. Windows will then automatically send the new document to the appropriate network share once the server becomes available again.
What about DFS replicas?
As you can see, offline caching gives users the ability to work through a server crash as though nothing ever happened. If you've been working with Windows Server 2000 or 2003 for a while, you might be saying to yourself that DFS replicas can do the exact same thing. It is true that DFS replicas can be used to make files constantly accessible, even during a crash. In truth, DFS replicas, if configured properly, work even better than offline caching when it comes to document availability. However, DFS replicas can only be deployed in Active Directory environments.
Believe it or not, there are a lot of organizations that still haven't deployed Active Directory. You will also need physical hardware and a Windows Server license for each DFS replica. This places DFS out of financial reach for smaller organizations. On the other hand, with a few exceptions, offline file caching can be implemented without having to make any major changes to your infrastructure and without having to spend any money.
Now that you have seen how offline file caching can be used to keep users working during server failures, let's talk about performance. With all of this file copying going on, it might seem as though offline file caching would diminish performance. However, the opposite is true.
When a user opens a file that is set up for offline caching, the file is copied to the user's offline files folder as it is opened. Now, let's assume that the user finishes working on the file, but decides to go back to the file later that afternoon. When the user attempts to open the file, Windows looks at the networked copy to check the file's date and time stamp. If the networked file is of the same version as the cached copy, then Windows will open the cached version rather than the networked version.
Why? Because Windows can read a file off of the local hard disk much more quickly than it can download the same file from a server. This gives the user the perception that the network has undergone a major upgrade to improve performance. The user will have no idea that the file is being read locally.
In a way though, using offline file caching really does improve performance. If frequently used files are being read from a local cache, then it means that they do not have to be downloaded. This frees up network bandwidth. More available bandwidth means that those who do need to download a file from a network server will see better performance.
File caching: The basics
Now that I have explained how your network can benefit from offline file caching, I want to take a moment and go over the basics. Offline file caching has some rather strange operating system requirements. The requirements are actually more stringent on the client than they are on the server.
On the client end, offline file caching is supported only by Windows 2000 Professional and by Windows XP. On the server end though, offline file caching is supported by any Windows operating system that uses Server Message Blocks (SMB). This means that someone could theoretically create a file share on a Windows 95 machine and, as long as the clients accessing the file share were running Windows 2000 or Windows XP, they could cache those files.
If you are worried about security though, then just make sure that no one in your organization is running Windows 95. After all, you can implement group policies that prevent users running Windows 2000 or Windows XP from creating share points on their local machines. If you are running Windows Server 2003, you can even prevent users from caching anything that you haven't specifically given them the authority to cache.
If administrators want to give users the ability to cache files, they can do so by going to the server containing the files, right-clicking on the folder containing the files, and selecting the Sharing And Security command from the resulting shortcut menu. This will open the folder's properties sheet with the Sharing tab selected. Click the Offline Settings button. This will reveal the Offline Settings dialog box, shown in Figure A.
|The Offline Settings dialog box allows you to control the level of caching the server will allow for a share.|
As you can see in the figure, the default setting is to only allow caching for files that users specifically request to be cached. You can change all of this though by selecting the All Files And Programs option. You can also select the corresponding Optimized For Performance check box for better performance. The last option allows you to disable file sharing for the folder completely.
Just granting permissions at the server though isn't enough. Windows 2000 and Windows XP are configured to disable file caching by default. The easiest way to configure offline file synchronization is to select the Folder Options command from Windows Explorer's Tools menu. When you do, you will see the Folder Options properties sheet. Select the Offline Files tab and you will see numerous options related to offline file caching, as shown in Figure B.
|The Offline Files tab allows you to configure the behavior of offline file caching.|
As you can see in the figure, most of the options are self explanatory. The tab contains options for enabling offline file caching and for automatically synchronizing at logon or logoff. You can even display a synchronization reminder at certain time intervals, create a desktop shortcut to the offline files folder, and encrypt the offline files for greater security. One option on this tab that definitely needs a little explaining though is the Amount Of Disk Space To Be Used For Temporary Files option.
This option allows you to choose the maximum amount of hard disk space that may be used by cached files. The default is 10 percent of your computer's total disk space. The way this works is that when the maximum size limit is reached, then the file that has been sitting idle in the cache for the longest period of time is deleted to make room for newly cached files.
Another thing that you need to understand is that this limit applies only to automatically cached files. A user also has the option of pinning a file. A pinned file is a file that the user requests to make available offline at all times. A user can do this by right-clicking on a file or folder and selecting the Make Available Offline command from the shortcut menu. The problem is that some users have a tendency to try to pin a high level folder containing tens of gigabytes worth of data in subfolders. This typically runs the workstation out of disk space in a matter of minutes.
If a user has been working with a file offline and then tries to synchronize a modified version with the network, then there is always a chance that the version on the network has also been modified. Windows is not capable of merging the changes, so users will have to make a decision. They can either keep one version and delete the other, or they can rename one of the files so that they have both versions on hand.
If you or your users are on the go a lot, then you need to know that the offline file caching process is not 100 percent reliable for mobile users. Recently I had to take a business trip to Las Vegas. Since I was going to be gone for a full week, I wanted to be able to take advantage of some of the downtime and work on some writing assignments that were coming due. Prior to my departure, I pinned one of my network shares so that I would have a cached copy of everything that I had ever written stored on my local hard disk.
To make a long story short, I got to the airport and my flight was delayed so I decided to get a little work done. I fired up the laptop and none of my cached files were on it even though I had performed a manual synchronization the night before. Although I looked desperately for my files, they were nowhere to be found, and I had no way of going back home to get them. Had my wife not been kind enough to burn my files to a CD and overnight them to me, it would have been a very unproductive week.
It's easy to look at a situation like this and assume that I must have made some sort of mistake when performing my manual synchronization. Granted, it is possible that I could have done something stupid during the synchronization although I saw the files synchronizing. It would be especially easy to make this assumption being that this was the only time that my offline file cache has failed me, except for one little detail. The Internet is filled with stories like mine from people who have had no trouble with offline files, but suddenly get left high and dry for no apparent reason.
Since this does sometimes happen, the best advice that I can give you is that if you plan on traveling with a laptop then it's a good idea to perform a manual synchronization, shut down your PC, disconnect from the network, and reboot to make sure that you still have access to your offline files.
While researching this article, I have found a few Web sites that hint at the possibility that this problem occurs less frequently if the user logs into the same domain as the cached files are located in. These same sites also suggested that occasionally logging in as a different user might trigger the problem. I can't tell you if this rumor has any merit or not, but I can tell you that the server which stores the files that I had attempted to cache prior to my trip is in the same domain as I was logging into, and that I always log in with the same account.
In spite of the occasional glitch though, caching files for offline use generally works well. It has been my experience that the benefits far outweigh the headaches most of the time.