 TechNet Magazine November 2007

TechNet Magazine November 2007

Administración de Windows: Cambios en los archivos sin conexión en Windows Vista

Se trata de un problema común, ¿cómo permitir que los usuarios trabajen con archivos almacenados en la red, cuando disponen de una conexión poco confiable o no disponen de ella, y evitar al mismo tiempo los problemas de control de versiones? Una continuidad de estas características es esencial para poder ofrecer una experiencia sin inconvenientes. Descubra cómo las mejoras en Windows Vista ofrecen un mejor enfoque para trabajar con archivos sin conexión.

Jeremy Moskowitz Implementación de escritorio: Implementación sencilla y escalable con BDD 2007

¿No tiene SMS 2003? No se preocupe, hay otra solución para crear implementaciones de escritorio sencillas. Aquí tiene una guía exhaustiva de BDD 2007 y SQL Server para crear implementaciones escalables que requieran pocas entradas manuales o ninguna.

Adam Shepherd Comunicaciones: Servidores Exchange de transporte perimetral en Microsoft: Segunda parte

Los servidores Exchange de transporte perimetral pueden ayudar a crear un entorno de mensajería más confiable y seguro. Ya le mostramos cómo configurar estos servidores en la primera parte. Ahora, le guiaremos por algunos ejemplos detallados de funciones clave que pueden mejorar su entorno de mensajería.

Kay Unkroth Redes: Configurar el acceso remoto VPN con ISA Server 2006

Una red privada virtual (VPN) puede ofrecer mejoras de conectividad e incrementos de productividad, y no tiene por qué ser difícil de implementar ni administrar. Averigüe cómo puede usar ISA Server 2006 en dos escenarios de VPN comunes.

Alan Maddison SQL Server: Optimización del rendimiento de las consultas de SQL Server

Al optimizar el rendimiento de la base de datos, la optimización de las consultas individuales es tan importante como la optimización de las configuraciones de software y hardware del servidor. Con sólo una consulta descontrolada se puede arruinar una base de datos. El objetivo de esta guía es generar, analizar y ajustar los planes de ejecución para optimizar el rendimiento de las consultas de SQL Server.

Maciej Pilecki Nota del editor: Más poder para usted

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

Greg Steen Preguntas y respuestas sobre Exchange: Protocolos de correo electrónico seguros, correo electrónico no deseado de origen desconocido y mucho más

En la entrega de este mes, el equipo de Exchange trata la Seguridad del nivel de transporte para SMTP, cómo evitar que NDR suplantados atasquen las colas y cómo abordar diversos desafíos de instalación.

Nino Bilic and Scott Landry Utility Spotlight: Cmdlets de SMS para Windows PowerShell

Sepa cómo puede empezar a usar cmdlets de Windows PowerShell para administrar clientes de SMS 2003 desde la línea de comandos.

Don Brown The Cable Guy: Inicio de sesión único inalámbrico

El inicio de sesión único ofrece muchas ventajas tanto a los usuarios finales como a los administradores. A continuación explicamos cómo el inicio de sesión único puede simplificar la implementación de la autenticación inalámbrica para la red.

Joseph Davies Notas de investigación: Uso de la informática de alto rendimiento en la lucha contra el VIH

Conozca cómo colabora el equipo de eScience de Microsoft Research con investigadores médicos y usa la informática de alto rendimiento para ayudar a encontrar una cura para el VIH.

Kristin Firth and Mia Matusow Windows PowerShell: Escritura de expresiones regulares

Con una expresión regular bien escrita, un script de Windows PowerShell puede determinar si los datos se presentan en un formato válido. Obtenga información general sobre el uso de expresiones regulares en Windows PowerShell.

Don Jones Hey, Scripting Guy!: Administración de escritorios desde ultratumba

Los encargados del scripting muestran cómo usar Administración remota de Windows para recuperar las propiedades y las instancias de clases en un equipo remoto. Ah, y también hay un rompecabezas genial.

The Microsoft Scripting Guys Vigilancia de seguridad: Acceso seguro desde cualquier lugar

Explore consideraciones de diseño de seguridad y red para una solución de acceso desde cualquier lugar mediante los componentes de Servicios de Terminal Server y aprenda algunos métodos útiles y prácticas recomendadas para crear una solución con Windows Server 2008.

John Morello Archivos del escritorio: La verdad acerca de la desfragmentación

Los mitos acerca de las trampas de la desfragmentación han evitado que muchos administradores realicen esta importante tarea de mantenimiento. Averigüe qué problemas son verdaderos, cuáles son improbables y cómo los puede evitar.

Wes Miller Notas de campo: El pez gordo del código de conducta

Cuando los miembros de la comunidad empiezan a actuar, quizás lo que necesitas es un pez gordo. Vea cómo la ingeniería social ayudó a salvar Live QnA.

Betsy Aoki Confidencial de Windows: La paradoja del sistema de archivos

¿Se ha preguntado alguna vez por qué necesita un controlador en miniatura del sistema de archivos integrado en esos archivos de arranque de fundamental importancia?

Raymond Chen


 Administraci&#243;n de Windows: Cambios en los archivos sin conexi&#243;n en Windows Vista
Administración de Windows Jeremy Moskowitz,

Cambios en los archivos sin conexión en Windows Vista
Resumen:
  • Continuidad en línea y sin conexión
  • Disponibilidad de archivos
  • Cómo evolucionan las carpetas sin conexión

Uno de los problemas más complicados de la administración de escritorios consiste en permitir a los usuarios sin conexión trabajar como si estuvieran en línea. La necesidad es mayor de lo que pueda creer, los usuarios son hoy día mucho más móviles de lo que eran hace cinco años. Aunque hay una serie de casos en los que quizás necesite trabajar
sin conexión, los tres más comunes son: cuando desconecta el portátil de la red de la oficina y sale de viaje, cuando se conecta a través de un vínculo lento o intermitente y cuando la sucursal pierde conectividad con la oficina principal.
En estas circunstancias, ¿cómo es posible mantener una copia de un archivo en el equipo sin conexión mientras la original está en el servidor principal? Y lo más importante, ¿cómo es posible gestionar un conflicto si alguien de la oficina principal cambia el archivo en el servidor mientras otra persona lo cambia cuando está desplazado? Afortunadamente, estos problemas los trata el motor de archivos sin conexión, que está integrado en Windows® 2000, Windows XP y Windows Vista®.

El almacenamiento en caché es la respuesta
El motor de archivos sin conexión es en realidad una máquina de almacenamiento en caché gigante. Por supuesto, de forma subyacente (y dentro de Microsoft) se conoce con el nombre de caché en el lado cliente (CSC). El motor de archivos sin conexión es los suficientemente configurable y flexible para permitir que los usuarios decidan qué es lo que desean almacenar y para ayudarle a conseguir que el sistema almacene en memoria caché lo que desea. Le permite obtener acceso a los mismos archivos tanto sin conexión como en línea, sin cambiar el espacio de nombres. Es decir, se obtiene acceso a los archivos mediante la misma ruta de acceso UNC o letra de unidad tanto si trabaja en línea como sin conexión.
Puede configurar los archivos que se van a almacenar en memoria caché de manera manual o automática. Si sabe que usa a menudo archivos o carpetas determinados mientras está de viaje, simplemente puede designar un archivo o carpeta como los que viajarán con usted. Para hacerlo, un usuario de Windows XP haría clic con el botón secundario en un archivo que esté almacenado de forma local o en un recurso compartido de red y seleccionaría la opción para hacer que los archivos estuvieran disponibles sin conexión (consulte la figura 1). En Windows Vista la opción se llama Siempre disponible sin conexión. Hacer disponible de manera manual un archivo sin conexión se suele denominar anclar un archivo.
Figura 1 Cómo hacer disponible un archivo sin conexión
Figura 1 Cómo hacer disponible un archivo sin conexión
Figura 1a Carpeta de archivos sin conexión
Figura 1a Carpeta de archivos sin conexión
El recurso compartido que está usando puede conectarse a través de una ruta de acceso UNC o asignarse con una letra de unidad. Por supuesto, el archivo no necesita estar almacenado en un equipo que ejecute Windows Server®. Puede residir en cualquier equipo que cumpla con el protocolo SMB (Bloque de mensajes del servidor), como un servidor Samba o dispositivo NAS (con algunas raras excepciones), que también cumpla con el protocolo SMB.
La primera vez que elija anclar un archivo, Windows XP le guía a través de una serie de pantallas del asistente, preguntando cuándo sincronizar. Si hace clic en Siguiente en cada pantalla y escoge las opciones predeterminadas, la sincronización sucede cada vez que inicia sesión o desconecta y también en segundo plano cuando está inactivo. Cuando el asistente se completa, verá un cambio de icono que indica que el archivo está ahora disponible sin conexión.
Una vez que desconecta de la red, el resto de archivos en el recurso compartido pasa a ser no disponible excepto aquellos escogidos para el uso sin conexión. Esto a veces resulta problemático: el icono muestra qué archivos están siempre disponibles sin conexión, pero no está claro inmediatamente antes de que haya desconectado que no todos los otros archivos vayan a estar disponibles. Trataré este problema con más detalle más adelante en el artículo.
Hacer que los archivos estén disponibles sin conexión de manera manual tiene sus ventajas, pero a veces tiene sentido hacerlo de manera más automatizada. Exploraré este escenario a continuación, mediante lo que a menudo se ha denominado almacenamiento automático en caché.

Cuando el almacenamiento automático en caché vence al almacenamiento manual en caché
El almacenamiento automático en caché se configura en un servidor según el recurso compartido. Por lo que si tiene un recurso compartido llamado Ventas y desea permitir que el personal de ventas pueda llevarse consigo sus archivos cuando viaja, puede indicar al motor de CSC que lo haga. La figura 2 muestra el cuadro de diálogo Configuración sin conexión que aparece cuando se hace clic en la ficha Almacenamiento en caché en Windows Server 2003. La configuración se explica en la figura 3.
Figure 3 Configuración del almacenamiento automático en caché (Close Figure 3)

Valor | Descripción
Sólo los archivos y programas que los usuarios especifiquen estará disponibles sin conexión. | Permite a los usuarios especificar manualmente los archivos que van a estar disponibles sin conexión. Éste es el valor predeterminado.
Todos los programas que el usuario abra desde el recurso compartido estarán disponibles sin conexión automáticamente. | Permite el almacenamiento automático en caché de todos los archivos y programas que toca el Explorador de Windows. La configuración Rendimiento óptimo se usa al almacenar automáticamente en caché los programas más que los documentos, pero normalmente no tiene efecto en el rendimiento y puede omitirse sin riesgos en la mayoría de los casos. Windows Vista la omite por completo.
Los archivos o programas del recurso compartido no estarán disponibles sin conexión. | Bloquea el acceso del usuario al elemento Disponible sin conexión en un cliente de Windows 2000, Windows XP o Windows Vista.
Figura 2 Cuadro de diálogo Configuración sin conexión en Windows Server 2003
Figura 2 Cuadro de diálogo Configuración sin conexión en Windows Server 2003
Para ver cómo funciona el almacenamiento automático en caché, supongamos que tiene el recurso compartido Ventas que contiene 10, de Sales01.txt a Sales10.txt, y que ha habilitado la configuración denominada Todos los programas que el usuario abra desde el recurso compartido estarán disponibles sin conexión automáticamente. Los resultados no son inmediatamente obvios. Para el usuario no hay más señal externa que la de que, de repente, tiene disponibles más archivos sin conexión. Además, sólo los archivos abiertos por Windows (y por lo tanto almacenados en memoria caché) están más tarde disponibles para ser usados sin conexión. En resumen, es necesario abrir los archivos en línea que desea usar sin conexión antes de desconectar realmente de la red. De lo contrario, no estarán disponibles sin conexión cuando los necesite.
Además, los archivos que se almacenan en memoria caché automáticamente no permanecerán en ella necesariamente para siempre. Windows XP y Windows Vista gestionan este espacio temporal de una manera un poco diferente, pero el aspecto clave es que los archivos se pueden expulsar según las restricciones de espacio. Los archivos se mantienen según se han usado. Aquellos que no se han abierto en mucho tiempo se expulsan para dejar espacio a los archivos nuevos a medida que se abren. Así pues, aunque hay una probabilidad alta de que un archivo que haya modificado recientemente esté todavía en la memoria caché, no asuma que el almacenamiento automático en caché garantiza que los archivos estén disponibles. Si quiere estar seguro que un archivo estará disponible, necesita anclarlo. Como administrador, también puede usar una directiva de grupo para anclar archivos con la configuración de archivos sin conexión asignada administrativamente.
Echemos un vistazo a un ejemplo de trabajo real. Suponga que un usuario de Windows XP denominado EastSalesUser1 abrió un archivo denominado Sales05.txt y que un usuario de Windows Vista denominado EastSalesUser2 abrió Sales05.txt en el recurso compartido \\server\sales.
Puesto que el almacenamiento automático en caché se ha establecido en el recurso compartido de ventas, aunque EastSalesUser1 (en Windows XP) y EastSalesUser2 (en Windows Vista) se encuentren sin conexión, podrían seguir trabajando en esos archivos. Windows ha almacenado una copia de esos archivos en la memoria caché de Archivos sin conexión. Pero ¿qué ocurre con los otros archivos que los usuarios no han usado todavía?
Windows XP y Windows Vista reaccionan de manera diferente a los archivos que se han dejado en la oficina, tal como puede ver en las figuras 4 y 5. Windows XP no indica de ninguna forma si había archivos no almacenados en memoria caché. Cuando se encuentra sin conexión, esos archivos desaparecen de una manera que puede resultar confusa. Windows Vista, al contrario, cuenta con una superposición de icono y muestra una X un poco atenuada en los archivos que no han sido almacenados en memoria caché. Esto constituye un gran paso adelante a la hora de mostrar qué archivos están disponibles sin conexión. El único problema es que el usuario sólo lo ve después de desconectar, no durante una sesión en línea. Así pues, hacer más explícito el estado del archivo sería un extra muy bienvenido.
Figura 4 Windows XP sólo muestra los archivos disponibles una vez se encuentra sin conexión
Figura 4 Windows XP sólo muestra los archivos disponibles una vez se encuentra sin conexión
Figura 5 Windows Vista muestra los archivos no disponibles mientras se encuentra sin conexión
Figura 5 Windows Vista muestra los archivos no disponibles mientras se encuentra sin conexión

Disponible, o no
Algunos administradores dudan si aprovechar la función Archivos sin conexión, precisamente a causa de la posible confusión: qué archivos están definitivamente disponibles sin conexión y cuáles no y cómo diferenciarlos. En la figura 5, el icono del círculo verde sobre sales01.txt indica que está garantizado que el archivo está disponible. (De nuevo, al anclar archivos, se garantiza que el archivo esté disponible sin conexión).
Sin embargo, tal como expliqué, Sales05.txt, que tanto Windows XP como Windows vista han hecho disponible sin conexión a través del almacenamiento automático en caché, no está necesariamente disponible sin conexión. Recuerde, sólo los archivos que haya tocado estarán disponibles sin conexión. Así que sería preferible si el sistema indicara que los archivos están temporalmente o posiblemente disponibles sin conexión. Puesto que no hay diferenciación de icono, determinar qué archivos estarán disponibles sin conexión puede ser confuso. La IU de Windows Vista es mejor, pero aún necesita cierta mejora en este aspecto. Una propiedad del Explorador en Windows Vista llamada Disponibilidad sin conexión ofrece información de disponibilidad. Esa propiedad se muestra en el panel de vista previa cuando se selecciona un elemento. Si se ancla el elemento, el valor es "Siempre disponible". Si no se ancla pero se almacena en memoria caché, el valor es "Disponible".
La idea de los archivos disponibles sin conexión de manera temporal es semejante en Windows XP y Windows Vista, pero las implementaciones son ligeramente diferentes. La figura 6 muestra la forma en que Windows XP y Windows Vista administran los archivos sin conexión.
Figura 6 Áreas de archivos sin conexión de Windows XP y Windows Vista
Figura 6 Áreas de archivos sin conexión de Windows XP y Windows Vista
En resumidas cuentas, tanto Windows XP como Windows Vista tienen un lugar en el que mantener los archivos sin conexión, pero los archivos Siempre disponibles sin conexión y los archivos Disponibles sin conexión de manera temporal se almacenan de una forma un poco distinta en cada sistema operativo.
Para Windows XP, los archivos que están siempre disponibles sin conexión (designados por el cambio de icono como se ve en la figura 1) se colocan donde permanecen para siempre. Si ancla 10 GB de archivos manualmente, con lo cual los convierte en Siempre disponibles sin conexión, los 10 GB siempre estarán disponibles. No hay límite para el número de archivos que un usuario puede anclar (fuera del tamaño máximo de partición). Sin embargo, Windows XP tiene un máximo de 2 GB para archivos almacenados automáticamente en memoria caché. La idea es que sólo los archivos que se abren de manera rutinaria se almacenen aquí mientras que los que no han sido usados durante un tiempo son expulsados siempre que sea necesario. De forma predeterminada, se asigna a la Memoria caché disponible temporalmente un 10 por ciento del espacio disponible en el disco duro, tal como se muestra en la figura 7. Esta configuración está sólo disponible para administradores en Windows XP.
Figura 7 Cómo configurar espacio en disco para archivos sin conexión en Windows XP
Figura 7 Cómo configurar espacio en disco para archivos sin conexión en Windows XP
Windows Vista puede almacenar también los archivos permanente o temporalmente. Sin embargo, hay una diferencia. La Memoria caché de archivos temporales está integrada en la memoria caché general. De forma predeterminada, toda la memoria caché (tanto los archivos temporales y los archivos Siempre disponibles sin conexión) se limita al 25 por ciento del espacio disponible en el disco duro. La razón por la que esto se cambió es que en Windows XP un usuario podría mantener el almacenamiento manual en caché de los archivos (quizás varias decenas de gigabytes), y quedarse directamente sin espacio en el disco duro. Con el esquema nuevo, el administrador aparta una cantidad específica de espacio para toda la memoria caché, para que no pueda suceder. Al observar la figura 8, tenga en cuenta que el 25 por ciento del espacio disponible en la unidad de disco se muestra de manera confusa como un 15,2 por ciento de toda la unidad de disco. Tenga en cuenta también que el segundo control deslizante, que establece el espacio temporal, nunca puede configurarse por encima del primer control deslizante, que establece el espacio máximo de todos los archivos sin conexión. Se puede obtener acceso a estos controles deslizantes de los Límites de uso de disco para archivos sin conexión haciendo clic en la opción Cambiar límites, pero tenga en cuenta que necesita credenciales de administrador para hacerlo.
Figura 8 Espacio disponible para archivos sin conexión en Windows Vista
Figura 8 Espacio disponible para archivos sin conexión en Windows Vista

Evitar el almacenamiento excesivo en caché
La Redirección de carpetas es otra característica de Windows que le permite asegurar que ciertas carpetas clave normalmente locales en el equipo se almacenen realmente en los servidores. La idea es que no tiene que preocuparse si este equipo local no funciona puesto que dispone de una copia de los archivos importantes en el recurso compartido de red.
Suponga que tiene una carpeta Mis documentos redirigida (para Windows XP) o una carpeta Documentos (para Windows Vista). En este caso (de hecho cuando se redirige cualquier carpeta), el sistema operativo asume que siempre desea estos archivos disponibles sin conexión y todos los archivos de la carpeta redirigida recibirán el símbolo mostrado en la figura 1. La desventaja es que si está en una red bien conectada y siempre en línea y se desplaza a un equipo nuevo, almacenará todos los contenidos de la carpeta redirigida en el equipo nuevo, incluso si sólo piensa usarlo para una sesión. Esto no sólo es un derroche de espacio, es un riesgo de seguridad si no se administra adecuadamente.
Otro caso en el que los archivos se almacenan en caché automáticamente y sin saberlo es al usar el Explorador de Windows para examinar los archivos de un recurso compartido. Si solamente observa un conjunto de, por ejemplo, archivos gráficos en un recurso compartido de red con el Explorador y el almacenamiento automático en caché está activado, es muy probable que esos archivos se descarguen automáticamente y se coloquen en la caché. Esto es porque usar el Explorador para obtener acceso a un archivo es todo lo que se necesita para colocarlo temporalmente en la memoria caché sin conexión. A menudo se obtiene acceso a todos los archivos del recurso compartido para obtener metadatos como el tamaño del archivo o una vista preliminar de una imagen. Cuando esto sucede a través de un vínculo rápido y bien conectado, no merece la pena. Windows almacena el archivo en memoria caché de forma rápida y silenciosa para el uso posterior. Pero cuando está conectado a ese recurso compartido de red con almacenamiento automático en memoria caché a través de un vínculo de baja velocidad, las cosas pueden ser mucho más problemáticas. La situación es básicamente igual de forma predeterminada para el Explorador de Windows XP y el Explorador de Windows Vista. La buena noticia es que el motor de almacenamiento en caché sin conexión de Windows Vista puede aprender a reconocer mejor un vínculo de baja velocidad.

Archivos sin conexión con directiva de grupo
Cambios importantes en los archivos sin conexión de Windows Vista
Los miembros del equipo Archivos sin conexión desean que conozca sus cambios favoritos, pero no había espacio para explorarlos todos en el artículo. Así, en pocas palabras, estos son los principales cambios en los Archivos sin conexión:
  1. Las transiciones continuas sin conexión a en línea implican que los identificadores abiertos no bloquean la transición.
  2. Granularidad sin conexión por archivo, por lo que un recurso compartido sin conexión ya no hace que todo el servidor esté sin conexión.
  3. Modo sin conexión forzado a través de un botón Trabajar en línea/sin conexión en el Explorador de Windows.
  4. Cifrado por usuario del contenido en memoria caché.
  5. Nuevo motor de sincronización mucho más rápido en la detección y análisis de los cambios.
  6. Integración con Búsqueda de Windows para que se puedan indizar las carpetas redirigidas.
  7. Sincronización local a remota, que puede aprovechar la característica Transferencia de mapa de bits diferencial.
  8. Resolución diferida del conflicto a través del Centro de sincronización.
  9. Los globos del área de notificación han desaparecido; ya no molestan al usuario.
  10. Nueva compatibilidad integral con API COM y WMI para la administración; documentada en MSDN® en msdn2.microsoft.com/bb530662.
  11. Compatibilidad con scripts a través de un proveedor WMI (que se documentará en MSDN en breve).
  12. Nuevas propiedades de elemento de shell Estado sin conexión y Disponibilidad sin conexión.
  13. Conversión en fantasma para representar los elementos no disponibles del espacio de nombres mientras se encuentra sin conexión. El Explorador muestra éstos elementos atenuados con la superposición de una X gris, ayudando a evitar cambios drásticos de la vista de la carpeta shell cuando se realice la transición de en línea a sin conexión.
  14. Nuevo applet del Panel de control.
Si desea obtener más información, encontrará gran cantidad de información sobre el tema en mi libro y en la documentación de Microsoft.

Tal como afirmamos, siempre que un usuario (o el Explorador) tenga acceso a un archivo, todo el archivo se integra en la memoria caché. Y si ese archivo es un documento de 80 MB de Visio® o de Word, que así sea. Tanto Windows XP como Windows Vista entienden lo que es un vínculo de baja velocidad. De hecho, de manera predeterminada, Windows XP piensa que un vínculo de baja velocidad es 64 Kbps. Si la velocidad de la conexión es más que ésta y el cliente es Windows XP, ese archivo se baja a través de esa canalización lenta en el momento del inicio de sesión, para consternación del usuario. Así que es mejor configurar Windows para administrar mejor lo que hacer a través de ese vínculo de baja velocidad. Como verá en un momento, puede conseguir esto a través de una directiva de grupo creando un Objeto de directiva de grupo (GPO) para que se vincule a una unidad organizativa (OU) que contiene las cuentas de destino, Windows XP o Windows Vista.
Cuando el usuario se conecta a través de un vínculo de baja velocidad, Windows XP trata de usar los archivos almacenados en caché de forma local antes de intentar usar la copia en red. Esto tiene sentido. Pero Windows XP hace todavía algo que quizás no se espere: descarga los archivos grandes que el usuario no tiene todavía en la memoria caché si el usuario los abre desde la red o si el Explorador los toca, con consecuencias nefastas. Y, en mis pruebas, si la sincronización se programa para que ocurra en el cierre de sesión (el valor predeterminado), el resto de esos archivos se descargan a través del vínculo de baja velocidad y se almacenan en la memoria caché. (Consecuencias aún más nefastas).
El comportamiento de Windows Vista es diferente. No reconoce ninguna situación como lenta de manera predeterminada. De hecho, si se conectara con una lata, con una velocidad de 1 bit por segundo, Windows Vista consideraría esa conexión como rápida y usaría la copia de los archivos en la red. Pero Windows Vista puede aprender a reconocer qué recursos compartidos desea designar para realizar la transición cuando la conexión es lenta. Cuando se produce una situación así, las cosas mejoran. El comportamiento de Windows Vista (una vez configurado mediante la directiva de grupo) es tal que los contenidos de los recursos compartidos definidos por el vínculo lento no están simplemente disponibles a través de un vínculo de baja velocidad mediante las operaciones de un archivo normal y del Explorador.
La sincronización en segundo plano realizada por el servicio Archivos sin conexión no ocurre a través de una conexión lenta. Sin embargo, debe tenerse en cuenta que la sincronización manual puede realizarse a través del Centro de sincronización.
La configuración de Windows Vista para modificar su gestión de los vínculos de baja velocidad se realiza a través de la configuración de la directiva de grupo Configurar el modo de vínculo de baja velocidad (no confundir con la configuración de nombre similar de Windows XP Configurar velocidad lenta de vínculos). La configuración del modo de vínculo de baja velocidad adquiere los valores siguientes: los nombres de los servidores y de los recursos compartidos que desea pasar automáticamente a sin conexión cuando la conexión es lenta y cómo de lenta necesita ser esa conexión antes de que esa combinación servidor\recurso compartido se encuentre sin conexión. La combinación servidor\recurso compartido puede ser cualquier combinación de \\server\share o incluso de una sola estrella (*) para indicar todos los recursos compartidos de todos los servidores. El segundo conjunto de valores es una declaración de la capacidad de proceso (en kbps) y la latencia (en milisegundos) que deben cruzarse con el objeto de ser consideradas lentas. Ésta es la primicia, no obstante: lo más útil del par (capacidad de proceso) no se comprueba al descargar los archivos. Por lo que si tiene 10 GB de archivos en una carpeta redirigida Documentos y está en un vínculo de baja velocidad en un portátil que no contiene todavía cualquiera de esos archivos, prepárese para una larga espera. Sin embargo, si la empareja con la comprobación de la latencia y la latencia cae por debajo del valor recomendado, el recurso compartido hace la transición a sin conexión, ahorrándole al usuario la dolorosa demora de tener que esperar esos archivos.
La revisión de Windows Vista en el artículo 934202 de Knowledge Base (un cambio que se integrará en Windows Vista Service Pack 1) debe mejorar el rendimiento de ciertas condiciones de VPN de baja velocidad. (Este artículo está disponible en línea en support.microsoft.com/kb/934202.) De hecho, esta revisión debe habilitar el valor de la capacidad de proceso que se comprobará cuando se produce la descarga a través de un vínculo de baja velocidad.

Conflictos de sincronización
Probablemente se esté preguntando lo que sucedería si alguien cambiara un archivo sin conexión (por ejemplo, mientras se encuentra en un avión), mientras otra persona lo cambia en línea (conectado en la oficina principal). Esta situación se resuelve en el nivel de cliente. Cuando realiza la transición de sin conexión a en línea, la sincronización en segundo plano de los archivos sin conexión de Windows Vista ocurre de inmediato. A continuación, se le pregunta acerca de lo que hacer (a través de una entrada en el Centro de sincronización después de que un icono aparezca en el área del notificaciones de la barra de tareas). La interfaz de usuario ha sido rediseñada para mostrar que un archivo parece ser más nuevo y para mostrar más información acerca de la colisión. Un usuario puede conservar los archivos con colisiones eligiendo cambiar el nombre del archivo que está actualmente sólo en su equipo al volver a guardarlo en el servidor, como en la figura 9.
Figura 9 Aviso de conflicto de cambio de archivo de Windows Vista
Figura 9 Aviso de conflicto de cambio de archivo de Windows Vista

¿Desea obtener más información?
Archivos sin conexión es una característica atractiva tanto para usted como para los usuarios. Por supuesto, si está usando la Redirección de carpetas, ya la está usando, así que aumentar sus conocimientos sólo le traerá beneficios. He mencionado un número de cambios de Archivos sin conexión en Windows Vista, pero no todos ellos. Si desea obtener más información acerca de este tema, consulte la barra lateral "Cambios importantes en los archivos sin conexión de Windows Vista".
Encontrará mucha más información sobre Archivos sin conexión en go.microsoft.com/fwlink/?LinkId=98141 para Windows XP y go.microsoft.com/fwlink/?LinkId=98138 para Windows Vista.
Hay también una sección muy amplia dedicada a Archivos sin conexión, incluidos los pormenores de cada configuración de directiva de grupo, en mi libro (consulte la biografía al final del artículo). Finalmente, para obtener aún más información y para hablar con otros usuarios acerca de sus experiencias con Archivos sin conexión visite GPanswers.COM en el foro comunitario en una sección dedicada en exclusiva a este tema.

Jeremy Moskowitz,MCSE y MVP en directivas de grupo, dirige GPanswers.com, un foro comunitario sobre directivas de grupo. También dirige una serie de talleres intensivos de aprendizaje sobre directivas de grupo. Su último libro es Group Policy: Management, Troubleshooting, and Security (Sybex, 2007). Póngase en contacto con Jeremy y obtenga más información en www.GPanswers.com.
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 Implementaci&#243;n de escritorio: Implementaci&#243;n sencilla y escalable con BDD 2007
Implementación de escritorio Adam Shepherd

Implementación sencilla y escalable con BDD 2007
Resumen:
  • Las capacidades fundamentales de BDD 2007
  • Integración con SQL Server
  • Generar una solución de implementación escalable

La mayoría de las personas implicadas en implementar Windows ha oído hablar de Microsoft Solution Accelerator para Business Desktop Deployment. También conocido como BDD, es un conjunto de información acerca de prácticas recomendadas y
herramientas desarrolladas para ayudar a implementar Windows® en escritorios de cliente. Windows Vista® incluye una actualización del Acelerador de soluciones en forma de BDD 2007. Esta versión contiene una nueva consola Microsoft® Management Console (MMC) y un secuenciador de tareas que se origina desde System Center Configuration Manager 2007, el sucesor de Systems Management Server (SMS) 2003.
Una de las características que menos se entiende de BDD 2007 es su capacidad de funcionar como solución de implementación completa. En versiones anteriores, BDD podía ayudar a crear y mantener imágenes de escritorio de una manera fácil de administrar y repetible. Ahora, BDD 2007 otorga la capacidad adicional de generar una solución de implementación escalable al combinar BDD con los Servicios de implementación de Windows (WDS), SQL ServerTM y la réplica del sistema de archivos distribuido (DFS-R) de Windows Server® 2003.
Pero, espere... ¿el uso de SMS 2003 con Operating System Deployment (OSD) Feature Pack no es una práctica recomendada para la implementación del cliente de Windows?
Sí, si ya dispone de una infraestructura de SMS 2003, debe preparar el terreno para usar BDD 2007, SMS 2003 y OSD Feature Pack para la implementación. Éste es actualmente el modo más completo de lograr una implementación sin retoques y verdaderamente puede reducir los costos de configuración, instalación y administración de Windows en su organización.
Sin embargo, muchos clientes no tienen SMS 2003 ni otra solución equivalente de implementación de software. Para estos clientes hay otra opción en la que me centraré en este artículo.

Conceptos centrales de BDD 2007
BDD 2007 ofrece dos métodos principales de implementación. El primer método, la instalación con interacción mínima, solamente usa BDD 2007 para la implementación del cliente. De fábrica, presenta un conjunto de asistentes en el momento de la creación para capturar información acerca de la implementación, como el nombre de equipo que debe asignarse al cliente (consulte la figura 1), la distribución de teclado y la zona horaria que deben usarse, etcétera. Este método se conoce como "interacción mínima" porque normalmente requiere una cantidad muy reducida de entradas manuales para recopilar esa información antes de iniciar el proceso de creación.
Figura 1 Asistente para la implementación con interacción mínima de BDD 2007
Figura 1 Asistente para la implementación con interacción mínima de BDD 2007
El segundo método, la implementación sin retoques, se basa en las capacidades de SMS 2003 con OSD Feature Pack al integrarse con BDD 2007. Esta configuración constituye una solución de implementación sin intervención completamente automatizada, escalable y de fácil administración.
En el momento de la creación y en uno de los primeros pasos de una implementación de SO del cliente, BDD 2007 recopila información de una serie de orígenes diferentes. Estos orígenes incluyen llamadas de WMI y los archivos de configuración de BDD 2007, Bootstrap.ini y CustomSettings.ini. La información se recopila y almacena como variables, que se usan en toda la implementación. En el caso de un escenario de interacción mínima, los archivos Bootstrap.ini y CustomSettings.ini ofrecen la posibilidad de predefinir toda la información que de otro modo tendría que recopilarse mediante entrada manual en los asistentes de implementación.
La capacidad de especificar de antemano toda la información que los asistentes para la implementación con interacción mínima tendrían que capturar en el momento de la creación permite automatizar todo el proceso de interacción mínima y avanzar hacia una solución de implementación sin retoques en los entornos no compatibles con SMS 2003. Entre los ejemplos de información que puede optar por predefinir se incluye: ComputerName=RDG0001VST, para asignar al equipo el nombre de RDG0001VDT o bien TimeZoneName=GMT Standard Time, para garantizar que la zona horaria del equipo esté establecida en la hora del meridiano de Greenwich. Todas las propiedades disponibles que pueden usarse durante una implementación con BDD están bien documentadas en una referencia de configuración a la que puede tener acceso en technet.microsoft.com/library/bb490302.aspx.
Para obtener más información acerca de la configuración y el uso de BDD 2007, consulte el artículo "Implementación de Windows Vista con BDD 2007" en el número de septiembre de 2007 de TechNet Magazine (technetmagazine.com/issues/2007/09/BDD).

BDD y SQL Server
¿Por qué usar una base de datos con BDD 2007? Hay que buscar la respuesta en el modo de proporcionar información dinámicamente durante una implementación que de lo contrario tendría que indicarse manualmente mediante los asistentes para la instalación con interacción mínima. Como ya he apuntado, esto puede lograrse mediante el archivo CustomSettings.ini. El problema es que, en una implementación real, estos detalles cambiarán en función de la máquina en la que se va a implementar. Por otro lado, el archivo CustomSettings.ini puede convertirse rápidamente en algo de difícil administración si intenta definir opciones y parámetros específicos para 500 máquinas distintas. Si se conecta una base de datos back-end a la consola de BDD, se agrega una solución mucho más fácil de administrar, que es dinámica y extensible.
Hablemos un poco más acerca de cómo SQL Server se integra con BDD 2007. En primer lugar, debe asegurarse de que SQL Server (preferiblemente SQL Server 2005 o posterior) esté instalado en el servidor de implementación. Afortunadamente, los pasos para crear la base de datos en BDD 2007 son fáciles: simplemente haga clic con el botón secundario en el nodo de la base de datos del Deployment Workbench de BDD 2007, haga clic en Nuevo y siga las instrucciones (consulte la figura 2). El equipo de BDD ha hecho un gran trabajo al ofrecer asistentes que permiten conseguir el funcionamiento fácil y rápidamente.
Figura 2 Configuración de la base de datos de implementación para BDD 2007
Figura 2 Configuración de la base de datos de implementación para BDD 2007
Una vez creada la base de datos, puede empezar a explorar sus capacidades. Las entradas de la base de datos se dividen en cuatro categorías principales: equipo, función, ubicación y marca y modelo. Cada categoría permite definir entradas y, para cada entrada que se defina, es posible rellenarla con variables de BDD 2007, asignar aplicaciones y suministrar otros valores clave (consulte la figura 3).
Figura 3 Asignar propiedades de implementación
Figura 3 Asignar propiedades de implementación
Resulta útil contemplar estas cuatro categorías en dos grupos bien diferenciados. Las categorías Equipo, Ubicación y Marca y modelo ofrecen métodos diferentes de identificar un equipo en el momento de su creación. Cada equipo identificado puede entonces asociarse a una función específica en la base de datos, de modo que quede aprovisionado para un propósito específico, como ventas, marketing o finanzas, con cada función garantizando que se instale la línea pertinente de aplicaciones de negocios.
Use la sección Equipo para identificar equipos mediante una dirección MAC, una etiqueta de inventario, un identificador único universal (UUID) o el número de serie. A causa de las muchas entradas que probablemente se creen en esta sección, una para cada equipo de su organización, agregue únicamente las propiedades muy específicas, tales como ComputerName, a cada entrada.
Use la sección Ubicación para crear entradas para ubicaciones geográficas específicas en toda su organización. Cada entrada se identifica por medio de la puerta de enlace predeterminada de esa ubicación. Esto puede ser especialmente útil si tiene unidades organizativas (OU) basadas en ubicación en Active Directory® y quiere que los equipos creados en una ubicación se agreguen al dominio en la unidad organizativa que corresponda a esa ubicación.
Use la sección Marca y modelo para crear entradas para cada uno de los tipos de hardware que debe admitir su implementación. BDD 2007 los hace coincidir con la información detectada mediante llamadas WMI. Un uso común de la sección Marca y modelo en entornos de desarrollo es el de crear una entrada que detecte si el equipo es una máquina virtual con Virtual PC 2007 o con Virtual Server 2005, comprobando las propiedades de marca y modelo "Microsoft Corporation" y "Virtual Machine" respectivamente. Si en el momento de la creación hace coincidir estas propiedades, puede indicar a BDD que debe instalar la aplicación Virtual Machine Additions durante la implementación agregando simplemente la aplicación a la entrada Marca y modelo.
Ahora que ha proporcionado los métodos para identificar los equipos, use la sección Funciones para crear las entradas de cada función de implementación que quiera suministrar. Es posible que los ejemplos incluyan una entrada para una función de Windows XP y una función de Windows Vista, que se configuran agregando a cada entrada la propiedad BuildID que corresponda a la compilación de Windows XP o Windows Vista definida en BDD. Un enfoque alternativo es el de especificar las funciones departamentales, como Contabilidad, Ventas o Finanzas. Tiendo a rellenar la mayoría de las propiedades de BDD en esta sección (zona horaria, configuración regional, información de la organización, etcétera). Esto ofrece la mínima administración de la base de datos debido al hecho de que las entradas no están vinculadas a ningún equipo, hardware o ubicación específicos.
Es necesario indicar a BDD 2007 que debe buscar en la base de datos, en el momento de la implementación, cualquier entrada que coincida con el equipo que se está creando actualmente. Para configurar BDD de modo que use la base de datos durante una implementación, haga clic con el botón secundario en el punto de implementación y elija Configurar base de datos. Esto le llevará a recorrer una serie de asistentes que rellenan el archivo CustomSettings.ini con las entradas que hacen que el proceso de instalación con interacción mínima consulte la información en la base de datos.

Cómo hacer una implementación escalable
Ahora tiene un servidor de implementación que puede automatizar la instalación con interacción mínima y disponer dinámicamente cada equipo para que funcione con una función de negocio específica. Pero, ¿cómo se puede escalar esta solución?
La arquitectura de la solución se establece alrededor de una topología de concentrador y radio, como se muestra en la figura 4. El primer servidor de implementación que se establece será el concentrador y el servidor de implementación principal. Cada uno de los servidores secundarios de la implementación actuará como radio.
Figura 4 Arquitectura de implementación de concentrador y radio
Figura 4 Arquitectura de implementación de concentrador y radio
Para habilitar esta arquitectura, es preciso usar DFS-R con el fin de replicar el recurso compartido de distribución en cada uno de los servidores de implementación. A continuación, se usa la réplica de instantáneas de SQL Server para proporcionar una copia de la base de datos de implementación de BDD a cada uno de los servidores de implementación secundarios. Lo mejor de esta solución es que los servidores de implementación secundarios tienen requisitos mínimos: sólo se necesita tener instalados SQL Server Express, WDS y DFS-R en cada equipo para habilitar la implementación.
Debido a las grandes cantidades de datos que pueden almacenarse en el recurso compartido de distribución de BDD 2007, establezco el uso de DFS-R en Windows Server 2003 R2 en vez de los servicios de réplica de archivos de anteriores versiones de Windows Server. DFS-R usa la compresión diferencial remota (RDC) con el fin de sólo replicar los cambios diferenciales (delta) de los archivos entre los miembros del grupo de réplica. Esto puede tener una gran repercusión en la cantidad de tráfico de réplica cuando se hace un cambio pequeño, como un controlador nuevo, en el archivo de imágenes personalizado. Con DFS-R, el tráfico de réplica equivale únicamente al tamaño de los cambios hechos en vez de redistribuir todo el archivo de imágenes.
Hay abundante información acerca de DFS en el sitio web de Microsoft (empiece por consultar microsoft.com/windowsserver2003/technologies/storage/dfs), pero describiré los pasos básicos de instalación y configuración necesarios para disponer de una descripción general del proceso en el contexto de la implementación basada en BDD.
Tenga en cuenta que si los servidores han estado ejecutando Active Directory basado en una instalación de Windows Server 2003 anterior a R2, es posible que el esquema de Active Directory deba actualizarse para permitir DFS-R, ya que el servicio de réplica requiere nuevas clases de objeto. Para obtener una información completa acerca de la extensión del esquema de Active Directory en Windows Server 2003 R2, consulte go.microsoft.com/fwlink/?LinkId=99936.
El primer paso es instalar los componentes de DFS en el servidor de implementación de Windows Server 2003 R2. Puede hacerlo de varias maneras, siendo una de las más sencillas la del asistente para agregar o quitar componentes de Windows estándar. Una vez que lo haya hecho, tendrá que establecer un grupo de réplica mediante la consola de administración DFS que se muestra en la figura 5.
Figura 5 Consola de administración DFS
Figura 5 Consola de administración DFS
Para escalar la solución de implementación de BDD 2007, hay dos carpetas específicas que deben replicarse. La primera es el recurso compartido de distribución de BDD 2007, que contiene todos los archivos de origen y configuración de BDD. Estos archivos deben estar disponibles en cada servidor de implementación.
La segunda carpeta para replicar es la carpeta de arranque que usa WDS para guardar el archivo LiteTouch_x86.wim. Se trata del entorno de arranque de BDD proporcionado por WDS a los equipos cliente de escritorio para iniciar el proceso de implementación. Debe replicar este archivo para que cuando se haga algún cambio en el entorno de arranque del servidor de implementación principal, los cambios se repliquen en todo el resto de la infraestructura de implementación.
Las rutas de acceso que deben replicarse son X:\Distribution (donde X es la letra de unidad que se especifica en el momento de la instalación de BDD 2007) e Y:\RemoteInstall\boot (donde Y es la letra de unidad del volumen que contiene el recurso compartido de WDS RemoteInstall).
La réplica en DFS-R es con varios maestros y, por lo tanto, no es posible crear una topología de réplica unidireccional. Por este motivo, para permitir la administración centralizada del recurso compartido de distribución, configure la carpeta de distribución en cada uno de los servidores de implementación secundarios para que sea de sólo lectura. Esto permite que sólo la réplica DFS-R se escriba en la carpeta (puesto que usa derechos de copia de seguridad y restauración). Los equipos cliente que se generan a partir de estos servidores secundarios nunca necesitarán escribir en esta carpeta, de modo que no hay necesidad de que ninguna cuenta tenga permisos superiores a los de lectura.
El paso final de la configuración para completar la réplica de los datos mediante DFS-R es el de establecer la directiva de actualización del almacén de datos de configuración de arranque (BCD) en WDS. Esto garantiza que cualquier cambio hecho en el entorno de arranque se vea reflejado en cada uno de los servidores de implementación secundarios. Este cambio de configuración debe establecerse en todos los servidores WDS, y yo recomiendo integrarlo en el proceso de creación y configuración para el aprovisionamiento de un servidor de implementación.
En cada servidor de implementación, ejecute el siguiente comando:
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
El tiempo del período de actualización depende de la frecuencia de actualización de los datos en los servidores de implementación. Si configura DFS-R para replicar cada hora, tiene sentido configurar la directiva de actualización del almacén BCD para que se actualice cada 60 minutos.

Réplica de SQL Server
Hasta el momento, ha escalado BDD 2007 para replicar el recurso compartido de distribución de BDD y la imagen de arranque de WDS del servidor de implementación principal en cada uno de los servidores de implementación secundarios. Ahora necesita completar el proceso y replicar la base de datos de Deployment Workbench de BDD 2007 para que esté disponible de forma local en cada servidor de implementación.
SQL Server usa una metodología de réplica que en la documentación del producto se describe como no muy distinta a la manera en que se publican las revistas. En el caso de una revista, hay una editorial (publicador) que produce la revista, unos distribuidores que la distribuyen para la editorial y unos suscriptores que se suscriben y reciben la revista. SQL Server usa esta misma terminología para sus capacidades integradas de réplica.
Tenga en cuenta que, para ser un publicador de bases de datos de SQL Server, el servidor no puede ejecutar SQL Server Express Edition; debe usar una versión completa de SQL Server. Para el servidor de implementación principal, yo uso SQL Server 2005 (aunque SQL Server 2000 también es compatible). Para cada servidor de implementación secundario, puede usar SQL Server 2005 o bien SQL Server 2005 Express.
Antes de iniciar la configuración de la réplica de SQL Server, hay unos pocos pasos que debe completar para garantizar que SQL Server se haya configurado correctamente para admitir la réplica. Al aprovisionar los servidores de implementación, asegúrese de que los componentes de réplica se incluyan durante la instalación de SQL Server 2005 o SQL Server 2005 Express Edition. De forma predeterminada, SQL Server Express no instala los componentes de réplica.
Después, al permitir que el entorno de arranque de interacción mínima se conecte a SQL Server de forma remota, es necesario habilitar conexiones remotas en SQL Server. Para configurar SQL Server para conexiones remotas, inicie la herramienta de configuración de superficie de SQL Server, seleccione Configuración de superficie para servicios y conexiones, y configure el servidor para que acepte tanto conexiones locales como remotas de TCP/IP y canalizaciones con nombre.
A continuación, en el servidor de implementación principal, cree una carpeta compartida para guardar los datos de instantáneas de réplica que leen los agentes de réplica en cada servidor de implementación secundario. Me referiré a esta carpeta compartida más adelante. Suelo colocar esta carpeta en el mismo volumen que el resto del contenido de implementación.
Los pasos finales de instalación sólo son necesarios para SQL Server Express Edition en los servidores de implementación secundarios. De forma predeterminada, el servicio Explorador de SQL Server está deshabilitado. Para permitir la réplica, este servicio debe haberse establecido en automático y haberse iniciado. Use la herramienta Administrador de configuración de SQL Server para configurar este servicio. También debe crear una base de datos en los servidores secundarios en los que se replicará el contenido. Conviene que este nombre de base de datos sea igual que el nombre de la base de datos de BDD 2007 en el servidor de implementación principal, ya que así se minimiza la configuración adicional necesaria.

Configuración de la réplica
Ahora todo está listo para configurar la réplica de SQL Server. Para empezar, en el servidor de implementación maestro, en el que se debe ejecutar la versión completa de SQL Server 2005, inicie SQL Server Management Studio. El primer paso es crear y configurar una distribución. Para hacerlo, navegue a la carpeta de réplica de la consola de administración, como se muestra en la figura 6. Haga clic con el botón secundario en la carpeta de réplica y seleccione Configurar distribución para iniciar el asistente de distribución.
Figura 6 SQL Server Management Studio: Replicación
Figura 6 SQL Server Management Studio: Replicación
En el asistente, confirme que el servidor de implementación principal debe actuar como su propio distribuidor. Establezca la carpeta raíz de instantáneas para que sea la ruta de acceso UNC del recurso compartido de réplica de SQL Server creado anteriormente. Finalmente, establezca que el servidor de implementación principal se configure como publicador.
Cuando este asistente haya configurado correctamente el servidor como publicador y distribuidor, tendrá que indicar a SQL Server qué base de datos desea que se publique. Para hacerlo, haga clic con el botón secundario en la carpeta de réplica y haga clic en Propiedades del publicador. En el cuadro de diálogo de propiedades, seleccione Bases de datos de publicaciones y elija la base de datos de BDD 2007 para la réplica transaccional, como se muestra en la figura 7. En realidad, no se usa la réplica transaccional, pero se selecciona esa misma opción tanto si su intención es la réplica de instantáneas como la réplica transaccional.
Figura 7 Publicación de la base de datos
Figura 7 Publicación de la base de datos
Ahora debe crear una publicación a la que puedan suscribirse los servidores de implementación secundarios. En la carpeta de réplica, haga clic con el botón secundario en Publicaciones locales y haga clic en Nueva publicación para iniciar el asistente para publicación. Seleccione la base de datos de BDD como base de datos para publicar. Seleccione Réplica de instantáneas como tipo de publicación y especifique todas las tablas, los procedimientos almacenados y las vistas que se van a replicar. Debe optar por crear inmediatamente una instantánea inicial. Para programar al agente de instantáneas, es más que suficiente que esto se ejecute una vez al día de forma predeterminada, a menos que prevea hacer cambios frecuentes en la base de datos.
El paso final es suscribir cada uno de los servidores de implementación secundarios a esta publicación. Ello indica a SQL Server que extraiga una copia de la base de datos en intervalos especificados para cada servidor de implementación secundario. En la carpeta de réplica, en la subcarpeta Publicaciones locales, localice la publicación que se acaba de crear, haga clic con el botón secundario en ella y seleccione Nuevas suscripciones para iniciar el asistente de suscripciones. En este asistente, seleccione la publicación de BDD creada en los pasos anteriores como publicación elegida. Elija ejecutar todos los agentes en la distribución, habilitando la topología de réplica como suscripción de inserción. A continuación, agregue cada servidor de implementación secundario como suscriptor y nomine la base de datos creada en cada servidor para que reciba la copia de los datos replicados (recuerde que esta base de datos debe tener el mismo nombre que la base de datos de implementación principal). Finalmente, configure una cuenta para las conexiones y defina la programación para la réplica. Esto debe reflejar la programación que ha elegido para el agente de instantáneas. Hasta aquí, el paseo rápido por lo que se necesita para poner en funcionamiento la réplica de SQL Server. Verá cómo empiezan a replicarse los datos en menos de lo que cree.

Configuración de BDD 2007
Hasta ahora, ha configurado BDD 2007 para que use una base de datos y ha establecido la réplica de la base de datos y el recurso compartido de distribución de BDD 2007 en los servidores de implementación secundarios. Para completar la solución de implementación, debe configurar BDD 2007 de modo que, cuando un cliente descargue el entorno de arranque de BDD, se conecte automáticamente a cualquiera que sea su servidor de implementación local.
Cuando se arranca el entorno Windows PE con interacción mínima, si el cliente se ha arrancado desde un servidor WDS, se establece un valor de registro en Windows PE que almacena el nombre del servidor que el cliente acaba de descargar del entorno de arranque. Los scripts de implementación iniciales de BDD 2007 toman este valor y lo almacenan en una variable de entorno denominada %WDSServer%.
Tenga en cuenta que si usa la versión inicial de BDD 2007, puede encontrarse con que este valor no se rellena apropiadamente en el registro de Windows PE. Dispone de una actualización para corregir este comportamiento en support.microsoft.com/kb/937191.
Para configurar BDD 2007, edite simplemente los archivos de configuración BootStrap.ini y CustomSettings.ini, de manera que cualquier referencia al servidor de implementación se reemplace por %WDSServer%. Ello suele suponer el reemplazo de los valores para el nombre de instancia de SQL Server junto con el valor de DeploymentRoot, el servidor que guarda el recurso compartido de distribución. Puede ver un ejemplo del archivo Bootstrap.ini y un extracto de un archivo CustomSettings.ini en la figura 8 y la figura 9.
Figure 9 CustomSettings.ini (Close Figure 9)
[Settings]
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Properties=Manufacturer

[Default]
OSInstall=Y
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234

[CSettings]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CRoles]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Figure 8 Bootstrap.ini (Close Figure 8)
[Settings]
Priority=Default

[Default]
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234
SkipBDDWelcome=YES
Tenga en cuenta que esta solución establece tener WDS en el mismo servidor que almacena la base de datos replicada de BDD 2007 y el recurso compartido de distribución replicado de BDD 2007. Las razones son evidentes: ello permite usar la variable %WDSServer% para ofrecer un método sencillo a prueba de errores con el fin de indicar al equipo cliente dónde se encuentra el servidor de implementación local e impedir una respuesta a través de la WAN.

Consideraciones adicionales
La gran ventaja de BDD 2007 es que es extensible, así que hay muchos otros aspectos que pueden considerarse para extender esta solución. Por ejemplo, se podrían usar las capacidades integradas para supervisar SQL Server y DFS-R mediante el diseño de métodos para rellenar los equipos del entorno con información de una base de datos de administración de activos o incluso mediante el uso de un procedimiento almacenado de SQL para recuperar información de estas características. Lamentablemente, no dispongo de espacio para tratar todo esto aquí, pero espero haber aportado una visión de algunas de las maneras para aprovechar las capacidades de BDD en su propia organización.

Adam Shepherd es un consultor de Servicios de consultoría de Microsoft (Microsoft Consulting Services, MCS) en el Reino Unido. El enfoque técnico de Adam está en implementar, mantener y administrar el cliente de Windows. Puede ponerse en contacto con Adam en adamshep@microsoft.com.


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

Servidores Exchange de transporte perimetral en Microsoft: Segunda parte
Resumen:
  • Uso de registros y seguimientos en el transporte perimetral
  • Configuración contra correo electrónico no deseado con scripts
  • Pruebas en escenarios típicos de correo electrónico no deseado
Descargar el código de este artículo: Edge2007_11.exe (161KB)

Con la cantidad de correo electrónico no deseado y contenido malintencionado que circula por Internet, ¿cómo puede ofrecer mensajería confiable y segura a los usuarios de su organización? Una forma, que ya empecé a describir el mes pasado en la primera parte de esta serie, es implementar
servidores Exchange Server 2007 de transporte perimetral y Forefront Security para Exchange Server en una red perimetral entre Internet y su entorno de producción.
En esta entrega final, explicaré cómo analizar agentes de transporte perimetral en acción mediante funciones de registro y seguimiento estándar de Exchange Server 2007. También usaré un método personalizado para volcar todos los objetos de eventos de la canalización de transporte en archivos basados en XML. Después, ilustraré cómo aplicar configuración contra correo electrónico no deseado en un laboratorio de pruebas de transporte perimetral según la configuración que Microsoft usa en su propio entorno de producción corporativo. Por último, terminaré con algunos escenarios de prueba interesantes y realistas para ver cómo los agentes de transporte perimetral responden a varias situaciones de correo electrónico no deseado.
Para obtener más información sobre la instalación del laboratorio de pruebas de transporte perimetral y la arquitectura general de transporte perimetral, consulte el primer artículo de esta serie en el ejemplar de octubre de 2007 de TechNet Magazine, disponible en technetmagazine.com/issues/2007/10/Edge.
Hago un uso intensivo de scripts y archivos por lotes para automatizar las tareas de configuración más importantes. Puede encontrar estos scripts en la descarga de código que acompaña a este artículo (acuda a technetmagazine.com/code07.aspx). Además, para obtener información detallada de referencia sobre la configuración de TI de Microsoft respecto a los agentes de transporte perimetral, recomiendo las notas del producto "Transporte perimetral y protección de mensajería en Microsoft® Exchange Server 2007", producidas por Microsoft IT Showcase. Puede descargar estas notas del producto de IT Showcase en microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Registro y seguimiento
Exchange Server 2007 incluye varias funciones de registro y seguimiento, entre ellas, registro de protocolos, registro de agentes y seguimiento de la canalización, que facilitan el diagnóstico y la solución de problemas de agentes de transporte. Aunque en este artículo no me voy a ocupar exactamente de la solución de problemas de agentes de transporte, la información de registro y seguimiento es útil para examinar cómo funcionan los agentes de transporte perimetral.
Si quiere realizar un seguimiento de información acerca de actividades SMTP de envío y recepción, debería habilitar el registro de protocolos para los conectores de envío y recepción. Con el entorno de pruebas que configuré en la primera parte de esta serie (consulte la figura 1), habilité el registro de protocolos por medio del parámetro siguiente en los cmdlet New-SendConnector y New-ReceiveConnector:
Figura 1 El entorno de pruebas
Figura 1 El entorno de pruebas
–ProtocolLoggingLevel: Verbose
Puede encontrar los archivos de registro SMTP resultantes de forma predeterminada en subcarpetas bajo %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.
El registro de protocolos es útil si quiere analizar conversaciones SMTP, aunque los agentes contra correo electrónico no deseado no siempre interfieren con la sesión SMTP. Por ejemplo, el agente de filtro de contenido quizás sólo marque los mensajes entrantes con un valor de nivel de confianza contra correo no deseado (SCL). Mientras que el valor SCL esté por debajo de un umbral especificado (el valor predeterminado es 7), el agente de filtro de contenido no hará que el proceso de transporte perimetral rechace el mensaje. Por lo tanto, los progresos de conversación SMTP no resultan afectados.
Para analizar las acciones que los agentes contra correo electrónico no deseado (filtro de conexión, filtro de contenido, reglas perimetrales, filtro de destinatarios, filtro de remitentes e identificador de remitente) realizan en los mensajes que pasan por la canalización de transporte, necesita comprobar los registros de agentes en vez de los registros de protocolos. El registro de agentes se suele habilitar según el parámetro AgentLogEnabled en el archivo EdgeTransport.exe.config. De forma predeterminada, los registros de agentes se encuentran en la carpeta %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. Puede abrir los registros en Bloc de notas, aunque el cmdlet Get-AgentLog muestra la información de registro de agentes de forma más intuitiva en el Shell de administración de Exchange.
Otra función útil es el seguimiento de la canalización, que permite capturar instantáneas de mensajes de un remitente particular según los mensajes van pasando por la canalización de transporte. La idea es relativamente sencilla; el proceso de transporte perimetral crea una instantánea de cada mensaje antes y después de invocar agentes de enrutamiento y recepción SMTP registrados para los eventos OnEndOfHeaders, OnEndofData, OnSubmittedMessage y OnRoutedMessage. Al comparar las instantáneas de mensajes, puede ver cómo los agentes individuales modifican cada mensaje. Por supuesto, es imprescindible que habilite esta valiosa función en el entorno de pruebas.
El uso siguiente del cmdlet Set-TransportServer activa el seguimiento de canalización para un usuario de prueba. El parámetro PipelineTracingEnable establecido en $true habilita el seguimiento de la canalización. La dirección de correo electrónico del usuario de prueba se establece en el parámetro PipelineTracingSenderAddress:
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
Con el seguimiento de canalización habilitado, puede encontrar archivos de instantáneas para cada mensaje del remitente especificado (en este caso, Contoso.User@contoso.com) en la carpeta %ArchivosDePrograma\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Esta es la carpeta predeterminada. Para cada mensaje, los archivos de instantáneas se encuentran en un subdirectorio nombrado según un GUID asignado al mensaje. Tenga en cuenta que puede encontrar el mensaje original en un archivo llamado Original.eml y copias del mensaje en archivos .eml que empiezan con SmtpReceive o Routing según los eventos encontrados y los agentes instalados. Para analizar el procesamiento de agentes contra correo electrónico no deseado registrados para los eventos de recepción SMTP OnEndofData y OnEndOfHeaders, compruebe los archivos .eml SmtpReceive*. Para analizar el procesamiento de antivirus y otros agentes registrados para los eventos de enrutamiento OnSubmittedMessage y OnRoutedMessage, analice los archivos .eml Routing*.

Volcado de canalización personalizado
Las funciones de registro y seguimiento de agente estándar de Exchange Server 2007 satisfacen todas las necesidades de solución de problemas a pesar de que las funciones estándar no cubren todos los eventos de transporte. Por ejemplo, el seguimiento de canalización no puede capturar información acerca de OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand ni de eventos de transporte semejantes, porque el host de envío aún no ha transferido ningún mensaje que podría escribirse en la carpeta %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Si desea capturar información detallada acerca de estos eventos, necesita implementar un agente personalizado que vuelque los datos de evento en archivos del sistema de archivos.
Como vimos en mi artículo anterior, no es complicado crear agentes personalizados, así que no he podido resistir la tentación de crear un agente de recepción SMTP y un agente de enrutamiento para volcar todos los objetos de evento de la canalización de transporte en archivos XML. Encontrará un proyecto correspondiente de Microsoft Visual Studio® 2005 llamado PipelineXMLDump en la descarga disponible para este artículo. Los dos archivos importantes son DumpAgents.cs, que implementa las fábricas de agente y los agentes, y XMLDump.cs, que implementa una clase auxiliar para escribir los campos de objetos de origen y argumento de eventos por medio de métodos System.Re- flection en archivos XML. Si compila el código fuente y copia el archivo PipelineXMLDump.dll resultante en una carpeta llamada C:\PipelineXMLDump en el servidor de prueba de transporte perimetral, puede registrar y habilitar los agentes personalizados con los scripts RegisterPipelineXMLDump.ps1 y EnableDumpAgents.ps1. Los scripts están incluidos en la carpeta de proyecto PipelineXMLDump de la descarga. Por supuesto, mis agentes personalizados tienen únicamente propósitos ilustrativos, no se han probado lo suficiente y no se deben instalar nunca en un servidor de producción. La responsabilidad del uso de estos agentes queda por entero con el usuario.
DumpAgents.cs muestra cómo implementar todos los controladores de eventos de enrutamiento y recepción SMTP compatibles con la canalización de transporte. Este puede ser un buen punto de partida si quiere implementar sus propios agentes personalizados. Mis agentes de volcado escriben archivos XML en subcarpetas bajo %ArchivosDePrograma%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump que corresponden al identificador de la sesión SMTP (agente de recepción SMTP) o al identificador del mensaje (agente de enrutamiento). La figura 2 presenta un ejemplo de información de argumento de eventos transmitida al agente de recepción SMTP en el controlador OnConnectEvent. El ejemplo revela el extremo IP local (puerto y dirección IP) que aceptó una solicitud de conexión entrante.
Figura 2 Información del argumento volcada durante el evento OnConnect
Figura 2 Información del argumento volcada durante el evento OnConnect

Preparación de las pruebas
Ya hemos visto suficiente teoría acerca del registro, el seguimiento y el volcado. Preparémonos para la ejecución de algunas pruebas que muestran agentes contra correo electrónico no deseado en acción. El siguiente es un resumen breve que refleja la configuración de TI de Microsoft de la forma más precisa posible en su entorno de pruebas. Como mencioné anteriormente, hay información de referencia disponible en las notas del producto "Transporte perimetral y protección de mensajería en Microsoft Exchange Server 2007".
Empiece por desactivar el agente de reescritura de direcciones de la bandeja de entrada, el agente de filtro de datos adjuntos y el agente de reescritura de direcciones de la bandeja de salida mediante la ejecución del script EDGE01_disable_agents.ps1 de la descarga. La reescritura de direcciones no es necesaria, porque los destinatarios usan las mismas direcciones de correo electrónico interna y externamente. No uso el agente de filtro de datos adjuntos porque hay funciones de filtrado de datos adjuntos superiores en Forefront Security.
El entorno de pruebas no está conectado a Internet. Esto dificulta la comprobación del agente de filtro de conexión. Para remediar el problema, puede crear una lista de direcciones IP bloqueadas en el host de Internet mediante la ejecución del archivo INTERNET01_create_IP_block_list.bat. Asegúrese de que tiene instaladas las herramientas de soporte de Windows®, ya que incluyen la herramienta de línea de comandos DNS (dnscmd.exe). De lo contrario, tendrá que emplear tiempo creando los registros DNS manualmente con la consola DNS.
Ahora puede configurar el agente de filtro de conexión mediante la ejecución del script EDGE01_add_block_list_provider.ps1. Este script agrega un proveedor de la lista de direcciones IP bloqueadas para ip-bl.consolidatedmessenger.com. Esta es la lista de direcciones IP bloqueadas de Consolidated Messenger, ya creado en el entorno de pruebas con la ejecución del archivo INTERNET01_create_IP_block_list.bat en el host de Internet, como mencionamos anteriormente. La configuración de TI de Microsoft usa también la lista de direcciones IP bloqueadas y la lista de direcciones IP permitidas, pero estas funciones no requieren configuración manual. Es importante tener en cuenta que la configuración de TI de Microsoft no usa proveedores de la lista de direcciones IP permitidas.
A continuación, configure el agente de filtro de destinatarios mediante la ejecución del script EDGE01_recipient_filter.ps1 para bloquear mensajes a destinatarios inexistentes, así como mensajes a buzones y listas de distribución global que son sólo para uso interno o de salida.
El agente de filtro de remitentes necesita también una actualización de la configuración. La configuración de TI de Microsoft usa filtrado de remitentes como medida contra ataques de inundación de correo desde direcciones de remitente específicas y para bloquear ciertos servidores de la lista y orígenes semejantes que no se consideran relevantes para el negocio. Además, la configuración de TI de Microsoft usa filtrado de remitentes para bloquear mensajes con información de remitente no válida o ausente. Apliquemos esta configuración al entorno de pruebas con la ejecución del script EDGE01_sender_filter.ps1 en el servidor del transporte perimetral.
Necesita también configurar registros de marco de directivas de remitente (SPF) en DNS, si quiere reflejar la configuración de TI de Microsoft. Para generar un registro SPF que confirme la autoridad de su servidor de transporte perimetral para mensajes de su dominio, adventure-works.com, puede usar el Asistente para el registro SPF de identificador de remitentes de Microsoft disponible en microsoft.com/mscorp/safety/content/technologies/senderid/wizard. Pruébelo y especifique un nombre de dominio de Internet existente. En el entorno de pruebas, puede ejecutar el archivo INTERNET01_create_SPF_record.bat en el host de Internet.
Ya está. No hace falta configurar parámetros adicionales, porque la mayor parte de los agentes incluyen una configuración predeterminada razonable. Para realizar una comprobación rápida de la configuración predeterminada más importante para los agentes de reglas perimetrales, identificador de remitente, análisis de protocolo y filtro de contenido, ejecute el script EDGE01_check_defaults.ps1 en el servidor de transporte perimetral.

Agentes de transporte perimetral en acción
Ahora, pongamos los agentes de transporte perimetral a trabajar en algunos escenarios realistas de mensajería. Para enviar mensajes de prueba al servidor de transporte perimetral, uso el servicio POP3 y SMTP incluido en Windows Server 2003 y Outlook® Express como cliente de mensajería, con la configuración predeterminada gran parte del tiempo, pero con el registro habilitado.
Pero primero, una advertencia: no siga ninguno de estos pasos ni ejecute los scripts descritos en esta sección si su entorno de pruebas tiene alguna conexión a sistemas de producción o a Internet. Una vez más, la responsabilidad es suya.
El primer agente que voy a probar es el agente de filtro de conexión. Merece ser el primero, porque es el agente que trabaja más duro en un servidor de transporte perimetral. En Microsoft, el agente de filtro de conexión bloquea aproximadamente el 88 por ciento de todos los envíos de mensajes de Internet. De 13 millones de intentos de envío en un día normal, sólo alrededor de 1,5 millones son de remitentes legítimos.
Así que enviemos un mensaje de correo electrónico como Fabrikam.User@Fabrikam.com a Administrator@adventure-works.com. Si las cosas funcionan apropiadamente, el administrador no recibirá el mensaje. En su lugar, Fabrikam.User recibirá una notificación de estado de entrega (DSN) para indicar que la entrega no se ha realizado. Fabrikam.User comprueba que la dirección de correo electrónico es correcta, envía de nuevo el mensaje y, una vez más, Fabrikam.User recibe una DSN. Entonces, Fabrikam.User se pone en contacto con el departamento de soporte técnico y notifica el problema. No es el primer usuario que tiene este problema. De hecho, ningún usuario de Fabrikam se puede comunicar con Adventure Works. Algo ha sucedido. El problema es urgente. Para resolverlo rápidamente, compruebe los registros SMTP en la carpeta %systemroot%\system32\Logfiles\SMTPSVC1 de INTERNET01 y, como muestra el texto rojo en la figura 3, ahí está.
Figure 3 Los registros SMTP muestran el problema. (Close Figure 3)
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,
El error 550 indica que Consolidated Messenger puso la dirección IP de su host de Internet en una lista de direcciones IP bloqueadas. Bueno. Entonces, se pone en contacto con Consolidated Messenger para que modifiquen la lista. Pero resulta que es más fácil entrar en la lista de direcciones IP bloqueadas de Consolidated Messenger que salir. Se tardará días, si no semanas, en solucionar el problema.
Necesita ayuda más rápidamente, así que se pone en contacto con Adventure Works a través de la dirección de correo electrónico cmipbl@adventure-works.com. Envía un mensaje de correo electrónico como Fabrikam.Admin@Fabrikam.com, describe la situación y solicita el desbloqueo de la dirección IP de Internet de su host (en este caso, 192.168.1.100). Después de comprobar su identidad, Adventure Works desbloquea la dirección mediante el uso del comando siguiente para conceder una excepción temporal que expira automáticamente a los 30 días:
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
Treinta días deberían ser suficientes para arreglar las cosas con Consolidated Messenger, y Adventure Works no necesita emplear tiempo en el mantenimiento manual de la excepción. Al conceder excepciones de expiración automática, Adventure Works conserva al mínimo la carga administrativa asociada con el mantenimiento de listas de direcciones IP permitidas.

Remitentes seguros
Ahora, probemos el reconocimiento de remitentes seguros del filtrado de contenido, una función nueva e interesante que aumenta la precisión del filtrado de correo electrónico no deseado. EdgeSync propaga información de remitentes seguros del entorno interno en formato con hash y cifrado a los servidores de transporte perimetral. El agente de filtro de contenido usa esta información durante el proceso de filtrado para tomar decisiones con fundamento. Sólo necesita obtener la información de remitentes seguros (es decir, la lista de remitentes seguros, la lista de destinatarios seguros, la lista de remitentes bloqueados y los contactos externos) en Active Directory® con el cmdlet Update-SafeList y la réplica de la información al servidor de transporte perimetral mediante el cmdlet Start-EdgeSynchronization. El departamento de TI de Microsoft ejecuta el cmdlet Update-SafeList con una frecuencia programada fuera de horas punta. En nuestro entorno de pruebas, es suficiente ejecutar un script correspondiente (HUB-MBX-01_update_safelist.ps1) de forma manual.
Primero, preparemos el entorno de pruebas con la ejecución del script EDGE01_clean_up.ps1 en el servidor de transporte perimetral para quitar la entrada de la lista de direcciones IP permitidas creada anteriormente. Esto es necesario porque el agente de filtro de contenido no se aplica a mensajes de orígenes que están en esta lista. A continuación, quite la entrada de la lista de direcciones IP bloqueadas correspondiente a 100.1.168.192.ip-bl.consolidatedmessenger.com de la lista de bloqueo de Consolidated Messenger mediante la ejecución del archivo INTERNET01_clean_up.bat en el host de Internet. De otro modo, el host simulado de Internet no podrá enviar los mensajes, como ya demostramos.
Finalmente, envíe un mensaje que el agente de filtro de contenido seguramente considerará correo no deseado. Esto es complicado, porque el agente de filtro de contenido usa el umbral de rechazo SCL predeterminado para entregar la mayoría de los mensajes a los usuarios y reducir al mínimo falsos positivos. Sin embargo, después de algunas pruebas, encontré un mensaje que incrementa la clasificación de SCL hasta el nivel de rechazo. Para enviar el mensaje como Contoso.User@Contoso.com, ejecute el script INTERNET01_contoso_msg.vbs en el host de Internet.
Mi script usa una conexión SMTP anónima para enviar el mensaje al servicio SMTP en INTERNET01. Para que funcione, necesita configurar el servicio SMTP para retransmitir mensajes a usuarios anónimos. En Administrador de IIS, abra las propiedades para el servidor virtual SMTP predeterminado. En la ficha Acceso, haga clic en el botón Retransmisión y seleccione Todo menos la lista siguiente. Hablaré de las implicaciones de esta configuración en un momento.
Cuando ejecute el script para enviar este mensaje, Contoso.User recibirá una DSN que indica que la entrega produjo un error con el código de diagnóstico: smtp;550 5.7.1, correspondiente a mensajes rechazados por restricciones de contenido. También puede ver esta respuesta en el registro SMTP del host de Internet, y si ejecuta el comando Get-AgentLog | Select-Object -Last 1 en el servidor de transporte perimetral para mostrar la última entrada del registro de agentes, podrá ver que el mensaje se rechazó porque su clasificación de SCL era 7, como muestra la figura 4.
Figura 4 Mensaje bloqueado debido a restricciones de contenido
Figura 4 Mensaje bloqueado debido a restricciones de contenido
Ahora, Contoso.User no es remitente de correo no deseado. Es lamentable que su mensaje no se aceptara en este caso, pero Contoso.User se puede comunicar generalmente con destinatarios en Adventure Works. Así que Contoso.User informa al administrador en otro mensaje de correo electrónico que su mensaje original se bloqueó por error. El administrador conoce a Contoso.User y, para garantizar que los filtros de correo no deseado no bloquean sus mensajes en el futuro, el administrador incluye a Contoso.User en la lista de remitentes seguros. Para hacer esto en Office Outlook 2007, haga clic con el botón secundario en un mensaje recibido de Contoso.User, seleccione Correo electrónico no deseado y haga clic en Agregar el remitente a la lista de remitentes seguros.
Con el intervalo usual, el cmdlet Update-SafeList se ejecuta para actualizar la información de la lista de remitentes seguros en Active Directory y, después de la sincronización perimetral siguiente, Contoso.User se podrá comunicar con el administrador sin falsos positivos. Para simular este procedimiento, ejecute el script HUB-MBX-01_update_safelist.ps1.
Ahora ejecute el script INTERNET01_contoso_msg.vbs para enviar el mensaje de Contoso.User otra vez. Compruebe después el registro de agentes en el servidor de transporte perimetral con el comando Get-AgentLog | Select-Object -Last 1 y, bajo ReasonData, podrá ver que el filtrado de contenido quedó eludido. Se acabaron los falsos positivos para Contoso.User.

Ataques de correo electrónico no deseado
Para concluir las pruebas, tirémoslo todo por la borda. Como sin duda habrá advertido, configuré el host de Internet durante la prueba anterior como relé abierto, que abre la puerta a remitentes de correo no deseado. Así que ahora veamos lo que sucede si Spam.Sender@cohovineyards.com advierte esta configuración deficiente y abusa del host para enviar miles de mensajes de correo no deseado a Adventure Works. El script INTERNET01_spam_msg.vbs sólo envía un mensaje de correo no deseado, pero puede editar el script y cambiar el valor max_loop para generar más.
Para simular un ataque de correo no deseado, envié 1.000 mensajes a mi host para la transmisión al servidor de transporte perimetral. El servicio SMTP limita el número de mensajes por conexión de salida a 20, así que llevó algún tiempo transmitir un número suficiente de mensajes de correo no deseado para que el agente de análisis de protocolo del servidor de transporte perimetral entrara en acción.
El agente de análisis de protocolo ayuda al agente de filtro de conexión con el mantenimiento automático de las entradas de la lista de direcciones IP bloqueadas en base al análisis de protocolo SMTP y a las actualizaciones de reputación IP de Microsoft Update. En este caso, el análisis del protocolo SMTP atrapó los mensajes de correo electrónico no deseado. El agente de análisis de protocolo realiza un seguimiento de la clasificación de SCL de cada mensaje para calcular un valor SCL medio que usa para determinar el nivel de reputación de un remitente (SRL). Según iban llegando cada vez más mensajes ilegítimos durante mi campaña simulada de correo no deseado, el SRL del host de Internet fue aumentando hasta superar el umbral de bloqueo SRL. Como resultado, el host acabó en la lista de direcciones IP bloqueadas durante 24 horas. Se acabó el correo electrónico no deseado de este host. Sucedió automáticamente. No fue necesaria la intervención del administrador.
La figura 5 muestra la entrada resultante de la lista de direcciones IP bloqueadas y los cambios correspondientes en el tratamiento de los mensajes. Antes del bloqueo del host, el servidor de transporte perimetral rechazaba cada mensaje de correo no deseado durante el evento OnEndOfData porque el agente de filtro de contenido respondía a cada mensaje según el umbral de SCL (vea la figura 4 como referencia). El mensaje se envió, pero no se entregó correctamente. Tras el bloqueo del host, la conexión quedó rechazada durante el evento OnMailCommand por parte del agente de filtro de conexión. Los mensajes ya no se envían. Ahorra ancho de banda de la red y recursos de procesamiento para desconectar a remitentes de correo no deseado antes de la entrega de los mensajes.
Figura 5 Bloqueo de un host de Internet remitente de correo no deseado
Figura 5 Bloqueo de un host de Internet remitente de correo no deseado

Más pruebas
Por supuesto, hay más funciones y escenarios de agentes que puede probar. Por ejemplo, puede probar el filtrado de remitentes mediante el envío de mensajes como Blocked.User@Contoso.com o Blocked.User@Fabrikam.com. Puede probar el filtrado de destinatarios mediante el envío de mensajes a Blocked.User@adventure-works.com. También puede usar Telnet para simular ataques de recolección de directorios con intervalos de retraso diferentes. La configuración de TI de Microsoft usa el intervalo predeterminado de cinco segundos para respuestas 5yz de SMTP en el conector de recepción de cara a Internet, tiempo suficiente para que el departamento de TI de Microsoft pueda convertir los intentos de recolección de directorios en ataques frustrados. Pero puede aplicar valores diferentes con el cmdlet Set-ReceiveConnector, como demuestra el script EDGE01_tarpitting.ps1.
Puede ir más allá y consultar los archivos de instantáneas creados por el seguimiento de canalización para los mensajes de Contoso.User@Contoso.com. Compruebe las marcas antivirus, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, que Forefront Security usa para marcar los mensajes según se examinan. Cuando Forefront Security en el servidor de transporte de concentradores encuentra esta marca con información de versión reciente, no tiene que examinar el mensaje una segunda vez. Si trata de eludir Forefront Security al insertar marcas antivirus falsas en sus mensajes de prueba, verá el firewall de encabezados en acción: quitará estas marcas justo después del evento OnDataCommand, mucho antes de que se active el evento OnSubmittedMessage que invoca al agente de enrutamiento de FSE.
Mientras consulta los encabezados de mensajes en los archivos de instantáneas, quizás desee crear un registro de prueba SPF para Contoso.com que identifique una dirección IP incorrecta como remitente legítimo. Una forma de conseguirlo es ejecutar el archivo INTERNET01_wrong_SPF_record.bat en el host de Internet. Después, debería enviar un mensaje de prueba como Contoso.User@Contoso.com y examinar los encabezados X-MS-Exchange-Organization-SenderIdResult y Received-SPF:
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Conclusión
Como ha visto en este artículo y en el anterior, los servidores de transporte perimetral de Exchange Server 2007 vienen con un conjunto completo de agentes de transporte para implementar funciones contra correo electrónico no deseado confiables y de gran precisión, entre ellas, filtrado de conexión, análisis de protocolo y filtrado de contenido. La arquitectura de transporte es extensible y compatible con la implementación de agentes adicionales para obtener funcionalidad ampliada. El agente de enrutamiento FSE es un buen ejemplo de un agente adicional que integra Forefront Security para Exchange Server en la arquitectura de transporte.
En combinación con funciones adicionales, por ejemplo, retraso de la conexión, firewall de encabezados, TLS y autenticación, los servidores de transporte perimetral ofrecen los medios necesarios para lograr un nivel muy alto de protección de la mensajería en múltiples niveles y sin puntos únicos de posibles errores. Con la implementación de servidores de transporte perimetral y Forefront Security en una red perimetral, de forma estrictamente independiente de su organización interna del servidor Exchange, puede mantener el contenido malintencionado e ilegítimo lejos de su entorno de mensajería al tiempo que realiza la entrega de mensajes legítimos a los usuarios con tasas de falsos positivos muy bajas.

Kay Unkrothes una empresaria 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.


 Redes: Configurar el acceso remoto VPN con ISA Server 2006
Redes Alan Maddison

Configurar el acceso remoto VPN con ISA Server 2006
Resumen:
  • Protocolos VPN
  • Configuración de una conexión VPN de sitio a sitio
  • Configuración de una conexión VPN de acceso remoto
  • Nuevas funciones en ISA Server 2006

Las redes privadas virtuales proporcionan altos niveles de adaptabilidad, escalabilidad y control sobre la conectividad de red. Además de mejorar la seguridad, pueden dar lugar a ahorros considerables
en comparación con las conexiones dedicadas tradicionales de punto a punto. Además, son flexibles.
Hay muchos tipos de VPN. Algunos se usan para conectar usuarios móviles a la red corporativa; otros sirven para conectar dos redes separadas geográficamente. Los protocolos que usan y las funciones que ofrecen estas VPN diferentes varían. Algunas proporcionan funciones de seguridad, como autenticación y cifrado, mientras que otras quizás no incluyan funciones de seguridad en absoluto. Y, obviamente, algunas son más fáciles de configurar y administrar que otras.
En este artículo, trataré la implementación de una VPN mediante ISA Server 2006. En particular, me centraré en la utilidad de VPN con ISA en dos escenarios comunes: como forma de ofrecer conexiones VPN de acceso remoto a los usuarios y como forma de ofrecer conexiones VPN de sitio a sitio. Ambas implementaciones incluyen características de seguridad para garantizar la privacidad de los datos y ofrecer protección a los recursos de red internos.
En la primera situación (conexión VPN de acceso remoto), un cliente remoto inicia una conexión VPN al servidor ISA a través de Internet. A continuación, el servidor ISA conecta el cliente remoto a su red interna, lo que ofrece al usuario acceso continuo a los recursos de la red interna, incluidos datos y aplicaciones. La segunda situación (conexión VPN de sitio a sitio) es algo más compleja debido al uso de un enrutador, que puede ser el servidor ISA mismo. No obstante, permite la conexión sin fisuras entre oficinas o sucursales diferentes o de todas ellas con la oficina central.
Hay varios beneficios adicionales derivados del uso de ISA Server 2006 para implementar una VPN. Uno de los más importantes se debe a la naturaleza integrada de ISA Server, que implica que la funcionalidad de VPN y la funcionalidad del firewall trabajan en estrecha colaboración. Además, ISA Server incluye una característica de cuarentena de VPN que usa la función Control de cuarentena de acceso a red de Windows Server® 2003 para poner en cuarentena los equipos de acceso remoto hasta que un script del servidor valida su configuración. Esto agrega otro nivel de protección al proporcionar un modo de comprobar cosas como el estado de la definición antivirus y la directiva local del firewall en el equipo remoto antes de otorgarle acceso a los recursos de red internos.
Los principales beneficios administrativos que ofrece ISA Server como solución de VPN incluyen la administración centralizada de directivas y las capacidades de supervisión, registro y notificación. En relación con sus responsabilidades administrativas diarias, el valor de estas capacidades puede ser incalculable. En particular, las funciones de supervisión en tiempo real y filtrado de registros ofrecen transparencia fundamental del tráfico en la red y de las conexiones realizadas a través de ISA Server.

Protocolos VPN
Los protocolos de túnel básicos que se usan en una conexión VPN con ISA constituyen la primera línea de defensa para proteger las conexiones. ISA Server es compatible con tres protocolos: el Protocolo de túnel de nivel dos (L2TP) a través de IPsec, el Protocolo de túnel punto a punto (PPTP) y el modo de túnel IPsec. Este último protocolo sólo se admite en conexiones de sitio a sitio y se usa principalmente para la interoperabilidad con enrutadores y otros sistemas operativos que no son compatibles con L2TP o PPTP.
L2TP se vincula a IPsec porque L2TP no cuenta con un mecanismo propio para ofrecer privacidad de datos. Junto con IPsec, puede ofrecer métodos eficaces de autenticación y cifrado; la combinación se convierte en una solución atractiva. PPTP usa la versión 2 del Protocolo de autenticación por desafío mutuo de Microsoft® (MS CHAP) o el Protocolo de autenticación extensible-Seguridad del nivel de transporte (EAP-TLS) para la autenticación, y el Cifrado punto a punto de Microsoft (MPPE), obviamente, para el cifrado.
La selección por parte de las empresas de L2TP a través de IPsec o de PPTP a menudo depende de factores que son específicos a cada organización. L2TP a través de IPsec permite usar cifrado más complejo y sofisticado, y es compatible con más tipos de redes (incluidas IP, X.25, Frame Relay y ATM). Sin embargo, PPTP es más fácil de implementar y suele tener menos requisitos. Dicho esto, en situaciones libres de restricciones organizativas, la implementación de L2TP a través de IPsec es una práctica recomendada.

Conexiones VPN de sitio a sitio
ISA Server 2006 supone un progreso tremendo a la hora de simplificar la configuración de VPN de sitio a sitio. En versiones anteriores, era necesario realizar muchos más pasos. En este ejemplo, haré referencia a un único sitio remoto que conecta a una oficina central mediante el uso de L2TP a través de IPsec con un servidor ISA en ambas ubicaciones. El proceso requiere la configuración del servidor ISA en la oficina central antes de configurar el sitio remoto.
El primer paso en el proceso es configurar las cuentas de usuario locales requeridas en ambos servidores ISA. Esta identidad de usuario proporcionará el contexto de seguridad para la conexión al servidor remoto o al servidor ISA principal. El nombre de esta cuenta debe coincidir con el nombre de la conexión VPN creada en la consola de administración de ISA. Por ejemplo, una buena convención de nomenclatura sería establecer el nombre de usuario "Site VPN" (VPN en sitio) en el servidor ISA de la oficina central (que señala al sitio remoto) y "HQ VPN" (VPN en oficina central) en el servidor ISA remoto. Una vez que ha creado estas cuentas, acuda a las propiedades de cuenta, abra la ficha Marcado y asegúrese de que la opción Permitir acceso está seleccionada.
Después de crear la cuenta de usuario local, el paso siguiente es crear el certificado de la infraestructura de claves públicas (PKI) que se usará para la autenticación entre los dos sitios. Tiene la opción de usar una clave pre-compartida, pero el uso de un certificado es siempre un método preferible. La manera más sencilla de instalar un certificado para una conexión VPN es conectar directamente a su propia entidad de certificación empresarial y solicitar un certificado a través del sitio web del servidor de certificados. Pero, para ello, es posible que necesite crear una regla de acceso con el fin de permitir al servidor ISA conectar con el servidor de certificados a través de HTTP.
Si conoce las versiones anteriores de ISA Server, advertirá que la interfaz de ISA Server 2006, mostrada en la figura 1, es mucho más intuitiva. Al seleccionar VPN en el panel de la izquierda, aparecen opciones contextuales de configuración y tareas en los paneles del centro y de la derecha.
Figura 1 La interfaz de ISA Server 2006 es más intuitiva.
Figura 1 La interfaz de ISA Server 2006 es más intuitiva.
Inicie el Asistente para VPN de sitio a sitio. Para ello, haga clic en la tarea Crear conexión VPN de sitio a sitio en el panel de la derecha. El asistente solicitará un nombre para la red de sitio a sitio. Este nombre debe coincidir con el nombre de la cuenta de usuario que creó previamente. Después de escribir el nombre, haga clic en el botón Siguiente. En la pantalla siguiente (consulte la figura 2), seleccione el protocolo VPN que desea usar; en mi ejemplo, se trata de L2TP a través de IPsec. Haga clic en Siguiente y el asistente le advertirá que debe haber disponible una cuenta de usuario que coincida con el nombre de la red. Como ya se ha ocupado de esto, haga clic en Aceptar para pasar a la pantalla siguiente.
Figura 2 Seleccione el protocolo VPN que desea usar.
Figura 2 Seleccione el protocolo VPN que desea usar.
Ahora, debe crear un grupo de direcciones IP. Tiene dos opciones: puede crear un grupo de direcciones estáticas en el servidor ISA o puede usar su servidor DHCP existente para administrar la asignación de direcciones. Ambos métodos son aceptables, de modo que su decisión debería guiarse por los procedimientos de la compañía referentes a esta opción particular. La pantalla le solicitará que especifique el nombre del servidor remoto. Escriba el nombre de dominio completo del servidor remoto y, seguidamente, proporcione las credenciales de usuario para la conexión. Recuerde que tiene que especificar la información de la cuenta de usuario que creó en el servidor ISA remoto. En este ejemplo, sería la cuenta de usuario HQ VPN, como se muestra en la figura 3.
Figura 3 Escriba el nombre de dominio completo del servidor remoto.
Figura 3 Escriba el nombre de dominio completo del servidor remoto.
En la pantalla siguiente, seleccione el método de autenticación saliente. (Como ya he mencionado con anterioridad, siempre es preferible usar un certificado.) A continuación, indique el intervalo de direcciones IP que se usa en la red interna del sitio remoto.
Después, si usa ISA Server 2006 Enterprise Edition, el asistente le permitirá configurar las direcciones IP dedicadas de equilibrio de carga de red del sitio remoto. Si usa ISA Server 2006 Standard Edition, omita el paso de equilibrio de carga y pase directamente a la pantalla siguiente (consulte la figura 4), que es donde creará la regla de red para dirigir el tráfico del sitio remoto a la red local.
Figura 4 Cree la regla de red que distribuye el tráfico.
Figura 4 Cree la regla de red que distribuye el tráfico.
También deberá crear una regla de acceso, que es el siguiente paso del proceso. Durante la configuración de la regla de acceso, hay tres opciones en cuanto a los protocolos de permiso que se pueden usar: puede permitir todo el tráfico saliente, puede permitir todo el tráfico saliente a excepción de ciertos protocolos o puede permitir sólo ciertos protocolos. En la mayoría de las situaciones, le convendrá seleccionar la opción de todo el tráfico saliente.
Ya casi ha terminado. En este momento, el asistente presentará un resumen de la configuración y, en cuanto haga clic en el botón Finalizar, se habrá creado la conexión VPN de sitio a sitio. Se abrirá un cuadro de diálogo que indica la necesidad de habilitar una regla de directiva del sistema para realizar descargas de la lista de revocación de certificados. Haga clic en Sí para habilitar esta regla. Seguidamente, el asistente ofrecerá información acerca de pasos adicionales de configuración que podrían ser necesarios. Cuando haya completado la configuración de ISA Server en el sitio principal, deberá seguir los mismos pasos para configurar el sitio remoto. Cuando se han completado los dos pasos, los usuarios de ambos sitios podrán comunicarse a través de la VPN.

Conexión VPN de acceso remoto
La configuración de una conexión VPN de acceso remoto para el acceso de clientes es mucho más sencilla (consulte la figura 5). El primer paso consiste en seleccionar VPN en el panel de la izquierda en la consola de administración de ISA Server. Seleccione la tarea Habilitar acceso de clientes de VPN en el panel de la derecha. Recibirá una advertencia de que esto puede provocar el reinicio del servicio Enrutamiento y acceso remoto. Debido a que esto podría causar problemas de conexión, quizás sea conveniente implementar este cambio durante un período de mantenimiento programado. Haga clic en Aceptar para dejar atrás esta advertencia; ISA Server habilita una directiva del sistema que permite el acceso del tráfico de clientes de VPN al servidor ISA. Para ver esta regla, seleccione Directiva de firewall en la consola de administración de ISA Server y elija la tarea Mostrar reglas de directivas del sistema.
Figura 5 Configure una conexión VPN de acceso remoto.
Figura 5 Configure una conexión VPN de acceso remoto.
También se habilita una regla de red predeterminada para posibilitar el enrutamiento entre la red interna y las dos redes VPN (clientes de VPN y clientes de VPN en cuarentena). Para ver o editar esta regla de red seleccione Redes en el panel izquierdo y abra la ficha Reglas de red en el panel central.
Ahora, deberá configurar el acceso de clientes de VPN. Hay tres parámetros adicionales que se deben configurar: los grupos de seguridad de Windows que tienen permitido el acceso, los protocolos que pueden usar los clientes y la asignación de usuarios. El cuadro de diálogo para configurar estos parámetros se muestra en la figura 6.
Figura 6 Configure el acceso de clientes de VPN.
Figura 6 Configure el acceso de clientes de VPN.
La ficha Grupos requiere simplemente que seleccione los grupos de Windows que deben disponer de acceso remoto a través de VPN. Desde una perspectiva administrativa, creo que es buena idea contar con un solo grupo con este permiso. Esto simplifica la administración del acceso remoto.
La ficha Protocolos muestra que sólo PPTP está habilitado de forma predeterminada. Definitivamente debería habilitar L2TP a través de IPsec si esto es posible en su entorno.
La asignación de usuarios permite asignar cuentas de usuario de espacios de nombres, como el Servicio de autenticación remota telefónica de usuario (RADIUS), a cuentas de Windows para garantizar que las directivas de acceso se aplican correctamente. Habrá terminado en cuanto haya completado estas opciones de configuración y haya aplicado los cambios a ISA Server. A partir de este momento, los clientes tendrán acceso continuado a los datos y las aplicaciones de la red interna mediante una conexión VPN.

Mejoras en ISA Server 2006
ISA Server 2006 incluye varias mejoras que suponen un incremento de la eficacia y el rendimiento con respecto a versiones anteriores. Estas características, entre ellas, la compresión HTTP, la compatibilidad con el Servicio de transferencia inteligente en segundo plano (BITS) y la calidad del servicio (QoS), ofrecen varias técnicas para optimizar el uso de la red. Por supuesto, aun con estas técnicas, debería continuar usando las tecnologías comunes de optimización del ancho de banda que son básicas en ISA Server, incluido el almacenamiento en caché.
La compresión HTTP ha recibido compatibilidad en varios productos de Microsoft durante ya algún tiempo (por ejemplo, ha estado presente en Internet Explorer® desde la versión 4 y en Windows Server desde Windows® 2000). Sin embargo, esta es la primera versión de ISA Server que admite la compresión HTTP, además de los algoritmos GZIP y Deflate estándar del sector.
¿Qué significa esto? Gracias a la compatibilidad con la compresión HTTP, un explorador web en conformidad con HTTP 1.1 puede solicitar contenido comprimido de cualquier sitio web. Pero recuerde que sólo se comprimen las respuestas, no las conexiones salientes iniciales del cliente.
La compresión HTTP es una configuración global de la directiva HTTP aplicable a todo el tráfico HTTP que pasa por ISA Server; no está asociada a una regla de red específica. Sin embargo, tiene la opción de implementar la compresión HTTP con cada escucha (puede configurarla mediante el Asistente para escucha de web).
La compresión HTTP, a la que se puede obtener acceso a través de la opción General en el panel de la izquierda, está habilitada de forma predeterminada. Pero, como muestra la figura 7, tendrá que configurar los elementos de la red donde se usará la compresión. Retomemos el ejemplo de VPN de sitio a sitio. Necesita seleccionar la ficha Devolver datos comprimidos y agregar el elemento de la red Site VPN que creó con anterioridad. En este punto, también tiene la opción de seleccionar los tipos de contenido que se deben comprimir. ISA Server 2006 se distribuye con una lista de tipos de contenido estándar, pero puede agregar tipos de contenido personalizados a través del panel de tareas Directiva de firewall en la ficha Cuadro de herramientas. Recuerde que la ficha Devolver datos comprimidos hace referencia a la compresión de los datos por parte de ISA Server antes de devolverlos al cliente. Para que ISA Server solicite que un servidor web se encargue de la compresión de los datos antes de enviarlos a ISA Server, use la ficha Devolver datos comprimidos.
Figura 7 Configure la compresión HTTP.
Figura 7 Configure la compresión HTTP.
BITS es un servicio de transferencia asincrónica de archivos para el tráfico HTTP y HTTPS. Windows Server 2003 incluye BITS 1.5, que es compatible con cargas y descargas, aunque las cargas requieren también IIS 5.0 o una versión posterior. Como servicio inteligente de transferencia de archivos, BITS tiene la capacidad de examinar el tráfico de red y usar sólo la parte inactiva del ancho de banda de la red. Además, la transferencia de archivos es dinámica y BITS responderá a aumentos del tráfico de red normal con la reducción de su uso de la red. Aquí, la ventaja es que BITS asegura que la carga y la descarga de archivos grandes no influirán negativamente en otros usos de la red. Desde una perspectiva administrativa, esto significa que seguramente recibirá muchas menos llamadas sobre el rendimiento insatisfactorio de la red. ¡Buenas noticias!
BITS ofrece otras ventajas que pueden mejorar la experiencia del usuario y conseguir un rendimiento de la red superior. Por ejemplo, una transferencia de archivos que usa BITS es binaria, lo que significa que BITS puede reanudar transferencias de archivos (sin empezar desde el principio) que se han interrumpido por factores como la interrupción del servicio de la red. Además, ISA Server 2006 incluye compatibilidad integrada con una función de almacenamiento en caché de Microsoft Update que hace uso del almacenamiento en caché de BITS para optimizar las actualizaciones.
El protocolo Servicios diferenciados (DiffServ) habilita el establecimiento de prioridades entre paquetes (o QoS) para el tráfico HTTP y HTTPS. Es decir, según la configuración de su servidor ISA, se dará prioridad a un tráfico determinado. Esto es útil en redes que tienen un ancho de banda limitado, debido al volumen del tráfico o a la velocidad de la conexión de la red. Según el Grupo de trabajo de ingeniería de Internet (IETF), DiffServ es un mecanismo de administración de tráfico basado en clases. Así, DiffServ puede diferenciar entre distintos tipos de tráfico y administrarlos en consecuencia, lo que garantiza la preponderancia del tráfico de alta prioridad.
Para ofrecer esta característica, ISA Server funciona en conjunción con otros enrutadores compatibles con QoS. Es importante asegurarse de que los bits DiffServ de ISA Server coinciden con las prioridades de los enrutadores, si quiere que los paquetes sean distribuidos con el mismo orden.
Según la implementación en ISA Server, este tipo de establecimiento de prioridades entre paquetes es una configuración de directiva HTTP global y aplicable a todo el tráfico HTTP que pasa por ISA Server 2006 mediante un filtro web DiffServ. Esto significa que ISA Server no es compatible con DiffServ para otros protocolos y, de hecho, puede descartar bits DiffServ existentes en tráfico que no es HTTP.
Como muestra la figura 8, DiffServ se implementa como filtro web. Seleccione Complementos en el panel izquierdo para obtener acceso a DiffServ. Es importante que no cambie la configuración predeterminada ni el orden de prioridad del filtro DiffServ, ya que ISA Server necesita inspeccionar el tamaño de la solicitud o la respuesta en el momento en que se procesa.
Figura 8 Obtenga acceso al filtro web DiffServ.
Figura 8 Obtenga acceso al filtro web DiffServ.
Si observa detenidamente la figura 8, verá que el filtro DiffServ no está habilitado de forma predeterminada. Para habilitar el filtro, seleccione Habilitar filtros seleccionados en el panel de tareas y configure el filtro. Como el establecimiento de prioridades entre paquetes de DiffServ en ISA Server se basa en direcciones URL o en dominios concretos, necesita agregar esta información a las preferencias de DiffServ. Para hacerlo, seleccione General en el panel izquierdo de la consola de administración y, a continuación, en Configuración de directiva HTTP global, seleccione Especificar las preferencias de DiffServ. Al especificar estas preferencias, deberá definir las prioridades, así como las direcciones URL y los dominios que deben recibir prioridad. ISA Server 2006 ofrece funciones nuevas muy eficaces para la configuración del acceso remoto con clientes de VPN y la creación de VPN de sitio a sitio. Debe colocar ISA Server 2006 al principio de su lista cuando considere la solución de VPN que desea implementar.

Alan Maddison trabaja como consejero superior en la práctica de tecnología de Microsoft de MTI Technology Corporation. Su trabajo se centra principalmente en Active Directory, Exchange Server y en la virtualización.


 SQL Server: Optimizaci&#243;n del rendimiento de las consultas de SQL Server
SQL Server Maciej Pilecki

Optimización del rendimiento de las consultas de SQL Server
Resumen:
  • Análisis de los planes de ejecución
  • Optimización de consultas
  • Identificación de consultas que optimizar

Al optimizar el servidor de la base de datos, necesita también mejorar el rendimiento de las consultas individuales. Esto es igual de importante, o incluso más, que optimizar otros aspectos de la instalación del servidor, aspectos que afectan al rendimiento, como las configuraciones de hardware y software.
Incluso si el servidor de la base de datos se ejecuta en el hardware más eficaz, su rendimiento puede verse afectado negativamente por un conjunto de consultas que se comporten incorrectamente. De hecho, incluso una sola consulta incorrecta, a veces denominada "consulta descontrolada", puede provocar serios problemas de rendimiento a la base de datos.
De manera opuesta, el rendimiento general de la base de datos puede mejorarse en gran medida al optimizar el conjunto de las consultas más costosas o que se ejecutan con mayor frecuencia. En este artículo, trataré algunas de las técnicas que puede emplear para identificar y optimizar las consultas más costosas y las de peor rendimiento del servidor.

Análisis de los planes de ejecución
Para optimizar una consulta individual, normalmente se empieza observando el plan de ejecución de esa consulta. El plan de ejecución describe la secuencia de operaciones, físicas y lógicas, que SQL ServerTM realizará con el objeto de cumplir la consulta y producir el conjunto de resultados deseado. El plan de ejecución lo genera un componente motor de la base de datos llamado Optimizador de consultas durante la fase de optimización del procesamiento de la consulta, esto tiene en cuenta muchos factores diferentes, como los predicados de búsqueda en la consulta, las tablas implicadas y sus condiciones de combinación, la lista de columnas devueltas y la presencia de índices útiles que pueden servir como rutas de acceso eficaces a los datos.
Para las consultas más complejas, el número de todas las permutaciones posibles puede ser muy grande, por lo que el optimizador de consultas no evalúa todas posibilidades, sino que en su lugar intenta encontrar un plan que sea "lo suficientemente bueno" para una consulta determinada. Esto es porque el encontrar un plan perfecto no siempre es posible; e incluso cuando es posible, el costo de la evaluación de todas las posibilidades para encontrar que el plan perfecto podría fácilmente tener más peso que cualquier ganancia de rendimiento. Desde el punto de vista de los administradores de bases de datos, es importante comprender el proceso y sus limitaciones.
Hay varias maneras de recuperar un plan de ejecución para una consulta:
  • Management Studio proporciona las características Mostrar el plan de ejecución real y Mostrar el plan de ejecución estimado, que presentan el plan de una manera gráfica. Estas características ofrecen la solución más conveniente para el examen directo y constituyen, sin duda, el enfoque usado con más frecuencia para mostrar y analizar los planes de ejecución. (En este artículo, usaré los planes gráficos generados de este modo para ilustrar mis ejemplos).
  • Varias opciones SET, como SHOWPLAN_XML y SHOWPLAN_ALL, devuelven el plan de ejecución en forma de documento XML que describe el plan mediante un esquema o como un conjunto de filas con descripciones textuales de cada una de las operaciones en el plan de ejecución.
  • Las clases de evento del Analizador de SQL Server, como Showplan XML, le permiten reunir los planes de ejecución de instrucciones recopiladas gracias al seguimiento.
Aunque una representación XML del plan de ejecución puede no ser el formato más sencillo para que las personas lo lean, esta opción le permite escribir los procedimientos y utilidades que pueden analizar sus planes de ejecución, buscar signos de problemas de rendimiento y planes poco óptimos. Una representación basada en XML también puede guardarse en un archivo con la extensión .sqlplan y abrirse, a continuación, en Management Studio para producir una representación gráfica. Estos archivos pueden guardarse también para un análisis posterior, eliminando, por supuesto, la necesidad de reproducir el plan de la ejecución cada vez que desee analizarlo. Esto es especialmente útil cuando desea comparar sus planes para ver cómo cambian con el tiempo.

Costo estimado de la ejecución
Lo primero que tiene que entender acerca de los planes de ejecución es cómo se generan. SQL Server usa un optimizador de consultas basado en el costo, es decir, intenta generar un plan de ejecución con el costo estimado más bajo. La estimación se basa en las estadísticas de distribución de datos que están disponibles para el optimizador cuando evalúa cada tabla implicada en la consulta. Si esas estadísticas se pierden o quedan obsoletas, el optimizador de consultas carecerá de la información esencial necesaria para el proceso de optimización de consultas y, por lo tanto, es probable que las estimaciones queden fuera de la marca. En dichos casos, el optimizador seleccionará un plan menos óptimo tanto sobrestimando como subestimando los costos de ejecución de los distintos planes.
Hay algunas suposiciones falsas muy comunes acerca del costo estimado de ejecución. En particular, con frecuencia las personas asumen que el costo estimado de ejecución es un buen indicador de cuánto tiempo tardará la consulta en ejecutarse y que esta estimación les permite distinguir los planes buenos de los que no lo son. Esto no es verdad. En primer lugar, existe la suficiente documentación sobre lo que son las unidades para expresar el costo estimado y si éstas tienen alguna relación directa con el tiempo de ejecución. En segundo lugar, puesto que se trata de una estimación y podría estar equivocada, en ocasiones los planes con costos estimados más altos pueden ser mucho más efectivos en términos de CPU, E/S y del tiempo de ejecución, a pesar de que sus estimaciones sean más altas. Este caso se suele dar con las consultas que implican variables de tabla, ya que para éstas no hay estadísticas disponibles, el optimizador de consultas siempre asume que una variable de tabla contiene sólo un fila, aunque contenga un número mucho mayor. Además, el optimizador de consultas elegirá un plan basado en una estimación inexacta. Por lo tanto, al comparar los planes de ejecución de las consultas, no debe depender únicamente del costo estimado de la consulta. En su lugar, incluya el resultado de las opciones STATISTICS I/O y STATISTICS TIME en el análisis, para entender cuál es realmente el costo de la ejecución en términos de E/S y tiempo de la CPU.
Merece también la pena mencionar aquí un tipo especial de plan de ejecución, llamado plan paralelo. Si ejecuta su consulta en un servidor con más de una CPU y su consulta puede optar por la paralelización, puede que se elija un plan paralelo. (Generalmente, el optimizador de consultas sólo considerará un plan paralelo para una consulta que tenga un costo que supere cierto umbral configurable). Debido a la sobrecarga generada al administrar múltiples subprocesos paralelos de ejecución (lo cual implica distribuir el trabajo a través de los subprocesos, llevar a cabo la sincronización y reunir los resultados), los planes paralelos son más costosos de ejecutar y eso se refleja en su costo estimado. Así que, ¿por qué se eligen frente a planes más baratos que no son paralelos? Gracias al uso de la eficacia de procesamiento de varias CPU, los planes paralelos tienden a generar los resultados más rápido que los planes estándar. Dependiendo de su situación específica, incluidas variables como los recursos disponibles y la carga simultánea de otras consultas, esta situación puede ser deseable para su instalación. Si éste fuera el caso, debe controlar cuál de sus consultas puede producir planes paralelos y cuántas CPU pueden usar cada uno. Esto lo puede hacer configurando el grado máximo de la opción de paralelismo en el nivel de servidor e invalidándolo en el nivel de consulta individual con OPTION (MAXDOP n) tal como considere necesario.

Análisis de un plan de ejecución
Ahora me centraré en una consulta sencilla, en su plan de ejecución y en algunos métodos para mejorar su rendimiento. Supongamos que ejecuto esta consulta mediante Management Studio con la opción Incluir plan de ejecución real activada en la base de datos de ejemplo de Adventure Works en SQL Server 2005:
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
Como resultado, veo el plan de ejecución descrito en la figura 1. Esta consulta sencilla calcula la cantidad total de pedidos realizados por cada cliente de Adventure Works. Al observar el plan de ejecución, puede consultar cómo el motor de la base de datos procesa la consulta y produce el resultado. Los planes de ejecución gráficos deben leerse de arriba a abajo y de derecha a izquierda. Cada icono representa una operación lógica y física realizada y las flechas muestran flujo de datos entre las operaciones. El grosor de las flechas representa el número de filas que se transmite entre las operaciones, cuanto más gruesa es la flecha, más filas habrá implicadas. Si coloca el puntero sobre uno de los iconos del operador, la información sobre herramientas en color amarillo (como la mostrada en la figura 2) mostrará detalles de esa operación en particular.
Figura 1 Plan de ejecución de ejemplo
Figura 1 Plan de ejecución de ejemplo
Figura 2 Detalles sobre una operación
Figura 2 Detalles sobre una operación
Observando cada uno de los operadores, puede analizar la secuencia de pasos realizados:
  1. El motor de la base de datos realiza una operación Clustered Index Scan en la tabla Sales.Customer y devuelve la columna CustomerID para todas las filas de esa tabla.
  2. A continuación, realiza un Index Scan (lo cual significa que realiza un examen de índice no agrupado) en uno de los índices de la tabla Sales.SalesOrderHeader. Éste es un índice de la columna CustomerID, pero también incluye implícitamente la columna SalesOrderID (la clave de clúster de la tabla). El examen devuelve los valores de ambas columnas.
  3. El resultado de ambos exámenes se une en la columna CustomerID mediante el operador físico Merge Join. (Esta es una de tres maneras físicas posibles de realizar una operación de unión lógica. Es rápido pero requiere la reorganización de ambas entradas en una columna unida. En este caso, ambas operaciones de examen ya han devuelto las filas reorganizadas en CustomerID, por lo que no hay necesidad de realizar la operación Ordenar adicional).
  4. A continuación, el motor de la base de datos realiza un examen del índice agrupado en la tabla Sales.SalesOrderDetail, recuperando los valores de cuatro columnas (SalesOrderID, OrderQty, UnitPrice y UnitPriceDiscount) de todas filas en esta tabla. (Se había estimado que esta operación devolvería 123.317 filas y esa fue la cifra realmente devuelta, tal como puede observar en las propiedades de número estimado de filas y número real de filas de la figura 2, por lo que la estimación fue bastante acertada).
  5. Las filas producidas por el examen de índice agrupado se transmiten al primer operador Compute Scalar de manera que el valor de la columna calculada LineTotal pueda calcularse para cada fila, según las columnas OrderQty, UnitPrice y UnitPriceDiscount implicadas en la fórmula.
  6. El segundo operador Compute Scalar aplica la función ISNULL al resultado del cálculo anterior, tal como lo requiera la fórmula de la columna calculada. Esto completa el cálculo de la columna LineTotal y lo devuelve, junto con la columna SalesOrderID, al operador siguiente.
  7. El resultado del operador Merge Join del paso 3 se une con el resultado del operador Compute Scalar del paso 6, mediante el operador físico Hash Match.
  8. A continuación, se aplica otro operador Hash Match para agrupar las filas devueltas de Merge Join por el valor de la columna CustomerID y el agregado calculado SUM de la columna LineTotal.
  9. El último nodo, SELECT, no es un operador físico ni lógico, sino más bien un marcador de posición que representa los resultados de consulta generales y el costo.
En mi equipo portátil, este plan de ejecución tuvo un costo estimado de 3,31365 (como se muestra en la figura 3). Cuando se ejecutó con STATISTICS I/O ON, la consulta notificó la realización de un total de 1.388 operaciones de lectura lógicas en las tres tablas implicadas. Los porcentajes que se muestran bajo cada uno de los operadores representan el costo de cada operador individual en relación al costo general estimado de todo el plan de ejecución. Si observa el plan de la figura 1, puede ver que la mayor parte del costo total de todo el plan de ejecución se asocia con los tres operadores siguientes: el Clustered Index Scan de la tabla Sales.SalesOrderDetail y los dos operadores Hash Match. Pero antes de seguir con la optimización de éstos, me gustaría señalar un cambio muy sencillo en mi consulta que me permitirá eliminar dos de los operadores por completo.
Figura 3 Costo total estimado de ejecución de la consulta
Figura 3 Costo total estimado de ejecución de la consulta
Puesto que la única columna que devuelvo de la tabla Sales.Customer es CustomerID y esta columna se incluye también como una clave externa en Sales.SalesOrderHeaderTable, puedo eliminar completamente la tabla Customer de la consulta sin cambiar el significado lógico o el resultado producido por nuestra consulta mediante este código:
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Esto produce un plan de ejecución distinto, que se muestra en la figura 4.
Figura 4 Plan de ejecución después de eliminar la tabla Customer de la consulta
Figura 4 Plan de ejecución después de eliminar la tabla Customer de la consulta
Se eliminaron por completo dos operaciones, Clustered Index Scan en la tabla Customer y Merge Join entre Customer y SalesOrderHeader, y la unión Hash Match se sustituyó por Merge Join, que es más eficaz. Sin embargo, para usar Merge Join entre las tablas SalesOrderHeader y SalesOrderDetail, se tuvieron que devolver las filas de ambas tablas clasificadas por la columna de unión SalesOrderID. Para conseguirlo, el optimizador de consultas decidió realizar un Clustered Index Scan en la tabla SalesOrderHeader, en lugar de usar un Non-Clustered Index Scan, que hubiera sido más barato en términos de la E/S implicada. Se trata de un buen ejemplo sobre cómo trabaja en la práctica el optimizador, puesto que los ahorros en el costo por cambiar la manera física de llevar a cabo la operación de unión fueron mayores que los costos de E/S adicionales generados por el Clustered Index Scan, el optimizador de consultas eligió la combinación resultante de operadores porque ofreció el costo total estimado de ejecución más reducido posible. En mi equipo portátil, aunque el número de lecturas lógicas subió (a 1.941), el tiempo de CPU consumido fue realmente más pequeño y el costo de ejecución estimado de esta consulta se redujo alrededor de un 13 por ciento (2,89548).
Digamos que deseo mejorar aún más el rendimiento de esta consulta. Ahora observo el Clustered Index Scan de la tabla SalesOrderHeader, que se ha convertido en el operador más caro de este plan de ejecución. Puesto que sólo necesito dos columnas de esta tabla para llevar a cabo la consulta, puedo crear un índice no agrupado que contenga sólo esas dos columnas, reemplazando el examen de toda la tabla por uno del índice no agrupado, mucho más pequeño. La definición del índice puede que tenga este aspecto:
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
Tenga en cuenta que el índice que he creado incluye una columna calculada. Esto no es siempre posible, dependiendo de la definición de la columna calculada.
Después que crear este índice y ejecutar la misma consulta, obtengo el nuevo plan de ejecución mostrado en la figura 5.
Figura 5 Plan de ejecución optimizado
Figura 5 Plan de ejecución optimizado
El Clustered Index Scan de la tabla SalesOrderDetail se ha reemplazado por un Non-Clustered Index Scan con un costo de E/S mucho más reducido. También he eliminado uno de los operadores Compute Scalar, puesto que mi índice incluye un valor ya calculado de la columna LineTotal. El costo estimado del plan de ejecución es ahora 2,28112 y la consulta realiza 1.125 lecturas lógicas cuando se ejecuta.

El índice de cobertura
Ejercicio de consulta de pedido del cliente
P Aquí tiene un ejercicio de consulta de pedido del cliente: trate de averiguar la definición del índice, qué columnas debe contener para convertirse en un índice de cobertura para esta consulta y si el orden de las columnas en la definición del índice provocaría alguna diferencia en el rendimiento.
R Le reté a averiguar cuál sería el índice de cobertura más óptimo de la tabla Sales.SalesOrderHeader para la consulta de ejemplo en mi artículo. Para conseguirlo, lo primero que debe tener en cuenta es que la consulta usa sólo dos columnas de la tabla: CustomerID y SalesOrderID. Si ha leído mi artículo detenidamente, habrá advertido que en el caso de la tabla SalesOrderHeader, ya hay un índice existente que cubre esta consulta, se trata del índice en CustomerID y contiene implícitamente la columna SalesOrderID, que es la clave de clúster de la tabla.
Por supuesto, expliqué también por qué el optimizador de consultas decidió no usar este índice. Sí, podría forzar al optimizador de consultas a usar este índice, pero la solución sería menos eficiente que el plan existente que usa los operadores Clustered Index Scan y Merge Join. Esto es porque estaría forzando al optimizador de consultas a elegir entre realizar una operación Sort adicional para poder seguir usando Merge Join o retroceder y usar un Hash Join menos efectivo. Ambas opciones tienen un costo estimado de ejecución más alto que el plan existente (la versión con la operación Sort funcionaría bastante mal), así que el optimizador de consultas no las usará a menos que se le obligue. Así pues, en esta situación, el único índice que funcionaría mejor que el Clustered Index Scan sería un Non-Clustered Index Scan en SalesOrderID, CustomerID. Pero es importante tener en cuenta que las columnas deben estar en ese orden exacto:
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
Si crea este índice, el plan de ejecución contendrá el Index Scan y no el operador Clustered Index Scan. Esto constituye una diferencia considerable. En este caso, el índice no agrupado que contiene sólo dos columnas es mucho más pequeño que toda la tabla en forma de índice agrupado. Por lo tanto, requerirá menos E/S para leer los datos necesarios.
Este ejemplo muestra también como el orden de las columnas del índice puede tener una repercusión considerable en la utilidad para el optimizador de consultas. Asegúrese de tener esto en cuenta cuando diseñe los índices de varias columnas.

El índice que he creado en SalesOrderDetail es un ejemplo del llamado "índice de cobertura". Se trata de un índice no agrupado que contiene todas las columnas necesarias para realizar la consulta, eliminando la necesidad de examinar toda la tabla mediante los operadores Table Scan o Clustered Index Scan. El índice es, en esencia, una copia más pequeña de la tabla, que contiene un subconjunto de columnas de la tabla. Sólo esas columnas necesarias para contestar la consulta (o consultas) se incluyen en el índice, en otras palabras, el índice contiene sólo lo que necesita para "cubrir" la consulta.
La creación de índices de cobertura para las consultas más frecuentemente ejecutadas es una de las técnicas más fáciles y comunes que se usa en la optimización de consultas. Funciona especialmente bien en situaciones en las que la tabla contiene un número de columnas pero sólo algunas de ellas son mencionadas con frecuencia por las consultas. Al crear uno o más índices de cobertura, puede mejorar mucho el rendimiento de las consultas afectadas, puesto que éstas obtendrá acceso a una cantidad de datos mucho más pequeña y, por lo tanto, proporcionarán menos E/S. Existe, sin embargo, un costo oculto por mantener los índices adicionales durante las operaciones de modificación de datos (INSERT, UPDATE y DELETE). Dependiendo de su entorno y de la relación entre las consultas SELECT y las modificaciones de datos, debería juzgar detenidamente si los costos adicionales de mantenimiento del índice están justificados por las mejoras de rendimiento de consultas.
No tenga miedo de crear índices de varias columnas en vez de índices de una sola columna. Éstos tienden a ser mucho más útiles que los índices de una sola columna y es más probable que el optimizador de consultas los use para cubrir la consulta. La mayoría de los índices de cobertura son índices de varias columnas.
En el caso de mi consulta de ejemplo, hay todavía posibilidad de incorporar alguna mejora y esta consulta podría optimizarse aún más colocando un índice de cobertura en la tabla SalesOrderHeader. Esto elimina el Clustered Index Scan en favor de un Non-Clustered Index Scan. Esto se lo dejo para que lo haga como ejercicio. Trate de resolver la definición del índice, qué columnas debe contener para convertirse en un índice de cobertura para esta consulta y si el orden de las columnas en la definición del índice provocaría alguna diferencia en el rendimiento. Consulte la barra lateral del "Ejercicio de consulta de pedido del cliente" si desea ver la solución.

Vistas indizadas
Si el rendimiento de mi consulta de ejemplo es muy importante, puedo ir un paso más adelante y crear una vista indizada que almacene físicamente los resultados materializados de la consulta. Hay ciertos requisitos previos y limitaciones de vistas indizadas, pero si se puede usar uno, puede mejorar el rendimiento drásticamente. Tenga presente que las vistas indizadas conllevan un costo más alto de mantenimiento que los índices estándar. Como resultado, debe tener cuidado cuando las use. En este caso, la definición del índice tiene este aspecto:
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Tenga en cuenta la opción WITH SCHEMABINDING, que es un requisito previo para crear un índice en esa vista y la función COUNT_BIG(*), que es necesaria si nuestra definición del índice contiene una función agregada (en este ejemplo, SUM). Después de crear esta vista, puedo crear un índice en ella, como éste:
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
Cuando creo este índice, el resultado de la consulta incluida en la definición de la vista se materializa y se almacena físicamente en disco en el índice. Tenga en cuenta que todas las operaciones de modificación de datos en las tablas base a continuación actualizan automáticamente los valores de la vista según su definición.
Si ahora vuelvo a ejecutar la consulta, lo que suceda dependerá de la versión de SQL Server en la que se ejecute. En las versiones Enterprise o Developer, el optimizador de consultas asociará automáticamente esta consulta con la definición de la vista indizada y usará la vista indizada en vez de consultar las tablas base implicadas. La figura 6 muestra el plan de ejecución producido en este caso. Consiste en una sola operación, un Clustered Index Scan del índice que creé en la vista. El costo estimado de ejecución es sólo 0,09023 y sólo realiza 92 lecturas lógicas.
Figura 6 Plan de ejecución cuando se usa una vista indizada
Figura 6 Plan de ejecución cuando se usa una vista indizada
También puede crear y usar esta vista indizada en otras ediciones de SQL Server, pero para lograr el mismo efecto tiene que cambiar la consulta para hacer referencia a la vista directamente mediante la sugerencia NOEXPAND, así:
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
Cuando puede observar, las vistas indizadas pueden ser una característica muy eficaz si se usan adecuadamente. Son las más útiles para optimizar las consultas que realizan agregaciones sobre grandes cantidades de datos. Si se usa en Enterprise Edition, pueden beneficiar a muchas consultas sin la necesidad de realizar cambios en el código.

Identificación de las consultas a optimizar
¿Cómo identifico las consultas que deben optimizarse? Yo busco las consultas que se ejecutan con frecuencia, es posible que individualmente no tengan un costo muy alto de ejecución, pero el costo agregado de ejecución puede ser mucho más alto que el de una consulta más grande que se ejecuta raramente. No estoy diciendo que no deba optimizar las grandes, simplemente creo que debe concentrarse en primer lugar en las consultas que se ejecutan con más frecuencia. Así que, ¿cómo las identifica?
Desgraciadamente, el método más seguro es algo complicado e implica realizar un seguimiento de todas las consultas ejecutadas en su servidor y, a continuación, agruparlas por sus firmas. (Es decir, texto de consulta con los valores de parámetros reales reemplazados por marcadores con el objeto de identificar el mismo tipo de consulta, incluso si se ejecutó con valores de parámetro diferentes). Se trata de un proceso complicado, puesto que las firmas de consulta son difíciles de generar. Itzik Ben-Gan describe una solución que usa funciones definidas por el usuario de CLR y expresiones regulares en su libro Inside Microsoft SQL Server 2005: T-SQL Querying.
Existe otro método mucho más sencillo, pero de alguna manera menos confiable. Puede confiar en las estadísticas que se mantienen para todas consultas en la memoria caché del plan de ejecución y consultarlas mediante vistas dinámicas de administración. La figura 7 contiene una consulta de ejemplo que le muestra tanto el texto como el plan de ejecución de las 20 consultas en la memoria caché con el número más alto acumulado de lecturas lógicas. Esta consulta resulta muy útil para identificar rápidamente las consultas que generan el número más alto de lecturas lógicas, pero tiene sus limitaciones. Es decir, sólo mostrará las consultas que tienen sus planes en la memoria caché en el momento en el que ejecuta la consulta. Si algo no se copia en la memoria caché, se perderá.
Figure 7 Identificación de las 20 consultas más costosas en términos de E/S de lectura (Close Figure 7)
SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
Una vez que haya identificado las de más escaso rendimiento, observe sus planes de consulta y busque maneras de mejorar su rendimiento usando algunas de las técnicas de indización que he descrito en este artículo. Si el resultado es satisfactorio, será tiempo bien invertido.
¡Feliz optimización!

Maciej Pilecki es Consejero asociado en Solid Quality Mentors, una organización global especializada en aprendizaje, apoyo y consultoría. Cuenta también con la certificación Microsoft Certified Trainer (MCT) y el programa Most Valuable Professional (MVP) de SQL Server, con frecuencia imparte cursos y conferencias sobre numerosos aspectos de SQL Server y el desarrollo de aplicaciones.


 Nota del editor: M&#225;s poder para usted
Nota del editor
Más poder para usted

El número del mes pasado supuso el punto de partida de lo que espero será un diálogo continuo sobre el tema de la informática ecológica. Es cierto, este tema todavía no está bien definido. (¿Qué es ecológico? Si el depósito de mi coche me permite recorrer 50 km por litro en vez de 40 km, ¿es eso ecológico? Lo siento, pero lo realmente ecológico es no tener coche. Vivo en Nueva York, por lo que ando bastante).
Es obvio que en estos momentos cualquier compañía que se precie intenta colocar su propia etiqueta de ecológico en sus productos o servicios. Sin embargo, hay una buena razón para esto que justifica, asimismo, que el tema apareciera en nuestra portada el pasado mes; el potencial es impresionante.
Todos sabemos que se trata de generar ingresos al mismo tiempo que se ayuda a conservar el medioambiente. El hecho es que ser ecológicamente correcto se ha convertido en un argumento de ventas eficaz que genera resultados muy positivos. ("Es la economía, ¡estúpido!") Es fantástico si una compañía de automóviles puede vender más coches fabricándolos más eficaces. En último término, lo que se espera es que podamos mantener una economía saneada consolidada sobre un entorno sano y sostenible.
Así, pues, ¿Cómo influye todo esto al profesional de TI? El doctor Jonathan Koomey, científico del Lawrence Berkeley National Laboratory y profesor-consultor en la Universidad de Stanford, publicó recientemente un estudio que estima el consumo total de energía de los servidores en EE. UU. y todo el mundo. En 2005, los centros de datos (servidores junto con su infraestructura de apoyo, como los sistemas de enfriamiento) fueron responsables del 1,2 por ciento del consumo total de energía en EE. UU., la cifra total alcanza el resultado de cinco centrales eléctricas de 1.000 megavatios (MW) y un costo de 2.700 millones de dólares. A nivel mundial, este costo se eleva a 7.200 millones de dólares (el resultado total de 14 centrales eléctricas de 1.000 MW). Es muchísimo dinero, y energía, que podría ahorrarse y gran parte de ese trabajo podría empezar dentro del mismo centro de datos.
¿Cómo es posible planear la capacidad del centro de datos? ¿Cómo se puede ajustar la capacidad para adaptarse a la demanda, sin tener que ejecutar al 100 por cien en todo momento? (Sugerencia: virtualización). Supervisamos los servidores para comprobar la conectividad de red, el uso de la memoria, etc., pero, ¿quién presta atención al consumo de energía? ¿Consumen los servidores más antiguos mucha más energía que los equipos nuevos? ¿Es este costo incrementado mayor que el costo de un equipo de reemplazo?
En los próximos meses, uno de nuestros expertos residentes, Dave Ohara (autor de artículo del mes pasado, que está disponible ahora en línea en technetmagazine.com), le mostrará el trabajo que se está desarrollando aquí en Microsoft con la creación de nuestro propios centros de datos ecológicos en Quincy, Washington y San Antonio, Texas y cómo se ha ofrecido respuesta a esas preguntas. Nos gustaría también oír cómo administra usted, como usuario, estos asuntos (o, si ha elegido no incorporarse a esta tendencia, nos gustaría saber el por qué). Mándenos un correo electrónico a tnmag@microsoft.com o visite nuestro blog en blogs.technet.com/tnmag. (Joshua Hoffman)

Mi agradecimiento a los siguientes expertos de Microsoft: Tim Carroll, Omesh Desai, Steve Jenness, Sam Kroonenburg, Mutlu Kurtoglu, KC Lemson, Tim Mintner, Jim Truher, Buck Woody y Sudarshan Yadav.


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

Captura de pantalla de vídeo
My Screen Recorder Pro
deskshare.com/msrpro.aspx
Suponga que tiene una reunión en 20 minutos y que aún necesita componer una presentación sobre la nueva configuración del sistema. Incluso puede que tenga que explicar diariamente el mismo tutorial de la aplicación con distintos usuarios. Si esta situación le resulta familiar, le ofrecemos esta sugerencia: eche un vistazo a My Screen Recorder Pro de DeskShare.
Tal como indica su nombre, esta aplicación le permite grabar la actividad que tiene lugar en su escritorio en forma de vídeo, lo que ofrece una excelente manera componer una presentación improvisada o tutorial reutilizable para sus clientes. My Screen Recorder Pro también es compatible con la grabación de audio, por lo que puede incluir una narración al mismo tiempo. (Sugerencia: cree un script o un esquema antes de iniciar la grabación).
La creación de un vídeo nuevo es bastante sencilla. Seleccione la región que desea grabar (todo el escritorio, un área personalizable del escritorio, una porción fija del escritorio o una ventana concreta de la aplicación) y, a continuación, haga clic en el botón Record (grabar).
La aplicación puede grabar en AVI, en Windows Media® Video (WMV) o en Flash, por lo que podrá distribuir los resultados de una manera relativamente fácil e incluso incrustar los vídeos en páginas web o transmitirlos en secuencias para un uso público más amplio. También puede crear un archivo ejecutable para el vídeo y reproducirlo de forma local en la mayoría de los PCs de Windows®. El vídeo se incrusta dentro del archivo ejecutable, lo que simplifica la distribución y convierte la reproducción en un proceso muy intuitivo para el usuario final.
Si el tutorial o la presentación se prestan a múltiples segmentos, puede fusionar varias tomas en un mismo vídeo. O, si necesita llevar a cabo tareas de edición en el vídeo, puede dividir o cortar la grabación según sus necesidades.
Aunque en la mayoría de casos puede usarse la configuración predeterminada, la aplicación le permite ajustar la velocidad de fotogramas, la calidad del audio y la configuración de compresión para adaptarse mejor a su entorno. Esto es útil para solucionar cualquier restricción de tamaño o ancho de banda con la que pueda encontrarse. También puede crear una grabación mediante un sencillo modo de lapso de tiempo, que a efectos prácticos le permitirá comprimir partes de larga ejecución de la grabación (por ejemplo, una barra de progreso lenta). Otra característica muy atractiva es la opción de cambiar el cursor del mouse para la grabación y agregar efectos de puntero del mouse para captar la atención sobre las acciones que ocurren mientras la sesión de grabación está en curso. Por ejemplo, puede ampliar el puntero o hacer que aparezcan anillos alrededor del mismo siempre que haga clic en el botón del mouse. Además, puede agregar subtítulos y la marca de hora a la grabación para su archivo.
Para las personas más cautelosas, un poco "paranoicas" o extremadamente prudentes, My Screen Recorder Pro permite programar grabaciones; además el programa puede ejecutarse desde la línea de comandos, ofreciéndole la opción de supervisar discretamente las actividades en una estación de trabajo. Finalmente, la aplicación cuenta con características integradas para publicar sus vídeos en un sitio FTP. Cuando se combina con el programador, esta opción puede ser útil para llevar a cabo auditorías.

Precio: 99 dólares (directo) para una única licencia.
Cree una presentación grabando lo que sucede en el escritorio
Cree una presentación grabando lo que sucede en el escritorio

Disk Defrag
PerfectDisk 8
raxco.com/products/PerfectDisk2k
La desfragmentación del disco duro es esencial en cualquier sistema Windows. Si usted es como yo, seguro que agrega y elimina constantemente aplicaciones, características y actualizaciones de software. Hay una gran cantidad de utilidades de desfragmentación de disco entre las que elegir, de hecho, ya hablé sobre una el mes pasado. No obstante, la desfragmentación es muy importante por lo que merece la pena hablar ahora sobre PerfectDisk 8 de Raxco Software. Aunque todas las versiones de Windows incluyen una herramienta de desfragmentación, en ocasiones es necesaria una utilidad que ofrezca un control más preciso sobre la operación de desfragmentación. Si ese es el caso, eche un vistazo a PerfectDisk.
Tal como cabría esperar de cualquier herramienta de desfragmentación de Windows, PerfectDisk 8 puede desfragmentar unidades FAT16, FAT32 y NTFS y también le permite desfragmentar unidades RAID. PerfectDisk 8 está disponible en versiones de escritorio y servidor, y está certificado para Windows Vista® y es compatible con otras versiones de Windows, incluidos Windows Server® 2003 y Windows 2000. Incluso hay una versión para Exchange.
La compañía recomienda su tecnología SMARTPlacement, que intenta organizar la estructura de archivos en el disco para velocidades de acceso más rápidas. Por ejemplo, en sistemas Windows XP, la tecnología SMARTPlacement es la responsable de administrar los archivos de arranque y los archivos .ini, ordenándolos con el objetivo de reducir el tiempo de búsqueda en disco en el inicio del sistema. Además de desfragmentar una unidad completa, también puede elegir desfragmentar un solo archivo, lo que resulta útil, por ejemplo, después de descargar un archivo ISO grande.
Para administrar esos complicados archivos de sistema que no puede gestionar mientras se ejecuta el sistema operativo, la aplicación usa un modo sin conexión que se puede ejecutar en el siguiente inicio del sistema o, si se dan las condiciones adecuadas, la aplicación puede intentar desmontar el disco para ejecutar la desfragmentación. Otra característica muy atractiva es el modo de desfragmentación del protector de pantalla de PerfectDisk, que le permite empezar a desfragmentar automáticamente cuando se ejecuta el protector de pantalla.
PerfectDisk incluye también una versión de línea de comandos que le permite programar fácilmente la desfragmentación a través de su programador de tareas preferido y habilitar la ejecución remota a través de cualquier agente de administración de sistema que pueda estar ejecutándose en el sistema. Para implementaciones más grande, no dude en descargar la herramienta gratuita PerfectDisk Command Center, que le permite implementar, actualizar, programar y configurar de manera remota la aplicación para estaciones de trabajo en toda la empresa.

Precio: PerfectDisk 8 Professional (para el escritorio) a partir de 39,99 dólares para una sola licencia. PerfectDisk 8 Server a partir de 239,99 dólares para una sola licencia.
PerfectDisk ofrece diversas opciones de configuración
PerfectDisk ofrece diversas opciones de configuración

Reseña de libro
Network Warrior
oreilly.com
Si en su negocio ejecuta el hardware de Cisco, es probable que quiera conseguir una copia de Network Warrior (O'Reilly, 2007) de Gary Donahue. Este libro puede ser un valioso recurso para una amplia gama de lectores, tanto si acaba de iniciarse en el campo de las funciones de red, o ha recibido recientemente su certificación CCNA, como si es un consumado administrador de sistemas que desea poner al día sus capacidades de funciones de red.
Para mí es especialmente interesante que este libro se haya basado en la aplicación real de la tecnología de funciones de red y que ofrezca una referencia rápida a muchas de las tareas más comunes que el usuario encuentra en sus actividades diarias como profesional de red. El libro empieza en el nivel básico, definiendo exactamente lo que comprende una red desde lo más simple. Y avanza con una introducción sobre los concentradores, conmutadores, VLAN, trunking y VLAN Trunk Protocol (VTP), así como los árboles de extensión con el Protocolo de árbol de extensión (STP) y la tecnología EtherChannel de Cisco System.
A lo lago de Network Warrior, podrá observar ejemplos básicos que usan los comandos del Sistema operativo de interconexión de redes (IOS) de Cisco y de la interfaz de línea de comandos (CLI) de CatOS junto con las explicaciones de los métodos y tecnologías. Me gusta especialmente que el libro aporte una breve explicación sobre la base de las metodologías actuales, ofreciendo al mismo tiempo una serie de perspectivas interesantes (como por ejemplo, por qué existe aún CatOS y no únicamente IOS).
El libro incluye una explicación sobre los enrutadores y el enrutamiento en general, donde obtendrá más información sobre los fundamentos del enrutamiento, desde las estadísticas a las distancias administrativas de los distintos protocolos de enrutamiento. También contiene introducciones sobre protocolos, tal como Abrir primero la ruta de acceso más corta (OSPF), Protocolo de puerta de enlace de borde (BGP) y el Protocolo de información de enrutamiento (RIP).
En la sección sobre Hot Standby Router Protocol (HSRP) de Cisco, el autor explora la administración de la disponibilidad y ofrece algunas configuraciones básicas para evitar el tiempo de inactividad en la infraestructura de la red. A continuación ofrece una revisión de las características y funciones de algunos de conmutadores multinivel de Cisco, como Cisco 6500 y Catalyst 3750 y una explicación de algunas de las configuraciones básicas que puede encontrar.
La información acerca del mundo de las telecomunicaciones también resulta bastante útil. El libro le enseña parte de la jerga para que pueda evitar el hecho de tener que sonreír y afirmar con la cabeza sin saber de qué le hablan la próxima vez que vengan a hacer una conexión. Aprenderá lo suficiente acerca de la Unidad de servicio de canal/Unidad de servicio de datos (CSU/DSU), la configuración de conexiones DS3 y los Frame Relay de varios nodos como para permitirle conversar con los técnicos de telecomunicaciones.
Hay una sección muy interesante sobre la seguridad y los servidores de seguridad, que le muestra cómo diseñar y configurar listas de control de acceso (ACL), además trata la autenticación, las redes perimetrales y opciones de configuración del servidor de seguridad específicas de PIX. Es muy interesante el breve apartado dedicado a la teoría del firewall, que hace hincapié en los mantras por los que regirse como el de "denegar todo; permitir lo que es necesario" y "la seguridad es un equilibrio entre la conveniencia y la paranoia".
La última sección de Network Warrior ofrece una explicación detallada sobre el diseño de red, tratando aspectos básicos de diseños comunes de infraestructura de red, tal como una configuración de comercio electrónico de tres niveles y una red de núcleo contraído sin un nivel de distribución, subrayando la importancia de la documentación y de las convenciones de nomenclatura.

Precio: 44,99 dólares de lista.

Administre los bloqueos de archivos
WhoLockMe
dr-hoiby.com/WhoLockMe
Sería muy agradable que cada aplicación cerrara los archivos correctamente. Desgraciadamente, no lo hacen. Las infracciones del uso compartido pueden convertirse en un verdadero fastidio y el averiguar qué proceso bloquea actualmente un archivo puede ser incluso más molesto. No sé si ocurre en su caso, pero personalmente odio tener que cerrar las aplicaciones de una en una, sólo para poder controlar un archivo. Afortunadamente, hay una extensión muy sencilla y gratuita del Explorador de Windows denominada WhoLockMe que puede servir de ayuda.
Disponible para Windows NT®, Windows 2000, Windows Server 2003 y Windows XP, esta aplicación le permite conocer qué proceso está actualmente bloqueando el archivo de su interés. Lo único que tiene que hacer es hacer clic con el botón secundario y seleccionar en el menú contextual del Explorador de Windows.
WhoLockMe le muestra el nombre del proceso que bloquea el archivo, su identificador de proceso (PID), la ruta de acceso al archivo abierto, el dominio y el usuario del contexto de ejecución del proceso, así como la ruta de acceso completa al infractor. Si se atreve, incluso puede elegir eliminar el proceso directamente de la IU.
Desgraciadamente, WhoLockMe no se ha actualizado desde hace tiempo y no funciona en Windows Vista. Sin embargo, si ejecuta una versión anterior de Windows, esta aplicación es una herramienta rápida y efectiva para averiguar quién o qué tiene un bloqueo en el archivo que necesita mover, eliminar o editar.

Precio: Producto gratuito

Herramientas de DNS
DNSStuff.com
www.dnsstuff.com
Si gestiona aplicaciones o redes orientadas a Internet, sin duda depende de DNS para poder administrarlas, así como para que las cosas se ejecuten sin complicaciones y permitir a los visitantes saber dónde residen tanto usted como sus aplicaciones. Un conjunto de herramientas del cual dependo con mucha frecuencia cuando hay un problema de DNS procede de DNSstuff.com. Esta colección de herramientas basadas en Web puede convertirse en un excelente recurso para solucionar problemas y comprobar sus configuraciones de infraestructura.
El sitio ofrece herramientas para problemas relacionados con dominios, IP, nombre de host, correo electrónico, sitios web y problemas generales de la red; más de 45 herramientas de consulta diferentes que pueden ayudarle a llevar a cabo una gran infinidad de tareas, desde validar la configuración del servidor de correo hasta comprobar la velocidad del hospedaje DNS. Es cierto que podrá encontrar probablemente equivalentes de la mayor parte de estas herramientas dentro de su propia infraestructura, pero la comprobación externa puede ofrecer información clave para solucionar problemas. Y no tendrá que molestar al compañero de la compañía vecina para que le haga una búsqueda de DNS inversa.
Una de las herramientas más eficaces y completas del sitio es el DNSreport. Sólo tiene que especificar un nombre de dominio, hacer clic en el botón y recuperará una gran cantidad de información respecto a su instalación. Cada elemento de línea de prueba muestra un estado con código de colores, que es muy útil para examinar rápidamente los resultados de prueba y comprobar la existencia de posibles problemas. El informe comprueba las zonas primarias del dominio, mostrándole detalles como los registros del servidor de nombres (NS) y si se ha enviado o no la dirección IP así como el nombre de host. El informe también comprueba posibles carencias de seguridad, comprobando que los servidores DNS no son servidores abiertos, que todos tienen los mismos registros de NS y que no han filtrado ningún registro de NS "invisibles" en solicitudes no relacionadas con NS.
Obtendrá igualmente una explicación detallada sobre la disponibilidad de la instalación a medida que DNSreport prueba varios servidores de nombres, enlaces IP públicos y servidores sin nombres al mismo tiempo que comprueba puntos únicos de error. Además, DNSreport comprueba los detalles de Inicio de autoridad (SOA), devolviendo el número de serie de SOA, los valores de actualización, expiración, reintento y período de vida (TTL) y llevando a cabo una comprobación de los registros MNAME y RNAME.
Las comprobaciones de registros de correo de Exchange (MX) del informe validan las entradas de DNS inversas y garantizan que el usuario no tenga ningún registro duplicado y que los registros tienen nombres de host válidos. Además, la herramienta trata de conectarse a su servidor de correo y comprobar elementos tales como si el nombre de host del servidor de correo se encuentra en el saludo, si acepta mensajes dirigidos a abuse@sudominio (tal como se especifica en varios RFC) y si el servidor SMTP está actualmente configurado como retransmisión abierta (y actúa por lo tanto como un imán para remitentes de correo electrónico no deseado en todo el mundo). Finalmente, DNSreport devuelve su registro www A, comprueba que todas las IP son públicas y determina si su configuración CNAME provocará una búsqueda de DNS adicional.
Si DNSreport no es suficiente, el sitio le permite también usar una herramienta de búsqueda para comprobar si se incluye un servidor de correo en el conjunto de bases de datos de correo electrónico no deseado muy conocidas y otro para encontrar el contacto relacionado con el abuso de un dominio. Puede realizar búsquedas de IP Whois, traceroutes y pings, así como búsquedas DNS generales y búsquedas DNS en memoria caché en los principales ISP. Puede incluso hacer búsquedas de NETGEO IP, comprobaciones de direcciones MAC y llevar a cabo volcados de archivos de zona si se suscribe. En resumen, se trata de un conjunto muy valioso de herramientas.

Precio: 3 dólares al mes para una única suscripción de usuario (acceso completo y búsquedas ilimitadas).
DNSstuff.com ofrece un conjunto completo de herramientas de supervisión muy útiles
DNSstuff.com ofrece un conjunto completo de herramientas de supervisión muy útiles

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


 Preguntas y respuestas sobre Exchange: Protocolos de correo electr&#243;nico seguros, correo electr&#243;nico no deseado de origen desconocido y mucho m&#225;s
Preguntas y respuestas sobre Exchange
Protocolos de correo electrónico seguros, correo electrónico no deseado de origen desconocido y mucho más
Nino Bilic and Scott Landry
Esta columna se basa en parte en una versión preliminar de Windows Server 2008. Por lo tanto, todos los detalles de este documento están sujetos a cambios.

P Deseo usar SMTP seguro, ¿cómo consigo que Exchange Server escuche SMTP en el puerto 465?
R Lo siento, pero esto no se puede hacer. Sí, puede hacer que cualquier servidor virtual SMTP o conector de recepción se escuche en el puerto 465, pero de este modo no conseguirá su objetivo de SMTP seguro (SMTPS).
¿Por qué? Bien, retrocedamos un poco y veamos el porqué. Hay dos tipos de SSL: explícito e implícito. Inicialmente, la mayor parte del SSL era implícito, lo cual implicaba el uso de un puerto dedicado para SSL. Por ejemplo, HTTP está en el puerto 80 de forma predeterminada, pero HTTPS (HTTP con SSL) está en el puerto 443. Hace varios años, la comunidad de Internet decidió que no fuera necesario un puerto dedicado para SSL. De este modo surgió el SSL explícito.
Netscape ya había elegido 465 como el puerto SMTPS, pero Exchange Server no tenía funcionalidad SSL en SMTP. Sin embargo, el equipo de Exchange observó la ventaja que ofrecía el SSL explícito, que se podría usar igualmente tanto por clientes como por servidores y eligió ser compatible con SSL explícito para SMTP.
En el caso de SMTP, el SSL explícito usa el comando STARTTLS ESMTP para señalar que el socket existente está a punto de ser protegido. La mayoría del resto de los servidores SMTP y proveedores de cliente han implementado también el comando STARTTLS, por lo que nunca hubo necesidad de ser compatible con el puerto 465, el cual, de todos modos, no constituía un estándar oficial de Internet.
Hasta el momento, ninguna versión de Exchange Server es compatible con SSL implícito para SMTP. Comunicar a un conector de recepción de Exchange o servidor virtual SMTP que escuche en el puerto 465 no cambia este hecho. Por lo tanto, necesita usar un cliente que sea compatible con STARTTLS en el puerto 25. Si no puede usar el puerto 25, la siguiente elección lógica es el 587, que es el puerto estándar para envíos SMTP de cliente. No hay muchos clientes actuales que no sean compatibles con STARTTLS en el 25, así que el agregar compatibilidad con SSL implícito no ha sido necesario.
A propósito, los protocolos POP3 e IMAP4 de Exchange siempre han sido compatibles con SSL implícito. Pero Exchange Server 2007 cuenta ahora también con compatibilidad añadida para SSL explícito para estos dos protocolos. No obstante, puesto que no muchos clientes son compatibles aún con este estándar más nuevo, SSL implícito todavía funcionará durante bastante tiempo.

P Tengo una gran cantidad de correo en la cola para diversos dominios y ninguno de mis usuarios ha enviado ninguno de los mensajes de correo. ¿Qué es lo que ocurre y qué puedo hacer para evitarlo?
R No se preocupe, no es el único. Cualquier persona que tenga un servidor en Internet puede encontrarse con este problema. Básicamente, hay dos causas posibles. La primera es que de algún modo usted mismo se ha abierto a las retransmisiones (consulte support.microsoft.com/kb/304897). Pero, por supuesto, usted no lo haría conscientemente, ¿verdad? (Las retransmisiones abiertas se han deshabilitado de manera predeterminada desde Exchange Server 2000). Así que lo más probable es que esté viendo lo que se denomina correo electrónico no deseado de informe de no entrega (NDR). En el proceso de envío de correo electrónico comercial no solicitado (UCE), los remitentes de correo electrónico no deseado con frecuencia realizan envíos a direcciones inexistentes de su dominio. El servidor intenta notificar al remitente de correo electrónico no deseado que los usuarios no existen, pero por supuesto, el remitente de correo electrónico no deseado ha suplantado el remite. El remitente de correo electrónico no deseado puede estar suplantando una dirección no válida (en cuyo caso el NDR queda pendiente cierto tiempo hasta que se agota el tiempo) o puede estar intentando que su servidor envíe correo electrónico no deseado a otro dominio en su propio beneficio, como un archivo adjunto del NDR que su servidor ha generado.
Podría deshabilitar los NDR, pero, en ese caso, si un usuario legítimo escribe mal una dirección por error, el servidor nunca le permitirá saber a este usuario que el correo electrónico no se envió y que los mensajes podrían haberse perdido. Le presentamos una solución mejor.
En primer lugar, asegúrese de que no se encuentra abierto a retransmisiones. (Tenía que decirlo). A continuación, active algún tipo de filtro contra correo electrónico no deseado, como el filtro inteligente de mensajes (FMI) o el filtro de contenido de Exchange Server 2007, además de unas cuantas Listas de bloqueados en tiempo real (RBL). Esto puede ser tanto en la función de Transporte perimetral como en la función de Transporte de concentradores, pero debe realizarse en primer enlace, ya que normalmente el 90 por ciento del volumen de correo tiende a ser correo electrónico no deseado y no es deseable mantener los servidores ocupados con esta clase de correo).
En último lugar, habilite el filtrado de destinatarios en el primer Exchange Server que acepte correo en su entorno. Esto permite al servidor rechazar un mensaje antes de que entre en su red. Si la dirección es legítima pero se ha escrito mal, ésta obtendrá el NDR, pero éste se generará a partir del servidor del remitente.

P Tenía un servidor que ejecutaba Exchange Server 2000 y otro que ejecutaba Exchange Server 2003, ambos podían enviar correo electrónico correctamente a Internet. Después instalé Exchange Server 2007 y ahora los buzones de correo de cada servidor no pueden enviar correo.
R Si en el pasado sólo ha tenido un Exchange Server, puede que no esté muy familiarizado con el concepto de los conectores. Los conectores de Exchange son objetos lógicos de configuración de enrutamiento que comunican a Exchange dónde dirigir el correo electrónico. Al introducir Exchange Server 2007 en una organización existente, con el objeto de enrutar el correo, necesariamente debe tener conectores de grupo de enrutamiento y un conector SMTP.
Necesitará dos conectores de grupo de enrutamiento, uno de ellos desde el grupo de enrutamiento de Exchange Server 2007 al grupo de enrutamiento de Exchange Server 2003 y viceversa. Puede configurar esto como parte del proceso de instalación, pero si lo lleva a cabo inadecuadamente o no está seguro, puede comprobarlo mediante el shell de administración de Exchange y corregir allí el problema. Si no lo hace, no podrá enviar correo electrónico entre los servidores. Los mensajes acabarán en colas de destino inalcanzables.
Para enrutar correo electrónico de Internet sólo necesita un conector SMTP, también conocido como conector de envío en Exchange Server 2007. Debe tener uno en Exchange Server 2000 y Exchange Server 2003, pero puede que hasta ahora haya funcionado sin el mismo. El espacio de direcciones debe ser SMTP:* para todos los dominios y puede especificar tanto el uso de un host inteligente como el DNS para la entrega de correo. Puede elegir si desea el servidor Exchange Server 2007 o el servidor más antiguo para administrar el correo saliente de Internet, o bien puede crear uno en ambos grupos de enrutamiento si desea que cada servidor administre el suyo propio. Puede crear también uno de estos como parte del proceso Edgesync si tiene instalada la función de servidor de Transporte perimetral.
Si puso previamente un host inteligente en el servidor virtual SMTP, ahora es un buen momento para quitarlo. Sólo debe estar en el conector SMTP, nunca en el servidor virtual puesto que así interrumpiría al conector del grupo de enrutamiento.
Debe saber también que los correos electrónicos entrantes se controlan a través del registro MX o la IP a la cual realiza el reenvío el firewall. No hay mucho que configurar en Exchange, pero este documento puede ser de ayuda si aún persisten los problemas: msexchangeteam.com/archive/2006/11/17/431555.aspx.

P ¿Por qué obtengo varios informes de diarios del mismo mensaje en Exchange Server 2007?
R El agente de diario de transporte de Exchange Server 2007 realizará el registro de los mensajes tras la categorización. El categorizador tiene muchas razones por las que bifurcar un mensaje (es decir, copia el cuerpo del mensaje y coloca distintos destinatarios de sobre en las distintas copias). Por ejemplo: puesto que los registros en diario tienen ahora la capacidad de decirle quiénes eran los miembros de un grupo de distribución en el momento en el cual se envió el mensaje, un caso en el cual podría obtener varios informes es el de un grupo de distribución anidado.
Tener más posibilidades en los medios de generación de informes implica que puede obtener unas pocas copias del mismo mensaje, cada una con un informe único. No existe una manera garantizada de saber si han llegado todos los informes para un mensaje, pero si está realizando tareas de archivado, deseará trabajar con su proveedor de archivo para asegurarse de que conoce los cambios.

P ¿Dónde se encuentra la característica de reenvío de mensajes no resueltos al host en Exchange Server 2007? ¿Qué debo hacer ahora?
R El perro se lo comió.
Realmente, esta característica específica nunca funcionó especialmente bien en las situaciones en las que se disponía de más de un Exchange Server. No obstante, Exchange ya tenía otro método para llevar a cabo la misma tarea y ese método era mucho más eficaz. Específicamente, el usuario tiene la posibilidad de compartir dominios SMTP individuales con otros sistemas. Así que la característica "reenvío no resuelto" se eliminó y el concepto de dominio de uso compartido se amplió y simplificó. En Exchange Server 2007, simplemente vaya a Organización | Transporte de concentradores | Dominios aceptados y cambie el tipo de dominio de Autoritativo a Retransmisión interna. Para algunos entornos es un poco más complicado, por lo que estamos trabajando en actualizar parte de la documentación. Aunque esto debe servir de ayuda mientras tanto.

P Estoy intentando preparar mi dominio raíz para la instalación de Exchange Server 2007. El servidor desde el que estoy intentando ejecutar la instalación de Exchange Server 2007 tiene instalado el Administrador del sistema de Exchange (ESM) de Exchange Server 2003 y la instalación presenta errores. ¿Cuál es el problema?
R Brevemente, no es compatible ejecutar cualquier parte de la instalación de Exchange Server 2007 en un equipo que tiene instalado algún componente de Exchange Server 2000 ó 2003. Puesto que está instalado el ESM de Exchange Server 2003, la instalación de Exchange Server 2007 lo advertirá y la comprobación de requisitos previos de la instalación no será correcta, por lo que se le comunicará lo siguiente, "Ya hay instalada una versión de Exchange Server en este equipo. Ejecute la instalación de Exchange Server 2007 desde un equipo diferente o quite la versión anterior de Exchange Server".
Probablemente la manera más sencilla de solucionar este problema es ejecutar la instalación de Exchange Server 2007 desde otro servidor en el dominio raíz y preparar el dominio de este modo. Si eso no es posible, tendrá que desinstalar el componente de Exchange Server 2003 antes de poder continuar con la instalación de Exchange Server 2007.
Recuerde que puede usar la versión de 32 bits de Exchange Server 2007 para preparar el dominio, por lo que puede usar cualquier servidor de 32 bits del dominio raíz. Para obtener más información sobre este tema, consulte technet.microsoft.com/library/bb232170.aspx.
A propósito, esto implica que no es posible instalar el ESM de Exchange Server 2003 y la Consola de administración de Exchange de Exchange Server 2007 en el mismo equipo, puesto que la coexistencia de las herramientas de administración de Exchange Server 2003 y Exchange Server 2007 en el mismo equipo no es compatible. Exchange Server 2007 bloqueará la instalación si intenta instalarlo en un equipo que tenga instalado algún componente de Exchange Server 2000 o Exchange Server 2003.
Finalmente, tenga en cuenta que no debe intentar instalar las herramientas de administración de Exchange Server 2007 en primer lugar y, a continuación, seguir con las herramientas de Exchange Server 2003 en el mismo equipo. Este enfoque le colocará en una configuración que no ha sido probada y que podría ofrecerle resultados inesperados al tratar de administrar los servidores. Si necesita administrar ambas versiones de servidor desde un solo equipo, podría usar el escritorio remoto para conectarse a una versión, o usar un equipo virtual para hospedar una versión diferente de las herramientas de administración en un entorno aislado.

P ¿Cuándo podré por fin ejecutar las herramientas de administración de Exchange Server 2007 en la estación de trabajo de Windows Vista®?
R La compatibilidad oficial de las herramientas de administración de Exchange Server 2007 con Windows Vista será posible con el lanzamiento de Exchange Server 2007 SP1. Estará disponible para la descarga un paquete con las herramientas de administración de Exchange Server 2007 SP1 una vez esté disponible la versión de Exchange Server 2007 SP1.

Q ¿Qué ocurre con el ESM de Exchange Server 2003 en Windows Vista o Windows Server 2008? ¿Podré ejecutar eso también?
R No, desgraciadamente esto no es posible. Las herramientas de administración para cualquier versión de Exchange Server anterior a Exchange Server 2007 SP1 no serán compatibles ni en Windows Vista ni en Windows Server 2008. Esto significa que incluso después de los lanzamientos de Windows Server 2008, la instalación del ESM de Exchange Server 2003 en el mismo no será compatible. La administración de los servidores de Exchange Server 2003 tendrá que realizarse desde estaciones de trabajo de Windows Server 2003 o de Windows XP; también puede usar la conexión a Escritorio remoto desde cualquier sistema operativo.

P Tengo varios servidores Exchange Server 2003 ejecutándose en mi dominio. ¿Podré actualizar mis controladores de dominio a los controladores de dominio de Windows Server 2008?
R Sí claro, ejecutar Exchange Server 2003 SP2 en el dominio que tiene controladores de dominio de Windows Server 2008 es compatible. Tenga en cuenta que Exchange Server no puede usar controladores de dominio de sólo lectura (RODC) de Windows Server 2008 ni servidores de catálogo global de sólo lectura (ROGC). Especificar manualmente (codificar) a Exchange Server para que use RODC/ROGC de Windows Server 2008 puede provocar un comportamiento inesperado.

Nino Bilic Administrador de programas de compatibilidad para Exchange Server, emplea su tiempo libre descubriendo la belleza de la comunicación de servidor a servidor leyendo una tonelada de trazas de Netmon antes de ir a dormir cada noche.
Scott LandryIngeniero de escala de soporte técnico para Exchange Server, no va a ningún sitio sin su toalla, una copia de la Guía y su confiable teléfono Windows Mobile.


 Utility Spotlight: Cmdlets de SMS para Windows PowerShell
Utility Spotlight
Cmdlets de SMS para Windows PowerShell
Don Brown
Descargar el código de este artículo: Utility2007_11.exe (1211KB)

Anteriormente no era posible administrar los clientes de Microsoft System Management Server (SMS) 2003 desde la línea de comandos. Por suerte, entre las muchas importantes tecnologías que han surgido últimamente para ayudar a los administradores a administrar la complejidad, cambios y configuración, se presentó Windows PowerShell para resolver ese problema.
Para aprovechar esta situación, creé una pequeña "utilidad", SMS2003PowerShellSnapinSample (que puede encontrar en la descarga de código que acompaña esta columna, disponible en línea en technetmagazine.com/code07.aspx). La utilidad es en realidad una recopilación de seis cmdlets fusionados en un solo componente de Windows PowerShellTM. Mediante estos cmdlets, es posible configurar una directiva local de cliente de SMS desde Windows PowerShell para el equipo local o grupos de equipos remotos.
Cuanto más jugaba con la directiva local de cliente de SMS, más sentido adquiría lo que hacía. Como ventaja adicional, llegué a comprender más detalles sobre el funcionamiento de SMS. Aprendí que a través de la aplicación cuidadosa de la directiva local de cliente de SMS, éste podía controlarse de una manera totalmente nueva: los equipos que pertenecen al mismo sitio no tienen porqué configurarse del mismo modo. Las ideas comenzaron a fluir, desde la configuración de ciertos equipos para que no se requiriera permiso para controlar el equipo remotamente, al cambio de la frecuencia con la que el cliente comprueba si hay nuevas directivas, o la deshabilitación de componentes específicos a varias horas del día, ya no hay límites a la hora de usar la directiva local de cliente de SMS. Echemos un vistazo más detenido.

Acerca de la directiva local de cliente avanzado de SMS
Programación de recursos
  • Presentación de Windows PowerShell Una base ideal para todos aquellos que desean comenzar a usar Windows PowerShell
  • Personalizar SMS mediante directivas locales. Foro de Technet Aplicación basada en MOF de la directiva local de cliente avanzado de SMS
  • Creación del primer Cmdlet
  • Cómo crear un componente de Windows PowerShell
  • Protección de acceso a redes (NAP) para Windows Server 2008
  • Guía del programador de Windows PowerShell Para aquellos que desean más información acerca de escribir cmdlets, componentes, hosts y otra serie de ayudas de programación para Windows PowerShell
  • Guías paso a paso sobre Windows Server 2008 Beta 3

Todos los clientes avanzados y funcionales de SMS 2003 tienen una directiva de configuración, que fundamentalmente es una lista de configuración que dirige sus distintos componentes. En estas directivas de configuración se incluyen todos los clientes, recopilaciones de inventario y configuraciones de distribución de software (entre otros). Las propias directivas se crean en el servidor del sitio y se ofrecen al cliente avanzado a través del punto de administración de SMS.
El cuerpo en sí de una directiva de SMS se parece a un archivo Managed Object Format (MOF) en que contiene un conjunto de instancias que se compilarán en los espacios de nombres \\.\root\CCM WMI (Instrumental de administración de Windows®) en el cliente avanzado. El resto de agentes leerán, a continuación, estas configuraciones, que se encuentran en el espacio de nombres \\.\root\ccm\policy\machine\requestedconfig. No obstante, al aplicar la directiva local a través de MOF, sólo puede compilar un MOF en un solo equipo y debe ejecutarse de manera local (o cuando haya iniciado sesión directamente en la máquina). Sin embargo WMI, debido a su naturaleza distribuida, es accesible tanto de manera local como remota, lo que ofrece un amplia gama de opciones para ayudar a los administradores de SMS. Esto significa que puede conectarse a WMI en un equipo remoto con la misma facilidad que desde su equipo local, siempre que se den los derechos administrativos apropiados.
La directiva de cliente de SMS consiste en opciones de configuración para los distintos componentes de cliente, pero también puede incluir las instrucciones para ejecutar el contenido del paquete de software. Al igual que con la directiva de grupo de Active Directory®, la directiva de cliente avanzado de SMS 2003 obtenida desde un punto de administración de SMS puede invalidarse con la directiva de cliente local de SMS. No es posible invalidar todas las partes de una directiva, pero algunas propiedades realmente interesantes sí que pueden invalidarse. Esto ofrece a los administradores de SMS un mayor grado de control sobre la configuración y operaciones del cliente de SMS porque permite las excepciones a la configuración estándar aplicada en el sitio de SMS.
Tome como ejemplo un entorno seguro y consolidado, donde los administradores de SMS administran los servidores y las estaciones de trabajo como clientes de un solo sitio principal de SMS. En este entorno imaginario, una directiva de seguridad puede indicar que se pida permiso al usuario antes de que los técnicos del servicio de asistencia puedan obtener el control remoto sobre el equipo. Esto obviamente resulta un problema si los técnicos del servicio de asistencia desean usar el control remoto para asociarse a los servidores: normalmente, ningún usuario inicia sesión en los servidores, por lo que nadie puede otorgar el permiso de control remoto. Sin embargo, gracias a la cuidadosa aplicación de la directiva local, el requisito del permiso del usuario puede invalidarse en clientes específicos. Probablemente, puede imaginarse muchas otras circunstancias en las que puede resultar práctico conceder una excepción a la directiva local de SMS para la configuración de un agente de cliente de SMS particular.

Dentro del componente de Windows PowerShell
Una vez que adquiera cierta familiaridad con los principios básicos de Windows PowerShell, puede usar el código fuente de ejemplo que ofrece esta columna para ampliar lo que puede hacer a la directiva local de cliente de SMS desde la línea de comandos. Hay atributos específicos que deben aplicarse a una clase antes de exponerla en Windows PowerShell. Necesita decidir a qué hace referencia el cmdlet y qué acción debe llevarse a cabo. A esto se le denomina emparejamiento "verbo-nombre". Algunos verbos comunes que verá en Windows PowerShell son Add, Get y Set. La parte del sustantivo describe el objeto sobre el que desea actuar. Los cmdlets normalmente tienen parámetros, que se declaran en una clase de Cmdlet como las propiedades públicas de varios tipos. Por último, la función ProcessRecord es el lugar principal donde llevará a cabo la mayor parte de su trabajo. La figura 1 muestra una plantilla genérica que puede usar para cmdlets propios.
Figure 1 Plantilla de Cmdlet (Close Figure 1)
[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true,
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}
Una vez que ha compilado su componente, lo registra con Windows PowerShell e incluye una clase en su proyecto que tenga establecido el atributo RunInstaller y unas pocas propiedades específicas definidas. Consulte el código fuente que acompaña a este artículo para obtener información más específica. Para registrar su componente, necesitará usar la herramienta InstallUtil.exe que se incluye en Microsoft® .NET Framework. La figura 2 muestra la sintaxis que debe usar para registrar su componente. Tenga en cuenta que en Windows Vista® es una operación que requiere la elevación de privilegios, por lo que deseará abrir Windows PowerShell con la opción "Abrir como administrador" o usar Script Elevation PowerToys para Windows Vista (que puede descargar en technetmagazine.com/issues/2007/06/UtilitySpotlight).
Figure 2 Cómo instalar el componente desde Windows PowerShell (Close Figure 2)
PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Running a transacted installation.
...
The transacted install has completed.
El paso siguiente consiste en averiguar si Windows PowerShell reconoce el componente. Use el cmdlet Get-PSsnapin con el parámetro Registered para que Windows PowerShell resuma los componentes cargados actualmente, seguido de una lista de componentes registrados que se pueden agregar. Su componente debe encontrarse en esta lista:
PS> Get-PSsnapin -registered
Ahora puede agregar el componente de Windows PowerShell al shell mediante el cmdlet Add-PSsnapin, del siguiente modo:
PS> add-pssnapin SMS2003PowerShellSnapinSample
Si la operación se realiza correctamente, debe poder ejecutar los cmdlets en el componente de Windows PowerShell.
Para consultar todos los cmdlets disponibles a través de cualquier componente de Windows PowerShell, sólo tiene que especificar el componente en particular con el cmdlet Get-Command, incluido el nombre de su componente como valor para el parámetro PSsnapin. El componente de ejemplo que acompaña esta columna muestra seis cmdlets, incluida la plantilla de Cmdlet verbo-nombre, como se muestra en la figura 3.
Figura 3 Visualización de los cmdlets de un componente
Figura 3 Visualización de los cmdlets de un componente
En el código fuente de ejemplo, sólo he escrito ayuda para el cmdlet Get-SMSServerConnection para demostrar cómo se ha creado. Si desea ampliar la ayuda, tendrá un ejemplo sobre el que basarse en el archivo XML. La figura 4 muestra el resultado de la ayuda.
Figure 4 Resultado del ejemplo Get-Help (Close Figure 4)
PS > get-help Get-SMSServerConnection

NAME
    Get-SMSServerConnection

SYNOPSIS
    This cmdlet establishes a connection to the specified SMS primary site server using your current credentials. An object of type "SMSProvider" is returned through the pipeline.

SYNTAX
    Get-SMSServerConnection [-SMSServerName] [<string>] [<CommonParameters>]

DETAILED DESCRIPTION
    This Cmdlet makes a connection to the specified SMS primary site server.  An object of type "SMSProvider" is returned. The "SMSProvider" object is not serializable and is used only to forward on through the pipeline to other cmdlets.

RELATED LINKS
Ahora que ya sabe cómo instalar el componente de Windows PowerShell, cómo averiguar qué comandos están presentes en el componente y cómo obtener ayuda en un cmdlet típico, comencemos a usar los cmdlets. Para mostrar una lista de todas las recopilaciones en un servidor de sitio principal de SMS, puede usar el siguiente comando:
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name
Tenga en cuenta la canalización. Esta es una parte fundamental del funcionamiento de Windows PowerShell y es una herramienta muy eficaz. Es posible hacer casi cualquier cosa en Windows PowerShell en una línea. El cmdlet Get-SMSServerConnection establece una conexión con el servidor SMS. Puesto que el cmdlet Get-Collections tiene un solo parámetro de entrada del tipo devuelto por Get-SMSServerConnection, puede pasar simplemente el resultado desde el cmdlet Get-SMSServerConnection al cmdlet Get-Collections. Así es cómo funciona la canalización, se trata de un buen ejemplo sobre cómo transmitir objetos complejos de un cmdlet a otro. También puede almacenar objetos en variables y si ya lo hacía en un script de Windows PowerShell, puede que tenga el siguiente aspecto:
$SMS = Get-SMSServerConnection
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS
El resultado puede ser un poco difícil de leer si la salida no tiene formato, ya que Get-Collections devuelve un objeto del tipo SMSCollections (que es básicamente una matriz de objetos del tipo SMSCollection). En resumen, la visualización no es muy agradable hasta que elimine las recopilaciones que no le interese ver o dé formato al resultado en una tabla que sólo contenga las propiedades que le interesan. Esto se consigue pasando el resultado del cmdlet Get-Collections a través de la canalización al cmdlet Format-Table, que sólo puede mostrar las propiedades que especifique. Por ejemplo, puede anexar | Format-Table Name, Members.
Pero hay una mejor manera de mostrar todos los miembros de una recopilación determinada y en este ejemplo es Get-CollectionMembers. Este cmdlet devuelve una matriz de cadenas, que representan el nombre de cada miembro de la recopilación. Tal como habrá adivinado, se trata de un estupendo candidato para transmitir la canalización al próximo cmdlet.
Hasta este punto, no ha habido directiva local de cliente avanzado de SMS, sólo conexiones al servidor del sitio principal de SMS y enumeraciones de recopilaciones y miembros de recopilaciones. En este componente de ejemplo de Windows PowerShell hay dos últimos cmdlets, denominados Enable-SoftwareDistribution y Disable-SoftwareDistribution respectivamente. Aquí es donde entra en juego la directiva local de cliente de SMS. Estos dos últimos cmdlets manipulan la directiva local de cliente de SMS para el componente del agente del cliente de distribución de software en el cliente avanzado de SMS. Tal como habrá adivinado por la parte del verbo del cmdlet, Disable coloca una invalidación de la directiva local de cliente que especifica que el Agente del cliente de distribución de software también debe deshabilitarse. Del mismo modo, el verbo Enable elimina todas las invalidaciones de directivas locales de cliente, devolviendo el Agente del cliente de distribución de software a su estado normal, que se define por la directiva de SMS transmitida a través del punto de administración de SMS. La figura 5 muestra un ejemplo del aspecto que podría tener una línea de Windows PowerShell que coloca una invalidación de directiva local de cliente de SMS en el Agente del cliente de distribución de software y lo fuerza a ser deshabilitado para todos miembros de la recopilación personalizada de los sistemas Windows Server 2003. La línea para quitar todas las invalidaciones de directivas locales de cliente de SMS para el Agente del cliente de distribución de software también se incluye en esa misma recopilación. Los cmdlets Disable-SoftwareDistribution y Enable-SoftwareDistribution pueden usarse también individualmente, si sólo tiene unos pocos equipos en los desea manipular la directiva local de cliente de SMS.
Figure 5 Cómo ensamblar los cmdlets, ejemplos (Close Figure 5)
PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

Pasos siguientes
El código fuente de ejemplo que viene con este artículo puede proporcionar un buen punto de partida para aplicar las invalidaciones de las directivas locales de cliente de SMS a los grupos de equipos. El ejemplo actual sólo cubre el Agente del cliente de distribución de software y por tanto sólo la propiedad Enabled. Los otros agentes de cliente tienen muchas más propiedades a las que puede aplicar invalidaciones de la misma manera. Ahora que ya dispone de un punto de partida común, el siguiente paso lógico es observar otras partes de la directiva local de cliente de SMS. Piense en grupos de sistemas administrados que puedan ser buenos candidatos para las invalidaciones de directivas locales de cliente de SMS y qué reemplazo de directiva local tiene sentido que use. Nota final: Es aconsejable conocer siempre de antemano las repercusiones de estas actuaciones, así que debe probar todo con detenimiento en un entorno de laboratorio.

Don Brown es un Ingeniero de campo principal en Microsoft y ha trabajado y prestado asistencia técnica para SMS (es decir, SCCM) durante muchísimo tiempo. Póngase en contacto con él en donbrown@microsoft.com.


 The Cable Guy: Inicio de sesi&#243;n &#250;nico inal&#225;mbrico
The Cable Guy
Inicio de sesión único inalámbrico
Joseph Davies

Las conexiones inalámbricas que se establecen y después se deben autenticar con una red privada pueden suponer una complicación adicional tanto para el usuario como para el administrador. Un cliente inalámbrico basado en Windows miembro de un dominio de Active Directory debe realizar una autenticación basada en IEEE 802.1X para obtener una conexión inalámbrica protegida
y un inicio de sesión en el dominio. Puesto que la autenticación puede implicar el uso de credenciales del usuario o el equipo y puesto que los inicios de sesión en el dominio son dependientes de la conectividad de la red, surgen problemas al configurar el orden en el que se realizarán las autenticaciones y al especificar qué credenciales usar. Todo esto puede influir en los inicios de sesión en el dominio y provocar que se pidan al usuario credenciales en numerosas ocasiones.
Afortunadamente, el inicio de sesión único inalámbrico en Windows Vista® permite especificar que la autenticación IEEE 802.1X para Acceso protegido Wi-Fi 2 (WPA2)-Enterprise, WPA-Enterprise y la autenticación 802.1X con Wireless Equivalency Privacy (WEP) ocurra antes del proceso de inicio de sesión del usuario. Esto le permite resolver problemas de inicio de sesión de dominio en configuraciones específicas. El inicio de sesión único inalámbrico también integra sin problemas la autenticación inalámbrica con la experiencia de inicio de sesión de Windows®, lo cual repercute en la satisfacción general del usuario. Por estas razones, deseo introducirme este mes en las características del inicio de sesión único inalámbrico, cómo se configura y cómo funciona durante el proceso de inicio de sesión del usuario.

Aspectos básicos del inicio de sesión único
Un cliente inalámbrico de Windows puede realizar la autenticación en la red inalámbrica usando únicamente credenciales de equipo o de usuario, o una combinación de ambos. Si sólo se usan credenciales de equipo, Windows realiza la autenticación 802.1X antes de mostrar la pantalla de inicio de sesión de Windows. Esto permite el acceso anticipado del equipo cliente inalámbrico a los recursos de red como los controladores de dominio de Active Directory®.
Si se usan sólo credenciales de usuario, Windows sin el inicio de sesión único realiza la autenticación 802.1X cuando se completa el proceso del inicio de sesión del usuario. La figura 1 muestra la escala de tiempo de inicio e inicio de sesión para este escenario.
Figura 1 Escala de tiempo cuando se usan sólo credenciales de usuario para la autenticación inalámbrica
Figura 1 Escala de tiempo cuando se usan sólo credenciales de usuario para la autenticación inalámbrica
Las consecuencias de usar sólo credenciales de usuario para la autenticación inalámbrica son que el usuario no puede hacer un inicio de sesión inicial en el dominio a un equipo porque no hay credenciales en caché local para su cuenta de usuario y no hay conectividad al controlador de dominio para autenticar las nuevas credenciales de inicio de sesión. Además, algunas operaciones de inicio de sesión de dominio presentarán errores porque no hay conectividad a los controladores de dominio del dominio de Active Directory en ese momento. Los scripts de inicio de sesión, las actualizaciones de las directivas de grupo y las actualizaciones de perfil presentan errores, lo cual provoca errores de registro de eventos en Windows.
Cuando se usa una combinación de credenciales de usuario y equipo, Windows realiza una autenticación 802.1X con credenciales de equipo antes de mostrar la pantalla de inicio de sesión de Windows. Una vez que el usuario ha iniciado sesión, Windows realiza otra autenticación 802.1X con credenciales de usuario. Algunas infraestructuras de red usan distintas LAN virtuales (VLAN) para equipos que se han autenticado con credenciales de equipo y para aquellos que han usado credenciales de usuario. Si la autenticación a la red inalámbrica que usa credenciales de usuario y el cambio a la VLAN de usuario autenticado ocurre después del proceso del inicio de sesión de usuario, el cliente inalámbrico de Windows no tendrá acceso a los recursos de red en la VLAN de usuario autenticado, como controladores de dominio de Active Directory, durante el proceso del inicio de sesión del usuario. Una vez más, esto lleva a operaciones de inicio de sesión de dominio con errores.
Surge otro problema cuando la autenticación inalámbrica con credenciales de usuario usa un conjunto de credenciales de seguridad distinto a las credenciales del inicio de sesión del usuario. Para dichas configuraciones, Windows solicita credenciales de usuario adicionales cuando comienza la autenticación inalámbrica, lo que puede ser confuso.
La característica de inicio de sesión único en Windows Vista se desarrolló para solucionar los problemas de los inicios de sesión de dominio, separar las VLAN autenticadas por usuario y por equipo, y solicitar al usuario credenciales distintas en momentos distintos. Con el inicio de sesión único, los administradores de red pueden especificar que esa autenticación inalámbrica con credenciales de usuario ocurra antes del proceso de inicio de sesión del usuario. Cuando las credenciales de usuario necesarias para el inicio de sesión de usuario y para la autenticación inalámbrica son diferentes, se solicitan todas las credenciales necesarias y se reúnen en la pantalla de inicio de sesión de Windows.
Con el inicio de sesión único, un cliente inalámbrico de Windows Vista puede configurarse para realizar la autenticación de red inalámbrica con credenciales de usuario antes del proceso del inicio de sesión del usuario. La figura 2 muestra la nueva escala de tiempo de inicio e inicio de sesión.
Figura 2 Escala de tiempo cuando la autenticación de red inalámbrica con credenciales de usuario ocurre antes del inicio de sesión de usuario
Figura 2 Escala de tiempo cuando la autenticación de red inalámbrica con credenciales de usuario ocurre antes del inicio de sesión de usuario
Esto permite configuraciones que usan sólo credenciales de usuario o una combinación de credenciales de usuario y equipo con VLAN separadas sin pérdida de funcionalidad. Puesto que el cliente inalámbrico tiene conectividad de red o conectividad a la VLAN de usuario autenticado antes de que comience el proceso de inicio de sesión del usuario, las operaciones de inicio de sesión de dominio pueden completarse correctamente. Si desea ver un ejemplo, consulte "Unión de un cliente inalámbrico de Windows Vista a un dominio" en microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx.
Según la configuración del perfil inalámbrico, el inicio de sesión único consolida los campos de entrada de las credenciales de usuario para la autenticación inalámbrica y los agrega a la pantalla de inicio de sesión de Windows. Por lo tanto, el usuario suministra al mismo tiempo todas las credenciales de usuario para el inicio de sesión de usuario y la autenticación inalámbrica que usa credenciales de usuario.
Los métodos del Protocolo de autenticación extensible (EAP) escritos para la nueva arquitectura EAPHost en Windows Vista pueden usar la API de compatibilidad del Proveedor de autenticación de inicio de sesión previo (PLAP) de EAP para incluir los campos de entrada necesarios para la autenticación en la pantalla de inicio de sesión de Windows. Si desea obtener más información, consulte el SSO y API de PLAP en msdn2.microsoft.com/bb530584.
Como ejemplo de inicio de sesión único, considere un cliente inalámbrico de Windows Vista que se ha configurado para realizar la autenticación únicamente mediante credenciales de usuario y un nombre de usuario y contraseña para ambos inicios de sesión en el dominio y la autenticación 802.1X. Cuando el usuario presiona Ctrl+Alt+Supr en la pantalla inicial de Windows Vista, el inicio de sesión único determina que la autenticación 802.1X debe ocurrir antes del inicio de sesión del usuario. Cuando el usuario escribe su nombre de usuario y la contraseña, el inicio de sesión único realiza en primer lugar la autenticación de red inalámbrica basada en el usuario primero y muestra un mensaje que indica que se está realizando la conexión con la red inalámbrica por su nombre. Después de la autenticación inalámbrica, Windows Vista realiza el inicio de sesión del usuario y muestra el escritorio del usuario.

Configuración del inicio de sesión único
Entre bastidores
Para ayudarle a comprender en mayor medida el proceso de autenticación inalámbrica, observemos detalladamente lo que ocurre cuando el usuario intenta iniciar sesión activamente. Cuando un usuario presiona Ctrl+Alt+Supr para el inicio de sesión del usuario en un cliente inalámbrico que ejecuta Windows Vista, se ejecutan los siguientes pasos:
  1. La configuración automática inalámbrica determina el perfil de red inalámbrica que usar. Si el cliente inalámbrico ya ha realizado correctamente la autenticación con credenciales de equipo, se usa el perfil de red inalámbrica conectada actualmente. Si el perfil inalámbrico determinado está configurado para realizar la autenticación sólo con credenciales de equipo, no será necesaria ninguna autenticación inalámbrica adicional con credenciales de usuario. Los pasos del 2 al 6 asumen que el perfil inalámbrico seleccionado está configurado para realizar la autenticación con credenciales de usuario, tiene habilitado el inicio de sesión único y la configuración Realizar inmediatamente antes de que se seleccione el inicio de sesión del usuario.
  2. El usuario escribe sus credenciales para el inicio de sesión de usuario y la autenticación inalámbrica (si fuera necesario) y comienza el inicio de sesión de usuario.
  3. Windows muestra un mensaje al usuario que intenta conectarse al nombre de la red inalámbrica.
  4. Windows intenta realizar una autenticación de red inalámbrica con credenciales de usuario. Si está habilitada la configuración Permitir diálogos adicionales durante la sesión de inicio único y el tipo de EAP necesita mostrar cuadros de diálogo adicionales al usuario, Windows muestra los cuadros de diálogo. Si la autenticación inalámbrica no transcurre correctamente dentro del retardo máximo para la conectividad (en segundos), se abandona la autenticación inalámbrica. Si se selecciona la configuración Esta red usa diferentes VLAN para autenticarse con credenciales de equipo y de usuario, Windows realiza una renovación de DHCP de la configuración de la dirección IP del adaptador de red inalámbrica cuando la autenticación inalámbrica se realice correctamente.
  5. Windows realiza el proceso del inicio de sesión del usuario.
  6. Windows muestra el escritorio.
Si se selecciona la configuración Realizar inmediatamente después de que el usuario inicie sesión, Windows realiza los pasos en el siguiente orden: 1, 2, 5, 3, 4, 6.

Para habilitar y configurar el inicio de sesión único, puede usar la extensión de directiva del grupo de directivas de red inalámbrica (IEEE 802.11) y configurar las opciones de seguridad avanzada para un perfil inalámbrico de una directiva de Windows Vista. Si desea obtener más información sobre el tema, consulte "Configuración de directivas de grupo inalámbricas para Windows Vista" en technetmagazine.com/issues/2007/04/CableGuy.
En el cuadro de diálogo Configuración de seguridad avanzada, seleccione Habilitar inicio de sesión único en esta red y configure las opciones del inicio de sesión único como considere necesario. La figura 3 muestra un ejemplo de inicio de sesión único habilitado con la configuración predeterminada.
Figura 3 Configuración predeterminada de inicio de sesión único
Figura 3 Configuración predeterminada de inicio de sesión único
Existen configuraciones de inicio de sesión único para realizar la autenticación inalámbrica 802.1X inmediatamente antes o después del proceso del inicio de sesión de usuario y para especificar el retraso de tiempo para que se complete la autenticación 802.1X antes de iniciar el proceso del inicio de sesión de usuario. Puede indicar también si desea que se muestren los cuadros de diálogo más allá de la consolidación de campos de entrada en la pantalla de inicio de sesión de Windows. Por ejemplo, si un tipo EAP desea que el usuario confirme el certificado enviado desde el Servicio de autenticación remota telefónica de usuario (RADIUS) durante la autenticación, el tipo EAP puede mostrar el cuadro de diálogo.
También puede especificar que el cliente inalámbrico debe iniciar una renovación del Protocolo de configuración dinámica de host (DHCP) de la configuración TCP/IP del adaptador inalámbrico después de realizar la autenticación basada en el usuario. Seleccione esta opción si hay VLAN separadas para los clientes inalámbricos autenticados de equipo y usuario y si esas VLAN son subredes IPv4 o IPv6 diferentes.
Después de crear el perfil inalámbrico que contiene la configuración de inicio de sesión único dentro de la directiva, puede configurar también clientes inalámbricos de Windows Vista exportando el perfil como un archivo XML y, a continuación, importando el perfil XML en clientes inalámbricos de Windows Vista.
Para crear un perfil inalámbrico de inicio de sesión único, cree un perfil inalámbrico con la configuración de inicio de sesión único apropiada. En la ficha General de la directiva inalámbrica de Windows Vista, haga clic en el perfil inalámbrico con la configuración de inicio de sesión automático y, a continuación, haga clic en Exportar. Cuando se le solicite, especifique el nombre y ubicación del archivo XML del perfil.
Para usar el perfil XML de inicio de sesión único para otro cliente inalámbrico de Windows Vista, importe el perfil XML con el comando:
netsh wlan add profile filename=
    "[FileName].xml"
Para determinar si un perfil inalámbrico tiene habilitado el inicio de sesión único, use:
netsh wlan show profile=[ProfileName]
La configuración de inicio de sesión único se indica en la sección "Configuración de seguridad" de la pantalla de comando netsh wlan show profile y en el texto de los eventos de conexión inalámbrica en el registro de eventos de Windows. Además, puede usar el componente Visor de eventos para ver los eventos en la carpeta Microsoft\Windows\Configuración automática de WLAN de los registros de aplicaciones y servicios con el origen de "Configuración automática de WLAN" y las Id. de evento 13001, 13002, 13003 y 13004.
Encontrará más información en la página Web Redes inalámbricas en microsoft.com/wifi. Y consulte la barra lateral "Entre bastidores" si desea conocer más detalles sobre el proceso de inicio de sesión único.

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


 Notas de investigaci&#243;n: Uso de la inform&#225;tica de alto rendimiento en la lucha contra el VIH
Notas de investigación
Uso de la informática de alto rendimiento en la lucha contra el VIH
Kristin Firth y Mia Matusow

Al pensar en las personas que llevan a cabo investigaciones médicas, ¿sólo imagina hombres y mujeres con la característica bata blanca de laboratorio trabajando con tubos de ensayo y microscopios? ¿Quizás un equipo de químicos en una universidad o una compañía farmacéutica? Éstos son las ideas más comunes y reales que normalmente se tienen sobre la investigación médica, pero sólo representan
uno de los aspectos de todo el campo. En el mundo real, parte del amplio campo de la investigación médica se lleva a cabo en entornos muy diferentes.
Quizás se sorprenda al conocer que Microsoft Research juega un papel fundamental en el esfuerzo por desarrollar una vacuna para el virus de la inmunodeficiencia humana (VIH). Además, Microsoft no usa para ello ningún tipo de instrumento o instalación de laboratorio. El ambiente es más el de una oficina, amueblada con mesas y muchos PCs.
Así que, ¿qué papel juega Microsoft en toda esta investigación? Esas personas con batas de laboratorio blancas (los científicos de varias universidades y centros de investigación, incluidos el hospital Massachusetts General en Boston, la Universidad de British Columbia, la Universidad de Washington, el Fred Hutchinson Cancer Research Center y Murdoch University en Australia) reúnen grandes cantidades de datos en sus proyectos. El grupo eScience de Microsoft Research, que cuenta con unas seis personas ubicadas principalmente en Redmond, Washington (y una persona en Nuevo Méjico), ayuda a estos investigadores a procesar y analizar enormes cantidades de datos. Microsoft Research se integró en este proyecto en el año 2003 y hoy en día el grupo eScience colabora con científicos en varios de proyectos que tratan de solucionar los problemas que afectan a la sociedad. El equipo trabaja muy de cerca con científicos externos, creando soluciones personalizadas para proyectos, analizando detalladamente cifras y resultados.
Microsoft colabora en un proyecto de alta prioridad para analizar los datos relacionados con los patrones de mutación del VIH. David Heckerman, médico y doctorado, Investigador principal para Microsoft, explica que el VIH muta rápidamente cuando es atacado por el sistema inmunológico de una persona infectada. "Actualmente trabajamos en un estudio que intenta determinar cómo muta el VIH en respuesta al sistema inmunológico del portador. Para hacerlo, examinamos las correlaciones entre el tipo de sistema inmunológico de la persona y las secuencias de proteínas del VIH que lo infectan."
Los científicos usan las muestras de personas infectadas con VIH para determinar los tipos de sistema inmunológico y las secuencias de VIH. Aquí es donde se entiende el análisis al detalle de las cifras. El estudio busca correlaciones entre 3.000 aminoácidos del VIH y centenares de tipos de sistemas inmunológicos de centenares de personas. "Hemos diseñado pruebas estadísticas que producen correlaciones de confianza, con un número reducido de falsos positivos y falsos negativos", señala Carl Kadie, doctorado e Ingeniero principal de desarrollo de software de investigación para Microsoft. "Sin embargo, estas pruebas requieren gran cantidad de eficacia en el cálculo, por lo que a más sujetos, mayor efectividad. La idea es ejecutar millones de simulaciones para revelar las correlaciones de más confianza".

Uso de la HPC para la lucha contra el VIH
Hace sólo unos años, las limitaciones de procesamiento entorpecían los esfuerzos de investigación. Con tan sólo seis equipos, los investigadores de Microsoft implicados en este proyecto no tenían la suficiente capacidad de procesamiento para llevar a cabo los análisis en el espacio de tiempo necesario. Examinar todas las posiciones del genoma de la vacuna y los distintos tipos de sistemas inmunológicos hubiera supuesto emplear un año para analizar tan sólo 200 sujetos. Incluso si los investigadores tuvieran 20 equipos para dedicarlos por completo al análisis, se habrían encontrado con el problema de tener que llevar a cabo las pruebas manualmente en 20 equipos individuales, recibiendo 20 conjuntos individuales de resultados, por lo que hubieran necesitado otro programa (además de más tiempo) para tabular los conjuntos individuales de resultados. La administración de los múltiples trabajos, la unión de los resultados parciales y el resto de tareas individuales implicadas habrían llevado demasiado tiempo. Por lo tanto se integraron en el grupo de Informática de alto rendimiento (HPC) de Microsoft.
En 2006, los investigadores implementaron Windows® Compute Cluster Server 2003. Esta solución de HPC puso en marcha un método sencillo para que los investigadores administraran el rendimiento de muchos equipos funcionando al mismo tiempo. Esencialmente, Windows Compute Cluster Server permite distribuir el trabajo a través de los nodos de servidor que se ejecutan en paralelo. La tarea de distribuir los datos entre los nodos, administrando los datos y combinando los resultados se ha automatizado por completo. La solución incluye los procedimientos de instalación, un conjunto de herramientas de administración y un programador de trabajo integrado.
Finalmente, con esta solución, las barreras tecnológicas más significativas se han derribado: la potencia de cálculo ya no estaba limitada y el proceso de distribución del trabajo y la administración de datos se automatizó por completo.

La instalación
Para Microsoft Research, el clúster de cálculo supuso una gran ventaja. Windows Compute Cluster Server 2003 es ideal para proyectos que implican aplicaciones que realizan la misma operación repetidamente, por ejemplo, cuándo la resolución de problemas y el análisis pueden acelerarse ejecutando tareas en paralelo. Sin embargo, la implementación de esta solución no debería emprenderse a la ligera, pues la informática de alto rendimiento puede ser excesivamente intensiva, especialmente en términos de energía y enfriamiento. Implica varios servidores que, a menudo, funcionan al 100 por cien de uso de CPU durante semanas.
Los pasos siguientes tienen como objeto determinar las dimensiones del clúster que puede permitirse la organización y dónde se puede almacenar. Si el entorno ya se basa en Windows con Active Directory® en uso, los administradores disponen de la infraestructura que necesitan para instalar, implementar y ser compatible con un clúster. En los entornos en los que Active Directory no está en uso, se requieren una serie de pasos de configuración adicionales.
Debe decidir también cómo disponer los nodos dentro del clúster de cálculo, lo cual implica usar las herramientas que vienen con Compute Cluster Server 2003 o usar sus propias técnicas internas de implementación. Necesita implementar Compute Cluster Server 2003 junto con las aplicaciones de software que desea ejecutar en el clúster. Debe configurarse también el acceso del usuario al clúster de modo que los usuarios tengan la capacidad de conectar con el clúster y de enviar trabajos, lo cual puede realizarse a través de la IU gráfica incluida o a través de interfaces de línea de comandos.
Compute Cluster Server 2003 es un sistema operativo de 64 bits. (La arquitectura típica de un entorno de Compute Cluster Server 2003 se ilustra en la figura 1.) En el momento en el se escribía esta columna (junio 2007), Microsoft Research ejecutaba una variedad de aplicaciones diferentes en un clúster creado sobre 25 servidores IBM eServer 326. Cada uno de estos servidores cuenta con dos procesadores AMD Opteron que se ejecutan a 2,6 GHz.
Figura 1 Control de la eficacia con Windows Compute Cluster Server 2003
Figura 1 Control de la eficacia con Windows Compute Cluster Server 2003
Tras implementar Windows Compute Cluster Server, el grupo actualizó la aplicación que lo usa para que la correlación genética se ejecute en el clúster. La complejidad de implementar las aplicaciones para los clústeres de cálculo puede variar. Las propias aplicaciones influyen en la cantidad de programación que es necesaria.
Al principio, el grupo usaba las herramientas integradas en Windows Compute Cluster Server para establecer rápidamente una IU genérica. Sin embargo, esto sólo fue una solución rápida, pronto el grupo creó su propia aplicación web personalizada, que ofrece mayor flexibilidad y es compatible con la opción de exponer algunos de los nodos de clúster a científicos no pertenecientes a Microsoft. De hecho, Microsoft forma parte del Open Grid Forum y parte de los clústeres de Microsoft Research se ponen a disposición de usuarios de otras universidades repartidas por todo el mundo, posibilitando a los investigadores colaborar y compartir la carga de trabajo.
Además de sus IU gráficas, Windows Compute Cluster Server también es compatible con operaciones de línea de comandos, permitiendo a los usuarios escribir scripts. Ofrece, asimismo, API enriquecidas que se pueden usar para escribir los programas que interactúan directamente con el programador de proyectos de Windows Compute Cluster, una técnica que Microsoft Research eligió poner en marcha.

Obtener resultados
Gracias a su uso de la informática de gran rendimiento, el grupo eScience de Microsoft Research está consiguiendo grandes avances en la carrera por el desarrollo de una vacuna contra el VIH. "Con la informática de alto rendimiento es posible acelerar el tiempo de investigación", comenta Heckerman. "Varios de los grupos externos con que colaboramos ahora usan nuestras técnicas estadísticas y comparten sus conclusiones. Y como resultado, los científicos ya proponen nuevas hipótesis para que hagamos pruebas. Antes, la obtención de resultados hubiera tardado al menos un año para cada paso del proceso. Ahora apenas tarda un solo día".
Antes de Windows Compute Cluster Server, los métodos que usaba Microsoft Research habrían sido poco prácticos debido al tiempo necesario para realizar el análisis. "Con Windows Compute Cluster Server", señala Kadie, "podemos ejecutar 50 trabajos de 200.000 tareas en la misma cantidad de tiempo que se usaba para procesar un solo trabajo".
Ahora que el grupo eScience tiene capacidades de cálculo masivo, puede realizar las pruebas con muchas ejecuciones en datos simulados. Las ejecuciones en datos simulados son críticas a la hora de determinar qué resultados en datos reales son los interesantes. Cuantas más simulaciones se lleven a cabo, más confiables serán los resultados.

Lecciones aprendidas
Microsoft Research se ha beneficiado obviamente del uso de Windows Compute Cluster Server, pero la relación es simbiótica por naturaleza. Los desarrolladores del grupo de informática de alto rendimiento, que trabajan en una segunda versión de Windows Compute Cluster Server, continúan ampliando conocimientos a partir de los comentarios que proporciona el grupo eScience.
En particular, el grupo de HPC ha aprendido mucho acerca de la asignación de recursos al supervisar y analizar el comportamiento del clúster de Microsoft Research para determinar la mejor manera de equilibrar los recursos del clúster entre múltiples usuarios. Por ejemplo, en este proyecto, un usuario normalmente crea un trabajo cada vez con una media de 50 tareas asociadas con cada trabajo. El usuario envía el trabajo y el administrador de trabajos de Windows Compute Cluster asigna suficientes recursos para administrar las 50 tareas. Para hacer esto, reclama inmediatamente que todos nodos disponibles en el clúster trabajen en las tareas. Este escenario no sería problemático en un entorno de usuario único, pero se ha convertido en un problema en un entorno multiusuario donde es muy importante que los proyectos progresen simultáneamente.
Actualmente, cuando se completan 10 de las 50 tareas del trabajo, los 10 servidores no se quedan libres. El Administrador de trabajos espera hasta que se hayan completado las 50 tareas del trabajo antes de dejar libres los servidores para que gestionen otro trabajo. Los desarrolladores de HPC trabajan ahora para obtener un método de reasignar los recursos al completarse cada tarea, no el trabajo total.
Microsoft Research contó también con el grupo de HPC para ayudar a resolver problemas específicos que pertenecían a la manera en la que investigadores deseaban usar Windows Compute Cluster Server. Especialmente, los investigadores deseaban configurar la seguridad para que las credenciales del usuario se propagaran automáticamente desde el front-end web hasta el clúster de cálculo. La solución fue trabajar dentro de Microsoft® .NET Framework y ampliar la autenticación mediante formularios de ASP.NET para que la aplicación web pudiera suministrar los nodos de clúster con credenciales de usuario completas cada vez que un usuario enviaba un trabajo.
Ahora los miembros del equipo eScience en Microsoft Research y sus compañeros de todo el mundo pueden centrarse en las partes más importantes de sus trabajos y dejar todas las tareas implicadas en procesamiento y administración de datos a los equipos. "Como resultado, podemos llegar aún más lejos como equipo", dice Heckerman. "Estamos sobrepasando los límites de lo que se conoce hasta ahora sobre el VIH y progresamos muy satisfactoriamente en la lucha contra la enfermedad".

Kristin Firth y Mia Matusowambas pertenecientes a Blue Line Writing & Editing, han pasado la última década creando contenido estratégico para organizaciones empresariales en los sectores público y privado en tres continentes.


 Windows PowerShell: Escritura de expresiones regulares
Windows PowerShell
Escritura de expresiones regulares
Don Jones

192.168.4.5. \\Server57\Share. johnd@contoso.com. Seguramente reconoce estos tres elementos: una dirección IP, una ruta de acceso UNC (convención de nomenclatura universal) y una dirección de correo electrónico. Su cerebro reconoce su formato. Cuatro grupos de dígitos, barras diagonales inversas, el símbolo @ y otras indicaciones revelan los tipos de datos que estas cadenas de
caracteres representan. Con sólo pensar un poco, puede reconocer rápidamente que 192.168 por sí solo no constituye una dirección IP válida, que 7\\Server2\\Share no es una ruta de acceso UNC válida y que joe@contoso tampoco representa una dirección válida de correo electrónico.
Los equipos informáticos, desgraciadamente, tienen que esforzarse un poco más para "entender" formatos complicados como estos. Aquí es donde entran en juego las expresiones regulares. Una expresión regular es una cadena, escrita mediante un lenguaje especial de expresiones regulares, que ayuda a los equipos informáticos a identificar cadenas de un formato particular, por ejemplo, direcciones IP, rutas de acceso UNC y direcciones de correo electrónico. Una expresión regular bien escrita tiene la capacidad de permitir a un script de Windows PowerShellTM aceptar datos válidos y rechazar datos no válidos que no presentan el formato especificado por el usuario.

Establecimiento de coincidencias simples
El operador –match de Windows PowerShell compara cada cadena con una expresión regular, o regex, y devuelve el resultado Verdadero o Falso dependiendo de si la cadena coincide con el regex. Un regex muy sencillo ni siquiera necesita contener sintaxis especial; será suficiente el uso de caracteres literales. Por ejemplo:
"Microsoft" –match "soft"
"Software" –match "soft"
"Computers" –match "soft"
Cuando se ejecutan en Windows PowerShell, las dos primeras expresiones devuelven Verdadero, mientras que la tercera devuelve Falso. En cada una de ellas, la cadena viene seguida por el operador –match que, a su vez, precede a un regex. De forma predeterminada, el regex flotará por la cadena para encontrar una coincidencia. Los caracteres "soft" se encuentran tanto en "Software" como en "Microsoft", pero en posiciones diferentes. Además, fíjese que, de forma predeterminada, un regex no distingue mayúsculas de minúsculas: "soft" se encuentra en "Software" a pesar de la "S" mayúscula.
Sin embargo, si es necesario, un operador diferente, –cmatch, ofrece comparación de regex que distingue mayúsculas de minúsculas, por ejemplo:
"Software" –cmatch "soft"
Esta expresión devuelve Falso, ya que la cadena "soft" no coincide con "Software" en una comparación que distingue mayúsculas de minúsculas. Tenga en cuenta que el operador –imatch también está disponible como opción explícita que no distingue mayúsculas de minúsculas, a pesar de que este es el comportamiento predeterminado de –match.

Caracteres comodín y repetidores
Un regex puede contener algunos caracteres comodín. Un punto, por ejemplo, equivale a una instancia de cualquier carácter. Un signo de interrogación equivale a cero instancias o a una instancia de cualquier carácter. A continuación, se incluyen algunos ejemplos a modo de ilustración:
"Don" –match "D.n" (True)
"Dn" –match "D.n" (False)
"Don" –match "D?n" (True)
"Dn" –match "D?n" (True)
En la primera expresión, el punto equivale exactamente a un carácter, así que el resultado de la coincidencia es Verdadero. En la segunda expresión, el punto no encuentra el carácter que requiere para la inclusión, de modo que el resultado de la coincidencia es Falso. El signo de interrogación, como se muestra en las expresiones tercera y cuarta, puede coincidir con un solo carácter desconocido o con ningún carácter en absoluto. Finalmente, en el cuarto ejemplo, el resultado de la coincidencia es Verdadero porque "D" y "n" se presentan sin caracteres intermedios. Así, podemos considerar que el signo de interrogación representa un carácter opcional, y el resultado de la coincidencia continúa siendo Verdadero aunque no haya ningún carácter en esa posición.
Un regex también reconoce los símbolos * y + como repetidores. Estos símbolos deben seguir a algún carácter. El símbolo * equivale a cero o más instancias de los caracteres especificados, mientras que el símbolo + coincide con uno o más de los caracteres especificados. A continuación se muestran algunos ejemplos:
"DoDon" –match "Do*n" (True)
"Dn" -match "Do*n" (True)
"DoDon" -match "Do+n" (True)
"Dn" -match "Do+n" (False)
Vea que tanto * como + coinciden con "Do", no sólo con la "o". Esto se debe a que los repetidores están diseñados para coincidir con una serie de caracteres, no solamente con uno.
¿Qué sucede si necesita establecer coincidencias con el punto o los símbolos "*", "?" o "+"? Basta con usar una barra diagonal inversa precedente, que es el carácter de escape de regex:
"D.n" -match "D\.n" (True)
Fíjese que este carácter es diferente del carácter de escape de Windows PowerShell (el apóstrofo hacia atrás), pero sigue la sintaxis de regex estándar del sector.

Clases de caracteres
Una clase de caracteres es una forma más amplia de carácter comodín que representa un grupo entero de caracteres. Windows PowerShell reconoce numerosas clases de caracteres. Por ejemplo:
  • \w equivale a cualquier carácter de palabra, tanto letras como números.
  • \s equivale a cualquier carácter de espacio en blanco: tabulaciones, espacios, etc.
  • \d equivale a cualquier carácter de dígito.
También hay clases de caracteres negativos: \W equivale a caracteres que no son de palabra, \S equivale a caracteres que no son de espacio en blanco y \D equivale a caracteres que no son de dígito. Estas clases pueden aparecer seguidas por * o + para indicar que se aceptan varias coincidencias. A continuación se muestran algunos ejemplos:
"Shell" -match "\w" (True)
"Shell" -match "\w*" (True)
Cmdlet del mes
El cmdlet Write-Debug es muy útil para escribir objetos (por ejemplo, cadenas de texto) en la canalización de depuración. No obstante, el resultado de este cmdlet en el shell puede ser decepcionante, ya que da la impresión de que su efecto es nulo.
El truco es que la canalización de depuración está desactivada de forma predeterminada; la variable $DebugPreference está establecida en "SilentlyContinue". Por el contrario, si la establece en "Continue", todo lo que envíe con Write-Debug aparecerá en la consola como texto amarillo. Esta es una manera perfecta de agregar código de seguimiento a los scripts para comprobar la ejecución de scripts complejos. El color amarillo ayuda a distinguir entre el resultado del código de seguimiento y el resultado normal del script, y podrá anular los mensajes de depuración en cualquier momento sin tener que quitar todas las instrucciones Write-Debug. Simplemente vuelva a establecer $DebugPreference en "SilentlyContinue" y el texto de depuración quedará suprimido.

Aunque ambas expresiones devuelven Verdadero, las coincidencias que ofrecen son apreciablemente diferentes. Afortunadamente, hay un modo de averiguar las intenciones del operador –match: cada vez que se realiza una coincidencia, una variable especial llamada $matches se rellena con los resultados de la misma, es decir, con los caracteres de la cadena que el operador ha encontrado como coincidencia de su regex. La variable $matches retiene sus resultados hasta que se realiza otra coincidencia positiva con el operador –match. La figura 1 muestra la diferencia entre las dos expresiones que le acabo de mostrar. Como puede ver, \w coincide con la "S" de "Shell", mientras que el repetidor \w* coincide con la palabra entera.
Figura 1 Un * puede marcar una diferencia tremenda.
Figura 1 Un * puede marcar una diferencia tremenda.

Grupos, intervalos y tamaños de caracteres
Un regex también puede contener grupos o intervalos de caracteres encerrados en corchetes. Por ejemplo, [aeiou] significa que cualquiera de los caracteres incluidos ("a", "e", "i", "o" o "u") constituye una coincidencia aceptable. [a-zA-Z] indica que cualquier letra en el intervalo a-z o A-Z es aceptable (aunque si usa el operador –match que no distingue mayúsculas de minúsculas, será suficiente usar sólo a-z o sólo A-Z). Por ejemplo:
"Jeff" -match "J[aeiou]ff" (True)
"Jeeeeeeeeeeff" -match "J[aeiou]ff" (False)
También puede especificar un número mínimo y un número máximo de caracteres mediante llaves. {3} indica que quiere exactamente tres instancias del carácter especificado, {3,} significa que quiere por lo menos tres o más instancias, y {3,4} indica que quiere por lo menos tres pero no más de cuatro instancias. Esta es una forma ideal de crear regex para direcciones IP:
"192.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Este regex solicita cuatro grupos de dígitos de uno a tres dígitos cada uno, todos ellos separados por un punto literal. Pero considere este ejemplo:
"300.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Esto muestra las limitaciones de un regex. Aunque el formato de esta cadena parece una dirección IP, obviamente no es una dirección IP válida. Un regex no puede determinar si los datos son realmente válidos; sólo puede determinar si su aspecto es correcto.

Detenga la flotación
La solución de problemas relacionados con regex puede ser complicada. Por ejemplo, aquí tenemos un regex que comprueba una ruta de acceso UNC con el formato \\Server2\Share:
"\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Aquí, el regex mismo es difícil de leer porque es necesario escapar cada barra diagonal inversa literal que quiero comprobar con una segunda barra diagonal inversa. Aunque esto parece funcionar bien, realmente no es así:
"57\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Está claro (por lo menos para nosotros) que este segundo ejemplo no es una ruta de acceso UNC válida; sin embargo, el regex la aceptó. ¿Por qué? Recuerde que un regex flota de forma predeterminada. Este regex simplemente busca dos barras diagonales inversas, una o más instancias de letras y números, otra barra diagonal inversa, y más letras y números. Este patrón existe en la cadena, junto con otros dígitos al principio, que resultan en una ruta de acceso UNC no válida. Lo que hace falta es pedir al regex que empiece a realizar coincidencias al principio de la cadena, sin flotar. Esto se consigue así:
"57\\Server2\Share" -match "^\\\\\w+\\\w+" (False)
El carácter ^ indica que esta es la ubicación donde empieza la cadena. Con esta adición, la ruta de acceso UNC no válida da lugar a errores, ya que el regex espera que los dos primeros caracteres sean barras diagonales inversas y, en este caso, no lo son.
De forma similar, el símbolo $ se puede usar para indicar el final de una cadena. Esto no sería muy útil en el caso de una ruta de acceso UNC, porque este tipo de ruta puede contener segmentos de ruta adicionales, como \\Server2\Share\Folder\File. No obstante, estoy seguro de que hay muchas situaciones en las que desearía especificar el final de una cadena.

Ayuda con expresiones regulares
En Windows PowerShell, el tema de ayuda about_regular_expressions ofrece asistencia básica sobre sintaxis del lenguaje de regex, pero los recursos en línea pueden ofrecer aún más información. Por ejemplo, uno de mis sitios web favoritos, www.RegExLib.com, incluye una biblioteca gratuita de expresiones regulares que se han escrito con varios propósitos y que el público ha contribuido. Puede buscar palabras clave, como "correo electrónico" o "UNC", para localizar rápidamente un regex que cubra sus necesidades o que, al menos, ofrezca un buen punto de partida. Si logra crear un regex estupendo, puede remitirlo a la biblioteca para que otros usuarios puedan usarlo.
También me gusta RegexBuddy (www.RegexBuddy.com). Es una herramienta económica que proporciona un editor gráfico de regex. RegexBuddy simplifica el ensamblaje de regex complejos, además de facilitar la comprobación de cada regex para asegurarse de que acepta cadenas válidas y rechaza cadenas no válidas. Algunos desarrolladores de software han creado también editores y herramientas de comprobación de regex comerciales y shareware gratuito que los usuarios encontrarán de gran utilidad.

Uso de expresiones regulares
Quizás se pregunte para qué usaría un regex en la vida real. Imagine que está leyendo información de un archivo CSV y la usa para crear usuarios nuevos en Active Directory®. Si el archivo de CSV viene generado por otra persona, querrá comprobar que los datos que contiene presentan un aspecto apropiado. Un regex es perfecto para esta tarea. Un regex sencillo como \w+, por ejemplo, puede confirmar que los nombres y los apellidos no contienen caracteres especiales ni símbolos, mientras que algo más complicado puede confirmar que las direcciones de correo electrónico cumplen su estándar corporativo. Por ejemplo, podría usar esto:
"^[a-z]+\.[a-z]+@contoso.com$"
Este regex requiere una dirección de correo electrónico con el formato don.jones@contoso.com. El nombre y el apellido sólo pueden contener letras y deben estar separados por un punto. Por cierto, las direcciones de correo electrónico son las cadenas más complicadas a la hora de escribir regex. Si puede restringir el ámbito a un estándar corporativo particular, lo tendrá mucho más fácil.
No se olvide de los delimitadores de inicio y fin (^ y $), que garantizan que no hay caracteres ni símbolos detrás de contoso.com y que no hay ningún elemento precedente a los caracteres que forman el nombre del usuario.
Realmente, el uso de este regex en Windows PowerShell es bastante sencillo. Si damos por sentado que la variable $email contiene la dirección de correo electrónico que lee del archivo CSV, algo como lo siguiente servirá para comprobar su validez:
$regex = "^[a-z]+\.[a-z]+@contoso.com$"
If ($email –notmatch $regex) {
  Write-Error "Invalid e-mail address $email"
}
Y, en este ejemplo, ha aprendido un operador nuevo. -notmatch devuelve Verdadero si la cadena no coincide con el regex proporcionado. También hay un –cnotmatch para comparaciones que distinguen mayúsculas de minúsculas.
Hay muchos más aspectos de las expresiones regulares que no he tratado aquí, entre ellos, otras clases de caracteres, operaciones más avanzadas y algún que otro operador. También está el tipo de objeto [regex] compatible con Windows PowerShell. Sin embargo, lo que he cubierto en esta introducción rápida sobre la sintaxis de regex será suficiente para que pueda ponerse manos a la obra. Visíteme siempre que lo desee en www.ScriptingAnswers.com si necesita ayuda con algún regex especialmente complicado.

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


 Hey, Scripting Guy!: Administraci&#243;n de escritorios desde ultratumba
Hey, Scripting Guy!
Administración de escritorios desde ultratumba
Los encargados del scripting
Descargar el código de este artículo: HeyScriptingGuy2007_11.exe (151KB)

Con motivo de la abrumadora demanda popular, pensamos que este mes deberíamos hacer algo diferente. En lugar de empezar hablando del scripting de administración de sistemas, empezaremos por... (y aquí se oye música siniestra) contar una historia de miedo.
Nota: vale, técnicamente, si de verdad quisiéramos hacer algo diferente este mes, empezaríamos por hablar del scripting de administración de sistemas, para variar. Pero síganos la corriente, ¿vale? Gracias.
Hace muchos años, falleció una de las tataratataratatarabuelas del scripting. Poco después de enterrar a la abuela en un ataúd de madera muy sencillo, el abuelo empezó a tener pesadillas terribles en las que veía a su amada esposa arañando el ataúd, tratando desesperadamente de salir de la tumba. Después de repetirse las pesadillas varias veces, y tras repetidas súplicas, el abuelo convenció finalmente a las autoridades locales para que exhumaran el cuerpo. Cuando abrieron el ataúd, todos quedaron horrorizados al ver que las uñas de la abuela estaban torcidas y el interior del ataúd estaba lleno de arañazos.
Bueno, quizás esta historia no sea enteramente cierta; de hecho, cuanto más lo pensamos, más convencidos estamos de que no tiene nada de verdadera. No obstante, la historia nos enseña una lección importante. No tenemos la menor idea de cuál, pero tiene que estar ahí, en alguna parte.
Espere un momento, ¡ahora nos acordamos! Los ataúdes se diseñaron originalmente para proteger al difunto de los elementos y para evitar la descomposición del cuerpo. Desgraciadamente, los ataúdes tuvieron una consecuencia inesperada: al menos en teoría, es posible enterrar a personas vivas y las cajas de pino dificultan mucho la escapada. Como demuestra claramente la historia de la tataratataratatarabuela del scripting, incluso los mejores planes pueden tener como resultado el desastre... y el entierro de personas vivas. (Música siniestra una vez más...)
Nota: por supuesto, esto es así a menos que elija la opción del ataúd mejorado, inventado por Franz Vester alrededor de 1860. Este ataúd incluye una cuerda conectada a una campana que permanece en la superficie; en caso de entierro prematuro, el "difunto" puede tocar la campana para pedir ayuda. Este ataúd mejorado incluye también una escalera plegable, aunque no nos queda enteramente claro cómo una escalera plegable te puede ayudar a escapar de un ataúd que está dos metros bajo tierra. Si resulta que te entierran encima de un garaje, bueno, una escalera plegable sería útil. Pero en caso contrario...
Exactamente lo mismo (lo de que incluso los mejores planes pueden llevar al desastre) se puede aplicar a los firewalls de Internet. (Bueno, más o menos...) Los firewalls se diseñaron originalmente para mantener a los tipos malos fuera: bloquean el tráfico de red entrante, lo que puede ayudarle a mantener a piratas informáticos e intrusos alejados de sus equipos. Eso está muy bien pero, como ocurre con el problema de ser enterrado vivo, aquí también hay una consecuencia inesperada: los firewalls también pueden dejar fuera a los tipos buenos. Esto es especialmente cierto en el caso de Instrumental de administración de Windows® (WMI), que depende de DCOM para realizar tareas administrativas en equipos remotos. Los firewalls tienden a bloquear todo el tráfico DCOM entrante, algo que hace muy difícil (si no totalmente imposible) la administración de los equipos a través de Internet mediante programación. De hecho, sin abrir puertos adicionales en el firewall y, por lo tanto, sin incrementar su vulnerabilidad ante piratas informáticos e intrusos, esto es totalmente imposible. Por supuesto, a menos que opte por WinRM: Administración remota de Windows (no incluye la escalera plegable).

¿Qué es Administración remota de Windows?
Según el SDK de WinRM (msdn2.microsoft.com/aa384426), Administración remota de Windows es la implementación de Microsoft del Protocolo WS-Management, un protocolo estándar, basado en SOAP y de fácil uso con firewalls que permite la interoperabilidad de hardware y sistemas operativos de proveedores diferentes. Impresionante, ¿no? No vamos a tratar el Protocolo WS-Management en la columna de este mes, así que recomendamos la lectura del SDK de WinRM para obtener los detalles. Por el momento, todo lo que nos interesa es que WinRM está disponible en Windows Server® 2003 R2, Windows Vista® y Windows Server 2008, y que permite administrar equipos a través de Internet. Para ello, WinRM usa el puerto 80, un puerto de servicios estándar de Internet que la mayoría de los firewalls dejan abierto. Sin embargo, el puerto usado por WinRM y el mecanismo de transporte predeterminado, HTTP, se puede cambiar como se requiera.
En la columna de este mes, tampoco trataremos la instalación y la configuración de WinRM. Ya hay mucha información disponible al respecto: msdn2.microsoft.com/aa384372. Sin embargo, nos tomaremos un momento para remarcar un punto importante: si quiere usar WinRM para recuperar información de un equipo remoto (que, por supuesto, es la razón principal para usar WinRM en primer lugar), su equipo local y el equipo remoto deben ejecutar WinRM.
¿Qué significa eso? Bien, significa que si no ha actualizado sus equipos cliente a Windows Vista (¡díganos que no es cierto!) o, si no ha actualizado sus servidores a Windows Server 2003 R2 o a Windows Server 2008, no encontrará WinRM especialmente útil, por lo menos en la actualidad. No obstante, no hace falta decir que este probablemente no será el caso mañana. Y, por supuesto, si damos por hecho que su firewall lo permite, siempre puede usar WMI y DCOM para administrar equipos remotos.

Devolución de todas las propiedades y las instancias de una clase
A quién le importan todas esas advertencias y avisos, ¿no le parece? En vez de preocuparnos de todas esas paparruchas, veamos si podemos averiguar cómo escribir un script que aproveche WinRM. Casualmente, resulta que tenemos un script muy sencillo que, por medio del protocolo HTTP y el puerto 80, conecta a un equipo denominado atl-fs-01.fabrikam.com y, seguidamente, devuelve información completa sobre todos los servicios instalados en el equipo. Consulte la figura 1 para ver el script en todo su esplendor.
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.
Figure 1 Enumeración de servicios en un equipo remoto (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Como puede ver, empezamos por asignar el nombre DNS del equipo (atl-fs-01.fabrikam.com) a una variable llamada strComputer. Alternativamente, podríamos realizar la conexión con la dirección IP del equipo (o incluso con la dirección IPv6). Por ejemplo:
strComputer = "192.168.1.1"
Después de asignar un valor a strComputer, creamos una instancia del objeto WSMan.Automation. Luego, llamamos al método CreateSession para conectar al equipo remoto, en este caso, mediante el protocolo HTTP (justo como dijimos que íbamos a hacer):
Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)
Como mencionamos, queremos devolver información acerca de los servicios instalados en el equipo remoto. Además y, por lo menos para este primer ejemplo, queremos información acerca de todas las propiedades de todos los servicios. ¿Qué significa todo esto? Esto significa que necesitamos especificar una cadena de recurso URI que enlace a la clase Win32_Service en el equipo remoto:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"
Ya, este no es el URI más bonito jamás visto. (Aunque, ahora que lo pienso, creo que nunca se ha visto un URI bonito.) Pero, afortunadamente, la mayor parte del URI es cosa hecha; sólo necesita preocuparse de la ruta WMI al final:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
Esto debería ser bastante sencillo. ¿Qué sucede si desea conectar a la clase root/cimv2/Win32_Process? Pues sólo tiene que modificar la ruta URI en consecuencia:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
¿Que le interesa la clase root/default/SystemRestore? Bien, una vez más, modifique la clase URI, con cuidado de especificar el espacio de nombres predeterminado (en lugar del espacio de nombres cimv2):
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore
Etc... Es una pena que también necesite incluir la parte http://schemas.microsoft.com/wbem/wsman/1/wmi del URI, pero...
Llegados a este punto, estamos listos para recibir algunos datos. Para ello, simplemente llamamos al método Enumerate, con el paso de la variable strResource como único parámetro del método:
Set objResponse = _
  objSession.Enumerate(strResource)
¿Rellenará esta línea de código objResponse con información acerca de los servicios instalados en el equipo atl-fs-01? Seguro que sí. Sin embargo, a diferencia de lo que ocurre con scripting WMI estándar, no recibirá una serie de objetos, cada uno con sus propiedades y métodos de propiedad. En su lugar, recibirá un blob XML enorme que se parece a lo que puede ver en la figura 2.
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>
Figure 2 Blob XML enorme (Close Figure 2)
<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center
Si es todo un experto en XML, esto no supondrá problema alguno; cualquier usuario familiarizado con XML debería ser capaz de analizar y producir esta información sin demasiadas complicaciones (aunque, en palabras del SDK de WinRM, esta información no está en formato de lectura humana). Pero, ¿qué sucede si no es un experto en XML? En este caso, tiene dos opciones. Una, puede esperar hasta el mes próximo, cuando le enseñaremos algunos trucos para trabajar con XML de WinRM. O dos, puede hacer lo que hicimos nosotros en nuestro script de ejemplo: usar la transformación XSL que se instala junto con WinRM.

¿La qué?
Una transformación XSL no es nada más que una plantilla que describe cómo se debe mostrar un archivo XML. Una discusión completa sobre archivos XSL va más allá de lo que podemos hacer en la columna de este mes, bueno, incluso una descripción rápida de los archivos XSL va más allá de lo que tenemos capacidad para hacer en la columna de este mes. Por lo tanto, no intentaremos explicar cómo WsmTxt.xsl (el nombre de la transformación integrada) funciona realmente. En su lugar, simplemente le mostraremos cómo puede usar esta transformación en su script.
Al llamar al método Enumerate, WinRM devuelve un script XML. La manera más fácil de trabajar con estos datos es establecer un bucle Do Until que continúe ejecutándose hasta que alcance el final del script. Eso es lo que hacemos aquí:
Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop
Como puede ver, dentro de nuestro bucle, llamamos a una subrutina denominada DisplayOutput. Cuando llamamos a esta subrutina, pasamos el valor del método ReadItem de la secuencia como parámetro de la subrutina. Como sugiere este enfoque, la secuencia XML se devuelve en trozos, no como un blob de datos enorme. Nuestro script, a su vez, lee los datos XML, un trozo, o un elemento, cada vez.
Mientras tanto, la subrutina DisplayOutput tiene este aspecto:
Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
En pocas palabras, empezamos por crear dos instancias del objeto MSXml2.DOMDocument.3.0. Cargamos la secuencia de datos XML (strWinRMXML) en un objeto y, luego, cargamos el archivo XSL (WsmTxt.xsl) en el otro objeto. Ahora, llamamos al método TransformNode con el fin de usar la información en el archivo XSL para dar formato y mostrar los datos obtenidos de la secuencia XML.
Sí, es algo confuso. Pero por lo menos los resultados (aunque no son perfectos) son más fáciles de leer (consulte la figura 3).
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>
Figure 3 Una versión más limpia de XML (Close Figure 3)
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.
Como ya hemos dicho, esto está muy bien, pero no es necesariamente excelente. Esta es una razón más para regresar el mes próximo, cuando le enseñaremos algunas maneras de manipular los resultados XML.

Devolución de las propiedades y las instancias seleccionadas de una clase
Es obvio que todo esto está muy bien, pero... quizás no refleje del todo su modo de hacer las cosas. Sí, habrá veces en que deseará devolver todas las propiedades de todas las instancias de una clase; sin embargo, también habrá veces (quizás muchas más veces) en que deseará devolver sólo propiedades o instancias seleccionadas de una clase. Por ejemplo, quizás quiera devolver sólo información acerca de los servicios en ejecución, algo que se consigue con un script WMI normal mediante el uso de código semejante a este:
Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")
Muy bien. Pero, ¿se puede saber cómo modificará su cadena de recurso para conseguir la equivalencia con esto?
Bueno, para ser honestos, no modificará su cadena de recurso para hacerla equivalente a la instrucción ExecQuery. Definitivamente necesitará modificar la cadena de recurso, pero también tendrá que hacer otras cosas.
Con esto en mente, echemos un vistazo a la figura 4. Este es un script WinRM que devuelve información acerca de los servicios en ejecución en un equipo (no de los servicios instalados en el equipo).
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>
Figure 4 Búsqueda de servicios en ejecución (Close Figure 4)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
A primera vista, podría parecer idéntica al primer script WinRM que le mostramos; sin embargo, hay algunas diferencias muy importantes. Para empezar, mire el valor que asignamos a la cadena de recurso:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"
Fíjese que, al escribir una consulta filtrada, no especificamos el nombre verdadero de la clase (Win32_Service) con la que queremos trabajar; en su lugar, conectamos simplemente al espacio de nombres (root/cimv2) donde reside esta clase. Recuerde colocar el asterisco (*) al final. Si no lo hace, el script devolverá el mensaje de error "... el nombre de la clase debe ser '*' (asterisco)", lo que significa que necesita dar a la clase el nombre *.
Además, necesitamos definir un filtro y un dialecto:
strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"
El filtro debe ser fácil de resolver; aquí es donde colocamos nuestra consulta WQL ("Select * From Win32_Service Where State = 'Running'"). El dialecto, entre tanto, es el lenguaje de consulta usado al crear el filtro. Actualmente, sólo hay un lenguaje de consulta permitido: WQL. No obstante, se debe especificar el dialecto, o el script devolverá un mensaje de error para indicar que el dialecto del filtro no es compatible.
Nota: es interesante que el mensaje de error sugiere que quite el dialecto al llamar al método Enumerate. Esta es una recomendación que no debe seguir. Cuando se realiza una consulta filtrada, es necesario especificar el dialecto, que debe ser WQL. Punto.
El otro cambio que hay que hacer se da al llamar al método Enumerate. En este momento, necesitamos pasar las variables que representan el filtro (strFilter) y el dialecto (strDialect), así como la variable que representa el recurso (strResource):
Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)
Inténtelo y verá lo que sucede.
Y ahora, ¿qué tal si devolvemos sólo las propiedades seleccionadas de una clase? Por ejemplo, suponga que le interesa devolver sólo las propiedades Name y DisplayName de todos los servicios en ejecución en un equipo. ¿Qué hacemos en este caso?
Bien, en un caso como este, puede tratar de manipular el XML para que sólo se muestren las propiedades Name y DisplayName. Eso es posible, pero también es un poco complicado. Un método más fácil es especificar dichas propiedades al asignar el filtro:
strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"
Con esto, conseguirá las propiedades Name y DisplayName de cada servicio, así:
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Ya, el formato es un poco engorroso. ¿Qué es eso de XmlFragment? Otra razón más para regresar el mes próximo.

Espere y verá.
Con un poco de suerte, esto debería ser suficiente para introducirse en el salvaje y maravilloso mundo de WinRM. Por supuesto, no podríamos terminar una columna sobre WinRM sin mencionar las "morgues de espera" que solía haber por todas partes en Alemania. En ciudades con morgues de espera, los cadáveres no se enterraban inmediatamente. En su lugar, los colocaban en salas bien calentitas y les conectaban varias cuerdas y cables a los dedos. Por supuesto, la idea era que el movimiento más leve activaría una alarma para pedir ayuda. Los cuerpos permanecían en estas morgues de espera hasta que era evidente que estas personas ya no tenían remedio ni esperanza de hacer nada nunca más.
Ahora que lo pienso, una morgue de espera es muy semejante a formar parte del equipo de encargados del scripting, ¿no? Claro que nadie regresó jamás a la vida en ninguna morgue de espera, mientras que en el equipo de encargados del scripting...

Dr. Scripto's Scripting Perplexer
En junio de 2007, los encargados del scripting asistieron a la conferencia Tech•Ed 2007 en Orlando, Florida. Como asistir a la conferencia no fue suficiente, decidimos divertirnos un poco. No sólo eso, sino que pensamos que todo el mundo debía divertirse un poco. Así que inventamos Dr. Scripto's Fun Book, un librillo lleno de rompecabezas de scripting y otras cosas. Nos unimos a TechNet Magazine (es decir, les convencimos para que nos cedieran una esquinita de su espacio en la conferencia) y empezamos a distribuir estos librillos a todo el que pasaba.
Resultó que el librillo fue un artículo bastante popular (quizá no tan popular como las muñecas de Dr. Scripto, pero casi). Los oportunistas de TechNet Magazine vieron de inmediato el modo en que podían aprovechar el éxito de los encargados del scripting (ya que, al parecer, los encargados del scripting no son capaces de aprovechar nunca su propio éxito), y nos pidieron que creáramos algunos rompecabezas para ellos. Cuando Jean Ross, se dio la vuelta sólo un minuto, Greg Stemp dijo "¡Desde luego, lo haremos!" Y aquí estamos: Dr. Scripto's Scripting Perplexer. Que disfrute.

Scripting de orden
En este rompecabezas, todas las letras de la sección superior se pueden ordenar para crear un script (en VBScript). Pero no se preocupe, no tiene que ordenarlo todo a la vez; basta con ordenar una columna cada vez. Las letras en cada columna de la sección superior sirven para rellenar los espacios en blanco en la misma columna de la sección inferior. Por ejemplo:
Como puede ver, en la columna 1, tenemos las letras S, C y T. Estas tres letras pertenecen a la cuadrícula inferior en un orden desconocido. Cuando todas las letras quedan colocadas en el orden apropiado, la cuadrícula inferior se convierte en algo lógico que se puede leer de izquierda a derecha. Eche un vistazo a la solución:
Puede ver que las letras S, C y T en la columna 1 se colocan abajo en el orden T, S y C. Estas resultan ser las primeras letras de cada palabra en "The Script Center". El verdadero rompecabezas es un poco más difícil porque, bueno, es más largo y porque el resultado final es un script completo.
Pista: el script final empieza con una ruta de acceso completa a un archivo, luego se analiza y muestra sólo el nombre del archivo.
¡Buena suerte!

Dr. Scripto's Scripting Perplexer
Respuesta: Scripting de orden, noviembre de 2007
En este rompecabezas, necesita ordenar los caracteres de una columna en los cuadros correctos más abajo para que las filas inferiores creen un script. Aquí tiene el script independiente:
name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
Este es su aspecto en la cuadrícula del rompecabezas:

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: Acceso seguro desde cualquier lugar
Vigilancia de seguridad
Acceso seguro desde cualquier lugar
John Morello

Una de las tendencias innegables en la tecnología actual es el incremento de la conectividad y la movilidad de los trabajadores. Muchas organizaciones tienen personal que realiza sus funciones desde oficinas distantes, trabaja de forma remota o viaja con frecuencia para visitar a los clientes. Si estos usuarios disponen de acceso sencillo a las aplicaciones y los datos, independientemente de su ubicación, serán más
productivos. Sin embargo, hasta hace poco, la disponibilidad de acceso remoto seguro a menudo implicaba la instalación de software de cliente, el uso de comandos largos y misteriosos, y tiempos de conexión prolongados.
Durante los últimos años, han surgido varios enfoques que han convertido el acceso remoto en una tecnología más sencilla y accesible. Por ejemplo, Outlook® Web Access (OWA) ofrece una manera simple basada en explorador de que los usuarios puedan obtener acceso a su correo electrónico, el calendario y los contactos sin las complejidades de una red privada virtual (VPN) de nivel 3. Aunque las tecnologías como OWA pueden constituir una pieza importante de una solución de "acceso desde cualquier lugar", la mayoría de las organizaciones tienen muchas aplicaciones clave que no permiten la misma clase de experiencia integrada de explorador. En estos casos, las soluciones como Terminal Services ofrecen un método eficaz para otorgar a los usuarios acceso a sus aplicaciones allí donde se encuentren.
En Windows Server® 2008, Microsoft mejoró considerablemente el paquete de funciones integradas de Terminal Services. Ahora, Terminal Services incluye una característica de publicación por aplicación en ventanas de conexión directa llamada RemoteApp, una función de controlador de impresión universal en EasyPrint y un portal basado en explorador llamado Acceso web de TS. Además, y este es un aspecto clave en el escenario de acceso desde cualquier lugar, Windows Server 2008 incluye también el componente Puerta de enlace de TS, que ofrece encapsulación SSL para el Protocolo de escritorio remoto (RDP), con lo que puede atravesar dispositivos de traducción de direcciones de red (NAT) y firewalls de un modo fácil y seguro. La función Puerta de enlace de TS se integra también con la Protección de acceso a redes (NAP), otra tecnología nueva en Windows Server 2008 que se encarga de inspeccionar el estado de los clientes de extremo. Cuando se combinan todos estos componentes, las organizaciones tienen la capacidad de crear soluciones que permiten a los usuarios obtener acceso sencillo y seguro a sus aplicaciones y datos desde cualquier parte.
Esta columna se centra en los aspectos de diseño de seguridad y red de una solución de acceso desde cualquier lugar, y no tanto así en los detalles de administración de los componentes de Servicios de Terminal Server. Describiré los métodos y las prácticas recomendadas para la creación de esta solución con base en la tecnología incluida en Windows Server 2008.

¿Cuál es el problema asociado a las redes privadas virtuales de nivel 3?
Al considerar la adopción de cualquier tecnología nueva, es importante que comprenda sus ventajas con respecto a otros enfoques actuales de modo que pueda evaluar exactamente el valor del modelo nuevo. En el caso de una VPN clásica de nivel 3, suelen darse dos problemas principales que es necesario solucionar: seguridad y facilidad de uso.
Puede parecer ilógico mencionar la seguridad como un problema inherente a muchas de las VPN actuales basadas en nivel 3. ¿No es el objetivo absoluto de una VPN proporcionar un túnel seguro por Internet? Para entender este concepto, parémonos un momento a pensar qué cosas solemos tomar como amenazas de VPN. No digo que los datos transmitidos por estas VPN estén en peligro de interceptación o modificación; la mayoría de las VPN de nivel 3 ofrecen cifrado excelente de la secuencia de datos. En lugar de esto, piense en las amenazas que representan los equipos remotos con acceso completo a todos los puertos y todos los protocolos en la red de su organización. El problema no está en las secuencias de datos que las VPN de nivel 3 cifran y transmiten por la red, sino en los clientes remotos que se conectan a través de estos túneles y que suponen un incremento del riesgo para la red interna. Recuerde que la mayoría de las organizaciones afectadas por malware como Slammer o Blaster no recibieron la infección de equipos en la red interna ni de piratas informáticos capaces de burlar el firewall. La infección provino de trabajadores remotos que conectaron a sus redes mediante VPN desde equipos infectados. Cuando estas VPN crean conexiones basadas en nivel 3 completamente enrutadas, el equipo remoto a menudo goza de tanto acceso (bueno y malo) a los recursos internos como cualquier equipo ubicado en el centro de datos.
Lo que es más, las VPN de nivel 3 suelen ser caras de operar, ya que requieren la instalación y la configuración de software en equipos que no están administrados por un grupo de TI de la organización. Por ejemplo, la instalación de un cliente de VPN en el equipo doméstico de un usuario puede conllevar la creación de paquetes de instalación personalizados, indicaciones de instalación detalladas que el usuario debe seguir y conflictos de solución de problemas con aplicaciones en el equipo del usuario. Además, los costos de administración pueden ser altos si resulta necesario implementar nuevas versiones del cliente o los datos de configuración cambian (por ejemplo, si se agrega un extremo nuevo de VPN). Para el usuario, el trabajo a través de esta VPN es, a menudo, una experiencia muy poco intuitiva. Como sólo proporciona la conexión de nivel 3, los datos y las aplicaciones empresariales del usuario no se muestran fácilmente accesibles ni visibles.

Solución de problemas con Terminal Services
Terminal Services, y otras tecnologías VPN del nivel de aplicación o nivel 7, resuelven estos dos problemas al ofrecer un control mucho más preciso sobre los recursos y los protocolos a los que los usuarios pueden obtener acceso y al convertir el trabajo del usuario final en una experiencia mucho más sencilla e intuitiva que antes.
Desde el punto de vista de la seguridad, la característica más importante que diferencia el enfoque de VPN de nivel 3 del uso de Terminal Services y Puerta de enlace de TS es que la conexión a la red interna no es una canalización completamente abierta. En concreto, mientras que un enfoque de nivel 3 creará una interfaz virtual en el equipo local con capacidad de enrutamiento completa hacia la red interna, el enfoque de la puerta de enlace de TS sólo permite paquetes basados en RDP para alcanzar la red interna. Así, la superficie de ataque total queda reducida considerablemente y se pueden aplicar controles más granulares en RDP. Por ejemplo, aunque RDP proporciona compatibilidad nativa con la redirección de unidad, las organizaciones podrían configurar sus puertas de enlace de TS para la integración con NAP y no permitir esta capacidad a menos que el equipo remoto demuestre que su software antivirus está actualizado.
Para los usuarios finales, la diferencia más obvia entre los enfoques basados en VPN de nivel 3 y en Terminal Services es un proceso de configuración mucho más simple (a menudo, no hace falta configuración alguna), así como un acceso más sencillo e intuitivo a las aplicaciones y los datos. Como el cliente de Conexión a Escritorio remoto está integrado en Windows (y se mantiene actualizado a través de tecnologías de servicios normales como Windows® Update), no suele ser necesario instalar software de cliente. Además, mediante Acceso web de TS, los usuarios sólo tienen que visitar una única dirección URL para encontrar todas sus aplicaciones y datos. Basta con hacer clic en la aplicación apropiada para que la puerta de enlace de TS aplique la tunelización segura de la conexión por Internet y la aplicación se proporciona al escritorio del usuario mediante conexión directa. Es decir, la aplicación presentará el aspecto y el comportamiento típicos de una instalación local, incluso podrá copiar y pegar, y minimizar la barra de tareas. Al dotar a las aplicaciones y los datos de una capacidad superior de detección y ofrecer una configuración instantánea, el enfoque basado en Servicios de Terminal Server para conseguir acceso remoto aumenta la satisfacción del usuario y reduce los gastos de soporte técnico.

Opciones de arquitectura de red
Hay dos enfoques básicos de diseño de red que se pueden usar para conseguir la disponibilidad de un servidor Puerta de enlace de TS en Internet. El primero coloca la puerta de enlace de TS en la red perimetral entre dos firewalls de nivel 3/4. El segundo mantiene la puerta de enlace de TS en la red interna y usa un firewall de nivel de aplicación (como Microsoft® ISA Server, Microsoft Intelligent Application Gateway o alguna otra solución de terceros) para permanecer en la red perimetral e inspeccionar los marcos HTTPS entrantes. Los paquetes sólo se reenviarán al servidor interno Puerta de enlace de TS tras el análisis de estas sesiones entrantes.
Si una organización sólo tiene firewalls de nivel 3/4 con inspección básica de paquetes con estado, el dispositivo Puerta de enlace de TS se puede colocar directamente en la red perimetral, como se muestra en la figura 1. En este diseño, el firewall de cara a Internet restringe la conectividad a la puerta de enlace de TS para permitir sólo tráfico HTTPS de Internet. Sin embargo, el firewall no realiza inspecciones en el nivel de aplicación de este tráfico; simplemente reenvía el tráfico a la puerta de enlace de TS. A continuación, el servidor Puerta de enlace de TS extrae los marcos RDP de los paquetes HTTPS y los reenvía al servidor back-end apropiado. Estos servidores back-end suelen estar separados de la red perimetral por un segundo firewall configurado para permitir que los marcos RDP de la puerta de enlace de TS lleguen a los servidores internos adecuados.
Figura 1 Con un firewall de nivel 3/4, la puerta de enlace de TS se coloca en la red perimetral.
Figura 1 Con un firewall de nivel 3/4, la puerta de enlace de TS se coloca en la red perimetral.
Aunque este escenario es completamente posible y puede resultar útil en muchas organizaciones, tiene dos desventajas clave. En primer lugar, como la puerta de enlace de TS recibe tráfico directamente de Internet, está expuesta a un nivel relativamente más alto de riesgo en lo que respecta a partes externas malintencionadas. Estas partes podrían intentar el ataque de la puerta de enlace a través de la sesión SSL y, como el firewall front-end sólo comprueba los encabezados y no las cargas, estas sesiones alcanzarían la puerta de enlace. Esto no quiere decir que la puerta de enlace de TS sea un componente vulnerable; ha pasado por los mismos rigurosos procesos de pruebas y diseño de seguridad que el resto del producto Windows Server 2008. Sin embargo, su riesgo relativo es más alto en esta situación simplemente porque se ocupa de tráfico sin filtrar que procede directamente de Internet. La segunda desventaja es la cantidad superior de tráfico que se debe permitir entre la puerta de enlace y el firewall back-end. Para autenticar usuarios, la puerta de enlace de TS necesita comunicarse con Active Directory®. Para posibilitar esta comunicación, el firewall back-end debe tener excepciones para una gama mucho más amplia de puertos y protocolos que simplemente HTTPS. Este nivel superior de comunicación permitida representa, una vez más, un aumento del riesgo relativo del diseño.
Un enfoque más satisfactorio para exponer una puerta de enlace de TS a Internet es usar un firewall de nivel de aplicación (nivel 7) para ocuparse de sesiones HTTPS entrantes antes de que alcancen la puerta de enlace (consulte la figura 2). En este diseño, aún podría haber una red perimetral formada por firewalls tradicionales de nivel 3/4. Pero, en lugar de tener la puerta de enlace de TS en el perímetro, se coloca allí el firewall de nivel 7. Al tiempo que el tráfico alcanza el firewall de cara al exterior, el firewall filtra todo menos los marcos HTTPS y, seguidamente, reenvía estos marcos al firewall de nivel 7. El firewall de nivel 7 terminará la sesión SSL, inspeccionará el contenido sin cifrar de la secuencia, bloqueará el tráfico malintencionado y enviará los marcos RDP a través del firewall back-end y hacia la puerta de enlace de TS. Fíjese que, si lo desea, el firewall de nivel 7 también podría volver a cifrar los marcos antes de enviarlos a la puerta de enlace de TS. Es posible que este enfoque no sea necesario en la red privada de una organización, pero puede ser muy útil en centros de datos hospedados o en redes compartidas.
Figura 2 Uso de un firewall de nivel de aplicación con un dispositivo Puerta de enlace de TS
Figura 2 Uso de un firewall de nivel de aplicación con un dispositivo Puerta de enlace de TS
Este diseño evita las dos desventajas de la solución anterior. Como el servidor Puerta de enlace de TS sólo recibe tráfico inspeccionado por el firewall de nivel 7, hay menos riesgo de que se den ataques procedentes de Internet. El firewall de nivel 7 debería filtrar estos ataques y enviar sólo tráfico inspeccionado y limpio a la puerta de enlace.
La segunda ventaja principal de esta solución hace referencia a la colocación de la puerta de enlace relativa a la red interna. El tráfico proveniente de Internet queda inspeccionado por el firewall de nivel 7 antes de alcanzar la puerta de enlace, por lo que puede permanecer en la red interna y tener acceso directo a controladores de dominio para la autenticación y a hosts RDP para sesiones de usuario. Además, el firewall back-end puede tener una directiva mucho más restrictiva. En lugar de permitir tanto tráfico RDP como tráfico de autenticación de directorios, simplemente necesita permitir sesiones RDP desde el firewall de nivel 7 a la puerta de enlace de TS. El uso de un firewall de nivel 7 como front-end para la implementación de la puerta de enlace de TS constituye una solución más segura y fácil de administrar sin requerir un diseño nuevo para la red perimetral existente.

Integración de NAP
Recursos de Terminal Services
  • Terminal Services en Windows Server 2008
  • Foro de TechNet sobre Terminal Services en Windows Server 2008
  • Blog del equipo de Terminal Services
  • Microsoft Intelligent Application Gateway 2007
  • Protección de acceso a redes (NAP) para Windows Server 2008
  • Blog de Protección de acceso a redes (NAP)
  • Guías paso a paso sobre Windows Server 2008 Beta 3

Un buen diseño del perímetro es un elemento clave de la solución de acceso desde cualquier lugar, pero es igualmente importante garantizar el cumplimiento y la seguridad de los dispositivos de extremo. RDP es un protocolo rico que permite muchos tipos de redirección de dispositivos, como impresoras y sesiones RDP, por lo que es vital que los clientes que conectan a su solución cumplan las directivas de seguridad de su organización. Por ejemplo, incluso con una topología de red segura basada en prácticas recomendadas como las descritas anteriormente, un usuario final que conecta a un servidor Terminal Server desde un equipo no seguro puede acabar por perder datos confidenciales o colocar archivos malintencionados en el servidor. Aunque la amplitud de la conectividad y los daños potenciales sean mucho menores que si el usuario realizase la conexión a través de una VPN de nivel 3, es importante administrar el riesgo de la pérdida de datos y garantizar el cumplimiento de sus directivas de TI.
La Protección de acceso a redes (NAP) es una tecnología nueva en Windows Server 2008 que permite controlar no sólo quién puede conectar a la red, sino también las clases de sistemas que pueden iniciar la conexión. Por ejemplo, puede usar NAP para asegurarse de que sólo equipos con un firewall en ejecución y software antivirus actualizado puedan conectar a la red. NAP es una solución extensible que cubre no sólo la red interna de la organización, sino también a los usuarios remotos, tanto los que conectan a través de VPN de nivel 3 como los que conectan por medio de la puerta de enlace de TS. Mediante la integración de NAP con el diseño de la puerta de enlace de TS, puede asegurarse de que sólo los sistemas que cumplen sus directivas de seguridad llegan a realizar una conexión satisfactoria. Para más detalles sobre NAP, consulte mi columna Vigilancia de seguridad en el ejemplar de TechNet Magazine de mayo de 2007, disponible en línea en technetmagazine.com/issues/2007/05/SecurityWatch.
La integración de NAP en una implementación de Puerta de enlace de TS es un proceso sencillo que implica un solo servicio adicional en el diseño. Este servicio, el Servidor de directivas de redes (NPS), se puede instalar en el mismo servidor Puerta de enlace de TS o en una instancia de sistema operativo independiente. A continuación, se usa la MMC de la puerta de enlace de TS para crear Directivas de autorización de conexiones (CAP), que definen las capacidades de RDP permitidas para un estado concreto. El servidor Puerta de enlace de TS se configura para consultar a NPS cada vez que se intenta una conexión nueva y para reenviar un informe de mantenimiento (SoH) de la conexión a NPS. El Servidor de directivas de redes compara el SoH con las directivas y comunica a la puerta de enlace de TS si se debe permitir la conexión, según el estado del cliente.
Como ilustra la figura 3, si un sistema que no cumple las directivas no está configurado para usar Windows Update, pero la directiva de seguridad de la organización requiere que las actualizaciones automáticas estén habilitadas, cuando un usuario intenta conectar a la puerta de enlace de TS, su equipo generará y reenviará un SoH. Este SoH informará de que el firewall está activado y el software antivirus está actualizado, pero las actualizaciones automáticas están deshabilitadas. La puerta de enlace de TS simplemente reenviará este SoH al NPS (la puerta de enlace de TS no dispone de lógica para descodificar el SoH por sí misma), y el NPS comparará el SoH con las directivas definidas por su administrador. Como las actualizaciones automáticas no están habilitadas, NPS determinará que la conexión no se presenta en cumplimiento de las directivas, y comunicará a la puerta de enlace de TS que no se debe permitir la conexión. La puerta de enlace de TS descartará la conexión y notificará al usuario que el equipo no cumple las directivas de seguridad de la organización. Así, el usuario puede llevar a cabo la acción correctiva necesaria (en este caso, bastará con habilitar las actualizaciones automáticas) y volver a intentar la conexión. Como resultado, se generará un SoH nuevo, NPS determinará el cumplimiento y la puerta de enlace de TS permitirá la conexión.
Figura 3 Sólo los sistemas que demuestran un estado de cumplimiento pueden conectar.
Figura 3 Sólo los sistemas que demuestran un estado de cumplimiento pueden conectar.

Conclusión
Windows Server 2008 incluye los bloques de creación clave para una solución segura de acceso desde cualquier lugar. La puerta de enlace de TS proporciona un método seguro para la tunelización de sesiones de escritorio remoto por Internet y ofrece a las organizaciones variedad de opciones en cuanto a su integración en las redes existentes. Las opciones incluyen la colocación de la puerta de enlace de TS directamente en la red perimetral o el uso frontal de un firewall de nivel 7, como ISA Server o Intelligent Application Gateway. NAP se puede combinar con Puerta de enlace de TS para agregar funciones de inspección de estado de clientes de extremo en la solución. Las comprobaciones de clientes de extremo ofrecen a las organizaciones la tranquilidad de que las conexiones remotas proceden de usuarios válidos, pero también de que se originan en equipos que cumplen las directivas de seguridad de TI. Cuando se combinan, estas tecnologías proporcionan a las organizaciones capacidades de acceso remoto que son más seguras, más eficientes en el modo de operación y más satisfactorias como experiencia para los usuarios finales. Encontrará más información al respecto en los sitios incluidos en la barra lateral sobre recursos de Terminal Services.

John Morelloha trabajado con Microsoft desde el año 2000. Bajo el cargo de consultor jefe, ha diseñado soluciones de seguridad para empresas del Fortune 100 y para clientes de la administración pública y de defensa. En la actualidad, es administrador jefe de programas en el grupo de Windows Server, que trabaja en tecnologías de acceso remoto en cualquier parte. Puede leer al blog de su equipo en la dirección blogs.technet.com/WinCAT.


 Archivos del escritorio: La verdad acerca de la desfragmentaci&#243;n
Archivos del escritorio
La verdad acerca de la desfragmentación
Wes Miller

La fragmentación de disco surge en paralelo con la aparición de los discos duros. Si le preocupa mantener el buen estado de sus sistemas, debe desfragmentarlos regularmente. Esto probablemente le recuerde a esa conversación anual que mantiene con su dentista sobre la limpieza de los dientes, ya sabe a qué me refiero. Bien, pues la desfragmentación es igual de importante.
A menos que su equipo esté siempre apagado y abandonado en una esquina, con el uso los equipo se fragmentan más y más. En un momento, le mostraré cómo sucede, pero en primer lugar repasemos un poco la historia de la desfragmentación.

Desfragmentación y Windows NT
Windows NT® no contaba con una utilidad de desfragmentación integrada, en aquel momento no se consideraba necesario el disponer de una. A fin de cuentas, NTFS se creó teniendo en cuenta la optimización y no se veía afectado por la fragmentación tan drásticamente como un volumen FAT equivalente. Pero con el tiempo, incluso el rendimiento de NTFS puede sufrir debido a una ubicación de archivos poco efectiva. Esto dio origen a un mercado muy próspero de herramientas de desfragmentación de terceros. Uno de los productos más populares entre los profesionales de TI fue el Diskeeper de Executive Software (ahora Diskeeper Corporation). Cuando Windows 2000 integró la funcionalidad de desfragmentación, Microsoft obtuvo la licencia de la tecnología de Executive Software. La función de desfragmentación de Windows® 2000 estaba disponible en el propio componente de Microsoft® Management Console (MMC) (dfrg.msc), que podía invocarse haciendo clic en un volumen o ejecutando manualmente defrag.exe desde la línea de comandos. A pesar de no disponer de programación y de sólo contar con una línea de comandos restringida, muchos profesionales de TI crearon scripts funcionales para automatizar la desfragmentación con esta versión integrada. Defrag.exe en Windows XP y Windows Server® 2003 aportó ciertas mejoras sobre la versión anterior, pero sólo ofrecía automatización limitada, aún era necesario crear los scripts.
Varios proveedores, incluido Winternals Software (empresa a la que pertenecía anteriormente), crearon software para el espacio de desfragmentación de la empresa. La mayor parte de estos productos funcionan del mismo modo, con una consola centralizada, un agente de determinado tipo que reside en los sistemas cliente (a veces todo el tiempo, a veces sólo a petición) y una estructura para ordenar cuándo y cómo se ejecuta la tarea de desfragmentación.
Windows Vista® continúa en gran parte la tendencia de la desfragmentación de sistema único, aunque se optimiza el desfragmentador y se incluyen opciones tales como la desfragmentación de fragmentos de archivos pequeños (64 MB o menos), lo que acelera la desfragmentación pero deja muchos fragmentos de archivos más grandes a lo largo del disco. El motor de desfragmentación en sí es más eficaz en Windows Vista y Windows Server 2008 que en versiones anteriores de Windows. También se ejecuta automáticamente y no requiere ninguna programación manual. Pero si está a cargo de una gran organización o desea optimizar los sistemas de formas que la desfragmentación no ofrece de manera predeterminada, puede que aún tenga que recurrir a software de terceros. Y, al igual que en versiones anteriores, puede que encuentre dificultades al desfragmentar un volumen en el que la compresión NTFS esté habilitada y se use ampliamente. Una herramienta de terceros puede ser también útil en un escenario de este tipo.

¿Cómo se produce la fragmentación?
La fragmentación se produce porque los archivos cambian con el tiempo. En condiciones ideales los propios archivos de Windows no cambian. O por lo menos, no cambian muy a menudo, realmente sólo con los service pack y las instalaciones de actualización de software. En otros casos los archivos de sistema permanecen relativamente constantes. Tras realizar una actualización a gran escala como la instalación de un service pack, la fragmentación ocurrirá de manera natural puesto que los archivos que se han actualizado generalmente no se pueden sobrescribir donde están en el disco, y pueden requerir un rearranque para actualizarse, lo cual provoca aún más fragmentación.
Por otro lado, los archivos y datos de usuario (y el Registro de Windows), están sujetos a cambios constantes. La lectura, escritura, edición, copia y eliminación de archivos generan una gran cantidad de fragmentación, especialmente a medida que se llena la capacidad del disco duro.
Para visualizar esto, imagínese un disco perfectamente distribuido, en el que los archivos ocupan espacio de manera contigua, sin espacio entre ellos. Suponga que abre un archivo, lo edita y, a continuación, trata de guardarlo. Si el archivo ha crecido, Windows tiene que guardarlo en su totalidad en otra parte del disco (imagine que tras el archivo N) o bien tiene que guardar los datos más nuevos tras el archivo N. Esto significa que el archivo 2 está ahora fragmentado. Si ahora edita el archivo 1, tendrá dos archivos fragmentados. Si esta operación se repite a lo largo del tiempo, terminará con un sistema considerablemente fragmentado en el cual la unidad de disco tiene que buscar en múltiples ubicaciones para tener acceso a un mismo archivo. Con archivos de bases de datos grandes, archivos de disco duros ampliados para tecnologías informáticas virtuales e ingentes cantidades de vídeo y audio almacenados en un disco de capacidad media, la fragmentación es muy común. Por supuesto, el cada vez mayor tamaño de los discos duros actuales ha reducido en gran medida el problema de la desfragmentación, pero no lo ha hecho desaparecer. Y los portátiles más antiguos con discos duros más pequeños responderán cada vez peor, serán más lentos al arrancar y tardarán más tiempo en abrir y guardar los archivos.
El problema clave no es necesariamente el nivel de fragmentación del sistema, sino el de los archivos individuales. Desde que llegaron al mercado los primeros desfragmentadores de disco con efectos visuales multicolores, los usuarios creyeron que lo más deseable era contar con una barra sólida de color. Sin embargo, de hecho, esto está lejos de ser lo más deseable. Algunos productos tratan de hacer que los discos de los usuarios aparezcan como dos bloques, uno de color (datos del archivo) y otro generalmente blanco (espacio disponible). Desgraciadamente, se trata de una de las peores cosas que puede hacer a un disco si su intención es minimizar la frecuencia y costo de la desfragmentación. Si ha comprimido mucho todos datos de los archivos en la parte frontal del disco y ha eliminado gran parte del espacio disponible al realizar ediciones adicionales en el archivo, todas esas ediciones tendrán que escribirse al final de los datos de los archivos, por lo que al desfragmentar de ese modo, ya ha provocado realmente la fragmentación, empezando con la siguiente edición del archivo. En vez de dos bloques de datos de archivos perfectamente organizados, una buena desfragmentación ofrece como resultado una imagen que no es necesariamente perfecta. Si desea ver un ejemplo, consulte la figura 1 con mi sistema de ejemplo antes de la desfragmentación. A continuación, observe la figura 2 para ver el mismo sistema una vez Windows haya completado la desfragmentación.
Figura 1 Mi unidad de disco antes de la desfragmentación
Figura 1 Mi unidad de disco antes de la desfragmentación
Figura 2 Mi unidad de disco tras la desfragmentación
Figura 2 Mi unidad de disco tras la desfragmentación
Observe como Windows se centra no en la fragmentación de los archivos de todo el disco, sino en la propia fragmentación individual de archivos (consulte la figura 3 para ver la sección del informe de desfragmentación en los Archivos más fragmentados antes de desfragmentar este sistema).
Figura 3 Informe de desfragmentación
Figura 3 Informe de desfragmentación
Como resultado, incluso después de la desfragmentación, Windows no mostrará un conjunto completamente compactado de datos de archivo en la parte frontal del disco. Observe también la sección grande de datos de color verde que hay en las figuras 1 y 2. Esto es el archivo de paginación de Windows, del que hablaré en breve. Si tiene la hibernación habilitada en el sistema Windows, su archivo se mostrará de manera parecida en una desfragmentación.

La desfragmentación habitual es esencial
Al igual que con la limpieza dental, es imprescindible recordar que la desfragmentación debe hacerse regularmente. Desfragmentar con frecuencia resulta aún más importante en sistemas de mucho uso como servidores, ya que si espera demasiado el proceso puede tardar demasiado y el servidor puede quedar no disponible o sin respuesta (ya que la desfragmentación puede tardar bastante tiempo y ciertas fases de la misma pueden requerir también un uso intensivo de la CPU).
Incluso los mejores desfragmentadores en línea no pueden desfragmentar todo. Por ejemplo, no siempre pueden desfragmentar archivos abiertos o bloqueados (como el archivo de paginación o los archivos del registro) y deben evitar el archivo de hibernación si éste existe (que es tan grande como la RAM en uso en el sistema). Para optimizar los archivos bloqueados, consulte la sección siguiente sobre trucos de desfragmentación.
Creo que es importante comprender los mitos y los hechos asociados a la desfragmentación. La figura 4 y la figura 5 enumeran algunos temas comunes que siempre surgen al hablar sobre la desfragmentación y explican las posibilidades reales de que ocurran estos problemas.
Figure 5 Mitos sobre la desfragmentación (Close Figure 5)

Mito | Probabilidad
Los sistemas se bloquearán. | No es probable, los bloqueos se deben generalmente a los problemas del controlador o del hardware (daños en la memoria, problemas de carácter térmico que provocan rearranques o error del disco debido al abuso térmico del disco).
Las aplicaciones se bloquearán. | No es probable, al igual que con un sistema entero, una aplicación adecuadamente diseñada no debe bloquearse debido a la fragmentación, así pues, a menos que se demuestre que ésta es la causa, no debe asumir que es culpa de la fragmentación.
Se generarán daños en el registro. | No es probable (consulte más arriba), la fragmentación no provoca ni conlleva daños para el registro.
La desfragmentación debe generar como resultado una barra sólida en cualquier representación visual del disco. | No es probable, no debe comprimir juntos todos los archivos en el sistema a menos que planee específicamente crear una imagen del sistema con una herramienta de generación de imágenes basada en sectores que no excluya el espacio disponible ni reduzca o divida las particiones. Necesita ubicar los archivos en la parte frontal del disco; de lo contrario, la consolidación radical de archivos sólo resultará en una mayor fragmentación.
Figure 4 Dudas comunes sobre la desfragmentación (Close Figure 4)

Duda | Probabilidad
El rendimiento del sistema se verá afectado. | Alta, dependiendo del uso específico del sistema.
La recuperación de archivos eliminados accidentalmente puede ser difícil o incluso puede que no sea posible. | Alta, la mayoría de las herramientas de recuperación de archivos dependen de la heurística (determinar el tipo de datos) y de la proximidad del clúster de archivo. Los archivos dispersos provocan una operación de recuperación más compleja o irrealizable.
Será difícil desfragmentar el sistema. | Mediana, hay una correlación directa entre la frecuencia con que se usa el sistema y los cambios de los archivos en el sistema con el tiempo. Si los usuarios editan con mucha frecuencia los archivos pero los guardan sólo en recursos compartidos del servidor, por ejemplo, no observará mucha degradación con el tiempo.
Se producirán daños en el disco. | Baja, poco probable. De nuevo, si realiza un uso abusivo del sistema (lo deja encendido con los discos funcionando durante todo el tiempo, editando, modificando o eliminando archivos) es muy probable que esto ocurra. Pero con el hardware actual, esto no debería ocurrir simplemente motivado por la edición de archivos.

La desfragmentación como parte de su infraestructura
Debe considerar seriamente ejecutar un desfragmentador con regularidad en todos sus sistemas. Sus opciones son usar el desfragmentador integrado en Windows o consultar las opciones de terceros. Básicamente, se reduce a la cantidad de ingeniería que desea poner en marcha. Windows XP y versiones posteriores le permiten agregar defrag.exe como Tarea programada, el artículo de Knowledge Base support.microsoft.com/kb/555098 le muestra como hacerlo. Tenga en cuenta que la desfragmentación de un portátil conlleva ciertas consideraciones especiales. Lo deseable es desfragmentar un sistema de usuario cuando está encendido, idealmente mediante alimentación eléctrica, pero por otra parte no es deseable usar ciclos de la CPU o del disco cuando un usuario móvil está intentando llevar a cabo su trabajo. Desgraciadamente, cuando un usuario móvil no está trabajando en su sistema, lo más probable es que se encuentre desconectado de la corriente o bien esté en modo de espera o en hibernación (lo que equivale a estar apagado desde la perspectiva de la administración de energía y las Tareas programadas). En Winternals (como probablemente en todas partes), empleamos bastante tiempo intentando diseñar un escenario ideal para usuario móvil. Si usa Windows Vista, una solución que emplee el desfragmentador integrado y las Tareas programadas, que cuentan con una mejor percepción de la energía que en versiones anteriores, podría ser la adecuada. En caso contrario, puede ser necesaria una solución de terceros para sistemas móviles. Algunos de éstos inician realmente una tarea de desfragmentación, le indican que se ejecutó, cuándo se ejecutó (y con qué frecuencia) y cuánto tiempo duró.
Además de los escenarios móviles, también es deseable pensar en la fragmentación más allá del sistema de archivos. Esto no es algo por lo que generalmente deba estar preocupado en sistemas de escritorio o móviles, sin embargo los servidores Microsoft Exchange, SQL ServerTM u otros almacenes de datos pueden requerir su propia desfragmentación. En esos casos, es necesario decidir si esta operación debe hacerse antes o después de haber llevado a cabo una desfragmentación del sistema de archivos.
Si usa un desfragmentador de terceros, asegúrese de que usa la API de desfragmentación de Windows. Desde Windows NT 4.0, Windows ha tenido su propia API de desfragmentación para evitar pérdidas de datos inesperadas. Por ejemplo, si se encuentra en el proceso de mover un archivo y su sistema se queda sin alimentación, lo último que desea es un movimiento de fragmentación incompleto, que podría tener como resultado la pérdida de datos e incluso impedir que el sistema pueda arrancar.
Finalmente, si usa cualquier tecnología informática virtual, puede que desee considerar cómo administrar también la desfragmentación de los discos virtuales. Son tan propensos a la fragmentación como sus equivalentes físicos y en muchos sentidos puede ser peor debido a sus restricciones de tamaño. Además, si su solución de virtualización le permite reducir discos o particiones, puede que necesite desfragmentar en primer lugar para liberar espacio (o como mínimo, reducir la cantidad de tiempo que una operación de reducción pudiera tardar).

Herramientas adicionales
En este momento, seguramente estará convencido de que la desfragmentación es una función importante y valiosa. Incluso si no usa una herramienta de terceros para la propia desfragmentación, puede que desee considerar una herramienta de Mark Russinovich llamada PageDefrag, que puede obtener del sitio de herramientas de Microsoft Sysinternals (consulte microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx). Tal como mencioné anteriormente, el archivo de paginación de Windows no puede desfragmentarse mientras Windows está en línea. De hecho, los mismo puede aplicarse a los archivos del registro de Windows y a los registros de eventos. PageDefrag le permite desfragmentar estos archivos bloqueados antes de que Windows haya terminado de arrancar y bloquearlos con un pequeño controlador. Para usarlo, ejecute simplemente PageDefrag y configúrelo para que se ejecute en el próximo rearranque o en cada uno de ellos. Cuando el sistema se reinicie (en el punto en el proceso de arranque en el que puede haber observado anteriormente una ejecución de comprobación de disco), se desfragmentarán los archivos especificados en la lista (consulte la figura 6).
Figura 6 Archivos que desfragmentar en PageDefrag
Figura 6 Archivos que desfragmentar en PageDefrag
Una vez que PageDefrag se ha completado, el sistema terminará de arrancar normalmente. Si desea obtener más información sobre PageDefrag, Lance Whitney escribió sobre él en la columna de septiembre de Utility Spotlight (consulte technetmagazine.com/issues/2007/09/UtilitySpotlight). Tenga en cuenta que PageDefrag sólo es compatible con Windows NT 4.0, Windows 2000, Windows XP y Windows Server 2003, actualmente no es compatible con Windows Vista.
Además de PageDefrag, hay otra herramienta disponible de Sysinternals llamada Contig, que le permite desfragmentar un archivo específico manualmente (consulte microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx). Esto puede ser útil si un archivo específico no pudo desfragmentarse mediante una tarea normal de desfragmentación o si ha sido fragmentado desde entonces (pero el resto del volumen no está tan fragmentado).
Contig puede desfragmentar también todo un directorio o subdirectorios mediante caracteres comodín. A continuación se desfragmentarán todos archivos bajo el directorio de Windows, independientemente de dónde estén ubicados.
Contig –s c:\Windows\*.*
Aplicar el conmutador -v hará la operación detallada y -q la hará ejecutarse en silencio.

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: El pez gordo del c&#243;digo de conducta
Notas de campo
El pez gordo del código de conducta
Betsy Aoki

A veces, lo que necesitas no es un servidor más grande, ni una base de usuarios mejor educados que se abstengan de llamar tu atención cuando estás a punto de salir pronto de fin de semana. A veces, el problema no está en administrar el código, sino que lo que necesitas es un pez gordísimo.
Hará cosa de un año, yo estaba trabajando en temas relacionados con el abuso para el sitio Live QnA (qna.live.com). Hacíamos uso de los botones Eliminar y supervisábamos el sitio en cuanto a ataques de idiotez y comportamientos de mal gusto. Disponíamos de herramientas internas. Disponíamos de directivas externas. Nos enfrentábamos a un par de verdaderos chiflados que intentaban sabotear nuestras preguntas con contenido desagradable.
Mientras tanto, yo estaba acabada, me estaba quemando. A fin de cuentas, la salud de la comunidad del sitio me afectaba directamente. Fui yo quien ayudó a elaborar el código de conducta que establecía el tono del sitio. Era la guardiana, y todos parecían morirse por COMPORTARSE bien.
Sólo que no lo hacían. Las personas somos así, capaces de la mayor perfidia y la santidad más desenfrenada, y lo que yo quería no pasaba en realidad por si alguien iba a llamar o no idiota a otro usuario.
Así que un sábado estaba sentada en mi cocina, pensando acerca del código de conducta que estaba defendiendo. Mientras garabateaba con mi pluma, experimenté uno de esos movimientos tipo "paralelismo cerebral" en mi cabeza. ¿Y si no hubiera un código de conducta, sino un pez gordo que marcara la conducta? Y si fuera así, ¿qué aspecto tendría ese pez y cómo actuaría? Todo hay que decirlo, me crié en Nueva Inglaterra donde comíamos un tipo de pez gordo. Un pez gordo blanco, escamoso, aburrido. Quise ser capaz de censurar y engatusar a mis afiliados a QnA con el tono práctico y malintencionado de un pez gordo. No ser sólo el martillo que golpea con el botón Eliminar, que últimamente usaba con demasiada frecuencia, sino alguien con el ingenio mordaz que haría reír tanto que cualquiera prometería no volver a cruzar la línea otra vez. Así es como nació Norbert, el pez gordo del código de conducta. Pensé en darle una pipa, pero consideré que la pajarita era suficiente.
El pez gordo del código de conducta
El pez gordo del código de conducta
Cargué mi dibujo del pez a un LiveID nuevo, le di un nombre de usuario de QnA y Norbert, el pez gordo del código de conducta, estaba listo para empezar. Él no siempre sería yo, que conste. A veces otro miembro del equipo desempeñaría el rol de pez gordo y reprendería a los bellacos. ¿Quién es el pez gordo del código de conducta? Consulte go.microsoft.com/fwlink/?LinkId=99044. ¿El pez gordo del código de conducta hiere los sentimientos de las personas? Consulte go.microsoft.com/fwlink/?LinkId=99045.
Los miembros de la comunidad QnA se adaptaron a él como... bueno... como un pez se adapta al agua. Bromeaban con él, lo citaban, se ponían de mal humor por su culpa. Educaba a los recién llegados, reprendía a la gente que pensábamos que todavía era recuperable y ofrecía una manera desenfadada de contemplar las reglas, más allá de la mera lectura de una página web repleta de jerga legal.
Tanto si se trata de la política de la empresa, de una ley tribal como de la jerarquía del patio de recreo, las reglas siempre dependen de la buena voluntad de la gente que percibe los efectos de su aplicación. Como profesional de TI o desarrollador de sitios web de la comunidad, uno puede crear herramientas que ayuden a la aplicación de las reglas, pero a veces la mejor herramienta para el trabajo resulta ser algo que surge de tu propia personalidad o del sentido de humanidad del colectivo. Una buena limpieza de ingeniería social puede ser más eficaz que mucha ingeniería técnica. Bueno, en nuestro caso, una buena limpieza y un pez gordo.

Betsy Aoki es administradora de programas de comunidad de Microsoft para el equipo de Xbox. Sus apacibles manías se expresan con avidez en sus mensajes de correo electrónico, entradas de blog y, con suerte, en XNA Framework.


 Confidencial de Windows: La paradoja del sistema de archivos
Confidencial de Windows
La paradoja del sistema de archivos
Raymond Chen

Si echa un vistazo en su disco duro, probablemente advertirá que un considerable número de archivos del sistema operativo frecuentan el directorio raíz de la unidad de arranque. Si examina más atentamente esos archivos, es posible que perciba una cosa: boot.ini, NTLDR y NTDETECT.COM son archivos de arranque críticos, e hiberfil.sys es el archivo de hibernación. Todos son archivos implicados en las primeras etapas cruciales de arranque del sistema operativo o, en el caso de hiberfil.sys, de reanudación desde la hibernación, y deben estar en la raíz de la unidad de arranque. ¿Por qué no los puede mover a cualquier otra parte?
Mi colega Adrian Oney explicaba: para leer los archivos de arranque del disco, se necesita el controlador del sistema de archivos pero el controlador del sistema de archivos está en el disco, que no se puede leer hasta que no haber cargado el controlador del sistema de archivos. ¡Ah no, una situación sin salida!
El círculo vicioso se interrumpe si hay un controlador en miniatura del sistema de archivos integrado en los archivos de arranque críticos. Este controlador en miniatura sabe justo lo suficiente para localizar los archivos en el directorio raíz y cargarlos en memoria. A su vez, esos archivos pueden encaminar el sistema operativo para que, a continuación, el verdadero controlador del sistema de archivos se haga cargo y busque los archivos en lugares mucho más elaborados, como los subdirectorios.
La hibernación sigue una pauta parecida. Hibernar el sistema operativo significa volcar todo el contenido de la memoria en el archivo de hibernación; restaurarlo desde la hibernación trae consigo volver a "absorber" ese archivo en la memoria y fingir que nada ha sucedido. Y aquí estamos de nuevo con otro problema del huevo y la gallina: para cargar el archivo de hibernación, se necesita el controlador del sistema de archivos, pero el controlador del sistema de archivos está en el archivo de hibernación. Si se guarda el archivo de hibernación en el directorio raíz de la unidad de arranque, puede usar en su lugar el controlador en miniatura del sistema de archivos.
Los que habían usado las primeras versiones de MS-DOS® son plenamente conscientes de esta restricción de la ubicación de los archivos de arranque del sistema operativo. El antiguo comando SYS convertía un disquete viejo y aburrido en un disquete de arranque mágico. Sin embargo, si se ejecutaba en un disquete que ya contenía datos, había muchas posibilidades de que la conversión produjera un error porque las primeras versiones de MS-DOS requerían que los archivos de arranque ocuparan determinadas ubicaciones en el disquete para que el sector de arranque los encontrara. Las versiones posteriores de MS-DOS redujeron estos requisitos gracias mejoras en el cargador de arranque pero, incluso con la versión mejorada, los archivos del sistema deben continuar ubicados en el directorio raíz.
Un cliente preguntó: "¿puedo mover el archivo de hibernación a un subdirectorio?" A fin de cuentas, ¿por qué importa dónde esté el archivo? Las ACL del archivo serán las mismas indistintamente de su ubicación. Quería colocarlo en una unidad distinta de la unidad de arranque y se le había dicho que eso no era posible. Realmente no entendía la razón de esta restricción, así que intentó una última cosa: bueno, pues si al menos lo puedo mover a un subdirectorio, puedo crear un directorio y convertirlo en unión que señale hacia donde realmente quiero tener el archivo de hibernación. Bien, ¡he reubicado el archivo de hibernación!
Por supuesto, el controlador en miniatura del sistema de archivos no entiende de puntos de montaje, porque los puntos de montaje significan "hablar" con el servicio de administración del disco. Y, en el momento en que se arranca el sistema, el equipo ni tan siquiera ha cargado todavía el sistema operativo ni mucho menos algún elaborado servicio avanzado que sabe cómo volver a asignar letras de unidad a las rutas de acceso ARC; incluso si de algún modo se lograra ejecutar ese servicio, aún habría que encontrar los controladores de dispositivo para esos otros discos duros y cargar los correspondientes controladores del sistema de archivos.
Sólo es cuestión de tiempo y alguien pedirá una manera de colocar el archivo de hibernación en una unión DFS.

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. Su nombre Web 2.0 es Raymond o quizás Chester.