Migration Limitations and Restrictions

Table 20-1 highlights the possible upgrade paths. Within the table, Windows NT 4.0 Terminal Server Edition and all Windows 2000 versions are assumed to use Microsoft's native RDP-based services only (no Citrix software).

Table 20-1: The Operating System and MetaFrame Upgrade Matrix

Upgrade From	Upgrade To	Upgrade Possible	Recommended	Caveats
Windows NT 3.51 Server	Windows 2000 Server	Yes	No	Hardware limitations drivers Legacy settings and files Service Pack 5 (required)
Windows NT 3.51 Server	Windows Server 2003	No	No
Windows NT 4.0 Server	Windows 2000 Server Windows Server 2003	Yes	Yes	Legacy settings and files Service Pack 5 (required) Service Pack 6a (recommended)
Windows NT Server Enterprise Edition	Windows 2000 Server Windows Server 2003	Yes	Yes	Must use equivalent versions Legacy settings and files Service Pack 5 (required) Service Pack 6a (recommended)
Windows 2000 Server	Windows Server 2003	Yes	Yes	Must use equivalent versions
Windows NT 4.0 Terminal Server Edition (TSE)	Windows 2000 Server Windows Server 2003	Yes	No	Must use equivalent versions Legacy settings and files Service Pack 5 (required) Service Pack 6a (recommended) Licensing changes
Windows NT 4.0 TSE MetaFrame 1.0	Windows 2000 Server Windows Server 2003	No	No	Uninstall Citrix MetaFrame Licensing changes
Windows NT 4.0 TSE MetaFrame 1.8	Windows 2000 Server Windows Server 2003	No	No	Reinstall Citrix MetaFrame 1.8 Licensing changes
Windows 2000 Server MetaFrame 1.8	Windows Server 2003	No	No	Not supported by Citrix
Windows 2000 Server MetaFrame XP	Windows Server 2003	Yes	Yes	Licensing changes

Upgrading the Domain

Upgrading the domain is a significant first step, especially when upgrading from Windows NT 4.0. The next few sections discuss the required steps to perform the upgrade from a variety of operating systems.

Upgrading from Windows NT 3.51 Server

Although strictly speaking, an upgrade path from Windows NT 3.51 to Windows 2000 is possible, the authors strongly recommend it not be taken. The upgrade process is both inconsistent in its results, and unpredictable in terms of stability owing to the significant incompatibilities in hardware abstraction layers (HAL) and drivers. In rare cases where the network is trapped in a dependency on a legacy NT 3.51 domain controller, a rolling upgrade to Windows NT 4.0 and/or Windows 2000 may be needed. This should be viewed as a transitional upgrade only, with the upgraded server gracefully demoted and removed from the domain as soon as possible.

Upgrading from Windows NT 4.0 Server

The upgrade path from Windows NT 4.0 to Windows 2000 Server or Windows Server 2003 is more linear. The fundamental Microsoft restrictions must be met in terms of hardware capability, and application and driver compatibility. In addition, the primary domain controller (containing the read/write copy of the accounts database) must be upgraded first. Although NT 4.0 Service Pack 5 is the stated minimum requirement, Service Pack 6a provides greater stability and the same NTFS version compatibility as Service Pack 5 (NTFS version 5). Note that NTFS 5 compatibility does not allow a Windows NT 4.0 server to access all of the features of Windows 2000 NTFS, specifically: release points (also called mount points or junction points), Encrypting File System (EFS), and disk quotas. Finally, all upgrades from version to version are limited to upgrading to an equivalent, or later, operating system. For example, you cannot upgrade from Windows NT 4.0 Enterprise Edition to Windows Server 2003, you must use Windows Server 2003 Advanced Server.

Experience has shown that a transitional upgrade is by far the preferred method to migrate a domain from Windows NT 4.0 to Windows 2000 Server or Windows Server 2003, with or without Active Directory. In this context, transitional means the upgraded server platforms (PDCs and BDCs) exist only long enough to allow their roles to be moved to a new "clean install" server. Any upgrade from Windows NT 4.0 to Windows 2000 or later is imperfect, and legacy files and settings derived over the lifecycle of the original server are carried forward to the "new" domain model. The simplified transitional upgrade process is

• Validate to legacy NT 4.0 PDC based on Microsoft's upgrade recommendations.

• Install and configure a new NT 4.0 Interim server as a BDC with all required patches and services packs. This may be a high-end workstation rather than a server platform.

• Promote this interim BDC to PDC. This may be either a logical promotion using dcpromo to simultaneously demote the old PDC, or a ruthless promotion with dcpromo where the old PDC is offline and inaccessible.

• Verify that the read/write copy of the SAM database is completely replicated before proceeding.

• Upgrade the Interim server (now PDC) to Windows 2000 or Windows Server 2003 and install Active Directory as a mixed mode domain.

• Verify that all services (WINS, DNS, file replication) are working correctly.

• Verify that the upgrade is properly acknowledged by member servers. This may require a reboot of Windows 2000 or later member servers to re-register DNS and services in Active Directory.

• Remove the Legacy BDC (old PDC) from the domain and rebuild as Windows 2000 Server or Windows Server 2003, rejoin the domain, promote to domain controller, and verify services and synchronization.

• Once the rebuilt Domain Controller is stable, transfer the operation's master roles as necessary and reverify services and synchronization.

• Continue rebuilding the remaining Legacy BDCs as required.

• Demote and remove the Interim Domain Controller if appropriate.

Although this process may seem more cumbersome than the textbook Microsoft upgrade, consider the complexity of trying to configuration manage a directly upgraded server:

• Which files and versions are Legacy and not used by the current OS? Which registry entries are no longer valid?

• Which profile information must be managed? The information in %systemroot%\ profiles\%username% or that in Documents And Settings\%username%?

• Which profile elements are still linked?

Additional limitations, such as how to overcome the boot partition size limitation of Windows NT 4.0 (4.0GB native, 7.6GB maximum), are not always considered during an in-place upgrade.

One of the most commonly overlooked upgrade caveats deals with the Microsoft Terminal Services Licensing service. In a Windows NT 4.0 domain with Windows 2000 or Windows Server 2003 member Terminal Servers (with or without Citrix MetaFrame), the Licensing Service must be installed on a Windows 2000 or later member server. As soon as the domain is upgraded to Windows 2000 or Windows Server 2003, Terminal Services Licensing can only run on a domain controller. Terminal Services breaks immediately upon upgrade and remains so until it is deinstalled from the member server and reinstalled and relicensed on the Domain Controller.

Upgrading from Windows 2000 Server

The Windows 2000 to Windows Server 2003 upgrade is seamless and subject only to the previously discussed hardware, application, and version limitations. One notable exception is Novell Netware integration. If your environment requires interoperability with Novell over IPX/SPX (NWLink), you cannot use the 64-bit version of Windows Server 2003. Additionally, Windows 2003 Server-based domains can operate in one of three modes: Windows 2000 Mixed Mode (NT 4.0 compatible), Windows 2000 Native Mode (no NT 4.0 domain controllers), or Windows Server 2003 Mode (all domain controllers must be Windows Server 2003). Table 20-2 lists the features available for each mode.

Table 20-2: The Windows Server 2003 Domain Mode Feature Matrix

Domain Feature	Windows 2000 Mixed	Windows 2000 Native	Windows Server 2003
Domain controller rename tool	Disabled	Disabled	Enabled
Update logon timestamp	Disabled	Disabled	Enabled
Kerberos KDC key version numbers	Disabled	Disabled	Enabled
User password on InetOrgPerson object	Disabled	Disabled	Enabled
Universal Groups	Enabled for distribution groups. Disabled for security groups.	Enabled. Allows both security and distribution groups.	Enabled. Allows both security and distribution groups.
Group Nesting	Enabled for distribution groups. Disabled for security groups, except for domain local security groups that can have global groups as members.	Enabled. Allows full group nesting.	Enabled. Allows full group nesting.
Converting Groups	Disabled. No group conversions allowed.	Enabled. Allows conversion between security groups and distribution groups.	Enabled. Allows conversion between security groups and distribution groups.
SID History	Disabled.	Enabled. Allows migration of security principals from one domain to another.	Enabled. Allows migration of security principals from one domain to another.

Upgrading Terminal Servers

Operating system upgrades based on Microsoft's best practices allow administrators to migrate from one Terminal Server OS to the next. Upgrade considerations for Windows NT 4.0 TSE and Windows 2000 are listed next. While these upgrades are possible, administrators should consider the implications of moving multiple disparate OS versions to a common standard. Although the benefits of having all Terminal Servers running the same (modern) OS are obvious, configuration control and management may be lost. A Windows Server 2003 Terminal Server built from the ground up will be radically different from a server that was migrated from Windows NT 4 to Windows 2000 to Windows Server 2003. If a precise configuration control and management process requires servers to be identical, do not upgrade, rebuild.

Upgrading from Windows NT 4.0 TSE

The TSE-to-Windows 2000 Server (Terminal Server) or TSE-to-Windows Server 2003 (Terminal Server) upgraded path is subject to the same limitations discussed in the "Migration Limitations and Restrictions" section. Although not addressed as a critical consideration in that section, administrators must be aware that the upgrade also upgrades Internet Explorer. Any Terminal Service applications dependent upon IE functionality must be compatible with IE 5.01 or later. Additionally, licensing based on the old Operating Systems Equivalency provision (if a user ran Windows 2000 Professional on their desktop, they did not need a Terminal Service Client Access License) has been removed. All users (either by device or by user) must have a Windows Server 2003 CAL.

Upgrading from Windows 2000

The Windows 2000 to Windows Server 2003 upgrade is seamless and subject only to the previously discussed hardware, application, license, and version limitations.

Upgrading Citrix MetaFrame

Upgrading existing Windows 2000 servers that are already running MetaFrame XP is a straightforward Microsoft-centric in-place upgrade. Conversely, upgrading both the OS version and the Citrix MetaFrame version requires special considerations.

Upgrading from Windows NT 4.0 TSE and MetaFrame 1.8

Microsoft documentation indicates Citrix MetaFrame 1.8 must be deinstalled prior to upgrading to Windows 2000. This is not strictly true, and although not a recommended upgrade path, it is a viable subject for several restrictions:

• The operating system must be upgraded first.

• After the OS upgrade, Citrix MetaFrame 1.8 for Windows NT will show as "installed" but will not function, and error messages will indicate a new version of Citrix MetaFrame is required.

• Reinstall Citrix MetaFrame 1.8 for Windows 2000.

• This upgrade process preserves all published applications and MetaFrame settings.

Upgrading from Windows 2000 and MetaFrame 1.8

Migration from MetaFrame 1.8 to MetaFrame XP on Windows 2000 is intended to be a transitional strategy, not a permanent fixture. During the migration process, the MetaFrame server farm must run in Interoperability mode, which limits the use of some MetaFrame XP advanced features. The following general limitations apply:

• Upgrade Citrix MetaFrame from 1.8 to XP first.

• Migration licenses are required.

• Avoid leaving the farm in Interoperability mode for an extended period.

• The MetaFrame XP server farm must have the same name as the MetaFrame 1.8 server farm. When you install MetaFrame XP on the first server in the farm, name the server farm at the same time you create the data store.

  Note

  ICA Clients see the MetaFrame XP and MetaFrame 1.8 farms operating in mixed mode as a single farm. However, they are actually two separate farms.

• Management Utilities are different.

  • MetaFrame XP farms and MetaFrame 1.8 farms are managed by separate utilities. You can manage a MetaFrame 1.8 farm using MetaFrame 1.8 utilities including Citrix Server Administration (mfadmin.exe) and Published Application Manager (appcfg.exe). You should use the updated versions of these tools that are installed on each MetaFrame XP server. We do not recommend running previous versions of these tools from the existing MetaFrame 1.8 servers.

  • Use the Published Application Manager utility to configure and modify published applications for MetaFrame 1.8 servers. Use the Citrix Server Administration utility to configure options on MetaFrame 1.8 and MetaFrame XP servers. Note that the settings on MetaFrame XP servers take effect only when the server farm is operating in mixed mode.

  • Use the Citrix Management Console to manage a MetaFrame XP farm. Published Application Manager cannot be used to manage applications migrated to MetaFrame XP servers.

• When MetaFrame XP is configured for mixed mode operation, MetaFrame 1.8 farms and MetaFrame XP farms appear unified because ICA browsers in both farms pool information. A MetaFrame XP server becomes the master ICA browser of both farms. The new master ICA browser holds information about the published applications available on each server.

  MetaFrame XP mixed mode operation requires two types of network traffic. Both MetaFrame 1.8 servers and MetaFrame XP servers communicate via UDP Port 1604 for MetaFrame 1.8 server communication. In addition, IMA TCP Port 2512 traffic exists between all MetaFrame XP servers for MetaFrame XP server communication. Operating in MetaFrame XP mixed mode results in increased network traffic and can affect network scalability.

• For additional details, refer to the Citrix XP Migration whitepaper at http://support.citrix.com/servlet/KbServlet/download/30-102-7632/XP_Migration_Whitepaper.pdf

During the transitional phase (before all servers are moved to MetaFrame XP), the following functional limitations exist:

• In mixed mode, the XML Service connects to the Program Neighborhood Service using Program Neighborhood Named Pipes. In native mode, the XML Service connects to the IMA Service using an IMA Remote Procedure Call (RPC).

• The ICA Client uses the Program Neighborhood virtual channel to connect to the Program Neighborhood Service in mixed mode, and to the Program Neighborhood subsystem in native mode.

• The ICA Client uses the ICA browser protocol (UDP Port 1604) to connect to the ICA browser service in mixed mode, and to the browser subsystem in native mode.

• In mixed mode, the Program Neighborhood and ICA browser services exist and are enabled, while the Program Neighborhood and browser subsystems are disabled. The Program Neighborhood and ICA browser services interact with the local Windows Registry.

• In mixed mode, Citrix Server Administration (mfadmin.exe) makes RPC connections to all MetaFrame 1.8 and MetaFrame XP servers. It also connects to Termsrv via Winstation API (RPC). In native mode, Citrix Server Administration makes RPC connections only to MetaFrame 1.8 servers.

• In mixed mode and in native mode, Published Application Manager (appcfg.exe) reads application information only from MetaFrame 1.8 servers. Published applications for MetaFrame XP are managed only through the Citrix Management Console.

• The IMA service exists in both modes of operation. It communicates with other servers via the IMA protocol over TCP Port 2512. It also connects to Termsrv via Winstation API (RPC), the local host cache via ODBC, and the data store via ODBC. The IMA service interacts with the local Windows Registry only in mixed mode.

This upgrade process preserves all published applications and MetaFrame.

Licensing Considerations

One of the most confusing parts of upgrading a Citrix MetaFrame farm is the limitations imposed by Microsoft's Terminal Services licensing, which varies based on the domain environment and the operating system used for the Terminal Servers. Table 20-3 summarizes the licensing server options.

Table 20-3: Microsoft Terminal Services Licensing

Domain	Terminal Server OS	Licensing Server
Windows NT	Windows NT TSE	Windows NT member server, Windows 2000 member server, or Windows Server 2003 member server
	Windows 2000	Windows 2000 member server or Windows Server 2003 member server
	Windows Server 2003	Windows Server 2003 member server
Windows 2000	Windows NT TSE	Windows 2000 domain controller or Windows Server 2003 member server
	Windows 2000	Windows 2000 domain controller or Windows Server 2003 member server
	Windows 2003	Windows Server 2003 member server
Windows 2003	Windows NT TSE	Windows Server 2003 member server
	Windows 2000	Windows Server 2003 member server
	Windows 2003	Windows Server 2003 member server

For Windows Server 2003 Terminal Servers, a new licensing server is required (Windows 2000 will not support Windows Server 2003 Terminal Services licensing). However, a Windows Server 2003 licensing server will support Windows 2000 and Windows 2003 licensing as well as legacy Windows NT TSE licensing. On the plus side, a Windows Server 2003 license server does not have to be a domain controller, and when installed in a Windows 2000 domain, eliminates the former restriction that Windows 2000 Terminal Services Licensing Service must reside on a DC. During migration to Windows Server 2003, the first step is to install a new Windows Server 2003 license server.

Finally, the Windows Server 2003 licensing server must be configured as a license server compatible with Windows 2000 server, as discussed in the Microsoft KnowledgeBase article Q278513.