Migration Paths for Migrating to a Failover Cluster Running Windows Server 2012

  • Article

 

Applies To: Windows Server 2012

This topic provides guidance for migrating specific clustered services and applications to a failover cluster running the Windows Server 2012 operating system by using the Migrate a Cluster Wizard in Failover Cluster Manager. The topic covers supported migration paths, provides an overview of wizard-based migration, and notes which clustered services and applications require special handling during migration.

Migration paths for specific migrations

The following table lists the operating system versions on a source failover cluster that can be migrated to a failover cluster running Windows Server 2012 for each clustered service or application. Migrations between failover clusters created with physical computers and failover clusters that are created from virtual machines (also known as a guest cluster) are supported.

Supported migrations for clustered roles and resources to a Windows Server 2012 failover cluster

Clustered role or resource

From Windows Server 2008 SP2

From Windows Server 2008 R2 SP1

From Windows Server 2012

Cluster Registry settings

Yes

Yes

Yes

Cluster Shared Volumes (CSV)

No

Yes

Yes

DFS Namespace (DFS-N)

Yes

Yes

Yes

DFS Replication (DFS-R)

No

Yes

Yes

DHCP Server

Yes

Yes

Yes

Distributed Network Name (DNN)

No

No

Yes

File Server

Yes

Yes

Yes

Scale-out File Server for application data

No

No

Yes

Generic Application

Yes

Yes

Yes

Generic Script

Yes

Yes

Yes

Generic Services

Yes

Yes

Yes

Virtual Machines

Yes

Yes

Yes

Hyper-V Replica Broker

No

No

Yes

IP addresses (IPV4, IPV6, IPv6 tunnel addresses)

Yes

Yes

Yes

iSCSI Target Server

No

Yes

Yes

Internet Storage Name Service (iSNS)

Yes

Yes

Yes

Message Queuing (MSMQ), MSMQ triggers

Yes

Yes

Yes

Microsoft Distributed Transaction Coordinator (MSDTC)

Yes

Yes

Yes

Network Name resources

Yes

Yes

Yes

NFS shares

Yes

Yes

Yes

Other Server

Yes

Yes

Yes

Physical Disk resource

Yes

Yes

Yes

WINS Server

Yes

Yes

Yes

Cluster roles that cannot be migrated

Some services and applications that can run in a failover cluster on Windows Server 2012 cannot be migrated by using the Migrate a Cluster Wizard—in some cases because they were not supported on earlier versions of clustering. The Migrate a Cluster Wizard in Windows Server 2012 cannot be used to migrate the following clustered roles:

  • Microsoft SQL Server

  • Microsoft Exchange Server

  • Print Spooler – In Windows Server 2012, the print spooler is no longer a clustered resource. Instead, high availability is defined as a highly available virtual machine running on a single cluster node. The Print Server role is installed on a single virtual machine, which can be migrated to other nodes automatically or manually. For more information, see High Availability Printing Overview.

  • DFS Replication (DFS-R) from Windows Server 2008 - Migration from Windows Server 2008 R2 or Windows Server 2012 is supported, but not from Windows Server 2008.

  • Remote Desktop Connection Broker - In Windows Server 2012, the active/passive clustering model for the RD Connection Broker role service, used in earlier versions of Windows Server, is replaced by the Active/Active Broker feature, which eliminates the need for clustering and provides a fully active/active model. For more information, see the blog entry RD Connection Broker High Availability in Windows Server 2012.

  • Volume Shadow Copy Service (VSS) tasks

  • Task Scheduler tasks (Windows Server 2012 only)

  • Cluster Aware Updating (CAU) settings (Windows Server 2012 only)

Roles restricted to a single instance per cluster

For the following roles, only one instance per failover cluster is supported:

  • DHCP Server

  • WINS Server

  • iSCSI Target Server

  • Hyper-V Replica Broker (Windows Server 2012 only)

For those roles, the Migrate a Cluster Wizard will not attempt to create a second role instance if one instance already exists on the target cluster.

Migrations for which the Migrate a Cluster Wizard performs most or all steps

For the following clustered services or applications, The Migrate a Cluster Wizard performs most or all steps for a migration to a Windows Server 2012 failover cluster:

  • Distributed File System (DFS) Namespace

  • Generic Application

  • Generic Script

  • Generic Service

  • IPv4 Address, when migrating within the same subnet

  • IPv6 Address or IPv6 Tunnel Address

  • Internet Storage Name Service (iSNS)

  • Network Name (other than the cluster name)

    If Kerberos authentication is enabled for the Network Name resource, the migration wizard prompts you for the password for the Cluster service account that is used by the old cluster.

  • NFS

  • Physical Disk (resource settings only; does not copy data to new storage)

  • Windows Internet Name Service (WINS) (Extra steps might be required if you migrate to new storage, and you use a different drive letter on the path to the new database.)

For step-by-step instructions for performing a migration between two multimode failover clusters, see Migration Between Two Multi-Node Clusters. For step-by-step instructions for performing a stand-alone migration while upgrading a single failover cluster, see In-Place Migration for a Two-Node Cluster.

Migration within mixed environments

The Migrate a Cluster Wizard can migrate clustered resources within mixed environments. For example, the wizard accommodates the following differences in the source and destination environments:

  • Migrate static IP addresses to a cluster using DHCP.

  • Migrate IPv4 resources into an IPv6 environment.

  • Migrate across routed subnets.

  • Migrate a physical cluster to a guest (virtual) cluster (with the exception of Hyper-V clusters, which must run on physical computers).

  • Migrate between different editions of the operating system (for example, from Windows Server Enterprise to Windows Server Datacenter), between x86 and x64 processor architectures, and from a cluster running ona Server Core installation or from Microsoft Hyper-V Server to a cluster running a full installation of Windows Server.

During migration, the wizard allows you to address name conflicts between resource groups, resources, and share names and to address drive letter collisions. The wizard resolves the conflicts as part of the post-migration repair process.

Important

The Migrate a Cluster Wizard moves resources, not data. If you plan to migrate to new storage, you must move the data and folders yourself.

Additional steps for a wizard-based migration

Some additional steps typically are needed before or after you run the wizard, including the following:

  • Install server roles and features that are needed in the new cluster. In most cases, you must install the role or feature on all nodes of the cluster.

  • Copy or install any associated applications, services, or scripts on the new cluster (all nodes).

  • If a migrated role or feature uses the same storage, take the services and storage offline on the old cluster and then make the storage available to the new cluster.

  • If a migrated role or feature uses new storage, ensure that any data and folders are copied to new storage. Verify permissions on any shared subfolders that were migrated.

  • If the new cluster is on a different subnet, provide static IP addresses.

  • If the new cluster uses a different volume letter, update drive path locations for applications.

  • Configure Task Manager tasks on the new cluster. (Windows Server 2012 only)

  • For a virtual machine, install the latest integration services on the new virtual machine. Configure Volume Shadow Copy Service (VSS) backups. For a Windows Server 2012 migration, configure Hyper-V Replica settings.

  • Configure Cluster Aware Updating (CAU). (Windows Server 2012 only)

Migration reports

The wizard provides both a Pre-Migration Report and a Post-Migration Report, which provide important information. We recommend that you review both reports while performing a migration:

  • The Pre-Migration Report explains whether each resource that you plan to migrate is eligible for migration.

  • The Post-Migration Report contains information about the success of the migration, and describes additional steps that might be needed before you bring the migrated resources online.

Note

Two resource groups are never migrated: Cluster Core Resources Group and Available Storage Group. You can ignore these resource groups in the migration reports.

Clustered role and feature migrations that require extra steps

This section provides guidance for migrating clustered roles and features that require additional steps before or after you run the Migrate a Cluster Wizard to perform a cluster migration.

Clustered DFS Replication migrations

Before you migrate clustered Distributed File System (DFS) Replication (also known as DFS-R or DFSR) to a cluster running Windows Server 2012, you must add the new cluster to the DFS replication group to which the old cluster belongs, and then wait until DFS Replication synchronizes the data to the new cluster. After data synchronization is complete, you can decommission the old cluster. For step-by-step guidance, see File and Storage Services: Prepare to Migrate and File and Storage Services: Post-migration Tasks.

To migrate clustered instances of DFS Replication between clusters running Windows Server 2012

  1. Obtain the name of the cluster to which you will migrate. In Active Directory, this is the name that is used for the computer account of the cluster itself (also called the cluster name object or CNO). Add this name to the replication group that you will migrate. For more information, see Add a member to a replication group.

  2. Wait until DFS Replication finishes synchronizing the replicated data to the cluster to which you will migrate.

  3. If you plan to decommission the cluster from which you migrated, remove its network name from the replication group. If necessary, destroy the cluster.

For more information about DFS Replication in Windows Server 2012, see DFS Namespaces and DFS Replication Overview.

Clustered DHCP migrations

When migrating clustered Dynamic Host Configuration Protocol (DHCP) to a cluster running Windows Server 2012, the Migrate a Cluster Wizard migrates resources and settings, but not the DHCP database. For information about how to migrate the DHCP database, see DHCP Server Migration: Migrating the DHCP Server Role. The information in the topic also applies to migrations from Windows Server 2008 R2 to Windows Server 2012. The topic includes information about migrating from a cluster.

Note

Although the migration of the clustered DHCP role is supported, in Windows Server 2012 there is the option to use DHCP failover. DHCP failover provides redundancy and load balancing without clustered DHCP. For more information, see Migrate to DHCP Failover and Understand and Deploy DHCP Failover.

Clustered DTC migrations

Before you begin the migration of clustered Distributed Transaction Coordinator (DTC) to a cluster running Windows Server 2012, you must make sure the list of transactions stored by DTC is empty. This is referred to as draining the transaction logs. If you do not drain the logs, the information in the logs (the transaction state information for unresolved transactions) will be lost during the migration. Unresolved transactions include Active, In Doubt, and Cannot Notify transactions.

To drain DTC transaction logs of unresolved transactions

  1. Stop the application that creates transactions on the clustered instance of DTC that is being migrated.

  2. On a node of the cluster that you are migrating from, click Start, point to Administrative Tools, and then click Component Services. (In Windows Server 2012, open Component Services directly from the Start screen.)

  3. Expand Component Services, expand Computers, expand My Computer, expand Distributed Transaction Coordinator, and then expand Clustered DTCs.

  4. Expand the clustered instance of DTC that you are migrating, and then click Transaction List.

  5. View the transaction list to see if it is empty. If there are transactions listed, then either wait for them to be completed or right-click each transaction, click Resolve, and then select Forget, Commit, or Abort.

    For information about the effect of each of these options, see Transaction State Resolution After System Failure.

For additional information, see View Transaction Information.

Clustered File Server and Scale-out File Server migrations

You can migrate a clustered file server from Windows Server 2008 R2 or Windows Server 2008 to a failover cluster running Windows Server 2012 by using the Migrate a Cluster Wizard.

Clustered file server migrations

If you plan to migrate to new storage, keep in mind that if the migrated files and folder inherit permissions from their parents, during migration it is the inheritance setting that is migrated, not the inherited permissions. Therefore it is important to make sure that the parent folders on the source server and the destination server have the same permissions to maintain the permissions on migrated data that has inherited permissions. After the file server migration, it’s important to verify the folder permissions after the migration. Sometimes folder permissions reset to Read-only during a file server migration.

You do not need to migrate the quorum resource. When you run the Create a Cluster Wizard in Windows Server 2012, the cluster software automatically chooses the quorum configuration that provides the highest availability for your new failover cluster. You can change the quorum configuration on the new cluster if necessary for your specific environment.

Scale-out File Server migrations

The Scale-out File Server feature was introduced in Windows Server 2012. You can use the Migrate a Cluster Wizard to migrate a scale-out file server from one Windows Server 2012 failover cluster to another Windows Server 2012 failover cluster.

  • The new failover cluster must use the same storage that the old cluster used.

  • When you prepare for the migration, after you add the File Server role to each cluster node, you must configure the File Server role as the Scale-out File Server for application data role type. For more information, see Deploy Scale-out File Server.

Clustered FSRM migrations

To migrate the File Server Resource Manager (FSRM) classification, storage reporting, and file management task configuration on a clustered file server running Windows Server 2008 R2 or Windows Server 2008 to a failover cluster running Windows Server 2012, you must export the configuration from one FSRM server node in the cluster and then import the configuration to another FSRM server. These steps must be performed locally on one node of the cluster. You then fail over the other nodes until this process is complete. For step-by-step instructions, see Migrate File and Storage Services to Windows Server 2012.

Important

When you migrate the configuration, FSRM requires that you use the same drive letters on both the source and destination servers.

Clustered Message Queuing (MSMQ) migrations

When you migrate a clustered instance of Message Queuing (also known as MSMQ) to a cluster running Windows Server 2012, it’s important to take the following precautions to ensure that the data is preserved and you can bring the service online on the new cluster:

  • Before you migrate, you should back up the data that is associated with clustered instances of Message Queuing. This ensures that you can restore service-specific Message Queuing data if it is accidentally deleted during migration. For more information about Message Queuing backup and restore, see Backing up and restoring messages.

  • During the migration, it’s important to make sure that the migration is complete before you delete either clustered instance of Message Queuing (old or new). Otherwise, service-specific data for Message Queuing might be deleted from the shared storage, which prevents the remaining Message Queuing resource from coming online. After the migration is complete and you are ready to delete a clustered instance of Message Queuing (old or new), first remove the disk resource from that clustered instance and take the disk offline. Then delete the clustered instance of Message Queuing.

Other Server migrations involving resource types not built into failover clusters

Before you use the Migrate a Cluster Wizard to migrate an application that uses a clustered resource type that is not built into failover clustering, be sure to add the resource type to the new cluster. You can then use the Migrate a Cluster Wizard to migrate your clustered application. In this situation, the Migrate a Cluster Wizard attempts a "best effort" migration.

To add a resource type to a failover cluster running Windows Server 2012

  1. Open Failover Cluster Manager from the Start screen of any node in the cluster running Windows Server 2012.

  2. If the cluster to which you want to migrate is not displayed, in the console tree, right-click Failover Cluster Manager, click Connect to Cluster, select the cluster that you want to migrate to, and then click OK.

  3. In the console tree, right-click the cluster, and then click Properties.

  4. Click the Resource Types tab, and then click Add.

  5. Specify the following information for the resource type:

    • Resource DLL path and file name: The path and file name of the resource dynamic-link library (DLL) that the Cluster service should use when it communicates with your service or application.

    • Resource type name: The name that the Cluster service uses for the resource type. This name stays the same regardless of the regional and language options that are currently selected.

    • Resource type display name: The name that is displayed for the resource type. This name might vary when you make changes to regional and language options.

Clustered virtual machine migrations

You can use the Migrate a Cluster Wizard to migrate highly available virtual machines deployed using Hyper-V from a Windows Server 2008 R2 or Windows Server 2008 failover cluster to a cluster running Windows Server 2012. Using the wizard, you can migrate the Virtual Machine clustered role, select highly available virtual machines to migrate, and update virtual network settings for the virtual machines on the new cluster.

Migrating a highly available virtual machine requires some additional steps:

  • You must merge or discard all shadow copies before you migrate the volume that contains the virtual machines. You should back up the volumes before you begin merging or discarding shadow copies.

  • If you migrate one virtual machine that is stored on Cluster Shared Volume (CVS) volume, the Migrate a Cluster Wizard migrates all virtual machines on that volume. This restriction does not apply if you are migrating a Scale-out File Server cluster between Windows Server 2012 failover clusters. The Scale-out File Server cluster does not use CSV volumes, so you can migrate one virtual machine at a time.

  • After you migrate the virtual machines, you must install the latest integration services on the new virtual machines.

  • The wizard does not migrate Hyper-V Replica settings or Volume Shadow Copy Service (VSS) tasks. If you are using these with your virtual machines, you must configure them on the new cluster after the migration.

For step-by-step guidance, see Migration of Highly Available Virtual Machines Using the Migrate a Cluster Wizard.

Additional references