 TechNet Magazine February 2007
TechNet Magazine February 2007
FEBRUARY 2007
Administración de Windows

Este mes, Mark Russinovich profundiza en el kernel de Windows Vista para explicar los nuevos algoritmos de medida de rendimiento de subprocesos y procesos, que ofrecen una imagen más precisa del tiempo de CPU que se usa. También trata el Servicio Programador de aplicaciones multimedia que ofrece a los usuarios una experiencia de reproducción más continua mediante una mejor administración de tareas en segundo plano como antivirus e indización de contenido.

Este mes también nos centramos en las capacidades de delegación de Active Directory y las plantillas de directiva de grupo de Windows Vista, de manera que pueda aprovechar como nunca la directiva de grupo. Y, por supuesto, todos nuestras secciones habituales se incluyen este mes: The Cable Guy, The Scripting Guys y Confidencial de Windows.
CARACTERÍSTICAS
Administración de Windows Dentro del kernel Windows Vista: parte 1

Con Windows Vista, los cambios del kernel del sistema operativo ofrecen avances en muchas áreas, que van de la administración de la memoria a la confiabilidad pasando por la seguridad. Empezamos esta serie con una introducción al modo en que el kernel ofrece mejoras en las áreas de procesos, subprocesos y E/S.

Mark Russinovich Delegación de autoridad en Active Directory

La implementación de la delegación en Active Directory puede mejorar la seguridad y simplificar las tareas de administración, y el inicio puede ser más fácil de lo que piensa. Aquí tiene algunos modelos de delegación simples que funcionarán en la mayoría de infraestructuras de TI con pequeños cambios.

Joel Yoker y Rob Campbell Inmersión en las nuevas plantillas de directiva de grupo de Windows Vista

Windows Vista presenta cambios considerables en las plantillas de directiva de grupo. Descubra todo lo que necesita saber acerca del formato nuevo, denominado ADMX, y cómo estos cambios mejorarán la administración de configuraciones del sistema.

Darren Mar-Elia Guía de solución de problemas de directiva de grupo

Llegar al fondo de problemas de directiva de grupo puede ser un proceso difícil, pero si se conoce cómo funciona la directiva de grupo y dónde pueden surgir problemas, se simplifica el proceso. Esta introducción lo ayudará a solucionar problemas de directiva de grupo como si se tratara de un gurú.

Derek Melber Supervisión de Active Directory con MOM

Los módulos de administración para Microsoft Operations Manager 2005 permiten supervisar de forma más eficaz la infraestructura de TI. Descubra cómo estos cinco módulos de administración pueden ayudarle a vigilar el estado, la seguridad y la confiabilidad del entorno de Active Directory.

John Hann Juegos en un entorno seguro

Tanto si está ocupado en el trabajo como si está jugando una partida importante en casa, la ejecución como usuario limitado tiene muchas ventajas de seguridad. Desgraciadamente, algunos juegos no funcionan si no se los ejecuta como administrador. Aquí tiene información sobre algunos problemas comunes y sus soluciones.

Matt Clapham
COLUMNAS
Nota del editor

En el interior

Joshua Trupin Caja de herramientas

Nuevos productos para profesionales de TI

Greg Steen Q&A de SQL

Tamaño de base de datos, creación de reflejos, transacciones marcadas y otros temas

Editado por Nancy Michell Utility Spotlight

Inventario de directiva de grupo

Greg Steen The Cable Guy

Compatibilidad con QoS en Windows

Joseph Davies 		Windows PowerShell

Una línea de scripting cada vez

Don Jones ¡Hola, chicos del scripting!

Persiguiendo coches... y el XML

Los chicos del scripting de Microsoft Vigilancia de seguridad

Implementación de EFS: parte 1

John Morello Archivos del escritorio

Ampliación de Windows PE

Wes Miller Notas de campo

Simplemente deja de funcionar

R'ykandar Korra'ti Confidencial de Windows

Una bendición "mixta"

Raymond Chen


 Administraci&#243;n de Windows: Dentro del n&#250;cleo de Windows Vista: Parte 1
Administración de Windows Mark Russinovich

Dentro del núcleo de Windows Vista: Parte 1
Resumen:
  • Programación y prioridad de subprocesos
  • Vínculos simbólicos basados en archivos
  • Cancelación de operaciones de E/S

Ésta es la primera parte de una serie sobre las novedades en el núcleo de Windows Vista. En este artículo analizaré los cambios producidos en las áreas de procesos y subprocesos y en E/S. Las siguientes entregas incluirán la administración de la memoria, inicio y apagado, confiabilidad y recuperación y seguridad.
El ámbito de este artículo comprende los cambios al núcleo de Windows Vista™ únicamente, en concreto a Ntoskrnl.exe y sus componentes estrechamente asociados. Recuerde que existen muchos otros cambios considerables en Windows Vista que no están relacionados con el núcleo propiamente y que, por tanto, no se explicarán. Entre estos se incluyen las mejoras al shell (como la búsqueda integrada de escritorio), trabajo en red (como la nueva pila IPv6 y un servidor de seguridad bidireccional) y un modelo de gráficos de próxima generación (como Aero™ Glass, Windows® Presentation Foundation, el Administrador de ventanas del escritorio y el nuevo modelo de controlador de gráficos). Tampoco se han incluido los nuevos entornos de controlador de modo de núcleo y de modo de usuario de Windows (UMDF y KMDF), ya que se pueden instalar en niveles de versiones anteriores de Windows.

Cuenta de ciclos de la CPU
Windows Vista incluye varias mejoras en el área de procesos y subprocesos entre las que se incluyen el uso del contador de ciclos de CPU, para una asignación más justa de CPU, y el nuevo Servicio programador de aplicaciones multimedia (MMCSS) que ayuda a las aplicaciones de medios a proporcionar una reproducción libre de errores.
Todas las versiones de Windows NT® hasta e incluyendo Windows Vista programan una rutina de interrupción de temporizador de intervalos para que se ejecute aproximadamente cada 10 o 15 ms (milisegundos), en función de la plataforma de hardware. La rutina comprueba en qué subproceso se ha interrumpido y actualiza las estadísticas de uso de la CPU del subproceso como si dicho subproceso se hubiera ejecutado durante todo el intervalo, mientras que en realidad podría haber empezado a ejecutarse antes del final del intervalo. Es más, quizá se podría haber asignado técnicamente el subproceso a la CPU, pero no tuvo ocasión de ejecutarse, ya que se han ejecutado rutinas de interrupción de software y hardware en su lugar.
Si bien la cuenta basada en el reloj podría ser correcta para las herramientas de diagnóstico que informan sobre el uso de la CPU del proceso y los subprocesos, el uso de ese método por parte del programador de subprocesos puede provocar una asignación de CPU incorrecta. De forma predeterminada, en las versiones de cliente de subprocesos de Windows se permite ejecutar hasta 2 tics del reloj (6 en primer plano). Sin embargo, puede que el subproceso no disponga de tiempo prácticamente en la CPU o que disponga de hasta 6 tics (18 en primer plano), en función de su comportamiento y otras actividades del sistema.
En la Figura 1 se muestra la incorrección que se puede producir si dos subprocesos que tienen la misma prioridad pasan a estar disponibles para su ejecución al mismo tiempo. El subproceso A se ejecuta hasta el próximo vencimiento del intervalo de tiempo en el que el programador asume que se ha ejecutado para todo el intervalo y por tanto decide que el turno del subproceso A ha terminado. Además, el subproceso A se carga incorrectamente para la interrupción que se ha producido en su turno. En el intervalo siguiente, el programador escoge hacerse cargo del subproceso B y ejecutarlo para un intervalo completo.
Figura 1 Programación incorrecta de subprocesos
Figura 1 Programación incorrecta de subprocesos
En Windows Vista, el programador utiliza el registro del contador de ciclos de los procesadores modernos para realizar un seguimiento preciso de cuántos ciclos de CPU ejecuta un subproceso. Al calcular cuántos ciclos puede ejecutar la CPU en un intervalo de reloj, puede repartir de forma más precisa los turnos en la CPU. Además, el programador de Windows Vista no cuenta la ejecución interrumpida en relación con el turno de un subproceso. Esto significa que en Windows Vista un subproceso siempre obtendrá por lo menos su turno en la CPU y nunca más de un intervalo de reloj de ejecución adicional, dando como resultado una mayor corrección y un comportamiento de aplicaciones más determinista. En la Figura 2 se muestra cómo Windows Vista responde a la situación mostrada en la Figura 1 proporcionándoles a ambos subprocesos por lo menos un intervalo de tiempo de ejecución.
Figura 2 Programación basada en ciclos de Windows Vista
Figura 2 Programación basada en ciclos de Windows Vista
En la barra lateral "Watching Process CPU Usage" (en inglés) se muestra cómo puede supervisar el uso de ciclos de la CPU de procesos con la utilidad Explorador de procesos.

Servicio programador de aplicaciones multimedia
Los usuarios esperan que las aplicaciones multimedia, incluidos los reproductores de música y vídeo, ofrezcan una experiencia de reproducción perfecta. Sin embargo, la demanda de CPU por parte de otras aplicaciones que se ejecutan simultáneamente, como el antivirus, la indización del contenido o incluso el cliente de correo, puede dar como resultado desagradables interrupciones momentáneas. Para ofrecer una mejor experiencia de reproducción, Windows Vista presenta MMCSS para administrar las prioridades de CPU de los subprocesos multimedia.
Una aplicación multimedia, como el Reproductor de Windows® Media 11, se registra con MMCSS mediante API nuevas que indican sus características multimedia, que deben coincidir con una de las enumeradas por nombre bajo la siguiente clave del Registro:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks

Figura A Visualización del tiempo de CPU y delta de ciclos en el Explorador de procesos (Hacer clic en la imagen para reducirla)
Figura A Visualización del tiempo de CPU y delta de ciclos en el Explorador de procesos
Figura A Visualización del tiempo de CPU y delta de ciclos en el Explorador de procesos (Hacer clic en la imagen para ampliarla)

Figura 3 Definición de tareas de audio del programador de aplicaciones multimedia
Figura 3 Definición de tareas de audio del programador de aplicaciones multimedia (Hacer clic en la imagen para reducirla)
Figura 3 Definición de tareas de audio del programador de aplicaciones multimedia
Figura 3 Definición de tareas de audio del programador de aplicaciones multimedia (Hacer clic en la imagen para ampliarla)
MMCSS, que se ha implementado en %SystemRoot%\System32\Mmcss.dll y se ejecuta en un proceso de host de servicios (Svchost.exe), tiene un subproceso de administración de prioridades que se ejecuta en prioridad 27. (Las prioridades de subprocesos oscilan entre 0 y 31.) Este subproceso aumenta la prioridad de los subprocesos multimedia registrados en el rango asociado con el valor de la categoría de programación de su clave del Registro de la tarea, según se incluye en la Figura 4. En Windows, las prioridades de subprocesos 16 y superiores se encuentran en un rango de prioridades en tiempo real y superiores al resto de subprocesos de un sistema (a excepción de los subprocesos de trabajadores del Administrador de memoria del núcleo, que se ejecutan en las prioridades 28 y 29). Sólo las cuentas administrativas, como la cuenta del sistema local en la que se ejecuta MMCSS, tienen el privilegio de prioridad de aumento necesario para establecer prioridades de subprocesos de tiempo real.
Figure 4 Prioridades de subprocesos de MMCSS (Close Figure 4)

Programación de categorías | Prioridad de subprocesos aumentada
High | 23-26
Medium | 16-23
Cuando reproduce un archivo de audio, el Reproductor de Windows Media registra las subprocesos de la tarea de audio y, al reproducir un vídeo, registra los subprocesos de tareas de reproducción. El servicio MMCSS aumenta todos los subprocesos que han indicado que están proporcionando una secuencia al mismo tiempo que se están ejecutando en el proceso propietario de la ventana en primer plano y al tiempo que tienen el valor BackgroundOnly establecido como True en su clave de definición de la tarea.
Pero si bien MMCSS quiere ayudar a que los subprocesos multimedia obtengan el tiempo de CPU que necesiten, también quiere asegurarse de que otros subprocesos obtengan por lo menos algún tiempo de CPU para que el sistema y otras aplicaciones sigan respondiendo. Por tanto, MMCSS reserva un porcentaje de tiempo de CPU para otra actividad, tal y como se indica en el siguiente valor del Registro:
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
De forma predeterminada, esto supone el 20 por ciento; MMCSS supervisa el uso de la CPU para asegurarse de que los subprocesos multimedia no aumenten más de 8 ms sobre 10 ms si otros subprocesos quieren utilizar la CPU. Para que los subprocesos multimedia no ocupen esos 2 ms restantes, el programador deja caer sus prioridades en un rango de 1-7.
Puede consultar cómo aumenta MMCSS la prioridad de subprocesos en la barra lateral "Watching MMCSS Priority Boosting" (en inglés).

Vínculos simbólicos basados en archivos
Entre los cambios relacionados con E/S de Windows Vista se incluyen los vínculos simbólicos basados en archivos, un procesamiento más eficiente de terminación de E/S, un soporte técnico completa para la cancelación de E/S y E/S con prioridades.
Una característica del sistema de archivos que muchos han echado de menos de NTFS, el vínculo de archivo simbólico (o, como se ha llamado en Unix, el vínculo lógico) finalmente llega a Windows Vista. La versión Windows 2000 de NTFS introdujo los vínculos de directorio simbólicos, llamados "unión de directorio", que le permiten crear un directorio que señale a un directorio diferente, pero hasta la versión de Windows Vista, NTFS sólo ha sido compatible con los vínculos físicos de archivos.
Una diferencia mayor en la forma en que Windows resuelve los vínculos simbólicos y las uniones de directorio es el lugar donde tiene lugar el procesamiento. Windows procesa los vínculos simbólicos en el sistema local, aunque hagan referencia a una ubicación en un servidor de archivos remoto. Windows procesa las uniones de directorio que hacen referencia a un servidor de archivos remoto en el propio servidor. Los vínculos simbólicos de un servidor pueden, por tanto, hacer referencia a ubicaciones a las que sólo se puede tener acceso desde un cliente, como otros volúmenes de cliente, mientras que las uniones de directorio no. Para solucionar esto, Windows Vista es compatible con el nuevo tipo de vínculo simbólico tanto para archivos como para directorios.
Muchos comandos del sistema de archivos han sido actualizados para entender las implicaciones de los vínculos simbólicos. Por ejemplo, el comando Delete sabe cómo no seguir los vínculos, lo que daría como resultado la supresión del objetivo, pero en su lugar se elimina el vínculo. Sin embargo, debido a que no todas las aplicaciones pueden tratar los vínculos simbólicos correctamente, la creación de un vínculo simbólico requiere el nuevo privilegio de creación de vínculos simbólicos que sólo tienen de forma predeterminada los administradores.
Puede crear un vínculo simbólico desde el símbolo del sistema con el comando Mklink. El comando de directorio integrado del símbolo del sistema identifica un vínculo simbólico etiquetándolo como <SYMLINK> y le muestra el objetivo entre paréntesis, como se indica en la Figura 5. El Explorador de Windows distingue también los vínculos simbólicos y los muestra con una flecha de acceso directo. Puede consultar el objetivo de un vínculo en el Explorador agregando la columna de objetivo del vínculo a la ventana de exploración. Observación del aumento de prioridad de MMCSS
Puede presenciar el aumento de subprocesos que le aplica el servicio de MMCSS a los subprocesos del Reproductor de Windows Media mediante la reproducción un clip de vídeo o audio, ejecutando el Monitor de rendimiento, configurando la escala gráfica en 31 (la prioridad de subproceso más alta de Windows) y agregando el contador de prioridad actual a todas las instancias de los objetos de subprocesos del Reproductor de Windows Media (Wmplayer.exe) en la pantalla. Uno o más subprocesos se ejecutarán con la prioridad 21.
Figura B El aumento de prioridades de subprocesos para el Reproductor de Windows Media
Figura B El aumento de prioridades de subprocesos para el Reproductor de Windows Media (Hacer clic en la imagen para reducirla)
Figura B El aumento de prioridades de subprocesos para el Reproductor de Windows Media
Figura B El aumento de prioridades de subprocesos para el Reproductor de Windows Media (Hacer clic en la imagen para ampliarla)

Figura 5 Uso de Mklink para crear un vínculo simbólico
Figura 5 Uso de Mklink para crear un vínculo simbólico (Hacer clic en la imagen para reducirla)
Figura 5 Uso de Mklink para crear un vínculo simbólico
Figura 5 Uso de Mklink para crear un vínculo simbólico (Hacer clic en la imagen para ampliarla)

Cancelación y terminación de E/S
Existe cierto número de cambios camuflados en el sistema de E/S que pueden mejorar el rendimiento de las aplicaciones de servidor. Estas aplicaciones utilizan comúnmente un objeto de sincronización denominado "puerto de terminación" para esperar a que finalicen las solicitudes de E/S asincrónicas. Antes de Windows Vista, cuándo se finalizaba dicha E/S, el subproceso que publicó la E/S ejecutaría el trabajo de terminación de E/S, provocando un cambio en el proceso al que pertenece el subproceso e interrumpiendo cualquier otra cosa que pasara. A continuación, el sistema de E/S actualizaría el estado del puerto de terminación para despertar un subproceso en espera de este cambio.
En Windows Vista, el procesamiento de terminación de E/S se lleva a cabo no necesariamente por el subproceso que publicó la E/S, sino por el que esté en espera de que despierte el puerto de terminación. Este cambio relativamente secundario evita la programación innecesaria de subprocesos y conmutadores de contexto que puedan degradar el rendimiento general del sistema y de la aplicación. Para mejorar el rendimiento aún más, un servidor puede recuperar los resultados de múltiples operaciones de E/S de una terminación en una sola solicitud, evitando así las transiciones al modo de núcleo.
Probablemente el cambio más visible en el sistema de E/S desde la perspectiva del usuario final es el soporte técnico de Windows Vista para la cancelación de operaciones sincrónicas de E/S. Si ha utilizado alguna vez un comando Net View o ha intentado tener acceso a un recurso compartido de un sistema remoto sin conexión que utilice Windows XP o Windows Server® 2003, ha experimentado los problemas con las operaciones de E/S que no se pueden cancelar: El explorador de archivos o comandos no responderá hasta que caduque el tiempo de espera de la red. Una aplicación no tiene otra opción que esperar a que la operación genere un error, ya que no hay manera de indicarle al controlador de dispositivo que ejecuta la E/S que deje de preocuparse por ésta.
En Windows Vista la mayoría de las operaciones de E/S pueden ser canceladas, incluyendo la E/S del archivo abierto que utilizan el explorador y Net View. Sin embargo, las aplicaciones se tienen que actualizar para responder a solicitudes de usuario final de cancelación de E/S y muchas de las utilidades de Windows Vista que interactúan con dispositivos que tiene tiempos de espera tienen el soporte técnico necesario. Los cuadros de diálogo para abrir y guardar archivos que se utilizan prácticamente en todas las aplicaciones de Windows, incluyendo aplicaciones de terceros, por ejemplo, ahora habilitan el botón de cancelación al tratar de mostrar el contenido de una carpeta. El comando Net cancela también su E/S sincrónica cuando presione Ctrl + C.
Puede consultar las prestaciones de la cancelación de E/S abriendo el símbolo del sistema en Windows Vista y escribiendo:
net view (\\nonexistentmachine)
El comando se colgará mientras Windows trata de contactar con el sistema inexistente, pero puede escribir Ctrl + C para terminarlo. En Windows XP, Ctrl + C no tiene efecto y el comando no se devuelve hasta que transcurra el tiempo de espera de la operación de red.
Otro tipo de E/S que ha causado problemas a los usuarios en versiones anteriores de Windows eran las que no podían cancelar correctamente los controladores de dispositivos, ya que no existía forma fácil de que supieran que debían hacerlo. Si ha terminado alguna vez un proceso, pero posteriormente observó cómo se demoraba en herramientas de visualización de procesos, ha presenciado un controlador de dispositivo que genera un error al responder a una finalización de proceso y a una cancelación de E/S publicada por el proceso que no se había completado. Windows no puede realizar la limpieza de procesos final hasta que toda la E/S del proceso se haya terminado o cancelado. En Windows Vista, los controladores de dispositivos registran fácilmente la notificación de finalizaciones de procesos y de este modo la mayoría de los problemas de procesos irresolubles desaparecen.

Prioridad de E/S
Si bien Windows siempre ha sido compatible con la priorización del uso de la CPU, no ha incluido el concepto de prioridad de E/S. Sin prioridad de E/S, las actividades en segundo plano, como la indización de búsquedas, la exploración de virus y la desfragmentación de disco, pueden afectar gravemente a la receptividad de las operaciones en primer plano. Un usuario que inicia una aplicación o que abre un documento mientras otro proceso realiza E/S de disco, por ejemplo, sufre demoras, como las esperas de tareas en primer plano para el acceso a disco. La misma interferencia afecta también a la reproducción de transmisión por secuencias del contenido multimedia, como canciones de un disco duro.
Windows Vista introduce dos tipos nuevos de priorización de E/S para que las operaciones de E/S en primer plano tengan preferencia: prioridad en operaciones de E/S individuales y reservas de ancho de banda de E/S. El sistema de E/S de Windows Vista incluye internamente soporte técnico para cinco prioridades de E/S, como se muestra en la Figura 6, pero sólo se utilizan cuatro de las prioridades (las versiones futuras de Windows pueden ser compatibles con High).
Figure 6 Prioridades de E/S de Windows Vista (Close Figure 6)

Prioridad de E/S | Uso
Critical | Administrador de memoria
High | No usado
Normal | Prioridad predeterminada
Low | Prioridad de tarea predeterminada
Very Low | Actividad en segundo plano
E/S tiene una prioridad predeterminada Medium y el Administrador de memoria utiliza Critical cuando quiere escribir datos sucios de la memoria fuera al disco en situaciones de memoria baja para dejar espacio en la RAM para otros datos y código. El Programador de tareas de Windows establece la prioridad de E/S para tareas que tengan la prioridad de tarea predeterminada en Low y la prioridad especificada por aplicaciones escritas para Windows Vista y que realizan procesamiento en segundo plano en Very Low. Todas las operaciones en segundo plano de Windows Vista, incluyendo la exploración de Windows Defender y la indización de búsquedas del escritorio, utilizan una prioridad de E/S muy baja. Prioridad de E/S muy baja
El Monitor de procesos, un sistema de archivos en tiempo real y la utilidad de supervisión del Registro, de Sysinternals, reúnen información detallada para las operaciones del sistema de archivos de escritura y lectura, incluyendo sus prioridades de E/S en Windows Vista. La línea resaltada muestra un ejemplo de una E/S de prioridad muy baja publicada por SuperFetch (que trataré en mi siguiente entrega).
Figura C Visualización de prioridad de E/S muy baja en el Monitor de procesos
Figura C Visualización de prioridad de E/S muy baja en el Monitor de procesos (Hacer clic en la imagen para reducirla)
Figura C Visualización de prioridad de E/S muy baja en el Monitor de procesos
Figura C Visualización de prioridad de E/S muy baja en el Monitor de procesos (Hacer clic en la imagen para ampliarla)

El controlador de dispositivo de la clase de almacenamiento del sistema (%SystemRoot%\System32\Classpnp.sys) implanta las prioridades de E/S y de este modo se aplican automáticamente a las E/S dirigidas a la mayoría de los dispositivos de almacenamiento. La clase y otros controladores de almacenamiento insertan E/S medias por delante de las que son bajas y muy bajas en sus colas, aunque publican por lo menos una E/S en espera con prioridad baja o muy baja por segundo, de forma que los procesos en segundo plano puedan hacer progresos. La lectura de datos con una E/S muy baja también provoca que el Administrador de caché escriba inmediatamente modificaciones en el disco en vez de hacerlo más tarde y que eluda su lógica de leer hacia adelante para las operaciones de lectura que, de otro modo, se leerían preventivamente desde el archivo al que se tiene acceso. Consulte en la barra lateral "Seeing Very Low I/O Priority" (en inglés) para obtener un ejemplo de una prioridad de E/S muy baja con la utilidad Monitor del proceso.
La compatibilidad de reserva de ancho de banda de Windows Vista resulta práctica para las aplicaciones de reproductor de medios. El Reproductor de Windows Media lo utiliza, junto con aumentos de prioridad de MMCSS, para proporcionar una reproducción casi libre de errores del contenido local. Una aplicación de reproducción de medios le solicita al sistema de E/S que le garantice la capacidad de leer datos a una tasa especificada y, si el dispositivo puede proporcionar los datos en la tasa solicitada y las reservas existentes lo admiten, orienta a la aplicación en cuanto a qué velocidad se deben publicar las E/S y qué tamaño deberían tener las E/S. El sistema de E/S no atenderá otras E/S a menos que pueda satisfacer los requisitos de las aplicaciones que han realizado reservas en el dispositivo de almacenamiento objetivo.
Un cambio final en el sistema de E/S que merece ser mencionado es el tamaño de las operaciones de E/S. Desde la primera versión de Windows NT, el Administrador de memoria y el sistema de E/S han limitado la cantidad de datos procesados por una solicitud de E/S de almacenamiento individual a 64 KB. Por tanto, incluso si una aplicación publica una solicitud de E/S mucho más grande, se divide en solicitudes individuales que tienen un tamaño máximo de 64 KB. Cada E/S asume una sobrecarga de transiciones en modo de núcleo e inicia una transferencia de E/S en el dispositivo de almacenamiento, de modo que en Windows Vista los tamaños de solicitud de E/S de almacenamiento ya no se tapan. Se han modificado varios componentes del modo de usuario de Windows Vista para aprovecharse del soporte técnico de E/S más grandes, incluyendo la funcionalidad de copia del Explorador y el comando Copy del símbolo del sistema, que ahora publica una E/S de 1 MB.

Próximamente
Ahora ya ha visto dos áreas en las que el núcleo de Windows Vista se ha mejorado. Puede obtener información exhaustiva adicional en la siguiente edición de mi libro, Windows Internals (con David Solomon como coautor), cuyo lanzamiento está previsto al mismo tiempo que la siguiente versión de Windows Server, con el nombre de código de "Longhorn". En la próxima entrega, seguiré explicando el nuevo núcleo mediante el análisis de la administración de memoria, junto con el encendido y apagado del sistema.

Mark Russinovich es un empleado técnico de Microsoft perteneciente a la división de servicios y plataformas. Es coautor de Microsoft Windows Internals (Microsoft Press, 2004) y un frecuente orador en conferencias de desarrolladores y TI. Se unió a Microsoft con la adquisición reciente de la compañía que cofundó, Winternals Software. También creó Sysinternals, donde publicó las utilidades del Explorador de procesos, 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: Delegaci&#243;n de autoridad en Active&#160;Directory
Administración de Windows Joel Yoker and Rob Campbell

Delegación de autoridad en Active Directory
Resumen:
  • Definición de funciones administrativas
  • Desarrollo de un modelo de unidad organizativa y grupo de seguridad
  • Uso de cuentas secundarias
  • Herramientas de delegación de derechos

Las capacidades de delegación en Active Directory son bastante eficaces; responden a una serie de problemas de seguridad y simplifican las tareas de administración. Mediante una delegación correcta de derechos en Active
Directory®, puede aplicar funciones especificadas en el entorno, limitar la repercusión y la probabilidad de errores administrativos, y aplicar el principio de privilegio mínimo en la infraestructura. Todavía hay muchas organizaciones que dependen de Active Directory y aún no han aprovechado la eficacia de la delegación. En parte, esto se debe a que, a simple vista, el desarrollo de un modelo de delegación de Active Directory para la empresa parece ser bastante complejo. Mientras que el principal obstáculo es desarrollar un modelo de la delegación que satisfaga las necesidades exclusivas de la organización, lo cierto es que hay modelos muy sencillos que se pueden aplicar a la mayoría de infraestructuras de TI con pequeñas modificaciones.
Aunque cada entorno es diferente en algo, la realidad es que la mayoría de las empresas grandes son semejantes en muchos sentidos y encaran los mismos desafíos de TI. Por ejemplo, muchas organizaciones están divididas en regiones geográficas, han evolucionado a partir de una ingeniería de TI o unos equipos de soporte técnico de funcionamiento distintos, y tienen unidades de negocio independientes. Y muchas organizaciones grandes deben tratar estos asuntos en términos de aumento de privilegios, abuso de cuentas de servicios y "confianza".
La confianza es un término interesante y a menudo se convierte en la justificación para tener varios bosques de Active Directory. Los problemas de confianza provienen con frecuencia de la capacidad de una división o región para influir en la disponibilidad del sistema de otra división o región. Es habitual en los niveles de habilidades que se diferencie entre los límites de la organización y que haya una falta de conocimiento exhaustivo de sistemas específicos necesarios para ofrecer soporte a una región o unidad de negocio concretas. Así, las divisiones suelen no querer renunciar a sus derechos administrativos en favor de un grupo central.
Mientras tanto, para cualquier implementación de Active Directory, los administradores deben definir las reglas de compromiso de las aplicaciones que usan la infraestructura de Active Directory. Desgraciadamente, un enfoque común (que a menudo se cita en las guías de instalación) es hacer que una cuenta de servicio sea un miembro del grupo Admins. de dominio. El problema de este enfoque es que las cuentas de servicio son cuentas genéricas fundamentalmente. Al conceder a estas cuentas los derechos de un administrador de dominio, se introduce una amenaza considerable para el entorno de TI. Las cuentas de servicio pueden caer fácilmente en manos de administradores malintencionados o descuidados, o bien ser usadas por atacantes que aprovechen problemas de seguridad subyacentes de una aplicación.
Aunque estos obstáculos parecen ser insuperables, representan el escenario principal para implementar un modelo de delegación de Active Directory. El desarrollo de un modelo de la delegación es un proceso de diseño iterativo y le sugerimos que siga estos pasos:
  1. Defina las funciones administrativas de TI de la organización.
  2. Desarrolle un modelo de unidad organizativa y grupo de seguridad.
  3. Establezca cuentas secundarias para administradores de TI.
  4. Delegue derechos.
Observemos con mayor detenimiento estos pasos.

Definición de funciones
El proceso de definición de funciones comienza con una descripción completa de la administración de servicios y la administración de datos. Estos conceptos son la piedra angular de cualquier modelo de delegación de Active Directory.
En esencia, la administración de servicios es la administración de los componentes de infraestructura de servicio de directorios fundamentales, tales como los servidores Exchange y los controladores de dominio. La administración de datos es la administración de objetos, tales como buzones de correo y cuentas de usuario que residen en los servicios. Dentro del ámbito de Active Directory, los administradores de servicios son responsables en última instancia de la entrega y la disponibilidad de los servicios de directorio, mientras que los administradores de datos administran cuentas de usuario y servidor, grupos y otros recursos del dominio.
Active Directory es compatible con la delegación granular de autoridad a través de unidades organizativas (OU). Las unidades organizativas pueden adaptarse con frecuencia para ofrecer el mismo nivel de autoridad que está disponible para los administradores dentro del servicio de directorio o los modelos de dominio existentes. Pero es importante entender que algunas funciones simplemente no pueden delegarse y deben administrarse mediante un grupo o entidad únicos y de confianza.
El análisis de tareas también es fundamental. Necesita saber qué tareas de Active Directory llevan a cabo los administradores y cómo se asignan esas tareas a funciones. Por ejemplo, la creación de sitios de Active Directory es una tarea de administración de servicios, mientras que la modificación de la pertenencia a grupos de seguridad generalmente está dentro de la administración de datos. Se debe evaluar la frecuencia, la importancia y la dificultad de cada tarea. Éstos son aspectos esenciales de la definición de tareas, porque determinan si se debe delegar un derecho. Las tareas que se realizan de forma rutinaria, tienen un riesgo limitado y cuya finalización no es importante, son candidatas excelentes para la delegación. Por otro lado, las tareas que no se realizan casi nunca, tienen una gran repercusión en la organización y requieren niveles altos de habilidad, son malas candidatas para la delegación. En su lugar, la extensión (elevación temporal de una cuenta a la función necesaria o reasignación de la tarea) es la ruta adecuada para estas tareas.
Puesto que muchas de las características de organizaciones grandes son semejantes, se puede asumir con seguridad la implementación de un modelo de delegación común. Para el propósito de este artículo, ofreceremos un conjunto de muestra de las funciones que permiten las capacidades de administración a la vez que respetan los límites de la organización e intentan mitigar los problemas de confianza (tales como la disponibilidad de los activos de una empresa, como los controladores de dominio). Tenga en cuenta que este modelo es apenas un ejemplo; se trata de un punto de partida ideal para hablar de las funciones en la organización, aunque no debe planear usar esta orientación al pie de la letra.
Algunas funciones ya las define Active Directory y otras se deben crear desde cero para completar el modelo de delegación. Un conjunto de muestra de funciones que se ajustaría a muchos entornos grandes de Active Directory quizás incluya Administradores de organización, Admins. de dominio y Tier4 Admins (Admins. de nivel4) para la administración de servicios, y Tier3 Admins (Admins. de nivel3), Regional Admins (Admins. regionales), Tier2 Admins (Admins. de nivel2) y Tier1 Admins (Admins. de nivel1) para la administración de datos. Consulte la Figura 1 para obtener una lista de estas funciones y sus responsabilidades.
Figure 1 Definición de funciones y responsabilidades (Close Figure 1)

Administradores de servicios | Descripción
Administradores de organización | Responsable de la administración de servicios de nivel superior en la empresa. No debe contener ningún miembro permanente.
Administradores del dominio | Responsable de la administración de servicios de nivel superior en el dominio. Debe contener sólo un número pequeño y controlable de administradores de confianza.
Tier4 Admins (Admins. de nivel4) | Responsable de la administración de servicios en el dominio. Concede sólo los derechos necesarios para administrar los servicios correspondientes. Sirve también como un punto de extensión para administradores de datos.
Administradores de datos | Descripción
Tier1 Admins (Admins. de nivel1) | Responsable de la administración general de objetos de directorio, realiza tareas tales como el restablecimiento de contraseñas, la modificación de propiedades de cuenta de usuario, etc.
Tier3 Admins (Admins. de nivel3) | Responsable de la creación y/o eliminación selectivas de cuentas de usuario y equipo en la configuración regional o la organización.
Regional Admins (Admins. regionales) | Responsable de la administración de la estructura de unidades organizativas local. Concede permisos para crear la mayoría de los objetos de una unidad organizativa.
Tier3 Admins (Admins. de nivel3) | Responsable de la administración de todos los administradores de datos. Sirve como departamento de soporte técnico y punto de extensión de nivel superior para todos los administradores regionales.

Administradores de servicios
Observemos con mayor detenimiento las funciones del administrador de servicio. Los administradores de servicios administran componentes de infraestructura esenciales y todos los que se incluyen esta categoría tienen muchos privilegios. Por lo tanto, una estrategia de privilegio mínimo, que significa que sólo se concede el conjunto mínimo de permisos necesario para realizar las tareas correspondientes, es muy recomendable en este caso.
Los administradores de organización y dominio de Active Directory representan dos grupos de administradores especiales cuyo contexto de seguridad es necesario para funciones críticas dentro del directorio. Estos grupos, Administradores de organización y Admins. de dominio, son responsables de la administración de servicios de nivel superior. Para mitigar los riesgos inherentes en dichos grupos con muchos privilegios, recomendamos encarecidamente que se restrinja la pertenencia a los mismos. De hecho, el grupo Administradores de organización no debe tener miembros permanentes y los grupos de Admins. de dominio deben contener sólo un número pequeño y controlable de individuos de confianza que trabajen para la organización a tiempo completo.
Cuando sea necesario realizar tareas de administración de empresa como la autorización de servidor DHCP o la creación de sitios de Active Directory, el grupo Admins. de dominio del dominio raíz del bosque de Active Directory puede aumentar los privilegios administrando la pertenencia del grupo Administradores de organización. Estos privilegios sólo deben concederse por espacios de tiempo cortos para evitar la creación de miembros permanentes en el grupo Administradores de organización. Por supuesto, todos los miembros de un grupo Admins. de dominio de un bosque de Active Directory determinado deben tener la misma confianza.
Un error común que suelen cometer la mayoría de las organizaciones al desarrollar un modelo de delegación, es deshabilitar o paralizar estas funciones integradas. La modificación de las funciones predeterminadas puede causar resultados imprevisibles y no hay garantía de que las revisiones de service pack ni las actualizaciones de producto conserven esta configuración. Además, este tipo de modificación crea un entorno no compatible fuera de la organización. Un enfoque práctico consiste en usar las funciones y los grupos integrados, pero limitando la pertenencia. Para ello, tendrá probablemente que crear funciones nuevas para los administradores que anteriormente pertenecían a grupos como Adminis. de domino.
Tier4 Admins (Admins. de nivel4) El grupo Tier4 Admins (Admins. de nivel4) debe consistir en administradores de servicios centralizados que ofrecen soporte técnico para todos los servicios de empresa. Puesto que se trata de una función creada, los permisos de servicio de directorio y acceso al sistema se pueden adaptar a los requisitos específicos de la organización. Aunque los miembros de este grupo son administradores de servicio, pueden realizar también tareas de administración de datos en todo el bosque. Debido a que hay muchas clases de sistemas y áreas diferentes de responsabilidad, las funciones del nivel4 se dividen en varios subgrupos dentro del directorio. Por ejemplo, se deben crear grupos independientes del nivel4 para ofrecer una administración distinta de sistemas específicos, tales como los servidores Exchange. Este grupo sirve también como un punto de extensión para administradores de datos.
Una de las razones por las que a menudo la gente desea que se le conceda la pertenencia al grupo Admins. de dominio es conseguir derechos administrativos de todo el sistema en un dominio determinado. El truco para que estos administradores de servicio trabajen en el modo de privilegio mínimo es conceder el control de Tier4 Admins (Admins. de nivel4) de los servidores de empresa sin hacerlos administradores de dominio. Para evitar la extensión de privilegios, no se debe conceder a los administradores de Tier4 Admins (Admins. de nivel4) la pertenencia al grupo BUILTIN\Administradores en controladores de dominio, ya que ese grupo tiene muchos derechos subyacentes para el servicio de directorio que no se pueden separar. Por ejemplo, un miembro del grupo BUILTIN\Administradores de un dominio determinado puede administrar la pertenencia al grupo Admins. de dominio, permitiendo que ciertos miembros aumenten sus privilegios sin realizar comprobaciones ni equilibrios.
Recordando nuestra regla de no paralizar permisos predeterminados, podemos mitigar este riesgo haciendo que los grupos del nivel4 sean miembros anidados de los grupos de dominio integrados Opers. de servidores y DNS Admins (Admins. de DNS). De esta forma, se permite la administración local de controladores de dominio a la vez que se limita la capacidad de Tier4 Admins (Admins. de nivel4) de aumentar los privilegios. Para la mayoría de los sistemas (que no sean controladores de dominio, servidores de certificados, etc.), debe hacer que el grupo Tier4 Admins (Admins. de nivel4) sea miembro del grupo Administradores local. La automatización de la pertenencia anidada a grupos locales se puede lograr mediante la funcionalidad Grupos restringidos de directiva de grupo.

Administradores de datos
Ahora centrémonos en las funciones de administración de datos. Deben estar diseñadas con derechos acumulativos, lo que significa que un administrador de Tier2 Admins (Admins. de nivel2) debe tener los mismos derechos que un administrador de Tier1 Admins (Admins. de nivel1) junto con algunos privilegios adicionales, etc. Por ello, nos centraremos en estos grupos y seguiremos un orden de abajo a arriba.
Tier1 Admins (Admins. de nivel1) El grupo Tier1 Admins (Admins. de nivel1) debe ofrecer la administración general de objetos de directorio anteriormente creados. Este grupo es para los administradores con un aprendizaje mínimo o para aquéllos que realicen tareas aisladas, tales como restablecimientos de contraseñas. Conceda a este grupo los derechos de la unidad organizativa para modificar propiedades de cuenta de usuario, restablecer contraseñas de cuenta de usuario, desbloquear cuentas, activar/desactivar cuentas de usuario, agregar y restablecer cuentas de equipos de estación de trabajo y modificar la pertenencia de objetos de grupos que no sean administrativos.
Tier2 Admins (Admins. de nivel2) Este grupo debe permitir la administración y la creación selectiva de objetos, permitiendo que sólo se creen los objetos que pueda administrar Tier1 Admins (Admins. de nivel1). Por ejemplo, los grupos de seguridad sólo se pueden crear en la unidad organizativa de grupos. Los administradores de Tier2 Admins (Admins. de nivel2) pueden agregar y modificar cuentas de Tier1 Admins (Admins. de nivel1); agregar, modificar y eliminar cuentas de usuario de una unidad organizativa; eliminar objetos de equipos de estación de trabajo; y agregar, modificar y eliminar objetos de servidor, contacto y carpetas compartidas.
Regional Admins (Admins. regionales) A este grupo se le conceden derechos exclusivos sobre su estructura de unidades organizativas regionales. Sin embargo, sus administradores no pueden administrar otras estructuras de unidades organizativas regionales del directorio. Las cuentas de este grupo se deben considerar con muchos privilegios y, como resultado, se almacenan en una jerarquía de unidad organizativa independiente y están administradas por los administradores de servicios de Tier4 Admins (Admins. de nivel4). A los administradores de Regional Admins (Admins. regionales) se les permite crear la mayoría de los objetos sin restricciones dentro de su estructura de unidades organizativas (una excepción notable es la creación de otras unidades organizativas), que conlleva el riesgo adicional de crear objetos que no se puedan administrar en niveles inferiores.
Tier3 Admins (Admins. de nivel3) Muchas organizaciones tienen un departamento de soporte técnico centralizado o de nivel superior. Esta función llena la lista de administradores de datos y ofrece un grupo de administradores de datos por encima de todos los administradores regionales. Los derechos no se delegan a estos grupos específicamente dentro del directorio; en su lugar, se delegan a través de la pertenencia anidada de cada grupo Regional Admins (Admins. regionales). Esto ofrece un punto de extensión de nivel superior para todos los administradores de datos así como un punto de entrada de problemas que pasarán a los grupos de administración de servicios.

Creación de un modelo de unidad organizativa y grupo de seguridad
Una vez que las funciones están definidas en la organización, se debe definir un modelo de unidad organizativa y grupo de seguridad. Hay dos razones principales para crear una unidad organizativa en Active Directory: la delegación de derechos y la creación de un punto donde se puedan vincular los objetos de directiva de grupo. Las unidades organizativas definen un ámbito de administración (SOM) dentro del directorio y se pueden usar para limitar los derechos a objetos de varios niveles. Como resultado, el modo en que elija delegar la autoridad debe ser un factor principal en la implementación de la estructura de unidades organizativas.
Teniendo esto en cuenta, se debe crear una unidad organizativa de nivel superior (o una serie de unidades organizativas) directamente bajo el dominio para albergar todos los objetos. Esta unidad organizativa sirve para el propósito específico de definir el SOM de nivel superior de Tier4 Admins (Admins. de nivel4). Al crear una unidad organizativa de nivel superior, los derechos sobre el servicio de directorio pueden comenzar explícitamente en el nivel de unidad organizativa en lugar de en el nivel de dominio. La delegación desde una unidad organizativa de nivel superior en lugar de un dominio mitiga el riesgo observado anteriormente de que los usuarios tengan la capacidad de aumentar los privilegios mediante la manipulación de los grupos del dominio integrados.
Debajo de las unidades organizativas de nivel superior, debe crear jerarquías independientes de unidades organizativas inferiores para representar cada región o unidad de negocio que tiene un equipo de administración de datos específico. Cada unidad organizativa inferior regional debe tener una jerarquía de unidades organizativas común y no extensible para la administración de objetos de directorio. La uniformidad es fundamental para la administración progresiva, ya que gran parte de la delegación de derechos será automática. Éste es un orden de gran tamaño, ya que es posible que cada región desee unidades organizativas únicas. Sin embargo, los administradores de TI deben mantenerse firmes, y si una extensión es requerida para una región, la estructura de unidades organizativas inferiores debe extenderse para todas las regiones. Esto puede parecer difícil al principio, pero si la organización ofrece un alojamiento genérico para los objetos, las situaciones aisladas acaban produciéndose con el tiempo.
Finalmente, cree grupos y cuentas de subadministradores independientes para eliminar a la capacidad de los administradores de aumentar los privilegios (un grupo Tier1 Admins (Admins. de nivel1), Tier2 Admins (Admins. de nivel2) y Regional Admins (Admins. regionales) para cada jerarquía de unidad organizativa inferior). Al colocar estas cuentas en unidades organizativas independientes, se permite la restricción de la administración a ese nivel o a uno inferior. Así, si todas las cuentas de Tier1 Admins (Admins. de nivel1) y el grupo de seguridad asociado residen en una unidad organizativa donde no tienen derechos, los administradores no podrán apropiarse de otras cuentas de administrador ni aumentar los privilegios de otros administradores a su nivel. Cualquier miembro del grupo Admins. de dominio, por ejemplo, puede convertir cualquier otra cuenta de usuario del dominio en un administrador de dominio. Sin embargo, con este modelo de unidad organizativa aplicado, se mitiga ese riesgo. En la Figura 2, se muestra una estructura de unidad organizativa de ejemplo con grupos de seguridad asociados.
Figura 2 Estructura de unidad organizativa y grupos de seguridad asociados
Figura 2 Estructura de unidad organizativa y grupos de seguridad asociados

Establecimiento de cuentas secundarias
La clave para conseguir un modelo satisfactorio de delegación consiste en aplicar el principio de privilegio mínimo. En la práctica, esto significa que una entidad de seguridad debe tener sólo la capacidad de realizar las tareas necesarias para su función y nada más. Desgraciadamente, muchos administradores de TI usan la misma entidad de seguridad para la administración de directorios y para tareas diarias como la exploración de la Web y la lectura del correo electrónico. Tener cuentas separadas disminuye la probabilidad de que un administrador con niveles dañe el servicio de directorios por error o sea víctima de un ataque enviado a través de aplicaciones diarias y dirigido al administrador de directorios.
Para alcanzar esto sin requerir que el usuario cierre sesión y vuelva a abrirla, se usa el servicio de inicio de sesión secundario (Runas.exe). Éste permite a los usuarios aumentar sus privilegios mediante un conjunto alternativo de credenciales al ejecutar scripts o archivos ejecutables en servidores y estaciones de trabajo.
Mientras el concepto del uso de cuentas de privilegio mínimo es relativamente sencillo, las organizaciones a veces lo encuentran difícil de implantar, ya que puede que los hábitos de TI anteriores sean bastante difíciles de quebrantar. Un método directo para evitar el uso de cuentas con privilegios en tareas diarias es no ofrecer acceso al correo a dichas cuentas en Exchange Server, reforzando este principio mediante una directiva administrativa en la organización. Este enfoque relativamente sencillo reduce apreciablemente la probabilidad de que se usen dichas cuentas para tareas rutinarias no administrativas.

Delegación de derechos
El paso final para desarrollar un modelo de delegación es la delegación real de derechos en Active Directory. Esto trae consigo la manipulación de entradas de control de acceso (ACE) y de listas de control de acceso (ACL) en los datos almacenados en el directorio. Las ACL de contenedores de Active Directory definen qué objetos se pueden crear y cómo se administran dichos objetos. La delegación de derechos implica operaciones básicas en objetos, como la capacidad de ver un objeto, de crear un objeto secundario de una clase especificada o de leer información de atributos y seguridad en objetos de una clase especificada. Aparte de estas operaciones básicas, Active Directory define derechos extendidos, que permiten operaciones tales como Enviar como y Administrar topología de réplica.
En pasos anteriores, hemos tratado la creación de grupos de seguridad que se asignan a funciones definidas de la organización. Esto significa que para cada función hay un grupo de seguridad asociado por estructura de unidades organizativas inferiores. Para implementar el modelo de delegación, se deben asignar permisos a estos grupos sobre los objetos del directorio. En este punto del proceso, no desea grandes descubrimientos ni tener que crear un entorno sumamente personalizado. En su lugar, pruebe a aprovechar los grupos y los derechos integrados en la medida de lo posible. Supongamos que una función concreta necesita administrar registros DNS para el bosque. No intente delegar los derechos sobre los contenedores y los contextos de nomenclatura a DNS integrado de Active Directory; en vez de eso, simplemente aproveche el grupo BUILTIN\DNS Admins (BUILTIN\Admins. de DNS) del dominio. Además, los derechos de usuario y otros permisos se pueden extender a través de la directiva de grupo para ofrecer los derechos adicionales necesarios para administrar una clase específica de sistema mediante una función determinada.
Al asignar permisos mediante la delegación, debe limitar o incluso eliminar completamente el uso de ACE de denegación en el directorio. Pueden resultar delicadas a la hora de solucionar problemas. Un mejor enfoque es usar ACE de admisión para conceder derechos a los grupos personalizados que representan las funciones. Recuerde que las funciones definidas por el usuario, tal como Tier4 Admins (Admins. de nivel4), sólo tendrán los derechos explícitos definidos por esa función.
La herencia resulta fundamental para la seguridad de Active Directory y define cómo una ACL concreta se aplica a objetos secundarios en un contenedor o subcontenedor determinado. Sea siempre específico acerca del ámbito de herencia, asegurándose de que las ACE heredables se aplican tan próximas a los objetos de destino como sea posible. Los permisos de denegación heredables aplicados en el objeto primario tendrán prioridad frente a permisos de denegación heredables aplicados en el objeto primario principal; ésta es una de las razones principales por las que no se recomiendan las ACE de denegación para la delegación práctica. Además, los permisos heredables no pueden invalidar ninguna ACE explícita de un objeto. Por ello, se recomienda que limite o elimine la capacidad de los administradores con niveles para modificar la lista de control de acceso discrecional (eliminando el privilegio de escritura en DACL) en objetos de directorio. Tenga en cuenta que el creador del objeto posee estos derechos de manera implícita. La regla general es que si un administrador tiene la capacidad de cambiar la DACL de un objeto, probablemente lo hará. No permita que el duro trabajo que la organización ha encomendado al modelo de delegación se pierda al introducir la elección y un posible error administrativo.
Hay varias herramientas que deberá usar para implementar correctamente un modelo de delegación de Active Directory. Para la mayoría de las organizaciones grandes, el uso del asistente de delegación integrado para asignar permisos en el directorio es una tarea desalentadora en la que prima la posibilidad de un error administrativo. En su lugar, siempre se debe usar la automatización para garantizar que el modelo de delegación está bien documentado, es compatible y ofrece una opción de recuperación en caso de que se pierda o se cambie la configuración de algún modo sin querer.
La herramienta principal necesaria para implementar la delegación es DSACLS.EXE, una herramienta de línea de comandos usada para manipular las ACL de servicio de directorio en objetos. Esta herramienta también permite especificar los indicadores de herencia para una DACL en el objeto primario. (Los indicadores de herencia incluyen este objeto y subobjetos, sólo subobjetos y propagan los permisos heredables sólo en un nivel). Los comandos de DSACLS no funcionarán correctamente en última instancia si un indicador de herencia está establecido incorrectamente, de modo que es esencial realizar pruebas al usar esta herramienta. Aquí tiene un ejemplo de la sintaxis de DSACLS para delegar la capacidad de crear objetos de equipo en la unidad organizativa de demostración de destino:
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS distingue mayúsculas y minúsculas con respecto a los tipos de objeto. Esto significa que si intenta delegar permisos para la clase de objeto "cn=Computer" en "cn=computer", no funcionará (consulte la Figura 3).
Figura 3 Error debido a distinción de mayúsculas y minúsculas
Figura 3 Error debido a distinción de mayúsculas y minúsculas (Hacer clic en la imagen para reducirla)
Figura 3 Error debido a distinción de mayúsculas y minúsculas
Figura 3 Error debido a distinción de mayúsculas y minúsculas (Hacer clic en la imagen para ampliarla)
Es necesario contar con un conjunto específico de derechos para crear algunos objetos. Esto tiene que ver con los atributos "obligatorios" y "opcionales" de los objetos. La mejor metáfora que he conocido para explicar este concepto es el modelo de la hamburguesa. Las hamburguesas deben estar compuestas por una hamburguesa de carne y un bollo para ser consideradas hamburguesas. Estos son los atributos obligatorios de la clase de objeto hamburguesa. Los elementos como pepinillos, ketchup, lechuga, etc. son los atributos opcionales. Si extendemos la clase de objeto para definir una hamburguesa con queso, agregaremos el queso a la lista de atributos obligatorios.
Los objetos de usuario funcionan de la misma manera. Digamos que vamos a seguir este modelo para crear objetos de usuario con la siguiente sintaxis de DSACLS:
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
El administrador se enfrentará a varios errores durante la creación de objetos de usuario. Necesitamos conceder los privilegios necesarios para establecer los atributos correspondientes de objeto de usuario, incluida la configuración de la contraseña. Todo esto se muestra en la siguiente sintaxis de DSACLS adicional.
Para el primer paso, conceda el privilegio para escribir atributos obligatorios mediante la concesión de los concediendo la Lectura genérica/Escritura genérica a todos los atributos de la clase de usuario:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
Para el paso siguiente, conceda el derecho extendido para cambiar la contraseña:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
Para el paso final, conceda el privilegio de Propiedad de lectura y escritura del atributo Último cambio de contraseña:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
Una vez que se hayan delegado los derechos correspondientes, las funciones definidas se limitarán sólo a la administración de las clases de objeto definidas en la DACL del contenedor. Mediante el ejemplo de objeto de equipo anterior, el menú contextual de Usuarios y equipos de Active Directory restringe la lista de objetos nuevos que puede crear el usuario al que se delegan dichos derechos (consulte la lista restringida en la Figura 4).
Figura 4 Lista restringida de objetos nuevos
Figura 4 Lista restringida de objetos nuevos
El valor de DSACLS también se puede automatizar para ofrecer una implementación compleja de derechos. Aquí se muestran algunos de los comandos de DSACLS que se pueden usar para delegar derechos de manipulación de atributos de dirección comunes a objetos de usuario de un contenedor determinado:
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
Ejemplos como éstos son comunes para la mayoría de los modelos de delegación y se pueden usar junto con las funciones definidas anteriormente.
Otra herramienta usada para implementar la delegación es DSREVOKE.EXE, que permite a los administradores localizar y eliminar derechos delegados para entidades de seguridad específicas de objetos del directorio. Aunque esta herramienta puede ser muy útil, es específica de una entidad de seguridad y no evalúa la pertenencia anidada de los grupos de seguridad.
Además de estas herramientas de línea de comandos, recomendamos el uso de la asignación de derechos de usuario y los grupos restringidos con directiva de grupo. Como hemos indicado anteriormente, la asignación de derechos de usuario permite a los administradores de TI extender o eliminar derechos de nivel inferior (tales como el derecho de obtener acceso y reiniciar el sistema de forma remota) para varios grupos de usuarios de sistemas de destino específicos. Los grupos restringidos se pueden usar para especificar y aplicar la pertenencia local y de dominio en el bosque. Juntas, estas herramientas ofrecen todo lo que necesita para automatizar e implementar un modelo de delegación de Active Directory.

Resumen
Aunque la tarea de desarrollo de un modelo de delegación de Active Directory puede parecer compleja, lo cierto es que se pueden aplicar modelos muy sencillos a la mayoría de infraestructuras de TI. Uno de los pasos más importantes a la hora de implementar un modelo práctico de delegación es definir funciones claras. Debe limitar las funciones definidas a un número pequeño y controlable. El equilibrio es complicado, ya que si se cuenta con demasiadas funciones, habrá algunas que no se usen, mientras que tener muy pocas funciones no permitirá la separación de las mismas.
Al definir las tareas, recuerde clasificarlas por frecuencia, importancia y dificultad. Una vez que defina las funciones, desarrolle un conjunto de casos de uso para ayudar a identificar lo que cada función puede o no puede hacer y poder automatizar el proceso de prueba. Los casos de uso bien preparados ayudarán a explicar estas funciones a sus poseedores en la organización y a mitigar cualquier sorpresa debido a errores de automatización.
Finalmente, siempre es una buena idea tomar un enfoque práctico al desarrollar un modelo de delegación. Recuerde, la sencillez se equipara a la compatibilidad y un modelo de delegación sostenible reportará grandes beneficios a la hora de controlar los derechos administrativos en el entorno de Active Directory.
Recursos adicionales
  • Design Considerations for Delegation of Administration in Active Directory (en inglés)
  • Best Practices for Delegating Active Directory Administration (en inglés)

Joel Yoker es consultor senior del equipo federal de Microsoft. Joel y Rob se dedican a desarrollar e implementar soluciones de seguridad para clientes del gobierno de Estados Unidos.
Rob Campbell es técnico especialista senior del equipo federal de Microsoft. Joel y Rob se dedican a desarrollar e implementar soluciones de seguridad para clientes del gobierno de Estados Unidos.


 Administraci&#243;n de Windows: Obtenga m&#225;s informaci&#243;n sobre las nuevas plantillas de directivas de grupo en Windows Vista
Administración de Windows Darren Mar-Elia

Obtenga más información sobre las nuevas plantillas de directivas de grupo en Windows Vista
Resumen:
  • Información sobre ADMX
  • Edición de archivos ADMX
  • Cuáles son las diferencias entre los archivos ADM y ADMX
  • Creación de un almacén central

Antes de Windows Vista, los valores del Registro que podían establecerse dentro de las directivas de grupo se regían a través de archivos ADM, cuya sintaxis era críptica y con propietario. Si quiso controlar valores adicionales del Registro más allá de los entregados por Microsoft con los archivos ADM estándar, tuvo que aprender
la sintaxis y a crear un archivo ADM personalizado. Además, estos archivos ADM se almacenaron con cada objeto de directiva de grupo (GPO) en el entorno Active Directory ® y cada uno de estos GPO con sus correspondientes archivos ADM se replicaron a todos los controladores de dominio en el dominio.
Con el lanzamiento de Windows Vista™, Microsoft da un paso de gigante en el área de las plantillas del Registro basadas en directivas de grupo. Windows Vista incluye cambios considerables tanto en el formato del archivo ADM, ahora llamado ADMX, como en la forma en la que se almacenan estos archivos. En este artículo, me adentraré en el estudio del nuevo formato ADMX y explicaré en qué difieren estos archivos de los ADM. También hablaré de la forma en la que se lleva a cabo el almacenamiento de estos archivos en un entorno de Windows Vista.

Diferencias de ADMX
La diferencia más importante entre el nuevo formato de archivo ADMX y el antiguo formato ADM que ha estado presente desde Windows NT ® 4.0 es que ADMX ha adoptado el estándar XML para la descripción de la configuración de directivas del Registro. Este punto es positivo por varias razones. La primera es que hay muchas más herramientas para editar XML que para la sintaxis del formato ADM. La segunda es que debido a que el XML se encuentra esquematizado, finalmente resultará más fácil crear herramientas que le ayuden a colocar las etiquetas correctas en el lugar correcto con el fin de crear un archivo ADMX bien estructurado. El significado de esquematizado es que, para una determinada aplicación de XML, tal como el formato ADMX, existe un esquema documentado que describe los elementos y los atributos que son posibles, así como cuál es su organización. Estudiaremos un ejemplo más adelante en el artículo.
La otra diferencia fundamental entre ADMX y ADM es la separación de la sección de cadenas del archivo ADMX principal en un archivo ADML de lenguaje específico. Si está familiarizado con los archivos ADM, sabrá que al final de cada archivo hay una sección delimitada con una etiqueta "[strings]" en la que puede asignar valores a cadenas de texto que desea que aparezcan al utilizar el editor de directivas de grupo y las plantillas administrativas. Por ejemplo, el texto que vio al hacer clic en la ficha Explicación de una determinada directiva se almacenó en dicha sección de cadenas. El problema con esto es que las cadenas se almacenaron dentro del archivo ADM, de modo que si quisiera utilizar dicho ADM en un sistema Windows ® con un idioma diferente, tendría que crear un nuevo archivo ADM con una sección de cadenas para dicho idioma.
La cosa se complica aún más si alguien, digamos, con la versión francesa de Windows, quisiera editar un GPO existente que hubiese utilizado ADM inglés. El administrador francés sólo vería inglés en el editor de directivas de grupo. Windows Vista resuelve este problema separando la sección [strings] en un archivo de idioma ADM basado en XML (o ADML). El archivo ADML puede entregarse en cualquier idioma admitido y puede modificarse fácilmente para ser compatible con cualquier idioma nuevo sin tener que tocar el archivo ADMX principal que almacena las directivas. Lo que es más importante, cuando dicho administrador francés edita un GPO de su estación de trabajo de Windows Vista, el editor de directivas de grupo detectará que se está utilizando la versión francesa de Windows y cargará los archivos ADML franceses para ese GPO automáticamente.
Puede ver todos los archivos ADMX y ADML que vienen con su instalación de Windows Vista abriendo la carpeta en c:\windows\policydefinitions (consulte la Figura 1).
Figura 1 Archivos ADMX en Windows Vista
Figura 1 Archivos ADMX en Windows Vista (Hacer clic en la imagen para reducirla)
Figura 1 Archivos ADMX en Windows Vista
Figura 1 Archivos ADMX en Windows Vista (Hacer clic en la imagen para ampliarla)
Tenga en cuenta que en la parte superior de la lista de archivos de la Figura 1, hay una carpeta llamada en-us. Esta es la carpeta específica del idioma que contiene los archivos ADML de los archivos ADMX que ve en esta carpeta PolicyDefinitions; en este caso para inglés de EE.UU. Hay un archivo ADML para cada ADMX. Al igual que para este tipo de escritura, Windows Vista contiene 132 archivos ADMX/ADML de forma predeterminada. Esta es otra diferencia importante entre Windows Vista y versiones anteriores: Los GPO creados con Windows XP solían tener cinco archivos ADM, el más grande de ellos el archivo System.adm, que contenía los elementos de la directiva para la mayor parte de los componentes de Windows bajo el control de directivas. En Windows Vista, Microsoft ha decidido dividir los archivos ADMX por función; de ahí el número mucho mayor de archivos ADMX. Cada ADMX cubre generalmente un único componente de Windows (tales como el Panel de control, el Cliente DNS, el Explorador de Windows, etc.).

Información sobre ADMX
El hecho de que los ADMX estén escritos en lenguaje XML es una mejora considerable, tal como comenté anteriormente. Sin embargo, muchos administradores no saben escribir XML, así que menos aún entienden el esquema utilizado por ADMX para la creación de las extensiones de directivas. Si bien un tutorial sobre la creación personalizada de ADMX está más allá del ámbito de este artículo, veamos cómo se crean los ADMX.
Puede abrir archivos ADMX o ADML con cualquier editor de texto, incluso el Bloc de notas, pero a menos que su editor entienda la sintaxis XML, puede que no sea muy significativo. Yo utilizo Visual Studio® porque su característica IntelliSense ® permite completar determinados elementos. La Figura 2 muestra las primeras líneas de uno del ADMX que vienen con Windows Vista.
Figure 2 XML en un archivo ADMX (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
Puede parecer extraño si uno no está familiarizado con XML, pero muchos de estos elementos XML pueden encontrarse en cualquier archivo ADMX. El elemento policyNamespaces, por ejemplo, identifica unívocamente este archivo ADMX dentro del universo de todos los archivos ADMX.
Si creó archivos ADM personalizados en versiones anteriores de Windows, sabrá que existía un conjunto de etiquetas, tales como Category, Policy, ListBox y ActionList que se utilizaban para definir la configuración de directivas que aparecería en el editor de directivas de grupo. Muchas de estas etiquetas no han cambiado, o sólo han cambiado levemente en el formato ADMX, pero tienen un aspecto muy diferente porque aparecen representadas en XML. Por ejemplo, yo había creado un archivo ADM personalizado que habilitaba varios tipos de registro en Windows para la solución de problemas de directivas de grupo. Una sección de dicho ADM personalizado se muestra en la Figura 3. Trasladé este archivo al nuevo formato ADMX, tal como se muestra en la Figura 4.
Figure 4 Archivo ADM convertido a archivo ADMX (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 Archivo ADM personalizado (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
En muchos aspectos, este fragmento de ADMX es mucho más fácil de comprender que su semejante ADM, ya que es más breve. El elemento de la directiva especifica lo que hace esta directiva (Folder Redirection Logging). Los atributos prefijados con $(string. son referencias al elemento correspondiente de la cadena ADML. Los atributos key y valuename, obviamente, especifican a qué clave del Registro y valor afecta esta directiva. El elemento parentCategory controla dónde aparece esta directiva en la jerarquía de plantillas administrativas del editor de directivas de grupo. El elemento supportedOn indica qué versión de sistema operativo respeta esta directiva, y finalmente, los elementos enabledvalue y disabledvalue especifican qué valores se incluyen en el Registro cuando esta directiva se establece como habilitada y deshabilitada.
Se trata de una directiva bastante sencilla de activación/desactivación. Al igual que en la sintaxis ADM, es posible crear elementos de interfaz de usuario más complejos con el editor de directivas de grupo. Cuándo lo hace dentro de ADMX, la sintaxis se ve algo más implicada e incluye un atributo de presentación que hace referencia a una parte del archivo ADML en la que pueden encontrarse las etiquetas de texto del elemento de la interfaz de usuario. Pero más allá de esto, la sintaxis ADMX no es mucho más complicada en realidad. Algo que se debe tener presente es que algunos de los nombres de las etiquetas han cambiado entre ADM y ADMX. De modo que, por ejemplo, en lenguaje ADM teníamos las etiquetas "edittext" y "listbox". En ADMX, se hace referencia a dichas etiquetas como "text" y "list" dentro del archivo ADMX. Esos elementos tendrán las entradas correspondientes en el archivo ADML que especifica el texto que aparece con ellos.
Como puede que ya sepa, un administrador puede cargar un archivo ADM (heredado) en el editor de objetos de directiva de grupo de Windows Vista. A menudo me preguntan si Microsoft ofrecerá una utilidad para convertir los archivos ADM personalizados a la sintaxis ADMX. De hecho, Microsoft se unió a FullArmor Corp. con el fin de lanzar al mercado una herramienta gratuita llamada ADMX Migrator. Esta herramienta hace dos cosas. Primero, convierte los archivos ADM antiguos personalizados al formato ADMX (consulte la Figura 5 para obtener un ejemplo del uso de la herramienta para convertir el gpolog.adm personalizado).
Figura 5 ADMX Migrator
Figura 5 ADMX Migrator (Hacer clic en la imagen para reducirla)
Figura 5 ADMX Migrator
Figura 5 ADMX Migrator (Hacer clic en la imagen para ampliarla)
La segunda cosa que ofrece es un editor de ADMX que le permite crear archivos ADMX nuevos desde cero. Puede descargar esta herramienta en go.microsoft.com/fwlink/?LinkID=77409.

Almacenamiento de ADMX
El otro cambio destacable que quiero tratar es la forma en la que se almacenan los archivos ADMX y ADML para el uso. En las versiones de Windows anteriores a Windows Vista, al editar un GPO nuevo, los archivos ADM se copiaban automáticamente desde la estación de trabajo local en la que se realizaban las tareas de edición a la parte SYSVOL del GPO en un controlador de dominio dentro de su dominio Active Directory. Estos ADM se replicaban posteriormente a cada DC de un dominio, para cada GPO creado. Esta acción suponía un gasto excesivo de ancho de banda y de almacenamiento en disco, especialmente en entornos grandes con decenas o cientos de GPO. Windows Vista da la vuelta a este proceso. De forma predeterminada, cuando crea un GPO basado en Active Directory en una estación de trabajo de Windows Vista, las directivas de la plantilla administrativa que aparecen en el editor de directivas de grupo se cargan desde la carpeta c:\windows\policydefinitions en el equipo desde el que está editando el GPO.
Los archivos ADMX y ADML no se copian en SYSVOL; sólo se mencionan de forma local. De esta forma se elimina la carga de almacenamiento y red que los ADM suponen para el entorno de las directivas de grupo. Pero puede ser aún mejor. Windows Vista es compatible también con un almacén central, un repositorio de plantillas administrativas. Lo cual dirige el modo de controlar de forma eficaz los archivos ADMX utilizados para editar los GPO, con independencia de quién los edite. Se hace copiando todos los archivos ADMX y ADML oficiales (y cualquiera personalizado que haya creado) en una ubicación de la red, y entonces, cualquier edición posterior de directivas de grupo de estaciones de trabajo de Windows Vista hace referencia a dichas versiones basadas en red, en lugar de a cada versión local individual. La configuración de un almacén central es una tarea sencilla que se realiza una vez por dominio. Sólo tiene que seguir los pasos de la barra lateral "Creación de un almacén central".

Resumen
El nuevo formato ADMX de Windows Vista es una clara mejora con respecto a los archivos ADM utilizados en versiones anteriores de sistema operativo. El uso de XML proporciona un marco más limpio para editar y buscar estos archivos. El traslado de cadenas específicas del idioma a archivos independientes hace que la edición de directivas de grupo de varios idiomas sea perfecta, y el almacén central elimina la necesidad de almacenar y actualizar todos sus GPO con copias de archivos ADM. Todo esto hace que obtener más información sobre ADMX sea un paso inteligente.
Creación de un almacén central
La creación del almacén central es relativamente directa. Siga estos pasos sencillos para crear uno en su dominio Active Directory:
Paso 1: Abra el Explorador y desplácese hasta el recurso compartido SYSVOL en el DC del emulador de PDC de su entorno (puede utilizar cualquier DC, pero en el propietario de la función PDC es generalmente donde se centra cualquier cambio en las directivas de grupo).
Paso 2: Vaya hasta la carpeta de directivas bajo SYSVOL y cree una carpeta nueva llamada PolicyDefinitions.
Paso 3: Copie el contenido de la carpeta C:\windows\policydefinitions de su estación de trabajo de Windows Vista en la nueva carpeta PolicyDefinitions, incluida la carpeta ADML dependiente del idioma (por ejemplo, en-us en equipos con inglés de EE.UU.).
Una vez que los archivos ADMX y ADML se copian en la carpeta del almacén central, el editor de objetos de directivas de grupo de Windows Vista comenzará a hacer referencia a los archivos que se encuentran allí, y omitirá los que están almacenados localmente.

Darren Mar-Elia es MVP en directivas de grupo de Microsoft, creador del famoso sitio de directivas de grupo www.gpoguy.com y coautor de la guía Microsoft Windows Group Policy Guide (Microsoft Press, 2005) (en inglés). Es también CTO y fundador de SDM Software, Inc. Póngase en contacto con él en la dirección Darren@gpoguy.com


 Administraci&#243;n de Windows: Gu&#237;a de soluci&#243;n de problemas de directiva de grupo
Administración de Windows Derek Melber

Guía de solución de problemas de directiva de grupo
Resumen:
  • Problemas de GPO comunes
  • Reglas de directiva de grupo
  • Solución de problemas de GPO
  • Herramientas de solución de problemas

Microsoft Active Directory se ha convertido en un componente importante de muchas infraestructuras de TI. Una de las características más importantes de Active Directory es la directiva de grupo, que permite a los administradores centralizar la administración de controladores de dominio, servidores miembro y escritorios.
Aunque la directiva de grupo ofrece claramente muchas ventajas, tiene un pequeño problema. Su diseño e implementación pueden resultar complejos en una organización grande e incluso puede ser más problemática para solucionar problemas cuando algo sale mal. En este artículo, profundizaré en la estructura de la directiva de grupo y mostraré cómo solucionar sus problemas. Al final, tendrá todas las armas que necesita para enfrentarse a casi cualquier problema de directiva de grupo.

Configuración problemática
Hay muchas partes móviles dentro de la directiva de grupo, especialmente con respecto a la manera en que se comunica con el diseño y la implementación generales de Active Directory®. Al solucionar muchas clases de problemas de acceso y red, siempre debe incluir Active Directory y los principios básicos de la implementación de directiva de grupo en la búsqueda de una solución. Para empezar el proceso de solución de problemas, centrémonos en la configuración de directiva de grupo que puede ser incorrecta y luego pasaremos a problemas más complejos que pueden hacer que la directiva de grupo funcione incorrectamente.
La configuración de directiva de grupo la consultan los administradores de Active Directory que usan archivos de plantilla administrativa (archivos ADM o ADMX) y el Editor de objetos de directiva de grupo o GPEdit (que se inicia al ejecutar gpedit.msc). Con GPEdit, el administrador crea archivos de objeto de directiva de grupo o GPO. Los GPO están configurados para aplicarse (o no aplicarse) a equipos y usuarios dentro de la estructura de Active Directory. Hay una serie de reglas que los GPO deben seguir para funcionar correctamente. Veamos esas reglas.
El GPO debe estar vinculado Cuando se crea un GPO nuevo, no puede estar vinculado a ningún nodo dentro de Active Directory. Aunque el GPO se puede editar y modificar, no afectará a ningún objeto hasta que se vincule a un nodo. Para asegurarse de que el GPO está vinculado correctamente, puede ver la ventana de información en la Consola de administración de directivas de grupo (GPMC) que se muestra en la Figura 1.
Figura 1 Los vínculos de GPO se muestran con claridad
Figura 1 Los vínculos de GPO se muestran con claridad (Hacer clic en la imagen para reducirla)
Figura 1 Los vínculos de GPO se muestran con claridad
Figura 1 Los vínculos de GPO se muestran con claridad (Hacer clic en la imagen para ampliarla)
GPO debe tener como destino el objeto correcto Como sabe, la directiva de grupo debe tener como destino los objetos correctos en Active Directory. Sin embargo, esto a veces se pasa por alto en medio de un ejercicio de solución de problemas. Dentro de un GPO, hay dos categorías principales: equipo y usuario. Cuándo configure un GPO, esté seguro de saber si es un equipo o un objeto de usuario. Así, podrá comprobar que los tipos de objeto correctos se colocan en la unidad organizativa (OU) a la que se vincula el GPO.
Los GPO no se aplican a grupos Aunque puede desear que así sea, un GPO no se puede aplicar a un objeto de grupo de seguridad de Active Directory. Los único dos objetos que puede configurar un valor de GPO son equipos y usuarios. Los GPO no pueden configurar objetos a través de la pertenencia a grupos. Por ejemplo, si hay un GPO vinculado a la unidad organizativa de finanzas (Finance), como se muestra en la Figura 2, los únicos objetos que se verán afectados por la configuración son Derek y Frank. La configuración del GPO no afectará a los miembros del grupo Marketing, con independencia de quién pertenezca a ese grupo.
Figura 2 Unidad organizativa de finanzas (Finance) y objetos incluidos
Figura 2 Unidad organizativa de finanzas (Finance) y objetos incluidos (Hacer clic en la imagen para reducirla)
Figura 2 Unidad organizativa de finanzas (Finance) y objetos incluidos
Figura 2 Unidad organizativa de finanzas (Finance) y objetos incluidos (Hacer clic en la imagen para ampliarla)
El objeto de destino debe estar en la ruta de acceso del GPO Cuando advierta que un valor de GPO no afecta a un objeto como debe, hay otro valor más importante: el objeto debe estar dentro del ámbito de administración (SOM) del GPO. Esto significa que el objeto debe estar ubicado en el nodo donde el GPO está vinculado (incluso con un nodo secundario será suficiente). Por ejemplo, ninguno de los objetos de la unidad organizativa Marketing se verá afectado por un GPO que esté vinculado a la unidad organizativa de finanzas, como se muestra en la Figura 3. El SOM de un GPO abarca desde el nodo donde está vinculado, hasta el final de la estructura de Active Directory.
Figura 3 Cuando las unidades organizativas están en el mismo nivel, los GPO sólo se aplican a la unidad organizativa a la que están vinculados
Figura 3 Cuando las unidades organizativas están en el mismo nivel, los GPO sólo se aplican a la unidad organizativa a la que están vinculados (Hacer clic en la imagen para reducirla)
Figura 3 Cuando las unidades organizativas están en el mismo nivel, los GPO sólo se aplican a la unidad organizativa a la que están vinculados
Figura 3 Cuando las unidades organizativas están en el mismo nivel, los GPO sólo se aplican a la unidad organizativa a la que están vinculados (Hacer clic en la imagen para ampliarla)
Los GPO se deben habilitar Cuando se crea un GPO, no se configura para realizar ninguna modificación en objetos de destino. Sin embargo, se habilita para las partes de equipo y usuario. Si cualquiera de estas partes se deshabilita, puede ser complicado localizar este problema. Por lo tanto, cuando solucione problemas de un GPO que no se aplicará, es recomendable comprobar si todos o alguno de los GPO están deshabilitados. Para ello, puede consultar Group Policy Objects (Objetos de directiva de grupo) | Account Policy (Directiva de cuentas) en la GPMC y comprobar el estado de GPO.
Algunos valores necesitan un reinicio Cuando un valor de GPO no funciona correctamente, quizás se deba al procesamiento inherente de los GPO. Cuando se desencadena la actualización en segundo plano periódica de los GPO, sólo puede procesar parte de los valores de GPO, pero no todos. Por lo que, aunque haya creado un valor, puede que aún no haya surtido efecto. Hay algunos valores que se clasifican como directivas de primer plano y sólo se aplican al reiniciar el equipo o cuando el usuario cierra sesión y luego vuelve a iniciarla. Algunos ejemplos de valores que se comportan así son la instalación de software, la redirección de carpetas y la aplicación de script.

Aplicación sincrónica y asincrónica de la configuración
En un GPO, puede configurar cómo se realiza la aplicación de directivas en el reinicio y el inicio de sesión. Los cambios que puede realizar ofrecerán acceso inmediato al escritorio mientras las directivas se aplican, o bien asegúrese de que todas directivas se aplican antes de que el usuario tenga acceso al escritorio. La Figura 4 muestra cómo se comporta cada sistema operativo de forma predeterminada. Si desea modificar este comportamiento, puede cambiar el siguiente valor de directiva:
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 Procesamiento predeterminado en cliente (Close Figure 4)

Sistema operativo | Inicio | Inicio de sesión | Actualización de directiva
Windows 2000 | Sincrónicamente | Sincrónicamente | Asincrónicamente
Windows XP Professional | Asincrónicamente | Asincrónicamente | Asincrónicamente
Windows Server 2003 | Sincrónicamente | Sincrónicamente | Asincrónicamente
La mayoría de los administradores prefieren tener una aplicación sincrónica de las directivas, con el fin de garantizar que todas se aplican antes de que el usuario pueda tener acceso al escritorio. Esto garantiza que todos los valores de configuración y seguridad se aplican antes de que el usuario pueda realizar cualquier trabajo. Tenga en cuenta que éste no es el estado predeterminado en Windows® XP Professional, que se ha optimizado para una velocidad mejorada de inicio de sesión.

Modificación de herencia predeterminada
Hay cuatro métodos diferentes que se pueden usar para modificar la herencia predeterminada de procesamiento de GPO. Estas opciones son eficaces y se deben usar con moderación, ya que pueden causar modificaciones considerables en el comportamiento del procesamiento de directivas de grupo. Asimismo, sus problemas pueden ser difíciles de resolver. Las opciones para modificar la herencia predeterminada incluyen los siguientes cuatro valores y configuraciones:
  • Bloqueo de herencia de directivas
  • Cumplimiento de GPO
  • Filtrado de GPO de la lista de control de acceso (ACL)
  • Filtros del instrumental de administración de Windows (WMI)
Puesto que estos valores se deben usar con moderación, debe ser fácil registrar cuándo se usan. Para averiguar si estas opciones están en uso, consulte la GPMC. El bloqueo de la herencia se realiza en el dominio o en el nodo de la unidad organizativa (OU) en la GPMC. El cumplimiento de GPO, el filtrado de ACL y el filtrado de WMI se establecen en cada GPO.
También puede ejecutar el comando Gpresult desde el equipo de destino para hacerse una idea de si alguno de estos valores prohíbe la aplicación de las directivas. Para obtener una vista más exhaustiva del conjunto resultante de directivas que se aplica, puede agregar el conmutador /v al comando Gpresult, que ofrecerá la información detallada.

Problemas de plantillas ADM
Cuándo intente configurar los valores de un GPO en la sección Plantillas administrativas, trabajará con las plantillas ADM. Además de las plantillas ADM que se suministran con el sistema operativo, puede personalizar las que desee usar en un GPO. El código de la plantilla ADM crea las carpetas y las directivas del Editor de directivas de grupo en el nodo Plantillas administrativas. Sin embargo, si la plantilla ADM está dañada, no se encuentra o no está configurada correctamente, es bastante probable que no vea parte o la totalidad de la configuración en el editor. A continuación se muestran otros problemas que se deben evitar cuando se usen plantillas ADM.
Plantillas ADM que faltan Al editar un GPO y descubrir que hay valores en una plantilla personalizada ADM que no aparecen en el editor, debe importar la plantilla ADM en el GPO. Para ello, sólo tiene que hacer clic con el botón secundario del mouse en el nodo Plantillas administrativas del editor y seleccionar Agregar o quitar plantillas.
Preferencias que faltan Hay dos tipos de configuración que se pueden crear en un GPO personalizado: preferencias y directivas. Las directivas son los valores predeterminados de Microsoft que se encuentran en una de las cuatro subclaves del registro; cada una termina con el texto "Directivas" (Policies). Las preferencias son las modificaciones del registro "de estilo anterior" que no se encuentran en ninguna de las cuatro subclaves y que son difíciles de invertir una vez configuradas. Estas preferencias no aparecen en el editor de forma predeterminada. Debe activarlas para que aparezcan en el menú Ver de la barra de herramientas. Aquí, seleccione Filtrado y active la casilla de verificación "Mostrar sólo valores de directivas que pueden ser totalmente administrados". De esta forma, se mostrarán inmediatamente las preferencias configuradas en las plantillas ADM personalizadas que ha importado.

Herramientas útiles
Hay muchas herramientas disponibles para ayudarle a localizar los problemas de directiva de grupo. Algunas están integradas en el sistema operativo y otras pueden descargarse e instalarse. A continuación, voy a describir las herramientas correspondientes de forma que pueda elegir la correcta para su tarea.
Dcgpofix Puede ocurrir que haya un problema con uno de los dos GPO predeterminados: Directiva predeterminada de dominio y Directiva predeterminada de controladores de dominio. Si uno o ambos de los GPO están dañados, tanto como para que no pueda corregirlos, o se ha producido algún otro problema desconocido, puede usar la herramienta dcgpofix para revertirlos al estado predeterminado. Esta herramienta se incluye en Windows Server® 2003. No debe ejecutar esta herramienta en ningún controlador de dominio de Windows 2000; use Recreatedefpol en su lugar. Y recuerde, al usar esta herramienta, perderá cualquier configuración personalizada.
Recreatedefpol Esta herramienta es similar a Dcgpofix, pero para los servidores Windows 2000. Puede devolver los dos GPO predeterminados al estado de recién instalados. Esta herramienta sólo se debe usar en una situación de recuperación de desastres, no para mantenimiento rutinario de GPO. Puede descargar esta herramienta.
Visor de eventos El Visor de eventos tiene información en abundancia con respecto a directiva de grupo. Desgraciadamente, requiere consultar todos los archivos de registro diferentes para encontrar las entradas de directiva de grupo. Encontrará entradas relacionadas con aplicación, réplica y actualización de directivas, que pueden ser útiles al tratar de localizar un problema. No siempre hay mucha información sobre errores específicos de directiva de grupo en los registros de eventos, pero recuerde que siempre puede buscar en TechNet si encuentra errores que no puede identificar.
Gpresult Esta herramienta sólo se puede ejecutar en el equipo de destino, aunque ofrece información acerca del Conjunto resultante de directivas (RSoP), los GPO bloqueados, los permisos de GPO, etc. El uso del comando con el conmutador /v mostrará una gran cantidad de información acerca de los GPO que afectan el equipo y acerca de cuentas de usuario asociadas al inicio de la sesión actual.
Gpupdate Si va a implementar la configuración nueva de GPO o trata de garantizar que todo el procesamiento de GPO se ha llevado a cabo, puede usar la herramienta Gpupdate. Se trata de una herramienta de línea de comandos que se suministra con el sistema operativo (Windows XP y posterior). Al ejecutarla, activará una actualización en segundo plano que aplicará toda la configuración de GPO que sigue este tipo de actualización. Si agrega el conmutador /force, volverá a aplicar toda la configuración de GPO, incluso si no ha habido ningún cambio en el GPO desde la última actualización. La ejecución de este comando antes de ejecutar el comando Gpresult constituye un método muy eficaz para seguir los problemas de GPO.
Gpotool Puesto que los GPO se replican desde el controlador de dominio donde los cambios de GPO ocurren inicialmente hasta el resto de controladores de dominio, existe la posibilidad de que se produzca un error de réplica o no converja de manera eficaz. El resultado es la incoherencia o error de los cambios en la aplicación correcta en los equipos de destino. Herramientas tales como Gpresult y RSOP pueden ayudar a determinar qué GPO se han aplicado, aunque esta herramienta, Gpotool, puede ayudar a determinar si los GPO de cada controlador de dominio son coherentes. La herramienta forma parte del Kit de recursos de Windows Server 2003 en go.microsoft.com/fwlink/?LinkId=77613.
Replmon Al solucionar problemas de réplicas de GPO de un controlador de dominio a otro, es importante saber qué herramientas puede usar para que las réplicas funcionen. Puesto que hay dos partes de un GPO que se deben replicar, hay dos partes a las que se debe prestar atención. La primera, que es el contenido de SYSVOL en cada controlador de dominio, se controla mediante el servicio de replicación de archivos (FRS). Realmente no hay mucho que pueda hacer para controlar esta réplica, excepto deshabilitar y habilitar el servicio para que pueda desencadenar un intervalo de réplica. La otra parte del GPO, que se almacena en Active Directory, está controlada por la réplica de Active Directory. Esta réplica se puede controlar entre controladores de dominio del mismo sitio de Active Directory mediante Sitios y servicios de Active Directory. Sin embargo, si necesita desencadenar una réplica entre controladores de dominio en sitios diferentes de Active Directory, debe usar una herramienta como Replmon. Replmon puede forzar la réplica de la base de datos de Active Directory a través de los límites del sitio, mientras que Sitios y servicios de Active Directory no puede. Por lo tanto, cuando haya información no coincidente de directiva de grupo, que se almacene en Active Directory, puede usar Replmon para desencadenar un proceso de réplica con el fin de conseguir que la información converja en todos los controladores de dominio. Replmon forma parte del kit de recursos y las herramientas de soporte técnico de Windows XP. Puede descargar esta herramienta en go.microsoft.com/fwlink/?LinkId=77614.
RSOP Al igual que la herramienta de línea de comandos Gpresult, RSOP ofrece una interfaz gráfica para consultar la configuración aplicada por todos los GPO. RSOP.MSC es una herramienta integrada para Windows XP Professional y Windows Server 2003. La herramienta ofrece los resultados de toda la configuración de directivas aplicada en un formato semejante al del Editor de objetos de directiva de grupo, como se muestra en la Figura 5.
Figura 5 Herramienta Conjunto resultante de directivas
Figura 5 Herramienta Conjunto resultante de directivas

Conclusión
La solución de problemas de directiva de grupo no es la tarea más fácil del mundo. De hecho, como este artículo muestra, la directiva de grupo puede ser bastante compleja. Al tratarla en la solución de problemas, debe entender la arquitectura principal y el procesamiento general propio de la directiva de grupo. También debe conocer cómo se actualiza, se replica, se procesa y se aplica un GPO. Si domina todo estos conceptos, la solución de cualquier problema de directiva de grupo será mucho más fácil. Siguiendo las instrucciones de este artículo y usando las herramientas correctamente, estará listo para enfrentarse a todos los problemas de directiva de grupo que pueda encontrar.

Derek Melber es director de soluciones de educación, certificación y compatibilidad para DesktopStandard, una subsidiaria que pertenece por completo a Microsoft. Derek es coautor de Microsoft Windows Group Policy Guide (Microsoft Press, 2005). También ha escrito una serie de libros sobre auditoría de seguridad de Windows (www.theiia.org). Póngase en contacto con él en la dirección derekm@desktopstandard.com.


 Administraci&#243;n de Windows: Supervisi&#243;n de Active&#160;Directory con MOM
Administración de Windows John Hann

Supervisión de Active Directory con MOM
Resumen:
  • Módulos de administración para Active Directory
  • Sugerencias de personalización para MOM
  • Ajuste de alertas

Los módulos de administración son la parte vital de Microsoft Operations Manager (MOM) 2005 y son lo que lo diferencia de otros productos de administración. MOM usa módulos de administración para reunir reglas, informes, tareas y vistas, y su ámbito puede estar limitado a una aplicación específica
o servicio, como Active Directory. Los equipos de producto de Microsoft crean los módulos de administración para las aplicaciones que desarrollan y se aseguran de que MOM refleje el amplio conocimiento que del producto tiene el equipo. Además, los módulos de administración pueden personalizarse para ajustarse al entorno de TI. Así contará con reglas que supervisan y administran el producto de acuerdo con el servidor y el entorno de aplicaciones.
No sólo hay un módulo de administración específico para Active Directory®, sino también una gran cantidad de módulos de administración para medir el estado de los servicios de directorio desde el sistema operativo de Windows Server®, pasando por el protocolo de configuración dinámica de host (DHCP), DNS y el servicio de replicación de archivos (FRS). Repasemos estos módulos de administración con todo detalle para que conozca mejor la administración de un extremo a otro de Active Directory, que es posible a través de MOM.

Módulo de administración de DHCP
El módulo de administración del servicio DHCP supervisa el servicio DHCP que se ejecuta en Windows NT®, Windows ® 2000 y Windows Server 2003. Es una buena idea supervisar DHCP, puesto que puede saber si los clientes tienen los problemas de conexión a la red. También será puesto sobre aviso frente a servidores DHCP (no autorizados) malintencionados que se ejecuten en el entorno. El paquete de descarga para este módulo de administración contiene una guía que muestra las reglas y los informes, así como los escenarios de supervisión y la implementación. También puede encontrarse valiosa documentación y guías adicionales en el sitio web de MOM 2005 de TechNet (microsoft.com/technet/prodtechnol/mom/mom2005).
Cuanto más nueva sea la versión de Windows en la que ejecute el servicio DHCP, mayor será la instrumentación y la funcionalidad de MOM 2005 para la administración. Por lo tanto, obtendrá más información de un servidor DHCP de Windows Server 2003 que de un servidor DHCP de Windows NT. Por ejemplo, un servidor DHCP que se ejecuta en Windows Server 2003 puede tener sus superámbitos supervisados, mientras que el módulo de administración de DHCP sólo supervisa ámbitos normales en un servidor DHCP de Windows 2000. Puede excluir ámbitos de la supervisión colocándolos como un parámetro para la secuencia de comandos de supervisión.
Como se ha mencionado anteriormente, el módulo de administración de DHCP es compatible con servidores DHCP que se ejecutan en Windows NT, en Windows 2000 Server y en Windows Server 2003. Los grupos de equipos se rellenan a través de fórmulas que usan la versión de sistema operativo y si el servidor aloja el servicio de servidor DHCP.
El módulo de administración de DHCP no es compatible con configuraciones de bajos privilegios. La cuenta de acción de agente debe ser un miembro del grupo Administradores local. La supervisión sin agente es compatible, pero las tareas no se admiten en una configuración sin agente. La Figura 1 incluye una lista de los informes que están disponibles en el módulo de administración de DHCP.
Figure 1 Informes de servicio DHCP (Close Figure 1)

Todos los servidores DHCP
Todos los servidores DHCP autorizados
Historial de rendimiento: longitud de cola activa
Historial de rendimiento: conflicto de comprobación de longitud de cola
Historial de rendimiento: disminuciones por segundo
Historial de rendimiento: detecciones por segundo
Historial de rendimiento: milisegundos por módulo (prom)
Historial de rendimiento: NACK por segundo
Historial de rendimiento: direcciones de ámbito libres
Historial de rendimiento: direcciones de ámbito en uso
Historial de rendimiento: direcciones de superámbito libres
Historial de rendimiento: direcciones de superámbito en uso
Puede descargar el módulo de administración de DHCP en go.microsoft.com/fwlink/?LinkId=79527.

Módulo de administración de DNS
El módulo de administración del servicio de nombres de dominio supervisa el servicio DNS que se ejecuta en Windows 2000 Server y Windows Server 2003. Puesto que es una parte esencial del estado general de una implementación de Active Directory, resulta fundamental supervisar DNS con MOM 2005. El módulo de administración de DNS supervisa los problemas de resolución de nombres, los problemas de base de datos, los problemas de registro, eventos de tiempo de ejecución y errores, así como contadores de rendimiento relacionados.
Para Windows 2000 Server, debe haber instalado un proveedor DNS de Instrumental de administración de Windows (WMI). En concreto, esto permite al módulo de administración de DNS consultar el espacio de nombres DNS de WMI para obtener información y realizar comprobaciones.
Todos los grupos de equipos se rellenan a través de fórmulas que usan la versión de sistema operativo y si el servidor aloja el servicio de servidor DNS para determinar la pertenencia a grupos. El módulo de administración de DNS es compatible con privilegios bajos sólo en Windows Server 2003. En Windows 2000, la cuenta de acción debe ser un miembro del grupo Administradores local. En Windows Server 2003, la cuenta de acción debe ser un miembro de los grupos Usuarios y Usuarios del monitor de sistema locales. Además, la cuenta de acción debe contar con los permisos Administrar registro de auditoría y de seguridad (SeSecurityPrivilege) y Permitir el inicio de sesión local (SeInteractiveLogonRight). La Figura 2 incluye una lista de los informes que están disponibles en el módulo de administración de DNS.
Figure 2 Informes de servicio DNS (Close Figure 2)

Todos los servidores DNS de Windows
Todos los servidores DNS de Windows por zona
Todos los servidores DNS de Windows por servidor
Marcus Oh, MVP para Microsoft® Systems Management Server (SMS), desarrolló una secuencia de comandos que prueba un servidor DNS llamando a nslookup para comprobar la capacidad del servidor DNS a la hora de resolver nombres. Reserve tiempo para consultar esta publicación de blog en marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html; deseará integrar esta secuencia de comandos en su módulo de administración de DNS.
Puede descargar el módulo de administración de DNS en go.microsoft.com/fwlink/?LinkId=79528.

Módulo de Administración de FRS
El módulo de administración de servicio de replicación de archivos de Windows supervisa el servicio FRS que se ejecuta en Windows 2000 y Windows Server 2003. Los controladores de dominio usan FRS para replicar scripts de inicio de sesión e información de directiva de grupo. El módulo de administración de FRS detallará el estado del servicio FRS para cada controlador de dominio.
El módulo usa la herramienta Ultrasound, que está disponible en go.microsoft.com/fwlink/?LinkId=79529. Ultrasound crea un espacio de nombres WMI para FRS en cada controlador de dominio. Tenga en cuenta que Ultrasound requiere una base de datos y almacenará la información del espacio de nombres WMI en cada controlador de dominio para supervisar el estado correspondiente. Con la información de Ultrasound, el módulo de administración de FRS ofrece la supervisión de conjuntos de réplicas, miembros, conexiones, el propio servicio FRS y el servicio de controladores de Ultrasound.
De hecho, debe instalar Ultrasound en un servidor independiente del servidor de administración. Las reglas de Ultrasound generan eventos y alertas en nombre de otros equipos. Para que las reglas de Ultrasound procesen los datos correctamente, debe habilitar el agente de conexiones proxy en la consola de administrador de MOM en cada servidor que ejecute Ultrasound. La Figura 3 incluye los cuatro informes de servicio que están disponibles en el módulo de administración de FRS.
Figure 3 Informes de servicio FRS (Close Figure 3)

Ultrasound: problemas detectados con frecuencia: conexiones más problemáticas
Ultrasound: problemas detectados con frecuencia: miembros más problemáticos
Ultrasound: problemas detectados con frecuencia: conjunto de réplicas más problemático
Ultrasound: problemas detectados con frecuencia: resumen
Los grupos de equipos asociados a este módulo de administración incluyen los servidores de Microsoft Ultrasound 1.0 y los servidores de FRS que se ejecutan en Windows 2000 Server y Windows Server 2003. Todos los grupos de equipos se rellenan a través de fórmulas que usan la versión de sistema operativo y si el servidor aloja el servicio FRS para determinar la pertenencia a grupos. El grupo de servidores de Ultrasound se rellena si el servidor tiene Ultrasound instalado.
Al configurar el módulo de administración de FRS para privilegios bajos, las tareas no funcionan, aunque sí se admite el resto de la funcionalidad del módulo de administración. La cuenta de acción debe tener acceso de lectura a la base de datos de Ultrasound y permiso de ejecución del procedimiento almacenado GetControllerStatusForMOM001. El módulo de administración de FRS admite la supervisión de equipos sin agente y administrados con agente.
Puede descargar el módulo de administración de FRS en go.microsoft.com/fwlink/?LinkId=79530.

Módulo de administración de Windows Server
El módulo de administración de sistema operativo Windows supervisa Windows NT 4.0 Server, Windows 2000 Server y Windows Server 2003. El módulo de administración de sistema operativo informará sobre el estado del sistema operativo para los controladores de dominio y supervisará también los servicios raíz del sistema. El módulo de administración ofrece el estado de los servicios centrales de Windows, la memoria y el rendimiento del procesador, así como el espacio libre en disco y la latencia de éste. Hay cierta superposición entre las reglas de supervisión de este módulo de administración y el resto de los que se tratan en este artículo, aunque ofrece una visión muy completa del estado del controlador de dominio.
La Figura 4 muestra los informes disponibles en el módulo de administración de sistema operativo. Al igual que con los otros módulos de administración, todos los grupos de equipos se rellenan a través de fórmulas que usan la versión de sistema operativo.
Figure 4 Informes de sistema operativo (Close Figure 4)

Análisis de rendimiento de disco
Configuración de sistema operativo
Rendimiento de sistema operativo
Apagado de sistema operativo por evento
Apagado de sistema operativo por servidor
Configuración de almacenamiento de sistema operativo
Instalaciones de software y aplicaciones por aplicación
Instalaciones de software y aplicaciones por instancia
Instalaciones de software y aplicaciones por servidor
Confiabilidad: errores de aplicación por aplicación
Confiabilidad: errores de aplicación por equipo
Confiabilidad: errores de aplicación por evento
Confiabilidad: errores de sistema operativo por equipo
Confiabilidad: errores de sistema operativo por evento
Confiabilidad: errores de sistema operativo por código de detención
Historial de rendimiento: historial de rendimiento
Historial de rendimiento: informes adicionales
Al configurar el módulo de administración de sistema operativo para el funcionamiento con privilegios bajos, Windows 2000 necesita que la cuenta de acción sea un miembro del grupo Administradores local. Windows Server 2003 necesita que la cuenta de acción sea un miembro de los grupos Usuarios y Usuarios del monitor de sistema locales, y que cuente con los permisos Administrar registro de auditoría y de seguridad (SeSecurityPrivilege) y Permitir el inicio de sesión local (SeInteractiveLogonRight). La mayor parte del módulo de administración de sistema operativo, menos las tareas, es compatible con los equipos supervisados sin agente.
Puede descargar el módulo de administración de sistema operativo en go.microsoft.com/fwlink/?LinkId=79531.

Módulo de administración de Active Directory
El módulo de administración de Active Directory es muy amplio y sus reglas abarcan tanto Windows 2000 Server como Windows Server 2003. El módulo de administración de Active Directory engloba cinco áreas de reglas: supervisión del lado cliente, supervisión de confianza, supervisión de réplica y detección de topologías, más las reglas que abarcan los sistemas operativos Windows 2000 Server y Windows Server 2003. Como se ha indicado anteriormente, las versiones más nuevas de Windows permiten una mayor instrumentación y, por lo tanto, una supervisión adicional. Por ejemplo, el módulo de administración es compatible con la supervisión de confianza en Windows Server 2003, pero no en Windows 2000.
El módulo de administración de Active Directory crea varios grupos que usa para aplicar las reglas a equipos específicos. Las reglas de supervisión del lado cliente usan un grupo llamado Active Directory Client Side Monitoring (Supervisión del lado cliente de Active Directory). Los equipos que tienen instalado el agente MOM se colocarán en este grupo para supervisar y administrar las reglas. Yo puse unos cuantos equipos de escritorio con la licencia del agente en este grupo, así como algunos servidores Exchange. Los servidores Exchange usan Active Directory exhaustivamente y constituirían un indicador principal de un problema en curso. Los equipos de escritorio del grupo pueden ayudarle a medir la experiencia de usuario final. Las reglas de supervisión del lado cliente usan secuencias de comandos para probar la conectividad a controladores de dominio, consultándolos a través de LDAP y notificando de los errores. Es importante tener en cuenta que las reglas de supervisión del lado cliente sólo pueden aplicarse a equipos administrados con agente que tienen habilitadas las conexiones proxy, pero no son controladores de dominio.
Las reglas de supervisión de confianza usan un grupo llamado Active Directory Trust Monitoring (Supervisión de confianza de Active Directory). Los equipos con Windows Server 2003 también se colocarían en este grupo para probar las confianzas. Windows Server 2003 tiene un espacio de nombres WMI para la supervisión de confianza. Estas reglas usan una secuencia de comandos para consultar el espacio de nombres WMI. Cuándo se detectan errores de confianza con otros dominios, estas reglas le pondrán sobre aviso.
Hay muchas reglas del módulo de administración de Active Directory que se aplican a Windows 2000 Server o Windows Server 2003. Dichas reglas marcan las diferencias de implementación de Active Directory entre los dos sistemas operativos. Sin embargo, la mayor parte del módulo de administración de Active Directory está en las reglas combinadas para ambos sistemas operativos. Algunas de estas reglas incluyen secuencias de comandos para probar la conectividad entre controladores de dominio, los elementos que contienen la función Operaciones de maestro único flexible (FSMO), el tamaño de base de datos del árbol de información de directorios (DIT), validar el procesamiento de directivas de grupo, la inspección del comprobador de coherencia de información (KCC) y la prueba del servicio de mensajería entre sitios.
La supervisión de réplica es el eje del módulo de administración de Active Directory. Los dos grupos Active Directory Replication Latency Data Collection Sources (Orígenes de recopilación de datos de latencia de réplica de Active Directory) y Active Directory Replication Latency Data Collection Targets (Destinos de recopilación de datos de latencia de réplica de Active Directory) permiten configurar los controladores de dominio usados sólo para notificar la supervisión de réplica. La latencia de replica se calcula para cada miembro de los grupos de recopilación de datos. Los contadores de rendimiento se rellenan con el tiempo que tardan las actualizaciones en replicarse en cada uno de los miembros de grupo. La latencia de réplica de empresa se calcula y notifica (y se generan las alertas) si excede los umbrales definidos. Tenga en cuenta que debe haber instalado un espacio de nombres WMI para la supervisión de réplica en Windows 2000 Server.
La detección de topologías en el módulo de administración de Active Directory se usa para crear diagramas de la implementación. Estos útiles diagramas pueden exportarse a Microsoft Office Visio®. MOM construye los diagramas en tiempo real, de forma que el usuario puede crear una versión actualizada en apenas unos segundos.
En Vistas de diagramas de la Consola del operador de MOM 2005, hay tres diagramas del módulo de administración de Active Directory. El diagrama de objetos de conexión interrumpida (consulte la Figura 5) mostrará cualquier conexión que esté en estado de error. Este diagrama puede estar en blanco si no hay ningún error de conexión.
Figura 5 Conexiones interrumpidas resaltadas en la vista de diagrama
Figura 5 Conexiones interrumpidas resaltadas en la vista de diagrama
El diagrama de objetos de conexión resalta las conexiones entre controladores de dominio. El diagrama de vínculos de sitios muestra cada sitio de Active Directory, encapsulando los controladores de dominio correspondientes de ese sitio y los vínculos de conexión del sitio.
Puesto que los diagramas creados por MOM para estas vistas son dinámicos, puede exportarlos a Visio para una edición y personalización sencillas. Por ejemplo, la Figura 6 muestra el diagrama de vínculos de sitios en proceso de edición en Visio.
Figura 6 Edición de un diagrama de vínculos de sitios en Visio
Figura 6 Edición de un diagrama de vínculos de sitios en Visio (Hacer clic en la imagen para reducirla)
Figura 6 Edición de un diagrama de vínculos de sitios en Visio
Figura 6 Edición de un diagrama de vínculos de sitios en Visio (Hacer clic en la imagen para ampliarla)
La Figura 7 incluye una lista de los informes que están disponibles en el módulo de administración de Active Directory. Los grupos de equipos asociados a este módulo de administración se muestran en la Figura 8. Como puede ver, los grupos de equipos de Active Directory se rellenan por pertenencia explícita; los grupos de equipos de Windows se rellenan según la versión del sistema operativo y si el equipo es un controlador de dominio.
Figure 8 Grupos de equipos (Close Figure 8)

Supervisión del lado cliente de Active Directory
Datos de latencia de réplica de Active Directory
Orígenes de colección
Datos de latencia de réplica de Active Directory
Destinos de colección
Supervisión de confianza de Active Directory
Controladores de dominio de Windows 2000 Server
Controladores de dominio de Windows Sever 2003
Figure 7 Informes de Active Directory (Close Figure 7)

Controlador de dominio de AD
Elementos que contienen funciones de AD
Objetos de conexión de réplica de AD
Vínculos de sitio de réplica de AD
Espacio en Disco de DC de AD
Cambios de dominio de AD
Errores de autenticación de cuenta de equipo de AD
Ancho de banda de réplica de AD
Latencia de réplica de AD
El módulo de administración de Active Directory se puede configurar para privilegios bajos en controladores de dominio de Windows Server 2003. El módulo de administración no es compatible con la supervisión sin agente. En Windows 2000 Server, la cuenta de acción de agente debe estar en el grupo Admins. del dominio o Administradores local. La cuenta de acción de agente en controladores de dominio de Windows Server 2003 debe tener permisos adicionales con objeto de configurarlos para privilegios bajos, incluida la pertenencia a los grupos Usuarios y Usuarios del monitor de sistema, el acceso a registros de eventos y los privilegios SeSecurityPrivilege, SeAuditPrivilege y SeInteractiveLogonRight. Asimismo, se necesita el siguiente acceso: acceso completo al contenedor CN=MomLatencyMonitors en Active Directory para la supervisión de réplica, acceso de lectura a los directorios que contienen la base de datos de NTDS.dit y los archivos de registro, y acceso de lectura a la clave de registro siguiente:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
Si supervisa confianzas en Windows Server 2003, tenga en cuenta que la secuencia de comandos de supervisión de confianza de AD necesita que la cuenta de acción de agente pertenezca a los grupos Admins. del dominio o Administradores.
Puede descargar el módulo de administración de Active Directory de go.microsoft.com/fwlink/?LinkId=79540.

Personalización de MOM para Active Directory
El módulo de administración de Active Directory tiene que estar configurado o las alertas mantendrán ocupada por completo a la consola. El momento más ruidoso del módulo de administración de Active Directory ocurre cuando un controlador de dominio se reinicia (parece como si se activarán todas las posibles alertas). Lo malo es que no es fácil detener esta situación. Lo mejor es usar el modo de mantenimiento de MOM para controlar las alertas durante las ventanas de mantenimiento anticipado. El propósito del modo de mantenimiento es resolver automáticamente las alertas de los controladores de dominio para no ocupar la consola.
Asegúrese de configurar el grupo Active Directory Client Side Monitoring (Supervisón del lado cliente de Active Directory) colocando equipos cliente y servidores adecuados en el mismo. Las reglas asociadas a este grupo ayudarán a determinar el estado de las FSMO y la conectividad a éstas.
Hay reglas del rendimiento que usan umbrales para enlazar a las FSMO mediante LDAP, PING, y DNS con el fin de comprobar la conectividad. Estas reglas se ubican en las reglas de rendimiento de disponibilidad de Active Directory. Debe personalizar los umbrales usados por estas reglas definiendo la gravedad de las alertas. Por ejemplo, los enlaces de FSMO usan valores de atributo que están en segundos. Las reglas de rendimiento de cada función de FSMO usan esta metodología de creación de alertas.
Es importante entender cómo funciona la configuración de Cálculo de gravedad de alerta para la regla de estado. El cuadro de diálogo usa condiciones If-Else para el valor de atributo y define la gravedad de alerta en consecuencia (consulte la Figura 9). Cuando la regla recopila el contador de rendimiento de último enlace creado por la secuencia de comandos de respuesta maestra de op de AD, lo comprueba con los umbrales condicionales definidos por las reglas. Debe configurar estos niveles de alerta diferentes para su entorno.
Figura 9 Definición de reglas de gravedad de alerta
Figura 9 Definición de reglas de gravedad de alerta (Hacer clic en la imagen para reducirla)
Figura 9 Definición de reglas de gravedad de alerta
Figura 9 Definición de reglas de gravedad de alerta (Hacer clic en la imagen para ampliarla)
Recuerde la programación de réplica para cada controlador de dominio. Si un controlador de dominio determinado tiene una programación diferente a otros, sesgará los resultados de latencia de réplica y hará que el usuario defina umbrales más altos. Necesitará definir los parámetros para las secuencias de comandos de réplica con el fin de satisfacer las necesidades de su entorno particular. Es importante tener en cuenta que cuando un controlador de dominio no funciona o tiene problemas de réplica, el resto de controladores de dominio de los grupos pueden notificar un error de réplica para ese evento de controlador de dominio incluso si no se trata de un asociado de réplica directo. Por lo tanto, incluso si coloca el controlador de dominio incorrecto en modo de mantenimiento, el resto de controladores de dominio pueden notificar errores de réplica.
La supervisión de réplica es donde debe gastar la mayor parte de su esfuerzo a la hora de ajustar el módulo de administración de Active Directory. Necesitará ejecutar el módulo de administración en el entorno durante unas semanas para observar cómo pone sobre aviso. Una vez que observe ciertas tendencias, use los informes para resumir las latencias y ajustar los umbrales en consecuencia.
Finalmente, debe aprovecharse de la orientación ofrecida en Alert Tuning Solution Accelerator (en inglés).

Mirando hacia el futuro
MOM 2005 y el módulo de administración de Active Directory permiten supervisar de forma eficaz la implementación de Active Directory en su organización. Con los módulos de administración de Active Directory, DHCP, DNS, FRS y de sistema operativo Windows Server, tiene una mayor capacidad de supervisión de la mayoría de aspectos de la infraestructura, a la vez que protege el estado y la buena conservación de la infraestructura de Active Directory, así como a los usuarios. Al usar los datos expansivos recopilados en el almacén de datos de informe, puede analizar sus datos de rendimiento y eventos para facilitar la planeación de capacidades y las tendencias de rendimiento.
Para encontrar los módulos de administración que he tratado en este artículo, junto con muchos otros, consulte Management Pack Catalog (en inglés).
La actualización siguiente del módulo de administración de Active Directory contendrá la colección habitual de correcciones y cambios a unos pocos umbrales. Más interesantes son las características nuevas planeadas para el lanzamiento siguiente del producto, denominado System Center Operations Manager 2007, que incluyen las capacidades de supervisar varios bosques de un solo grupo de configuración, definir los grupos de controladores de dominio (cada uno con su propia latencia de réplica esperada entre otros grupos) y supervisar controladores de dominio que se ejecutan en la versión siguiente de Window Server. Deténgase en el sitio web de MOM en microsoft.com/mom para obtener más información

John Hann ha trabajado con MOM desde MOM 2000 y ha sido MVP de MOM desde 2004. John participa en MyITForum.com, MOMCommunity.com y LearnMOM.com. Puede ponerse en contacto con él a través de su blog.


 Administraci&#243;n de Windows: Juegos en un entorno seguro
Administración de Windows Matt Clapham

Juegos en un entorno seguro
Resumen:
  • Escritura en carpetas protegidas y claves de registro
  • Errores de protección de copia
  • Problemas de firewall
  • Problemas con clientes de empresa

Actualmente trabajo como administrador de programas de seguridad en Microsoft. También escribo sobre seguridad con cierta frecuencia para TechNet Magazine. No hace falta que diga que me tomo la seguridad muy en serio. Sin embargo, también tengo otros
intereses. En mi tiempo libre, me encanta jugar a juegos basados Windows®. En especial, soy muy aficionado a los juegos de tiro, los simuladores, los juegos de rol y los de estrategia en tiempo real. Sin embargo, hay una trampa. Como mis amigos Jesper Johansson y Aaron Margosis, me niego a ejecutarlos con privilegios administrativos, a menos que sea absolutamente necesario. Hago esto en parte para asegurarme de que sólo obtengo 0wn3d en un juego de red debido a mi falta de habilidades y no como resultado de que alguien me bombardee con un rootkit para ralentizar mi puntería (consulte Quake 3 Buffer Overflow Advisory (en inglés) que aparece en la lista de la barra lateral "Recursos").
Soy tan firme en este sentido que a menudo no puedo jugar a un título nuevo recién lanzado (consulte la Figura 1). Si yo no puedo conseguir que el juego se ejecute en mi cuenta de usuario limitado (LUA) en un cliente del dominio de Small Business Server (SBS) después de instalarlo y actualizarlo en una cuenta de administrador, lo elimino de inmediato. No hay ninguna excusa para que la ingeniería sea tan escasa y no me faltan juegos entre los que poder elegir. Admito que quizás puede parecer una posición un tanto extrema, pero soy firme con respecto a este punto. De todos modos, no estoy en contra de dejar a un lado ciertas debilidades para disfrutar de un rato de juego de calidad, y eso es lo que trataré aquí. De modo que permítanme compartir parte de los problemas relacionados con los juegos que he encontrado y las soluciones que he descubierto que funcionan. Para obtener un resumen rápido de recomendaciones, eche un vistazo en la barra lateral a "Sugerencias para jugar como usuario limitado".
Figura 1 Problema de acceso a archivos al realizar una actualización manual
Figura 1 Problema de acceso a archivos al realizar una actualización manual (Hacer clic en la imagen para reducirla)
Figura 1 Problema de acceso a archivos al realizar una actualización manual
Figura 1 Problema de acceso a archivos al realizar una actualización manual (Hacer clic en la imagen para ampliarla)

Problemas comunes
Este problema de privilegios no es nada nuevo. Hay numerosos juegos, así como otros tipos de programas, que requieren privilegios administrativos para ejecutarse correctamente. Eche un vistazo al artículo de Knowledge Base "Algunos programas no funcionan correctamente si inicia sesión mediante una cuenta de usuario limitada" (consulte support.microsoft.com/kb/307091). Incluye una lista de casi 200 juegos y aplicaciones que presentan dificultades cuando los ejecuta un usuario limitado, incluidos unos cuantos programas de Microsoft.
Quiero ser claro y no considero que requerir privilegios administrativos para instalar o actualizar (manualmente) un juego sea un problema. Esto es necesario hasta que tengamos la capacidad de realizar instalaciones por usuario rutinarias en Windows. Ese día está cerca, pero aún no ha llegado. Sin embargo, una vez que un juego está instalado y actualizado, debería estar listo para que lo ejecutara cualquier usuario en un sistema, incluso uno con privilegios limitados.
Intento de escritura en carpetas protegidas y claves de registro El problema más común que he visto es que un juego falla en el inicio o durante la partida porque intenta escribir en carpetas protegidas o claves del registro (algo común en muchas aplicaciones basadas en Windows). De forma predeterminada, sólo los administradores (y los usuarios avanzados desaprobados) pueden escribir en ciertas carpetas (como % PROGRAMFILES %) y en los subárboles del registro (como HKEY_LOCAL_MACHINE). Los errores en este caso pueden ser relativamente obvios: "Error 42: No se pueden escribir archivos de registro en C:\Archivos de programa\CoolGamesInc\NewestFPS\Logs\” o "El juego no está instalado correctamente, vuelva a instalarlo y reinicie". También he visto algunos ejemplos durante el juego, como mensajes de error que aparecen al guardar la partida. A veces, los desarrolladores de los juegos al menos avisan al usuario de que el juego necesita privilegios administrativos para funcionar, que es lo que me ocurrió con Age of Mythology®. Los juegos multijugador en línea masivos (MMOG) a menudo chocan con los problemas de privilegios, ya que suelen actualizarse automáticamente y el ángulo de actualización automática es un poco más complicado de resolver desde el punto de vista tecnológico. Cuando ejecuté la versión de prueba de EVE Online, advertí que padecía no sólo por colocar archivos de registro en ubicaciones inadecuadas, sino también por tratar de actualizar automáticamente los datos de contenido del juego en la carpeta de la instalación.
Errores de protección de copia La segunda razón más común que he observado por la que los juegos no se inician es que la protección integrada de copia del juego (u otra característica antipiratería) no funciona como usuario limitado. Podría deberse a que el controlador no se inició correctamente o a que algún servicio en segundo plano no se está ejecutando. La representación más común que he visto de este problema es que el juego pide al usuario que inserte un disco (aún cuando los medios necesarios ya están en la unidad). También me he topado con juegos que indican que los privilegios de administrador son necesarios en la creencia errónea de que sólo los administradores pueden ejecutar correctamente la comprobación de la protección de copia. Los peores casos son los que ofrecen mensajes de error mal construidos y sin sentido, que no tienen ninguna referencia en el sitio de soporte técnico del juego.
Error al solicitar una excepción de firewall Los juegos multijugador que se pueden ejecutar en una red local o en Internet son muy comunes, y Windows XP Service Pack 2 (SP2) agregó un mensaje de advertencia que indica al usuario si hay aplicaciones que intentan escuchar en la red. Esto me lleva al siguiente problema común que he observado: los juegos que necesitan una excepción de firewall pero no piden agregar esta excepción en el momento de instalación. Puesto que los usuarios limitados no pueden modificar la configuración de firewall, esta advertencia (consulte la Figura 2) no puede resolverse sin que un administrador realice algunas tareas de configuración. Y lo que es peor: a veces el problema no es obvio, ya que la advertencia aparece en el shell de Windows, no dentro de la interfaz del juego. De hecho, normalmente no veo el mensaje de error hasta que salgo del juego.
Figura 2 La configuración de firewall detiene el entretenimiento
Figura 2 La configuración de firewall detiene el entretenimiento (Hacer clic en la imagen para reducirla)
Figura 2 La configuración de firewall detiene el entretenimiento
Figura 2 La configuración de firewall detiene el entretenimiento (Hacer clic en la imagen para ampliarla)
Problemas con clientes de empresa He descubierto otro problema no relacionado directamente con la ejecución como usuario limitado, pero que vale la pena tratar sin embargo. Mi entorno informático doméstico se ejecuta como una empresa pequeña (no entraré demasiado en detalles aquí, aunque puede leer acerca de ello en el artículo "Master Your Domain: Build a Corporate Network at Home" (en inglés) que Jesper Johansson y yo escribimos para el número de octubre de 2006 de TechNet Magazine. Con SBS 2003 (R2), he configurado un dominio completo de Windows con una carpeta Mis documentos que se redirecciona a un recurso compartido del servidor. Así es como descubrí el último problema más común que voy a tratar: los juegos que no pueden funcionar con clientes de empresa.
Me llevé un doble chasco con Age of Empires® III (AoE3). Como mérito del equipo de desarrollo, el juego se inicia y se reproduce correctamente como usuario limitado. Sin embargo, advertí que los escenarios se cargaban lentamente debido a la gran cantidad de datos de registro que se escriben través de la red. Asimismo, AoE3 perdía mi configuración, los juegos guardados y el progreso siempre que salía del mismo. Los archivos estaban sin duda ahí, en la carpeta Mis documentos, pero, simplemente, el juego no los cargaba. Esto fue toda una decepción, especialmente si tenemos en cuenta que AoE3 es mucho más compatible con LUA si se compara con los títulos anteriores de la serie.
Me he topado con un juego que, al menos, reconoce dichos problemas con clientes de empresa. Cuando probé Fable®: The Lost Chapters™, el juego tuvo la consideración de indicarme que las carpetas remotas de Mis documentos no eran compatibles y, a continuación, se cerró gentilmente. Elogio al equipo de desarrollo por reconocer una situación no compatible y descartarla. Sin embargo, resultaba un poco confuso que el juego se detuviera, ya que sólo quería colocar unos cuantos megabytes de datos en la carpeta Mis documentos.

Soluciones sencillas
He visto estos problemas una y otra vez, en más juegos de los que puedo recordar. Afortunadamente, la mayoría tienen soluciones alternativas adecuadas. Mi solución favorita es abandonar por completo el juego y cambiar a un título que esté preparado para LUA de un publicador diferente. De nuevo, quizás esto suene un poco extremo. Y no es una gran solución si acabo de gastar 60 euros en un título nuevo y no puedo devolverlo porque la caja ya está abierta. De modo que veamos qué formas hay de corregir los juegos que ya tenemos en nuestro poder.Sugerencias para jugar como usuario limitado
  • Realice la actualización a Windows Vista.
  • Pruebe la demostración antes de adquirirlo. De esta forma, verá probablemente cualquier problema de LUA que la versión completa pueda tener.
  • Compruebe la lista de programas que se sabe que tienen problemas de ejecución con LUA ().
  • Busque juegos que lleven el logotipo Diseñado para Windows.
  • Actualice el juego después de la instalación y antes de ejecutarlo como usuario limitado.
  • Cuando encuentre un juego que no funcione como usuario limitado, haga llegar su preocupación al publicador y al servicio de soporte técnico de la empresa.
  • Si es necesario, use una cuenta de usuario avanzado del sistema local.

Corrección de problemas de protección de copia Primero, vamos a tratar el problema del controlador de protección de copia. Los sistemas de protección de copia no tienen por qué desaparecer, pero eso no significa que deban impedir a los que no son administradores ejecutar los juegos. La mayoría de los juegos usan el mecanismo de protección SafeDisc de Macrovision, que instala un controlador que busca un disco de juego original. De forma predeterminada, el controlador está configurado para iniciarse a petición (una función que los usuarios limitados no pueden realizar). Microsoft y Macrovision han distribuido correcciones, pero he encontrado otra solución alternativa:
  1. Abra el Administrador de dispositivos con una cuenta de administrador.
  2. Vaya al menú Ver y seleccione Mostrar dispositivos ocultos.
  3. Expanda el nodo Controladores que no son Plug and Play.
  4. Abra las propiedades del controlador de seguridad o SecDrv (consulte la
    Figura 3 Permitir que la ejecución de protección de copia se ejecute correctamente (Hacer clic en la imagen para reducirla)
Figura 3 Permitir que la ejecución de protección de copia se ejecute correctamente
Figura 3 Permitir que la ejecución de protección de copia se ejecute correctamente (Hacer clic en la imagen para ampliarla)
Puesto que el controlador se inicia ahora con el equipo, está listo cuando el usuario inserta el disco para ejecutar el juego.
Corrección de problemas del sistema de archivos y de acceso al registro La suposición de acceso libre a cualquier parte del sistema de archivos o del registro es un problema común de muchos programas actuales y heredados, no sólo de los juegos. El artículo de Aaron Margosis "Problems of Privilege: Find and Fix LUA Bugs" (en inglés) profundiza sobre las soluciones a los distintos problemas que llevan a exigir privilegios de administrador (consulte ).
Los problemas de acceso pueden ser un poco complicados de descubrir, pero una vez que se distingue el conjunto necesario de archivos, carpetas y claves de registro, es bastante fácil aflojar las listas de control de acceso (ACL) para permitir a usuarios limitados reproducir juegos. He obtenido grandes resultados con el método siguiente:
  1. Obtenga las últimas versiones de Filemon y Regmon en microsoft.com/technet/sysinternals.
  2. Ejecute las herramientas como administrador y que éstas recopilen registros.
  3. Ejecute el juego durante unos minutos como administrador, realizando las tareas más comunes (iniciar una misión, guardar un juego, alojar un juego de red, etcétera).
  4. Filtre los resultados de Filemon y Regmon para centrarse en los accesos del juego que se van a analizar.
  5. Afloje las ACL según sea necesario para las carpetas y claves del registro en cuestión.
  6. Ejecute el juego como usuario distinto del administrador para comprobar si ahora funciona.
Una precaución a la hora de aflojar las ACL: no las abra demasiado (por ejemplo, Todos£Control total), ni en un nivel muy alto (como HKEY_CLASSES_ROOT). También es mejor evitar cambios en permisos de carpetas del sistema como %SYSTEMROOT% y %PROGRAMFILES% para evitar romper la estructura de Windows o dejar el sistema en un estado no seguro.
Otra solución alternativa posible es ejecutar el juego como usuario avanzado del sistema local. Ésta no es mi primera elección, pero si se usa una cuenta local del sistema en cuestión, el impacto se limita al menos a una sola estación de trabajo, en caso de que haya algún problema. He descubierto que esta corrección funciona para la mayoría de juegos que parecen funcionar correctamente sólo como administrador.
Como comentario adicional, pienso que ejecutar un juego brevemente como administrador es una forma útil de conseguir que se actualice automáticamente. Yo suelo ejecutar el juego como administrador, invocar la opción de actualización y luego salir del juego y volver a la cuenta de usuario limitado para jugar realmente. Merece la pena mencionar que Windows™ Vista permite a los usuarios limitados actualizar aplicaciones, asumiendo que la revisión está firmada por el publicador original.
Windows Vista también ayuda a juegos y a otras aplicaciones a tratar problemas de acceso a archivos y al registro. De forma predeterminada, los programas ejecutados por usuarios limitados tiene activadas correcciones de compatibilidad (shim) de virtualización que redireccionan los accesos equivocados de archivo y registro a una caché específica del usuario. He visto juegos diseñados para los sistemas Windows 9x, (por ejemplo, The Neverhood) que no se ejecutan correctamente en Windows XP (debido a problemas de permisos) y que funcionan perfectamente en Windows Vista con las correcciones de compatibilidad (shim) predeterminadas. Estoy deseando probar algunos otros juegos problemáticos en Windows Vista, aunque me estoy temiendo que tendré problemas para encontrar un juego cuyas correcciones de compatibilidad (shim) de Windows Vista no sean correctas.
Corrección de problemas de firewall Los problemas de firewall se resuelven mejor al instalar por primera vez el juego. Sin embargo, cuando la instalación del juego no es lo suficientemente hábil como para solicitar y configurar los ajustes de firewall necesarios, he aquí un método que he descubierto que funciona bien:
  1. Inicie la sesión como administrador.
  2. Abra el panel de control Firewall de Windows.
  3. Elija agregar un programa a la lista de excepciones del firewall.
  4. Seleccione el juego de la lista o busque el archivo ejecutable del juego cuando se le solicite.
Al agregar el archivo ejecutable a las excepciones del firewall, me aseguro de que se permitirá el acceso del juego a cualquier puerto que necesite para funcionar correctamente. Seguro que habrá trastornos.
Corrección de problemas con clientes de empresa Los problemas que encuentran los juegos en clientes de empresa desaparecerán con el tiempo. El número de hogares con varios equipos y banda ancha está aumentando y hay una comunidad creciente de usuarios que ejecutan SBS en casa. Pero por ahora, sigue siendo necesaria una solución.
En mi caso particular, descubrí que un valor de LUA local del sistema resolvía el problema de mi carpeta Mis documentos redireccionada. Tanto Age of Empires III como Fable: The Lost Chapters funcionaban correctamente como usuario limitado siempre que la carpeta Mis documentos no se redireccionara a una carpeta de red.Recursos
  • Quake 3 Buffer Overflow Advisory (en inglés)
  • Windows Vista Application Development Requirements for User Account Control Compatibility
  • Aplicación del principio de privilegio mínimo para cuentas de usuarios en Windows XP
  • Herramienta LUA Buglight de Aaron Margosis
  • Standard User Analyzer
  • Master Your Own Domain: Build a Corporate Network at Home (en inglés)
  • Problems of Privilege: Find and Fix LUA Bugs (en inglés)
  • Algunos programas no funcionan correctamente si inicia sesión mediante una cuenta de usuario limitada

Conclusión
Recomiendo encarecidamente la ejecución como usuario limitado para que pueda aprovechar las ventajas asociadas de no ser administrador. No es siempre fácil jugar en un entorno con menos privilegios, conectado a una empresa, pero tampoco es imposible. Con el paso de los años, he encontrado muchos juegos de todos los géneros que funcionan correctamente como usuario limitado. Y he descubierto algunas correcciones que hacen que otros títulos funcionen. Mientras tanto, con la virtualización de Windows Vista, los juegos a los que era imposible jugar como usuario limitado en Windows XP, volverán a funcionar.

Matt Clapham, administrador de programas de seguridad de Microsoft, participa de manera activa en la comunidad de Seattle para la seguridad de TI y forma parte del equipo de administración de riesgos en un proyecto de TI que aún se encuentra en ciernes.


 Nota del editor: En el interior
Nota del editor
En el interior

WINDOWS VISTA ESTÁ LISTO para tener una gran repercusión en departamentos corporativos de TI en 2007. Tal y como se indicaba en InformationWeek, un informe reciente de IDC estima que 100.000 trabajos de TI se crearán en EEUU este año como resultado directo del "impulso" de Windows Vista. Cerca de 90 millones de equipos nuevos de todo el mundo se entregarán con Windows Vista instalado este año y, el año que viene, el 80 por ciento de equipos nuevos que se suministren a empresas tendrán Windows Vista preinstalado. Mientras tanto, tiene que decidir si es el momento de implementar el sistema operativo en su organización. Podemos ayudarle
El número de este mes de TechNet Magazine inicia una serie que analizará en profundidad el elemento que hace destacar a Windows Vista: el kernel. Ciertamente, Windows Vista tiene algunas buenas características nuevas de experiencia de usuario, pero, si esa fuera la razón principal para la migración, seríamos cautelosos. El kernel representa el corazón del sistema operativo y hay mejoras considerables en la manera en que funciona el kernel de Windows Vista.
¿Quién mejor para escribir acerca de dichos cambios que Mark Russinovich, que sabe más que nadie en el mundo acerca del kernel de Windows? Su libro Windows Internals, del que es coautor junto con David Solomon, se ha convertido en el primer recurso que cualquier persona consulta para entender lo que ocurre internamente.
Este mes, Mark habla de las mejoras de asignación de CPU, que harán que las aplicaciones de escritorio ofrezcan una mayor respuesta, y describe cómo Windows Vista mejora el rendimiento multimedia con respecto al kernel. El artículo también trata cambios importantes en el modelo de E/S de Windows Vista, que incluyen los vínculos simbólicos basados en archivos, la capacidad nueva para cancelar las operaciones sincrónicas de E/S (el principal cambio, en mi opinión), y el concepto de la prioridad de E/S. No olvide leer el completo artículo de Mark, ya que podrá evaluar Windows Vista para su empresa.
Por supuesto, quedan las tareas diarias a las que hay que enfrentarse y nosotros le podemos ayudar también en ese sentido. En este número, se trata gran parte del terreno administrativo de Windows, con artículos sobre delegación de autoridad en Active Directory, plantillas nuevas de directiva de grupo en Windows Vista, solución de problemas de directiva de grupo y supervisión de Active Directory con MOM.
Finalmente, si desea jugar y permanecer seguro, deberá echar un vistazo a la nueva característica de juegos en un entorno seguro. Ya sabe lo que suelen decir: "nada de juegos, a trabajar". £JOSHUA TRUPIN

Mi agradecimiento a los siguientes expertos técnicos de Microsoft: Matt Ayers, Eugene Bak, Vijay Bharadwaj, Michael Fortin, David Hicks, Khushru Irani, Mehmet Iyigun, Arun Kishan, Mark Lawrence, Pavel Lebedynskiy, Ben Mickle, Michael Murgolo, John Orefice, Ravisankar Pudipeddi, Jeffrey Richter, David Solomon, Jim Truher, Landy Wang y Andy Zeigler.


 Caja de herramientas: Nuevos productos para profesionales de TI
Caja de herramientas
Nuevos productos para profesionales de TI
Greg Steen

Mover datos
SQL Examiner Bundle
www.sqlaccessories.com
Cualquiera que sea su función en una organización (DBA, desarrollador, especialista de funcionamiento o empleado con múltiples funciones), si trabaja con SQL Server™, probablemente haya tenido que mover datos entre entornos y asegurarse de que la integridad de los datos y las estructuras de los mismos permanecen intactas. Por supuesto, SQL Server tiene muchas características integradas de réplica y sincronización, pero si lo que va a comprobar es si la base de datos de QA coincide exactamente con la base de datos de desarrollo, una herramienta como SQL Examiner Bundle de TulaSoft puede ser inestimable y le permitirá ahorrar tiempo y esfuerzo.
Con unos cuantos clics del mouse, la aplicación puede descubrir discrepancias de la estructura de la base de datos o de los propios datos entre dos instancias de la base de datos. Simplemente tiene que dirigir la aplicación a las bases de datos que desee comprobar y realizar la comprobación. Como sugiere su nombre, SQL Examiner Bundle incluye dos aplicaciones: SQL Examiner y SQL Data Examiner. SQL Examiner consulta la estructura de las bases de datos, mientras que SQL Data Examiner consulta todos los datos y resalta cualquier diferencia.
SQL Examiner consultará y comparará todo en las instancias de la base de datos, desde tablas y procedimientos almacenados, a colecciones de catálogos de texto y esquemas XML. Los que usen SQL Server 2005 pueden comparar también los ensamblados de Common Language Runtime (CLR). Una vez que compare las bases de datos, SQL Examiner permite que elija qué objetos de la base de datos se deben sincronizar, además de la dirección de la sincronización.
Consultar y comparar las bases de datos con SQL Examiner
Consultar y comparar las bases de datos con SQL Examiner (Hacer clic en la imagen para reducirla)
Consultar y comparar las bases de datos con SQL Examiner
Consultar y comparar las bases de datos con SQL Examiner (Hacer clic en la imagen para ampliarla)
Una característica realmente novedosa es que la aplicación genera una secuencia de comandos SQL que crea un objeto y que resaltará la diferencia de esa secuencia de comandos generada entre las bases de datos. Ésta es una forma ideal de resaltar errores después de que una secuencia de comandos de creación o migración no cree correctamente la estructura de la base de datos de destino. ("¡Ah, ahí es donde olvidé mi índice agrupado!") Puede ejecutar las secuencias de comandos generadas individualmente, guardarlas para que se ejecuten más tarde o simplemente hacer clic en el botón Synchronize (Sincronizar) y que la aplicación haga todo el trabajo en su lugar.
Otra característica interesante es la opción de agregar exclusiones a la comparación, como ignorar comentarios, desencadenadores, índices o propiedades extendidas de un objeto. Después de consultar la comparación de estructura, SQL Data Examiner le permite consultar los datos y ver si existe alguna discrepancia. Puede escoger qué tablas desea comparar así como qué columnas de esas tablas especificadas se deben comparar. Una vez que la comparación de las tablas de datos ha terminado, puede ver qué filas son idénticas, cuáles son diferentes y qué reside sólo en una base de datos o en la otra.
Al igual que con SQL Examiner, SQL Data Examiner permite hacer clic en un botón para sincronizar las tablas, o bien puede elegir selectivamente qué datos deben transferirse así como la dirección de esa transferencia. Ambas aplicaciones permiten guardar la configuración como un proyecto, de modo que no tendrá que volver a crear las tareas cada vez. Cada aplicación se puede comprar por separado, aunque, por mi experiencia, me apuesto a que querrán las dos.
Precio: 299,95 dólares para una licencia de un solo usuario.

Buscar archivos duplicados
zsDuplicateHunter (Professional Edition)
Zizasoft
Si está implicado en la administración de escritorio, sin duda se habrá topado con un usuario que "se ha quedado sin espacio" en su equipo. Una investigación revela que éste ha estado copiando sus documentos cada vez que realizaba una edición, a pesar de que cuenta con un sistema de almacenamiento conectado a una red (NAS) con copia de seguridad para la base de usuario de almacenamiento de archivos. O bien, tiene un servidor de registro con procesos por lotes que ha logrado duplicar registros inmensos y ha ocupado todo el espacio asignado del servidor. Una solución posible a estos problemas es zsDuplicateHunter Professional Edition, un buscador de duplicados que puede ejecutarse en Windows®, Linux o Mac OS X.
La aplicación permite buscar fácilmente unidades, directorios o recursos compartidos de red, y descubrir los duplicados posibles. Yendo más allá de comparaciones de nombre, la aplicación permite agrupar archivos por tamaño, suma de comprobación o incluso cálculo implícito con el fin de asegurar que los archivos que limpie son realmente diferentes. Además, no es necesario eliminar permanentemente los duplicados. Como precaución, la aplicación permite mover todos los duplicados marcados a una carpeta especificada.
Otra característica interesante es la opción "Keep Files in this Folder, Delete Duplicates Elsewhere" (Mantener archivos en esta carpeta, eliminar duplicados en otra parte) que permite seleccionar el directorio de origen limpio y eliminar cualquier otro que pueda estar en el disco. En los resultados de búsqueda, también puede hacer doble clic en cualquier archivo para abrirlo con un visor asociado de archivos, clasificarlo y seleccionarlo para obtener los resultados exactos que necesite. Una característica interesante para el "profesional de TI" permite ajustar cuánta memoria puede tomar la aplicación al buscar duplicados. Como protección adicional, también puede deshabilitar los archivos ocultos o de sistema de la búsqueda con el fin de garantizar que no elimina nada que no deba, ni ningún archivo que controle el sistema operativo u otra aplicación.
La edición Professional Edition también ofrece un filtro granular en los resultados de la búsqueda que permite aplicar una expresión regular para buscar archivos exactos que desee eliminar.
Precio: 39,95 dólares para una licencia de un solo usuario.

Llevar consigo las aplicaciones
MojoPac
www.mojopac.com
Si va de un entorno a otro y echa de menos sus aplicaciones favoritas y la configuración de escritorio, o si simplemente no le gusta dejar huella en el equipo de escritorio de otras personas, quizás desee echar un vistazo a MojoPac de RingCube Technologies.
Dejando a un lado su nombre un tanto ridículo, MojoPac permite llevar consigo su configuración y sus aplicaciones a cualquier sistema de Windows XP (Home, Professional, Media Center o Tablet) en un disco duro USB, un dispositivo personal de medios que puede conectar al sistema host a través de USB 2.0, como Zune o iPod, o incluso un teléfono móvil con suficiente espacio de almacenamiento. En el momento de la redacción de este artículo, no se admitían los hosts de Windows™ Vista y Windows 2000, pero, en la documentación del sitio web del producto, se señalaba que pronto estaría disponible una actualización compatible con estos sistemas operativos.
Llevar la configuración con MojoPac
Llevar la configuración con MojoPac (Hacer clic en la imagen para reducirla)
Llevar la configuración con MojoPac
Llevar la configuración con MojoPac (Hacer clic en la imagen para ampliarla)
Actualmente, MojoPac requiere privilegios de administrador en el sistema host, aunque la versión 2.0 versión que está en desarrollo será compatible con un modo de usuario limitado. La herramienta ejecuta básicamente interferencias entre el sistema operativo del host y los dispositivos de almacenamiento, y, en el primer inicio después de que instale la aplicación en el dispositivo portátil, MojoPac activa la configuración inicial de la cuenta de Windows para que se ejecute, con lo que se configuran los valores personales como usuario de MojoPac en el dispositivo de MojoPac.
Una vez que esté en funcionamiento, el intercambio entre el sistema host y el sistema de Mojo es fácil: Solo tiene que hacer clic en la barra de herramientas (que puede estar minimizada) en la parte superior de la pantalla. Instale las aplicaciones en el dispositivo de Mojo como lo haría normalmente mientras MojoPac está activo. Y, tan pronto como observe la advertencia de gran tamaño en los documentos de Léame sobre la instalación en el directorio predeterminado, debe estar listo para comenzar.
En general, MojoPac tiene el potencial para ser un gran activo para cualquier profesional de TI que se desplace y desee su propia configuración. Por ejemplo, puede contar con todas las utilidades de sistema, detectores de paquetes y controladores de tráfico en MojoPac, y solucionar problemas desde cualquier PC de la organización sin dejar rastro.
Precio: 49,99 dólares para una licencia de un solo usuario.

Reseña de libro
Administrator’s Guide to SQL Server 2005
www.aw-bc.com
Cada vez mas grupos de TI se dan cuenta de la eficacia potencial y la gran funcionalidad ofrecida por SQL Server 2005. Desde la amplia compatibilidad con datos XML, hasta SQL Server Integration Services (SSIS), pasando por SQL Server 2005 Service Broker, la aplicación agrega toneladas de útiles mejoras. Para ayudarle con la nueva ruta de acceso de actualización o con la administración de la instancia de SQL Server 2005 recientemente lanzada al mercado, Buck Woody ha escrito una guía de referencia excelente: Administrator’s Guide to SQL Server 2005 (Addison-Wesley Professional, 2006).
El libro ofrece una introducción a prácticas de administración útiles aplicadas a la nueva plataforma de servidor y, a diferencia de muchas otras referencias que existen, lo hace de forma concisa. El libro empieza con una sección sobre el ajuste correcto del tamaño de la infraestructura para satisfacer las necesidades de la aplicación, así como una guía en la que la versión de SQL Server sería apropiada en escenarios distintos. Aquí, también se hará una idea de cómo distribuir la infraestructura para asegurarse de que no ha terminado con cuellos de botella de rendimiento evitables en la instalación.
A continuación, la guía pasa a describir las distintas herramientas ofrecidas con SQL Server, tales como Analizador de SQL Server y SQL Server Management Studio. También ahondará en tareas de mantenimiento y automatización, y consultará cómo puede planear el crecimiento basado en perfiles de servidor y cómo proponer un plan de mantenimiento adecuado para su implementación.
En el capítulo de seguridad, explorará también cómo proteger su instalación, desde la red y el hardware, hasta el sistema operativo y la instancia de SQL Server. En él, también ahondará en los servicios de administración de claves, certificados y cifrado adicionales ofrecidos por la nueva plataforma.
Otro capítulo explica los mecanismos que existen para asegurar una gran disponibilidad del sistema, según las necesidades de las implementaciones. Descubrirá los clústeres, la creación de reflejos de base de datos, la réplica y el trasvase de registros como métodos para obtener sus requisitos de tiempo de actividad. Y con la virtualización como medio ideal para lograr una gran disponibilidad sin la sobrecarga de infraestructuras físicamente distintas, el libro ofrece una guía paso por paso para configurar un clúster de dos nodos con Microsoft Virtual Server.
El capítulo sobre SSIS no sólo muestra cómo usar la nueva herramienta (adiós a DTS) para desarrollar e implementar funciones de extracción, transformación y carga (ETL), sino también cómo usar los servicios para crear tareas de supervisión, notificación por correo electrónico y copia de seguridad.
Finalmente, los últimos capítulos profundizan en los servicios de informe y análisis que ofrece la nueva plataforma de SQL Server. Aquí, tratará el diseño y la creación de informes, la administración de sistemas de informe y lo que implica el mantenimiento de la implementación de servicios de análisis.
En resumidas cuentas, la guía Administrator’s Guide to SQL Server 2005 es una forma estupenda de agilizar la administración, la supervisión y la actualización a SQL Server 2005.
Precio: $49.99.


 Preguntas y respuestas sobre SQL&amp;: Tama&#241;o de base de datos, creaci&#243;n de reflejos, transacciones marcadas y mucho m&#225;s
Preguntas y respuestas sobre SQL&
Tamaño de base de datos, creación de reflejos, transacciones marcadas y mucho más
Editado por Nancy Michell

Cómo mover un clúster
P Necesito mover un clúster de SQL Server 2000 a nuevas direcciones IP tanto para los servidores físicos internos, como para el clúster de Windows ® y el clúster de SQL Server™. ¿Tendré que volver a crear por completo la solución?
R No, todo lo que tiene que hacer es ejecutar la configuración de SQL Server y modificar las direcciones IP. En este vínculo puede leer un artículo sobre Microsoft Knowledge Base que explica cómo hacerlo.

Tamaño de la base de datos
P Tengo SQL Server 2000 SP4 en funcionamiento con una base de datos crítica de casi 10 GB, un modelo de recuperación SIMPLE, un archivo principal de 9.850 MB y un archivo de registro de transacciones de 88 MB. La copia de seguridad de la base de datos también tiene casi 10 GB. ¿Tengo que reducir el tamaño de la base de datos para mejorar el rendimiento? En caso necesario, ¿debo utilizar DBCC SHRINKDATABASE o DBCC SHRINKFILE? (Desgraciadamente, no dispongo de horas que no sean horas punta para realizar este mantenimiento.)
DBCC SHRINKDATABASE o DBCC SHRINKFILE sólo le servirán de ayuda si la base de datos experimenta muchas eliminaciones y actualizaciones que tienen como resultado un volumen de datos menor. Pero la verdadera pregunta es, ¿por qué le preocupa? Un espacio en disco de 10 GB puede valer hoy día unos 20 dólares. ¿No tendría más sentido agregar otros 100 GB o más de espacio en disco y continuar con la ejecución? El rendimiento empeorará a medida que el espacio se fragmenta, pero si no puede encargarse de ningún tipo de mantenimiento, no tiene muchas más opciones. A veces se utiliza una segunda copia de la base de datos en este tipo de casos. Se conserva una copia de seguridad actualizada con réplica, se realiza el mantenimiento de la copia de seguridad y, a continuación, se cambian las aplicaciones a la copia de seguridad. Obviamente, este proceso exige algunos cambios de código y el movimiento del modelo de recuperación SIMPLE (a FULL o BULK_LOGGED) pero puede ser una buena solución a largo plazo.

Actualización de versiones y rendimiento
P Necesito mover dos aplicaciones de SQL Server 2000 a SQL Server 2005. ¿Cómo puedo evitar posibles descensos en el rendimiento durante la actualización?
R Generalmente, las siguientes cuestiones pueden provocar una caída del rendimiento durante la actualización a otra versión, de modo que trate de evitarlas:
  1. No ha creado de nuevo las estadísticas después de la actualización a SQL Server 2005.
  2. Tiene las cláusulas JOINS y WHERE que comparan dos clases de datos diferentes, lo cual tiene como resultado un rendimiento incorrecto, especialmente si el servidor había estado ejecutando SQL Server 2000 SP3 o una versión anterior (consulte support.microsoft.com/kb/271566/).
  3. La instancia de SQL Server 2005 no está correctamente configurada; la memoria, las extensiones de ventana de dirección (AWE), los controladores, etc., no se han configurado correctamente. Se ha ajustado el cuadro que ejecuta SQL Server 2000, pero la persona que lo hizo no lo documentó, de modo que fue nunca se realizó en la instancia de SQL Server 2005.
  4. El hardware tiene un error. A menudo, se compra nuevo hardware porque parece bueno sobre el papel, pero no da la talla en el día a día.
Antes generar una instancia de SQL Server, debe establecerse una línea de referencia de rendimiento para confirmar que se alcanzará el rendimiento que espera. Esta acción descarta la infraestructura como un posible problema. Es necesario que observe contadores de rendimiento tales como el disco, la E/S y la memoria y que los compare entre las instancias.

Creación de reflejos de bases de datos
P Utilizo la creación de reflejos de bases de datos y quiero habilitar la opción de base de datos READ_COMMITTED_SNAPSHOT. Cuando trato de habilitarla una vez establecida la creación de reflejos, obtengo una excepción que indica que la base de datos se encuentra en una sesión de creación de reflejos y que no puede ejecutarse el comando.
R Esto sucede porque el establecimiento de la opción READ_COMMITTED_SNAPSHOT requiere un reinicio de la base de datos para tener efecto. Por lo tanto, es necesario interrumpir la sesión de creación de reflejos, establecer la opción y reiniciar la base de datos. Una vez realizados esos pasos, puede restablecer la creación de reflejos. La base de datos reflejada interpretará la opción después de que la sesión esté establecida y la utilizará en caso de que se produzca un error.

P Estoy tratando de establecer la creación de reflejos asincrónicos y estoy obteniendo un error 1418. La ejecución de Netstat -ano muestra que SQL Server escucha en el puerto correcto en todos servidores. El error aparece cuando trato de iniciar la creación de reflejos. ¿Qué sucede?
R Una posibilidad es que el firewall esté bloqueando la comunicación; este es un problema relativamente común que debe investigar. Consulte los siguientes artículos para obtener más ayuda: Troubleshooting Database Mirroring Setup (en inglés) y MSSQLSERVER_1418 (en inglés).
Debe tener en cuenta que este problema no es específico de la creación de reflejos asincrónicos. De hecho, puede suceder también con la creación de reflejos sincrónicos.
El error que obtiene ("La dirección de red del servidor "%.*ls” no puede alcanzarse o no existe. Compruebe el nombre de la dirección de red y vuelva a emitir el comando") es correcto. A menudo no se trata de que el socio remoto no exista, lo que sucede simplemente es que no es posible tener acceso a él.
Esto podría suceder si el socio remoto no está disponible, no escucha el puerto, o incluso si el extremo no está disponible (puede suceder si los socios no pueden negociar el mismo mecanismo de cifrado o tienen otros problemas de autenticación). También puede suceder si el socio está bloqueado, lo cual puede ser el resultado de que el firewall del socio esté iniciando el comando.
Otros problemas que quizás desee descartar para incluyen el nombre del origen de datos (DSN) y problemas de resolución de nombres. La recomendación genérica es utilizar nombres de dominio completos. De modo que si bien el firewall puede que sea con frecuencia el problema, recuerde que hay muchas causas posibles.

P Deseo utilizar la creación de reflejos de SQL Server 2005; sin embargo, he oído que no se recomienda la creación de reflejos cuando varias aplicaciones se conectan a varias bases de datos en la misma instancia de SQL Server. ¿Estoy en lo cierto?
R La respuesta depende realmente de si cada aplicación tiene su propia base de datos o de si las aplicaciones utilizan transacciones entre bases de datos transacciones o del Coordinador de transacciones distribuidas (DTC). Si se utilizan transacciones entre bases de datos, entonces la creación de reflejos puede incluir incoherencias lógicas en las que las transacciones no se realizan como se espera. Una buena explicación de lo que sucede en estas circunstancias puede encontrarse aquí.
Si varias aplicaciones utilizan varias bases de datos y cada aplicación tiene su propia base de datos, entonces la creación de reflejos no causará estos problemas.

Transacciones marcadas
P ¿Qué son exactamente las transacciones marcadas y son algo que puede utilizarse si una base de datos es SQL Server y otra es Oracle?
R Marcar una transacción es algo que el administrador de bases de datos hace periódicamente para poner una marca en el mismo lugar en todos los registros. Esta acción, combinada con la capacidad de restaurar una tabla en una marca de transacción, le permite restaurar todas las bases de datos al mismo punto. Hacer esto puede resultar muy laborioso, porque tendrá que restaurar todas las bases de datos implicadas y se perderán datos en todas las bases de datos, de modo que debe evitarlo cerciorándose de que no pierde los archivos de registro. Las transacciones marcadas son específicas de SQL Server, de modo que si sus transacciones distribuidas incluyen bases de datos que no son SQL Server, no podrán participar en el marcado de transacciones. En general, muy pocos sistemas de bases de datos distribuidos utilizan marcas de transacciones. Simplemente tratan la pérdida de uno de los registros de transacciones como un evento catastrófico que requerirá mucho trabajo manual de recuperación.

Herramienta de conversión Access-To-T-SQL
P ¿Hay alguna herramienta de conversión Access™-SQL a T-SQL disponible para procedimientos almacenados?
R Pruebe SQL Server Migration Assistant (SSMA) for Access, que es posible descargar. Allí encontrará también SQL Server Migration Assistant for Oracle, SQL Server Migration Assistant for Sybase y Migrating Informix Databases to Microsoft ® SQL Server 2000.
Para convertir de Access a SQL Server, podría utilizar el Asistente de conversión de Office, pero SSMA for Access, que se muestra en la Figura 1, tiene más características, incluidos los informes de evaluación de la conversión y exploración de red. SSMA for Access corrige también muchos problemas que actualmente no trata correctamente el Asistente de conversión de Office.
Figura 1 SQL Server Migration Assistant for Access
Figura 1 SQL Server Migration Assistant for Access (Hacer clic en la imagen para reducirla)
Figura 1 SQL Server Migration Assistant for Access
Figura 1 SQL Server Migration Assistant for Access (Hacer clic en la imagen para ampliarla)

Índices no agrupados
P Tengo una tabla en la que la clave principal está formada por GUID (digamos, GUID1 y GUID2). Ya tuve mi índice único agrupado en GUID1 y GUID2. Ahora, por razones de rendimiento, quiero crear el segundo índice no agrupado en GUID2 y GUID1. ¿Habrá algún efecto indirecto en el rendimiento si declaro el índice como único?
R No hay ninguna penalización en el rendimiento al declarar el índice no agrupado como único. De hecho, el hacerlo puede tener como resultado menos niveles en el árbol de índice.
Cuándo un índice no agrupado se declara como que no es único, el localizador de filas se adjunta a la parte clave de las entradas del índice en las páginas raíz y que no son hojas. Esto se realiza para la eliminación y actualización de entradas de índice, que evita la exploración de cadenas sinónimas cuando hay duplicados para una clave; la entrada específica que se va a cambiar puede localizarse mediante una operación de búsqueda de sistema en el localizador positivo clave. El resultado es que esas entradas son más largas (considerablemente de acuerdo con la clave de clúster que ha elegido). Como resultado, las páginas raíz y que no son hojas se llenarán más rápido de forma natural. Si el índice es único, debe declararlo como tal.
La cuestión es, independientemente de si la tabla tiene un índice agrupado, cualquier índice no agrupado de la tabla que no sea declarado único tendrá el localizador adjunto a las entradas de las páginas raíz y otras páginas que no son hojas.
Además, si utiliza una columna de identificador int como clave suplente y después agrega dos índices únicos (GUID1, GUID2) y (GUID2, GUID1), esto hará que probablemente mejore el rendimiento, ya que los índices tendrán una clave de clúster de 4 bytes en lugar de una clave de clúster de 32 bytes.

Bloqueos de actualizaciones
P Tengo un procedimiento almacenado con la estructura siguiente:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
Este procedimiento almacenado admite que sólo una persona que llama tome el bloqueo y hará que cualquier otra persona que llama quede en espera. ¿Puedo lograr el mismo comportamiento reduciendo el nivel de aislamiento?
Parece que READ COMMITTED es el nivel correcto de aislamiento, ya que esta transacción tiene sólo una consulta, y si alguna otra transacción está en proceso de actualizar el mismo registro, esta transacción esperará en la otra transacción. ¿Estoy en lo cierto?
R No es la configuración en serie de su ejemplo lo que hace que las demás personas que llaman permanezcan en espera; es la propia actualización en sí. Sí, puede establecer el aislamiento en READ COMMITTED y la actualización tomará de forma natural cualquier bloqueo de actualización en cualquier índice que utilice. Esto causará problemas a otros procesos que ejecuten la misma instrucción, de modo que se bloquearán hasta que la actualización se realice. (Además, tampoco necesita la transacción explícita aquí si la actualización es la única instrucción; cada instrucción está implícitamente en su propia transacción si no está en una explícita).
Sin embargo, si no hay las filas que coincidan con la cláusula WHERE en la instrucción UPDATE, entonces el uso del nivel de aislamiento serializable evitaría que dichas filas se insertaran o modificaran en otras transacciones. Si fuese a ejecutar UPDATE en el aislamiento READ COMMITTED, esto no sucedería y otras transacciones podrían insertar filas candidatas a la actualización. Si el código del procedimiento almacenado es como el código que ha mostrado, puede que no tenga sentido realizar ninguna de estas acciones (en serie o transacción); simplemente llevar a cabo la actualización.

Mis agradecimientos a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Gaurav Aggarwal, Anthony Bloesch, Todd Briley, Shaun Cox, Roberto Di Pietro, Michael Epprecht, Kevin Farlee, Umachandar Jayachandran, Chuck Ladd, Kaloian Manassiev, Luciano Moreira, Ward Pond, Mark Prazak, Arunachalam Thirupathi, Roger Wolter, Clement Yip y Frankie Yuen.


 Utility Spotlight: Inventario de directiva de grupo
Utility Spotlight
Inventario de directiva de grupo
Greg Steen
Descargar el código de este artículo: GPInventory.exe (150KB)

¿CÓMO sabe lo que tiene si no mantiene ningún seguimiento de ello? El hecho de tener a mano la información del inventario puede ahorrarle muchos dolores de cabeza al celebrarse las reuniones de asignación de presupuestos y las auditorías anuales. Y, por supuesto, los dirigentes siempre parecen querer saber quién tiene qué y por qué, y lo que costará realizar esa importante actualización.
Una herramienta que puede ayudarle con todo esto es el inventario de directiva de grupo (GPInventory.exe), incluido con el Kit de recursos de Windows Server® 2003. Este programa permite consultar y recuperar información de sistema con el conjunto de directivas resultante (RSOP) y las consultas de Instrumental de administración de Windows® (WMI) de varios hosts remotos, como muestra la ilustración. Como es de esperar, el programa recupera fácilmente información de directiva de grupo, aunque es también un medio eficaz de extraer información detallada de sistema, como, por ejemplo, las aplicaciones instaladas, el nombre y velocidad del procesador, o la lista de revisiones instaladas. Pero ¡espere, hay más! Desde que forma parte del Kit de recursos de Windows Server 2003, es totalmente gratis.
Figura 1 Uso de GPInventory para recopilar información
Figura 1 Uso de GPInventory para recopilar información (Hacer clic en la imagen para reducirla)
Figura 1 Uso de GPInventory para recopilar información
Figura 1 Uso de GPInventory para recopilar información (Hacer clic en la imagen para ampliarla)
Hay muchas maneras diferentes de usar GPInventory.exe. Por ejemplo, si necesita comprobar el estado de la garantía, puede reunir los números de serie o de servicio de los equipos de la red sin tener que consultar cada caja. O bien, si tiene un entorno de laboratorio y desea ver si un equipo está actualmente en uso, puede consultar a los usuarios conectados actualmente al sistema sin tener que moverse de su asiento. Si tiene configurado un servidor blade en el que las imágenes se arrojan a las tarjetas de forma rutinaria (para limpiar y restaurar el entorno de QA, por ejemplo), puede consultar la fecha de instalación del equipo con objeto de comprobar cuándo se aplicó la última imagen.
GPInventory es también bastante fácil de usar. Sólo tiene que dirigir la aplicación a un archivo que tenga una lista de equipos que desee que incluir en el inventario, seleccionar qué consultas se ejecutarán y, a continuación, procesar la lista. La herramienta entonces se extiende y se conecta con cada equipo de la lista y lo consulta. Si realiza una consulta rápida, también puede seleccionar los equipos de destino directamente de Active Directory® y las acciones de consulta que desea realizar en el menú Consulta.
Para ejecutar una consulta de RSOP en un equipo, necesitará tener el permiso Generar conjunto resultante de directivas (registro) (que poseen, de forma predeterminada, los administradores de dominio y administradores delegados). Las consultas de WMI requieren derechos administrativos en el equipo remoto, a menos que use el complemento de MMC de control de WMI para conceder derechos de activación de cuenta y activación remota en el espacio de nombres root\cimv2 a otro usuario.
Una vez que realice la consulta, puede guardar los resultados como un archivo de texto delimitado por tabulaciones o como XML. Ambas variedades pueden importarse en Microsoft ® Excel ® para el análisis. Puede clasificar y luego aplicar un autofiltro para buscar toda la información.
GPInventory también es compatible con la ejecución de línea de comandos, de modo que puede configurar fácilmente una tarea programada para consultar información de sistema y guardarla en un archivo XML directamente, sin la intervención de GUI. Esto puede ser muy útil para las consultas largas que están más indicadas para la ejecución en horas de menor actividad.
La herramienta viene con un conjunto predeterminado de consultas de RSOP y WMI, aunque puede agregar, editar y actualizar el archivo de consulta con su propia lista personalizada si no encuentra lo que necesita. El documento de ayuda que se incluye muestra cómo definir una consulta nueva en el archivo XML de lista de consultas.
GPInventory.exe constituye una forma ideal de reunir información en los equipos que ejecutan Windows en la red, ya sea para obtener información de inventario, directiva de grupo o estado. Encontrará un vínculo a la herramienta de inventario de directiva de grupo en la sección de descargas de nuestro sitio web.

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.


 The Cable Guy: Compatibilidad con QoS en Windows
The Cable Guy
Compatibilidad con QoS en Windows
Joseph Davies
Este artículo se basa en parte de la versión preliminar de Windows Server, "Longhorn". Toda la información mencionada aquí está sujeta a cambios.

La calidad del servicio (QoS) abarca un conjunto de tecnologías para administrar tráfico de red de una manera rentable con el fin de mejorar las experiencias de usuario en entornos domésticos y empresariales. Las tecnologías de QoS permiten medir el ancho de banda, detectar las condiciones cambiantes de la red (tales como la congestión o la disponibilidad del ancho de banda)
y dar prioridad al tráfico o reducir el flujo del mismo. Por ejemplo, el sistema de QoS se puede aplicar para dar prioridad a la entrega de tráfico sensible a la latencia (como aplicaciones de voz o vídeo) y para controlar la repercusión del tráfico no sensible a la latencia, como transferencias de conjuntos masivos de datos. Para ofrecer una entrega con prioridad del tráfico de TCP/IP, es necesario contar con la compatibilidad con dispositivos de infraestructura de red y hosts. Esta columna describe los métodos para usar QoS con hosts basados en Microsoft® Windows®.
El problema central de definir QoS para redes TCP/IP es cómo especificar y ofrecer la entrega con prioridad del tráfico IP. Aunque el RFC 791 original para IP definiera el campo de tipo de servicio (TOS) con la capacidad de especificar la prioridad, la demora, el rendimiento, la confiabilidad y las características de costo, el protocolo IP es fundamentalmente una tecnología de conmutación de paquetes basada en datagramas de mejor esfuerzo, que suele tratar cada paquete de igual forma y de acuerdo con un orden de prioridad de llegada.

Configuración de entrega con prioridad
Para ofrecer el servicio de entrega con prioridad, hay una serie de procedimientos que puede realizar. Puede configurar la infraestructura de red para ofrecer una administración especial del tráfico marcado y que luego los hosts de envío marquen el tráfico saliente. Como alternativa, puede hacer que los hosts de envío programen dinámicamente la infraestructura de la red para ofrecer una administración especial basada en las características del tráfico saliente (como las direcciones y los números de puerto).
Para el tráfico de TCP/IP, puede usar unos pocos métodos diferentes con el fin de ofrecer la entrega con prioridad. Por ejemplo, en la capa de interfaz de red para Ethernet, el etiquetado IEEE 802.1p marcará los marcos enviados por un host para la entrega con prioridad mediante un campo de prioridad de 3 bits en el encabezado de la red de área local virtual (VLAN) del marco de Ethernet. El encabezado de VLAN se coloca dentro del encabezado de Ethernet, entre el campo de dirección de origen y el de longitud (para un marco IEEE 802.3) o el de EtherType (para un marco de Ethernet II).
La implementación del etiquetado 802.1p en un host de envío requiere que el adaptador de la red y el controlador de dispositivo sean compatibles con 802.1p y que el adaptador de la red tenga habilitada la compatibilidad con 802.1p. Normalmente, puede habilitar la compatibilidad con 802.1p en la ficha Avanzadas de las propiedades de un controlador de adaptador de red. Los conmutadores de Ethernet también deben tener habilitada la compatibilidad con 802.1p.
En la capa de interfaz de red para red inalámbrica IEEE 802.11, la certificación de Wi-Fi Alliance para multimedia Wi-Fi (WMM) define cuatro categorías de acceso para dar prioridad al tráfico de red. Estas categorías de acceso son (en orden de prioridad de mayor a menor) voz, vídeo, mejor esfuerzo y segundo plano. La compatibilidad de host para la prioridad de WMM requiere que ambos adaptadores de red inalámbrica y sus controladores sean compatibles con WMM. Los puntos de acceso inalámbrico (AP) deben tener habilitado WMM.
En el nivel de Internet, puede usar los servicios diferenciados y definir el valor del punto de código de servicios diferenciados (DSCP) en el encabezado de IP. Tal y como se define en RFC 2472, el valor DSCP es los 6 bits de valor superior del campo TOS de IP versión 4 (IPv4) y del campo de clase de tráfico de IP versión 6 (IPv6).
Los enrutadores empresariales más modernos admiten la diferenciación de tráfico DSCP, aunque esta característica está deshabilitada de forma predeterminada. Durante el reenvío, los enrutadores que admiten DSCP leen el valor DSCP y colocan el paquete en una cola específica. Por ejemplo, los enrutadores se pueden configurar para que sitúen los paquetes reenviados en la cola de "prioridad alta", de "mejor esfuerzo" o "inferior al mejor esfuerzo" en función de los valores DSCP definidos. Al configurar las colas y los valores DSCP, el tráfico marcado con DSCP podrá tener niveles de servicio diferentes. Por ejemplo, el tráfico de red importante recibe preferencia de reenvío frente al tráfico masivo de datos de menor prioridad. La especificación de WMM define cómo las categorías de acceso de WMM se asignan a valores DSCP. Un punto de acceso inalámbrico compatible con WMM lee el valor DSCP y controla el tráfico en función de su categoría de acceso.
En el nivel de Internet, puede usar también el protocolo de reserva de recursos (RSVP), un protocolo de señalización definido en RFC 2205. Los hosts pueden usar este protocolo para intentar reservar el ancho de banda de una red hasta un extremo. No obstante, RSVP no está muy implementado en redes y no es compatible actualmente con Windows XP, Windows Server® 2003, Windows™ Vista ni la versión siguiente de Windows Server, cuyo nombre en código es "Longhorn" (actualmente en versión beta).
Para enviar paquetes marcados para la entrega con prioridad, las aplicaciones o componentes del sistema operativo deben poder especificar los valores de la prioridad de 802.1p o el valor DSCP. Las secciones siguientes describen cómo componentes de Windows o aplicaciones basadas en Windows pueden especificar la prioridad de 802.1p para marcos de Ethernet o el valor DSCP para el tráfico de TCP/IP.

QoS en Windows XP y Windows Server 2003
Windows XP y Windows Server 2003 ofrecen API para asignar parámetros de QoS al tráfico. Los desarrolladores de aplicaciones pueden usar Windows Sockets (WinSock) y API genéricas de QoS (GQoS) para aplicar los parámetros de QoS en el nivel de aplicación en cada socket. Los administradores de red pueden usar herramientas de administración de tráfico escritas para llamar a API de control del tráfico (TC) con el fin de aplicar parámetros de QoS en el nivel de host.
Puede usar WinSock y la opción de socket IP_TOS con el fin de establecer el valor DSCP para paquetes salientes para un socket. Sin embargo, de forma predeterminada, la pila de TCP/IP ignora la opción de socket IP_TOS. Para usar la opción de socket IP_TOS, primero debe crear y establecer el valor de registro DWORD DisableUserTOSSetting=0 en la siguiente clave de registro (consulte la Figura 1):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Figura 1 Establecimiento del valor de registro de DisableUserTOSetting
Figura 1 Establecimiento del valor de registro de DisableUserTOSetting
Debe reiniciar el equipo para que el valor del registro surta efecto.
Para especificar el valor DSCP para el tráfico sin tener que usar la opción de socket IP_TOS, puede usar las API de GQoS. GQoS forma parte de Windows Sockets 2.0 (Winsock2). La mayoría de las aplicaciones compatibles con QoS usan la API de GQoS para invocar las capacidades de QoS en Windows. GQoS en Windows XP Service Pack 2 (SP2) permite a una aplicación establecer un valor DSCP y reducir el flujo de tráfico saliente. Para establecer las prioridades de 802.1p en equipos que ejecutan Windows XP SP2, debe usar la API de TC.
La API de TC ofrece acceso a mecanismos de control de tráfico que regulan el tráfico de red en el host local. Admite el control directo de valores DSCP, etiquetas 802.1p y tasa de disminución de flujo de tráfico. Los administradores de red pueden usar los programas de administración de tráfico para invocar la API de TC directamente en nombre de las aplicaciones que no reconocen QoS. Puesto que se trata de una API de un nivel inferior a la API de GQoS, la API de TC requiere los privilegios del nivel de administrador.
A diferencia de la API de GQoS, la API de TC admite tráfico de varias aplicaciones en el mismo host de envío para agregarlo a un solo flujo de QoS. Como parte de esta agregación, el tráfico puede identificarse por una combinación de las direcciones IP de origen y destino, los puertos de origen y destino, y el protocolo (TCP o UDP). Por ejemplo, todo el tráfico de una dirección IP de destino específica puede incluirse en un solo flujo de QoS para cualquier puerto de origen y puerto de destino, con independencia de la aplicación de envío del host. La API de GQoS, por otro lado, permite a una aplicación definir su propio tratamiento de QoS en los datos que envía a través de un socket.
Para ser compatible con la capacidad de QoS, los equipos basados en Windows XP y Windows Server 2003 deben tener el componente Programador de paquetes QoS instalado y habilitado en las propiedades de conexiones de red de la carpeta Conexiones de red (consulte la Figura 2). El componente Programador de paquetes QoS (Psched.sys) está instalado y habilitado de forma predeterminada para equipos con Windows XP. El componente Programador de paquetes se puede instalar en Windows Server 2003.
Figura 2 Configuración del Programador de paquetes QoS
Figura 2 Configuración del Programador de paquetes QoS

QoS en Windows Vista y Windows Server "Longhorn"
La compatibilidad con QoS en Windows Vista y Windows Server "Longhorn" se ha mejorado y simplificado. Para el personal de TI, ahora es posible usar QoS basado en directivas con el fin de establecer valores DSCP y controlar la velocidad de envío de aplicaciones sin tener que usar API o modificar las aplicaciones existentes. Para los desarrolladores, se admiten GQoS y API de TC, aunque la compatibilidad con estas API no está planeada para versiones futuras de Windows. Asimismo, la opción de WinSock IP_TOS se ha eliminado. Para reemplazar API de GQoS y TC, y simplificar la compatibilidad con QoS en aplicaciones actualizadas o futuras, Windows Vista y Windows Server "Longhorn" admiten la nueva API de QoS2, también conocida como Quality Windows Audio-Video Experience (qWAVE).
La calidad de servicio (QoS) basada en directivas de Windows Server "Longhorn" y Windows Vista permite ofrecer una experiencia de usuario final mejorada, controlar los costos de ancho de banda o negociar una mayor calidad de los niveles de servicio con los proveedores de ancho de banda o los departamentos empresariales. El ancho de banda de red de los equipos con Windows Server "Longhorn" o Windows Vista se puede administrar de forma central, independientemente de la aplicación en cuestión y en toda la infraestructura de Active Directory®. Debido a que la administración del tráfico tiene lugar por debajo de la capa de aplicación, no es necesario modificar las aplicaciones existentes para llevar a cabo la administración del tráfico de QoS basada en directivas.
La configuración de QoS basada en directivas de Windows Server "Longhorn" y Windows Vista permite establecer prioridades o administrar la velocidad de envío del tráfico saliente en función de las condiciones siguientes:
  • Aplicación de envío (nombre y ruta de acceso del ejecutable)
  • Direcciones IPv4 o IPv6 de origen o destino, o prefijos de dirección
  • Protocolo (TCP, UDP o ambos)
  • Puertos de origen o destino, o intervalo de puertos (TCP o UDP)
Las directivas de QoS se aplican a una sesión de inicio de usuario o a un equipo como parte de un objeto de directiva de grupo (GPO) vinculado a un contenedor de Active Directory, como un dominio, un sitio o una unidad organizativa (OU), o bien se pueden aplicar a un grupo de seguridad. Como parte de la directiva de grupo, las directivas de QoS se crean a partir de la infraestructura de administración de Active Directory existente.
QoS basado en directivas permite definir la prioridad del tráfico. Puede configurar una directiva de QoS para marcar el tráfico de IPv4 o IPv6 saliente con un valor específico DSCP. Puede administrar también el uso del ancho de banda para el tráfico saliente. Puede configurar una directiva de QoS con una tasa de disminución de flujo para el tráfico saliente. Mediante esta limitación, los componentes de QoS limitan el tráfico de red saliente agregado a una tasa especificada. En equipos, puede administrar el uso del ancho de banda para el tráfico entrante, configurando valores avanzados con el fin de especificar el rendimiento de entrada del tráfico de TCP estableciendo un valor máximo para el tamaño de ventana de recepción de TCP.
En Windows Vista y Windows Server "Longhorn," el Programador de paquetes QoS está instalado y habilitado de forma predeterminada. El componente Pacer.sys es un nuevo controlador de filtro ligero de especificación de interfaz de dispositivo de red (NDIS) 6.0 que controla la programación de paquetes correspondiente a la calidad de servicio basada en directivas y al tráfico de las aplicaciones compatibles con QoS. Pacer.sys sustituye a Psched.sys en Windows Server 2003 y Windows XP.
Para implementar QoS basado en directivas en la Intranet, configure directivas de QoS basadas en usuarios o equipos, y aplíquelas al contenedor apropiado de Active Directory. Los equipos basados en Windows Vista o Windows Server "Longhorn" descargan y aplican los valores basados en QoS cuando actualizan la directiva de grupo de configuración de usuario o configuración de equipo.
Dado que las aplicaciones de audio/video (A/V) comparten cada vez más las redes, se necesita una solución de QoS para que el tráfico A/V que depende del tiempo pueda recibir un trato preferencial a través del tráfico de datos. Asimismo, cada vez existen más redes inalámbricas, lo que introduce una complicación adicional para la latencia y las aplicaciones sensibles al ancho de banda.
La función qWAVE en Windows Vista ofrece un conjunto de módulos de software relacionados con QoS que afrontan los desafíos de red introducidos por las aplicaciones de AV y las redes inalámbricas. qWAVE se integra en el subsistema de QoS y funciona con múltiples tecnologías de red y de prioridad de paquetes de capas de Internet e interfaz de red. qWAVE es compatible con varias secuencias de AV (flujos en tiempo real que requieren QoS) y secuencias de datos (flujos de mejor esfuerzo, como transferencia de correos electrónicos o archivos) de forma simultánea.
La colección de tecnologías qWAVE detecta y controla el ancho de banda de LAN, descubre la capacidad de QoS de la red y proporciona control de admisión distribuido para el uso justo y coherente del ancho de banda de la red. Estas tecnologías permiten técnicas de transmisión de AV avanzadas, de tal manera que las aplicaciones puedan adaptarse de forma dinámica a condiciones de red variables y sólo están disponibles para los desarrolladores a través de la API de QoS2.
La API de QoS2 en Windows Vista y Windows Server "Longhorn" reemplaza la API de GQoS y la opción de WinSock IP_TOS, por lo que su uso debe resultarle más fácil que el de la API de GQoS.

Información adicional
Para obtener más información sobre QoS, hay varias fuentes excelentes disponibles a través de TechNet. Comience con el sitio web de calidad de servicio de Microsoft (en inglés). Compruebe también la sección de QoS del blog Windows Core Networking (en inglés).

Joseph Davieses escritor técnico de Microsoft y enseña y escribe sobre temas de conexión en red de Windows desde 1992. Es autor de cinco libros para Microsoft Press® y de la columna mensual The Cable Guy de TechNet.


 Windows&#160;PowerShell: Una l&#237;nea de scripting cada vez
Windows PowerShell
Una línea de scripting cada vez
Don Jones

En columnas pasadas, he enfatizado el hecho de que Windows PowerShell es un shell. Está pensado para usarse interactivamente, a diferencia del shell de cmd.exe (o símbolo del sistema) con el que probablemente ya está familiarizado. No obstante, Windows PowerShell es compatible con un lenguaje de scripting, que es más consistente que el lenguaje de lotes de cmd.exe, y es
tan eficaz o más que lenguajes como VBScript. Sin embargo, el hecho de que Windows PowerShell™ sea un shell interactivo hace que el scripting sea notablemente fácil de aprender. De hecho, puede desarrollar scripts interactivamente en el shell, lo que permite escribir una línea de script cada vez y ver de inmediato los resultados del trabajo.
Esta técnica de scripting iterativo también simplifica la depuración. Dado que puede ver directamente los resultados de script, puede revisarlos de forma rápida cuando no obtiene los resultados esperados.
En esta columna, voy a mostrarle un ejemplo de scripting interactivo en Windows PowerShell. Crearé un script que lee los nombres de servicio de un archivo de texto y deshabilita cada modo de inicio de servicio.
Lo que quiero que aprenda de este tutorial es el concepto de crear scripts de Windows PowerShell en pequeñas partes, en lugar de intentar abordar todo un script como una sola pieza. Puede tomar cualquier tarea administrativa que necesite llevar a cabo y descomponerla en sus partes constitutivas y, a continuación, descubrir cómo realizar cada parte de trabajo independientemente. Windows PowerShell ofrece medios excelentes para unir estas partes, como podrá comprobar. Y descubrirá que, al trabajar en partes pequeñas a la vez, le resultará más sencillo desarrollar el script final.

Lectura de nombres de un archivo
Puede resultar frustrante tratar de entender cómo leer archivos de texto en Windows PowerShell. Si ejecuto Help *file*, todo lo que obtengo es ayuda para cmdlet Out-File, que envía texto a un archivo, en lugar de leerlo. No es ninguna ayuda en absoluto. Sin embargo, los nombres de cmdlet de Windows PowerShell siguen una clase de lógica que puedo usar en mi beneficio. Cuándo Windows PowerShell recupera algo, el nombre de cmdlet suele comenzar por Get. De modo que ejecuto Help Get* para ver esos valores de cmdlet y, entonces, al desplazarme por la lista, encuentro Get-Content. Parece prometedor. De modo que ejecuto Help Get-Content para saber más acerca de su función (consulte la Figura 1) y parece que satisfará mis necesidades.
Figura 1 Ejecución de Help Get-Content para obtener más información
Figura 1 Ejecución de Help Get-Content para obtener más información (Hacer clic en la imagen para reducirla)
Figura 1 Ejecución de Help Get-Content para obtener más información
Figura 1 Ejecución de Help Get-Content para obtener más información (Hacer clic en la imagen para ampliarla)
Windows PowerShell trata casi todo como un objeto y los archivos de texto no son una excepción. Un archivo de texto es técnicamente una colección de líneas y cada línea del archivo actúa a modo de objeto independiente. De modo que, si creo un archivo de texto denominado C:\services.txt y lo lleno de nombres de servicio (colocando cada nombre en una línea del archivo), Windows PowerShell podrá leer los nombres individualmente mediante el valor de cmdlet Get-Content. Puesto que la idea de este tutorial es mostrar cómo se pueden desarrollar scripts de forma interactiva, comenzaré ejecutando Get-Content, dándole el nombre de mi archivo de texto y viendo lo que sucede:
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
Como esperaba, Windows PowerShell lee el archivo y muestra el nombre. Por supuesto, mi objetivo no es realmente que se muestren sólo los nombres, pero ahora sé que Get-Content funciona de la manera que esperaba.

Cambio de un servicio
El siguiente paso que deseo realizar es cambiar un modo de inicio de servicio. De nuevo, empiezo tratando de encontrar el valor de cmdlet correcto. De modo que ejecuto Help *Service*. Esto devuelve una lista corta y el valor de cmdlet Set-Service parece ser el único que responderá a mis necesidades. Deseo probar este valor de cmdlet para asegurarme de que comprendo cómo funciona antes de intentar incorporarlo a un script. Al ejecutar Help Set-Service, descubro cómo debe funcionar el cmdlet y una prueba rápida lo confirma:
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

Combinación de las partes
Ahora necesito combinar la capacidad de leer nombres de servicio de un archivo con el valor de cmdlet Set-Service, y es aquí donde entran en juego las eficaces capacidades de canalización de Windows PowerShell. Con la canalización, la salida de un cmdlet puede pasar como entrada a un segundo cmdlet. La canalización transfiere objetos enteros. En caso de que una colección de objetos se coloque en la canalización, cada objeto pasa a través de ella individualmente. Esto significa que la salida de Get-Content que, recuerde, es una colección de objetos, puede pasar a Set-Service. Puesto que Get-Content transfiere una colección, cada objeto (o línea de texto) de la misma se transfiere a Set-Service individualmente. El resultado es que Set-Service se ejecuta una vez para cada línea del archivo de texto. El comando es similar al siguiente:
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
Esto es lo que sucede:
  1. El valor de cmdlet Get-Content se ejecuta y lee el archivo entero. Cada línea del archivo se trata como un objeto único y juntas forman una colección de objetos.
  2. La colección de objetos pasa hasta Set-Service.
  3. La canalización ejecuta el valor de cmdlet Set-Service una vez para cada objeto de entrada. Para cada ejecución, el objeto de entrada pasa hasta Set-Service como primer parámetro del cmdlet, que es el nombre del servicio.
  4. Set-Service se ejecuta, usando el objeto de entrada para su primer parámetro y cualquier otro parámetro que se especifique (en este caso, el parámetro -startuptype).
En este momento, resulta interesante observar que he realizado la tarea sin escribir tan siquiera un script. Esta misma acción sería difícil de lograr en el shell de Cmd.exe y ocuparía una docena de líneas de código en VBScript. Sin embargo, Windows PowerShell procesa todo esto en una línea. De todos modos, aún no he acabado. Como puede ver, mi comando no ofrece muchos resultados de estado. Aparte de la falta de errores, es difícil ver si ha sucedido algo realmente. Ahora que he dominado la funcionalidad necesaria para realizar mi tarea, puedo empezar a darle un mejor aspecto mediante el auténtico scripting.
Función de símbolo instantáneo de Windows PowerShell por Michael Murgolo
Una de las aplicaciones Microsoft® PowerToys para Windows® más populares (y una de mis favoritas) es Abrir ventana de comandos aquí. Disponible como parte de Microsoft PowerToys para Windows XP o en las herramientas del kit de recursos de Windows Server® 2003, Abrir ventana de comandos aquí permite hacer clic con el botón secundario del mouse en una carpeta o unidad del Explorador de Windows para abrir una ventana de comandos que señala a la carpeta seleccionada.
A medida que iba conociendo Windows PowerShell, me di cuenta de que deseaba que tuviera la misma funcionalidad. De modo que tomé el archivo setup .inf de Abrir ventana de comandos aquí, cmdhere.inf, de las herramientas del kit de recursos de Windows Server 2003 y lo modifiqué para crear un menú contextual de símbolo instantáneo de Windows PowerShell. Este archivo .inf se incluye con la publicación del blog original en la que se basa esta barra lateral (disponible en leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx). Para instalar la herramienta, sólo tiene que hacer clic con el botón secundario del mouse en el archivo .inf y seleccionar la opción de instalación.
Al crear la versión de Windows PowerShell de esta herramienta, descubrí que la original tenía un error: si se desinstalaba Abrir ventana de comandos aquí, dejaba una entrada de menú contextual sin función. Como resultado, he proporcionado una versión actualizada de cmdhere.inf, también disponible en la publicación del blog original.
Estos dos PowerToys se aprovechan del hecho de que las entradas de menú contextual se configuran en el registro bajo claves asociadas a los tipos de objeto de directorio y unidad. Se trata de la misma forma en que las acciones de menú contextual están asociadas a tipos de archivo. Por ejemplo, al hacer clic con el botón secundario del mouse en un archivo .txt en el Explorador de Windows, se obtienen varias acciones (como Abrir, Imprimir y Editar) en la parte superior de la lista. Para entender cómo están configurados estos elementos, echemos un vistazo al subárbol de registro HKEY_CLASSES_ROOT.
Si abre el Editor del Registro y amplía la rama HKEY_CLASSES_ROOT, verá claves denominadas por tipo de archivo, como .doc, .txt y similares. Si hace clic en la clave .txt, verá que el valor (Predeterminado) es txtfile (consulte la Figura A). Éste es el tipo de objeto asociado a un archivo .txt. Si desplaza y expande la clave txtfile y, a continuación, expande la clave de shell contenida en ésta, verá las claves de algunas entradas de menú contextual de un archivo .txt. (No las verá todas porque hay otros métodos de creación de menús contextuales). Bajo cada una de ellas, hay una tecla de comando. El valor (Predeterminado) de la tecla de comando es la línea de comandos que Windows ejecuta al seleccionar el elemento del menú contextual.
Las herramientas para el símbolo de cmd y el símbolo de Windows PowerShell usan esta técnica para configurar las entradas de menú contextual de Abrir ventana de comandos aquí y la función de símbolo instantáneo de Windows PowerShell. No hay ningún tipo de archivo asociado a unidades ni directorios, aunque hay claves de unidad y directorio en HKEY_CLASSES_ROOT asociadas a los objetos.
Figura A Entradas de menú contextual configuradas en el registro
Figura A Entradas de menú contextual configuradas en el registro (Hacer clic en la imagen para reducirla)
Figura A Entradas de menú contextual configuradas en el registro
Figura A Entradas de menú contextual configuradas en el registro (Hacer clic en la imagen para ampliarla)

Michael Murgolo es consultor jefe de infraestructuras de Servicios de consultoría de Microsoft (Microsoft Consulting Services, MCS) Está especializado en las áreas de sistemas operativos, implementación, servicios de red, Active Directory, administración de sistemas, automatización y administración de revisiones.

Scripting interactivo
Uno de los procedimientos que necesito realizar es hacer que los valores de cmdlet se ejecuten para los servicios de C:\services.txt. De esta forma, podré obtener el nombre de servicio así como cualquier otra información que desee y podré seguir el avance del script.
Anteriormente, usé la canalización para pasar objetos de un cmdlet a otro. Esta vez, sin embargo, voy a usar una técnica más parecida al script, denominada construcción de Foreach (que presenté en la columna del mes pasado). La construcción de Foreach puede aceptar una colección de objetos y ejecutar varios cmdlets para cada objeto de la colección. Designo una variable que representa el objeto actual en cada momento a lo largo del bucle. Por ejemplo, la construcción puede empezar así:
foreach ($service in get-content c:\services.txt)
Sigo ejecutando el mismo valor de cmdlet Get-Content para recuperar el contenido del archivo de texto. Esta vez, solicito que la construcción de Foreach se repita a través de la colección de objetos devueltos por Get-Content. El bucle se ejecuta una vez en cada objeto y el objeto actual se coloca en la variable $service. Ahora sólo tengo que especificar el código que deseo ejecutar con el bucle. Comenzaré intentando duplicar mi comando de una sola línea original (esto minimizará la complejidad y asegurará que no pierda ninguna funcionalidad):
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
Aquí se producen algunos procesos interesantes. Observe que he terminado la primera línea de la construcción de Foreach con una llave de apertura. Todo lo que hay dentro de las llaves de apertura y cierre se considera dentro del bucle de Foreach y se ejecutará una vez para cada objeto de la colección de entrada. Después de escribir { y presionar Entrar, observe que Windows PowerShell ha cambiado su símbolo por >> (consulte la Figura 2). Esto indica que sabe que he empezado una construcción de alguna clase y que está esperando a que la termine. A continuación, he escrito el valor de cmdlet Set-Service. Esta vez, he usado $service como primer parámetro, ya que representa el nombre del servicio actual leído en mi archivo de texto. En la línea siguiente, concluyo la construcción con una llave de cierre. Después de presionar Entrar dos veces, Windows PowerShell ejecuta de inmediato mi código.
Figura 2 Windows PowerShell sabe que se ha iniciado una construcción
Figura 2 Windows PowerShell sabe que se ha iniciado una construcción (Hacer clic en la imagen para reducirla)
Figura 2 Windows PowerShell sabe que se ha iniciado una construcción
Figura 2 Windows PowerShell sabe que se ha iniciado una construcción (Hacer clic en la imagen para ampliarla)
Correcto, de inmediato. Lo que he escrito parece un script, pero Windows PowerShell realmente se está ejecutando en tiempo real y no se ha almacenado en ningún archivo de texto. Ahora volveré a introducirlo todo, agregando una línea de código para obtener el nombre de servicio actual:
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
Observe que estoy solicitando que muestre algo y he encerrado ese algo entre comillas dobles. Las comillas indican a Windows PowerShell que se trata de una cadena de texto y no de otro comando. Sin embargo, al usar comillas dobles (frente a las simples), Windows PowerShell busca cualquier variable en la cadena de texto. Si encuentra alguna, sustituye el valor real de la variable por el nombre de la misma. De esta forma, al ejecutarse el código, puede comprobar que se muestra el nombre de servicio actual.
¡Y esto todavía no es un script!
Hasta ahora, he usado Windows PowerShell interactivamente, que es una forma estupenda de ver de inmediato los resultados de lo que escribo. Sin embargo, en algún momento, el hecho de volver a escribir estas líneas de código se volverá algo tedioso. De ahí que Windows PowerShell también pueda ejecutar scripts. De hecho, los scripts de Windows PowerShell siguen la definición más literal de la palabra script: Windows PowerShell básicamente sólo lee en el archivo de texto de script y "escribe" cada línea que encuentra, exactamente como si el usuario escribiera las líneas manualmente. Esto significa que todo lo que he realizado hasta este momento se puede pegar en un archivo de script. Así, usaré Bloc de notas para crear un archivo denominado disableservices.ps1 y pegar lo siguiente en él:
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
He colocado este archivo en una carpeta denominada C:\test. Ahora trataré de ejecutarlo desde Windows PowerShell:
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
¡Ay! ¿Qué ha salido mal? Windows PowerShell se ha centrado en la carpeta C:\test, pero no ha encontrado mi script. ¿Por qué? Debido a restricciones de seguridad, Windows PowerShell está diseñado para no ejecutar ningún script de la carpeta actual, con lo cual evita que un script se apropie de cualquier comando del sistema operativo. Por ejemplo, no puedo crear un script con el nombre dir.ps1 y que invalide el comando normal dir. Si necesito ejecutar un script desde la carpeta actual, tengo que especificar una ruta de acceso relativa:
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
Y ahora, ¿qué? Sigue sin funcionar. He obtenido la ruta de acceso correcta, pero Windows PowerShell dice que no puede ejecutar ningún script. Esto se debe a que, de forma predeterminada, Windows PowerShell no puede ejecutar scripts. De nuevo, se trata de una precaución de seguridad diseñada para evitar los problemas que todos hemos tenido con VBScript. Los scripts malintencionados no se pueden ejecutar en Windows PowerShell de forma predeterminada porque ningún script se puede ejecutar de forma predeterminada. Para ejecutar mi script, necesito cambiar explícitamente la directiva de ejecución:
PS C:\test> set-executionpolicy remotesigned
La directiva de ejecución RemoteSigned permite a los scripts sin firmar que se ejecuten desde el equipo local (para ejecutar los scripts descargados, sigue siendo necesaria una firma). Allsigned es una directiva más adecuada que sólo ejecuta scripts firmados digitalmente con un certificado emitido por un editor de confianza. Sin embargo, no tengo ningún certificado a mano, por lo que no puedo firmar mis scripts y RemoteSigned será una elección bastante buena para esta situación. Ahora trataré de ejecutar mi script de nuevo:
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
Quiero indicar que la directiva de ejecución RemoteSigned que vamos a usar no es una gran elección; es solamente una buena. Aunque existe una solución mucho mejor. Sería más seguro obtener un certificado de firma de código, usar el valor de cmdlet Set-AuthenticodeSignature de Windows PowerShell para firmar los scripts y establecer la directiva de ejecución AllSigned, mucho más segura.
Hay también otra directiva, Unrestricted, que debe evitar sin duda. Esta directiva permite que todos los scripts (incluso scripts malintencionadas de ubicaciones remotas) se ejecuten libremente en el equipo, lo que puede ponerle en una situación muy peligrosa. Por consiguiente, no recomiendo usar la directiva Unrestricted en ningún caso.

Resultados inmediatos
Las capacidades de scripting interactivo de Windows PowerShell permiten crear prototipos de script de forma rápida o incluso pequeñas partes de script. Obtendrá resultados inmediatos, de modo que puede ajustar los scripts para obtener exactamente los resultados que desee. Cuando termine, puede pasar el código a un archivo .ps1, para conservarlo y que sea fácilmente accesible en el futuro. Y recuerde: lo ideal es que firme digitalmente los archivos .ps1 para poder dejar que Windows PowerShell establezca la directiva de ejecución AllSigned, la directiva más segura que permite la ejecución de scripts.

Don Jones es el principal gurú de scripting de SAPIEN Technologies y coautor de Windows PowerShell: TFM (en inglés) (consulte www.SAPIENPress.com). Póngase en contacto con él en la dirección don@sapien.com.


 &#161;Hola, chicos del scripting!: Persecuci&#243;n de coches... y XML
¡Hola, chicos del scripting!
Persecución de coches... y XML
Los chicos del scripting de Microsoft
Descargar el código de este artículo: HeyScriptingGuy2007_02.exe (150KB)

"NO SÉ por qué mi perro persigue a los coches", dice un viejo chiste. "A fin de cuentas, ¿qué haría con uno si consiguiera cogerlo?
Una buena pregunta, que los chicos del scripting no pueden contestar. Bueno, a menos que se trate de Lucy, el perro que corre calle abajo y que atrapa el coche. No tenemos ninguna duda de que ese perro robaría una tienda de licores y utilizaría el coche para escapar. Y teniendo en cuenta el estado del césped delantero, estamos dispuestos a apostar que no haría ninguna parada de descanso durante el camino, no sé si sabe a qué me refiero.
Si tuviéramos que actualizar esta antigua historia por una de la era de alta tecnología actual, quizás dé como resultado algo como esto: "No sé por qué mi Administrador de sistemas siguen intentando aprender XML. A fin de cuentas, ¿qué haría con él si consiguiera aprender?
Nota En nuestra defensa, sólo dijimos que íbamos a actualizar ese viejo chiste: nunca dijimos que iba a ser divertido.
Para ser sincero, puede que el XML sea una especie de tecnología sobrevalorada, al menos en lo referente a la administración del sistema. La verdad es que muchos administradores de sistemas han vivido mucho tiempo y han disfrutado unas vidas felices sin escribir jamás una secuencia de comandos que interactúe con un archivo XML, así que no esperamos que eso cambie en un futuro próximo.
Dicho esto, también es verdad que cada vez más aplicaciones adoptan el XML como estándar para el almacenamiento de datos. ¿Por qué no? Puesto que se trata de simples archivos de texto con adornos, estos archivos de datos XML son rápidos y fáciles de crear, son portátiles entre las plataformas y no requieren ningún complicado programa de base de datos (por no decir caro). ¿Tiene un sistema operativo y un editor de texto? Entonces puede crear una base de datos XML.
Lo que quiere decir, por supuesto, que existe al menos una cosa que un Administrador de sistemas puede hacer con XML: escribir secuencias de comandos que consulten un archivo XML como si ese archivo fuera una base de datos completa. ¿Y, oye, quién mejor que los chicos del scripting para darle unos cuantos consejos sobre cómo llevar esto a cabo?
Bueno, de acuerdo, buen tanto. Sin embargo, si tuviéramos que aventurarnos a hacer una suposición, apostaríamos a que Lucy está, probablemente, muy ocupada desenterrando el parterre de alguien como para escribir una columna acerca de XML.
Para empezar, echemos un vistazo a un archivo XML sencillo (consulte la Figura 1), un archivo de la base de datos que representa cuatro secuencias de comandos que se encuentran en la columna diaria ¡Hola, chicos del scripting!
Figure 1 ¡Hola, chicos del scripting! Secuencias de comandos en XML (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
Como puede ver, es un archivo pequeño, bastante sencillo. Cada secuencia de comandos individual se archiva bajo una etiqueta <Script>. De ahora en adelante, nos referiremos a estas secuencias de comandos como registros. Sí, tiene razón £los aficionados a XML nunca se referirían a estos elementos como registros. No importa: nuestro objetivo es mostrarle cómo aplicar algo que ya conoce £técnicas de consulta a la base de datos£ a una clase nueva y diferente de origen de datos. Hemos pensado en centrarnos primero en cómo conseguir hacer las cosas, así que quizá volvamos a este tema en un futuro y le facilitemos la terminología apropiada.
De acuerdo, volvamos a los registros. Cada registro contiene los campos siguientes: <Category>, <Subcategory>, <Keyword>, <Title> y <URL>.
Hmm, parece que no está tan impresionado como cabía esperar. Quizá le ayudaría que le mostremos una secuencia de comandos que abriera este archivo XML y devolviera un eco del contenido:
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Nota Tenga cuidado: estos nombres de etiqueta distinguen entre mayúsculas y minúsculas. Es "/Repository/Script", no "/repository/script", ni "/REPOSITORY/SCRIPT".
Efectivamente, tampoco es demasiado impresionante. Pero ésa es la cuestión: no es ni la mitad de difícil de lo que esperaba.
Como puede ver en el código, empezamos creando una instancia del objeto Microsoft.XMLDOM, el objeto COM utilizado para el trabajo con archivos XML. Después, hemos establecido la propiedad Async en False. Esto garantiza que todo el archivo se lea en la memoria antes de que se le devuelva el control a la secuencia de comandos. A continuación, utilizamos el método de carga para leer el archivo C:\Scripts\Scripts.xml:
xmlDoc.Load("C:\Scripts\Scripts.xml")
En cuanto se haya cargado el archivo en la memoria, podemos utilizar el método selectNodes para seleccionar los registros especificados de la base de datos:
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
Échele un vistazo más detenidamente al parámetro transferido a selectNodes. Según parece, representa la ruta de acceso dentro del archivo XML. Nuestro archivo XML tiene la estructura siguiente:
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
¿Debería preocuparse? En una palabra: ¡sí! Al tratar con archivos XML, la estructura es muy importante. ¿Por ejemplo, cómo obtenemos las propiedades individuales de un registro? Muy sencillo: accedemos a la etiqueta <Repository> seguida por la etiqueta <Script>, seguidas por las etiquetas individuales de la propiedad. Y, ¿saben qué? Es la misma ruta de acceso que especificamos como parámetro para selectNodes. Simplemente seguimos esa ruta de acceso con /*, lo que significa "Selecciona todas las propiedades de estos registros". En otras palabras, nuestra recopilación devuelta consistirá en todas las propiedades de todos los registros de la base de datos, parecido a una consulta "Selecciona * de" del servicio Instrumental de administración de Windows® (WMI).
Nota Inténtelo con la secuencia de comandos de muestra y verá exactamente a qué nos referimos.
El resto de la secuencia de comandos es fácil; lo único que tenemos que hacer es configurar un bucle For Each para movernos a través de la recopilación y devolver un eco del valor de la propiedad Text de cada elemento y cada propiedad:
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
Más fácil que perseguir coches.
Sin embargo, tiene razón: si lo único que queríamos era devolver un eco de todo el contenido del archivo, podríamos habernos saltado toda esa historia del XML y simplemente utilizar FileSystemObject. (Quizás habría sido un poquito más complicado, pero apenas un poco). Si nuestra intención era deslumbrarle y hacerle pensar "Vaya, tampoco es tan difícil manejar este XML", bueno, probablemente aún tengamos otra posibilidades de demostrarlo.
Veamos qué podemos hacer al respecto. En la primera secuencia de comandos, recuperamos todos los valores de propiedad de todos los registros. Está bien, pero supongamos que lo que de verdad queríamos recuperar es el título de la secuencia de comandos. ¿Podemos hacerlo? Pues, un segundo...
De acuerdo, según Lucy, lo único que tenemos que hacer es modificar nuestro comando selectNodes, agregando la propiedad de interés al final de la ruta de acceso. En otras palabras:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
Según parece, la única razón por la que recuperamos todas las propiedades la primera vez es porque utilizamos el carácter comodín *. Ahora recuperamos sólo la propiedad Title. ¿Por qué? Porque es el único valor de propiedad que hemos pedido recuperar.
Nota Vaya, mira eso: XML le da exactamente lo que ha pedido. No te ofendas, Lucy, ¡pero creemos que el XML es el nuevo mejor amigo del hombre!
Y, claro, puede devolver más de una propiedad. Por ejemplo, este comando modificado devuelve los valores para las propiedades Title y URL:
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
Es verdad, la sintaxis es un poco rara, pero una vez se acostumbre, no está tan mal. Para empezar, especificamos la parte principal de la ruta de acceso, como hicimos antes:
    /Repository/Script/
A continuación, agregamos un conjunto de paréntesis y, dentro de esos paréntesis, especificamos las propiedades que se van a devolver. (Tenga en cuenta que utilizamos un separador £el carácter | £ para separar las propiedades individuales). En otras palabras:
    (Title | URL)
Como dijimos, puede que sea un poco simplón, pero funciona.
Y no, no está limitado a devolver solamente dos propiedades. Mientras siga agregando con separadores, puede devolver toda la información que desee su espíritu. Por ejemplo, el comando que sigue devuelve tres propiedades (Title, URL y Keyword):
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
Muy interesante, ¿verdad?
Bueno, pensamos que era interesante. Sin duda, son un público exigente. Sin embargo, de nuevo, ha marcado un buen tanto: lo único que hemos hecho hasta ahora es recuperar información acerca de todos los registros de la base de datos. Sin embargo, no hay nada malo en eso. Con frecuencia, suele ser lo que usted desea hacer. Por otro lado, habrá también veces (muchas veces) en las que queramos recuperar información únicamente acerca de un subconjunto de dichos registros. Por ejemplo, puede que queramos devolver información sólo acerca de las secuencias de comandos que tienen una palabra clave igual a las bases de datos. Ya sabe, con una consulta semejante a esta:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
De nuevo, la sintaxis es un poco rara. Como nota positiva, sin embargo, la sintaxis es también fácil y sin complicaciones. Después que especificar la ruta de acceso principal colocamos nuestra cláusula "Where" (por ejemplo, donde X iguala a Y) entre corchetes, de este modo:
/Repository/Script [Keyword = ‘databases’]
Como probablemente ya habrá deducido, nuestra cláusula Where equivalente indica la secuencia de comandos "Devuelve sólo los elementos en los que el atributo Keyword sea igual a las bases de datos". Tenga en cuenta que las bases de datos se encierran entre comillas sencillas. No sólo es completamente correcto, sino que es bastante necesario. Si el término del filtro está entre comillas dobles, obtendrá un error de sintaxis cuando intente ejecutar la secuencia de comandos.
Nota ¿Por qué? Porque, recuerde, toda la cadena de consulta £"/Repository/Script [Keyword = ‘databases’]"£ está entre comillas dobles.
Por supuesto, no está limitado a utilizar el signo igual (=) al filtrar los datos. Puede utilizar los signos mayor que (>) o menor que (<), así como los favoritos de todos, los signos menor que o igual a (<=) y mayor que o igual a (>=). También puede anular cualquiera de estos signos colocando un signo de admiración delante. Por ejemplo, este comando solicita todas las secuencias de comandos donde Keyword no es igual a las bases de datos (fíjese en el signo !=):
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
Espere un segundo: ¿Quien ha dicho "Claro, se puede establecer un filtro, pero apuesto a que no se puede establecer un filtro y especificar las propiedades que desea que se devuelvan"? Por supuesto que puede:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
Si todo va bien, este comando devolverá sólo la propiedad Title de todas las secuencias de comandos que tengan las bases de datos de Keyword. Veamos si funciona:
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
Veamos si podemos incluir otro comando más antes de que se acabe el día. Aunque estamos progresando, aún podríamos devolver más registros de los que queremos devolver en realidad. A fin de cuentas, nuestro comando anterior devuelve una mezcla de secuencias de comandos de Microsoft® Access® y Microsoft SQL Server™. (¿Por qué? Porque todas estas secuencias de comandos utilizan las bases de datos de Keyword.) ¿Qué pasaría si quisiéramos limitar los datos devueltos a las secuencias de comandos que tengan bases de datos para la palabra clave y que tengan Microsoft SQL Server como subcategoría? ¿Es posible filtrar con múltiples criterios?
Como si tuviera que preguntar:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
es la misma sintaxis básica; acabamos de utilizar dos criterios separados (a saber, Keyword = databases' y Subcategory = 'Microsoft SQL Server') y ha conectado ambas con el operador AND.
Nota Sí, tiene razón: con este simple y pequeño archivo XML podríamos haber solicitado todas las secuencias de comandos cuya subcategoría fuera igual a Microsoft SQL Server. Pero eso no habría sido divertido y cualquier cosa menos educativo.
También puede utilizar cláusulas OR. Por ejemplo, supongamos que tenemos una gran cantidad de secuencias de comandos de Microsoft Office, incluidos los que tienen una subcategoría igual a Microsoft Excel®, Microsoft PowerPoint®, Microsoft Outlook®, etcétera. ¿Es posible restringir los datos devueltos únicamente a las secuencias de comandos de las subcategorías Microsoft Word o Microsoft Access? Claro que sí:
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
¿Mejor así? Efectivamente, quizás no se trate de la columna que cambió su vida para siempre; sin embargo, existen bastantes probabilidades de que, tarde o temprano, consultar un archivo XML de esta manera sea factible. Pero la decisión es suya: puede aprender algunas técnicas XML básicas o puede perseguir coches. Como quiera. (Si elige esto último y resulta que se encuentra con Lucy, el perro que va corriendo calle abajo, salúdela de parte de los chicos del Scripting. ¡Y dígale que ni se acerque al jardín!)
¡Hola, chicos del scripting! - Todos los días
Acaba de examinar con detenimiento la columna ¡Hola, chicos del scripting! de este mes y ha pensado que es el mejor material técnico que ha leído jamás. Quizás vaya aún más allá y diga que es la mayor obra maestra escrita hasta la fecha. Es más, se detiene ansioso delante de su buzón esperando el siguiente número de la Revista de TechNet, para poder seguir leyendo artículos como éste.
¿A qué diantres está esperando? ¿Quiere saber más acerca de Lucy, el perro del vecindario, o leer acerca de las últimas proezas del hijo del scripting? ¿Ha oído cómo ha ido la serie de juegos Turducken Bowl del año pasado? Esté al tanto de todos estos importantes asuntos leyendo las columnas ¡Hola, chicos del scripting! diarias £sí, hemos dicho "diarias". De lunes a viernes (menos las principales fiestas y las vacaciones de los chicos del scripting), podrá leer todo lo relacionado con el béisbol, el fútbol y el baloncesto de las ligas escolares y alguna que otra vez obtener un pronóstico meteorológico local. (Hay que reconocerlo: sólo es local si por "local" usted entiende Redmont, aunque, ¿quién no quiere saber cómo está el tiempo en Redmond?)
No sólo eso, en realidad también aprenderá todos los días algo nuevo acerca de la redacción de secuencias de comandos. Sí, en medio de todo este contenido fascinante se encuentra la auténtica información sobre la redacción de secuencias de comandos. En cada columna, los chicos del scripting contestan a preguntas verdaderas, enviadas por gente que consideran personas reales. Puede leer la columna diaria en microsoft.com/technet/scriptcenter/resources/qanda. También, puesto que ellos ya han contestado a centenares de preguntas, los archivos son bastante extensos y constituyen un gran origen de información sobre la redacción de secuencias de comandos (consulte microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx).
¿Tiene alguna pregunta para los chicos del scripting? Tendrá una pequeña oportunidad de recibir una respuesta si envía su pregunta a scripter@microsoft.com. (Por contra, no tendrá dicha oportunidad si no la envía, así que, ¿qué tiene que perder? A diferencia de un billete de lotería, es gratis y sus probabilidades son ligeramente mayores).

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 el TechNet Script Center. Visite la página web www.scriptingguys.com.


 Vigilancia de seguridad: Implementaci&#243;n de EFS: Parte 1
Vigilancia de seguridad
Implementación de EFS: Parte 1
John Morello

Hasta ahora, todo el mundo ha oído informes acerca de datos personales o confidenciales que se pierden a causa del robo de un equipo portátil o de una mala colocación. Los equipos portátiles desaparecen de forma periódica. Con el robo de identidad en alza y el cumplimiento normativo más crítico que nunca, una protección completa de datos en los sistemas informáticos móviles es esencial.
Una respuesta es utilizar el Sistema de cifrado de archivos (EFS), incluido en Windows® desde Windows 2000, que ofrece un cifrado integrado, de gran rendimiento y basado en el disco. El EFS se integra a la perfección con el Explorador de Windows, de forma que los usuarios finales a menudo no sabrán si el archivo que utilizan está cifrado. Además, el EFS funciona igualmente bien con las tecnologías nativas de autenticación y control de acceso de Windows, así los usuarios no tienen que recordar contraseñas independientes para tener acceso a sus datos. Por último, el EFS ofrece opciones manejables para recuperar datos en caso de que un usuario pueda perder el acceso a sus claves de cifrado (como si se elimina su perfil de usuario o queda dañado o si se pierde su tarjeta inteligente).
El EFS utiliza tecnología integrada de criptografía en Windows para generar, almacenar e implementar claves de cifrado de alta seguridad para proteger los datos. En Windows XP Service Pack 1 (SP1) y versiones posteriores, el EFS utiliza el algoritmo Estándar de cifrado avanzado (AES, Advanced Encryption Standard) con una clave de 256 bits para cifrar los datos en disco. Estas claves simétricas quedan protegidas con un par de clave asimétrico (RSA). El EFS cifra cada archivo con su clave AES. A continuación, cifra esta clave con la clave RSA del usuario y almacena el resultado en el archivo. Para obtener más información sobre criptografía de EFS, consulta la barra lateral "Recursos EFS". Por ahora, no me centraré en los apuntalamientos técnicos de EFS, sino más bien en cómo implementarlo y en cómo hacerlo viable en su entorno. Por este motivo, damos por sentado que cuenta con un conocimiento previo de conceptos de criptografía de EFS.

Un nota sobre seguridad de EFS
Existen algunas aplicaciones que afirman poder piratear o interrumpir el cifrado de EFS. Ninguna de estas aplicaciones descifra en realidad el texto cifrado de AES (o Estándar de cifrado de datos, DES, o Estándar ampliado de cifrado de datos, DESX), sino que obtiene acceso a la clave privada EFS del usuario mediante el forzado de la contraseña del usuario. Lo importante que se debe tener presente acerca del cifrado de EFS es que las claves privadas utilizadas para generar y proteger los datos cifrados utilizan la API de la Protección de Datos (DPAPI). La DPAPI utiliza los derivados de las credenciales de inicio de sesión del usuario para proteger los datos de forma que el resultado sea que la protección de datos con EFS es tan buena como lo sea la contraseña de usuario. Con Windows Vista™, ahora puede almacenar certificados de cifrado de EFS en tarjetas inteligentes, lo que cambia este paradigma y aumenta en gran medida la seguridad relativa de los datos protegidos de EFS.
¿Durante cuánto tiempo tiene que resistir una contraseña a estos ataques? Dadas las capacidades actuales del hardware y los algoritmos modernos de ataque de contraseñas, se recomienda una contraseña de 11 caracteres o mayor (o, mejor dicho, una frase). Una frase de 11 caracteres o más es sumamente resistente a los métodos más avanzados de hoy en día, incluyendo ataques de hash precalculados (como la tabla de cadenas arco iris; consulte la publicación en blog "Why you shouldn't be using passwords of any kind on your Windows networks" (en inglés) incluida en la barra lateral "Recursos" para obtener más información).

¿PKI o no PKI?
Una de las equivocaciones más comunes acerca de EFS es que requiere una infraestructura de claves públicas (PKI) para funcionar. Si bien EFS se puede integrar fácilmente y se aprovecha de una PKI, si su organización tiene una, no se trata en ningún caso de un requisito. Dicho esto, la decisión relativa a si utilizar o no una PKI en la implementación de EFS afectará a muchas futuras decisiones de implementación, de modo que se debe examinar primero.
La ventaja principal de utilizar una PKI con EFS es la capacidad de llevar a cabo la recuperación y archivado de claves. Mientras que EFS admite sólo a administradores para realizar la recuperación de datos, la recuperación de claves automática está sólo disponible con una PKI, e incluso entonces, sólo al ejecutar Windows Server® 2003 Enterprise Edition como Autoridad de Certificado (CA). La recuperación de datos es el proceso por el que un usuario que pierde el acceso a su clave de cifrado puede ofrecerle sus datos cifrados a un administrador designado, conocido como Agente de Recuperación de Datos (DRA), que puede a su vez descifrar dichos datos y devolvérselos al usuario o volver a cifrarlos para su uso con una clave privada nueva. El DRA funciona como una sombra del proceso de cifrado del usuario, proceso según el cual todo que cifre el usuario con su clave se cifra también con una copia de la clave del DRA. Así, cuando se pierde la clave de usuario, el DRA puede entrar, obtener los datos del texto cifrado, aplicarle una clave de DRA para descifrarlo (o volver a cifrarlo) y, a continuación, devolver los datos al usuario. El enfoque de DRA funciona bien, pero puede ser difícil de administrar si el usuario ha cifrado cantidades grandes de datos o no tiene personal local de TI para que actúen como DRA.
La recuperación de claves, por otro lado, requiere que el CA haga una copia de la clave de cifrado del usuario durante el proceso de creación de claves y almacene de forma segura la copia de dicha clave en la base de datos de CA. Entonces, cuando un usuario pierde el acceso a archivos cifrados, el administrador de la entidad emisora sólo necesita entrar en esta base de datos y recuperar la clave de usuario. En ese punto, el usuario tendrá acceso inmediato a sus datos otra vez sin que tener que disponer de un DRA para recuperarlos. Cuándo se haga así, la recuperación de claves puede ser más rápida y más eficiente. Tenga en cuenta, sin embargo, que una práctica recomendada consiste en tener siempre DRA disponibles, incluso cuando se utilice la recuperación de claves, para ofrecer un mecanismo de copia de seguridad para eventos de pérdida de claves. Esto también admite que las organizaciones grandes tengan un sistema de recuperación distribuido donde los administradores locales de TI puedan recuperar los datos de usuarios sin tener que involucrar al grupo de administradores de PKI.
Otra prestación posible derivada del uso de PKI con EFS es facilitar un uso compartido más fácil de archivos cifrados. Recuerde que EFS no se limita únicamente a sistemas de equipo portátil; puede ser igualmente valioso en cualquier situación donde la seguridad física de un equipo no se pueda garantizar. En estas situaciones, es posible que exista la necesidad de que múltiples usuarios puedan tener acceso a los mismos datos cifrados. Si bien el soporte técnico de Windows para el uso compartido de archivos cifrados está limitado de algún modo, ya que sólo admite el uso compartido de archivos individuales, no directorios, puede ser una herramienta útil. Para facilitar el uso compartido de archivos de EFS, el usuario que comparte el archivo debe tener acceso a las claves públicas de los usuarios con los que comparte (lo que es más fácil si esos usuarios tienen un certificado EFS válido publicado en su cuenta de Active Directory®). Si bien es posible llevar a cabo esta publicación manualmente, el uso de un CA de Windows instalado en el modo Enterprise (integrado en Active Directory) automatiza el proceso completamente.

Administración de claves de EFS
Si tiene una PKI basada en Windows Server 2003 disponible para utilizar, la generación de certificados EFS del usuario es un proceso sencillo. Un CA de Windows Server 2003 viene acompañado de un conjunto predeterminado de plantillas de certificado, incluyendo una EFS básica. Sin embargo, esta plantilla es una plantilla de versión 1 y no es compatible con el archivado de claves. Por tanto, antes de ponerla disponible en el CA, querrá duplicar la plantilla para crear una nueva plantilla de versión 2 (por ejemplo, lo podría llamar EFS con archivado de claves, como se muestra en la Figura 1). En esta plantilla nueva, vaya a la ficha de manejo de solicitudes y seleccione la opción de archivado de claves de cifrado del usuario. Tenga en cuenta que tendrá que tener el archivado de claves configurado correctamente en el CA antes de habilitar esta opción. En la sección de recursos se incluye un excelente paseo por el proceso. También debe establecer esta plantilla para sustituir la EFS básica y asegurarse así de que los clientes utilicen esta nueva versión (consulte la Figura 2).
Figura 1 EFS con archivado de claves
Figura 1 EFS con archivado de claves (Hacer clic en la imagen para reducirla)
Figura 1 EFS con archivado de claves
Figura 1 EFS con archivado de claves (Hacer clic en la imagen para ampliarla)
Figura 2 Sustitución de la plantilla EFS básica
Figura 2 Sustitución de la plantilla EFS básica (Hacer clic en la imagen para reducirla)
Figura 2 Sustitución de la plantilla EFS básica
Figura 2 Sustitución de la plantilla EFS básica (Hacer clic en la imagen para ampliarla)
A continuación, tendrá que establecer los permisos apropiados en la plantilla para admitir que el conjunto correcto de usuarios tenga acceso de inscripción. Dado que el componente EFS en Windows solicitará automáticamente un certificado la primera vez que se utilice EFS, normalmente no tiene que admitir la inscripción automática de usuarios en relación con la plantilla EFS. De hecho, yo no le recomendaría que admita la inscripción automática para los certificados EFS a menos que esté seguro de que todos los usuarios inscritos automáticamente utilizarán EFS. En la Figura 3 se muestra la configuración de la inscripción EFS. Si emite certificados para usuarios que puede que nunca utilicen EFS aumentará el tamaño de la base de datos de CA sin finalidad alguna. Aunque el tamaño de la base de datos de CA no está limitado, puede resultar más difícil de administrar (sobre todo a través de la Microsoft Management Console o MMC) ya que aumenta el número de certificados publicados.
Figura 3 Configuración de permisos de usuario de EFS
Figura 3 Configuración de permisos de usuario de EFS (Hacer clic en la imagen para reducirla)
Figura 3 Configuración de permisos de usuario de EFS
Figura 3 Configuración de permisos de usuario de EFS (Hacer clic en la imagen para ampliarla)
Por último, si necesita compatibilidad con el uso compartido de archivos cifrados, puede que desee que el CA publique automáticamente el certificado de usuario en Active Directory.
Una vez haya configurado la plantilla correctamente en el CA, la primera vez que un usuario cifra un archivo con EFS, obtendrá su certificado del CA y éste archivará automáticamente su clave privada.

Administración de claves de DRA
La siguiente pregunta que se debe tener en cuenta si tiene una PKI en funcionamiento es si utilizar o no certificados de DRA generados por el CA. ¿Por qué no querría utilizar certificados de DRA del PKI? Imagine una situación donde tenga un CA emisor con un período de validez de certificado bastante corto (dos años o menos). Ese CA no podrá publicar ningún certificado con una validez más larga que la suya, lo que significaría que sus certificados de DRA tendrían (a lo más) una duración de dos años. Esto puede dar como resultado una situación significativamente más compleja de recuperación de datos. Este ejemplo hipotético se ilustra en la situación siguiente.
  1. Un usuario cifra un archivo en enero de 2006; los certificados de DRA que se han insertado en su equipo a través de la Directiva de grupo tiene una duración de dos años (caducan en enero de 2008).
  2. El usuario sigue trabajando con EFS, cifrando los archivos nuevos.
  3. En enero de 2008, los certificados de DRA caducan y el administrador inserta certificados nuevos a través de la Directiva de grupo.
  4. De aquí en adelante, cualquier operación de cifrado utiliza los certificados nuevos de DRA (incluido cualquier archivo que abra y que se hayan cifrado con los DRA antiguos; cuando se guardan, utilizarán los nuevos DRA) pero ninguno de los archivos que no se toquen quedará protegido por los DRA antiguos.
  5. El usuario daña accidentalmente su perfil y requiere la recuperación de datos.
  6. El administrador de TI ahora debe tener dos conjuntos de certificados de DRA: Los nuevos, para cualquier archivo tocado desde el paso 3, y el viejo, para cualquier archivo no tocado desde entonces.
Si bien es posible que el administrador de TI ejecute una secuencia de comandos después del paso 3 para actualizar todos los archivos con el DRA nuevo (mediante cipher.exe/U), puede ser un proceso engorroso. También, para ser claros, los pares de claves de DRA no son inútiles después de que hayan alcanzado su fecha de caducidad, aunque el componente EFS no admitirá operaciones nuevas de cifrado si se incluye un certificado de DRA caducado en la directiva de recuperación. Los archivos antiguos cifrados con pares de claves de DRA pueden, por supuesto, recuperarse. Por tanto, los pares de claves de DRA nunca se deben descartar, ni siquiera después de que haya caducado su periodo de validez. Simplemente no sabe cuándo necesitará utilizarlos.
Para estas razones, le recomiendo que los entornos que tengan CA con duraciones de certificado cortas empleen certificados de DRA autofirmados con vidas más largas. La utilidad de cifrado incluye un conmutador (cipher.exe/R) que crea automáticamente pares de claves del agente de recuperación de EFS con una duración de 100 años (consulte la Figura 4). El certificado de este par de claves se puede adjuntar a objetos de directiva de grupo (GPO) y se puede utilizar como DRA en toda la organización. Puesto que el componente EFS no comprueba la cadena de confianza de los certificados de DRA, estos certificados autofirmados funcionarán sin tener que realizar ningún cambio en la lista de autoridades de confianza de certificado raíz de los sistemas. Independientemente de la duración de un CA de la organización, siempre recomiendo crear por lo menos un certificado de DRA duradero y adjuntarlo a un GPO para todo el dominio. Ésta es la opción de recuperación de datos de reserva para usarla en caso de que el resto de opciones fallen. Esto es especialmente vital si utiliza claves de DRA generadas por CA en ausencia de un archivado de claves de CA. En caso de que un certificado de DRA quede comprometido, puede actualizar el GPO con un certificado nuevo y utilizar cipher.exe/U, como se ha indicado anteriormente, con el fin de actualizar sus archivos.

Figura 4 Ejecución de Ciquer /R (Hacer clic en la imagen para reducirla)

Figura 4 Ejecución de Ciquer /R (Hacer clic en la imagen para ampliarla)
Recurso de EFS
Puede obtener aún más información sobre detalles de EFS y prácticas recomendadas en los sitios siguientes.
  • Why you shouldn’t be using passwords of any kind on your Windows networks (en inglés)
  • Implementing Key Archival Walkthrough (en inglés)
  • Encrypting File System in Windows XP and Windows Server 2003 (en inglés)

Implementación de DRA y KRA
El archivado de claves ofrece la capacidad para los administradores de CA de recuperar las claves de cifrado custodiadas en nombre del usuario. Obviamente, se trata de una capacidad muy sensible y eficaz, ya que puede admitir que un administrador de CA descifre cualquier dato en la organización que utiliza una clave firmada por el CA. Por tanto, la recuperación y el archivado de claves se deben tratar con cuidado y sólo se le debe otorgar este permiso a una pequeña parte del personal de seguridad de confianza. Debido a la naturaleza sensible de la recuperación de claves, si desea depender de ello como mecanismo principal para recuperar el acceso a datos cifrados de EFS, es importante tener un proceso de derivación claramente definido para que las solicitudes de recuperación se envíen al equipo de administración de CA. Sólo después de que la solicitud se haya investigado con cuidado se debe iniciar el proceso de recuperación. Entonces, una vez que se recupera la clave, se le debe ofrecer al usuario a través de un método seguro (en otras palabras, no a través de correo electrónico) ya que la clave recuperada ofrece acceso a todos los datos protegidos por EFS del usuario.
Las claves del Agente de recuperación de claves o KRA se generan y mantienen por los administradores de CA y no se anuncian a través de la Directiva de grupo. De hecho, el propio EFS no puede determinar si se ha archivado o no una clave que utiliza. Simplemente realiza sus operaciones de cifrado como lo haría normalmente. Además, las claves de KRA creadas en el CA no son específicas de EFS de ningún modo. Un CA que utilice el archivado de claves tendrá un número n de claves de KRA adjuntas en el nivel de CA que se utilizarán para proteger cualquier clave archivada por el CA. Estas claves pueden incluir las utilizadas con EFS, correo electrónico seguro o cualquier otro fin de certificado que incluya cifrado. Las claves de KRA se deben almacenar de forma segura por los agentes de recuperación de claves individuales y debe haber al menos dos KRA que se utilicen para ofrecer una solución alternativa en caso de que se pierda una de las claves.
La primera vez que un administrador inicia sesión en el controlador de dominio de un dominio recién creado, se crea una directiva de recuperación predeterminada en el nivel de dominio mediante un certificado autofirmado y un par de claves almacenadas en el perfil del administrador del DC. Este certificado de DRA tendrá una validez de tres años. El enfoque recomendado es eliminar este certificado predeterminado y reemplazarlo con certificados autofirmados de mayor duración y publicados por su PKI. Si no elimina este certificado autofirmado predeterminado, tres años después de su creación EFS detendrá el cifrado de los archivos nuevos de todo el dominio. Esto se debe a que el certificado habrá caducado y el EFS evitará el cifrado de más datos si se incluye un certificado de DRA caducado en su directiva de recuperación. Si bien es posible utilizar Windows XP y sistemas posteriores sin ninguna directiva de agente de recuperación en funcionamiento, no se lo recomendamos en absoluto. Si lo hace y un usuario pierde el acceso a su clave de cifrado por cualquier motivo y la recuperación de claves no es posible, todos sus datos se perderán irrevocablemente.
Como he dicho, las claves de DRA pueden ser autofirmadas o las puede haber publicado un CA. En la mayoría de los casos, es mejor un enfoque híbrido, con, al menos, dos DRA autofirmados de larga duración utilizados en toda la empresa como agentes de recuperación en última instancia. Dado que los certificados de DRA se implementan a través de los objetos de directiva de grupo, poseen las mismas capacidades de herencia que otros GPO. Es decir, el algoritmo de aplicación y acumulación de GPO de unidad organizativa, dominio, ubicación y local estándar que controla la aplicación de otra configuración de GPO corresponde también a los DRA. Por tanto, una organización puede implementar fácilmente un enfoque nivelado con respecto a los DRA, donde el grupo central de TI tiene acceso de DRA a cada parte de la empresa, pero donde los grupos locales de TI también mantienen la capacidad para sus áreas específicas de responsabilidad. Esto supone una ventaja especialmente valiosa en organizaciones geográficamente dispersas y grandes, ya que alivia la necesidad de transferir cantidades grandes de datos cifrados a través de vínculos de WAN para facilitar la recuperación de datos. En la Figura 5 se muestra una implementación típica de DRA con múltiples niveles.
Figura 5 Implementación de DRA de múltiples niveles
Figura 5 Implementación de DRA de múltiples niveles
En este caso, un usuario de la unidad organizativa Baton Rouge acabaría con seis DRA para cada archivo cifrado: dos de sus administradores locales, dos del grupo de TI de Norteamérica y dos del nivel de dominio. De este modo, si el usuario perdiera acceso a sus datos cifrados, lo podría recuperar gracias a un DRA local en el caso de Baton Rouge o gracias al grupo de TI de Norteamérica. Como opción final, si estos cuatro DRA no estuvieran disponibles o se perdieran, los DRA de nivel de dominio podrían hacerse cargo y recuperar los datos también. Independientemente de qué DRA haya realizado la recuperación, el proceso sería esencialmente el mismo. El usuario pondría primero los datos a disposición del DRA. Es importante que el DRA realice los pasos necesarios para asegurarse de que la solicitud sea legítima y que proceda del auténtico propietario de los datos. Una vez hecho esto, el DRA cargaría el certificado de DRA, descifraría (y preferiblemente volvería a cifrar) los datos y le enviaría de nuevo los datos al usuario final. Algunas organizaciones eligen también realizar una recuperación local, donde el DRA visitaría físicamente al usuario del problema, cargaría su par de claves de DRA en el perfil y descifraría los datos y eliminaría el par de claves. El usuario tendría así acceso a los datos con formato de texto simple y podría volver a cifrarlos con una clave nueva. Se debe tener en cuenta que este enfoque es mucho menos seguro, ya que el par de claves de DRA se copia (aunque temporalmente) a la máquina local, pero puede ahorrar algún tiempo, sobre todo si se debe recuperar una gran parte de los datos.
Tenga en cuenta que si se le ofreciera al usuario una recuperación a través de la recuperación y el archivado de claves, la solicitud de recuperación se trataría independientemente de este proceso. En vez de utilizar un DRA, la solicitud de recuperación de claves del usuario pasaría a los administradores de CA, que deben investigar la solicitud, entrar al archivado y recuperar la clave privada del usuario. A continuación, pondrían esta clave a disposición del usuario de forma segura, como, por ejemplo, colocándola en un sitio Web seguro para su descarga. (Si el usuario utilizaba una tarjeta inteligente para almacenar su clave de EFS, disponible con Windows Vista, esa clave también se debe volver a publicar). El usuario cargaría esta clave en su perfil y tendría acceso inmediato a todos sus datos cifrados.
Dado que el DRA y los pares de claves se pueden utilizar para descifrar datos confidenciales, es importante que estén bien protegidos. Los pares de claves de KRA y DRA no se deben almacenar en los perfiles de administradores normales de escritorio (los perfiles en los que llevan a cabo sus tareas diarias normales). En lugar de esto, estos pares se deben almacenar de forma segura y sin conexión en un disquete, en un disco óptico o en un medio flash, y en una ubicación físicamente segura. De este modo, cuándo se necesite la recuperación, el agente de recuperación puede cargar el par de claves en una estación de trabajo desde estos medios, realizar la operación de recuperación y eliminar el par. En algunas organizaciones especialmente sensibles a la seguridad, se designan estaciones de trabajo dedicadas a la recuperación y aumento de la seguridad de estos pares de claves, aunque esto no es un requisito para todas las organizaciones.

La próxima vez
Ahora que he examinado la administración de claves, la recuperación de datos y los aspectos de Active Directory relativos a la planificación de EFS, me centraré en las preguntas de desarrollo de los clientes en la parte 2 de este tema, que se publicará el mes próximo. En ella explicaré temas tales como el control del uso de EFS a través de las directivas de grupo, la elección de qué se debe cifrar, el cifrado automático de los datos a través de secuencias de comandos de inicio de sesión y mejoras del cliente para el Explorador de Windows con el fin de trabajar con datos protegidos por EFS de forma aún más fácil.

John Morello se graduó summa cum laude en LSU y ha trabajado con Microsoft durante seis años en una amplia variedad de funciones. Como Consultor senior, ha diseñado soluciones de seguridad para empresas pertenecientes a Fortune 100 y para clientes de defensa, civiles y federales. Actualmente es Director de programa en el grupo de Windows Server que trabaja en tecnologías


 Archivos del escritorio: Ampliaci&#243;n de Windows PE
Archivos del escritorio
Ampliación de Windows PE
Wes Miller

Antes incluso de lanzar al mercado Windows PE hace más de cinco años, algunos clientes deseosos ya solicitaban más características. Desgraciadamente, Windows PE no se diseñó para ser ampliado fácilmente del modo que, digamos, puede ampliarse Windows XP Embedded, con la adición de más capas en el sistema operativo. Por supuesto, Windows PE tuvo que contar con el soporte del rudimentario
Win32 ® (tal como funcionarían la mayoría de las aplicaciones de Windows ®) y el soporte de redes y almacenamiento masivo (para establecer comunicaciones por la red y poder instalar Windows). Pero ya desde el principio, el shell fue algo que quisimos restringir; utilizando cmd.exe en lugar del shell tradicional de Windows Explorer limitamos las posibilidades del entorno de Windows PE y, lo que es más importante, lo hicimos para que el entorno predeterminado fuera fácilmente ejecutable mediante secuencias de comandos para todas tareas de la automatización.
Aún así, puede ampliar Windows PE, lo único que tiene que recordar es que es limitado. Cabe esperar que la aplicación no funcione o que se comporte incorrectamente si necesita alguna de las tecnologías enumeradas en la lista de la Figura 1 (esta lista no es exhaustiva).
Figure 1 API que faltan de Windows (Close Figure 1)

.NET Framework (cualquier versión)
Interfaces de servicio de Active Directory® (ADSI, Active Directory® Services Interfaces)
DirectX®
Microsoft Data Access Components (MDAC)
Jet (Access)
Visual Basic® (versiones previas a .NET incluidas)
Cualquier tipo ejecutable que necesite un marco que no esté instalado con Windows de forma nativa.
Explorador de Windows o Internet Explorer
Reproductor de Windows Media®
SAPI, MAPI, TAPI (API de discurso, correo y telefonía de Windows respectivamente)
Si no sabe de qué depende su aplicación, es necesario que lo averigüe. ¿Pero cómo? Cuándo tratamos de que los componentes de ADO, las aplicaciones HTML (HTA) y Windows Script Host (WSH) funcionaran con Windows PE antes de lanzarlo al mercado, nos enfrentamos al mismo problema. Hay que tener en cuenta sin embargo que si bien este artículo describirá maneras para localizar estas dependencias, la adición de código binario de Windows a la imagen de Windows PE más allá de lo que incluye el comando MKIMG no está contemplado en el Contrato de licencia para el usuario (CLUF). Será necesario que adquiera un anexo de licencia de Microsoft para poder implementar cambios de esa naturaleza en su entorno.

Descripción de las dependencias
Si abre el archivo .inf de una aplicación en el Bloc de notas y lo examina con atención, podrá aprender mucho. De hecho, es a menudo la manera más fácil de conocer el sentido de una aplicación y de saber qué dependencias tiene. Lo importante que hay que saber acerca de Windows PE es que generalmente es tan limitado que tendrá que depurar múltiples niveles de dependencias £las dependencias directas de su propia aplicación y las dependencias que cada una de ellas pueda generar£ para que la aplicación funcione de forma fiable. En esencia, se puede producir una gran cascada de dependencias si no se tiene cuidado. Con algunas adiciones accidentales (o a propósito) al componente, la imagen puede aumentar considerablemente de tamaño y complejidad.
Si tiene un archivo .inf que describe la aplicación, puede obtener indicios acerca de las dependencias localizando claves del Registro y archivos que el archivo .inf agrega al sistema. Busque las secciones CopyFiles y AddReg. Estas entradas señalarán a apps, DLL y a otros archivos de los que dependa la aplicación. De los tres complementos para Windows PE (ADO, HTA y WSH), WSH fue el más sencillo de crear. Debido a que aún estaba disponible una versión redistribuible de WSH para versiones anteriores de Windows y porque existe un archivo .inf integrado en Windows hoy en día que se encarga de realizar las asociaciones de archivos para WSH (en %windir%\inf\wsh.inf), su instalación en Windows PE fue relativamente fácil.

Orca y la realización de instantáneas
Si la aplicación en cuestión se distribuye como archivo de Microsoft ® Installer (MSI), puede hacer dos cosas para localizar las dependencias. Si es un gurú de MSI, puede utilizar Orca (una herramienta para editar archivos de Windows Installer que se distribuye como parte del SDK de la plataforma Windows Server ® 2003 R2: go.microsoft.com/fwlink/?LinkId=77941) para verlo. También puede instalar los componentes de MSI que desee realizando un análisis previo y posterior de los archivos y las claves del Registro que han cambiado. Puede hacer un volcado del Registro, instalar el app, volver a exportar el registro y ejecutar WinDiff en él (consulte la barra lateral "Cómo utilizar WinDiff"). El resultado puede entonces utilizarse como plantilla de los cambios que es necesario hacer en el Registro. El problema es que el número de cambios puede ser enorme. No obstante, puede ser la mejor opción si no tiene un archivo .inf (ni el autor de la aplicación) cercano.
Puede que el proceso de realización de instantáneas de una aplicación le resulte familiar. En esencia, es el mismo análisis previo y posterior que se realiza para conseguir que la aplicación se ejecute. Microsoft solía distribuir (con Windows 2000) una herramienta que realizaba este proceso, pero dicha herramienta ya no funciona con ninguna versión posterior de Windows. Hay diversas aplicaciones comerciales (herramientas para volver a empaquetar instalaciones) que pueden hacerlo, pero también es posible hacerlo con utilidades gratuitas. Para solucionarlo, instale el SDK de la plataforma (consulte el vínculo del párrafo anterior), que incluye WinDiff. Tenga en cuenta que para realizar la comparación WinDiff, lo ideal es que desee instalar la aplicación en Windows Server 2003, Service Pack 1 (SP1) porque esa es la versión de Windows PE que debe estar utilizando; Windows PE 1.6, una versión creada a partir de las ediciones Standard Edition o Enterprise Edition (con SP1). Al realizar esta tarea en Windows Server 2003, tendrá el entorno más parecido posible al que tendría con Windows PE (en el que obviamente no puede ejecutar MSI). Siga los pasos de la barra lateral "Cómo utilizar WinDiff".
De este modo, podrá tener acceso a gran cantidad de información que ha cambiado. Lamentablemente, no existe una forma sencilla de exportar la información que ha cambiado desde el Registro, ni capturas de archivo para crear algún tipo de manifiesto para instalar la aplicación. Es necesario incorporar los cambios manualmente. En este punto es donde encontramos algunos de los problemas más complicados de la primera versión de Windows PE. Conseguir que los componentes de HTA funcionaran por completo fue una tarea compleja, ya que no había una definición para ellos (fuera de Internet Explorer®) en Microsoft. Utilizando las diferencias, pudimos conseguir mediante procesos manuales el suficiente soporte para HTA para que resultara funcional. Aunque es posible agregar manualmente estas claves en el Registro de Windows PE, puede que desee agregarlas una vez iniciado Windows PE. Puede observar los archivos OC.bat y OC2.bat que se utilizaron para instalar el soporte para HTA, WSH y/o ADO en Windows PE a través de la secuencia de comandos buildoptionalcomponents.vbs incluida en las herramientas de creación de Windows PE.

Herramientas útiles
Aún después de aislar las dependencias directas, con frecuencia no se puede encontrar cada código binario del que depende la aplicación. No sabrá, por ejemplo, si requiere otro DLL u OCX para realizar alguna tarea. Así que, ¿cómo saberlo? Mark Russinovich, famoso por Sysinternals (ahora técnico en Microsoft) escribió una utilidad llamada listdlls que hace justamente eso. Listdlls puede descargarse de microsoft.com/technet/sysinternals/utilities/ListDlls.mspx. Para utilizar la utilidad, ejecute el comando listdlls.exe > dlls.txt y examine el resultado. La Figura 2 muestra el resultado de la ejecución de listdlls sobre sí misma. Puede comparar esta lista con los archivos DLL y OCX incluidos en Windows PE para determinar si todas las dependencias de la aplicación están en su sitio o no (en el caso de listdlls, ya están presentes). Para el soporte HTA en Windows PE, la utilidad listdlls fue esencial para identificar algunas dependencias que no se pudieron identificar de otro modo.
Figura 2 Resultado de la ejecución de lisdlls sobre sí misma
Figura 2 Resultado de la ejecución de lisdlls sobre sí misma (Hacer clic en la imagen para reducirla)
Figura 2 Resultado de la ejecución de lisdlls sobre sí misma
Figura 2 Resultado de la ejecución de lisdlls sobre sí misma (Hacer clic en la imagen para ampliarla)
Pero únicamente porque un archivo DLL esté incluido en la lista no significa necesariamente que la aplicación lo necesite para poder ejecutarse. Si carga el Bloc de notas, por ejemplo, verá que carga el archivo uxtheme.dll. En Windows PE, este archivo DLL no está disponible y, de hecho, dado que ya no se utilizan temas de Windows, nunca se cargará. Aprender cuáles de los archivos DLL que muestra la aplicación listdlls son realmente necesarios frente a cuáles carga Windows bajo petición es, desgraciadamente, una difícil tarea que requerirá una dosis importante de prueba y error o estar muy familiarizado con aspectos de nivel profundo de Windows (para ello, recomiendo el libro de Mark Russinovich y David Salomon, Microsoft Windows InternalsFourth Edition (Microsoft Press ®, 2004)
De hecho, Mark incluye también la misma funcionalidad en Process Explorer replacement for Windows Task Manager, disponible de forma gratuita. La diferencia es que la utilidad listdlls crea un resultado que, en mi opinión, es más fácil de establecer en secuencias de comandos y de utilizar para encontrar y reunir dependencias perdidas.
Tenga en cuenta que incluso una vez que se agrega un archivo DLL a la imagen, puede que aún haya trabajo por hacer. Es decir, hay dos tipos de archivos DLL: los que requieren registro y los que no. Desgraciadamente, no hay una manera fácil de distinguirlos, aparte de tratar de registrar cada uno de ellos. Para registrar un DLL (o un OCX), hay que ejecutar regsvr32 dllname.dll. Si funciona correctamente, recibe un cuadro de diálogo que le dice que se ha registrado el archivo DLL. De lo contrario, puede que no reciba ningún mensaje, o es más probable que vea un cuadro de diálogo que le informa de que hubo un error en el registro del DLL o que no ha podido ser registrado. Al desarrollar los componentes opcionales HTA y ADO para Windows PE, descubrimos que los DLL requieren almacenamiento de escritura al realizar su registro, tanto para escribir temporalmente, ya sea para copiar un archivo.inf para la instalación como para registrar alguna otra dependencia (es decir, un directorio específico que sea necesario). En Windows PE, solían suponer un error. Ahora nos complace saber que con Windows PE 2.0, este tipo de tareas funcionarán, ya que existe un espacio nuevo disponible de forma predeterminada.
Una tercera herramienta que Mark ha creado y sacado al mercado recientemente recibe el nombre de Process Monitor. Process Monitor puede contemplarse como un superconjunto de Regmon y Filemon, ya que ofrece muchos más detalles que cualquiera de ellos a la vez que agrega una capa nueva completa de comunicación entre procesos. Esta herramienta increíblemente eficaz puede ayudarle a solucionar problemas de aplicaciones de Windows, así como a dar respuesta a preguntas acerca de lo que suceden realmente con interdependencias de DLL. Es posible descargarse Process Monitor.

Eliminación de archivos de Windows PE
Junto con la capacidad de agregar cosas a Windows PE, otra petición frecuente eran las instrucciones sobre la forma de hacer Windows PE más pequeño. Hay pasos para ayudarle a reducir un poco el tamaño de Windows PE. La copia con licencia de Windows PE debe incluir una colección de herramientas de creación y alguna documentación. Uno de los documentos es un archivo de ayuda llamado winpe.chm. Si abre este archivo y examina la sección relativa al entorno de preinstalación de Windows de la guía de usuario, deberá ver un tema que trata la reducción del tamaño de Windows PE. Esta sección incluye una lista de archivos que puede eliminar sin riesgos (suponiendo que no los necesite). Encontrará tres secciones relativas a los archivos que puede eliminar:
  • Los archivos de fuentes pueden siempre eliminarse sin riesgos.
  • Las utilidades y archivos .inf relacionados con la red pueden eliminarse, pero sólo debe hacerlo si no tiene pensado utilizar su versión en la red en absoluto.
  • Las utilidades de línea de comandos no deben eliminarse. No recomiendo eliminar ninguna de ellas a menos que sepa específicamente su función y lo que puede suceder si la elimina.
Una vez que haya determinado qué archivos puede eliminar sin riesgos, puede simplemente copiar un archivo por lotes u otra secuencia de comandos y eliminarlos de su versión de Windows PE una vez que mkimg.cmd haya completado la versión.

Modificación del Registro de Windows PE
Puede ver que tomamos una decisión meditada al no instalar los componentes opcionales en el momento de la creación. Aunque esto supuso un poco más de tiempo en el momento de la ejecución, significó también que no tuvimos que desarrollar una forma completamente nueva de incluir estos componentes de nuevo en Windows PE; algo para lo que no teníamos tiempo y que seguramente hubiese supuesto haberlos omitido por completo. ¿Pero qué sucede si desea hacer un cambio en el Registro, tal como agregar algo en el delta de cambios del Registro de su aplicación, o si simplemente desea editar una clave que pueda mantener la aplicación en funcionamiento? Esta acción se puede realizar fácilmente, utilizando regedit, que muestra en la Figura 3. Siga estos pasos:
  1. Ejecute regedit y seleccione el subárbol HKEY_LOCAL_MACHINE.
  2. Seleccione Archivo | Cargar subárbol y, a continuación, examine hasta la ubicación de su versión de Windows PE. Seleccione setupreg.hiv en I386\System32\ (o MiniNT\System32, si se trata de una imagen que está colocando en un disco duro).
  3. Especifique un nombre temporal para el subárbol, tal como WinPE, y examine hasta ese nodo en HKLM.
  4. Modifique esta clave consecuentemente. Como punto de interés, observe que este nodo es en efecto el mismo nodo HKLM\System que sería en una instalación normal de Windows.
  5. Una vez que ha realizado sus modificaciones, seleccione la clave en HKLM que creó en el paso 3 (es muy importante hacerlo correctamente o podría dañar el sistema).
  6. Seleccione Archivo | Descargar subárbol... y confirme el cuadro de diálogo Sí | No, y asegúrese de desmontar el Registro cada vez, ya que tenerlo bloqueado evitará una compilación correcta de Windows PE.
Figura 3 Cómo abrir el Registro de Windows PE
Figura 3 Cómo abrir el Registro de Windows PE (Hacer clic en la imagen para reducirla)
Figura 3 Cómo abrir el Registro de Windows PE
Figura 3 Cómo abrir el Registro de Windows PE (Hacer clic en la imagen para ampliarla)
Puede modificar HKLM\System siguiendo estos pasos. Hay también otras dos claves que se encuentran en I386\System32 que le permiten modificar otras áreas del Registro: DEFAULT es el subárbol predeterminado para usuarios (incluso SYSTEM, que se ejecuta como al utilizar Windows PE), y SOFTWARE, que es igual que HKLM\Software. Como siempre, modifique el Registro con el cuidado y sólo si es necesario.
Ahora tiene más información que debe ayudarle a comenzar a mover su herramienta de recuperación o solución de problemas favorita en Windows PE. El próximo mes, trataré la serie PSTools, que es una colección de herramientas de administración del sistema muy útiles creadas también por Mark Russinovich.
Uso de WinDiff
WinDiff puede ayudarle a encontrar las dependencias de su aplicación. Siga estos pasos para realizar una correcta instalación y ejecución:
  1. Prepare su sistema para la instalación; desea minimizar el tiempo y cualquier cambio en archivos o el Registro entre la instantánea inicial y la final.
  2. Abra un símbolo del sistema y ejecute reg export HKLM C: \HKLM1.reg para realizar una exportación completa del subárbol del Registro HKEY_Local_Machine.
  3. Ejecute dir C: \*.*/S > C: \C1.txt para realizar un volcado completo de todos archivos en la unidad C: (suponiendo que C: es su unidad del sistema).
  4. Instale su aplicación y configure cualquier ajuste posterior a la instalación.
  5. Ejecute reg export HKLM C: \HKLM2.reg.
  6. Ejecute dir C: \*.*/S > C: \C2.txt.
  7. Abra WinDiff y seleccione Archivo | Comparar archivos... y seleccione HKLM1.reg en el primer cuadro de diálogo Abrir archivo y HKLM2.reg en el segundo.
  8. Debe ver un mensaje en rojo que le indica cuál es más nuevo. Tenga paciencia; puede que tarde un poco debido a que las exportaciones de HKLM pueden ser bastante grandes.
  9. Haga doble clic en el texto en rojo para ampliar las diferencias.
  10. Puede que desee configurar lo que se muestra en la comparación mediante una comprobación de Opciones | Mostrar sólo líneas correctas. Esto habilitará que sólo se muestren las líneas recientemente agregadas en el segundo archivo comparado (de modo que sólo aparecerán archivos nuevos y nuevas claves del Registro).
Tenga en cuenta que puede que necesite utilizar la función de búsqueda para localizar claves relacionadas con su aplicación. En las Figuras A y B, puede ver cambios de archivos y del Registro en una aplicación ficticia. Por suerte, las funciones de copiar y pegar están disponibles en WinDiff. Para utilizar estas funciones, basta con hacer clic en la línea > ! y seleccionar las líneas deseadas.
Figura A Entradas de WinDiff
Figura A Entradas de WinDiff (Hacer clic en la imagen para reducirla)
Figura A Entradas de WinDiff
Figura A Entradas de WinDiff (Hacer clic en la imagen para ampliarla)
Figura B Clave específica en WinDiff
Figura B Clave específica en WinDiff (Hacer clic en la imagen para reducirla)
Figura B Clave específica en WinDiff
Figura B Clave específica en WinDiff (Hacer clic en la imagen para ampliarla)

Wes Miller es Director de desarrollo de Pluck (www.pluck.com) en Austin, Texas. Anteriormente, Wes trabajó en Winternals Software en Austin, 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.


 Notas de campo: Simplemente deja de funcionar
Notas de campo
Simplemente deja de funcionar
R'ykandar Korra'ti

"NO SÉ, simplemente sigo perdiendo la conexión".
"¿Alguna hora concreta? ¿Algo específico que haga cuando sucede? ¿Algún equipo en concreto desde el que se conecta?"
"No. Estoy conectada y, entonces, ya no lo estoy. ¡Mierda! Ya se ha ido".
"Eso no me da mucho con lo que trabajar. Vamos, dígame algo más. Una sugerencia, una pista, algo".
"Le he dicho todo lo que sé. A veces simplemente pierdo la conexión. ¿Puede corregirlo?"
Le dije que lo estudiaría. No hay mucho en los registros del enrutador, pero ocasionalmente nuestro tráfico disminuye realmente, lo que indica que algo falla (aunque sólo durante uno o dos minutos, tras los cuales todo vuelve a la normalidad). No hay ningún error, ningún patrón, sólo las pérdidas frecuentes de tráfico. Es extraño. Entonces tenemos suerte:
Ring ring, suena el teléfono acoplado a la línea ADSL.
Nuestra conexión de IP se pierde.
Es una broma, pienso. Y entonces lo veo: si alguien llama al número de teléfono de ADSL (ése que nadie usa y que se supone que nadie conoce), se pierde la conexión. El mayor desastre por el que la empresa telefónica reivindica que nunca tendrá que preocuparse en el punto de venta del servicio número uno, ocurre con rapidez y de forma llamativa.
Y, lo que es más, sólo estamos a 300 metros de la subestación. Esto no debería ocurrir. Compruebo los cables, lo reinicio todo e incluso limpio las conexiones para ver si sirve de algo. Pero, por supuesto, no es así. De modo que llamo a la empresa telefónica. "¿Sabe que su gente promete que nunca se interrumpirá la conexión por llamadas telefónicas entrantes? ¿Adivina qué sucede? Tal vez estemos muy influenciados por los televendedores".
Quizá sea el cable...
Quizá sea el cable...
Un técnico viene al día siguiente y descubre que, inexplicablemente, realizamos las pruebas a más de 900 m de distancia de la subestación, lo suficientemente lejos como para que una malhumorada ardilla pudiera cortar nuestra conexión con un pequeño imán de brújula. Finalmente, descubrimos que cuando se instaló el cableado en nuestro vecindario, todas las líneas de teléfono estaban agrupadas y se envío una línea a cada uno de los pisos del bloque, con la idea de no tener que realizar nunca más otro cableado. Esto está bien si todo el mundo se mueve por un sistema analógico, pero, desde el punto de vista del ADSL, cada pulgada lineal de esas ramas cuenta como distancia desde la subestación, lo que disminuye la fuerza de la señal.
Afortunadamente, el problema tenía una solución rápida y fácil. Todas las ramas laterales de la línea se desconectaron y se agregó una nota que decía "NO VOLVER A CONECTAR. PARTE DE ADSL EN USO". ¡Ta chan! Una distancia de sólo 300 metros, una señal mucho más fuerte y, lo más importante, ninguna pérdida en el transporte.
Moraleja: no suponga que un problema de conexión es esotérico o incluso viene provocado por el software. A veces, es sólo cuestión del cable. No olvide nunca que los chicos de la empresa telefónica comprueben la intensidad de la señal ADSL real en el momento de la instalación, incluso aunque estén seguros de que no es necesario; nunca sabe qué más puede haber conectado, esperando a confundirle posteriormente. Y no confíe en el tema de la distancia a la subestación. No tiene la menor idea de por dónde discurren los cables, ni tampoco ellos. Descúbralo. Ellos tienen las herramientas; ellos tienen la tecnología: impúlselos a utilizarlas. Se alegrará de ello. Especialmente cuando los televendedores encuentren su número de ADSL.

R'ykandar Korra'ti, administradora de correo para una pequeña cooperativa de ISP, vive cerca de Seattle con su compañera Anna. Habiendo administrado anteriormente productos de correo en Microsoft, ahora está centrada en un campo tan esotérico que no tiene realmente un nombre, en un centro de posgrado. Los posibles consejeros académicos pueden ponerse en contacto con ella en darako@murkworks.net.


 Confidencial de Windows: Una bendici&#243;n &quot;mixta&quot;
Confidencial de Windows
Una bendición "mixta"
Raymond Chen

Al insertar un CD o DVD, el shell "husmea" el disco para determinar qué tipo de contenido reside en él. Esta determinación indica al shell qué acción de reproducción automática debe realizar. Los detalles precisos de cómo se realiza el examen no se revelan, porque son heurísticos que pueden cambiar en el futuro si se encuentra un algoritmo mejor.
La documentación formal del algoritmo lo haría contractual, con lo cual se impediría que el algoritmo se modificara en lanzamientos posteriores. Oficialmente, por lo tanto, los detalles del algoritmo no se especifican.
Si nunca ha escrito documentación para un SDK, puede no haberse dado cuenta de que la documentación lleva al contrato. Una vez que haga constar que algo se comporta de una cierta manera, no podrá cambiarlo. Si lo hace, las personas que dependían de ese comportamiento dirán "Oye, eso no es lo que la documentación dice. Ha cambiado las reglas una vez que el juego ha empezado".
Aparte de esta advertencia, aquí tiene una descripción increíblemente simplificada y rápida de cómo Windows® XP Service Pack 2 (SP2) clasifica el contenido de CD y DVD de datos que carecen de un archivo autorun.inf. Las versiones y los service packs futuros de Windows pueden comportarse de forma distinta. Digo "increíblemente simplificada" porque el algoritmo real es una tabla de decisiones de 61 pasos que tiene en cuenta todos los tipos de información como, por ejemplo, si la aplicación en primer plano respondió a la notificación "Query cancel autoplay" (Reproducción automática de cancelación de consulta), si hay un programa de pantalla completa en ejecución e incluso si el equipo es un equipo portátil acoplado o desacoplado recientemente. No obstante, sólo voy a tratar el paso del examen de contenido.

Primero, el shell comprueba si el usuario especificó "No realizar ninguna acción" como acción para todos los tipos de contenido. Si ése es el caso, entonces no se produce ningún examen. La decisión es simplemente "No realizar ninguna acción".
Aparte de eso, el shell tiene algo hacer. Consulta cada archivo del disco (hasta cuatro directorios de profundidad) y los pone en una de las siguientes categorías según el tipo percibido: imagen, música o película.
Los archivos que no se ajustan a una de estas categorías no se tienen en cuenta. Si sólo hay una categoría representada entre todos los archivos que se comprobaron (por ejemplo, todos los archivos del disco son archivos de música), esto establece el tipo de disco. Si hay más de una de estas tres categorías representada, entonces se considera que el disco es de contenido mixto.
Esto significa que la carátula de álbum del CD lleno de archivos de música hará que el CD sea tratado como de contenido mixto por Windows XP SP2. Éste es uno de esos aspectos que podrían probablemente modificarse. Pero supongamos que este algoritmo se modifica y decidimos que una imagen ocasional en un CD lleno de archivos MP3 no debe inclinar la balanza hacia el contenido mixto. Alguna empresa quizás tenga un CD con muchos archivos de audio y apenas unos pocos de imagen. La empresa confía, de hecho, en que el CD sea detectado como de contenido mixto. Pero cuando el algoritmo cambia, el CD se clasifica incorrectamente como de música. Entonces, esa empresa no estará conforme. ¿Pero quién es el culpable de este problema? ¿Puede ser la empresa la culpable de confiar en los detalles del algoritmo de examen? ¿O es Windows quien tiene la culpa ya que es responsable de cambiar el algoritmo?
Y quién lo iba a decir: en Windows™ Vista, el algoritmo ha cambiado, aunque sólo levemente. En Windows Vista, se realizan varias comprobaciones de antemano para evitar parte del algoritmo en el caso de determinados formatos de disco muy conocidos. Por ejemplo, si una carpeta DCIM está presente en la raíz del disco, se supone que está compuesta de imágenes digitales. Ahora, esperaremos a ver si alguien lo nota.

Raymond Chen, The Old New Thing (en inglés) y su libro del mismo nombre (Addison-Wesley, 2007) tratan de la historia de Windows y la programación Win32. Raymond se lo cuestiona todo.