Partager via

RRAS Migration: Migrating Routing and Remote Access Service

  • Article

Updated: February 11, 2010

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2

Complete the following procedures to migrate the Routing and Remote Access service from a source server to a destination server.

  • Migrating the Routing and Remote Access service from the source server

  • Migrating Routing and Remote Access service to the destination server

  • Completing the required manual migration steps

Membership in the local Administrators group or equivalent is the minimum required to complete these procedures. If User Account Control (UAC) is enabled, you might have to run the following steps by using the Run as administrator option. For more information, see Run a program with administrative credentials in the Windows Server TechCenter (https://go.microsoft.com/fwlink/?LinkId=131210).

If NPS is used for authentication, accounting, and policy management

If your RRAS server uses a Network Policy Server (NPS) for authentication, accounting, or policy management, instead of the Windows security account database, and if NPS must also be migrated to a new computer running Windows Server 2008 R2, then use the Network Policy Server Migration Guide (https://go.microsoft.com/fwlink/?linkid=159109).

Important

Migrate your NPS before you migrate the RRAS server.

Migrating the Routing and Remote Access service from the source server

Follow these steps to capture the configuration of Routing and Remote Access service on the source server.

To capture the Routing and Remote Access service configuration

  1. On the source server, open a Windows PowerShell session with elevated user rights.

  2. Load Windows Server Migration Tools into your Windows PowerShell session.

Note

If you opened the current Windows PowerShell session by using the Windows Server Migration Tools shortcut on the Start menu, skip this step and go to the next step. You should only load the Windows Server Migration Tools snap-in in a Windows PowerShell session that was opened by using another method, and into which the snap-in has not already been loaded. 

To load Windows Server Migration Tools, run the following cmdlet:

    Add-PSSnapin Microsoft.Windows.ServerManager.Migration

  1. RRAS can be running on the source server while you are capturing its configuration. However, if you made configuration changes to RRAS that require a service restart, then you must stop RRAS before starting the migration. Use the following PowerShell command to stop the service:

    stop-service remoteaccess -force

Note

You must use the -force parameter because RRAS has dependent services. 

To verify that the service is stopped, run the following command:

    get-service remoteaccess

  1. On the source server, from Windows PowerShell, collect the settings from the source server by running the Export-SmigServerSetting cmdlet as an administrator. The following is the syntax for the cmdlet:

    Export-SmigServerSetting -featureID NPAS-RRAS -User All -Group -path StorePath -verbose

    The Export-SmigServerSetting cmdlet parameters can collect all Routing and Remote Access service settings on the source server in a single file (Svrmig.mig). Before you run this command, review the following:

    • When you run the Export-SmigServerSetting command, you are prompted to provide a password to encrypt the migration store data. You must provide this same password when you later import from the migration store. Make sure you provide a strong password to encrypt the migration data and that the location of the migration data file is secure.

    • The StorePath variable that is provided as the value of the path parameter can be an empty or nonempty folder. The actual data file that is placed in the folder (Svrmig.mig) is created by the Export-SmigServerSetting cmdlet. Do not specify a file name. If a migration data file already exists and you want to rerun the Export-SmigServerSetting cmdlet, you must first move the Svrmig.mig file from that location and store it elsewhere, rename it, or delete it.

    • If the path is not a shared location that the destination server can access, you must manually copy the migration store to the destination server or to a location that the destination server can access.

    • Migrating users and groups can be combined with the cmdlets that are used to migrate RRAS. The -Users and -Group parameters can be used in the Export-SmigServerSetting command to migrate the user and group accounts that are present locally on the RRAS source server. If you are using an Active Directory domain or RADIUS for authentication, then these parameters are not needed.

      The -Users command supports the following parameters:

      • All. All user accounts on the source server are included in the migration output file.

      • Enabled. Only enabled user accounts on the source server are included in the migration output file.

      • Disabled. Only disabled user accounts on the source server are included in the migration output file.

      To prevent migrating any user accounts, do not include the -Users parameter in the command.

      The -Group command takes no additional parameters. If it is present, then all groups defined locally on the source server are included in the migration output file.

Note

The process described in the Local User and Group Migration Guide does not migrate some settings, including those under the Dial-in tab. We recommend that you thoroughly review the Local User and Group Migration Guide to understand which settings are migrated and which are not.

Migrating Routing and Remote Access service to the destination server

Return to the destination server, and use the following procedure to complete the migration:

To import the Routing and Remote Access service configuration to the destination server

  1. Before you use the Import-SmigServerSetting cmdlet to import the Routing and Remote Access service settings, be aware of the following condition:

    • If you chose to migrate the users and groups on the source computer, you need to specify the -User and -Group parameters in the Import-SmigServerSetting cmdlet on the destination server.

  2. On the destination server, open a Windows PowerShell session with elevated user rights.

  3. Load Windows Server Migration Tools into your Windows PowerShell session.

Note

If you opened the current Windows PowerShell session by using the Windows Server Migration Tools shortcut on the Start menu, skip this step and go to the next step. You should only load the Windows Server Migration Tools snap-in in a Windows PowerShell session that was opened by using another method, and into which the snap-in has not already been loaded. 

To load Windows Server Migration Tools, run the following cmdlet:

    Add-PSSnapin Microsoft.Windows.ServerManager.Migration

  1. On the destination server, from Windows PowerShell, run the following command, where StorePath is the folder that contains the Svrmig.mig file that you exported from the source server. Do not include the name of the file in the path.

    Import-SmigServerSetting -featureid NPAS-RRAS -User All -Group -Force -path StorePath -Verbose

    For more information about running the Import-SmigServerSetting cmdlet, see the “Using Windows Server Migration Tools” section in the Windows Server Migration Tools Installation, Access, and Removal step-by-step guide in the Windows Server Technical Library (https://go.microsoft.com/fwlink/?LinkID=155112).

  2. Before starting the RRAS service, you must manually stop the RASMAN service. Run the following command in the Windows PowerShell Command Prompt window:

    Stop-service -force rasman

  3. Then run the following command in the Windows PowerShell Command Prompt window to start the Routing and Remote Access service:

    Start-Service RemoteAccess

If a failure occurs while running the Import-SmigServerSetting cmdlet, review the Setupact.log, Setuperr.log, and ServerMigration.log files under %localappdata%\SvrMig\Log. Information about how the RRAS components migrated is included in the Servermigration.log file.

After the script completes, review the following section and adjust any remaining settings that require manual configuration.

Completing the required manual migration steps

Certain settings cannot be migrated by the Windows PowerShell scripts, and they must be configured manually on the destination server. Review the following configuration options, and apply those that are relevant to your environment.

Dial-up demand-dial connections

Because of the differences in modem hardware that might exist between the source and destination servers, dial-up connections are not migrated. Use the Demand-Dial Interface Wizard in the RRAS MMC snap-in.

To create a dial-up demand-dial connection

  1. If you are using Server Manager, in the navigation pane, expand Roles, expand Network Policy and Access Services, and then expand Routing and Remote Access.

  2. Right-click Network Interfaces, and then click New Demand-dial Interface.

  3. Follow the steps in the wizard to configure the connection.

Certificates for IKEv2, SSTP, and L2TP/IPsec connections

Certificates can be exported from the source server and imported to the destination server by using the Certificates MMC snap-in.

SSL certificate binding for SSTP VPN connections

The selection of a specific certificate to be used for SSTP connections is not migrated by the scripts. You must first import and install the certificate to the destination server. Then in the RRAS MMC snap-in, select the certificate to be used by SSTP.

To select the certificate for SSTP

  1. If you are using Server Manager, in the navigation pane, expand Roles, and then expand Network Policy and Access Services.

  2. Right-click Routing and Remote Access, and then click Properties.

  3. On the Security tab, under SSL Certificate Binding, select the certificate that you want to use, and then click OK.

Routing and Remote Access service policies and accounting settings

If you are not using a local or remote server to run NPS, then default remote access policies and accounting settings are automatically created on the destination server when RRAS is configured.

To migrate NPS settings refer to the NPS Migration Guide (https://go.microsoft.com/fwlink/?linkid=159109), specifically the Migrating server settings section under Migrating the NPS Role. There are separate sections for Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2.

PEAP, smart card, and other certificate settings on Network Policy Server

If you also migrated a local or remote server running NPS to support the RRAS server that you are migrating, we recommend that you verify that the server that is running NPS has the correct certificate configuration. Specifically, confirm that any certificates that are associated with Protected Extensible Authentication Protocol (PEAP) and the Smart card or other certificate authentication settings are set properly. You can find these settings on the server that is running NPS, in the NPS MMC snap-in under Connection Request Policies or Network Policies (depending on where the authentication protocols are configured). If no certificates are present, or if the certificates are not configured correctly, perform the following steps:

To reconfigure PEAP or smart card certificates

  1. Remove the PEAP or SmartCard or other certificate methods from the list of authentication methods.

  2. Add the method back to the list.

  3. Reconfigure the certificate for the specified method.

Weak encryption settings

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. For more information about the registry entries that RRAS adds, see “Registry entries that Routing and Remote Access adds in Windows Server 2008”, article 947054 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?linkid=159112). The description of the settings for the weak encryption settings are at the end of the article, and they are named AllowPPTPWeakCrypto and AllowL2TPWeakCrypto.

Security Note
Weak encryption includes the use of 40-bit or 56-bit encryption in PPTP, and the use of MD5 or DES for L2TP/IPsec. By default, these weak algorithms are disabled, and we recommend that you do not use them unless they are required.

Connection Manager profiles

Profiles that are created by the Connection Manager Administration Kit (CMAK) can only be created on a computer with the same 32-bit or 64-bit architecture as the client computer on which they are to be run. If your source server is 64-bit, and you have created 64-bit profiles on that source server, you can copy them from the %PROGRAMFILES%\CMAK\Profiles folder to the appropriate folder on the destination server. You can manage them there by using CMAK, as follows:

  • Profiles that are created for computers running Windows Server 2003 or Windows XP should be placed in the folder %PROGRAMFILES%\CMAK\Profiles\Previous release.

  • Profiles that are created for computers running Windows Vista or Windows® 7 should be placed in the folder %PROGRAMFILES%\CMAK\Profiles\Windows 7 and Windows Vista.

If the source server is 32-bit, you must use a computer running a 32-bit version of Windows to create and manage the profiles. You can set up a computer running a 32-bit version of Windows 7, and then install CMAK on it to manage the profiles for your 32-bit client computers. For more information, see Connection Manager Administration Kit in the Windows Server Technical Library (https://go.microsoft.com/fwlink/?linkid=136440).

Group forwarded fragments

The Group Forwarded Fragments setting on NAT is enabled if the RRAS server is deployed behind a NAT device that runs Windows. This is required for L2TP/IPsec connections that are using computer certificate authentication to succeed. We recommend that you enable this setting. Group Forwarded Fragments can be enabled for IPv4 on the Windows NAT computer by running the following command at the command prompt:

netsh int ipv4 set global groupforwardfragments=enabled

RAS administration and security DLLs

Administration DLLs and security DLLs and their corresponding registry keys are not migrated. This is because they are available in both 32-bit and 64-bit versions, and they do not work in a 32-bit to 64-bit migration. If the source and destination computers are 64-bit, the administration and security DLLs can be reused. For more information, refer to the following topics:

RAS Administration DLL (https://go.microsoft.com/fwlink/?linkid=163778)

RAS Security DLL (https://go.microsoft.com/fwlink/?linkid=163779)

Next topic: RRAS Migration: Verifying the Migration

See Also

Concepts

Routing and Remote Access Service Migration Guide
RRAS Migration: Preparing to Migrate
RRAS Migration: Verifying the Migration
RRAS Migration: Performing Post-Migration Tasks