Migrar el acceso remoto a Windows Server 2012

Se aplica a: Windows Server 2012

El servicio de enrutamiento y acceso remoto (RRAS) era un servicio de rol de los sistemas operativos Windows Server anteriores a Windows Server 2012 que permitía usar un equipo como enrutador IPv4 o IPv6, como enrutador de traducción de direcciones de red (NAT) IPv4 o como servidor de acceso remoto que hospedaba conexiones de acceso telefónico o de red privada virtual (VPN) desde clientes remotos. Ahora se ha combinado esta característica con DirectAccess para conformar el rol de servidor de acceso remoto en Windows Server 2012. En esta guía se describe cómo migrar un servidor que hospeda el servicio de enrutamiento y acceso remoto (en Windows Server 2008 R2 y otras versiones de nivel inferior) a un equipo que ejecuta Windows Server 2012.

Acerca de esta guía

La documentación y las herramientas de migración simplifican la migración de la configuración de roles de servidor y los datos desde un servidor existente a un servidor de destino que está ejecutando Windows Server 2012. El uso de las herramientas que se describen en esta guía puede simplificar el proceso de migración, reducir el tiempo de migración, aumentar la precisión del proceso de migración y contribuir a eliminar los posibles conflictos que, de otro modo, podrían producirse durante este proceso. Para obtener más información sobre la instalación y uso de las herramientas de migración en los servidores de origen y destino, consulta la Guía de instalación, acceso y eliminación de Herramientas de migración de Windows Server (https://go.microsoft.com/fwlink/?LinkId=247607).

Destinatarios

Este documento está dirigido a los administradores de tecnología de la información (TI), profesionales de TI y otros trabajadores del conocimiento que son responsables del funcionamiento y la implementación de servidores de acceso remoto en un entorno administrado. Puede ser necesario tener conocimientos de creación de scripts para realizar algunos de los pasos de migración incluidos en esta guía.

Qué no incluye esta guía

En esta guía no se describe la arquitectura o la funcionalidad detallada del rol de acceso remoto. Los escenarios siguientes no se contemplan en esta guía de migración:

• Los procesos de actualización en contexto, en los que el nuevo sistema operativo se instala en el hardware de servidor existente utilizando la opción Upgrade durante la instalación.

• Escenarios de clúster y multisitio

• Migración de más de un rol de servidor

  Si el servidor ejecuta varios roles, se recomienda que diseñe un procedimiento de migración personalizado específico para el entorno del servidor, basado en la información que se proporciona en esta guía y en otras guías de migración de roles.

Escenarios de migración compatibles

En esta guía se proporcionan instrucciones para migrar un servidor existente a un servidor que ejecuta Windows Server 2012.

Sistemas operativos compatibles

En esta guía se proporcionan las instrucciones para migrar los datos y configuración desde un servidor existente que se está reemplazando por un nuevo servidor físico o virtual 64 bits con un sistema operativo limpio instalado, tal y como se describe en la siguiente tabla.

• Las versiones de los sistemas operativos que se muestran en la tabla anterior corresponden a las combinaciones de sistemas operativos y Service Packs más antiguos que se admiten. Se admiten los Service Pack más nuevos.

• No se admite la migración con un servidor de destino que ya tenga DirectAccess configurado.

• Las ediciones Foundation, Standard, Enterprise y Datacenter del sistema operativo Windows Server se admiten como servidores de origen o de destino. Esto incluye la migración entre ediciones. Por ejemplo, puede migrar desde un servidor que ejecute Windows Server 2003 Standard a un servidor que ejecute Windows Server 2012.

• Se admiten las migraciones entre sistemas operativos físicos y virtuales.

• No se admite la migración de un servidor de origen a uno de destino que ejecute un sistema operativo en un idioma de interfaz de usuario del sistema (es decir, el idioma instalado) distinto al del servidor de origen. Por ejemplo, no puede usar Herramientas de migración de Windows Server para migrar los roles, configuración del sistema operativo, datos o recursos compartidos desde un equipo que ejecute Windows Server 2008 R2 con la interfaz de usuario del sistema en francés a un equipo que ejecute Windows Server 2012 con la interfaz de usuario del sistema en alemán.

  Nota

  El idioma de la interfaz de usuario del sistema es el idioma del paquete de instalación localizada que se usó para instalar el sistema operativo Windows.

• Tanto la migración basada en x86 como la basada en x64 se admiten en Windows Server 2003 y Windows Server 2008. Todas las ediciones de Windows Server 2008 R2 y Windows Server 2012 se basan en x64.

Configuraciones de rol compatibles

A continuación se muestra una lista de escenarios de migración que se admiten para el acceso remoto. En estos escenarios se migra toda la configuración.

• DirectAccess (admitido solo en la migración de Windows Server 2012 a Windows Server 2012)

• Servidor VPN

• Servidor de acceso telefónico

• Traducción de direcciones de red (NAT)

• Enrutamiento, con los siguientes componentes opcionales:

  • Agente de retransmisión DHCP

  • Protocolo de información de enrutamiento (RIP)

  • Protocolo de administración de grupos de Internet (IGMP)

Además de los escenarios anteriores, la migración también ajusta automáticamente la configuración del servidor de destino para responder a las características que ya no se admiten y admitir las características que son nuevas en Windows Server 2012 y no se admitían en versiones anteriores de Windows.

Dependencias de migración

Si se debe migrar también un servidor NPS local o remoto que se usa para la autenticación, la contabilización de cuentas o la administración de directivas, migre el servicio NPS antes de migrar Acceso remoto. Para obtener más información, consulte Migrar Servidor de directivas de redes a Windows Server 2012.

Si está actualizando de Windows 2008 R2 DirectAccess a Windows Server 2012, asegúrese de que todos los parámetros de configuración de DirectAccess se hayan aplicado en el servidor de Windows 2008 R2. Es posible guardar los parámetros de configuración a través de la consola, pero no aplicarlos. Antes de actualizar, asegúrese de que los parámetros de configuración guardados también se hayan aplicado.

Componentes de migración que no se admiten en todas las versiones de sistemas operativos

Los siguientes componentes de acceso remoto no son compatibles con todos los sistemas operativos:

Componentes de migración que no se migran automáticamente

Los cmdlets de Windows PowerShell que se proporcionan con las Herramientas de migración de Windows Server no migran los siguientes elementos y configuraciones de acceso remoto. En su lugar, el elemento o configuración debe configurarse manualmente en el nuevo servidor RRAS, tal y como se describe en la sección Completar los pasos de migración manuales necesarios de esta guía.

• Enlaces de certificado SSL. La configuración del enlace de certificado SSL y crypto-binding para SSTP se migra de la siguiente manera:

  1. El asistente para migración busca un certificado de origen en el equipo de destino. Si encuentra uno, SSTP usará ese certificado.

  2. Si no lo encuentra, el asistente para migración buscará un certificado válido con la misma raíz de confianza que la del certificado de origen.

  3. Si aún así no encuentra un certificado, entonces la configuración de SSTP en el equipo de destino será la "Predeterminada".

  4. Si se usan certificados autofirmados (válidos para Windows Server 2012), se crearán automáticamente en la carpeta de destino.

• Cuentas de usuario en el servidor RRAS local. Si usa las cuentas de usuario y grupo basadas en el dominio y los servidores RRAS anteriores y nuevos forman parte del mismo dominio, no se requiere ninguna migración de las cuentas. Se pueden usar las cuentas de usuario local si está configurada la Autenticación de Windows en el servidor de origen de RRAS.

• Solo enrutamiento/VPN/DirectAccess cuando están todos instalados. Si la configuración del servidor de acceso remoto incluye todos los servicios disponibles, todos los servicios se migrarán juntos. La migración de solo uno de los servicios al servidor de destino no se admite.

• Un servidor local o remoto que está ejecutando el Servidor de directivas de redes (NPS) que proporciona autenticación, contabilización de cuentas y administración de directivas. En esta guía no se incluyen los pasos necesarios para migrar un servidor que está ejecutando NPS. Para migrar un servidor que ejecuta NPS, usa Migrar Servidor de directivas de redes a Windows Server 2012. La migración de NPS se debería realizar cuando se indique más adelante en esta guía.

  Nota

  Si no usa un servidor que esté ejecutando NPS, no se migra la configuración predeterminada de directivas de acceso remoto y contabilización de cuentas que se crean automáticamente al configurar RRAS.

• Conexiones de acceso telefónico de marcado a petición. El servidor de destino podría tener módems diferentes y hay muchas configuraciones de marcado a petición que son específicas del módem o dispositivo ISDN seleccionado.

• Certificados utilizados para autenticar las conexiones IKEv2, SSTP y L2TP/IPsec.

• Enlace de certificado SSL para SSTP cuando la casilla Usar HTTP no está activada.

• Conexiones VPN de IKEv2 que usan adaptadores de red IPv6. IKEv2 se admite en los servidores RRAS que solo están ejecutando Windows Server 2008 R2. En Microsoft Management Console (MMC) de RRAS en Windows Server 2008 R2, puede especificar la interfaz de red utilizada para adquirir las direcciones IPV6 DHCP y DNS que se usan para los clientes VPN de IKEv2. Si migra RRAS desde Windows Server 2008 R2 a otro servidor que ejecuta Windows Server 2008 R2, se migra la configuración. Sin embargo, si migra desde una versión de Windows anterior, no hay ninguna configuración para migrar y se usa el valor predeterminado de Permitir que RAS seleccione el adaptador.

• Cifrado débil. En Windows Server 2003 está habilitado el cifrado débil, pero en las versiones posteriores de Windows está deshabilitado de manera predeterminada. Solo puede habilitar el cifrado débil si modifica el Registro. Durante la migración de Windows Server 2003, el proceso de migración no crea en el nuevo servidor la configuración del Registro requerida, que se debe configurar manualmente. En las versiones posteriores de Windows, esta configuración del Registro se migra si está presente.

• DLL de administración y DLL de seguridad y sus claves del Registro correspondientes. Estas DLL están disponibles en las versiones de 32 bits y 64 bits, y no funcionan en una migración de 32 bits a 64 bits.

• DLL personalizadas utilizadas para marcar una conexión de marcado a petición. Estas DLL están disponibles en las versiones de 32 bits y 64 bits, y no funcionan en una migración de 32 bits a 64 bits. Tampoco se migra ninguna configuración del Registro correspondiente.

• Perfiles del Admistrador de conexiones. El kit de Administración de Connection Manager se usa para crear perfiles de acceso remoto telefónico y VPN. Los perfiles creados están almacenados en carpetas concretas en el servidor RRAS. Los perfiles que se crean en una versión de 32 bits de Windows no funcionan en los equipos que están ejecutando una versión de 64 bits de Windows y viceversa. Para obtener más información sobre los perfiles de conexión, consulta el Kit de administración de Connection Manager (https://go.microsoft.com/fwlink/?linkid=55986).

• Configuración de fragmentos reenviados de grupo en NAT. Esta configuración está habilitada si el servidor RRAS se implementa detrás de un enrutador de NAT que se ejecuta en el sistema operativo Windows. Esto es necesario para establecer correctamente las conexiones L2TP/IPsec que usan la autenticación del certificado de equipo. Se recomienda que habilite este valor para evitar un problema conocido en RRAS.

• La opción de configuración Registrar información adicional de Enrutamiento y acceso remoto (utilizada para depuración) del cuadro de diálogo Propiedades de Enrutamiento y acceso remoto de la pestaña Registro.

Información general del proceso de migración del servicio de enrutamiento y acceso remoto

El proceso previo a la migración implica la recopilación manual de datos, seguida de la ejecución de procedimientos en los servidores de origen y destino. El proceso de migración incluye procedimientos de servidor de origen y destino que usan los cmdlets Export y Import para recopilar, almacenar y migrar automáticamente la configuración del rol de servidor. Los procedimientos posteriores a la migración incluyen la comprobación de que el servidor de destino reemplazó correctamente el servidor de origen y, a continuación, lo retiró o reasignó. Si el procedimiento de comprobación indica que se produjo un error en la migración, comienza la solución de problemas. Si la solución de problemas no obtiene resultados, se proporcionan instrucciones de recuperación para devolver la red al uso del servidor de origen inicial.

Impacto de la migración

Durante la migración, el servidor de acceso remoto no está disponible para aceptar conexiones entrantes ni para enrutar el tráfico.

• Los nuevos clientes remotos no pueden conectarse al servidor mediante conexiones de acceso telefónico, VPN o DirectAccess. Las conexiones existentes en el servidor están desconectadas. Si hay varios servidores de acceso remoto, la pérdida de disponibilidad de este servidor produce una reducción en la capacidad hasta que el nuevo servidor esté de nuevo operativo. Para las conexiones de marcado a petición, se debe proporcionar una conectividad alternativa entre las oficinas o volver a configurar las conexiones que señalen a un servidor alternativo.

• Las funcionalidades de enrutamiento y NAT no están disponibles. Si la funcionalidad se requiere durante la migración, se puede implementar un enrutador alternativo hasta que el nuevo servidor de destino esté disponible.

Entre los impactos posteriores a la migración se incluyen los siguientes:

• Si piensa reutilizar el nombre del servidor de origen como nombre del servidor de destino, el nombre se puede configurar en el servidor de destino cuando el servidor de origen esté desconectado de la red. De lo contrario, se produce un conflicto de nombres que puede afectar a la disponibilidad. Si piensa ejecutar ambos servidores, se debe proporcionar un nombre único al servidor de destino.

• Un servidor VPN puede estar conectado directamente a Internet o se puede colocar en una red perimetral que está detrás de un firewall o enrutador de NAT. Si la dirección IP o el nombre DNS del servidor de destino cambian como parte de la migración, o una vez finalizada la migración,las asignaciones del firewall o del dispositivo NAT deben configurarse de nuevo para que señalen a la dirección o nombre correctos. También se debe actualizar cualquier servidor DNS de intranet o de Internet con el nombre y dirección IP nuevos. También, recuerde proporcionar información sobre cualquier cambio de nombre del servidor o dirección IP a los usuarios para que puedan conectarse al servidor correcto. Si usa los perfiles de conexión creados mediante el kit de administración de Connection Manager,implemente un nuevo perfil con la información de la dirección de servidor actualizada.

Se recomienda que anuncie la fecha y hora prevista de la migración para que los usuarios puedan planear en consecuencia, y realice cualquier otra disposición necesaria.

Permisos necesarios para completar la migración

Se requieren los siguientes permisos en el servidor de origen y los servidores de acceso remoto de destino:

• Se requieren permisos de usuario de dominio para unir el nuevo servidor al dominio.

• Se requieren permisos administrativos locales para instalar y administrar el rol de acceso remoto.

• Permisos de administrador equivalentes para los GPO de DirectAccess, tal como se configuraron en el equipo de origen.

• Se requieren permisos de escritura en la ubicación del almacén de migración. Para obtener más información, consulta Acceso remoto: preparación de la migración en esta guía.

Duración estimada

La migración puede tardar entre dos y tres horas, incluidas las pruebas.

Vea también

Acceso remoto: preparación de la migración
Acceso remoto: migración de acceso remoto
Acceso remoto: comprobación de la migración
Acceso remoto: tareas posteriores a la migración