How Services for Netware Works

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Services for NetWare Architecture

Services for NetWare 5.03 includes two components: Directory Synchronization Services and the File Migration Utility (FMU).

Directory Synchronization Services

Using Directory Synchronization Services (MSDSS) an organization can retain an existing Novell directory in an environment that includes computers running Windows Server 2003 and Active Directory. MSDSS synchronization enables you to choose:

  • One-way synchronization to centralize directory management from Active Directory.

  • Two-way synchronization to manage data from either Active Directory or a Novell directory.

File Migration Utility

Using FMU, an organization can migrate a Novell Bindery or NDS directory to Windows Server 2003 Active Directory.

MSDSS

The following sections summarize the synchronization methods that are available with Directory Synchronization Services (MSDSS):

  • Forward Synchronization

  • Reverse Synchronization

  • One-Way Synchronization

  • Two-Way Synchronization

  • Scheduled Synchronization

  • Manual Synchronization

  • Synchronization Filtering

  • Password Synchronization

Forward Synchronization

The process of synchronizing data from Active Directory to Novell directories is referred to as forward synchronization. The forward synchronization process efficiently queries Active Directory for any new objects and alterations to existing objects. If an existing object is modified, only its changes, not the entire object, are synchronized with NDS, eDirectory, or Bindery directory services objects. If a new object is created, then only the new object and its attributes are synchronized with NDS, eDirectory, or Bindery directory services objects. Synchronization takes place during the scheduled synchronization or when you initiate a manual synchronization.

Reverse Synchronization

The process of synchronizing data from Novell directories to Active Directory is referred to as reverse synchronization. Reverse synchronization is less efficient than forward synchronization. This means that network utilization during reverse synchronization is higher than it is during forward synchronization.

NDS does not currently provide a comprehensive mechanism to query changes to objects. Therefore, during reverse synchronization, an MSDSS algorithm compares all of the objects residing in the NDS directory to the objects residing in Active Directory. Only changed objects and newly created objects in NDS are copied to Active Directory.

Because network utilization during reverse synchronization can be higher, it should be scheduled to run less frequently than forward synchronization. However, if you decrease the frequency of directory synchronization in either direction, you will increase the likelihood of inconsistencies between Active Directory and NDS.

One-Way Synchronization

Using one-way synchronization, you can deploy Active Directory in a Novell environment without replacing existing directories or having to manage two directories. This enables you to:

  • Consolidate network management where multiple directories are required.

  • Manage accounts from a single directory.

  • Use directory-enabled applications, devices, and services based on Active Directory.

After an initial reverse synchronization is performed (from NDS, eDirectory, or Bindery directories to Active Directory), the NDS, eDirectory, or Bindery directory objects that reside in Active Directory can be forward-synchronized on a one-way basis. When users, groups, organizational units (OUs), or any of their applicable attributes are modified in Active Directory, they will be synchronized with the NDS, eDirectory, or Bindery directories during the next scheduled synchronization.

Setting up a one-way synchronization session provides an administrator with a central directory management solution and supports additions or modifications to NDS, eDirectory, or Bindery directory services objects from Active Directory only.

Two-Way Synchronization

Using two-way synchronization, you can create or change objects in either Active Directory or NDS and the partner directory will be updated at the next scheduled synchronization.

You can use two-way synchronization to enable interoperability between NDS and Active Directory and to maintain an existing NDS directory and add Active Directory.

Scheduled Synchronization

During a scheduled synchronization, changes from one directory are replicated to another directory at scheduled intervals that are set by an administrator. The default interval for forward synchronization is every 15 minutes, 24 hours a day. The default interval for reverse synchronization is every hour, from midnight to 06:00. If a two-way synchronization session has been configured, you can define a separate schedule for each direction of the synchronization.

Manual Synchronization

When you manually synchronize directories, you have the option of copying recent changes from one directory to another immediately, without waiting for the next scheduled synchronization.

Usually, it is safe to let synchronization occur during the normally scheduled times. However, a security-related situation might call for an immediate manual synchronization. For example, users with access to both directory platforms might request a password reset or logon change, or user accounts might need to be immediately disabled.

When user accounts are disabled in Active Directory, access to those accounts from Active Directory is immediately restricted. However, users will still have access to their accounts from NDS until a scheduled synchronization takes place. To prevent this situation from occurring, you can perform a manual synchronization.

Synchronization Filtering

Using synchronization filtering, administrators can define an explicit set of object types within a session to be read during the synchronization process. Object types are collections of attributes. When a synchronization filter is applied, changes to a defined object type are synchronized on the next scheduled synchronization.

Password Synchronization

Password synchronization can occur only if passwords are changed from Active Directory. Passwords are synchronized when an administrator performs any of the following administrative functions:

  • Initial reverse synchronization

  • User creation in NDS or eDirectory

  • Password changes in Active Directory

Initial Reverse Synchronization

Users that have been copied from NDS, eDirectory, or Bindery to Active Directory through initial reverse synchronization will be prompted to change their passwords the first time they log on to Active Directory. This new password will then be synchronized with the password attribute in NDS, eDirectory, or Bindery.

User Creation in NDS or eDirectory

If users are created in NDS or eDirectory (in a two-way synchronization), the new user objects are copied to Active Directory on the next scheduled reverse synchronization. When the new users successfully log on to Active Directory, they are prompted to change their passwords. The new passwords are copied to NDS or eDirectory on the next scheduled forward synchronization.

Password Changes in Active Directory

When users change their passwords or when an administrator resets user passwords in Active Directory, the new passwords overwrite the existing NDS, eDirectory, or Bindery passwords. This password synchronization process occurs during the next scheduled forward synchronization.

Note

  • If the User must change password at next logon check box is selected for any user, the password will not be synchronized from Active Directory to the Novell directory until the user logs on to Active Directory and changes the password.

Because it is impossible to access encrypted passwords stored in NDS, eDirectory, and Bindery, new user passwords are created when user objects are migrated to Active Directory. Any password changes made from NDS or eDirectory will not be synchronized with Active Directory. The new password is generated using password generation schemes that are specified by Services for NetWare.

The password scheme is applied and then copied to Active Directory before the user object is migrated. When the user accounts exist in Active Directory, users will be prompted to create new passwords when logging on to Active Directory.

Changes made to user passwords in Active Directory will be synchronized with the respective Novell user objects at the next scheduled synchronization.

User password schemes only affect user objects that exist in NDS, and use of a password scheme will not overwrite a valid user password in Active Directory. Because of this password scheme rule, it is recommended that all future password changes occur in Active Directory. Otherwise, if a user password is changed in NDS, the passwords in both directories will be inconsistent until it is changed in Active Directory.

The following table lists and describes the password schemes that are available to administrators.

Password Schemes Available to Administrators

Password Schemes Description

Set passwords to blank.

Clears all passwords. Users logging on to Active Directory for the first time will not need to specify a password.

Set passwords to the name of the user.

Sets passwords to user names after migration has taken place. This is the default scheme.

Set passwords to a random value.

Creates random passwords for each user migrated to Active Directory. The password generated by SFN does meet Windows Server 2003 default password policy.

Set all passwords to the following value.

Provides an option to specify and confirm the password value for all users migrating to Active Directory.

MSDSS Directory Schema Extensions

Extensions to the Active Directory and NDS directory schemas are required for full MSDSS functionality.

Note

  • MSDSS directory schema extensions are implemented once and are irreversible.

A directory schema provides a description of object classes and associated attributes that can be placed in a directory. For each object class, the directory schema defines:

  • The required attributes of the object class

  • Any additional attributes of the object class

  • The parent object class of the defined object class

Active Directory Schema Extensions

Extensions to the Active Directory schema are required for:

  • Migration

  • One-way synchronization

  • Two-way synchronization

If a user who is installing MSDSS has the necessary permissions to extend the Active Directory schema, MSDSS automatically updates the Active Directory schema during the setup process. The schema update process is required only once for each Active Directory forest. If a user who is installing MSDSS does not have the necessary permissions to extend the Active Directory schema, the schema can be updated manually by a user with the appropriate schema credentials. To manually update the schema, log on to the schema master in the Active Directory forest in which MSDSS is to be installed with the appropriate schema credentials, then open a command prompt and type:

msiexec /I Path \msdss.msi SCHEMAONLY=1

NDS Directory Schema Extensions

Extensions to the NDS directory schema are required for two-way synchronization.

To support two-way synchronization, you must also extend the NDS schema. If you are required to extend the NDS schema when you create a new session, the system prompts you. Extending the NDS schema requires the following:

  • Installation of Novell Client for Windows (also a requirement for MSDSS).

  • Administrator permission to access the root object of the NDS tree.

  • Access to the server that stores the master replica of the root partition (this server propagates the changes to all the servers in the NDS tree).

You can also extend the NDS or eDirectory schema manually by using the MSDSS command-line NDS schema extension tool NDSext.exe (available in the systemroot\System32\Directory Synchronization\Client folder). Use the following syntax:

ndsext extend Treename Username.Context Password

This command enables you to extend the NDS schema of a specified tree.

File Migration Utility

The File Migration Utility (FMU) enables you to migrate files from NetWare servers to Windows Server 2003. FMU can copy files from multiple NetWare file servers to multiple file servers running Windows Server 2003.

FMU is integrated with MSDSS and enables the migration of large numbers of data files from all versions of NetWare over to Windows Server 2003, while preserving unique file-security permissions during the migration. In addition, users can access their files during the migration process.

Before using FMU to translate the NDS, eDirectory, or Bindery file system rights and permissions to the equivalent rights and permissions in the NTFS file system, you must run a one-time migration of NDS or Bindery directory objects to Active Directory. This operation creates the mapping file used by FMU to map user rights to folders. After a scan confirms that all files, subdirectories, and permissions will migrate successfully, you can perform the migration process. Each source directory and file is copied to the selected target. Each migrated trustee is translated with its associated rights to the equivalent NTFS permissions and then added to the security descriptor for the migrated directory or file.

For each NDS or Bindery volume, FMU calculates the effective rights, starting at the root, and tracks inheritance and filters as the migration continues through the tree. Like Novell NetWare, Microsoft Windows secures folders and files by controlling group and user access. Windows security is supported through the NTFS file system. To help preserve security on transferred NetWare files, you must transfer the NetWare files to an NTFS volume, where the effective rights of the NetWare files are converted to permissions.

After you have performed the one-time migration and selected the option to migrate files, a migration log will be created that can be used later by FMU. This migration log serves as a mapping file that maps user objects in NDS to Active Directory.

Accounts Required for FMU

FMU requires the following accounts for its security context:

  • The account that the user provides for NDS or Bindery access. The security context of this account is used to read the directories, files, and associated trustees that reside on the source Novell system.

  • The user accounts accessed through Active Directory for users who are logged on. The security context of this account is used for creating directories and files and setting the associated security descriptor on the targeted Active Directory domain.

Sources and Targets

During a migration, the source is always either a volume or a directory from an NDS or Bindery server. You can have multiple mappings in any migration. One source can be mapped to multiple targets or multiple sources can be mapped to a single target. The migration target must be a shared folder on Microsoft Windows 2000 or Windows Server  2003.

You can display the source and target listings by using Active Directory Service Interfaces (ADSI) calls and then use the Lightweight Directory Access Protocol (LDAP), NDS, and NWCOMPAT providers to populate the lists. If any of these providers are missing, you might get blank listings.

FMU and MSDSS

MSDSS is an essential part of the file migration process because MSDSS informs FMU of the user and group relationships with the corresponding objects in NDS or Bindery. Within NDS, users, groups, organizational units, and organizations can all be trustees to directories and files.

Note

  • Trustees are granted rights to work with directories, files, or objects. Active Directory does not support a container such as an organization to be the trustee of a directory or file. For more information about NDS or Bindery inheritance, see Novell documentation.

To maintain these rights throughout the migration of files from Novell NetWare to Microsoft Windows, MSDSS maps organizational units and organizations to Active Directory groups by creating local domain security groups for each NDS organizational unit and organization.

MSDSS Migration Logs for FMU

FMU requires the MSDSS-generated migration log to determine where each Novell trustee has been mapped in Active Directory. The migration log contains a list of trustee objects that were migrated to Active Directory during the MSDSS one-time migration process, and the log also lists the groups of trustees that were made members in Active Directory. Only trustees and their group associations that are listed in the migration log will be used to ensure equivalent security for files during the file migration process. The migration log contains a list of trustee objects that were migrated to Active Directory during the MSDSS one-time migration process. MSDSS can recognize the following NDS, eDirectory, or Bindery trustee objects:

  • Users

  • Groups

  • Organizational units

  • Organizations

Because only the trustee objects from NDS or eDirectory organizational units or organizations that you selected during the MSDSS one-time migration process will appear in the migration log, you will need to know which trustees have restrictions to the files you will be migrating to Windows and where these trustees reside in your NDS or eDirectory hierarchy.

You can use the migration log Maps option to display the maps that are loaded with the migration log. You can use Maps to confirm the trustee relationships to their corresponding objects in Active Directory before you perform a file migration. You can view the following maps:

  • NDS Organizations and organizational units to Active Directory Group Mappings

  • NDS Group to Active Directory Group Mappings

  • NDS User to Active Directory User Mappings

You can use the migration log Access Rights option to view NetWare rights that are equivalent to NTFS permissions.

Note

  • The NDS Modify right does not have an equivalent NTFS permission.

Directory Service Interoperability

Using the Services for NetWare directory service interoperability features, an organization can establish a synchronization strategy over a period of weeks or months, during which Active Directory interoperates with Novell Bindery, NDS, or eDirectory. This enables an organization to perform a migration to Windows Server 2003 in planned stages.

To maintain an environment that contains both Active Directory and Bindery/NDS directory services, you can perform a phased migration and run the two systems in parallel. A phased migration reduces the risk of data loss because you can migrate in managed stages and you can reverse the process if necessary. However, maintaining two separate directory services can, over time, add additional administrative costs to the migration.

In a phased migration, you use MSDSS to copy all Bindery or NDS user accounts, groups, and distribution lists, and (for NDS only) organizational units and organizations to Active Directory, while you maintain these objects in NDS or Bindery. While you gradually move resources to the Windows Server 2003-based environment, the MSDSS-provided directory synchronization enables users to continue to access those resources that remain on NetWare servers. As the changeover continues, users begin to access resources on computers running Windows Server 2003.

If you plan to perform a migration over several months or longer, two-way synchronization is recommended. Two-way synchronization should be used if the long-term goal is to interoperate using the two directory services. In this scenario, you can replace existing NetWare technologies with the latest comparable Microsoft technologies over a period of time.

After you have moved all resources to Windows Server 2003, converted all Novell services and applications to their counterparts in Active Directory, and moved object security permissions and objects that MSDSS does not migrate (such as computer accounts, printer objects, and application objects), synchronization between the two directory services might not be necessary. If not, you can delete the synchronization sessions and decommission remaining NetWare servers.

Services for NetWare and MIIS

Microsoft Identity Integration Server 2003 (MIIS) enables the integration and management of identity information across multiple repositories, systems, and platforms. MIIS augments Active Directory by providing broad interoperability capabilities, including: integration with a wide range of identity repositories; provisioning and synchronizing identity information, including password management, across multiple stores; and brokering changes to identity information by automatically detecting updates and sharing the changes across systems.

  • MIIS also provides cross-platform identity synchronization across many different identity stores, including Novell's eDirectory. MIIS is a much more robust long-term cross-platform interoperability solution than Services for NetWare; however, MIIS does not support NDS. MIIS supports Novell's eDirectory version 8.6.2 and later.

    Note

    • NetWare 5.x and NetWare 6.x are supported by MIIS if the NDS directory has been upgraded to Novell's eDirectory:

MIIS currently supports the following versions of Novell's eDirectory:

  • eDirectory 8.6.2

  • eDirectory 8.7

  • eDirectory 8.7.x

    Note

    • Support for eDirectory 8.7.x is included with Microsoft Identity Integration Server 2003, SP1.

For NetWare administrators who manage networks that include Novell software not supported by MIIS, Services for NetWare 5.03 can provide an interim Active Directory/NDS interoperability solution. For all other Novell customers, MIIS is the recommended long-term interoperability solution.

Services for NetWare Troubleshooting

Windows Server 2003 includes tools to help you monitor network traffic and to troubleshoot connectivity-related problems, including problems with routers, login scripts, client/server installation and configuration, and password synchronization. Among the troubleshooting tools provided with Windows Server 2003 are:

  • Netdiag to help isolate TCP/IP-related connectivity problems.

  • Netstat to display active TCP/IP connections, ports on which the computer is listening, Ethernet statistics, the IP routing table, IPv4 statistics (for the IP, ICMP, TCP, and UDP protocols), and IPv6 statistics (for the IPv6, ICMPv6, TCP over IPv6, and UDP over IPv6 protocols).

  • Ping for troubleshooting IP-level connectivity between two TCP/IP computers.

  • Tracert to trace routes and display the path between the sending host and a destination.

  • Pathping to identify the path to a remote host and then ping the remote host for a period of time to collect and report statistics.

  • Event Viewer to track errors and events recorded in Application, Security, and System logs.

  • Ipxroute to display and modify information about the routing tables used by the IPX protocol.

  • Network Monitor to monitor, record, and analyze network traffic.

For more detailed information about these and other troubleshooting tools, see “TCP/IP Tools and Settings” and “Services for Netware Tools and Settings.”

Connectivity Problems

Most connectivity problems between computers running Windows Server 2003 and NetWare are caused by invalid configurations. If these systems are incorrectly configured, NetWare might not be able to access resources or it might access them inconsistently. Because resource access involves interaction between both Windows Server 2003-based and NetWare-based computers, you must be sure that resource access configurations are accurate on these computers.

In general, any of the following conditions could be symptomatic of protocol related issues, such as a scenario that includes IPX configured on a NetWare server while a computer running Windows Server 2003 is using IP.

  • Access is denied to applications residing on NetWare servers.

  • Programs fail to run and display error messages.

  • Data throughput is slow.

  • Users see the error message “Server not found.”

  • Users are denied access to network resources located on NetWare servers.

  • Access to NetWare resources is limited.

  • Some clients have some access to NetWare services, while others have none.

  • Users can connect to servers running Windows Server 2003, but not to NetWare servers.

  • Users can connect to some NetWare servers, but not to others.

To resolve some of the connectivity issues, you can verify that NetWare rights and user credentials are configured correctly by asking the following questions:

  • Have you configured user accounts correctly on the NetWare file server?

  • Have you set up the appropriate groups?

  • Is group membership correctly configured?

  • Have you set up user rights correctly for required resources?

Note

  • For more information about NetWare configuration procedures, contact your NetWare administrator or refer to the Novell NetWare documentation.

Router Problem

In addition to potential NetWare and Windows Server 2003 connectivity problems, you might also experience the following router problem: NetBIOS-over-IPX packets do not propagate across routers.

If an incomplete browse list is displayed for a NetWare directory, or you cannot browse a server across a WAN link, you might have a problem with propagating packets using NetBIOS over IPX.

To facilitate the communication of a LAN-based protocol (such as NetBIOS) across an IPX network, IPX routers must be capable of propagating NetBIOS-over-IPX broadcast packets (type 20 packets), also known as IPX WAN broadcast packets. However, many router manufacturers set router parameters that prevent passing type 20 packets by default. If your router is not configured to pass type 20 packets, contact the router manufacturer for reconfiguration procedures.

Services for NetWare Protocols

NWLink, the IPX/SPX/NetBIOS-Compatible Transport Protocol, is Microsoft’s 32-bit implementation of Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX). NWLink is included with Windows Server 2003.

NWLink provides the transport protocol to support communications with NetWare file servers. To log on to a NetWare network from Windows Server 2003, you must use a NetWare client such as Novell Client for Windows XP Professional.

Note

  • You can also use NWLink to enable NetWare clients to connect to Windows Server 2003, Windows XP Professional, or Windows 2000 resources.

Because NWLink is Network Driver Interface Specification (NDIS)-compliant, a computer running Windows Server 2003 can also simultaneously run other protocol stacks, such as TCP/IP, for communication with computers running Windows with TCP/IP. In addition, you can bind NWLink to multiple network adapters with multiple frame types.

NWLink supports the networking application programming interfaces (APIs) NetBIOS and Windows Sockets (Winsock). These APIs enable communication among computers running Windows Server 2003 and between computers running Windows Server 2003 and NetWare bindery or NDS-based servers.

In addition to using NWLink to connect computers running Windows Server 2003 and NetWare, you can use NWLink whenever you need IPX/SPX. For example, when an IPX/SPX-based protocol is required, you can use NWLink as an alternative protocol to connect computers running Microsoft Proxy Server for Windows, Microsoft Systems Management Server (SMS), Microsoft Host Integration Server, Microsoft SQL Server, or Microsoft Exchange Server.

NWLink requires no initial client configuration on small non-routed networks.

Note

  • The 64-bit versions of the Windows XP and Windows Server 2003 family do not support NWLink.

When used in combination with a redirector, NWLink can also function as a protocol that connects computers running the following Microsoft operating systems, if they are also running IPX/SPX:

  • Windows 2000 Server

  • Windows XP Professional

  • Windows 2000 Professional

  • Windows NT

  • Windows for Workgroups 3.11

  • Windows 98

  • Windows 95

  • Microsoft MS-DOS

The following figure shows NWLink in the Windows Server 2003 architecture and the files in which each of the NWLink protocols are implemented.

NWLink in Windows Server 2003 Architecture

NWLink in Windows Server 2003 Architecture

NWLink provides a comprehensive set of transport and network layer protocols that enable integration with the NetWare environment. The following table shows NWLink protocols, defines their functions, and lists the associated drivers.

NWLink Protocols

Protocol Function Driver

IPX

Provides connectionless datagram transfer services.

Nwlnkipx.sys

SPX and SPXII

Provides connection-oriented transfer services.

Nwlnkspx.sys

RIP

Provides route and router discovery services.

Nwlnkipx.sys

SAP

Collects and distributes service names and addresses.

Nwlnkipx.sys

NetBIOS

Provides compatible support with NetBIOS, for IPX/SPX on NetWare servers.

Nwlnknb.sys
IPX

IPX is a peer-to-peer networking protocol that provides connectionless datagram transfer services and controls addressing and routing of packets of data within, and between, network segments. With connectionless transmission, it is unnecessary to set up a session each time packets are to be transmittedpackets are simply sent out on the network media. This requires less overhead than connection-oriented transmission, where it is necessary to establish a session each time packets are transmitted. Connectionless transmission works best when data is generated intermittently, in short bursts.

Because IPX is a connectionless protocol, it does not provide for flow control or acknowledgment when the destination node receives the datagram packet. Instead, individual datagram packets travel independently to their destination. There is no guarantee that packets arrive at their destination or that they arrive in sequence. However, because transmission on local area networks (LANs) is relatively error-free, IPX is efficient in delivering short-burst data on LANs.

NWLink enables application programming for Winsock and remote procedure calls (RPCs) over Windows Sockets. IPX supports Windows Socket IDs for use by Windows Sockets applications. IPX enables NetBIOS, named pipes, mailslot, network dynamic data exchange (network DDE), RPC over NetBIOS, and RPC over named pipes. Through direct hosting, NWLink also supports other applications that use IPX. Direct hosting is a feature that enables computers to communicate over IPX while bypassing the NetBIOS layer. Direct hosting can lower overhead and increase throughput.

IPX Frame Structure

An IPX packet is encapsulated within the data field of an Institute of Electrical and Electronic Engineers (IEEE) frame, such as Ethernet, Token Ring, or Fiber Distributed Data Interface (FDDI), and immediately follows the media and data-link layer headers. The following figure shows the structure of an IPX header. The first 30 bytes of an IPX frame contain the header information while the remaining bytes contain the actual IPX packet data. For example, the packet data might signify a client request for a service or the data might be a server response.

IPX Packet Header Structure for IPX

IPX Packet Header Structure for IPX

SPX

SPX is a transport protocol that offers connection-oriented services over IPX. Although connection-oriented services require overhead for session setup, when a session is established, connection-oriented services require less overhead for data transmission than connectionless services. SPX works best for applications that require a continuous connection. SPX provides reliable delivery through sequencing and acknowledgments and also verifies successful packet delivery to any network destination by requesting verification from the destination node upon receipt of the data. SPX can track data transmissions consisting of a series of separate packets. If an acknowledgment request brings no response within a specified time, SPX retransmits the request eight times. If no response is received, SPX assumes the connection has failed.

SPXII

SPXII improves upon SPX in the following ways:

  • SPXII allows more outstanding unacknowledged packets than SPX. SPX permits only one outstanding unacknowledged packet at a time, while SPXII allows as many outstanding packets as negotiated by the networked peers at connection setup time.

  • SPXII allows larger packets. SPX has a maximum packet size of 576 bytes, while SPXII can use the maximum packet size of the underlying LAN. For example, SPXII can use a packet size of 1518 bytes on an Ethernet network.

  • SPXII provides a packet burst mechanism. Packet burst, also known as burst mode, allows the transfer of multiple data packets without requiring that each packet be sequenced and acknowledged individually. By allowing multiple packets to be acknowledged once, burst mode can reduce network traffic on most IPX networks. Additionally, the packet burst mechanism monitors for dropped packets and retransmits only the missing packets.

Note

  • In Windows Server 2003, burst mode is enabled by default.
RIP

NWLink uses Routing Information Protocol (RIP) over IPX (RIPX) to implement route and router discovery services used by SPX and NetBIOS/IPX (NBIPX). RIP runs on a layer equivalent to the OSI Application layer and determines the forwarding media access control (MAC) address for outbound traffic. RIP code is implemented within the file Nwlnkipx.sys.

NWLink includes the RIP protocol for Windows-based clients and for computers running Windows Server 2003 that do not have the Routing and Remote Access service installed. These computers do not forward packets as routers do, but rather use a RIP table to determine where to send packets. RIP clients, such as workstations, can locate the optimal route to an IPX network number by broadcasting a RIP GetLocalTarget route request. Each router that can reach the destination responds to the GetLocalTarget route request with a single route. Based on the RIP responses from the local routers, the sending node chooses the best router to forward the IPX packet. However, clients using the RIP protocol without Routing and Remote Access do not forward packets.

The RIPX packet header immediately follows the IPX packet header. The following figure shows the packet header for RIPX.

IPX Packet Header Structure for RIPX

IPX Packet Header Structure for RIPX

SAP

Service Advertising Protocol (SAP) is the protocol that routers use to distribute the names and addresses of services running on IPX nodes. When bindery-based or NDS queries fail, SAP clients use SAP broadcasts to send the following types of messages:

  • SAP GetNearestServer request for the name and address of the nearest server of a specific type.

  • SAP general service request for the names and addresses of all services or of all services of a specific type.

NWLink includes a subset of the SAP protocol for Windows-based clients and for computers running Windows Server 2003 that do not have an IPX router installed.

The SAP header immediately follows the IPX header. The following figure shows the SAP header.

IPX Packet Header Structure for SAP

IPX Packet Header Structure for SAP

NetBIOS over IPX

To facilitate the operation of NetBIOS-based applications on an IPX network, NetBIOS over IPX provides the following standard NetBIOS services:

  • Datagrams. Single packets sent without acknowledgment, for example, broadcasts.

  • Sessions. Multiple packets sent with acknowledgments between two endpoints.

  • Name management. Registering, querying, and releasing NetBIOS names.

The following figure shows the packet structure for NetBIOS over IPX.

IPX Packet Header Structure for NetBIOS over IPX

IPX Packet Header Structure for NetBIOS over IPX

The module NWLnkNB.sys formats NetBIOS-level requests and passes them to NWLink for transmission over the network. NWLnkNB.sys includes the following performance enhancements:

  • PiggyBackAck. A feature that facilitates acknowledgment of previous frames within the response frames.

  • Sliding window acknowledgment mechanism. A dynamic window–sizing algorithm that enables burst mode to adjust the number of frames it can send.

As an alternative to NetBIOS over IPX, computers can communicate directly over IPX through direct hosting.

Protocol Priority Setting

When multiple transport protocols exist on a computer’s network adapter, Windows Server 2003 negotiates network connections in the order that the network services binding list prioritizes the protocols. For example, if TCP/IP is ranked at the top of the network services binding list, Windows Server 2003 attempts to make network connections with TCP/IP before attempting to use other transport protocols. If users require network connections to servers using TCP/IP, setting the highest priority to this protocol provides the best overall performance. However, if users need connections to NetWare servers using IPX/SPX, you can improve overall performance for those users by changing the protocol priorities in their network services binding list, so that Windows Server 2003 attempts to make network connections with IPX/SPX before using the other protocols.

The forwarder component provides IPX router support. The name of the forwarder component driver is Nwlnkfwd.sys. This component is installed with NWLink but is used only when a computer running Windows Server 2003 is acting as an IPX router running the Routing and Remote Access service. This component operates in kernel mode.

When the IPX router software is activated, the forwarder component works with the IPX Router Manager and the filtering component to forward packets. The forwarder component obtains configuration information from the IPX Router Manager and stores a table of the best routes. When the forwarder component receives an incoming packet, it passes the packet to the filtering driver, which checks for input filters. When the component receives an outgoing packet, it passes the packet to the filtering driver, and if no outgoing filters prevent the packet from being transmitted, the filtering component passes the packet back to the forwarder component. The forwarder component then forwards the packet over the appropriate interface.

Frame Types and Network Numbers

NWLink uses frame types and network numbers to communicate with other computers on the same network segment and to provide correct packet routing.

To connect a computer running Windows Server 2003 to a computer running IPX/SPX, a network number and frame type must be configured for each computer. The frame type and network number must be identical to the frame type and network number used on the local network segment. The NWLink Auto Detect feature automatically detects the internal network number and frame type. The Auto Detect feature, which is the recommended method for configuring network number and frame type, works in the following manner:

  • When the NWLink protocol is initialized, it sends a RIPX request using a specific frame type. The RIPX request is a broadcast request for the local network. If a response is not received, NWLink sends additional requests.

  • When a response to a RIPX request is received, the frame type for NWLink is set to the frame type of the response, and the IPX network number is set to the value of the Source Network number in the IPX header of the RIP response.

    Note

    • If a computer has multiple network adapters attached to different networks, such as Token Ring, FDDI, and Ethernet, you can run Auto Detect for each adapter.

  • If there are multiple RIPX responses containing multiple network numbers, Auto Detect uses a counting algorithm to determine the most likely network number.

  • If there is no RIPX response to any request, NWLink sets the frame type to Ethernet 802.2 (for Ethernet network adapters) and the network number to 0.

AutoDetect uses the RIPX response to select the frame type and network number. If a network computer has an incorrect manual setting, AutoDetect will select an inappropriate frame type and network number combination for the network adapter. For example, if a computer replies with an incorrect frame type and network number, Auto Detect detects the incorrect configuration and uses it. Auto Detect might also select an incorrect network number if multiple computers respond. In that case, Auto Detect uses a heuristic algorithm to determine the most likely network number, but Auto Detect does not validate the packet information that it receives.

Understanding Network Numbers

You can configure NWLink with two distinctly different types of network numbers for routing purposes: the external network number and the internal network number. NWLink uses an IPX external network number to identify the computer’s local network segment within the routed environment. In addition, NWLink uses a virtual network number, also known as an internal network number, to identify a logical network inside the computer. The purpose of the logical network inside the computer is to provide optimal routing to services running on the computer.

In Windows Server 2003 you can change both the external network number and internal network number from Control Panel.

External network number

The external network number is associated with the physical network adapter and the local area network segment (a segment in a NetWare network is analogous to a TCP/IP subnet). The external network number identifies the computer’s local segment and facilitates communications within the routed environment. Accordingly, packets transmitted across the network contain the computer’s external network number. Otherwise, if an internal number exists, the packets must contain the internal network number along with an appended MAC address to identify individual computers. All computers on the same network segment that use a given frame type must have the same external network number that must also be unique for each network segment.

If you replace a network adapter or connect the computer to a different segment, or if the external network number on a segment changes, you might not be able to communicate over IPX. If you lose IPX connectivity, you must reset the external network number and reboot the computer, when prompted to do so.

  • To determine the external network number and frame type that have been set on a computer running Windows Server 2003, run the ipxroute config command at the command-line interface of that computer.

  • To determine the external network number and frame type that have been set on a server running NetWare, enter config at the command-line interface of the NetWare server or inspect the Autoexec.ncf file.

Note

  • It is possible to run multiple IPX networks over the same physical network segment if those networks use different frame types.
Internal Network Number

Internal network numbers are necessary for internal routing purposes. Service-supporting hosts, which are hosts running services that SAP-based clients need to access, use internal network numbers. Service-supporting hosts use these numbers to help clients determine the optimal route for transmitting packets to services running on the service-supporting hosts. If only external network numbers are used, different routers might send a client multiple routes with the same route metrics, when only one route is actually optimal. However, if you specify an internal network number, you create a virtual network inside the service-supporting host and packets are always forwarded to the services running on the service-supporting host using an optimal path.

By default, NWLink does not identify internal network numbers. For example, when NWLink is installed, the Auto Detect feature does not detect the internal network number automatically. Instead, NWLink sets an internal network number of 00000000 on the computer’s network adapter. When set to 00000000, the internal network number is not in use for that computer. This default behavior works whether NWLink is bound to a single network adapter or to multiple network adapters. However, an internal network number is required if the computer running Windows Server 2003 is acting as a server for applications that use NetWare SAP. This includes applications such as SQL Server, Exchange Server, SNA Server, or Host Integration Server (HIS) 2000.

Depending on your configuration, you might already have an internal network number. The Routing and Remote Access service and the SAP agent automatically install a unique internal network number during setup procedures. If you previously installed any of these services, you might already have a unique internal network number set for your computer’s network adapter.

The default value of zero (00000000) for the internal network number is not returned when you type ipxroute config at the command-line interface. However, if you configure an internal network number, you can view the number using either ipxroute config, or by monitoring a trace of a RIP or SAP broadcast from the computer where the number is set.

Both Windows Server 2003 and NetWare support frame types for Ethernet, Token Ring, and FDDI topologies. The following table lists the frame types that Windows Server 2003 supports:

Frame Types Supported by Windows Server 2003

Network Type Supported Frame Types

Ethernet

Ethernet II, 802.2, 802.3, Ethernet Subnetwork Access Protocol (SNAP)

Token Ring

802.5 and 802.5 SNAP

FDDI

802.2, 802.3, and SNAP

Frame types are based upon IEEE standards and define packet formats used by various topologies.

Ethernet II

The Ethernet II frame includes a 2-byte Type field that immediately follows the source address. The Type field contains a unique value, called an EtherType*,* which identifies the receiving computer for which the upper-layer protocol handles Data field contents.

Ethernet 802.2

Several frame types are based on the IEEE 802.3 standards, which define operations for the physical layer and the MAC sublayer. NetWare combines the IEEE 802.3 standard for the physical layer and the IEEE 802.2 standard for operations of the Logical Link Control (LLC) sublayer and refers to this combination as the Ethernet 802.2 frame type.

Ethernet II and Ethernet 802.2 frames can run on the same network. Because the value in the Ethernet II Type field always equals a number greater than 1,500 and the value in the Ethernet 802.2 Length field always equals a number of 1,500 or less, network hardware and software can distinguish between these frame types. This makes it possible for both frame types to coexist on the same network.

Subnetwork Access Protocol

The Subnetwork Access Protocol (SNAP) frame type is derived from the Ethernet 802.2 frame type. The SNAP portion of the frame is carried in the Data field. This frame type gives individual vendors the ability to assign unique values for protocols running on their hardware.

Ethernet 802.3

Like the 802.2 frame, the 802.3 frame differs from the Ethernet II frame because the 802.3 frame uses a Length field in place of the Type field in Ethernet II. It is often called 802.3 raw because it does not use the 802.2 LLC header in the Data field.

Token Ring 802.5

The Token Ring protocol is composed of two distinct frame subtypes, the MAC frames and non-MAC frames:

  • MAC frames. These transmit management information for the Token Ring network. MAC frames carry signaling information and are not passed on by bridges and routers. They reside only on the LAN ring segment where the packets originate.

  • Non-MAC frames. These transmit data for Token Ring networks. Non-MAC frames transmit data between computer stations on the ring and are passed on by bridges and routers.

Note

  • The content of fields at the beginning of a Token Ring frame can redefine the composition of fields later in the frame.

The following resources contain additional information that is relevant to this section.