 TechNet Magazine March 2008

TechNet Magazine March 2008

Cobertura especial: Windows Server 2008: Cambios del kernel de Windows Server 2008

Aproveche nuestro repaso detallado de los cambios clave en el kernel de Windows Server 2008, que mejoran la confiabilidad, el rendimiento y la escalabilidad. Averigüe cómo Windows Server 2008 hace un uso más eficaz de grupos de subprocesos, agiliza la recuperación de errores de hardware, mejora la virtualización con Hyper-V y mucho más.

Mark Russinovich Cobertura especial: Windows Server 2008: Novedades en Servicios de dominio de Active Directory

Windows Server 2008 presenta numerosas mejoras sustanciales en los Servicios de dominio de Active Directory. Observe, por ejemplo, cómo los controladores de dominio de sólo lectura y Windows Server Core mejoran la seguridad de su entorno, cómo el nuevo Administrador de servidores y la renovada función de copias de seguridad simplifican la administración y, por último, cómo las nuevas herramientas de auditoría ayudan a garantizar el cumplimiento.

Gil Kirkpatrick Cobertura especial: Windows Server 2008: Introducción a IIS 7.0

IIS 7.0 incluye numerosas características nuevas, demasiadas para incluirlas en un solo artículo. La versión nueva se basa en el diseño sólido y centrado en la seguridad de IIS 6.0, y ofrece mejoras que incrementan las capacidades de administración y extensibilidad de la plataforma. Aquí encontrará información general sobre los cambios más importantes en IIS 7.0.

Isaac Roybal Cobertura especial: Windows Server 2008: Acceso a red basado en directivas con Windows Server 2008

¿Cómo podemos ofrecer acceso a la red a los usuarios que lo necesitan sin sacrificar la seguridad? Vea cómo las nuevas tecnologías en Windows Server 2008, como el Firewall de Windows con seguridad avanzada y la protección de acceso a redes, permiten aplicar un enfoque basado en directivas para conseguir este objetivo. Ian Hameroff y Amith Krishnan 62 Configuración de funciones con el Administrador de servidores Un servidor DNS no tiene por qué ser un servidor de impresión. Una estrategia de Windows Server 2008 para mejorar la seguridad y la capacidad de administración consiste en simplificar las funciones de servidor de modo que pueda instalar fácilmente las herramientas y los servicios que necesita, nada más. Aquí tiene una introducción al uso del Administrador de servidores para configurar funciones y simplificar implementaciones.

Ian Hameroff and Amith Krishnan Cobertura especial: Windows Server 2008: Configuración de funciones con el Administrador de servidores

Un servidor DNS no tiene por qué ser un servidor de impresión. Una estrategia de Windows Server 2008 para mejorar la seguridad y la capacidad de administración consiste en simplificar las funciones de servidor de modo que pueda instalar fácilmente las herramientas y los servicios que necesita, nada más. Aquí tiene una introducción al uso del Administrador de servidores para configurar funciones y simplificar implementaciones.

Byron Hynes Cobertura especial: Windows Server 2008: Implementación de Windows Server 2008 con System Center

Solía ser el caso que los administradores de servidores instalaban Windows Server manualmente con el CD o el DVD y, después, empleaban horas en la configuración del servidor. Con el lanzamiento de System Center Configuration Manager 2007 y el nuevo Microsoft Deployment Toolkit, los administradores de servidores pueden usar las mismas herramientas que los administradores de escritorios han usado durante años para automatizar las implementaciones.

Tim Mintner Cobertura especial: Windows Server 2008: Auditoría y cumplimiento en Windows Server 2008

La auditoría de los cambios constituye ahora una responsabilidad fundamental para los departamentos de TI. Es una parte esencial de la comprensión y la administración de sistemas y datos en un entorno distribuido. Este artículo trata los desafíos comunes, los aspectos de cumplimiento y normativa, algunos conceptos básicos de auditoría y la creación de una estrategia de auditoría completa.

Rob Campbell and Joel Yoker Nota del editor: En dedicación a Windows Server 2008

Joshua Hoffman Cartas: Comentarios de los lectores

Cuadro de herramientas: Nuevos productos para profesionales de TI

Greg Steen Utility Spotlight: Certificación del logotipo de Windows Server

Para ayudar a los ISV y los clientes a evaluar la compatibilidad de aplicaciones, Microsoft creó el programa "Works with Windows Server 2008". Aquí examinamos las herramientas de prueba de compatibilidad gratuitas disponibles a través del programa que ayudan a garantizar que las aplicaciones proporcionarán una experiencia previsible.

Venkat Krishnamachari The Cable Guy: Migración de la intranet a IPv6 con ISATAP

Cómo prepararse para la migración a IPv6 The Cable Guy explica cómo puede usar la tecnología de transición de IPv6 para obtener conectividad IPv6 y migrar a una intranet con capacidad para IPv6.

Joseph Davies Windows PowerShell: Informe de progreso

Para los usuarios con problemas de concentración, y también para aquellos que no los tienen, es buena idea proporcionar comentarios de estado en los scripts. Aquí tiene todo lo que necesita saber para proporcionar el estado en Windows PowerShell.

Don Jones ¡Hola, encargados del scripting!: Nuestros juegos de shell favoritos

Los chicos del scripting demuestran cómo cambiar la fecha de última modificación de un archivo con algo de scripting y el objeto Shell.

The Microsoft Scripting Guys Vigilancia de seguridad: Uso de SCW en Windows Server 2008

Ya ha oído hablar de la nueva herramienta Administrador de servidores en Windows Server 2008. Pero, además, el Asistente para configuración de seguridad (SCW) todavía está disponible. Averigüe por qué le interesa usar SCW.

Jesper M. Johansson Archivos del escritorio: No se puede ser demasiado rico ni demasiado delgado

Los clientes ligeros van y vienen, pero siempre parece haber algún escenario que se puede beneficiar de ellos. Hoy en día, se usan en quioscos y en entornos en los cuales la exploración web es el único factor necesario. Presentamos una introducción acerca de cómo puede replanear el hardware antiguo con una aplicación cliente para ahorrarse algún dinero.

Wes Miller Notas de campo: Preparación para TI 2.0

Veamos la importancia de aprender del pasado con el fin de resolver los desafíos que el futuro presenta para TI.

Romi Mahajan Confidencial de Windows: Así se convirtieron en RC las versiones beta

Raymond Chen trata la intrigante historia de cómo han cambiado las convenciones de nomenclatura para versiones no finales. Y suplica a las compañías que se tomen las pruebas beta más en serio.

Raymond Chen


 Cobertura especial: Windows Server 2008: Cambios del kernel de Windows Server 2008
Cobertura especial: Windows Server 2008 Mark Russinovich

Cambios del kernel de Windows Server 2008
Resumen:
  • Administración de la memoria y SMB 2.0
  • Recuperación automática de NTFS, arquitectura de errores de hardware de Windows y el comprobador de controladores
  • Escalabilidad con puertos de terminación de E/S, grupos de subprocesos y NUMA
  • Virtualización Hyper-V

Windows Server 2008 es la última versión de la plataforma de servidor de Microsoft, e incluye cambios al nivel de sistema que abarcan todas las áreas funcionales del sistema operativo, desde la administración de la memoria
hasta la programación de subprocesos, desde las funciones de red hasta la seguridad, por nombrar algunas.
Debido a que Windows Server® 2008 comparte el kernel de Windows Vista® SP1, incluye muchas de las mejoras que vimos en mis artículos anteriores de TechNet Magazine: "Dentro del kernel de Windows Vista", partes 1-3 (febrero, marzo y abril de 2007) y "Estudio del Control de cuentas de usuario de Windows Vista" (junio de 2007). Sólo algunas de las características que describí en estos artículos se centran exclusivamente en el cliente y no se incluyen en Windows Server 2008, como SuperFetch, ReadyBoost, ReadyDrive, ReadyBoot y el Servicio Programador de aplicaciones multimedia (MMCSS).
En lugar de repetir el alcance de los cambios importantes del kernel introducidos en Windows Vista que se encuentran también en Windows Server 2008, como el establecimiento de prioridades de E/S, la nueva arquitectura de arranque, BitLockerTM, la integridad del código y los niveles obligatorios de integridad, me voy a centrar en los cambios clave que no cubrí en dichos artículos, incluidos los relacionados con la confiabilidad, el rendimiento, la escalabilidad y la nueva tecnología de virtualización de equipos de hipervisor de Microsoft, Hyper-VTM.
Además, como en los artículos anteriores, el ámbito de este queda restringido al kernel del sistema operativo, Ntoskrnl.exe, y a los componentes del sistema asociados estrechamente. No cubre los cambios en la instalación (WIM, o formato Windows® Imaging, y el Modelo de servicio basado en componentes), la administración (mejoras en Active Directory® y la directiva de grupo), diagnósticos y supervisión generales (Infraestructura de diagnóstico de Windows), funciones de red básicas (el nuevo firewall y la implementación TCP/IP), Server Core ni las funciones de servidor, por ejemplo.
Uso de sistemas multiprocesador
Uno de los cambios de bajo nivel en el sistema es que Windows Server 2008 sólo incluye una versión del kernel diseñada para funcionar en sistemas multiprocesador. En el pasado, Windows usaba una versión específica a monoprocesadores en equipos con una sola CPU porque esta versión podía lograr un rendimiento ligeramente superior al omitir el código de sincronización necesario sólo en entornos de multiprocesador. Con la aceleración del hardware, las ventajas de rendimiento de las optimizaciones se vuelven insignificantes, y la mayoría de los sistemas de servidor actuales incluyen más de un procesador, lo que convierte en innecesaria una versión monoprocesadora.
La Figura 1 muestra las variantes del kernel de Windows Server 2008, donde la versión usada en un sistema depende de si es la versión depurada (comprobada) o la versión a la venta del sistema operativo, si la instalación es de 32 bits o de 64 bits (Itanium, Intel 64 o AMD64) y, si es una instalación de 32 bits, si el sistema tiene más de 4 GB de memoria física o es compatible con la Prevención de ejecución de datos (DEP). Windows Server 2008 es también el último sistema operativo de Windows Server que ofrecerá una versión de 32 bits.
Figure 1 Variantes del kernel de Windows Server 2008 (Close Figure 1)

Kernel | 32 bits | 64 bits
Multiprocesador | Sí | Sí
Multiprocesador comprobado | Sí | Sí
Multiprocesador con extensión de dirección física (PAE) | Sí | No
Multiprocesador PAE comprobado | Sí | No
Cada lanzamiento de Windows Server se centra en mejorar el rendimiento de escenarios de servidor clave, como el servicio de archivos, E/S de red y la administración de memoria. Además, Windows Server 2008 tiene varios cambios y características nuevas que permiten a Windows aprovechar las arquitecturas de hardware nuevas, adaptarse a redes de alta latencia y eliminar los cuellos de botella que limitaban el rendimiento en versiones anteriores de Windows. Esta sección revisa las mejoras en el administrador de memoria, el sistema de E/S y la introducción del nuevo Network File System, SMB 2.0.

Administración de memoria
Experimento: Detección de E/S de disco grandes
Puede usar una herramienta de supervisión del sistema de archivos como el monitor de procesos de Sysinternals de TechNet (technet.microsoft.com/sysinternals/bb896645.aspx) para buscar operaciones de E/S de archivo grandes en un sistema con Windows Server 2008.
Hay varias maneras de generar E/S grandes. Si tiene un segundo sistema que ejecuta Windows Vista Service Pack 1 o Windows Server 2008, puede ejecutar el monitor de procesos en el servidor y supervisar las copias de archivo en el segundo sistema. Generalmente, también es posible generar E/S de archivo de paginación grandes con la ejecución de un programa que hace un uso intensivo de la memoria y lleva al administrador de memoria a escribir páginas en el archivo de paginación.
La Figura A muestra el monitor de procesos después de ejecutar un programa que hace un uso intensivo de la memoria en un sistema con Windows XP, con la opción Habilitar resultados avanzados activada en el menú de opciones del monitor de procesos y un filtro establecido para mostrar sólo las escrituras en el archivo de paginación, pagefile.sys. La columna Detalle muestra que las escrituras son de un tamaño de 64 KB.
Figura A
Al ejecutar los mismos pasos en Windows Server 2008, es muy probable que vea algo semejante a lo que muestra la Figura B, donde la mayoría de las escrituras son de aproximadamente 1 MB.
Figura B

El administrador de memoria incluye varias mejoras de rendimiento en Windows Server 2008. Por ejemplo, produce menos E/S de disco a un tamaño superior que en Windows Server 2003 al capturar datos del archivo de paginación o realizar E/S de lectura anticipada en archivos asignados. Las E/S de archivo más grandes son el resultado de cambios en el sistema de E/S que eliminan el límite de tamaño de E/S de 64 KB presente desde la primera versión de Windows NT®.
También es importante tener en cuenta que las lecturas de datos para lecturas anticipadas (lecturas especulativas) de archivos asignados por el administrador de caché suelen ser dos veces más grandes en Windows Server 2008 que en Windows Server 2003 y van directamente a la lista de elementos en espera (la memoria caché de datos y el código del sistema). Este comportamiento se da en lugar de requerir al administrador de caché que asigne memoria virtual y lea los datos en el espacio de trabajo del sistema (memoria asignada al sistema por el administrador de memoria), lo que podría provocar que otros datos o código en uso queden expulsados innecesariamente del espacio de trabajo.
El administrador de memoria realiza también E/S más grandes al escribir datos en el archivo de paginación. Mientras que Windows Server 2003 a menudo realizaba escrituras incluso inferiores a 64 KB, en Windows Server 2008, el administrador de memoria produce comúnmente escrituras de 1 MB.
Además de mejorar el rendimiento al reducir el número de escrituras en el archivo de paginación, las escrituras más grandes reducen la fragmentación dentro del archivo. Esto, a su vez, causa una reducción en el número de lecturas y búsquedas en disco que se requieren para leer varias páginas, ya que, la mayoría de las veces, no se encuentran en ubicaciones adyacentes.
El administrador de memoria trata también de escribir otras páginas modificadas que están cerca de la que se está escribiendo en el espacio de direcciones del proceso propietario, y toma como objetivo el área del archivo de paginación donde ya residen otras páginas próximas. Esto minimiza también la fragmentación y puede mejorar el rendimiento porque las páginas que podrían acabar por escribirse en el archivo de paginación ya se han escrito. Además, reduce el número de lecturas de paginación requeridas para extraer un intervalo de páginas de proceso adyacentes. Vea la barra lateral "Experimento: Detección de E/S de disco grandes" para obtener más información sobre el uso de E/S grandes por parte del administrador de memoria.

SMB 2.0
El protocolo de sistema de archivos remoto SMB (Bloque de mensajes del servidor), también conocido como Sistema de archivos de Internet común (CIFS), ha sido la base del servicio de archivos de Windows desde la introducción de la funcionalidad de servicio de archivos en Windows. Durante los últimos años, las limitaciones de diseño de SMB han restringido el rendimiento del servicio de archivos de Windows y la capacidad de aprovechar características nuevas del sistema de archivos local. Por ejemplo, el tamaño máximo de búfer que se puede transmitir en un solo mensaje es aproximadamente de 60 KB, y SMB 1.0 no reconocía los vínculos simbólicos NTFS del lado cliente incluidos en Windows Vista y Windows Server 2008.
Windows Vista y Windows Server 2008 introducen SMB 2.0, que es un nuevo protocolo de servicio de archivos remoto que Windows usa cuando el cliente y el servidor lo permiten. Además de procesar correctamente los vínculos simbólicos del lado cliente y otras mejoras de NTFS, SMB 2.0 recurre al procesamiento por lotes para minimizar el número de mensajes que intercambian el cliente y el servidor. El procesamiento por lotes puede mejorar la capacidad de proceso en redes de alta latencia, como redes de área ancha (WAN), porque permite que haya más datos en movimiento al mismo tiempo.
Mientras que SMB 1.0 producía E/S para un solo archivo secuencialmente, SMB 2.0 hace uso de canalizaciones de E/S con el fin de producir varias E/S simultáneas para el mismo archivo. Mide la cantidad de memoria de servidor usada por un cliente para E/S pendientes con el fin de determinar el alcance necesario de las canalizaciones.
Como resultado de los cambios en el sistema de E/S y el administrador de memoria de E/S de Windows, el ajuste automático de la ventana de recepción de TCP/IP y las mejoras en el motor de copia de archivos, SMB 2.0 ofrece mejoras de capacidad de proceso considerables y una reducción en tiempos de copia de archivos para transferencias grandes. Como ambos sistemas operativos implementan SMB 2.0, la implantación de servidores de archivos Windows Server 2008 con clientes de Windows Vista posibilita el uso de SMB 2.0 y la realización de estas ventajas de rendimiento.

Confiabilidad con la recuperación automática de NTFS
La confiabilidad es un atributo clave de servidor, y Windows Server 2008 proporciona varias mejoras que ayudan a los administradores a mantener el funcionamiento óptimo de su servidor, entre ellas, la reparación en línea de la coherencia de NTFS, una infraestructura nueva para la generación de informes de errores de hardware y extensiones del comprobador de controladores.
Con los dispositivos de almacenamiento de varios terabytes actuales, la desconexión de un volumen para comprobar la coherencia puede tener como resultado una interrupción del servicio de varias horas. Con el reconocimiento de que muchos daños en disco se encuentran en un solo archivo o en una parte de los metadatos, Windows Server 2008 implementa una característica nueva de recuperación automática de NTFS para reparar daños mientras el volumen permanece en línea.
Cuando NTFS detecta los daños, impide el acceso a los archivos dañados y crea un subproceso de trabajo del sistema que ejecuta correcciones de tipo Chkdsk en las estructuras de datos dañadas, y permite el acceso a los archivos reparados al terminar. El acceso a otros archivos continúa normalmente durante esta operación, lo que minimiza la interrupción de servicio.

Infraestructura WHEA
La Arquitectura de errores de hardware de Windows (WHEA) incluida en Windows Server 2008 promete simplificar la administración de errores de hardware y habilitar la respuesta proactiva a errores no irrecuperables. A menudo, los servidores tienen severas garantías de tiempo activo, de forma que la identificación y la solución de errores de manera oportuna en dichos sistemas es crítica.
El análisis de bloqueos enviados a Microsoft a través del Análisis de bloqueos en línea (OCA) muestra que aproximadamente un diez por ciento de los bloqueos de sistema operativo vienen ocasionados por errores de hardware, pero determinar la causa raíz de estos bloqueos ha sido difícil o imposible porque la información sobre los errores proporcionada por el hardware para la captura durante los bloqueos es insuficiente. Además, antes de Windows Server 2008, Windows no ofrecía compatibilidad integrada con la supervisión del estado de los dispositivos ni implementaba la notificación o la corrección de errores inminentes. La razón es que los dispositivos de hardware no usan un formato de error común y no ofrecen compatibilidad con software de administración de errores.
WHEA ofrece un mecanismo unificado de detección del origen de errores y generación de informes asociados para dispositivos de plataforma, incluidos procesadores, memoria, cachés y buses como PCI y PCI Express. Esto se consigue mediante la implementación de la arquitectura mostrada en la Figura 2, donde el núcleo es una API del kernel a la que llaman los orígenes de errores para informar de los errores. La API requiere que todos los errores tengan un formato determinado, y registra los errores mediante el Seguimiento de eventos para Windows (ETW). Los errores irrecuperables se registran después del reinicio.
Figura 2 Infraestructura WHEA para la generación de informes de errores
Figura 2 Infraestructura WHEA para la generación de informes de errores
ETW se introdujo en Windows 2000, y el uso de WHEA por parte de ETW permite a los fabricantes de hardware y los proveedores de software desarrollar aplicaciones de administración de diagnósticos de dispositivos que consumen eventos de WHEA. Si un evento es tan grave como para provocar el bloqueo del sistema, WHEA garantiza que el registro del error irrecuperable queda almacenado en el archivo de volcado del bloqueo para que los administradores puedan determinar la causa raíz del bloqueo.
Otra pieza clave de WHEA es el Controlador de errores de hardware específicos de la plataforma (PSHED) incluido en %Systemroot%\System32\Pshed.dll. El kernel se conecta a PSHED, e interacciona con el hardware de plataforma y firmware, de forma que, esencialmente, sirve de nivel de traducción entre las notificaciones de error y la API de WHEA para la generación de informes de errores. Hay un PSHED suministrado por Microsoft para cada arquitectura de plataforma (x86, x64, Itanium), y PSHED presenta un modelo de complemento para que los fabricantes y los proveedores de hardware puedan omitir los comportamientos predeterminados con los específicos para su plataforma.
Finalmente, los componentes del sistema que interactúan con otros orígenes de errores, incluidos controladores de dispositivos, la capa de abstracción de hardware (HAL) y el kernel, pueden implementar controladores de errores de hardware de bajo nivel (LLHEL) que, inicialmente, se ocupan de las condiciones de error. El cometido de un LLHEL es extraer información de errores del dispositivo, notificar a PSHED para que reúna información adicional de errores de plataforma y, después, llamar a la API de WHEA del kernel para la generación de informes de errores.

Comprobador de controladores
El comprobador de controladores, una herramienta eficaz para localizar controladores de dispositivos con errores y hardware con problemas, se ha incluido en cada copia de Windows a partir de Windows 2000. Los administradores configuran comúnmente el comprobador de controladores (%Systemroot%\System32\Verifier.exe) para supervisar en profundidad el comportamiento de controladores de dispositivos que parecen causar bloqueos de sistema. El comprobador de controladores filtra operaciones no válidas de controlador para que los archivos de volcado de los bloqueos señalen directamente a la parte culpable.
Un inconveniente de implementaciones anteriores del comprobador de controladores es que la mayoría de los cambios de configuración requerían el reinicio del sistema, algo que es obviamente indeseable en un servidor de producción. La implementación del comprobador de controladores en Windows Server 2008 mejora este proceso al eliminar el requisito de reinicio para las comprobaciones más útiles, lo que permite solucionar problemas en un servidor sin tener que reiniciarlo.
Además, el comprobador de controladores introduce tres comprobaciones nuevas, como muestra la Figura 3. Las comprobaciones de seguridad garantizan que los controladores de dispositivos establezcan permisos seguros en los objetos que usan para interactuar con aplicaciones. Al exigir las solicitudes de E/S pendientes, se comprueba la resistencia de un controlador ante operaciones asincrónicas de E/S que se completan inmediatamente en lugar de hacerlo tras una demora. Y otras comprobaciones varias se ocupan de buscar controladores que liberan incorrectamente recursos en uso, hacen un uso inapropiado de las API de registro del Instrumental de administración de Windows (WMI) y permiten la pérdida de identificadores de recursos.
Figura 3 El comprobador de controladores con opciones activadas de Windows Server 2008
Figura 3 El comprobador de controladores con opciones activadas de Windows Server 2008

Escalabilidad
La escalabilidad se refiere a la capacidad de un sistema operativo o una aplicación para utilizar de forma eficaz varios procesadores y grandes cantidades de memoria. Cada versión de Windows mejora la escalabilidad al minimizar o eliminar el uso de bloqueos que reducen el paralelismo en multiprocesadores, y Windows Server 2008 no es una excepción a esta tendencia.
Una mejora relativamente pequeña pero importante está en el código que ejecuta la expiración de temporizadores, que ya no adquiere el bloqueo de distribuidor, un bloqueo de programador en todo el sistema utilizado por todas las operaciones de sincronización de bajo nivel. La reducción resultante en la carga de sincronización de CPU permite a sistemas de Terminal Server de Windows Server 2008 admitir un 30 por ciento de usuarios simultáneos más que Windows Server 2003.
Otras mejoras de escalabilidad en Windows Server 2008 incluyen mejoras de puertos de terminación, una implementación nueva de grupos de subprocesos, un uso más eficiente de hardware de acceso a memoria no uniforme (NUMA) y la partición dinámica de sistemas.

Administración mejorada de puertos de terminación de E/S
La mayoría de las aplicaciones de servidor escalables de Windows, incluidas IIS, SQL Server® y Exchange Server, dependen de una API de sincronización de Windows denominada puerto de terminación para minimizar el cambio de subproceso de ejecución al ejecutar operaciones de E/S. Esto se consigue al asociar primero las notificaciones de llegadas de solicitud nuevas, como conexiones de cliente de servidor web, con un puerto de terminación y dedicar un grupo de subprocesos a la espera de las notificaciones. Cuando llega una solicitud, Windows programa un subproceso que, a continuación, suele ejecutar otras operaciones de E/S, como leer una página web del disco y enviarla al cliente para completar la solicitud.
Para que el mismo subproceso pueda volver al estado de espera de solicitudes de cliente adicionales tan rápidamente como sea posible, el subproceso produce E/S asincrónicamente y asocia terminaciones de E/S con el puerto de terminación. Seguidamente, el subproceso vuelve a la espera en el puerto de terminación, que programará el subproceso cuando llegue una solicitud nueva o se complete una de las E/S. De este modo, el mismo subproceso permanece activo en una CPU: alterna entre el procesamiento de solicitudes de cliente y la espera en el puerto de terminación.
Un inconveniente de la implementación de puertos de terminación en versiones previas de Windows es que, cuando se completaba una E/S, el sistema de E/S hacía que el subproceso que producía el E/S realizara inmediatamente un pequeño bit de procesamiento de terminación, independientemente de cualquier otra cosa que estuviera haciendo. Si había otros subprocesos activos, a menudo esto provocaba que el programador llevara a cabo el cambio de un subproceso activo y el cambio de contexto al emisor.
Windows Server 2008 evita estos cambios de contexto al aplazar el procesamiento de terminación al subproceso siguiente para esperar en el puerto de terminación asociado con la E/S. Así, aunque un subproceso diferente sea el siguiente para pasar a la espera en el puerto de terminación, realizará el procesamiento de terminación antes de ejecutar otro código, y el programador no necesita cambiar al subproceso emisor. Esta reducción de cambios de contexto puede mejorar dramáticamente la escalabilidad de aplicaciones de servidor de uso intensivo.

Grupos de subprocesos más eficientes
La escritura de aplicaciones que aprovechen varias CPU puede ser difícil, así que Windows XP introdujo grupos de subproceso de trabajo, una infraestructura y API asociadas que abstraen los detalles de ejecución de unidades pequeñas de trabajo en las CPU. Una aplicación especifica los elementos de trabajo a la API de grupos de subprocesos que, seguidamente, los ejecuta en uno de varios subprocesos que crea y administra para cada CPU en el sistema.
El objetivo del grupo de subprocesos es minimizar los cambios de contexto al usar los mismos subprocesos para ejecutar varios elementos de trabajo en sucesión. Cuando esto no resulta posible porque uno de los subprocesos está ocupado con otro trabajo, ejecuta el elemento de trabajo mediante un subproceso diferente en una CPU distinta.
La implementación de grupos de subprocesos en Windows Server 2008 hace un uso más eficaz de CPU indirectamente porque se beneficia de las mejoras en puertos de terminación y directamente al optimizar la administración de subprocesos de forma que los subprocesos de trabajo van y vienen dinámicamente cuando se necesita que se ocupen de las cargas de trabajo de las aplicaciones. Es más, el núcleo de la infraestructura ha pasado al modo de kernel, lo que reduce al mínimo el número de llamadas de sistema por parte de las aplicaciones que usan la API. Finalmente, la API nueva permite a las aplicaciones realizar ciertas operaciones de forma más sencilla, por ejemplo, anular las unidades de trabajo en cola durante el cierre de las aplicaciones.

Optimizaciones de NUMA
Windows Server 2003 introdujo optimizaciones para equipos NUMA en el programador de subprocesos y el administrador de memoria, pero Windows Server 2008 agrega optimizaciones de NUMA en el administrador de E/S y amplía las optimizaciones de NUMA del administrador de memoria.
Los sistemas NUMA suelen ser sistemas multiprocesador en los que la memoria tiene una latencia diferente según el procesador que obtiene acceso a ella (consulte la Figura 4). La memoria se divide en nodos, donde las latencias entre las CPU y los nodos pueden variar, y cada CPU se considera parte de un nodo al que tiene acceso rápido de forma preferente.
Figura 4 Ejemplo de sistema NUMA
Figura 4 Ejemplo de sistema NUMA
Los sistemas NUMA, especialmente aquellos con más de ocho CPU, a menudo son más eficaces en cuanto a rendimiento y rentabilidad que los sistemas de acceso uniforme a la memoria. Un sistema de acceso uniforme a la memoria debe distribuir memoria equitativamente a todas las CPU, mientras que un sistema NUMA puede implementar interconexiones de alta velocidad para memoria directamente conectada a una CPU, y conexiones más económicas de alta latencia para CPU y memoria con mayor separación.
Para escalar de forma eficaz en un sistema NUMA, el sistema operativo o la aplicación deben reconocer la topología de nodos para que el procesamiento se ejecute cerca de la memoria que contiene los datos y el código del procesamiento. Por ejemplo, el programador de Windows asigna a cada subproceso un "procesador ideal", que es la CPU en la que el programador intenta siempre ejecutar el subproceso. Así, es más probable que los datos que el subproceso coloca en la memoria caché de la CPU estarán disponibles para el subproceso cada vez que se ejecuta.
En Windows Server 2003, el programador amplía este concepto al considerar el nodo que contiene el procesador ideal como nodo ideal del subproceso, y trata de programar el subproceso de otra CPU en el nodo ideal cuando el procesador ideal está ocupado con la ejecución de un subproceso diferente. El administrador de memoria de Windows Server 2003 acabó también por ofrecer compatibilidad con NUMA y, siempre que es posible, dirige las asignaciones de memoria del subproceso a la memoria del nodo en que se ejecuta el subproceso.
En Windows Server 2008, el administrador de memoria divide los búferes de memoria no paginados del kernel (memoria usada por el kernel y los controladores de dispositivos para almacenar datos que permanecen en RAM) entre los nodos para que las asignaciones provengan de la memoria en el nodo en que se origina la asignación. Las entradas de la tabla de páginas del sistema (PTE) se asignan desde el nodo en que se origina la asignación, si la asignación requiere una tabla de páginas nueva, en lugar de asignarse desde cualquier nodo, como ocurre en Windows Server 2003.
En Windows Server 2003, cuando un subproceso realiza una asignación de memoria, el administrador de memoria preferiría el nodo en que se ejecuta el subproceso en el momento de la asignación. Si el subproceso se programó momentáneamente en un nodo no ideal, cualquier asignación realizada durante este tiempo vendría del nodo no ideal. Así, cuando el subproceso se ejecuta finalmente en su nodo ideal, no estará tan próximo a los datos o al código almacenados en la memoria asignada.
Para resolver esta situación, el administrador de memoria de Windows Server 2008 prefiere el nodo ideal de los subprocesos para todas las asignaciones de un subproceso, incluso cuando el subproceso se ejecuta cerca de un nodo diferente. El administrador de memoria también entiende automáticamente las latencias entre procesadores y nodos, de forma que, si el nodo ideal no tiene memoria disponible, pasa a comprobar el nodo más cercano al nodo ideal. Además, el administrador de memoria migra páginas en su lista de elementos en espera al nodo ideal de un subproceso cuando el subproceso hace referencia al código o a los datos.
Las aplicaciones que desean controlar la localidad de sus asignaciones puede usar nuevas API de memoria de NUMA con el fin de especificar el nodo preferido para asignaciones de memoria, vistas de asignación de archivos y objetos de asignación de archivos. Para asignaciones relacionadas con asignaciones de archivos, el administrador de memoria comprueba si la operación de asignación especifica un nodo. Seguidamente, comprueba si el objeto de asignación de archivos especifica uno y, finalmente, acude al nodo ideal del subproceso si es necesario.
Antes de Windows Server 2008, la interrupción y la llamada a procedimiento diferida (DPC) asociada para una E/S de almacenamiento o de red podían ejecutarse en cualquier CPU, incluidas aquellas de un nodo diferente a aquel en que se inició la E/S, lo que posiblemente hacía que los datos leídos o escritos en la operación de E/S se encontrasen en la memoria de un nodo diferente al nodo que ofrece acceso a los datos.
Para evitar esto, el sistema de E/S de Windows Server 2008 dirige la ejecución de DPC a una CPU en el nodo que inició la E/S, y los sistemas que tienen dispositivos compatibles con el bus PCI MSI-X (una extensión al estándar MSI) pueden localizar aún más la terminación de E/S al usar controladores de dispositivos que aprovechan las API de Windows Server 2008 para dirigir una interrupción de E/S al procesador que inició la E/S.

Partición dinámica
Una de las maneras en que un sistema puede ser más escalable es ofrecer compatibilidad con la partición dinámica de recursos de hardware, como CPU y memoria. Esta misma compatibilidad puede incrementar también la disponibilidad del sistema cuando los recursos se pueden reemplazar sin requerir el reinicio.
Windows Server 2003 posibilitaba la ampliación de memoria en caliente, lo que permitía a servidores con compatibilidad de memoria dinámica usar RAM al tiempo que el administrador agrega este tipo de memoria. Windows Server 2008 amplía la compatibilidad con memoria dinámica al permitir el reemplazo de memoria.
La memoria RAM con mayor dependencia de correcciones ECC presenta el riesgo de que podría dejar de funcionar por completo, así que, en un servidor que admite el reemplazo en caliente, Windows Server 2008 puede migrar datos transparentemente de los bancos de memoria con errores a bancos de reemplazo. Para ello, primero migra los datos bajo el control del sistema operativo; luego, apaga de forma eficaz los dispositivos de hardware al colocarlos en un estado de baja potencia, migra el resto de los datos de la memoria y vuelve a activar los dispositivos para reanudar el funcionamiento normal.
Windows Server 2008 también permite agregar y reemplazar procesadores en caliente. Para un reemplazo en caliente, el hardware debe ser compatible con el concepto de CPU de reserva, que se pueden colocar en línea o agregar dinámicamente cuando una CPU existente genera indicaciones de errores, algo que actualmente sólo es posible en sistemas avanzados. El programador de Windows Server 2008 reduce la actividad en la CPU con errores y migra el trabajo a la unidad de reemplazo. Así, se puede quitar la CPU con errores para reemplazarla por una unidad de reserva.
Como Windows Server 2008 permite agregar procesadores en caliente, el administrador puede actualizar las capacidades de procesamiento de un servidor sin tiempo de inactividad. Sin embargo, el programador y los sistemas de E/S sólo ofrecerán una CPU nueva como disponible a controladores de dispositivos y aplicaciones que solicitan la notificación de llegada de CPU a través de API nuevas porque algunas aplicaciones dan por hecho que el número de CPU está fijado para una sesión de arranque. Por ejemplo, una aplicación podría asignar una matriz de colas de trabajo correspondiente a cada CPU, donde un subproceso usa la cola asociada con la CPU en que se ejecuta. Si el programador colocase uno de los subprocesos de la aplicación en una CPU nueva, intentaría hacer referencia a una cola inexistente, lo que posiblemente causaría daños en los datos de la aplicación y el bloqueo de la misma.
Las aplicaciones basadas en servidor de Microsoft, como SQL Server y Exchange Server, permiten agregar CPU, al igual que varios procesos básicos de Windows, por ejemplo, el proceso del sistema, el administrador de sesiones (%SystemRoot%\System32\Smss.exe) y procesos de hospedaje de servicio genérico (%Systemroot%\System32\Svchost.exe). Otros procesos pueden solicitar también la notificación de la llegada de CPU nueva con una API de Windows. Cuando llega una CPU nueva, Windows envía una notificación sobre la llegada inminente a los controladores de dispositivos, inicia la CPU y, seguidamente, solicita a los controladores de dispositivos y las aplicaciones que usen las CPU para asignar estructuras de datos con el fin de realizar el seguimiento de la actividad en la CPU nueva, si fuera necesario.

Virtualización de equipos
Antes de Windows Server 2008, los productos de virtualización de Microsoft, incluido Virtual Server 2005, se implementaban mediante la virtualización hospedada, como muestra la Figura 5. En la virtualización hospedada, las máquinas virtuales vienen implementadas por un Monitor de equipo virtual (VMM) que se ejecuta junto al sistema operativo host, normalmente como controlador de dispositivos. El VMM depende de los controladores de dispositivos y la administración de recursos del sistema operativo host y, cuando el sistema operativo host lo programa para la ejecución, distribuye el tiempo de la CPU entre máquinas virtuales (VM) activas.
Figura 5 Virtualización hospedada de equipos
Figura 5 Virtualización hospedada de equipos
Hyper-V, anteriormente "Viridian", se implementa mediante la virtualización de hipervisor. El hipervisor tiene el control total de todos los recursos de hardware, e incluso el sistema operativo Windows Server 2008, que arranca el sistema y a través del cual el usuario controla las VM, se ejecuta esencialmente en una máquina virtual, como vemos en la Figura 6.
Figura 6 Arquitectura Hyper-V
Figura 6 Arquitectura Hyper-V
El hipervisor puede dividir el sistema en varias VM y trata la versión de arranque de Windows Server 2008 como partición maestra, o raíz, lo que le ofrece acceso directo a dispositivos de hardware, como el disco, los adaptadores de red y el procesador de gráficos. El hipervisor espera que la raíz realice la administración de la energía y responda a eventos Plug and Play de hardware. Intercepta E/S de dispositivos de hardware iniciadas en particiones secundarias y las dirige a la raíz, que usa controladores de dispositivos de Windows Server 2008 estándar para obtener acceso al hardware. De este modo, los servidores que ejecutan Hyper-V pueden sacar el máximo partido de la compatibilidad de Windows con dispositivos de hardware.
Al configurar Windows Server 2008 con la función de servidor Hyper-V, Windows establece la Base de datos de configuración de arranque (BCD) hypervisorimagelaunchtypeboot en auto y configura el controlador de dispositivos Hvboot.sys para entrar en funcionamiento con prontitud durante el proceso de arranque. Si la opción está configurada, Hvboot.sys prepara el sistema para la virtualización y carga %Systemroot%\System32\Hvax64.exe o %Systemroot%\System32\Hvix64.exe en la memoria, según si el sistema implementa extensiones de virtualización de CPU AMD-V o Intel VT, respectivamente.
Una vez que se ha cargado, el hipervisor usa las extensiones de virtualización para insertarse debajo de Windows Server 2008. Las aplicaciones de modo de usuario usan el nivel de privilegios Anillo 3 del procesador x64 y el código de modo kernel se ejecuta al nivel Anillo 0, así que el hipervisor opera al nivel de privilegios conceptual Anillo menos 1, ya que puede controlar el entorno de ejecución de código que se ejecuta al nivel Anillo 0.
Al usar la consola de administración de Hyper-V para crear o iniciar una partición secundaria, se comunica con el hipervisor que usa el controlador %Systemroot%\System32\Drivers\Winhv.sys, que, a su vez, usa la API de hiperllamadas documentada públicamente para dirigir el hipervisor a la creación de una partición nueva de tamaño de memoria física y características de ejecución particulares. El servicio de VM (%Systemroot%\System32\Vmms.exe) en la raíz se encarga de crear un proceso de trabajo de VM (%Systemroot%\System32\Vmwp.exe) para cada partición secundaria con el fin de administrar el estado de las mismas.
Una forma en que Windows mejora el rendimiento de sistemas operativos de VM secundarios es que ambos Windows Server 2008 y Windows Vista implementan mejoras de código en forma de secuencias de código que se activan sólo cuando el sistema operativo se ejecuta en un hipervisor que implementa la API de hiperllamadas de Microsoft. Al solicitar directamente los servicios del hipervisor, la VM secundaria evita la sobrecarga de código de virtualización que resultaría si el hipervisor tuviera que adivinar la intención del sistema operativo secundario.
Por ejemplo, un sistema operativo invitado que no implementa mejoras de código para bloqueos por bucle, que ejecutan sincronización de multiprocesadores de bajo nivel, giraría simplemente en un bucle cerrado en espera de un bloqueo por bucle enviado por otro procesador virtual. El giro podría ocupar a una de las CPU de hardware hasta la programación del segundo procesador virtual por parte del hipervisor. En sistemas operativos mejorados con código, el código de bloqueo por bucle indica al hipervisor el momento en que giraría normalmente a través de una hiperllamada. De este modo, el hipervisor puede programar inmediatamente otro procesador virtual y evitar el desperdicio de uso de CPU.
Otra manera en que Windows Server 2008 mejora el rendimiento de VM viene dada por la aceleración del acceso de VM a los dispositivos. El rendimiento queda mejorado al instalar una colección de componentes, denominados colectivamente "componentes de integración de VM", en el sistema operativo secundario.
Si ejecuta una VM sin instalar los componentes de integración, el sistema operativo secundario configurará los controladores de dispositivos de hardware para los dispositivos emulados que le presente el hipervisor. El hipervisor debe intervenir cuando un controlador de dispositivos intenta tocar un recurso de hardware para informar a la partición raíz, que realiza E/S de dispositivos mediante controladores de dispositivos estándar de Windows en nombre del sistema operativo de la VM secundaria. Debido a que una sola operación de E/S de alto nivel, como una lectura de disco, puede implicar muchos accesos discretos de hardware, podría causar muchas transiciones, llamadas intercepciones, en el hipervisor y en la partición raíz.
Windows Server 2008 minimiza las intercepciones con tres componentes: el controlador de bus de máquina virtual (%Systemroot%\System32\Drivers\Vmbus.sys), clientes de servicio virtual (VSC) y proveedores de servicios virtuales (VSP). Al instalar componentes de integración en una VM con un sistema operativo compatible, los VSC adquieren la función de controladores de dispositivos y usan los servicios del controlador Vmbus.sys en la VM secundaria para enviar solicitudes de E/S de alto nivel al controlador de bus de máquina virtual en la partición raíz a través de los servicios de hiperllamada y uso compartido de memoria del hipervisor. En la partición raíz, Vmbus.sys reenvía la solicitud al VSP correspondiente, que inicia las solicitudes de E/S estándar de Windows a través de los controladores de dispositivos de la raíz.
Como puede ver, Windows Server 2008 juega una función clave en la estrategia de virtualización de equipos de Microsoft con su introducción de la virtualización basada en hipervisor Hyper-V. Encontrará más información sobre esta y otras características en la próxima edición de mi libro, Microsoft Windows Internals, programado para la publicación más adelante este mismo año.

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


 Cobertura especial: Windows Server 2008: Novedades en Servicios de dominio de Active Directory
Cobertura especial: Windows Server 2008 Gil Kirkpatrick

Novedades en Servicios de dominio de Active Directory
Resumen:
  • Uso del nuevo Administrador de servidores con ADDS
  • Ejecución de servicios de dominio en Server Core
  • Controladores de dominio de sólo lectura
  • Cambios en contraseñas, copias de seguridad y auditorías

Con Windows 2000, Microsoft presentó al mundo Active Directory. El siguiente gran lanzamiento, Windows Server 2003, integró mejoras significativas en Active Directory, pero no
fueron cambios de excesiva relevancia. Actualmente, Active Directory® es un servicio de directorio muy consistente y eficaz. Aún así, el equipo de Active Directory ha integrado numerosas mejoras en la última versión para mejorar la seguridad y la capacidad de administración de este servicio de red principal.
Hacia el cambio de siglo, Active Directory se encargaba de autenticar al usuario cuando iniciaba la sesión, aplicaba directivas de grupo al usuario y su equipo, y le ayudaba a encontrar la impresora que estaba buscando. Apenas unos años más tarde, Microsoft lanzó al mercado una variante independiente denominada Active Directory Application Mode (ADAM).
Alrededor del año 2006, todo esto había cambiado. Active Directory ya no era una tecnología específica. En su lugar, se había convertido en un nombre de marca que identificaba un conjunto de servicios de fábrica para el control de identidades y acceso de Windows®. La Figura 1 ofrece un resumen rápido de lo que constituye la marca Active Directory.
Figure 1 Componentes de Active Directory (Close Figure 1)

Tecnología actual de Active Directory | Anteriormente denominada | Descripción
Servicios de dominio de Active Directory (ADDS) | Active Directory | Lo que solíamos llamar Active Directory. Ofrece autenticación basada en NTLM y Kerberos para usuarios y equipos de dominio, y administra unidades organizativas, usuarios, grupos, directivas de grupo y mucho más.
Active Directory Lightweight Directory Services (ADLDS) | Active Directory Application Mode (ADAM) | Servidor LDAP de alto rendimiento basado en el mismo código fuente usado por ADDS.
Servicios de certificados de Active Directory (ADCS) | Servicio de certificado | Ofrece autenticación segura mediante certificados X.509.
Active Directory Rights Management Services (ADRMS) | Servidor de Active Directory Rights Management Services | Protege los activos digitales, como documentos y correo electrónico, del uso no autorizado mediante la creación de archivos y contenedores protegidos con derechos.
Servicios de federación de Active Directory (ADFS) | Servicios de federación de Active Directory | Ofrece inicio de sesión único web y federación de identidades para servicios web compatibles con WS-*.
Así pues, para usar la terminología apropiada, este artículo abarca exactamente los Servicios de dominio. Pero, para ser sincero, se trata del mismo Active Directory que ha aprendido a adorar desde el año 2000.

Administrador de servidores en Windows Server 2008
Las primeras dos mejoras de Active Directory que me dispongo a explicar no son, realmente, cambios aplicados a los Servicios de dominio de Active Directory (ADDS), sino que se trata, más bien, de cambios en Windows que modificarán la manera en que administra Active Directory. La primera, el nuevo Administrador de servidores, se muestra nada más arrancar el servidor Windows Server® 2008 por primera vez. La segunda es la instalación Server Core, la cual explicaré en unos momentos.
Probablemente, el Administrador de servidores le será familiar gracias al Asistente para configurar su servidor de Windows Server 2003, que se muestra de manera predeterminada tras instalar Windows Server 2003. Esta versión, no obstante, no es muy útil para la administración diaria y todos los usuarios que conozco marcan la casilla "No mostrar esta página al iniciar sesión".
El Administrador de servidores en Windows Server 2008, por otro lado, es bastante útil (consulte el artículo de Byron Hynes en este número de TechNet Magazine para obtener información general sobre el Administrador de servidores). En primer lugar, tal como puede observar en la Figura 2, el Administrador de servidores es actualmente un complemento Microsoft® Management Console (MMC) y no una aplicación HTML de Microsoft (HTA). Esto significa que tiene una interfaz de usuario con características completas que es familiar y fácil de personalizar. El Administrador de servidores viene preparado para permitirle administrar la instalación de funciones de servidor (servicios principales como DNS, ADDS e IIS) y características (componentes de software, como Microsoft .NET Framework, cifrado de unidad BitLockerTM y Windows PowerShellTM). Más allá de la capacidad de agregar y quitar software, el Administrador de servidores proporciona también un único punto de contacto para ejecutar herramientas de diagnóstico (como el Visor de eventos y PerfMon) y las utilidades de configuración del sistema (como el Administrador de dispositivos y el Firewall de Windows). Si agrega los complementos MMC para Active Directory, por ejemplo, Usuarios y equipos, Dominios y confianzas, y Sitios y servicios, conseguirá una interfaz muy atractiva para realizar la administración diaria del controlador de dominio (DC) de Windows Server 2008.
Figura 2 Administrador de servidores en Windows Server 2008
Figura 2 Administrador de servidores en Windows Server 2008

Windows Server 2008 Server Core
Windows Server Core constituye una nueva opción de instalación de Windows que proporciona una versión reducida de Windows al contener únicamente los componentes necesarios para ejecutar ciertas funciones clave de servidor, incluidos los Servicios de dominio de Active Directory. La Figura 3 incluye las funciones compatibles con Server Core. Aunque una instalación de Server Core incluye una interfaz gráfica de usuario, no ejecuta el shell de escritorio de Windows y casi todas las herramientas gráficas para administrar y configurar Windows están ausentes (consulte la Figura 4). En su lugar, lo único que obtendrá será una ventana de comandos y un terrible desasosiego al no saber qué hacer a continuación. ¿Cómo cambio el nombre de equipo? ¿Cómo puedo configurar una dirección IP estática?
Figura 4 No hay mucho que ver en la interfaz de usuario de Server Core.
Figura 4 No hay mucho que ver en la interfaz de usuario de Server Core.
Los primeros minutos frente a una instalación de Server Core pueden ser muy frustrantes. Pero, tras emplear un poco de su tiempo en volverse a familiarizar con WMIC, NETSH y NETDOM, podrá llevar a cabo todas las tareas usuales de instalación y configuración sin ninguna dificultad. Y podrá continuar el uso de Regedit y el Bloc de notas para satisfacer sus necesidades de herramientas gráficas.
La ventaja principal de Server Core es que se quita gran parte del código que obtiene con una instalación de Windows normal, que probablemente no necesitará para todas estas funciones de servidor principal. Esto reduce la superficie de ataque potencial para el malware (una cosa buena) y reduce la cantidad de revisiones y reinicios que tendrá que realizar en sus DC (algo incluso más positivo). Además, consigue una superficie de disco mucho más pequeña y unos requisitos de disco duro reducidos, lo cual no supone una gran diferencia, pero sí puede ser de gran ayuda en entornos de servidor virtualizado.
¿Podría la ausencia de utilidades gráficas dificultar la administración de ADDS? No, en absoluto. Puede realizar casi todas sus tareas de administración de forma remota al ejecutar las utilidades en su estación de trabajo y conectar al controlador de dominio a través de la red. La gran mayoría de los DC acabarán por ejecutarse en instalaciones de Server Core.

Cambios de DCPROMO
El primer cambio que advertirá en ADDS es el nuevo DCPROMO. Funciona de la misma manera que DCPROMO en Windows Server 2003, pero se ha vuelto a escribir por completo con el objeto de facilitar su uso. Por ejemplo, ya no tiene que escribir sus credenciales de administrador de dominio; DCPROMO puede usar las credenciales de su inicio de sesión activo para aumentar el nivel del servidor. Tampoco es necesario escribir DCPROMO/ADV para obtener las opciones de Modo avanzado de DCPROMO, puesto que hay una casilla en el primer cuadro de diálogo de DCPROMO para habilitar estas opciones. El Modo avanzado permite también seleccionar el controlador de dominio existente desde el que realizar la replicación. Esto significa que es posible mantener la carga de replicación de DCPROMO fuera de sus DC de producción.
Al aumentar el nivel de un DC a un nuevo dominio o bosque, DCPROMO ofrece la opción de configurar el nivel funcional del bosque y el dominio, en lugar de hacerlo más tarde. También es posible especificar el sitio de Active Directory en el cual desea colocar el DC durante el proceso de aumento de nivel, lo cual es muy útil en el escenario desatendido de DCPROMO. DCPROMO sugerirá incluso el mejor sitio para la ubicación del DC según la dirección IP del DC.
El nuevo DCPROMO reúne también todas las opciones de configuración en una única página; en un mismo lugar, podrá elegir si el nuevo DC será un catálogo global (GC), un servidor DNS o un DC de sólo lectura. No tendrá que acudir a una ubicación confusa del complemento Sitios y servicios de Active Directory para marcar el DC como GC.
Pero quizás la característica más atractiva del nuevo DCPROMO es la capacidad de guardar toda la configuración de DCPROMO en un archivo de respuesta justo antes de que se inicie el proceso de aumento de nivel. Esto es mucho más sencillo, además de reducir las posibilidades de error, que improvisar el archivo de respuesta a mano. Puede usar el archivo de respuesta para realizar DCPROMO desatendidos en otros servidores. Y para aquellos fanáticos del scripting, se puede obtener acceso a todas las opciones de DCPROMO desde la línea de comandos.

Controladores de dominio de sólo lectura
En las primeras etapas de Active Directory, las empresas, con frecuencia, implementaban controladores de dominio en cada uno de los sitios en los que los usuarios iniciaban sesión. Por ejemplo, esto era bastante frecuente en los bancos, que colocaban un DC en cada sucursal. La lógica consistía en que los usuarios de la sucursal bancaria pudiesen iniciar la sesión y obtener acceso a los recursos de la red local incluso en caso de error de la WAN.
En aquellos tiempos, la necesidad de seguridad física de los DC no se comprendía adecuadamente. Incluso me encontré con controladores de dominio debajo de escritorios a los que cualquier persona podía obtener acceso. No fue hasta unos pocos años después que arquitectos de Active Directory comenzaron a apreciar el riesgo de seguridad que suponía un DC sin protección, y las organizaciones de TI comenzaron a consolidar sus DC en centros de datos más centralizados. A partir de entonces, los usuarios de sucursales tuvieron que autenticarse a través de WAN, pero esto supuso un cambio muy importante en cuanto a seguridad añadida.
Active Directory en Windows Server 2008 cambia la ecuación con respecto a implementaciones de sucursal al introducir controladores de dominio de sólo lectura, o RODC. Estos representan el cambio más importante en los Servicios de dominio de Windows Server 2008.
El equipo de Active Directory se centró en los requisitos del escenario de la sucursal a la hora de diseñar el RODC, y adoptaron el siguiente objetivo: "Lo que ocurre en la sucursal, se queda en la sucursal". El hecho es que, si implementa un DC en una sucursal físicamente no segura, hay muy poco que pueda hacer para prevenir que el DC, y los equipos que confían en este DC, sean víctimas de ataques. Sin embargo, puede evitar que los daños causados por estos ataques se extiendan de la sucursal al resto del dominio.
Tenga en cuenta que, a pesar de que constituyen un cambio muy relevante en la infraestructura de ADDS, los RODC son sencillos de implementar. Su dominio debe estar en un nivel funcional de bosque de Windows Server 2003 y debe haber, al menos, un DC de Windows Server 2008 en el dominio. Además de constituir simplemente una solución de sucursal, los RODC tienen sentido en entornos orientados a Internet y en situaciones en las que el DC se ubica en el perímetro de la red.

Deserción del DC
Hay varias clases de amenazas que deben considerarse en una sucursal. La primera es el escenario "DC robado", en el cual alguien "huye" con el DC o el disco del DC. Más allá de la interrupción del servicio local, el riesgo consiste, a fin de cuentas, en que el atacante obtiene acceso a todos los nombres de usuario y contraseñas en el dominio y, desde aquí, eleva sus privilegios para obtener acceso a recursos protegidos o provocar una denegación de servicio. Para solucionar esta amenaza, los RODC, de manera predeterminada, no almacenan los valores hash de contraseña en el Árbol de información del directorio (DIT) del RODC. Así pues, para autenticar a un usuario en el dominio, cuando un usuario se autentica por primera vez en un RODC específico, el RODC pasa la solicitud a un controlador de dominio completo (FDC) en el dominio. El FDC procesa la solicitud y, si es correcta, el RODC emite una solicitud de replicación para el valor hash de la contraseña.
Un RODC comprometido podría solicitar, de manera potencial, valores hash de contraseña para cuentas confidenciales. Para evitarlo, el administrador de dominio puede configurar una directiva de replicación de contraseñas para cada RODC. La directiva de replicación de contraseñas se compone de dos atributos en el objeto de equipo del RODC. El atributo msDS-RevealOnDemandGroup contiene los nombres distintivos de grupos, usuarios o cuentas de equipo cuyas contraseñas se pueden almacenar en caché en el RODC (estos son normalmente los usuarios y los equipos que se encuentran en el mismo sitio que el RODC). msDS-NeverRevealGroup contiene los nombres distintivos de grupos, usuarios o cuentas de equipo cuyas contraseñas no se pueden almacenar en caché en el RODC (por ejemplo, la cuenta del administrador de dominio nunca debe tener los valores hash de la contraseña almacenados en caché en un RODC). Cuando el RODC solicita el valor hash de la contraseña para una cuenta particular, el FDC evalúa la solicitud según la directiva de replicación de contraseñas para determinar si el valor hash de la contraseña debe replicarse en el RODC. Con el robo de un DC, la vulnerabilidad se limita a aquellas contraseñas almacenadas en caché en el RODC robado en el momento en se quitó de la red, y se elimina la posibilidad de compromiso de contraseñas críticas.
El objeto de equipo del RODC contiene otros dos atributos para ayudarle a determinar exactamente qué cuentas deben almacenar sus contraseñas en caché. El atributo msDS-AuthenticatedAtDC enumera las cuentas que se han autenticado en el RODC, y el atributo msDS-RevealedList indica las cuentas cuyas contraseñas están almacenadas actualmente en el RODC.
Los valores hash de las contraseñas de usuarios y equipos no son los únicos secretos almacenados en un DC. La cuenta KrbTGT contiene las claves del servicio Centro de distribución de claves de Kerberos (KDC) que se ejecuta en cada controlador de dominio. En un escenario normal, cada KDC del dominio comparte la misma cuenta KrbTGT, y es posible que un atacante pueda recuperar estas claves de un DC robado y usarlas para atacar el resto del dominio. Sin embargo, cada RODC tiene su propia cuenta y claves de KrbTGT, lo que elimina esta posibilidad.
Tampoco es excepcional que las aplicaciones almacenen contraseñas u otro tipo de información confidencial en el DIT. Si un atacante tiene la intención de robar un DC, podría robar posiblemente estas contraseñas de aplicación y usarlas para obtener acceso a las aplicaciones. Para evitar este riesgo, los Servicios de dominio de Windows Server 2008 permiten a los administradores definir el conjunto de atributos con filtro de DC de sólo lectura (RO-FA). Los atributos que forman parte de RO-FAS nunca se replican en los RODC; por lo tanto, estos no se pueden obtener de un DC comprometido. Debe asignar atributos a RO-FAS mediante la configuración del bit 9 (0x0200) del atributo searchFlags del objeto attributeSchema correspondiente en el esquema.

Ataque de los bárbaros
Otra clase de amenaza para controladores de dominio de sucursal podría ser el caso de un administrador de servidor local que aprovecha los privilegios del DC para obtener acceso a otros recursos de dominio o para diseñar un ataque de denegación de servicio. De nuevo, si el administrador local tiene acceso físico al controlador de dominio, se podrá hacer muy poco para evitar los daños. Pero es posible evitar que el atacante use el controlador de dominio de la sucursal para comprometer otros DC del dominio.
Los RODC no se consideran confiables como controladores de dominio por parte de los DC completos del dominio. Desde el punto de vista de la confianza, los FDC tratan los RODC como servidores miembro del dominio. Un RODC no es miembro de los grupos Controladores de dominio empresariales y Controladores de dominio. La cuenta RODC tiene limitada su capacidad para actualizar cualquier valor del directorio y, por lo tanto, incluso si un atacante compromete la cuenta RODC, no obtendrá prácticamente privilegios útiles.
Los RODC no se muestran tan siquiera en la topología de replicación de DS normal. Puesto que los RODC parecen servidores miembro normales en lugar de controladores de dominio, el Comprobador de coherencia de la información (el proceso responsable en cada DC de calcular la topología de replicación de DS) no creará objetos de conexión a partir de RODC. Ningún DC completo o RODC tratará de llevar a cabo la replicación a partir de un RODC. Por el contrario, el RODC creará un objeto de conexión que representará un acuerdo de replicación entrante a partir de un DC completo, pero este objeto de conexión sólo existe en la réplica del RODC; ningún otro DC tiene una copia de este objeto de conexión. Desde el punto de vista de la replicación, los RODC son como trampas para los objetos de directorio. Los objetos se replican dentro, pero no fuera.

Separación de funciones administrativas en RODC
Es muy común que un DC de sucursal venga administrado por un administrador de servidor local que lleva a cabo todas las funciones, desde la ejecución de copias de seguridad en el controlador de dominio a la limpieza de teclados. Pero otorgar a un administrador de sitio remoto los derechos necesarios para llevar a cabo el mantenimiento general en un controlador de dominio supone un riesgo de seguridad, y la administración del sitio puede elevar posiblemente sus privilegios en el dominio. Los RODC ofrecen dos clases de separación de funciones administrativas para mitigar esta amenaza.
Con la primera clase de separación de funciones, el administrador de dominio puede aumentar el nivel del RODC de la manera normal mediante DCPROMO o puede usar un proceso de dos pasos en el cual el proceso de aumento de nivel real se delega de manera segura al administrador del sitio de la sucursal, sin otorgar ningún derecho de administración de dominio. El administrador de dominio crea previamente la cuenta de equipo del RODC en el dominio mediante el complemento MMC Usuarios y equipos de Active Directory, tal como se muestra en la Figura 5.
Figura 5 Creación previa de una cuenta de equipo del RODC
Figura 5 Creación previa de una cuenta de equipo del RODC
Al seleccionar "Crear previamente una cuenta de controlador de dominio de sólo lectura", se ejecuta una versión abreviada de DCPROMO que realiza todas las tareas que requieren acceso administrativo al dominio, incluidas la creación de la cuenta de equipo, la asignación del RODC a un sitio, la especificación de las funciones del DC, la especificación de la directiva de replicación de contraseñas y la definición del usuario o el grupo que necesitará los derechos para completar la operación DCPROMO en el RODC. El administrador o el grupo delegados se almacenan en el atributo managedBy del objeto de equipo del RODC.
El administrador delegado puede, a continuación, ejecutar DCPROMO en el mismo servidor. DCPROMO detectará la cuenta creada previamente y convertirá el servidor en un RODC. Al ejecutar DCPROMO de esta manera, no se necesitan credenciales de administrador de dominio.
La segunda manera en que los RODC ofrecen separación de funciones administrativas es mediante la creación de funciones administrativas locales en el mismo RODC. Estas funciones parecen grupos locales de equipo que se almacenan en el registro del RODC y sólo se pueden evaluar en el RODC. Pero, en lugar de usar el complemento MMC Administración de equipos, el administrador administra las funciones locales de RODC mediante NTDSUTIL. La Figura 6 indica las funciones administrativas locales en un RODC. Estas funciones se corresponden una a una con los grupos integrados en Windows.
Figure 6 Funciones administrativas locales de RODC (Close Figure 6)

Operadores de cuentas
Administradores
Operadores de copia de seguridad
Acceso de DCOM a servicio de certificados
Operadores de cifrado
Usuarios COM distribuidos
Lectores del registro de eventos
Invitados
IIS_IUSRS
Creadores de confianza de bosque de entrada
Operadores de configuración de red
Usuarios del registro de rendimiento
Usuarios del monitor de rendimiento
Acceso compatible con versiones anteriores de Windows 2000
Operadores de impresión
Usuarios de escritorio remoto
Replicador
Operadores de servidores
Servidores de licencias de Terminal Server
Usuarios
Grupo de acceso de autorización de Windows

Rarezas de RODC
Puesto que los RODC son de sólo lectura y ningún otro controlador de dominio se replicará a partir de ellos, los RODC exhiben ciertos comportamientos inesperados. Por ejemplo, los objetos persistentes (objetos eliminados de todos los sitios menos de un DC particular debido a la incapacidad de replicación del DC por más tiempo que la vigencia del bosque) se detectan normalmente a través de los partners de replicación saliente del DC. Pero, puesto que los RODC no tienen partners de replicación entrante, no existe la detección de objetos persistentes para ellos.
Los RODC no llevarán a cabo operaciones de actualización de LDAP (agregar, modificar, eliminar, cambiar nombre o mover). En su lugar, los RODC devolverán un error con una referencia LDAP a un DC de escritura que puede llevar a cabo la operación. Si la aplicación que emitió la actualización de LDAP no administra adecuadamente la operación de referencia, podría generarse un error en la aplicación.
Finalmente, si un usuario de otro dominio del bosque intenta autenticarse en un RODC, el RODC debe ser capaz de obtener acceso a un DC completo en su propio dominio con el objeto de obtener la contraseña confiable para pasar adecuadamente la solicitud de autenticación al DC en el dominio de usuario. Si la conexión de red entre el RODC y el DC completo en su dominio no está disponible, habrá un error en la autenticación.

Directivas de contraseña muy específicas
La capacidad de definir más de una directiva de contraseña en el dominio fue probablemente la característica más solicitada de Windows Server 2008 ADDS. Como probablemente sepa, en Windows 2000 y Windows Server 2003 Active Directory, cada dominio es compatible sólo con una única directiva de contraseña que se aplica a todas las entidades de seguridad del dominio. Si necesita una directiva de contraseña independiente para un grupo específico de usuarios, tiene que crear un dominio independiente. Pero, ahora, una característica nueva en Windows Server 2008 ADDS, denominada Directivas de contraseña muy específicas, permite definir varias directivas de contraseña en un dominio.
La nueva estrategia usa grupos para aplicar directivas de contraseña muy específicas a usuarios. En primer lugar, debe definir la directiva de contraseña específica mediante la creación de un nuevo objeto msDS-PasswordSettings en el contenedor CN=Password Settings Container, CN=System, DC=<domain>. El objeto msDS-PasswordSettings (PSO) contiene atributos que reflejan la configuración de la directiva de contraseñas en la Directiva de grupo (consulte la Figura 7).
Figure 7 Atributos del objeto mSDS-PasswordSettings (Close Figure 7)

Atributo | Descripción
mSDS-PasswordReversibleEncryptionEnabled | Valor booleano que indica si las contraseñas se han cifrado mediante cifrado reversible.
mSDS-PasswordHistoryLength | Número de entradas conservadas en el historial de contraseñas.
mSDS-PasswordComplexityEnabled | Valor booleano que indica si las restricciones de complejidad de contraseña están habilitadas.
mSDS-MinimumPasswordLength | Número entero que define la longitud mínima de la contraseña.
mSDS-MinimumPasswordAge | INTEGER8 que indica la antigüedad mínima de la contraseña antes de que pueda cambiarse.
mSDS-MaximumPasswordAge | INTEGER8 que indica la antigüedad máxima de la contraseña antes de que deba cambiarse.
mSDS-LockoutThreshold | Número entero que indica el número de inicios de sesión con error antes del bloqueo.
mSDS-LockoutObservationWindow | INTEGER8 que indica el número de nanosegundos dentro de los cuales deben ocurrir los inicios de sesión consecutivos con error para activar el bloqueo.
mSDS-LockoutDuration | INTEGER8 que indica el número de nanosegundos durante los cuales queda bloqueada la cuenta.
A continuación, asigna la directiva de contraseñas a usuarios o grupos al agregar los nombres de usuario o grupo al atributo mDS-PSOAppliesTo de varios valores del PSO. Una vez que acepta la idea de que no tiene que aplicar directivas de contraseña a unidades organizativas (OU), es bastante sencillo. Pero existe alguna complejidad adicional.
Los usuarios son normalmente miembros de muchos grupos. Así pues, ¿qué sucede si hay varias directivas de contraseña conflictivas asociadas a un usuario debido a estas pertenencias a grupos? En este caso, ADDS usa una evaluación de la prioridad para determinar qué directiva de contraseña se debe aplicar. Funciona de este modo:
  1. Si una directiva de contraseñas está vinculada directamente a un objeto de usuario (no a través de la pertenencia a grupos), se aplicará esa directiva de contraseña.
  2. Si hay varias directivas de contraseña vinculadas directamente al usuario, se aplicará la directiva con el valor más bajo de prioridad (tal como determine el valor del atributo msDS-PasswordSettingsPrecendence del PSO).
  3. Si hay varios PSO con la misma prioridad, se aplicará el que tenga el valor objectGUID más bajo.
  4. Si ningún PSO está vinculado directamente al usuario, ADDS evaluará los PSO vinculados a los grupos del usuario. Si hay más de un PSO, se aplicará el PSO con el valor más bajo en el atributo msDS-PasswordSettingsPrecedence.
  5. Si hay más de un PSO con el mismo valor de prioridad, se aplicará el que tenga un valor objectGUID más bajo.
  6. Si no hay ningún PSO asociado con el usuario, se usará la directiva de contraseña del dominio.
Los objetos de usuario tienen un nuevo atributo denominado msDS-ResultantPSO para ayudar a esclarecer exactamente qué PSO se aplica a un usuario. Este atributo contiene el nombre distintivo del PSO que administra la contraseña del usuario.
Las directivas de contraseña muy específicas le ofrecen más flexibilidad de la que posiblemente necesitará jamás, pero debe administrar estas directivas con cuidado para que sean lo más sencillas posible. No existe utilidad de fábrica para definir directivas de contraseña muy específicas; necesitará usar ADSIEdit o buscar una utilidad de terceros.

Servicio reiniciable de Active Directory
Cada vez que detiene un controlador de dominio para el mantenimiento de DIT, puede provocar interrupciones en los niveles de servicio de la red. Los DC de Windows Server 2008 cuentan con una nueva característica que permite detener el servicio de directorio sin desactivar por completo el DC.
El comando NET STOP NTDS detiene ADDS en un DC de Windows Server 2008. Al hacer esto, el proceso de la autoridad de seguridad local (LSASS) en el DC continúa ejecutándose, pero descarga todas las DLL relacionadas con ADDS y el servicio de directorio no está disponible. LSASS se comporta esencialmente como lo haría en un servidor miembro y reenvía solicitudes de autenticación del dominio a un DC. Puesto que se han descargado las DLL que administran ADDS, puede aplicar revisiones relacionadas con ADDS o llevar a cabo una desfragmentación sin conexión del DIT. El inicio de ADDS es tan simple como NET START NTDS. No obstante, para restaurar el DIT a partir de una copia de seguridad del estado del sistema, deberá realizar el arranque en modo de reparación del servicio de directorio.
Es importante que comprenda que el servicio de directorio no es realmente un servicio de Windows. Es, todavía, un componente integrante de LSASS, por lo que no puede detener LSASS sin apagar el equipo. Pero la capacidad de iniciar y detener el servicio de directorio en Windows Server 2008 constituye una opción conveniente.

Copia de seguridad y recuperación
Todo el mecanismo de copia de seguridad y restauración se ha renovado por completo en Windows Server 2008. No entraré en detalles aquí, pero las nuevas Copias de seguridad de Windows Server integran cambios que afectan a ADDS.
Copias de seguridad de Windows Server es una solución de copia de seguridad basada en volúmenes, lo cual significa que realiza copias de seguridad de volúmenes completos de disco de una vez. Sólo realiza copias de seguridad en dispositivos de disco (o similares), no tiene compatibilidad con cinta.
Existe una opción de copia de seguridad del estado del sistema para la utilidad de copia de seguridad de línea de comandos WBADMIN. Mediante el comando START SYSTEMSTATEBACKUP de WBADMIN, puede crear ahora una imagen de copia de seguridad que contiene todos los archivos de sistema críticos necesarios para restaurar Active Directory en un controlador de dominio. Existe, no obstante, capacidad para cinco volúmenes en el conjunto de las copias de seguridad, pero los volúmenes en el conjunto de copias de seguridad contendrán sólo los archivos necesarios para una restauración del estado del sistema. Es incluso más molesto el hecho de que, a partir de la compilación RC0 de Windows Server 2008, no es posible realizar una copia de seguridad del estado del sistema en un recurso compartido de red. Debe tener un volumen de disco local disponible para almacenar imágenes de copia de seguridad del estado del sistema, y este volumen no debe formar parte del conjunto de volúmenes de copia de seguridad del estado del sistema. Puede que tenga que agregar un volumen de disco nuevo a cada controlador de dominio en que realice copias de seguridad de estado del sistema.
La restauración del estado del sistema es bastante sencilla. Simplemente arranque el DC en el modo de restauración de servicios de directorio y ejecute el comando START SYSTEMSTATERECOVERY de WBADMIN. El resultado es un DIT restaurado de manera no autoritativa, en el cual puede restaurar autoritativamente objetos específicos mediante NTDSUTIL, tal como haría en Windows Server 2003.
Un aspecto de las Copias de seguridad de Windows Server merece mención especial: almacena imágenes de copia de seguridad en formato de disco duro virtual (VHD). Se trata del mismo formato que usa Microsoft Virtual Server 2005 para almacenar sus imágenes de disco virtual. Esto significa que puede tomar una imagen de copia de seguridad creada con las Copias de seguridad de Windows Server y montarla como una unidad de disco en un equipo virtual que se ejecute bajo Microsoft Virtual Server. A continuación, podrá examinar el contenido de la copia de seguridad como si se tratara de una unidad de disco normal.
Otro cambio con respecto a la copia de seguridad de ADDS es la capacidad de usar el Servicio de instantáneas de volumen para crear instantáneas de un momento dado de Active Directory. Al crear una instantánea mediante NTDSUTIL, el Servicio de instantáneas de volumen guarda la imagen anterior de cada bloque de disco del DIT antes de que se sobrescriba durante una operación de actualización. Al combinar las imágenes anteriores guardadas con la versión actual del DIT, el Servicio de instantáneas de volumen puede crear una instantánea completa del DIT con muy poca sobrecarga. La creación de una instantánea normal tarda tan sólo unos segundos, independientemente del tamaño del DIT.
En sí misma, se trata de una capacidad interesante, pero no del todo útil. Sin embargo, en Windows Server 2008, ADDS incluye una utilidad de línea de comandos denominada DSAMAIN que monta la imagen de instantánea en modo de sólo lectura. Esto proporciona un servidor LDAP independiente, muy semejante a una sesión de ADLDS que incluye el contenido de su directorio en el momento de la instantánea. Puede examinar el directorio mediante la utilidad LDP u otras herramientas LDAP, y recuperar versiones de objetos de directorio de un momento dado anterior.

Replicación SYSVOL con DFS-R
Windows Server 2003 R2 contaba con un Servicio de archivos distribuidos (DFS) totalmente renovado que integraba un mecanismo de replicación de archivos innovador denominado DFS-R. Este usa la compresión diferencial remota, que reduce sustancialmente el tráfico de replicación de archivos al determinar qué bloques de un archivo de destino necesitan replicarse para presentar sincronización con el archivo de origen. Sin embargo, Windows Server 2003 R2 usa todavía el Servicio de replicación de archivos (no DFS-R) para replicar SYSVOL entre controladores de dominio. Debido a esto, la replicación de SYSVOL continuaba siendo una fuente de problemas para los administradores de Active Directory.
Cuando se lleva a cabo la ejecución en el nivel funcional de dominio de Windows Server 2008, Windows Server 2008 puede replicar SYSVOL mediante DFS-R, lo que mejora la velocidad y la eficacia de la replicación de SYSVOL. De esta manera, es mucho más razonable colocar archivos de gran tamaño en SYSVOL para que estén disponibles en todos los DC. Para usar DFS-R con SYSVOL, debe migrar, en primer lugar, los datos anteriores de SYSVOL a DFS-R mediante la utilidad DFSRMIG. Este proceso consta de cuatro pasos:
  • Crear los objetos de Active Directory requeridos por DFS-R.
  • Crear la nueva estructura de archivos para SYSVOL en cada controlador de dominio.
  • Cambiar todos los controladores de dominio para que usen el nuevo SYSVOL.
  • Quitar el SYSVOL anterior.
Según el tamaño de SYSVOL y el número de controladores de dominio que posea, este proceso puede tardar unos momentos en realizarse, pero el rendimiento y la confiabilidad mejorados hacen que la espera merezca la pena.

Mejoras de auditorías
El sistema de auditorías de Active Directory para Windows Server 2003 constituye tanto una bendición como una maldición. Por una parte, ofrece una solución bastante completa, flexible y segura para efectuar el seguimiento de los cambios en el directorio. No obstante, algunos usuarios comentan que presenta problemas de capacidad de uso muy significativos.
Las auditorías de los cambios de directorio en un controlador de dominio de Windows Server 2003 se han convertido en un asunto de "todo o nada", o están activadas o no lo están. El volumen de tráfico de auditorías en un DC empresarial muy activo puede convertir la realización de auditorías en una tarea poco práctica. La configuración de un sistema de auditorías para crear los mensajes que realmente necesita mediante descriptores de seguridad individuales es aburrida y puede llevar fácilmente a error. Los mismos mensajes de auditoría son, con frecuencia, crípticos y, en muchos casos, no contienen la información que necesita, como los valores anteriores y posteriores de los atributos cambiados. Además, la recopilación, la correlación y el archivado de los mensajes procedentes de varios controladores de dominio no son realmente factibles con las herramientas nativas de Windows.
El sistema de auditoría de los servicios de directorio en Windows Server 2008 trata algunos de estos problemas. En primer lugar, hay cuatro nuevas subcategorías de auditoría para auditar los servicios de directorio: Acceso DS, Cambios DS, Replicación DS y Replicación DS detallada. Así pues, si desea simplemente auditar los cambios de directorio, no necesita examinar todos los eventos de lectura y replicación. Pero, si desea incluir las eliminaciones de objetos en su registro de auditoría, debe habilitar Acceso DS. Esto genera mensajes para todos los accesos de objeto de DS, con lo cual generará de nuevo demasiados mensajes. Además, puede configurar los descriptores de seguridad para generar los mensajes de auditoría que desea para los objetos de interés.
Los mensajes de auditoría se han limpiado sustancialmente para que sean legibles y contengan los datos que necesita. En particular, los cambios de directorio generan entradas de registro de auditoría que contienen los valores anteriores y nuevos de los atributos cambiados. Esto constituye una enorme mejora. La única desventaja en este caso es que los valores anteriores y nuevos aparecen en entradas separadas del registro de auditoría, por lo que tiene que llevar a cabo su correlación con el objeto de entender realmente el cambio realizado. Muchos productos complementarios de recopilación de registros de auditoría, incluidos los Servicios de recopilación de auditorías de Microsoft, son compatibles con esta clase de correlación.

Mejoras de la interfaz de usuario
Los complementos MMC Usuarios y equipos, Sitios y servicios, y Dominios y confianzas de Active Directory han sido siempre adecuados para administrar Active Directory. En Windows Server 2008, se han limpiado las herramientas básicas de administración y se ha integrado un par de características nuevas muy atractivas. Si habilita Características avanzadas, el cuadro de diálogo Propiedades muestra para cada objeto una ficha adicional denominada Editor de atributos. Se trata de la misma ficha de editor de atributos usada por ADSIEdit, que permite inspeccionar y editar todos los atributos del objeto. La propia ficha ofrece ahora una mejor descodificación de los atributos codificados, como el atributo userAccountControl. La Figura 8 muestra la adecuada integración del editor de atributos.
Figura 8 Editor de atributos en Usuarios y equipos de Active Directory
Figura 8 Editor de atributos en Usuarios y equipos de Active Directory

Conclusión
Además de los puntos clave que he tratado en este artículo, existen otras muchas mejoras integradas en ADDS en Windows Server 2008. Por ejemplo, el KDC usa el Estándar de cifrado avanzado de 256 bits (AES-256) si el dominio se encuentra en el nivel funcional de dominio de Windows Server 2008. Puede habilitar la Prevención de eliminación accidental de objetos al activar la casilla apropiada en la ficha Objeto para cualquier objeto de DS. El Motor de almacenamiento extensible que ofrece el servicio de administración de datos se ha mejorado para usar la corrección de errores de un solo bit, lo que reduce la probabilidad de que un error de hardware o software en el subsistema de disco pueda dañar el DIT. El servicio DNS comienza a procesar solicitudes antes de haber cargado por completo la base de datos DNS. El Servicio de ubicación del controlador de dominio se ha mejorado para que, en caso de no encontrar un DC en el sitio deseado, intente ubicar un DC en el sitio más próximo, en lugar de usar simplemente cualquier DC que pueda encontrar en el dominio. Además, NTDSUTIL es ahora compatible con RODC y las instantáneas del Servicio de instantáneas de volumen.
Claramente, Windows Server 2008 integra un número considerable de mejoras en los Servicios de dominio de Active Directory. En conjunto, estos cambios mejorarán apreciablemente la seguridad y la capacidad de administración de ADDS. Lo mejor, no obstante, es que el integrar Windows Server 2008 en su entorno de Active Directory no implica una migración masiva, es un proceso sencillo e incremental.

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


 Cobertura especial: Windows Server 2008: Introducci&#243;n a IIS 7.0
Cobertura especial: Windows Server 2008 Isaac Roybal

Introducción a IIS 7.0
Resumen:
  • Cambios de arquitectura de IIS 7.0
  • Administración de IIS 7.0
  • Compatibilidad con versiones anteriores
  • Solución de problemas de IIS 7.0

Cada departamento de TI es distinto; cada uno tiene su conjunto exclusivo de necesidades y objetivos, especialmente en lo que se refiere al hospedaje de sitios o de servicios web. Los servidores web pueden necesitar determinados ingredientes para cumplir los requisitos de la organización, además del reto que supone
la replicación de esta receta en varios servidores al mismo tiempo que se intenta administrarlos de la manera más eficaz posible. Algunos de los cambios más importantes integrados en IIS 7.0 tienen como objetivo ayudar a los departamentos de TI a conseguir precisamente este objetivo a la hora de crear un servidor web o granjas de servidores web.
Cuando revisé la lista de las estupendas características integradas en IIS 7.0, me alegré en gran medida de tener la oportunidad de compartir los detalles de estas características con los lectores de TechNet Magazine. Me di cuenta de que probablemente no podría abarcarlas todas aquí, por lo que decidí centrarme en algunas de las características más significativas y en los cambios más sustanciales de IIS 7.0. Para obtener más información, visite el sitio web de la comunidad de IIS en IIS.net.

Nueva arquitectura
Los principales cambios integrados en IIS 7.0 se refieren a la arquitectura, el procesamiento de solicitudes, la compatibilidad con el marco de aplicaciones PHP y el almacén de configuración. Con IIS 6.0, las características eran básicamente una cuestión "de todo o nada". Tenía que instalar todas las características y sólo era posible personalizar IIS mediante ISAPI.
IIS se ha creado en consonancia con la premisa de que un administrador web desea empezar a partir de un conjunto base de funcionalidades y, a continuación, agregar sólo las funcionalidades adicionales necesarias deseadas en su entorno. El usuario es el que mejor conoce su entorno, por lo que IIS 7.0 le ofrece los bloques de creación para crear su propio servidor web personalizado. De este modo, atenuará la sobrecarga administrativa al reducir la superficie de ataque del servidor y eliminar la necesidad de actualizaciones de los componentes que no se usan. La clave de este nuevo enfoque es la arquitectura modular de IIS 7.0.
IIS 7.0 cuenta con un nuevo diseño que permite seleccionar las funciones, los módulos, que se van a instalar en el servidor. Estos módulos se conectan directamente a la canalización de solicitud integrada. Este nuevo diseño modular cuenta con distintos beneficios, incluida la reducción de la superficie de ataque y la superficie global del servidor web.
IIS tiene actualmente 40 módulos predeterminados, por ejemplo, los módulos básico, anónimo y autenticación de Windows® son ahora módulos individuales que se pueden agregar a la canalización de solicitud de manera independiente. Para una clasificación sencilla, los módulos se agrupan en ocho subcategorías (consulte la Figura 1).
Figura 1 Los módulos de IIS 7.0 se clasifican en ocho áreas funcionales.
Figura 1 Los módulos de IIS 7.0 se clasifican en ocho áreas funcionales.
Esto significa que ahora cuenta con la capacidad de crear un servidor web personalizado adaptado exactamente a su entorno. Pero, ¿qué ocurre si necesita una funcionalidad que los 40 módulos predeterminados no ofrecen, por ejemplo, una clase determinada de autenticación personalizada o un modificador de contenido? No hay problema. Es posible escribir un módulo en código nativo o administrado para cubrir esta necesidad y conectarlo directamente a la canalización. Esto también permite a Microsoft escribir y proporcionar módulos nuevos de manera individual para que no tenga que esperar al próximo service pack o versión del producto. IIS 7.0 también proporciona la capacidad de sobrescribir cualquiera de los 40 módulos predeterminados con sus propios módulos personalizados. Para obtener más información acerca de cómo crear su propio módulo, consulte IIS.net.

Canalización de solicitud integrada
Piense en la canalización de solicitud integrada como un conjunto esencial de pasos lineales que deben tener lugar cada vez que se sirve una página (como puede observar en la Figura 2). Normalmente, debe tener lugar algún tipo de autenticación seguida de autorización para recuperar el contenido, así como la determinación y la ejecución del controlador necesario para dicho contenido, el rendimiento de cualquier registro necesario y, por último, el envío de una respuesta. La canalización de solicitud integrada otorga a IIS 7.0 la flexibilidad necesaria para ejecutar distintos marcos de aplicaciones al mismo tiempo. Por ejemplo, puede ejecutar la autenticación mediante formularios sobre contenido PHP con un módulo de registro personalizado, todo en una misma canalización.
Figura 2 Módulos y canalización integrada de IIS 7.0
Figura 2 Módulos y canalización integrada de IIS 7.0
Cada sitio web del servidor tiene una canalización de solicitud integrada y puede ejecutarse en uno de dos modos, integrado y clásico. El modo integrado es el modo predeterminado, y permite la conexión de funciones específicas a la canalización, lo cual proporciona un control granular sobre el proceso de solicitud. Por razones de compatibilidad, el modo clásico reproduce la funcionalidad de IIS 6.0/ISAPI a través de un módulo de ISAPI en la canalización. Esto es muy útil a la hora de migrar aplicaciones a IIS 7.0.

Instalación predeterminada
Hablemos ahora acerca de la instalación de su nuevo servidor web modular. Si observa una instalación predeterminada de IIS 7.0, advertirá que sólo están incluidos 10 módulos, si incluimos el servicio WAS (Windows Process Activation Service). La instalación de IIS 7.0 ofrece la funcionalidad base de IIS para instalar la función de servidor web; de manera específica, sólo proporciona los módulos necesarios para proporcionar contenido estático, como HTML sin formato o ASP clásico. Lo que se instale en el servidor tras este paso es estrictamente una opción personal. Esta es la funcionalidad incluida en una instalación predeterminada:
  • Características HTTP comunes, incluidas Contenido estático, Documento predeterminado, Examen de directorios y Errores HTTP
  • Características de estado y diagnóstico, como Registro HTTP y Monitor de solicitudes
  • Características de seguridad, como Filtro de solicitudes
  • Características de rendimiento, como Compresión de contenido estático
  • Herramientas de administración, incluida la Consola de administración de IIS
  • Servicio WAS (Windows Process Activation Service)
Como puede ver, se trata de un servidor mínimo que no incluye ASP.NET ni otras funcionalidades nuevas de IIS 7.0, como las características de diagnóstico y solución de problemas. La habilitación de funciones adicionales en el servidor, como la capacidad de proporcionar contenido dinámico como ASP.NET y FastCGI (PHP), es bastante sencilla. Seleccione el conjunto de módulos que desea instalar en "Agregar servicios de función" de la función de servidor web de Windows Server® 2008 Server Manager.

Nuevo almacén de configuración
Otro cambio clave en IIS 7.0 que le hará la vida más fácil es, sin duda, el nuevo almacén de configuración. La metabase, ahora componente de instalación opcional para la compatibilidad con versiones anteriores, se ha reemplazado por un sistema de configuración XML. Puedo oírle decir: "¡Pero si la metabase era XML!" Sí, lo era. Pero era complicada y difícil de leer (por lo menos para los mortales). Se ha reemplazado, por tanto, por un sistema XML más flexible. Al igual que ASP.NET, IIS 7.0 usa archivos de configuración limpios, sencillos, portátiles y legibles.
El paso a este formato significa que el sistema de configuración es ahora independiente del equipo, al contrario que la metabase que estaba vinculada a un equipo individual. Como resultado, ahora podrá transportar fácilmente el sistema de configuración a otros servidores con tan sólo arrastrar y colocar, o usar XCOPY, y ya está.
Este nuevo sistema de configuración hace maravillas también con las granjas de servidores web mediante el uso de una nueva característica integrada en IIS 7.0 denominada Configuración compartida. Puesto que este nuevo sistema de configuración es portátil, puede compartir un archivo de configuración maestro entre todos los nodos de la granja de servidores. La Configuración compartida le permite exportar la configuración de un servidor de preproducción conocido como correcto y, a continuación, compartirla en todo el entorno "activo" o de producción.
Al exportar el archivo de configuración, debe proporcionar una contraseña de clave de cifrado. Esto protege el archivo de configuración de servidores web no autorizados que intenten imitar la configuración de su servidor sin autorización.
La habilitación de la configuración compartida es sencilla. En el nodo de servidor del Administrador de IIS, seleccione Configuración compartida, ubicada en la sección Administración del panel de tareas. Simplemente marque "Habilitar configuración compartida", proporcione la ruta de acceso física de la configuración que va a compartir (normalmente será un recurso compartido UNC), escriba las credenciales necesarias para obtener acceso a la ruta de acceso física y haga clic en Aplicar. Una vez que se encuentre el archivo .config de configuración, se solicitará la contraseña de cifrado. Cuando el proceso haya terminado, reinicie el Administrador de IIS para que seleccione la configuración nueva.
La estructura del nuevo sistema de configuración es diferente a la que estaba acostumbrado, por lo tanto, repasemos los aspectos básicos. Tal como muestra la Figura 3, la configuración de IIS 7.0 se ha desglosado en dos categorías, la configuración de todo el servidor y la configuración específica del sitio. La configuración de todo el servidor se almacena en applicationhost.config, que se ubica en %systemroot%\windows\system32\inetsrv\config. Esto incluye todos los módulos instalados, los sitios del servidor, etc. La configuración específica del sitio se almacena en archivos web.config individuales.
Figura 3 Hay un archivo de configuración para la configuración de todo el servidor y archivos individuales independientes para cada sitio web de dicho servidor.
Figura 3 Hay un archivo de configuración para la configuración de todo el servidor y archivos individuales independientes para cada sitio web de dicho servidor.
Si ha usado ASP.NET, probablemente esté familiarizado con los archivos web.config. IIS 7.0 usa archivos web.config para almacenar la configuración específica de sitios web individuales, como la configuración de aplicaciones y documentos predeterminada de un sitio, así como la configuración de ASP.NET. Esto significa que tendrá un archivo web.config para cada sitio en su servidor.
Los archivos web.config de los sitios se ubican en la ruta de acceso física de cada sitio, por ejemplo, %systemroot%\inetpub\wwwroot. Este diseño ofrece los mismos beneficios de portabilidad indicados anteriormente pero en el nivel de sitio. Es posible desarrollar fácilmente un sitio en un servidor de prueba, por ejemplo, y, a continuación, simplemente arrastrar y colocar, o XCOPY, el archivo web.config del sitio, así como los archivos de aplicación en un servidor de producción.
Siempre que transporte o comparta archivos de configuración, preste atención a la información específica del equipo, como las direcciones IP y las letras de unidad. IIS 7.0 ofrece una solución para este posible descuido mediante la compatibilidad con variables de entorno de sistema operativo (como %systemroot%). Asegúrese de que el mismo conjunto de módulos está instalado en todos los servidores de producción y prueba. De este modo, evitará errores inesperados de aplicación. También pueden ocurrir errores si el archivo web.config hace referencia a un módulo que no está instalado o si un módulo predeterminado entra en conflicto con un módulo personalizado.

Administración del servidor web
Ahora, por tanto, ya dispone de este gran servidor web nuevo, personalizable, flexible y portátil. ¿Cómo va a administrarlo? La administración fue una parte importante de la planeación y la creación de IIS 7.0. Hay varias maneras de realizar tareas administrativas.
Las preferencias de administración pertenecen normalmente a una de tres categorías: administración basada en operaciones de apuntar y hacer clic en la en la interfaz de usuario, introducción de comandos en la línea de comandos y escritura de scripts para automatizar lo máximo posible. Comencemos con la interfaz de usuario.
En IIS 6.0, el complemento Microsoft® Management Console (MMC) de interfaz de usuario tenía dos vistas básicas conocidas, la vista de árbol y la vista de fichas. Para entrar en una configuración, hacía clic con el botón secundario, seleccionaba Propiedades y se le ofrecían una serie de fichas, por no mencionar los botones de radio y las casillas.
Afortunadamente, la interfaz de usuario de IIS 7.0 se ha modernizado por completo. Esta interfaz de usuario, denominada Administrador de IIS, se ha diseñado para habilitar un enfoque orientado a las tareas, como se muestra en la Figura 4. Existe también un Administrador remoto para clientes de nivel inferior, como Windows XP y Windows Server 2003. Puede descargarlo de IIS.net/downloads.
Figura 4 Nueva interfaz de usuario en IIS 7.0
Figura 4 Nueva interfaz de usuario en IIS 7.0
La nueva interfaz de usuario consta del panel Conexiones a la izquierda, el panel Acciones a la derecha y un panel de tareas o espacio de trabajo en el centro. El árbol administrador de conexiones de la izquierda es semejante a la vista de árbol de IIS 6.0 con nodos principales y secundarios. Una novedad de la vista de árbol es la capacidad de crear nuevas conexiones, guardar conexiones actuales o eliminar conexiones existentes. El panel de tareas es la mejora más importante de la interfaz de usuario, con dos vistas desde las que trabajar. La vista de características extrae todas las propiedades configurables de IIS de la anterior vista "de fichas" y las agrupa por área administrativa, por ejemplo, IIS, administración y seguridad.
Las propiedades de ASP.NET se han integrado también en el Administrador de IIS, lo que elimina la necesidad de usar un complemento MMC adicional. Cada propiedad configurable tiene su propio icono, lo cual facilita su localización. Y, puesto que el Administrador de IIS se creó como aplicación de Windows Forms, puede agregar fácilmente iconos de complementos para cualquier módulo personalizado o funcionalidad que escriba.
La segunda vista del panel de tareas es la vista de contenido, que es muy similar a la de IIS 6.0, ya que puede ver lo que hay en el directorio de contenido del sitio y puede llevar a cabo acciones según este contenido. La novedad aquí consiste en la capacidad de seleccionar una parte específica del contenido, por ejemplo, una página web específica y, a continuación, cambiar a la vista de características para invocar una determinada configuración en el contenido seleccionado, lo cual le ofrece un control granular hasta el nivel de página.

Otros métodos de administración
Para aquellos que prefieren la línea de comandos, existe una herramienta nueva muy eficaz denominada APPCMD.exe que permite realizar tareas sencillas, como la detención de un sitio o la copia de seguridad del archivo de configuración actual, así como tareas más complejas, como la búsqueda del esquema de configuración. La sintaxis es muy sencilla:
APPCMD (command) (object-type) <identifier> </parameter1:value1 ...>.
Si desea una lista de todos los objetos disponibles para APPCMD, escriba:
APPCMD /?
O, si desea ver los comandos disponibles para un tipo determinado de objeto, escriba:
APPCMD (object-type) /?
Para los programadores, se han añadido a ISS 7.0 una API de código administrado denominada Microsoft.Web.Administration y un nuevo proveedor del Instrumental de administración de Windows (WMI). Estos dos métodos abren un gran abanico de opciones para la creación de scripts, la automatización y la escritura de herramientas de administración de IIS 7.0. Ambos pueden usarse con Windows PowerShell®, y el proveedor de WMI también se puede usar con VBScript y JScript®. Para obtener información adicional, consulte blogs.msdn.com/carlosag/archive/2006/04/17/MicrosoftWebAdministration.aspx.

Administración remota y administración delegada
IIS 7.0 ofrece nuevos métodos para administrar de manera remota el servidor, los sitios, las aplicaciones web y los derechos de administración delegados de manera segura para los usuarios que no son administradores. Expliquemos en primer lugar las nuevas capacidades de administración remota y cómo le pueden facilitar la vida.
En el pasado, había dos maneras de administrar un servidor IIS de manera remota: mediante el sitio web de administración remota o mediante Escritorio remoto/Terminal Services para obtener acceso a la interfaz de usuario. Pero si se encontraba fuera del firewall o de la oficina, estas dos opciones no eran muy útiles. IIS 7.0 soluciona este problema al integrar capacidades de administración remota directamente en la interfaz de usuario que funcionan a través de HTTPS compatible con firewall.
La administración remota en IIS 7.0 facilita el trabajo en numerosos aspectos. En primer lugar, puede disfrutar de la misma experiencia de interfaz de usuario que obtendría si hubiera iniciado la sesión de manera local. En segundo lugar, no hay necesidad de abrir puertos en el firewall, puesto que la comunicación se produce a través de HTTPS. Por último, ahora es posible administrar varios servidores desde una interfaz de usuario única. No es necesario tener varias ventanas del escritorio remoto o del sitio web remoto abiertas al mismo tiempo.
El servicio de administración remota real de IIS 7.0 es, esencialmente, una aplicación web pequeña que se ejecuta como servicio independiente, bajo una cuenta de servicio local de Windows NT® denominada NT Service\WMSVC. Este diseño mantiene la funcionalidad de administración remota incluso si el servidor IIS en sí no responde.
Al igual que la mayoría de las características de IIS 7.0, por motivos de seguridad, la administración remota no se instala de manera predeterminada. Para instalar las características de administración remota, agregue los servicios para la función de servidor web en el Administrador de servidores de Windows Server 2008, que se encuentra en Herramientas de administración. Una vez que se ha instalado esta característica, debe habilitar las conexiones remotas e iniciar el servicio WMSVC, puesto que está desactivado de manera predeterminada.
La configuración de inicio predeterminada del servicio WMSVC es manual. Si desea que el servicio se inicie automáticamente tras un reinicio, necesitará cambiar la configuración a automática. Puede hacerlo a través de la línea de comandos al escribir:
sc config WMSVC start=auto
Al habilitar las conexiones remotas a través del servicio de administración, verá una lista de parámetros, como Credenciales de identidad, Conexiones y Restricciones de direcciones IPV4. La única decisión que es crítica en este punto es determinar a qué conjunto de credenciales de identidad se debe otorgar permiso para la conexión a IIS 7.0: sólo credenciales de Windows o credenciales de Windows y del Administrador de IIS.
La primera opción es bastante descuidada, pues indica que sólo desea permitir cuentas de usuario de Windows, ya sean locales o de dominio. La segunda opción implica tanto a usuarios de Windows como de un tipo de cuenta que es completamente nueva en IIS 7.0 y que no está asociada con las cuentas de usuario de Windows: Usuarios del Administrador de IIS. Con Usuarios del Administrador de IIS, los administradores pueden crear cuentas de usuario que sean conocidas sólo en el contexto de IIS 7.0 y que no tengan acceso al sistema operativo. Por último, de manera predeterminada, IIS ofrece un certificado autofirmado para empezar, pero se recomienda que agregue un certificado SSL firmado válido. Ahora, simplemente aplique su configuración e inicie el servicio.
Para control y seguridad adicionales, los administradores de TI tienen la capacidad de delegar de manera segura tareas de administración de sitios o aplicaciones web individuales a usuarios que no son administradores.
La administración delegada es esencialmente administración remota, pero limita el alcance del acceso a sitios o aplicaciones web individuales. La característica Usuarios del Administrador de IIS es especialmente útil en este contexto. Es posible crear usuarios de IIS para los propietarios de sitio de uso único y delegar permisos para la administración de su propio sitio o aplicación. Estos no tienen acceso a la configuración de todo el servidor y están limitados únicamente a la configuración de su sitio o aplicación web específicos.
Puede especificar también qué características y configuraciones pueden cambiar los usuarios e, incluso, cuáles deben aparecer en la interfaz de usuario. Por ejemplo, si no desea que un usuario pueda cambiar el tipo de autenticación usada para su sitio, puede configurar esta característica como de sólo lectura o no heredada. Cuando una característica es de sólo lectura, los usuarios pueden tener acceso a la misma y determinar la configuración pero no pueden realizar cambios. Con la configuración no heredada, el icono de la característica no aparecerá en la vista Administrador de IIS del usuario delegado. Esta clase de delegación de características permite proporcionar un acceso estrictamente controlado a otros usuarios sin ofrecer control administrativo sobre el servidor web.

Avanzando hacia IIS 7.0
Al diseñar IIS 7.0, el equipo deseaba garantizar que la transición al mismo fuera lo más fluida posible al permitir el uso de algunas inversiones existentes en scripts y herramientas de administración para IIS 6.0. Se prestó bastante atención a la compatibilidad con versiones anteriores de IIS 7.0 de manera que funcionara con los scripts de IIS 6.0. Hay una gama completa de herramientas, desde la compatibilidad de metabase de IIS 6.0 a la consola real de administración de IIS 6.0, que puede instalar bajo el nodo de compatibilidad de administración de IIS 6.0 durante la instalación.
La infraestructura de compatibilidad de metabase de IIS 6.0 usa un componente llamado ADOMapper. Este permite ejecutar los scripts de metabase de ADSI y ABO de IIS 6.0 en el nuevo sistema de configuración, que queda limitado únicamente a lo que IIS 6.0 podía hacer. Por lo tanto, no puede leer o escribir propiedades nuevas de IIS 7.0, obtener acceso a los nuevos datos de tiempo de ejecución ni leer y escribir propiedades de ASP.NET o archivos web.config.

Solución de problemas y Diagnósticos
La solución de problemas y el diagnóstico son tareas que consumen, desde siempre, bastante tiempo. El estudio de los registros y la reproducción de problemas en una granja amplia de servidores web o incluso en un único servidor pueden ser labores complejas. IIS 7.0 dispone de una herramienta denominada Seguimiento de solicitudes con error para ayudar a mitigar parte de esta complejidad y reducir el tiempo perdido. Puede ser útil en muchas situaciones, incluso cuando una solicitud se bloquea o da lugar a errores, así como para investigar problemas de autorización y autenticación.
El Seguimiento de solicitudes con error usa reglas como criterio para buscar errores. Las reglas de seguimiento pueden crearse para buscar tipos de comportamiento o errores al especificar el tipo de contenido del cual desearía efectuar un seguimiento (todo el contenido del servidor, sólo contenido de ASP.NET o contenido personalizado, como PHP) y bajo qué condiciones debe empezar a efectuarse este seguimiento (un determinado código de estado devuelto, tiempo que se ha tardado en iniciar la página, gravedad del evento o una combinación de todos).
Suponga, por ejemplo, que los usuarios comunican que un sitio tarda mucho en cargarse. Se trata de un escenario difícil de reproducir en cualquier caso, pero especialmente si tiene miles de visitas por hora. Con el Seguimiento de solicitudes con error, simplemente necesita agregar una regla de seguimiento para iniciar el registro cuando una página tarda más del tiempo deseado en cargarse (en este ejemplo, digamos que dos segundos), y esperar a que el servidor reproduzca el problema por su cuenta (consulte la Figura 5).
Figura 5 Uso del seguimiento de solicitudes con error para la solución de problemas
Figura 5 Uso del seguimiento de solicitudes con error para la solución de problemas
La diferencia entre el seguimiento de solicitudes con error y el registro tradicional es que el primero sólo realiza un registro si se detecta un criterio de solicitud con error particular. El mismo archivo de registro es un archivo XML al que se agrega una hoja de estilos XML, lo que potencia su limpieza y la facilidad de lectura. Al igual que la mayoría de las características de IIS 7.0, esta no se encuentra instalada de manera predeterminada y se ubica en la sección de estado y diagnóstico de la instalación. Debe habilitarla también en el Administrador de IIS.
IIS 7.0 supone un gran paso adelante para todos los administradores. Su nueva arquitectura y capacidades ofrecen la agilidad y la flexibilidad necesarias para adaptarse a un entorno siempre variable. Con las características de administración, las herramientas de compatibilidad con versiones anteriores y las capacidades de solución de problemas, está listo para implementarlo hoy mismo y trabajar con su entorno existente.

Isaac Roybal es director de productos de Windows Server en Microsoft. Su responsabilidad abarca todos los aspectos relacionados con la Web y Windows Server. Isaac ha trabajado para Windows Server desde la aparición de Windows NT 3.51 e IIS 4.0. Anteriormente, era director de programas de operaciones para el grupo Office Internet Platform & Operations. Cuenta con certificación MCSE en Windows NT 4.0, Windows 2000 y Windows Server 2003.


 Cobertura especial: Windows Server 2008: Acceso a red basado en directivas con Windows Server 2008
Cobertura especial: Windows Server 2008 Ian Hameroff and Amith Krishnan

Acceso a red basado en directivas con Windows Server 2008
Resumen:
  • Equilibrio de la seguridad y el acceso a redes
  • Enfoque del acceso a redes basado en directivas
  • Nuevas tecnologías de seguridad en Windows Server 2008

Se ha escrito mucho acerca de la desaparición de perímetros de red tradicionales ocasionada por una plantilla cada vez más móvil y la diversidad creciente de usuarios y dispositivos que requieren
acceso a los recursos de TI de la organización. Para aumentar la productividad, los usuarios y los propietarios de línea de negocio semejantes impulsan la demanda de una experiencia de conexión que es al mismo tiempo fluida y libre de procedimientos tediosos. Como complemento a esta situación ya compleja, tenemos la carga cada vez más pesada de cumplimiento de normativas, el cambiante paisaje de amenazas y los riesgos asociados a la descentralización de los datos.
Esto tiende a dejar a los administradores de Windows® justo en medio de un desafiante acto de equilibrio de seguridad: cómo permitir el acceso sencillo a los recursos sin descuidar el cumplimiento de requisitos crecientes de seguridad de la información y la red.
Aunque puede que no haya una única solución a todos estos desafíos, los administradores de Windows tienen varias herramientas a su disposición que pueden ayudar a aumentar los controles de seguridad, como firewalls avanzados, que ya tienen establecidos. Una gran manera de conseguir el equilibrio apropiado entre el acceso y la seguridad es pasar de modelos tradicionales de conectividad a uno que procura definir el acceso a redes de una forma más lógica y centrada en directivas.

Enfoque del acceso a redes basado en directivas
Recursos de funciones de red
  • IPsec
  • Firewall de Windows con Seguridad avanzada
  • Aislamiento de servidor y dominio
  • Protección de acceso a redes (NAP) para Windows Server 2008

El acceso a redes basado en directivas tiene como objeto eliminar las limitaciones que se encuentran al tratar de basar la confianza principalmente en el perímetro de la topología de la red. Por ejemplo, ¿puede determinar realmente que un dispositivo cuenta con la confianza y la autorización necesarias para conectar a los servidores que ejecutan su aplicación de administración de las relaciones con el cliente (CRM) simplemente porque está conectado a uno de sus puertos de conmutador Ethernet detrás del firewall corporativo?
En su lugar, el nuevo modelo fundamenta las decisiones de acceso en la autenticación de la postura de seguridad del dispositivo y la identidad del usuario que solicita el acceso, independientemente de cuál sea el origen de la conexión. Una vez que se ha realizado la autenticación, este mismo marco se puede usar para autorizar la información y los recursos a los que se puede obtener acceso.
El paso de una postura defensiva a otra más centrada en el acceso implica varios ingredientes clave, entre ellos, el establecimiento de mecanismos que pueden validar la identidad y el cumplimiento de directivas de los host que se conectan, emitir una identidad de usuario de confianza y controlar dinámicamente el acceso a redes con base a estos atributos. Para simplificar la administración de estas piezas móviles, un almacén centralizado de directivas también es un componente importante.
La adopción de un enfoque basado en directivas puede ayudar a unir varios controles dispares de seguridad de host y acceso a redes en una solución más completa. Esto, a su vez, permite establecer reglas básicas de acceso a redes en un nivel lógico por encima del tejido de conectividad, lo que lleva a la generación de procedimientos recomendados tradicionales de defensa en profundidad.
Por ejemplo, cuando un usuario conecta un equipo portátil a la red inalámbrica de la organización, se puede comprobar su cumplimiento de los requisitos de configuración de seguridad más recientes. Una vez que se ha determinado que el equipo portátil tiene todas las actualizaciones antivirus actuales y las revisiones de seguridad críticas, y que tiene todos los controles de seguridad de extremos habilitados, como un firewall de host, se puede conceder el acceso a la red corporativa. Entonces, cuando el usuario intenta obtener acceso a una aplicación de negocio, la combinación del estado de mantenimiento del equipo portátil y la identidad de red del usuario se puede usar con el fin de determinar si el usuario está autorizado para conectar a los recursos que hospedan la aplicación. Al operar a este nivel lógico por encima de la infraestructura de red física, las directivas se pueden aplicar continuamente, incluso si el usuario pasa de una conexión inalámbrica a una conectada o incluso a una conexión de acceso remoto.
Con la implementación, el acceso a redes basado en directivas puede proporcionar una experiencia de conexión sin complicaciones a los usuarios, sin sacrificar la seguridad en el proceso. Para los administradores, el aumento del nivel de los controles de acceso a redes a partir de configuraciones de puerta de enlace de acceso remoto o de puertos de conmutador puede ofrecer una experiencia de administración más sencilla. En ambos casos, el resultado final es un incremento de la productividad y una mejora general del estado de la red de la organización, incluso cuando las redes sirven de host a partes con derechos de acceso diferentes, como huéspedes (invitados o de cualquier otro modo), proveedores, partners y empleados.
Como es el caso con cualquier proyecto de seguridad, el primer paso a la hora de implementar el acceso a redes basado en directivas implica el desarrollo de un conjunto de directivas operativas holísticas. Esto incluye normalmente instrucciones para:
  • el cumplimiento de seguridad de dispositivos; ¿qué significa para un dispositivo estar en buen estado?
  • la división en zonas de la red lógica; ¿cómo separará los dispositivos en mal estado de los dispositivos autorizados?
  • la administración de riesgos de información; ¿cómo se clasifican y protegen los datos confidenciales?
Afortunadamente, hay disponible una variedad de recursos de desarrollo de directivas en el Centro de seguridad de TechNet de Microsoft® (microsoft.com/technet/security).
Una vez que ha desarrollado las directivas de acceso, necesitará seleccionar las tecnologías que pueden distribuirlas fácilmente y aplicarlas con eficacia. Para esto, lo que necesita es Windows Server® 2008. Windows Server 2008 no es sólo la versión de Windows Server más segura hasta la fecha sino que, además, ofrece a los administradores una plataforma de seguridad reforzada que puede convertirse en el centro de una solución de acceso a redes basado en directivas. Entre su larga lista de características nuevas y mejoradas, Windows Server 2008 proporciona muchos de los ingredientes necesarios para implementar el acceso seguro y basado en directivas a su red, lo que ayuda a garantizar la protección de la información confidencial ante amenazas.

Funciones de red de siguiente generación
En el centro de los avances de seguridad de red incluidos en Windows Server 2008, se encuentra la pila TCP/IP de siguiente generación, una actualización importante de la funcionalidad de red de la plataforma y los servicios relacionados. Además de proporcionar rendimiento de red mejorado y escalabilidad superior, Windows Server 2008 incrementa la seguridad a través de una serie de características de red integradas que ofrecen una base sólida sobre la que se puede crear una solución de acceso a redes basado en directivas.
El protocolo de seguridad de Internet (IPsec) es una de las características que se han mejorado apreciablemente en Windows Server 2008, y podría desempeñar una función clave en un enfoque de acceso a redes basado en directivas. Pero esto no trata del uso de IPsec como protocolo de tunelización y cifrado, sino de aprovechar sus capacidades de autenticación de red de host a host. Además, como IPsec funciona en el nivel 3, se puede utilizar para aplicar las directivas de acceso a redes en variedad de tipos de red.
Con el fin de facilitar la implementación de los controles de acceso a redes basados en IPsec, Windows Server 2008 introduce una larga lista de mejoras y características nuevas para simplificar la creación, el cumplimiento y el mantenimiento de directivas. Por ejemplo, el número y los tipos de métodos de autenticación de IPsec disponibles han aumentado. Esto se consiguió a través de la introducción de IP autenticado (AuthIP), una extensión del protocolo de Intercambio de claves por red (IKE). AuthIP permite crear reglas de seguridad de conexión (otro nombre para directivas de IPsec en Windows Server 2008) que requieren la autenticación satisfactoria entre sistemas en comunicación al mismo nivel, no sólo con credenciales de equipo sino, opcionalmente, también con credenciales de usuario o de estado. Esta flexibilidad añadida posibilita el diseño de redes lógicas muy sofisticadas sin necesidad de mejorar la infraestructura de conmutación y enrutamiento.

Firewall de Windows con Seguridad avanzada
El nuevo Firewall de Windows con seguridad avanzada se basa en las características de IPsec descritas anteriormente. Al combinar reglas de seguridad de conexión de IPsec con filtros de firewall en una sola directiva, el nuevo Firewall de Windows agrega otra dimensión de acceso a redes basado en directivas: acciones de firewall de autenticación más inteligentes.
Como muestra la Figura 1, ahora tiene tres opciones para elegir al definir la acción específica que un filtro de firewall de entrada o de salida debería realizar: permitir, bloquear o permitir sólo si es seguro. Cuando "Permitir la conexión si es segura" se selecciona como acción, el Firewall de Windows aprovecha las capacidades de autenticación de red de host a host de IPsec para determinar si el host o el usuario que solicitan la conexión deben recibir aprobación con base a la directiva definida. La regla del firewall permite estipular qué usuarios, equipos y grupos tienen derecho de hacer la conexión. Merece la pena tener en cuenta que esto agrega un nivel adicional de protección, lo que sirve de suplemento a los controles de acceso de los niveles de aplicación y de sistema operativo existentes.
Figura 1 Definición de reglas de firewall de autenticación
Figura 1 Definición de reglas de firewall de autenticación
Llegados a este punto, debería ser capaz de ver cómo es posible unir estos controles diferentes de seguridad de red a través de una directiva centralizada para obtener un modo más efectivo y escalable de administrar el acceso a redes.
Volvamos al ejemplo de CRM: el administrador podría crear una regla entrante para los servidores que ejecutan la aplicación CRM de la compañía (a través de los puertos de servicio o del archivo ejecutable del programa) con la opción "Permitir la conexión si es segura" activada. Dentro de la misma directiva de firewall, el administrador puede especificar que sólo miembros del grupo "Usuarios de la aplicación CRM" pueden conectar a esta aplicación de red, como muestra la Figura 2. Si toma este mismo concepto y lo amplía para abarcar todas las comunicaciones de red entre todos los equipos administrados en su red, habrá agregado un nivel de Aislamiento de servidor y dominio a su estrategia de acceso a redes basado en directivas.
Figura 2 Los administradores pueden especificar quién se puede conectar según esta directiva.
Figura 2 Los administradores pueden especificar quién se puede conectar según esta directiva.

Aislamiento de servidor y dominio
La mayoría de las organizaciones experimentan la conexión en sus redes de un número creciente de invitados y otros dispositivos no administrados, por lo que contar con la capacidad de separar y proteger sus host de confianza se ha convertido en algo crítico. La buena noticia es que hay muchas maneras de aislar los equipos de confianza y administrados de los otros en la red. Sin embargo, deberá tener en cuenta que muchas de estas opciones son costosas (por ejemplo, se requieren sistemas separados de cableado físico) y difícil de mantener (por ejemplo, VLAN basadas en conmutación) al tiempo que crecen las redes.
El Aislamiento de servidor y dominio puede ofrecer un método más rentable y fácil de administrar para dividir su entorno en redes seguras y lógicamente aisladas. Como muestra la Figura 3, usa esencialmente las mismas reglas de seguridad de la conexión (es decir, las directivas de IPsec) mencionadas anteriormente, pero deberá asignarlas a todos los equipos administrados mediante la Directiva de grupo de Active Directory®. Esto tiene como resultado una directiva de acceso a redes que requiere la autenticación correcta entre todos los sistemas al mismo nivel antes de que empiece cualquier comunicación. Como este aislamiento se da en el nivel 3, la aplicación de estos controles de acceso abarca concentradores, conmutadores y enrutadores en límites físicos y geográficos.
Figura 3 Definición de requisitos de autenticación para cubrir las necesidades de acceso a red
Figura 3 Definición de requisitos de autenticación para cubrir las necesidades de acceso a red
Para crear una red aislada, los equipos en la red deben estar separados según el tipo de acceso deseado. Se pueden definir directivas de forma que los equipos en una red aislada puedan iniciar comunicaciones con todos los equipos en la red, incluidos los que no se encuentran en la red aislada. A la inversa, los equipos que no están en la red aislada no pueden iniciar comunicaciones con equipos que están en la red aislada. De hecho, los equipos en la red aislada omitirán todas las solicitudes de comunicación de equipos fuera de la red aislada.
La pertenencia a dominios y un dominio de Active Directory se usan para aplicar la directiva de la red. Los equipos miembros del dominio sólo aceptan comunicaciones autenticadas y seguras de otros equipos miembros del dominio. Opcionalmente, también se puede exigir el cifrado de toda comunicación dentro del dominio aislado.
El Aislamiento de servidor y dominio ofrece ventajas económicas considerables, ya que no se requieren cambios importantes en la infraestructura existente de la red ni en las aplicaciones. Esta solución crea un velo de protección habilitado por directivas que no sólo proporciona protección contra ataques costosos de red y acceso no autorizado a recursos de red de confianza, sino que tampoco requiere el mantenimiento continuado basado en cambios en la topología de la red.

Protección de acceso a redes
Como hemos descrito anteriormente, la solución de Aislamiento de servidor y dominio garantiza la separación lógica de los equipos y los servidores en la red. Aunque esta solución ayuda a evitar el acceso no autorizado a la red, no hay garantía de que un equipo autorizado no será la causa de una amenaza de seguridad.
La Protección de acceso a redes (NAP) es una plataforma integrada en Windows Server 2008 que ayuda a garantizar que los equipos que conectan a una red o que se comunican en una red cumplen los requisitos de estado del sistema (es decir, cumplimiento de seguridad y directivas) tal y como lo ha definido.
Incluso los usuarios autorizados son a menudo responsables de propagar virus y spyware en la red. Por ejemplo, cuando un usuario se va de vacaciones, su equipo podría dejar de cumplir los requisitos de seguridad establecidos por el administrador. Esto podría tener repercusiones potencialmente graves si las revisiones o las firmas emitidas durante la ausencia del usuario no se aplican al equipo.
No es posible para un administrador realizar el seguimiento de cada usuario que se conecta a la red. Lo que se necesita es una herramienta automatizada que compruebe el cumplimiento del estado de cada equipo que se conecta a la red y que resuelva la situación al detectar equipos que no cumplen los requisitos, todo ello con base a una directiva central. NAP hace exactamente eso, y agrega otro nivel a su solución de acceso a redes basado en directivas.
El agente NAP, integrado en el sistema operativo del equipo cliente (como en Windows Vista®) o de instalación por separado (para versiones anteriores de Windows y sistemas operativos ajenos a Windows), informa de cualquier problema de cumplimiento al Servidor de directivas de redes (NPS), que es el motor de directivas integrado en Windows Server 2008. Es en el NPS donde se definen las directivas de cumplimiento que cada dispositivo debe observar.
Aunque es necesario restringir dispositivos que no superan comprobaciones de cumplimiento, es importante garantizar que tienen la opción de entrar en cuarentena y actualizarse. NAP ofrece la opción de actualizar automáticamente el dispositivo en los casos en que el firewall o la solución antivirus están activados o actualizarlo manualmente al colocarlo en cuarentena. Aquí, el dispositivo tiene acceso a un servidor de actualización con las últimas revisiones, actualizaciones y firmas. Una vez que el usuario actualiza manualmente el dispositivo, se le concede acceso a la red, siempre que supere antes la comprobación del cumplimiento.
Con este grado de ubicuidad, el acceso a redes es ahora mucho más sencillo. Sin embargo, esto ha creado la carga añadida de comprobar que los dispositivos están en buen estado y se presentan en conformidad sin tomar en consideración el mecanismo de acceso. Los equipos pueden obtener acceso a la red a través de un punto de acceso inalámbrico o un conmutador compatible con 802.1X, o pueden realizar la conexión de forma remota desde casa con una conexión de acceso remoto basada en VPN o en Terminal Services. NAP no sólo garantiza el cumplimiento en equipos que conectan a través de estos mecanismos diferentes, sino que también ofrece la aplicación de requisitos en el servidor DHCP, el conmutador 802.1X, la puerta de enlace VPN, la puerta de enlace de Terminal Services o el punto de acceso inalámbrico compatible con 802.1X.
En la Figura 4, se ha aislado la red mediante la solución de Aislamiento de servidor y dominio. El uso de NAP con esta red aislada ofrece ventajas adicionales para garantizar el cumplimiento de los requisitos de estado de los equipos que se conectan a la red. El cliente, al inicio, envía su informe de mantenimiento (SoH) a la Autoridad de registro de mantenimiento (HRA), que es un servidor de certificados. La HRA pasa el informe de mantenimiento al Servidor de directivas de redes para la validación de directivas. Si el informe de mantenimiento es válido, la HRA emite un certificado de mantenimiento para el cliente de NAP y, ahora, el cliente puede iniciar la comunicación segura basada en IPsec con recursos seguros. Si el informe de mantenimiento no es válido, la HRA indica al cliente de NAP cómo corregir su estado y no emite un certificado de mantenimiento. El cliente de NAP no podrá iniciar la comunicación con otros equipos que requieren un certificado de mantenimiento para la autenticación de IPsec. Sin embargo, el cliente de NAP podrá comunicarse con el servidor de actualizaciones para lograr el cumplimiento.
Figura 4 Protección de acceso a redes que usa IPsec para la aplicación de requisitos
Figura 4 Protección de acceso a redes que usa IPsec para la aplicación de requisitos

En resumen
Aunque sólo hemos tratado las características y las funciones nuevas de Windows Server 2008 en superficie, es importante comprender el modo en que cada componente ha avanzado con respecto a la versión anterior. Lo que distingue esta estrategia del enfoque tradicional de defensa en profundidad es el marco subyacente de directivas que Windows Server 2008 ofrece a través de, por ejemplo, la Directiva de grupo de Active Directory.
Gracias a esta experiencia integrada, tendrá una base de trabajo sólida para definir e implementar una solución de acceso a redes basado en directivas sin tener que eliminar inversiones existentes. Al elevar la decisión de acceso a un nivel más lógico y centrado en directivas, tiene la oportunidad de inclinar a su favor el acto de equilibrio entre "acceso fácil" y "seguridad incrementada".
Microsoft ha publicado gran cantidad de material donde se describen en detalle las áreas de tecnología mencionadas en este artículo. Recomendamos que revise primero estos artículos y guías paso a paso para obtener experiencia operativa con las diferentes características. Los vínculos en la barra lateral "Recursos de funciones de red" le ayudarán a empezar. Después, considere implantar cada fase de manera que ofrezca una base sólida para la fase siguiente.
Por ejemplo, cree un conjunto de reglas de firewall de autenticación para las aplicaciones críticas, como se plantea en la sección Firewall de Windows con seguridad avanzada. Una vez que esté satisfecho con esto, puede ampliar las reglas de seguridad de conexión para aislar su dominio de red y, luego, colocar NAP por encima en el nivel siguiente. Las ventajas de implementar una estrategia de acceso a redes basado en directivas pueden ser considerables, por ejemplo, le ayudarán a mantenerse al día con el mundo tan cambiante que son nuestras redes corporativas.

Ian Hameroff es director de productos en el grupo Marketing de productos de acceso y seguridad en Microsoft. Es responsable de la administración y el marketing de productos de las tecnologías de red para la plataforma Windows Server. Ian se encarga de la estrategia de comercialización para las tecnologías de red de Windows Server y las soluciones centradas en iniciativas de red y seguridad clave, como el aislamiento de servidor y dominio, funciones de red escalables y la adopción de IPv6.
Amith Krishnan es director de productos en el grupo Marketing de productos de acceso y seguridad en Microsoft y participa en el marketing y la administración de productos para iniciativas de red y seguridad de Windows Server, como la protección de acceso a redes y conexiones inalámbricas seguras. Se encarga también de desarrollar la estrategia de comercialización y de propagar el conocimiento de estas soluciones.


 Cobertura especial: Windows Server 2008: Configuraci&#243;n de funciones con el Administrador de servidores
Cobertura especial: Windows Server 2008 Byron Hynes

Configuración de funciones con el Administrador de servidores
Resumen:
  • Diferencia entre funciones y características
  • Usos del Administrador de servidores
  • Trabajo con asistentes
  • Administración de funciones y características desde la línea de comandos

Uno de los temas recurrentes en Windows Server 2008 parece ser que menos es más. No me refiero a la idea de eliminar innecesariamente características. Me refiero a la estrategia de simplificar y clarificar funciones y herramientas para que pueda instalar exactamente lo que necesita, y nada más. El Administrador de servidores
es una parte importante de este concepto en Windows Server® 2008.
Hay dos aspectos en este sentido. El primero es el concepto de crucial importancia de características y funciones de servidor, que son los bloques de creación de Windows Server 2008. El segundo es la propia herramienta Administrador de servidores. Esta herramienta no sólo reemplaza varias herramientas usadas en Windows Server 2003, sino que concentra mucha más funcionalidad en un mismo lugar para que los administradores, siempre tan ocupados, puedan hacer más de forma más rápida y sencilla.

Funciones y características
Si ha leído material acerca de Windows Server 2008, probablemente habrá encontrado algunos términos que no ha oído en el contexto de Windows® con anterioridad, tales como "cargas de trabajo" y "funciones". Empezaré por explicar lo que significan estos términos para los profesionales de TI.
Al principio del ciclo de desarrollo de Windows Server 2008, empleamos mucho tiempo en averiguar exactamente el modo en que los usuarios usan nuestros productos de servidor. Este esfuerzo continúa, por cierto. En general, encontramos que las personas implementan nuestros servidores para hacer cosas específicas. Esto quizás parezca obvio, pero fue una gran revelación para algunos de nosotros aprender que los usuarios no compran nuestros servidores simplemente para tener un servidor. Lo que es más importante, no implementan servidores para realizar tareas innumerables. En lugar de esto, quieren un servidor para hacer algo específico. Por supuesto, hay excepciones pero, en la mayoría de los casos, se aprovisiona un servidor para realizar una función particular.
En respuesta a estas revelaciones, agrupamos las "cosas particulares" en clasificaciones amplias, llamadas cargas de trabajo. Por ejemplo, hay una carga de trabajo de base de datos y una carga de trabajo de servidor de aplicaciones. Como las cargas de trabajo son amplias y a veces un poco imprecisas, creamos subcategorías dentro de las cargas de trabajo llamadas funciones. Una función es una sola cosa muy específica que se espera que haga un servidor. Piense cómo se refieren a los servidores en su red los usuarios de la organización. Si es el caso de la mayoría de los usuarios, seguramente se piensa en ellos como servidor de archivos, controlador del dominio, servidor de impresión, servidor web, etc. Como este es el modo en que las personas tienden a pensar en los servidores, Windows Server 2008 toma el mismo enfoque para tratar con funciones.
En líneas generales, hay tres categorías principales de funciones en Windows Server 2008: Administración de acceso e identidades (funciones consideradas parte de Active Directory®), infraestructura (esto incluye servidores de archivos, servidores de impresión, DNS, etc) y aplicación (por ejemplo, la función de servidor web y Terminal Services).
Hay unas 17 funciones de servidor que se incluirán con Windows Server 2008 (funciones como Servicios de certificados de Active Directory, Servicios de acceso y directivas de redes y Administrador de virtualización de Windows Server). Y funciones adicionales, como Servicios de multimedia de transmisión por secuencias, estarán disponibles para la descarga.
Cada función merece realmente su propio artículo. Algunas de ellas se tratan con más detalle en esta edición de TechNet Magazine, otras ya las hemos visto anteriormente y otras están todavía por venir. Debería explorar cada una de ellas; comience con la información disponible en technet2.microsoft.com/windowsserver2008/en/servermanager/default.mspx.
Al iniciar la implementación de Windows Server 2008, necesita elegir las funciones que se instalarán en cada servidor. Esta implementación basada en funciones es un concepto importante para usar de forma eficaz Windows Server 2008 y contar con agilidad al implementar los recursos.
La lista de funciones no incluye cosas como el cifrado de unidad BitlockerTM o el equilibrio de carga de red (NLB). Esto se debe a que estas son características y, aunque deseables, no son cosas que llevan a los usuarios a comprar un sistema. Las funciones, por otro lado, representan tareas cuya realización específica asignamos a un sistema adquirido con este propósito. Por ejemplo, los usuarios no compran servidores para implementar el equilibrio de carga. Sin embargo, compran servidores para servir un sitio web. Y, aunque NLB puede ser un aspecto esencial de, por ejemplo, un servidor web, no es la causa de la existencia del servidor.
En lugar de tener todas las características del servidor instaladas y activas, el administrador elige qué características necesitan instalarse. La lista de características incluidas con Windows Server 2008 se muestra en la Figura 1. Al incluir sólo las funciones y las características necesarias, mejoran la estabilidad y la seguridad. No tiene que preocuparse por el consumo de recursos por parte de las características o las funciones que no están instaladas. Y no tiene que preocuparse por resolver problemas relacionados con las características o las funciones que no están instaladas.
Figure 1 Características incluidas en Windows Server 2008 (Close Figure 1)

Características de Microsoft .NET Framework 3.0
Cifrado de unidad BitLocker
Extensiones de Servidor BITS
Kit de administración de Connection Manager
Experiencia de escritorio
Administración de directivas de grupo
Cliente de impresión en Internet
Servidor de nombres de almacenamiento de Internet (iSNS)
Monitor de puerto de LPR
Message Queue Server
E/S de múltiples rutas
Protocolo de resolución de nombres de mismo nivel
Experiencia de calidad de audio y vídeo de Windows (qWave)
Asistencia remota
Herramientas de administración remota del servidor
Administrador de almacenamiento extraíble
RPC sobre el proxy HTTP
Servicios para NFS
Servidor SMTP
Administrador de almacenamiento para redes SAN
Servicios simples de TCP/IP
Servicios SNMP
Subsistema para aplicaciones UNIX
Cliente Telnet
Servidor Telnet
Cliente del Protocolo trivial de transferencia de archivos (TFTP)
Clúster de conmutación por error
Equilibrio de carga de red
Copias de seguridad de Windows Server
Administrador de recursos del sistema de Windows
Servidor del Servicio de nombres Internet de Windows (WINS)
Servicio WLAN
Windows Internal Database
Windows PowerShell
Servicio WAS (Windows Process Activation Service)
La representación perfecta de este concepto es la opción de instalación de Server Core. Server Core va más allá del ámbito de este artículo, pero puede ver la extensión lógica de tomar funciones y características no utilizadas y ni tan siquiera copiarlas en el disco duro o presentarlas como disponibles. Una diferencia clave entre una instalación normal y una instalación de Server Core es que una instalación normal incluye los recursos requeridos para instalar funciones adicionales en cualquier momento, y es compatible con todas las funciones. Server Core, sin embargo, ni siquiera tiene una GUI para su shell, y sólo es compatible con un número limitado de funciones.

Administrador de servidores
La nueva consola del Administrador de servidores en Windows Server 2008 simplifica la administración y la protección de varias funciones de servidor en una empresa. En esencia, el Administrador de servidores es una Consola de administración de Microsoft® (MMC) ampliada, y permite ver y administrar virtualmente toda la información y las herramientas que afectan a la productividad del servidor. Ofrece un solo origen para administrar la identidad y la información de sistema del servidor, y muestra el estado del servidor, identifica problemas con la configuración de funciones del servidor y administra todas las funciones instaladas en el servidor. Tenga en cuenta que, además, reemplaza varias características incluidas con Windows Server 2003, como Administre su servidor, Configure su servidor y Agregar o quitar componentes de Windows.
En algunos casos, el Administrador de servidores puede reducir la necesidad de ejecutar el Asistente para configuración de seguridad (SCW) antes de implementar servidores. El Administrador de servidores configurará su servidor para que las funciones instaladas sean funcionales, por ejemplo, al configurar automáticamente el Firewall de Windows. No obstante, en situaciones en que se han agregado funciones y luego se han quitado, o cuando se desea tener más control sobre parámetros de seguridad concretos, SCW es una herramienta valiosa. Para obtener más información, consulte la columna Vigilancia de seguridad de Jesper Johansson, "Uso de SCW en Windows Server 2008" en este número (microsoft.com/technet/technetmag/issues/2008/03).
Durante el desarrollo de Windows Server 2008, consideramos detenidamente el modo en que esperábamos que los administradores realizaran tareas. Encontramos maneras en que herramientas y asistentes simplificaban el trabajo, y encontramos casos que requerían cambiar de herramienta demasiadas veces. Establecimos un objetivo de diseño importante para Windows Server 2008 en general, y para el Administrador de servidores en particular, con el fin de dotar de eficacia a la administración de servidores al permitir a los administradores realizar muchos tipos de tareas en un mismo lugar. Como resultado, con el Administrador de servidores, puede:
  • ver y modificar las funciones y las características de servidor instaladas en el servidor.
  • realizar tareas de administración que conciernen al servidor, como iniciar y detener servicios, y administrar cuentas de usuario locales.
  • realizar tareas de administración que conciernen a las funciones instaladas en el servidor.
  • comprobar el estado del servidor, identificar eventos críticos y analizar problemas de configuración.
  • instalar o quitar funciones, servicios de función y características que usan una GUI o una línea de comandos.
La Consola del Administrador de servidores presenta mucha información y funcionalidad en un espacio muy reducido. La Figura 2 muestra la Consola del Administrador de servidores en el nodo de función Servicios de archivo. La ventana principal de la consola contiene cuatro secciones contraíbles: Resumen de servidores, Resumen de funciones, Resumen de características y Recursos y soporte técnico.
Figura 2 Consola del Administrador de servidores con la función Servicios de archivo
Figura 2 Consola del Administrador de servidores con la función Servicios de archivo
La sección Resumen de servidores incluye dos subsecciones: Información del equipo e Información de seguridad. La subsección Información del equipo muestra el nombre del equipo, el dominio, el nombre de la cuenta del administrador local, las conexiones de red y el identificador del producto del sistema operativo. También puede usar comandos aquí para editar esta información. La subsección Información de seguridad muestra si se han habilitado las opciones de actualizaciones automáticas de Windows y el Firewall de Windows, y si la Configuración de seguridad mejorada (ESC) de Internet Explorer® está activada (para administradores o para otros usuarios). De forma similar, hay comandos disponibles para editar estos parámetros y ver todas las opciones avanzadas.
La sección Resumen de funciones contiene una tabla que indica qué funciones están instaladas en el servidor. Los comandos de esta sección permiten agregar o quitar funciones, o ir a una consola más detallada que permite administrar las funciones individuales.
La sección Resumen de características contiene una tabla que indica qué características están instaladas en el servidor. Aquí, como es de esperar, puede agregar y quitar características.
Finalmente, la sección Recursos y soporte técnico indica si el servidor participa en el Programa para la mejora de la experiencia del usuario y el Informe de errores de Windows, y permite configurar la participación del servidor en programas de contribución de comentarios. También puede localizar rápidamente temas relacionados de ayuda e investigación adicionales en los TechCenters de Windows Server y las bibliotecas técnicas.

Información de funciones
Cada función instalada tiene su propia página principal dentro del Administrador de servidores. Para cada una de estas páginas principales de función, la sección Recursos y soporte técnico ofrece un menú de configuraciones recomendadas o situaciones de aplicación de la función o de partes de la función. Cada configuración recomendada está asociada a una lista de comprobación de ayuda que le guía por las tareas que necesita realizar con el fin de crear la mejor experiencia para la función dada.
Una cosa especialmente buena del Administrador de servidores es que agrupa información y comandos importantes, y los coloca justo donde se necesitan. Por ejemplo, en la página principal de la función Servicios de archivo, vemos inmediatamente los eventos relacionados con esta función, sin tener que iniciar el Visor de eventos y crear un filtro.
Sin embargo, algunas funciones pueden generar cientos de eventos, de forma que también podrá crear filtros personalizados desde la página principal de la función. Puede elegir Filtrar eventos en el menú lateral y restringir aún más los eventos que se muestran. Este cuadro de diálogo no ofrece todas las opciones de filtrado disponibles en el visor de registro de eventos, pero permite ver rápidamente sólo los eventos relacionados con esta función particular y no hay que preocuparse por filtrar los otros.
Igualmente, puede ver el estado de los servicios del sistema (servicios requeridos por esta función, pero que forman parte del sistema general) y de los servicios de la función (específicos a esta función). Para algunas funciones, es posible elegir qué partes de una función estarán disponibles y se instalarán diferentes servicios de la función en consonancia. Directamente desde la página principal de la función, puede iniciar y detener servicios, así como especificar qué servicios deberían supervisarse como servicios del sistema para la función.

Trabajo con asistentes
Un asistente bien diseñado puede ahorrarle tiempo y evitar errores, especialmente al tratar con tareas que sólo se realizan ocasionalmente. Versiones anteriores de Windows Server requerían usar Configure su servidor, Administre su servidor y Agregar o quitar componentes de Windows para cambiar los componentes instalados en el servidor. Las comprobaciones de dependencias eran limitadas, y Agregar o quitar componentes de Windows exigía que se completara la instalación de una función antes de agregar otra.
Ahora, con los asistentes del Administrador de servidores, puede instalar o quitar varias funciones, varios servicios de función y varias características en una misma sesión. Pero, lo que es más importante, las comprobaciones de dependencias se realizan durante el uso de los asistentes del Administrador de servidores, lo que garantiza que las funciones y los servicios de función que se necesitan se han instalado. Y las funciones se configuran con la configuración de seguridad recomendada de forma predeterminada; sin embargo, puede usar el Asistente para configuración de seguridad si desea modificar los parámetros de seguridad. Puede tener su servidor completamente listo para la implementación tras una sola sesión en uno de los asistentes del Administrador de servidores.
El Administrador de servidores contiene varios asistentes, entre ellos, el Asistente para agregar funciones, el Asistente para agregar servicios de funciones, el Asistente para agregar características, el Asistente para quitar funciones, el Asistente para quitar servicios de funciones y el Asistente para quitar características.
El Asistente para agregar funciones, que, como habrá adivinado, se usa para agregar funciones al servidor, comprueba automáticamente las dependencias entre funciones, y se asegura de que todas las funciones y los servicios de función que se necesitan se han instalado para cada función seleccionada. Para algunas funciones, como Terminal Services y Servicios de certificados de Active Directory, el Asistente para agregar funciones ofrece también páginas de configuración que permiten al usuario especificar cómo se debe configurar la función como parte del proceso de instalación. La Figura 3 muestra la página Seleccionar funciones de servidor del Asistente para agregar funciones.
Figura 3 Uso del Asistente para agregar funciones para seleccionar funciones de servidor
Figura 3 Uso del Asistente para agregar funciones para seleccionar funciones de servidor
La mayoría de las funciones se componen de varios subelementos, a los que el Administrador de servidores llama servicios de función. Una vez que se ha instalado una función compleja, puede usar el Asistente para agregar servicios de funciones con el fin de agregar servicios de función a la función.
De forma similar al Asistente para agregar funciones, el Asistente para agregar características permite instalar características. Puede agregar una o más características al sistema en una sola sesión.
El Asistente para quitar funciones, como su nombre implica, permite quitar funciones de un servidor. El asistente comprueba automáticamente las dependencias para asegurarse de que no se quitan las funciones ni los servicios de función que se necesitan. También puede quitar servicios de una función instalada con el Asistente para quitar servicios de funciones. Mientras tanto, el Asistente para quitar características permite quitar características del sistema.

La línea de comandos
En ocasiones, encuentro a un profesional de TI que odia los asistentes. Aunque son pocos los profesionales de TI con opiniones tan demarcadas, a muchos de ellos les gusta contar con la opción de usar una línea de comandos. Puede ser más cómodo, y posibilita el scripting y la repetición sin complejidades. El Administrador de servidores ofrece una herramienta de línea de comandos, ServerManagerCmd.exe, que es notablemente más fácil de usar que las herramientas anteriores ocsetup y pkgmgr. Puede usar ServerManagerCmd.exe para instalar y quitar funciones, servicios de función y características. Y se utilizan parámetros sencillos para mostrar una lista de todas las funciones, los servicios de función y las características, tanto de los elementos instalados como de aquellos disponibles para la instalación.
Cómodamente, esta línea de comandos permite instalar y quitar funciones, servicios de función y características de forma desatendida. También puede usar la línea de comandos para instalar o quitar una sola función, un único servicio de función o una característica en una instancia de comando, o puede usar un archivo de respuesta XML con el comando Administrador de servidores para agregar o quitar varias funciones, varios servicios de función y varias características en una sola instancia de comando. Es posible ver registros de operaciones y ejecutar consultas para mostrar listas de funciones, servicios de función y características que se han instalado y que están disponibles para la instalación.
Un aspecto destacado de esta herramienta de línea de comandos es el parámetro –whatif, que permite ver exactamente los cambios que se aplicarían al servidor si se instalase una función específica. Por ejemplo, la Figura 4 muestra los resultados de ejecutar el comando siguiente:
ServerManagerCmd -install Web-Server
-allsubfeatures -whatif
Obviamente, puede guardar estos resultados en un archivo para el análisis posterior.
Figura 4 Uso del parámetro –whatif para ver los cambios que se aplicarían al servidor
Figura 4 Uso del parámetro –whatif para ver los cambios que se aplicarían al servidor
Para un estudio más exhaustivo de los detalles y la sintaxis de ServerManagerCmd.exe, consulte el "Apéndice de descripción técnica del Administrador de servidores" disponible en go.microsoft.com/fwlink/?LinkId=107113.
Mi agradecimiento a Gaby Kaplan por su colaboración en este artículo.

Byron Hynes es estratega de tecnología empresarial en el Grupo de partners y empresas en Microsoft. Anteriormente, trabajó en la división de Windows Server, y también como asesor e instructor. Puede ponerse en contacto con él en la dirección bhynes@microsoft.com.


 Cobertura especial: Windows Server 2008: Implementaci&#243;n de Windows Server 2008 con System Center
Cobertura especial: Windows Server 2008 Tim Mintner

Implementación de Windows Server 2008 con System Center
Resumen:
  • Características de implementación de Configuration Manager
  • Creación y personalización de secuencias de tareas de servidor
  • Adición de funciones de servidor
  • Configuración de variables específicas de equipo

Con el lanzamiento de System Center Configuration Manager 2007, los administradores de servidores pueden ahora aprovechar las mismas herramientas de implementación de sistema operativo que los administradores de clientes
han usado durante años. En el pasado, los administradores de servidores solían realizar instalaciones manuales de Windows Server® mediante el CD o el DVD y, a continuación, empleaban horas en la configuración del servidor. Algunos administradores fueron un paso más adelante y crearon rutinas de instalación desatendidas mediante la creación de un archivo unattend.txt, además de usar quizás Servicios de instalación remota (RIS) para automatizar el proceso de instalación y evitar tener que estar presente físicamente en la consola de servidor. Los administradores más avanzados aprovecharon los Servicios de implementación automatizada (ADS) para Windows Server 2003 con el objeto de automatizar completamente todo el proceso de creación del servidor. Hoy en día, con Windows Server 2008, el proceso de instalación de servidores ha cambiado sustancialmente por primera vez desde Windows NT® 4.0.
La implementación de Windows Server 2008 usa las mismas herramientas y tecnologías de implementación que Windows Vista®. Debido a este cambio, las herramientas que los administradores de servidores han usado en el pasado deberán actualizarse o reemplazarse. RIS se ha reemplazado por los Servicios de implementación de Windows® (WDS) y ADS no es compatible con la implementación de Windows Server 2008. Para obtener más información acerca de las tecnologías y las herramientas que han cambiado con la implementación de servidor y cliente, consulte "10 cosas que debe conocer acerca de la implementación de Windows Vista" en technetmagazine.com/ issues/2006/11/Deployment.
Puesto que las tecnologías subyacentes para implementar Windows Server 2008 y Windows Vista son las mismas, ¿no sería estupendo si pudiera usar las mismas herramientas y sacar provecho del mismo conocimiento para la implementación de ambos? System Center Configuration Manager y Microsoft® Deployment ofrecen ahora este conjunto de herramientas integrado. Este artículo describe cómo puede usar Configuration Manager junto con Microsoft Deployment para empezar a implementar Windows Server 2008.

Implementación del SO con Configuration Manager
Antes de comenzar a implementar Windows Server 2008, revisemos las características de implementación del sistema operativo de Configuration Manager. Al iniciar la Consola de Configuration Manager, si va a Administración de equipos, observará una nueva área de aterrizaje para la implementación del sistema operativo, tal como se muestra en la Figura 1.
Figura 1 La página de implementación del sistema operativo
Figura 1 La página de implementación del sistema operativo
En esta página, puede ver un resumen rápido de las implementaciones del sistema operativo que han tenido lugar en su entorno y puede navegar a otros nodos de implementación de sistema operativo, como Administrar secuencias de tareas y Administrar imágenes de arranque. Encontrará una lista de informes web para ver el estado de las implementaciones, así como el estado del entorno de implementación. Hay también una referencia de ayuda rápida en la sección de recursos con vínculos a la documentación de ayuda para la implementación de sistemas operativos.
Debajo de los nodos en el panel de navegación, puede ver todos los elementos que deben configurarse para realizar una implementación de sistema operativo. Este es un resumen de estos elementos:
Imágenes de arranque Contiene una lista de imágenes de arranque basadas en Windows PE 2.0 que se usarán durante el proceso de implementación.
Asociaciones de equipo Se usa principalmente para implementaciones de cliente con el objeto de asignar un equipo existente a otro nuevo de manera que el estado de usuario pueda administrarse de forma segura. Contiene también un asistente para importar cuentas de equipo desconocidas a la base de datos de Configuration Manager para que sea posible implementar servidores completos.
Imágenes del sistema operativo Contiene una lista de los paquetes con imágenes personalizadas WIM para la implementación de servidor y cliente.
Paquetes de instalación del sistema operativo Aloja paquetes que contienen el conjunto completo de archivos de origen para una implementación de sistema operativo, como los archivos de origen para Windows Server 2008.
Secuencias de tareas Contiene varios pasos, cada uno de los cuales define qué acciones de línea de comandos se ejecutarán sin la interacción del usuario. Las secuencias de tareas son el motor del proceso de implementación de sistema operativo, y pueden ofrecer todos los pasos necesarios para implementar y configurar un sistema operativo.
Controladores Se trata de un repositorio central donde se administran todos los controladores necesarios para los distintos modelos de equipos de servidor y equipos cliente.
Paquetes de controladores Contiene uno o más conjuntos de controladores que se pueden distribuir a puntos de distribución de Configuration Manager y se usan durante la implementación de equipos de servidor o equipos cliente.
Ahora que disponemos de un conocimiento básico de las características de implementación de sistema operativo de Configuration Manager, reunamos todas las partes que necesitamos para llevar a cabo una implementación de Windows Server 2008.

Preparación para implementar Windows Server 2008
¿Qué es Microsoft Deployment?
Microsoft Deployment es la siguiente versión de Business Desktop Deployment (BDD) 2007. Reúne las herramientas y los procesos necesarios para la implementación de escritorios y servidores en una consola de implementación y una serie de materiales de orientación comunes. El producto agrega nuevas capacidades de implementación y secuencias de tareas para escritorios y servidores que usan System Center Configuration Manager 2007.
Microsoft Deployment está disponible en el Centro de descarga Microsoft y los materiales de orientación se pueden leer en línea en los TechCenters de Implementación de escritorio e Implementación de servidor de Microsoft TechNet. Para obtener más información y vínculos a estos destinos y otro contenido relacionado, visite microsoft.com/deployment.

Para implementar Windows Server 2008 con Configuration Manager, necesita los siguientes elementos:
Microsoft Deployment Toolkit (MDT) Proporciona herramientas y documentación de procedimientos recomendados para implementar sistemas operativos de servidor y de cliente. Se integra directamente con la Consola de Configuration Manager para simplificar el proceso de implementación. Puede descargar Microsoft Deployment Toolkit de microsoft.com/deployment.
Imagen de arranque personalizada Configuration Manager proporciona imágenes de arranque de 32 bits y 64 bits que se basan en Windows PE 2.0 e incluye compatibilidad con VBScript, Instrumental de administración de Windows (WMI) y aplicaciones HTML (HTA). Sin embargo, si desea que su proceso de implementación solicite información de una base de datos independiente de SQL Server®, necesitará una imagen de arranque personalizada que sea compatible con ADO.
Paquete de instalación de sistema operativo Contiene los archivos de origen del DVD de Windows Server 2008.
Paquete de MDT Contiene todos los scripts y los archivos auxiliares necesarios para Microsoft Deployment Toolkit.
Paquete de cliente de Configuration Manager Contiene los archivos de instalación para el cliente de Configuration Manager.
Paquete de configuración Contiene el archivo unattend.xml usado para una instalación automatizada de Windows Server 2008, así como el archivo customsettings.ini usado con Microsoft Deployment Toolkit.
Paquete de Sysprep Se usa sólo para implementar Windows Server 2003 o Windows XP, y proporciona los archivos sysprep necesarios en la preparación de un equipo para capturar una imagen de sistema operativo.
Controladores Contiene todos los controladores necesarios para modelos específicos de servidores.
Recursos compartidos de red para orígenes de paquetes y capturas de WIM Las ubicaciones UNC (convención de nomenclatura universal) en las que se almacenarán los paquetes indicados anteriormente junto a la imagen de WIM personalizada.
Puede parecer que es mucho el trabajo necesario para crear todos estos paquetes. La buena noticia es que, con Microsoft Deployment Toolkit, un asistente se encargará de crear todos los paquetes.
Con el objeto de usar Microsoft Deployment Toolkit con Configuration Manager, debe instalarlo en el mismo equipo que la consola de administración de Configuration Manager. Una vez que haya hecho esto, vaya a Inicio | Todos los programas | Microsoft Deployment Toolkit y seleccione Configure ConfigMgr Integration, para configurar la integración de ConfigMgr. A continuación, especifique el nombre de su servidor de sitio de Configuration Manager y el código del sitio, y haga clic en Siguiente. Esto agrega extensiones a la Consola de Configuration Manager proporcionada por Microsoft Deployment Toolkit. Ahora, cuando inicie la Consola de Configuration Manager y haga clic con el botón secundario en Secuencias de tareas, podrá ver una nueva opción, tal como se muestra en la Figura 2.
Figura 2 Importación de secuencia de tareas de Microsoft Deployment
Figura 2 Importación de secuencia de tareas de Microsoft Deployment
Seleccione Importar secuencia de tareas de Microsoft Deployment y siga los pasos a continuación para crear los paquetes necesarios y la secuencia de tareas de Windows Server 2008:
  1. En la pantalla Elegir plantilla, seleccione Secuencia de tareas de servidor y, a continuación, haga clic en Siguiente.
  2. Proporcione un nombre a la secuencia de tareas, así como comentarios que la describan y, a continuación, haga clic en Siguiente.
  3. Rellene los detalles para la unión a un dominio o un grupo de trabajo, incluidas las credenciales de cuenta de usuario para unir el servidor al dominio. Rellene la información de su organización y la clave del producto, y proporcione una ruta de acceso UNC y un nombre de archivo para la captura de la imagen personalizada WIM. Proporcione las credenciales de usuario para la conexión al recurso compartido de red que almacenará el archivo WIM y, a continuación, haga clic en Siguiente.
  4. En la pantalla Imagen de arranque, seleccione crear un nuevo paquete de imágenes de arranque y proporcione una ubicación de red para usarla como directorio de origen del paquete de imágenes de arranque y, a continuación, haga clic en Siguiente.
  5. Proporcione un nombre para el paquete, la información de la versión y comentarios para el paquete de imágenes de arranque, y haga clic en Siguiente.
  6. Elija una plataforma (x86 o x64), compatibilidad con ADO, cualquier fuente opcional que necesite, un fondo personalizado para la imagen de arranque si fuera necesario y cualquier carpeta extra para incluirla en la imagen de Windows PE. A continuación, haga clic en Siguiente.
  7. En la pantalla Paquete de MDT, seleccione Crear un nuevo paquete de archivos de Microsoft Deployment Toolkit, proporcione una ruta de acceso UNC para usarla como origen del paquete y haga clic en Siguiente.
  8. Proporcione el nombre, la versión, el idioma, el fabricante y comentarios para el paquete de MDT y, a continuación, haga clic en Siguiente.
  9. Para la imagen de sistema operativo, seleccione Crear un nuevo paquete de instalación de SO, proporcione la ruta de acceso a los archivos de origen de Windows Server 2008 y una ubicación UNC para usarla como directorio de origen del paquete, y haga clic en Siguiente.
  10. Para el Paquete de cliente, seleccione Crear un nuevo paquete de cliente de Configuration Manager y haga clic en Siguiente.
  11. Para el Paquete de configuración, seleccione Crear un nuevo paquete de configuración y proporcione una ubicación UNC para usarla como origen del Paquete de configuración y, a continuación, haga clic en Siguiente.
  12. Para el Paquete de Sysprep, seleccione No son necesarios archivos Sysprep y haga clic en Siguiente.
Ahora el asistente creará la imagen de arranque y todos los paquetes. Si expande Paquetes, Imágenes de arranque, Paquetes de instalación de sistema operativo y Secuencias de tareas, podrá ver todos los paquetes y la secuencia de tareas que se han creado. Una vez que se han creado todos estos paquetes, deben implementarse en puntos de distribución.
Además de estos paquetes, con frecuencia necesitará agregar controladores al hardware de servidor específico. Para ello, se agregan controladores al almacén de controladores de Configuration Manager y se crea un paquete de controladores que se usará durante la implementación.
Para importar controladores al catálogo de controladores y crear un paquete de controladores, vaya a la Consola de Configuration Manager, haga clic con el botón secundario en Controladores y seleccione Importar. Seleccione importar todos los controladores de la ruta de acceso UNC especificada y, a continuación, escriba la ruta de acceso UNC que contenga todos los controladores que haya reunido para sus modelos de servidor específicos. Cuando haya terminado, haga clic en Siguiente.
En la página Detalles de los controladores, seleccione qué archivos INF desea que se importen y asigne opcionalmente los controladores a una categoría. Una categoría podría basarse en un tipo de modelo específico de servidor. Haga clic en Siguiente y, a continuación, en la página Agregar controladores al paquete, haga clic en Nuevo paquete. Especifique un nombre, comentarios y una ruta de acceso UNC que se usará como origen del paquete de controladores, y haga clic en Aceptar. Seleccione Actualizar puntos de distribución cuando haya terminado y haga clic en Siguiente.
En la página Agregar controlador a imágenes de arranque, seleccione la imagen de arranque que ha creado anteriormente y marque la casilla Actualizar puntos de distribución cuando haya terminado. Haga clic en Siguiente y, a continuación, en la página de resumen, haga clic en Siguiente de nuevo para finalizar el asistente, importar los controladores y crear el paquete de controladores.

Edición de la secuencia de tareas
Una vez que ha terminado de crear todos los paquetes necesarios y la secuencia de tareas para instalar Windows Server 2008, deseará probablemente personalizar varias de las acciones en la secuencia de tareas predeterminada. Para modificar la secuencia de tareas, haga clic en la misma con el botón secundario y seleccione Editar. Se mostrará la plantilla de secuencias de tareas del servidor de Microsoft Deployment, como en la Figura 3.
Figura 3 Es posible personalizar la secuencia de tareas predeterminada.
Figura 3 Es posible personalizar la secuencia de tareas predeterminada.
En un nivel superior, una secuencia de tareas es una serie de elementos de línea de comandos conocidos como tareas y cada una de ellas realiza operaciones específicas. Cada tarea puede tener propiedades específicas que se pueden configurar y puede tener también condiciones establecidas en la ficha Opciones, que evalúan si deben ejecutarse tareas específicas. Por ejemplo, la primera tarea de la secuencia de tareas tiene condiciones establecidas tal como se muestra en la Figura 4.
Figura 4 Puede deshabilitar una tarea o establecer condiciones para la misma en la ficha Opciones.
Figura 4 Puede deshabilitar una tarea o establecer condiciones para la misma en la ficha Opciones.
En este ejemplo, la tarea está deshabilitada de manera predeterminada porque se ha marcado la casilla Deshabilitar este paso. Si la tarea estuviera habilitada, sólo se ejecutaría según las condiciones especificadas actualmente.
Algunas de las tareas más comunes que quizás necesite modificar antes de implementar Windows Server 2008 son: Formato y disco de partición, Validar, Aplicar imagen de sistema operativo y Aplicar configuración de red.
La tarea Formato y disco de partición le permite definir cómo desea crear la estructura del disco de partición para sus implementaciones de servidor. La configuración predeterminada crea una partición que usa todo el espacio del primer disco. Puede que no desee implementar sus servidores con esta configuración, así que puede cambiarla para especificar el diseño de disco que desea usar.
La tarea Validar permite comprobar ciertos requisitos básicos, como la memoria y la velocidad del procesador. Por ejemplo, si el estándar de su compañía para implementaciones de servidor es de 2 GB de memoria, podría configurar este valor como requisito y la instalación no continuará si el servidor no lo cumple.
La tarea Aplicar imagen de sistema operativo permite configurar la imagen específica que se va a implementar. Por ejemplo, cuando se usan archivos de origen para Windows Server 2008, tiene la opción de implementar Server Standard, Server Enterprise, Server Datacenter, Server Standard Core, Server Enterprise Core y Server Datacenter Core. Necesitará elegir la imagen apropiada que se va a usar, y esto dependerá de qué versión de Windows Server 2008 desea implementar.
La tarea Aplicar configuración de red permite configurar direcciones IP estáticas para las tarjetas de red, así como cambiar la configuración para la unión a un dominio o un grupo de trabajo. Aunque es posible configurar una dirección IP estática mediante esta tarea, el hacerlo implicará que esta secuencia de tareas funcionará sólo con un servidor. Más adelante, veremos cómo puede configurar direcciones IP estáticas con variables de manera que pueda usar una única secuencia de tareas con varios servidores.

Instalación y configuración de funciones de servidor
Hasta ahora, hemos visto cómo puede modificar la secuencia de tareas con el objeto de configurar elementos relacionados con la instalación del sistema operativo. Con Microsoft Deployment Toolkit, no obstante, se le ofrece también la posibilidad de instalar y configurar funciones de servidor. Por ejemplo, puede configurar una secuencia de tareas para implementar Windows Server 2008 en un servidor de sucursal que ejecutará un controlador de dominio de sólo lectura y un servidor de archivos.
Para hacer esto correctamente, en el editor de secuencias de tareas, navegue hasta la tarea Instalar software y seleccione Agregar | MDT | Instalar funciones y características. A continuación, en la tarea recién creada Instalar funciones y características, marque Controlador de dominio de Active Directory y Servidor de archivos, tal como se muestra en la Figura 5.
Figura 5 Instalación de funciones y características
Figura 5 Instalación de funciones y características
Ahora es necesario que configure las opciones del controlador de dominio de sólo lectura. En el editor de secuencias de tareas, seleccione Agregar | MDT | Configurar ADDS. En la tarea recién creada Configurar ADDS, seleccione crear una réplica nueva de controlador de dominio de sólo lectura y especifique los valores de las siguientes propiedades:
  • Nombre DNS del dominio existente
  • Controlador de dominio de origen de replicación
  • Cuenta
  • Contraseña de recuperación (modo seguro)

Trabajo con variables
Es importante que entienda que una de las características más eficaces que las secuencias de tareas ofrecen a los usuarios es la capacidad de configurar prácticamente cualquier propiedad de la secuencia de tareas de manera dinámica como variable durante la implementación. Tanto Configuration Manager como Microsoft Deployment ofrecen varios mecanismos para configurar y usar variables.
Configuration Manager permite configurar variables como variables de equipo, variables de colección o directamente dentro de la secuencia de tareas. Microsoft Deployment permite configurar variables a través del archivo customsettings.ini, una base de datos back-end o un servicio web. Puede encontrar una lista de variables que se pueden configurar en technet.microsoft.com/bb632442.aspx.
Usemos ahora el ejemplo en el cual configuramos una dirección IP estática en un servidor particular. Anteriormente en este artículo, vimos cómo configurar la dirección IP estática directamente dentro de la secuencia de tareas en la tarea Aplicar configuración de red. No se trata, sin embargo, del procedimiento más adecuado, ya que la secuencia de tareas sólo es útil para un servidor específico.
Lo que desea hacer en su lugar es abandonar la secuencia de tareas y configurar la dirección IP a través de una variable. Este es el proceso paso a paso para establecer la dirección IP estática como variable de equipo:
  1. En la Consola de Configuration Manager, navegue hasta System Center Configuration Manager | Base de datos del sitio | Administración de equipos | Colecciones.
  2. Para asignar una variable por equipo a un equipo, localice y expanda la colección a la que pertenece el equipo, haga clic con el botón secundario en el equipo, seleccione Propiedades y, a continuación, haga clic en la ficha Variables.
  3. Para especificar variables personalizadas y sus valores asociados, haga clic en el icono Nuevo para abrir el cuadro de diálogo <Nueva> variable.
  4. En el cuadro de diálogo <Nueva >variable, es necesario que especifique un nombre para la variable e indique si esta variable estará visible en la Consola de Configuration Manager 2007. Para una dirección IP estática, agregará las siguientes variables:
  • OSDAdapter0IPAddressList
  • OSDAdapter0SubnetMask
  • OSDAdapter0Gateways
  • OSDAdapter0DNSServerList
Las variables configuradas deben parecerse a las reflejadas en la Figura 6.
Figura 6 Uso de las variables de equipo para configurar una dirección IP estática
Figura 6 Uso de las variables de equipo para configurar una dirección IP estática

Implementación de la secuencia de tareas
Ahora que ya ha configurado la secuencia de tareas por completo y que también ha configurado las variables, está preparado para implementar Windows Server 2008. Configuration Manager ofrece varios mecanismos para implementar un sistema operativo, como el entorno de ejecución previo al arranque (PXE), medios de arranque de secuencias de tareas, medios independientes y anuncios estándar para equipos existentes.
En un intento de favorecer la simplicidad, resumiré cómo crear una secuencia de tareas para medios de arranque. En la Consola de Configuration Manager, navegue hasta Secuencias de tareas y, a continuación, seleccione Crear medios de secuencia de tareas en el menú Acciones. En la página Seleccionar tipo de medios, seleccione Medios de arranque y haga clic en Siguiente. En la página Tipo de medios, especifique un CD como tipo de medio y un nombre para el archivo de medios. En la página Seguridad, puede especificar una contraseña para proteger el medio o un certificado autofirmado. A continuación, especifique la imagen de arranque. Una vez que haya llevado a cabo estos pasos, pasará a la página Confirmación, en la que hará clic en Finalizar. Para obtener instrucciones detalladas sobre cómo implementar mediante este y otros mecanismos, consulte la documentación en technet.microsoft.com/bb681029.aspx.

Conclusión
En este artículo, ha comprobado cómo es posible usar System Center Configuration Manager y Microsoft Deployment para implementar Windows Server 2008, agregar funciones como Servidor de archivos y Controlador de dominio, configurar variables de equipo específicas e implementar el sistema operativo con medios de arranque de secuencia de tareas. Aunque las implementaciones reales de servidor pueden ser mucho más complejas, este artículo le asistirá en la unificación de las herramientas de implementación de servidor y cliente.

Tim Mintner es ingeniero de desarrollo de software senior en el equipo Microsoft Solutions Accelerator, especializado en Microsoft Deployment Toolkit. Tiene más de 14 años de experiencia en el trabajo con clientes para implementar sistemas operativos de Microsoft. Puede ponerse en contacto con Tim en tmintner@microsoft.com.


 Cobertura especial: Windows Server 2008: Auditor&#237;a y cumplimiento en Windows Server 2008
Cobertura especial: Windows Server 2008 Rob Campbell y Joel Yoker

Auditoría y cumplimiento en Windows Server 2008
Resumen:
  • Aumento de la importancia del cumplimiento
  • Comprensión de los cambios en su entorno
  • Retos de la auditoría de eventos de seguridad
  • Aspectos técnicos de las auditorías

En el mundo de la tecnología de la información, el cambio es una constante. Si su organización de TI es como la mayoría, no debe perder más tiempo y debe tratar de comprender los cambios que tienen lugar en su entorno. A medida que aumenta la complejidad y escala de los entornos de TI, también lo hace la repercusión de
los errores administrativos y las divulgaciones accidentales de datos. La sociedad de hoy en día demanda responsabilidad por dichos eventos, por lo que las organizaciones se consideran actualmente responsables legales de la protección de la información que administran.
Como resultado, la auditoría de los cambios en el entorno se ha convertido en un factor muy importante. ¿Por qué? Las auditorías proporcionan los medios para comprender y administrar los cambios en entornos de TI sumamente distribuidos y de gran tamaño tan frecuentes hoy en día. En este artículo, abarcamos los retos a los que se enfrentan la mayoría de las organizaciones, el entorno de cumplimiento y normativa de TI, algunos de los aspectos básicos de las auditorías en Windows® y cómo la funcionalidad de Windows Server® 2008 y los Servicios de recopilación de auditorías (ACS) de Microsoft® System Center Operations Manager 2007 pueden dar lugar a una estrategia de auditorías integral.

Auditoría de los retos
Un vistazo rápido a los titulares del día nos muestra que las divulgaciones de datos se están convirtiendo en un problema creciente. Muchos de estos incidentes implican una acción legal, pérdidas financieras y problemas de relaciones públicas para las organizaciones responsables. La capacidad de explicar qué cambios tuvieron lugar o la identificación rápida de problemas es la clave para reducir la repercusión de los incidentes de divulgación de datos.
Por ejemplo, digamos que su organización es responsable de administrar información de identificación personal para una base de clientes determinada. Aunque existen numerosas maneras de proteger la información contenida en los sistemas que debe administrar, todavía pueden darse divulgaciones no autorizadas. Una auditoría adecuada puede permitir a la organización saber exactamente qué sistemas se han visto comprometidos y, quizás, qué datos se han perdido. Sin la auditoría, la repercusión de la pérdida de datos podría ser mucho mayor, en gran parte porque no habría manera de estimar el alcance de los posibles daños.
Así pues, ¿por qué no la ponen en práctica las organizaciones de TI? El hecho es que la mayoría de las organizaciones no comprenden completamente los aspectos técnicos de una auditoría. Aunque los altos directivos comprenden generalmente conceptos como los de copia de seguridad y restauración, la complejidad inherente a la auditoría de los cambios en el entorno es un mensaje difícil de transmitir. Como resultado, tras un solo incidente significativo surgen gran cantidad de preguntas sobre la auditoría. Por ejemplo, puede que una auditoría básica esté habilitada pero, si el sistema no está configurado para llevar a cabo la auditoría de un cambio particular, debido a la falta de planeación, esta información no se recopilará.
Es más, los eventos de seguridad auditados tienen ciertos problemas inherentes que los profesionales de TI deben saber tratar. Una de estas dificultades es la distribución de sistemas dentro de los grandes entornos informáticos actuales. Este factor supone retos de recopilación y agregación significativos, puesto que el cambio puede darse en cualquier sistema o conjunto de sistemas y en cualquier momento. Esto nos lleva a otro reto, la correlación. La traducción de relaciones entre eventos en uno o varios sistemas es, con frecuencia, necesaria para obtener el verdadero significado de lo que está ocurriendo.
Otro problema a considerar es que las auditorías normalmente van más allá de los límites organizativos tradicionales. Las distintas estructuras de organización o equipo existen por distintos motivos y puede que no sea demasiado fácil obviarlas. Muchas organizaciones cuentan con un equipo de servicios de directorio, un equipo de infraestructura de mensajería y un equipo dedicado al escritorio pero, probablemente, sólo hay un equipo de seguridad responsable de todas estas áreas. Es más, el personal de seguridad dedicado de su organización puede que no esté físicamente presente en todas las ubicaciones. Por ejemplo, las sucursales a menudo dependen de una sola persona o un equipo pequeño para todas las tareas, incluida la administración del registro de eventos de seguridad.
Por último, la cantidad total de eventos supone un reto en sí. Los eventos de seguridad auditados ocurren en un volumen mucho mayor que otros tipos de registro de eventos. El número de eventos recopilados dificulta la retención y la revisión efectivas de los registros. Además, al estipular los requisitos de retención de esta información, las normativas actuales y propuestas no ayudan a reducir esta carga en las infraestructuras informáticas actuales.
En el pasado, la auditoría del acceso a la información podía resumirse como el deseo de conocer y el intento de garantizar la seguridad. Actualmente, puesto que las organizaciones, y el equipo directivo responsable de las mismas, se consideran responsables legales de la pérdida de información o de la ausencia de una protección adecuada de la misma, es muy importante para los administradores de TI familiarizarse con la normativa aplicable a sus entornos. Para compañías globales, los retos son incluso más complejos, puesto que cada país tiene sus propias reglas referentes a la información y a su protección. Algunos ejemplos de la legislación existente sobre cumplimiento de normativas se indican en la Figura 1, junto con las expectativas asociadas que afectan a las organizaciones de TI.
Figure 1 Normativas y su significado para los profesionales de TI (Close Figure 1)

Normativa | Expectativa
Ley Sarbanes-Oxley de 2002 (SOX) | La sección 404 reconoce la función de los sistemas de información y obliga a las compañías comerciales públicas a proporcionar una revisión anual de sus controles internos sobre generación de informes financieros.
Ley de Transferencia y Responsabilidad del Seguro de Salud (HIPAA) | Trata la seguridad y la privacidad de datos sanitarios. La "Regla de seguridad" cubre medidas de seguridad administrativas, físicas y técnicas de estos datos.
Detección electrónica (eDiscovery) | Define los estándares para la retención de documentos y el acceso a los mismos, incluida la responsabilidad sobre quién tiene acceso a los documentos y cómo.
Ley Federal de Gestión de Seguridad de la Información de 2002 (FISMA) | Orden federal para proporcionar un marco integral de seguridad de la información (INFOSEC) para sistemas gubernamentales de Estados Unidos, la coordinación con varias agencias de aplicación de la ley, el establecimiento de controles, el reconocimiento de productos comerciales y las capacidades de software. La sección 3544 abarca las responsabilidades de las agencias, incluidos los controles de TI.
Estándares Federales de Procesamiento de la Información (FIPS), publicación 200 | Especifica los requisitos de seguridad mínimos de los sistemas de información y de información federal, y resume el uso de las recomendaciones halladas en NIST Special Publication (SP) 800-53. En NIST SP 800-53, sección AU-2 (Eventos de auditoría), se especifica que los sistemas de información deben ofrecer la capacidad de compilar los registros de auditoría de varios componentes en una traza de auditoría de todo el sistema correlacionada temporalmente, para administrar los eventos auditados por componentes individuales y para garantizar que la organización revisa periódicamente los eventos de auditoría.
En este escenario de presión legal, ¿qué deben hacer los profesionales de TI? Los administradores y los técnicos de TI necesitan crear una historia clara y concisa para presentarla al personal dentro y fuera de la organización. Esto incluye el desarrollo de una estrategia apropiada de auditoría, la cual requiere medidas proactivas e inversiones. El concepto clave en este caso es que la auditoría no puede ser una idea tardía en el diseño, como lo es con mucha frecuencia.
Los retos de TI como estos pueden normalmente resolverse con una buena combinación de personal, procesos y tecnología. En las auditorías, lo que importa es el proceso. Por lo tanto, el primer paso debe ser dominar los aspectos básicos de manera que pueda responder a las necesidades y los requisitos de su organización en torno al cumplimiento de la normativa. Abarquemos ahora algunos de los aspectos básicos de la auditoría en Windows. A continuación, nos dedicaremos a los cambios integrados en Windows Server 2008 y Windows Vista®.

Auditoría de eventos de seguridad
Todos los eventos auditados se registran en el registro de eventos de seguridad de Windows. Estos eventos no suelen requerir una acción inmediata y, normalmente, son de naturaleza informativa. Cada evento registra una Auditoría correcta o un Error de auditoría para un tipo específico de acceso que haya ocurrido. Esto es diferente a los registros de eventos de aplicación o del sistema, donde los problemas pueden identificarse a través de codificación en colores (sugerencia: busque los eventos en rojo para identificar problemas).
El registro de eventos de seguridad es diferente porque los eventos auditados se ocultan, con frecuencia, por su volumen y, tal como se ha mencionado antes, la correlación de los datos de seguridad puede suponer un reto significativo. Incluso una simple infracción de datos en un solo sistema es problemática. El registro de eventos de seguridad debería analizarse con el objeto de identificar qué cuenta se usó para obtener acceso a los datos. Esto requiere que el administrador efectúe un seguimiento de todo el registro para encontrar la cuenta. Desgraciadamente, los ataques sofisticados actuales son, a menudo, coordinados y distribuidos, y dificultan bastante esta clase de análisis para la víctima.
Dicho esto, es importante comprender los elementos clave que permiten que la información se registre en el registro de eventos de seguridad de Windows: Directiva de auditoría y Listas de control de acceso del sistema (SACL). Las directivas de auditoría son parámetros configurables para un equipo local a través de la Directiva de grupo o la Directiva de seguridad local, y definen la recopilación de eventos correctos y con error de tipos específicos de acceso. Las siguientes categorías principales de directivas de auditoría han estado presentes en Windows durante muchos años (más sobre la nueva directiva de auditoría granular en Windows Server 2008 en unos momentos):
  • Auditar eventos de inicio de sesión de cuenta
  • Auditar la administración de cuentas
  • Auditar el acceso del servicio de directorio
  • Auditar eventos de inicio de sesión
  • Auditar el acceso a objetos
  • Auditar el cambio de directivas
  • Auditar el uso de privilegios
  • Auditar el seguimiento de procesos
  • Auditar eventos del sistema
La necesidad de definir la directiva de auditoría y estas categorías asociadas queda normalmente bien comprendida por parte de la mayoría de las organizaciones de TI, pero la directiva de auditoría representa sólo una parte de la solución. Las SACL juegan también una función significativa en la implementación de un plan de auditoría integral. Dos categorías específicas de directivas de auditoría, auditar el acceso del servicio de directorio y auditar el acceso a objetos, dependen por completo de las SACL para devolver información en el registro de eventos de seguridad. Así pues, ¿qué son exactamente las SACL?
Cada objeto (archivo, registro o servicio de directorio) tiene una Lista de control de acceso (ACL) con una o más Entradas de control de acceso (ACE) divididas en dos tipos: una lista de control de acceso discrecional (DACL) y una SACL (la última define la configuración que registra los intentos de acceso a los objetos protegidos). Cada una de las ACE en una SACL especifica los tipos de intentos de acceso de un administrador de confianza especificado que deben registrarse en el registro de eventos de seguridad. Las ACE definen el registro de intentos de acceso correctos y/o con error a los objetos especificados. La Figura 2 muestra el uso de una SACL en un objeto para generar eventos de tipos específicos de acceso.
Figura 2 Uso de una SACL en un objeto
Figura 2 Uso de una SACL en un objeto
La comprensión de la relación entre la directiva de auditoría y las SACL es importante, puesto que la configuración es necesaria para capturar los eventos auditados "correctos" en consonancia con los cambios en el entorno. Tal como se ha mencionado, las categorías "auditar el acceso del servicio de directorio" y "auditar el acceso a objetos" sólo permiten la generación de auditorías en el registro de eventos de seguridad para estas categorías específicas, pero los eventos sólo se generan si un objeto tiene una ACE de auditoría configurada en su SACL. Una vez que estas piezas están en su lugar, la Autoridad de seguridad local (LSA) de Windows genera eventos de seguridad que se escriben en el registro de eventos de seguridad.
Los eventos consisten en dos áreas diferenciadas: el encabezado, que es estático y está predefinido para cada identificador de evento (Id. de evento) y el cuerpo, que es dinámico y contiene detalles diferentes para eventos diferentes. La Figura 3 muestra estos dos elementos en un evento de seguridad de Windows Server 2008 de ejemplo. La comprensión de estos componentes de evento es importante para la fase de análisis de cualquier proyecto de auditoría, y es de particular interés con respecto a cómo se devuelve la información en herramientas como ACS.
Figura 3 El encabezado y el cuerpo de un evento auditado
Figura 3 El encabezado y el cuerpo de un evento auditado

Windows Eventing 6.0
Ahora que entendemos el problema, ¿cómo ayuda Windows Server 2008 a las organizaciones a enfrentarse a estos desafíos? Windows Server 2008 es el primer servidor que contiene el nuevo subsistema de eventos Windows Eventing 6.0, el cual mejora en gran medida el entorno de administración de los eventos de seguridad. Tenga en cuenta que, aunque en este artículo nos hemos centrado en Windows Server 2008, el 95% del nuevo conjunto de características existe también en Windows Vista.
Una de las primeras novedades que los usuarios advertirán en Windows Eventing 6.0 es la nueva interfaz de usuario. El nuevo complemento de Microsoft Management Console (MMC) Visor de eventos ofrece una página excelente de introducción y resumen, vistas personalizadas flexibles y texto explicativo ampliamente mejorado. Estas interfaces pueden ayudar al usuario final o al administrador del sistema a encontrar información de eventos y a configurar opciones del registro de eventos muy importantes directamente en el Visor de eventos.
Un problema clave que a menudo repercutía en los datos de seguridad dentro del registro de eventos era la retención de datos. Anteriormente, el subsistema de registro de eventos (incluidos todos los registros) tenía límites de escalabilidad. Si se excedían estos límites, todo el subsistema detenía los eventos de registro. No obstante, este no es el caso en Windows Eventing 6.0; las organizaciones están limitadas ahora sólo por la cantidad disponible de espacio en disco. Sin embargo, tenga en cuenta que los registros de eventos muy grandes pueden ser complicados de analizar, puesto que cada entrada de registro individual se debe evaluar durante el filtrado, por lo que, definitivamente, deseará mantener su registro a un tamaño razonable.
Por supuesto, esto todavía deja al administrador de TI la responsabilidad del desarrollo de un plan de archivado de registros de eventos en muchos sistemas. Como ayuda para esta tarea en el nivel de servidor local, una característica que forma ahora parte de Windows Eventing 6.0 es la opción "Archivar el registro cuando esté lleno; no sobrescribir eventos". En versiones anteriores de Windows, esta opción sólo se podía configurar directamente a través de la modificación del valor del Registro AutoBackupLogFiles. Aunque esto suministra un mecanismo para el archivo local de registros, no ofrece una solución para la administración de estos archivos a largo plazo, ni soluciona el problema de agregación en varios sistemas. Los Servicios de recopilación de auditorías ofrecen una solución completa para esto, a la que llegaremos en breve.
La nueva interfaz es sólo el principio. La verdadera ventaja de Windows Eventing 6.0 es el nuevo servicio Registro de eventos de Windows y el motor subyacente basado en XML. Estos componentes son los que proporcionan la mejora de la escalabilidad, la accesibilidad y las opciones de administración. Los eventos se almacenan ahora en un formato XML flexible que posibilita soluciones personalizadas que pueden aprovechar esta información de manera nativa.
Windows Eventing 6.0 ofrece también la capacidad de asociar acciones administrativas con eventos específicos. Esto lo consigue integrando el servicio Recopilador de eventos de Windows con el Programador de tareas para ofrecer eventos basados en tareas. Se trata de un nuevo paradigma para el Programador de tareas, que anteriormente estaba limitado a activar eventos basados en la hora. El asistente para "Adjuntar tarea a este evento" (disponible en el menú contextual de cualquier evento en el Visor de eventos de Windows Server 2008) proporciona una manera fácil de iniciar un programa, enviar un correo electrónico o mostrar un mensaje siempre que se registre un evento específico. Esto puede ser muy útil a la hora de identificar las acciones específicas que tienen lugar en su entorno y que se pueden aislar en un evento de seguridad específico. Por ejemplo, si está realizando la auditoría de cambios en la clave del Registro "Schema Update Allowed" en sus controladores de dominio, puede crear una tarea que envíe un mensaje de correo electrónico a los administradores de seguridad específicos para notificarles la modificación de esta clave del Registro.
Además de la nueva capacidad de recopilar y almacenar un gran número de entradas de evento, ahora también puede controlar mejor qué eventos se registran en el registro de eventos. Esto es posible gracias a una nueva característica denominada Directiva de auditoría granular (GAP). En versiones anteriores de Windows, las nueve categorías de auditoría existentes con frecuencia provocaban una sobrecarga de eventos. Estas categorías de nivel superior se pueden controlar ahora a través de 50 subcategorías granulares, cada una de las cuales representa un subconjunto relacionado de eventos.
Esto le ofrece la capacidad de filtrar información que no sea crítica del registro de eventos sin perder visibilidad en el nivel de categorías. Por ejemplo, si en un sistema particular desea supervisar los cambios sólo en el Registro, pero no en el sistema de archivos, previamente sólo podía elegir la generación de informes de éxito o error en la categoría Acceso a objetos. Con GAP, puede filtrar subcategorías como Sistema de archivos, Servicios de certificación y Recurso compartido de archivos, y generar informes de eventos sólo en la subcategoría Registro. Para explorar las subcategorías de GAP en un sistema Windows Server 2008, debe ejecutar el comando Auditpol en un símbolo del sistema elevado. Para enumerar las subcategorías disponibles de GAP, escriba lo siguiente:
auditpol /list /subcategory:*
Para obtener una lista de las subcategorías de GAP configuradas en su sistema, escriba esto:
auditpol /get /category:*
Tenga en cuenta que GAP no se puede configurar a través de la interfaz de usuario estándar de la directiva de grupo y debe administrarse a través de auditpol.exe. El artículo de Knowledge Base en support.microsoft.com/kb/921469 ofrece instrucciones acerca de cómo implementar la configuración de GAP a través de la directiva de grupo para sistemas Windows Server 2008 y Windows Vista.
Windows Server 2008 también puede capturar valores tanto nuevos como anteriores de los tipos específicos en el registro de eventos de seguridad. En versiones anteriores de Windows, el subsistema de auditoría sólo registraba el nombre del atributo de objeto de Active Directory® o el valor del Registro que se cambiaba; no registraba los valores anteriores y actuales del atributo. Esta nueva capacidad se aplica a los Servicios de dominio de Active Directory, a Active Directory Lightweight Directory Services y al Registro de Windows. Al habilitar Auditoría correcta o Error de auditoría en las subcategorías de "Registro" o "Cambios de servicio de directorio" y configurar las SACL asociadas, surgirán eventos detallados en el registro de eventos para las acciones en estos objetos. Esto se puede realizar mediante los siguientes comandos auditpol:
auditpol /set /subcategory:"Registry" /success:enable
auditpol /set /subcategory:"Directory Service
    Changes" /success:enable
En cuanto a los cambios del Registro, estos aparecen como eventos con el identificador 4657, tal como muestra la Figura 4.
Figura 4 Antes y después de un cambio en el Registro
Figura 4 Antes y después de un cambio en el Registro
Esta característica es especialmente útil al efectuar el seguimiento de los cambios en objetos de Active Directory. Para Cambios de servicio de directorio, estos cambios aparecen en un par de eventos con el identificador 5136, tal como muestra la Figura 5. Cada evento tiene el objeto, el atributo y la operación del servicio de directorio en el cuerpo del evento. Para cambios a los atributos con datos existentes, contemplamos dos operaciones: Valor eliminado y Valor agregado. Para los atributos que no se han rellenado, sólo veríamos la operación Valor agregado al escribir datos en dicho atributo. Por ejemplo, cuando se lleva a cabo una operación de modificación satisfactoria en un atributo de un objeto de usuario, como telephoneNumber, Active Directory registra los valores previos y actuales del atributo en entradas detalladas del registro de eventos.
Figura 5 Antes y después de un evento de Cambios de servicio de directorio
Figura 5 Antes y después de un evento de Cambios de servicio de directorio
Si se crea un objeto nuevo, se registran los valores de los atributos que se rellenan en el momento de la creación del objeto. Si se mueve un objeto dentro de un dominio, se registra la ubicación anterior y la nueva (en forma de nombre distintivo). Esta característica "anterior y nueva" está habilitada de manera predeterminada cuando se aplica la configuración apropiada de la directiva de auditoría. Si hay un atributo del cual desea mantener la confidencialidad, como los cambios del número de identificación de empleados, puede excluir específicamente los atributos con tan sólo realizar una sencilla modificación del esquema. Al modificar la propiedad searchFlags del atributo en el esquema a 0x100 (valor 256 -NEVER_AUDIT_VALUE), tal como se muestra en la Figura 6, no surgirá el evento Cambios de servicio de directorio cuando tengan lugar cambios en el atributo.
Figura 6 Exclusión de un atributo de Cambios de servicio de directorio
Figura 6 Exclusión de un atributo de Cambios de servicio de directorio
Por último, una de las nuevas características más atractivas en Windows Eventing 6.0 es Suscripciones de eventos. Tal como hemos mencionado, el acceso al registro de eventos y la revisión del mismo constituyen tareas clave de administración del sistema. La nueva capacidad Suscripciones de eventos ofrece un método para reenviar eventos directamente entre sistemas. Las Suscripciones de eventos consisten en un Recopilador de eventos que reúne eventos y Orígenes de eventos que se han configurado para reenviar eventos a hosts especificados. La capacidad de consumir eventos viene proporcionada por el servicio Recopilador de eventos de Windows (novedad en Windows Eventing 6.0), y la funcionalidad de suscriptor está integrada en el servicio Registro de eventos de Windows. Un recopilador se puede configurar para reunir eventos de muchos orígenes de eventos, que pueden ser de los sistemas Windows Server 2008 o Windows Vista.
Todos los datos recopilados de orígenes de eventos residen en un Registro de eventos discreto, denominado Eventos reenviados (ForwardedEvents.evtx), y se administran a través del servicio Registro de eventos en el recopilador. La configuración en ambos extremos (recopilador y origen) es necesaria y se puede automatizar (winrm quickconfig –q en el origen; wecutil qc /q en el recopilador). Es importante tener en cuenta que esta capacidad de suscripción de eventos no fue diseñada para empresas ni para reemplazar sistemas que envían eventos a una base de datos externa.
Un ejemplo de aprovechamiento de esta capacidad puede darse en una pequeña granja de servidores web. Suponga que tiene un conjunto reducido de sistemas asociados con un sitio web particular (incluidos servidores web y SQL Server). Esos sistemas pueden consolidar su información del registro de eventos de seguridad en un único sistema que usa la nueva funcionalidad Suscripción de eventos. Los entornos de mayor tamaño requerirán normalmente un conjunto de herramientas de consolidación del registro de eventos más avanzado.

Servicios de recopilación de auditorías
Dadas todas las nuevas capacidades de Windows Server 2008, la solución real para la administración y el archivado a largo plazo de la información del registro de eventos de seguridad es posible gracias a una base de datos centralizada de la información de auditoría. Servicios de recopilación de auditorías es una característica principal de System Center Operations Manager 2007. ACS ofrece un mecanismo para reenviar, recopilar, almacenar y analizar los datos de eventos de seguridad. Los eventos de seguridad se recopilan prácticamente en tiempo real y se almacenan en un repositorio central de SQL. ACS proporciona a las organizaciones un método para ofrecer acceso con privilegios mínimos a la información de auditoría puesto que no se requiere acceso físico a los sistemas que se están auditando. Veamos cómo funciona ACS.
ACS consta de tres componentes principales. En primer lugar, el Reenviador, que es la parte del agente Operations Manager que transmite los datos del registro de eventos desde el cliente a la infraestructura ACS. Los reenviadores transmiten datos al segundo componente, el Recopilador, que es el agente de escucha del servidor. Los Reenviadores de ACS se conectan a través del puerto TCP 51909 para comunicarse con su Recopilador asignado de una manera segura. Antes de la transmisión, los datos del registro de eventos se normalizan en XML, lo cual significa que la información excesiva se elimina y la información de eventos se resume en campos asignados según la información específica del encabezado y el cuerpo del evento. Una vez que la información alcanza el recopilador, se envía al tercer y último componente, la base de datos de ACS. Esta se convierte en el repositorio para un almacenamiento a largo plazo de la información de eventos de seguridad. Una vez almacenada, la información se puede extraer directamente a través de consultas SQL o se representa mediante informes HTML a través de SQL Server® Reporting Services. ACS ofrece tres vistas predeterminadas, tal como se muestra en la Figura 7.
Figure 7 Vistas de ACS (Close Figure 7)

Nombre de la vista de ACS | Propósito
AdtServer.dvHeader | Información del encabezado de los eventos recopilados.
AdtServer.dvAll | Información del encabezado y de todo el cuerpo de los eventos recopilados.
AdtServer.dvAll5 | Encabezado y cinco primeras cadenas de la información del cuerpo de los eventos recopilados.
Desde el punto de vista del rendimiento, un único recopilador de ACS puede administrar un pico máximo de 100.000 eventos por segundo y un máximo continuo de 2500 eventos por segundo. Para facilitar la planeación, un único recopilador de ACS puede ser compatible con 150 controladores de dominio, 3000 servidores miembro o 20.000 estaciones de trabajo, según la configuración predeterminada de la directiva de auditoría. En un escenario real y probado, alrededor de 150 controladores de dominio mostraron un máximo de, aproximadamente, 140 eventos por segundo con un promedio máximo de 500.000 eventos por hora. En apenas 14 días (la configuración predeterminada de retención para ACS), unos 150 GB de datos de eventos de seguridad se almacenaron en la base de datos de SQL Server. Una configuración más agresiva de directiva de auditoría y SACL asociada generará obviamente aún más datos (por hora, por día y en general).
Lo más importante a tener en cuenta es que, con este volumen de datos, nadie tendría capacidad para revisar cada evento en un entorno empresarial normal de gran tamaño. Sin embargo, las organizaciones no deben atemorizarse ante las cifras representadas aquí. La comprensión de los cambios que suceden en su entorno supone el análisis de grandes cantidades de datos.
En este aspecto es donde destaca ACS. Gracias a SQL Server Reporting Services y ACS, puede identificar problemas normalmente ocultos en el registro de eventos de seguridad de la misma manera y con la facilidad que identifica los eventos con codificación en colores que se encuentran en el registro de eventos de aplicación. Aunque ACS incluye un conjunto de informes predeterminados, ampliarlos para las necesidades específicas de su entorno es bastante sencillo.
Considere el siguiente escenario: debido a la importancia de las confianzas externas en el entorno, la administración nos ha solicitado desarrollar un informe que detalle la creación de confianzas de Active Directory. Después de llevar a cabo cierta investigación, sabemos que se crea un objeto trustedDomain en el contenedor cn=System dentro del contexto de nomenclatura de dominio específico en Active Directory cuando se crea una confianza. Después de editar la SACL en este contenedor para auditar la creación correcta de cualquier objeto del dominio de confianza, tenemos la capacidad de capturar eventos de seguridad cada vez que se crea un objeto de este tipo. Esto se representa en un evento 566 en el registro de eventos de seguridad del DC en el que se lleva a cabo la creación de la confianza. A continuación, podemos escribir una consulta SQL sencilla para recuperar esta información desde ACS:
select * from AdtServer.dvAll
where EventID = '566' and
String05 like '%trustedDomain%'
order by CreationTime desc
Para reunir esto en un informe, use la versión de Visual Studio® 2005 que se incluye con SQL Server 2005 Reporting Services, puesto que se ofrece específicamente para el desarrollo de informes. Una vez que finaliza el asistente, será muy fácil crear informes similares al que aparece en la Figura 8. Además, cualquier cambio en el entorno que se pueda representar en el registro de eventos de seguridad se puede resumir en un informe similar de aspecto muy profesional.
Figura 8 Informe de ACS de ejemplo
Figura 8 Informe de ACS de ejemplo

Desarrollo de un plan de auditoría
Ahora que entendemos los retos, así como los aspectos legales y técnicos de las auditorías, ¿cómo deben los administradores de TI enfocar el desarrollo de un "plan de auditoría" para su organización? Al igual que la mayoría de las cosas, el desarrollo de una directiva de auditoría integral es un proceso que comprende varios pasos. El primer paso consiste en determinar lo que se debe auditar. Esto incluye el análisis de su entorno y la determinación de los tipos de eventos y cambios que deben generar auditorías. Esto podría incluir elementos sencillos, como los bloqueos de cuenta, los cambios de grupo con distinción, la creación de confianzas o cambios más complejos, como las modificaciones de elementos de configuración dentro de las aplicaciones de su entorno. La clave en este caso es que la administración debe implicarse en la determinación de los elementos que deben formar parte de un plan de auditoría. Este ejercicio necesita realizarse en papel y debe repetirse a intervalos regulares, no sólo después de incidentes significativos.
El segundo paso implica la identificación de cómo la información de auditoría relativa a cambios específicos se devuelve en forma de eventos de seguridad. La información de auditoría es, en ocasiones, críptica y no fácilmente legible. Antes de la implementación, deben establecerse las correlaciones entre los eventos de seguridad y varias acciones para entender lo que realmente significan los eventos de seguridad. Después de un incidente no es el mejor momento para averiguar las relaciones de los eventos con las acciones.
El tercer paso es el momento de la verdad que se produce cuando implementa su directiva de auditoría y las SACL. Tal como se ha mencionado anteriormente, necesitará definir la configuración de la directiva de auditoría (para habilitar la generación de eventos de seguridad) y las SACL (para generar las trazas de auditoría de acciones asociadas) en el directorio, el sistema de archivos y el Registro con el fin de obtener una visión completa de los cambios en estas áreas.
Todo esto nos lleva al cuarto y último paso: la recopilación, los desencadenadores y el análisis. Según el tamaño y las necesidades de su organización, esto se puede realizar con las capacidades nativas de Windows Server 2008 o con soluciones avanzadas, como la funcionalidad Servicios de recopilación de auditorías de System Center Operations Manager. Un error común cometido por la mayoría de las organizaciones es configurar sólo la directiva de auditoría sin definir las SACL. El último paso abarca la implementación de una solución de tecnología para generar informes y compartir datos con las partes interesadas de la organización. Como se mencionó anteriormente, la mayoría de las organizaciones tienen una entidad establecida responsable de la seguridad, y un plan de auditoría se debe estructurar en consonancia con los elementos existentes de la organización para ser efectivo. La clave de este paso final es recopilar y presentar la información de una manera significativa para todos los responsables de forma que comprendan los cambios en el entorno.
La mayoría de las organizaciones de TI esperan a que se produzca un evento significativo para pasar de considerar un plan de auditoría integral a realmente requerir uno. Windows Server 2008 ofrece mecanismos de mejora para la recopilación y el análisis de los datos de eventos de seguridad en comparación con plataformas anteriores. Las tecnologías avanzadas de recopilación y de generación de informes como ACS exponen los problemas que solían quedar ocultos por el volumen de eventos y la distribución, con lo cual estos cambios son obvios al instante.
Al igual que ocurre con la mayoría de los problemas de TI, el proceso es el reto principal. La configuración y el análisis adicionales siempre son necesarios para capturar lo que los administradores de TI esperan. Así pues, el desarrollo de un conocimiento profundo de los requisitos de su entorno y de las capacidades de la plataforma Windows le permitirá superar estos retos en el futuro. Suerte.

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


 Nota del editor: En dedicaci&#243;n a Windows&#160;Server&#160;2008
Nota del editor
En dedicación a Windows Server 2008

Se lanzan productos todo el tiempo. Y, cuando se cuenta con una serie de centenares de productos (miles, realmente, si tomamos en cuenta la Web), la noción del lanzamiento de un producto puede convertirse en mundana. Esta vez no.
Este febrero, Microsoft lanza Windows Server 2008, y no podríamos estar más emocionados. No cabe duda de que este lanzamiento se ha hecho esperar, pero creo que descubrirá que ha valido la pena. La cantidad de mejoras fundamentales y de funciones nuevas es increíble. Podríamos hablar de IIS 7.0 (y lo hacemos) o de la protección de acceso a redes (también lo hacemos). Podríamos hablar del Administrador de servidores, de las innovadoras técnicas de implementación o de las nuevas características de cumplimiento (y por supuesto que lo hacemos). La lista es larguísima pero, a decir verdad, lo que más me llama la atención sobre esta nueva versión es el esfuerzo que se ha puesto en mejorar la capacidad de administración de Windows Server.
Dedicamos mucho tiempo a averiguar qué podíamos hacer para simplificar la vida de los profesionales de TI. Por ello, es realmente gratificante ver un producto diseñado específicamente para ayudar a los profesionales de TI a hacer mejor su trabajo. Como ejemplo, tomemos la nueva infraestructura de eventos en Windows Server 2008, que Rob Campbell y Joel Yoker tratan en la edición de este mes. Incluso los más fanáticos entre nosotros encontramos difícil alterarnos por algo como la función de eventos pero, permítame que le diga, estoy asombrado por la diferencia que marca en esta versión. Datos XML, vistas personalizadas, descripciones más detalladas, creación de informes simplificada... Es un poco demasiado.
Bromas aparte, las mejoras básicas principales que proporciona esta versión a nuestro sector son dignas de causar emoción. Las mejoras en Active Directory, IIS, funciones de red, seguridad, virtualización y más hacen de este uno de los lanzamientos de producto más importantes de nuestra historia, así que dedicamos este número a todo lo que necesita saber acerca de Windows Server 2008.
Y, como acontecimiento especial, nos complace dar la bienvenida de nuevo a Mark Russinovich, técnico del departamento de plataformas y servicios, y creador de las populares herramientas de Sysinternals. Mark ha creado parte del contenido más solicitado en la historia de TechNet Magazine, en particular, la serie sobre los cambios del kernel de Windows Vista (en las ediciones de febrero, marzo y abril de 2007). Mark retoma la serie este mes con un examen profundo y técnico de los cambios que encontrará en el kernel de Windows Server 2008. Que disfrute.
(Joshua Hoffman)

Con agradecimiento a los siguientes expertos técnicos de Microsoft: Brandon Baker, Mai-lan Tomsen Bukovec, Bryce Cogswell, Nils Dussart, Gregoire Guetat, Brett Hill, Gaby Kaplan, Jason Leznek, Paul Mayfield, Nathan Muggli, Meg Muran, Michael Murgolo, Michael Niehaus, Raja Perumal, David Solomon, Eric Traut, Jim Truher y Landy Wang.


 Cartas: Comentarios de los lectores
Cartas
Comentarios de los lectores

Windows Vista Complete PC Backup
Gracias por su artículo en la edición de septiembre de 2007 sobre Windows Vista® Complete PC Backup ("Guía de las tecnologías de copia de seguridad de Windows Vista", technetmagazine.com/issues/2007/09/Backup). Sin embargo, no puedo probar esta función. Cuando me pregunta dónde poner la imagen de copia de seguridad, indica que la colocará en el disco duro externo (que es lo que yo querría hacer). Pero no me da la opción de poner el archivo en una carpeta concreta del disco duro externo, y me preocupa que sobrescriba el resto de los archivos en esta unidad. ¿Es esto algo por lo que necesito preocuparme?
Ben B.

Pasamos su pregunta a la autora, Christine Fok, que nos informó de que Complete PC Backup creará una carpeta en el destino para almacenar la imagen, así que no tiene que preocuparse; los datos no se sobrescribirán.

Referencia errónea a clave del Registro
El artículo "Localizar problemas de red esquivos" de diciembre de 2007 (technetmagazine.com/issues/2007/12/Network) contiene un error secundario en la referencia a una clave del Registro para ajustar la pila TCP/IP en Windows®. En la página 70, el autor, Christopher Stoneff, menciona que se pueden ajustar los valores de la clave HKLM\System\CurrentControlSet\Services\TCPIP, cuando la clave correcta es, en realidad, HKLM\System\CurrentControlSet\Services\TCPIP\Parameters (seguramente olvidó agregar "Parameters").
Ingmar K.

Christopher Stoneff nos ha confirmado que tiene razón. La clave incluye \Parameters al final. Sentimos la omisión de esta parte necesaria de la ruta de acceso del Registro. Hemos realizado esta corrección en la versión en línea del artículo.

Cifrado de archivos
Me interesa aprender más acerca del Sistema de cifrado de archivos (EFS) y leí su columna Vigilancia de seguridad de marzo de 2007 titulada "Implementación de EFS: Parte 2" (technetmagazine.com/issues/2007/03/SecurityWatch). Tengo un entorno de dominio en el que algunos usuarios ya cifraban archivos. Con posterioridad, introduje una entidad de certificación y plantillas EFS. Mi pregunta es la siguiente: Si estos usuarios que ya han cifrado archivos con sus propios certificados autofirmados necesitan cifrar archivos nuevos, ¿deben cifrarlos con el certificado autofirmado antiguo o deberían inscribirse para obtener un certificado nuevo de mi entidad de certificación? Además, si todos los usuarios tienen perfiles de movilidad, ¿dónde se almacenarán las claves privadas de los usuarios?
Ammar H.

John Morello, que escribió la columna sobre implementación EFS, nos ha enviado una respuesta a su pregunta:
Una vez que los usuarios se inscriban para obtener el certificado EFS nuevo, empezarán a usarlo para operaciones nuevas. Sin embargo, cualquier archivo cifrado existente continuará cifrado con el par de claves antiguo hasta que se actualice. Entonces, después de que los usuarios se han inscrito, puede ejecutar cipher /u, que actualizará todos estos archivos con el par de claves nuevo.
Si usan perfiles de movilidad, los pares de claves se moverán en los perfiles. En su lugar, recomiendo el uso de credenciales móviles, que son más ligeras que los perfiles de movilidad. Consulte esta página para obtener más información: go.microsoft.com/fwlink/?LinkId=107469.

Expresión regular errónea
Con respecto a la columna ¡Hola, encargados del scripting! de enero de 2008 titulada "Las expresiones regulares saltan a la vista" (technetmagazine.com/issues/2008/01/HeyScriptingGuy), el ejemplo que usa
objRegEx.Pattern = "[^A-Z][^a-z]"
quizás no sea lo que se pretendía. La intención era que encontrara los caracteres que no estaban en minúscula o en mayúscula. Este patrón, sin embargo, es para una mayúscula seguida de una minúscula. No funciona con una cadena como "aBcde". Quizás debería ser así:
objRegEx.Pattern = "[^A-Z^a-z]"
Roger R.

Pasamos su pregunta a los chicos del scripting, y esto es lo que dijeron:
Oye, Roger. Gracias por informar del asunto. Parece que hicimos un cambio a la columna en algún momento y esto se nos pasó por alto. En el borrador original (que aún tengo en algún lugar de mi equipo), dijimos que el ejemplo era para encontrar una letra en mayúscula seguida de una minúscula. Seguramente decidimos después que esto no era tan útil como encontrar caracteres que no eran letras y, aunque cambiamos el texto, olvidamos cambiar el código de muestra. Lo corregiremos en la versión en línea. Lo sentimos mucho.


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

Administración de bases de datos SQL
SQL Sentry Event Manager
sqlsentry.net/event-manager/standard-sql-server.asp
Cuanto más grande y más compleja sea su infraestructura, mayor será su preocupación por el mantenimiento y las tareas operativas que interfieren unas con otras. Esto puede llevar al caos de flujo de procesos para los usuarios finales. Afortunadamente, hay herramientas disponibles para el administrador del sistema y de bases de datos que ayudan a coordinar las programaciones de un entorno complejo.
Una de estas herramientas que quizás desee considerar para su entorno de servidor con varias bases de datos es SQL Sentry Event Manager, una aplicación de servidor de Microsoft® .NET Framework que usa SQL Server® 2000 o SQL Server 2005 de fondo. El usuario conecta a la aplicación de servidor a través de la interfaz de usuario de la consola de SQL Sentry, lo que ofrece una vista unificada de los servidores administrados en el entorno. La aplicación del servidor no tiene agentes, pero esto, como de costumbre, implica que necesitará ejecutarse bajo un contexto de usuario que tiene los derechos de conectar a los equipos y los servicios que desea administrar.
Una de las características más promocionadas de la aplicación es que la interfaz de usuario de la consola ofrece la capacidad de volver a programar las tareas de servidor con tan sólo arrastrar y colocar para ayudar a alinear el mantenimiento y la actividad operativa con el fin de evitar conflictos y tiempo de inactividad. Aunque la interfaz de usuario puede parecer algo complicada al principio, permite detectar rápidamente posibles problemas y encontrar una franja temporal para trasladar cualquier tarea conflictiva. Incluso ofrece una vista similar a la de Microsoft Outlook® de los trabajos de agentes SQL y las tareas programadas de Windows® para los servidores que ha elegido supervisar. Y la vista de calendario destaca las tareas en ejecución prolongada y aquellas con error para ayudarle a detectar y resolver problemas durante el progreso.
Además de la funcionalidad de programación, SQL Sentry tiene un sólido sistema de notificación que elimina la necesidad de usar SQL Mail, MAPI, xp_sendmail o sp_send_dbmail. También distribuye todas las notificaciones de eventos de los servidores administrados a través de su subsistema, lo que da un control centralizado de los tipos, la frecuencia y la distribución de las notificaciones.
Las notificaciones se pueden configurar al nivel global, de servidor y de tarea o trabajo. Esto ofrece la granularidad que la mayoría de los administradores esperan para este tipo de evento. Puede establecer varios tipos diferentes de condiciones de evento para activar una notificación, por ejemplo, cuando un trabajo tarda mucho o muy poco en completarse, cuando un indicador de rendimiento, como la utilización de CPU, alcanza cierto umbral, o cuando un trabajo de agente SQL queda bloqueado por alguna razón. También puede configurar SQL Sentry para que notifique de cambios en la configuración, así sabrá cuándo alguien ajusta la programación, interrumpe una supervisión, etc.
Pero SQL Sentry no se ocupa sólo de trabajos de agente SQL y de eventos del programador de tareas de Windows. La aplicación es compatible también con eventos de planes de mantenimiento, paquetes DTS, tareas de SSIS y con el registro de agente SQL.
Con frecuencia, a los cargos superiores les suele gustar ver lo bien que funcionan los sistemas y, si tiene un historial de tiempo activo del que puede estar orgulloso, probablemente querrá mostrarlo. SQL Sentry tiene varias opciones de creación de informes integradas precisamente para esta tarea, ya que permiten generar e imprimir gráficos estadísticos de tiempo de ejecución y rendimiento. También puede exportar los datos de los informes a XML, CSV o HTML para la inclusión en sus propios documentos y herramientas de creación de informes.
La versión Professional Edition agrega la capacidad de administrar servidores Oracle, además de características como supervisión de servicios de informes, puesta en cola de trabajos de agente SQL, encadenamiento de eventos de servidor ajenos a SQL y calendario para recursos compartidos.

Precio: Versión Standard Edition a partir de 395 dólares.
Programación de mantenimiento con SQL Sentry
Programación de mantenimiento con SQL Sentry

Administración remota de sistemas
Mobile Admin
rovemobile.com/products/ma/features
Como no puede estar en más de un lugar al mismo tiempo, una herramienta de administración de servidor remota móvil es una buena idea para el profesional de TI muy ocupado. Merece la pena echar un vistazo a Mobile Admin, de Rove Mobile (anteriormente, Idokorro Mobile).
Mobile Admin es una instalación cliente/servidor en la que un servidor de comunicaciones (que tiene acceso a los servidores que desea administrar) interactúa con un conjunto de dispositivos portátiles inalámbricos. La parte del servidor de la aplicación no tiene agentes, lo que significa que no tiene que instalar nada en los servidores que desea administrar. Sin embargo, debe dar a este contexto de equipo y aplicación los derechos apropiados de administración remota con el fin de administrar los equipos en la infraestructura.
La mayoría de las principales plataformas móviles pueden obtener acceso al servidor, entre ellas, los Pocket PC y smartphone Windows Mobile®, así como los smartphone BlackBerry. Además, cualquier equipo conectado a Internet con un explorador compatible puede conectar a Mobile Admin (siempre que lo permita su directiva de seguridad).
Una de las primeras preocupaciones para cualquier profesional de sistemas o redes en relación con administraciones móviles es la seguridad. Los usuarios que tienen BlackBerry Enterprise Server pueden cifrar toda la comunicación con TDES (Triple Data Encryption Standard) o AES (Advanced Encryption Standard), ambos compatibles con FIPS (Federal Information Processing Standard).
Además, Mobile Admin amplía la función "kill" en caso de pérdida del BlackBerry, y permite eliminar el software y los datos del teléfono de forma remota. Para otros dispositivos portátiles, puede implementar una VPN para proteger las comunicaciones y/o configurar Mobile Admin para usar un inicio de sesión de Windows, LDAP, RSA SecurID, la autenticación de RADIUS o un inicio de sesión específico de Mobile Admin.
Una vez que ha realizado la conexión, puede llevar a cabo tareas de administración de Windows, por ejemplo, ver y borrar registros de eventos, reiniciar equipos, administrar archivos y directorios, y ver y editar tareas programadas.
En cuanto a la integración de Active Directory®, puede ver, crear, editar, deshabilitar o eliminar usuarios, grupos y equipos. Mientras tanto, para la administración de Exchange, puede cambiar la configuración del buzón de correo, movilizar e inmovilizar colas de mensajes y más.
Con IIS, puede reiniciar grupos de aplicaciones o sitios web, y cambiar la configuración de directorios virtuales. En lo que respecta a servidores SQL, puede ejecutar consultas T-SQL, modificar inicios de sesión, y detener e iniciar trabajos de agente SQL. Y, si ejecuta los Servicios de Cluster Server, puede mover grupos, desconectar recursos y conmutar entre otras tareas administrativas comunes.
Finalmente, Mobile Admin también ofrece compatibilidad para administrar varios aspectos de Oracle, Novell LDAP, Lotus Domino, Citrix, HP iLO, Backup Exec, etc.

Precio: A partir de 245 dólares por servidor.

Reseña de libro
Managing Windows Network Forensics and Investigation
sybex.com
Es posible que cuente con el hardware y los procedimientos adecuados para detectar y mitigar las amenazas contra sus redes. Pero, ¿conoce los procedimientos o dispone de los protocolos que necesita para investigar y, quizás, iniciar procedimientos legales contra infractores que provocan riesgos de seguridad?
Aquí es donde entra en juego el libro Mastering Windows Network Forensics and Investigation (Sybex, 2007). Enseña las habilidades necesarias para investigar a fondo intrusiones de red de Windows, desde incidentes de un solo equipo a escala reducida (como el uso inadecuado de los servicios de la compañía) hasta ataques de mayor envergadura y más generalizados contra sistemas muy importantes.
El libro nos guía por el proceso de recopilación de pruebas, y cubre todos los aspectos, desde entrevistas hasta el seguimiento de eventos y registros auditados. Explica dónde y cómo recopilar las pruebas en equipos y redes de Windows mediante herramientas como WireShark, LogParser, EnCase y el conjunto de herramientas de Sysinternals.
Además, el libro explora la información que se puede obtener del Registro, la estructura y el contenido del sistema de archivos, los registros basados en texto, los registros de eventos y los procesos en los equipos en cuestión. Además, averiguamos cómo crear un CD de análisis activo, que contiene las herramientas que necesita para localizar las pruebas que necesita. Finalmente, el libro trata cómo presentar los resultados de su investigación, con detalles sobre las instrucciones y los procedimientos para testificar ante un tribunal.

Precio: $59.99.

Recopilación de datos del sistema
MetaLAN
hammer-software.com/metalan.shtml
La administración centralizada es uno de los componentes clave de la administración satisfactoria de sistemas. Elimina complicaciones y evita pérdidas de tiempo, lo que reduce la presión a que se ve sometido en el trabajo.
MetaLAN de Hammer Software es una herramienta que le ayuda a administrar usuarios y servidores en su red de Windows. Esta aplicación sin agente permite reunir rápidamente información acerca de los equipos de Windows, administrarlos y realizar cambios en su configuración. Esto, por supuesto, requiere el contexto de usuario y los derechos necesarios para hacerlo.
MetaLAN tiene dos modos de operación. Puede elegir ejecutarlo directamente en modo de administrador (que se ocupa de los equipos en los que desea realizar consultas o modificar propiedades) o puede usar el complemento gratuito agente/servicio, ProbeServer, en el equipo remoto conjuntamente con MetaLAN en modo de servidor para supervisar continuamente las estaciones de trabajo.
Al iniciar la aplicación, obtendrá acceso a la interfaz de usuario del panel de control de MetaLAN, que le da la opción de buscar dominios para administrar en la red actual. Aquí, puede iniciar también varias herramientas, por ejemplo, Help Desk Tool, Report Tool, Software Tool y RegCast Tool.
Help Desk Tool ofrece una vista de búsqueda y exploración de los equipos en el dominio que administra. Si selecciona un equipo, obtendrá información útil acerca del mismo, incluido el fabricante, las direcciones IP, los procesadores, las unidades, las direcciones MAC y las funciones de servidor. Desde aquí, puede ejecutar consultas del Instrumental de administración de Windows (WMI), conectar a monitores de rendimiento en tiempo real, ver el software instalado y realizar otras tareas administrativas muy útiles.
Report Tool ofrece vistas rápidas, exportables y gráficas de sus nodos administrados. Por ejemplo, puede generar un gráfico circular de las velocidades de CPU de todos los equipos en la red o comprobar qué equipos tienen Windows XP Service Pack 2 instalado.
Software Tool permite ver y exportar listas rápidamente del software instalado en un grupo de uno a cualquier número de equipos en la red. Esta es una gran herramienta para auditorías.
Por último, RegCast Tool permite ver (y modificar, si es administrador de dominio o de la empresa) información del Registro en equipos remotos de un grupo seleccionado de equipos.
MetaLAN incluye también una herramienta para implementar e instalar de forma remota paquetes Microsoft Installer (MSI), si son compatibles con la instalación silenciosa, una vista de almacenamiento que muestra cada unidad en los equipos y cuánto espacio libre hay disponible, y una herramienta de administración de servicios que permite iniciar, detener e incluso quitar servicios. Por si esto fuera poco, también incluye una herramienta de control remoto VNC (Virtual Network Computing) con un pequeño archivo ejecutable VNC que ofrece el control remoto del equipo (de forma muy parecida a Asistencia Remota).

Precio: A partir de 75 dólares por un paquete de licencias de 20 nodos.
Help Desk Tool ofrece una vista de búsqueda y exploración.
Help Desk Tool ofrece una vista de búsqueda y exploración.

Automatización de tareas
AutoHotkey
autohotkey.com
La automatización puede ser el mejor amigo de un profesional de TI, pues ayuda a evitar tareas laboriosas y repetitivas. Entre las muchas herramientas en el mercado que pueden ayudarnos en este sentido, encontramos la utilidad AutoHotkey. Esta herramienta gratuita de código abierto simplifica las rutinas de escritorio al automatizar prácticamente cualquier tarea que requiera el uso del teclado, el mouse o incluso de joystick. Se trata de una herramienta de macros y teclas de acceso rápido basada en scripts en esteroides.
AutoHotkey se ejecuta en la bandeja del sistema y, tras el inicio, ejecuta la definición de scripts que ha creado. El programa ejecuta los comandos individuales de script según aparecen en el archivo de scripts. Esto le resultará muy útil para abrir su conjunto favorito de aplicaciones al inicio, por ejemplo. Pero espere, que hay más: también puede definir cualquier número de teclas y cadenas de acceso rápido.
Las teclas de acceso rápido son cualquier combinación de teclas definidas para activar una acción, por ejemplo, el inicio de una aplicación, mostrar Windows en primer plano o simular la acción de desplazamiento de la rueda del mouse.
Por el contrario, las cadenas de acceso rápido son abreviaciones de texto para comandos o frases de escritura frecuente. Además, estas cadenas se pueden usar para iniciar una acción generada por script de forma similar a las teclas de acceso rápido. Por ejemplo, podría crear una cadena de acceso rápido con la sencilla secuencia de teclas "td" para abrir Microsoft Word y escribir la fecha de hoy en el formato que desee. O, si hay un párrafo de respuesta particular que siempre envía a sus usuarios, podría crear una cadena de acceso rápido muy simple para volcar automáticamente el párrafo en un mensaje nuevo de Outlook.
El lenguaje de scripting mismo es compatible con variables, expresiones para operaciones de matemáticas y cadenas, variables globales integradas, funciones, bucles e instrucciones condicionales, así que seguro que podrá crear un script que cubra sus necesidades de administración del sistema. En total, hay más de 100 construcciones y comandos para ayudarle. Por ejemplo, puede simular la acción de arrastrar el cursor del mouse, mostrar cuadros de mensaje, ejecutar operaciones asincrónicas, enviar mensajes de correo electrónico, modificar el Registro, establecer temporizadores en los bucles para realizar comprobaciones periódicas, abrir aplicaciones, cerrar ventanas y eliminar procesos.
Otra estupenda característica de AutoHotkey es que puede compilar sus scripts para volverlos a emplear y distribuir una vez que los ha adaptado a sus necesidades. De este modo, los usuarios que no tienen la herramienta AutoHotkey instalada pueden utilizar sus scripts y accesos directos. Y, debido a la licencia del proyecto de código abierto, puede distribuirlos o venderlos sin restricciones.
En su organización interna, podría distribuir fácilmente a los usuarios finales un script ejecutable que realice algún conjunto de personalizaciones que, de otro modo, tendría que llevar a cabo manualmente en sus equipos. Además, si necesita adaptar los scripts a cada usuario, AutoHotkey acepta también parámetros y modificadores de línea de comandos, así que aquí tiene algo que es útil y reutilizable en el dominio.
A diferencia de muchos proyectos de código abierto, que a menudo carecen de profundidad en la documentación, la documentación de AutoHotkey es completa y está bien diseñada, y enseña lo necesario para generar por script las tareas de automatización con muchos ejemplos buenos y útiles. Además, en el sitio web del proyecto, encontrará un foro activo de usuarios para resolver cualquier pregunta y un wiki que contiene scripts, tutoriales y una referencia de comandos. También hay una página de presentación de scripts que ofrece un buen conjunto de ejemplos utilizables proporcionados por usuarios.

Precio: Producto gratuito.
AutoHotkey puede compilar scripts para volverlos a emplear y distribuir.
AutoHotkey puede compilar scripts para volverlos a emplear y distribuir.

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


 Utility Spotlight: Certificaci&#243;n del logotipo de Windows Server
Utility Spotlight
Certificación del logotipo de Windows Server
Venkat Krishnamachari
Descargar el código de este artículo: Works with Windows Server 2008 (KB)

Con la certificación de software de Windows Server® 2008, Microsoft trata de ayudar a los desarrolladores a utilizar los procedimientos recomendados, y permite a los profesionales de TI evaluar las aplicaciones antes de la compra, lo que ahorra tiempo y fastidios. Con el fin de asistir a los clientes en la evaluación de la compatibilidad de las aplicaciones, Microsoft ha creado el programa "Works with Windows Server 2008", que incluye herramientas de prueba de compatibilidad gratuitas para ayudar a garantizar que las aplicaciones proporcionarán una experiencia previsible.
La herramienta "Works with" recopila datos acerca de la repercusión de la aplicación en el sistema operativo durante su ciclo de vida al supervisar el estado del sistema de archivos, del Registro, de los servicios y los controladores. La herramienta analiza estos datos e informa de errores y logros en casos de prueba. El documento "Works with" Test Framework y las herramientas adicionales, disponibles en windowsservercatalog.com/ready, ofrecen más información. Estas herramientas ayudan a los ISV a integrar compatibilidad en las aplicaciones y a los profesionales de TI a evaluar la aptitud de las aplicaciones para la implementación en Windows Server 2008.
Para usar estas herramientas, instale primero la última versión de Windows Server 2008 en un equipo de prueba, descargue la herramienta "Works with" de windowsservercatalog.com/ready y asegúrese de incluir la herramienta Application Verifier. La GUI de la herramienta tiene cuatro funciones sencillas: crear un paso de prueba, reanudar un paso de prueba existente, ver los resultados de la prueba y crear un paquete de envío (para ISV que requieren la validación de "Works with" por parte de un proveedor de pruebas autorizado).
Informe de texto con resultados
Informe de texto con resultados
La creación de un paso de prueba se realiza al recorrer el ciclo de vida de una aplicación: instalación, configuración, ejecución y desinstalación. La herramienta "Works with" se ejecuta principalmente de fondo: comprueba la estabilidad del sistema operativo y la compatibilidad del instalador, además de observar si las características se ejecutan apropiadamente dados los requisitos de seguridad nuevos de la plataforma y otras características configurables. Generalmente, es mejor completar el paso de prueba y generar el informe completo, que suele llevar de dos a cuatro horas. Sin embargo, puede detener un paso de prueba, generar un informe rápido y reanudar la prueba más tarde.
Cuando termine, tendrá informes de estado claros en rojo o verde de cada caso de prueba con resultados detallados, como los que se muestran en la captura de pantalla. Las pruebas en verde indican compatibilidad satisfactoria. En el caso de obtener resultados en rojo, podrá revisar un archivo de registro que ayuda a entender la condición del error. Asegúrese de guardar los registros generados de forma local en otro equipo; le servirán de referencia futura tras eliminar el equipo de prueba. La herramienta "Works with" se ejecuta en cualquier aplicación de servidor, y también puede evaluar componentes de cliente y herramientas de administración que se han diseñado para Windows Vista®.
Si usa software comercial, la herramienta "Works with" puede ayudarle a planear la migración con aplicaciones compatibles conocidas. Puede usar los resultados de prueba para consultar a proveedores sobre planes de compatibilidad a la vez que ahorra tiempo a los desarrolladores, que no tendrán que dedicar sus esfuerzos a descubrir problemas y aplicar correcciones. En cuanto a aplicaciones personalizadas, puede ofrecer información sumamente específica a los equipos de desarrollo. También podrá confirmar la compatibilidad continuada según se publiquen nuevas revisiones y documentar datos de configuración de las aplicaciones para el departamento de TI. Algunos clientes han usado las herramientas para documentar los archivos que utilizan las aplicaciones del sistema.
Nos interesa su opinión sobre cómo podemos mejorar los casos de prueba o las herramientas para ampliar las posibilidades de uso en su entorno. Envíe sus comentarios a la dirección wslogofb@microsoft.com.

Venkat Krishnamachariha sido técnico principal encargado de la certificación de software de Windows Server desde 2005; previamente, había trabajado en el equipo que lanzó SQL Server 2005.


 The Cable Guy: Migraci&#243;n de la intranet a IPv6 con ISATAP
The Cable Guy
Migración de la intranet a IPv6 con ISATAP
Joseph Davies
Este artículo se basa en una versión preliminar de Windows Server 2008. Por tanto, toda la información de este documento está sujeta a cambios.

Un concepto erróneo bastante frecuente acerca del protocolo de Internet versión 6 (IPv6) es que, con el objeto de usarlo, debe implementar el direccionamiento y el enrutamiento nativos de IPv6, lo cual requiere un análisis detallado de los esquemas de direccionamiento de IPv6, las actualizaciones y la configuración del enrutador, así como un programa de lanzamiento. Si bien, eventualmente, esto debería hacerse para la conectividad nativa de
IPv6, es posible implementar fácilmente la conectividad IPv6 de túnel mediante el Protocolo de direccionamiento automático de túnel dentro de un sitio (ISATAP). Con conectividad IPv6 de túnel, los hosts compatibles con ISATAP pueden comunicarse mediante el tráfico IPv6 encapsulado con un encabezado IPv4 (el campo del Protocolo IPv4 se establece en 41). El tráfico de ISATAP puede atravesar una intranet de sólo IPv4, por lo que puede comenzar a probar las aplicaciones compatibles con IPv6 inmediatamente, sin tener que esperar una infraestructura nativa de IPv6.
ISATAP es una tecnología de asignación de direcciones y de tunelización automática definida en RFC 4214 que ofrece conectividad unidifusión IPv6 entre hosts IPv6/IPv4 a través de una intranet de sólo IPv4. Los hosts ISATAP usan una interfaz de tunelización lógica a la que se asignan direcciones ISATAP, que tienen la forma UnicastPrefix:0:5EFE:w.x.y.z (cuando w.x.y.z es una dirección IPv4 privada asignada al host ISATAP) o UnicastPrefix:200:5EFE:w.x.y.z (cuando w.x.y.z es una dirección IPv4 pública asignada al host ISATAP). UnicastPrefix es un prefijo de dirección unidifusión de 64 bits. Aquí se incluyen prefijos locales de vínculo, globales y locales únicos. Ejemplos de direcciones ISATAP son 2001:DB8::98CA:200:131.107.28.9 y 2001:DB8::98CA:0:10.91.211.17.

Migración de intranet a IPv6 con ISATAP
Una implementación de ISATAP consiste en una o más subredes ISATAP lógicas, que son redes de sólo IPv4 a las que se ha asignado un prefijo de subred IPv6 de 64 bits. En una subred ISATAP lógica, hay hosts ISATAP y enrutadores ISATAP. Un host ISATAP usa una interfaz de tunelización de ISATAP para encapsular el tráfico IPv6. Este tráfico puede enviarse directamente a otros hosts ISATAP en la misma subred ISATAP lógica. Para alcanzar los destinos que están en otras subredes ISATAP o en subredes IPv6 nativas, el tráfico se envía a un enrutador ISATAP. Un enrutador ISATAP es un enrutador de IPv6 que anuncia prefijos de subred a los hosts ISATAP y reenvía el tráfico IPv6 entre los hosts ISATAP y los hosts de otras subredes IPv6. La Figura 1 muestra los componentes de ISATAP en una intranet simplificada.
Figura 1 Partes de sólo IPv4 y partes con capacidad para IPv6 de la intranet
Figura 1 Partes de sólo IPv4 y partes con capacidad para IPv6 de la intranet
ISATAP permite implementar capacidades de direccionamiento y enrutamiento nativos de IPv6 en la intranet en tres fases.
Fase 1: Intranet de sólo IPv4 En esta fase, toda la intranet puede ser una única subred ISATAP lógica. La Figura 2 muestra un ejemplo con una intranet de sólo IPv4 con un enrutador ISATAP que sólo anuncia un prefijo de dirección global o local único a los hosts ISATAP.
Figura 2 Una intranet de sólo IPv4
Figura 2 Una intranet de sólo IPv4
Fase 2: Partes de sólo IPv4 y partes con capacidad para IPv6 de la intranet En esta fase intermedia, la intranet tiene una parte de sólo IPv4 (la subred ISATAP lógica) y una parte con capacidad para IPv6. La parte con capacidad para IPv6 de la intranet es compatible con IPv4 y se ha actualizado para ofrecer compatibilidad con el direccionamiento y el enrutamiento nativos de IPv6. Ya vimos esta configuración en la Figura 1.
Fase 3: Intranet con capacidad para IPv6 En esta fase final, toda la intranet es compatible con IPv4 y con el direccionamiento y el enrutamiento nativos de IPv6. Tenga en cuenta que ISATAP ya no es necesario. La Figura 3 muestra un ejemplo.
Figura 3 Intranet con capacidad para IPv6
Figura 3 Intranet con capacidad para IPv6
Con ISATAP, puede tener conectividad IPv6 entre hosts y aplicaciones durante las primeras dos fases de la transición de una intranet de sólo IPv4 a una intranet con capacidad para IPv6.

Windows Server 2008 y Windows Vista
El protocolo IPv6 para Windows Server® 2008 y Windows Vista® es compatible con ISATAP como host ISATAP y como enrutador ISATAP. Hay una interfaz de tunelización de ISATAP independiente para cada interfaz LAN que se encuentra instalada en el equipo que tenga un sufijo DNS diferente. Por ejemplo, si un equipo que ejecuta Windows Vista tiene dos interfaces LAN, ambas están asociadas a la misma intranet y se les ha asignado el mismo sufijo DNS, sólo habrá una interfaz de tunelización de ISATAP. Si estas dos interfaces LAN están asociadas a dos redes distintas con sufijos DNS diferentes, habrá dos interfaces de tunelización de ISATAP. Para equipos que ejecutan Windows Server 2008 o Windows Vista SP1, las interfaces de túnel ISATAP se colocan en un estado de medios desconectados a menos que se pueda resolver el nombre "ISATAP".
De manera predeterminada, el protocolo IPv6 para Windows Vista sin service packs instalados automáticamente configura direcciones ISATAP locales de vínculo (FE80::5EFE: w.x.y.z o FE80::200:5EFE:w.x.y.z) en las interfaces de túnel ISATAP para las direcciones IPv4 que se asignan a las interfaces LAN correspondientes.
El protocolo IPv6 para Windows Server 2008 y Windows Vista SP1 configura direcciones ISATAP locales de vínculo en interfaces de túnel ISATAP sólo si el nombre "ISATAP" se puede resolver.
Para recibir un mensaje de anuncio de enrutador desde el enrutador ISATAP, el host ISATAP debe enviar al enrutador ISATAP un mensaje de solicitud de enrutador. En una subred Ethernet, un host IPv6 nativo envía un mensaje de solicitud de enrutador multidifusión y, a continuación, los enrutadores de la subred responden con un mensaje de anuncio de enrutador. Puesto que ISATAP no usa el tráfico multidifusión IPv4 ni requiere una infraestructura con capacidad multidifusión IPv4, el host ISATAP debe llevar a cabo la unidifusión del mensaje de solicitud de enrutador al enrutador ISATAP.
Para llevar a cabo la unidifusión del mensaje de solicitud de enrutador al enrutador ISATAP, el host ISATAP debe determinar, en primer lugar, la dirección IPv4 unidifusión de la interfaz del enrutador ISATAP en la subred ISATAP lógica. Para el protocolo IPv6 de Windows Server 2008 y Windows Vista, un host ISATAP obtiene la dirección IPv4 unidifusión del enrutador ISATAP a través de la resolución satisfactoria del nombre de host "ISATAP" en una dirección IPv4 o con el comando netsh interface isatap set router.

Migración de la intranet: Fase 1:
Con el objeto de implementar ISATAP en la intranet para la fase 1 de su migración a IPv6, necesita llevar a cabo los pasos siguientes:
Determinar el prefijo de subred ISATAP Debe determinar el prefijo de subred de 64 bits para asignarlo a la subred ISATAP lógica correspondiente a su intranet. Puede obtener un prefijo de 48 bits de un ISP o de un registro de Internet, o puede derivar su propio prefijo local único de 48 bits (consulte RFC 4193 en línea en tools.ietf.org/html/rfc4193).
A partir del prefijo de 48 bits, elija un identificador de subred de 16 bits para la subred ISATAP lógica. El resultado de la combinación del prefijo de 48 bits y del identificador de subred de 16 bits es el prefijo de subred ISATAP de 64 bits. Por ejemplo, el prefijo local único de 48 bits FD8A:219C:052A::/48 y el identificador de subred 1 forman el prefijo de subred de 64 bits FD8A:219C:052A:1::/64.
Designar un equipo de enrutador ISATAP Determine qué equipo será el enrutador ISATAP. Aunque muchos enrutadores comerciales son compatibles con la funcionalidad de enrutador ISATAP, la información que presento aquí es específica para los equipos que ejecutan Windows Server 2008.
El equipo de enrutador ISATAP no necesita varias interfaces LAN, ni necesita estar conectado a una parte con capacidad para IPv6 de la intranet para la fase 1. Sin embargo, debe elegirse el equipo que posteriormente pueda actualizarse con una interfaz LAN adicional conectada a la parte con capacidad para IPv6 de la intranet.
Configurar el equipo de enrutador ISATAP En el equipo de enrutador ISATAP, la publicación del siguiente comando ubica las interfaces de tunelización de ISATAP en el equipo de enrutador ISATAP en un estado de medios conectados:
netsh interface isatap set router IPv4Address
IPv4Address es la dirección IPv4 asignada a la interfaz LAN del equipo de enrutador ISATAP asociado a la subred ISATAP lógica.
A continuación, determine el nombre o índice de la interfaz de tunelización de ISATAP que corresponde a la interfaz LAN del equipo de enrutador ISATAP asociado a la subred ISATAP lógica, todo a partir del resultado de este comando:
netsh interface ipv6 show interfaces
Después, use este comando para habilitar los anuncios en la interfaz ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex advertise=enabled
ISATAPInterfaceNameOrIndex es el nombre o índice de la interfaz de tunelización de ISATAP.
A continuación, use este comando con el fin de configurar el equipo de enrutador ISATAP para anunciar el prefijo de subred ISATAP a los hosts ISATAP:
netsh interface ipv6 add route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex publish=yes
ISATAPSubnetPrefix es el prefijo de subred ISATAP determinado.
Configurar DNS En su DNS, agregue un registro (A) de dirección para el nombre ISATAP a los dominios apropiados de forma que los hosts ISATAP de la intranet puedan resolver satisfactoriamente el nombre "ISATAP". Por ejemplo, si los hosts de la intranet usan el sufijo DNS contoso.com, ahora debe agregar un registro A al dominio contoso.com para el nombre isatap.contoso.com con la dirección IPv4 que se asigna a la interfaz LAN del enrutador ISATAP en la intranet de sólo IPv4.
Si el servidor DNS ejecuta Windows Server 2008, use el editor del Registro (regedit.exe) en el servidor DNS para quitar la entrada de ISATAP del valor del Registro HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DNS\Parameters\GlobalQueryBlockList.
Probar los hosts ISATAP Desde un host ISATAP en la intranet, use la herramienta Ipconfig para ver las direcciones asignadas. Los hosts ISATAP deben tener una dirección con el formato ISATAPSubnetPrefix:: 5EFE:w.x.y.z o ISATAPSubnetPrefix:: 200:5EFE:w.x.y.z. Por ejemplo, si su prefijo de subred ISATAP es FD8A:219C: 052A:1::/64 y un host ISATAP tiene la dirección IPv4 10.1.31.97, el host ISATAP debe tener la dirección FD8A: 219C:052A:1::5FE:10.1.31.97 asignada a su interfaz de tunelización de ISATAP.
Si un host ISATAP no tiene una dirección ISATAP basada en el prefijo de subred ISATAP, compruebe que el host puede resolver el nombre "ISATAP". En caso contrario, compruebe que los registros A se han creado en los dominios apropiados y, para los servidores DNS que ejecutan Windows Server 2008, compruebe que el valor del Registro GlobalQueryBlockList se ha modificado para quitar la entrada de ISATAP. Si se puede resolver el nombre, compruebe que el equipo de enrutador ISATAP se ha configurado correctamente. Si se ha configurado, compruebe que los enrutadores en la intranet permiten el reenvío del tráfico del protocolo IPv4 en 41.
Cuando los hosts ISATAP se pueden configurar así mismos correctamente con direcciones basadas en el prefijo de subred ISATAP, estos registran las direcciones ISATAP como registros AAAA en el DNS y comienzan a usarlas para la conectividad basada en IPv6.

Migración de la intranet: Fase 2
En la fase 2 de la migración a IPv6, es necesario que modifique la configuración del enrutador ISATAP para realizar el reenvío entre la parte de sólo IPv4 y la parte con capacidad para IPv6 de la intranet.
En el equipo de enrutador ISATAP, publique el comando siguiente:
netsh interface ipv6 show interfaces
A partir del resultado del comando anterior, determine el nombre o índice de la interfaz LAN asociada a la parte con capacidad para IPv6 de la intranet y la interfaz de tunelización de ISATAP.
Use este comando para habilitar el reenvío en la interfaz ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=enabled
Use este comando para habilitar el reenvío en la interfaz LAN:
netsh interface ipv6 set interface LANInterfaceNameOrIndex forwarding=enabled
LANInterfaceNameOrIndex es el nombre o índice de la interfaz LAN.
Use el siguiente comando para agregar una ruta predeterminada al enrutador ISATAP:
netsh interface ipv6 add route ::/0 LANInterfaceNameOrIndex NextHopAddress publish=yes
NextHopAddress es la dirección IPv6 de un enrutador IPv6 nativo y vecino en la parte con capacidad para IPv6 de la intranet.
Para que la subred ISATAP lógica sea accesible desde la parte con capacidad para IPv6 de la intranet, es importante que configure los enrutadores IPv6 nativos con una ruta para el prefijo de subred ISATAP que señala al equipo de enrutador ISATAP.
Para deshabilitar de manera selectiva ISATAP de los equipos en la parte con capacidad para IPv6 de la intranet, manipule los registros A para el nombre ISATAP en su DNS de manera que los equipos en la parte con capacidad para IPv6 de la intranet no puedan resolver el nombre ISATAP.
Otra opción con la que cuenta es crear y establecer el valor del Registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip6\Parameters\DisabledComponents en 0x4 (tipo DWORD).

Migración de la intranet: Fase 3
Para la fase 3, cuando toda la intranet tiene capacidad para IPv6, necesitará quitar la implementación de ISATAP a través de DNS y volver a configurar el equipo de enrutador ISATAP. Para DNS, quite todos los registros A para el nombre ISATAP. Esto evitará que cualquier host determine la dirección IPv4 del enrutador ISATAP.
Para el equipo de enrutador ISATAP, ejecute el comando siguiente:
netsh interface isatap set router default
Este comando vuelve a establecer el componente ISATAP en su estado predeterminado.
Determine el nombre o índice de la interfaz de tunelización de ISATAP a partir del resultado de este comando:
netsh interface ipv6 show interfaces
Use este comando para deshabilitar el reenvío y los anuncios en la interfaz ISATAP:
netsh interface ipv6 set interface ISATAPInterfaceNameOrIndex forwarding=disabled advertise=disabled
Use este comando para quitar la ruta del prefijo de subred ISATAP del equipo de enrutador ISATAP:
netsh interface ipv6 delete route ISATAPSubnetPrefix ISATAPInterfaceNameOrIndex
ISATAPSubnetPrefix es el prefijo de subred ISATAP.
Para obtener más información acerca de la implementación de ISATAP, incluidos detalles acerca de consideraciones de enrutadores y firewalls ISATAP redundantes, consulte la "Guía de implementación del Protocolo de direccionamiento automático de túnel dentro de un sitio" en go.microsoft.com/fwlink/?LinkId=106926.

Joseph Davies es escritor técnico de Microsoft, y enseña y escribe sobre temas de red de Windows desde 1992. Ha escrito ocho libros para Microsoft Press y es autor de la columna mensual en línea Cable Guy de TechNet. Para obtener más detalles acerca de The Cable Guy, consulte microsoft.com/technet/community/columns/cableguy/about.mspx.


 Windows PowerShell: Informe de progreso
Windows PowerShell
Informe de progreso
Don Jones

Recientemente escribí un script bastante largo y complicado de Windows PowerShell que, durante la ejecución, dejaba de responder casi por completo. Lo escribí para la ejecución como tarea programada, así que no producía prácticamente resultados visibles. Al ejecutar la primera prueba importante, me preocupó la idea de que,
accidentalmente, quizás había escrito un bucle infinito o algún otro tipo de script problemático.
Cuando vi que el shell permanecía inmóvil, con el parpadeo patético de su cursor, me pregunté: "¿He acabado con el shell?" Aparentemente, no tengo confianza en mí mismo porque presioné rápidamente las teclas Ctrl+C para interrumpir el script. Hora de hacer uso de un informe de progreso.

Tonterías, nada más que tonterías
Cmdlet del mes: Tee-Object
Este mes, quiero echar un vistazo a uno de mis cmdlets de solución de problemas favoritos. Veamos este ejemplo:
Get-WMIObject Win32_Service | Where { $_.State -ne "Running"
-and $_.StartMode -eq "Automatic" } | ForEach-Object { $_.Start() }
A simple vista, parece que esto iniciaría todos los servicios que están establecidos para el inicio automático; por alguna razón, todavía no se han iniciado. Sin embargo, esto no funciona realmente, y averiguar por qué no funciona puede ser complicado, ya que no podemos ver lo que ocurre dentro de la canalización. Bueno, no podemos ver lo que ocurre dentro de la canalización a menos que usemos Tee-Object.
Tee-Object redirecciona objetos a un archivo (o a una variable) y los pasa por la canalización. Por ejemplo:
Get-WMIObject Win32_Service | Tee-Object AllServices.csv | Where
{ $_.State -ne "Running" -and $_.StartMode -eq "Automatic" } |
Tee-Object FilteredServices.csv | ForEach-Object { $_.Start() }
Esta modificación me permite ver lo que sucede después de cada comando de canalización. Así, descubro rápidamente que mi archivo FilteredServices.csv no contiene nada. No es de extrañar que el script no funcione. Al investigar un poco más, vemos la causa raíz del problema: StartMode es "Auto", no "Automatic". Tee-Object me permite localizar con toda precisión el lugar exacto del problema.

Lo primero que quería hacer era agregar varios mensajes de estado para saber exactamente lo que hacía el script. El shell permite hacer esto fácilmente con el cmdlet Write-Verbose. Adelante; pruébelo en el shell:
Write-Verbose "Test Message"
Si lo ha probado, habrá advertido que no hace nada. Eso es porque Write-Verbose envía objetos a la canalización Verbose especial que, de forma predeterminada, no muestra su resultado. Una variable integrada del shell, $VerbosePreference, controla esta canalización. El valor predeterminado de esta variable es SilentlyContinue, que suprime los resultados detallados. La configuración en Continue abre la canalización:
$VerbosePreference = "Continue"
Ahora puedo agregar varias instrucciones Write-Verbose a mi script y obtener detalles sobre lo que pasa durante la ejecución. Y lo mejor de esta técnica es que, al acabar de probar y solucionar problemas, puedo eliminar todos los estorbos adicionales mediante la configuración de $VerbosePreference una vez más en SilentlyContinue al principio del script.
No hay necesidad de quitar todas las instrucciones Write-Verbose. De hecho, al permanecer en el script, cada vez que necesito ejecutar el script manualmente, puedo volver a activar fácilmente la canalización Verbose si es necesario.

Pero necesito progreso real.
Cuando quedé satisfecho de que el script no estaba atrapado en un bucle infinito y que, de hecho, funcionaba perfectamente, desactivé la canalización Verbose y lo ejecuté otra vez, para asegurarme.
El problema ahora es que, a pesar de saber que el script funciona perfectamente, no puedo soportar la vista de un cursor intermitente. Tengo problemas de concentración. Busqué desesperadamente algo de pintura; así, al menos, podría sentarme a mirar cómo se seca.
Lo que necesitaba era una indicación general del progreso del script y una idea aproximada de cuándo acabaría. Básicamente, quería una barra de progreso o algo así.
Afortunadamente, Windows PowerShellTM incluye el cmdlet Write-Progress. Este cmdlet no ofrece una barra de progreso gráfica como vemos en Windows®, pero produce una barra de progreso bastante decente, como muestra la Figura 1. Tiene un aspecto similar a la barra de progreso de copia de archivo que usa la parte basada en texto de la configuración en Windows Server ® 2003 o incluso en Windows XP.
Figura 1 ¿Cuál es el progreso del script?
Figura 1 ¿Cuál es el progreso del script?
El uso de Write-Progress requiere un poco de explicación. Pienso que un ejemplo sería aún mejor. Considere este script:
for ($a=1; $a -lt 100; $a++) {
  Write-Progress -Activity "Working..." `
   -PercentComplete $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Usa Write-Progress para mostrar una barra de progreso. He usado Start-Sleep con el fin de interrumpir el script un segundo cada vez en el bucle para que se ejecute con la lentitud necesaria que nos permita ver el progreso: sin estas pausas, el bucle cuenta de 0 a 100 tan rápidamente que la barra de progreso sólo se ilumina brevemente en la pantalla.
Como puede ver, Activity, que he establecido en Working, se muestra en la parte superior de la barra de progreso. Status se muestra justo debajo, y CurrentOperation aparece en la parte inferior. El shell sólo es compatible con una barra de progreso cada vez. Cada uso de Write-Progress creará una barra de progreso nueva, si no se muestra una actualmente, o actualiza la barra actual.
Lo que no he hecho aquí es indicar a la barra que debe desaparecer en cuanto termine. Puedo hacerlo al agregar esto al final del script:
Write-Progress -Activity "Working..." `
 -Completed -Status "All done."
Por lo general, la barra de progreso desaparecerá por sí sola una vez que ha finalizado el script pero, si el script tiene otras cosas que hacer, deseará ocultar la barra de progreso cuando ya no la necesite. El parámetro -Completed quita simplemente la barra de la pantalla.

Tick, Tick, Tick
Otro uso común de Write-Progress es mostrar los segundos de ejecución que quedan, en lugar de una barra de progreso. Por ejemplo:
for ($a=100; $a -gt 1; $a--) {
  Write-Progress -Activity "Working..." `
   -SecondsRemaining $a -CurrentOperation
   "$a% complete" `
   -Status "Please wait."
  Start-Sleep 1
}
Todo lo que he hecho aquí es cambiar el recuento del bucle de 100 a 1, y he usado el parámetro SecondsRemaining de Write-Progress, en lugar de PercentComplete. El resultado aparece en la figura 2. Como puede ver, el indicador de progreso ha desaparecido; ha quedado reemplazado por un reloj de cuenta atrás. El shell convierte automáticamente el número total de segundos que quedan en horas, minutos y segundos, lo que simplifica la información. El porcentaje completado que se muestra aquí cuenta hacia atrás desde 100, lo que corresponde al parámetro CurrentOperation que he proporcionado. No se produce el cálculo real del porcentaje completado; Windows PowerShell muestra simplemente el valor de $a seguido de la cadena "% complete".
Figura 2 ¿Cuánto queda para que se complete el script?
Figura 2 ¿Cuánto queda para que se complete el script?

Scripts capaces de comunicación
Me encanta escribir scripts que comunican lo que andan haciendo, ya sea en formato de resultados detallados o mediante una barra de progreso sencilla. Esto puede beneficiarme a mí, que tengo problemas de concentración, o a cualquiera que necesite ejecutar mi script dentro de unos meses. En última instancia, mostrar algún tipo de información de estado y progreso será una gran ventaja.

Don Jones es editor colaborador de la revista TechNet Magazine y coautor de Windows PowerShell: TFM (SAPIEN Press, 2007). Se dedica a enseñar Windows PowerShell (www.ScriptingTraining.com) y puede ponerse en contacto con él a través del sitio web ScriptingAnswers.com.


 &#161;Hola, encargados del scripting!: Nuestros juegos de shell favoritos
¡Hola, encargados del scripting!
Nuestros juegos de shell favoritos
Los chicos del scripting de Microsoft
Descargar el código de este artículo: HeyScriptingGuy2008_03.exe (150KB)

Según un proverbio antiguo, ni tan siquiera el gorrión más diminuto puede caer al suelo sin que lo sepan los cielos. Con esto, los chicos del scripting no quieren decir que la gente vaya por ahí matando gorriones. Aunque si hay alguien que quiera ocuparse de esos cuervos que se posan en el tejado y empiezan a graznar a las 7:00 de la mañana todos los sábados..., eso es un cuento diferente. (El editor de scripting adora los cuervos, así que estamos seguros de que, al decir "ocuparse", el chico del scripting que escribe esta columna quiere decir "asegurarse de que están sanos." -El editor) No obstante, es todo un alivio saber que, si se cae, hay a quien le importa y que, por pequeño e insignificante que parezca, hay quien está pendiente de lo que pueda pasarle. (Aunque se trate de un simple editor. -El editor)
Lo que se aplica a los gorriones resulta ser verdadero también en materia de scripting para administración de sistemas. Se puede decir que, en el mundo del scripting, la mayor parte de la atención se centra en los grandes kahunas del scripting: Windows PowerShellTM, VBScript, WMI, ADSI e, incluso, FileSystemObject. Es comprensible que estas tecnologías se lleven todo el mérito y la publicidad. A fin de cuentas, permiten hacer muchas cosas útiles y maravillosas. Pero eso no significa que estas sean las únicas tecnologías disponibles para trabajar con scripts. Ni mucho menos.
Tomemos el objeto Shell como ejemplo. Aunque el objeto Shell no es tan conocido ni popular como Windows PowerShell, es útil e importante.
Hay muchas posibilidades de que, tarde o temprano, alguien le pedirá que escriba un script de administración del sistema que usa el objeto Shell. Esto da origen a una pregunta obvia: ¿Qué se puede hacer exactamente con el objeto Shell? Resulta que hay muchas cosas fantásticas que se pueden hacer con el objeto Shell. Algunas de ellas (por ejemplo, administrar la cuota de disco y mostrar una barra de progreso durante la copia o el traslado de archivos) ya se han descrito en Microsoft® Windows® 2000 Scripting Guide (microsoft.com/technet/scriptcenter/guide). En la columna de este mes, le mostraremos algunas otras cosas ingeniosas que puede hacer con el objeto Shell, cosas que probablemente no tenía ni la menor idea de que podían hacerse en absoluto, mucho menos con el objeto Shell.

Cambios en la fecha de última modificación de un archivo
Seguro que hay quien se queda mirando este título anterior y piensa: "Oye, espera un segundo. No se puede cambiar la fecha de última modificación de un archivo con un script, por lo menos, eso no se puede hacer con VBScript". A esto, solamente podemos decir una cosa: ¿De dónde ha sacado semejante idea?
Ya sé; seguramente eso es algo que los chicos del scripting hemos dicho en el pasado. Bueno, pues resulta que estábamos equivocados. ¡Qué sorpresa, ¿eh?! Es posible cambiar la fecha de última modificación de un archivo con VBScript. Y todo lo que hay que hacer es usar el objeto Shell.
Nota: no se moleste en preguntar cómo es posible que los chicos del scripting se equivocaran en algo así; después de todos estos años, eso debería ser obvio. Una pregunta mucho más interesante es esta: ¿Cómo nos las arreglamos para hacer algo bien en ocasiones?
Así que desea cambiar la fecha de última modificación de un archivo, ¿eh? Entonces, use este script:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")

objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Como puede ver, no hay nada terriblemente complicado en el asunto. Empezamos por crear una instancia del objeto Shell.Application. A propósito, no confunda Shell.Application con Wscript.Shell, el objeto Shell de Windows Script Host. El objeto Shell con que trabajamos hoy es el objeto Shell de Windows. Una vez que nuestra instancia del objeto Shell está en funcionamiento, usamos el método Namespace para enlazar a la carpeta C:\Scripts y, luego, usamos el método ParseName, con un nombre un tanto extraño, para enlazar a un archivo específico dentro de dicha carpeta. En este caso, enlazamos a una imagen JPEG con el nombre de archivo Dr_Scripto. jpg:
Set objFolderItem = _
  objFolder.ParseName("Dr_Scripto.jpg")
¿Y qué hacemos después de enlazar al archivo mismo? Eso es fácil; simplemente asignamos una fecha y una hora nuevas a la propiedad ModifyDate:
objFolderItem.ModifyDate = _
  "01/01/2008 8:00:00 AM"
Eso es todo lo que debemos hacer.
Sabe, tiene razón. Eso es fantástico. Una vez que ejecutamos el script, la fecha de última modificación del archivo estará establecida en 01/01/08 8:00. Si lo desea, puede abrir la carpeta C:\Scripts en el Explorador de Windows para comprobarlo.
Por supuesto, habrá quien esté pensando: "Perfecto. Es posible cambiar la fecha de última modificación de un archivo. Pero, ¿por qué querría cambiar la fecha de última modificación de un archivo? Mucha gente usa la fecha de última modificación de los archivos como sistema de control de versiones. Por ejemplo, si tiene varias copias de un script, una forma de realizar el seguimiento de la versión oficial es comprobar la fecha de última modificación. Así, sabrá que una copia particular del script es una versión sin modificar del script original.
Nota: de acuerdo, lo sabemos, alguien puede ejecutar el script que acabamos de mostrar y cambiar la fecha de última modificación. Pero, a menos que firme todo lo que hace mediante código, siempre se puede encontrar alguna manera de vencer al sistema. Si damos por sentado que los compañeros con los que comparte los scripts son de confianza, este es un enfoque razonable.
En algún momento, quizás decida que desea actualizar, y estandardizar, la fecha de última modificación de todos sus scripts. ¿Cómo puede hacerlo? Bien, si todos sus scripts están en la carpeta C:\Scripts, puede ejecutar el código siguiente:
Set objShell = _
  CreateObject("Shell.Application")

Set objFolder = _
  objShell.NameSpace("C:\Scripts")
Set colItems = objFolder.Items

For Each objItem In colItems
    objItem.ModifyDate  = _
      "01/01/2008 8:00:00 AM"
Next
Como puede ver, este script empieza de forma muy semejante al primer script que mostramos. Sin embargo, en este caso, después de enlazar a la carpeta C:\Scripts, no usamos ParseName para enlazar a un archivo individual en esta carpeta. En su lugar, usamos esta línea de código para devolver una colección de todos los archivos en la carpeta:
Set colItems = objFolder.Items
Una vez que tenemos la colección, configuramos un bucle For Each que pase por todos los elementos de la colección. Dentro del bucle For Each, usamos esta práctica línea de código para cambiar el valor de la propiedad ModifyDate del primer archivo de la colección a 01/01/08 8:00:
objItem.ModifyDate  = _
  "01/01/2008 8:00:00 AM"
A continuación, simplemente pasamos el bucle y repetimos el proceso con el siguiente archivo de la colección. Al terminar, todos los archivos de la carpeta C:\Scripts (bueno, excepto los archivos ocultos) tendrán la misma fecha de última modificación. ¿Ve que fácil es? Entonces, ¿quién ha dicho que no es posible cambiar la fecha de última modificación de un archivo con VBScript?
Ah, cierto.

Hablando de meter la pata...
En un tiempo inmemorable, cuando los chicos del scripting empezaron a trabajar con scripting de administración de sistemas, no había manera de obtener acceso a toda la información extendida que se asocia a los archivos en el sistema de archivos NTFS. Por ejemplo, si hace clic con el botón secundario en un archivo .wav y luego en Propiedades, verá información semejante a la que muestra la Figura 1.
Figura 1 Resumen de propiedades de archivo
Figura 1 Resumen de propiedades de archivo
¿Cómo se pueden recuperar valores, como la velocidad de bits o el tamaño de muestra de sonido, mediante un script? No se puede. Bueno, no se puede a menos que usemos el objeto Shell. O Windows Desktop Search 3.0, si ha descargado e instalado el software. En algún momento, se agregó al objeto Shell la capacidad de recuperar toda la información de propiedades extendidas de los archivos, pero los chicos del scripting no se percataron del hecho. Consecuentemente, hemos estado diciendo a la gente: "No se puede usar un script para determinar la velocidad de bits de un archivo .wav", aunque, como demuestra el código de la Figura 2, sí que se puede.
Figure 2 Use un script para encontrar la velocidad de bits de un archivo .wav (Close Figure 2)
Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = objFolder.ParseName("J0388563.wav")

For i = 0 to 33
    strHeader = objFolder.GetDetailsOf(objFolder.Items, i)
    strValue = objFolder.GetDetailsOf(objFolderItem, i)
    If strValue <> "" Then
        Wscript.Echo strHeader & vbTab & strValue
    End If
Next
¿Cómo funciona este script? Bien, este también empieza como el primer script que mostramos: creamos una instancia del objeto Shell.Application y enlazamos a la carpeta C:\Scripts; después, usamos el método ParseName para enlazar al archivo en cuestión (en este caso, J0388563.wav).
Ahora, las cosas se complican un poco. Para empezar, configuramos un bucle For Next que se ejecute de 0 a 33, ya que los archivos admiten un máximo de 31 propiedades extendidas diferentes a las que se han asignado números de índice de 0 a 33. Fíjese que hay algunos números, como 27 y 28, que son números de índice válidos pero que no contienen ningún valor de propiedad. De hecho, los archivos admiten las propiedades mostradas en la Figura 3.
Figure 3 Propiedades de archivo (Close Figure 3)

Índice | Propiedad
0 | Nombre
1 | Tamaño
2 | Tipo de archivo
3 | Modificado
4 | Creado
5 | Último acceso
6 | Atributos
7 | Estado
8 | Propietario
9 | Autor
10 | Título
11 | Asunto
12 | Categoría
13 | Páginas
14 | Comentarios
15 | Copyright
16 | Intérprete
17 | Álbum
18 | Año
19 | Número de pista
20 | Género
21 | Duración
22 | Velocidad de bits
23 | Modo protegido
24 | Modelo cámara
25 | Fecha de captura
26 | Dimensiones
29 | Episodio
30 | Descripción del programa
32 | Tamaño de muestra de sonido
33 | Velocidad de muestra de sonido
Así que, ¿qué hacemos dentro del bucle For Next? Bien, lo primero es ejecutar esta línea de código:
strHeader = _
  objFolder.GetDetailsOf(objFolder.Items, i)
Aquí, usamos el método GetDetailsOf para recuperar el nombre de la propiedad 0 (recuerde, nuestro bucle se ejecuta de 0 a 33). Entonces almacenamos este nombre en una variable denominada strHeader; usamos esta línea de código para recuperar el valor de propiedad del elemento 0 y almacenamos la información devuelta en una variable denominada strValue:
strValue = _
  objFolder.GetDetailsOf(objFolderItem, i)
¿Ahora entiende cómo funciona? El elemento 0 resulta ser la propiedad Name. De modo que, la primera vez que pasa por el bucle, strHeader será igual a Name. Mientras tanto, el nombre real (es decir, el valor de la propiedad Name) del primer archivo es J0388563.wav. Por lo tanto, la primera vez que pasa por el bucle, strValue será igual a J0388563.wav. Si lo ponemos así, no parece tan complicado, ¿verdad?
Como probablemente sabe, no todos los tipos de archivo admiten todas las propiedades extendidas. Por ejemplo, un archivo .jpg no presentará título de álbum ni velocidad de muestra de sonido. Por lo tanto, en la siguiente línea de código, comprobamos si un valor devuelto es una cadena vacía:
If strValue <> "" Then
Si el valor es una cadena vacía, simplemente volvemos al principio del bucle y repetimos el proceso con la propiedad extendida siguiente. Si el valor no es una cadena vacía, devolvemos el valor y el nombre de la propiedad, así:
Wscript.Echo strHeader & vbTab & strValue
¿El resultado final? Algo muy semejante a esto:
Name    j0388563.wav
Size    169 KB
Type    Wave Sound
Date Modified   1/19/2004 8:56 AM
Date Created    3/6/2006 2:02 PM
Date Accessed   12/3/2007 10:41 AM
Attributes      A
Status  Online
Owner   FABRIKAM\kenmyer
Bit Rate        90kbps
Audio Sample Size       4 bit
Audio Sample Rate       11 kHz
Interesante.
No nos queda mucho tiempo (ni espacio) pero, si busca una manera todavía más fácil de devolver los valores de propiedad más pertinentes, pruebe el script de la Figura 4.
Figure 4 Una manera fácil de devolver valores de propiedad (Close Figure 4)
Const colInfoTip = -1

Set objShell = CreateObject("Shell.Application")

Set objFolder = objShell.NameSpace("C:\Scripts")
Set objFolderItem = _
  objFolder.ParseName("01. Out On The Weekend (Album Version).wma)")

Wscript.Echo objFolder.GetDetailsOf(objFolderItem, colInfoTip)
¿Qué hace este script? Si se encuentra en el Explorador de Windows y mantiene el cursor del mouse sobre un archivo, aparecerá información sobre herramientas que ofrece datos útiles acerca del archivo, como muestra la Figura 5. ¿Cómo se puede obtener esta información sobre herramientas mediante un script? Exacto. Use el script que acabamos de mostrarle:
Figura 5 Propiedades mostradas mediante información sobre herramientas
Figura 5 Propiedades mostradas mediante información sobre herramientas
Artist: Neil Young
Album Title: Harvest
Year: 1972
Track Number: 1
Duration: 0:04:35
Type: Windows Media Audio file
Bit Rate: 256kbps
Protected: Yes
Size: 5.31 MB
Y ya no tenemos más tiempo por este mes. Bueno, tenemos tiempo para una última nota sobre los gorriones. Una razón por la que quizás desee prestar atención a los gorriones diminutos es esta: en algunas partes del mundo, se considera mala suerte que un gorrión entre en la casa. ¿Por qué? Significa que alguien que vive en la casa va a morir. En algunos casos, eso sólo es verdad si el gorrión aterriza sobre un piano. Pero eso no es una superstición, es sólo algo muy raro. Pero aquí viene la parte interesante: en otras partes del mundo, si un gorrión entra en la casa, significa que alguien que vive en la casa va a casarse. ¿Qué le parece la diferencia, eh?

Dr. Scripto's Scripting Perplexer
El desafío mensual que prueba no sólo sus habilidades de resolución de rompecabezas, sino también sus habilidades de creación de scripts.

Marzo de 2008: Script críptico
El rompecabezas de este mes es un criptograma, lo que significa que cada letra se ha reemplazado por una letra diferente. Hemos dejado todos los símbolos y los números intactos. Una letra siempre representará la misma letra reemplazada. Por ejemplo, todas las repeticiones de la letra a podrían quedar reemplazadas por la letra b; todas las repeticiones de la letra b podrían quedar reemplazadas por la letra z, etc. He aquí un ejemplo simple:
tdsjqu dfoufs
se convierte en esto:
script center
En este caso, la descodificación se consigue al reemplazar cada letra con la letra del alfabeto que la precede, de modo que t queda reemplazada por s, d queda reemplazada por c, etc.
Nuestro rompecabezas es un poco más difícil. Descodifique este script y obtendrá un script que abre Microsoft Excel®, agrega una hoja de cálculo nueva, asigna cuatro valores a la primera columna en la hoja de cálculo y ordena dicha columna en orden ascendente.
Diviértase.

El rompecabezas
kqyjs edfjkzyrlyg = 1
kqyjs edyq = 2
kqyjs edjqtstqmj = 2

jzs quwzekzd = ktzfszquwzks("zekzd.faadlkfslqy")
quwzekzd.iljludz = stcz

jzs quwmqtxuqqx = quwzekzd.mqtxuqqxj.frr
jzs quwmqtxjozzs = quwmqtxuqqx.mqtxjozzsj(1)

quwmqtxjozzs.kzddj(1, 1) = "kfs"
quwmqtxjozzs.kzddj(1, 2) = "rqg"
quwmqtxjozzs.kzddj(1, 3) = "ufs"
quwmqtxjozzs.kzddj(1, 4) = "faz"

jzs quwtfygz = quwzekzd.fkslizkzdd.zysltztqm
quwtfygz.jqts quwtfygz, edfjkzyrlyg, , , , , , edyq, , , edjqtstqmj

Dr. Scripto's Scripting Perplexer
Respuesta: Sript críptico, marzo de 2008
Aquí está la clave para descodificar el script:
Actual Letter	a	b	c	d	e	f	g	h	i	j	k
Coded Letter	f	u	k	r	z	b	g	o	l	w	x

Actual Letter	l	m	n	o	p	q	r	s	t	u	v	w	x	y	z
Coded Letter	d	n	y	q	a	h	t	j	s	c	i	m	e	v	p
Y aquí tiene el script descodificado:
Const xlAscending = 1
Const xlNo = 2
Const xlSortRows = 2

Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True

Set objWorkbook = objExcel.Workbooks.Add
Set objWorksheet = objWorkbook.Worksheets(1)

objWorksheet.Cells(1, 1) = "Cat"
objWorksheet.Cells(1, 2) = "Dog"
objWorksheet.Cells(1, 3) = "Bat"
objWorksheet.Cells(1, 4) = "Ape"

Set objRange = objExcel.ActiveCell.EntireRow
objRange.Sort objRange, xlAscending, , , , , , xlNo, , , xlSortRows

Los chicos del scripting de MicrosoftLos chicos del scripting trabajan para Microsoft, mejor dicho, están contratados por 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: Uso de SCW en Windows Server 2008
Vigilancia de seguridad
Uso de SCW en Windows Server 2008
Jesper M. Johansson
Este artículo se basa en una versión preliminar de Windows Server 2008. Por tanto, toda la información de este documento está sujeta a cambios.

En el año 2005, Microsoft lanzó al mercado Windows Server 2003 SP1. Este Service Pack introdujo la primera herramienta de administración de seguridad basada en funciones para Windows: el Asistente para configuración de seguridad (SCW). Principalmente, Microsoft diseñó SCW como herramienta para reducir la superficie de ataque. Su propósito era analizar lo que el usuario
hace con su equipo y, automáticamente, configurarlo para admitir las funciones necesarias, y deshabilitar las funciones y los servicios no utilizados.
Windows Server® 2008 conserva SCW, que se ha actualizado con funciones nuevas e integración con el nuevo Firewall de Windows®. Sin embargo, continúa siendo una herramienta de administración tan avanzada como siempre.
Windows Server 2008 incluye también la nueva herramienta Administrador de servidores basada en funciones y sus complementos, el Asistente para agregar funciones y el Asistente para agregar características. En Windows Server 2008, en lugar de agregar componentes individuales a través del antiguo panel de control Agregar o quitar componentes de Windows, ahora se usan las herramientas de administración de funciones para configurar el servidor. Byron Hynes cubre estas herramientas en el artículo "Configuración de funciones con el Administrador de servidores", incluido en esta edición de TechNet Magazine.
Los asistentes para agregar funciones y características configuran el servidor con los componentes correctos para admitir las funciones elegidas. Además, configuran el firewall integrado para garantizar que estas funciones se ejecutan correctamente. Dado esto, quizás esté preguntándose si hay necesidad de usar SCW. Cierto, hay muchos administradores que ya no necesitan SCW. Sin embargo, hay dos grupos de personas para quien SCW puede ser una herramienta de valor incalculable. El primero está formado por los paranoicos de la seguridad. Estas personas aprecian la capacidad de SCW para llevar la seguridad a un nivel avanzado.
Puede pensar en los asistentes para agregar funciones y características como herramientas que toman un servidor predeterminado y lo configuran para ofrecer compatibilidad segura con las funciones y las características que desea. SCW, por el contrario, es la herramienta que configura el servidor para admitir sólo las funciones y las características que desea. SCW tiene también un efecto pedagógico, ya que ayuda a entender más a fondo la configuración del servidor. Por lo tanto, le recomiendo que ejecute SCW una vez que se haya configurado el servidor con su complemento de funciones y características.
El segundo grupo de personas incluye a los usuarios que desean entender las relaciones entre los componentes. SCW viene con un conjunto de archivos XML que documentan las relaciones entre funciones y características, servicios y puertos de red. Si le interesa entender lo que necesitan los distintos componentes, SCW es una herramienta muy valiosa.
En esta columna, describiré el funcionamiento de SCW y cómo usarlo para proteger el servidor. Ofreceré una comparación entre SCW y las herramientas del Administrador de servidores. Sepa que esta columna está adaptada de mi libro, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008).

Información general sobre el Asistente para configuración de seguridad (SCW)
Como introducción, presentaré algunas estadísticas acerca de la superficie de ataque en Windows Server 2008. Antes de configurar un servidor con su selección personal de funciones y características, aún tiene una cantidad significativa de servicios. De forma predeterminada, Windows Server 2008 tiene 105 servicios; de ellos, 42 están configurados para iniciarse automáticamente, 55 son de inicio manual y el resto están deshabilitados. Compare esto con una instalación limpia de Windows Server 2003 R2 SP2, que tiene 86 servicios instalados de forma predeterminada: 34 están configurados para iniciarse automáticamente, 32 están configurados para solicitar el inicio y el resto están deshabilitados.
Incluso con la metáfora de funciones y la reducción en funciones predeterminadas compatibles, Windows Server 2008 tiene una superficie más amplia y requiere que tome precauciones adicionales al asegurar los servidores. SCW le ayudará a crear una configuración de seguridad personalizada para sus servidores particulares.
SCW aplica un enfoque de seguridad de servidores completamente diferente a la estrategia de las herramientas existentes. Funciona con una metáfora de funciones para configurar el sistema de modo que admita dichas funciones y poco más. SCW ayuda a configurar el firewall, igual que los asistentes para agregar funciones y características, pero, además, SCW deshabilita los servicios innecesarios y configura algunos parámetros de configuración de seguridad adicionales. Finalmente, los asistentes para agregar funciones y características sólo pueden instalar y configurar funciones integradas en Windows, mientras que SCW es extensible. Un desarrollador o un administrador pueden escribir un archivo de configuración personalizado de función o característica y usar SCW para configurar cualquier producto.
SCW está diseñado para el uso posterior a la instalación de todas las funciones y las características que el servidor debe tener. Si tiene aplicaciones de terceros en su servidor, también debería instalarlas antes de ejecutar SCW.
Para demostrar cómo funciona esto, he configurado un servidor con tres funciones (servidor de aplicaciones, servidor DNS y servidor web) y dos características (las características de Microsoft® .NET Framework 3.0 y el servicio WAS, Windows Process Activation Service). Este no es un conjunto especialmente lógico de funciones y características, pero sirve como buen ejemplo para esta discusión.
Para iniciar SCW, ejecútelo desde el menú Herramientas administrativas. Verá el cuadro de diálogo que muestra la Figura 1.
Figura 1 SCW empieza por preguntar lo que desea hacer.
Figura 1 SCW empieza por preguntar lo que desea hacer.
El primer paso es elegir si desea crear una directiva de seguridad nueva, editar o aplicar una directiva existente o revertir una directiva de forma que el sistema recupere la configuración original. Las opciones no necesitan mucha explicación.
Cuando elige crear una directiva de seguridad nueva, SCW crea una directiva nueva con el uso de algún equipo como plantilla para lo que la directiva debe admitir. Analiza el equipo, determina qué características y funciones admite y garantiza que estas funcionan, pero también se asegura de que muchas características innecesarias no estén habilitadas.
SCW funciona en un modelo prototipo. Usa archivos XML para especificar la apariencia de las funciones y las características según los archivos instalados, los servicios configurados, etc. Por esta razón necesita tener instalado en el equipo todo lo que desea que la directiva controle. Si tiene programas de terceros que instalan definiciones de SCW durante su configuración, se integrarán sin complicaciones. Sin embargo, si sus programas de terceros no instalan definiciones de SCW, necesitará configurarlos manualmente.
Como puede ver, es posible crear una directiva en un sistema y, después, aplicarla a muchos sistemas. Si se dispone a crear una red con muchos sistemas, primero debería definir las clases de host configuradas por separado. Seguidamente, puede crear una directiva que use una de estas clases como prototipo y aplicar fácilmente la directiva a todas las demás con modificaciones mínimas.
Al hacer clic en Siguiente (en el cuadro de diálogo que muestra la Figura 1), el asistente pregunta qué equipo desea usar como línea base, o prototipo, para esta directiva nueva. Por lo general, elegirá el equipo local, pero también tiene la opción de usar un equipo remoto como prototipo.
Después de especificar el sistema que se debe usar, pasamos a la fase de análisis. Aquí, SCW enumera qué funciones y características hay instaladas y las compara con las funciones y las características de la base de datos. La base de datos contiene información sobre los servicios utilizados por cada función y cada característica, los puertos de red que necesitan y otros datos de configuración importantes. Después de completar el análisis, puede hacer clic en Ver base de datos de configuración para averiguar lo que ha encontrado el Asistente para configuración de seguridad. Tenga en cuenta que esta es una vista de sólo lectura que presenta información completa acerca de la configuración del equipo. De hecho, si le interesa de verdad entender lo que hay en su equipo, puede emplear una cantidad considerable de tiempo en el análisis de esta información.

Configuración del servidor con SCW
Al hacer clic en Siguiente, se obtiene acceso a la primera de cuatro secciones en SCW: Configuración del servicio basada en funciones. Es posible que advierta que las funciones en SCW, como muestra la Figura 2, no son las mismas que en el Asistente para agregar funciones. La mayor parte de las funciones disponibles en el Asistente para agregar funciones también están presentes aquí pero, además, SCW ofrece algunas que no están incluidas en el Asistente para agregar funciones. Por ejemplo, la función Servidor de aplicaciones que seleccioné no está presente. Esto es así porque SCW usa una metáfora ligeramente diferente para funciones. Trataré esto más detalladamente en breve.
Figura 2 Uso de SCW para seleccionar las funciones que debe admitir su servidor
Figura 2 Uso de SCW para seleccionar las funciones que debe admitir su servidor
Con frecuencia, tendrá el conjunto correcto de funciones ya seleccionado en este cuadro de diálogo. Así que compruebe simplemente que el análisis encontró lo que cree que debería haber encontrado. Si hay algo que no cuadra, compruebe que la función está instalada, e instálela si es necesario antes de volver a ejecutar SCW. Si comete un error, no es el fin del mundo. La característica de reversión en SCW le devolverá al punto de inicio al deshacer cualquier cambio que haya hecho la directiva.
Las respuestas que ofrezca en esta sección son muy importantes, porque determinan lo que verá más tarde en la sección de red. Afortunadamente, la lógica de detección es bastante buena y, generalmente, está seleccionado el conjunto de funciones correcto.
Fíjese también que, de forma predeterminada, verá Funciones instaladas, que son las funciones que el servidor puede admitir con el disco en el estado actual. Las funciones seleccionadas son las que admite actualmente. También puede ver todas las funciones en la base de datos. Para hacerlo, seleccione Todas las funciones en la lista desplegable. Esto es útil principalmente cuando hay que crear una directiva con un servidor prototipo que todavía no tiene todas las funciones necesarias instaladas.
Tras la configuración de funciones, seleccionamos las características de cliente que desea admitir. El conjunto de características es semejante, aunque no idéntico, al conjunto del Asistente para agregar características, y hay menos características en el conjunto. Una vez más, las metáforas no son exactamente iguales, y SCW se puede ampliar, así que lo que veremos es distinto a lo incluido en el Asistente para agregar características.
Al hacer clic en Siguiente en la página Características de cliente de SCW, obtenemos acceso al cuadro de diálogo Seleccionar Opciones de administración y otras, como muestra la Figura 3. Una "opción" en SCW es algo que no coincide exactamente con una función ni con una característica. Puede ofrecer funcionalidad administrativa o puede ser un servicio único, como la Detección de servicios interactivos. Igualmente en este caso, la mayor parte de las opciones que necesita deberían estar seleccionadas. Vale la pena mencionar el menú desplegable. Este menú ofrece opciones pertinentes a las funciones y las características seleccionadas anteriormente, y será diferente en equipos distintos.
Figura 3 Selección de otros servicios y características en SCW
Figura 3 Selección de otros servicios y características en SCW
Para continuar, tenemos el cuadro de diálogo Servicios adicionales. Aunque SCW incluye una base de datos de servicios muy amplia, aquí no se describe todo. Los servicios que SCW encuentra en un equipo que no están presentes en la base de datos se muestran en la página Servicios adicionales. Todos los servicios integrados deberían estar aquí, y no debería ver este cuadro de diálogo a menos que tenga instalado algún servicio de terceros.
El asistente permite seleccionar lo que se desea hacer con los servicios que no se van a configurar. Esta opción está diseñada para el uso cuando se desea aplicar la directiva creada a un equipo diferente. Si este equipo tiene servicios diferentes que aquel en el que se creó la directiva, SCW necesita saber qué hacer con ellos. Una opción es dejarlos como están, que es la opción predeterminada. La otra opción es deshabilitarlos, que es más segura pero puede causar problemas de funcionamiento. Pero, si sigue el consejo de únicamente aplicar las directivas a los servidores que son idénticos al equipo de creación, la opción que elija en esta página es irrelevante.
Así, acabamos la parte de configuración de funciones de SCW, y el asistente resume lo que hemos hecho. Como vemos en la Figura 4, con tan sólo elegir la configuración predeterminada, modificaremos apreciablemente la superficie de ataque del equipo. Por ejemplo, como este equipo no es un servidor de impresión y no tiene impresoras instaladas, no hay por qué ejecutar el servicio Administrador de trabajos de impresión. SCW deshabilita todos los servicios que no son necesarios. En nuestro servidor de prueba, SCW deshabilita 17 servicios que estaban configurados para el inicio automático y 42 servicios de inicio manual. Por supuesto, sus resultados variarán según la configuración del servidor, pero puede ver que SCW permite adaptar fácilmente una directiva concreta a sus servidores particulares, con lo que se reduce en gran medida la superficie de ataque.
Figura 4 SCW resume los cambios realizados.
Figura 4 SCW resume los cambios realizados.
Ahora pasamos a la sección posiblemente más importante de SCW: funciones de red. Después de la página de bienvenida inicial, vemos el cuadro de diálogo Reglas de seguridad de red, como muestra la Figura 5. Este cuadro contiene una lista de todas las reglas de firewall propuestas por SCW, que se basan en la compatibilidad con funciones seleccionada en las secciones anteriores.
Figura 5 SCW determina y enumera las reglas que necesita.
Figura 5 SCW determina y enumera las reglas que necesita.
Si no se modifica la configuración en la sección de red, SCW creará reglas de firewall que bloquean las interfaces de red de forma que sólo se admitan estas funciones y características pero que todos los clientes puedan obtener acceso a ellas. Pero, para optimizar realmente la seguridad en los servidores, debería usar SCW como elemento esencial a la hora de crear una estrategia de aislamiento de servidores. Para aprender más sobre el aislamiento de servidores (y el aislamiento de dominios), vea technet.microsoft.com/network/bb545651.
El kit de recursos de seguridad de Windows Server 2008 incluye un capítulo sobre la protección de la red con el aislamiento de servidores y dominios. También trata el uso del modelado de amenazas de red para analizar la red y facilitar la implementación del aislamiento de servidores. SCW es una herramienta valiosa en este proceso.
Puede configurar restricciones en las reglas propuestas al seleccionar la regla y hacer clic en Editar. Esto nos lleva al cuadro de diálogo de la Figura 6. Esta es una de cuatro páginas que permiten aplicar restricciones adicionales a las reglas para redes. Por ejemplo, puede requerir la autenticación IPsec. En este caso, también podemos enlazar el puerto con extremos determinados. De este modo, podemos configurarlo para permitir la administración remota sólo desde ciertos sistemas host. Como puede ver, esta es una ventaja clave que no ofrecen los asistentes para agregar funciones y características.
Figura 6 SCW permite crear reglas de IPsec y firewall.
Figura 6 SCW permite crear reglas de IPsec y firewall.
Esta capacidad de crear reglas de seguridad de conexión basadas en las funciones seleccionadas tiene dos propósitos importantes. Primero, ofrece una oportunidad de aprendizaje dorada para entender lo que hacen los servidores. Ni tan siquiera es necesario diseñar un servidor. Basta con ejecutar el asistente, realizar las selecciones y ver su efecto en las opciones de páginas posteriores. En segundo lugar, permite asociar el abstracto concepto de "puerto" al concepto mucho más lógico de "servicio", y configurar restricciones de red según lo que el sistema esté haciendo realmente.
Si se hace correctamente, esto permite desarrollar una configuración muy precisa para los servidores. La sección de redes de SCW es indudablemente el lugar donde debería emplear la mayor parte de su tiempo al crear la directiva de seguridad para los servidores.
El resto de SCW permite configurar parámetros de auditoría y algunos parámetros del Registro. La configuración predeterminada de estos parámetros es adecuada para la mayoría de las organizaciones y, a menos que tenga requisitos especiales, no necesitará hacer mucho aquí.
Después de crear la directiva, puede guardarla y aplicarla al equipo en que trabaja. O puede aplicarla a los otros equipos. También puede transformar la directiva en Objeto de directiva de grupo (GPO) mediante el comando scwcmd.exe /transform.
Sin embargo, si tiene parámetros específicos del equipo en la directiva, es posible que esto no se realice correctamente o que produzca resultados muy extraños. Por ejemplo, si crea restricciones de extremo que incluyen adaptadores locales en la sección de redes, se considera que la directiva es específica del equipo y no se transformará correctamente. Esto se debe al hecho de que los adaptadores deben quedar especificados mediante GUIDs. El GUID de un adaptador en un equipo no tiene sentido en otro equipo.
Por lo tanto, es mejor usar SCW con cada servidor independiente y como herramienta de aprendizaje. Para granjas de servidores grandes, puede usar SCW con el fin de obtener más información sobre los equipos y desarrollar una directiva básica. Entonces, puede tomar esta directiva y volver a crearla para la aplicación con cualquier herramienta que use para configurar los servidores, por ejemplo, la directiva de grupo o un sistema de administración empresarial (como Microsoft Systems Center).

SCW frente al Administrador de servidores
Una cosa que hemos visto hasta ahora es que la metáfora utilizada para funciones y características es diferente. Una "característica" en SCW es algo que el equipo hace para actuar como cliente. Un "función" es algo que hace para actuar como servidor.
Esto difiere de la metáfora usada en las herramientas del Administrador de servidores, donde una función es una colección de servicios y características que se pueden tomar como unidad, y una característica es algo que ofrece compatibilidad con funciones. En esencia, el Administrador de servidores considera que una función es aquello para lo que compró el servidor. Las características son importantes, pero no son la razón de compra del servidor. Las dos metáforas y los dos usos diferentes de los mismos términos confunden a los usuarios. Considere este aspecto con cuidado antes de cambiar de una herramienta a otra.
Además, las herramientas del Administrador de servidores no son extensibles. Están diseñadas para administrar sólo los componentes que vienen con Windows. En contraste, los programas de terceros instalados pueden agregar funciones y características a SCW. Incluso puede escribir sus propias funciones y características. Las notas del producto "Extending the Security Configuration Wizard" (en go.microsoft.com/fwlink/?LinkId=107397) explican cómo hacerlo.
SCW deshabilita también los componentes que no necesita. Por el contrario, las herramientas del Administrador de servidores se limitan a implementar los componentes que solicita; no tocan nada más en el equipo. Si necesita ayuda para determinar qué componentes no necesita, SCW es la herramienta que debe usar.
Además, tanto las herramientas del Administrador de servidores como SCW configurarán la red, pero SCW es mucho más eficaz en este sentido. Si se dispone a crear una estrategia de aislamiento de servidores, SCW puede ser una mina de información y su mejor amigo a la hora de llevar a cabo la implementación. Esto es obviamente un tema de administración de seguridad avanzada, pero SCW es una herramienta de seguridad avanzada.
Finalmente, SCW configurará también algunos parámetros de seguridad adicionales, algo que no harán las herramientas del Administrador de servidores. Sin embargo, estos quedan superados en gran parte por controles más eficaces, o ya establecidos de forma predeterminada, en Windows Server 2008.

Jesper M. Johansson es ingeniero de seguridad dedicado a problemas de seguridad de software y es editor colaborador de TechNet Magazine. Tiene un doctorado en MIS y más de 20 años de experiencia en seguridad.


 Archivos del escritorio: No se puede ser demasiado rico ni demasiado delgado
Archivos del escritorio
No se puede ser demasiado rico ni demasiado delgado
Wes Miller

Si ha estado alguna vez en un campus de Microsoft, probablemente haya observado los sistemas de quiosco de uso compartido en las áreas de recepción de la mayoría de los edificios. Estos sistemas se construyeron con un front-end basado en web conectado a Windows Terminal Services de manera que los empleados que iban de edificio en edificio pudiesen estar al día del correo electrónico y disfrutar de otros tipos de
conectividad. En un principio, se instalaron en equipos más antiguos que se habían retirado de servicio y se habían reciclado. El hardware, que era demasiado lento, no tenía memoria suficiente y contaba con unidades de disco duro inadecuadas, era perfecto para aplicaciones de cliente ligero. Si tiene hardware que se haya quedado anticuado por cualquier razón, también puede sacar buen provecho del mismo como estación de trabajo en salas de conferencias, como equipos para aprendizaje, etc. Mejor que desecharlos en un vertedero, puede adoptar un enfoque más ecológico y sacar un buen provecho del mismo.
Si su organización está considerando una actualización a Windows Vista®, puede que se de cuenta de que parte de su hardware es más antiguo de lo que creía. Esto puede significar que no dispone de compatibilidad para el Módulo de plataforma segura (TPM) o Aero® pero, si todo lo que necesitan sus sistemas es una unidad de disco duro más grande o más RAM, no dude en actualizar el hardware. No obstante, algunos de sus sistemas, simplemente, no podrán ejecutar Windows Vista porque el hardware no contará con la potencia necesaria o carecerá de alguna funcionalidad clave. Se trata, por tanto, de un hardware perfecto para ejecutar como cliente ligero de Windows®. La Figura 1 indica los requisitos de hardware de Windows Vista de manera que conozca a qué categoría corresponde exactamente su hardware actual.
Figure 1 Requisitos de hardware de Windows Vista (Close Figure 1)

Hardware | Requisitos
CPU | 1 GHz o más recomendado. La velocidad de la CPU puede determinar la capacidad de uso de Windows Vista. Una CPU lenta y de núcleo único no servirá, pero puede dar lugar a un buen cliente ligero. Si considera un cambio a x64, una actualización de hardware de Windows Vista puede ser el mejor momento para cambiar a x64, durante la actualización general del hardware.
Memoria | 1 GB o más recomendado. Con frecuencia, se puede agregar memoria a un sistema, pero piense si es rentable instalar memoria en docenas, cientos o miles de sistemas.
GPU | 128 MB o más de memoria gráfica, compatible con DirectX® 9.0 con un controlador WDDM y compatibilidad con Pixel Shader 2.0. No se trata de un buen negocio, puesto que limita la compatibilidad con Aero.
HDD | 40 GB o más en disco duro. Se trata probablemente de un problema a considerar en sistemas móviles, más que en sistemas de escritorio.
Problemas de controlador | ¿Están disponibles los controladores de Windows Vista para todo el hardware de sus sistemas?
TPM | Si desea compatibilidad con BitLocker sin que sea necesaria una unidad flash USB, su equipo necesitará el hardware TPM 1.2.

Así pues, ¿qué es posible hacer con un cliente ligero?
Mediante el uso de hardware y sistemas operativos anticuados, es posible crear áreas comunes o quioscos de recepción para que los usuarios puedan estar al día del correo electrónico, al igual que lo hacen en las oficinas de Microsoft. Puede instalar sistemas que ejecuten Escritorio remoto o una versión administrada cuidadosamente de Internet Explorer®. Puede instalar sistemas de reproducción de presentaciones en salas de conferencia al ejecutar Microsoft PowerPoint® y Escritorio remoto y poco más. También puede usar combinaciones de hardware antiguo/cliente ligero para sistemas de punto de venta o quioscos de búsqueda de trabajo. Así pues, ¿qué cliente ligero debería usar?

Windows XP Embedded
He mencionado en columnas anteriores cómo Windows XP Embedded se desarrolló como versión flexible y por componentes de Windows XP. Tal como se detallaba en la columna de Don Jones del mes de abril de 2007 (consulte technetmagazine.com/issues/2007/04/XPe), hay varias herramientas que puede usar para crear imágenes de Windows XP Embedded; la principal es Target Designer (consulte la Figura 2). Target Designer le permite crear su propia imagen personalizada de Windows XP Embedded.
Figura 2 Imagen de Windows XP Embedded de Target Designer
Figura 2 Imagen de Windows XP Embedded de Target Designer
Tenga en cuenta que Target Designer incluye numerosas plantillas de diseño para ayudarle a empezar. Por supuesto, puede hacerlo sólo, pero el uso de una plantilla lo hará considerablemente más fácil. En la Figura 2, puede observar el quiosco/consola de juegos y las plantillas Terminal basadas en Windows, que son buenos lugares para empezar. Windows XP Embedded también le ofrece compatibilidad completa con dispositivos y administración de energía nativa, al igual que le ofrecería la imagen del sistema operativo completo (tan sólo tiene que integrar la compatibilidad en su imagen). Por supuesto, a medida que agregue más características, necesitará más hardware, por lo que es importante que elija con sabiduría. Hay bastante información acerca de Windows XP Embedded en el sitio web de Microsoft: microsoft.com/windows/embedded/eval/xpe/default.mspx.

Windows Embedded for Point of Service
Windows Embedded for Point of Service (WEPOS) proporciona una plantilla completamente estandarizada para sistemas de punto de servicio (POS) creados sobre Windows XP Embedded. WEPOS ofrece compatibilidad integrada para numerosos periféricos relacionados con POS y su uso se dirige principalmente a los sectores de venta al por menor y hostelería. A diferencia de Windows XP Embedded, ofrece un conjunto muy fijo de funcionalidades diseñadas sólo para esta función y no se puede personalizar hasta el grado permitido por Windows XP Embedded.
La plataforma WEPOS se ha diseñado para un sistema mínimo; tan sólo requiere un procesador Pentium II a 233 MHz o superior, 64 MB de RAM y 280 MB para la imagen de sistema operativo principal. Para obtener información detallada acerca de WEPOS y vínculos para solicitar una versión de prueba, consulte microsoft.com/windows/embedded/wepos.

Windows Fundamentals for Legacy PCs
A diferencia de Windows XP Embedded y WEPOS, que se han diseñado principalmente para que el fabricante de dispositivos los incluya en el mismo dispositivo, Windows Fundamentals for Legacy PCs (FLP) se otorga con licencia como componente de Software Assurance, diseñado para su uso principalmente en este escenario concreto. La Figura 3 muestra la pantalla de instalación de Windows FLP, que ofrece cuatro opciones de configuración para que los usuarios elijan: mínima, típica, completa y personalizada.
Figura 3 Instalación de Windows FLP
Figura 3 Instalación de Windows FLP
Windows FLP requiere 64 MB de RAM, 500 MB o más de espacio en el disco duro y una resolución de pantalla de 800x600 o superior. Los requisitos reales del sistema en cuanto a espacio de disco duro pueden variar según los componentes del SO que elija instalar.
Si lo que busca es un sistema operativo relativamente flexible y mínimo para usarlo en hardware heredado y ya dispone de Software Assurance, Windows FLP es, sin duda, una buena elección. Consulte microsoft.com/licensing/sa/benefits/fundamentals.mspx para obtener más información acerca de cómo Windows FLP le puede ofrecer una migración sencilla al hardware y al sistema operativo más actuales.

Windows XP simplificado
Además de estas versiones más reducidas, Windows XP es en sí perfecto para usarlo tal como es. Si no tiene mucha RAM, deshabilitar servicios como Temas de Windows y otros puede ahorrar bastante sobrecarga para que el sistema funcione adecuadamente. No obstante, asegúrese de que sabe exactamente lo que deshabilita y que no pone en peligro la seguridad (al deshabilitar el Firewall de Windows, por ejemplo).

Lo que no funcionará
Desafortunadamente, con frecuencia, los usuarios intentan usar otras opciones de Windows para sistemas ligeros. Estas son las selecciones más obvias y aspectos específicos acerca de por qué cada una de ellas no funcionará tal como quizás espere.
Windows XP Starter Edition se ha simplificado para su uso en sistemas limitados, pero se ha diseñado especialmente para la utilización en mercados de tecnología en desarrollo y está sólo disponible como copia con licencia de Windows de un OEM incluida en un equipo nuevo en dichos mercados. Por lo tanto, generalmente no se trata de una opción. Si siente curiosidad sobre el tema, consulte: microsoft.com/presspass/newsroom/winxp/WinXPStarterFS.mspx.
Asimismo, Windows PE no es tampoco una opción viable. Y lo más interesante es que durante el desarrollo de Windows PE, Microsoft pensó inicialmente en su uso como sistema operativo ligero. Sin embargo, al final, no se diseñó simplemente para su uso como sistema operativo ligero, sino como entorno mínimo de preinstalación y orientado a la implementación. Por ejemplo, Windows PE no tiene shell aparte del símbolo del sistema (y no es posible agregar fácilmente uno muy funcional), no dispone de conjunto definido de API, ni de administración de energía o compatibilidad con audio.
Una versión reducida de Windows XP tampoco es una buena solución. He oído la sugerencia de que una opción viable podría ser reducir Windows. No me refiero a desactivar simplemente los servicios o deshabilitarlos, sino a quitar realmente aplicaciones con el objeto de conseguir una instalación de Windows más ligera. Desaconsejo por completo esta opción. Si quita binarios de Windows con el objeto de reducirlo, corre el riesgo de hacerlo poco seguro o inestable. Si lo que necesita es una versión de Windows más reducida, use Windows XP Embedded. Existe una curva de aprendizaje y se tardará algún tiempo en perfeccionar la imagen, pero es muy eficaz y, lo mejor de todo, es compatible con Microsoft.
Semejante a una versión reducida de Windows XP, el uso de una versión anterior de Windows puede parecer una opción atractiva, pero la falta de compatibilidad, actualizaciones y seguridad debería desmotivarle. Simplemente haga uso de las soluciones compatibles que ofrece Microsoft para ayudarle a cubrir sus necesidades informáticas más ligeras y sacar el máximo provecho de ese hardware ya anticuado sin sacrificar características atractivas o la seguridad.

Wes Miller es director técnico senior de productos en CoreTrace (www.CoreTrace.com) en Austin, Texas. Anteriormente, trabajó en Winternals Software como director de programas en Microsoft. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.


 Notas de campo: Preparaci&#243;n para TI 2.0
Notas de campo
Preparación para TI 2.0
Romi Mahajan

En La vida de la razón, el gran filósofo y ensayista George Santayana escribió que "aquellos que no recuerdan el pasado están condenados a repetirlo", con lo que quiso indicar la gran importancia de aprender de errores pasados para construir activamente un futuro mejor. La aplicación de este pensamiento es clara en los mundos de la política, la cultura, la historia e incluso la ciencia. De hecho, la idea de "aprender de los errores" es tan común que se ha convertido en cliché. Pero, ¿cuántos de nosotros dedicados a la tecnología de la información pensamos verdaderamente en el pasado y aprendemos de lo vivido? Y, si no lo hacemos, ¿estamos preparados para el mundo de TI del futuro? ¿Y qué apariencia tiene este mundo futuro?
Recurramos al poder de la memoria para intentar adivinarlo. Durante los últimos 30 años, los cambios han sido profundos. TI ha evolucionado de grandes sistemas mainframe a informática basada en el uso de exploradores, de la concentración de dispositivos a la proliferación de dispositivos, de la inmadurez y la rareza a la superespecialización y la vulgaridad, de la sencillez relativa a la complejidad extraordinaria. Así, cabe esperar que el entorno de TI se vuelva más complejo, más especializado y más democratizado. TI necesitará también ofrecer compatibilidad con el número creciente de clases de dispositivos, así como con el número creciente de clases de plataformas. Todo esto requerirá procesos de planeación más detallados que nunca.
¿Hemos asimilado estas nociones? Ni siquiera nos acercamos.
Tomemos, por ejemplo, las conversaciones de un debate que dirigí recientemente sobre la aproximación al consumidor de las TI como parte de una conferencia de tecnología en noviembre 2007. La premisa del debate era sencilla: que la división radical entre las tecnologías empresariales y de consumo ha desaparecido, que las aplicaciones y los dispositivos de consumo impulsan el desarrollo de TI y que los departamentos de TI necesitan prepararse para la familia de fenómenos representados por los Facebooks, los iTunes y los BlackBerrys del mundo. ¿Una idea sencilla? ¿Obvia? ¿Sobresabida?
A juzgar por la reacción de la gente en la sala, en absoluto. De unas 100 personas, sólo cuatro mencionaron su uso de Facebook. "Eso es para jóvenes", dijo un participante. "¿No son los empleados de su departamento de TI jóvenes que utilizan Facebook?", preguntó uno de nuestros panelistas. La confusión se apoderó de la sala. Únicamente unos cuantos directores de TI en el debate creían necesario renovar sus organizaciones con el empleo de personas que entienden cómo crear y mantener aplicaciones y dispositivos en las plataformas nuevas que ocupan la mayor parte del tiempo que los usuarios dedican a la tecnología.
Al tratar la pregunta sobre cómo crear directivas eficaces de TI para controlar el uso y la seguridad de tecnologías de cruce como teléfonos móviles y equipos portátiles, que son dispositivos de doble uso, en casa y en el trabajo, la multitud ofreció una respuesta ruidosa pero poco sustancial. Una opinión común quedó encapsulada por una persona que, del modo draconiano típico de TI 1.0, dijo: "Si alguien de mi oficina conectara un reproductor MP3 a un portátil del trabajo o se dejara accidentalmente un móvil de la empresa en el bar, lo despediría".
Mmmm. Adelante.
Esta pobreza de pensamiento se puede detectar también en la sequedad de las conferencias dirigidas a directores de TI. Si veo otra conferencia dedicada a las vagas nociones de "la alineación empresarial de TI" o "los indicadores de gestión comunes", creo que dejaré de viajar. ¿Por qué no nos estamos preguntando cómo será TI 2.0 y cómo podemos prepararnos para su uso? ¿Por qué no nos estamos preguntando qué habilidades y actitudes necesitará la nueva generación de profesionales de TI para crear un futuro dinámico? ¿Por qué no nos lamentamos del hecho de que no hay ni una sola compañía que ve su departamento de TI del modo que las compañías innovadoras ven sus departamentos de investigación y desarrollo? En lugar de tratar la centralización frente a la descentralización, ¿por qué no hacemos frente a la verdadera cuestión, el totalitarismo de TI frente a la democratización de TI?
Tenemos que amarnos un poco más y demostrar que nos importa el futuro. Todos hemos oído hablar de la llegada de Web 2.0. Es hora de empezar a pensar en TI 2.0 si queremos realizar algo que remotamente se acerque al potencial de la tecnología.

Romi Mahajan es Director de marketing en el equipo de marketing de plataformas y audiencia técnica de Microsoft. Romi tiene varias publicaciones en diversos campos, incluidos política, medio ambiente, tecnología y sociología.


 Confidencial de Windows: As&#237; se convirtieron en RC las versiones beta
Confidencial de Windows
Así se convirtieron en RC las versiones beta
Raymond Chen

En los tiempos de Windows®, las versiones preliminares del producto seguían una progresión bastante estándar. Primero teníamos las versiones alfa, que se usaban de forma interna y, posiblemente, se compartían con partners de desarrollo de software ajenos al equipo del producto de Windows.
Después de las versiones alfa, naturalmente, vienen las versiones beta, que se envían a una audiencia algo más amplia. Una diferencia principal entre los usuarios de las versiones alfa y beta es que las versiones beta incluyen a personas que no son desarrolladores de software, como usuarios finales a los que les gusta probar software aún no comercializado y empresas que desean avanzar con la evaluación del nuevo sistema operativo para determinar la compatibilidad del producto nuevo no sólo con sus aplicaciones internas críticas, sino también con la red corporativa, las configuraciones estándar de hardware y las herramientas de administración del sistema.
Finalmente, tenemos las versiones "release candidates", o RC. Estas son las versiones del código candidatas para el lanzamiento final. Es decir, si todo va bien, estas son las versiones que acaban en el mercado. Si se encuentra algún error horrible que anula esta esperanza, tan pronto como se corrige el error, se crea otra versión RC y se vuelve a iniciar el ciclo de pruebas. Windows 95 se lanzó al mercado en su sexta versión RC.
Me han dicho que el equipo de Windows NT® siguió el mismo método de nomenclatura, pero encontraron un problema: las empresas no se molestaron en probar sus aplicaciones críticas con las versiones beta de Windows NT. La lógica aplicada fue algo así: "¿Para qué molestarnos? Es sólo una versión beta. Las versiones beta son para aficionados. Todo será diferente en la versión final de todos modos. Las pruebas que realicemos ahora serán una pérdida de tiempo."
De forma similar, las empresas de software no prestaron atención a los problemas encontrados durante las pruebas de la versión beta de Windows NT. "No disponemos de compatibilidad para sistemas operativos beta", dijeron.
Estas compañías empezaron a realizar pruebas en serio cuando salieron las versiones RC e, inevitablemente, encontraron gran cantidad de problemas. Algunos eran problemas que las compañías podían resolver por su cuenta, pero había cuestiones más complejas, relacionadas con el hecho de que Windows NT no era "lo suficientemente compatible" con la versión anterior del sistema operativo. Había problemas secundarios de funcionamiento de características concretas; algunos de estos se podían corregir en plazos de tiempo breves. Pero algunos problemas eran tan críticos que había que posponer el lanzamiento del producto para que el equipo pudiera resolverlos.
Las versiones RC generaron también muchas sugerencias. Recibimos comentarios como: "Pensamos que la interfaz del usuario tendría un aspecto mejor si se organizasen los botones de este modo" o "Se podría escribir este mensaje de otra forma para que resulte menos confuso para los empleados". Estas habrían sido sugerencias maravillosas si hubieran llegado durante la fase beta pero, cuando se lanza la primera versión RC, ya es demasiado tarde para empezar a hacer cambios en el diseño de la interfaz. Para entonces, los archivos de ayuda y la documentación ya se han escrito, el producto se ha traducido a docenas de idiomas y se han diseñado y retocado las capturas de pantalla para el manual y la caja del producto que, seguramente, estarán en proceso de impresión o incluso habrán acabado de imprimirse. Todo este trabajo no se puede echar a perder para mover un botón.
Recuerdo una reunión durante la era de Windows XP en que se discutía uno de estos cambios de última hora. El cambio propuesto habría requerido que un archivo de ayuda de 20 KB se modificase para que las instrucciones coincidieran con la nueva interfaz de usuario. El representante de localización y traducción nos informó de que volver a traducir el archivo de ayuda modificado con restricciones de tiempo tan severas costaría cientos de miles de dólares.
Para contrarrestar la opinión de que las versiones beta no cuentan, el equipo de Windows NT recurrió a la inflación de categorías. Todavía hay versiones beta, pero las versiones beta más avanzadas, cuando hay todavía tiempo (pero no mucho) de hacer cambios de perfeccionamiento, han pasado a ser versiones RC y, lo que antes eran versiones RC, ahora son versiones de custodia. Este término transmite con precisión el estado real de la versión: "Está acabada, y no vamos a tocarla a menos que se trate de un caso de emergencia".

Raymond Chen The Old New Thing, y en su libro homónimo (Addison-Wesley, 2007) se trata la historia de Windows y la programación de Win32. Se cree que puede ver su casa desde aquí arriba.