Migration Options

Updated: September 15, 2010

Applies To: Windows Server 2008 R2

Executive Summary

This topic discusses the migration strategy for a small to medium-sized organization from a Novell NetWare environment to a Microsoft Windows Windows Server 2008 R2 environment. Typically, this type of organization runs Novell NetWare and eDirectory for file and printer sharing with a standard operating environment (SOE) based on an older version of the Microsoft Windows operating system. The proposed migration strategy would take them to an environment running Windows Server 2008 R2 and Microsoft Active Directory with an SOE based on Windows 7. Next, the available interoperability options and migration strategies are discussed.

This topic presents the options and issues with migrating user accounts from eDirectory to Active Directory, and migrating shared file data from NetWare file servers to Windows Server 2008 R2 file servers. It also discusses the migration of shared printer queues, and concludes there is no way to automatically migrate print queues from NetWare servers to Windows Server 2008 R2 servers, but that it is possible for print queues on both types of servers to feed network attached printers.

Based on this analysis, the most appropriate migration strategy is a data-first, SOE-second approach. User accounts would be migrated first, followed by an interoperability solution using the Microsoft networking client. The shared file data would then be migrated, which allows the Windows 7 SOE to be deployed to computers.

This approach allows the migration to take place with minimal disruption to the users and the least load on support staff. It also represents the least risk to the organization, as there are plenty of opportunities to roll back individual shared file servers and individual workstations, and the deployment can proceed at a rate with which the organization is most comfortable.

Introduction

Any project that aims to replace Novell NetWare with a Microsoft Windows infrastructure must have a migration plan. This migration plan determines how the organization should move from the current environment to the proposed environment.

The current environment is generally characterized as follows:

• Novell eDirectory provides network authentication and authorization services. That is, eDirectory is the thing that users log in to every day, and which checks the credentials of users when they access files and printers.

• NetWare file and print servers provide shared data services and shared printer services. These services are secured using security principals held in eDirectory.

• Workstations run a version of the Microsoft Windows operating system and the Novell NetWare client. Many versions of the Windows operating system include a NetWare client, but organizations often deploy the NetWare client provided by Novell.

The proposed Microsoft Windows environment is usually characterized as follows:

• Microsoft Active Directory provides network authentication and authorization services. At the time of writing, the version of Active Directory that an organization would usually choose to deploy is Windows Server 2008 R2.

• Microsoft Windows file and print servers provide shared data services and shared printer services. These services are secured using security principals held in Active Directory. Again, an organization would choose to deploy Windows Server 2008 R2.

• Workstations run a version of the Microsoft Windows operating system with a Microsoft networking client. Organizations typically choose to deploy a brand-new SOE based on Windows 7 as part of the migration.

Migrating from one environment to another involves the following major tasks:

• Migrating user accounts and other security principals, including groups, from eDirectory to Active Directory.

• Migrating shared data from NetWare servers to Windows servers, and transforming NetWare security access control lists (ACLs) from eDirectory to Active Directory security ACLs.

• Replacing NetWare printer queues with Windows printers.

• Modifying or replacing the SOE.

These tasks do not necessarily need to take place in the order listed.

Purpose

The aim of this topic is to discuss possible migration strategies and list the advantages and disadvantages of different approaches to the migration process. The tools that can be used in the implementation of each migration strategy are noted and discussed in context.

User Account Migration

User accounts and groups (also known as security principals) from eDirectory cannot access files on a Windows file server, nor can security principals from Active Directory access files on a NetWare file server. Thus before any user can log in to Active Directory and access files on a Windows file server, security principals must be created in Active Directory that correspond to each of the security principals in eDirectory.

Two approaches exist to creating the security principals in Active Directory:

• Recreating the security principals, either manually or using a script

• Migrating the security principals from eDirectory to Active Directory using an automated tool

Recreating the security principals works best when:

• The number of security principals is small or

• The security principals are already stored in a list (such as an Excel spreadsheet)

Using an automated tool is most appropriate when:

• There is a large number of security principals and

• The definitive list of security principals is stored in eDirectory

In addition, automated tools normally generate a name mapping file, which can be used by a file migration tool to transform the ACLs on the files. The value of this feature is low if there is no requirement to transform the ACLs on files.

Often, there is a requirement to implement a new account and group naming convention as part of the migration. Most automated tools provide the ability to cater to this requirement in one of two ways:

• eDirectory accounts can be mapped to existing Active Directory accounts. This requires that a manual or scripted method be used to create the Active Directory accounts before the tool is used.

• The tool provides the ability to preview the Active Directory account before it is created and change the proposed name of the account.

As a migration strategy, it may make more sense to rename the account at a later time.

Note also that an eDirectory Organizational Unit (OU) can be used as a security principal on NetWare servers, but an Active Directory OU is not a security principal. Most automated tools address this by creating a group in Active Directory that corresponds to the eDirectory OU.

The automated tools that are available include (but are not limited to):

• Microsoft Services for NetWare (SFN) 5.03 SP2

• NDS Migrator by Quest Software

These tools are essentially the same; the differences between them are in the complexity of the user interface, the performance, and the ease of integration with other tools.

The migration strategy may require that the account migration tools be re-run several times to pick up any new or modified accounts in eDirectory until the migration is complete.

Recommended User Account Migration Strategy

Microsoft’s recommended strategy for migrating user accounts from Novell eDirectory to Microsoft Active Directory on Windows Server 2008 R2 involves the following process:

• Create a Windows Server 2008 R2 forest and domain with both at the Windows Server 2003 functional level

• Add a Windows Server 2003 R2 SP2 server as an additional domain controller within the Windows Server 2008 R2 forest

• Install the Novell Client 32 and Microsoft Services for NetWare (SFN) 5.03 SP2 on the Windows Server 2003 R2 SP2 server

• Follow the one-way migration instructions for migrating user accounts in the NetWare to Windows Server 2008 R2 Migration Planning Guide on the Microsoft web site at https://go.microsoft.com/fwlink/?LinkId=190426.

• Remove the Windows Server 2003 R2 SP2 domain controller

• Change the functional level of the forest and domain to Windows Server 2008 R2

SFN migrates the eDirectory information to the copy of Active Directory on the Windows Server 2003 R2 SP2 server. The accounts will be automatically replicated to the copy of Active Directory on the Windows Server 2008 R2 server.

File Migration

Migrating files from NetWare to Windows servers involves two main actions:

1. Transferring the file data from NetWare file servers to Windows file servers

2. Transforming the security ACLs on the files and directories from the eDirectory security principals to the Active Directory security principals

Transferring File Data

Transferring file data can be done at any time. In its simplest form, data can be transferred using an XCOPY command at a workstation that has both the NetWare client and the Microsoft Networking client installed and that can access both types of file server. Transferring the data ahead of time is a useful strategy since copying files can be time consuming. If this approach is used, the shared data would need to be kept up to date using a tool like ROBOCOPY to synchronize the shared data directories.

Transforming Security ACLs

Two approaches exist to transforming the ACLs on the files and directories:

• Setting the ACLs on the destination directories appropriately so that the files and directories will inherit the new ACLs

• Using an automated tool that consumes the name mapping file produced by an automated user migration tool

The first option is most appropriate when a fairly strict security configuration is already in place, or when the organization desires to implement a strict file system security convention.

The second option is most appropriate when the security configuration from the NetWare file system needs to be retained and the security configuration is not regular (for example, some files and directories have ACLs that differ from the parent directories). This option can only be used when a name-mapping file is available.

Transforming all of the ACLs depends on the availability of the user accounts in Active Directory. If the user accounts have not been migrated or created, then the ACLs cannot be transformed.

User Access to Files

Providing user access to the migrated file data on Windows file servers depends on two other tasks being complete:

• User accounts have been migrated or created in Active Directory

• Users are logging in to Active Directory

Users can be allowed to access the same shared file systems on both the NetWare and the Windows servers, but the network must perform a bi-directional file replication to synchronize the two file systems. This is a complex arrangement and will introduce difficulties with replication conflicts, so generally it is much safer and easier to prevent users from being able to access both file systems at the same time.

If the file data is transferred from NetWare to Windows with the aim of providing access to the data on the Windows server at a later time, then the security on the Windows server should be set to prevent unauthorized access to the data until the migration to Windows is complete.

After the migration to Windows is complete, users can be given access to the file data on the Windows system. Their access to the same file data on the NetWare servers needs to be revoked. While it is possible to change the security on the NetWare file system to prevent access to the data, doing so would ruin any possibility of rolling back to the NetWare servers. This is because, unlike Windows, NetWare does not have the concept of a shared directory; basically the whole volume is shared. Therefore, the most appropriate means of preventing access to the NetWare file system is to unmount the NetWare volume. This does, of course, mean that all of the file data on an entire volume needs to be migrated at the same time.

Recommended File Migration Strategy

Microsoft’s recommended strategy for migrating file data from Novell NetWare file servers to Windows Server 2008 R2 involves the following process:

• Create a Windows Server 2008 R2 forest and domain with both at the Windows Server 2003 functional level

• Add a Windows Server 2003 R2 SP2 server as an additional domain controller within the Windows Server 2008 R2 forest

• Install the Novell Client 32 and Microsoft Services for NetWare (SFN) 5.03 SP2 on the Windows Server 2003 R2 SP2 server

• Install the File Migration Utility that comes with SFN on the Windows Server 2003 R2 SP2 server

• To migrate files, follow the instructions in the NetWare to Windows Server 2008 R2 Migration Planning Guide on the Microsoft web site at https://go.microsoft.com/fwlink/?LinkId=190426.

• Remove the Windows Server 2003 R2 SP2 domain controller

• Change the functional level of the forest and domain to Windows Server 2008 R2

Printer Queues

Most organizations that run Novell NetWare servers use network attached printers, with printer queues hosted on the NetWare servers. Windows client users connect to these printer queues, and print jobs are spooled from the client to the print server and then on to the printer.

Unfortunately, there is no way to easily migrate printer queues from NetWare servers to Windows Server 2008 R2 servers. There are several reasons for this:

• Printers on Windows Server 2008 R2 servers use a virtual TCP/IP port to communicate with the print device. This is difficult to migrate from the NetWare server, particularly if the NetWare server uses IPX to communicate to the print device.

• Printers on Windows Server 2008 R2 servers require that the correct drivers be installed for the print device. NetWare printer queues do not have printer drivers associated with them, which makes it difficult to identify the correct driver for the print device.

• Once the printer is created on the Windows Server 2008 R2 print server, it is difficult to change the printer connections on the client computers. Typically the printer names do not have a simple mapping, and as part of connecting a Windows client computer to the new printer, the printer driver will be automatically installed (if necessary).

Fortunately, most network attached print devices can be sent print jobs from multiple print servers. That is, it is possible to send print jobs from both a NetWare print server and a Windows Server 2008 R2 print server.

This capability provides the ability to manually recreate the printer queues from the NetWare print servers on the Windows Server 2008 R2 print servers. After recreating the queues, the Windows client connections can be migrated to the printers on the Windows Server 2008 R2 print servers.

The client connections can be migrated in one of several ways:

• When the new Windows 7 SOE is deployed, the user can simply connect to their nearest print device using the standard method to find the print device (usually by searching for it in Active Directory).

• If the existing Windows systems have the ability to connect to the Windows Server 2008 R2 print servers, then the printer connections can be manually changed. This might be done by an administrator or by providing instructions to the users.

Because the new SOE will probably change the user’s customary logon procedure as well as the overall look and feel of the workstation, asking the user to reconnect to the printer is not unusual.

Client Operating System

Understanding how existing client operating systems access network resources is an important part of determining the best migration approach.

By default, most versions of the Windows operating system install the necessary features to log on to Windows Active Directory and to access resources on Windows servers. This networking stack is commonly referred to as the Microsoft networking client.

Organizations that run Novell NetWare and eDirectory also need to have the necessary features to log on to eDirectory and access resources on NetWare servers. This networking stack is called the NetWare client, and two main forms are available:

• The Novell version of the client, which comes with NetWare

• The Microsoft version of the client, called Client Service for NetWare (only available on Windows XP and earlier)

Most organizations that use eDirectory use the Novell version of the client.

Many organizations that run NetWare and eDirectory exclusively uninstall the Microsoft networking client from the Windows SOE, if it is available. If this is the case, then the interoperability options may be more difficult to implement.

If the Windows SOE includes both networking stacks, one of the two will be the primary account that the user logs onto, where they are authenticated by the primary network operating system. If the user account and password on the secondary network operating system are the same as the primary account credentials, the user will be automatically logged on to the secondary network operating system with no further interaction. Also, if the user changes their password, the password will be changed in both locations.

Novell provides a client for all major versions of the Windows desktop operating system. While some older versions of the Novell client exhibit problems when performing a dual-login and logging into Active Directory domains, using the most recent version of the Novell NetWare client will ensure the highest probability of a smooth transition.

Interoperability Solutions

The “transition period” is from when the users’ accounts and data are migrated to the Windows Server 2008 R2 environment until the time when the new Windows 7 SOE is deployed to the users. During this period additional interoperability may need to be provided so that users can access shared file resources on both NetWare servers and Windows Server 2008 R2 servers.

A number of options exist for providing this interoperability, including the ones listed next.

Microsoft Client on Existing Workstations

The most basic option uses the Microsoft networking client. This strategy allows data to be migrated immediately from the NetWare file servers to the Windows Server 2008 R2 file server because users can attach to both environments using the native protocols.

The disadvantages of this approach are:

• The Microsoft Client is not available on the new Windows 7 operating system, so this approach would only work if the new client SOE is Windows XP or earlier.

• Users are required to enter two sets of credentials. As noted above, however, the Novell client uses “pass through” authentication to log on to both environments if the user IDs and passwords are the same, making it possible for users to only enter their credentials once.

• Additional tools are required to maintain password synchronization between the old and new environments, and additional effort is required to run these tools. The effect of this is reduced if the deployment timeframe is short.

• The Microsoft networking client (and possibly a newer version of the Novell client) may need to be deployed to all existing Windows systems in the network. This deployment may cause considerable disruption and is a logistical exercise in its own right, particularly if the organization does not have a software deployment mechanism. Avoiding rework on existing Windows systems is generally the best approach for a migration plan.

NetWare Client Included in New Desktop SOE

A second option is to include the most recent Novell client in the new Windows 7 SOE. The Novell client would be removed after the new SOE is deployed. If a systems management tool is available, the organization could:

• Deploy the new workstations into the Active Directory

• Configure the Novell client to log on to both environments

• Wait until the desktop deployment is complete before migrating all shared file data from the NetWare servers

• Remove the Novell client by sending a systems management job to each client system

• Decommission the NetWare environment

The disadvantages of this option include:

• Removing the Novell client from Windows systems has traditionally been difficult. Also, SOE deployment best practices discourage deploying a piece of core system software and then removing it later.

• Users are required to enter two sets of credentials. However, the Novell client uses “pass through” authentication to log on to both environments if the user IDs and passwords are the same, making it possible for users to only enter their credentials once.

• Additional tools are required to maintain password synchronization between the old and new environments. The effect of this is reduced if the deployment timeframe is short.

SAMBA Services on NetWare Servers

It is possible to install SAMBA services on NetWare file servers. SAMBA lets Windows users who have matching eDirectory accounts access shares on NetWare servers using the native Microsoft Windows networking client. After authenticating to Windows, users can connect to and access files on NetWare file servers.

With this interoperability option, an organization could do the following:

• Install SAMBA on all NetWare file servers

• Share the NetWare volumes though SAMBA as Windows shared directories

• Replicate user accounts from eDirectory to Active Directory

• Deploy the Windows 7 SOE. At this stage, the Windows login script would connect users’ home drives and departmental drives to the SAMBA shared directories on the NetWare file servers

• Migrate shared file resources from the NetWare file server to Windows Server 2008 R2 file servers, and transform the security ACLs from NetWare to Windows

• Redirect users’ drive connections to the shared directories on the Windows Server 2008 R2 file servers

• Un-share the SAMBA shared directories

• Dismount the NetWare volumes

• Decommission the NetWare file servers and eDirectory

The disadvantages of this option include:

• Users are required to enter two sets of credentials unless their credentials are the same on eDirectory and Windows.

• Additional tools are required to maintain password synchronization between the old and new environments. The effect of this is reduced if the deployment timeframe is short.

• SAMBA would need to be deployed to the existing NetWare file servers, which may introduce reliability issues to the existing environment.

• Certain versions of SAMBA require that the default security configuration of Windows 7 be modified so passwords are transmitted across the network in clear text. This can be controlled through group policy, so this exposure would only exist during the transition phase.

Migration Strategies

At a conceptual level, three primary strategies exist for migrating from a Novell NetWare and eDirectory environment to a Windows Server 2008 R2 and Active Directory environment.

In all three strategies, two tasks must be completed before any other work is performed:

• The user accounts must be migrated from eDirectory to Active Directory

• New printer queues must be created on the Windows Server 2008 R2 print servers

All-At-Once Strategy

The first strategy is the all-at-once or big-bang strategy, where the shared file data is migrated from the NetWare file servers to the Windows Server 2008 R2 file servers. At the same time, the Windows 7 SOE is deployed to the desktop systems. A common use of this strategy is performing the migration over a weekend.

The benefit of this approach is that there are no interoperability issues. There is no need for the existing workstations to access files on the Windows Server 2008 R2 servers, or for the new Windows 7 SOE systems to access files on the NetWare file servers.

The problem with this approach is that it is an all or nothing approach. This increases the risk of disrupting business as usual because if any issues arise regarding access to applications or shared file data, they will affect all of the users at once. Also, it may not be physically possible to implement this approach if many users are located at remote sites or due to other logistical issues.

Data First, SOE Second Strategy

The second strategy is data first, SOE second. In this approach, the shared data is migrated from the NetWare file servers to the Windows Server 2008 R2 file servers. Access to the data is provided to existing Windows systems using one of the interoperability approaches described in the previous section. The Windows 7 SOE systems are then deployed without any ability to access data on NetWare file servers.

The benefit of this approach is that the data migration does not affect the configuration on the desktop, making it relatively easy to roll back to having users access the shared file data on the NetWare file servers. This approach reduced the risk of disruption to business. The Windows 7 SOE can be deployed to users at a rate that is acceptable to users and support staff. If any individual system fails to run an application (or has some other fault), it is relatively easy to re-install the previous SOE onto the computer.

The problem with this approach has to do with the interoperability approaches available. Neither is perfect, and may be difficult to implement:

• To use the Microsoft networking client on the existing workstations, it may be necessary to deploy the binary files and registry updates. If the organization does not have a software deployment mechanism, this may be difficult to achieve. Also, this approach involves changes to the existing systems, which may lead to reliability problems on the existing systems.

SOE First, Data Second Strategy

The third strategy is SOE first, data second. In this approach, the Windows 7 SOE is deployed to all users first. Access to data on the NetWare file servers is provided using one of the interoperability approaches described in the previous section. Once all of the systems have been deployed, the shared file data can be migrated from the NetWare file servers to the Windows Server 2008 R2 file servers.

As with the data first, SOE second strategy, the benefit of this approach is reduced risk. The Windows 7 SOE deployment can be performed at a rate which is acceptable to users and support staff alike, and any individual computer can be rolled back to the previous SOE. The data migration can also be easily rolled back.

This approach also has problems due to the interoperability options available:

• Including the NetWare client in the Windows 7 SOE means that it must be removed after the data migration has been completed. This may be difficult for an organization to achieve, especially if a systems management tool is not available to the organization.

• Implementing SAMBA may not provide a seamless authentication experience for the user. It also requires changes to the existing NetWare servers, which may lead to reliability issues.

The other problem associated with this approach is that the shared file data migration depends on deploying the Windows 7 SOE to all computer systems. If any one system cannot run Windows 7 for any reason (for example, the user has an application that does not run on Windows 7), then the data migration could be held up while the issue is resolved.

Conclusion

For most small to medium organizations, the most appropriate migration strategy is to perform a data first, SOE second migration. This approach provides the fastest migration to the Windows Server 2008 R2 infrastructure. It also avoids the risk of holding up the migration project if an individual computer cannot run Windows 7.

To facilitate this approach, the most appropriate interoperability approach for most organizations is to use the Microsoft networking client on the existing systems. If the Microsoft networking client is already installed on the existing systems, then this represents the simplest solution to interoperability.

A high-level migration plan using the data first, SOE second strategy with the Microsoft networking client as the interoperability solution would look similar to this:

1. Install the Windows Server 2008 R2 Active Directory, with a secondary Windows Server 2003 R2 domain controller.

2. Migrate user accounts from eDirectory to the Active Directory.

3. Deploy the Microsoft networking client (if necessary) and configure it so that users log onto both eDirectory and Active Directory.

4. Install the Windows Server 2008 R2 print servers and create the printer queues.

5. Install the Windows Server 2008 R2 file servers and migrate the shared file data.

6. Change the users’ logon scripts so that drive mappings connect to the Windows Server 2008 R2 file servers.

7. Unmount the data volumes on the NetWare servers.

8. Deploy the Windows 7 SOE to all computers in the organization.

9. Decommission the NetWare servers.

This basic plan would need to be fleshed out to include timing and procedures for migrations at multiple sites. Since visiting remote sites twice is usually not desirable, the data migration and Windows 7 SOE deployment could be performed as part of a single, multi-day visit, with the data migration happening before the Windows 7 SOE deployment.

Also, some remote sites might not have local file servers. The workstations at these sites should be upgraded after the data on all of the file servers has been migrated, unless the file servers used by those sites can be cataloged. Likewise, some users might access files on servers at other sites. Understanding these access issues will help determine the order in which workstations in remote sites should be deployed.