Virtualización de controladores en Windows Server 8 “Beta”

Y bien pues uno de los grandes atractivos de Windows Server 8 es el soporte para el clonado de controladores virtuales, así como un mecanismo de seguridad para prevenir problemas de USN rollback.

En el caso del clonado pues por medio del VM-Generation ID (para lo que requerimos una plataforma de virtualización con dicha capacidad [por ahora solo Windows 8 Server, pero esto esta “abierto” para que otros lo implementen, aunque no se quien desearía otra plataforma de virtualización]), además el controlador con la función de PDC Emulator debe de correr sobre una plataforma física y con el sistema operativo Windows Server 8.

Esto funciona muy similar al concepto del invocationID, simplificando es una forma única de identificar la copia del DIT o para este caso, la maquina virtual, en este escenario el PDC Emulator detecta que esto es un clon y si cumple con los requerimientos pues le autoriza el proceso de clonado, el cual creara una nueva cuenta para el equipo así como un nuevo SID y otros para identificar esta entidad.

Le insto a visitar los siguientes vínculos para obtener mas información “Active DirectoryDomain Services (AD DS) Virtualization” y “Understand and TroubleshootVirtualized Domain Controller (VDC) in Windows Server "8" Beta”.

Hasta muy pronto!

Nuevos cmdlets...

Sabías que hay 58 cmdlets nuevos en el módulo de Active Directory de Powershell v3, sí el que viene en Windows 8 Server.

Les adjunto la lista de lo nuevo por ahora…

Add-ADCentralAccessPolicyMember

Add-ADResourcePropertyListMember      

Clear-ADClaimTransformLink    

Get-ADCentralAccessPolicy

Get-ADCentralAccessRule 

Get-ADClaimTransformPolicy    

Get-ADClaimType

Get-ADDCCloningExcludedApplicationList

Get-ADReplicationAttributeMetadata

Get-ADReplicationConnection   

Get-ADReplicationFailure

Get-ADReplicationPartnerMetadata      

Get-ADReplicationQueueOperation

Get-ADReplicationSite

Get-ADReplicationSiteLink

Get-ADReplicationSiteLinkBridge

Get-ADReplicationSubnet

Get-ADReplicationUpToDatenessVectorTable        

Get-ADResourceProperty  

Get-ADResourcePropertyList    

Get-ADResourcePropertyValueType

Get-ADTrust

New-ADCentralAccessPolicy

New-ADCentralAccessRule 

New-ADClaimTransformPolicy    

New-ADClaimType

New-ADReplicationSite   

New-ADReplicationSiteLink

New-ADReplicationSiteLinkBridge

New-ADReplicationSubnet 

New-ADResourceProperty  

New-ADResourcePropertyList    

Remove-ADCentralAccessPolicy  

Remove-ADCentralAccessPolicyMember    

Remove-ADCentralAccessRule    

Remove-ADClaimTransformPolicy 

Remove-ADClaimType      

Remove-ADReplicationSite

Remove-ADReplicationSiteLink  

Remove-ADReplicationSiteLinkBridge    

Remove-ADReplicationSubnet    

Remove-ADResourceProperty

Remove-ADResourcePropertyList 

Remove-ADResourcePropertyListMember   

Set-ADCentralAccessPolicy

Set-ADCentralAccessRule

Set-ADClaimTransformLink

Set-ADClaimTransformPolicy

Set-ADClaimType

Set-ADReplicationConnection

Set-ADReplicationSite

Set-ADReplicationSiteLink

Set-ADReplicationSiteLinkBridge

Set-ADReplicationSubnet

Set-ADResourceProperty

Set-ADResourcePropertyList

Sync-ADObject

Test-ADServiceAccount

Como estamos en una fase de  “preview” pues aun no existe toda la documentación del caso, aun así ya hemos trabajado con alguno de estos comandos de forma satisfactoria.

Y no olvidemos el modulo nuevo  que nos ayuda para temas de implementación de controladores, he aquí la lista de cmdlets de este modulo.

Get-Command -Module ADDSDeployment | Select Name

Name

----

Add-ADDSReadOnlyDomainControllerAccount

Install-ADDSDomain

Install-ADDSDomainController

Install-ADDSForest

Test-ADDSDomainControllerInstallation

Test-ADDSDomainControllerUninstallation

Test-ADDSDomainInstallation

Test-ADDSForestInstallation

Test-ADDSReadOnlyDomainControllerAccountCreation

Uninstall-ADDSDomainController

Acá copio algunos ejemplos que nos pueden ayudar en el día a día del administrador.

• Para crear un nuevo sitio, protegido contra borrado accidental y con Universal Group Caching habilitado:

New-ADReplicationSite -Name siteB -ProtectedFromAccidentalDeletion $true -UniversalGroupCachingEnabled $true

• Para crear un enlace de replicacion entre sitioA y sitioB, este utilizando el protocolo de SMTP, con un costa de 500 y una frecuencia de replicación de 180 minutos.

New-ADReplicationSiteLink -Name siteA-siteB -InterSiteTransportProtocol SMTP -SitesIncluded "siteA", "siteB" -Cost 500 -ReplicationFrequencyInMinutes 180

• Para crear una subred y ligarla al sitio que recién creamos.

New-ADReplicationSubnet -name 13.0.0.0/24 -site siteB

Espero esto les despierte la curiosidad por ver que mas hay… justo como me paso a mi.

Gracias por su tiempo.

Promoviendo mi primer Windows Server 8

Buenas! Imagino usted también esta emocionado con husmear un poco en lo que es Windows 8, sí realmente es bonito esto del interfaz Metro, pero en mi caso lo mio es la parte de servidor.

En este pequeño articulo veremos lo que es la promoción de un controlador, el primer controlador en Server 8, este en un ambiente donde los demás DCs son Windows Server 2008 R2.

Como ya es costumbre deberemos ejecutar el famoso ADPREP, el cual lo encontraremos en el disco de instalación en la carpeta support, el proceso es muy similar, desde la consola de comandos con derechos elevados invocas el utilitario con el parámetro /forestprep. Con estos cambios llevaremos nuestro esquema a la versión 52.

La primer gran diferencia que notaremos es que el amigo “dcpromo” ya no esta, ahora todo el enfoque lo tenemos en el Server Manager.  De hecho espero poder escribir mas sobre este pues a sido mejorado notablemente.

Para verlo de una forma sencilla primero aplicaremos los binarios necesarios y luego configuraremos el controlador.

 Debo resaltar que este proceso es bastante detallado y casi en todas las etapas encontraremos hipervínculos que nos brinden mas información sobre el proceso actual.

Acá según el escenario podremos agregar controladores a un dominio existente, o bien un nuevo dominio o bosque.

Al igual podremos seleccionar otras funciones como DNS o RODC.

 Si la red donde se ubica nuestro equipo esta mapeada con algún sitio en la información contenida en la partición de Configuración acá se presentara el sitio en que el controlador será asignado o bien usted mismo lo podrá seleccionar según su necesidad.

 También se nos presentara la opción de configurar la contraseña del DSRM, recordemos que a partir de Windows Server 2008 esta puede tener diferentes comportamientos, esto lo configuramos a través de la llave de registro

HKLM\System\CurrentControlSet\Control\LSA\DsrmAdminLogonBehavior

Que puede contener los valores:

0 - Comportamiento por defecto, solo cuando se inicia el sistema en DSRM.

1 - En modo DSRM y cuando el servicio de NTDS esta detenido.

2 – En cualquier momento.

Esto es configurable para cubrir las necesidades en casos que detengamos el servicio del NTDS para dar algun mantenimiento al sistema, base de datos del directorio u otros.
En la siguiente pantalla se nos presentan aquellas “opciones avanzadas” donde especificas si estas haciendo una instalación desde un medio (IFM).
También podemos seleccionar el controlador contra el cual deseamos ejecutar la replicación inicial y las particiones de aplicación deseadas si fuera el caso.

A continuación podremos especificar la ruta donde almacenaremos la base de datos, así como sus bitácoras y la carpeta del SYSVOL.  

Finalmente como es costumbre se presenta la pantalla donde revisamos la información provista antes de ejecutar la instalación.

Desde luego podemos exportar los comandos relacionados a este proceso, esto nos será muy útil en casos futuros. Incluyo acá un ejemplo de dichos cmdlets.

#

# Windows PowerShell script for AD DS Deployment

#

Import-Module ADDSDeployment

Install-ADDSDomainController `

-DoNotConfigureGlobalCatalog:$false `

-CreateDNSDelegation:$true `

-CriticalReplicationOnly:$false `

-DatabasePath "C:\Windows\NTDS" `

-DomainName "contoso.com" `

-InstallDNS:$true `

-LogPath "C:\Windows\NTDS" `

-RebootOnCompletion:$true `

-ReplicationSourceDC "dae-dc-01.contoso.com" `

-SiteName "HQs" `

-SYSVOLPath "C:\Windows\SYSVOL" `

-Force:$true

Notaron el nuevo modulo llamado “ADDSDeployment”, si algo mas que aprender. Vale la pena recalcar que esto lo podemos hacer tambien de forma remota, pues ahora el Server Manager te permite administrar equipos remotos e inclusive agruparlos lógicamente para manejar varios equipos al mismo tiempo en caso de que su configuración sea similar.

Si la revisión de los pre-requisitos es satisfactoria entonces la instalación procederá, de lo contrario se nos brindara información detallada sobre los temas a tratar.

Nótese también que al ser esto una versión Beta aun no aparece soportada en WSUS, por ende deberá conectarse a Internet para descargar las actualizaciones referentes, al momento de este articulo únicamente 3 paquetes habían disponibles.

En este caso explicito la plataforma de virtualización es Windows Server 2008 R2; por ser este un host en Windows 8 Server las herramientas adicionales de virtualización ya vienen incluidas en el sistema operativo, por ende no deberá preocuparse de dicho proceso.

Como hemos visto este es un proceso bastante fluido y sin complejidad alguna, espero pronto este ustedes estén promoviendo sus nuevos controladores en Windows 8 Server.

Hasta pronto!

dssite.msc

Alguna vez han notado que la consola DSSITE se llama "Active Directory Sites and Services" pero no hay nada en dicha interfaz que haga referencia a los servicios?

Claro y por ende cuando debemos hacer algún trabajo relacionado a estos pues debemos ir al (para algunos) muy temido y oscuro ADSIedit.

Bien pues la solución está a un clic de distancia, pues si miras en el menú de View, ahí está la opción de Show Services Node.
Perfecto, ahora ya pueden manipular los servicios como Exchange, Lync, RRAS, PKI y otros.

Hasta pronto!

y mi RID pool?!

Cada security principal (computer, user, group, OU) tiene un RID y otros métodos para ser identificado, pero dejemos eso para luego...
Estos son asignados por los controladores de domino, lo cuales piden al portador del FSMO llamado RID Master bloques de 500 RIDs para asignarlas según se soliciten, esto básicamente les da cierta autonomía para que estos puedan crear security principals.
Tomando esto en cuenta el gusanito de la curiosidad creo hace que usted se pregunte que bloque o segmento de RIDs actual tiene un controlador determinado.
Esto lo podemos averiguar por medio de un convertidor que tiene la herramienta LDP.
Al ejecutar LDP, luego vaya a la opción de Bind y presione OK en la siguiente pantalla, eso le llevara al RootDSE bajo el contexto de seguridad actual.
Luego navegue a la opción de View, a continuación seleccione Tree navigate y presione OK, esto le permitirá navegar la partición de domino.
Navegue al OU donde están los controladores, en mi caso OU=Domain Controllers,DC=contoso,DC=com.
Si expande dichos objetos vera una serie de objetos hijos, para este escenario nos interesa el RID Set y los atributos de este rid* como se muestra en la imagen.



Toma el valor del rIDAllocationPool, navega a Utilities, Large Integer Converter, pega el valor
anterior y presiona el boton Run.

En mi caso esto me revela que mi segmento de RID inicia en 28600 (Low Part) y finaliza en 29099 (High Part).
Puedo saber con el mismo procedimiento cual fue el pool o segmento de RIDs anteriormente asignado (rIDPreviousAllocationPool) o bien el ultimo RID asignado (rIDNextRID).
Otra cosa interesante que podríamos hacer en este mismo tema es mirar el objeto RID Manager$ que está ubicado en el contenedor llamado System en el mismo contexto de nombres.
En dicho objeto el rIDAvailablePool no indica el total de RID disponibles nuestro domino.
Además acá podemos mirar "quien" nuestro DC cree es el fSMORoleOwner o dicho de otra manera cual DC es el portador del FSMO de RID Master.
Bueno, espero esto les ayude a tener una mejor comprensión de sus controladores y su ambiente.
Como ya sabemos pronto saldrá el preview de Windows Server 8... cuando lo tengan les insto a hacer este ejercicio en esta versión del sistema ;-)
Hasta pronto!

Service Pack 2 E14 "Database is mandatory on UserMailbox"

Algo rápido pues el tiempo es algo que últimamente escasea.
Si se encuentran con este error al aplicar el SP2 a sus Exchange 2010...

Les invito a darle un vistazo a las cuentas del sistema como "FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042" y "Discovery Search Mailbox"
Probablemente el homeMDB de estos no este poblado o apunte a un buzón que ya no existe.
Hasta pronto! (eso espero).

Buscando computadoras virtualizadas.

Una rápida desde el campo de batalla.

Como encontrar maquinas virtualizadas con Hyper-V, pues ellas crean un objeto SCP en AD, este en el caso de los hosts que ofrecen el servicio es algo como lo siguiente:

D:\>adfind -f “(&(objectClass=serviceConnectionPoint)(cn=Microsoft Hyper-V))”

dn:CN=Microsoft Hyper-V,CN=DAE-DC-01,OU=Domain Controllers,DC=contoso,DC=com

>objectClass: top

>objectClass: leaf
>objectClass: connectionPoint
>objectClass: serviceConnectionPoint
>cn: Microsoft Hyper-V
>distinguishedName: CN=Microsoft Hyper-V,CN=DAE-DC-01,OU=Domain Controllers,DC=contoso,DC=com
>name: Microsoft Hyper-V
>keywords: Service mode=Standalone server
>serviceBindingInformation: dae-dc-01.contoso.com
>serviceBindingInformation: RDP listener port=2179
>serviceBindingInformation: msxml://D:\ProgramData\Microsoft\Windows\Hyper-V\InitialStore.xml
>objectCategory: CN=Service-Connection-Point,CN=Schema,CN=Configuration,DC=contoso,DC=com

 Acá el output lo filtre un poco, cabe resaltar los atributos keywords (me indica si es in servidor stand-alone o cluster) y el serviceBindingInformation (indica el host ofreciendo el servicio y el puerto entre otros).

Ahora para un equipo virtualizado la consulta sería algo similar a esto:

D:\>adfind -f “(&(objectClass=serviceConnectionPoint)(cn= Windows Virtual Machine))”

dn:CN=Windows Virtual Machine,CN=DAE-DC-03,OU=Domain Controllers,DC=contoso,DC=com

>objectClass: top
>objectClass: leaf
>objectClass: connectionPoint
>objectClass: serviceConnectionPoint
>cn: Windows Virtual Machine
>distinguishedName: CN=Windows Virtual Machine,CN=DAE-DC-03,OU=Domain Controllers,DC=contoso,DC=com
>name: Windows Virtual Machine

Como podemos observar en el dn de ambos objetos estos son objetos hijos de la cuenta computadora en cuestión, esto no son visibles desde ADUC.

Todo lo anterior lo podrían hacer también con WMI pero no es algo que yo maneje con tanta destreza y además eso requeriría consultas a los equipos versus este método que toma ventaja del directorio.

Saludos.

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!

No tocar [MpsSvc]...

Creo que muchas personas concordarían conmigo al razonar que: si en un sistema detenemos el Windows Firewall (MpsSvc) nuestro sistema quedaría desprotegido, permitiendo acceso total a este. Pues esto no es cierto, al contrario. A partir de Windows Server 2008 al detener o deshabilitar dicho servicio encontraremos que el sistema caerá en cierto estado de bloqueo donde por ejemplo servicios como IPSec o Windows Service Hardening no funcionaran. Aun mas, en el caso de los controladores de dominio estos denegaran todo trafico entrante pero si permitirán el trafico saliente (créanme no es nada agradable). Por ende o corres al centro de datos o te conectas por alguna herramienta como el ILO de HP o el DRAC de Dell para iniciar el servicio, pero mientras no haces no tendrás nada, no resolución de nombres, no autenticación, nada.

DAG caído/eliminado parcialmente.

Hay momentos en que las estrellas es alinean, causando erupciones volcánicas, ciclones, usnRollBacks y que tu DAG muera… todo en cuestión de minutos y afectando tu servicio de directorio y mensajería.

En este pequeño articulo relatare un poco sobro como solucione este problema para volver a tener nuestro DAG (la parte del usnRollBack yo no la trabaje pero hay bastante información en la web… Bing es su amigo en estos casos).

Primero que nada unos conceptos, cuando creas un DAG veras dos objetos uno en la partición de configuración en “CN=Database Availability Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=tuOrganizacion,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=sysadmin-cr,DC=com” tipo “msExchMDBAvailabilityGroup” el cual es el DAG en sí, este contiene parámetros de configuración como el file share witness, dirección IP y otras. El segundo objeto lo encontraremos en la partición de dominio, un objeto tipo “computer” que es la representación del DAG, este lo llamaremos el “CNO (Cluster Name Object)”.
Además de esto nos interesa el atributo “msExchMDBAvailabilityGrouoLink” que está en los objetos tipo “msExchExchangeServer”, básicamente acá se apunta la membresía del servidor con el DAG. De hecho en el objeto del DAG este se refleja como el “msExchMDBAvailabilityGrouoLinkBL”
Muy bien, recordemos que no podemos eliminar un equipo de un DAG si este tiene copias de bases de datos por lo cual estas deben de ser eliminadas. Una vez que nuestros bases de datos de buzones no tengan copia alguna entonces será posible modificar la membresía del DAG removiendo sus miembros. Les sugiero dar un vistazo al “msExchMDBAvailabilityGroupLink” para evitar problemas más adelante.
Ahora que el DAG no tiene miembros lo podremos remover sin problema alguno.
Nótese que este no es el proceso normal, acá estoy trabajando en caliente con un ambiente en producción, no hay más servidores de Mailbox disponibles ni otras opciones, valore usted su posición antes de proceder de una manera así de drástica.
Una vez eliminado el DAG debo de detener y deshabilitar el servicio del “Cluster Service” esto en cada miembro del antiguo DAG.
También debo mencionar que en las bases de datos o “msExchPrivateMDB” (buzones de correo) y/o “msExchPublicMDB” (carpetas compartidas) se refleja cual es el servidor primario de dicha base de datos, llamado “master”. Esta información se almacena en el “msExchMasterServerOrAvailabilityGroup” el cual muy probablemente luego de eliminar el DAG va a mostrar el GUID del objeto borrado y otra información que no le será muy común, basta con actualizar este atributo con el “distinguishedName” del  servidor que ahora hospeda la base de datos. Uno de los cambios en Exchange 2010 es el hecho de que las bases de datos son portables, estas ya no están ligadas a un servidor especifico, solamente se hospedan en estos, pero esto también la necesidad de que su nombre sea único en la organización de Exchange.
En nuestro caso en CNO no existía y las opciones de restauración eran nulas.
Como siguiente paso pre-configuraremos el objeto del CNO, creando un objeto tipo “computer” en el contenedor de nuestra elección, dicho objeto debe estar deshabilitado y además necesitamos darle “Full Control” al grupo del “Exchange Trusted Subsystem” y al primer equipo que vayamos a unir al DAG. Desde luego esto luego de un tiempo prudencial para la replicación de Active Directory.
Cuando agreguemos dicho equipo al DAG parte de las modificaciones que se realizaran habilitaran la cuenta, mantenga esto en mente por si el proceso falla que usted verifique dicho objeto continúe deshabilitado.
Si usted pudo agregar el miembro del DAG exitosamente pues es usted el héroe y feliz administrador de un DAG, a partir de este punto la administración es completamente normal.
Se agregan y configuran otros miembros, las redes, copias de bases de datos y demás.
Cualquier duda sugiero dar un vistazo a http://technet.microsoft.com/en-us/library/ff367878.aspx , http://technet.microsoft.com/en-us/library/dd351172.aspx y finalmente http://technet.microsoft.com/en-us/library/dd298065.aspx
Hasta pronto!

Exclusión del PDC.

Cuando diseñamos ambientes tecnológicos a veces se nos olvida uno que otro detalle… a algunos esto nos pasa muy a menudo por ende mejor documento esto.
En ciertos escenarios puede darse que nuestros servidores de Exchange empiecen a hablar/consultar al servidor que es el dueño del FSMO de PDC Emulator, el cual por dicha condición ya tiene una cantidad de carga extra con respecto a los demás, razón por la cual quizás deseemos controlar o bien evitar esto.
En la primer opción podemos regular un mínimo de controladores disponibles antes de DSAccess empiece a consultar el PDC. Por ejemplo, tienes 10 controladores y se da una caiga, desde luego DSAccess hará los ajustes necesarios pero hasta que lleguemos al límite, digamos 3 no vamos a contactar al PDC.
http://technet.microsoft.com/en-us/library/aa998226%28EXCHG.80%29.aspx
O bien, podríamos simplemente excluirlo por completo, esto siguiendo las instrucciones provistas en el siguiente híper vinculo.
http://blogs.technet.com/b/richardroddy/archive/2010/06/16/msexchange-adaccess-dsaccess-errors-and-the-manage-auditing-and-security-right.aspx
Claro no hay una receta mágica y cada ambiente es diferente, la primer opción deja la probabilidad de la utilización del PDC por el DSAccess, mientras que la segunda no. Factores como frecuencia de cambios en políticas, sistemas de provisión de cuenta y/o cambio de contraseñas y otros relacionados al rol deben de tomarse en cuenta al realizar esta configuran.
Bueno espero este les ayude a tener mayor control sobre su ambiente y a la vez mejorar su experiencia con este.
Hasta pronto!