http://www.microsoft.com/TechNet/boes/bo/winntas/technote/nt302.htm (PC Press Internet CD, 03/1996)
| Updated: March 13,1996 |  Go To TechNet Home Page |
As an open operating system Microsoft® Windows NT™ supports interoperability with TCP/IP, NetWare®, UNIX®, Macintosh®, and migration from Novell® NetWare. To successfully make this happen you need to know what features are available, installation considerations, and the potential problems to be prepared for.
At the end of this session you will be able to install and configure the following platforms for Microsoft Windows NT:
TCP/IP
Novell NetWare
Macintosh
UNIX
Interoperating with TCP/IP
Interoperating with Macintosh
Interoperating with UNIX
A significant difference between the Microsoft Windows NT™ Server operating system and other operating systems is that networking capabilities are built into Windows NT Server.
Because most modern operating systems (including Windows NT) support TCP/IP protocols, an internetwork with mixed system types can share information using simple networking applications and utilities. With TCP/IP as a connectivity protocol, Windows NT can communicate with many non-Microsoft systems.
Microsoft TCP/IP on Windows NT enables enterprise networking and connectivity on Windows NT-based computers. Adding TCP/IP to a Windows NT configuration offers the following advantages:
A standard, routable enterprise networking protocol that is the most complete and accepted protocol available. All modern operating systems offer TCP/IP support, and most large networks rely on TCP/IP for much of their network traffic.
A technology for connecting dissimilar systems. Many standard connectivity utilities are available to access and transfer data between dissimilar systems, including File Transfer Protocol (FTP) and Terminal Emulation Protocol (Telnet). Several of these standard utilities are included with Windows NT.
A method of gaining access to the Internet. The Internet consists of thousands of networks worldwide connecting research facilities, universities, libraries, and private companies. The Microsoft Windows NT 3.5 Resource Kit includes a number of utilities for Internet access, including WWW (World Wide Web) and Gopher.
A robust, scaleable, cross-platform client-server framework. Microsoft TCP/IP offers the Windows® Sockets interface, which is ideal for developing clientserver applications that can run on Windows Sockets-compliant stacks from other vendors.
Microsoft Windows NT 3.5 includes many TCP/IP integration components, including:
Before you install Microsoft TCP/IP, it is important to know the required configuration parameters. If you are installing Windows NT Server in a routed network environment, there are three parameters required for each computer running TCP/IP: IP address, subnet mask, and default gateway.
Every host interface on a TCP/IP network is identified by a unique IP address. This address is used to identify a host on a network; it also specifies routing information in an internetwork. An IP address consists of 32 bits divided into four octets, or fields. An address is usually represented in dotted decimal notation, which depicts each octet in its decimal value and separates each octet with a period. Windows NT supports class A, B and C IP addresses.
Because IP addresses identify hosts on an interconnected network, each host on the internetwork must be assigned a unique IP address, valid for its particular network.
If you plan on connecting your network to the worldwide Internet, you must obtain the network ID portion of the IP address from InterNIC to guarantee IP network ID uniqueness. The InterNIC can be contacted through electronic e-mail at info@internic.net (for the United States, 1-800-444-4345 or, for Canada and overseas, 619-455-4600).
If you do not plan on connecting to the worldwide Internet, you can use any valid network ID, which is determined by its address class.
A subnet mask is used to "mask" a portion of the IP address so that TCP/IP can distinguish the network ID from the host ID. When TCP/IP hosts communicate, the subnet mask is used to determine whether a host is located on a local or a remote network.
A default subnet mask is used for TCP/IP networks that are not interconnected or that do not use a network ID assigned by the InterNIC. Windows NT has a default subnet mask for each address class:
Class A: 255.0.0.0
Class B: 255.255.0.0
Class C: 255.255.255.0
For example, if your IP address is 131.107.126.88, and your network is a local area network, you use the default subnet mask for a class B address; 255.255.0.0.
A custom subnet mask is often required when you have only one network ID. For example, if the InterNIC assigns your company one network ID, and you have a wide area network consisting of multiple sites, you would define a custom subnet mask for your network ID that is based on the number of subnets and the number of hosts required on each subnet. Custom subnet masks allow you to use the single network ID for all subnets.
For communication with a host on another network, an IP address must be configured for a router with a route to the destination network. If no route is found to the destination network, the default gateway is used. If you do not specify a default gateway, communications are limited to the local network and to networks with entries in the local route table.
Whenever IP prepares to send a packet, it first determines whether the destination host is on a different network. If it is, the request is sent to a router that can communicate with the destination network. If no route to the destination network is found on the local host, the request is sent to the default gateway. A default gateway is simply the router to use for all remote requests when no other path to that network can be found.
The TCP/IP protocol is fully integrated into Windows NT. This means that no additional software is required for installation. Installing TCP/IP on Windows NT is similar to adding any other network component.
TCP/IP is installed through Control Panel Network. Choose Add Software and select TCP/IP Protocol and Related Components. You will then be prompted to install the configuration options. The default configuration includes TCP/IP Internetworking and Connectivity Utilities.
TCP/IP Internetworking is the actual TCP/IP protocol stack for basic communications with other Microsoft TCP/IP computers. This is a required component.
Connectivity Utilities include the utilities to communicate with other TCP/IP hosts, using FTP, Telnet, and so on. This is selected by default, but can be cleared if there are no requirements for communicating using standard TCP/IP utilities.
After completing the default installation options you will be prompted for a path to the Windows NT distribution files. Type the path to the location of Windows NT distribution files, and the TCP/IP software is installed on the local computer.
Installing TCP/IP requires careful configuration of an IP address, subnet mask, and default gateway. An error in typing the IP address, subnet mask, or default gateway can lead to problems. Problems can range from trouble communicating by means of TCP/IP if the default gateway or subnet mask is wrong, to network problems with a duplicate IP address.
TCP/IP parameters can be configured in two ways-manually by the user, or dynamically using a Dynamic Host Configuration Protocol (DHCP) server. Configuring TCP/IP manually presents the possibility of having multiple computers configured with the same IP address. Duplicate IP addresses cause IP communications to fail. Configuring TCP/IP dynamically with DHCP reduces the chance of having duplicate IP addresses.
To configure TCP/IP manually, from the TCP/IP Configuration dialog box, enter correct values for each parameter (IP address, subnet mask, and default gateway).
One of the new TCP/IP components added to Windows NT Server 3.5 is that of DHCP Server support. Implementing DHCP eliminates some of the configuration problems associated with manually configuring TCP/IP. DHCP centralizes TCP/IP configurations and manages the allocation of TCP/IP configuration information by automatically assigning IP addresses to computers configured to use DHCP.
Using DHCP to configure IP addressing information automatically means that:
Users no longer have to get IP addressing information from an administrator to configure TCP/IP properly. When a DHCP client is started, it automatically receives, or leases, IP addressing information from a DHCP server.
The DHCP server supplies all the necessary configuration information to all the DHCP clients. As long as the DHCP server has the correct configuration information, none of the clients or servers will be configured incorrectly.
The difficult-to-trace network problems that result from incorrectly configured clients and servers will be completely eliminated.
To implement DHCP, software is required on both the client and the server.
A DHCP server requires:
The DHCP server service configured on at least one computer within the TCP/IP internetwork running Windows NT Server, as long as your IP routers support Request for Comment (RFC) 1542. Otherwise, you will need a DHCP server on each subnet.
A DHCP scope created on the DHCP server. A DHCP scope consists of a pool of IP addresses, such as 131.107.3.51 through 131.107.3.200, which the DHCP server can assign, or lease, to DHCP clients.
A DHCP client requires:
A computer running a DHCP-supported operating system. The following operating systems are capable of being a DHCP client:
Windows NT Server 3.5
Windows NT Workstation 3.5
Microsoft Windows® for Workgroups 3.11 with the Microsoft 32-bit TCP/IP VxD installed (provided on the Windows NT Server 3.5 CD)
Microsoft Network Client 3.0 for MSDOS® with the real mode TCP/IP driver included on the Windows NT Server 3.5 CD
LAN Manager 2.2c included on the Windows NT Server 3.5 CD
DHCP enabled at the client
Each time the DHCP client restarts, it requests IP addressing information from a DHCP server.
When the DHCP server receives the request, it selects an unleased IP address from its pool of IP addresses and offers it to the DHCP client. In most cases, the DHCP server also returns additional TCP/IP configuration information, such as the subnet mask and default gateway.
If there is no available IP addressing information in the pool to lease to a client, the client is unable to bind TCP/IP. IP addressing information is leased to a client until the client manually releases it, or until the DHCP server cancels the lease and makes it available to other clients.
You install a DHCP server as part of the process of installing Microsoft TCP/IP. It is important to note that even though the process might be somewhat familiar to you, it is usually done after carefully planning and developing a strategy for implementing DHCP in a TCP/IP internetwork.
After the DHCP Server service has been installed and initialized on Windows NT, you must create a range of addresses before the server can assign addresses to requesting clients. The scope must be configured to supply a client computer with the following information:
A range or pool of addresses from which the DHCP server can draw to lease to clients
A subnet mask to be assigned to clients
Optionally, the DHCP server can provide additional TCP/IP configuration parameters to the client, such as the following:
Default gateway address
Domain Name Service (DNS) server address(es)
WINS server address(es)
NetBIOS name resolution type
Configure a DHCP scope from the Network Administration DHCP Manager. During this configuration you will be prompted to create a pool of IP addresses. From the Scope menu, choose Create. This pool of IP addresses allows for DHCP clients to receive address leases from the DHCP server.
You enable a client to use DHCP as part of the process of installing Microsoft TCP/IP. If you installed and configured TCP/IP manually, you can modify the TCP/IP configuration to take advantage of DHCP. This solves the problem of configuring duplicate IP addresses.
You configure TCP/IP automatically using DHCP from Control Panel Network. In the TCP/IP Configuration dialog box, select Enable Automatic DHCP Configuration, and restart the computer.
You can verify the DHCP configuration from the command prompt by using IPCONFIG /ALL.
Two common DHCP configuration problems are:
Routing of DHCP messages requires the IP router to support (RFC 1542). Verify your router supports this. If not, a DHCP Server is required on each subnet that will support DHCP clients.
Make sure to exclude IP addresses of non-DHCP clients from the DHCP scope. Failure to do so can result in duplicate IP addresses on the network.
The Windows Internet Name Service (WINS) was designed to eliminate the need for broadcasts to resolve computer names to IP addresses and provide a dynamic database that maintains computer name to IP address mappings.
When using TCP/IP to communicate on a network, the computer name that is used when accessing network resources must be resolved to an IP address. This is necessary because TCP/IP does not know how to establish communication with a computer name, such as STUDENT3, but does know how to communicate with an IP address, such as 131.107.3.13. To resolve the computer name to its IP address, TCP/IP can use a variety of methods-broadcasts, a static mapping file (LMHOSTS), or a WINS server. Both servers and clients use WINS.
A WINS server maintains a database that maps the NetBIOS computer names of WINS clients to their IP addresses. WINS clients request the IP address for the desired computer from a WINS server, which retrieves the IP address from its database instead of using broadcasts.
WINS clients are configured with the IP address of one or more WINS servers. On startup, WINS clients communicate directly with a WINS server to register their computer name and corresponding IP address. When a WINS client needs to resolve a computer name to an IP address, such as when connecting to \\STUDENT3\share, the WINS client sends a request to the WINS server for the IP address of the computer name being used.
WINS clients are configured during the configuration of TCP/IP by providing the IP address of the primary and secondary WINS servers.
To implement WINS, software is required on both the client and the server for the NetBIOS computer name to IP address resolution to occur. The following operating systems are capable of being WINS clients:
Windows NT Server 3.5
Windows NT Workstation 3.5
Windows for Workgroups 3.11 with the Microsoft 32-bit TCP/IP VxD installed (provided on the Windows NT Server 3.5 CD)
Microsoft Network Client 3.0 for MSDOS with the real mode TCP/IP driver included on the Windows NT Server 3.5 CD
LAN Manager 2.2c included on the Windows NT Server 3.5 CD
Other clients that are not WINS-enabled can access WINS servers using normal name resolution methods. Static mappings can be added to the WINS database for the hosts that are not WINS-enabled. This allows WINS clients to use the WINS server to resolve names, even for non-WINS enabled hosts.
To understand why WINS is beneficial in configuring TCP/IP on client computers, it is helpful to contrast the WINS method of NetBIOS name resolution with the non-WINS method.
When a client wants to establish a NetBIOS session with another NetBIOS host, it must first resolve the destination hosts NetBIOS computer name to an IP address. This can be accomplished by the following methods:
B-node - The local client broadcasts a NetBIOS name query request, hoping the destination host hears it, and responds.
Enhanced B-node - The local client can check a local file (LMHOSTS) for resolution. If the local resolution is successful, a directed request is sent to the destination host.
P-node - The client will send a request directly to a NetBIOS Name Server to locate the destination NetBIOS host. No broadcasts are sent for name resolution, even if the Name Server is not available.
M-node - The client will broadcast for name resolution initially, then attempt to use the NetBIOS Name Server if the broadcast fails to resolve the name.
Each of these methods has disadvantages that are overcome with the WINS method.
The Windows Internet Name Service is a combination of the previous methods, using the best features of each method. By default, WINS uses H-node resolution, in which the host first attempts to register and resolve NetBIOS names using the NetBIOS Name Server (WINS), and if not successful, using broadcasts.
WINS provides the following advantages:
First uses directed sends rather than broadcasts which alleviates network traffic. WINS clients can still use broadcasts to locate local NetBIOS resources if the WINS server is down. If the WINS server is down, the WINS client will retry the WINS server on the next attempt even if the broadcast was successful.
A dynamic database, which is kept current even when a client changes its IP address, for example due to a new DHCP IP address allocation.
Eliminates the need for an LMHOSTS file to be maintained at any of the TCP/IP hosts.
Provides internetwork and inter-domain browsing without configuring and maintaining the an LMHOSTS file.
The WINS process involves client to server communication. The WINS clients register their NetBIOS names with the WINS server. The registered name is stored in a database at the server.
The WINS server registers names on a temporary basis so the name might later be reused if the client stops using it.
WINS clients are responsible for maintaining the leases on its registered names and informing the WINS server when the name is no longer in use. This is done by sending the WINS server a release message.
After the WINS clients have registered their names with a WINS server, clients can communicate with each other by obtaining the IP address of a NetBIOS computer from a WINS server.
Novell NetWare is a very popular network operating system. Windows NT 3.5 includes various components that allow you to connect to a Novell NetWare network.
If part of your computer resources are on a Novell NetWare network, your Windows NT network will have to communicate and share resources with the NetWare network. With Windows NT, NWLink protocol, Client Service for NetWare (CSNW), and Gateway Service for NetWare (GSNW), Microsoft network clients can now communicate and share resources with a NetWare network. This is possible even though the Microsoft network clients have no NetWare client software installed.
A NetWare client can access data stored on a NetWare server by directly accessing the NetWare server and the Windows NT Server computer that is running NWLink through clientserver applications. The Microsoft network client can access the NetWare server through the Windows NT server running the Gateway Service for NetWare. A Windows NT computer can access resources on the NetWare server as a client through the integrated Client Service for NetWare component.
NWLink is an implementation of the Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) protocol used in NetWare networks. The NWLink Transport Protocol is a native 32bit Windows NT implementation of IPX/SPX.
A Windows NT Server computer configured with NWLink can be used as an application server for NetWare clients. Microsoft NWLink is a Network Device Interface Specification (NDIS)-compliant version of the IPX/SPX protocol, which is used on Novell NetWare networks. NWLink allows computers running Windows NT to communicate with other Windows NT computers or NetWare servers. Two networking Application Programming Interfaces (APIs) are supported to allow this communication:
Windows Sockets-This interface supports existing NetWare applications written to comply with the NetWare IPX/SPX Sockets interface.
NetBIOS-This interface supports sending and receiving Novell NetBIOS packets between a NetWare workstation running Novell NetBIOS and a Windows NT computer running NWLink NetBIOS.
NWLink also provides NetWare clients access to Windows NT Server applications such as Microsoft SQL Server™ and SNA Server.
Windows NT Server computers running NWLink can support client applications for MSDOS, OS/2®, Windows, or Windows NT computers through a variety of communications mechanisms, such as Windows Sockets, Remote Procedure Calls (RPC), or Novell NetBIOS, over the IPX/SPX transport.
The NWLink protocol has many features to enhance communication on a Windows NT network.
SPX II-NWLink supports Windows Sockets on the new Novell SPX II protocol. SPX II has been enhanced to support windowing and has the ability to set a maximum frame size.
Multiple Bindings-NWLink can be bound to multiple network adapters with multiple frame types.
Frame Type Auto Detect-NWLink automatically detects which frame type is being used on the network during startup and uses that frame type. If there are multiple frame types detected, NWLink defaults to the 802.2 frame type.
Direct hosting over IPX-The Windows NT Server service (not the redirector) supports direct hosting technology. This allows Windows for Workgroups 3.11 clients to communicate up to 20 percent faster than they could using NetBIOS over IPX with Windows NT 3.5 computers.
Two terms, frame type and binding, are important to understand when working with a NetWare environment.
Frame type is the way in which the network adapter formats the data to be put on the network. NetWare IPX clients and servers can be configured for different frame types, but for the computers to communicate, they must be configured for the same frame type. For example, if a NetWare client's IPX protocol is bound to the 802.2 frame type, the NetWare server's IPX has to be bound to an 802.2 frame type. Also, each supported topology (Ethernet, Token Ring, FDDILink™, and ArcNet®) requires a different format.
Binding is the process of associating a protocol driver with the network adapter with which it will work, and establishing a communication channel between the two.
The Auto Frame Type Detection allows Windows NT to determine which IPX frame type is being used on the network and to set the NWLink frame type automatically. NWLink checks frames being passed to the network card to which the protocol is bound. If it detects frames of the type 802.2 or no frames at all, it sets the frame type to 802.2. Otherwise, it sets the frame type to whatever is being passed on the network.
Although frame types are automatically detected during installation of Windows NT 3.5, it is still considered a good practice to doublecheck that the correct frame type was detected.
The NWLink protocol in Windows NT Server 3.5 can use multiple frame types on a single network adapter. This can be done on a Windows NT Server computer by configuring NWLink in the Control Panel Network application and manually selecting the frame types to be used on the network adapter.
NWLink is installed by default during the Windows NT installation. Because NWLink operates through the NDIS 3.0 stack, the NWLink protocol can be run on any network adapter card that uses an NDIScompatible driver.
When NWLink is installed in Windows NT, the frame type is set to Auto Frame Type Detection by default. This allows Windows NT to determine which IPX frame type is being used on the network and set the NWLink frame type accordingly.
You install the NWLink protocol through the Control Panel Network Add Software option.
To confirm the NWLink installation view the configuration of NWLink under Network settings in Control Panel.
There are a couple of common problems associated with NWLink. The first is that some people think that by installing NWLink, they can access file and print resources on a NetWare server. NWLink is only a transport protocol, not a redirector. To access file and print resources, the computer will need client redirector, such as CSNW or GSNW.
The second problem is that with the default setting of Autodetect Frame Type, the frame type is set to that of the first frame received, and not configured to communicate over all detected frame types. You may need to manually configure the appropriate frame types for your installation.
Client Service for NetWare (CSNW) is a fully native implementation of a NetWare redirector for Windows NT Workstation. It is implemented as native 32-bit Windows NT code, and it includes a service and a device driver. CSNW takes full advantage of the advanced networking architecture of Windows NT, and it provides access to NetWare file and print services.
To access files or printers on a NetWare server, you need to use CSNW with NWLink. CSNW provides the following functionality:
Allows users to access NetWare file and print servers.
16-bit NetWare application support. The NetWare SYSCON, FCONSOLE, PCONSOLE, and RCONSOLE utilities, and others, have been tested by Microsoft for use with CSNW. A complete list of supported NetWare utilities can be found in the Windows NT Workstation documentation.
Support for the following protocols:
Long File Name (LFN) Support, when the NetWare server is running the OS/2 name space (OS2.NLM).
Because CSNW uses the NWLink IPX/SPX protocol, the NWLink transport should be installed before CSNW. If NWLink is not installed before installing CSNW, it will automatically be installed during the CSNW installation. After it is installed, CSNW can be used to access file and print services on NetWare 2.x, 3.x, and 4.0 (with bindery emulation) file servers, as NetWare clients do.
The Client Service for NetWare does not support the new NetWare 4.x NetWare Directory Services (NDS). NetWare 4.x servers must have bindery emulation enabled before Client Service for NetWare users can access them. It is enabled by default with the NetWare 4.x installation program.
The first time the client computer is restarted after Client Service for NetWare has been installed, the user is asked to choose a preferred server. Any NetWare servers found on the network are listed and available for the user to choose.
The preferred server is used to validate the user at Windows NT logon. A different server can be chosen for each Windows NT user, or the user can select None and not be validated by a NetWare server. The user name and password that were used to log on to Windows NT are used to validate the user on NetWare servers. It is best to keep your user name and password on NetWare servers identical to what you use when logging on to Windows NT. This allows you to use NetWare servers without having to supply another user name and password. It also makes it easier for network administrators to coordinate user accounts.
Important NetWare logon scripts will not execute on Windows NT. If the user has NetWare logon scripts to run during logon, they will have to be recreated on Windows NT. Some NetWare-specific logon commands cannot be recreated without additional utilities. The Windows NT Resource Kit includes a number of utilities that allow you to duplicate NetWare logon scripts for Windows NT users.
When CSNW is installed, an icon labeled CSNW is created in Control Panel. If you find it necessary to change the designated preferred server, you can use the CSNW utility to do so.
One feature of Windows NT Server is its ability to access files and printers on a Novell NetWare server. This is accomplished by using the Gateway Service for NetWare (GSNW).
Microsoft Gateway Service for NetWare (GSNW) is a 32-bit Windows NT service. In combination with NWLink, GSNW allows a Windows NT Server to access files or printers on a Novell NetWare server (the same functionality as CSNW). The service also allows a Windows NT Server to act as a non-dedicated gateway to NetWare file systems for any Server Message Block (SMB) client, including Windows for Workgroups, Windows NT, or any Microsoft networking client.
GSNW can be used to access file and print services on NetWare 2.x and 3.x file servers, and on NetWare 4.x file servers running bindery emulation. GSNW does not support the NetWare 4.x NetWare Directory Services (NDS).
Microsoft designed this service for users who only occasionally need access to NetWare servers and prefer not to have the memory overhead associated with running multiple redirectors on their own computers.
With GSNW, the Windows NT Server computer connects to the NetWare file server's directory and then shares it, just as if the directory were on the Windows NT computer. Microsoft network clients can then access the directory on the NetWare server by connecting to the share created on the Windows NT Server computer.
For a Windows NT Server to act as a gateway to resources on a NetWare server, the NetWare server must have a group named NTGATEWAY. In addition, the user name to be used as the gateway account must be included in the group NTGATEWAY. Use the NetWare Syscon utility to create the group and user account.
Any resources that you want to be shared through the gateway must be made available to the members of the group NTGATEWAY through the Syscon Group options.
You install GSNW using the Control Panel Network application. The NWLink transport must be installed before installing GSNW, because GSNW requires the IPX protocol enabled by NWLink. It requires no files from Novell.
The frame type that NWLink uses must match the frame type being used on any NetWare servers that must be accessed.
When installation is complete, the computer must be restarted for the changes to take effect. The first time the computer restarts, the system requests the preferred server for the current user.
The GSNW installation creates a new icon, labeled GSNW, and adds it to Control Panel. GSNW is used to select the defaults for the preferred NetWare server and the NetWare print queue.
After the user account and group are set up and the installation is complete, the gateway can be configured. This is done through the Gateway Service for NetWare application in Control Panel.
To configure GSNW, you must do the following:
Select a server
Set up the gateway
Make a connection by establishing a sharable resource
To configure the Gateway Service for NetWare, you must select the preferred server for the Gateway to connect to. This is done from the Select Preferred Server drop-down list box in the Gateway Service for NetWare dialog box.
After the preferred server has been selected, Windows NT attempts to connect to the NetWare server. If the attempt to make the connection is unsuccessful, you are given the opportunity to select another preferred server.
To set up the gateway, check the Enable Gateway box and add the Gateway's user account and password that were created earlier. Remember that this user account must be a member of the NTGATEWAY group on the NetWare server.
The Gateway must establish a connection to the NetWare server to provide transparent access to NetWare resources.
To set up directories to be available on the Windows NT Server system from the NetWare server, you choose the Gateway button in the Gateway Service for NetWare dialog box.
You use Print Manager to connect to a NetWare print queue and select the Share This Printer on the Network check box to enable the computer to act as a NetWare print queue gateway.
Network paths must be provided using UNC syntax, for example \\NW311\SYS\USERS.
The only security that is available for the Gateway resources is on the shared directories.
The following permissions are available:
No Access. No access is allowed to files or subdirectories.
Read. User is granted access to Read files and subdirectories.
Change. User is granted access to Read, Change, and Delete both files and subdirectories.
Full Control. Allows user to Read, Write, Delete, and Change files.
The default permissions for gateway-shared directories are Full Control for Everyone.
Any file level security has to be assigned to the NetWare user account specified when the Gateway was enabled. For example, if the SUPERVISOR account was used when the Gateway was enabled, all file-level rights are assigned to users who are accessing files through the Gateway. The only way to change these rights would be to change the share-level permissions for the Windows NT Gateway share. You have to decide whether file-level security is needed. If it is, you can assign the correct rights to the user account that is used by the Gateway.
The Add Users and Groups dialog box is used to add users and groups to the permissions list for a Gateway Service for NetWare resource. This dialog box determines which users can access the shared resource. Physical access is granted to the NTGATEWAY account at the NetWare server.
After the NetWare client support is configured (either CSNW or GSNW), you can use both File Manager and Print Manager to access directories and print queues on a NetWare server.
Users can connect to directories on NetWare file servers using File Manager. With File Manager, users can browse and connect to resources on both Windows NT computers and NetWare computers. After being connected to a NetWare drive, users can simply drag and drop directories and files.
On NetWare networks, the servers, volumes, and directories are organized in a treelike structure. Both volumes and directories are represented by the shared directory icon.
NetWare server volumes, directories, and print queues can be represented by their universal naming convention (UNC) names:
\\NetWare_Server\volume\directory
NetWare syntax is also supported:
NetWare_Server/volume:directory
To print to a NetWare print queue, users connect to it using Print Manager. When you connect to a NetWare print queue, you are prompted to install a local printer driver.
If the NetWare system is first in the network search order for print providers, the list of servers on the NetWare system is automatically displayed in the Shared Printers box. After connecting, users can print to the NetWare print queue, just as they would to a Windows NT print queue.
The printing options that are supported for NetWare print queues include settings for:
Form feeds
Print notification
Banner pages
Printing options are set for the user who is logged on to Windows NT. Settings affect all NetWare print queues used from a given Windows NT workstation.
To further assist in the integration of Microsoft Windows NT into a Novell NetWare environment, Microsoft has developed File and Print Service for NetWare (currently in beta testing).
The File and Print Service for NetWare allows a Novell NetWare client (running standard Novell client software) to access file and print resources on a Microsoft Windows NT Server computer. Nothing changes on the client side, they access resources as they normally would. The server they connect to, may now be a Microsoft Windows NT Server computer, though to the user, it will function as a NetWare server.
This add-on product makes a Windows NT Server computer look like a NetWare 3.x server providing file and print resources. This offers the following advantages:
Client computers remain intact running current client software
Simultaneous connections to Novell NetWare and Windows NT 3.5 Server computers
Integration with the advanced computing platform of Windows NT Server
Helps ease migration from NetWare to Windows NT
The Windows NT Server Migration Tool for NetWare (NWConv) allows you to migrate NetWare servers to computers running Windows NT Server. The Migration Tool transfers user and group accounts, and directories and files from NetWare servers to Windows NT Server domain controllers. Account information can optionally be copied to a separate domain controller.
The Migration Tool allows you to:
Preserve appropriate user account information
Control how user and group names are transferred
Set passwords for transferred accounts
Control how account restrictions and administrative rights are transferred
Select the directories and files to transfer
Select a destination for transferred directories and files
Preserve effect rights on directories and files
Additionally, the Migration Tool allows the administrator to run a trial migration that goes through checking and converting all objects without actually moving users or files to a Windows NT Server domain controller. This allows the administrator to check for errors before running the actual migration.
Note The Migration Tool does not change a NetWare server into a Windows NT Server. It is used for copying files and bindery information to a separate Windows NT Server domain controller. (The bindery is a NetWare database that stores information, such as user accounts, passwords, shared resource information, and group account information.)
To successfully transfer directory and file rights with the Migration Tool, the following requirements must be met:
You must be migrating from NetWare 2.x, 3.x, or 4.x (using bindery emulation mode).
Access Privileges-To run the Migration Tool the user must have Supervisor privileges on the NetWare Server, and also be a member of the Administrators group on the Windows NT Server domain.
The destination drive must be a Windows NT Server NTFS partition. Files and directories transferred to a non-NTFS partition will lose all permissions.
The Gateway Service for NetWare (GSNW) must be started on the Windows NT Server computer, as it uses the NetWare connectivity to communicate between the NetWare server and the Windows NT Server domain controller.
The Migration Tool assumes that all necessary trust relationships are established on the Windows NT Server domain. This is important if you transfer account information to a primary domain controller in a different domain.
Although the Migration Tool eases the conversion from NetWare to a Windows NT Server computer, differences between the two operating systems still require that some decisions be made prior to starting the migration. The Migration Tool provides options to allow flexibility in the transfer of users, groups, and files.
In a multiple NetWare server environment, it is common to find the same user or group entered in the binderies of more than one server. When migrating from the NetWare environment, you must consider how you will manage duplicate NetWare accounts (users or groups).
Because Windows NT Server uses the domain model, account names are required to be unique within the domain. When duplicate names are encountered during the migration, they will overwrite the existing account, be logged as errors, be ignored, or migrated by adding a prefix to the NetWare user name, depending on the user option chosen.
The Migration Tool does not automatically transfer Supervisor privilege equivalents to the Domain Admins group on a computer running Windows NT Server. The operator can override this default in the User Options under Supervisors.
NetWare assigns restrictions on an account-by-account basis. Some of these restrictions are implemented in Windows NT Server through account policies instead of being based on the individual user.
The Migration Tool will transfer most NetWare user account information, files, and directories. However, some of the NetWare settings do not directly translate to Windows NT Server.
The Migration Tool will migrate the following NetWare information.
User accounts
Group accounts
Account permissions where applicable
Directory structures
Files
The Migration Tool will not migrate the following NetWare information.
Login scripts - Windows NT logon scripts provide similar functionality.
Print server and queue information - Printers can be set up as either Windows NT printers, or, with GSNW and NWLink in use as a Gateway, clients from both NetWare and Windows-based networks can use the NetWare printers.
User-defined objects - These Bindery database objects have no Windows NT Server equivalent.
Workgroup and user account managers - There is no equivalent group in Windows NT Server. The User Account Managers is just a concept, not a real group in the binderies.
Passwords - Windows NT Server does not have the ability to read NetWare passwords.
Because NetWare does not implement all rights in the same way as Windows NT Server, translations are made when there is an equivalent permission. If there is not an equivalent permission, the right is dropped during migration.
The following table shows the NetWare rights and the equivalent Windows NT Server permissions.
NetWare rights Windows NT Server
permissions
Supervisor (S) Full Control (All)
Read (R) Read (RX)
Write (W) Change (RWXD)
Erase (E) Change (RWXD)
Modify (M) Change (RWXD)
Create (C) No equivalent
File Scan (F) No equivalent
Access Control (A) Change Permissions (P)
The first time you start the Migration, the Migration Tool for NetWare dialog box is displayed so that you can choose the NetWare and Windows NT Server domain controller you want to use.
To select a NetWare server to migrate, you must have Supervisor rights on the server. To transfer data to a Windows NT Server computer, you must be a member of the Administrators group.
1. From the File menu in Program Manager, choose Run.
2. In the Command Line box, type nwconv and then choose OK.
The program will prompt you for both the NetWare server and the destination Windows NT Server computer.
1. Choose the Add button.
The Select Servers for Migration dialog box appears.
2. In the From NetWare Server box, type the name of the source NetWare server or choose the Browse button for a list of servers.
3. In the To Windows NT Server box, type the name of the destination Windows NT Server computer, or choose the Browse button for a list of domains and computers.
4. Choose the OK button.
By default, all user accounts are transferred from the selected NetWare server to the domain of the selected Windows NT Server computer, except when there is a name conflict. When a username on the NetWare server is identical to a username on the Windows NT domain, the account is not transferred, and an error is logged. When a group name is identical, the account is not transferred and no error is logged. You can change user and group options for transferring user and groups.
1. From the Migration Tool for NetWare dialog box, choose User Options.
2. From the User and Group Options dialog box, set the appropriate options.
Transfer Users and Groups. If this check box is cleared, then no users or groups will be transferred to the Windows NT Server domain controller. This allows for a migration of files only, in the case the users already exist on the computer running Windows NT Server.
Passwords. The Migration Tool cannot read the user's passwords from the NetWare server because NetWare passwords are encrypted in the bindery. This means that the operator must specify how passwords should be set on the new Windows NT accounts. The following options are available.
No Password - Users will have no password on the Windows NT Server.
Password Is Username - User's password will be the same as the username.
Password Is - A single password may be specified for all users that are migrated.
The default User Must Change Password check box will require the user to change their password upon first logging on.
Usernames and Groups Names. It is common to have duplicate user accounts and groups on NetWare servers because NetWare user accounts are server specific. The Username tab provides four options to handle the duplicate names during migration, they are as follows:
Log Error - Adds an error to the ERROR.LOG file.
Ignore - Causes no action to be taken.
Overwrite With New Info - Overwrites Windows NT account information with NetWare user account information.
Add Prefix - Creates a new Windows NT account when a conflict occurs with a prefix specified by the administrator.
Defaults. The Defaults tab provides two selections:
Use Supervisor Defaults - If the operator wishes, they can migrate NetWare Supervisors' account restrictions rather than using Windows NT Server account policies. These restrictions include password requirements and intruder lockout settings.
Add Supervisors to Administrators group - On a NetWare network there are probably more people with Supervisor equivalent than are necessary on a Windows NT Server network so, by default, those users are not added to the Administrators group. Users that require it can be added to the Administrators group selectively at a later time. By selecting this check box, all users with Supervisor Equivalence on the NetWare Server will become members of the Administrators Group.
The File Options dialog box allows the operator to:
Select which files are to be transferred - By default, all appropriate directories and files are transferred from all NetWare volumes on the selected server to the selected Windows NT Server computer. Directories and files that are transferred retain their effective rights provided they are copied to an NTFS partition.
When determining where to transfer directories and files, the Migration Tool looks for a share on the computer running Windows NT Server that matches the volume name on the NetWare server. If no share exists, the Migration Tool creates one when the migration is started. The Migration Tool locates the shares it creates by first looking for enough space on NTFS partitions, and if it cannot find a suitable NTFS partition, on FAT partitions.
Set the resource share name - For each NetWare volume, the Migration Tool transfers the contents to a shared directory named after the volume on the computer running Windows NT Server. You can specify a different shared directory as a destination instead. If the shared directory does not exist, it is created during the migration.
Select whether to copy hidden or system files. By default, the following files are not transferred:
To see which directories and files will be transferred by default, you can view them in the Files To Transfer dialog box. If the check box next to a directory or file is cleared, that directory or file will not be transferred. You can also run a trial migration and then review the file LOGFILE.LOG to see which directories and files will be transferred.
Microsoft Windows NT Server integrates into an Apple® Macintosh network by using Services for Macintosh. This service is a thoroughly integrated component of Windows NT Server that makes it possible for PC and Apple Macintosh clients to share files and printers. Services for Macintosh features include:
Graphical administration tools that are fully integrated into Windows NT Server File Manager, Print Manager, and Server Manager.
Printing to non-PostScript® printers.
Compatibility with all computers that run Windows NT Server.
Secured logons that provide added protection from network sniffers.
Support of AppleTalk® Phase 2.
Windows NT Server Services for Macintosh include AppleTalk Filing Protocol (AFP) versions 2.0 and 2.1, LocalTalk®, EtherTalk®, TokenTalk®, and FDDITalk. In addition, Services for Macintosh supports version 5.2 or later of the LaserWriter® printer.
In addition to the Windows NT Server requirements, Services for Macintosh also requires the following:
2 MB of free hard disk space for the Services for Macintosh software.
An NTFS partition in order to create directories that can be accessed by Macintosh workstations.
All Macintosh systems that can use AppleShare® (the Apple networking software) can use the Services for Macintosh (this includes all Macintoshes, except for the Macintosh XL and 128K). In addition to the capability of using AppleShare, the following are required:
Version 6.0.8 or later of the Macintosh operating system; System 7.1 is preferred.
Version 2.0 or later of the AppleTalk Filing Protocol (AFP); 2.1 is preferred.
One of the following is required for connectivity:
LocalTalk card in the Services for Macintosh Server
Ethernet cards in the Macintosh clients
Ethernet cards in LocalTalk Router
Services for Macintosh can be installed from the Control Panel Network application. After installation, the computer must be restarted for the installation to take effect.
For the File Server portion of Services for Macintosh to be installed, the computer running Windows NT Server must have an NTFS partition. If there is no NTFS partition on your server, a message warns you that you will only be able to install Print Services for Macintosh. Without File Server for Macintosh, you will not be able to store Macintosh files.
When Services for Macintosh is installed, two services are enabled: File Server for Macintosh and Print Server for Macintosh. Also, a device, the AppleTalk protocol, is enabled. The services can be controlled through the Control Panel Services application, while the device is controlled through the Control Panel Devices application. By default, the services are started automatically.
File Server for Macintosh
This service allows you to designate a directory as a Macintosh-accessible volume, ensure Macintosh filenames are legal NTFS names, and handle permissions.
Print Server for Macintosh
This service, also know as MacPrint, allows network users to send print jobs to a spooler on the computer running Windows NT Server and continue working, rather than waiting for their print jobs to complete.
AppleTalk Protocol
This protocol is a stack of protocols that Services for Macintosh uses to route information. It works behind the scenes to ensure that computers on the network can talk to one another.
The AppleTalk protocol is the component of Services for Macintosh that can be configured. This is done through the AppleTalk Protocol Configuration dialog box displayed during the installation of Services for Macintosh.
The AppleTalk Protocol Configuration dialog box allows you to select the zones, similar to workgroups, where services will appear, specify the server to act as an AppleTalk router, and choose advanced options for AppleTalk routing.
The configuration options in the AppleTalk Protocol Configuration dialog box are displayed in the following table.
Configuration option Description
Network The adapter driver to which the AppleTalk Protocol will
be bound.
Zone Similar to workgroups; zones are a collection of
computers. This is the area in which the
Macintosh-accessible volumes and Windows NT Server
printers will appear through the Macintosh Chooser.
Enable Routing If this box is checked, the computer running Windows NT
Server and Services for Macintosh will become an
AppleTalk router. This means that if the AppleTalk
Protocol is bound to more than one network adapter, the
computer running Windows NT Server will be seen by
Macintoshes connected to all of the bound networks. If
this box is not selected, the computer running Windows
NT Server will only be seen from the Macintoshes
connected to the default network, the one to which the
AppleTalk Protocol is bound.
Advanced Options Available when the Enable Routing check box is selected
in the AppleTalk Protocol Configuration dialog box and
the Advanced button is chosen. Advanced options
include:
Networks. Allows you to select the appropriate network
adapter card for configuration.
Seed This Network. Seeding allows a computer running
Windows NT Server to initialize network information.
Seeding the network involves identifying zones on the
network and determining network ranges. This option
should only be selected on systems that will be the
authority for the zone and network number range for the
Macintosh network.
Network Range. Setting the network range is an
important part of seeding a network because all
AppleTalk networks in an internet are assigned a range
of numbers. Each workstation on the network is
identified to the network by one of these numbers,
combined with a dynamically assigned AppleTalk node
identification number. Because of this, no two networks
on an internet should have overlapping ranges.
The allowable values for network range are 1 to 65,279.
If you specify a range that overlaps another range, an
error message is displayed.
Zone Information. Setting zone information is also part
of seeding a network. From here, the current list of
zones can be viewed, zones can be added and removed,
and the default zone can be set.
The default zone is the zone in which all AppleTalk
devices will appear if a desired zone has not been
specified for them.
After installation, you can set several configuration options for Services for Macintosh by using the MacFile menu of Server Manager. When the MacFile Properties dialog box is displayed, choose the Attributes button. The MacFile Attributes dialog box displays the following parameters.
Parameter Description
Server Name for AppleTalk This is the server name that Macintosh
Workstations workstations will see when they log
on.
Logon Message This is a message that Macintosh users
will see when they log on. You must be
running Macintosh System 7.1 or
greater to see this message.
Allow Guests to Log On This option allows users who do not
have a user account and password to
log on.
Allow Workstations to Save This allows Macintosh users to save
Password their password on their workstation so
that they will not always be prompted
for the password. However, this will
make the Windows NT Server system less
secure.
Require Microsoft Macintosh users must use Microsoft
Authentication Authentication to log on to the
server. This option uses encrypted
passwords.
Sessions This is the number of Macintosh users
that may be connected at one time.
A Macintosh volume is equivalent to a shared directory. It must be created on an NTFS partition.
On a computer running Windows NT Server, it is possible to share the same directory multiple times with different share names. It is also possible to share a subdirectory of an existing share with a totally different share name. However, with the Services for Macintosh, creating a Macintosh-accessible volume involves slightly different rules:
It is not possible to configure one directory as multiple volumes.
For example, once D:\TEST has been made a Macintosh-accessible volume called TEST, it is not possible to create another Macintosh-accessible volume called TEST2 from the D:\TEST directory.
It is not possible to nest volumes.
For example, if you create a Macintosh-accessible volume called TEST, you will not be able to create volumes for \DOCS, \FILES, or \GAMES because these directories are in the TEST directory tree.
\TEST\DOCS
\TEST\FILES
\TEST\GAMES
Instead, create individual volumes for the \DOCS, \FILES, and \GAMES directories and do not create the TEST volume at the parent directory level.
The maximum number of volumes is 255 (this is an AppleTalk limitation), although the number that can be seen by Macintosh workstations is determined by the length of the volume names.
When a Windows NT system shares files, the files are placed in a shared directory that other users on the network can access. For a Macintosh workstation to access the files in the shared directory, the system administrator must designate the shared directory as a Macintosh-accessible volume.
Creating a Macintosh-accessible volume is very similar to sharing a directory:
1. In File Manager, select the directory on an NTFS partition to use as a Macintosh volume.
2. From the MacFile menu, choose Create Volume.
The Create Macintosh Accessible Volumes dialog box is displayed.
The main differences between this dialog box and the Share As dialog box, which is used to share a directory, are the following fields:
Password and Confirm Password
Users connecting from a Macintosh workstation are required to supply an assigned password. The password only applies to Macintosh users accessing the volume. Non-Macintosh users do not have to supply a password when accessing the same directory structure through a share name.
Volume Security
This allows the administrator to set the entire volume as read-only or make the volume accessible to guests.
When using Services for Macintosh, there are special file considerations, such as:
Translating filenames - Files stored on an NTFS partition are translated to 8.3 format.
Filename appearance - Files appear differently to Macintosh and non-Macintosh users.
Associating file extensions - Causes the correct application to launch, whether a Macintosh or non-Macintosh user requests the application.
When a Macintosh file is created on the server, Services for Macintosh checks to ensure that it does not contain any characters considered illegal by NTFS. If any illegal characters are found, they are removed before passing the file to NTFS. If the filename is longer than a FAT-standard 8.3 filename, NTFS will create a short 8.3 filename for the file. Whenever a file is created with a filename longer than 8.3, NTFS always creates an 8.3 filename.
When using Services for Macintosh, long filenames are translated to 8.3 format as follows:
1. Use the first six characters of the long file name.
2. Append ~ for the seventh character.
3. Append a unique number for the eighth character.
4. If the filename has an extension, the first three characters after the last period of the long filename are used for the extension of the 8.3 filename.
Within a directory that has been both shared and made a Macintosh-accessible volume, the following occurs:
Non-Macintosh systems accessing the share can see directories and files, which is how everything is actually stored.
Macintosh workstations can see what appears to be Macintosh files and folders, along with their respective icons.
When accessing the volume, Macintosh users can create files and folders with Macintosh filenames, which can be up to 31 characters and contain spaces and other characters. Because Macintosh-accessible volumes are on NTFS partitions, non-Macintosh systems which do not recognize long filenames will see the NTFS-generated 8.3 filename when accessing the shared directory.
For Macintosh users, if the file has been created by a non-Macintosh system and the filename has more than 31 characters, they will see the NTFS-generated 8.3 filename.
With extension-type associations, both Macintosh and non-Macintosh versions of applications can easily work on the same data file.
When a file on the server has an extension associated with a Macintosh file type and file creator, the Macintosh Finder will display the appropriate icon for the file when a Macintosh user looks at the files on the server. In addition, if a Macintosh user chooses the file, the correct application will start and open the file.
Use the Associate option from the MacFile menu in File Manager to manage file extension associations.
Services for Macintosh offers some unique security features and considerations. In this section the following will be covered:
File-level security
Setting permissions
Network-level security
Logons
Microsoft Authentication
Using Windows NT Server and NTFS, permissions can be placed on shares, directories, and files. Macintosh permissions differ in that they can only be set for folders, not for individual files.
A Macintosh has three file-permission types. They are known as access privileges and are discussed in the following table.
Permission Description
See Files The user can see the files in the current folder and
read the files.
See Folders Users can see what folders are contained in the current
folder. They can see and open any folders.
Make Changes Users can modify files, rename files, move files,
create new files, and delete existing files.
Macintosh users are given access privileges as members of three different categories:
Owner - By default, the user who created the folder or the user or group account that has been assigned ownership.
Group - Every folder can have one group associated with it, and the permissions apply to members of that group.
Everyone - All users connected to the volume.
When a user at a Macintosh workstation creates a folder on the server, the user's primary group is the group that is associated with the folder. When the owner then gives permissions for the folder to the Group category, it is the owner's primary group that is receiving the permissions.
User Manager for Domains allows an administrator to set a global group as the primary group for a user. The primary group is only used for two things:
Services for Macintosh
The POSIX subsystem
Using Windows NT, permissions can be assigned separately for each file. The Macintosh does not support file-level permissions. File-level permissions will apply to Macintosh users only if those permissions are more restrictive than permissions assigned to the directory containing the file. For example, if a Macintosh user has See Files, See Folders, or Make Changes permissions for a directory (which appears as a folder), the user can read and make changes to the files in the directory. However, if that user has only Read permission for any particular files in that directory, the user can only read that file.
Services for Macintosh translates permissions so that those set by a non-Macintosh user are translated into the equivalent Macintosh permissions (and vice versa). Permissions are translated based on the following table.
Macintosh permissions Equivalent Windows NT permissions Read See Files and Folders Write and Delete Make Changes
In a Macintosh environment, a folder's owner can set Macintosh permissions on a file created in that environment, but only at the folder level.
In a Windows NT environment, a user can set permission on a file created in a Macintosh environment according to the following rules:
The folder's owner, an account with the Change Permissions right, or an administrator can set Windows NT permissions on the directory or files.
A system administrator can set Macintosh permissions using the MacFile Permissions menu of File Manager.
With Services for Macintosh, network security is enforced in the same way for Macintosh workstations and non-Macintosh workstations.
Services for Macintosh uses the same user accounts database as Windows NT Server. Therefore, if a person using a Macintosh workstation already has an account on a computer running Windows NT Server and Services for Macintosh, it is not necessary to create another account for that user. It is only necessary to create accounts for Macintosh users who do not already have an account on the computer running Windows NT Server.
Because the Macintosh logon process uses standard Windows NT user accounts, Macintosh users may log on to the local domain or any trusted domain within the network.
There are three possible ways a Macintosh user can log on to a computer running Windows NT Server and Services for Macintosh:
As a guest
Allows logons without requiring a password.
As a user with a clear-text password
Clear-text password protection is part of the AppleShare software on Macintoshes. It does not provide any kind of password encryption. Passwords can be no more than eight characters long.
As a user with an encrypted password
The encrypted password can be up to 14 characters long.
Services for Macintosh includes an optional Microsoft Authentication component, which is an extension to AppleShare. Microsoft Authentication provides a more secure logon session.
There are several reasons that Microsoft developed its own User Authentication Module (UAM) instead of using the existing Apple UAM.
The encryption scheme used in the Apple UAM requires that a clear-text password be stored on the server. This is unacceptable in a Windows NT Server environment because of C2 requirements. The Microsoft UAM uses encrypted passwords.
Microsoft has added support for logging on to trusted domains.
Passwords under the Apple UAM are a maximum length of eight characters, with Microsoft Authentication this is increased to 14 characters.
Microsoft Authentication can be completely installed on Macintosh workstations over the network. After it is installed, Authentication is required when a Macintosh user connects to a computer running Windows NT Server. If the Macintosh is running System 7.1 or later and Windows NT Server is configured to require Microsoft Authentication, the user can only use Microsoft Authentication. Earlier systems will have two choices: Microsoft Authentication or clear-text passwords, even if Microsoft Authentication is required.
When Services for Macintosh is installed, the Print Server for Macintosh is integrated into the Windows NT Server Print Manager.
The Print Server enables Macintosh workstations to print to printing devices connected to the Windows NT Server system, including non-PostScript printing devices. The Print Server also enables non-Macintosh systems to print to AppleTalk PostScript printers that have been connected to the Windows NT Server system.
Services for Macintosh spools Macintosh and non-Macintosh print jobs before they are sent to the printer. Users do not have to wait for their jobs to print before they can continue working.
Macintosh workstations
Macintosh systems follow normal Macintosh procedures in sending print jobs to a Macintosh printer, unless the printing device has been captured. If the printing device has been captured, Macintosh print jobs will be spooled to the Windows NT Server system, which will then send it to the printing device.
Non-Macintosh systems
For non-Macintosh systems to use an AppleTalk printer, the printing device must be PostScript-compatible and use the LaserWriter driver. In addition, the printing device must also be captured by the Windows NT Server system.
When setting up a printer on an AppleTalk network to be used with Services for Macintosh, it is possible to specify whether Services for Macintosh will capture the printer. Capturing a printer means that the printer will not accept print jobs from any source except a Windows NT Server Print Server. This allows an administrator to have full control over the captured printer.
If a printer is not captured and a user is printing to the printer, the printer will appear busy to any other system trying to print to the same printer.
When an AppleTalk printer connection is created through Print Manager, the printer is automatically captured. To release the printer, choose Properties from the Printer menu, and then choose the Settings button.
Minimally, the integration of Windows family and UNIX systems must provide for simple network connectivity between the systems. Users should be able to access files across platforms over a network, and applications on different systems must be able to communicate with each other. To achieve better integration, it is also necessary to enable cross-platform application development, object services, database access, messaging, and system management.
With cross-platform application development, developers will be able to write platform independent applications. Cross-platform object services enables software components to communicate across platforms easily and can users more productive. System administrators will be able to manage heterogeneous systems easily if system management software can provide, at one place, management information about heterogeneous systems. Cross-platform database and messaging services provide users with a means for easy, platform-independent information exchange.
At a minimum, system integrators must arrange to provide users with a means of accessing files between the Windows family and UNIX systems. System integrators must enable Windows family systems to provide file services to UNIX clients and vice-versa.
Windows NT Server provides file services to PCs through the Server Message Block (SMB) protocol. File service for UNIX clients is available through the Network File System (NFS) protocol and the FTP service.
NFS: Third party NFS servers such as DiskShare from Intergraph Corporation®, BW-Connect from Beame & Whiteside Inc., NFSWare from Process Software, and Chameleon32NFS from NetManage Inc. are available for Windows NT. These servers enable Windows NT Server to provide file service for PCs, UNIX workstations or other systems acting as NFS clients. They provide support for the NTFS, FAT, CDFS and HPFS file systems and some also enable the exporting of network drives. A Windows NT Server system could, for instance, connect to a NetWare® server and share out the NetWare server's files to NFS clients. Support for the Intel®, Alpha AXP™, and MIPS® platforms is available and PowerPC™ support will be available in future.
FTP, RCP: Windows NT Server provides the FTP service which enables bi-directional transfer of ASCII and binary files. The FTP service is not installed by default since the service could cause a security breach to the Windows NT system. Since UNIX users are already familiar with the FTP service, they can easily access files from Windows NT Server. A third party RCP server for Windows NT is available from Software Innovations Inc.
UNIX servers can provide file services to Windows family systems through NFS, SMB, FTP, and RCP.
NFS: Third party NFS clients such as PC-NFS®/Windows from Sun Microsystems®, PC-NFS/Windows NT from Intergraph, BW-Connect from Beame & Whiteside, and Chameleon32NFS from NetManage are available for the Windows family. With such software users on PCs, users can access files from PCs, UNIX systems and other systems acting as NFS servers.
Microsoft Networking: Users from Windows or Windows NT systems can access files on UNIX systems running LAN Manager for UNIX (LMU). Microsoft has licensed to AT&T® GIS the source code for LAN Manager for UNIX and the source code for Windows NT Server. AT&T will sublicense the code to other vendors so as to provide Microsoft Networking on UNIX systems. Advanced Server for UNIX (ASU) is the next generation of LAN Manager for UNIX being developed by AT&T. The ASU technology is fully interoperable and functionally compatible with the networking technology incorporated in Windows NT. ASU is equivalent to Windows NT Server in terms of establishing and managing accounts and providing support for trusted domains. System administrators can use the Windows NT Server tools to administrate the UNIX servers. DEC™ has a license for Advanced Server for UNIX and has stated that it will implement it on the OSF/1 and VAX™ systems. Unipress will provide Advanced Server for UNIX on Solaris. SCO® announced an agreement to license ASU from AT&T GIS and provide it on SCO-UNIX. Bull, SNI, and Olivetti® will also provide Advanced Server for UNIX on their UNIX systems.
FTP, RCP: Windows NT provides FTP and RCP clients while FTP and RCP clients for Windows are available from third parties like Walker Richer Quinn, Wollongong, and Frontier Technologies. Both FTP and RCP clients are functionally similar to the ones available on UNIX systems. With the FTP client, a user on Windows NT can access ASCII and binary files on remote systems. RCP provides a mechanism to unidirectionally copy files between two systems of which one or both can be remote. The remote system(s) must be configured to trust the RCP requests by configuring a file such as a .rhosts file.
Users in an enterprise often need to run both personal productivity Windows-based applications and some vertical or in-house developed solution on a UNIX system. In such cases, the user needs to access both applications from the same system.
With third party products, users on UNIX systems or X terminals can run remote Windows NT applications or remote X Window System applications on Windows NT. Similarly, a user sitting at a Windows family system can run remote X Window applications on UNIX systems. This is made possible by third-party software from numerous vendors.
Organizations with existing UNIX systems are increasingly using Windows and Windows NT for their businesses. In such organizations, users on UNIX systems who need applications like word processors and spreadsheets either buy expensive UNIX applications, or a PC and PC-based applications. Users who buy a UNIX application are restricted to using the application only for that particular version of the UNIX system. Users cannot change over to another UNIX system of their choice and still use the same application they bought earlier.
WISE is a Microsoft licensing program that enables integration of Windows-based solutions with UNIX and Macintosh® systems. Microsoft has licensed Windows source code to Insignia Solutions Inc. and Locus Computing Corporation. With Insignia's product, Softwindows, users can run shrink-wrapped Windows and OLE-based applications on Macintosh and non-Intel® based UNIX systems. With Locus' product, Merge, users can work with shrink-wrapped Windows-based applications on Intel-based UNIX systems.
WISE emulators enable users to run inexpensive, shrink-wrapped Windows-based applications on UNIX and Macintosh systems. WISE emulators make over 10,000 off-the-shelf Windows-based applications available to users on Macintosh and UNIX systems and increase the users' productivity.
The benefits of WISE are:
Compatibility: Since WISE emulators utilize Windows source code licensed from Microsoft, they provide maximum compatibility with the many thousands of shrink-wrapped Windows-based applications on the market. Users can choose from several inexpensive shrink-wrapped Windows-based applications off the shelf and use them on UNIX and Macintosh systems.
Consistency: End users who need to utilize existing Macintosh and UNIX solutions can now concurrently use company-standard Windows-based applications to simplify their jobs. Users can thus use a consistent set of applications across several platforms.
Confidence: Users can adopt a solution that will evolve along with future versions of Windows, taking full advantage of evolving technology. Microsoft has committed to providing WISE licensees with future versions of Windows source code, thereby continuing to maximize application compatibility and performance for today's and tomorrow's applications.
Through the WISE licensing program, Microsoft will enable full OLE support on all major UNIX systems. Users can use OLE enabled applications on UNIX systems and also realize all the benefits of OLE on UNIX systems.
Corporate users often need to use personal productivity applications on Windows as well as vertical workstation applications available on UNIX systems. In such situations system administrators need to arrange a means of providing users with access to both the personal productivity applications and the UNIX applications from the same system.
Windows NT Server can provide application services to Windows family systems over a network. Users on Windows family clients connect to a sharepoint on a Windows NT Server and use applications on the server.
Application services to UNIX clients are provided by: telnet, rlogin, rsh, rexec: telnet and rlogin. These services offer basic terminal emulation to remote systems over TCP/IP. rsh provides a simple mechanism to execute a process on a remote system supporting remote execution over TCP/IP. rexec provides similar functionality as rsh with the addition of cleartext password authentication.
Windows NT does not provide any of these services itself since these could cause a security loophole. When a user on another system needs to telnet, rlogin, rsh or rexec to a Windows NT system, the password for the Windows NT account will be passed in clear-text over the network. A malicious sniffer on the network could get hold of the user's password and compromise security. If users still desire these services on Windows NT, they can use third party telnet and rlogin server software available from Altaman Software, Seattle Lab, and Software Innovations. With this software, users on UNIX clients can telnet into Windows NT and run applications on the server. Software Innovations also provides rsh and rexec servers for Windows NT.
X Window System clients on Windows NT: X Window System client software on Windows NT is available from third parties such as Datafocus Inc. and Data Micro Systems. Users sitting on UNIX systems can run X Window System applications on Windows NT over a network.
Running Windows-based applications remotely: Citrix Systems, Prologue, and Adonis Corporation will make multi-user versions of Windows NT available to customers. Using software being developed by these companies, users sitting at UNIX systems or X terminals can run Windows family-based applications on Windows NT Server systems over a network.
Telnet, rlogin, RSH, REXEC: Windows NT provides Telnet, RSH, and REXEC clients. Third party rlogin, RSH, REXEC, and Telnet clients are available for the Windows family from vendors like Wollongong, Walker Richer Quinn, FTP Software, and Frontier Technologies.
X Window System servers on Windows NT: Users on Windows and Windows NT systems can run X Window System applications on remote UNIX systems using X server software. Third party X server software such as XoftWare from AGE Logic, eXcursion from DEC, X-One from Grafpoint, eXceed from Hummingbird Communications, Multiview/X from JSB Corporation, Chameleon from NetManage, PC-Xware from Network Computing Devices, X/Vision from VisionWare, Reflection/X from Walker Richer Quinn, and eXodus from White Pine Software are available for the Windows family.
Users should be able to send messages from one system to another independent of the systems being used. In addition, communication between users on different systems becomes easier if the users make use of similar applications.
Microsoft Mail enables users on PCs, Macintosh and UNIX systems to exchange messages with each other. With WISE emulators, users on UNIX and Macintosh systems can send and receive email using the same Windows-based mail application on all systems. WISE emulators allow users on the different systems to communicate with the same email application, thus improving communication and increasing productivity.
In addition to sending mail to UNIX systems, users can use Microsoft Mail and gateways to send email to Macintosh, MVS™, VMS™ and several other systems.
System administrators can enable users to send email between Windows family and UNIX systems by using Microsoft Mail and gateways. Microsoft Mail can be used to send mail to SMTP, X.400 and uucp based email applications on UNIX systems using the Microsoft Mail Gateway to SMTP, and the Microsoft Mail Gateway to X.400. The SMTP gateway supports Multipurpose Internet Mail Extensions (MIME), several attachment handling options, message forwarding and multiple local account aliases. The X.400 gateway is compliant with the 1984 X.400 standard.
Microsoft Exchange, the next messaging product from Microsoft, will provide clients for Windows family, Macintosh and UNIX systems. Using these clients, users can send and receive messages between PCs, Macintosh and UNIX systems. Microsoft Exchange Server provides native support for SMTP and X.400. System administrators can thus set up communication between Microsoft Exchange and both X.400 and SMTP based messaging applications on UNIX systems.
Microsoft Exchange Server, the next messaging product from Microsoft, will also enable messaging between PCs, Macintosh and UNIX systems.
Windows NT provides TCP/IP printing services based on RFC1179, which contains the communication specification for line printer remote (lpr) and line printer daemon (lpd) printing. The lpd and its components in RFC1179 are known as Berkeley Style Daemons. Windows NT enables printing to UNIX servers that support the Berkeley style TCP/IP printing daemons. Windows NT provides an LPD server that allows UNIX machines with Berkeley-style LPR daemons to send print jobs to Windows NT.
Third party LPR and LPD support for Windows is available from third parties like NetManage, Wollongong, SunSelect, Walker Richer Quinn, and Frontier Technologies.
Microsoft Windows NT has an integrated SNMP (Simple Network Management Protocol) Service that can be installed when using the TCP/IP protocol. This service turns a Windows NT computer into a SNMP Agent, that can be managed via a SNMP Management station (such as various SNMP managers for UNIX platforms), responding to SNMP requests, and initiating SNMP trap messages.
Using Microsoft Systems Management Server, system administrators on Windows NT Server can distribute and install software, get hardware and software configuration, and do remote performance analysis and troubleshooting for Windows family systems. Using Microsoft Systems Management Server with DEC Polycenter AssetWorks on Windows NT Server and UNIX client software from DEC, system administrators on Windows NT Server can get hardware/software information from and distribute/install software to UNIX systems. DEC provides Microsoft Systems Management Server clients for OpenVMS, Ultrix™, SunOS, and OSF/1. Clients for Solaris, HP-UX and AIX will be available in future.
Systems Management Server also enables information exchange with system management software like OpenView and NetView.
Developers on PCs, Macintoshes, and UNIX systems can write software to access a Microsoft SQL Server database running on Windows NT Server. Similarly, developers on Windows and Windows NT systems can write client software to get data from databases, such as SYBASE® and ORACLE®, running on UNIX servers.
ODBC is an open, vendor-neutral, and powerful interface that application writers can use to transparently access database systems from different database vendors. Developers need not learn multiple programming interfaces since they can use a standard set of interfaces provided by ODBC. Using ODBC, developers can write software to access over 50 database servers including ORACLE, Informix®, SYBASE and Microsoft SQL Server. ODBC support is available in many popular front-end applications and development tools, such as Microsoft Visual Basic®, Powersoft PowerBuilder™ and Knowledgeware® ObjectView. ODBC support on UNIX systems will be available from Visigenic software. ODBC support on the Macintosh is available from Apple®.
ODS is an event driven application program interface that provides the foundation for integrated client-server business solutions. Using ODS, developers can integrate almost any external data with Microsoft BackOffice and Microsoft SQL Server.
Developers can use ODS to build gateways between Microsoft SQL Server and a wide range of databases on MVS, UNIX, VMS, and AS/400 systems. For instance, an application could be written on Windows NT Server using ODS, such that when a Microsoft SQL Server client requests data, the application sends the request to another system and passes the reply back to the client. For the client, the reply seems to come from Microsoft SQL Server, but the information actually comes from the ODS application that could, for example, be getting the data from a UNIX server.
ODS can be also used to build server applications, such as a security application to verify logins to a Microsoft SQL Server database, an auditing application to maintain a record of client transactions, or an application for notifying a user of changes in a Microsoft SQL Server database.
Developers can write to UNIX APIs on Windows NT by using either the POSIX subsystem of Windows NT or by using third-party products such as NuTCRACKER from Datafocus Corporation and Portage from Consensys Corporation.
The POSIX subsystem of Windows NT is certified by the National Institute of Standards and Technology (NIST) to be compliant with the IEEE 1003.1 POSIX specification.
NuTCRACKER provides support for UNIX APIs on the Win32® subsystem of Windows NT and Portage provides UNIX System V Release 4 support on top of the Win32 subsystem. Both these third party products provide several UNIX utilities on Windows NT. The products can be used either as porting tools to port UNIX applications to Win32 or for simultaneous cross-platform development. NuTCRACKER and Portage provide support for UNIX processes, signals, semaphores, message passing, sockets, file management, and the C runtime libraries.
Developers can use the remote procedure call (RPC) mechanism provided by Windows NT to write distributed applications. Since Microsoft RPC interoperates with the Distributed Computing Environment (DCE) RPC, developers can write applications that communicate with UNIX applications that make use of DCE RPC.
Using the Winsock interface provided by Microsoft, developers on Windows family systems can write applications that communicate with UNIX systems. Since the Winsock interface is similar to the Berkeley sockets interface available on most UNIX systems, developers already proficient on UNIX systems can easily use Winsock on Windows NT.
DCE on Windows NT is available from DEC. This provides RPC, directory, time, security and thread services. A DCE client for Windows is available from Gradient Technologies.
© 1995 Microsoft Corporation.
THESE MATERIALS ARE PROVIDED "AS-IS," FOR INFORMATIONAL
PURPOSES ONLY.
NEITHER MICROSOFT NOR ITS SUPPLIERS MAKES ANY WARRANTY, EXPRESS
OR IMPLIED WITH RESPECT TO THE CONTENT OF THESE MATERIALS OR THE
ACCURACY OF ANY INFORMATION CONTAINED HEREIN, INCLUDING, WITHOUT
LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. BECAUSE SOME STATES/JURISDICTIONS DO
NOT ALLOW EXCLUSIONS OF IMPLIED WARRANTIES, THE ABOVE LIMITATION
MAY NOT APPLY TO YOU.
NEITHER MICROSOFT NOR ITS SUPPLIERS SHALL HAVE ANY LIABILITY FOR
ANY DAMAGES WHATSOEVER INCLUDING CONSEQUENTIAL INCIDENTAL, DIRECT,
INDIRECT, SPECIAL, AND LOSS PROFITS. BECAUSE SOME STATES/JURISDICTIONS
DO NOT ALLOW THE EXCLUSION OF CONSEQUENTIAL OR INCIDENTAL DAMAGES
THE ABOVE LIMITATION MAY NOT APPLY TO YOU. IN ANY EVENT, MICROSOFT'S
AND ITS SUPPLIERS' ENTIRE LIABILITY IN ANY MANNER ARISING OUT
OF THESE MATERIALS, WHETHER BY TORT, CONTRACT, OR OTHERWISE SHALL
NOT EXCEED THE SUGGESTED RETAIL PRICE OF THESE MATERIALS.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |