Introduction
Since the release of Microsoft Internet Explorer 10, Microsoft has changed the way they handle cookies. In older versions your user profile just had a folder named Cookies that contained them all. When using RES ONE Workspace, you just needed to make sure that the folder was included in the user settings.
Capturing the history was also easy. The only difference was that it was located in the local part of the profile and not the roaming part.
However, when IE 10 was released, everything changed. They started using a webcache database that’s located in the local part of the user profile. It gets locked after logon and simply adding it to the user settings in ROW apparently isn’t enough.
Check the following excellent blogs by Rory de Leur for more information:
http://rorydeleur.nl/2014/10/microsoft-wont-give-me-my-cookies/
http://rorydeleur.nl/2015/03/houston-we-got-cookies-with-ie11/
Of course, you can contact Microsoft support about this issue. However, when using RES ONE Workspace, people usually setup a local or mandatory profile. And Microsoft simply doesn’t support ‘roaming-cookies’ in any other setup than roaming profiles.
Solution to saving cookies with ROW
One of the most common solutions was to ‘spoof’ the profile from local or mandatory to roaming to trick Windows into handling the cookies correctly. While fairly effective, it seemed like a ‘duct-tape’ way of fixing things.
In the summer of 2015 RES released Workspace Manager 2014 SR3 Revision 5 and RES ONE Workspace 2015 Revision 4. In these releases they included a fix for the ‘roaming-cookies’ issue.
Basically they do the same ‘spoof’ with the user profile.
There are a couple of steps that need to be done before enabling this fix:
1. At logon it first checks the version of Internet Explorer. If it isn’t version 11.0.9600.17842 or higher it will give a notice in the ROW/RWM event log and the fix will not work. So update your browser first.
2. Enable the following computer policy:
Location: Computer Configuration – Policies – Administrative Templates – System – User Profiles
Setting: Delete cached copies of roaming profiles
State: Enabled
3. Enable (or actually disable) the following user policy:
Location: User Configuration – Policies – Administrative Templates – Windows Components – Internet Explorer – Internet Control Panel – Security Page – Internet Zone
Setting: Turn on Protected Mode
State: Enabled
Options: Protected Mode – Disable
Or configure this in ROW/RWM with the following keys: (Which obviously is the way to go)
Key: HKEY_CURRENT_USER – Software – Microsoft – Windows – CurrentVersion – Internet Settings – Zones – 1 through 4
Value: 2500
Data: 3
KEY: HKEY_CURRENT_USER – Software – Microsoft – Internet Explorer – Main
Value: NoProtectedModeBanner
Data: 1
4. Add the following registry setting:
Key: HKEY_LOCAL_MACHINE – SOFTWARE – Wow6432Node – RES – Workspace Manager (64-bit)
Key: HKEY_LOCAL_MACHINE – SOFTWARE – RES – Workspace Manager (32-bit)
Value: RestoreCookies
Data: yes
5. Re-add the Internet Explorer user settings in ROW/RWM.
RES WM 2014 SR3 Revision 5 and ROW 2015 Revision 4 both have a new template for the Internet Explorer user settings that contain the required registry and file locations that need to be captured.
That’s it. But keep in mind that this only works for the cookies and not for the internet history.
What I really wanted to talk about
But while I was just planning to write a post about why it didn’t work for a specific customer, I ended up writing all of the above. So back to the customer.
They used a development and a production database for their RES WM 2014 implementation.
Roaming cookies on machines that use the development database worked like a charm. But on machines that use the production machines it would fail most of the time.
FYI: You can check if the cookies are created correctly by looking in the following folder:
For every cookie there should be a .dat file and a .txt file (Enable ‘Show hidden files, folders and drivers’ and disable ‘Hide protected operating system files’). If the RES ‘Roaming-cookies’ fix doesn’t do its job for some reason you will only see the .txt files.
Cause of someone throwing out our cookies
After a lot of testing, comparing settings between databases, ruling stuff out, etc. we found out that there were a couple of authorized files that caused the problem. Authorized files? Yes, you heard/read me correctly. Some people who shall not be named added authorized files that are located at UNC paths. The files in question didn’t exist anymore.
It seems that during logon, those locations are being polled and if they don’t exist, this process takes longer which apparently causes some other stuff to fail.
So we deleted the authorized files and everything was fine. We contacted RES about this and they too can’t explain why this happened. There is the option ‘Do not verify UNC path of security rules when offline’ (Under Setup – Advanced Settings). But this is only when the session is in an offline state.
There is also the option ‘Ping file server to verify UNC path of security rules when online’. However, due to the problem being fixed already, we can’t really test it. So if you are really attached to the UNC authorized files, enabling this might do the trick for you. But personally I would rather clean up outdated authorized files as a solution.
So to sum things up: If you have performed all the prerequisites defined by RES and the cookies still don’t roam, check for outdated authorized files.
