This article discusses the Terminal Server Administration tool, UserManager.
Users have more possible configurations in Terminal Server. For instance,some users may have permission to connect to the Terminal Server as a fileserver but not have permission to use it as an application server (throughthe Terminal Server Client). Also, users can have different profiles andhome directories, depending on whether they are using "normal" workstationsor whether they are connecting through the Client.
When you create a user, the only difference on the main User Manager screenis the additional "Config" button at the bottom. After installing aTerminal Server, you will find the same default users (Admin and Guest) andthe same default groups as you would expect on a Windows NT Servercomputer.
The User Configuration screen allows these options:
Allow Logon to Terminal Server
This is similar to giving the user the right to log on locally.
By default, Everyone has the right to log on locally (that is, to log on atthe Terminal Server console). Just as in Windows NT Server, this right isset in User Manager by selecting User Rights on the Policies menu. BecauseTerminal Server clients are, in effect, logging on at the server's console,this is a necessary right.
NOTE: Denying users the right to log on locally will keep Terminal Serverclients from logging on at all.
NOTE: Because this right is necessary for Clients to be able to log on, ifyou install a Terminal Server as a domain controller, two situations arelikely to occur. First, if you install as a backup domain controller (BDC)with an Windows NT Server as the primary domain controller (PDC), when yourTerminal Server joins the domain, Everyone will lose the right to log onlocally because these policies are global to the domain's domaincontrollers. Second, if you install a Terminal Server as a PDC, Everyonewill be able to log on at the console of any BDCs in the domain, whetherthey are Terminal Server computers or not.
So, for a client to be able to log on to the Terminal Server, the user musthave two rights: the User Manager user right to log on locally and the user-specific configuration "Allow Logon to Terminal Server."
If you deny a user the "Allow Logon to Terminal Server" right, that userwill not be able to log on at the Terminal Server console or through theTerminal Server client. But the user can log on normally from other WindowsNT servers, workstations, or other domain workstations. So, if anadministrator has a group of users who will connect through the client andanother who will log on normally, this is the correct check box forallowing or denying access.
It is also possible to remove the Everyone group from the right to log onlocally. Another group of client users can be created and given this right.
If a user attempts to log on to a Terminal Server through the client andhas been denied the right to log on locally, the user will receive thismessage:
The local policy of this system does not allow you to log on interactively.
If the user does not have the check box selected in User Configuration for"Allow Logon to Terminal Server," another error is returned:
Your interactive logon privilege has been disabled. Please contact your system administrator.
If BOTH permissions have been denied the user, he or she will get thefollowing message:
The local policy of this system does not allow you to log on interactively.
Timeout Settings (in Minutes)
Connection: By default this is turned off. This setting controls how long aclient can be connected. This is not dependent on any other state (forexample, being disconnected or idle). If a user can only be connected for10 minutes, then 10 minutes after connection, the user will bedisconnected. If this feature is enabled, the default value is 120 minutes.
Disconnection: After a user has been disconnected, how long should theTerminal Server keep the session active? When a user is disconnected, theserver keeps the session and all running processes active, so that the usercan reconnect and continue working where she or he left off. This refers toany type of disconnection (for example, connection timeout, dropped modemline, network failure, user selects Disconnect on the Start menu). If thisfeature is enabled, the default value is 10 minutes.
Idle: How long should the server wait before disconnecting an idle session?If this feature is enabled, the default value is 30 minutes.
This setting does not apply to Microsoft's RDP client. If Citrix's ICAclient is being used, these settings are relevant and determine whether theclient computer's local devices will be available as local devices while ina Terminal Session.
If you are logged on to a Terminal Server using the RDP client, when youaccess your drive C, you are accessing the server's drive C, not your localdevice. The same is true for printers, printer ports, and COM ports.
You can specify an application to start up as soon as the user logs onthrough the Client. This is similar to placing an application in the user'sstartup folder.
The option to "Inherit Client Config" applies only to Citrix's ICA Clients.
On a Broken or Timed out Connection...
If a connection is lost or times out, you have the options of disconnectingthe session, which leaves the session intact so the user can reconnect andkeep working, or you can reset the connection, which terminates thesession.
Reconnect Sessions Disconnected...
This option is used for Citrix direct-serial-port connecting devices only.
Modem Callback Is...
Modem callback options apply only to Citrix's ICA Clients. For Microsoft'sRDP client, configure these settings through RAS.
Shadowing applies only the Citrix's ICA clients. Shadowing allows ICAclients to view or take over other ICA client sessions. Note that theTerminal Server console cannot be shadowed, and sessions cannot be shadowedfrom the console. Shadowing only works from client to client and only inconjunction with the ICA client and Metaframe.
User Configuration also includes a new option for NetWare users:
NetWare Logon Configuration:
Terminal Server offers the same NetWare connectivity options as Windows NTServer 4.0, with 3 additions. The first is here in User Manager. Specifyinga NetWare server here will allow the user to log on to NetWare prior tologging on to Terminal Server or Windows NT. If you add a domainadministrator name and password here, if the user's NetWare passworddiffers from the Windows NT password, the NetWare password will be used,and the Windows NT password will be synchronized to it.
The other two new NetWare options are the Administrator utility "NetWareUser Access for Terminal Server," which copies NetWare user accounts toTerminal Server, and the command-line utility NDSPSVR, which sets apreferred NDS logon server globally (this is not available on a per-userbasis) for all NetWare users who connect to this Terminal Server.
The User Environment Profile screen:
Note that this is very similar to the Profile settings for Windows NTServer users. The only difference is that you can specify two differentprofiles and two different home directories for each user. If the user logson normally from a Windows NT workstation, for instance, he or she can havea different profile and home directory than if he or she logs on to theTerminal Server through the RDP client. One profile can be roaming and theother mandatory.
User Profiles Overview:
- If you specify a User Profile Path only, the user will get that profile regardless of how he or she logs on.
- If you specify a Terminal Server Profile Path only, the user will get the profile if he or she logs into the domain from any Terminal Server console or through the Terminal Server client. Otherwise, the path will be ignored.
- If you specify both a User Profile path and a Terminal Server Profile path, the user will use the User Profile path if logging on at a Windows NT Workstation computer or Windows NT Server computer (not a Terminal Server and not using the Terminal Server client program), and the user will use the Terminal Server Profile path is logging on at any Terminal Server console or through the client program.
- Profile types can be mixed. That is, if a user has two profile paths, one can be mandatory and the other non-mandatory.
Windows Terminal Server 4.0 and Windows NT Server 4.0 both use UserProfiles to store user's desktop information. These profiles are simply aseries of folders, typically stored under a folder named with the user'slogon name. By default, every user who logs on to a Windows NT Workstation4.0, Windows NT Server 4.0, or Windows Terminal Server 4.0 computer gets aprofile folder under the %SystemRoot%\Profiles folder. When users log on,the profile is loaded into HKEY_CURRENT_USER in the registry. When the userlogs off, the registry information is written to the user's profile folder.One important note: if you store the profile someplace other than thedefault location, the profile is always copied to the user's%SystemRoot%\Profiles folder before it is loaded into the registry. This iscalled the Locally Cached Profile. It allows the user to get the expecteddesktop even if the network is unavailable. This is an important concept inTerminal Server. (Also note that this caching of profiles can be turned offthrough a System Policy.)
In User Manager, administrators can specify a path for profiles. This pathcan be local or can reside on a network share. One common practice is topick a central network location, create a Profiles folder, and share it foreveryone to use. Then, in User Manager, under Profiles\User Profile Pathenter the path \\Server\Profiles\%username%. By using this path,administrators can select several users at once and set their profile pathsquickly.
Terminal Server allows users to have two profile paths: a User Profile Pathand a Terminal Server Profile Path. The User Profile Path is identical tothe User Profile Path function in Windows NT Server 4.0. Users have threelogon options with Terminal Server. They can log on "normally" from acomputer running either Windows NT Workstation or Windows NT Server, theycan log on at the Terminal Server console, or they can log on through theTerminal Server client software. If only a User Profile Path is specified,the user will get the same profile regardless of the logon type she or heuses.
Before considering the Terminal Server Profile path, it is important tonote where the local profile cache is located for each logon type. If theuser logs on from a computer running Windows NT Workstation or Windows NTServer (that is, not using the Terminal Server client software), theprofile is copied from the profile path location to the user's computer,saved in the local %SystemRoot%\Profiles\Username folder, and then loadedinto the registry. However, if the user logs on at the Terminal Serverconsole or through the Terminal Server client, the profile is loaded intothe Terminal Server's %SystemRoot%\Profiles\%username% folder.
Also note that, for logon purposes, a Terminal Server console is consideredthe same as a Terminal Server client session. So, if you specify a TerminalServer Profile path in your domain and the user logs on to the domain fromany Terminal Server console, she or he will use the Terminal Server Profilepath. However, the profile will be cached in the%SystemRoot%\Profiles\%username% folder of the Terminal Server at which theuser logs on. When the user logs on through the Terminal Server client, theprofile is always cached on the Terminal Server to which the user connects.
If users need different profiles, it is okay to specify a different profilepath for User Profile path and for Terminal Server Profile path. Theseprofiles can also be different types; that is, one can be mandatory and theother nonmandatory.
However, administrators should carefully consider profile caching beforedeciding on a profiles strategy. There is a particular situation thatshould be avoided (and this is true in both Windows NT Server and TerminalServer). If a user logs on to different domains in which he or she hasdifferent profile types (mandatory/nonmandatory) so that the cached profileis being overwritten with different profile types, the user's profile willnot work as expected. Nonmandatory profiles may be ignored, and mandatoryprofiles may become nonmandatory. This situation can also be created if auser initially has a User Profile path to a mandatory profile and then theuser is given a nonmandatory Terminal Server Profile path.
Fortunately, this is not a common scenario because users are not typicallyallowed to log on at the Terminal Server console. It is also rare to haveWindows NT Workstation users log on to one domain with a mandatory profileand another domain with a nonmandatory profile.
If your environment will not allow you to avoid this locally cached profileconfusion, you can create a System Policy that tells the system not tocache the profiles. This option is found under Default Computer\Windows NTUser Profiles\Delete cached copies of roaming profiles. With this policy inplace, the problem will not exist since the cached profile never gets mixedwith various profiles.
Further, it is especially important to have home directories specified foreach user. The default location is the user's locally cached profile. Ifthe user logs on under one of the scenarios to be avoided, having differentprofiles writing over the locally cached profile, the use will beoverwriting the home directory and potentially any saved filed. If the homedirectory is in the default location (locally cached profile) and you set asystem policy to not to cache roaming profiles, the home directory can bedeleted, again perhaps losing files. This is a problem not only because thehome directory could have user files in it, but because the home directorycontains a Terminal Server specific directory, the user's Windowsdirectory. This is where user's application-specific .ini files are stored.