Prepárese para el fin de la vida de Windows Server 2008

Migrar a la nube de Azure

Una forma de hacer frente al fin de la vida útil de Windows Server 2008 es migrar máquinas virtuales a la nube de Azure. Microsoft está incentivando esta opción al permitir que las máquinas virtuales migradas ejecuten Windows Server 2008 o 2008 R2. Los administradores que migren sus máquinas virtuales de Windows Server 2008 o 2008 R2 a Microsoft Azure recibirán tres años adicionales de actualizaciones de seguridad. Estas actualizaciones no están disponibles para máquinas virtuales que se ejecutan en las instalaciones.

La migración de máquinas virtuales de Windows Server 2008 o 2008 R2 a Azure es un proceso relativamente fácil. Primero, los administradores deben asegurarse de que sus máquinas virtuales ejecuten Windows Server 2008 SP2 o posterior. A continuación, los administradores deben configurar máquinas virtuales para habilitar la administración remota, desde cualquier versión de Remote Desktop Services, y deben abrir el puerto 3389 en el firewall de Windows. Una vez que los administradores completen esto, deben configurar las contraseñas de la máquina virtual para que nunca caduquen. Finalmente, los administradores pueden cargar el archivo del disco duro virtual de la máquina virtual en Microsoft Azure. Microsoft proporciona instrucciones paso a paso para todo el proceso.

Actualice el sistema operativo Windows

Si los administradores desean mantener sus máquinas virtuales en funcionamiento en las instalaciones, su mejor opción es actualizar a un sistema operativo más nuevo. Cuando se trata de actualizaciones del sistema operativo, Microsoft generalmente recomienda que los administradores creen una nueva máquina virtual que ejecute el nuevo sistema operativo y luego migren sus cargas de trabajo de la vieja máquina virtual a la nueva máquina virtual.

Este enfoque ayuda a garantizar la seguridad y la estabilidad porque la carga de trabajo se ejecuta sobre un sistema operativo que los administradores instalan limpiamente. La transición de las cargas de trabajo a una nueva VM también ofrece a los administradores la opción de usar una configuración de almacenamiento diferente o adoptar el Sistema de Archivos Resiliente.

A veces es necesario realizar una actualización del sistema operativo en el lugar sobre una máquina virtual existente, en lugar de crear una nueva máquina virtual y migrar las cargas de trabajo. Esto es especialmente cierto cuando una aplicación que se ejecuta en una VM heredada no se puede reinstalar fácilmente en una nueva VM. Por ejemplo, los administradores pueden requerir una actualización en el lugar si ya no tienen acceso a los archivos de instalación de una aplicación o si agotaron todas las activaciones de la licencia de la aplicación.

Si los administradores deciden realizar una actualización in situ, su ruta de actualización puede variar según la versión de Windows Server que adopten. Por ejemplo, los administradores no pueden actualizar directamente de Windows Server 2008 a Windows Server 2016. Sin embargo, los administradores pueden actualizar a Windows Server 2012 R2 y luego a Windows Server 2016.

Los administradores tampoco pueden cambiar las arquitecturas del sistema, como 32 bits y 64 bits durante una actualización en el lugar, ni pueden cambiar el idioma del sistema operativo.

Los administradores deben entender que Microsoft eliminó la opción de cambiar de Server Core a la experiencia GUI completa en Windows Server 2016. Esto significa que si una VM está ejecutando Server Core actualmente y los administradores desean cambiar al modo GUI, o al revés, deben actualizar la VM a Windows Server 2012 R2, cambiar al modo que desean usar y luego continuar con una actualización a Windows Server 2016 o posterior.

Independientemente de si los administradores deciden migrar sus máquinas virtuales de Windows Server 2008 y 2008 R2 a la nube de Azure o realizar una actualización in situ, es fundamental hacer una copia de seguridad de las máquinas virtuales de antemano. Esto le da a los administradores una forma de volver a poner todo de la forma en que estaba en caso de que algo salga mal. Cuando sea posible, también es una buena idea ensayar las actualizaciones en un entorno de espacio aislado antes de intentar una actualización de la VM de producción.