Agosto 2008 Agosto 2008
SQL Server: Buenos consejos para el mantenimiento eficaz de bases de datos
Ocurre demasiado a menudo que personas no entrenadas para administrar bases de datos acaban, no se sabe cómo, siendo responsables de una base de datos. Estas personas carecen de los estudios y conocimientos adecuados para mantener bases de datos, y así es como los problemas comienzan a surgir. Esta es una guía para todos aquellos administradores involuntarios que necesiten un curso intensivo en prácticas recomendadas para el mantenimiento de bases de datos. Paul S. Randal
Administración de Windows: Cómo tomarle el pulso a un servidor
Sus usuarios se quejan de que un servidor no funciona como debería. ¿Sabe dónde acudir para diagnosticar el problema? PerfMon resulta una herramienta indispensable para este fin, ya que dispone de numerosas capacidades de diagnóstico. Obtenga una descripción general de los indicadores clave que deberá emplear para diagnosticar una serie de cuellos de botella habituales que pueden acabar ralentizando los servidores. Steven Choy
System Center: Windows PowerShell en System Center Operations Manager
Windows PowerShell se ha integrado en System Center Operations Manager 2007 y representa una forma eficaz de realizar y automatizar tareas administrativas habituales. Obtenga una visión general acerca de cómo puede usar Windows PowerShell en OpsMgr para realizar el mantenimiento rutinario, administrar agentes y mucho más. Marco Shaw
Internet Information Services: Escale sus aplicaciones ASP.NET: Lecciones aprendidas
La clave para escalar correctamente una aplicación ASP.NET es que haya un esfuerzo colaborativo entre los desarrolladores y los administradores de red desde el inicio del ciclo de vida de la aplicación. Averigüe los factores que son necesarios para escalar una aplicación y vea si esta colaboración puede ayudar a garantizar que la aplicación se ejecute del modo previsto. Richard Campbell
Columns
Nota del editor: En vivo desde Tech.Ed: | Cartas: Comentarios de los lectores: | Cuadro de herramientas: Nuevos productos para profesionales de TI:
Preguntas y respuestas sobre SQL: Particiones y comprobaciones de coherencia, entre otros temas: Paul Randal aclara sus dudas sobre SQL Server, mostrando cómo realizar comprobaciones de coherencia y otras operaciones de mantenimiento en bases de datos muy grandes, cómo controlar una actualización accidental, entre otras cuestiones.Paul S. Randal | Utility Spotlight: Utilidad Windows Installer CleanUp: La información de configuración de Windows Installer residual puede provocar problemas al intentar actualizar o desinstalar una aplicación. Puede solucionar el problema con la utilidad Windows Installer CleanUp, que le permite quitar la información de Windows Installer de una aplicación y reinstalar a continuación la aplicación.Lance Whitney | Dentro de SharePoint: Solución de problemas de integración de mensajería: La integración de SharePoint en un entorno de mensajería seguro no es una tarea sencilla, pero el impacto positivo en la productividad hará que valga la pena todo el esfuerzo destinado al proyecto. Aquí se ofrecen instrucciones acerca de cómo solucionar problemas que pueden surgir al configurar el entorno.Pav Cherny
Windows PowerShell: Un adelanto de la administración remota en la versión 2.0: Windows PowerShell 2.0 está en preparación y la última versión de CTP ofrece nuevas capacidades que son fantásticas. Aquí tiene información sobre comunicación remota, una de las nuevas características más espectaculares que encontrará en la versión CTP2 de Windows PowerShell 2.0.Don Jones | Hey, Scripting Guy!: Tomando la directa: Con Windows Vista, ya no existe el control de ActiveX UserAccounts.CommonDialog para abrir un cuadro de diálogo de abrir archivos. Aquí puede averiguar cómo resolver ese problema con Visual Basic Express Edition.Los Scripting Guys de Microsoft | Archivos del escritorio: Información general sobre Servicios de implementación de Windows: Explore las diferentes versiones de Servicios de implementación de Windows, vea cómo puede capturar una imagen personalizada del sistema operativo y averigüe lo que necesita para realizar instalaciones más automatizadas.Wes Miller
Vigilancia de seguridad: Contraseñas y tarjetas de crédito, 2ª parte: En la segunda parte de esta serie de tres entregas, Jesper Johansson describe cómo los proveedores de software, los paquetes de seguridad y las estrategias de marketing dificultan los verdaderos esfuerzos de seguridad y nos advierte acerca de cómo estas prácticas pueden llevar a la destrucción del ecosistema de la seguridad en tecnología.Jesper M. Johansson | Informática sostenible: Cómo filtrar el "greenwashing": Comprender cómo funciona el consumo de energía resulta fundamental hoy en día para administrar una infraestructura de TI. Obtenga más información acerca de las estrategias que puede emplear para implementar la supervisión de energía en su entorno y comprender más a fondo el consumo de energía de los dispositivos en su organización.Dave Ohara | Notas de campo: IMAP salva el mundo: ¿Tiene correo electrónico guardado en muchos lugares distintos, en formatos distintos y en distintos sistemas operativos? Dara Korra'ti explica cómo puede tener acceso a todo su correo desde un mismo lugar con IMAP4.R'ykandar Korra'ti
Confidencial de Windows: Basarse en el pasado: Raymond explica cómo el sistema Alpha AXP, que en el pasado fue un sistema muy potente, salió de su retiro para ayudar a desarrollar una nueva generación de sistemas de 64 bits.Raymond Chen


SQL Server
Buenos consejos para el mantenimiento eficaz de bases de datos
Paul S. Randal
De un vistazo:
  • Administración de datos y archivos de registro de transacciones
  • Eliminación de la fragmentación de índices
  • Cómo garantizar estadísticas exactas y actualizadas
  • Detección de páginas dañadas en la base de datos
  • Establecimiento de una estrategia eficaz de copias de seguridad

Contenido
Administración de archivos de datos y archivos de registro
Fragmentación de índices
Estadísticas
Detección de daños
Copias de seguridad
Conclusión
Varias veces por semana me piden consejo sobre cómo mantener de forma efectiva bases de datos de producción. A veces estas preguntas provienen de administradores de bases de datos que están implementando nuevas soluciones y necesitan ayuda
para optimizar las prácticas de mantenimiento y así adaptarse a las características nuevas de sus bases de datos. Con mayor frecuencia, sin embargo, las preguntas me llegan de personas que no son administradores profesionales de bases de datos y a quienes, por alguna razón, les han asignado la propiedad y la responsabilidad de una base de datos. A estas personas me gusta llamarlas "administradores de bases de datos involuntarios". El objetivo de este artículo es proporcionar una guía de buenas prácticas para el mantenimiento de bases de datos dirigida a todos los administradores de bases de datos involuntarios que hay por el mundo.
Al igual que con la mayoría de tareas y procedimientos en el mundo de las tecnologías de la información, no hay una solución universal y fácil para el mantenimiento eficaz de bases de datos, aunque sí hay una serie de áreas clave que casi siempre necesitan abordarse. Mis cinco áreas principales de interés (no por orden de importancia) son:
  • Administración de archivos de datos y archivos de registro
  • Fragmentación de índices
  • Estadísticas
  • Detección de daños
  • Copias de seguridad
Una base de datos sin mantenimiento (o mal mantenida) puede desarrollar problemas en una o más de estas áreas, lo cual a largo plazo puede provocar un mal rendimiento de la aplicación o incluso tiempos de inactividad y pérdida de datos.
En este artículo explicaré la razón por la que estos problemas son importantes y mostraré unos métodos sencillos para mitigar los problemas. Basaré mis explicaciones en SQL Server® 2005 y resaltaré asimismo las principales diferencias que encontraremos en SQL Server 2000 y la siguiente versión de SQL Server 2008.

Administración de archivos de datos y archivos de registro
La primera área que siempre recomiendo comprobar a la hora de hacerse cargo de una base de datos es la configuración de la administración de archivos de datos y archivos de registro (de transacciones). Concretamente, debe comprobar lo siguiente:
  • Que los archivos de datos y archivos de registro están separados entre sí además de aislados de todo lo demás.
  • Que el crecimiento automático está configurado correctamente.
  • Que la inicialización instantánea de archivos está configurada.
  • Que la autorreducción no está habilitada y la reducción no forma parte de ningún plan de mantenimiento.
Cuando los archivos de datos y de registro (que lo ideal sería que estuvieran en volúmenes completamente separados) comparten el mismo volumen/tamaño que cualquier otra aplicación que crea o amplía archivos, existirá la posibilidad de que los archivos se fragmenten. En los archivos de datos, la excesiva fragmentación de archivos puede ser un factor que contribuya en cierta medida a realizar mal las consultas (especialmente aquellas que recorren grandes cantidades de datos). En los archivos de registro, la fragmentación puede tener mucho mayor efecto en el rendimiento, especialmente si la función de crecimiento automático está activada para aumentar el tamaño de los archivos con una cantidad muy pequeña cada vez que es necesario.
Los archivos de registro se dividen internamente en secciones llamadas archivos de registro virtuales (VLF). Cuanto mayor sea la fragmentación del archivo de registro (empleo el singular aquí porque no supone ninguna ventaja tener múltiples archivos de registro, debería haber solamente uno por cada base de datos), mayor número de archivos VLF habrá. Cuando un archivo de registro tiene más de, pongamos, 200 archivos de registro virtuales, el rendimiento se puede ver afectado de forma negativa cuando efectúa operaciones relacionadas con el registro, tales como la lectura de registros (para las réplicas o reversiones transaccionales, por ejemplo), las copias de seguridad de registros e incluso los desencadenadores en SQL Server 2000 (la implementación de desencadenadores se ha cambiado en SQL Server 2005 al marco del control de versiones de filas en lugar del registro de transacciones).
El procedimiento recomendado con respecto al tamaño de los archivos de datos y de registro es crearlos con un tamaño inicial adecuado. En el tamaño inicial de los archivos de datos se debe tener en cuenta que existe la posibilidad de que a corto plazo se agreguen datos adicionales a la base de datos. Por ejemplo, si el tamaño inicial de los datos es 50 GB, pero se sabe que en los seis meses siguientes se agregarán otros 50 GB de datos, tiene más sentido crear directamente un archivo de datos de 100 GB que tener que aumentarlo varias veces para alcanzar ese tamaño.
Por desgracia, esto se complica un poco más para los archivos de registro y tendrá que considerar factores como el tamaño de las transacciones (las transacciones de larga ejecución no pueden eliminarse del registro hasta que se hayan completado) y la frecuencia de copias de seguridad del registro (ya que esto es lo que elimina la parte inactiva del registro). Para más información, consulte el mensaje "8 Steps to Better Transaction Log Throughput" escrito por mi esposa, Kimberly Tipp, en el blog SQLskills.COM.
Una vez definidos, los tamaños de archivo deben controlarse a varias horas del día y aumentarse manualmente de forma proactiva en un momento adecuado del día. La opción de crecimiento automático debe dejarse activada como medida preventiva para así permitir que los archivos puedan crecer si ocurrieran eventos anómalos. La lógica en contra de dejar la administración de archivos enteramente en manos del crecimiento automático es que el crecimiento automático de pequeñas cantidades provoca la fragmentación de archivos y puede convertirse en un proceso largo y lento que atasque la carga de trabajo de la aplicación en tiempos imprevisibles.
El tamaño del crecimiento automático debe establecerse en un valor específico en lugar de en un porcentaje, para de este modo enlazar el tiempo y el espacio necesario para llevar a cabo el crecimiento automático, si fuera necesario. Imaginemos, por ejemplo, que quiere definir un archivo de datos de 100 GB para que tenga un tamaño fijo de crecimiento automático de 5 GB en lugar de, digamos, el 10 por ciento. Esto significa que siempre crecerá 5 GB independientemente de lo grande que acabe siendo el archivo, en vez de incrementar siempre una cantidad determinada (10 GB, 11 GB, 12 GB, etc.) cada vez que el archivo aumente de tamaño.
Cada vez que se aumente un registro de transacciones (ya sea manualmente o a través de crecimiento automático) éste se inicializará a cero. Los archivos de datos tienen el mismo comportamiento predeterminado en SQL Server 2000, pero si empieza con SQL Server 2005 puede habilitar la inicialización instantánea de archivos, con lo que se omite la inicialización a cero de los archivos y se consigue, por tanto, que el crecimiento y el crecimiento automático sean prácticamente instantáneos. Al contrario de lo que muchos creen, esta característica está disponible en todas las ediciones de SQL Server. Para más información, introduzca "inicialización instantánea de archivos" en el índice de los Libros en pantalla de SQL Server 2005 o SQL Server 2008.
Por último, debe tener cuidado de que la función de reducción no esté habilitada en ningún caso. Esta función puede usarse para reducir el tamaño de un archivo de datos o de registro, si bien es un proceso muy intrusivo que consume muchos recursos y que causa grandes cantidades de fragmentación de exploración lógica en archivos de datos (para obtener más detalles, consulte más abajo) y conlleva un bajo rendimiento. He cambiado la entrada en los Libros en pantalla de SQL Server 2005 por reducir para añadir una advertencia al respecto. No obstante, la reducción manual de archivos de datos y de registro individuales puede ser aceptable en circunstancias especiales.
Vídeo
Vea el vídeo de Paul Randal donde demuestra el modo en que las funciones de reducir y reducir automáticamente pueden causar graves problemas de fragmentación en las bases de datos.

La reducción automática es el peor atacante ya que se inicia cada 30 minutos en segundo plano y trata de reducir las bases de datos que tienen la opción de reducción automática activada. Es un proceso algo impredecible en el que sólo se reducen las bases de datos con más del 25 por ciento de espacio libre. La reducción automática usa muchos recursos y provoca una fragmentación que disminuye el rendimiento, por eso no es una buena estrategia en ningún caso. Debe desactivar siempre la reducción automática con el siguiente código:
ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;
Tener un plan periódico de mantenimiento que contemple un comando manual de reducción de la base de datos es una idea casi igual de mala. Si cree que su base de datos crece continuamente después de que el plan de mantenimiento la haya reducido, eso se debe a que la base de datos necesita ese espacio para ejecutarse.
Lo mejor que puede hacer es permitir que la base de datos crezca hasta alcanzar un tamaño estable y evitar ejecutar la reducción. Puede encontrar más información sobre las desventajas de utilizar la reducción además de comentarios acerca de los nuevos algoritmos de SQL Server 2005 en mi antiguo blog de MSDN® en blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx.

Fragmentación de índices
Aparte de la fragmentación a nivel de sistema de archivos y dentro del archivo de registro, también es posible hacer fragmentaciones dentro de los archivos de datos, en las estructuras que almacenan los datos de tabla e índice. Hay dos tipos básicos de fragmentación que puede ocurrir dentro de un archivo de datos:
  • Fragmentación dentro de páginas individuales de datos e índices (a veces denominada fragmentación interna)
  • Fragmentación dentro de las estructuras de índice o tabla formadas por páginas (denominada fragmentación de exploración lógica y fragmentación de exploración de extensión)
La fragmentación interna es aquella en la que hay mucho espacio vacío en una página. Como se muestra en la figura 1 , cada página de una base de datos tiene un tamaño de 8 KB y un encabezado de 96 bytes; por tanto, una página puede almacenar unos 8.096 bytes de datos de tabla o índice (hallará información interna específica de tablas e índices para estructuras de datos y de filas en la categoría "Inside the Storage Engine" de mi blog, sqlskills.com/blogs/Paul). Puede llegar a generarse espacio en blanco si cada registro de tabla o de índice ocupa más de la mitad del tamaño de una página, ya que sólo se puede almacenar un registro por página. Esto puede ser muy difícil o imposible de corregir dado que requeriría cambios en el esquema de la tabla o del índice, por ejemplo cambiar una clave de índice para que no cause la inserción aleatoria de puntos como hace un GUID.
Figura 1 Estructura de la página de una base de datos (haga clic en la imagen para ampliarla)
Con mayor frecuencia, la fragmentación interna es el resultado de la modificación de datos, como inserciones, actualizaciones y eliminaciones, operaciones estas que pueden dejar espacios en blanco en una página. La mala administración del factor de relleno también puede llegar a contribuir a la fragmentación; consulte los Libros en pantalla para obtener más información al respecto. Dependiendo del esquema de tabla/índice y las características de la aplicación, es posible que este espacio en blanco, una vez creado, nunca se pueda volver a usar y además puede provocar el crecimiento incesante de cantidades de espacio no utilizado en la base de datos.
Imagínese, por ejemplo, una tabla de 100 millones de filas con un tamaño medio de registro de 400 bytes. Con el tiempo, el modelo de modificación de datos de la aplicación deja en cada página un promedio de 2.800 bytes de espacio libre. El espacio total necesario para la tabla ronda los 59 GB, calculado teniendo en cuenta que 8.096-2.800/400 = 13 registros por 8 KB por página, y después dividiendo 100 millones entre 13 para de esta forma obtener el número de páginas. Si no se ha malgastado el espacio, deberían caber 20 registros por página, reduciendo así el espacio total necesario a 38 GB. ¡Esto supone un ahorro enorme!
Por tanto, el espacio malgastado en páginas de datos o de índices provoca que se necesiten más páginas para albergar la misma cantidad de datos. Esto no sólo ocupa más espacio en el disco, sino que además significa que las consultas tienen que emitir más E/S para leer la misma cantidad de datos. Y todas estas páginas adicionales ocupan más espacio en la memoria caché de datos, consumiendo así más memoria del servidor.
La fragmentación de exploración lógica es causada por una operación denominada división de página. Esto ocurre cuando se quiere insertar un registro en una página específica del índice (con arreglo a la definición de la clave de índice) y no hay suficiente espacio en la página para albergar los datos que se desean insertar. Se divide la página por la mitad y se mueve aproximadamente el 50 por ciento de los registros a una página nueva. Generalmente, esta página nueva no es físicamente contigua a la página previa, por eso se dice que está fragmentada. La fragmentación de exploración de extensión tiene un concepto similar. La fragmentación dentro de estructuras de tabla/índice afecta a la capacidad de SQL Server para hacer exploraciones eficaces, ya sea de una tabla/un índice enteros o limitados por una cláusula WHERE (como SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000).
La figura 2 muestra las páginas de índice recién creadas con un factor de relleno del 100 por ciento y ninguna fragmentación (las páginas están llenas y el orden físico de las páginas coincide con el orden lógico). La figura 3 muestra la fragmentación que se puede producir tras inserciones/actualizaciones/eliminaciones aleatorias.
Figura 2 Páginas de índice recién creadas sin fragmentación; páginas llenas al 100% (haga clic en la imagen para ampliarla)
Figura 3 Páginas de índice con fragmentación interna y fragmentación de exploración lógica tras inserciones, actualizaciones y eliminaciones aleatorias (haga clic en la imagen para ampliarla)
A veces se pueden prevenir fragmentaciones cambiando el esquema de tabla/índice pero, como mencioné anteriormente, puede resultar una tarea muy difícil o imposible. Si la prevención no es una opción, existen otras maneras de eliminar la fragmentación una vez que se ha producido; en particular, mediante la regeneración o reorganización de un índice.
Regenerar un índice implica crear una nueva copia del índice, bien compactado y tan contiguo como sea posible, y después eliminar el antiguo índice fragmentado. Puesto que SQL Server crea una copia nueva del índice antes de eliminar la antigua, se necesitará tanto espacio libre en los archivos de datos como el aproximadamente equivalente al tamaño del índice. En SQL Server 2000, la regeneración de un índice siempre era una operación sin conexión. En SQL Server 2005 Enterprise Edition, sin embargo, la regeneración de índices puede realizarse en línea, con unas pocas restricciones. La reorganización, por otro lado, usa un algoritmo local para compactar y desfragmentar el índice; requiere solamente 8 KB de espacio adicional para ejecutarse y siempre se ejecuta en línea. De hecho, en SQL Server 2000 escribí específicamente el código de reorganización del índice como una alternativa en línea y eficiente en espacio para regenerar índices.
En SQL Server 2005, los comandos para investigar son ALTER INDEX … REBUILD, para regenerar índices, y ALTER INDEX … REORGANIZE, para reorganizarlos. Esta sintaxis reemplaza los comandos de SQL Server 2000 DBCC DBREINDEX y DBCC INDEXDEFRAG, respectivamente.
Hay muchas similitudes entre estos métodos, como la cantidad de registros de transacciones generados, la cantidad de espacio libre necesario en la base de datos y si el proceso es interrumpible sin causar pérdidas de trabajo. Encontrará un artículo técnico que aborda estas similitudes, entre otras cosas, en microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx. Aunque este documento se basa en SQL Server 2000, los conceptos se aplican igualmente a versiones posteriores.
Algunas personas sencillamente prefieren volver a generar o reorganizar los índices cada noche o cada semana (usando una opción de plan de mantenimiento, por ejemplo) en lugar de averiguar qué índices están fragmentados y si se sacará algún beneficio de eliminar la fragmentación. Aunque esta puede ser una buena solución para un administrador de bases de datos involuntario que desea poner algo en su sitio con el mínimo esfuerzo, tenga en cuenta que puede ser una mala elección para bases de datos o sistemas más grandes, donde escasean los recursos.
Un enfoque más sofisticado implica usar la DMV (vista de administración dinámica) sys.dm_db_index_physical_stats (o DBCC SHOWCONTIG en SQL Server 2000) para determinar periódicamente qué índices se fragmentan y después decidir si y cómo operar en ellos. El artículo técnico también analiza el uso de estas elecciones más sistemáticas. Asimismo puede consultar código de ejemplo para hacer este filtrado en el ejemplo D de la entrada de los Libros en pantalla para la DMV sys.dm_db_index_physical_stats en SQL Server 2005 (msdn.microsoft.com/library/ms188917) o el ejemplo E de la entrada de los Libros en pantalla para el comando DBCC SHOWCONTIG en SQL Server 2000 y versiones posteriores (en msdn.microsoft.com/library/aa258803).
Sea cual sea el método que utilice, es altamente recomendable investigar y corregir la fragmentación con regularidad.
El procesador de consultas es la parte de SQL Server que decide cómo se debe ejecutar una consulta, concretamente qué tablas e índices se usarán y qué operaciones se llevarán a cabo para obtener resultados; lo que se conoce como plan de consulta. Algunas de las entradas más importantes en este proceso de toma de decisiones son las estadísticas, que describen la distribución de valores de datos entre columnas dentro de una tabla o un índice. Obviamente, las estadísticas deben ser exactas y recientes para que le resulten útiles al procesador de consultas, si no se provocará un mal rendimiento del plan de consulta.
Las estadísticas se generan leyendo los datos de las tablas o índices y determinando la distribución de datos entre las columnas pertinentes. Las estadísticas se pueden crear recorriendo todos los valores de datos de una columna en concreto (recorrido completo), aunque también se pueden basar en un porcentaje de datos definido por el usuario (recorrido de muestra). Si la distribución de valores en una columna está bien compensada, entonces bastará con un recorrido de muestra, lo que resultará más rápido que crear y actualizar las estadísticas con un recorrido completo.
Tenga en cuenta que es posible crear y mantener estadísticas automáticamente estableciendo las opciones de base de datos AUTO_CREATE_STATISTICS y AUTO_UPDATE_STATISTICS en ON, como se muestra en la figura 4. Estas opciones están activadas de forma predeterminada, pero si acaba de heredar una base de datos se recomienda comprobarlo para asegurarse. Cuando las estadísticas se quedan desfasadas es posible actualizarlas manualmente con la instrucción UPDATE STATISTICS en conjuntos específicos de estadísticas. También se puede usar el procedimiento almacenado sp_updatestats, que actualiza todas las estadísticas desfasadas (en SQL Server 2000, sp_updatestats actualiza todas las estadísticas, independientemente de su antigüedad).
Figura 4 Cambios en la configuración de la base de datos a través de SQL Server Management Studio (haga clic en la imagen para ampliarla)
Si desea actualizar las estadísticas en el marco de su plan periódico de mantenimiento, hay un truco que debería considerar. Tanto UPDATE STATISTICS como sp_updatestats se vuelven de manera predeterminada al nivel de muestreo anteriormente especificado (si existe), que puede ser menos que un recorrido completo. El índice regenera automáticamente estadísticas de actualización con un recorrido completo. Si actualiza estadísticas manualmente tras una regeneración de índice, es posible que acabe con estadísticas menos precisas. Esto puede ocurrir si el recorrido de muestra de la actualización manual sobrescribe el recorrido completo provocado por la regeneración de índice. Por otro lado, al reorganizar índices no se actualizan las estadísticas.
Repito, hay muchas personas que tienen un plan de mantenimiento que actualiza todas las estadísticas en algún momento antes o después de regenerar todos los índices (y sin saberlo acaban teniendo unas estadísticas probablemente menos precisas). Si sencillamente opta por regenerar todos los índices cada cierto tiempo, de esta forma también se ocupará de las estadísticas. Si decide tomar una vía más compleja con eliminación de fragmentación, también debe hacerlo para el mantenimiento de las estadísticas. Sugiero que haga lo siguiente:
  • Analice los índices y determine cómo y en cuáles va a aplicar la eliminación de fragmentación.
  • Actualice las estadísticas de todos los índices no regenerados.
  • Actualice las estadísticas de todas las columnas no indizadas.
Para obtener más información sobre estadísticas, consulte el artículo técnico "Estadísticas usadas por el optimizador de consultas en Microsoft® SQL Server 2005" (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx).

Detección de daños
Hasta el momento he hablado del mantenimiento relacionado con el rendimiento. Ahora voy a cambiar de tercio y tratar la detección y mitigación de daños.
Es muy improbable que la base de datos que está administrando contenga información completamente inútil que no le interese a nadie, entonces ¿cómo puede hacer para asegurarse de que no se dañen los datos y que éstos se puedan recuperar en caso de desastre? Los detalles acerca de cómo crear una estrategia de recuperación en caso de desastre y de alta disponibilidad quedan fuera del ámbito de este artículo, si bien hay unas cuantas cosas que puede ir haciendo para empezar.
La gran mayoría de los daños son causados por el "hardware". ¿Por qué lo escribo entre comillas? Bueno, en realidad el hardware se emplea aquí como forma abreviada para "algo en el subsistema de E/S dentro de SQL Server". El subsistema de E/S está formado por elementos tales como el sistema operativo, los controladores del sistema de archivos, los controladores de dispositivos, los controladores RAID, los cables, las redes y las propias unidades de disco reales. Son muchos sitios donde pueden (y suelen) surgir problemas.
Uno de los problemas más comunes se produce cuando falla el suministro eléctrico y una unidad de disco está en pleno proceso de escritura de una página en la base de datos. Si la unidad de disco no consigue completar el proceso de escritura antes de quedarse sin electricidad (o las operaciones de escritura se copian en caché y no hay suficiente batería de reserva para vaciar la memoria caché de la unidad), el resultado podría ser una imagen de página incompleta en el disco. Esto puede suceder porque una página de base de datos de 8 KB está compuesta por 16 sectores contiguos de disco de 512 bytes. Una escritura incompleta podría escribir algunos de los sectores de la página nueva pero dejar algunos de los sectores de la imagen de la página anterior sin escribir. Esta situación se conoce como página rasgada. ¿Cómo se detecta esto cuando sucede?
SQL Server tiene un mecanismo para detectar esta situación. Consiste en almacenar un par de bits de cada sector de la página y escribir un patrón específico en su lugar (esto sucede poco antes de que se escriba la página en el disco). Si el patrón no es el mismo cuando la página se vuelve a leer, SQL Server sabrá que la página se ha "rasgado" y generará un error.
En SQL Server 2005 y versiones posteriores se incluye un mecanismo más completo llamado sumas de comprobación de página que puede detectar cualquier daño en una página. Consiste en escribir una suma de comprobación de una página completa en la página justo antes de de escribirla en el disco y después probarla cuando la página se vuelva a leer, igual que para detectar páginas rasgadas. Tras habilitar las sumas de comprobación de página, habrá que leer una página en el grupo de búferes, cambiarla de alguna manera y luego escribirla al disco otra vez antes de que una suma de comprobación de página la proteja.
Por tanto, se recomienda tener las sumas de comprobación de página activadas para SQL Server 2005 en adelante, con la detección de páginas rasgadas habilitada para SQL Server 2000. Para habilitar sumas de comprobación de página puede usar:﻿
ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;
Para habilitar la detección de páginas rasgadas en SQL Server 2000 puede usar:
ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;
Con estos mecanismos puede detectar que una página contiene errores, pero solamente al leerla. ¿Cómo forzar fácilmente que se lean todas las páginas asignadas? El mejor método para hacer esto (y para encontrar cualquier otra clase de error) es usar el comando DBCC CHECKDB. A pesar de las opciones especificadas, este comando siempre leerá todas las páginas de la base de datos, causando por tanto que se verifiquen todas las sumas de comprobación de página o detecciones de páginas rasgadas. También debe activar alertas para saber en qué momento los usuarios se encuentran con errores durante la ejecución de consultas. Puede recibir notificaciones de todos los problemas descritos arriba usando una alerta para errores de gravedad 24 (figura 5).
Figura 5 Configuración de una alerta para los errores de gravedad 24 (haga clic en la imagen para ampliarla)
También es una buena costumbre ejecutar regularmente DBCC CHECKDB en las bases de datos con el objetivo de comprobar su integridad. Hay muchas variantes de este comando y tantas otras preguntas acerca de la frecuencia con que debe ejecutarse. Por desgracia, no hay artículos técnicos que traten este tema. Sin embargo, como DBCC CHECKDB es la parte principal de código que escribí para SQL Server 2005, he tratado este asunto extensamente en mi blog. Consulte la categoría "CHECKDB From Every Angle" de mi blog (sqlskills.com/blogs/paul), donde encontrará numerosos artículos sobre comprobaciones de coherencia, prácticas recomendadas y consejos prácticos. Para administradores de bases de datos involuntarios, la regla general es ejecutar un DBCC CHECKDB tan a menudo como se hagan copias de seguridad completas de la base de datos (más adelante hallará más información al respecto). Recomiendo ejecutar el siguiente comando:
DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS,
  ALL_ERRORMSGS;
Si este comando da resultados, DBCC habrá hallado daños en la base de datos. La pregunta siguiente será qué hacer si DBCC CHECKDB encuentra errores. Aquí es donde entran en juego las copias de seguridad.
Cuando ocurre un daño u otro desastre, la manera más efectiva de recuperar datos es restaurando la base de datos a partir de copias de seguridad. Ahora bien, con esto se da por supuesto que hay copias de seguridad y que éstas no están dañadas. Pasa con demasiada frecuencia que las personas que desean saber cómo conseguir que una base de datos dañada vuelva a funcionar no disponen de copias de seguridad. La respuesta fácil es que, sencillamente, no puede, no sin experimentar algún tipo de pérdida de datos que podría hacer estragos en su lógica empresarial e integridad de sus datos relacionales.
Así que aquí tenemos un ejemplo muy claro de por qué realizar copias de seguridad con regularidad. Si bien es cierto que las implicaciones de usar copias de seguridad y restaurar quedan fuera del ámbito de este artículo, me permiten ofrecerle una ayuda rápida sobre cómo establecer una estrategia de copias de seguridad.
En primer lugar debe efectuar con regularidad copias de seguridad completas de la base de datos. De este modo creará una única versión puntual de lo que podrá restaurar más adelante. Para realizar un copia de seguridad completa de la base de datos use el comando BACKUP DATABASE. Consulte ejemplos en los Libros en pantalla. Para mayor protección, puede usar la opción WITH CHECKSUM, que comprueba las sumas de comprobación de página (si existen) de las páginas que se están leyendo y calcula una suma de comprobación de toda la copia de seguridad. Debe seleccionar una frecuencia que refleje cuántos datos o trabajo podría estar dispuesto a perder su negocio. Por ejemplo, realizar una copia de seguridad completa de la base de datos una vez al día significa que se podría perder hasta el valor de los datos de un día en caso de desastre. Si sólo usa copias de seguridad completas de la base de datos, debería estar en el modelo de recuperación SIMPLE (denominado comúnmente modo de recuperación) para así evitar complicaciones relacionadas con la administración del crecimiento del registro de transacciones.
En segundo lugar, conserve siempre las copias de seguridad durante unos cuantos días para el caso de que alguna de ellas estuviera dañada (una copia de seguridad de hace unos días siempre es mejor que ninguna copia de seguridad). También debe comprobar la integridad de sus copias de seguridad, para ello use el comando RESTORE WITH VERIFYONLY (una vez más, consulte los Libros en pantalla). Si utilizó la opción WITH CHECKSUM cuando se creó la copia de seguridad, ejecutar el comando de verificación comprobará que la suma de comprobación de la copia de seguridad todavía es válida y revisará todas las sumas de comprobación de las páginas contenidas en la copia de seguridad.
En tercer lugar, si realizar cada día una copia de seguridad completa de la base de datos no es suficiente para cumplir con la pérdida máxima de datos/trabajo que admite su negocio, se recomienda investigar las copias de seguridad diferenciales de la base de datos. Una copia de seguridad diferencial de la base de datos se basa en una copia de seguridad completa de la base de datos y contiene un registro de todos los cambios producidos desde la última copia de seguridad completa de la base de datos (un error que se comete a menudo es creer que las copias de seguridad diferenciales son incrementales, y no lo son). Un ejemplo de estrategia podría ser efectuar una copia de seguridad diaria completa de la base de datos con una copia de seguridad diferencial de la base de datos cada cuatro horas. Las copias de seguridad diferenciales ofrecen una única opción extra de recuperación a un momento dado. Si sólo usa copias de seguridad completas y diferenciales de la base de datos, debe seguir usando el modelo de recuperación simple.
Para finalizar, lo último en recuperación son las copias de seguridad de registros. Éstas sólo están disponibles en los modelos de recuperación FULL (o BULK_LOGGED) y proporcionan una copia de seguridad de todos los registros generados desde la última copia de seguridad de registros. Mantener un conjunto de copias de seguridad de registros con copias de seguridad completas de la base de datos (y quizás copias diferenciales de la base de datos) proporciona un número ilimitado de versiones a un momento dado para recuperar, incluida una recuperación actualizada. Debe tenerse en cuenta que el registro de transacciones continuará creciendo a no ser que se "libere" efectuando una copia de seguridad de registros. Un ejemplo para este caso sería realizar una copia de seguridad completa de la base de datos cada día, una copia de seguridad diferencial de la base de datos cada cuatro horas y una copia de seguridad de registros cada media hora.
Optar por una estrategia de copias de seguridad y configurarla puede ser una tarea complicada. Como mínimo, debe realizar una copia de seguridad periódica completa de la base de datos para asegurarse de que tiene por lo menos una copia a un momento dado desde la que recuperar información.
Como puede ver, para garantizar que su base de datos permanezca en buen estado y disponible hay unas cuantas tareas que tiene que realizar. He aquí mi lista de comprobación final para un administrador de base de datos involuntario que se hace cargo de una base de datos:
  • Elimine la fragmentación excesiva del archivo de registro de transacciones.
  • Establezca el crecimiento automático correctamente.
  • Desactive las operaciones de reducción programadas.
  • Active la inicialización instantánea de archivos.
  • Implemente un proceso periódico para detectar y eliminar la fragmentación de índices.
  • Establezca AUTO_CREATE_STATISTICS y AUTO_UPDATE_STATISTICS en ON e implemente un proceso periódico para actualizar estadísticas.
  • Active la opción de sumas de comprobación de página (o, como mínimo, la detección de páginas rasgadas en SQL Server 2000).
  • Disponga de un proceso periódico para ejecutar DBCC CHECKDB.
  • Implemente un proceso periódico para efectuar copias de seguridad completas de la base de datos, además de copias de seguridad diferenciales y copias de seguridad de registros para la recuperación a un momento dado.
En este artículo he usado comandos de T-SQL, pero también se pueden hacer muchas cosas desde Management Studio. Espero haberle dado algunos consejos útiles para el mantenimiento efectivo de bases de datos. Si tiene comentarios o preguntas, escríbame a paul@sqlskills.com.

Paul S. Randal es el director general de SQLskills.com y uno de los profesionales más valorados (MVP) de SQL Server. Ha trabajado en el equipo de Motor de almacenamiento de SQL Server en Microsoft de 1999 a 2007. Paul es un experto en recuperación ante desastres, en alta disponibilidad y en el mantenimiento de bases de datos. Además, es autor de un blog: SQLskills.com/blogs/paul.

© 2008 Microsoft Corporation y CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.


Administración de Windows
Cómo tomarle el pulso a un servidor
Steven Choy
De un vistazo:
  • Personalización del monitor de rendimiento
  • Orientación sobre los elementos que se deben medir y la frecuencia
  • Información general sobre los contadores clave y los conceptos de búsqueda

Contenido
Hacer que los resultados sean más legibles
Elementos y período de medición
Cuello de botella de disco duro
Cuello de botella de memoria
Cuello de botella de procesador
Cuello de botella de red
Cuello de botella de proceso
Conclusión
Imagínese que acaba de llegar a la oficina un lunes por la mañana y le saluda un usuario ansioso que se queja de que su servidor va demasiado lento. ¿Cómo empezaría a ayudarle? Rendimiento
El Monitor de sistema, una práctica herramienta integrada en Windows®, puede ayudarle a diagnosticar el problema.
Para obtener acceso al monitor de rendimiento, escriba perfmon en el símbolo del sistema o seleccione el Monitor de rendimiento o Monitor de confiabilidad y rendimiento (en Windows Vista® y Windows Server® 2008) en el menú Herramientas administrativas. Para agregar los contadores de rendimiento y objetos que desea supervisar, haga clic en el signo más y seleccione los elementos deseados de la lista de posibles opciones.
Entonces, ¿cómo se le toma el pulso a un servidor? Existen más de 60 objetos de rendimiento básicos, y cada objeto contiene varios contadores. En este artículo hablaremos de los contadores que revelan las constantes vitales de un servidor y describiremos los intervalos típicos de muestreo que los ingenieros de soporte técnico de Microsoft® emplean más a menudo para solucionar los problemas relacionados con el rendimiento.
Por supuesto, una línea de base ofrece un punto de referencia fundamental a la hora de solucionar problemas. Puesto que la carga del servidor depende de los requisitos empresariales y, además, varía ocasionalmente en función del ciclo de negocio, es importante establecer una línea de base determinada por la carga de trabajo normal durante un período especificado. Eso le permite observar los cambios e identificar las tendencias.

Hacer los resultados más legibles
Antes de profundizar en un análisis de los contadores que representan las constantes vitales de los servidores, comentaremos dos trucos que le facilitarán la medición de dichas constantes vitales mediante el Monitor de rendimiento. Tenga en cuenta que, si bien estos trucos no son necesarios en Windows Vista ni en Windows Server 2008, si ejecuta el Monitor de rendimiento en versiones anteriores de Windows, estos ajustes podrían resultar de gran utilidad.
En primer lugar, quite todas las interferencias de muestra que impiden obtener una vista gráfica clara de las líneas de tendencia. En Windows Vista y Windows Server 2008, el Monitor de rendimiento puede mostrar hasta 1.000 puntos de datos en la vista gráfica. En versiones anteriores de Windows, el límite es de tan sólo 100 puntos de datos. Cuando existen más de 100 puntos, el Monitor de rendimiento "empaqueta" los puntos de datos. Un paquete se representa mediante una línea vertical, que indica el número mínimo, el promedio y el número máximo de puntos de muestra incluidos en el paquete.
Como puede comprobar en el gráfico de la figura 1, resulta difícil marcar la línea de la tendencia cuando se muestran tantos datos al mismo tiempo. El gráfico de la figura 2 muestra cuánto más fácil resulta capturar los datos con rapidez una vez desactivada toda la información visual superflua. Para obtener información sobre cómo desactivar estas líneas verticales, vea el artículo de Microsoft Knowledge Base disponible en support.microsoft.com/kb/283110.
Figura 1 Datos de rendimiento mostrados con paquetes que distraen y sin comas (haga clic en la imagen para ampliarla)
Figura 2 Vista más limpia de los datos con separadores de coma (haga clic en la imagen para ampliarla)
El segundo truco consiste en agregar separadores de coma entre los números, lo que facilita enormemente la lectura de los valores que muestran los contadores. Windows Vista y Windows Server 2008 tienen los separadores de coma habilitados de forma predeterminada. En versiones anteriores de Windows, sin embargo, el Monitor de rendimiento no habilita las comas de forma predeterminada.
Esto puede no parecer una gran diferencia, pero echemos un vistazo a la figura 1, que muestra los contadores de rendimiento sin comas y, seguidamente, miremos la figura 2, que muestra los contadores con comas. En mi opinión, el segundo resulta mucho más legible. Para obtener instrucciones sencillas sobre cómo agregar separadores de coma a contadores de rendimiento en Windows XP, vea el artículo de Microsoft Knowledge Base en support.microsoft.com/kb/300884.

Elementos y período de medición
Los cuellos de botella suelen producirse cuando un recurso alcanza su límite de capacidad, lo que provoca una ralentización del rendimiento de todo el sistema. Los cuellos de botella son provocados normalmente por recursos insuficientes o configurados incorrectamente, componentes que no funcionan debidamente o solicitudes incorrectas de recursos realizadas por un programa.
Existen cinco áreas principales de recursos que pueden causar cuellos de botella y afectar al rendimiento del servidor: el disco físico, la memoria, el proceso, la CPU y la red. Si se hace un uso excesivo de cualquiera de estos recursos, el servidor o la aplicación pueden ralentizarse notablemente o incluso bloquearse. Describiremos cada una de estas cinco áreas y ofreceremos orientación sobre los contadores que deben usarse, así como los umbrales sugeridos para medir el pulso de los servidores.
Dado que el intervalo de muestreo tiene una repercusión considerable en el tamaño del archivo de registro y la carga del servidor, deberá establecer dicho intervalo en función del lapso de tiempo medio que transcurre hasta que se produce el problema para poder establecer una línea de base antes de que el problema se vuelva a producir. Esto le permitirá detectar cualquier tendencia que conduzca al problema.
Quince minutos son un buen marco para establecer una línea de base durante las operaciones más habituales. Si el tiempo medio transcurrido hasta que se produce el problema es de unas cuatro horas, establezca el intervalo de muestreo en 15 segundos. Si dicho tiempo es de ocho horas o más, establezca el intervalo de muestreo en por lo menos cinco minutos, ya que, de lo contrario, acabará obteniendo un archivo de registro con un tamaño desmesurado, lo que dificultará enormemente el análisis de los datos.

Cuello de botella de disco duro
Debido a que el sistema de disco almacena y controla los programas y los datos del servidor, un cuello de botella que afecte al uso y a la velocidad del disco tendrá una gran repercusión en el rendimiento general del servidor.
Tenga en cuenta que si los objetos de disco no se han habilitado en su servidor, deberá usar la herramienta de línea de comandos Diskperf para habilitarlos. Asimismo, observe que % de tiempo de disco puede superar el 100 por ciento y que, por lo tanto, personalmente prefiero usar % de tiempo inactivo, promedio de segundos de disco/lectura y promedio de segundos de disco/escritura para tener una idea más exacta de hasta qué punto está ocupado el disco duro. Encontrará más información sobre % de tiempo de disco en el artículo de Microsoft Knowledge Base disponible en support.microsoft.com/kb/310067.
A continuación están los contadores que emplean los ingenieros de soporte técnico de Microsoft para supervisar los discos.
Disco lógico\% de espacio libre Mide el porcentaje de espacio libre existente en la unidad de disco lógica seleccionada. Procure que este indicador no se sitúe por debajo del 15 por ciento, ya que corre el riesgo de quedarse sin espacio disponible para que el sistema operativo pueda almacenar archivos críticos. Una solución obvia en este caso sería agregar más espacio en disco.
Disco físico\% de tiempo inactivo Mide el porcentaje de tiempo en el que el disco ha permanecido inactivo durante el intervalo de muestreo. Si este contador se sitúa por debajo del 20 por ciento, el sistema de disco estará saturado. Una opción es reemplazar el sistema de disco actual por un sistema más rápido.
Disco físico\Promedio de segundos de disco/lectura Mide el promedio de tiempo en segundos que necesita el disco para leer datos. Si este número es superior a 25 milisegundos (ms), significa que el sistema de disco sufre latencia al leer desde el disco. Para los servidores fundamentales que hospedan SQL Server® y Exchange Server, el umbral aceptable es mucho más bajo, aproximadamente 10 ms. La solución más lógica en este caso consiste en reemplazar el sistema actual de disco por un sistema más rápido.
Disco físico\Promedio de segundos de disco/escritura Mide el promedio de tiempo en segundos que se tarda en escribir datos en el disco. Si el número supera los 25 ms, el sistema de disco sufrirá latencia al escribir en el disco. Para los servidores fundamentales que hospedan SQL Server y Exchange Server, el umbral aceptable es mucho más bajo, aproximadamente 10 ms. La solución más probable en este caso es reemplazar el sistema de disco con un sistema más rápido.
Disco físico\Longitud promedio de la cola de disco Indica el número de operaciones de E/S que permanecen a la espera de que la unidad de disco duro esté disponible. Si el valor en este caso es superior al número de ejes más dos, significa que el propio disco puede ser el cuello de botella.
Memoria\Bytes de caché Indica la cantidad de memoria en uso para la memoria caché del sistema de archivos. Si este valor es superior a 200 MB, podría haber un cuello de botella del disco.

Cuello de botella de memoria
Una escasez de memoria es normalmente debida a una cantidad insuficiente de RAM, una pérdida de memoria o un modificador de comandos de memoria insertado en el archivo boot.ini. Antes de pasar a hablar de los contadores de memoria, nos detendremos en el parámetro /3GB.
Una mayor cantidad de memoria reduce la actividad de E/S del disco lo que, a su vez, mejora el rendimiento de las aplicaciones. El parámetro /3GB se introdujo en Windows NT® como una manera de proporcionar más memoria para los programas de modo de usuario.
Windows usa un espacio de direcciones virtual de 4 GB, independientemente de la cantidad de RAM física de que disponga el sistema. De forma predeterminada, los 2 GB inferiores se reservan para programas de modo de usuario y los 2 GB superiores para programas de modo kernel. Sin embargo, el parámetro /3GB permite asignar 3 GB a los procesos de modo de usuario. Esto, por supuesto, se produce en detrimento de la memoria del kernel, que dispondrá tan sólo de 1 GB de espacio de direcciones virtual. Y esto puede causar problemas, ya que los bytes de bloque no paginado, los bytes de bloque paginado, las entradas libres de la tabla de páginas del sistema y el montón del escritorio están todos apretados en un único GB de espacio. Por lo tanto, el parámetro /3GB sólo debe usarse después que comprobar a fondo el entorno.
Se trata de un tema a tener en cuenta si sospechamos que estamos sufriendo un cuello de botella relacionado con la memoria. Si el parámetro /3GB no es la causa de los problemas, puede usar estos contadores para diagnosticar un posible cuello de botella de la memoria.
Memoria\% de bytes confirmados en uso Mide la proporción de bytes confirmados respecto al límite de confirmación, es decir, la cantidad de memoria virtual en uso. Indicará que no hay memoria suficiente si el número es superior al 80 por ciento. La solución obvia en este caso consiste en agregar más memoria.
Memoria\% Mbytes disponibles Mide la cantidad de memoria física, en megabytes, disponible para los procesos que se están ejecutando. Si este valor es inferior al 5 por ciento de la RAM física total, significa que no hay memoria suficiente, lo que puede provocar un aumento de la actividad de paginación. Para resolver este problema, basta con agregar más memoria.
Memoria\Entradas libres de la tabla de páginas del sistema Indica el número de entradas de la tabla de páginas que no está usando actualmente el sistema. Si este número es inferior a 5.000, es muy posible que haya una pérdida de memoria.
Memoria\Bytes de bloque no paginado Mide el tamaño en bytes del bloque no paginado. Se trata de un área de la memoria del sistema para aquellos objetos que no pueden escribirse en el disco, sino que deben permanecer en la memoria física mientras estén asignados. Si el valor es superior a 175 MB (o 100 MB con el parámetro /3GB), es posible que haya una pérdida de memoria. Se graba un identificador típico de evento 2019 en el registro de eventos del sistema.
Memoria\Bytes de bloque paginado Mide el tamaño en bytes del bloque paginado. Se trata de un área de la memoria del sistema empleada para los objetos que pueden escribirse en el disco cuando no se usan. Si este valor es superior a 250 MB (o 170 MB con el parámetro /3GB), es posible que haya una pérdida de memoria. Se graba un identificador típico de evento 2020 en el registro de eventos del sistema.
Memoria\Páginas por segundo Mide la velocidad a la que se leen las páginas desde el disco o se escriben en éste para resolver errores severos de página. Si el valor es superior a 1.000, es posible que se produzca una pérdida de memoria a consecuencia de un exceso de paginación.

﻿Cuello de botella de procesador
Una carga excesiva del procesador puede ser debida a que el propio procesador no ofrece un rendimiento suficiente o bien a una aplicación ineficaz. Deberá comprobar si el procesador invierte mucho tiempo en la paginación a consecuencia de no disponer de suficiente memoria física. Para investigar un posible cuello de botella de procesador, los ingenieros de soporte técnico de Microsoft emplean los siguientes contadores.
Procesador\% de tiempo de procesador Mide el porcentaje de tiempo transcurrido que invierte el procesador en ejecutar un subproceso no inactivo. Si el porcentaje es superior al 85 por ciento, el procesador está sobrecargado, por lo que es posible que el servidor requiera un procesador más rápido.
Procesador\% de tiempo de usuario Mide el porcentaje de tiempo transcurrido que el procesador invierte en el modo de usuario. Si este valor es alto, significa que el servidor está ocupado con la aplicación. Una posible solución en este caso sería optimizar la aplicación que está agotando los recursos del procesador.
Procesador\% de tiempo de interrupción Mide el tiempo que el procesador invierte en recibir y atender interrupciones de hardware durante intervalos específicos de muestreo. Este contador indica un posible problema de hardware si el valor es superior al 15 por ciento.
Sistema\Longitud de la cola del procesador Indica el número de subprocesos que contiene la cola del procesador. Si el valor es más de dos veces el número de unidades CPU durante un período prolongado, significa que el servidor no tiene suficiente potencia de procesador.

Cuello de botella de red
Un cuello de botella de red, por supuesto, afecta a la capacidad del servidor para enviar y recibir datos a través de la red. Puede tratarse de un problema con la tarjeta de red del servidor, o quizás que la red se haya quedado saturada y necesite segmentarse. Puede usar los siguientes contadores para diagnosticar los posibles cuellos de botella de la red.
Interfaz de red\Total de bytes/s Mide la velocidad a la que se envían y reciben bytes a través de cada adaptador de red, incluidos los caracteres de tramas. Si detecta que se consume más del 70 por ciento de la interfaz, significa que la red está saturada. Para una tarjeta NIC de 100 Mbps, la interfaz consumida es de 8,7 MB por segundo (100 Mbps = 100.000 kbps = 12,5 MB por segundo * 70 por ciento). En una situación de este tipo, se recomienda agregar una tarjeta de red más rápida o bien segmentar la red.
Interfaz de red\Longitud de la cola de salida Mide la longitud de la cola de paquetes de salida (en paquetes). Si el valor es superior a dos, la red está saturada, situación que podrá solventar agregando una tarjeta de red más rápida o segmentando la red.

Cuello de botella de proceso
El rendimiento del servidor se verá gravemente afectado si tiene un proceso que no funciona de la manera prevista o procesos que no están optimizados. Las pérdidas de subprocesos e identificadores podrían incluso llegar a bloquear un servidor, mientras que un uso excesivo del procesador ralentizará notablemente su rendimiento. Los siguientes contadores son imprescindibles para diagnosticar cuellos de botella relacionados con procesos.
Proceso\Recuento de identificadores Mide el total de identificadores abiertos actualmente por un proceso. Si el número es superior a 10.000, el contador indica una posible pérdida de identificadores.
Proceso\Número de subprocesos Mide el número de subprocesos activos en ese momento en un proceso. Si el número es superior a 500 entre la cantidad mínima y máxima de subprocesos, podría haber una pérdida de subprocesos.
Proceso\Bytes privados Indica la cantidad de memoria que ha asignado el proceso en cuestión y que no puede compartirse con otros procesos. Si el valor es superior a 250 entre la cantidad mínima y máxima de subprocesos, podría haber una pérdida de memoria.

Conclusión
Ahora ya sabe qué contadores usan los ingenieros de soporte técnico de Microsoft para diagnosticar los diversos cuellos de botella. Por supuesto, lo más probable es que se cree su propio conjunto de contadores favoritos adaptados a sus necesidades específicas. Si no desea perder tiempo agregando manualmente los contadores favoritos cada vez que se dedique a supervisar sus servidores, afortunadamente existe una opción en el Monitor de rendimiento que le permite guardar todos los contadores en una plantilla para poder usarlos en futuras ocasiones.
Es posible que siga preguntándose si debe ejecutar el Monitor de rendimiento de manera local o remota. Y si lo ejecuta en local, ¿cómo se verá afectado el rendimiento? Todo dependerá de su entorno específico. Si establece intervalos de al menos cinco minutos, el rendimiento del servidor apenas se verá afectado.
Se recomienda ejecutar el Monitor de rendimiento en local si se conoce que existe un problema de rendimiento en el servidor, ya que el Monitor de rendimiento podría no ser capaz de capturar los datos de un equipo remoto si se agotan los recursos en el servidor. Ejecutarlo de forma remota desde un equipo centralizado es en realidad la mejor opción en situaciones en las que se desea supervisar o establecer una línea de base para varios servidores.

Steven Choy es Ingeniero de campo principal en Microsoft. Ha prestado asistencia técnica a organismos gubernamentales y clientes comerciales en proyectos de implementación y migración de escritorios, administración de revisiones y directiva de grupo. Sus esfuerzos se centran actualmente en la virtualización y el estado de funcionamiento de servidores.


System Center
Windows PowerShell en System Center Operations Manager
Marco Shaw
De un vistazo:
  • Shell de comandos de OpsMgr
  • Proveedor de supervisión de OpsMgr
  • Automatización de tareas administrativas habituales
  • Algunos ejemplos reales de Windows PowerShell

Contenido
Shell de comandos de Operations Manager
El proveedor Monitoring de OpsMgr
Automatización de tareas habituales
El mundo real
Conclusión
System Center Operations Manager 2007 (OpsMgr) ha concedido acceso a los administradores a Windows PowerShell, un lenguaje de scripts nuevo y eficaz que permite automatizar tareas. En noviembre de 2006 se realiza el lanzamiento público y desde entonces se ha descargado más de dos millones de veces.
En este artículo hablaré de Windows PowerShell® y explicaré cómo se aplica a Operations Manager. Explicaré algunas de las tareas habituales que Windows PowerShell le puede ayudar a realizar de una forma más sencilla y automatizada, e indicaré algunos sitios web que proporcionan scripts y explicaciones útiles. He reunido información y entradas de blog de numerosos expertos que usan Windows PowerShell en la actualidad.
Aunque Microsoft ha comenzado el lanzamiento de versiones CTP (Community Technology Preview) de Windows PowerShell 2.0, dichas versiones no están preparadas para su uso en producción, además no se han probado con OpsMgr y no deben instalarse en un sistema de producción.

Shell de comandos de Operations Manager
En OpsMgr, se obtiene acceso a Windows PowerShell a través del shell de comandos, que es parecido al entorno predeterminado de Windows PowerShell, con la diferencia de que carga un archivo de consola y un script que inicializa el entorno con cmdlets de OpsMgr, con funciones y con una conexión predeterminada.
Puede iniciar el shell de comandos desde un icono en el menú Inicio de OpsMgr o haciendo clic con el botón secundario del mouse en un nombre de equipo en la consola de interfaz de usuario de OpsMgr (consulte la figura 1). Esto le sitúa directamente en la ruta de acceso de la unidad Monitoring de OpsMgr (que describiré en breve).
Figura 1 Abrir el shell de comandos desde la interfaz de usuario de OpsMgr (haga clic en la imagen para ampliarla)
Windows PowerShell interactúa con OpsMgr a través del SDK de OpsMgr. Por suerte para los administradores, ya se han proporcionado cmdlets para numerosas tareas que normalmente se automatizarían o se llevarían a cabo desde una línea de comandos. Si no hay un cmdlet para una determinada tarea, puede usar Windows PowerShell para interactuar con el SDK.
Los comandos que proporciona el shell de comandos de Operations Manager se incluyen en un complemento, una DLL que se carga con Windows PowerShell y que contiene cmdlets para la administración de OpsMgr. El complemento también incluye el proveedor OperationsManagerMonitoring de Windows PowerShell. Esta herramienta, también denominada proveedor Monitoring, permite la navegación por conexiones, grupos y objetos de supervisión; esta navegación se asemeja bastante a la que se realiza por el sistema de archivos.
Puede obtener una lista de todos los cmdlets específicos de OpsMgr con el cmdlet Get-OperationsManagerCommand, tal como se muestra en la figura 2. En la primera versión era una función que no admitía la posibilidad de completar con el tabulador y en la versión con SP1 se convirtió en cmdlet. El lanzamiento original de Operations Manager incluía 74 cmdlets, mientras que OpsMgr SP1 tiene 87.
Figura 2 Obtención de una lista de cmdlets de OpsMgr (haga clic en la imagen para ampliarla)

El proveedor Monitoring de OpsMgr
Con el cmdlet Set-Location, o el alias cd, puede desplazarse por el diseño de grupos y equipos. El diseño base de la unidad Monitoring predeterminada es similar al siguiente:
Monitoring:\->RMS->Groups (as defined in OpsMgr)
  ->Computers(as defined in OpsMgr)
Desde aquí, puede llegar a objetos más específicos. Tenga en cuenta que en este caso estoy considerando únicamente un entorno simple en el que hay un solo servidor de administración. El primer servidor de administración instalado en un grupo de administración se denomina servidor de administración raíz (RMS).
Cuando se inicia el shell de comandos, éste crea una unidad denominada Monitoring, asigna la unidad a la raíz del proveedor OperationsManagerMonitoring y, finalmente, establece la ruta de acceso o la ubicación actual en la raíz de la unidad Monitoring. A continuación, el shell de comandos busca en el Registro el nombre del RMS predeterminado con el que se va a conectar. Si la conexión al RMS se realiza correctamente, la ubicación o la ruta de acceso actual se establece en el nombre de la conexión, o RMS, tal como se muestra en la figura 3.
Figura 3 La ubicación del shell de comandos se establece en el RMS (haga clic en la imagen para ampliarla)

Automatización de tareas comunes
Veamos cómo Windows PowerShell maneja algunas de las tareas administrativas más habituales.
Controlar el modo de mantenimiento No importa la tarea con la que esté lidiando, normalmente querrá especificar la fecha y hora en las que se va producir. Vamos a echar un vistazo rápido al cmdlet Get-Date para que vea lo fácil que puede ser. En la figura 4 se muestran algunos ejemplos.
Figura 4 Uso del cmdlet Get-Date (haga clic en la imagen para ampliarla)
Como puede ver, he creado una variable $date que contiene un objeto que representa la hora actual. A continuación, he usado algunos métodos documentados admitidos por el objeto para mostrar lo sencillo que resulta obtener la fecha y la hora cinco minutos más tarde y cinco horas después. Si deseara obtener valores del pasado, simplemente usaría (-5) en vez de (5).
Cuando necesite bloquear todas las alertas procedentes de un equipo, puede habilitar el modo de mantenimiento. OpsMgr 2007 permite establecer un servicio de Windows®, o incluso una determinada base de datos, en modo de mantenimiento en vez de un equipo o grupo entero. Hay tres cmdlets que tratan específicamente tareas de modo de mantenimiento: Get-MaintenanceWindow, New-MaintenanceWindow y Set-MaintenanceWindow.
Si desea poner un equipo en el modo de mantenimiento desde el shell de comandos, vaya al equipo u objeto de supervisión que desee usando el proveedor Monitoring e invoque el cmdlet New-MaintenanceWindow, tal como se muestra en la figura 5. Como puede ver, esta acción establece el equipo denominado Denver.contoso.com en modo de mantenimiento. Por otra parte, he definido la hora de inicio del período de mantenimiento para que surta efecto de forma inmediata y la hora de finalización para se produzca exactamente una hora después. Tenga en cuenta cuando se establece un equipo en modo de mantenimiento mediante este método no se detienen todas las alertas, ya que las instancias HealthService y HealthServiceWatcher del objeto siguen habilitadas.
Figura 5 Uso del cmdlet New-MaintenanceWindow (haga clic en la imagen para ampliarla)
Boris Yanushpolsky, administrador de programas del equipo de Microsoft OpsMgr, ha proporcionado código de Windows PowerShell muy útil que se puede usar para definir todos los objetos que hacen referencia a un equipo en modo de mantenimiento y ha explicado cómo usarlo una vez creado un script. Para obtener más información, consulte su blog en blogs.msdn.com/boris_yanushpolsky/archive/2007/07/25/putting-a-computer-into-maintenance-mode.aspx.
A veces es necesario determinar si los objetos están en un modo de mantenimiento en el que no deberían estar. Recorrer todos los objetos para intentar averiguarlo puede convertirse en toda una odisea. Afortunadamente, Boris Yanushpolsky acude al rescate de nuevo con un script de Windows PowerShell que usa el SDK de OpsMgr. Puede copiar el código directamente desde su mensaje en el blog (blogs.msdn.com/boris_yanushpolsky/archive/2007/08/06/so-what-is-in-maintenance-mode.aspx) y pegarlo en una ventana del shell de comandos para obtener una lista de todos los objetos que están en modo de mantenimiento.
Cuando un objeto está en modo de mantenimiento, es posible que desee finalizar el período de mantenimiento antes de la hora de finalización especificada inicialmente. Si está familiarizado con Windows PowerShell, aunque normalmente espere un cmdlet con un verbo stop o remove, en realidad debe usar Set-MaintenanceWindow, tal como se muestra en la figura 6.
Figura 6 Uso de Set-MaintenanceWindow para cambiar la hora de finalización (haga clic en la imagen para ampliarla)
Administrar agentes Los administradores trabajan a menudo con agentes y hay seis cmdlets y una función (en esta versión) que tratan distintas tareas relacionadas con agentes. El siguiente comando le permite obtener una lista de los mismos:
Get-Command *-agent*
En la versión SP1, Install-AgentByName se empaqueta como un cmdlet en lugar de una función. Se recomienda usar el cmdlet Install-AgentByName, ya que proporciona una mejor base para la asistencia y la coherencia.
La ayuda integrada que se incluye con el shell de comandos proporciona algunos ejemplos excelentes sobre el uso de los cmdlets Install-Agent y Uninstall-Agent. Roger Sprague, ingeniero sénior de diseño de software en el equipo de Microsoft OpsMgr, ha publicado un método alternativo en su blog, que se reproduce en la figura 7 (consulte el mensaje original en blogs.msdn.com/scshell/archive/2006/09/28/getting-started.aspx).
Este script funciona correctamente con OpsMgr RTM (debe ubicarse en la raíz del proveedor de supervisión, en este caso es monitoring:\oxford.contoso.com), pero no lo hace con OpsMgr SP1. Para que funcione con OpsMgr SP1, el primer comando de la figura 7 se debe cambiar por el siguiente:
$managementServer = Get-RootManagementServer
Figura 7 Instalación de un agente
# Get the Root Management Server.
$managementServer = Get-ManagementServer -Root: $true

# Create the discovery configuration for computer2 and computer3.
$discoConfig = New-WindowsDiscoveryConfiguration -ComputerName: computer2, computer3

# Discover the computers.
$discoResult = Start-Discovery -ManagementServer: $managementServer -WindowsDiscoveryConfiguration: $discoConfig

# Install an agent on each computer.
Install-Agent -ManagementServer: $managementServer -AgentManagedComputer: $discoResult.CustomMonitoringObjects
En este punto, el agente se instala en el sistema remoto que se debe supervisar, pero todavía hay un último paso donde el servidor de administración debe aceptar realmente el nuevo agente antes de que se supervise por completo. Si no se realiza ninguna acción adicional, el servidor de supervisión aceptará automáticamente al nuevo agente para supervisión. También se puede efectuar un seguimiento rápido de este proceso de aceptación mediante el cmdlet Get-AgentPendingAction. Este cmdlet de una sola línea realizará un seguimiento rápido del proceso de aceptación del agente:
Get-AgentPendingAction | Where Object {$_.AgentName –like
'computer*'} | Approve-AgentPendingAction
Al canalizarlo a Reject-AgentPendingAction, en vez de a Approve-AgentPendingAction, se puede bloquear la aceptación de este agente por parte del servidor de OpsMgr, si la acción todavía está pendiente. Si no está pendiente, use el cmdlet Uninstall-Agent en su lugar.
Según he mencionado, también puede usar Install-AgentByName para especificar un equipo directamente en la línea de comandos donde se instalará el agente.
Trabajar con módulos de administración Hay cuatro cmdlets que le ayudarán a tratar las distintas tareas de los módulos de administración. Puede enumerarlos con:
Get-Command –noun ManagementPack
Este comando sencillo proporciona los módulos de administración instalados actualmente y sus números de versión:
Get-ManagementPack | Format-Table –autosize
A continuación voy a usar el shell de comandos para instalar dos módulos de administración habituales con estos instaladores:
  • Internet Information Services System Center Operations Manager2007 Management Pack.msi
  • Windows Server® Base OS System Center Operations Manager2007 Management Pack.msi.
Debido a que mi objetivo es mostrar cómo el shell de comandos puede facilitar tareas periódicas, voy a hacerlo usando el menor número posible de comandos (como se muestra en la figura 8). Podría haber cambiado este procedimiento de instalación para pasar el marcador silencioso al instalador (los archivos .msi), pero quería seleccionar la ubicación en la que se extraerán manualmente los archivos.
Figura 8 Instalación de módulos de administración (haga clic en la imagen para ampliarla)
A continuación, necesito instalar las bibliotecas comunes, lo que puedo hacer del siguiente modo:
Get-ChildItem –Path C:\MPs –filter *Library.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
El siguiente paso es instalar los otros módulos de administración necesarios:
Get-ChildItem –Path C:\MPs –filter *200?.mp |
ForEach-Object
  {Install-ManagementPack –filePath $_.FullName}
Tal como se muestra en la figura 9, la ayuda integrada del shell de comandos ofrece un ejemplo excelente del uso del cmdlet Export-ManagementPack para exportar los módulos de administración sin sellar. Cambie la siguiente línea si desea exportar todos los módulos administración:
$mps=Get-ManagementPack |
Where-Object {$_.Sealed –eq $false}

$mps=Get-ManagementPack
Figura 9 Exportación de un módulo de administración (haga clic en la imagen para ampliarla)
Manipular las funciones de usuario El cmdlet Get-UserRole proporciona funcionalidad para administrar usuarios pero, curiosamente, no incluye un cmdlet Set complementario, y normalmente no se usa para realizar modificaciones o actualizaciones (según la documentación del SDK de Windows PowerShell). Como se puede ver en la figura 10, primero se obtiene una lista de las funciones actuales de usuario y, a continuación, se agrega un usuario al grupo Read-Only Operators (consulte la figura 11).
Figura 10 Presentación de las funciones de usuario (haga clic en la imagen para ampliarla)
Figura 11 Adición de un usuario (haga clic en la imagen para ampliarla)
Habilitar los servicios de recopilación de auditorías (ACS) ACS es una nueva característica opcional de Operations Manager 2007 que, en resumen, proporciona una forma centralizada de tratar la información de auditoría de seguridad. ACS no está habilitado de forma predeterminada y normalmente se configura más adelante en una fase posterior de una implementación de OpsMgr.
Cuando llega el momento de habilitar una gran cantidad de agentes para ACS, Windows PowerShell acude al rescate para ayudar a automatizar la configuración. Durante la versión beta de OpsMgr, Microsoft proporcionó un script para habilitar ACS en todos los agentes. Neale Browne, colaborador y blogger de SystemCenterForum.org, fue un paso más allá y agregó compatibilidad para parámetros adicionales.
El sitio de SystemCenterForum.org (un sitio de la comunidad que ofrece soluciones de Microsoft® System Center) ha publicado dos scripts distintos de Windows PowerShell para automatizar la configuración de ACS. Para configurar todos los agentes de un determinado grupo, use systemcenterforum.org/wp-content/uploads/ACSBulkEnableGroupDisplayName.zip. Para configurar todos los agentes supervisados, descargue systemcenterforum.org/wp-content/uploads/ACSBulkEnableAllAgents.zip.
Habilitar el agente de conexiones proxy El entorno de OpsMgr puede incluir dispositivos supervisados sin agente. Estos dispositivos se deben asignar a un servidor de administración o a un dispositivo administrado por agente que proporcionará la supervisión remota. Puede encontrar una descripción detallada sobre el uso de un script de Windows PowerShell para configurar una gran cantidad de agentes en systemcenterforum.org/enable-agent-act-as-a-proxy-in-bulk-via-powershell. Una versión actualizada del script está disponible en systemcenterforum.org/wp-content/uploads/SetAgentProxyBulk_FQDN.zip.
Hay otras condiciones en las que determinados módulos de administración requieren que un agente se configure para actuar también como proxy. Consulte la documentación del módulo de administración para obtener más detalles.

El mundo real
A continuación se presentan algunos ejemplos reales para demostrar cómo Windows PowerShell puede ayudar en la automatización.
Resolver alertas ¿Alguna vez ha tenido que eliminar varias alertas de un determinado equipo? Tal vez se produjo un error en una aplicación o las alertas no se resolvieron activamente. El siguiente un comando de una sola línea resolverá todas las alertas que tengan un estado de resolución de cero:
Get-Alert –criteria 'ResolutionState = ''0''' |
Resolve-Alert | Out-Null
El siguiente ejemplo realiza la misma tarea que el primero, pero se ejecutará más rápidamente en un entorno de mayor tamaño con más alertas pendientes:
Get-Alert | Where-Object {$_.ResolutionState -eq 0} |
Resolve-Alert | Out-Null
Esta diferencia de rendimiento se debe a que, cuando se usa el parámetro de criterios, el valor pasado se proporciona directamente a la base de datos SQL Server® y sólo se devuelven los datos relevantes. De este modo se reducen los objetos que se deben pasar a la consola de Windows PowerShell.
Ahora dispone de una forma rápida de quitar todas las alertas pendientes de un equipo. En función de sus requisitos, puede establecer el comando para que se ejecute de forma automática.
Por último, este comando rápido le permite ver todas las alertas de un día específico:
Get-Alert -criteria 'TimeRaised >= ''4/25/2008'''
Puede modificar fácilmente el valor de fecha y canalizar la salida al cmdlet Resolve-Alert.
Probar alertas Es posible que a veces desee supervisar determinados eventos en el Visor de eventos de Windows y probarlos. Estas dos líneas crearán una entrada rápida del registro de eventos:
$api=New-Object -comObject MOM.ScriptAPI
$api.logscriptevent("API test",100,0,
  "Test using PowerShell")
Sin embargo, se escribirá de forma predeterminada en el registro de eventos de Operations Manager, que probablemente no es el lugar donde se espera que se registre un determinado evento. Afortunadamente, Stefan Stranger, ingeniero de campo principal en Microsoft, ha escrito un script para crear eventos en el Visor de eventos de Windows y proporcionar más flexibilidad a la hora escribir en un determinado registro. Encontrará el script en go.microsoft.com/fwlink/?LinkId=120308. (Stefan ha empaquetado el script en un archivo .cab. Deberá descargar el archivo y, a continuación, hacer clic con el botón secundario en él para extraer el script.)
Lo único que se debe tener en cuenta con el script de Stefan es que el valor especificado para el origen del evento determina en qué registro se escribirá la entrada. Tal vez la forma más sencilla de asegurarse que una alerta se dirige al registro adecuado es abrir el Visor de eventos de Windows y buscar el origen de la entrada más reciente.
Establecer el propietario En ocasiones puede resultar útil establecer el propietario de una alerta automáticamente. A continuación se describe una forma sencilla de hacerlo desde el shell de comandos:
$alert = Get-Alert
  -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4
$alert.set_owner("Administrator")
$alert.update("Updated owner")
La primera línea de este código obtiene el identificador de un determinado objeto de alerta y lo pasa a la variable $alert. En la segunda línea, dicha variable se usa para establecer el propietario y, por último, la actualización se aplica a la base de datos de OpsMgr. Si comprueba el propietario de la alerta con el siguiente comando, verá que ha cambiado:
Get-Alert -id f3f73d62-37ab-45ce-a7ff-2bdda0dfaeb4 |
Select-Object Owner
Para establecer el propietario de un conjunto de alertas completo, puede simplificar el código del siguiente modo:
Get-Alert | ForEach-Object {$_.Set_
  Owner("Administrator");
  $_.Update("Owner set")}
Restaurar el estado de supervisión Es muy probable que se encuentre con agentes que se encuentran en un estado "no supervisado". En este caso, es posible que necesite restaurar todos los agentes a un estado supervisado completo rápidamente y, a continuación, intentar determinar lo que ha sucedido. Al ejecutar el script de la figura 12 directamente desde el shell de comandos se debe restaurar la supervisión completa de los agentes afectados.
Figura 12 Restablecimiento del almacén del servicio de mantenimiento
$all="Microsoft.SystemCenter.AllComputersGroup"
$agents = Get-ChildItem Microsoft.SystemCenter.AllComputersGroup | `
  Where-Object {$_.HealthState -eq 'Uninitialized'}
foreach ($agent in $agents)
{
$agent.DisplayName
Push-Location $all\$agent\Microsoft.SystemCenter.HealthService
Get-Task | Where-Object {$_.Name -eq "Microsoft.SystemCenter.ResetHealthServiceStore"} | `
    Start-Task -Asynchronous
Pop-Location
}
Observe el código de la figura 12. Después de declarar una variable, obtengo una lista de todos los agentes de este RMS y filtro los que parecen tener problemas. A continuación, llamo una tarea asincrónicamente que restablece el almacén del servicio de mantenimiento en todos los agentes de la lista filtrada.
Asociar alertas a módulos de administración En la figura 13 se muestra cómo obtener una lista de todas las alertas nuevas, así como el módulo de administración al que está asociada cada una.
El código requirió algunos ajustes para garantizar que se podían resolver todos los nombres de módulo de administración. Los cmdlets usados variarán en función de si la alerta procede de una regla o de un monitor. (Tenga en cuenta que en la figura 13 necesité implementar una solución temporal para el cmdlet Get-Monitor. Desde OpsMgr SP1, el cmdlet admite un nuevo parámetro de identificador, lo que simplifica ligeramente el código.)
Figura 13 Búsqueda del módulo de administración
Get-Alert | Where-Object {($_.PrincipalName -ne $null) -and ($_.ResolutionState = '0')}| `
Format-Table –autosize PrincipalName,Severity, `
  @{Label="MP"
      Expression={If(!($_.IsMonitorAlert)){
        ForEach-Object {
          ((Get-Rule $_.MonitoringRuleId).GetManagementPack()).DisplayName}
       }
       Else{
         ForEach-Object {
          $id=$_.ProblemId
          ((Get-Monitor -criteria "Id='$id'").GetManagementPack()).DisplayName}
         }
   }
}
Informes sencillos Al actualizar el entorno, puede resultar útil auditar las versiones de todos los agentes instalados. Sólo se necesita un script sencillo para imprimir un informe estupendo:
Get-Agent| `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
}
En la figura 14 se muestra el resultado del script. Este script es una versión ampliada de los ejemplos proporcionados en systemcenterforum.org/checking-operations-manager-2007-agent-and-server-versions-via-powershell.
Figura 14 Resultado que muestra las versiones de algunos agentes (haga clic en la imagen para ampliarla)
Programar una tarea Es posible que desee ejecutar un script de Windows PowerShell de forma periódica. Supongamos que usa un equipo cliente para conectarse y administrar el servidor OpsMgr y tiene las herramientas de administración de OpsMgr instaladas localmente. Consideremos, por ejemplo, que desea ejecutar el informe de versiones de agente diariamente y guardar el resultado en un archivo que se denomine con la fecha actual. Puede usar el programador de tareas de Windows integrado para ejecutar el script desde el equipo local.
Para ello, sólo tiene que configurar una tarea nueva con el programa establecido como powershell.exe (normalmente se encuentra en C:\Windows\System32\WindowsPowerShell\v1.0). Una vez creada la tarea, edítela y establezca el comando para que se ejecute de forma parecida a:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Resulta que al final tuve que realizar unos cuantos cambios en mi código de Windows PowerShell original, tal como se puede ver en la figura 15. Tuve que agregar el complemento PowerShell de OpsMgr, crear la unidad Monitoring asociada al proveedor OperationsManagerMonitoring y crear una conexión al RMS. También cargué el script de Windows PowerShell personalizado para OpsMgr (Microsoft.EnterpriseManagement.OperationsManager.ClientShell.Startup.ps1) para cargar las funciones específicas de OpsMgr.
Figura 15 Programación del script de versiones de agente
Add-PSSnapin Microsoft.EnterpriseManagement.OperationsManager.Client
New-PSDrive Monitoring Microsoft.EnterpriseManagement.OperationsManager.Client\
  OperationsManagerMonitoring ""
New-ManagementGroupConnection Oxford.contoso.com

Set-Location 'C:\Program Files\System Center Operations Manager 2007'
./Microsoft.EnterpriseManagement.OperationsManager.ClientShell.NonInteractiveStartup.ps1

$file="C:\$(Get-Date -f `"MMddyyyy`").rpt"

Get-Agent -Path Monitoring:\Oxford.contoso.com | `
Format-Table DisplayName,@{ `
  Label="Version"
  Expression={ `
    switch ($_.Version){
    "6.0.5000.0" {"RTM"}
    "6.0.6246.0" {"SP1 (RC)"}
    "6.0.6278.0" {"SP1 (RTM)"}
    }
  }
} | Out-File $file
Pero eso no es todo. Tal vez haya observado que cada vez que se ejecuta la tarea, aparece una ventana de consola negra en la pantalla si algún usuario ha iniciado sesión en el sistema donde se está ejecutando el script. Encontrará un pequeño truco que se ocupa de este tema, proporcionado por Don Jones y Jeffery Hicks de Sapien, en blog.sapien.com/index.php/2006/12/26/more-fun-with-scheduled-powershell.
Fundamentalmente necesita incluir el script en VBScript. Para ello, se usa código como el de la figura 16 en lugar de llamar el comando siguiente desde la tarea programada:
C:\Windows\System32\WindowsPowershell\v1.0\powershell.exe
  –Command "& {& 'c:\agent_report2.ps1'}"
Figura 16 Ocultación de las pantallas emergentes
Dim objShell
Set objShell=CreateObject("WScript.Shell")

'enter the PowerShell expression you need to use short filenames and paths
strExpression="'c:\agent_report2.ps1'"

strCMD="powershell -nologo  -command " & Chr(34) & _
"&{&" & strExpression &"}" & Chr(34)

'Uncomment next line for debugging
'WScript.Echo strCMD

'use 0 to hide window
objShell.Run strCMD,0
La tarea usará en este caso el programa wscript.exe y la llamada sería similar a la siguiente:
C:\WINDOWS\System32\wscript.exe C:\agent_report.vbs
Por último, se pueden crear informes automatizados y el proceso se oculta a los usuarios que han iniciado sesión.

Conclusión
En este artículo se ha realizado un breve recorrido de las nuevas características de automatización disponibles con OpsMgr 2007 y supone tan solo una mínima parte de cómo se puede usar Windows PowerShell para la administración de OpsMgr.
Me gustaría dar las gracias a todas las personas mencionadas en el artículo, así como a Pete Zerger, MVP de MOM y fundador de SystemCenterForum.org, por su valiosa ayuda.

Marco Shaw es analista de sistemas de TI para una compañía de telecomunicaciones de Canadá. Ha trabajado en el sector de TI durante más de 10 años y recientemente ha recibido un galardón de MVP de Windows PowerShell. Marco también es director adjunto de comunidad del nuevo sitio web de la comunidad de PowerShell en powershellcommunity.org. Tiene su propio blog en marcoshaw.blogspot.com.


Internet Information Services
Escalar aplicaciones ASP.NET: Lecciones aprendidas
Richard Campbell
De un vistazo:
  • La importancia de la colaboración desarrolladores/TI
  • Descripción de las principales estrategias de escalado
  • Compartir conocimientos entre equipos
  • Acordar un conjunto básico de conocimientos

Contenido
Fundamentos del escalado
La reunión de las mentes
Lo que el equipo de red necesita saber del equipo de desarrollo
Lo que el equipo de desarrollo necesita saber del equipo de red
Volver al escalado
El bombardeo cooperativo
Como consultor, cada aplicación ASP.NET escalada correctamente con la que he trabajado ha sido el resultado de un esfuerzo colaborativo entre los desarrolladores (que la han creado) y los administradores de red (que realmente la ejecutan). Lamentablemente, no siempre resulta obvio al principio del
ciclo de vida de una aplicación que esta colaboración sea esencial. Por lo que rara vez tengo la oportunidad de participar desde el principio en el ciclo de vida de una aplicación; lo normal es hacerlo únicamente en el amargo final cuando surgen los problemas.
La verdad es que ninguna aplicación se escala de forma eficaz la primera vez, ya que es imposible que todo esté correcto de buenas a primeras. Para escalar correctamente una aplicación, es necesario comprender el modo en que se ha creado, así como el funcionamiento del entorno operativo en el que se ejecuta. Es decir, se necesita información tanto del personal de desarrollo como del de red. Sin este conocimiento compartido no se puede llegar a buen puerto.

Fundamentos del escalado
Antes de profundizar en el tema, vamos a allanar el terreno con lo que se necesita saber para escalar realmente una aplicación ASP.NET. Habitualmente se emplean dos estrategias fundamentales, especialización y distribución, y ambas se aplican en el escalado de aplicaciones ASP.NET de mayor tamaño. Además, cada truco para el escalado de la aplicación ASP.NET cambia de una u otra aplicación.
La especialización supone la separación de los elementos de la aplicación de modo que se puedan escalar independientemente. Por ejemplo, podría crear servidores de imágenes dedicados en vez de usar los mismos servidores que para la representación de las páginas ASP.NET. La configuración óptima de un servidor de imágenes difiere bastante de la de un servidor ASP.NET. Además, al separar las solicitudes de imágenes del resto de la aplicación se abre la posibilidad de usar recursos de terceros para servir las imágenes. El mismo enfoque se puede aplicar a otros archivos de recursos.
Por otro lado, la distribución implica la difusión de la aplicación simétricamente en varios servidores, lo que normalmente se denomina una granja de servidores web. Las aplicaciones ASP.NET resultan especialmente adecuadas para la distribución, ya que cada solicitud de página individual es relativamente pequeña y las interacciones de un determinado usuario son muy independientes de los demás usuarios. La distribución es realmente la manifestación de la filosofía de "escalado horizontal", donde varios servidores de rendimiento medio trabajan conjuntamente para servir a los usuarios, en vez del enfoque de "escalado vertical" en el que un servidor masivo realiza todas las tareas.
La combinación de la especialización y la distribución aumenta la eficacia, ya que sólo se pueden distribuir los elementos de la aplicación que necesitan un rendimiento adicional. Por ejemplo, si ha creado servidores de imágenes especializados pero el servicio de imágenes sigue sin ser adecuado, puede agregar servidores de imágenes en lugar de agregar servidores para toda la aplicación. Es importante tener en cuenta estas estrategias a medida que se profundiza en la mejora del rendimiento y en la escalabilidad de la aplicación ASP.NET.

La reunión de las mentes pensantes
Es muy probable que los desarrolladores y el personal de red/TI se reúnan en algún momento del ciclo de vida de una aplicación ASP.NET. Con suerte, esto sucederá antes de que se implemente la aplicación, pero a veces sólo se reúnen después de una crisis como, por ejemplo, cuando la aplicación se ejecuta de maravilla en el entorno de prueba, se envía a los usuarios y entonces se ralentiza enormemente (es en ese momento cuando se solicitan los servicios de consultores como yo).
Cuando los desarrolladores y el personal de red se reúnen, el objetivo principal es intercambiar información. Los desarrolladores poseen conocimientos clave acerca de la aplicación y el personal de red los tiene acerca del entorno operativo. Cada grupo necesita comprender los datos del otro grupo y cuanto más cerca del comienzo del ciclo de vida de la aplicación se reúnan, tanto mejor.
Esta reunión no se debe producir por primera vez durante una crisis. Sin un conocimiento básico entre los dos equipos, es muy difícil averiguar el motivo por el que la aplicación no tiene el rendimiento esperado. Además, es muy fácil estar a la defensiva y echar las culpas exclusivamente al otro equipo. Y eso nunca es cierto, ya que siempre se necesita a ambas partes para solucionar problemas de elevada complejidad.
Incluso cuando todo va viento en popa, este tipo de reunión puede ser todo un desafío. Las que he organizado normalmente empiezan con el personal de red a un lado de la mesa y el equipo de desarrollo al otro. Se miran fijamente. Mi estrategia para que fluya la conversación consiste normalmente en describir el objetivo de la reunión, en concreto un intercambio de conocimientos. No importa quién comience primero. Empezaré con lo que el equipo de red necesita saber del equipo de desarrollo.

Lo que el equipo de red necesita saber del equipo de desarrollo
Cada aplicación ASP.NET tiene sus propias peculiaridades, pero hay una serie de elementos clave que se aplican a todos los casos. Uno de ellos es el archivo web.config (consulte la figura 1). Web.config es un punto de intersección entre el equipo de desarrollo y el equipo de red. Unas veces lo configuran los desarrolladores y otras el personal de red. De cualquier manera, el contenido de web.config limita la configuración de hardware y de red y afecta directamente al modo de funcionamiento de la aplicación. El análisis de cada pequeño aspecto del archivo web.config daría para escribir un libro. La cuestión es que ambos grupos deben estudiar el archivo web.config y ponerse de acuerdo en lo que significa lo que representa la configuración, así como en las repercusiones que tendrán las distintas configuraciones en la aplicación y en el entorno.
Figura 1 Archivo web.config que muestra algunas configuraciones de aplicaciones y la configuración de errores personalizados (haga clic en la imagen para ampliarla)
Por ejemplo, la sección <authorization> de web.config especifica el modo en que los usuarios se autenticarán en la aplicación y, de este modo, define una dependencia. Si la aplicación usa la autenticación de Windows®, dependerá de Active Directory®. Si usa autenticación basada en formularios, la dependencia será de un almacén de datos de cuentas de usuario. Está claro que a este tema le vendría bien una reunión.
Merece la pena tener en cuenta la sección <customErrors>, ya que afecta al modo en que el error se presenta a los usuarios. No se trata de una configuración compleja, pero una reunión podría ayudar a comprender cómo van a ser las páginas de error. Es probable que al principio del ciclo de vida colaborativo no haya páginas de error personalizadas,... una reunión más.
La sección <appSettings> de web.config puede ser particularmente importante. Normalmente los desarrolladores usan esta sección para ocultar valores globales como cadenas de conexión para bases de datos. Es un gran origen de dependencias y una parte clave en la planificación de la conmutación por error, la migración, etc. Pero como la sección <appSettings> es completamente personalizable, puede contener prácticamente de todo y es posible que sean necesarias muchas explicaciones para entender todo su contenido. En esta sección es habitual dejar huérfanos, es decir, valores que realmente no se usan en ninguna parte de la aplicación.
Aunque los desarrolladores no usen la sección <appSettings>, es posible que el personal de red/operaciones si quiera que lo hagan (tener todas las cadenas de conexión de base de datos en la sección es una forma eficaz de crear una estrategia sencilla de conmutación por error). Si el servidor de base de datos se queda inactivo, se puede insertar una cadena de sustitución que apunte a otro servidor de base de datos. Si se aprovecha esta oportunidad al principio del ciclo de desarrollo, se puede incrementar la confiabilidad y la capacidad de mantenimiento de la aplicación.
Finalmente, debe tener en cuenta un valor absolutamente clave en web.config desde el punto de vista del escalado: la etiqueta <sessionState>, que determina dónde se guardarán los datos de sesión para la aplicación. De forma predeterminada, los datos de sesión se almacenan "InProc" o en el espacio de proceso de la aplicación ASP.NET. Si los datos de sesión están configurados para proceso interno, significa que todo el equilibrio de carga debe ser "adherente": a un determinado usuario siempre le debe atender el mismo servidor, donde se encuentran los datos de sesión. Se trata de una conversación intensa entre los desarrolladores y el personal de red, porque afecta directamente al modo en que se escala y en que se realiza la conmutación por error. Hablar en un primer momento de esto puede ahorrar muchos quebraderos de cabeza a la hora de depurar la aplicación.
Cuando la conversación llegue al tema del estado de sesión, se desplazará tranquilamente hacia los requisitos de equilibrio de carga de la aplicación en general. Algunos entornos tienen hardware de equilibrio de carga dedicado con características específicas, pero si la aplicación no puede controlar estas características, no van a tener mucho sentido. Me he encontrado en situaciones en las que el equilibrio de la carga de hardware se ha usado con una aplicación ASP.NET que tenía datos de sesión en proceso. La consecuencia era la pérdida ocasional de sesiones sin explicación alguna. Parecía como si hubiera un error en la aplicación, pero no era así. En realidad se trataba de un error de configuración.
El personal de red necesita que el equipo de desarrollo le explique exactamente los esquemas de equilibrio de carga que funcionarán para la aplicación. Es en gran medida una conversación en dos sentidos acerca de los esquemas de equilibrio de carga que están disponibles y lo que puede tolerar la aplicación. Una gran ventaja de tener la conversación al principio del ciclo de vida de la aplicación es que se puede planear con antelación el cambio a un esquema de equilibrio de carga fuera de proceso sin afinidad.
Cuando una aplicación ASP.NET está lista para la implementación (o ya está en su implementación inicial), el personal de desarrollo tendrá una idea bastante clara de las áreas de la aplicación que son rápidas y las que son lentas. Y lo que es más importante es que conocerán los cuellos de botella o los posibles puntos de crisis en el sistema. Si el equipo de red/operaciones conoce los cuellos de botella, pueden prepararse con antelación para hacer frente a problemas y, tal vez, evitarlos.
Por ejemplo, una vez trabajé con una aplicación que realizaba un proceso de carga masiva de datos cada noche, durante el tiempo de inactividad de la aplicación. Los desarrolladores crearon el mecanismo de carga de datos, lo probaron y comprendieron su funcionamiento. Sabían que producía mucho estrés para la base de datos, pero se trataba de una forma efectiva de solucionar el problema.
Pero nunca le dijeron al equipo de red que se realizaba este proceso o que lo habían programado para que se ejecutara a la 1:00 a.m., exactamente la misma hora a la que se ejecutaban las copias de seguridad de base de datos. La base de datos permanecía en línea, pero se ejecutaba mucho más lentamente durante la hora de la copia de seguridad, ya que todas las transacciones que estaban enviando a la base de datos se mantenían en el registro de transacciones.
El conflicto sólo se identificó cuando se agotó el espacio en disco del volumen de registro de transacciones de base de datos, debido a la combinación simultánea de la carga de datos y de la copia de seguridad. Al cambiar la hora de la carga de datos a las 3:00 a.m., el problema se resolvió, pero sólo después de varios días de crisis.
Hablar al principio del proceso acerca de este tipo de cuestiones de carga de trabajo en la aplicación puede ahorrar muchos problemas posteriores.

Lo que el equipo de desarrollo necesita saber del equipo de red
Mi punto de partida favorito en la parte de la reunión donde el personal de red explica su mundo al personal de desarrollo es el diagrama de la red. Con demasiada frecuencia, los desarrolladores ven la red como en la figura 2, es decir, no ven ninguna red, simplemente servidores web, exploradores e Internet.
Figura 2 Visión simple del desarrollador sobre la red (haga clic en la imagen para ampliarla)
La realidad, evidentemente, es mucha más compleja. Un diagrama como la figura 3 se asemeja más a la verdad, aunque esté simplificado. Al observar la figura 3, inmediatamente se plantean muchas preguntas como, por ejemplo, "cómo trabajarán los usuarios de redes privadas virtuales (VPN) con la aplicación" o "cuál es la diferencia de autenticación entre un usuario interno y otro público", etc.
Figura 3 Red real que los desarrolladores deben comprender (haga clic en la imagen para ampliarla)
Evidentemente, no basta con proporcionar un diagrama de red. También es importante explicar la red en detalle porque es imposible saber, con tan solo mirar un diagrama, qué elementos afectarán a la aplicación. Es necesario hablar del proceso de conexión real de un usuario público, un usuario VPN y un usuario interno. El debate sobre las distintas reglas de firewall que existen, especialmente en arquitecturas de red de tipo DMZ más complejas, planteará de forma natural posibles problemas para la aplicación.
Evidentemente, será beneficioso tener todas estas conversaciones antes de que se haya implementado la aplicación, incluso antes de que se inicie el desarrollo; pero, a pesar de todo, la conversación se tiene que producir finalmente y es fundamental que alguien en reunión entienda perfectamente el diagrama de toda la red.
La red también es el escenario de modelos de conmutación por error y de redundancia, pero sin algún tipo de soporte técnico del software o al menos el conocimiento del comportamiento, estos modelos rara vez funcionan según lo planeado. Es necesario celebrar una reunión acerca de cómo serán los distintos escenarios de conmutación por error. El hecho de que haya clústeres en la base de datos afectará al código relacionado con el acceso a la base de datos. Por ejemplo, ¿se pueden reintentar las consultas después de un cambio de servidor? Si está disponible un sitio redundante, ¿cómo se van a replicar los datos en el sitio? ¿Cómo se realizará el cambio de un sitio a otro?
Se puede ver una vez más que una reunión al principio del proceso sirve de ayuda, si bien es verdad que más vale tarde que nunca. Todas las personas implicadas en la aplicación deben entender estas cuestiones. No hay nada más frustrante que tener una solución de conmutación por error que no funcione realmente cuando se necesita.
Por último, hay un otro recurso de red clave que se debe compartir: los registros de producción. Siempre recomiendo que los registros de producción estén disponibles para el equipo de desarrollo. La respuesta típica del personal de red ante esta solicitud es: "Pídemelos y te los enviaré". No considero que esto sea adecuado. Resulta mucho más efectivo dar a los desarrolladores la capacidad de que puedan recuperar los registros, normalmente desde un sitio de copia de seguridad.
Los registros de producción son esenciales durante una crisis. Con frecuencia constituyen la mejor (y única) fuente de datos reales y empíricos sobre lo que ha sucedido realmente. Pero también son valiosos en circunstancias más normales. Cuando los desarrolladores tienen acceso rutinario a los registros de producción, pueden consultarlos para comprobar el comportamiento de una nueva característica. Esto es una forma fantástica para averiguar que la característica no hace lo previsto y corregir el problema antes de que se convierta en una crisis. Si todo el mundo tiene acceso a los registros, se puede reaccionar más rápidamente a los problemas y corregirlos antes.

Volver al escalado
La reunión entre el equipo de red y el equipo de desarrollo gira entorno a la comprensión del alcance completo de los problemas que rodean al escalado de una aplicación ASP.NET. El entorno real en el que funciona la aplicación afecta directamente al modo en que funcionará el código que ejecuta la aplicación. Todas las estrategias de escalado afectarán a su comportamiento en el entorno. La aplicación de una estrategia de especialización, como la separación de las partes relacionadas con SSL de la aplicación, puede requerir cambios en el entorno de red y, seguramente, cambios en los propios servidores.
Incluso un cambio aparentemente centrado en el código, como el uso de almacenamiento en caché, puede afectar al entorno. Esto se debe a que al agregar el almacenamiento en caché de los datos a la aplicación ASP.NET, se reduce el número de llamadas de base de datos a cambio de un aumento en el uso de memoria. El resultado es que puede aumentar el número de servidores ASP.NET necesarios, o aumentar el número de reciclajes de subprocesos de trabajo, lo que activaría eventos de supervisión de la red.
El escalado de la aplicación ASP.NET afecta tanto al equipo de desarrollo como al de red, por lo que merece la pena que participen ambos grupos en el proceso de toma de decisiones. A menudo la colaboración dará como resultado soluciones originales que los equipos no habrían descubierto al trabajar de forma independiente. Por ejemplo, el personal de red puede darse cuenta de que existen soluciones de hardware en la compañía que pueden resultar útiles para que los desarrolladores cumplan los requisitos de rendimiento y escalado. Este tipo de oportunidades se ponen de manifiesto al hablar de los detalles de la aplicación y del entorno.

El bombardeo cooperativo
Recursos para escalar aplicaciones ASP.NET

  • Desarrollar aplicaciones ASP.NET de alto rendimiento
  • Procedimientos: Escalar aplicaciones .NET
  • Procedimientos: Optimizar y escalar el rendimiento de las aplicaciones que se basan en .NET Framework
  • Implementar una arquitectura escalable
  • Maximizar el rendimiento de IIS
  • Estrategias de escalado para aplicaciones ASP.NET
Una crisis en el escalado no tiene porque ser algo malo. De hecho, normalmente es algo bueno ya que se produce cuando un gran número de usuarios desea ejecutar la aplicación, poniendo así a prueba el valor de la aplicación. Eso sí, hay que hacer que funcione.
En ocasiones, las crisis de escalado se producen por cualquier otro evento, tal vez su compañía está realizando una promoción o alguien ha escrito sobre usted en un blog o quizás un sitio de red social ha dirigido una gran cantidad de personas a su sitio web al mismo tiempo. De repente, se encuentra en medio de un bombardeo intentando mantener la aplicación en funcionamiento. Como habrá adivinado, lo mejor es analizar este tipo de escenarios antes de que se produzcan realmente. Así que nada mejor para cerrar la reunión entre los desarrolladores y el personal de red que una demostración de cómo la colaboración entre ambos equipos puede ayudar a una organización a superar este tipo de crisis.
La primera cuestión que surge al gestionar la crisis es "¿cómo se detecta que el sitio está sucumbiendo bajo carga?". Con demasiada frecuencia la respuesta es "tenemos una llamada del director técnico". Si la primera señal de que el sitio web tiene problemas es una llamada de alguien externo, entonces puede empezar a preocuparse. Algún sistema de medición decente debería notificarle los problemas antes de que suene el teléfono. Aunque eso no impediría que suene el teléfono, al menos le dará cierta ventaja a la hora de responder. Una respuesta del tipo "¿ah, sí?" al director técnico no es una forma de progresar profesionalmente.
Siguiente pregunta: ¿a quién se llama primero? ¿Quién responde al evento? Normalmente alguien del personal de red recibe la primera advertencia y es posible que esa persona sea relativamente inexperta, por lo que es necesario establecer un plan de escalado de problemas claro. ¿A quién se llama después? El reto es efectuar un diagnóstico rápido lo antes posible para averiguar el tipo de problema que se está produciendo. Una cosa es cuando se trata de una interrupción de la red y otra cosa bien distinta es un problema de escalado. Con los problemas de escalado, se recomienda que alguien del equipo de desarrollo intervenga lo antes posible.
Todos los implicados en el bombardeo necesitan disponer de información valiosa, por lo que los derechos de acceso efectivos son clave. El objetivo es difundir tanta información como se posible para poder efectuar un diagnóstico efectivo y esto, a la larga, debe establecer el alcance de la solución.
A menudo, si la única respuesta es escribir código, el evento habrá acabado antes de que se pueda escribir código. Evidentemente, el evento se debe tener en cuenta para modelar las prioridades de desarrollo en el futuro, pero no es razonable (ni inteligente) intentar escribir un montón de código y ponerlo en producción sin realizar pruebas cuidadosas. Regla número 1 de cualquier bombardeo: no empeorarlo.
Cuando se trata de problemas de escalado, la solución a veces consiste en esperar simplemente a que desaparezcan. Pero sigue siendo una decisión que se puede tomar.
Al mismo tiempo, la planificación de estas contingencias significa que se pueden aplicar distintas técnicas rápidamente. Resulta increíble ver el poco tiempo que demora solucionar un problema de escalado cuando trabajan conjuntamente los recursos de red y de desarrollo, incluso podrían ser lo suficientemente eficaces como para que el evento promocional previsto tenga realmente éxito.
Como conclusión, la lección aprendida por el equipo de red es que una aplicación ASP.NET de alto escalado y buen rendimiento supone una colaboración con éxito entre las personas que crean la aplicación y las que la implementan y usan.
La colaboración es inevitable, por lo que lo mejor es comenzar cuanto antes las reuniones entre los equipos para compartir información. El objetivo de las reuniones es crear conocimiento y consenso para todos los elementos de la aplicación: lo que hace, cómo funciona, de qué depende, cómo se comporta bajo carga y cómo afronta los problemas que van surgiendo a lo largo del tiempo.
Cuando se obtiene una colaboración realmente efectiva, el resultado es una compañía más ágil, con gran capacidad de respuesta ante problemas y que puede comunicar los objetivos claros acerca de lo que la aplicación necesita para tener éxito en el futuro.

Richard Campbell es director regional de Microsoft, MVP en ASP.NET y uno de los presentadores de .NET Rocks, el programa de entrevistas en Internet para desarrolladores .NET (visite dotnetrocks.com). Richard lleva años asesorando a compañías sobre el rendimiento y el escalado de ASP.NET y también es uno de los cofundadores de Strangeloop Networks.


Nota del editor En vivo desde Tech•Ed
Joshua Hoffman

Siempre me resulta algo complicado el momento en que me siento a escribir la Nota del editor de cada mes. Proponer un tema generalmente no es difícil, ya que siempre hay muchas cosas interesantes sobre las que hablar. Lo que ocurre realmente es que las Notas del editor se tienen que escribir casi seis semanas antes de que casi nadie las lea (en parte para que tengamos tiempo de imprimir la revista, pero sobre todo para que los correctores dispongan de todo el tiempo necesario para corregir todos mis errores). A diferencia de los blogs, que pueden reaccionar al momento, resulta difícil escribir acerca de "noticias" en esta situación, ya que cuando se leen, han dejado de ser noticia.
Y sin embargo, aquí estoy, en la feria de Tech•Ed 2008, en un Orlando "soleado", y esto es lo más importante que sucede en nuestro sector en este momento. De modo que aunque esto ya no sea noticia de última hora cuando lo lea,... pues… mala suerte.
Para nosotros, Tech•Ed es un evento fascinante por varios motivos. Se trata uno de los únicos momentos del año en que coincidimos con muchos de nuestros lectores (e incluso con nuestros autores) en persona. Es verdad que tenemos la satisfacción de estar en contacto a lo largo del año mediante correo electrónico, mensajería instantánea y llamadas telefónicas, pero no se puede comparar con la lluvia de ideas y conversaciones interesantes que surgen en un acontecimiento en el que se congregan tantas personas.
Tech•Ed también es una buena oportunidad para echar un vistazo a lo que ocurrirá el próximo año. Los ejecutivos estarán aquí dirigiendo la estrategia de conjunto, que por supuesto es informativa. Se hablará mucho acerca de las nuevas direcciones que tomará la virtualización, la próxima generación de la Web, los conceptos revolucionarios en administración de sistemas y otras muchas cosas.
Sin embargo, yo estoy aquí por los temas fundamentales. Mark Russinovich, técnico en Microsoft y redactor colaborador, realizará una charla sobre la redefinición de los límites de seguridad. Steve Riley, otro redactor colaborador, hablará de la desaparición total de los límites de red, un concepto realmente emocionante e innovador. Mark Minasi, Romi Mahajan, Dharmesh Godha y yo abordaremos en una mesa redonda la aproximación al consumidor de las TI.
También explicaré lo que hay que hacer para empezar a escribir en TechNet Magazine. Siempre me ha resultado muy gratificante dar esta charla y además ha servido de inspiración para más de un autor novel. Cuando lea este artículo, podrá consultar las diapositivas de mi charla en nuestro blog en blogs.technet.com/tnmag. Écheles un vistazo. ¿Quién sabe? Quizás asista al próximo Tech•Ed como uno de nuestros autores.
¡Y no se olvide de las fiestas de Tech•Ed! También nos encantan las fiestas.
—Joshua Hoffman

Mi agradecimiento a los siguientes expertos de Microsoft: Sunil Agarwal, Eric Charran, Trina Gorman, Sanjeev Nair, Isaac Roybal, Jez Sadler, Roger Sprague, Stefan Stranger, Kevin Sullivan, Jim Truher, Alan von Weltin, Michael Walsh y Buck Woody.


Cartas Comentarios de los lectores

Tipos de contenido de SharePoint
Busco información que me ofrezca una vista detallada acerca del uso de tipos de contenido en Microsoft® SharePoint®. ¿Dónde puedo encontrar esa información?
—E.A.

Una buena fuente de información es el blog del equipo de tecnologías y productos de Microsoft SharePoint (disponible en blogs.msdn.com/sharepoint). Por otra parte, Pav Cherny ha escrito un artículo acerca de la estandarización de la administración de datos con tipos de contenido personalizados que puede encontrar en technet.microsoft.com/magazine/cc194408. Hay unas notas del producto acerca de la administración de metadatos empresariales que pueden resultarle útiles y que están disponibles en technet.microsoft.com/library/cc262729.
Otro recurso que puede explorar es el blog de Andrew May en blogs.msdn.com/andrew_may. Andrew es programador y escritor en Microsoft y se encarga de redactar la documentación para desarrolladores relacionada con las características de administración de contenido empresarial en Windows® SharePoint Services 3.0 y Microsoft Office SharePoint Server 2007. En su blog escribe acerca de los tipos de contenido y ofrece pósteres de ilustraciones técnicas que tratan los tipos de contenido y explican aspectos más complicados de la administración de contenido empresarial en un entorno de SharePoint.

Llevar la seguridad más lejos
Me encantó el artículo "El gran debate: la seguridad por oscuridad" (junio de 2008, technet.microsoft.com/magazine/cc510319). Sin embargo, me decepcionó un poco que todo girara entorno al cambio del nombre del administrador. Comparto en gran medida la opinión de Roger Grimes y Aaron Margosis acerca del nombre del administrador porque, efectivamente, eso es mejor que nada y además crea menos quebraderos de cabeza en las tareas de administración. Hay sin embargo otros muchos retos fascinantes: se mencionaron los recursos compartidos administrativos y, aunque el grupo no entró en mucho detalle, este tipo de recursos generan algunos problemas graves para la administración cuando se bloquean.
Me gustaría asimismo que este grupo debatiese sobre los inconvenientes y ventajas de los intentos de "reducir la superficie de ataques". La reducción de la superficie de ataques es una ligera variante de la seguridad por oscuridad porque la mayoría de las cosas que quita la gente es cerrando todo lo que difunda la ubicación o la identidad. Por ejemplo, tengo muchos clientes que quitan IPv6 en nombre de la seguridad por oscuridad. El procedimiento de eliminación de servicios se asemeja a menudo al que utilizaban los médicos en la Edad Media: cerrar los ojos, llegar hasta la herida y rezar para que no se muera el paciente.
—Shelly B.

Estamos totalmente de acuerdo con usted acerca del enfoque restrictivo que se dio en el artículo sobre el cambio del nombre del administrador. En los primeros borradores se incluyeron otros ejemplos, pero el artículo habría tenido 20 páginas si no lo hubiéramos recortado. Así que decidimos centrarnos en un ejemplo y resultó que el tema de la cuenta de administrador era el que más se mencionaba. Pero no se preocupe, ya hemos empezado a amenazar a los autores para que escriban más acerca del tema que menciona en un futuro próximo.

No lo suficientemente oscuro
"El gran debate: seguridad por oscuridad" fue un buen artículo. Pensando en él me di cuenta de dos cosas. En primer lugar, creo que la oscuridad es algo bueno, siempre y cuando el rendimiento de la inversión (ROI) en oscuridad sea lo suficientemente elevado. En segundo lugar, me di cuenta que gran parte de la seguridad de TI siempre ha tenido un componente de oscuridad.
Tomemos como ejemplo las contraseñas. Con el paso del tiempo, las contraseñas se han ido haciendo más oscuras. Al principio, la mayoría de los equipos no requerían contraseña. Después, a medida que los equipos estaban más conectados, bastaba con una simple contraseña. Conforme aumentó la conectividad, se consideró que era importante que una contraseña tuviera como mínimo ocho caracteres. Cuando esa solución ya no era lo suficientemente segura, tuvimos que recurrir a la combinación de caracteres y, más adelante, a frases de contraseña, etc. Sospecho que descubriremos que nuestras protecciones oscuras de toda la vida seguirán siendo lo "insuficientemente" oscuras.
—Tom B.

Tom, gracias por sus comentarios agudos. Será fascinante ver cómo evoluciona esta tendencia, en concreto a medida que los conceptos de seguridad como la autenticación multifactor (tarjetas inteligentes con contraseñas, por ejemplo) sean más habituales.

Pósteres de TechNet Magazine
Desearía obtener los pósteres de Microsoft que se han incluido en unos números de TechNet Magazine para los desarrolladores de mi compañía. ¿Me podría indicar cómo comprarlos?
—Helen G.

Los tres pósteres disponibles son: Arquitectura de componentes de Microsoft Exchange Server 2007, Componentes de características de Windows Server® 2008 Active Directory® y Componentes de características de Windows Server 2008. Para comprarlos llame al 800-444-4881 (EE. UU. y Canadá) o al 785-838-7500 (resto de países).


Cuadro de herramientas Nuevos productos para profesionales de TI
Greg Steen

Supervisar los servidores
PA Server Monitor Pro
poweradmin.com/servermonitor
Necesita controlar todas las partes de su infraestructura. Saber que algo no funciona antes que los usuarios finales es esencial para el control de daños y para las comunicaciones. Además, no es muy divertido tener al jefe vigilándole constantemente. PA Server Monitor Professional Edition de Power Admin LLC es una herramienta que le ayudará a controlar la infraestructura de servidores.
Poner en funcionamiento y ejecutar PA Server Monitor es relativamente sencillo, sobre todo la característica integrada Smart Configuration Process, que permite detectar equipos en la LAN y configurar de forma automática un conjunto de monitores para cada uno de los equipos. Si no le interesa realizar el proceso de detección, puede importar una lista de equipos para los que desee configurar comprobaciones de supervisión. Una vez configurado un equipo, puede exportar dicha configuración mediante la GUI para usarla como plantilla en otros equipos o como copia de seguridad en caso de que necesite efectuar una reinstalación.
PA Server Monitor ofrece 18 monitores diferentes que puede asignar a cada uno de los servidores. Estos monitores incluyen comprobaciones estándar como supervisar el espacio en disco, los errores del registro de eventos, la ejecución remota de scripts, los cambios de archivos y directorios, el uso de CPU y memoria, la respuesta del Protocolo de mensajes de control de Internet (ping) y el estado de los servicios de Windows®.
Hay otros monitores especialmente útiles, incluida la supervisión de puertos TCP, que pueden supervisar el estado básico de puertos y enviar además texto de comando y comprobar la respuesta en función de un valor predeterminado. Con la supervisión de archivos de registro puede comprobar un archivo de registro para buscar un caso del texto que puede definir como una expresión regular o texto sencillo. Un monitor de cuota de directorio le permite asegurarse que los usuarios finales no exceden sus límites y que les notificará a través del correo electrónico cuando superen las cuotas establecidas. Puede supervisar la ejecución de scripts para cualquier tarea personalizada que desee ejecutar. Por último, puede usar la supervisión de antigüedad de archivo para comprobar la cola de correo y asegurarse de que no se realizan copias de seguridad de la misma.
Una vez definido un monitor para un servidor, debe definir la acción que se llevará a cabo cuando se alcance el umbral del monitor. PA Server Monitor ofrece 15 acciones integradas, entre las que se incluyen el correo electrónico, el registro de eventos, los cuadros de mensaje, los archivos de registro, el reinicio de servicios, el Protocolo simple de paginación de red (SNPP) y los scripts personalizados para acciones personalizadas. Al definir las acciones, también puede definir una cadena de escalado de acciones, que llevará a cabo acciones adicionales si el monitor permanece en un estado de error durante un período de tiempo mayor que el especificado. Por ejemplo, puede establecer una acción para reiniciar primero el sitio web de forma automática. Después, si al cabo de otros cinco minutos sigue habiendo un error en la comprobación, se enviará un mensaje de correo electrónico a su dispositivo portátil para notificarle sobre el estado del sitio.
A lo largo del tiempo es probable que desee consultar las estadísticas de los monitores configurados. PA Server Monitor tiene características de elaboración de informes integradas para ayudarle a obtener la información necesaria. Los informes integrados incluyen un resumen de servidor que muestra las estadísticas y el estado de un servidor concreto, un resumen general que proporciona una línea sobre cada uno de los equipos supervisados, y un mapa de estado gráfico que muestra los indicadores de estado de instalaciones dispersas geográficamente. Los informes se generan en HTML para poder tener acceso a ellos con un explorador web, dando así un toque agradable al centro de operaciones. Asimismo, puede generar informes ad hoc con diagramas y gráficos sencillos, o exportarlos a un archivo CSV para su uso posterior. Los informes también se pueden programar a fin de que la aplicación le envíe directamente a usted por correo electrónico de forma automática las últimas estadísticas de los servidores con regularidad.
PA Server Monitor no tiene agentes. Una indudable ventaja es que puede empezar a usarlo rápidamente, siempre que el contexto de servicio de la aplicación se ejecute con la suficiente autoridad para conectarse a los equipos de la red que se ejecutan a través de Instrumental de administración de Windows (WMI) y de otros servicios administrativos remotos, como la llamada a procedimiento remoto (RPC). Sin embargo, uno de los inconvenientes que presenta es el elevado nivel de cuenta que necesita para conectarse con los equipos remotos. Por supuesto, hay otros tipos de monitores de protocolo de servidor, incluidos HTTP y SMTP, que no requieren permisos elevados.
Otro posible inconveniente es que la conexión a equipos a través de una topología de red e infraestructura compleja y dispersa puede resultar difícil y dependerá de la confianza de la red y del dominio. Al fin y al cabo, el funcionamiento de este enfoque sin agente en su entorno dependerá del diseño de la infraestructura y de lo que desee hacer exactamente con la solución de supervisión de servidores.
Precio: 99 dólares (venta directa) para 20 monitores activos o 349 dólares (venta directa) para 100 monitores activos.
Controlar los servidores con PA Server Monitor Professional Edition (haga clic en la imagen para ampliarla)

Limpiar los archivos duplicados
dupeGuru
hardcoded.net/dupeguru
Si trabaja con usuarios finales o administra espacio en disco de usuario compartido, seguramente habrá observado que el espacio de usuario se desorganiza mucho con el paso del tiempo. Esto se debe normalmente a que un solo usuario guarda el mismo archivo en varios lugares o incluso a que muchos usuarios guardan el mismo archivo en varias ubicaciones. Un buscador de duplicados puede convertirse en una herramienta imprescindible a la hora de consolidar y limpiar ese espacio de usuario. Una buena solución es dupeGuru de Hardcoded Software.
Esta herramienta busca duplicados en la carpeta o unidad de disco de destino, examinando los nombres de archivo y el contenido. Pero dupeGuru va más allá de la simple comparación de cadenas, ya que usa un algoritmo de coincidencia aproximada para encontrar duplicados que, de otro modo, se omitirían. Una vez seleccionados los duplicados, puede enviarlos a la papelera de reciclaje, eliminarlos para siempre, moverlos a otra carpeta o abrirlos con la aplicación predeterminada para efectuar una comprobación final. Si lo desea, puede exportar los resultados a XHTML para revisarlos más adelante.
En las preferencias, puede decidir la rigurosidad con la que desea que el filtro de nombre y contenido de archivo actúe al examinar los archivos. Esto permite aumentar el número de duplicados encontrados, aunque también incrementará la probabilidad de detectar una coincidencia positiva falsa. dupeGuru tiene además la capacidad de marcar todos los duplicados que contienen una determinada palabra en el nombre de archivo. Esto puede resultar útil para encontrar todos los archivos "Copia de" creados accidentalmente por los usuarios, así como las carpetas vacías denominadas "Nueva carpeta" diseminadas por los directorios.
Hay versiones disponibles para Windows 2000 (y posteriores) y para Mac OS X. Si desea reducir el número de duplicados de su música o fotos, eche un vistazo a las versiones adaptadas dupeGuru ME y dupeGuru PE respectivamente.
Precio: 19,95 dólares (venta directa).
Limpiar los archivos duplicados con dupeGuru (haga clic en la imagen para ampliarla)

Controlar el entorno
pt360 Tool Suite PRO
packettrap.com
Puede resultar muy ventajoso disponer de una interfaz única que le permita ver y administrar una serie de herramientas de supervisión y administración de red. Además de ahorrarle mucho tiempo (y espacio en el escritorio), un conjunto de programas integrado puede facilitar el uso compartido de datos entre las distintas herramientas de supervisión, a la vez que le permite analizar numerosos monitores a la vez, con lo que obtiene una vista más completa del estado de su infraestructura.
Si le gusta como suena esto, eche un vistazo a pt360 Tool Suite PRO de PacketTrap Networks. Esta aplicación ofrece una interfaz de usuario integrada para las herramientas de PacketTrap Networks, así como capacidades de elaboración de informes consolidados y centralización. Puede crear y organizar la vista de herramientas en un panel personalizado para obtener acceso inmediato a las herramientas más usadas y a la información de estado de la infraestructura. El panel pt360 también tiene la capacidad de mostrarse en modo de pantalla completa. Esto es perfecto para el centro de operaciones, ya que permite a cualquier miembro del equipo consultar la pantalla rápidamente y ver el estado de los distintos recursos de red y de servidor. La aplicación admite múltiples paneles, por lo que puede crear varias vistas del entorno en función de sus necesidades.
Para configurar un panel, sólo tiene que seleccionar una serie de gadgets en una lista desplegable y hacer clic en cada uno de ellos para configurarlos. Los gadgets se agrupan en cinco categorías (Application, Networking, Devices, Availability y Other) y se basan en SNMP (Protocolo simple de administración de red) y WMI para supervisar los servidores, las aplicaciones y los dispositivos de red. Los gadgets de Application ofrecen enlaces a Active Directory®, Microsoft® Exchange Server y SQL Server®, además de proporcionar una herramienta de explorador. Los gadgets de Networking ofrecen información detallada sobre interfaces de dispositivo y proporcionan las 10 vistas principales sobre la pérdida media de paquetes, la máxima latencia y el uso de interfaz por cliente. Los gadgets de Device proporcionan indicadores de rendimiento sobre el uso de CPU y de memoria, el espacio disponible en disco, las listas de volúmenes, el uso de la interfaz de red y mucho más. Resultan excelentes para controlar el modo en que los servidores actúan en tiempo real mediante sus consultas WMI configurables. Los monitores de Availability muestran el tiempo de actividad de los equipos en forma de gráfico, indicador, texto o lista. Y, por último, el gadget Other incluye un reloj digital grande.
Además del panel, el conjunto de herramientas de pt360 incluye herramientas de red. Por ejemplo, dispone de Cisco Configurator. Esta herramienta permite archivar, modificar, cargar, descargar y comparar archivos de configuración de los equipos de Cisco. Asimismo incluye tres herramientas ping distintas: una ofrece una vista de tabla que se puede ordenar, otra muestra una vista gráfica y la última permite realizar un análisis de ping rápidamente en un grupo de direcciones IP. Otros tipos de herramientas de análisis que tiene a su disposición son un escáner de direcciones MAC, una herramienta de análisis de puertos y una herramienta de análisis de WMI.
El conjunto de herramientas también puede actuar como servidor syslog y enviar, recibir, registrar y mostrar mensajes syslog de cualquier dispositivo de la red que admita syslog. La presentación también admite filtros, por lo que puede aislar fácilmente mensajes de problemas, acelerando así el proceso solución de problemas.
El conjunto de programas funciona como un servidor TFTP (Protocolo trivial de transferencia de archivos) y le permite mover rápidamente archivos de y a dispositivos de la red. Otras herramientas incluyen capacidades de enrutamiento de seguimiento, Whois y Wake On LAN. Evidentemente, como se trata de una solución de administración centralizada con conexiones a los hosts mediante WMI y SNMP, es fundamental el modo en que el conjunto de programas almacena sus credenciales para la conexión. Afortunadamente, el conjunto de programas usa un almacén de credenciales cifrado con AES (Estándar de cifrado avanzado) de 256 bits en el que puede agregar, actualizar y eliminar la información necesaria para supervisar la infraestructura.
Precio: 999 dólares (venta directa) para una única licencia.
Figura 36 Supervisión de sistemas con pt360 Tool Suite PRO

Administrar el uso de disco
TreeSize Professional
jam-software.com/treesize/index.shtml
"¿Qué es lo está ocupando todo el espacio en disco del servidor?" ¿Le suena este tipo de queja? Su aplicación de supervisión le acaba de enviar un mensaje de correo electrónico que le notifica que se ha alcanzado el umbral de poco espacio en disco. Bien, ahora se preguntará qué tiene que hacer para limpiar ese equipo. Y cómo condenar rápidamente al culpable a "Mayús-Supr" (es el acceso directo rápido para pasar por alto la papelera de reciclaje). TreeSize Professional de JAM Software es una herramienta que puede ayudarle en la búsqueda de una solución para la supervisión del host.
La aplicación se ejecuta en Windows 2000 y versiones posteriores para las versiones de 32 y 64 bits de Windows, y ofrece una visión detallada de los archivos que ocupan espacio en las unidades. Todo lo que tiene que hacer es seleccionar la unidad de disco que va a interrogar y la aplicación analizará la estructura de carpetas de forma automática. Una vez completada esta acción, tendrá acceso a siete vistas distintas de la unidad. La primera es la vista Chart con tres gráficos distintos para que pueda analizarlos: un gráfico circular, un gráfico de barras y un gráfico de cuadros de tamaños proporcionales. Cada uno de estos gráficos permite examinar en profundidad cada una de las carpetas para identificar rápidamente los devoradores de espacio. Asimismo, puede personalizar los colores y el estilo de los gráficos.
La siguiente vista es Detail, que proporciona una vista de tabla de archivos que se puede ordenar y que le permite elegir el tipo de presentación para las columnas. Las selecciones más destacadas entre los usuarios incluyen el autor de los archivos de Microsoft Office, el tamaño promedio de archivo en una carpeta, el porcentaje que ocupa en el directorio principal el archivo o carpeta y los vínculos físicos.
La vista Extensions indica los tipos de archivo que ocupan más espacio en cada directorio a medida que se examinan en profundidad las carpetas. La vista Users muestra la vista compuesta de la cantidad de espacio que ocupan los archivos de una cuenta de usuario o del sistema, lo que resulta fundamental para aislar a los usuarios problemáticos. La vista File Ages ofrece una vista gráfica de los porcentajes de archivos que se han modificado o creado, o a los que se ha tenido acceso el día, mes o año anterior (el intervalo de tiempo que prefiera). Esto permite identificar archivos antiguos para archivarlos o eliminarlos de forma segura. También está la vista Top 100 que identifica los 100 archivos de mayor tamaño en la unidad. Y por último está la vista History, que indica los patrones de uso de la unidad a lo largo del tiempo.
Cada una de las siete vistas se puede imprimir, guardar y copiar en el portapapeles para su uso posterior. Además, TreeSize acelera las tareas habituales de mantenimiento de limpieza mediante la barra de herramientas con la capacidad File Search, aislando los archivos de mayor tamaño, los archivos más antiguos, los archivos temporales, los archivos de caché de Internet y los archivos duplicados. TreeSize Professional también puede analizar la red mediante recursos compartidos UNC, pero hay una penalización de rendimiento importante debido a la sobrecarga de red que supone.
La aplicación también es compatible con un modo de línea de comandos. Esto es ideal para ejecuciones nocturnas y de programación. Asimismo, puede crear un análisis de tareas programadas, configurándolo para que analice una ruta y produzca un conjunto de informes según la programación estándar establecida. Esto resulta útil para supervisar el espacio del usuario compartido cada noche y controlar el modo en que se usa el espacio en disco.
Si se está preguntando cómo es posible que todo el terabyte de espacio del usuario ya esté lleno, tal vez TreeSize pueda ayudarle a ver cómo se usa el espacio en disco y empezar a administrarlo de una forma más eficaz.
Precio: 49,95 dólares (venta directa) para una única licencia.
Administrar el uso del disco con TreeSize Professional (haga clic en la imagen para ampliarla)

Greg Steen es un entusiasta empresario dedicado a las tecnologías. 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 SQL Particiones y comprobaciones de coherencia, entre otros temas
Paul S. Randal

P Accidentalmente, adjunté una base de datos de producción a un servidor SQL Server® 2005 y ahora estoy intentando adjuntarlo al servidor correcto, que usa SQL Server 2000. Lo he intentado simplemente separando la base de datos y adjuntándola al servidor SQL Server 2000, y también lo he probado con una copia de seguridad y una restauración, pero ninguno de estos dos métodos ha funcionado. ¿Por qué no funciona en mi servidor SQL Server 2000? Ésta es la única copia de la base de datos que tengo.
R La primera cosa que hay que tener en cuenta es la importancia de disponer de copias de seguridad. Los administradores de bases de datos suelen tener en mente la necesidad de realizar copias de seguridad para recuperar datos dañados o que han sufrido cualquier otro desastre. Pero usted ha dado con un problema menos evidente: algo ha fallado durante una actualización, aunque en este caso fuese una actualización accidental. La verdad es que siempre se debe tener una copia de seguridad completa y reciente de la base de datos por si a ésta le sucediera algo.
Una actualización, sea intencionada o accidental, es una operación en un solo sentido y es muy difícil invertir sus efectos. Cuando se actualiza entre versiones de SQL Server, se llevan a cabo una serie de pasos de actualización en la base de datos. Cada paso suele implicar algunos cambios físicos en la base de datos y el número de versión de la base de datos aumenta.
Por ejemplo, uno de los cambios más importantes que se realizan al actualizar una base de datos de SQL Server 2000 a SQL Server 2005 es el cambio de la estructura de catálogos del sistema de una base de datos (que se suelen denominar tablas del sistema o metadatos de la base de datos), que contienen distintos metadatos sobre tablas, índices, columnas, asignaciones y otros detalles con respecto a la estructura relacional y física de la base de datos.
A medida que se van llevando a cabo pasos de la actualización, el número de versión de la base de datos va aumentando. Por ejemplo, las bases de datos de SQL Server 7.0 tienen el número de versión 515, las bases de datos de SQL Server 2000 tienen el número de versión 539 y las bases de datos de SQL Server 2005 tienen el número de versión 611 (o 612 si la característica vardecimal está habilitada). De esta forma, SQL Server puede saber cuál fue el último paso de actualización realizado en la base de datos.
Las versiones de SQL Server no pueden leer bases de datos actualizadas a versiones más recientes de SQL Server (por ejemplo, SQL Server 2000 no puede leer una base de datos que se ha actualizado a SQL Server 2005). Esto ocurre porque las versiones anteriores no tienen el código necesario para interpretar el diseño de la base de datos ni las estructuras actualizadas. Y he aquí el problema con su base de datos, que se ha actualizado a SQL Server 2005 y por este motivo no se puede volver a adjuntar a SQL Server 2000.
Puesto que no dispone de una copia de seguridad de toda la base de datos, su única opción es exportar todos los datos de la base de datos actualizada y transferirlos manualmente a una nueva base de datos de SQL Server 2000. Siempre y cuando no haya usado ninguna característica nueva de SQL Server 2005, podrá crear la estructura de la base de datos, crear la base de datos en SQL Server 2000 y, finalmente, exportar o importar los datos.
Para crear la base de datos en SQL Server 2005, puede usar el Explorador de objetos de SQL Server Management Studio (haga clic con el botón secundario en la base de datos, seleccione Tareas y, a continuación, la opción de Generar secuencias de comandos). El asistente ofrece unas explicaciones muy claras y generará un script para crear todos los objetos, los índices, las restricciones, los desencadenadores, etc.
P Recientemente, hemos rediseñado nuestro esquema para usar particiones de tabla en la tabla principal, ya que hemos oído que de esta forma se mejora el rendimiento. La base de datos se almacena en una sola unidad de disco de 120 GB y la tabla se encuentra en un solo grupo de archivos. Las ventanas no se desplazan, sino que cada semana se van agregando particiones nuevas y todos los datos deben estar disponibles en línea. La mayoría de las consultas procesan datos de una sola semana y algunas buscan en los datos del último año. Parece más sencillo realizar esta operación en un solo grupo de archivos, ¿estoy en lo cierto o se me escapa algo?
R Aunque parezca más sencillo usar un solo grupo de archivos, si lo hace, es poco probable que pueda ver las ventajas de usar particiones. Los principales usos de las particiones son para un mantenimiento más eficaz de las bases de datos y para aumentar la disponibilidad de los datos en caso de un desastre, además se puede crear un esquema que optimice el rendimiento.
El ejemplo arquetípico de partición es para una tabla de ventas, con 12 particiones, cada una de las cuales representa los datos de las ventas de cada mes del año anterior. Al acabar el mes, la partición más antigua queda fuera (se archiva o se elimina) y entra una nueva partición. Éste es el entorno de ventanas que se desplazan al que hacía referencia. La partición del mes en curso es de lectura y escritura y los meses anteriores son de sólo lectura. Cada partición se almacena en un grupo de archivos independiente. Este esquema permite beneficiarse de todas las ventajas de las particiones, pero no es el mejor en todas las circunstancias.
Mi esposa, Kimberly, propuso un cambio en el esquema descrito más arriba que permite una indexación más eficaz. Supongamos que divide la tabla de ventas en dos tablas: una que contenga sólo la partición de lectura y escritura y otra que contenga las 11 particiones de sólo lectura, con una vista de particiones de ambas tablas.
Al hacerlo así, la tabla de lectura y escritura tiene un número inferior de índices, mientras que la tabla de sólo lectura puede tener más índices para permitir consultas de informes. Además, las operaciones de lenguaje de manipulación de datos (DML) en los datos de lectura y escritura son considerablemente más eficaces porque no tienen que mantener tantos índices no agrupados.
Así, las consultas de los datos de lectura y escritura no tendrán que procesar también los datos de sólo lectura. La eliminación de particiones en planes de consulta no es perfecta en SQL Server 2005, especialmente en casos con predicados complejos, pero ha mejorado mucho en SQL Server 2008. Para obtener más información, consulte el mensaje de Kimberly sobre este tema en el blog sqlskills.com/blogs/kimberly/default,month,2007-10.aspx#a71c70243-3d57-4940-9af7-a802b73f2f93.
Para mostrarle a lo que me refiero, le describiré algunas de las características que se habilitan al crear particiones de varios grupos de archivos.
Disponibilidad parcial de la base de datos Esta es la capacidad de una base de datos de estar en línea y ser accesible durante una situación de recuperación ante desastres siempre que el grupo de archivos principal esté en línea. Si sólo tiene un grupo de archivos, toda la base de datos estará inactiva mientras se realiza la restauración. Si los datos se encuentran en diversos grupos de archivos, sólo los grupos de archivos dañados estarán fuera de línea durante la restauración y su aplicación podrá seguir funcionando.
Restauración por etapas Este esquema es parecido a la disponibilidad parcial de la base de datos. Con un solo grupo de archivos, la unidad de restauración es una sola página o la base de datos completa. Con varios grupos de archivos, se puede restaurar sólo un grupo de archivos, con lo que la base de datos puede estar disponible parcialmente.
Mantenimiento de bases de datos con particiones Con cualquiera de los esquemas de particiones descritos más arriba se puede realizar la eliminación de fragmentación de índices por partición, incluso cuando todas las particiones se encuentran en un solo grupo de archivos. Pero con un solo grupo de archivos, se pierde la capacidad de realizar comprobaciones de coherencia por grupo de archivos, lo que puede reducir drásticamente la cantidad de datos que la comprobación de coherencia de la base de datos (DBCC) necesita para procesarse (y, a su vez, la cantidad de CPU y recursos de E/S que se usan).
En pocas palabras, aunque se pueden tener varias particiones dentro del mismo grupo de archivos, son muchas las ventajas de tener una correlación 1-1 entre particiones y grupos de archivos.
P Hace poco tiempo tuvimos un buen susto con uno de nuestros servidores de base de datos más moderno: una placa de memoria averiada estaba dañando datos. Lo descubrimos cuando empezaron a aparecer datos aleatorios en nuestra aplicación. Ejecutamos DBCC CHECKDB y encontramos todo tipo de daños. Por desgracia, también ocurrió en nuestras copias de seguridad, así que tuvimos que eliminar manualmente los datos incorrectos.
Para abreviar, reemplazamos el hardware averiado y activamos las sumas de comprobación de página. Nos gustaría realizar comprobaciones periódicas de coherencia pero no disponemos de una ventana de mantenimiento grande y nuestra base de datos de 2,4 TB tarda mucho tiempo en realizar comprobaciones. ¿Qué podemos hacer?
R La pregunta sobre cómo realizar comprobaciones de coherencia y otras operaciones de mantenimiento en una base de datos muy grande cada vez es más común. Muchos administradores de bases de datos dejan de realizarlas cuando se dan cuenta de que DBCC CHECKDB tarda más tiempo en ejecutarse del permitido por su ventana de mantenimiento. En algunos casos, la base de datos se usa las 24 horas del día, 7 días de la semana y no hay tiempo válido para renunciar a la CPU y la carga de E/S que requiere DBCC CHECKDB durante un período de tiempo prolongado.
Aparte de dejar de lado y no ejecutar ninguna comprobación de coherencia (que yo no recomiendo en absoluto), existen cuatro métodos que puede emplear. He ayudado personalmente a clientes a usar estos cuatro métodos.
Uso de la opción WITH PHYSICAL_ONLY de DBCC CHECKDB Un DBCC CHECKDB normal realiza gran cantidad de comprobaciones lógicas de coherencia y usa mucha CPU (ya que básicamente es una operación enlazada a la CPU). Al usar la opción WITH PHYSICAL_ONLY, las comprobaciones se limitan a comprobaciones muy rápidas de la coherencia del mapa de bits de la asignación DBCC CHECKALLOC y, a continuación, se leen y realizan auditorías de todas las páginas asignadas de la base de datos, con lo que se fuerza la comprobación de todas las sumas de comprobación de página presentes en las páginas por probar. De esta forma, DBCC CHECKDB se convierte en una operación ligada a acciones de E/S mucho más rápida (en realidad, a veces es incluso una vez o más rápido que un DBCC CHECKDB completo, que se puede traducir en un ahorro de tiempo muy considerable).
División de la carga de trabajo de la comprobación de coherencia Esta operación implica fragmentar las tablas de la base de datos en grupos del mismo tamaño (el método más sencillo es hacerlo por número de páginas) y, a continuación, mediante los comandos de DBCC CHECKTABLE, comprobar la coherencia de todas las tablas de un solo grupo cada noche. Así, por ejemplo, si comprobamos siete grupos, uno cada día, con un DBCC CHECKALLOC y un DBCC CHECKCATALOG todas las semanas, se obtiene el equivalente a un DBCC CHECKDB, aunque éste se realizaría en el transcurso de una semana.
Uso de particiones de tablas con varios grupos de archivos Las tablas más grandes de bases de datos muy grandes se pueden dividir en varios grupos de archivos. Un esquema de comprobación de coherencia de ejemplo puede ser ejecutar un DBCC CHECKFILEGROUP diario en el grupo de archivos que incluye la partición de lectura y escritura y también un DBCC CHECKFILEGROUPs semanal en los grupos de archivos que incluyen las particiones de sólo lectura. La lógica de este método es que se realiza una copia de seguridad exhaustiva de los datos de sólo lectura y que éstos no se usan en el procesamiento diario. Como resultado, no es necesario realizar comprobaciones de coherencia tan a menudo porque los daños no son tan críticos en estos datos.
Traslado de las comprobaciones de coherencia a otro servidor Esta opción implica restaurar las copias de seguridad completas y periódicas de la base de datos en otro servidor y ejecutar el DBCC CHECKDB en dicho servidor. Obviamente, esto descarga por completo la carga de trabajo que implican las comprobaciones de coherencia del servidor de producción. Sin embargo, el inconveniente es que si se encuentran datos dañados, se debe llevar a cabo una comprobación de coherencia en el servidor de producción; aunque esto rara vez ocurre.
Como se puede ver, los administradores de bases de datos tienen muchas opciones para realizar comprobaciones de coherencia en una base de datos muy grande, con lo que se reduce la carga de recursos adicional necesaria al realizar un DBCC CHECKDB completo. Como ya he mencionado anteriormente, he ayudado personalmente a clientes a usar estos cuatro métodos. Creo que estas opciones le serán de utilidad.
Sugerencia: Uso de desencadenadores para implementar lógica en los servidores
En algunos casos, es necesario implementar la lógica del servidor con desencadenadores, pero debe tener en cuenta ciertos inconvenientes. A continuación enumeramos algunos aspectos importantes que debe tener presente.
  • Los desencadenadores son activados por instrucciones, no por filas. Una vez dicho esto, asegúrese de que incluye lógica adicional en la lógica de su desencadenador para controlar la situación en que varias filas o ninguna fila se ven afectadas por la instrucción (los desencadenadores son activados por instrucciones, aunque no haya ninguna fila afectada). Los datos afectados se encuentran en tablas virtuales de las instrucciones del lenguaje de manipulación de datos (DML). Estas tablas se pueden unir, lo que le permitirá trabajar con los datos.
  • Los desencadenadores se ejecutan de forma sincrónica en su transacción. Recuerde esto cada vez que desee llamar a una aplicación externa u obtiene acceso a un recurso externo en el que no puede estar seguro de que recibirá una respuesta rápida o en un tiempo razonable. Por ejemplo, si activa una instrucción de actualización para una tabla y se activa un desencadenador en esa acción, la transacción (la parte implícita de la instrucción de actualización) no terminará hasta que no se haya completado toda la lógica del desencadenador. Si la aplicación o el proceso externos devuelven un código de error, SQL Server puede que cancele la transacción y revierta su transacción (según el control de errores y el código de error implementados). Así pues, si debe realizar alguna acción externa en un desencadenador y no es crítica para la transacción (o no debe ejecutarse dentro del mismo ámbito), la debe pasar a otro proceso y recopilar los datos de manera asincrónica. En SQL Server 2005 se introdujo SQL Server Service Broker, que puede realizar estas operaciones de forma asincrónica.
  • Los errores provocados por una instrucción en un desencadenador son muy difíciles de encontrar. Si hay varias tablas incluidas en la transacción, recuerde examinar los desencadenadores si se produce un error e implemente el control de errores apropiado. Si cambia el esquema de su base de datos, asegúrese de realizar también un seguimiento de la lógica del desencadenador, ya que, de lo contrario, un desencadenador pequeño puede tener un importante impacto en el rendimiento y la estabilidad generales. La mayoría de las implicaciones que provienen de cambios en el esquema pueden comprobarse mediante Visual Studio® for Database Professionals, realizando comprobaciones automáticas del esquema a la vez que se edita el proyecto y realizando análisis de código estático con el fin de encontrar incoherencias en los tipos de datos.
—Jens K. Suessmeyer, consultor de bases de datos en Microsoft

Paul S. Randal es el director general de SQLskills.com y uno de los profesionales más valorados (MVP) de SQL Server. Ha trabajado en el equipo de Motor de almacenamiento de SQL Server en Microsoft de 1999 a 2007. Paul creó DBCC CHECKDB/reparación para SQL Server 2005 y fue responsable del motor de almacenamiento de núcleo durante el desarrollo de SQL Server 2008. Paul, que es un experto en recuperación ante desastres, en la alta disponibilidad y en el mantenimiento de bases de datos, participa frecuentemente en conferencias. Puede consultar su blog en SQLskills.com/blogs/paul.


Utility Spotlight Utilidad Windows Installer CleanUp
Lance Whitney

Se intenta desinstalar o actualizar una aplicación en un equipo de su entorno, pero el comando no se ejecuta. En lugar de eso, aparece un error que indica que la aplicación no se pudo desinstalar o actualizar. ¿Le suena de algo? Si es así, indudablemente se habrá preguntado cuál es la causa de este problema.
El software instalado con la tecnología de Microsoft® Windows® Installer (MSI) escribe determinados archivos y los valores del Registro. Si falta o está dañado uno de esos archivos o los valores del Registro, es posible que no pueda quitar, actualizar o incluso reinstalar el programa. La solución en estos casos consiste en quitar toda la información de Windows Installer de modo que el programa se pueda reinstalar correctamente. Para ello, Microsoft ofrece la utilidad gratuita Windows Installer CleanUp.
La utilidad Windows Installer CleanUp elimina todos los archivos y valores del Registro que se asocian con la configuración de Windows Installer de un programa. Es importante tener en cuenta que la herramienta no quita los archivos de instalación ni los valores del Registro reales del programa. La herramienta tampoco reemplaza el comando Agregar o quitar programas.
En su lugar, debe recurrir a esta utilidad si no puede desinstalar o actualizar una aplicación mediante Agregar o quitar programas u otros métodos. Al eliminar la información de Windows Installer, debe poder reinstalar la aplicación. Puede dejar el programa instalado tal como está, actualizarlo o incluso quitarlo.
La utilidad Windows Installer CleanUp muestra una lista de todas las aplicaciones basadas en Windows Installer en el equipo (haga clic en la imagen para ampliarla)
Tal vez algunos de los lectores están familiarizados con el programa msizap de línea de comandos de Microsoft, que quita los datos de Windows Installer de un programa. Bien, ese comando sigue siendo útil en este caso: Windows Installer CleanUp es simplemente un front-end fácil de usar de msizap, por lo que ya no se tiene que enfrentar a complicadas opciones de la línea de comandos.
Después de instalar la utilidad, encontrará un subdirectorio denominado Windows Installer Clean Up anidado en Archivos de programa. En ese subdirectorio hay tres archivos: msicuu.exe, msizap.exe y readme.txt. El archivo msicuu.exe muestra una lista de todas las aplicaciones basadas en Windows Installer del equipo, y le permite seleccionar, anular la selección y quitar cualquiera de las aplicaciones. Este programa pasa el conjunto de aplicaciones seleccionadas al comando msizap.exe, que quita la información de Windows Installer de las aplicaciones seleccionadas.
Para ejecutar Windows Installer CleanUp, vaya al menú Inicio | Todos los programas y busque la carpeta correspondiente; a continuación, haga clic en el acceso directo de Windows Installer Clean Up. Aparecerá una lista con todas las aplicaciones basadas en Windows Installer que se encuentran en el equipo (tal como se muestra en la captura de pantalla). Seleccione la aplicación que le da problemas y haga clic en el botón Remove. La aplicación se elimina a continuación de la base de datos de Windows Installer. Ahora tiene la oportunidad de reinstalarla correctamente.
Después de que ejecute la herramienta CleanUp, la aplicación ya no aparecerá en Agregar o quitar programas. Por lo tanto, si finalmente desea quitar la aplicación, primero debe reinstalarla. Windows Installer CleanUp sólo funciona con software que usa tecnología de Windows Installer. Este tipo de tecnología normalmente cubre las instalaciones empaquetadas como archivos MSI.
Finalmente, tenga en cuenta que debe iniciar sesión como administrador para ejecutar Windows Installer CleanUp. La herramienta es compatible con todas las versiones de 32 y 64 bits de Windows. Para obtener más información sobre la utilidad y descargar el software, vaya a support.microsoft.com/kb/290301.

Lance Whitney es escritor técnico, profesor y consultor de TI. Ha pasado cientos y cientos de horas trabajando con estaciones de trabajo y servidores de Windows. Periodista en sus inicios, dio un giro hacia el mundo de TI hace unos 15 años.


Dentro de SharePoint Solución de problemas de integración de mensajería
Pav Cherny

Descarga de código disponible en: SharePoint2008_08.exe (416 KB)
Contenido
Enfoque general de solución de problemas
Arquitectura de mensajería de SharePoint
Obtención de información de diagnóstico
Transferencia de mensajes salientes
Transferencia de mensajes entrantes
Administración de directorios
Conclusión
En un entorno de SharePoint bien diseñado, los trabajadores de la información no tienen que cambiar sus hábitos de comunicación ni sus rutinas de trabajo para poder colaborar. SharePoint puede entregar documentos e información adicional, como alertas y avisos, directamente en sus buzones, en lugar de comprobar manualmente los sitios de colaboración de forma continua.
Los usuarios también pueden participar en flujos de trabajo respondiendo a estos mensajes o enviando nuevos elementos como mensajes de correo electrónico para documentar las bibliotecas y las listas.
Sin embargo, la integración de SharePoint® en un entorno de mensajería seguro supone desafíos y deja un espacio abierto para que los componentes que no pertenecen a SharePoint repercutan en la colaboración basada en SharePoint. El desafío es aislar y eliminar de manera eficaz las causas principales de los problemas en el entorno integrado allí donde sucedan.
En esta columna, analizo la integración de mensajería de SharePoint en función de una estrategia probada de solución de problemas que proporciona resultados rápidos. La idea es localizar de manera eficaz el punto problemático y luego acercarse con pasos para la solución de problemas más detallados y orientados.
En una organización grande, esta investigación por fases quizás signifique pasar el caso a otro especialista después de un análisis inicial, especialmente si el problema está relacionado con componentes que no pertenecen a SharePoint. Por otra parte, en organizaciones pequeñas y medianas, no es raro que un solo administrador de TI tenga que solucionar problemas de todos los sistemas directamente implicados, lo que resalta aún más la necesidad de usar enfoques estructurados.
Para que esta columna siga orientada a la práctica, uso un entorno de pruebas con Active Directory®, Exchange Server 2007 y WSS 3.0. Las instrucciones detalladas para crear este entorno de pruebas así como las herramientas de solución de problemas que se tratan en esta columna se encuentran en el material complementario, disponible en la sección Descargas de código del sitio web de TechNet Magazine.

Enfoque general de solución de problemas
La solución de problemas de integración de mensajería de SharePoint requiere un enfoque muy estructurado, quizás aún más que en otros escenarios de interoperabilidad. Hay varios factores que complican este intento.
Obviamente se debe tratar con tecnologías complejas, y mientras se lucha con los problemas de transferencia de mensajes, las conversiones de formato de mensajes, los aspectos de seguridad y los problemas de administración de directorios, se encontrará con que algunos mensajes de error de SharePoint pueden ser confusos. Los grupos de noticias de Internet están colmados de temas de discusión y sugerencias no resueltas que pueden llevarle por un camino equivocado, por ejemplo ejecutar todas las aplicaciones web bajo la identidad del grupo de aplicaciones de la administración central de SharePoint para lograr que la integración de mensajería funcione.
Pero también hay aspectos positivos. SharePoint es muy flexible. De hecho, puede ofrecer información detallada sobre solución de problemas si se sabe dónde consultar. Con unos cuantos scripts básicos se puede mejorar mucho la eficacia de la solución de problemas.
El primer objetivo de la solución de problemas es comprender el problema particular que se está tratado. Se debe identificar dónde reside el problema y qué componentes implica. También se podría reproducir el problema en configuraciones del sistema diferentes y estudiar los archivos de registro basados en texto y los registros de eventos de Windows®. Pero esto puede ser complicado dado que algunos problemas sólo ocurren esporádicamente. Además, cuanto mejor se logre reproducir un problema, más rápido se podrá identificar y eliminar su causa principal. Otro objetivo importante, que a menudo se pasa por alto, es documentar todos los cambios de configuración y correcciones y garantizar que se aplican en todos los sistemas relevantes del entorno, por ejemplo en todos los servidores front-end de una granja de servidores web.

Arquitectura de mensajería de SharePoint
Siempre que se enfrenta con un problema relacionado con la integración de mensajería, se recomienda en primer lugar tomar una taza de café o de té y, a continuación, revisar la arquitectura de integración de mensajería de SharePoint antes de entrar en la solución de problemas. De lo contrario quizás termine corrigiendo un problema o componente equivocado. Por ejemplo, un error "Acceso denegado", que le impide crear un objeto de contacto en Active Directory no es necesariamente un indicador de que necesita corregir permisos de acceso en Active Directory, como verá más adelante.
En todo caso, es esencial entender la función de cada componente que participa en la integración de mensajería y la interacción mutua de los componentes individuales. Si observa la figura 1 verá los componentes importantes en un escenario de conectividad SharePoint-Exchange, que trataremos con todo detalle en las secciones siguientes.
Figura 1Arquitectura de integración de mensajería de SharePoint (haga clic en la imagen para ampliarla)

Obtención de información de diagnóstico
Una de las herramientas más importantes de solución de problemas es la información de diagnóstico confiable. El clásico de todos los tiempos es el registro de eventos de Windows. Entre otras cosas, con Administración central de SharePoint se puede controlar el nivel de detalle con el que SharePoint escribe en el registro de eventos de Windows de los servidores web (en la página Operaciones, en Crear registros e informes, hacer clic en Registro de diagnósticos). Se puede especificar el evento menos crítico que desea incorporar al registro de eventos y al registro de seguimiento. El registro de seguimiento (ubicado de forma predeterminada en %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Logs) es muy útil si se busca información de bajo nivel, pero se puede llenar muy rápido, por lo que esta característica se debe usar con moderación.
Otra manera de obtener información de diagnóstico es habilitar la depuración de la aplicación web afectada, por medio de la configuración del archivo web.config correspondiente, tal y como se describe en el material complementario, en Web Application Config.pdf. SharePoint muestra información de seguimiento detallada directamente en la interfaz de usuario. Una ventaja de este enfoque es que se puede ver la información de errores pertinente sin tener que analizar megabytes de datos de seguimiento. Una desventaja es que se debe cambiar la configuración del sistema de la aplicación web. No se olvide de realizar copias de seguridad del archivo web.config original y de restaurar después la configuración original cuando haya terminado de solucionar los problemas.
También se puede configurar el servicio SMTP para escribir información de procesamiento detallada en el archivo de registro del protocolo SMTP (en Administrador de IIS, en la ficha General, seleccionar la casilla Habilitar registro). Asegúrese de instalar el módulo Registro ODBC junto con la característica Servicio SMTP tal y como se describe en SharePoint Messaging Integration.pdf que se encuentra en el material complementario, incluso si no planea usar Registro ODBC. De otro modo, el servicio SMTP no escribirá el archivo de registro del protocolo. De forma predeterminada, el archivo de registro del protocolo SMTP se encuentra en %SystemRoot%\System32\LogFiles\SmtpSvc1. Es un archivo de texto que permite analizar con todo detalle la comunicación SMTP y determinar si un mensaje sale del servidor de SharePoint.
También puede habilitar el registro del protocolo en el servidor de transporte de concentradores que se comunica con el servicio SMTP, en la configuración de Conector de envío y Conector de recepción (consulte SharePoint Messaging Integration.pdf). Puede usar muchas otras herramientas para seguir la ruta que toman los mensajes en un entorno de Exchange Server 2007 a través de servidores de transporte de concentradores y servidores de buzón, tales como Seguimiento de mensajes, Visor de colas y Seguimiento de conductos. Si desea obtener información detallada acerca de solución de problemas en el flujo de correo en Exchange Server 2007, consulte el tema "Problemas de transporte y de flujo de correo" en go.microsoft.com/fwlink/?LinkID=120145.
En controladores de dominio de Active Directory, se puede recopilar información detallada sobre solución de problemas si se habilita el registro de diagnóstico para Acceso al directorio y otras categorías, configurando las entradas del registro correspondientes en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Un valor de 0x0 en una categoría significa que sólo se registran eventos críticos mientras que un valor de 0x5 significa todos los eventos, incluida la información de depuración. El uso de un nivel de registro mayor que 0x3 puede degradar el rendimiento del servidor y llenar rápidamente el registro de eventos de Windows. Durante el funcionamiento normal, todos los valores se deben establecer en 0x0.
La recopilación de información de diagnóstico detallada en servidores SharePoint, Exchange y Active Directory en una situación de solución de problemas puede ayudar a encontrar de manera rápida y confiable el foco del problema. También son útiles herramientas de solución de problemas adicionales, tales como herramientas de TCP/IP (ping, tracert, telnet, etc.) y Monitor de red, ya que la mayor parte de las comunicaciones entre estos sistemas se llevan a cabo a través de la red de equipos. Microsoft® Network Monitor 3.1se encuentra disponible en go.microsoft.com/fwlink/?LinkId=120143.

Transferencia de mensajes salientes
Recursos
  • Sitio web de productos y tecnologías de SharePoint
  • Centro tecnológico de Windows SharePoint Services
  • Centro de desarrollo de Windows SharePoint Services
  • Blog del equipo de productos y tecnologías de Microsoft SharePoint
Equipado con registros de eventos, registros de seguimiento, registros de protocolos, registros de seguimiento de mensajes y seguimientos de red, estoy listo para realizar la solución de problemas de integración de mensajería de SharePoint. Comencemos con la parte sencilla: la transferencia de mensajes salientes. SharePoint es compatible con la transferencia de mensajes salientes en distintas configuraciones y no necesita un servicio SMTP local en los servidores web. Sin embargo, en un escenario completo de integración de mensajería, la configuración recomendada usa el servicio SMTP local. La figura 2 muestra los componentes clave en el escenario.
Figura 2 Transferencia de mensajes salientes (haga clic en la imagen para ampliarla)
Este escenario de mensajería consta de cuatro etapas: SharePoint debe transferir el mensaje al servicio SMTP, el servicio SMTP debe procesar el mensaje, el servidor de transporte de concentradores debe recibir el mensaje y Exchange Server 2007 debe transferir el mensaje al destino final.
Si SharePoint no puede transferir el mensaje al servicio SMTP, normalmente se recibirá un error en la interfaz de usuario, por ejemplo que no es posible enviar una notificación por correo electrónico. La causa podría ser que el servicio SMTP no esté en ejecución. O quizás el registro del protocolo SMTP indica que el servicio SMTP rechazó el intento de envío con un código de error 550 (No se ha completado la acción solicitada: buzón no disponible), lo que indica que el problema se encuentra en el servicio SMTP.
Para comprobar que no es un problema de SharePoint, se puede usar un script básico (consulte SMTP.vbs en el material complementario) para enviar a través de SMTP un mensaje de prueba con la misma información de emisor y destinatario. El script no se ejecutará correctamente si es un problema del servicio SMTP. De hecho, quizás este script ofrezca pistas valiosas de la causa principal del problema que desafortunadamente SharePoint no divulga ni siquiera con la depuración habilitada, como se muestra en la figura 3.
Figura 3 No se puede retransmitir mensajes (haga clic en la imagen para ampliarla)
Al conceder los permisos de retransmisión del servidor web en la configuración del servicio SMTP y reiniciar el servicio, se podrá resolver el problema de envío de mensajes de SharePoint. Ahora el mensaje puede alcanzar el servicio SMTP, y la siguiente pregunta importante es si el servicio SMTP puede enrutar el mensaje al servidor de transporte de concentradores.
Si el mensaje se queda en la carpeta de cola, significa que el servicio SMTP no puede ponerse en contacto con el servidor de transporte de concentradores. Esto se debe a que el servicio de transporte de Microsoft Exchange no está en ejecución o debido a un problema de comunicación de red o de configuración. Mediante el cliente Telnet, se puede comprobar rápida y fácilmente si es posible conectarse al puerto de destino de un conector de recepción configurado para la comunicación interna.
Este no es necesariamente el puerto TCP 25. De hecho, si el servicio SMTP usa este puerto, quizás los mensajes se transfieran al conector de recepción predeterminado para servidores de transporte de concentradores, configurado para bloquear envíos de mensajes anónimos. En este caso, verá un archivo de mensaje en la carpeta de entrega. (El servicio de temporizador de Windows SharePoint Services debe estar detenido; de lo contrario, el mensaje desaparece después de algunos segundos). El archivo de mensaje es una notificación de estado de entrega que indica que el mensaje ha sido rechazado con: "Código de diagnóstico: smtp; 530 5.7.1. El cliente no se autenticó".
Para resolver este problema, debe crear un conector de recepción dedicado para los servidores de SharePoint. Como los servidores de SharePoint son sistemas internos, elija la opción de autenticación Protegido externamente. De este modo, no necesita conceder derechos extendidos a la cuenta de inicio de sesión anónimo. Además, considere el uso de IPsec para proteger la comunicación entre servidores de SharePoint y el servidor de transporte de concentradores.
Si los mensajes dejan la carpeta de cola SMTP y los registros del protocolo SMTP en el servidor de SharePoint y el servidor de transporte de concentradores (consulte la carpeta %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive) indican que la transferencia de mensajes se realizó correctamente, puede considerar que el trabajo se ha realizado, asumiendo que Exchange Server 2007 puede enrutar el mensaje al destino. Como mencionamos anteriormente, se deben usar las herramientas de solución de problemas de flujo de correo incluidas en Exchange Server 2007 para investigar los problemas que surgen si los mensajes no alcanzan los destinatarios de Exchange de destino. En esta etapa, tenga en cuenta que la información de destinatarios incorrecta, los filtros de correo no deseado y las restricciones del tamaño de los mensajes pueden evitar la entrega final.

Transferencia de mensajes entrantes
En la dirección opuesta, la transferencia de mensajes es un poco más complicada porque los problemas potenciales son más sutiles. Por ejemplo, la documentación de producto de SharePoint recomienda configurar los registros MX en DNS para dominios del correo electrónico de SharePoint, que en una organización de Exchange son una causa habitual de pérdida de enrutamiento de mensajes.
Exchange Server 2007 usa conectores de envío con espacios de direcciones asociados para transferir los mensajes. Esto podría provocar el enrutamiento de los mensajes de SharePoint a servidores de transporte perimetral para realizar la transferencia a través de Internet incluso si los servidores de SharePoint son internos. En lugar de eso, en la transferencia de mensajes interna use conectores de envío con espacios de direcciones detallados y en la configuración del conector especifique que los servidores de SharePoint ejecutan el servicio SMTP como host inteligentes (consulte SharePoint Messaging Integration.pdf en la descarga complementaria). El establecimiento de una topología de enrutamiento bien definida con servidores cabeza de puente dedicados ayuda a lograr una transferencia de mensajes segura de Exchange a SharePoint.
Para comprobar que los mensajes llegan a los servidores de SharePoint, detenga el servicio de temporizador de Windows SharePoint Services. Los mensajes se amontonarán en la carpeta de entrega porque el servicio de temporizador es el que procesa los mensajes y coloca los datos adjuntos de archivos en bibliotecas de documentos asociadas con las direcciones de correo electrónico del destinatario, como se indica en la figura 4. Si los mensajes no llegan a la carpeta de entrega, use el Visor de colas en el servidor de transporte de concentradores para ver si Exchange enruta correctamente los mensajes. A continuación, investigue los problemas de comunicación de red que podrían impedir la comunicación entre el servidor de transporte de concentradores y el servicio SMTP del servidor de SharePoint.
Figura 2 Transferencia de mensajes salientes (haga clic en la imagen para ampliarla)
Cuando reinicia el servicio del temporizador, debe ver que los elementos de mensaje desaparecen de la carpeta de entrega. Sin embargo, si los datos adjuntos de mensajes no terminan como documentos en las bibliotecas de destino, a pesar de que SharePoint indique un procesamiento correcto de los mensajes en el registro de eventos de Windows, significa que Exchange ha enviado los mensajes en formato RTF de Exchange. Para investigar este problema, detenga nuevamente el servicio de temporizador, envíe desde su cliente Outlook® otro mensaje con datos adjuntos y, a continuación, abra el mensaje en el Bloc de notas después de que llegue a la carpeta de entrega. Ahora busque la cadena "winmail.dat". Si la encuentra, significa que Exchange Server envía los mensajes en un formato incorrecto.
SharePoint requiere datos adjuntos de mensajes codificados en formato MIME o UUENCODE. Además, SharePoint no muestra los problemas de procesamiento relacionados con winmail.dat en el registro de eventos de Windows (consulte la figura 5). Simplemente, los datos adjuntos de archivos no aparecerán en la biblioteca de documentos. Use el Bloc de notas como herramienta de solución de problemas y elimine el problema del formato configurando en la Consola de administración de Exchange una definición de dominio remoto para el dominio del correo electrónico de SharePoint. En la ficha Formato del mensaje original enviado como datos adjuntos al informe del diario, en Formato de texto enriquecido de Exchange, seleccione No utilizar nunca.
Figura 5 Procesamiento de mensajes Winmail.dat (haga clic en la imagen para ampliarla)

Administración de directorios
Uno de los eventos más útiles del servicio de temporizador es el evento 6873, que indica que ocurrió un error al procesar un archivo de correo electrónico entrante debido a un alias desconocido. Esto sucede si un usuario de Exchange especifica una dirección de correo electrónico de SharePoint incorrecta al enviar los mensajes, tal como una biblioteca de documentos inexistente.
Este problema se puede mitigar configurando el servicio de administración de directorios en la configuración del correo electrónico entrante en la administración central de SharePoint para crear objetos de destinatario para bibliotecas de documentos habilitadas para correo electrónico en Active Directory. Entonces los usuarios de Exchange podrán seleccionar fácilmente de la libreta de direcciones estos objetos de destinatario que contienen la información de dirección correcta.
No obstante, observe que ahora aparecen problemas completamente nuevos por solucionar. En una configuración de sistema segura, se producirán errores en el servicio de administración de directorios basados en el principio de privilegio mínimo, porque esta característica eleva los requisitos de permisos en el servidor web. Además, la documentación del producto (por ejemplo technet.microsoft.com/library/cc262947.aspx) exagera un poco la situación al sugerir que debe conceder el derecho "Crear, eliminar y administrar cuentas de usuario" a la cuenta del grupo de aplicaciones de administración central en la unidad organizativa que especificó en los objetos de destinatario de SharePoint en Active Directory.
El servicio de administración de directorios crea objetos de contacto y grupo y, por lo tanto, la cuenta del grupo de aplicaciones de administración central requiere control total sobre los objetos de contacto y grupo de esta unidad organizativa, pero no requiere permisos administrativos para las cuentas de usuario. Si establece el servicio de administración de directorios en una granja de servidores web tal como se describe e intenta habilitar el correo electrónico en una biblioteca de documentos, es muy probable que obtenga el error "Acceso denegado".
La información de errores apunta a problemas de permisos de Active Directory, y los administradores de SharePoint asignan rápidamente control total para Todos en la unidad organizativa de SharePoint. Sin embargo, esta acción no sólo debilita la seguridad de Active Directory, sino que tampoco resuelve el problema.
Una solución de problemas estructurada requiere localizar en primer lugar el foco del problema y posteriormente aplicar cambios de configuración orientados. Si sigue este enfoque y comprueba el registro de eventos de Windows en el controlador de dominio y quizás si realiza un seguimiento de las comunicaciones de red con el Monitor de red, pueda averiguar que este problema sucede cuando SharePoint no tiene acceso a Active Directory. Por lo tanto, es improbable que esos cambios de configuración de Active Directory corrijan el problema. El problema se produce en el servidor de SharePoint.
Desafortunadamente es muy difícil obtener información más útil sobre este problema de permisos. SharePoint no registra ninguna información adicional en el registro de eventos de Windows. Sin embargo, si habilita la depuración de SharePoint, podrá ver la pila de llamadas (tal como se muestra en la figura 6), que sugiere que el servicio de administración de directorio usa el método CreateContact de un servicio web de SharePoint. El SDK de SharePoint le indicará que se trata del servicio web de integración de correo electrónico (<WSS_server>:<admin_port>/_vti_bin/SharePointEmailWS.asmx).
Figura 6 Resultados de depuración
Server was unable to process request. ---> Access is denied.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message,      WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[]      parameters)
   at Microsoft.SharePoint.DirectorySoap.SPDirectoryManagementProxy.CreateContact(String Alias,      String FirstName, String LastName, String ForwardingEmail, ContactFlags Flags)
   at Microsoft.SharePoint.SPList.UpdateDirectoryManagementService(String oldAlias, String      newAlias)
   at Microsoft.SharePoint.SPList.Update(Boolean bFromMigration)
   at Microsoft.SharePoint.SPList.Update()
   at Microsoft.SharePoint.ApplicationPages.EmailSettingsPage.SubmitButton_Click(Object sender,      EventArgs args)
   at System.Web.UI.WebControls.Button.OnClick(EventArgs e)
   at System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)
   at System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String      eventArgument)
   at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean      includeStagesAfterAsyncPoint)
Analicemos sharepointEmailWS.asmx en un explorador web para ver la lista de operaciones admitidas. Puede observar el método CreateContact, y si hace clic en el vínculo de CreateContact se mostrarán los mensajes SOAP que debe enviar a este servicio web si desea crear un contacto en Active Directory. Esto es útil porque ahora puede crear una herramienta de solución de problemas basada en scripts (consulte sharepointEmailWS.vbs en el material complementario) que funcione fuera de la interfaz de usuario de SharePoint, lo cual facilita la especificación de cuentas de usuario diferentes durante las ejecuciones de las pruebas. La figura 7 muestra la información devuelta si ejecuta este script con la cuenta del grupo de aplicaciones de administración central (a la izquierda) y con la cuenta del administrador de SharePoint (a la derecha).
Figura 7 Dos mensajes de error "Acceso denegado" diferentes (haga clic en la imagen para ampliarla)
¡Los mensajes de error son diferentes! Ambos mensajes establecen que se deniega el acceso, pero el error de la izquierda indica un problema de procesamiento y el de la derecha no lo hace. Así que, ¿cuál es la diferencia entre las cuentas del grupo de aplicaciones y la cuenta del administrador de SharePoint?
El administrador de SharePoint es un administrador local del servidor de SharePoint mientras que las cuentas del grupo de aplicaciones no lo son. Si se agregan las cuentas del grupo de aplicaciones de su aplicación web al grupo de administradores locales y se reinicia el servidor web, el problema se resolverá, aunque no son grandes noticias. Considero inaceptable la ejecución de cuentas del grupo de aplicaciones con privilegios administrativos en los servidores web de producción.
¿Por qué una cuenta del grupo de aplicaciones requiere estos permisos elevados? Una vez más, el script puede revelar la respuesta. Si concede permisos de administrador local a todos los usuarios del servidor web para realizar pruebas, encontrará que las cuentas del grupo de aplicaciones pueden usar el servicio web de integración de correo electrónico mientras que el acceso permanece denegado para todas las demás cuentas, incluidos los administradores de SharePoint. Esto significa que el servicio web de integración de correo electrónico usa la configuración del grupo de aplicaciones como base para las decisiones de control de acceso.
La configuración del grupo de aplicaciones forma parte de la metabase IIS (o del archivo applicationHost.config en IIS 7.0), y el acceso a la metabase está restringido a los administradores locales de forma predeterminada. Afortunadamente, es posible conceder acceso a la metabase a cuentas de usuarios que no son administradores con el Explorador de Metabase incluido en las herramientas del kit de recursos de IIS 6.0. En IIS 7.0, es aún más fácil conceder control total al archivo applicationHost.config; simplemente ejecute los siguientes comandos:
CACLS "%SystemDrive%\Windows\System32\inetsrv\config\applicationHost.config"
/G "<application pool account>" :F /E iisreset /noforce
En resumen, para crear objetos de contacto en Active Directory, el grupo de aplicaciones de administración central requiere control total sobre los objetos de contacto y grupo en la unidad organizativa de destino. Y las cuentas del grupo de las aplicaciones web requieren acceso total a la metabase en los servidores de SharePoint de la granja de servidores web. Ahora está listo para crear objetos de contacto mediante la interfaz de usuario de SharePoint.
Pero espere: ¡hay mucho más! En Active Directory, la creación de objetos de destinatario es sólo la mitad de la historia de integración de directorios. La otra mitad es la generación de atributos de destinatario relacionados con Exchange y la actualización de libretas de direcciones basadas en el servidor. Por ejemplo, si actualiza la lista global de direcciones en el servidor Exchange mediante el comando Shell de administración de Exchange: Update-GlobalAddressList "Default Global Address List", podrá encontrar objetos de destinatario creados recientemente para bibliotecas de documentos de SharePoint en la libreta de direcciones de Outlook. Pero si se envían mensajes a estos destinatarios se obtendrán informes de entrega sin éxito debido a información de dirección incorrecta, como se ilustra en la figura 8.
Figura 8 Mensaje que no se puede entregar a una biblioteca de documentos (haga clic en la imagen para ampliarla)
La sigla IMCEAEX significa dirección encapsulada del conector de Internet Mail para Exchange. Indica una dirección encapsulada de destinatario que no pertenece a Exchange en un formato que el viejo conector de Internet Mail de Exchange puede controlar. Pero actualmente trabajamos con Exchange Server 2007 y conectores de envío basados en SMTP nativo.
El punto es que el servicio web de integración de correo electrónico de SharePoint no escribe los atributos de dirección que Exchange Server 2007 requiere para la transferencia de mensajes. Sólo escribe el nombre, apellido, nombre para mostrar y dirección de destino (y, opcionalmente, los atributos msExchRequireAuthToSendTo). Pero no establece el sobrenombre de correo, el nombre distintivo (DN) del Exchange heredado ni las direcciones proxy, y no asocia el objeto de destinatario con una directiva de destinatarios de Exchange.
Para resolver este problema, use el cmdlet Get-Mailbox en el Shell de administración de Exchange para obtener todos los objetos de destinatario con una dirección de destino que señale al dominio del correo electrónico de SharePoint. Y canalice la salida al cmdlet Set-MailContact para activar las directivas de destinatarios de Exchange, de la siguiente manera:
Get-Contact | where { $_.WindowsEmailAddress –like
  '*sharepoint.contoso.com' } | Set-MailContact
  -EmailAddressPolicyEnabled:$True
Como alternativa, use la consola de administración de Exchange y seleccione la casilla "Actualizar direcciones automáticamente según directiva de direcciones" en las propiedades del objeto de contacto.

WSS 3.0 y MOSS 2007 admiten originalmente la integración de mensajería completa para habilitar alertas y notificaciones basadas en correo electrónico, flujos de trabajo y envíos de documentos. Aunque configurar los sistemas correctamente no es una tarea sencilla, la integración de mensajes puede aumentar la productividad del trabajador. Concretamente, debe asegurarse de que la transferencia de mensajes entrantes y salientes funciona correctamente. También debe estar seguro de que la integración de directorios funciona.
Los mensajes de error de SharePoint no siempre son intuitivos o informativos. No obstante, he mostrado algunas formas de llegar hasta el fondo de los problemas de integración, ubicar las causas principales y eliminar los problemas de forma confiable sin tener que arriesgar la seguridad en los servidores de SharePoint.

Pav Cherny es experto en TI y autor especializado en tecnologías de Microsoft para la colaboración y las comunicaciones unificadas. Sus publicaciones incluyen notas del producto, manuales de productos y libros centrados en operaciones de TI y administración de sistemas. Pav es Presidente de Biblioso Corporation, una empresa especializada en servicios de documentación y localización administrados.


Windows PowerShell Un adelanto de la administración remota en la versión 2.0
Don Jones

Este artículo se basa en una versión preliminar de Windows PowerShell. Por tanto, toda la información de este documento está sujeta a cambios.

Contenido
Dos tipos de comunicación remota
Sincrónico frente a asincrónico
Espacios de ejecución reutilizables
Comunicación remota convergente
La aplicación rompedora en la versión 2.0
¿Ha tenido la oportunidad de experimentar con la versión más reciente de Community Technology Preview (CTP) de Windows PowerShell 2.0? La versión más reciente, CTP2, ha refinado aún más la administración remota, y ahora mismo es un excelente momento para comenzar a familiarizarse con las nuevas capacidades que ofrece. Antes de comenzar, le recomiendo que dedique un momento a
descargarla de go.microsoft.com/fwlink/?LinkID=119707.
En primer lugar, permítame clarificar un par de puntos importantes. CTP es código en una fase anterior a la beta, que Microsoft ofrece para permitir que los usuarios ansiosos como yo se hagan una idea de hacia dónde se dirige Microsoft con la próxima versión de una aplicación. Cada hito o entrega de CTP (como la llaman en el sector) puede variar completamente con respecto a las entregas anteriores. Por eso el equipo de desarrollo reúne los comentarios, los revisa con cuidado y, a continuación, realiza los cambios en la aplicación basándose en estos comentarios de los usuarios. Esa metodología plantea una importante ventaja y una importante salvedad acerca del uso de CTP.
Vídeo
Observe a Don Jones demostrar las nuevas capacidades de administración remotas de Windows PowerShell 2.0 CTP2.

La ventaja consiste en que al usar CTP, se pueden proporcionar comentarios (a través del sitio web connect.microsoft.com) acerca del producto durante un momento del desarrollo en que el equipo puede actuar sobre esos comentarios. Si espera hasta la etapa beta o, peor aún, hasta la etapa de candidato de versión comercial, es mucho más difícil que se incorporen sus comentarios. Durante el uso de CTP, quizás algo suceda y el equipo puede realizar cambios vastos y generales, si fuera necesario.
Eso me lleva a la salvedad. CTP no está listo para producción. Sí, posiblemente Windows PowerShell™ 2.0 CTP2 es uno de los fragmentos más estables de versión preliminar de código que haya visto, pero tenga en cuenta que es posible que la próxima entrega de CTP sea una aplicación totalmente distinta. Así que no debe comenzar a depender de CTP2, porque en la próxima versión puede ser necesario que comience todo de nuevo.
Tenga en cuenta que CTP no se puede instalar en paralelo con Windows PowerShell 1.0. Para obtener una instalación ideal, en el sistema también se debe instalar Microsoft® .NET Framework 3.5 para habilitar todas las características disponibles. De lo contrario, algunas características estarán limitadas.
Además, como CTP es código muy temprano, Microsoft ha puesto hasta ahora un mayor énfasis en el funcionamiento de la aplicación en los sistemas operativos más recientes, es decir, Windows Vista® y Windows Server® 2008. La compatibilidad del sistema operativo actual no es una indicación de la que se puede esperar en la versión final del código. La migración a sistemas operativos anteriores recibe atención en un momento posterior del ciclo de desarrollo.

Dos tipos de comunicación remota
En el mundo de la administración remota, generalmente puede encontrar dos tipos de comunicación remota: convergente y ramificada. La comunicación remota convergente abarca a múltiples administradores que realizan conexiones de shell seguras a un solo servidor. Windows PowerShell está diseñado para habilitar esta funcionalidad de una manera segura y con particiones de modo que una empresa de hospedaje de Exchange Server, por ejemplo, pueda ofrecer a sus clientes acceso administrativo a sus partes de un servidor. Con la comunicación remota convergente, se obtiene un acceso seguro, remoto e interactivo a la copia de Windows PowerShell (sólo en la versión 2.0) instalada en un servidor remoto.
La comunicación remota ramificada se produce al enviar un conjunto de comandos a un grupo completo de servidores remotos a la vez. Los comandos "se ramifican" desde la estación de trabajo al grupo de servidores en paralelo. Los comandos se ejecutan en cada servidor, y los resultados, en forma de objetos de Windows PowerShell, se devuelven a la estación de trabajo para poder revisarlos y trabajar con ellos. Windows PowerShell es compatible con dos tecnologías principales para comunicación remota ramificada: Instrumental de administración de Windows® (WMI) y Administración remota de Windows (WinRM), que se suministró por primera vez con Windows Server 2008 y se actualizó más tarde en la versión de CTP de Windows PowerShell 2.0.

Sincrónico frente a asincrónico
En realidad, incluso Windows PowerShell 1.0 tenía algunas capacidades ramificadas básicas vinculadas a WMI. Por ejemplo, se podía crear fácilmente una matriz de nombres de equipo y posteriormente recuperar una clase WMI de cada uno:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem
    –computer $names
Los métodos de ejecución, por ejemplo el reinicio de un equipo, necesitaban algo más de trabajo debido a que la versión 1.0 no ofrecía una forma masiva de ejecutar los métodos WMI. Sin embargo, en la versión 2.0 de CTP esto ha cambiado gracias al cmdlet Invoke-WmiMethod:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot
No obstante, esta técnica presenta un problema. Es sincrónica, lo que significa que se pone en contacto con cada equipo de uno en uno, y hay que esperar a que cada uno termine antes de poder ejecutar otros comandos. Pero CTP introduce un nuevo concepto: trabajos en segundo plano, lo que permite que comandos de este tipo se ejecuten en segundo plano. Para simplificar, se puede hacer que un comando WMI se ejecute en segundo plano simplemente con agregar el parámetro -AsJob:
$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob
Se puede revisar el estado del trabajo resultante ejecutando Get-PSJob y los resultados finales del trabajo se pueden ver ejecutando Receive-PSJob. (Analizaré con más profundidad los detalles subyacentes a la administración de trabajos en una futura columna). Sin embargo, el cmdlet Invoke-Command ofrece un medio todavía mejor para ejecutar comandos en segundo plano, tal como:
$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob
En realidad envía el comando Get-WmiObject a cada equipo especificado y, a continuación, lo ejecuta de forma local. Normalmente se ejecuta mucho más rápido y sin tener que depender de las conexiones de llamadas a procedimiento remoto (RPC) de WMI. En vez de eso, Invoke-Command emplea WinRM, que de forma predeterminada usa los puertos 80 o 443. Estos puertos facilitan la navegación por los firewalls y es totalmente configurable. Invoke-Command también es compatible con parámetros adicionales alternativos para credenciales y limitación de peticiones, que permiten dirigirse a cientos de equipos pero sólo tener unos cuantos ejecutándose en paralelo. Esto permite evitar la congestión y las sobrecargas en exceso.

Espacios de ejecución reutilizables
Si se planea administrar más de una vez de forma remota un conjunto de equipos determinado, se debe considerar el uso de espacios de ejecución en lugar de listas simples de nombres de equipo. En Windows PowerShell, un espacio de ejecución es simplemente una instancia del motor del shell, tanto si se ejecuta de forma local en el equipo como ventana de la consola del shell, como si lo hace en segundo plano en un equipo remoto. Iniciar un espacio de ejecución remoto es fácil:
$names = @("server1","server2","server2")
New-RunSpace –computer $names
Como los espacios de ejecución también usan WinRM, usan el puerto 80 (o el puerto 443, si especifica el parámetro -UseSSL) de forma predeterminada. También pueden aceptar credenciales alternativas, etc. Si se recuperan los objetos resultantes de espacios de ejecución, se pueden pasar a Invoke-Command, y Windows PowerShell enviará el comando a los equipos en los que existen esos espacios de ejecución:
$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob
Aquí la ventaja consiste en que los espacios de ejecución permanecen activos mientras el shell está abierto, de modo que se pueden volver a usar para comandos adicionales.

Comunicación remota convergente
Los espacios de ejecución son también la clave para la comunicación remota convergente. Por ejemplo, la figura 1 muestra un espacio de ejecución que he creado en un equipo remoto; recupero una referencia a ese espacio de ejecución y, a continuación, uso el cmdlet Push-Runspace para activarlo. En ese momento, ejecuto comandos en el equipo remoto, de un modo similar al que permitirían SSH u otras utilidades remotas del shell. La ejecución de Pop-Runspace devuelve el espacio de ejecución "local" original, y el mensaje del shell ayuda a realizar un seguimiento del lugar en que me encuentro en un momento dado.
Figura 1 Uso de un espacio de ejecución para ejecutar comandos en un equipo remoto (haga clic en la imagen para ampliarla)
La secuencia exacta de comandos que ejecuto es la siguiente:
PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>
Esta técnica es denomina convergente porque múltiples administradores pueden abrir espacios de ejecución interactivos remotos en el mismo servidor al mismo tiempo: ellos "convergen" desde sus estaciones de trabajo individuales al servidor. Un nuevo modelo de seguridad en Windows PowerShell 2.0 permite crear shells y cmdlets restringidos, para evitar que cada administrador realice modificaciones globales. Cada uno está limitado a su propia área del shell. (Estas nuevas técnicas de seguridad requieren desarrollos personalizados de software en un lenguaje orientado a .NET Framework. Este aspecto supera el ámbito de la columna de Windows PowerShell, pero es interesante saber que estas capacidades existen).

La aplicación rompedora en la versión 2.0
La versión de CTP de Windows PowerShell 2.0 tiene una lista espectacular de características nuevas. En mi opinión, la comunicación remota es la aplicación rompedora. Puede beneficiar a cada administrador en prácticamente cualquier entorno.
Debe familiarizarse con estas características para poder ofrecer sus sugerencias al equipo de producto. ¿Desea que los puertos predeterminados de WinRM se administren a través de directivas de grupo? ¿Los cmdlets deben funcionar de un modo diferente? ¿Hay problemas de rendimiento? ¿WinRM resulta fácil de configurar? Puede tener repercusión si envía las sugerencias a connect.microsoft.com o comparte sus comentarios con destinatarios reconocidos con el premio MVP, entre los que me incluyo (para ponerse en contacto conmigo, publique sus comentarios en los foros en ScriptingAnswers.com). ¡Participe y ayude a crear la aplicación rompedora de la próxima generación de Windows PowerShell!
Cmdlet del mes Select-Object
Pruébelo: Get-Service | ConvertTo-HTML | Out-File Servicios.htm. Ahora consulte en su explorador web el archivo HTML resultante. Hay bastante información, ¿no es cierto? Ojalá hubiera una manera de reducirla un poco y seleccionar la información de interés. Precisamente estas son las capacidades de Select-Object. Por ejemplo, digamos que sólo desea una lista de nombres de servicio y sus estados actuales. Puede usar: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Servicios.htm.
No obstante, algo que debe recordar es que Select-Object descarta el objeto original, en este caso, los servicios, y produce un objeto personalizado (literalmente, un tipo de objeto PSCustom) que sólo contiene las propiedades que ha especificado. Cualquier funcionalidad del objeto original deja de estar accesible, por lo que es probable que desee ubicar Select-Object cerca del final de la canalización y trabajar con el objeto original mientras sea posible.

Don Jones es coautor de Windows PowerShell v2.0: TFM y entrenador a cargo del aprendizaje en aula "Fuerzas especiales" de ScriptingAnswers.com (scriptinganswers.com/training.asp). Puede ponerse en contacto con él en la dirección jeepdon@mac.com.


Hey, Scripting Guy! Tomando la directa
Los Scripting Guys de Microsoft

En los últimos meses, uno de los encargados de scripting pudo experimentar algo nuevo aquí en el área de Seattle. Es un programa que se está probando en varias ciudades de EE. UU. y que se llama peaje electrónico. Sin embargo, en el Estado de Washington, el sistema se conoce como Good to Go!
Funciona más o menos así: se paga por obtener un dispositivo electrónico que se fija al parabrisas. También se abre una cuenta en la que se deposita una pequeña cantidad de dinero. Cada vez que se pasa bajo uno de los dispositivos que supervisan en la autopista, el dinero se deduce automáticamente de la cuenta. Básicamente, se paga por conducir por la autopista sin tener que pararse nunca en una cabina de peaje.
Ahora en muchos lugares donde hay que pagar peaje, las personas que comparten el automóvil no tienen que pagar. Sin embargo, la parte interesante acerca de Good to Go! es que sólo funciona en el carril de automóviles de uso compartido. ¿Y qué sentido tiene eso, se preguntará? ¿Por qué se molesta alguien en compartir el automóvil si luego tiene que pagar? Pues en realidad no lo hace. Este sistema sólo cobra a personas que desean usar el carril de automóviles de uso compartido cuando están solos. El motivo obvio para desear conducir por el carril de automóviles de uso compartido es que normalmente hay menos automóviles en ese carril; y a veces es el único carril por el que se mueven los automóviles.
Como hemos mencionado, este sistema está en fase experimental en este momento, aunque miles de personas ya se han apuntado. Hay muchas personas en el área de Seattle que están dispuestas a pagar dinero por tomar una vía directa para llegar allá donde quieran ir.
En la columna de este mes, los Scripting Guys hemos decidido hacer un pequeño experimento por nuestra cuenta. Hemos decidido mostrarles una vía directa conocida como Microsoft® Visual Basic® Express Edition. Empezaremos diciéndoles que una de las mejores cosas sobre esta vía es que realmente es gratuita; no se les cobrará ningún peaje, independientemente de dónde se use esta información, cuántas personas la usen o el momento del día en que lo hagan. Suena bien, ¿no? Seguramente puede parecer que hay que pagar un pequeño precio ya que tiene que aprender algunas cosas nuevas, pero probablemente llegará a la conclusión de que las ventajas lo valen.
Antes de continuar, debemos mencionar que sabemos que nos estamos saliendo un poco de nuestros límites. Normalmente, los productos de Visual Studio® como Visual Basic y Visual C#® serían temas a tratar en MSDN® Magazine, no en TechNet Magazine. Pero como MSDN y TechNet se están convirtiendo cada vez más en una gran familia disfun..., digo, feliz, esperamos que con esto se nos conceda un pequeño margen de maniobra. También, aunque hablemos de trabajar con lo que tradicionalmente ha sido una herramienta de desarrollador, todavía nos estaremos dirigiendo a los administradores de sistemas de Windows®. Continúe con nosotros unos cuantos minutos más y sabrá a lo que nos referimos.
La primera cosa que necesita hacer para seguirnos es instalar Visual Basic. No, espere. No huya diciendo "¡yo esto no lo tengo!" o "¡no puedo permitírmelo!". Microsoft ofrece una Express Edition de Visual Basic que se puede descargar gratuitamente desde microsoft.com/express/download.
No vamos a explicar con detalle cómo se trabaja con Visual Basic Express. Hay tutoriales en la sección de ayuda, y la verdad es que la propia ayuda es bastante buena, difícil de creer, ¿verdad? Lo que haremos es mostrarle cómo se usa Visual Basic Express para resolver un problema determinado de Windows Vista® (aunque este ejemplo también funcionará en versiones anteriores de Windows), y después puede continuar jugando por sí solo. El problema que vamos a resolver es éste: ¿cómo se abre un cuadro de diálogo Abrir archivo en Windows Vista?
Hace unos años explicamos cómo abrir un cuadro de diálogo Abrir archivo desde un script (consulte el artículo "¿Cómo puedo mostrar un cuadro de diálogo a los usuarios para que seleccionen archivos?" en microsoft.com/technet/scriptcenter/resources/qanda/jan05/hey0128.mspx). Ese artículo se publicó en enero de 2005, mucho antes de la presentación de Windows Vista. La solución usa el control ActiveX® UserAccounts.CommonDialog para abrir un cuadro de diálogo para abrir archivos, que le permite examinar el archivo que desee abrir. Por desgracia, este control se ha eliminado de Windows en la versión Windows Vista, lo que significa que esta solución no funcionará en sistemas recientes. Y no, nadie nos preguntó si esto era una idea buena. Lo que esto significa es que, por lo que nosotros sabemos, no hay manera de mostrar el cuadro de diálogo Abrir archivo mediante VBScript. Así que en vez de escribir un script, lo que haremos será usar Visual Basic para escribir un programa. Una de las cosas que hará esta aplicación es abrir el cuadro de diálogo Abrir archivo.
Sí, es cierto, el ejemplo vamos a mostrarle crea una aplicación completa en Visual Basic. Eso quizá asuste un poco al principio, pero pronto verá que, con Visual Basic Express, una aplicación completa puede ser tan fácil de escribir como un script. Esta aplicación consistirá en una ventana o un formulario que le permitirá hacer clic en un botón para abrir el cuadro de diálogo Abrir archivo. A continuación podrá seleccionar archivos de texto desde este cuadro de diálogo y nuestra aplicación leerá esos archivos de texto y mostrará una parte seleccionada del contenido del formulario.
Pues venga, manos a la obra. Empezaremos abriendo Visual Basic Express. Lo primero que tenemos que hacer es crear un proyecto nuevo, cosa que haremos seleccionando Nuevo proyecto desde el menú Archivo. Esto hará que aparezca el cuadro de diálogo Nuevo proyecto. (Tenga en cuenta que si usa una versión de Visual Basic Express anterior a la 2008 encontrará algunas pequeñas diferencias con lo que presentamos aquí). Vamos a crear una aplicación de Windows Forms, así que seleccione la plantilla de Aplicación de Windows Forms y escriba el nombre que desea asignar al proyecto. Hemos llamado al nuestro ReadFiles, como se puede ver en la figura 1.
Figura 1 Creación de un proyecto nuevo en Visual Basic (haga clic en la imagen para ampliarla)
Cuando se crea el proyecto por primera vez, aparece automáticamente un formulario nuevo con el que trabajar. La aplicación que vamos a crear presentará al usuario un formulario parecido al de la figura 2. Como mencionamos anteriormente, el formulario incluye un botón que, al hacer clic en él, mostrará el cuadro de diálogo Abrir archivo apuntando a la carpeta C:\Scripts. El usuario podrá seleccionar uno o más archivos de texto de cualquier parte del sistema de archivos. A continuación, la aplicación leerá la primera línea de cada uno de los archivos de texto seleccionados y mostrará los resultados en el cuadro de lista del formulario. (Si esto le suena familiar, lo más probable es que haya participado en la división de principiantes de los Juegos de Scripting 2008: microsoft.com/technet/scriptcenter/funzone/games/games08/bevent3.mspx.).
Figura 2 Formulario ReadFiles que se presentará a los usuarios
Para crear nuestro formulario, tenemos que arrastrar controles del Cuadro de herramientas al formulario del proyecto. De forma predeterminada, el Cuadro de herramientas está abierto en el lado izquierdo de la ventana de Visual Basic. (Si el Cuadro de herramientas no está abierto, haga clic en el botón Cuadro de herramientas del lado izquierdo del área de trabajo de Visual Basic y amplíe Todos los formularios Windows Forms). Haga clic en Botón en el Cuadro de herramientas y arrastre el mouse a través del formulario para crear el botón del tamaño que desee. Para agregar una etiqueta al botón, haga clic en el botón que acaba de agregar al formulario y escriba la etiqueta que desee. (También puede editar la propiedad Texto en el cuadro de diálogo Propiedades, que de forma predeterminada se encuentra en la esquina inferior derecha del espacio de trabajo de Visual Basic). A nuestro botón lo hemos llamado "Browse For Files". A continuación, haga clic en Cuadro de lista y vuelva a hacer clic en el formulario y arrastre el mouse para crear el cuadro de lista. Usaremos el cuadro de lista para mostrar las líneas que leemos de los archivos de texto.
Eso es todo lo que tenemos que hacer para crear nuestro formulario. Ahora viene la parte divertida: necesitamos que pase algo al hacer clic en el botón. Empecemos haciendo doble clic en el control Button del formulario. Esto abrirá un editor de código con una subrutina nueva ya creada automáticamente: la subrutina Button1_Click.
Private Sub Button1_Click _
  (ByVal sender As System.Object, _
   ByVal e As System.EventArgs) _
  Handles Button1.Click
End Sub
Esta subrutina se ejecutará cada vez que se haga clic en el botón de nuestro formulario. Como puede ver, esta subrutina por ahora está vacía; necesitamos agregar el código que dirá a la aplicación lo que hacer cuando se presione el botón. ¿Y qué es lo que queremos hacer? En primer lugar queremos hacer lo que al principio de este artículo prometimos que enseñaríamos: cómo abrir el cuadro de diálogo Abrir archivos. Igual que ocurre con casi todo lo que haga con Visual Basic, para ello usaremos Microsoft .NET Framework.
Empezaremos añadiendo un par de instrucciones de importación sobre la subrutina.
Imports System
Imports System.IO
Estas instrucciones especifican los espacios de nombres de .NET Framework. Como usaremos las clases incluidas en estos espacios de nombres, las importaremos aquí para sencillamente poder hacer referencia a las que necesitemos. Tenga en cuenta que hemos dicho de insertar estas instrucciones encima de la subrutina. Las instrucciones de importación son globales, lo que significa que no pueden ir dentro de una subrutina ni de una función; tienen que estar solas.
En VBScript, a menos que se agregue la instrucción Option Explicit en la parte superior del script, no necesita declarar las variables explícitamente. En Visual Basic esto se agrega automáticamente, así que tendrá que declarar todas las variables. Vamos a necesitar una variable que contenga una referencia al objeto OpenFileDialog (que representa el cuadro de diálogo Abrir archivo):
Dim dlg As Windows.Forms.OpenFileDialog
Ahora que hemos declarado (con Dim) una variable del tipo OpenFileDialog, podemos crear una versión nueva de este objeto, por ejemplo:
dlg = New OpenFileDialog()
Sin embargo, todavía no hemos mostrado el cuadro de diálogo. Primero debemos establecer algunas propiedades:
dlg.Multiselect = True
dlg.InitialDirectory = "c:\scripts"
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
La propiedad Multiselect especifica si se permitirá al usuario seleccionar más de un archivo desde el cuadro de diálogo. En este caso queremos que así sea, por tanto estableceremos esta propiedad en True. Configuramos la propiedad InitialDirectory en C:\Scripts. Si no establece esta propiedad, el cuadro de diálogo se abrirá en el directorio principal del equipo.
Y, por último, aunque no por ello menos importante, establecemos la propiedad Filter:
dlg.Filter = "txt files (*.txt)|*.txt|" & _
  "All files (*.*)|*.*"
Aquí filtramos los archivos que mostrará el cuadro de diálogo. Haremos que sólo se muestren archivos .txt. Al establecer estas propiedades obtendremos un cuadro de diálogo para abrir archivos parecido al de la figura 3.
Figura 3 Cuadro de diálogo Abrir mostrando sólo archivos de texto (haga clic en la imagen para ampliarla)
Por fin ya es hora de mostrar el cuadro de diálogo. Esto lo haremos con el método ShowDialog:
dlg.ShowDialog()
El método ShowDialog devuelve un valor que indica si el usuario hizo clic en Abrir para abrir los archivos seleccionados o si hizo clic en Cancelar para cerrar el cuadro de diálogo. Si hacen clic en Cancelar, no querremos hacer nada. Así que ponemos la llamada a ShowDialog en una instrucción If para asegurarnos de que han hecho clic en Abrir antes de continuar:
If dlg.ShowDialog() = _
  Windows.Forms.DialogResult.OK Then
Sí, lo sabemos, hemos comprobado la propiedad Aceptar en lugar de la propiedad Abrir. Que quede entre nosotros, pero el botón Abrir es realmente lo mismo que un botón Aceptar, es sólo que mostrar al usuario Aceptar tiene mucho más sentido.
Ahora necesitamos saber qué archivo o archivos ha seleccionado el usuario desde el cuadro de diálogo. Los nombres de archivo se incluyen en la propiedad FileNames del objeto OpenFileDialog, así que establecemos un bucle For Each para leer todos los nombres de archivo que contiene esta propiedad:
For Each strName In dlg.FileNames
¡Uy! Si nos hemos olvidado de declarar strName...
Dim strName As String
Ahora necesitamos abrir cada uno de estos archivos y leer información de ellos. La manera de hacerlo en Visual Basic es con un bloque Using:
Using sr As StreamReader = File.OpenText(strName)
Un bloque Using no es algo a lo que estén acostumbrados los creadores de scripts de VBScript, ya que en realidad no existe en VBScript. Visual Basic es un poco mejor (de acuerdo, en muchos casos mucho mejor) para administrar recursos del sistema que VBScript. La gracia de usar una instrucción Using es asegurarse de que se liberan recursos del sistema al salir del bloque. En este caso, sólo nos estamos asegurando de no depender de contenidos de archivos y bloques grandes de memoria.
Sabemos que esto suena un poco complicado. Pero en realidad, imagine que se trata de una instrucción Set. Sólo estamos creando una versión de un objeto nuevo, en este caso un objeto StreamReader, y le asignamos la secuencia de texto que devuelve el método File.OpenText. Tenga en cuenta que pasamos a OpenText el nombre del archivo que queremos abrir, el archivo de nuestra recopilación de FileNames que estamos recorriendo actualmente con el bucle.
Así que nuestra variable StreamReader, sr, tiene el contenido del archivo. Ahora necesitamos otra variable:
Dim strLine As String
Usaremos esta variable para almacenar la primera línea del archivo de texto que acabamos de abrir:
strLine = sr.ReadLine()
Leemos la primera línea del archivo llamando al método ReadLine en nuestro objeto StreamReader. (Recuerde que el objeto StreamReader tiene el contenido de nuestro archivo). Almacenamos esta línea de texto en la variable strLine.
Ahora sólo tenemos que llamar al método Add del objeto ListBox para agregar esta línea a nuestro cuadro de lista:
ListBox1.Items.Add(strLine)
Para este ejemplo, lo único que queremos es la primera línea del archivo, así que podemos cerrar nuestro StreamReader (ya no queremos obtener el texto completo de nuestro archivo) y cerrar nuestro bloque Using:
sr.Close()
End Using
Después de eso, realizamos un bucle completo para encontrar el siguiente archivo seleccionado desde el cuadro de diálogo de abrir archivos hasta leer todos los archivos seleccionados y agregar todas las líneas al cuadro de lista. El código completado se parece al de la figura 4.
Figura 4 Código completo de ReadFiles
Imports System
Imports System.IO

Public Class Form1

  Private Sub Button1_Click _
   (ByVal sender As System.Object, _
    ByVal e As System.EventArgs) _
   Handles Button1.Click
    Dim dlg As Windows.Forms.OpenFileDialog
    Dim strName As String

    dlg = New OpenFileDialog()

    dlg.Multiselect = True
    dlg.InitialDirectory = "c:\scripts"
    dlg.Filter = "txt files (*.txt)|" & _
      "*.txt|All files (*.*)|*.*"

    If dlg.ShowDialog() = _
     Windows.Forms.DialogResult.OK Then
      For Each strName In dlg.FileNames
        Using sr As StreamReader = _
         File.OpenText(strName)
          Dim strLine As String
          strLine = sr.ReadLine()
          ListBox1.Items.Add(strLine)
          sr.Close()
        End Using
      Next
    End If
Ya ve, le dijimos que crear una aplicación no iba a ser mucho más difícil que crear un script.
Puede probar la aplicación presionando F5 (o presionando el botón Iniciar depuración de la barra de herramientas Depuración). Cuando se hace clic en el botón y después se seleccionan uno o más archivos del cuadro de diálogo Abrir archivos, los resultados deberían ser parecidos a los de la figura 5.
Figura 5 Primeras líneas de los archivos seleccionados mostradas en el cuadro de lista
Cuando la aplicación se ejecute como desea, seleccione Generar ReadFiles (o el nombre que le haya puesto a su proyecto) desde el menú Generar. De esta forma se creará un archivo .exe llamado ReadFiles.exe que se puede ejecutar del mismo modo que haría con cualquier otra aplicación, y podrá distribuirlo a sus usuarios.
Somos conscientes de que esto puede que no parezca una vía rápida para usar el cuadro de diálogo de abrir archivos. Pero si considera que esto no es posible hacerlo escribiendo un script desde Windows Vista, entonces la opción de escribir una pequeña aplicación es un pequeño precio que se puede pagar. Es como tener que pagar para poder llegar a algún sitio cuando se está en la autopista: puede ser un poco complicado, pero al final se llega donde se quería ir.
Una ventaja añadida de usar Visual Basic para algo como esto es que ahora usted ha empezado a trabajar con una herramienta que es más eficaz que VBScript y que le permite crear fácilmente aplicaciones con una interfaz de usuario agradable. Todo un lujo. Los administradores de sistemas también encontrarán muchos otros usos para Visual Basic.
Y recuerde, no necesita volver a aprender cómo conducir para usar el nuevo carril de pago; sólo necesita acostumbrarse al hecho de que los automóviles que tiene delante se mueven realmente. De la misma manera, si ya conoce VBScript, no necesita aprender un lenguaje completamente nuevo desde cero para usar Visual Basic, sólo necesita acostumbrarse al hecho que puede hacer muchas más cosas.
Dr. Scripto's Scripting Perplexer
El desafío mensual que pone a prueba no sólo sus habilidades para resolver rompecabezas, también sus habilidades para el scripting.

Agosto de 2008: Alfabeto de scripting
En el enigma de este mes, tiene que insertar las letras de la A a la Z en los espacios en blanco para descubrir una palabra relacionada de alguna manera con el scripting. Cada letra (de la A a la Z) sólo se debe usar una vez y las letras no aparecen por orden alfabético. La letra insertada podría ser el principio de la palabra, el final de la palabra o estar en alguna parte en el medio de la palabra. Por ejemplo, en la primera línea hemos insertado la letra C para completar la palabra SCRIPT:

RESPUESTA:
Dr. Scripto's Scripting Perplexer
Respuesta: Alfabeto de scripting, agosto de 2008

Los chicos de la sección Scripting Guys 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.


Archivos del escritorio Información general sobre Servicios de implementación de Windows
Wes Miller

Contenido
WDS en Windows Server 2003
WDS en Windows Server 2008
Tomar una decisión
Consideraciones
Introducción a WDS
Imágenes de captura
Información general sobre capturas
Migración de imágenes
Instalación desatendida
El artículo del mes pasado revisó el historial de herramientas de implementación PXE (entorno de ejecución previo al arranque) de Microsoft. Este mes, profundizaremos en los Servicios de Implementación de Windows (WDS), tratando específicamente las versiones presentadas para Windows Server 2003 y la versión actualizada que se lanzó con Windows Server.
2008. Después de eso, le explicaré como empezar a usar WDS.
Lo mejor es pensar que WDS es como una nueva versión de RIS (Servicios de instalación remota). Aunque los dos comparten algunos componentes clave, y aunque de hecho la versión de WDS en Windows Server® 2003 tiene un modo heredado que es funcionalmente idéntico a RIS, la propia infraestructura de WDS se ejecuta en modo nativo y en el 50 por ciento de modo mixto es completamente nuevo.

WDS en Windows Server 2003
Al mismo tiempo que se lanzó al mercado Windows Vista®, se empezó a ofrecer WDS. Este paso era necesario porque la instalación de Windows Vista se volvió a diseñar completamente con la arquitectura WIM (formato de imágenes Windows®), haciendo que RIS no fuera capaz de implementar Windows Vista (y, en última instancia, Windows Server 2008). En ese momento se presentó WDS como descarga fuera de banda para clientes que ejecutaran Windows Server 2003 SP1. Con SP2, WDS suplantó completamente a RIS.
Debe recordar que como WDS en Windows Server 2003 tiene compatibilidad completa con productos anteriores, no es necesario cambiar a modo nativo al instalar WDS en sistemas Windows Server 2003 SP2. Puede continuar ejecutándolo en modo heredado (funcionando funcionalmente como servidor RIS) o en modo mixto, permitiendo el inicio de WDS o de RIS.
Además de poder implementar Windows Vista y Windows Server 2008, cuando WDS se ejecuta en modo nativo o en la mitad nativa del modo mixto tiene varias características adicionales. En lugar de usar el motor de instalación de modo kernel de Windows y el núcleo tradicional de instalación del que hablé el mes pasado (technet.microsoft.com/magazine/cc645015), WDS usa Windows PE como su entorno de preinstalación de arranque e implementa imágenes basadas en WIM en vez de usar instalaciones basadas en RISetup o en RIPrep. De este manera, las implementaciones son más rápidas, más fáciles y más seguras.
Además, muchas de las limitaciones que mencioné el mes pasado, como la necesidad de usar caracteres ANSI (American National Standards Institute) se eliminan ya que Windows PE puede visualizar los mismos juegos de caracteres que una instalación completa de Windows.
Además, WDS tiene ahora unas cuantas herramientas que se echaban mucho en falta en RIS, como un complemento MMC (Microsoft® Management Console) que ayude en la administración, y una herramienta de configuración de línea de comandos muy completa que habilita las capacidades de configuración mucho más allá de lo que permitía RIS.
Dado que tanto el modo heredado como el mixto permiten implementar imágenes de Windows basadas en RISetup y RIPrep, debe tener en cuenta lo siguiente. RIS solía usar un componente llamado SIS (almacenamiento de instancia única) para optimizar el almacenamiento de imágenes en disco. SIS, que posteriormente se lanzó como parte de Windows Storage Server 2003, usaba un servicio llamado Groveler, que se ejecuta en segundo plano en servidores RIS (y WDS), buscando archivos idénticos. Si coinciden el tamaño y el valor hash de cualquier archivo, SIS guarda una copia en su propia carpeta de almacén común SIS y después crea un vínculo permanente a cada una de las versiones originales que encontró.
SIS está diseñado para afectar lo menos posible al uso del procesador al tiempo que permite ahorros considerables de almacenamiento. Era un gran concepto que se utilizó por primera vez en RIS y después se extendió su uso en la plataforma de Windows Server. Pero SIS ya no se usa a partir de WDS.
WDS en Windows Server 2003 en modo nativo (y siempre en Windows Server 2008) usa imágenes WIM para la instalación. Tiene su propia compresión y, lo que es más importante, su propio modelo de almacenamiento de archivos de instancia, por eso no usa SIS para nada. El almacén de imágenes reemplaza al modelo de almacenamiento que usa RIS por un diseño nuevo basado en WIM para WDS. Se puede consultar más información sobre SIS en go.microsoft.com/fwlink/?LinkId=120302.

WDS en Windows Server 2008
En Windows Server 2008, WDS se ha convertido en un superconjunto y en un subconjunto de la funcionalidad de Windows Server 2003. Ahora puede implementar las imágenes a través de multidifusión en el modo independiente que usa un servidor de transporte, un nuevo servidor de TFTP (Protocolo trivial de transferencia de archivos) con mejor rendimiento, soporte para sistemas x64 basados en EFI (Extensible Firmware Interface), e informes mejorados de métrica de instalación. Trataré este tema en el artículo del mes que viene.
Tenga en cuenta que hay una característica de WDS en Windows Server 2003 que se ha dejado de incorporar en Windows Server 2008: el soporte de instalaciones heredadas. La capacidad de implementar imágenes RISetup/RIPrep o de usar el selector de OS de RIS heredado para iniciar una instalación ya no están disponibles.

Elegir una cosa
Una de las preguntas más frecuentes que me han hecho desde que se lanzó al mercado Windows Server 2008 es: ¿qué versión de WDS debo usar? La respuesta depende de si está implementando versiones de Windows anteriores a Windows Vista y, si fuera el caso, si está listo para hacer la transición de RISetup y/o imágenes basadas en RIPrep a usar explícitamente una instalación basada en WIM.
WDS, incluso en Windows Server 2008, es capaz de implementar versiones anteriores de Windows hasta Windows 2000 si se encuentra en una imagen WIM, y puede hacerlo usando multidifusión. Así que si hace la transición de RIS a WDS en este momento y piensa incorporar Windows Server 2008 en su infraestructura (y está dispuesto a migrar de imágenes basadas en RIS a basadas en WDS) entonces una migración a WDS en Windows Server 2008 puede ser una buena idea.
También podría migrar de RIS a WDS en el propio sistema Windows Server 2003, siendo esto lo que sucede básicamente cuando se instala SP2 y cambia a imágenes basadas en WDS. Después podría actualizar a Windows Server 2008 WDS y listo.
Aunque este no es el modelo que yo recomendaría. Al igual que con muchas versiones de Windows Server anteriores a la 2008, Microsoft recomienda migrar (frente a actualizar el propio servidor) de una versión de Windows Server a otra.
Y como mencioné anteriormente, considerar versiones de x64 de Windows Server 2008 seguramente tiene mucho más sentido en su infraestructura que lo tenía en las versiones de x64 de Windows Server 2003. Si hace esa transición, realizar una migración de servidor a servidor de WDS en Windows Server 2003 a Windows Server 2008 será relativamente más fácil y mucho más seguro que comparado con una actualización del propio servidor.

Consideraciones
Hay una serie de puntos que deben tenerse en cuenta cuando trabaje en la implementación de WDS. Tenga en cuenta que en realidad no hay requisitos nuevos para WDS (RIS tenía muchas de estas mismas consideraciones) pero deseará tenerlos en cuenta tanto si está creando un solo servidor de WDS como si crea una infraestructura entera:
Privilegios hay elementos principales que debe recordar al administrar un servidor WDS. Es necesario autorizar un servidor WDS en Active Directory® igual que se hacía con RIS. Para ello debe ser administrador de dominio en el dominio raíz del bosque, administrador de empresa o se le deben haber delegado los privilegios apropiados. También es necesario ser administrador del dominio para administrar el servidor WDS y, por supuesto, también debe ser administrador en el propio servidor WDS.
Virtualización Cuando se ejecuta en una instancia virtualizada de Windows Server 2003 o Windows Server 2008 bajo Microsoft Virtual PC o Virtual Server y al comunicarse con un PC cliente en la misma instalación de Virtual PC o de Virtual Server, se puede dar una condición de anticipación al inicio del arranque PXE que puede provocar que el cliente funcione con extrema lentitud o que no responda en absoluto. Se recomienda virtualizar clientes o servidores, pero no los dos (especialmente en el mismo sistema host). Personalmente, yo no recomendaría virtualizar un servidor WDS para usarlo en producción, principalmente debido al punto siguiente.
Otros Servicios WDS, como RIS, no siempre se lleva bien con otros servicios de producción. En especial, he visto problemas con RIS/WDS al ejecutarse en un sistema de producción que también ejecuta Microsoft Exchange Server, Systems Management Server (SMS) y System Center Configuration Manager (SCCM).
Normalmente recomiendo que WDS sea la única función del servidor si se está usando para producción con más de unos pocos clientes. Esto no es exclusivo de WDS, antes de su implementación debe considerar y probar con cuidado si debe mezclar o no las funciones de productos de servidor de Windows.
Vínculos lentos o de alta latencia Al igual que ocurre con RIS, WDS no está pensado para usarse a través de una conexión de poco ancho de banda o una conexión de latencia alta como sería un vínculo por satélite; el protocolo de enlace PXE puede ser problemático y la descarga de imágenes se hará interminables, si es que funciona.

Introducción a WDS
Más sobre WDS

  • Guía paso a paso para WDS en Windows Server 2003
  • Guía paso a paso para Servicios de implementación de Windows (Windows Server 2008)
  • Implementación y administración de la actualización de WDS en Windows Server 2003
  • Documentación para Servicios de implementación de Windows en Windows Server 2008
  • Referencia Técnica: Servicios de implementación de Windows (Windows Server 2008)
Para empezar, tiene que decidir si va a usar WDS en Windows Server 2003 o en Windows Server 2008. Si usa Windows Server 2003, le recomiendo empezar con SP2, que de forma nativa incluye WDS como componente opcional (reemplazando a RIS), en vez de usar SP1 y la descarga opcional de WDS anteriormente incluida en el Kit de instalación automatizada de Windows (WAIK).
Para cualquiera de las versiones de Windows Server deseará crear su sistema del servidor. Debería usar una tarjeta de interfaz de red (NIC) de alta calidad con una capacidad de como mínimo 100 Mbps o más. No use la formación de equipos de NIC, ya que la infraestructura PXE de WDS puede experimentar problemas si lo hace. Tenga en cuenta que si usa Windows Server 2008, puede instalar WDS en Server Core o en la instalación completa de Windows Server 2008.
WDS se instala en Windows Server 2003 como componente opcional (como ocurría con RIS anteriormente). Se puede instalar durante la instalación del sistema operativo o posteriormente ejecutando Agregar o quitar programas | Agregar o quitar componentes de Windows (o ejecutando sysocmgr.exe desde el símbolo del sistema). WDS se instala en Windows Server 2008 como función y se puede instalar mediante el asistente de configuración inicial (haga clic en Agregar funciones | Siguiente | y seleccione Servicios de implementación de Windows), mediante el Administrador de servidores (con los mismos pasos que el asistente para configuración inicial) o desde el símbolo del sistema ejecutando ServerManagerCmd –install WDS.
Cuando haya instalado WDS tendrá que configurarlo. Desde el menú Inicio de Windows, vaya a Herramientas administrativas y seleccione Servicios de implementación de Windows. Cuando se inicie MMC, haga clic con el botón secundario del mouse en su servidor y seleccione "Configurar servidor" en el menú para iniciar el asistente para configuración.
Si está instalando en Windows Server 2003 y actualizando un servidor RIS existente, deseará especificar el directorio de RemoteInstall existente para que la instalación heredada se pueda actualizar al modo mixto. Si ese fuera el caso, debería asegurarse de que el directorio Remote-Install no se encuentra en la partición del sistema, ya que ello podría afectar al rendimiento.
La figura 1 muestra la consola de WDS en Windows Server 2008 antes de que haya finalizado el asistente para configuración. La figura 2 muestra la Página de bienvenida al asistente de configuración de WDS en Windows Server 2008. La figura 3 muestra el paso de configuración de PXE del asistente para configuración de WDS. En este paso puede determinar si el servidor debe responder a cualquier cliente (útil para la configuración inicial), responder sólo a equipos cliente conocidos (los que se han preparado previamente en Active Directory) o responder a todos clientes (y si debe retener opcionalmente todos los clientes desconocidos para que un administrador pueda elegir qué hacer).
Figura 1 WDS instalado pero aún sin configurar
Figura 2 Asistente para configuración de WDS
Figura 3 Elección de una directiva de respuesta para el servidor de PXE
La figura 4 muestra un servidor WDS completamente configurado en Windows Server 2008 (sin imágenes instaladas todavía) con su página de propiedades abierta. Si usa un servidor que ya es un protocolo de configuración dinámica de host (DHCP), asegúrese de establecer la opción DHCP 60 en PXEClient y que WDS no oiga el puerto 67. De este modo permitirá que el servidor WDS se salte un paso del proceso de detección de PXE (como ya comenté en el artículo del mes pasado).
Figura 4 Servidor WDS completamente configurado en Windows Server 2008
Cuando el asistente finalice podrá agregar imágenes nuevas. Se pueden agregar dos tipos de imágenes a un servidor WDS que se ejecuta en modo nativo o mixto:
  • Imágenes de arranque: son las imágenes que contienen Windows PE 2.x, normalmente se copian desde Windows Server 2008 o desde el DVD de instalación de Windows Vista SP1. Tenga en cuenta que si usa multidifusión querrá usar el archivo \Sources\Boot.wim desde Windows Server 2008 para las imágenes de arranque (incluso si implementa Windows Vista o un sistema operativo heredado). Las imágenes de arranque normalmente consisten en Windows PE, Windows Setup.exe y otras dependencias.
  • Imágenes de instalación: se componen de imágenes del sistema operativo Windows, normalmente el archivo \Sources\Install.wim de Windows Vista o de Windows Server 2008.
Para agregar una imagen de inicio predeterminada o una imagen de instalación predeterminada, los pasos son prácticamente los mismos. Se empieza cada proceso haciendo clic con el botón secundario del mouse en el tipo de imagen y eligiendo agregar una imagen de ese tipo.
Para una imagen de instalación necesita especificar un nombre para el grupo de imágenes (ya que un WIM predeterminado en el DVD de Windows contiene más de un tipo de sistema operativo). A continuación, examine el boot.wim o install.wim apropiados que desea agregar y haga clic en Abrir. Para imágenes de instalación, desactive todas las imágenes de volumen (imágenes de sistema operativo) que no desee agregar al servidor WDS. Por último, puede instalar por PXE clientes con estas imágenes predeterminadas.

Imágenes de captura
Para crear las imágenes personalizadas de sistema operativo, necesita crear una imagen de captura, es decir, una imagen de Windows PE que se diseña para permitirle capturar un sistema Windows en forma de imagen WIM. La manera más fácil de hacerlo es usar una imagen boot.wim que haya instalado anteriormente.
Haga clic con el botón secundario en la imagen y elija Crear imagen de inicio de captura. Especifique el nombre y la descripción que usar para su imagen, y la ubicación para guardar una copia local del archivo .wim en caso de problemas de conectividad de la red al implementar la imagen de captura. A continuación, siga el asistente hasta que termine y haga clic en Finalizar.
Después, haga clic con el botón secundario en la carpeta de imágenes de arranque de MMC de WDS y haga clic en Agregar imagen de inicio. Siga las instrucciones del asistente como hizo anteriormente. Cuando haya terminado, estará listo para capturar una imagen de instalación de Windows.

Información general sobre capturas
Antes de capturar una imagen de sistema operativo debe, por supuesto, instalar Windows y asegurarse de que incluye todas las aplicaciones, personalizaciones y actualizaciones que desee. A continuación, lo que debe hacer es ejecutar Sysprep en el sistema; sólo se pueden capturar imágenes de instalación de Windows desde sistemas preparados con Sysprep. Es necesario especificar una ubicación local válida para guardar la imagen nueva (para evitar posibles daños) y una extensión de archivo *.wim.
Después de configurar el sistema y de copiar la versión correcta de sysprep.exe al sistema, debe seguir estos pasos:
  1. Desde el símbolo del sistema que está en el equipo de referencia, cambie al directorio donde se encuentra sysprep.exe.
  2. Inicie Sysprep (también puede hacerse mediante doble clic en sysprep.exe y especificando las opciones manualmente). En equipos que usan Windows Vista o Windows Server 2008, ejecute el comando sysprep /oobe /generalize /reboot. En equipos que trabajan con versiones anteriores de Windows, ejecute SYSPREP –mini –reseal –reboot.
  3. Cuando el equipo se reinicie, arranque con PXE (el proceso puede variar en función del sistema cliente).
  4. Desde el menú de arranque, seleccione la imagen de captura WDS y haga clic en Siguiente.
  5. Elija la unidad de disco, el nombre y la descripción para la imagen.
  6. Como se mencionó anteriormente, sólo estarán visibles los sistemas que se hayan preparado con Sysprep. Se trata de una limitación por diseño que no se puede eludir.
  7. Haga clic en Examinar y examine la carpeta local donde desea almacenar la imagen de instalación capturada. La ubicación que elija puede ser una unidad de disco asignada de la red.
  8. Seleccione la opción de cargar imagen al servidor de WDS.
  9. Escriba el nombre del servidor de WDS y haga clic en Conectar.
10. Desde la lista Grupo de imágenes, seleccione el grupo de imágenes donde desea almacenar la imagen y haga clic en Finalizar.
Esta imagen ahora estará lista para implementarse desde el servidor WDS. Hay una cosa que los usuarios veteranos de RIS pueden haber advertido: no he capturado esta imagen de Windows en vivo. WDS requiere que el sistema que se va a capturar esté sin conexión.
RIPrep, en RIS, podía capturar sistemas conectados (de hecho, esto era algo obligatorio). Era un proceso extremadamente frágil. Creo que encontrará el proceso de captura en WDS relativamente fácil y mucho más sólido.

Migración de imágenes
Si ha estado usando RIS anteriormente, seguro que tiene algunas imágenes por ahí. Aquellas imágenes que estén basadas en RISetup (una instalación con scripts) ya no le servirán para nada. Sin embargo, puede migrar las imágenes de RIPrep a imágenes basadas en WIM de WDS. De hecho, WDS incluso permite migrar las imágenes mediante WDSUtil (esto lo explicaré con más detalle el mes próximo).
Normalmente recomiendo hacerlo sólo si se ha invertido una cantidad considerable de tiempo en una imagen que no desea perder. El proceso funciona bastante bien, pero me han hablado de algunos errores durante la conversión, lo que normalmente significa que habría que volver a crear la imagen desde cero en todo caso.

Instalación desatendida
Crear una imagen como hice anteriormente genera una imagen que se puede instalar manualmente. Para una instalación más automatizada o completamente automatizada, es necesario usar dos archivos de instalación desatendida. El propio WDS necesita un archivo de respuestas (unattend.xml, almacenado en el directorio \RemoteInstall\WDSClientUnattend del servidor WDS) que automatiza el proceso de instalación de WDS. El segundo es el propio archivo de instalación desatendida. Para Windows Vista o posterior, se trata del archivo unattend.xml. Para versiones anteriores de Windows, es un archivo sysprep.inf almacenado en una estructura de directorio $OEM$ o en \Unattend del directorio de cada imagen. Este archivo se usa para automatizar la instalación real de Windows cuando WDS se ha completado.
Para crear el archivo Unattend de WDS, cree un archivo unattend.xml para WDS con WAIK. Copie este archivo al directorio RemoteInstall o a un subdirectorio. Haga clic con el botón secundario en la imagen de instalación para la que desea usar el archivo unattend y haga clic en Propiedades. En la ficha Cliente, seleccione Habilitar instalación desatendida y especifique el archivo unattend.xml anterior.
Para crear el archivo unattend de la imagen para imágenes anteriores a Windows Vista, copie el archivo sysprep.inf al directorio $OEM$ para la imagen, por ejemplo D:\RemoteInstall\Images\Windows XP\SP2\$OEM$\$1\sysprep\sysprep.inf. Para imágenes de Windows Vista, especifique la imagen que desea asociar, haga clic en Propiedades, y después en la ficha General, haga clic en Permitir que la imagen se instale en modo desatendido. A continuación, especifique el archivo unattend.xml que se usará para la instalación.
Ya casi hemos terminado. Esta columna debería haberle servido como introducción a WDS. El próximo mes, profundizaremos con más detalle en WDSUtil, en el almacén de imágenes y en la multidifusión. Después concluiremos la serie con un estudio detallado sobre cómo y por qué debería plantearse la posibilidad de crear una solución de implementación personalizada de WDS. Hasta entonces, eche un vistazo a la barra lateral "Más sobre WDS" que acompaña a este artículo.

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


Vigilancia de seguridad Contraseñas y tarjetas de crédito, 2ª parte
Jesper M. Johansson

Contenido
Proceso de inicio de sesión pseudomultifactor
El problema de los complementos del explorador
El autenticador no debe cambiar nunca
Uso de una versión anterior menos segura de las contraseñas
Cómo omitir el inicio de sesión pseudomultifactor
Problemas con contraseñas comprometidas
Algunas ventajas
Engañar a los usuarios con una imagen atractiva
Abrir o no abrir
Ofrecer una comunicación segura
La privacidad está en juego
Bienvenido a la segunda entrega de esta serie de tres partes sobre cómo el sector de TI confunde a los consumidores en lugar de ayudarles con los problemas de seguridad. En el número de julio de 2008 de TechNet Magazine hablaba de consejos improcedentes e incorrectos sobre seguridad, así como de flujos de trabajo confusos de inicio de sesión. Si no ha leído aún la primera parte, la encontrará
en technet.microsoft.com/magazine/cc626076. Expuse la idea de lo común que sigue siendo aún el confundir a los consumidores con consejos de seguridad insuficientes y flujos de trabajo incorrectos de inicio de sesión y el socavar los esfuerzos de los mismos a la hora de proteger su información personal.
En esta entrega seguiré tratando este tema, aportando ejemplos más reales tomados del mundo de la seguridad del consumidor. La última entrega de esta serie, que incluirá una "llamada a las armas" para los profesionales de la seguridad de todo el mundo, se publicará en el próximo número de TechNet Magazine.

Proceso de inicio de sesión pseudomultifactor
En octubre de 2005, el Federal Financial Institutions Examination Council (FFIEC) publicó sus directrices con el título "Authentication in an Internet Banking Environment" (consulte www.ffiec.gov/press/pr101205.htm). El calendario para su implementación era de tan sólo 14 meses, por lo que las instituciones financieras de EE. UU. pronto se encontraron con numerosas dificultades para encontrar la manera de cumplir con las nuevas directrices.
La mayoría de las instituciones no consiguieron realizarlo en el plazo previsto. Muchas de las instituciones que al final cumplieron con las directrices, lo hicieron con medidas destinadas exclusivamente a satisfacer dichas directrices. En otras palabras, las instituciones tomaron medidas que no aumentaban en absoluto la seguridad de los clientes, ya que se trata en realidad de meros ensayos dentro del "escenario de la seguridad". Algunos de los ejemplos más interesantes de soluciones poco útiles son aquellas soluciones que intentan crear la autenticación multifactor sin ser en realidad multifactor.
Tomemos, por ejemplo, la tecnología que mide la cadencia de escritura cuando un usuario escribe la contraseña. Esta solución empleada en un sitio web presenta un cuadro de diálogo de inicio de sesión con exactamente el mismo aspecto que el anterior cuadro de diálogo del mismo tipo. Este cuadro de diálogo, sin embargo, es ahora un objeto de Adobe Flash.
El objeto de Flash registra la cadencia de escritura del usuario que incluye, entre otras, características como el tiempo que dura la presión de las teclas y el intervalo de tiempo que transcurre entre cada presión de teclas. Estos datos y la contraseña se envían al sitio web, donde se comparan con los valores almacenados. El inicio de sesión se acepta cuando los datos de la cadencia de escritura se sitúan dentro de determinadas variaciones de los datos almacenados y la contraseña coincide. La idea general es que esto permita al sitio usar un método pseudobiométrico de autenticación sin tener que instalar hardware de terceros en el cliente.
De ahora en adelante, denominaré a este proceso autenticación de pseudomultifactor. No se trata de una autenticación multifactor real. Esta mide dos o más de los siguientes factores canónicos:
  • Algo que el usuario tiene (como una tarjeta inteligente)
  • Algo que el usuario sabe (como una contraseña)
  • Algo que el usuario es (como una huella dactilar)
En lugar de incluir varios factores en el proceso de autenticación, la autenticación pseudomultifactor lee varios parámetros a partir de un solo factor: la contraseña. A continuación, emplea estos parámetros adicionales para sacar las conclusiones pertinentes acerca de algo que el usuario es.
La tecnología usada para la autenticación pseudomultifactor presenta muchas imperfecciones que, en conjunto, convierten a esta tecnología en una herramienta realmente ineficaz a la hora de resolver los problemas de seguridad para los que está diseñada.

El problema de los complementos del explorador
Los sistemas de autenticación pseudomultifactor se basan en complementos del explorador para ofrecer el procesamiento sofisticado de cliente que necesitan. Está claro que todos los programas de software presentan errores y algunos de estos provocan vulnerabilidades. Estas vulnerabilidades se convierten en un verdadero problema cuando la actualización del software es un proceso complicado y el usuario no está seguro de haber instalado una actualización.
Los complementos del explorador son responsables de estos dos tipos de características: son difíciles de actualizar y no ofrecen al usuario información detallada sobre el grado de actualización de la versión instalada. Como resultado, el usuario tiene que exponer en Internet un componente de software que, de lo contrario, no hubiera sido necesario hacerlo.
En determinadas ocasiones mantener actualizados un complemento requiere visitas frecuentes el sitio web del complemento para descargar las actualizaciones necesarias. Sobre decir que este tipo de situación no se produce normalmente para la mayoría de los usuarios. Cualquier sistema que requiera que un usuario final exponga otro software no relacionado a Internet sólo para proporcionar funciones de seguridad debe ser tomado en gran consideración.

El autenticador no debe cambiar nunca
El factor "algo que forma parte de usted" tiene un rasgo, quizás incluso un defecto, que no afecta a los otros dos factores. Si bien es posible cambiar contraseñas (algo que sabe) y producir nuevos tokens de seguridad (algo que tiene), el número de autenticadores biométricos que puede usar es bastante limitado. Con las huellas dactilares, por ejemplo, se suele disponer de diez de por vida. Si perdiera uno de estos dígitos en un accidente, normalmente no podría reemplazarlo.
Vamos a ver ahora cómo se aplica esto al ejemplo de inicio de sesión pseudomultifactor. Las métricas reunidas como parte de otro factor no se pueden reemplazar ni modificar fácilmente. En efecto, cuando se cambia una contraseña, también lo hace la manera en que el usuario la escribe, pero no lo hará la forma en que normalmente presiona las teclas en el teclado. Esta técnica se basa precisamente en ese aspecto. Si estas métricas se ven comprometidas, podrían sintetizarse. Como mínimo, un atacante puede capturar estas métricas y reproducirlas.

Uso de una versión anterior menos segura de las contraseñas
Una buena idea consiste en usar contraseñas largas y cambiarlas a menudo. Además, como comenté en la primera parte de esta serie y a diferencia de determinadas opiniones, otra buena práctica consiste en registrar las contraseñas, por supuesto de un modo seguro. Sin embargo, estas prácticas no son propicias para escribir contraseñas de forma manual. Una contraseña larga es más difícil de escribir y una contraseña registrada resulta mucho más útil cuando se puede copiar y pegar. Una de las mejores maneras de realizar el seguimiento de cien o más contraseñas es emplear una utilidad de software como, por ejemplo, Password Safe (que encontrará en sourceforge.net/projects/passwordsafe). Este tipo de herramienta permite generar contraseñas completamente aleatorias, almacenarlas en un formulario cifrado y pegarlas directamente en los cuadros de diálogo de inicio de sesión. De hecho, con herramientas como éstas, no le hará falta conocer ni las contraseñas.
Pero ahí está el problema: no es posible medir la cadencia de escritura a menos que el usuario escriba la contraseña. Y si además tiene que escribir la contraseña en un objeto que mide la cadencia de escritura, ahí es donde empieza a fallar esta técnica de administración de contraseñas. Escribir correctamente una contraseña completamente aleatoria de 15 caracteres no es una tarea sencilla. Por lo tanto, los usuarios optarán generalmente por simplificar sus contraseñas cuando usen este tipo de sistema. Aun así, una contraseña completamente aleatoria de 15 caracteres es en sí mucho más segura que una contraseña más corta emparejada con un sistema de autenticación pseudomultifactor.
En efecto, la autenticación pseudomultifactor, implementada exclusivamente, obliga a los usuarios a usar contraseñas menos seguras. Desgraciadamente, como comprobará en breve, tener en cuenta a usuarios que emplean técnicas correctas de administración de contraseñas obvia prácticamente cualquier valor que ofrezcan los sistemas de autenticación pseudomultifactor.

Cómo omitir el inicio de sesión pseudomultifactor
Aunque un sitio ejecute la autenticación pseudomultifactor, debe admitir asimismo una forma de omitir dicho sistema. En primer lugar, pocos sitios pueden obligar a todos sus usuarios a que instalen una tecnología de "cuartos" para poder tener acceso al sitio. Parte de estos usuarios como, por ejemplo, algunos autores de TechNet Magazine, siempre se negarán a instalar este tipo de software.
En segundo lugar, la cadencia de escritura puede cambiar por muchos motivos que los sitios deberán contemplar. Por ejemplo, supongamos que un usuario se hace un esguince en la muñeca y que esto modifica temporalmente su cadencia de escritura. ¿Cómo podrá obtener acceso al sitio si éste analiza su cadencia y piensa que otra persona está intentando iniciar sesión con sus credenciales de usuario? Si la lesión fuera permanente, el usuario podría restablecer el valor de cadencia almacenado. Sin embargo, como se trata de una lesión temporal, el usuario probablemente no desea restablecer el valor almacenado, ya que asume que su cadencia de escritura pronto volverá más o menos a su estado original.
Por último, no todos los usuarios son capaces de usar sistemas de autenticación pseudomultifactor. Por ejemplo, una persona minusválida que interactúa con el equipo a través de una interfaz de reconocimiento de voz podría no ser capaz de rellenar el cuadro de diálogo, en función de si evita o no la entrada mediante programación. En ese caso, lo más probable es que la ley exija un sistema alternativo compatible con los usuarios minusválidos.
La forma más sencilla y directa de aceptar todas estas situaciones consiste en admitir también la autenticación estándar basada en contraseña.

Problemas con contraseñas comprometidas
Los sistemas de autenticación pseudomultifactor pretenden solucionar varios problemas asociados con la autenticación basada en contraseña. Sin embargo, estos sistemas no consiguen abordar cada una de las principales formas en que pueden comprometerse las contraseñas. Existen cinco maneras principales en las que los sistemas basados en autenticación por contraseña pueden verse comprometidos, entendiendo por "verse comprometidos" el hecho de que un atacante obtiene y usa la contraseña de otro usuario:
  • Averiguación de contraseñas
  • Capturadores de teclado
  • Ataques de suplantación de identidad (phishing)
  • Preguntar al usuario
  • Irrumpir en cualquier sistema que almacena la contraseña o un hash de ésta
La averiguación de contraseñas ha dejado de ser un método de ataque común para los atacantes y se ha ido sustituyendo progresivamente por otros métodos como los capturadores de teclado o la suplantación de identidad. La averiguación de contraseñas, además, sólo queda mitigada en parte por la autenticación pseudomultifactor. Es poco probable que un método normal de averiguación de contraseñas funcione con un sistema de autenticación pseudomultifactor, ya que el atacante debe adivinar la contraseña y la cadencia de escritura. Aunque en teoría es posible sintetizar la métrica de escritura, rara vez es necesario hacerlo, ya que los verdaderos datos normalmente se pueden capturar mediante un ataque de suplantación de identidad o un capturador de teclado. Asimismo, si el sistema ofrece además una interfaz estándar de inicio de sesión sólo mediante contraseña, el atacante puede usar simplemente ese sistema para adivinar la contraseña.
La mejor manera de combatir los ataques de averiguación de contraseñas es usar contraseñas seguras. Si enseñáramos a los usuarios a emplear contraseñas más seguras, posiblemente con la ayuda de herramientas, la autenticación pseudomultifactor no sería necesaria. (En cambio, las contraseñas más sencillas que se emplean normalmente con los sistemas de autenticación pseudomultifactor hacen en realidad más viable el método de averiguación de contraseñas.) Por lo tanto, cualquier valor que pueda ofrecerse en este caso para mitigar la averiguación de contraseñas sólo agrega valor si la implementación no es compatible con el inicio de sesión de sólo contraseña. Y, como he comentado, esto es prácticamente imposible. Es decir, si los usuarios emplean contraseñas menos seguras en presencia de sistemas de autenticación pseudomultifactor, la averiguación de contraseñas puede convertirse de nuevo en un método de ataque viable, de forma que la autenticación pseudomultifactor reduciría la seguridad en lugar de aumentarla. Por lo tanto, es necesario investigar más sobre este tema.
La autenticación pseudomultifactor tampoco es efectiva para resolver los problemas derivados de ataques de capturadores de teclado. Aunque a día de hoy no tengo noticia de ningún capturador de teclado de uso habitual que capture la cadencia de escritura, no hay motivo alguno por el que no se pueda diseñar uno que lo haga. Un capturador de teclado es un hardware que se coloca entre el teclado y el equipo o un software que captura las pulsaciones de teclas. En cualquier caso, el capturador tiene acceso completo a todos los datos que usa la solución de autenticación pseudomultifactor.
De hecho, el capturador de teclado puede incluso tener acceso a más datos, ya que una solución de autenticación se ejecuta en modo de usuario, mientras que un capturador de teclado se sitúa muy por debajo de ese nivel. A menos que exista un canal de confianza entre el teclado y el objeto basado en Web empleado para capturar la contraseña, no es posible evitar este tipo de riesgo. Si las soluciones de autenticación pseudomultifactor acaban siendo lo suficientemente habituales, está claro que tarde o temprano alguien creará un capturador de teclado de este tipo.
Asimismo, los ataques de suplantación de identidad tampoco pueden combatirse mediante la autenticación pseudomultifactor. En lugar de usar simplemente una pantalla de inicio de sesión falsa, el atacante puede usar un objeto de Flash para capturar la contraseña y la cadencia de escritura.
También hay que admitir que la autenticación pseudomultifactor puede ayudar en determinadas situaciones en las que la técnica del atacante sólo proporcionará la contraseña del usuario. Por ejemplo, la manera más fácil de obtener una contraseña de un usuario es preguntarle al propio usuario. Lo sorprendente es que esta técnica ha resultado ser efectiva, ya sea preguntando a los usuarios en persona, por teléfono o a través de mensajes de suplantación de identidad.
Preguntarle a un usuario su cadencia de escritura resultará, por supuesto, mucho menos efectivo. Del mismo modo, si una base de datos corporativa de contraseñas se ve comprometida, lo más probable es que el atacante sólo obtenga acceso a las contraseñas. Pero aquí de nuevo los ataques sólo se mitigarán si el sistema no ofrece autenticación estándar basada sólo en contraseña.
Me gustaría destacar además que si la propia base de datos de contraseñas ya está en realidad comprometida, es probable que el atacante haya puesto en peligro el sistema de un modo mucho más profundo que el que sería posible con una sola contraseña de cuenta de usuario normal, o incluso con varias. De este modo, no sirve de mucho intentar mitigar lo que puede hacer un atacante en posesión de una base de datos de contraseñas.

Algunas ventajas
Para ser justos, la autenticación pseudomultifactor sí puede ayudar a solucionar algunos problemas, siempre que el sistema no ofrezca la opción estándar de inicio de sesión basado únicamente en contraseña. Por ejemplo, puede usarse para evitar las contraseñas compartidas. Sin embargo, esto puede ser un inconveniente para los sistemas en los que sea legítimo compartir cuentas entre varios usuarios, como puedan ser cuentas bancarias conjuntas.
Además, un cuadro de diálogo interactivo de inicio de sesión debidamente diseñado (no un inicio de sesión en un sitio web) podría forzar al usuario a pasar por otras fases de autenticación si su cadencia de escritura no coincide. Esto puede proporcionar seguridad adicional para una cuenta comprometida en un entorno muy confidencial.

Engañar a los usuarios con una imagen atractiva
Una de las mejores formas de engañar a los usuarios es proporcionarles indicaciones poco precisas de seguridad. El método más común es quizás la imagen del candado que se muestra en una página web, como la de la figura 1. Esta página va más allá e incluso muestra la palabra "Secure" (seguro) junto al candado.
Figura 1 Ejemplo de abuso del icono del candado, una tendencia preocupante (haga clic en la imagen para ampliarla)
Como sabrá, el mero hecho de colocar una imagen de candado y la palabra "Seguro" en una página no la hace segura. Sin embargo, lo inquietante de este tema es que es una práctica bastante habitual, incluso entre los sitios web más visitados y de mayor reputación. El resultado es que muchos usuarios se acostumbran a buscar estas indicaciones visuales de seguridad en el cuerpo de la página web en lugar de averiguar si estas indicaciones tienen algún significado en el lugar que realmente importa: la barra de direcciones. El wiki sobre el contexto de seguridad web W3C incluye una entrada sobre este problema; lo encontrará en w3.org/2006/WSC/wiki/PadlockIconMisuse.
Es lamentable que haya tantos ejemplos de este tipo de uso indebido. Diversos estudios han revelado que los usuarios no son capaces de identificar sitios web malintencionados, incluso cuando los certificados son muy obvios (consulte www.usablesecurity.org/papers/jackson.pdf). En el fondo se trata de la capacidad de distinguir fácilmente lo falso de lo verdadero, aunque no se disponga del verdadero para compararlo. Para ello hace falta tener habilidad; la información atractiva y engañosa de seguridad en páginas web dificulta el desarrollo de esta habilidad, ya que se atrae a los usuarios hacia la información incorrecta.
Una variante especialmente perturbadora de este problema es la que se muestra en la figura 2. En este caso, la página que muestra la información en realidad no es segura. Si miramos la barra de direcciones, veremos que el protocolo indicado es "http". Este sitio hace uso de una técnica muy común de optimización: en lugar de cifrar la página que contiene el formulario de inicio de sesión, sólo se cifra el envío del formulario. El inicio de sesión es seguro, tal como indica la página, siempre que asociemos "seguro" con "cifrado". Sin embargo, y esto es crucial, el usuario no puede comprobar dónde se envían las credenciales hasta que éstas se han enviado. El sitio no muestra un certificado que autentique el sitio al usuario hasta que se haya enviado el formulario. Es una cuestión de confianza, como caer hacia atrás esperando que la persona que se encuentra detrás de nosotros nos agarre. En el momento de enviar el formulario, puede que el daño ya esté hecho.
Figura 2 Imagen atractiva de seguridad en una página que no es segura (haga clic en la imagen para ampliarla)
La capa de sockets seguros (SSL), el protocolo que proporciona la seguridad en HTTPS, tiene dos finalidades importantes. En primer lugar, autentica el servidor para el usuario. En segundo lugar, ofrece un mecanismo sencillo para negociar una clave de cifrado de sesión que se puede usar entre cliente y servidor.
Si sólo se cifra el envío del formulario, ya no se logra el principal y primer objetivo. Los sitios que emplean esta optimización usan simplemente SSL como un método para negociar claves. Lo irónico es que esto lo podrían hacer simplemente empleando un protocolo de negociación de claves estándar, con lo que se evitarían el costo y la sobrecarga que supone el uso de SSL.
El sitio que se muestra en la figura 2 no es una rareza. Muchos sitios ofrecen protección SSL sólo para el envío de formularios, pero no para el propio formulario. Este sitio en concreto, sin embargo, presenta un rasgo aún más perturbador. Si escribimos https://www.<sitio>.com (observe el indicador https seguro) en la barra de direcciones del explorador, el sitio le redirigirá a la versión no SSL de éste. Aunque intente inspeccionar un certificado antes de enviar sus credenciales al sitio, éste último se negará a mostrarle el certificado.
No todos los sitios funcionan incorrectamente, pero muchos sí. Y dos de las más importantes entidades financieras de Estados Unidos emisoras de tarjetas de crédito se encuentran entre los infractores. De hecho, de las tres principales compañías de tarjetas de crédito que uso, sólo American Express proporciona un certificado en el formulario de inicio de sesión. American Express redirige incluso las solicitudes HTTP a HTTPS. Buen trabajo.
Un último apunte con respecto a las imágenes atractivas y sin sentido de seguridad y la ausencia de certificados en los formularios de inicio de sesión. Es posible que se pregunte por qué un sitio haría este tipo de cosas. El motivo es simplemente económico. Presentar certificados requiere cifrar la página, y cifrar la página implica realizar una inversión en el procesamiento. El gasto en el procesamiento significa que se requieren más equipos para cubrir una misma carga. Y más equipos cuestan más dinero. Lamentablemente, cuando se trata de elegir entre proteger la privacidad del cliente y aumentar los beneficios, muchas organizaciones optan por la segunda.

Abrir o no abrir
Hace poco recibí un mensaje de correo electrónico asombroso de la compañía de mi seguro médico. Cualquiera que haya usado un equipo informático en los últimos 10 años sabrá que nunca hay que abrir datos adjuntos de correo electrónico no solicitados. Así que imagínense mi sorpresa al recibir el mensaje que se muestra en la figura 3.
Figura 3 Mensaje de correo electrónico con "datos adjuntos seguros" (haga clic en la imagen para ampliarla)
Por lo que parece, formulé una pregunta en el sitio web de la compañía de seguro médico y ya ni me acordaba de ésta cuando llegó el mensaje sospechoso. Y así es cómo me respondió la compañía. Al principio pensé que se trataba de un esquema inteligente de suplantación de identidad. Cuando me di cuenta de que era un mensaje legítimo, se me pusieron los pelos de punta.
La primera instrucción es hacer doble clic en los datos adjuntos para iniciar el descifrado del mensaje. El conjunto de la comunidad de la seguridad y los administradores de TI se han pasado los últimos 10 años intentando enseñar a los usuarios a no hacer doble clic en datos adjuntos. Y luego viene una compañía (mi compañía de seguro médico, por cierto, no es la única organización que hace uso de este método) y me dice que debo hacer clic en los datos adjuntos para mi seguridad. ¿Cómo debe actuar el usuario en esta situación? ¿Qué conducta debe aprender u olvidar?
Seguidamente, usé la característica de vista previa en Microsoft® Office Outlook® 2007 para ver el archivo. Como se puede comprobar en la figura 4, Outlook pensó que este mensaje podría ser un ataque y me advirtió que no lo abriera.
Figura 4 Outlook 2007 considera que el documento seguro es hostil (haga clic en la imagen para ampliarla)
Resulta irónico, a la par que triste, que una compañía de asistencia sanitaria infrinja los controles de seguridad más básicos empleados en el cliente de correo electrónico más popular del mundo. Teniendo en cuenta que esta compañía ni se molestó en probar su nueva solución de seguridad con Outlook, me pregunto qué otras cosas hará para proteger mi información privada. O, dicho de manera más rotunda, ¿qué otras soluciones está implementando la compañía exclusivamente para evitar ser acusada de no proteger adecuadamente la privacidad de sus clientes? Esto es similar a la dramatización de seguridad que llevan a cabo las instituciones financieras. En mi opinión, en este caso el principal objetivo de la solución es evitar ser acusados, y no proteger realmente a los clientes.
Tenía ganas de saber en qué consistían en realidad los datos adjuntos. Resultó ser un objeto de control ActiveX®. Para ver los datos adjuntos, tuve que abrirlo en Internet Explorer® e instalar el objeto. Me apareció la pantalla de confirmación que se muestra en la figura 5. Como se puede comprobar, los diseñadores se esforzaron mucho en lograr que el mensaje se pareciera a un sobre de correos tradicional; incluso tiene un sello que afirma que el sobre es de confianza.
Figura 5 El documento "seguro" muestra un sobre con el sello "Trusted" (de confianza) (haga clic en la imagen para ampliarla)
Este tipo de tecnología es preocupante por muchos motivos. En primer lugar, promueve un comportamiento totalmente incorrecto por parte del usuario: abrir datos adjuntos no solicitados. En segundo, el mensaje real contiene instrucciones realmente inadecuadas sobre cómo configurar el sistema para que abra siempre datos adjuntos sin solicitar la confirmación del usuario. En tercero, los mensajes adquieren un carácter muy sospechoso cuando nos encontramos ante mensajes conflictivos del equipo para los que el correo electrónico dice que son de confianza y Outlook dice que no lo son. Por último, los datos adjuntos en cuestión contienen imágenes atractivas de seguridad sin sentido para convencer al usuario de que en realidad son de confianza. Si el usuario aprende a confiar en este tipo de mensajes, entonces la línea que separa este tipo de confianza con la de confiar en mensajes malintencionados de aspecto similar es mínima.

Ofrecer una comunicación segura
Admitámoslo: el problema que esta tecnología pretende solucionar es muy importante. Comunicar con los clientes con confianza es una tarea difícil. Sin embargo, esta solución en concreto está sobrediseñada. Lo más probable es que provoque confusión en los clientes y produzca un resultado final contrario al que pretendía: evitar comprometer el sistema del cliente.
Los sitios web mejor diseñados emplean ahora un "centro de mensajes". Con este tipo de diseño, cuando la compañía necesita comunicarse con el cliente, envía un mensaje de correo electrónico con un texto parecido al siguiente: "Tiene un mensaje en el centro de mensajes. Vaya a nuestro sitio web, inicie sesión y haga clic en el vínculo Centro de mensajes para ver el mensaje". Las compañías ganan más puntos cuando usan extensiones seguras multipropósito al correo de Internet (S/MIME) para firmar cualquier mensaje de correo electrónico dirigido a los clientes y permitir que el usuario autentique el origen. Si además el mensaje no incluye ninguna frase del tipo "haga clic en este vínculo", ganarán aún más puntos. El usuario debe escribir la dirección URL de la compañía de forma manual para asegurarse de que irá al sitio previsto.
Con un centro de mensajes y un mensaje firmado, las compañías pueden lograr un canal de confianza para comunicarse con el cliente. Todo lo que ve el cliente durante el flujo de trabajo de mensajes se autentica, con lo que la compañía se asegura de no promover prácticas de seguridad deficientes.

La privacidad está en juego
Hasta ahora, he dedicado las dos primeras entregas de esta serie a describir cómo los profesionales de la seguridad ofrecen realmente un mal servicio a los usuarios. Nuestro trabajo consiste en mantener la seguridad. Sin embargo, muchas de las decisiones que se toman y de las soluciones que se implementan confunden a los usuarios y les enseñan a tomar decisiones incorrectas, además de proporcionarles una sensación falsa de seguridad. No debemos abrumar a los usuarios con estas ideas opuestas.
Tal como comenté anteriormente, para los usuarios convencionales, la seguridad consiste simplemente en proteger las contraseñas y los números de tarjeta de crédito. Desean que la tecnología funcione y que sea de confianza. Lamentablemente, tienen que tomar decisiones y, por lo tanto, nuestro trabajo consiste en asegurarnos de que las decisiones que tomen estén bien fundamentadas.
En la última entrega de esta serie, hablaré de cómo algunas de las tecnologías más importantes disponibles para los consumidores no cumplen las expectativas depositadas en ellas. También presentaré mi "llamada a las armas". Así que ya saben: pueden consultar la columna sobre vigilancia de seguridad de septiembre de 2008.

Jesper M. Johansson es un arquitecto de software que trabaja en el campo del software de seguridad y colabora como editor en TechNet Magazine. Posee un doctorado en sistemas de información de administración, más de 20 años de experiencia en el ámbito de la seguridad y es MVP de Microsoft en seguridad empresarial. Su último libro es Windows Server 2008 Security Resource Kit.


Informática sostenible Cómo filtrar el "greenwashing"
Dave Ohara

Contenido
La necesidad de contar con datos
Medir el uso de energía
Factor de energía
Medir en producción
Microsoft Enterprise Engineering Center
Conclusión
Hay una cantidad abrumadora de productos y soluciones que se comercializan bajo la etiqueta de ecológicos, de bajo consumo y más eficaces. Este tipo de campaña de marketing a bombo y platillo crea confusión en el mercado en cuanto a lo que realmente es ecológico. Incluso después de evaluar las especificaciones de varios productos, resulta difícil, si no imposible, que un profesional de TI
determine el tipo de equipo que debe usarse cuando el impacto medioambiental es una preocupación clave. En las demostraciones siempre se destaca el gran ahorro de energía, lo que lleva a pensar que la rentabilidad de la inversión (ROI) justifica más fácilmente la actualización. Después de todo, el ahorro de energía debería reducir el costo total de la propiedad.
El paso que dan todo tipo de compañías al etiquetar aparentemente todos los productos como respetuosos del medioambiente y aprovechar el interés actual en soluciones ecológicas, ha desembocado en el concepto de "greenwashing", que hace referencia a las promesas exageradas de las ventajas medioambientales que ofrecen los productos. ¿Cuál es la verdad en el ahorro de energía? La respuesta no es tan evidente como, por ejemplo, la instalación de nuevas bombillas de bajo consumo en casa.
A medida que aumenta el interés por los esfuerzos de TI sostenibles y se amplia el mercado de equipos de TI respetuosos con el medio ambiente, muchas personas y organizaciones se saltan pasos para ir directamente al resultado final de implementar portátiles, equipos de escritorio y servidores de bajo consumo, y usar la virtualización para reducir el consumo de energía. Pero pocas organizaciones llevan a cabo auditorías para determinar las ventajas reales de lo que han comprado.
Aunque la situación ideal sería poder efectuar mediciones en el entorno de producción, es algo que puede resultar caro. Si no está preparado para realizar mediciones en producción, puede avanzar realizando una auditoría de energía al principio del proceso en los laboratorios de rendimiento y evaluación (la mayoría de las compañías tienen algún responsable de laboratorio o de grupo para probar y evaluar los equipos antes de comprarlos). Es en ese momento en el que se puede agregar el rendimiento energético como uno de los criterios de prueba y tener en cuenta los resultados obtenidos para la toma de decisiones sobre la compra de productos, en lugar de basarse en los datos suministrados por los fabricantes. Cree su propia base de datos de consumo de energía de dispositivos a medida que efectúa las pruebas. De este modo, podrá ignorar el "greenwashing" y comprobar por sí mismo lo que realmente funciona.
Por supuesto, me gustaría puntualizar que para obtener datos muy precisos sobre el funcionamiento con carga auténtica, deberá supervisar las pruebas en su propio entorno de producción. Cuanto más pronto comience a supervisar el entorno de producción, mejor será para su organización y para los resultados finales. Es un proceso crítico para obtener éxito a largo plazo.

La necesidad de contar con datos
En una situación ideal, las pruebas independientes evaluarían el rendimiento por vatio de los dispositivos de hardware con cargas de usuario reales. Pero el sector se encuentra en las primeras etapas de desarrollo e implementación para este tipo de pruebas. Y las que están disponibles, como los bancos de pruebas de SPEC Power, todavía se encuentran en la fase inicial. La eficacia de estas pruebas de energía se verá realmente cuando estén listas. Pero, al igual que sucede con cualquier prueba, los fabricantes aprenderán a modificar sus equipos para obtener unos resultados excelentes de las pruebas.
Los profesionales de TI experimentados han aprendido a cuestionar las pruebas realizadas por los laboratorios. Y al igual que los fabricantes de automóviles se aseguran de que sus mejores coches realizan las pruebas en carretera, los proveedores de TI se asegurarán de enviar las configuraciones de equipo más eficaces a las pruebas de consumo energético.
Considere las pruebas de virtualización que se usan en la comparación de un grupo de servidores aprovisionados de forma excesiva donde no se ha ejecutado una consolidación de servidores para demostrar las ventajas de la virtualización. Los proveedores omiten mencionar aspectos como, por ejemplo, los posibles efectos de rebote de proyectos de ahorro de energía como la virtualización. Esto hace referencia fundamentalmente al momento en que el ahorro energético reduce los costos y la demanda aumenta como respuesta, disparando el uso energético y aumentando el uso. No se fíe si ve una solución como la virtualización comercializada como remedio milagroso para el ahorro energético. Realmente tiene que ver cómo funciona todo en conjunto y cuál será el efecto dominó a lo largo del tiempo.
Así pues, ¿cómo determinar el camino correcto que debe tomar su organización? Hay muchos consultores preparados para llevar a cabo evaluaciones previo pago. Sin embargo, este enfoque presenta algunos inconvenientes importantes. ¿Realmente desea transferir la habilidad de ser eficiente a alguien externo a la organización? ¿Desea depender de un consultor al que le interesa mantener un contrato a largo plazo y crear una dependencia del servicio?
Se podría convertir en un proyecto inmenso en el que interviniesen decenas de personas para determinar la estrategia de sostenibilidad medioambiental. Evite la tentación de seleccionar sólo una parte del entorno y empezar a realizar mediciones. Aunque se supone que es lo correcto, este enfoque no tiene sentido, ya que sólo se selecciona una acción al azar. Debe averiguar dónde se encuentra realmente el consumo de energía y en que parte usted puede influir.

Medir el uso de energía
Debe realizar un nuevo enfoque sobre lo que funciona. Los profesionales de TI saben cuándo un elemento de hardware no funciona si, por ejemplo, un servicio deja de estar activo. Pero, ¿qué sucede cuando un elemento de hardware no funciona correctamente en lo que respecta al consumo de energía? Probablemente no se detecta ya que la mayoría de las organizaciones no tienen datos para establecer el ahorro energético de su línea de base.
¿Cómo se obtienen estos datos? Algunos sugieren la necesidad de un entendido en energía. No obstante, esto significa que haya alguien que pueda recorrer la organización de la compañía y que esté especializado en cuestiones energéticas. Un método más sencillo y accesible es agregar herramientas de medición de energía a las funciones existentes en laboratorios de rendimiento.
Existen numerosos dispositivos de medición de energía. Lamentablemente, en este momento no existe el dispositivo perfecto para un laboratorio de rendimiento de TI. En la gama baja, se puede hacer con un dispositivo Watts Up Pro. Se trata de un dispositivo USB que proporciona medición de energía en línea para 120 V. Otro dispositivo es Smart-Watt, un dispositivo de medición de consumo de energía en red con un intervalo de 100-240 V y 15-30 A. Los dispositivos Smart-Watt también están disponibles con sensores de temperatura y humedad para medir los factores ambientales. Por otro lado, están los dispositivos de análisis de energía industrial, como Extech Appliance Tester 380801 y Fluke 345 Power Clamp. No debe tener problemas para encontrar dispositivos como éstos que se adapten a las necesidades de pruebas de su laboratorio.

Factor de energía
Si no tiene experiencia en la medición de energía, es importante que comprenda el concepto de factor de energía. El factor de energía de un sistema eléctrico de CA se define como la relación de la energía real con la energía aparente y utiliza un número entre 0 y 1. La energía real (vatios) es la capacidad del circuito para realizar el trabajo. La energía aparente (VA) es el producto de la corriente y el voltaje del circuito.
Puede que se pregunte por qué esto es importante. Eche un vistazo a la figura 1. La fotografía muestra un dispositivo de supervisión de energía de Smart Works que se usa para comparar la eficacia energética de un equipo portátil, una bombilla y un condensador. Una bombilla tiene una carga de 50 W y 50 VA, con el factor de energía de 1,0. Un condensador con una carga capacitiva pura obtiene una carga de 2 W y 193 VA para un factor de energía de 0,01. El equipo portátil usa 22 W de energía, pero tiene una lectura de 48 VA para un factor de energía de 0,47. El bajo factor de energía del equipo portátil probablemente se debe a un diseño ineficaz de la fuente de alimentación y seguramente es el resultado de los objetivos de costos de fabricación.
Figura 1 Consumo de energía de un equipo portátil, una bombilla y un condensador (haga clic en la imagen para ampliarla)
Con tanto interés en la eficacia energética, los proveedores buscan mejorar el rendimiento de las fuentes de alimentación en las condiciones previstas. Si se compara el factor de energía de los equipos existentes con el de los nuevos, puede observar que se obtiene algo más de capacidad energética al elegir soluciones con fuentes de alimentación más eficaces y factores de energía superiores.

Medir en producción
El objetivo de los resultados de medición en el laboratorio de medición es predecir el rendimiento en el entorno de producción. El problema con la medición del consumo de energía en producción es el costo necesario para medir todos los dispositivos. No obstante, una estrategia para reducir el costo de la medición de la energía en producción consiste en efectuarla en la unidad de distribución de alimentación y agregar múltiples lecturas de equipo. En la figura 2 se ofrece una lectura de energía de muestra tomada de una unidad de distribución de alimentación con varios elementos del mismo equipo en una sola unidad. Gracias a la posibilidad de cálculo del consumo de energía medio por servidor, este instrumento de medición presenta datos sobre el consumo de energía en producción.
Figura 2 Medición en la unidad de distribución de alimentación (haga clic en la imagen para ampliarla)
A medida que se mide cada equipo, la información de energía se debe integrar en la base de datos de administración de configuración. Si esto resulta muy difícil, puede crear una base de datos propia o, como mínimo, una hoja de cálculo de Excel® que enumere los dispositivos y el consumo de energía de los mismos. A medida que acumule más dispositivos, puede rellenar las estimaciones de otros y crear así un cálculo de capacidad energética global. Tenga presente que un servidor nuevo de bajo consumo consumirá más de la mitad de su carga de energía mientras está inactivo con respecto a los momentos de máxima actividad. Si además dispone de servidores antiguos que ejecutan soluciones obsoletas, éstos pueden consumir grandes cantidades de energía, incluso si están inactivos. Se trata de uno de los objetivos más fáciles de conseguir a la hora de recuperar capacidad energética.
Si desea continuar sus esfuerzos de mejora, el siguiente paso es calcular la energía por cada bastidor usado en el centro de datos. También debe estar seguro de comprender las capacidades energéticas y de refrigeración al modificar el entorno. Con el tiempo, empezará a ver los equipos en función de las necesidades energéticas y no sólo según el espacio que necesitan. El espacio es un concepto sencillo, porque es estático y visual. Los profesionales de TI pueden hablar fácilmente de servidores 1U, 2U y 4U. Pero si se empieza a hablar de servidores de 200 W y de 450 W, los mismos profesionales de TI ya no se sentirán tan cómodos con la conversación. Se trata de un nuevo lenguaje para los equipos de TI y es algo que se nota en los centros de datos actuales. Muchos disponen de espacio de sobra para más equipos, aunque hayan alcanzado su capacidad energética máxima.

Microsoft Enterprise Engineering Center
El Microsoft Enterprise Engineering Center (EEC) recientemente ha incorporado capacidades de medición de energía en sus instalaciones. Situado en el campus corporativo de Microsoft en Redmond (Washington), el EEC (microsoft.com/windowsserver/evaluation/eec/default.mspx) es un campo de pruebas de vanguardia para los entornos informáticos más complejos.
Con más de 40 millones de dólares en hardware y equipos de red (consulte la figura 3), el EEC puede llevar a cabo las recreaciones más complejas de entornos empresariales reales de producción. El grupo se ha asociado con numerosos proveedores de soluciones cliente/servidor, de red y de almacenamiento para ofrecer una combinación de última tecnología y plataformas heredadas. El objetivo es garantizar que cada prueba ofrezca un reflejo preciso del entorno actual del cliente. El servicio más reciente que se está desarrollando en las instalaciones elabora informes sobre el consumo de energía de soluciones para proporcionar una prueba comparativa del rendimiento por vatio.
Figura 3 Una de las numerosas filas del laboratorio EEC (haga clic en la imagen para ampliarla)
En los últimos años, el EEC ha presenciado muchos operadores de centros de datos quedarse sin alimentación ni refrigeración para sus equipos. Los equipos más modernos sueles venir acompañados de mayores densidades de potencia, lo que supone más requisitos para las instalaciones. El personal del EEC ha conocido de primera mano los costos y el tiempo que son necesarios para mejorar la infraestructura de energía y refrigeración. Por lo tanto, para lograr un funcionamiento más eficaz y rentable, el EEC ha incorporado la capacidad de medir la energía por dispositivo.
Algunas de las herramientas y equipos que usa el EEC no se habían entregado cuando se redactó este artículo. Como se trata de una nueva solución, el EEC seguirá desarrollando mejores técnicas, trabajando con clientes, proveedores y equipos de desarrollo de Microsoft. El EEC comparte los métodos que ha estado desarrollando hasta ahora con los clientes para obtener comentarios desde el principio, lo que permite a los clientes crear sus propios bancos de pruebas.
No dé por sentado que los resultados son los evidentes. El EEC ha compartido algunos de los resultados interesantes que el grupo ha obtenido al usar características de supervisión de energía en los laboratorios de rendimiento de EEC:
  1. 1. Apagar un dispositivo no reduce necesariamente el consumo de energía tanto como cabría esperar (consulte la figura 4). En un caso relacionado con hardware de servidor, el EEC descubrió un dispositivo que consumía en realidad 100 W cuando se apagaba y seguía conectado. Esto sorprendió a muchos y el EEC analizó la configuración muchas veces. Finalmente se usó un termómetro de infrarrojos para medir la temperatura de entrada y salida, y comprobaron que el dispositivo, de hecho, consumía 100 W mientras estaba apagado.
  2. El software puede tener influir mucho en el consumo de energía. En conmutadores de red idénticos con el mismo hardware y las mismas configuraciones de BIOS, se obtuvo una diferencia del 21% en el consumo de energía al ejecutarse software de red distintos. Las soluciones de tecnología avanzada con más procesos y características habilitadas, como las herramientas de seguridad y supervisión, suelen consumir más que sus equivalentes de gama baja más sencillas.
  3. En escenarios de virtualización, el EEC ha medido el consumo de energía con respecto al uso de E/S y CPU para determinar cuándo un determinado elemento de hardware maximiza su rendimiento por vatio. El EEC descubrió que un enfoque limitado del uso de CPU podía provocar que se cargaran numerosas máquinas virtuales en un equipo físico, reduciendo así el rendimiento general por vatio.
  4. Los dispositivos de mayor densidad, como es lógico, presentan más problemas de energía y refrigeración. Al implementar sistemas de mayor densidad, es necesario consultar lo antes posible al personal de las instalaciones de energía y de refrigeración. Estos dispositivos pueden ser una buena solución para sus propios dispositivos de supervisión de energía en producción si sabe que habrá limitaciones de energía en el entorno.
  5. Los sistemas de fuentes de alimentación duales pueden consumir mucha más energía que una sola fuente de alimentación.
  6. Los elementos de hardware aparentemente idénticos con configuraciones idénticas pueden presentar consumos de energía considerablemente distintos. Las diferencias observadas fueron lo suficientemente importantes como para que el personal del EEC volviera a comprobar los elementos de hardware con el fin de asegurarse que tenían la misma configuración.
  7. Las clasificaciones de vatios que se indican en la placa de producto no son números reales de consumo, sino capacidades nominales de las fuentes de alimentación.
  8. Mantener una base de datos de pruebas y resultados de consumo de energía por dispositivo y subcomponente es fundamental para conservar conocimientos y comparar datos.
  9. Las configuraciones diferentes de cantidades equivalentes de RAM consumen distintas cantidades de energía. Normalmente, menos módulos DIMM consumen menos energía; por ejemplo, 4 módulos DIMM de 2 GB consumen menos respecto a 8 módulos DIMM de 1 GB. Pero ha habido casos en los que menos módulos DIMM consumían más energía.
Figura 4 Comparación del consumo de energía en dispositivos encendidos y apagados (haga clic en la imagen para ampliarla)

Conclusión
Si incorpora la capacidad de medir el consumo de energía a los laboratorios de rendimiento, podrá empezar a acumular su propia base de datos de consumo de energía por dispositivo con datos precisos sobre las cargas reales. Al implementar estas soluciones, debe auditar los resultados en un sistema de realimentación de bucle cerrado para determinar la precisión de las pruebas de laboratorio. Al igual que el EEC aprendió mediante la realización de sus propias pruebas de medición, existen algunos detalles realmente interesantes que se pueden analizar para ayudarle a filtrar el "greenwashing" y descubrir la verdad.
Este método de medición en laboratorios de rendimiento influirá el mercado global para comenzar a identificar lo que realmente es más eficaz energéticamente. Y con el tiempo, los fabricantes descubrirán que es necesario proporcionar datos más precisos acerca de sus afirmaciones sobre el ahorro de energía. Del mismo modo, con el tiempo los profesionales de TI hablarán de vatios por dispositivo como criterio de compra habitual. Es necesario que se convierta en una práctica habitual, especialmente para las compañías que compran grandes cantidades de servidores. Sin embargo, puede tomar el control pensando a partir de ahora en la energía como uno de sus recursos valiosos de TI.
Mantener refrigerado el centro de datos
La refrigeración del centro de datos ofrece un gran potencial para reducir el consumo de energía. Es asombrosa la cantidad de calor que se puede generar en un centro de datos y la cantidad de energía que se usa para mantener el hardware refrigerado. Pero si desea administrar la refrigeración de forma correcta, resolver problemas y desarrollar soluciones de refrigeración más eficaces, necesitará una solución de supervisión de temperatura. Considere la solución que usan los centros de datos de Microsoft.
Microsoft Research ha creado una red de sensores de temperatura para los centros de datos que ofrece un mayor control de la temperatura y permite la evaluación de las distintas mejoras en la refrigeración. Por ejemplo, un centro de datos de Microsoft estaba evaluando la posibilidad de usar cortinas de aire de final de pasillo para mejorar el proceso de separación de aire caliente y frío. Después de instalar las cortinas, algunos servidores empezaron a enviar alarmas de calor excesivo. Naturalmente, los ingenieros de operaciones aumentaron el flujo de aire desde el sistema de refrigeración para proporcionar más aire frío. Para su asombro, más servidores enviaron alarmas de sobrecalentamiento. Todos esos servidores estaban situados en la parte inferior del bastidor y, por supuesto, la parte inferior normalmente es el área más fría de un sistema de refrigeración elevado.
Con la red de sensores, los ingenieros confirmaron que los bastidores más altos estaban más refrigerados, mientras que los que estaban situados en la parte inferior del bastidor estaban más calientes. Pronto se dieron de que se estaba inyectando aire caliente del pasillo caliente situado entre la parte inferior del bastidor y el suelo, un resultado del principio de Bernoulli. Corrigieron fácilmente el sobrecalentamiento al sellar la parte inferior del bastidor y reducir la velocidad del flujo de aire.
Este es el tipo de datos que Microsoft Enterprise Engineering Center recopila y analiza cuando lleva a cabo pruebas de rendimiento. Así que el EEC notificó recientemente a Microsoft Research que estaban preparados para una prueba de implementación. En un día el sistema se implementó en 10 bastidores y la instalación sólo tardó una hora en realizarse. El EEC ahora puede estudiar y comprender mejor las cuestiones de refrigeración y su relación con el rendimiento del hardware.
Está claro que no basta con supervisar para solucionar un problema. La ganancia real se basa en la capacidad de encontrar áreas problemáticas que pueda corregir y en las que pueda realizar cambios, así como evaluar distintas soluciones para comprobar si tienen el resultado previsto. Después de todo, mejor ser precavido y saber qué hacer cuando la nueva solución de refrigeración provoque de forma inesperada el sobrecalentamiento de los bastidores.

Dave Ohara tiene 26 años de experiencia en tecnología. Actualmente trabaja con varias compañías implementando iniciativas ecológicas.


Notas de campo IMAP salva el mundo
R'ykandar Korra'ti

A veces soluciones a problemas nuevos y pequeños también pueden resolver problemas viejos y grandes. Este es uno de esos casos.
El invierno pasado, nuestra administradora web compró un MacBook. Hasta entonces ella sólo había usado Windows®, pero ahora tenía OS X y, en una máquina virtual, Windows XP para sincronizar sus dispositivos de Windows Mobile® y para otras tareas sencillas.
Necesitaba tener acceso a todos sus archivos del correo desde ambos sistemas operativos. Pero no quería ejecutar Entourage desde el Mac, eso habría sido demasiado fácil. No, quería ejecutar la aplicación Mail.app, el cliente de correo electrónico incluido con OS X. Otro detalle importante es que lo había conservado todo en el almacén local de su equipo portátil, sin duplicar. Mi trabajo: hacer que esto sea posible.
Hacer que los archivos se puedan leer desde todas partes sólo presentaba los pequeños problemas mencionados anteriormente porque (y esta es la primera moraleja de nuestra historia) todo, incluyendo Exchange Server, Microsoft® Office Outlook® y Mail, habla IMAP4. IMAP4 es un protocolo de mensajería que permite administrar almacenes de mensajes de servidor desde clientes ligeros. Tiene menos funciones de las que disfrutan los usuarios de Exchange, pero funciona (consulte Cómo funciona: IMAP4 en la edición de marzo/abril de 2006 de TechNet Magazine en technet.microsoft.com/magazine/cc161016).
Así que, sólo hizo falta cambiar algunos valores de configuración para que IMAP4 funcione sobre SSL en línea, copiar todas sus carpetas locales en el servidor y ¡listos! Ella podría tener acceso al correo en todos los clientes y mantener sus dispositivos de Windows Mobile actualizados. Problema resuelto.
Pero al proponer una solución sencilla a un problema que podría ser complicado, es como comprarse una cortadora de madera. De repente se compra más y más madera y antes de que se dé cuenta ha construido un escenario completo donde se puede representar la obra "Romeo y Julieta".
Nuestro diminuto ISP ejecuta Windows, OS X, Mac OS, Linux, e incluso tiene un solitario y antiguo sistema AmigaOS que busca quien le quiera. Hace mucho tiempo, hospedábamos las noticias de Usenet y el correo UUCP en ese Amiga. Creaba archivos almacenados en formato RFC-733/AmigaUUCP. También tenemos archivos de Microsoft Mail (formato .mmf) y algunos archivos de correo Unix de parecida antigüedad (en formato .mbox). Todos han terminado ahí sin hacer nada, burlándose de nosotros, un problema que hemos considerado muchas veces pero del que siempre terminamos huyendo despavoridos.
Esta situación nos recuerda la segunda moraleja de nuestra historia, el lema de todo pirata informático que se precie: no borres nunca lo que no puedas reemplazar.
Empecemos primero por los archivos de Microsoft Mail. Outlook no es capaz de importar archivos .mmf desde hace tiempo. Pero aunque hemos actualizado los clientes con el paso de los años, siempre hemos conservado por lo menos una licencia del producto anterior por precaución. Como resultado, nuestra estantería de licencias es como un historial de Microsoft Corporation. ¿Necesita un MS-DOS®? ¿OS/2 1.31? ¿Microsoft Mail? ¿Office 95? ¡Ningún problema! ¿Le gustaría en inglés o en francés?
Outlook 2000 importaba .mmf, pero su compatibilidad con IMAP era un poco extraña y a veces no importaba los datos del encabezado. Además, tampoco podía comunicarse con IMAP4 y con servidores Exchange al mismo tiempo. Esto era una limitación importante, pero no algo que lo hiciera imposible. Importemos los archivos .mmf mediante Outlook 2000, actualicemos a Outlook 2003 con la licencia que conservamos, y unas cuantas horas de arrastrar y soltar después: archivos de hace 15 años en línea y visibles desde cualquier parte. De forma similar para .mbox, coloque un servidor IMAP compatible con mbox en un equipo Linux y ponga los archivos con formato .mbox en su directorio de trabajo. A continuación use la compatibilidad IMAP de Outlook para conectar y copiar carpetas al servidor de producción que prefiera.
Para los archivos de Amiga, por otro lado, se requirió escribir un pequeño programa en código C para convertir los encabezados RFC-733 en formato RFC-822, esquivar los divisores de mensajes de estilo SysV y recuperar los datos de la línea de remitente del infierno particular en el que vivían. Este es el precio que se paga por dejar que los problemas se asienten demasiado largo. Pero, una vez hecho, el formato AmigaUUCP se convirtió en formato .mbox. Y una vez colocado en el mismo directorio de trabajo, el IMAP4 de Outlook dejó el correo en tan buen estado como si fuera nuevo. Incluso empaquetó muy bien los datos adjuntos.
Ahora tenemos archivos que datan de 1990 en línea en un formato unificado y seguimos buscando más archivos que podamos tener. Y hacemos esto porque sí. ¿No nos estaremos obsesionando?

R'ykandar Korra'ti, administradora de correo para una pequeña cooperativa de ISP, vive cerca de Seattle con su compañera Anna. Trabajó anteriormente en la administración de productos de correo en Microsoft, y ahora escribe artículos técnicos cuando no compone letras profundamente oscuras de canciones para mandolina. Los agentes editoriales se pueden poner en contacto con ella en darako@murkworks.net.


Confidencial de Windows Basarse en el pasado
Raymond Chen

Un colega mío rescató un equipo Alpha AXP de un armario polvoriento. Al arrancar el sistema, descubrió que ejecutaba una versión de 64 bits de la versión 2000 de Windows®. ¿Cómo es posible?
Resulta que yo también tenía uno de esos equipos en mi oficina. En su apogeo, este tipo de equipo era un motor muy potente a tener en cuenta. Su tamaño era aproximadamente el de una nevera pequeña y generaba tanto ruido como una aspiradora. Contenía cuatro procesadores Alpha AXP (los conté y sí, eran cuatro), cada uno ejecutándose a unos asombrosos 400 MHz. Tenía un gigabyte de RAM y trece gigabytes de espacio en disco duro, repartidos en una docena de unidades de disco SCSI rápidas. Esto puede parecer insignificante en la actualidad, pero en los años 90 este tipo de equipos Alpha AXP era la envidia de todos y el que tenía uno era el chico más popular a la hora de la comida.
En 1999, cuando Compaq anunció que ya no admitiría Windows en Alpha AXP, muchos de los sistemas Alpha AXP se quedaron en Microsoft sin ninguna función oficial. Sin embargo, algunos de estos equipos se dedicaron a una serie de tareas no oficiales. Mi sistema Alpha AXP lo usé para indizar todo el código fuente de Windows. Ya se puede imaginar lo cómodo que resulta para un programador poder identificar todos los autores de llamada de una función en cuestión de segundos o buscar en el código fuente una función o un cuadro de diálogo que se muestra en un seguimiento de depuración.
Pero incluso para la sencilla tarea de indizar el código fuente de Windows, el sistema Alpha AXP pronto se vio eclipsado por los equipos x86. Estos eran más baratos y rápidos, ofrecían más espacio de disco duro y tenían más memoria. Así, mi equipo no tardó en unirse a sus hermanos olvidados. Se supuso que el final del soporte técnico del sistema Alpha AXP significaría el final de estos equipos, pero se les brindó la oportunidad de tener un momento de gloria y exhalar su último aliento en aras de la siguiente generación.
El proyecto de Windows de 64 bits ya estaba en marcha y de los procesadores de 64 bits que se consideraron sólo el Alpha AXP tenía realmente la capacidad física. El procesador Intel Itanium todavía estaba en desarrollo y sólo se ejecutaba en un simulador, y la arquitectura AMD64 ni siquiera se había inventado. Como resultado, el sistema de 64 bits de Windows se desarrolló inicialmente en el sistema Alpha AXP.
Cuando Compaq anunció que ya no admitía Windows en el sistema Alpha AXP, se cambió la finalidad de todos los equipos Alpha AXP que anteriormente se habían usado para el desarrollo y las pruebas de Windows 2000 de 32 bits y comenzaron a tener una vida secreta como equipos de prueba para un sistema operativo de 64 bits que nunca se distribuiría en ese formato. El sistema Alpha AXP simplemente fue una plataforma de prueba de concepto.
Los equipos Alpha AXP desempeñaron bien esa función y ofrecieron al equipo de trabajo de Windows de 64 bits un hardware real con el que trabajar en lugar de tener que ejecutar el sistema operativo en un simulador Itanium (ya se puede imaginar lo lento que era este último). Evidentemente, el sistema Alpha AXP no era el hardware de destino final, pero supuso una gran ayuda. Y cuando las CPU Itanium físicas comenzaron a aparecer, desapareció el nicho ocupado por los equipos Alpha AXP y estos se guardaron de nuevo en armarios polvorientos.
Mis amigos que trabajan en Microsoft Archives recuperaron mi viejo y fiable equipo Alpha AXP de su armario polvoriento para esta fotografía en la que posa junto a uno de los productos que contribuyó a que fuera posible: la edición de 64 bits de Microsoft Windows Server® 2003. Y sin duda alguna se trata del material auténtico.

El sitio web de Raymond Chen, The Old New Thing, y su libro homónimo (Addison-Wesley, 2007), tratan sobre la historia de Windows y la programación Win32. Prefiere que no le encierren en un armario polvoriento.