6 Tips para troubleshooting de AD DS

1.- Determinar la salud del DNS

Lo primero que debemos determinar cuándo realizamos una asesoría en AD es la salud del DNS. Una falla en el DNS puede causar muchos problemas en la autentificación, fallo en las aplicaciones, exchange, replicaciones, problemas de respuesta en LDAP, entre otros.

Como describimos anteriormente la revisión del DNS es crítica, para poder determinar el estado de salud de la plataforma, detallaremos unos CMDLET para complementar el Dcdiag.exe, el cual es:

dcdiag /test:DNS /e /v

La opción /e indica que la prueba correrá en todos los servidores de DNS, y /v indica una salida detallada de texto para el resultado de esta prueba. En un ambiente amplio, esto puede tardar un tiempo, pero vale la pena esperar.

Siempre comienzo leyendo desde el final del reporte, donde aparece una tabla como table 1. DCdiag ejecuta 6 pruebas diferentes: Authentication (Auth), Basic Connectivity (Basc), Forwarders (Forw), Delegation (Del), Dynamic Registration Enabled (Dyn) y Resource Record Registration (RReg). La tabla además lista la prueba de External (Ext), la conexión a internet, pero este comando no realiza esa prueba.

Captura de pantalla 2016-01-28 a la(s) 16.59.57

En la salida de la tabla 1, muestra cada servidor DNS (El cual usualmente también son los Domain Controlers) del bosque listado por dominio. Lo bueno de eso es que muestra la configuración de dominio del bosque, la cual es de mucha ayuda si eres consultor o ingeniero de soporte y no estas familiarizado con la infraestructura. En los datos de lectura de la tabla, los resultados son:

  • PASS: El servidor DNS completa el test.
  • FAIL: El servidor DNS falla el test.
  • N/A: La prueba no fue ejecutado. Esto ocurre generalmente por una falla en alguna prueba anterior, por lo que no tiene sentido realizar una prueba sobre un servicio que ya sabe que está fallando.

En la tabla 1 podemos ver el valor de esta prueba. Inmediatamente podemos ver los lugares conflictivos. En un bosque de multiple dominio, debes ejecutar este comando con credenciales de Enterprise Admin, u obtendrás resultados fallidos en todas las pruebas de los servidores DNS por que no tienes los privilegios suficientes. Esto es lo que sucede para el dominio EMEA en la tabla 1.

Al termino del reporte se presenta una lista completa de las fallas, donde se pueden ver todos los detalles. Por ejemplo puedo ir a la parte superior del reporte y buscar por Corp-DC02, y obtener los detalles que son mostrados en figure 1.

En este primer paso se presenta muy buena información, se puede construir la configuración del DNS Resolve para cada servidor DNS. Lo principal en este paso, es que se muestra el porque la prueba de Forwarder nos entregaba N/A en la tabla 1. Usando este método podemos elegir el camino entre los resultados “warning”, “failure” y “N/A” de la tabla 1. Y por supuesto lo mejor de todo esto, es que tienes la información de todos los servidores DNS del bosque en un archivo, generado por un solo comando.

Captura de pantalla 2016-01-28 a la(s) 17.03.19.png

2.- Determinando la salud de la replicación del AD

 La herramienta de soporte para Windows Server incluye la opción en Repadmin llamada /replsum. Similar al comando DCdiag /test:dns del Tips 1, /replsum colecciona la información de replicación de todos los DC del bosque. Esto muestra el reporte de en qué momento ocurre la replicación entre los DC, el comando debe ser ejecutado en cada uno de los DC del bosque. Aquí están las opciones más usadas:

Repadmin /replsum /bysrc /bydest /sort:delta

  • /bysrc indica la colección de datos de los DC que han replicado en otros DC.
  • /bydest indica la colección de datos de los DC que han replicado en otros DC.
  • /sort:Delta muestra los resultados en orden decendiente

Un ejemplo de esto se ve en table 2. Aquí se muestran seis DC y gracias a delta se muestran por orden de su última replicación. Aquí podemos ver fácilmente la salud del dominio, excepto para WTEC-DC2, el cual no ha sido replicado de hace cinco días, que arroja el error 1722. Yo sé que este DC se encuentra apagado ya que está siendo movido a un nuevo Data Center.

Captura de pantalla 2016-01-28 a la(s) 17.06.49

3.- Detalle de replicación para todos los DC del bosque.

 Esta técnica (similar a la del tips número 2) nos entrega mayor detalle. El comando es /repadmin /showrepl * /csv>showrepl.csv. Esta opción de salida en formato CSV, como se muestra en table 3.

Me gusta este comando por que frecuentemente muestra un error en mayor detalle qué el comando /replsum. Además, ofrece un reporte de distintos errores (o errores adicionales, código de error y más) y especifica los datos que /replsum no entrega.

Captura de pantalla 2016-01-28 a la(s) 17.08.03

4.- Diagnóstico NTDS

Este punto es esencial para obtener información adicional de los datos en el visor de eventos de Directory Service (DS). Está habilitado por registro en HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\NTDS\Diagnostic. Es bastante sencillo. Aquí hay una variedad de atributos que, cuando son habilitados entregan información adicional en los logs de eventos para ayudarte en las tareas de troubleshooting. Los datos válidos de estos registros es una variable de 0 a 5. El valor por defecto es 0, significando una entrega de datos mínima, y añadiendo 5 entrega más datos de los que quieres. Generalmente configuro 3 y reviso si es que llegase a necesitar más información. En ciertos casos, si necesito mayor detalles en la replicación, al valor de “5 replication event” lo cambio a 3, para reproducir el problema. Asegúrate de cambiar el valor a 0 cuando las labores de troubleshooting finalicen.

Los valores más comunes que utilizo son:

  • 1 Knowledge Consistency Checker
  • 10 Performance Counters
  • 13 Name resolution (Relacionado con el DNS)
  • 15 Field Engineering
  • 18 Global Catalog
  • 2 Security Events
  • 5 Replication Events
  • 8 Directory Acces
  • 9 Internal Processing

El valor 9 Internal Processing es útil para obtener información adicional sobre el DS event, esto indica que error interno está ocurriendo. Esto a menudo muestra eventos adicionales que ayudarán en el diagnóstico del problema. Es común añadir un valor mayor a 1. Realizando troubleshooting de replicación, es buena idea habilitar el valor 1 Knowledge Consistency y 5 Replication Events.

El valor 15 Field Engineering entregará diversa información adicional a los logs de DS. A diferencia de los otros diagnósticos, este debe ser ajustado a cinco para que entregue información relevante. Específicamente, esto genera los eventos 1644 y 1643, que mostrarán la ineficiencia en las consultas a LDAP, incluyendo a los clientes que generan las consultas, el tipo de consulta, y la raíz de la consulta. Esto es importante, ya que uno de los dolores de cabeza relacionados con el AD, es el proceso Local System Authority Subsystem Services (LSASS), que se encuentre utilizando suficientes recursos para colgar, o crashear nuestro DC, causando una lentitud en el ingreso del usuario. Una ineficiencia en las consultas a LDAP de parte de los usuarios o aplicaciones puede suponer una enorme carga en LSASS. Habilitando este diagnóstico podemos identificar de manera más rápida al culpable según su nombre o dirección IP. Algunos administradores dejan este diagnóstico habilitado permanentemente en organizaciones ocupadas, pero de nuevo, esto llenará nuestros logs de eventos, y posiblemente esconda o sobre escriba otros eventos importantes en los logs de DS.

5.- Reportes HTML y consola de administración de políticas de grupo.

Seguramente todos los administradores de AD han usado esta herramienta en algún momento, pero pensé que valdría la pena mencionar los valores de los reportes HTML. Aquí hay dos tipos de reportes que uso frecuentemente cuando trato con entornos con los cuáles no estoy familiarizado y por lo general quiero probar las configuraciones de las Group Policy Object (GPO), así como los resultados en un cliente en particular o clientes.

Obtener un reporte de las GPO es valioso, incluso si eres el administrador de la plataforma, ya que muestra exactamente las configuraciones definidas (de hecho, solo muestra las configuraciones definidas), por lo que no tendrás dificultades para investigar en el editor de políticas para encontrar las que se encuentran establecidas. Esta es una manera rápida de ver si la GPO está definida como esperas que lo esté. Incluso muestra los links, filtros aplicados y otros detalles. Los reportes HTML para la Default Domain Policy son simples de leer y pueden ser expandidos o cerrados por sección según lo necesites, ya que se encuentran en formato HTML. Para obtener este reporte, de click derecho sobre la GPO y selecciona “save report”.

Uno de los problemas a solucionar en las GPO está relacionado con un cliente el cuál molesta al usuario, quien se encuentra a cientos de kilómetros de distancia para ingresar y obtener un GPOResult. Si el usuario ha ingresado en al menos una estación de trabajo, la consola de administración de políticas de grupos (GPMC) puede entregar con un formato HTML el resultado del GPResult que se produce cuando el usuario ingresa.

6.- Diagnóstico de rendimiento para Active Directory.

Si bien hay muchos otros tips para troubleshooting que pude haber añadido, este es uno que probablemente, no del todo conocido. En el troubleshooting del rendimiento de los servidores, hay un conjunto estándar de objetos, incluidos el procesador, disco lógico, memoria del servidor, sistema y así entre otros. Sin embargo hay un objeto de NTDS que nos proporciona contadores relevantes del AD como, DRA, Kerberos, LDAP y contadores incluso relacionados con eventos en NTLM. Además podemos recopilar valores importantes de los datos de nuestro AD mediante el monitoreo de los procesos de LSASS. Recomiendo habilitar los siguientes:

  • Object: Process
    • Contadores: % de tiempo de procesado, conjunto de trabajo, y pico de conjunto de trabajo.
  • Object: NTDS
    • Contadores: Todos los contadores.

Desafortunadamente hay poca información disponible dentro de lo aceptable. El más útil encontrado es la guía de implementación para la rama de Microsoft Office. Si bien hay muchos contadores y puedes o no estar familiarizados con ellos, aquí hay algunos significados.

  • DRA Pending Replication Synchronization: Este es el directorio de sincronización de las colas y los retrasos en la replicación, Microsoft dice que estos valores deben ser lo más bajo posibles y que el hardware está retrasando la replicación. Estos son indicios de que los recursos del DC tienen un alto porcentaje de utilización.
  • LDAP Cliente Sessions: Este es el número de sesiones abiertas simultáneamente por clientes LDAP. Esto es útil para determinar la actividad de los clientes de LDAP y si el DC está habilitado para soportar esa carga. Por supuesto los picos se registran durante la autenticación de los clientes lo cual no es un problema necesariamente, pero en largos periodos los altos valores significan un exceso de trabajo para el DC.
  • LDAP Bind Time: Este es el tiempo en milisegundos que es necesario para completar la unión de LDAP. La documentación de Microsoft indica que esto debe tener el menor tiempo posible, pero si corres un análisis a través de los logs de análisis de rendimiento (PAL), indicara 15 sobre milisegundos como un warning, y sobre 30 como un error.

En el diagnóstico de procesos LSASS, como en cualquier análisis de rendimiento, debe haber una base establecida. Una nota en el DS blog de Microsoft indica que si una base no está establecida, debe ser utilizado el 80%. Es decir los contadores LSASS no deben superar el 80% de consumo, ya que sobre el 80% indicará una sobre carga, lo que podrá traer una alta demanda de consultas a LDAP, o la falta de recursos en el servidor. La solución es aumentar los recursos del servidor, o disminuir la demanda de consultas, pero tenga en cuenta que el alto uso de recursos puede causar un impacto en el rendimiento del dominio.

Si desea solucionar problemas de recursos, utilize una plataforma x64 en los DC, con diversos procesadores, y 32GB de Ram. Es sorprendente cuanta memoria realmente puede utilizar los recursos LSASS.

Espero que estos tips sean de gran utilidad a la hora de realizar un troubleshooting de AD DS.

Ernesto León, Técnico en Soporte, Blue Solutions.

Advertisements

3 Consejos para la resolución de problemas en SCCM

System Center Configuration Manager es una gran plataforma para la administración de activos presentes en el dominio. Con soporte, que incluye a clientes Linux y Mac.

Ofrece un amplio abanico de posibilidades para mantener control, estandarización de los equipos y seguridad en el momento de la automatización de tareas. Esto se traduce en un sano ecosistema.

¿Qué ocurre cuando deja de existir un sano ecosistema? Lo más probable es que la plataforma no esté operando en óptimas condiciones, por lo que debemos preguntarnos ¿Qué pudo haber fallado?.

La plataforma no es tan elocuente para acusar un problema de funcionamiento, así que les comparto consejos donde buscar, para generar un diagnóstico, antes de comenzar a correr en círculos.

1. Revisar los estados de los sistemas desde la consola de SCCM

Toda actividad de revisión, diagnóstico y reparación debieran partir por aquí. Estos indicadores mostrarán cuál es el componente que está delatando algún problema.

Los indicadores a revisar son:

  • Estado del sitio
  • Estado del componente

Ambos indicadores están dentro del módulo de Supervisión.

M1

En estado de sitio se revisa el estado de cada uno de los roles de la implementación. Por rol me refiero a Puntos de Administración (MP), Servidor de Sitio (Site Server), Punto de Distribución (DP), etc.

M2.png

En estado de componente se encuentra el estado de los elementos ya más técnicos. Se describe en detalle lo que puede entregar el estado de sitio. Siempre es recomendado estar atento a los dos indicadores.

 La forma correcta de acceder a los registros es hacerle click con el botón secundario y luego en mostrar mensajes. En el menú aparecen las opciones. A modo personal, siempre reviso todos y luego dentro de la ventana voy filtrando.

M3.png

M4

M5.png

Revisando los estados ya sabremos algo de lo que está ocurriendo.

2. Comprobación de la comunicación entre cliente y punto de administración.

Entre los clientes y el punto de administración la comunicación es a través de HTTP. Todo el tráfico es web. Los clientes descargan políticas y envían sus inventarios a través de un servicio publicado en IIS.

Una buena manera de comprobar la comunicación es acceder a la URL http://nombre_MP/sms_mp/.sms_aut?mplist desde el navegador del cliente y se debiera tener un resultado muy similar a este:

M6

En el caso que de un código 400 o superior, es porque el problema se encuentra en el servicio.

3. Revisión logs

Aparte de los eventos que la consola nos puede entregar a través de la revisión del estado del sitio y de los componentes, se pueden encontrar registros aún más detallados sobre lo que está ocurriendo.

Para revisar estos logs, debemos navegar hacia la ruta: %ProgramFiles%\Microsoft Configuration Manager\logs.

M7.png

Como recomendación, ordenar los logs por fecha antes de comenzar a revisarlos. Esto ayudará a revisar los logs que se van actualizando de forma más periódica.

A los administradores les recomiendo siempre les recomiendo tener instaladas en su equipo las herramientas para la administración: https://www.microsoft.com/en-us/download/details.aspx?id=50012

Y también el libro gratuito: Troubleshooting Configuration Manager

http://blogs.msdn.com/b/microsoft_press/archive/2013/11/12/free-ebook-microsoft-system-center-troubleshooting-configuration-manager.aspx

Ahora que ya conocen algo más de la plataforma, espero que puedan aplicarlo cuando estén frente a una problemática, o bien, acordarse donde están estos consejos.

Maximiliano Marín, Consultor de Infraestructura, Blue Solutions

¿Cómo configurar servidor de KMS 2012R2?

La función de un servidor KMS es bastante sencilla y útil. Su misión es entregar una licencia de Windows al equipo del cliente. Su implementación en bastante simple, hasta Windows 2008 R2 no se utilizaba interfaz gráfica, solo se trabajaba a través de líneas de comandos. Hoy en Windows Server 2012 R2 se añadió la posibilidad de usar una interfaz gráfica. Claro está que aún puede ser implementado a través de líneas de comandos.

A continuación vamos a realizar la implementación.

1.- Desde la consola de Server Manager de nuestro Windows 2012, debemos hacer click en manage, add roles and features y desde la opción de roles del servidor, seleccionamos “volumen activation services”

e1

Procediendo a la instalación.

e2

Una vez finalizada la instalación, damos click en “Volume Activation Tools” para comenzar con la configuración.

e3

Al ingresar a la herramienta de Volume Activation podemos observar que además de la opción de Key Management Service (KMS) está la opción de Active Directory-Based Activation. Nosotros utilizaremos el KMS y daremos click en next, ya que las activaciones basadas en Active Directory, solo soportan desde Windows 8 en adelante.

e4

Aquí utilizamos  KMS host key. ¡Ojo debe comprarse! y click en Next.

6e

7e

Seleccionamos la localidad donde serán utilizadas las licencias y click en commit para finalizar.

8e

9e

Este servicio se utiliza para activar las licencias de multiples equipos conectados a la red, realizando de esta forma una labor automatizada.

 Ernesto León, Técnico en Soporte, Blue Solutions.

¿Cómo podemos actualizar el protocolo de replicación de archivos para AD DS en Windows Server 2012 y 2012 R2?

EL protocolo de replicación en archivos en Active Directory Domain Services es imprescindible para el óptimo funcionamiento de la plataforma, de lo contrario existirían problemas de inconsistencia en la información y bases de datos de AD DS. Microsoft al estar consciente de esto, ha decidido crear un nuevo protocolo de replicación de archivos, 15 veces más rápido y mucho más estable que su versión FRS.

En este artículo usted aprenderá a realizar la actualización del protocolo FRS a DFS-R, para aprovechar todas las bondades que ofrecer Windows Server 2012, y 2012 R2.

Lo primero que debemos saber, es si se está usando FRS o DFS-R. No es fácil detectarlo, ya que la interfaz gráfica usada para administrar o configurar el Dominio no cuenta con la información. Sin embargo, existe una opción para averiguarlo y es a través del Registro (registry), debemos utilizar REGEDIT.EXE y encontrar:

”HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters”

Cuando llegamos aquí, tendremos dos posibilidades, que exista o no una sub carpeta “Syvols\Migrating SysVols”.

Opción 1 Subcarpeta SysVols:

“HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\Sysvols\Migrating SysVols”

Esto significa que que se está utilizando DFS-R

1q

Opción 2 No existe subcarpeta SysVols:

Sí la subcarpeta SysVols no existe, significa que se está usando FRS.

2Q

La primera figura, que usa DFS-R, está tomada en un Controlador de Dominio donde se ha creado un Dominio y Bosque nuevos directamente con niveles funcionales Windows 2012 R2.

La segunda figura, corresponde a un Dominio que se ha actualizado desde versiones anteriores.

Entonces, ¿Cómo podemos hacer la migración del servicio de replicación de archivos?

1.- Debemos elevar el nivel funcional de Dominio y Bosque a “Windows Server 2012”.

2.- En uno de los Controladores de Dominio debemos abrir una línea de comandos como administrador y pasar al primer estado. Debemos ejecutar:

DFSRMIG /SetGlobalState 1

Y periódicamente verificar si el proceso fue completado con:

DFSRMIG /GetGlobalState

3g

Una vez alcanzado el nuevo estado (Prepared) podemos seguir con el siguiente:

DFSRMIG /SetGlobalState 2

4g

De forma análoga pasaremos al estado 3.

5q

Y si queremos comprobar, podemos verificar en el registro, que aparece la carpeta mencionada al principio de la nota, y además que el estado es 3 (Eliminated).

6.

El cambio de FRS a DFS–R, en muchos casos permanece oculto para los administradores de Active Directory, que suponen erróneamente su actualización automática cuando se actualiza el Domino. Afectando la calidad y el desaprovechamiento de recursos en nuestros servicios al utilizar un protocolo antiguo.

Nicolas Herrera, Consultor de Infraestructura, Blue Solutions