none
Internet Explorer 10 cookies and roaming profiles (WebCache directory)

    Discussão Geral

  • Hi,

    I'm having a cookie problem on 2 out of 2 tested environments using Windows Server 2008 R2 (with roaming profiles) and Internet Explorer 10 (IEAK'ed) :S

    For instance when I login to www.google.com with my username and password, as long as I'm using my Windows session I'm logged in to www.google.com every time I open the browser (with all iexplore.exe processes closed before). When I logoff my Windows session my (roaming) profile is beeing saved on the fileserver and the locally cached Windows profile is beeing deleted.

    When I logon to Windows again (on the same computer) the roaming profile is beeing copied from the fileserver to my client (including the .txt cookies), but www.google.com isn't logging me in automatically. The same thing happens with other cookies related stuff on websites :S

    Also tried WITH and WITHOUT folder redirection for AppData/Cookies/etc, even a newly installed environment with Microsoft defaults is giving me problems.

    Anybody out there having the same problem ?


    sexta-feira, 1 de março de 2013 14:22

Todas as Respostas

  • Hi,

    do you have the google toolbar installed?

    google have markup on their pages that uses methods from their toolbar and bho's.

    Regards.


    Rob^_^

    sábado, 2 de março de 2013 00:14
  • In my newly created test setup I have nothing installed, just a clean Windows 2008 R2 as a workstation and a clean Windows Server 2012 domain controller hosting the roaming profile path, so no 3rd party software involved.

    Waiting for others to see the problem as well, I will try an IE10 installation WITHOUT IEAK to see if that's any good.

    sábado, 2 de março de 2013 08:30
  • Hmm, quick test without IEAK showed me good results, will try several things/upgrades/installs to see what's causing the problem
    sábado, 2 de março de 2013 10:14
  • Update, looks like existing IE8 cookies do work the first time a user logs in to a machine with Internet Explorer upgraded to v10 (with or without IEAK). The second time they login the cookies fail.

     

    Tried everything from modifying security zones, cookie settings, compared serval registry and profile data from different logons and configs, but that didn't help.

     

    Without deleting the locally cached Windows profile at logoff everything works like a charm(!), hmm, will try to tweak ntuser.ini to see if they are beeing stored within Local or LocalLow with IE10.

    sábado, 2 de março de 2013 12:16
  • With the Local and LocalLow profiles EXCLUDED (so they ARE beeing transfered to the roaming profile UNC path at logoff) from the ExcludeProfileDirs under HKCU\Software\Microsoft\Windows NT\CurrentVersion\WinLogon everything works as it should.

     

    Found out that %LocalAppData%\Microsoft\Windows\WebCache is "causing" the problem, when searching for that on the internet I saw IE10 uses a new file structure for it's history, cache & cookies @ http://blog.nirsoft.net/2012/12/08/a-few-words-about-the-cache-history-on-internet-explorer-10/

     

    Now we'll have to find out if we can redirect that directory somehow or open a case at Microsoft.

    sábado, 2 de março de 2013 12:45
  • Microsoft case opened

    segunda-feira, 4 de março de 2013 09:56
  • Microsoft reproduced the problem, looks like a design flaw by me
    sábado, 16 de março de 2013 17:55
  • Hello,

    Not an answer, but the site I'm working at has the same issue.

    Windows 7 with IE10 and Persona.  (Works like roaming profile)

    Please let me know what Microsoft response was.

    For us because we have Windows 7 we are downgrading to IE9 and blocking IE10 from Windows Update for now.


    Walter

    terça-feira, 26 de março de 2013 00:06
  • Hi Richard,

    I'm having the same issue.

    Could you please let me know what Microsoft response was.

    Maurits

    terça-feira, 9 de abril de 2013 12:40
  • Can't share that much information since I may not share internal information, but the problem has been reproduced and they're evaluating/working on a fix. Better to open a support case yourself and get the info from Microsoft. Besides the info they also know others have the issue as well than.

    We're using IE8 right now and I don't know if we wait for the fixed version or move to IE9/Chrome Enterprise instead.

    terça-feira, 9 de abril de 2013 12:51
  • I don't have SA for Windows 2008 r2 server, only for Office 2013.

    Used my gpo's to change the registry key:

    Orginal key:
    [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
    "ExcludeProfileDirs"="AppData\\Local;AppData\\LocalLow;$Recycle.Bin"

    Adjusted key:
    [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
    "ExcludeProfileDirs"="$Recycle.Bin"

    quarta-feira, 10 de abril de 2013 10:41
  • Good luck with that :)
    quarta-feira, 10 de abril de 2013 16:20
  • Hi Richard,

    So is your problem solved?

    What I have seen is that %appdata%\Microsoft\Windows\Cookies contains cookies but when roaming this directory only with the needed IE data, the cookies won't work.

    So it looks like the %localappdata%\Microsoft\Windows\WebCache directory contains important information which will make the roaming cookies work.

    The problem with the WebCache is that after closing IE several files are still in use by windows processes making it impossible to copy it or perform actions on it.

    terça-feira, 23 de abril de 2013 12:44
  • Problem hasn't been solved yet, Microsoft is working on a fix.

    Correct, the WebCache database contains pointers/links to the real cookies, when that database gets deleted Internet Explorer thinks the website doesn't have a cookies stored yet and it's creating a new cookies and pointer/link again in the WebCache "database".

    I like the idea, but I'm still wondering after all this time why someone at Microsoft decided to store that outside the "Roaming" part of the profile...

    terça-feira, 23 de abril de 2013 19:30
  • Yes indeed. But Microsoft has done it before and created policies to put it in the roaming part manually. I'm sure it's done because of the size of the whole WebCache dir. If Microsoft did put it in the roaming part people would say the opposite and would complain about why Microsoft put such large directory in the roaming part of the profile.

    But I hope they will fix it in a way that after closing Internet Explorer, no process keeps the files in use so we will be able to copy over the WebCache dir without any problem.

    Update: I found some handy information about why and how it works:

    http://www.ericlawrence.com/eric/show.asp?entry=4/3/2013%205:27:00%20PM

    Update 2: I saw that the auto login on gmail.com doesn't work but when I double click on the login field I see my name appear which I saved in me previous session (localprofile is deleted and using a roaming profile). So it works partially without the WebCache folder content.

    • Editado MobileMeneer quarta-feira, 24 de abril de 2013 12:46
    quarta-feira, 24 de abril de 2013 05:44
  • Problem hasn't been solved yet, Microsoft is working on a fix.

    Correct, the WebCache database contains pointers/links to the real cookies, when that database gets deleted Internet Explorer thinks the website doesn't have a cookies stored yet and it's creating a new cookies and pointer/link again in the WebCache "database".

    I like the idea, but I'm still wondering after all this time why someone at Microsoft decided to store that outside the "Roaming" part of the profile...

    Any updates on this?  I tried IE9 and am getting the same exact behavior as with IE10 so it's back to IE8 for now...  

    (2K8R2 & XenApp 6.5 using RDS profiles)


    • Editado IKeyz quinta-feira, 13 de junho de 2013 16:47
    quinta-feira, 13 de junho de 2013 16:45
  • They're still working on a fix for IE10/IE11.

    IE9 does not have the same behaviour for us.

    terça-feira, 2 de julho de 2013 10:56
  • Any news about a fix for this issue? We have the same problem after upgrading to Internet Explorer 10 on our RDS environment. The workaround to copy the "local" folders into the roaming profile is not acceptable for us, we want to keep the roaming profile as small as possible for better logon times.
    quarta-feira, 21 de agosto de 2013 05:41
  • The only news is the fix is postponed a couple of times, will not be ready before december.

    IE11 in Windows 8.1 (aka Blue) should be fixed when it hits RTM.

    I hope they release a downloadable IE11 for Win7/Win2012 this year as well, so maybe we can skip IE10

    quarta-feira, 21 de agosto de 2013 05:48
  • I seem to be having success working around this by changing the "Local AppData" registry value within the User Shell Folders key in the user registry hive. Not done a huge amount of testing to look for undesired side effects, but my cookies are now working between Windows sessions on 2008 R2 with IE 10.

    Details here: http://rcmtech.wordpress.com/2013/08/30/internet-explorer-10-not-saving-cookies-when-roaming-profile-used/

    Please let me know if you try this and notice anything weird!


    • Editado robincm2 sexta-feira, 30 de agosto de 2013 22:58 typo
    sexta-feira, 30 de agosto de 2013 15:25
  • Where do you think your temporary internet files (and bunch of other sh*t that should be deleted) are beeing stored ?
    sexta-feira, 30 de agosto de 2013 15:34
  • I mentioned this in the blog post. "Temporary internet files" are stored in

    %USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files

    as referenced in the registry in the "User Shell Folders\Cache" value.

    Because "temporary internet files" has its own User Shell Folders entry, which specifies a folder within %userprofile%, they remain "local" and are still discarded at logoff as desired. Now there may well be other stuff that should be discarded and won't be, but that's why I posted this, to see if anyone had noticed anything.

    Have you tried it?

    sexta-feira, 30 de agosto de 2013 22:57
  • No, and won't try :)

    But you'll have to add some about the %temp% folder as well.

    sábado, 31 de agosto de 2013 06:20
  • %temp% also references %userprofile% in the registry and thus also still points to C:\


    • Editado robincm2 segunda-feira, 2 de setembro de 2013 07:59 technical update
    segunda-feira, 2 de setembro de 2013 07:52
  • I have a similar solution that copies cookie data off of a remote server at the end of a session/logoff and restores it at the beginning of the next session.  This solution uses AppSense, not roaming profiles, but the goal is the same I think.  What we found was that the WebCache database was not being copied off to the permanent storage.  We added a step that terminated the IE process prior to logoff and then it seemed to work.

    However, it's still acting a bit strange.  The cookie txt files are restored to the remote server at login, but IE then creates duplicate txt files with, what appears to be the same content.  I'm trying to figure out why that is happening and stumbled on this thread.

    quarta-feira, 23 de outubro de 2013 00:39
  • The local AppData folder is a location to store application data. Windows uses the Local and LocalLow folders for application data that does not roam with the user. Usually this data is either machine specific or too large to roam. I would recommend not to make registry changes to redirect the AppData/Local folders to the roaming profiles share. Doing so can cause unexpected issues. Microsoft is aware of the issue and is working on a solution. I will post back once a solution has been identified.

    Thanks!

    AJAYPS - MSFT


    segunda-feira, 11 de novembro de 2013 13:32
  • Thanks for the update!

    For those of us who can't afford to wait for that, I've been running this for a few months now and no nasty side effects have popped up yet (aside from each user's network storage growing by ~32MB the first time they log on when the WebCacheV01.dat file is created).

    I know it's not ideal, but when these situations are imposed on us we have to find workarounds until the official solutions are released.

    I hope this thread will be updated by somebody from Microsoft when the official solution has been released.

    segunda-feira, 11 de novembro de 2013 13:49
  • jolly --> http://www.bink.nu/internet-explorer-11-for-windows-7-and-windows-server-2008-r2-released


    Really disappointed that IE11 does NOT solve the problem. :-(
    domingo, 17 de novembro de 2013 16:47
  • Microsoft is aware of this issue for months but still no workable solution. In the meantime IE11 is released with the same issue. Everyone (including Microsoft) tells us to keep your browser up to date, but that's not possible with this webcache roaming issue.
    quarta-feira, 11 de dezembro de 2013 08:33
  • Gotta love MS. Does anyone have any update on whether there is even a workaround for this issue aside from redirecting the entire Appdata folder for roaming?
    quinta-feira, 23 de janeiro de 2014 20:45
  • Looks like I have exact same issue using Redirection of Cookie directory.  Very disappointing.....
    quinta-feira, 30 de janeiro de 2014 22:08
  • Any news on the fix?


    Sysadm

    terça-feira, 18 de fevereiro de 2014 20:36
  • Nice, looking forward to the release of the hotfix
    sexta-feira, 21 de fevereiro de 2014 10:38
  • Good news! Hope they will release this hotfix soon enough!

    sexta-feira, 21 de fevereiro de 2014 14:42
  • Is there any public info about the fix available yet, even if the installer can't be downloaded?

    How does the "fix" work? Move the webcachev01 to the roaming part of the profile?

    Or have they re-though the whole thing? (again)

    sexta-feira, 21 de fevereiro de 2014 14:56
  • use a MDlink

    mklink C:\Users\user\AppData\Local\Microsoft\Windows\webcache \\roamingprofilefolder /D

    users must have rights for: Create symbolic links

    works for me on a citrix farm

    quarta-feira, 26 de fevereiro de 2014 15:52
  • Great idea.  I would love to implement that but I have had issues where the symbolic links won't stick from session to session since "Local" doesn't roam and the script to create it requires administrative rights.  Have you run into that or overcome it?
    quarta-feira, 26 de fevereiro de 2014 17:53
  • Can you send the fix to us?? Thanks, Ash

    quarta-feira, 26 de fevereiro de 2014 22:15
  • We're also having these problems after updating to IE11 (from IE9) on our terminal servers.
    Users started complaining that their "internet settings" are not saved (by which they mean cookies).

    I've tried setting up a sync job to their home drive (with RES Workspace Manager) at log on and off, but this means syncing another (at least) 30 MB at logon which slows down the logon process. It would be easier if the WebCache folder was redirectable or even better of it was kept in the Roaming part of AppData...

    Waiting for a hotfix...

    quarta-feira, 5 de março de 2014 07:33
  • We're also having these problems after updating to IE11 (from IE9) on our terminal servers.
    Users started complaining that their "internet settings" are not saved (by which they mean cookies).

    I've tried setting up a sync job to their home drive (with RES Workspace Manager) at log on and off, but this means syncing another (at least) 30 MB at logon which slows down the logon process. It would be easier if the WebCache folder was redirectable or even better of it was kept in the Roaming part of AppData...

    Waiting for a hotfix...


    Same here...
    quarta-feira, 5 de março de 2014 07:43
  • I had a major issue with Cookies on IE 11 within a xenapp 6.5 environment, users have roaming profiles. Cookies was just not working.

    I changed the setting in privacy settings on the citrix servers to allow cookies and this made no difference in the end I downloaded the IECW for IE 11

    I created a custom setting for the privacy tab run this on each xenapp server and it worked. Was banging my head on the wall for 2.5 days trying to get cookies working.

    I don't know if this will help anybody thought it worth sharing.

    quarta-feira, 5 de março de 2014 11:29
  • I had a major issue with Cookies on IE 11 within a xenapp 6.5 environment, users have roaming profiles. Cookies was just not working.

    I changed the setting in privacy settings on the citrix servers to allow cookies and this made no difference in the end I downloaded the IECW for IE 11

    I created a custom setting for the privacy tab run this on each xenapp server and it worked. Was banging my head on the wall for 2.5 days trying to get cookies working.

    I don't know if this will help anybody thought it worth sharing.


    we're also running xenapp 6.5 with roaming profiles, so I'm definitely interested ;-)
    • Editado Laggetjeuh quarta-feira, 5 de março de 2014 11:34 definately doh
    quarta-feira, 5 de março de 2014 11:33
  • cool - just to give you the full picture I install the IECW on a DC with IE 11 installed- had to install IE 11 on there to update the GPO settings, by doing this it automatically installs the adxm files etc...

    I created the custom app on the same box (the DC)

    again don't know if this helps but thought I would share the full story

    quarta-feira, 5 de março de 2014 11:40
  • use a MDlink

    mklink C:\Users\user\AppData\Local\Microsoft\Windows\webcache \\roamingprofilefolder /D

    users must have rights for: Create symbolic links

    works for me on a citrix farm

    After some playing I have it successfully running in my place too.  The security issues I was running into was resolved with a Group Policy to allow users to create symbolic links.  Its a Computer Security Policy.  Then I attached this script to login and all is good, I use a Symbolic link to point it to a folder int eh Roaming part of the user profile.  Thanks for pointing me in the right direction.

    rd C:\Users\%username%\AppData\Local\Microsoft\Windows\webcache /s /q

    md C:\Users\%username%\AppData\Roaming\Microsoft\Windows\webcache

    mklink C:\Users\%username%\AppData\Local\Microsoft\Windows\webcache C:\Users\%username%\AppData\Roaming\Microsoft\Windows\webcache /D

    Royalties accepted in bitcoins....

    quarta-feira, 5 de março de 2014 17:07
  • wouldn't it be better to point the link to a location that isn't part of the roaming profile?

    when using the roaming part it will increase the roaming profile with at least 30MB, which has to be loaded and unloaded at logon/logoff. I'm thinking of pointing it to another location, like the user's ts home drive...

    quinta-feira, 6 de março de 2014 07:42
  • We are having the same issue and opened a support ticket with MS a few days ago in hopes of getting a "private hotfix". No luck with that. The only thing the support tech. could tell us that MS has a hotfix that they are testing and will be released in the next cumulative update but they had no idea when that would be. Does anyone know if MS actually has a set schedule for releasing IE Cumulative Updates?

    Thanks,

    Steve Barth

    quinta-feira, 6 de março de 2014 14:36
  • Hey Steve

    I did the same... This is MSS answer:

    Yes, as you have seen this is a known issue for us and the steps needed to release a fix are still in progress. What you read in that forum is not entirely true, there has never been a hotfix created for this issue and we only provided private bits to selected customers to validate the correctness of the fix: in fact, that information should not have been shared publicly. I’m sorry but there’s no private bits I can provide currently, so we’ll have to wait for the official release. This is currently set for April but still under confirmation: I should have more information in the coming weeks.

    sexta-feira, 7 de março de 2014 07:47
  • Hey

    From MSS:

    I have some news to share on the release of this fix. All testing has completed properly and we're currently aiming the April release cycle for the IE10 fix and the May release cycle for IE11 fix. This is mainly due to the upcoming update for Windows 8.1 (the OS version tied to IE11), so this separate release is mainly motivated by that fact. I understand this separation is not something we would want, but this is what we have to work with.

    The April release is scheduled to hit the streets on the 8th at 10:00 AM Redmond time, whereas the May release is set for the 13th of May, with the same time frame.

    Looking forward to the fix ;)

    Michael

    segunda-feira, 10 de março de 2014 18:24
  • Thanks for the info.

    Would be nice to get some detail about how the fix will work: I'm slightly concerned that the "fix" will not migrate existing cookie data, and depending on how it "fixes" the issue and what migration steps it takes, I'll probably want to undo the workaround I've been using once the official fix has been installed.

    quarta-feira, 12 de março de 2014 12:54
  • Installed the april updates on a couple of test desktops (Windows 7, IE10), roamed between them while checking out websites that I know are storing cookies in the user profile, and...

    ...the issue's still not fixed. At least not for me.

    IE10 is still creating the WebCache in the Local part of the AppData folder, with nothing to imply that anything is done differently this time around.

    Has anyone else installed the latest updates and gotten better results?

    terça-feira, 8 de abril de 2014 21:15
  • No luck on 2008R2, IE10 as well :-/
    quarta-feira, 9 de abril de 2014 09:46
  • Maybe it will be an hotfix thats needs to download manualy not from the automatic updates

    how can we know if they release one?

    quinta-feira, 10 de abril de 2014 07:15
  • Here's to hoping that either Michael_DK or Steven Barth (or anyone who's opened a ticket with Microsoft) chime in soon to tell us what MSS has to say about this.

    I really don't mind that this - IMO - serious bug has been left unfixed for over a year now. I think what's killing most of us is that Microsoft itself can't seem to provide a reliable ETA for the fix. It makes any kind of planning for us lowly admins impossible.

    As mentioned by a couple of posters before, yes, there are plenty of workarounds available. I've got the workaround using the symbolic link tested and ready for deployment. However, like robincm2, I do not wish to see the workaround being unceremoniously undone by the hotfix - when it finally arrives - and creating a ton of grief for our end users in the process.

    quinta-feira, 10 de abril de 2014 08:47
  • Hi folks

    Thanks for your patience with this. Please see:http://support.microsoft.com/kb/2955387

    Regards

    Mark.


    Mark Feetham Senior Program Manager Internet Explorer Supportability


    quinta-feira, 10 de abril de 2014 12:06
  • are the cookies still stored in the same location in the userprofile after applying the update?

    because I'd like to move my user cookies (which are now redirected to their ts home folder with a symlink) back to the location that is now supposed to be roaming...

    (haven't heard any reactions about it actually working though so I'll wait until I do, IE11 on 2008R2 here btw)

    edit: installed all available updates on our test environment (2008r2 with ie11) where the symlink workaround is not active and cookies are still NOT saved.

    • Editado Laggetjeuh quinta-feira, 10 de abril de 2014 14:14
    quinta-feira, 10 de abril de 2014 12:17
  • Well, I don't know what's more disheartening: not knowing whether the hotfix was included with the latest updates, or knowing that the supposed fix is included, but finding out that it isn't working as intended :/

    Just built up another test environment (Windows 7, IE10, roaming profiles), making sure that the cumulative update (KB2936068) was indeed installed ... and confirmed that cookie roaming still isn't working.

    Delving into the folder locations that IE is using, I'm still seeing that:

    - The actual cookie files are going to %APPDATA%\Roaming\Microsoft\Windows\Cookies\

    - The WebCache database and logs are going to %LOCALAPPDATA%\Microsoft\Windows\WebCache\

    So what is the hotfix doing differently? Did the hotfix enable a hidden option to configure the WebCache location?

    quinta-feira, 10 de abril de 2014 15:08
  • It still doesnt work, would be nice to get some more information about this.

    (If you read kb955857 they talk about "Windows 8-based computer". What about, Windows 2008R2?)

    sexta-feira, 11 de abril de 2014 11:09
  • Hi.

    Can anybody confirm that cookies and roaming profiles are now working correctly?

    As more and more websites are not beeing deisplayed correctly with older browsers we have to take the decision whether to wait somewhat longer for MS to fix the problem or rollout Firefox for all our customers.

    Thanks.
    sábado, 19 de abril de 2014 11:37
  • Hi.

    Can anybody confirm that cookies and roaming profiles are now working correctly?

    As more and more websites are not beeing deisplayed correctly with older browsers we have to take the decision whether to wait somewhat longer for MS to fix the problem or rollout Firefox for all our customers.

    Thanks.

    can't confirm. can only deny on win2008r2 with ie11.
    terça-feira, 22 de abril de 2014 05:33
  • Windows 2008 R2/XenApp 6.5 combo with roaming profiles and same problem here since rolling out IE10. As an attempt to fix, I've redirected the local appdata folder to the user's home folder for a couple of users (my own account included).

    This sort of works except if you happen to logon to two XenApp sessions, IE won't open on the second session - one assumes because both XenApp servers are attempting to access the same webcache database and it's locked by the first session.

    As users do occasionally logon to two XenApp servers at the same time, redirecting local appdata in this way isn't exactly compelling - as well as putting a bigger strain on the LAN - whereas access to the local C: drive goes across the bigger VHDX/MPIO SAN network.

    Why oh why didn't they just put the webcache in the roaming profile????

    terça-feira, 22 de abril de 2014 12:35
  • http://support.microsoft.com/kb/2955387 isn't really applicable as mentioned above, it only mentions Windows 8 and this thread is mainly about Windows 2008 R2 and XenApp.

    terça-feira, 22 de abril de 2014 12:37
  • Windows 2008 R2/XenApp 6.5 combo with roaming profiles and same problem here since rolling out IE10. As an attempt to fix, I've redirected the local appdata folder to the user's home folder for a couple of users (my own account included).

    This sort of works except if you happen to logon to two XenApp sessions, IE won't open on the second session - one assumes because both XenApp servers are attempting to access the same webcache database and it's locked by the first session.

    As users do occasionally logon to two XenApp servers at the same time, redirecting local appdata in this way isn't exactly compelling - as well as putting a bigger strain on the LAN - whereas access to the local C: drive goes across the bigger VHDX/MPIO SAN network.

    Why oh why didn't they just put the webcache in the roaming profile????

    Noticing the same problems with redirecting the webcache to users' TS home folder here.
    When users have 2 terminal server sessions active, IE just won't launch in the second session. Eventlog reports that the webcache files are in use (which is true because the first session is using them).

    terça-feira, 22 de abril de 2014 12:39
  • Actually the above isn't true - the scenario mentions Windows 8 but the "applies" to says just IE10 so infers all operating systems.

    Does anyone know what change has been made, i.e. have they moved webcache to the roaming profile?

    terça-feira, 22 de abril de 2014 12:45
  • Does anyone know what change has been made, i.e. have they moved webcache to the roaming profile?

    Well, I had a 3 hour remote assistance session with MSS last week (without results, by the way), and all they could confirm was that the cumulative update is supposed to include the WebCache in the set of files that is copied over to the user's roaming profile upon logoff. No change was made to the location where IE10 initially saves the WebCache - ie. it's still being saved in the LocalAppData, and not in the roaming profile.

    When I asked for the exact location in the roaming profile where the WebCache is supposed to go, I did not get a definite answer.

    I know for a fact, however, that any attempt to copy the WebCache files without first breaking the file locks held by a Windows process (don't remember the exact one - it can be found by using Process Monitor) is going to fail, so perhaps that's why the hotfix isn't working as intended.

    I did not test further, however, because I've kind of lost hope that a proper fix is forthcoming. For now I've also implemented the workaround by using a symbolic link to redirect the WebCache folder. The fact that IE can't be used in two desktops sessions is something I'm willing to accept.

    quarta-feira, 23 de abril de 2014 08:26
  • Hard to belive that MS did not realize such design flaw in the early development phase of IE10.

    For me it seems obvious that if you try to combine files which are saved in different "storage locations" (romaing data and non-romaing data) into one file you will get into trouble. Simply putting all into the romaing part will blow up romaing data massively (as internet cache is then part of it) that this could not be the solution.

    So for me this seems to be a typical catch 22 .

    quarta-feira, 23 de abril de 2014 09:25
  • It is rather surprising that nobody went "hang on" when such big change was made to a key function. Doesn't Microsoft think anyone uses RDS or XenApp or any of the other remote desktop systems?

    That said, moving the cookies specifically from thousands of small text files into one database does make sense. The overhead of downloading thousands of small files (timestamp check, open for read, open for write, read data, write data, close files) is probably more than copying one ~30MB file across a high-speed LAN.

    Chrome isn't that much better in this area.

    So looks like it's still broken over a year after the fault was first reported? Not good...

    quarta-feira, 23 de abril de 2014 14:30
  • sexta-feira, 25 de abril de 2014 09:42
  • For now I've also implemented the workaround by using a symbolic link to redirect the WebCache folder. The fact that IE can't be used in two desktops sessions is something I'm willing to accept.

    Could you not symbolically link the folder from %LocalAppData%\Microsoft\Windows\WebCache to %AppData%\Microsoft\Windows\WebCache (i.e. the roaming area) which would then copy back to the network on logoff but also not have the problem of shared file access?

    Cheers, Rob.

    sexta-feira, 25 de abril de 2014 10:38
  • Ohh hang on - that's not going to work is it because isn't the webcache file locked and therefore wouldn't roam correctly?
    sexta-feira, 25 de abril de 2014 10:42
  • Initial feedback from me is that the hotfix isn't working either. The hotfix is confirmed as installed but on logging off, I cannot see WebCache anywhere in my roaming profile on the network.
    sexta-feira, 25 de abril de 2014 11:13
  • The are using a 3rd party user management system to manage profiles so not sure we should get too excited about it fixing the problem with normal roaming profiles because it's ain't working here :-(

    It would be useful if Microsoft could give some hint as to how they have supposedly fixed this? If the file is still in the same folder, have they manually fudged the roaming profile code to handle this one case specifically and in which case, where should it appear in the roaming profile? That would, I assume, require a change to the OS and this was an IE fix. Or some other mechanism entirely.

    Have they just ensured that the file is unlocked during logoff so some other mechanism?

    sexta-feira, 25 de abril de 2014 12:06
  • Ohh hang on - that's not going to work is it because isn't the webcache file locked and therefore wouldn't roam correctly?

    Correct.

    In fact, I have actually tested a scenario where I used a logoff PowerShell script to first kill the process(es) holding the file locks on the WebCache, then copying the files to the user's home share. The files would then be copied to the user's Local AppData upon logon.

    However, we're dealing with a VDI environment that is rather delicately sized IOPS-wise, so the idea of having all these WebCache files transferring back and forth all day long for hundreds of users didn't sit well with me. I may still rework my workaround to function like this in the future, but for now, all seems well. I haven't had complaints yet.

    The reason why the locks on the WebCache aren't released when you close off Internet Explorer is - according to MSS - that the WebCache mechanism is (or will be) used for more than just IE.

    sexta-feira, 25 de abril de 2014 16:01
  • It's all a bit of a mess isn't it ;-) I can't blame Microsoft too much as hindsight is a wonderful thing but all of this "user settings/profile" malarkey feels like a "I wouldn't start from here" response. I don't think even Google with Android who had a clean sheet have done this much better except most of the apps are "cloud aware" when it comes to their settings. But even then, roaming to a second device (e.g. tablet & phone) doesn't work all the time.

    But I do think they should have changed webcache.dat from the local app data folder to roaming and then given a way of moving it via the registry. If in the roaming profile, one could easily exclude it from roaming via an exclusion if needed.

    So for those users whereby copying a 30MB file each log on/off isn't too worrying (and to be honest, that's not a very big file), then the default would be it just worked.

    sexta-feira, 25 de abril de 2014 16:26
  • So for those users whereby copying a 30MB file each log on/off isn't too worrying (and to be honest, that's not a very big file), then the default would be it just worked.

    To also be honest this really depends on your situation.

    Some of us have to deal with rather large number of users so 30MB isn't much that's true however 30MB*number of users can be quite a lot.

    Seems like MS more and morer focuses on the individual cloud user and ignores the demand of the admins who try to get their things working in large enterprise.

    I'm also really tired of installing a Web browser and getting an OS update instead, and this is not the first time.

    Sorry but I'm really annoyed meanwhile.

    sexta-feira, 25 de abril de 2014 17:01
  • So for those users whereby copying a 30MB file each log on/off isn't too worrying (and to be honest, that's not a very big file), then the default would be it just worked.

    ..snip..

    Sorry but I'm really annoyed meanwhile.

    As I said, for those of us where it isn't worrying. If you are worried about this kind of thing, you're already in the loop of controlling profiles very carefully. We're in the middle ground I suspect - we've got ~150 XenApp users on a pretty high speed backbone with plenty of XenApp host capacity and MPIO SAN that really isn't too stressed.

    But yes, I'm annoyed too that cookie roaming in XenApp is broken. We have enough trouble defending XenApp sometimes - it's blamed for every crash even though 99% of the time, the application fault also occurs outside of XenApp as well ;-)

    The solution is to throw it all away and start again but that would be us living in cloud cuckoo land - Microsoft is caught in a rock and hard place re: backwards compatibility. I get equally defensive when people say "Look at all those mistakes Microsoft made with IE". It's very easy to throw rocks in hindsight when people like Google with Chrome can benefit from all the mistakes the real trailblazers made...

    sexta-feira, 25 de abril de 2014 17:17
  • I know the question is for 2008r2 but does this work if you go to 2012 RDS with User Profile Disks?

    terça-feira, 6 de maio de 2014 23:26
  • use a MDlink

    mklink C:\Users\user\AppData\Local\Microsoft\Windows\webcache \\roamingprofilefolder /D

    users must have rights for: Create symbolic links

    works for me on a citrix farm

    1. Can someone help me accomplish the same for my farm? 

    2. The webcache folder on my golden image gives me the "file open or in use" message when I test creating a symbolic link.

    3. If/when I do figure out how to make it allow me to link the WebCache folder will it apply to all profiles if I use the %username% variable? 

    segunda-feira, 12 de maio de 2014 12:40
  • Re: #3 - I suspect not - you'll have to try and script this per user. Something in the logon script maybe? It's a right old mess IMO!

    segunda-feira, 12 de maio de 2014 15:10
  • use a MDlink

    mklink C:\Users\user\AppData\Local\Microsoft\Windows\webcache \\roamingprofilefolder /D

    users must have rights for: Create symbolic links

    works for me on a citrix farm

    1. Can someone help me accomplish the same for my farm? 

    2. The webcache folder on my golden image gives me the "file open or in use" message when I test creating a symbolic link.

    3. If/when I do figure out how to make it allow me to link the WebCache folder will it apply to all profiles if I use the %username% variable? 

    Use something like this at logon:

    rd C:\Users\%username%\AppData\Local\Microsoft\Windows\WebCache /s /q

    If exist "H:\WebCache\" goto mklink

    md "H:\WebCache"
    :mklink

    mklink "C:\Users\%username%\AppData\Local\Microsoft\Windows\WebCache" "H:\WebCache" /D


    Information:
    H: would be your home drive...
    To let users make a mklink, GPO: COMPUTER\Windows Settings\Security Settings\User Rights Assignment\Create symbolic links

    terça-feira, 13 de maio de 2014 07:58
  • Okay, I've made some progress on this today and it's working so far. It's still unclear what the following article/IE hotfix actually does:

    http://support.microsoft.com/kb/2955387/en-gb

    Because it's certainly doesn't magically fix getting cookies to fully roam - the webcache is still in the same folder. However, I think what it fixes is the problems reported above whereby any other stuff one want's to do with webcache fails because the files are locked most of the time.

    So with this hotfix in place, I was able to implement the following PowerShell logon script:

    $SourcePath = "$LocalAppData\Microsoft\Windows\WebCache"
    $LinkExists = $False
    If (Test-Path $SourcePath) {
    	$Attributes = (Get-Item -Path $SourcePath -Force).Attributes
    	$LinkExists = [Bool]($Attributes -band [IO.FileAttributes]::ReparsePoint)
    	If (!$LinkExists) {
    		If ($Debugging) {Write-Host "Debug: deleting old webcache folder"}
    		Remove-Item -Path $SourcePath -Recurse -Force -ErrorAction SilentlyContinue
    	}
    }
    $TargetPath = "$RoamingAppData\Microsoft\Windows\WebCache"
    If (!(Test-Path $TargetPath)) {
    	If ($Debugging) {Write-Host "Debug: creating new webcache folder"}
    	[void](New-Item -Path $TargetPath -ItemType Directory)
    }
    If (!$LinkExists) {
    	Write-Host "Configuring IE webcache to roam"
    	$Cmd = "cmd /c 'mklink /d " + $SourcePath + " " + $TargetPath + "'"
    	Invoke-Expression $Cmd 2> $Null
    }

    $LocalAppData and $RoamingAppData are variables that point to here:

    C:\Users\myusername\AppData\Local
    C:\Users\myusername\AppData\Roaming

    What the script basically does is this set-up a symbolic link that links:

    "C:\Users\myusername\AppData\Local\Microsoft\Windows\WebCache"

    To:

    "C:\Users\myusername\AppData\Roaming\Microsoft\Windows\WebCache"

    When one logs off, WebCache roams to the network. When one logs on, it roams back and so far, cookies appear to be sticking. We use Spiceworks and before one had to type username & password each time. In my test, the logon details are persisted.



    quarta-feira, 14 de maio de 2014 16:26
  • PS. Note how I'm having to use cmd.exe to run mklink because there isn't a native PowerShell way of creating symbolic links. There are a couple of PowerShell extensions that add this functionality but rolling that out of all XenApp systems was a little OTT. It only runs once per XenApp server so isn't a huge overhead.
    quarta-feira, 14 de maio de 2014 16:28
  • Maybe I missed anything obvious.

    Now there is a hotfix for this hottest and newest Internet Explorer which gives me the opportunity to write some PowerShell skripts where I have to call cmd.exe cause symbolic links cannot be created natively to force this newest and hottest IE to do to some extent what the older versions already did - too simply roam that part of the data which obviously should be roamed and leave the rest of it on the machine untouched.

    Maybe I'm simply asking for to much. MS please give us enterprise architects / consultants /administrators a browser which is simply usable in such environments like Citrix/RDS farms as you already did in the past.

    We all know that you built in a design flaw which leavs that kind of customers behind awkward, but maybe you at least could tell us what your plans are for the future in this regards.

    Please share your plans so that we are able to also make some plans for our customers.

    Thanks for your patience.

    quarta-feira, 14 de maio de 2014 18:05
  • Not exactly the newest and hottest as we're on IE10 and maybe IE11 isn't broken.

    But in principle I agree. I've spent hours on this problem and whilst I kind of expect Adobe to do bad things with the profile (like putting cache files in roaming profile!), I don't expect Microsoft to do the same. How did this get through testing and why is it still not resolved over 1.5 years after IE10 was released.

    As we're on a high-speed LAN, roaming an additional 30MB is okay although not ideal if there was a better way to do this.

    That said, user management in Windows shows it's heritage and it's always been quirky in multiuser environments. It could do with a fresh start but due to backwards compatability requirements, that's darn hard to achieve.

    quinta-feira, 15 de maio de 2014 14:28
  • IE10 and IE11 suffer from the same problem so I'm talking about the newest and hottest one.

    The patch is currently released only for IE10 but will be released for IE11 in May, however I'm rather sceptical as I do not expect it to do anything different than the one for IE10.

    quinta-feira, 15 de maio de 2014 17:29
  • The new method was surely UEV, but V1 didn't support cookies, per http://support.microsoft.com/kb/2847017/en-US

    If the webcache files are no longer (post update) locked all the time then perhaps UEV might be worth a try again, specially as it's now up to v2 (though I've not yet found any documentation about what UEV 2 can or cannot do re. IE and/or cookies - if anyone finds anything please let me know!).

    Seems rather daft for a company to spend time coding a new method of storing cookies and simultaneously code a new method for roaming user data that are not compatible with each other...

    sexta-feira, 16 de maio de 2014 08:32
  • We were experiencing the same issue. Ours is related to gmail and 2-step verification. I had hope when I saw a recent June 2014 hotfix (MS14-035)

    http://support.microsoft.com/kb/2955387/en-us

    Persistent cookies are not roamed in Internet Explorer 11 or Internet Explorer 10.

    Initially it did not work, however, combining this hotfix with ENABLING the following GPO:

    Computer Configuration\Administrative Templates\System\User Profiles\Delete cached copies of roaming profiles

    so far appears to be working. I am still inquiring as to the relationship between webcache and this GPO, but it is progress. Interested if this works for others.

    quarta-feira, 25 de junho de 2014 20:25
  • Initially it did not work, however, combining this hotfix with ENABLING the following GPO:

    Computer Configuration\Administrative Templates\System\User Profiles\Delete cached copies of roaming profiles

    so far appears to be working. I am still inquiring as to the relationship between webcache and this GPO, but it is progress. Interested if this works for others.

    Aye, this seems to do the trick in our environment as well! And the good news is that it works for both IE10 and IE11.

    Thanks for the find! This will solve a ton of frustrations for our end users.

    Although the GPO doesn't seem to make much sense at first, I think it implies that Microsoft coded a hotfix that says: export cookie-related WebCache data to the roaming profile at logoff (but not the entire WebCache database!), but only do it if you flag the desktop as being one that should be cleared of all personal data when you log off. It makes some sense, but the least Microsoft could've done is mention that the GPO is a requirement for the hotfix to work.

    sexta-feira, 27 de junho de 2014 12:26
  • Great, thanks for the followup.

    A couple other notes: If you know how roaming profiles work, if there is no local cached copy, an entire download of the roaming profile will happen from network to PC at every login with that GPO. We already had in place "redirect folders: appdata(roaming) with My Docs, My Pic, etc following that location" to our users home drives so this really didn't impact us much from a performance perspective. It may be important for others to complement the fix with this type of change especially if you have users on the other end of slow links who would suffer greatly if they had to redownload a lot of roaming profile every time.

    sexta-feira, 27 de junho de 2014 13:04
  • We also have folder redirection configured, because we work in a VDI environment where the virtual desktops are dynamically assigned (ie. no one gets the same desktop twice in a row).

    We actually had the GPO that you mentioned set to 'not configured' because it would be superfluous in our environment: our virtual desktops get refreshed (= reverted to the original, clean state) each time a user logs off. Our line of thought was: why delete local profile data if VMware throws away the desktop anyway?

    It seems that with the hotfix and the GPO setting enabled, Windows creates a abcdef.dat file with every abcdef.txt cookie file in %appdata%\Microsoft\Windows\Cookies. I suppose that's where the required data is stored.

    Edit: After some more testing, it's apparent that any existing WebCache cookie-related data you may have accumulated through workarounds such as the one with the symbolic link or by roaming the WebCache folder through some custom scripted method, is not carried over when you enable the GPO. This leads me to believe that with the hotfix+GPO, IE10 and IE11 no longer rely on the WebCache database for storing cookie index data, but rather, make use of the extra .dat files in %appdata%\Microsoft\Windows\Cookies instead.


    sexta-feira, 27 de junho de 2014 14:00
  • I'm in a VDI environment (Citrix VDI-In-A-Box) desktop are dynamically assigned. Using Citrix Profile Manager and Folder Redirection

    I have IE 10 installed Update Version 10.0.17 (KB2957698 - the link takes me to MS14-035 Security Update page so I think this is the correct update of IE with the fix in) I have the GP set but it is not working.  I'm not getting a abcdef.dat created in the cookies folder when I save a login.  I get a file container.dat and it will save the login for that session but when I log off I have to re-enter username and password.

    Have enable citrix profile manager GPO Delete Locally Cached Profiles on logoff but this hasn't resolve the problem - There are no more IE updates to install.   Would there be any GPO which would affect this setting? 

    EDIT - as I'm not using roaming profiles (Using Citrix Profile Manager and Folder Redirection) not sure if this GPO setting will be activated or not.  Should I manually redirect C:\Users\myusername\AppData\Local\Microsoft\Windows\WebCache in Citrix Profile Manager

    • Editado JolyonHedges quinta-feira, 3 de julho de 2014 16:31 Added info
    quinta-feira, 3 de julho de 2014 16:27
  • We currently have IE 11 and Xenapp 6.5 with Citrix HRP 4 installed and now it seems the passwords are being remembered.

    We use Mandatory profile, and RES workspace manager 2014 fp 5.

    fyi.

    quinta-feira, 10 de julho de 2014 06:41
  • XenDesktop using Roaming Profiles here. Windows 7 and IE10.

    Just wanted to say, that this issue blows my mind... Come on Microsoft!

    going back to IE9 until it is fixed.

    quinta-feira, 10 de julho de 2014 15:37