NetWare to Windows 2000 Server Migration Planning Guide

Article
12/09/2009

Operating System

Abstract

This document provides a guide for customers planning to migrate all or part of their NetWare environment to the Windows® 2000 Server operating system. A description of the NetWare migration and interoperability tools provided by Microsoft® is included, as well as a step by step planning guide to how the tools can be used to migrate NetWare files, directories, and file and print services to Windows 2000 Server and the Active Directory™ service.

Introduction

The introduction of a new server operating system into an organization is driven by the demands the organization has for a platform on which to build solutions for their business problems. When it is time to integrate the new operating system into the network, planning and testing is required to ensure that the new platform is integrated as smoothly as possible with minimal disruption to users.

The purpose of this white paper is to help network administrators and other IT professionals develop and execute a plan for integrating the Windows 2000 Server platform into an existing NetWare environment with the ultimate objective of migration.

The following topics are covered in this paper:

Reasons to migrate from NetWare to Windows 2000 Server.
Major migration planning decisions.
Migration tools and services available from Microsoft.
Migration planning methodology.
Migration process description.

Reasons to Migrate

This document presumes that the decision to migrate from NetWare to Windows 2000 Server has either been made or is currently being considered with the intent to evaluate migration strategies. Although there are usually a core set of reasons that prompt Novell customers to migrate to the Windows 2000 Server operating system, it is important to understand that there may be several benefits for doing so beyond those initially considered. These benefits include enhancements in the following areas:

Server Product: Windows 2000 Server provides more comprehensive, more integrated, and higher performance network operating system services than does NetWare.
Desktop Support: Windows 2000 Server is a better platform from which to manage a Windows-centric desktop environment
Network Support: Using Windows 2000 Server, NetWare customers can consolidate the number of platforms they must support, reducing support costs.

The benefits achieved in these three areas contribute to a lower total cost of ownership and a higher level of responsiveness and flexibility within a Windows 2000-based network. See Table 1 for more specific benefits that have compelled many customers to migrate to the Windows 2000 Server operating system.

Table 1 Comparing Windows 2000 Server and NetWare 5.1

Benefits	Windows 2000 Server	NetWare 5.1
Global Data Availability	Partitions span WAN links. Optimized for WAN.	Partitions are not recommended to span WAN Links. Optimized for LAN.
Internet Standards Support	Native LDAP implementation with integrated DNS namespace support	Translated LDAP implementation with not NDS namespace integration
Interoperability Support	Supports multiple synchronization, connector, and meta-directory technologies and publishes all services using LDAP	Supports only cross-platform NDS and does not publish all directory services using LDAP
Integrated Desktop Management Services	Provides desktop settings management, software distribution and desktop settings lockdown	No integrated desktop management support available. Requires separate purchase of ZENworks
File and Storage Services	Supports dynamic volume management, removable and hierarchical storage management, file replication, and distributed file system	NSS lacks these services.
Integrated VPN Solution	Supports IPSec, RADIUS and Server-to Server VPN in the box	No integrated VPN solution available. Requires separate purchase of BorderManager.
Advanced protocol and media support	Supports PPTP, SMTP, NNTP, ATM and Gigabit Ethernet as well as bandwidth and application Quality of Service	Lacks advanced protocol and media support. No QoS
Application Services	Supports distributed transactions, message queuing, universal data access, and SMP up to 32 processors and 64GB of memory	WebSphere lacks support for transactions, component and queuing services. Only provides JDBC for database access. Does not support SMP and supports 4GB of memory
Development Environment	Supports multi-language development environment (Visual Basic, C, C++, and Java). Support distributed component model (DCOM, COM, COM+ and Java)	Development environment limited to Java. No support for EJB. Only support for CORBA object model
Integrated High Availability Services	Supports load balancing, clustering of web and application servers and file replication services for file servers. (*Advanced Server only)	Not available with product. Requires separate purchase of Standby Server product
Advanced Platform Services	Supports thin client access, Voice-over-IP telephony, and streaming media services	Has no support for these features.
Application Support	Supports 8,000+ applications on Windows platform with over 500,000+ Windows developers	Supports fewer applications with little developer interest in NetWare NLMs or Java on NetWare.

Migration Path Choices

Before migrating from NetWare to Windows 2000, certain choices must be evaluated, among them:

Deciding on a gradual migration or a direct migration path from NetWare to Windows 2000.
Deciding on an automated or manual migration from NetWare to Windows 2000.

Direct vs. Gradual Migration

When migrating from a NetWare environment to Windows 2000 and the Active Directory service, there are two basic approaches: gradual migration and direct migration.

Gradual migration assumes that both directory services will coexist for an extended period of time. Direct migration assumes quick migration of all NetWare services to Windows 2000. Both migration paths are discussed later in this document in "NetWare to Windows 2000 Migration". From a business perspective, the difference between a quick and a slow migration must be evaluated according to the impact each might have on an organization. The cost and the risk associated with the two types of migration must be considered, and correlatively, the network management structure evaluated. The cost of the slower migration tends to be higher because the work is carried out over a longer period of time and requires multiple support and management resources expressly associated with an infrastructure that is complex and supplied by multiple vendors. However, the risk is lower because rollback can be done easily and problems can be resolved during the migration project with little impact on the production system.

In contrast, the quick migration has a lower cost but the risk is higher. The cost is lower in terms of both the amount of time needed to make the switch and the lower support impact on the system. However, the risk is higher because any problems that arise can create greater disruption in the production system.

Automated vs. Manual Migration

The next decision that needs to be made is whether the Windows 2000 migration should be performed manually or should employ migration tools and services.

The reasons to use migration tools are relatively clear and include the ability to automate the migration of information while using existing NetWare investments and settings to decrease the time spent on the migration. However, using migration tools and factoring in their cost may not always be necessary, particularly in the following situations:

There is little configuration investment in access control lists (ACLs) or user account information in the Novell environment.
Information is not accurate or current.
Number of objects or files is so small that it is not worth the time to learn, install, and use the migration tools.

If one of more of these situations describes your network environment, consider a manual migration in which user account information is reentered and/or file permissions are reset.

Deciding Which Systems and Services to Migrate

During the planning process, knowing which services can be migrated easily from a given NetWare environment to Windows 2000 and which tools can be used to make the migration more efficient assists in planning for migrating and integrating those services.

NetWare 3.x Environments

NetWare 3.x services typically include file, print and limited Internet services. NetWare 3.x environments use binderies to store user account and other resource information and are maintained on each server. However, replication of account information is not provided. Implementation of bindery services normally includes file and print services, although older versions of messaging, applications, and databases may also be present and rely on those services.

Migration of bindery environments represents less of a challenge because only a small number of services are subject to migration. Further, migration from NetWare bindery to Windows 2000 Active Directory is almost always desirable unless some specific application or service prevents the migration. Such scenarios might occur when an application such as Novell GroupWise cannot be easily migrated.

If migration is not an option, interoperability can be easily achieved at several levels. The Windows 2000 operating system includes services and support for connecting clients directly to Netware bindery servers or passing clients through to existing NetWare servers using Gateway Services for NetWare**.**

NetWare 4.x and 5.x Environments

Novell Directory Services (NDS), included with NetWare versions 4.x and 5.x, presents a special challenge when considering migration. Because NDS provides a hierarchical directory namespace, mapping that namespace to Windows 2000 Server requires thoughtful planning. In most circumstances, the optimum Active Directory namespace will not be the one used by NDS. This disjointed mapping is due to the basic methods of partitioning and replication, as well as the foundation of the namespace itself.

Similar namespace mappings may occur if a Geographic namespace model is used for Active Directory. Most NDS implementations follow this model to accommodate partitioning at the organizational unit (OU) level.

Active Directory and NDS provide a certain level of interoperability due to a common implementation of standards. However, there are several differences in the extent and form of that implementation that the reader should be aware of in planning a migration:

Hierarchical Namespace: Previously discussed.
Replication: NDS and Active Directory both provide replication services for the directory within each partition.
DNS: NDS provides support for basic DNS services as well as support for DNS dynamic updates. Novell's proprietary implementation differs somewhat from the Windows 2000 implementation of DNS in that no explicit mapping between NDS namespace and DNS namespace is provided.
DHCP: The primary difference between NetWare and Windows 2000 DHCP relates to their integration with the DNS dynamic update protocol. NDS dynamically registers the client IP address with the associated NDS computer object, while Active Directory dynamically registers the client IP address with the host name in DNS. Both DNS services are capable of interoperating through standard zone transfers.
LDAP Services: Both NDS and Active Directory support LDAP version 3. With a few exceptions, the implementations are interoperable even though not all NDS services are made available through LDAP.
Internet Services: From a high-level, both NetWare and Windows 2000 provide similar Internet services such as Web services. The specific implementations vary significantly, and great care should be taken when swapping Web servers. NetWare assumes a Java-centric platform, and Windows 2000 focuses on the Component Object Model (COM).
Authentication: Both products use completely different methods and protocols for authenticating clients. Windows 2000 uses Kerberos authentication over IP only, while NDS authenticates using NetWare Core Protocol over either IP (for NetWare 5.x and later versions) or more commonly IPX.
Network Security: From a high level, NetWare 5 provides a similar set of network services to Active Directory. These include support for SSL, X.509 digital certificates, and security policies. Should strategic interoperability be desired, it is recommended that you focus on the use of SSL and PKI to ensure a good level of interoperability. Both platforms support many similar security policies such as account lockout, access control, password policies, etc. These will be covered in more detail in the Security section of this document.

With a few exceptions, do not attempt to make a direct correlation between NDS partitions (that are disassociated with namespace) and partitions in Active Directory that map to DNS domains and namespace. There is an excellent white paper that contrasts the concepts and mechanics of NDS and Active Directory at https://www.microsoft.com/windows2000/guide/server/compare/default.asp.

Migration of NDS to Active Directory can normally be accomplished with little difficulty. Using the utilities provided by Microsoft Services for NetWare can help you make a successful migration, although you might want to use third-party utilities to accomplish advanced migration tasks. This issue is addressed in the next section of this document, but the reason to use third party tools relates to migrating object types other than users, organizational units (OUs), and groups.

Migration Tools and Services

Microsoft has developed a number of tools and services that can simplify the migration process. In addition, there are a number of third-party migration tools and services that can be considered as well.

Microsoft provides migration tools and services for customers in two places:

**NetWare connectivity services—**These are included with the Windows 2000 operating system.
**NetWare interoperability and migration tools and services—**These are included in a separate product, Services for NetWare (v.5).

The Windows 2000 operating system includes important NetWare connectivity services that are useful in achieving NetWare interoperability and migration. These integrated services both complement and help implement the components included in Services for NetWare.

Services for NetWare version 5 (which refers to the version of Services for Netware and not the NetWare 5 product) provides the interoperability services that actually synchronize or migrate information, files, and functionality between NetWare and Windows 2000. The interoperability services included with the Windows 2000 operating system, in contrast, include what are more accurately described as connectivity services that facilitate communication between NetWare and Windows 2000, but do not synchronize or migrate that information.

The NetWare component services included with each are reviewed below.

Connectivity Services

Three key connectivity services included in the Windows 2000 Server operating system facilitate cross-platform communication:

NWLink
Client Services for NetWare
Gateway Services for NetWare

NWLink

NWLink is an implementation of the IPX/SPX protocol used in NetWare networks. NWLink allows computers running the Windows 2000 operating system to communicate with other Windows 2000 based computers or with NetWare servers.

NWLink is fully compatible with NetWare IPX/SPX and provides efficient communication between both clients and servers.

A Windows 2000 Server-based 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, the protocol used by Novell NetWare networks. NWLink also gives NetWare clients access to applications for Windows 2000 Server such as Microsoft Exchange Server and Microsoft SQL Server™.

Windows 2000 Server-based computers running NWLink can support client applications written for OS/2, MS-DOS®, and for Windows 95, Windows 98, Windows® NT, and Windows 2000 operating systems 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 provides the following features that allow seamless communication between Windows 2000 and NetWare networks:

SPX II—NWLink supports Windows Sockets on the Novell SPX II protocol. SPX II has been enhanced to support windowing and has the capability of supporting larger frame sizes.
Multiple Bindings—NWLink can be bound to multiple network adapters with multiple frame types.
Frame Type Auto Detect—NWLink can automatically detect 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. If there are multiple frame types in use on the network, Windows 2000 will select the frame type of the first router to respond.

NWLink Frame Types

Two terms, frame type and binding, are important to understand when working with a NetWare environment. Frame type determines the manner 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. 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.

Auto Frame Type Detection

The Auto Frame Type Detection feature allows Windows 2000 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.

Manual Frame Type Detection

The NWLink protocol in Windows 2000 Server can use multiple frame types on a single network adapter. You can accomplish this by configuring NWLink in Network in Control Panel and manually selecting the frame types to be used on the network adapter.

Two issues associated with NWLink implementation often arise, both of which are easily resolved. 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, you must install a client redirector, such as Client Services for NetWare (CSNW) or Gateway Services for NetWare (GSNW).

The second common issue encountered when implementing NWLink is that in the default setting for Auto Frame Type Detection, 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 if multiple IPX frame types exist on your network.

Client Services for NetWare

Client Services for NetWare (CSNW) is a native implementation of a NetWare redirector for Windows-based clients. It is implemented as native 32-bit Windows 2000 code and includes both a service and a device driver. CSNW takes full advantage of the advanced networking architecture of Windows 2000 and provides access to NetWare file and print services. CSNW provides the following functionality:

Access to NetWare file and print servers.
16-bit NetWare application support. Microsoft has tested the NetWare Syscon, Fconsole, Pconsole, and Rconsole utilities, as well as others for use with CSNW. A complete list of supported NetWare utilities can be found in the Windows 2000 documentation.
Long File Name (LFN) support, used when the NetWare server is running the OS/2 namespace (OS2.NLM).

Support for the following protocols:
- NetWare Core Protocol (NCP): This provides file/print level access similar to Server Message Blocks (SMBs).
- Burst Mode: This provides sliding window enhancements for large data transfers.
- Large Internet Protocol (LIP): This allows routed connections to negotiate the largest available packet size.

CSNW uses the NWLink protocol. Thus, 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.x (in NDS or with Bindery Services enabled) file servers, just as NetWare clients can.

Client Services for NetWare is often confused with NWLink and Gateway Services for NetWare. CSNW provides the redirector function to NWLink that allows a Windows 2000-based computer to access NetWare file and print services.

CNSW can be used in a NetWare and Microsoft Exchange Server environment to move client systems to the robust Windows 2000 platform, without losing the ability to access NetWare services. Finally, it should be reiterated that CSNW is only useful in NetWare environments that use the IPX/SPX protocol. CSNW does not support the NetWare 5.x TCP/IP protocol in this release.

Gateway Service for NetWare

Gateway Service for NetWare (GSNW) provides two key functions. First, it allows a Windows 2000 Server to access file and print services on a NetWare server. In this function, it can be thought of as CSNW for Windows 2000 Server. GSNW also allows Windows Networking clients to pass-through to a NetWare Server. In this respect, GSNW is a gateway from Microsoft to Novell networks.

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 in NDS mode or running bindery emulation.

Gateway Service for NetWare should be used in the following scenarios:

The Windows 2000 or Microsoft Exchange server requires direct access to NetWare file or print services. One circumstance in which this service would be required is the extraction of NetWare accounts from a server or the source extraction of accounts from a NetWare-hosted messaging system such as GroupWise.
Microsoft Networking clients that require access to Novell NetWare resources through a Windows 2000 server. This requirement may exist for either Windows 2000 Server, which occasionally require access to NetWare resources, or for Windows 2000-based workstations that do not wish to fully participate in the Novell network by running the NetWare client.

Note: A gateway can only be used for a computer running Windows 2000 Server to communicate with a one Netware server at a time. Multiple simultaneous connections are not supported.

Services for NetWare (v.5)

In addition to the many built-in connectivity services included with Windows 2000, Microsoft also provides NetWare add-on utilities in a separate product called Services for NetWare version 5, which specifically address integration with NetWare. These services include the Microsoft Directory Synchronization Services, File Migration Utility, and File and Print Services for NetWare.

Microsoft Directory Synchronization Services

Microsoft Directory Synchronization Services (MSDSS) is a tool used for two-way synchronization of directory information stored in the Active Directory and NDS. MSDSS also synchronizes directory information stored in Active Directory with all versions of NetWare 3.x bindery services on a one-way basis.

Microsoft Directory Synchronization Services (MSDSS) is the cornerstone of any NDS/Bindery to Active Directory migration strategy. MSDSS also plays a critical role in long-term coexistence strategies by allowing NetWare customers to deploy Active Directory services without having to replace existing directories or bear the cost of managing two separate directories. As a result, customers have the flexibility to consolidate network management when multiple directories are required, manage accounts from either directory and use directory-enabled applications, devices, and services based on Active Directory.

Direct Migration

After installing MSDSS and a Novell client on a Windows 2000 domain controller, multiple sessions can be created in MSDSS to link pairs of containers in Active Directory and either NDS or Netware bindery services. When creating a session the administrator can select the migrate mode. You can quickly configure a migration by selecting this option and defining other session options, such as the treatment of passwords and the names of the two containers. This process can be done for a single or multiple sessions on the same MSDSS server. After one or more session has been configured, the migration can be started. The migration process, essentially, copies NDS or NetWare bindery objects, such as users, groups, and containers to the target Active Directory container preserving their structure and most schema elements. During the directory migration process, a file ACL-mapping table is generated that is used later to migrate NetWare files to Windows 2000. The file ACL-mapping table preserves file access control permissions and rights established in NDS/NetWare in the Windows 2000-based network.

Gradual Migration

If you decide to perform a gradual migration, instead of performing a migration through MSDSS, you can establish a one-way or two-way synchronization relationship between both directories. One-way synchronization is the preferred configuration when the objective is medium term migration. One-way synchronization synchronizes changes made in Active Directory to NDS (including passwords) but does not sync NDS changes to Active Directory. This configuration mode therefore provides a way to centrally administer both directories from Active Directory.

Two-way synchronization should be considered when the objective is long-term interoperability and co-existence of NDS and Active Directory. Two-way synchronization synchronizes changes made in either Active Directory or NDS with each other. This configuration mode provides a way to maintain both directories over an extended period of time while keeping the information stored in each up to date.

It is important to note that the synchronization mode, whether initially set at two-way, one-way, or migration mode, can be easily changed to provide customers with the flexibility, for example, to move from directory synchronization to migration.

MSDSS works with all versions of NDS on NetWare 4.x or 5.x operating systems and NetWare 3.x binderies and supports either IPX/SPX or Pure IP NetWare core network protocols.

File Migration Utility

The File Migration Utility (FMU) is an add-on utility included in Services for NetWare 5 that provides a central management console to automatically manage the migration of files from NetWare file and print servers to Windows 2000 Servers. The file migration utility helps customers migrate their NetWare files to a Windows 2000 Server by:

Accelerating the migration process.
Preserving file security information.
Simplifying migration management.

Migration can be a time-consuming task that is typically performed manually or with expensive third party tools. The File Migration Utility reduces the time and cost of migration by copying multiple NetWare files to one or more Windows 2000 Servers automatically.

The File Migration Utility also copies those files while preserving the permissions and ACLs associated with each file. Through granular mapping support and integration with MSDSS, files and the rights they have inherited or been assigned in NetWare are calculated and maintained in the Windows 2000-based network, preserving security and minimizing the time-consuming process of reassigning file rights and permissions.

The File Migration Utility migrates files simply, as well as quickly and securely, by providing a central point of administration for migration management. As such, administrators can monitor which files have been migrated and which haven't in a detailed report on status. Incremental migration support also allows customers to perform a gradual migration. Finally, both the TCP/IP and IPX/SPX protocols are supported to allow the migration of NetWare files and their permissions from the most recent versions of NetWare.

File and Print Services for NetWare

File and Print Services for NetWare version 5 (FPNW5) is a back-end service that allows a Windows 2000 Server to emulate a NetWare 3.12 compatible file and print server. FPNW5 usage is transparent to other NetWare resources including clients. FPNW5 allows a Windows 2000 Server to take on some of NetWare's file and print services, as well as serve as an applications platform.

It is important to note that the bindery, emulated by FPNW5, is authenticating a client logging onto a server running FPNW5. From a security perspective, the only commonality between Windows 2000 domain security and FPNW is that they share the same list of user accounts.

FPNW5 is an excellent tool to use during migration periods or when file and print services need to be offered to NetWare clients from a Windows 2000 Server. For migration purposes, it is possible to completely spoof an existing NetWare server after retirement and have the Windows 2000 Server running FPNW appear to be the retired NetWare Server.

What Can Be Migrated?

Table 2 below provides a summary of the NetWare-based elements that can be migrated automatically from the major versions of NetWare to the Windows 2000 Server, using the previously described tools and services. Elements listed that cannot be migrated automatically must be migrated manually or through alternate means

Table 2 Summary of Migration Services

NetWare Element	NetWare Versions	Microsoft Migration Tool Available?	Tool Name
Files	NetWare 3.x	Yes	FMU
	NetWare 4.x	Yes	FMU
	NetWare 5.x	Yes	FMU
Directories	NetWare 3.x	Yes	MSDSS
	NetWare 4.x	Yes	MSDSS
	NetWare 5.x	Yes	MSDSS
	NDS 8	Yes	MSDSS
F/P Servers	NetWare 3.x	Yes	FPNW5
	NetWare 4.x	Partial	FPNW5
	NetWare 5.x	Partial	FPNW5
NLMs/Applications	NetWare 3.x	N/A	N/A
	NetWare 4.x	No
	NetWare 5.x	No

NetWare to Windows 2000 Migration

Planning the Migration

The type of migration taken from NetWare to the Windows 2000 operating system will vary greatly. This section provides a discussion of recommended methodology for different levels of migration from NetWare to Windows 2000. Issues dealing with long-term integration and coexistence are addressed later in the document, and are not specifically addressed here.

NetWare Inventory

When planning the migration from Netware to Windows 2000, note these key informational points that can help you to make informed decisions about the migration method as well how to handle as disaster-recovery scenarios. Consider these main points:

Where are the NetWare Servers physically located?
Where are the Netware servers logically located?
How many Netware servers are in the environment?
What is the purpose of the Netware servers?
Who uses the servers?

With an understanding of the roles of the servers, you will be able to make the appropriate decision on the type of migration (quick or gradual) as well as understand the cost and impact of the migration on the users of these servers.

Methodology

Two general migration strategies present themselves with respect to the scope and methods that will be used during a migration from NetWare to Windows 2000. A gradual migration assumes that the migration will take place over an extended period of time. Conversely, the direct migration strategy provides the quickest path to moving services from NetWare to Windows 2000.

Both migration strategies use the steps laid out in this document. The difference in the implementation of the strategies is based on the scope of services being migrated and the definition of stages that will take place.

Gradual Migration

Gradual migration assumes the deployment of Active Directory services into a NetWare environment, and the subsequent coexistence of both directories for an extended period of time. Although a gradual migration is easy to execute, several decisions must be made regarding the level of integration and interoperability to be achieved. To help make these decisions, examine the key areas of network configuration listed below and answer the questions provided to determine the level of interoperability/integration needed.

Administration and Management

Windows 2000 includes an excellent administrative interface and common management paradigm. This raises the most difficult question to be answered concerning a gradual migration. Should administration and management be moved to Active Directory?

To answer this question, consider the following: Windows 2000 Services for NetWare 5 includes Microsoft Directory Synchronization Services that can propagate not only modifications to the directory, but also synchronize passwords. This means that as far as account administration is concerned, most aspects of administration can be truly single seat, with changes being made in both directories and reflected in the other.

Situations in which you cannot administer the directory services through a single point of administration are generally limited to NDS-integrated applications that include application extensions that cannot be directly accommodated by Active Directory, and application distribution services in NDS systems that have deployed ZENworks.

Reasons to move to Active Directory during a gradual migration:

Directory administration of clients is reduced.
Administrators gain experience in Active Directory administration during the early stages of migration.

Reasons to delay moving to Active Directory during a gradual migration:

Directory object administration is limited to those objects synchronized by MSDSS. Currently supported object types are users, groups, containers, and OUs.
Synchronization of directory security, such as access control, is not supported.

Infrastructure Services

Will primary network services, such as DNS and DHCP, be provided by NetWare or Windows 2000? DNS is a central component of the Active Directory service. The Windows 2000 implementation of DNS also includes support for standards such as the DNS dynamic update protocol, Service Resource Records, and subnet mask ordering that provide excellent value in any environment.

The two primary infrastructure services to migrate are normally DNS and DHCP. Migrating both of these services should be a straightforward affair when taking into account the following considerations:

Migration of DNS services that are based on NetWare should present no problems and is recommended due to the strong reliance of Active Directory on DNS.

Migration of DHCP services is desirable because of the integration that DHCP has with DNS. NetWare DHCP also provides services to NDS that will be unavailable if you are using Windows 2000 DHCP. NDS relies on DHCP to map client IP addresses to the computer object in NDS, while Active Directory may use DHCP to dynamically register the client IP host as an Address record in the DNS domain. To mitigate the impact of migrating infrastructure services:
1. Determine whether DHCP is being used for dynamic mapping in NDS.
2. Migrate DHCP services when NDS client name resolution is no longer required. This condition should be met when ZENworks is no longer being used.

Internet Services

Microsoft Internet Information Server (IIS) has a strong record for performance, reliability, and support for rapid application development. IIS 5 continues this tradition with expanded support for the latest standards and tight integration with Windows 2000 and Active Directory.

There is a great deal of disparity between NetWare and Windows 2000 as Internet service platforms. Decisions to be made regarding these services are:

**When to migrate—**Most Internet services in NetWare and Windows 2000 use their respective directories for authentication and access control. This requires that some amount of infrastructure be in place before moving any intranet related services. The prerequisite infrastructure for this move is an operational directory with domain controllers available for authentication.

**What to migrate—**Non-Java applications and Internet Web sites that conform to HTML, DHTML, and XML specifications should be moved first.
- Windows 2000 does not provide a direct equivalent to the BorderManager product; rather, the services that are offered by BorderManager are integrated into Windows 2000. If you are using Novell's Internet caching server, you should have no issues with the migration because this service is not dependent on the directory used or the directory structure.
- Although DNS service is really an ancillary issue, you should note that CNAME entries must be modified with respect to any named service.
**Potential issues—**Client caches may hold the address of an old Internet service provider. This issue can be addressed by flushing the browser cache.
- Web sites ported to IIS 5 should be tested in the browser client. NetWare environments often use Netscape Navigator, which does not support all functions provided by IIS 5.
**Administrative issues—**Completely separate administrative interfaces exist between NetWare and Windows 2000 Internet services. Administrators should spend some time getting acquainted with IIS 5. Detailed information about Internet Explorer 5 can be found at https://www.microsoft.com/windows/ie.

Client Services

The real power of Active Directory can be experienced when client integration is present. Apart from some excellent specifications of its own, Windows 2000 Professional includes management features that greatly reduce the cost of deploying and managing the desktop when used in conjunction with Windows 2000 Server. Client services based on Windows 2000 Professional include Kerberos authentication that will affect the NetWare login, an updated DNS stack that is capable of DNS dynamic update registration, and many active management features that can impact ZENworks (if present).

Additional client issues relate to migrating services provided by ZENworks. Features of IntelliMirror do replace the functions of ZENworks but a couple of issues remain.
IntelliMirror requires Windows 2000 installed on the desktop. Windows 95, Windows 98, and Windows NT 4 clients cannot take advantage of IntelliMirror.

The engines that drive ZENworks and IntelliMirror are not similar. There is currently no migration utility to facilitate the task of moving ZENworks NAL configurations and .AOT/.AXT packages into a Windows installer MSI package. However, there are many utilities available from third parties that allow an application to be easily repackaged as an .msi package file.

The issues surrounding migration of ZENworks environments must be addressed individually. Applications must be repackaged in .msi format to be used with Windows Installer. Fortunately, many vendors are already shipping their software in this format. In addition, scripts can be used to help transform NetWare Application Launcher (NAL) applications into Windows Installer MSI packages using such tools as Windows Script Host. Repackaging is generally recommended in order to ensure the reliability of logo-certified msi applications and the ease with which applications can be repackaged into an .msi format.

Application specific information for both Windows 2000 Server and Professional can be found at https://msdn.microsoft.com/certification/appspec.asp.

Security

Security services represent one of the foundations of Windows 2000 and Active Directory. In addition to Kerberos, Windows 2000 includes Public Key Infrastructure (PKI), virtual private networking (VPN) services, enhanced crypto API, and auditing capabilities. These services provide increased interoperability options with like services hosted on other platforms. These services also tightly integrate with Active Directory and are managed as such.

The options available for migration of security services should be addressed individually. The primary consideration will be that of client authentication. While it is theoretically feasible to provide a single authentication service on the back-end using Kerberos, it is not practical to implement under NDS. In the scenario of a gradual migration where services will be provided on both NetWare and Windows 2000 platforms, the best solution is to deploy the NetWare Client 32 on networking clients.

Reasons for Client 32 deployment:

Clients utilize native authentication using both Kerberos and Netware Core Protocol.
Works with any Windows client.

Reasons against Client 32 deployment:

Additional client resources are required to maintain both clients.
Passwords must be synchronized or clients will be prompted for passwords for both platforms.
Clients must learn to navigate both NDS and Active Directory trees.
Client 32 must be removed after migration. The stability of this procedure is not known.
Clients may require IPX installed if it is not present on the NetWare servers.

Several excellent documents on security technologies can be found at https://www.microsoft.com/windows2000/techinfo/howitworks/default.asp.

The additional security topic that needs to be addressed during a gradual migration is security policy. Earlier in the document, a brief discussion of common security elements was introduced. Fundamentally, both products address security in the same manner–through policies, standards, and procedures. Both Windows 2000 and NetWare also introduce aspects of security that can be considered proprietary and are not interoperable. The commonality and differences are provided in the following table with the interoperable services.

Table 3 Security Interoperability Summary

Security Element	Item	Windows 2000 Service	NetWare Service	Interoperability Available
Standards	Authentication	Kerberos	NCP	No
		X.509 v3	X.509 v3	Yes
	Network Security	SSL/TLS	SSL v3	Yes (SSL)
		NetLogon	Packet Signatures	No
	File System	NTFS/EFS	NFS	No
Polices	Account	Account Lockout		Yes
		Unique Passwords		Yes
		Time Restrictions	Time Restrictions	Yes
		Complex Passwords	Complex Passwords	Yes
	Server	Restricted Network Access	Restricted Network Access	Yes
		Restricted Console Access	Restricted Console Access	Yes
		IPSec	NCP Packet Signatures	No
		Restrict Physical Access	Restrict Physical Access	Yes

Access Control

Gradual migrations will always result in separately managed access control of services. Even though Active Directory may effectively subsume account administration, services, including security services, provided in the NetWare environment will ultimately require separate administration. Early in the planning process, a thorough discovery of security services should be performed and those areas that will require manual administration will need to be identified.

Window 2000 and all of its services share a similar paradigm in terms of access control. This paradigm however is usually not the same as NetWare. As such a 1:1 mapping of object and attribute level security is not always possible. The issues regarding access control relate primarily to NDS OUs being used as security principals. Granting object rights to an OU in NDS has a filtering effect on those objects contained within the OU. This behavior is referred to as dynamic inheritance and is not implemented in Active Directory. When performing object mappings between NDS and Active Directory, the inherited rights of objects in NDS should be documented for proper implementation within Active Directory.

In any case, it is almost always appropriate to establish Active Directory groups that mirror NDS OUs that have been given rights assignment. Once established, Active Directory groups can be assigned the same level of access control as the OU in NDS.

Other factors that should be considered when examining a gradual migration are interoperability, administration, and management. The gradual migration strategy does allow an organization to use services provided by both NetWare and Windows 2000 platforms. By using two distinct platforms, many administrative functions must be performed on both platforms. This is particularly true of access control of the directories themselves.

Long Term Management

The gradual migration strategy assumes an extended period of coexistence of the two operating systems. Whether or not Active Directory services have been determined to be the focal point for providing directory services, certain issues must addressed regarding directory management.

Directory management may be effectively performed from NDS or Active Directory or both. There are limitations to the scope of directory management that can be performed, however, and advantages and disadvantages to management from either during migration.

The scope of single directory management is limited to those objects that are subject to synchronization between Active Directory and NDS using MSDSS. Although this scope might include most of the directory, many functions of proprietary management will remain. NetWare requires that all system services and partitioning as well as ZENworks administration be performed using administrative utilities native to NetWare. Likewise, Active Directory requires direct administration of services specific to Active Directory. However, since most directory administration is associated with objects that are also the most frequently modified (such as users, groups, and containers) and that can be replicated between the directory services, dual management will be minimal.

The primary consideration relative to management is which directory will act as the focal point of administration: NDS as a primary point, or Active Directory services as the primary point of administration. Even in the case of long-term coexistence, it is strongly recommended that management be moved to Active Directory. This is because of the processing and network costs associated with reverse synchronization (from NDS to Active Directory), the ability of MSDSS to only synchronize passwords in a forward synchronization mode (Active Directory to NDS) and the additional administrative overhead associated with dual administration.

Note that reverse synchronization requires that the entire NDS directory be queried and compared to Active Directory to discern changes. In contrast, MSDSS implements forward synchronization that uses attribute level synchronization nearly as efficient as Active Directory replication itself.

Direct Migration

Contrasted with gradual migration, a direct migration assumes a rapid migration of all services from NetWare to Windows 2000. Like gradual migration, this strategy does not preclude the continued hosting of certain services in the legacy NetWare environment, but it does assume the following attributes of deployment.

**Client preference is considered to be native Windows 2000—**The direct migration is often performed in conjunction with a Windows 2000 client deployment that precludes the necessity of also deploying the NetWare client redirector.
**Authentication and client services that require access control are migrated quickly—**The scope of this task entails migrating the directory itself, along with heavily used file and print services. Supplemental services such as Gateway Services for NetWare and File and Print Services for NetWare can be used for those secure resources that cannot be rapidly migrated.
**Administration of account, computer, and group resources are performed exclusively through Active Directory—**This is easily accomplished through the use of MSDSS. Apart from the initial reverse synchronization to populate Active Directory, continuing synchronization uses only one-way synchronization to publish changes from Active Directory to NDS or NetWare 3.x binderies.

Transitional Management

The management of all synchronized objects solely through Active Directory always accompanies direct migration. This occurs so you can gain the benefit of the strong administrative and managerial features of Active Directory and gain early administrative familiarity with the product.

Chief among the Active Directory management strengths is the capability to use the IntelliMirror® management technologies. The migration of clients should be preceded by a strong client management plan. The best management plan is apply policy to clients immediately upon migration to Active Directory and Windows 2000. The ability to effectively manage clients is reduced over time, as client configurations become more diverse through usage. Managing Windows 2000 clients as they appear ensures a known state for managing them.

Choosing a Path

The greater the investment made in NetWare, the more likely the choice of a gradual migration path. This is normally the case if you want to mitigate the impact of moving a large system at a rapid pace. Forced gradual migrations are likely to occur in organizations that have deployed GroupWise and NDS. Most organizations that have fully deployed ZENworks will also probably choose this path so that the transition between management systems is a smooth one for the clients.

In many cases, however, it is desirable to rapidly replace NDS with the Active Directory service. The most common direct migration scenarios deal with the rollout of new desktops or a pressing requirement to migrate from an older NDS or Bindery system to a more comprehensive network operating system.

The direct migration path is also suitable for small to medium-sized organizations that have not deployed complex applications on NDS. Migration in these cases can normally be accomplished in a short amount of time with minimal impact to business operations. Regardless of the intended path, most large organizations should assume an incremental migration due to the period of extended coexistence required during migration.

Even simple infrastructure scenarios such as infrastructure deployment require background planning. The Active Directory service is composed of many components that are inter-related. The breadth of services and benefits included in Windows 2000 are likely to encourage wide-scale deployments where none were anticipated.

Other Migration Issues

Other circumstances that might require special attention during the migration-planning phase are addressed in the following sections.

NDS for Windows NT

NDS for Windows NT provides a subset of NDS services in an un-replicated NDS partition. This product, based on redirection, does not exist for Windows 2000 (at time of writing) so migration of those services must be planned. NDS for Windows NT effectively represented Windows NT 4 resources within the NDS tree and re-directed the Windows NT Server SAMserv .dll to NDS for authentication. The best migration path is to simply uninstall NDS for Windows NT and revert to a Windows NT domain structure in anticipation of quick in-place upgrade to Windows 2000 Server. You can do this by clicking Start, pointing to Programs, clicking Novell (Common), and in the Domain Object wizard, click one of the three options present as outlined by Novell in their NDS product documentation:

Uninstall NDS and Include New NDS Information in the Windows NT Domain. This option reads the current Windows NT domain information from NDS and moves it to the Windows NT domain. If you have added users and other objects to NDS since moving the Windows NT domain to NDS, those objects are added to the Windows NT domain. Any objects that were originally in the Windows NT domain but were not moved to NDS are no longer in the domain.
Uninstall NDS and Update the Passwords from NDS. This option makes everything the same as it was before NDS was installed except for the passwords. Windows NT passwords remain the same as they currently are in NDS.
Uninstall NDS. This option makes everything the same as it was before NDS was installed. The administrator account password is updated to the current password.

Once uninstalled, the Windows NT Server can be upgraded in-place to Windows 2000 Server.

Bindery Migration

So far, we have primarily discussed migration from an NDS environment. While there is much involved in that process, NetWare bindery will be the more common migration scenario due to the greater abundance of NetWare 3.x servers in Novell environments. Fortunately, the limited services provided through bindery make migration quite easy.

MSDSS supports synchronization between Active Directory and NetWare bindery. The options for migration strategy in this case vary significantly from NDS.

First, the services provided through NetWare bindery are limited to basic account information and file and print services. Unfortunately, these services are explicit for each NetWare server, requiring that synchronization sessions be established to several NetWare servers to extract complete account information. After the initial reverse synchronization, it is rarely necessary to perform one again.

Bindery services require the extensive use of the File Migration Utility to migrate NetWare volumes and file resources.

Legacy access to bindery resources can be provided through GSNW or CSNW. If a large number of clients are being migrated prior to file and print services, it may be appropriate to maintain the NWLink and CSNW instead of GSNW. GSNW will not perform well with heavy client access.

Finally, if NetWare clients are to be maintained or administrator retraining needs to be minimized, the File and Print Services for NetWare utility can be installed on a Windows 2000 file and print server to emulate the NetWare 3.x environment.

ZENworks

Although few in number, fully deployed ZENworks environments present a special challenge during migration. Although many of the functions of ZENworks have equivalents in IntelliMirror (specifically, using Group Policy logon scripts and application deployment), there is no conversion utility to move from ZENworks NAL packages to Windows Installer .msi packages. Such a migration often requires a gradual migration strategy to mitigate the impact on client and administrative systems. Simple removal of ZENworks from the client without replacing that functionality results in the disruption of the clients. On the other hand, leaving ZENworks in place does not bring the organization any closer to an efficient desktop management solution.

Two strategies are available to solve this dilemma: management migration and client migration.

Management Migration

ZENworks provides many of the services offered by Microsoft System Management Server (SMS) 2.0. Should comprehensive system management of multiple client operating systems be required, direct migration from ZENworks to SMS 2.0 is strongly recommended.

The migration of the management system, ZENworks to Systems Management Server, requires little Windows 2000 infrastructure and can be performed before the migration of any other systems. Gradual migrations resulting in long-term coexistence are particularly well suited to this strategy as well.

For additional information on this subject, see the "Integrating SMS 2.0 with Novell Netware" white paper at https://www.microsoft.com/technet/sms/20/default.mspx

Client Migration

If the deployment of SMS is not an option, the migration of clients to the Windows 2000 Professional operating system is preferred. This strategy assumes that ZENworks will continue to be used until all clients are migrated to Windows 2000 Professional.

Because removing ZENworks from a client is a difficult process, it is preferable to perform a clean installation of Windows 2000 on the client to bring the client to a known, manageable state.

Finally, its important to assess whether a conversion of NAL .AOT/.AXT application packages is even desirable. In most environments customers find that it might be easier and result in a more stable application deployment if they repackage their applications using a third party tool that makes those applications Certified for Windows 2000 logo compliant .msi packages. By starting from scratch, customers can ensure that their logo-compliant applications are reliable and stable, resulting in higher availability and lower support costs.

Steps to Migration

The tools used to accomplish most migrations from NetWare to Windows 2000 are included with Services for NetWare 5 and Windows 2000 Server. Regardless of the type of migration to be performed, the steps to accomplish a migration are largely the same. Differences in implementation fall within the scope of services to be migrated and the administrative procedures used during the migration period. This section provides an overview of migration steps with particular emphasis on planning requirements. References are made to other documentation that discusses the details of each step.

Other than the initial requirements and service discussions, the primary steps covered in the section are:

Preparation and MSDSS installation.
Migrate/synchronize NDS/Bindery to Active Directory.
Migrate file and print services.
Migrate files.

After planning the initial steps of any migration process, whether direct or gradual, you can either migrate or synchronize NDS or NetWare 3.x binderies to Active Directory. After directory migration or synchronization occurs, file and print services and files can be migrated.

Each of the steps listed above have other specific procedures that are detailed in each section.

DNS Considerations

Most NDS environments do not depend on DNS for NetWare related services because NDS uses SLP, or SAP, for name resolution services. Still, DNS is usually present to specifically service client browser functionality and other Internet services.

In these circumstances, it is a simple matter to migrate DNS services to Windows 2000. If DHCP is being used to manage client IP addresses, all DHCP clients can be reoriented to Windows 2000 DNS through IP scope options. In cases where static IP addressing is being used, manual entries must be made.

To initially populate the Windows 2000 DNS database, the Windows 2000 DNS server can initially be configured as a secondary zone and receive transfers from the NDS-based master.

Note: Windows 2000 DNS should not be Active Directory-integrated during the initial zone transfer. The DNS file will be needed to initiate the primary zone.

After the initial zone transfer, it is a good idea to transfer the responsibilities of the primary zone to take advantage of the DNS dynamic update capability in Windows 2000 DNS. Removing the secondary zone definition, editing the start of authority (SOA) record of the xxx.DNS file, and creating a new primary zone, which points to the edited file for the database, can accomplish this.

DHCP

DHCP should be considered a critical service in NDS. The DHCP server dynamically registers the client's IP address in the NDS database with the associated computer name. This requires that the transfer of DHCP services occur only as the last clients on a particular scope are migrated.

Network Prerequisites

Legacy NDS clients can use one of four network protocol modes: IP only, IPX only, IP with IPX compatibility, or IP and IPX together. Pure IP is a recent feature of NetWare (added in NetWare 5); so most environments might still be using either IPX or IP and IPX mode.

The Windows 2000 domain controller running the Microsoft Directory Synchronization Service requires the NetWare client installed in a mode that allows communication to the NDS tree. Directory Synchronization works on a client using IP only, but the server attached to it for synchronization must be in CMD mode.

Authentication

Clients configured with both Client 32 and Microsoft Networking can authenticate using both NDS and Active Directory. Two options are available that should cover most scenarios:

Native Authentication: Desktops currently configured to authenticate with NDS should continue to do so. Simply adding Microsoft Networking to the client and configuring the appropriate settings ensures a smooth coexistence between the two back ends.
Gateway Services: New Windows 2000 clients and servers should not run Client 32 unless absolutely necessary. Instead, configure one or more servers with Gateway Services for NetWare to provide client access to NetWare resources during migration.

Clients

Numerous clients exist in most environments. Whether the clients are accessing NetWare bindery or a version of NDS, most operating systems are capable of authenticating with Active Directory.

Most NetWare clients will be running IPX unless a full NDS migration to pure IP has been performed. If this is the case, it is strongly recommended that all clients have IP installed to facilitate authentication and communication with Active Directory. Avoid installing IPX on Windows 2000 clients if possible to limit the amount of client protocols to be managed and lessen network chatter caused by IPX.

Should it be necessary to install the NetWare Client 32 redirector on Windows 2000 Professional clients, administrators must obtain that software from Novell. Windows 2000 includes only the software components necessary to upgrade an existing Novell client on Windows NT Workstation 4.0. Microsoft did this to allow a seamless upgrade from Windows NT Workstation 4.0 to Windows 2000 Professional for Windows NT Workstation 4 clients with existing installed Novell clients. Fresh installations of Windows 2000 Professional or Windows NT Workstation 4 upgrades that do not have an existing Novell client will not be accompanied and will not install a Novell client.

Preparing to Install MSDSS

This section covers the steps necessary to install MSDSS and prepare for synchronization between Active Directory and either NDS or NetWare 3.x bindery environments. For more detailed documentation, see the MSDSS Deployment Guide. Topics covered in this section include:

Creating the Active Directory tree,
Installing NetWare Client 32 Redirector
Extending the Active Directory Schema
Extending the NDS Schema.

Details and procedures of actual software installation for MSDSS can be found in product documentation and the Getting Started Guide.

The Services for NetWare (SFNW) tool used is MSDSS.

Creating the Active Directory Tree

There are two basic options for migration: the first is to use the tools provided to use the existing NDS tree to create an identical Active Directory tree structure, and the second, to set up the structure of Active Directory without regard to the NDS implementation. In this paper, the first option is discussed in detail. For more information on the second option, refer to the Windows 2000 Deployment Guide.

The first step in beginning the migration process is to populate the Active Directory using the directory information from NDS or account information from the NetWare 3.x bindery. Although establishing standard configuration options are beyond the scope of this document, some specific decisions and actions need to be performed prior to the initial synchronization session.

Two types of sessions are available during session establishment: location driven synchronization and object level synchronization.

Location level synchronization synchronizes objects that have either been modified or moved to a different location in the directory.
Object level synchronization synchronizes objects that have been modified, but ignores changes in the object location.

Which one should you plan to use? You will probably need both in the course of establishing sessions to synchronize all desired OUs. When the namespace of Active Directory coincides with that used in NDS or you want to just copy the existing NDS structure to Active Directory, location synchronization should be used. When the namespace between the two directories is disjointed, it is generally best to choose object driven.

The following scenarios illustrate the concepts of location-driven and object-driven synchronization.

Streetmarket, a fictional company, has deployed Active Directory in an existing NDS directory environment. The Streetmarket administrator established two directory synchronization sessions:

A location-based session for its manufacturing department.
An object-based session for its distribution department.

No session has been configured to accommodate change propagation for the headquarters unit, a separate organizational unit. In this scenario, the changes made will have the results described in the following table.

Table 3 Active Directory Initialization

Active Directory Change	NDS Result	Reason
The Manufacturing OU is renamed Products.	Session mapped OU in NDS is renamed to Products.	A name change has occurred.
User is deleted from Headquarters.	NDS is not updated.	No synchronization session has been configured for Headquarters.
User is deleted from Manufacturing.	NDS is updated.	An object change (delete) has occurred to an object within the scope of a session.
User is moved from distribution to a child OU of Distribution	NDS is not updated.	The location of the object is still within the object-based session.
User is moved from Distribution OU to the Products OU.	NDS is updated.	In this case, the user is moved out of the object-based session scope into the location based session scope.
User is moved from Products OU to a child OU of Products.	NDS is updated.	Object move has occurred within the scope of a location-based session.

Being able to limit the affect of object moves should provide enough flexibility during namespace planning that the current NDS structure will have little influence on the Active Directory.

Determine the directory structure of Active Directory and then predetermine the desired mappings and the scope of synchronization sessions.

This discussion focuses on which objects within a single NDS OU need to be mapped to more than one OU in Active Directory. In this case, it is advisable to establish a staging OU in Active Directory to initially receive all of the objects from the single NDS OU. At this point, two options are available:

The objects are left in the temporary OU until migration of the OU is complete and the session no longer required. At that point, the objects can be placed in their proper locations in Active Directory.
After the initial synchronization, the objects are moved to their respective OUs in Active Directory. The session will be removed; a staging container established in NDS, and a new one-way session (no reverse synchronization) is created to propagate the users in multiple OUs to the new single NDS staging OU.

Should the inverse of this scenario occur, in which multiple NDS OUs will be mapped to a single Active Directory OU, perform a normal initial synchronization and then a standard one-way session to propagate changes from the Active Directory OU to the multiple NDS OUs.

In any case, do not allow the NDS structure to dictate the Active Directory structure unless the NDS structure is appropriate for the organization. As mentioned previously, the underlying structures of the two directories do not normally coincide.

The last task of Active Directory initialization is to ensure that enough Windows 2000 servers exist to handle the synchronization loads. Loads generated by MSDSS sessions are not heavy but must be run on a Windows 2000 domain controller. The more objects, sessions, and higher frequency of synchronization loads may justify the establishment of an additional domain controller placed near the NDS server that is connected to it as a subscriber directory.

Installing NetWare Client 32 Redirector

MSDSS requires the NetWare Client 32 redirector in order to perform NCP (Netware Core Protocol) functions over IP, to enable password synchronization, and to capture changes made in NDS so that they can be propagated to Active Directory. When operating in a pure IP environment, it is not necessary to install IPX/SPX (NWLink) on the synchronization servers. IPX/SPX is required, however, on the Windows 2000 client that will be performing the Schema update.

Extending Active Directory Schema

A schema extension is performed only once and it is normally a permanent update. You must be a member of the Schema Administrators group to perform schema extensions, in order to protect against unauthorized schema modification.

The Active Directory schema may need to be extended for two-way directory synchronization of all schema attributes to function. It is a single master operation and you require access to the schema master to perform it. After the schema has been extended, you can successfully run the Microsoft Directory Synchronization Service installation process.

Extending the schema can be performed using the command line switch:

msiexec /a dirsync.msi SCHEMAUPDATE=1

Note: he /a signifies an administrative install and SCHEMAUPDATE=1 tells dirsync.msi to update the Active Directory schema and not do anything else. Refer to Appendix B of the MSDSS Deployment guide for additional notes on Active Directory schema updates.

Due to the nature of the schema, permissions to make changes are restricted to members of the Schema Administrators group. Further, domain controllers may not make modifications to the schema. MSDSS, however, does need to make changes to the Active Directory schema, so note the following points:

The schema update may be accomplished either during installation of MSDSS or manually through command line. Refer to MSDSS Deployment Guide for details.
The Schema master must be available during the installation of MSDSS or manual schema update.

The easiest method of schema update is to perform the operation using the command line method from the domain controller Schema master. If this is not convenient, follow the procedures given in the MSDSS section of this document.

Extending NDS Schema

The NDS schema can be extended during the creation of a new session or from a supplied command-line utility. The NDS schema might only need to be extended when two-way synchronization is required. Supervisor rights to the root object of the tree and access to the server that holds the Master replica of the Root partition are required. This server then propagates the changes to all the servers in the tree. If schema extensions are necessary during the creation of a new session, you are prompted by the MSDSS Setup wizard to make these changes.

If you want to extend an NDS schema after a session has been created, you can use the Directory Synchronization NDS Schema Extension Tool provided in the systemroot\System32\Directory Synchronization\Client folder. This tool is a command-line utility (NDSext.exe) that can extend the NDS schema of a specified tree.

Note: You must have the Novell Client 32 redirector, Client Services for NetWare (CSNW) or Gateway Services for NetWare (GSNW) installed to update the NDS Schema.

The NDS schema can be extended during the creation of the first session or through the command line. For details and prerequisites, refer to the MSDSS Deployment Guide and details provided in the MSDSS Getting Started Documentation that accompanies the MSDSS software.

Migrate/Synchronize NDS to Active Directory

After session planning and installation of MSDSS, the next step is to begin establishing directory synchronization or migration sessions according to the migration plan. The implementation configuration of individual sessions is done according to the plan established during the initialization of Active Directory. The tasks covered in this section include:

Create initial synchronization sessions
Perform reverse synchronization
One-way synchronization
Two-way synchronization
Migration

The SFNW tool used is MSDSS.

For more detailed documentation, see the MSDSS Deployment Guide and MSDSS Getting Started Guide.

One part of session planning has been deferred to this point. Depending on the migration scope and type, sessions will be configured to perform synchronization on a one-time migration basis, one-way (from Active Directory to NDS) or two-way. The additional option of performing an initial reverse synchronization must also be decided at this time. Each of these options will be addressed in this section.

Initial Synchronization

The core of the directory migration process is the initial synchronization of NDS with Active Directory. Establishing the initial Directory Synchronization session specifies whether migration, one-way or two-way synchronization will be used, as well as whether or not to perform an initial reverse synchronization from NDS to Active Directory.

Initial synchronization begins with creating a session. With this session, you define parameters that characterize how specific information is to be synchronized between the two directories by relating pairs of organizational units in NDS and Active Directory with each other.

Each session contains the configuration information about the publishing and subscribing directories necessary to perform the synchronization.

The following information must be supplied when creating a new session:

Specify the publisher and subscriber directories. Active Directory will be the publisher and NDS (or NetWare 3.x bindery) can be selected as the subscriber.
Select synchronization mode. After the initial synchronization is performed, selecting one-way allows the publishing Active Directory to propagate changes to the subscribing NDS directory. Two-way synchronization allows changes in both directories to be published to the other. Finally, the migration option performs a reverse initial synchronization once, which populates Active Directory and then severs any ongoing synchronization between the two directories.
Define the treatment of NDS passwords. Because MSDSS allows for the one-way synchronization of passwords, user account passwords in NDS or NetWare 3.x binderies must be reset because neither directory service provides a way to read or capture Novell passwords.
Specify the publisher container that contains the data to be synchronized with the subscriber. This step establishes the mapping of OUs or sub-trees.
Specify the computer that hosts this synchronization session (the computer where the Directory Synchronization Server component was installed).
Specify the subscriber container to be synchronized with the publisher. If the container does not exist in NDS, it must be created before specifying it here.
Specify the administrative account and password necessary to access the subscriber. This will normally be the NetWare Administrator account or equivalent.
Select the initial synchronization options. During an initial synchronization, you copy specified data from one directory to another. An initial reverse synchronization is a one-time process, rather than an ongoing process based on a schedule. During initial synchronization, you can either copy directories or merge them.

The subscribing directory (NDS or Bindery) must be selected upon creation of a new session. Once selected you need to supply information regarding which subscribing container will be used for synchronization. Two options are available during the creation of an initial synchronization session:

Perform Initial Synchronization
- Choosing to perform an initial synchronization will result in a reverse synchronization.
- During this time, you are also prompted to select the method for password generation. Options are random, blank, set to user account name, or all passwords set to a specified value. For details on this password generation, refer to the MSDSS Getting Started Guide.
Skip Initial Synchronization
- When choosing to skip the initial synchronization process, you can create multiple sessions in sequence and then synchronize them later at the same time. Normally, an initial synchronization is performed during both a direct and a gradual migration.

When electing to perform an initial synchronization, a reverse synchronization is performed and Active Directory is populated with NDS objects according to the options previously specified.

Note: When selecting a subscribing container, you must also supply the credentials that the Directory Synchronization service will use to access the subscriber. For example, if you are synchronizing Active Directory with NDS, the Directory Synchronization service account is that of the NetWare administrator.

One-way Synchronization

One-way synchronization is often used in smaller companies and during direct migrations. After the initial (reverse) synchronization is complete, changes to objects within the scope of a given session will be synchronized (published) to the subscribing NDS containers according to the rules (object, location, object type, and schedule) defined during the session establishment.

One-way synchronization assumes that administration of synchronized objects will be performed through Active Directory. A second assumption is that the objects being synchronized are intended to use Active Directory as the primary platform for directory services.

Two-way Synchronization

Choosing to perform two-way synchronization results in propagating changes made in either directory to each other. Two-way synchronization is really two distinct processes in which a forward (such as one-way) synchronization takes place independently of changes to NDS being propagated to Active Directory. The second process is actually a reverse synchronization.

When two-way synchronizations are performed, the objects within the scope of the subject session continue to be administrated through Netware NDS or Bindery. This is generally the case during a gradual migration and in organizations that have large or highly distributed NDS services.

Under all circumstances, sessions that publish to NetWare Bindery should only use one-way synchronization.

Migration

Choosing to perform a migration results in copying Novell-based user accounts, groups, OUs, and other container objects to Active Directory on a one-time basis. After completed, no ongoing synchronization relationship exists, and the directory/bindery objects are just copied to Active Directory, providing the most direct way to migrate Novell information.

It is important to note that the synchronization mode initially selected for any session can be changed. This is useful, for example, in gradual migration scenarios when synchronization between Active Directory and NDS are required for a period of time, after which all NDS directory services are migrated to Windows 2000 Server.

The initial synchronization is significant in relation to the reverse synchronization and password policy to be used. It is not possible to extract the user account passwords from NDS, so user accounts that are created in NDS and synchronized to Active Directory services will have passwords created according to a policy defined in the synchronization session.

Object mapping must also be selected at this time. Object mapping determines whether objects are mapped based on the name of the object or a custom mapping that allows synchronization of objects dependent of location. These decisions should be made by this point.

Migrate Files and Print Services

This section discusses ways to mitigate the impact of migration on file and print services. Steps to actually migrate the files are included later in this document. The steps covered in this section include:

Configuring Gateway Services for NetWare
Configuring File and Print Services for NetWare

The SFNW and connectivity tools used include: GSNW, FPNW5

For more detailed documentation, see the Windows 2000 Server product documentation.

Establishing file and print services during migration is an important step in the migration process. The establishment of NetWare-based file services during a period of client transition may be required even when migrating files.

The options for this step are to either allow access to NetWare volumes for native Windows 2000-based clients or to establish file and print services hosted on Windows 2000 that are accessible using the NetWare client.

These options are facilitated through the use of Gateway Services for NetWare (GSNW), which is included with the Windows 2000 operating system and File and Print Services for NetWare 5 that ships as part of SFNW.

Both of these utilities receive secondary consideration during migration planning but play a powerful role in filling gaps in the migration process. Take the following scenarios for example:

Suppose an organization desires a rapid (direct) migration of clients to Windows 2000 and Active Directory. This subject company also wants to avoid deploying the NetWare Client redirector on the clients. Once the migration (synchronization) of user accounts is complete, GSNW can be used to allow access to NetWare based volumes to Windows 2000 clients. This is particularly useful until such time that all clients that require access to the NetWare volumes can be migrated and the files subsequently migrated to Windows 2000 volumes.

Another common scenario occurs when a delay exists in the migration of the desktops themselves. Users who have used a NetWare platform to host their file and print services have become accustomed to its interface from both a user and an administrator point of view. To minimize the collateral impact and cost of the migration, File and Print services for NetWare allows a computer running Windows 2000 Server to actually look like a NetWare 3.12 file and print server. This also assists NetWare administrators during the migration period by giving them a familiar administrative paradigm for file and print administration.

Configuring Gateway Services for NetWare

Gateway Services for NetWare (GSNW) serves a critical role in most migrations. Regardless of the success of a migration, there usually remains some service or resource that must remain on the legacy system. In these cases, it is not desirable to configure migrated clients with the NetWare client. GSNW is an excellent method of providing access to NetWare based resources from single or multiple points on the Windows 2000-based network. Giving migrated clients access to NetWare-based resources in this manner ensures uninterrupted service to the clients.

The strategy for use of GSNW must draw a line between providing easy access to resources and optimizing performance. The common initial use of GSNW is to give NetWare-based file access to clients as they migrate. In most instances, clients are unaware of the gateway service because identical drive mappings are used to provide access to a particular resource. During some point in the client migration process, however, the resource itself should be moved to mitigate potential performance degradation associated with gateway use.

During the installation of GSNW, you will be prompted for the user, the default tree and context for the preferred server. The server specified should optimally host the NetWare volumes that will be configured through the gateway later.

The configuration of the Gateway itself allows access to specified NetWare resources through one or more configured connections. The service acts by converting client requests (SMB) to NetWare Core Protocol (NCP) requests. Note that the Gateway server is acting on behalf of the client.

To configure the Gateway, a group named NTGATEWAY must exist on the NetWare server of NDS. This group should have appropriate access privileges to the resources that will be accessed.

There must be a user account specified that exists on the NetWare network. This account should be a member of the NTGATEWAY group.

For each NetWare volume or printers that is to be accessed, activate a gateway.

Security is provided on both the Windows 2000 gateway server by setting access permissions on the share, and on the Netware resource using trustee rights for the user account used for the Gateway.

Configuring File and Print Services for NetWare

The configuration of FPNW is a simple wizard-driven installation process. Questions that must be known during installation are:

Server Name: What server name will be advertised to NetWare clients?
SYS Volume: Like NetWare, FPNW will require that a directory be specified for mapping to the server's NetWare style SYS volume.
Supervisor Account: Selecting a supervisor password will be required during installation.
Performance Tuning: Advanced server tuning can be set to specify the expected number of user that will be accessing the server as well as performance optimization preference to file services.

If you are installing FPNW on a domain controller, you are prompted to enter a password for the FPNW Service Account. If you install FPNW on multiple domain controllers in a domain, you must specify the same password for this account on each domain controller on which you install the utility.

Once FPNW is fully established and users are accessing their NetWare files through a Windows 2000 file and print server that is emulating a NetWare 3.12 server, the emulation can continue indefinitely. However, after files have been migrated, there is little need to maintain FPNW, except to allow administrators to maintain the NetWare user interface.

Migrating Files

Establishing Gateway services for access to NetWare volumes is an excellent solution during the migration period. But during the migration, there will be a point at which NetWare volumes must be moved to Windows 2000 hosts. The File Migration Utility (FMU) provides the functionality to perform these operations. The steps covered in this section include:

Identifying source and target volumes
Ensuring that security associations exist
File migration
Disabling legacy file access

The SFNW tool used in this section is the File Migration Utility.

For more detailed documentation see the File Migration Utility product documentation

The FMU can be used in either a direct or gradual migration scenario and is used at the point where the migration of all users that access a particular NetWare file resource is complete. FMU can be used to carry out the primary migration strategy in either scenario:

The use of FMU in a direct migration allows identification and rapid migration of a large number of files based on groups of files, directories, or volumes. The utility is sophisticated enough to provide reliable reporting on the status of the file migration.
The ability to migrate small groups of files also accommodates a gradual migration. During the process of migrating users, there will be points at which all of the users that were accessing a particular directory have been migrated. These directories or groups of files can then be quickly migrated and client access redirected to the new Windows 2000 share.

FMU complements the use of FPNW. When required (such as in a direct migration), files can be migrated before the clients are completely migrated, allowing the clients to continue to view the shares as NetWare volumes.

File migration is a complex task made easy through the use of FMU. There are only a few steps to the process that are covered in the following sections.

FMU supports a variety of client platforms and will work over either IPX or IP. Supported platforms for network clients are:

Windows 2000 standard network client (integrated with the operating system, no installation required)
Novell Netware Client 4.7 or later

Supported operating systems are the following:

Windows 2000 Server
Windows 2000 Professional
Novell NetWare 3.x, 4.x, 5.x

Supported directory services are the following:

Active Directory
Novell NDS 4.x, 5.x
Novell NetWare 3.x binderies

Identifying Source and Target Volumes

After identifying what files can be migrated, the next step in the migration process is to identify both the source (NetWare-based) files and where they will be migrated to in Windows 2000. This visual mapping process is provided in the FMU wizard.

During this process statistics are built and displayed regarding the number of files to be migrated and total size. FMU also checks for available disk space on the destination volume.

Ensuring Security Associations Exist

Because access rights are maintained during the file migration process, it is important to note that the security principles that had rights to the target files also exist, post-migration, in Active Directory.

The following table lists the access right mappings that are made during the migration.

Novell File System Rights	Microsoft NTFS
Read	Read
Write	Write
Modify	Read/Write*
Create	Write
Erase	Delete
Access Control	Change Permissions
File Scan	Read

These mappings are Read permissions with the exception of the Modify permission, which can be changed prior to running the migration job.

File Migration

Once started, the FMU provides visual and logged status on the migration progress. Duplicate files that exist on the target volume will be overwritten.

Upon completion, the results can be displayed, which demonstrate:

Total volumes migrated.
Directories per volume migrated.
Files per volume migrated.
Total files migrated.
Number of errors encountered.

Note: During the file migration process, user access to their files remains uninterrupted because FMU supports in-process file access

Disabling Legacy File Access

It is important to note that this is not a synchronization utility. Unless files that are migrated have Read permissions, it is important to remove access to the files on the NetWare side before migration and keep it removed after migration is complete.

Additional Operations

Finishing the Job

The final task during a migration is decommissioning the NetWare servers. This is not a difficult process, but still requires thoughtful planning so the retirement is accomplished in an incremental fashion.

Appendix A includes excerpts from the MSDSS deployment guide that address specific requirements and the steps taken during this process.

Supplementary Information

Ancillary planning issues are discussed in this section.

Object Support

MSDSS supports the users, groups, and containers object types for migration. The issue of migrating additional object types can be addressed as follows:

The only NDS (and bindery equivalent) object type that should be of concern is print services and computers. Microsoft does not ship any utilities that address the migration of print services (such as printer queues or printer machine objects). Additional object types such as the NDS Organizational Person and application objects have no direct equivalent in Active Directory and should be handled through scripted or manual migration procedures. In most cases is preferable to establish these manually in Active Directory due to the substantial differences in computer and printer object schema.

Reverse Synchronization

Both two-way synchronization and initial synchronization include the process of reverse synchronization. Because there is no method of querying NDS for changes, reverse synchronization must read all subject NDS objects and compare them to Active Directory for changes. At that point only the changed objects themselves are replicated.

While this process is not a major concern, it is much less efficient than forward synchronization. In the case where many objects are subject to the reverse synchronization process, it is advisable to schedule this process for non-peak server or network times.

Password Synchronization

Directory Synchronization allows for passwords stored in Active Directory to be read and altered for all Directory Synchronization session traffic. It does not, however, provide access to the encrypted passwords that are stored in an NDS or Bindery environment.

Keeping passwords synchronized should not be a problem, because any change in the Active Directory password is synchronized during the next synchronization session. The preferred method is to do password control from Active Directory. To do this however, the clients must be logging on to Active Directory.

Note: When using password synchronization, ensure that the security policies of the two directories do not conflict. For example, it would be a bad thing to require an NDS password change one day before Active Directory prompted the user for a change.

Third Party Migration Tools

Microsoft recognizes that many companies moving to Microsoft Windows 2000 Server operating system have planning and deployment requirements. To address these needs, Microsoft works with leading independent software vendors (ISVs) to deliver a wide range of accessory products and tools that speed migration to Windows 2000 Server and the Active Directory service.

For More Information

For the latest information on Windows 2000, check out our Web site at https://www.microsoft.com/windows2000.

For additional technical papers that compare the Windows 2000 operating system with Novell's NetWare, see the following Web site at:

https://www.microsoft.com/windows2000/techinfo/interop/netwareinterop.asp

Additional Web Site Resources

In addition to this paper and the tools and services described here, there are other white papers and technical papers that may be of use:

For an Active Directory Overview see: https://www.microsoft.com/windows2000/technologies/directory/default.asp

For an Active Directory walkthrough from an NDS Administrator's point of view see: https://www.microsoft.com/windows2000/

For an introduction to Windows 2000 Server see: https://www.microsoft.com/windows2000/techinfo/howitworks/default.asp

For Windows 2000 planning and deployment please see: https://www.microsoft.com/windows2000/techinfo/planning/default.asp

Summary

This release of the Windows 2000 Server operating system provides an unprecedented degree of support for interoperability between Windows 2000 and NetWare. Although Microsoft believes that the Windows 2000 Active Directory service is the superior solution, the realities of the many diverse IT system infrastructures require a great deal of flexibility in terms of the integration and coexistence of the two systems. Windows 2000 delivers several technologies and utilities that may be deployed to facilitate these requirements.

Central to most deployments is the Microsoft Directory Synchronization Service included with Windows 2000. This service provides the mechanism to connect and to synchronize NDS and Active Directory services with options to facilitate a number of migration or coexistence options.

Windows 2000 also includes updates to popular services that meet the needs of more complex solutions. Gateway Services for NetWare provides a single point of access to NetWare resources from Windows 2000. Client Services for NetWare continues to provide client access directly to NetWare bindery and NDS 4.x resources, and the inclusion of protocols such as LDAP and ADSI add functionality for integration between the two directories.

Appendix A: Removing NDS from a Novell Server

Always ensure that the servers are synchronized when you reconfigure NDS. All updates are time stamped to co-ordinate the update sequence and a server that is not synchronized will create problems. Use DSREPAIR.NLM to verify the Timesync State amongst the servers. A delta of two seconds is fine.

Backing up the File System = Phase 1

The file system will be intact after DS is removed from the server, but because you do not have a user database to authenticate users, your access to this file system is very limited. It is easy to reinstall NDS and get access again, but in the event of permanent removal of DS, it is better to backup. Modern backup systems normally back up the file system with the file system rights. You can easily restore it on another server in the same tree and still have the same rights. This is the preferred method for moving the content of an entire volume to another server.

NDS Aware Applications = Phase 2

Removing NDS is very destructive. The server will be removed from the NDS Tree and the procedure will impact some of the NDS-aware applications. If this server is the Tree CA and if this is a licensing server, then you have to decide either to use another server or to move the services to another computer.

The Tree CA cannot be moved without resigning all the certificates that use the new Tree CA. Any company using BorderManager or LDAP with SSL capability is making use of the Tree CA. The easiest solution is to leave the Tree CA for last.

By default, all servers are licensing servers. The best thing to do is to find out whether there are any licenses assigned to the server for specific use. A normal server and user license is not a problem. If there are any special licensing setups, assign all these licenses to a new server. Use NLSMGR32 in SYS:PUBLIC\WIN32, but authenticate to DS as the licensing supervisor. You will not be allowed to manage licenses if you don't own them.

Look at any other software on the server and don't overlook NDPS, DNS, and DHCP. The server might be a Broker or run a Gateway for the Novell printing system. You must be able to run the server as a file server with no other services before you can remove NDS.

Timesync = Phase 2

First verify the timesync configuration if you have more than one NDS server, because a lot depends on this mechanism. The timesync.cfg file in SYS:SYSTEM holds all the information you need. On a NetWare 5 server this file is automatically created and maintained, but on a NetWare 4 server you need to manually update it. To verify server version, type: VERSION in the server's command line. The first line tells you if it is a NetWare 4 or 5 server.

Once you have ascertained the version, you might need to update timesync.cfg. Type the following command in the server's command line:

SET Timesync Write Parameters = ON.

This will not work on a NetWare 5 server.

NetWare 4 and 5 servers always look in the server path for the files you would like edit. Therefore type:

LOAD Edit Timesync.cfg.

This command brings up the text editor and shows the content of timesync.cfg. You should see something like this on a version 5 server:

# Timesync.cfg is now updated automatically

# when changes are made on the System Console
# TIMESYNC Configuration Parameters
Configured Sources = OFF
Directory Tree Mode = ON
Hardware Clock = ON
Polling Count = 3
Polling Interval = 600
Service Advertising = ON
Synchronization Radius = 2000
Type = SINGLE
# TIMESYNC Configured time sources list

The first thing to look for is Type=. You always want to change the server type to SECONDARY if it is not the last server in the Tree. The last server will be a SINGLE. Read the section on Timesync to complete the procedure. After the server's time is stable again, you can continue to the next phase. Use DSREPAIR.NLM (second option on the main menu: Time synchronization) to verify if all servers are in synch. In very large environments this might take a while.

Remove All Master Replicas from the Server = Phase 4

During the removal of NDS, the server will try and change replica types for you. The process is more controlled if you do this one at a time before NDS removal. The easiest way to see which replicas are on a server is to use DSREPAIR.NLM. Use the Advanced options menu and go to Replica and partition operations. The server displays a list of replicas on the server and also indicates their types. If any Master replica is found, then select the replica in question and press RETURN. The first option on the next screen is View replica ring. Press RETURN again to see how many copies of that replica are available.

When this is the only server, you will only have one replica. If you know there are more servers and you only see one copy, you must place a replica on another server. Verify that all the Replica states are on after the replica has been added to another server, and then make the new copy the Master.

Note: Removing the Master replica means changing the Replica type of a Read/Write copy to Master. Do not use the delete options presented in DSREPAIR.NLM to destroy or delete a Master replica. Add a copy to another server and upgrade that to a Master. This automatically downgrades the current master to a Read/Write. See the section on changing Replica Type.

Read/Write Replicas on the Server = Phase 5

Removing NDS from a NetWare server takes care of replica placement, but you never want to end up using the automated procedure in large environments. It is better to remove all the replicas from the server before NDS is removed. Take care not to manually remove Secondary copies. They are maintained by the server and will be removed by NDS. Give NDS time to sort it out. If you do all operations from one workstation running NDSMGR32.EXE and the environment is not complex, then it is a very short procedure. Normally the only problem is the combination of large replicas and Transaction Tracking System (TTS). The older version of DS (older than version 8) use Novell's TTS and tends to bend the server. Set the Maximum Transactions for TTS to 5000. The default is 10000.

Removing NDS from the Server = Phase 6

After reviewing the preceding points, you are ready to remove NDS from the server in the NDS Tree. This is a straightforward procedure as long as you have network connectivity. Load INSTALL (NetWare 4) or NWCONFIG (NetWare 5) and go to Directory Options. The second line on the next screen is Remove Directory Services from this server. Follow the options on the screen and complete all steps. The server will be running after this, but there will be no directory service installed on it.

The two NLMs mentioned also have an override switch that allows you to do this without the Administrator password. Refrain from using this option, because it doesn't leave the NDS tree in a consistent state.

Appendix B: Windows 2000 Deployment in NetWare Environments

This appendix contains other scenario walkthroughs that may assist you in your migration endeavor, and highlight required tools, services, and implementation approaches and considerations. Each scenario is based on a Windows 2000 Server deployment in a NetWare environment based on the scenario roles the Windows 2000 Server is intended to play.

Scenario 1: Best of Breed

Active Directory includes many exciting new features that add value to any organization when deployed. Internet Services, Remote Access and application support are superior to those offered by NetWare. The best of breed scenario assumes that Active Directory will be deployed to plug the deficiencies of NetWare in these areas.

Solution

Fortunately, the Active Directory scales well in these types of situations. Active Directory can be easily deployed in a limited manner that seamlessly integrates with NetWare. The level of integration required by this type of deployment is strictly dependent on the reliance of application and routing and remote access services on Active Directory. In many cases, client modification will not be necessary unless direct interaction with Active Directory is desired. Deployment of the Internet Information Service can accommodate a wide range of authentication mechanisms that will work with the standard NetWare client.

Key Implementation Elements	Required?
Active Directory Design	Optional
DNS Deployment	Optional
Active Directory Deployment	Yes
Microsoft Networking on clients	Optional
MSDSS Installation	Yes
MSDSS Reverse Synchronization	Yes
MSDSS Two-way Synchronization	No
MSDSS One-way Synchronization	Yes
Gateway Services for NetWare	No
Resource Migration	No
FPNW Deployment	No

Scenario 2: Application Platform

Streetmarket, the fictional company introduced earlier in this paper, has a well-defined NDS environment but requires a more robust applications platform. Windows 2000 and Active Directory have been selected to host an enterprise resource planning (ERP) application and also to serve as the long-term corporate directory. Desktops consist of a mix of Windows 95, Windows 98, and Windows NT 4 workstations. Although the company plans to standardize all desktops on Windows 2000 Professional, planning for that migration will not begin until after the ERP application has been deployed.

Solution

Streetmarket has a couple issues that are easily dealt with:

Strong DNS services are required: NetWare does supply DNS services, but NetWare uses NDS for object name resolution and not DNS. Thus, services such as DNS dynamic update are rarely deployed. Migrating this service to Windows 2000 will have very little impact on the NDS environment bur significant benefit will be derived from the services being hosted by Windows 2000.

Cross Platform Authentication: The clients will no doubt be authenticating to NDS. The Active Directory-based application will natively expect Active Directory credentials. This means that Active Directory and NDS must maintain identical user account lists. MSDSS will be used to facilitate this requirement.

The solution is to deploy the necessary Windows 2000 infrastructure to support the application and its users. The infrastructure will be designed to support the eventual system wide migration.

Key Implementation Elements	Required?
Active Directory Design	Yes
DNS Deployment	Yes
Active Directory Deployment	Yes
Microsoft Networking on clients	Yes
MSDSS Installation	Yes
MSDSS Reverse Synchronization	Yes
MSDSS Two-way Synchronization	Optional
MSDSS One-way Synchronization	Optional
Gateway Services for NetWare	No
Resource Migration	No
FPNW Deployment	No

Scenario 3: Infrastructure

Windows 2000 supplies outstanding system infrastructure services, including advanced DNS services, robust DHCP and NetBIOS resolution using WINS. It is strategically advantageous to move any of these services to Active Directory.

Solution

Active Directory deployed for infrastructure services such as DNS and DHCP is one of the easier integrations with NDS. Cases such as this provide an excellent opportunity to deploy key Windows 2000 infrastructure components that not only provide services to almost any desired platform, but also establish an excellent foundation for Active Directory itself.

Deployment of infrastructure services requires detailed DNS namespace planning, and a skeleton deployment of the entire forest. Because no clients or additional services will initially be provided, only enough Windows 2000-based servers and domain controllers need be deployed to provide DHCP and DNS services. Figure 1 illustrates the integration of Windows 2000 DNS and DHCP in a NetWare environment.

Figure 1: Integrating Windows 2000 DNS and DHCP services

The advantage of this solution is that instead of storing client IP address mappings in NDS, DNS dynamic update and DHCP can be used together to properly register this information in Active Directory DNS. Fault tolerance is gained from the integration of the Active Directory DNS database into Active Directory itself. This solution is particularly useful for those organizations that wish to move from SLP to DNS for name resolution.

Clients gain all DHCP and DNS services from the Windows 2000 infrastructure. No functionality is lost in NetWare.

Key Implementation Elements	Required?
Active Directory Design	Optional
DNS Deployment	Yes
Active Directory Deployment	Optional
Microsoft Networking on clients	No
MSDSS Installation	Optional
MSDSS Reverse Synchronization	Optional
MSDSS Two-way Synchronization	No
MSDSS One-way Synchronization	Optional
Gateway Services for NetWare	No
Resource Migration	No
FPNW Deployment	No

Scenario 4: Upgrade

A typical scenario occurs when the company has an aging NetWare system that has reached the end of its useful life and needs to be upgraded. The options presented in this scenario are to upgrade to a later version of NetWare or to upgrade/migrate to Windows 2000. Because of the benefits provided by a migration to Windows 2000 and Active Directory, the company chooses to migrate as their strategic decision. The end objective is to retire all components of the NetWare environment.

Solution

The chosen timeline can be based on either a gradual or direct migration. In the case where a gradual migration is selected, the company has two primary options:

The migration may be performed based on the schedule of replacement of backend services (servers/software) or scheduled based on selected user and resource migration, which in turn would dictate the backend deployment. In either case, a minimum of additional hardware is needed because a close correlation to service mapping is used.
The legacy system is left intact while the Windows 2000 infrastructure is deployed. At the point when the Windows 2000 infrastructure is capable of receiving designated services, migrations begin.

Because this is such a common scenario, it may be helpful to further describe the methodology behind these options.

Gradual deployment and migrations are popular because of the low impact and low resource requirement. The basic strategy is to decide whether to replace components of the infrastructure based on the requirement to support users and resources being migrated, or to migrate users and resources based on their being hosted and/or dependent on a particular server. The strategy in either case will be centric, and the interdependencies of the system components must be determined.

User-Centric Approach: Deployments are often scheduled based on groups of users that will be migrated. This is a logical approach, it is the dependencies of the users that determine what servers and resources will be migrated. In the case of a migration from NetWare to Active Directory, it is more a matter of server placement, because any domain controller within a domain may act as a master for users. Specific server deployment is determined by a requirement to host resources or provide gateway services so clients are able to access resources still hosted on NetWare. A user-centric migration is illustrated in Figure 2 below.

Figure 2: User-centric migration

Server-Centric Approach: The server-centric approach assumes that the driving force behind the migration schedule is based on a requirement to move servers in a specific order. The result is similar to a user-centric approach except that during planning, users and resources are migrated according to their dependency on a particular server to be migrated. This differs from the user centric approach, in which it is the users being migrated that determines what servers will be moved. Figure 3 illustrates a server-centric migration approach.

Figure 3: Server-centric migration

Another facet of the migration is procedural. Will the deployment be conducted piecemeal: replacing a server from NDS with an equivalent Windows 2000-based service, or will the Windows 2000 service be deployed in parallel: Windows 2000 is deployed with no initial regard for the NetWare environment?

Piecemeal: A Windows 2000 Active Directory forest is functional after completion of the first server installation and promotion to domain controller. Although that statement oversimplifies the situation somewhat, little hardware is required to host a production operation. At this point, a staged migration of NDS servers may take place on a server-by-server basis. Often this type of migration will limit wide design deviations between the two systems because of the tight integration that takes place during the transition period.

Parallel: The parallel deployment methodology, which is illustrated in Figure 4 below, assumes zero tolerance to disruption of operations caused by the replacement of servers. Instead, the Active Directory is established as a completely separate and autonomous system. The Active Directory services are only flushed to the point that is required to host services. In many cases, this might consist of just three or four servers. The great advantage this has over a piecemeal deployment is the six degrees of freedom available in the design, considering that no dependencies exist to the legacy environment.

Figure 4: Parallel deployment of Active Directory and NDS

Key Implementation Elements	Required?
Active Directory Design	Yes
DNS Deployment	Yes
Active Directory Deployment	Yes
Microsoft Networking on clients	Yes
MSDSS Installation	Yes
MSDSS Reverse Synchronization	Yes
MSDSS Two-way Synchronization	No
MSDSS One-way Synchronization	Yes
Gateway Services for NetWare	Optional
Resource Migration	Yes
FPNW Deployment	No

Scenario 5: Remote Access

The routing and remote access features of Windows 2000 present a compelling case for deployment of Active Directory to host these resources. This scenario assumes that Windows 2000 and Active Directory are chosen to handle the connections between perimeter networks and the corporate office, with the possible expansion of Windows 2000 to other areas of network service.

A corporate remote access solution should provide authentication and security to the level that remote users can be treated as native participants in the corporate network. Windows 2000 is fully capable of providing this solution and can facilitate a number of authentication protocols, and advanced security features such as hosting VPNs that use Internet Protocol Security (IPSec), Layer 2 Tunneling Protocol (L2TP), and Point-to-Point Tunneling Protocol (PPTP).

Solution

Because the remote access solution relies on Active Directory, a synchronization of accounts as well as passwords must be performed to provide an effective solution.

Routing and Remote Access is an easy solution to deploy, because of the isolation of the service from core infrastructure services. Note that even this isolated service will be only one component of the Active Directory service after full migration, and must be planned to the point where namespace and logical placement in the forest are determined. Another critical component of this solution is the physical and logical placement of devices on the network.

As a general rule, it is a bad idea for the account database to be exposed to the Internet, and since any remote access solution should include the Internet as a medium, the placement of domain controllers is crucial. There should never be a direct path to a Windows 2000 domain controller from an insecure network. As such, RRAS-capable devices should be configured only as stand-alone servers that refer to Active Directory over a private network. The method by which this is accomplished is directly influenced by the physical location of devices that connect to the Internet. The number of suitable locations depends on corporate security policy, but options include:

Interior network: RRAS devices behind firewall.
DMZ: RRAS devices in isolated network, protected through firewall on either side.
Perimeter network: RRAS devices straddle Internet and interior networks.

Key Implementation Elements	Required?
Active Directory Design	Yes
DNS Deployment	Yes
Active Directory Deployment	Yes
Microsoft Networking on clients	Optional
MSDSS Installation	Yes
MSDSS Reverse Synchronization	Yes
MSDSS Two-way Synchronization	No
MSDSS One-way Synchronization	No
Gateway Services for NetWare	No
Resource Migration	No
FPNW Deployment	No

Scenario 6: Client Deployment

The Windows 2000 Professional operating system is a desirable upgrade path for desktops because of its stability, hardware support, and management features. To implement the full potential of Windows 2000 Professional, it needs to be integrated with Active Directory, because it is Active Directory that provides the management capabilities of IntelliMirror that were introduced earlier.

Often the deployment of the Windows 2000 client drives the migration of the infrastructure services.

Solution

There are several options for migrating clients from NetWare to native Microsoft Networking. Despite the use of TCP/IP by NetWare 5, most NetWare clients deployed today are still using IPX, or IP in IPX compatibility mode to access NetWare resources. The optimal solution for Windows 2000 client deployment is to deploy the client in its native mode without the installation of the NetWare client. To do this, the clients must authenticate to Active Directory, and heavily used resources such as file services should be hosted on Windows 2000-based servers at the time the client is migrated.

Subsequently, there will be periods of transition when clients will access resources across platforms. When Windows 2000 clients require access to NetWare based resources, Gateway Services for NetWare is used to facilitate communications. Conversely, when NetWare clients that have not yet been migrated require access to Windows 2000 based resources, File and Print Services 5 is implemented to allow native access to those clients.

Key Implementation Elements	Required?
Active Directory Design	Yes
DNS Deployment	Yes
Active Directory Deployment	Yes
MS Networking on clients	Yes
MSDSS Installation	Yes
MSDSS Reverse Synch	Yes
MSDSS Two-way Synch	No
MSDSS One-way Synch	Yes
Gateway Services for NetWare	Optional
Resource Migration	Yes
FPNW Deployment	Optional

Scenario 7: Hardware Refresh

Another common scenario for direct migration is to deploy Active Directory as part of a hardware refresh of the servers. This scenario normally manifests itself in companies that had concurrently deployed a large portion of the NetWare network. In those cases, a large percentage of the servers are subject to replacement in the same period. After deciding to deploy Windows 2000, the direct migration approach is used to achieve both a hardware refresh as well as a refresh of the back-end operating systems.

Solution

The replacement of the servers in this case will not necessarily coincide with client upgrades. Unfortunately, Windows 98 and earlier versions of the operating system and Windows NT clients that have had the NetWare client installed are in poor condition to perform authentication with Active Directory. Options in the case where clients are not configured to perform Windows Networking functions are:

Modify client stack: Modification of the client stack is not difficult in a managed environment. In an unmanaged environment, however, it may be more cost effective to simply upgrade the clients to Windows 2000. Microsoft Networking is installed on clients in any case.
Ignore Clients: Let desktops continue to use the NetWare environment until the client migration can be performed.

Key Implementation Elements	Required?
Active Directory Design	*Yes*
DNS Deployment	Yes
Active Directory Deployment	Yes
Microsoft Networking on clients	Optional
MSDSS Installation	Yes
MSDSS Reverse Synchronization	Yes
MSDSS Two-way Synchronization	No
MSDSS One-way Synchronization	Yes
Gateway Services for NetWare	Yes
Resource Migration	Yes
FPNW Deployment	Optional

03/00

NetWare to Windows 2000 Server Migration Planning Guide

On This Page

Introduction

Reasons to Migrate

Migration Path Choices

Deciding Which Systems and Services to Migrate

Migration Tools and Services

Connectivity Services

Services for NetWare (v.5)

What Can Be Migrated?

NetWare to Windows 2000 Migration

Planning the Migration

NetWare Inventory

Methodology

Gradual Migration

Long Term Management

Direct Migration

Transitional Management

Choosing a Path

Other Migration Issues

NDS for Windows NT

Bindery Migration

ZENworks

Steps to Migration

DNS Considerations

DHCP

Network Prerequisites

Authentication

Clients

Preparing to Install MSDSS

Migrate/Synchronize NDS to Active Directory

Migrate Files and Print Services

Migrating Files

Additional Operations

Supplementary Information

Object Support

Reverse Synchronization

Password Synchronization

Third Party Migration Tools

For More Information

Summary

Appendix A: Removing NDS from a Novell Server

Backing up the File System = Phase 1

NDS Aware Applications = Phase 2

Timesync = Phase 2

Remove All Master Replicas from the Server = Phase 4

Read/Write Replicas on the Server = Phase 5

Removing NDS from the Server = Phase 6

Appendix B: Windows 2000 Deployment in NetWare Environments

Scenario 1: Best of Breed

Additional resources