This is something that comes up often enough in our support forums that it’s worth lifting the covers on what Internet Explorer (IE) appears to do that makes handling cookies so difficult, and then open up a little bit on how we handle cookies in UPM.

First of all, a few words about cookies and browsers in general.

IE and other browsers use cookies to store little bits of information on the computer where the browser is running (“the client”).  They can be used to remember information from one browser session to another.  On a complex site, cookies can be used to remember what you were last doing, so that when you return, you can pick up your last activity where you left off.

Cookies are implemented as small text files stored in a Cookies directory in the user’s profile.  On my Windows 7 machine, they’re in a directory:

 C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies

If you look, you’ll find a load of files of the form user@domain[n].txt and a file index.dat .  Here’s an extract from my own Cookies directory:

C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies>dir billp@support*.txt /od

 Volume in drive C is OSDISK

 Volume Serial Number is CC96-A378

 

 Directory of C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies

 

17/05/2010  17:52               523 billp@support.creative[1].txt

03/06/2010  16:38                95 billp@support.citrix[3].txt

04/06/2010  23:54               270 billp@support.citrix[2].txt

16/06/2010  10:38                94 billp@support.citrix[4].txt

03/07/2010  09:54               272 billp@support.citrix[1].txt

13/07/2010  12:08               103 billp@support.gotomeeting[3].txt

24/11/2010  11:51               301 billp@support.citrix[8].txt

11/01/2011  18:11               720 billp@support.microsoft[2].txt

24/01/2011  15:36                95 billp@support.citrix[6].txt

24/01/2011  16:38               372 billp@support.citrix[5].txt

              12 File(s)          4,569 bytes

               0 Dir(s)  52,063,981,568 bytes free

 

C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies>dir index.dat /ash

 Volume in drive C is OSDISK

 Volume Serial Number is CC96-A378

 

 Directory of C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies

 

24/01/2011  16:19           360,448 index.dat

               1 File(s)        360,448 bytes

               0 Dir(s)  52,213,972,992 bytes free

 

C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies>attrib index.dat

A  SH   I    C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies\index.dat

 

C:\Users\billp\AppData\Roaming\Microsoft\Windows\Cookies>

Notice how many cookie files I’ve got for support.citrix.com .  However, only one of them actually contains current information – all the others are older (stale) versions, created by IE.  IE uses index.dat to keep track of which one is the active one.  Unfortunately IE is rather sloppy about tidying-up stale cookie txt-files, especially if your profile looks like a local profile (which a UPM profile does).  If you’re not careful, the number of stale cookies can mushroom, leading to cookie-bloat and increasing logon/logoff times.  What you need to do is run through index.dat – there’s a published API – looking for cookie files and deleting everything that’s not referenced.  Wait till IE is done first, of course, but then you can trim away the stale cookies and keep logon times fast.  Unfortunately it’s not that simple. 

Now it gets interesting, as we get into the realm of sysinternals tools, a bit of googlework and a bit of intelligent guesswork.  IE opens index.dat as a memory-mapped file (we think), and grows the file in fixed block increments.  So when IE shuts down, and closes index.dat , unless IE has also grown the file by a block or more, the time stamp on index.dat doesn’t change, and nor do any entries get written to the NTFS Change Journal.  Plus, if you try and open index.dat from another program, after IE has exited, you may well find it locked – here we surmise that IE passes a handle to another program in windows (possibly winlogon.exe), so that you can’t look at it until very late in logoff processing. 

So UPM leaves cookie processing as late as possible in the logoff processing, to allow time for index.dat to be released.  This processing is activated if you configure “Process Internet cookie files on logoff”.  It keeps trying to open index.dat and then looks through the cookie index, deleting the files that aren’t referenced, thereby preventing cookie bloat.  Then it synchronises the cookie folder with the user store, using the “Folders to mirror” policy.  The reason this is needed is twofold:

  1. It ensures that the index.dat file is copied up to the user store, even if IE hasn’t updated the size or the timestamp, and
  2. It ensures that stale cookies get removed from the user store too.  (For example, if the last support.citrix cookie on the user store was billp@support.citrix[4].txt and the current session has created a newer billp@support.citrix[3].txt , then the [4] version in the user store needs to be deleted, and the newer [3] version copied there instead 

Logically, the file index.dat , together with its associated cookie-txt files, has to be treated as a single, complete set of internally-consistent objects.  You can’t merge cookies from multiple sessions and hope that they’ll somehow combine.  At best you’ll be left with a lot of stale txt files, at worst, you’ll leave index.dat completely out of step with the txt files, and you’ll lose cookie information. 

As it says in the main documentation, if you need to handle cookies properly with UPM, you have to specify both policies:

  • “Process Internet cookie files on logoff” to activate UPM’s logic to trim stale cookie files from the cookie directory and
  • “Folders to mirror” to update the user store with a completely consistent set of cookies, represented by index.dat and just the matching user@domain[n].txt files 

Hopefully the “why” is a little clearer now.