Migrate Remote Access to Windows Server 2012

Applies To: Windows Server 2012

Routing and Remote Access Service (RRAS) was a role service in Windows Server operating systems prior to Windows Server 2012 that enabled you to use a computer as an IPv4 or IPv6 router, as an IPv4 network address translation (NAT) router, or as a remote access server that hosted dial-up or virtual private network (VPN) connections from remote clients. Now, that feature has been combined with DirectAccess to make up the Remote Access server role in Windows Server 2012 This guide describes how to migrate a server that is hosting the Routing and Remote Access service (in Windows Server 2008 R2 and other down-level versions) to a computer that is running Windows Server 2012.

About this guide

Migration documentation and tools ease the migration of server role settings and data from an existing server to a destination server that is running Windows Server 2012. By using the tools that are described in this guide, you can simplify the migration process, reduce migration time, increase the accuracy of the migration process, and help to eliminate possible conflicts that might otherwise occur during the migration process. For more information about installing and using the migration tools on the source and destination servers, see the Windows Server Migration Tools Installation, Access, and Removal Guide (https://go.microsoft.com/fwlink/?LinkId=247607).

Target audience

This document is intended for information technology (IT) administrators, IT professionals, and other knowledge workers who are responsible for the operation and deployment of the Remote Access servers in a managed environment. Some scripting knowledge may be required to perform some of the migration steps that are contained in this guide.

What this guide does not provide

This guide does not describe the architecture or detailed functionality of the Remote Access role. The following scenarios are not supported in this migration guide:

• Any process for an in-place upgrade, in which the new operating system is installed on the existing server hardware by using the Upgrade option during setup

• Clustering and multisite scenarios

• Migrating more than one server role

  If your server is running multiple roles, it is recommended that you design a custom migration procedure that is specific to your server environment and based on the information that is provided in this and other role migration guides.

Supported migration scenarios

This guide provides instructions for migrating an existing server to a server that is running Windows Server 2012.

Supported operating systems

This guide provides instructions for migrating data and settings from an existing server that is being replaced by a new physical or virtual 64-bit server with a clean-installed operating system, as described in the following table.

• The versions of operating systems shown in the preceding table are the earliest combinations of operating systems and service packs that are supported. Newer service packs are supported.

• Migration with the destination server already having DirectAccess configured is not supported.

• The Foundation, Standard, Enterprise, and Datacenter editions of the Windows Server operating system are supported as either source or destination servers. This includes migrating across editions. For example, you can migrate from a server running Windows Server 2003 Standard to a server running Windows Server 2012.

• Migrations between physical operating systems and virtual operating systems are supported.

• Migration from a source server to a destination server that is running an operating system in a different system UI language (that is, the installed language) than the source server is not supported. For example, you cannot use Windows Server Migration Tools to migrate roles, operating system settings, data, or shared resources from a computer that is running Windows Server 2008 R2 in the French system UI language to a computer that is running Windows Server 2012 in the German system UI language.

  Note

  The system UI language is the language of the localized installation package that was used to set up the Windows operating system.

• Both x86- and x64-based migrations are supported for Windows Server 2003 and Windows Server 2008. All editions of Windows Server 2008 R2 and Windows Server 2012are x64-based.

Supported role configurations

The following is a broad list of the migration scenarios that are supported for Remote Access. All settings under these scenarios are migrated.

• DirectAccess (supported in Windows Server 2012 to Windows Server 2012 migration only)

• VPN server

• Dial-up server

• Network address translation (NAT)

• Routing, with the following optional components:

  • DHCP Relay Agent

  • Routing Information Protocol (RIP)

  • Internet Group Management Protocol (IGMP)

In addition to the above scenarios, migration also automatically adjusts configuration of the destination server to account for features that are no longer supported and to support features that are new in Windows Server 2012 and not supported on earlier versions of Windows.

Migration dependencies

If a local or remote NPS server that is used for authentication, accounting, or policy management must also be migrated, then migrate the NPS service before migrating Remote Access. For more information, see Migrate Network Policy Server to Windows Server 2012.

If you are upgrading from Windows 2008 R2 DirectAccess to Windows Server 2012, ensure that all the DirectAccess configuration settings have been applied on the Windows 2008 R2 server. It is possible to save settings through the console but not apply them. Before upgrading, ensure that the saved settings have also been applied.

Migration components that are not supported in all operating system versions

The following Remote Access components are not supported by all operating systems:

Migration components that are not automatically migrated

The following Remote Access elements and settings are not migrated by the Windows PowerShell cmdlets that are supplied with the Windows Server Migration Tools. Instead, you must manually configure the element or setting on the new RRAS server as described in Completing the required manual migration steps in this guide.

• SSL certificate bindings. SSL Certificate binding and crypto-binding settings for SSTP are migrated as follows:

  1. The migration Wizard looks for a source certificate on the destination computer. If one is found, SSTP uses that certificate.

  2. If a source certificate is not found, the migration wizard will look for a valid certificate with the same trusted root as the source certificate.

  3. If still no certificate is found, then the SSTP configuration on the destination computer is ‘Default’.

  4. If self-signed certificates are being used (valid for Windows Server 2012), they will be automatically created on the destination computer.

• User accounts on the local RRAS server. If you use domain-based user and group accounts, and both the old and new RRAS servers are part of the same domain, no migration of the accounts is required. Local user accounts can be used if Windows Authentication is configured on the RRAS source server.

• Only routing/VPN/DirectAccess when all are installed. If your Remote Access server configuration includes all of the available services, then all services must be migrated together. Migrating only one of the services to the destination server is not supported.

• A local or remote server that is running Network Policy Server (NPS) that provides authentication, accounting, and policy management. This guide does not include the steps that are required to migrate a server that is running NPS. To migrate a server that is running NPS, use Migrate Network Policy Server to Windows Server 2012. NPS migration should be performed when directed later in this guide.

  Note

  If you are not using a server that is running NPS, the default Remote Access policies and accounting settings that are automatically created while configuring RRAS are not migrated.

• Dial-up based demand-dial connections. The destination server might have different modems, and there are many demand-dial settings that are specific to the modem or ISDN device that is selected.

• Certificates used for authenticating IKEv2, SSTP, and L2TP/IPsec connections.

• SSL Certificate Binding for SSTP when the Use HTTP check box is not selected.

• IKEv2 VPN connections that use IPv6 network adapters. IKEv2 is supported on RRAS servers that are running Windows Server 2008 R2 only. In the RRAS Microsoft Management Console (MMC) on Windows Server 2008 R2, you can specify the network interface used to acquire IPV6 DHCP and DNS addresses that are used for IKEv2 VPN clients. If you migrate RRAS from Windows Server 2008 R2 to another server running Windows Server 2008 R2, the setting is migrated. However, if you migrate from a previous version of Windows, there is no setting to migrate, and the default value of Allow RAS to select the adapter is used.

• Weak encryption. In Windows Server 2003, weak encryption is enabled, but on later versions of Windows it is disabled by default. You can enable weak encryption only by modifying the registry. During migration from Windows Server 2003 the required registry settings are not created on the new server by the migration process, and they must manually be configured. For later versions of Windows, if these registry settings are present, they are migrated.

• Admin DLLs and Security DLLs and their corresponding registry keys. These DLLs are available in both 32-bit and 64-bit versions, and they do not work in a 32-bit to 64-bit migration.

• Custom DLLs used for dialing a demand-dial connection. These DLLs are available in both 32-bit and 64-bit versions, and they do not work in a 32-bit to 64-bit migration. Any corresponding registry settings also are not migrated.

• Connection Manager profiles. The Connection Manager Administration Kit is used to create VPN and dial-up remote access profiles. Profiles created are stored under specific folders on the RRAS server. Profiles that are created on a 32-bit version of Windows do not work on computers that are running a 64-bit version of Windows, and vice versa. For more information about connection profiles, see Connection Manager Administration Kit (https://go.microsoft.com/fwlink/?linkid=55986).

• The Group Forwarded Fragments setting on NAT. This setting is enabled if the RRAS server is deployed behind a NAT router running on the Windows operating system. This is required for L2TP/IPsec connections that are using computer certificate authentication to succeed. We recommend that you enable this value to work around a known issue in RRAS.

• The Log additional Routing and Remote Access information (used for debugging) setting in the Routing and Remote Access Properties dialog box on the Logging tab.

Overview of the Routing and Remote Access service migration process

The pre-migration process involves the manual collection of data, followed by running procedures on the destination and source servers. The migration process includes source and destination server procedures that use the Export and Import cmdlets to automatically collect, store, and migrate server role settings. Post-migration procedures include verifying that the destination server successfully replaced the source server and then retiring or repurposing the source server. If the verification procedure indicates that the migration failed, troubleshooting begins. If troubleshooting fails, rollback instructions are provided to return the network to the use of the original source server.

Impact of migration

During migration, the Remote Access server is not available to accept incoming connections or to route traffic.

• New remote clients cannot connect to the server by using dial-up, VPN or DirectAccess connections. Existing connections on the server are disconnected. If you have multiple remote access servers, then the loss of availability of this server results in a reduction in capacity until the new server is operational again. For demand-dial connections, you must provide alternate connectivity between offices or reconfigure the connections to point to an alternate server.

• Routing and NAT functionalities are not available. If the functionality is required during the migration, an alternate router can be deployed until the new destination server is available.

Post-migration impacts include the following:

• If you plan to reuse the name of the source server as the name of the destination server, the name can be configured on the destination server after the source server is disconnected from the network. Otherwise, there is a name conflict that can affect availability. If you plan to run both servers, then the destination server must be given a unique name.

• A VPN server can be directly connected to the Internet, or it can be placed on a perimeter network that is behind a firewall or NAT router. If the IP address or DNS name of the destination server changes as part of the migration, or after the migration is completed, then the mappings in the firewall or NAT device must be reconfigured to point to the correct address or name. You must also update any intranet or Internet DNS servers with the new name and IP address. Also, remember to provide information about any server name or IP address changes to your users so that they can connect to the correct server. If you use connection profiles that are created by using the Connection Manager Administration Kit, then deploy a new profile with the updated server address information.

We recommend that you advertise the expected date and time of the migration so that users can plan accordingly, and make other arrangements as needed.

Permissions required to complete migration

The following permissions are required on the source server and the destination Remote Access servers:

• Domain user rights are required join the new server to the domain.

• Local administrative rights are required to install and manage the Remote Access role.

• Equivalent administrator permissions for DirectAccess GPOs as were configured on the source computer.

• Write permissions are required to the migration store location. For more information, see Remote Access: Prepare to Migrate in this guide.

Estimated duration

The migration can take two to three hours, including testing.

See Also

Remote Access: Prepare to Migrate Remote Access: Migrate Remote Access Remote Access: Verify the Migration Remote Access: Post-migration Tasks