Monitoreando un servicio.

Algo rápido y simple para cerrar la semana!

Estaba visitando un cliente donde el servicio de DNS fallaba continuamente, como sabemos podemos configurar acciones de recuperación para un servicio, esto en sus Propiedades por lo cual haremos un simple script que reinicie el servicio, luego documente su estado, fecha, hora y nombre del host y finalmente nos envíe esta información.





Seria algo como:

(sc start DNS) & (sc query DNS >G:\Scripts\serviceWatch\dns.txt)
date /t >>G:\Scripts\serviceWatch\dns.txt
time /t >>G:\Scripts\serviceWatch\dns.txt
hostname >>G:\Scripts\serviceWatch\dns.txt
blat.exe - -attach G:\Scripts\serviceWatch\dns.txt -to daemonroot22@gmail.com -f service-account@daemonroot.com -server 192.168.0.22 -subject "El servicio de DNS se ha reiniciado nuevamente" -body "El servicio de DNS se ha detenido y reiniciado en múltiples ocasiones, por favor referirse al archivo adjunto para mayor información"Salve lo anterior en un archivo tipo BAT e indique la ruta como muestra la imagen, para ver la consola de administración de los servicios ejecute el services.msc.

Desde luego, ajuste las rutas de los archivos, direcciones de correo e IPs de acuerdo a su ambiente. Como en este caso el servicio de DNS no es 100% confiable, mejor utilice la IP de su Hub Transport y no el FQDN.

**Para descargar BLAT visite http://sourceforge.net/projects/blat/files/ o bien utilice SendEmail o el utilitario de su agrado.

***Si alguna vez este script le envía cientos de correos a su teléfono a media madrugada y su esposa se molesta, no me hago responsable, pero créame que lo entiendo!

Feliz fin de semana.

Respaldos del System State en C:

No es recomendado pero la necesidad muchas veces manda… por defecto Windows Server 2008 no permite almacenar respaldo del System State en su unidad C: pero hay ocasiones donde no tenemos elección.
Primero necesitamos instalar las herramientas de respaldo, de alguna de las siguientes maneras:
-Por medio del Server Manager, seleccionando Windows Server Backup Features y sus subcomponentes o en la sección de Features.
-Con el comando “servermanagercmd -install Backup-Features Backup-Tools” *
-Por medio de PoS “Add-WindowsFeature Backup-Features,Backup-Tools”
-O el comando “ocsetup WindowsServerBackup” en Server Core.
Ok, ahora el truco para lograr correr los respaldos esta en el Registry, debemos navegar a la ruta: “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine” donde crearemos una sub-llave llamada “SystemStateBackup” en la cual crearemos un registro tipo DWORD llamado “AllowSSBToAnyVolume” con un valor decimal de 1.
Ahora bien, ya tenemos la forma de crear los respaldos, cuando lo hagan notaran que el tamaño es un poco grande, por lo cual necesitamos hacer algo para purgarlos, afortunadamente el mismo utilitario de creación nos permite hacer esto.
Entonces el script sería algo como esto:
del C:\WindowsImageBackup\%computername%\ssbu.old
ren C:\WindowsImageBackup\%computername%\ssbu.log ssbu.old
(WBAdmin START SYSTEMSTATEBACKUP -BackupTarget:C: -quiet >C:\WindowsImageBackup\%computername%\ssbu.log) && (WBAdmin DELETE SYSTEMSTATEBACKUP -keepVersions:2 -quiet >>C:\WindowsImageBackup\%computername%\ssbu.log )
Primero renombramos la bitácora (me gusta tener información sobre la vez anterior que la tarea se ejecutó la tarea), luego hacemos el respaldo... si este es exitoso entonces purgamos los respaldos antiguos manteniendo 2 versiones o las que usted guste... todo esto se graba en nuestra bitácora. La cual la próxima vez será renombrada para tomar el lugar de su sucesora...
espero el ciclo sea comprensible.
Ahora bien, hagamos este proceso más fácil, creemos una tarea programada que se encargue de el! "SCHTASKS /Create /TN SSBU /SC Weekly /D Fri /TR C:\Scripts\ssbu-job.bat /ST 23:00"
Acá asumo que los comando anteriores fueron guardados en un archivo .bat (para efectos del ejemplo llamado ssbu-job.bat, esto en "C:\Scripts") el cual ha sido programo para ejecutarse todos los Viernes a las 2300 horas, listo!


Como ya sabemos existen mil y una formas de ejecutar una tarea, esta es tan solo una humilde contribución de este colaborador, espero les sea útil!
*ServerManagerCMD esta practicamente en desuso en Server 2008 R2.
**WBAdmin también incluye el parámetro “-schedule” para programar respaldos, yo soy fan del batch, por lo cual hago esto así :P

Nuevo KB!

Atención con este KB recién publicado, recuerden que este hotfix debe aplicarse únicamente cuando es necesario, esto NO es una actualización o parche rutinario.
"A domain controller that is running Windows Server 2003 SP2 stops responding intermittently"
http://support.microsoft.com/kb/981259
Esto se debe a un problema en el Directory System Agent, el cual afecta todas las versiones de Windows Server 2003.

E14 en WSUS!

Ya es oficial! Exchange 2010 en WSUS.
http://blogs.technet.com/wsus/archive/2010/04/07/new-product-category-for-exchange-server-2010.aspx

La magia antes del Ctl+Alt+Del

Todo inicia con una consulta tipo SRV al servidor DNS...
1- El computador o servidor miembro busca un Domain Controller en su dominio para autenticar (si, esta información esta almacenada en el Registro de Windows). Recordemos que los objetos "computer" son un "security principal" así como los objetos "user" por lo cual también deben autenticar, cambiar contraseñas y demas...
2- Mediante el puerto 53 UDP se hace una petición al servidor DNS por todos los registros SRV de la zona ldap._tcp.._sites.dc._msdcs., donde corresponde al sitio en AD donde la computadora se localiza y se refiere al dominio al cual el equipo es miembro. La información sobre el sitio es almacenada en la siguiente sub-llave del registro HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Services\Netlogon\Parameters\DynamicSiteName. Si el nombre del sitio cambio desde el ultimo reinicio del equipo o bien este no existe pues la consulta fallara y entonces el equipo hará una búsqueda en la zona ldap._tcp.dc._msdcs. en donde está la lista de todos los Domain Controllers del dominio y en la sana teoría cualquiera podría autenticarnos.
3- El DNS retorna al equipo la lista de DCs para el sitio o bien para el dominio.
4- El cliente hace una consulta LDAP para validar que dicho cliente existe en el directorio, acá se valida el nombre del equipo, el nombre del dominio al cual pertenece, el GUID y sAMAccountName (equipo01$). Esto se hace por medio de una consulta anónima, aun no se ha dado la autenticación.
5- Si el controlador encuentra que la información es correcta se envía una respuesta de "success" a la petición de LDAP.
6- Basado en la lista de controladores obtenida en el paso 3 el equipo envía un ping a estos, el primer controlador en responder será el que maneje la petición de autenticación (acá mi cabecita asume que la prioridad y peso de los registros SRV se toma en cuenta, si este es el mismo para todos [0 y 100 respectivamente] simplemente se escoge el orden de los equipos de forma aleatoria, similar a un Round Robin, realmente debo buscar más información al respecto, pero lo anterior sería lo más lógico basado en la teoría, claro mi lógica a veces es un poco extraña).
7- El equipo inicia una serie de conexiones TCP con el controlador que selecciono anteriormente. Se realizaran consultas al puerto de RPC (135 TCP), como sabemos dicho protocolo utiliza puertos aleatorios para la comunicación así que esta consulta nos dirá cual puerto debemos usar creando así las conexiones necesarias para realizar las comunicaciones RPC (RPC se puede limitar a usar puertos estáticos, lo cual disminuirá la cantidad de puertos habilitados en el firewall http://support.microsoft.com/kb/555381). También se establecerá comunicación mediante SMB (445 TCP), esto para File Sharing.
8- Una vez creadas las conexiones anteriores el equipo intentara enviar su petición de autenticación por el puerto 88 UDP, que es donde Kerberos escucha. Como sabemos UDP no ofrece garantía/confirmación de entrega por lo cual si este proceso falla se reintentara la transmisión, esta vez utilizando TCP. Este comportamiento también se pude manipular, forzando a que únicamente se utilice TCP (http://support.microsoft.com/?kbid=244474).
9- Basado en la información recibida del RPC Port Mapper (paso 7) el equipo creara una conexión TCP a dicho puerto, donde el AD Logon RPC Server está escuchando, toda información que se intercambia en este paso esta encriptada.
10- El controlador responde la petición de autenticación Kerberos brindando una llave de sesión, la cual será utilizada durante el proceso de autenticación con el controlador.
11- Utilizando dicha llave y la conexión establecida en el paso 9 se envía múltiples peticiones de autenticacion tipo RPC R_Logon al controlador.
12- Utilizando la conexión SMB creada anteriormente el equipo se conecta al volumen compartido IPC$. También se consulta al controlador si este sabe de algún Microsoft DFS Referral.
13- Utilizando la conexión SMB anterior el equipo realiza pruebas para determinar si la conexión al controlador es de alta velocidad (slow-link test). Dicha prueba determinara ciertos comportamientos futuros, como por ejemplo el proceso de ciertas políticas o también la uso/proceso de perfiles roaming. La prueba de slow-link consiste en un ping de 60 bytes el cual esta cronometrado, luego otro de 1514 bytes repitiendo ambos 3 veces, con la información de latencia se determina la velocidad del enlace y si este debe ser catalogado como slow-link (menor a los 500Kbps o cual sea el valor definido para este).
14- El equipo hará consultas al puerto 389 TCP sobre el dominio y contextos de nombre (consultas al rootDSE, al menos eso creo).
15- El equipo intentara hacer una conexión autenticada a LDAP, esto enviando una petición tipo Generic Security Service (GSS)­SPNEGO.
16- Mediante LDAP el equipo averigua su lugar en la jerarquía de AD, con lo cual sabe que GPOs aplican a su sitio, dominio y/o Unidad Organizativa, esto mediante una consulta LDAP que le retorne el los atributos "gpLink" y "gpOptions" de cada contenedor.
17- Dicha consulta retornara el DN de los GPOs (si gusta ver una lista de sus políticas en AD navegue al contenedor de Policies, que se encuentra en el contenedor System en la partición de dominio).
18- El equipo mediante una petición SMB leerá del SYSVOL el GPC de cada GPO que le aplique. Eso si antes revisara por algún DFS Referal que le lleve al share más cercano (cuando aplica).
19- El equipo leerá y procesara el contenido de cada GPT.
20- El equipo utilizara NTP para hacer una sincronización de tiempo contra el controlador, esto en el caso ideal de que el NTP para nuestros clientes sea tipo NT5DS.
21- Por último el equipo determinara si se necesita realizar alguna transacción referente a certificados, esto al hacer una consulta LDAP a la partición de configuración, específicamente al contenedor CN=Public.Key.Services,CN=Services,CN=Configuration,DC=daemonroot,dc=com en búsqueda de objetos tipo "NTAuthCertificates" y "caCertificate".

Aunque todo esto suena a mucho trabajo realmente es algo rápido y sencillo, que en promedio dura unos 30/40 segundos... en la sana teoría =P
A partir de este punto ya se inicia el proceso de mostrarnos el prompt del Ctl+Alt+Del para así autenticarnos, pero eso ya es otro cuento y el Lobo Feroz hoy no está para contárnoslo...

E14, ojo!

A como voy explorando Exchange 2010 me encuentro y me encanto con sus mil nuevas funciones, también he visto pequeños parámetros que para un mejor funcionamientos deben de ser ajustados apropiadamente.

1. Al crear DAGs se debe especificar el valor máximo para el reset de la bitácora del quórum, recordemos que el DAG a final de cuentas es un clúster...
Esto se debe especificar manualmente en la siguiente llave de registro:
HKEY_LOCAL_MACHINE\Cluster\Quorum\MaxQuorumLogSize dándole un valor de 4194304 decimal o bien 0x400000 hexadecimal.

2.Exchange es muy sensible en cuando a su almacenaje, e visto casos donde una mala configuración de discos se trae abajo el rendimiento del servidor por completo.
En el Registro hay un valor que establece el timeout de los discos, para un server con DAGs este debe de ser de 20 mientras que para un servidor regular este debe de ser de 10.
Esto se debe configurar en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Disk\TimeOutValue.
3. Otra más, cuando se crea un nuevo Mailbox Database, este no se liga automáticamente un Offline Address Book, así que se debe de especificar manualmente.
Esto en las Propiedades de la base de datos en la etiqueta de Client Settings.

Tal vez estas y otras cosillas más que deben de haber por ahí se arreglen con el SP1 que fue anunciado hace un par de días, esperémoslo! http://msexchangeteam.com/archive/2010/04/07/454533.aspx