Fixing IE cookie trouble with RES WM

By Max Ranzau


delcookiesFrom the Worlds Greatest Browser (Right…) Dept: In Internet Explorer 10 and up, the WebCacheV01.dat file was introduced. This file lives in %LocalAppdata%\Microsoft\Windows\WebCache. The webcache folder is hidden. The issue at hand is that the webcache file is always in use, which makes for a rainy day if you try to roam/copy IE cookies, or otherwise store them with RES User-Settings. The issue was described back in April by Rob Beekmans on his blog here.

As of now, the problem is rumored to have been addressed by Microsoft on Server 2012, but is still very much alive and kicking on Server 2008, which at the time of writing still represents a large contingent of server deployments out there.

While Mr. Beekmans illustrated the issue, my partner-in-crime the good Mr. Aarts tackled the issue head on, providing a neat and shareable solution with the RES community in the shape of a Workspace Manager buildingblock. By running a couple of strategic Powershell scripts in the users session and including a couple of extra (freeware) utilities as custom resources, the buildingblock solves the problem described above. The Workspace Manager BB includes the following:

  • A PowerShell command to set the PS execution policy to unrestricted to make sure we don’t get any unnecessary prompts when running the following items unattended:
  • A PS script running at logoff, which backs up the current webcache to a location of your choice *1). The script will create two backup .zip files for the two folders WebCache and INetCookies as well. The script will also leave 5 rotated backup file sets.
  • A PS script running at logon to restore the latest backup of these two folders to their original location
  • Both logon/logoff scripts closes all open file handles before making the backup/restore operations.
  • 7zip and SysInternals Handle64.exe are included as RESWM custom resources.

As you may infer, the above essentially extends the WM User Settings with a basic Hybrid Profile – style copyout-copyin script system. This is necessary, as UserSetting would face the same issue as any other UEM; that the target files are locked. I’d say there’s a loud and clear feature request waiting to be implemented here that could solve a lot of potential headaches for customers.

script1Important: As you can see on the screenshot, there is a couple of places you may need to modify the logon/logoff scripts. The destination where the backup files are to be stored defaults to H:\ – you may need to change that. If you already are using a UNC path like \\server\share\%username% for your User Settings, you perhaps want to consider using that as well. Just remember to add a subfolder for this, like \\server\share\%username%\IEbackup or similar. We could of course have added an environment variable so you only had to change the storage destination once, however it’s two edits. Chances are you may survive it :)

Click the brick to download the buildingblock: legobrick-cropped

  • By Barry Schiffer, July 28, 2014 @ 14:20

    Although it’s great tone able to offer a solution I would hate do powershell while logging on or off because powershell is terribly slow. Would be better if we could do this with vb or a simple cmd.

  • By RESguru, July 28, 2014 @ 17:20

    Hi Barry,
    I would agree with you. Perhaps initially it would make good sense to keep an close eye on the logon-time before and after implementing this. There’s an old built-in feature in RES WM that can do that, although it wasn’t designed for said purpose (see this article Another more direct approach could be to compile the PS scripts into .exe’s using for example PowerShell Studio ( I am not sure how much of a performance lift that actually would yield, however it would probably be worth a shot. If you do try this, comment back and let the community know the before and after effects on logon time.

    Thanks for your feedback,

  • By Ferry Stelte, July 31, 2014 @ 07:15

    Hi Max,

    Good solution to a problem which can be very frustrating to customers. Although I did notice something in the building block. I use Server 2008R2 as my SBC platform and implemented the building block to see if everything would work fine. I noticed that I didn’t have a INetCookies folder in my profile (using a local profile which I spoof to roaming at logoff) and thus cookies aren’t saved.
    Isn’t the default location for cookies in Win7/Win2008R2 appdata/microsoft/windows?
    I added an extra variable for the cookies in appdata and after logging off and on, cookies do work now. Am I missing something or am I right in concluding that INetCookies in localappdata are a part of win8/server 2012 and up and cookies in appdata is still win7/win2008R2 related?

  • By Bram Wolfs, July 31, 2014 @ 13:30

    Hi guys,

    This issue has been fixed for IE 10 on 2008R2. The webcache file will now roam, at least if you use roaming profiles. But I’m not sure it will work for existing profiles, I only tested it with new profiles after applying the IE 10 update.


  • By RESguru, July 31, 2014 @ 20:25

    Hi Brams, thanks for clarifying that. Chances are that the 2008 systems, having been around for a while. have existing profiles. I’m working on updating this article as one of our readers found room for improvement. Stay tuned!

  • By Maurice Bonnema, August 1, 2014 @ 01:50

    Nice, thanks for posting. I’m facing this issue on Windows 2012 R2 Xendesktop 7.1 with RES WM 2014 SR1. Causing the Webcachev01.dat is in use it coudn’t be copied by user settings. I will try this solution and will give a feedback on the login time.

  • By Maurice Bonnema, August 1, 2014 @ 02:05

    You can replace the Execute command for the Execution policy by using a commandline like this: powershell.exe -executionpolicy unrestricted -command %script% the executionpolicy will be unrestricted in that powershell session only.

  • By Bram Wolfs, August 1, 2014 @ 02:28

    Another method I have used before the fix is to redirect the webcache to the roaming profile with a symbolic link. All what is needed is a execute command in RES WM at user login :

    rd %userprofile%\AppData\Local\Microsoft\Windows\webcache /s /q
    md %userprofile%\AppData\Roaming\Microsoft\Windows\webcache
    mklink %userprofile%\AppData\Local\Microsoft\Windows\webcache %userprofile%\AppData\Roaming\Microsoft\Windows\webcache /D

    The only downside of this method is that the user needs permissions to create symbolic links. Which can be set in this policy :
    Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Create symbolic links


  • By Maurice Bonnema, August 1, 2014 @ 02:38

    The scripts are running, but at logoff there is notting created on my home dir (changed the path in the script) any idea where to look?

  • By Dennis van Dam, August 4, 2014 @ 22:57

    this kills the taskhost, but what things will not be executed by the taskhost if you kill it? It isn’t there only to keep the IE10 db locked.

  • By Rob Aarts, August 11, 2014 @ 14:29

    @Barry, It would be even better when MS should finally fix this one ;-).

    @Ferry, Thanks for your input. We are working on improvements at this moment.

    @Bram, Thx for your input. We tried Symlinks but after a while we found out that in in some circumstances they didn’t work (we didn’t find the cause off it).

    @Maurice, Thx for your input. Contact me if your still struggling (You need WM 2014 with Dynamic privileges for it).

    @Dennis The script first founds out which processes are locking the file. Only this processes will stopped.

  • By Doede van der Veer, August 18, 2014 @ 07:25

    Scripts are running, folders, files and zip’s have been made. But still cookie warning when i logon again.

  • By Rob Aarts, August 25, 2014 @ 02:20

    Hi Doede,

    Maybe all website information is deleted after you close IE?

    Feel free to contact me if it doesn’t workout.

  • By Dennis van Dam, August 30, 2014 @ 09:23

    Hi Rob, but the Process is always the taskhost, so why search for the process? Still, if it works (and it should work as all other parties say “kill taskhost and you’re done”) it’s a good workaround ;)

  • By Rob Aarts, September 3, 2014 @ 00:33

    Hi Dennis,

    ‘Kill taskhost and you’re done’ could affect other processes to. we only want to stop processes that lock the database file.

  • By Dennis van Dam, September 11, 2014 @ 01:50

    Yeah Rob, but did you ever see another process other than taskhost locking the DB? I didn’t.

    Still if it works, people can use this nice workaround untill someone finds a perhaps better solution ;)

  • By Jos, September 17, 2014 @ 04:07

    Awesome it works! Thanks for the workaround.

    The logon delay is in my case 4 seconds, and the log off 6. It is acceptable in the environment where I implemented it.

    Oh and don’t forget to add the “\” at the end if you change the drive letter to a UNC path. so instead of “\\server\share\%username%” use “\\server\share\%username%\”.

    Thanks again!

  • By Rob van Dick, October 13, 2014 @ 01:45

    Hi Rob,

    First of all thanks for shareing this with us. But I have a problem with it. The scripts are running and the zip files are created, but the zipfiles are not compleet. The WebCacheV01.dat isn’t in the zip file. I think some process still locks the WebCacheV01 file.

    Do you have suggestions for me?


  • By Rob Aarts, October 15, 2014 @ 13:00

    Hi Rob,

    Your welcome ;-)

    Are you using IE10 and Windows 8?
    Can you check your IE settings (policy) about caching the history? if the file is deleted after closing IE we can’t move it.

    Let me know the result pls. see for my contact details.


  • By Mitchel, November 24, 2014 @ 05:08

    Hi Rob,

    Unfortunately this work-around only works partially for me. The logoff script works perfect and the WebCacheV01.dat file is copied and zipped as expected.

    At first it does seem like the login script is working too because it does copy the WebCache folder back to the LocalAppData\Microsoft\Windows folder.

    However when I open up Internet Explorer my browsing history isn’t there. I also noticed that Windows creates WebCacheV01.tmp file next to WebCacheV01.dat.

    I also tried setting the WebCache folder attributes to +S and +H since these attributes are lost in the copying process. Unfortunately this did not help.

    Do you have any suggestions?


  • By Rob Aarts, November 24, 2014 @ 11:36

    Hi Mitchel,

    I hear some rumors that this issue (finally) should be fixed bij MS soon.

    I suggest you take a look at the blog by Rory de Leur

    I have one adjustment on the script off Rory:
    My logoff script first deletes the ‘Webcache’ en ‘Inetcookies’ folders from the network location.


  • By Rory de Leur, November 25, 2014 @ 16:34

    Hi Rob,

    I just updated my article (to busy updating the design and relocate my website), and your last suggestion is now part of it because i run into problems with the webcache about two weeks ago and found it out the hard way. If you do not clean/remove the webcache on the backup location it will corrupt your local cache at logon. The script now removes the cookies and webcache before backup (at logoff).

  • By Rob Aarts, November 26, 2014 @ 01:50

    Hi Rory,

    Great work, together we can resolve this issue (Community Power)

    I shall ask Max if we can place your buildingblocks here (if you don’t mind off course).

  • By Rob Aarts, November 26, 2014 @ 02:04

    Hi Rory,

    We can even make this script more advanced by syncing (not copying) the folders where the folders on the client should be leading.

    In my opinion this could save some time executing the script ;-)

  • By Rory de Leur, December 3, 2014 @ 03:51

    Rob, syncing will out perform the copy if you got a slow network connection (it has to perform a diff), But maybe zipping it to the file server (instead of coping) can work, and that can be done with powershell. The backup guys will see a huge difference.

  • By Michael Baars, December 1, 2015 @ 00:44

    We just solved an issue at a customer where cookies (for IE10 or IE11) were not roaming for VDI. After several hours with tech support from Microsoft finally a solution (actually: it already exists) was found.

    It appears that this issue is originating as ‘we’ administrators were frustrating Microsoft with the case that cookies generate to many tiny files, which impact for example (backup) performance or logon/logoff (roaming, copying it to/from the server). Also the large amount of files require a lot of file IO when accessing these cookies.

    As a solution Microsoft introduced with IE10 a new concept, a database that is stored in the local appdata part of a user profile. The downside to this is that the database is exclusive locked when Internet Explorer is active, and even minutes after it is closed. This also is the case if an IE window is integrated in another application (and this is often, I can assure to you). This means that the database is locked most of the time and prevents backing it up using for example RES ZeroProfiling (or any other solution). And as it is in local appdata, it also does not roam.

    The solution would be a setting like “Enable roaming cookies”.

    The funny thing: This setting exists! It is just called a bit different, like “Delete cached copies of roaming profiles”.
    The official description:
    Why didn’t i interprete it this way?!?

    The description so it is available even if the link ever goes down:
    If you enable Group Policy, any local copy of a user’s roaming profile is deleted when the user logs off. However, the roaming profile still remains on the network server that stores it.

    You can configure a Group Policy Object (GPO) to perform the preceding behavior by performing the following steps:
    1.Edit the GPO that you want to modify.
    2.Locate the following section: Computer Configuration \ Administrative Templates \ System \ User Profiles.
    3.Double-click Delete cached copies of roaming profiles (the Group Policy setting).
    4.Click Enabled.

    After setting this policy (and allowing it to be distributed among your domain controllers and become active… give it some time), you will see the following behavior:

    In the folder “%APPDATA%\Microsoft\Windows\INetCookies” (Win 8/10/2012) or “%APPDATA%\Microsoft\Windows\Cookies” (Win 7) besides the common .TXT files there will be additional .DAT files. These contain the information to be able to rebuild the cookie database.

    Good luck using this information and make sure it does not cost you weeks (like it did in our case)!

Other Links to this Post

  1. Technotes from an Application& Desktop Delivery Professional » Microsoft won’t give me my cookies — October 13, 2014 @ 06:07

  2. Microsoft won't give me my cookies - — November 13, 2014 @ 18:55