You may recall I did a couple of articles a while ago talking about how IE10+ Cookies and History behaved for roaming users - mainly those on Citrix platforms, although the concepts were perfectly applicable to other roaming situations as well. You may recall that Microsoft had shunted these settings out to a Jet Blue database - a typical modus operandi for them these days, Windows 10's basic profile comes with three of them as standard - and it was very difficult to roam these settings because of various OS hooks.
As far as the investigation got, we found mainly that using Folder Redirection for Cookies or History, in any situation, tended to break rather dramatically, and the only way to reliably roam them was by using AppSense or Citrix UPM with Folder Redirection for these particular folders disabled. Other UEM products may also have worked - sadly, due to pressures of time and work, I didn't get to test any more. However, Microsoft apparently released an update that dealt with the roaming issues - see here for an article that describes this very problem. Essentially, the solution simply creates pairs of .dat files and then imports them into the dreaded webcachev01.dat file at logon. Unfortunately, though, this fix is only implemented when you are using a Microsoft roaming profile - local, mandatory, super-mandatory profiles don't benefit from it.
Meanwhile, Satya Nadella's new agile "mobile first, cloud first" Microsoft have slashed IE support and announced that as of January 12 2016, the only supported IE version will be Internet Explorer 11. Ignoring the fact that they've gone against their initial promise to support a browser for as long as the OS capable of running it (they've lopped a year of support from IE7, four years from IE8 and IE9, and seven years from IE10), this means that we're again stuck in the rush to make sure that all of our sites and web apps are compatible with a new version of IE.
And also, I've noticed that out-of-the-box, IE History seems to be the most part broken for roaming users since IE11 came along.
And also, I've noticed that out-of-the-box, IE History seems to be the most part broken for roaming users since IE11 came along.
So, as you can see there are currently a few major drivers for a revisiting of the Cookies and History subject - I promised a part #3, so in view of all these happenings, let's waste no time and get to it!
Testing parameters
We're going to perform the same tests as we did previously, and see how Cookies and History fare in roaming situations for a variety of different types. We're going to test one system only - XenApp 7.6 FP3 on Server 2012 R2 running IE11, with all patches applied.
We haven't tested on Windows 10 IE11 for a few small(!) reasons:-
Microsoft have earmarked a November release of Windows 10 updates to, allegedly, provide fixes for all the roaming issues I've blogged about so far, which means there will (against all my instincts!) be a part #4 coming hopefully next month some time.
So on our XenApp 2012 R2 IE11 roaming instance, we're going to test these methods of persistence
We haven't tested on Windows 10 IE11 for a few small(!) reasons:-
- Windows 10 Start Menu breaks when you use a mandatory profile
- Windows 10 Start Menu breaks when you use Citrix User Profile Manager
- Windows 10 fails to purge profiles correctly when they're mandatory or temporary
Microsoft have earmarked a November release of Windows 10 updates to, allegedly, provide fixes for all the roaming issues I've blogged about so far, which means there will (against all my instincts!) be a part #4 coming hopefully next month some time.
So on our XenApp 2012 R2 IE11 roaming instance, we're going to test these methods of persistence
- Standard Microsoft roaming profile
- Standard Microsoft roaming profile with Folder Redirection
- AppSense DesktopNow with mandatory profile and Personalization Server
- AppSense DesktopNow with mandatory profile and Folder Redirection
- Citrix User Profile Manager
- Citrix User Profile Manager with Folder Redirection
and we're going to run these tests for Cookies and History persistence (lifted from previous articles)
Hopefully, the solutions we come up with should be portable to any UEM technology or persistence method - but I'm not going to make any promises around that :-)
Hopefully, the solutions we come up with should be portable to any UEM technology or persistence method - but I'm not going to make any promises around that :-)
Test 1
Browse to www.google.co.uk. Respond to the cookie warning. Log the session out, log back in, verify that the cookie warning no longer appears.
Test 2
Log in to an account at mail.google.com. Close the session. Log back in, verify that the Google Mail account logs in automatically using the cookie.
Test 3
Browse to www.bbc.co.uk/news. Respond to the cookie warning. Log the session out, log back in, verify that the cookie warning no longer appears.
Test 4
Browse to theregister.co.uk. Respond to the cookie warning. Log the session out, log back in, verify that the cookie warning no longer appears.
Test 5
Open up the History folder. Verify that the websites visited so far all appear in History. Log the session out, log back in, verify that the History is still present.
Test 6
Put the system clock forward 48 hours. Log in and verify that the History and Cookies are still persisting correctly (pay particular attention to History).
Information and required settings
Cookie path changes
Firstly, the default path to your Cookies folder appears to have changed. The folder is now called INetCookies instead of Cookies. For all non-redirected users, the path is set in the Registry to %LOCALAPPDATA%\Microsoft\Windows\INetCookies, but as soon as a roaming user launches IE, Cookies are populated to %APPDATA%\Microsoft\Windows\INetCookies instead. If you're a non-roaming user, Cookies just write to the folder in %LOCALAPPDATA%.
This little "trick" of Microsoft's has me wondering about the reliability of Folder Redirection, because essentially they seem to be letting roaming users override the folder location set in the Registry. Interesting!
Profile spoofing
So really, to get Microsoft's patch to work and allow us to roam the Cookies correctly, we really should spoof a roaming profile when we're not using one. AppSense DesktopNow has a built-in engineering setting for spoofing a roaming profile - with other tech (like UPM), we may have to resort to trickery. I've found that the easiest way to emulate a roaming profile is to set the DWORD State value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\[USERSID] to 20 (decimal) at logon. You can additionally flip it to 5 (decimal) at logoff to purge the profile also. Pulling the user's SID, and elevating the context of your commands, are the real tricks for this part and that's where advanced UEM solutions come into their own - but it is possible with a bit of scripting, which we've done below.
If you're not using a UEM solution with this sort of capability, PowerShell startup, logon and logoff scripts will do (execution policy shouldn't matter - GPO PS scripts automatically run as Bypass). Run the script below as a GPO Startup Script to allow users to write to the ProfileList key (AppSense and other products seem to bypass this through some form of voodoo, possibly using SYSTEM to impersonate the user). Bear in mind that this will involve opening up this key in HKLM to all users for Write access - if this is an issue, you could apply custom permissions to the key and subkeys.
and then at logon, run this script to pull the SID and then spoof the roaming profile type - but be aware of this gotcha too:-
If you're using 2012 R2 DCs, make sure you're aware that now, by default, logon scripts actually run five minutes after user logon has finished (which kind of makes them an after-logon script). If you want them to actually run as logon scripts (i.e. at logon!), you need to define the following GPO and set it to 0 - Computer Config | Admin Templates | System | Group Policy | Configure Logon Script Delay. Thanks to MVP Darren Mar-Elia for pointing that out - took me the better part of two days to get to the bottom of it!
Anyway, here's the logon script you'll need
and at logoff, run this one to reset the profile to a non-roaming one (5 indicates mandatory) so that it doesn't try to write the profile up to a share and (if you want it to) purges it
Citrix User Profile Management
Citrix User Profile Management, where utilized, is done with the following settings deployed via GPO
![]()
Firstly, the default path to your Cookies folder appears to have changed. The folder is now called INetCookies instead of Cookies. For all non-redirected users, the path is set in the Registry to %LOCALAPPDATA%\Microsoft\Windows\INetCookies, but as soon as a roaming user launches IE, Cookies are populated to %APPDATA%\Microsoft\Windows\INetCookies instead. If you're a non-roaming user, Cookies just write to the folder in %LOCALAPPDATA%.
This little "trick" of Microsoft's has me wondering about the reliability of Folder Redirection, because essentially they seem to be letting roaming users override the folder location set in the Registry. Interesting!
Profile spoofing
So really, to get Microsoft's patch to work and allow us to roam the Cookies correctly, we really should spoof a roaming profile when we're not using one. AppSense DesktopNow has a built-in engineering setting for spoofing a roaming profile - with other tech (like UPM), we may have to resort to trickery. I've found that the easiest way to emulate a roaming profile is to set the DWORD State value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\[USERSID] to 20 (decimal) at logon. You can additionally flip it to 5 (decimal) at logoff to purge the profile also. Pulling the user's SID, and elevating the context of your commands, are the real tricks for this part and that's where advanced UEM solutions come into their own - but it is possible with a bit of scripting, which we've done below.
If you're not using a UEM solution with this sort of capability, PowerShell startup, logon and logoff scripts will do (execution policy shouldn't matter - GPO PS scripts automatically run as Bypass). Run the script below as a GPO Startup Script to allow users to write to the ProfileList key (AppSense and other products seem to bypass this through some form of voodoo, possibly using SYSTEM to impersonate the user). Bear in mind that this will involve opening up this key in HKLM to all users for Write access - if this is an issue, you could apply custom permissions to the key and subkeys.
$acl = Get-Acl"HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList"
$inherit = [system.security.accesscontrol.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [system.security.accesscontrol.PropagationFlags]"None"
$rule = New-ObjectSystem.Security.AccessControl.RegistryAccessRule ("DOMAIN\Group","FullControl",$inherit,$propagation,"Allow")
$acl.SetAccessRule($rule)
$acl |Set-Acl-Path"HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList"
and then at logon, run this script to pull the SID and then spoof the roaming profile type - but be aware of this gotcha too:-
If you're using 2012 R2 DCs, make sure you're aware that now, by default, logon scripts actually run five minutes after user logon has finished (which kind of makes them an after-logon script). If you want them to actually run as logon scripts (i.e. at logon!), you need to define the following GPO and set it to 0 - Computer Config | Admin Templates | System | Group Policy | Configure Logon Script Delay. Thanks to MVP Darren Mar-Elia for pointing that out - took me the better part of two days to get to the bottom of it!
Anyway, here's the logon script you'll need
$USERSID = ([Security.Principal.WindowsIdentity]::GetCurrent()).User.Value
$regpath = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\$USERSID"
$name = "State"
Set-ItemProperty-Path$regpath-Name$name-Value"20"
$regpath = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\$USERSID"
$name = "State"
Set-ItemProperty-Path$regpath-Name$name-Value"20"
$USERSID = ([Security.Principal.WindowsIdentity]::GetCurrent()).User.Value
$regpath = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\$USERSID"
$name = "State"
Set-ItemProperty-Path$regpath-Name$name-Value"5"
$regpath = "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\$USERSID"
$name = "State"
Set-ItemProperty-Path$regpath-Name$name-Value"5"
Citrix User Profile Management
Citrix User Profile Management, where utilized, is done with the following settings deployed via GPO
Folder Redirection
All Folder Redirection for Cookies and History is achieved by setting the Registry values in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders to the required network locations. Microsoft no longer support allow you to do this via GPO (although you can do it with Group Policy Preferences)
Attributes on History folder and files
I'm also certain now that getting History working depends on the attributes being set on the %LOCALAPPDATA%\Microsoft\Windows\History folder and the desktop.ini file in that folder, as well as the desktop.ini file being present and correct. Sometimes, the folders are created without the relevant desktop.ini file or the attributes and this seems to break History completely. I'd hope this has actually been raised with Microsoft as a bug, because it seems very prevalent in my testing (not holding my breath though, especially now that I've seen people resorting to petitions on change.org to get Microsoft to take notice of things). To have a chance of History working, you need to make sure the following criteria are fulfilled (use your tool or script of choice to achieve it)
All Folder Redirection for Cookies and History is achieved by setting the Registry values in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders to the required network locations. Microsoft no longer support allow you to do this via GPO (although you can do it with Group Policy Preferences)
Attributes on History folder and files
I'm also certain now that getting History working depends on the attributes being set on the %LOCALAPPDATA%\Microsoft\Windows\History folder and the desktop.ini file in that folder, as well as the desktop.ini file being present and correct. Sometimes, the folders are created without the relevant desktop.ini file or the attributes and this seems to break History completely. I'd hope this has actually been raised with Microsoft as a bug, because it seems very prevalent in my testing (not holding my breath though, especially now that I've seen people resorting to petitions on change.org to get Microsoft to take notice of things). To have a chance of History working, you need to make sure the following criteria are fulfilled (use your tool or script of choice to achieve it)
%LOCALAPPDATA%\Microsoft\Windows\History needs to exist
%LOCALAPPDATA%\Microsoft\Windows\History\desktop.ini needs to exist and have the following content
[.ShellClassInfo]
ConfirmFileOp=0
CLSID={FF393560-C2A7-11CF-BFF4-444553540000}
UICLSID={7BD29E00-76C1-11CF-9DD0-00A0C9034933}
%LOCALAPPDATA%\Microsoft\Windows\History and the desktop.ini file within need to have the following file attributes set - System and Hidden (command lines to set are below)
attrib +s +h %LOCALAPPDATA%\Microsoft\Windows\History
attrib +s +h %LOCALAPPDATA%\Microsoft\Windows\History\desktop.ini
Extra Registry settings
Finally, if you're using a tool like AppSense or other high-end UEM solution, make sure this Registry key is saved with your Personalization settings. You don't need this with UPM in the config we've done as it should save the entire HKCU hive.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache
It doesn't appear in the AppSense EM group by default, but I'm pretty sure it's necessary for History roaming to work correctly.
Testing results
So, how did each set of tests work out this time? Let's have a look...
| Test1 | Test2 | Test3 | Test4 | Test5 | Test6 | |
| MS roaming profile | Pass | Pass | Pass | Pass | Fail | Fail |
| MS roaming profile with Redirection | Pass | Pass | Pass | Pass | Fail | Fail |
| AppSense with mandatory profile and PS | Pass | Pass | Pass | Pass | Pass | Pass |
| AppSense with mandatory profile and Redirection | Pass | Pass | Pass | Pass | Fail | Fail |
| Citrix UPM | Pass | Pass | Pass | Pass | Pass | Fail |
| Citrix UPM with Redirection | Pass | Pass | Pass | Pass | Fail | Fail |
AppSense DesktopNow, with Personalization Server enabled, comes out of this smelling of roses again, successfully roaming everything. Citrix UPM comes close, failing to roam History after 48 hours, for a reason I can't quite quantify. But as long as you use or spoof a roaming profile, Cookies seems to work right across the board, which is progress - of a sort. Cookies can roam OK - as long as you have a roaming profile set or spoofed. History seems to only work with a UEM solution and a bit of file attributes jiggery-pokery. But again, Folder Redirection really seems to screw the pooch in most situations. I think it may be time to close the door completely on Folder Redirection as a solution for roaming Cookies and History.
Summary
For anyone who feels this article is a bit TL:DR, what are the important points to take away?
- To successfully roam Cookies, you need to spoof or set a roaming profile type - to spoof, either use a UEM solution or the scripts I put together in the article
- To successfully roam History, you need to ensure that the desktop.ini file exists with the right content in the History folder, and the attributes for the file and folder are set as documented in the article
- History writes to %LOCALAPPDATA%, so a standard roaming profile simply won't cut it - UEM appears to be a requirement at some level to make it roam
- Don't use Folder Redirection for Cookies and History, especially given that Microsoft are essentially bypassing it for their roaming "fix"
- Windows 10 still breaks quite regularly when you apply any tried-and-tested roaming techniques to it
- Not really relevant to the subject, but Microsoft have turned logon scripts into "post-logon scripts" in the default settings for Server 2012 R2 - if you're using logon scripts, you may want to set the GPO to 0
It's still not where we want it, but the fix Microsoft have applied has given us *some* wiggle room with this. As long as you set the profile type correctly, either through tools like AppSense or scripting, you can roam Cookies fairly reliably. That's better than we had.
With regard to History, still not great, but a lot of users rely on the TypedURLs history from the Registry rather than the History function per se - but not something to stake the farm on. If you desperately need History to roam, you may need to go down the UEM route. I only tested AppSense DesktopNow, which managed it without any issues, but I assume other high-end vendors like RES should also cope just fine.
Microsoft have announced a raft of Windows 10 updates for next month to address roaming issues and Start Menu problems (I sincerely hope they are telling the truth!), so I will revisit these tests at the end of next month with a Windows 10 slant.
But for now - it's slightly better. We're now a bit of the way back towards where we were with Windows 7 and 2008 R2 :-)