When a user logs on to a workstation, the system checks the profile path attribute of his or her user object to see whether the user has a centrally stored profile. If he or she does, and it is newer than any locally cached copy that may exist, the profile is downloaded for the user. In the same way, when a user logs on to a terminal server, the system queries the UserParameters attribute and looks for a Terminal Services Profile path. Figure 4.14 shows the Terminal Services Profile tab of a user object.
This separation enables administrators to maintain separate profiles for users depending on which type of computer they are accessing. In most cases, you will want to take advantage of Terminal Services profiles, as certain functions of Terminal Services make it difficult to not maintain them. I'll explain what I mean.
If you do not use roaming profiles for your users' workstations, you rely on the fact that the computer maintains a copy of the user profile. If your users do not log on to more than one PC, this setup is perfectly fine. On a terminal server, however, not using roaming profiles means that the terminal server would be maintaining the profiles for all your users. Also, if you need to scale your Terminal Services infrastructure and use load balancing to distribute your users among more that one terminal server, your users would be maintaining separate profiles on each server.
To alleviate the disk space problem, we can enable a system policy that deletes cached copies of roaming profiles. This way, after a user logs off of the terminal server, the disk space is reclaimed once the system copies the profile back to the central location.
^ If you do not define a Terminal Services profile path but define a Windows roaming profile path, the terminal server will use the Windows profile. Also, if the Terminal Services profile is defined but unavailable, the system will fall back on the Windows profile. This behavior may have undesired results if you are using applications with ACSs on your server. See the appendix for a script that will detect whether the profile that is loaded is a Terminal Services profile and will log the user out before any ACSs run.
If you use roaming Windows profiles, using Terminal Services profiles can be even more critical, because if the system does not find a Terminal Services profile path in the user's account, it will then look for a Windows profile path and use it instead. As you learned in Chapter 3, ACSs often make changes to registry settings under the HKEY_CURRENT_USER subkey to help tune applications for simultaneous users. If these changes are made to the user's Windows profile, the user might experience problems the next time he or she logs on to a workstation.
Geography may also be a factor in separating your profiles. You probably store you users' Windows profiles on file servers that are close to their workstations, but your terminal servers, given their low-bandwidth requirements, may be in a central data center. You would not want to have to pull a profile across a slow WAN link.
O When you enable Terminal Services, a utility is added to the system, TSPROF.EXE. This utility allows you to query, copy, and update Terminal Services profiles on your user objects without having to go into the Active Directory Users and Computers snap-in.
Was this article helpful?