Este es el segundo artículo de la serie de Preguntas y Respuestas (PR2). Si te perdiste el primer artículo hace clic aquí.
En este “PR2” vamos a abordar las siguientes consultas (entre paréntesis las iniciales de quien envió la pregunta):
- (LM) Al abrir la consola de administración de Exchange 2010 se me presenta constantemente el error “Access is denied”
- (JC) Cuál sería el procedimiento correcto para parchear ambientes con Exchange 2010 y 2013 incluyendo últimos Rollup y CU?
- (AJ) Recientemente agregamos otro proveedor de internet ya que el primero tiene muchas caídas y nos deja incomunicados. Qué configuración debo aplicar a mi registro MX para que cuando un proveedor falle el correo entre por el enlace del otro proveedor?
- (HV) Dudas con el formato de la salida en powershell…
1. (LM) Al abrir la consola de administración de Exchange 2010 se me presenta constantemente el error “Access is denied”.
The attempt to connect to http://servidor/Powershell using «Kerberos» authentication failed: Connecting to remote server failed with the following error message: Access is denied.
Este error se puede deber a varios motivos, en general hoy por hoy donde la mayor parte de los servidores con Exchange se encuentran virtualizados es muy común encontrarse con errores relacionados con Kerberos por cuestiones de sincronización de hora. No es que no suceda con servidores físicos, pero se ve más frecuentemente en servidores virtualizados.
Por qué se da más frecuentemente con Exchange virtualizado?
Supongamos el siguiente escenario, tenemos 2 hosts con Hyper-V (o vmware), en uno de ellos tenemos 1 controlador de dominio, digamos que en el host “A”. Por otro lado en el host “B” tenemos un servidor con Exchange. Tanto la VM con el DC como la VM con Exchange se encuentran con los servicios de integración que entre otras cosas manejan la sincronización de hora con el host.
A su vez cada host se encuentra con la configuración de sincronización de hora predeterminada.
Con el paso del tiempo los host van quedando desfasados a nivel de tiempo lo que en algún punto deriva en errores de autenticación de Kerberos.
Qué debemos hacer?
Lo primero que debemos hacer en este caso es revisar la configuración de hora. Idealmente sincronizariamos todos los equipos (incluyendo a los host) desde la jerarquía de Active Directory, es decir con controladores de dominio hasta llegar al DC con el rol de PDC emulator. El DC con el rol de PDCe debe estar configurado para sincronizar la hora con una fuente externa autoritativa (este debería ser el único equipo que sincronice con una fuente externa). En adición, desmarcar de los servicios de integración de las VM de controladores de dominio la opción de sincronización de hora.
De esta manera tendríamos todos los equipos sincronizando de un modo u otro con el PDCe del dominio y este último sincronizando con una fuente externa confiable.
Por último, tener en consideración que cualquier cambio a nivel de configuración de hora debe ser muy bien planificado ya que el impacto puede ser importante.
2. (JC) Cuál sería el procedimiento correcto para parchear ambientes con Exchange 2010 y 2013 incluyendo últimos Rollup y CU?
Exchange 2010 se encuentra en fase de soporte extendido y el último Service Pack (SP) es el 3 (ver procedimiento de instalación). Por lo que en este caso lo que pueden seguir liberándose son Rollup updates (RU). Estos RU son específicos al nivel de Service Pack del servidor, es decir que el RU que instalemos debe ser para Service Pack 3 (si estamos actualizados en cuanto a SP).
A su vez cada RU incluye las actualizaciones incluidas en los últimos RU de la misma serie, por ejemplo el RU13 incluiría todas las actualizaciones incluidas hasta el RU12.
En principio la instalación de un RU en un servidor Exchange que no está en DAG no requiere un procedimiento específico más allá de agendar una ventana de hora donde se sepa que el correo va a estar intermitente o fuera de servicio. Para el caso de Exchange en DAG es necesario seguir un procedimiento específico como se detalla en el siguiente artículo (el procedimiento puede aplicar independientemente de si se usa DAG omitiendo lo que no aplique):
Cómo instalar un rollup para Exchange 2010 en DAG?
En el caso de Exchange 2013 (o 2016), ya no tenemos SP ni RU, lo que tenemos son “CU” (Cumulative Updates). Estos CU incluyen toda la instalación del producto, es decir que no debemos instalar Exchange 2013, luego el CU1, CU2, etc. Instalamos directamente Exchange utilizando el último CU.
Instalar un CU en un entorno con un solo servidor no requiere ningun procedimiento específico más allá de como se menciono anteriormente para el caso de Exchange 2010 coordinar una ventana de tiempo donde se pueda trabajar sabiendo que el correo va a estar fuera de servicio. En el caso de instalar un CU para Exchange 2013 en DAG primero se deben poner los servidores en un modo mantenimiento.
Para ver el detalle de instalación de un CU para Exchange 2013 en DAG ver el siguiente artículo (al igual que en el caso anterior, el procedimiento puede ser utilizado para cualquier servidor omitiendo la parte específica a DAG):
Actualización de Cumulative Update en Exchange 2013
3. (AJ) Recientemente agregamos otro proveedor de internet ya que el primero tiene muchas caídas y nos deja incomunicados. Qué configuración debo aplicar a mi registro MX para que cuando un proveedor falle el correo entre por el enlace del otro proveedor?
Existen varias opciones, en este caso quizás la más sencilla sea utilizar múltiples registros MX.
Por ejemplo, tenemos el enlace del proveedor “A” con una IP pública 1.1.1.1, por otro lado tenemos el enlace del proveedor “B” con una IP pública 2.2.2.2.
A nivel de DNS externo podríamos tener 2 registros de tipo A (host):
- MailA – 1.1.1.1
- MailB – 2.2.2.2
Teniendo configurado ambos enlaces a nivel de firewall, permitiendo la entrada de SMTP y con el NAT correspondiente a los servidores que reciban el correo externo solo resta configurar los registros MX.
Los registros MX llevan un valor de preferencia, donde el registro que tiene menor preferencia tiene mayor prioridad, entonces si por ejemplo queremos que en condiciones normales el correo ingrese por el proveedor “A” y en caso de falla que lo haga por el enlace del proveedor “B” podríamos crear los siguientes registros:
- MX – Pref: 10 – Host: MailA
- MX – Pref: 20 – Host: MailB
Si en cambio preferimos balancear la entrada podríamos generar los mismos registros pero en lugar de utilizar preferencias diferentes utilizar el mismo valor.
Por más info ver el artículo de Introducción a DNS para Exchange.
4. (HV) Dudas con el formato de la salida en powershell…
Esta en particular en realidad era una consulta relacionada a errores dentro de un DAG.
Para mostrarme el error me enviaron un correo con la siguiente captura de pantalla:
Como se puede ver, la idea era ver el error que se registraba pero la salida queda cortada en:
Failures:…
Con esta descripción no tenemos idea de qué sucede, solo sabemos que hay fallas.
Cuando en la salida de un comando vemos el mensaje o el valor cortado, en general las opciones más útiles son las siguientes:
- Cambiar el formato de la salida a modo lista (Format-List o FL)
- Especificar en modo tabla con los parámetros “autosize” y “wrap” (Format-Table o FT)
Ejemplo 1:
Get-ExchangeServer | FL
Ejemplo 2:
Get-ExchangeServer | FT –AutoSize –Wrap
Así que dejamos este artículo por acá, deja tus comentarios más abajo si te quedan dudas.
Si tenés alguna consulta sobre Exchange y querés que la respuesta sea publicada en el sitio podes suscribirte y responder el correo de bienvenida con tu pregunta.
Semanalmente se van a ir respondiendo las de mayor interés.
Deja una respuesta