Document revision date: 30 March 2001

In addition to one primary domain controller and one or more backup domain controllers, the domain can contain one or more member servers. Advanced Server, Windows NT Server, and LAN Manager V2.x servers can function as member servers. (Support of member server functionality begins with V7.3 of the Advanced Server for OpenVMS.)

A domain can have several member servers, or none. A member server differs from a domain controller in the following ways:

• The member server does not store copies of the domain's security accounts database.
• The member server does not validate domain logon requests.

Member servers rely on domain controllers to validate credentials of users requesting access to member server shares. When a domain user attempts to access data on a member server's shares, the user's workstation sends user name and password information to the member server. The member server then relays this information to a domain controller to authenticate the user. The domain controller can authenticate domain user requests to member server resources.

You may want to configure your Advanced Server as a member server instead of a backup domain controller (or primary domain controller) for any of the following reasons:

• Member servers do not spend time processing logon requests. Thus, this role can be a good choice for servers that have heavy workloads or that perform extremely time-critical tasks.
• More important, configuring one or more servers as member servers rather than domain controllers can help decrease the network load, eliminating network traffic normally generated by domain controllers for replicating user databases and authenticating logon requests. (When a client attempts to find a logon server to authenticate a request, all domain controllers respond to the request. In some environments, this can generate a significant load on the network.)
• As a member server, the Advanced Server can participate in a native-mode Windows 2000 environment (also referred to as a pure Windows 2000 environment, this is a domain in which all domain controllers are Windows 2000 systems).
  In a native-mode Windows 2000 domain environment, domain controllers participate in a "multi-master domain controller model," meaning that changes to the security accounts database can be made on any domain controller. Any domain controller can be the replicator, sending copies of the updated security accounts database to the other domain controllers.
  This model contrasts to the primary/backup domain controller model used by Windows NT Servers and Advanced Server for OpenVMS servers configured as PDCs and BDCs. In the PDC/BDC model, changes to the security accounts database must be made on the primary domain controller first, which then replicates the database to the backup domain controllers.
  Configuring the Advanced Server as a member server, network administrators can include the Advanced Server for OpenVMS in a native-mode Windows 2000 domain, and the Windows 2000 domain controllers can continue using the multi-master model uninterrupted.
  The Advanced Server can also participate as a backup domain controller or member server in a mixed-mode Windows 2000 domain.
• You can set up different administrator or user accounts from the rest of the servers in a domain. For example, you may have a person dedicated to administering a particular type of database. If you make the Advanced Server a member server, then you can make that person an administrator on the server with the special database. This way, he or she can manage that server but not have any control over the domain's master user accounts database or its other servers.
• If there is a possibility that your Advanced Server may be moved to a different domain in the future, it is simpler to move a member server from one domain to another than to move a BDC from one domain to another.

PATHWORKS for OpenVMS (LAN Manager) and LAN Manager V2.x servers can coexist in a domain with the Advanced Server. A LAN Manager server cannot be the primary domain controller in such a domain, however, because LAN Manager V2.x does not support all the types of information contained in Advanced Server accounts.

Under some circumstances, you may need to maintain LAN Manager servers. For example, you may need to have a PATHWORKS V5 for OpenVMS server to provide Remote Boot Services, which are not supported by Advanced Server. You can incorporate LAN Manager servers into your network as backup domain controllers, member servers, or standalone servers in an Advanced Server domain.

Adding a LAN Manager server to an Advanced Server domain presents a few challenges because of the following differences in server capabilities:

• The LAN Manager server receives a copy of the domain's user and group database, but the LAN Manager server does not recognize local groups. Therefore, you cannot assign permissions for resources on LAN Manager servers based on the domain's local groups.
• LAN Manager servers are limited to 256 groups, but there is no limit to the number of groups that can exist in an Advanced Server domain. If the number of groups in a domain containing a LAN Manager server exceeds 256, the replication process can break down, affecting the databases on LAN Manager servers.
• LAN Manager servers do not recognize trust relationships. Therefore, if the domain containing LAN Manager servers trusts other domains, you cannot assign permissions on the LAN Manager servers to users and global groups from the trusted domain.
• Domains composed entirely of LAN Manager servers cannot have trust relationships with other domains and therefore cannot allow users and global groups defined on other domains to access its resources. If a workstation user in an Advanced Server domain needs to access a resource in a LAN Manager domain, that user must also have an account in the LAN Manager domain, or that domain must allow guest logon.

If it is a backup domain controller or member server, a LAN Manager server stores a copy of the domain's security database. A LAN Manager server running as a backup domain controller can validate logon attempts from computers running Windows for Workgroups or LAN Manager software. A LAN Manager standalone server does not receive a copy of the domain accounts database, and neither standalone nor member servers can validate client domain logon requests.

A Windows NT Server can be part of the same domain as an Advanced Server and can be designated as the primary domain controller.

For more information about the differences between Windows NT Server and the Advanced Server, see Appendix A, Differences Between Advanced Server and Windows NT Server, in this guide.

2.5.6 Advanced Server for UNIX (Tru64 UNIX) Servers

An Advanced Server for UNIX (Tru64 UNIX) server can be part of the same domain as an Advanced Server for OpenVMS server and can be designated as the primary domain controller. For Advanced Server for UNIX (Tru64 UNIX) servers, you have the following options:

• You can remotely manage the Advanced Server for UNIX (Tru64 UNIX).
• From an Advanced Server for UNIX (Tru64 UNIX), you can remotely manage the OpenVMS Advanced Server.

For more information about the Advanced Server for UNIX (Tru64 UNIX) product, see the Advanced Server for UNIX (Tru64 UNIX) documentation set.

2.6 Workstation Environments

On an Advanced Server network, you can use user profiles to define and enhance workstation environments. A user profile contains the per-user settings of the Windows NT environment, including the following:

• Logon script specification
  A logon script can be a batch file containing Advanced Server and operating system commands, such as commands to make network connections or start application or executable programs. If a user has a logon script, that script is run whenever the user logs on at any type of workstation on the network.
  For more information about logon scripts, see Section 2.6.1, Tips for Using Logon Scripts, in this guide.
• Home directory location
  A home directory gives a user storage space. Normally, users also control access to their home directories and can restrict or grant access to other users.
  For more information about home directories, see Section 2.6.2, Tips for Using Home Directories , in this guide.

You manage user environments by editing the user profile. However, user profiles are applicable only at Windows NT workstation computers and have no effect on other types of client workstations.

2.6.1 Tips for Using Logon Scripts

A logon script is an executable or batch file composed of Advanced Server and operating system commands that runs automatically when a user logs on to the network. Logon scripts are used to configure users' work environments, make network connections, and start applications. They also can be used to run programs that scan for computer viruses on local workstations.

Advantages to using logon scripts include:

• You can manage part of the user's environment (such as network connections) without managing or dictating the entire environment.
• You can create common network connections for multiple users.
• Logon scripts are centrally located on the server and are easy to create and maintain.
• If you have a LAN Manager server running on your network, you can continue to use the logon scripts that you created for that system.

To assign a user a logon script, specify the path name of the logon script file in the user's account profile. Then, when the user logs on, the logon script downloads and runs. You can assign a different logon script to each user or create logon scripts for use by multiple users. For more information on user profiles, see Chapter 3, User Accounts.

The path name that you specify in the user's account profile is relative to the logon script path of the computer on which the script is stored. For example, if PWRK$LMROOT:[LANMAN.REPL.IMPORT.SCRIPTS] is the computer logon script path and PWRK$LMROOT:[LANMAN.REPL.IMPORT.SCRIPTS]cristalw.bat is the script for CristalW, then you need to specify only cristalw.bat as the logon script path name in CristalW's account profile.

To create a logon script, simply create an MS-DOS batch file. Table 2-1 describes several special parameters that you can use when creating logon scripts. Although a logon script works from any client, these parameters apply only when the user logs on from a Windows NT client.

Table 2-1 Parameters for Logon Scripts

Parameter	Description
%HOMEDRIVE%	The letter for the local workstation drive connected to the user's home directory.
%HOMEPATH%	The full path name of the user's home directory. This parameter applies only when the home directory is a local directory (absolute path) on the workstation.
%HOMESHARE%	The share name containing the user's home directory. This parameter applies only when the home directory is a shared network directory (UNC path).
%OS%	The operating system of the user's workstation.
%PROCESSOR_ARCHITECTURE%	The processor type (such as 80386) of the user's workstation.
%PROCESSOR_IDENTIFIER%	The processor model (such as Model 3, Intel) of the user's workstation.
%PROCESSOR_LEVEL%	The processor level (such as 6) of the user's workstation.
%PROCESSOR_REVISION%	The processor revision (such as 0304) of the user's workstation.
%USERDOMAIN%	The name of the domain containing the user's account.
%USERNAME%	The user's user name.

A logon script always downloads from the server that validates the user's logon request. To ensure that logon scripts always work, be sure that logon scripts for all user accounts in a domain exist on every server in the domain that validates logon requests.

2.6.2 Tips for Using Home Directories

Home directories can serve as private storage spaces for users. Users can control access to their home directories and can restrict or grant access to other users.

The home directory can be a local path on the server or a remote path located on another server on the network. If users have home directories on computers other than their own workstations, connections are made automatically to their home directories at every logon from a Windows NT workstation computer.

Whenever a user starts from the command prompt on a Windows NT workstation computer, the user's home directory is set as the default directory. The user's home directory also is set as the working directory for all applications that the user starts, except when those applications have a program item that specifies a different working directory. Note that the home directory takes effect only for users starting from a Windows NT workstation. When a user logs on from a non-Windows NT client, the usual default directory takes effect.

For information on file and directory permissions, see Chapter 6, Managing Network Shares, in this guide.

2.6.3 Windows NT and Windows 2000 Workstation Computers

Each Windows NT and Windows 2000 workstation computer on your network can participate in either a domain or a workgroup.

A Windows NT or Windows 2000 workstation computer participating in a workgroup has its own database of users, processes logon requests by itself, uses only its own users and groups, and is separate from all domains. Computers in a workgroup do not share account information. On this type of workstation, only the user accounts that were created at the workstation can be logged on to or given rights and permissions at the workstation.

Users can log on to an Advanced Server domain from a Windows NT or Windows 2000 workstation only if that workstation is part of the domain or of a trusted domain. A Windows NT or Windows 2000 workstation computer that participates in a domain does not get a copy of the domain's user database, but it does receive the benefits of the domain's user and group database. It can use user accounts and global groups from that domain, and the domains it trusts, to provide access to resources on the workstation.

At a Windows NT or Windows 2000 workstation computer participating in a domain, users can log on to user accounts located in the workstation domain (or in any domain the workstation domain trusts). For example, suppose a workstation is participating in the Sales domain, and Sales trusts the MIS domain. At the workstation, a user can log on to an account located in either the Sales domain or the MIS domain. You can place users and global groups from the domain (and domains trusted by the workstation domain) in local groups on the workstation, and you can assign permissions and rights on the workstation to users and global groups from the domain (and domains trusted by the workstation domain).

Even though a workstation participating in a domain can use accounts located in that domain, user accounts still can be created at the workstation itself. These accounts are local to that workstation and cannot be used on any other computer.

You should not create a local workstation account for a user who has a domain account. Instead, a user with a domain account always should log on to that account.

Windows for Workgroups computers generally are organized into workgroups. Workgroups are similar to domains in network browsing: When a user uses File Manager to browse the network, the user sees the network divided into domains and workgroups. If the user selects a domain or workgroup, then the user can browse the contents of that domain or workgroup.

Every Windows for Workgroups computer on your network can participate in a domain or in a workgroup. In most cases, you will want Windows for Workgroups computers to participate in a domain so that they can be integrated into the Advanced Server administrative models.

Windows for Workgroups computers can participate in workgroups containing Windows NT workstations. Similarly, on a Windows for Workgroups computer, you can specify the name of an Advanced Server domain as the computer's workgroup and the Windows for Workgroups computer can then function as a computer contained in the domain.

If a Windows for Workgroups user must access a resource in a domain that has no Windows for Workgroups computers, the user must know the name of the computer on which the resource is located. Whenever a Windows for Workgroups computer starts, the user can log on to the network using a user name and password previously specified at the computer. Alternatively, the user can wait to log on to the network until making an initial network access attempt.

If a Windows for Workgroups user has an account in an Advanced Server domain, you can specify the user name and password of that account to Windows for Workgroups and set the workgroup name on the computer to be the name of the domain. Then, users can log on to their domain accounts automatically when they log on to the network.

2.6.5 Windows 95 and Windows 98 Computers

You can choose whether you want the Windows 95 and Windows 98 computers on your network to participate in a workgroup or in a domain. In most cases, you will want them to participate in a domain, because a user with an account on an Advanced Server domain can log on to that account from a Windows 95 or Windows 98 computer only if that computer is part of the domain.

Windows 95 and Windows 98 computers that participate in a domain do not get a copy of the domain's user database, but they do receive the benefits of the domain's user and group databases.

You can configure a Windows 95 or Windows 98 computer to prevent users from logging on to the local workstation after an unsuccessful attempt to log on to the domain. This prevents users from gaining access to resources local to the Windows 95 or Windows 98 workstation if, for example, their domain user accounts have expired or have been disabled.

A Windows 95 or Windows 98 computer that participates in a workgroup has its own database of users and can process logon requests. However, computers in a workgroup do not share account information. This means that you can assign rights and enable users to log on only to accounts that are created on the Windows 95 or Windows 98 computer.

Windows 95 and Windows 98 computers that participate in a workgroup can control access to resources by running share-level security. Under share-level security, each shared resource on a local workstation is protected by a unique password. Users from remote computers can access the resource only if they enter the correct password.

2.6.6 Windows, MS-DOS, and OS/2 Computers

Windows V3.x, MS-DOS, and OS/2 computers cannot store user accounts. This makes them unable to participate in domains in the same way as Windows NT, Windows 95, Windows 98, Windows 2000, or Windows for Workgroups computers. However, with valid network logon, they can access resources on servers.

Windows, MS-DOS, and OS/2 computers usually have a default domain set for network viewing. If a user has a domain account, the domain into which the user logs on is always viewed. You can add other domains to the viewing list.

	privacy and legal statement
6553PRO_002.HTML