Acceso al directorio en Exchange 2010
por Daniel Seveso
En un artículo anterior, describo un error inherente al acceso al Active Directory en ambientes Exchange 2010, y quise profundizar un poco más en las causas detrás del mismo y por qué esto no sucede normalmente en versiones anteriores de Exchange.
Antecedentes
La incorporación de nuevas funcionalidades de administración como WinRM Remote PowerShell y RBAC, han cambiado las dependencias de Exchange con respecto a Active Directory. Usamos un juego de controladores de dominio para las sesiones de administración (Power Shell o Management Console) y un juego de controladores de dominio independiente para DSAccess.
Acceso al directorio del Exchange Management Shell
Exchange Management Console, la consola de administración de Exchange 2010, traduce todas sus operaciones a comandos de Exchange Management Shell (PowerShell), por lo que la operación de Exchange a través de la consola y sus dependencias con los controladores de dominio se realiza de la misma forma que desde la línea de comandos de PowerShell.
Adicionalmente, todos los comandos de PowerShell son considerados “Remotos” en Exchange 2010, por lo que la consola se debe conectar al Web Service de administración aunque la misma sea ejecutada desde el propio servidor a administrar. Podrán observar el siguiente mensaje cuando se conectan a una nueva sesión de PowerShell:
VERBOSE: Connecting to srv01.contoso.com
VERBOSE: Connected to srv01.contoso.com
Cada sesión de PowerShell tiene una configuración de ambiente que puede ser consultada con Get-ADServerSettings:
[PS] C:\Windows\system32>Get-ADServerSettings |fl
RunspaceId : c6804805-15e5-4904-bfb1-339803deb612
DefaultGlobalCatalog : srv01.contoso.com
PreferredDomainControllerForDomain : {}
DefaultConfigurationDomainController : srv01.contoso.com
DefaultPreferredDomainControllers : {srv01.contoso.com}
UserPreferredGlobalCatalog :
UserPreferredConfigurationDomainController :
UserPreferredDomainControllers : {}
RecipientViewRoot : contoso.com
ViewEntireForest : False
Identity :
IsValid : True
En el ejemplo pueden ver los controladores de dominio que están siendo utilizados en la sesión. Esta configuración es válida para la sesión en curso y cualquier modificación a la misma con Set-ADServerSettings será descartada en cuanto cerremos la ventana de PowerShell. La configuración por omisión es la selección automática de los Domain Controllers en el sitio local.
En la configuración de ambiente hay tres categorías de controladores de dominio:
| ConfigurationDomainController | A cargo de leer y escribir objetos en la partición de configuración (por ej. bases de datos, miembros de DAGs, etc.) |
| DomainController | A cargo de leer y escribir objetos en la partición de dominio (por ej. usuarios, system mailboxes, etc.) |
| GlobalCatalog | A cargo de leer información de particiones de dominio del forest completo (por ej. usuarios, system mailboxes, etc.) |
Como se imaginan a esta altura, podemos cambiar los controladores de dominio de esta configuración de ambiente usando Set-ADServerSettings –PreferredServer:
[PS] C:\Windows\system32>Set-ADServerSettings -PreferredServer srv02.contoso.com
[PS] C:\Windows\system32>Get-ADServerSettings |fl
RunspaceId : c6804805-15e5-4904-bfb1-339803deb612
DefaultGlobalCatalog : srv01.contoso.com
PreferredDomainControllerForDomain : {<contoso.com, srv02.contoso.com>}
DefaultConfigurationDomainController : srv01.contoso.com
DefaultPreferredDomainControllers : {srv01.contoso.com}
UserPreferredGlobalCatalog : srv02.contoso.com
UserPreferredConfigurationDomainController : srv02.contoso.com
UserPreferredDomainControllers : {srv02.contoso.com}
RecipientViewRoot : contoso.com
ViewEntireForest : False
Identity :
IsValid : True
El cambio en la configuración sólo afecta la sessión de administración en curso, indicando a los comandos del Shell donde escribir o leer información de directorio. Esta configuración no afecta el DSAccess ni los servicios de Exchange que utilizan DSAccess para acceder a Active Directory.
Acceso al directorio de DSAccess o Active Directory driver
DSAccess es un componente en Exchange 2010 y versiones anteriores de Exchange que provee servicios de acceso al directorio a sus diferentes componentes, como el Information Store, System Attendant, Active Directory Topology o w3svc. La configuración recomendada (también la configuración por omisión), es la selección automática de los controladores de dominio preferentemente del site local al servidor. DSAccess también reconoce las tres categorías de domain controllers descritas anteriormente, ConfigurationDomainControllers, DomainController y GlobalCatalog.
DSAccess funciona con independencia de la configuración de PowerShell, por lo tanto, operaciones complejas que requieren coordinación de los servicios de Exchange con la creación de objetos desde el Shell, pueden sucitar inconvenientes como los descritos en el artículo de referencia.
Siguiendo el mismo ejemplo, cuando se crea una nueva base de datos, Exchange Management Shell usa el DefaultConfigurationDomaincontroller para crear los objetos “database” y “database copy” en la partición de configuración, y usa el DefaultPreferredDomainController para crear el system mailbox asociado a la nueva base de datos en la partición de dominio local. Si intentamos montar esta base de datos inmediatamente luego de la creación de esto objetos, el componente Active Manager en Exchange tratará de leer el objeto “database copy” con el CurrentConfigDomainController y su correspondiente “system mailbox” con CurrentGobalCatalogs (los controladores de dominio en uso por DSAccess). Si la lectura de los objetos se raliza en un controlador de dominio diferente del que se efectuó su escritura, y el tiempo transcurrido no alcanza para completar la replicación intra-site, Exchange no podrá encontrar estos objetos e informará del error pertinente.
Al igual que Exchange Management Shell, Exchage 2010 permite configurar DSAccess para operar con controladores de dominio específicos, mediante el comando Get/Set-ExchangeServer, y así evitar los problemas por latencia de replicación.
Para consultar que domain controllers está utilizando DSAccess y saber si hay alguno estáticamente configurado, usamos Get-ExchangeServer:
[PS] C:\Windows\system32>Get-ExchangeServer ExServer -Status |fl curr*
CurrentDomainControllers : {srv01.contoso.com, srv02.contoso.com}
CurrentGlobalCatalogs : {srv01.contoso.com, srv02.contoso.com}
CurrentConfigDomainController : srv01.contoso.com
[PS] C:\Windows\system32>Get-ExchangeServer ExServer -Status |fl stat*
StaticDomainControllers : {}
StaticGlobalCatalogs : {}
StaticConfigDomainController :
StaticExcludedDomainControllers : {}
Para configurar el acceso a un domain controller en particular usamos Set-ExchangeServer. Dependiendo del rol que queremos para ese domain controller usaremos uno o más de los parametros Static* disponibles. Por ejemplo para configurar el rol DomainController fijo a srv02.contoso.com ejecutamos:
[PS] C:\Windows\system32>set-ExchangeServer ExServer -StaticDomainControllers srv02.contoso.com
[PS] C:\Windows\system32>Get-ExchangeServer -Status |fl stat*
StaticDomainControllers : {srv02.contoso.com}
StaticGlobalCatalogs : {}
StaticConfigDomainController :
StaticExcludedDomainControllers : {}
Configuración estática no es la recomendada
Por razones de escalabilidad y tolerancia a fallas, la configuración estática no se recomienda para instalaciones en producción, y solamente debe ser usada eventualmente, en casos de seguimiento de problemas o ambientes controlados.
Para revertir los cambios tanto en PowerShell como en DSAccess, sigue los pasos indicados en “Revertir los cambios”