Setting domain policy folder redirection at gpedit

Discoveries about profile deployment

I have had the need to reinstall a Windows 7 workstation at a small business network and at last I also had the time to do it. (sigh)

The current state of affairs realized pretty quickly after introducing a new workstation to the domain network. Some aspects, like domain policies, worked inconsistently and user folders were mapped all over the place.

I wanted to have at least roaming profiles for convenience and also keep the familiar Z-drives (home folders) for people so they wouldn't get confused and continued hoarding their stuff in the same place. And the arrangement had to be so laid-back that I wouldn't have to create necessary directories for every user - just creating the account should suffice.

Although I've been an admin for years, there was also a bit confusion with terminology. Windows has the opportunities to set profile path and home folder from AD management console or by-computer basis by deploying a group policy. In practice the profile is a stash directory for everything (mostly application-related data) considering the user, like kind of home directory in Unices. Home folder on the other hand is mostly the user's 'My Documents'.

In addition there is third opportunity, folder redirection, which I think is a kind of symlink or information for the OS about where to map certain directories. It is managed from the group policy and you can map only certain directories.

There were also some login (ahem.. logon) problems in which Windows provided me only with a temporary profile. It seemed the previous backup registry entry which held my SID caused Windows to fail login completely although there was no "current" registry key present with my SID, only the .bak. This was solved by removing the unneeded .bak-key from the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.

Setting the folder permissions for profiles folder

In part the login problem was probably caused by too strict permissions on the root shares (the shares that are the root for home folders and profiles). The permissions are definitely not intuitive so one should be very careful and probably do a re-check when setting them. (maybe in the future the whole listing of the permissions that made my setup work)

Noteworthy was that Windows client apparently does not check whether the logging user's profile or home folders exist (in the policy designated path, eg. \\\server\share) if it has a record of the profile in the local cache. In other words, if the same user has logged in before on the same computer and there are still outdated indications about SID and the local copy of profile, only a temporary profile is used. So when trying to check the permissions of directories and that all directories are automatically created upon new user login, you have to be sure that Windows thinks that a new user is trying to login - otherwise it won't even bother try to create new user directories.


Also there was a little problem with the fresh workstation install. The previous workstation had held the admin tools for tweaking the domain network and I had to get the dsa.msc going if I wanted to check in what state the user profiles were now. For some reason the MSU-archive which contained the remote server administration tools (RSAT) installation was stuck at "searching for updates on this computer".

Luckily the solution was found with just a bit googling; only had to extract the cabinet from the msu file (I did it with 7-Zip) and install it manually:

dism /online /add-package /packagepath:Windows6.1-KB958830-x64-RefreshPkg.msu

After that I had to enable it from Windows features (Programs and Features).

{{ message }}

{{ 'Comments are closed.' | trans }}