Routing and Remote Access Service Migration Guide
Updated: February 11, 2010
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2
Routing and Remote Access service (RRAS) is a feature in the Windows Server® operating systems that enables 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 hosts dial-up or virtual private network (VPN) connections from remote clients. This guide describes how to migrate a server that is hosting the Routing and Remote Access service to a computer that is running Windows Server 2008 R2. Migration involves moving current Routing and Remote Access service data and registry settings from a source server to a destination server.
Note
Your detailed feedback is very important, and it helps us to make Windows Server Migration Guides as reliable, complete, and easy to use as possible. Please take a moment to rate this topic by clicking the stars in the upper-right corner of the page (1=poor, 5=excellent), and then add comments that support your rating. Describe what you liked, did not like, or want to see in future versions of the topic.
To submit additional suggestions about how to improve migration guides or utilities, you can post your comments on the Windows Server Migration forum (https://go.microsoft.com/fwlink/?LinkId=181228), or you can send an e-mail message with your comments and suggestions to Routing and Remote Access Documentation Feedback (rrasdoc@microsoft.com). The author of the guide will review your comments and use them to improve this documentation. Your e-mail address is not saved or used for any other purposes.
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 2008 R2. 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=134763).
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 RRAS 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 RRAS service. 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 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. Migration guides for additional roles are available at Migrate Server Roles to Windows Server 2008 R2 in the Windows Server 2008 R2 TechCenter (https://go.microsoft.com/fwlink/?LinkID=128554).
Supported migration scenarios
This guide provides instructions for migrating an existing server that is hosting the Routing and Remote Access service to a server that is running Windows Server 2008 R2.
Warning
This guide does not contain instructions for migration when the source server is running multiple roles. If your source server is running multiple roles, some migration steps in this guide, such as those for migrating user accounts and network interface names, can cause other roles that are running on the source server to fail.
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.
Note
All of the options in the table refer to a full installation of the Windows Server operating system because the Routing and Remote Access service does not currently support the Server Core installation option.
| Source server processor | Source server operating system | Destination server operating system | Destination server processor |
|---|---|---|---|
x86- or x64-based |
Windows Server 2003 with Service Pack 2 |
Windows Server 2008 R2, full installation option |
x64-based |
x86- or x64-based |
Windows Server 2003 R2 |
Windows Server 2008 R2, full installation option |
x64-based |
x86- or x64-based |
Windows Server 2008, full installation option only |
Windows Server 2008 R2, full installation option only |
x64-based |
x64-based |
Windows Server 2008 R2, full installation option only |
Windows Server 2008 R2, full installation option only |
x64-based |
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.
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 2008 R2 Enterprise. The Server Core installation option is not supported because the RRAS service is not available in that edition.
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 in the French system UI language to a computer that is running Windows Server 2008 R2 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 are x64-based.
Supported role configurations
The following is a broad list of the migration scenarios that are supported for the Routing and Remote Access service. All settings under these scenarios are migrated.
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 2008 R2 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 RRAS. For more information, see the Network Policy Service Migration Guide in the Windows Server TechCenter (https://go.microsoft.com/fwlink/?linkid=159109).
Migration components that are not automatically migrated
The following RRAS 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.
Important
Perform the manual configuration of these elements only when directed later in this guide.
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 the routing service or only the remote access service when both are installed. If your RRAS server configuration includes both of the available services (the routing service and the remote access service), then both 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 the NPS Migration Guide in the Windows Server TechCenter (https://go.microsoft.com/fwlink/?linkid=159109). 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 64bit 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 following illustration shows that 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.
.gif)
Impact of migration
During migration, the RRAS server is not available to accept incoming connections or to route traffic.
New remote clients cannot connect to the server by using dial-up or VPN 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. For more information, see Completing Migration later in this guide.
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 RRAS servers:
Domain administrative rights are required join the new server to the domain.
Local administrative rights are required to install and manage the Routing and Remote Access service.
Write permissions are required to the migration store location. For more information, see RRAS Migration: Preparing to Migrate in this guide.
Estimated duration
The migration can take two to three hours, including testing.
Next topic: RRAS Migration: Preparing to Migrate
See Also
Concepts
RRAS Migration: Preparing to Migrate
RRAS Migration: Migrating Routing and Remote Access Service
RRAS Migration: Verifying the Migration
RRAS Migration: Performing Post-Migration Tasks