Hola a todos, mi nombre es David y en este post quiero hablaros sobre problemas que aparecen al intentar recrear Virtual Directories durante el troubleshooting de una incidencia. Dado que hablaré sobre Virtual Directories en «Default Web Site» y «Exchange Back End«, la entrada está pensada para las versiones 2013/2016 de Exchange (pero la idea es aplicable al 2010).

Uno de los componentes esenciales de Exchange es el IIS (Internet Information Services), dado que proporciona servicios como acceso a OWA y ECP, conexión a través de Outlook Anywhere o MAPI, o el acceso mediante dispositivos móviles (entre otros). Todos esos servicios son proporcionados a través de Virtual Directories que trabajan con el protocolo HTTPS (obviamente, en el puerto 443). Más allá de todo eso, lo que no se nos debe olvidar es que IIS es en sí, un servidor web, por tanto no es un elemento «dedicado» para Exchange.

Vamos a poner algunos ejemplos que me he encontrado en entornos de clientes por intentos de recrear Virtual Directories incorrectamente. Voy a usar el Virtual Directory de OWA, pero aplicable a cualquier otro. Para crear y eliminar este Virtual Directory tenemos 2 cmdlets: New-OwaVirtualDirectory y Remove-OWAVirtualDirectory. Pero antes de crear o eliminar, veamos cómo y dónde está almacenada la información de este Virtual Directory.

Como decíamos antes, IIS es un rol dentro de Windows Server y puede estar instalado en cualquier servidor. Por ello, el IIS tiene un archivo de configuración donde guarda las aplicaciones y Virtual Directories creados directamente en él, llamado «applicationHost.config» (almacenado en C:\Windows\System32\inetsrv\config\»). Este es un archivo local, por tanto todo lo que se almacena / cambia en él es únicamente accesible por el IIS localmente. ¿Qué ocurre con los Virtual Directories de Exchange? Que además de estar almacenados en los archivos de configuración locales, también tienen información almacenada dentro de Active Directory, permitiendo la gestión de los mismos tanto desde el propio servidor Exchange como desde uno remoto.

Usaremos ADSIEdit para conectarnos a la partición de «Configuration»:

Este ejemplo está tomado de un servidor Exchange 2016. Si tenéis un Exchange 2013 multirol se vería igual.

¿Dónde puede aparecer el problema al crear / borrar los Virtual Directories? Pues si en lugar de usar los cmdlets que tenemos disponibles para ello, lo hacemos directamente usando ADSEdit o bien sobre la consola del IIS. Cuando ejecutamos Remove-OwaVirtualDirectory, automáticamente se borra la entrada local del applicationHost.config del IIS y, a la vez, se borra el objecto de Active Directory llamado «owa (Default Web Site)«. De la misma manera, New-OwaVirtualDirectory crea la entrada local en IIS y a la vez una entrada en Active Directory. Vamos con un ejemplo:

Un administrador de IT nos llama porque sus usuarios no pueden acceder a OWA. Ha leído un par de foros y, tras varios intentos de arreglarlo, decide contactar con nosotros. Al intentar cargar la página nos encontramos el siguiente error:

 

Como primer paso, abriremos el IIS Manager y el «Exchange Management Shell» (EMS) para ver qué pasa. En el primero desplegaremos el «Default Web Site«, y en el segundo ejecutaremos Get-OwaVirtualDirectory. Estos son los resultados:

Como podemos ver, a nivel de Active Directory el Virtual Directory existe, dado que obtenemos un resultado via EMS, pero no aparece en la consola del IIS Manager. Esto implica que alguien ha eliminado manualmente desde IIS Manager el Virtual Directory. Bien, intentemos recrearlo con New-OwaVirtualDirectory:

El error nos indica que el objeto ya existe, y nos da una ruta de Active Directory. Recordemos que New-OwaVirtualDirectory crea el objeto en el IIS local pero también a nivel de Active Directory. En este caso debemos usar ADSEdit y conectarnos a la partición de «Configuration» como indicamos anteriormente para borrar el objecto «CN=owa (Default Web Site)». Tras realizar esto podremos ejecutar New-OwaVirtualDirectory para que OWA vuelva a funcionar correctamente.

Vamos a hacerlo a la inversa. En este caso nos encontramos con el siguiente error al acceder a OWA.

Al abrir la consola del IIS Manager, veremos que el Virtual Directory existe. Además, podemos acceder a todas las opciones y realizar cambios en cualquier parámetro.

Llegado el momento, decidimos abrir el «Exchange Management Shell» (EMS) y ejecutamos: Get-OwaVirtualDirectory

Sin resultado. Esto quiere decir que aunque en IIS veamos el Virtual Directory (por tanto está almacenado en su archivo de configuración local), el objecto no existe a nivel de Active Directory. Entonces podemos pensar que, con ejecutar New-OwaVirtualDirectory, el problema queda solucionado. Veamos:

El objecto ya existe. ¿Cómo puede ser esto? Leamos todo el error «The virtual directory ‘owa’ already exists under ‘ex16.itadmins.es/Default Web Site«. Y realmente es cierto. Si vamos a la consola del IIS Manager, hay un Virtual Directory llamado «owa», porque está en la configuración local del IIS. Es importante leer bien el error para saber dónde está el problema: el ejemplo anterior nos daba una ruta de un objecto de Active Directory, aquí nos indica directamente en el IIS. Entonces, usando el razonamiento anterior, si borramos el Virtual Directory desde IIS, tendremos que ser capaces de poder ejecutar correctamente New-OwaVirtualDirectory. Bien, borramos «owa» del «Default Web Site» y probamos:

Tenemos un nuevo error. Probablemente en otro Virtual Directory más simple estos pasos hubieran sido suficientes, pero del Virtual Directory de OWA dependen más elementos. Así que llegados a este punto, para resolverlo tenemos 3 opciones:

1. Editar manualmente el archivo applicationHost.config, acceder a la sección de <sites> y eliminar todo lo referenciado a OWA. Si no lo has hecho nunca, probablemente te lo cargues.

2. Si dispones de otro servidor con la misma versión, puedes copiar el applicationHost.config y pegarlo en este servidor.

3. Usar una antigua aplicación llamada «Internet Information Services (IIS) 6.0 Resource Kit Tools« para poder resolverlo.

Vamos a ver cómo realizar el punto 3, dado que os puede ser útil en cualquier otro momento. Lo primero es descargarse dicho software. El único problema que puede presentarse tras la instalación es que, al ser un software antiguo, requiere NET Framework 3.5. En Windows 2012 R2, una vez instalado la versión 4 o superior, los archivos del 3.5 son borrados del repositorio local. Para ello vamos a necesitar la ISO de instalación de Windows 2012 R2 y seguir este tutorial:

Una vez completada la instalación tendremos una nueva aplicación instalada llamada «Metabase Explorer«. La ejecutaremos y nos desplazaremos a la siguiente ruta:

Como podéis ver, aún aparecen restos de «owa». Los borraremos desde la opción que aparece al hacer clic con el botón derecho y finalmente podremos recrear el Virtual Directory.

Bueno, y hasta aquí el artículo de hoy. Espero que haya quedado claro la importancia de no borrar manualmente objetos relacionados con los Virtual Directories ni de IIS ni directamente de Active Directory. Y, en caso de que os encontréis en alguna de estas situaciones, que tengáis idea de cómo solventarlos más rápidamente :).

¡Nos vemos en el siguiente post!