Chapter 3: Planning Your Novell to Windows Migration Project

  • Article
On This Page

Introduction and Goals Introduction and Goals
Evaluating the Existing Environment Evaluating the Existing Environment
Developing the Solution Design and Architecture Developing the Solution Design and Architecture
Migration Planning Migration Planning
Creating the Functional Specification Creating the Functional Specification
Developing the Project Schedule Developing the Project Schedule
Test Planning Test Planning

Introduction and Goals

The Planning Phase of a project is the time when the initial vision is translated into practical plans for how to achieve it. Most of the activity during the Planning Phase involves making decisions and documenting them. The full project team should be engaged at this point. Readers should consult the UMPG for guidance on organizing the team and processes to accomplish the work of the Planning Phase.

The focus of the Planning Phase, the second phase of the migration planning methodology, is on further understanding the existing environment, developing the details of the right solution (selecting a migration strategy and process), establishing a schedule for the migration, and finally building a lab to test the migration.

The information provided in this section will guide you on the considerations to keep in mind as you make decisions. For example, designing the physical architecture is partially determined by the amount of performance that is needed, as well as other production and operational requirements.

Major Tasks and Deliverables

The following set of deliverables and activities will need to be completed during this phase. This work may involve several iterations of each deliverable, because they represent the documentation of some complex decisions that must take several technical factors and organizational needs into consideration.

  • The functional specifications document, which summarizes the key decisions made during the planning process, should include:

    • Key design goals

    • Summary of the existing environment

    • Scope summary

    • Background information that places the solution in a business context

    • The solution design and architecture, from the conceptual, logical, and physical points of view

    • Features and services that define the functionality of the solution

    • Component specifications that define the products that will be used to deliver required features and services

    • Dependencies on other projects or resources outside the project team's control

  • The master project plan and schedule, which describes when each piece of the work will be done and shows how the work will be coordinated, taking dependencies into account.

  • An updated risk assessment with management plans for top risks.

Planning Phase Major Milestone: Project Plans Approved

The phase concludes when the project team agrees that the plans are sufficiently well-defined to proceed with development and testing, and the team, business sponsor, and key stakeholders approve the design and the master project plan and schedule, usually at a milestone meeting. The formal conclusion is marked by the second major project milestone, Project Plans Approved.

Evaluating the Existing Environment

It is critical to fully understand the current environment before designing the environment to which you plan to upgrade. Allow time in the Planning Phase to continue the assessment work that you did in the Envisioning Phase by collecting more detailed information about the existing environment and evaluating that information to determine the appropriate next steps.

The evaluation process can shed light on constraints to the implementation process that weren't considered previously, such as time restrictions that would affect the window of opportunity for change. These restrictions can include seasonal businesses, company budgeting cycles, or even vacation schedules.

Ultimately, while the amount of time spent in the assessment and evaluation process will vary greatly, the goals are the same: to understand the technology infrastructure in place and the risks involved in the project to limit the surprises that may occur during the Migrating and Deploying phases.

In preparation for development of the functional specifications document, the following assessment tasks should be performed:

  • Diagram the network including hardware and software. Create a diagram of the NetWare network and all of its components. Identify which servers are file and print servers, Web servers, mail servers, and database servers. Thoroughly document all servers, including NetWare versions, transport protocols, NDS partitioning, and directory versions (Bindery or NDS).

  • Document any printers that need to be replaced. Check printers to ensure that they can be printed to using protocols other than IPX (ideally TCP/IP). Include any printers that need to be replaced in budget and timeline estimates.

  • Identify all types of information stored on the network. Identify all types of information stored on the NetWare network (not just NDS or Bindery information), where it is stored, who is responsible for which information, which subsets of users have access to which data, and what the associated security requirements are.

  • Identify all Novell-dependent software. Among the software in the diagram, identify all software that is dependent on Novell.

  • Review WAN/LAN links, and their available bandwidth. Determine the available bandwidth for WAN and LAN links. This will help you decide how you can effectively design the Active Directory topology in respect to the current Novell portioning on the existing network.

  • Analyze the current namespace design. Familiarize yourself with the current Novell namespace design.

  • Review user environment components involved in the migration. Review user environment components, primarily login scripts and group/system policies.

  • Perform a directory health check. Go through the Novell NDS or eDirectory to determine if the directory is working properly. In addition, if there is already an Active Directory infrastructure in place, verify that it is working properly. The health check ensures that the objects scheduled for migration are appropriate and that they can be migrated to the new environment.

    There are a number of different ways to perform an eDirectory health check. Step-by-step procedures for verifying the DS versions, time synchronization using DSREPAIR, and making sure that all of the servers are in sync, using DSTRACE to verify that the servers have replicated properly, can be found in the Novell white paper TID #10012858.

    Additional tests covered in the Novell white paper that may be useful include:

    • Replica Synchronization (DSREPAIR)

    • External References (DSREPAIR). Make sure that the external references are updated. There are references to several other white papers that discuss tools you can use based on whether you are using NetWare 5.1 or 4.x

    • Replica State (DSREPAIR)

    • Remote Server IDs (DSREPAIR)

    • Replica Ring (DSREPAIR)

    • Schema (DSTRACE). Turn off DSTRACE and then you are ready to conduct the migration process.

    • Repair local database (DSREPAIR)

    • Back up the database (DSREPAIR)

Note: During migration planning, should you decide to use the third-party tool, Quest NDS Migrator, the assessment process can be enhanced with the NDS Quest Reporter tool. Migration tool selection is covered in the "Migration Process" section of this chapter. For additional information regarding NDS Quest Reporter, see the "Bibliography/References" section in Appendix A.

After you have finished the assessment and evaluation tasks, do the following:

  • Decide how to handle Novell-dependent software. Before the migration begins, decide whether you will replace all Bindery-, NDS-, or NLM-dependent software (such as NDS-compliant DNS, DHCP, ZENworks, etc.) with Active Directory-compatible software (leading to a direct migration, or whether you want to continue to use some or all of the Bindery- or NDS-integrated services or applications (leading to a phased migration). Be sure to include the e-mail system in this list.

  • Determine the systems to be migrated. Determine which systems will be migrated or decommissioned. Determine the affected users, groups, objects, folders, files, databases, and e-mail systems (GroupWise or others).

  • Plan for future hardware, software, and network bandwidth needs. Research what additional functionality your organization plans to implement in the future. Factor these features into your migration planning (for example, when you plan namespace design, WAN links, application software needs, etc.).

  • Analyze future namespace design. Familiarize yourself with Active Directory namespace design principles and consider future namespace design. Refer to the current Novell namespace design.

Developing the Solution Design and Architecture

Creating the solution design and architecture involves a systematic progression from abstract concepts to specific technical detail. Designing can be divided into three sequential but overlapping steps, which represent three ways of describing the solution.

  • Conceptual design, which analyzes and prioritizes businesses, user, system, and operational requirements and describes in nontechnical language how the solution will meet them.

  • Logical design, which describes the solution in terms of the organization, structure, and interaction of its parts in technical language.

  • Physical design, which identifies the detailed instantiation of the solution which will be built, for example software architecture, communication protocols, physical infrastructure architecture, and topology.

This section will provide you with an overview of the areas you should focus on when designing your new Windows environment. For detailed information on designing a Windows Server 2003 Active Directory environment, see Windows Server 2003 Deployment Kit: Designing and Deploying Directory and Security Services https://www.microsoft.com/downloads/details.aspx?FamilyID=6CDE6EE7-5DF1-4394-92ED-2147C3A9EBBE&displaylang=en#filelist. Before reading this document, you may want to familiarize yourself with Windows Server terminology, because some key concepts like organizational unit are used differently than in the Novell context.

As previously stated, the focus of this guide is to provide you with information on how to migrate your existing Novell environment to Windows. However, before you can migrate to a new Windows environment, you must first determine what that environment will look like. Proper design of your new Windows Server 2003 Active Directory structure is a critical component in the successful deployment of the technology. Mistakes made in the planning portion of Active Directory can prove to be costly and difficult to correct. In the planning process you and your team should determine what the new environment will look like (the design) and how you will get there (the migration plan). Use the information that follows to help the team make the necessary decisions.

Areas of Focus for the Solution Design

There are a number of Microsoft documents that detail the process of designing a Windows Server 2003 Active Directory. The purpose of this section is to identify the key areas that you need to consider before migrating from a Novell environment to Windows Server 2003 Active Directory.

Windows Server 2003 Design

Determine the software version and the hardware configuration that will be used. In addition, before deploying the servers in a test environment, consider the use of third-party applications to protect data on the servers and make appropriate decisions. The design of the system and the servers should take into account any data protection software (backup, antivirus, etc.) that you decide to use.

Active Directory Design

Active Directory is a necessary and fundamental component of any Windows Server 2003 implementation. You can use built-in tools to set up Active Directory, in addition to Windows Server 2003, as long as you consider a few straightforward design parameters before deployment:

Architecture

  • Forest and Domain Design. Determine the Forest and Domain Model. Options include a Single Forest/Single Domain Model, a Single Forest/Multiple Domain Model, a Multiple Forest Model, or a combination environment.

  • Functional Levels in Windows Server 2003 Active Directory. Determine the Windows functionality that will be required. This decision is based on the needs of your organization, such as whether or not you have Windows 2000 or Windows NT4 domain controller and whether there is a requirement to retain Windows NT4 domain controllers.

  • Namespace. Will there be any Namespace issues? When shares are migrated from a source server to the target server, the UNC paths of the migrated files are changed. This may affect any application or user that references the UNC path, for example application links, logon scripts, network places, and shortcuts. Applications and users generally reference files in one of the following ways:

    • Mapped drive letters

    • UNC paths

    • DFS

Networking Services

Windows Server 2003 introduces several functional improvements to network services. These improvements allow for increased administrative functionality, greater reliability, and an overall increase in value for an organization’s network infrastructure.

  • DNS. The first step in the actual design of the Active Directory structure is deciding on a common Domain Name System (DNS) namespace that Active Directory will occupy. Active Directory revolves around and is inseparable from DNS, as such, this decision is one of the most important ones to make. The namespace chosen can be as straightforward as microsoft.com, for example, or it can be more complex. Before you can make this decision, you need to consider multiple factors. Is it better to register an Active Directory namespace on the Internet and potentially expose it to intruders, or is it better to choose an unregistered internal namespace? Is it necessary to tie multiple namespaces into the same forest? These questions must be answered before the design process can proceed.

  • WINS. Many modern networks include components that rely on WINS, including down-level (pre-Windows 2000) clients, legacy applications, and even some Microsoft services such as Distributed File System (DFS) that use NetBIOS resolution by default. Consequently, it is often necessary to keep using WINS in Windows networks, unless it can be definitively proven that it is no longer necessary.

  • DHCP. DHCP can be configured to allow for the Server service to update the Dynamic DNS record for the client if that client is unable to perform the update itself. This option can be turned on and off at the server level, through the DHCP Manager MMC. Additional design considerations regarding DHCP include:

    • Migrating existing DHCP scopes or recreating the scopes

    • Placement of DHCP services

Configuration

  • Active Directory Site and Replication Topology Layout. For purposes of replication, Active Directory logically organizes groups of servers into “sites”. Typically, a single site should be composed of servers that are connected to each other through T1 or higher-speed connections. The important factors to consider while identifying a site for consolidation include:

    • Network availability, bandwidth, and latency

    • Existing or future service level agreements (SLAs)

    • Application requirements

    • Physical condition of the location

    • User perception of performance

  • Domain Controllers. Determine the placement of domain controllers in Windows Server 2003 as it is the critical factor to improving the communication response time from an Active Directory query.

  • LAN and WAN links. 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 will be inconsequential. If the Active Directory and NetWare servers are physically separated across a low bandwidth or nonpersistent WAN connection, replication traffic will be more impactful. 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 Bindery. Although each environment is unique, it is important to understand that the following factors affect directory synchronization traffic:

    • Number of objects in Active Directory

    • Object size

    • Number of changes

    • Frequency of synchronization

    • One-way or two-way synchronization configuration

Management

  • Group Policies. While Group Policy Objects (GPOs) are a system introduced with Active Directory, predecessors to GPOs and components of GPOs are available without the use of Active Directory. System policies were introduced with Windows 95 and Windows NT 4.0 and were used to manage various aspects of those operating systems in a Workgroup or Domain environment. Local policies are available for Windows 2000, 2003 and XP computers that are not members of an Active Directory forest.

    Because of the potential presence of other policy based system for systems management, it is important to review the current use of policies in your organization and create a plan for either replicating the existing policy set using GPOs or modifying the existing requirements and implementing the new set of requirements

  • Login Scripts. Logins scripts are used extensively to control various aspects of the user experience in a NetWare environment. However, because NetWare uses a proprietary scripting language and system to provide login scripts, migration to batch file-based Active Directory login scripts requires careful planning. This is an excellent opportunity to review current login scripts for accuracy and relevance before design. Because of the hierarchical nature of NDS, login scripts in an NDS environment can be present at many levels of the directory and are all processed sequentially. Consequently, they should all be taken into account during design. In addition to the batch file processing capability natively present in Active Directory, capabilities of GPOs, Windows Scripting Host, and various Resource Kit Tools provide a powerful toolset for the creation of login scripts.

  • Security. Determine the security requirements that must be replicated in the new environment and the tools or features necessary to accomplish the required level of security.

Workstations

  • There are basically four different options for configuring the clients:

    • Physically walk to every single desktop, uninstall the Novell Client32, and remap to the Windows client. This is a manual process that takes approximately 10-15 minutes per workstation. If you don’t have a lot of computers in the environment, this may be the easiest approach.

    • Create a script. The script uninstalls and then installs in one process. It can be implemented manually through a batch file or a login script.

    • Launch a script through Group Policy. You can create a script that will uninstall the Client32 and install Windows remotely.

    • Retire Client32 during a phased desktop refresh. Before the client is removed, the Client32 software remains on the desktop, but all of the mappings are removed. Basically you remove the login script from the Novell system and you use Group Policy and Active Directory to do all of the drive mappings. At this point the Client32 is effectively unused, but is still present. While the refresh is in progress, you will still need to maintain a NetWare authentication mechanism in place so the user can login, but otherwise Active Directory will take over the network login functions.

Many organizations are choosing this fourth option.

Migration Planning

After you have determined what your new environment will look like, you are ready to determine how you will migrate your existing environment to the new environment. There are three components to planning the migration from Netware to Windows Server 2003: building the new environment, determining your migration strategy, and determining your migration process for moving your existing users and data to the new environment.

Building Active Directory

Before you can migrate you must first build the new Windows Active Directory environment. This section provides an overview of the options for building Active Directory. For detailed information regarding building Active Directory, see the Windows Server 2003 Deployment Kit: Designing and Deploying Directory and Security Services (https://www.microsoft.com/downloads/details.aspx?FamilyID=6CDE6EE7-5DF1-4394-92ED-2147C3A9EBBE&displaylang=en#filelist).

The Active Directory deployment strategy that you apply will vary according to your existing network configuration. For example, if your organization is purely a Novell NetWare environment, you will have to design and build the Active Directory from scratch. However, if your organization currently runs Windows NT 4.0, you can perform an in-place upgrade of the existing environment. If your organization currently runs Windows 2000 Active Directory, you can upgrade the domain to Windows Server 2003 functional levels through a separate migration process.

There are two strategies to building an Active Directory:

  • Build Active Directory from scratch

  • Upgrade (in-place) Migration of an Existing NT4 Domain or Windows 2000 environment

Building Active Directory from Scratch

If your organization only has NetWare servers and has never installed a Windows NT network in the environment, you can build the new Active Directory from scratch. With this process, a new, clean Active Directory is built, objects are created from scratch, and using migration tools, information such as user accounts and groups is pulled out of NDS and then moved across to Active Directory.

The advantage of creating an Active Directory from scratch is that it is clean and provides the opportunity to create a clear design. One of the disadvantages is that every computer must be touched. Computers that were members of a Workgroup have to now join the new domain. Another disadvantage is that you have to recreate or manually create user profiles. Things like user favorites, screen savers, icons, registry settings, and drive mappings are attached to the workgroup. When the computer is joined to the domain these preferences are lost. Fortunately, there are automated tools described in this document that will allow you to capture this information and recreate it in the new environment.

Upgrade (In place) Migration of an Existing NT4 Domain or Windows 2000 Environment

The in-place domain upgrade process is a direct upgrade of the existing production Windows NT 4.0 Server (operating system and domain) to Windows Server 2003 and Active Directory. Use the Windows Server 2003 Setup Wizard included on the Windows Server 2003 CD to perform the upgrade. For more information on upgrading existing NT4 domains, see Upgrading Windows NT 4.0 Domains to Windows Server 2003 Active Directory (https://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbb_over_dnrr.asp).

Upgrading your Windows 2000 domains to Windows Server 2003 domains is an efficient, straightforward way to take advantage of additional Windows Server 2003 features and functionality. Upgrading from Windows 2000 to Windows Server 2003 requires minimal network configuration and has little impact on user operations. For more information on upgrading existing Windows 2000 domains, see Windows Server 2003Upgrading Windows 2000 Domains to Windows Server 2003 Domains (https://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/dssbb_over_dnrr.asp).

Determining Your Migration Strategy

When developing a migration strategy there are a number of decisions that you must make:

  • Plan a direct or phased migration. Plan an immediate, one-time migration, or a phased migration over time (synchronizing Active Directory and your NDS directory during the transitional period). Detailed information for planning your phased or direct migration is covered in the following section.

  • Identify containers and servers to migrate or synchronize. Identify the containers that you want to migrate or synchronize and the Active Directory and NDS or Bindery servers between which you want to establish those relationships.

  • Identify and obtain administrator accounts with sufficient permissions to successfully complete the migration. If you will use synchronization, ensure that you have the required accounts with permissions to extend the Active Directory schema (even though the Services for NetWare 5.03 tool, Microsoft Directory Synchronization Service (MSDSS), does this automatically, you must have schema-extending administrative authority). If you will use two-way synchronization, ensure that you have the necessary permissions to extend the NDS schema.

    Important: When you set up a two-way synchronization session with MSDSS, you must have full administrator privileges to the entire NDS container in which you are creating the session. Ensure that these privileges are maintained for the life of the session—if these privileges are changed, objects may be deleted from one or both of the directories.

  • Choose the migration administrators. Decide who you will add as a member of the MSDSS Admins group that is created automatically when you install MSDSS. Choose the users to whom you will delegate specific MSDSS administrative tasks.

  • Determine the appropriate migration process. Determine if you will perform the migration manually or you employ migration tools and services. For details on selecting migration tools see the Migration Tools section of this chapter.

A Phased or Direct Migration?

In the Envisioning Phase, you determined which type of migration will work best for your organization. Use the sections that follow to plan the appropriate migration.

Phased Migration

In a phased migration, you use MSDSS to copy all Bindery or NDS user accounts, groups, and distribution lists, and (for NDS only) Organizational Units and organizations to Active Directory. At the same time, these objects are maintained in NDS or Bindery. While you gradually move resources to the Windows Server 2003-based environment, the MSDSS-provided directory synchronization enables users to continue to access those resources that remain on NetWare servers. As the changeover continues, users begin to access resources on Windows Server 2003-based servers with their new accounts and associated migrated permissions.

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

If you choose a phased migration:

  • List migration priorities. List the departments or other groupings, the software, and the hardware that you must migrate immediately, and which resources can be migrated over time. List the order in which you want to accomplish each stage

  • Choose one- or two-way synchronization. Decide whether one-way synchronization (using Active Directory to manage objects in both directories) or two-way synchronization (using either Active Directory or NDS to manage shared data) is appropriate to the situation. Take network traffic into account. Decide the timetable for replacing any of the Bindery- or NDS-dependent software with Active Directory-enabled counterparts. For more information, see the “Synchronization” section in this chapter.

Direct Migration

Keep in mind that this process can only be performed if there are no requirements to maintain legacy Novell systems and your environment is small enough or you have enough resources to migrate all of the workstations in the environment.

This process should be fully tested in the test environment to identify any issues and verify that there are no application requirements for Novell servers. After Novell servers are retired, the client will no longer be able to communicate with a server until it has been migrated to the Windows environment.

Synchronization

Synchronization allows users to work on both systems without losing data or having versioning problems. You will need to plan for synchronization if you are doing a phased migration or if your direct migration project lasts long enough to require that you support users on both systems.

The administration of multiple directory services often leads to time-consuming and redundant management. Establishing a periodic synchronization of both directories, using MSDSS or a third-party tool such as Quest NDS Migrator, will help you reduce the time you spend on directory management.

When you introduce Windows Server 2003 and Active Directory into an existing Novell network, you can facilitate directory management and improve data availability by establishing directory interoperability. Central to interoperability is the capability to synchronize the information stored in Active Directory with the Novell directory information within your organization. Microsoft Directory Synchronization Services (MSDSS), included with Services for NetWare 5.03, makes Active Directory synchronization with NDS and NetWare 3.x binderies possible.

By default, MSDSS synchronization duplicates the Bindery or NDS structure in Active Directory. Also like migration, synchronization maps Novell user, group, and distribution list objects to Active Directory user, group, and distribution list objects, and (for NDS only) it maps Novell OUs and organizations to Active Directory OUs. In addition, MSDSS synchronization optionally provides custom object mapping (for NDS only) that enables you to map objects in dissimilar directory structures to each other.

Synchronization and Active Directory are easy to set up through the MSDSS management interface. MSDSS provides two options for managing synchronization as part of a migration strategy:

  • One-way synchronization. This option enables you to manage objects in both directories from Active Directory. Reasons to select one-way synchronization include:

    • You want to centralize directory administration from Active Directory.

    • The network is predominantly Windows-based (with some NDS-based computers), or the network is currently NDS-based but you plan to reduce the number of directories over time.

    • You want to administer and update NDS user account passwords to support a single set of logon credentials that enable users to log on to both a Windows-based and a Novell-based network.

    • You are preparing to migrate an NDS-based directory environment to Active Directory.

  • Two-way synchronization. This option enables you to manage shared data, such as user account information, from either directory. Reasons to select two-way synchronization include:

    • You want two sets of network administrators to administer both Active Directory and NDS.

    • The network environment contains NDS as the primary directory, and you have no plans to consolidate the number of directory platforms.

    • You are planning to maintain and actively administer both directory environments for an extended period of time (several months or longer).

For more information on synchronization strategies see the NetWare to Windows Server 2003 Migration Planning Guide (https://www.microsoft.com/windowsserver2003/techinfo/overview/sfnmig.mspx).

Migration Process

The next component of the Planning Phase is determining your migration process. There are two options for the migration process: manual migration or automated migration using tools.

The reasons to use migration tools are relatively clear and include the capability to automate the migration of information while using existing NetWare investments and settings to decrease the time spent on the migration.

Migration tools provide the capability to automate the migration of information by using existing NetWare settings to decrease the time spent on the migration. Using migration tools, however, and factoring in their sometimes significant cost, may not always be necessary, particularly in situations where:

  • There is little configuration investment in access control lists (ACLs) or user account information in the Novell environment

  • The information stored in the Novell environment is not accurate or current

  • The number of objects or files is so small that it is not worth the time to install, learn, and use the migration tools

If one of more of these situations describes your network environment, consider a manual migration.

However, if you have a significant configuration investment, your Novell environment is up-to-date, and you have a large number of objects and files to migrate, migration tools may be helpful in the migration process.

Manual Migration

If you choose manual migration, you will need to re-enter user account information and/or reset file permissions manually.

Automated Migration

This guide focuses on two migration tools: Services for NetWare 5.03 and Quest NDS Migrator. For many organizations, Services for NetWare 5.03 provides for a robust synchronization and migration strategy that is cost-effective and easy to deploy. Other organizations have effectively used the advanced control, logging, and risk-management capabilities of Quest NDS Migrator to control their migration strategy. Either option is valuable, and it is recommended that you test both solutions as part of a prototype environment to determine which tools provide the best fit for your migration strategy. You should make a decision by the end of the prototype.

Migration Tools

While there are a number of tools available to assist with the migration, this guide focuses on Microsoft Services for NetWare 5.03 (SfN) and a third-party tool, Quest NDS Migrator.

Services for NetWare

Services for NetWare 5.03 (SfN) and Windows Server 2003 provide protocols and services that enable migration, synchronization, and limited interoperability with Novell NetWare networks. These protocols and services enable network managers and technical staff to integrate computers running Windows Server 2003 into a NetWare network to facilitate migration and/or coexistence. To enhance interoperability with NetWare networks, Services for NetWare 5.03 includes Directory Synchronization Services (MSDSS) and the File Migration Utility (FMU):

  • 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.

    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.

  • File Migration Utility. The File Migration Utility (FMU) is a utility that provides a central management console to automatically manage the migration of files from NetWare file and print servers to Windows 2003 servers. The File Migration Utility helps customers migrate their NetWare files to a Windows 2003 server by:

    • Accelerating the migration process through automation.

    • Preserving file security information.

    • Simplifying migration management.

    The File Migration Utility reduces the time and cost of migration by copying multiple NetWare files and their associated permissions to one or more Windows 2003 servers automatically. It preserves the permissions and ACLs associated with each file it copies. 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 2003-based network, preserving security and minimizing the time-consuming process of reassigning file rights and permissions.

    The File Migration Utility migrates files easily, 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 status report. Incremental migration support also allows customers to perform a gradual migration. Finally, FMU supports both the TCP/IP and IPX/SPX protocols to allow the migration of NetWare files and their permissions.

Table 1.0 provides a summary of the NetWare-based elements that can be migrated automatically from the major versions of NetWare to the Windows 2003 Server using the previously described tools and services.

Table 1.0: Summary of Services for NetWare 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

In addition to the tools outlined, Services for NetWare 5.03 provides troubleshooting support that enables you to troubleshoot connectivity problems, login scripts, and password synchronization. Services for NetWare 5.03 also provides tools for monitoring network traffic.

Quest NDS Migrator

Quest NDS Migrator is a comprehensive third-party solution that accelerates and simplifies migrations from Novell Directory Services (NDS) to Active Directory. Quest NDS Migrator offers a project-based step-by-step approach for migrating NDS and Bindery systems to Windows Server 2003 Active Directory. Quest NDS Migrator is a comprehensive tool that is recommended for large environment migrations. However, before deciding whether to use this tool, your organization should evaluate the cost of the tool and the resources required to support it.

Quest NDS Migrator works well in large environments, because it takes into account the fact that most NDS to Active Directory migrations are not simply one massive object copying process. Quest NDS Migrator allows object migration activities to be broken down into manageable object groupings.

The Quest NDS Migrator solution is comprised of several components including Quest NDS Reporter and Quest NDS Migrator:

  • Quest NDS Reporter. Quest NDS Reporter allows you to collect information about your Novell environment before you begin the migration. There are a number of reports that provide you with information regarding groups, users, and file servers. For more information about Quest NDS Reporter see the "Bibliography/References" section in Appendix A.

  • Quest NDS Migrator. Quest NDS Migrator provides all the tools you require to migrate objects and data to Active Directory from a central console. The console allows you to access all of the Quest migration options, both pre- and post-migration, and to schedule the data migration from Novell file servers to Microsoft file servers. In addition, Quest NDS Migrator provides a native view of both your NDS and Active Directory tree, allowing you to visualize the tree structure and better plan the migration of objects.

Creating the Functional Specification

Collect all of your decisions in the areas that you have thought about and documented during the Envisioning and Planning Phases. Be sure that the specifications are clear enough so that everyone can understand whether any particular specification has been met. The initial document is a baseline. You will want to check it in and do version control on it so that you can control the design that you’re actually going to build. The documentation that you have created up to this point will be included or summarized in this definitive document. Use this as a baseline. You will want to do version control on the document so that you can record changes that occur and track the design that you are actually going to build.

Developing the Project Schedule

A project plan complements the functional specifications document. It graphically illustrates the process of building and testing the technologies required and provides an outline of who is doing what during the project.

By using a product such as Microsoft Project 2003, you can organize the steps in a logical, linear process. The high-level tasks should be established first. Typically, they are the phases or high-level tasks involved in the project, such as Envisioning, Planning, Migrating, and Deploying. Then the main tasks of these phases can be added.

You should include dates and durations in the project plan, using the basic concept of starting with the end date when everything needs to be up and running, and then working backward. It's important to include key milestones, such as acquiring new software and hardware, sending administrative resources to training classes, and provisioning new data circuits.

To keep momentum going and to identify potential delays, milestones should be set for the completion of each phase. In most cases, projects without periodic dates set as interim milestone points will not meet the expected completion date. Projects that extend too far beyond the allotted time frame add costs and risks such as employee turnover, changing business conditions, and new revisions of hardware and software products.

Include slack time for unexpected events or stumbling blocks that the team may encounter. Each phase of the project needs to be outlined and then expanded. A good rule of thumb is to have each line represent several hours or days of work instead of trying to list every task that needs to take place during the phase. If the project plan includes too much detail, it quickly becomes unmanageable.

The plan should also assign resources to the tasks and start to define the teams that will work on the different components of the project. If an outside organization is going to assist in the process, include it at the appropriate points in the project.

Test Planning

Developing a Test Plan

The final component in the Planning Phase is to develop a test plan. The test plan defines the objectives and scope of the testing effort and identifies the methodology that your team will use to conduct tests. It also identifies the hardware, software, and tools required for testing and the features and functions that will be tested. A well-rounded test plan notes any risk factors that jeopardize testing and includes a testing schedule.Your test plan should include:

  • Testing scope and objectives

  • Testing methodology

  • Required resources

  • Identification of the features and functions that are to be tested

  • Testing schedule

For detailed information on developing a test plan, see the Creating a Test Plan section of the Windows Server 2003 Deployment Kit (https://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/all/deployguide/en-us/pdpbc_test_atds.asp).

Setting Up the Test Environment

Set up a test lab that includes a restored copy of the Bindery or NDS Server and a Windows Server 2003 domain controller with the Novell Client for Windows and the latest version of MSDSS.

  • Include examples of current and planned client workstations in the lab.

  • Include a copy of the production NDS structure in the lab.

  • Include copies of as many source Novell file/print servers as possible. Be sure to preserve security settings.

  • Include any other components that affect user experience in the lab, for example, system policies.

  • Install any Novell-dependent applications in the test lab and test their compatibility with your migration plans.

Developing Test Lab Guidelines and Procedures

Users of the test lab need to know when they can perform their tests, whether their testing will disrupt other tests, and what the current state of the lab is. Your lab manager or an assigned team member should establish a communication system to disseminate information about the availability and state of the test lab and should establish guidelines for lab use.

Guidelines should be easy to follow and should address:

  • Roles and responsibilities. Identify who is responsible for tasks such as scheduling test lab use and performing backups.

  • Facilities and guidelines for special types of tests. Identify the domains and configurations team members should use for testing the migration process.

  • Test lab change control procedures. Identify who is allowed to make configuration changes and define the approval process for change requests. For example, identify who can make schema changes and who should be notified when a change is made. Describe how changes to the lab should be made and identify who is responsible for documenting these changes.

  • Server initialization procedures. Document the steps for installing, configuring, and populating domain controllers and member servers. Include DNS settings if you do not plan to use the DNS Server service in Windows Server 2003.

  • Test lab restore procedures for testing the rollout. Document the steps for restoring domain controllers to their original state and for refreshing user account data. Document all server configurations. Test the refresh process before you begin migration testing.

  • Client computer restore procedures. If you plan to rebuild client computers frequently to test various configurations, document the tools required to quickly restore the computers to a known state. For example, if you use RIS, note this in your guidelines.

As part of the lab guidelines and procedures, the lab manager or an appointed team member also should develop an escalation plan and an incident-tracking system.