 TechNet Magazine October 2007

TechNet Magazine October 2007

Informática verde: Cree un centro de datos verde

Las compañías de todo el mundo están empezando a pensar en maneras de ahorrar energía y reducir los costos, pero todavía existe poca información sobre cómo actuar al respecto. Empiece con nuestra introducción a la planeación, diseño e implementación de un centro de datos verde en su organización.

Dave Ohara Administración de Windows: Guía de réplica de Active Directory

Active Directory ofrece una gran flexibilidad para aceptar un entorno grande o descentralizado, pero puede resultar difícil mantener la integridad de sus datos. La réplica de Active Directory define cómo se comunican las actualizaciones a través de su entorno y cómo se resuelven los conflictos. Aquí encontrará todo lo que debe saber para hacer frente al desafío.

Laura E. Hunter System Center: Nuevas herramientas de administración de actualizaciones de software

Con System Center Configuration Manager 2007, encontrará un mecanismo completamente nuevo para tratar con la administración de actualizaciones que asegura un mejor cumplimiento para cada cliente. Aprenda cómo este enfoque mejorado puede ayudarle a tener actualizados todos sus equipos.

Steve Rachui Comunicaciones: Servidores Exchange de transporte perimetral en Microsoft

¿Cómo garantiza Microsoft la entrega de mensajes legítimos para los empleados mientras mantiene la afluencia masiva de contenido malintencionado alejada del entorno de mensajería? Una forma es implementar servidores Exchange Server 2007 de transporte perimetral y Forefront Security para Exchange Server. Descubra cómo estas tecnologías pueden garantizar la seguridad en su organización.

Kay Unkroth SQL Server: Optimización del rendimiento de la CPU de SQL Server

La clave para un buen uso de la CPU en su servidor de base de datos es comprobar que la CPU esté procesando lo que tiene que procesar, en lugar de malgastar ciclos en código mal optimizado o hardware lento. A continuación se enumeran algunas sugerencias para sacarle el máximo partido a SQL Server y a su hardware.

Zach Nichter Nota del editor: Lo mejor aún está por llegar

Joshua Hoffman Cuadro de herramientas: Nuevos productos para profesionales de TI

Greg Steen Preguntas y respuestas sobre SQL: Desencadenadores de entrada, desfragmentaciones del archivo de datos, etc.

Edited by Nancy Michell Utility Spotlight: Control remoto para máquina virtual Plus

Matthijs ten Seldam El negocio de TI: Cálculo del valor de la infraestructura de TI en la Administración

Acer Maamoun The Cable Guy: El protocolo de Internet autenticado

Joseph Davies Windows PowerShell: Trabajar sin un script

Don Jones ¡Hola, encargados del scripting!: Hágase de Silverlight

The Microsoft Scripting Guys Vigilancia de seguridad: BitLocker y la complejidad de la confianza

Justin Troutman Archivos del escritorio: Guía del usuario avanzado para WIM e ImageX

Wes Miller Notas de campo: Recicle su PC

Jim Lynch Confidencial de Windows: Llamada al Dr. Watson

Raymond Chen


 Inform&#225;tica verde: Cree un centro de datos verde
Informática verde Dave Ohara

Cree un centro de datos verde
Resumen:
  • Sistemas de supervisión de energía
  • Rasgos esenciales de un centro de datos verde
  • Efectos de H.R. 5646
  • Prácticas recomendadas para empezar

Lo verde está de moda hoy en día y el concepto tiene repercusión en la manera en que se diseñan los centros de datos. Las compañías de todo el mundo comienzan a pensar en los modos de ahorrar energía y reducir
costos con la compra de nuevo hardware y servicios. No obstante, existe poca información sobre qué acciones emprender para controlar los costos de energía. En el pasado, la electricidad se trató como un gasto general, similar al costo del espacio. Pero con costos de energía y problemas crecientes de fiabilidad, suministro y capacidad, la electricidad necesita una estrategia específica propia.
Los proyectos de optimización de rendimiento y reducción de costos son una parte de las recomendaciones diarias en casi todas las áreas de negocios. Por lo tanto, ¿por qué no tratar los costos de energía de la misma manera?
Como profesionales de TI, muchos de nosotros tomamos decisiones acerca de la configuración e instalación de servidores, las especificaciones de los equipos que compran nuestras organizaciones y en los requisitos para mejorar y crear centros de datos. Incluso ofrecemos información para el diseño inicial durante el desarrollo de aplicaciones. En lo que se refiere a estos proyectos, obviamente tenemos una excelente oportunidad de ser ecológicos e influir en la eficiencia de la energía de cualquier centro de datos.
La primera parte de cualquier estrategia consiste en conocer cuál es su uso actual de la energía. Necesita saber dónde se usa su energía y en qué equipos específicos, así como qué uso es eficiente y cuál se desperdicia en el centro de datos. Desgraciadamente, es poco habitual encontrar un medidor de consumo de energía que pueda desglosar el uso a un nivel en que se puedan ver los resultados de sus acciones. Normalmente, la mayoría de las organizaciones sólo ven una factura de energía mensual que acumula el consumo en el total de la última línea. Esto supone un estímulo muy pequeño para el ahorro de energía, porque las nunca se aprecia la repercusión de las decisiones que se toman, y no hay manera de que puedan demostrar que en realidad sus cambios ahorran energía.
Uno de los primeros problemas que se presentan cuando se considera la iniciativa de un centro de datos ecológico es si se cuenta con apoyo de la dirección. En este artículo, asumiré que la respuesta es "todavía no". El apoyo de la dirección requiere un compromiso serio que ofrezca recursos y presupuesto para su iniciativa. Y aunque se habla mucho de los centros de datos ecológicos, la realidad es que todavía existe una ausencia de apoyo serio por parte de la dirección. Si contara ya con un apoyo de la dirección así, probablemente ya tendría un centro de datos verde en funcionamiento.
De todos modos, aún si asumimos que no obtiene el apoyo que necesita, hay mucho que puede hacer para llevar adelante su iniciativa de un centro de datos verde. Entonces, ¿cómo determina las acciones que se deben ejecutar para lograr sus objetivos? Afortunadamente, la eficiencia de la energía no es un concepto nuevo y los profesionales de TI pueden aprender mucho de los otros sectores.

Resumen del consumo de energía
Uno de los desafíos más grandes a los que me enfrento cuando escribo sobre este tema es encontrar el sentido de la gran disparidad entre las cifras que ofrecen distintas fuentes. Algunos estudios dicen que los centros de datos representan entre un 1,2 y un 2 por ciento de la electricidad que se consume en los Estados Unidos. Según algunos cálculos, si se pensara que los centros de datos constituyen por sí mismos un sector, los centros de datos de EE. UU. se acercarían a los cinco primeros sectores en términos del uso de energía. Mientras tanto, la electricidad puede representar entre un 15 y un 20 por ciento como máximo del costo operativo en un centro de datos corporativo en EE. UU.
Un estudio de los laboratorios nacionales Lawrence Berkeley realizado para el Consejo de EE. UU. para la promoción de una economía basada en la eficiencia de la energía, determinó que los centros de datos pueden consumir hasta 40 veces más energía que los edificios de oficinas convencionales. El estudio detalla acerca de lo que se puede hacer para mejorar la eficiencia de la energía desde una perspectiva de las instalaciones (consulte eetd.lbl.gov/emills/PUBS/PDF/ACEEE-centro de datoss.pdf). Un buen punto de partida consiste en determinar hasta qué punto su centro de datos sigue las recomendaciones que se presentan en este estudio.
Sin duda, existen muchas perspectivas, estudios y números con respecto al consumo de energía. Sin embargo, un tema que permanece constante, es que existe mucho derroche. Sólo piense en cuántos servidores se compraron con la intención de llevarse más por el mismo precio; esto significa comprar tanta energía de CPU, memoria, almacenamiento y sistemas de alimentación redundantes como sea posible mientras no se supere el presupuesto. Muchos de dichos servidores funcionaron a un promedio del 10 al 15 por ciento de su capacidad en los últimos 3 a 5 años. Aunque a menudo la atención se centra en las CPU, otros componentes desempeñan aquí un papel importante: memoria, discos e interfaces de red, que conllevan necesidades de energía significativas y, cuando se combinan, superan el consumo de energía de la CPU.
Mientras tanto, el exceso de hardware, desde procesadores a sistemas de alimentación redundantes, puede conducir a un derroche considerable. Dada la cultura reacia al riesgo existente en la mayoría de los departamentos de TI, el exceso de capacidad es la norma. La decisión más segura es contar con exceso de hardware, aunque necesariamente no sea la mejor decisión financiera. Pero aunque la energía es un factor clave, normalmente se pasa por alto al calcular los costos del ciclo de vida. Desgraciadamente, no hay estímulos para comprar soluciones eficientes, porque no hay análisis de costo-beneficio de los responsables de las tomas de decisiones después de la implementación.
Sin embargo, hay un punto medio por alcanzar. El péndulo se mueve hacia el otro extremo cuando la dirección comienza a darse cuenta del poco uso que se hace de toda la capacidad de hardware que tiene el centro de datos, y consideran la consolidación de servidores una manera de reducir los costos. Es mucho más fácil analizar correctamente la las necesidades que deben satisface los servidores al principio que intentar consolidar después servidores que ya se implementaron.
Ahora que el sector de TI alcanza un nuevo nivel de madurez, la optimización con reducción de costos se convierte en una prioridad. El consumo de energía es un indicador que la dirección puede usar para medir la eficacia de decisiones tomadas respecto al ciclo de vida del hardware de TI. Tanto AMD, como Intel y los OEM de servidores y componentes hacen referencia al rendimiento por vatio de sus plataformas. Las cifras de rendimiento por vatio se pueden usar para calcular un costo operativo mediante la fórmula inversa: vatios por unidad de rendimiento. Con la cantidad de personas implicadas en el desarrollo de soluciones de TI (utilidades, desarrollo de aplicaciones, arquitectura, operaciones y unidades de negocios) el rendimiento por vatio responde a la pregunta "¿qué obtengo a cambio?" y le permite compartir las distintas soluciones en términos de eficiencia de energía.
¿Por qué es una práctica común ignorar los costos de energía y pasar por alto las decisiones que afectan a los costos operativos y de instalaciones? ¿Cuántos centros de datos ha visto que funcionen al límite de su capacidad debido a restricciones de energía y refrigeración? Había un tiempo en que tener suficiente espacio físico para el centro de datos era el problema. Sin embargo, actualmente el problema es tener suficiente capacidad para alimentar y refrigerar todos los equipos, y saber cuánto tiempo pasará hasta agotar la capacidad.

La importancia de los sistemas de supervisión de energía
El consumo adecuado de energía puede ser difícil de medir. Como mencioné anteriormente, la mayoría de las compañías acumulan los costos de energía como un todo en lugar de desglosar el consumo de energía en unidades específicas. Este método de tratar a energía como un gasto general crea la percepción de que los costos de energía están más allá del control de la unidad de negocio. Sin embargo, esto no es verdad.
Un centro de datos puede usar decenas de veces más de energía por metro cuadrado que un espacio de oficinas estándar y, por lo tanto, aún las mínimas mejoras de eficiencia en los centros de datos pueden representar ahorros sustanciales. No es sorprendente que los ahorros de costos sean el motivo principal por el que los centros de datos implementan programas de ahorros de energía. El problema es que se establece el método del costo más bajo para cargar el consumo de energía y se acumulan los costos mensuales de instalaciones para operaciones de centro de datos. A continuación, los costos se asignan en grupos basados en el espacio ocupado o en la conexión de puertos; este método ofrece un desglose muy inexacto de los costos reales de funcionamiento de cualquier equipo del centro de datos.
Es poco frecuente que una organización tenga una solución que mida el uso real de energía en función de los distintos dispositivos del centro de datos, y esto se debe en gran parte al hecho de que instalar un medidor de energía y un sistema de informes requiere una inversión inicial considerable. Sin embargo, al invertir en este tipo de sistemas se puede obtener como resultado un ahorro de costos aún mayor.
Por supuesto, un sistema de supervisión de energía en sí mismo no es suficiente; necesitará un plan para determinar cómo usará los datos recopilados para administrar mejor el consumo de energía y, al final, ver un retorno de su inversión. Analicemos la compañía canadiense Abitibi Consolidated, el productor más grande del mundo de productos para periódicos y papel. En 2001, cuando el mercado de energía eléctrica de Ontario se desreguló, Abitibi Consolidated quedó expuesto a precios de mercado y disponibilidad fluctuantes. Para optimizar sus compras de energía, la compañía implementó un sistema de supervisión y medición. En pocos meses, el nuevo sistema ya recuperó la inversión, gracias al ahorro del uno por ciento que la compañía obtuvo por el mero hecho de comprar su energía de forma más eficiente.
¿Cuánta energía necesita ahorrar para justificar una actualización del sistema de supervisión de energía en su centro de datos? Bill Laing, director general de desarrollo de Windows Server® 2008 en Microsoft, dijo en una entrevista reciente que la nueva versión de Windows Server con ahorro de energía predeterminado habilitado, podría reducir el consumo en hasta un 20 por ciento: un ahorro importante. La figura 1 muestra algunas de las opciones de energía disponibles en Windows Server 2008 beta 3. No obstante, tenga en cuenta que el ahorro no se puede calcular como una reducción directa en el costo de la energía consumida. Hay varios factores diferentes implicados, como el costo de construcción de un nuevo centro de datos y la el número de sistemas que actualmente admiten configuraciones menos eficientes.
Figura 1 Opciones de energía en Windows Server 2008 beta 3
Figura 1 Opciones de energía en Windows Server 2008 beta 3
En este momento, en Windows Server 2003 SP1 podría seleccionar la opción de energía y desempeño del procesador equilibrados en el servidor. Pero sin un sistema de medición, no podrá cuantificar el ahorro, ni ningún otro factor implicado en realizar y permitir este cambio.
También cabe destacar que para muchos centros de datos, el consumo de energía normalmente fluctúa sólo un cuatro por ciento durante cualquier período de 24 horas, lo que indica que dicho consumo de energía no depende de la carga. Con las recientes innovaciones de los fabricantes de hardware, este resultado cambia para los nuevos equipos y la cantidad de energía consumida disminuye con cargas más pequeñas.

Definición de un centro de datos verde
Podría continuar varias páginas enumerando los criterios o rasgos que caracterizan a un centro de datos verde. Por supuesto, no tengo espacio para abarcarlo todo en este artículo, pero deseo resaltar algunas características clave que debe tener presente si toma en serio la implementación de un centro de datos verde. Incluso si en este momento sólo se encuentra en la fase de planeación, con esta lista puede realizar comparaciones para determinar dónde se encuentra actualmente su centro de datos:
  1. Las medidas se usan para desglosar el uso de energía por componentes (como un servidor de 2U, un servidor de 4U, un conmutador, una SAN y un SAI) y a qué unidades de negocio se carga la energía que usan esos componentes.
  2. El uso de energía se supervisa de manera continua para determinar las demandas de energía máxima y mínima.
  3. Las capacidades de energía se supervisan en el ámbito de todo el centro de datos y se llega hasta los circuitos para garantizar que todos se encuentran dentro de límites aceptables.
  4. El plan de ahorro de energía se documenta y recompensa.
  5. El plan de ahorro de energía se revisa regularmente y se toman acciones correctivas para controlar los errores.
  6. Se determina cómo se cargan los costos en las unidades de negocios para modificar comportamientos, y se promueve el ahorro de energía entre unidades de negocios independientes. Este aspecto se debe promover desde la dirección.
  7. El límite de CPU se habilita en los servidores, y el laboratorio de rendimiento mide el rango de energía consumida con diferentes cargas.
  8. La elaboración del perfil térmico se usa para identificar los lugares calientes y con exceso de enfriamiento.
  9. La ingeniería del rendimiento de TI incluye medidas de eficiencia de energía.
  10. La realimentación de datos en vivo está disponible para organizaciones individuales, y les permite reaccionar de manera adecuada. California ISO llega a ofrecer datos en tiempo real al público en su sitio web, como se muestra en la figura 2.
Figura 2 El sitio web de California ISO ofrece una instantánea en directo que incluye la demanda actual y el nivel de conservación actual solicitado de sus clientes
Figura 2 El sitio web de California ISO ofrece una instantánea en directo que incluye la demanda actual y el nivel de conservación actual solicitado de sus clientes
Cuantas más características de este tipo implemente, más cerca está de tener en funcionamiento un sistema avanzado de supervisión de energía. He incluido una tarjeta de resultados (consulte la figura 3) con ocho preguntas que se puede formular para determinar el nivel actual de su centro de datos: básico, intermedio o avanzado.
Figure 3 ¿Cómo de verde es su centro de datos? (Close Figure 3)

Nivel | Acciones...
Básico | ¿Revisa su factura mensual de electricidad?
¿Comprueba sus equipos eléctricos con regularidad para realizar planeación de capacidad?
Intermedio | ¿Ha automatizado la medición e informes de carga y consumo de los circuitos eléctricos?
¿Revisa la eficiencia de energía del equipo cuando realiza la compra?
Avanzado | ¿Supervisa el consumo de energía por bastidor, dispositivo y circuito?
¿Analiza la supervisión de datos e informes históricos?
¿Usa informes en tiempo real del consumo de energía por departamentos para entender los impactos de los cambios e implementaciones?
¿Usa datos para negociar tasas de energía favorables con la compañía suministro?

Con el conocimiento ya hay medio camino realizado.
Otro problema al que se enfrentará es la estandardización en la organización. Realizar cambios como los descritos en este artículo, que cambien el paradigma por el cuál se mide la energía, y que impliquen la participación de las unidades de negocio en la organización, conlleva la alineación entre grupos de instalaciones a través de múltiples centros de datos que trabajen con un amplio conjunto de grupos de TI. Dichos problemas de organización son los primeros obstáculos para implementar un programa de ahorro de energía.
Es importante que se asegure de contar con una persona o equipo únicos responsables de analizar el consumo de energía a través de los centros de datos. Este centro de conocimientos (del que carecen la mayoría de las compañías cuando se trata de consumo de energía) es esencial. También es importante que sus herramientas recopilen datos de instalaciones dispares de manera uniforme y notifiquen los resultados a cada unidad de negocio de una manera coherente (la figura 4 muestra un panel de ejemplo para informar los datos).
Figura 4 Panel de supervisión de datos globales de ejemplo (cortesía de OSIsoft)
Figura 4 Panel de supervisión de datos globales de ejemplo (cortesía de OSIsoft)
Sin los instrumentos correctos, no sabrá si en realidad su sistema funciona de manera eficiente, ni las unidades de negocio individuales sabrán si sus esfuerzos producen resultados. Si desea realmente cambiar el comportamiento humano, necesita ofrecer a los usuarios la información en tiempo real con tendencias de datos históricos para que puedan visualizar los resultados de sus acciones. No puede recompensar de forma eficaz a los grupos por logros en eficiencia de energía si cada unidad de negocio se encuentra en un sistema diferente, usa un conjunto de herramientas diferente, y toma medidas diferentes para informar de su éxito.

Fuerzas del sector
No se sienta sólo en sus esfuerzos de hacer más ecológica su compañía. Los líderes en otros mercados, desde compañías como Boeing y Toyota hasta organismos públicos como el Estado de California, realizan importantes inversiones para que sus operaciones y productos tengan más eficiencia de energía.
En cuanto al mundo de TI, en 2006 la Cámara de Representantes de EE .UU. aprobó un proyecto de ley, H.R. 5646, ahora ley pública 109-431, realizando un llamado a la Agencia de Protección Ambiental (EPA) para investigar los costos de energía y el consumo de electricidad de servidores y centro de datos y los efectos posibles de cambiar a sistemas de energía más eficientes. El estudio, llevado a cabo por ENERGY STAR, un programa de EPA, realizó proyecciones de crecimiento a corto plazo en el uso de energía de servidores y centros de datos de EE. UU, valoró costos potenciales y ahorro de energía relacionados con mejoras de eficiencia de energía de centros de datos y servidores, y valoró estímulos posibles y programas voluntarios para promover servidores y centros de datos con energía eficiente. Los resultados finales del estudio se presentaron al Congreso en agosto de 2007. Puede encontrar más información acerca de este estudio en energystar.gov.
También se encuentran en desarrollo nuevos estándares de edificios para edificios ecológicos Estos estándares incorporan criterios como la capacidad de submedición de por hora de circuitos en función del propósito y consumo de energía, la creación de medidores que comuniquen datos de consumo de energía a un sistema de administración de datos de medición, y sistemas de administración de datos de medición que almacenen datos y creen informes de usuario que muestren el consumo de energía calculado por hora, diario, mensual y anual de cada medidor. Los sistemas de cumplimiento requieren muchos de estos criterios cuando se suscribe a programas de ahorro de energía donde se necesita demostrar que los cambios funcionan (por ejemplo los créditos de energía renovables, los créditos del carbón y los programas de reducción de energía).
Algunos usuarios han solicitado pruebas de especificaciones, pero es difícil representar el espectro de usos. Se han hecho intentos para estandardizar las pruebas, pero como con la mayoría de las pruebas de rendimiento, se pueden usar para optimizar los resultados "percibidos", que no representan el uso real. Considere, por ejemplo, los kilómetros por litro. Las calificaciones de EPA calculan los kilómetros por litro que un conductor típico debe obtener en condiciones de ciudad y autopista normales Sin embargo, la mayoría de los conductores conducen en entornos que no son normales y los factores que afectan a la eficiencia de combustible pueden variar apreciablemente. Esta misma orientación se aplica al ahorro de energía en el centro de datos. Los únicos resultados exactos para su organización vendrán de la medición del ahorro de energía en su propio entorno.

¿Dónde está el ahorro?
Se deben considerar muchos factores para determinar el ahorro. ¿Conoce el costo de agregar más energía en un área determinada? ¿Tiene una estrategia para minimizar las restricciones de energía? ¿Puede resolver el problema ubicando sus centros de datos en lugares donde la energía sea más económica? ¿O debe centrarse en operaciones que mejoren sus instalaciones existentes?
En algunas compañías, la mejor manera de reducir costos puede ser reubicar los centros de datos en áreas con fuentes de electricidad más económicas. La virtualización de servidores ofrece otro enfoque para reducir el consumo de energía. De hecho, algunas compañías de energía, (PG&E, SoCal Edison, y SDG&E, para nombrar algunas) ofrecen incentivos financieros a clientes que emprendan proyectos de virtualización de servidores que tengan como resultado una reducción de equipos de servidores.
Pero hay pasos menos drásticos y más sencillos que se pueden dar. La mayoría de los departamentos de TI no tienen la menor idea de cuánta energía consumen sus sistemas en la actualidad, y esto significa una enorme oportunidad para un posible ahorro. Un primer paso podría ser examinar el consumo de energía asociado a dispositivos individuales y, a continuación, ver si existen cambios que se puedan realizar por dispositivo. Muchos cambios pequeños pueden sumar ahorros sustanciales.
Para comparar, piense en la casa típica donde el propietario no tiene la menor idea de cuánta energía emplea cada artículo de la casa: lo único que hace es pagar una factura mensual total. Puede obtener un dispositivo económico y sencillo, como Kill A Watt, que mide el consumo de energía de los distintos dispositivos. ¿Cuánto gasta en mantener encendido su horno a microondas cuando no lo usa? ¿Cuánta energía se consume cuando deja el cargador de su teléfono conectado? Con este mismo enfoque, puede agregar medidores a los bastidores y recopilar datos de distintos dispositivos. Las herramientas de administración se pueden usar para recopilar datos directamente desde algunos servidores con capturas de SNMP de consumo de energía.

Introducción
La figura 5 ofrece un resumen de recomendaciones que debe seguir para poner en marcha su plan. En esta etapa, es importante entender que no está limitado a elegir entre los dos extremos. Puede optar por un enfoque más equilibrado, que probablemente es más práctico. Inicie un esfuerzo de base, e identifique a los empleados de la compañía que son apasionados del ahorro de energía. Comience a medir algunos dispositivos dentro de una unidad de negocios para ofrecer datos visibles. Tomar impulso y mostrar resultados cuantificables le ayudará a obtener el apoyo que necesita para ampliar la inversión de la compañía para convertirse en empresa verde.
Figure 5 Claves para la implementación de un plan de ahorro de energía (Close Figure 5)

Recopilar datos manualmente para determinar el estado de sus sistemas actuales. Determinar cuánta energía consumen los dispositivos y aplicaciones, y desglosar los costos.
Crear un sistema de realimentación de bucle cerrado para medir la eficacia de los cambios realizados.
Asegurarse de supervisar el consumo de electricidad en los lugares correctos y al nivel apropiado (por dispositivo, organización de TI, unidad de negocio, aplicación, etc.).
Crear un fondo para proyectos de ahorro de energía para ofrecer financiación del capital.
Descubrir las personas de su organización pueden hacerse cargo de la eficiencia de energía y hacer que se involucren.
¿Quiénes son las personas que conducirán la eficiencia de energía en su compañía? La alta dirección, la gerencia, o simplemente las personas que están interesadas en el impacto de su compañía en el entorno. En cada compañía hay personas que viven este tema con pasión. Una de sus primeras decisiones es probar el método de base e implicar a estas personas desde el comienzo.
Por último, para cualquier dirección que elija, la planeación de un programa de eficiencia de energía para su centro de datos requerirá obtener colaboración de los grupos de TI. Hasta hace poco, el enfoque típico de la planeación de soluciones de TI ha sido ignorar los costos de energía durante la fase inicial de diseño, centrándose en el hardware y el software que se compra, junto con el trabajo y costos para hospedar la solución. Cuando la energía está oculta en el costo general de las soluciones en funcionamiento en un centro de datos, la eficiencia de energía tiene baja prioridad. Sacar a la luz la energía real que consumen las soluciones es el primer paso crítico para cambiar el comportamiento de su organización.

Dave Ohara tiene 26 años de experiencia en el mundo de la tecnología, y ha trabajado para compañías como Microsoft, Apple y Hewlett-Packard. Con experiencia en desarrollo de productos, marketing, proselitismo tecnológico, arquitectura de infraestructuras, ingeniería de procesos, ingeniería de fiabilidad y logística de distribución, ahora Dave trabaja junto a varias compañías implementando iniciativas verdes.
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 Administraci&#243;n de Windows: Gu&#237;a de r&#233;plica de Active Directory
Administración de Windows Laura E. Hunter

Guía de réplica de Active Directory
Resumen:
  • Transición a Active Directory
  • Mantener la coherencia
  • Gestión de la resolución de conflictos
  • Cambios en Windows Server 2008

Antes de la introducción de Windows 2000 Server y Active Directory, muchos entornos corporativos dependían de Windows NT para su infraestructura de servidores y
administración de identidades y acceso. Cuando se implementó Windows NT® 4.0, era una oferta atractiva para el espacio de los sistemas operativos de red (NOS), pero tuvo varios inconvenientes que hacían difícil su implementación en una gran empresa.
Para empezar, Windows NT usaba un espacio de nombres plano para almacenar recursos de red, lo cuál significaba que no existía una buena manera de separar los recursos en subconjuntos más pequeños ni de configurar algún tipo de administración granular. No puede, por ejemplo, configurar un contenedor departamental para los recursos de su departamento de marketing, ni configurar un administrador local con derechos para restablecer únicamente las contraseñas de los usuarios de dicho departamento. De esta manera, la seguridad de Windows NT se basaba en todo o nada; si deseaba delegar las tareas administrativas en un ingeniero de soporte técnico de escritorio, a menudo se veía forzado a conceder muchos más permisos que otorgaría en otra situación.
Además, Windows NT almacenaba toda su información en una base de datos del administrador de cuentas de seguridad (SAM) que no estaba diseñada para crecer por encima de los 40 MB. Si su base de datos SAM crecía por encima del máximo recomendado (lo cual pasaba aproximadamente con entre 25.000 y 40.000 objetos, según la configuración), debía dividir su entorno en varios dominios independientes, lo cuál dificultaba tanto la administración de la red como la tarea de ofrecer a los usuarios el acceso a los recursos. Cada dominio NT contenía un único controlador de dominio principal (PDC), que incluía la única copia de lectura/escritura de la base de datos SAM; aunque fuera posible implementar uno o más controladores de dominio de reserva (BDC) para ofrecer tolerancia a errores, estos BDC eran de sólo lectura y no podían realizar actualizaciones, como por ejemplo cambiar una contraseña de usuario, para lo cual era necesaria una operación de escritura.
Por último, Windows NT dependía de la resolución de nombres NetBIOS, que se basaba en la difusión, y que generaba a menudo una gran cantidad de tráfico cuando los usuarios examinaban sus recursos de red, especialmente si necesitaban hacerlo a través de un vínculo WAN lento o con mucho tráfico.

Emerge un nuevo modelo
En el año 2000, Microsoft lanzó al mercado Windows® 2000, que incluía una revisión importante de sus ofertas de NOS anteriores. El nuevo servicio de NOS, Active Directory®, era tan diferente de Windows NT como cabía esperar. Active Directory no dependía de un espacio de nombres plano, sino que se creó a partir del estándar X.500, que creó una estructura de organizativa jerárquica; los recursos podían ahora organizarse en varas unidades organizativas dentro de un único dominio y la administración de cada unidad organizativa se podía delegar hasta el nivel de las tareas.
Otro cambio significativo respecto de Windows NT fue el nuevo modelo de réplica con varios maestros. Atrás quedaba el PDC que admitía escritura y los BDC asociados; en Active Directory, cada controlador de dominio tenía la capacidad de escribir en la base de datos de Active Directory.
Sin embargo, aunque contribuía a una mayor flexibilidad en términos de compatibilidad con un entorno grande o descentralizado, también generaba nuevos desafíos para mantener la integridad de Active Directory. Si John Smith y Jane Dow cambian el mismo objeto en oficinas que se encuentran en cada punta del país, ¿qué sucede si dichos cambios son incompatibles entre sí? El modelo de réplica de Active Directory define las formas en que se comunican las actualizaciones a todos los controladores de dominio dentro de un entorno, así como la manera de administrar cualquier conflicto que surja como resultado de la capacidad de varios maestros de realizar cambios prácticamente desde cualquier lugar.

Mecánica de la réplica de Active Directory
A los efectos de estos ejemplos, sólo explicaremos la réplica interna en los sitios. Básicamente, la réplica dentro de un sitio se diseña para replicar rápidamente los cambios a los DC del mismo sitio y se realiza mediante la notificación de cambios. En el caso de la réplica interna en sitios, DC1 notificará a DC2 que tiene cambios que deben replicarse, después de lo cuál DC2 extraerá dichos cambios de DC1. De forma similar, cuando DC2 tenga algún cambio lo notificará a DC1, después de lo cual DC1 extraerá dichos cambios de DC2. Como puede ver, toda la réplica de Active Directory sucede en las operaciones de extracción, no en las de inserción.
Dado que Active Directory puede escalar a cientos de miles o incluso a millones de objetos, es necesario dividir la base de datos de Active Directory en secciones, denominadas contextos de nomenclatura (NC). Como mínimo, cada controlador de dominio almacena tres NC en su copia local de la base de datos de Active Directory.
NC de esquema Este NC se replica al resto de los controladores de dominio del bosque. Contiene información acerca del esquema de Active Directory, que, a su vez, define las diferentes clases y atributos de objetos que hay dentro de Active Directory.
NC de configuración Este NC también se replica al resto de los DC del bosque, y contiene información de configuración para todo el bosque que pertenece al diseño físico de Active Directory, así como información acerca de especificadores de pantalla y cuotas de Active Directory para todo el bosque.
NC de dominio Este NC se replica al resto de los DC dentro un sólo dominio de Active Directory. Éste es el NC que contiene los datos de Active Directory a los que se tiene acceso con más frecuencia: los usuarios, grupos, equipos y otros objetos reales que residen dentro de un dominio de Active Directory determinado.
Para optimizar mejor el tráfico de réplica, cada contexto de nomenclatura se replica por separado para que un NC que cambia pocas veces, como el NC de esquema, no ocupe ancho de banda de red que necesita el DC de dominio, que probablemente cambiará con mayor frecuencia.
Dado que los cambios de directorio se pueden realizar desde cualquier DC de Active Directory, la réplica de Active Directory debe realizar el seguimiento de dos tipos de operaciones de escritura. Uno de los tipos es el de las escrituras originales: aquéllas que tienen lugar cuando un determinado cambio se realiza directamente en un DC determinado. Por ejemplo, si se conecta a DC1 y cambia una contraseña de usuario, el cambio en cuestión se considera una escritura original en DC1. Active Directory también debe realizar el seguimiento de escrituras replicadas; como puede suponer, esto significa que se ha replicado un determinado cambio desde otro controlador de dominio. El cambio que se haya considera escritura original en DC1 se considera una escritura replicada cuando se replica a DC2, a DC3 y a cualquier otro DC en todo el dominio.
Los controladores de dominio de Active Directory administran la transmisión de cambios de directorio mediante el uso de metadatos de réplica. Esto significa que, además de comunicar los datos reales que han cambiado de un DC a otro (si la descripción de John Smith se cambia por "Director de RR. HH."), Active Directory también transmite información adicional acerca de dicho cambio para permitir que los controladores de dominio administren la réplica de la manera más eficiente, como por ejemplo el DC a partir del cuál se originó el cambio, el momento en que se realizó el cambio y otros datos clave.
El primer elemento de los metadatos de réplica que explicaremos es el números de secuencias de actualización (USN). Cada controlador de dominio mantiene un USN que es específico de dicho controlador de dominio. Siempre que se realiza un cambio en Active Directory desde ese DC, el USN se incrementa en 1. Así que si un DC tiene un USN de 1.000 a las 11 de la mañana y de 1.005 a las 11:30 de la mañana, sabrá que se realizaron cinco cambios en la base de datos de Active Directory en ese DC. Cuáles hayan sido dichos cambios no importa en lo que respecta al USN: puede haber modificado cinco objetos diferentes, creado cinco objetos, eliminado cinco objetos o cualquier combinación de estas opciones; el USN del DC seguirá aumentando en cinco. Además, los USN sólo pertenecen a un controlador de dominio específico, y no tienen ninguna relevancia cuando se comparan con los otros DC. Es posible que un DC de un dominio realice un cambio a las 11:30 de la mañana al que asigne un USN de 1051, y que un segundo DC del mismo dominio realice un cambio precisamente en el mismo momento que le asigna un USN de 5084. Aunque estos dos DC tienen USN radicalmente diferentes para un cambio que se realiza aproximadamente en el mismo momento, este hecho es irrelevante para la manera en que se replican estos cambios; los números de secuencias de actualización de un DC no tienen ningún significado en ninguno de los otros DC en cuanto a la comparación de los cambios entre sí.
Pero esta no es la única manera de aumentar un USN de DC. Recuerde que un cambio en la base de datos de Active Directory puede consistir en una escritura original o una escritura replicada. Ambos tipos de operaciones de escritura aumentan los números de secuencias actualizadas en un controlador de dominio, lo cual significa que aumentan siempre que los cambios se replican desde otro DC. Ahora, cada DC necesita claramente una manera de realizar un seguimiento de los cambios que ya se han replicado ya que, de lo contrario, cada DC enviaría a través de la red la base de datos completa de Active Directory en cada réplica. Para evitarlo, cada controlador de dominio de Active Directory mantiene un valor denominado vector de límite máximo (HWMV) para los otros controladores de dominio con los cuales realiza la réplica. Cada DC asociará este vector de límite máximo al identificador único global (GUID) del DC remoto, para evitar cualquier confusión si un controlador de dominio remoto cambia de nombre o se elimina del directorio.
Empecemos con un ejemplo sencillo, donde se configuran dos controladores de dominio en los dominios contoso.com, dc1.contoso.com y dc2.contoso.com. Dado que existen dos DC en el dominio contoso.com, DC1 y DC2 sólo se replican entre sí. Tenga en cuenta que este es un ejemplo sencillo que aún no muestra todo el panorama de réplica de Active Directory; añadiremos más información a medida que vayamos explicando más detalles.
También hay que señalar que el USN actual de DC1 es 3000, el USN actual de DC2 es 4500, y que estos dos DC están completamente actualizados entre sí cuando empezamos nuestro ejemplo:
Paso 1: DC1 y DC2 están actualizados entre sí. DC1 tiene un vector de límite máximo para DC2 de 4500, y DC2 tiene un vector de límite máximo para DC1 de 3000, como se muestra en la figura 1.
Figura 1 Estado actual de los dos DC
Figura 1 Estado actual de los dos DC
Paso 2: Un administrador crea un nuevo objeto en DC1, y el USN de DC1 aumenta a 3001, como se muestra en la figura 2. Observe que el HWMV de DC1 no cambia en DC2, porque DC1 aún no ha notificado a DC2 que tiene cambios en espera.
Figura 2 Se agrega un nuevo objeto
Figura 2 Se agrega un nuevo objeto
Paso 3: DC1 notifica a DC2 que tiene cambios disponibles. DC2 inicia la réplica con DC1 para solicitar todas las actualizaciones disponibles. Como parte de esta solicitud, DC2 envía a DC1 el vector de límite máximo que tiene almacenado para DC1, como se muestra en la figura 3.
Figura 3 Notificación de cambios
Figura 3 Notificación de cambios
Paso 4: DC1 envía a DC2 el cambio que corresponde al USN 3001, es decir, el objeto que se crea en DC1 en el paso 2. DC2 actualiza su propio USN a 4501 y su HWMV para DC1 a 3001, como se muestra en la figura 4.
Figura 4 Cambios y actualizaciones
Figura 4 Cambios y actualizaciones
¿Todo bien por ahora? Pero ahora existe un problema. DC2 tiene un cambio que necesita replicar. Si lo único necesario son los USN y los vectores de límite máximos, en este momento DC2 se pondría en contacto con DC1 para volver a replicarle el mismo cambio que DC1 acaba de replicar a DC2, lo cual provocaría un ciclo de réplica interminable y eso consumiría cada vez más el ancho de banda de manera progresiva. Para combatir esta situación, necesitamos algunas piezas más del rompecabezas, y la primera de ellas es el vector de actualización (vector UTD o, simplemente, UTDV).
El UTDV es otra parte de los metadatos de réplica que se usa para amortiguar la propagación; es decir, su propósito es evitar que un mismo cambio malgaste el ancho de banda con continuas replicas una y otra vez a través de la red. Cada DC mantiene una tabla de UTDV para el resto de los DC que almacenan una réplica del contexto de nomenclatura en cuestión. Para el NC de dominio, cada DC de un dominio mantiene un UTDV para cada DC del dominio; para los NC de configuración y esquema, se mantiene para cada DC del bosque. La tabla de UTDV realiza un seguimiento no sólo del USN más alto que ha recibido cada DC de sus asociados de réplica, sino también del valor más alto de USN que ha recibido de cada DC que replica un NC determinado. Para permitir que esto suceda, cada cambio que se replica incluye también la siguiente información:
  • El GUID del DC que replica el cambio. Puede ser un cambio que se replica como una escritura original o como una escritura replicada.
  • El USN del DC que replica el cambio. Una vez más, puede ser de una escritura original o de una escritura replicada.
  • El GUID del DC que originó el cambio. Si este GUID es el mismo que el GUID del DC que replica el cambio, entonces se trata de una escritura original. De lo contrario, entra en juego la tabla de UTDV.
  • El USN del DC que originó el cambio. Nuevamente, si este USN es el mismo que el USN del DC que replica el cambio, entonces se trata de una escritura original. De lo contrario, la tabla de UTDV está desactivada.
Para ilustrar mejor este proceso, aumentaremos la complejidad de nuestro ejemplo añadiendo un tercer controlador de dominio, DC3. En esta instancia, DC1, DC2, y DC3 son todos asociados de réplica mutuos: DC1 replica con DC2 y DC3, DC2 con DC1 y DC3, y DC3 con DC1 y DC2:
Paso 1: DC1, DC2 y DC3 están todos actualizados entre sí.
Paso 2: DC3 realiza una sola escritura original al restablecer la contraseña de la cuenta de usuario jsmith. DC3 notifica a DC1 y DC2 que tiene cambios disponibles. DC1 y DC2 incorporan la escritura original de DC3 y, a continuación, actualizan sus tablas de HWMV y de UTDV para DC3 como se muestra en la figura 5.
Figura 5 Actualización de las tablas de HWMV y de UDTV
Figura 5 Actualización de las tablas de HWMV y de UDTV
Paso 3: Aquí es donde entra en juego el vector de actualización. DC2 notifica a DC1 que tiene cambios disponibles. A continuación, DC1 se pone en contacto con DC2 para solicitar los nuevos cambios al enviar a DC2 la siguiente información:
  • El valor de límite máximo de DC1 para DC2, que en este caso es 4501.
  • La tabla de UTDV de DC1 (que se muestra en la figura 6), que indica el USN original que ha recibido de todos los DC, incluido DC3.
Figure 6 Tabla UTDV (Close Figure 6)

Todos los DC que replican este NC | UTDV
<GUID de DC2> | 4501
<GUID de DC3> | 7002
En función del HWMV de 4501, DC2 comprueba que no ha replicado el cambio en cuestión a DC1 (consulte la figura 7).
Figure 7 Es necesario replicar un cambio (Close Figure 7)

Propiedad | Valor | GUID de DC local | USN local | El GUID del DC original | USN original
Propiedad de contraseña de jsmith | %#FH%2rfg2 | <GUID de DC2> | 4501 | <GUID de DC3> | 7002
Sin embargo, a partir de la tabla de UTDV que DC1 transmitió antes de que comenzara la réplica, DC2 determina que en realidad DC1 no necesita este cambio, porque ya lo ha recibido de DC3. En este momento, DC1 simplemente actualiza su entrada de HWMV para DC2 para reflejar el aumento de USN, como se muestra en la figura 8. Sin embargo, para conservar el ancho de banda, los datos reales no se envían por la red.
Figura 8 Amortiguamiento de la propagación
Figura 8 Amortiguamiento de la propagación
Paso 4: Este mismo amortiguamiento de propagación se producirá cuando DC2 notifique a DC3 que tiene cambios disponibles y cuando de DC1 notifique a DC2 y DC3 del mismo modo. Los tres DC actualizarán sus respectivas entradas de HWMV para sus asociados de réplica como se muestra en la figura 8, pero nuevamente, los datos reales no recorrerán la red porque ya se transmitieron a cada DC en el paso 2.

Resolución de conflictos en un entorno con varios maestros
Hasta aquí nuestros ejemplos pertenecen a un mundo ideal, donde sólo un administrador realiza cambios en un DC a la vez y jamás nadie pisa el trabajo de los demás. En el mundo real, sabemos que rara vez sucede así. Como las actualizaciones de un objeto de Active Directory pueden venir de cualquier controlador de dominio del dominio, ¿qué sucede si dos administradores realizan actualizaciones que producen conflictos desde dos controladores de dominio diferentes? En un entorno de Active Directory se producen tres tipos de conflictos, y cada uno de ellos usa un método de resolución de conflictos diferente.
Cambios de propiedad que producen conflictos . Este conflicto se produce si dos administradores actualizan el mismo objeto de una manera que genere un conflicto: un administrador define la descripción de un usuario como "Marketing", mientras que otro administrador en un DC diferente define la misma descripción de usuario como "Ventas y marketing".
Creación de nuevos objetos que entran en conflicto . Este conflicto se produce si dos administradores crean un objeto con el mismo nombre al mismo tiempo, como por ejemplo, dos usuarios denominados jsmith.
Mover un objeto a un contenedor eliminado . Este tipo de conflicto es mucho menos habitual y sucede si un administrador crea o mueve un objeto de un contenedor, como una unidad organizativa, al mismo tiempo que otro administrador de un DC diferente elimina dicho contenedor.
Para abordar los dos primeros tipos de conflictos, es el momento de presentar dos conjuntos más de metadatos de réplica que se usan principalmente en la resolución de conflictos. El valor versionID se asigna a cada atributo individual de un objeto, con un valor inicial de 1 cuando el objeto se crea por primera vez. VersionID aumenta en 1 siempre que desde cualquier DC se modifica un atributo individual. Por lo tanto, si se actualiza el atributo de descripción de un usuario concreto desde su valor predeterminado (en blanco o <no establecido>) a "Departamento de marketing", el atributo de descripción tendrá un versionID de 2. Si más adelante la descripción se modifica a "Departamento de ventas y marketing", el atributo de descripción tendrá un versionID de 3, etc. Este versionID se incluye con cada entrada de réplica junto con los otros conjuntos de metadatos que ya hemos presentado.
VersionID también se puede usar para reducir aún más el tráfico de réplica. Por ejemplo si un administrador de DC2 ha realizado varios cambios en un único atributo (quizás haya cometido errores al escribir el cambio) de manera que DC2 tenga las escrituras originales correspondientes a los versionID 2, 3, 4 y 5, entonces DC2 sólo replicará la escritura correspondiente al último, versionID 5. Dado que, de todos modos, los cambios anteriores simplemente estarán sobrescritos, de este modo se obtiene un método abreviado para reducir el uso innecesario de ancho de banda.
Cada cambio en Active Directory incluye también la segundo conjunto adicional de metadatos que se usa en la resolución de conflictos, una marca de tiempo, como parte de los metadatos de réplica y que indica cuándo se realizó la modificación.
El atributo de marca de tiempo se usa también como una medida proactiva del estado de Active Directory. Si un DC no ha detectado cambios con una marca de tiempo relativamente reciente de un DC determinado, comenzará a generar mensajes de error que indican que es posible que exista un problema con el DC en cuestión.
¿Cómo se usan estos dos atributos en la resolución de conflictos? Examinemos por separado cada tipo de conflicto.

Resolución de cambios de propiedad que producen conflictos
Considere el ejemplo del objeto de usuario jsmith en el dominio contoso.com. Un administrador en DC1 cambia la descripción de jsmith a "Marketing". Casi simultáneamente, un administrador en DC3 cambia la misma descripción de usuario a "Ventas y marketing". En este momento, la información comparada de DC1 y DC3 acerca del atributo de la descripción de jsmith es la que se muestra en la figura 9.
Figure 9 Cambios casi simultáneos (Close Figure 9)

Servidor | Propiedad | Valor | VersionID | TimeStamp | GUID de DC local | USN local | El GUID del DC original | USN original
DC1 | Propiedad de descripción de jsmith | "Marketing" | 2 | 2007-06-07 14:03:25 | <GUID de DC1> | 3003 | <GUID de DC1> | 3003
DC3 | Propiedad de descripción de jsmith | "Ventas y marketing" | 2 | 2007-06-07 14:04:57 | <GUID de DC3> | 7003 | <GUID de DC3> | 7003
Si DC2 recibe simultáneamente ambos cambios, está claro que deberá determinar cuál es el cambio "ganador". El orden de desempates para la resolución de conflictos es el siguiente:
  1. La modificación que tiene el versionID más alto se aceptará como cambio "ganador"; el cambio "perdedor" se sobrescribirá. En este caso, el versionID es 2 para ambos registros, así que necesitamos pasar al segundo factor de desempate.
  2. Si ambos registros tienen el mismo versionID, el cambio que tiene la marca de tiempo posterior será aceptado como cambio ganador; se sobrescribirá el cambio perdedor. En este caso, la marca de tiempo de la escritura original de DC3 es posterior, así que la descripción de jsmith se establece en "Ventas y marketing". En el caso poco habitual de que tanto versionID como la marca de tiempo sean idénticos, necesitamos un tercer factor de desempate definitivo:
  3. Si ambos registros tienen el mismo versionID y la misma marca de tiempo, ganará cualquier escritura que se origine en el DC con el GUID de número más bajo; se sobrescribirá la escritura con el GUID de número más alto. Por lo tanto si el GUID de DC1 es 1234567890 y el GUID de DC3 es 2345678901, la escritura original de DC1 ganaría si versionID y la marca de tiempo fueran idénticos.
Probablemente piense: "¿No hubiera tenido más sentido que la marca de tiempo fuera el primer factor de desempate? Esta situación no está tan definida como quizás crea. Si la marca de tiempo fuera el principal factor de desempate en la resolución de conflictos de Active Directory, lo único que un administrador malintencionado necesitaría hacer para propagar sus cambios sería retrasar el reloj en un DC determinado para que siempre gane gracias a las marcas de tiempo.

Resolución de conflictos de creación de objetos
En los casos donde se crean dos objetos con el mismo nombre, Active Directory usará los tres mismos factores de desempate descritos en la sección anterior para determinar cuál es el objeto "ganador". Sin embargo, a diferencia de la sección anterior, el objeto "perdedor" no se sobrescribe. En vez de eso, se cambia el nombre del objeto perdedor mediante caracteres CNF (que indica objetos en conflicto), seguido por dos puntos y el GUID del objeto "perdedor". Esto permite que los administradores determinen más metódicamente qué objeto se debe retener y cuál eliminar.

Resolución del traslado de un objeto a un contenedor eliminado
Como mencioné anteriormente, la resolución del traslado de un objeto a un contenedor eliminado es un conflicto relativamente poco habitual, que sólo se produce en dos situaciones. En una, un administrador de un DC crea un objeto dentro de un contenedor determinado, por ejemplo la unidad organizativa Aprendizaje, al mismo tiempo que un administrador de otro DC elimina la unidad organizativa Aprendizaje. La segunda situación se puede producir cuando un administrador de un DC mueve un objeto a un contenedor al mismo tiempo que un administrador de otro DC elimina dicho contenedor.
En este caso, la resolución es bastante sencilla: Active Directory mueve el objeto "huérfano" a un contenedor especial diseñado para este fin dentro de Active Directory, el contenedor LostAndFound, que está ubicado en la raíz de cada dominio de Active Directory. En el dominio contoso.com, el contenedor LostAndFound se encuentra en la siguiente ruta de acceso LDAP: LDAP://cn=LostAndFound,dc=contoso,dc=com. Si no ve el contenedor LostAndFound cuando abre el complemento Usuarios y equipos de Active Directory, simplemente haga clic en Ver | Características avanzadas.

Protección contra la reversión de USN
Una de las situaciones más graves que puede encontrar en un entorno de Active Directory es también una de las más sencillas de evitar, una vez que se comprende su causa y cómo solucionar el problema. La reversión de USN es una condición de error que puede bloquear la réplica en su red por completo, y se produce cuando se permite que un controlador de dominio permanezca durante mucho tiempo sin conexión y más adelante vuelve a funcionar o cuando se restaura un controlador de dominio con un método no admitido.
Una causa subyacente de reversión de USN tiene que ver con la manera en que se procesan las eliminaciones de objetos en el entorno con varios maestros de Active Directory. Cuando un objeto se elimina en un DC, no se elimina por completo el objeto, sino que éste desecha de manera que el objeto de desecho se pueda replicar a los otros DC y notificarles así su eliminación. Lo más notable es que un objeto de desecho posee un atributo isDeleted que se establece en TRUE. Para reducir el tamaño del objeto de desecho, se elimina la mayor parte de los valores contenidos en el objeto, tales como descripción, información personal y pertenencia a grupos de un objeto de usuario (para obtener más información sobre este proceso, consulte el artículo de Gil Kirkpatrick "Reanimación de objetos de desecho de Active Directory," disponible en línea en technetmagazine.com/issues/2007/09).
La reversión de USN se puede producir porque estos objetos de desecho no se conservan por tiempo indefinido. De forma predeterminada, se purgan por completo de la base de datos de Active Directory después de 60 o 180 días (en función de la versión de Windows Server® que se ejecuta cuando se crea el entorno de Active Directory por primera vez). Este período de 60 o 180 días se denomina vigencia de objetos de desecho. Todos los controladores de dominio necesitan tener la posibilidad de replicar por lo menos una vez durante este período para no convertirse en elementos prácticamente inútiles; crean una oportunidad para la reversión de USN. Básicamente, la reversión de USN se produce cuando un controlador de dominio está tan desactualizado que "pierde" uno o más objetos de desecho y, de este modo, no puede obtener su copia local de la base de datos de Active Directory con un estado completamente actualizado con los otros DC. Para evitarlo, ningún controlador de dominio que permanezca sin conexión durante un tiempo mayor que la vigencia de objetos de desecho se debe volver a funcionar; más bien se debe reconstruir desde el principio después de eliminar los metadatos del antiguo DC de Active Directory con los pasos que se describen en el artículo 216498 de Microsoft Knowledge Base (support.microsoft.com/kb/216498).
La segunda causa de reversión de USN se produce cuando un controlador de dominio se restaura con un método no compatible, normalmente mediante una herramienta de clonación o creación de imagen de disco. Cuando esto sucede, la base de datos de Active Directory restaurada no se da cuenta de que se encuentra "atrasada en el tiempo", porque el método de restauración no conoce Active Directory. La reversión de USN era difícil de detectar en Windows 2000 y en la versión inicial de Windows Server 2003, pero Windows Server 2003 SP1 (y Windows Server 2008, aparecerá pronto en el mercado) tienen controles integrados para detectar cuándo un DC se restaura de un modo incorrecto. En estas versiones más reciente de los sistemas operativos, un DC registrará los identificadores de evento 1115, 2095, 2103 y 2110 en el registro de eventos de servicios de directorio; el texto de estos eventos, así como los pasos necesarios para realizar una recuperación ante una reversión de USN, se pueden encontrar en el artículo 875495 de Microsoft Knowledge Base (support.microsoft.com/kb/875495) para Windows Server 2003. Puede obtener información sobre cómo trabajar con reversiones de USN en Windows 2000 en el artículo 885875 de Microsoft Knowledge Base, disponible en support.microsoft.com/kb/885875).

Actualización del modelo de varios maestros en 2008
En la versión de Windows Server 2008 que pronto verá la luz, Microsoft ha incluido un leve cambio en el modelo de varios maestros: el Controlador de dominio de sólo lectura (RODC). El RODC está diseñado principalmente para implementaciones de sucursal o para cualquier situación donde no se dispone de personal de TI dedicado en una ubicación determinada y es necesario dar pasos adicionales para garantizar la integridad de un DC determinado. Aunque podríamos ocupar un artículo completo en explicar todos los detalles técnicos del RODC, revisemos los puntos clave que debe conocer.
Como su propio nombre indica, la copia de la base de datos de Active Directory que reside en un RODC es de sólo lectura. Puede conectarse a un RODC para leer prácticamente cualquier información que necesite, pero no puede realizar operaciones de escritura en un RODC.
En segundo lugar, un RODC no realiza ninguna réplica de salida. Este es un cambio fundamental respecto al modelo de réplica con varios maestros que hemos explicado hasta aquí. Un RODC recibirá la réplica de entrada de otros DC que se pueden escribir de Windows Server 2008, pero en ningún caso replicará información a los otros DC. Esto crea un nivel adicional de seguridad de manera tal que, incluso si un usuario malintencionado puede modificar de algún modo Active Directory desde el RODC, esas modificaciones no se propagarán hacia afuera al resto de su entorno.
Quizás lo más interesante de todo es que el RODC no replica contraseñas de usuario de forma predeterminada. Cuando la base de datos de Active Directory se replica de forma entrante a un RODC desde un DC que se puede escribir, todos los objetos de usuario se replican sin la información de la contraseña de usuario. Esto ofrece aún otro nivel de seguridad en un entorno de sucursal, de manera tal que si a un DC tuviera piernas y pudiera marcharse, no existe información de contraseña residente en el disco duro del DC. En conjunto, estos cambios en la idea original de réplica de Active Directory con varios maestros crean un modelo con muchas mejoras para la protección de los controladores de dominio ubicados en sucursales u otras ubicaciones remotas.

Laura E. Hunter ha recibido cuatro veces el premio Microsoft MVP en el área de redes de Windows Server. Cuenta con 10 años de experiencia en el sector de TI y es autora o coautora de numerosos libros, artículos, y notas del producto del sector, como Active Directory Cookbook, segunda edición (O'Reilly, 2006).


 System Center: Nuevas herramientas de administraci&#243;n de actualizaciones de software
System Center Steve Rachui

Nuevas herramientas de administración de actualizaciones de software
Resumen:
  • Administración de actualizaciones de forma tradicional
  • El nuevo proceso en SCCM 2007
  • Configuración y flexibilidad personalizadas
  • Programación de actualizaciones con precisión

La administración de las actualizaciones de software se introdujo por primera vez en Systems Management Server (SMS) 2.0 con las herramientas de detección de seguridad y actualizaciones de Office. Estas herramientas han experimentado numerosas revisiones: la herramienta ampliada de
de inventario de actualizaciones de seguridad se ha revisado para aceptar la digitalización de productos adicionales; la herramienta de inventario Inventory Tool for Microsoft ® Updates, para combinar las herramientas de seguridad y de Office en un solo producto; e Inventory Tool para actualizaciones de Dell. La herramienta de publicación de actualizaciones personalizadas también se introdujo para admitir la revisión de productos de terceros. Inventory Tool for Microsoft Updates (ITMU) ha pasado por tres revisiones. Cada una de estas herramientas tiene sus propios catálogos e infraestructura de detección así como requisitos y desafíos específicos. Con el tiempo, los catálogos para estos sistemas se hicieron bastante grandes; de hecho, se hicieron tan grandes que las actualizaciones más antiguas se eliminaron y se sustituyeron por otras nuevas debido a las restricciones de tamaño.
Con la cantidad de opciones existentes, era un reto implementar actualizaciones con estas herramientas. Es evidente que existía la necesidad de simplificar el proceso. La siguiente versión de SMS, System Center Configuration Manager 2007 (SCCM), da grandes pasos en esa dirección. Con SCCM, el mecanismo de actualización de software se crea para garantizar que los resultados finales sean mejores. Con un enfoque completamente diferente de las operaciones de administración de actualizaciones, los viejos catálogos y motores de análisis son cosa del pasado. El estado de las actualizaciones, que normalmente se detallaba mediante inventario de hardware, usa un mecanismo nuevo (el mensaje de estado) para asegurar una mejor determinación del cumplimiento, así como su aplicación en cada cliente. Podrá comprobar que el nuevo de la administración de actualizaciones en SCCM 2007 representa una mejora considerable.
SCCM 2007 presenta dos componentes nuevos, que trataremos antes de adentrarnos en la funcionalidad de administración de actualizaciones.
Software Update Point (SUP) Como ya se ha mencionado, ya no existen catálogos en SCCM. En su lugar, SCCM trabaja directamente con un servidor de Windows Server® Update Services (WSUS) dedicado, que actuará como punto de actualización de software (SUP) para permitir descargas de metadatos y detección de clientes. En SCCM, las características de entrega binaria de actualizaciones del WSUS están deshabilitadas para centrarse en el proceso de detección. Con este ajuste, WSUS se adapta para administrar la detección de hasta 25.000 clientes por SUP en un servidor dedicado. SCCM permite también configurar el SUP detrás de un clúster de equilibrio de carga de red (NLB) para aumentar la disponibilidad y la escala y habilitar hasta cuatro SUP para un total de 100.000 posibles clientes por sitio principal.
Elementos de configuración (CI) Un elemento de configuración es un enfoque nuevo que se usa en SCCM para definir configuraciones específicas que deben existir en los sistemas de destino. La administración de actualizaciones de SCCM ahora usa esta infraestructura. Las actualizaciones ya no deben considerarse en términos de distribución normal de software, aunque todavía existen similitudes. Ahora, las actualizaciones residen en su propio nodo de la consola de administrador y usan este mecanismo completamente único de CI. En el cliente, las actualizaciones se descargan de forma selectiva y se almacenan de forma local.

Configuración de la administración de actualizaciones
La configuración de la administración de actualizaciones afecta a tres áreas generales: habilitar el agente de cliente, configurar el SUP y configurar las actualizaciones para la distribución.
El agente del cliente de SCCM (tal y como se muestra en la figura 1) es parecido a otros agentes de cliente, y se configura en el mismo nodo de la consola administrativa. La página de propiedades del nodo Software Updates Client Agents es donde los administradores habilitan este agente y configuran las opciones de instalación de actualizaciones y de reevaluación de implementación. La opción para habilitar el agente de cliente para actualizaciones de software afecta a todo el sitio; es decir, que todos los clientes de SCCM asignados al sitio donde está activada esta función tendrán este rol habilitado. Si algún sistema de un entorno no debe tener esta función habilitada, puede invalidar la configuración para todo el sitio y usar la configuración en función de cada sistema mediante las opciones de invalidación de directiva local.
Figura 1 Propiedades del agente de cliente
Figura 1 Propiedades del agente de cliente
Estas opciones también permiten al administrador especificar cómo administrar los plazos de actualización. Imagine, por ejemplo, que tiene cuatro actualizaciones pendientes de instalación, una de las cuales (la actualización A) tiene una fecha límite anterior por un día a la de las otras tres. Pero suponga que es preferible instalar las cuatro actualizaciones al mismo tiempo, incluso aquellas cuya fecha límite no se ha alcanzado todavía. Puede hacerlo desde esta ficha, mediante la opción de aplicar todas las implementaciones obligatorias. Es más, estas opciones permiten a los administradores especificar que deben suprimirse todas las notificaciones y las indicaciones visibles del proceso de actualización. Estas opciones se muestran en la figura 1.
Las opciones de la ficha Deployment Re-evaluation permiten a los administradores programar cuándo se reevaluarán las implementaciones. Los clientes de SCCM se evaluarán según esta programación, para consultar si las actualizaciones que se han instalado anteriormente todavía son necesarias y, si faltan, volverlas a instalar.

Configuración del SUP
Tal y como se ha explicado anteriormente, el SUP es el componente responsable de descargar toda la información de actualización disponible en una programación y para interactuar directamente con clientes de SCCM para realizar comprobaciones de cumplimiento a partir de la base de datos de actualizaciones. Antes de configurar un SUP, debe instalarse un WSUS 3.0 o un servidor más grande, ya que el proceso del SUP no instala realmente WSUS, sólo lo configura para el uso de SCCM. Además, la consola de administrador de WSUS debe estar instalada en el servidor del sitio para permitir la conectividad con el servidor WSUS. Cuando SCCM sustituye al servidor WSUS para la función de SUP, el servidor WSUS queda dedicado a SCCM y sólo los clientes de éste lo pueden usar.
El SUP es una nueva función del sistema de sitio en SCCM. Para empezar la configuración, navegue hasta el nodo de sistemas del sitio en la consola de administrador y añada un nuevo sistema del sitio. El paso siguiente es seleccionar Software Update Point y seguir el asistente, que recogerá la información siguiente:
  • Configuración de proxy
  • Información de puerto y SSL
  • La forma en que este SUP debe sincronizar las actualizaciones: desde Microsoft Update, mediante un SUP precedente o manualmente
  • Programación de sincronización
  • Actualice las clasificaciones de interés, como las actualizaciones críticas, los controladores, las actualizaciones de seguridad, los conjuntos de actualizaciones, etc.
  • Actualice los productos disponibles: Windows® Exchange, SQL Server™, etc. (tal y como muestra la figura 2)
  • Idioma
Figura 2 Configuración del producto en el asistente de función del sitio
Figura 2 Configuración del producto en el asistente de función del sitio
Una vez completado el asistente, se instalará el SUP y se ajustarán las configuraciones internas para que sean compatibles con los requisitos de SCCM. Se recomienda confirmar que la instalación se ha realizado correctamente revisando el archivo SUPSetup.log que se encuentra en la carpeta de registros donde se ha instalado SCCM.
Una vez instalado el SUP, debe realizarse la sincronización para que el SUP recupere las actualizaciones y las almacene en la base de datos de SUP y SCCM. La sincronización puede ejecutarse manualmente o en una programación configurada cuando se ejecuta el asistente de instalación de SUP. La sincronización de actualización manual puede inicializarse a tiempo, y es recomendable asegurar que la sincronización se realice después de instalar el SUP por primera vez. La figura 3 muestra cómo hacerlo.
Figura 3 Ejecutar la sincronización manualmente
Figura 3 Ejecutar la sincronización manualmente
El proceso de sincronización consta de dos pasos. Primero, el servidor SUP (WSUS) se configura para ajustarse a la configuración de SCCM y las actualizaciones configuradas se sincronizan con el propio servidor SUP (WSUS). A continuación, la información de actualización del SUP (WSUS) se sincroniza en la base de datos de SCCM y pasa a estar disponible para la implementación de la actualización. Este segundo paso crea los CI necesarios (uno para cada actualización de software) en la base de datos de SCCM; este proceso puede tardar bastante tiempo. La sincronización inicial puede llegar a durar varias horas. El proceso de sincronización puede revisarse en el registro WSyncMgr; se muestra un extracto de este registro en las figuras 4 y 5. Concretamente, la figura 4 muestra el proceso de sincronización que solicita que el servidor SUP (WSUS) actualice su lista de actualizaciones desde Microsoft Update. La figura 5 muestra el inicio del proceso para sincronizar el inventario de SUP con la base de datos de SCCM.
Figura 4 Sincronización de la lista de actualizaciones
Figura 4 Sincronización de la lista de actualizaciones
Figura 5 Sincronizar las actualizaciones como CI en la base de datos de SCCM
Figura 5 Sincronizar las actualizaciones como CI en la base de datos de SCCM
Una vez que un servidor de WSUS se ha configurado como un SUP, puede llevarse a cabo cualquier acción de administración necesaria mediante la consola del administrador de SCCM. Si los cambios de configuración se realizan directamente en el servidor de WSUS, es posible que SCCM resulte afectado de forma negativa. Además, estas configuraciones se restablecerán cada hora, cuando SCCM compruebe su SUP para garantizar que las configuraciones sean correctas.
En una jerarquía de varios niveles, necesita tener por lo menos un SUP en cada sitio principal en el que se vayan a implementar actualizaciones de software. Estos SUP trabajarán juntos en una jerarquía en la que sólo un SUP, que normalmente es que se encuentra en el lugar más alto de la jerarquía, se sincronizará con Microsoft Updates. Los SUP restantes se sincronizarán desde un socio de réplica de SUP configurado precedente.

Configuración de la implementación de actualizaciones
Una vez configurado el agente de cliente y configurado y sincronizado el SUP, estará listo para preparar la implementación. Primero, examinemos los diversos nodos de la IU de administración de SCCM. Básicamente, hay cinco nodos principales de interés: repositorio de actualización, listas de actualización, plantillas de implementación, administración de implementaciones y paquetes de implementación.
El repositorio de actualización es donde se almacenan todas las actualizaciones sincronizadas y donde están disponibles para su implementación. Las actualizaciones pueden implementarse seleccionando una o más actualizaciones e iniciando el Asistente para implementar actualizaciones de software, que realiza dos tareas: configurar la plantilla de implementación (o seleccionar alguna ya existente) y configurar la implementación. Explicaré rápidamente en qué consiste este proceso. La lista de actualizaciones puede llegar a ser bastante grande, y la opción de buscar en carpetas, una característica nueva de SCCM 2007, puede ayudarle a encontrar actualizaciones de interés basándose en 28 criterios relacionados con las actualizaciones, como gravedad, clasificación, producto, fecha de lanzamiento o suplantación.
Las listas de actualizaciones permiten a los administradores crear un conjunto fijo de actualizaciones que administrar. Pueden usarse para la realización de informes de cumplimiento, la creación de implementaciones y para delegar las funciones de administración. Una vez creadas, estas listas de actualizaciones se replican en la jerarquía para volver a usarse en sitios secundarios, como hacen los paquetes o los anuncios. Cuando se replican, las listas de actualizaciones no están vinculadas a ninguna implementación particular; simplemente son listas de actualizaciones. Una vez completada y replicada la lista, las actualizaciones que contiene pueden implementarse como una unidad seleccionando la lista y eligiendo la implementación de actualizaciones.

Plantillas de implementación
Las plantillas de implementación contienen la configuración habitual (como, por ejemplo, la información sobre la programación y la colección de destino) usada durante la implementación de una actualización de software, y se han desarrollado para disminuir el tiempo administrativo implicado en la implementación de actualizaciones. Las plantillas pueden crearse para reaccionar ante varias condiciones de implementación en un entorno, y para usarlas en el Asistente para la implementación simplemente hay que seleccionar la plantilla apropiada. Las opciones rellenadas previamente por la plantilla de implementación incluyen la colección objetivo, las opciones de fecha límite de actualización (tal y como se muestra en la figura 6), las opciones de reinicio y las ventanas de mantenimiento. Cuando hay muchas actualizaciones en una implementación, puede resultar afectado el rendimiento del sistema de destino, ya que pueden coincidir las fechas límite de todas las actualizaciones. Además, hay que tener en cuenta que la configuración de la plantilla se aplica a la implementación cuando ésta se crea. Dicha configuración seguirá aplicándose a la implementación a menos que se modifique manualmente dentro de ésta. Es importante tener en cuenta que modificar las opciones de la plantilla más tarde no hará que se cambien las opciones modificadas en las implementaciones ya existentes que usan la plantilla modificada.
Figura 6 Definición de programaciones de implementación en el asistente
Figura 6 Definición de programaciones de implementación en el asistente
Las opciones de la figura 6 pueden configurarse al ejecutar el Asistente para plantilla de implementación o el Asistente para implementar actualizaciones de software (si se está creando una plantilla nueva). Tenga en cuenta que la opción de duración en esta pantalla está establecida en 0. El valor predeterminado de esta opción es de dos semanas. Si esta opción está establecida en un valor distinto de 0, existirá una demora en el cliente de una duración equivalente a la duración de dicho valor, como máximo antes de que se implementen las actualizaciones. En el tiempo que transcurre entre que la implementación está disponible y vence la fecha límite configurada, la actualización estará disponible para su instalación manual por parte de usuarios finales para las instalaciones programadas antes de la fecha límite. Una vez alcanzada la fecha límite, se aplicará y se instalará la actualización. Si se producen retrasos en la implementación de una actualización, compruebe que esta opción esté configurada correctamente en función de sus necesidades.

Administración de la implementación
Después de configurar una implementación de actualización de software, puede obtener acceso a ella desde el nodo de administración de implementaciones. Tenga en cuenta que una implementación de software configurada no es lo mismo que un paquete de implementación. Las opciones relacionadas con la implementación, así como las actualizaciones incluidas en la implementación, pueden verse y manipularse en este nodo, pero no el propio paquete. Las opciones de implementación que se encuentran aquí reflejan las opciones que provienen del Asistente para actualizaciones de software, así como las que se heredan de la plantilla elegida.

Paquetes de implementación
Los paquetes de implementación se parecen a los paquetes SMS estándar en que definen las características específicas de la actualización: directorio de origen, punto de distribución, etc. Los paquetes de implementación son independientes de la implementación usada para distribuir las actualizaciones y son esencialmente una ubicación de almacenamiento para las actualizaciones. Si más de un paquete de implementación contiene las actualizaciones necesarias para una implementación, los agentes de SCCM determinarán la mejor ubicación desde la que recuperar la actualización y pueden usar cualquier paquete de implementación disponible que contenga la actualización.
El Asistente para implementar actualizaciones de software se usa para implementar actualizaciones en SCCM. Dicho asistente puede usarse con actualizaciones específicas o listas de actualización. La figura 7 muestra cómo iniciar el asistente.
Figura 7 Inicio del Asistente para implementar actualizaciones de software
Figura 7 Inicio del Asistente para implementar actualizaciones de software
El asistente le pide un nombre para la implementación, le pregunta si desea usar una configuración de plantilla existente o una nueva (si se elige una plantilla nueva el asistente le solicitará que indique las opciones de plantilla descritas anteriormente), la configuración del paquete de implementación (existente o nueva), la configuración del punto de distribución, las opciones de ubicación para la descarga, los idiomas de actualización para descargar y la información de programación de implementación.
Con la configuración completa, se actualizará la directiva para notificar a los clientes de las actualizaciones de destino y se instalarán las actualizaciones en los sistemas cliente. Los procesos del cliente son bastante diferentes de las versiones anteriores y se encuentran fuera del ámbito de este artículo. Una diferencia clave, no obstante, es que los análisis de actualizaciones ya no se realizan de forma local (el SUP realiza todos los análisis) pero los detalles acerca del cumplimiento de las actualizaciones se almacenan en el repositorio local del instrumental de administración de Windows (WMI), de forma similar a las versiones anteriores.
A diferencia de las versiones anteriores, no obstante, el inventario de hardware ya no se usa para enviar el estado de actualización al servidor del sitio. Ahora, los mensajes de estado (un nuevo tipo de mensaje de estado simplificado) se envían al servidor del sitio mediante el punto de administración. Los mensajes de estado proporcionan datos acerca de todos los clientes administrados para la detección del cumplimiento y para seguir el progreso de las implementaciones. Hay una serie de nuevos informes en SCCM para la administración de actualizaciones de software, incluido el cumplimiento global por equipo de las actualizaciones implementadas en cada cliente, estado de cumplimiento de implementación por cliente, y los informes de error de cliente para detecciones e implementaciones que generan una lista ordenada por pila de los principales problemas que resolver.
Además del cumplimiento tradicional programado y obligatorio de implementaciones de actualizaciones, SCCM permite instalar actualizaciones aprobadas antes de la fecha límite de la instalación en una programación muy semejante a la usada actualmente con las actualizaciones automáticas. Este práctico complemento hará incrementar todavía más el número de sistemas compatibles antes de la fecha límite de la implementación.
Si le interesan las actualizaciones personalizadas, SCCM también las permite. La herramienta de publicación de actualizaciones personalizadas de SMS 2003 R2 ha sido modificada para poder usarlo con SCCM 2007, y ahora es el publicador de actualizaciones de System Center, de modo que pueda implementarse cualquier actualización personalizada de la misma manera que la descrita.
Los cambios para actualizar la administración son extensos en SCCM, pero desde una perspectiva administrativa deberían ser más fáciles de usar y suponer una mejora respecto a versiones anteriores. Aunque algunos de los cambios conceptuales pueden resultar difíciles de comprender al principio para los usuarios acostumbrados a SMS 2003, el esfuerzo de aprender el nuevo sistema vale la pena. Que disfrute.

Steve Rachui es ingeniero de escala de soporte técnico para la capacidad de administración del grupo de servicios de soporte técnico de productos de Microsoft. Ha proporcionado soporte técnico para SMS desde la versión 1.2. Puede ponerse en contacto con Steve en la dirección steverac@microsoft.com.


 Comunicaciones: Servidores Exchange de transporte perimetral en Microsoft
Comunicaciones Kay Unkroth

Servidores Exchange de transporte perimetral en Microsoft
Resumen:
  • La función de servidor Transporte perimetral de Exchange
  • Configuración de un laboratorio de pruebas
  • Agentes y eventos de transporte
  • Información interna del agente
Descargar el código de este artículo: ExchangeEdge2007_10.exe (354KB)

Microsoft recibe de Internet aproximadamente 13 millones de intentos de entrega de mensajes en un día hábil promedio, y bloquea más de 10,5 millones de los mismos como no legítimos. En situaciones
críticas, tales como durante ataques de correo no deseado o brotes de virus en Internet, el volumen puede aumentar a más de 90 millones. Por supuesto, este es un dato que afecta específicamente a Microsoft, pero además el scamming, correo no deseado, phishing, virus originados en le correo electrónico, recolección de directorios, ataques de denegación de servicio distribuidos (DDoS) y problemas semejantes, no son específicos de Microsoft. Frente a dichos problemas, ¿cómo garantiza la entrega de todos los mensajes legítimos a sus usuarios mientras mantiene la afluencia masiva de contenido ilegítimo, malintencionado alejada de su entorno de mensajería?
Una manera de conseguir una protección de mensajería confiable es implementar servidores de transporte perimetral de Exchange Server 2007 y Forefront Security para Exchange Server en una red perimetral entre Internet y su entorno de producción. Esta red coloca un equipo organizado de más de 10 agentes de transporte perimetral en su perímetro para ayudarlo a proteger sus sistemas y usuarios de producción. El valor de bloquear el contenido no deseado en el primer punto posible es obvio. En una situación ideal, esto sucede aún antes de que el contenido se entregue a sus servidores, si se considera la carga que de otro modo tendría que mantener su entorno de mensajería en una situación crítica. Aún así, la protección de mensajería es mucho más que el simple bloqueo de los mensajes.
Éste es el primer artículo de una serie de dos partes que analiza la arquitectura y características clave de los agentes contra correo electrónico no deseado y agentes antivirus disponibles con Exchange Server 2007 y Forefront Security para Exchange Server. Para que las explicaciones sean realistas y prácticas, le mostraré en este primer artículo cómo construir un laboratorio de pruebas que refleje el diseño de protección de mensajería que usa Microsoft en su propio entorno de producción corporativo. A continuación, cubriré la arquitectura de transporte perimetral de Exchange Server 2007 con mayor detalle.
A través de este artículo, usaré muchos scripts y archivos por lotes para automatizar las tareas de configuración más importantes. Estos archivos incluyen comentarios que explican los pasos individuales realizados. Puede encontrar los scripts en la descarga disponible en el sitio web de TechNet Magazine en technetmagazine.com/code07.aspx.

Topología de transporte perimetral
La figura 1 ilustra el diseño de transporte perimetral que Microsoft IT implementó en el entorno de producción corporativo. Existen algunas características de diseño muy interesantes que me gustaría señalar antes de explicarle la arquitectura de transporte perimetral. Si está interesado en los detalles completos de la implementación, consulte las notas del producto IT Showcase que se mencionan en la barra lateral "Recursos de Exchange".
Figura 1 Topología de transporte perimetral en Microsoft
Figura 1 Topología de transporte perimetral en Microsoft
Cuando analice la figura 1, observará que la topología de transporte perimetral en Microsoft es completamente redundante. No existe un único punto de error en ninguna ubicación. Para equilibrar la carga, Microsoft IT usa externamente operación por turnos de DNS e internamente conectores de mensajería con múltiples cabezas de puente. También es digno de mencionar que todos los servidores de transporte (concentrador de transporte y transporte perimetral) ejecutan Forefront Security para Exchange Server para la exploración de virus. Esto permite a Microsoft IT examinar todos los mensajes entrantes, salientes e internos en cuanto los mensajes alcanzan un servidor de transporte en la topología de enrutamiento de mensajes.
Otra característica de diseño importante relacionada con la seguridad es que los servidores de transporte perimetral no forman parte del entorno corporativo de Active Directory®. De hecho, no es necesario implementar servidores de transporte perimetral en ningún bosque de Active Directory. Sin embargo, para mantener un marco de administración coherente, aplicar un conjunto común de directivas y ofrecer compatibilidad con inicio de sesión único, Microsoft IT implementa todos los servidores de transporte perimetral en un bosque de la extranet que es independiente del entorno de producción.
Por último, puede ver claramente que todos los mensajes de Internet llegan a Microsoft a través de los servidores de transporte perimetral situados en Norteamérica. Los servidores de transporte perimetral que se encuentran en Dublín y Singapur sólo atienden los mensajes salientes. La ventaja de concentrar todo el tráfico entrante en los servidores de transporte perimetral en Norteamérica es centralizar la seguridad y los controles contra correo electrónico no deseado mientras se evita la transferencia de mensajes salientes de los grandes centros de datos regionales a través de la red troncal de mensajería interna.
Omesh Desai, ingeniero de sistemas de Microsoft IT, diseñó la topología de transporte perimetral en Microsoft. Cuando pregunté a Omesh acerca de las características más importantes de diseño, me dijo: "En nuestro diseño de transporte perimetral, aprovechamos las capacidades nativas de Exchange contra el correo electrónico no deseado y las capacidades antivirus para conseguir una protección de mensajería en múltiples niveles en la red troncal de mensajería. La seguridad del perímetro de mensajería es la máxima prioridad pero también es importante un modelo de administración sencillo. Los servidores de transporte perimetral nos ayudan a aumentar la seguridad mediante configuraciones de firewall más estrictas a la vez que aumenta la precisión del filtrado de correo no deseado a través de servicios de reputación IP, actualizaciones automáticas de filtros de contenido, agregación de lista segura y validación de matasellos de correo electrónico. Toda la comunicación interna de servidor a servidor se cifra de forma predeterminada y si es posible ciframos también la comunicación con destinos externos.
En nuestros servidores de transporte perimetral usamos dos procesadores de doble núcleo de 64 bits y ocho gigabytes de memoria. Con seis de estos servidores, con equilibrio de carga a través de dos centros de datos, tenemos las capacidades necesarias para aguantar incluso grandes cargas de entregas de mensajes, tal como sucede durante los brotes de virus en Internet".

Laboratorio de pruebas de transporte perimetral
Instalación del laboratorio de pruebas
Dado que se recomienda usar nombres de dominio no existentes y direcciones IP privadas, usaré AdventureWorks.com y las direcciones IP de los intervalos 192.168.xxx.0-24. No hay matrices de sistemas redundantes ni de firewalls porque no realizo pruebas de equilibrio de carga ni tolerancia a errores. Por supuesto, los sistemas firewall actuales que usa Microsoft IT no se pueden analizar por razones de seguridad. De todos modos, dichos detalles no son importantes para este entorno de pruebas.
Mi entorno de pruebas usa ISA Server 2006 porque probablemente es uno de los sistemas firewall más comunes que se usan con Exchange Server 2007. La ejecución de ISA Server 2006 tanto en el firewall externo como en el interno ayuda a mantener la complejidad del entorno de pruebas en un nivel moderado, si bien para entornos de producción recomiendo usar sistemas variados de firewall externos e internos, para aumentar la seguridad. No implementé directivas de seguridad IP (IPsec) ni preparé el entorno para seguridad del nivel de transporte (TLS), porque estos temas están fuera del ámbito de este artículo.
Sin embargo, usé máquinas virtuales y software de evaluación de 32 bits, que puede descargar del sitio web de Microsoft. Microsoft no admite la versión de 32 bits de Exchange Server 2007 en producción, pero en un entorno de pruebas no presenta problemas.
Siempre que sea posible, mi laboratorio de pruebas depende de la configuración predeterminada. Sólo la configuración IP, los firewalls y las zonas DNS requieren cierta atención especial antes de ejecutar la instalación de Exchange Server 2007 y suscribir el servidor de transporte perimetral al entorno de producción. Para obtener más información respecto a la configuración IP, consulte el laboratorio de pruebas, en el archivo IP Configuration.xls que encontrará en la descarga complementaria. Si usa las mismas asignaciones de dirección IP, puede configurar rápidamente el firewall externo, llamado ISA01, si ejecuta directamente el script ISA01_Firewall_Policies.vbs en el equipo ISA01, y puede usar ISA02_Firewall_Policies.vbs para el firewall interno (ISA02). La descarga complementaria incluye también los archivos por lotes para configurar los servidores DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat y AD02_DNS_Config.bat). Debido a que estos archivos por lotes usan la herramienta de línea de comandos de DNS (dnscmd.exe), las herramientas de soporte de Windows deben estar instaladas; de lo contrario tendrá que crear manualmente los registros DNS por medio de la consola DNS.
Para evitar cualquier interferencia desde entornos existentes, mi laboratorio de pruebas no se conecta a Internet. Este aislamiento es una buena precaución. Aunque se generan errores en todas las descargas de actualizaciones de firmas, reputación de IP y filtros de contenido, esto no es crítico para fines de pruebas. Para evitar los mensajes de error, vaya a Actualizaciones del detector en la consola del Administrador de Forefront Server Security, y establezca la frecuencia de actualización de todos los motores de análisis en una vez, y especifique una fecha que ya haya pasado.

Para explorar estas características en acción, una buena práctica es construir un entorno de pruebas; el sentido común sugiere nunca usar un sistema de producción con fines de prueba. Como mínimo, necesita un servidor que ejecute Exchange Server 2007 para las funciones de servidor Buzón, Acceso de cliente y Concentrador de transporte. Necesitará un segundo Exchange Server para la función de servidor Transporte perimetral. Podría omitir la instalación del servidor de transporte perimetral si implementa todos los agentes de transporte en el servidor de funciones múltiples, si ejecuta el script Install-AntispamAgents.ps1 (lo podrá encontrar en los servidores concentradores de transporte en la carpeta %ProgramFiles%\Microsoft\Exchange Server\Scripts). Pero este enfoque se parecería poco a la implementación de Microsoft IT. Para un laboratorio de pruebas práctico, necesitará incluir algunos servidores más. La figura 2 muestra el entorno de pruebas que usé para la investigación de este artículo. En la descarga complementaria se encuentra a su disposición una ilustración más detallada. Para obtener más información acerca de la configuración del laboratorio, consulte la barra lateral "Instalación del laboratorio de pruebas".
Figura 2 Entorno de pruebas de transporte perimetral
Figura 2 Entorno de pruebas de transporte perimetral
Durante la suscripción del servidor de transporte perimetral y la configuración de los conectores asociados, Microsoft IT quita todos los conectores predeterminados y avanza con la creación de cuatro conectores para comunicarse eficientemente con los diferentes tipos de hosts SMTP (protocolo simple de transferencia de correo) y con los servidores concentradores de transporte internos. El primer conector de envío es un conector de Internet general para todos los destinos que no coinciden con definiciones específicas del espacio de direcciones.
El segundo conector de envío es un conector de Internet con definiciones detalladas del espacio de direcciones para destinos conocidos que no son compatibles con SMTP ampliado (dominios HELO). Mediante la configuración del parámetro ForceHELO para este conector en $true, Microsoft IT evita una secuencia innecesaria de EHLO, respuesta de error 500, HELO cuando se establecen conexiones SMTP.
El tercer conector de envío es un conector de Internet con definiciones detalladas del espacio de direcciones para dominios de asociados y otros dominios remotos compatibles con TLS para comunicarse de forma segura sobre conexiones cifradas (dominios TLS). El parámetro RequireTLS de este conector se establece en $true.
El cuarto conector de envío es un conector entrante para transferir los mensajes recibidos de Internet a los servidores concentradores de transporte en el entorno corporativo. Una vez más, para obtener información más detallada respecto a la configuración del servidor de transporte perimetral, consulte las notas del producto IT Showcase que se mencionan en la barra lateral "Recursos de Exchange".
Para aplicar una topología de conector del estilo de Microsoft IT al laboratorio de pruebas, usé un procedimiento basado en scripts creado por Omesh para uso interno de Microsoft IT. Por razones de seguridad, lo cambié y acorté drásticamente los comandos individuales, pero la topología del conector resultante todavía corresponde a la topología de Microsoft IT. Aquí tiene los pasos:
  1. En el servidor Exchange de funciones múltiples (HUB-MBX-01) y el servidor de transporte perimetral (EDGE01), quitar los conectores predeterminados.
  2. En HUB-MBX-01, crear un nuevo conector de recepción mediante la ejecución del script HUB-MBX-01_recv_connector.ps1 que se puede encontrar en la descarga de este artículo.
  3. En EDGE01, crear dos nuevos conectores de recepción para la conectividad de mensajería interna y externa mediante la ejecución del script EDGE01_recv_connector.ps1.
  4. En EDGE01, crear un archivo de suscripción mediante la ejecución de este comando:
    New-EdgeSubscription -FileName
    "c:\subscriptionfile.xml"
Copiar el archivo de suscripción resultante a la carpeta raíz del servidor concentrador de transporte (c:\subscriptionfile.xml).
5. En HUB-MBX-01, asegurarse de que la ruta de acceso al archivo de suscripción es C:\subscriptionfile xml y, a continuación, ejecutar el script HUB-MBX-01_complete_subscription.ps1. Este script importa el archivo de suscripción para la sincronización perimetral sin la creación automática de un conector de envío, crea los conectores de envío para conectividad con Internet e interna, y replica la configuración resultante al servidor concentrador de transporte mediante la sincronización perimetral.
6. Compruebe la configuración mediante el envío de mensajes de prueba como Contoso.User@contoso.com y Fabrikam.User@fabrikam.com desde el host de Internet a Administrator@adventureworks.com y conteste a los mensajes recibidos para garantizar el funcionamiento de la transferencia de mensajes entrantes y salientes.
Sugiero que abra los archivos de script individuales en el Bloc de notas y analice los cmdlets y parámetros que usan estos scripts para realizar la configuración. La información detallada acerca de estos cmdlets y parámetros está disponible en línea en la documentación de producto de Exchange Server 2007.

Arquitectura de transporte perimetral
Ahora nos conectaremos con los agentes de transporte perimetral, que esperaban que alguien dijera HELO o EHLO desde el momento en que instalé la función de servidor de transporte perimetral. Si ejecuta el cmdlet Get-TransportAgent en el servidor de transporte perimetral, debe ver las 11 entradas que se enumeran en la figura 3. Todos los agentes están habilitados de forma predeterminada para ofrecer protección de mensajería con la configuración apropiada.
Figure 3 Agentes de transporte (Close Figure 3)

Agentes de recepción SMTP
Agente de filtro de conexión
Agente de reescritura de direcciones de la bandeja de entrada
Agente de regla perimetral
Agente de filtrado de contenido
Agente de identificación de remitente
Agente de filtro de remitente
Agente de filtro de destinatario
Agente de análisis de protocolos
Agente de filtrado de datos adjuntos
Agentes de enrutamiento
Agente de reescritura de direcciones de la bandeja de salida
Agente de enrutamiento FSE
El cmdlet Get-TransportAgent y la figura 3 enumeran los agentes por su orden de prioridad, aunque éste no es el orden en que los agentes realizan su trabajo. El orden del trabajo depende principalmente de la secuencia de eventos de recepción y eventos de enrutamiento SMTP para la que los agentes están registrados. Para ver cómo se relacionan los agentes y eventos, observe el diagrama que se muestra en la figura 4, que ilustra cómo se integran los agentes de transporte en la arquitectura de transporte perimetral.
Figura 4 Agentes de transporte dentro de la arquitectura de transporte perimetral.
Figura 4 Agentes de transporte dentro de la arquitectura de transporte perimetral.
Durante el procesamiento de los mensajes, los eventos de transporte ocurren en varias etapas intermedias para invocar código adicional para el filtrado de correo no deseado, realizar análisis de virus y otras tareas. En este diseño escasamente acoplado y extensible, el proceso de transporte perimetral (EdgeTransport.exe) asume la función de origen de eventos. Los controladores de eventos, en otras palabras los agentes de transporte, son objetos delegados administrados que se basan en Microsoft® .NET Framework 2.0, registrados con el origen de eventos para recibir notificaciones de devolución de llamada.
La figura 5 muestra los registros de evento de todos los agentes instalados en un servidor de transporte perimetral con Forefront Security. Es posible que estos registros sean algo difíciles de clasificar debido a la gran cantidad de registros de agente, pero no desespere. Si en un servidor de transporte perimetral ejecuta el comando Get-TransportPipeline | Format-List, puede analizar los registros de cada evento de transporte individual de manera más conveniente. Asegúrese de que el servicio de transporte de Microsoft Exchange (MSExchangeTransport.exe) se encuentra en ejecución y que ha enviado por lo menos un mensaje a través del servidor de transporte perimetral desde el último reinicio del servicio. Como revela la salida, se pueden registrar múltiples agentes para el mismo tipo de evento y se pueden registrar agentes individuales para múltiples eventos. Los registros de eventos sólo dependen de los requisitos de procesamiento del agente correspondiente.
Figura 5 Registros de evento de agentes de transporte
Figura 5 Registros de evento de agentes de transporte
Uno de los eventos más importantes es el evento de enrutamiento OnSubmittedMessage, que se activa cuando un mensaje alcanza la cola de envío. Todos los mensajes deben pasar por esta cola a través de SMTP, ya sea que lleguen a través de SMTP, el sistema de archivos o por cualquier otro mecanismo. El categorizador es un componente principal de la arquitectura de transporte de Exchange Server, responsable de la resolución de destinatarios, bifurcación y enrutamiento de mensajes y generación de notificación del estado de entrega (DSN). El evento OnSubmittedMessage es por lo tanto una elección de registro perfecta para los agentes que deben procesar todos los mensajes recibidos. El agente de enrutamiento FSE es un componente de Forefront Security registrado para el evento OnSubmittedMessage para pasar todos los mensajes recibidos a los motores de análisis de virus. Debido a que el agente de enrutamiento FSE se registra para el evento OnSubmittedMessage, ningún mensaje puede saltarse la solución antivirus.
Así que ¿por qué simplemente todos los agentes no se registran para el evento OnSubmittedMessage y consideran realizado el trabajo? Porque desea bloquear los mensajes no deseados lo antes posible, antes de que su servidor confirme una entrega correcta. De lo contrario, sus servidores quizás tengan que procesar 90 millones de mensajes no deseados durante un ataque de correo no deseado o un virus, posiblemente tengan que generar 90 millones de informes de no entrega (NDR), lo cual puede suponer, a su vez, una amenaza grave para usuarios inocentes. Los ataques de correo no deseado y virus casi siempre usan información falsificada del remitente. El envío de millones de NDR a destinatarios que no crearon los mensajes originales no sólo representa un derroche de sus recursos y de los recursos de las organizaciones objetivo, también es una oportunidad para que usuarios malintencionados inunden el sistema con correo y realicen ataques DDoS. Por su propia protección y la de otros, es importante detener a los remitentes malintencionados en sus rastros.
Para bloquear de forma eficaz un mensaje, un agente de transporte debe interrumpir la conversación SMTP con el host remoto antes de que su servidor confirme la recepción de los datos con un código de estado 250 OK. Según el principio de almacenar y reenviar de SMTP, su servidor puede descartar sin riesgos cualquier dato recibido sin generar los NDR si no se ha confirmado la entrega del mensaje. Los agentes de recepción SMTP lo pueden realizar. Interactúan con la sesión SMTP porque la canalización de transporte invoca a estos agentes en función de eventos de recepción SMTP cuando el host remoto se conecta al servidor, establece una sesión SMTP, transmite los verbos SMTP, envía los mensajes y finaliza la conexión. Los eventos de recepción SMTP relacionados con cada paso se describen en la figura 6. Debido a la capacidad de rechazar los mensajes antes de la entrega y desconectar los hosts SMTP remotos, todos los agentes contra correo no deseado de Exchange Server 2007 se implementan como agentes de recepción SMTP.
Figure 6 Eventos de sesión SMTP (Close Figure 6)

Acción | Eventos relacionados
Conexión al servidor | OnConnectEvent
Establecimiento de sesión SMTP | OnHeloCommand, OnEhloCommand, OnAuthCommand, OnEndOfAuthentication
Transmisión de verbos SMTP | OnMailCommand, OnRcptCommand, OnDataCommand, OnNoopCommand, OnHelpCommand
Envío de mensajes | OnEndOfHeaders, OnEndOfData
Rechazo de comando o mensaje | OnReject
Restablecimiento de la conexión | OnRsetCommand
Finalizar la conexión | OnDisconnect
Es importante reconocer la diferencia entre agentes de recepción y agentes de enrutamiento SMTP con respecto a su contexto de procesamiento. Mientras que los agentes de enrutamiento tienen acceso completo a las propiedades del mensaje, los agentes de recepción SMTP son más sensibles al contexto porque interactúan con la sesión SMTP. Por ejemplo, un filtro de correo no deseado no puede actuar sobre las propiedades del mensaje hasta que el host remoto haya transferido el mensaje. Por lo tanto, es importante registrar al agente para el evento de recepción SMTP correcto. Consulte la barra lateral "Desarrollo de agentes de transporte" para obtener mayores detalles.

Recursos de Exchange
  • Transporte perimetral y protección de mensajería en Microsoft Exchange Server 2007 (Notas técnicas de producto de Microsoft IT Showcase)
  • Windows PowerShell Script Center
  • Exchange Server 2007 TechCenter
  • Blog del equipo de Microsoft Exchange "You Had Me From EHLO"

No deje de leernos
Tomemos un descanso antes de entrar con mayor detalle en la arquitectura de transporte y escenarios de prueba. He incluido mucha información, que abarca desde una implementación de servidores de transporte perimetral del estilo de Microsoft IT hasta los eventos internos que se activan en la canalización de transporte durante el procesamiento del mensaje. En la siguiente entrega de esta serie de dos partes, continuaré el análisis del comportamiento de los agentes de transporte perimetral en algunos escenarios de prueba interesantes.
Mientras tanto, le recomiendo descargar la versión de prueba de 90 días de Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) y seguir las explicaciones de Steve para compilar e instalar los agentes de ejemplo en su entorno de pruebas. Incluso si no es desarrollador, encontrará que es muy sencillo realizar estas tareas. No me sorprendería ver que un número creciente de aplicaciones de negocios dependa de agentes personalizados, dado lo útil que resulta desarrollar estos componentes en Exchange Server 2007 con Visual Studio 2005.

Kay Unkrothes una emprendedora que ha trabajado como ingeniera de soporte, desarrolladora de sistemas, consultora, instructora y autora especializada en tecnologías de servidores de Microsoft durante más de 15 años. Kay también es cofundadora y presidente de Biblioso Corporation, una compañía que se especializa en servicios administrados de documentación y localización.


 SQL Server: Optimizaci&#243;n del rendimiento de la CPU de SQL Server
SQL Server Zach Nichter

Optimización del rendimiento de la CPU de SQL Server
Resumen:
  • Solución de problemas de rendimiento de bases de datos
  • Revisión de causas relacionadas con el hardware
  • Uso de PerfMon para hacer un seguimiento de los cuellos de botella en las bases de datos
  • Evaluación del rendimiento de las consultas

La solución de problemas de rendimiento en un sistema de base de datos puede ser una tarea muy dura. Es importante saber dónde hay que buscar, pero todavía más crucial es saber por qué el sistema reacciona como reacciona ante una determinada solicitud. Hay varios factores que pueden afectar al uso de la CPU
en un servidor de base de datos: La compilación y recompilación de instrucciones SQL, la ausencia de índices, las operaciones con varios subprocesos, los cuellos de botella de disco, los cuellos de botella de memoria, el mantenimiento rutinario y la actividad de extracción, transformación y carga (ETL), entre otros. El uso de la CPU en sí no es incorrecto: la CPU sirve precisamente para trabajar. La clave para un buen uso de la CPU es comprobar que éste procese lo que debe, en lugar de malgastar ciclos en código mal optimizado o hardware lento.

Dos caminos que llevan al mismo lugar
Visto desde un nivel alto, existen dos vías para identificar problemas de rendimiento de CPU. La primera es revisar el rendimiento del hardware del sistema, un ejercicio que ayuda a determinar dónde buscar cuando se sigue la segunda vía: revisar la eficacia de las consultas del servidor. Esta segunda vía suele ser más eficaz para identificar problemas de rendimiento de SQL Server™. No obstante, a menos que sepa exactamente dónde se encuentran sus problemas de rendimiento de consultas, siempre debe empezar con una evaluación del rendimiento del sistema. Al final, acabará usando las dos vías. Vamos a asentar algunas bases para poder examinar ambas vías.

Asentar las bases
Hyper-threading
El hyper-threading es un tema que vale la pena examinar a fondo, dado que afecta a SQL Server. El hyper-threading presenta ante el sistema operativo dos procesadores lógicos por cada procesador físico. En esencia, el hyper-threading libera tiempo de los procesadores físicos para optimizar el uso de cada uno de ellos. El sitio web de Intel (intel.com/technology/platform-technology/hyper-threading/index.htm) ofrece una descripción más completa de cómo funciona el hyper-threading.
En sistemas SQL Server, el sistema de administración de bases de datos transfiere su propios subprocesos y colas (que son extraordinariamente eficaces) al sistema operativo, por lo que el hyper-threading sólo sirve para sobrecargar las CPU físicas en sistemas con un uso ya alto de la CPU. Cuando SQL Server pone en cola varias solicitudes para trabajar con varios programadores, el sistema operativo tiene que intercambiar el contexto de los subprocesos una y otra vez en los procesadores físicos para satisfacer las solicitudes que se realizan, incluso si los dos procesadores lógicos se encuentran en el mismo procesador físico. Si observa un valor de cambios de contexto por segundo mayor que 5.000 por procesador físico, debería plantearse desactivar el hyper-threading en su sistema y volver a analizar el rendimiento.
En casos excepcionales, las aplicaciones que experimentan un alto uso de CPU en SQL Server pueden aprovechar eficazmente el hyper-threading. Pruebe siempre las aplicaciones contra SQL Server con el hyper-threading activado y desactivado antes de implementar los cambios en sus sistemas de producción.

Un procesador avanzado de doble núcleo obtendrá fácilmente un rendimiento superior al de la RAM en un equipo, y éste funcionará más rápidamente que un dispositivo de almacenamiento conectado. Una buena CPU puede gestionar aproximadamente un rendimiento seis veces superior al de una memoria actual de altas prestaciones DDR2, y dos veces superior al de una memoria de altas prestaciones DDR3. El rendimiento normal de una memoria es 10 veces superior al de las unidades de canal de fibra más rápidas. En cambio, los discos duros sólo pueden realizar un número limitado de IOPS (operaciones de entrada/salida por segundo), un valor que está determinado enteramente por el número de búsquedas por segundo que puede realizar una unidad. Para ser justos, no es normal que se use una única unidad de almacenamiento para responder a todas las necesidades de almacenamiento en sistemas de bases de datos corporativos. La mayoría de las instalaciones actuales usan redes de área de almacenamiento (SAN) en servidores de base de datos de empresa o grupos RAID más grandes, que pueden evitar o minimizar problemas relacionados con el procesador de E/S del disco. Lo más importante que debe recordar es que, independientemente de cuál sea la configuración, los cuellos de botella de disco y de memoria pueden afectar al rendimiento de sus procesadores.
A causa de las diferencias de velocidad de E/S, recuperar datos del disco cuesta mucho más que recuperar datos de la memoria. Una página de datos de SQL Server ocupa 8 KB. Una extensión de SQL Server está formada por ocho páginas de 8 KB, que da un total de 64 KB. Esto es importante porque cuando SQL Server solicita una página de datos concreta del disco, no se recupera sólo la página de datos, sino toda la extensión en la que reside la página de datos. Existen algunas razones por las que este sistema es más rentable para SQL Server, pero aquí no entraremos en detalles. Publicar una página de datos que ya está copiada en caché desde el grupo de búferes en rendimiento máximo debería tardar menos de medio milisegundo; recuperar una única extensión del disco debería tardar entre 2 y 4 milisegundos en un entorno óptimo. Normalmente se espera que una lectura del subsistema de un disco en buen estado tarde entre 4 y 10 milisegundos. Recuperar una página de datos de la memoria suele ser entre 4 y 20 veces más rápido que publicar una página de datos del disco.
Cuando SQL Server solicita una página de datos, comprueba la memoria caché del búfer de la memoria antes de buscar la página de datos en el subsistema del disco. Si la página de datos se encuentra en el grupo de búferes, el procesador recuperará los datos y, a continuación, realizará el trabajo necesario. Este tipo de errores se denominan errores de software de página. Los errores de software de página son ideales para SQL Server porque los datos que se recuperan como parte de una solicitud deben estar en la memoria caché del búfer antes de poder usarlos. Una página de datos que no se encuentra en la memoria caché del búfer debe recuperarse desde el subsistema de disco del servidor. Cuando el sistema operativo tiene que recuperar la página de datos desde el disco, se habla de un error de disco duro de página.
Al correlacionar el rendimiento de la memoria, el rendimiento del disco y el rendimiento de la CPU, un denominador común ayuda a obtener una visión general de todo: el rendimiento. Para que pueda entenderse, rendimiento se puede definir como la medida de la cantidad de datos que se pueden especificar en una canalización con capacidad limitada.

Vía 1: Rendimiento del sistema
Existen pocos métodos para determinar si un servidor tiene un cuello de botella de CPU, y no hay muchas causas posibles de un uso alto de la CPU. Es posible hacer un seguimiento de algunos de estos problemas mediante PerfMon o una herramienta de supervisión del sistema equivalente, mientras que el seguimiento de los demás se puede llevar a cabo mediante el Analizador SQL o herramientas equivalentes. Otro método es usar comandos de SQL a través del Analizador de consultas o SQL Server Management Studio (SSMS).
La filosofía que sigo para evaluar el rendimiento del sistema consiste en empezar con una visión general y, después, ir profundizando. Obviamente, no se pueden analizar las áreas conflictivas hasta haberlas identificado. Después de evaluar el uso general de la CPU con una herramienta como PerfMon, puede usarla para examinar un par de contadores de rendimiento sencillos y fáciles de comprender.
Uno de los contadores de rendimiento más sencillos es el de porcentaje de tiempo de procesador; cuando está en PerfMon, se resalta al abrir la ventana Agregar contadores. El porcentaje de tiempo de procesador es el tiempo que los procesadores están ocupados realizando tareas. El uso de procesadores se considera alto cuando este valor es del 80 por ciento o más durante la mayor parte del tiempo de máximo funcionamiento. Lo normal y previsible es que existen picos de hasta el 100 por cien algunas veces, incluso cuando el servidor no esté funcionando al 80 por ciento.
Otro contador que se debería considerar es Longitud de la cola del procesador, que se encuentra bajo el objeto de rendimiento del sistema en PerfMon. Longitud de la cola del procesador muestra cuántos subprocesos esperan para realizar tareas en la CPU. SQL Server administra su trabajo mediante programadores en el motor de la base de datos, donde pone en cola y procesa sus propias solicitudes. Dado que SQL Server administra su propio trabajo, usará un único subproceso de CPU para cada procesador lógico. Esto significa que debe haber un número mínimo de conversaciones en espera en la cola del procesador para que se puedan realizar tareas en un sistema dedicado a SQL Server. Normalmente no debería existir un número cinco veces superior al del número de procesadores físicos en un SQL Server dedicado, pero consideramos que hay un problema si dicho número es del doble. En servidores donde el sistema de administración de bases de datos comparte un sistema con otras aplicaciones, es conveniente revisar esto junto con el rendimiento de los contadores de porcentaje de tiempo de procesador y cambios de contexto por segundo (a continuación, se describirán los cambios de contexto) para determinar si sus otras aplicaciones o el sistema de administración de bases de datos debe trasladarse a un servidor diferente.
Cuando veo un procesador en cola junto con un alto uso de CPU, analizo los contadores de compilaciones y de recompilaciones por segundo que hay en SQL Server: Objeto de rendimiento Estadísticas de SQL (vea la figura 1). La compilación y la recompilación de planes de consulta contribuyen a un mayor uso de la CPU del sistema. Deberían existir valores cercanos a cero para las recompilaciones, pero vigile la tendencia de sus sistemas para determinar cómo se comporta normalmente su servidor y así como el número normal de compilaciones. Las recompilaciones no siempre pueden evitarse, pero las consultas y los procedimientos almacenados pueden optimizarse para minimizar las recompilaciones y volver a usar los planes de consulta. Compare estos valores con las instrucciones de SQL que llegan al sistema mediante las solicitudes de lote por segundo que también se encuentran en SQL Server: objeto de rendimiento Estadísticas de SQL. Si las compilaciones y recompilaciones por segundo suponen un porcentaje alto de las solicitudes de lote que llegan al sistema, significa que esta es un área que debe revisarse. En algunas situaciones, es posible que los desarrolladores de SQL no entiendan cómo ni por qué su código puede contribuir a agravar este tipo de problemas de recursos del sistema. En otro lugar de este artículo se ofrecerán algunas referencias para ayudarle a minimizar este tipo de actividad.
Figura 1 Selección de los contadores que supervisar
Figura 1 Selección de los contadores que supervisar
Desde PerfMon, compruebe el contador de rendimiento llamado Cambios de contexto por segundo (vea la figura 2). Este contador indica cuántas veces hay que sacar los subprocesos de los programadores del sistema operativo (no de los programadores de SQL) para trabajar para otros subprocesos que están en espera. Los cambios de contexto suelen ser más frecuentes en los sistemas de base de datos compartidos con otras aplicaciones como IIS u otros componentes del servidor de aplicaciones de proveedor. El umbral que uso para Cambios de contexto por segundo es unas 5.000 veces superior al número de procesadores del servidor. Este valor puede ser mayor en sistemas que tienen activados los subprocesos y un uso de la CPU entre moderado y alto. Cuando el uso de la CPU y los cambios de contexto superan periódicamente sus umbrales, significa que existe un cuello de botella de la CPU. Si esto ocurre frecuentemente, debe empezar a planear la compra de más CPU, o de CPU más rápidas si su sistema está obsoleto. Para obtener más información, consulte la barra lateral "Hyper-threading".
Figure 2 Contadores de rendimiento que deben tenerse en cuenta (Close Figure 2)

Contador de rendimiento | Objeto de contador | Umbral | Notas
% de tiempo de procesador | Procesador | > 80% | Las posibles causas pueden ser la demanda de memoria, una baja reutilización del plan de consulta o la existencia de consultas no optimizadas.
Cambios de contexto por segundo | Sistema | > 5.000 x procesadores | Las posibles causas pueden ser otras aplicaciones del servidor, la ejecución de más de una copia de SQL Server en el mismo servidor o que hyper-threading esté activado.
Duración de la cola de procesador | Sistema | > 5 x procesadores | Las posibles causas pueden ser otras aplicaciones del servidor, un alto volumen de compilaciones o recompilaciones o la ejecución de más de una copia de SQL Server en el mismo servidor.
Compilaciones por segundo | SQLServer: Estadísticas de SQL | Tendencia | Compare con las solicitudes de lote por segundo
Recompilaciones por segundo. | SQLServer: Estadísticas de SQL | Tendencia | Compare con las solicitudes de lote por segundo
Solicitudes de lote por segundo | SQLServer: Estadísticas de SQL | Tendencia | Compare con la compilación y las recompilaciones por segundo.
Duración prevista de la página | SQLServer: Administrador de búfer | < 300 | Probabilidad de demanda de memoria.
Escrituras diferidas por segundo | SQLServer: Administrador de búfer | Tendencia | Probabilidad de grandes vaciados de caché de datos o demanda de memoria.
Controles por segundo | SQLServer: Administrador de búfer | Tendencia | Evaluar los controles contra PLE y Escrituras diferidas por segundo
Proporción de aciertos de caché: Planes SQL | SQLServer: Planear caché | < 70% | Indica una baja reutilización del plan.
Proporción de aciertos de caché del búfer | SQLServer: Administrador de búfer | < 97% | Probabilidad de demanda de memoria.
El escritor diferido de SQL Server (que es el nombre que recibe en SQL Server 2000) o el monitor de recursos (como se denomina en SQL Server 2005) es otra área que supervisar cuando el uso de CPU es alto. El vaciado de búfer y de las memorias caché de procedimientos pueden contribuir a consumir tiempo de CPU mediante el subproceso de recursos llamado Monitor de recursos. El Monitor de recursos es un proceso de SQL Server que determina qué páginas se conservarán y qué páginas necesitan ser vaciadas desde grupo de búferes al disco. A cada página del búfer y de las memorias caché de procedimiento se les asigna en principio un costo que representa los recursos que se consumen cuando se coloca dicha página en caché. Este valor de costo disminuye cada vez que el Monitor de recursos lo examina. Cuando una solicitud requiere espacio caché, las páginas se vacían de la memoria a partir del costo asociado a cada página; las páginas con los valores más bajos se vacían primero. Se puede seguir la actividad del Monitor de recursos a través del contador de rendimiento de escrituras diferidas por segundo bajo SQL Server: objeto Administrador de búfer dentro de PerfMon. Debería realizar un seguimiento de la tendencia que sigue este valor para determinar qué umbral es el normal en su sistema. Generalmente se revisa este contador junto con los contadores de duración prevista de la página y de controles por segundo para determinar si existe demanda de memoria.
El contador de duración prevista de la página (PLE) ayuda a determinar la demanda de la memoria. El contador de PLE muestra cuánto tiempo permanece una página de datos en la memoria caché del búfer. 300 segundos es el umbral aceptado por el sector para este contador. Un promedio inferior a 300 segundos durante un período extendido le indica que las páginas de datos se están vaciando de la memoria con demasiada frecuencia. Cuando esto sucede, el Monitor de recursos debe trabajar más intensamente, lo que a su vez exige más actividad en los procesadores. El contador de PLE debe evaluarse junto con el contador de páginas de control por segundo. Cuando se produce un control en el sistema, las páginas de datos erróneos de la memoria caché del búfer se vacían en el disco, y causa que disminuya el valor de PLE. El proceso del Monitor de recursos es el mecanismo que vacía estas páginas en el disco, así que durante estos controles es normal que incremente el valor de escrituras diferidas por segundo. Si su valor de PLE aumenta inmediatamente una vez completado un control, puede hacer caso omiso de síntoma temporal. Por otro lado, si encuentra que está habitualmente por debajo del umbral de PLE, es bastante probable que esa memoria adicional alivie sus problemas y que al mismo tiempo devuelva algunos recursos a la CPU. Todos estos contadores se encuentran en SQL Server: objeto de rendimiento Administrador de búfer.

Vía 2: Rendimiento de las consultas
Seguimiento de SP
Al realizar el seguimiento de su aplicación SQL Server, vale la pena familiarizarse con los procedimientos almacenados que se usan para el seguimiento. Si usa una interfaz gráfica (SQL Server Profiler) para realizar el seguimiento, puede aumentar la carga del sistema entre un 15 y un 25 por ciento. Si puede usar procedimientos almacenados en su seguimiento, este valor puede reducirse a la mitad.
Cuando sé que el sistema tiene un cuello de botella en algún lugar y deseo determinar qué instrucciones SQL actuales están probando problemas en el servidor, ejecuto la consulta siguiente. Esta consulta me permite ver las distintas instrucciones y los recursos que están usando actualmente, así como instrucciones que necesitan ser revisadas para mejorar el rendimiento. Para obtener más información acerca de los seguimientos de SQL, consulte msdn2.microsoft.com/ms191006.aspx.
SELECT
    substring(text,qs.statement_start_offset/2
        ,(CASE
            WHEN qs.statement_end_offset = -1 THEN len(convert(nvarchar(max), text)) * 2
            ELSE qs.statement_end_offset
        END - qs.statement_start_offset)/2)
    ,qs.plan_generation_num as recompiles
    ,qs.execution_count as execution_count
    ,qs.total_elapsed_time - qs.total_worker_time as total_wait_time
    ,qs.total_worker_time as cpu_time
    ,qs.total_logical_reads as reads
    ,qs.total_logical_writes as writes
FROM sys.dm_exec_query_stats qs
    CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
    LEFT JOIN sys.dm_exec_requests r
        ON qs.sql_handle = r.sql_handle
ORDER BY 3 DESC

Los planes de consulta se evalúan, se optimizan, se compilan y se ubican en la memoria caché de procedimiento cuando se envía una nueva consulta a SQL Server. Cada vez que se envía una consulta al servidor, la memoria caché de procedimiento se revisa para intentar conciliarla con un plan de consulta que coincida con una solicitud. Si no se encuentra ninguna, SQL Server crea un nuevo plan; ésta es una operación que puede llegar a suponer un gran costo.
Algunas consideraciones para la optimización de CPU de T-SQL:
  • Reutilización del plan de consulta
  • Reducción de compilaciones y recompilaciones
  • Clasificación de operaciones
  • Uniones inapropiadas
  • Ausencia de índices
  • Análisis de tabla/índice
  • Uso de funciones en cláusulas SELECT y WHERE
  • Operaciones con varios subprocesos
Vamos a examinar todo esto con un poco de perspectiva. Normalmente, SQL Server obtiene datos tanto de la memoria como del disco y habitualmente trabaja con más de una página de datos. Normalmente hay varias partes de una aplicación que trabajan en un registro que ejecutan varias consultas más pequeñas o unen tablas para proporcionar una vista completa de los datos pertinentes. En entornos OLAP, es posible que las aplicaciones trabajen con millones de filas de una o dos tablas para poder consolidar, acumular y resumir los datos para un informe regional de ventas. En este tipo de situaciones, la recuperación de datos se puede medir en milisegundos si los datos están en la memoria, pero estos milisegundos pueden convertirse en minutos cuando se recuperan los mismos datos desde disco en lugar de desde la RAM.
El primer ejemplo es una situación con un alto volumen de transacciones, y la reutilización del plan depende de la aplicación. Una baja reutilización del plan origina un número elevado de compilaciones de instrucciones de SQL, que a su vez originan un volumen elevado de procesamiento de CPU. En el segundo ejemplo, el uso elevado de recursos del sistema puede hacer que la CPU del sistema esté excesivamente activa, ya que hay que vaciar constantemente los datos existentes de la memoria caché del búfer para hacer sitio para el gran volumen de nuevas páginas de datos.
Imagine un sistema altamente transaccional, donde una instrucción SQL como la que se muestra a continuación se ejecuta 2.000 veces en un período de 15 minutos para recuperar información sobre el embalaje de envío. Sin no se reutiliza el plan de consulta, en teoría podría haber un tiempo individual de ejecución de unos 450 ms por instrucción. Si se usa el mismo plan de consulta después de la ejecución inicial, cada consulta posterior podría ejecutarse probablemente en unos 2 ms, con o que el tiempo total de ejecución podría reducirse a unos 5 segundos.
USE SHIPPING_DIST01;
SELECT
    Container_ID
    ,Carton_ID
    ,Product_ID
    ,ProductCount
    ,ModifiedDate
FROM Container.Carton
WHERE Carton_ID = 982350144;
La reutilización del plan de consulta es crucial para un rendimiento óptimo en sistemas con muchas transacciones, y normalmente se consigue mediante la parametrización de las consultas o los procedimientos almacenados. A continuación, se muestran algunos recursos excelentes para obtener información acerca de la reutilización del plan de consulta:
  • Problemas de compilación y de recompilación de lotes y de almacenamiento en caché de planes en SQL Server 2005 (microsoft.com/technet/prodtechnol/sql/2005/recomp.mspx)
  • Optimización de procedimientos almacenados de SQL Server para evitar recompilaciones (sql-server-performance.com/rd_optimizing_sp_recompiles.asp)
  • Recompilación de consultas en SQL Server 2000 (msdn2.microsoft.com/aa902682.aspx)
Un lugar útil con valiosa información es el de las vistas dinámicas de administración de SQL Server 2005 (DMV). Cuando el uso de la CPU es elevado, hay un par de DMV que suelo usar para determinar si la CPU se está usando apropiadamente.
Uno de dichos DMV es sys.dm_os_wait_stats, que se usa para proporcionar a los DBA una forma de determinar cada uno de los tipos de recurso o funciones que usa SQL Server y cronometrar el tiempo que el sistema permanece en espera a causa de dicho recurso. Los contadores de este DMV son acumulativos. Esto significa que para saber qué recursos podrían estar afectando a las distintas áreas del sistema, primero tendrá que enviar un comando DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) para restablecer todos los contadores después de revisar los datos de los problemas más importantes. El DMV sys.dm_os_wait_stats es el equivalente del comando DBCC SQLPERF(WAITSTATS) de comprobación de coherencia de base de datos en SQL Server 2000. Puede encontrar más información acerca de los distintos tipos de espera en Libros en línea de SQL Server en msdn2.microsoft.com/ ms179984.aspx.
Es importante saber que las esperas son normales en un sistema, incluso cuando el funcionamiento es óptimo. Debe detectar si las esperas están causadas por un cuello de botella de CPU. Las esperas de señal deberían reducirse al mínimo en relación con el tiempo de espera global. El tiempo que un recurso concreto espera un recurso de procesador puede determinarse fácilmente restando el tiempo de espera de señal del tiempo de espera total; este valor no debería ser mayor que el 20 por ciento del tiempo de espera total.
El DMV sys.dm_exec_sessions muestra todas las sesiones abiertas en el SQL Server. Este DMV proporciona una vista de alto nivel del rendimiento de cada sesión y todo el trabajo que ha realizado cada sesión desde el principio. Esto incluye la cantidad total de tiempo que ha estado esperando la sesión, el uso total de cpu, el uso de memoria y un recuento de lecturas y escrituras. El DMV también le proporcionará la entrada, el tiempo de entrada, el equipo host y la última vez que la sesión hizo una solicitud de SQL Server.
Si usa el DMV sys.dm_exec_sessions, podrá determinar sólo las sesiones activas, así que si detecta un uso alto de CPU, aquí es donde debe empezar a buscar. Revise primero las sesiones que tienen un alto recuento de CPU. Determine la aplicación y el usuario que ha estado realizando el trabajo y, a continuación, empiece a analizar más detalladamente. Asociar el DMV sys.dm_exec_sessions al sys.dm_exec_requests puede proporcionarle mucha información que está disponible a través de los procedimientos almacenados sp_who y sp_who2. Si combina estos datos con la función de administración dinámica (DMF) sys.exec_sql_text mediante la columna sql_handle, puede obtener la consulta que está actualmente en ejecución de la sesión. El fragmento de la figura 3 muestra cómo combinar estos datos para poder determinar qué está ocurriendo en un servidor en cada momento.
Figure 3 Determinación de la actividad del servidor (Close Figure 3)
SELECT es.session_id
    ,es.program_name
    ,es.login_name
    ,es.nt_user_name
    ,es.login_time
    ,es.host_name
    ,es.cpu_time
    ,es.total_scheduled_time
    ,es.total_elapsed_time
    ,es.memory_usage
    ,es.logical_reads
    ,es.reads
    ,es.writes
    ,st.text
FROM sys.dm_exec_sessions es
    LEFT JOIN sys.dm_exec_connections ec
        ON es.session_id = ec.session_id
    LEFT JOIN sys.dm_exec_requests er
        ON es.session_id = er.session_id
    OUTER APPLY sys.dm_exec_sql_text (er.sql_handle) st
WHERE es.session_id > 50    -- < 50 system sessions
ORDER BY es.cpu_time DESC
Considero que esta instrucción es útil para determinar en qué aplicaciones centrarse. Al comparar la CPU, la memoria, las lecturas, las escrituras y las lecturas lógicas para todas las sesiones de una aplicación, y determinar que el recurso de CPU es mucho mayor que otros recursos usados, en primer lugar, me centro en dichas instrucciones SQL.
Para realizar un seguimiento de instrucciones SQL históricamente para una aplicación, uso rastros de SQL Server. Puede obtener acceso a ellos a través de la herramienta Analizador de SQL o a través de los procedimientos almacenados de rastreo del sistema para poder evaluar qué está ocurriendo. Vea la barra lateral sobre seguimiento de SP para obtener más información acerca de este tema. Debe revisar el analizador en el caso de las instrucciones con un uso alto de CPU, así como advertencias de hash y de clasificación, errores de acceso a caché y otros marcadores rojos. Esto puede ayudarle a estrechar la búsqueda de instrucciones SQL específicas o de un período de tiempo concreto que ha causado un alto uso de recursos. El analizador es capaz de realizar el seguimiento de texto de instrucciones SQL, planes de ejecución, uso de CPU, uso de la memoria, lecturas lógicas, las escrituras, almacenamiento en caché de planes de consulta, recompilaciones, expulsión de planes de consulta de la memoria caché, errores de acceso a caché, análisis de tabla y de índice, estadísticas inexistentes y muchos otros eventos.
Una vez recopilados los datos de los procedimientos almacenados sp_trace o del Analizador de SQL Server, generalmente se usa una base de datos, que se rellena con datos de seguimiento después del suceso o bien mediante la definición del seguimiento de modo que escriba en la base de datos. Puede rellenar la base de datos después del suceso usando la función del sistema de SQL Server llamada fn_trace_getinfo. La ventaja de este método es que puede consultar y clasificar los datos de varias maneras para ver qué instrucciones SQL han usado más CPU o han tenido más lecturas y contar cuántas recompilaciones se han producido, entre otras cosas. Éste es un ejemplo de cómo se usa esta función para cargar una tabla con un archivo de seguimiento del analizador. El valor predeterminado especifica que todos los archivos de seguimiento para ese rastro se cargarán en el orden en el que se han creado:
SELECT * INTO trc_20070401
FROM fn_trace_gettable('S:\Mountpoints\TRC_20070401_1.trc', default);
GO

Conclusión
Como ha podido comprobar, un alto uso de CPU no indica necesariamente que existe un cuello de botella de CPU. Un alto uso de CPU puede estar enmascarando otros cuellos de botella de aplicación o de hardware. Una vez que haya llegado a la conclusión de que el uso de la CPU es alto a pesar de que los otros contadores indiquen un estado correcto, puede empezar a buscar la causa en el sistema y aislar una solución (ya sea comprando más CPU u optimizando el código SQL). Haga lo que haga, no abandone. Con las sugerencias ofrecidas en este artículo, junto con un poco de práctica e investigación, optimizar el uso de la CPU bajo SQL Server es un plan de ejecución viable.

Zach Nichter es un profesional de SQL Server con más de 10 años de experiencia. Ha desempeñado numerosas funciones de soporte técnico de SQL Server, entre las que se incluyen administrador de bases de datos, responsable de equipo, administrador y consultor. Actualmente, Zach trabaja para Levi Strauss &Co. como arquitecto de administración de bases de datos, y se centra en la supervisión, la arquitectura y el rendimiento de SQL Server, entre otras iniciativas estratégicas. Además, Zach es el autor de un video blog que se encuentra en www.sqlcatch.com.


 Nota del editor: Lo mejor a&#250;n est&#225; por llegar
Nota del editor
Lo mejor aún está por llegar
Joshua Hoffman

Aunque no lo crea, comenzaré mi primera Nota del director con una referencia retrospectiva. La verdad, el uso de esta especie de recurso literario al principio de la partida no augura nada bueno, pero sigamos de todas formas.
En el verano de 2005, los dos números inaugurales de TechNet Magazine fueron tuvieron una buena acogida. Era el momento de aumentar la programación de la producción y empezar a entregar con regularidad contenidos técnicos de calidad a los profesionales de TI. Joshua Trupin, nuestro editor ejecutivo, y Stephen Toub (en aquel momento director técnico de nuestra publicación hermana, MSDN Magazine), habían realizado un gran trabajo al reunir a los mejores expertos y planear los primeros números, pero ambos tenían que regresar a sus ocupaciones habituales.
Así que me uní al equipo como nuevo editor técnico, abrumado por la confianza que depositaron en mí y el trabajo que habían realizado hasta ese momento. Después de todo, editar una revista no es una hazaña pequeña. Llegaba con un curso de profesional de TI (fanático puro), y había pasado los cuatro años anteriores en los Servicios de consultoría de Microsoft (MCS). Tenía muy poco (o ningún) conocimiento de cómo funcionaba en realidad la industria editorial. Tenía una lista de lectura kilométrica. Tenía que empezar a planear tres números de inmediato. Tenía nuevos compañeros de equipo, autores, revisores técnicos, socios, y, por supuesto, lectores por conocer. Y, sobre todo, tenía plazos de imprenta inamovibles (que, como podrá imaginar, es un concepto difícil para que un viejo empleado de Microsoft lo comprenda).
Pero el equipo me acogió, me aguantó y mimó, e hizo más de lo que pueda imaginar para ayudarme a realizar mi trabajo. Los autores, revisores, socios y ustedes, nuestros lectores, han hecho que este trabajo sea fascinante, desafiante y profundamente gratificante, y soy un privilegiado por haber hecho tantos amigos nuevos. Miro hacia atrás a los dos últimos años, y me siento orgulloso de lo que este equipo ha conseguido. Pero ahora, como nuevo editor jefe, me siento aún más emocionado por lo que hay delante.
Esta revista existe con la única misión de formar correctamente a los profesionales de TI en los productos y tecnologías de Microsoft (le puedo asegurar que nuestros sueldos dependen de hacer eso, por encima de todo lo demás). Nos ha dicho lo que hicimos bien y, lo que es más importante, lo que necesitamos mejorar. Tomamos muy en serio esos comentarios. En los meses y años venideros continuaremos mejorando, agregaremos nuevos autores y nuevas columnas, mejoraremos nuestra plataforma en línea con nuevos contenidos y nuevos medios, y con suerte posibilitaremos que pueda aprender de la manera que le resulte más apropiada. Sin embargo, nada de todo esto puede tener éxito, sin su constante participación. Comparta con nosotros que funcionó en su caso y qué no. ¿A qué debemos dedicar nuestro tiempo? Usted tiene el control, así que también puede aprovecharlo. Envíe su correo electrónico a tnmag@microsoft.com y haga que se escuche su voz. (Joshua Hoffman)

Mi agradecimiento a los siguientes expertos de Microsoft: Omesh Desai, Raja Ganjikunta, Saleem Hakani, Justin Hall, Michael Murgolo, John Orefice, Jim Truher, Marc Umeno, Jeff Wettlaufer, Buck Woody y Minxiao Zhou.


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

Scripting más eficaz
PowerShell Analyzer
www.pwershellanalyzer.com
Se habla mucho de Windows PowerShell™, y con razón. Si todavía no ha tenido la oportunidad de conocer un poco este lenguaje de scripting de última generación, ahora es el momento de hacerlo. Y aquellos que se hayan actualizado a Microsoft® Exchange 2007 comprobarán rápidamente que el nuevo shell de administración de Exchange está construido sobre Windows PowerShell, así que le permite hacer todo lo que puede hacer la consola de administración de Exchange pero desde la línea de comandos, lo cual es ideal para automatizar las tareas repetitivas. Desgraciadamente, es posible que exista una curva de aprendizaje para asimilar la sintaxis y la semántica. Aquí es donde entra en juego PowerShell Analyzer, de ShellTools.
La aplicación es básicamente un IDE para escribir y depurar scripts de Windows PowerShell. Pero a diferencia del ciclo tradicional de escribir compilar y probar, la aplicación mantiene el espíritu del administrador al teclado, proporcionando interactividad en tiempo real con un espacio de ejecución de Windows PowerShell. PowerShell Analyzer permite especificar comandos línea a línea, editar o ejecutar scripts de Windows PowerShell en un editor de la parte inferior de la IU. Ambas opciones permiten la finalización básica del código, lo cual es una gran ayuda para guiarle por los numerosos parámetros de los cmdlets. Si usa Windows PowerShell por primera vez, debe saber que los cmdlets son comandos abstractos parametrizados orientados a tareas.
Para obtener aún más ayuda, PowerShell Analyzer incorpora una ficha de acceso rápido que muestra descripciones detalladas, sintaxis, explicaciones de parámetros y ejemplos para cada uno de los cmdlets. Además, existen referencias para los proveedores de Windows PowerShell, para los archivos de ayuda integrados disponibles y los alias cortos de los cmdlet.
Cuando se ejecutan comandos de Windows PowerShell, de hecho se reciben objetos de Microsoft .NET Framework y no sólo un resultado de texto en pantalla. PowerShell Analyzer permite capturar las propiedades de los resultados devueltos y pasarlos a varios "visualizadores". Dichos visualizadores le permiten interactuar con los objetos (por ejemplo, ofrecer una exploración en árbol de datos XML o una vista clasificable y agrupable de la tabla de jerarquía), además de generar varios gráficos distintos para representar visualmente el conjunto de datos devuelto. Por supuesto, todas estas opciones no están disponibles para cualquier comando o script que ejecute, pero cuando son aplicables le ofrecen un completo conjunto de representaciones de sus datos, que posteriormente puede guardar o exportar para reutilizarlos.
PowerShell Analyzer también le permite trabajar simultáneamente con diversos espacios de ejecución, de modo que puede cambiar de tarea fácilmente. Además, la ventana del editor le ofrece estilos para resumir código y resaltar código personalizable para facilitar la lectura de los scripts.
En general, si va a trabajar con Windows PowerShell, una herramienta como PowerShell Analyzer facilitará enormemente la creación, edición y depuración de sus scripts.

Precio: 129 dólares (directo) para una única licencia.
Figura powershell

Desfragmentar discos
Auslogics Disk Defrag
www.auslogics.com/disk-defrag
Cuanto más se use el disco duro, más fragmentados estarán los archivos del disco. Crear y eliminar archivos, instalar y quitar programas e incluso generar memorias caché temporales de disco contribuyen a aumentar la fragmentación. Además, el índice de fragmentación puede aumentar drásticamente cuando falta espacio disponible en la unidad, ya que los nuevos archivos se propagan por los "agujeros" disponibles en un espacio que está casi completamente lleno. Toda esta fragmentación causará un rendimiento más lento del sistema.
Por supuesto, todo el mundo sabe que las versiones actuales de Windows® incluyen herramientas de desfragmentación. Pero si lo que busca es una opción dedicada o si acaba de actualizarse a Windows Vista® y echa de menos el control y la presentación de IU presente en las versiones anteriores de la herramienta de desfragmentación, hay una alternativa muy interesante que quizá desee probar: Disk Defrag, de Auslogics.
Disk Defrag funciona con Windows XP, Windows 2000, Windows Server® 2003 y Windows Vista. Y, como probablemente esté esperando, puede desfragmentar volúmenes FAT16, FAT32 y NTFS. La aplicación es de pequeño tamaño y se instala rápida y fácilmente.
Ejecutar la aplicación es igual de fácil. Lo único que tiene que hacer es elegir la unidad que desea desfragmentar, hacer clic en Next y sentarse a observar. Una vez completada la ejecución, Disk Defrag le ofrece un breve resumen de los resultados que muestra el número total de archivos, directorios, archivos fragmentados, archivos desfragmentados y archivos omitidos, así como la disminución del porcentaje de fragmentación. Si lo desea, también puede hacer clic en el botón Display Report de Disk Defrag para que la aplicación genere una versión HTML del informe de desfragmentación. Este informe le ofrece información útil adicional sobre el disco, como por ejemplo una lista de archivos omitidos y su ubicación, el número de fragmentos, el tiempo transcurrido para la ejecución y la información de clúster del disco.

Precio: Producto gratuito.
Disk Defrag es fácil de instalar y de usar
Disk Defrag es fácil de instalar y de usar

Transferencia de archivos
FileZilla
filezilla.sourceforge.net
No hay nada como un buen cliente de SFTP para facilitarle el trabajo (especialmente cuando el cliente está bien programado y es gratuito, como en el caso de FileZilla). FileZilla es un proyecto de código abierto, hospedado en SourceForge.net, iniciado por Tim Kosse y dos de sus colegas en 2001 para un proyecto de la clase de informática. FileZilla funciona con todas las versiones de Windows, desde Windows NT®4.0 a Windows Vista. El proyecto se ha desarrollado substancialmente en los últimos seis años, pero Kosse sigue siendo el jefe de proyecto de la aplicación.
Además de conexiones FTP estándar, el cliente admite conexiones vía SFTP con la versión 2 de Secure Shell (SSH2), FTP a través de TLS y FTP a través de SSL con cifrado implícito y explícito, así que podrá conectarse a una gran variedad de servidores. FileZilla puede incorporar firewalls locales por lo que permite limitar los puertos locales usados, así como establecer un enlace IP específico para transferencias no pasivas para IPv4 y para IPv6. El cliente también es compatible con varias configuraciones de proxy, como las de los proxys SOCKS4/5, HTTP1.1 y FTP.
En cuanto a la autenticación de servidor para sus conexiones FTP, FileZilla es compatible con configuraciones anónimas, configuraciones normales de nombre de usuario y contraseña y configuraciones basadas en cuentas. Además, puede habilitar la compatibilidad con Kerberos Generic Security Services (GSS) (para lo cual es necesario tener instalado en Kerberos para Windows en el sistema) y crear una lista de servidores compatibles con GSS. Naturalmente, también necesitará un ticket Kerberos v5 válido para que funcione GSS. También puede habilitar el soporte para su servidor Ident para conectarse a servidores que lo requieren como forma de identificación de su cliente.
FileZilla también puede administrar grupos grandes de sitios FTP y le permite organizar sus conexiones en una estructura de árbol. Para cada conexión que establezca, también puede definir directorios locales y remotos predeterminados, especificar el puerto al que debería conectarse, elegir si desea omitir el proxy configurado, elegir explícitamente un modo de transferencia activo o pasivo e incluso establecer un desplazamiento de zona horaria de servidor. Además de las conexiones guardadas, FileZilla tiene también una opción Quickconnect para las transferencias espontáneas, de modo que pueda escribir la dirección, el nombre de usuario, la contraseña y el puerto para, a continuación, hacer clic en un botón para conectarse. Una vez configuradas todas sus conexiones y opciones, puede exportarlas a XML como copia de seguridad o para reutilizarlas en otros sistemas.
La IU de la aplicación, parecida a la interfaz del Explorador de Windows, le permite arrastrar y soltar fácilmente los archivos entre los sistemas locales y remotos. Para transferencias de archivo, puede especificar una configuración predeterminada de sustitución de archivos, además de la opción de limitar las velocidades de descarga y carga en función de un conjunto predefinido de reglas o con un límite de velocidad fijo en KB. De forma predeterminada, FileZilla está configurado para usar transferencias de archivos comprimidos MODE Z en servidores compatibles, pero el usuario puede ajustar el nivel de compresión o desactivar la opción. El cliente tiene también una función de cola de transferencia que le permite poner en cola un conjunto de archivos para transferir y después importar y exportar esa lista de transferencias para reutilizarla. Esta función es perfecta para tareas repetitivas de administración del sistema.

Precio: Producto gratuito.

Edición de ejecutables
PE Explorer
www.heaventools.com
Para quienes realmente quieran introducirse en los detalles de sus aplicaciones, es recomendable echarle un vistazo a PE Explorer de HeavenTools. Esta aplicación le permite trabajar dentro de sus archivos Portable Executable (PE), que se usan para binarios ejecutables en aplicaciones Windows. En pocas palabras, PE Explorer proporciona una IU para explorar y editar el contenido de dichos ejecutables. PE Explorer puede abrir diversos tipos de archivos, desde los tipos más habituales como EXE o DLL, a los menos conocidos, como DPL o CPL.
La primera vez que decide explorar un archivo ejecutable, PE Explorer le muestra información acerca de las cabeceras del archivo, como el número de secciones de código, el tamaño de la imagen, el subsistema de la aplicación y la información del tamaño de pila. Otra vista ofrece una introducción a las cabeceras de sección del ejecutable; al hacer doble clic en una cabecera de sección se muestra una ventana que le permite explorar el contenido de cada sección.
La aplicación, que no está precisamente pensada para pusilánimes, le permite extraer, recalcular y eliminar secciones del PE cargado. Es una herramienta ideal para detectar virus, malware y demás ejecutables malintencionados y puede usar el visor Digital Signature Viewer de la aplicación para revisar y validar la firma digital Microsoft Authenticode, si la hay, en el archivo ejecutable cargado. Es una forma eficaz de comprobar el publicador y la integridad del archivo ejecutable.
PE Explorer contiene también una función de desensamblado rápido integrada, que le permite examinar el código de ensamblaje de su archivo ejecutable. Además, es compatible con los conjuntos de instrucciones habituales Intel x86, junto con extensiones como MMX, 3D Now! y SSE/2/3. El desensamblador también extrae cadenas de texto ASCII de la porción de datos de su PE.
Otra característica es Dependency Scanner, que analiza todos los módulos a los que está vinculado estáticamente su archivo PE y los que están cargados con demora, y los muestra en una estructura jerárquica de árbol, donde se muestra hasta dónde abarca el archivo PE.
Uno de los aspectos más divertidos de PE Explorer es, en mi opinión, Resource Editor. Esta característica le permite ver, extraer, reemplazar, editar y eliminar los recursos de un archivo ejecutable especificado. La IU le muestra una estructura tipo directorio de los recursos incrustados, como imágenes, sonidos, diálogos, menús, datos XML, datos HTML y barras de herramientas. No todos esos recursos permiten editarlos directamente, pero la mayoría permite su sustitución y edición. De este modo puede, por ejemplo, agregar su propia marca personalizada a una aplicación, cambiar el mensaje de los cuadros de diálogo, personalizar las acciones de la barra de herramientas, etc., sin tener acceso al código fuente. PE Explorer es una herramienta muy útil para quienes deseen analizar en detalle los archivos ejecutables. Pero si Resource Editor es la única función que desea, échele un vistazo a la aplicación Resource Tuner de la misma compañía y mucho más barata.

Precio: 129 dólares (directo) para una licencia personal; 199 dólares (directo) para una licencia empresarial.
Figure peexplorer

Reseña de libro
Seguridad extrema
www.awprofessional.com
Agregar un perímetro de red tradicional con buenos fundamentos a su infraestructura interna es un paso importante para proteger sus activos. Pero no es una solución milagrosa. Con la cada vez mayor movilidad y conectividad del hardware y el software de hoy en día, no existe un verdadero perímetro en su infraestructura corporativa; en su lugar, la infraestructura hasta extremos remotos. De hecho, mientras se protege contra los ataques de fuera de su entorno, es más probable que se inicie accidentalmente un ataque por parte de un usuario que trae su equipo portátil de casa y entra en su red corporativa no controlada.
Si lo que quiere es controlar el acceso a la red y asegurar los extremos de su infraestructura, es buena idea leer el libro de Mark Kadrich, Endpoint Security (Addison-Wesley Professional, 2007). El libro empieza definiendo exactamente qué son los extremos y le ofrece una muestra de las distintas variaciones que existen: clientes de Windows, clientes de Linux, dispositivos incrustados, teléfonos móviles y PDA. Kadrich ve la red como un "problema de control". Rechaza la típica representación de una red compleja con analogías orgánicas y, en cambio, la describe como algo que puede ser delineado y visualizado de forma útil y de fácil uso.
El libro explora los principios básicos del control de acceso a la red (NAC) y del establecimiento de un nivel de confianza. Esta explicación incluye cómo crear una línea de base segura para sus sistemas extremos mediante la protección y el control de su software de origen y su entorno de creación. Una visión general de las herramientas que pueden ayudarle a hacer que los extremos sean seguros y confiables cubre los aspectos conocidos, como el uso de firewall y software antivirus, señala la necesidad de una administración proactiva de las revisiones y, por último, describe herramientas más avanzadas, como los sistemas de detección y prevención de intrusiones, los comprobadores de integridad de host y el cifrado.
La segunda parte del libro explora los detalles de protección de los sistemas operativos de diversos tipos de cliente, incluidos Microsoft Windows, Apple OS X y Linux. Cada uno de estos capítulos le ofrece una introducción de cómo realizar una comprobación inicial de estado para su sistema extremo. Hay capítulos dedicados a los PDA, a los Smartphones y a los dispositivos incrustados, que explican cómo estos dispositivos se han convertido en una amenaza grave a su infraestructura y cómo proteger diversos tipos de comunicación en ellos.
Finalmente, Kadrich examina cuatro casos prácticos e identifica en cada uno de ellos cómo se pusieron en peligro los extremos y cómo se hubieran podido mitigar los errores. En resumen, Endpoint Security está repleto de información útil para el profesional de seguridad, y ofrece una visión no comercial sobre cómo garantizar la seguridad de su red desde el perímetro extremo.

Precio: 54,99 dólares la lista.

Greg Steen es un profesional de la tecnología, empresario y aficionado a la búsqueda de nuevas herramientas y referencias para ayudar a facilitar las operaciones y el desarrollo para los profesionales de TI. ¿Tiene alguna sugerencia? Hágasela llegar a tntools@microsoft.com


 Preguntas y respuestas sobre SQL: Desencadenadores de entrada, desfragmentaciones del archivo de datos, etc.
Preguntas y respuestas sobre SQL
Desencadenadores de entrada, desfragmentaciones del archivo de datos, etc.
Editado por Nancy Michell

Configuración de la cuenta de servicio
Sugerencia: Contraseñas más seguras
El motor SQL Server 2000 conserva dos copias de cada contraseña de entrada a SQL Server. Una versión es la contraseña real que suministra el usuario, mientras que la segunda es la contraseña en letras mayúsculas.
Esta práctica sirve para validar contraseñas con diferenciación entre mayúsculas y minúsculas, porque los usuarios pueden iniciar sesión mezclando mayúsculas y minúsculas o usando solo mayúsculas, y obtener acceso al servidor. Sin embargo, esta comodidad tiene un inconveniente: guardar las contraseñas en mayúsculas facilita los ataques para adivinar las contraseñas con ataques de fuerza bruta porque se reduce el número de contraseñas posibles.
SQL Server 2005 sólo almacena la copia original de la contraseña. Las contraseñas que especifica el usuario deben coincidir con la contraseña almacenada en el servidor. Si la contraseña no coincide, se produce un error de entrada y se deniega el acceso al usuario. Si se olvida la diferenciación entre mayúsculas y minúsculas, se debe restablecer la contraseña.
Suponiendo que el nombre de la entrada de usuario es SQLCOMMUNITY, puede restablecer la contraseña de SQL Server mediante el comando siguiente:
Use Master;
ALTER LOGIN SQLCOMMUNITY WITH PASSWORD = 'k3t9h4s8wJF7t';
Este comando restablecería la contraseña de entrada de SQLCOMMUNITY en SQL Server a "k3t9h4s8wJF7t".

P: En SQL Server™ 2000, establecía la cuenta de servicio del motor y agente de SQL Server mediante el applet Servicios de Herramientas administrativas. Ahora, en SQL Server 2005, tengo entendido que se debe usar la herramienta Administrador de configuración. ¿Por qué no puedo seguir usando las herramientas de Windows?
R: SQL Server 2005 se ha creado para ser más seguro que las versiones anteriores. En muchas tiendas, los usuarios sencillamente establecerían cuentas internas, como LocalSystem, para ejecutar SQL Server. Sin embargo, estas cuentas suelen tener o más o menos derechos y permisos de Windows® de los que necesitan. Debe crear una cuenta de Windows con privilegios no elevados para ejecutar los servicios Motor y Agente SQL Server 2005. Si selecciona estas cuentas mediante el Administrador de configuración, se les otorgarán los derechos y permisos apropiados de forma automática tanto en SQL Server como en el sistema operativo. Si usa las herramientas de Windows para administrar los servicios de SQL Server, es posible que no otorgue los derechos apropiados, o bien, que otorgue demasiados.
Para obtener más información, consulte la sugerencia Cambio de la cuenta de servicio.

¿Quién está iniciando sesión en Mi servidor?
P: Quiero saber quién inicia sesión en mi servidor y cuándo, además de restringir el acceso de algunos usuarios específicos a ciertos períodos de tiempo y saber cómo iniciar un seguimiento para localizar la actividad de los usuarios. ¿Es posible?
R: Sí, puede hacer todas estas cosas mediante SQL Server 2005 si tiene Service Pack 2 instalado.
SQL Server 2005 permite crear desencadenadores de entrada que pueden activar un T-SQL o un procedimiento almacenado en respuesta a un evento LOGON. Puede usar un desencadenador de entrada para auditar y controlar los usuarios mediante un seguimiento de la actividad de entrada, restringiendo las entradas a SQL Server o limitando el número de sesiones para entradas específicas. Tenga en cuenta que el evento se lanza cuando se ha autenticado una entrada correctamente, pero poco antes de que la sesión del usuario se haya establecido realmente. Por lo tanto, todos los mensajes que se originan desde dentro del desencadenador (como por ejemplo, mensajes o errores) de la instrucción PRINT se envían al registro de errores de SQL Server. Si se produce un error de autenticación de una entrada, no se activarán los desencadenadores Logon.
El ejemplo siguiente muestra como puede crear un desencadenador de inicio de sesión y enviar un mensaje al registro de errores de SQL Server cuando inicie sesión algún usuario:
ALTER TRIGGER Ops_Login
ON ALL SERVER
AFTER LOGIN
AS
PRINT SUSER_SNAME() + ' has just logged in to ' + LTRIM(@@ServerName) + ' SQL Server at '+LTRIM(getdate())
GO
Para ver todos los desencadenadores establecidos a escala del servidor, use la consulta siguiente:
SELECT * FROM sys.server_triggers;

Desfragmentación de prácticas recomendadas
P: ¿Cuál es la mejor manera de corregir la fragmentación de los archivos de datos en SQL Server? Las herramientas de desfragmentación de Windows tratan el archivo de datos de SQL en conjunto por lo que no lo desfragmentarán.
R: Podría realizar una copia de seguridad de la base de datos y, a continuación, restaurarla. Si existe espacio para un archivo contiguo, la base de datos se deberá escribir al lado. Dicho esto, no suele merecer la pena el tiempo de inactividad para tratar de desfragmentar los archivos físicos. De todos modos, prácticamente no existe fragmentación externa. Es más útil volver a indizar los datos con regularidad para reducir la fragmentación interna tanto como sea posible. Esto maximizará la eficacia de las lecturas previas y la cantidad de datos que se pueden almacenar en búfer.
Los factores más importantes para la eficacia de la E/S del disco garantizan que la alineación del disco y la configuración de RAID son correctas, escalan las matrices del disco para tratar la carga de E/S de forma adecuada y mantienen el diseño apropiado del registro, los datos, y la base de datos temporal, así como de los archivos de copia de seguridad. Si evita el crecimiento automático y la autorreducción como método principal para cambiar el tamaño de los archivos de datos, reducirá el número del volumen de los fragmentos de archivos creados. Por ejemplo, al realizar 10 crecimientos automáticos de 500 MB cada uno, seguramente agregaría 10 nuevos fragmentos físicos del archivo. En cambio, un único crecimiento manual de 5 GB agregará tan solo un fragmento.

Sugerencia: Cambio de la cuenta de servicio
¿Sabía que cuando la cuenta de inicio de sesión de servicio de SQL Server está configurada con una cuenta de Windows NT®, SQL Server establece los derechos y permisos del usuario de Windows en varios archivos, carpetas y claves del Registro? Además, puede establecer la cuenta de servicio de SQL Server de la consola Servicios dentro de Herramientas administrativas. Sin embargo, al hacerlo a través de Servicios, no se establecen los derechos y permisos y es posible que se encuentre con problemas graves debido a la falta de una configuración de seguridad apropiada en los elementos de SQL Server y Windows mencionados anteriormente.
Por lo tanto, es muy recomendable que use el Administrador de configuración de SQL Server, en lugar de la consola Servicios al cambiar la cuenta de servicio del Agente SQL Server. Sin embargo, si ya ha realizado los cambios en la cuenta con la consola Servicios, todavía podrá corregir este problema.
Paso 1: Aplique todos los permisos en las siguientes claves del Registro y sus subclaves:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\90
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<MSSQL.x>
Paso 2: Establezca el control total de la cuenta de inicio para el servicio MSSQLServer y SQLServerAgent (una cuenta de Windows NT local o una cuenta de Windows NT del dominio) en esta carpeta NTFS:
Drive:\Program Files\Microsoft SQL Server\<MSSQL.1>\MSSQL
Sin embargo, en lugar de hacerlo manualmente, se recomienda usar el Administrador de configuración de SQL Server para realizar cambios en las cuentas de servicio del Agente SQL Server.

Desea expresar mi agradecimiento a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Cary Gottesman, Saleem Hakani, Trayce Jordan, Peter Kalbach, Al Noel, Uttam Parui, Amber Sitko y Buck Woody.


 Utility Spotlight: Control remoto para m&#225;quina virtual Plus
Utility Spotlight
Control remoto para máquina virtual Plus
Matthijs ten Seldam
Descargar el código de este artículo: UtilitySpotlight2007_10.exe (10163KB)

La virtualización es un tema de actualidad. Muchos profesionales de TI usan la virtualización de hardware en situaciones de aprendizaje y pruebas. Por eso, Microsoft ofrece Virtual PC 2007, una solución de virtualización de software para instalaciones independientes con un número limitado de máquinas virtuales. Tenga en cuenta que este producto no reemplaza a Virtual Server
2005, que introdujo la virtualización en el centro de datos.
Microsoft® Virtual Server 2005 permite virtualizar muchas cargas de trabajo del servidor pero, a diferencia de Virtual PC, la interfaz Virtual Server es una aplicación web. Aunque la administración basada en web tiene sus ventajas, para la administración diaria se suele preferir una IU completa que se comporte como una aplicación de Windows®.
Control remoto para máquina virtual Plus (VMRCplus), es una IU alternativa para Virtual Server 2005. Debido a que se trata de una aplicación de Windows Forms, VMRCplus ofrece una administración sencilla de Virtual Server y sus máquinas virtuales. Tenga en cuenta que Virtual Server se suministra con una herramienta denominada VMRC que se usa para el control remoto de máquinas virtuales, pero VMRCplus ofrece tanto la administración de la configuración de Virtual Server como el control remoto de máquinas virtuales, y todo en una sola aplicación.

Virtual Machine Manager
En la figura 1 se muestra la ventana principal de VMRCplus, Virtual Machine Manager. En este ejemplo, Virtual Machine Manager está conectado a localhost y tiene cinco máquinas en funcionamiento, tres en estado guardado y las otras desactivadas. Está seleccionada la sexta máquina de la lista, y se muestra información adicional incluido el sistema operativo invitado, la carga de CPU, las estadísticas de E/S del disco y la red, y la versión de las adiciones instaladas. Tenga en cuenta que la lista está ordenada por estado.
Figura 1 Virtual Machine Manager de VMRCplus
Figura 1 Virtual Machine Manager de VMRCplus
A través de Virtual Machine Manager, se podrá conectar a hosts de Virtual Server y ver sus máquinas virtuales. Para cambiar de host, seleccione la ficha del host correspondiente y para conectarse a un host use la lista desplegable de la barra de herramientas, o bien, escriba el nombre de host o la dirección IP. Una vez establecida correctamente una conexión, VMRCplus agrega el nombre o la dirección IP a la lista.
Algunas propiedades del host de Virtual Server, como la información sobre la CPU y la memoria, aparecen en la parte inferior de la ventana. El contador de memoria ofrece una vista rápida de la cantidad de RAM disponible para las máquinas virtuales.

Administración de Virtual Server
Con Virtual Machine Manager, además de visualizar información también permite configurar las distintas opciones. Desde la opción de menú View se puede establecer el intervalo de actualización que usa VMRCplus para actualizar la lista de máquinas virtuales. La configuración del intervalo de actualización actual aparece en la esquina inferior de la derecha de la ventana, tal como se muestra en la figura 1.
El menú Virtual Server le proporciona acceso a la configuración de Virtual Server, incluida la de Control remoto para máquina virtual (VMRC), la ubicación predeterminada para máquinas virtuales nuevas, la configuración de seguridad y las propiedades del servicio. En la página de configuración de VMRC se puede establecer cualquiera de las propiedades, además de deshabilitar VMRC y volver a la configuración predeterminada de Virtual Server.
La página de configuración de seguridad permite especificar los permisos de Virtual Server. De forma predeterminada, el grupo local Administrators tiene control total sobre Virtual Server, por tanto, podrá especificar los permisos de los grupos y los usuarios. Si no forma parte del grupo de administradores local, debe agregar primero un grupo o su cuenta y establecer los permisos adecuados. Sin embargo, no es necesario que ejecute VMRCplus como administrador porque los privilegios de usuario normales son suficientes.
En la figura 2 se muestran las propiedades del host Virtual Server, incluidas las propiedades físicas. Tenga en cuenta que este host es compatible con la virtualización asistida por hardware, como se indica en las características del procesador.
Figura 2 Propiedades de Virtual Server
Figura 2 Propiedades de Virtual Server

Administración de redes y discos virtuales
VMRCplus incluye otros administradores destinados a funciones específicas de Virtual Server. Virtual Disks Manager tiene una interfaz con fichas que corresponden a los tipos de discos virtuales que se pueden crear, incluidos los discos duros (dinámicos o fijos), los disquetes y los discos de diferenciación. También podrá examinar sus discos virtuales.
Virtual Networks Manager permite administrar las redes virtuales. Podrá agregar la red virtual de un archivo de configuración virtual de la red (VNC), o bien, crear uno nuevo. Al crear la red virtual, puede asociar un adaptador de red host o designar la red sólo para invitados. Desde la misma ventana podrá habilitar un servidor DHCP virtual y abrir la configuración correspondiente.

Administración de máquinas virtuales
Los administradores anteriores se centraban en la administración de Virtual Server. ¿Qué ofrece VMRCplus para la creación y configuración de máquinas virtuales?
La creación de máquinas virtuales es un proceso sencillo: seleccione Virtual machine | Create en el menú. El cuadro de diálogo que aparece ofrece valores equivalentes a los de Virtual Server, aunque existen algunas diferencias en la interfaz. Por ejemplo, VMRCplus siempre crea dos discos duros virtuales y los asocia al SCSI. VMRCplus también permite la creación de varias máquinas virtuales a la vez; para ello, seleccione la opción para crear varias máquinas virtuales ("Create multiple virtual machines") e indique el número que desea. VMRCplus agrega un guión y el número de una secuencia al nombre de la máquina virtual que ha proporcionado.
Una característica realmente eficaz es la capacidad de crear varias máquinas virtuales a partir de una máquina virtual principal. Supongamos que ha creado una máquina virtual con las adiciones, Service Pack, revisiones y herramientas más recientes, y que quiere usarla como base para otras máquinas virtuales. Si ha ejecutado sysprep en la fase final y ha apagado la máquina principal, podrá crear varias máquinas virtuales que heredarán las propiedades de ésta.
Pasados unos segundos, podrá crear muchas máquinas virtuales basadas en la principal, además de iniciar rápidamente estas nuevas máquinas virtuales desde la misma referencia. Cuando haya terminado, una vez las haya probado, por ejemplo, sencillamente las puede eliminar. También es fácil: VMRCplus admite la selección múltiple en la lista de máquinas virtuales, así como la ordenación de las columnas. Por tanto, puede seleccionar varias máquinas virtuales y quitarlas (lo cual sencillamente las elimina del Registro), o bien eliminar las máquinas virtuales (con lo que también se eliminan los archivos correspondientes).
Hay otros comandos de selección múltiple que puede usar en las máquinas virtuales, como selección múltiple e iniciar, selección múltiple y abrir la consola o selección múltiple y guardar estado. Para realizar todo esto puede usar la IU o las teclas de acceso directo.
La configuración de una máquina virtual también es fácil con la página de configuración de hardware. Puede establecer la cantidad de memoria, agregar controladores de SCSI, adjuntar discos o imágenes (con tan sólo arrastrarlos y colocarlos), además de habilitar y configurar los adaptadores de red. La ventana de propiedades avanzadas le permite establecer los elementos de configuración más avanzados. Por ejemplo, puede ejecutar máquinas virtuales en una cuenta de usuario específica, de modo que podrá establecer el inicio automático de una máquina al iniciar Virtual Server.

Control remoto
Finalmente, VMRCplus ofrece también Console Manager, que permite realizar sesiones de control remoto (sesiones de VMRC) con máquinas virtuales. Para abrir una consola, seleccione una máquina virtual en funcionamiento (o varias) y haga clic en el botón de la consola de la máquina virtual en la barra de herramientas de las propiedades.
En la figura 3 se muestra la ventana de Console Manager, que permite ordenar por fichas las sesiones remotas. Para pasar de una máquina virtual a otra, seleccione la ficha correspondiente. Existe también una barra de herramientas que contiene las funciones que más se suelen usar.
Figura 3 Console Manager
Figura 3 Console Manager
Como puede observar, Console Manager tiene menús contextuales que permiten adjuntar una imagen virtual de disquete o una imagen de ISO, montar unidades de host e instalar adiciones actuales. Además, existe una barra de estado que muestra el estado de los soportes de disquete y CD/DVD, la versión actual de las adiciones de la máquina virtual, la tecla del host activo actualmente y el valor de configuración de cambio de tamaño de la pantalla dinámica. VMRCplus permite establecer la tecla del host. También permite el acceso a la configuración de hardware y a las propiedades avanzadas de la máquina virtual.
VMRCplus ofrece otras características prácticas. Por ejemplo, puede hacer una captura de pantalla de la configuración de la máquina virtual y guardarla como archivo .jpg, lo cual puede ser bastante útil para la solución de problemas. También puede seleccionar la opción para enviar texto a una máquina virtual para enviar texto a la máquina virtual como pulsaciones de tecla. No se trata de la función de portapapeles, pero es muy práctico en las situaciones en que, por ejemplo, debe copiar y pegar la clave de producto del host en la máquina virtual.
Paul Despe creó VMRCplus en principio como una herramienta para desarrolladores que controlaba algunas funciones básicas pero no abarcaba todas las características de Virtual Server. Sólo se usaba para realizar pruebas y presentaba una serie de problemas. Hace aproximadamente un año, empecé a rescribir el código para mejorar y ampliar su funcionalidad. Desde entonces se ha hecho popular para los usuarios de Virtual Server de Microsoft. Sin embargo, tenga en cuenta que VMRCplus no es una aplicación compatible con Microsoft. Se ofrece "tal como es" y está sujeta al contrato de licencia para el usuario final que incluye.
VMRCplus se ha desarrollado para Virtual Server 2005 Service Pack 1. Aunque las versiones anteriores deberían ser compatibles con el producto, solo se ha probado con Service Pack 1. En consecuencia, los usuarios deben actualizar los hosts de Virtual Server a Service Pack 1 antes de usarlo. VMRCplus se puede descargar desde el sitio web de TechNet Magazine en technetmagazine.com/code07.aspx.

Matthijs ten Seldam es un veterano consultor de Servicios de consultoría de Microsoft. Está especializado en las áreas de seguridad, implementación y automatización, y es experto en virtualización.


 El negocio de TI: C&#225;lculo del valor de la infraestructura de TI en la Administraci&#243;n
El negocio de TI
Cálculo del valor de la infraestructura de TI en la Administración
Acer Maamoun

Es difícil demostrar las ventajas de una inversión en infraestructuras de TI, tanto en hardware como en software, en administraciones públicas. Como sucede en otras organizaciones grandes, los administradores deben presentar las nuevas adquisiciones o mejoras como modelos de negocio ventajosos para la empresa, de modo que tengan prioridad frente a otras solicitudes de financiación.
Debido a que hay diferentes formas de encuadrar los modelos de negocio, los administradores de TI deben elegir el más conveniente para la cultura específica de su propia organización. Esto sirve tanto para administraciones público como para empresas. Alinear las TI con otras prioridades de la empresa es esencial. En el sector público, las organizaciones de TI han tenido éxito en la articulación de modelos de negocio con el concepto de valor público para crear carteras de proyectos e iniciativas.
La creación de un modelo de negocio que demuestre cómo la mejora de la infraestructura conlleva una mejor productividad o un servicio mejorado es un proceso difícil. Echemos un vistazo a algunas soluciones para definir y calcular el valor de las inversiones en infraestructura de TI que adoptan en el mundo real las organizaciones de TI dependientes de organismos públicos.

Justificación de las inversiones
Una queja común dentro de las organizaciones de TI es que reciben muchas solicitudes de demasiados departamentos de la empresa, cada una de las cuales, por supuesto, con nivel alto de urgencia. Las nuevas iniciativas tienden a ajustarse a los requisitos que regulan específicamente cada departamento o a prioridades relativas a la misión correspondiente. Estas iniciativas pueden parecer una selección aleatoria, pero suelen estar estrechamente alineadas con el valor público que pretende obtener cada departamento.
Por otro lado, los costos operativos que se generan proporcionalmente en función de la cantidad usada para mantener las operaciones particulares de cada departamento pueden esconder el costo y el valor de funciones que afectan a toda la empresa o servicios compartidos. En este entorno, el valor de las inversiones en nuevas infraestructuras y mejoras de la infraestructura existente con una repercusión a escala de empresa o que coincidan indirectamente con los objetivos de los distintos departamentos puede ser muy difícil de evaluar de forma adecuada.
En consecuencia, toda la organización de TI se suele encontrar con dificultades para mantener una visión empresarial en relación con la TI, tal como describe en el Marco Federal de Arquitectura Empresarial de la Administración de servicios generales (GSA Federal Enterprise Architecture Framework: whitehouse.gov/omb/egov/a-1-fea.html). En este entorno, es difícil darse cuenta de la mayoría de los esfuerzos para usar una vista compartida de la arquitectura empresarial, un modelo común de desarrollo de modelos de negocio y un proceso de administración de carteras para colocar las solicitudes de inversión de TI y el gasto en igualdad de condiciones. Un modelo más eficiente consiste en favorecer una cartera de actividades de TI que maximice de forma eficaz las ventajas del valor público. Esto requiere que se seleccionen y se apliquen criterios comunes de valor público a través de los procesos de desarrollo de casos del negocio, la administración de carteras, la realización y evaluación de las prestaciones.

Cálculo del valor
Existen algunos problemas reales con las inversiones de TI a escala de empresa. En primer lugar, tienen una repercusión más indirecta y duradera en términos de ventajas del valor público. Estas ventajas se acumulan, a menudo de forma desigual, en diferentes partes de la organización de forma que no siempre es fácil identificarlas de forma clara. Además, los riesgos y costos asociados se perciben con más facilidad que el valor público, al ser éste menos detectable y cuantificable.
Los modelos de negocio se deben basar en la forma en que una inversión en infraestructura permite realizar inversiones futuras y también las actividades actuales. Existen diferentes formas de calcular este valor, cada una de las cuales tiene sus propias ventajas e inconvenientes, así como un grado diferente de idoneidad para la cultura y. madurez de una organización particular.
Matemática Estos métodos se basan en un modelo matemático de posibles ventajas. Un método eficaz, denominado opciones reales, se basa en la teoría financiera. Tiene en cuenta los posibles cambios y necesidades de flexibilidad que puedan existir en el futuro considerando explícitamente el derecho a llevar a cabo una acción (es decir, la opción real) a un costo y en un espacio de tiempo determinados. Las opciones incluyen el aplazamiento, la ampliación, preparación o el abandono de las inversiones, así como el cambio de entradas o salidas y el desarrollo de programas piloto.
El sistema de las opciones reales es especialmente apropiado cuando los eventos futuros influyen en una decisión sobre inversión. En el caso la infraestructura de TI, dichos eventos pueden ser los siguientes: requisitos normativos, exigencias del negocio o incluso un evento importante, como un error de funcionamiento grave.
Simulación El análisis de incertidumbre está basado en la simulación de Monte Carlo, que usa herramientas automatizadas para calcular los resultados de escenarios alternativas en función de la selección de valores variables y en la repetición del proceso. La simulación requiere la identificación de un intervalo de valores (como el número de estaciones de trabajo afectadas o la respuesta electrónica del canal) y la distribución de la probabilidad de cada variable. El resultado de una simulación es el intervalo de los posibles resultados y permite la identificación del valor medio de las ventajas, así como los costos y riesgos. La elección meticulosa de variables de valor y riesgo para reflejar la posible repercusión de inversiones en infraestructura permite poner la recuperación de dicha inversión en perspectiva.
Escenarios Cuando los modelos de simulación o matemáticos no pueden aplicarse o bien no encajan en la cultura y las habilidades de la organización, pueden usarse en su lugar técnicas basadas en el escenario. Tomando en consideración la actividad o la misión de la agencia, las prioridades políticas y las tendencias ambientales (incluida la tecnología), la organización puede desarrollar un número limitado de escenarios plausibles para los próximos tres a cinco años. Cada escenario debe centrarse exclusivamente en la demostración de las ventajas de la inversión en infraestructura.
A diferencia de los ejercicios de planeación a un plazo más largo, no es necesario que los escenarios se excluyan mutuamente y es posible asignarles probabilidades. Los escenarios pueden tener en cuenta las elecciones futuras, los resultados de debates políticos y posibles eventos del mercado de TI, tales como adquisiciones o cambios importantes en las estrategias de los proveedores.
Escenario del peor caso Esta variación del enfoque basado en el escenario se aplica cuando la organización de TI cree que se necesita urgentemente una inversión para responder a los inminentes desafíos en cuanto al negocio y la misión, o bien sencillamente para mantener los niveles actuales de servicio. Cuando existen problemas de infraestructura desatendidos, éstos empeoran y aumenta el esfuerzo necesario para corregirlos. Quien inicie cambios, seguramente encontrará resistencia y es improbable que reciba reconocimiento por sus esfuerzos. Dicho escenario se puede solucionar en parte con un gran énfasis en las métricas y en la medición de factores relevantes para una parte del rendimiento afectado como, por ejemplo, el tiempo de respuesta de las solicitudes y el tiempo empleado en reparaciones. Esta información debe estar ampliamente disponible de manera que todo el mundo esté enterado de los posibles cambios en el rendimiento.
Los escenarios del peor caso enfatizan de forma intencionada las consecuencias de no realizar la inversión centrándose en las desventajas y el aumento de los riesgos. Este método se debe usar con mucho cuidado y solo en circunstancias realmente excepcionales. Con este método se podría crear la impresión de que la organización de TI trata de pasar por alto los procesos de administración de la inversión establecidos, lo cual puede generar conflictos y el desajuste que dichos procesos haya podido resolver.

Elección de una metodología de planeación
La figura 1 resume los pros y los contras de cada método y cuándo tenerlos en cuenta. Una vez elegido un método, se debe usar de forma coherente en toda la organización para garantizar que se pueda comparar su aplicación.
Figure 1 Metodologías de modelos de negocio (Close Figure 1)

Método Ventajas Inconvenientes A tener en cuenta
Opciones reales (matemáticas)
  • Riguroso
  • Base teórica sólida
  • Complejo
  • No adecuado cuando prevalecen valores intangibles
  • El valor y el valor futuro son cuantificables en su mayor parte
  • Existe una cultura afianzada de evaluación de la inversión
  • Las habilidades están fácilmente disponibles
Simulación
  • Permite la exploración de valores alternativos
  • Una forma sencilla de crear alternativas
  • Los promedios no tienen mucho sentido con los bienes intangibles
  • La selección del intervalo en la variable es importante
  • Predominan las ventajas tangibles
  • Existe soporte técnico para las herramientas
Escenario
  • Permite cualquier combinación de ventajas tangibles e intangibles
  • Permite la exploración de escenarios muy diferentes mediante la combinación de diferentes técnicas
  • Precisa una fuerte disciplina para converger en escenarios comparables
  • La perspectiva cronológica puede variar
  • Prevalecen los valores intangibles o no queda clara la naturaleza real de las ventajas
  • La cultura de la organización es hostil a otros métodos
Escenario del peor caso
  • Permite ver claramente las consecuencias de no hacer una inversión
  • Sencillo de crear
  • No ayuda a establecer prioridades
  • Se puede usar incorrectamente
  • La inversión es absolutamente crítica y no admite demora
La eficacia de cualquiera de estos enfoques depende de una serie de factores. Contestar las preguntas siguientes es un buen punto de partida. ¿Está el método integrado o es compatible con procesos obligatorios (como los presupuestos y la planeación del capital)? ¿Es el método del modelo de negocio elegido fácil de usar y eficaz a la hora de comunicar el valor a los interesados?
Las organizaciones deben tener un equilibrio entre la flexibilidad para elegir los indicadores del valor que encajen en una determinada agencia y la orientación para garantizar la posibilidad de comparación entre agencias. Además, es especialmente importante la capacidad de usar una métrica de valoración determinada durante el ciclo de vida de la inversión y no sólo durante el tiempo que dure el modelo de negocio. Del mismo modo, la planeación debe tener utilidad para diferentes tipos de inversiones.
En consecuencia, se debería seleccionar y desarrollar un método de generación de valor junto con los participantes en la estructura de gobierno de la organización. Es esencial que el marco seleccionado ofrezca una manera eficaz para comunicar el valor a los interesados internos y externos. Esto es aplicable tanto a ejecutivos de la empresa como a cargos públicos o la dirección de las agencias.
Recursos adicionales
  • Webcast: La TI como activo estratégico de la empresa
  • Serie de conexiones del administrador de TI

Acer Maamoun es consultor de estrategia empresarial y trabaja para Microsoft. Tiene más de 18 años de experiencia en la alineación entre negocios y estrategias de TI.


 The Cable Guy: El protocolo de Internet autenticado
The Cable Guy
El protocolo de Internet autenticado
Joseph Davies
Algunas partes de esta columna analizan una versión preliminar de Windows Server 2008. Dichos comentarios están sujetos a cambios.

Tanto Windows Vista como Windows Server 2008 (que ahora se encuentra en fase de prueba de la versión beta) admiten el protocolo de Internet autenticado (AuthIP), una versión mejorada del protocolo de intercambio de claves por red (IKE). Tanto AuthIP como IKE son protocolos usados para determinar material de claves y negociar parámetros de seguridad para comunicaciones protegidas mediante
protocolo de seguridad de Internet (IPsec). AuthIP ofrece configuración y mantenimiento simplificados de directivas de IPsec en muchas configuraciones y flexibilidad adicional para la autenticación de IPsec en el mismo nivel. Este artículo describe los detalles del protocolo AuthIP y los comportamientos de coexistencia entre interlocutores IPsec del mismo nivel que admiten AuthIP e IKE o sólo IKE.

Información general de IKE
Ejemplos de negociación
Para demostrar el comportamiento de coexistencia, examinemos lo que sucede entre interlocutores IPsec del mismo nivel basados en Windows Vista y Windows XP al intentar negociar la protección de IPsec.

Ejemplo 1: Dos interlocutores IPsec en modo de solicitud basados en Windows Vista
En este ejemplo, un IPsec del mismo nivel basado en Windows Vista (Peer 1) es el iniciador, y el respondedor ejecuta Windows Vista (Peer 2). Ambos sistemas del mismo nivel se configuran con modo de solicitud para comunicaciones entrantes y salientes. En modo de solicitud, un IPsec del mismo nivel solicita protección pero no la necesita. Los mensajes se intercambian de la siguiente manera:
  1. Peer 1 envía un segmento TCP Sincronizar (SYN) de texto no cifrado, e inicia una conexión TCP con Peer 2.
  2. Peer 2 envía un segmento de acuse de recibo de TCP SYN (ACK).
  3. Peer 1 envía un segmento TCP ACK.
  4. Peer 1 envía un mensaje ISAKMP basado en AuthIP e inicia una negociación de modo principal de AuthIP.
  5. Peer 1 envía un mensaje ISAKMP basado en IKE, e inicia una negociación de modo principal de IKE.
  6. Peer 2 responde con un mensaje ISAKMP basado en AuthIP y continúa una negociación de modo principal de AuthIP.
  7. Peer 1 y Peer 2 completan negociaciones de modo principal, modo rápido y modo extendido (opcional).
  8. Los segmentos siguientes que se envían por la conexión TCP están protegidos con IPsec.
El orden exacto de los mensajes del 1 al 5 depende de la latencia de la red. Los ejemplos descritos en este artículo se aplican a una red de muy baja latencia, en que el protocolo de enlace TCP (mensajes 1 a 3) se completa antes de que Peer 1 pueda enviar los mensajes ISAKMP iniciales (mensajes 4 y 5). En una red con mayor latencia, observará que Peer 1 envía el segmento TCP SYN de texto no cifrado, el mensaje ISAKMP basado en AuthIP y, a continuación, el mensaje ISAKMP basado en IKE como los primeros tres mensajes del intercambio de mensajes.

Ejemplo 2: Un IPsec del mismo nivel en modo de solicitud basado en Windows Vista y un IPsec del mismo nivel en modo de solicitud basado en Windows XP
En este ejemplo, un IPsec del mismo nivel basado en Windows Vista (Peer 1) es el iniciador y el respondedor ejecuta Windows XP (Peer 2). Ambos sistemas del mismo nivel se configuran con modo de solicitud para comunicaciones entrantes y salientes. Los mensajes se intercambian de la siguiente manera:
  1. Peer 1 envía un segmento TCP SYN de texto no cifrado, e inicia una conexión TCP con Peer 2.
  2. Peer 2 envía un segmento SYN-ACK TCP.
  3. Peer 1 envía un segmento TCP ACK.
  4. Peer 1 envía un mensaje ISAKMP basado en AuthIP e inicia una negociación de modo principal de AuthIP.
  5. Peer 1 envía un mensaje ISAKMP basado en IKE, e inicia una negociación de modo principal de IKE.
  6. Peer 2 responde con un mensaje ISAKMP basado en IKE y continúa la negociación de modo principal de IKE.
  7. Peer 1 y Peer 2 completan las negociaciones de modo principal y de modo rápido de IKE.
  8. Los segmentos siguientes que se envían por la conexión TCP están protegidos con IPsec.

Ejemplo 3: Un IPsec del mismo nivel en modo de solicitud basado en Windows Vista y un IPsec del mismo nivel en modo de requerir basado en Windows XP
En este ejemplo, un IPsec del mismo nivel basado en Windows Vista (Peer 1) es el iniciador y el respondedor ejecuta Windows XP (Peer 2). Peer 1 se configura con modo de solicitud para comunicaciones salientes y Peer 2 se configura con modo de requerir para comunicaciones entrantes. En modo de requerir, un IPsec del mismo nivel requiere protección de IPsec y descarta de modo silencioso los paquetes sin protección. Los mensajes se intercambian de la siguiente manera:
  1. Peer 1 envía un segmento TCP SYN de texto no cifrado, e inicia una conexión TCP, que Peer 2 descarta de modo silencioso.
  2. Peer 1 envía un mensaje ISAKMP basado en AuthIP, e inicia una negociación de modo principal de AuthIP, que Peer 2 descarta de modo silencioso.
  3. Peer 1 envía un mensaje ISAKMP basado en IKE, e inicia una negociación de modo principal de IKE.
  4. Peer 2 responde con un mensaje ISAKMP basado en IKE y continúa la negociación de modo principal de IKE.
  5. Peer 1 y Peer 2 completan las negociaciones de modo principal y de modo rápido de IKE.
  6. Peer 1 retransmite el segmento TCP SYN (protegido con IPsec).
  7. Peer 2 envía el segmento TCP SYN-ACK (protegido con IPsec).
  8. Peer 1 envía el segmento TCP ACK (protegido con IPsec).

IKE es un estándar de Internet, definido en RFC 2409 (ietf.org/rfc/rfc2409.txt), que define un mecanismo para establecer asociaciones de seguridad (SA) de IPsec. Una SA es una combinación de una directiva de mutuo acuerdo y claves que definen servicios y mecanismos de seguridad que ayudan a proteger la comunicación entre interlocutores IPsec. Específicamente, IKE combina la asociación de seguridad de Internet y el protocolo de administración de claves (ISAKMP) en RFC 2408 y Oakley Key Determination Protocol (RFC 2412). IKE usa Oakley Key Determination Protocol para generar el material de clave secreto para comunicaciones protegidas.
IKE usa ISAKMP para negociar las SA. ISAKMP incluye componentes para identificar y autenticar sistemas del mismo nivel, administrar las SA y cambiar el material de clave. ISAKMP es un marco para negociar comunicaciones protegidas independiente de los protocolos específicos de intercambio de claves, de los algoritmos de cifrado e integridad y de los métodos de autenticación.
Los interlocutores IPsec usan IKE para realizar negociaciones de modo principal y modo rápido de IKE. La negociación de modo principal crea la SA de ISAKMP, que protege negociaciones de seguridad. Durante la negociación de modo principal, el iniciador y el respondedor intercambian una serie de mensajes ISAKMP para negociar los algoritmos de cifrado y hash para la SA de ISAKMP, intercambian material de determinación de claves y se identifican y autentican entre sí.
En la fase de negociación de modo rápido, se crean las dos SAs de IPsec (una SA para datos entrantes y otra para datos salientes), que protegen los datos enviados entre dos interlocutores IPsec. Durante la negociación de modo rápido, el iniciador y el respondedor intercambian una serie de mensajes ISAKMP cifrados para negociar los algoritmos de cifrado y hash para las SA de IPsec entrantes y salientes.
Para obtener más información acerca de las negociaciones de modo principal y modo rápido basadas en IKE, consulte "Negociación IKE para asociaciones de seguridad de IPsec" en microsoft.com/technet/community/columns/cableguy/cg0602.mspx.

Información general de AuthIP
AuthIP es una versión mejorada de IKE que ofrece flexibilidad adicional con compatibilidad para autenticación basada en usuario, autenticación con múltiples credenciales, negociación mejorada de métodos de autenticación y autenticación asimétrica. Como IKE, AuthIP es compatible con las negociaciones de modo principal y modo rápido. AuthIP también es compatible con el modo extendido, una parte de la negociación de un IPsec del mismo nivel durante la cual se puede realizar una segunda ronda de autenticación. El modo extendido, que es opcional, se puede usar para varias autenticaciones. Por ejemplo, con el modo extendido puede realizar autenticaciones independientes basadas en equipo y en usuario.
La compatibilidad con autenticación múltiple forma parte del cumplimiento de IPsec para la plataforma de protección de acceso a redes (NAP), en la que los interlocutores de IPsec se autentican con credenciales de equipo y también usan un certificado de mantenimiento para demostrar que son compatibles con los requisitos de mantenimiento de sistema. Para obtener más información acerca de la protección de acceso a redes, consulte microsoft.com/nap. Y para obtener información adicional acerca de las características de AuthIP, consulte "AuthIP en Windows Vista " en microsoft.com/technet/community/columns/cableguy/cg0806.mspx.

Mensajes AuthIP
Tanto IKE como AuthIP usan ISAKMP para su intercambio de claves y como protocolo de negociación de SA. Los mensajes ISAKMP se envían mediante el protocolo de datagrama de usuario (UDP) y se componen de un encabezado ISAKMP y una o más cargas ISAKMP. El encabezado ISAKMP contiene información acerca del mensaje, que incluye el tipo de mensaje. La figura 1 muestra el formato del encabezado ISAKMP.
Figura 1 Formato del encabezado ISAKMP
Figura 1 Formato del encabezado ISAKMP
En el encabezado ISAKMP, la cookie del iniciador y la cookie del respondedor se establecen en un número aleatorio distinto de cero elegido por los interlocutores IPsec. El campo Siguiente carga indica la primera carga del mensaje ISAKMP, justo a continuación del encabezado ISAKMP. RFC 2408 enumera los valores definidos del campo Siguiente carga. Los tipos de carga 128-255 están reservados para uso privado. Los campos Versión principal y Versión secundaria indican las versiones de ISAKMP en el IPsec del mismo nivel que envía el mensaje ISAKMP. Para IKE y AuthIP, la versión principal es 1 y la versión secundaria es 0.
El campo Tipo de intercambio indica el tipo de intercambio ISAKMP que se realiza. El tipo de intercambio dicta la estructura y orden de las cargas ISAKMP. RFC 2408 define los valores del campo Tipo de intercambio. Los tipos de intercambio 128-255 están reservados para uso privado.
El campo Marcadores contiene tres marcadores definidos en RFC 2408. El bit menos significativo (bit 0) es el bit Cifrado, que indica que las cargas de ISAKMP están cifradas (cuando se establece en 1) o no cifradas (cuando se establece en 0). El cifrado se realiza mediante el algoritmo negociado por la SA de ISAKMP, identificada por la combinación de los campos Cookie del iniciador y Cookie del respondedor. El siguiente bit menos significativo (bit 1) es el bit Commit, que indica que el intercambio de claves es sincronizado (cuando se establece en 1) o no sincronizado (cuando se establece en 0). El bit Commit se usa para garantizar que la SA completa su negociación antes que se envíen los datos cifrados. El siguiente bit menos significativo (bit 2) es el bit Authentication Only, que se usa para indicar que el mensaje contiene (cuando se establece en 1) o no contiene (cuando se establece en 0) la carga Notify completa del tipo de intercambio informativo y que ha sido autenticada pero no cifrada.
El campo Id. de mensaje contiene un identificador único para el mensaje. El identificador de mensaje se usa para evitar conflictos cuando ambos interlocutores IPsec intentan establecer simultáneamente una SA de IPsec. El campo Longitud indica la longitud del mensaje ISAKMP completo.
Para IKE, el mensaje ISAKMP contiene una serie de cargas ISAKMP. La primera carga se indica con el campo Siguiente carga del encabezado ISAKMP. Cada carga ISAKMP tiene su propio campo Siguiente carga para indicar la carga que sigue. El campo Siguiente carga de la última carga está establecido en 0. La figura 2 muestra el formato de los mensajes IKE.
Figura 2 Formato de mensajes IKE
Figura 2 Formato de mensajes IKE
AuthIP usa mensajes ISAKMP con tipos de intercambio 243 (modo principal), 244 (modo rápido), 245 (modo extendido) y 246 (Notificar) en el campo Tipo de intercambio del encabezado ISAKMP. Una diferencia importante en los mensajes ISAKMP basados en AuthIP es que sólo contienen una carga ISAKMP: la carga Cifrada o la carga Notificar. La carga Cifrada contiene las cargas incrustadas que se usan en las negociaciones de modo principal, modo rápido o modo extendido. La carga Cifrada puede contener un conjunto de texto sin formato o de cargas cifradas, en función del bit Cifrado del campo Marcadores del encabezado ISAKMP. La figura 3 muestra el formato de mensajes AuthIP que contienen la carga Cifrada.
Figura 3 Formato de mensajes AuthIP que contienen la carga Cifrada
Figura 3 Formato de mensajes AuthIP que contienen la carga Cifrada

Coexistencia de AuthIP e IKE
Windows Vista® y Windows Server® 2008 son compatibles con IKE y AuthIP. Sin embargo Windows® XP y Windows Server 2003, sólo son compatibles con IKE. Un IPsec del mismo nivel que se inicia y es compatible con AuthIP e IKE y tiene una directiva de seguridad de conexión que usa AuthIP e IKE debe determinar si el IPsec del mismo nivel que responde es compatible con AuthIP o IKE. A continuación, debe usar el protocolo más apropiado para negociar la protección de IPsec y preferir el uso de AuthIP sobre IKE.
Para determinar el protocolo de negociación del IPsec del mismo nivel que responde, un IPsec del mismo nivel que inicia y que usa AuthIP e IKE envía los siguientes mensajes al mismo tiempo:
  • Mensaje 1: un mensaje AuthIP que inicia una negociación de modo principal
  • Mensaje 2: un mensaje IKE que inicia una negociación de modo principal
Si el nodo que responde es compatible con AuthIP, debe responder al mensaje 1 con un mensaje AuthIP que continúe la negociación de modo principal y descarte de modo silencioso el mensaje 2. Un nodo que responde y que no es compatible con AuthIP descarta de modo silencioso el mensaje 1 porque el campo Tipo de intercambio contienen un valor que no admite y responde al mensaje 2.
Para evitar la negociación basada en IKE entre dos interlocutores IPsec que ejecutan Windows Vista o Windows Server 2008 cuando el mensaje 1 se pierde en la red o llega después que el mensaje 2, los interlocutores IPsec que ejecutan Windows Vista o Windows Server 2008 envían el mensaje 2 con una carga ISAKMP de identificador de proveedor de AuthIP. La carga Id. de proveedor de AuthIP compatible indica que el IPsec del mismo nivel es compatible con AuthIP.
Por lo tanto, si un IPsec del mismo nivel que ejecuta Windows Vista o Windows Server 2008 recibe el mensaje 2 con la carga Id. de proveedor de AuthIP compatible, espera que el IPsec del mismo nivel que inicia retransmita los mensajes 1 y 2 y responde al mensaje 1.
El IPsec del mismo nivel que inicia sigue retransmitiendo ambos Mensajes 1 y 2 hasta que reciba una respuesta o se agote el tiempo de espera. Cuando el iniciador recibe una respuesta, determina la capacidad del respondedor a partir del encabezado ISAKMP de la respuesta. Si el tipo de intercambio se establece en 243 (que es el tipo de intercambio de una negociación de modo principal basada en AuthIP), el respondedor tiene capacidad AuthIP. Si el Tipo de intercambio se establece en 2 (que es el tipo de intercambio de una negociación de modo principal basada en IKE), el respondedor tiene capacidad IKE.
En función de la respuesta, el iniciador responde con el siguiente mensaje AuthIP a una negociación de modo principal basada en AuthIP o bien con el siguiente mensaje IKE a una negociación de modo principal basada en IKE. Los interlocutores IPsec deben usar el mismo protocolo que se usa para negociar la SA de ISAKMP durante la vigencia de la SA.

Joseph Davieses escritor técnico de Microsoft y autor del artículo mensual Cable Guy de TechNet en Microsoft.com/technet/community/columns/cableguy.


 Windows PowerShell: Trabajar sin un script
Windows PowerShell
Trabajar sin un script
Don Jones

Siempre que hablo con la gente acerca de Windows PowerShell (ya sea en una conferencia, en el grupo de noticias público de Windows PowerShell o en mi sitio web), conozco a administradores que me dicen que "esperarán" para aprender Windows PowerShell. ¿Por qué? La razón que dan con mayor frecuencia es que
"no tienen tiempo de aprender a redactar en este momento".
Es un caso habitual. En general, los administradores estamos bastante atareados, y no solemos tener mucho tiempo libre para aprender una tecnología nueva. Pero tenemos que ir siempre hacia adelante, aprendiendo software nuevo como Windows Vista®, Windows Server® 2008 y Exchange Server 2007, para estar a la vanguardia de las tecnologías vitales para nuestros trabajos. Y Windows PowerShell™ es una parte importante de estas tecnologías.
Otro motivo que citan a menudo los administradores para postergar el aprendizaje de Windows PowerShell es que tienen "miedo de convertirse en programadores", tal y como me dijo un compañero administrador. Bueno, pues en eso yo le puedo ayudar. Se sorprenderá si le digo que puede hacer cosas realmente asombrosas con Windows PowerShell sin escribir ni una sola línea de código.

Prepararse para la canalización
He escrito antes acerca de la flexible y eficaz canalización orientada a objetos que usa Windows PowerShell. Aunque las palabras "orientado a objetos" le hagan sospechar que me estoy adentrando en el terreno de los programadores, no tema. Uno de los aspectos de la canalización que más me gustan es la forma de usarlo interactivamente. Le puede dar resultados inmediatos y permite refinar fácilmente los resultados para llegar a obtener exactamente lo que desea. Por ejemplo, supongamos que quiero obtener un inventario de espacio libre en disco para varios equipos remotos. Ahora supongamos que tengo los nombres de dichos equipos listados en un archivo de texto llamado C:\equipos.txt. Es un archivo de texto simple con un nombre de equipo por línea, mucho menos complicado que una base de datos.
Para empezar, intentaré ver si puedo recuperar esta información desde mi equipo local. A fin de cuentas, si yo consigo en un equipo, no resultará difícil hacerlo en varios. Y recuerde que no habrá que escribir código. Lo haré todo interactivamente en el shell y obtendré resultados justo después de presionar Intro.
Una sugerencia sobre este tipo de tareas. Si desea inventariar información de administración de equipos remotos, probablemente usará Windows® Management Instrumentation (WMI). Ahora suponga que, en este ejemplo, lo único que sé es que necesito usar WMI. Así que entro en Live Search y escribo "windows wmi liberar espacio en disco" como término de búsqueda. Aparecen varios resultados que contienen las palabras "Win32_LogicalDisk". Parece una clase de WMI, y podría ser la que necesito. Ni me molesto en hacer clic en ninguno de estos resultados de búsqueda. En vez de eso, escribo "Win32_LogicalDisk" como nuevo término de búsqueda y el primer resultado es de una página de documentación sobre Win32_LogicalDisk en el sitio de MSDN ® (msdn2.microsoft.com/aa394173.aspx). Así que entro en esa página y veo que una de las propiedades de esta clase es FreeSpace, lo cual suena muy prometedor.

Encontrar un Cmdlet
Para el paso siguiente, necesito encontrar un cmdlet que pueda recuperar las propiedades de una clase WMI. Uno de los aspectos más notables de Windows PowerShell es que tiene unas fantásticas características integradas de autodetección, es decir, el shell le ayuda a descubrir sus capacidades. Así que escribo Help *wmi* para averiguar qué sabe el shell acerca de cómo trabajar con WMI. Los resultados, que se muestran en la figura 1, son el alias Gwmi y el cmdlet al que señala, Get-WMIObject. Básicamente, hay dos formas de tener acceso a la misma funcionalidad, de modo que no hay muchas opciones a elegir. Dado que hacen lo mismo y que Gwmi es un nombre más corto, usaré éste:
Figura 1 Información que tiene el shell acerca de cómo trabajar con WMI
Figura 1 Información que tiene el shell acerca de cómo trabajar con WMI
PS C:\> gwmi win32_logicaldisk
Tenga en cuenta que Windows PowerShell no distingue entre mayúsculas y minúsculas: sabe que los administradores no tenemos tiempo para detalles irrelevantes como presionar la tecla Mayús.
Los resultados de este comando, que aparecen en la figura 2, incluyen mis cinco unidades de disco locales y propiedades FreeSpace correspondientes, que aparecen en la lista como bytes. En la lista también se incluye una propiedad DriveType para cada una de estas unidades, y aparecen valores de 2, 3, y 5 en mi equipo.
Figura 2 Todas mis unidades locales y las propiedades FreeSpace correspondientes
Figura 2 Todas mis unidades locales y las propiedades FreeSpace correspondientes

Cmdlet del mes
Es posible que haya usado Get-Content para leer el contenido de un archivo de texto. Este comando trata cada línea del archivo como un objeto [string], y pasa los objetos a la canalización para que trabajen con ellos otros cmdlets. Pero Get-Content tiene algunas opciones que lo hacen más flexible: el parámetro -readCount, por ejemplo, permite especificar cuántos objetos [string] se pasan a la canalización a la vez (el valor predeterminado es enviarlos todos), mientras que el parámetro -totalCount controla el número total de líneas que se leen desde el archivo. Ambos parámetros son útiles para trabajar con archivos muy grandes donde es posible que no desee procesar el archivo entero de una sola vez por motivos de rendimiento.
Este es otro parámetro útil. El parámetro –encoding permite leer correctamente una amplia variedad de tipos de codificación de archivos, como Unicode, ASCII, UTF7, UTF8, entre otros. Para ver una lista completa de tipos de codificación compatibles, ejecute help gc (gc es un alias de Get-Content).

Refinar los datos
En este punto tengo dos problemas. Primero, no me interesa ninguna de las demás propiedades, sólo me interesa el espacio libre (FreeSpace). Segundo, no quiero saber nada acerca del espacio disponible para unidades ópticas, unidades extraíbles o unidades de red; sólo me interesan los discos duros locales. Quizá la propiedad DriveType me puede ayudar a distinguir entre los distintos tipos de unidad. Vuelvo al explorador web y veo que la documentación contiene una tabla que explica lo que representan los distintos valores DriveType. Sólo quiero los que tienen un DriveType de 3, que indica que la unidad es un disco duro local. Al no haber hecho esto nunca, decido mirar si el comando Gwmi admite algún tipo de filtrado. Al ejecutando Help Gwmi –full se muestran detalles acerca del funcionamiento del comando, incluidos varios ejemplos. Encuentro un parámetro que parece útil, –filter, y decido intentar ejecutar lo siguiente:
gwmi win32_logicaldisk -filter "drivetype = 3"
¡Funcionó! Mi lista de unidades ahora sólo contiene los discos fijos locales. Así queda resuelto el segundo problema; ahora necesito solucionar el primero: deshacerme de todas las propiedades que no me interesan.
Ejecuto Get-Command para mostrar todos los cmdlets de Windows PowerShell y me encuentro con Select-Object. La descripción dice que "selecciona las propiedades especificadas de un objeto o de un conjunto de objetos". Así que intento esto:
gwmi win32_logicaldisk -filter "drivetype = 3" | select freespace
Si canalizo los resultados de Gwmi a Select (el alias de Select-Object) puedo obtener la propiedad que necesito. Pero vaya. Estos resultados no son lo que esperaba, ya que lo único que tengo es una lista de números y ya no sé qué unidad corresponde a cada listado de espacio disponible. Así que vuelvo a la documentación y veo que la propiedad DeviceID contiene la letra de unidad. Reviso rápidamente mi comando y lo vuelvo a probar:
gwmi win32_logicaldisk -filter "drivetype = 3" | select deviceid,freespace
¡Perfecto! Y ya que sólo se muestran dos propiedades, el shell puede mostrar la información en una tabla ordenada. El mes próximo explicaré cuándo decide Windows PowerShell usar listas y tablas.

Cálculos
He recuperado información sobre el espacio disponible, pero está en bytes y esta medida no es tan útil como lo sería en megabytes o en gigabytes. Quizás no me interesa tanto la propiedad FreeSpace, como un valor calculado a partir de la propiedad FreeSpace. El cmdlet ForEach-Object (o uno de sus muchos alias, como %) puede resultar útil en este sentido. Este cmdlet permite usar una variable especial, $_, para referirse al disco lógico actual, y permite tener acceso a todas las propiedades de cada disco por separado y realizar algunos cálculos. Aquí puede ver el comando modificado por mí:
gwmi win32_logicaldisk -filter "drivetype = 3" | % { $_.deviceid; $_.freespace/1GB }
Lo único que he hecho es eliminar Select y sustituirlo por el alias de ForEach-Object (%). El cmdlet sólo necesita que especifique qué hacer con cada Win32_LogicalDisk obtenido, y le he indicado que obtenga la propiedad DeviceID y divida la propiedad FreeSpace por un gigabyte (Windows PowerShell "distingue" entre KB, MB y GB) para que el resultado se exprese en gigabytes.

Varios equipos
Ahora que funciona para un equipo, es hora de hacer que funcione con varios equipos. Sé cómo obtener el contenido de un archivo de texto. Esto se hace de la misma forma que en los viejos tiempos de MS-DOS®: usando el comando Type, que en Windows PowerShell resulta que es un alias de Get-Content:
Type c:\computers.txt
Lo que quiero hacer es tomar cada uno de estos equipos, y para cada uno, realizar el comando WMI que ya he preparado. La expresión "para cada uno" indica un cmdlet concreto: ForEach-Object. Vamos directos al grano, y echemos un vistazo al comando final:
type c:\computers.txt | % { $_;
gwmi –computername $_ win32_logicaldisk -filter "drivetype=3" | % { $_.deviceid; $_.freespace/1GB} }
De un poco de miedo, ¿no? Debido a que uso exclusivamente de alias en lugar de nombres de cmdlet, cuesta leer el resultado. No obstante, es bastante fácil de descifrar si se hace de bit en bit:
  • Empecemos "escribiendo" el contenido de mi archivo de texto.
  • Canalizo el contenido a ForEach-Object.
  • ForEach-Object genera el artículo actual, mediante la variable $_ (se trata del nombre del equipo actual).
  • A continuación, ForEach-Object ejecuta mi comando WMI, que tiene otra llamada ForEach-Object.
Puede ser de ayuda expandir los nombres de alias en nombres de cmdlet. Aquí está el mismo comando, pero esta vez he deletreado los cmdlets y he fragmentado el comando en líneas individuales para que se vea más fácilmente cada sección:
Get-Content C:\Computers.txt |
ForEach-Object {
 $_; Get-WMIObject –computername $_
Win32_LogicalDisk -filter "DriveType=3" |
 ForEach-Object {
 $_.DeviceID; $_.FreeSpace/1GB
 }
}
Los resultados (que no resultan atractivos, pero sí funcionales) se muestran en la figura 3.
Figura 3 Los resultados finales
Figura 3 Los resultados finales

No se necesita scripting
El objetivo de esta explicación es demostrar que puede usar Windows PowerShell sin necesidad de scripting. Con tan sólo algunos ejemplos como este, además de una pequeña estudiar un poco el propio Windows PowerShell, puede encontrar algunos de los bits que necesita para realizar cualquier tarea que se proponga.
La idea es que Windows PowerShell ha venido para quedarse. ¿Por qué no empieza ahora a aprender a usarlo? Es posible que se esté preguntando cómo había podido vivir sin él. ¡No permita que la palabra scripting le impida sumergirse en este apasionante mundo!

Don Jones es el principal gurú de scripting de SAPIEN Technologies y formador de ScriptingTraining.com. Póngase en contacto con Don a través de su sitio web en ScriptingAnswers.com.


 &#161;Hola, encargados del scripting!: H&#225;gase de Silverlight
¡Hola, encargados del scripting!
Hágase de Silverlight
Los encargados del scripting
Descargar el código de este artículo: HeyScriptingGuy2007_10.exe (156KB)

La historia de la humanidad ha estado marcada durante mucho tiempo por el choque de fuerzas diametralmente opuestas: Los romanos contra las hordas bárbaras; los Montesco contra los Capuleto; los encargados del scripting contra los que creen que un artículo acerca de scripting de administración de sistemas debe hablar en realidad acerca de la administración de sistemas antes que, por ejemplo, del choque histórico entre fuerzas diametralmente opuestas. [o, pongamos, de ganchos de carnicero... (nota del director)]
El mundo de la informática no está inmune a estos choques entre fuerzas diametralmente opuestas. En particular, se menciona el choque entre desarrolladores y administradores del sistema. Como Karl Marx dijo al inspeccionar la situación: "este hombre está muerto o mi reloj se ha detenido".
Espere, perdón, en realidad era Groucho Marx. Karl Marx dijo: "el arte es siempre y en todas partes la confesión secreta y, al mismo tiempo, el movimiento inmortal de su tiempo". Para ser sinceros, no tenemos la menor idea de lo que significa. Además, Groucho Marx era bastante más gracioso que Karl Marx, aunque las ocurrencias de Groucho no sean muy relevantes para el choque entre desarrolladores y administradores del sistema.
No obstante, estamos casi seguros de que fue Karl Marx quien acostumbraba a obligar a los encargados del scripting a recitar el himno a la automatización cada mañana antes de trabajar: "los administradores del sistema no son desarrolladores". Y realmente era una gran verdad: los administradores del sistema no eran desarrolladores. Los desarrolladores eran personas que escribían los programas, mientras que los administradores del sistema eran personas que... bueno, sinceramente, no estamos seguros de que nadie de Microsoft sepa en realidad qué hacían los administradores del sistema. Pero fuera lo que fuera, seguro que no escribían programas de software.
Por supuesto, Karl Marx también es el autor de la canción "Los tiempos están cambiando" (o eso nos contó).
Gracias en parte al TechNet Script Center (microsoft.com/technet/scriptcenter), los administradores del sistema gradualmente descubrieron VBScript y comenzaron a escribir sus propias utilidades, que, aunque no sean tan completas y extensas como los programas típicos, realizan útiles tareas de administración. Para escribir estas utilidades, los administradores del sistema han tenido que apelar a habilidades muy semejantes a las que usan los desarrolladores.
Y eso para empezar. La llegada de Windows PowerShell™ (microsoft.com/technet/scriptcenter/hubs/msh.mspx) implica que Microsoft® .NET Framework ya no está fuera del alcance de los administradores del sistema y escritores de script. Windows Vista® presentó los gadgets al mundo (microsoft.com/technet/scriptcenter/topics/vista/gadgets-pt1.mspx) y puso a los administradores del sistema (o al menos, a los que escriben scripts), en pie de igualdad con los desarrolladores. Y ahora (redoble de tambores) llega Microsoft Silverlight, el "complemento que sirve para todos los exploradores y plataformas que permite vivir la próxima generación de experiencias de medios y aplicaciones interactivas enriquecidas para la Web basadas en .NET Framework".
Suena bien, ¿no? Pero, se preguntará, ¿y esto qué tiene que ver con los creadores de scripts de administración de sistemas como usted? Para ser sinceros, no estamos totalmente seguros. Sin embargo, Silverlight hace muy fácil la creación de interfaces de usuario y presentaciones multimedia atractivas. Y aunque el material de marketing se refiere invariablemente a Silverlight como una manera de crear aplicaciones web, una verdad poco conocida es que Silverlight parece funcionar igualmente bien en aplicaciones HTML y en HTA (microsoft.com/technet/scriptcenter/hubs/htas.mspx), un medio muy apreciado por los escritores de script. Por tanto, quizá merezca la pena intentar usar Silverlight.

Antes de que continuemos...
Debemos indicar que no hablaremos hoy sobre muchas funciones y posibles usos de Silverlight; nuestro objetivo principal es mostrarle suficientes fragmentos de código para que jugar con la tecnología. Si desea instalar Silverlight (es gratis, por cierto), vaya a la página principal de Silverlight en microsoft.com/silverlight. También puede encontrar los SDK, proyectos de ejemplo y otros materiales útiles en silverlight.net/GetStarted.
Por ahora, daremos hecho que ya instaló Silverlight. También asumiremos que ya fue a la sección Code Downloads del sitio web de TechNet Magazine (technetmagazine.com/code07.aspx) y descargó los archivos que se describen en la figura 1.
Figure 1 Componentes de proyecto de Silverlight (Close Figure 1)

Archivo | Descripción
CreateSilverlight J | Se trata de un script JScript (en su versión inicial, Silverlight admite sólo scripting JScript) que se usa para especificar la configuración de inicio de Silverlight, incluido el archivo XAML usado para configurar objetos de interfaz de usuario y gráficos.
SampleProject.js | Se trata simplemente de un archivo vacío donde puede especificar funciones JScript.
Silverlight.js | Este archivo se usa para inicializar el control de Silverlight.
SampleProject.html | Esta es la parte más emocionante. SampleProject.html es simplemente un archivo HTML que incluye código para la lectura de los tres archivos .js. También incluye código para crear una instancia del control de Silverlight.
SampleProject.xaml | ¿Para qué sirve esto? Para averiguarlo, tendrá que regresar al texto principal de este artículo.
No necesitará SampleProject.js obligatoriamente, al menos para seguir el artículo de este mes. Silverlight le permite adjuntar scripts a objetos y eventos en su proyecto; dichos scripts se pueden codificar en su archivo HTML o (como en este caso) leer desde un archivo "include" externo como éste. Además, vamos a convertir SampleProject.html en una HTA: simplemente cambie el nombre por SampleProject.hta. ¿Fue fácil, no?
Asegúrese de guardar en una carpeta todos estos archivos. Y, a continuación, prepárese para la diversión.

El archivo XAML
Como quizás adivinó, todo el entusiasmo del artículo ¡Hola, encargados del scripting! de este mes gira en torno al archivo XAML. (A propósito, XAML se pronuncia "zamel," que rima con camel (camello). O con mammal (mamífero). O también con enamel [encía]. XAML es un acrónimo de lenguaje de marcado de aplicaciones extensible. Entre otras cosas, XAML ofrece una manera de crear interfaces de usuario que usan un lenguaje similar a XML. ¿Facilita esto a alguien, especialmente a un administrador del sistema, la creación de interfaces de usuario? Está a punto de averiguarlo.
Para comenzar este ejercicio, inicie el Bloc de notas y abra el archivo SampleProject.xaml. Si observa que existe código, reemplácelo con lo siguiente:
<Canvas
 xmlns="http://schemas.microsoft.com/
    client/2007"
 xmlns:x="http://schemas.microsoft.com/
    winfx/2006/xaml">
</Canvas>
Nota: SampleProject.hta ya está preconfigurado para cargar información de SampleProject XAML. Para usar un archivo XAML diferente, necesita editar el archivo CreateSilverlight.js.
Después de pegar el código, guarde el archivo y, a continuación, haga doble clic en SampleProject.hta. ¿Adivina lo que verá? Exacto: un enorme e inútil cuadro gris.
Pero espere, no se vaya. Es exactamente eso lo que debe ver.
No hay mucho por ver simplemente porque aún no hemos hecho nada: todo lo que hicimos hasta ahora es agregar un lienzo a nuestro archivo XAML. Pero ése es un paso importante. Después de todo, si desea probar pintura al óleo lo primero que debe hacer es encontrar un lienzo para pintar. Lo mismo sucede con Silverlight: antes de que podamos empezar a agregar elementos a nuestro proyecto necesitamos primero un lienzo sobre el que "pintar". Y ya lo tenemos.
A propósito, ¿por qué obtuvimos un cuadro gris de 300 píxeles de ancho por 300 píxeles de alto? Muy fácil: ésas son las especificaciones que se encuentran, de forma predeterminada, en el archivo CreateSilverlight.js. Si no desea esos valores predeterminados, simplemente abra CreateSilverlight.js y ajuste la configuración según sea necesario. ¿Preferiría un lienzo blanco de 800 píxeles de ancho por 300 píxeles de alto? Probablemente lo preferirá para los ejemplos que estamos a punto de usar. Simplemente asegúrese de que estas tres líneas están presentes en CreateSilverlight.js:
width:'800', // Width of rectangular region of
             // control in pixels.
height:'300', // Height of rectangular region
              // of control in pixels.
background:'white', // Background color of
                    // control.
Nota. Buena observación: en el archivo .js original el fondo está establecido en #D6D6D6. Ahora lo establecimos en blanco. Pero resulta que en un archivo XAML se pueden usar valores RGB para representar los colores, o se pueden usar nombres de colores para representar los colores. Vaya a msdn2.microsoft.com/bb188314.aspx para obtener una lista completa de los valores y los nombres de los colores. Dado que los encargados del scripting prefieren referirse a los colores por sus valores RGB ("¿Mi casa? Es una FFFFFACD con molduras FFCD5C5C"), decidimos usar aquí los nombres de colores.
Otra sugerencia: no se limite a usar colores sólidos para el fondo del lienzo. Pegue el código de la figura 2 en su archivo XAML y observe el resultado.
Figure 2 Colores elegantes (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
¿Lo intentó? Queda bien, ¿no?
Por supuesto, un lienzo en blanco por sí mismo no es muy interesante. Así que sigamos adelante y agreguemos un objeto al lienzo. Aunque Silverlight le permite agregar todo tipo de objetos diferentes (incluidos elipses, rectángulos, líneas y polígonos), agregaremos a nuestro lienzo un bloque de texto clásico. ¿Cómo? Mediante la inserción de las siguientes etiquetas entre las etiquetas <Canvas> y </Canvas> de nuestro archivo XAML:
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">
</TextBlock>
Como puede ver, este asunto del XAML realmente no es tan difícil. Empezamos mediante la etiqueta <TextBlock>, y nos aseguramos de incluir los distintos parámetros de TextBlock (como Name y FontSize) dentro de la etiqueta. a continuación, indicamos que terminamos nuestro TextBlock mediante la etiqueta </TextBlock>. ¿Cuál es la ventaja de este sistema? Esta es prácticamente lo único que hay que hacer para agregar cualquier objeto a un archivo XAML. ¿Desea agregar un rectángulo de 300 píxeles de ancho por 100 píxeles de alto? De acuerdo:
<Rectangle
 Height="300"
 Width="100"
 Fill="Blue">
</Rectangle>
A propósito, al agregar una forma (por ejemplo, un rectángulo) a su lienzo, asegúrese de especificar un color de relleno y un color de trazo. Si no lo hace, Silverlight agregará un rectángulo transparente al lienzo. El rectángulo existirá, pero a menos que tenga visión de rayos X como Superman, no podrá verlo.
Hablando de colores de relleno y colores de trazo, ésta es la manera en que se asignan colores a algunos objetos de Silverlight. En otros objetos, necesita usar un pincel, como LinearGradientBrush que ya le mostramos (pero no analizamos) en nuestra sugerencia adicional. Si prefiere pintar objetos con un color sólido, puede usar SolidColorBrush, que por cierto, responde bien a su nombre. Por ejemplo, examine el etiquetado XAML de la figura 3 que "pinta" nuestro texto de rojo (técnicamente, pinta la propiedad Foreground de TextBlock).
Figure 3 Pintura de texto (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Para obtener un efecto más atractivo, pruebe la propiedad ImageBrush, que rellena texto con una imagen:
<TextBlock.Foreground>
 <ImageBrush Name="test_brush" ImageSource="Sunset.jpg"/>
</TextBlock.Foreground>
Y he aquí otra sugerencia más: Si prueba la propiedad ImageBrush, probablemente deseará aumentar el valor de FontSize porque cuanto más grande es el texto, mejor es el efecto.
Inténtelo y verá lo que sucede. Como es de esperar, le resultará llamativa.

Pero espere: Todavía no ha visto nada
Tenemos que ponernos al mismo nivel: hasta ahora nos hemos reservado lo mejor para nosotros. Está muy bien poder mostrar texto en Silverlight y aún está mejor poder dibujar rectángulos, elipses y polígonos. Pero todo eso no es nada cuando se compara con las animaciones que se pueden agregar a un proyecto de Silverlight.
Nuevamente, lo único que podemos hacer en este artículo es presentarle algunas maneras de crear animaciones en Silverlight: ir más allá supondría ocupar un espacio que no tenemos. (No es culpa nuestra: seguimos insistiendo en que TechNet Magazine se convierta en la revista ¡Hola, encargados del scripting!, pero parece que hay algún problema para que nuestros mensajes de correo electrónico lleguen a sus destinatarios.)
Pero vayamos al grano: he aquí un efecto atractivo para que el texto se intensifique de manera lenta (pero segura). Agregue el código de la figura 4 entre las etiquetas <TextBlock> y </TextBlock> en su archivo XAML.
Figure 4 Trucos de TextBlock (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Hay que admitir que parece una operación compleja, pero afortunadamente, la mayor parte es sólo etiquetado repetitivo. Para empezar, no basta con agregar una animación a un archivo XAML; necesita indicar cuándo se supone que esa animación se reproducirá. Eso requiere que especifiquemos un conjunto de Triggers para el TextBlock. En este caso, crearemos un desencadenador que iniciará la animación cada vez que se cargue TextBlock:
<EventTrigger RoutedEvent="TextBlock.Loaded">
En Silverlight, las animaciones deben hacerse en un guión gráfico (un término que se toma prestado de la industria cinematográfica). Por eso tenemos las etiquetas <BeginStoryboard> y <Storyboard>.
Para hacer que nuestro texto se intensifique, necesitamos modificar la propiedad Opacity. Aumentaremos gradualmente el valor desde 0.0 (transparente) a 1.0 (color sólido). Debido a que Opacity resulta ser una propiedad Double (una propiedad basada en un valor numérico de doble precisión), usamos una animación DoubleAnimation. ¿Y cómo hacemos para usar una animación DoubleAnimation? Indicando el objeto que deseamos animar (en este caso Test, el nombre que asignamos a TextBlock); especificando la propiedad de destino (Opacidad); y, a continuación, especificando el rango de animación (de opacidad 0.0 a opacidad 1.0) y la duración de la animación completa (5 segundos). En otras palabras:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
Nota. Asegúrese de usar la sintaxis 0:0:5 (horas, minutos, segundos) para indicar 5 segundos. Si usa el valor 5 de forma independiente no generará ningún error, pero la animación tardará 5 días en completarse.
¿Lo intentó? Ahora pruebe lo siguiente: dentro de la etiqueta DoubleAnimation, establezca la propiedad AutoReverse en True:
AutoReverse="True"
Su animación se intensificará y volverá a atenuarse.
Establezca la propiedad RepeatBehavior en Forever y su texto continuará intensificándose y atenuándose, pero para siempre:
RepeatBehavior="Forever"
¿Es para siempre demasiado tiempo? Establezca RepeatBehavior en, por ejemplo, 3x, para que la animación se reproduzca 3 veces y, a continuación, salga.
RepeatBehavior="3x"
Todo muy bonito, nos decimos. Sin embargo, ¿qué sucede si no le gusta que un texto se intensifique y después se atenúe? ¿Qué sucede si prefiere que un texto cambie gradualmente de color? En tal caso debe usar una animación ColorAnimation:
<ColorAnimation
 Storyboard.TargetName="test_brush"
 Storyboard.TargetProperty="Color"
 From="Red" To="Blue" Duration="0:0:5" />
Nota. Asegúrese de empezar con texto rojo si prueba el ejemplo siguiente. Recuerde que ya le mostramos cómo pintar su texto de rojo.
Divertido, ¿verdad? Y aún así, parece un poco decepcionado. Ah, esa es la razón: ColorAnimation estuvo bien, pero en realidad esperaba poder hacer que los objetos volaran alrededor de la pantalla. No se ponga triste. ¿Qué clase de software sería Silverlight si no le permitiera hacer volar los objetos vuelen por la pantalla? Pruebe esto:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Left)"
 To="150"
 Duration="0:0:5" />
Como puede observar, hacemos que nuestro TextBlock se mueva lentamente desde su posición inicial hasta un lugar ubicado a 150 píxeles del borde izquierdo del lienzo (Canvas.Left). Si deseamos mover TextBlock hacia arriba y abajo, simplemente hay que usar la propiedad Canvas.Top:
<DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="(Canvas.Top)"
 To="150"
 Duration="0:0:5" />
¿Podríamos (aguantad la respiración) combinar estas animaciones y hacer que TextBlock se mueva de lado a lado y de arriba a abajo? No tenemos ni la más mínima idea. Pero he aquí una sugerencia: pegue ambas animaciones en su archivo XAML (una a continuación de la otra) y observe lo que sucede.
Nota. Muy bien, era mentira: ya sabíamos que podría combinar estas animaciones. De hecho, podría llenar un único proyecto de Silverlight con un montón de animaciones. Es un poco complicado, quizás tendría que incluir marcado adicional para asegurarse de que una animación termina antes de que comience la siguiente. Pero esto también le permite realizar algunas animaciones muy elegantes simplemente con escribir algunas etiquetas similares a XML.

Lo sentimos amigos; terminó la presentación
Sí, lo sabemos: también lamentamos tener que irnos, especialmente ahora que empezamos con el material realmente bueno. Pero no se preocupe; esto no tiene que ser una despedida. Si desea conocer más acerca de Silverlight, escríbanos unas líneas a scripter@microsoft.com. Si hay suficiente interés, veremos lo que podemos hacer en los próximos artículos. Además, asegúrese de pasar por el TechNet Script Center (microsoft.com/technet/scriptcenter/resources/tnmag/archive.mspx); publicaremos vínculos para completar los ejemplos XAML (¿eXAMpLos?). Hasta entonces, como Karl Marx y Frederick Engels dijeron al final de su declaración desde el Comité comunista de correspondencia de Bruselas a G. A. Kottgen, "Buenas noches, y conduzcan con cuidado".

Los encargados 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: BitLocker y la complejidad de la confianza
Vigilancia de seguridad
BitLocker y la complejidad de la confianza
Justin Troutman

Windows Vista. Hasta ahora no había tenido la oportunidad de escribir ningún artículo en el que aparecieran estas palabras, por eso me siento como un niño de cinco años con un cheque en blanco para gastar en una juguetería. Existen muchas características de las que hablar, propiedades que vale la pena explorar y muchos caminos por los que puede discurrir una conversación.
Hace poco, leyendo el blog de Bruce Schneier, el gurú de la seguridad, encontré una entrada que hablaba sobre un concepto nuevo para mí en ese momento: BitLocker™. Deduje que se trataba de un producto pensado para ofrecer la funcionalidad de criptografía en Windows Vista® y me estremecí y pensé "Oh no, Windows Vista incorpora criptografía. No puede tratarse de nada bueno. Y, aunque el resultado sea presentable, seguro que hay una puerta trasera oculta.".
Existen argumentos históricos, que pueden ser discutibles, respecto a la falta de confianza en las características de seguridad integradas en Windows®. Pero esta no es la razón por la que escribo esta columna. En realidad, quiero explicar con argumentos por qué creo que hay razones de peso para dar una oportunidad a BitLocker. Además, quiero hacer algún comentario sobre el tipo de filosofía que garantiza la vitalidad del software y hardware criptográficos.
Pero no me malinterprete: no creo que BitLocker sea la panacea de la seguridad en conjunto, ya que solo es una de las piezas que componen el puzzle de la seguridad. Su objetivo es ofrecer resistencia frente a determinados modelos de amenaza.
En particular, BitLocker se centra en la pérdida o el robo de equipos portátiles. Los trabajadores móviles manejan todo tipo de información confidencial en diferentes lugares: trenes, aviones, restaurantes, hoteles, oficinas de la empresa y sucursales. Esta información la transportan en equipos portátiles y otros dispositivos móviles que suelen carecen de una seguridad real, por lo que los datos que contienen son muy vulnerables. ¿Qué pasa con los datos cuando uno de los usuarios se deja un equipo portátil en algún lugar?
Esta claro que no se pueden evitar los descuidos de la naturaleza humana. Por suerte, se pueden limitar las consecuencias negativas derivadas. Para una empresa, el costo de reemplazar un equipo portátil es pequeño, comparado con el costo de la pérdida de datos confidenciales. Es ésta la seguridad que BitLocker pretende ofrecer.

Más allá de los créditos
Estoy analizando BitLocker desde una perspectiva interesante porque todavía no lo he probado. Sé lo que estará pensando: ¿cómo es posible que alguien que no ha usado nunca BitLocker opine sobre él y que además diga algo útil sobre el tema? Siga leyendo. Lo que quiero analizar en realidad es la criptografía desde un nivel más alto y las filosofías de diseño que son importantes para obtener una solución satisfactoria.
Toda la historia empezó cuando leí el blog de Bruce Schneier. Supongamos que desea ver una película nueva. A partir del trailer y los actores principales del reparto ya ha sacado algunas conclusiones sobre la película. Es cierto que un buen reparto no garantiza que la película sea buena. Sin embargo, la lista del reparto puede decir mucho acerca de la película y de lo que se puede esperar de ella. Por ejemplo, no será lo mismo una película en la que aparezcan Chris Rock y Ben Stiller que una de Kate Winslet y Johnny Depp.
Del mismo modo, cuando comprobé que un gurú de la seguridad respetado a escala internacional analizaba BitLocker en su blog, saqué algunas conclusiones. Primero pensé que esta tecnología debía ser lo suficientemente buena para merecer un comentario tan respetuoso o bien, tan absolutamente nefasta que era necesario hacerlo público. Para mi sorpresa, la opinión de Bruce Schneier era positiva.
Había una frase en particular que destacaba en su crítica: "No tiene puertas traseras para la policía". Esta declaración tiene mucho alcance; se expresaba con gran confianza y se incluía un vínculo al blog del equipo de integridad de sistema de Microsoft®. Seguí el vínculo y encontré un artículo de Niels Ferguson, un desarrollador de Microsoft especializado en seguridad, en el que se denunciaban los rumores especulativos de que Microsoft había incluido en BitLocker puertas traseras de forma intencionada por motivos legales. Ferguson declaraba abiertamente que las puertas traseras son inaceptables y que no formaría parte de un proyecto que las admitiera. Además explicaba que aunque Microsoft estuviera obligado a incluir una puerta trasera por ley, la empresa anunciaría la puerta trasera, o bien, retiraría completamente dicha característica.
El nombre que aparecía en el artículo, Niels Ferguson, explica la confianza de Schneier y también la mía. Ferguson sabe de lo que habla y tiene un historial que garantiza que se puede confiar en lo que dice. Bruce Schneier y Niels Ferguson son coautores de Practical Cryptography (una obra imprescindible acerca de la aplicación de criptografía de calidad de forma sencilla, correcta y segura) y codiseñadores del cifrado de bloques Twofish, una red Feistel de 128 bits, que se ganó la denominación de red criptoanalítica por quedar finalista en el proceso de selección del Estándar de cifrado avanzado (AES).
Por supuesto, tener un criptógrafo veterano en un proyecto no garantiza que el producto final será seguro. Incluso los maestros de esta arte en ocasiones pueden dejar pasar algún trazo. Pero con independencia del éxito que pueda llegar a tener BitLocker con el tiempo, al menos puede estar seguro de que en su creación se han usado estrategias de diseño solventes.
Si hay que hablar de intentos fallidos, hay que mencionar los intentos realizados con buena fe por desarrolladores que no tienen ni una pizca de sentido criptográfico y los intentos realizados con mala fe de aquéllos cuya única preocupación es sacar un producto al mercado. Ambas posibilidades, con independencia de las distintas intenciones de cada una de ellas, suponen fracasos para la seguridad en preparación. Sin embargo, no parece que éste sea el caso de BitLocker. La intervención de al menos un criptógrafo competente y la existencia de amplios recursos para apoyar el esfuerzo, es una perfecta combinación.

Unas palabras sobre la confianza
Hace poco, Phil Zimmerman, creador del cifrado de PGP, compartió algunos principios generales conmigo. Si alguna vez se confeccionara un "Credo de la seguridad para desarrolladores", sus consejos seguramente figurarían en uno de los lugares destacados. Aunque sus declaraciones no pretendían centrarse en BitLocker, las filosofías de diseño que promueven se pueden aplicar a la mayoría de las soluciones criptográficas. Es posible que las encuentre demasiado obvias o entusiastas, pero dado el estado de la seguridad de hoy en día, vale la pena describirlas explícitamente.
Al diseñar una infraestructura criptográfica, el desarrollador debe actuar de forma sencilla, correcta y segura. Aunque los errores son inevitables, no se deben aceptar con normalidad sin darles importancia. El desarrollador debe ser un incondicional del perfeccionismo meticuloso. En palabras de Zimmerman, "diseña como si cometer un error costará la vida de alguien". ¿Cree que es una exageración? En el congreso anual de 2005 sobre aplicaciones de seguridad para equipos, el criptógrafo Brian Snow, de la NSA, que ahora está jubilado, dijo: "En un dispositivo de seguridad, lo que busco son funciones y garantías. No se puede usar el cliente para probar la versión beta. Si mi producto falla, alguien podría morir". Así que recuerde: los errores pueden acarrear algo más que un simple costo económico.
Los usuarios tienen derecho a que existan garantías. Ganar la confianza de los usuarios (y mantenerla) es esencial. Zimmerman lo dice alto y claro: "Gánese la confianza de los usuarios. En cuanto asuma esa carga, ya no podrá desprenderse de ella". De esta forma, la empresa conserva la confianza del usuario y su propia reputación en cuanto a la seguridad. Si se pierden estos dos elementos, es posible que sean irrecuperables.
Espero que éstas sean las perspectivas que haya tenido presente Microsoft al diseñar BitLocker (o cualquiera de los demás productos en esta materia). Dicho esto, ahora explicaré por qué creo que Microsoft ha seguido estas premisas y ha conseguido una tecnología criptográfica que se debe tomar en serio.

Poor-man y Elephant
En esencia, BitLocker es ser la forma que usa Windows Vista para cifrar todos los datos de volumen del sistema (especialmente, en las ediciones Enterprise y Ultimate). Puede parecer que se trate de una aplicación sencilla, pero hay tener en cuenta las restricciones existentes. Debido a que BitLocker cifra los datos por sector y el texto cifrado no puede superar la longitud del texto sin formato, no hay espacio para nada más, como por ejemplo, el nonce (valor de seguridad, que puede ser número o cadena, y que se usa sólo una vez para la autenticación), el un vector de inicialización (IV) o el código de autenticación de mensajes (MAC). Preví que dichas estrictas restricciones y las condiciones que imponen son posibles, sin embargo, también sabía que la autenticación de ese mensaje se debería tener en cuenta de alguna manera.
BitLocker depende de lo que habitualmente se llama autenticación económica. El riesgo no es lo conservador que debería, porque asume que el texto cifrado manipulado no tiene como resultado texto sin formato significativo. Es decir, si se manipula el texto cifrado se bloqueará el sistema por ejemplo, en lugar de permitir que un adversario lleve a cabo alguna función.
El equipo de Microsoft responsable de BitLocker sabía que el nuevo cifrado de bloques necesitaría más tiempo del aceptable para realizar el análisis, pero los diseños existentes todavía no se habían analizado lo suficiente o bien no eran lo bastante eficaces. Por ello, Microsoft eligió AES (estándar de cifrado avanzado) en modo CBC (encadenamiento de bloques de cifrado) para el cifrado, al que haré referencia como AES-CBC. Esto no se puede distinguir en el modelo elegido de ataque de texto sin formato (abreviado, IND-CPA) y, además, no protege la integridad. Asimismo, debido a que no hay espacio para un MAC, y CBC es un modo de confidencialidad, no se protege la integridad. Hay que ponerse en la cola de Elephant para entrar.
El nuevo componente Elephant tiene dos difusores creados para procesar autenticación económica mejor que como lo hace el AES-CBC sin formato. Sin embargo, hay que recalcar que existe una opción para ejecutar el AES-CBC sin Elephant para quienes deban ajustarse a las estrictas directivas de cumplimiento de estándares. Aunque no siempre es ideal, la autenticación económica es la solución más conveniente dadas las restricciones existentes, y Elephant se propone sacar lo mejor de la situación. ¿Cómo funciona todo esto exactamente?
En la figura 1 se ilustra el flujo de datos. Cuando se lleva a cabo el cifrado, el texto sin formato se combina a través de XOR, con una clave de sector. A continuación, el texto fluye a través de dos difusores sin clave. A partir de ahí, el texto se cifra mediante AES-CBC. La clave de sector y AES-CBC requieren el material de clave y, por lo tanto, se les aplica claves por separado. Este método simplifica la formalización de una prueba para reducir la seguridad de la creación de AES-CBC y Elephant a la de AES-CBC. Elephant es un primitivo nuevo y es posible que haya resistencia a su aplicación hasta que se haya analizado rigurosamente. Pero este método equilibra la escala ya que BitLocker puede demostrar que AES-CBC con Elephant no es tan vulnerable como AES-CBC por sí solo.
Figura 1 La autenticación económica con Elephant
Figura 1 La autenticación económica con Elephant
La clave de sector y los componentes de AES-CBC reciben 256 bits de material de clave cada uno, por lo que la longitud de la clave tiene un total de 512 bits. Sin embargo, de forma predeterminada, cada uno de los componentes solo usa 128 bits del material de clave, por lo que no se usa parte de dicho material. La razón es que resulta más sencillo eliminar los bits que no son necesarios que cambiar la infraestructura de administración de claves ya que la longitud de éstas puede variar.
La longitud del bloque puede ser cualquier potencia de dos, dentro del intervalo comprendido entre los 512 y los 8.192 bytes. Para garantizar que cualquier modificación del texto cifrado tenga como resultado la modificación aleatoria de todo el texto sin formato del sector, el cifrado de bloques está diseñado para reaccionar en función de este tamaño de bloque variable. Además, si se comporta como un cifrado de bloques modificable (tal como lo describen Liskov, Rivest y Wagner), y el algoritmo cambia ligeramente entre sector y sector, un adversario no podrá mover correctamente un texto cifrado de un sector a otro.

El tiempo lo dirá
Al especular acerca del árbol de la seguridad criptográfica de BitLocker se pierde la noción de todo el bosque del proyecto. Para BitLocker, la seguridad no es suficiente para funcionar, ya que BitLocker no es una solución independiente, si no uno de los apéndices de Windows Vista. Microsoft afirma que BitLocker está integrado perfectamente en Windows Vista. Pero si está perfecta integración con el sistema operativo es real, ¿no es posible que el error de otro componente pueda provocar un error en BitLocker o ponerlo en peligro?
Personalmente, soy partidario del trabajo por módulos y del aislamiento de errores. La integración total sin modularidad implica complejidad. De acuerdo, es posible que éste no sea el caso de Windows Vista y BitLocker, pero sólo el tiempo y un análisis exhaustivo lo dirán.
Entonces, ¿qué opino de BitLocker? Me quito el sombrero ante el equipo de integridad del sistema de Microsoft por confiar en criptógrafos auténticos y confiables, que han trabajado como deben hacerlo los criptógrafos. Es obvio que esta característica se ha diseñado en aras de la criptografía y no de una campaña de marketing. Por tanto, mi respuesta es que BitLocker se debe tomar en serio. Tenga en cuenta que esto deja a un lado la opinión acerca de la perfección de su seguridad. De nuevo, lo dirá el tiempo y su evaluación en el mundo real. Se han roto muchos protocolos y primitivos criptográficos, pero como mínimo, el equipo de integridad del sistema de Microsoft nos ha proporcionado información y plataformas en las que crear soluciones aún mejores.

Justin Troutman es un criptógrafo en aprendizaje y estudiante universitario de matemáticas. Su trabajo se centra principalmente en la criptografía simétrica. Además es el fundador de Extorque, empresa especializada en la investigación y la consultoría criptográficas.


 Archivos del escritorio: Gu&#237;a del usuario avanzado para WIM e ImageX
Archivos del escritorio
Guía del usuario avanzado para WIM e ImageX
Wes Miller
Este artículo se basa en una versión de preliminar del Kit de instalación automatizada de Windows (WAIK) y Windows Server 2008. Por tanto, toda la información de este documento está sujeta a cambios.

En varios de mis artículos anteriores he escrito sobre ImageX y el formato de imagen de Windows (WIM). Hace algunos meses, en Tech•Ed escuché algunos de los comentarios y preguntas de los profesionales de TI que comenzaban a usar los Servicios de implementación de Windows (WDS), ImageX y el Kit de instalación automatizada de Windows (WAIK) y constaté
que había que los usuarios necesitaban más información. De modo que en el artículo de este mes me gustaría centrarme en ImageX y el formato WIM, y en cómo sacar el máximo provecho de éstos. Juntos, ImageX y WIM le permiten implementar fácilmente no sólo Windows Vista® y Windows Server® 2008, sino además Windows® XP, Windows Server 2003 y Windows 2000.

Cambios en WAIK
El próxima versión de Windows Server 2008 quizás le haga preguntarse qué esto para WAIK. Microsoft planea lanzar al mercado una versión actualizada del WAIK en el mismo período que la versión Windows Server 2008. No hay cambios considerables en el formato WIM (la herramienta ImageX y el formato permanecen sin cambios); tampoco cambia WDS para Windows Server 2003. Al contrario de lo que dicen los rumores, la multidifusión no estará disponible en WDS de Windows Server 2003; sólo los servidores de WDS que ejecutan Windows Server 2008 tendrán la nueva capacidad de implementación de multidifusión para WDS.
Windows PE 2.0 y la instalación de Windows se revisarán para que sean compatibles con:
  • Implementación de Windows Server 2008 y Windows Vista.
  • Implementación de multidifusión mediante WDS desde un servidor WDS de Windows Server 2008.
  • Implementación de versiones x64, así como de versiones x86 de Windows Vista y Windows Server 2008 desde Windows PE x86.
En primer lugar, esto significa que Windows PE 2.0 podrá implementar Windows Server 2008 tan fácilmente como lo hace con Windows Vista; las mismas herramientas y procesos funcionan igual tanto en uno como en el otro. En segundo lugar, podrá usar la implementación de multidifusión mediante WDS una vez que sus servidores WDS se ejecuten en Windows Server 2008. Por último, esto significa que tendrá la capacidad de usar un disco de Windows PE 2 .0 x86 e implementar desde dicho disco una imagen x86 o x64 de Windows.
Mencioné este último punto en Tech•Ed en mi sesión sobre Windows x64. Desafortunadamente, ha habido alguna confusión en torno a este punto en los blogs y en la comunidad técnica de Windows. Esto no significa que Microsoft distribuirá Windows x64 y Windows x86 en cada DVD de Windows Vista o Windows Server 2008. Tampoco significa que debe combinar las imágenes de Windows x64 y Windows x86 en un único archivo WIM (aunque puede hacerlo). Al hacerlo de este modo no se ahorra el espacio de almacenamiento que se consigue ahorrar con una instancia única, pero WIM puede viajar en un único archivo.
Esto significa que los clientes de empresa y los OEM que dedicaron varios años al desarrollo de procesos de implementación basados en x86 (y scripts y herramientas personalizadas) ahora podrán implementar Windows x86 o x64 en WIM mediante una instalación de 32 bits, algo que los clientes corporativos vienen solicitando desde que se presentó Windows x64 en 2005.

ImageX en el día a día
Uso de /mount, /mountrw y /delete
A continuación se ofrecen algunas sugerencias muy útiles para usar los modificadores de comandos /mount, /mountrw y /delete con ImageX:
  • Monte un volumen con /mountrw si piensa editarlo.
  • Debe montar WIM en un directorio vacío, simplemente para eliminar la confusión de cualquier archivo almacenado allí y evitar que ImageX genere mensajes de advertencia innecesarios.
  • No olvide hacer usar /unmount /commit en su imagen de lectura/escritura si desea guardar los cambios realizados. En mi caso, frecuentemente realizaba cambios y más tarde olvidaba confirmarlos (por lo que los perdía).
  • La eliminación de archivos con /mountrw y la eliminación de imágenes de volumen con /delete no recupera ningún espacio; en realidad, puede incluso llegar a ocupar más espacio. Consulte en este artículo la sección sobre /export para obtener información más detallada.
  • Sólo se puede montar un único archivo WIM una vez para acceso de lectura/escritura. Dos usuarios no pueden editar el mismo WIM a la vez, y no se pueden editar dos imágenes de volumen a la vez.
  • Aún en modo de sólo lectura (/mount), se debe limitar el número de imágenes de volumen que se montan de manera simultánea, porque el controlador depende de la cantidad de memoria de bloque no paginado de Windows disponible en el sistema para cada imagen montada. El resultado es un límite que puede variar en función del sistema (o de la arquitectura del sistema). Mi sugerencia es no probar con más de cinco imágenes de manera simultánea.
  • Las ediciones importantes a través de /mountrw prácticamente no consumen nada de tiempo cuando se realizan los cambios, pero pueden provocar que /commit necesite mucho tiempo, y que se deberán comprimir y almacenar los nuevos datos del archivo.
  • Use /delete y /mountrw con cuidado ya que, una vez que se confirman los cambios, no se pueden deshacer.
  • Cuando en un archivo WIM sólo existe una imagen de volumen, no se puede ejecutar /delete (en su lugar, elimine la totalidad del archivo WIM o anexe otra imagen de volumen).
  • Para obtener rápidamente un árbol de directorios del contenido de una imagen de volumen, en lugar de /mount use el comando siguiente:
ImageX /dir <path_to_wim_file> <image index>
  • Si edita dos archivos WIM al mismo tiempo, intente no usar /unmount en los dos a la vez; ejecute los eventos mount/unmount de forma secuencial para que no se bloqueen entre sí.

ImageX se diseñó específicamente para reflejar la manera en que los clientes OEM y de empresa afirman que usan las herramientas. La figura 1 muestra este proceso.
Figura 1 Uso de ImageX
Figura 1 Uso de ImageX
Hay que señalar que el paso cinco es crítico: la realidad es que una imagen cambia constantemente. Por lo tanto, la captura y modificación de la imagen necesita ser lo más rápida y fácil posible.
Con esa finalidad, puede anexar una imagen adicional (mediante el modificador de comandos /append) a una imagen ya creada. Inicialmente, el equipo de desarrollo pensó que desearía agregar un SKU adicional (una versión de Windows) a su imagen anterior, pero cuanto más trabajaba con los clientes corporativos en los comienzos del desarrollo de Windows Vista, más escuchaba que se estaba usando para implementar rápidamente X, y después volver a capturar X1, donde había realizado alguna de las modificaciones del paso 2. Esto permitía volver a capturar la imagen con rapidez, dado que sólo se modificaba un número limitado de archivos.
Cuando el equipo lo comprendió, se dio cuenta de que quizás no tenía sentido mantener la imagen original en todas las situaciones. Un poco más adelante explicaré el modificador de comandos /export que se agregó específicamente debido a este escenario y el siguiente.

El cambio es constante
Desde el principio, el equipo de desarrollo decidió que los archivos WIM pudieran editarse. Como ya habían decidido que un formato de procesamiento de imágenes basado en sectores no funcionaría (consulte el artículo de diciembre 2006 en technetmagazine.com/issues/2006/12/DesktopFiles si desea ver una explicación), los miembros del equipo tenían que entregar una solución que lograra montar con facilidad los archivos de forma nativa, como una parte del sistema de archivos de Windows, y realizar cambios en las imágenes de volumen montadas en el archivo WIM. Esto significaba que existirían algunas "partes móviles" más, como me gusta denominarlas. Montar una imagen basada en sectores es relativamente fácil, pero montar un formato de archivo propietario como WIM requería algunas herramientas muy específicas.
El formato necesitaba acceso desde el indicador de comandos, y excluir Windows Shell Extensions que se usa con frecuencia para administrar los archivos ZIP y CAB de forma nativa. Desafortunadamente, estos controladores sólo permiten un acceso abstracto del Explorador de Windows a un objeto.
Como resultado, la solución WIM implica un controlador (wimfltr.sys) e ImageX, que sirve como método para en realidad cargar el controlador y administrar la interfaz para montar el WIM. El controlador sirve para agregar una abstracción al sistema de archivos de Windows, como se muestra en la figura 2. Cada vez que ejecuta un comando como éstos, le indica a ImageX que debe cargar el controlador wimfltr.sys y hacer que el controlador superponga la primera imagen de volumen (la imagen 1 en los comandos usados aquí) en el montaje de directorio vacío, como puede verse a continuación:
Figura 2 Montaje de una imagen de volumen WIM
Figura 2 Montaje de una imagen de volumen WIM
ImageX /mount iso\sources\boot.wim 1 mount
ImageX /mountrw iso\sources\boot.wim 1 mount
Este es el comportamiento predeterminado en WAIK. Por lo tanto, si explora o genera una lista de directorios en el directorio de montaje, puede ver la raíz de la imagen de volumen 1 en boot.wim. Por supuesto, el uso de /mountrw o /mount determinará si este directorio es de lectura/escritura o de sólo lectura (consulte la barra lateral "Uso de /mount, /mountrw y /delete" para obtener más información).
La capacidad de /mountrw se diseñó e en principio para agregar con facilidad controladores u otros archivos o contenido que se copian con xcopy, configurar archivos de respuesta o modificar el registro sin conexión de un archivo de WIM montado para modificarlo según sea necesario (vea la figura 3). No se diseñó para hacer que se agreguen o eliminen aplicaciones completas (dado que las aplicaciones instaladas de MSI no se pueden instalar sin conexión).
Figura 3 Modificación de un archivo WIM montado
Figura 3 Modificación de un archivo WIM montado
Es esencial entender que mientras realiza cambios en el archivo WIM cuando está montado no cambia directamente el archivo WIM mismo (al menos no de inmediato) sino que cambia una memoria caché del archivo WIM que es, en realidad, una combinación de la superposición y los cambios realizados. Como explico en la barra lateral, ya experimenté antes este problema. Una vez que finalice, asegúrese de usar los modificadores de comandos /unmount y /commit, porque sólo entonces sus cambios se confirmarán en el archivo WIM. De lo contrario, se perderán por completo.
Cuando guarda sus cambios confirmándolos, le indica al controlador que realice los cambios en el propio archivo WIM. El controlador agrega los datos adicionales del archivo. Tenga en cuenta que si ha realizado muchos cambios, significa que /commit puede necesitar mucho tiempo, dado que sólo entonces se agregan al WIM los datos del archivo.
Además, a diferencia de los que sucede en un formato de procesamiento imágenes basado en sectores, es posible que haya cambiado uno o varios archivos en la imagen de volumen. Como resultado, los archivos ya no tienen una instancia única (a menos que este mismo archivo ya se haya almacenado otra vez) y se perderán los datos del archivo original. WIM, a diferencia de un volumen NTFS o FAT, no marca un archivo como eliminado (ya no hace referencia a él pero no lo limpia). Como resultado, si hace ediciones frecuentes con /mountrw, anexa con /append muchas imágenes o usa /delete para eliminar una imagen de volumen, lo único que hace el archivo WIM es olvidar las referencias a los datos del archivo, pero no quita por completo los datos de archivo relacionados.
Por ello, el equipo de desarrollo creó el modificador de comandos /export, que también se conoce en cierto sentido como el "desfragmentador de WIM".

Exportación
Notas importantes sobre /export
Cuando se usa /export para crear un nuevo archivo WIM, se puede especificar qué tipo de compresión usar en lugar de aceptar el tipo de compresión predeterminado usado actualmente. Si cambia el tipo de compresión actual, es posible que la exportación necesite mucho tiempo.
Cuando se usa de forma equivalente a /append (mediante la adición de una imagen de volumen a un archivo WIM existente), /export no permite modificar el atributo /compression del archivo WIM.
Si exporta una imagen de volumen de Windows PE 2.0 totalmente nueva, puede especificar el modificador de comandos /boot.

El modificador de comandos /export se crea en respuesta a los escenarios mencionados anteriormente, y a unos cuantos escenarios más esotéricos detectados por el equipo. En pocas palabras, /export permite tomar una imagen de volumen existente (dos o tres) y exportarla. Esto significa tomar rápidamente los archivos WIM X y X1 anteriores y crear un nuevo WIM sólo con X, sólo con X1, o con X1 e Y1 mediante la exportación a partir de otro archivo WIM.
Imagine un escenario en que realiza modificaciones a X y anexa los cambios con /append como X1. Decide que desea eliminar X dado que lo ha sustituido con su nueva imagen para este trimestre. Puede usar el modificador de comandos /delete e ImageX se olvidará de la imagen X. Sin embargo, para ahorrar espacio y eliminar toda la información relacionada con X, debe ejecutar este comando:
ImageX /export source.wim 2 destination.wim "New image for Q4CY07"
De este modo exportará la segunda imagen de volumen a un nuevo archivo WIM con el nuevo nombre y eliminará por completo la información anterior de la imagen de volumen 1. También puede exportar imágenes WIM distribuidas si desea reensamblarlas en un archivo WIM (como analizaré posteriormente en este artículo). Las imágenes distribuidas no se pueden editar mediante /mountrw, lo cual puede ser un motivo reensamblarlas. Es importante tener en cuenta que no existe un comando /import para ImageX porque /export puede crear nuevos archivos WIM o anexarse a archivos existentes. Consulte la barra lateral "Notas importantes sobre /export" para obtener información adicional sobre este tema.
Esta cuestión también es crucial si ejecuta peimg /prep: aunque este comando prepara la imagen de Windows PE para su uso, no realiza ninguna limpieza en WIM. Lo ideal es que, como parte del proceso de lanzamiento de Windows PE, prepare la imagen y, a continuación, la exporte a un nuevo archivo boot.wim. Tenga en cuenta que el proceso de arranque sólo sabe buscar en \sources\boot.wim el archivo WIM, así que asegúrese que su nombre sea correcto y que esté marcado como una imagen de volumen de arranque.
He mencionado que probablemente desee optimizar sus imágenes a través de la ejecución de /export en ellas cuando esté preparado para retirar de servicio las antiguas imágenes de volumen, o combinar varias imágenes juntas. También deseará hacerlo si realizó numerosas ediciones con /mountrw o /delete. En caso contrario, su archivo WIM continuará creciendo con el tiempo (de maneras misteriosas que no podrá diagnosticar). Si usa /mountrw o /delete con regularidad, considere agregar /export en su flujo de trabajo para garantizar que sus imágenes están totalmente optimizadas.

Expansión
Desde el principio, otro problema que surgió fue la probable necesidad de que los archivos WIM se ajustasen en múltiples partes de medios brillantes. Anticipamos que Windows se entregaría en varios CD (y posiblemente en DVD, como pasó) y, como resultado, incorporo la compatibilidad de expansión en WIM y ImageX.
Como mencioné, una imagen distribuida que se crea mediante /split es básicamente de sólo lectura; no se puede realizar /capture directamente en una nueva imagen distribuida, no se puede montar mediante ImageX y no se puede anexar mediante /append. Por tanto, recomiendo que divida su archivo WIM sólo después de que termine su flujo estándar de trabajo y esté listo para realizar el lanzamiento. Es decir, realice todas sus ediciones en el archivo WIM normal y considere la posibilidad de dividirlo, como parte del proceso del lanzamiento para su escenario de implementación.
En lo que se refiere a la aplicación de la imagen, las imágenes distribuidas pueden suponer un desafío. Sugiero usar ImageX en lugar del programa de instalación cuando se usan imágenes distribuidas. También recomiendo aplicar las imágenes a través de la red (para obtener un óptimo rendimiento, sin crear una imagen del disco a partir del cuál se aplican) o bien copiarlas directamente a la unidad de disco y aplicarlas después (teniendo en cuenta que estará enlazada al disco, dado que el disco se lee y escribe en el momento de aplicar la imagen).

Búsqueda de validación
Cuando usa ImageX, mueve muchos datos que, además, son muy importantes. Una pregunta frecuente que este año escuché en Tech•Ed fue: "¿Cómo puedo asegurarme de que mis imágenes son válidas?" Pues ni es pan comido ni resulta tampoco tan difícil.
Lo más importante que debe entender acerca de WIM es que, como la mayoría de los formatos de archivo, es susceptible de dañarse. La mayoría de las veces este daño se produce cuando un archivo WIM se transmite a través de la red. Desde el principio en Windows Vista, vimos problemas específicos con tarjetas de red específicas: si eliminaban paquetes, el archivo WIM se dañaba, y no siempre de una manera fácil de diagnosticar. Esta situación reflejaba en realidad lo que hubiera sucedido años antes cuando el archivo driver.cab aumentaba de tamaño: se dañaba de forma aleatoria también. Generalmente, cuando se obtienen informes de imágenes incorrectas o de errores de instalación, se desea comprobar qué tipo de NIC está en uso en los sistemas que generan los informes. Esto sucede tanto si usa ImageX por separado como si ejecuta WDS.
Así que ¿cómo se puede comprobar si una imagen está en buen estado o no? Primero, puede usar el modificador de comandos /check. De este modo se guardan comprobaciones de integridad adicionales en el archivo WIM y se comprueba, antes de su aplicación, que WIM no se haya dañado. Asegúrese de ejecutar también /check en el momento de aplicar la imagen, con lo cuál se validará (aunque este proceso lleva más tiempo).
Además, si tiene problemas, o simplemente si desea ser meticuloso, puede ejecutar una utilidad de operaciones hash en los archivos antes de las capturas y después de la aplicación. Puede también realizar la comprobación después de la captura si monta la imagen y vuelve a realizar la operación hash; ésta es una buena forma de garantizar la captura correcta de la imagen.
Deseará garantizar que sus imágenes se capturan de manera correcta desde el principio. El modificador de comandos /check y el propio formato están diseñados como puntos de control, no como herramientas de recuperación para reparar una imagen capturada de manera incorrecta.

Arranque y marcadores
Mencioné anteriormente que puede usar /boot para capturar una imagen de volumen WIM de Windows PE y arrancarla. Debe considerarse simplemente como un sector de arranque en una imagen de volumen determinada. Sólo puede existir en una única imagen de volumen por WIM y sólo es válido en Windows PE 2.0. Tenga en cuenta que no puede arrancar Windows PE 1.x con WIM: es sencillamente imposible.
Es posible que en las imágenes de volumen de Windows vea referencias a marcadores. Sólo la instalación de Windows usa marcadores. Un marcador 2 en una imagen de volumen significa que una imagen de volumen que contiene Windows PE y la instalación. Un marcador 9 significa que sólo contiene Windows PE. Cualquier otro marcador o la ausencia de un marcador significa que la instalación no usará ni debe usar la imagen. Debe tener en cuenta que puede establecer marcadores en una imagen después de que se haya capturado y usar ImageX para modificarlos. Recomiendo usar WAIK (y opcionalmente Business Desktop Deployment Solution Accelerator) para crear su imagen WIM de arranque de Windows PE porque, para empezar, los marcadores se establecerán correctamente.

Una nota para usuarios de HTA
Recientemente me he enterado de que se ha comunicado la existencia de problemas con la ejecución de archivos HTA en Windows PE 2.0. Desafortunadamente, parece ser un problema de los archivos HTA que contienen un volumen de scripting considerable. En la figura 4, examine la captura de pantalla del archivo de ejemplo creado y observe el error de scripting devuelto (que no contiene información). Varios clientes notificaron este problema y yo mismo lo experimenté.
Figura 4 Error de scripting de HTA
Figura 4 Error de scripting de HTA
Afortunadamente, la solución es relativamente fácil. Al preparar su imagen, agregue compatibilidad XML así como compatibilidad HTA. La dependencia que falta en el componente HTA parece estar incluida en el módulo del complemento XML, con lo cual se resuelve este problema.
Me gustaría dar las gracias a Bruce Green, desarrollador de ImageX, y a Minxiao Zhou y Raja Ganjikunta del Equipo de pruebas de implementación de Windows por su ayuda en este artículo.

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


 Notas de campo: Recicle su PC
Notas de campo
Recicle su PC
Jim Lynch

La comunidad El programa Microsoft Authorized Refurbisher (MAR, microsoft.com/mar) es un proyecto extraordinario y relativamente desconocido, iniciativa de Microsoft Unlimited Potential, en el que Microsoft ofrece soporte técnico a diferentes proyectos para mejorar la educación, crear negocios y trabajos, además de generar oportunidades económicas sostenibles para muchos colectivos que carecen de un servicio adecuado. El programa Community MAR, iniciado en 2000 en el Reino Unido, se compone de más de 800 PC de renovación en 50 países de todo el mundo.
Uno de los aspectos más asombrosos del programa Community MAR es que puede suministrar licencias para Windows® 2000 y Windows XP por tan solo cinco dólares estadounidenses. MAR ha suministrado estas licencias, más de 200.000 en un año, para los PCs de renovación de organizaciones no lucrativas, escuelas, bibliotecas, universidades y, en EE. UU., programas de acceso a la tecnología para particulares con ingresos bajos o minusválidos. De este modo, Community MAR llega a los que se encuentran en el lado equivocado de la división digital y ofrece acceso a oportunidades educativas y laborales.
Con la intención de llegar a los niños que carecen de servicios, Community MAR abarca todo el mundo. Por ejemplo, Operation Homelink suministra equipos a familias militares de EE. UU. con bajos ingresos; Computer Aid International del Reino Unido es la organización no gubernamental más grande y suministra equipos a África; y la red de renovación Computers for Schools Canada suministra una parte significativa de los equipos que se encuentran en las escuelas canadienses.
El valor de la reutilización
La EPA (Agencia para la Protección del Medio Ambiente de EE. UU.) en colaboración con la Universidad de Tennessee ha demostrado recientemente el valor de la reutilización de la electrónica en términos de energía, materiales, emisiones de CO2y emisiones tóxicas. Según su programa de cálculo electrónico de prestaciones ambientales (eerc.ra.utk.edu/ccpct/eebc/eebc.html), la reutilización de un solo equipo con un monitor CRT ahorra:
  • 13,5 kg de desecho peligroso
  • 35 kg de desecho sólido
  • 35 kg de materiales
  • 67 kg (66,25 litros) de agua contaminada
  • 32 toneladas de aire contaminado
  • 604 kg de emisiones2 de CO
  • 7.719 kilovatios de energía

De hecho, el programa Community MAR se inició en 2000 para aumentar el flujo de equipos de trabajo en escuelas y organizaciones benéficas en el Reino Unido con acceso limitado a la tecnología. El programa se ha ampliado a EE. UU. y Australia en 2003 y se internacionalizó en 2005. Ahora está disponible para todo tipo de renovaciones: comerciales, no comerciales, gubernamentales y escolares. Mientras tanto, también ha creado un sector de reutilización y renovación de equipos en expansión.
Una de las prestaciones menos visibles del programa Community MAR es la ambiental. Ampliar la vida de los equipos electrónicos es la forma más eficaz de reciclar porque conserva el máximo nivel de funcionamiento de los dispositivos y genera las recompensas económicas, ambientales y sociales más altas. El reciclaje al final de la vida útil de un producto es, ciertamente, bueno y necesario, pero no evita la pérdida de entre el 10 y el 30 por ciento de los materiales y la energía existente en cada uno de los artículos.
No es sorprendente que la fabricación de equipos tenga un alto costo ambiental. Según el científico ambiental Eric D. Williams de Arizona State University, en la fabricación del equipo de escritorio y monitor medios de 24 kg se necesitan 240 kg de combustibles fósiles, 22,7 kg de sustancias químicas y 1.550 kg de agua. Ampliar su vida durante dos o tres años ahorra de 5 a 20 veces más energía que el reciclaje al final de la vida útil en relación con el ciclo de vida del equipo (consulte la barra lateral "El valor de la reutilización" para consultar otras cifras que le sorprenderán).
En términos generales, a través de este programa innovador, Microsoft ayuda a crear oportunidades que pueden transformar las comunidades aportando prestaciones tecnológicas a las personas que las necesitan. Otra prestación sorprendente es que el programa Community MAR ha aumentado la concienciación pública y el apoyo a la reutilización de equipos.

Jim Lynch es director del programa de reciclaje y reutilización de equipos en TechSoup.org, una empresa no lucrativa con sede en San Francisco cuyo objetivo es suministrar hardware, software y conocimientos de muy bajo costo a organizaciones benéficas de todo el mundo.


 Confidencial de Windows: Llamada al Dr. Watson
Confidencial de Windows
Llamada al Dr. Watson
Raymond Chen

Es posible que haya observado que si solicita a Dr. Watson (drwtsn32.exe) que haga un volcado de la memoria del proceso Winlogon, Windows® se apaga en cuanto finaliza dicha operación. Algunas personas se preguntan, "¿por qué conectar un depurador para que Winlogon detenga todo el sistema?"
En realidad esto no es así. Ejecutar Dr. Watson en un proceso no es lo mismo que conectar un depurador a un proceso. La conexión de un depurador implica el uso de un programa como ntsd, y funciona correctamente, si tiene los privilegios necesarios. En realidad, este es el modo en que el equipo de Windows depura los problemas con Winlogon. Así que la respuesta literal a esta pregunta es: "la conexión de un depurador a Winlogon no detiene el sistema".
Pero Dr. Watson es un médico forense, no un médico general y primero toma un volcado de memoria de un proceso problemático, y después detiene dicho proceso. Como el Dr. Watson no intenta en realidad solucionar el problema, si permitiera que el proceso se siga ejecutando, ese proceso simplemente se volvería a bloquear. Y enseguida llamaría al médico para que volviera a entrar, lo que conduciría a un bucle infinito. En cierto sentido, Dr. Watson es un depurador que en realidad no realiza ninguna depuración. Un médico eficiente simplemente aparece en la escena, toma notas cuidadosamente, y después detiene el proceso. Y es precisamente esto, eliminar Winlogon después de tomar el volcado de la memoria, lo que hace que el sistema se bloquee.
Si detiene Winlogon, su sistema se rearrancará
Si detiene Winlogon, su sistema se rearrancará
Winlogon es lo que se conoce como un "proceso crítico de sistema" y la muerte de un proceso crítico fuerza el reinicio del sistema. ¿Por qué el sistema considera a Winlogon crítico para su funcionamiento? En primer lugar, Winlogon es responsable de administrar la secuencia de aviso de seguridad, Ctrl+Alt+Supr. Si Winlogon muere, la secuencia de aviso de seguridad deja de funcionar. Lo cuál, en sí, ya es negativo. Lo que agrava el problema es que dada la ausencia del vigilante oficial de la secuencia de aviso de seguridad, lo único que puede hacer cualquier otro programa es esperar a que el usuario presione Ctrl+Alt+Supr y mostrar en respuesta un diálogo de contraseña falso. ¡No sería una secuencia de aviso de seguridad muy buena si su identidad pudiera ser suplantada! Como una medida protectora, Windows se apaga antes de que la situación negativa se vuelva peor.
Ahora, si ejecuta el Administrador de tareas, resalte un proceso crítico de sistema como Winlogon, haga clic en Finalizar proceso, confirme y, vaya, acaba de eliminar Winlogon y el sistema se rearrancará (se supone, por supuesto, que realiza la ejecución con una cuenta elevada de administrador y, por lo tanto, tiene los privilegios suficientes para eliminar el proceso).
En versiones anteriores de Windows, el Administrador de tareas intentaba evitar que eliminara estos procesos críticos de sistema, pero su algoritmo para decidir qué procesos eran críticos no era muy inteligente. Si era lo suficientemente hábil, se podía falsificar el Administrador de tareas y crear un programa que dicho administrador considerara imposible eliminar. Por supuesto, en realidad no sucedía así. Seguía siendo posible eliminar el programa: sólo tenía que usar otro programa que no fuera el Administrador de tareas para hacerlo. Por ejemplo, quizás se podía probar el programa taskkill.
Para evitar falsificaciones, el Administrador de tareas simplemente ya no intentaba evitar que eliminara los procesos críticos de sistema. Después de todo, si el usuario no hace nada, no puede hacerlo mal. Esto significa que el Administrador de tareas ya no lo vigila cuando elimina un proceso. No le dará un tirón de orejas cuando intente eliminar algo que probablemente convendría dejar estar. Si elige eliminar un proceso crítico de sistema, simplemente tendrá asumir las consecuencias.

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. Chen considera que hay que dejar a otros el trabajo de los mecanismos operativos.