 TechNet Magazine April 2007

TechNet Magazine April 2007

Administración de Windows : En el kernel de Windows Vista: Parte 3

En este número, concluimos nuestro exhaustivo debate sobre las novedades del kernel de Windows Vista. En esta última entrega, nos ocupamos de los cambios y las nuevas características relativas a la confiabilidad, la recuperación y la seguridad.

Mark Russinovich Administración de Windows: Recuperación de desastres: Usuarios y grupos de Active Directory

La recuperación de datos de Active Directory puede ser muy compleja, pero es esencial disponer de un plan de recuperación en vigor. Vamos a mostrar cómo Active Directory almacena, elimina, restaura y replica objetos, para que pueda estar preparado la próxima vez que se elimine accidentalmente un usuario o la pertenencia a un grupo.

Gil Kirkpatrick Administración de Windows: Razones por las que Windows XP Embedded le resulta importante

Aunque es posible que usted no lo sepa, Windows XP Embedded podría ser una opción idónea para la integración TI de su empresa. Obtenga más información sobre cómo Windows XP Embedded puede reducir las tareas administrativas adicionales, ahorrarle dinero y mejorar la seguridad.

Don Jones Administración: Planee de antemano con System Center Capacity Planner

Un hardware insuficiente lleva a tiempos de respuesta largos, pero un hardware excesivo desperdicia recursos del presupuesto y la administración. Aprenda cómo puede usar System Center Capacity Planner para modelar su red y calcular exactamente sus necesidades de infraestructura.

John Savill Administración: Inventarios de clientes avanzados con SMS

Listo para usar, Microsoft Systems Management Server 2003 recoge mucha información, pero no recoge tanta como usted puede necesitar. Averigüe cómo la combinación correcta de secuencias de comandos, WMI y el conocimiento de SMS le pueden ayudar a expandir los inventarios de SMS para recopilar y elaborar informes de casi cualquier información.

Wes Dobry Administración: Implementación de actualizaciones de software personalizadas con SMS 2003 R2

Systems Management Server 2003 R2 permite usar características de actualización administradas para implementar actualizaciones personalizadas. Explore dos herramientas nuevas, la herramienta de inventario para actualizaciones personalizadas y la herramienta de publicación de actualizaciones personalizadas, y compruebe cómo pueden ayudarle a implementar sus propias actualizaciones, además de las actualizaciones de otros desarrolladores.

Steve Rachui Del editor: Puede que nos equivoquemos…

Joshua Trupin Toolbox: Nuevos productos para profesionales de TI

Greg Steen SQL Q&A: Reconstrucción de índices, longitud de colas de discos y otros aspectos

Edited by Nancy Michell Utility Spotlight: Ejecuciones automáticas

El gran número de aplicaciones que se ejecutan automáticamente en el inicio del sistema puede ser una fuente inagotable de dolores de cabeza. Pero con las ejecuciones automáticas, puede investigar cada aplicación que se ejecute automáticamente, lo que le permite solucionar problemas, rastrear programas de código malintencionado y liberar recursos del sistema.

Lance Whitney The Cable Guy: Configuración de la Directiva de grupo inalámbrica para Windows Vista

Descubra cómo puede usted usar la directiva de grupo para configurar y distribuir centralmente la configuración de red inalámbrica a todos los equipos de su red de Active Directory.

Joseph Davies Windows PowerShell: Aplicación de filtros y formato a los datos

Windows PowerShell ofrece un acceso sencillo a una gran variedad de datos. No obstante, cuando estos datos están sin procesar, no están listos para usarse para fines de negocio típicos. Aprenda a personalizar los datos recopilados mediante la aplicación de filtros y formato y la especificación de propiedades.

Don Jones ¡Hola, chicos del scripting!: Dominio inocente de los usuarios y grupos locales

Parece que todo el mundo lo ha estado preguntando. Y ahora, finalmente los chicos del scripting le muestran cómo usar scripts para administrar usuarios y grupos locales.

The Microsoft Scripting Guys Vigilancia de seguridad: Asistente para configuración de seguridad

El Asistente para configuración de seguridad constituye una forma eficaz para proteger miles de servidores distribuidos en un gran número de ubicaciones geográficas. Aquí encontrará todo lo que necesita saber para empezar a reforzar sus servidores y reducir su superficie de ataque basándose en las funciones que realizan.

John Morello Archivos del escritorio: Cuando mi sistema es x64

Eche un vistazo a una implementación de Windows XP y Windows Server 2003 en sistemas x64, y revise algunas de las ventajas de la implementación y algunos de los obstáculos con los que puede tropezar. Igualmente, podrá familiarizarse con la compatibilidad, migración e implementación de Windows Vista x64.

Wes Miller Dentro de Microsoft.com: Uso de los Servicios de federación de Active Directory (ADFS)

Microsoft proporciona una extranet para sus socios, que necesita que cada usuario externo tenga una cuenta de dominio única. Sepa cómo pretende Microsoft usar los Servicios de federación de Active Directory para mejorar la experiencia del usuario a la vez que se agiliza la administración asociada.

Jim Guthrie Notas de campo: Las alegrías y las penas de aprende

Cuándo la alegría de ser uno de los primeros usuarios comienza a desparecer, recuerde que el conocimiento hace que la tecnología sea más fácil de usar y se pueda ofrecer mejor soporte técnico. Como profesionales de TI, debemos experimentar constantemente con los productos nuevos. Puede que le sorprenda mucho lo que va a descubrir.

Mark D. Scott Confidencial de Windows: El poder de los errores

¿A quién le interesa activar un error? Hay aplicaciones que, de hecho, dependen de un error del sistema operativo. Si se corrige el error, la aplicación deja de funcionar.

Raymond Chen


 Administraci&#243;n de Windows : En el kernel de Windows Vista: Parte 3
Administración de Windows Mark Russinovich

En el kernel de Windows Vista: Parte 3
Resumen:
  • Confiabilidad
  • Recuperación
  • Seguridad

En esta serie hemos tratado hasta ahora las mejoras del kernel de Windows Vista relacionadas con los procesos, E/S, administración de la memoria, inicio del sistema, apagado y administración de la energía. En esta tercera y última
entrega, me centro en las características y mejoras de las áreas de confiabilidad, recuperación y seguridad.
Una característica de la que no me ocupo en esta serie es el control de cuenta de usuario (UAC), que comprende varias tecnologías distintas, como la virtualización del sistema de archivos y el Registro para aplicaciones heredadas, el consentimiento de elevación para tener acceso a los derechos administrativos, y el mecanismo del nivel de integridad de Windows® para aislar los procesos que se ejecutan con derechos administrativos desde procesos con menos privilegios ejecutados en la misma cuenta. Busque una explicación exhaustiva de los elementos internos del UAC en un futuro número de TechNet Magazine.
Windows Vista™ aumenta la confiabilidad del sistema y su capacidad de diagnosticar problemas del sistema y las aplicaciones mediante varias características y mejoras nuevas. Por ejemplo, el registro de eventos de seguimiento de kernel para Windows (ETW) está siempre activo y genera eventos de seguimiento para actividades de archivo, de Registro, de interrupción y de otros tipos en un búfer circular. Cuándo surge un problema, la nueva Infraestructura de diagnóstico de Windows (WDI) puede capturar una instantánea del búfer y analizarlo de forma local o cargarlo en el servicio de soporte técnico de Microsoft para solucionar dicho problema.
El nuevo Monitor de rendimiento y confiabilidad de Windows ayuda a los usuarios a relacionar los errores, por ejemplo, los bloqueos e interrupciones, con los cambios realizados en la configuración del sistema. La eficaz Herramienta de reparación del sistema (SRT) reemplaza a la consola de recuperación para la recuperación sin conexión de los sistemas que no se pueden iniciar.
Hay tres áreas que dependen de los cambios del sistema en el nivel del kernel y que merecen un estudio más detallado en este artículo: Administrador de transacciones de kernel (KTM), un tratamiento mejorado de los bloqueos y versiones anteriores.

Administrador de transacciones de kernel
Uno de los aspectos más tediosos del desarrollo de software es el control de las condiciones de error. Esto sucede sobre todo si en el curso de una operación de alto nivel, una aplicación ha completado una o más subtareas que generan cambios en el sistema de archivos o el Registro. Por ejemplo, un servicio de actualización de software de una aplicación podría realizar varias actualizaciones del Registro, reemplazar uno de los archivos ejecutables de la aplicación y, más adelante, recibir una denegación de acceso al tratar de actualizar un segundo ejecutable. Si el servicio no desea dejar la aplicación en un estado de inestabilidad, debe realizar el seguimiento de todos los cambios que realiza y estar dispuesto a deshacerlos. Probar el código de recuperación de errores es difícil y, en consecuencia, a menudo se omite, pues los errores del código de recuperación pueden hacer que no valga la pena.
Las aplicaciones escritas para Windows Vista pueden, con muy poco esfuerzo, obtener capacidades de recuperación automática de errores mediante la nueva compatibilidad transaccional en NTFS y el Registro con el Administrador de transacciones de kernel. Si una aplicación desea hacer varios cambios relacionados, puede crear una transacción del Coordinador de transacciones distribuidas (DTC) y un identificador de transacción de KTM, o bien crear un identificador de KTM directamente y asociar las modificaciones de los archivos y claves del Registro a la transacción. Si todos los cambios se realizan correctamente, la aplicación confirma la transacción y se aplican los cambios, pero en cualquier momento hasta ese punto la aplicación puede revertir la transacción y entonces se descartan los cambios.
Otra ventaja es que las demás aplicaciones no ven los cambios realizados en una transacción hasta que ésta se confirma, y las aplicaciones que usan el DTC de Windows Vista y el próximo Windows Server®, denominado por el momento "Longhorn", pueden coordinar sus transacciones con SQL Server™, Microsoft® Message Queue Server (MSMQ) y otras bases de datos. Por lo tanto, un servicio de actualización de aplicaciones que utilice transacciones de KTM no dejará nunca una aplicación en un estado de inestabilidad. Ésa es la razón por la que tanto Windows Update como la característica Restaurar sistema usan transacciones.
KTM, como esencia de la compatibilidad transaccional, permite que los administradores de recursos de transacciones como NTFS y el Registro coordinen sus actualizaciones para un conjunto concreto de cambios realizados por una aplicación. En Windows Vista, NTFS usa una extensión para proporcionar compatibilidad con transacciones denominadas TxF. El Registro usa una extensión parecida denominada TxR. Estos administradores de recursos del modo de kernel funcionan conjuntamente con el KTM para coordinar el estado de la transacción, de la misma forma que los administradores de recursos del modo de usuario usan DTC para coordinar el estado de la transacción a través de varios administradores de recursos del modo de usuario. Las aplicaciones de otros fabricantes también pueden usar KTM para implementar sus propios administradores de recursos.
TxF y TxR definen un conjunto nuevo de API del sistema de archivos y del Registro que se parecen a las existentes, salvo que incluyen un parámetro de transacción. Si una aplicación desea crear un archivo en una transacción, primero usa KTM para crear la transacción y, a continuación, pasa el identificador de transacción resultante a la API de creación del nuevo archivo.
TxF y TxR dependen de la funcionalidad de registro del sistema de archivos de alta velocidad del Sistema de archivos de registro comunes o CLFS (%SystemRoot%\System32\Clfs.sys) introducido en Windows Server 2003 R2. TxR y TxF usan CLFS para almacenar permanentemente los cambios de estado transaccionales antes de que confirmen una transacción. De este modo pueden ofrecer recuperación transaccional y garantías incluso si se produce una interrupción del suministro eléctrico. Además del registro de CLFS, TxR crea un conjunto de archivos de registro relacionados para realizar el seguimiento de los cambios de las transacciones del archivo del Registro del sistema en %Systemroot%\System32\Config\Txr, como se muestra en la Figura 1, además de conjuntos independientes de archivos de registro para cada subárbol del Registro de usuarios. TxF almacena los datos transaccionales de cada volumen en un directorio oculto en el volumen denominado \$Extend\$RmMetadata.
Figura 1 Archivos de registro TxR del subárbol del Registro del sistema
Figura 1 Archivos de registro TxR del subárbol del Registro del sistema

Compatibilidad mejorada con los bloqueos
Si Windows encuentra un error irrecuperable del modo de kernel (debido a un error de controlador de dispositivo, a un hardware defectuoso o al sistema operativo), trata de evitar que se dañen los datos del disco mediante la detención del sistema después de mostrar la característica pantalla azul de error y (si se ha configurado así) mediante la escritura del contenido de la memoria física, o de parte de ella, en un archivo de volcado. Los archivos de volcado son útiles porque al reiniciar el equipo después de un bloqueo, el servicio Online Crash Analysis de (OCA) Microsoft puede analizarlos para buscar la causa raíz. Si lo desea, también los puede analizar usted mismo con las herramientas de depuración de Microsoft para Windows.
En versiones anteriores de Windows, sin embargo, la compatibilidad con archivos de volcado no se habilitaba hasta que el proceso Administrador de sesión (%Systemroot%\System32\Smss.exe) empezaba a paginar los archivos. Esto significaba que los errores graves que se producían antes de ese momento generaban una pantalla azul, pero ningún archivo de volcado. Puesto que la mayor parte de la inicialización de los controladores de dispositivo tiene lugar antes de que se inicie Smss.exe, los bloqueos tempranos nunca ocasionan archivos de volcado y el diagnóstico de las causas resulta muy difícil.
En Windows Vista se reduce el periodo de tiempo en que no se genera archivo de volcado, mediante la inicialización de la compatibilidad con archivos de volcado una vez que se han inicializado todos los controladores de dispositivo de inicio, pero antes de cargar los controladores de inicio del sistema. Como consecuencia de este cambio, si experimenta un bloqueo durante la primera parte del proceso de inicio, el sistema puede capturar un archivo de volcado, lo que le permite usar OCA para resolver el problema. Además, Windows Vista guarda los datos en un archivo de volcado en bloques de 64 KB, mientras que las versiones anteriores de Windows los escribían en bloques de 4 KB. Este cambio hace que los archivos de volcado de gran tamaño se escriban con una velocidad 10 veces mayor.
El manejo de los bloqueos de aplicaciones también se ha mejorado en Windows Vista. En versiones anteriores de Windows, cuando una aplicación se bloqueaba, se ejecutaba un controlador de excepción no controlado. El controlador iniciaba el proceso Informe de errores de aplicaciones (AER) de Microsoft (%Systemroot%\System32\Dwwin.exe) para mostrar un cuadro de diálogo que indicaba que el programa se había bloqueado y preguntaba si se deseaba enviar un informe del error a Microsoft. Sin embargo, si la pila del subproceso principal del proceso se dañaba durante el bloqueo, el controlador de excepción no controlado se bloqueaba al ejecutarse, lo que hacía que el kernel finalizara el proceso, desaparecieran las ventanas del programa, y no se mostrara el cuadro de diálogo de informe de errores.
Windows Vista saca el manejo de errores fuera del contexto del proceso bloqueo y lo lleva a un servicio nuevo, Informe de errores de Windows (WER). Este servicio se implementa mediante un archivo DLL (%Systemroot%\System32\Wersvc.dll) en un proceso de hospedaje de servicios. Cuándo se bloquea una aplicación, se sigue ejecutando un controlador de excepción no controlado, pero el controlador envía un mensaje al servicio WER, que inicia el proceso Informe de errores WER (%Systemroot%\System32\Werfault.exe) para mostrar el cuadro de diálogo de informe de errores. Si se daña la pila y se bloquea el controlador de excepción no controlado, el controlador se vuelve a ejecutar y se vuelve a bloquear, hasta que se consume toda la pila del subproceso (área de trabajo de la memoria), momento en que interviene el kernel, que envía el mensaje de notificación del bloqueo al servicio.
Puede ver la diferencia entre estos dos enfoques en las Figuras 2 y 3, que muestran la relación del proceso de Accvio.exe, un programa de prueba que se bloquea, y los procesos de informes de errores resaltados en verde, en Windows XP y Windows Vista. La nueva arquitectura de control de errores de Windows Vista significa que los programas ya no se cierran silenciosamente, sin ofrecer la oportunidad de que Microsoft obtenga un informe del error y los desarrolladores de software puedan mejorar las aplicaciones.
Figura 2a Control de errores de aplicaciones en Windows XP
Figura 2a Control de errores de aplicaciones en Windows XP
Figura 2b
Figura 3a Control de errores de aplicaciones en Windows Vista
Figura 3a Control de errores de aplicaciones en Windows Vista
Figura 3b

Instantáneas de volumen
Windows XP introdujo una tecnología denominada Instantáneas de volumen para crear instantáneas de un momento dado de los volúmenes de disco. Las aplicaciones de copia de seguridad pueden usar estas instantáneas para crear imágenes de copia de seguridad coherentes, pero aparte de eso, las instantáneas quedan ocultas a la vista y se conservan sólo durante el proceso de copia de seguridad.
Las instantáneas no son en realidad copias completas de los volúmenes. Son más bien vistas de un volumen de un momento anterior que comprenden los datos reales del volumen que tienen superpuestas copias de los sectores del volumen que han cambiado desde que se tomó la instantánea. El controlador del Proveedor de instantáneas de volumen (%Systemroot\%System32\Drivers\Volsnap.sys) supervisa las operaciones dirigidas a los volúmenes y crea copias de seguridad de los sectores antes de permitir que cambien; almacena los datos originales en un archivo asociado a la instantánea en el directorio de Información de volumen del sistema del volumen.
Windows Server 2003 mostraba la administración de instantáneas a los administradores del servidor y a los usuarios de los sistemas cliente con las Instantáneas para carpetas compartidas. Esta característica habilitaba instantáneas persistentes a las que los usuarios podían tener acceso a través de la ficha Versiones anteriores de los cuadros de diálogo Propiedades del Explorador para sus carpetas y archivos ubicados en los recursos compartidos de archivos del servidor.
La característica Versiones anteriores de Windows Vista proporciona esta compatibilidad a todos los sistemas cliente, creando automáticamente instantáneas de volumen, por lo general una vez al día, a las que se puede tener acceso desde los cuadros de diálogo de propiedades del Explorador, con la misma interfaz usada en Instantáneas para carpetas compartidas. Esto permite ver, restaurar o copiar versiones anteriores de los archivos y directorios que se pueden haber modificado o eliminado accidentalmente. Si bien no se trata de una tecnología nueva, la implementación de Versiones anteriores de Windows Vista de Instantáneas de volumen optimiza la de Windows Server 2003 para el uso en entornos de escritorio de cliente.
Windows Vista aprovecha también la ventaja de las instantáneas de volumen para unificar los mecanismos de protección de datos del usuario y del sistema y evitar que se guarden datos redundantes de copia de seguridad. Si un cambio de la instalación o la configuración de una aplicación causa comportamientos incorrectos o no deseados, puede usar Restaurar sistema, una característica de los sistemas operativos Windows NT® introducida en Windows XP para restaurar archivos del sistema y datos a su estado en el momento que se creó un punto de restauración.
En Windows XP, Restaurar sistema usa un controlador de filtro del sistema de archivos (un tipo de controlador que puede ver los cambios en el nivel de archivo) para hacer copias de seguridad de archivos del sistema en el momento en que cambian. En Windows Vista, Restaurar sistema usa instantáneas de volumen. Si se usa la interfaz de usuario de Restaurar sistema en Windows Vista para volver a un punto de restauración, en realidad se están copiando en el volumen en funcionamiento versiones anteriores de archivos del sistema modificados de la instantánea asociada al punto de restauración.

BitLocker
Windows Vista es la versión más segura de Windows que existe. Además de contar con el motor anti spyware Windows Defender, Windows Vista introduce numerosas características de seguridad y defensa, como el cifrado de volumen completo de BitLocker™, la firma digital de código para el código del modo de kernel, los procesos protegidos, la selección aleatoria de carga de espacios de direcciones y las mejoras a la seguridad del servicio de Windows y el Control de cuentas de usuario.
Un sistema operativo sólo puede aplicar sus directivas de seguridad cuando está activo, de modo que es preciso tomar medidas adicionales para proteger los datos cuando la seguridad física de un sistema pueda estar en peligro y sea posible tener acceso a los datos desde fuera del sistema operativo. Los mecanismos basados en hardware, como las contraseñas de BIOS y el cifrado, son dos tecnologías usadas comúnmente para impedir el acceso no autorizado, sobre todo en equipos portátiles, que pueden perderse o ser sustraídos más fácilmente.
Windows 2000 introdujo el Sistema de cifrado de archivos (EFS) y, en su versión de Windows Vista, EFS incluye varias mejoras respecto a las implementaciones anteriores: mejoras de rendimiento, compatibilidad con el cifrado del archivo de paginación y almacenamiento de claves de EFS de usuario en tarjetas inteligentes. Sin embargo, EFS no se puede usar para proteger el acceso a áreas sensibles del sistema, como los archivos del subárbol del Registro. Por ejemplo, si la directiva de grupo le permite iniciar sesión en su equipo portátil aún cuando no esté conectado a un dominio, los verificadores de sus credenciales de dominio se copian en la memoria caché del Registro, de modo que un atacante podría usar herramientas para obtener el hash de su contraseña de cuenta de dominio y usarlo para tratar de obtener su contraseña mediante un buscador de contraseñas. La contraseña proporcionaría acceso a su cuenta y a los archivos EFS (asumiendo que no haya almacenado la clave de EFS en una tarjeta inteligente).
Para que resulte fácil cifrar el todo el volumen de inicio (el volumen con el directorio de Windows), con todos sus archivos del sistema y de datos, Windows Vista introduce una característica de cifrado de todo el volumen denominada Cifrado de unidad BitLocker de Windows. A diferencia de EFS, implementado por el controlador de sistema de archivos NTFS y que funciona en el nivel del archivo, BitLocker cifra en el nivel del volumen mediante el controlador de cifrado de volumen completo (FVE) (%Systemroot%\System32\Drivers\Fvevol.sys) como muestra el diagrama de la Figura 4.
Figura 4 Controlador de filtro de FVE de BitLocker
Figura 4 Controlador de filtro de FVE de BitLocker
FVE es un controlador de filtro, de forma que ve automáticamente todas las solicitudes de E/S que NTFS envía al volumen, cifrando los bloques mientras se escriben y descifrándolos mientras se leen. Para ello, usa la Clave de cifrado de volumen completo (FVEK) asignada al volumen cuando se configura inicialmente para el uso de BitLocker. De forma predeterminada, los volúmenes se cifran mediante una clave AES de 128 bits y una clave de difusor de 128. Dado que el cifrado y el descifrado tienen lugar por debajo de NTFS en el sistema de E/S, el volumen se muestra a NTFS como si no estuviera cifrado, y no es necesario que NTFS esté informado de que BitLocker está habilitado. Si trata de leer datos del volumen desde el exterior de Windows, parece que los datos son aleatorios.
FVEK se cifra con una clave maestra de volumen (VMK) y se almacena en una región especial de metadatos del volumen. Al configurar BitLocker, existen varias opciones para proteger VMK, en función de las capacidades del hardware del sistema. Si el sistema cuenta con un Módulo de plataforma segura (TPM) que satisface la versión 1.2 de la especificación de TPM y tiene asociada compatibilidad con el BIOS, puede cifrar VMK con TPM, puede hacer que el sistema cifre VMK con una clave almacenada en TPM y otra almacenada en un dispositivo de memoria flash USB, o bien puede cifrar la clave con una clave almacenada en TPM y un PIN que se escribe cuando se inicia el sistema. Para sistemas que no cuentan con TPM, BitLocker ofrece la opción de cifrar VMK con una clave almacenada en un dispositivo externo de memoria flash USB. En cualquier caso, necesitará un volumen sin cifrar del sistema NTFS de 1.5 GB, en el que se guardan el Administrador de inicio y la Base de datos de configuración de inicio (BCD).
La ventaja de usar un TPM es que BitLocker usa las características de TPM para asegurarse de que no descifrará VMK y desbloqueará el volumen de inicio si el BIOS o los archivos de inicio del sistema han cambiado desde que se habilitó BitLocker. La primera vez que se cifra el volumen del sistema, y cada vez que se realicen actualizaciones de cualquiera de los componentes mencionados, BitLocker calcula los valores hash SHA-1 de los componentes y almacena cada hash, denominado medida, en distintos Registros de configuración de la plataforma (PCR) del TPM, con la ayuda del controlador de dispositivo de TPM (%Systemroot%\System32\Drivers\Tpm.sys). A continuación, usa TPM para sellar el VMK, operación que usa una clave privada almacenada en TPM para cifrar el VMK y los valores almacenados en PCR junto con otros datos que BitLocker pasa TPM. Después, BitLocker almacena el VMK sellado y FVEK cifrado en la región del metadatos del volumen.
Cuándo se inicia el sistema, mide sus propios valores hash y el código de carga de PCR y escribe el hash en el primer PCR del TPM. A continuación, mide el hash del BIOS y almacena esa medida en el PCR apropiado. El BIOS, a su vez, mide el hash del siguiente componente de la secuencia de inicio, el Registro de inicio maestro (MBR) del volumen de inicio, y este proceso continúa hasta que se mide el cargador del sistema operativo. Cada parte de código subsiguiente que se ejecuta es responsable de medir el código que carga y de almacenar la medida en el registro apropiado del TPM. Por último, cuando el usuario selecciona el sistema operativo que va a iniciar, el Administrador de inicio (Bootmgr) lee el VMK cifrado del volumen y pide a TPM que lo abra. Sólo si todas las medidas son iguales que cuando se selló el VMK, incluso el PIN opcional, el TPM descifrará correctamente el VMK.
Este esquema es como una cadena de comprobación, donde cada componente de la secuencia de inicio describe el componente siguiente al TPM. El TPM sólo revelará su secreto si todas las descripciones que recibe coinciden con las originales. Por lo tanto, BitLocker protege los datos cifrados aún cuando se extraiga el disco y se ponga en otro sistema, el sistema se inicie con otro sistema operativo, o los archivos sin cifrar del volumen de inicio estén en peligro.

Comprobación de la integridad del código
El código malintencionado implementado como controlador de dispositivo del modo de kernel se ejecuta en el mismo nivel de privilegio que el kernel y, por lo tanto, es muy difícil de identificar y quitar. Dicho código puede modificar el comportamiento del kernel y de otros controladores y puede resultar virtualmente invisible. La integridad del código de Windows Vista para la característica de código del modo de kernel, también denominada firma del código del modo Kernel (KMCS), sólo admite la carga de controladores de dispositivo si han sido publicados y firmados digitalmente por desarrolladores sometidos a examen por parte de una entidad de certificación (CA). De manera predeterminada, KMCS se aplica en Windows Vista para los sistemas de 64 bits.
Las entidades de certificación cobran honorarios por sus servicios y realizan comprobaciones básicas sobre los antecedentes, como por ejemplo, la identidad de una empresa; es más difícil producir código malintencionado anónimo del modo de kernel que se pueda ejecutar en Windows Vista de 64 bits. Además, el código malintencionado que consigue colarse por el proceso de comprobación podría dejar indicios que lleven al autor si dicho código se detecta en un sistema en peligro. KMCS tiene usos secundarios: ofrece información de contacto del equipo de análisis de bloqueos en línea de Windows si se sospecha que un controlador contiene un error que bloquea los sistemas de los clientes y desbloquea contenido multimedia de alta definición, lo que describiré en breve.
KMCS usa tecnologías de criptografía de clave pública que se han usado en Windows más de diez años y requiere que el código del modo de kernel contenga una firma digital generada por una entidad de certificación de confianza. Si un publicador envía un controlador al Laboratorio de calidad del hardware de Microsoft Windows (WHQL) y el controlador pasa las pruebas de confiabilidad, Microsoft actúa como la entidad de certificación que firma el código. La mayoría de los publicadores obtendrán las firmas a través del WHQL, pero cuando un controlador no tenga un programa de pruebas del WHQL, el publicador no desee someterse a las pruebas del WHQL, o el controlador sea un controlador de inicio que se carga al principio del inicio del sistema, los publicadores deberán firmar el código ellos mismos. Para hacerlo, primero deben obtener un certificado de firma de código de una de las entidades de certificación que Microsoft haya identificado como de confianza para la firma de código del modo de kernel. A continuación, el autor crea digitalmente el hash del código, firma el hash cifrándolo con una clave privada y adjunta el certificado y el hash cifrado al código.
Cuándo un controlador trata de cargarse, Windows descifra el hash adjunto al código mediante la clave pública almacenada en el certificado y comprueba que el hash coincide con el incluido en el código. La autenticidad del certificado se comprueba de la misma forma, pero se usa la clave pública de la entidad de certificación, que está incluida en Windows.
Windows comprueba también las cadenas del certificado asociado hasta llegar a una de las entidades emisoras raíz incrustadas en el cargador de inicio de Windows y el kernel del sistema operativo. En un sistema de producción no debe haber nunca intentos de cargar un controlador de 64 bits sin firmar, pues a diferencia del Administrador Plug and Play, que muestra un cuadro de diálogo de advertencia si se le indica que cargue un controlador sin una firma digital que confirme que ha pasado las pruebas del WQHL, Windows Vista de 64 bits escribe en modo silencioso un evento en el registro de eventos de aplicación Integridad del código, como el que se muestra en la Figura 5, siempre que bloquea la carga de un controlador sin firmar. Windows Vista de 32 bits comprueba también las firmas digitales de controlador, pero permite que se carguen controladores sin firmar. Su bloqueo interrumpiría los sistemas mejorados de Windows XP que requieren los controladores cargados en Windows XP; además, proporciona compatibilidad con hardware para el que sólo hay controladores de Windows XP. Con todo, Windows Vista de 32 bits también escribe eventos en el registro de eventos de la Integridad del código cuando carga un controlador sin firmar.
Figura 5 Eventos de intento de carga de controlador sin firmar
Figura 5 Eventos de intento de carga de controlador sin firmar
Puesto que la firma de código se usa normalmente para etiquetar código como publicación oficial que ha superado pruebas rigurosas, por lo general los publicadores no desean firmar el código de prueba. Por ello, Windows Vista dispone de un modo de firma de prueba que se puede habilitar y deshabilitar con la herramienta Bcdedit (descrita en mi artículo de TechNet de marzo de 2007), en el que cargará controladores del modo de kernel firmados digitalmente con un certificado de prueba generado por una entidad de certificación interna. Este modo se ha diseñado para que lo utilicen los programadores mientras desarrollan el código. Cuándo Windows se encuentra en este modo, muestra en el escritorio marcadores como el que se muestra en la Figura 6.
Figura 6 Modo de firma de prueba de Windows Vista
Figura 6 Modo de firma de prueba de Windows Vista

Procesos protegidos
La nueva generación de contenido multimedia, como HD-DVD, BluRay y otros formatos con licencias del Advanced Access Content System (AACS, Sistema de contenido de acceso avanzado), será más habitual en los próximos años. Windows Vista dispone de varias tecnologías, conocidas colectivamente como Ruta de acceso a medios protegida (PMP), que el estándar del AACS exige para que se pueda reproducir este tipo de contenido. PMP incluye el Audio de modo de usuario protegido (PUMA) y Ruta de acceso de vídeo protegida (PVP) que ofrecen mecanismos para los controladores de audio y vídeo, así como aplicaciones de reproductor de medios, para impedir que el software o hardware no autorizados capturen contenido con formato de alta definición.
El PUMA y la PVP definen interfaces y compatibilidad específicas del audio y vídeo, los controladores de dispositivos, y el hardware, pero la PMP depende también de un mecanismo general del kernel introducido en Windows Vista, denominado proceso protegido. Los procesos protegidos se basan en el proceso estándar de Windows que encapsula una imagen ejecutable en ejecución, sus archivos DLL, el contexto de seguridad (cuenta bajo la que se ejecuta el proceso y sus privilegios de seguridad) y los subprocesos que ejecutan código en el proceso, pero impiden ciertos tipos de acceso.
Los procesos estándar implementan un modelo de control de acceso que concede acceso completo al propietario del proceso y a las cuentas administrativas con el privilegio de depuración de programas. El acceso completo permite al usuario ver y modificar el espacio de direcciones del proceso, incluso el código y los datos asignados al proceso. Además, los usuarios también pueden insertar subprocesos en el proceso. Estos tipos de acceso no satisfacen los requisitos de la PMP, porque permitirían al código no autorizado obtener acceso a contenido de alta definición y a claves de la Administración de derechos digitales (DRM) almacenadas en un proceso que reproduce el contenido.
Los procesos protegidos restringen el acceso a un conjunto limitado de interfaces de información y de administración de procesos que incluyen la consulta del nombre de la imagen del proceso y la terminación o suspensión del proceso. El kernel hace que la información de diagnóstico de los procesos protegidos esté disponible a través de funciones generales de consulta del proceso que devuelven datos relativos a todos los procesos de un sistema y, por ello, no requieren acceso directo al proceso. Los accesos que supongan un riesgo para los medios sólo son admitidos por otros procesos protegidos.
Además, para evitar riesgos internos, todo el código ejecutable cargado en un proceso protegido, incluso su imagen y archivos DLL ejecutables, debe estar firmado por Microsoft (WHQL) con un marcador de entorno protegido (PE), o si es un códec de audio, firmado por el desarrollador con un certificado de firma DRM obtenido de Microsoft. Dado que el código del modo de kernel puede obtener acceso completo a todos los procesos, incluidos los protegidos, y Windows de 32 bits admite la carga de código sin firmar del modo de kernel, el kernel ofrece una API para que los procesos protegidos consulten la "limpieza" del entorno del modo de kernel y usen el resultado para desbloquear el contenido principal únicamente si no se carga código sin firmar.
Identificar un proceso protegido
No hay ningunos API que identifiquen específicamente los procesos protegidos, pero se pueden identificar indirectamente en función de la información limitada disponible sobre ellos y la incapacidad de depurarlos incluso desde una cuenta administrativa. El proceso Aislamiento de gráficos de dispositivo de audio (%Systemroot%\System32\Audiodg.exe) se usa para reproducir DVD con codificación de sistema de codificación de contenido (CSS) y se puede identificar como un proceso protegido en el panel de Administrador de tareas por el hecho de que el Administrador de tareas no puede obtener el estado de su línea de comandos, virtualización y prevención de ejecución de datos aunque se ejecute con derechos administrativos.
Administrador de tareas mostrando el proceso protegido
Administrador de tareas mostrando el proceso protegido

Selección aleatoria de carga de espacios de direcciones
A pesar de medidas como la prevención de ejecución de datos y la comprobación mejorada de errores del compilador, los autores de código malintencionado siguen descubriendo vulnerabilidades de desbordamiento de búfer que les permiten infectar procesos abiertos a la red como Internet Explorer®, servicios de Windows y aplicaciones de otros fabricantes para introducirse en un sistema. Sin embargo, una vez han logrado infectar un proceso, deben usar API de Windows para lograr su objetivo, leer los datos de usuario o establecer una presencia permanente mediante la modificación de la configuración del usuario o el sistema.
De la conexión a una aplicación con puntos de entrada de API exportados por archivos DLL se ocupa normalmente el cargador del sistema operativo, pero estos tipos de infección de código malintencionado no pueden usar los servicios del cargador. Ello no suponía un problema para el código malintencionado en versiones anteriores de Windows, porque en las distintas versiones de Windows, las imágenes de ejecutables del sistema y los archivos DLL se cargan siempre en la misma ubicación, lo que hace que el código malintencionado asuma que las API residen en direcciones fijas.
La característica Selección aleatoria de carga de espacios de direcciones de Windows Vista (ASLR) impide que el código malintencionado pueda descubrir dónde están las API: para ello, carga los archivos DLL y ejecutables del sistema en una ubicación distinta cada vez que se inicia el sistema. En una fase temprana del proceso de inicio, el Administrador de memoria escoge una referencia aleatoria de carga de la imagen de DLL de una de las 256 direcciones alineadas de 64 KB en la región de 16 MB de la parte superior del espacio de direcciones del modo de usuario. Como los archivos DLL que tienen el nuevo marcador de reubicación dinámica en el encabezado de su imagen se cargan en un proceso, el Administrador de memoria los pone en la memoria, empezando en la dirección de referencia de carga de la imagen y avanzando hacia abajo.
Los archivos ejecutables que tienen el marcador reciben un tratamiento parecido y se cargan en un punto aleatorio alineado de 64 KB dentro de 16 MB de la dirección de carga base almacenada en el encabezado de su imagen. Si un archivo DLL o ejecutable concreto se vuelve a cargar una vez que lo han descargado todos los procesos que lo usan, el Administrador de memoria selecciona otra ubicación aleatoria para cargarlo. En la Figura 7 se muestra un ejemplo de diseño de espacio de direcciones para un sistema de Windows Vista de 32 bits, con las áreas en que ASLR selecciona la referencia de carga de la imagen y la dirección de carga de los archivos ejecutables.
Figura 7 Efecto de ASLR en las direcciones de carga de los archivos ejecutables y DLL
Figura 7 Efecto de ASLR en las direcciones de carga de los archivos ejecutables y DLL
Sólo se reubican las imágenes que tienen el marcador de reubicación dinámica, que incluye todos los archivos DLL y ejecutables de Windows Vista, porque si se movieran las imágenes heredadas se podrían destruir suposiciones internas de desarrolladores acerca de donde se cargan sus imágenes. Visual Studio® 2005 SP1 agrega compatibilidad con el establecimiento del marcador de forma que desarrolladores de terceros puedan sacar partido de las ventajas de ASLR.
La carga aleatoria de las direcciones de los archivos DLL en una de 256 ubicaciones no imposibilita que el código malintencionado descubra la ubicación correcta de una API, pero ralentiza en gran medida la velocidad de propagación de un gusano de red e impide que el código malintencionado que sólo tiene una oportunidad para infectar el sistema funcione correctamente. Además, la estrategia de reubicación de ASLR tiene como ventaja secundaria que los paquetes de espacios de direcciones son más compactos que en versiones anteriores de Windows, lo que crea regiones más grandes de memoria libre para asignaciones de memoria contiguas, reduce el número de tablas de página que el Administrador de memoria asigna para realizar el seguimiento del diseño de espacios de direcciones y minimiza los errores del búfer de traducción de direcciones (TLB).

Mejoras de la seguridad de servicios
Los servicios de Windows son el blanco perfecto del código malintencionado. Muchos proporcionan acceso de red a su funcionalidad, lo que podría exponer a un sistema al acceso de forma remota. La mayor parte de ellos se ejecuta con más privilegios que las cuentas de usuario estándar, ofreciendo la oportunidad de elevar los privilegios en un sistema local si se ven sometidos a riesgos por parte de código malintencionado. Por ello, Windows empezó a evolucionar con los cambios realizados en Windows XP SP2, que reducían los privilegios y el acceso asignado a los servicios únicamente a los necesarios para sus funciones. Por ejemplo, Windows XP SP2 introdujo las cuentas de servicio local y de servicio de red, que sólo contienen un subconjunto de los privilegios disponibles para la cuenta donde siempre se ejecutaban previamente los servicios, el sistema local. Así se minimiza el acceso que puede obtener un atacante al aprovechar un servicio.
ASLR en acción
Los efectos de ASLR se pueden ver muy fácilmente, comparando las direcciones de carga de DLL de un proceso en dos sesiones de inicio distintas mediante una herramienta como Explorador de procesos de Sysinternals. En estas dos capturas de pantalla, tomadas en dos sesiones distintas, Ntdll.dll se cargó en el Explorador, primero en la dirección 0x77A30000 y después en la dirección 0x77750000.
Direcciones base distintas para ntdll.dll
Direcciones base distintas para ntdll.dll
Direcciones base distintas para ntdll.dll
Direcciones base distintas para ntdll.dll

En mi artículo anterior, describía cómo los servicios se ejecutan aislados de las cuentas de usuario en su propia sesión, pero Windows Vista amplía su uso del principio de privilegios mínimos mediante una reducción aún mayor de los privilegios y el acceso a los archivos, las claves del Registro y los puertos del firewall que asigna a casi todos los servicios. Windows Vista define una nueva cuenta de grupo, denominada Identificador de seguridad del servicio (SID), exclusiva de cada servicio. El servicio puede establecer permisos en sus recursos, de forma que sólo tenga acceso su SID de servicio, impidiendo que los servicios que se ejecutan en la misma cuenta de usuario puedan tener acceso si un servicio se ve en peligro. El SID de un servicio se puede ver usando el comando sc showsid seguido del nombre del servicio, como se muestra en la Figura 8.
Figura 8 Consultar un SID de servicio
Figura 8 Consultar un SID de servicio
Los SID de servicio protegen el acceso a recursos propiedad de un servicio concreto, pero de manera predeterminada los servicios continúan teniendo acceso a todos los objetos a los que puede tener acceso la cuenta de usuario en la que se ejecutan. Por ejemplo, un servicio que se ejecute en la cuenta de servicio local podría no tener acceso a los recursos creados por otro servicio que se ejecute como servicio local en otro proceso que haya protegido sus objetos con permisos que hagan referencia a un SID de servicio, pero sí puede leer y escribir objetos para los que tenga permiso el servicio local (y a los grupos a los que pertenezca el servicio local, como el grupo de servicios).
Windows Vista introduce así un nuevo tipo de servicio restringido denominado servicio restringido de escritura, que concede un acceso de escritura de servicio sólo a los objetos accesibles para su SID de servicio, al grupo Todos y al SID asignado a la sesión de inicio. Para ello usa SID restringidos, un tipo de SID introducido en Windows 2000. Cuando el proceso que abre un objeto es un servicio restringido de escritura, el algoritmo de comprobación de acceso cambia para que un SID que no se haya asignado a un proceso, de forma tanto restringida como sin restricciones, no se pueda usar para conceder al proceso acceso de escritura a un objeto. Puede consultar si un servicio es restringido con el comando siguiente:
sc qsidtype [service]
Hay otro cambio que hace fácil que un servicio impida que otros servicios que se ejecutan en la misma cuenta tengan acceso a los objetos que crea. En versiones anteriores de Windows, el autor de un objeto es también el propietario del objeto y los propietarios tienen la capacidad de leer y cambiar los permisos de sus objetos, concediendo acceso completo a sus propios objetos. Windows Vista introduce el nuevo SID de derechos de propietario, el cual, si existe en los permisos de un objeto, puede limitar los accesos que un propietario tiene a su propio objeto, incluso eliminando el derecho de establecer y consultar los permisos.
Otra mejora del modelo de seguridad de servicios de Windows Vista permite que el desarrollador de un servicio especifique exactamente qué privilegios de seguridad necesita el servicio para funcionar cuando el servicio se registra en un sistema. Por ejemplo, si el servicio necesita generar eventos de auditoría, podría contener el privilegio de auditoría.
Cuándo el Administrador de control de servicio inicia un proceso que hospeda uno o varios servicios de Windows, crea un token de seguridad (objeto del kernel que enumera la cuenta de usuario de un proceso, las pertenencias a grupos y los privilegios de seguridad) para el proceso que sólo contiene los privilegios necesarios para los servicios del proceso. Si un servicio especifica un privilegio que no está disponible para la cuenta en que se ejecuta, el servicio no se puede iniciar. Si ninguno de los servicios que se ejecutan en un proceso de cuenta de servicio local necesita el privilegio de depuración de programas, por ejemplo, el Administrador de control de servicio elimina dicho privilegio del token de seguridad del proceso. Así, si el proceso del servicio se ve en peligro, el código malintencionado no puede usar los privilegios no solicitados explícitamente por los servicios que se ejecutan en el proceso. El comando sc qprivs indica qué privilegios ha solicitado un servicio.

Conclusión
Así concluye mi análisis en tres partes de los cambios del kernel de Windows Vista. Hay características y mejoras que no he tratado ni mencionado, por ejemplo, un nuevo grupo de subprocesos de trabajo para desarrolladores de aplicaciones, los nuevos mecanismos de sincronización, como los bloqueos de lector/escritor compartidos, el etiquetado de subprocesos de servicios, la compatibilidad con la comprobación y el cambio de tamaño de discos de NTFS, y un nuevo mecanismo IPC del kernel denominado Llamada avanzada a procedimiento local (ALPC). Puede buscar más información sobre estas y otras características en la próxima edición de Windows Internals, que se publicará a finales de 2007.
Ver el servicio de escritura restringida
Sólo un proceso de hospedaje de servicios de Windows Vista aloja servicios restringidos; se puede identificar con una herramienta de consulta de procesos como Process Explorer, como el que tiene la línea de comandos:
svchost -k LocalServiceNoNetwork
Los servicios configurados para ejecutarse en este proceso son Motor de filtro de base, Servicio de directivas de diagnóstico, Firewall de Windows, Registros y alertas de rendimiento, e Inicio de servicios de Windows Media® Center.
En esta pantalla se muestra la forma de texto del SID del servicio Motor de filtro de base, NT SERVICE\BFE, mencionado una vez con el marcador de restringido y otra vez sin él, de modo que el proceso tiene acceso a los recursos accesibles para esa cuenta. Con todo, no tiene necesariamente acceso a otros objetos normalmente accesibles para la cuenta del servicio local. Por ejemplo, como la cuenta de NT AUTHORITY\SERVICE no aparece en el token del proceso con el marcador de restringido, el proceso no puede modificar objetos que conceden acceso de escritura únicamente a esa cuenta y no a otras del token que tienen el marcador de restringido.
Los servicios que se ejecutan en este proceso limitan también sus privilegios, porque los privilegios enumerados en la parte inferior del cuadro de diálogo de propiedades son un subconjunto de los disponibles para la cuenta del servicio local.
Marcadores SID en un servicio
Marcadores SID en un servicio

Mark Russinovich es técnico de Microsoft en la división de plataformas y servicios. Es coautor de Microsoft Windows Internals (Microsoft press, 2004) y ponente habitual en conferencias de TI y desarrolladores, incluidos Microsoft Tech•Ed y el PDC. Entró a formar parte de Microsoft con la reciente adquisición de la empresa que cofundó él mismo, Winternals Software. También creó Sysinternals, donde publicó muchas utilidades muy conocidas, como Process Explorer, Filemon y Regmon.
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 Administraci&#243;n de Windows: Recuperaci&#243;n de desastres: Usuarios y grupos de Active Directory
Administración de Windows Gil Kirkpatrick

Recuperación de desastres: Usuarios y grupos de Active Directory
Resumen:
  • Mecánica de replicación y vinculación de objetos
  • Usar NTDSUTIL para realizar copias de seguridad y restaurar
  • Restauraciones autoritativas y no autoritativas

Active Directory es uno de los servicios más importantes de una red de Windows. Para evitar tiempo de inactividad y pérdida de productividad, es esencial disponer de planes eficaces de recuperación de desastres para los problemas relativos a Active Directory. Todo esto puede sonar obvio, pero es
sorprendente cuántos administradores no elaboran planes para una de las situaciones de error más habituales de Active Directory®: la eliminación accidental de datos.
La eliminación accidental de objetos es una de las causas raíz más frecuentes de los errores del servicio. En mis seminarios y conferencias, pregunto a menudo quién ha experimentado errores de Active Directory causados por la eliminación accidental de datos. Invariablemente, casi todos los asistentes levantan la mano.
Para entender por qué la recuperación de datos es tan compleja, primero hay que entender lo siguiente: cómo almacena y replica objetos Active Directory, cómo los elimina, y cómo funcionan los mecanismos de las restauraciones autoritativas y no autoritativas.

Almacenamiento de objetos
Active Directory es una base de datos de objetos especializada que implementa el modelo de datos X.500/LDAP. El almacén de datos (denominado Árbol de información de directorios o DIT) se basa en el Motor de almacenamiento extensible (ESE), un motor de bases de datos de método de acceso secuencial indizado (ISAM). Conceptualmente, Active Directory almacena el DIT en dos tablas: la tabla de datos (que contiene los objetos y atributos de Active Directory propiamente dichos), y la tabla del vínculos (que contiene las relaciones entre los objetos).
Cada objeto de Active Directory se almacena en una fila independiente de la tabla de datos, con una columna por atributo. La tabla de datos contiene todas las entradas de todas las réplicas almacenadas en el controlador de dominio (DC). En un controlador de dominio normal, la tabla de datos contiene las entradas del contexto de nombres del dominio, el contexto de nombres de la configuración y contexto de nombres del esquema. En un catálogo global, la tabla de datos contiene entradas para cada objeto del bosque.
Active Directory usa la etiqueta del nombre distintivo (DNT), un entero de 32 bits, para identificar de forma exclusiva cada fila de la tabla de datos. El DNT, usado para hacer referencia a los objetos internamente, es mucho más pequeño que otros identificadores, como el nombre distintivo (DN) y el GUID de objeto (una estructura binaria de 16 bytes). Pero a diferencia del GUID de objeto, el DNT es un identificador de configuración regional y es distinto en cada controlador de dominio.

Vinculación de objetos en Active Directory
Active Directory administra dos tipos de relaciones entre los objetos del DIT: la relación principal-secundario (denominada también relación de contenedor) y la relación de referencia (denominada también relación de vínculo). Para implementar la relación principal-secundario, Active Directory almacena una columna adicional en la tabla de datos denominada etiqueta de nombre distintivo principal, o PDNT. Esta columna contiene siempre el DNT del objeto principal de un objeto.
Cada atributo de Active Directory se define mediante un objeto attributeSchema en el contenedor de esquema de Active Directory. Ciertos atributos de Active Directory se definen como atributos de vínculo, determinados por un valor par y distinto de cero en el atributo linkID del objeto attributeSchema. Los atributos de vínculo establecen una relación entre los objetos del directorio y pueden tener un solo valor o varios valores. El atributo de miembro de un objeto de grupo es un ejemplo de atributo de vínculo de varios valores: establece un vínculo entre el objeto de grupo y los objetos de miembro.
Aunque parezca que el atributo de miembro de un grupo contiene los nombres completos de los miembros (como lo muestra el complemento Usuarios y equipos de Active Directory, por ejemplo), no es así como los almacena Active Directory. Cuando se agrega el nombre completo de un objeto de miembro al atributo del miembro del grupo, Active Directory almacena el objeto DNT, no su nombre completo. Puesto que el DNT no cambia, aún cuando se cambie el nombre de un objeto, se puede cambiar el nombre de un objeto de usuario y Active Directory no tendrá que clasificar todos los grupos del sistema para actualizar el nombre completo de cada uno de los atributos de miembro. Así es como Active Directory mantiene la integridad referenciar dentro del DIT. En la Figura 1 se muestra una representación, muy simplificada, de cómo se relacionan entre sí la tabla datos y la tabla de vínculos. En estas tablas se muestra que los tres objetos de usuario (Molly Clark, Alexander Tumanov y Makoto Yamagishi) son miembros del grupo de técnicos sénior.
Figure 1 Cómo se relacionan las tablas de datos y de vínculos (Close Figure 1)

Tabla de datos |  |  |
DNT | PDNT | Clase de objeto | Cn
14529 | 14401 | Unidad organizativa | Ingenieros
14530 | 14529 | Grupo | Ingenieros senior
14531 | 14529 | Usuario | Molly Clark
14532 | 14529 | Usuario | Alexander Tumanov
14533 | 14529 | Usuario | Makoto Yamagishi
Tabla de vínculos |  |  |
Atributo | DNT | Vínculo hacia adelante |
Miembro | 14530 | 14531 |
Miembro | 14530 | 14532 |
Miembro | 14530 | 14533 |
Estos vínculos se denominan vínculos hacia adelante. De igual forma, Active Directory proporciona también atributos de vínculo hacia atrás. Estos últimos proporcionan una referencia desde el objeto vinculado hacia atrás, hasta el objeto que hace referencia a él, es decir, el objeto con el vínculo hacia adelante. El atributo memberOf para usuarios y grupos es un ejemplo de atributo de vínculo hacia atrás. El objeto attributeSchema que describe un atributo de vínculo hacia atrás tiene un valor linkID mayor en una unidad que el valor linkID de número par del atributo de vínculo hacia adelante correspondiente. Por ejemplo, el atributo de miembro del esquema de Windows Server® 2003 R2 tiene un valor de linkID de 2; el atributo memberOf que actúa como vínculo hacia atrás tiene un valor de linkID de 3. En la Figura 2 se ofrece una lista de los atributos vinculados definidos de forma predeterminada en la esquema de Windows Server 2003 R2.
Figure 2 Atributos de vínculo en el esquema de Windows Server 2003 R2 (Close Figure 2)

Atributo de vínculo hacia adelante | linkID | Atributo de vínculo hacia atrás | Vinculado
miembro | 2 | memberOf | 3
administrador | 42 | directReports | 43
propietario | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
Los atributos de vínculo hacia atrás son siempre de varios valores y Active Directory los mantiene automáticamente. De hecho, los atributos de vínculo hacia atrás no se pueden modificar directamente. Aunque parezca que se puede modificar el atributo memberOf de un usuario o grupo mediante el complemento MMC Usuarios y equipos de Active Directory, en realidad el complemento modifica el atributo de miembro del grupo correspondiente, y Active Directory actualiza el atributo memberOf en segundo plano. Por eso no se necesitan permisos en el objeto de usuario para agregar el usuario a un grupo: sólo se modifica el atributo de miembro del objeto de grupo. Puesto que cada controlador de dominio administra sus atributos de vínculo hacia atrás de forma local, los cambios realizados en estos no se replican nunca. Sólo se replica el cambio del atributo de vínculo hacia adelante, por ejemplo, el atributo de miembro de un grupo.
En un controlador de dominio normal, la tabla de datos contiene entradas para objetos de dominio y objetos de los contenedores de configuración y de esquema. Hay tipos de grupos que pueden contener referencias a objetos que residen en otro dominio. ¿Cómo almacena Active Directory un DNT para un objeto que no está en su tabla de datos? La respuesta está en el propietario de la función de FSMO (Flexible Single Master Operations) de maestro de infraestructura y en algo conocido como objeto fantasma.

Objetos fantasma
Cuando se agrega un miembro de un dominio a un grupo de otro dominio, Active Directory crea automáticamente un objeto especial en la tabla de datos denominado fantasma, que contiene el objectGUID, el objectSid y el DN del nuevo miembro. Esto proporciona un DNT que se puede almacenar en el atributo de miembro del grupo. Si un controlador de dominio es un catálogo global, no necesitará crear un fantasma porque ya tiene una entrada en la tabla de datos para cada objeto del bosque.
El controlador de dominio que tiene la función de FSMO de la infraestructura compara periódicamente las entradas de su tabla de datos con un catálogo global y si descubre que se ha movido un objeto, se le ha cambiado el nombre o se ha eliminado, actualiza los fantasmas de la tabla de datos y replica el cambio en los demás controladores de dominio del dominio. Además, en virtud de un recuento de las referencias, el maestro de la infraestructura puede quitar también los fantasmas a los que no hace referencia ningún atributo de vínculo hacia adelante del dominio.
Los fantasmas permiten que los controladores de dominio administren las referencias a objetos de otros dominios del bosque, pero los atributos de vínculo hacia adelante, también pueden hacer referencia a objetos que están fuera del bosque, por ejemplo, en un dominio de confianza. En este caso, Active Directory crea un objeto denominado entidad principal de seguridad externa (FSP) en el contenedor CN=ForeignSecurityPrincipals del NC del dominio. La FSP contiene el Identificador de seguridad (SID) del objeto externo y otros atributos que identifican el objeto en el dominio externo, pero no hay ningún proceso que garantice que la FSP se mantenga al día. En lo que se refiere a la recuperación de datos, tratamos las FSP como a cualquier otro objeto de Active Directory.

Eliminar objetos
Ahora primero me centraré en la restauración de usuarios y su pertenencia a grupos. Sin embargo, estos mismos principios se pueden aplicar a la recuperación de otros atributos vinculados.
Cuando Active Directory elimina un objeto, no lo elimina físicamente del DIT. En lugar de ello, marca el objeto como eliminado estableciendo su atributo isDeleted en verdadero, con lo que el objeto no está visible para las operaciones normales de directorio. Active Directory quita todos los atributos no destinados a ser guardados, tal como define el esquema, y cambia el nombre distintivo relativo (RDN) del objeto al <RDN>0aDEL<:objectGUID>anterior. A continuación, mueve el objeto al contenedor CN=Deleted Objects del NC. (Hay clases de objetos del contexto de nombres de la configuración que Active Directory no mueve al contenedor de objetos eliminados). Active Directory quita los vínculos hacia adelante hacia otros objetos que tenga el objeto eliminado, lo que reduce su número de referencias en la tabla de vínculos. Si hay otros objetos que contienen vínculos hacia adelante hacia el objeto que se ha quitado, Active Directory elimina también esos vínculos.
El objeto resultante se denomina objeto de desecho. Active Directory replica este objeto de desecho en otros controladores de dominio, en los que se realizan los mismos cambios. Tenga en cuenta que Active Directory no replica los cambios realizados en los vínculos hacia adelante que hacen referencia al objeto eliminado. Cada controlador de dominio realiza el cambio equivalente de forma local, de modo que no hay necesidad de replicarlo. Esto afecta a la recuperación de las pertenencias a grupos, como se describe más adelante en el artículo.
Active Directory conserva los objetos desechados en el DIT, tal como determina el atributo tombstoneLifetime del objeto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain>. El proceso de recolección de elementos no usados en cada controlador de dominio quita los objetos de desecho anteriores a la vigencia configurada del objeto de desecho. De forma predeterminada, la vigencia del objeto de desecho es de 60 días en Windows® 2000, Windows Server 2003, y Windows 2003 R2. Es de 180 días para Windows Server 2003 SP1.
La vigencia del objeto de desecho afecta de manera significativa al proceso de restauración. No se pueden realizar restauraciones desde una copia de seguridad que sea anterior a la vigencia del objeto de desecho. Puesto que los objetos que se han eliminado y se han recopilado como basura en el dominio ya no tienen objetos de desecho, la operación de eliminación no se replicará nunca en el controlador de dominio restaurado. Los objetos eliminados permanecerán en el controlador de dominio restaurado como objetos persistentes y el controlador de dominio restaurado no convergerá adecuadamente con los demás controladores de dominio del dominio.

Replicar objetos
Siempre que un controlador de dominio realice una operación de actualización de cualquier tipo (por ejemplo, agregando un objeto o modificando un atributo) el controlador de dominio asignará un número de 64 bits exclusivo a la operación de actualización, denominado número de secuencias de actualización (USN). Active Directory etiqueta los objetos y atributos actualizados con el USN, para que sea más fácil determinar si se tienen que replicar.
Active Directory replica los objetos atributo por atributo. Es decir, si se modifica un atributo de un objeto, Active Directory replicará sólo ese atributo, no el objeto entero. Para ello, Active Directory realiza el seguimiento de los cambios que realiza en cada atributo con metadatos de réplica. Los metadatos de réplica de un atributo son:
  • El USN local, que identifica la operación de cambio en el controlador de dominio local
    • .
  • El invocationID del controlador de dominio que originó el cambio (específicamente, el atributo invocationID del objeto nTDSSettings correspondiente al controlador de dominio), que identifica una generación concreta del DIT en un controlador de dominio.
  • El USN de la operación original tal como existe en el controlador de dominio de origen.
  • Una marca de tiempo con la hora del sistema del controlador de dominio en que se realizó el cambio de origen.
  • Un número de versión secuencial de 32 bits que se incrementa cada vez que se cambia el valor.
Si un controlador de dominio de destino solicita cambios del controlador de dominio de origen, envía el USN del último cambio replicado correctamente al controlador de dominio de origen junto con un vector de actualización que incluye el mayor USN de origen recibido por el controlador de dominio de destino de cada controlador de dominio que tiene una réplica del NC que se está replicando. El controlador de dominio de origen usa esta información para enviar sólo las actualizaciones que el controlador de dominio de destino todavía no ha recibido.
Al procesar las actualizaciones entrantes de los atributos, el controlador de dominio de destino comprueba el número de versión de cada atributo. Si el número de versión de un atributo entrante es mayor que la versión que el controlador de dominio ya tiene para ese atributo, el controlador de dominio almacena el valor entrante. Si el número de versión entrante es igual a la versión que el controlador de dominio ya tiene, el controlador de dominio compara las marcas de tiempo y usa el atributo con la más reciente. Si las marcas de tiempo son iguales, el controlador de dominio de destino elige el valor con el invocationID más alto. Así se garantiza que finalmente todos los controladores de dominio tendrán el mismo valor para cada atributo replicado.

Replicación de valor vinculado
En Windows 2000, Active Directory replicaba los atributos de varios valores de la misma forma que los atributos de un solo valor. Ello ocasionaba problemas con objetos de grupo dinámicos y grandes, cuyo atributo de miembro de varios valores podía cambiar a menudo en distintos controladores de dominio. Si un administrador agregaba un usuario a un grupo en un controlador de dominio y otro agregaba al grupo un usuario distinto en otro controlador de dominio dentro de la ventana de latencia de replicación, Active Directory elegía la última adición y perdía por completo la primera. Microsoft solucionó este problema en Windows Server 2003 con un proceso denominado Replicación de valor vinculado (LVR).
Con el nivel funcional del bosque de Windows Server 2003 o el nivel funcional del bosque provisional, Active Directory replica cada uno de los valores de los atributos de vínculo hacia adelante de varios valores por separado y cada valor tiene sus propios metadatos de replicación. Así se resuelve de forma eficaz el problema encontrado en Windows 2000, donde la actualización casi simultánea de la pertenencia a grupos en distintos controladores de dominio podía ocasionar la pérdida de datos.
Con todo, hay algo que es muy importante saber. La elevación del nivel funcional del bosque no corrige automáticamente los atributos de vínculo con varios valores con los nuevos metadatos de la replicación. Sólo los valores que se agregan después de elevar el nivel funcional del bosque tendrán los nuevos metadatos. Esto afecta significativamente a la recuperación de las pertenencias a grupos, como se verá en seguida.

Copias de seguridad
Windows incluye la utilidad básica NTBACKUP, que se puede usar para realizar una copia de seguridad del estado del sistema de un controlador de dominio. El estado del sistema de un controlador de dominio consta de su Registro, SYSVOL, los archivos de DIT de Active Directory y los archivos esenciales del sistema. Casi todas las utilidades de copia de seguridad de otros fabricantes también tienen la capacidad de realizar copias de seguridad y restaurar el estado del sistema de un controlador de dominio.
Para realizar una copia de seguridad del estado del sistema en un archivo de disco, use el comando siguiente:
NTBACKUP backup systemstate /F “<filename>”
Aquí, <filename> es el nombre del archivo de copia de seguridad que se va a crear y debe tener la extensión .bkf.

Realizar restauraciones no autoritativas
La restauración de objetos eliminados de Active Directory desde una copia de seguridad es un proceso de dos pasos. Primero se reinicia el controlador de dominio en el modo de restauración de servicios de directorio (DSRM) y, a continuación, se restaura todo el DIT de Active Directory desde la copia de seguridad del estado del sistema con la utilidad de NTBACKUP de Windows u otro producto equivalente. Este proceso sobrescribirá todo el DIT.
Hay dos maneras de iniciar un controlador de dominio en DSRM. Si tiene acceso a la consola del sistema del controlador de dominio, de apagar y reiniciar el controlador de dominio y presionar F8 cuando se le pida que abra el menú de inicio de Windows. Seleccione Restauración de servicios de directorio en el menú y escriba la contraseña de DSRM.
Si administra el servidor de forma remota, no podrá tener acceso al menú de inicio de Windows. En lugar de ello, puede cambiar las opciones de inicio del sistema seleccionando Propiedades en Mi PC, haciendo clic en la ficha Avanzadas y, presionando el botón Configuración que se encuentra en Inicio y recuperación. Presione el botón Editar de la sección Inicio del sistema para editar el archivo boot.ini y agregue el conmutador /SAFEBOOT:DSREPAIR al fin de la línea, como se muestra en la Figura 3. (Para obtener más información sobre los conmutadores de boot.ini, consulte microsoft.com/technet/ sysinternals/information/bootini.mspx).
Figura 3 Opciones de configuración de inicio de DSRM
Figura 3 Opciones de configuración de inicio de DSRM
Al reiniciar el servidor, se reiniciará en DSRM. Recuerde que tiene que quitar el conmutador /SAFEBOOT del archivo boot.ini si desea reiniciar el controlador de dominio en el modo normal.
Una vez iniciada la sesión con la contraseña de DSRM, vuelva a restaurar la copia de seguridad del estado del sistema con el comando NTBACKUP, pero sin especificar ningún parámetro. (No puede realizar una restauración con NTBACKUP desde la línea de comandos). Cuando se abra el asistente, seleccione Restaurar archivos y configuraciones y haga clic en Siguiente. A continuación, seleccione el archivo de copia de seguridad y compruebe la casilla Estado del sistema, como se muestra en la Figura 4.
Figura 4 Uso del asistente para copia de seguridad o restauración para restaurar el estado del sistema
Figura 4 Uso del asistente para copia de seguridad o restauración para restaurar el estado del sistema
Si deseara volver a iniciar el controlador de dominio en modo normal en ese momento, el proceso de replicación de Active Directory volvería a sincronizar el controlador de dominio restaurado con los demás controladores del dominio y todos los datos restaurados se sobrescribirían con los datos actuales. Obviamente, no desea que suceda esto. En lugar de ello, necesita una manera de forzar la replicación de los objetos que se están restaurando en los demás controladores de dominio del dominio.

Realizar una restauración autoritativa
NTDSUTIL aumenta también el número de versión de cada atributo en 100.000 por cada día que transcurre entre la fecha de la copia de seguridad y la fecha de la restauración. A menos que haya atributos que se actualicen más de 100.000 veces al día (lo que es muy improbable), el número de versión de los atributos restaurados será mucho mayor que los números de versión que tienen los demás controladores de dominio y el objeto restaurado autoritativamente se replicará en ellos. Los otros objetos que se han restaurado de manera no autoritativa a partir de la copia de seguridad se sobrescribirán, en última instancia, con los datos existentes en los demás controladores de dominio.
Una vez haya completado la restauración no autoritativa, pero antes de reiniciar en el modo normal, debe usar el programa NTDSUTIL para realizar una restauración autoritativa de los objetos que desee recuperar. A pesar de su nombre, la restauración autoritativa de un objeto no lo "restaura": únicamente garantiza que Active Directory replicará el objeto en los demás controladores de dominio. Para hacerlo, NTDSUTIL asigna el siguiente USN disponible al USN local de los atributos del objeto. De esta forma, el objeto se envía a los asociados de replicación la próxima vez que se sincronicen. Para restaurar un solo objeto, asegúrese de que el controlador de dominio se inicia en DSRM y siga estos pasos:
  1. Abra una ventana de comandos y escriba:
    ntdsutil
  2. En el símbolo del sistema ntdsutil, escriba:
    authoritative restore
  3. En el símbolo del sistema de la restauración autoritativa, escriba:
    restore object “<DN of object to be restored>”
    Por ejemplo, si desea restaurar la cuenta de Molly Clark de la unidad organizativa Eng en el dominio DRNET, deberá escribir:
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    Si desea restaurar de manera autoritativa todo un subárbol de un directorio, por ejemplo, una unidad organizativa, deberá escribir:
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    (NTDSUTIL proporciona también un comando de restauración de base de datos que restaura de manera autoritativa todo el dominio y los NC de configuración y esquema. La restauración de todo el dominio está llena de peligros, por lo que esta opción no es recomendable. Si tiene que restaurar un dominio entero, debe restaurar un controlador de dominio y volver a aumentar el nivel de los demás controladores de dominio en el dominio como se describe en "Planning for Active Directory Forest Recovery".
  4. Cuando se le pida, confirme que la restauración autoritativa debe aumentar los números de versión de los objetos respectivos y sus atributos.
  5. Salga de ntdsutil (debe escribir quit dos veces).
  6. Reinicie el controlador de dominio en el modo normal de Active Directory.
La próxima vez el controlador de dominio se replique con sus asociados, el usuario que ha restaurado saldrá de la replicación. La restauración del objeto de usuario es sólo la mitad del problema. Si introduce vínculos de objeto como los que hay entre un grupo y sus miembros, la situación es más complicada. Hay algunos problemas fundamentales que podría encontrarse durante la restauración y con posterioridad a ella, que se describen en las secciones siguientes.
Primero vamos a revisar lo que sucede cuando se elimina un objeto que tiene vínculos hacia atrás. Imagine que elimina un objeto de usuario que es miembro de uno o varios grupos. Cada controlador de dominio que tenga una copia del objeto de usuario la convertirá en un objeto de desecho y quitará todas las referencias de la tabla de vínculos, quitando así el objeto de usuario de todas las pertenencias a grupos en el dominio del usuario. (Recuerde que quitar el usuario de las pertenencias a grupos no es un cambio replicado, puesto que cada controlador de dominio actualiza la pertenencia a grupos de forma local. El número de versión y USN local del atributo de miembro de grupo se quedan igual). Poco después, los objetos fantasma se quitarán de las tablas de vínculos de otros dominios, también sin actualizar los metadatos de replicación del atributo de miembro de grupo.
Al restaurar de manera no autoritativa el DIT de un controlador de dominio en el dominio de usuario, se recupera el objeto de usuario junto con todas las pertenencias a grupos de los grupos del dominio, de modo que el controlador de dominio restaurado es coherente en sí mismo. Después de usar la utilidad NTDSUTIL para restaurar autoritativamente el usuario, el objeto de usuario deja de estar replicado en todos los demás controladores de dominio del dominio.
Sin embargo, puesto que los metadatos de replicación de los grupos actuales del dominio no cambian, los atributos de miembro de los grupos del controlador de dominio restaurado no son iguales que los de los demás controladores de dominio. Y no hay forma de hacerlos converger al mismo estado. Por ello, las pertenencias del usuario no se restaurarán en los otros controladores de dominio del dominio.

Problema: las pertenencias a grupos dentro del dominio no se restauran
La restauración autoritativa del objeto de usuario no recupera las pertenencias a grupos del usuario. ¿Por qué? Porque la relación de pertenencia se almacena y replica mediante el atributo de miembro de los objetos de grupo (los vínculos hacia adelante), no mediante el atributo memberOf del usuario (el vínculo hacia atrás). El problema es cómo buscar las antiguas pertenencias a grupos del usuario y, una vez se conocen, cómo recuperarlas adecuadamente.
Microsoft ha realizado mejoras progresivas en el proceso de recuperación de las pertenencias a grupos del usuario, de modo que la técnica que se utilice depende de la versión de Active Directory que se esté ejecutando. La sección siguiente está relacionada sobre todo con Active Directory en Windows 2000.
Determinar las antiguas pertenencias a grupos del usuario es bastante fácil: no tiene más que analizar el atributo de vínculo hacia atrás en el controlador de dominio restaurado, en este caso, el atributo memberOf del objeto de usuario. El atributo memberOf contendrá todas las asociaciones a grupos locales y globales del dominio del usuario. Se puede usar el complemento Usuarios y equipos de Active Directory de MMC (ADUC), o la utilidad de LDIFDE, incluida en Windows Server, para enumerar las pertenencias a grupos del usuario restauradas.
La siguiente línea de comandos de LDIFDE enumerará los grupos del dominio DRNET a los que pertenece Molly Clark, y almacenará los resultados en el archivo de output.ldf:
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
Tenga en cuenta que debe iniciar el controlador de dominio en el modo normal para usar las herramientas LDAP y, una vez más, debe deshabilitar la replicación entrante, de lo contrario, los datos que ha restaurado se sobrescribirán. La manera más fácil de deshabilitar la replicación entrante es usar el comando REPADMIN:
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
Aquí, <dcname> es el nombre del controlador de dominio en que está realizando la restauración. No olvide volver a habilitar la replicación mediante –DISABLE_INBOUND_REPL cuando haya terminado.
Si sólo va a recuperar unos cuantos usuarios, es bastante fácil volver a agregar un usuario a los grupos usando ADUC manualmente. Si va a recuperar un gran número de usuarios, hay herramientas que pueden automatizar parte del proceso. La utilidad de Microsoft GROUPADD (disponible en los servicios de soporte técnico de Microsoft) puede aceptar el archivo LDIF que creó para enumerar las antiguas pertenencias a grupos del usuario y generar un archivo LDIF que las vuelve a crear. Por ejemplo, se usaría este comando de GROUPADD para procesar el archivo LDIF creado en el ejemplo anterior para Molly Clark:
C:\> groupadd /after_restore output.ldf
Este comando creará un archivo LDIF para cada dominio a los que pertenecía Molly Clark con el nombre groupadd_<dominio>. ldf (donde <dominio> es el nombre de dominio completo del dominio cuyos grupos se van a actualizar). El archivo LDIF creado arriba se tendría que actualizar con el comando siguiente:
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
Con Windows Server 2003, Microsoft mejoró NTDSUTIL para aprovechar los metadatos adicionales que existen en el atributo de miembro para proporcionar compatibilidad con la replicación de valor vinculado (LVR). Si el objeto de usuario restaurado había sido miembro de cualquier grupo del dominio y la pertenencia a grupos del usuario se había almacenado con los metadatos de LVR, NTDSUTIL incrementa el número de versión del valor correspondiente del atributo de miembro, lo que a su vez hace que la pertenencia restaurada deje de estar replicada.
La versión de Windows Server 2003 SP1 de NTDSUTIL incorpora las funciones de GROUPADD y creará automáticamente archivos LDIF al realizar la restauración autoritativa del objeto de usuario. En la Figura 5 se muestra la nueva versión de NTDSUTIL, y en la Figura 6 el contenido del archivo LDIF creado automáticamente.
Figure 6 Contenido del archivo LDIF creado por NTDSUTIL (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
Figura 5 Nueva versión de NTDSUTIL con las capacidades de GROUPADD integradas
Figura 5 Nueva versión de NTDSUTIL con las capacidades de GROUPADD integradas
Si restaura toda una unidad organizativa que contiene varios usuarios y grupos, volver a agregar los usuarios a sus grupos manualmente es bastante laborioso. Otra forma de recuperar las pertenencias a grupos restauradas consiste en restaurar autoritativamente los propios grupos.
Con todo, la restauración autoritativa de grupos presenta dos problemas. El primero es bastante obvio: si se restaura un grupo, la pertenencia a ese grupo volverá a su estado en el momento de la copia de seguridad. Esto significa que los cambios realizados en el grupo desde la última copia de seguridad se tendrán que volver a aplicar al grupo. El segundo problema es un poco más sutil y tiene que ver con el funcionamiento de la replicación de Active Directory. Después de una restauración autoritativa de los usuarios y los grupos, no se puede saber en qué orden saldrán de la replicación. Si un objeto de grupo se replica en un controlador de dominio antes que el objeto de usuario restaurado, el controlador de dominio de replicación quitará automáticamente la referencia de usuario del grupo, porque el objeto de usuario todavía no existe en ese controlador de dominio. Cuando el objeto de usuario se replica más tarde, no se agregará al grupo.
La solución más fácil a este problema consiste en realizar la restauración autoritativa de los grupos una segunda vez. Después de realizar la primera restauración autoritativa, reinicie en el modo normal y asegúrese de que esa replicación finaliza correctamente. A continuación, vuelva a iniciar en DSRM y ejecute NTDSUTIL para realizar una restauración autoritativa de los grupos a los que pertenecía el usuario. Así se garantiza que, al volver a iniciar en el modo normal, el objeto de usuario habrá salido de la replicación antes de que se repliquen los objetos de grupo que hacen referencia a él.

Problema: las pertenencias a grupos en otros dominios no se restauran
El problema "a qué grupos pertenecía este usuario" es, en realidad, más difícil de lo que he explicado. El usuario que se va a restaurar puede haber sido miembro de grupos locales y universales de dominio en otros dominios, y esas pertenencias a grupos no se restaurarán cuando se realice la restauración no autoritativa. ¿Cómo puede saber a qué grupos de otros dominios pertenecía el usuario? La respuesta se encuentra en el catálogo global. Además de los datos de su propio dominio, el catálogo global contiene una copia de sólo lectura de los datos de los demás dominios del bosque.
Para sacar partido de los datos de todo el bosque del catálogo global, debe realizar la restauración no autoritativa en un catálogo global, lo que quiere decir que, en primer lugar, debe haber realizado una copia de seguridad de un catálogo global. Así, al ejecutar LDIFDE para identificar las pertenencias a grupos del usuario, puede conocer las pertenencias del usuario a grupos universales de otros dominios.
Al enumerar las pertenencias a grupos del usuario que va a recuperar, debe conectarse al puerto del catálogo global 3268 y no al predeterminado 389, y especificar el dominio raíz del bosque como base de la búsqueda. LDIFDE mostrará las pertenencias a grupos del usuario recuperado, incluida la pertenencia a grupos universales de todos los dominios del bosque. Para hacerlo, siga estas instrucciones:
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
Si ejecuta GROUPADD o la nueva herramienta NTDSUTIL en un catálogo global, producirá un archivo LDIF para el dominio de usuario, y un archivo LDIF para cada dominio al que el usuario restaurado pertenecía de un grupo universal. Al importar estos archivos LDIF, restaurará todas las pertenencias a grupos del usuario. Así llegamos al problema siguiente.

Problema: recuperación de pertenencias a grupos locales de dominio en otros dominios
Hay tres clases de grupos en un entorno de Active Directory de Windows. Los grupos globales sólo pueden contener miembros del mismo dominio, pero se pueden usar como miembros dentro de los grupos locales de dominio en su propio dominio y otros dominios del bosque. El atributo de miembro de grupos globales no aparece en el catálogo global, pero esto no representa problema alguno porque los grupos globales sólo contienen miembros de su propio dominio. Los grupos universales pueden contener miembros de cualquier dominio y se pueden usar como miembros en otros grupos universales del bosque y en grupos locales de dominio en su propio dominio y otros dominios del bosque. El atributo de miembro de los grupos universales se replica en los catálogos globales. Los grupos locales de dominio pueden contener miembros de cualquier dominio del bosque, pero no se pueden usar como miembros de grupos de otros dominios. Lo que es más importante, el atributo de miembro de los grupos locales de dominio, como el de los grupos globales, no aparece en el catálogo global. Como consecuencia, no una hay manera fácil de recuperar la pertenencia del usuario en los grupos locales de dominio de otros dominios.
Hasta Windows Server 2003 SP1, la única manera de recuperar las pertenencias a grupos locales de dominio en dominios externos consistía en restaurar un controlador de dominio en cada dominio, buscar manualmente los datos de dominio de todos los grupos locales de dominio que contenían el usuario restaurado y, a continuación, volver a agregar el usuario a los grupos identificados. En un entorno grande con muchos dominios, este método lleva muchísimo tiempo.
La versión de Windows Server 2003 SP1 de NTDSUTIL puede ayudar. Al ejecutar NTDSUTIL en un controlador de dominio, la utilidad crea un archivo de texto que contiene el nombre completo y el GUID de los objetos de usuario restaurados. A continuación, para cada dominio externo, puede restaurar de manera no autoritativa un solo controlador de dominio, copiar el archivo de texto en el controlador de dominio y ejecutar NTDSUTIL para generar un archivo LDIF específico del dominio que vuelva a agregar al usuario recuperado a los grupos locales de dominio a los que pertenecía.
Para hacerlo, realice los pasos siguientes en un controlador de dominio de cada dominio externo:
  1. Inicie el controlador de dominio del dominio externo en DSRM.
  2. Use NTBACKUP para restaurar una copia del DIT que contenga las pertenencias a grupos del usuario restaurado
    3. .
  3. Copie el archivo .txt creado por NTDSUTIL en el controlador de dominio actual.
  4. Abra una ventana de comandos y escriba ntdsutil.
  5. Escriba restauración autoritativa.
  6. Escriba create LDIF file(s) from <nombre de archivo> (donde <nombre de archivo> es el nombre del archivo de texto).
  7. Escriba quit dos veces para salir de ntdsutil.
  8. Reinicie el controlador de dominio en el modo normal de Active Directory
    9. .
  9. Escriba ldifde –i –f <nombre del archivo ldif> (donde <nombre de archivo ldif> es el nombre del archivo LDIF que acaba de crear).
Ya ha restaurado todas las pertenencias a grupos del usuario eliminadas.

Paso a paso
La recuperación de usuarios de Active Directory y sus pertenencias a grupos, especialmente en un entorno con muchos dominios, es complicada. Los pasos concretos necesarios para recuperar correctamente las pertenencias a grupos dependen de la versión de Windows que se ejecute.
Si se ejecuta Windows 2003 SP1, se deben realizar los pasos siguientes:
  1. Inicie un catálogo global en DSRM y realice una restauración del estado del sistema mediante una copia de seguridad que contenga al usuario eliminado.
  2. Use NTDSUTIL para realizar una restauración autoritativa del usuario eliminado. NTDSUTIL creará un archivo de texto con los DN y los GUID del objeto restaurado, y uno o varios archivos LDIF para restaurar las pertenencias a grupos del usuario.
  3. Use LDIFDE –i –f <nombre del archivo LDIF> (donde <nombre de archivo LDIF> es el nombre de los archivos LDIF creados en el paso 2) para importar las pertenencias a grupos en el dominio actual y otros dominios.
  4. Reinicie el catálogo global en el modo normal
    5. .
  5. En un controlador de dominio de cada dominio externo, inicie DSRM y realice una restauración del estado del sistema mediante una copia de seguridad que contenga las pertenencias a grupos del usuario restaurado.
  6. Ejecute NTDSUTIL mediante el comando create ldif files.
  7. Reinicie el controlador de dominio en el modo normal.
  8. Con LDIFDE –i –f filename <nombre de archivo> (donde <nombre de archivo> es el nombre de archivo que ha creado en el paso 6) restaure las pertenencias a grupos en el dominio externo.
  9. En este momento, si lo desea, puede forzar la replicación con REPADMIN/syncall.
Si ejecuta una versión de Windows Server 2003 sin SP1 instalado, o si ejecuta Windows 2000, tiene que realizar ciertos pasos adicionales. Como la versión antigua de NTDSUTIL no crea archivos LDIF, use la utilidad GROUPADD para crearlos. El proceso es el siguiente:
  1. Inicialice un catálogo global en DSRM y realice una restauración del estado del sistema con una copia de seguridad que contenga el usuario eliminado.
  2. Deshabilite el NIC o desenchufe el cable para impedir la replicación entrante.
  3. Reinicie el catálogo global en el modo normal.
  4. Utilice LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf para volcar la pertenencia del usuario con el nombre distintivo <dn>.
  5. Utilice GROUPADD /after_restore membership.ldf para crear los archivos LDID.
  6. Use LDIFDE –i –f <nombre de archivo> (donde <nombre de archivo LDIF> es el nombre del archivo LDIF creado por GROUPADD en el paso 5) para importar las pertenencias a grupos del dominio actual y otros dominios.
  7. Vuelva a habilitar la replicación mediante REPADMIN/options <dcname> -DISABLE_INBOUND_REPL.
  8. En un controlador de dominio de cada dominio externo, inicie DSRM y realice una restauración del estado del sistema mediante una copia de seguridad que contenga las pertenencias a grupos del usuario restaurado.
  9. Reinicie el controlador de dominio en el modo normal.
  10. Con LDIFDE –i –f <nombre de archivo>(donde <nombre de archivo> es el nombre del archivo LDIF creado por GROUPADD en el paso 5) restaure las pertenencias a grupos en el dominio externo.
  11. En este momento, si lo desea, puede forzar la replicación con REPADMIN/syncall.
Ahora, lo único que falta es que el entorno anterior a Windows Server 2003 anterior a SP1 recupere las pertenencias a grupos locales del dominio externo del usuario restaurado. Las únicas opciones son restaurar manualmente las pertenencias a grupos locales del dominio o restaurar un controlador de dominio a partir de una copia de seguridad y restaurar autoritativamente los grupos locales de dominio.

Resumen
Aunque sea bastante fácil eliminar accidentalmente usuarios o unidades organizativas de Active Directory, la recuperación correcta de los usuarios eliminados y sus pertenencias a grupos puede ser muy compleja, laboriosa y dada a errores. Para asegurarse de que puede recuperarse de estos desastres lo más rápidamente posible, debe entender la mecánica de la vinculación de objetos, la replicación, la eliminación y las restauraciones autoritativas.
¿Cree que puede realizar todos los pasos correctamente la primera vez que trate de hacerlo en su entorno de producción? Para asegurarse de que está preparado la próxima vez que tenga que recuperar el objeto de usuario del director general, debe disponer por escrito de un plan para recuperar los objetos eliminados. Ponga el plan en práctica por lo menos un par de veces antes de usarlo en datos reales. Su jefe (y su director general) se lo agradecerán.
Recursos adicionales
  • Cómo restaurar cuentas de usuario eliminadas y sus pertenencias a grupos en Active Directory
  • Servicios de soporte técnico de Microsoft
  • Guía paso a paso para la administración de Active Directory

Gil Kirkpatrick es Director de tecnología de NetPro y ha desarrollado software para Active Directory desde 1996. Junto con Guido Grillenmeier de HP, imparte los conocidos talleres de Recuperación de desastres de Active Directory. También es el fundador de la Conferencia de expertos en directorios (www.dec2007.com).


 Administraci&#243;n de Windows: Razones por las que Windows XP Embedded le resulta importante
Administración de Windows Don Jones

Razones por las que Windows XP Embedded le resulta importante
Resumen:
  • Qué encierra Windows XP Embedded
  • Opciones especiales de hardware
  • Personalización de Windows XP Embedded

Windows XP Embedded es la versión por componentes de Windows que asocia frecuentemente con dispositivos electrónicos para el consumidor, como por ejemplo, cajas de adaptación multimedios o aparatos electrónicos. Pero Windows XP Embedded también puede tener su espacio en la integración de la tecnología de la información en la empresa. Aunque quizás no sea la mejor
solución para cada uno de los usuarios, existen algunas situaciones específicas en las que reduce las tareas administrativas, ofrece hardware potencialmente más barato y reducido, así como mayor seguridad.

Qué es Windows XP Embedded
Windows ® XP Embedded es una de las tres versiones de superficie pequeña de Windows, junto con Windows Embedded CE y Windows Embedded para Punto del Servicio. Entre los sistemas operativos incrustados de Windows, únicamente Windows XP Embedded ofrece la funcionalidad completa (o al menos el potencial para ofrecerla) de un equipo cliente de Windows XP Professional. Se basa en Windows XP Professional Service Pack 2 (SP2); sin embargo, Windows XP Embedded es diferente del Windows XP habitual en su nivel extremo de modularización. Windows XP Embedded no tiene lo que probablemente denomine una imagen estándar de instalación. En su lugar, se usa un conjunto de herramientas denominado Windows Embedded Studio con el fin de crear un entorno personalizado de Windows XP Embedded para cualquier dispositivo que esté creando, y ese entorno incluye sólo la funcionalidad que su dispositivo va a necesitar. Si no necesita DirectX ® ni Windows Explorer, bastará con que no los instale. Esta modularización significa que cada una de las imágenes de Windows XP Embedded que cree e implemente tendrá menos partes móviles, para expresarlo de alguna forma, lo cual significa que el esfuerzo administrativo será menor y la seguridad mayor; por otra parte se aporta una capacidad para trabajar con hardware más barato. Algunas de las opciones disponibles se pueden ver en Target Designer (que forma parte de Windows Embedded Studio), como se muestra en la Figura 1.
Figura 1 Selección de los componentes en Target Designer
Figura 1 Selección de los componentes en Target Designer

Un lugar en la empresa
Cada vez más escenarios de usuario resultan idóneos para un dispositivo basado en Windows XP Embedded. Por ejemplo, las empresas con grandes centros de atención telefónica para el servicio a clientes. En muchos casos, los representantes de los centros de atención telefónica necesitan una o dos aplicaciones desarrolladas internamente y, quizás, un explorador web. Únicamente, están usando una parte de las capacidades del equipo, de modo que Windows XP Embedded le permite reducir esas capacidades para que se ajusten a lo estrictamente necesario. Cuando la funcionalidad es menor, se expone un área más pequeña de la superficie a errores o a posibles ataques a la seguridad.
Debido a que los dispositivos de Windows XP Embedded tienen una funcionalidad limitada, se pueden ejecutar en hardware con menor potencia y, por lo general, más barato. Varios fabricantes producen placas base que usan procesadores con menos potencia y compatibles con Intel. Estas placas base son muy pequeñas, usan muy poca energía y, a menudo, no necesitan un ventilador ya que no se calientan. Funcionan muy bien en dispositivos de pequeña superficie e incrustados con capacidad para ejecutar únicamente un conjunto reducido de aplicaciones.

Superpoderes especiales de Windows XP Embedded
Windows XP Embedded ofrece algunas opciones muy valiosas que no están disponibles en la versión completa de Windows XP. El Filtro de escritura mejorado (EWF) e Hibernar una vez, Reanudar muchas (HORM) pueden hacer más sencillas las tareas de administración de Windows. El EWF es un componente opcional que se puede agregar a una implementación de Windows XP Embedded que haga que un volumen determinado de disco sea de sólo lectura. Cualquier actividad de escritura en el disco se desvía a una superposición que puede encontrarse en otro disco o incluso en la memoria. El mismo sistema operativo ve la superposición de EWF y su volumen primario como una sola unidad, lo cual significa que parece un volumen normal de disco. Entre bastidores, sin embargo, el volumen primario no cambia realmente; los cambios sólo se realizan en la superposición del EWF. Esto puede resultar favorable de diversas maneras. Imagine que implementa una imagen de Windows XP Embedded para una tarjeta Compact Flash (CF) (las imágenes de Windows XP Embedded pueden pesar tan solo 5 MB y, a menudo, llegan a alrededor de 200 MB, de modo que una CF tendría mucho espacio para almacenamiento). Esa tarjeta de CF puede conectarse a un adaptador y a un conector IDE de la placa base, de forma que la tarjeta CF parece un disco fijo normal. Las tarjetas CF actuales tienen una capacidad de escritura reducida (alrededor de 100.000), de modo que el EWF se usaría para que el volumen de CF fuera de sólo lectura. Imagine que tiene que poner la superposición del EWF en la memoria RAM: si el usuario comete un error, bastará con apagar el equipo. La superposición del EWF y los cambios realizados en el equipo se pierden inmediatamente. Cuando reinicia el equipo, regresa al punto de partida almacenado en la tarjeta CF. Puede usar la misma configuración para una imagen basa en CD o DVD, ya que estos tipos de medio son intrínsecamente de sólo lectura, EWF captura cualquier actividad de escritura para una superposición. Incluso aunque la superposición se hubiera almacenado en un disco duro interno pequeño, con toda seguridad, el volumen de arranque original (en CD o DVD) no se cambia nunca; si usted restablece el equipo a su configuración original, bastará con que elimine la superposición del EWF.
Con HORM, como su nombre indica, puede hacer hibernar un equipo una vez y, posteriormente, reanudar a partir de ese punto de hibernación una y otra vez. El equipo se enciende casi instantáneamente. Configure el equipo y obtenga todas las aplicaciones necesarias que se estén ejecutando y, a continuación, hágalo hibernar. A partir de ese momento, cada vez que usted encienda el equipo, sólo necesitará esperar unos pocos segundos para que todo empiece a funcionar.

Creación de una imagen de Windows XP Embedded
Microsoft cuenta con un programa de socio incrustado formado por empresas que están especializadas en trabajar con Windows XP Embedded (los listados de tales empresas se encuentra en la página principal de Windows XP Embedded en microsoft.com/embedded). Sin embargo, con tantas empresas que proporcionan a los fabricantes de PC imágenes creadas previamente (donde se incluyen aplicaciones corporativas y configuraciones específicas), es posible que quiera crear sus propias imágenes de Windows XP Embedded, las cuales podrá compartir con un socio incrustado que le suministre sistemas completos y de superficie pequeña. El Windows Embedded Studio, que se instala en Windows XP Professional, se puede usar para crear y administrar imágenes de Windows XP Embedded.
Para usar el conjunto de herramientas, instale en primer lugar la versión completa de Windows XP Professional en el hardware que tenga previsto usar para el sistema Windows XP Embedded. De esta forma, podrá usar la rutina de configuración completa de Windows XP al objeto de que todo el hardware funcione de forma adecuada. A continuación, instale Windows Embedded Studio. Por lo general, se instala una base de datos que se usa para administrar imágenes incrustadas, pero ésta se puede instalar en cualquier otra ubicación, lo que proporciona un repositorio central. Posteriormente, ejecutará una utilidad de línea de comandos denominada Tap.exe, la cual crea un componente nuevo especial que puede usar Windows XP Embedded. Normalmente, los componentes encapsulan la funcionalidad, como por ejemplo, un reproductor de medios, un sistema de archivos u otras aplicaciones personalizadas; en este caso, estará creando un componente que contiene los controladores de dispositivos de hardware necesarios para su sistema en particular. Este paso se debe completar en el hardware de destino, de forma que la herramienta pueda detectar e incluir los controladores apropiados de hardware.
En el paso siguiente, ejecute el Diseñador de componentes de Windows XP Embedded e importe el paquete de componentes que ha creado la utilidad Tap.exe. Como se muestra en la Figura 2, el Diseñador de componentes lee la información del dispositivo y ensambla un componente de Windows XP Embedded, que podría convertirse en la base de una imagen nueva de Windows XP Embedded. Esto simplifica mucho el proceso que determina exactamente qué controladores de dispositivo necesitará una plataforma determinada. Después de crear el componente, usará el Administrador de bases de datos de componentes para importar el componente nuevo a la base de datos de componentes de Windows XP Embedded, un repositorio donde se almacenan todos los componentes de Windows XP Embedded. Cuando se tiene un componente en la base de datos, estará disponible para su uso en las imágenes de Windows XP Embedded.
Figura 2 Diseñador de componentes
Figura 2 Diseñador de componentes
Ahora ya está preparado para comenzar a crear una configuración de destino nueva, con el Diseñador de destino de Windows XP Embedded, la herramienta donde realizará la mayor parte de su trabajo. Como se vio en la Figura 1, agregará los componentes que necesite para crear el conjunto de funciones que requiera el dispositivo. También necesitará agregar algunos componentes principales de Windows, como por ejemplo el Explorador de Windows (si su dispositivo requiere un shell gráfico), el sistema de archivos NTFS (o FAT32), el Cargador NT, compatibilidad para un idioma, el interfaz de usuario principal, etc. Más de diez mil componentes están disponibles de forma predeterminada.
También puede preconfigurar los valores de cada componente. Por ejemplo, el componente de la interfaz de usuario principal se puede personalizar para que muestre elementos específicos en el menú Inicio de Windows, en el Escritorio y en otras ubicaciones. La capacidad de personalizar los valores para cada componente asegura que cada dispositivo quedará preconfigurado con el fin de adaptarse a sus necesidades (consulte la Figura 3).
Figura 3 Personalización de los valores
Figura 3 Personalización de los valores
La parte más complicada de una imagen de Windows XP Embedded son las dependencias. Por ejemplo, no puede agregar un componente de DirectX a la imagen sin agregar también varios componentes que proporcionan a Windows sus capacidades principales de gestión de gráficos. Llevar un seguimiento de todas las dependencias puede resultar bastante difícil, especialmente para las imágenes más pesadas y complejas que podrían tener, literalmente, miles de dependencias. Este es el trabajo de la base de datos de componentes. Bastará que presione F5 en el Diseñador de destino para que examine todos los componentes que ha agregado y, de forma automática, agregará las dependencias que necesiten los componentes que se encuentran en la lista. La Figura 4 muestra el examen en curso; se trata de un paso fundamental y es lo que permite que Windows XP Embedded sea tan modular. Sin esta inteligencia integrada en el Diseñador de destinto, sería muy difícil crear correctamente las imágenes que contengan todas las dependencias adecuadas.
Figura 4 Comprobación de dependencias
Figura 4 Comprobación de dependencias
Una vez se hayan agregado todos los componentes y sus dependencias, podrá crear la imagen de Windows XP Embedded. Las imágenes son simplemente los archivos que se deben copiar en el volumen de arranque del dispositivo de Windows XP Embedded. No necesita ninguna herramienta especial para implementarlas (aunque el conjunto de herramientas de Windows XP Embedded incluye un servidor de arranque remoto semejante en la funcionalidad a los Servicios de instalación remota; permite la implementación de imágenes de Windows XP Embedded en hardware a partir de cero). Tras completar estos pasos, podrá comprobar el tamaño de su imagen. He creado una imagen muy básica que incluye el shell de Explorer y unas cuantas aplicaciones, como por ejemplo, el Bloc de notas y Paint, y he creado una imagen de menos de 90 megabytes. Seguramente no encuentre muchos usuarios que estén interesados en un dispositivo donde solamente se puedan ejecutar el Bloc de notas y Paint, pero ilustra lo pequeña que pueda ser una imagen para una tarea específica.

Windows XP Embedded frente a Windows XP
Windows XP Embedded no es para nada una opción de sistema operativo con menos funciones. Microsoft pone a su disposición componentes empaquetados previamente que permiten que un equipo que ejecute Windows XP Embedded tenga gran parte de la misma funcionalidad que tiene una versión completa de Windows XP. Esto incluye las opciones para instalar DirectX 9.0c, Microsoft ®.NET Framework, Windows Media® Player 10 y mucho más. También encontrará gran cantidad de información para desarrolladores donde se describe cómo crear componentes personalizados, como por ejemplo, un shell personalizado para reemplazar a Explorer, lo que le permitirá crear un entorno a la medida para un dispositivo incrustado determinado.
Windows XP Embedded, sin embarbo, no ofrece todas las funciones que se incluyen en la versión completa de Windows XP Professional. Por ejemplo, Protección de archivos de Windows (WFP) no está incluida en Windows XP Embedded; tampoco lo están algunas de las características descriptivas, como son Paseo por Windows XP, las pantallas de bienvenida iniciales y los asistentes que ayudan a los usuarios nuevos a configurar su equipo, o Instalación de Windows. Windows XP Embedded no usa la Activación de productos de Windows (las imágenes de Windows XP Embedded se activan mediante el uso de una clave de producto de tiempo de ejecución que se encuentra en las herramientas de Windows Embedded Studio). Principalmente, Windows XP Embedded no usa Windows Update en absoluto, aunque puede usar un servidor de Microsoft Software Update Services en su entorno. Finalmente, Windows XP Embedded también carece de MSN ® Explorer, el cual está incluido en Windows XP Professional.
Si miramos hacia el futuro, Windows XP Embedded sigue evolucionando con nuevas funciones: Feature Pack 2007 se encuentra ahora disponible, el cual agrega nuevas características, como por ejemplo, un arranque basado en USB, mejoras en el EWF que permiten que archivos nuevos se comprometan con el volumen primario sin necesidad de comprometer a la superposición en su totalidad, compatibilidad para la compresión NTFS y mucho más. Estas mejoras siguen agregando flexibilidad y opciones al sistema operativo Windows XP Embedded, a la vez que hacen que vaya igualando al conjunto de funciones de Windows XP Professional.

Avanzando hacia los sistemas incrustados
Es posible que lleve más trabajo crear los sistemas incrustados que un sistema Windows XP tradicional, pero ofrecen ventajas considerables en ciertas situaciones. A pesar de que su funcionalidad es más reducida, los sistemas Windows XP Embedded pueden prestar compatibilidad a hardware más pequeño y de menos necesidades energéticas, cuyo cuidado y reparaciones son más sencillos, por otra parte su costo es más bajo. El bajo consumo energético ayuda igualmente a reducir los costos de las utilidades y la generación de calor, lo que ofrece más flexibilidad en el diseño de espacios de trabajo compactos. Aparte de los usos que se esperan de Windows XP Embedded (dispositivos para el consumidor, dispositivos de asistencia sanitaria, quioscos, y otros lugares donde puede que ni se dé cuenta de que Windows XP Embedded está presente), puede que este sistema operativo incrustado también tenga un lugar en su empresa.

Don Joneses el director de proyectos y servicios de SAPIEN Technologies y coautor de Windows PowerShell: TFM (SAPIEN Press). Póngase en contacto con Don a través de su sitio web en www.ScriptingAnswers.com.


 Administraci&#243;n: Planee de antemano con System Center Capacity Planner
Administración John Savill

Planee de antemano con System Center Capacity Planner
Resumen:
  • Principios de SCCP
  • Creación de un nuevo modelo
  • Ajuste del modelo
  • Simulación de uso real

En la actualidad, los componentes de la infraestructura son esenciales para las empresas a las que dan soporte. Sin embargo, con el aumento del número de usuarios y la mayor diversidad de las empresas, la estimación precisa del tamaño y
el número de servidores necesarios para ejecutar los componentes puede resultar complicado. Un hardware insuficiente lleva a tiempos de respuesta largos, pero un hardware excesivo no es más que un desperdicio de recursos del presupuesto y conlleva más tareas de administración. Por todo ello, Microsoft creó la herramienta System Center Capacity Planner (SCCP) 2006.
En un nivel superior, SCCP le permite escribir información sobre la topología de la red (ubicaciones, velocidades de los vínculos, latencia), el software y el hardware que se deben usar, y los perfiles del uso (por ejemplo, el número de mensajes enviados). A continuación, SCCP ejecuta simulaciones de distintos niveles de uso y detalla la utilización de componentes de hardware y de red. Esta creación de modelos ayuda a comprobar si la configuración propuesta, si se implementara, sería adecuada para lograr los requisitos del servicio.
No hace falta ejecutar SCCP en ningún servidor específico ni realizar pruebas de red; es esencialmente una herramienta de simulación que se puede ejecutar en escenarios de prueba en un modelo de entorno. Los requisitos del sistema para SCCP son mínimos: Windows® XP con Service Pack 2 (SP2), Windows Server® 2003 o Windows 2000 con SP4, más Microsoft®.Net Framework 2.0. Es de esperar que la siguiente generación de SCCP se comunique más estrechamente con Systems Management Server (SMS) y Microsoft Operations Manager (MOM), y que automatice parte de la recopilación de información, puesto que MOM ya recopila información sobre la utilización de servidor y SMS dispone de información sobre la configuración del hardware.
La instalación de SCCP 2006 es sencilla. Se usa un asistente para instalación estándar que sólo requiere la aceptación del contrato de licencia y la confirmación de la carpeta de instalación. Una vez que el producto está instalado, se agrega un acceso directo al menú Todos los programas. La primera vez que se inicia SCCP, la pantalla de bienvenida de la herramienta de planeación de capacidad de Microsoft ofrece acceso a tres de los cuatro componentes de la herramienta, como se muestra en la Figura 1.
Figura 1 Iniciar la herramienta de planeación de capacidad
Figura 1 Iniciar la herramienta de planeación de capacidad
El Asistente para modelos le hace preguntas sobre el entorno deseado, para crear un Modelo de arquitectura del sistema (SAM). El SAM contiene los datos de las ubicaciones, los usuarios, la red, los patrones de uso y el hardware.
El editor de modelos permite ajustar con precisión y modificar el SAM que se ha creado con el asistente o el editor. Es aquí donde puede validar los modelos, mostrar el uso simulado y probar otros escenarios como la carga adicional de los servidores de correo o la presencia de usuarios remotos.
La herramienta de planeación de la capacidad cuenta con varios tipos de hardware predefinidos para el uso en SAM. Sin embargo, si sus necesidades son otras, el editor de hardware admite la definición personalizada de configuraciones de hardware.
Cuándo se selecciona un modelo, la simulación de herramienta de planeación de la capacidad permite realizar varias pruebas en dicho modelo, para determinar su viabilidad para la implementación en una situación real.
La mejor manera de observar los componentes y su funcionamiento conjunto es la de usar la herramienta. Voy a comenzar con el asistente, ejecutaré una simulación y, a continuación, ajustaré con precisión un modelo de arquitectura agregando hardware personalizado. En este tutorial voy a trabajar con un entorno de Exchange, pero el proceso funciona de forma parecida para MOM.

Crear un modelo
Para poder realizar la validación o escenarios "y si" en una infraestructura planeada, o incluso si sólo desea ejecutar escenarios sobre la infraestructura implementada actualmente, debe describir el entorno a SCCP. Lamentablemente, en la versión actual no se puede simplemente digitalizar la red. En su lugar, debe detallar la infraestructura en lo que se refiere a ubicaciones físicas y tipos de conectividad entre ellas, colocación de servidores, buzones y usuarios, y detalles sobre cómo van a usar el entorno los usuarios.
La herramienta está sujeta a ciertas limitaciones, que se explican pormenorizadamente en la guía de usuario. Por ejemplo, en un modelo de Exchange, se admite un bosque único. Esto quiere decir que no se crea un modelo de los dominios en bosques externos, y se asume que los servidores de aplicaciones para usuario tienen un catálogo global y un almacén de buzones en el mismo sitio. Sólo se puede crear un modelo para 100 sitios, de los cuales 10 como máximo pueden ser sitios concentradores, un máximo de 300 equipos servidor, y sólo se admiten clientes de Outlook® 2003 (web o locales). La parte positiva es que SCCP admite hasta 49.999 clientes en ubicaciones centrales o de concentrador, y hasta 10.000 en sucursales. No se admiten características de Exchange como ActiveSync® y conexiones de Outlook Mobile Access, ni tampoco opciones heredadas de conectividad como POP e IMAP. No se tiene en cuenta la utilización generada por operaciones de copia de seguridad y restauración, como tampoco lo son configuraciones de clúster. Sin embargo, la herramienta de planeación de la capacidad dispone de las opciones necesarias para crear un modelo preciso del uso habitual del correo.
Para empezar el tutorial en la página de bienvenida, seleccione la opción para crear un modelo con el Asistente para modelos y describa la infraestructura cuyo modelo se va a crear. Voy a crear una empresa que tiene tres ubicaciones: una ubicación central en Dallas y sucursales en Houston y Austin, todas ellas con varios usuarios locales de correo electrónico. No tiene que haber necesariamente servidores en cada ubicación, por lo que proporciono información sobre el número y el tipo de usuarios de correo electrónico. SCCP determinará en qué ubicaciones debe haber servidores de Exchange locales y dónde tendrán acceso los usuarios a su servidor de Exchange de forma remota.
Después que crear un modelo básico de la infraestructura de la empresa, el asistente pregunta el número de sitios centrales y de sucursales, la conectividad entre sitios, y el porcentaje del ancho de banda que se puede usar para la mensajería. El asistente adopta un enfoque amplio para empezar a funcionar; más adelante, puedo realizar ajustes en el modelo creado por el asistente para configurar vínculos individuales con más granularidad. En este ejemplo, puedo confirmar que hay una oficina central y dos sucursales (consulte la Figura 2). Hay conexiones T1 entre las sucursales y la oficina central, y se puede usar la mitad del ancho de banda para la mensajería. No es necesario que configure la velocidad entre sitios centrales, puesto que sólo hay uno.
Figura 2 Configurar la topología de WAN y el ancho de banda de conexión
Figura 2 Configurar la topología de WAN y el ancho de banda de conexión
En la ventana siguiente del asistente se pregunta el número medio de usuarios en las sucursales, el cliente de correo electrónico (Outlook 2003 en modo en caché o Outlook Web Access), y el número de usuarios en la oficina central. Una vez más, se trata de información de muy alto nivel, que se puede ajustar posteriormente con el Editor de modelos. En este caso, diré que cada sucursal tiene 200 usuarios y la oficina central tiene 500, y que todos ellos usan Outlook en modo en caché.
El asistente tiene tres niveles predeterminados de uso de correo: alto, medio y bajo. En cada nivel se asume un tamaño medio de buzón distinto, un número de mensajes enviados y recibidos, y un tamaño medio de mensaje de correo electrónico. Si ninguno de los tipos integrados coincide con los patrones de uso esperados en su organización, se puede configurar cada uno de los valores individuales de cuatro características de uso independientes.
El paso siguiente consiste en configurar las preferencias de hardware, como se muestra en la Figura 3. SCCP admite la especificación de hasta tres configuraciones posibles de CPU, que se usarán para crear el modelo de hardware para las distintas funciones de servidor. Las configuraciones de CPU van desde un único procesador Pentium III Xeon a 1 GHz hasta un procesador Xeon MP cuádruple a 3.66 GAZ. Exchange 2003 consta de varias funciones, que son Almacén de buzones, Cabeza de puente y Cliente, más una función adicional de catálogo global de Active Directory®. Si la utilización lo permite, existe la opción de consolidar funciones en un número menor de servidores. Si no se especifica la consolidación de servidores, se configurarán servidores independientes para cada una de las funciones, aunque la utilización no lo requiera. Si se permite que SCCP consolide servidores se obtendrán mejores resultados.
Figura 3 Configurar perfiles de hardware para servidores
Figura 3 Configurar perfiles de hardware para servidores
Por último, se puede seleccionar el tipo de discos disponibles en función de la interfaz, el tamaño y la velocidad. No es necesario indicar el número de discos, la herramienta de planeación de capacidad lo calculará. La herramienta puede especificar también una Red de área de almacenamiento (SAN), aunque en la actualidad no existe la capacidad de crear clústeres.
El paso siguiente del asistente es un resumen del modelo estimado, que muestra el número de servidores que SCCP calcula como óptimo, las funciones de cada uno de los servidores, y datos como las configuraciones de procesadores, memoria y discos. Si se había seleccionado una SAN, también se muestra.
Tenga en cuenta que, como he seleccionado varias ubicaciones, es posible que sólo se muestren los servidores de un subconjunto de las ubicaciones. Es así porque SCCP confirmó que los servidores de Exchange locales de algunas ubicaciones no son óptimos y es mejor dar servicio a los buzones a través de un servidor de buzones remoto de Exchange, que es el caso en el ejemplo que se muestra en la Figura 4. En este caso, los 400 usuarios de las sucursales no tienen almacén de buzones local de Exchange, si no que se han unificado en el único servidor de almacén de buzones de Exchange en la ubicación de Dallas, que ahora muestra 500 usuarios.
Figura 4 Resumen de la evaluación inicial de la planeación de capacidad
Figura 4 Resumen de la evaluación inicial de la planeación de capacidad
Hasta este punto del asistente puedo hacer clic en los botones Atrás y Siguiente para modificar las respuestas y ajustar el resumen del modelo (o hacer clic directamente en las páginas de asistente desde el panel de exploración izquierdo). Una vez satisfecho con la configuración, hago clic en el botón Finalizar de la página de resumen del modelo. Así se abre el modelo en el Editor de modelos, donde se puede realizar una configuración más granular.

Ajustar el modelo
El Asistente para modelos es una gran herramienta para crear un modelo de básico. Sin embargo, a menos que las distintas ubicaciones sean iguales y se pueda obtener una media, es probable que se necesite algún tipo de personalización para que el modelo sea realmente útil como punto de partida para calcular la utilización. No es excepcional que las ubicaciones tengan distinto número de usuarios, o quizás una combinación de varios clientes de mensajería, como Outlook 2003 en caché y Outlook Web Access (OWA). Si bien no es posible llegar a este nivel de detalle en el Asistente para modelos, se puede configurar mediante el Editor de modelos. Esta herramienta resulta también útil al tratar de comprobar los efectos de modificar algunos aspectos del entorno, por ejemplo agregando ubicaciones o tipos de usuarios adicionales.
El Editor de modelos, que se muestra en la Figura 5, guarda y recupera los modelos en archivos .sam, un formato propio de la herramienta. Es recomendable, lo mismo que con todo el trabajo, guardar los modelos en archivos antes de realizar cambios importantes, y usar un nombre descriptivo para asegurar que no se pierde ningún modelo de trabajo. En el menú Archivo existe la opción Exportar, que genera un informe de resumen detallado en formato de Excel® y como diagrama de topología de Visio® del modelo.
Figura 5 Ajustar una configuración SAM en el Editor de modelos
Figura 5 Ajustar una configuración SAM en el Editor de modelos
En el panel izquierdo del Editor de modelos hay un área básica de exploración con opciones para ver la topología global, la topología del sitio o un resumen del modelo. La topología global muestra el modelo de la arquitectura de una perspectiva del sitio, con redes adicionales como Internet. La vista de la topología del sitio muestra información sobre un sitio o red seleccionados. El resumen del modelo muestra un resumen textual del entorno, que es el mismo formato que se mostrará al finalizar el Asistente para modelos.
Sea cual sea la opción seleccionada, los detalles se muestran en el panel central del Editor de modelos. El panel derecho (en cierto modo parecido a la nueva versión de Microsoft Management Console (MMC) que se comercializó con Windows Server 2003 R2) es un área de "acciones" dividida en dos subáreas: la parte superior ofrece acciones contextuales que cambian en función de la vista actual o el objeto seleccionado, mientras la parte inferior contiene acciones generales que se pueden aplicar siempre. Estas últimas acciones permiten agregar un sitio nuevo, editar los perfiles de uso de los usuarios y ejecutar una simulación.
Al trabajar en el panel central del Editor de modelos, se pueden seleccionar todos los elementos. Después que seleccionar un elemento, además de que las acciones del elemento actual cambian en función del objeto seleccionado, puedo ver más detalles del objeto. Por ejemplo, al hacer doble clic en un sitio, se mostrará la vista de la topología del sitio, con detalles de los modelos de objeto de ese sitio. Así, un sitio con servicios locales mostraría uno o varios servidores, las redes y los usuarios de la ubicación. Esto permite, a su vez, hacer doble clic en el objeto seleccionado para ver sus propiedades detalladas y, a continuación, modificarlas como sea necesario.
Las líneas que conectan los sitios representan las redes entre las ubicaciones y se pueden editar para permitir la configuración exacta de la red. Por ejemplo, puedo especificar velocidades de ancho de banda distintas de vínculo superior y vínculo inferior, así como el porcentaje del ancho de banda disponible. También puedo configurar la latencia de las conexiones, que puede ser un atributo muy importante para lograr comunicaciones estables. Otro cambio habitual es la adición de más tipos de usuario. En este caso, digamos que tengo una combinación de clientes de Outlook Web Access y Outlook 2003 atendidos por la ubicación central. Después de abrir Dallas en la vista de topología del sitio, seleccionaría la opción para agregar un perfil de cliente, y agregaría información para los usuarios basados en el OWA consistente en el servidor que usarán los clientes de OWA, la red desde la que se conectarán los usuarios, y el ancho de banda que tendrán a su disposición, como se muestra en la Figura 6.
Figura 6 Agregar y modificar elementos en un modelo es muy sencillo
Figura 6 Agregar y modificar elementos en un modelo es muy sencillo
Una vez que SAM refleja la infraestructura existente o planeada con fidelidad, debe guardarla y darle un nombre como corresponda, para garantizar que se puede identificar fácilmente como punto de partida de modificaciones futuras. En este momento, deseo ejecutar una simulación para obtener un punto de referencia sobre el rendimiento del modelo en la configuración establecida. En función de ese punto de referencia, puedo modificar el modelo para probar varios escenarios "y si", como la adición de un nuevo sitio y de usuarios, la adición o eliminación de servidores, la adición de usuarios a las ubicaciones, o el cambio del tipo de conexión o de cliente de correo electrónico. Una vez que el modelo se ha actualizado con estos elementos, puedo ejecutar otra simulación para conocer el rendimiento de la nueva configuración.

Simular el uso real
La ejecución de la simulación es tan sencilla como hacer clic en la acción general de ejecución de simulación o en el botón de la barra de herramientas. Primero se muestra una comprobación del estado del modelo: cualquier error del modelo se muestra antes de realizar la simulación. Por ejemplo, si se agregan clientes de OWA a un modelo que anteriormente no tenía ninguno y no había configurado un servidor de aplicaciones para usuario, un mensaje de error le notificará que no hay ningún servidor de aplicaciones para usuario. Si no hay ningún error, el estado se mostrará mientras se realiza la simulación.
Cuando finaliza la simulación, se genera un informe con información detallada sobre del uso de todos los componentes y se abre la vista de resultados de la simulación. Inicialmente, en ella se muestra un resumen con los detalles de la CPU de nivel superior, la utilización del almacenamiento y los vínculos de conexión (que suelen generar cuellos de botella), así como tiempos de transacción y latencia más largos, que pueden afectar a la experiencia del usuario final. Los detalles sobre la utilización exacta de los servidores, SAN, y conexiones locales y externas se pueden ver seleccionando los vínculos del panel izquierdo de los resultados de la simulación, como se muestra en la Figura 7.
Figura 7 Resumen de los resultados de la simulación de un modelo sencillo
Figura 7 Resumen de los resultados de la simulación de un modelo sencillo
Si mantiene el mouse sobre las distintas representaciones gráficas, por ejemplo el análisis de cuellos de botella, se muestran el servidor y el atributo del servidor que causan un cuello de botella. Fíjese en la configuración de umbral en el panel izquierdo. Esta categoría permite establecer lo que considero un uso razonable antes de que se generen advertencias, una característica muy útil.
Los informes detallados de la simulación son de gran interés, no sólo para ayudar en la toma de decisiones de compra de hardware, si no también para mostrar la cantidad de recursos de red que serán usados por las aplicaciones de mensajería. Por ejemplo, para los usuarios que se conecten a través de vínculos WAN más lentos, el informe ofrece información sobre si el vínculo es lo suficientemente rápido. Si no lo es, puedo averiguar si la velocidad del vínculo entre ubicaciones se debe mejorar o si se debe agregar un servidor local de almacén de buzones, simplemente modificando el modelo y volviendo a ejecutar la simulación para obtener resultados que se ajusten a criterios específicos. De la misma forma, si todos los servidores se ejecutan a un 5 por ciento de utilización de CPU, puedo reducir la especificación de los servidores. La posibilidad de modificar los modelos con facilidad y de volver a ejecutar las simulaciones, tengo la opción de probar varias opciones de solución. Con indicadores precisos de todos los escenarios de prueba, puedo asistir a las reuniones sobre presupuestos y planeación con total confianza.

Resumen
He ofrecido una descripción general de cómo SCCP permite simular y analizar la implementación de Exchange. No olvide que SCCP realiza el mismo nivel de creación de modelos y simulación también para MOM. SCCP se puede descargar en la actualidad como parte de las descargas de MSDN® Premium o de TechNet Plus. ¦

John Savill es Director de infraestructura técnica de Geniant. Es CISSP, MCSE de seguridad y mensajería de Windows Server 2003, ocho veces MVP, e instructor de Krav Maga. Es también el autor de Windows Server 2003 Active Directory Design and Implementation de Packt Publishing.


 Administraci&#243;n: Inventarios de clientes avanzados con SMS
Administración Wes Dobry

Inventarios de clientes avanzados con SMS
Resumen:
  • Uso del Agente de inventario de hardware de SMS 2003
  • Expansión de inventarios con archivos MIF
  • Archivos MOF dinámicos frente a estáticos
Descargar el código de este artículo: DobrySMSInventory2007_04.exe (152KB)

Siempre llega un momento en la vida de todo administrador en el que su jefe le pide alguna información que no se puede recopilar sin cantidades arduas del trabajo. Pero se imagina que es un administrador proactivo
que ya ha recogido estos datos. Usted podría proporcionar a su jefe la información al momento, con lo que evitaría un tiempo de inactividad innecesario, evitaría horas extra y posiblemente ahorraría mucho dinero a la empresa. Usted podría ser un héroe.
Listo para usar, Microsoft ® Systems Management Server (SMS) 2003 recopila una enorme cantidad de información. Pero no lo recopila todo. Por ejemplo, de forma predeterminada SMS 2003 no realiza informes sobre grupos locales y sus miembros o sobre usuarios locales y sus atributos. La falta de esta información puede suponer un problema si, por ejemplo, un técnico pone Usuarios del dominio o, todavía peor, Todos en el grupo de administradores locales de cada sistema en los que ellos trabajan. O, por ejemplo, una empresa no tiene ninguna forma de saber qué archivo local y listas de exclusión de carpetas están en la solución de antivirus o anti software espía de su empresa. Esto puede no parecer un problema importante, hasta que alguien en TI se da cuenta de que los usuarios ponen c:\*.* en la lista de exclusiones.
Con la combinación apropiada de secuencias de comandos, el servicio Instrumental de administración de Windows® (WMI) y el conocimiento SMS, usted puede expandir los inventarios de SMS para que contengan casi cualquier información. Esto es posible a través del uso de archivos MIF (formato de información de administración) y MOF (formato de objeto de administración).

Realizar un inventario
Con SMS, las organizaciones pueden realizar implementaciones personalizadas, supervisar los objetivos y mantener los sistemas implementados. Mediante la expansión de inventarios SMS, se puede crear y administrar un objetivo mucho más personalizado. Por ejemplo, usted puede aplicar directivas de seguridad locales corporativas implementando sus directivas de seguridad en sistemas en los que un usuario ha modificado las directivas. También se pueden deshabilitar cuentas de usuario locales no aprobadas y quitar administradores locales superfluos.
Naturalmente, las organizaciones confían también en SMS para obtener información puntual y detallada acerca de sistemas cliente. La expansión de inventarios le permite crear informes que contengan información completamente personalizada que no está fácilmente disponible cuando sólo se confía en los inventarios predeterminados. Y la información puede ser muy granular. Por ejemplo, usted puede crear un informe que contenga el número de sistemas que tienen una clave del registro específica que señale a una granja de servidores determinada. Esto permitiría a los administradores calcular aproximadamente cuántos clientes se señalan para cada granja en un momento determinado. De igual forma, el equipo de seguridad puede comprobar qué sistemas de la red ejecutan un proceso específico que es conocido por ser un software espía.
El valor de los archivos MIF y MOF procede de la capacidad de introducir información desde casi cualquier fuente con su correspondiente traducción. Siempre que la información esté basada en texto, la información puede manipularse y colocarse en WMI con un archivo MOF, o recogerse en forma de archivo MIF y enviarse en el siguiente ciclo de inventario de hardware. La implementación de una expansión del inventario requiere conocimientos de VBScript o JScript®, así como saber qué se va a recopilar. Teniendo en cuenta que se puede recopilar casi todo, este conocimiento necesario puede abarcar desde WMI a conocimientos avanzados de SQL. Por supuesto, la comprensión de SQL es obligatoria independientemente del tipo de información que recopile, ya que necesitará este conocimiento cuando realice informes de los datos recogidos.

Cómo funcionan los inventarios
SMS contiene dos tipos de procesos de inventario: hardware y software. Los inventarios de software sólo contienen información acerca de archivos, por ejemplo, dónde están ubicados, de qué versiones son, su tamaño y otros atributos de archivo. Sin embargo, el proceso de inventario de software le permite también recopilar archivos y almacenarlos en el servidor del sitio.
La expansión de los inventarios de hardware se realiza fácilmente ya que estos inventarios contienen la matriz más grande de información acerca de un sistema. La información de los inventarios de hardware proviene principalmente de WMI, del Registro y del sistema BIOS.
Los inventarios de hardware se recopilan en una programación, que se configura en las opciones del sitio de Agente de Inventario de hardware en SMS 2003. Las recopilaciones pueden configurarse con tanta frecuencia como una vez cada minuto o de forma tan poco frecuente como una vez cada varios meses. Normalmente, se quiere encontrar un equilibrio que recopile esta información a la mayor velocidad requerida por la administración pero sin recargar la red, los servidores del sitio, los puntos de administración o los clientes.
Cuando el Agente de inventario de hardware se instala por primera vez, compila el archivo sms_def.mof. Éste contiene toda la información que SMS recopila inicialmente. Cuando se compila este archivo, todos los espacios de nombres de SMS y las clases asociadas requeridas por el Agente de inventario de hardware se crean en WMI. La mayor parte de ellos se localizan en el espacio de nombres \\.\root\CIMv2\SMS. Después de la instalación, el Agente de inventario de hardware examina la mayoría de estas clases para construir la información que se envía después al punto de administración y finalmente a la base de datos del sitio.

Archivos MIF
Además de extraer información de estas clases de WMI, el Agente de inventario de hardware busca archivos MIF en las carpetas de recopilación NOIDMIF e IDMIF. Todos los archivos MIF que encuentra el agente en estas ubicaciones se procesan en el siguiente inventario de hardware.
Los archivos MIF ofrecen la manera más fácil de expandir el Inventario de hardware de SMS. Existen dos tipos de archivos MIF: NOIDMIF e IDMIF. Estos archivos son archivos estáticos, similares a XML, y pueden contener casi cualquier información que un usuario podría querer incluir en la base de datos de SMS. Pueden crearse por cualquier medio usado para crear archivos de texto ordinarios. Así, estos archivos pueden crearse con la mayoría de lenguajes de secuencias de comandos o, simplemente, de forma manual.
Normalmente, los archivos MIF se usan en situaciones en las que la información no está incluida ni en el Registro ni WMI o cuando es necesario escribir la información manualmente. Estos archivos se pueden crear, por ejemplo, cuando su equipo de implementación de hardware proporciona un nuevo sistema. El técnico de implementación puede desplazarse a una aplicación HTML del sistema e introducir toda la información de activos que se vaya a usar para actualizar una base de datos de administración de activos. Esa aplicación crea entonces dinámicamente un archivo NOIDMIF y permite al técnico descargar el archivo a la carpeta de la recopilación de archivos NOIDMIF. Este archivo NOIDMIF puede contener toda la información escrita por el técnico y se incorpora a la base de datos de SMS.
Los archivos NOIDMIF y IDMIF tienen pocas diferencias. Un archivo IDMIF contiene un encabezado único que proporciona la información de la arquitectura y un Id. exclusivo. Los archivos IDMIF se pueden usar para incorporar dispositivos que no sean de sistema a SMS como sus propias entidades. Por ejemplo, un script puede usarse para crear sistemas en SMS que sean realmente impresoras y escribir información acerca de ellas en la base de datos de SMS.
Los archivos NOIDMIF y IDMIF se almacenan en ubicaciones estándar, que se dictan por claves del registro. La mayor parte del tiempo, son %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF e ...\IDMIF, suponiendo que el agente de SMS se haya instalado en la ubicación predeterminada. Si el agente se ha instalado en una ubicación personalizada, los directorios MIF debe estar en %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF e ...\IDMIF. Pero si existe cualquier duda en cuanto a las ubicaciones de estos directorios, puede localizar las siguientes claves del Registro:
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
Los archivos MIF tienen siempre el mismo formato, con independencia de la información recogida. Si se observa el archivo MIF mostrado en la Figura 1, verá que el archivo comprende un solo componente que contiene múltiples grupos y un solo atributo en cada grupo. Se requieren todas las secciones, aunque no es necesario que tenga más de un grupo o entrada de atributo. Puede observarlo como si cada grupo del archivo MIF fuera una fila de los datos de la sección nombrada en el inventario de hardware y cada atributo del grupo una columna de esa fila.
Figure 1 Localadmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
El ejemplo LocalAdmin.vbs, que se muestra en la Figura 2, es un VBScript bastante sencillo. Consulta el directorio NOIDMIF, elimina el archivo MIF temporal si existiera, crea el archivo MIF temporal, escribe de forma recursiva en el archivo información recopilada a través de una consulta WMI sencilla, elimina el archivo MIF que existe en la carpeta de recopilación NOIDMIF y, finalmente, mueve el NOIDMIF temporal a la carpeta de recopilación NOIDMIF.
Figure 2 Localadmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
Mientras los archivos MIF ofrecen una manera fácil de expandir el Inventario de hardware de SMS, hay algunos problemas que deben tenerse en cuenta al usarlos. Los MIF se procesan en cada ciclo de inventario de hardware. Pero desde que estos archivos se crean, recopilan, analizan y, finalmente, se incluyen en un inventario, la aparición en el inventario de la información incluida en un MIF se puede retrasar hasta en un ciclo del inventario de hardware. Esto significa que si una empresa tiene ciclos de inventario de hardware de un día, los datos de la base de datos de su sitio podrían tener un retraso de dos días. Por lo tanto, debe tener especialmente en cuenta cuándo se anuncian los programas que crean los archivos MIF y cuándo se ejecuta el ciclo de inventario de hardware.
Por ejemplo, una empresa llamada Contoso tiene ciclos de inventario de un día que ejecutan a medianoche. El lunes a la 1:00 a.m., se ejecuta un VBScript, lo que crea un archivo NOIDMIF que contiene el resultado de un escáner de rootkit. Este resultado se recopila a medianoche y se elabora un informe para el punto de administración. El administrador de SMS de Contoso mira entonces la información el miércoles por la noche a eso de las 10:00 p.m. y descubre que la información tiene una antigüedad de 45 horas. Esto sucede porque el administrador de SMS no pensó atentamente cuándo anunciar el programa usado para crear el archivo NOIDMIF.

Archivos MOF
Los archivos MOF son más complicados que los archivos MIF. Y tienen una ventaja sobre los archivos MIF ya que introducen su información directamente en WMI y pasan a formar parte del proceso de recopilación de datos estándar del agente de inventario de hardware. De ese modo, puede que no tenga que anunciar un VBScript una y otra vez para obtener información, lo que ahorra tiempo y problemas. En su lugar, puede anunciar el MOF una vez por equipo y entonces se recopila.
Los archivos MOF también tienen la ventaja de que la información está tan actualizada como el resto de la información del inventario de hardware. Cada vez que el Agente de inventario de hardware realiza su ciclo, se consulta a las clases y proveedores detallados en el archivo MOF y la información se devuelve rápidamente. Cuándo se necesita información rápidamente, se puede ejecutar un paquete que contiene su archivo MOF y un VBScript, con lo que se inicia un inventario de hardware. La información que necesita se adquiere entonces en tan poco tiempo como un ciclo de directiva de programa anunciado.
Existen tres clasificaciones de archivos MOF: Archivos MOF para una clase WMI y espacio de nombres existentes, archivos MOF para una clase adicional con un proveedor de WMI existente y archivos MOF para una clase adicional que no tenga un proveedor de WMI.
Los archivos MOF contienen dos partes. La primera parte es la sección de la definición del espacio de nombres. Aquí es donde se identifica la información del proveedor de WMI. La segunda sección contiene los atributos de elaboración de informes de SMS. Esta sección informa al Agente de inventario de hardware sobre dónde buscar y procesar la información incluida en las clases WMI mencionadas. Puesto que los archivos MOF tratan directamente con WMI, recomiendo tomarse algún tiempo y examinar el Kit del Desarrollo de Software (SDK) de Microsoft WMI si usted planea trabajar con estos archivos (consulte go.microsoft.com/fwlink/?LinkID=83121 para obtener más información).
Cada una de las clasificaciones de archivos MOF mencionadas puede ser estática o dinámica. Por ejemplo, tendría un archivo MOF estático si el procedimiento de creación de la empresa compiló un archivo MOF que incluía información relativa a quién construyó el sistema, qué versión de servidores usaron, cuáles fueron las versiones iniciales, la fecha en la que se fabricó el equipo, etc. Esta información no requiere nunca actualización y, por lo tanto, la información se puede introducir directamente en el archivo MOF y compilarse en WMI mediante mofcomp.exe. Después de que esto suceda, es necesario expandir el área en la que el agente de inventario de hardware realiza la búsqueda agregando la información del grupo y la clase en el archivo sms_def.mof del servidor del sitio.
Un archivo MOF dinámico es similar a un archivo MOF estático excepto porque en vez de escribir información recopilada directamente en WMI, los datos se recopilan a través de un proveedor de WMI. Un proveedor de WMI es un complemento que permite a una aplicación o servicio introducir la información directamente en WMI. Este proveedor permite obtener el acceso dinámico a otras áreas de WMI y el sistema, tal como el Registro, las ubicaciones de archivo y la información de Windows Installer.
A la hora de trabajar con archivos MOF, la manera más fácil de mejorar el inventario de hardware es tener más información sobre el catálogo del inventario de la que ya existe en WMI. Esto se puede hacer extendiendo el sms_def.mof o activando clases de elaboración de informes adicionales que están deshabilitadas actualmente. El archivo sms_def.mof está ubicado en la carpeta \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv Todos los dispositivos de la empresa colocarán el nuevo sms_def.mof en su siguiente ciclo de directiva de equipo y empezarán a recopilar información y elaborar informes sobre la misma.
El siguiente en la lista, en términos de dificultad, es usar un proveedor de WMI existente pero crear una nueva clase. Un ejemplo de este método se muestra en la Figura 3. En este ejemplo, mediante el uso de un proveedor integrado del Registro, la clase CU_Desktop se crea con una propiedad dinámica que consulta HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper en el dispositivo local. Después de que este archivo MOF se compila en el cliente, la información incluida en SMS_Def_Extension.mof (consulte la Figura 4) necesita agregarse a sms_def.mof. El archivo contiene información relativa a si SMS debe realizar un informe sobre la misma, el nombre del grupo, el Id. de clase, qué clase de Agente de inventario de hardware debe mirar en WMI para encontrar la información sobre la que elaborar el informe y, finalmente, los valores reales.
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 Currentuserdesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
Los archivos MOF tienen también la capacidad de obtener acceso a información ofrecida por proveedores de WMI que no están incluidos en sistemas de forma predeterminada. Para usar estos proveedores, el proveedor de WMI se debe distribuir e instalar primero antes de que el archivo MOF se compile en el cliente y sms_def.mof extendido.

Conclusión
Los archivos MIF y MOF son herramientas eficaces para una recopilación de información rápida y sustancial. Estos formatos de archivo ofrecen el marco para introducir fácilmente información en la base de datos de SMS sin modificar directamente las tablas. Con suficiente imaginación, se pueden realizar inventarios e informes de casi todo. Lo que es aún mejor, se pueden evitar situaciones problemáticas, ya que los administradores pueden actuar de forma proactiva para recopilar información esencial.
El conocimiento de los archivos MIF y MOF requiere algún tiempo. Sin embargo, existen recursos útiles que pueden ayudarle a saber cómo usar estos archivos. Para empezar, consulte la documentación WMI y el SDK, así como la Guía de operaciones de Systems Management Server 2003. Si hace el esfuerzo de entender estos conceptos, lo que consiga de la elaboración de inventarios de SMS expandidos compensará con creces todo ese esfuerzo.

Wes Dobry se encuentra en Orlando, área de Florida donde trabaja como consultor y administrador de red para una gran empresa del sector sanitario. Póngase en contacto con él wesdobry@wesdobry.com.


 Administraci&#243;n: Implementaci&#243;n de actualizaciones de software personalizadas con SMS 2003 R2
Administración Steve Rachui

Implementación de actualizaciones de software personalizadas con SMS 2003 R2
Resumen:
  • Nuevas características de administración de actualizaciones de SMS 2003 R2
  • Herramienta de publicación de actualizaciones personalizadas
  • Herramienta de inventario para actualizaciones personalizadas

Cuando necesita implementar actualizaciones personalizadas para sus sistemas, por ejemplo para hardware especializado o aplicaciones de línea de negocio, no dispone de la ventaja de un proceso administrado y automatizado como el de las actualizaciones de Windows. Al menos no lo tenía hasta ahora. Actualmente, gracias a Systems Management
Server (SMS) 2003 R2, puede usar esas mismas características de actualización administrada para implementar sus propias actualizaciones personalizadas. SMS 2003 R2 incluye varias características nuevas, entre las que se incluye una actualización de Device Management Feature Pack, vínculos a Operating System Deployment (OSD) Feature Pack y muchas características que mejoran la supervisión de la seguridad. Este producto tiene una herramienta de detección para evaluación de la vulnerabilidad que es fundamental para conocer las posibilidades del sistema y las vulnerabilidades de la red como, por ejemplo, los puntos débiles de la configuración del sistema operativo, las contraseñas de usuario y las configuraciones de IIS y SQL Server™. También incluye una herramienta de inventario para actualizaciones personalizadas (ITCU) y una herramienta de publicación de actualizaciones personalizadas (CUPT). Estas son las dos herramientas en las que me centraré en este artículo para ayudarle a implementar sus propias actualizaciones personalizadas de un modo sencillo y eficaz.

Herramienta de publicación de actualizaciones personalizadas
Antes de instalar y usar SMS 2003 R2, la jerarquía, incluidos los clientes, se deben actualizar a SMS 2003 Service Pack 2 (SP2). Para usar la CUPT, es necesario actualizar Microsoft ® Management Console (MMC) 3.0. No es necesario instalar CUPT en el servidor del sitio SMS, pero se debe instalar, como mínimo, en Windows® XP, y se necesita SQL Server 2005 para hospedar su base de datos; se debe instalar SQL Server Express Edition si no está disponible SQL Server 2005. La CUPT es fundamental para introducir y administrar actualizaciones personalizadas en el sistema SMS y también tiene características para probar los catálogos creados antes de su publicación en SMS.
Las actualizaciones personalizadas pueden ser de dos clases: actualizaciones proporcionadas por otros proveedores para el software que crean y actualizaciones creadas internamente exclusivas para un entorno determinado. CUPT es una herramienta capaz de administrar los dos tipos. Es más fácil usar actualizaciones personalizadas suministradas por terceros, de modo que comenzaremos por ellas. En el momento de escribir este artículo, hay tres empresas que crean catálogos de actualizaciones que se pueden usar para buscar y distribuir revisiones apropiadas en SMS: Adobe, 1e y Citrix. Para ver las empresas que participan, seleccione los catálogos de socios de actualizaciones personalizadas, como se muestra en la Figura 1.
Figura 1 CUPT en acción
Figura 1 CUPT en acción
Para usar las actualizaciones suministradas por los socios sólo es necesario descargar los catálogos y agregarlos a SMS. En primer lugar, descargue las actualizaciones que necesite y, a continuación, elija la opción del menú Acción para importarlas. Un asistente le preguntará la ubicación de los archivos .cab que acaba de descargar. Una vez que haya completado el asistente, las nuevas actualizaciones se podrán ver en la CUPT para, posteriormente, configurarse y publicarse en el servidor del sitio SMS. Sin embargo, debe tener en cuenta que es necesario marcar cada actualización para publicarla. Si una actualización no está marcada, no se incluirá cuando se realice la solicitud de publicación. Esto se puede hacer de forma global tal y cómo se muestra en la Figura 2. Observe que la columna del extremo de la derecha debe tener habilitada la marca para poder publicar la actualización.
Figura 2 Configuración de la marca de publicación
Figura 2 Configuración de la marca de publicación
Si es necesario, puede personalizar aún más cada actualización descargada. Para ello, sólo es necesario seleccionar la actualización y elegir Editar. Sin embargo, debe tener cuidado al personalizar una actualización, ya que una configuración incorrecta puede generar resultados inesperados e insatisfactorios.
Después de marcar las actualizaciones, llega el momento de publicarlas. Para ello, puede publicar en un archivo .cab externo y usarlo más adelante o sincronizar actualizaciones seleccionadas con la base de datos del sitio SMS para uso inmediato. Para llevar a cabo la sincronización con la base de datos del sitio SMS, es necesario proporcionar información de configuración como, por ejemplo, el nombre del servidor del sitio y la ruta de origen del paquete (consulte la Figura 3).
Figura 3 Información de sincronización
Figura 3 Información de sincronización
Para encontrar esta pantalla, resalte el nodo de actualizaciones personalizadas y, a continuación, elija */*Configuración en el menú */*Acción. Después de facilitar un nombre de servidor del sitio accesible y la ruta que señala el directorio de origen para la herramienta de inventario para actualizaciones personalizadas, se actualizarán el código del sitio y el estado.
Ahora, con las opciones de sincronización configuradas, la CUPT estará preparada para sincronizarse con el servidor del sitio SMS. Para realizar la sincronización, seleccione la opción de actualizaciones de publicación en el menú */*Acción. De este modo, se iniciará el asistente de publicación. Para publicar las actualizaciones en la base de datos SMS para uso inmediato, asegúrese de que está seleccionada la opción para sincronización con la base de datos del sitio de Systems Management Server. Afortunadamente, este paso tiene alguna ayuda visual: esta opción aparecerá atenuada si no se ha configurado la sincronización.
Una vez que haya finalizado el asistente, estarán disponibles las actualizaciones personalizadas para acción en la consola de administración de SMS. Al iniciar el asistente para distribución de actualizaciones de software, se proporciona una opción para trabajar con cualquier actualización personalizada disponible.
Una vez que hemos visto el proceso para aprovechar y usar actualizaciones creadas por proveedores para productos de terceros, ¿qué ocurre con las actualizaciones personalizadas para software suministrado por proveedores cuando no hay disponibles actualizaciones empaquetadas previamente? Aquí es donde CUPT destaca realmente. Con CUPT, puede crear actualizaciones personalizadas completadas con criterios definidos para cubrir casi cualquier situación.
La creación de una actualización personalizada no es difícil pero requiere que el administrador sepa cómo aplicar una revisión del software, qué criterios usar para determinar si una revisión es aplicable, y qué reglas de definición se deben usar para enfocar la actualización. Las reglas de definición se establecen de forma independiente al proceso de creación de la actualización. Para verlas, seleccione la opción Administrar reglas del menú Acción.
La creación de actualizaciones personalizadas se inicia con la selección de la opción Crear actualización en el menú Acción, que inicia un asistente en el que se proporcionan los detalles de la actualización personalizada. El análisis detallado de la creación de una actualización personalizada está fuera del ámbito de este artículo pero resulta instructivo seleccionar propiedades en una de las actualizaciones personalizadas de terceros importada para saber lo que se requiere en cada campo al crear su propia actualización. Las propiedades de una actualización de terceros configurada se muestran en la Figura 4.
Figura 4 Propiedades de una actualización de terceros
Figura 4 Propiedades de una actualización de terceros
Mediante el proceso de creación de actualizaciones personalizadas, puede hacer algo más que actualizaciones; también puede configurar software para distribuirlo entre los sistemas cliente. Aunque esto funcionará, es importante tener en cuenta que no es un enfoque recomendado ni es el uso para el que está diseñada CUPT.

Herramienta de inventario para actualizaciones personalizadas
La ITCU es una nueva herramienta que funciona con catálogos de actualizaciones personalizadas. Al igual que ocurría con las herramientas de detección anterior, ITCU crea colecciones, paquetes y anuncios personalizados que se usan para implementar las herramientas de detección en los clientes SMS de la empresa. Al igual que ocurría con las herramientas de detección anteriores, ITCU recuperará el catálogo, en este caso el catálogo de actualizaciones personalizadas de un punto de distribución de SMS accesible, realizará la detección en función de los datos del catálogo, insertará los resultados de la detección en el instrumental de administración de Windows (WMI) y comunicará los resultados a través del inventario de hardware. La diferencia principal del proceso de detección es el catálogo que se usa.
La introducción de SMS 2003 R2 agrega una herramienta eficaz al arsenal de características de seguridad de SMS existente. Los administradores nunca han podido aprovechar antes la infraestructura SMS existente para aplicar revisiones a aplicaciones de terceros y actualizaciones. SMS R2 es una característica adicional muy útil para el administrador de revisiones.
De modo que ahora dispone de dos herramientas para controlar actualizaciones de software de orígenes distintos a Microsoft. La facilidad de uso y la comodidad que proporcionan CUPT e ITCU le asegurarán que sus actualizaciones personalizadas funcionen igual de bien que las actualizaciones de Windows que usa actualmente.
Recurso de administración de actualizaciones
  • TechNet: Difusión por web
  • de administración de actualizaciones: Demostración TI - SMS 2003 R2
  • Diez principios de la administración de revisiones de Microsoft

Steve Rachui es */*Manageability Support Escalation Engineer del grupo de servicios de soporte técnico de Microsoft. Es compatible con SMS desde la versión 1.2. Puede ponerse en contacto con Steve en steverac@microsoft.com.


 Del editor: Puede que nos equivoquemos...
Del editor
Puede que nos equivoquemos...

UNA DE LAS PRINCIPALES DIFERENCIAS entre el material impreso e Internet es que una vez que algo se imprime, permanece para siempre. Si pone algo de información en Internet y necesita actualizarlo más adelante, sólo tiene que cambiar lo que haga falta. Nadie se dará cuenta de lo que ha pasado.
La información impresa es otra historia. Una vez que se envía algo a la imprenta, no hay marcha atrás. Se imprimen más de cien mil ejemplares y se imprima lo que se imprima, quedará en las bibliotecas para siempre. Además, el material impreso sigue una progresión natural, mes a mes, y uno sabe que en el último número se encontrarán las noticias y artículos más actuales.
En la actualidad, hacemos que la revista esté disponible en línea una vez que se ha publicado, lo que crea otro problema. Desde el punto de vista de un usuario que realiza una búsqueda en línea, todo el contenido de nuestro sitio web está ahí a la vez. ¿Cómo se puede saber si se está leyendo la información más reciente?
Para resolver este problema, hace unos años formulamos una directiva de correcciones que mejora nuestro producto impreso con la capacidad de llegar a los lectores en línea. En la página de correcciones de TechNet Magazine, verá que se comunican todos los cambios realizados en los artículos con posterioridad a su publicación. Se da una de cinco razones para la actualización de un artículo: técnica, editorial, nueva información, obsoleta y seguridad.
Por ejemplo, en el artículo "Techniques for Simplifying Desktop Image Creation", publicado en mayo de 2006, se mencionaba una herramienta denominada CNIC que todavía no estaba disponible. Cuándo CNIC estuvo disponible, agregamos una actualización a la página de correcciones y una actualización del editor al artículo publicado en línea. Si se hace clic en el vínculo de la actualización del editor se muestra directamente la nueva información.
Así, si bien cada número impreso de TechNet Magazine se reemplaza por uno nuevo todos los meses, nuestra directiva de correcciones garantiza que los artículos siguen siendo vigentes con el tiempo. JOSHUA TRUPIN

Mi agradecimiento a los siguientes expertos de Microsoft: Luis Botero, Derek Del Conte, John Doyle, David Feldman, Scott Hinsley, Jesper Johansson, Brian Mohr, Michael Murgolo, John Orefice, Mark Russinovich, Matt Steele, Fergus Stewart, Jason Stolarczyk, Jim Truher y Alan von Weltin.


 Toolbox: Nuevos productos para profesionales de TI
Toolbox
Nuevos productos para profesionales de TI
Greg Steen

Sincronización de archivos y directorios
Allway Sync
allwaysync.com

Sea cual sea el trabajo de TI que desempeñe, seguramente pasará mucho tiempo moviendo archivos y directorios de un lugar a otro, tanto desde el escritorio a una llave USB como entre servidores a través de la red. A menudo, es importante mantener esos directorios sincronizados para asegurarse de que no crea duplicados innecesarios y que trabaja con la versión más reciente de los archivos. A veces puede necesitar sincronizar archivos y directorios entre muchos equipos, como al implementar archivos con código HTML o XML estáticos en un conjunto de servidores web. Allway Sync de Usov Lab es una herramienta útil para realizar este tipo de tareas.
Allway Sync le ofrece verdadera sincronización en n direcciones, desde la réplica en una sola dirección de archivos y directorios a una opción bidireccional de varios directorios. La aplicación no sólo le permite mantener sincronizados unidades de disco locales y recursos en red, sino que también admite la sincronización automática a dispositivos extraíbles, como llaves USB y unidades de disco ópticas regrabables. Puede hacer que Allway Sync se inicie automáticamente al conectar el dispositivo al equipo.
Otras opciones de inicio automático para la sincronización incluyen iniciarse cuando se detectan cambios en archivos, cuando inicia o cierra una sesión, cuando se inicia Allway Sync y en intervalos de tiempo especificados. Incluso puede ligar la sincronización con una tarea programada a través de la GUI de la aplicación.
Sincronice archivos y carpetas con Allway Sync
Sincronice archivos y carpetas con Allway Sync
En la base de datos local de la aplicación se realiza el seguimiento de todas las modificaciones y eliminaciones de archivos, y Allway Sync ofrece muchas opciones para crear versiones de los archivos modificados y eliminar los archivos que tengan conflictos, incluida la opción de quitar elementos de forma permanente, moverlos a la Papelera de reciclaje o moverlos a una carpeta especificada.
Para cada trabajo, puede especificar varios filtros de inclusión o exclusión para obtener los archivos que necesita y omitir los que no necesita. Puede personalizar las acciones que desea que realice Allway Sync cuando detecte advertencias o errores y configurar una acción diferente para cada tipo de advertencia o error. Por ejemplo, puede elegir volver a intentar automáticamente una copia en caso de error y configurar no sólo el número de reintentos automáticos, sino también el retardo temporal entre reintentos para adaptarse a cualquier latencia de la red o problemas de conectividad a corto plazo.
Puede configurar el nivel de contenido de la característica de registro de la aplicación para asegurarse de recibir la máxima información acerca de sus trabajos. La configuración de la aplicación se puede importar y exportar a través de XML, de modo que resulta sencillo realizar copias de seguridad de la configuración o transferirla a otro equipo. Además, se incluye una funcionalidad divertida para las personas curiosas: la aplicación también dispone de una ventana de estadísticas de uso sencilla (a la que se puede obtener acceso mediante el menú Ayuda). Esta útil herramienta permite que la sincronización de los archivos sea rapidísima y es una verdadera oportunidad.
Precio: Gratuita para uso personal. 29,99 dólares para uso comercial.

Cree mapas de la red y supervísela
LANState Pro
10-strike.com/lanstate

El acceso rápido al estado y la disponibilidad de los recursos de la red es esencial en un entorno proactivo de operaciones de TI. Cuándo surge un problema, necesita conocerlo antes que nadie. La útil aplicación para crear mapas y supervisar redes LANState de 10-Strike Software puede ayudarle con capacidades de visualización rápida y administración de LAN para redes basadas en Windows®.
Al iniciar la aplicación para supervisar la red, puede seleccionar el Asistente para mapas de red (Network Mapping Wizard), que le permite examinar el Entorno de red o un intervalo de direcciones IP para detectar hosts aplicables. Si lo prefiere, puede agregar los hosts manualmente. Una vez creado el mapa de la red, LANState inicia automáticamente las comprobaciones de estado configuradas por el usuario, como, por ejemplo, una comprobación de puertos TCP o comprobación de ping de ICMP. Los hosts que responden están codificados con colores, mientras que los que no responden aparecen atenuados en gris. En este punto, puede organizar el mapa según las agrupaciones lógicas adecuadas para su configuración y cambiar los elementos visuales que desee, así como agregar descripciones y elementos similares.
Cree agrupaciones de red lógicas con LANState Pro
Cree agrupaciones de red lógicas con LANState Pro
Las herramientas de dibujo y edición son un poco difíciles de usar, pero una vez completado el mapa, puede guardarlo en un archivo y no tendrá que volver a crearlo. Además de las comprobaciones de puertos TCP y ping de ICMP, puede configurar LANState Pro para que compruebe la existencia de una carpeta o archivo, el tamaño de un archivo o el espacio disponible en disco en un host remoto según un intervalo y tiempo de espera configurables. Al hacer clic con el botón secundario en un host aparece un menú contextual que le permite obtener más información del sistema del host remoto, así como realizar una ruta de seguimiento, enviar un ping, realizar una comprobación predeterminada o enviar un mensaje de red.
La vista de la información del sistema le muestra todo tipo de datos, desde direcciones NIC MAC y direcciones IP enlazadas, hasta recursos compartidos de red, servicios y cuentas locales. La mayor parte de la información del sistema operativo requiere los permisos apropiados y puertos abiertos en el sistema remoto, pero puede obtener bastantes datos de buena calidad desde las llamadas RPC. Además, si dispone de los permisos adecuados, también puede enviar señales remotas de encendido y apagado a los hosts remotos.
Precio: 249,95 dólares por una licencia de usuario.

Scripting de línea de comandos
Reseña de libro
www.syngress.com

Los asistentes interactivos y las GUI de configuración pueden simplificar sobremanera las tareas complejas. Pero si es profesional de TI, estas interfaces pueden ralentizar su trabajo y no siempre proporcionan la granularidad o el control necesarios para la tarea en cuestión. Afortunadamente, ese nivel del control casi siempre está disponible mediante la interfaz de línea de comandos (CLI). Si se familiariza con las herramientas incluidas en Windows y aprende a personalizar el símbolo del sistema para optimizar las tareas administrativas, podrá ahorrar tiempo, aumentar la eficacia y tener un control más preciso. El libro de Pawan K. Bhardwaj How to Cheat at Windows System Administration Using Command Line Scripts (Syngress Publishing, 2006) le puede ayudar a dominar las utilidades de CLI y el sistema operativo.
Este libro ofrece información sobre la personalización del shell de comandos, el uso de archivos por lotes para tareas de automatización y procesamiento por lotes y la administración mediante CLI de las tareas programadas. Una vez que domina esas secciones, el libro presenta las utilidades incluidas en el sistema operativo Windows que le ayudan a administrar discos, archivos y directorios. También obtendrá una interesante introducción a los comandos de los Servicios de directorio, como DSQuery y DSMod, los cuales, combinados con las capacidades de procesamiento por lotes incluidas en los capítulos anteriores, pueden ahorrar mucho tiempo a la hora de administrar estructuras de directorios de gran tamaño.
También obtendrá información acerca de los comandos de las funciones de red de Windows disponibles (desde Netstat hasta Pathping) y verá una introducción a las herramientas de conexión remota, como TFTP, RSH, y RCP. De nuevo, si combina estas herramientas con las capacidades relativas a la automatización y las tareas programadas incluidas en la primera sección del libro, podrá aumentar la productividad. En resumen, aunque no se trata de una referencia completa acerca de las utilidades de Windows, el libro de Bhardwaj es una útil adición a su estante de la referencia.
Precio: 39,95 dólares, venta directa.

Pruebas de confiabilidad del hardware
BurnInTest
passmark.com/products/bit.htm

Tanto si participa en la producción de PC personalizados, si realiza actualizaciones de componentes de hardware para su base de clientes o si simplemente crea una nueva plataforma de escritorio con gran capacidad de administración, resulta fundamental garantizar que los componentes nuevos tendrán un rendimiento confiable antes de entregarlos a los usuarios. BurnInTest de PassMark Software se ocupa de garantizar esta confiabilidad mediante la ejecución de distintas pruebas de esfuerzo en los componentes especificados para garantizar que no tendrán errores al entregarlos.
Al igual que con todas pruebas de desgaste de software, la aplicación trata de "ejercitar" el hardware, poniendo el esfuerzo en componentes del sistema seleccionados con el fin de simular un ciclo largo de actividad en un período de tiempo corto. La idea es destapar cualquier error que se encuentre bajo la superficie antes de poner en servicio un sistema o dispositivo. BurnInTest permite realizar pruebas en todo tipo de componentes, desde CPU y tarjetas gráficas hasta unidades de disco duro y grabadoras de CD.
La aplicación es muy fácil de usar y configurar, y le permite cambiar los ciclos de esfuerzo y las preferencias para cada prueba de unidad componente en una configuración concreta. Una vez definida la configuración de las pruebas, puede guardar las preferencias para su uso posterior, acelerando la próxima repetición de las pruebas, que quizás deba realizar transcurridos unos meses.
Cada una de las pruebas tiene un ciclo de esfuerzo configurable, por lo que puede establecer un valor de carga de 1 a 100 para cada componente probado. Por ejemplo, puede probar las operaciones matemáticas de una CPU con una carga del 75% a la vez que prueba simultáneamente un 90% de carga en la memoria de sistema. También puede indicar a BurnInTest que se detenga una vez transcurrido un número de terminado de minutos o ciclos operativos.
La aplicación permite probar hasta 20 unidades de disco duro, unidades de disquete y unidades de disco ópticas simultáneamente, de modo que puede realizar prueba por lotes en las unidades de disco antes de desplegarlas en el entorno cliente. Esto puede representar un gran ahorro de tiempo al actualizar un componente del sistema, ya que puede probar todos los componentes nuevos a la vez, sin tener que probar cada sistema individualmente. También resulta interesante que el programa disponga de funciones para realizar comprobaciones de los parámetros de SMART.
La versión Professional Edition de la aplicación es compatible con diversas pruebas de bucle invertido para puertos USB 2.0, puertos paralelos y puertos serie. (Los dispositivos de bucle invertido de hardware están disponibles para su compra en PassMark). Esta versión de BurnInTest puede ejecutarse desde una unidad de CD o llave USB, lo cual aumenta la credibilidad de las pruebas realizadas al reducir la repercusión de la aplicación en el sistema probado.
Precio: 49 dólares Professional Edition; 24 dólares Standard Edition.

Greg Steen es un profesional, emprendedor y entusiasta de la tecnología. Siempre está buscando nuevas herramientas y métodos para ayudar a simplificar las operaciones y el desarrollo para los profesionales de TI.


 SQL Q&amp;A: Reconstrucci&#243;n de &#237;ndices, longitud de colas de discos y otros aspectos
SQL Q&A
Reconstrucción de índices, longitud de colas de discos y otros aspectos
Editado por Nancy Michell

P ¿Cómo se vuelven a generar los índices de SQL Server? Necesito saber por qué DBCC DBREINDEX consume todo mi espacio de disco y por qué no se libera espacio cuando el comando produce un error. El tamaño de mi base de datos es de 90 GB y la tabla más grande tiene 70 GB.
Cuándo ejecuto DBCC DBREINDEX, dejando el 10 por ciento de espacio libre, consume todo el espacio de disco disponible y el comando produce un error. El archivo de base de datos tiene inicialmente 90 GB, pero cuando se produce el error del comando DBCC, el archivo pasa a tener 160 GB y los 70 GB adicionales no se liberan. Tengo que reducir manualmente la base de datos varias veces para recuperar ese espacio.
Si el comando funciona, el tamaño del archivo de base de datos es también de 160 GB, pero el espacio se libera automáticamente unas horas después, mediante la autoreducción. ¿Sería aceptable hacer una desfragmentación en vez de ejecutar el comando DBREINDEX para consumir menos espacio? No tengo índices agrupados y uso el modo de recuperación sencilla.
R En el nivel más sencillo, los índices se vuelven a generar mediante una nueva copia del índice y, a continuación, eliminando la vieja. Esto significa que, básicamente, hay dos copias del índice durante un breve periodo de tiempo. La creación del índice nuevo podría requerir tanto espacio de archivo de base de datos como el índice original, y si la regeneración requiere una operación de ordenación, se necesita un 20 por ciento adicional del tamaño del índice para la ordenación.
Es decir, en el peor de los casos la regeneración de un índice requiere 1,2 veces el espacio del índice original. Si el archivo de base de datos no tiene suficiente espacio libre, el archivo tendrá que aumentar de tamaño al avanzar la operación. Es posible que si no está habilitado el crecimiento automático o no hay espacio suficiente en el volumen de disco, puede no haber suficiente espacio libre disponible y se producirá un error de la operación de regeneración.
Tanto si se produce un error de la operación como si no, el espacio adicional asignado al archivo de base de datos no se libera cuando finaliza la operación de regeneración. Se asume que el espacio se usará para operaciones normales de la base de datos.
Es casi seguro que la ejecución de la reducción (manual o automática) causará la fragmentación del índice, como consecuencia de la forma de trabajar del algoritmo. Para obtener más información, consulte Motor de Almacenamiento de SQL Server. La autoreducción puede perjudicar especialmente al rendimiento si la base de datos necesita espacio libre para operaciones normales, porque se podría iniciar un ciclo de crecimiento automático-autoreducción-crecimiento automático-autoreducción desastroso para la fragmentación y el rendimiento.
El uso de DBCC INDEXDEFRAG (o de ALTER INDEX ... REORGANIZE en SQL Server™ 2005) tiene la ventaja de que prácticamente no utiliza espacio adicional de archivo de base de datos, aunque puede tardar más y generar muchos más registros de transacciones que la reconstrucción de un índice. Para DBCC INDEXDEFRAG se crea siempre un registro completo, independientemente del modo de recuperación que se use, mientras que en el modo de recuperación simple la reconstrucción del índice se registrará de forma masiva. Cada método tienen sus ventajas e inconvenientes, que se explican pormenorizadamente en el artículo Procedimientos recomendados para la desfragmentación del índice de SQL Server.
Antes de tomar la decisión de cómo corregir la fragmentación, debe decidir si en realidad debe hacerlo. Dependiendo del tipo de operaciones para las que se use el índice, la fragmentación puede no tener efecto alguno en el rendimiento y, por lo tanto, corregirla no es más que una pérdida de recursos. El artículo ofrece información muy detallada.
Conclusión: asegúrese de que elige el método más indicado para eliminar la fragmentación en su entorno y que la eliminación contribuye a mejorar el rendimiento de las consultas.

P He configurado la creación de reflejos de base de datos correctamente entre dos instancias de SQL Server 2005. Mi aplicación se conecta a SQL Server mediante un inicio de sesión de SQL Server y se ha creado mediante ADO y el cliente nativo de SQL. La cadena de conexión y la configuración de la conexión especifican la información correcta, incluido el asociado de conmutación por error adecuado. También he creado todos los mismos inicios de sesión del servidor principal en el servidor reflejado. Al probar un error de la base de datos, el servidor reflejado asume la función de principal y todo parece ser correcto en la instancia de SQL Server. (Puedo incluso conectarme al servidor reflejado con el inicio de sesión de Windows®). Sin embargo, al tratar de volver a conectar la aplicación se muestra un error similar al siguiente:
Cannot open database "<db name>" requested by the login. The login failed.
Parece que el inicio de sesión no está asociado con un usuario en la nueva base de datos principal (que era inicialmente la reflejada). Ejecuto sp_change_users_login para sincronizar los usuarios e inicios de sesión de la base de datos, y obtengo un mensaje que dice que se han corregido varios usuarios huérfanos. A continuación, la aplicación se vuelve a conectar correctamente al nuevo servidor principal. He intentado realizar varias conmutaciones por error, y siempre se produce el mismo comportamiento: se pierde la asociación entre el inicio de sesión y el usuario.
¿Hay alguna manera de configurar la creación de reflejos para que no se produzca este problema?
R Sí. El problema se debe a que los identificadores de seguridad (SID) de los inicios de sesión de SQL Server de cada servidor no coinciden, aunque los nombres de los inicios de sesión sean los mismos. Este problema no existe con los inicios de sesión de Windows/dominio usuario/grupo, porque los SID para estos inicios de sesión se crean en función del SID de dominio del usuario/grupo y, por ello, será el mismo para el mismo usuario/grupo concreto, independientemente del SQL Server al que se agregue.
Para que el paso de sincronización de sp_change_users_login no sea necesario, tendrá que crear los inicios de sesión de SQL Server en el servidor reflejado no sólo con el mismo nombre, si no también con el mismo SID que el del servidor principal. Debe hacerlo mediante la especificación de SID de la instrucción CREATE LOGIN al crear los inicios de sesión en el servidor reflejado, de la siguiente manera:
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
Puede recuperar el SID de cada inicio de sesión del servidor principal consultando la vista de catálogo sys.sql_logins. En la Figura 1 se muestra el ejemplo de una consulta que generará una instrucción CREATE LOGIN real para cada inicio de sesión de SQL Server/Windows en un servidor determinado.
Figure 1 Generar la instrucción CREATE LOGIN (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

P ¿Cuál debe ser la longitud media de la cola de disco? Por ejemplo, si tengo 20 cilindros de discos físicos independientes en una Red de área de almacenamiento (SAN) con una configuración RAID 01, ¿cómo puedo calcular la longitud media de la cola de disco? ¿Es Longitud media de cola de disco/20 o Longitud media de cola de disco/2?
R En primer lugar, debe observar la latencia de disco antes de malgastar tiempo en la longitud media de la cola de disco en un entorno SAN. En realidad, depende de lo que trate de averiguar. Verá por qué en un momento.
La explicación de este contador (de Perfmon) es "La longitud media de la cola de disco es el promedio de solicitudes de lectura y escritura puestas en la cola del disco seleccionado durante el intervalo de tiempo de muestra". Es un contador de disco físico o de disco lógico, de modo que el número que obtenga dependerá de cómo se presenta el almacenamiento subyacente al sistema operativo.
Vamos a considerar su caso. Tiene 20 cilindros de discos en una configuración RAID 01, lo que significa que están seccionados y reflejados (o reflejados y seccionados, según se lea 01 o 10). El aspecto clave de la matriz de almacenamiento es que hay 10 cilindros de discos en el conjunto seccionado.
Lo que sucede es que carezco de información esencial, como el tamaño de las secciones, el tamaño de escritura, y qué clase de E/S emite (lectura, escritura, secuencial o aleatoria).
Si no tenemos en cuenta esta información por ahora, si la longitud media de la cola de disco es 10, el sistema operativo ha puesto en cola 10 E/S en la matriz de discos. Teóricamente, podría haber una operación de E/S en cada uno de los 10 conjuntos reflejados de la sección, o podría haber habido 10 E/S en un solo disco. No hay manera de saber cuál de las dos cosas sucedió.
Y aquí es donde se necesita la información que falta. Asumamos que el tamaño de la sección es 64 KB, el tamaño de escritura es 8 KB, y va a realizar todo un grupo de escrituras en secuencia. Ésta es una situación típica de la actividad de almacenamiento de SQL Server. En este caso, es bastante probable que ocho de las diez E/S fueran al primer disco, y las otras dos fueran al disco siguiente. Así, si desea calcular la longitud de la cola de disco por disco en esta situación, es 8 para el primer disco, 2 para el segundo disco, y 0 para los demás ocho discos de la matriz.
A continuación, vamos a cambiar la situación a un tamaño teórico de la sección de 8 KB y un tamaño del bloque de escritura de 64 KB, y vamos a mantener la longitud de la cola de disco en 10. En este caso, cada bloque de 64 KB se distribuye en 8 discos, de modo que una E/S se escribe en 8 discos y las 10 E/S de la cola se distribuyen en 80 escrituras de disco entre los 10 discos de la matriz. Si desea calcular la longitud de la cola de disco por cada disco de la matriz, será 8 para cada uno de ellos.
Seamos realistas y agreguemos otro nivel de incertidumbre a esta situación. En la mayoría de los casos, el almacenamiento de SAN se conectará al servidor mediante uno o varios HBA en el servidor, varias fibras para conectar el HBA al SAN, varios puertos en el cliente de SAN, y quizás un tipo de conmutador de fibra entre el servidor y la red SAN. A continuación, nos centramos en la arquitectura interna de los buses del interior de SAN, y en cómo se conectan los discos a los puertos del cliente de SAN.
Cualquier puesta en cola notificada en Perfmon puede ser un síntoma de una latencia alta o una cola larga en cualquiera de los puntos entre el lugar en que el sistema operativo mide la longitud de la cola de disco y la superficie de los discos. Por eso, debe fijarse en la latencia y basar sus decisiones en ese contador en lugar de en la longitud media de la cola de disco.

P Uso la réplica transaccional y sé que se han cambiado muchas filas manualmente en una tabla del suscriptor, así que recibo errores cuando el publicador trata de actualizar una fila que ya no existe en el suscriptor.
Necesito saber si hay alguna manera mediante la réplica para reinicializar sólo esta tabla desde el publicador en lugar de volver a solicitar una instantánea completa. He estudiado la función tablediff, que da la impresión que hará lo que deseo, pero desearía saber cómo interactúa con la réplica.
Por ejemplo, ¿toma tablediff una instantánea en el tiempo de la tabla del publicador y la compara con la equivalente de suscripción? ¿Debo detener la réplica para usar la función tablediff y garantizar la coherencia de los datos? ¿Hay algo más que deba saber?
R En primer lugar, tablediff no toma una instantánea literal ni de la tabla del publicador ni del suscriptor. En esta situación concreta, hay un par de opciones que se podrían considerar.
La primera sería detener temporalmente la réplica y ejecutar la utilidad. Si le preocupa que los usuarios traten de modificar los datos, puede usar los parámetros -sourcelocked y -destinationlocked, que establecerán un bloqueo exclusivo en las dos tablas mientras se ejecuta la utilidad. Si esto no es posible, otra opción sería observar los parámetros -rc y -ri mientras se ejecuta la réplica. Así, tablediff se ejecutará una vez y, a continuación, se ejecutará consecutivamente en los errores detectados, eliminando los que pudieran deberse a demoras de propagación de la réplica. Tenga en cuenta, sin embargo, que con esta opción, dependiendo de la demora de la réplica, podría no detectar todas las filas que se han cambiado en el suscriptor.

Mis agradecimientos a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Sunil Agarwal, Chad Boyd, David Browne, Gilles Comeau, Emmanuel Dreux, Amanda Foote, Matt Hollingsworth, Paul Mestemaker, Uttam Parui, Paul Randal, Dennis Tighe y Steven Wort.


 Utility Spotlight: Ejecuciones autom&#225;ticas
Utility Spotlight
Ejecuciones automáticas
Lance Whitney
Descargar el código de este artículo: Ejecuciones automáticas (490KB)

El PC habitual en que se ejecuta Windows® carga una serie de elementos en el inicio, por ejemplo archivos, controladores, tareas y servicios. En algún momento, es probable que necesite ver y, quizás, deshabilitar ciertos elementos del inicio: para solucionar un conflicto del inicio, rastrear código malintencionado en la secuencia del inicio automático, reducir el tiempo de inicio de Windows, o liberar memoria y recursos del sistema.
La Utilidad de configuración del sistema (msconfig.exe) le permite ver y deshabilitar varios archivos y servicios del inicio, pero pasa por alto muchos otros: barras de herramientas, objetos del auxiliar del explorador, extensiones de shell del Explorador de Windows. Además, msconfig no comunica mucha información sobre estos elementos. Para conocer y administrar mejor todo lo que se carga en el inicio, eche un vistazo a Ejecuciones automáticas de Sysinternals.
Ejecuciones automáticas, escrito por Mark Russinovich y Bryce Cogswell, es una utilidad gratuita que muestra todos los elementos del inicio (lo que se conoce como una imagen) de un equipo basado en Windows. Puede ver todas imágenes almacenadas en las carpetas de inicio, el Registro y otras áreas donde pueden estar ocultas (consulte la Figura 1).
Figura 1 Ver los elementos de inicio con Ejecuciones automáticas
Figura 1 Ver los elementos de inicio con Ejecuciones automáticas
Ejecuciones automáticas le muestra el nombre y la ubicación de cada imagen. Para los archivos se muestra la ruta de acceso de directorio; para las entradas del Registro se muestra la clave exacta. Ejecuciones automáticas proporciona también el nombre del publicador y una breve descripción basada en los datos de la versión de elemento. Si hace doble clic en una entrada irá a su directorio o clave del Registro; si hace clic con el botón secundario, se abre un menú emergente con más opciones, como un comando de Propiedades que muestra la ventana Propiedades de archivo estándar, con información completa de la versión. La opción para incluir las ubicaciones vacías muestra todas las áreas de inicio del equipo, tanto si tienen entradas actualmente como si no. Puede seleccionar también otras cuentas de usuario del equipo para consultar sus entornos de inicio.
Puede comprobar la firma digital de una entrada mediante el comando de comprobación, que consulta sitios web con listas de revocación de certificados (CRL) para determinar si una imagen está firmada digitalmente y si la firma es válida. Otra opción es la de esconder las entradas firmadas de Microsoft, que excluye las entradas ya firmadas por Microsoft y le permite centrarse en las imágenes de otros fabricantes.
La lista completa de los elementos de inicio se puede exportar a un archivo de texto, lo que resulta muy útil para deshabilitar un artículo si se desea obtener una instantánea del entorno de inicio antes de ajustarlo. A continuación, puede comparar el archivo de texto exportado con la configuración de inicio revisada para ver los cambios.
Éstas son sólo algunas de las categorías de inicio de las que se ocupa Ejecuciones automáticas:
Inicio de sesión incluye el usuario y todas carpetas de inicio de los usuarios, y las claves de ejecución del Registro.
Explorador incluye una lista de extensiones de shell del Explorador, las barras de herramientas y las ejecuciones activas de instalación.
Internet Explorer incluye los objetos auxiliares del explorador, y las barras de herramientas y extensiones de Internet Explorer®.
Proveedores de LSA incluye la autenticación de la autoridad de seguridad local, notificación y paquetes de seguridad.
En Ejecuciones automáticas, puede eliminar permanentemente un elemento de inicio o sólo deshabilitarlo. Una opción de búsqueda en línea le ayuda a determinar qué artículos puede deshabilitar sin riesgos. Esta opción ejecuta una búsqueda de Internet de páginas web que describan un elemento o su categoría y le indica si se debe eliminar del inicio. Al deshabilitar un elemento, Ejecuciones automáticas lo desplaza a una ubicación de copia de seguridad en el Registro o en el disco duro.
Ejecuciones automáticas funciona en todas versiones de Windows, incluidas la edición de 64 bits de Windows XP y la edición de 64 bits de Windows Server® 2003. Obtenga una copia en microsoft.com/technet/technetmag/code07.aspx.

Lance Whitneyes consultor, instructor y escritor técnico de TI. Ha pasado cientos y cientos de horas trabajando con estaciones de trabajo y servidores de Windows. Periodista en sus inicios, entró en el mundo de TI hace 15 años.


 The Cable Guy: Configuraci&#243;n de la Directiva de grupo inal&#225;mbrica para Windows Vista
The Cable Guy
Configuración de la Directiva de grupo inalámbrica para Windows Vista
Joseph Davies
Esta columna incluye información previa a su publicación acerca de "Longhorn" de Windows Server que está sujeta a cambios.

Como administrador, su trabajo sería probablemente un poco más fácil si pudiera configurar y distribuir centralmente la configuración de red inalámbrica a todos los equipos en su red de Active Directory. Afortunadamente, Windows es compatible con una extensión especial de directiva de grupo para la configuración de equipos que le permite hacer exactamente eso. Se
denomina la extensión Directivas de red inalámbrica (IEEE 802.11), compatible con equipos que ejecutan Windows Vista™, Windows® XP, Windows Server® 2003 y la siguiente versión de Windows Server, denominada "Longhorn".
A continuación, se describe su funcionamiento. Al unirse al dominio o al iniciarse (y en una base progresiva después de eso), estos sistemas operativos descargan automáticamente la configuración inalámbrica en esta extensión Directiva de grupo y la aplican. Puede configurar las directivas inalámbricas para un objeto de directiva de grupo basado en dominio desde el nodo siguiente en el complemento Editor de objetos de directiva de grupo: Configuración del equipo | Configuración de Windows | Configuración de seguridad | Directivas de red inalámbrica (IEEE 802.11).
La Figura 1 muestra la ubicación del nodo Directivas de red inalámbrica (IEEE 802.11) para un dominio denominado "Longhorn" de Windows Server o para un dominio de Windows Server 2003 que ha extendido su esquema con los archivos de extensión de esquema 802.11Schema.ldf y 802.3Schema.ldf (descritos en microsoft.com/technet/network/wifi/vista_ad_ext.mspx).
Figura 1 Nodo Directivas de red inalámbrica (IEEE 802.11)
Figura 1 Nodo Directivas de red inalámbrica (IEEE 802.11)
De forma predeterminada, no hay directivas de red inalámbrica (IEEE 802.11). Para crear una nueva directiva, haga clic con el botón secundario en Directivas de red inalámbrica (IEEE 802.11) del árbol de la consola y, a continuación, haga clic en Crear una nueva directiva de Windows XP o en Crear una nueva directiva de Windows Vista. Para cada tipo de directiva, sólo se puede crear una única directiva, pero cada directiva puede contener la configuración para múltiples redes inalámbricas.
Para la directiva de Windows XP, la configuración de directivas es muy similar a la descrita en mi columna de julio de 2003. Sin embargo, hay nuevas opciones para redes inalámbricas de no difusión, métodos de autenticación del acceso protegido Wi-Fi 2 (WPA2) y configuración de itinerancia rápida para la autenticación WPA2. Para poder usar esta nueva configuración, los equipos que ejecuten Windows XP Service Pack 2 (SP2) deben instalar la Actualización de Cliente inalámbrico para Windows XP SP2 ubicado en support.microsoft.com/kb/917021.
La directiva inalámbrica de Windows Vista contiene una configuración de directiva específica para clientes inalámbricos de Windows Vista y Windows Server "Longhorn". Si se configuran ambos tipos de directivas inalámbricas, los clientes inalámbricos de Windows XP sólo usarán su propia configuración de directiva y los clientes inalámbricos de Windows Vista sólo usarán su propia configuración de directiva. Si no existe ninguna configuración de directiva de Windows Vista, los clientes inalámbricos de Windows Vista usarán la configuración de Windows XP. En este artículo se describen los valores que pueden configurarse con la directiva inalámbrica de Windows Vista.
En la ficha General de directiva de red inalámbrica de Windows Vista puede configurar un nombre y una descripción para la directiva, especificar si habilitar el servicio de WLAN AutoConfig y configurar la lista de perfiles de red inalámbrica y su configuración en el orden que prefiera (consulte la Figura 2). También puede exportar un perfil como archivo XML seleccionando el perfil y haciendo clic en Exportar. Para importar un archivo XML como perfil inalámbrico, haga clic en Importar y especifique la ubicación del archivo.
Figura 2 Propiedades de directivas de red inalámbrica
Figura 2 Propiedades de directivas de red inalámbrica
La Figura 3 muestra la ficha Permisos de red para una directiva de red inalámbrica de Windows Vista con su configuración predeterminada. Esta ficha es nueva para Windows Vista y le permite especificar redes inalámbricas por el nombre y permitir o denegar el acceso a ellas. Por ejemplo, se puede crear una lista de admitidos que contenga los nombres de redes inalámbricas, también conocidos como Identificadores de red (SSID), a la que un cliente inalámbrico de Windows Vista tiene permiso para conectarse. Esto resulta útil para los administradores de redes que desean que los equipos portátiles de una organización se conecten a un conjunto específico de redes inalámbricas, en el cual se puede incluir la red inalámbrica de la organización y los proveedores de servicio de Internet.
Figura 3 Ficha Permisos de red
Figura 3 Ficha Permisos de red
Con una lista de denegación, es posible especificar por el nombre el conjunto de redes inalámbricas a las cuales el cliente inalámbrico no tiene permiso para conectarse. Esto es útil para evitar que equipos portátiles administrados se conecten a otras redes inalámbricas que estén dentro de un intervalo—por ejemplo, cuando una organización ocupa una planta de un edificio y hay otras redes inalámbricas de otras organizaciones en plantas adyacentes También se puede evitar que equipos portátiles administrados se conecten a redes inalámbricas no seguras conocidas mediante una lista de denegación. Para crear una lista o especificar redes inalámbricas individuales para conceder o denegar el acceso, haga clic en Agregar para agregar una red inalámbrica por el nombre y especificar si se admite o se deniega.
En la ficha Permisos de Red, existe también una configuración para evitar conexiones a redes inalámbricas ad hoc o de modo de infraestructura. También se puede permitir que los usuarios vean las redes inalámbricas que se han configurado como denegadas y habilitar a cualquier usuario para que cree un perfil de todos los usuarios. Se puede usar un perfil de todos los usuarios para que cualquier usuario con una cuenta en el equipo se conecte a una red inalámbrica específica. Si esta opción está deshabilitada, sólo los usuarios del grupo Administradores de red o del grupo Operadores de red pueden crear inalámbricos de todos los usuarios en el equipo.

Propiedades de perfiles de redes inalámbricas
Para administrar un perfil de red inalámbrica desde la ficha General de la directiva inalámbrica de Windows Vista, seleccione un perfil existente o haga clic en Edición o en Agregar y, a continuación, especifique si el nuevo perfil inalámbrico es para una red inalámbrica ad hoc o del modo de infraestructura.
Para crear un nuevo perfil inalámbrico, comience en la ficha Conexión dando un nombre al perfil y creando una lista de nombres de redes inalámbricas a las que se aplica (consulte la Figura 4). Se pueden agregar nuevos nombres escribiendo el nombre en el Nombre(s) de red (SSID) y haciendo clic en Agregar. También se puede especificar si el cliente inalámbrico que usa este perfil intentará automáticamente conectarse a las redes inalámbricas nombradas en el perfil cuando estén dentro del intervalo (sujeto al orden de preferencia de la lista de perfiles inalámbricos en la ficha General para la directiva de Windows Vista). Adicionalmente, se puede indicar si desconectarse automáticamente de esta red inalámbrica si una red inalámbrica con mayor preferencia entra dentro del intervalo e indicar que las redes inalámbricas de este perfil sean redes de no difusión (también conocidas como redes ocultas).
Figura 4 Ficha Conexión
Figura 4 Ficha Conexión
Desde la ficha Seguridad, mostrada en la Figura 5, se pueden configurar los métodos de autenticación y cifrado para las redes inalámbricas del perfil. La selección de los métodos de cifrado depende de su elección de método de autenticación. Las selecciones para cada uno se indican en la Figura 6.
Figure 6 Métodos de seguridad (Close Figure 6)

Métodos de autenticación
Abiertos
Compartidos
Personal de Acceso protegido Wi-Fi (WPA)
WPA-Enterprise
WPA2-Personal
WPA2-Enterprise
Abierto con 802.1X
Métodos de cifrado
Privacidad equivalente por cable (WEP)
Protocolo de integridad de claves temporales (TKIP)
Estándar de cifrado avanzado (AES)
Figura 5 Ficha Seguridad
Figura 5 Ficha Seguridad
Si decide seleccionar WPA-Enterprise, WPA2-Enterprise o Abierto con 802.1X como método de autenticación, puede configurar también el método de autenticación de la red (el tipo de Protocolo de autenticación extensible [EAP]), el modo de autenticación (la reautenticación de usuario, la autenticación de equipo, la autenticación de usuario o la autenticación de invitado), el número de veces de error de intento de autenticación antes de abandonar y si almacenar en caché la información del usuario para conexiones posteriores. Esta última opción especifica que cuando el usuario cierra la sesión, los datos de credenciales del usuario se quitan del Registro. Así, cuando el usuario vuelve a iniciar una sesión, se le pedirán sus credenciales (como el nombre de usuario y contraseña).
Para configurar las opciones de seguridad avanzadas para los métodos de autenticación WPA-Enterprise, WPA2-Enterprise, o Abierto con 802.1X, haga clic en Avanzadas. La Figura 7 muestra el cuadro de diálogo de la configuración de seguridad avanzada predeterminada.
Figura 7 Cuadro de diálogo Configuración de seguridad avanzada
Figura 7 Cuadro de diálogo Configuración de seguridad avanzada
En la sección IEEE 802.1X, puede especificar el número de mensajes sucesivos de EAPOL (EAP sobre LAN)-Inicio que se envían cuando no se recibe ninguna respuesta a los mensajes iniciales de EAPOL-Inicio y el intervalo de tiempo entre la retransmisión de mensajes de EAPOL-Inicio cuando no se recibe ninguna respuesta al mensaje EAPOL-Inicio enviado previamente. También puede establecer el período de tiempo durante el cual el cliente de autenticación no realizará ninguna actividad de autenticación 802.1X después de que reciba una indicación de error de autenticación por parte del autenticador, y el intervalo de tiempo que el cliente de autenticación esperará antes de retransmitir ninguna solicitud 802.1X después que la autenticación 802.1X de un extremo a otro se haya iniciado.
Inicio de sesión único (SSO) le permite configurar cuándo se produce la autenticación 802.1X con respecto al inicio de sesión de un usuario e integrar el inicio de sesión de un usuario y las credenciales de autenticación 802.1X en el servidor de inicio de sesión de Windows. En la sección SSO, se indica la configuración para realizar una autenticación inalámbrica inmediatamente antes o después del proceso de inicio de sesión de un usuario y para especificar el número de segundos de retraso para la conectividad antes de que comience el proceso. Puede indicar también si preguntar al usuario campos de entrada adicionales si el método de autenticación requiere que el usuario escriba credenciales adicionales, cuánto tiempo mostrar esos campos y si las redes inalámbricas para este perfil usan una LAN virtual (VLAN) diferente para un equipo o autenticación de usuario.
En la sección Itinerancia rápida, puede configurar el almacenamiento en caché de la Clave maestra en pares (PMK) y las opciones de autenticación previa. La sección Itinerancia rápida sólo aparece cuando se selecciona WPA2-Enterprise como método de autenticación. Con el almacenamiento en caché de la PMK, los clientes inalámbricos y los puntos de acceso (AP) inalámbricos almacenan en caché los resultados de autenticaciones 802.1X. Por lo tanto, el acceso es mucho más rápido cuando un cliente inalámbrico se desplaza a un AP inalámbrico para el que el cliente ya está autenticado. Se puede configurar un tiempo máximo para mantener una entrada en la PMK almacenada en caché y el número máximo de entradas. Con una autenticación previa, un cliente inalámbrico puede realizar una autenticación 802.1X con otros AP inalámbricos en su intervalo mientras se sigue conectando a su AP inalámbrico actual. Si el cliente inalámbrico se desplaza a un AP inalámbrico en el que se ha autenticado previamente, el tiempo de acceso se reduce notablemente. Puede configurarse el número máximo de veces para intentar una autenticación previa con un AP inalámbrico.
Para obtener más información acerca del soporte técnico inalámbrico en Windows, consulte microsoft.com/wifi. Para obtener más información acerca de la Directiva de grupo de Windows, consulte los recursos en microsoft.com/gp.

Joseph Davies es escritor técnico en Microsoft y ha enseñado y escrito sobre temas de red de Windows desde 1992. Ha escrito cinco libros para Microsoft Press y es el autor de la columna mensual TechNet Cable Guy.


 Windows PowerShell: Aplicaci&#243;n de filtros y formato a los datos
Windows PowerShell
Aplicación de filtros y formato a los datos
Don Jones

No hay duda de que Windows PowerShell puede devolver gran cantidad de información valiosa sin que el usuario deba realizar un gran esfuerzo. Por ejemplo, observemos el sencillo cmdlet Get-WMIObject, que se puede usar para devolver una lista de servicios del equipo local. La vista predeterminada, que incluye en una lista el estado, el nombre y el modo de inicio de
los servicios en ejecución, es esencialmente una vista de línea de comandos de la consola Servicios. Windows PowerShell™ facilita enormemente el acceso.
Pero hay mucha más información útil disponible para los servicios, además de lo que se muestra en la vista predeterminada. Intente ejecutar este comando:
$s = get-wmiobject win32_service
$s[0] | gm
La primera línea del comando devuelve una colección de todos los servicios (o, más concretamente, de todas instancias de la clase Win32_Service del Instrumental de administración de Windows®, o WMI) y los almacena en la variable $s. La segunda línea toma el primer servicio de esa colección (el número ordinal cero, indicado entre corchetes) y lo canaliza al cmdlet Get-Member, que he abreviado con su alias, gm. La salida resultante muestra todas las propiedades y métodos disponibles para ese tipo de datos. He decidido usar la clase Win32_Service en WMI en lugar del cmdlet integrado Get-Service de Windows PowerShell porque WMI expone más información que el objeto Service-Controller de Microsoft® .NET, incluida la propiedad Start-Name. Esa propiedad me indica el nombre de la cuenta de usuario con la que se ejecuta el servicio. Puede comprobar el nombre de una única instancia, como, por ejemplo, la primera, de la siguiente manera:
PS C:\> $s[0].StartName
LocalSystem
Sin embargo, la referencia a servicios por su número ordinal dentro de la colección no es muy útil, puesto que los servicios no están en ningún orden concreto. (Normalmente, aparecen en orden alfabético, pero no siempre). Desde una perspectiva de administración, es muy probable que lo que más le interese es obtener una lista de todos los servicios y la cuenta que usa cada uno de ellos para iniciar sesión. Esto sería útil, por ejemplo, para una auditoría de cumplimiento. Retrocedamos un momento y observemos los datos que WMI proporciona de forma predeterminada. Usaré el alias más corto de Get-WMIObject, gwmi (consulte la Figura 1).
Figure 1 Uso de gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
Obviamente, esto sólo es un ejemplo, pero puede observar que la salida no demasiado útil para un informe de administración. Lo que deseo conocer es el nombre del servicio y la propiedad StartName, que es la cuenta con la que se ejecuta el servicio. También me gustaría que el informe tuviera un formato más legible, en lugar de esta lista, que tiene un aspecto un tanto raro. Aquí es donde entran en acción los formidables cmdlets para filtrar datos y aplicar formato de Windows PowerShell.

Obtenga los datos que necesita
Empezaré por filtrar los datos de Get-WMIObject con el fin de mostrar las propiedades que me interesan. La mejor manera de hacerlo es usar el cmdlet Select-Object de Windows PowerShell o su alias sencillo, select. Select está diseñado para aceptar una colección de objetos (como, por ejemplo, la colección devuelta por Get-WMIObject) y mostrar sólo las propiedades deseadas de esos objetos. Esto significa que puedo canalizar la salida de gwmi para seleccionar y especificar las dos propiedades que me interesan. La Figura 2 muestra los resultados, que incluyen las propiedades Name y StartName con un formato agradable de tabla.
Figura 2 Ver únicamente las propiedades Name y StartName en una tabla
Figura 2 Ver únicamente las propiedades Name y StartName en una tabla
No obstante, si tuviera que crear este informe para una auditoría de cumplimiento, contendría demasiada información. Algunos de los servicios están deshabilitados, de modo que es muy probable que las personas que lean el informe no estén nada interesadas en saber cuál es la cuenta que usarían teóricamente los servicios deshabilitados. Por tanto, me gustaría quitar de la lista mediante un filtro todos los servicios que tienen un tipo de inicio Disabled (en la propiedad StartMode de la clase Win32_Service).
Windows PowerShell filtra los objetos con el cmdlet Where-Object o su alias más corto, where. El cmdlet where acepta una colección de objetos de entrada y los pasa a través de un bloque Script para determinar si cada uno de ellos estará presente en la salida del cmdlet según un conjunto de criterios definidos. Cada objeto que cumple los criterios produce una comparación verdadera (True) y se incluye en la salida; los objetos que producen un valor falso (False) no se incluyen.
De esta forma, he determinado que sólo deseo obtener los objetos cuya propiedad StartMode sea igual a Disabled. En términos de Windows PowerShell, esta evaluación tiene el siguiente aspecto:
$object.StartMode –eq “Disabled”
Por supuesto, $object es únicamente un ejemplo. No estoy escribiendo un script real, por lo que no tengo una variable denominada $object. En el bloque Script usado por where, no obstante, sí que se usa una variable especial denominada $_, que representa el objeto que evalúa actualmente el cmdlet. Así, el bloque script de where que he creado puede tener el siguiente aspecto:
$_.StartMode –eq “Disabled”
Se puede probar fácilmente:
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
Por supuesto, en esta prueba rápida, la salida vuelve a aparecer con el estilo de lista predeterminado. Además, para ahorrar espacio, sólo he incluido un servicio. Pero advertirá que esta salida tiene un orden inverso. He incluido los servicios deshabilitados, en lugar de excluirlos. El motivo es que el bloque Script va hacia atrás: Necesito incluir todos servicios donde StartMode no sea igual a Disabled, tal como muestra esta modificación de mi ejemplo:
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
Eso está mejor. Ahora que la salida contiene sólo los servicios que me interesan realmente, puedo canalizar de nuevo la salida para seleccionar y especificar únicamente las propiedades que deseo:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
La canalización de datos un cmdlet a otro y a otro más ilustra las capacidades de Windows PowerShell. Todavía no he escrito ningún script, pero he conseguido filtrar un gran conjunto de datos para obtener la salida que deseo.

El aspecto correcto
Debe tener presente que la salida de select sigue siendo un montón de objetos. Al recuperar una tabla con formato agradable mediante Windows PowerShell, esta tabla es realmente la representación de PowerShell.exe de esos objetos. Es decir, Windows PowerShell sabe que yo, como mero ser humano, no puedo ver los objetos, de modo que los representa como texto. En este caso, he representado los objetos como una tabla, con una columna para cara propiedad, como se ilustra en la Figura 2.
Quizás esto sea suficiente para la auditoría que tengo que realizar. Pero quizás no lo sea. Todas las personas tienen necesidades distintas y Windows PowerShell no pretende saber cuáles son sus necesidades específicas. En su lugar, le proporciona las herramientas que necesita para aplicar formato a la salida de la forma que se ajuste mejor a sus necesidades. Cuatro cmdlets integrados (Format-List, Format-Custom, Format-Table y Format-Wide) están diseñados para aceptar una colección de objetos (como, por ejemplo, la colección devuelta por select) y aplicar formato a esos objetos de varias maneras. Format-Table es básicamente lo que Windows PowerShell ya usa para aplicar formato la salida de mi cmdlet select. Para un aspecto diferente, probemos Format-List:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
El resultado tiene un aspecto parecido a este ejemplo:
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
El cmdlet Format-Wide está diseñado para producir de forma predeterminada una lista con varias columnas de la primera propiedad de cada objeto. Veamos esta línea, por ejemplo:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
Produce una lista de nombres de servicio, que no es lo que deseo obtener. En la salida falta StartName (consulte la Figura 3), que es un dato importante que necesito en mi informe de auditoría.
Figura 3 La salida mostrada con el cmdlet Format-Wide omite información clave: la propiedad StartName
Figura 3 La salida mostrada con el cmdlet Format-Wide omite información clave: la propiedad StartName
Como sólo trabajo con dos propiedades, es probable que Format-Table o Format-List sean aceptables. Pero es improbable que a un auditor le gustara ver esta información en pantalla. Probablemente preferiría tener algún tipo de archivo.

Exportación de los datos
Así, pues, ¿cómo podría desear ver un auditor los datos? La inclusión de la lista de servicios y nombres de inicio de sesión en un archivo CSV (valores separados por comas) podría resultar suficiente, puesto que el archivo se puede abrir fácilmente en Microsoft Excel®. Para crear un archivo CSV sólo hay que canalizar la salida al cmdlet Export-CSV de Windows PowerShell:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
Por supuesto, en el mundo actual, el formato CSV parece un poco anticuado. Quizás sus auditores preferirían que los datos se mostraran como páginas web en un servidor de la intranet. Para ello, convierta la salida a HTML con el cmdlet ConvertTo-HTML:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
El código HTML sin procesar es difícil de ver, por lo que deberá escribir la salida en un archivo:
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
El resultado, mostrado en la Figura 4, es una página HTML con formato correcto que se puede publicar en cualquier servidor web sin modificaciones adicionales.
Figura 4 Salida mostrada como página HTML con formato correcto
Figura 4 Salida mostrada como página HTML con formato correcto

Sólo los datos (pertinentes)
Windows PowerShell le ofrece acceso rápido a un amplio espectro de datos de administración. Sin embargo, esos datos sin procesar no siempre son útiles en un sentido de negocio.
Si filtra los datos (con where), elige las propiedades de objeto deseadas (con select) y aplica una opción de formato apropiada (como, por ejemplo, Format-Table o Format-List), podrá convertir rápidamente estos datos de administración en información útil con muy poco esfuerzo. Y, a continuación, si exporta los datos a un formato de archivo que se pueda compartir fácilmente, podrá trasladar esta información más allá de su propio escritorio y comunicar información valiosa a otras personas de su organización.

Don Jones es el director de proyectos y servicios de SAPIEN Technologies y coautor de Windows PowerShell: TFM (SAPIEN Press). Póngase en contacto con Don a través de su sitio web en www.ScriptingAnswers.com (en inglés).


 &#161;Hola, chicos del scripting!: Dominio inocente de los usuarios y grupos locales
¡Hola, chicos del scripting!
Dominio inocente de los usuarios y grupos locales
Los chicos del scripting de Microsoft
Descargar el código de este artículo: HeyScriptingGuy2007_04.exe (151KB)

¿Cómo puedo administrar descriptores de seguridad en archivos y carpetas?

Aunque no se lo crea, hubo un tiempo (hace mucho tiempo, por supuesto) en el que los chicos del scripting no eran demasiado listos. Sabemos que es difícil de creer, pero, ¿qué quiere decir con que no es tan difícil de creer? ¿Y qué significa eso de que no puede haber sido hace tanto tiempo? Deje que le digamos que... bueno, vale. Obviamente, vio a uno de los chicos del scripting intentando conectar un televisor nuevo el otro día.
En su defensa, este chico del scripting argumentaría que conectar un televisor nuevo no es ingeniería espacial, sino que es mucho más complicado. Sólo para conectar el televisor se necesitan tres cables de vídeo y un par de cables de audio; además, hay que conectar un reproductor de vídeo, un reproductor de DVD y una consola Xbox®, sin mencionar el tener que presionar toda una serie de números en el mando a distancia "universal" para que pueda reconocer todos estos dispositivos. En comparación con eso, colocar un satélite en órbita alrededor de Marte es pan comido.
Hay que decir que el chico del scripting consiguió realizar todas estas conexiones correctamente. Sin embargo, cuando encendió todos los aparatos, no pasó nada. Diligentemente, revisó y volvió a revisar todas las conexiones. Leyó todos los manuales de usuario e incluso buscó en Internet por si había información que le faltaba. Nada de nada. Ya iba a sacrificar un reproductor de MP3 al dios de la electrónica cuando se dio cuenta de que no había realizado el paso fundamental de conectar el cable que va desde la caja de cables al enchufe de la pared.
Nota: quizás esté pensando que si conectar todo el material de la familia del scripting es tan difícil, puede que la familia del scripting tenga demasiado material. Ciertamente, el chico del scripting estaría de acuerdo con usted. Sin embargo, cada vez que la familia vota sobre la adquisición de más material, este chico del scripting pierde por dos a cero. Y no, no tendría que ser por dos a uno, es dos a cero. Por algún motivo, el voto del padre del scripting parece que no cuenta nunca en las elecciones familiares, y no hay rastro de papel que valga.
En respuesta a su siguiente pregunta: sí, lo ha intentado. Pero hasta ahora la ONU ha rechazado el envío de observadores para supervisar las elecciones en la casa del scripting.
Por supuesto, pensándolo mejor, no es que los chicos del scripting (mejor dicho, el que intentaba instalar el televisor) fueran tontos, es que eran inocentes. Por ejemplo, cuando planeaban el manual de scripting de Microsoft® Windows® 2000, solicitaron ayuda a varios expertos para determinar cuáles serían los capítulos del libro. Uno de los capítulos que se quedó en el tintero fue un capítulo sobre la administración de usuarios y grupos locales. "¿Administrar usuarios y grupos locales?", dijeron los expertos. "¿Por qué tan siquiera se contempla incluir eso? ¿A quién le importa la administración de usuarios y grupos locales?"
Pues bien, muy a nuestro pesar, hemos descubierto que a todo el mundo (con la posible excepción de nuestros "expertos" internos) le importan los usuarios y grupos locales. Cada semana recibimos muchísimos correos electrónicos de personas que preguntan cómo hacer cosas como agregar un usuario a un grupo local, eliminar un usuario de un grupo local o cambiar la contraseña del administrador local en un equipo.
Si bien es cierto que el Repositorio de Script Center tiene algunos scripts de ejemplo que muestran cómo realizar estas tareas, la mayoría de estos scripts funcionan sólo en un equipo a la vez. Eso no es lo suficientemente bueno: los usuarios quieren saber cómo hacerlo en varios equipos simultáneamente. ¿Cambiar la contraseña del administrador local en un sólo equipo? Acérquense al mundo real, chicos del scripting: queremos hacerlo en todos los equipos o en todos los equipos de una unidad organizativa o en... bueno, ya nos entienden.
Teniendo en cuenta que el manual de scripting se publicó en 2003, hemos pasado casi cuatro años recibiendo estos mismos mensajes de correo electrónico. "Aquí hay otro lector que pregunta cómo puede leer nombres de equipo desde una hoja de cálculo de Excel® y, a continuación, cambiar la contraseña del administrador local en cada uno de esos equipos", observó recientemente uno de los chicos del scripting. "¿Qué podemos hacer?"
Bien, nos llevó cuatro años, pero al fin lo averiguamos. En la Figura 1 se muestra exactamente qué podemos hacer.
Figure 1 Finalmente lo averiguamos. (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
Nota: como puede observar, no tardamos cuatro años en escribir este script porque fuera difícil, sino porque solemos tardar ese tiempo en hacer cualquier cosa. Por eso uno nunca quiere perderse las fiestas de nochevieja anuales de los chicos del scripting; a fin de cuentas, nunca se sabe cuándo o si se celebrará el próximo acontecimiento anual.
Lo que vemos aquí es un script que extrae los nombres de los equipos de una hoja de cálculo y, a continuación, cambia la contraseña del administrador local en cada uno de esos equipos. Para hacer este truco de magia, empezamos fácilmente, dando por supuesto que tiene una hoja de cálculo muy sencilla, como la de la Figura 2. (Si no la tiene, créela ahora mismo).
Figura 2 Lista obligatoria de equipos
Figura 2 Lista obligatoria de equipos
Como puede ver, no tiene nada de especial. En la columna 1 (la columna A), incluimos una lista de los nombres de todos los equipos que tienen las contraseñas que necesitamos cambiar. En la columna 2 (la columna B), simplemente realizamos el seguimiento de la fecha y hora en que se cambió por última vez la contraseña del administrador de cada equipo. Esto le permite saber si todas sus contraseñas de administrador están sincronizadas.
En cuanto al script en sí mismo, empezamos con la instrucción On Error Resume Next. Generalmente, no nos molestamos en incluir el control de errores en nuestros scripts. No es porque nos opongamos al control de errores, sino porque intentamos que nuestros scripts sean lo más breves y sencillos posibles. En este caso, sin embargo, la instrucción On Error Resume Next es crucial. A fin de cuentas, nuestro script intentará conectarse a numerosos equipos distintos. ¿Qué sucede si uno de esos equipos está apagado? Pues con el control de errores no pasará nada. Es cierto, se producirá un error, pero el script podrá omitirlo y continuar. Sin el control de errores obtendría casi el mismo resultado que obtuvo el chico del scripting cuando encendió el nuevo televisor por primera vez: nada.
Lo siguiente es usar el siguiente bloque de código para crear una instancia del objeto Excel.Application, hacer que esa instancia de Excel esté visible en pantalla y abrir la hoja de cálculo C:\Scripts\Test.xls:
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
Y, por último, asignamos el valor 2 a una variable de contador denominada i. Usaremos esta variable para realizar un seguimiento de la fila actual en la hoja de cálculo.
Nota: ¿por qué se le asigna el valor 2? Muy sencillo: si observa de cerca la hoja de cálculo verá que los datos empiezan en la fila 2. La fila 1 es únicamente una fila de encabezado.
¿Lo ve? Quizás no seamos buenos a la hora de conectar cables YPbPr1, pero sí que sabemos algo del scripting.
Bueno, a veces.
Ahora estamos listos para empezar a trabajar. Primero, configuramos un bucle Do Unitl que se ejecute hasta detectar una celda vacía en la columna 1. Y sí, esto significa que, haga lo que haga, no puede dejar ninguna fila en blanco en la columna 1. Si el script detecta una fila en blanco, dará por supuesto que ha alcanzado el final de los datos, por lo que el bucle y el script finalizarán. Aunque hay formas de solucionar esta cuestión, es mucho más sencillo evitar tener filas en blanco en la hoja de cálculo.
Dentro del bucle, empezaremos por asignar el valor encontrado en la fila de celda i, columna 1, a una variable denominada strComputer. Recuerde que la primera vez que pasa por el bucle, i es igual a 2; por lo que trabajaremos con el valor de la celda 2, columna 1. Usaremos esta línea de código para crear una referencia a objeto (objUser) a la cuenta del administrador local del equipo representado por la variable strComputer:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
Si se tiene que producir algún error en este script, será en este punto. Por ejemplo, supongamos que tenemos problemas de red, que el equipo se ha apagado o que uno de los chicos del scripting ha conectado mal el reproductor de DVD y ha dejado sin suministro eléctrico a la mitad occidental de Estados Unidos. Si sucede cualquiera de estas cosas, no se podrá establecer una conexión con el equipo. Por este motivo, comprobaremos inmediatamente el valor del objeto Err de VBScript:
If Err = 0 Then
Si el objeto Err es igual a 0, significa que se pudo establecer la conexión con el equipo (y con la cuenta de administrador) sin ningún problema. Si el valor de Err es distinto de 0, sólo puede significar una cosa: se produjo algún error en nuestro intento de conexión. En ese caso, no nos molestaremos en cambiar la contraseña del equipo en cuestión; sobra decir que si no podemos establecer la conexión, no podremos cambiar la contraseña.
Suponiendo que todo vaya bien y que no se produzca ningún error, a continuación, ejecutaremos las dos líneas de código siguientes:
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
En la línea 1, usamos el método de SetPassword para asignar una contraseña nueva (egTY634!alK2) a la cuenta del administrador local. (Sí, sí, lo sabemos: se supone que no debe usar el nombre de su hijo como contraseña.) En la línea 2, escribiremos la fecha y la hora actuales (con la función Now de VB-Script) en la fila de la celda i, columna 2. Advierta que actualizamos la columna Password Changed (Contraseña cambiada) sólo si podemos conectarnos al equipo remoto y cambiamos la contraseña. Si no podemos conectarnos a un equipo, su campo Password Changed correspondiente no se actualizará nunca; de esta forma, podemos saber si las operaciones se realizaron correctamente o no.
¿Qué significa todo esto? Esto significa que, la primera vez que pase por el bucle, la hoja de cálculo tendrá un aspecto parecido al de la Figura 3.
Figura 3 Lista de equipos después de restablecer la primera contraseña
Figura 3 Lista de equipos después de restablecer la primera contraseña
El equipo 1 ya está. Ahora tenemos que hacer un poco de limpieza antes de continuar:
Err.Clear
i = i + 1
Aunque son muy cortas, estas dos líneas de código son muy importantes. (¡Cómo si los chicos del scripting fueran a escribir líneas de código que no fueran importantes!) La primera línea restablece el objeto Err a 0. Si no se produjo ningún error, esto es redundante; a fin de cuentas, en ese caso Err ya será 0. Si se produjo un error, sin embargo, Err será igual a un valor distinto de 0. En ese caso, es crucial restablecer manualmente el objeto Err. ¿Por qué? Porque se trata del objeto Error: sólo realiza el seguimiento de los errores, no de las acciones realizadas correctamente. Por ejemplo, supongamos que se produjo un problema con el equipo 1 y que no se pudo establecer una conexión. Digamos que esto hizo que el objeto Error se estableciera en 99.
Supongamos también que pasamos por alto este error con el bucle y nos conectamos correctamente al equipo 2. ¿Cuál cree que será el valor de Err ahora? Correcto: nos guste o no, el valor de Err seguirá siendo 99, porque el valor del objeto Err sólo cambia cuando se produce un error; no obstante, si no se produce ningún error, el objeto de Err seguirá conservando su valor actual indefinidamente.
¿Nos importa de verdad? Debería importarnos. A fin de cuentas, técnicamente no cambiamos la contraseña en un equipo si se establece una conexión correctamente; sólo cambiamos la contraseña si Err es igual a 0. Y (un momento, que ejecutamos la Calculadora) sí, teníamos razón: 99 no es igual a 0 (menos, por supuesto, en las elecciones de la familia del scripting, donde 99 votos del padre del scripting sólo suman 0). Esto es importante, porque aunque se pudo establecer la conexión con el equipo 2, Err no es igual a 0. Y, como Err no es igual a 0, ni siquiera intentamos cambiar la contraseña del administrador local.
Es decir, si cambia el valor de Err, deberá restablecer el valor a 0; de lo contrario, a partir de ese momento, el script creerá que se produjo un error. ¿Y cómo se restablece el valor del objeto Err a 0? Exacto: mediante una llamada a Err.Clear.
A continuación, incrementamos el valor de i en 1. ¿Por qué? La primera vez que pasó por el bucle, la variable i era igual a 2, porque deseábamos establecer la conexión con el equipo que aparecía en la fila 2, columna 1. La segunda vez que pasa por el bucle, lo que deseamos es conectarnos al equipo que aparece en la fila 3, columna 1. Como la variable i indica la fila con la que queremos trabajar, i tiene que ser igual a 3. Y, como todo el mundo sabe, 2+1=3. (Menos mal que todavía se estaba ejecutando la Calculadora.) Sólo entonces usamos el bucle y repetimos el proceso con el siguiente equipo de la hoja de cálculo.
Eso está muy bien pero, como ya no somos tan inocentes como antes, somos conscientes de que este script, por sí mismo, no podrá reducir la cantidad de mensajes de correo electrónico que recibimos. "Eso que hicieron con Excel estaba bien", dirá la gente, "pero tengo que cambiar la contraseña del administrador local en todos los equipos de una unidad organizativa o en todos los equipos que aparecen en un archivo de texto. O quizás me gustaría ver una lista de equipos y poder seleccionar uno de ellos en un cuadro de lista. O quizás lo que querría hacer es..."
Relájese. Sus deseos son órdenes para los chicos del scripting. (Suponiendo que esté dispuesto a esperar cuatro años a que su deseo se cumpla.) En realidad, tenemos muchas plantillas para varios equipos publicadas en Script Center, y estas plantillas facilitan enormemente la ejecución de un script en varios equipos. Por ejemplo, supongamos que desea cambiar la contraseña del administrador local para todos los equipos de una unidad organizativa. No hay problema. La plantilla para ejecutar un script en todos los equipos de una unidad organizativa tiene un aspecto como el presentado en la Figura 4.
Figure 4 Ejecución de un script en una unidad organizativa (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
¿Ve la sección de la plantilla denominada "Insert your code here" (Inserte el código aquí)? Lo único que debe hacer es eliminar el código de ejemplo de esa sección y reemplazarlo por el código (que puede copiar desde este artículo) para cambiar la contraseña del administrador local. Es decir, reemplace el código de ejemplo por el siguiente código:
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
Este ejemplo en concreto no registrará los resultados, pero puede agregar el código necesario para hacerlo. Reemplace el código de ejemplo, cambie la cadena de conexión LDAP://OU=Finance,dc=fabrikam,dc=com para dirigirla a una de sus unidades organizativas, y ya está.
En realidad, publicamos estas plantillas hace más de un año, creyendo que serían uno de los elementos más populares de Script Center. Nos equivocábamos: casi nunca se usan, aunque casi cada día la gente nos escribe preguntándonos cómo pueden ejecutar scripts en varios equipos. Damos por supuesto que nadie sabía que estas plantillas existían. Pero ahora ya lo sabe. O lo sabrá si le decimos dónde encontrarlas: microsoft.com/technet/scriptcenter/scripts/templates. Quizás por eso nadie usó nunca estas plantillas...
Ahora que los chicos del scripting ya no son tan inocentes como antes, ¿significa también que no son tan tontos y torpes como antes? Digámoslo así: hace un tiempo, no demasiado, uno de los chicos del scripting decidió pasar el fin de semana arreglando unas cosas en casa. Cuando vino a trabajar el lunes, tenía un pulgar aplastado que no dejaba de sangrar y un gran corte en la pierna.
Si lo pensamos bien, tampoco estaba tan mal. Por lo menos, no para un chico del scripting.

Los chicos del scripting de Microsoft trabajan para (bueno, son empleados de) Microsoft. Cuando no juegan al béisbol, ni entrenan ni lo ven (u otras actividades varias), dirigen TechNet Script Center. Visite la página web www.scriptingguys.com.


 Vigilancia de seguridad: Asistente para configuraci&#243;n de seguridad
Vigilancia de seguridad
Asistente para configuración de seguridad
John Morello
Esta columna contiene información preliminar sobre "Longhorn" de Windows Server y está sujeta a cambios.

La protección constante y eficaz de los servidores es un desafío para muchas organizaciones de TI, especialmente las que tienen muchos equipos dispersados por muchas zonas geográficas y de la organización. Si bien aumentar la protección de un solo servidor puede ser una tarea relativamente sencilla para un administrador con experiencia, hacerlo para decenas, centenares o
hasta miles de servidores es una situación muy diferente. Con el paso de los años, muchas organizaciones han elaborado sus propias listas de comprobación o estándares internos relativos a la seguridad de los servidores. También han incorporado las directrices ofrecidas por Microsoft, el Instituto Nacional de Estándares y Tecnología u otras terceras partes externas. Aunque esta documentación puede resultar de gran valor, por sí sola no es suficiente para que las organizaciones pongan estas recomendaciones en práctica en sus redes. En consecuencia, muchas han optado por mantener la configuración de instalación predeterminada o por invertir una cantidad de tiempo y esfuerzo considerables en la creación de sus propias secuencias de comandos o directivas para fortalecer los sistemas.
Con la llegada del Asistente para configuración de seguridad (SCW) en Windows Server® 2003 Service Pack 1 (SP1), Microsoft ofrece un método sencillo y compatible para fortalecer los servidores y reducir su superficie expuesta a ataques basándose en las funciones que realizan. Mediante la combinación de las prestaciones del SCW con las capacidades de implementación y administración centralizadas de la directiva de grupo, el SCW se puede escalar para su uso en las empresas de TI de mayor tamaño. En la columna de este mes, voy a ofrecer una introducción sobre cómo pueden usar el SCW y la directiva de grupo las organizaciones de TI para administrar sus servidores de manera más segura y coherente, a la vez que reducen los costos operativos y de implementación.

¿Qué es el SCW?
El SCW es un componente opcional, instalado a través del panel de control para agregar o quitar componentes de Windows®, disponible en todos miembros de la familia de Windows Server 2003 SP1, incluido Windows Server 2003 R2. Un administrador debe empezar ejecutando el SCW en un servidor de destino para identificar las funciones que desempeña. A continuación, el SCW ayuda al administrador a crear una directiva de seguridad que protege el equipo mediante un esquema de privilegios mínimos. Dicho de otro modo, el SCW ayuda a asegurar que sólo están disponibles los servicios, capacidades de aplicación y puertos requeridos para el funcionamiento de las funciones. Todo aquello que no sea específicamente necesario para las funciones del servidor será deshabilitado. Este enfoque ayuda a reducir la superficie de ataque del servidor de destino. Si ejecuta servicios que no son requeridos para la función que el servidor realiza, aumenta el riesgo para el servidor sin contrapartida alguna de capacidad ni funcionalidad. Si se deshabilitan estos servicios, se reduce el riesgo y se puede mejorar el rendimiento del servidor.
Mientras Microsoft ha introducido muchos avances de seguridad en Windows Server 2003, reduciendo en gran medida su superficie de ataque global en comparación con versiones anteriores de Windows Server, no ha avanzado en el mismo núcleo de muchos componentes que constituyen Windows Vista™ y la próxima versión Windows Server, denominada "Longhorn". Así, en una instalación predeterminada de Windows Server 2003, puede haber servicios habilitados y en ejecución que no son necesarios para todas las configuraciones de la función de servidor. Por ejemplo, el servicio de cola de impresión está habilitado de forma predeterminada, pero no es necesario en equipos que sólo actúan como servidor de base de datos.

Hacer realidad la seguridad basada en funciones
En los últimos años, Microsoft ha publicado abundante documentación centrada en la seguridad, que ayuda a los administradores a entender qué servicios son requeridos en distintas funciones de servidor y ofrece plantillas integradas para las funciones bien conocidas, por ejemplo los servidores web. Sin embargo, directrices como la de la Guía de seguridad de Windows Server 2003 pueden resultar de difícil implementación en entornos de gran tamaño, especialmente cuando las aplicaciones usadas en esos entornos son, con frecuencia, más compleja que las instalaciones básicas de IIS o SQL Server. Todo se complica más por los centenares de aplicaciones de otros fabricantes que usan las empresas, muchas de las cuales dependen de varias funciones de servidor y cuyos requisitos de aplicaciones y servicios no son siempre bien definidos.
SCW se ocupa de estos problemas mediante la agrupación en un asistente dirigido a los administradores de todos los conocimientos sobre dependencias y las recomendaciones de los manuales. Por ejemplo, si un administrador implementa una nueva aplicación (LOB) que requiere SQL Server™ e IIS, ya no tiene que invertir gran cantidad de tiempo en analizar la guía de seguridad y desarrollar su propia lista de dependencias personalizadas. En vez de eso, puede instalar la aplicación en el servidor e iniciar el SCW. El SCW detectará qué servicios se ejecutan actualmente y proporcionará al administrador una lista de las funciones que puede elegir para el servidor. En función de lo que seleccione, el SCW generará una directiva que deshabilitará todos servicios no requeridos por la matriz de dependencias de las funciones. El SCW ofrecerá también opciones para fortalecer el Registro, bloqueando las comunicaciones de red innecesarias y aplicando una directiva de auditoría eficaz. Después que ejecutar el SCW, el administrador puede guardar la directiva del SCW como archivo XML y aplicarlo a cualquier otro servidor que en que se ejecuta la misma aplicación LOB.
La ejecución del SCW ofrece tres importantes ventajas sobre otros enfoques manuales convencionales para proteger Windows Server. Primero, reduce mucho (si no la elimina por completo) la necesidad de que el administrador consulte constantemente la documentación del producto para determinar los servicios y la configuración necesarios para una carga de trabajo dada. Esta información está integrada en el SCW y la interfaz, controlada por preguntas, facilita al administrador la introducción de los datos necesarios. En segundo lugar, el SCW reúne las directrices de varias áreas, como el reforzamiento de los servicios, la reducción de la superficie de ataque de la red, el reforzamiento de los servicios LDAP y SMB, y el bloqueo de IIS. Hasta ahora, la realización de estas tareas de configuración requería distintas herramientas, cada con su interfaz y enfoque propios. Finalmente, puesto que el SCW muestra la configuración en un archivo de directiva XML, se puede usar en escenarios "crea una vez, aplica muchas veces". Es igual que vaya a implementar 1 o 100 servidores para una aplicación LOB concreta: la misma directiva del SCW se puede aplicar fácilmente a todos ellos. Así, la configuración de seguridad es más coherente y se reducen los costos operativos. Además, resulta más sencillo SCW anular las directivas.

Componentes del SCW
Por todas sus capacidades y prestaciones, el SCW es una herramienta relativamente sencilla que consta de tres partes principales: la interfaz del asistente, la interfaz de línea de comandos y la Base de datos de la configuración de seguridad (SCD). Los administradores de empresas pequeñas o medianas podrían tener que usar únicamente la interfaz del asistente. En entornos más grande o complejos, los administradores pueden usar la interfaz de línea de comandos para contribuir a automatizar tareas del SCW como la transformación de una directiva de SCW en un Objeto de directiva de grupo (GPO). Normalmente, sólo modificarán el SCD los administradores avanzados que deseen crear sus propias funciones personalizadas del SCW.
La interfaz del asistente, que se muestra en la Figura 1, permite a los administradores crear, editar, aplicar, y revertir la configuración de seguridad en un servidor de destino. Ofrece opciones a los administradores en un flujo de trabajo coherente que primero examina los servicios y la configuración, a continuación la conectividad de red, las directivas de auditoría de seguridad, y finalmente la configuración IIS.
Figura 1 Interfaz del SCW
Figura 1 Interfaz del SCW
La interfaz de línea de comandos del SCW ofrece tres funciones básicas. Permite a los administradores analizar y configurar varios servidores (locales o remotos) y revertir las directivas. Se puede usar para convertir automáticamente una directiva basada en XML del SCW en un GPO que se puede utilizar nativamente en herramientas de administración de GPO estándar, como la Consola de administración de directivas de grupo. Por último, la herramienta de línea de comandos del SCW que se muestra en la Figura 2 se usa para registrar nuevas extensiones de la Base de datos de configuración de seguridad.
Figura 2 Herramienta de línea de comandos de SCW
Figura 2 Herramienta de línea de comandos de SCW
La SCD no es más que una colección de archivos XML que detallan los servicios y la configuración concretos necesarios para cada función del SCW. Estos archivos se encuentran en el directorio %windir%\security\msscw\kbs. De forma predeterminada, el SCW se suministra con varias funciones esenciales de Windows Server, así como 12 funciones de aplicaciones predefinidas: BizTalk®, Commerce Server, Exchange Server, Host Integration Server, Internet Security and Acceleration Server, Microsoft Identity Integration Server, Microsoft Operations Manager, Small Business Server, SharePoint® Portal Server, SharePoint Team Services, SQL Server, y Systems Management Server. Cada función tiene su propio archivo XML (consulte la Figura 3). Cada vez que se crea una definición de función nueva, el archivo XML correspondiente se coloca en este directorio. Los archivos son XML estándar y se pueden leer en cualquier visor de texto u otra aplicación compatible con XML (consulte la Figura 4).
Figura 3 Funciones predefinidas
Figura 3 Funciones predefinidas
Figura 4 Archivo de configuración de función
Figura 4 Archivo de configuración de función

Combinar el SCW y la directiva de grupo
Por sí mismo, el SCW es una gran herramienta, pero su verdadera eficacia no se descubre hasta que se combina con la directiva de grupo. Desde la publicación de Windows® 2000, las recomendaciones de Microsoft para proteger los servidores de Windows se han centrado en usar la directiva de grupo para ofrecer una aplicación de directivas administrada centralizadamente, persistente y coherente. Mediante la agrupación de servidores en unidades organizativas en función de sus funciones, los administradores pueden implementar configuraciones de seguridad estándar en toda la empresa en lugar de tener que hacerlo en cada uno de los equipos individuales. Partiendo de la lógica de acumulación y de aplicaciones estándar de la directiva de grupo, las organizaciones pueden diseñar una jerarquía de funciones de servidor en niveles en la que unas cuantas directivas maestras pueden proteger cientos o miles de servidores individuales. Si hay funciones exclusivas de servidor que exigen desviarse de las directivas maestras, se pueden crear directivas delta más pequeñas centradas en la función más "cercanas" a los servidores en la jerarquía de la unidad organizativa. Así, se admiten pequeños cambios para habilitar la funcionalidad específica de la función sin tener que duplicar la totalidad de la directiva maestra, un enfoque que ofrece a las empresas grandes las ventajas de una directiva administrada centralmente y la flexibilidad para adaptarse a aplicaciones concretas cuando es necesario.
El verdadero desafío de este enfoque está en hacerlo realidad. En grandes organizaciones con muchas aplicaciones y funciones de servidor, la creación del conjunto correcto de directivas es difícil y laborioso, o lo era hasta la llegada del SCW. Mediante el uso del SCW para generar directivas y, a continuación, adjuntarlas a la unidad organizativa correcta, puede reducir mucho el tiempo necesario para implementar la seguridad alojada en directorio y basada en funciones, tanto para cargas de trabajo existente como para las que pueda adoptar más adelante. Para ilustrar mejor cómo podría hacer una organización que esto funcione, vamos a analizar la implementación en una empresa de gran tamaño del SCW y las directivas de grupo basadas en las funciones.

SCW en la empresa
Para este ejemplo, yo usaré la red ficticia de Contoso. Contoso tiene una organización de TI grande, compleja y geográficamente dispersa. Con la expectativa de reducir sus costos operativos y aumentar la seguridad de sus servidores, Contoso sigue los consejos de Microsoft para crear una jerarquía de unidades organizativas basada en las funciones, que separa y organiza los servidores en función de la carga de trabajo. Para crear las directivas y adjuntarlas a las unidades organizativas, Contoso usa el SCW.
Puesto que el SCW no se instala de forma predeterminada, Contoso debe habilitar específicamente el componente SCW en su imagen de instalación desatendida. Para hacerlo, agrega una línea, SCW=On, a la sección [Components] de Unattend.txt. A partir de ese momento, en todos los nuevos sistemas creados con esta imagen el componente SCW se instalará durante instalación. Tenga en cuenta que la mera configuración del SCW para que se instale no aplica ninguna directiva a los equipos cuando se generan.
Para aplicar una directiva predeterminada durante el proceso de configuración, Contoso edita la sección [Commands] del archivo de cmdlines.txt de la imagen para llamar a Scwcmd con las opciones siguientes:
scwcmd configure /p:ContosoBaselinePolicy.xml
El archivo de texto y el archivo XML deben estar en el directorio $OEM$ de la imagen. ¿Por qué aplicaría Contoso una directiva de línea de base en el tiempo de creación en lugar de depender únicamente de la adjuntada a la unidad organizativa superior del directorio? Mediante la aplicación de una directiva en tiempo de creación, Contoso puede garantizar que la línea de base es coherente, independientemente de que un equipo esté unido a Active Directory®. Por ejemplo, si se crea un servidor realizar pruebas, aplicando la directiva de línea de base durante el proceso de creación se asegura que, al menos, cumple la directiva de seguridad estándar de la organización, incluso si no se une nunca a Active Directory de producción. Si, más adelante, el servidor se une a Active Directory, la aplicación de la directiva de grupo y el algoritmo de prioridad sustituirá la configuración local por la del nivel de dominio o unidad organizativa (recuerde que el orden de prioridad para la aplicación de directivas es local, sitio, dominio y unidad organizativa).
Una vez que se ha instalado el SCW, Contoso puede empezar a crear su directiva de línea de base. La directiva de línea de base debe ser la que se implemente en el nivel superior de la jerarquía de unidades organizativas basada en funciones y, normalmente, será la directiva más restrictiva de la jerarquía. El objetivo es disponer de una directiva predeterminada lo más segura posible, y abrir sólo los servicios y puertos para cargas de trabajo individuales necesarios para las funciones de servidor. Para ello, la directiva de línea de base se debe crear a partir de un servidor vacío y recién creado, para después agregar el conjunto de herramientas de administración y utilidades de Contoso y, finalmente, ejecutar el SCW en el servidor. Por ejemplo, después de terminar la instalación básica de Windows, Contoso instala en el servidor (manualmente o mediante el archivo cmdlines.txt) sus herramientas antivirus, de copia de seguridad, de administración y de supervisión estándar. Dado que es probable que cada una de estas herramientas cree sus propios servicios de Windows, tenerlas en el servidor antes de crear la directiva de línea de base permite al SCW conocer su existencia durante la fase de bloqueo de servicios.
Una vez que se ha creado el servidor, Contoso ejecuta el SCW en él. El SCW se puede ejecutar de forma local o de forma remota, y lo debe ejecutar un miembro del grupo de administradores locales del equipo. Si el SCW se ejecuta de forma remota, ofrece una opción para especificar la cuenta de usuario en la que se debe ejecutar en el host remoto; si se ejecuta de forma local, se puede usar runas.exe para obtener el mismo resultado. La primera tarea que emprende el SCW es la de evaluar los servicios en ejecución en el equipo local y mostrar qué funciones están instaladas actualmente (consulte la Figura 5).
Figura 5 Seleccionar y ver las funciones de servidor
Figura 5 Seleccionar y ver las funciones de servidor
No se debe seleccionar ninguna función en el servidor de línea de base de Contoso, puesto que el equipo se ha diseñado para estar en un estado muy restringido. Después de seleccionar las funciones que realiza el servidor, el paso siguiente consiste en identificar las características de cliente necesarias para habilitar funcionalidad como Actualizaciones automáticas, Active Directory, o el cliente de FTP. Para la mayoría de las organizaciones, la aceptación de los valores predeterminados del SCW (como se muestra en la Figura 6) proporciona la funcionalidad importante (por ejemplo, la capacidad de unirse a un dominio), pero prohíbe las características menos esenciales (como el cliente de FTP).
Figura 6 Características instaladas
Figura 6 Características instaladas
A continuación, el SCW le permite elegir las herramientas administrativas específicas y los servicios no predeterminados que se van a admitir. Las opciones de los servicios no predeterminados son la razón por la que debe ejecutar el SCW después de instalar el conjunto estándar de la administración de servidores de Contoso. Cuando se instalen las aplicaciones antivirus, de copia de seguridad y otras relacionadas, el SCW tendrá constancia de la existencia de estos servicios y, por lo tanto los incluirá en la configuración de la directiva resultante.
La última pregunta de la sección de la seguridad de servicios pregunta cómo manejar los servicios no especificados. Son servicios que se pueden encontrar en otros equipos en los que se aplica la directiva del SCW, aunque no se ejecuten en el equipo en que la directiva se creó originalmente. Por ejemplo, si la directiva de línea de base se aplicada a un servidor nuevo que tiene una aplicación de otro fabricante nueva, todos los servicios que instale esa aplicación se tratan según la opción que el administrador elija aquí. El SCW permite al administrador no cambiar el modo de inicio del servicio o deshabilitarlo. La deshabilitación es la opción más segura, pero se debe usar con cautela, ya que los servicios cuya ejecución no se admita explícitamente no se podrán ejecutar. Por ello, esta opción está muy indicada para entornos de alta seguridad bien administrados. Para otras partes de una organización, se recomienda no cambiar el modo de inicio. Así, en el ejemplo de Contoso, es la opción elegida. Antes de finalizar las tareas de la sección de refuerzo de los servicios, el SCW proporciona al administrador un informe sobre los servicios que se verán alterados.
Tras finalizar el aumento de la seguridad de los servicios, el SCW ofrece opciones para limitar el acceso entrante a la red. Al igual que con la lista de servicios necesarios para una función determinada, la lista de puertos necesarios para una carga de trabajo determinada se incluye en la base de datos XML de SCW.
Los administradores pueden configurar puertos adicionales si es necesario y crear reglas de puerto por servicio, como se muestra en la Figura 7. Para el servidor de línea de base de Contoso, sólo se deben admitir los servicios más básicos, por ejemplo Escritorio remoto. Todas las demás excepciones se configurarán en las directivas basadas funciones que están más abajo en la jerarquía de unidades organizativas.
Figura 7 Ver y permitir puertos
Figura 7 Ver y permitir puertos
A continuación, el SCW permite al administrador seleccionar opciones de Registro, como la firma del tráfico de archivos e impresoras. Una vez más, en la configuración de la línea de base, es recomendable elegir los valores predeterminados más seguros.
En el siguiente grupo de opciones interviene la directiva de auditoría del sistema. En la mayoría de los sistemas, la mejor opción es seleccionar Auditar actividades correctas. La auditoría de todas las actividades consume más recursos del procesador y genera gran cantidad de datos en el registro de auditoría. Si se sospecha que se ha producido un ataque o se necesita un análisis más detallado, se puede habilitar la auditoría de los errores en un equipo concreto.
Finalmente, el SCW ofrecerá al administrador opciones para reforzar IIS. Estas opciones son parecidas a las disponibles en la herramienta de bloqueo de IIS y, ahora, están integradas directamente en la directiva del SCW.
Cuando se han finalizado todos los pasos, el SCW solicita al administrador que guarde el archivo XML. El archivo guardado se debe convertir en un formato que la directiva de grupo pueda reconocer de forma nativa. Se usa el archivo Scwcmd.exe para transformar el archivo XML guardado en un GPO. Éste es el comando que se debe escribir:
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
Esta directiva se crea automáticamente en Active Directory y se puede adjuntar al nivel superior de la jerarquía de unidades organizativas de seguridad basada en funciones de Contoso.
Una vez que se ha aplicado esta directiva al nivel superior de la jerarquía, cualquier equipo que se agregue a la jerarquía de unidades organizativas heredará su configuración. Si se agrega un equipo que requiere modificaciones en esta directiva (por ejemplo, un servidor de IIS que requiera la ejecución del servicio W3SVC), los administradores de Contoso volverán a ejecutar el SCW para esa nueva función de servidor, transformarán esta nueva directiva en un GPO y adjuntarán dicho GPO a una nueva sub-unidad organizativa en la que se encuentran los servidores. Puesto que el GPO más cercano al servidor tendrá prioridad, el resultado será que todos los valores de la línea de base estarán en su lugar, excepto los que se tengan que modificar para habilitar la funcionalidad deseada de la función para esa unidad organizativa (consulte la Figura 8).
Figura 8 Aplicación de la directiva en Contoso
Figura 8 Aplicación de la directiva en Contoso
El verdadero valor de este enfoque queda claro en organizaciones más grandes o cuando se implementan muchos servidores. Una vez que se ha creado la directiva inicial del SCW y se ha adjuntado a una unidad organizativa, sólo es necesario agregar los servidores subsiguientes a esa unidad organizativa, que heredan automáticamente la directiva de seguridad apropiada. Así, una vez que el conjunto inicial de directivas se ha creado y agregado a Active Directory, la implementación de otros servidores o la sustitución de los existentes es un proceso sencillo y rápido.

Con vistas al futuro
En la próxima versión de Windows Server "Longhorn", Microsoft ha dividido el sistema operativo en gran cantidad de componentes, lo que produce una superficie de ataque simplificada y limitada. En lugar de centrarse en bloquear la instalación predeterminada mínima, los administradores usarán la herramienta Administrador de servidores para agregar las funciones y cargas de trabajo necesarias en cada servidor. Administrador de servidores funciona como el SCW, en el sentido que tiene una base de datos interna de las dependencias que permite al instalador agregar sólo las partes de funcionalidad necesarias para proporcionar el servicio de funciones deseado. Además, la seguridad basada en funciones administrada centralmente con la directiva de grupo como se describe en este artículo se mejora aún más mediante el conjunto ampliado de características controladas por GPO. En resumen, Windows Server "Longhorn" hace avanzar el concepto de SCW a un siguiente nivel, con mayor flexibilidad y una seguridad más eficaz en el producto suministrado.
Recursos del SCW
Las siguientes páginas web le ayudarán a empezar a usar el SCW:
  • Documentación del Asistente para configuración de seguridad
  • Asistente para configuración de seguridad para Windows Server 2003
  • Windows Server 2003 "Longhorn"

John Morello se licenció en LSU y ha trabajado con Microsoft seis años en distintos puestos. Como consultor sénior, ha diseñado soluciones de seguridad para empresas pertenecientes a Fortune 100 y para clientes de defensa, civiles y federales. Actualmente es director de programas en el grupo de Windows Server que trabaja en tecnologías de seguridad y acceso remoto.


 Archivos del escritorio: Cuando mi sistema es x64
Archivos del escritorio
Cuando mi sistema es x64
Wes Miller

Durante más de cinco años, Windows XP ha estado disponible de forma nativa para arquitecturas de 64 bits. Pero, a menos que usted fuera uno de los primeros usuarios del procesador Intel Itanium (Windows XP para Itanium se lanzó al mercado el mismo día que Windows XP), es posible que haya oído hablar más de él recientemente con la disponibilidad de las versiones de Windows XP y Windows.
Server 2003 para sistemas x64. El término x64 (también se usa en el sector x86-64) es el nombre genérico para la arquitectura AMD64 de AMD y EM64T de Intel. Si adquirió un PC nuevo en el último año más o menos, es muy posible que sea compatible con 64 bits, aunque funcione a 32 bits (como la mayoría de los ordenadores).
Actualmente, trabajo en una joven empresa en Austin, Tejas. Debido a la arquitectura de uno de nuestros productos, estamos interesados en aprovechar algunas ventajas específicas de la arquitectura x64 (en gran parte como el equipo de Microsoft ® Exchange 2007, que ha abierto un nuevo camino y ha empezado lanzar al mercado productos únicamente para la arquitectura x64). De forma similar, el equipo de desarrollo y pruebas que dirijo se encarga únicamente de versiones x64 de Windows ® XP y Windows Server ® 2003 para estaciones de trabajo de desarrollo, equipos portátiles, servidores y servidores de producción. Además, uso Windows XP Professional x64 Edition en mi equipo portátil con el fin de probar y depurar nuestro producto.
Curiosamente, la primera respuesta que obtengo de la mayoría de las personas cuando menciono que uso Windows de 64 bits (en especial, en un sistema portátil) es una mirada bastante confusa. Y si están familiarizadas con la informática de 64 bits, la reacción se sitúa entre la incredulidad, la nausea y el asombro, debido a la creencia comúnmente establecida de que resulta complicado reunir controladores de dispositivo para los sistemas de 64 bits. En la columna de este mes, explicaré cómo y por qué uso Windows XP y Windows Server 2003 en sistemas x64 en el modo de 64 bits, asimismo describiré algunas de las ventajas (y obstáculos) que encontrará en su implementación. También describo aspectos de la compatibilidad, migración e implementación de Windows Vista™ x64.

Breve historia
Como he indicado anteriormente, el origen de la compatibilidad con 64 bits en Windows comienza con la compatibilidad para el procesador Intel Itanium. (Aunque Windows estaba disponible para el procesador Alfa de 64 bits, realmente, nunca fue de 64 bits cuando se ejecutaba en este procesador). En Windows XP y Windows Vista, no hay compatibilidad para Itanium, de modo que la arquitectura x64 actualmente es la portadora de la antorcha de la informática de cliente de Windows de 64 bits. En estos momentos, la selección de ediciones de Windows Server 2003 disponibles para x64 es mayor que para Itanium (que se ha relegado fundamentalmente a cargas de trabajo de centros de datos de tecnología muy avanzada), una tendencia que espero mantener con la versión siguiente de Windows Server, denominada "Longhorn", cuando se lance al mercado.
La compatibilidad para Windows en la plataforma x64 empezó a estar disponible cuando se lanzó al mercado Windows Server 2003 Server Pack 1 (SP1). Aunque puede resultar confuso, en esos momentos la versión x64 de Windows XP también empezó a estar disponible (lo que significa que los productos de 32 bits y de 64 bits de Windows XP se derivaban de diferentes árboles de códigos dentro de Windows). Mientras que, actualmente, los productos de 32 bits tienen un segundo service pack disponible, la versión de 64 bits de Windows XP técnicamente no tiene un nivel de service pack (o se podría interpretar que tiene un SP1 para Windows Server 2003 integrado).
Los requisitos para ejecutar Windows de 64 bits (Windows XP, Windows Server, Windows Vista o Windows Server "Longhorn") son idénticos. Obviamente, en primer lugar, debe tener un procesador con compatibilidad para 64 bits. En el caso de AMD, esto significa contar con un sistema de uno, dos o cuatro núcleos que ofrezca compatibilidad para AMD64 (consulte amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html). Para Intel, se debe buscar un sistema de uno, dos o cuatro núcleos que ofrezca compatibilidad para EM64T, o bien, Intel 64 Architecture (consulte intel.com/technology/intel64). Tenga en cuenta los detalles de más abajo. Un sistema Intel Core Duo, por ejemplo, no está preparado para 64 bits. Un sistema Intel Core 2 Duo es compatible con 64 bits (aunque se le podría denominar simplemente Centrino Duo, como ocurre con mi equipo portátil).

La vida con x64
Una vez haya determinado si su sistema es compatible con una versión de 64 bits de Windows de forma nativa, deberá solucionar el tema de la compatibilidad de dispositivos. Lamentablemente, a pesar de que Microsoft ha animado a proveedores y OEM (a través de sesiones de WinHEC durante al menos dos años) a crear y certificar controladores de 64 bits para sus dispositivos y sistemas, el desafío más grande al que se enfrenta cuando usa Windows x64 es encontrar controladores para dispositivos de hardware o software. Según mi experiencia, la opción que ofrece los mejores resultados es ejecutar x64 en un servidor donde la compatibilidad de los dispositivos necesaria esté limitada y donde las prestaciones de x64 sean las más evidentes.
Resulta más difícil encontrar controladores para el escritorio y para los sistemas móviles. Por lo general, tendrá más posibilidades con un proveedor OEM de primera línea o con un sistema fabricado con componentes de clase empresarial (donde la probabilidad de un uso empresarial empuja al proveedor u OEM a crear y firmar controladores compatibles con x64).
Para Windows Vista, afortunadamente, está situación experimenta una gran mejora. En vez de un mundo donde la arquitectura preferida es x86 y x64 la relegada con muy pocos controladores disponibles para la mayoría del hardware, ocurre totalmente lo contrario. Para Windows Vista, un proveedor de dispositivos debe realizar pruebas de compatibilidad con los controladores x64. De hecho, no es necesario incluir también los controladores x86, aunque podría hacerse. Conceptualmente, esto significa que algún hardware (especialmente los dispositivos que se benefician de las capacidades nuevas de Windows Vista) podría ser únicamente compatible con Windows x64 y no con x86.
La realidad es que los controladores son solamente un problema con el que tropezará cuando intente ejecutar Windows de 64 bits de forma nativa. El gran problema, en primera instancia, reside en llegar hasta allí (o en migrar); pero me detendré en este aspecto más adelante.

¿Por qué 64 bits?
AMD, Intel y Microsoft no se han pasado a la arquitectura de 64 bits únicamente por diversión, evidentemente. Al hacerlo se obtienen varias ventajas clave. Como puede comprobar en la Figura 1, la mejora más importante que ofrece la arquitectura de x64 es la capacidad de administrar apreciablemente más memoria (hasta 16 terabytes (TB) frente a las 4 GB que administra Windows de 32 bits). Tenga en cuenta que, mientras que los punteros de 64 bits pueden administrar hasta ese máximo de 16 TB, las aplicaciones tienen acceso únicamente a aproximadamente 8 TB.
Figure 1 Límites del espacio de direcciones de memoria (Close Figure 1)

Espacio de direcciones | Windows de 64 bits | Windows de 32 bits
Memoria virtual | 16 TB | 4 GB
Archivo de paginación | 512 TB | 16 TB
Bloque paginado | 128 GB | 470 MB
Bloque no paginado | 128 GB | 256 MB
Caché del sistema | 1 TB | 1 GB
Por otra parte, las versiones de x64 de Windows están preparadas para la prevención de ejecución de datos (DEP), que también se encuentra disponible en sistemas x86 con compatibilidad con NX (No Execute). Con esto es posible tener una solución controlada por hardware, la cual Windows usa para evitar desbordamientos de búfer. Evita la ejecución de código desde páginas de datos en la memoria (consulte support.microsoft.com/kb/875352 para obtener más información sobre este tema).
Las versiones x64 de Windows tienen compatibilidad nativa con CPU de multiprocesador o multinúcleo, tal como ocurre con las versiones x86 de Windows. Pero una de las mayores complejidades de la creación de imágenes de un sistema Windows XP queda eliminada gracias al uso de un único nivel de abstracción de hardware (HAL) en todas instalaciones de Windows x64 (se acabaron los problemas para identificar la HAL que se está usando en sistemas que no son ACPI o en de una CPU única).
Básicamente, Windows x64 como arquitectura le permite usar la infraestructura de administración y el software de 32 bits existentes (a través de la emulación), además del software de 64 bits con la capacidad de tener acceso a la memoria considerablemente mejorada. De hecho, los únicos efectos secundarios desfavorables al pasar a Windows x64 son: la ausencia completa del compatibilidad con aplicaciones de 16 bits (incluyendo trampas como aplicaciones de 32 bits con instaladores de 16 bits); los problemas con las aplicaciones que no se ejecutan de forma confiable cuando la DEP en hardware se habilita (aunque la DEP se puede deshabilitar proceso a proceso y el equipo de Compatibilidad de aplicaciones con Windows pule algunas aplicaciones que no se ejecutan correctamente cuando la DEP está habilitada); y, finalmente, el hecho de que en Windows Vista de 64 bits todos los controladores deben tener firma digital.
Se decidió agregar este último aspecto para ayudar a evitar alteraciones con el kernel de Windows en la memoria, una técnica frecuentemente usada por los rootkits. Lo que se prevé, ya que Microsoft está fomentando entre los proveedores el desarrollo de controladores para la arquitectura x64 (con el fin de que los controladores se someta a pruebas de calidad para el hardware de Windows), es que este requisito no resulte tan temido como antiguamente.
Hay un par de otros puntos a tener en cuenta cuando se considera el uso de Windows para sistemas x64. No existen versiones de Windows XP para sistemas x64 que contengan la funcionalidad incluida en Windows Media ® Center Edition o en Windows Tablet PC Edition. Sin embargo, en Windows Vista es diferente, ya que las versiones x64 de Windows tienen la misma funcionalidad que las versiones x86.

Virtualización
No he mencionado aún la virtualización. No me refiero a Microsoft Virtual PC ni a los productos de virtualización de VMWare PC; me estoy refiriendo a la virtualización del sistema operativo para archivos ejecutables de 32 bits. En las versiones de 32 bits de Windows, las aplicaciones de 16 bits se ejecutan todas en el contexto de NTVDM (Virtual MS-DOS® Machine). Como apunté anteriormente, no hay compatibilidad para aplicaciones de 16 bits en las versiones de 64 bits de Windows. En su lugar, mientras que la mayoría de los componentes integrados de Windows se ejecutan de forma nativa como binarios de 64 bits, algunos componentes y muchos programas de terceros se ejecutan como aplicaciones de 32 bits.
Windows le ofrece un nivel de emulación totalmente nueva denominada Windows On Windows (WOW) con el fin de que estas aplicaciones de 32 bits puedan obtener una vista diferente del sistema operativo (ejecutándose eficazmente en una versión de 32 bits de Windows). Con WOW, las aplicaciones x86 ven Archivos de programa (X86) simplemente como Archivos de programa. Igualmente, %WINDIR%\SysWOW64 aparece en las aplicaciones x86 como %WINDIR%\System32. Las aplicaciones x86 ven la clave del registro HKLM\SOFTWARE\Wow6432Node como verían el nodo HKLM\SOFTWARE.
Al usar la herramienta Explorador de procesos, puede explorar otra perspectiva de virtualización. Debido a que se espera que muchas aplicaciones de 32 bits interactúen con binarios de Windows de 32 bits integrados, muchos de estos binarios se encuentran disponibles en las versiones de 64 y 32 bits. Lo podrá comprobar fácilmente si agrega una columna adicional al Explorador de procesos. En la Figura 2, advertirá dos instancias de cmd.exe: una versión de 32 bits y una versión de 64 bits. Podrá comprobar que en la instancia de 32 bits que está resaltada hay varios DLL wow64* cargados en el proceso de 32 bits. Estos muestran el proceso de la virtualización, que permite que aplicaciones de 32 bits puedan funcionar en Windows de 64 bits. Tenga en cuenta también el directorio de trabajo (ruta) que usan las versiones de 64 y 32 bits del cmd.exe.
Figura 2 El Explorador de procesos muestra las versiones de 32 y de 64 bits de cmd.exe
Figura 2 El Explorador de procesos muestra las versiones de 32 y de 64 bits de cmd.exe
Finalmente, una cosa más que se debe tener en cuenta en la virtualización: que Windows ejecute explorer.exe como una aplicación de 64 bits nativa, tiene sus pros y sus contras. La mayor desventaja es que la extensión del shell de Explorer se debe recompilar para x64 al objeto de que pueda funcionar (la mayoría no lo está).
En Internet Explorer® ocurre lo contrario: se ejecuta nativamente con la versión de 32 bits de forma predeterminada. Principalmente, esto es así para que la gran cantidad de controles ActiveX ® que se usan actualmente en Internet puedan funcionar correctamente tal cual. Si no fuera así, y debido a que las aplicaciones de 64 bits no pueden cargar DLL ni controladores en procesos de 32 bits, no existe un método eficaz para cargar controles ActiveX de 32 bits que comprendan la mayoría de los controles ActiveX actualmente disponibles, en un explorador de 64 bits, lo que implicaría que bastante contenido de Internet sería inaccesible. Para comprobar esto en la práctica, intente cargar C:\Archivos de Programa\Internet Explorer\iexplore.exe en un sistema de Windows de 64 bits y visitar cualquier sitio que cargue contenidos del control ActiveX (incluso Windows Update), como resultado obtendrá errores de distintos grados. Windows Update (véase la Figura 3) ha actualizado la forma de abrir una instancia de 32 bits de Internet Explorer en esta situación. En el futuro, habrá seguramente ciertos contenidos de control ActiveX actualizados que se podrán beneficiar de Internet Explorer de 64 bits. No obstante, debido a que hoy en día la mayoría de los sistemas de Windows ejecutan exclusivamente Windows de 32 bits, no es fundamental que los contenidos de ActiveX estén actualizados. No creo que esto cambien durante bastante tiempo.
Figura 3 Los controles ActiveX de 32 bits producen errores en Internet Explorer de 64 bits
Figura 3 Los controles ActiveX de 32 bits producen errores en Internet Explorer de 64 bits

Windows x64 en Pluck
Al principio de este artículo, mencioné que en Pluck hemos iniciado la transición a Windows x64. Lo henos hecho en tres versiones diferentes de Windows: Windows XP Profesional x64 Edition, Windows Server 2003 Enterprise Edition x64 y Windows Vista x64.
Nuestra empresa es lo suficientemente pequeña de modo que, cuando comenzamos a desarrollar nuestro producto más reciente, pudimos empezar a migrar hacia Windows x64 con el fin de beneficiarnos de sus ventajas. Al hacerlo de esta forma, todo el hardware que pedimos era compatible con x64. De hecho, las capacidades de memoria ampliada de x64 junto con la virtualización nos permitió ejecutar nuestro producto de la forma que deseábamos. Todos los servidores físicos se ejecutaban como servidores virtuales de 64 bits en un servidor host de 64 bits. Cada servidor host tiene 16 GB de RAM dividida entre los servidores virtuales hospedados en ella (por lo general, 2 GB para cada equipo virtual de almacenamiento provisional o VM y 3 GB para cada VM de producción).
Si se usan sistemas de nivel 1 y también hardware virtualizado, se puede conseguir prácticamente el 100 por cien de compatibilidad de dispositivos. Mi equipo portátil, por ejemplo, tiene tres dispositivos que no tienen controladores x64 disponibles. Todos ellos parecen dispositivos de tipo plano anterior que no son fundamentales y el rendimiento del sistema es correcto sin su presencia. Curiosamente, una instalación de Windows Vista RC1 x64 tuvo como resultado exactamente la misma compatibilidad de dispositivos; aunque con el logotipo de apto para Windows de mi sistema, seguramente el proveedor suministrará en poco tiempo incluso estos controladores que faltan.
Debido a que nuestro uso de los sistemas se limita principalmente a Microsoft Office, Visual Studio® y diversas herramientas adicionales que se usan en el proceso de desarrollo y creación, no contamos con muchas aplicaciones heredadas que ocasionen problemas de compatibilidad en la migración. Mientras que una parte importante de nuestra empresa usa versiones de 32 bits de Windows, hemos iniciado la migración hacia 64 bits con nuevo hardware y ha resultado ser relativamente sencillo.

Implementación y migración a x64
Existen algunas consideraciones a tener en cuenta en lo que respecta a la implementación. Microsoft ofrece una versión de Windows Preinstallation Environment (Windows PE) específicamente para la arquitectura x64. Sin embargo, desde que existe paridad x86 en sistemas x64, puede querer usar Windows x86 PE para su implementación, en particular, si está usando una solución de creación de imágenes. Si implementa Windows XP con una instalación desatendida, Windows PE tendrá que ser específico para la arquitectura, ya que winnt32.exe debe ejecutarse en la misma arquitectura que se está implementando. Debido a que Windows PE no tiene un nivel de compatibilidad de 32 bits y winnt32.exe en x64 es una aplicación de 64 bits, Windows de 32 bits requiere Windows PE de 32 bits. Lo mismo se aplica a las versiones de 64 bits de Windows, que requieren Windows PE de 64 bits.
En este sentido, con los Servicios de instalación remota (RIS) es diferente, y por ello en Pluck usamos RIS. RIS, empezando con Windows Server 2003 SP1, también puede implementar x64 así como x86 o las arquitecturas de Itanium de Windows. Cuándo un sistema x64 se conecta a un servidor de RIS, el servidor (en la configuración predeterminada) ofrecerá imágenes RISetup o RIPrep x86 y x64. RIS también se puede configurar para que ofrezca imágenes x86 de clientes x64 o imágenes x64 exclusivamente. Se ofreció esta selección como valor predeterminado para proporcionar el mejor uso posible con hardware x64.
Tenga en cuenta que aún no he mencionado las actualizaciones. Tengo mis buenos motivos. Desafortunadamente, la actualización de la totalidad de un sistema operativo de x86 a x64 es una tarea masiva. Por este motivo y debido a la limitada implementación de Windows XP Professional x 64 Edition, no puede actualizar a Windows XP x64 desde ninguna versión x86, ni tampoco puede actualizar desde ninguna versión de Windows XP (x86 o x64) a Windows Vista x64. Windows Vista en sistemas x64 es, tal como antes lo fue Windows XP Professional x64 Edition, un producto de instalación limpia únicamente. Por este motivo, muchas empresas deciden migrar a x64 sólo cuando es necesario realizar una actualización de hardware; una estrategia similar a la que se espera que emprendan muchas empresas con Windows Vista (un cambio doble, lo que tiene más sentido).
Pero esto no quiere decir que las personas o las empresas que pasen de Windows x86 a Windows x64 no tengan herramientas fácilmente disponibles: sí que las tienen. Las versiones de la Herramienta de migración del estado del usuario (USMT) para Windows XP y Windows Vista no se han ampliado para ser compatibles con la migración (frente a una actualización en banda del sistema operativo) desde una instalación de Windows a otra. Este es el método predominante que usan hoy en día la mayoría de las empresas para implementar Windows a pesar de todo (empezando desde cero pero manteniendo todos los datos, incluso en el mismo equipo), de forma que usar el mismo mecanismo para cambiar a Windows en una arquitectura totalmente nueva no debería representar más problemas que antes.

Conclusión
A pesar de que la migración gradual a x64 de nuestra pequeña empresa pueda resultar considerablemente más fácil que el proceso de migración de envergadura al que se enfrentan las empresas más grandes, todos los profesionales de TI deben empezar a considerar un posible cambio a la arquitectura x64. La realidad es que aunque la arquitectura x86 y la versiones nativas x86 de Windows seguirán estando presentes en los próximos diez años, la arquitectura x64 es ciertamente el futuro de la informática en la empresa. Con el cambio completo de Microsoft a la compatibilidad con x64 para Exchange Server y otros productos, debería empezar a ver dónde encajarían los sistemas x64 en su arquitectura y cuál es su sitio en su plan de migración a Windows Vista, esté o no usando actualmente Windows XP o Windows Server 2003 de forma nativa en sus sistemas x64.

Wes Milleres un administrador de desarrollo de Pluck (www.pluck.com) en Austin, Texas. Anteriormente, trabajó en Winternals Software y en Microsoft como administrador de programas y administrador de producto para Windows. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.


 Dentro de Microsoft.com: Uso de los Servicios de federaci&#243;n de Active Directory (ADFS)
Dentro de Microsoft.com
Uso de los Servicios de federación de Active Directory (ADFS)
Jim Guthrie

En Microsoft proporcionamos una extranet para dar a nuestros socios acceso a importantes recursos internos. La arquitectura de la extranet necesita que cada participante ajeno a la organización tenga una cuenta de dominio única para este espacio. Esta cuenta la crean y administran empleados de Microsoft, en lugar de los
socios, por razones obvias. Sin embargo, aunque es funcional, la experiencia para el usuario puede ser poco satisfactoria y la carga en Microsoft para administrar todos esos usuarios de asociados consume muchos recursos.
Aquí se muestra cómo funciona la extranet en estos momentos. Cuando un cliente o un socio inician la sesión en una aplicación, se solicita que introduzcan sus credenciales. Durante la misma sesión, si ese usuario decide obtener acceso a un recurso diferente se le pedirán de nuevo sus credenciales. Esto continúa mientras salte de un recurso al siguiente. Si el usuario ha iniciado sesión en una única aplicación que usa varios recursos, como una base de datos financiera, tendrá que autenticarse en cada uno de los recursos de forma independiente. Esto puede ser un procedimiento incómodo y molesto para los usuarios.
Afortunadamente, mediante los Servicios de federación de Active Directory® (ADFS), podemos resolver el problema de la múltiple autenticación muy fácilmente, y usted también. ADFS es un componente R2 de Windows Server® 2003 que facilita una confianza entre dos o más organizaciones para permitir compartir múltiples recursos a la vez que se mantiene la capacidad de cada organización de administrar su propio conjunto de usuarios. En esta columna muestro cómo Microsoft pretende usar ADFS para resolver el problema de la extranet de múltiples recursos, que le proporcionará la información que usted necesita para implementar una solución semejante. Sin embargo, antes de entrar en detalles, eche un vistazo a la Figura 1 para familiarizarse con la terminología básica de ADFS.
Figure 1 Terminología ADFS (Close Figure 1)

.
Definición | de término
Federación | Un par de territorios o dominios que han establecido una confianza de federación de Active Directory.
Recurso de Servicio de Federación (FS-R) | Dirige las peticiones de autenticación entrantes al FS-A y a los recursos deseados.
Cuentas de servicio de federación (FS-A) | Proporcionan un token de cuenta para ser autenticado en FS-R.
Proxy del servicio de federación (FS-P) | Proporciona un nivel de separación entre los servidores FS y el tráfico entrante de Internet
Solicitud | Una instrucción que genera un servidor (por ejemplo, nombre, identidad, clave, grupo, privilegio o capacidad) acerca de un cliente.
Detección del territorio | Cada FS-A tiene un dominio o un territorio, en el que se guardan las credenciales de inicio de sesión. La detección del territorio determina qué FS-A se usa para la sesión de ADFS.

Una Solución ADFS
Cuando un usuario intenta obtener acceso a una aplicación de notificaciones ADFS, el explorador se envía al servicio de Federación de recursos (FS-R) para la detección del territorio. Aquí el usuario seleccionará el conjunto de credenciales que usará durante la sesión. En función del territorio que haya elegido el cliente, será redireccionada a continuación al servidor de Cuentas del Servicio de federación (FS-A). Es en este servidor donde recibirá una cuenta de token válida (en una cookie) que está basada en las credenciales que ella introdujo en forma de Windows Live™ ID (anteriormente una cuenta de Passport), Autenticación integrada de Windows o autenticación SSL (véase la Figura 2). En este modelo, es cada organización la que deberá mantener su propio servidor de federación de cuenta. En el caso de los servidores de socios de Microsoft, esto quita la carga sobre Microsoft.com para administrar cada cuenta en el entorno. Por supuesto, si usted implementa ese nivel de responsabilidad deberá seleccionar cuidadosamente las organizaciones con las que se asocie y asegurarse de que administren activamente su información de cuenta.
Figura 2 Flujo ADFS
Figura 2 Flujo ADFS
La siguiente parada en la ruta es volver al servidor FS-R para intercambiar el token de la cuenta por un token de recurso. En nuestra configuración, este token contiene una lista completa de los permisos que han sido concedidos al usuario a través del proceso de mapeo de notificaciones que se lleva a cabo en el FS-R. Una vez que se ha recibido el token, ese usuario obtiene la posibilidad de inicio de sesión único (SSO) sobre las aplicaciones de notificaciones ADFS mientras la sesión esté abierta o hasta 24 horas de forma predeterminada (esta ventana es configurable). El resultado es que usted ha habilitado SSO a estas aplicaciones de notificaciones ADFS, lo que deriva en una experiencia más segura y eficiente para el cliente. Para obtener un tutorial completo del proceso de autenticación de ADFS, consulte el artículo de Matt Steele en la edición de julio de 2006 de TechNet Magazine titulado "Simplificando el inicio de sesión único con ADFS".
Para mantener la seguridad de los recursos corporativos de Microsoft, hemos aislado el lado de Internet de la extranet del lado corporativo, lo que significa que cada servidor es potencialmente de doble-pertenencia. Se permite una confianza de un solo sentido a los usuarios corporativos internos y se usan los servidores para proporcionar la protección necesaria. Tenemos también un dominio independiente para el espacio de la extranet donde ofrecemos a usuarios externos el acceso a los recursos que necesitan.
El equilibrio de carga y los cambios en los archivos de la directiva ADFS fueron dos áreas importantes de problemas durante la implementación. El equilibrio de la carga fue un desafío tanto a nivel global como local. Inicialmente en producción usaremos el equilibrio de carga global de nuestros socios de red de entrega de contenido (CDN) Akamai o Savvis para los clústeres de servidor web cliente en dos regiones. Esto asegurará la disponibilidad del sistema para usuarios finales incluso en el improbable evento de que se desconecten un par de servidores regionales. Esto se consigue con la automatización de la conmutación por error basada en servicios de control de estado ofrecidos por los CDN. Además, tenemos la capacidad de agregar fácilmente más clústeres en el futuro. Como un ahorro de costos, nuestras implementaciones de preproducción han elegido no usar el servicio CDN.
En el nivel regional hemos emparejado los servidores para la conmutación por error a través de clústeres de equilibrio de carga de red (NLB). No usamos ninguna característica especial de equilibrio de carga, de modo que esto podría haber sido conseguido fácilmente mediante hardware. Sin embargo, de nuevo utilizamos NLB para obtener ahorro en los costos. Esta configuración ofrecerá suficiente estabilidad para asegurar un tiempo de actividad del 99,9 por ciento en todos los entornos compatibles.
Otro desafío que afrontamos fue el de comprobar que el archivo de la directiva de ADFS, la espina dorsal de ADFS, fuese distribuida correctamente a través de nuestro entorno y que los cambios realizados en el mismo también sean replicados. Para lograr esto, usamos otra característica integrada de Windows Server 2003 R2 (Replicación de sistema de archivos distribuidos (DFS-R)), un nuevo motor de replicación multi master basado en estado. En cada uno de los servidores back-end hemos habilitado una pertenencia a grupos DFS-R con una replicación de malla completa de 24 horas. Ahora, ocurra donde ocurra el cambio en el archivo de la directiva, se distribuirá a todos los servidores. Mientras controlemos quién puede modificar el archivo, tendremos un servicio estable de alta disponibilidad.
Hemos tratado de asegurar que todos los cambios se realicen a través del complemento de ADFS. Sin embargo, en la práctica vimos que ocasionalmente debemos actualizar este archivo manualmente. Al actualizar manualmente es importante recordar que ADFS mantiene un seguimiento de la versión de este archivo. Por lo tanto, usted debe incrementar el archivo para que sus cambios se reflejen en el entorno:
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
También tiene que recordar que, como todo XML, el archivo de directivas XML distingue entre mayúsculas y minúsculas. A través del archivo de directivas XML hay muchas referencias a las aplicaciones u otros servidores de ADFS y en todos los casos se deben copiar al pie de la letra de servidor a servidor. Tenga en cuenta los siguientes ejemplos comunes donde el primero, RevocationCheckFlags, se introdujo manualmente y el segundo es una URL de aplicación de confianza modificada desde la interfaz de usuario:
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
Para un nivel de seguridad adicional usamos otro componente de ADFS, el Proxy de servicio de Federación (FS-P), que asegura que en los FS-R se quite un nivel del acceso directo de solicitudes entrantes de Internet. Una manera singular mediante la que hemos implementado proxies en Microsoft.com es a través del uso de un solo conjunto de proxies para hospedar varios entornos ADFS en nuestra área de preproducción. Curiosamente, durante la evolución inicial de la tecnología, descubrimos que necesitábamos hacer una simple modificación en una clave de registro para que esto sucediera. La clave se encuentra en HKLM\Software\Microsoft\WebSSO. Cambiando simplemente el valor del directorio inicial en esta clave podrá usar el proxy para varios entornos. El valor predeterminado fue:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
Para intercambiar los entornos, la clave cambiaría de la siguiente manera:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
La creación de un archivo por lotes puede simplificar la administración de este proceso. Desafortunadamente la versión actual del complemento MMC para ADFS no admite intercambio de entornos, ya que hay una relación de uno a uno entre el proxy y el recurso o el servidor de cuentas. Esta es la única manera de maximizar la utilización de los servidores proxy. El resultado final es que supone un gran ahorro de costos ya que limita el número de servidores físicos necesarios por muchos entornos diferentes que usted elija hospedar.
Desde el punto de vista de la arquitectura nosotros ejecutamos nuestro entorno de preproducción con equipos virtuales (otra medida de ahorro de costos). Esto elimina la necesidad de comprar y albergar seis servidores adicionales. Hasta la fecha, no hemos tenido problemas de rendimiento. Sin embargo, para satisfacer la creciente demanda en el entorno de producción hemos elegido usar equipos físicos de mayor rendimiento.

No sólo para Active Directory
Microsoft.com no sólo usa cuentas de Active Directory para la autenticación, sino también hemos integrado correctamente cuentas de Windows Live ID. Hemos visto que usando Windows Live ID (WLID) 4.5, podemos usar una cuenta individual Windows Live ID para delegar el acceso a recursos de Microsoft utilizando una transformación de notificaciones personalizadas. Esto es una gran victoria para lograr la autenticación SSO ya que ya no necesitaremos una cuenta de dominio específica.

Desafíos pendientes
El mayor desafío al que nos enfrentamos en este momento es la administración de ADFS para compartir certificados de firma de token. Usamos certificados estándar que normalmente siguen siendo válidos durante un año sin necesidad de renovación. En el momento de la renovación cada uno de los servidores apropiados tendrá que ser actualizado en concordancia, lo que tendrá un efecto considerable en los FS-R. Aunque es fácil de manejar con 15 ó 20 federaciones, la escala en la que nos gustaría pensar es, por lo menos, de cientos o miles. Esto requeriría de personal a jornada completa para la administración de certificados SSL para un solo entorno. Tenemos varios equipos buscando los mejores métodos para automatizar esta solución pero no se ha decidido una línea de acción.
Otro desafío pendiente es que no todas las aplicaciones incluyen notificaciones ADFS de serie. Será necesaria cierta programación para que los sitios aprovechen la oportunidad de ADFS. Trabajamos junto con el equipo de Microsoft® Office SharePoint® Services para asegurar que la siguiente generación de SharePoint sea compatible con nuestras necesidades de implementación para ADFS.

Conclusión
Hay varios factores que considerar a la hora de tomar la decisión de migrar a un modelo ADFS. Uno es el número de recursos a los que obtendrán acceso los clientes. El proceso de configuración de una confianza federada entre organizaciones puede ser una tarea trivial, pero escribir, revisar y ejecutar directivas de acceso aceptables lleva tiempo y esfuerzo. Por tanto si usted tiene sólo un recurso al que sus clientes obtengan acceso, tendrá que decidir si el esfuerzo merece la pena. Sin embargo, a medida que crece el número de recursos aumentan también las prestaciones.
Si desea más información, consulte Introducción a ADFS y Servicios de federación de Active Directory (ADFS): Una ruta hacia la identidad federada y la administración de acceso.

Jim Guthrietrabaja para Microsoft en el equipo de Operaciones de Microsoft.com donde, además de desafrrollar su trabajo con ADFS, es Ingeniero de sistemas en el equipo de soporte de la plataforma Enterprise Portal.


 Notas de campo: Las alegr&#237;as y las penas de aprende
Notas de campo
Las alegrías y las penas de aprende
Mark D. Scott

Recuerdo cómo eran las cosas cuando aparecía un producto nuevo, la emoción de ser uno de los primeros en conocer la tecnología más reciente, estudiar el producto de cabo a rabo, aprender cómo funcionaba, hacerlo funcionar. Me encantaba ser uno de ellos, conocer lo nuevo, el mago al que se dirigen los demás para descubrir el secreto.
Pero, en algún momento, la alegría se ensombreció. No sé bien qué sucedió. A lo mejor la perdí con la frustración de tratar de hacer que aplicaciones vitales funcionaran a las 3 de la mañana. A lo mejor la dejé en el suelo con la documentación de producto que no entendí cuando el servidor de correo se trasladó al sur (cuando un servidor era suficiente). A lo mejor me estoy haciendo viejo y cínico. Da igual. Ya no me emociona perder noches, como ocurría hace unos años. Pero eso no quiere decir que esté bien dejar de aprender. No hace mucho que esto me volvió a quedar claro.
Recientemente he actualizado a Microsoft® Outlook® 2007 y la verdad es que me encanta. Además, estoy suscrito a MSN® Premium; mi ISP ofrece la suscripción como parte de sus servicios. En la versión anterior de Outlook, necesitaba un software especial, llamado conector, para obtener acceso a mi dirección de correo electrónico de MSN. Este conector de software no funcionaba con Outlook 2007, de modo que me puse en contacto con MSN. MSN me dijo que hablara con mi ISP, que, al final, me dijo que no admitía el conector de MSN de Outlook en Outlook 2007. Vueltas y vueltas, correo electrónico, chat, voz... me costó una eternidad conseguir esta información.
De repente pensé, a lo mejor ya no necesito el conector. Inicié Outlook 2007 y cree una nueva conexión a MSN, sin usar el software de conector. Outlook fue a Internet, encontró el servidor, y configuró la cuenta sin ningún problema. Además, hizo lo mismo para varias otras cuentas POP3. Así que obtuve acceso a mi correo electrónico y descubrí una magnífica característica nueva del producto.
Todo esto tiene una moraleja. Si alguien del departamento de soporte técnico se hubiera molestado en usar el producto nuevo, probablemente me podría haber dicho que no necesitaba el conector y los dos nos habríamos ahorrado mucho tiempo.
Quizás más importante: si hubiera estudiado el producto en primer lugar, es probable que yo mismo hubiera encontrado la solución. Pero quería que alguien me diera la respuesta. Como nadie se había molestado en explorar algo que, a fin de cuentas, era importante, todos perdimos mucho más tiempo que si cada uno de nosotros hubiera estudiado y resuelto el problema a nuestra manera, que es exactamente lo que acabé por hacer.
Los cambios en tecnología prueban que muchas de las cosas que asumimos son equivocadas. Para trabajar como profesionales de TI, debemos estar libres de prejuicios. El conocimiento que más nos cuesta adquirir es el que, sin duda, la tecnología va a sustituir: sustituir conocimientos es lo que hace que la tecnología sea fácil de usar. No debemos pensar que nuestros conocimientos más profundos van a estar siempre en primera línea. La primera línea está, no en la acumulación de hechos sobre el uso de la tecnología que quedan anticuados, si no en la capacidad de adquirir nuevos conceptos y técnicas. El aprendizaje continuado, como parte de nuestra rutina diaria, pone a punto nuestras nuevas capacidades. Con la gran cantidad de productos que siguen apareciendo todos los días, el aprendizaje debe formar parte de nuestro estilo de vida.
Si desea ponerse en contacto conmigo, puede enviarme un mensaje de correo electrónico a mi cuenta de Microsoft o de MSN: con Outlook 2007 puedo recibir el correo electrónico de ambas.

Mark D. Scottes Consultor sénior de Microsoft Consulting Services. Trabaja muy de cerca con los clientes para ayudarles en el diseño y creación de aplicaciones centradas los datos a gran escala. Puede ponerse en contacto con Mark en granddaddy2002@msn.com o mascott@microsoft.com.


 Confidencial de Windows: El poder de los errores
Confidencial de Windows
El poder de los errores
Raymond Chen

En Windows 95 , se podía ir a la página de solución de problemas y seleccionar la opción para deshabilitar las confirmaciones de búferes sincrónicas. Pero, ¿sabe usted lo que hacía esta casilla de verificación? ¿O por qué?
El comportamiento normal de la función Commit de MS-DOS® consistía en vaciar todos los datos no escritos de un archivo concreto al disco, y esperar a que los datos se hubieran confirmado como escritos antes de volver. Si estaba activada la opción para deshabilitar las confirmaciones de búferes sincrónicas, la llamada se devolvía inmediatamente, en lugar de esperar a que se escribieran los datos. Esto, por supuesto, era una infracción de la especificación de la función, que requiere que la llamada no se devuelva hasta que se han escrito los datos. Así se aumentaba el riesgo de lo que en el artículo 139669 de Knowledge Base se denomina eufemísticamente "problemas de integridad de archivo", ya que hacía que el programa que emitía la solicitud de vaciado pensara que los datos estaban seguros en el disco, cuando en realidad no lo estaban.
Un programa de base de datos puede usar la función Commit para establecer puntos en que el estado del archivo del disco es el que el programa espera que sea. Si se produce una interrupción de suministro eléctrico en el equipo durante una actualización, el programa de base de datos puede usar la información registrada en el último punto de confirmación para restablecer la integridad de la base de datos. Si la función Commit se devolvía inmediatamente antes de que se terminara la confirmación, se perdía este punto de control de integridad. El resultado era que la base de datos quedaba dañada.
¿Por qué estaba disponible esta opción disponible si las consecuencias eran tan negativas? La causa: un error de Windows® 3.11.
Figura 1 Habilitar el comportamiento con errores en Windows Server 2003
Figura 1 Habilitar el comportamiento con errores en Windows Server 2003
En Windows 3.11 apareció el “acceso a archivos de 32 bits", una implementación de 32 bits de la interfaz de E/S de archivos de nivel inferior. Pero la implementación de la función Commit tenía un error que omitía eficazmente las solicitudes para vaciar los búferes de archivos. Si se ejecutaba en Windows 3.11 un programa que vaciaba sus búferes de archivos, la llamada al vaciado no tenía efecto. En consecuencia, si se perdía el suministro de energía justo en el momento menos indicado, la base de datos quedaba dañada.
Los desarrolladores que trabajaron en el sistema de archivos de Windows 95 corrigieron este error, pero empezaron a llegar otros informes de errores. El programa de contabilidad de un usuario empezó a funcionar muy despacio. Después, el programa de base de datos de otro usuario hizo lo mismo. ¿Qué estaba pasando?
Resultó que estos programas emitían constantes llamadas de vaciado. Los programadores advirtieron que las llamadas de vaciado eran muy rápidas en Windows 3.11, así que las agregaron por todas partes en su programa. Escribir un byte, vaciar. Escribir una cadena, vaciar. Como los vaciados eran tan rápidos, la aplicación podía confirmar los datos en el disco después de cada operación, sin que el rendimiento se viera afectado. Pero una vez que en Windows 95 se corrigió el error, estos programas empezaron a tener un rendimiento muy lento, porque las llamadas a la función Commit, de repente, hacían trabajo real.
Por supuesto, si el equipo del sistema de archivos no hubiera hecho nada, estos programas hubieran seguido siendo muy lentos y los usuarios habrían llegado a la conclusión de que el problema era Windows 95. "Windows 95 es lentísimo", se decían unos a otros. Por otro lado, si el sistema de archivos volvía a tener el comportamiento de Windows 3.11, habrían vuelto a introducir un error que podría conducir a esos molestos "problemas de integridad de los archivos".
Concluyeron que la solución era dejar la corrección del error y agregar una casilla de verificación (casi oculta en la página de solución de problemas) para volver al comportamiento de Windows 3.11 para los usuarios que ejecutaban programas y se encontraban los problemas derivados de dicha corrección.
Más adelante, la historia se volvió a repetir. En Windows Server® 2003, el equipo de E/S descubrió un error en que las solicitudes etiquetadas como Forced Unit Access (FUA) perdían la etiqueta de FUA y se ejecutaban como E/S normal. Era como una nueva manera de omitir las solicitudes de vaciado. Corrigieron el error, pero mantuvieron la opción de volver al comportamiento anterior con el error. La versión de Windows Server 2003 de esta casilla se llama "Habilitar rendimiento avanzado", pero ahora ya sabe que, en realidad, significa "Restaurar el comportamiento anterior con el error".

Raymond Chen The Old New Thing, y su libro del mismo título (Addison-Wesley, 2007) tratan de la historia de Windows y la programación de Win32. Él respeta la ley al pie de la letra.