Some of the main topics in this chapter are
Administering users and groups is an essential element of overall system administration in a Windows NT environment. From access to security, proper management of users and the groups to which they belong is critical to a successful Windows NT network system.
In this chapter, you learn about the many tools available in the Windows NT operating system that help you properly manage the users and groups in your system.
The heart of system management in Windows NT is the user account. Whether you use the workgroup model or the domain model, creating and managing user accounts is a task you'll perform often. Although Windows NT brings account control under one interface (called User Manager), which greatly simplifies the process, it's still important that you fully understand user account management, including the use of User Manager.
Domain versus Workgroup ModelsIn the Windows NT environment, you must determine whether to use the workgroup model or the domain model.
In general, the workgroup model is appropriate for smaller networks that essentially function as peer-to-peer networks. In this model, each station has Windows NT Workstation, and there isn't necessarily a central Windows NT Server. In this configuration, a user must have an account on his local computer, as well as an account on each workstation to which that user needs access. For example, if the user needs access to shared resources on each of the other 15 stations in the network, that user must have an account on each of those stations.
In the domain model, by contrast, a user needs only one account within the domain to access resources anywhere on the network. In this model, at least one computer must have Windows NT Server software. This computer (the server) will serve as the primary domain controller (PDC) and authenticate access for requests for resources across the domain. In addition, other computers, also running Windows NT Server, can act as backup domain controllers (BDCs), though this is not required. If BDCs are used, they can enhance overall performance and provide redundancy in case the PDC fails.
The basic working component of Windows NT access and control is the user account. To log on to a computer with Windows NT, you must have a user account. As mentioned earlier, if you're logging on to a computer in a workgroup environment, you must have an account on the workstation itself, as well as any other workstations with resources you plan to use. If you're logging on to a domain system, you must have an account in that domain or a trusted domain. (For more about trusted domains, see the following section.)
The user account contains information such as the name of the user, a security password, logon permissions, which resources the user can access, and to what level those resources can be accessed. In other words, a user account sets all the parameters of the user's access to the network and its computers.
To understand how to apply groups, you need to understand what a trust relationship is and how it works. A trust relationship is a special logical relationship between two or more domains. In a trust relationship, one domain "trusts" another domain's users. Just as you may (or may not) "trust" someone enough to allow them access to your bank account, the trusting domain allows users who have accounts in the trusted domain to access resources in its domain. If domain A is the trusting domain and domain B is the trusted domain, then a user from domain B can access resources in domain A.
A trust relationship can be one-way or two-way (unidirectional or bidirectional). Fred trusts you to access his bank account, but you might not trust Fred to access yours. Likewise, the fact that domain A trusts domain B does not mean that B trusts A. You must explicitly set up the trust relationship between the two domains to be bidirectional if you want it to be so.
See "Master Account Domains, Resource Domains, and Trust Relationships," p. 92
Besides individual accounts, users can also be part of selected groups. A group is simply a number of users with some similar characteristics, such as access to certain resources. A given user can belong to as many groups as you deem appropriate.
For example, your organization may have all its budgeting data in a single folder. Although you might want all the users in the accounting department, plus all the department heads to have access to this data, you probably don't want all the network users to have such access. For this reason, you might create a group named Budget and grant all members of that group access to the budgeting data. To this group, you would add individual user accounts.
TIP: When you create a new resource, you can simultaneously grant access to that resource to predefined groups. Using the example just given, when you create the folder containing budgeting data, if you already have a group that contains all the users in the accounting department and another group containing all the department heads, you can simply grant those two groups access to your new budgeting folder. In addition to the two groups, you can also add any individual users who also need access but aren't members of one of the two groups.
The group concept enables you to administer resources and control access on a broad basis, saving time that otherwise would be necessary to assign each and every individual user the same access.
Using groups greatly simplifies the process of controlling access to resources on your network. To efficiently use groups, follow these three steps:
2. Create groups based upon your resource plan for each resource and grant the appropriate groups access to the appropriate resources.
3. Add to the group any users who need access to those resources.
With groups in place, it's easy to change the users' level of access to shared resources, or to add or take away resources from the group, because changes made to the group's permissions are applied globally to all users in the group.
Continuing the budgeting example, the Budget group may have access to last year's financial data. After the new year's budget is complete, however, you simply remove the group's permission to view the old data. This is much faster and easier than having to remove the same permission from each of several individual users' accounts.
Windows NT supports two types of groups: global groups and local groups. The following sections describe these types of groups.
Global Groups. Global groups (also called domain groups) are groups of domain users (in contrast are local users, whose access is limited to the computer on which they were created). A global group can be granted permissions in other domains through a trust relationship between the domains. The scope of global groups is the domain on which the users in the group are created. Permissions for a global group can be any Windows NT server or workstation in the domain. Here are some of the characteristics of a global group:
Global groups cannot contain local users because it would defeat the purpose of a global (or domain-wide) group. Because global groups can have permissions on any domain resource, putting a local user in a global group would give that user access to domain-wide resources. This contradicts the rule for local users that states a local user (by definition) can only have rights on the computer where the local user was created.
Local Groups. A local group is generally a group of users with access to a local resource, such as the drive on a local workstation. Local groups, however, can contain local users and global groups, which enables you to collect users from multiple domains into one group and manage them collectively.
For example, you might have a local group of users with access to only drive C on a Windows NT workstation. That local group can contain local users (with access only on that workstation) as well as a global group with access to the drive (plus whatever other rights they might have).
The benefit of allowing global groups in local groups is that it saves time in creating permissions. For example, if you have a pre-existing global group of domain users named Biggroup with 15 members and another two local users with access to a workstation (such as Tom's computer), you can create a local group consisting of the two individual local users plus Biggroup. This saves having to create a total of 17 permissions for Tom's computer's hard drive, as shown in Figure 21.1.
In Figure 21.1, the local users (Tom and Bill) are added as local users, and each of the domain users is added individually. By contrast, in Figure 21.2, a global group of domain users (Biggroup) is added as a group along with the individual local users.
TIP: Windows NT has several built-in global groups, including Administrators, Server Operators, Print Operators, Domain Users, and Guests. These groups are discussed in the following section.
By using local groups, you can group together accounts from one or more domains. The local group can contain individual users and global groups from outside the local domain, if those users and groups belong to a trusting domain. The primary purpose for local groups is to enable you to quickly assign permissions to resources within a domain to users and groups in the local domain, and to users and groups in other domains that trust the local domain.
While using Windows NT, global groups and local groups are distinguished graphically throughout the various interfaces. For instance, within the domain where they were created, global groups are shown without the domain prefix, whereas outside the domain where they were created the domain prefix is shown. That way, you can quickly determine whether you're working with a global group from the domain itself or from an outside (trusted) domain.
Permissions can be added to a local resource by individually adding all users, including those already assigned to a global group.
Here, permission to a local resource is assigned by using a local group with both local users and a global group of domain users.
In various utilities, you can distinguish the two groups by noting the type of icon associated with the group. Local groups have an icon with a picture of a computer, symbolizing that the scope of the local group is the computer. Global groups have an icon with a picture of the globe, symbolizing the wider scope of the global group. Figure 21.3 shows several groups of both types.
These icons represent global groups and local groups on the server.
Windows NT has a number of built-in groups. The domain controllers have these built-in local groups:
The domain controllers have these domain (global) groups:
Windows NT workstations and Windows NT servers without domain controller security have these built-in groups:
Some of these built-in groups automatically contain other types of users. Table 21.1 summarizes the automatic contents of the various built-in groups.
| Group | Automatic Contents |
| Administrators | Domain Admins |
| Domain Admins | Administrators |
| Backup Operators | None |
| Server Operators | None |
| Account Operators | None |
| Print Operators | None |
| Power Users | Setup User |
| Users | Domain Users |
| Domain Users | Administrators |
| Guests | Domain Guests, Guest |
| Domain Guests | Guest |
| Replicator | None |
In addition to the built-in groups, a number of groupings of users exist inherently on the Windows NT system. The most important inherent group is Everyone. This group consists of all users (local and network domain users) logged on at a particular time. Anyone who logs on automatically becomes part of the Everyone group. This group is important because it can be used to assign "universal" rights to resources using File Manager. In the following sections, various characteristics of the built-in groups are discussed in some detail.
Administrators. Members of the Administrators group have almost complete access to--as well as authority over--the domain, server, or workstation containing the group. These users can perform almost all administrative functions in the domain. They can create, delete, and manage local groups and global groups, assign user rights, install programs on remote workstations, lock the server, format server disks, and so on. However, administrators do not have complete and automatic access to directories and files on NTFS systems. Unless the owner of a file or directory grants access, even administrators cannot access that item. In this situation, the administrator would have to take over ownership of the resource to gain access to it.
Domain Admins. Every domain includes a global group named Domain Admins, which is automatically added to the local Administrators group. Therefore, all members of Domain Admins are domain administrators. You can assign a user as a domain administrator by adding the user to the Domain Admins group, or simply adding the user to the local Administrators group in the domain.
By adding the Domain Admins group to the Administrators group in other domains, you enable designated users to administer multiple domains with a single account in their home domain.
Backup Operators. This local group is designed to enable users to perform backup functions. Users in the Backup Operators group can back up and restore files (even if they lack read/write permission to the directories they're backing up), log on to the system locally, and shut down the system. Backup Operators don't have the capability to change security settings or perform other administrative tasks; however, they do have authority to shut down the system. There are no default members of the Backup Operators group.
Server Operators. The Server Operators group enables its members to manage servers. This group only exists in a Windows NT server that is acting as a domain controller. Users in this group have much of the same administrative authority as Administrators; for instance, they can log on to the system locally, share and unshare resources, format disks on the server, back up and restore files, and shut down servers. However, Server Operators do not have the authority to administer security on the system.
Account Operators. Users in this group can create and manage user accounts in the domain. They can create and modify user accounts and groups but cannot assign user rights. They also cannot manage user and group accounts created by Administrators. Instead, they can create accounts and assign those accounts to groups that have been set up by an Administrator.
Print Operators. The Print Operators group can log on to servers locally; shut down a server; and share, unshare, and manage printers on a Windows NT server.
Users. The most common group is Users. Members of this group can log on locally to a workstation, member server, or domain, but not to a PDC or BDC.
On a Windows NT workstation, members of the Users group can log on to the workstation, shut down and lock that station, maintain a local profile, and create and delete local groups.
Power Users. Power Users are like Users with some administrative rights. Power Users can create and modify those user accounts that they create. They can add accounts to the Users, Guests, and Power Users groups. They also can share and unshare files and printers at the local station.
Domain Users. All user accounts in a domain automatically become members of the Domain Users group. The Domain Users group is part of the local Users group, which makes all its members users of the domain.
Guests. Members of the Guests group on a domain have rights similar to Users. They can log on through a network client and access domain resources. Like Users, they cannot log on locally to a server (but instead must do so across the network).
NOTE: In Window NT 4.0, unlike the previous version, the Guest account is disabled by default after installation. This is done primarily because the Guest account is seldom used and in most installations goes overlooked.
Domain Guests. The Guest user account typically is included in the Domain Guests group, which is a member of the local Guests group. Members of the Domain Guests and Guests groups enjoy guest privileges in the domain to which they're logged on. To grant guest privileges across multiple domains, include the Domain Guests group in the local Guests groups of other trusting domains.
Replicator. The Replicator group is a special group to facilitate file and directory replication. There are no default members of this group, though the group exists on all servers and workstations.
When you create a user account on a Windows NT network, you'll frequently place that user into one or more of the built-in groups. As a member of a built-in group (or any other group, for that matter), a user "inherits" rights from the group. If a user is a member of more than one group, the user inherits all the rights from all the groups to which the user belongs.
For the remainder of this chapter, it's important to understand the terms permissions and user rights. In the context of Windows NT, rights apply to system-wide objects and tasks, and permissions apply to specific objects such as files and printers. Be careful not to confuse the two terms.
Understanding Permissions. Permissions are the access parameters associated with a resource. In other words, permissions define the rules by which operations can be performed on a particular resource. These permissions can be set as either object permissions or share permissions. In Windows NT, each object can have associated with it its own set of permissions, often called object permissions, which limit local access to the resource. For example, you might set the permissions on a folder so that the Guests group has read-only access to the folder. Anyone in that group who logs on to the workstation locally is restricted to read-only access to that folder.
In addition to local object permissions, you can attach share permissions to resources shared on a computer. These permissions determine the level of access remote users across the network have to the shared resource. For instance, instead of assigning read-only object permission to a folder, you could share the folder and then assign a set of share permissions different from the local object permissions. That way, members of the Guests group could have one set of permissions for the folder when they log on locally to the workstation and a different set of permissions when they access the resource from across the network. There is little difference between object permissions and share permissions except in the way you assign those permissions.
Understanding User Rights. Rights are the customizable powers granted to a built-in group. A right gives group members (or individual users) the authority to perform various actions across the network, such as logging on locally, locking the system, and so on. Here are the specific user rights available on Windows NT:
Assigning User Rights. You can administer user's rights easily by placing the user in a group whose rights you've already assigned. You also can assign rights to an individual account. In this section, we explore the User Rights feature, which is found in User Manager. A more in-depth discussion of User Manager is in the next section.
To assign rights, open User Manager and choose Policies, User Rights to display the User Rights Policy dialog box shown in Figure 21.4.
The User Rights Policy box is where you assign users' rights in groups.
From the Right drop-down list, select the right you want to assign. Then, if the group you want is not already listed in the Grant To list, click Add to display the Add Users and Groups dialog box shown in Figure 21.5.
Here you can assign the right to various groups and users.
If you only want to assign the selected right to various groups, select the groups from the Names list; then choose Add. To add the right to a particular user, click Show Users to cause User Manager to display individual accounts as well as groups in the Names list. Select the name(s) from the list; then click Add. When you're finished with the changes you want to make, choose OK.
Now that you understand the concepts behind groups and accounts, you can begin creating user accounts and groups. User Manager is the tool you use to create and modify user accounts.
The Windows NT User Manager interface helps you create user accounts and groups, assign users to groups, set access permissions for groups and individual users, create trust relationships, define account policies, and perform other administrative tasks.
To start User Manager, choose Start, Programs, Administrative Tools, User Manager. Figure 21.6 shows the User Manager program window.
With the Windows NT User Manager, you can create and administer user accounts.
NOTE: If you are using a domain controller, User Manager for Domains performs the same functions as User Manager and is almost identical except for the addition of a few special features that help you work with domain-wide accounts.
User Manager for Domains enables you to work with user accounts on a domain controller as well as accounts on individual workstations and members servers (servers that do not function as PDCs or BDCs). You can install User Manager for Domains on any Windows NT workstation or Windows 95 computer. In Windows 95, you must install the Server Tools to have this functionality. This enables you to administer user accounts on other computers besides your own.
With User Manager, you can perform the following functions:
TIP: You can sort the view in User Manager to display names according to their account names (the default) or long names. To switch between these two view methods, choose View, Sort by Full Name or View, Sort by Username.
To work with the database of users for a domain other than your current domain, choose User, Select Domain. From the Select Domain dialog box, choose the domain you want to administer; then click OK. The Select Users and Select Domain commands are available only with User Manager for Domains.
When you create an account, you first specify general information such as the username and password and also apply permissions and set other logon restrictions. In the sections that follow, we examine the steps for creating a user account.
NOTE: These sections explain how to create a new account. To modify an existing account, just select the account you want to modify by double-clicking the account in User Manager; then use the techniques explained in the following sections to set account properties.
Specifying General Account Information. To begin creating a new user account, choose User, New User to display the New User dialog box shown in Figure 21.7. In the Username text box, type the name for the new account. This is the name by which the user will log on to the computer or domain.
Begin by setting out the basic information: username and password.
The username is for the convenience of the user only. Internally, the system uses an identifier called the SID (Security Identifier) for the user account. Changing the username does not change the SID; it only changes the username property of the account.
Creating Consistent Usernames
In choosing usernames, be consistent; do not use user A's first name, user B's first initial and last name, and so on. Although you're free to use whatever convention makes sense for your organization, here are some common methods for user names, along with examples for a hypothetical user named Kevin Dean Pagan:
- First name only (Kevin)--not a good idea for large organizations
- Last name only (Pagan)
- First name and last initial (KevinP)
- Initials only (KDP)
- First initial and last name (KPagan)
Alternatively, you might decide to use an otherwise meaningless coding system for security or to protect the confidentiality of your users.
Next, type the user's full name in the Full Name text box. If you want, type an optional description, such as the user's department or job title, in the Description text box. Click the Password text box and type the password you want to assign to the account; then click the Confirm Password text box and type the password again. (This is the password the user will provide with his account name when he first logs on.)
Notice that four check boxes on the New User dialog box control general account properties:
Setting Group Membership. In addition to specifying general information, you need to specify the groups to which a user belongs. Click the Groups button to display the Group Memberships dialog box shown in Figure 21.8.
Depending on the type of environment in which you're creating the account (domain or not), User Manager automatically adds the account to the Users or Domain Users group. Other groups to which you can add the user appear in the Not Member Of list. To add the user to other groups, select the desired group(s) and click Add. To remove membership for a certain group, select that group from the Member Of list; then click Remove.
Use this dialog box to specify group memberships.
You can specify the group to be assigned as the primary group. The primary group association only affects users who log on using Windows NT Services for Macintosh or who run POSIX programs. To specify the primary group, select a group in the Member Of list; then click Set. When you're satisfied with the group membership assignments for the account, click OK.
Choosing a Profile. The next step in creating an account is to specify a user profile, home directory, and logon script. To do so, click the Profile button to display the User Environment Profile dialog box shown in Figure 21.9.
Use this dialog box to specify home directory, logon script, and profile.
A profile is a special file Windows NT uses to save user settings such as desktop configuration and schemes, colors, and so on. (Each computer maintains a default user profile. If a user logs on and no profile is specified, the default profile is used. This profile then becomes the user's profile.)
TIP: To support a user who logs on from various sites, store the profile on a network server that will be available to the user each time he logs on. This provides the user with the same custom interface settings each time he logs on, regardless of which computer he uses.
To specify a user profile for the account, type the path to the profile file in the User Profile Path text box. For example, you might specify \\server\profiles\acct, which defines the path to the file in UNC format.
If you're working with multiple accounts, you can use an environment variable in place of the user's name. For example, assume that you're working with six different accounts, so you can't specify a single file for the profile. Instead, you enter something similar to \\server\profiles\%username%. User Manager replaces the variable %username% with each user's name to create or read the appropriate profile. (You examine profiles in the later section "Managing User Profiles.")
In the Logon Script Name text box, enter the path to the logon script file for the account. You can specify the name of a batch (BAT) file, command (CMD) file, or executable (EXE) file. Typically, logon scripts are stored in the \systemroot\System32\Repl\Import\Scripts directory.
In the Home Directory section of the User Environment Profile dialog box, you specify the location of the user's home directory. This is the directory Windows NT will make active when the user logs on. In most cases, the user's home directory is the directory in which he stores his personal files and may be the user's workstation. However, you can specify a home directory on the user's local computer or on a server. To specify a local directory, choose the Local Path option button; then type the local disk and directory in the associated text box, such as C:\Users\Kevp.
TIP: If a user logs on from the same computer all or most of the time, you normally should use a local home directory on the user's computer to save network traffic and server disk space, as well as speed up access to the user's files. Users who often log on from various sites should have a home directory on a server so their home directory "follows" them and is always available.
To specify a shared network directory as the user's home directory, select the Connect option button. Then select a drive letter from the associated drop-down list. In the To text box, type the UNC path to the shared directory, such as \\Server\Users\Fredf.
TIP: If you're working with multiple user accounts, you can use the %username% environment variable in the home directory path. User Manager will replace the user's name with the environment variable.
Setting Logon Hours. To specify (or limit) the hours a user can log on to and use the system, click the Hours button in the New User dialog box to display the Logon Hours dialog box shown in Figure 21.10. For example, you might want to limit logons after "normal" business hours for users who normally have no need to log on late at night. As a general security precaution, it's a good idea to limit the use of the server at night. This prevents users from exploring at night when they might feel more adventuresome.
The default enables the user to log on at any time, day or night, on any day of the week. To disallow logon during a specific period, select the period of time to disallow in the desired day(s); then click Disallow. To disallow the same hour on every day, click the gray bar at the top of the hour column to select that hour for the entire week; then click Disallow.
The Logon Hours dialog box is where you control users' hours of access to the system.
NOTE: Disallowing logon applies only to server logon--it does not affect the user's ability to log on to a workstation locally. You might, for example, disallow logon to a server during a specific period every week to run backups on the server. The capability to set logon hours is available only through User Manager for Domains.
Setting Logon Restrictions. In addition to controlling when a user can log on, you also can specify from where the user can log on to a domain. This allows you to restrict which computers a user can use to access the domain. This option helps to prevent users with greater system access from logging on to the network in a less secure area and perhaps walking away from the workstation, thus enabling unauthorized access. To control logon, click the Logon To button in the New User dialog box to display the Logon Workstations dialog box shown in Figure 21.11.
This dialog box enables you to control the computers from which the user can log on to the system.
If you want to allow the user to log on to the domain from any computer, select the User May Log On to All Workstations option button. To restrict access to specific workstations, select the User May Log On to These Workstations option button and then enter up to eight workstation names in the text boxes.
Setting Account Type and Expiration. Most accounts in a domain are global, but you can create a local account, as discussed earlier in the "Understanding Groups" section. To specify the account type and expiration, click the Account button in the New User dialog box to display the Account Information dialog box shown in Figure 21.12.
Specify the account type and expiration.
You might want to cause an account to expire for a variety of reasons. For example, the user might be a temporary employee, or might only need the account during a specific project such as annual budgeting.
To specify that the account should expire, choose the End Of option button; then set the date on which you want the account to expire. The account will expire on midnight of that date. If you want the account to never expire, select the Never option button. (Never Expire is the default.)
You also use the Account Information dialog box to specify the type of account. Select either the Global Account or Local Account option button, depending on your requirements. In a domain, most accounts are global.
In addition to creating and modifying user accounts with User Manager, you can create and manage groups. After you create a group, you can add any user accounts you've created to the group. The following sections explain how to create local and global groups.
Creating a Local Group. To create a local group, choose User, New Local Group to display the New Local Group dialog box. In the Group Name text box, type the name you want to give the new group. You can use any combination of uppercase and lowercase letters but not the following characters:
In the Description text box, type an optional description for the group.
Next, you can begin assigning users to the group, or you can leave that task for later. To do it later, just click OK. To add users now, click Add to display the Add Users and Groups dialog box.
From the Names list, select all the groups and users you want to add to the new group; then choose Add. If you want to view the members of a listed group, select the group and choose the Members button. To delete a user or group from the group, click in the Add Names text box, highlight the name(s) to be deleted, and then press Delete. To search for a name or group locally or in a specific domain, click Search.
Creating a Global Group. Creating a global group is similar to creating a local group. In User Manager, choose User, New Global Group to display the New Global Group dialog box shown in Figure 21.13. As when creating a local group, type the group name in the Group Name box and an optional description in the Description box.
In this dialog box, enter information pertaining to the New Global Group.
To add users to the group, select their names from the Not Members list and click Add. To remove users from the group, select their names from the Members list and click Remove.
If you use network workstations in a variety of locations in your organization, you can easily understand the importance of maintaining a consistent "look and feel" of your interface with the network. More important perhaps than the look of the interface is knowing that you have consistent access rights and permissions if you log on to the network from another station.
Windows NT's user profiles enable a user's desktop settings and other interface and operating parameters (or operating environment) to be retained from session to session and from station to station. If the user profile is stored on a server on the domain, the user can have the same interface and settings regardless of which computer he uses to log onto the domain. In addition, profiles enable you to control the types of changes a user can make to his working environment. The following section provides an overview of profiles. A user's operating environment has several aspects, including:
User profiles are generally similar to logon scripts used by other platforms, such as Novell's NetWare, UNIX, and so on. However, profiles are also designed to take full advantage of the Microsoft GUI; accordingly, they deal with program groups, screen colors, sound schemes, and so on, in addition to the more traditional network settings.
NOTE: Windows NT profiles are only useful on Windows NT clients such as Windows NT Workstation. They aren't used on DOS, Windows 3.1x, or Windows for Workgroups workstations. They can, however, be used on Windows 95 workstations, as long as they're appropriately enabled.
A profile is a group of settings stored in a special type of Registry file that works in conjunction with a set of folders and shortcuts to re-create the user's working environment. When a user logs on, Windows NT reads the user's profile from the Registry file and sets up the Windows NT desktop according to the settings in the profile.
The first type of profile you can assign to a user is called a personal profile. The personal profile can be changed by the user from one logon session to another, subject to certain restrictions in the profile itself. This type of profile enables a user to make changes to his profile and retain those changes for future logon sessions.
The second type of profile is called a mandatory profile. A mandatory profile is almost identical to a personal profile, except that changes don't carry from one session to another. Although a user has some limited ability to change settings in a mandatory profile, those changes are not stored permanently in the user's profile. The profile changes are discarded at the end of the session, and the profile reverts to its original state for the next logon session.
TIP: Mandatory profiles can be useful in that they enable the administrator to create (and restrict) the user's ability to use certain resources or applications on a system. The administrator can update a mandatory user profile for several users at the same time (similar to working with a group)--for example, adding access to a new application to those users' profiles.
If a user has no profile, Windows NT uses a default profile from the user's logon workstation. The default profile is then, in effect, copied and saved as the user's personal profile for future logon sessions.
There are several instances when a user might log on and have no specific user profile--for instance, the first time a user logs on, or when no profile has been assigned. Also, a user may log on in the Guest account, or a user may log on and for some reason the user's profile may be unavailable.
Profiles are created and modified using User Manager for Domains. User profiles are created automatically when users are created. Profiles are then modified as needed by using User Manager for Domains to make appropriate changes to the profile for a particular user.
TIP: When you modify a user profile, you change the profile of the account you used to log on. For example, if you're the administrator and you use Kevin to log on and then edit the profile, the changes affect the Kevin account. Therefore, you should create a special administrator account to use just for creating other user's profiles. This account can then be used for profile editing without affecting your own personal account.
The basic steps for creating a new user were discussed earlier in this chapter in the section "Creating the User Account" and are listed again for ease of reference, this time emphasizing profile creation:
2. Create the desktop look you want for the user with whom you're working.
3. Start User Manager for Domains.
4. Select New User to access the New User dialog box (see Figure 21.14).
In this dialog box, enter information on the new user you're creating.
6. Click the Profile button to access the User Environment Profile dialog box (see Figure 21.15).
In this dialog box, enter information pertaining to the user profile environment.
8. Click OK to accept the changes; then click Add to add the user (with the profile) to your system's users.
Once created, profiles consist of a Registry file named NTuser.dat, which is a cached copy of the Windows NT Registry subtree HKEY_CURRENT_USER and a user-specific directory structure containing various shortcuts. NTuser.dat contains settings that define the computer's hardware, installed software, and environment settings. The directory structure and associated shortcuts define the user's desktop environment and application environment.
Local user profiles are stored in a folder matching the user's name within the Profiles folder. The Profiles folder typically resides under the system root, such as \WINNT\PROFILES. The profile for a user named billk, for example, would be stored in the folder \WINNT\PROFILES\BILLK.
Typically, the profiles folder contains subfolders such as:
Depending on a particular user's (or the default) profile, other folders can be used in addition to those listed, and users without some of these items in their profile may not have all these folders.
When a user logs on, Windows NT attempts to locate a user profile for the user's account by first determining whether or not the account contains a user profile path. If there's a path and the path is available and the user's profile exists on the path, Windows NT opens and uses the profile. If no profile exists on the path or no path is specified, Windows NT creates a profile folder on the local computer for the user. Windows NT then copies the contents of the Default User profile folder to the user's profile folder.
In addition, the contents of the All Users folder are used to define the user's desktop. When the user logs off, any changes he has made to his working environment are stored in his new profile folder and profile Registry file. (If the user makes no changes, the user's profile is still created as a personal profile--it's simply identical to the default profile.)
A roaming user is one who logs on to the network from more than one computer. For consistency, these users should use the same profile regardless of the logon location, giving them a consistent desktop and user settings from one session and station to the next. To ensure that consistency, these users should use a roaming user profile.
There's little difference between a local profile and a roaming user profile except for where the profile is stored and how it's accessed. You can implement a roaming profile in any of three ways:
NOTE: You cannot copy a profile using Explorer or another file management utility; you must use the System object in Control Panel to copy the profile. This procedure is discussed in the following section.
Each method relies on the profile path to specify the location of the user's profile. This path must reside on a server to which the user will have access regardless of his logon location; otherwise, the user won't be able to roam.
You might need to copy profiles from one location to another from time to time. For example, you might need to copy a profile to a user's profile path on a network server so that profile will be applied the next time the user logs on. As mentioned previously in this chapter, you can't copy a profile simply by using Explorer or another file management utility. You must use the System object in Control Panel:
2. Click the User Profiles tab (see Figure 21.16).
Use the User Profiles tab to copy profiles from one location to another.
4. Click Copy To to display the Copy To dialog box.
5. In the text box, type the path to the folder in which you want to copy the profile, or click Browse to browse for the folder.
6. Click OK when you're satisfied with the folder location.
With Windows NT 3.5x, user profiles were stored as a single file with either a usr file extension (personal profile) or man file extension (mandatory profile). Installing Windows NT 4.0 causes 3.5x local personal profiles to be converted from a single file to a folder containing the user profile and directory structure with shortcuts. Roaming profiles are treated differently, however.
Windows NT retains the 3.5x profile in its original location and creates a new user profile that incorporates the old profile in the new Windows NT 4.0 format. This means that both profiles are available. If the user logs on from a Windows NT 3.5x workstation, the old profile is used. If he logs on from a Windows NT 4.0 workstation, the new profile is used. Only one profile at a time is updated, so changes that the user makes when logged on under the old profile are not incorporated into the new profile, and vice versa.
When Windows NT creates the 4.0 roaming profile from the 3.5x profile, the old user profile is incorporated into the NTuser.dat file. Other settings in the old profile are used to create a directory structure with the same name as the profile file but with a pds extension. If the user name is Janet, for example, the directory structure for the 4.0 profile is created under the folder janet.pds.
Although the profile file names change, you don't have to make any changes to a user's account to specify the new profile path. During logon, Windows NT 4.0 recognizes when a 3.5x user profile is specified for an account and automatically looks for the appropriate 4.0 profile. If the user's account specifies the path \\server\profiles\fredz.usr, Windows NT automatically looks for \\server\profiles\fredz.pds. If the user's account specifies a mandatory 3.5x profile, Windows NT performs a similar name translation to open the correct 4.0 profile.
Although Windows NT automatically looks for a new mandatory profile if a 3.5x profile is specified in the user's account, it does not automatically upgrade mandatory profiles to 4.0 format. Instead, you must manually update the profiles by using the following steps:
2. Log off; then log back on as administrator.
3. Open the System icon in Control Panel and click the User Profile tab.
4. Copy the user profile to the user's profile path, giving it a name that matches the 3.5x user profile name but using the .pds file extension.
5. Open the user's new profile folder and rename the Registry file NTuser.dat to Ntuser.man.
Because upgrading mandatory profiles manually can be particularly time-consuming, consider using system policies as an alternative to mandatory profiles.
TIP: Because Windows NT 4.0 does not include the User Profile Editor included with previous versions, you might want to use system policies in place of all user profiles. The System Policy Editor included with Windows NT 4.0 enables you to define the same types of settings as previously available under the User Profile Editor, along with many others.
Logon scripts, as noted in the discussion on user profiles, are essentially a holdover from earlier (and non-Microsoft) operating systems. Although logon scripts are beyond the scope of this book, consider using them in the following situations:
© Copyright, Macmillan Computer Publishing. All rights reserved.