CachedLogonsCount

Como sabemos para agilizar el inicio de sesión la maquinas guardan cierta cantidad de credenciales, este comportamiento lo podemos modificar al navegar a HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon y variar el valor del registro CachedLogonsCount que por defecto es 10. Si este lo ponemos en 0 deshabilitaríamos el inicio de sesión fuera de línea, forzando siempre a que el equipo contacte a un DC/GC para el inicio de sesión.

Este en algunos casos como instituciones financieras puede ser muy útil.

¿Qué le paso a mi certificado?

Estaba trabajando en un ambiente de Exchange cuando note cierta anomalía en el estado de un certificado que claramente sabia es válido, luego de hacer la investigación respectiva les comparto la solución.

Resulta que en ciertos casos la información sobre la lista de revocación de certificados expira o bien la información sobre el estado de estos, dicha información Windows la obtiene por medio del servicio de WinHttpAutoProxySvc el cual en este escenario no estaba configurado apropiadamente.
Entonces vamos a hacer los siguiente, eliminar la información del CRL y OCSP y luego configurar el proxy y las excepciones apropiadas para que este pueda obtener la información, algo muy sencillo con los siguientes comandos:
certutil -urlcache ocsp delete
certutil -urlcache crl delete
netsh winhttp set proxy proxy-server="http://192.168.1.22:8080;https://192.168.1.22:8080" bypass-list="*.microsoft.com"
En algunos casos es necesario reiniciar el servicio, también para que el cambio se refleje debe usted reiniciar el EMC.
Recordemos que este servicio brinda a ciertos Win32 APIs y objetos COM la facilidad de peticiones tipo HTTP.
Esta configuración es explicita al servicio y no afecta la configuración que el/los usuarios tengan en su navegador.
(*192.168.1.22:8080 = tu servidor proxy:puerto del servicio)

Aclaración.

Desde hace unos meses cambie mi badge por uno azul con el logo de Microsoft, acepte una plaza como PFE así que con suerte llegue a conocer a algunos de mis lectores.

Tan solo deseo aclarar que este es mi blog personal, donde comparto parte de mi vivir diario, mi idea es únicamente compartir y documentar ciertas experiencias con la finalidad de ayudar a la gente, esto es mi blog, mi punto de vista y no tiene nada que ver con Microsoft.

De ninguna manera aunque yo sea un empleado de la empresa esto representa un punto de vista oficial de esta, ni tampoco tiene aval técnico alguno por su parte.

Como lo expresé en mis inicios tampoco hay algún tipo de garantía que mis humildes artículos sean exactamente lo que usted necesita, de hecho como abran notado frecuentemente también utilizo herramientas de terceros (no MSFT) pero como todos sabemos en el mundo de la informática hay mil y una formas de solucionar un problema… o hacerlo más grande.

La información acá descrita no revela datos de algún ambiente o cliente explicito, de hecho antes de publicar algo lo recreo en mi propio ambiente de pruebas para así evitar divulgar dato alguno.

Gracias por su tiempo e interés.

Curiosidades de las bases de datos.

Notas rapidas desde el campo de batalla.
1-      Ya no existe el evento 1207 por lo cual para saber el espacio en blanco necesitamos ejecutar algo como: Get-MailboxDatabase -Status | Select-Object Server,Name,AvailableNewMailboxSpace

2-      A parte de los límites de retención de ítems borrados de 14 días también hay otro limite por espacio el cual por defecto es de 30GBs. Este lo podemos ver de la siguente forma: Get-MailboxDatabase | Select-Object Name,Server,RecoverableItemsQuota,RecoverableItemsWarningQuota

Les recomiendo tomar en cuenta estos simple puntos al momento de planear la capacidad de sus sistemas.

PortQry.exe múltiple.

Tan solo un script rápido que revisa el estado de ciertos puertos clave, en este caso de Controladores de Dominio.
Primero, tenemos un archivo con la lista de los controladores a revisar (serverList.txt), este archivo lo recorreremos revisando los puertos uno a uno (53, 88, 135, 389 y 3268), la información obtenida la almacenaremos en el archivo llamado “outcome-PortCheck.log”.
Realmente la información obtenida va a ser bastante así que en un siguiente paso haremos un tipo de resumen con la información clave que necesitamos  y seguidamente la enviaremos por correo electrónico.
Al revisar el script notaran que los archivos de la corrida anterior se eliminan, iniciando así de nuevo el ciclo.
No es nada sofisticado pero hace el trabajo.

@echo off
REM ### ~daemonRoot ##################################################
REM ### El siguiente script es una sencilla herramienta de monitoreo de los puertos claves de los controladores ###
REM ### de dominio ###
REM ### Removiendo archivos anteriores ###
del C:\scripts\sum-PortCheck.log
del C:\scripts\outcome-PortCheck.log
REM ### Revisando puerto 53 (DNS) ###
for /f %%a in (C:\scripts\serverList.txt) do (echo hostName=%%a >>C:\scripts\outcome-portCheck.log) && (portqry -n %%a -e 53 >>C:\scripts\outcome-PortCheck.log)
REM ### Revisando puerto 88 (Kerberos) ###
for /f %%a in (C:\scripts\serverList.txt) do (echo hostName=%%a >>C:\scripts\outcome-PortCheck.log) && (portqry -n %%a -e 88 >>C:\scripts\outcome-PortCheck.log)
REM ### Revisando puerto 135 (RPC) ###
for /f %%a in (C:\scripts\serverList.txt) do (echo hostName=%%a >>C:\scripts\outcome-PortCheck.log) && (portqry -n %%a -e 135 >>C:\scripts\outcome-PortCheck.log)
REM ### Revisando puerto 389 (LDAP) ###
for /f %%a in (C:\scripts\serverList.txt) do (echo hostName=%%a >>C:\scripts\outcome-PortCheck.log) && (portqry -n %%a -e 389 >>C:\scripts\outcome-PortCheck.log)
REM ### Revisando puerto 3268 (GlobalCatalog) ###
for /f %%a in (C:\scripts\serverList.txt) do (echo hostName=%%a >>C:\scripts\outcome-PortCheck.log) && (portqry -n %%a -e 3268 >>C:\scripts\outcome-PortCheck.log)
REM ### Creando resumen ###
type outcome-PortCheck.log | findstr /i "hostname= listening filtered" >>C:\scripts\sum-PortCheck.log
REM ### Enviando resultados... ###
BLAT C:\scripts\sum-PortCheck.log -to engineering@sysadmin-cr.com -s "Reporte de Puertos de AD" -server smtp.sysadmin-cr.com -f daemonroot@sysadmin-cr.com
REM ### El archivo de salida debe ser analizado para tomar las respectivas acciones ###
REM ### ~daemonRoot ##################################################

cuando un cliente borra un ítem...

En las versiones de Outlook, cuando un cliente borraba un ítem de su buzón de correo… kaput, este era eliminado y la única manera de retenerlo era a través de una restauración de la base de datos. A partir de Exchange 2000 se introduce el “dumpster”, lo cual es un segundo repositorio especial donde se almacenan los ítems que fueron borrados por el usuario o bien por las políticas de retención.
En Exchange 2003 estos ítems eran retenidos por 7 días por defecto, a partir de Exchange 2007 esto se incrementó a 14; a grandes rasgos les comento que los ítems simplemente permanecían ocultos por medio del MAPI flag llamado “ptagDeletedOnFlag”.
Ya en Exchange 2010 estos son almacenados en una subcarpeta llamada “Deletions” dentro de la carpeta “Recoverable Items”. Otro punto que cabe resaltar es la versatilidad que nos brinda Outlook Web App para la recuperación de estos. Estas y otras mejoras más se hicieron para cumplimiento de regulaciones de retención, búsqueda y otras.
Debo resaltar que estos ítems no son considerados en los cálculos de la cuota de buzón, pensemos que userA tiene una cuota de 100MBs, en un día promedio este recibe el equivalente a 40MBs de correos, de los cuales desecha digamos 30MBs. Por ende el “dumpster” recibe 30MBs por día y si el valor por defecto de retención es de 14 días entonces 30 x 14 + 100 = 520MBs… Como cambio la perspectiva de los 100MBs de cuota por N usuarios en el servidor!… Creo que con esto ya ustedes están pensando cuan acertados son sus cálculos para el almacenaje de Exchange, lo cual es exactamente el punto de mi artículo.
Realmente desconozco alguna regla de oro para calcular este tipo de cosas, pero firmemente creo que el análisis continuo y proactivo de nuestro ambiente nos ayuda a determinar qué es lo más adecuado para este y también como prepararnos para futuros cambios.
Con una línea como esta puedes obtener información detallada de los buzones de correo alojados en un servidor determinado, exportando dicha información en un archivo con formato CSV:

Get-MailboxStatistics -Server hostname | Sort-Object TotalItemSize -Descending | Select DisplayName, MailboxGUID, ItemCount,TotalItemSize, DatabaseName, StorageLimitStatus, TotalDeletedItemSize | Export-CSV daemonR00t.csv

O bien le agregamos un par de funciones para convertir los datos en MBs:

Get-MailboxStatistics -Server excMBX00 | Sort-Object TotalItemSize -Descending | Select DisplayName, MailboxGUID, ItemCount,@{expression={$_.totalitemsize.value.ToMB()}}, DatabaseName, StorageLimitStatus, @{expression={$_.totaldeleteditemsize.value.ToMB()}} | Export-CSV daemonR00t.csv

También sugiero echar un vistazo a los eventos 1207 (EXC 2003/2007) ya que estos nos brindan la información sobre las tareas de purgado del cache de objetos borrados o “dumpster”.

Ya poniéndonos un poco creativos lo anterior lo podemos ejecutar en una tarea programada, que luego nos envíe el archivo de salida como un adjunto en un corre y así mantener los datos históricos para analizar tendencias y demás, pero ya es pasada la media noche y mañana me espera mucha más diversión frente a la consola así que, hasta pronto!