En las segunda entrega de la traduccion de articulos mas populares de ASKPFEPLAT, les traemos este post acerca de la carpeta SxS.Para ver el articulo original, haz clic aquí.

Recuerdan estas carpetas en Windows 2003 Server?

No recuerdo cuantas veces me han preguntado cómo depurarlas.

Aparentemente no soy el único que odia el desorden.

Y qué me dices de la ventana que pide que introduzcas el CD-ROM que aparece en los momentos más inoportunos? He tenido experiencias en las que tengo un servidor crítico caído y nadie encontraba un CD.

Corrupción de archivos, reparaciones, instalación de nuevas características, todo requiere el CD.

Introducción al almacén de componentes

Con Windows 2008 en adelante, hubo un cambio de este Viejo método al directorio Windows Side-by-Side (WinSXS), y hubo mucho regocijo ya que introdujo muchas características nuevas que facilitaban el trabajo de los administradores:

· Ya no se requiere un CD cuando se instala un rol o característica nueva ( a menos que la hayas removido por complete lo cual se aplica a Windows Server 2012)

· Reparación automática de archivos corruptos usando una copia fiel del almacén de componentes.

· Las herramientas de reparación como el Revisor de archivos de sistema (sfc.exe) no requiere un CD.

· Todas las versiones previas de los archivos de sistema operativo se almacenan y las versiones nuevas también (en caso de que instales un rol o característica en el futuro)

Sin embargo hay algunas preguntas:

Que es este directorio winsxs y por qué es tan grande? Mira más abajo

Lo puedo borrar? No.

Lo puedo mover? No.

Lo puedo depurar? Depende…

Escribimos un artículo referente a esto:

http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx

El punto es que a pesar de que desinstales un rol/característica los archivos aun estarán ahí junto con todas las actualizaciones que puedan ser requeridas.

Hay otro buen artículo que habla de cómo recuperar espacio después de un service pack.

http://blogs.technet.com/b/joscon/archive/2011/02/15/how-to-reclaim-space-after-applying-service-pack-1.aspx también este: http://support.microsoft.com/kb/2795190/EN-US

 

Windows Server 2012 Features on Demand (características bajo demanda)

Entonces llego Windows Server 2012 Features on Demand, el cual te permite remover cualquier rol/característica no necesitado sin afectar nada. Hasta ahora.

Es muy sencillo de utilizar con 3 simples pasos:

1) Abre una ventana de PowerShell (administrativa)

2) Usa el comando Get-WindowsFeature para encontrar el rol/característica

3) Para desinstalar, ejecuta el siguiente comando:
Uninstall-WindowsFeature –name <nombre del rol/característica> -remove

Tip: agrega el switch –Whatif al final para ver exactamente lo que será removido sin removerlo.

Para que hacer esto? Te daré tres razones:

1) Reducir el tamaño de la instalación base del SO.

2) Reducir el número de parches potenciales (y también reinicios)

3) Incrementar la seguridad removiendo características que no sean integrales para el rol del servidor.

Pero no te preocupes. Puedes añadirlos nuevamente después J

Entonces qué pasa si tratas de reinstalar un rol o característica que ha sido removido completamente?

Bueno, te daremos una advertencia diciendo que el rol no se encuentra y trataremos de obtenerlo de

Windows Update (o WSUS), alguna localidad especificada por GPO o manualmente especificar una ruta alterna.

Como se ve esto en powershell?

Para principiantes, cuando ejecutas el comando Get-Feature, te mostrara el rol o característica como Removido:

Si aun así intentas agregar el rol o característica a través de Powershell, así es como se ve:

En este punto, es obvio que no tenemos la GPO configurada con la ubicación alterna. Podemos darle acceso a internet al servidor y permitirle obtener la característica desde Windows update, si es posible, o podemos especificar una ubicación origen con el comando Install-WindowsFeature especificando el switch –Source. Aquí un ejemplo:

Install-WindowsFeature web-server –source {ubicación origen}

Así se ve desde la interfaz gráfica:

Si haces clic en “Specify an alternate source path option” aparece la siguiente ventana:

Puedes especificar una carpeta compartida que contenga el archivo install.wim, pero también necesitas especificar el índice de la imagen dentro del archive WIM. Mas al respecto en un minute…

Si quieres configurar esto desde antes puedes usar una GPO, la política que se configura es Computer Configuration\Administrative Templates\System\Specify settings for optional component installation and component repair

Así es como se ve la política cuando es configurada y habilitada:

Resaltando las opciones Never attempt to download payload from Windows Update o Contact Windows Update directly to download repair content instead of Windows Server Update Services (WSUS). Estas opciones pueden ser útiles dependiendo la configuración de tu ambiente.

Personalmente pienso que es bastante bueno poder apuntar al archivo install.wim en vez de una carpeta compartida con un listado plano de archivos de instalación.

Para hacerlo se especifica el parámetro WIM junto con la carpeta compartida que contiene el archivo install.wim. También tenemos que especificar qué imagen dentro del archivo install.wim queremos usar como origen.

Para aquellos que no saben, un archivo .wim, es simplemente un contenedor que contiene (valga la redundancia) una o más imagines. Estas pueden ser imágenes personalizadas que hayas creado y capturado tú mismo, imágenes modificadas con actualizaciones inyectadas, o solo las imágenes base contenidas en el archivo .wim teniendo el cd de Windows server 2012 como origen.

Entonces, el número del índice que debemos proveer podría ser diferente dependiendo del archivo install.wim que apuntemos como nuestro origen.

Para encontrar que imagen quieres usar, ejecuta el comando dism /get-Wiminfo /wimfile:{ubicación del install.wim} para mostrar las imagines contenidas dentro del archivo. Así es como se ve para el archivo default:

Como estoy instalando Windows Server 2012 Standard en mi ambiente, necesito especificar un índice de 2. La mayoría de ustedes probablemente están instalando Windows Server 2012 Standard también, a menos que estén instalando servidores Hyper-V, entonces es más probable que estén usando la versión Datacenter o incluso Server Core. Sin embargo, no hay diferencias especificas en los roles existentes en diferentes versiones. Así que realmente, podría especificar un índice de 2 o 4 y estaría bien.

El resultado final es que mi ruta alterna se ve así:

Wim:\\KMS-2012\2012_Source\install.wim:2

Ahora cada vez que reinstale mi rol o característica, utilizara este origen y funciona muy bien!

Cosas a considerar cuando usas el archivo install.wim como tu origen:

· Conforme aplicas actualizaciones a tus servidores, querrás mantener tu archivo .wim actualizado también. Por qué es esto? Si removiste un rol o característica después de haber sido actualizado, es posible que la actualización que aplicaste previamente aplique a varios roles o características por lo tanto no fue removida. Cuando intentas reinstalar el rol usando el archivo .wim como origen, si no tiene el mismo nivel de actualizaciones que el servidor, esta operación fallara. Si es más Nuevo de lo esperado no hay problema. El problema es solo con versiones más Viejas.

· Cuando removemos un rol o característica, también se eliminan los archivos asociados con el mismo, pero no se desinstalan las actualizaciones que ya hayan sido aplicadas. Cuando el rol o característica son reinstalados necesitamos archivos de cualquier actualización que haya sido aplicada.

· Está bien si el archivo install.wim este más actualizado que el servidor en el que estas habilitando el rol o característica. La parte más importante es que el archivo install.wim tenga los archivos de todas las actualizaciones aplicadas al servidor afectado. También, si el archivo install.wim es más reciente que el servidor, al habilitar el rol o característica se instalaran nuevas actualizaciones directamente del archivo .wim. Para actualizar completamente el servidor, se necesita aplicar nuevas actualizaciones de la forma normal ya sea WSUS o manualmente.

Si crees que es mucho trabajo, utiliza Windows update siempre y cuando el servicio no este deshabilitado, bloqueado por un firewall o por política de grupo; si no encontramos lo que requerimos en el archivo install.wim o en el servidor, buscaremos automáticamente en Windows Update. Funciona muy bien! J

Disfrútenlo!

~ Charity “reducir el tamano de las instalaciones base es el futuro?” Shelbourne

Una entrega mas de la traduccion de articulos mas populares de ASKPFEPLAT, les traemos este post.Para ver el articulo original, haz clic aquí.

Windows Server 2012 provee mejoras mayores al rol de Hyper-V, incluyendo consolidación incrementada de cargas de servidores, replicación de Hyper-V, Actualizaciones de clústeres, utilización de red y el switch extendido de Hyper-V, solo por nombrar unos cuantos! Hyper-V 3.0, como algunos lo llaman, ayuda a las organizaciones a mejorar el uso de sus servidores y a reducir costos.

La siguiente es una lista que desarrolle para Windows Server 2008 R2 SP1 (que se puede encontrar aquí: http://blogs.technet.com/b/askpfeplat/archive/2012/11/19/hyper-v-2008-r2-sp1-best-practices-in-easy-checklist-form.aspx) y fue actualizada con la última distribución. Para aquellos que utilizaron mi lista anterior notaran que hay algunos elementos iguales; eso es porque muchas de las mejores prácticas también aplican para Hyper-V en Server 2012!

Creo que tener una lista puede ser una gran herramienta para usarse no solo cuando se revise una existente de Hyper-V, pero una que puede ser utilizada como parte de planeación para asegurarse que las mejores prácticas sean implementadas desde el principio.

Es importante notar que esta no es una compilación exhaustiva, más bien una agrupación de características/opciones comúnmente utilizadas en los negocios que he tenido el placer de atender.

Un agradecimiento especial a Ted Teknos, Ryan Zoeller y Rob Hefner por su colaboración/sugerencias/correcciones mientras compilaba esta lista!

Sin más que agregar, aquí está la lista actualizada de mejores prácticas de Hyper-V 2012!

---

Aviso: Como con todas las mejores prácticas, no todas las recomendaciones pueden - o deben- ser aplicadas. Las mejores prácticas son lineamientos generales, no son reglas rígidas que deban de ser seguidas al pie de la letra. Por lo tanto, debes de ser muy cuidadoso al revisar cada elemento y determinar si hace sentido en tu ambiente. Si una (o más) de estas mejores prácticas te aplica, excelente; si no, simplemente ignórala. En otras palabras, depende de ti decidir si las debes de aplicar o no.

---

GENERAL (HOST):

⎕ Considera utilizar Server Core, o la interfaz mínima de Windows, para reducir el uso de recursos así como la superficie de ataque y la cantidad de reinicios necesarios en tu servidor (debido a que se requieren menos actualizaciones)

• Información de Server Core: http://msdn.microsoft.com/en-us/library/windows/desktop/hh846313(v=vs.85).aspx
• Informacion de Windows Minimal Interface: http://msdn.microsoft.com/en-us/library/windows/desktop/hh846317(v=vs.85).aspx

⎕ Asegúrate que los hosts estén actualizados con respecto a las actualizaciones recomendadas de Microsoft, para asegurar que los parches críticos –que resuelven asuntos de seguridad o problemas al SO- sean aplicados.

⎕ Asegúrate que todos los parches para Hyper-V y clúster (si aplica) hayan sido aplicados. Revisa los siguientes sitios y compáralos con tu ambiente, ya que no todos los hotfixes son aplicables:

· Un colega en Microsoft, Cristian Edwards, ha publicado un script de powershell que detecta que actualizaciones de Hyper-V y Failover Clustering 2012 te hacen falta basado en la lista actualizada por el grupo de producto! Encuentra el script aquí: http://blogs.technet.com/b/cedward/archive/2013/05/24/validating-hyper-v-2012-and-failover-clustering-2012-hotfixes-and-updates-with-powershell.aspx

· Lista de actualizaciones para Windows Server 2012 Hyper-V: http://social.technet.microsoft.com/wiki/contents/articles/15576.hyper-v-update-list-for-windows-server-2012.aspx

· Lista de actualizaciones de Failover Clúster: http://support.microsoft.com/kb/2784261

⎕ Asegúrate que los hosts tengan la versión mas reciente del BIOS, así como cualquier otro dispositivo de hardware (tal como Synthetic Fibre Channel, Tarjetas de red, etc.), para reducir cualquier problema conocido/soportabilidad.

⎕ El Host debe de ser unido al dominio, a menos que los estándares de seguridad dicten lo contrario. Al hacer esto, es posible centralizar el manejo de políticas de identidad, seguridad y auditoria. Adicionalmente, los hosts deben de ser parte del dominio antes de crear un Clúster de alta disponibilidad de Hyper-V.

· Para obtener mayor información: http://technet.microsoft.com/en-us/library/ee941123(v=WS.10).aspx

⎕ RDP Printer Mapping debe de ser deshabitado en los hosts, para remover cualquier probabilidad de que un driver de impresión pueda causar inestabilidad en el host.

• Método Preferido: Utiliza Group policy con servidores host en su propia OU.
  • Computer Configuration –> Policies –> Administrative Templates –> Windows Components –> Remote Desktop Services –> Remote Desktop Session Host –> Printer Redirection –> Do not allow client printer redirection –> Configurada como "Enabled”

⎕ No instalar ningún otro role en el host aparte de Hyper-V y Remote Desktop Services (si VDI será utilizado en el host).

• Cuando el rol de Hyper-V sea instalado, el Sistema operativo (OS) se convierte en la “Partición Padre” (una cuasi-maquina virtual), y la partición de Hypervisor se localiza entre la partición padre y el hardware. Como resultado, no es recomendado instalar roles adicionales (no relacionados con Hyper-V o VDI).

⎕ Las únicas características que deben de ser instaladas en el host son: Failover Clúster Manager (si el host será parte de un clúster), Multipath I/O (si el host será conectado a una SAN iSCSI, Storage Spaces y/o Canal de Fibra), o Remote Desktop Services si VDI es utilizado. (Ver más arriba la explicación por que no es recomendado).

⎕ Software de Anti-virus debe de excluir archivos específicos de Hyper-V utilizando el siguiente artículo: Hyper-V: Antivirus Exclusions for Hyper-V Hosts, resumiendo:

• Todos los folders que contengan archivos VHD, VHDX, AVHD, VSV e ISO.
• Directorio default de configuración de máquinas virtuales, si es utilizado (C:\ProgramData\Microsoft\Windows\Hyper-V)
• Directorio default de snapshot si es utilizado (%systemdrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots)
• Directorio personalizado de configuracion de maquinas virtuales, si aplica.
• Directorio default de ubicacion de discos duros virtuales.
• Directorio personalizado de ubicacion de discos duros virtuales.
• Directorios de Snapshots.
• Vmms.exe (Nota: Puede ser necesario excluir el proceso)
• Vmwp.exe (Nota: Puede ser necesario excluir el proceso)
• Adicionalmente, cuando utilices Clúster Shared Volumes, excluye la ruta CSV "C:\ClusterStorage" y todos los subdirectorios.
• Para obtener mayor información: http://social.technet.microsoft.com/wiki/contents/articles/2179.hyper-v-anti-virus-exclusions-for-hyper-v-hosts.aspx

⎕ La ruta por default para los discos duros virtuales (VHD/VHDX) debería de ser establecida a un drive que no sea de sistema, debido a que esto puede causar lentitud además de potencialmente dejar al host sin espacio en disco.

⎕ Si decides guardar el estado de la máquina virtual como la acción automática cuando la MV es detenida, la ruta del directorio default no debe de ser un disco de sistema, debido a la creación de un archivo .bin el cual es del mismo tamaño de la memoria reservada para la máquina virtual. Un archivo .vsv también puede ser creado en la misma ubicación que el archivo .bin, incrementando el espacio de cada VM. (La ruta por default es: C:\ProgramData\Microsoft\Windows\Hyper-V.)

• Nota: Hyper-V en Server 2012 solo utilizara el archivo .bin si configuras la acción automática como “Guardar”
• Cambios al uso del archivo .bin en Server 2012: http://blogs.msdn.com/b/virtual_pc_guy/archive/2012/03/26/option-to-remove-bin-files-with-hyper-v-in-windows-8.aspx

⎕ Si estas usando iSCSI: Windows Firewall with Advanced Security, habilita iSCSI Service (TCP-In) para Inbound y iSCSI Service (TCP-Out) para outbound en cada host, para permitir que el trafico iSCSI pase desde el host hasta la SAN y viceversa. Al no habilitar esta regla, la comunicación iSCSI no será exitosa.

Para configurar la regla iSCSI firewall por medio de netsh, puedes utilizar el siguiente comando:

Netsh advfirewall firewall set rule group=”iSCSI Service” new enable=yes

⎕ Ejecuta contadores de desempeno en el host de manera periódica, para asegurar desempeño óptimo.

• Es recomendado utilizar el contador de desempeño de la aplicación PAL de Codeplex (gratis):
  • http://pal.codeplex.com/
• Instala PAL en una estación de trabajo y ábrelo, haz clic en la pestaña Threshold.
  • Selecciona "Microsoft Windows Server 2012 Hyper-V" del título Threshold file, y selecciona Export to Perfmon template file. Guarda el archivo XML a una ubicación accesible por el host de Hyper-V.
• Siguiente, en el host, abre Server Manager –> Tool –> Performance Monitor
• En Performance Monitor, clic en Data Collector Sets –> User Defined. Clic derech en User Defined y selecciona New –> Data Collector Set. Nombra el collector set "Hyper-V Performance Counter Set" y selecciona Create from a template (Recommended) Clic en siguiente. En la siguiente pantalla, selecciona Browse y ubica el archivo XML que exportaste desde PAL. Una vez hecho esto, esto se mostrara en tus “User Defined Data Collector Sets.”
• Ejecuta estos contadores en Performance Monitor por 30 minutos a 1 hora (durante horarios de alta utilización) y busca problemas de velocidad de disco, memoria, CPU, etc.

GENERAL (VMs):

⎕ Asegúrate que estés corriendo solo sistemas operativos soportados en tu ambiente. Para una lista completa puedes usar la siguiente dirección: http://blogs.technet.com/b/schadinio/archive/2012/06/26/windows-server-2012-hyper-v-list-of-supported-client-os.aspx

Tarjetas de Red físicas:

⎕ Asegúrate que las tarjetas de red tengan el firmware actual, el cual muchas veces resuelve problemas conocidos.

⎕ Asegúrate que los controladores de las tarjetas de red estén actualizados en el host, esto resolverá problemas conocidos y/o incrementara el desempeño.

⎕ Las tarjetas de red no deben de usar direcciones IP automáticas APIPA (Automatic Private IP Addressing). APIPA no es ruteable y no es registrado en DNS.

⎕ VMQ debería de ser habilitado en adaptadores de red físicos conectados a un switch virtual externo.

• Para obtener mayor información:
  • http://social.technet.microsoft.com/wiki/contents/articles/13066.hyper-v-vmq-should-be-enabled-on-vmq-capable-physical-network-adapters-bound-to-an-external-virtual-switch.aspx
  • http://blogs.technet.com/b/cedward/archive/2011/04/13/hyper-v-networking-optimizations-part-2-of-6-vmq.aspx

⎕ TCP Chimney Offload no es soportado en arreglos de Red basados en software con Server 2012, debido a que TCP Chimney tiene la pila de red vaciada completamente a la tarjeta de red. Si no se está utilizando NIC teaming por software, puedes dejar esta configuración deshabilitada.

• PARA MOSTRAR EL ESTADO:
  • De una ventana de comandos elevada, escribe lo siguiente:
    • netsh int tcp show global
      • (La respuesta deberia de indicar Chimney Offload State como disabled)
• PARA DESHABILITAR TCP Chimney Offload:
  • De una ventana de comandos elevada, escribe lo siguiente:
    • netsh int tcp set global chimney=disabled

⎕ Marcos Jumbo (Jumbo frames) deberan de ser configurados a 9000 o 9014 (dependiendo de tu hardware) para redes que soporten CSV, iSCSI y Live Migration. Esto puede incrementar significativamente la velocidad (hasta 6 veces) y utilizara menos ciclos de CPU.

• Los Jumbo frames deben de ser soportados punta-a-punta por todos los dispositivos de red – NIC, SAN, Switch.
• Puedes habilitar jumbo frames cuando utilices cables cruzados (para Live Migration y/o Heartbeat), en un clúster de 2 nodos.
• Para verificar que los jumbo frames han sido configurados exitosamente, ejecuta el siguiente comando desde todos los hosts Hyper-V hacia tu SAN iSCSI:
  • Ping 10.50.2.35 –f –l 8000
    • Este comando mandara un paquete de 8K desde el host hacia la SAN (por ej. 10.50.2.35). Si recibes respuestas, jumbo frames Han sido configuradas correctamente.

⎕ Las tarjetas de red usadas para comunicacion iSCSI deben de tener deshabilitados todos los protocolos de red (en las propiedades de la coneccion de area local) con la excepción de:

• Protocolos del fabricante (si aplica)
• Internet Protocol Version 4
• Internet Protocol Version 6.
• Deshabilita otros protocolos (no mostrados arriba) ayuda a eliminar el trafico no-iSCSI en estas tarjetas de red.

⎕ No se deben de utilizar teams de tarjetas de red iSCSI. MPIO es el mejor método. Teaming puede ser usado para administración, produccion (tráfico de las máquinas virtuales), CSV Heartbeat y redes de Live migration.

• Para obtener mayor información acerca de teaming de tarjetas de red:
  • http://technet.microsoft.com/en-us/library/hh831648.aspx
  • http://www.microsoft.com/en-us/download/details.aspx?id=30160
• Para obtener mayor información acerca de MPIO:
  • Microsoft Multipath I/O (MPIO) Users Guide for Windows Server 2012:
    • http://www.microsoft.com/en-us/download/details.aspx?id=30450
  • Managing MPIO with Windows PowerShell on Windows Server 2012:
    • http://blogs.msdn.com/b/san/archive/2012/07/20/managing-mpio-with-windows-powershell-on-windows-server-2012.aspx

⎕ Si estas utilizando teaming de tarjetas de red para administración, CSV heartbeat y/o Live migration, configura los teams antes de que empieces a asignar redes.

⎕ Si usas un equipo agregado (dependiente del switch) en una máquina virtual, solo tarjetas SR-IOV pueden ser utilizadas...

• Para obtener mayor información: http://www.microsoft.com/en-us/download/details.aspx?id=30450

⎕ Si usas teaming dentro de una máquina virtual, hazlo en este orden:

METODO #1:

• Abre la configuración de la máquina virtual
  • Dentro de adaptadores de red, selecciona características avanzadas.
  • En el panel derecho, dentro de Network teaming, selecciona la casilla “Enable this network adapter to be part of a team in the guest operating system.”
• Dentro de la maquina virtual, abre Server Manager. Clic en la vista All Servers, y habilita teaming desde el servidor.

Metodo #2:

• Utiliza el siguiente comando de powershell (como Administrador) en el host Hyper-V donde la maquina virtual reside:
  • Set-VMNetworkAdapter –VMName contoso-vm1 –AllowTeaming On
    • Este comando habilita la alta disponibilidad en caso de que una de las tarjetas de red en team falle.
    • Dentro de la maquina virtual, abre Server Manager. Clic en la vista All Servers, y habilita teaming desde el servidor.

⎕ Cuando configures switches virtuales, es recomendado quitar la opción Allow management operating system to share this network adapter, para poder crear una red dedicada para que tus máquinas virtuales se comuniquen con otras computadoras en la red física. (Si el adaptador de administración esta compartido, no modifiques ningún protocolo).

Por favor nota: soportamos completamente en incluso recomendamos (en algunos casos) usar el switch virtual para separar redes para administración, live migration, CVS/Heartbeat e incluso iSCSI. Por ejemplo dos tarjetas a 10GB separadas para VLANs y QoS.

⎕ Configuración de red recomendada para clustering:

# Mínimo de redes por host	Host Administrativo	Acceso a red para VMs	CSV/Heartbeat	Live Migration	iSCSI
5	“Management”	“Production”	“CSV/Heartbeat”	“Live Migration”	“iSCSI”

** Redes CSV/Heartbeat & Live Migration Networks pueden usar cables cruzados para conectar los nodos, pero solo si estas creando un clúster de 2 nodos. Cualquier cosa mayor a 2 nodos requiere un switch. **

⎕ Deshabilita la comunicación del clúster para la red iSCSI.

• Desde Failover Clúster Manager, en Networks, las propiedades de la red iSCSI debe de ser establecida a “Do not allow clúster network communication on this network.” Esto previene el flujo de comunicación interna del clúster así como trafico CSV dentro de la misma red.

⎕ Redes redundantes son recomendadas (múltiples switches) – especialmente para Live Migration y redes iSCSI – ya que provee redundancia y calidad de servicio (QoS).

VLANS:

⎕ Si el arreglo de tarjetas de red está habilitado para redes de administración y/o Live migration, los puertos físicos en el switch al cual es host esta conectado debería de ser configurado como trunk en modo promiscuo. El switch físico puede pasar todo el tráfico al host para ser filtrado.

⎕ Apaga los filtros de VLAN en los arreglos de tarjetas de red. Permite al software de arreglos o al switch de Hyper-V (si está presente) que hagan el filtrado.

• Para obtener mayor información , descarga el documento Windows Server 2012 NIC Teaming (LBFO) Deployment and Management: http://www.microsoft.com/en-us/download/details.aspx?id=30160

Adaptadores de Red Virtuales (NICs):

⎕ Los adaptadores de red antiguos (conocidos como controladores de NICs emuladas) deberán ser utilizadas únicamente para arrancar una VM desde PXE o cuando se instale un sistema operativo que no detecte Hyper-V. Las tarjetas de red sintéticas de Hyper-V (por default) son mucho más eficientes; debido al uso de un Bus dedicado para las VMs para comunicarse entre la tarjeta de red virtual y la física; como resultado, tendrás menos ciclos de CPU así como reducción de transiciones por operación entre el hypervisor y el huésped.

DISCO:

⎕ Discos nuevos deberían de utilizar el formato VHDX. Los discos creados en versiones anteriores deberían de ser convertidos a vhdx, a menos que exista la necesidad de mover el disco a un Hyper-V 2008.

• El formato VHDX soporta capacidades de hasta 64 TB, protección mejorada contra corrupción de datos durante fallas de electricidad (grabando actualizaciones a las estructuras de datos del VHDX), y una alineación mejorada del disco duro virtual para trabajar mejor en discos con sectores más grandes.

⎕ Los discos utilizados para CSV deberán de ser particionados con NTFS. No puedes usar un disco para CSV que sea formateado con FAT, FAT32, o Resilient File System (ReFS).

• Para obtener mayor información: http://technet.microsoft.com/en-us/library/jj612868.aspx#BKMK_storage

⎕ Los discos deberían de ser fijos en un ambiente de producción, para incrementar la tasa de transferencia del disco. Los discos diferenciales y dinámicos no son recomendados para producción, debido a que incrementan el tiempo en lectura/escritura.

• Para obtener mayor información: http://technet.microsoft.com/en-us/library/cc720381(v=WS.10).aspx

⎕ Utiliza los snapshots con cautela. Si no son administrados apropiadamente, pueden causar problemas de espacio en disco, así como sobrecarga física en transferencias I/O. Adicionalmente, si estas hospedando Controladores de domino 2008 R2 o anteriores, aplicar un snapshot anterior puede causar USN rollbacks. Windows Server 2012 ha sido actualizado para proteger más eficazmente a los DCs de esta condición; aun así su uso debería de ser limitado.

• Para obtener mayor información: http://blogs.technet.com/b/reference_point/archive/2012/12/10/usn-rollback-virtualized-dcs-and-improvements-on-windows-server-2012.aspx
• Si estas creando una política de TI, por si misma no es efectiva, puedes configurar una ruta de snapshots para cada VM a localidades no existentes, así los usuarios tendrán un error si tratan de crear uno.
• Si los snapshots son mandatorios, la localización NO debe de ser el disco del sistema operativo.

⎕ El espacio mínimo recomendado en volúmenes CSV que contienen archivos de configuración de máquinas virtuales, VHD y/o archivos VHDX:

• 15% de espacio libre, si el tamaño de la partición es menos de 1 TB.
• 10% de espacio libre, si el tamaño de la partición está dentro de 1 y 5 TB.
• 5% de espacio libre, si el tamaño de la partición es mayor a 5TB.

• Para enumerar la información actual del volumen, incluyendo el porcentaje libre, puedes utilizar el siguiente comando de Powershell:
  • Get-ClusterSharedVolume "Cluster Disk 1" | fc *
    • Revisa la salida del campo "PercentageFree"

⎕ No esta soportado crear un arreglo de almacenamiento utilizando LUNs de Fiber Channel o iSCSI.

• Para obtener mayor información:
  • http://social.technet.microsoft.com/wiki/contents/articles/11382.storage-spaces-frequently-asked-questions-faq.aspx#What_types_of_drives_can_I_use_with_Storage_Spaces
  • http://blogs.technet.com/b/yungchou/archive/2012/08/31/windows-server-2012storage-virtualization-explained.aspx

⎕ El archivo de paginación en un huésped Hyper-V debe de ser manejado por el SO y no configurado manualmente.

 

MEMORIA:

⎕ Utiliza Memoria dinámica (Dynamic Memory) en todas las VMs (a menos que no sea soportado).

• La memoria dinámica ajusta la cantidad de memoria disponible para la máquina virtual, basada en cambios a la demanda de memoria utilizando un controlador de memoria en forma de globo, el cual permite el uso más eficiente de la memoria.

• Para obtener mayor información:
  • http://technet.microsoft.com/en-us/library/hh831766.aspx
  • http://technet.microsoft.com/en-us/library/hh831410.aspx#BKMK_DM

⎕ EL SO huésped debería de ser configurado con el mínimo de memoria recomendada

• 2048MB es recomendado para Windows Server 2012 (por ej. 2048 - 4096 Dynamic Memory). (El mínimo soportado es 512 MB)
• 2048MB es recomendado para Windows Server 2008, incluyendo R2 (por ej. 2048 - 4096 Dynamic Memory). (El mínimo soportado es 512 MB)
• 1024MB es recomendado para Windows 7 (por ej. 1024 - 2048 Dynamic Memory(El mínimo soportado es 512 MB)
• 1024MB es recomendado para Windows Vista (por ej. 1024 - 2048 Dynamic Memory). (El mínimo soportado es 512 MB)
• 512MB es recomendado para Windows Server 2003 R2 c/SP2 (por ej... 256 - 2048 Dynamic Memory). (El mínimo soportado es 128 MB.
  • Vease http://technet.microsoft.com/en-us/library/hh831766.aspx)
• 512MB es recomendado para Windows Server 2003 c/SP2 (por ej... 256 - 2048 Dynamic Memory). (El mínimo soportado es 128 MB).
  • Vease http://technet.microsoft.com/en-us/library/hh831766.aspx
• 512MB es recomendado para Windows XP. Importante: XP no soporta Dynamic Memory. (El mínimo soportado es 64 MB). Nota: el soporte para Windows XP termina en abrill 2014!

CLUSTER:

⎕ Establece la red preferida para comunicacion CSV, para saegurar que la red correcta sea utilizada para este tipo de trafico. (Nota: esto solo necesita ser ejecutado en unos de tus nodos Hyper-V)

• La metrica más baja en la salida generada por el siguiente comando de Powershell debería de ser utilizado para el tráfico CSV
  • Abre una ventana de Powershell (como “Administrador”)
  • Primero, debes de importar el modulo “FailoverClusters”. Escribe lo siguiente”:
    • Import-Module FailoverClusters
  • Siguiente, solicitaremos una lista de redes utilizadas por el host, asi como la métrica asignada, escribe lo siguiente:
    • Get-ClusterNetwork | ft Name, Metric, AutoMetric, Role
  • Para poder cambiar cual interfaz de red es utilizada para el trafico CSV, utiliza el siguiente comando en Powershell:
    • (Get-ClusterNetwork "CSV Network").Metric=900
      • Esto establecera la red llamaca "CSV Network" a 900

*** Establece la red preferida para Live Migration, para asegurar que las redes para Este trafico son correctas: Set preferred network for Live Migration, to ensure the correct network(s) are used for this traffic:

• Abre Failover Cluster Manager, Expande el Cluster
• Despues, clic derecho en Networks y selecciona Live Migration Settings
  • Utiliza las flechas arriba/abajo para listar las redes en el orden del mas preferido (arriba) al menos preferido (abajo)
  • Deselecciona cualquier red que no quieras usar para trafico de Live Migration.
  • Selecciona Apply y después OK.
• Una vez que hayas hecho este cambio, sera utilizado para todas las VMs en el clúster.

⎕ El tiempo de apagado del clúster (la llave de registro ShutdownTimeoutInMinutes) debería de ser configurada a un número aceptable

• El default se establece con el siguiente calculo (el cual puede ser muy alto, dependiendo en cuanta memoria fisica sea instalada)
  • (100 / 64) * Memoria Fisica
    • Por ejemplo, un sistema de 96GB tendria un tiempo de 150 minutos (100/64)*96 = 150
• Una sugerencia es establecer el tiempo de espera a 15, 20 o 30 minutos dependiendo el número de VMs en tu ambiente.
  • Llave de registro: HKLM\Cluster\ShutdownTimeoutInMinutes
    • Agrega lso minutos en valor Decimal.
    • Nota: se necesita un reinicio para que tome efecto.

⎕ Ejecuta la validacion del clusted periódicamente para remediar cualquier incidente

• Nota: si todas las LUNs son parte del clúster, la prueba de validación se saltara todas las revisiones de disco. Es recomendable configurar una LUN pequeña de prueba y compartirla en todos los nodos, para que una validación complete pueda ser completada.
• Si necesitas probar una LUN que tenga máquinas virtuales corriendo, el LUN tiene que ser desconectado.
• Para obtener mayor información: http://technet.microsoft.com/en-us/library/cc732035(WS.10).aspx#BKMK_how_to_run

⎕ Considera habilitar el modo cache de CSV si tienes VMs que sean usadas principalmente para peticiones de lectura, y no mucha labor de escritura. Escenarios como máquinas virtuales para VDI; también pueden ser utilizadas para reducir tormentas de arranque de VMs.

• Para obtener mayor información: http://blogs.msdn.com/b/clustering/archive/2012/03/22/10286676.aspx

 

REPLICACION DE HYPER-V:

⎕ Ejecuta el Hyper-V Replica Capacity Planner. El planificador de capacidad de replicación de Hyper-V, te permite planear tu estrategia de replicación basado en la carga de trabajo, almacenamiento y características de red y de servidores. Esta herramienta te ayuda a determinar:

• Cuanto ancho de banda es necesario entre el sitio primario y la replica?
• Cuanto almacenamiento se requiere entre el sitio primario y la replica?
• Cual es el impacto de almacenamiento al habilitar puntos de recuperación?

⎕ Actualiza el tráfico de entrada en el firewall para permitir el tráfico en los puertos TCP ‘80’ y/o ‘443’. (En el firewall de Windows, habilita la regla “Hyper-V Replica HTTP Listener (TCP-In)” en cada nodo del clúster.

Para habilitar el tráfico de replicación a través del puerto 80 (HTTP), puedes ejecutar el siguiente comando desde una ventana de comandos elevada:

netsh advfirewall firewall set rule group="Hyper-V Replica HTTP" new enable=yes

Para habilitar tráfico de replicación a través del puerto 443 (HTTPS) puedes ejecutar el siguiente comando desde una ventana de comandos elevada:

netsh advfirewall firewall set rule group="Hyper-V Replica HTTPS" new enable=yes

• Para obtener mayor información: http://blogs.technet.com/b/meamcs/archive/2012/08/03/windows-server-2012-part3-virtualization-enhancements-mobility-hyper-v-replica.aspx

⎕ Es recomendado habilitar compresión para tráfico de replicación, para reducir requerimientos de ancho de banda.

• Para obtener mayor información: http://social.technet.microsoft.com/wiki/contents/articles/12794.hyper-v-compression-is-recommended-for-replication-traffic.aspx

⎕ Configura los respaldos de Sistemas Operativos huésped con VSS para habilitar que los snapshots de aplicaciones sean consistentes con la réplica de Hyper-V.

• Para obtener mayor información: http://social.technet.microsoft.com/wiki/contents/articles/12795.hyper-v-configure-guest-operating-systems-for-vss-based-backups-to-enable-application-consistent-snapshots-for-hyper-v-replica.aspx

⎕ Los servicios de integración deben de ser instalados antes que cualquier máquina virtual primaria, las réplicas pueden utilizar una IP alterna después de un failover.

• Para obtener mayor información: http://social.technet.microsoft.com/wiki/contents/articles/12796.hyper-v-integration-services-must-be-installed-before-primary-or-replica-virtual-machines-can-use-an-alternate-ip-address-after-a-failover-en-us.aspx

⎕ Los discos duros virtuales con archivos de paginación deben de ser excluidos de replicación, a menos que el archivo de paginación se encuentre en el disco de sistema operativo.

• Para obtener mayor información: http://social.technet.microsoft.com/wiki/contents/articles/12800.hyper-v-virtual-hard-disks-with-paging-files-should-be-excluded-from-replication-en-us.aspx

⎕ Como mínimo, se deben de probar que los failovers funciones correctamente cada mes, para verificar que el failover será exitoso y que las cargas de trabajo de las máquinas virtuales operaran como es esperado.

• Para obtener mayor información: http://social.technet.microsoft.com/wiki/contents/articles/13040.hyper-v-test-failovers-should-be-carried-out-at-least-monthly-to-verify-that-failover-will-succeed-and-that-virtual-machine-workloads-will-operate-as-expected-after-failover.aspx

⎕ La réplica de Hyper-V requiere que el rol “Failover Clustering Hyper-V Replica Broker” sea configurado si es que el servidor primario o la réplica son parte de un clúster.

• Para obtener mayor información: http://blogs.technet.com/b/virtualization/archive/2012/03/27/why-is-the-quot-hyper-v-replica-broker-quot-required.aspx

⎕ La optimización de desempeño y características de la réplica de Hyper-V deberían de ser ajustadas utilizando las llaves de registro mencionadas en el siguiente artículo:

• http://support.microsoft.com/kb/2767928

ACTUALIZACION “CLUSTER-AWARE”:

⎕ Pon todos los perfiles de ejecución del servicio “Cluster-Aware Updating (CAU)” en una carpeta compartida que sea accesible desde todos los CAU Update coordinators potenciales. (Perfiles de ejecución son configuraciones que pueden ser guardadas como un archivo XML llamado “Perfil de ejecución actualizable” y ser reutilizado después para ejecuciones de actualización posteriores. http://technet.microsoft.com/en-us/library/jj134224.aspx

ARCHIVOS COMPARTIDOS CON SMB 3.0

⎕ Es requerido tener una infraestructura de Active Directory, para poder otorgar permisos a la cuenta de computadora de los hosts Hyper-V.

• Para obtener mayor información: http://technet.microsoft.com/en-us/library/jj134187.aspx

⎕ Las configuraciones de Loopback (donde la computadora que está ejecutando Hyper-V es utilizada como el servidor de archivos para almacenamiento de las máquinas virtuales) no son soportadas. Similarmente, ejecutar la carpeta compartida en una máquina virtual es que esta hospedada en alguno de los nodos no es soportado.

DOMAIN CONTROLLERS VIRTUALES (DCs):

⎕ Máquinas virtuales que sean DCs deben de tener un la opción “Shut down the guest operating system" en la configuración de acción automática (en la configuración de la máquina virtual en el host de Hyper-V)

⎕ Importante: Vea “Sea cauteloso cuando utilice snapshots” en la sección de Disco para más informacion acerca de snapshots.

• Para obtener mayor información: http://technet.microsoft.com/en-us/library/hh831734.aspx

⎕ Importante: Asegúrate que el KB2855336 (liberado en Julio del 2013) haya sido instalado. Nota: esta actualización fue liberada de nuevo en Julio 12 del 2013 para arreglar un problema. Para más información acerca de este problema, ve a la sección Known issue about this update rollup.

• Los VHDs de los Controladores de dominio que contienen la base de datos de Active Directory deben de tener “write caching” deshabilitado, para reducir la probabilidad de corrupción de AD (si la base de datos esta almacenada en un disco vIDE). Esta actualización resuelve Este problema para todos los sistemas operativos soportados.
• No es necesario hacer nada a los DCs despues de aplicar la actualizacion. AD envía una petición para ver si puede deshabilitar el cache de disco y si falla, envía IOs con el bit FUA (Force Unit Access), el cual es requerido para garantizar la integridad.
• Para obtener mayor informacion: http://support.microsoft.com/kb/2853952

SERVICIOS DE INTEGRACION (INTEGRATION SERVICESJ

⎕ Asegura que los servicio de Integracion (IS) hayan sido instalados en todas las VMs. Servicios de integracion incrementan significativamente la interaccion entre la maquina virtual y el host.

⎕ Asegúrate de tener instalada la última versión de servicios de integración – la misma versión que el (los) host(s) – en todos los sistemas operativos huéspedes, puesto que algunas actualizaciones de Microsoft hacen cambios/mejoras al software de integración. (Cuando una nueva versión de los servicios de integración es actualizada en el host, no actualiza los huéspedes automáticamente).

• Nota: Si los servicios de integración están desactualizados, veras eventos 4010 en el event viewer.
• Puedes encontrar la versión para cada una de tus VMs en un host ejecutando el siguiente comando de Powershell:
  • Get-VM | ft Name, IntegrationServicesVersion
• Si quieres un metodo para actualizar los servicios de integracion en VMs, revisa este blog: http://gallery.technet.microsoft.com/scriptcenter/Automated-Install-of-Hyper-edc278ef

OFFLOADED DATA TRANSFER (ODX):

⎕ Si tu SAN soporta ODX (ver este post para mas ayuda; también checa con tu fabricante), deberías considerar habilitar ODX en tus hosts Hyper-V, así como cualquier VM que se conecte directamente a LUNs en la SAN.

• Para habilitar ODX, abre Powershell (como administrador) y escribe lo siguiente:
  • Set-ItemProperty hklm:\system\currentcontrolset\control\filesystem -Name "FilterSupportedFeaturesMode" –Value 0
  • Asegurate de ejecutar este comando en cada host de Hyper-V que conecta la SAN, así como cualquier VM que se conecte directamente a la SAN.

• Para obtener mayor informacion: http://technet.microsoft.com/en-us/library/jj200627.aspx

CONVERSION DE MAQUINAS VIRTUALES:

⎕ Si estas convirtiendo maquinas virtuales de VMWare a Hyper-V, considera usar MVMC (una herramienta gratuita de Microsoft) o VMM.

• Nota: Si utilizas la herramienta MVMC, puedes usar tambien el Migration Automation Toolkit (MAT), que es gratuiito y puede ayudar a automatizar el prceso de conversión.

---

Espero sinceramente que encuentres útil este artículo! Si es así, manda este enlace a otros que se puedan beneficiar de el!

Hasta la próxima,

Roger Osborne, Microsoft PFE

(Twitter: RogOsb; LinkedIn: http://www.linkedin.com/in/rogerosborne)

Hola, somos Doug Symalla y Greg Jaworski, el equipo de TAG trayéndoles un blog pesado, lleno de detalles.

 

En el último blog de Doug, el planteó un roadmap de actualización de Active Directory. Les prometimos algunos detalles prácticos para cada una de las fases, así que iniciemos con la primera fase - El assesment. El objetivo de este blog es darles detalles a profundidad sobre la información que deben colectar, porqué deben colectarla y como pueden colectarla. Tengan en mente que nunca tendrán todo documentado perfectamente, siempre van a existir gaps al respecto. Será necesario tomar la decisión entre los costos asociados a obtener la información y el beneficio que se obtendría al contar con la misma. Si tienen alguna sugerencia sobre qué, cómo y porqué obtener más información, por favor háganoslo saber en la sección de "Comentarios". Su retroalimentación siempre es bienvenida.

Documentar la arquitectura de AD actual, el dimensionamiento de los DCs y la localización de los mismos

Qué: Una visión concisa de la infraestructura de AD completa. Esto incluye los sitios de AD, los Site links, la colocación de los Controladores de Dominio, el dimensionamiento de los Controladores de Dominio e información sobre el baseline de performance.

Porqué: Eventualmente se debe decidir (ver la Fase de Planeación) entre simplemente reemplazar todos los controladores de dominio existentes (los viejos) con nuevos controladores de dominio, o si se rediseñaría/redimensionaría la infraestructura.

Cómo:

· Dibujando el mapa con el AD Topology Diagrammer. Los diagramas de AD Sites y AD Domains son componentes muy importantes. También hay que poner atención en el nivele funcional del Dominio y del Forest y en las relaciones de confianza hacia otros Dominios o Forests.

· Recolectando algunos datos básicos sobre la configuración de todos los DCs. Esto debería incluir la versión del sistema operativo, la cantidad de memoria RAM, los CPUs, la configuración y el tamaño de los discos. Se pueden elaborar scripts de PowerShell para recolectar esta información de todos los controladores de dominio.

· Obteniendo un baseline de performance. Esta información puede obtenerse con Perfmon, apegándose a lo básico con los contadores para:

o Uso de CPU
o Uso de Memoria
o Uso de CPU y Working Set del proceso LSASS.exe
o Average Disk sec/read y Average Disk sec/write de cada uno de los discos
o LDAP searches per sec
o LDAP bind times
o NTLM authorizations per sec
o Kerberos authorizations per sec

Hacer un inventario de las configuraciones particulares de los Controladores de Dominio

Qué: Los detalles de la configuración en los Controladores de Dominio – especialmente aquellas configuraciones particulares que no son por default.

Porqué: Es necesario decidir si estas configuraciones van a seguirse utilizando y en dado caso, cómo hacer para mantenerlas y seguir adelante con la migración.

Cómo: Investigando en el Registry, las GPOs y la base de datos de AD.

· En el Registry de los Controladores de Dominio, deben buscarse las configuraciones listadas abajo (lo cual también se puede hacer con PowerShell). Después, se puede usar "Group Policy Modeling" o "Group Policy results" para revisar qué configuraciones podrían realizarse mediante política y cuales se realizarían manualmente.

o Revisar si se utilizan puertos estáticos de RPC. Por ejemplo, se configuró un rango fijo de puertos RPC, o un puerto para FRS o puertos para la replicación de AD?

o Se deshabilitó SMB signing alguna vez en el pasado?

o Se han implementado/instalado certificados (para LDAP) en los Controladores de Dominio?

o Se ha modificado el default del LMCompatibilityLevel?

o Se ha deshabilitado eDNS cuando se implementaron los Controladores de Dominio 2003 o en algún momento posterior?

o Se han modificado los limites en las conecciones NSPI?

o Alguna vez se habilitó DES encryption y después se descubrió que dicha configuración esta deshabilitada por default en Windows 7/2008 R2?

· Revisar las siguientes configuraciones en la base de datos de AD:

o Alguna vez han modificado los valores por default de la LDAP query policy?

o Existen cuentas de usuario en el directorio que hayan sido configuradas para utilizar DES encryption?

Hacer un inventario de otras aplicaciones/servicios instalados en los DCs

Qué: Determinar otras aplicaciones/servicios instalados en los Controladores de Dominio.

Porqué: Antes de retirar un Controlador de Dominio, es necesario tomar en cuenta los otros servicios como DHCP, WINS o DNS.

Cómo: Revisando los programas instalados y los servicios que se ejecutan en los DCs (esto también puede ser realizado utilizando PowerShell). Determinar cuáles de estos deberían ser migrados ya sea hacia los nuevos DCs o a algún otro servidor. Algunos de los servicios/aplicaciones que comúnmente vemos corriendo en los controladores de dominio y que son pasados por alto son:

· DHCP
· DNS
· WINS
· Terminal Services Licensing
· DFS Namespaces (ademas de SYSVOL)
· Certificate Services
· IAS/Radius/NPS
· Agentes de Directory Sync/Password Sync
· Password Filters personalizados

Investigar y Documentar las dependencias hacia AD en el ambiente

Qué: Hacer un inventario de las dependencias hacia Active Directory Dependents.

Porqué: You need to research whether or not your dependents are compatible with the new version of Active Directory/Domain Controllers.

Cómo: Dependiendo del tamaño de su ambiente, esto puede significar una tarea muy grande. Es muy común que existan en el ambiente clientes/aplicaciones que utilizan Active Directory sin que nadie sepa de su existencia. Por eso recomendamos iniciar con las:

1. Dependencias conocidas/obvias

2. Aplicaciones críticas de negocio (y otras dependientes de estas)

Dependencias conocidas/obvias:

· Iniciar con clientes/computadoras que están integradas al dominio. Consultar el atributo Operating System de cada uno de los objetos Computer. Buscar por sistemas operativos Microsoft que estén fuera de soporte como Windows NT o Windows 2000. Para sistemas operativos no Microsoft, revisar la compatibilidad con el fabricante del sistema operativo.

· Considerar aplicaciones Microsoft comunes, como Exchange o SCCM. En algunos casos la aplicación podría estarse ejecutando en el Controlador de Dominio (por ejemplo un agente de SCCM) mientras que en otros casos la aplicación quizás dependa de AD. Iniciar aquí para revisar la compatibilidad de dichas aplicaciones.

· Revisar y documentar la compatibilidad de cualquier otra dependencia conocida. Esto podría incluir por ejemplo, otros servicios de directorio que se integran/sincronizan con AD o aplicaciones LDAP que jalan información desde AD. Asegurarse de revisar si la aplicación "descubre" los controladores de dominio, o si la aplicación está configurada haciendo referencia directa a la dirección IP o al nombre de algún controlador de dominio. Si fuera este último caso, será necesario recordar que es necesario actualizar la configuración con el Nuevo nombre/dirección IP de alguno de los Controladores de Dominio nuevos una vez que estén en línea.

Aplicaciones Críticas de Negocio y Otras Dependencias

· ¡Que comience la cacería! Es necesario rastrear las dependencias e investigar el impacto potencial de la actualización. Hay que iniciar con los sistemas críticos/importantes que sustentan al negocio. Debe determinarse si se integran a AD y la manera en que lo hacen, después de lo cual se debe revisar si son compatibles con la nueva versión de los Controladores de Dominio.

· Si se sienten muy valientes, pueden optar por habilitar el modo verbose de LDAP logging y/o el modo verbose de Netlogon logging en los DCs, hacer a un lado todo el ruido y ver si se puede encontrar alguna dependencia “interesante”. Hay que proceder con mucha precaución antes de “explorar estos caminos”. Si no se tiene cuidado, puede generarse un montón de ruido (y muchos dolores de cabeza) sin obtener ninguna información útil.

· Otra opción interesante (otra vez debemos advertirles que el grado de dificultad es alto) sería cazar específicamente a los clientes obsoletos LM/NTLMv1. Nuestros colegas de AskDS tienen un gran blog sobre este tema.

Investigar los cambios al comportamiento por default del SO/DCs y su impacto potencial

Mucha de la información que les hemos pedido recolectar en las secciones anteriores, provee algunos consejos sobre los cambios en el comportamiento por default de las nuevas versiones de los sistemas operativos Windows. La tabla que mostramos a continuación hace un resumen de estos cambios. Después hay una descripción con más detalles de estos elementos, como podrían impactarles y nuestras recomendaciones y posibles workarounds. Nota: NO estamos incluyendo comportamientos/errores inesperados que puedan presentarse cuando se actualiza. Pueden encontrar esos aquí. Dichos errores deberían ser investigados durante las fases de Planeación y Pruebas.

Elemento/Comportamiento por Default	Windows Server 2003	Windows Server 2008	Windows Server 2008 R2	Windows Server 2012
Almacenar LMHash	X
Criptografía NT 4.0	X
Cifrado DES para Kerberos	X	X
Cifrado AES 128 bit y 256 bit para Kerberos		X	X	X
Limites LDAP Query hardcoded		X	X	X
Conexiones NSPI limitadas a 50		X	X	X
SMB Signing	X	X	X	X
Servicio Computer Browser habilitado	X
LMCompatibilityLevel	2	3	3	3
DFS Site-Costed Referrals		X	X	X
NullSessionPipeslist se acorta y NullSessionShares se elimina		X	X	X
EDNS0 habilitado	X		X	X
Aplicación estricta de la sección 3 del RFC 2696 (LDAP)			X	X
Compresión sID/PAC				X
Puertos RPC dinámicos	1025-5000	49152-65535	49152-65535	49152-65535

Hemos incluido esta tabla y una breve descripción de todos los cambios en una hoja Excel. Esperamos que sea una buena herramienta táctica para ustedes. Pueden encontrar la hoja aquí.

LM Hash y LM Authentication:

A partir de Windows Server 2008, los controladores de dominio (y los miembros del dominio) ya no almacenan el LM hash de los passwords. Estos “hashes” son fácilmente hackeados para obtener los passwords. Adicionalmente ya no será posible utilizar LM authentication.

Recomendaciones:
Adoptar el nuevo comportamiento por default y dejar de almacenar el valor de LMHash para los passwords. Es mucho más seguro. También cualquier cliente o aplicación “legacy” que utilicen LM authentication necesitan ser actualizados/eliminados.

Referencias:
http://support.microsoft.com/?id=299656
http://support.microsoft.com/?id=946405

Algoritmos de Criptografía NT 4.0 y Relaciones de Confianza NT 4.0:

A partir de Windows Server 2008, el sistema operativo dejó de usar algoritmos de criptografía “legacy” para la comunicación del canal seguro (secure cannel). Por default, Windows NT 4.0 (y otras aplicaciones/sistemas operativos que usan este algoritmo) no serán capaces de establecer un canal seguro (o autenticarse) con un controlador de dominio Windows Server 2008 o superior. Hay una opción de configuración/GPO que puede revertir este comportamiento – "Allow cryptography algorithms compatible with Windows NT 4.0". No obstante, se debe tomar en cuenta que incluso con esta configuración, no es posible establecer una relación de confianza entre Windows Server 2008 R2 y Windows NT 4.0.

Recomendaciones:
Esto es relativamente simple, más aún porque nosotros (Microsoft) ya no damos soporte a Windows NT 4.0. Debido a lo anterior, la mejor recomendación es alejarse de Windows NT 4.0. No vale la pena perder tiempo y recursos intentando arrastrar a Windows NT 4.0 al mundo moderno. Si el negocio aún necesita de un NT 4.0, lo mejor es sacarlo del dominio, desconectarlo de internet y hacer todo lo que sea posible para aislarlo, de esa forma podrá “morir en paz”.

Referencias:
http://support.microsoft.com/kb/942564
http://support.microsoft.com/kb/2021766

Cifrado DES y Autenticación Kerberos:

A partir de Windows Server 2008 R2, los controladores de dominio (y los miembros del domino) ya no permiten el cifrado DES para los tickets de Kerberos. El cifrado DES fue quebrado desde el milenio pasado, así que es tiempo de pasar a mejores mecanismos de cifrado como AES.

Recomendaciones:
Recopilar información para determinar quién/qué sigue utilizando cifrado DES en el dominio. Se debe decidir entre eliminar o actualizar al implicado. Si esto último fuera necesario, es posible configurar los controladores de dominio Windows Server 2008 R2 y superiores para permitir el cifrado DES de Kerberos.

References:
http://support.microsoft.com/kb/978055

Cifrado AES y Autenticación Kerberos:

A partir de Windows Server 2008 y Windows Vista, se agregó soporte de cifrado AES para Kerberos. Aun cuando esto es algo buen, es muy probable que ustedes noten eventos en el log de sus clientes anteriores “quejándose” por tipos de cifrado no soportados. No es necesario preocuparse, ya que los clientes y los controladores de dominio van a negociar el tipo de cifrado apropiado para ambos.

Recomendaciones:
No es necesario hacer nada. Hay que tomar en cuenta que los clientes anteriores a Windows Vista no soportaran los nuevos tipos de cifrado y es probable que registren advertencias o errores en su log de eventos de seguridad.

Referencias:
http://technet.microsoft.com/en-us/library/cc749438(v=WS.10).aspx

Limites en las políticas de LDAP Query:

A partir de Windows Server 2008, se han implementado límites “hardcoded” a las politicas de LDAP. Dichos límites son significativamente más agresivos que el rango configurable en Windows Server 2003. Específicamente los valores MaxReceiveBuffer, MaxPageSize, MaxQueryDuration, MaxTempTableSize y MaxValRange han sido limitados. Si en el ambiente, se han configurado estos parámetros quedando muy alejados de los valores por default, es probable sobrepasar estos límites “hardcoded”.

Recomendaciones:
Evaluar la configuración actual para la política de LDAP query. Si está configurada por default, no hay nada de que preocuparse. Si la política ha sido modificada, asegúrese de que no exceda los nuevos límites. Si fuera el caso, trate de determinar la razón y qué se puede hacer con el cliente o la aplicación que generó esta modificación.

Referencias:
http://support.microsoft.com/default.aspx?scid=kb;en-US;2009267

Límites a las conexiones NSPI:

La “Name Server Provider Interface” (NSPI) es una interfaz que proporcionan los controladores de dominio para permitir a los clientes de mensajería acceder y manipular los datos del directorio (address book). A partir de Windows Server 2008, el número de conexiones NSPI concurrentes ha sido limitada a 50 conexiones por usuario, por DC. Este comportamiento fue implementado a fin de proteger a los DCs de un posible agotamiento de recursos en el escenario en que los clientes NSPI sigan abriendo conexiones sin cerrar las conexiones anteriores que ya no son necesarias. Algunas aplicaciones de mensajería usan una cuenta de servicio para realizar las conexiones NSPI en nombre de los usuarios. En este escenario, una sola cuenta de usuario puede abrir cientos o miles de conexiones NSPI hacia un solo DC bajo el contexto de un solo usuario. En este caso, podría ser necesario aumentar el número máximo de conexiones NSPI en los controladores de dominio Windows Server 2008 R2.

Recomendaciones:
Si ustedes tienen alguna aplicación o cliente de mensajería que requiere más de 50 conexiones NSPI simultáneas por usuario/cuenta de servicio, pueden modificar este límite por default. Estimen un valor más apropiado (algo entre el valor predeterminado de Windows Server 2008 de 50 y el valor por default de Windows Server 2003 de 4 billones) y configuren sus controladores de dominio con ese valor.

Referencias:
http://support.microsoft.com/kb/949469

SMB Signing:

El SMB signing ha andado por aquí desde hace algún tiempo. Desde Windows NT 4.0 SP3 los sistemas operativos Microsoft han sido capaces de utilizar SMB signing. Y ha sido habilitado de forma predeterminada desde Windows Server 2003. Así que si ustedes deshabilitaron esta configuración alguna vez, este es un buen momento para volver a habilitarla.

Recomendaciones:
Revisar la configuración actual para SMB signing – especialmente si ha sido deshabilitada. En dado caso, determinar el porqué y si ya se puede volver a habilitar esta configuración relacionada a la seguridad.

Referencias:
http://support.microsoft.com/kb/887429

Servicio Computer Browser:

Windows Server 2008 y los sistemas operativos posteriores tienen deshabilitado el servicio de Computer Browser por default. Esto parece relativamente inofensivo (y una buena idea); No obstante, hay que tener en cuenta que, tanto "My Network Places " como " Network Neighborhood" se basan en el servicio de Computer Browser.

Recomendaciones:
A menos que tengan una buena razón para no hacerlo, sigan adelante y deshabiliten el servicio de Computer Browser.

Referencias:
http://technet.microsoft.com/en-us/library/bb726965.aspx

LMCompatibilityLevel predeterminado:

El LMCompatibilityLevel puede ser configurado de 0 a 5. EL default de Windows Server 2003 para el LMCompatibilityLevel es 2, mientras que para Windows Server 2008 en adelante el valor por default del LMCompatibilityLevel es 3. Por lo tanto, los controladores de dominio Windows Server 2008 (y superiores) seguirán aceptando los mismos niveles de autenticación NTLM (LM, NTLM, NTLMv2) igual que los controladores de dominio Windows Server 2003. Sin embargo, cuando actúe como cliente, Windows Server 2008 (y superior) utilizará NTLMv2 (en vez de NTLMv1). Esto difiere de Windows Server 2003 cuando actúa como cliente, el cual utilizará LM o NTLM (v1 o v2). Así, el comportamiento del lado del servidor no va a cambiar, mientras que el comportamiento del lado cliente cambiará.

Recomendaciones:
Leer la referencia de abajo para entender correctamente cómo funciona la autenticación NTLM. Esto les ayudará a entender las implicaciones del movimiento en la configuración por default de 2 a la configuración por default de 3. Entonces determinen que configuración están utilizando actualmente (la predeterminada o alguna otra). Finalmente, determinen que valor les gustaría dejar (el nuevo valor por default o algún otro).

Referencias:
http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx

DFS Site-Costed Referrals:

En los controladores de dominio Windows Server 2008 y superiores se habilitan los DFS Site-Costed Referrals de forma predeterminada. Esto permite a un cliente de DFS localizar objetivos (incluyendo SYSVOL y NETLOGON) más cercanos al cliente, en base a los costos definidos en los Site-links de Active Directory. Los controladores de dominio Windows Server 2003 ordenan las referencias de forma aleatoria (y poco eficiente).

Recomendaciones:
Adoptar la nueva configuración predeterminada con Site-Costed Referrals habilitado. Si los controladores de dominio recientes va a coexistir por un periodo de tiempo considerable con los controladores de dominio Windows Server 2003, debe considerarse la posibilidad de habilitar Site-Costed Referrals en los DCs Windows Server 2003.

Referencias:
http://support.microsoft.com/kb/905846

Null Session Pipes y Null Session Shares:

La lista predeterminada de excepciones en Windows Server 2003 incluye acceso anónimo a “named pipes” para (entre otros) Systems Network Architecture (SNA), print spooler, browser, netlogon, lsarpc y el Security Account Manager (SAMR). Estas excepciones fueron permitidas para lograr compatibilidad con aplicaciones y clientes “legacy”. En Windows Server 2008 R2 la lista predeterminada para NullSessionPipes es más corta (solo 3 entradas) y la lista predeterminada de NullSessionShares está vacía. Esta configuración podría causarle problemas a los clientes/aplicaciones “legacy” que siguen utilizando acceso por null session hacia los controladores de dominio a través de name pipes y/o recursos compartidos específicos.

Recomendaciones:
Es poco probable que tengan clientes que requieran este tipo de acceso. Si fuera el caso, es poco probable que sepan cuáles son los clientes que lo requieren. Hagan pruebas siempre que sea posible. De lo contrario, sólo hay que estar conscientes del cambio. Si llegan a descubrir algún problema, es posible hacer roll back a este cambio.

Referencias:
http://technet.microsoft.com/en-us/library/dd162275.aspx
http://msdn.microsoft.com/en-us/library/aa365590(VS.85).aspx

EDNS0:

La funcionalidad “Extension Mechanisms for DNS” (EDNS0) permite el uso de paquetes UDP (User Datagram Protocol) de mayor tamaño. Sin embargo, algunos programas de firewall no permiten que los paquetes de UDP sean mayores a 512 bytes. Como resultado, estos paquetes de DNS podrían ser bloqueados por el firewall. Técnicamente EDNS0 fue habilitado desde Windows Server 2003; no obstante algunos clientes deshabilitaban su comportamiento. Es necesario investigar si sus DCs/Servidores DNS actuales tienen EDNS= habilitado o deshabilitado.

Recomendaciones:
Dejar EDNS0 habilitado. Si fuera necesario, configurar el firewall u otro dispositivo de red para permitir paquetes de UDP mayores a 512 bytes. En el peor de los casos, el comportamiento de EDNS0 puede ser deshabilitado.

Referencias:
http://support.microsoft.com/kb/828263
http://support.microsoft.com/kb/832223

Comportamiento LDAP:

Los controladores de dominio Windows Server 2008 R2 y Windows Server son más estrictos en lo que respecta al cumplimiento del RFC2696 Section 3. Específicamente cuando se realiza una consulta paginada, cada página de la consulta debe contener valores idénticos exceptuando el messageID, la cookie y opcionalmente un pageSize modificado. Si las páginas de la consulta no se forman correctamente, el controlador de dominio regresará un error UNAVAIL_EXTENSION en lugar de la página solicitada. Ni los controladores de dominio Windows Server 2003 ni los Windows Server 2008 cumplen esta regla.

Recomendaciones:
La aplicación LDAP o el query LDAP afectado debe ser actualizado o modificado para realizar consultas compatibles con el RFC2696. Si esto no fuera posible, se puede modificar el comportamiento del controlador de dominio para que actúe como lo hace Windows Server 2003.

Referencias:
http://support.microsoft.com/kb/2468316
http://support.microsoft.com/kb/977180

SID Compression:

La autenticación de Kerberos en Windows incluye “tokens” de acceso (el SID del usuario, además de los SIDs de los grupos a los cuales pertenece el usuario, además del histórico de SID…) en la porción de datos de autenticación de los tickets de Kerberos. Si un token de acceso es demasiado grande, los datos de autenticación no cabrían en el ticket de Kerberos. Para ayudar a reducir el tamaño de los datos de autenticación, los controladores de dominio Windows Server 2012 comprimen los SIDs por default. Algunos clientes de Kerberos de terceros podrían no entender los datos de autenticación con la compresión de SIDs.

Recomendaciones:
Investigar los clientes de Kerberos no-Windows para determinar si son compatibles con la compresión de SIDs. En caso contrario, este comportamiento predeterminado se puede deshabilitar en los controladores de dominio Windows Server 2012.

Referencias:
http://support.microsoft.com/kb/2774190
http://blogs.technet.com/b/askds/archive/2012/09/12/maxtokensize-and-windows-8-and-windows-server-2012.aspx

Rango de puertos dinámicos RPC:

A fin de cumplir con las recomendaciones de la “Internet Assigned Numbers Authority” (IANA), Microsoft cambió el rango de puertos dinámicos de cliente para conexiones salientes a partir de Windows Vista y Windows Server 2008. Por default, el nuevo puerto de inicio es 49152 y el puerto final es el 65535. Esto representa un cambio de la configuración en versiones anteriores de Windows que utilizaban de forma predeterminada el rango de puertos del 1025 al 5000.

Este cambio no está directamente relacionado a los servicios de Active Directory, no obstante Active Directory utiliza RPC para comunicarse, por lo tanto, se ve afectado por este cambio.

Recomendaciones:
Ser conscientes de los cambios en el comportamiento de RPC. Si los controladores de dominio se comunican (para replicar AD y FRS) a través de un firewall, asegurarse de que los firewalls están configurados para permitir este nuevo rango de puertos.

Referencias:
http://support.microsoft.com/kb/929851
http://support.microsoft.com/kb/832017

Esperamos el esfuerzo que ponemos en esto sea valioso para ustedes.

Greg “AD Upgrade Ninja” Jaworski

Doug “Out of Blogging Breath“ Symalla

 

Una entrega más de la traducción de artículos más populares de ASKPFEPLAT, les traemos este post acerca de las actualizaciones de Windows 2012 y Windows 8.Para ver el articulo original, haz clic aquí.

Hola a todos,

Si prestan atención a las actualizaciones que liberamos cada mes o toman nota de que actualizaciones de Windows están en tu PC con Windows 8 o Windows Server 2012, puede que hayan visto algunas actualizaciones empaquetadas. Más abajo esta la lista de las primeras:

(Nótese que recientemente hemos renombrado las actualizaciones Acumuladas a Actualizaciones empaquetadas lo cual consideramos que las describen mejor)

· Windows 8 and Windows Server 2012 Update Rollup: April 2013 – KB2822241

· Windows 8 and Windows Server 2012 Update Rollup: March 2013 – KB2811660

· Windows 8 and Windows Server 2012 Update Rollup: February 2013 – KB2795944

· Windows 8 and Windows Server 2012 Update Rollup: January 2013 – KB2785094

· Windows 8 and Windows Server 2012 Update Rollup: December 2012 – KB2779768

· Windows 8 and Windows Server 2012 Update Rollup: November 2012 – KB2770917

· Windows 8 Client and Windows Server 2012 General Availability Update Rollup – KB2756872

Este artículo discute el propósito de estos paquetes,  de donde vienen y la audiencia a la cual están dirigidos. Nótese que la manera en que empaquetamos las actualizaciones puede cambiar conforme nuestros productos evolucionan así que esta información es solamente relevante a Windows 8 y Windows Server 2012.

Para empezar, estas actualizaciones empaquetadas no son actualizaciones cumulativas. Es necesario aplicar cada uno de los paquetes mensuales para tener las correcciones y mejoras de cada mes. Instalar la actualización de Febrero del 2013 no te instala las de Enero 2013 o de Octubre 2012. Estas actualizaciones son independientes unas de otras. Al hacer una búsqueda por el número de articulo KB (o solamente usando los enlaces de arriba para las actualizaciones existentes) encontraras información en lo que hace cada actualización ese mes. Nótese que estas actualizaciones no se enfocan en un componente en particular como hemos visto en actualizaciones cumulativas o empaquetadas anteriormente, más bien son amplias dentro de Windows.

Existen diferentes mecanismos utilizados para decidir que cuales actualizaciones incluir dentro de estos paquetes incluyendo retroalimentación de clientes Premier, Fabricantes OEM, Fabricantes independientes de Hardware (IHV), foros, blogs y Organizaciones internas de Microsoft. Basado en esta información, se toma la decisión de incluir los parches en la siguiente entrega basado en el siguiente criterio:

o Impacto al usuario final. El impacto tiene que ser significativo. Por ejemplo, el problema resuelto puede causar un BugCheck, pérdida de datos o algún otro evento significativo.

o Aplicabilidad o número de sistemas impactados. Aquí es cuando la telemetría es importante (Habilita WER para hacer mejores productos). también dependemos en volúmenes estimados de nuestros OEMs, ISVs e IHVs.

o Seguridad en que el parche no causara regresiones. Esta confianza está basada en nuestro análisis de código y pruebas extensas.

Nótese que las actualizaciones empaquetadas no son relacionadas con seguridad y están enfocadas a mejorar el desempeño e integridad de Windows. Los problemas de seguridad aún siguen siendo evaluados y liberados de acuerdo  al sitio Microsoft Security Response Center.

La mayoría de los consumidores aplicara estas actualizaciones de modo mensual sin dares cuenta y mejoraran su experiencia. Es recomendado que las empresas sigan el mismo proceso para distribuir estas actualizaciones mensualmente, tal como lo hacen con las actualizaciones de seguridad el Segundo martes de cada mes. Para no incrementar significativamente la carga de trabajo del equipo de TI.

Si instalas las actualizaciones manualmente, descargándolas del catálogo de Microsoft Update o desde enlaces de los artículos relacionados, debes de saber que puede haber prerrequisitos que tengan que ser instaladas previamente. Esto es realizado automáticamente cuando utilizas Windows Update, WSUS, Configuration Manager, etc. Por ejemplo, si vas al Microsoft Download Center y buscas las actualizaciones empaquetadas de Marzo (KB2811660), podrás ver varios links típicos de los diferentes tipos de arquitectura. Al seleccionar alguno de ellos (nótese que Windows 8 x64 y Windows Server 2012 son lo mismo) mostraran las actualizaciones enlazadas. Utilizamos la palabra enlazadas porque si fuéramos a instalar la actualización “Padre” KB2811660 desde Windows Update, instalara todas las actualizaciones “hijas” automáticamente. Entonces, el típico usuario casero no solo tendrá el KB2811660 instalado, sino también KB2800088, KB2812829, KB2815769 y KB2823233 automáticamente. Los usuarios que no utilizan Windows Update necesitan instalar manualmente todas las actualizaciones del centro de descargas cuando estén buscando la actualización “padre”, así que para el paquete de marzo, es necesario un total de cinco actualizaciones. Los usuarios caseros que utilizan Microsoft update y como mencione,  los clientes que utilizan WSUS y System Center Configuration Manager con su proceso de aprobación no tienen que preocuparse acerca de la relación padre / hijo puesto que eso será manejado por ti.

Aquí hay un ejemplo del paquete de Marzo y como aparece en el Microsoft Download Center:

El fin de estos paquetes es que los usuarios caseros y empresariales mantengan una línea base sólida y bien probada de sus sistemas operativos. Las actualizaciones empaquetadas son una manera de acomodarnos a la manera en que los clientes utilizan el producto hoy en día. Estos paquetes le permiten a los clientes mantener sus sistemas al día y de un modo mucho más rápido que antes.

Steve “SteveMat” Mathias

Esta es una traduccion manual del articulo original publicado en el blog ASKPFEPLAT, durante las siguientes semanas estaremos publicando traducciones de los articulos mas populares del blog, como siempre se aceptan y agradecen las sugerencias y comentarios.

 

Que tal, mi nombre es Adrián Corona, Soy un PFE transaccional en Microsoft y estoy muy entusiasmado puesto que este es mi primer post en un blog, es un poco extenso así que espero que no estés limitado en tu plan de datos. 

En esta ocasión estaré aportando a las series de post del programa MCM (Microsoft Certified Master) con un tópico que no es muy popular como replicación de Directorio Activo (DA) sin embargo es utilizado a diario – Índices!

Nota: solo cubriré información respecto a Windows 2003 en adelante, imagino que ya actualizaste tu infraestructura cierto?

Nota 2: Esta información también aplica para Active Directory Light-weight Services (ADLDS) o Active Directory Application Mode (ADAM).

Imagina que recibiste una llamada del departamento de desarrollo de software diciendo que los usuarios se están quejando del tiempo de respuesta de una aplicación critica (están cansados de ver esto:   ), esta aplicación está altamente integrada con DA pero no se sabe cómo funciona exactamente, probablemente porque la aplicación “ya estaba aquí mucho antes que todos los miembros actuales de TI y nadie tiene documentación” (cualquier parecido con la realidad es mera coincidencia); entonces, tomas tu teclado, inicias sesión en tu controlador de dominio de confianza y abres Performance monitor.

Sin pensarlo dos veces, disparas una captura con el Active directory Data collector set (disponible solo en Windows 2008+)

 

Nota: Si tienes SCOM, también puedes utilizar esto: (http://technet.microsoft.com/en-us/library/dd262067.aspx)

 

Ya que tienes eso listo, le pides al usuario que abra su aplicación y haga pruebas:

Después de un rato de captura de datos, obtienes tu resultado:

Interesante, veamos de que se trata:

Mmmh! Creo que esto tiene que ver con una consulta, más abajo haces clic en Active Directory – Search para ver más información:

Después de analizar estos resultados, volteas a ver a tu programador y orgullosamente dices… Tu problema es que estas haciendo una búsqueda medial, corrígela! Y vuelves a trabajar, entonces él te recuerda que no hay documentación y no hay nada que se pueda hacer desde el código de la aplicación y te pregunta si tú puedes ayudarlo.

Tu respuesta es… Exacto! Índices!

Si el programador puede hacer cambios a tu aplicación, te recomiendo que intentes hacer la optimización del lado del cliente primero (detalles más adelante)

Indización, en términos de bases de datos, es crear una estructura de datos o una lista “pre-compilada” de resultados posibles con el fin de obtenerlos mucho más rápido cuando una consulta es ejecutada en una tabla. En esencia esto quiere decir que hará más rápidas las operaciones de búsqueda en atributos específicos.

No quiero saturarte con mucha información, hablare de clases, atributos y opciones en otra publicación. Con la idea de que te quedes con ganas de más J.

Directorio Activo, como mi colega David Gregory explico en su publicación anterior, es una base de datos. Cuando un servidor es promovido a controlador de dominio, la base de datos es creada y muchas estructuras de datos son creadas también. Algunos atributos importantes son indexados por defecto para mejorar el rendimiento de consultas (LDAP u otras).

Más abajo encontraras una tabla con algunos de los atributos indexados por defecto en la base de datos de DA, (si te interesa ver la lista complete la puedes ver en este artículo.

Name	Syntax	Description
common-Name	Unicode String	Common-Name
display-Name	Unicode String	Display-Name
given-Name	Unicode String	Given-Name
group-Type	Integer	Group-Type
lDAP-Display-Name	Unicode String	LDAP-Display-Name
location	Unicode String	Location
Mail	Unicode String	E-mail-Addresses
name	Unicode string	RDN
object-Guid	Octet string	Object-Guid
object-Sid	SID	Object-Sid
organizational-Unit-Name	Unicode string	Organizational-Unit-Name
sAM-Account-Name	Unicode string	SAM-Account-Name
service-Principal-Name	Unicode string	Service-Principal-Name
sID-History	SID	SID-History
surname	Unicode string	Surname
user-Account-Control	Integer	User-Account-Control
user-Principal-Name	Unicode string	User-Principal-Name

Algunos atributos en esta lista también son parte de la lista parcial de atributos o PAS por sus siglas en Ingles y también son configuradas para resolución de nombres ambigua o ANR por sus siglas en ingles las cuales explicare más adelante. Los atributos en la ANR y PAS son aquellos utilizados frecuentemente para identificar a los objetos más comunes como el nombre, apellido,etc.

Una de las áreas más frecuentes en DA son consultas. Las consultas son ejecutadas hacia la base de datos miles de veces por día (o por segundo en algunos casos). Las consultas son utilizadas para muchas operaciones como autenticación, requerimientos de aplicaciones específicas, políticas de grupo, libreta de direcciones de Outlook y prácticamente cualquier aplicación que utilice DA.

 

Por qué me habría de interesar?

El desempeño de tu aplicación puede ser afectado severamente cuando las respuestas a una consulta son muy lentas.

Asumiendo que mi aplicación está tratando de obtener objetos dentro de DA con un criterio especifico, por ejemplo, si la aplicación no puede encontrar el valor exacto del campo descripción, la aplicación podría intentar buscar con asteriscos ( esto se conoce como una búsqueda medial, en la cual múltiples valores antes y después de la cadena de caracteres pueden existir):

Description=*test*

Probemos esto con mi herramienta favorita: ldp.exe

Si no tienes ldp instalado necesitas agregar las herramientas administrativas (RAST) para servicios de directorio, las instrucciones para instalarlo están aquí para Windows 7 o Windows 8.

1. Inicia el asistente para agregar roles desde el administrador de servidores.
2. Abre “Remote Server Administration Tools” y selecciona las herramientas que quieras instalar en tu equipo. Si seleccionas la primera opción todas las herramientas administrativas serán instaladas

 

Nota: ldp se instala automáticamente cuando agregas los servicios de directorio y/o promueves un Nuevo controlador de dominio.

Abre ldp y haz una conexión a tu DC en el Puerto de catálogo global (3268), no olvides autenticarte.

Si quieres ver información detallada acerca de los resultados de alguna consulta, selecciona Options-> Controls, y selecciona Search Stats desde la sección Load Predefined:

Ahora, construimos una consulta especificando el filtro (description=*test*). Dejamos en blanco el campo Base DN, lo cual causara que la búsqueda se genera en la raíz del directorio:

 

Para que esto funcione hay que modificar las opciones de búsqueda con los siguientes parámetros:

Al seleccionar el tipo de llamada Extended, estoy especificando que junto a mi consulta quiero que se haga una operación extendida. Esto causa que se adjunte un identificador de objeto (OID) a la consulta. En este caso, el identificador Search Stats ya ha sido especificado como se observa arriba. Si no seleccionas Extended en las opciones de búsqueda, los controles que especifiquemos serán ignorados. Este es el resultado cuando ejecuto mi consulta:

Analicemos la información adicional que fue desplegada:

Call time: Es el tiempo que tomo en ejecutarse la consulta. Es el tiempo que el procesador tomo convertido a milisegundos, si el servidor se llegara a congelar haciendo algo más al mismo tiempo que la consulta, el resultado puede variar.

*Entries returned: El número de objetos encontrados.

*Entries visited: Entradas de la base de datos que fueron “tocadas” por la consulta. Si la proporción entre objetos visitados y encontrados es muy grande, esta es nuestra primera pista de que nuestra consulta es ineficiente. Para realizar consultas más eficientes, existen estrategias como reducir el rango de búsqueda (buscar en un contenedor en lugar del dominio entero), buscar un atributo diferente o dejar de usar asteriscos. (Revisa la optimización de cuentas más abajo).

Used filter: El filtro que utilice en mi consulta.

Used indexes: Indica los índices que fueron utilizados ( o creados) por el DC para ejecutar la consulta.

*Pages referenced: Referencia al número de páginas que el DC tuvo que utilizar para obtener resultados.

*Pages read from disk: De todas las pagina referenciadas, cuantas vinieron de disco.

*Pages Pre-read from Disk: De todas las pagina referenciadas, cuantas vinieron de cache.

*Clean pages modified: Este contador me dice cuántas paginas “limpias” (paginas no modificadas en memoria) modifico el DC para darme resultados.

*Dirty pages modified: Este contador me da el número de “paginas sucias” que fueron modificadas por el DC mientras procesaba la búsqueda, en otras palabras una página “doblemente ensuciada”

*Log record generated: Este número se refiere a las páginas que fueron modificadas después de leer desde disco y puestas en memoria.

*Log record bytes generated: Tamaño en bytes de los archivos de log creados por esta consulta.

 

*Para que estos controles funcionen correctamente en 2008, R2 y 2012, necesitas el permiso SeDebugPrivilege (Debug Programs) en la cuenta que utilices para ejecutar LDP, este permiso se configura en la política de seguridad de la Default domain controllers Policy, por default, Los miembros del grupo Administrators tienen ese privilegio.

Puedes validar que tengas los permisos con el siguiente comando: “whoami /priv”

Si no lo tienes, puedes agregarlo modificando la Default domain controllers GPO

Busca Computer Configuration \ Windows settings \ Security Settings \ Local Policies \ User Rights Assignment \ Debug Programs y agrega al grupo o usuario que desees a la lista.

 

Optimización de consultas del lado del cliente.

Manteniendo el miso filtro del lado del cliente, asumiendo que solamente me interesan los resultados de un solo dominio. Si repito la misma consulta pero apuntando al Puerto 389 (LDAP) en vez del default 3268 (Global Catalog) y especificar la partición de dominio en la sección Base DN. Mantén todas las demás configuraciones como las tenias.

 

Con este cambio los contadores call time, pages referenced y entries visited mostraron una reducción de aproximadamente 20%. Es importante mencionar que el número de páginas leídas puede variar en consultas subsecuentes por que pueden ser almacenadas temporalmente desde consultas previas.

 

Ahora que sabemos todo esto, veamos cómo podemos mejorar la eficiencia modificando nuestros parámetros de consulta. Por ejemplo, modificando el Base DN a una OU especifica donde se encuentren los objetos que nos interesan, también cambiar el Scope desde Subtree a One Level. Por último, no me devuelvas todos los atributos solo el atributo “name”:

 

Podemos ver que aplicando estos cambios básicos , el call time y pages referenced fueron reducidos dramáticamente. Al seleccionar one level reducimos el número de entradas visitadas y al especificar un atributo especifico limitamos los datos devueltos, con esto vemos una reducción del 61% en el tiempo de llamada y un 13% en las páginas referidas.

 

Optimización del lado del server (Índices)

Si la optimización del lado del cliente no es suficiente o necesitamos ejecutar una búsqueda especifica que pueda ser acelerada por un índice (por ejemplo búsquedas Mediales) podemos ejecutar optimización del lado del servidor creando índices. Existen 3 tipos de índices:

Índice de atributo (Attribute Index): el índice será creado para un atributo en específico. La estructura de datos del índice contiene todos los valores del atributo a traves de la base de datos. Por lo tanto un atributo puede tomar mucho tiempo en ser generado.

Índice en contenedor (Containerized Index (PDNT)): Indiza el valor del atributo relativo al nombre del contenedor. (una OU es un ejemplo de contenedor). Debido a que el índice es basado en el contenedor, su tamaño será más pequeño y probablemente más fácil.

Índice Ordenado (Tuple Index): este índice esta optimizado para búsquedas mediales, en los cuales los índices son creados con variaciones del valor. Nuestro filtro *test* es una búsqueda medial, debido a que buscamos la cadena “test” dentro del resultado complete. Nota: este índice es válido solamente cuando la cadena a buscar es mayor que 3 caracteres. Índices ordenados son los más grandes pero dado que contienen una gran cantidad de resultados, pueden optimizar las consultas dramáticamente.

 

ANR: Ambiguous Name resolution. Este no es un índice pero es una herramienta de búsqueda muy importante. Si agregamos un atributo a la “lista” de atributos ANR, las búsquedas que requieran ANR harán una evaluación del valor deseado contra los atributos definidos como ANR. Uno de los consumidores más grandes de ANR es Exchange, si! Todas las consultas que se hacen a la lista global (GAL) utilizan ANR. Si quieres saber que atributos están seleccionados como ANR puedes consultar la partición de Schema por todos los atributos que tengan el atributo searchflags con alguno de los siguientes valores:

(|(searchflags=4)(searchflags=5)(searchflags=6)(searchflags=7)(searchflags=12)(searchflags=13)(searchflags=14)(searchflags=15)(searchflags=20)(searchflags=21)(searchflags=22)(searchflags=23)(searchflags=28)(searchflags=29)(searchflags=30)(searchflags=31)(searchflags=36)(searchflags=37)(searchflags=38)(searchflags=39)(searchflags=44)(searchflags=45)(searchflags=46)(searchflags=47)(searchflags=52)(searchflags=53)(searchflags=54)(searchflags=55)(searchflags=60)(searchflags=61)(searchflags=62)(searchflags=63))

Así es como se ve:

Getting 17 entries:

Dn: CN=Display-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: Display-Name;

Dn: CN=E-mail-Addresses,CN=Schema,CN=Configuration,DC=temores,DC=org

name: E-mail-Addresses;

Dn: CN=Given-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: Given-Name;

Dn: CN=Legacy-Exchange-DN,CN=Schema,CN=Configuration,DC=temores,DC=org

name: Legacy-Exchange-DN;

Dn: CN=ms-DS-Additional-Sam-Account-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-DS-Additional-Sam-Account-Name;

Dn: CN=ms-DS-Phonetic-Company-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-DS-Phonetic-Company-Name;

Dn: CN=ms-DS-Phonetic-Department,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-DS-Phonetic-Department;

Dn: CN=ms-DS-Phonetic-Display-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-DS-Phonetic-Display-Name;

Dn: CN=ms-DS-Phonetic-First-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-DS-Phonetic-First-Name;

Dn: CN=ms-DS-Phonetic-Last-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-DS-Phonetic-Last-Name;

Dn: CN=ms-Exch-Mail-Nickname,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-Exch-Mail-Nickname;

Dn: CN=ms-Exch-Resource-Search-Properties,CN=Schema,CN=Configuration,DC=temores,DC=org

name: ms-Exch-Resource-Search-Properties;

Dn: CN=Physical-Delivery-Office-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: Physical-Delivery-Office-Name;

Dn: CN=Proxy-Addresses,CN=Schema,CN=Configuration,DC=temores,DC=org

name: Proxy-Addresses;

Dn: CN=RDN,CN=Schema,CN=Configuration,DC=temores,DC=org

name: RDN;

Dn: CN=SAM-Account-Name,CN=Schema,CN=Configuration,DC=temores,DC=org

name: SAM-Account-Name;

Dn: CN=Surname,CN=Schema,CN=Configuration,DC=temores,DC=org

name: Surname;

 

Hay otros tipos de índices que solo especifican “pistas” o “hints” para crear el índice:

 

Subtree Index: Este tipo de índice prepara al DC para crear una “Vista Virtual” o VLV; una VLV no es un índice, más bien es una operación LDAP que habilita al cliente para solicitar un numero especifico de resultados antes y después del valor solicitado. Al ejecutar una VLV podrás ver una que una interfaz gráfica es generada dinámicamente con un conjunto pequeño de resultados y el usuario puede “Buscar” con diferentes métodos (scrolling, PAGE UP/DOWN, etc.). Esta es una operación que consume muchos recursos de Active directory y debería de ser evitada lo mas posible. Sin embargo es posible reducir un poco la carga de trabajo creándole un índice al atributo. (Exchange 2010 requiere que VLV este habilitado para ciertas operaciones) http://technet.microsoft.com/en-us/library/dd638130.aspx)

 

 

 

Qué clase de brujería es esta?

Para habilitar o deshabilitar índices hay que modificar el atributo searchflags en la definición del atributo que se quiera habilitar (en el esquema). El tributo searchflags es representado por un “signed integer “, esto quiere decir que soporta un rango desde negativo 2,147,483,648 hasta positive 2,147,483,647 (intenta poner cualquier valor dentro de ese rango y observa que sucede); sin embargo es más sencillo si lo tratamos como un arreglo de 9 bits en el cual cada bit tiene diferente propósito cuando se enciende

 

 

Show me the Money….

De vuelta a nuestra búsqueda de ejemplo. Como podríamos utilizar índices para optimizar búsquedas realizadas hacia el atributo descripción? En más detalle, asumamos que estamos ejecutando búsquedas mediales (description=*test*) en vez de una búsqueda de cadena inicial (description=test*). En este caso necesitamos un índice que sea optimizado para ambos casos: búsquedas mediales y a nivel de atributo.

Utilizando la información que discutimos antes, y los valores en la tabla anterior, necesitamos un índice Tuple (32) y un índice de atributo (1), entonces el valor que tenemos que especificar es 33 (32 + 1)

Es necesario establecer este valor en el atributo “description” en el esquema. Puedes usar la consola te Schema Management MMC, pero solo podrás configurar índices de atributo o contenedor desde ahí.

 

 

 

Recordatorio: Es necesario tener credenciales de Schema admin y conectarte al schema master con la consola, de otro modo, probablemente te topes con este amistoso mensaje:

Mmmh… intentemos con ADSIedit entonces, conéctate a la partición de Schema. Para hacerlo expande la partición de configuración y ve hacia Partitions, ahí encuentra Enterprise Schema dale clic derecho – Nueva conexión:

Ahora que todos los requisitos se cumplieron, ejecuta ADSI Edit y conéctate a la partición de esquema, busca el objeto que desees indizar (en esta caso el atributo descripción). Edita el objeto y busca el atributo searchflags. Configura el valor 33 (decimal) o 21 en Hex. Algo que me gusta de ADSIedit es que traduce el número que hayas puesto al valor que será establecido:

Una vez aceptado, AD creara el índice, puedes confirmar que haya sido creado en el event viewer en Directory services, anota el nombre del índice y el error -1404 JET_errIndexNotFound, No Such Index el cual
es esperado.

Ahora hay que esperar por confirmación de que el índice ha sido completado con el evento 1137, dependiendo de la cantidad de datos que se tengan que indizar esto puede llevar segundos hasta horas.

Debido a que este índice es creado en DCs, este cambio tiene que ser replicado y entonces los otros controladores regeneraran el índice en su momento, entonces el tiempo total para considerar in índice totalmente complete depende en la topología de AD, mi recomendación es monitoreo de los eventos mencionados.

Veamos como nuestro Nuevo índice afecta nuestra consulta. Si yo ejecuto la consulta optimizada anteriormente veo que el nuevo índice es utilizado:

En donde dice Used Indexes notaras que un nuevo índice fue usado con 3 piezas de información:

- Nombre del índice.

- Número aproximado de registros.

- Tipo de índice:

o N es Normal;

o P es contenido;

o I es Intersección Index (cuando se usa más de 1 índice crea un índice temporal)

o T es Tuple Index.

Si observas cuidadosamente, el número de entradas visitadas se redujo al menos 90% comparado contra la ejecución previa (16449), veras que el número de entradas visitadas contra regresadas es muy similar lo que indica una consulta mucho muy eficiente, el tiempo de llamada fue reducido en un 25%.

 

 

Cuál es el truco?

 

“Con grandes índices vienen grandes responsabilidades” tu base de datos de AD crecerá proporcionalmente al número de índices y al tipo de información que contengan. Afortunadamente hay modos para saber el tamaño de los índices: usando NTDSUTIL; es necesario detener los servicios de AD (ntds) si utilizas 2008 R2, si tus DCs usan 2003 necesitas reiniciar en modo DSRM (http://technet.microsoft.com/en-us/library/cc816897(v=WS.10).aspx)

Hay que seguir los siguientes pasos:

C:\Windows\system32>ntdsutil

ntdsutil: activate instance ntds

Active instance set to "ntds".

ntdsutil: files

file maintenance: Space Usage

Esto te dará una vista de tu base de datos como la siguiente:

La columna owned muestra el número de páginas que ocupa el índice, la implementación de ESENT hecha en AD utiliza páginas de 8KB de tamaño entonces, nuestro nuevo índice consume la colosal suma de 1208 kb en disco (8kb * 151 owned pages).

 

Es importante mencionar que estos índices consumirán recursos de los controladores de dominio cuando sean invocados como el resto de la base de datos de AD. Si los datos en los atributos indizados cambia rápidamente, el desempeño de tu DC tendrá un impacto, no puedo decir exactamente cuánto porque está basado en muchas variables, sin embargo, recomiendo 2 cosas:

1. Monitorea el uso de tus índices modificando la llave de registro “9 Internal processing”

 

2. Prueba la eficiencia de tu consulta modificando la llave de registro “15 Field Engineering”

 

Ambas llaves se pueden encontrar en: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

Si quieres instrucciones de como modificar estas llaves de registro ve a: (http://support.microsoft.com/kb/314980)

Resultados

Resumiendo aquí podemos ver las mejoras en este ejercicio:

Conclusión

Los Índices están hechos pare utilizarse y hacer nuestras vidas mas fáciles, pero antes de empezar a crearlos desmedidamente, hay que tener cuidado, ya discutimos el impacto que puede tener un índice en los recursos del DC, además muchos problemas de lentitud en ad pueden ser resueltos agregando más recursos a los servidores, agregando más DCs o solo reparando una aplicación mal escrita. No trato de desanimarte, más bien trato de que pienses en el costo-beneficio que tendrás al crear nuevos índices.

Recuerda: análisis y prueba! Solo así podrás entender el impacto real que tus DCs tendrás.

Si llegaste hasta aquí, gracias…. XD

Adrián “Solo quiero una” Corona