On a couple of occasions now I have done some work with Ben Whitmore (@byteben) down in the flatlands of Norfolk. The last time I was down there, we were doing an upgrade to AppSense EM 8 FR 5. Unfortunately there was something of a disaster during this, and we found there was an upgrade issue when endpoints were using Offline Mode, which effectively left us sans Personalization for a lot of users the next day until we implemented a workaround. Thankfully, AppSense have fixed this issue - details in this TechNote - in SP1 for EM 8 FR 5.
However, a further issue that came to light post-migration was the way that IE10 (and higher) handle cookies. I had a lot of back-and-forth emails with Ben regarding this, and one word that came up repeatedly in both emails and Tweets was the highly-appropriate term "minefield".
Traditional cookie handling
There have always been two main camps for cookie handling in DesktopNow - Folder Redirection, and Personalization Server. Personally, I've always preferred to redirect them onto the network, but some opt to capture them into Personalization. There's no right or wrong here - it's whatever works best for you.
So let's remind ourselves of how cookies should work. I'm running a published desktop on a XenApp 6.5 server with Internet Explorer 8 as my browser (stop laughing at the back - it's the default installed browser on 2008 R2), using a mandatory profile. I've got an AppSense EM configuration set up that redirects my Cookies folder to my home drive on the network.
When I go to a website that has a cookie warning (which seems to be just about every single one these days), we will see something like this
Naturally, clicking on Continue should make the warning go away and store the cookie in our Cookies folder, which will then be persisted because of the folder redirection. If we were putting {CSIDL_COOKIES} into Personalization Server, you'd also expect the same result. Just to verify this, I will log out of my XenApp session, make sure that the profile no longer exists on the server, and then log back in and try the same website.
Excellent - that's exactly the behaviour we are expecting. The cookies are persisting in our redirected folder, users aren't bothered by multiple prompts - all is good. The behaviour is the same in IE9 as it is in IE8, no issues are observed.
Now let's "upgrade" our browser to Internet Explorer 10. To do this on Windows Server 2008, you need to have SP1 installed.
Once the installation is done, let's go to the BBC website again. The "cookie warning" has returned! Is it just because we've upgraded our browser? Let's click Continue again and see what happens....
![]()
Damn! For some reason, cookies don't persist properly in IE10 using the Folder Redirection method. So, just what is going on here?
Environment Manager 8 FR 5
Now, those of you who've dared to do the upgrade to the latest version of AppSense DesktopNow EM will know that in your Windows Settings Groups, there are specifically defined settings for IE10 Cookies. Clearly something has changed under the hood!
![]()
If you read the article at https://www.myappsense.com/Knowledgebase/TN-151164.aspx (login required), you will see that indeed there has been a change. The Personalization Group needs to be utilized, and it captures the following Registry keys and folders:-
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\DomStorage\
{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\WebCache
{CSIDL_LOCAL_APPDATA}\Microsoft\Internet Explorer\DOMStore
{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\History
{CSIDL_APPDATA}\Microsoft\Windows\Cookies
{CSIDL_PROFILE}\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore
OK, so it's a change, but let's give it a go. After all, they've included the functionality (which presumes some testing done, yes?), so it should work...
The Windows Setting Group is pre-defined, which is handy, but please bear in mind this fact - you can't edit the pre-defined Windows Settings Groups at all. This is rather annoying if you want to change any of the settings (which you may well want to) - it might be easier to copy the pre-defined Windows Settings Groups and create your own, editable ones.
Anyways, let's link the pre-defined group to our Personalization Group
![]()
Nice and simple, eh? So let's now perform our test again and see what happens. After we click the Continue button and log out, there is data in the Personalization Server database...
![]()
...but unfortunately, this solution doesn't seem to work very well at all. Some websites retain the cookie settings OK - but some don't. Additionally, your cookies may be preserved on some sessions - then at next logon they're all gone again, and putting up the prompts that you've already responded to.
![]()
It's unclear if this "loss of cookie settings" has any pattern to it at all. As we are using a mandatory profile which is obviously discarded at logoff (the "delete cached copies of roaming profiles" GPO is in use), there is no actual IE-specific Personalization going on (all we are doing is the IE10 cookies via Windows Personalization), and we're visiting three different websites to see if the cookie message appears (just in case it was a site-based problem), it is clear that the this isn't working as we are used to. Hmmm. I can see how this would become an almighty pain in the backside to users - it doesn't stop you working, but it's a frustrating, nagging issue that you know should go away.
The only pattern I can discern is that it seems to be almost every second logon where this occurs, rather than each one, making things even more random. And the history of visited websites seems to disappear at the same time too. Clearly the AppSense solution has captured some of the pertinent data - but it isn't persisting correctly. So we've foregone the old reliable Folder Redirection solution for putting it into Personalization directly - yet neither of them seem to work satisfactorily!
Something else is going on here - something that the AppSense-provided solution doesn't quite cover. What could it be?
Digging time
As usual, the Intertubes will be involved in the research segment of attacking this problem.
Firstly I visited Microsoft's update servers and made sure I was fully patched (I was fairly sure I was - the patching process took several hours and hung my VM twice). I also ensured the latest Citrix hotfixes were present (shot in the dark, but you never know). There is no antivirus or similar product running on the test server - just a bare bones 2008 R2 install with XenApp on top.
Now, research at this precise moment would throw up an AppSense technote regarding this issue - https://www.myappsense.com/Knowledgebase/TN-151371.aspx (login required). I'm fairly sure this is probably a response to Ben's reporting of the issue or someone else's. However, it does provide a nice description of the issue (which I will summarize).
It looks like Microsoft decided, at some point, to move from IE's old way of tracking this sort of data - index.dat files - and replace them with a proper database file called WebCacheV01.dat. I'm assuming this was done to take advantage of modern compute and simplify coding, as well as improving performance. The AppSense article tells us that "when Internet Explorer is launched, the files under the %LocalAppData%\Microsoft\Windows\WebCache directory are locked...these files are in use during the Internet Explorer session and for some time after Internet Explorer has exited".
It's a Scheduled Task, of all things, that keeps the damn handle open. The task in question is Task Scheduler Library > Microsoft > Windows > Wininet. What the task is intended to do is something of a mystery - it's name is CacheTask, and trying to edit the "Custom Handler" under the Actions tab in Task Scheduler throws up this
![]()
Yes, I have no idea what this does - and information from Google is also sadly lacking. There's more than just this task with "mystery" properties - I can only assume some of the Windows Automatic Maintenance jobs are done by these things. It would be interesting to find out what they're really for, but I'm not interested in understanding it's purpose right now - just to prevent it from interfering with those cookies!
Well, as luck would have it, there's a short blog post from Michael Obernberger describing this exact issue - and, more importantly, an AppSense configuration available for download. Don't you just love community?
Breaking the open handle
Now, Michael's configuration (there's a link in his article - I've also reproduced an EM 8 FR 5 version of it at the end of this one) is nice and simple. It uses a bit of PowerShell tied to some AppSense EM Mirror Folder Actions. Essentially, in the Logon trigger you stop the task, Mirror the folder data in from the network, and then restart the task. And then during the Logoff trigger, you stop the task and Mirror the folder data out to the network. Dead simple!
You could maybe use Internet Explorer Process Started and Process Stopped as the trigger points, but given that IE is tied closely to the operating system many people opt to deal with it at logon and logoff.
If you wanted to get clever, you could actually Mirror the cookie data to a local folder, and then capture that into Personalization Server as the process exits. The advantage you would get from this method is that you could then use the Personalization rollback features and reduce reliance on network shares, but that would be slightly more complicated. However - the WebCacheV01.dat file can get big, and if it did I wouldn't fancy the overhead of putting hundreds or thousands of multiple copies of it into Personalization Server.
But.....unfortunately, in this case, this doesn't work either. What's going on?
Redirection+
What is actually needed, it turns out (in my testing anyways) is to, rather strangely, combine the old style with the new. The only way I could get this to work was by not only configuring the settings defined above (stopping the Scheduled Task and copying in the required file), but also by defining the Folder Redirection for Cookies. Reading Michael's article back that I mentioned earlier, I think that this is what he was alluding to, it just wasn't spelled out particularly clearly. But if you remove either of these parts - be it the part that copies in the .dat file or the Folder Redirection - then the roaming of Cookies will stop.
Now, adding the Windows Personalization Group for IE 10 Cookies isn't necessary for this to work - in fact, it seems to be completely extraneous (although see the note in the table below). The key is combining the Folder Redirection with the capture of the webcachev01.dat file, which can only be done when the Scheduled Task is stopped. In light of this, I won't be using the AppSense-provided Windows Personalization Group at all - and given the size that the webcachev01.dat file can get (32MB after two logons), this is probably a good thing, speaking frankly. This may change as AppSense try and address this issue, but for the moment, this is the only way I can find to make these cookies persist.
Summing up
To summarize, what I found was (where WPG is Windows Personalization Group for IE 10 Cookies and History, Copy Task is the "stop scheduled task and copy webcache folder" Actions, and Redirection is Folder Redirection of Cookies):-
Redirection alone - fails
Copy task alone - fails
WPG alone - fails
Redirection + WPG - fails
Copy task + WPG - fails
Redirection + copy task + WPG - works (NOTE - this combination may be required for certain websites however)
Redirection + copy task - works
The key to grabbing the webcachev01.dat file lies in using PowerShell to stop and start the Scheduled Task - the code used is shown below
schtasks /end /tn "Microsoft\Windows\Wininet\CacheTask" | Out-Null
schtasks /run /tn "Microsoft\Windows\Wininet\CacheTask" | Out-Null
There is a configuration available here that shows how this should be set up (EM 8 FR 5 version) - don't forget, obviously, to change the paths for the server and share to reflect your own environment!
I've tested this on three separate websites, twenty sessions in succession, and it seems to work on each. In each case I checked that the profile was completely removed before logging back on, and no other IE Personalization was taking place (in fact, no Personalization at all). However - I have only tested this on Windows Server 2008 R2, and I also wanted to test this on Windows 7, but Microsoft's licensing weirdness means I can't get a trial version of Windows 7 any more for my lab.
Also, it is worth noting that in Windows 8.1 (and Server 2012 R2, for that matter), Microsoft have back-tracked on this. Configuring AppSense EM to use simply the Folder Redirection method works perfectly in this case. Of course, this is IE11, and it may also turn out that upgrading to the latest version on Windows 7 or 2008 R2 may also do the trick for you (if you dare!)
Finally, this article only deals with Cookie persistence - and as I am sure you are aware, the AppSense-provided Windows Personalization Group also mentions History persistence. This is something I am going to tackle in my next article, if only to stop this one expanding too much!
Credits
Thanks to Michael Obernberger for the PowerShell and insight from his article that allowed us to focus on the core of this issue, and also to Ben Whitmore for providing plenty of relevant links and frustrated testing.
Update 07/01/15 - this method worked on the three websites I tested without any problems at all, but as I found out this morning, it doesn't work on a few odd websites (but adding the Windows Personalization Group in there as well should make the issue go away). I will try and find out why this happens to certain sites - in the meantime, I can only conclude that Microsoft's cookie implementation in IE10 is, to be frank, a steaming pile of horse poo. Avoid.
Once the installation is done, let's go to the BBC website again. The "cookie warning" has returned! Is it just because we've upgraded our browser? Let's click Continue again and see what happens....
Damn! For some reason, cookies don't persist properly in IE10 using the Folder Redirection method. So, just what is going on here?
Environment Manager 8 FR 5
Now, those of you who've dared to do the upgrade to the latest version of AppSense DesktopNow EM will know that in your Windows Settings Groups, there are specifically defined settings for IE10 Cookies. Clearly something has changed under the hood!
If you read the article at https://www.myappsense.com/Knowledgebase/TN-151164.aspx (login required), you will see that indeed there has been a change. The Personalization Group needs to be utilized, and it captures the following Registry keys and folders:-
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\DomStorage\
{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\WebCache
{CSIDL_LOCAL_APPDATA}\Microsoft\Internet Explorer\DOMStore
{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\History
{CSIDL_APPDATA}\Microsoft\Windows\Cookies
{CSIDL_PROFILE}\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore
OK, so it's a change, but let's give it a go. After all, they've included the functionality (which presumes some testing done, yes?), so it should work...
The Windows Setting Group is pre-defined, which is handy, but please bear in mind this fact - you can't edit the pre-defined Windows Settings Groups at all. This is rather annoying if you want to change any of the settings (which you may well want to) - it might be easier to copy the pre-defined Windows Settings Groups and create your own, editable ones.
Anyways, let's link the pre-defined group to our Personalization Group
Nice and simple, eh? So let's now perform our test again and see what happens. After we click the Continue button and log out, there is data in the Personalization Server database...
...but unfortunately, this solution doesn't seem to work very well at all. Some websites retain the cookie settings OK - but some don't. Additionally, your cookies may be preserved on some sessions - then at next logon they're all gone again, and putting up the prompts that you've already responded to.
It's unclear if this "loss of cookie settings" has any pattern to it at all. As we are using a mandatory profile which is obviously discarded at logoff (the "delete cached copies of roaming profiles" GPO is in use), there is no actual IE-specific Personalization going on (all we are doing is the IE10 cookies via Windows Personalization), and we're visiting three different websites to see if the cookie message appears (just in case it was a site-based problem), it is clear that the this isn't working as we are used to. Hmmm. I can see how this would become an almighty pain in the backside to users - it doesn't stop you working, but it's a frustrating, nagging issue that you know should go away.
The only pattern I can discern is that it seems to be almost every second logon where this occurs, rather than each one, making things even more random. And the history of visited websites seems to disappear at the same time too. Clearly the AppSense solution has captured some of the pertinent data - but it isn't persisting correctly. So we've foregone the old reliable Folder Redirection solution for putting it into Personalization directly - yet neither of them seem to work satisfactorily!
Something else is going on here - something that the AppSense-provided solution doesn't quite cover. What could it be?
Digging time
As usual, the Intertubes will be involved in the research segment of attacking this problem.
Firstly I visited Microsoft's update servers and made sure I was fully patched (I was fairly sure I was - the patching process took several hours and hung my VM twice). I also ensured the latest Citrix hotfixes were present (shot in the dark, but you never know). There is no antivirus or similar product running on the test server - just a bare bones 2008 R2 install with XenApp on top.
Now, research at this precise moment would throw up an AppSense technote regarding this issue - https://www.myappsense.com/Knowledgebase/TN-151371.aspx (login required). I'm fairly sure this is probably a response to Ben's reporting of the issue or someone else's. However, it does provide a nice description of the issue (which I will summarize).
It looks like Microsoft decided, at some point, to move from IE's old way of tracking this sort of data - index.dat files - and replace them with a proper database file called WebCacheV01.dat. I'm assuming this was done to take advantage of modern compute and simplify coding, as well as improving performance. The AppSense article tells us that "when Internet Explorer is launched, the files under the %LocalAppData%\Microsoft\Windows\WebCache directory are locked...these files are in use during the Internet Explorer session and for some time after Internet Explorer has exited".
It's a Scheduled Task, of all things, that keeps the damn handle open. The task in question is Task Scheduler Library > Microsoft > Windows > Wininet. What the task is intended to do is something of a mystery - it's name is CacheTask, and trying to edit the "Custom Handler" under the Actions tab in Task Scheduler throws up this
Yes, I have no idea what this does - and information from Google is also sadly lacking. There's more than just this task with "mystery" properties - I can only assume some of the Windows Automatic Maintenance jobs are done by these things. It would be interesting to find out what they're really for, but I'm not interested in understanding it's purpose right now - just to prevent it from interfering with those cookies!
Well, as luck would have it, there's a short blog post from Michael Obernberger describing this exact issue - and, more importantly, an AppSense configuration available for download. Don't you just love community?
Breaking the open handle
Now, Michael's configuration (there's a link in his article - I've also reproduced an EM 8 FR 5 version of it at the end of this one) is nice and simple. It uses a bit of PowerShell tied to some AppSense EM Mirror Folder Actions. Essentially, in the Logon trigger you stop the task, Mirror the folder data in from the network, and then restart the task. And then during the Logoff trigger, you stop the task and Mirror the folder data out to the network. Dead simple!
You could maybe use Internet Explorer Process Started and Process Stopped as the trigger points, but given that IE is tied closely to the operating system many people opt to deal with it at logon and logoff.
If you wanted to get clever, you could actually Mirror the cookie data to a local folder, and then capture that into Personalization Server as the process exits. The advantage you would get from this method is that you could then use the Personalization rollback features and reduce reliance on network shares, but that would be slightly more complicated. However - the WebCacheV01.dat file can get big, and if it did I wouldn't fancy the overhead of putting hundreds or thousands of multiple copies of it into Personalization Server.
But.....unfortunately, in this case, this doesn't work either. What's going on?
Redirection+
What is actually needed, it turns out (in my testing anyways) is to, rather strangely, combine the old style with the new. The only way I could get this to work was by not only configuring the settings defined above (stopping the Scheduled Task and copying in the required file), but also by defining the Folder Redirection for Cookies. Reading Michael's article back that I mentioned earlier, I think that this is what he was alluding to, it just wasn't spelled out particularly clearly. But if you remove either of these parts - be it the part that copies in the .dat file or the Folder Redirection - then the roaming of Cookies will stop.
Now, adding the Windows Personalization Group for IE 10 Cookies isn't necessary for this to work - in fact, it seems to be completely extraneous (although see the note in the table below). The key is combining the Folder Redirection with the capture of the webcachev01.dat file, which can only be done when the Scheduled Task is stopped. In light of this, I won't be using the AppSense-provided Windows Personalization Group at all - and given the size that the webcachev01.dat file can get (32MB after two logons), this is probably a good thing, speaking frankly. This may change as AppSense try and address this issue, but for the moment, this is the only way I can find to make these cookies persist.
Summing up
To summarize, what I found was (where WPG is Windows Personalization Group for IE 10 Cookies and History, Copy Task is the "stop scheduled task and copy webcache folder" Actions, and Redirection is Folder Redirection of Cookies):-
Redirection alone - fails
Copy task alone - fails
WPG alone - fails
Redirection + WPG - fails
Copy task + WPG - fails
Redirection + copy task + WPG - works (NOTE - this combination may be required for certain websites however)
Redirection + copy task - works
 |
| The node with the Actions required to bring in the persisted Cookies at logon |
 |
| The node with the Actions required to hive out the persisted Cookies at logoff |
The key to grabbing the webcachev01.dat file lies in using PowerShell to stop and start the Scheduled Task - the code used is shown below
schtasks /end /tn "Microsoft\Windows\Wininet\CacheTask" | Out-Null
schtasks /run /tn "Microsoft\Windows\Wininet\CacheTask" | Out-Null
There is a configuration available here that shows how this should be set up (EM 8 FR 5 version) - don't forget, obviously, to change the paths for the server and share to reflect your own environment!
I've tested this on three separate websites, twenty sessions in succession, and it seems to work on each. In each case I checked that the profile was completely removed before logging back on, and no other IE Personalization was taking place (in fact, no Personalization at all). However - I have only tested this on Windows Server 2008 R2, and I also wanted to test this on Windows 7, but Microsoft's licensing weirdness means I can't get a trial version of Windows 7 any more for my lab.
Also, it is worth noting that in Windows 8.1 (and Server 2012 R2, for that matter), Microsoft have back-tracked on this. Configuring AppSense EM to use simply the Folder Redirection method works perfectly in this case. Of course, this is IE11, and it may also turn out that upgrading to the latest version on Windows 7 or 2008 R2 may also do the trick for you (if you dare!)
Finally, this article only deals with Cookie persistence - and as I am sure you are aware, the AppSense-provided Windows Personalization Group also mentions History persistence. This is something I am going to tackle in my next article, if only to stop this one expanding too much!
Credits
Thanks to Michael Obernberger for the PowerShell and insight from his article that allowed us to focus on the core of this issue, and also to Ben Whitmore for providing plenty of relevant links and frustrated testing.
Update 07/01/15 - this method worked on the three websites I tested without any problems at all, but as I found out this morning, it doesn't work on a few odd websites (but adding the Windows Personalization Group in there as well should make the issue go away). I will try and find out why this happens to certain sites - in the meantime, I can only conclude that Microsoft's cookie implementation in IE10 is, to be frank, a steaming pile of horse poo. Avoid.