M
Mike Sandells
Guest
In testing Windows 10 (enterprise, 10240) with roaming profiles, we kept running into reliability issues - we'd sometimes get a temporary profile on login, or sometimes get lengthy hangs in the login process prior to any pre-shell login scripts. After a bit of work trying to narrow this down, the problem appears to be a more general issue with file locks that roaming profiles and redirected folders are particularly sensitive to.
In short, if a user logs off Windows 10, all is well.
If, on the other hand, they choose shutdown or restart, their connections to servers etc are not closed properly. This includes file locks, which are then left stuck until the server end times out the connection.
For a user with a roaming profile, this can leave the ntuser.dat and ntuser.ini files locked on the server - this is what leads to getting a temporary profile on next login. Event viewer reports that it can't use the roaming copy of the profile because a file is in use.
For a user with redirected folders (such a desktop, my documents, etc), the desktop.ini files in each of these locations is left open. This causes the lengthy delays for that user on subsequent logins as these time out in turn.
As these locks do time out eventually (15 mins in our environment), the appearance is of intermittent problems, but having narrowed down what's going on, there does not appear to be an intermittent element to it. So far, we are able to reproduce this behaviour consistently on Windows 10.
Where things get really weird is with Windows 10 fast startup enabled (i.e. the default). With this, if a roaming user is logged on, and shuts the machine down, the files etc remain locked while the machine is down as described above. But if the machine is powered back on then the connections close as it gets to the login prompt. We do not get this behaviour with a restart, or with a traditional full shutdown (fast startup disabled).
This looks as though some part of the OS shutdown process is interfering with the user logoff process, such that the user logoff process is not completing successfully and closing its connections. When fast startup is enabled, a shutdown isn't really a shutdown, and powering the machine back on seemingly allows that interrupted process to continue. For a real shutdown or restart, the process isn't able to continue and the files remain locked until the server end times them out. When simply logging off, there is nothing to interfere with the logoff process, and it all just works. At least, this is what it looks like to us, after monitoring the file locks at the server end, while trying various logout/shutdown/restart operations at a range of clients - alternative explanations for the observed behaviour would be most welcome.
In our case, the server end for the profiles is a netapp filer, but connections to Windows servers also persist until their natural timeout if the user shuts the PC down or restarts, but are promptly closed if the user logs off. Similarly, we can only reproduce this problem on Windows 10. So this looks to us like a Win10 issue rather than anything amiss at the server end.
Is there a known issue here? How might we diagnose this further? Is there anything we can tweak to ensure that logoff completes and closes all its files and connections before shutdown happens?
More...
In short, if a user logs off Windows 10, all is well.
If, on the other hand, they choose shutdown or restart, their connections to servers etc are not closed properly. This includes file locks, which are then left stuck until the server end times out the connection.
For a user with a roaming profile, this can leave the ntuser.dat and ntuser.ini files locked on the server - this is what leads to getting a temporary profile on next login. Event viewer reports that it can't use the roaming copy of the profile because a file is in use.
For a user with redirected folders (such a desktop, my documents, etc), the desktop.ini files in each of these locations is left open. This causes the lengthy delays for that user on subsequent logins as these time out in turn.
As these locks do time out eventually (15 mins in our environment), the appearance is of intermittent problems, but having narrowed down what's going on, there does not appear to be an intermittent element to it. So far, we are able to reproduce this behaviour consistently on Windows 10.
Where things get really weird is with Windows 10 fast startup enabled (i.e. the default). With this, if a roaming user is logged on, and shuts the machine down, the files etc remain locked while the machine is down as described above. But if the machine is powered back on then the connections close as it gets to the login prompt. We do not get this behaviour with a restart, or with a traditional full shutdown (fast startup disabled).
This looks as though some part of the OS shutdown process is interfering with the user logoff process, such that the user logoff process is not completing successfully and closing its connections. When fast startup is enabled, a shutdown isn't really a shutdown, and powering the machine back on seemingly allows that interrupted process to continue. For a real shutdown or restart, the process isn't able to continue and the files remain locked until the server end times them out. When simply logging off, there is nothing to interfere with the logoff process, and it all just works. At least, this is what it looks like to us, after monitoring the file locks at the server end, while trying various logout/shutdown/restart operations at a range of clients - alternative explanations for the observed behaviour would be most welcome.
In our case, the server end for the profiles is a netapp filer, but connections to Windows servers also persist until their natural timeout if the user shuts the PC down or restarts, but are promptly closed if the user logs off. Similarly, we can only reproduce this problem on Windows 10. So this looks to us like a Win10 issue rather than anything amiss at the server end.
Is there a known issue here? How might we diagnose this further? Is there anything we can tweak to ensure that logoff completes and closes all its files and connections before shutdown happens?
More...