Where are user profiles stored in windows 2003

If you chose the SMB Share - Advanced profile, on the Quota page, optionally select a quota to apply to users of the share. This GPO allows you to configure Roaming User Profiles settings such as primary computer support, which is discussed separately , and can also be used to enable Roaming User Profiles on computers, as is typically done when deploying in virtualized desktop environments or with Remote Desktop Services.

From the Tools menu select Group Policy Management. Group Policy Management appears. This prevents the GPO from being applied until you finish configuring it. Select the GPO. This step is necessary due to security changes made in MS If you are deploying Roaming User Profiles to user accounts, use the following procedure to specify roaming user profiles for user accounts in Active Directory Domain Services.

If you are deploying Roaming User Profiles to computers, as is typically done for Remote Desktop Services or virtualized desktop deployments, instead use the procedure documented in Step 6: Optionally set up Roaming User Profiles on computers.

If you set up Roaming User Profiles on user accounts by using Active Directory and on computers by using Group Policy, the computer-based policy setting takes precedence. Select all users to which you want to assign a roaming user profile, right-click the users and then select Properties.

For example:. To specify a mandatory roaming user profile, specify the path to the NTuser. For more information, see Create mandatory user profiles. However, when using a special profile, apps are not deployed by default. However, deployed apps in this scenario will leave some data stored on the computer, which could accumulate, for example, if there are hundreds of users of a single computer. To clean up apps, locate or develop a tool that uses the CleanupPackageForUserAsync API to clean up app packages for users who no longer have a profile on the computer.

If you are deploying Roaming User Profiles to computers, as is typically done for Remote Desktop Services or virtualized desktop deployments, use the following procedure.

If you are deploying Roaming User Profiles to user accounts, instead use the procedure described in Step 5: Optionally set up Roaming User Profiles on user accounts. If you set up Roaming User Profiles on computers by using Group Policy and on user accounts by using Active Directory, the computer-based policy setting takes precedence. From the Tools menu, select Group Policy Management. Group Policy Management will appear. Right-click Set roaming profile path for all users logging onto this computer and then select Edit.

A user's home folder, if configured, is the default folder used by some programs such as Windows PowerShell. You can configure an alternative local or network location on a per-user basis by using the Home folder section of the user account properties in AD DS. To configure the home folder location for all users of a computer running Windows 8.

Do not use environment variables or ellipses. The user's alias is appended to the end of the path specified during user sign on. To specify a mandatory roaming user profile, which is a preconfigured profile to which users cannot make permanent changes changes are reset when the user signs out , specify the path to the NTuser. For more information, see Creating a Mandatory User Profile. If your PCs are already deployed you can script the removal of these apps using the Remove-AppxPackage.

A "profile" is a collection of settings, configurations, and personal files that are unique to each user. Profiles permit multiple users to have different environments, even if they're all connected to the same server at the same time. Correctly implementing user profiles allows one user to set his Windows background to a picture of his kids, his mouse pointer to a dinosaur, and his menu color to purple—while another user can log on with normal settings.

There are hundreds of components that can be configured via user profiles. Some of these include:. In addition to the hundreds of Windows components that can be configured with a user profile, every application loaded on a server introduces more of its own settings. Microsoft Word has hundreds of settings, including file save locations, custom dictionary locations, grammar checking preferences, etc.

In fact, you can use a profile to customize practically any setting stored in the registry. Before discussing how user profiles are used in Terminal Server environments, let's see how they work.

This user profile is made up of two parts:. The files and folders that make up a Windows user profile allow each user to have his own unique environment.

One user's "My Documents" folder can be different from another user's "My Documents" folder. Even though each user sees the folder as "My Documents," they are two separate destinations accessed by two separate paths. Basically, any folder containing files specific to a user is part of the user profile.

User profiles are important in Terminal Server environments since there can be hundreds of users on the same server at the same time, and each needs access to his own custom folders.

In addition to the collection of folders, a user profile also contains Windows Registry settings that are used to maintain the user's individual application preferences and settings.

These include the file save locations in Microsoft Word, the proxy settings for Internet Explorer, the mouse cursor and scroll speed of Windows, and mapped printers and network drives. Registry settings are stored in each user's profile in a file called ntuser. Whenever a user logs on to Windows, his preferences are read from the ntuser. Because each user has his own HKCU hive even when multiple users are logged on at the same time , each can have his own settings on a Terminal Server.

This means that each user also has his own ntuser. What about the few remaining applications that use. INI configuration files instead of the registry for their configuration information? How do user profiles support different. INI files for different users? Fortunately, the architecture of Terminal Server allows multiple users to each have his own copy of centralized. INI files, even if these.

INI files are stored in common locations. This architecture is set up automatically when a server is placed into "install mode" for application installation.

Refer to Chapter 5 for more information on install mode. When an application is installed while the server is set to "install mode," any. INI configuration files usually written to common folders are instead diverted to the user profile location. For example, if an application installation procedure tries to create a file called application. Then, whenever the application looks for its application. INI file in the user profile, not the one in the common Windows folder.

This allows each user to maintain his own unique settings for applications, even if the applications don't properly use the Windows registry. In order to further understand user profiles, let's examine a sample. Figure 6. In the real world, all user profiles are different, but this table lists the basics.

It's important to note that every user who logs on to your Terminal Server has some form of user profile, even if that user only runs a single application and not a Windows desktop. This is due to the fact that running an application in an RDP session does not prevent Windows from running a server desktop in the background.

Terminal Server hides this desktop from the user so that the user can use his own local desktop. Now that we've reviewed the basics of Windows user profiles, let's take a look at the four different ways that profiles can be used in Terminal Server environments:.

Every Terminal Server user profile must be one of these four types. Each type is useful for different situations, and you can mix and match different types on the same server as needed. A "local profile" is a user profile stored locally on one computer. Local profiles contain the files, folders, and registry settings for each user as previously discussed. However, local profiles are only applied to the user environment when the user logs on to the computer where the local profile is stored.

Because local profiles only apply when the user logs on to the particular computer where the profile is stored, they work best when users are allowed to save their settings and configurations in single-server environments.

As outlined in Figure 6. If the user's profile is found, it is loaded into memory and its settings are applied. If the system cannot find an existing local profile for the user, a new local profile is created by making a copy of a generic profile template.

This creates a local profile for the user, and any changes made to the configurations or preferences are stored in the user's new local profile. When the user logs off, the system retains the user's local profile so that the next time the user logs on to that computer his own customized environment is loaded complete with pink backgrounds and dinosaur cursors.

Local profiles work well when users only log on to one server. The main disadvantage of local profiles is that they are always "local" to the computer where they were created. If a user has a local profile on one computer and logs on to another computer, a different local profile will be used or created.

There is no way for the second computer to access the profile that the user has created on the first computer. Obviously, local profiles can cause problems in an environment with multiple Terminal Servers since each server will contain a different local profile for each user.

In an environment with five Terminal Servers, each user would have five different local user profiles. Users would get a different profile depending on which server they logged on to. Confusion would be compounded when users connected to load-balanced applications where they are automatically connected to the least busy server.

One day, a user might connect to Server A. The next day, he might get Server B. From the user's standpoint, each day could bring a different profile with a different Windows background or application settings. In light of this scenario, it would be helpful if there were a way to store user profiles in a centralized location, allowing the user to get his own profile no matter what Terminal Server he logged on to.

Roaming profiles accomplish just that. A roaming profile is a user profile stored on a network share instead of on a local computer. When the user logs on to a computer, the computer checks to see if that user is configured to use a roaming profile.

If so, the computer copies the contents of the user's profile from the network share to the local computer, and the profile is loaded into its memory.

In this way, each user gets her own environment no matter where she logs on. Any changes that the user makes throughout the session are saved in the profile. When the user logs off, the profile is copied back to the original network share. That way, the next time the user logs on, the environment is exactly as she left it, even if she logs on to a different computer. For a user to have a roaming profile, you simply specify the network path where the profile will be stored.

When configuring a user's domain account, you will see two profile fields listed in the user's properties. These two fields are empty by default, indicating that the user is configured for a local profile. To configure a roaming profile, you must understand the differences between these fields and how they relate to each other. Let's consider what happens when a domain user logs onto a Terminal Server.

You can visualize this process with Figure 6. When a domain user logs on to a Terminal Server, the server contacts a domain controller and receives the user's profile paths. It then attempts to load that user's roaming profile from the network path specified in the "Terminal Services Profile" text field property of the user's account. If that field is blank, the server will attempt to load the roaming profile from the path specified in the "Profile Path" text field.

If that field is also blank, the server knows that no roaming profile has been specified, and so it creates or uses a local profile. If a user logs onto a non-Terminal Server, the system will immediately look for the roaming profile in the "Profile Path" location, bypassing the "Terminal Services Profile" text field.

This allows you to specify different profiles for users depending on whether they log on to a Terminal Server or a regular computer. This is useful because profiles on Terminal Servers tend to be different from profiles on regular workstations. When a user with a roaming profile logs off of a computer, the roaming profile is copied from the computer back up to the roaming profile master location.

As a result, the user will access the most up-to-date profile the next time he logs on, including any changes made during his last session. Roaming profiles contain the same components, files, and folders as local profiles. Operating system of the server is Windows Server with SP2 and all the latest are updates installed. Do you have any ideas how to get rid of these old user profiles? They consume some disk space and are unnecessary on the server.

The User Profile Hive Cleanup service helps to cleanup user sessions which are not completely terminated and terminates connections to registry keys which applications maintain in the user profile. This posting is provided "AS IS" with no warranties or guarantees and confers no rights. Most of the downtime's are caused because of SysAdmin's curiosity!

What next? How this tool can be run? This folder is not created on a new installation of Windows. If you do not want to create the Netlogon share in the default location, put the logon script in any folder that the user can access during logon, and then share this folder. Skip to main content. This browser is no longer supported.

Download Microsoft Edge More info. Contents Exit focus mode.