Desinstalación de Servidores de Exchange Legacy
Hola blogger@s!
Tras la migración de buzones a otro servidor, a una nueva versión de Exchange, o a Office 365, quizá necesitemos desinstalar un servidor Exchange en nuestro entorno de On-Premises. Esta operación debe llevarse a cabo con cuidado, y debemos evitar la eliminación de objetos en Directorio Activo mediante el uso de ADSIEdit o herramientas similares. La eliminación desde Directorio Activo podría provocar comportamientos inesperados si tenemos atributos populados en Directorio Activo con referencias a dichos objetos eliminados.
La desinstalación de un servidor de Exchange podría parecer una tarea sencilla desde la opción “Desinstalar un programa” del Panel de Control, pero se realizan durante la operativa varios chequeos para permitir que la desinstalación se lleve a cabo de forma correcta. Si dichos chequeos no se ejecutan de forma correcta, podemos intentar la desinstalación varias veces hasta conseguir el resultado deseado.
Este post estará enfocado en la desinstalación de servidores Legacy de Exchange 2007, ya que probablemente sea en este momento la versión que más se esté desinstalando dado el ciclo de vida de la misma, y dado que Windows Server 2003 se encuentra fuera del soporte extendido, o simplemente para preparar la coexistencia con Exchange Server 2016. La mayoría del contenido del post en cualquier caso aplicará también a Exchange 2010.
Orden de desinstalación
Cuando actualizamos (Service Pack o Rollup Updates) servidores de Exchange en un site de Directorio Activo, es importante actualizar los roles en el siguiente orden: CAS, HUB, UM (en caso de tenerlo) y finalmente Mailbox.
Cuando desinstalamos servidores de Exchange en un site de Directorio activo, el orden es exactamente el contrario: Primero los servidores con el role de Mailbox, UM, HUB y finalmente CAS.
Establecer correctamente el Managemente Scope
Si nuestro Forest contiene varios dominios en Directorio Activo, como Best Practice, desde una sesión de PowerShell debemos cambiar el scope.
Si realizamos una consulta mediante la variable $AdminSessionADSettings, veremos que el parámetro ViewEntireForest está establecido con valor False por defecto:
Si nuestro Forest contiene varios dominios en Directorio Activo, is mejor establecer dicho parámetro con valor True con el fin de ver todos los objetos de todo el Forest completo, en vez de una vista restringida.
Para ello, debemos ejecutar lo siguiente: $AdminSessionADSettings.ViewEntireForest = $true 
Disponemos de más información sobre este punto en el artículo: How to Change the Recipient Scope
Eliminar Bases de Datos de Buzones Legacy
Antes de llevar a cabo una desinstalación, es importante eliminar de forma manual las bases de datos de buzones del servidor que queremos desinstalar. Sólo en caso de que no existan buzones en las bases de datos en el servidor, podremos llevar a cabo la eliminación de las mismas, excepto si la primera base de datos de buzones (que contendrá el buzón de System Attendant). No es obligatorio eliminar las bases de datos de buzones para la desinstalación del producto, pero si las eliminamos previamente y de forma manual, ganaremos mucho tiempo si cualquier buzón permanece en una de las bases de datos.
Podemos revisar si un buzón permanece en una base de datos mediante la ejecución del siguiente cmdlet:
Get-MailboxStatistics –Database “ServerName\StorageGroupName\DatabaseName”
Si lo ejecutamos contra una base de datos vacía, dicho cmdlet debería devolvernos lo siguiente:
En este ejemplo, la base de datos DB04 está vacía, únicamente el buzón de sistema permanece en la misma, lo cual es esperado.
La base de datos DB04 puede ser eliminada.
Si además del buzón de sistema, vemos el buzón de System Attendant, será indicativo de que es la primera base de datos en el servidor de buzones, por lo que deberemos mantenerla montada y funcionando hasta la desinstalación del servidor. En la siguiente captura de pantalla, el buzón de System Attendant se encuentra en la base de datos “Mailbox Database”, por lo que, deberemos dejar montada dicha base de datos y operativa hasta que ejecutemos el programa de desinstalación del producto. En definitiva, la base de datos “Mailbox Database” será eliminada directamente por el programa de desinstalación. En cualquier caso, necesitaremos eliminar el resto de buzones de dicha base de datos en caso de haberlos: 
Desde la consola de administración de Exchange (EMC) podemos eliminar las bases de datos de buzones una a una, o podemos ejecutar el cmdlet: Remove-MailboxDatabase. Si un buzón (distinto de System Attendant) permanece en la base de datos que estamos intentando eliminar, el proceso fallará. En el siguiente ejemplo podemos ver cómo sería la eliminación de la DB04, la cual se encuentra vacía: 
Y el esperado mensaje de advertencia, para confirmar si queremos eliminar también el fichero de base de datos en caso deseado: 
Si existe un buzón en la base de datos, recibiremos el siguiente mensaje de error (por ejemplo, en el caso de la base de datos DB02 la cual aún contiene buzones en la misma): 
Para identificar qué buzones permanecen en la base de datos, debemos ejecutar el cmdlet “Get-Mailbox –Database <Database ID>” como se menciona en el cuadro de diálogo del error de la EMC anterior. También se podría ejecutar el siguiente cmdlet:
Get-MailboxStatistics –Database “ServerName\StorageGroupName\DatabaseName”
La mayoría de las veces las dificultades comienzan en este punto. Podemos recibir el mensaje de advertencia comentado más arriba, indicando que la base de datos que queremos eliminar aún contiene uno o más buzones… cuando en realidad los cmdlets indicados no devuelven ningún resultado.
En primer lugar, si de forma reciente hemos movido buzones entre bases de datos, necesitaremos esperar un tiempo prudencial de replicación en Directorio Activo.
Si recientemente no hemos movido ningún buzón entre bases de datos, puede darse el caso que tengamos una cuenta de usuario donde un atributo tenga aún referencias a dicho servidor o base de datos. Lo primero que podemos hacer es lanzar una consulta con LDP o ADSIEdit para el atributo HomeMDBBL contra la base de datos para ver si cualquier buzón aún permanece asociado a la misma. Este atributo contiene el Distinguished Name de los buzones alojados en una base de datos. Es un atributo de tipo BackLink, es decir, no puede ser modificado, pero al menos podremos revisar su valor.
En el siguiente ejemplo podemos ver en la base de datos DB02, que el HomeEDBBL contiene User1 Move1’, ‘User2 Move2’, ‘User3 Move3’…
En caso de que la eliminación de la base de datos DB02 fallase, podríamos revisar los usuarios detallados en el atributo HomeEDBBL, si es aún válido o no ya que, de forma probable, la eliminación de los atributos de Exchange de dichos objetos haya fallado de forma parcial si los mismos no tienen ya un buzón asociado, o que un movimiento de buzón para un determinado usuario no haya terminado de forma correcta. Simplemente y en ocasiones, será suficiente con mover de nuevo el buzón de nuevo a otra base de datos y el atributo HomeEDBBL nos devolverá un valor vacío.
También, y a pesar de que el atributo HomeEDBBL no devuelva ningún usuario en esa base de datos, si la eliminación aún falla por el error indicado de que aún existe uno o más buzones en la base de datos, probablemente tendremos una cuenta de usuario donde uno de esos atributos aún hace referencia a esa base de datos: HomeMDB, HomeMTA o msExchHomeServerName. Como no sabemos qué cuenta de usuario es, necesitaremos buscarla. LDP sea quizá en este punto la mejor herramienta para realizar consultas en Directorio Activo:
Connect y Bind en LDP: 
Y búsqueda en el nivel de dominio oportuno: 
La consulta a ejecutar en el campo de filtro es la siguiente:
(&((objectclass=*)(msExchHomeServerName=/o=MyCompany/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=E2K7-MBX)))
La parte importante de la consulta es básicamente el nombre LegacyExchangeDN del objeto del servidor:
La consulta devolverá todos los buzones que tengan el valor del atributo msExchHomeServerName con referencias al servidor, lo cual incluirá el buzón de Sistema (System Mailbox), pero necesitaremos localizar en la salida de la consulta si son buzones de usuarios esperados o no.
Se puede realizar una consulta similar en el filtro pero esta vez por los atributos HomeEDB o por el HomeMTA:
(&((objectclass=*)(HomeMDB=cn=DB04,cn=First Storage Group,cn=InformationStore,cn=E2K7-MBX,cn=Servers,cn=Administrative Group (FYDIBOHF23SPDLT),cn=Adminsitrative Groups,cn=MyCompany,cn=Microsoft Exchange,cn=Services,cn=Configuration,dc=testdomain,dc=com)))
En este filtro la parte importante es el distinguishedName de la base de datos de buzones.
Una vez hemos localizado los usuarios, necesitaremos aplicar una solución manual. Dependiendo de la situación, se puede solucionar moviendo los buzones a otra base de datos, o editando sus atributos estableciendo los valores correctos, o directamente eliminando los objetos si ya no tienen buzones asociados.
Una vez hayamos sido capaces de eliminar las bases de datos de buzones (excepto la primera), ya podremos eliminar los Storage Groups que estén vacíos.
Eliminación de Bases de Datos de Carpetas Públicas Legacy
Podemos tener una base de datos de carpetas públicas por servidor o ninguna.
Si no tenemos bases de datos de carpetas públicas podemos saltarnos esta parte del post. Pero, en caso de tenerlas, antes de desinstalar un servidor de Exchange 2007, es mejor eliminar la base de datos de Carpetas Públicas. No es obligatorio, pero igual que con las bases de datos de buzones, quizá necesitemos ejecutar varias veces la desinstalación hasta eliminar la base de datos, por lo que es mejor llevar a cabo una eliminación manual de las mismas antes de ejecutar la opción de desinstalación desde el Panel de Control.
Antes de eliminar una base de datos de carpetas públicas, necesitamos confirmar que esa base de datos no está siendo usada como “Base de Datos de Carpetas Públicas por defecto” en un servidor de buzones. Revisando por ejemplo las propiedades de la base de datos DB02, podemos observar como la base de datos de Carpetas Públicas “Public Folder Database” del servidor E2K7-MBX está configurada por defecto. No podremos eliminar dicha base de datos de Carpetas Públicas a causa precisamente de dicha configuración. Necesitaremos establecer otra base de datos de Carpetas Públicas por defecto:
Desde PowerShell podemos ver rápidamente qué base de datos de carpetas públicas estamos utilizando por defecto mediante la ejecución del siguiente cmdlet:
Get-MailboxDatabase | ft name,PublicFolderDatabase –AutoSize
Antes de proceder a su eliminación, debemos verificar que la base de datos no contiene Carpetas Públicas, con el comando Get-PublicFolderStatistics:
En la captura de pantalla podemos observar que varias Carpetas Públicas están siendo replicadas en dicha base de datos, por lo que no podremos eliminar la base de datos de carpetas públicas. Para ello, el cmdlet Get-PublicFolderStatistics debe devolver una lista vacía.
En caso de que necesitemos mantener el contenido de la carpeta pública, debemos mover el contenido de la misma a otra base de datos/servidor. Para ello podemos hacer uso del script MoveAllReplica.ps1:
MoveAllReplicas.ps1 -Server Server01 -NewServer Server02
Debemos tener cuidado con el volumen del contenido de la carpeta pública que vamos a mover. Si necesitamos mover 10Gb de contenido, esto generará 10Gb de replicación de mensajes, cuyo flujo será a través de SMTP, que en un momento dado podrá sobrecargar nuestros servidores de Exchange dejándolos en un estado ocupados o incluso llegando a no responder. Por lo cual, si el volumen a mover es elevado, no debemos mover el contenido de una vez, sino separarlo en varios lotes.
How to Move Public Folder Content from one Public Folder Database to Another Public Folder Database
Podemos usar la EMC también para añadir una replica en el nuevo servidor, y eliminar entonces el servidor existente:
Una vez hemos movido todas las replicas de Carpetas Públicas a otra base de datos, o eliminado el contenido de las mismas, debemos de nuevo asegurarnos que la salida del comando Get-PublicFolderStatistics devuelve un resultado vacío. Esta operación puede llevar algún tiempo dependiendo del volumen a mover y de las latencias. Pero, al menos y mientras esperamos a que el contenido desaparezca, debemos ser capaz de ver cómo el tamaño del contenido va disminuyendo de forma progresiva.
Cuando la base de datos de carpetas públicas esté vacío, únicamente lo eliminaremos desde la EMC o con el cmdlet: Remove-PublicFolderDatabase:
Offline Address Book
Este paso está relacionado de forma directa con el anterior (eliminación de base de datos de Carpetas Públicas). Dependiendo de nuestro entorno, quizá necesitaremos trabajar sobre la OAB antes de hacerlo con la base de datos de Carpetas Públicas.
Antes de desinstalar un servidor, es importante asegurarse que ese servidor no es el encargado de generar de ninguna de las OAB (lo cual es parte del role de Mailbox), de otro modo la desinstalación podría fallar. Simplemente podemos comprobarlo mediante la ejecución del siguiente cmdlet:
Get-OfflineAddressBook | ft Name,Server
De forma inmediata podremos saber qué servidor está a cargo de la generación de la OAB. Necesitaremos un servidor distinto. Supongamos que queremos eliminar Exchange 2007, podemos asignar un servidor de Exchange 2010 como generador de la OAB desde la EMC, simplemente “Moviendo” la misma:
Debemos revisar también el modo de distribución de la OAB. Puede ser a través de Web (Web-based) y/o a través de Carpetas Públicas: 
Desde Outlook 2007 deberíamos tener únicamente la distribución de la OAB como distribución Web. Si aún tenemos la distribución a través de Carpetas Públicas, debemos asegurar que los clientes Outlook están usando los directorios virtuales de la OAB, y habilitar únicamente la distribución Web (en otras palabras, deshabilitar la distribución a través de Carpetas Públicas). En cualquier caso, si deseamos eliminar todas las bases de datos de carpetas públicas de la organización, deberemos deshabilitar la distribución a través de Carpetas Públicas en todas las OABs antes de eliminar la última base de datos de Carpetas Públicas de la organización.
En caso de que la distribución de Carpetas Públicas no está habilitada para ninguna OAB, podemos eliminar el contenido de la Carpeta Pública desde la Consola de Administración de Carpetas Públicas, básicamente eliminando todas las replicas: 
El contenido no existirá más, pero no es posible eliminar la carpeta raíz de la OAB mediante la EMC. Para ello, revisad por favor la información contenida en el siguiente artículo:
Unable to delete the OAB system folders in Exchange 2007
Antes de llevar a cabo la desinstalación de un servidor, es importante también asegurar que dicho servidor no está siendo utilizado para la distribución de la OAB para los clientes Outlook (lo cual es función en el role de CAS):
En este ejemplo no podremos desinstalar los servidores E2K10-A, E2K10-B ni E2K7-CAS2 porque están siendo usados para la distribución Web de la OAB llamada “Default Offline Address List”.
Si deseamos verificar qué OAB será usada o no (con el fin de limpiar OABs en desuso o antiguas), podemos revisarlo de forma sencillo mediante la ejecución del siguiente cmdlet:
Get-MailboxDatabase | ft name,OfflineAddressBook
Si la OAB no está en uso, no la necesitaremos más y podremos proceder a la eliminación de la misma.
Conectores
Este punto podría resultar bastante obvio, pero también nos ayudará a ahorrar algo de tiempo.
Antes de llevar a cabo la desinstalación de un servidor de Exchange, el mismo no debe ser un cabeza de puente (bridgehead) de ningún conector de envío.
En la siguiente captura de pantalla, antes de desinstalar el servidor E2K7-HUB, necesitamos eliminarlo como servidor origen del conector de envío (o ejecutar el cmdlet Get-SendConnector):
En la relación a los conectores de recepción no funcionan de forma ligeramente distinta. Están asociados al servidor, y habitualmente no causan ningún problema para la desinstalación del programa. En cualquier caso, es mejor y más seguro eliminar los conectores de recepción creados antes de la desinstalación del servidor de Exchange.
Por último, si estamos usando un dispositivo de balanceo de carga para repartir el tráfico del flujo de correo entre varios servidores, no olvidemos eliminar el servidor de dicho pool.
Eliminación de Cluster Legacy
Si estamos usando cualquier tipo de Alta Disponibilidad en Exchange 2007 (CCR, SCC), el proceso de desinstalación puede variar ligeramente. No vamos a cubrir todos los pasos detallados para todos los tipos de cluster en este artículo, ya que todo puede variar dependiendo del entorno que tengamos (por ejemplo, varios CMS o un único CMS en un SCC), pero daremos algunos consejos.
Para familiarizarnos con el proceso, recomendamos la lectura del siguiente artículo de TechNet:
Uninstalling Clustered Mailbox Servers
Si estamos usando SCC con varios CMS, el primer CMS instalado en el servidor será el propietario del role msExchResponsibleMTAServer. Necesitaremos identificar dicho CMS, ya que será siempre el último CMS a desinstalar:
How to Determine the First Clustered Mailbox Server Installed in a Single Copy Cluster
Tendremos que hacerlo únicamente desde una línea de comandos. El siguiente cmd eliminará el CMS y desinstalará el role de Mailbox del nodo. Dicha operativa no puede llevarse a cabo desde la consola gráfica de un Cluster:
setup.com /mode:uninstall /removeCMS /CMSName:CMSName
Conclusión
Antes de la desinstalación de Exchange Server 2007 desde el Panel de Control:
-Eliminar primero las bases de datos de buzones (excepto la primera base de datos)
-A continuación, eliminar la base de datos de carpetas públicas (en caso de que dicho servidor tenga bases de datos de carpetas públicas)
-Revisar las OABs si el servidor a desinstalar no es generador o no está a cargo de la distribución de la OAB
-Revisar si el servidor a desinstalar no está siendo usado como Servidor Origen en ningún Conector de Envío
-Revisar los protocolos de acceso cliente (OWA, EAS, WebServices, Outlook Anywhere..) si no están llegando solicitudes a dicho servidor. Eliminar del pool del HLB
-Puede que necesitemos también desinstalar otros productos/agentes (3rd parties) basados en características de Exchange, como AntiVirus, Backup, herramientas de Monitorización.. Bastante a menudo esos componentes pueden causar que la desinstalación de Exchange falle.
Cuando hayamos completados estos puntos, podremos proceder a la desinstalación desde “Agregar o Quitar Programas” del Panel de Control. No olvidemos cerrar la EMC y la EMS durante la desinstalación.
Toda la información facilitada puede ser complementada con la documentación disponible en TechNet: Removing The Last legacy Exchange Server
Esperamos como siempre que este post os sea de utilidad.
Saludos!
Pedro Moreno