Delete users profile windows 2003

Selecting a language below will dynamically change the complete page content to that language. Warning: This site requires the use of scripts, which your browser does not currently allow.

See how to enable scripts. User Profile Deletion Utility Delprof. Details Version:. File Name:. 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. In fact, if you were to compare the two types of profiles, you would find them to be identical.

The only difference is that a profile stored in the network location specified in the user's domain account properties is called a "roaming profile. Roaming profiles are great for Terminal Server environments, although there are a few things that you need to be careful with. The first is that as users use their profiles, the collective size of all the files that make up the profile will start to grow. Left unchecked, user profiles can potentially grow to several or even hundreds of megabytes.

This can severely slow down the logon and logoff process since all those files would need to be copied across the network.

This is so important, in fact, that a whole section of this chapter is dedicated to limiting the size of your roaming profiles. Another potential problem with roaming profiles occurs when you have multiple groups of Terminal Servers separated by WAN links.

On which side of the WAN do you store the profiles for users who need to use servers on both sides? If you need strict control over your users, you can implement mandatory profiles. Mandatory profiles are a form of roaming profile. They both operate in the same way, except that with mandatory profiles the user's settings are not saved when they log off. Any configurations or settings that the user changes are not retained.

Mandatory profiles allow you to create standard profiles distributed to multiple users. They prevent users from "breaking" anything, since their changes do not get copied back up to the master profile location when they log off.

The next time they log on, their mandatory profile is downloaded again, exactly the same as it was the first time. The last profile type is called a "flex" or "hybrid" profile. These terms are usually interchangeable. A flex profile is not really a profile type as defined by Microsoft. Instead, it is process that combines the security and control advantages of mandatory profiles with some scripting to achieve the flexibility of roaming profiles.

Flex profiles have the advantages of roaming and mandatory profiles without the weaknesses. Flex profiles allow you to control the user environment while still letting the users have some leeway in what they can and cannot change. The best part about flex profiles is that you can define which parts and settings of the profile are retained the next time the user logs on and which are discarded. With the flex profile, you configure a mandatory profile for your user's Terminal Server session.

This mandatory profile is loaded the first time a user logs on to your Terminal Server. The user works in her environment and modifies her settings as usual most likely Office settings. When the user logs off, a script runs that calls an executable that saves the configurable settings you specified a file in the user's home folder.

This file is usually between 20k and k. Once the settings have been saved, the logoff process continues and the user's profile which was based on a copy of the mandatory profile is deleted. The original mandatory profile is loaded the next time the user logs on. Once it's loaded, a logon script runs that "customizes" the user's environment with the settings that were saved in the home folder from the previous session.

The beauty of this system is that you get the speed and stability of mandatory profiles, not to mention the control they give you as an administrator , while still having the ability to allow users to retain certain settings within from their sessions.

On top of that, flex profiles significantly reduce the chance of "profile corruption. This is a common cause of support calls in Terminal Server environments that make heavy use of roaming profiles when the design hasn't been well-thought through. The only drawback to flex profiles is that they are not officially supported by anyone. The idea itself has been around for quite some time, but it's implemented in different ways depending on where you find it.

Support is generally only available from public web forums and communities. See the appendix for a complete list. The most popular version of the flex profile is available for free. Visit www. Work your way to the "tools" and then to the "downloads" section of the site.

Van de Kamp's system utilizes a simple logon script that calls proflwiz. This executable uses a simple INI configuration file to determine which registry settings or directories within the profile should be retained.

When setup properly it takes no more than a second or so to run at logon and logoff, which in most cases is much faster than a standard roaming profile after users have been working on the system for awhile. What's great about van de Kamp's script is that it can also be modified to use the ifmember.

This lets you configure settings to be retained based on a user's group membership. Let's assume you have one group of users for whom you wish to retain Office settings and another group for whom you wish to retain only Visio settings. It would be a waste or resources and time to save all the settings for both groups of users if one group only needs Visio and another Office. Connect and share knowledge within a single location that is structured and easy to search.

I have a client machine XP SP3 which used to be connected to a windows domain, but the server has since gone down due to a hard drive failure, however the profiles still remain in 'documents and settings'.

Also, Windows prevents me from deleting or renaming the user's profile folder as well, due to a lock with ntuser. You may try the delprof. You can delete the profile directory manually. Then you just need to get rid of the corresponding registry entry so Windows knows it's gone. If you're not very familiar with the Windows Registry, be sure to backup any registry keys before deleting them.

When your looking at the User Profiles page click the link at the bottom for user accounts. Should be able to delete or downgrade then delete the user there. Sign up to join this community. The best answers are voted up and rise to the top. Stack Overflow for Teams — Collaborate and share knowledge with a private group. Create a free Team What is Teams? Learn more. Can't delete profile Ask Question.

Asked 11 years, 7 months ago. Active 11 years, 7 months ago.