none
Windows 10 roaming profile includes AppData\Local & LocalNow folders RRS feed

  • Question

  • I posted this over in the community first but somebody suggested I move it over here.

    Existing Windows 7 & Windows 8.1 domain environment with accounts configured to use roaming profiles stored on a Windows 2012 server using DFS file share.

    New Windows 10 Pro built for testing and logged on with an existing domain account. First hint something was wrong was the "Roaming profile not fully synchronised" errors. Looking the event log reveals lots of access denied errors from the user profile service attempting to copy to/from AppData\Local and AppData\LocalNow.

    Looking in the new v5 profile sub-folder created automatically, there is indeed three sub-folders:

    1. Roaming - expected
    2. Local - shouldn't be there
    3. LocalNow - shouldn't be there

    The Local & LocalNow folders are not in the v2 profile from the existing Windows 7 & 8.1 clients.

    Aside from these access denied errors and pop-up warning, including Local & LocalNow in the roaming profile is a really bad idea as it really slows down the log on & off process as they tend to contain large number of large files, e.g. cached application data. The whole idea of splitting Local & LocalNow out is so this temporary/rebuildable data can be kept out of the profile.

    Any idea why this is happening?

    Thanks, Rob.

    Thursday, August 27, 2015 9:30 PM

All replies

  • I also posted it on SuperUser and here's the replies:

    http://superuser.com/questions/961727/local-locallow-folders-getting-copied-into-roaming-profile-on-windows-10

    So it's not a new problem and my suggestion that it was Corel PaintShop was a red herring in that it the installation program for this application uses IE11 to render some content as part of the installation, thus waking up the Kraken that is IE11.

    I've not had much time to follow up over the past few days.

    Cheers, Rob.

    Thursday, August 27, 2015 9:35 PM
  • PS. Please don't tell me it's some workaround for the problem with IE11 cookies not roaming! In my previous life supporting a large Citrix XenApp farm where roaming profiles are pretty much essential (unless you can afford AppSense), I had to go through real hoops to get cookies and other IE11 stuff roaming correctly between XenApp servers.

    Cheers, Rob.

     
    Thursday, August 27, 2015 9:39 PM
  • Definitly its not an issue based on IE11. By Default AppData / Localnow is excluded by GPO and was working on 8.1. Also ' GPResult' is showing no error. If there is no fix it will be a 'nice' Feature for VPN Users waiting on 1 GB to be sync'd ;-)

    stefan

    Friday, August 28, 2015 5:12 AM
  • There are two keys that technically take part here:

    [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
    "ExcludeProfileDirs"="AppData\\Local;AppData\\LocalLow;$Recycle.Bin;SkyDrive;Work Folders"

    [HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System]
    "ExcludeProfileDirs"="Dropbox;AppData\\Roaming\\Dropbox;Google Drive;"

    Our GPU excludes Dropbox and Google Drive from roaming.

    The second is the one set by GPO. You'd have to use a custom registry GPO I assume to configure the first. If somehow that entry got zapped, then it would explain what we're seeing. Except I think that it's intact on my test system when the fault occurs.

    I assume Windows blends these two keys together when determining what to exclude from the roaming profile export to the network.

    Cheers, Rob.

    Friday, August 28, 2015 9:57 AM
  • The first Setting is Default (if nothing Special is set). You can only add more excludes / includes via GPO

    Our 'default' Looks like this 'HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs = AppData\Local;AppData\LocalLow;$Recycle.Bin;OneDrive;Work Folders'.

    Based on this Settings we should NOT see anything like LocalLow.. inside the Server Profile Location.

    Maybe some Microsoft Expert could help?

    thanks

    stefan

    Friday, August 28, 2015 3:29 PM
  • Had half an hour to look at this again today. I'm pretty sure this is something either Edge or IE11 related. VM powered up today and some updates installed so restart the VM with the test account logged in. Restarted several times and only "Roaming" written to AppData in roaming profile.

    Open Edge on www.bbc.co.uk and then select the option to open in IE11. Stuck it in favourites just as a bit of a test.

    Restart the VM and two things happened.

    Firstly, the restarting was held up by this dialog which did occur in the 2/3 restarts I'd just done previously. Secondly, "Local" and "LocalLow" popped up in the roaming profile (monitored separately). I left this dialog on screen and it finally did restart. I'm going to guess after the Local and LocalLow folders had finished copying? Something is adding a log off task to copy Local and LocalLow...

    Friday, August 28, 2015 4:51 PM
  • i removed the IE11 'Feature' and deleted the Local /locallow Folder on the Server. After i did a 'Login cycle' all Folders are back. So not IE11, but what else?. getting mad on this..

    cu

    stefan

    Friday, August 28, 2015 9:29 PM
  • I can't help Stefan as I'm as stumped as you. I have a very sneaky feeling that it maybe something around the problems I encountered a few years ago with IE changing the cookie mechanism. At the time I supported a XenApp farm where roaming profiles are critical and had to battle with this fault (you can see my comments on there):

    http://vthoughtsofit.blogspot.co.uk/2014/04/internet-explorer-10-webcache-file.html#.VeF9YHmFOUk

    My recall of the problem is a bit vague: the new cookie database (previously it had been lots of txt files) changed from the roaming to the local part of the profile - net result was each time a XenApp user was load balanced onto a new server at logon their cookies were lost, e.g. they had to keep logging into websites. The solution to this was (I think!) to use a junction to redirect the cookies folder into the roaming part of the profile. I did this in the PowerShell logon script. However, this wasn't totally successful as it was found the database was locked and therefore wasn't able to export to the network on log off. This is where things got a bit vague as at around the time, this KB was released:

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

    This was supposed to fix it but I never determined how it fixed it. For us, we still had the workarounds above but the KB did unlock the database so they worked.

    So here's the suggestion re: that KB. If you didn't have the workaround of using a junction to redirect the cookies folder into the roaming profile (which most people didn't), how did fix work? Because it certainly left the cookies database in the local profile folder. Some other mechanism must have been implemented to copy the cookies database to/from the network - almost separate to the normal roaming profiles process.

    My theory/wild guess is that mechanism here is accidentally copying the entire local & locallow folders when it detects there are some files created by IE. That "thing" preventing me from logging off is this mechanism at work.

    Maybe although you've removed the IE11 feature, the cookies folder is still there in your profile and the mechanism is still alive.

    I'll do a few more tests later.

    As I said though - lots of guessing going on here...

    Cheers, Rob.

    Saturday, August 29, 2015 9:55 AM
  • Hi Rob Nicholson,

    This case seems to be a known issue.

    Potential side-effects of this behavior include:
    Logoff delays as Windows 10 clients write more data to the roaming profile
    Logon delays as Windows 10 clients copy large profiles from the network
    Users see the on-screen error at logoff: "Your roaming user profile was not completely synchronized. See the event log for details or contact administrator."
    Increased network utilization
    Increased disk consumption storing larger profiles.

    The root cause is unknown. Please take the following steps to capture the log to help analyze the issue.

    Enable Profile ETL tracing and reproduce the problem

    set TRACE_LEVEL=3
    IF EXIST "%2" set TRACE_LEVEL=%2%

    tracelog -start profile -f "profile.etl" -guid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98 -level %TRACE_LEVEL% -flag 255 -b 10485760

    set TRACE_LEVEL=2
    IF EXIST "%2" set TRACE_LEVEL=%2%

    tracelog -start profile -kd -rt -ft 1 -f "profile.etl" -guid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98 -level %TRACE_LEVEL% -flag 255

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Tuesday, September 1, 2015 2:07 AM
    Moderator
  • I assume this is a batch file you want me to create and run? Where does the trace go and what do I then do with it?

    Cheers, Rob.

    Tuesday, September 1, 2015 9:20 AM
  • Hi Rob,

    Once the code has been run, we will get a log called "profile.etl", it should be located in C:\Windows\System32.

    Please upload it to OneDrive and paste the link here.

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Wednesday, September 2, 2015 5:50 AM
    Moderator
  • @MeipoXu:

    Is it possible to get tracelog without installing the whole WDK?

    Or can this be done with a logman command instead?

    Thursday, September 3, 2015 2:54 AM
  • Hi nsemenko,

    The main purpose is to allocate the  profile log to troubleshoot. The logman command line could be used to allocate the log, too. We could have a try.

    Start the log:
    logman -start profiletrace -p {eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98} 255 3 -ets

    Stop the log:
    logman -stop profiletrace -ets

    Please upload the log to One Drive and paste the link here.

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Monday, September 7, 2015 2:54 AM
    Moderator
  • Hi all,

    is there anz news on this issue?

    thanks

    stefan

    Saturday, September 26, 2015 7:55 PM
  • Same problem here.

    All on Build 10240 Enterprise edition. We've spotted some Roaming Profiles are syncing both the Downloads folder and the Local/LocalLow folders. Max profile size is set to 30MB, but several .V5 roaming profile folders are way over this, the largest being 12GB. We have group policies set to redirect Downloads and ignore Local/LocalLow which work fine on Windows7/8 but not on these Windows 10 machines.

    Not all Windows 10 users are affected though which is odd. All affected machines already had KB3081444 installed. In fact according to WSUS, KB3081444 supercedes the other patch mentioned (KB3081438). Also KB3081444 has itself been superceded 3 times, the latest of which is KB3095020

    We'll try this next. Anyone else had any joy identifying the cause and the fix?


    • Edited by markey165 Wednesday, September 30, 2015 12:54 PM
    Wednesday, September 30, 2015 12:51 PM
  • >We'll try this next. Anyone else had any joy identifying the cause and the fix?

    I haven't had time to look at this in more detail or generate the debug logs mentioned about. I put our small Windows 10 rollout on hold on the hope that a couple of months would see it fixed.

    Cheers, Rob.

    Wednesday, September 30, 2015 3:27 PM
  • I'm also seeing this problem on Enterprise x64 Build 10240. Fully patched.

    One profile that had been roaming correctly suddenly decided it needed to copy everything, including the Local and LocalLow folders, up to the network share. I poked around in the Registry exclude folder and things seem OK. Really need a fix to this.

    Saturday, October 3, 2015 12:55 PM
  • Problem is fixed in TH2
    Monday, October 12, 2015 6:48 PM
  • I have the same problem on some W10. What is TH2?


    Viele Grüße Dirk

    Tuesday, October 13, 2015 10:56 AM
  • TH2 is an insider build of the next version of Windows 10:

    http://www.winbeta.org/news/windows-10-th2-build-10540-screenshots-leaked

    So sounds like a known problem and will just have to wait for the fix. I've come back to this problem today but I'm struggling to repeat it but the Windows 10 VM that I'm using has just installed some updates. Maybe the fault has been fixed by a current Windows update.

    Cheers, Rob.

    Saturday, October 17, 2015 2:35 PM
  • Spoke too soon - managed to repeat it...

    Cheers, Rob.

    Saturday, October 17, 2015 5:53 PM
  • Its still not solved for existing profiles.

    As far as I see it does not occur for new profiles.


    Viele Grüße Dirk

    Tuesday, October 20, 2015 8:23 AM
  • Hi all, that means wait and check for the 'November' Rollout of Win10 and hope to get a fix for existing Profiles...

    cu

    stefan

    Friday, October 23, 2015 7:21 PM
  • I'm on build 10240 with all updates and this issue was persistent until I ran SFC /SCANNOW

    Worth a go.

    It also roamed folders that were supposed to be excluded as defined by GPO e.g. %APPDATA%\Microsoft\Crypto

     I have manually deleted them from the roamed profile and these too have stopped roaming.

    • Edited by The Steve_N Wednesday, October 28, 2015 4:18 PM More info
    Wednesday, October 28, 2015 4:11 PM
  • I've just deployed a new VM with Insider build 10565 and the program is still present. I assume that this Insider build is part of the November rollout so not looking good.

    This VM has no additional software installed except VMware Workstation tools.

    I'm just doing some more testing to see if I can repeat it under controlled environment. I still suspect it's something to do with IE11 but not 100% sure yet.

    Cheers, Rob.

    Thursday, November 5, 2015 4:44 PM
  • Hi Rob Nicholson,

    This case seems to be a known issue.

    Potential side-effects of this behavior include:
    Logoff delays as Windows 10 clients write more data to the roaming profile
    Logon delays as Windows 10 clients copy large profiles from the network
    Users see the on-screen error at logoff: "Your roaming user profile was not completely synchronized. See the event log for details or contact administrator."
    Increased network utilization
    Increased disk consumption storing larger profiles.

    The root cause is unknown. Please take the following steps to capture the log to help analyze the issue.

    Enable Profile ETL tracing and reproduce the problem

    set TRACE_LEVEL=3
    IF EXIST "%2" set TRACE_LEVEL=%2%

    tracelog -start profile -f "profile.etl" -guid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98 -level %TRACE_LEVEL% -flag 255 -b 10485760

    set TRACE_LEVEL=2
    IF EXIST "%2" set TRACE_LEVEL=%2%

    tracelog -start profile -kd -rt -ft 1 -f "profile.etl" -guid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98 -level %TRACE_LEVEL% -flag 255

    Best regards


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    I've built a new Insider Build 10565 Windows 10 VM and installed Visual Studio 2015 community as the easiest way to get tracelog.exe which is part of the Windows SDK. I then launched the VSD2015 developer command prompt as administrator and run the above from a batch file.

    You're lucky I'm a developer as well as this would be seriously confusing ;-)

    Anyway, I get an error on the second tracelog command because I think it's trying to start a profiler called "profile" that's already running.

    So I've modified the two tracelog commands to create a logger called profile1 and profile2 plus they can't share the same ETL file so it creates profile1.etl and profile2.etl instead:

    tracelog -start profile1 -f "profile1.etl" -guid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98 -level %TRACE_LEVEL% -flag 255 -b 10485760
    tracelog -start profile2 -kd -rt -ft 1 -f "profile2.etl" -guid #eb7428f5-ab1f-4322-a4cc-1f1a9b2c5e98 -level %TRACE_LEVEL% -flag 255

    I'm hoping this was the right thing to do. Now to see if I can reproduce the error.

    Friday, November 6, 2015 12:12 PM
  • Hmm, this is frustrating. In a early part of this new build, I tried logging on as my domain account and shutting down and the local & localnow folders were there. However, I went back to an earlier snapshot so I could do it again with tracing enabled and now it stubbornly won't repeat the problem! I'm going to carry on building the VM to see if it occurs again but this is taking a lot of time.

    Has anyone from Microsoft go access to the fix list for Windows 10 and was this issue on there as fixed? If so, then I might be wasting my time.

    Cheers, Rob.

    Friday, November 6, 2015 3:33 PM
  • I have the same problem.

    But I see that if I delete the file ntuser.pol from %userprofiles% dir

    and delete ntuser.pol from share \\fileserver\sharedprofiles\username.v5\ntuser.pol

    appdata\local and appdata\locallow are not copied during logout

    The problem is that after some time ntuser.pol appear again.

    Wednesday, November 11, 2015 11:18 AM
  • This is also annoying for our environment, especially the Downloads folder. We exclude that folder in the GPO and works very well with Windows 7 and 8.1, but for 10, profile size are getting bigger due to all the junk users download in there.
    • Edited by DJ X Friday, December 4, 2015 5:23 PM
    Friday, December 4, 2015 5:23 PM
  • We have the same problem. Sometimes not always the \Local and \LocalLow folder will also be copied to the server during logoff process.

    We observed this behaviour on the Windows 7 clients too and I was not able to find the cause for it.

    It's really annoying for the users because it uses a lot of time for the logoff/logon process and also for us administrators which fills up the available diskspace on the server share.

    I spend hours to try to find a solution, but was not successfully. I think it's not only a Windows 10 problem, as I said, we observed it also on the Windows 7 clients on the same domain.

    It's not reproducible sometimes it works fine, this makes it harder to solve.

    Does someone have an idea what I could try to solve or reduce this problem?

    Many thanks

    Friday, December 11, 2015 3:25 PM
  • Rob, have you had the change to see if this still happens in the big 1511 (TH2) update from last month?

    We're seeing sporadically on a couple of 10240 machines that we had been deferring the 1511 update for other reasons.

    Wednesday, December 16, 2015 4:51 PM
  • Brandon, I can not test 1511 machines because we don't have this version currently running, but we see this sporadically also on Windows 7 machines, therefore I think it's not only a 10240 (Windows 10 RTM) problem.

    It's sporadically on different machines, different useraccounts, different times. It's really hard to debug, in the moment I have no idea how to find a solution.

    Friday, December 18, 2015 11:48 AM
  • Any luck with this? I have th same problem with v5 profiles.

    v2 looks good, without a local and locallow folders,

    Monday, April 4, 2016 2:27 AM
  • We have still this problem. Mostly on Windows 10 RTM and also 1511 build. Sometimes also on Windows 7 clients in the same domain. We couldn't find a solution yet.
    Thursday, April 14, 2016 8:11 AM
  • We have exact the same problem with the Windows 10 v5 roaming profiles.

    Even when we add appdata\Local;appdata\LocalLow to the policy "User Configuration/Administrative Templates/System/User Profiles/Prevent the following directories from roaming with the profile" the folders are still copied to the roaming profile.

    Thursday, April 14, 2016 9:48 AM
  • We are also having this issue :( tried installing these updates (KB3081438, KB3081444) but nothing, its strange we have like 100 win 10 computers but only 5 or so doing this. 

    Windows version: Fully updated Windows 10 LTSB

    Thanks, Ben

    Friday, May 13, 2016 11:37 AM
  • We are having the same problem, same symptoms/set up as Ben. Anyone had any luck resolving? 

    Chris

    Friday, June 10, 2016 12:18 AM
  • This probably doesn't help the cause but I'm experiencing this issue with a number of Windows 7 roaming profiles although I believe this is an old intermittent bug that happens from time to time as I've seen this since at least 2009.

    I manually added Local and LocalLow to exclusions via group policy but this did not resolve the issue.

    I would be interested to hear if anyone has any advice as to how to resolve this problem.

    I should also add that the users that experience this problem carry forward the problem to other systems!


    • Edited by williamgault Tuesday, September 13, 2016 3:24 AM
    Tuesday, September 13, 2016 3:24 AM
  • The case where AppData\Local and LocalLow folders are incorrectly uploaded to roaming profile is fixed in the TH2 release of Windows 10.
    Friday, September 23, 2016 6:46 PM
  • Hi Enttrac

    Thanks for your posts above, very helpful. We have the exact same issue as listed, out of about 100 machines we have 3 or 4 that will randomly just dump their entire user profile on the network without warning. Given that O365 means we have very little option other than using Cached Exchange Mode, this gives us a real problem when large OST files suddenly appear on the network.

    What's the deal with the TH2 update? Is this something we can download as an MSU and apply?

    We are build 10240.

    EDIT: I should also add that we've been Windows 10 for about 5 months and we're up to date on patches in line with the deferred program. I see TH2 was released in November last year, so unsure why this issue would still be outstanding for us.

    Thanks

    MF


    • Edited by mbf199t Tuesday, September 27, 2016 9:16 AM
    Tuesday, September 27, 2016 9:15 AM
  • Hi all,

    I've been searching the internet for weeks now trying to see if anyone out there has found a solution to problems within IE10+. Ever since they've brought out the new way of storing browsing elements in the webcachev01.dat file I've seen forum after forum and business after business trying to find a solution to storage of the file, roaming of the file and loss of history and cookies between devices for users if they don't roam the file, this then causes slow logon and logoff times so it seems like it's a lose/lose situation. Microsoft haven't yet announced a way to keep the file at a manageable size or combat the loss of data and slow logon/logoffs. 

    There is one solution out there worth having a look at, especially if you are a multi-user site. It's a piece of software called WebCache Manager and it fixes those common problems. I don't necessarily want to be posting about products outside of Microsoft but it seems that the only fix is something that Microsoft do not yet offer.

    http://bit.ly/2c9l1rf

    Thanks

    LN

    Thursday, October 6, 2016 9:08 AM
  • Deleted
    Wednesday, February 14, 2018 8:46 AM
  • Same Problem here. No solution in 2018?
    Sunday, May 13, 2018 7:45 AM
  • Same Problem here. No solution in 2018?
    I agree
    Friday, May 18, 2018 1:50 PM
  • I experience the same problem with Windows 10 1803 and a server 2008 R2 server and domain.
    Tuesday, July 3, 2018 12:24 PM
  • Same problem here.  New laptops (Win 10 1803) rolled out to users, some (1 in 5?) now have a very long logon/logoff time (20 minutes).  Main problem is their Outlook .ost files in AppData\Local\Microsoft\Outook folder is now part of the profile.

    Can't believe that Microsoft are not aware of this.  Can't believe it is not fixed.

    So I tried to move the .ost file for a user.  Boot the laptop, sign in as user (don't start Outlook).  Control Panel, Mail, Profile. Find the location of the file and cut it and move to a test folder (C:\OutlookOST).  

    First problem 'The file is open in Skype for Business'.  Exit that.  Second problem. 'the file is open in Windows host process (rundll32).

    Madness.  And we are under pressure to get this fixed.

    • Proposed as answer by aara Writer Monday, September 17, 2018 8:08 AM
    Sunday, July 8, 2018 9:07 PM
  • May not be relevant to the Office issues but it's worth a read on profile issues especially surrounding the webcache! https://robbeekmans.net/euc/re-gain-control-of-your-web-data-with-avanite-and-cleanup-user-profiles/
    Thursday, July 26, 2018 10:02 AM
  • I think I see the problem. I was running regedit "As Administrator." The administrator account was then what was shown under HKCU.

    When I ran regedit normally, I found that HKCU for the regular user did not have an ExcludeProfileDirs value at all.

    Manually adding this value with its default setting corrected the issue and stopped Local and LocalLow from being replicated to the v6 path.

    I guess that a GPO ExcludeProfileDirs policy value needs to be applied for roaming profile users... or you need to set up something else to enforce this value into HKCU for roaming users.

    Monday, August 27, 2018 9:08 PM