Una de las preguntas que me realizan alumnos y lectores de mis libros sobre administración de sistemas informáticos es una lista de los temas a tener en cuenta para parchear Exchange Server.
Así que como continuación del libro EX2013ADM - Exchange Server 2013, encontrareis este post sobre el parcheado de Exchange.
Para los que no dispongáis del libro EX2013ADM - Exchange Server 2013, podéis consultar su índice y referencias en el apartado: "Índice y referencias libros" de este blog.
De hecho, muchos administradores de sistemas parchean Exchange y todo continua funcionando sin problemas.
Sin embargo, al tratarse de un servicio crítico, es buena idea tomar una serie de precauciones en el momento de parchear.
Parchear Exchange es sumamente importante, ya que resuelve muchos problemas no solo de seguridad si no que también de funcionalidad.
Veamos la lista de puntos a tener en cuenta:
1) Entender que los parches de Exchange corrigen problemas de funcionalidad:
En otros productos de Microsoft como Windows Server, al cabo del tiempo, los elementos que corrigen son fundamentalmente problemas de seguridad y no de funcionalidad.
Este no es el caso de los parches de Exchange.
Veamos un ejemplo:
Repasamos los errores que corrige un Update Rollup 6 para Exchange Server 2010 SP3 (publicado en 23/5/2014):
Update Rollup 6 for Exchange Server 2010 Service Pack 3 (microsoft.com)
Al repasar la lista de correcciones, veremos que principalmente se corrigen problemas de funcionalidad.
2) Entender el funcionamiento de los parches:
Para Exchange Server 2007 / Exchange Server 2010:
Los parches vienen en forma de Update Rollups y Service Pack.
Los Update Rollups, son actualizaciones acumulativas: por ejemplo: Update Rollup 4, incluye todas las correcciones de Update Rollup 1,2 y 3.
Los Update Rollups, funcionan sobre una rama de Service Pack o versión RTM, es decir, Update Rollup 4 for Exchange Server 2010 SP2, no es lo mismo que Update Rollup 4 for Exchange Server 2010 SP3.
En la siguiente imagen, podemos ver un ejemplo:
* No es el mismo fichero: Update Rollup 4 sobre Exchange 2010 SP2 que Update Rollup 4 sobre Exchange 2010 SP3
Los Service Pack, también realizan cambios en la funcionalidad del producto, no solo corrigen errores.
En la fecha de salida de un Service Pack, este corrige todos los errores de Service Pack y Update Rollups publicados con anterioridad.
Los Update Rollups, no substituyen todos los binarios de Exchange Server, solo substituyen algunos de ellos.
Con el fichero descargado de un Service Pack, podríamos realizar una instalación nueva de Exchange: Esta ya integraría el Service Pack.
Para Exchange Server 2013:
Los parches vienen el forma de Cumulative update y Service Pack.
Tanto los Cumulative Update como Service Pack son paquetes de parches que incluyen todos los binarios de Exchange.
La única diferencia entre Service Pack y Cumulative Update es que mientras los Cumulative Update solo corrigen errores, los Service Pack también añaden funcionalidades nuevas.
En los siguientes enlaces podemos ver ejemplos acerca de funcionalidades nuevas introducidas en Service Pack 1 para Exchange Server 2013:
Con el fichero
descargado de un Service Pack o Cumulative Update, podríamos realizar una instalación nueva
de Exchange: Esta ya integraría el Service Pack o Cumulative Update.
3) Situarse donde estamos:
Debemos averiguar la versión de Exchange tenemos, su nivel de parches y cuales le faltan.
Para ver la versión y compilación de nuestro Exchange, basta con ejecutar desde la Exchange Management Shell:
Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion
Este cmd-let, funcionará con Exchange Server 2007, 2010 y 2013.
Para revisar los parches publicados, debemos consultar el siguiente enlace:
Veamos el siguiente ejemplo:
Imaginemos que nuestra versión de compilación sobre Exchange 2010 es la siguiente: 14.03.0181.006
Si analizamos la tabla anterior, podemos ver que: 14 corresponde a Exchange 2010, 03 corresponde a Service Pack 3 y 181.006 corresponde a: Paquete acumulativo de actualizaciones 5 para Exchange Server 2010 SP3
4) Analizar los cambios que realizarán las actualizaciones (Release Notes)
Una vez sabemos en la versión que estamos situados, deberíamos revisar todos los cambios que generarán las actualizaciones.
Veamos un ejemplo sobre Exchange Server 2013:
Disponemos de: Exchange Server 2013 CU2 (9 de Julio de 2013) 15.00.0712.024
Vamos a aplicar la actualización a: Exchange Server 2013 CU6 (26 de agosto de 2014) 15.00.995.029
Deberíamos repasar las "Release notes" de CU3, SP1, CU5, CU6
Para actualizar a CU6, bastará con descargar e aplicar CU6, sin embargo, los cambios que se efectuarán serán los descritos en las "Release notes" de CU3, SP1, CU5, CU6
5) Esperar unos días después de la salida del parche.
En ocasiones, los parches pueden provocar fallos o inestabilidad en algún componente de Exchange, es por este motivo que Microsoft publica una segunda o tercera versión del parche.
Veamos dos ejemplos:
Sobre Exchange Server 2013:
Sobre Exchange Server 2010:
En ambos casos, vemos como el nombre del fichero acaba o contiene la cadena v2: Esto significa que primero se ha lanzado una versión que causaba problemas después de aplicar el parche sobre Exchange.
6) Repasar "Visor de eventos" antes y después de la actualización
Gracias al "Visor de eventos" (eventvwr.msc), podremos ver si se producen errores después de la aplicación de los parches.
7) Parar la entrada/salida de correo antes de actualizar
Si paramos la entrada/salida de correo antes de actualizar, conseguiremos que en caso de que tengamos que revertir desde un snapshot o backup, no tengamos perdida.
Es importante entender que la parada en la entrada y salida de correo debemos realizarla fuera del servidor de Exchange.
Por ejemplo, si detenemos el servicio de trasporte (servicio SMTP), los parches, en el mejor de los casos, reiniciaran el servicio, en el peor, marcarán error, al encontrarse el servicio detenido.
Parar la entrada/salida de correo debe realizarse fuera del servidor de Exchange, por ejemplo, deshabilitando la regla de entrada del puerto 25 TCP, para el correo entrante.
Desconectar el cable de red del servidor de Exchange, tampoco es buena idea, ya que Exchange, requiere Active Directory para funcionar.
8) Tener en cuenta que los servicios de Exchange quedarán afectados
Los parches, tanto Service Pack, como Update Rollups o Cumulative Update, reiniciaran los servicios en marcha.
Si tenemos clientes conectados, podrán sufrir desconexiones.
9) Reiniciar antes de actualizar
Si reiniciamos el servidor antes de aplicar los parches, conseguiremos liberar toda la memoria RAM que utiliza Exchange como caché.
Además, verificaremos que después del reinicio, todo queda funcionando, de esta forma si después de aplicar los parches, algo deja de funcionar, el culpable son los parches de Exchange.
10) Realizar backup y snapshot de AD y Exchange
Debemos tener un plan de marcha atrás si tenemos que revertir el estado.
El primer paso es verificar que los backups de Active Directory y Exchange se hayan realizado de forma correcta.
Tal y como explicamos en el libro EX2013ADM, Exchange guarda gran parte de su configuración en la base de datos de Active Directory.
Es por este motivo que cuando hablamos de un backup de Exchange, estamos hablando del pack: Exchange y Active Directory.
En el caso de dos controladores de dominio (DC), deberíamos respaldar los dos DC.
El backup nos proporciona una posible recuperación en caso de desastre, sin embargo esta recuperación acostumbra a ser lenta.
Es por este motivo que a pesar de que disponer de un backup actualizado es un elemento imprescindible, podemos ayudarnos de un snapshot a nivel de hipervisor para una recuperación rápida.
Recordemos: snapshot de los DC y Exchange.
Si disponemos de DCs Windows Server 2012 o superior, virtualizados y con un sistema de backups a nivel de hipervisor, no tendremos problemas al rescatar ya sea del backup o del snapshot.
Hemos de tener en cuenta que realizar un snapshot sobre un servidor de Exchange y aplicar parches trabajando sobre el snapshot, el rendimiento global va a caer, además necesitaremos espacio extra en el datastore donde esté situada la VM de Exchange.
El motivo es el funcionamiento de los snapshots: Cada fichero que sea modificado será guardado en un vmdk nuevo, que es el que mantiene el snapshot.
También al eliminar el snapshot, de producirá un acceso a disco muy intenso al consolidar los cambios de los vmdk que está funcionando el snapshot a los vmdk originales.
Para agilizar el proceso de snapshot, podemos realizar el snapshot con la VM parada.
Si nuestro sistema está dimensionado correctamente, no tendremos mayores problemas.
Muy importante: una vez realizada la instalación de parches y verificado que no necesitamos revertir el estado de la VM, eliminar el snapshot.
11) Espacio libre dentro de la VM
Es importante tener en cuenta que aplicar Service Pack (SP) (todas las versiones de Exchange) o los Cumulative Updates (CU) de Exchange Server 2013, requieren espacio en disco.
Pensemos que tanto los CU como los SP, substituirán todos los binarios de nuestra instalación de Exchange.
Podemos ver un ejemplo, en el siguiente post:
Según el este ejemplo, podemos ver como al aplicar SP1 de Exchange Server 2013, respecto al consumo de espacio en disco, sucede lo siguiente:
Antes: 38,6GB ocupados de 99,6GB
Después: 47,3GB ocupados de 99,6GB
Consumo: 8,7GB
12) Pausar tarea de backups
Si realizamos la aplicación de parches dentro de la misma ventana horaria en que se ejecutan los backups, es buena idea detener la tarea o tareas de backups.
Para decidir si pausar la tarea de backup de Exchange o todas las tareas, tener en cuenta que:
- Los backups realizarán un alto consumo de IOPS en el datastore donde se ubican las VMs.
- La tarea que realiza el backup de la VM de Exchange, conectara utilizando VSS a Exchange.
Es decir, la tarea de backup de Exchange, se ha de pausar siempre.
Pausar el resto de tareas, dependerá si el storage donde están ubicadas las VMs soporta la carga extra o no.
Si tenemos dudas, mejor pausar todas.
13) Batería de pruebas
Es importante antes de eliminar el snapshot, reiniciar y proceder a la batería de pruebas.
Las pruebas deberían incluir:
- Entrada y salida de correo al exterior
- Conexión a un buzón utilizando Active Sync, Outlook Anywhere, OWA, etc.
- En caso de disponer de varias versiones de Outlook, probar con todas ellas.
- Verificar que todos los almacenes estén montados.
- Repasar "Visor de eventos" (eventvwr.msc).
También podemos ayudarnos de los cmd-let de PowerShell de Exchange (Exchange Management Shell), para realizar los test.
Los cmd-let de test, son introducidos en Exchange Server 2007 y a cada versión se introducen nuevos cmd-let.
Ejemplo de ejecución de Get-Command Test-* sobre Exchange Server 2013:
