Until now the folder structure we were using for the home directories was a little odd. The home directories resided in "\\server\users\home\<department>\<accountname>" which means that whenever a user changes department his/her entire home directory had to be moved to a new location.
The server department started moving the first departments' users' home directories to a new structure (and updated the "homedirectory" value in the AD for the affected users accordingly). The new locations for the home directories are five DFSs under "\\server\users\home0[1-5]\<accountname>" hosted on a NetApp server. The split into "home01" to "home05" is done so that they do not have to restore a giant 10TB share and instead only have to deal with smaller 2TB portions when things go south.
And even though the people in charge claimed that they tested everything thoroughly things did go south when they migrated the home directories of the first hundred or so users ...
Every user in the domain has a home directory on the network, but not everyone's "Desktop", "Documents" and "Favorites" folder is actually being redirected. For example whenever a user logs onto a notebook they get a different GPO that does not redirect those folders. The same goes for users that are located in buildings with a slow uplink (read: DSL).
Migrating the users with "local folders" was no problem. They did not really notice anything changing. Those were the majority of the users in that first batch. But a couple users from that first batch were actually getting the folder redirection GPO and all those users were now reporting issues with their desktop missing and that they were getting an error message after logging in.
The error message was complaining that the old folder where their home directory was located could no longer be found. Of course it was no longer there, it had been moved as already mentioned. But for some reason the folder redirection GPO was not being applied or at least did not update the paths in the registry. After confirming the error message all the users had on their desktop was a single recycle bin icon. Nothing else.
Checking the eventlog on those machines showed no error messages related to GPOs or the folder redirection, not even in the specialized logs. On the contrary, the folder redirection log even said that the folder redirection had been applied successfully. Restarting the machine and logging in again and again did not help. Leaving a machine with such a user logged in for hours did nothing either. The desktop stayed empty. The only thing that helped and fixed the problem was running "gpupdate /force [/logoff]", forcing Windows to reapply the folder redirection. Upon logging in again everything was working and the users had their desktop again, at the new location.
Considering the server guys plan on moving another 3000 home directories this is of course less than optimal. We cannot tell our users that they need to run "gpupdate /force /logoff" when they are missing their desktop. So I looked into the issue a little more...
When the server guys moved the old home directory to it's new location under "\\server\users\home0[1-5]\<accountname>" they also removed the old folder "\\server\users\home\<department>\<accountname>" completely. So I reproduced the scenario and found out that this was actually the cause for the empty desktop (except for the single recycle bin icon) and the error message. No amount of restarting, relogging or waiting will fix this. Only "gpupdate /force" will.
If you leave the old folder under "\\server\users\home\<department>\<accountname>" alone and only move all the subfolders to the new location something else will happen. Upon logging in for the first time after the files had been moved and the homedirectory path in AD has been updated the user will be presented a desktop that contains not only the recycle bin but also all public desktop elements. His own files will still be missing but he will not get any error messages. When the user then logs out and back in again all his own desktop elements will be visible to him, since now the folder redirection has worked it's magic and has updated the paths in the registry accordingly.
Since leaving the old folder in place was not an option for the server guys because then they "could no longer easily tell which folders still have to be moved" and since telling all users to run "gpupdate /force" is not an option for my team I came up with a different (automated) solution for this problem.
I created a new GPO that runs the following powershell logon script.
$desktop = (Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders' -Name "Desktop").Desktop
if ($env:HOMESHARE -and ($env:HOMESHARE -ne $null) -and ($desktop -ne "$env:HOMESHARE\Desktop") -and ($desktop -ne "$env:USERPROFILE\Desktop")) {
Start-Process -FilePath "C:\Windows\System32\gpupdate.exe" -ArgumentList "/force /logoff" -Wait
}
The script will run the command "gpupdate /force /logoff" if the following three conditions are fullfilled:
- The $env:HOMESHARE variable exists and is filled
- The path to the desktop folder contains a different path than the path in $env:HOMESHARE
- The path to the desktop folder contains a different path than the path in $env:USERPROFILE
This way all users who have their desktop on the local machine ($env:USERPROFILE) and all users who have a working folder redirection to their home directory will not run the command. All users with a broken folder redirection will run the command, will get forcefully logged out again and after logging in again should have to correct path set for their desktop folder.
Some users might end up in an endless loop of logging in and getting logged out again. These users will need to be looked at individually. In one case a user had all his folders redirected to the proper location already, except for the desktop folder which could not be moved because a folder with a way too long name existed in the folder and prevented it.
[1] https://twitter.com/BeingSysAdmin/status/905008530553438210
No comments:
Post a Comment