Windows 2003 local settings temp folder

Any behavior that is insulting, rude, vulgar, desecrating, or showing disrespect. Any behavior that appears to violate End user license agreements, including providing product keys or links to pirated software.

Unsolicited bulk mail or bulk advertising. Any link to or advocacy of virus, spyware, malware, or phishing sites. Any other inappropriate content or behavior as defined by the Terms of Use or Code of Conduct. Any image, link, or discussion related to child pornography, child nudity, or other child abuse or exploitation. Unlock 1 Answer and 3 Comments. Andrew Hancock - VMware vExpert. See if this solution works for you by signing up for a 7 day free trial.

What do I get with a subscription? With your subscription - you'll gain access to our exclusive IT community of thousands of IT pros.

We can't always guarantee that the perfect solution to your specific problem will be waiting for you. If you ask your own question - our Certified Experts will team up with you to help you get the answers you need. Improve this answer. Evan Anderson Evan Anderson k 18 18 gold badges silver badges bronze badges. The Overflow Blog. Stack Gives Back Safety in numbers: crowdsourcing data on nefarious IP addresses. Featured on Meta.

New post summary designs on greatest hits now, everywhere else eventually. However, if user profiles are not designed properly, you will need to perform manual customization before bringing new servers or users into your environment. If this profile is created from scratch, the user must manually configure everything himself. That could take a fair amount of time, and there's always the risk that the user won't configure things properly.

On the other hand, if you pre-configure the user's profile then the user can begin working immediately. All of the options will be set up properly. If you give users mandatory profiles without telling them, they may try to save their settings only to find that their settings were not retained the next time they log on. Mandatory profiles prevent users from saving any preferences or settings to their application environment. If you use local profiles in an environment where users will try to save the settings from their Terminal Server sessions, the users may become confused because their environment could change from day to day as they connect to different servers.

This would decrease productivity and increase users' frustration. If your users use the same roaming profile on their local computer as they do when running sessions on Terminal servers, configuration settings or data could be lost from one of the sessions, since whichever session is logged off last will overwrite the master profile.

When a user with a roaming profile logs onto a Terminal Server session, he must wait as his profile is copied from its network storage location to the local Terminal Server. If the profile is large or if the network connection is slow, the user will be forced to wait a long time.

Remember that roaming profiles are entirely copied down from the network when the user logs onto a Terminal Server. They're then copied back up to the network when the user logs off.

Profiles can easily be several or even dozens of megabytes in size. If many users simultaneously log on and try to download their roaming profiles, it could negatively impact the network. You must consider the size of the profile, the speed of the network, and the number of users logging on or off together to determine if your network can support your users' profiles. When creating your strategy for managing the profiles of your Terminal Server users, there are many configuration options available.

You'll need to provide answers to several design questions:. All settings and configuration information contained in a user profile must be configured at some point. You can either preconfigure it so that it's ready to go the first time the user logs on, or you can let users configure their settings after they log on. When you're using local or roaming profiles, a copy is made of the local computer's "Default User" profile whenever a user who does not have a profile already created logs on.

As an administrator, you can use this to your advantage. Any changes that you make to the "Default User" profile will be included in each new copy of it, thereby allowing you to modify it to "preconfigure" user profiles. Rather than configuring the "Default User" profile manually, there is a shortcut that is much easier to use:.

Either of these methods will update the "Default User" profile, causing new users to receive their profiles based on this modified default user profile. You can make additional changes to the default user profile at any time, but be aware that any changes you make will not affect the current profiles that have already been created.

The process above can also be used to create a mandatory profile. Instead of copying the "Profile Template" profile to the Default User, you would simply copy the contents of the profile to the location where you wish to store your mandatory profile.

If you have more than one Terminal Server, you should copy the "Default User" profile that you modified to all of your servers since new user profiles are always generated from the local "Default User" path.

If you don't copy the profile, you might get users with profiles based on the wrong template depending on which server they logged on to. Instead of pre-configuring user profiles, you can simply choose to have your user profiles generated from the generic "out of the box" profile. Or, if you have scripting skills, you can use a logon script to configure users' environments the first time they logon.

More information about scripting user environment changes is available later in this chapter. At some point you must decide whether you will use local, roaming, mandatory, or flex profiles. As you're making this decision, keep in mind that you don't need to have an "all or nothing" solution. You may want to give some users flex profiles, while still restricting another group's ability to change any settings with mandatory profiles.

Local profiles can be used where the settings in the profile don't matter. This is usually the case when you're using policies to define desktop settings or when users are connecting to a single application that does not depend on the user profile at all. Also, if you're just starting out and you only have one Terminal Server, you can begin with local profiles.

As your environment grows, you can copy the existing local profiles to network share locations allowing them to be used as roaming profiles. The next option is roaming profiles. Roaming profiles are used most often in real world environments for the convenience they provide over local profiles.

Mandatory profiles are most often used in locked-down environments, although they're not necessary if policies are configured properly. Finally, Flex profiles are most often used in environments where speed, security and user perception are all a concern.

Of course, these are a concern in all environments, which is why this solution is rapidly growing in popularity. By default, user profiles contain many files and folders. Because every user's roaming profile is copied to the Terminal Server at logon and copied to the master network share location at logoff, it's important to keep the roaming profile as small as possible.

Left unchecked, a user's profile can easily grow to dozens or even hundreds of megabytes. When a user logs on, she must wait for the entire profile to be copied to the Terminal Server from the master network share.

If the profile is large, the logon process will be slow. It will seem to "hang" while the profile is copied. This is easily the most frequent cause of slow logons in Terminal Server environments. By default, any folders that contain user-specific information are part of the user profile.

As you saw back in Figure 6. For example, the "My Documents" folder is part of a user profile. In using your Terminal Server, most of your users will make extensive use of their "My Documents" folder.

In roaming profile environments, this can cause the profile to increase in size as users store more and more documents. Recall that when using roaming profiles, an increase in size is a bad thing. To mitigate this size issue, you have the option of redirecting certain profile folders to locations outside of the user's actual profile. This is part of the Windows IntelliMirror technology. For example, redirection could allow the "My Documents" folder to point to a static network location that never changes instead of a folder inside the user's roaming profile.

Users with a redirected "My Documents" folder continue to open, save, and browse "My Documents" as usual. They would not be aware that any redirection was taking place. The advantage to redirection is that the contents of the "My Documents" folder would be stored in one location like the user's home folder. This content would not be copied to and from the Terminal Server with the rest of the roaming profile.

Users would access a single "My Documents" network location no matter what Terminal Server they used. As an administrator, you'll need to choose which folders to redirect from user profiles.

Choosing these folders creates a balance between keeping the user profile as small as possible while allowing users to have fast, local access to their data. You have a lot of flexibility in the implementation of folder redirection, allowing you to evaluate which folders to redirect on a folder-by-folder or user-by-user basis.

If a folder contains configuration information that will be accessed in every session then you should probably not redirect it. However, folders containing user data files are good candidates for redirection since not all user files are used during every session.

However, throughout the course of a Terminal Server session, a user will only actually use a fraction of those documents. There's no reason that all documents should be copied to the Terminal Server every time the user logs on.

In Terminal Server environments, the most common implementation of this strategy is to redirect the "My Documents" and "Application Data" folders, although experimentation in your environment will tell you which folders work best for you. While it's technically possible to redirect the "Desktop" folder, you should really only redirect this across the network if it's actually necessary. Since the "Desktop" folder corresponds to the actual user's desktop, redirecting it means that the user's desktop is a view to a remote network drive.

The problem with this is that as long as the desktop is visible in the session, Windows will continuously refresh the contents of the desktop across the network. This doesn't affect anything in single server environments, but it has the potential to add unneeded traffic to your network when a Terminal Server is full of users whose desktops are redirected. Folder redirection can be set manually with the registry editor or applied via a policy.

Windows lets you redirect any of the 18 default folders. When specifying a target for the redirected folder, you may enter a UNC name instead of a hard-coded path. This registry key contains a values entry for each profile folder. You can change these to point to any path you want. Note that in order to access this option, you must connect to a live Active Directory environment.

You can't simply run gpedit. When configuring your GPO, you can set folder redirection on a group-by-group or a computer-wide basis all within the same GPO. You can also graphically configure options such as whether you want to redirect all users to a single folder or redirect each user to their own folder.

You may determine that some folders in a user's profile contain data not worth saving from session to session. In order to further decrease the size of roaming profiles, you can choose to exclude those folders from the roaming profiles altogether.