Chapter 5 - Network Services: Enterprise Level

Article
02/20/2014

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The following chapter is a tested but largely unedited draft of material that will appear in expanded form in the next update of the Windows NT Server Resource Kit*. At that time, the case study will be further revised and expanded to include details about the Divisional, Department, and Desktop server services and other helpful information*.

Chapter 4 introduced Terra Flora, a hypothetical case study of a fictitious company and of the challenges that company faces in bringing together its diverse, previously independent networks. The purpose of the case study is to show in real-world terms how network administrators and information officers can utilize Windows NT to integrate new and legacy hardware and software in a cost-effective way. The chapter further analyzed the Terra Flora case and developed a plan for interoperability. The next step for Terra Flora is to make choices about the Windows NT Server services and to configure those services.

Services will ultimately be configured on four defined levels of usage, depending on the scope of those services within the organization. These levels are, in order of increasingly narrow scope: Enterprise, Division, Department (or Branch Office), and Desktop. This chapter will deal with server services, but only on the Enterprise level. Detailed discussions of service configurations for the other three levels are not included in this edition of the Microsoft Windows NT 4.0 Networking Guide.

Enterprise-level server services are the those provided on a large scale to the entire network. These services primarily support the network itself; they are services that support other servers and keep the corporation-wide information synchronized on all areas of the network. These services include the following:

Dynamic Host Configuration Protocol (DHCP)
Windows Internet Name Service (WINS)
Domain Name System (DNS)
Network Logon Services
Centralized Services
Replication
Backup
Point-to-Point Tunneling Protocol

This chapter will make repeated references to the Terra Flora Network Diagram, printed on the inside back cover of this book. For convenience, open the diagram now so that you can easily refer to it as you read these discussions.

Terra Flora is a totally fictitious company whose business operations and networking environment are being examined and used to demonstrate the functionality of Windows NT Server products throughout this Interoperability section. The names of companies, products, people, characters, and data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted.

Preparations for Configuring Services

Before configuring services, Terra Flora needed to set up the hardware for these services and to adopt the protocols that the networks would use to communicate among themselves and with the Internet. The new protocols must then be installed and configured.

Selecting Protocol Standards

The first decision Terra Flora needs to make is which protocol to adopt as the protocol-of-choice for their network, which protocols to retain, and which to abandon.

Terra Flora's Choice of Protocols

Terra Flora elected to use Transmission Control Protocol/Internet Protocol (TCP/IP) as their network protocol of choice, while retaining Systems Network Architecture (SNA) protocols for connection to the legacy systems.

Why Terra Flora Chose TCP/IP as a Primary Standard

TCP/IP is a standard set of networking protocols that govern how data passes between the networked computers. With TCP/IP, Terra Flora networks will interoperate by using the Windows NT Workstation and Windows NT Server platforms with devices that use Microsoft Windows 95, other Microsoft networking products, and non-Microsoft operating systems, such as UNIX.

Many reasons supported the Terra Flora decision to use TCP/IP as the preferred network protocol.

TCP/IP is the primary protocol of the Internet and the World Wide Web. One of the primary goals of Terra Flora is to establish a presence on the Internet, allowing customers, nurseries, retail stores, and manufacturing sites to place orders directly. Terra Flora sees this as essential to keeping Terra Flora competitive.

TCP/IP is a very clean and efficient suite of standard protocols that can be used on both local and wide-area networks (WANs) to provide communications between all the basic operating systems on the network.

TCP/IP has the advantage of already being in place in parts of the Terra Flora network. TCP/IP currently supports communications between all UNIX-based systems and the AS/400 at Terra Flora, and is running on the following equipment.

Computers running Windows NT Workstation and Windows NT Server
Computers running Windows for Workgroups
Computers running Windows 95
Computers running LAN Manager

For a detailed discussion on TCP/IP see Chapter 6, "TCP/IP Implementation Details."

Why Terra Flora Chose SNA as a Secondary Standard

SNA Protocol enables communication between the department and divisions servers and the enterprise mainframe and AS/400 legacy application services. In the near future, SNA will remain, but Terra Flora plans to review the options of moving all the SNA dependent services to TCP/IP in a cost effective manner. If this is not an option, SNA will remain on the network as the protocol to access the legacy applications.

Why Terra Flora Rejected Other Protocol Options

Three other protocols are currently in place in various parts of the Terra Flora networks. The decisions to abandon these protocols as network standards were based on the reasons given in each case, as described below.

IPX/SPX

In the past, Terra Flora used the IPX/SPX protocol only in the Nursery Products division, to support NetWare services. IPX is easy to install and is dynamic in that it requires no configuration changes for either mobile or relocated network nodes.

Despite these advantages, the expense and performance degradation anticipated under this protocol for such a large and diverse network deterred Terra Flora from establishing IPX/SPX as a protocol standard. The protocol's reliance on network-wide broadcasts make overhead unreasonably high for effective WAN implementations.

IPX/SPX protocol depends on broadcasts of Service Advertising Protocol (SAP) and Routing Information Protocol (RIP) packets for network name-resolution services built into NetWare. SAP and RIP broadcasts are updated every sixty seconds by each server and sent to the entire network. These ongoing broadcasts are negligible within a local LAN environment. However, when IPX networks are connected in an enterprise manner, SAP and RIP broadcasts can dramatically erode the available bandwidth.

For the immediate future, Terra Flora will continue to use IPX/SPX for interchange of files between NetWare and other networking clients. Within the next year, Terra Flora aims to replace all hardware that depends on the IPX/SPX protocol with hardware that utilizes TCP/IP, and to phase out the IPX/SPX protocol.

AppleTalk

AppleTalk is a Macintosh-based protocol that runs primarily in peer-to-peer situations and has very limited support on other platforms.

At Terra Flora, AppleTalk has been used locally in the Retail Services division for graphics-art communications between Macintosh computers, which store the graphic software. Due to the small number of machines, the Macintosh computers were hooked together to form a peer-to-peer network.

Under the new Terra Flora plan, Windows NT Server Services for Macintosh will be added to the departmental servers running Windows NT Server, to provide file interchange and primary support for the Macintosh computers and the rest of the network. Although the Macintosh computers don't support TCP/IP, AppleTalk is enabled on the routers, allowing the Macintosh computers to communicate with the Department-level servers running Windows NT Server Services for Macintosh.

NetBEUI

NetBEUI is a non-routed, broadcast-based protocol. The master browser on TCP/IP networks cannot see or display computers that use NetBEUI to communicate with the network in the network browser list.

NetBEUI was used as a legacy protocol for networking between Windows 3.1 and MS-DOS clients. Terra Flora has already removed NetBEUI from all bridges and routed networks. Within the next six months, the Terra Flora client computers that rely on NetBEUI will be removed from the network or upgraded to Windows 95. The plan at Terra Flora is that no NetBEUI traffic will exist on any network segment after the next six months.

Installing and Configuring TCP/IP

Protocols are selected during the installation of a Windows NT operating system. The TCP/IP protocol must be configured differently for the various clients and client services.

The Terra Flora plan is to reduce network administration and improve performance by installing DHCP, WINS, and DNS to dynamically address computers, resolve names, and easily integrate with the existing UNIX environment. The installation of DHCP for dynamic addressing will decrease administration by lowering the number of entries necessary when the computers are moved from one physical location to another. The installation of WINS and DNS to resolve names will decrease the network traffic caused by computers announcing their presence to the network.

Configuring TCP/IP Clients

Only clients running an operating system software from the list below can be configured to act as a DHCP and WINS clients.

Windows NT Workstation version 3.5 or higher
Windows NT Server version 3.5 or higher
Windows for Workgroups 3.11 with the Microsoft 32-bit TCP/IP VxD installed
Microsoft Network Client for MS-DOS with real mode TCP/IP driver; this is one of the clients included on the Windows NT Server 3.5 or higher product
LAN Manager 2.2x for MS-DOS, included on the Windows NT Server version 3.5 CD-ROM and in the Windows NT Server 4.0 product
A Windows 95 computer

The configured clients can request DHCP IP addresses from computers running Windows NT Server DHCP service to communicate on the network with other computers. Configured clients can register their NetBIOS names with computers running Windows NT Server WINS service. The names and IP addresses will be passed to other computers to permit communications between the computers on the network. The configured clients can be located by computers running Windows NT Server DNS service and, therefore, communicate with other computers on the network.

Additional information on DHCP, WINS, and DNS appears later in this chapter and in Chapter 7 "Managing Microsoft DHCP Servers"; Chapter 8, "Managing Microsoft WINS Servers"; and Chapter 9, "Managing Microsoft DNS Servers."

The ability to use Windows NT Server DHCP service to obtain an address at startup is configured on the TCP/IP Properties dialog box, as illustrated on the Microsoft TCP/IP Properties dialog box below.

To open the TCP/IP Properties dialog box

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Protocols tab.
In Network Protocols, click TCP/IP Protocol.
Click Properties.

The Microsoft TCP/IP Properties dialog box appears.

All three client services, DHCP, WINS, and DNS will be configured using this graphical interface.

Configuring the DHCP Client

To configure a DHCP client

In the IP Address tab of the Microsoft TCP/IP Properties dialog box, click Obtain an IP address from a DHCP server, and then click OK.

You must restart your computer for the new settings to take effect.

Notes:

During the setup of Windows NT Workstation, you can elect to receive an IP address from a DHCP server. If you select Yes, then Obtain an IP address from a DHCP server is set as the default, and the procedure above is unnecessary.
The client computer will attempt to lease an IP address from the computer running Windows NT DHCP Server service. To obtain an address, the Scopes must be defined for the DHCP Server and addresses assigned to the Scopes for the client's subnet.

Configuring the WINS Client

A computer running Windows NT Server DHCP service can be configured to automatically provide IP addresses of the WINS and DNS servers used in the name resolution process. This removes the requirement of individually configuring each client with the WINS and DNS server IP addresses. The only requirement for the client is to click Obtain an IP address from a DHCP server in the Microsoft TCP/IP Properties dialog box.

The ability to use the Windows NT Server WINS service to resolve a client-computer request for other network computer names mapped to IP addresses is configured through TCP/IP. To do this, you need to know the following information.

Primary WINS Server address. This is the IP address of the WINS server that the client will register its name and IP address with.
Secondary WINS Server address. This is the WINS server that the client will register with and which will be used if the Primary WINS server is unavailable.

To configure a WINS client

In the Microsoft TCP/IP Properties dialog box, click the WINS Address tab.
Type the appropriate server addresses in Primary WINS and Secondary WINS.

Set the following options.
- To ensure that DNS servers will also be used to resolve client requests, select the Enable DNS for Windows Resolution check box.
- To ensure that the LMHOSTS file will be used to resolve name requests from the client if WINS should fail, select the Enable LMHOSTS Lookup check box.
Click OK when all settings are entered, as shown in the dialog box below.

You must restart your computer for the new settings to take effect.

Configuring the DNS Client

The ability to use the Windows NT Server DNS service to resolve client requests for other network computer names is configured through TCP/IP.

To configure a DNS client

In the Microsoft TCP/IP Properties dialog box, click the DNS tab.
In Host Name, type the client computer name.
In Domain, type the name of the authoritative domain.
Under Domain Service Search Order, type the IP address of the server that will be used to resolve DNS name queries, and click Add.

The TCP/IP DNS Server dialog box appears.
In DNS Server IP address, type the IP address of the DNS server that will be searched to resolve name-to-IP address queries, and click Add.
In Domain Suffix Search Order, type the domain suffix, click Add, and then click OK.

You must restart your computer for the new settings to take effect.

Notes:
- The domain name that would be entered for Terra Flora in step 3 of this procedure is Terraflora.com. For a complete discussion of domain names, see Chapter 3, "Implementation Considerations" of the Microsoft Windows NT Server 4.0 Networking Supplement.
- DNS Service Search Order contains the IP addresses of any DNS servers on the network (whether running Windows NT Server 4.0 DNS service or not).
- Domain Suffix Search Order indicated which subdomains will be searched to resolve the name queries.

Dynamic IP Addressing

All networked computers require both a unique name and address to communicate with any other networked computer. These addresses can be either dynamic or static.

Dynamic addressing automatically assigns an address to a computer when the computer is turned on or is moved to a different location (subnet) on the network.
Static addressing requires that an administrator configure new addresses.

Terra Flora's Choice of Addressing Services

Terra Flora has elected to use the Windows NT Dynamic Host Configuration Protocol (DHCP) to provide dynamic IP-addressing of the network computers.

Static configuration of client addresses can be expensive in terms of administrative effort and time. Currently, DHCP is the only open standard, which means it can interoperate with other operating systems. All other dynamic addressing products are proprietary.

Also, Terra Flora previously decided to standardize on the TCP/IP protocols with limited support for SNA protocol. The choice of DHCP helps keep the network administration costs down.

Other factors in the decision were Terra Flora's anticipated rate of corporate growth, the network requirements of traveling corporate personnel, and the requirements of the Internet. By setting up a dynamic system for addressing, Terra Flora can more easily accomplish its business goals in these areas.

Several tasks need to be accomplished to set up DHCP services for Terra Flora.

First, the servers that will become the DHCP servers need to be set up with static server addresses and then the DHCP Service must be installed on those servers.

Second, all the servers with DHCP enabled must be added to the DHCP Manager server list so that they can be administered.

Third, DHCP Scopes must be defined. This further involves establishing ranges of leased addresses for each subnet and configuring the optional configuration settings for those leases.

Fourth, Terra Flora will use DHCP Manager to reserve some IP addresses on the network for certain computers and devices.

Fifth, Terra Flora will configure a DHCP Relay Agent.

Administrative costs are reduced when network IP addressing tasks are performed by the servers instead of the administrative personnel; who are then free to perform other tasks. For example, the administrative task such as setup and maintenance of manual IP address tables to indicate which computer has which IP address will eliminated along with the need for administrators to travel to the physical location of computers to input or change the IP addresses.

Windows NT Server 4.0 supports DHCP to provide dynamic network addressing to clients. Currently it is the only open standard which can interoperate with other operating systems other products are proprietary.

Configuring DHCP

Procedures Used to Set Up DHCP

Computers running Windows NT Server are already placed throughout the Terra Flora network. On the Terra Flora network diagram, servers operating the DHCP service have been located in all three domains. In the California domain, CANTS40ENT03 is designated as a DHCP server. In the Northeast domain, NENTS40ENT01 plays that role, and in the Europe domain, it is EUNTS40ENT01. The DHCP service is part of the Windows NT Server product, and enabling the service is simple to do.

Configuring Static Server Addresses

A client computer obtains an address from a computer running the DHCP service when the client computer starts up. This depends on the client being able to locate the server responsible for leasing it an IP address. Because of this, the IP address of the server must not change; that is, the server running the DHCP service must have a static (unchanging) IP address.

To configure a static server address

In the Microsoft TCP/IP Properties dialog box, click the IP Address tab.
In Adapter, select the network adapter for which you wish to specify an IP address (if necessary), and then click OK.
Click Specify an IP address.

The settings in your dialog box will be similar to the following:

You must restart the server for these settings to take effect.

The option selected in the diagram is Specify an IP address. The administrator assigns a static IP Address, Subnet Mask, and Default Gateway address for the DHCP server.

Note: If the administrator specified an IP address and IP address information during the setup of Windows NT Server, the above step can be skipped.

Installing the DHCP Service on the Windows NT Server

DHCP can be installed as part of Setup. If DHCP is not installed as part of Setup, it must be configured on at least one network computer running Windows NT Server.

To install the DHCP server service on a computer running Windows NT Server

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Services tab.
Click Add.

The Select Network Services dialog box appears.
In Network Service, click Microsoft DHCP Server.
Click OK if loading from the network.

Or, click Have Disk to load the software from disks or a CD-ROM.
Type the full path to the Windows NT Server DHCP files, and then click OK.

You must restart the server for the changes to take effect.

Note: You must be logged on as a member of the Administrators group to install the DHCP service.

Accessing the DHCP Manager

The addition of the DHCP service places DHCP Manager on the Administrative Tools menu. Once the installation is complete on the computer running Windows NT Server, use DHCP Manager to complete the configuration of the DHCP server.

To access DHCP Manager

Click Start, point to Programs, point to Administrative Tools, and click DHCP Manager.

Adding Servers to the Server List

Using the DHCP Manager, the administrators at Terra Flora can configure, set up and maintain all the computers running Windows NT Server with the DHCP Server service enabled from a single computer or from any computer.

The DHCP Manager contains a list of the servers that it can administer. Initially, this list is empty. Until servers are added to the server list, the options provided with DHCP are not available. Even the first computer running Windows NT Server on which you install DHCP must be added to the server list before it can be administered. DHCP Manager.

To add a DHCP server to the Server List

On the Server menu of DHCP Manager, click Add.

The Add DHCP Server to Server List dialog box appears.
In DHCP Server, type the IP address of the DHCP server to be added to the list, and then click OK.
Repeat steps 1 and 2, if necessary, to add all the network computers running Windows NT Server with DHCP service enabled.

Note: You cannot administer network servers running other dynamic addressing programs from a computer running Windows NT Server with DHCP service enabled.

Managing DHCP Scopes

On any given network, for clients to obtain dynamic IP addresses, there must be at least one computer running Windows NT Server DHCP service. Once the DHCP Server service is installed on a computer running Windows NT Server, and the Windows NT server is added to the server list, a DHCP scope must be created.

A DHCP scope consists of a pool of IP addresses on a given subnet, such as 223.223.223.1 to 223.223.223.200, that the DHCP Server can lease to DHCP Clients.

At Terra Flora, each computer running Windows NT Server DHCP service will store at least one scope containing the ranges of IP addresses that the Windows NT Server DHCP service can lease to requesting clients. Each scope will contain a unique pool of addresses from which to assign IP addresses.

Refer to the Terra Flora diagram. On the California domain PDC, a scope will be named CAPDCDHCP and will contain its own unique pool of IP addresses that will be assigned as clients start up. The scope on the BDC will be named CABDCDHCP and will also have a unique pool of addresses.

When the computer running Windows NT Server DHCP Service receives a request from a DHCP enabled client for an IP address, the DHCP server will select an available IP address from its pool of IP addresses and offer it to the DHCP client, along with other configuration information that can be displayed using various DOS commands.

The computers running Windows NT Server DHCP service will not only provide Terra Flora with the ability to dynamically configure clients IP addresses, but DHCP will, as part of the service it provides, record that address as leased to the client, eliminating the need for manual tracking of IP addresses. The DHCP leasing policy can be fully configured by administrators, eliminating any need for manual intervention.

The Windows NT Server DHCP service lease mechanism provides the following benefits:

No need for user configuration.

Users no longer need to acquire an IP address from an administrator to properly install and configure TCP/IP. When a client is configured to use automatic DHCP, it will automatically lease an IP address from a DHCP Server at start up.
No more configuration errors.

The Windows NT Server DHCP Service supplies all of the necessary configuration information to all of the DHCP-enabled clients and servers. As long as the DHCP Server maintains the correct configuration information, none of the clients or servers will ever be incorrectly configured. At Terra Flora, the difficulty of tracing network problems that resulted from incorrectly configured workstations and servers will be a thing of the past.
Very little administrative overhead.

Administrators define a pool of IP addresses that the Windows NT DHCP Service will lease to the DHCP clients. Administrators no longer need to keep track of which IP address are in use and which IP addresses are available.
No need to reconfigure clients or servers that change subnets.

When the client computer changes subnets and starts up on its new subnet, it will lease an IP address from a Windows NT Server running the DHCP Service that is appropriate for the subnet on which it is now located.
DHCP client configurations automatically updated during the renewal process.

For example, if you change a DNS server address, it gets distributed to the network client dynamically.

Note: DHCP clients will cache their old IP addresses and will request the old IP addresses from the DHCP server if it is available. In most cases, the DHCP server will have the address available, as it assigns new addresses before scavenging old addresses.

A scope includes the following:

A range of IP addresses that can be leased by DHCP clients, referred to as a pool of IP addresses or an IP address pool. Each DHCP scope will have a unique pool of IP addresses, which it can lease to DHCP clients. The IP addresses in the pool will not exist in a scope stored on any other network computer running Windows NT Server DHCP service.
A valid Subnet Mask for the pool of IP addresses.
Any IP addresses in the IP address pool range that need to be excluded so that they will not be leased to DHCP clients, such as the IP addresses of the other DHCP servers on the network, WINS and DNS servers, subnet addresses, router IP addresses, or any range that will be used on the network by devices requiring static IP addresses.
The duration of the IP address lease, which defaults to three days.

The maximum lease duration can be set to either 'Unlimited' or up to 999 days, 23 hours, and 59 minutes. For details on what happens when a lease expires, see Chapter 7, "Managing Microsoft DHCP Servers."

The default length of an IP address lease can be configured to a longer or shorter amount of time by an administrator.

Based on the number of available IP addresses in the DHCP scopes, how many of the scope's IP addresses will typically be in use by DHCP clients, and the frequency with which the DHCP clients will be rebooting or changing subnets, the lease duration for a DHCP Lease duration at Terra Flora will be configured at 7 days. This will provide a good balance between having too many addresses leased out to computers that are no longer on the network, and the renewal network traffic.

At Terra Flora, the guidelines for determining the appropriate lease duration were:

Increasing the Lease Duration

Terra Flora had to consider the number of IP addresses available in each DHCP scope. If there would be a large number of IP addresses available in the DHCP scope and relatively few DHCP clients, the lease duration should likely be increased in length. Increasing the lease duration would reduce the frequency that the DHCP clients will query the DHCP Server to renew their leases and therefore somewhat reduce network traffic.
Reducing the Lease Duration

If there was to be a limited number of IP addresses available in the DHCP scope, most of which will be in use at any given time, it would be desirable to reduce the lease duration. In addition, if DHCP clients on a given network would frequently be changing subnets and therefore requiring a different IP address, it would be beneficial to reduce the lease duration, especially if there are a limited number of IP addresses available. Reducing the lease duration would require DHCP clients to renew their leases more frequently, but would also ensure that any unused IP addresses in the pool are seen as available to lease by the DHCP server as soon as possible.
The name of the scope, which is a maximum of 128 characters, and a descriptive comment about the DHCP Scope.

At Terra Flora, the descriptive comment will be the name of the Domain on which the DHCP server resides.

The creation of DHCP servers scopes is performed from the DHCP Manager

To create a scope

Open DHCP Manager and double-click the DHCP server you want to manage.
On the Scope menu, click Create.
Under IP Address Pool, enter the server's beginning IP address in Start Address.
In End Address, enter the last IP address.
To add exclusion ranges, type a range in Exclusion Range, and click Add; then repeat for as many ranges as you want to set.
To remove exclusion ranges, click the range in Excluded Address, and then click Remove.
Under Lease Duration, click Limited To and enter the amount of time that the lease will last.
In Name, type the name of the scope.
If appropriate, type remarks in Comment, and then click OK.

Terra Flora will configure a scope named "California" for the California Domain on the PDC. The Lease Duration at Terra Flora will be defined at seven days.

Note: Once the administrative scope has been created, it must be activated before the DHCP Server will lease any IP addresses from the DHCP scope's IP address pool.

A DHCP scope is activated and deactivated from the DHCP Manager Scope menu. In DHCP Manager, active scopes will be preceded by a light bulb icon that looks as it is turned on and deactivated scopes will be preceded by a gray light bulb that looks as if it is turned off.

Once a DHCP scope has been created any of the scope's settings, such as the range of the IP address pool, it can be modified from the Scope Properties menu.

Reserving IP addresses

The DHCP Manager allows the reservation of a specific IP address for a computer. At Terra Flora, the plan is to reserve DHCP IP addresses on the network in the scope for the following devices and computers:

Domain controllers (since the network also uses LMHOSTS files that define IP addresses for domain controllers).
Clients that use IP addresses assigned by another TCP/IP configuration method, such as UNIX DNS and netware clients.
Any DNS Servers on the network, whether running Windows NT Server 4.0 DNS service or not.
Any Windows NT Server with WINS enabled.
Any Routers used to direct network traffic between subnets.
Any DHCP servers.

The IP address for the DHCP servers were assigned during the Windows NT Server Setup. The addresses assigned to the DHCP servers will now be reserved for those servers.

The administrator will reserve IP addresses using Add Reservations on the DHCP Manager Scope menu. When the computer client requests an IP address from the DHCP Server, the DHCP Server will always return the reserved IP address.

Note: The static addresses placed in Add Reservations will always override any configuration options specified using DHCP Manager.

To reserve a client address in DHCP:

In DHCP Manager, double-click the DHCP server you want to manage.
Click the scope in which you want to add reservations.
On the Scope menu, click Add Reservations.

Two important entries in the dialog box are:

Unique Identifier

The unique identifier is the media access control (MAC) address for the DHCP client and can be obtained by typing the following command at the command prompt on the client computer for which the address will be reserved:
- IPCONFIG -ALL.
- Press enter.
- The MAC address is the address labeled as the Physical Address.
Client Name

This entry should be the computer name of the DHCP client. The name is used only for identification purposes. This entry is not available when adding reservations for MS-DOS–based DHCP clients.

Notes: It is critical that Unique Identifier entry be correct because the MAC address is sent as part of the DHCP client's request for an IP address to the DHCP Server. If this value is not correct, no match is found on the DHCP server, which means the DHCP Server will assign the client any available IP address instead of the reserved IP address.

On Windows 95 clients, you must run the program Winipcfg.exe to view the MAC or physical address.

Configuring DHCP Options

At a minimum, a DHCP server must provide the DHCP client with the following information:

A valid IP address to lease (configured when the DHCP Scope is created).
A Subnet Mask (configured when the DHCP Scope is created).
A Default Gateway, which defaults to an IP address of 0.0.0.0 if not configured.

These items are referred to as configuration parameters. There are about 60 other predefined DHCP configuration parameters, called options, that an administrator can configure through the DHCP Manager for one or all scopes on a DHCP server. For a complete listing of the options and their meanings, see Chapter 7, "Managing Microsoft DHCP Servers"

There are four methods that can be used to set the DHCP Options:

Global

When you set a global DHCP option, the option takes affect for all DHCP scopes defined on the selected DHCP server. Global DHCP options appear in the DHCP Manager with a globe icon proceeding them.
Scope

Setting a scope DHCP option will set the option only for the selected scope on the Options Scope menu. DHCP options configured for a scope are displayed with a series of computer icons proceeding them in DHCP Manager.
Default

Setting a default DHCP option modifies the default value for one of the DHCP Options. When a default value is set, the default value becomes the default that was set during administration rather than the DHCP default that was set during installation of DHCP.
Client

This method can be used to configure one or more of the DHCP options for a specific DHCP client. DHCP options can be set for a client only if the DHCP client has a reserved IP address. The only way to see if a DHCP option is set for a DHCP client is to view the properties of an active client lease on the Scope Active Leases menu and then clicking Options.

Configuring a Global, Scope, or Default DHCP Option

Configure a Global, Scope, or Default DHCP Option on the DHCP Options menu by clicking Global, Scope, or Default.

If Scope or Global is selected, the following dialog box appears, indicating which menu option was selected by printing the title of the menu option in the title bar.

To configure DHCP options globally or by scope

In DHCP Manager, double-click the DHCP server you want to manage.
Click the scope for which you want to configure DHCP Options.
On the DHCP Options menu, click Global to change options globally.

Or, click Scope, to change options by scopes.
Click Edit Array.

Enter the changes that you want for DHCP options.

Using the dialog box, the administrator can change or add a new DHCP option to the list and configure it with the proper settings.

To configure Default DHCP Options

If necessary, click the DHCP Standard Options default as the value in Option Class.
In Option Name, click Change to change the default.

Or, click New to create a new default.
When the fields that need to be changed appear, enter the appropriate settings, and then click OK.

Configuring DHCP Options for a Particular Client

Configuring client options can be performed only if the IP address for the client has been reserved. Configuring client options is performed using a different graphical interface than was used to configure the Global, Scope or Default options.

For details about reserving addresses, see "Reserving IP addresses," earlier in this chapter.

To configure DHCP options for a particular client

Click the server where the reserved client's IP address resides for which you want to enable options.
Click the scope that contains the client reservation.
On the Scope menu, click Active Leases.
Click the client that you want to configure.
Click Properties.
Click Options.

The DHCP Options: Reservations dialog box appears.
In Unused Options, click the option you want to add for the client, and then click Add.
To change or enter a value for the option, click it in Active Options, and then click Value.
Enter the appropriate value, and click OK.

For a complete description of the options available, see Chapter 7, "Managing Microsoft DHCP Servers."

Precedence of DHCP Options

If a DHCP option is set for more than one level, such as for both global and scope, precedence is in the following order:

Client overrides both scope and global.
Scope overrides global.
If there is no client or scope setting for a DHCP option, then the global setting has precedence.

Benefits of DHCP Options

These include:

Centrally administered network settings
Dynamic updates
No need for manual entry on every client

Commonly Configured DHCP Options

Some of the DHCP options administrators typically configure are:

003 Router

The Router parameter requires the IP addresses for one or more routers and is the equivalent of the Default Gateway entry in the TCP/IP configuration dialog box.
006 DNS Servers

The Domain Name Server parameter requires the IP addresses for one or more DNS servers.
015 Domain Name

This option is used to specify DNS domain names to be used for host name resolution.
044 WINS/NBNS Servers

The WINS/NBNS (NetBIOS Name Servers) Servers parameters requires IP addresses for one or more WINS/NBNS servers.
046 WINS/NBT node type

This DHCP option can be used to configure the method that the DHCP client will use to resolve computer (NetBIOS) names: 0x1 (b-node), 0x2 (p-node), 0x4 (m-node), or 0x8 (h-node).

Note: A computer running Windows NT Server DHCP service can be configured to automatically provide IP addresses of the WINS and DNS servers used in the name resolution process. This removes the requirement of individually configuring each client with the WINS and DNS server IP addresses. The only requirement for the client is to click Obtain an IP address from a DHCP server on the Microsoft TCP/IP Properties dialog box.

Configuring a DHCP Relay Agent

Computers running Windows NT Server DHCP service have the ability to use the bootP relay service which enables clients on one subnet to access a DHCP server on another subnet. Refer to the Terra Flora network diagram. In the Terra Flora California domain, all the servers running Windows NT Server DHCP service are located on the Enterprise level.

There are three subnets in the California domain, and only one subnet contains the servers running Windows NT Server DHCP service. The two subnets that do not contain computers running Windows NT Server DHCP service have a computer running Windows NT Server that acts as DHCP relay or bootP relay agent. The DHCP bootP relay agents are named CANTS40DIV03 and CANTS40DPT02.

When a dynamic client computer on the subnet where the bootP relay agent resides requests an IP address, the request is forwarded to the subnet's bootP relay agent. The bootP relay agent, in turn, is configured to forward the request directly to the correct computer running Windows NT Server DHCP service. The computer running Windows NT Server DHCP service returns an IP address directly to the requesting client.

For a detailed discussion on the bootP relay agents, see Chapter 7, "Managing Microsoft DHCP Servers."

Configuration of the DHCP bootP relay agent is a two-step process. The first step is to install the DHCP Relay Agent Service on the computer that will act as a bootP relay agent. The DHCP Relay Agent Service is a Windows NT Server service. The bootP agents can then be configured, using the Microsoft TCP/IP Protocol Properties dialog box, with the IP address of the computer running Windows NT Server DHCP, so the agent will know where to forward requests from clients for available IP addresses. Installing the service and configuring the agents are both performed using Network in Control Panel.

To install the DHCP Relay Agent Service

In the Network dialog box, click the Services tab.
Click Add.
Under Network Service, click DHCP Relay Agent, and then click Have Disk if loading the software from disks or a CD-ROM.

Or, click OK if loading from the network.
In the message that appears, type the full path to the Windows NT Server DHCP files, and click OK.

The DHCP service is installed.
Click Close.

Configuration and binding information is checked.

You must shut down and restart the computer before the new settings will take effect

Addition of the TCP/IP address of the computers running Windows NT Server DHCP service to the bootP relay agents is performed in the TCP/IP Properties dialog box.

To add an IP address to the bootP relay agent:

In the Network dialog box**,** click the Protocols tab.
Click TCP/IP Protocol, and then click Properties.
Click the DHCP Relay tab.
Check that the Seconds threshold and Maximum hops settings are set at 4.
Under DHCP Servers, type the IP address of the server that will provide the IP addresses to the subnet's requesting clients.
Click Add, and then click OK.

Name Resolution Using WINS and DNS

Due to the heterogeneity of the network at Terra Flora, administrators have decided to implement two Windows NT Server services to manage all name resolution issues. Windows Internet Name Service (WINS) and Domain Name System (DNS).

Terra Flora is interoperating several heterogeneous networks. To communicate, each computer needs a unique computer address and name. There are two types of names and both types exist on one or more of the small Terra Flora networks being merged into one large network. Windows NT network applications use a naming convention known as NetBIOS. In general, NetBIOS computer names consist of a single part.

In contrast, TCP/IP components rely on the DNS naming convention. DNS computer names consist of two parts: a computer name and a domain name, which combine to form the fully qualified domain name (FQDN).

NetBIOS computer names can be made compatible with DNS computer names, making interoperation possible between the two. Windows NT combines the NetBIOS computer name with the DNS domain name to form the FQDN.

Note: Under Windows NT Server, the DNS host name defaults to the same name as the NetBIOS computer name. You can change this if you need separate names.

The Decision to Use WINS

As with dynamic addressing of computers, dynamic name registration and resolution of computers and associated addresses will reduce administrative costs at Terra Flora. If administrative tasks can automatically be performed by the computers running Windows NT Server with WINS enabled, administrators are free to perform other network administrative tasks.

A WINS server maintains a dynamic database that maps the NetBIOS computer names of WINS clients to their IP addresses. Both a computer name and IP address are necessary for network clients to communicate effectively on the enterprise network. At Terra Flora, clients are configured as both DHCP- and WINS-enabled.

The primary purpose of WINS is to respond to network clients that are trying to locate a computer on the network by using its' NetBIOS name. The WINS server responds to the network client with the IP address of the desired computer, thus enabling the client computer to connect to the desired computer via a TCP/IP session. To enable this functionality, the WINS clients register their NetBIOS names with the WINS server. The registered name is stored in a database on the server on a dynamic basis so the name can be reused later if the client stops using it.

A WINS client is responsible for maintaining the lease on its registered name and informing the WINS server periodically that it is still present on the network. When it shuts down, it also notifies the WINS server that the name is being released.

Terra Flora administrators decided to use WINS for the following reasons:

Dynamic database maintenance will support computer name registration and name resolution. WINS provides dynamic name services, and it offers a NetBIOS name space, making it much more flexible than DNS for name resolution. The WINS and DNS servers will be integrated to serve all name resolution needs at Terra Flora.
WINS centralizes management of the computer-name database and the database replication policies, which will alleviate the need for managing LMHOSTS files.
Windows NT Server has been chosen as the integration tool to interoperate the heterogeneous networks at Terra Flora. Implementation of WINS will reduce the IP broadcast traffic while allowing client computers to easily locate remote systems across local or wide area networks.

Installing and Configuring WINS

A WINS server is a computer running Windows NT Server using the Microsoft TCP/IP protocol and the WINS server software. WINS servers maintain a database that maps computer names to IP addresses, allowing users to easily communicate with other computers while gaining all of the benefits of using TCP/IP.

For a complete discussion of the WINS service, see Chapter 8, "Managing Microsoft WINS Servers."

Installing WINS Servers

Installing a WINS server is part of the process of installing Microsoft TCP/IP in Windows NT Server. The following instructions assume you have already installed the Windows NT Server operating system on the computer.

You must be logged on as a member of the Administrators group to install WINS.

To install a WINS server

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Services tab.
Click Server, and then click Add.
In the Select Network Service dialog box, click Windows Internet Name Service.
Click Have Disk if you are loading the software from disks or a CD-ROM.

Or, click OK if loading from the network.
In the Windows NT Setup dialog box, type the full path to the Windows NT Server WINS files, and then click Continue.

You must shut down and restart the computer before the new settings will take effect. The WINS Manager then appears on the Administrative Tools (Common) menu on the desktop.

Managing WINS Servers

The addition of the WINS service places the WINS Manager on the Administrative Tools (Common) menu. Once the installation is complete on the computer running Windows NT Server, use WINS Manager to complete the configuration of WINS.

To start WINS Manager

Click Start, point to Programs, point to Administrative Tools (Common), and click WINS Manager.

Adding WINS Servers

Before you can administer and manage WINS servers, you must add the WINS servers to the Server List using the WINS Manager graphical interface. At Terra Flora, all computers running Windows NT Server WINS service will be added to the WINS Server List. Until the WINS servers are added to the list, no WINS features are available. Once the servers are added to the list, administration of any computer running Windows NT Server WINS Service can take place from any other computer running Windows NT Server WINS Manager.

To Add a WINS server to the Server List

On the WINS Manager Server menu, click Add.

The Add WINS Server to Server List dialog box appears.
In WINS Server, type the IP address of the DHCP server to be added to the list, and then click OK.

Once a WINS Server is added to the list, configuration of the server can take place.

Configuring WINS Servers

Terra Flora will configure multiple WINS servers to increase the availability and balance the load among servers. To configure a WINS server, you must be a member of the administrators group of that server.

To configure a WINS server

In WINS Manager, click the server you want to configure.
On the Server menu, click Configuration.

The WINS Server Configuration dialog box appears.

Select the configuration options you want.
- To specify how often a WINS client will renew its name registration with the WINS Server, type a value in Renewal Interval.
- To specify the interval between when an entry in the WINS database is marked as released (no longer registered) and when it is marked as extinct, type a value in Extinction Interval.
- To specify the interval between when an entry is marked extinct and when the entry is scavenged (removed) from the WINS database, type a value in Extinction Timeout.
- To specify when the WINS server will verify that old names it does not own (those replicated from other WINS servers) are still active, type a value in Verify Interval.
- To specify pull parameters, select the Initial Replication check box under Pull.
- To specify the number of times that the WINS server will attempt to contact a replication partner for pulling new WINS database entries, type a value in Retry Count.
- To have the WINS server notify its replication partners of the status of its WINS database when the system is initialized, select the Initial Replication check box under Push Parameters.
- To notify the replication partners of the WINS server when a name registration changes the WINS database status, select the Replicate on Address Change check box.
Click Advanced to configure other options.
- To specify logging of database changes to Jet.log, select the Logging Enabled check box.
- To log events in detail, select the Log Detailed Events check box.
- To replicate only WINS push or pull partners, select the Replicate Only With Partners check box.
- To automatically back up the database when WINS Manager stops, select the Backup On Termination check box.
  
  The database backup path must have a directory specified.
- To treat static unique and static multihomed records in the database as dynamic when they conflict with a new registration or replica, select the Migrate On/Off check box.
  
  This means that if they are no longer valid, they will be overwritten by the new registration or replica. By default, this option is not checked.
- To set the highest version ID number for the database, enter that number in Starting Version Count.
- To specify the directory where the WINS database backups will be stored, type the path in Database Backup Path.
When you have completed all changes in the WINS Server Configuration dialog box, click OK.

Notes:

Specify the %systemroot%\system32\wins directory. A subdirectory for the backup will be added to WINS directory.
Logging events in detail requires considerable system resources and should be turned off if you are tuning for performance.
If the Replicate Only With Partners check box is not selected, an administrator can ask a WINS server to pull or push from or to a non-listed WINS server partner. By default, this option is checked.
Usually, you will not need to change the value in Starting Version Count unless the database becomes corrupted and needs to start fresh. In such a case, set this value to a number higher than appears as the version number counter for this WINS server on all the remote partners that earlier replicated the local WINS server's records. WINS may adjust the value you specify to a higher one to ensure that database records are quickly replicated to other WINS servers.
If you specify a backup path, WINS automatically performs a full backup of its database to this directory every 24 hours. WINS uses this directory to perform an automatic restoration of the database in the event that the database is found to be corrupted when WINS is started. Do not specify a network directory.

Configuring Replication Partners

All of the WINS servers on a network can be configured to communicate with each other so that a name registered with one WINS server will eventually be known by all WINS servers. In addition to registration of all names on the network with all WINS servers, all WINS servers will eventually be notified when a name is released. Replication is carried out among replication partners, rather than by each server replicating to all other servers. Each WINS server must be configured with at least one other WINS server as its replication partner.

In Terra Flora's main California Domain, one WINS server will be designated as the central server, and all other WINS servers will be configured as both push and pull partners of this central server. A pull partner is a WINS server that pulls in replications of database entries from its partner by requesting and then accepting the replications. A push partner is a WINS server that sends update notification messages to its partner when its WINS database has changed. This configuration ensures that the WINS database on each server contains names addresses for every network computer.

The Terra Flora network diagram of the California domain shows only two of the WINS servers. At Terra Flora, WINS will be enabled on several computers running Windows NT at the Enterprise level. All of these computers running Windows NT Server WINS server will be configured as push and pull partners of each other.

The PDC will act as the central server. It will push changes made to its database to the next server in the line, which then pulls the changes from the PDC. This will continue down the line, with the server last on the line pushing back to the central server, which will pull in changes from the last server on the line. This ensures that all the databases on all WINS servers are replicated and up-to-date.

Additionally, the administrator can perform a replication immediately or at a specified time.

To add a replication partner to a WINS server

On the WINS Manager Server menu, click Replication Partners.

The Replication Partners dialog box appears, showing all replication partners of the WINS server.
Click Add.
Type the IP address of the WINS server that is to be added as a push or pull partner.

The added server can be configured as either a push or pull partner to the WINS server. The replication partner will automatically be added as both a push and pull partner of the server that is being configured. This can be changed.

To configure replication partners for a WINS server

In WINS Server in the Replication Partners dialog box, click the server you want to configure.
Under Replication Options, select the Push Partner check box, the Pull Partner check box, or both, to indicate the appropriate replication partnership.
Under Replication Options, select the Configure check box for each of the appropriate settings.

The Push Partners Properties or Pull Partners Properties dialog box appears.

To define pull partner properties

In Start Time on the Pull Partner Properties dialog box, type a number to indicate when replication should begin, using any separator (such asAM or PM) for hours, minutes, and seconds.
In Replication Interval, type a time in hours, minutes, and seconds to indicate how often replications will occur.

Or, to use values specified in the Preferences dialog box, click Set Default Values.
Click OK.

The AM and PM designators are part of your time setting in International (in Control Panel).

To define push partner properties

In Update Count on the Push Partner Properties dialog box, type the number of additions and updates that can be made to records in the database before replication must take place.

The minimum value is 20; replications that have been pulled in from partners do not count as insertions or updates in this context.
Click OK.

If you decide later to reset the values specified in the Preferences dialog box, you can reopen the Push Partner Properties dialog box and click Set Default Values.

Triggering Replication Between Partners

You can also immediately replicate the database between the partners, rather than waiting for the start time or replication interval specified in the Preferences dialog box. For details, see "Setting Preferences for WINS Manager" later in this chapter.

You probably want replication to begin immediately after you make a series of changes, such as entering a range of static address mappings.

To trigger replication

On the Server menu of WINS Manager, click Replication Partners.
Click the WINS servers to which you want to send a replication trigger.

Or, if you want the selected WINS server to propagate the trigger to all its pull partners, select the Push With Propagation check box.
Under Send Replication Trigger Now, click Push or Pull, depending on which partners you want to trigger.

If Push With Propagation is not selected, the selected WINS server does not send the trigger to its other partners.

If Push With Propagation is selected, the selected WINS server sends a propagate push trigger to its pull partners after it has pulled in the latest information from the source WINS server. If it does not need to pull in any replicas because it has the same or more up-to-date replicas than the source WINS server, it does not propagate the trigger to its pull partners.

To start replication immediately

In the Replication Partners dialog box, click Replicate Now.

Adding Static Mappings

Static mappings are permanent lists of computer name-to-IP address mappings. In the table, the administrator indicates the computer name and matches the IP address the computer. When a network client sends a name request to the WINS server, the WINS server will always respond with the name entered by the administrator. At Terra Flora, all DNS servers, DHCP servers and other WINS servers will be statically added to all WINS servers.

Note: If DHCP is also used on the network, a reserved (or static) IP address will override any WINS server settings. Static mappings should not be assigned to WINS-enabled client computers.

You can add static mappings to the WINS database for specific IP addresses using two methods:

Typing static mappings in a dialog box.
Importing files that contain static mappings.

To type static mappings in a dialog box

On the Mappings menu, click Static Mappings.
Click Add Mappings.
In Name, type the computer name of the system for which you are adding a static mapping.

WINS Manager automatically adds the two backslashes (\\), which normally proceed the entry of a computer name.
In IP Address, type the address for the computer.
In Type, click to indicate whether this entry is a unique name or a group with a special name, and then click Add.

The mapping entry is immediately added to the database, and the check boxes are cleared so that you can add another static mapping entry.

The settings available under Type include the following:

Unique is a unique name in the WINS database that permits only one address per name. The unique name is the WINS client's computer name.
Group indicates a normal group for which the IP addresses of the individual clients are not stored. A normal group is the name to which broadcasts are sent and is the domain name used for browsing purposes. A normal group name has Ox1E as its 16th byte, which appears as a [1Eh] at the end of the name in Mappings, View Database option in WINS Manager. A normal group name does not have an IP address associated with it and can be valid on multiple networks and registered with multiple WINS Servers. When a WINS server receives a request for the group name, the WINS server returns the limited broadcast address 255.255.255.255, which the WINS client will then use to broadcast to the network. For a description of the 16th byte fields, see Appendix G, "NetBIOS Names."
Internet Group is a group that contains the IP addresses for up to 25 primary and backup domain controllers for the domain. An Internet group has a 0X1C as its 16th byte, which appears as a [1Ch] at the end of the name in Mappings, View Database option in WINS Manager. The Internet group name is another instance of the domain name being registered; however, this instance is used for the domain controllers in the domain to communicate with each other.
Multihomed is similar to a unique name in that it is the WINS client's computer name; however, it can have up to 25 addresses and is for use by multihomed systems. A multihomed system is a system with more than one network interface and more than one IP address.

If Internet Group or Multihomed is selected under Type, the dialog box shows additional controls for adding multiple addresses. Click the down arrow (button) to move the address you type into the list of addresses for the group. Use the up-arrow button to change the order of a selected address in the list.

Entries for static mappings of unique and special group names can be imported from any file with the same format as the LMHOSTS file, which is described in Chapter 10 "Using LMHOSTS Files." Scope names and keywords other than #DOM are ignored. Static Mapping for normal group and multihomed names can be added only by typing entries in the Add Static Mappings dialog box.

Note: For Internet group names defined in this dialog box (that is, added statically), make sure that the primary domain controller (PDC) for that domain is defined in the group if the PDC is running Windows NT Advanced Server version 3.1.

To import a file containing static mapping entries

In the Static Mappings dialog box, click Import Mappings.
In the Select Static Mapping File dialog box, enter the name of the file containing the names to be mapped.

The specified file is read, and then a static mapping is created for each computer name and address. If the #DOM keyword is included for any record, an Internet group is created (if it is not already present), and the address is added to that group.

For more information on managing Static Mappings, see Chapter 8, "Managing Microsoft WINS Servers."

Setting Preferences for WINS Manager

Several options can be configured to administer WINS servers. The control preferences are on the Options menu.

To set preferences for WINS Manager

On the Options menu, click Preferences.

In the Preferences dialog box, specify the settings you want to change.
- To indicate how you want address information to be displayed throughout WINS Manager, click Computer Name Only, IP Address Only, or one of the ordered combinations: Computer Name (IP Address) or IP Address (Computer Name.)
- To automatically refresh the statistics in the WINS Manager window, select the Auto Refresh check box under Server Statistics, and then enter a number in Interval (seconds) to specify the time between refresh actions.
- To have computer names to adhere to the LAN Manager naming convention, select the LAN Manager-Compatible check box.
  
  This check box should be selected unless your network accepts NetBIOS name from other sources.
- To have the system query the listed servers each time the system starts to find out if each server is available, select the Validate Cache Of "Known" WINS Servers At Startup Time check box.
- To have a warning message appear each time you delete a static mapping or the cached name of a WINS server, select the Confirm Deletion Of Static Mappings And Cached WINS Servers check box.
- To specify the default for replication start time for new pull partners, type a time in Start Time, and then specify values in Replication Interval to indicate how often data replicas will be exchanged between the partners.
- To specify the default number of local registrations and changes that can occur before this server (as a push partner) sends a replication trigger, enter a number in Update Count under New Push Partner Default Configuration.
  
  The minimum value is 20.
Click OK.

WINS Manager also automatically refreshes the statistical display each time an action is initiated while you are working in WINS Manager.

LAN Manager computer names are limited to 15 characters, as compared to the 16-character NetBIOS names used by some other sources, such as Lotus Notes. In LAN Manager names, the 16th byte is used to indicate whether the device is a server, workstation, messenger, and so on. When this option is selected, WINS adds and imports static mappings with 0, 0x03, and 0x20 as the 16th byte.

All Windows – based networking, including Windows NT, follows the LAN Manager convention.

The replication interval should be equal to or less than the lowest refresh time interval that is set on any of the replicating WINS servers. The minimum value for the replication interval is 40 minutes.

The Decision to Integrate DNS with WINS

DNS is not dynamic, which means that administrative overhead is increased in a network like Terra Flora with the use of DNS. Administrators must update DNS computer files whenever a computer moves or a new computer is added to the network.

WINS was created to ease this type of administrative burden. Coupling DNS with WINS capitalizes on the strengths of each to provide a form of dynamic DNS. Windows NT 4.0 Server DNS Service provides a WINS lookup feature. If the name cannot be resolved using DNS, the name request is forwarded to WINS for resolution. It is this form of an integrated, dynamic, name-resolution feature that contributed to the decision at Terra Flora to migrate most of their DNS information and application to computers running Windows NT Server with the DNS service enabled. Terra Flora will use both DNS and WINS to resolve names.

It is clear to the CIO that the WINS Lookup feature provided as part of the Windows NT Server DNS service would help cut administrative costs by eliminating some of the manual name and address tracking administrative tasks associated with the current network DNS systems.

A key feature of the DNS service in Windows NT Server 4.0 is a graphical interface from which the database files can be managed. Use of this graphical tool should eliminate some of the error associated with making changes directly to a zone database file using an file editor.

Note: This form of dynamic name resolution is only available on networks with computers running Windows NT Server with DNS and WINS enabled.

For a complete discussion of DNS and WINS integration, see Chapter 3, "Implementation Considerations" in the Microsoft Windows NT Server 4.0 Networking Supplement.

Implementation Plan for DNS

DNS is in use on many of the heterogeneous networks at Terra Flora. The plan to implement Windows NT Server DNS service was quite involved due to the fact that DNS is running without problems on the majority of the small, heterogeneous networks. However, the benefit of reduced administrative cost, combined with an integrated solution for the heterogeneous network was a compelling benefit to use Windows NT Server WINS and DNS services.

Note: Before the merger of the heterogeneous networks, Terra Flora had four DNS zones. Terraflora.com was registered with Internet Network Information Center and operated as the authoritative domain. Three other zones were created on DNS servers, one for each of the company divisions, which were Nursery. Terraflora.com; Retail. Terraflora.com, and Supply.Terraflora.com.

The plan at Terra Flora includes replacing two of the three division's DNS systems with computers running Windows NT Server 4.0 DNS service. These two division are Supply.Terraflora.com and Nursery. Terraflora.com

The Sun server in the Retail Services division \\CASWN25ENT01 currently runs the key mission critical corporate application systems of Terra Flora. The plan for the current DNS system in the Retail. Terraflora.com zone is to incorporate a server running Windows NT Server 4.0 DNS service as a secondary server and track the performance of the server.

Then the Retail.Terraflora.com zone will be split. The new zone will be called NT.Retail.Terraflora.com and will consist of only computers running Windows NT Server 4.0 DNS service and no other DNS service. The servers will also be running WINS and DHCP and have the WINS Lookup feature enabled. The plan will be to eventually migrate all of the DNS functionality in the Retail Services division to Windows NT Server 4.0.

Note: Domain: There are several meanings associated with Domain. In the DNS world a domain is the name and address of every machine associated with a group. Windows NT Server domains are defined as the logical grouping of network servers and other computers that share a common security and user account information. For this discussion, domains will be divided into two terms: DNS Domains and Windows NT Server Domains.

Replacing the Nursery and Supply Divisions DNS Systems

The plan at Terra Flora is to replace the DNS servers storing the zone information and files of Nursery.Terraflora.com and Supply.Terraflora.com with the Windows NT Server DNS service. To do this, the following steps must be performed:

Windows NT Server 4.0 DNS service will be installed on primary and secondary servers running Windows NT Server DNS service in each zone. The graphical DNS manager tool is available on the Administrative Tools menu as a result of the installation of Windows NT 4.0 DNS Service.
All the servers running Windows NT Server 4.0 with the DNS service enabled will be added to the server list using the graphical interface tool called DNS Manager. In this way, Terra Flora can administer all the computers running Windows NT Server 4.0 DNS service from any computer running Windows NT Server DNS service by using the DNS Manager graphical interface.
The zone, boot and cache files for Nursery.Terraflora.com and Supply.Terraflora.com will be moved to the appropriate computer running Windows NT Server 4.0 with the DNS service enabled. The boot file will be changed to indicate the new information such as names and IP addresses of the zones.
The database resource records will be changed to reflect these changes such as where zone files are located, the location of primary and secondary databases and static information about other DNS servers that are not running the Windows NT Server 4.0 DNS service.
The static resource records of the servers which are not Windows NT Server 4.0 DNS servers will be added or updated as necessary to ensure that all DNS servers are checked for name resolution.
The servers running Windows NT Server 4.0 DNS service will be enabled to participate in WINS Lookup.

Integrating the Retail DNS System with Windows NT Server DNS Service

For Retail.Terraflora.com, the plan is different. A server running Windows NT Server 4.0 DNS Service will be added as a secondary server to the existing DNS Zone which is installed on a computer not running Windows NT Server. The performance of Windows NT will be measured.

A key feature of the Windows NT Server 4.0 DNS is the WINS Lookup feature. The Retail.Terraflora.com zone will be split. A new subzone called NT.RetaiI.Terraflora.com will be set up on computers running Windows NT Server DNS service. The servers in the new subzone will be WINS lookup enabled. Migration to the servers running Windows NT Server DNS service will take place over the next several months. As applications requiring DNS services are changed, the DNS services will be moved to the servers running Windows NT Server 4.0 DNS. The following steps will be followed:

Windows NT Server 4.0 DNS Service will be installed on all servers in the new split zone which will be created as NT.Retail.Terraflora.com.
Using the graphical tool, all the Windows NT Server 4.0 DNS servers will be added to the Windows NT Server 4.0 DNS system, allowing administration from any server running Windows NT Server 4.0 DNS service.
The new NT.Retail.Terraflora.com subzone will be configured as a primary and secondary zone. The secondary zone is a replicated copy of the primary subzone database.
NS and A resource records will be added to the NT.Retail.Terraflora.com Windows NT Server 4.0 DNS database pointing to the Terraflora.com Windows NT Server 4.0 DNS database for name resolution.
NS records will be added to the Terraflora.com Windows NT Server 4.0 DNS database pointing to the NT.Retail.Terraflora.com Windows NT Server 4.0 DNS database for name resolution.
Static NS and A records will be added to the zone file for NT.Retail.Terraflora.com for all DNS servers that are running an operating system other than Windows NT Server 4.0 and for all workstations that are not Windows NT, Windows 95, Windows for Workgroups, and LanMan 2.x.
All Windows NT Server 4.0 DNS servers will be WINS enabled.

Installing DNS Service

DNS is one of the Windows NT Server services. The instructions below assume you have already installed the Windows NT Server operating system. Terra Flora will install the DNS service on all computers running Windows NT Server service that will provide DNS services.

To install the DNS service

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Services tab.
Click Server, and then click Add.
In the Network Services dialog box, click Microsoft DNS Server, and then click Have Disk if loading the software from disks or a CD.

Or, select OK if loading from the network.
In the Windows NT Setup dialog box, type the full path to the Windows NT Server DNS files, and then click OK.
In the Network Settings Change dialog box, click Yes to restart the computer and complete the DNS installation.

Note: You must be logged on as a member of the Administrators group to install a DNS server.

Managing DNS Servers

Once a Windows NT Server DNS server is installed, DNS Manager is added to the Administrative Menu. Using DNS Manager, the administrator can add servers running Windows NT Server 4.0 DNS service to the server list. Once added, the administrator can view and change parameters of any of the Windows NT Server 4.0 DNS servers in the list.

To open the DNS Manager

Click Start, point to Programs, point to Administrative Tools, and click DNS Manager.

The Domain Name Service Manager window appears.

Add All Windows NT DNS Servers to the Server List

All of the servers running Windows NT Server 4.0 DNS service on the network can be administered and managed from any single computer running Windows NT Server DNS service, through the DNS Manager interface. To do this, the administrators at Terra Flora will add the servers to the server list using the DNS Manager interface. DNS features will not be available on any of the computers running Windows NT until the server is added to the server list.

To add a DNS server

In Domain Name Service Manager, click Server List.
On the DNS menu, click New Server.

The Add DNS Server dialog box appears.
In DNS Server, type the IP address of the DNS server to be added to the server list, and then click OK.

The server appears in the server list in Domain Name Service Manager.

Copy the Files

Three of the four existing zones will be moved to servers running Windows NT Server 4.0 DNS service.

The administers at Terra Flora will remove the appropriate zone, boot and cache files from the system servers which currently store the zones of Terraflora.com, Nursery.Terraflora.com and Supply.Terraflora.com. The files will then be placed in the SystemRoot\System32\DNS directory of the proper new server running Windows NT Server 4.0 DNS service which will, from that point forward, store the zone information.

The Terra Flora administrator will use the editor that they are familiar with to change the information about the zones in the boot file as appropriate.

Once the files are in the proper directory, the zone's structure can be viewed using the DNS Manager graphical interface. The administrators will be able to view the structure of the Nursery.Terraflora.Com and Supply.Terraflora.Com and Terraflora.Com zones.

Creating the New Zone

A zone is the administrative tool for information about the DNS domains. At Terra Flora, Terraflora.Com is the main authoritative DNS domain and the root zone. Three additional zones called Nursery.Terraflora.Com, Supply.Terraflora.Com and Retail.Terraflora.Com exist at Terra Flora. At Terra Flora, three of the zones have been moved to computers running Windows NT DNS Service. See the previous section "Copy the Files" for details.

Because of the mission critical nature of the applications in the retail division, the Retail.Terraflora.Com zone will be maintained. A fifth zone will be created to split the Retail.Terraflora.Com zone. This fifth zone will include only servers running Windows NT Server 4.0 DNS server. The zone will be set up as both primary and secondary in order for replication of the resource record database to take place. Two servers will store the zone information, one will store the primary zone information and one will store the secondary zone information.

To add the primary NT.Retail.Terraflora.Com zone

In Domain Name Service Manager, click the server for which you will be creating the zone.
On the DNS menu, click New Zone.

The Create new zone forIP address of the server selected dialog box appears.
Click Primary.
Click Next.
In Zone Name, type the name of the root domain within the zone.
If necessary, type the name of the database file in which you want the DNS resource records to be stored in Zone File.
Click Next.
Click Finish.

An SOA (Start of Authority) record is created in the database file entered in step 7. The SOA record indicates the Name Server which is the best source of information for supplying name resolution data.

NT.Retail.Terraflora.Com will also be set up as a secondary zone and the server assigned will be different than the one assigned for the Primary zone. If the server that stores the primary zone goes down, the server storing the secondary zone will be used for name resolution.

Selecting Primary as a zone type indicates that the zone does not obtain it's resource records from any other zone, the DNS Administrators are required to add, delete and modify all necessary resource records to the primary zone files.

The root domain is a DNS domain with multiple sections, each with a maximum of 63 characters and separated by a period (.). The zone name must be unique. The zone name will be NT.Retail.Terraflora.Com.

The default name of the Zone File will be the same name as entered in the Zone Name field.

To add the secondary NT.Retail.Terraflora.Com zone

In Domain Name Service Manager, click the server for which you will be creating the secondary zone.
On the DNS menu, click New Zone.

The Create new zone forIP address of the server selected dialog box appears.
Click Secondary as the Zone Type.
In Zone, type the name of the zone.
In Server, type the name of the server on which the primary zone information is stored, and then click Next.

The secondary zone name appears in Zone Name.
In Zone File, type the name of the secondary database file you want the DNS resource records to be stored in, and then click Next.
Click Add, and enter the IP address of the IP Master, which is the server on which the primary zone information is stored.
Click Next.
When a message appears, confirming that all the information for the new zone has been entered, click Finish.

Selecting Secondary as the zone type indicates that the zone obtains its resource records from the primary zone. This means that the DNS Administrators are required to add, delete, and modify all resource records in the primary zone and not this secondary zone.

At Terra Flora, the zone name will be NT.Retail.Terraflora.Com, matching the primary name. The name should always be the primary zone name. When the secondary server starts, a query will be sent to the server specified as the IP Master for the zone file with the same primary name.

The default name in Zone File will be the name you entered in Zone Name.

Each secondary zone must have at least one IP master. You can add more than one IP master and move them in the list using the Move Up and Move Down buttons.

Adding and Changing Database Resource Records

During the process of creating the new NT.Retail.Terraflora.Com zone, Terra Flora specified the database file name and database server which would store the zone's database information. Resource records need to be added to the zone's database file that will indicate how computer names will be resolved.

Terra Flora has configured the DNS system so that when a client requests an IP address from the DNS server, the server on which the zone file for Terraflora.Com resides is examined first. If the name cannot be resolved within the Terraflora.Com file, the request is then forwarded to the servers on which the zone files for Retail.Terraflora.Com, Nursery.Terraflora.Com, and Supply.Terraflora.Com reside.

The resource records implementing this lookup already exist in all zones, except for the new NT.Retail.Terraflora.Com zone which was just created. New resource records must be put in the two zones Terraflora.Com and NT.Retail.Terraflora.Com.

Additionally, the resource records that exist in Nursery.Terraflora.Com and Supply.Terraflora.Com must be changed to reflect the information about the new server that now stores the zone files for Nursery.Terraflora.Com and Supply.Terraflora.Com.

The resource records that will be added to or changed for each of the zones are described below:

Terraflora.Com

An A (Address) record will be added supplying the host name and host address of NT.Retail.Terraflora.Com, which will indicate to other DNS servers and to the primary server storing the Terraflora.Com zone database file to search the NT.Retail.Terraflora.Com zone database file to resolve the clients name requests.

An NS (Name Server) record will be added supplying the DNS Name Server name for the NT.Retail.Terraflora.Com zone, which will indicate to other DNS servers and to the server storing the Terraflora.Com zone database file to search the zone database file of NT.Retail.Terraflora.Com to resolve the request.

The NS (Name Server) records will be changed to indicate the new DNS Name Server information for the Nursery.Terraflora.Com and Supply.Terraflora.Com zones.

Other records can be added as necessary by the Terra Flora administrators, but these records are key in resolving name requests.
NT.Retail.Terraflora.Com

An A (Address) record will be added supplying the host name and host address of NT.Retail.Terraflora.Com to indicate to other DNS servers that the information stored in the NT.Retail.Terraflora.Com database should be examined for name resolution.

An NS (Name Server) record will be added supplying the DNS Name Server name for the NT.Retail.Terraflora.Com zone to indicate to other DNS servers that the information stored in the NT.Retail.Terraflora.Com database should be examined for name resolution.
Supply.Terraflora.Com and Nursery.Terraflora.Com

The NS (Name Server) records will be changed supplying the new DNS Name Server name for the Supply.Terraflora.Com and Nursery.Terraflora.Com zone to indicate to other DNS servers that the information stored in the two zones should be examined for name resolution.

Other records can be added as necessary by the Terra Flora administrators, but these records are key in the continued use of DNS at Terra Flora.

To add a database resource record

In Domain Name Service Manager, click the zone for which you will be creating the new record.
On the DNS menu, click New Record.

The New Resource Record dialog box appears.
In Record Type, click the record you want to add.

The dialog box changes, depending on which type of record you selected. For example, the For Domain name that is the zone name appears when you specify an NS record.
Under Value, type the necessary information, such as the Name Server DNS Name for NS records, which specifies the server name that will be used to resolve name requests.
Click OK.

To change a database resource record

In Domain Name Service Manager, click the server that stores the zone with which you want to work.
Click the zone that contains the record you want to change.
In Record forzone name, click the record type you want to change.
Double-click the record to be changed.

The dialog box changes, according to the kind of information required. For example, the Terra Flora administrator would type the name of the server which will now store the zone information for Nursery.Terraflora.Com in Name Server DNS Name.
To change another database resource record, repeat these steps.

For example, at Terra Flora, the administrator would repeat this procedure for Supply.Terraflora.Com.
When finished making changes, click OK.

At Terra Flora, the database resource records will need to be reviewed and changed as necessary.

In the case of Terraflora.Com, the administrator will be changing the NS record for Nursery.Terraflora.Com and Supply.Terraflora.Com. Consequently, the administer would complete the procedure for one record to step 5 and then repeat the procedure for the other record.

Static DNS Server Resource Records

At Terra Flora, there are DNS Servers that are not running Windows NT Server 4.0 in the Retail.Terraflora.Com zone that will be added to the zone files residing on the servers running Windows NT Server 4.0 DNS service. The static entry of the DNS servers ensures that all DNS servers will be searched in an attempt to map name and IP addresses. An A (Address) and NS (Name Server) resource record will be added to each zone for each DNS server that is to participate in name resolution.

WINS Lookup

When a server running Windows NT Server 4.0 DNS Service receives a DNS request to resolve a specified DNS name to an IP address, it will search its A (Address) resource records until it finds one whose DNS name matches the one specified in the request. It then returns the IP address stored in that A (Address) resource record to the requesting computer.

If the server cannot locate an A (Address) resource record for the requested DNS name, and if Use Wins Resolution is enabled, the DNS server will extract the host name, which is the text of the name, on the left hand side of the name, up to the first period, and send a request to a the specified WINS server asking it to map the host to an IP address. If the name was registered with WINS, WINS will return the associated IP address to the DNS server and the DNS server will return it in response to the original DNS request.

Any number of WINS servers can be specified for fault tolerance purposes. The server running Windows NT Server DNS service will try to locate the name by searching the WINS servers in the order listed.

To enable WINS Lookup

In Domain Name Service Manager, click the zone for which you will be enabling WINS Lookup.
On the DNS menu, click Properties.
In the Zone Properties dialog box, click the WINS Lookup tab.
Select the Use WINS Resolution check box.
Under WINS Servers, type the WINS Server IP address that will be used for resolution.
Click Add.

You can repeat the procedure to add as many WINS servers for resolution as needed.

Integrating DHCP, WINS, and DNS in Heterogeneous Networks

Terra Flora has a difficult mix of disparate network operating systems, supporting multiple protocols, and different services with various administration tools. Most of them can support the TCP/IP protocol, and many of them can be dynamically configured with their IP address via the Dynamic Host Configuration Protocol, or DHCP.

However, there are legacy UNIX servers, and other network devices that use static IP addresses, and use the Domain Name Space (DNS) services to provide hostname-to-IP-address resolution. Therefore, they need to have a DNS servers in the environment as well.

The long range goals at Terra are to be able to handle an expanding network, and reduce costs. In addition, the types of network clients are changing, with portable and fully mobile networking requirements that break the previous networking models, and exceed the capabilities of the existing administrative mechanisms.

With that understanding, it becomes clear that Terra Flora needs to deploy DHCP services in their network environment to address the dynamic nature of the network clients and reduce the administrative costs of assigning and updating the host table information on the DNS servers. As DHCP only provides the dynamic IP address leasing, WINS services must also be deployed to provide the name resolution for these dynamic network clients. However, due to the presence and limitations of the existing legacy systems in the network, Terra Flora must continue to support DNS as well.

In order to meet the objectives, Terra Flora will deploy DHCP, WINS, and DNS services in their network environment. However, this does not mean that these technologies are islands unto themselves, where clients or servers using DNS can only access machines in the traditional DNS host tables, or where DHCP and WINS clients can only access computers similarly configured.

Windows NT Server 4.0 includes integrated name resolution server components, which allows both DNS and WINS-based clients to resolve names from both types of clients, while minimizing the impact on the existing network infrastructure.

Using Windows NT Server 4.0 and integrating WINS, DNS and DHCP, the process of name and IP resolution becomes basically dynamic. A computer running Windows NT 4.0 will have a NetBIOS name. If a Windows NT, Windows 95 or Windows for Workgroups client sends a request for the IP Address location of a computer AshleyJ.Terraflora.com, and both computers are DHCP, WINS and DNS configured, the process of mapping the IP Address to the NetBIOS computer name of Ashleyj is as follows:

A DHCP, WINS and DNS client computer requests the IP address of the NetBIOS named computer Ashleyj.
The computer Ashleyj receives an IP address when it first starts up from DHCP.
The IP address is registered with the WINS server, mapping the name Ashleyj to the IP address.
The DNS server is able to resolve the Terraflora.Com portion of the name as a zone known to the WINS server.
In configuring the Windows NT Server 4.0 DNS server, WINS servers were specified and associated to the zones. The NetBIOS portion of the name, which is the text up to the first period '.', will be sent by the server running Windows NT Server 4.0 DNS Service to the specified WINS servers.
The WINS servers will be examined for the friendly name Ashleyj and the IP address. This information is sent back to the server running Windows NT Server 4.0 DNS service and then forwarded to the original requesting computer.

Network Logon Services

At Terra Flora, the logon services provided by the Windows NT operating system were selected to provide centralized network logon. This decision was made because Windows NT Server is the only product that provides the capability to log onto all the heterogeneous networks at Terra Flora. The Windows NT Server product provides users with the capability to sign onto all appropriate network resources using a single user account and password.

Note: Password synchronization between network operating system platforms is not automatic for all platforms, but is a future technology for Windows NT Server (ODSI).

The Decision to Centralize Logon Services

Modern network server operating systems track user accounts in a secure and replicated database called a directory. The operating system services that facilitate the use of this database are called Directory Services. A domain is the administrative unit of Windows NT Server Directory Services. Within a domain, an administrator creates one user account for each user which includes user information, group memberships and security policy information.

Refer to the Terra Flora network diagram. At Terra Flora, three domains have been set up. They are the California Domain, the North East Domain and the Europe Domain.

Within each domain, domain controllers manage all aspects of user-domain interactions. Domain computers are computers running Windows NT Server that share one directory database to store security and user account information for the entire domain. Domain controllers use the information in the directory database to authenticate users logging on to domain accounts. Trust relationships are then set up between the domains to allow users in one domain to logon automatically to another domain. For details on how to manage the user work environment and domains, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User Group Accounts" and Chapter 3, "Managing User Work Environments."

Currently, each of the heterogeneous networks in Terra Flora has its own security system through which the user signs onto the system and is authenticated to use the resources for which permissions are granted. One of the major complaints of network users is that they have to use multiple user accounts and passwords to sign onto different networks. Additionally, because there was no communications between networks, the users are required to log off one network to log onto another network.

At Terra Flora, the following steps have already been completed:

PDC and BDCs for each Windows NT administrative domain have been properly configured. For details, see Start Here Installation and Basics Microsoft Windows NT Server, Version 4.0 and Microsoft Windows NT Server Concepts and Planning.
The networks have been physically connected.
User have been granted proper permissions and network access to all required network resources. For details on how to manage the user work environment and domains, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User Group Accounts" and Chapter 3, "Managing User Work Environments."

Following the steps in the remainder of the chapter will provide the user with the ability to logon onto the network from any computer in the network and, if the accounts, passwords and permissions have been granted on all network platforms, will provide access to all the user's required network resources.

For the user, the single network logon will provide transparent, seamless access to the network resources. For example, a NetWare user will logon as usual to the NetWare network and be authenticated to the Windows NT network at the same time. It will just happen and the user will not know that a different network has been accessed. An additional benefit to the user is the ability to sign onto all appropriate network resources from any computer on the network.

For Terra Flora, this consistent interface helps to easily integrate the business processes available through applications stored on servers on different networks, reduces training and reduces support costs as it all appears to the user as the same network system, and reduces the administration costs associated with setting up and maintaining separate logon accounts and passwords on each separate network.

The following sections include information on installing and configuring network logon services to allow authentication of:

UNIX Clients to Windows NT Servers
Windows NT Clients to UNIX Servers
Windows NT Clients to NetWare Servers
NetWare Clients to Windows NT Servers
Windows NT Clients to Banyan Servers
Windows 3.1 Clients to Windows NT Servers
MS-DOS Clients to Windows NT Servers
Windows for Workgroups Clients to Windows NT Servers
Windows 95 Clients to Windows NT Servers
Macintosh Clients to Windows NT Servers

UNIX Clients Authenticating to Windows NT Servers

The UNIX operating systems support the Network File System (NFS). Terra Flora's Retail Services division uses as its primary divisional server a Sun server running the Solaris UNIX operating system. User names and passwords for authentication to the UNIX server are stored on the UNIX server, named CASUN25ENT01, (refer to the Terra Flora diagram) on the /etc directory in the Passwd file. At Terra Flora, a third party product by Intergraph called DiskShare will be installed on servers running Windows NT Server to allow UNIX clients access to Windows NT Servers.

Once Intergraph DiskShare is installed and configured, the existing UNIX /etc/Passwd file will be imported to the WINNT\System32\Drivers\Etc directory. Intergraph DiskShare provides a graphical interface through which the administrators can edit the password file. DiskShare provides a way to map UNIX names and passwords to the Windows NT user accounts and passwords so that UNIX users can have the same permissions as the Windows NT users to which they are mapped. Once the mapping is complete, users signing on to the Windows NT network will be simultaneously authenticated to the UNIX network.

Installing Intergraph DiskShare

Documentation is provided with the product. For installation instructions, see the Intergraph DiskShare Quick Start Guide. Additional information is provided in online Help files.

See the documentation accompanying the product for details on the various options provided.

Editing the Password File

The Passwd file is where the UNIX authentication information is stored. Using the graphical interface, administrators can add, change or delete the User Name, the User ID (UID), the user's group ID (GID) and the password.

The first step is for the administrator to copy the Passwd file from the /etc directory on the UNIX server to the WINNT\System32\Drivers\Etc directory on the computer running Windows NT Server. Once the file is in the right directory on the computer Windows NT server, it can be accessed by DiskShare to allow the necessary administration.

To access the Password File Editor

Click Start, point to Programs, and click DiskShare Server.
On the Server menu, click Password File Editor.

The Password File Editor dialog box appears.
In Password File Entries, click the user you want to change or delete.

Type the appropriate information for the user name, user UID, user GID, and password in the spaces provided, and then do one of the following:
- To add the user, click Add.
- To enter changes for the user, click Change.
- To delete the user, click Delete.

Mapping UNIX Passwords to Windows NT User Accounts

At Terra Flora, all user accounts, passwords and permissions have been set up on the computers running Windows NT Server. For details see, Microsoft Windows NT Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

Additionally, the UNIX /etc/Passwd file has been copied to the proper Windows NT directory WINNT\System32\Drivers\Etc, which makes it accessible to the graphical interface supplied in Integraph's DiskShare. The entries in the UNIX password file will be mapped or matched to user accounts created in Windows NT domains.

Mapping the UNIX user accounts and passwords to a Windows NT User account grants the UNIX user the same rights and permissions to the Windows NT server as the Windows NT user to whose account the UNIX account is mapped.

Note: If the name and password are exactly the same in the UNIX /etc/Passwd file as that stored in the Windows NT Directory Database, mapping is automatic.

Without mappings, server resource access will default to whatever privileges are given to the Everyone user trying to access the group. See your UNIX documentation for more details on UNIX privileges.

To administer UNIX-to-NT user mappings

Open the NFS Administrator.
Click Mappings.

In the User Mappings dialog box, the users that are currently mapped are listed in NFS Mapped Users.
In Network Users, click the UNIX user to be mapped to the Windows NT user.
In NT Users, click the Windows NT user to which you want the UNIX Network user mapped.
Click Add.

The mapping appears in NFS Mapped Users.

Additional information that appears in the NFS Administrator window includes:

Network Users, which list user names and user IDs (UIDs) in the format: network user name:UID. This information comes from the UNIX-style password file.
NT Users, which lists Windows NT user accounts that are local to the domain controller of the specified NT domain.
List Names From Domain, which lists all NT domains to which the local machine has access. It includes the local machine name, the primary domain, and any domains that trust the primary domain.

Note: Changes made in this dialog box do not take effect until you click OK, to write the new information to the registry.

Online Help is part of the DiskShare product and explains mapping, such as how to map Windows NT User Groups to UNIX Groups and perform reverse mappings. These sections focus on administrative tasks specific to the Intergraph PC-NFS and DiskShare products.

Note: Sharing and unsharing of NFS directories and files requires the same user permissions required by Windows NT Server and LAN Manager. The local user account must be logged on as a member of the Administrators, Server Operators, or Power Users groups.

Sharing NFS Server Resources

Two separate and complimentary mechanisms govern file access through the NFS server. The first is the NFS administrator's ability to control both which server resources are made available as network resources and what access clients within the network will have to the data. The second is the security administration performed by the underlying server file system itself. Effective access permission granted to any user is the more restrictive of these two mechanisms.

Share permissions are the first line of defense for the NFS server. Using share permissions, an administrator can control which network NFS client nodes have read and/or write access to NFS Shared resources. Four levels of access are available depending on the type of object selected, as follows:

No Access

This prevents all mount or connection requests for the share except for those individual client nodes or client groups that have a type of access specified.
Read-Only

The client is allowed to mount and read the shared resource, but cannot alter it.
Read-Write

The client may mount, read and write the shared resource.
Root

The client may mount, read, write, and perform "superuser" type operations on the file system assuming the requesting User ID is correct for the operation, and that is maps to the Administrator privilege. This access level can only be assigned to individual client nodes or client groups.

To determine if sufficient permission is available for the NFS request, the Global Permission is checked first. If this is not sufficient, an individual client's permission entry is checked. If no individual client permissions are present, then permission is given based on client group access.

File permissions within NFS are very much like those in a UNIX system. Under UNIX, every file belongs to a single user and group; the user must be a member of the group that owns the file. More precisely, a file has a single user ID and a single group ID. Because several different user accounts can have the same user ID, and several groups the same group ID, it may be ambiguous to speak of a particular user or group. The following criteria, in order of decreasing precedence, govern access to files:

Access granted to the owner of the file, a user with the same effective user ID as the file owner ID.
Access granted to members of the group to which the file belongs, users can belong to several groups simultaneously.
Access to granted to all others, such as those who do not own the file and are not members of the group to which the file belongs.

Each permission category controls three modes of access:

Read, which is the ability to open the file for read access and examine its contents without altering it in any way.
Write, which is the ability to open the file with write access and update its contents.
Execute, which is the ability to load the file into the system and run it. For directory files, execute access is interpreted as search permission.

Understanding the Security Descriptor

Intergraph DiskShare uses the Windows NT security descriptor when implementing NFS access permissions. The security descriptor is the structure that governs security within Windows NT. The security descriptor contains the following components:

File owner.
File group.
System Access Control List (SACL). The SACL is used for auditing and does not affect file permissions.
Discretionary Access Control List (DACL).

The following is an example of a security descriptor:

Owner:	spike
Group:	UtilGroup
DACL:	spike	Read (R)
UtilGroup		Read (RX)
Everyone		Read (RX)

In this example, the file owner is spike, the file group is UtilGroup, and the DACL shows the permissions given to spike, UtilGroup, and Everyone.

Within the security descriptor, the file owner and file group are pointers to Security Identifiers (SIDs). The SID can be thought of as the internal representation for an individual user or group. The primary reason for using SIDs is to distinguish between accounts across different domains that may share the same account name. Even though the names are the same, they represent different accounts and can thus be given different access rights to the same file.

Understanding the DACL

The Discretionary Access Control List (DACL) within the security descriptor provides the core of Windows NT security. The DACL is a list of entries that grants or denies certain rights to specific users or groups. A list entry is called an Access Control Entry (ACE). Each ACE consists of the following:

A Security Identifier (SID) to identify a particular user or group.
An access list specifying the rights allowed or denied for the user or group.

The following is an example of a DACL:

DACL:	mrjones	Full Control (All)
ToolGroup		Read (RX)
Everyone		Read (RX)

In this DACL, mrjones has read, write, and execute access to the file; members of the group ToolGroup have read and execute access, and members of the group Everyone (all other users) have read and execute access.

The following rules govern access to a file:

If no DACL is present, everyone is granted full access.
If a DACL is present, but contains no entries, everyone is denied any access.
The file owner always has the ability to change the DACL.

Reverse Mapping Permissions

The function of Intergraph DiskShare is to translate between a security descriptor on the computer running Windows NT Server and Intergraph DiskShare and a (UID, GID, mode) triplet on the NFS client.

Intergraph DiskShare controls permission translation with reverse mapping. Intergraph DiskShare's NFS Administrator program allows the DiskShare administrator to specify a mapping between NFS User and Group IDs and their corresponding Windows NT users and groups.

A given UID can be mapped to any Windows NT user.

Because multiple UIDs can be mapped to the same Windows NT user, one of the mappings will be marked as the default mapping. The default mapping is the UID to be returned when the mapped Windows NT user is found to be the file owner.

If the given UID is not mapped, the ANONYMOUS LOGON account will be used. This can have some undesirable results, so we recommend that all UIDs be mapped to a valid Windows NT account.
A given GID can be mapped to any Windows NT group.

Note: If the given GID is not mapped, no group will be assigned, and no group entry will be placed in the DACL.

You can use the reverse mapping feature when mapping from NFS to Windows NT, or from Windows NT to NFS.

Sharing Files and Directories on a NFS Server

Once the DiskShare product is installed, the ability to share the NFS server files and directories and grant permissions to the users is provided through the computer running Windows NT Server.

To share files and directories on a NFS Server

Click Start, and then click Run.
In Open, type winfile, and then click OK.
On the Disk menu, click Share as.
Click NFS, and then click OK.
In the New NFS Share dialog box, type the path of the file you want to share.
Click Permissions.

The NFS Share Permissions dialog box appears.
Enter the settings you want for Anonymous UID and Type of Access, and then click Add.
Under Names in the Add Clients and Client Groups dialog box, click the user to be granted access.
In Type of Access, click the setting you want, and then click OK.

UNIX Client Sign On

Once the above steps are performed, the UNIX client is mapped with the proper permissions to the computer running Windows NT Server. When the UNIX client signs onto the server, authentication is provided via pcnfsd on the UNIX server to Windows NT User Account.

From the UNIX client, create a local directory as a mount point. Then mount the exported directory to a local directory.

Windows NT Clients Authenticating to UNIX Servers

At Terra Flora, a third party product called Intergraph PC-NFS for Windows NT will be installed on all computers running Windows NT Workstations and client computers running Windows NT that need access to UNIX servers. When the Windows NT client computer starts, a login screen will display. The user logs into the NFS authenticating server and can access the resources for which permissions have been granted.

A new product called Intergraph DiskAccess will replace the product Intergraph PC-NFS for Windows NT. It is scheduled to ship 30 days after the Windows NT Server 4.0 product ships. The current product of Intergraph PC-NFS for Windows NT can be used with server versions of the Windows NT product which proceeded the 4.0 version, and operates fine with version 4.0. The major difference between Intergraph's DiskAccess and PC-NFS will be changes to the graphical interface.

The users at Terra Flora have been granted permissions and the user accounts and passwords have been entered in the /etc/Passwd file of the authenticating UNIX server.

Installing Intergraph PC-NFS for Windows NT

Intergraph PC-NFS for Windows NT is to be installed on the computers running Windows NT Workstation and Windows NT Server, which will require client access to UNIX servers. For instructions on installing Intergraph PC-NFS for Windows NT, see the documentation provided with the product titled PC-NFS for Windows NT Quick Start Guide. Once installed, the product provides File Manager functions, a Control Panel-based configuration program and various utility programs.

Configuring PC-NFS

Configuration of the product can be performed to customize PC-NFS to fit your network environment.

To start PC-NFS Config

Click Start, point to Settings and click Control Panel.
Double-click PC-NFS Config.

See online Help for details about using PC-FNS Config.

Logging onto a UNIX Server Using PC-NFS

Once the above steps are complete, computers running Windows NT Workstation and Server that will require client access to UNIX servers can logon to Windows NT and be authenticated to the UNIX servers in the same step. When a user logs into the system and starts a Windows NT session, by default the PC-NFS Login dialog box appears to indicate that PC-NFS software is running.

Authentication establishes UNIX-style user and group permissions for UNIX clients on the network and is necessary if the NFS server restricts entry by user name. You do not have to use the PC-NFS Login dialog box to log in to the server before connecting to network-based NFS resources. However, if you do not do so, you may find that an NFS server restricts or denies access to some or all of its resources.

To log on as a Windows NT client to a UNIX server

Click Start, point to Programs, point to PC-NFS for Windows NT, and then click PC-NFS Login.
In PCNFSD, type the name of the NFS authenticating server.

This can be any computer running NFS, such as a UNIX server for which the user has permissions.
In Username, type your user name for login purposes.
In Password, type your password.
Click Log In.

Mounting Remote Resources

To mount or connect to a resource, use the Windows NT Explorer. Remote NFS resources mounted through PC-NFS software appear as virtual disk drives on your computer and display as network drives in Windows NT Explorer.

To Mount Remote Resources

Click Start, point to Programs, and then click Windows NT Explorer.
On the Tools menu, click Map Network Drive.

The Map Network Drive dialog box appears.
In Drive, click the drive you want to use.
In Path, type the path to the remote device to which you want to attach.
To map to another network drive using a different user account or group account ID, enter than information in Connect As.
Click OK.

Windows NT Clients Authenticating to NetWare Servers

On Terra Flora's network, there are existing installations of Novell NetWare, which are primarily used for file and print services. User accounts and privileges are stored in the NetWare Bindery, which is Novell's equivalent of the Windows NT directory. Access is validated based on user accounts and passwords in a Windows NT domain via the directory database, or on a Novell NetWare server via the bindery.

Novell uses the IPX/SPX protocol as their primary network protocol. In order for Windows NT Workstations or Windows NT Servers to communicate with the NetWare services, Microsoft developed NWLINK, an IPX/SPX-compatible protocol. NWLINK is the fundamental building block for the NetWare-compatible services on the Windows NT platform, and by itself, NWLINK does provide connectivity for database access to databases running as NetWare Loadable Modules on NetWare servers. So, for example, a Visual Basic application running on Windows NT Workstation can access an Oracle database running on a NetWare server, through ODBC and the NWLINK components.

Client Service for NetWare (CSNW)

The Client Service for NetWare installed on a computer running Windows NT Workstation provides basic file and print connectivity for that client to a NetWare 3.x server, or a NetWare 4.x server which includes the functionality of CSNW on the server platform. A different service, Gateway Service for NetWare (GSNW), provides access for computers running Windows NT Server to NetWare Servers.

To add CSNW

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Services tab.
Click Add.
Click Client Services for NetWare, and click OK.
Type the path to the CSNW files, and click Continue.
In the Client Services for NetWare Dialog box, type the name of the NetWare Server that will be used for authentication, click OK, and then click Close.

You must restart the computer to complete the installation. Click Yes and the computer will restart to complete the process.

Configuration of CSNW is necessary for the Windows NT Client to be able to connect to the NetWare server. A preferred server is selected when the CSNW service is added to the computer running Windows NT Workstation. In addition, as a result of adding CSNW, a CSNW icon is added to the Control Panel.

To activate and configure CSNW

Click Start, point to Settings, and click Control Panel.
Double-click CSNW.
In the Current Preferred Server dialog box, select a server, if necessary, and then click OK.

The Preferred Server setting performs the Attach command to the NetWare server and thus provides authentication to the NetWare server providing that the user and privileges have been added to the NetWare Bindery on the server that the user is trying to access.

Gateway Service for NetWare (GSNW)

The Gateway Service for NetWare (GSNW) provides computers running Windows NT Server all support necessary to connect to NetWare servers, plus the additional capability to re-share the network connections from a NetWare server. The service allows the computers running Windows NT Server to access the NetWare servers as if they were just another client and, in addition, allows the network clients to access files on a NetWare server without having to have a NetWare client redirector on an IPX/SPX protocol stack loaded.

Gateway Service for NetWare depends on and works with two other NetWare compatibility features of Windows NT Server; the NWLink protocol, and NWLink NetBIOS. NWLink is an implementation of the internetworking packet exchange (IPX) and sequenced packet exchange (SPX) transport protocols used by the NetWare network. NWLink NetBIOS is a Microsoft-enhanced implementation of Novell NetBIOS, and transmits Novell NetBIOS packets between a NetWare server running Novell NetBIOS and a Windows NT computer, or between two Windows NT computers. The Microsoft implementations of the IPX, SPX, and Novell NetBIOS compatible protocols can seamlessly coexist with other protocols on the same network adapter card.

The computer running Windows NT Server establishes a network connection to the NetWare server, similar to any network client connection.

Gateway Service for NetWare is installed from the Windows NT Server CD-ROM.

Note: Before you install the Gateway Service, you must remove any existing NetWare redirectors, such as NetWare Services for Windows NT from Novell, and then restart your computer.

To remove existing NetWare redirector installations

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Services Tab.
Click the existing NetWare redirector software, and click Remove.
When prompted to confirm your choice, click Yes.

You must restart your computer to complete the removal process.

You are now ready to install the Gateway Service on a computer running Windows NT Server. You must be logged on as a member of the Administrators group for the local computer to install and configure the Gateway Service for your Windows NT computer. When you install the Gateway Service on a computer running Windows NT Server, the NWLink transport protocol is also installed if it is not already on your computer.

Activating a Gateway

Before enabling a gateway on a computer running Windows NT Server:

A user account must be set up on the NetWare network with the necessary rights for the resources you want to access.
The NetWare server must have a group named NTGATEWAY with the necessary rights for the resources you want to access.
The NetWare user account you use must be a member of the NTGATEWAY group.

By controlling membership in the NTGATEWAY group, the administrator can control which Windows NT Server computers can be gateways to the NetWare server, and what kind of access to what files each user account has.

The administrator has total control over whether the gateway allows access to files and print queues on the NetWare server. With a gateway, the network administrator can control access to NetWare network resources either over the gateway or directly on the NetWare network:

On the Windows NT Server computer acting as a gateway, the administrator can restrict access by limiting which network users or groups have access to gateway shares. Using multiple share restrictions through a gateway, the Windows NT administrator can control which network users and groups can access files through the gateway.
Using NTGATEWAY special gateway group created on the NetWare file, the administrator can set trustee rights on the directories and files to which users and groups are allowed access through the gateway. There is no auditing of gateway access.

To make a NetWare server available to a gateway account

Use the NetWare syscon utility to create the NTGATEWAY group account on the NetWare file server.
Use syscon to create a NetWare user account with the same name and password the user will use to log on from the Windows NT Server computer.
Add the gateway account to the NTGATEWAY group.
Establish trustee rights for the NTGATEWAY group.

For detailed information on the syscon utility and NetWare user accounts and trustee rights, see your NetWare documentation.

If you want to control user access, you can set permissions for the share when you create it, or later if your needs change.

Install Gateway Services for NetWare

Once the user gateway and information is added to the NetWare server, you are ready to install GSNW on the computer running Windows NT Server.

To install GSNW

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Services tab.
Click Server, and then click Add.
Click Gateway Services for NetWare, and click OK.
Type the path to the source files, and click Continue.
In the Gateway Services for NetWare dialog box, enter the name of the NetWare server to which the computer running Windows NT Server will connect.
Click Gateway.
Select the Enable Gateway check box.
Type the NetWare user account created to logon to the NetWare server from a computer running Windows NT Server, and click Add.
In the New Share dialog box. type the Share name of the gateway on the NetWare server.
Type the full path to the new share on the NetWare server.
Type an entry in Comment, if you want one.
Enter a letter for the drive on which the new share will reside.
If necessary, enter a value to limit the number of users.
Click OK.

The GSNW option is added to Control Panel and is used to activate the gateway.

Limitations of the Gateway Service for NetWare

GSNW is not designed to be a high bandwidth, user intensive, high performance gateway. It is designed to meet the needs of the customers who desire to have casual access to files that exist on a NetWare server, from a Windows Networking, or remote client.

Accessing Shared Resources on the NetWare Server

To access shared resources on a NetWare server, use the Map Network Driver option in the Explorer. You can map to both print and file servers. Again, this assumes that the proper privileges are assigned to the user when the connection is attempted.

To access shared resources

Click Start, point to Programs, and click Windows NT Explorer.
On the Tools menu, click Map Network Drive.
In Drive, confirm that the drive displayed is the one that is mapped to the server you want to access.
In Path, type the path to the resource to which you are trying to connect.
To connect to the specified drive on start up, select the Reconnect at Logon check box.
Click OK.

Commands to View and Find NetWare Servers

From the command line you can view your existing network connections, and their network providers.

To view network connections

Click Start, point to Programs, and click Command Prompt.
Type Net Use, and press enter.

You can also browse the network to specifically find NetWare servers.

To browse for NetWare Servers

Click Start, point to Programs, and click Command Prompt.
Type Network:NW, and press enter.

Windows NT Client Logon to NetWare

Logging onto the NetWare network is accomplished through Windows NT. When the user starts a computer running Windows NT Server or Workstation and the steps outlined above are complete, the Begin Logon dialog box appears. The user then supplies the alt+ctrl+del key sequence and the Logon Information dialog box appears. When the user provides the logon information, the user is authenticated to the Windows NT network. At the same time, the user is authenticated to the NetWare network and has access to all NetWare resources for which they have been granted permissions.

NetWare Clients Authenticating to Windows NT Servers

At Terra Flora, the NetWare clients are, in most cases, configured with only the NetWare client software, including the IPX/SPX stack, and the NCP protocol. For many reasons, including limited conventional memory, or other incompatibilities, the users simply cannot run multiple protocol stacks on their client machines.

It is easy to justify a business case for connecting the NetWare clients to the Windows NT Servers. This connection would allow the computers running Windows NT Server to absorb the additional file and print load on the network and save Terra Flora the expense of investing in additional NetWare systems.

In the past, Terra Flora has been reluctant to take this step because completing the connection of the NetWare clients to computers running Windows NT Server would have required adding SMB networking support to and changing the configuration on each NetWare client, which just did not make cost-effective sense.

Now using the File and Print Services for NetWare, network clients can directly access information on a Windows NT Server without changing any of the client-side software or configuration information.

The File and Print Services for NetWare uses an NCP-compatible protocol to support file and print services to NetWare clients, using either the NETX or VLM redirectors. To the NetWare client, the Windows NT Server looks like a NetWare 3.12 server, providing both file and print resources via the same dialogs as the NetWare servers themselves.

To install FPNW on a computer running Windows NT Server

Click Start, point to Programs, and click Control Panel.
Double-click Network.
Click the Services tab.
Click Have Disk, and then type the path to the FPNW files, which are shipped on disks or a CD-ROM as part of a separate Microsoft product called Services for NetWare.
Click OK.
In the Select OEM Option dialog box, click File and Print Services for NetWare, and then click OK.
In the Install File and Print Services for NetWare dialog box, type the location for the SYSVOL directory that will be the equivalent of the NetWare SYS: volume in Directory for SYS Volume.
In Server Name, type the computer name that the NetWare client computers will use to access the server.
Type a password for the Supervisor's account in Supervisor Account, and then type the same password in Password and Confirm Password.
In Tuning, click an option for tuning server performance.
If you are installing File and Print Services for NetWare on a domain controller, enter a password for the FPNW Service Account when prompted.

You must restart the computer to complete the installation. The FPNW icon will then appear in Control Panel; a check box and NW Compat option are added to the New User dialog box for User Manager for Domains.

The network administrator can then select the Maintain NetWare Compatible Login check box to allow the user to log on to File and Print Services for NetWare.

Notes:

In step 7 of the procedure above, it is recommended that you specify a directory on an NTFS partition to be the equivalent of the NetWare SYS: volume. If you specify a directory on a non-NTFS partition, you lose the security features that NTFS provides and will not be able to set or enforce file or directory security settings. SYS is the volume that is traditionally created.
In step 8, above, the Server Name must be typed in all capital letters. The default is the server's computer name with **"**FPNW" appended, but can be any NetWare-compatible name that does not conflict with any other NetWare server names.
In step 9, above, the password can be as many as 14 characters, and is case-sensitive.
If you install File and Print Services for NetWare on multiple domain controllers in a domain, you must specify the same password for this account on each domain controller on which you install the utility.

Security access to FPNW on the Windows NT server is specified in the user's User Account. For information on setting up User Accounts, see Concepts and Planning.

NetWare Client Logon to Windows NT

Logging onto the Windows NT network is accomplished through NetWare. When the user starts the NetWare client, the user provides the necessary information to log onto the NetWare network. At the same time that the user is authenticated to the NetWare network, the user is also authenticated to the Windows NT network and has access to all Windows NT resources for which they have been granted permissions.

Windows NT Clients Authenticating to Banyan Servers

Windows NT Clients can authenticate to Banyan servers using the Banyan Enterprise Client for Windows NT version 5.56. The Windows NT clients will be able to access file and print resources on Vines server using this product.

Installing Banyan Enterprise Client for Windows NT

Banyan provides a product called Banyan Enterprise Client for Windows NT which enables the computers running Windows NT server or workstation to connect as clients to the Banyan servers.

At Terra Flora, user accounts and passwords are set up on the Banyan server that match the user accounts and passwords set up in the Directory Services of Windows NT.

To install Banyan Enterprise Client for Windows NT

Click Start, point to Programs, and click Windows NT Explorer.
Select the letter of the drive that contains the setup files.
Double-click Setup.exe.
In the Network Communications dialog box, select the Enable IP Encapsulation check box, and then click Advanced.
In the VINES Workstation Configuration dialog box, select the settings you want, if necessary, and then click Continue.
In the VINES Desktop Configuration dialog box, select the options shown in the following illustration.
Select the Create VINES Program group named check box and enter the name of the VINES program as you want it to appear under Programs on the Start menu.
Select the Change AUTOEXEC.NT check box to load the TSR, and then click OK.
In the Configure Network Computer Name dialog box, type the name of the computer on which you are installing Banyan Enterprise Client for Windows NT, and then click Continue.

You must restart the computer to complete the procedure.

Notes:

You are not required to use Log In Search, but if the groups are set up on the Banyan server, you can use this feature. The groups specified in the Search List will be searched to see if the user that is attempting to log in is a member of that group and what the permissions are associated with the user. You can specify up to three groups. When the user attempts to log on, the first group is checked, if no information about the user is located, the second group is checked. If no information about the user is found, the third group is checked. If no user information is found, the log in attempt fails.
The Load Banyan VINES Workstation during system start check box must be selected if the computer running Windows NT is to authenticate to the Banyan server automatically during logon.
The Use Windows NT Logon for VINES (common login) option creates a common login for both Windows NT and Banyan VINES. This requires that the user account and password on both machines be the same.
You can specify the log in attempt seconds before the result is a time out failure.
Step 10, above, allows MS-DOS applications to recognize the Banyan connections. This is required since most administrative applications running on the Banyan server are MS-DOS based.
In step 11, above, the Name must be included in a group in Street Talk on the Banyan server. You can indicate any name that is included in the group but the default will be the name of computer on which you are installing the product.

If the Banyan Enterprise Client for Windows NT is configured as described, login will take place when the Windows NT client starts up. When the user logs into the Windows NT network, authentication to the Banyan server also occurs.

If you elect not to configure automatic log in to the Banyan server because use is infrequent, the users can sign onto the Banyan server from the Windows NT Start menu.

To log into the Banyan server

Click Start, point to Programs, and click VINES (the program group name will appear as entered in the Vines Workstation Configuration dialog box).
Double-click Login.
In the VINES Login dialog box, type the user's account name and password that is configured on the Banyan server, and then click OK.

The VINES Login Status dialog box appears. Once this dialog box is closed, the Windows NT Start menu dialog box appears.

Banyan Clients Authenticating to Windows NT Servers

Banyan Systems Inc. has announced their StreetTalk Access for Windows NT which allows Banyan clients to directly access file and print resources on Windows NT servers. For more information, please contact Banyan Systems Inc. at https://www.banyan.com.

Windows 3.1 Clients Authenticating to Windows NT Servers

In order for a Windows 3.1 client to connect to a network, network software such as LAN Manager or Microsoft Networking Clients must be installed and configured. See the user documentation accompanying the LAN Manager or Microsoft Networks product for installation instructions. At Terra Flora, LAN Manager 2.2c is the product that will be installed to allow the Windows 3.1 clients to access the network.

Once LAN Manager is installed, the Config.sys and Windows\system.ini files will be updated and the network will start up automatically when the client running Windows 3.1 is started.

In addition, for a user to log onto a computer running Windows NT Server the user's account with necessary permissions must exist on the computer running Windows NT Server. For information on creating the user account and assigning permissions to access resources, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

Once LAN Manager is installed, the LAN Manager Logon will display every time the Windows 3.1 client starts up.

If a User Account and permissions have been set up on the Windows NT Server, the user is authenticated to the Windows NT network. To access the file and print servers, the user supplies the network path and connects to the required Windows NT resources.

To connect to Windows NT resources

On Program Manager, click LAN MAN.
Click Net Admin.
Double-click Network.

The Drives - Network Connections dialog box appears.
Select the Drive Letter for the connection.
In Path, type the path to the Windows NT Resources to which you want to connect.
To connect to the Windows NT Resources each time the computer starts up, select the Reconnect at Startup check box.
Click Connect.

Note: The user can connect to the network using File Manager. On the Disk menu, click Connect Network Drive and enter the path of the network resource to which you want to connect.

MS-DOS Clients Authenticating to Windows NT Servers

In order for a DOS client to connect to a network, network software such as LAN Manager or Microsoft Networks must be installed and configured. See the user documentation accompanying the selected product for installation. At Terra Flora, LAN Manager 2.2c is the product that will be installed to allow the MS-DOS clients to access the Windows NT network.

Once LAN Manager is installed, the Autoexec file is changed and the network will start up automatically when the client running DOS is started.

In addition, for a user to log onto a computer running Windows NT Server the user's account with necessary permissions must exist on the computer running Windows NT Server. For information on creating the user account and assigning permissions to access resources, see Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

When the network starts, the user types the Net Use command at the prompt and supplies the server name and share to which they want to connect. In the example below, the user wants to connect to payroll share on the Supply and Manufacturing payroll department server. At the prompt, the user would type:

Net Use * \\CAWPS30DPT01\Payroll

When enter is pressed, an available drive letter is assigned and connection to the server is completed.

Windows For Workgroups Clients Authenticating to Windows NT Servers

At Terra Flora, the clients running Windows for Workgroups are already configured and working together in workgroups. The workgroups are defined by task. For example, one of the payroll workgroups consists of all those responsible for entering hours worked into the payroll system. Since all the computers running Windows for Workgroups are already connected as workgroups, it is a simple configuration task to the computers to access other network computers running Windows NT Server.

Before the users of the computer running Windows for Workgroups can logon to the computer running Windows NT Server, the user's accounts and passwords must be set up and proper permissions assigned to the user on the Windows NT Server. For details, see Microsoft Windows NT Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

To make sure TCP/IP is enabled

On the Program Manager, double-click Network.
Double-click Network Setup.
In the Network Setup dialog box, make sure that Microsoft TCP/IP-32 3.11b is one of the drivers selected, and then click OK.

If the driver is not selected or is not available, see your Windows For Workgroups documentation for instructions on how to select the driver.

Note: The driver is located on the NT Server CD and can be selected from the \Clients\TCP32WFW directory.

At Terra Flora, the Windows for Workgroups client will log on onto the computer running Windows NT Server. In order to accomplish this task, the computer running Windows for Workgroups needs to be properly configured.

To configure the computer running Windows for Workgroups to join the Windows NT domain

On the Program Manager, double-click Main.
Double-click Control Panel.
Double-click Network.
In the Microsoft Windows Network dialog box, make sure the computer name appears in Computer Name.
In Workgroup, click the domain the user will log on to.
In Default Logon Name, type the user account, as set up on the Computer running Windows NT Server.
Click Startup, and then specify settings in the Startup Settings dialog box for how logon will occur when you start the computer running Windows for Workgroups.
Under Options for Enterprise Networking, select Log On to Windows NT or LAN Manager Domain.
Make sure the setting for Domain Name is correct, and then click Set Password.
In the Change Domain Password dialog box, make sure the information displayed is correct, or change the password, and then click OK.

The password must match the user account information set up on the computer running Windows NT Server.

When the user starts up the computer, the Welcome to Windows for Workgroups dialog box appears.

If the Logon Name is correct, the user types the password, clicks OK, and is authenticated to the Windows NT Network. The information can be changed.

Windows 95 Clients Authenticating to Windows NT servers

At Terra Flora, Windows 95 clients have been configured and are in use throughout the Terra Flora Network. Configuration of each Windows 95 client is required for the client to access the Windows NT Domain.

During Windows 95 setup, information is supplied which will be reviewed during the configuration process. Additional information will be configured about the Windows NT Domain and the Windows NT client.

Prior to configuring the Windows 95 clients, the Terra Flora administrators set up user accounts on the Windows NT servers, granting the proper permissions to each user that will access the computers running Windows NT Server. For details, see Microsoft Windows NT Concepts and Planning, Chapter 1, "Managing Windows NT Server Domains," Chapter 2, "Working with User and Group Accounts," and Chapter 3, "Managing User Work Environments."

To configure the Windows 95 client requiring access to a computer running Windows NT Server

Click Start, point to Settings, and click Control Panel.
Double-click Network.
In the Network dialog box, click the Configuration tab, which displays information that was input during the setup of Windows 95.
Click Client for Microsoft Networks, and then click Properties. The dialog box appears.
Enter settings in the Client for Microsoft Networks Properties dialog box, as illustrated below, substituting the name of your Windows NT domain in Windows NT domain, and then click OK.
Click TCP/IP and the installed net card, and then click Properties.
Verify that the IP address information is correct.
Verify the information contained on the other TCP/IP tabs: DNS Configuration, WINS Configuration, Gateway, Bindings, and Advanced, and then click OK.

Refer to the Windows 95 Resource Kit for more information about these options, if necessary.
In the Network Dialog box click the Identification tab.
Type the name of the computer, the NT domain name, and a description of the client, and then click OK.

You must restart the computer for the changes to take effect.

When the client starts Windows 95, the Enter Network Password dialog box appears. To log on to the network, the user enters the User Name and Password that match the ones set up for the user on the computer running Windows NT Server.

Macintosh Clients Authenticating to Windows NT Servers

Microsoft Windows NT Server Services for Macintosh is a thoroughly integrated component of Microsoft Windows NT Server, making it possible for computers running Windows NT Server and Apple Macintosh clients to share files and printers.

With Services for Macintosh, Macintoshes need only the Macintosh operating system software to function as clients; no additional software is required. You can, however, set up the optional user authentication module, which is software that provides a secure logon to the Windows NT Server.

For complete information on planning and setting up the Macintosh network, see the Microsoft Windows NT Server 4.0 Networking Supplement.

Installing Services for Macintosh

Terra Flora is using Macintosh clients to produce some of the necessary graphical marketing materials. At Terra Flora, they will enable Services for Macintosh on the computers running Windows NT Server using the Network icon in the Control Panel and the Windows NT Server distribution disk.

When Services for Macintosh are installed, the AppleTalk Protocol, File Server for Macintosh, and Print Server for Macintosh are automatically started, or enabled. An explanation of these services is provided in the Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 15, "Introduction to Services for Macintosh."

In addition, setting up Services for Macintosh creates an icon in Control Panel, which gives the administrator the same server administration capabilities as the MacFile menu, excluding volume management, for the local computer.

To set up Services for Macintosh

Services for Macintosh are loaded through the Network Icon on the Control Panel from the CD ROM accompanying the Windows NT Server product.

On the Control Panel, click the Network icon.
Click the Services tab.
Click Add.
On Network Service, click to Services for Macintosh, and click OK.
Type the full path of the Services for Macintosh, and click Continue.
In the AppleTalk Protocol Configuration dialog box, enter the changes you want, such as selecting a new zone, a different network, or enabling AppleTalk routing.

For details about this configuration, see*,* Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 16, "How Services for Macintosh Works," Chapter 18, "Setting Up Services for Macintosh" and Chapter 21, "Working with Macintosh-Accessible Volumes." Choose OK or Cancel if you don't want to change the configuration.

The computer must be restarted for the changes to take effect.

Authentication Services for Macintosh Client Software

Microsoft authentication is an extension to AppleShare, which provides a more secure logon session to a computer running Windows NT Server. It encrypts passwords and stores them on the computer running Windows NT Server. Administrators can either set up or instruct Macintosh users to set up the authentication file on their Macintoshes via the network.

With Microsoft authentication, users can also specify a domain when they log on or change their passwords. So if there are multiple domains on the network, the user's account domain will be used.

Note: Because the Apple System software up to version 7.1 does not fully support custom user authentication modules, Microsoft encourages the installation of Microsoft Authentication (MS UAM) only if increased security is necessary on the network computers running Windows NT Server.

A user authentication module (UAM) is a software program that prompts users for an account name and password before they log on to a server. Apple's Chooser has a standard UAM built in, which uses the clear-text password method of security. Microsoft Authentication offers an additional level of security because it encrypts, or scrambles, a password so it cannot be monitored when it is sent over the network. At Terra Flora, the administrators have determined that encryption is an important security measure, and will require use of Microsoft Authentication when the user logs on to the computer running Windows NT Server.

To gain access to the authentication files

On the Macintosh Apple menu, click Chooser.

The Chooser dialog box appears.
Click the AppleShare icon, and then click the AppleTalk zone in which the computer running Windows NT Server resides.
Click the name of the Windows NT Server, and then click OK.

A sign-in dialog box appears.
Click Registered User or Guest, as appropriate, and then click OK.

A server dialog box appears.
Click Microsoft UAM Volume, and then click OK.

To install the authentication files on the Macintosh client

From the Macintosh Desktop, double-click the Microsoft UAM Volume.

The Microsoft UAM Volume window appears.
Drag the AppleShare Folder to the System Folder on your hard disk.

Note: If the Macintosh client already has an AppleShare Folder in the System Folder, you will see a message that asks whether you want to overwrite the folder. You should not overwrite it because it may contain other UAMs, such as the NetWare UAM. If you want to maintain the files in the original AppleShare Folder, simply open the AppleShare Folder in the Microsoft UAM Volume, and drop the MS UAM file into your existing AppleShare Folder in your System Folder.

Configuring Services for Macintosh

Apple Talk Protocol is a stack of protocols that Services for Macintosh uses to route information and configure zones. It works behind the scenes to ensure that computers on the network can talk to one another. The Apple Talk Protocol is configured accessing Services for Macintosh located under the Network option of the Control Panel.

To configure Services for Macintosh

In Control Panel, click Network.
In the Services tab, select Services For Macintosh and click Properties.

The Microsoft AppleTalk Protocol Properties dialog box appears.
Select a default network from a list of adapter cards bound to the AppleTalk Protocol.

For details, see the Microsoft Windows NT Server Networking Supplement, Chapter 19, "Configuring Services for Macintosh."

How Files Are Shared

With Services for Macintosh, Macintosh users can easily share files stored on the computer running Windows NT Server. On a computer running Services for Macintosh, files are stored in shared directories or in Macintosh volumes.

With Services for Macintosh, Macintosh users cannot automatically gain access to all shares. To make a directory, and consequently its subdirectories, which may or may not be shared on the Windows NT system network, available to Macintosh users, the administrator must designate the directory as a Macintosh-accessible volume. For details, see the Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 21, "Working with Macintosh-Accessible Volumes."

Creating Volumes

All Macintosh-accessible volumes must be created on an NTFS partition. Similar to creating a share (shared directory) for PC users, you can designate a directory as a Macintosh-accessible volume. If the directory is to be accessed by PC clients as well as Macintosh clients, make sure you share the directory using the Share As command on the Disk menu and designate it as a Macintosh-accessible.

Note: You cannot give a directory Macintosh-accessible volume status if it is a subdirectory of another directory that has Macintosh-accessible volume status. For specifics, see Microsoft Windows NT Server Networking Supplement, Chapter 21, "Working with Macintosh-Accessible Volumes."

You can designate a directory as a Macintosh-accessible volume using the Create Volume command on the MacFile menu. From the Create Volume dialog box, you can create the volume by accepting the default settings, or may customize by changing the options.

To create a Macintosh-accessible volume

In File Manager, select the directory that you want to designate as a Macintosh-accessible volume.
On the MacFile menu, click Create Volume.
Type a name in Volume Name, which will be the name Macintosh users will see when they log on.
To accept the default options (listed below in Table 5.1), click OK.

Or, go to step 5.
Enter the settings you want to change from the default settings.

Refer to Table 5.2, below, for descriptions of the options.
Click Permissions to set directory permissions for Macintosh users, and then click OK.

The Macintosh-accessible volume automatically inherits the permissions of the corresponding directory, although you may change these. See Setting Permissions for Volumes and Folders later in this section.

Table 5.1. The default settings for the Create Volume dialog box

Option	Default Setting
Volume name	Same as the directory name. The character limit is 27.
Path	Same as the directory path.
Password/Confirm Password	No password.
This volume is read-only	This option is Off.
Guests can use this volume	This option is On (Yes).
User Limit	Unlimited.
User Permissions	Current directory permissions.

Table 5.2 Alternate settings for the Create Volume dialog box

Option	Default Setting
Option	Description
Password	Enter the password for this volume. When Macintosh users try to mount this volume, they will be asked for this password.
Confirm Password	Confirm the password just entered.
This volume is read-only	This volume and all of its contents have read-only access. This option supersedes all directory permissions set with the Permission button. In other words, if you give this volume read-only access, the permissions of directories with less restrictive access will not be honored.
Guests can use this volume	Guests can have access to this volume. If not selected, guests do not have access.
User Limit	Number of clients that can simultaneously mount the volume on the respective desktops. Select Unlimited or Allow and specify the number of users.
Permissions	Set access permissions on this volume. See Setting Permissions for Volumes and Folders later in this section.

Creating Folders in a Volume

You can create subdirectories for a Macintosh-accessible volume from the computer running Windows NT Server or folders from the Macintosh clients. In either case, the procedure for creating the directories or folders is no different than it is for creating other directories or folders on the respective systems.

On the computer running Windows NT Server, the folders appear in the File Manager's directory tree as subdirectories of the directory. To create another subdirectory, you select the directory in which it will appear and choose Create Directory from the File menu.

On the Macintosh, you create folders using the New Folder command on the File menu. You can view and use the folders in the Macintosh-accessible volume just organized by Name, Date, Icon, Size, and so forth.

Note: You cannot designate the subdirectory or folder as another Macintosh-accessible volume when the directory is already designated as a Macintosh-accessible volume.

Network Security

Services for Macintosh translates user identification, authentication (passwords), and permissions so that the security of the server is maintained regardless of the type of client used.

Services for Macintosh uses the same user accounts database as Windows NT Server. Therefore, if you already have Windows NT Server accounts created for the people who will be using Macintoshes on the network, you don't need to create additional accounts.

One aspect of Windows NT Server user accounts, the user's primary group, applies only to Services for Macintosh. The user's primary group is the group the user works with most, and it should be the group with which the user has the most resource needs in common. When a user creates a folder on a server, the user becomes the owner. The owner's primary group is set as the group associated with the folder. The administrator or owner can change the group associated with the folder.

Passwords

Macintosh users are logged on to a computer running Windows NT Server in one of three possible scenarios:

Guest Logons

Using Services for Macintosh, you can set up guest logons, which allow users without accounts to log on to the server using a Macintosh. You can specify what access to resources guest logon users have; administrators typically grant guest users fewer permissions than users who have accounts on the server. If the guest logon option is enabled, the server always approves the logon request without requiring a password. For information on setting up Guest Logons, see the Microsoft Windows NT Server Concepts and Planning Guide.
Cleartext Passwords

Cleartext password protection is part of the AppleShare client software on Macintoshes. It provides less security than encrypted password protection because the passwords are sent over computer lines and can be detected by "sniffers," which are network monitors that can look for passwords. Moreover, the AppleShare passwords can be no longer than eight characters. This method of protection is offered for Macintosh users who use the standard AppleShare client software or System 7 File Sharing.
Encrypted Passwords

An encrypted, or encoded, password is more secure than the cleartext password type of security. Windows NT Server encodes passwords and stores them so that they cannot be directly stolen from the client itself. Encrypted passwords can be as long as 14 characters. Services for Macintosh offers encrypted passwords to Macintosh clients.

For more information about security, see Windows NT ServerServices for Macintosh, Microsoft Windows NT Server 4.0 Networking Supplement and the Windows NT Server System Guide.

Volume Passwords

Services for Macintosh provides an extra level of security through Macintosh-accessible volume passwords. A volume password is a password you assign to a Macintosh-accessible volume when configuring it. Any Macintosh user who wants to use the volume must type the volume password. Volume passwords are case-sensitive. Volume passwords are optional; when you create a new Macintosh-accessible volume, the default is to have no volume password.

Note: Because of a constraint with the System 6 and 7 Finder, you cannot automatically mount a volume with a volume password at startup or by double-clicking an alias. You also cannot automatically mount a volume if the user originally connected to the volume with Microsoft Authentication.

Permissions

Access to network files and directories is controlled with permissions. With the Windows NT security system, you specify which users can use which shares, directories, and files, and how they can use those files. The Macintosh-style permissions differ in that they can be set for folders (directories) only—not files.

The Windows NT Server Administrator account always has full permissions on Services for Macintosh volumes.

Macintosh users set Macintosh-style permissions on the folders they create. In Windows NT, new files and new subdirectories inherit permissions from the directory in which they are created.

Macintosh files effectively inherit the permissions set on folders. Even though the Macintosh doesn't have file permissions, any Windows NT permission specified for a file will be recognized by the File Server for Macintosh, even though the Macintosh user won't see any indication in the Finder that these permissions exist. The Macintosh has the following four types of permissions for a folder:

See Files, which lets a user see what files are in the folder and read those files
See Folders, which lets a user see what folders are contained in the folder
Make Changes, which lets a user modify the contents of files in the folder, rename files, move files, create new files, and delete existing files
Cannot Move, Rename, or Delete, which prohibits these actions on a folder

The Macintosh security scheme is based on the idea that every folder on a server falls into one of three types: private information, accessible only by a single person, the owner of the folder; group information, accessible by a single workgroup; and public information, accessible by everyone.

For example, there can be a folder containing information that all members of a certain group should see, but that only one person can change. The person allowed to change the information should be the owner of the folder and should have See Files, See Folders, and Make Changes permissions. The workgroup that uses the folder should be the group associated with the folder and should have only See Files and See Folders permissions. Because no one else needs to see the folder's contents, the Everyone category should not be selected.

Although a folder's owner will often be a member of the group associated with the folder, this is not required.

With both Macintosh-style and Windows NT Server-style permissions, users' access to folders can be defined differently for each directory and subdirectory within a directory tree. For example, you could give a user See Files, See Folders, and Make Changes permissions for one folder, only the See Files permission for a subfolder of that folder, and no permissions at all for another subfolder.

The Macintosh does not support file-level permissions. When a file has file-level permissions, those permissions apply to Macintosh users only if the permissions are more restrictive than those assigned for the directory that contains the file.

Setting Permissions for Volumes and Folders

You control who can use Macintosh-accessible volumes by setting permissions. Permissions also control what kind of access is granted to users. For example, permissions dictate which users can make changes to a folder, and which ones can read the content of the folder but not alter it.

To set Macintosh-style permissions on a Macintosh-accessible volume or folder

In File Manager, click the directory you've designated as a Macintosh-accessible volume or a subdirectory that represents a folder in the volume.
On the MacFile menu, click Permissions.

Select or click to clear the See Files, See Folders, and Make Changes check boxes, as appropriate, for Owner, Primary Group, and Everyone.

Refer to Table 5.3, below, to help you decide which permissions to set.

Table 5.3 Options for Permissions

Permission	Description
See Files	Allows the owner, primary group, or everyone to see and open files in this folder.
See Folders	Allows the owner, primary group, or everyone to see and open folders in this folder.
Make changes	Allows the owner, primary group, or everyone to add or delete files and folders, and save changes to files in this folder.

To copy the permissions you set to all folders within this volume or folder, select the Replace permissions on subdirectories check box.
To prevent Macintosh users from moving, renaming, or deleting the volume or folder, select the Cannot move, rename, or delete check box.

Printing

When you set up a printer on the AppleTalk network to be used with Services for Macintosh, you can specify whether Services for Macintosh will capture the printer. This means that the printer will not accept print jobs from any source other than the print server, thus giving Windows NT Server administrators complete control over the printer.

In general, it is best to always capture a printer, unless a source other than the print server prints jobs on the printer. If a printer won't be used by anything other than Windows NT Server, Microsoft recommends that you capture it. Doing so ensures that users don't accidentally bypass the print server and send print jobs directly to the printer or reset the printer, which may cause spooler problems.

If a printer is not captured and both Windows NT Server and another source send jobs to the printer, no jobs will be interrupted; however, while the printer is printing a job from one source, it will appear busy to the other sources.

For information about how to capture AppleTalk printers, see the Networking Supplement.

Before setting up printers, it's important to understand the distinction between a printing device and a printer that you create using the Add Printer wizard.

A printing device is the hardware that actually does the printing, such as a Hewlett-Packard LaserJet.
A printer you create using Windows NT Server is a software interface between the document and the printing device. You create a printer using the Add Printer wizard, and each printer sends jobs to the printing device, according to the specified priority—for example, on a first-come, first-served basis.

These concepts and others are explained more fully in the Windows NT Server Concepts and Planning Guide and the Windows NT Networking Supplement.

When Services for Macintosh (SFM) is set up, several AppleTalk services are integrated into Windows NT Server. The print server, called Print Server for Macintosh, is integrated into the Windows NT Server Printers folder. The print server makes printers connected to the computer running Windows NT Server available to Macintosh clients, and it makes AppleTalk PostScript printers (with LaserWriter drivers) available to PC clients.

When the print server receives print jobs from the print server, it sends them to a spooler, which is a portion of the hard disk. The spooler then sends the print job to the specified printing device—for example, to a printing device on the AppleTalk network. This enables Macintosh users, as well as PC users, to submit print jobs and continue working on their computers without waiting for the print job to complete.

The print server also translates all incoming PostScript files if the print request is to a non-PostScript printer attached to the computer running Windows NT Server. So, a Macintosh client (but not a Windows NT client) can send a PostScript job to any Windows NT Server printer.

Note: This implementation of Postscript RIP for SFM supports 300 dpi and Postscript level 1.

Stopping and Restarting the Print Server

When you set up SFM, all services are automatically started, including the print server. You might want to stop and restart the print server if, for example, you must remove a printing device. You stop and restart the Print Server for Macintosh using the Services icon in Control Panel.

To stop and restart Print Server for Macintosh

In Control Panel, click Services.
In Service, click Print Server For Macintosh.
Click Stop or Start, as appropriate, and then click.
To change options at startup, click Startup.
Click Close.

Creating a Printer on a Computer Running Windows NT Server

After you have physically attached a printing device to a computer running Windows NT Server (either directly or on a network), use the Add Printer wizard to create a printer that represents it. You can create more than one printer representing the same printing device.

For example, if you have a printing device in your office but also share it with others over the network, you might want to create two printers representing the printing device. You can create a printer for yourself that is not shared over the network and a second printer that is shared. Then it's easy to control the use of the shared printer. You can set permissions on the shared printer, ensuring that only members of your department can print to it. Or you can set a low priority for it, ensuring that documents you send to the printer will always print before documents sent by those who share it.

Another common example is to create a printer that spools to a printing device at night and another printer that spools to the same printing device during the day.

To create a printer, you must be logged on with sufficient permissions. Administrators, Server Operators, and Print Operators can create printers.

To create a printer

Click Start, point to Settings, and then click Printers.
In the Printers dialog box, click Add Printer.
Follow the Add Printer wizard to choose the printer ports, printer driver, and printer name. You can also set printer properties, such as location and scheduling information.

See the online Help during setup for more information.

Note:

The printer name can be up to 32 characters in length. This name will appear in the title bar of the printer window. By default, it is the name that network users (except MS-DOS users) will see when you share the printer.

Choose the Share this printer option during setup. In the Share Name box, specify the printer name that you want MS-DOS clients to see.

When you are selecting a destination, if the printing device is physically connected to the Windows NT Server computer, then select the appropriate port. If the printing device is on the network, click Add Port. Choose AppleTalk Printing Devices from the Printer Ports dialog box and click OK. From the Available AppleTalk Printing Devices dialog box, select a zone and a printer, and click OK.

Setting Up a User Account for Macintosh Print Jobs

After setting up Services for Macintosh, you should create an account that will be used by all Macintosh clients when printing jobs to captured AppleTalk printing devices or to other devices on the computer running Windows NT Server. You should also configure Print Server for Macintosh to use this account.

After it is created, the user account (for example, MACUSERS) appears in the list of names that appears when you choose Permissions from the Security menu in Print Manager. You can give specific rights to this user account, just as you would any user account, including Print and No Access.

For more information about permissions, see Networking Supplement, Chapter 22, "Managing the File Server." For information on creating a user account and more specific information for configuring it to run with a service (such as Print Server for Macintosh), see the Windows NT Server Concepts and Planning Guide.

To configure the Print Server for Macintosh service to use a user account

In Control Panel, double-click Services.
Click Print Server For Macintosh.
Click Startup.
In the Print Server For Macintosh dialog box, click This Account and type the user account.
To require Macintosh users of the computer running Windows NT Server to use a password , type a password in Password and in Confirm Password.
Click OK.

Enabling Clients to Use Printers on the AppleTalk Network

With SFM, both PC and Macintosh clients can send print jobs to printing devices or spoolers on the AppleTalk network.

The printing device must appear as a LaserWriter in the Chooser, and there must be a Windows NT print driver for the printing device.

Macintosh clients use printers just as they normally do—through the Chooser. If an AppleTalk printer has been set up through Print Manager, it can be captured so that Macintosh clients cannot access it directly. This causes Macintosh print jobs go through the computer running Windows NT Server and be spooled along with print jobs from PC clients.

You can disable the capture setting. Doing so enables any Macintosh client to print to an AppleTalk printer directly. There are a few problems with this scenario, the most important being that the jobs will not be under the administrator's control.

To release or recapture an AppleTalk printing device

In Printers, select an AppleTalk printing device.
On the File menu, click Properties.
Click the Ports tab, and then click Configure Port.

A dialog box appears, asking if you want to capture this AppleTalk printing device.
Click Yes to capture it.

– Or –

Click No to release it.
Click OK.

When an AppleTalk printer is released, any Macintosh user on the AppleTalk network can use the device directly.

A printing device on AppleTalk can be captured when SFM is set up and a printer is created for it. It must remain captured so that all Macintosh clients send print jobs through the computer running Windows NT Server. If a printing device has been released for some reason, you can recapture it.

You can select another spooler instead of an actual device. Use this type of configuration with caution. It is possible to create an endless loop of print spooling with this method.

Centralized Services

At Terra Flora, the goal of centralizing administrative services was achieved with the installation of Windows NT Server as the common platform from which to interoperate their heterogeneous networks. Use of the Windows NT network operating system has provided Terra Flora with the ability to administer all clients and servers running operating systems other than Windows NT from one client computer. Several sessions can be started on any computer running Windows NT Server or Workstation so the administrator can view and monitor all network computers.

Though there are some limitations to the extent of administrative functionality, Windows NT Server was the most flexible and functional solution to the challenges presented to Terra Flora's plan to centrally administer the different network operating systems.

The Decision to Centralize Administrative Tasks

To Terra Flora, one of the major benefits of installing and configuring Windows NT Server services is the ability to administer all clients and servers on the network from a central point, regardless of the geographic location of the computer or which operating system is running.

Additionally, all the servers can be administrated on one client running Windows NT Workstation or Server because the computer will support the running of multiple sessions.

Most of the administration of all network servers will be performed by the network administration staff located in Sacramento, California. The administration may not be performed on a single computer, but the ability to do so provides greater flexibility to the network administrators. Occasionally, the administrators will want to sign onto machines while visiting remote sites and administer computers located at corporate headquarters or at the remote sites. At some remote sites administration may be localized to reduce excessive wide area network (WAN) traffic.

The administrative tasks necessary to manage the clients and servers are the same regardless of the operating system that is being run on the computer. For example, administrators set up and maintain user accounts and grant permissions to users or groups of users on Windows NT Servers as well as on UNIX and NetWare servers. Administrative tools are supplied with each operating system and the idea of interoperability includes the ability to sign onto any computer in the network and run any administrative tools on any network computer. Windows NT provides this capability.

This ability will reduce the administrative costs associated with managing a network the size of Terra Flora's. This eliminates the need for administrators to be located at remote sites, the need for administrators to travel to remote sites to perform routine administrative tasks and eliminates some of the wide area network (WAN) traffic that would occur administering files remotely.

The following table provides examples of which administrative tools are provided by which operating systems to remotely administer the servers at Terra Flora. This section will focus on the ability to connect to the administrative tool from Windows NT. The details of how to use each of the administrative tools is provided in the documentation accompanying the operating system.

Operating System	Administrative Tools (not all-inclusive)	Use of the Tool
UNIX	FTP	Allows users to connect to the UNIX remote hosts (computers) to transfer files such as /etc/passwrd, /etc/hosts, etc.
	Telnet	In many UNIX-oriented environments, administrative functions are performed via a remote console command-line interface, known as Telnet. Telnet is a simple UNIX remote command line window to the remote host server. Windows NT Workstation and Windows NT Server have a graphical Telnet application in the Program Manager's Accessories group.
	X/Windows	Provides access to graphical programs running on UNIX servers. The XWindows client acts as a UNIX display server. The Windows NT client can run both character bit DOS applications and XWindows graphical interface applications.
NetWare	Syscon	The primary NetWare administration tool used to set up and maintain user accounts, policies and resource permissions.
	RConsole	Provides remote connection of a network client to the NetWare network as a remote system console.
	PConsole	Provides the tools necessary to manage print servers.
Banyan	Manage.com	Provides a menu from which Banyan administrators can choose the administration tool with which they want to work.
	Mservice.com	Allows the user to add services with which they will administrate Banyan servers to a menu to select from and run.
	Muser.com	Allows administration of Banyan user accounts.
Windows NT	User Manager	Allows the management of user and group accounts which grant access to the Windows NT network resources.
	Server Manager	Server Manager is used to manage Windows NT domains and computers.
	Internet Homepage	The Catapult server provides centralized access to the Internet and acts as an Internet proxy server.

UNIX Administration

Two additional services need to be added to the computers running Windows NT Workstation or Server in order to use computers running Windows NT Workstation or Server to administer UNIX servers, FTP and Telnet.

File Transfer Protocol

File Transfer Protocol (FTP) allows users to connect to the remote computers to transfer files. What this means to the administrator is that, for example, files stored on a remote UNIX computer can be transferred to a local Windows NT computer, administrative changes can be made to the files, and the files transferred back to the remote computer for continued storage.

FTP is widely used on the Internet for transferring files. Terra Flora is anticipating that over time, this file download process will be hidden by world wide web (WWW) browsers that will perform the transfer operations in the background as required by the applications.

FTP Server

FTP Server capabilities are built into Windows NT Server. This provides capabilities for UNIX clients or windows sockets-based UNIX oriented applications to perform file transfer. Files can be transferred to the UNIX server for administration or transferred from a UNIX server for administration.

Note: One of the limitations of the FTP server is that the password to the FTP server is sent over the wire in clear text, meaning that the password is not encrypted or otherwise protected on the network. Any person on the network with a network sniffer can capture the password packets and know the password for the specified user.

Due to the clear-text password limitation, most FTP servers are configured to only allow anonymous connections. Anonymous is a specific user name which is used for non-secure sessions. Anonymous is used to prevent anyone from accidentally using a valid user name and password to gain server access. Once the user is connected to the server using the anonymous user name and password, the user is prompted for their domain name service (DNS) name as the password, such as johndoe@terraflora.com to provide an audit of the user's access and hits on specific files stored on the FTP server.

Installing FTP Server

FTP Server is installed when you install the Internet Information Server. Once the FTP server is installed, there is a graphical interface that provides the connection to the server that stores the files you want to transfer.

To install the FTP Server service

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Services tab.
Click Add.
In the Select Network Service dialog box, click Microsoft Internet Information Server 2.0 (IIS).
Click Have Disk, and enter the path to the Windows NT CD-ROM or disks that contain the services.
Click OK.
If you are not using IIS and are installing it only to access FTP, click to clear the following check boxes in the Microsoft Internet Information Server 2.0 Setup dialog box:

• Internet Information Service

• World Wide Web Services

• Gopher Service
Click OK.

Transferring Files Using FTP

This example illustrates how files would be transferred from a UNIX server using FTP. The files would be transferred to a Windows NT Server and the administrator could make changes to the files and transfer the files back to the UNIX server on which they are normally stored. The administrators at Terra Flora use FTP to transfer remote server files on a regular basis to avoid editing the files remotely over the WAN. At Terra Flora, the UNIX server is named CAPWKSENT01. Using the procedure below, FTP will be used to transfer the files from the UNIX server to the Windows NT Server.

To transfer files from the Terra Flora UNIX server, the administrator will

Click Start, point to Programs, and click Command Prompt.
Type FTP and the host name or IP address of the server from which files will be transferred.
If you are using FTP to access an UNIX server, you must provide the UNIX user-account and password information, as shown in the following illustration.

Once you connect to the UNIX server, you can use standard FTP commands, such as Get and Put, to transfer files, as if you were running FTP on the UNIX server.

Telnet Client

At Terra Flora as in many UNIX environments, administrative functions are often performed on a remote console, which is a control client computer through which a user communicates with a server. The administrator uses a command-line interface available on the client, known as Telnet, which is a simple UNIX remote command line window to access the remote server. Windows NT Workstation and Windows NT Server provide a graphical Telnet application. The application allows the computer running Windows NT Workstation or Windows NT Server to connect to the UNIX server and use the Telnet commands to administer the server. The computer running Windows NT Server or Workstation connects to the UNIX server as just another remote client.

Note: Windows NT does allow administrative commands to be issued through the command-line interface, however, it is not the preferred method of administration.

Windows NT Server does not contain a Telnet server, but Telnet servers are available as shareware on the Internet.

The Telnet client service is installed as part of the installation TCP/IP services on of either computers running Windows NT Workstation or Server.

To run the Telnet service on the computer running Windows NT Workstation or Server

Click Start, point to Programs, point to Accessories, and then click Telnet.
On the Connect menu, click Remote System.
In Host Name, type the name of the UNIX computer on which the files you want to administer are stored.
Click Connect.
If the client is not already connected to the UNIX server, type the user-account and password-login information required to access the UNIX server when prompted.

Once logged onto the UNIX server, you can administer the UNIX files stored on the server.

For UNIX clients to communicate with Windows NT Servers, Integraph's DiskShare product was installed on the computers running Windows NT Server. Once installed, the UNIX clients were able connect to the Windows NT server, once a user account had been set up and proper permissions on the Windows NT server granted to the user of the UNIX client. For details, see "UNIX Clients Authenticating to Windows NT Servers," earlier in this chapter. The UNIX client can then administer the Windows NT Servers.

Access to the UNIX servers by Windows NT clients can now be performed because Integraph's PC-NFS was installed on the Windows NT client computers. Again, since proper permissions have been granted to the user on the UNIX server, the Windows NT client can administer the UNIX servers. For complete instructions on the installation, configuration and use of Integraph PC-NFS and DiskShare, see the earlier topics in this chapter, "UNIX Clients Authenticating to Windows NT Servers" and "Windows NT Clients Authenticating to UNIX Servers."

Once the connection is made between the computers running UNIX and Windows NT, administration can be performed using the additional services of FTP and Telnet as described above.

X/Windows Support

Client/server graphical application support for UNIX-based applications has evolved around the X/Windows interface. The X/Windows application programming interfaces (APIs) help to span the different variations of UNIX implementation in various networking environments by providing a common application interface programming model for applications.

In the popular PC-based computing circles, a client computer refers to the end-node machines sitting on the desktops, while the server computer is a powerful processing "workhorse" computer which makes resources available to a large number of clients.

In X/Windows, and UNIX, terminology, the X/Windows server is really the X/Windows display server which provides the services to display the graphical interface application to the user and resides on the desktop machines. The X/Windows client is the is the processing engine for the X/Windows application. For those readers familiar with the PC-based nomenclature, simply reverse the typical definitions when thinking about the X/Windows environment.

X/Windows is different than typical PC-based client server models. In X/Windows, the server application executes the instructions on the network server known as the X/Client. The network server executes the applications, and sends the commands to draw the appropriate graphical images on the screen. The user mouse clicks and keyboard commands are sent across the network to the X/Client application, and are processed remotely. In essence, X/Windows applications that are viewed on the desktop are actually running on the remote network server, and the graphical information, as well as the user input are relayed across the network to the display client.

Applications written to the common X/Windows specifications will run on many different versions of UNIX, however, some of their version-specific functionality may not be available on all platforms.

X/Windows Server

Terra Flora, with its mixed networking environment, has made use of the traditional UNIX computing model which is a workstation computer (server) running a version of UINX connected to a mainframe or minicomputer (client) for, as an example, statistical sales analysis.

However, as the PC-based computing environment has spanned the enterprise, the ease of use and powerful graphical productivity applications have moved into sales and accounting areas by necessity to communicate with the rest of the corporation, as well as provide a common platform for document creation, charting, and integrated analysis.

At Terra Flora, this has also led to the dual-computer desktops in many work areas. One workstation running UNIX with X/Windows applications for statistical sales analysis work, and another desktop running the Windows interface for document creation, charting and integrated analysis presented in graphical format. The problem with this solution is that it is expensive, both in hardware costs and administration. Additionally, it is difficult to get information from one system to another. There is a solution for this problem, X/Windows servers for Windows NT.

In the previous section, an example was presented illustrating how a computer running Windows NT Server or Workstation can become a remote console to administer files on, for example, a UNIX server. The interface presented to the client computer is a character mode interface. There is no access to the graphical applications on the UNIX server.

At Terra Flora, an X/Windows product from Hummingbird Communications, Ltd called eXceed, version 5, will be installed on all computers running Windows NT Workstation or Server that will act as remotes consoles connecting to the UNIX servers. By installing the X/Windows product, the client will be able to access a DOS character mode interface and access the graphical interface applications.

To install X/Windows

Click Start, and then click Run.
Follow instructions provided in the Exceed 5 documentation about the information to be entered on the command line and other installation details.

Below are samples of the graphical interface demo files loaded on all UNIX servers. The demo files are all loaded on a single Windows NT computer to illustrate the ability to use both graphical applications and character bit applications.

The first shot is the graphical application called Xeyes.

xng_h06

The second screen shot is of the UNIX graphical application called Xclock.

xng_h07

The third screen shot is of the graphical application called calculator.

xng_h08

As demonstrated in the screen shot below, the Windows NT client can be used to run multiple sessions. Any variety of the graphical applications can be run from a single station. On a single workstation, both Windows-based applications and X/Windows applications are accessible, and information interchange is relatively easy. The cost reduction is significant, as Windows NT Workstations are typically less expensive than UNIX workstations, plus the second desktop machine is no longer required.

NetWare Administration

NetWare servers cannot be administered directly. Instead a NetWare client acts as the system console and controls the administration of the NetWare server. A computer running Windows NT Server with the Gateway Services for NetWare (GSNW) enabled or a computer running Windows NT Workstation with the Client Services for NetWare (CSNW) enabled, can act as a NetWare client and connect to the NetWare Environment.

For complete instructions on installing and configuring CSNW and GSNW, see the earlier topics in this chapter, "Windows NT Clients Authenticating to NetWare Servers" and "NetWare Clients Authenticating to Windows NT Servers."

NetWare Administration Using a Windows NT Computer

At Terra Flora, CSNW or GSNW has been installed on all computers running Windows NT Workstation or Server that are going to function as NetWare clients to administrate NetWare servers. For a detailed explanation of CSNW and GSNW, installation and configuration instructions, see the earlier topics in this chapter, "Client Service for NetWare" and "Gateway Service for NetWare."

Now that the two systems can interoperate, any computer running Windows NT can act as a system console and run the NetWare Administration utilities, examples of which would be Syscon, PConsole and RConsole. For details on the use and operation of the NetWare Administration utilities, see the NetWare documentation.

Access to the NetWare environment as a NetWare client is accomplished through Windows NT using either the CSNW or GSNW service. When the computer running Windows NT Server or workstation with either the CSNW or GSNW service installed starts up, the Begin Logon dialog box appears. The user then logs into the Windows NT Network as normal, supplying the user account and password for Windows NT set up by the administrator. If the CSNW or GSNW service is correctly configured, the user is authenticated not only to the Windows NT network, but to the NetWare network at the same time.

Access to Syscon, RConsole and PConsole is accomplished on the Windows NT client as if the Windows NT client were a NetWare client. In a NetWare environment, the primary administration tool called System Console (Syscon) is used to set up user accounts, define policies, and grant user access permissions to the NetWare network.

The screen shot of Syscon below was captured on a computer running Windows NT Workstation or Windows NT Server connecting as a NetWare client to the NetWare environment.

RConsole provides a remote view of the NetWare system console. The console functions can be performed on the remote console. The screen shot of RConsole below was captured on a computer running Windows NT Workstation or Windows NT Server connecting as a NetWare client to the NetWare environment.

PConsole provides the administrator with the tools necessary to manage print servers. The screen shot of PConsole below was captured on a computer running Windows NT Workstation or Windows NT Server connecting as a NetWare client to the NetWare environment.

Multiple sessions of the administration tools can be run on a single Windows NT client. The information about each of the servers to which the client is connected will be displayed in a separate window on the client. This is a major benefit of using computers running Windows NT. The result is the ability to monitor all of the NetWare servers from one system console, which is not possible on computers running other operating systems such as MS-DOS.

To connect to additional NetWare servers

Click Start, point to Programs, and click Windows NT Explorer.
On the Tools menu, click Map Network Drive.
In Drive, enter a drive letter, if necessary.
In Path, type the path to the NetWare server.
To connect to the NetWare server using another user account and password, type the information in Connect As (optional).
Click OK.

Note: Although Windows NT Workstation and Windows NT Server versions 4.0 support connections to NetWare Directory Services (NDS), they do not support administration of NDS trees at this time.

The screen shot below displays multiple sessions of the administration tools running on one Windows NT client.

Administrating Windows NT Servers Using NetWare Clients

For a NetWare client to access and administer a Windows NT Server, File and Print Services for NetWare must be installed on the computer running Windows NT Server. Once FPNW is installed and configured, a NetWare client can sign onto the computer running Windows NT Server and perform administration tasks. For instructions on installing and configuring FPNW, see "NetWare Clients Authenticating to Windows NT Servers," earlier in this chapter. For details on the use of the administration tools, see online Help.

Banyan Administration

As part of the Terra Flora strategy to provide centralized network services, Terra Flora has installed Banyan Enterprise Client for Windows NT on all computers running Windows NT Server or Workstation that will be required to function as Banyan clients. Banyan servers cannot be directly administered. Instead as with NetWare and UNIX, server administration is performed on clients functioning as system consoles.

Installation of the Banyan Enterprise client for Windows NT allows the computer running Windows NT Server or Workstation to connect to the Banyan network as a system console. The system console has access to the administration tools on the Banyan server that allow the management of user accounts and other networking services.

When a computer running Windows NT Server or Workstation that will function as a Banyan client starts, the user supplies the same user account and password normally used to log on to Windows NT and is authenticated to the Windows NT network.

Logon to the Banyan server may be configured as automatic, which means that the configuration of the Banyan Enterprise client for Windows NT is set up so that authentication to the Banyan server is accomplished when the user supplies their user account and password for logging onto the Windows NT network. For information on installation and configuration of Banyan Enterprise Client for Windows NT on the on computers running Windows NT Server and Workstation, the section titled, "Windows NT Clients Authenticating to Banyan Servers," earlier in this chapter.

During Banyan logon, the redirector will map the system files volume to the default Z drive. The user can then select the administration tools they want to work with from drive Z.

From the DOS prompt, type Manage.com. Press enter. The Manage.com menu appears. From the menu, the user selects the type of administration that they want to do. See your Banyan documentation for details on the administration utilities available on the Manage.com menu. The screen shot of Manage.com below was captured on a computer running Windows NT Server connecting as a Banyan client to the Banyan server.

The first two menu options are the ones that we will focus on for the remainder of this section. Services (Mservice) allows the Banyan Administrator to administer the server using various services that can be specified on the menu. See your Banyan documentation for details on the use of Services options.

Services can be accessed in two ways.

At the DOS prompt, after connecting to the Banyan Server from a computer running Windows NT Workstation or Server, type Mservice.com and press enter.
Additionally, as is illustrated in this example, you can select option 1 Services on the Manage.com menu.

The screen shot of MService below was captured on a computer running Windows NT connecting as a Banyan client to the Banyan server.

Option 2 on the Manage.com menu allows the user to administer user accounts on the Banyan server. For detailed instructions on how to use the User option, see your Banyan documentation.

There are two ways to access Users:

At the DOS prompt, after connecting to the Banyan Server from a computer running Windows NT Workstation or Server, type Mservice.com and press enter.
Additionally, as is illustrated in this example, you can select option 1 Services on the Manage.com menu.

The screen shot of MUser below was captured on a computer running Windows NT connecting as a Banyan client to the Banyan environment.

Multiple sessions of the administration tools can be run on a single computer running Windows NT Workstation or Server acting as a client connected to a Banyan client. The information about each of the servers to which the client is connected will be displayed in a separate window on the client. This is a major benefit of using computers running Windows NT. The result is the ability to monitor all of the Banyan servers from one computer running Windows NT Workstation or Server acting as a system console. This feature also exists in a limited fashion on computers running Windows 95, but is not a feature that is available on computers running other operating systems such as MS-DOS.

The screen shot below displays multiple sessions of the administration tools running on one Windows NT client.

Windows NT Connectivity and Administration

Computers running Windows NT Workstation or Windows NT Server can be administered from any other computer running Windows NT Server or Workstation. Additionally, most computers operating in a heterogeneous network can be used to connect and in some cases administer computers running Windows NT Workstation or Windows NT Server.

By installing and configuring Intergraph DiskShare on the computers running Windows NT Server, UNIX clients can connect to connect to computers running Windows NT Server for access to file services.
By installing and configuring File and Print Services for NetWare on the computer running Windows NT Server, NetWare clients can be used to connect to computers running Windows NT Server.
By installing and configuring network software such as LAN Manager or Microsoft Works, Windows 3.1 clients and DOS clients can be used to connect to and administer Windows NT servers.
By installing and configuring Services for Macintosh, Macintosh clients can be used to connect to computers running Windows NT Server.
Computers running Windows for Workgroups and Windows 95 can be configured to authenticate automatically to the Windows NT network and can be used to administer the Windows NT servers.

For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

User Manager for Domains

User Manager for Domains is used to administer user and group accounts which allow users to participate in a Windows NT domain and access the domain's resources. Additionally with User Manager for Domains, rights and permissions can be granted to the user and group accounts providing the appropriate amount of access and restrictions to network resources in the Windows NT domain.

Once a client computer accesses the Windows NT Server with the proper permissions, the client can administer the server. For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

To run User Manager

Click Start, point to Programs, point to Administrative Tools (Common), and then click User Manager for Domains.

For complete instructions on the use of User Manager for Domains, see the Windows NT Server Concepts and Planning Guide, Chapter 2, "Working with User and Group Accounts." See Chapter 3, "Manager User Work Environments," for complete instructions on managing User Profiles and System Policies.

Server Manager

Client computers connected to the computer running Windows NT Server can be used to administer the computers running Windows NT Server by connecting to the servers. For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

Server Manager is the tool used to manage domains and computers. With Server Manager you can:

Select a Windows NT domain, workgroup or computer for administration.
Manage a computer including viewing a list of connected users, viewing shared and open resources, managing services and shared directories and sending messages to connected users.
Manage a domain including promoting a backup domain controller to the primary domain controller (PDC), synchronizing servers with primary domain controllers and adding computers to and removing computers from the domain.

Once a client computer accesses the Windows NT Server, the client can administer the server. For complete instructions on how to install and configure the software required for interoperating the different operating systems referenced above, see "Network Logon Services," earlier in this chapter.

To run Server Manager

Click Start, point to Programs, point to Administrative Tools (Common), and then click Server Manager.

For complete instructions on the use of Server Manager, see the Help file.

Internet Service

At Terra Flora, a server has been installed to provide a proxy agent to the Internet and prevent unauthorized access to or from the network. What happens is that network users communicate with the proxy agent server that acts as a fire wall to the network and the proxy agent server then communicates with the Internet. By the same token, users accessing the Terra Flora network from the Internet communicate with the proxy agent server acting as a fire wall and protecting the network from unauthorized access. There is no actual access to the Internet from the network and there is no access from the Internet to the network except through the proxy fire wall server, which will authenticate requested user access.

Additionally, the Internet server provides a central access point to the Internet. All users either exiting the network to the Internet or entering the network from the Internet will pass through this central server.

Replication and Backup Services

At Terra Flora, the Windows NT Replication service will be used to ensure that all crucial Enterprise level databases are replicated to other computers running Windows NT Server. These include WINS and DNS.

Terra Flora has elected to use a flexible back up strategy for the data that exists on their servers, at all levels. Third party software will be incorporated for online backups and to protect master copies of distributed databases and other software.

The business reasons for replicating and backing up the business applications and databases are fairly obvious, to protect the business critical applications and ensure that should servers fail, recovery is quick and accurate.

Terra Flora's Decisions About Replication

On servers running Windows NT Server, replication of the Enterprise databases are configured at the time that the Enterprise level service is installed. For example the WINS and DNS databases were configured to replicate on backup servers during configuration. Additionally, the primary domain controller (PDC) will replicate the directory services to the backup domain controller (BDC), ensuring fault tolerance and providing another server which can authenticate users of the Windows NT services.

DHCP is a database that is not automatically replicated. For this reason, Terra Flora will use the Replicator service, which is a service that is part of Windows NT Workstation and Server, to backup the DHCP database and files to another server, ensuring that should the primary server fail, DHCP information can be recovered and dynamic network addressing of clients and servers continue.

Terra Flora's Decisions About Backup

Terra Flora has elected to use a flexible back up strategy for the data that exists on their servers, at all levels. Regularly scheduled backup of the WINNT, data and software master copy directories will be performed using third party software which works in conjunction with Windows NT. For daily, weekly and disaster recovery, Terra Flora will use the Seagate, (formerly Arcada) BackUp Exec for Windows NT, Single Server/Enterprise Edition - Version 6 Product.

Seagate Backup Exec for Windows NT is a proven 32-bit backup that protects the entire network. With centralized administration and its exclusive ExecView monitoring console, Backup Exec provides client/server functionality for Windows NT data protection. Backup Exec supports any combination of clients on any platform, on the Windows NT network. The documentation accompanying the product will explain setup and configuration of backup service.

For online backups, Terra Flora uses Octopus for Windows NT to provide data fault tolerance and real time data protection between the Enterprise/Enterprise Remote servers and for designated data directories on the divisional/regional servers such as project directories. Online backups are backups that occur as data in a file or database is added, changed or deleted.

Octopus mirrors files and/or directories rather than disks and will be set up on the computers running Windows NT Server. Source servers are the computers where the data to be backed up resides and target servers are the computers where the mirrored data will be stored. Any changes to the source files are mirrored and sent over the network to the target computers. Documentation accompanying the Octopus product explains setup and configuration of backup services.

At the Terra Flora Enterprise/Enterprise Remote level, the computers running Windows NT Server will back up their own servers as well as back up data directories on the Division/Region servers. The Division/Region servers will backup their own servers as well as back up the data directories on the Department/Branch Office servers. The Department/Branch servers will backup their own servers and users of the Desktop workstations will be responsible for backing up the necessary information on the workstations.

Backup of the DHCP Directory and Files

Replication of the WINS and DNS databases is an automatic feature of both the Windows NT Server WINS and DNS services and is configured during the installation process of WINS and DNS. At Terra Flora, replication of these databases has been configured to replicate on different servers in the network. The DHCP service, while it does provide a backup of the database and files in the System32\DHCP\Backup directory, cannot automatically be configured to replicate to different servers. An additional step is required.

The System 32\DHCP\ Backup directory is stored on the same physical drive as the DHCP database directory. At Terra Flora, the plan is to backup the DHCP directory to a different physical device on the same computer running the Windows NT Server DHCP service and then replicate the backup to another server. This plan provides a backup DHCP database copy should either the physical drive on which the DHCP database is stored or the computer running Windows NT Server DHCP service fail. The backup plan for the DHCP servers is as follows:

The Registry will be edited to allow backup of the DHCP database to another physical drive on the DHCP server.
Additionally, each DHCP database and associated files will be replicated to an Enterprise/Enterprise level server that is not running DHCP.
The Replicator service will be used to back up the necessary file stored in the System32\DHCP\Backup directory to an Enterprise/Enterprise Remote server which is not running the DHCP service.

Refer to Terra Flora's network diagram, one DHCP database directory on the server named CANTS40ENT03 will be replicated to CANT40ENT01 and the other DHCP directory on the server named CANT40ENT02 will be replicated on CANT40ENT05.

Editing the Registry

At Terra Flora, the Registry Editor will be changed to ensure that backup is made to a different physical device on the DHCP server that stores the database and files.

To edit the registry

At the command prompt, type Regedt32, and press enter.
Double-click HKEY_LOCAL_MACHINE.
Double-click System.
Double-click CurrentControlSet.
Double-click Services.
Double-click DHCP Server.
Double-click Parameters.
Double-click Backup Database Path.
Change the first part of the line to indicate a different physical drive on the server, such asD:\System32\dhcp\backup.

The information will then be backed up to the physical drive indicated.

You can now use the Replicator Service to copy that directory to a backup server.

Managing Directory Replication

Backing up a directory to a different server is a task performed by Windows NT Server Directory Replicator service. The server on which the DHCP directory is stored will be configured as an export server. The server which will store the backup copy of the DHCP directory and files is the import server.

When you update a file in the directory tree on one server (the export server), the updated file is automatically copied to all the other computers (the import computers). Only servers running Windows NT Server can be export servers; import computers can run either Windows NT Server or Windows NT Workstation.

How Directory Replication Works

Directory replication is initiated and carried out by the Directory Replicator service. This service operates on each export server and import computer that participates in replication. The service on each computer logs on to the same user account, which you create for this purpose.

You set up an export server and import computers to send and receive updated files. An export directory on the export server contains all the directories and subdirectories of files to be replicated, and when changes are saved to files in these directories, the files automatically replace the existing files on all the import computers.

You can also specify whether to have the export server send changes out as soon as a file has changed or, to prevent exporting partially changed trees, to wait until one export subdirectory has been stable before exporting. See "Managing Exported Subdirectories," later in this chapter.

In addition, you can lock a particular export or import directory, when needed. Changes to the locked directory are not exported or imported until you unlock the directory.

On the export server, you also designate which computers or domains are to receive replicated copies of the directories this server is exporting.

An export server has a default export path:

C:\systemroot\SYSTEM32\repl\EXPort

All directories to be replicated are exported as subdirectories in the export path. Subdirectories created in the export path, and files placed in those subdirectories, are automatically exported. Export servers can replicate any number of subdirectories (limited only by available memory), with each exported subdirectory having up to 32 subdirectory levels in its tree.

An import computer has a default import path:

c:\systemroot\SYSTEM32\repl\IMPort.

Imported subdirectories and their files are automatically placed here. You do not need to create these import subdirectories. They are created automatically when replication occurs.

Replication Prerequisites

Before a computer can participate in replication, you must create a special user account. Then for each computer in a domain that will participate in replication, configure its Directory Replicator service to log on using that special account:

In User Manager for Domains, create a domain user account for the Directory Replicator service to use when logging on. Be sure the user account has the Password Never Expires option selected, all logon hours allowed, and membership in the domain's Backup Operators group. See online Help and Microsoft Windows NT Server 4.0 Concepts and Planning, Chapter 2, "Working with User and Group Accounts" and Chapter 3, "Managing User Work Environments" for details.
After the user account is created for each computer that will be configured as an export server or an import computer, use Server Manager to configure the Directory Replicator service to start up automatically and to log on under that user account. Be sure the password for that user account is typed correctly. See online Help for details.

Setting Up an Export Server

Any computer running Windows NT Server can be set up as an export server. (A computer running Windows NT Workstation cannot.)

Before you set up an export server, you must perform these tasks on the export server:

Assign a logon account to the Directory Replicator service of the export server.
Create the directories to be exported. They must be subdirectories of the replication export path (usually C:\systemroot\ SYSTEM32\REPL\EXPORT).

Use the Directory Replication dialog box to set up an export server.

Managing Exported Subdirectories

By clicking Manage under Export Directories in the Directory Replication dialog box, you can manage certain features of subdirectory replication by the export server:

You can lock a subdirectory to prevent it from being exported to any import computers. For example, if you know a directory will be receiving a series of changes that you do not want partially replicated, you can put one or more locks on the subdirectory in the export path. Until you remove the lock or locks, the subdirectory will not be replicated. The date and time the lock was placed is displayed so that you know how long a lock has been in force.
When you stabilize a subdirectory, the export server waits two minutes after changes before exporting the subdirectory. The waiting period allows time for subsequent changes to take place so that all intended changes are recorded before being replicated.
You specify whether the entire subtree (the export subdirectory and all of its subdirectories) or just the first-level subdirectory in the export directory path is exported.

Setting Up an Import Computer

Both Windows NT Server and Windows NT Workstation computers can be set up as import computers. A computer running Windows NT Server that is configured as an export server can also be configured as an import computer.

Before you set up an import computer, you must assign a logon account to the Directory Replicator service of the import computer.

On the import computer you do not need to create the imported subdirectories. A subdirectory is automatically created the first time it is imported.

Use the Directory Replication dialog box to set up an import computer. The Windows NT Server version of the Directory Replication dialog box is slightly different from the Windows NT Workstation version of this dialog box. The Windows NT Workstation version contains only the items related to imported directories.

Tip You can set up a server to replicate a directory tree to itself (from its export directory to its import directory). This replication can provide a local backup of the files, or you can use the import version of these files as another source for users to access, while preserving the export version of the files as a source master.

Managing Locks and Viewing Import Subdirectory Status

You can use locks to prevent imports to subdirectories on an import computer. Import of a locked subdirectory to that import computer is prevented until the lock is removed. Locking a subdirectory on an import computer affects replication to only that computer, not to other import computers.

You can manage locks on subdirectories and also view the status of each subdirectory by clicking Manage under Import Directories in the Directory Replication dialog box.

The Status column can have one of four entries:

OK indicates that the subdirectory is receiving regular updates from an export server and that the imported data is identical to that exported.
No Master indicates that the subdirectory is not receiving updates. The export server might not be running, or a lock might be in effect on the export server.
No Sync indicates that although the subdirectory has received updates the data is not up-to-date. This could be due to a communications failure, open files on the import computer or export server, the import computer not having access permissions at the export server, or an export server malfunction.
No entry (blank) indicates that replication never occurred for that subdirectory. Replication may not be properly configured for this import computer, for the export server, or both.

The Last Update column shows the date and time of the latest change to the import subdirectory or to any of its subdirectories.

Point-to-Point Tunneling Protocol (PPTP)

With the release of Windows NT Server 4.0, the ability to communicate securely over the Internet has become a reality. At Terra Flora, this will mean that Seville, Spain will be able to communicate with corporate headquarters using the Internet. Terra Flora will install computers running Windows NT at remote sites including Seville, Spain. Seville, Spain will be configured to use PPTP through a dial up Remote Access Service (RAS) connection to the Internet Information Server (IIS) at the Enterprise level named CANTS40ENT04.

The Decision to Use PPTP

The Seville, Spain site is a Nursery growing plants for distribution to the retail stores. It has become, by necessity, a distribution site, implementing the same distribution procedures as other distribution sites. Basically, a computer running Windows NT Server will be installed at the Seville, Spain site, along with other computers running Windows NT Workstation, in order to computerize the manual processes. Computerizing the Seville, Spain site will also allow Nursery personnel to focus on tasks other than the tasks performed by the computers at other nursery and distribution sites.

Remote Access Service (RAS) has been offered with Windows NT Server since the product was introduced. A RAS server is usually connected to a PSTN, ISDN or X.25 line allowing remote users to access a various network servers. RAS now allows remote users access through the Internet by using the new Point-to-Point Tunneling Protocol (PPTP). For detailed information on RAS, see the Microsoft Windows NT Server 4.0 Networking Supplement, Chapter 5, "Understanding Remote Access Service," Chapter 6, "Installing and Configuring Remote Access Service" and Chapter 7, "RAS Security."

At Terra Flora, PPTP will be installed to enable remote users to access corporate networks securely across the Internet by dialing into an Internet Service Provider (ISP) or by connecting directly to the Internet. PPTP offers the following advantages:

Lower Transmission Costs

PPTP uses the Internet as a connection instead of a long-distance telephone number or 800 service. This can greatly reduce transmission costs.
Lower Administrative Overhead

With PPTP, network administrators centrally manage and secure their remote access networks at the RAS server. They need to manage only user accounts instead of supporting complex hardware configurations.
Enhanced Security

Above all, the PPTP connection over the Internet is encrypted and secure, and it works with any protocol (including, IP, IPX, and NetBEUI).

Applications for PPTP

PPTP provides a way to route Point-to-Point Protocol (PPP) packets over an IP, IPX or NetBEUI network. Since PPTP allows multiprotocol encapsulation, Terra Flora can send any type of packet over the network.

PPTP treats the existing corporate network as a PSTN, ISDN, or X.25 network. This virtual WAN is supported through public carriers, such as the Internet.

Compare PPTP to the other WAN protocols: When using PSTN, ISDN, or X.25, a remote access client establishes a PPP connection with a RAS server over a switched network. After the connection is established, PPP packets are sent over the switched connection to the RAS servers to be routed to the destination LAN.

In contrast, when using PPTP instead of a switched connection to send packets over the WAN, a transport protocol such as TCP/IP is used to send the PPP packets to the RAS server over the virtual WAN.

The end benefit for the corporation is a savings in transmission costs by using the Internet rather than long distance dial-up connections.

Secure Access to Corporate Networks over the Internet

A RAS client that has PPTP as its WAN protocol can access resources on a remote LAN by connecting to a Windows NT RAS server through the Internet. There are two ways to do this: By connecting directly to the Internet or by dialing an Internet Service Provider (ISP) as shown in the following examples.

The client that is directly connected on the Internet dials the number for the RAS server. PPTP on the client makes a tunnel through the Internet and connects to the PPTP enabled adapter on the RAS server. After authentication, the client can access the corporate network, as shown in the figure below.

Note: Connecting directly to the Internet means direct IP access without going through an ISP. (For example, some hotels allow you to use an Ethernet cable to gain a direct connection to the Internet.)

xng_h21

The same functionality is achieved by calling an ISP instead of being directly connected to the Internet. The client first makes a call to the ISP. After that connection is established, the client makes another call to the RAS sever located anywhere on the Internet or the ISP and that establishes the PPTP tunnel.

xng_h22

At Terra Flora, the clients are directly connected to the Internet, no ISP is used. The RAS servers at headquarters and Seville will dial directly into the Internet.

Security Considerations

Data sent across the PPTP tunnel is encapsulated in PPP packets. Because RAS supports encryption, the data will be encrypted. RAS supports bulk data encryption using RSA RC4 and a 40-bit session key that is negotiated at PPP connect time between the RAS client and the Windows NT RAS server.

PPTP uses the Password Authentication Protocol and the Challenge Handshake Authentication Protocol encryption algorithms.

In addition to supporting encrypted PPP links across the Internet, a PPTP-based solution also enables the Internet to become a network backbone for carrying IPX and NetBEUI remote-access traffic. PPTP can transfer IPX traffic because it encapsulates and encrypts PPP packets so that they can ride TCP/IP. Thus, a solution does not depend only on TCP/IP LANs.

This technology gives Terra Flora the opportunity to send sensitive materials over the Internet, an option that they haven't had previously. They will use this connection to collect general ledger information from Seville and to provide to Seville marketing information such as product special pricing and corporate advertisements which will be incorporated into network web pages.

Installing PPTP

You must have the PPTP protocol installed on the RAS servers and on the client or communications servers.

To Install PPTP

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Protocols Tab.
Select Point-to-Point Protocol, and then click Add.
Click Have Disk if loading the software from disks or a CD.

Or, click OK if loading from the network.
When prompted, type the full path to the Windows NT Server PPTP files, and then click OK.
Enter the number of connections you want available to PPTP (that is, for Virtual Private Networks).
RAS setup will start and add the PPTP protocol to RAS.

You must restart your computer to complete the installation.

Protecting a RAS Server from Internet Attacks

If PPTP filtering is selected, the selected network adapter for all other protocols is effectively disabled. Only PPTP packets will be allowed in.

Terra Flora will want to do this on all multihomed computers with one network adapter (with PPTP filtering enabled) connected to the Internet and another network adapter connected to the internal corporate network. Clients outside the corporate network can use PPTP to connect to the computer from across the Internet and gain secure access to the corporate network. Thus, the only traffic that can access the corporate network is PPTP packets from clients who have been authenticated using RAS authentication.

Note: The RAS client can either be connected to the Internet directly or to a service provider. It is not necessary to be connected to both to use PPTP.

To install PPTP filtering for protection

Click Start, point to Settings, and click Control Panel.
Double-click Network.
Click the Protocols tab.
Click TCP/IP Protocol.
Click Properties.
Click the IP Address tab, if necessary, and then click Advanced.
In Adapter, click the network adapter for which you want to specify PPTP filtering.

The PPTP filtering settings in this dialog box are defined only for the selected network adapter.
To enable PPTP filtering, click Enable PPTP Filtering.

You must restart the computer to have the settings take effect.

For more information about advanced TCP/IP configuration, see the topic "To Configure Advanced TCP/IP Options" in the TCP/IP online Help file.

Chapter 5 - Network Services: Enterprise Level

On This Page

Preparations for Configuring Services

Selecting Protocol Standards

Installing and Configuring TCP/IP

Dynamic IP Addressing

Terra Flora's Choice of Addressing Services

Configuring DHCP

Name Resolution Using WINS and DNS

The Decision to Use WINS

Installing and Configuring WINS

The Decision to Integrate DNS with WINS

Installing DNS Service

Managing DNS Servers

Integrating DHCP, WINS, and DNS in Heterogeneous Networks

Network Logon Services

The Decision to Centralize Logon Services

UNIX Clients Authenticating to Windows NT Servers

Mapping UNIX Passwords to Windows NT User Accounts

Windows NT Clients Authenticating to UNIX Servers

Windows NT Clients Authenticating to NetWare Servers

NetWare Clients Authenticating to Windows NT Servers

Windows NT Clients Authenticating to Banyan Servers

Banyan Clients Authenticating to Windows NT Servers

Windows 3.1 Clients Authenticating to Windows NT Servers

MS-DOS Clients Authenticating to Windows NT Servers

Windows For Workgroups Clients Authenticating to Windows NT Servers

Windows 95 Clients Authenticating to Windows NT servers

Macintosh Clients Authenticating to Windows NT Servers

Centralized Services

The Decision to Centralize Administrative Tasks

UNIX Administration

NetWare Administration

Banyan Administration

Windows NT Connectivity and Administration

Replication and Backup Services

Terra Flora's Decisions About Replication

Terra Flora's Decisions About Backup

Backup of the DHCP Directory and Files

Point-to-Point Tunneling Protocol (PPTP)

The Decision to Use PPTP

Secure Access to Corporate Networks over the Internet

Installing PPTP

Protecting a RAS Server from Internet Attacks

Additional resources