IT Infrastructure Analysis

  • Article

Updated: September 15, 2010

Applies To: Windows Server 2008 R2

When you plan how to implement a NetWare to Windows Server 2008 R2 migration, in addition to analyzing the organization from an information perspective, you must also analyze and document the network infrastructure. Analyzing the full IT infrastructure should help you to choose between a direct migration and a staged migration.

The IT infrastructure analysis assesses the current NetWare context, including details such as:

  • Local or wide area network links

  • The existing namespace design, including how objects and files are organized and managed

  • Existing hardware

  • Applications that require Novell

During this analysis, you must also determine the network design elements that you want to introduce or modify along with the introduction of Windows Server 2008 R2. These elements might include network traffic optimization, a different namespace design, a Windows Server 2008 R2 domain controller on which to install MSDSS, a workstation from which to remotely administer MSDSS, and Active Directory–enabled applications. The sections immediately below address the following IT infrastructure analysis issues:

  • Local area network (LAN) and wide area network (WAN) links

  • Namespace design issues

  • Workstations

  • Servers

The first IT infrastructure issue that affects how you decide to use MSDSS is whether you have a LAN or WAN. A small network typically consists of a LAN with no WAN links, one or two NetWare servers, and usually not more than 200 users. Medium-sized networks are characterized by the presence of WAN links. WAN links add complexity to the physical network. Additionally, in an NDS environment, WAN links affect how the NDS database is partitioned. See “Using Partitions and WAN Links” in the “Namespace Design Issues” section of this document for more information. In medium-sized networks, the user base is also typically larger, which can lead to longer migration times for the network.

The decision to use directory migration or coexistence can be influenced by many factors:

  • Migration. A LAN is easy to migrate from the server point of view because it can include only a few servers at one location. In a LAN environment, you can quickly install the Windows® 7 operating system on all the desktops using the Windows Server 2008 R2 Windows Deployment Services feature. In a WAN environment, when the goal is migration rather than ongoing coexistence, a period of temporary coexistence is probably required. MSDSS synchronization allows users to access both the new and the old systems while you perform the migration in stages. In a medium-sized organization, a period of coexistence of up to three months before a migration is complete is not uncommon. This is because you must allocate time for planning, training, implementation, and decommissioning NetWare.

  • Coexistence. Larger organizations might choose directory coexistence, rather than migration, as a long-term or permanent strategy. Even in a small network, the absence of WAN links and the small number of servers are not the only infrastructure issues to weigh. Migrating users, groups, and files is part of the equation. You must also take into account the necessity of maintaining user access to current services or, if necessary, replacing those services. For more information about this issue, see the “Workstations” section in this document.

Planning for Directory Synchronization Traffic

One factor to consider when you plan directory synchronization is how server locations affect network traffic. If Active Directory and NetWare information exists on servers in the same location, synchronization traffic is inexpensive. If the Active Directory and Novell servers are physically separated across a low bandwidth or non-persistent WAN connection, replication traffic is more expensive. In the latter case, consider locating both the MSDSS server and the NDS server within the same site or NDS partition.

You must also plan for any additional network bandwidth requirements that might arise from the introduction of periodic directory synchronization between Active Directory and NDS or Active Directory and Bindery. Although each environment is unique, it is important to understand that the following factors affect directory synchronization traffic:

  • Number of objects. The number of objects that are synchronized affects traffic.

  • Object size. The average object size affects traffic. The larger the object, the more information is transferred (particularly from NDS to Active Directory, which synchronizes whole objects, not just changed object attributes).

  • Number of changes. The average number of directory object and attribute additions, deletions, and modifications that occur between synchronization intervals affects traffic. The more changes that are made to each directory between synchronization sessions, the more synchronization traffic occurs.

  • Frequency of synchronization. By default, a session synchronizes Active Directory with NDS or Bindery every 15 minutes, and, if two-way synchronization is used, it synchronizes NDS with Active Directory every 24 hours. Frequency of synchronization does not have a large impact on forward synchronization (from Active Directory to NDS) regardless of how you set the synchronization interval. However, frequency of synchronization does increase bandwidth use for reverse synchronization (from NDS to Active Directory). In reverse synchronization, MSDSS reads all objects in the synchronized container (except those that are filtered), which increases traffic from the NDS computer to the MSDSS computer. After the object gets to the MSDSS computer, MSDSS checks it to see whether it has changed. If it has, then MSDSS writes it to Active Directory; if not, MSDSS just discards it.

  • One-way or two-way configuration. One-way synchronization configuration often results in substantially less synchronization traffic than two-way synchronization. This is because one-way synchronization (Active Directory to NDS or Active Directory to Bindery) is done at the attribute level—only those attribute values in Active Directory that have changed are synchronized with NDS. In two-way synchronization, the reverse synchronization process from NDS to Active Directory is done at the object level—the entire object is synchronized with Active Directory even if only a single NDS attribute has changed.

Keeping these factors in mind, use the following equation to estimate the aggregate impact of forward synchronization (Active Directory to NDS or Bindery) on network traffic:

ADST = N × AOS × XO × XA, where
ADST = average daily synchronization traffic
N = number of objects in NDS container or Bindery server
AOS = average size of objects in NDS container or Bindery server per day
XO = percentage of objects changed per day
XA = percentage of attributes changed per day

The amount of traffic for an individual forward synchronization session can be determined by using the forward synchronization formula with a time interval equal to the synchronization interval for variables XO and XA. For example, you could adjust the formula to reflect hourly traffic rather than daily traffic by changing ADST to AHST (average hourly synchronization traffic) and changing AOS, XO, and XA from “per day” to “per hour.”

Use the following equation to estimate the aggregate impact of reverse synchronization (NDS to Active Directory) on network traffic:

ADST = N × AOS × f, where
ADST = average daily synchronization traffic
N = number of objects in NDS container
AOS = average size of objects in NDS container per day
f = frequency of reverse synchronization every day

The amount of traffic for a reverse synchronization session can be determined by using the reverse synchronization formula for a time interval equal to the synchronization interval. You could, for example, adjust the formula to measure hourly rather than daily traffic.

Namespace Design Issues

The second IT infrastructure issue that you need to consider is namespace design. This section refers only to NDS, not Bindery. Because Bindery is a much simpler directory service than either NDS or Active Directory, namespace design issues are not relevant for a Bindery network.

The primary difference between the NDS and Active Directory namespaces is that Active Directory relies on the Domain Name System (DNS) for resource location. DNS is a hierarchical naming system that is used for locating domain names on the Internet and on private TCP/IP networks. The DNS service maps DNS domain names to IP addresses, and vice versa. However, NetWare uses its Service Location Protocol (SLP) as its main locator. Unlike DNS, which is the worldwide standard for mapping domain names to IP addresses, SLP is unique to Novell. Although the NDS and Active Directory namespaces are thus quite different at a technical level, MSDSS can synchronize directory objects between them.

You do not have to structure the Active Directory namespace identically to NDS for them to be synchronized by MSDSS. You do, however, have to plan whether you want the two namespace structures to differ, and if so, how.

The sections below cover the following namespace-related topics:

  • Working with naming conventions

  • Using partitions and WAN links

  • Understanding OUs, groups, and rights

  • Establishing a synchronization session at any container level

  • Custom mapping objects between different namespaces

A detailed discussion of NDS and Active Directory namespace design is beyond the scope of this paper. See the “Install Windows Server 2008 R2 Server Roles with Server Manager” section of the Install and Deploy Windows Server (https://go.microsoft.com/fwlink/?LinkId=194991) for more information. Also see the Novell Web site (https://go.microsoft.com/fwlink/?LinkId=194992) to find more information about NDS namespace design.

Working with Naming Conventions

When you design a namespace, you must understand how a given system handles user names. Most medium-sized organizations that use NDS use unique common names (CNs). This solves some tricky e-mail setup problems. However, in NDS, it is the distinguished name and not the common name that uniquely identifies the user. The common name for objects, including User objects, is the name that you specify when you create them. An example of a common name is Jack. An NDS distinguished name is a text string that uniquely identifies a directory object. An example of an NDS distinguished name is Jack.Sales.Msft.

The fact that many NDS-based organizations use unique common names but that in NDS the distinguished name uniquely identifies the user means that a user’s common name can appear in more than one OU. For example, Jack.Sales.Msft and Jack.Marketing.Msft are two different people. In Active Directory, the user’s account name must be unique per domain. Therefore, in Windows Server 2008 R2, you would have to create the two “Jacks” with different account names if they both belong to the same domain.

If both example user objects are synchronized from NDS to the same Active Directory domain, MSDSS creates the first user (Jack.Sales.Msft) as Jack and the second one (Jack.Marketing.Msft) as Jack0. Notice the logon name (account name) change. You can ensure that the logon names stay the same in two ways:

  • Change NDS logon names. Change all logon names to be unique before you use MSDSS to synchronize or migrate networks. The user should become familiar with the new name and should find migrating to Windows Server 2008 R2 easier.

  • Use more than one Active Directory domain. Synchronize or migrate the NDS structure to different Active Directory domains. You might decide to have a marketing domain and a sales domain. Both “Jacks” can then exist in Active Directory as Jack.

When you decide whether or not to create an Active Directory namespace that duplicates the NDS namespace, it is important to understand differences in the number of partitions required by NDS as compared with Active Directory. The more partitions you use, the higher the administrative costs. It is highly likely that you will need far fewer Active Directory domains than NDS partitions. This is primarily because Active Directory replicates data over WANs more efficiently than does NDS, which tends to use partitions to reflect geographical divisions.

For example, for a U.S.-based organization, NDS typically requires a separate partition for the Los Angeles site, the Chicago site, and the New York site because they use WAN connections to bridge these sites. However, for the same organization, Active Directory would typically be deployed as a single partition (Active Directory domain) with replicas of the same data in each city. This is because Active Directory automatically compresses data that flows across a WAN, automatically uses bridgehead servers to eliminate duplicate traffic, and supports traffic scheduling. NDS does not compress data, requires complex manual configuration on each replica server to simulate bridge heading, and does not make scheduled replication possible. Therefore, although NDS administrators ordinarily do not implement single partitions that span WAN connections, Active Directory administrators can do this.

Because most NDS implementations follow a geographic model while Active Directory has no such constraint, in most cases the optimal Active Directory namespace design differs from the existing NDS namespace design. Take this advantage of Active Directory into consideration when creating an MSDSS plan.

Understanding OUs, Groups, and Rights

Both NDS and Active Directory use OUs, but they have important functional differences. One major difference is the role that OUs play—or do not play—in security.

  • NDS OUs. In NDS, you use an OU for partitioning and for security. An NDS OU is a security principal that can be associated with a network resource (such as a file). A user who is a member of an NDS OU is automatically granted access rights to any resource that lists the OU as an entity permitted to have those rights. For example, everyone who is a member of the Marketing OU—from the group assistant to the product manager—can access a file that has the Marketing OU listed in its access control list (ACL).

  • Active Directory OUs and Security Groups. By contrast, you use Active Directory OUs for delegation of administration and for applying group policy, but they are not security principals. In the Windows Server 2008 R2 operating system, Active Directory user and computer accounts and groups are security principals. The security group, not the OU, is the Active Directory mechanism for granting access rights to resources to a collection of users. When you use security groups, access to resources is always granted explicitly and is unaffected by users moving between OUs. The benefit of Active Directory group-based (rather than NDS OU-based) security is that Active Directory makes organizational restructuring easier—administrators do not have to reset security permissions every time changes are made to the organizational hierarchy.

When you plan how to use MSDSS, consider how Active Directory namespace design features differ from NDS namespace design capabilities. These differences can affect your decision whether to duplicate the NDS namespace or to create a different Active Directory namespace. Often, when an NDS namespace uses separate partitions, you can install Active Directory as a single domain with multiple OUs to simplify administration. OUs in both directories group people together to ease administration. It is therefore easy to map an object that is in one area of one directory to an object that is in a differently named area of the other directory.

For a step-by-step demonstration of migrating an NDS container and its contents to an Active Directory container, see the “Directly Migrating NetWare 4.x, 5.x, or 6.x NDS” section of this document.

For more information about Active Directory OUs and security groups, see the “Related Links section of this document.

Establishing Synchronization Session at Any Container Level

When you configure a synchronization session, you can choose to root the synchronization session at any container level in the directory hierarchy. For example, the tree structure might have one root container with four sub-containers. You can choose to have a single session rooted at the root level, or you can choose to have four sessions, one for each sub-container. When you decide what to do in a particular environment, ask yourself if you want to apply the same set of synchronization parameters for all objects and sub-containers. If yes, you should root the synchronization session at the highest level possible in the tree, subject to the constraint described earlier. If no, synchronize at the container level at which you want to apply a common set of synchronization parameters (such as frequency of synchronization, one-way or two-way synchronization, and objects that are filtered).

Custom Mapping Objects Between Different Namespaces

If you perform a one-time migration from NDS or Bindery to Active Directory, MSDSS creates an Active Directory namespace that duplicates and replaces the NDS or Bindery structure. However, with Active Directory-to-NDS synchronization (either one-way or two-way), you have the option to use custom object mapping to synchronize objects when the Active Directory namespace differs from the NDS namespace. These options are:

  • Modify existing NDS namespace and/or create new Active Directory namespace. You cannot create Active Directory OUs and NDS containers while you are running the MSDSS Synchronization Wizard. Therefore, before you initiate synchronization, use NetWare administrative tools to create any new NDS containers you might want, and use the Windows Server 2008 R2 Active Directory Users and Computers snap-in to create Windows Server 2008 R2 Active Directory OUs.

  • Map relationship between specific objects. If you have created an Active Directory namespace that is not identical to the NDS namespace, you can use the MSDSS custom object-mapping feature to map objects between the two different namespaces. When the MSDSS Synchronization Wizard displays the Object Mapping Scheme page, specify the Active Directory and NDS objects between which you want to establish a one-to-one relationship independent of the object locations in either directory tree. For example, in NDS an OU called Sales contains five user accounts, as follows:

    OU=Sales
CN=Joe
CN=Tom
CN=Jody
CN=Mike
CN=Cathy

    You want to move over only the first three users. Therefore, you custom object map Joe, Tom, and Jody, synchronizing these three objects with the corresponding objects in Active Directory OU, which does not have to be named Sales.

Workstations

The third IT infrastructure issue that influences how you decide to implement MSDSS is how workstations are set up. You obtain the fullest benefit of Active Directory for a workstation only when you migrate it to the Windows® XP Professional operating system. This is true for earlier versions of Windows-based workstations installed in a NetWare environment and for other Novell client workstations.

However, NetWare networks typically have networking components and application software running on their workstations that are integrated with NDS (or, less often, with Bindery). Therefore, if a computer is running a service that requires NDS (or Bindery), you must consider replacing that service. Replacing existing directory-enabled services or applications with new Active Directory–enabled software is a project that you should perform independently of the MSDSS migration of NetWare users, groups, distribution lists, OUs, and organizations, and the File Migration Utility migration of files.

If you do choose to migrate all services, another factor is the size of your organization. The larger your environment, the more complex the secondary migration projects will be, and the more time you will need.

If you choose to retain the operating system software that is already in place on your workstations and all or some of the NDS-integrated components on those workstations, you can use MSDSS to synchronize the two directory services. MSDSS gives you the option of maintaining a mixed network in which Active Directory and NDS coexist.

When you decide which strategy is appropriate for your environment, consider the workstation-related topics discussed in the following sections:

  • Novell NetWare Client for Windows (Client32)

  • Microsoft® Client Services for NetWare

  • Microsoft® Client for Microsoft® Networks

  • Printing considerations

  • Novell Workstation Manager

  • ZENworks

  • BorderManager

Novell NetWare Client for Windows

In NetWare environments, most Windows-based workstations can use Novell NetWare Client for Windows (also called Novell Client or Client32) to access NDS. (For software included with Windows that can also provide NDS access, see the next section, “Microsoft Client Services for NetWare.”) Novell NetWare Client for Windows software makes it possible for Windows-based client computers to use file, print, and other services that are available on NetWare servers.

The following are important to keep in mind regarding Novell NetWare Client for Windows in relation to MSDSS synchronization or migration:

  • Synchronization. In a synchronized environment where Active Directory forms the core directory, you might be able to restrict the use of Novell NetWare Client for Windows and use it on only a limited number of workstations. Novell NetWare Client for Windows software is required on workstations in a synchronized environment if any of the following are true:

    • You want to use the workstation to administer an MSDSS session from a remote computer.

    • You want to use the workstation to administer NDS partition and replication configurations with NDS Manager, or if you want to perform any NWAdmin/Console1 operations.

    • You need to authenticate into an NDS network to access or use NDS-enabled applications.

  • Staged migration. If you choose to perform a staged migration from NetWare to Windows Server 2008 R2, you might want to have Novell NetWare Client for Windows deployed on client workstations during the migration period, and then remove it when the migration is completed. This makes it possible for clients to use both Windows Server 2008 R2 Kerberos and NetWare Core Protocol (NCP) authentication.

Microsoft Client Services for NetWare

Windows-based workstations in NetWare environments can use Client Services for NetWare (CSNW), which is included with Windows-based workstation operating systems, to gain access to NDS. CSNW is sometimes used for this purpose as an alternative to Novell NetWare Client for Windows. CSNW provides access to NetWare 5.x and earlier environments using the IPX/SPX protocol. After you complete a migration and decommission NetWare, you can uninstall CSNW.

Microsoft Client for Microsoft Networks

Most desktops running Windows in a NetWare environment already have the Microsoft Client for Microsoft Networks installed. On these computers, when Windows installed the network card, it also installed and configured Microsoft Client for Microsoft Networks, which is redirector software that intercepts client (workstation) requests for files and printers and routes them to the appropriate remote device, such as a network server, another workstation, a printer, or a directory share.

Note

Do not uninstall the Microsoft Client for Microsoft Networks software after a migration.

Printing Considerations

Microsoft File and Print Services for NetWare (FPNW) 5.02 is part of Microsoft Services for NetWare (SFN) 5.03 SP2. It is installed on a Windows Server® 2003 R2 SP2 file server and makes the server appear as a NetWare 3.x file server (operating in “Bindery” mode). Users logging onto client workstations using the Novell client can attach to these servers using native NetWare protocols. However, these servers do not participate in the eDirectory environment. Instead the security principals used are the Active Directory accounts, so in effect the user would connect to the FPNW server using their Active Directory account.

Since the recommended Microsoft migration pathway from NetWare to Windows Server 2008 R2 involves using a server running Windows Server 2003 R2 SP2, an organization could install FPNW on the server running Windows 2003 R2 SP2 and then use that environment as a temporary interoperability solution.

Novell Workstation Manager

Novell Workstation Manager is a snap-in for Novell NetWare Administrator that you can use to administer both NDS and Windows accounts from one administrative point. If you migrate to Active Directory, or if you use one-way synchronization and use Active Directory to manage all user objects, you should uninstall this component.

ZENworks

Older versions of Novell desktop management suite, ZENworks, are integrated with NDS and require Novell NetWare Client for Windows. Fully deployed ZENworks environments are uncommon. If an organization does use ZENworks, you must decide between two options:

  • Migrate from ZENworks. A complete migration from NDS to Active Directory also requires moving to Microsoft desktop management services. Windows Server 2008 R2 includes built-in desktop management features, such as remote operating-system installation, application distribution, data and settings mirroring, and industry-standard management instrumentation (Windows® Management Instrumentation [WMI]), each of which can be used by Windows Server 2008 R2 management tools. If you want additional desktop management solutions (or solutions that can run on a mixed network), you can purchase Microsoft® System Center Configuration Manager 2007 R2, which can manage Windows-based client workstations in a Windows 2000 SP4 and later environment and Windows-based servers that are in a Windows Server® 2003 SP1 and later environment or an NDS-based Novell NetWare environment, regardless of the directory service in use. Also note that there are third-party tools that can be used to migrate users from ZENworks. Windows Server 2008 R2 policies can also assist greatly in desktop management scenarios.

  • Keep ZENworks by synchronizing. If you choose to continue to use ZENworks, understand that because it is NDS-integrated and needs Novell NetWare Client for Windows, it places an additional resource requirement on the desktop.

If you do migrate from ZENworks to Microsoft desktop management, you can then also easily migrate Dynamic Host Configuration Protocol (DHCP) services from NetWare to Windows Server 2008 R2. In NetWare, the DHCP networking protocol dynamically registers the client workstation’s IP address in the NDS database with the associated computer name. Similarly, in Windows Server 2008 R2, DHCP provides dynamic configuration of IP addresses for computers, ensuring that address conflicts do not occur. Because Windows Server 2008 R2 DHCP is integrated with the Windows Server 2008 R2 implementation of DNS (which is itself a central component of Active Directory), consider migrating both of these primary network services.

BorderManager

Novell BorderManager is another major NDS-integrated application to consider when you choose between synchronization and migration. If your environment currently uses BorderManager to manage and protect your intranet and Internet borders, it is likely that your long-term plan includes the replacement of BorderManager with Microsoft® Internet Security and Acceleration Server. If replacing your proxy systems is not in your budget, implementing directory synchronization makes it possible for you to use BorderManager as your proxy server until such replacement is desired.

Servers

The fourth IT infrastructure issue that you need to consider when you decide how to use MSDSS is how to handle servers. If you choose to implement MSDSS synchronization, you need one or more servers running Windows Server 2008 R2 in addition to the existing NetWare (or other) servers, depending on the size and structure of your network. If you choose to perform a complete migration, after the migration you will have replaced all NetWare servers with Windows Server 2008 R2 servers. The following sections describe what you need to know about servers when you plan to deploy MSDSS.

Windows Server 2008 R2 MSDSS Domain Controller

To implement MSDSS, you must install the Windows Server 2008 R2 operating system and the MSDSS software on at least one server. When you install Active Directory on a server running Windows Server 2008 R2, it becomes a domain controller. You use this domain controller to configure Active Directory, to install MSDSS, and then to import information from your existing NetWare environment.

The larger your environment, the more new servers you need. If you are planning to have more than one domain, you need new hardware for the first domain controller in each domain.

Using MSDSS to import the NetWare information into Active Directory saves the administrative overhead that you would otherwise expend in creating new users and groups on the new Windows Server 2008 R2 domain controller.

You must also install Novell NetWare Client for Windows software on the MSDSS server or servers. MSDSS uses Novell NetWare Client for Windows to authenticate and to gain access to NDS. While accessing NDS, MSDSS authenticates, but it does not use a license. MSDSS also uses Novell NetWare Client for Windows to map one directory’s contents to another, accounting for the fact that the object classes in Novell NDS or Bindery directories are different from Active Directory object classes. Novell NetWare Client for Windows is also required to use File Migration Utility to migrate files.

You can install Novell NetWare Client for Windows in four modes: IP only, IPX only, IP and IPX combined, and IP with IPX Compatibility Mode. A significant number of NetWare environments still use IPX today. MSDSS works in all these modes because it uses Novell NetWare Client for Windows to access the lower layers.

If you are migrating NDS, you can import the user and group information from one NDS server to the MSDSS server because you have one user database per tree. You can then migrate the file system. Remember that each Novell server has its own file system, which is not replicated to other servers (this contrasts with NDS, where the directory is replicated to other servers). After the files are migrated, you can uninstall NDS from the server to free the hardware for the Windows Server 2008 R2 operating system.

Non-MSDSS Windows Server 2008 R2–based Servers

An Active Directory forest can have multiple trees with multiple servers. All the servers in one forest belong to one directory and need only the standard Microsoft client portion of the Windows Server 2008 R2 operating system. When you plan to implement MSDSS, keep the following points about non-MSDSS Windows Server 2008 R2–based servers in mind:

  • Remote MSDSS administration. If you install MSDSS on a non-domain controller server or on a Windows-based workstation, only the MSDSS console is installed (installing MSDSS on a Windows Server 2008 R2 domain controller installs both MSDSS itself and the MSDSS console). You must also install Novell NetWare Client for Windows on this computer. The console makes it possible for you to view MSDSS sessions. Novell NetWare Client for Windows makes it possible for you to remotely access a domain controller running MSDSS and thus perform all MSDSS administration tasks.

  • File and Print Services for NetWare. During a staged migration, you can offer file and print services that are available on a Windows Server 2008 R2–based server to NetWare clients by installing File and Print Services for NetWare (FPNW) on the server running Windows Server 2008 R2. FPNW is available on the same Services for NetWare Web site that contains MSDSS and File Migration Utility.

  • NetWare servers. To complete a migration, the final task is to decommission the NetWare servers. If the hardware can be used as a server or workstation install Windows Server 2008 R2 or Windows 7 respectively.