Stale Cookies - Citrix Profile Management

Talking with a partner recently, the Citrix Profile Management policy entitled “Process Internet cookie files on logoff” came up in conversation.  This policy is under the Citrix Components > Profile Management > Advanced settings section of the Group Policy.  The policy is shown below:

Looking at this more closely, the index.dat file hasn’t been used since Internet Explorer 9, Internet Explorer 10 and above uses the WinInet subsystem and the webcachev01.dat for a similar purpose, so the description is somewhat misleading.  The policy however does say it removes extra cookies, but we didn’t quite understand what this meant.

So, in this blog we look to see what this policy does, now please bear in mind this is from an observational standpoint as we don’t know what the code in UPM does.  And just a quick note at this point, we still call Citrix Profile Management UPM as in User Profile Management, this should possibly be CPM but old habits die hard!

The first thing we tried was logging on and logging off 2 different Server 2016 machines with Citrix 7.18 installed and UPM configured.  One server had the “Process Internet cookie files on logoff” policy enabled, the other had it disabled.  What we found was that on the server where the policy was enabled we got the following Event log entries:

Citrix Profile Management was interacting with the webcachev01.dat database.  Clearly the product knows that index.dat is no longer relevant so this looks promising.

The server where the policy was disabled did not show the same behaviour, the Event Log had none of these entries so that was working as expected also.

Next, we used a Server 2016 machine with Citrix 7.18 installed and UPM Configured as per the following article:  https://support.citrix.com/article/CTX224498.  In short, we configured these policies:

Now we logged on with our user (CTXUser1).  Once logged on we launched Internet Explorer 11, we accepted the default settings, and browsed to https://www.cnn.com

Logging off the session we can now see what UPM has captured.  We have 1 cookie file in the %LocalAppData%\Microsoft\Windows\INetCookies folder:

And we have 27 cookie files in the %LocalAppData%\Microsoft\Windows\INetCookies\Low folder:

Also, using a proprietary tool we have here at Avanite, we can also look at the contents of the webcachev01.dat file for CTXUser1 which has been mirrored from the %LocalAppData%\Microsoft\Windows\Webcache folder.  We see a single entry in the Cookies (M) container:

And we see 27 entries in the Cookies (L) container:

All looks good.

Looking at the data in the Cookies (L) container one of the cookie files has an expiry date of 08/11/2018 13:20pm – the cookie was set to expire in 30 minutes.

So as a first test we waited an hour then logged on our CTXUser1 user, then logged off again.

The UPM profile hadn’t changed, and neither had the webcachev01.dat so this isn’t a “stale” cookie.

From here we wondered if deleting a cookie file from the %LocalAppData%\Microsoft\Windows\INetCookies\Low folder would do anything.  So, we deleted the %LocalAppData%\Microsoft\Windows\INetCookies\Low\1AZK375A.cookie from the UPM profile store.

We logged on again, then logged off and had a look to see what changed.  Short answer, nothing – we now had 27 entries in the webcache Cookies (L) container and 26 cookie files in the %LocalAppData%\Microsoft\Windows\INetCookies\Low folder.

Hmmm, next we wondered what happens if we did that the other way around.  So, we deleted one of the entries from the webcachev01.dat database Cookies (L) container (using our proprietary tool mentioned earlier) – we picked EntryId 5 which represents the Z7L8DSS1.cookie file.

Once again we logged on, then logged off and had a look to see what changed.  This time we saw that UPM had deleted the Z7L8DSS1.cookie file from the profile:

So what does this tell us?

The webcachev01.dat is essentially an index for WinInet to locate cookies on the system.  When an index doesn’t exist in the database UPM removes the file as this must be a “stale” cookie.  UPM is right, the cookie file is useless as it can never be located so it is removed/deleted.

Now the other way around, we have an index entry but no cookie file.  In this scenario we would expect that the index is updated to remove the redundant index entry, but this doesn’t happen.

Also, when a cookie has expired it remains in both the index and the file system.  Ideally this would be removed as it is no longer relevant too.

So we are quite happy that we can now explain this UPM policy setting and what it does.  Essentially UPM provides a mechanism whereby cookies not referenced in the webcachev01.dat are removed when the “Process Internet cookie files on logoff” policy is enabled.

One interesting observation during our testing was seeing the following in the event log:

As we have the “Profile Streaming” policy enabled we suspect what happens is that all the cookie file from the disk are pulled down to the server during logoff to be analysed hence the logoff process takes an increasingly long time.

Peter Jones (Avanite CTO)