Actualizar el sistema, Consideraciones y mas

Hoy quiero abordar cuestiones relativas a las actualizaciones en general, además de las de producto y Sistema Operativo enfocándolo en entornos Exchange y Lync, hacer hincapié en las medidas a tomar, más allá de las típicas de parchear preproducción, hacer un backup o tareas cotidianas que a veces por prisas no se realizan o no de la forma más correcta.


En base a varias tareas, os voy a ir exponiendo mis prioridades y puntos de vista, empecemos:

La primera tarea es obtener ciertos datos de la infraestructura:
- ¿Qué versión de S.O. tengo?
- ¿Qué versión de producto?
- ¿Hardware? ¿Firmware?, en clientes y Servidores.
- etc..


Todo esto nos viene bien tenerlo documentado o bien hacer un documento previo a las siguientes fases.


La segunda tarea, se basa en leer y leer, informarnos, muchas veces es lo más pesado y lo que menos gusta en general.
Sobre qué leer, pues todo lo relativo y que esté publicado sobre los posibles parches o mejoras a aplicar.
En el caso de Microsoft, principalmente technet. Buscar en Blogs información de otros colegas, en redes sociales como los grupos de Linkedin o simplemente tirar de buscador en base a problemas del fix, rollup, parche o versión de producto y S.O.


Ésta tarea no es un trabajo a hacer en 5 minutos, ni de unas horas, de una mañana o incluso de una semana. Puede llevar mucho tiempo, más del que nos gustaría, pero hay que dedicarle el necesario según el tipo de actualización y sobre qué producto. Claro está que muchas veces no hay tiempo para ello pues nos aprietan las tuercas los fuegos existentes, los jefes o simplemente la emoción de probar nuevas funcionalidades :).

La idea es poder llegar a la siguiente fase con bastante información.
Debemos intentar exprimir nuestros sistemas en buscar información posible, reports, estadísticas, problemas actuales, posibles problemas y dependencias.


Como no, contar con la ayuda de colegas para éste trabajo alivia el proceso.


La tercera tarea, una vez que sé lo que tengo, nos hemos informado de opciones, vamos a intentar ir aproximándonos a aplicar una solución, muchas veces descartando otras. Por lo que en ésta tarea debemos de cuestionarnos TODO:


- ¿Es necesario?
- ¿a qué afecta? ¿clientes, Servidores? ¿otras herramientas? ¿dptos? ¿desarrollos?
- ¿costes? ¿tiempo?
- ¿hay vuelta atrás?
- ¿mejora o no seguridad? ¿es estable?
- ¿hay otros productos que me aporten mas? ¿debo planearme un cambio en la arquitectura o en algun componente?
- ¿cuanto voy a tardar si va bien?, ¿y si falla y he de volver para atrás?


Realmente debemos medir el beneficio que nos aporta un parche, una actualización o incluso un cambio de producto. Si, incluso eso, un cambio de un producto a otro es cuestionable en muchos de los casos a sabiendas de no llevarlo a cabo, pues nos va a enriquecer conocer otras cosas, comparar y ser más especialistas en nuestro trabajo.

Más cuestiones una vez que tenemos decidido donde vamos, principalmente siempre me planteo las siguientes:
- ¿como? ¿actualizo o monto desde cero? Realizo procedimientos (punto siguiente).
- ¿cuando? ¿por la mañana, el viernes, fin de semana? ¿el mes que viene? ¿en qué hora afecto menos al servicio?


Si bien, a menos que sea necesario, está bien definir pautas como no actualizar ciertas cosas un viernes, a primera hora de la mañana, etc, aqui cada empresa o cliente es un mundo.


Según el producto, podremos plantearlo de diferentes formas y en diferentes momentos. Aquí la experiencia es un grado y con productos como Exchange y Lync más aún.


Según entornos, el mejor momento de cambios es el fin de semana, puentes e incluso en agosto cuando no hay casi usuarios. En otros entornos cualquier hora es mala, por lo que ahi entra en juego poder balancear servicios, alta disponibilidad y el tener un backup o una buena vuelta hacia atrás.


A final de esta tarea, debemos decidir y documentar el objetivo, tener claro donde llegar, con qué herramientas y de qué manera actualizar, e incluso migrar. Sobre todo para evitar cambiar el objetivo a los 5 minutos de empezar. Pues se supone que con el trabajo anterior la decisión se ha tomado con referencias y debe ser viable llevarla a cabo.


Definidas las principales tareas y el objetivo a alcanzar, lo siguiente es procedimentar.
Debemos crear un documento de pasos, paso a paso, orden tras orden, en la que plasmar todo aquello que debamos tener en consideración para llegar al objetivo. Incluídos los pasos previos. Técnicos y no técnicos.

Debemos tener a mano en esos pasos, los comandos, scripts o operaciones necesarias para llevarlo a cabo.
También la comunicación a quien le pueda afectar, contar con los recursos de personal necesarios y el apoyo de colegas por si la cosa se tuerce.
No debemos esperar a último momento a buscarlos, dejandolo pendiente, de descargar, de leer o de hacer cambios, de comunicar, etc, pues al final si surje un problema, las prisas no son buenas y los fallos son más graves.
No tengamos miedo a sobre la marcha tener que hacer cambios en el orden de las tareas a realizar, una cosa es planificar sobre el papel y otra en la realidad, pero mejor ir adelantándonos el trabajo y saber adaptarnos.


Las próximas veces acertaremos más en la tarea.
Como ejemplo básico de procedimentar la actualización de un cliente de OCS a Lync, podemos usar el siguiente esquema, sin entrar en scripts, y en definir las tareas complejas:


- Crear las tareas necesarias para la aplicación de parches de S.O. para cumplir los requerimientos de la actualización.
- Crear la tarea con los scripts necesarios para actualizar de versión y aplicar los parches necesarios de producto.
- Notificar a los usuarios que se producirá una actualización y en qué periodo.
- Aplicar los parches de sistema operativo necesarios para esa nueva versión o los que correspondan por seguridad
- Reiniciar el sistema
- Aplicar la actualización del producto y sus parches, cuando el usuario no esté logado, o si está logado cerrar outlook y la versión actual de ocs para evitar fallo de actualización. Notificar de lo que está actualizandose al usuario.


Conviene mínimo hacerse un esquema básico de este estílo, pero más aún detallar cada tarea y documentarla lo máximo posible, generando un documento de procedimiento que como bien decía nos servirá para futuros trabajos similares con pequeños cambios.Simplemente pensar, la actualización de un rollup o cumulative update en Exchange y Lync, siempre es similar, los procedimientos de poner el servidor en mantenimiento o hacer una parada de servicio controlada en ambos sistemas, siempre son comunes a muchos trabajos.


La memoria nos juega malas pasadas, si está documentado es más fácil, más seguro y más rápido, y aun así a veces cometemos fallos o se producen errores.

Tras esta larga explicación sobre cómo creo se debe afrontar una actualización, me centro (espero que mas brevemente) en los siguientes productos, Lync, Exchange y parches de S.O.:


Aplicar actualizaciones a ciertos productos, no es cuestión de 5 minutos tal y como hablábamos.

Concretamente, el trabajo para actualizar productos como los mencionados, es largo y tedioso. Se requiere gente con conocimientos avanzados y expertos en ello. Incluso aun así, en ciertos entornos, se escapan cosas de nuestras manos.


En entornos sencillos con un buen backup y una pequeña preparación puede ser suficiente. Pero en otros entornos, esto puede llevar días e incluso semanas. No el hecho de aplicar parches pero sí las tareas anteriores.

Hay procedimientos en technet para actualizar estos productos, pero muchas veces se quedan escasos. Son generalistas y no abarcan los casos concretos, de ahí el tener cuidado.

Por ello el crear nuestros propios procedimientos.
Microsoft en el caso de rollups nos publica lo que cambia de uno a otro, pero hemos de ver qué nos afecta en cada uno de ellos y hemos de decidir si merece o no la pena actualizar al último o esperar sean otros los que detecten fallos y los que ayuden a corregirlos.

En entornos de preproducción hay cosas que no se detectan, por lo que disponer de un entorno de pruebas es una ayuda pero no lo es todo.

Mi experiencia me dice que estar a la última no siempre es bueno. Por ello le doy un tiempo a ciertos rollups y si no hay ruido al respecto ciertos fallos, lo pruebo en preproducción y pasado un tiempo prudencial entonces es cuando lo aplico en producción.

En Exchange, debemos usar las indicaciones de MS en cuanto al orden de actualizar los Roles...Edge, CAS, HUB..MBX...UM..etc. Si nuestro entorno es de un solo servidor, ésto de poco sirve. En versiones como Exchange 2016, se ha buscado simplificar éste problema, veremos qué tal resulta.
En Lync es similar, mucha planificación, y más si lo tenemos con enterprise voice, UM, etc.

Aquí se complica cualquier actualización, por pequeña que sea. Y el riesgo de hacer algo mal puede llevar a una caída parcial de servicio.

Por último, actualizar parches de S.O. en estos entornos, afecta al producto muy directamente. Pues los servidores primero deben estar alineados, un cambio en un parche que aplique sobre .Net Framework o incluso algo más sencillo, que aplique sobre un permiso, una estructura de registro, o algún parche de seguridad, nos pueden hacer tambalear el sistema.

¿Debemos por lo tanto estudiar cada parche de S.O. que aplicamos?, realmente es imposible. Podemos informarnos, ser precavidos en su aplicación y si algo falla, tirar de soporte o intentar volver hacia atrás, pero aquí es difícil tener espacio de maniobra para detectarlo.

La opción de preproducción es buena, pero no efectiva al 100%.

Ni que decir sobre el NO actualizar. No he hablado de ello pues no lo veo como opción alguna, por mucho que decimos a veces de ..."si funciona déjalo así".

Conozco aún sitios con NT funcionando por esa premisa, pero eso es otra historia.


Como conclusión última a éste tema, con Exchange y Lync, la idea es no actualizar  automáticamente, ni S.O., ni Rollups ni CU. Entiendo que MS sí lo pueda hacer y en un entorno estándar con más razón, pero las Pymes y grandes empresas no suelen ser estándares de estos productos.

Creo que no me he dejado nada en el tintero, si el tiempo me lo permite, incluiré algún procedimiento de los que más usamos.


Un saludo y gracias, más si has llegado al final de ésta lectura.


Álvaro Velasco Miguel.