Tips for customising and managing User Profiles for network-based users

In this article I would like to share a set of steps and tips for managing a standardised profile and how to implement a template that network-based users can use when logging-on to a Windows-based workstation or server. Most of these tips have come from back in Windows NT4.0/2000 era, I think it’s worth sharing these tips as they are still valuable in knowing the fundamentals of Windows profiles, even if there are other more modern approaches to achieve the same result.

Quick reference bookmarks for this article:

Overview of Windows User Profiles

Let’s quickly re-cap the general behavior and types of user-profiles that can exist on a Windows-based computer.

Firstly on a Windows client or server you can have either a “Local” or “Network” profile type. Local profiles are generated and stored locally on the hard-drive in the computer that a user is logging onto. Network profiles on the other-hand are located on a remote file server or network share. For obvious reasons, both have their positives and negatives; deciding on profile types will ultimately be dependant on the type of network environment that you operate and in some cases might consist of both types of profile depending on the end-user location.

Network profiles are also refered to as “Roaming profiles” as they can essentially move with the user in the case where the end-user logs on to different computers. Roaming profiles can be configured using Group Policy to either cache for offline availability or not cache for security purposes on an end-users computer. Caching might be handy when a user uses a laptop or portable device for instance. Caching can have a performance improvement over non-caching if the profile is large in file size.

Profiles can also be considered “mandatory” in either a local or network context; this means that the contents of the profile cannot change essentially. Some I.T Administrators will configure network profiles to be mandatory and choose to redirect particular folders in that profile to other network-based locations outside of the profile path. This can have some benefits as it would allow for a standard template that never changes and still enables the user to write data into the profile, but instead redirecting that data to locations outside the actual profile path, this can be achieved by defining Folder Redirection options from within Group Policy.

When a user logs on to a Windows-based computer for the very first time, a profile will not exist for them. Windows will try and generate a profile for this user, if the user is a network-based user and they have a network path defined in their account properties via Active Directory then this profile will be generated at this UNC path defined, if the user does not have a network-based profile path defined then Windows will attempt to generate this profile on the local hard drive under a common location (typically C:\Users for Windows Vista and above or C:\Documents and Settings for Windows XP/2003).

This process of generating a profile occurs by taking a copy of a template profile or skeleton profile and then renaming it as the Users SAM Account name, if the computer already has a “local” user with the exact same SAM Account name as a network-based user who decides to logon, then you will commonly see Windows append the network NetBIOS domain name to the end of the profile path – this occurs so that duplication doesn’t occur.

The profile that is used as the template or skeleton is called the “Default User” profile. I choose to refer to this as a skeleton profile because it should only ever contain the basic parameters and therefore as a result is very light weight and small in size. The default profile can be found as a hidden folder under the common local path for profiles on any computer’s hard drive. You will need to enable Hidden Files and System Files to see this folder. The NTFS Security ACL on this directory is special in that it allows the built-in principal group “Everyone” control to make a copy of the folder or in security terms “read” the folder. In Windows Vista and above this folder is called “Default” and in Windows XP/2003 its called “Default User”.

Now after reading the overview, in no particular order here are some useful guides on managing profiles that I have implemented over the years. Please comment if there are any question with the following;

  • Supported by Microsoft
  • Not-Supported by Microsoft

How to turn the default user profile into a network default user profile in Windows 7, Windows Vista, Windows Server 2008, and Windows Server 2008 R2

  1. Use an account that has local administrative credentials to log on to the computer that has the customised default user profile.
  2. Use the Run command to connect to the NETLOGON shared folder of a domain controller.  For example, the path resembles the following:
    \\<Server_name>\NETLOGON
  3. Create a new folder in the NETLOGON shared folder, and name it Default User.v2.
  4. Click Start, right-click Computer, click Properties, and then click Advanced system settings.
  5. Under User Profiles, click Settings.  The User Profiles dialog box shows a list of profiles that are stored on the computer.
  6. Select Default Profile, and then click Copy To.
  7. In the Copy profile totext box, type the network path of the Windows default user profile folder that you created in step 3. For example, type the following path:
    \\<Server_name>\NETLOGON\Default User.v2
  8. Under Permitted to use, click Change, type the name Everyone, and then click OK.
  9. Click OK to start to copy the profile.
  10. Log off the computer when the copying process is completed.

How to turn the default user profile into a mandatory user profile in Windows 7, Windows Vista, Windows Server 2008, and Windows Server 2008 R2

  1. Log on to the computer that has the customised local default user profile by using an account that has local administrative credentials.
  2. Click Start, right-click Computer, click Properties, and then click Advanced System Settings.
  3. Under User Profiles, click Settings.  The User Profiles dialog box shows a list of profiles that are stored on the computer.
  4. Select Default Profile, and then click Copy To.
  5. In the Copy profile to text box, type the shared network path of the Windows default user folder that you have previously setup.  For example, type the following path:
    \\<Server_name>\Profiles\Mandatory.v2
  6. Under Permitted to use, click Change, type the name Everyone, and then click OK.
  7. Click OK to start to copy the profile.
  8. Log off the computer when the copying process is completed.
  9. On the central file server, locate the folder that you created for the mandatory profile and open it.
  10. In Windows Explorer click Organise, and then click Folder options.
  11. Click the View tab, click to select the Show hidden files and folders check box,   click to clear the Hide extensions for known file types check box,  click to clear the Hide protected operating system files check box, click Yes to dismiss the warning, and then click OK to apply the changes and close the dialog box.
  12. Locate and right-click the NTUSER.DAT file,  click Rename, change the name of the file to NTUSER.MAN, and then press ENTER.

Setting the correct share permissions on a network-based path for hosting roaming profiles or roaming mandatory profiles

When defining a central location on a network file server to host your profiles, it is very important to ensure the correct permissions are defined at the root of the share otherwise you will encounter problems with users either generating a copy of your roaming profile template or writing back to the network location when they log off.

  1. On a central file server, create a new folder or use an existing folder that you use for roaming user profiles. For example, you can use the following folder name “Profiles” and then share that folder.
  2. When sharing I prefer to make the share a hidden share name, although it really doesn’t matter. Each sub-folder or “Profile” that gets generated will have the Owner as the only user with permission to use the directory anyway.
  3. After sharing the folder you need to define the following share permissions. These permissions are not hard and fast but are best practice, you could be a bit more secure and define specific user groups, just ensure that the permisson level is matching below. Remember these are not NTFS ACL’s these are only share permissions and therefore should be sufficient.
    • The share permissions for shared folders that contain roaming user profiles must have Full Control permissions for the Authenticated Users group.
    • The share permissions for folders that are dedicated to storing mandatory user profiles should have Read permissions for the Authenticated Users group.
    • As a best practice add Full Control permissions for the Administrators group or equivalent group.
    • NTFS Security tab should be ok with the default ACL inherted from the root of the drive, this will typically have a CREATOR OWNER built-in principal that has Special permissions defined to enable Full Control on any sub-folder that gets created.

How to turn a custom user profile into a network default user profile in Windows 7, Windows Vista, Windows Server 2008, and Windows Server 2008 R2

Now this guide used to be a supported process by Microsoft, but due to the complexity of what a profile can contain in more modern operating systems – the option to copy a customised profile into the default network profile is no longer supported. Technically can still be done but I guess Microsoft could see the potential problems that could arise and put a stop to this. Windows 7 was the first O.S I noticed the feature dropped in.

Before getting into the detail, please be aware that the more customisation that you do the more chance of creating a profile that becomes invalid for use as a Default skeleton profile. Things like special ACL’s set on sub-folders, storing PKI data or credentials in the vault would all be things that won’t hold when the profile is copied over and could void it also.

The steps here are much the same as the first guide above, although you’ll notice the changes.

  1. Logon to the computer using a Template Account, this can be either a network-based account or a local account with preferably local administrative rights to the computer. Customise the desktop and preferences to your default liking. I normally open applications that have first-run wizards that tend to confuse end-users and make changes to wallpaper or start menu preferences. Some first-run applications I leave if I intend on letting the user pick first run preferences. Setting Auto Update preferences for some applications might be something you choose to do if you don’t have another way to manage these settings.
  2. Now using another account that has local administrative credentials log on to the same computer that has the customised user profile in step 1.
  3. Use the Run command to connect to the NETLOGON shared folder of a domain controller.  For example, the path resembles the following:
    \\<Server_name>\NETLOGON
  4. Create a new folder in the NETLOGON shared folder, and name it Default User.v2.
  5. Click Start, right-click Computer, click Properties, and then click Advanced system settings.
  6. Under User Profiles, click Settings. The User Profiles dialog box shows a list of profiles that are stored on the computer.
  7. Now in this step we need to use a small third-party tool called “Enabler“. This will over come the issue where the Copy To button is grayed out. Microsoft has now set this button to grey out or disable on any profile selection other than the Default Profile. Thus why this guide is no longer supported. Open the Enabler tool and use it to cause the Copy To button to re-enable again. Once doing this step you can go ahead to step 8 – which follows on much the same as the first guide.
  8. Select User’s Profile from the list, this will be listed as the name of the user in step 1 and then click Copy To.
  9. In the Copy profile to text box, type the network path of the Windows default user profile folder that you created in step 4.  For example, type the following path:
    \\<Server_name>\NETLOGON\Default User.v2
  10. Under Permitted to use, click Change, type the name Everyone, and then click OK.
  11. Click OK to start to copy the profile.
  12. Log off the computer when the copying process is completed.
  13. You may want to delete the template profile after testing by logging on as a real user and seeing if it has worked.

What is with this .V2 folder name? I am seeing some of my users get roaming profiles without .V2 appended on the end?

Ok so you’re wondering what the V2 extension is on the end of the folder name for a roaming profile? Basically we all know the jump from Windows XP/2003 based systems to Windows Vista/7 systems was significant in more ways than one, the profile architecture was no different, it’s not just the added folders that might seem to have changed it’s also the registry hive or otherwise known as NTUSER.DAT file that has significant structural changes as well.

Therefore on a standalone local profile there was no need to differentiate the profile types, but when we talk about a shared network path for storing roaming profiles, this could potentially become an issue. In response to the potential conflict here, Microsoft has implemented a special flag in the NETLOGON process that enables the same logical network path to contain either versions of a profile and serve the correct one depending on the client’s operating system. Profiles with .V2 appended are suitable for Windows Vista and above where as Profiles without .V2 are for operating systems before Windows Vista. When you define a Profile Path in Active Directory for a user account, you specify the profile as the folder path without the .V2 in the path name. Windows clients are intelligent enough to append this if a .V2 profile exist.

The only time when a .V2 is not appended onto the folder name is when the profile is generated on a Windows Vista or above computer and it’s the first time a profile has been created for this user. The operating system is assuming that the client will not be rolling back to a older operating system. The structure has been designed to maintain back-wards compatability for those organisations who are migrating users to more modern operating systems and not going back the other way.

I am lazy, why can’t I just copy/paste the profile folders?

Yes, technically you can do this. Manually copying the profile folders and/or replacing a folder by means of copy and renaming is certainly possible – I have seen this done, it’s just not best practice nor a clean method. This is why I began the title as “I am lazy”.

The reason you shouldn’t copy profiles this way is due to the security delegation that the “Copy To” command provides. Unless you make sure that every file/folder copied has inherited the correct security ACL’s then I would recommend just using the purpose-built dialog for this task. Specifically I have found issues where not using the Copy To command has left a default profile skeleton unusable because the NTUSER.DAT file was not reset and permissions were not delegated correctly. The registry hive for the default user profile needs to be in a generic state before a new user can build its own profile from it. Trust me you will have a pain-free experience and possibly not waste time hitting your head against a brick wall if you just take time to follow the correct steps to copy profiles in Windows.

Rating 3.00 out of 5

1 thought on “Tips for customising and managing User Profiles for network-based users”

  1. Pingback: How to manage Windows 8 User Profiles when a user moves between Windows 7 and Windows 8 computers – Tim Raines Blog

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top