none
Problem with roaming profile V6 - Win 10 14332

    Question

  • Hello all,

    Strange problem, i want to know if more Insiders got this problem in (VM) Win 10 14295 and  (VM)  Win 10 14316 and 14332

    I created an (VM) DC with Server 2016 Technical preview 4,  Also reproduced this error on my production (VM) DC server 2012 r2.

    I created an test user on server 2016, after first login no problem with roaming profile, even when i am sign out and sign in. Still no problem.

    When i restart the Windows 10 VM, i got this message after sign in. 

    Image

    In the eventlog i find this error:

    User profile Service 1521.

    Translation "There was a problem with your roaming profile you have been logged on with your previously saved local profile. Please see the event log for details or contact your administrators."

    Got the same problem when i create a another test user on our production DC server 2012 R2, with new roaming profile location to another server.

    In the eventviewer of Windows 10 i find this error:

    Translation

    "User profile Service 1521.

    DETAIL - the process cannot access the file because it is being used by another process. "

    Anyone else with same problem?

    ****** UPDATE *******

    Tested this on Another Hyper-V server,

    (VM) server 2012 r2 DC
    (VM) Windows 10, newest build (V6 roaming profile)

    Same result, This must be a problem in Windows 10 related to roaming profile v6.

    ****** UPDATE *******



    Thursday, April 14, 2016 4:56 AM

All replies

  • Found a workaround, if i wait a couple of minutes before login, I dont see this error.

    If i login directly after restart the roaming profile issue will occurs.

    Network is connected correctly without exclamation mark if i will login directly.

    Didn't test this on a physical PC, only on VM.

    Thursday, April 28, 2016 6:58 AM
  • This sounds very familiar...

    Somewhere between Win7 and Win10 the behaviour changed such that file locks, including those for a roaming profile user, were not closed immediately but kept open for a while in case they were needed again. If the machine is shutting down, the shutdown can pull the rug from under the network stack before the handles get closed properly, and the machine can shutdown leaving the ntuser.dat and other profile files open (these being the last files in use on the server on logoff).

    If the user tries to log on before the server has timed these connections out and closed the files, they can get a file in use error and windows logs them on with a temporary profile instead.

    We raised this with MS some time back, and the upshot is that they do not consider this behaviour to be a bug, and will not fix. So, we're left with workarounds:

    Using SMB 2.1 or 3 on the server where the profiles are stored helps. It doesn't solve it completely, but the server will try to contact the original owner of the lock, and if there is no response it clears the lock and gives the new client access. The timeout on contacting the original owner is shorter than the login profile timeout, so the effect is slow login rather than a temporary profile.

    Advise users to log off rather than shutdown or restart. In our testing, it's only 10 seconds or so that the machine needs to stay up for before the handles are closed, and that makes it much rarer.

    Shorten the time before the server closes connections that are idle.

    Downgrade either the clients, or the server where the profiles are stored, to only speak SMB1. This avoids the whole problem of file handles persisting, but has other downsides.

    The other solution is to have a windows service that monitors whether a roaming user is logged on, and keeps that flag set for 30 seconds or so after they have logged off. It can then delay shutdown by 20 seconds or so if needed, but not if not. This means machines take longer to shutdown or restart if logged on to by a roaming user, but guarantees enough time for the file handles to be closed properly on logoff.

    See also this thread: https://social.technet.microsoft.com/Forums/en-US/ba54df5f-4356-4cee-b724-303aaad51266/file-locks-persisting-after-shutdownrestart-causes-serious-roaming-profile-redirected-folder?forum=win10itprogeneral

    Thursday, April 28, 2016 9:30 AM
  • Didn't see your reply, 

    'We raised this with MS some time back, and the upshot is that they do not consider this behaviour to be a bug, and will not fix. So, we're left with workarounds:'

    Not a bug, strange!

    I will test your workarounds! Thank you

    Thursday, July 21, 2016 9:59 AM
  • We recently solved our problem with those mentioned persisting file/directory locks which frequently corrupted our Windows 10 roaming profiles. In our case the "Arcserve Backup Agent for Open Files for Windows" on our W2012R2/W2016 file server however was responsible for the persisting file locks after  a user logged off from a Windows 10 client. After removing this component no further file/directory locks on the file server have occured at user logoffs/client reboots.

    Wednesday, July 4, 2018 12:55 PM
  • We recently solved our problem with those mentioned persisting file/directory locks which frequently corrupted our Windows 10 roaming profiles. In our case the "Arcserve Backup Agent for Open Files for Windows" on our W2012R2/W2016 file server however was responsible for the persisting file locks after  a user logged off from a Windows 10 client. After removing this component no further file/directory locks on the file server have occured at user logoffs/client reboots.

    Just stopping the service did not solve the problem?? Has anyone else tested this solution?


    Tuesday, July 10, 2018 12:58 PM
  • We had to remove this Arcserve component complete, just disabling did not solve it.
    Tuesday, July 10, 2018 1:35 PM
  • We had to remove this Arcserve component complete, just disabling did not solve it.
    Need to reboot?
    Tuesday, July 10, 2018 2:07 PM
  • If I remember it right, we did not try it without rebooting.
    Tuesday, July 10, 2018 2:37 PM
  • Confirmed, after remove "Arcserve Backup Agent for Open Files for Windows" and reboot, problem is gone!
    Tuesday, July 17, 2018 12:24 PM