Index.dat: To move, or not to move...
With the ever-decreasing cost per megabyte of storage, many more organizations today are increasing the amount of user data to be stored in a central location. Whether for better administrative control, security or as a means to keep the client workstations lighter and more energy efficient, application data is being redirected to remote disks. For most applications, there is little repercussion to this approach. However, Internet Explorer performance and stability can be impacted greatly from such a configuration.
Internet Explorer utilizes a number of caches for user browsing data. The most common of these are the Temporary Internet Files, History and Cookies folders. Each contains a reference database, index.dat, which allows Internet Explorer to keep track of the location of individual pieces of browsing data and other relative attributes of that data, such as expiration and last-accessed dates. It should be fairly evident that these indices are constantly being read from and written to during the course of a browsing session. Each object being requested has to be looked up to determine if it exists and if so, its attributes have to be enumerated. If not, the client must download a copy of the object, place it into the appropriate cache and then update the index with its location and applicable attributes.
With all of this ongoing checking and updating, one would assume that Internet Explorer would be in a state of constant disk use. However, through the use of memory-mapping techniques and delayed-write file operations, the negative performance impact can be kept to a minimum, provided that the appropriate index is readily available. When these operations are carried out over latent network connections or to an over-utilized external disk-based storage system, index updates can fail. Consequently, the resulting behavior that is displayed to the user can vary from Internet Explorer becoming unresponsive to missing or poor content layout.
It would be wrong to state that these inaccessibility problems could not happen on a client’s local machine. For instance, if a client redirected their Temporary Internet Files folder to a secondary hard disk on their local machine and then later, browsed the Internet while multi-tasking with a disk-intensive application running on the secondary drive, IE could be impacted. However, in this circumstance, the end-user experience would extend beyond the errors or unresponsive behavior of IE. The additional CPU and disk activity being performed by the secondary application would likely cause the entire desktop session to become slower or even unresponsive.
There may be environments where administrators and users never experience these behaviors. Unfortunately, this provides a false sense of security to both administrators and users alike. The more comfortable administrators and users become with this type of configuration, the harder it becomes to undo later. As the organization grows in both users and network utilization, the threat of an unresponsive browser increases. Whether during an executive-level demonstration of the organization’s newest web site or entering time card data, it will become noticeable and significantly impactful. The question then becomes, what are Microsoft’s official recommendations?
Simply put: Do not redirect the user’s Internet Explorer’s folders. Internet Explorer currently does not have the capacity to reliably utilize its data files from a remote location. Outward signs (error dialogs, event logs, browser behavior) do not indicate that the problem is caused by inaccessible indices. The sooner those administrators revert from this practice, the less impact there will be when organizations grow.
From a Microsoft support perspective, the Internet Explorer support team rarely begins troubleshooting by asking if the user’s folders are redirected. While there is one UI to ‘move’ the user’s Temporary Internet Files folder location, it fails to state that it should be kept to a local logical drive. Additionally, there are no interfaces other than the registry editor which provide for changing the location of the Cookies or History folders. Without an interface to indicate that the configuration is utilizing redirected folders, it can overlooked easily and administrators tend to not mention it as it didn’t seem relevant at the time. Eventually, once discovered, the issue is resolved with the recommendation to return the folders to their proper locations on the local machine.
In closing, if you are contemplating redirecting any of these folders, don’t. The impact may not be felt for days, weeks or months to come. When and if it should appear, the diagnosis will likely take considerable time and resources that could be better spent elsewhere. Reverting the configuration may be difficult to impossible given the amount of dependence on centralizing this data.
If you already have redirected these folders, start building a contingency plan and detail the time and resources required to undo it. If you are utilizing Terminal Server configurations, be mindful of the amount of disk space required locally on the server to accommodate the extra data being stored there after removing the redirection. If your organization is focused on maintaining site preference cookies for users with roaming profiles, it may be easier to leave the user shell folder locations set at their recommended default values and then incorporate a policy to force the clients to empty the Temporary Internet Files when the browser is closed. This will result in a small cache to copy across the network when the user logs in or out. The cookies should be preserved and roam as expected.
This blog has been provided to you by another one of our Senior Support Escalation Engineers for Internet Explorer, Joel Baxter.
Related Article:
Regards,
The IE Support Team