Julio 2008 Julio 2008
IIS: implementación de IIS 7.0
El lanzamiento de Internet Information Services 7.0 establece nuevos estándares, ofrece mejoras fundamentales y proporciona nuevas capacidades para la consolidación de entornos web. Analice las mejoras más importantes y obtenga una guía exhaustiva para probar, organizar y migrar sus aplicaciones web a IIS 7.0. Fergus Strachan
Comunicaciones y colaboración: Planeación de la migración a la mensajería unificada
La transición de un sistema heredado de correo de voz a una plataforma de mensajería unificada puede realizarse fácilmente y con la mínima interrupción para los usuarios finales, siempre que cuente con un sólido plan implementado. Esto es lo que debe saber para planear su propia migración, probar sus nuevos sistemas e implementar la mensajería unificada en su organización. Jeff Goodwin
Comunicaciones y colaboración: Descubra el modo en que la voz aumenta la eficacia de OCS 2007
Microsoft Office Communication Server introduce una serie de cambios significativos en la telefonía empresarial. Descubra cómo se realizan las llamadas de voz capa por capa, cómo se pueden enrutar estas llamadas a varios extremos y la importancia de las conversaciones en las comunicaciones de OCS. Rajesh Ramanathan
Comunicaciones y colaboración: Creación de conexiones eficaces con Groove y SharePoint
Microsoft Office Groove y SharePoint Server proporcionan capacidades de colaboración eficaces. Compare el modo en que se diferencian y complementan, y descubra cómo puede integrar Groove y SharePoint con el fin de proporcionar una solución de colaboración sencilla y flexible en beneficio de los usuarios en ubicaciones diversas. Alan Maddison
Administración de Windows: Introducción a Windows Server 2008 Failover Clustering
Durante años, los usuarios se han quejado de que la tecnología de clústeres de Windows Server es muy complicada. Con la publicación de Windows Server 2008, se ha rediseñado por completo esta tecnología. Explore algunos de los avances más significativos de Windows Server 2008 Failover Clustering, y descubra el modo en que esta nueva implementación facilita la configuración y el mantenimiento de los clústeres. Chuck Timon
Columns
Nota del editor: La impresión ha muerto: | Cartas: Comentarios de los lectores: | Cuadro de herramientas: Nuevos productos para profesionales de TI:
Preguntas y respuestas sobre Exchange: Equilibrio de carga, transporte perimetral y mucho más: ¿Tiene más dudas acerca de Exchange? En este número, respondemos preguntas acerca del uso de Exchange con SharePoint, el uso de la replicación continua en espera y la instalación de servidores Buzón de correo de Exchange 2007 en Windows Server 2008, entre otras.Henrik Walther | Utility Spotlight: Microsoft SharedView: ¿Desea colaborar rápidamente con alguien que se encuentra en otra ciudad? Compruebe cómo Microsoft SharedView, una utilidad gratuita, le permite compartir fácilmente documentos y pantallas con miembros de un grupo pequeño, incluso más allá de las fronteras físicas.Greg Steen | Dentro de SharePoint: Integración de aplicaciones de Office: Averigüe cómo las aplicaciones de Microsoft Office se integran y comunican con SharePoint, y conozca modos de integrar aplicaciones ajenas a Microsoft con SharePoint a partir de los mismos principios.Pav Cherny
Windows PowerShell: el buzón de entrega: Don Jones habla de las funciones de filtrado, la canalización, los objetos personalizados y la forma en que las pelotas de ping-pong encierran el secreto del funcionamiento de Windows PowerShell.Don Jones | Hey, Scripting Guy!: Subidón de adrenalina: Los Scripting Guys vuelven cargados de adrenalina con una nueva entrega de sus scripts, y muestran cómo se puede obtener acceso mediante scripts al nuevo almacén de datos de configuración de arranque de Windows Vista y Windows Server 2008.Los Scripting Guys de Microsoft | Archivos del escritorio: Windows con arranque en red: Explore la historia de los Servicios de instalación remota (RIS) y otras tecnologías relacionadas con PXE que se usan en Microsoft.Wes Miller
Vigilancia de seguridad: Contraseñas y tarjetas de crédito, parte 1: Primer número de un total de tres dedicados al modo en que las prácticas y los consejos más comunes en relación con la seguridad están anticuados y, de hecho, entorpecen los esfuerzos de seguridad.Jesper M. Johansson | Notas de campo: Garantía de unas elecciones precisas: Examine las vulnerabilidades del sistema electoral actual en Estados Unidos y compruebe cómo puede usarse la criptografía para obtener resultados electorales completamente verificables.Josh Benaloh | Confidencial de Windows: La historia ocupa su espacio: A diferencia de lo que pueda creer, Microsoft Bob es muy popular. Raymond Chen explica cómo Microsoft Bob logró colarse en millones de hogares.Raymond Chen


IIS
implementación de IIS 7.0
Fergus Strachan
De un vistazo:
  • Implementación de IIS 7.0 en un entorno de granja de servidores web
  • Mejoras en la seguridad y el rendimiento
  • Migración de aplicaciones web ASP.NET de IIS 6.0 a IIS 7.0
  • Migración de aplicaciones web PHP a IIS 7.0

Contenido
Preparado, listo, prueba
Configuración de la prueba
Mejoras importantes para los administradores de TI
Arquitectura de IIS
Modos integrado y clásico
Módulos y funcionalidad
Migración de aplicaciones web
Conclusión
El equipo de IIS en Microsoft comunica que Internet Information Services (IIS) 7.0 es el lanzamiento más importante en la historia de IIS. En esta versión, se establecen nuevos estándares, se ofrecen mejoras fundamentales y
se presentan nuevas capacidades para la consolidación de entornos web. Microsoft.com ya usa IIS 7.0, que está incluido en Windows Server® 2008 y Windows Vista® SP1, y varias empresas de hospedaje web ya han empezado a ofrecer servicios con IIS 7.0 a diseñadores y desarrolladores web que deseen trasladar sus aplicaciones web existentes a la nueva plataforma de servidor web.
En este artículo, trataremos las mejoras clave de IIS 7.0 más importantes para los profesionales de TI y profundizaremos en la migración de aplicaciones web ASP.NET y PHP. Sin embargo, en primer lugar, me gustaría describir un laboratorio de pruebas que se parezca a un entorno de producción básico.
Este es un paso importante. Antes de implementar IIS 7.0 en los servidores de producción, necesitará pasar un tiempo realizando pruebas exhaustivas en un entorno de laboratorio para asegurarse de que sus aplicaciones web se ejecutan correctamente en el nuevo servidor web.

Preparado, listo, prueba
Mi laboratorio de pruebas incluye los sistemas que ejecutan Windows Server 2003 e IIS 6.0, que hospedan aplicaciones ASP.NET, y servidores que ejecutan Ubuntu 7.10 (distribución Linux) y Apache HTTP Server 2.2, que hospedan las aplicaciones web basadas en PHP. Mi objetivo final es la implementación de Windows Server 2008 en los sistemas provisionales y de producción, así como la transición de aplicaciones web complejas para sustituir versiones de IIS 6.0 y de Apache por IIS 7.0.
Tengo dos aplicaciones web clave: DotNetNuke 4.7 y osCommerce 3.0a4. DotNetNuke es un marco de aplicación web basado en ASP.NET 2.0 y Microsoft® SQL Server®. La otra aplicación, osCommerce, es la versión alfa más reciente de una solución de comercio electrónico con funciones completas creada en PHP y MySQL. Usemos estas aplicaciones avanzadas con IIS 7.0.
Me gustaría dejar claro que mi intención no es comparar versiones, productos o plataformas de software. No obstante, hay una gran cantidad de ventajas relacionadas con la estandarización en Windows Server 2008 e IIS 7.0 que debería destacar. En particular, se reduce la complejidad administrativa y se puede minimizar el número total de servidores web en ejecución.
En la Figura 1, puede ver información general acerca del laboratorio de pruebas que estoy usando para este artículo. Si desea seguir mis explicaciones en su propio entorno de pruebas, puede encontrar los vínculos a los componentes de software necesarios, así como instrucciones de instalación paso a paso en el material complementario incluido en la sección de descarga de códigos del sitio web de TechNet Magazine en .com.
Figura 1 Entorno de prueba para la implementación de IIS 7.0 (haga clic en la imagen para ampliarla)
Observe que, aproximadamente al mismo tiempo que me encontraba terminando este artículo, Microsoft lanzó una herramienta de línea de comandos (MSDeploy.exe) para ayudar a los clientes durante la implementación, la sincronización y la migración de aplicaciones web a IIS 6.0 y 7.0. Recomiendo que pruebe esta herramienta. Puede encontrar información detallada en el blog del equipo Microsoft Web Deployment en go.microsoft.com/fwlink/?LinkId=118272.

Configuración de la prueba
Cuando escribí esto, Windows Server 2008 aún era una versión preliminar, por lo que no sustituí Windows Server 2003 en los servidores de controladores de dominio ni de bases de datos. Con el lanzamiento oficial de Windows Server 2008, tal vez desee considerar también la migración de su infraestructura de Active Directory®. La migración de bases de datos de SQL Server® 2005 y MySQL a SQL Server 2008 tampoco se encuentra dentro del alcance de este artículo.
El principal motivo por el que implementé SQL Server 2008 en mi servidor provisional es que requiere menos esfuerzo que la instalación de SQL Server 2005 con Service Pack 2. DotNetNuke podía ejecutarse sin problemas con una base de datos de SQL Server 2008. La instalación de MySQL 5.0 en Windows Server 2008 también resultaba muy sencilla.
Aunque IIS 7.0 está disponible en Server Core, no usé una instalación de Server Core debido a ciertos requisitos para mi prueba. Mi servidor provisional requería la instalación completa, ya que era mi sistema de prueba principal. Además, Microsoft .NET Framework no está disponible en Server Core.
PHP funciona correctamente en Server Core, pero mi objetivo es consolidar las aplicaciones ASP.NET y PHP, por lo que Server Core no es una opción. Hasta que .NET Framework no sea compatible con Server Core, deberá realizar una instalación completa para que se acepte el uso de aplicaciones ASP.NET. Si desea obtener instrucciones detalladas paso a paso para la instalación del entorno de prueba, consulte el archivo 01_install_testlab.htm del material complementario.
Opté por realizar una instalación limpia de Windows Server 2008 (en lugar de actualizar servidores existentes). Entre otras cosas, la instalación limpia facilita la implementación de un escenario de migración de ensayo como el que aparece en la Figura 2. La estrategia subyacente consiste en conservar las granjas de servidores web existentes en ejecución hasta que todos los componentes de aplicaciones web relevantes se hayan probado correctamente en el servidor provisional y se hayan trasladado a la nueva granja de servidores web de IIS 7.0.
Figura 2 Preparación del conmutador a IIS 7.0 (haga clic en la imagen para ampliarla)
Puede mover todas las aplicaciones web existentes a la vez o de forma gradual, en función de la complejidad de su entorno. Una vez que lleve a cabo una prueba de aceptación en la nueva granja de servidores web para todas las aplicaciones y los sitios web, puede realizar el cambio mediante la modificación de los registros DNS de interés con el fin de dirigir a los exploradores a la nueva granja de servidores web de IIS 7.0. De esta forma, se minimizan el tiempo de inactividad y las interrupciones.

Mejoras importantes para los administradores de TI
MSDN® Magazine cuenta con un excelente artículo de Mike Volodarsky titulado "Explore el servidor web de Windows Vista y más allá" (disponible en msdn2.microsoft.com/magazine/cc163453.aspx), donde puede encontrar información acerca de las mejoras en IIS 7.0.
Otra buena lectura es una publicación en el blog del equipo de Microsoft.com, llamada "The Tasty Morsels Found in Dogfood" (disponible, en inglés, en go.microsoft.com/fwlink/?LinkId=117436). En ella, se resumen las experiencias iniciales con IIS 7.0 de los miembros del equipo. En pocas palabras, según ellos, las principales mejoras son:
  1. Instalación simplificada.
  2. Gran compatibilidad.
  3. No hacen falta metabases.
  4. La configuración centralizada se lleva a cabo a través del archivo applicationHost.config que se encuentra en el recurso compartido de UNC.
  5. Configuración delegada mediante archivos web.config en los directorios de aplicación
  6. Herramientas de administración mejoradas.
  7. Seguimiento de solicitudes con error.
  8. Solicitud de filtrado sin necesidad de URLScan.
  9. Disponibilidad de sincronización de contenido simplificado mediante recursos compartidos de UNC.
10. Almacenamiento en la memoria caché de resultados de contenido dinámico.
Por supuesto que la instalación simplificada está en mi lista. En su publicación en el blog, el equipo de Microsoft.com muestra cómo implementar todas las características de IIS 7.0 (o, claro está, sólo las características que desee) con una única línea de comandos. Adopté este enfoque en mis instrucciones de instalación del laboratorio de prueba, con la línea de comandos que aparece en la Figura 3.
Hay que reconocer que el comando es bastante largo. Si desea copiar este comando, le recomiendo que lo copie y lo pegue del sitio web de TechNet Magazine, en lugar de escribirlo a mano. Aunque este comando coloca todos los módulos disponibles en el equipo con IIS 7.0, no incluye PHP. IIS 7.0 no incluye PHP, y la descarga y la instalación de los paquetes de Debian por Internet es un concepto extraño para Windows® Package Manager (pkgmgr.exe). Aquí es donde entra el Kit de instalación automatizada (AIK) de Windows.
Figura 3 Implementación de las características de IIS 7.0 con una línea de comandos sencilla
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
Con AIK, puede crear un DVD de instalación personalizada para Windows Server 2008 que incluya IIS 7.0 y PHP 5. También puede incluir MySQL, archivos de aplicación web y cualquier otro componente necesario para la implementación. Todos los componentes pueden ser parte del programa de instalación de Windows Server 2008, lo que permite aplicar las personalizaciones de forma coherente en todos los servidores web. No es necesario modificar las líneas de comandos ni los archivos de configuración.
Puede, incluso, crear un DVD personalizado para instalaciones completamente desatendidas. El AIK incluye documentación y herramientas para crear un archivo AutoUnattend.xml, que puede colocar en la carpeta raíz del DVD. El archivo Custom Image Deployment.htm del material complementario proporciona instrucciones paso a paso.
Muchos administradores también están de acuerdo en que la compatibilidad es una mejora clave. A medida que avanzaba, esperaba encontrarme una serie de problemas de compatibilidad con DotNetNuke y osCommerce, pero la transición a IIS 7.0 fue bastante sencilla, a pesar de que estas aplicaciones web incluyesen características avanzadas, como la autenticación de formularios y las direcciones URL de uso fácil con motores de búsqueda.
Con DotNetNuke, no encontré ningún problema hasta que pasé a un escenario de granja de servidores web compleja con contenido UNC compartido en una plataforma de 64 bits. No obstante, este problema apenas tenía ninguna gravedad. En última instancia, esta compatibilidad mejorada implica que se necesita menos tiempo para conseguir la ejecución de las aplicaciones web en IIS 7.0.
Si se encontrase algún problema de compatibilidad con sus aplicaciones web, la capacidad integrada de diagnóstico y seguimiento pasará a ser una de sus características nuevas favoritas rápidamente. La información de diagnóstico detallada es muy significativa y las rutas de solución sugeridas son útiles y funcionan de verdad.
En la Figura 4, puede ver la información de diagnóstico que recibe al ejecutar DotNetNuke 4.7 en IIS 7.0 en modo integrado. En este ejemplo, aparecen tres opciones (incluidas en la sección "Cosas que puede hacer"). La modificación de la aplicación para que admita el modo integrado probablemente sea la mejor elección para los desarrolladores de DotNetNuke. Por el contrario, hacer caso omiso del error podría ser mala idea. Yo prefiero la tercera opción, habilitar el modo clásico mediante el paso de la aplicación web a Classic .NET AppPool, ya que deseo ejecutar DotNetNuke 4.7 sin modificar en IIS 7.0.
Figura 4 Información de diagnóstico para DotNetNuke durante la ejecución en modo integrado (haga clic en la imagen para ampliarla)

Arquitectura IIS
Tal vez se pregunte qué son los modos integrado y clásico, y por qué afectan a la aplicación ASP.NET (DotNetNuke), pero no a la aplicación PHP (osCommerce). Para comprenderlo mejor, debe echar un vistazo en primer lugar a la arquitectura de IIS 7.0. Las versiones anteriores integran el tiempo de ejecución de ASP.NET en el servidor web principal, fundamentalmente, mediante una extensión ISAPI (aspnet_isapi.dll). IIS 7.0, por otro lado, permite a los módulos de ASP.NET conectarse directamente al servidor web principal a través de un módulo HTTP de nivel global llamado ManagedEngine, que carga el archivo DLL de compatibilidad con ASP.NET (webengine.dll) en la canalización de procesamiento de solicitudes de IIS 7.0.
Los módulos nativos usan la API principal de servidor web IIS para registrarse en eventos concretos de la canalización, como BeginRequest, AuthenticateRequest, AuthorizeRequest y ExecuteRequestHandler. ManagedEngine también ofrece la compatibilidad necesaria para integrar los módulos de ASP.NET en la canalización de solicitudes. Mediante esta nueva arquitectura, IIS 7.0 puede invocar módulos nativos y de ASP.NET en cualquier etapa del procesamiento de solicitudes, con independencia del tipo de contenido solicitado.
A modo de ejemplo, tomemos la autenticación de usuario de ASP.NET. En IIS 6.0, un módulo HTTP basado en ASP.NET puede registrarse en eventos OnAuthenticate (como FormsAuthentication.OnAuthenticate y WindowsAuthentication.OnAuthenticate) para establecer la identidad del usuario en el HttpContext actual. Esto es de gran utilidad en el tiempo de ejecución de ASP.NET, pero no puede usar el código ASP.NET para proteger los recursos expuestos a través de una aplicación web basada en PHP.
Según su configuración de mapa de scripts, IIS 6.0 reenvía las solicitudes para los tipos de contenido de ASP.NET a aspnet_isapi.dll, pero no reenvía las solicitudes para los tipos de contenido de PHP a la extensión de ISAPI para ASP.NET. Después de todo, ASP.NET no procesa el código PHP, pero también significa que el código de autenticación ASP.NET no se ejecuta si se solicita una página de PHP. De este modo, con IIS 6.0, necesita duplicar la lógica de autenticación, ya que las aplicaciones PHP deben implementar sus propios mecanismos de autenticación.
IIS 7.0 usa un modelo de procesamiento controlado por eventos que permite mezclar y hacer coincidir módulos individuales en la canalización de solicitudes. Entre otros componentes, IIS 7.0 incluye los módulos administrados WindowsAuthentication y FormsAuthentication que producen eventos OnAuthenticate cuando la canalización de solicitudes desencadena el evento AuthenticateRequest. Ahora dispone de un módulo nativo, como RequestFilteringModule o IpRestrictionModule, controla el evento BeginRequest para rechazar solicitudes críticas lo antes posible, ejecuta un código de autenticación de ASP.NET personalizado en el evento AuthenticateRequest y hace que FastCgiModule ejecute el motor de scripting de PHP (php-cgi.exe) en el evento ExecuteRequestHandler para procesar páginas de PHP.
El resultado de esta arquitectura integrada es que los desarrolladores web no tienen que duplicar el código para implementar la lógica empresarial común. Puede proteger todos sus recursos de IIS, incluidas las aplicaciones PHP, mediante un código de autenticación personalizado de ASP.NET. Puede realizar otras tareas previas y posteriores al procesamiento a través de módulos de ASP.NET, como la reconfiguración de direcciones URL, el seguimiento personalizado y el registro de errores.

Modos integrado y clásico
El efecto secundario que provoca esta nueva arquitectura es que las aplicaciones ASP.NET existentes pueden necesitar cambios en el código y en la configuración que deberían realizar los desarrolladores de aplicaciones para asegurar que los cambios no provocan conflictos de módulos en la canalización de la solicitud. Si no puede trasladar inmediatamente una aplicación web existente, puede habilitar el modelo clásico en el conjunto de aplicaciones que el proceso de trabajo usa para ejecutar la aplicación web. IIS 7.0 no carga ManagedEngine en los procesos de trabajo en modo clásico, lo que implica en este caso que la canalización de solicitud no puede resolver o invocar módulos de ASP.NET. En lugar de eso, IIS 7.0 activa una serie de controladores de ISAPI, que están basados en IsapiModule (aspnet_isapi.dll), para procesar tipos de contenido de ASP.NET similares a IIS 6.0. Puede comprobarlo si analiza la sección de controladores en system.webServer en el archivo applicationHost.config, que puede encontrar de forma predeterminada en la carpeta %WinDir%\System32\InetSrv\Config.
Busque la cadena aspx a modo de ejemplo y encontrará una entrada que señala a PageHandlerFactory-Integrated (cargado en los procesos de trabajo de grupo de aplicaciones en modo integrado según el parámetro preCondition="integratedMode") y otras entradas que señalan a PageHandlerFactory-ISAPI-2.0 y a PageHandlerFactory-ISAPI-2.0-64 (cargados en los procesos de trabajo de grupo de aplicaciones en modo clásico según el parámetro preCondition="classicMode").
Ya que el modo de canalización se establece a nivel de grupo de aplicaciones, IIS 7.0 puede ejecutar aplicaciones web en los modos integrado y clásico a la vez. Los procesos de trabajo sólo necesitan ejecutarse en diferentes grupos de aplicaciones, pero se pueden hospedar en el mismo servidor.
Recuerde que los modos integrado y clásico sólo afectan a la forma en que IIS 7.0 integra ASP.NET en la canalización de solicitudes. Estos modos de canalización no afectan a las aplicaciones PHP de forma directa. FastCgiModule y el resto de los módulos nativos se cargan sin condiciones previas relacionadas con el modo de canalización en los modos integrado y clásico. FastCGI es la interfaz preferida para ejecutar el motor de scripting PHP en IIS 7.0. En lugar de usar FastCGI, puede crear también una asignación de controlador para el motor de scripting PHP mediante CGI, o puede usar IsapiModule junto con PHP-ISAPI (php4isapi.dll).
No obstante, en mi opinión, estas alternativas de configuración al estilo de IIS 6.0 han quedado desfasadas ahora que FastCGI rendimiento y estabilidad muy superiores. CGI es más lento, ya que IIS debe inicializar un nuevo proceso CGI para cada solicitud HTTP, mientras que FastCGI usa repetidamente los procesos de CGI para varias solicitudes. ISAPI necesita una compilación de PHP seguro para subprocesos, que implica una sobrecarga mayor que la ejecución de PHP no seguro para subprocesos.
Probablemente sea más importante todavía el hecho de que no todas las extensiones PHP están disponibles en una versión segura para subprocesos, y que no es recomendable la ejecución de extensiones no seguras para subprocesos con ISAPI, ya que puede provocar problemas de estabilidad en el servidor. FastCGI, por otro lado, es un entorno de concurrencia única, como CGI. Se usa para ejecutar versiones de PHP no seguras para subprocesos. FastCGI es estable, rápido e ideal para PHP 5 en IIS 7.0. También está disponible en IIS 6.0 si no está listo aún para el cambio a IIS 7.0.

Módulos y funcionalidad
IIS 7.0 dispone de una arquitectura altamente modularizada (o, desde el punto de vista de los desarrolladores de IIS, de un conjunto de características formado por componentes). Esto es algo positivo para los administradores web, que desean mantener la superficie de memoria y la superficie de ataque de IIS 7.0 tan pequeñas como se pueda. Al habilitar diferentes módulos, o incluso sustituir los módulos estándares con módulos personalizados, puede obtener control total sobre las características de IIS 7.0 de los servidores web.
Si desea ejecutar ASP.NET en modo integrado o clásico, así como aplicaciones PHP en el mismo servidor, deberá instalar, como mínimo, la función de servidor web y los módulos principales para admitir el procesamiento de solicitudes, la configuración de servidores, ASP.NET, ISAPI y CGI (que incluye el módulo FastCGI). Esto se puede conseguir mediante la siguiente línea de comandos:
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
Generalmente, prefiero instalar IIS 7.0 con todas las opciones disponibles en el servidor provisional con el fin de asegurarme de que todos los componentes y las herramientas administrativas están disponibles para hacer que mis aplicaciones web estén listas lo antes posible. Mi estrategia consiste en asegurarme de que todo funciona correctamente y, a continuación, limito la configuración mediante la desinstalación de servicios de función y la deshabilitación de módulos. Cuando una aplicación web empieza a dar problemas, agrego de nuevo los servicios de función o los módulos que eliminé.
También puede usar Package Manager (pkgmgr.exe) o la herramienta de línea de comandos de IIS 7.0 (appcmd.exe), o modificar la sección globalModules en el archivo applicationHost.config directamente, pero creo que las herramientas gráficas son muy útiles. Recuerde que algunos módulos, como RequestFilteringModule y StaticCompressionModule, son bastante útiles, incluso aunque no son, en sentido estricto, necesarios para la ejecución de las aplicaciones web. Al desinstalar un módulo necesario para un grupo de aplicaciones, recibirá un error HTTP al tratar de obtener acceso a la aplicación web, como se muestra en la Figura 5.
Figura 5 Una aplicación ASP.NET no se ejecutará en modo clásico si no puede encontrar IsapiModule (haga clic en la imagen para ampliarla)
Nota: a modo de práctica recomendada, asegúrese de que el mismo grupo de módulos está instalado y habilitado para todos los servidores de IIS 7.0. Si desea consultar los componentes instalados, visite HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\y compruebe las claves del Registro. Un valor REG_DWORD de 0000 0001 para una clave del Registro, por ejemplo, para NetFxEnvironment o CGI, muestra que el componente correspondiente está instalado.

Migración de aplicaciones web
Ya vale de teoría; llegó la hora de ponerse en acción y mover algunas aplicaciones web a IIS 7.0. Como ya dije anteriormente, mi servidor provisional ejecuta IIS 7.0 con todos los componentes disponibles y la versión PHP 5 no segura para subprocesos registrada con FastCGI. Antes de empezar, necesito hacer un par de preguntas básicas:
  • ¿Necesita la aplicación web un sistema de administración de bases de datos, como SQL Server o MySQL?
  • ¿Necesito instalar o configurar componentes adicionales, como conexiones ODBC, objetos COM o certificados SSL?
  • ¿Necesita la aplicación web cuentas de servicio especiales y permisos locales o de acceso remoto elevados para el acceso a recursos compartidos de archivos, entre otros?
  • ¿Hay alguna dependencia en las características específicas de plataforma que no están disponibles en IIS 7.0, como dependencias en el módulo Apache para la reconfiguración de direcciones URL (mod_rewrite)?
Preguntas como estas le permitirán conseguir que sus aplicaciones web se ejecuten correctamente en IIS 7.0 con mayor rapidez. Por ejemplo, al intentar la migración de una aplicación PHP de Apache 2.2 que use mod_rewrite (por ejemplo, para facilitar el uso de motores de búsqueda o para evitar el robo de ancho de banda mediante imágenes vinculadas en línea), experimentará problemas hasta que implemente una solución de reconfiguración de direcciones URL personalizada compatible en IIS 7.0. Por suerte, osCommerce no necesita la funcionalidad de mod_rewrite en IIS 7.0, pero tal vez algunos paquetes de optimización de motores de búsqueda lo hagan.
Ahora que he determinado e instalado los componentes adicionales necesarios en el servidor provisional, ya puedo poner en funcionamiento mis aplicaciones web. Una vez más, me hago a mí mismo algunas preguntas:
  • ¿Cuál es la configuración más simple que puedo usar para tener compatibilidad con la aplicación web?
  • ¿Qué configuración se usa actualmente en el entorno de producción?
  • ¿Puedo optimizar la configuración de la aplicación web en la nueva plataforma?
  • ¿Cuál es el conjunto mínimo de servicios y módulos de función que necesita la aplicación web para funcionar con la configuración deseada?
La ejecución de la aplicación web con la configuración más sencilla constituye la forma más rápida de asegurarse de que realmente funciona. Si todo parece correcto, es el momento de aplicar una configuración parecida al entorno de producción existente e importar datos de producción en bases de datos de prueba. Por supuesto, puede que algunos problemas sólo surjan en las configuraciones avanzadas.
También puede observar oportunidades para introducir mejoras al reflejar la configuración de producción en un laboratorio de pruebas. La colocación del archivo applicationHost.config en un recurso compartido de UNC es una gran forma de centralizar la configuración de varios servidores web. Para aumentar la tolerancia a errores mediante la redundancia y la sincronización de contenido, considere la implementación de la replicación del sistema de archivos distribuido (DFS), que consiste en un motor de replicación con varios maestros basado en estados y está disponible con Windows Server 2003 R2 y Windows Server 2008. Además, puede reducir los requisitos de almacenamiento en los clientes web si coloca los archivos de contenido de sus aplicaciones web en recursos compartidos de UNC.
Otras posibles optimizaciones pueden suponer seguridad o almacenamiento dinámico en caché. Las optimizaciones de seguridad y de rendimiento no estaban entre los objetivos de mi laboratorio de pruebas, ya que no se encuentran dentro del alcance de este artículo. Tampoco configuré DFS para evitar la instalación de otros servidores. Las instrucciones paso a paso del material complementario ofrecen un ejemplo simplificado de cómo hospedar un archivo applicationHost.config y contenido web en recursos compartidos de UNC. La Figura 6 muestra cómo implementar una granja de servidores web basada en UNC con DFS.
Figura 6 Implementación de granjas de servidores web con un archivo applicationHost.config y contenido web en recursos compartidos de UNC (haga clic en la imagen para ampliarla)

Conclusión
IIS 7.0 es una plataforma de servidor web impresionante. Incluye una arquitectura de núcleo rediseñada a la vez que conserva casi el 100% de la compatibilidad con IIS 6.0. Debería ser capaz de ejecutar la mayoría de las aplicaciones web ASP.NET existentes sin necesidad de realizar cambios. No obstante, dada la amplitud de los cambios arquitecturales, no puede dar por hecho que no encontrará problemas de compatibilidad.
Tanto si está migrando aplicaciones web ASP.NET como PHP a IIS 7.0, es mejor adoptar un enfoque organizado y probado con énfasis en operaciones adecuadas de planeación, preparación, pruebas y documentación de código y cambios de configuración.
IIS 7.0 merece la pena. Hay muchas mejoras en áreas como la seguridad, el rendimiento, la facilidad de configuración y la flexibilidad. Haría falta un libro entero para hablar de todas ellas. La configuración centralizada y el uso compartido de contenido con base a los recursos compartidos de UNC, la configuración delegada a través de archivos web.config en directorios de aplicaciones, las herramientas de administración mejoradas, la información de diagnóstico detallada, el seguimiento de solicitudes con error y el almacenamiento dinámico en caché de resultados son formas infalibles de ganarse el afecto de los administradores web.
La capacidad de combinar módulos nativos y administrados en la canalización de procesamiento de solicitudes beneficia a los desarrolladores de ASP.NET. Las mejoras de rendimiento y estabilidad que se incluyen con FastCGI en IIS 7.0 son noticias fantásticas para los desarrolladores de aplicaciones PHP.
Hay otro aspecto importante que ayuda a los profesionales de TI a triunfar con IIS 7.0: el portal de la comunidad Microsoft IIS (www.iis.net). Aquí encontrará toda la información que necesita, incluidos artículos detallados acerca de la nueva arquitectura, código fuente para los desarrolladores de C++ y ASP.NET que muestra cómo crear módulos de IIS 7.0 e instrucciones paso a paso para poner en funcionamiento las aplicaciones PHP. Definitivamente, debería visitar este sitio. Es un buen sitio para obtener las respuestas a sus preguntas relacionadas con IIS.

Fergus Strachan es fundador y director de Maestra Ltd London, una empresa de asesoría especializada en el diseño de infraestructura de TI y el apoyo a la administración de proyectos, que ofrece servicios a bancos internacionales e instituciones educativas en el Reino Unido. Escribe artículos acerca de la tecnología de servidores de Microsoft y es autor de Integrating ISA Server 2006 with Microsoft Exchange 2007. También es coautor de Microsoft Exchange Server 2003 Resource Kit.

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


Comunicaciones y colaboración
Planeación de la migración a la mensajería unificada
Jeff Goodwin
De un vistazo:
  • Breve historia del correo de voz
  • Aspectos que deben considerarse al planear la migración
  • Estrategias de migración
  • Desafíos con varios sitios

Contenido
Breve historia del correo de voz
Planeación de la migración
Estrategias prácticas de migración
Tutorial de migración
La importancia de seguir un plan
La migración de un sistema de correo de voz heredado a una plataforma de mensajería unificada puede suponer un desafío. Pero, con cierta planeación previa, es posible llevar a cabo esta migración muy fácilmente al mismo tiempo que se reduce cualquier interrupción que los usuarios puedan experimentar. De hecho, la reducción de la
interrupción del servicio probablemente deba ser su objetivo principal a la hora de ejecutar un proyecto de migración de este tipo.
Para saber todo lo que necesita planear durante la migración, debe, en primer lugar, conocer por qué las compañías creen que el correo de voz es una aplicación crítica. Esta información básica le ayudará a comprender qué características necesita implementar durante la migración a la mensajería unificada y por qué dichas características son importantes para los administradores.

Breve historia del correo de voz
Puesto que no es posible planear cómo llegar a un destino sin saber exactamente dónde comienza el viaje, mi intención es retroceder y ofrecer una breve introducción de los sistemas de correo de voz: de dónde proceden y cómo se estructuran. Existen teorías acerca de quién inventó el primer sistema de correo de voz. Sin embargo, el primer sistema de correo de voz disponible para la venta se denominó VMX, acrónimo de Voice Message Exchange (intercambio de mensajes de voz).
VMX se diseñó en un principio para proporcionar un método de comunicación por voz con otras personas dentro de la misma compañía, del mismo modo que el correo electrónico se usa hoy en día. El sistema contaba con comandos para enviar y reenviar mensajes, y devolver respuestas a los mismos. Siempre que se dejaba un mensaje, el usuario recibía una notificación. Existían varios métodos de notificación, entre ellos, las llamadas (llamar a la persona a un número de teléfono específico) y una luz de mensaje en espera (un indicador que se iluminaba en el teléfono de la persona).
A medida que VMX ganaba popularidad, las organizaciones comenzaron a unir sus sistemas de correo de voz. Esto generó una solución de correo de voz a nivel de empresa en la que los empleados podían enviar mensajes de difusión a listas de distribución de toda la compañía.
Por supuesto, para proporcionar una manera de interactuar con el sistema de correo de voz, debía crearse una interfaz de usuario de teléfono (TUI). Estas TUI han cambiado a lo largo de los años; no existe una interfaz estándar para el correo de voz. Si dispone de correo de voz en su teléfono móvil, posiblemente esté acostumbrado a oír cosas como "pulse 1 para el correo de voz". Pero, a medida que los sistemas de correo de voz controlados por voz, que usan interfaces de usuario de voz (VUI), pasan a ser más comunes, la propia TUI deja de ser tan importante como era anteriormente. Sin embargo, no debe subestimar el apego que los usuarios puedan tener a una interfaz específica.
Los sistemas de correo de voz de empresa en uso hoy día dependen de dos arquitecturas distintas: distribuida y centralizada. En la Figura 1, las oficinas de Seattle, Nueva York y Austin tienen una arquitectura de correo de voz distribuida, en la cual los sistemas de correo de voz están en la misma ubicación en cada uno de estos sitios. Por contraste, las oficinas de Londres, París y Glasgow tienen un modelo centralizado, donde la infraestructura PBX se conecta en red y todas las llamadas se enrutan a la ubicación central en Londres. Ambos modelos tienen ventajas y desventajas. Pero tenga en cuenta que, incluso en un modelo distribuido, los sistemas de correo de voz pueden conectarse en red para la entrega de mensaje entre los sitios.
Figura 1 Los dos modelos comunes de arquitectura de correo de voz (haga clic en la imagen para ampliarla)
Hay tres razones principales por las que una organización puede seleccionar el uso de un modelo distribuido: la necesidad de disponibilidad local, el uso de sistemas PBX dispares que no se pueden unir en red y las restricciones del plan de marcado uniforme.
Algunas organizaciones necesitan el sistema de correo de voz para que, en casos de suspensión de la actividad de la red, el sistema de correo de voz y PBX local continúe funcionando correctamente, lo que mantiene la funcionalidad total del sistema del sitio. Los sistemas de respuesta interactiva de voz (IVR) seguirán funcionando, y las personas que llaman desde fuera podrán dejar mensajes. De hecho, no hay repercusión en los usuarios finales, y el funcionamiento continúa siendo normal. Puede que esto le suene familiar; es la misma razón por la que muchas organizaciones deciden localizar sus servidores con Microsoft® Exchange Server. Puede que su organización desee llevar a cabo una evaluación del riesgo para determinar si esta supervivencia localizada es necesaria.
Cuando una organización aumenta su número de adquisiciones, los sitios remotos tienen, con frecuencia, plataformas PBX que no pueden conectarse en red con el resto de la infraestructura. En este caso, las organizaciones pueden cambiar la infraestructura PBX, lo cual supone un proyecto de alto costo, o dejar el sitio intacto y conectar en red la plataforma de correo de voz para proporcionar un intercambio de mensajes de correo de voz sin complicaciones. También hay disponibles servidores de terceros para permiten conectar en red distintos sistemas de correo de voz.
Con el objeto de conectar en red las PBX, es necesario un plan de marcado uniforme (UDP). Un UDP dice que las extensiones de teléfono y de correo de voz no se pueden superponer. En la Figura 1, vemos que Seattle, Nueva York y Austin tienen intervalos de extensión que se superponen. Esto es porque no hay un UDP para los sitios ubicados en Estados Unidos. Podría crearse un UDP ampliando los intervalos de extensión a 7 o 10 dígitos, pero esto provoca otros problemas.
Puede que tenga que cambiar las plantillas de marcado en cada teléfono, cambiar todas las extensiones de usuario en el PBX y cambiar cualquier aplicación que se integre con el sistema. Y esto puede provocar la frustración de los empleados, que deben recordar y marcar ahora 7 o 10 dígitos para llamar a alguien que puede encontrarse muy cerca.
Aunque estas características básicas y los desafíos arquitectónicos han mejorado con el paso de los años, los conceptos básicos del correo de voz siguen siendo los mismos. El intercambio de mensajes, las redes, los métodos de notificación, la interfaz de usuario y la arquitectura son todos factores importantes que debe tener en cuenta a la hora de planear una migración.

Planeación de la migración
La mensajería unificada implica cambios en cada una de las partes de la organización, desde cómo los usuarios interactúan con el correo de voz hasta cómo se ha diseñado la arquitectura o cómo los administradores llevan a cabo la administración. Todas estas diferencias deben ser tratadas a la hora de migrar a un sistema de mensajería unificada. Lo que sigue es una lista de comprobación de lo que hay que tener en cuenta a la hora de planear la migración.
Red de mensajes Cualquier organización que pase de una plataforma de correo de voz heredada a la mensajería unificada de Exchange debe tener un período de coexistencia. Si su organización ya ha implementado una red de mensajes, es decir, un sistema para interoperar distintos sistemas de correo de voz, simplemente agregue el sistema de mensajería unificada a la lista de sistemas existentes. Recomiendo encarecidamente la red de mensajes para cualquier organización que tenga numerosas ubicaciones con correo de voz o sistemas PBX independientes.
Infraestructura Para diseñar la infraestructura de la mensajería unificada es necesario que tome decisiones sobre los requisitos de red, la integración de telefonía, la colocación de servidores, etc. Si no está familiarizado con las estrategias de implementación básicas, lea mi anterior artículo "Implementación de Mensajería unificada con Exchange Server 2007" (consulte technet.microsoft.com/magazine/cc137737).
Operadores automáticos Muchos sistemas contienen varios operadores automáticos, distintos según sea de día, de noche y para los distintos departamentos. Necesitará trabajar con el equipo de telecomunicaciones de su organización para reflejar los operadores automáticos en los sistemas de correo de voz heredados.
Indicación de mensaje en espera Puede que desee que su solución pueda prescindir de los indicadores de mensaje en espera, pero sus usuarios, con toda probabilidad, solicitarán esta característica. No debe subestimar la opinión de los usuarios en este respecto. Afortunadamente, hay numerosas compañías que han desarrollado aplicaciones de indicador de mensajes para Exchange Server.
Compatibilidad con fax Muchas plataformas de correo de voz heredadas son compatibles con fax entrante. La Mensajería unificada de Exchange es también compatible con las capacidades de fax entrante, por lo que puede que desee incluir la compatibilidad con esta capacidad en su nueva implementación.
Respuesta interactiva de voz Algunas plataformas de correo de voz heredadas son compatibles con aplicaciones de respuesta interactiva de voz (IVR) que la Mensajería unificada de Exchange no puede duplicar. Puede que desee dejar estos sistemas implementados mientras encuentra otra alternativa adecuada.
Administración La Mensajería unificada de Exchange depende de Active Directory® y de la función de servidor de buzones de Exchange. Necesitará planear cómo la administración, los requisitos del sistema y demás, se verán afectados por una implementación de mensajería unificada.
Interfaz de usuario Al lanzar una nueva interfaz de usuario, debe proporcionar recursos de aprendizaje a sus usuarios. La Mensajería unificada de Exchange emplea una interfaz muy similar a la de la mayoría de los proveedores de telefonía móvil, por lo tanto, será bastante intuitiva para la mayoría de los usuarios. También usa el reconocimiento de voz de forma que los usuarios no necesiten usar tonos. En Exchange Server, esto se denomina Outlook® Voice Access.
Recursos de aprendizaje La mensajería unificada introduce un cambio de paradigma en la manera en que los usuarios se comunican y usan el correo de voz. Más allá de la interfaz de usuario, debe ofrecer recursos de aprendizaje a sus usuarios para enseñar prácticas recomendadas y presentar las maneras, nuevas y más eficientes, en las que podrán comunicarse. Por ejemplo, puede que los usuarios no sepan cómo interactuar con el correo de voz en su bandeja de entrada o cómo configurar algunas opciones avanzadas de mensajería unificada.

Estrategias prácticas de migración
Sin duda, existen desafíos en la migración de una organización de gran tamaño a una solución de mensajería unificada. Sin embargo, he estado trabajando en comunicaciones unificadas durante 10 años y he visto la migración correcta incluso en las organizaciones más complejas con requisitos muy específicos.
Tanto si se ocupa de una organización de varios sitios como de sitio único, será de ayuda si crea su propia estrategia de migración en torno a estos cinco pasos básicos:
  1. Planeación y diseño de la solución.
  2. Instalación y configuración de la función del servidor Mensajería unificada.
  3. Migración de un grupo piloto.
  4. Revisión del diseño según los comentarios del grupo piloto.
  5. Migración de los usuarios.
Las organizaciones con varios sitios se enfrentan, por supuesto, a ciertos desafíos que, generalmente, no se encuentran en escenarios de sitio único. Explico estos desafíos por separado en la barra lateral "Desafíos con varios sitios".
La planeación y el diseño de la solución constituyen el paso más importante del proceso de migración. Recomiendo que asigne un equipo de mensajería unificada al proyecto. Este equipo debe incluir a representantes de las distintas partes de la organización con experiencia en telecomunicaciones, Active Directory, Exchange, redes, seguridad, aprendizaje y administración de proyectos. Deberá obtener un gráfico detallado de las arquitecturas de PBX, correo de voz y correo electrónico existentes en la compañía.
Una vez que cuenta con un diseño, puede instalar y configurar la función del servidor Mensajería unificada. No le debe preocupar la instalación de un servidor Mensajería unificada en paralelo a su sistema de correo de voz heredado existente. Asegúrese de seguir las prácticas recomendadas documentadas.
En este momento, está preparado para probar su servidor Mensajería unificada. Designe y migre un pequeño grupo piloto de usuarios al nuevo sistema. Un grupo de 25 a 50 usuarios servirá. Seleccione a los usuarios cuidadosamente, creando un grupo piloto que consista en un grupo variado de usuarios, desde personal de TI y telecomunicaciones a directores de departamentos y personal de ventas. Al implicar a una gama tan variada de personas, podrá determinar mejor si su diseño es acertado, qué requisitos específicos necesita tener en cuenta, qué recursos de aprendizaje podrían ser necesarios para los usuarios, etc.
Una vez que reciba los comentarios del grupo piloto, tendrá que revisar su diseño para solucionar cualquier problema que se haya descubierto durante la prueba. Específicamente, deberá volver a visitar los aspectos que ya expliqué en la sección "Aspectos que deben considerarse al planear la migración" y asegurarse de que ha tratado estos puntos adecuadamente para su organización. Tenga en cuenta que los cambios más comunes en este sentido pertenecen generalmente al aprendizaje.
El paso final consiste en migrar a los usuarios. Hay muchas opiniones y estrategias respecto a cómo migrar el sistema a la producción total. Las dos metodologías principales son una migración gradual y una migración inmediata.
Si decide migrar gradualmente su comunidad de usuarios durante un período de semanas o meses, creará islas de correo de voz entre sus usuarios heredados y sus usuarios de mensajería unificada. Esto impide que los usuarios puedan reenviarse mensajes unos a otros a través del correo de voz. Y, si su diseño no incluye una solución de red de mensajes, interrumpirá algunas de sus comunicaciones de negocio. Si va a hacer esto, recomiendo la inclusión de una solución de red de mensajes en su diseño inicial.
Para una migración inmediata, debe mover a todos los usuarios en una única fase. Las organizaciones realizan normalmente este tipo de migración durante un fin de semana, de forma que tengan tiempo de probar el sistema, realizar cambios de configuración y dar marcha atrás a la migración en caso de que se produzca un bloqueo grave.
Sea cual sea el método que elija, asegúrese de preparar al personal del servicio de asistencia con respecto a las preguntas y las respuestas más comunes que ha reunido gracias al grupo piloto. También debe asegurarse de que los trabajadores del servicio de asistencia realicen adecuadamente las tareas clave, como la habilitación de usuarios, la validación de la habilitación de usuarios y el cambio de contraseñas.

Tutorial de migración
A medida que avanzo a través de la migración de muestra, tenga en cuenta que el objetivo principal de una migración correcta a la mensajería unificada es mover los buzones de correo de voz desde una plataforma de correo de voz heredada a la mensajería unificada, con las mínimas interrupciones posibles a los usuarios (tanto internos como externos).
La Figura 2 detalla la arquitectura de una organización. No hay planes de cambiar esta arquitectura mixta de Exchange. Las oficinas con sede en EE.UU. disponen de un centro de datos principal ubicado en Seattle. Todas las aplicaciones de TI de Austin dependen de Seattle, y la oficina de Nueva York garantiza los servicios de Exchange localizados. El correo de voz para las ubicaciones de EE.UU. está distribuido debido a la dispar infraestructura PBX. Técnicamente, la infraestructura PBX no se puede conectar en red para proporcionar correo de voz centralizado. Las oficinas europeas, por contraste, tienen un centro de datos centralizado ubicado en Londres. Todas las aplicaciones de TI y telecomunicaciones en Europa dependen de este centro de datos centralizado.
Figura 2 Arquitectura de muestra antes de la migración (haga clic en la imagen para ampliarla)
Toda la infraestructura de correo de voz se basa en la plataforma Octel (ahora conocida como Avaya). Todos los sistemas de correo de voz se han conectado en red mediante Octel Analog Networking (OAN), protocolo de red propietario que usa líneas telefónicas analógicas y llamadas de larga distancia para enviar mensajes de correo de voz en red. Esta arquitectura posibilita la mensajería de voz a nivel corporativo entre sitios.
Desafíos con varios sitios
Las organizaciones de varios sitios se enfrentan a un número indeterminado de desafíos a la hora de implementar la mensajería unificada. Afortunadamente, es posible extraer enseñanzas de algunos de los desafíos a los que se han enfrentado otras organizaciones. No podría cubrir cada uno de los desafíos en este artículo, pero sí puedo exponer los desafíos más comunes que he visto al trabajar con varias organizaciones.
"Tengo una arquitectura centralizada de Exchange Server y un entorno de telefonía mixto."
Un entorno distribuido es fácil de diseñar. Debe implantar un servidor Mensajería unificada e integrarlo con la PBX local en cada uno de los sitios. Pero, ¿qué ocurre si tiene un entorno centralizado o incluso un entorno mixto? La pregunta que necesita hacerse es si necesita la supervivencia local de la mensajería unificada en el sitio. Con la supervivencia local de la mensajería unificada, la ubicación puede perder su conexión con el servidor de Exchange centralizado y proporcionar, aún, la funcionalidad de operadores automáticos, además de permitir a las personas que llaman desde el exterior (posiblemente bastantes clientes) dejar mensajes. La respuesta dependerá de lo crítica que sea la ubicación y de la facilidad de administración de la solución.
Si requiere la supervivencia local de su sitio, un servidor Mensajería unificada remoto en el sitio puede ser una buena opción. Si no es necesario, puede instalar una puerta de enlace SIP en el sitio local. La Mensajería unificada de Exchange no requiere la conexión en red de la infraestructura PBX y, por lo tanto, tampoco se requiere un plan de marcado uniforme.
"Me encuentro en el proceso de actualización de mi arquitectura de Exchange."
Muchos clientes dudan a la hora de comenzar una migración de mensajería unificada mientras se encuentran en proceso de actualización de su infraestructura de Exchange. Mi consejo es que si ya ha tomado la decisión de pasar a la mensajería unificada, siga adelante y realice la migración mientras el servidor de Exchange se está actualizando. Siga simplemente sus planes de actualización y, seguramente, no encontrará complicaciones adicionales en el proyecto.
"Tengo muchos sitios pequeños con menos de 10 empleados y algunos de ellos no incluyen PBX."
En los sitios más pequeños que disponen de una PBX ubicada en el sitio, lo único que tiene que hacer es instalar una puerta de enlace SIP en el sitio local. Para sitios que no disponen de una PBX, existen técnicas de telefonía que se pueden usar para reenviar los teléfonos a la PBX central con el fin de enrutar las llamadas al sistema de mensajería unificada. En resumen, es posible implementar servicios de mensajería unificada en los sitios remotos más pequeños de la organización de forma rentable.
Es importante tener en cuenta que estos sitios más pequeños suponen realmente un gran banco de pruebas para su migración. Una estrategia común de migración consiste en comenzar en el perímetro de la red y pasar, a continuación, al núcleo. Debe migrar los sitios más pequeños en primer lugar y, a continuación, realizar un examen "post mortem" con el equipo de mensajería unificada con el objeto de averiguar qué es lo que funcionó bien y qué desafíos se encontraron. A continuación, puede implementar las lecciones aprendidas cuando migre el próximo sitio.
El equipo de mensajería unificada ha decidido migrar desde el perímetro de la red al núcleo. Para todas las ubicaciones, la implantación del servidor Mensajería unificada seguirá la práctica recomendada de seguir la arquitectura del servidor de Exchange. El equipo ha creado su propia documentación de planeación para cada sitio, teniendo en cuenta los elementos explicados en la sección "Aspectos que deben considerarse al planear la migración". La documentación se usa durante la instalación y la configuración de los servidores, durante el aprendizaje de los usuarios y en la planeación de las estrategias de migración.
Para cada sitio, el equipo planea migrar inmediatamente a los usuarios a la mensajería unificada y mantener la plataforma heredada para admitir el uso de las aplicaciones IVR, que permanecerán activas hasta encontrar una solución alternativa. El equipo decidió esperar 30 días una vez realizada la migración antes de pasar a la siguiente ubicación. El período de espera pretende garantizar que cada sitio se haya ajustado a la nueva plataforma antes de mover a más usuarios y sumar más llamadas a la carga del servicio de asistencia.
La organización ha decidido migrar la ubicación de Austin en primer lugar. Puesto que el correo electrónico de Austin se sirve desde Seattle, el equipo instala la función del servidor Mensajería unificada en Seattle y ofrece la integración PBX con la instalación de una puerta de enlace SIP en Austin. Puesto que la plataforma de correo de voz heredada se ha conectado en red, el equipo debe solucionar la necesidad de conectar en red la plataforma de mensajería unificada con la instalación de un servidor de red de mensajes. El nuevo sistema se enseña a los usuarios, la migración ocurre sin problemas, y el equipo decide migrar Nueva York a continuación.
La ubicación de Nueva York tiene sus propios servidores Buzón de correo y Transporte de concentradores. Las prácticas recomendadas, por lo tanto, establecen que un servidor Mensajería unificada debe instalarse en Nueva York. El equipo instala el servidor, siguiendo los documentos de planeación de la migración. El servidor se agrega a la lista de nodos en el servidor de red de mensajes para la inclusión en la red de correo de voz. Se ofrece preparación a los usuarios, que migran sin problemas a la mensajería unificada.
La ubicación de Seattle ya tiene un servidor Mensajería unificada implementado desde la fase de migración de Austin. El equipo determina que el servidor contiene suficientes puertos de correo de voz para funcionar con las ubicaciones de Seattle y Austin. Se ofrece preparación a los usuarios de Seattle, que migran a la mensajería unificada.
La arquitectura de Europa es mucho más fácil de diseñar. La infraestructura PBX está conectada en red y Exchange está centralizado. En Londres, se implementa un servidor Mensajería unificada y se migra cada uno de los sitios, el sitio más pequeño en primer lugar. La Figura 3 ilustra la arquitectura final.
Figura 3 Arquitectura de muestra tras la migración (haga clic en la imagen para ampliarla)

La importancia de seguir un plan
Muchas empresas me han pedido que resuelva sus migraciones de mensajería unificada con error. Muchas de estas organizaciones omitieron una o más de las reglas clave.
En primer lugar, recuerde siempre que no se trata simplemente de un sistema de correo de voz. Se trata de una aplicación crítica, y así debe ser tratada. Los usuarios dependen de las tecnologías de correo de voz para intercambiar información. Tenga presente que se trata de una aplicación de negocio y planee su migración para que tenga en cuenta todas las consideraciones expuestas en este artículo.
Debe implicar totalmente al equipo de telecomunicaciones en cualquier migración a la mensajería unificada. El equipo de telecomunicaciones cuenta con el mayor conocimiento de las aplicaciones de telefonía integradas en la infraestructura corporativa.
Al migrar a la mensajería unificada, tenga en cuenta la solución empresarial. Aunque, en un principio, simplemente estará implementando un único sitio, debe tener en cuenta siempre el resto de los sitios. Por ejemplo, la implementación de un sitio único sin proporcionar red de mensajes al resto de los sitios, repercutirá en la comunicación entre los usuarios. Esto, por supuesto, puede ser una tarea complicada, por lo que no dude en consultar con un especialista para diseñar una arquitectura que tenga en cuenta todas sus aplicaciones de TI.
Por último, no subestime la importancia del aprendizaje. La mensajería unificada introduce un cambio de paradigma en la manera en que los usuarios se comunican y usan el correo de voz. Lo que desde su punto de vista pueda parecer intuitivo, puede que no sea tan intuitivo para otros. Un buen aprendizaje es clave para dar lugar a una transición lo más fluida posible.

Jeff Goodwin es tecnólogo jefe en The VIA Group. Se ha especializado en el diseño y la implementación de Exchange y Mensajería unificada. Puede ponerse en contacto con él en la dirección jgoodwin@theviagroup.com.


Comunicaciones y colaboración
Descubra el modo en que la voz aumenta la eficacia de OCS 2007
Rajesh Ramanathan
De un vistazo:
  • Realización de llamadas con OCS 2007
  • Seguridad de las llamadas
  • Conversaciones multimodales con OCS
  • Integración de mensajería unificada de Exchange para el correo de voz

Contenido
Llamadas de voz básicas
Uso de números telefónicos
Llamadas seguras
Atravesamiento de NAT y firewalls
Enrutamiento en números telefónicos
Enrutamiento entrante
Informes de calidad y solución de problemas
Unificación del proceso
Comportamiento y conversaciones multimodales
Correo de voz
Conclusiones
La primera parte de esta serie acerca de Microsoft Office Communication Server (OCS) 2007 mostraba el modo en que se creó OCS a partir de los puntos fuertes de Live Communication Server (LCS) 2005. Su objetivo consiste en proporcionar
un servicio de mensajería instantánea (IM) y unas capacidades de presencia de clase empresarial de calidad superior, así como funciones telefónicas y de medios avanzadas (consulte el número de febrero de 2008 de TechNet Magazine en technet.microsoft.com/magazine/cc194409). En este artículo, profundizaremos en los aspectos de voz sobre IP (VoIP). Explicaré cómo se realizan llamadas de voz simples en el sistema OCS y trataré la tecnología capa a capa, para agregar cada componente junto con su funcionalidad correspondiente.
Tal y como señalé en el artículo anterior, se puede configurar OCS de diversos modos para proporcionar servicios telefónicos a los usuarios:
Enterprise Voice Esta es la solución completa de comunicaciones unificadas que usa OCS en conjunto con el servidor de Microsoft® Mediation, sin necesitad de una PBX. El servicio de mensajería unificada de Exchange (UM) proporciona en este sistema una serie de funciones de correo de voz. En el resto del artículo, llamaré a los usuarios que tengan este servicio "usuarios UC". También usaré el término "extremo UC" para referirme a los clientes que usen esta configuración.
Enterprise Voice con PBX integrada Esta configuración permite a los usuarios disfrutar de las ventajas de la comunicación unificada, a la vez que conservan los teléfonos PBX de sus escritorios. Admite la configuración en paralelo de OCS y PBX, para que las llamadas entrantes suenen de manera simultánea en los extremos de Office Communicator y PBX. La PBX aún se dedica al enrutamiento de llamadas y sigue proporcionando los servicios de correo de voz.
Control de llamadas remotas Esta función usa el teléfono PBX como principal y permite el control por parte del cliente de Office Communicator.

Llamadas de voz básicas
En este apartado, me centraré en el funcionamiento de los usuarios de Enterprise Voice. Las llamadas de voz sencillas se configuran en el sistema OCS mediante el mecanismo SIP INVITE, tal y como se describe en RFC 3261. El servidor de OCS desempeña el papel de un proxy semejante a un administrador de correo que transmite los mensajes entre los clientes (o extremos). Cada vez que un cliente crea una sesión en tiempo real, ya sea mediante una llamada o una sesión de mensajería instantánea, se origina un nuevo SIP INVITE. Si se reconoce el INVITE con una respuesta (es decir, si el extremo remoto envía una respuesta 200 OK), se establece la llamada (consulte la Figura 1).
Figura 1 Formato de INVITE y 200 OK.
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
En la Figura 2, Alice usa la llamada de Office Communicator (OC) 2007 para llamar a Bob. OC 2007 origina un INVITE para el SIP del identificador uniforme de recursos (o URI) de Bob (sip:bob@ejemplo.com). El INVITE lleva el descriptor de la sesión de audio (denominado SDP) de los extremos de medios en los que Alice puede recibir audio. OCS bifurca el INVITE a los extremos SIP registrados de Bob (por ejemplo, Communicator Phone Edition y el escritorio de Communicator). El INVITE contiene un encabezado From del sip:alice@ejemplo.com. Los extremos cliente de Bob usan este encabezado en una búsqueda de nombres inversa (RNL) para encontrar el nombre (Alice) que se mostrará en la notificación de la llamada entrante.
Figura 2 Enrutamiento de una llamada a varios extremos (haga clic en la imagen para ampliarla)
Para cada extremo, se muestra un URI de agente de usuario globalmente enrutable (GRUU). El GRUU se identifica únicamente con un extremo SIP y se obtiene durante el proceso de registro del servidor OCS. La dirección GRUU ayuda a enrutar los mensajes SIP. Por ejemplo, una vez que un extremo responde a una llamada, se puede realizar otra señalización SIP entre extremos para llevar a cabo otras operaciones durante la llamada. Para ello, se usa directamente la dirección GRUU.
La Figura 3 continúa el proceso en que Bob responde desde el escritorio de Communicator. El OC de Bob envía un mensaje 200 OK para informar del lugar donde puede recibir audio. En cuanto el proxy de OCS detecta que uno de los extremos ha respondido, cancela la llamada a los otros extremos de Communicator Phone Edition. Cuando la respuesta 200 OK llega al extremo del Communicator de Alice, ambos extremos del Communicator tienen suficiente información (puertos IP, parámetros de cifrado, etc.) para iniciar los medios.
Figura 3 Respuesta desde un extremo (haga clic en la imagen para ampliarla)

Uso de números telefónicos
Hasta este punto hemos visto que el usuario crea una invitación haciendo clic en Llamada de Communicator. El proceso varía un poco cuando el usuario selecciona o escribe un número telefónico:
  • En primer lugar, el cliente normaliza el número telefónico y lo representa como un URI de TEL, que describe los recursos que identifican los números telefónicos, tal y como se indica en RFC 3966.
  • Como el servidor de OCS sólo reconoce los URI de SIP, los clientes convierten el URI de TEL al URI de SIP correspondiente. Para ello, se agrega el sufijo del dominio y una etiqueta usuario=teléfono.
  • Si el número corresponde a un usuario interno, OCS transfiere la invitación directamente. Si el número es externo, la invitación se transfiere a la puerta de enlace SIP-RTC más cercana.
Para realizar llamadas a algunos números de redes telefónicas conmutadas (RTC), es necesario configurar la ruta de acceso a medios antes de que se responda a la llamada, con el fin de que puedan reproducirse los anuncios remotos o puedan recopilarse dígitos adicionales para completar la llamada. En este tipo de situaciones, la puerta de enlace RTC envía un indicador de progreso de la sesión 183 con un SDP de audio. Communicator usa esta información para configurar una ruta de acceso a medios bidireccional con un extremo de destino antes de que el usuario remoto responda a la llamada.
Una vez que se ha configurado la ruta de acceso a medios, Communicator habilita el teclado de multifrecuencia de tono dual o DTMF (marcado telefónico por tonos), para que el usuario pueda escribir los dígitos adicionales que necesite el sistema remoto. Todos los dígitos DTMF se envían a través de la ruta de acceso a medios como paquetes de RFC 2833. La puerta de enlace RTC se ocupa de generar los tonos DTMF apropiados en la RTC.
Tenga en cuenta que si Bob ha activado la opción de llamada simultánea en su teléfono móvil, el proxy de OCS enrutará la llamada a la puerta de enlace y llamará a la vez a los otros extremos del Communicator de Bob. En estas situaciones, el proxy de OCS indica que se ha activado la bifurcación en la respuesta del progreso de la sesión 183. Esto provoca que Communicator establezca un canal de medios sólo de recepción de datos en la puerta de enlace RTC.

Llamadas seguras
Una de las características principales de las llamadas de voz configuradas con OC consiste en cifrar los medios de forma predeterminada con el Protocolo seguro de transporte en tiempo real (SRTP), tal y como se define en RFC 3711. SRTP proporciona confidencialidad, autenticación de mensajes y protección de reproducción para el tráfico RTP. Durante la configuración de llamadas, los clientes negocian las capacidades de seguridad entre sí e intercambian claves criptográficas como parte del mecanismo INVITE.
La configuración de cifrado predeterminada para OC es de carácter opcional, lo que permite que dos extremos de OC configuren un canal de medios cifrado. Se puede ajustar este parámetro mediante el administrador para que cumpla con las necesidades de la organización. Por ejemplo, puede realizarse de un modo más estricto, obligando a que todas las llamadas estén cifradas, o se puede desactivar por completo.

Atravesamiento de NAT y firewalls
Los clientes del sistema OCS usan la tecnología del establecimiento interactivo de conectividad (ICE) con el fin de proporcionar conectividad de medios a aquellos usuarios que usen dispositivos y firewalls de traducción de direcciones de red (NAT). De este modo, no precisan que se realice ninguna modificación a los componentes NAT existentes. El Grupo de trabajo de ingeniería de Internet (IETF) se encuentra en estos momentos inmerso en un proceso de estandarización de la tecnología ICE. Cada cliente es consciente del servidor perimetral de audio/vídeo (A/V) que le atiende a través de un mecanismo de aprovisionamiento en banda. Asimismo, mantiene un vínculo autenticado con el servidor perimetral A/V durante el inicio de sesión.
Antes de realizar una llamada, el cliente ubica los recursos en las posibles ubicaciones de conectividad (direcciones y puertos, conocidos también como candidatos) en el servidor perimetral A/V (para la transmisión de medios), en la NAT o en el propio cliente host. Cuando se envía el protocolo de inicio de sesión (SIP) INVITE, se transfiere también la información acerca de la conectividad. La respuesta 200 OK transmite información candidata semejante acerca del interlocutor. Cuando los extremos obtienen una lista de candidatos a interlocutor, un mecanismo elaborado de clasificación y comprobación selecciona la mejor ruta entre ambos interlocutores en la que se garantiza que la transmisión de medios se realizará correctamente.

Enrutamiento en números telefónicos
El enrutamiento en números telefónicos introduce algunos aspectos más complejos en el mecanismo de llamada básico, debido a los siguientes factores:
  • Puede que las organizaciones tengan otros planes de marcado que se implementan internamente para la opción de marcado rápido.
  • Puede que se hayan almacenado los números en un formato no estándar (por ejemplo, es posible que los usuarios almacenen cadenas de siete dígitos en Microsoft Office Outlook®).
  • Puede que existan varias directivas asignadas a diversos números salientes. Por ejemplo, se puede bloquear el marcado de números internacionales para ciertos usuarios.
El sistema OCS precisa que los números telefónicos cumplan con el formato URI de TEL según RFC 3966 antes de que puedan enrutarse correctamente. Los números que no estén en este formato se convierten antes de que el cliente emita un INVITE. El diagrama de la Figura 4 muestra este proceso en el sistema OCS.
Figura 4 Enrutamiento de números telefónicos (haga clic en la imagen para ampliarla)
Los números que están disponibles para el cliente pueden provenir de diversas fuentes. Los números prenormalizados provienen del Servicio de libreta de direcciones (ABS), que puede tener reglas de normalización definidas por el administrador para convertir los números a un formato normalizado E.164. Cuando un cliente emite un SIP INVITE para el número normalizado, OCS aplica un proceso de traducción para asignar dicho número a cualquier usuario interno.
  • El paso 1 muestra que los números que entran en el sistema son de carácter único (normalizado según el plan de numeración E.164) o con un contexto telefónico que identifica la ubicación. Los números se envían al servidor como parte del SIP INVITE. OCS, por su parte, enruta el INVITE a un proceso de traducción.
  • El proceso de traducción (paso 2) intenta asignar el número telefónico a un extremo UC mediante una RNL del servidor. La traducción puede identificar una ruta para dicho número a un enrutamiento saliente o a un usuario UC. También puede hacer que la llamada fracase con un código 4xx si no se traduce el número correctamente.
  • Si se traduce el número para un número externo o ajeno a UC, se envía al componente del enrutamiento saliente, que, por su parte, redirige el INVITE a la puerta de enlace SIP-RTC correspondiente para continuar con su procesamiento. Esto se realiza después de aplicar las directivas para los números relacionados con el autor de la llamada (paso 3A). El enrutamiento saliente se ocupa de equilibrar la carga de llamadas en las diversas puertas de enlace. En caso de que sea necesario, también se ocupa de conmutar por error a otras puertas de enlace. Si el acceso a un número determinado está prohibido, el proceso de enrutamiento de salida puede hacer fracasar o rechazar la llamada y, a continuación, devolver un SIP con el código de respuesta 403. Tenga en cuenta que sólo se aplica el enrutamiento de salida cuando el autor de la llamada es un usuario UC. Si este no es el caso, OCS intentará usar las rutas estáticas hacia las puertas de enlace que se hayan configurado para el URI.
  • Si el número se traduce al de un usuario UC, el INVITE se enruta al URI del SIP de dicho usuario (paso 3B). El enrutamiento entrante es una función de OCS que sólo se aplica a los usuarios UC y a todas las llamadas dirigidas al URI del SIP. Como podrá observar, el enrutamiento entrante aplica las reglas relacionadas con el tiempo de espera de llamada, y con el desvío de llamadas y de correo de voz para el usuario UC.
Tenga en cuenta que el número resultante del proceso de normalización puede variar según la ubicación del cliente. Los administradores pueden configurar los perfiles de ubicación y asignar reglas de conversión de números específicas a las ubicaciones (como, por ejemplo, el modo en que funcionaría el marcado de cuatro dígitos en una ubicación determinada). A cada usuario UC se le asigna un perfil de ubicación. Del mismo modo, todos los clientes del sistema descargan las reglas específicas de su propio perfil de ubicación. Para ello, se usa el aprovisionamiento en banda. A continuación, entraré en los detalles del enrutamiento entrante.

Enrutamiento entrante
Las reglas del enrutamiento entrante determinan el modo en que debe enrutarse una llamada, tanto si hay clientes registrados en el sistema como si no. El componente del enrutamiento entrante también se ocupa de aplicar a las llamadas entrantes las reglas basadas en presencias. Por ejemplo, puede enviar las llamadas entrantes al correo de voz si el usuario ha establecido el estado de presencia en No molestar. El enrutamiento entrante es consciente de los niveles del contenedor de presencia, por lo que rechaza automáticamente las llamadas de aquellos usuarios que se encuentran en contenedores bloqueados. La Figura 5 muestra un resumen de las opciones que admite el componente del enrutamiento entrante de OCS.
Figura 5 Capacidades del enrutamiento entrante
Capacidad | Comentario
Duración del timbre | De forma predeterminada, la duración es de 20 segundos. Este valor se puede cambiar a 60 segundos como máximo. Una vez que transcurre la duración máxima del tiempo de espera, las llamadas se desvían al destino de las llamadas no respondidas.
Desvío de las llamadas no respondidas al correo de voz | Esta es la opción predeterminada si el usuario tiene habilitado el correo de voz. Las llamadas se desvían según las reglas del enrutamiento entrante.
Generación de notificaciones de llamadas perdidas cuando el autor de la llamada cuelga antes de que la llamada se desvíe al correo de voz. | Notifica estas llamadas perdidas al servicio de mensajería unificada de Exchange.
Bloqueo de llamadas | Rechaza las llamadas procedentes de usuarios bloqueados (sólo se pueden bloquear las llamadas de usuarios con identidades SIP).
No molestar | Las llamadas se desvían al correo de voz. Si el usuario se encuentra en este modo, no se llama a los destinos de llamada simultánea.
Permitir una lista de interrupción | Admite las llamadas si su autor se encuentra en el contenedor Equipo, incluso si el usuario se encuentra en el modo No molestar.
Llamadas simultáneas | Configura las llamadas entrantes para que llamen tanto a un número telefónico RTC como a clientes de Communicator y Communicator Phone Edition.
Desvío de llamada inmediato | Las llamadas entrantes se desvían inmediatamente a otro usuario, número telefónico RTC o correo de voz.
Llamadas desviadas no respondidas | Desvía una llamada no respondida a otro usuario, número telefónico RTC o correo de voz.
Horas de trabajo | Usa las horas de trabajo que están configuradas en el calendario de Outlook para activar los parámetros de desvío de llamadas de un usuario.
Las reglas de enrutamiento entrante deben cargarse al servidor como esquema XML, como parte de la información del aprovisionamiento automático de un usuario. La Figura 6 muestra el funcionamiento del enrutamiento entrante. Cualquier llamada a un usuario del sistema OCS llama al usuario predeterminado (que se muestra como "Yo"). Si no se responde a la llamada durante la duración del timbre, se envía la llamada no respondida al correo de voz de forma predeterminada. El usuario puede optar por modificar la configuración predeterminada, para lo que puede seleccionar el desvío inmediato a un número, a otra persona o directamente al correo de voz.
Figura 6 Enrutamiento de llamadas (durante las horas de trabajo) (haga clic en la imagen para ampliarla)
Cualquier llamada que se desvíe inmediatamente a otra persona o a otro número provocará la activación de las reglas de enrutamiento entrante para dicha persona o número. El usuario también puede configurar las llamadas no respondidas para que se desvíen a otro número o a otra persona.
Si el usuario activa la opción Aplicar solamente durante mis horas de trabajo en Outlook en las reglas de desvío, se aplicarán las reglas de la Figura 6 durante las horas de trabajo. Fuera de estas horas, se aplicará el comportamiento predeterminado de llamada a extremos registrados. Tenga en cuenta que este comportamiento precisa que la organización haya implementado los clientes Microsoft Exchange Server 2007 y Outlook 2007, ya que Communicator toma la información de las horas de trabajo del servicio web de disponibilidad de Exchange 2007 y aprovecha la capacidad de detección automática de Outlook 2007 para obtener la ubicación del servidor.

Informes de calidad y solución de problemas
Es esencial que se realicen supervisiones aunque los clientes del sistema OCS 2007 usen RTAudio, un códec de audio de última generación que tolera condiciones de red imperfectas, como la vibración, la pérdida de paquetes, etc. De este modo, los administradores podrán localizar y corregir posibles condiciones problemáticas frecuentes. Al final de cada llamada, los clientes del sistema OCS 2007 elaboran un informe que envían a un servidor central de calidad de la experiencia (QoE). Este trata de la calidad y proporciona estadísticas detalladas del ancho de banda, de la pérdida, la vibración, la puntuación de opinión media (una medida de la percepción del usuario) y los dispositivos usados, entre otros aspectos. Para ello, se envía la carga al servidor QoE en una solicitud SIP SERVICE, cuya dirección se programa mediante el mecanismo de aprovisionamiento en banda.
Tenga en cuenta que todos los extremos cliente envían sus informes de calidad de las llamadas al servidor QoE de manera independiente. En caso de producirse el fracaso de llamadas debido a errores de marcado, los clientes también envían un informe a OCS, lo que proporciona un repositorio de todos los errores que han creado los clientes.﻿

Unificación del proceso
Ahora que hemos tratado los diversos aspectos de la configuración de una llamada (incluido el marcado de números, el enrutamiento entrante y saliente, y las comprobaciones de la conectividad), echemos un vistazo al proceso en conjunto. La Figura 7 resume lo que ocurre desde el momento en que un usuario realiza una llamada. Los clientes del sistema OCS desempeñan un papel decisivo a la hora de configurar una llamada. Del mismo modo, ellos son los que administran por completo el proceso de configuración de la llamada. OCS se implica en el enrutamiento inicial de la llamada, mientras que los servidores perimetrales ayudan a los clientes a encontrar la ruta de medios óptima. Veamos ahora el siguiente paso: la conversación.
Figura 7 Flujo de llamada de extremo a extremo (haga clic en la imagen para ampliarla)

Comportamiento y conversaciones multimodales
El concepto de las conversaciones es clave en el sistema OCS. Una conversación consiste en una sesión multimodal entre dos o más personas que puede incluir voz, vídeo y un servicio de mensajería instantánea al mismo tiempo. También puede incluir artefactos para la transferencia de archivos durante la sesión, correo electrónico mediante Outlook o notas almacenadas en Microsoft Office OneNote®.
Hay varios aspectos de las conversaciones que pueden tener un impacto en el diseño de los sistemas cliente de OCS:
  • Todas las modalidades implicadas en una conversación usan la misma ventana. Si se agrega un mensaje instantáneo a una conversación de audio, se asocia a la misma ventana.
  • Las conversaciones pueden desarrollarse en varios dispositivos. Los usuarios pueden optar por tener audio en Communicator Phone Edition pero hacer uso de mensajes instantáneos en el escritorio de Communicator.
  • Todos los modos se concentran en una conferencia: si tiene lugar esta concentración, todas las modalidades de conversación deben llevarla a cabo conjuntamente, independientemente del dispositivo en que esté activada la modalidad. Por ejemplo, si para la misma conversación están disponibles un modo de audio en Communicator Phone Edition y un modo de mensajería instantánea en el escritorio de Communicator, la escalada a la conferencia garantiza que tanto el audio como la mensajería instantánea tienen el mismo grupo de participantes para la conversación.
  • Se registran las conversaciones, no las sesiones individuales. Los registros de llamada incluyen toda la información acerca de la conversación, incluidos detalles sobre las notas que se han tomado, los intercambios de mensajes instantáneos, la duración del audio, etc. Esto proporciona a los usuarios una visión bastante útil y consolidada de la conversación completa cuando abren el registro de llamada en Outlook.
  • Las conversaciones pueden continuar a partir de los registros de llamada. Los clientes de OCS unifican conversaciones mediante un identificador de conversación (un número que identifica una conversación de forma exclusiva en los diferentes dispositivos y aplicaciones). Existe un mecanismo bastante elaborado para computar diferencias de conversaciones cuando comienza una nueva conversación a partir del registro de una conversación anterior. El identificador de la conversación también se almacena como identificador del correo electrónico en Outlook.
El identificador de la conversación se transfiere como propiedad personalizada de SIP INVITE, Ms-Conversation-Id. La Figura 8 muestra una transacción de este tipo, en la que primero se agregó la voz, seguida de la mensajería instantánea. Vea cómo, al final de la conversación multimodal, el registro que se almacena en Outlook tiene el mismo identificador que la conversación.
Figura 8 Conversaciones multimodales e identificador de la conversación (haga clic en la imagen para ampliarla)

La mensajería unificada de Exchange es el sistema de correo de voz para OCS 2007. OCS sólo enrutará llamadas a los usuarios que estén habilitados por UC para el servicio de mensajería unificada de Exchange. OCS proporciona diversas características para la integración con la mensajería unificada de Exchange:
  • La opción Llamar al correo de voz desde la UI del teléfono de Communicator (consulte la Figura 9) permite al usuario administrar el correo de mensajería unificada, modificar los saludos, etc. sin necesidad de escribir el NIP, ya que el usuario se ha autenticado previamente.
  • El indicador de espera de mensaje en la UI de Communicator (consulte la Figura 10) permite al usuario abrir la carpeta del correo de voz en Outlook mientras en Communicator Phone Edition se reproducen los mensajes de voz de dicha carpeta directamente en el teléfono.
  • Las llamadas se pueden desviar directamente al correo de voz desde la UI de Communicator.
  • Las llamadas rechazadas se desvían directamente al correo de voz.
  • El elemento Reproducir en el teléfono, del correo de voz de Outlook, llama directamente a los clientes de Office Communicator.
Figura 9 Opción Llamar al correo de voz en Communicator
Figura 10 Indicador de espera de mensaje en Communicator
El mecanismo que usa OC para recibir las notificaciones del correo de voz no se parece al de Communicator Phone Edition. OC registra las notificaciones de correo nuevas en la carpeta de búsqueda del correo de voz de Outlook. Los mensajes nuevos se registran en esta carpeta. Communicator también usa los registros de llamadas y conversaciones perdidas.

Conclusión
En este artículo, he tratado el funcionamiento de las llamadas de voz en OCS 2007, un sistema creado a partir de SIP que aprovecha bastantes RFC. Los extremos cliente desempeñan un papel muy importante a la hora de administrar las llamadas en OCS. De forma predeterminada, todas las llamadas de voz están protegidas mediante cifrado. OCS proporciona componentes flexibles para permitir la administración de números y el flujo asociado en el sistema.
Las conversaciones, que implican el uso de voz, mensajería instantánea y vídeo, constituyen un concepto principal de OCS. OCS se integra con la mensajería unificada de Exchange y permite que se informe a los extremos de Communicator sobre los mensajes de correo de voz recibidos. Además, permite el acceso al correo de voz mediante Outlook o directamente desde el servidor.

Rajesh Ramanathan ha trabajado en el sector de las comunicaciones durante 14 años, y ha diseñado protocolos de voz, experiencias de usuario y conferencias de voz para Office Communicator 2007. Actualmente, se encarga de la administración de programas en el equipo de Office Communicator en Microsoft. Puede ponerse en contacto con él en la dirección rajeshra@microsoft.com.


Comunicaciones y colaboración
Creación de conexiones eficaces con Groove y SharePoint
Alan Maddison
De un vistazo:
  • Creación de una biblioteca de documentos de SharePoint
  • Creación de un área de trabajo de Groove
  • Sincronización de Groove y SharePoint
  • Permiso de acceso al área de trabajo

Contenido
Unión de Groove y SharePoint
Introducción
Configuración del control de aprobación
Creación del área de trabajo de Groove
Sincronización de Groove y SharePoint
Permiso de acceso al área de trabajo
Conclusiones
A menudo, los profesionales de TI se preguntan acerca de la aparente semejanza entre Microsoft Office Groove 2007 (Groove) y Microsoft Office SharePoint Server 2007 (SharePoint). No están muy seguros de
cuándo debe utilizarse cada uno de ellos. A primera vista, ambos productos parecen muy similares, ya que los dos proporcionan capacidades de colaboración. Sin embargo, en cuanto se profundiza en su arquitectura, se comienzan a apreciar las diferencias.
Sharepoint® ofrece un marco estable y escalable de administración de contenidos, así como un conjunto de herramientas de colaboración compatibles con flujos de trabajo estructurados. Groove™, en cambio, es un conjunto de herramientas de colaboración que permiten una rápida implementación del área de trabajo con muy poca o ninguna carga de TI. Groove proporciona un marco ideal para una colaboración ad hoc dinámica y segura, ya que, entre sus varias características, admite la colaboración en documentos, discusiones encadenadas y calendarios. En resumen, la mayoría de los usuarios acabarán usando estos productos de modos diferentes.
Además, con la publicación de Groove 2007, se agrega compatibilidad para integrar SharePoint mediante la herramienta Archivos de SharePoint. Esta herramienta permite que las áreas de trabajo de Groove se sincronicen con las bibliotecas de documentos de SharePoint. Además, la compatibilidad integrada implica mayor facilidad para sacar el máximo partido a ambos productos. De hecho, la combinación de la naturaleza dinámica y flexible de Groove con la sofisticación y la eficacia de SharePoint beneficiará de forma significativa a muchas personas.
Unión de Groove y SharePoint
El mundo actual de la TI exige una mayor colaboración entre las organizaciones y sus socios y proveedores. Sin embargo, las soluciones de colaboración eficaces que se están implementando con productos como SharePoint, suelen centrarse sobre todo en los equipos internos y en la necesidad de aumentar la disponibilidad de la información dentro de la organización. En estos casos, los desafíos relacionados con la capacidad de permitir el acceso de usuarios externos a una organización, tanto desde un punto de vista administrativo como de seguridad, suelen ser significativos. Ante estos desafíos, el objetivo principal es permitir que los usuarios puedan hacerse llegar a los socios externos cuando sea necesario.
La combinación de Groove y SharePoint proporciona exactamente esta solución. SharePoint proporciona un marco de colaboración interna, búsquedas de contenido y de flujo de trabajo. Al adoptar Groove, se permite a las empresas que amplíen estas capacidades para incluir una sencilla colaboración entre organizaciones. Gracias a Groove, los usuarios pueden configurar rápidamente áreas de trabajo colaborativas que van más allá de las fronteras de la propia empresa. Además, al ser compatible con las claves simétricas del estándar de cifrado avanzado (AES) de 192 bits, se garantiza la seguridad de esta colaboración. De hecho, la seguridad de Groove está integrada y continuamente activa, por lo que los usuarios no se tendrán que preocupar de configurarla.
La arquitectura de seguridad de Groove proporciona una protección de alto nivel para las áreas de trabajo y su contenido, durante el almacenamiento local y durante la transmisión a través de la red. La herramienta Archivos de SharePoint permite que la información se sincronice bidireccionalmente con una biblioteca de documentos de SharePoint con el fin de garantizar que la información está centralmente disponible para que el acceso interno sea más sencillo. Veamos unos ejemplos concretos para observar el funcionamiento de este proceso.
Introducción
Las organizaciones suelen trabajar con diversas empresas durante las actividades empresariales del día a día. Esto no implica únicamente a las organizaciones externas, sino también a personas de otros departamentos con los que no se suele trabajar, por ejemplo, el departamento financiero, jurídico o de comunicaciones corporativas. De este modo, las organizaciones precisan crear un equipo interno ad hoc que colabore y facilite el producto de esta colaboración a aquellos que no están implicados en el proceso de colaboración pero que deben tener acceso a los resultados del mismo. Con SharePoint y Groove, es muy fácil alcanzar estos objetivos.
Si aún no tiene una biblioteca de documentos de SharePoint con la que sincronizar el área de trabajo de Groove, el primer paso es crear una. Para ello, conéctese a SharePoint y, a continuación, seleccione el vínculo Ver todo el contenido. Cuando se haya cargado esta página, seleccione Crear y, a continuación, tal y como se muestra en la Figura 1, seleccione Biblioteca de documentos en la columna Bibliotecas.
Figura 1 Creación de una biblioteca de documentos de SharePoint (haga clic en la imagen para ampliarla)
Hay varios parámetros que se deben configurar en la página de la nueva biblioteca de documentos: el nombre y la descripción de la biblioteca, si se incluirá en la sección de Vínculos rápidos, si se permitirá el control de versiones y cuál será el formato predeterminado de los documentos nuevos que se creen directamente en la biblioteca. La opción Historial de versiones de documentos está deshabilitada de forma predeterminada, pero sería conveniente que la activara si el control de versiones es apropiado para su entorno. También debería tener en cuenta algunas de las funciones avanzadas que están disponibles en SharePoint y que puede usar como parte de la implementación de Groove y SharePoint. Esta funcionalidad mejorada incluye:
  • Historial de versiones
  • Control de aprobación
  • Procedimientos de desproteccción
  • Control del flujo de trabajo
  • Directivas de retención de documentos
  • Auditorías
  • Really Simple Syndication (RSS)
Estas funciones adicionales, disponibles a través de SharePoint, pueden proporcionar un valor increíble al trabajar con Groove. En mi ejemplo, esta funcionalidad adicional (concretamente, el control de aprobación) resultará muy útil. Por ejemplo, supongamos que los miembros de un equipo colaboran en Groove para crear el borrador de un documento. Cuando el borrador final esté listo para la revisión, se puede sincronizar con SharePoint y, a continuación, someterse al proceso de aprobación.

Configuración del control de aprobación
Para configurar esta funcionalidad, debemos seleccionar el menú Configuración de la biblioteca de documentos y, a continuación, elegir el elemento de configuración. Esto permite ver todas las opciones de configuración y personalización. Para configurar la aprobación, seleccione el vínculo de configuración del flujo de trabajo en la sección Permisos y administración para que aparezca la página Agregar un flujo de trabajo. Ahora, seleccione la plantilla del flujo de trabajo, que, en nuestro ejemplo, será la plantilla de aprobación. A continuación, escriba un nombre para el flujo de trabajo. Luego debe decidir si va a usar una lista de tareas existente o va a crear una nueva. Una nueva lista de tareas ofrece una mayor confidencialidad, pero como no tiene relevancia en nuestro ejemplo, seleccione la predeterminada.
Después de elegir la lista de tareas, deberá decidir cómo comenzará el proceso de aprobación. Seleccionemos un proceso manual y proporcionemos los permisos correctos a todos los usuarios autenticados para iniciar el proceso. Otras opciones permiten automatizar el proceso según el control de versiones, si está habilitado en la biblioteca de documentos o cada vez que se agregue un nuevo documento o se modifique uno ya existente.
Después de hacer clic en Siguiente para aceptar estas opciones de configuración, deberá especificar más información de configuración para finalizar. La primera opción que debe configurar es el modo en que deben asignarse las tareas. Como es posible que varias personas participen en el proceso de aprobación, puede asignar los aprobadores en serie (de forma que una persona apruebe un elemento y luego se pase a la siguiente persona) o en paralelo (de modo que cualquiera pueda aprobarlo en cualquier momento). Entonces, debe decidir si los aprobadores podrán asignar tareas a otras personas y si podrán solicitar cambios antes de que se complete la tarea.
El paso siguiente consiste en seleccionar a los propios aprobadores y, a continuación, decidir cuándo se deberá completar la tarea. Por último, debe decidir cuándo se completará el flujo de trabajo. La opción predeterminada indica que el flujo de trabajo estará completado cuando se terminen las tareas. La última opción de configuración consiste en especificar si se actualiza el estado de la aprobación al completar el flujo de trabajo. Una vez que haga clic en el botón Aceptar, se habrá creado el proceso de aprobación y podrá comenzar el proceso de aprobación de documentos.

Creación del área de trabajo de Groove
Una vez que haya creado la biblioteca de documentos de SharePoint, el siguiente paso consiste en crear un área de trabajo de Groove. Para ello, asegúrese primero de que tiene una cuenta de Groove y, como mínimo, una identidad. Las identidades conforman la base de la presencia y de la comunicación en Groove. Se puede asociar cada cuenta de Groove con varias identidades, y cada identidad se asocia a un único archivo de contactos, con el fin de que pueda personalizar su información de contacto para cada identidad que use. También puede exportar su cuenta de Groove y sus identidades asociadas para usarlas en varios equipos.
Una vez que haya creado una cuenta y una identidad, abra la barra de inicio de Groove; para ello, haga doble clic en el icono de Groove de la bandeja del sistema. Haga clic en la opción Nueva área de trabajo, escriba un nombre apropiado para el área de trabajo y, a continuación, seleccione el tipo estándar. El área de trabajo estándar de Groove facilita la presencia, las alertas y la asignación de funciones para los miembros del área de trabajo. Cuando haga clic en Aceptar, Groove creará el área de trabajo y la abrirá. La Figura 2 muestra una nueva área de trabajo con algunos archivos incluidos en la herramienta Archivos. En este momento, el área de trabajo ya es funcional y puede configurar alertas o agregar herramientas.
Figura 2 Nueva área de trabajo de Groove (haga clic en la imagen para ampliarla)
Las alertas se pueden configurar en la propia herramienta, en el área de trabajo o al nivel de archivos individuales. Los cuatro niveles de alerta son ninguna, media, alta y automática. Una alerta media resalta el contenido nuevo; una alerta alta o automática reproducirá un archivo de audio. También puede configurar las alertas para que le envíen una notificación cuando un usuario entre en un área de trabajo determinada. Para configurar las alertas, seleccione Configurar alertas en el menú Opciones. Las alertas de los archivos individuales se configuran en las propiedades de cada archivo. Para ello, haga clic con el botón secundario en un archivo del área de trabajo y, a continuación, seleccione Propiedades.
Además de la herramienta de archivos para la colaboración en documentos y la herramienta de discusión para las discusiones en subprocesos que forman parte del área de trabajo estándar predeterminada, existen muchas más herramientas, entre las que se incluyen Calendario, Formularios, Seguimiento de asuntos, Reuniones, Bloc y, por supuesto, la herramienta Archivos de SharePoint. Cada una de ellas proporciona una funcionalidad colaborativa adicional de gran valor. Si desea agregar una herramienta, seleccione el botón Agregar una herramienta a esta área de trabajo, que se encuentra en la zona inferior derecha del área de trabajo. A continuación, seleccione la herramienta que desea agregar, tal y como se muestra en la Figura 3. También se puede eliminar una herramienta fácilmente en cualquier momento.
Figura 3 Adición de una herramienta al área de trabajo de Groove (haga clic en la imagen para ampliarla)

Sincronización de Groove y SharePoint
Después de agregar la herramienta Archivos de SharePoint, debe configurar la dirección URL del sitio de SharePoint que contiene la biblioteca de documentos con la que se desea sincronizar. Para ello, seleccione la ficha Archivos de SharePoint en la zona inferior de la pantalla del área de trabajo y simplemente haga clic en el botón de configuración en el área de trabajo de Groove, como vemos en la Figura 4.
Figura 4 Configuración de la herramienta Archivos de SharePoint (haga clic en la imagen para ampliarla)
Cuando haya escrito la dirección URL, obtendrá una lista de todas las bibliotecas disponibles en este sitio de SharePoint. Tal y como se muestra en la Figura 5, seleccione a continuación la biblioteca que desea usar. Groove se conectará e iniciará la sincronización automática. Esto quiere decir que todos los documentos que se encuentren en este momento en la biblioteca de SharePoint se descargarán al área de trabajo de Groove y estarán disponibles automáticamente. La Figura 6 muestra un ejemplo.
Figura 5 Después de establecer la dirección URL, sus bibliotecas de SharePoint estarán disponibles en Groove (haga clic en la imagen para ampliarla)
Figura 6 Sincronización de Groove y SharePoint (haga clic en la imagen para ampliarla)
Como se acaban de descargar, los documentos aparecen como no leídos en el área de trabajo de Groove. Tenga en cuenta que todos los archivos que estén sincronizados con SharePoint pueden aprovechar la función de proteger o desproteger de SharePoint. Además, al desproteger un archivo, se garantiza que ningún otro usuario pueda modificar un documento durante la edición por su parte.
También conviene recordar que la herramienta Archivos de SharePoint proporciona una sincronización bidireccional, por lo que si usa Groove para agregar archivos a la herramienta Archivos de SharePoint, se sincronizarán con la biblioteca de documentos de SharePoint. Aunque la sincronización predeterminada está configurada para que se realice automáticamente, puede iniciarla manualmente con el botón Sincronizar ahora. Si lo hace, verá un resumen de los cambios realizados en cualquier archivo que deba sincronizarse y una acción asociada: obtener (de SharePoint) o enviar (a SharePoint), tal y como se muestra en la Figura 7.
Figura 7 Después de una sincronización manual, verá un resumen de las modificaciones (haga clic en la imagen para ampliarla)
Otra cosa que conviene recordar es que la herramienta de archivos que se implementa como parte del área de trabajo estándar de Groove es diferente a la herramienta Archivos de SharePoint. La herramienta Archivos de Groove no se sincroniza con SharePoint y, según lo que necesite, puede eliminarse. Sin embargo, como no se sincroniza con SharePoint, se puede usar como una ubicación de almacenamiento de los archivos temporales a los que el equipo necesite obtener acceso durante el desarrollo de un proyecto. Los archivos almacenados allí mantendrán la sincronización entre los miembros del área de trabajo.

Permiso de acceso al área de trabajo
Ahora que se ha implementado la infraestructura básica de colaboración, puede comenzar a permitir el acceso a los usuarios al área de trabajo. Sin embargo, en primer lugar, deberá invitarlos, algo que puede hacer a través del correo electrónico o con el servicio de mensajería instantánea de Groove. De forma alternativa, Groove permite exportar la invitación a un archivo. Este archivo, con la extensión .grv, está asociado de forma predeterminada a la aplicación de Groove y se puede enviar de maneras diferentes, por ejemplo, puede colocarlo en un sitio web para que el destinatario descargue la invitación.
El servicio de mensajería instantánea de Groove incluye controles de seguridad para garantizar que el destinatario es el único que puede leer la invitación. Al enviar una invitación por correo electrónico o mediante un archivo de invitación, asegúrese de que ha activado la opción Requerir confirmación de aceptación. De este modo, podrá comprobar que la persona que se une al área de trabajo es la persona a la que ha invitado. Esto agrega un nivel adicional de seguridad al área de trabajo. Tenga en cuenta que también puede cancelar las invitaciones pendientes.
Al invitar a usuarios al área de trabajo, debe seleccionar una función para cada destinatario. Entre las funciones, se incluyen Administrador, Participante e Invitado. De manera predeterminada, se asigna la función de Participante. Cada función tiene unos derechos determinados en el área de trabajo y, como norma general, conviene que restrinja la función de Administrador únicamente a aquellas personas que necesiten realmente todos los derechos del área de trabajo como, por ejemplo, la capacidad de eliminar herramientas. Los creadores del área de trabajo obtienen la función de Administrador de forma predeterminada. Asimismo, es posible modificar las funciones asignadas en cualquier momento.
Dada la naturaleza ad hoc del proyecto de este artículo, la última tarea consistiría en eliminar el área de trabajo de Groove una vez que se haya completado todo el proceso. En cuanto se haya asegurado de que ha sincronizado el área de trabajo con la biblioteca de SharePoint, abra el área de trabajo, vaya al menú Archivo y seleccione Eliminar área de trabajo. A continuación, deberá elegir entre eliminarla del propio equipo o para todos los miembros. Todos los usuarios obtienen una copia del área de trabajo en su equipo, que se mantiene indefinidamente a menos que la elimine para todos los miembros.
La culminación del proyecto permite aprovechar la naturaleza complementaria de Groove y SharePoint. Cuando haya finalizado la sincronización de documentos, es el momento ideal para aprovechar los parámetros de la Directiva de administración de la información de SharePoint. Concretamente, es posible habilitar la expiración de los datos para proporcionar un método con el que administrar automáticamente los datos archivados.
La habilitación de la expiración permite determinar un período de tiempo durante el cual se deben conservar los datos. Una vez que acabe este período de conservación, SharePoint podrá eliminar automáticamente los datos o iniciar un proceso de flujo de trabajo. Esta funcionalidad proporciona un buen modo de integrar los datos de Groove en la directiva de administración del ciclo de vida de la información de su compañía. Puede configurar la directiva de conservación de datos en cualquier momento. De hecho, si no lo hizo al configurar la biblioteca al principio, puede hacerlo ahora.
Para habilitar la expiración, seleccione el menú Configuración de la biblioteca de documentos y, a continuación, seleccione el elemento del menú de configuración de la biblioteca de documentos. Entonces, podrá ver la opción de menú Configuración de la directiva de administración de la información en la sección Permisos y administración. Cuando haya hecho clic en el vínculo de configuración de la directiva de administración de la información, podrá definir una nueva directiva personalizada o habilitar la biblioteca de documentos para que use la directiva definida en el nivel de sitio.
Tenga en cuenta que si define una directiva personalizada, deberá especificar información de configuración. Por lo tanto, en mi ejemplo, habilitaría la expiración y, a continuación, seleccionaría un período de conservación y una acción que se deberá llevar a cabo una vez que finalice este período.
Groove es un cliente de colaboración bastante completo que se diseñó con el fin de proporcionar un marco dinámico, intuitivo y seguro para la colaboración ad hoc. Gracias a su amplio conjunto de herramientas, Groove proporciona una plataforma colaborativa ligera y adaptable que se puede usar fácilmente en una o varias organizaciones.
Si SharePoint ya proporciona un conjunto de herramientas colaborativas y un marco de administración de contenido estables y eficaces, se dará cuenta de que la combinación con Groove ofrece una solución más que atractiva. Ambos productos se complementan a la perfección y, al usarse conjuntamente, aumenta de manera significativa la productividad de los equipos colaborativos.﻿

Alan Maddison es consultor senior de Strategic Business Systems, una división de Brocade.


Administración de Windows
Introducción a Windows Server 2008 Failover Clustering
Chuck Timon
De un vistazo:
  • Complemento Administración del clúster de conmutación por error
  • Nuevas características y mejoras
  • Funciones de copia de seguridad y restauración
  • Migración desde Windows Server 2003

Contenido
Nueva interfaz de administración
Procesos de configuración mejorados
Procedimiento de validación incrustado
Nuevo modelo de quórum
Características de seguridad mejoradas
Ampliación de la funcionalidad de red
Aumento de la confiabilidad al interactuar con el almacenamiento
Procesos de recuperación integrados
Nuevas funciones de copia de seguridad y restauración
Migración desde los clústeres de Windows Server 2003
Desde que se incluyó por primera vez la tecnología de clústeres en Windows NT 4.0 Enterprise Edition, los usuarios se han quejado de lo difícil que es configurarlos, y más aún mantenerlos. Para administrar un clúster,
es necesario que el administrador tenga algo más que un conocimiento general de la propia pieza de clúster. Además, debe conocer en profundidad las tecnologías de almacenamiento y el modo en que el servicio de clúster interactúa con una serie de soluciones de almacenamiento. Muchas organizaciones tienen problemas a la hora de conseguir el conjunto de habilidades necesarias para poner en funcionamiento una solución de alta disponibilidad, además de mantenerla.
La tecnología de clústeres ha mejorado a lo largo de los años, pero aún dejaba mucho que desear cuando Microsoft comenzó a trabajar en Windows Server® 2008. Por este motivo, el equipo comenzó a rediseñarla con el único objetivo de simplificarla. En Windows Server 2008, le han hecho un lavado de cara a los Servicios de Cluster Server de Microsoft® (MSCS), y ahora se conocen como Failover Clustering.
Esto no quiere decir que lo único que tiene que aportar la nueva implementación de Failover Clustering sea simplicidad. A lo largo de los años, Microsoft ha aprendido bastantes lecciones, ya que las organizaciones han proporcionado comentarios bastante valiosos acerca de lo que les gustaría ver en una solución de clústeres. La nueva funcionalidad de Failover Clustering trata la mayoría de los problemas más importantes y, asimismo, ofrecen algunas características nuevas e interesantes que lo convierten en una proposición muy atractiva. En este artículo, por lo tanto, me gustaría presentarle algunas de las nuevas e increíbles características de Windows Server 2008 Failover Clustering.

Nueva interfaz de administración
Después de instalar Failover Clustering, podrá obtener acceso a la interfaz de administración a través de las herramientas administrativas o con Cluadmin.msc. El complemento Administración del clúster de conmutación por error, al igual que otras interfaces de administración en Windows Server 2008, es una consola de Microsoft Management Console (MMC) 3.0. Aquellas personas que tengan experiencia con los clústeres se sentirán bastante desorientados la primera vez que abran el complemento Administración del clúster de conmutación por error.
La nueva interfaz se divide en tres paneles distintos, tal y como se muestra en la Figura 1. El panel izquierdo enumera todas las copias de Windows Server 2008 Failover Clustering que se encuentran en la organización. El panel central ofrece los detalles de la configuración de la sección del clúster que se haya seleccionado en el panel izquierdo. Por otro lado, el panel derecho muestra las acciones que se pueden ejecutar.
Figura 1 Complemento Administración del clúster de conmutación por error (haga clic en la imagen para ampliarla)
Supongamos, por ejemplo, que ha seleccionado Almacenamiento en el panel izquierdo. En el panel central, aparecerán los detalles del almacenamiento proporcionado por el clúster, así como su disponibilidad, en caso de que la hubiera. Como puede observar en la Figura 1, el clúster contiene una porción de almacenamiento compatible con un disco testigo, almacenamiento destinado a un servidor de archivos y algo de almacenamiento disponible. El panel derecho enumera acciones relevantes, como la de agregar más capacidad de almacenamiento. Tenga en cuenta que no se puede usar el complemento Administración del clúster de conmutación por error para administrar las versiones anteriores del Servicio de Microsoft Cluster Service.

Procesos de configuración mejorados
La configuración de un clúster de conmutación por error es bastante sencilla. La mayoría de las acciones para configurar, volver a configurar y mantener un clúster están respaldadas por asistentes. Gracias a ellos, el administrador ya no necesita preocuparse de si los recursos se han configurado correctamente o si aparecerán en línea en el orden correcto.
La Figura 2 muestra el asistente para alta disponibilidad. En este ejemplo en particular, se ha configurado un servidor de archivos. A la izquierda, podrá ver una lista de los pasos por los que el asistente guía al administrador. Una vez que se completa el proceso, se muestra una página de resumen y es posible ver un informe del mismo.
Figura 2 Asistente para alta disponibilidad (haga clic en la imagen para ampliarla)

Procedimiento de validación incrustado
En las versiones anteriores de Windows Server, si se deseaba el tratamiento de una configuración de hardware como solución de clúster admitida, debía enumerarse como solución de clúster en el Catálogo de Windows Server. Esto incluía los clústeres de varios sitios, que se enumeraban independientemente bajo la categoría Geográficamente dispersos. Para aparecer en el catálogo, los proveedores de hardware debían realizar una serie de pruebas del laboratorio de calidad de hardware de Windows (WHQL) y, a continuación, enviar los resultados a Microsoft. Esto era bastante costoso para los proveedores, por lo que el mantenimiento de la base de datos del Catálogo de Windows Server era una tarea complicada.
En Windows Server 2008, se incluye un proceso de validación integrado en Failover Clustering. Este proceso consiste en una serie de pruebas que se agrupan en cuatro categorías principales, tal y como se muestra en la Figura 3.
Figura 3 Categorías de la prueba de validación del clúster de conmutación por error (haga clic en la imagen para ampliarla)
Puede observar que se ha ampliado la categoría Red para mostrar las pruebas que se están ejecutando. Cada categoría, por su parte, contiene un grupo de pruebas. La categoría Almacenamiento, que es probablemente la más importante de las cuatro, incluye pruebas para garantizar que las soluciones de almacenamiento cumplen con los nuevos requisitos de Windows Server 2008 Failover Clustering.
Concretamente, los proveedores de hardware deben usar controladores basados en el propio controlador de Microsoft Storport, por lo que deben ser compatibles con las reservas persistentes de SCSI-3. Asimismo, cuando se use un módulo específico de dispositivo de múltiples rutas, este deberá estar basado en el estándar E/S de múltiples rutas de Microsoft.
Gracias a la inclusión del proceso de validación, el modelo de compatibilidad ha cambiado. Todos los tipos de hardware deben presentar el logotipo de Windows Server 2008 y deben pasar todas las pruebas de validación. Las únicas excepciones son los clústeres de varios sitios que tienen dos espacios de almacenamiento independientes y distintos (uno en cada lado), y la implementación de la replicación continua en clúster de Exchange Server 2007, ya que no tiene ninguna capacidad de almacenamiento compartido.

Nuevo modelo de quórum
También se ha cambiado el modelo de quórum en Windows Server 2008 Failover Clustering. En los sistemas antiguos, cuando un administrador oía la palabra quórum, se le venía a la cabeza un disco compartido que incluía la configuración del clúster y algunos archivos replicados. Este era el único punto de posibles errores del clúster. Si el disco de quórum producía errores, finalizaba el servicio del clúster y, por lo tanto, se perdía la alta disponibilidad.
Los clústeres de Windows Server 2003 proporcionaban un segundo tipo de quórum conocido como Conjunto de nodos mayoritario. Este tipo de quórum solía implementarse en los clústeres de varios sitios y no precisaba un almacenamiento compartido. El quórum Conjunto de nodos mayoritario consistía en un archivo compartido que se ubicaba en la unidad del sistema de cada nodo del clúster. Las conexiones a este quórum se realizaban mediante conexiones de bloque de mensajes del servidor (SMB). Una vez más, para que funcionara el clúster, era necesario que participaran la mayoría de los nodos.
Posteriormente, con la replicación continua en clúster (CCR) de Exchange Server 2007, se agregó a los clústeres de Windows Server 2003 la capacidad de testigo del recurso compartido de archivos (FSW). Esto permitía que un único nodo de clúster CRR de Exchange 2007 (o cualquier clúster de varios sitios) siguiera proporcionando servicios. Sólo era necesario que se alcanzara la mayoría mediante la conexión al FSW.
En Windows Server 2008 Failover Clustering, el concepto de quórum ahora equivale al de consenso. El quórum, o consenso, se alcanza mediante la obtención de los votos suficientes para poner en servicio el clúster. Estos votos se pueden obtener de diversos modos, según la configuración del quórum. Existen cuatro modos de quórum disponibles en un clúster de conmutación por error de Windows Server 2008, tal y como se muestra en la Figura 4. De los cuatro modos que aparecen en la lista, tan sólo los dos primeros (Mayoría de nodo y Mayoría de disco y nodo) se pueden seleccionar automáticamente durante el proceso de creación del clúster. Se debe usar la siguiente lógica:
  • Si se va a configurar un número impar de nodos en el clúster, seleccione el modo Mayoría de nodo.
  • Si se va a configurar un número par de nodos en el clúster y el almacenamiento compartido está activado y accesible, seleccione Mayoría de disco y nodo.
Figura 4 Modos de quórum en el Asistente para configurar quórum de clúster (haga clic en la imagen para ampliarla)
Si desea seleccionar un disco testigo del almacenamiento disponible, seleccione el primer disco que tenga como mínimo un tamaño de 500 megabytes y que tenga configurada una partición NTFS. Los modos de quórum restantes sólo se pueden seleccionar de forma manual, por lo que deberá ejecutar el asistente para configurar quórum de clúster. La opción de Mayoría de recurso compartido de archivos y nodo se usa normalmente durante la configuración de un clúster de varios sitios o en un clúster CCR de Exchange 2007. La última opción es el modo Sin mayoría: sólo disco, que equivale al modelo de quórum compartido de los clústeres heredados. Es un único punto de posibles errores y, por lo general, no se recomienda su uso.
Sólo hay dos tipos de recursos testigo, un disco físico y un archivo compartido que se pueden configurar en el clúster para alcanzar el consenso.
Un disco testigo es una porción de almacenamiento que el servicio de clúster puede activar. Este disco está ubicado en el grupo de recursos principal del clúster, junto a los recursos del nombre de la red y de las direcciones IP asociadas. Cuando se configura el disco testigo, se coloca en él una carpeta del clúster y una copia completa de la configuración del clúster (sección del clúster o réplica).
Un FSW es un recurso compartido de red que, en una situación ideal, está ubicado en un servidor de la red que no forma parte del clúster. Se realiza una conexión SMB al FSW, y este mantiene una copia del archivo de registro testigo, que contiene información acerca del control de versiones de la configuración del clúster.
Sólo se puede configurar un recurso testigo en un clúster. Este recurso proporciona un voto extra en caso de que el clúster deba alcanzar el quórum. Es decir, si le hace falta al clúster un único voto (y, por lo tanto, un nodo) para alcanzar el consenso, el recurso testigo entra en línea para que esto sea posible. Si al clúster le hace falta más de un voto para conseguir el quórum, se omite el recurso testigo y el clúster permanece en un estado latente a la espera de que se una otro nodo de clúster.

Características de seguridad mejoradas
Los clústeres de conmutación por error incluyen varias mejoras en cuanto a seguridad. Probablemente la más significativa tenga que ver con la eliminación del requisito referente a la existencia de una cuenta de servicios de clúster (CSA). En versiones anteriores del Servicio de Microsoft Cluster Service, se necesitaba una cuenta de usuario del dominio durante el proceso de configuración. Esta cuenta, que se usaba para iniciar el servicio de clúster, se agregaba al grupo de administradores locales de cada nodo del clúster. Del mismo modo, se proporcionaban los derechos de usuario local requeridos para que el servicio de clúster funcionara correctamente. Como cuenta de usuario del dominio, la CSA estaba sujeta a un número de directivas de nivel de dominio que se podían aplicar a los nodos del clúster. Estas directivas podían impactar de manera negativa en la alta disponibilidad, lo que provocaba errores en el servicio del clúster.
Actualmente, el servicio de clúster se ejecuta con una cuenta de sistema local que posee un conjunto de derechos determinados sobre el nodo del clúster local. De este modo, puede funcionar correctamente. El contexto de seguridad para el clúster ha cambiado al objeto de nombre de clúster (CNO), que es el objeto del equipo que se crea de forma predeterminada en el contenedor Computers de Active Directory® cuando se crea por primera vez el clúster. Cuando el clúster se ha creado correctamente y hay un CNO en Active Directory, ya no hace falta la cuenta de usuario que se creó para instalar y configurar el clúster.
Los objetos de equipo adicionales que se hayan creado en el contenedor Computers de Active Directory se asocian a un clúster de conmutación por error. Estos objetos, denominados objetos de equipo virtual (VCO) se corresponden con los recursos de nombre de red que se crearon como parte de los puntos de acceso cliente (CAP) en el clúster. El CNO, que se responsabiliza de crear todos los VCO de un clúster, se agrega a la lista de control de acceso del sistema (SACL) del objeto en Active Directory (consulte la Figura 5).
Figura 5 Seguridad de un VCO en Active Directory (haga clic en la imagen para ampliarla)
El CNO también se responsabiliza de sincronizar las contraseñas de dominio para todos los VCO que haya creado. Este proceso se realiza de acuerdo con la directiva de dominio que se haya configurado para la rotación de contraseñas. De modo adicional, dado que el CNO se responsabiliza de crear en un clúster todos los objetos de equipo asociados al VCO, el CNO (cuenta de equipo) debe tener el derecho de nivel de dominio para crear objetos de equipo en el contenedor en el que se hayan creado los VCO (de forma predeterminada, el contenedor Computers).
Otro cambio a tener en cuenta es que ahora se usa Kerberos como método de autenticación predeterminado. El hecho de que existan cuentas de equipo en Active Directory ha permitido la mejora de esta característica de seguridad. Si una aplicación que no puede usar Kerberos para autenticarse precisa en algún momento el acceso a los recursos del clúster, este puede usar la autenticación de NT LAN Manager (NTLM).
También es más segura la comunicación entre los nodos de clúster que están directamente relacionados con el proceso del clúster. Todas las comunicaciones entre clústeres están firmadas de forma predeterminada. Mediante la interfaz de lenguaje común (CLI) de cluster.exe, se puede modificar esta propiedad del clúster para cifrar la comunicación entre los nodos. De este modo, se proporciona un mayor nivel de seguridad.

Ampliación de la funcionalidad de la red
Las nuevas capacidades de red de los clústeres de conmutación por error permiten una mayor flexibilidad a la hora de diseñar soluciones de alta disponibilidad y para la recuperación ante desastres. Al mismo tiempo, las mejoras de red proporcionan una conectividad más confiable entre los nodos del clúster.
La característica que más han solicitado los clientes es la capacidad de ubicar nodos del clúster en redes independientes. Ahora es posible hacerlo. Se ha vuelto a escribir completamente el controlador de red del clúster para que pueda proporcionar una comunicación entre nodos altamente confiable y tolerante a errores. Esto es posible siempre que cada nodo esté conectado con, al menos, dos redes independientes y que se hayan enrutado de manera diferente.
El controlador de red del clúster construye su propia tabla interna de enrutamiento, basada en la información acerca de la conectividad que se proporciona durante el proceso de inicio del clúster. Incluye información acerca de la conectividad local, así como la que se proporciona en la base de datos de la configuración del clúster (subárbol del registro de clúster).
Parte del proceso de validación del clúster incluye un proceso de detección de la conectividad de la red. La capacidad de ubicar nodos de clúster en diversas redes conectadas ha suavizado los requisitos de red para los clústeres de varios sitios. Esto facilita y abarata su implementación por parte de las organizaciones. También convierte el almacenamiento iSDCS en una solución más atractiva para el uso con clústeres de conmutación por error.
Los nodos del clúster también pueden obtener la información de direcciones IP mediante DHCP (Protocolo de configuración dinámica de host). Esto puede aligerar la carga de administración de la red si se asignan direcciones dinámicas a los servidores del entorno.
La configuración de las interfaces de red del nodo de un clúster determina las redes que usarán direcciones IP estáticas o dinámicas. Incluso si un recurso de dirección IP de un clúster se obtiene a partir de un servidor DHCP, se puede cambiar a una dirección IP estática mediante el complemento Administración del clúster de conmutación por error.
Antiguamente, todas las comunicaciones de los clústeres usaban la difusión por el Protocolo de datagramas de usuario (UDP) y, en ocasiones, recurrían a la multidifusión. La funcionalidad de la multidifusión se ha dejado de usar y las comunicaciones entre clústeres usan actualmente la unidifusión UDP. El puerto que suelen usar más a menudo los clústeres de Microsoft sigue siendo el 3343. A muchos administradores de red les complacerá descubrir que ya no se usa la difusión. Sin embargo, lo que merece más la pena de un clúster es el nuevo proceso de mensajería interno del propio servicio de clúster. Este tema no se tratará en este artículo. La comunicación entre clústeres está actualmente relacionada con la comunicación TCP, que es mucho más confiable, a pesar de que se sigue usando UDP como mecanismo de transporte.

Aumento de la confiabilidad al interactuar con el almacenamiento
El modo que tienen los clústeres de conmutación por error de interactuar con el almacenamiento ha cambiado radicalmente. Se ha vuelto a escribir por completo el controlador de disco del clúster (clusdisk.sys), y ahora es un controlador Plug and Play (PnP). También ha cambiado su modo de interactuar con el almacenamiento.
En Windows Server 2003, el controlador de disco del clúster se encontraba en una ruta directa al almacenamiento. Sin embargo, en Windows Server 2008, se comunica con el controlador del administrador de la partición (partmgr.sus) para la interacción con el almacenamiento. Ambos enfoques se ilustran en la Figura 6.
Figura 6 Cambios en la pila de almacenamiento en Windows Server 2008 (haga clic en la imagen para ampliarla)
El administrador de la partición se responsabiliza principalmente de proteger los recursos de disco del clúster. Todos los discos que se encuentran en un bus de almacenamiento compartido permanecen automáticamente sin conexión cuando se les asigna por primera vez un nodo del clúster. Esto permite que el almacenamiento se asigne simultáneamente a todos los nodos de un clúster incluso antes de la creación del mismo. Ya no es necesario iniciar los nodos uno por uno, preparar los discos en uno de ellos y, a continuación, apagar el nodo para iniciar otro, comprobar la configuración del disco, etc.
Sin embargo, aún se deben ejecutar las pruebas de almacenamiento como parte del proceso de validación del clúster. Por lo tanto, es necesario que se inicien todos los discos. Esto se puede realizar en uno de los nodos del clúster antes de ejecutar el proceso de validación. Una vez que se haya agregado el almacenamiento a un clúster, los discos muestran el estado Reservado en la interfaz Administración de discos y nunca se dejan en estado desprotegido.
Otro cambio tiene que ver con los comandos SCSI. En Windows Server 2003, los comandos Reserve\Release de SCSI-2 se usaban con el controlador de disco del clúster durante la escritura de los sectores del propio disco. En Windows Server 2008, se precisan los comandos PR (Reserva persistente) de SCSI-3. Conviene registrar los nodos del clúster antes de que puedan realizar una reserva para el almacenamiento. Del mismo modo, los nodos del clúster defienden periódicamente sus reservas mediante el protocolo de Reserva y Defensa.
Una de las pruebas de almacenamiento del proceso de validación comprueba esta funcionalidad. Si una solución de almacenamiento no es compatible con los comandos (PR) de SCSI-3, no será compatible con un clúster de conmutación por error.
Muchas organizaciones usan para conectarse con el almacenamiento un software de múltiples rutas para la redundancia. Esto es compatible e, incluso, se promueve como práctica recomendada. Sin embargo, es necesario volver a escribir las soluciones de software de múltiples rutas de terceros o los módulos específicos de dispositivos. Para ello, debe usarse el estándar de E/S de múltiples rutas de Microsoft. De este modo, las soluciones y los módulos serán compatibles con un clúster de conmutación por error. Esto garantiza que todos los comandos PR de SCSI-3 se envían de manera simultánea por todas las rutas hacia el almacenamiento, independientemente de si la ruta está activa o no. Esta funcionalidad también se comprueba como parte del proceso de validación.
Las mejoras adicionales del almacenamiento incluyen un proceso mejorado de comprobación de disco (chkdsk.exe), una funcionalidad integrada de reparación de disco que anteriormente formaba parte de la utilidad de recuperación del servidor del clúster, así como discos de recuperación automática. En los clústeres de conmutación por error, se usan tanto la firma de disco como el identificador de LUN durante la identificación de un recurso de disco del clúster. Si se ha modificado alguno de los dos, se actualiza la configuración del clúster. Esto se traduce en una reducción del número de errores, debido a que se ha modificado un atributo del recurso de un disco físico, lo cual resulta en una mayor disponibilidad.

Procesos de recuperación integrados
La reparación del disco que se ha mencionado anteriormente es, evidentemente, una de las capacidades de recuperación integradas. Otra de ellas es la capacidad de reparación de Active Directory. Si se elimina un objeto de equipo que representa al CNO, ya no tendrá que crear los objetos de equipo asociados a los CAP del clúster. Sin embargo, el primer problema con el que seguramente se encontrará tendrá lugar cuando las aplicaciones o los usuarios altamente disponibles no puedan obtener acceso a los recursos que se encuentren fuera del clúster, debido a que no pueden obtener un símbolo (token) de seguridad.
El proceso de recuperación de un CNO eliminado consiste en dos pasos. En primer lugar, un administrador de dominio debe ocuparse de recuperar el objeto de equipo eliminado que se encuentra en el contenedor DeletedObjects de ActiveDirectory. A continuación, una vez que se haya restaurado y rehabilitado el objeto, debe ejecutar el proceso de reparación del objeto de Active Directory. Para ello, use el complemento Administración del clúster de conmutación por error.
En los clústeres de Windows Server 2003, cabía la posibilidad de que el archivo de configuración del clúster ubicado en el subdirectorio %systemroot%\cluster pudiera corromperse y, por lo tanto, necesitara reemplazarse. En este caso, es bastante útil la capacidad de recuperación automática de los clústeres de conmutación por error. Si el servicio de clúster se inicia en un nodo y la base de datos de la configuración se corrompe, se cargará una plantilla de configuración mínima a partir de la información contenida en la clave del Registro HKLM\System\CCS\Services\ClusSvc\Parameters. El nodo tratará de unirse a un clúster que ya esté formado y, si lo consigue, se insertará en el nodo una copia nueva del subárbol del registro del clúster. En caso de que un nodo no pueda unirse a un clúster, finalizará el servicio.

Nuevas funciones de copia de seguridad y restauración
Windows Server 2008 Failover Clustering se presenta con su propio escritor del Servicio de instantáneas de volumen. Este escritor desempeña un papel fundamental a la hora de realizar copias de seguridad y de restaurar una base de datos de un clúster, así como de los datos que se encuentran en los recursos del disco físico. La tarea de realizar copias de seguridad de la configuración del clúster es bastante sencilla. Mientras el estado del sistema forme parte de una copia de seguridad, la configuración del clúster se puede restaurar. Sin embargo, tenga en cuenta que sólo se debe hacer una copia de seguridad de un clúster si este tiene quórum. Esto garantiza que se va a realizar una copia de seguridad de la configuración del clúster más reciente.
Existen dos tipos diferentes de restauraciones de clústeres: autoritativa y no autoritativa. Una restauración no autoritativa usa Copias de seguridad de Windows Server o una aplicación de copias de seguridad de terceros para ejecutar la restauración a partir de una copia de seguridad seleccionada. Por otro lado, sólo se puede realizar una restauración autoritativa de un nodo de clúster mediante el CLI de Copias de seguridad de Windows Server (wbadmin.exe).
En resumidas cuentas, una restauración autoritativa lleva la configuración del clúster "hacia atrás en el tiempo", hasta el momento en que se realizó la copia de seguridad. Para realizar una restauración autoritativa, se detiene el servicio de clúster en todos los nodos, excepto en el nodo en que se esté ejecutando la restauración. Cuando se haya completado la restauración y se haya iniciado el servicio de clúster en el nodo restaurado, la configuración restaurada del clúster se convierte en la configuración definitiva del nuevo clúster. A continuación, cuando se haya reiniciado el servicio en los nodos restantes del clúster, se inserta la configuración restaurada durante el proceso de unión.
Esto puede ahorrar bastante tiempo y dinero en circunstancias determinadas. Supongamos que tiene un clúster de impresión que hospeda varios recursos del administrador de trabajos de impresión, que cada uno de ellos admite 1500 impresoras y que, accidentalmente, elimina uno de los recursos. Un gran número de usuarios ya no podrán imprimir documentos. En lugar de volver a agregar manualmente todas las impresoras en la configuración del clúster, es mucho más rápido realizar una restauración autoritativa de la configuración del clúster. Por supuesto, esto depende de si tiene una copia de seguridad y una estrategia de restauración lo suficientemente sólidas.

Migración desde los clústeres de Windows Server 2003
Debido a todos los cambios en la arquitectura de Windows Server 2008 Failover Clustering, no se admiten las actualizaciones locales o graduales desde Windows Server 2003. Al actualizar los clústeres de Windows Server 2000 a Windows Server 2003, muchas organizaciones expulsaban todos los nodos del clúster de forma sistemática. A continuación, realizaban una instalación limpia del sistema operativo y, finalmente, volvían a insertar el nodo en el clúster. No se puede usar este enfoque para migrar a Windows Server 2008, ya que los nodos de clúster de Windows Server 2003 y Windows Server 2008 no pueden formar parte del mismo clúster.
Afortunadamente, se ha incluido un asistente para ayudarle en el proceso de migración. No obstante, una migración a un clúster de conmutación por error de Windows Server 2008 precisará algo de planeación previa. Existen tres situaciones básicas de migración:
  • Uso de los mismos servidores y almacenamiento.
  • Uso de los mismos servidores pero con un nuevo almacenamiento.
  • Uso de nuevos servidores y almacenamiento.
Cualquiera de estos escenarios conlleva asegurarse de que el hardware está certificado por el programa de logotipo de Windows Server 2008 y, además, que se ha ejecutado correctamente el proceso de validación del clúster de conmutación por error. Una vez que se hayan completado estos pasos, se puede continuar con el proceso de migración.
No se pueden migrar todos los recursos de un clúster de Windows Server 2003. Se pueden migrar los nombres de red, las direcciones IP, los discos físicos, los archivos compartidos, las raíces del sistema de archivos distribuidos (DFS), DHCP y WINS. También puede migrar, hasta cierto punto, los servicios, aplicaciones y recursos de scripts genéricos.
Mientras tanto, aplicaciones como Microsoft Exchange y SQL Server® tienen sus propios procedimientos de migración a un clúster de conmutación por error. Se pueden migrar las impresoras a Windows Server 2008 mediante el complemento Administración de impresión (que se instala con la función del servidor de impresión) para, en primer lugar, exportar las impresoras y, a continuación, importarlas a un nuevo servidor de impresión de alta disponibilidad. No se puede migrar ningún tipo de recurso de terceros.
El proceso de migración no se aplica a ningún tipo de datos. Implica la migración de los parámetros de configuración del clúster de Windows Server 2003 a los de Windows Server 2008.
Al principio, todos los recursos migrados permanecerán sin conexión hasta que se complete el proceso de migración. Esto se debe a que puede que deba llevar a cabo algunos pasos adicionales. Por lo tanto, es importante revisar el informe que se elabora una vez que ha finalizado el proceso de migración para comprobar los pasos adicionales (propios de la migración de datos, en caso de que se vaya a realizar la migración a nuevo almacenamiento) que se deben llevar a cabo antes de activar el clúster. Por ejemplo, si se está migrando un servidor DHCP, la función del servidor DHCP debe estar instalada en todos los nodos del clúster. Si la migración se está realizando a un servidor WINS, la función del servidor WINS también debe estar instalada en todos los nodos del clúster.

Chuck Timon es un ingeniero de soporte técnico en Microsoft y se ocupa de las tecnologías de clústeres e instalación. Escribió el manual de aprendizaje sobre Windows Server 2008 Failover Clustering y actualmente está desarrollando el material de aprendizaje de Hyper-V.


Nota del editor La impresión ha muerto
Joshua Hoffman

La impresión ha muerto. O eso quieren hacerle creer muchos. En la era de la información ilimitada, disponible en todas las formas posibles, en miles de dispositivos fantásticos, ¿qué sentido tiene un conjunto de papeles unidos con pegamento? ¿Realmente son necesarios en nuestro entorno actual? ¿Deben las revistas y los periódicos ser relegados a las estanterías de un museo, de forma que podamos recordar en un futuro cómo era llevar con nosotros diminutos trocitos comprimidos de árbol y tinta?
¿Le parezco un poco melodramático? Sí. Estoy seguro de que ha adivinado que se trata de una premisa con la que no estoy en absoluto de acuerdo (y no sólo por el bien de la seguridad de mi trabajo; hay muchísimas cosas que podría estar haciendo en Microsoft). Creo firmemente en el hecho de que la palabra impresa ofrece una experiencia increíblemente profunda y rica, a pesar de (o quizás debido a) su sencillez. Siempre preferiré leer un artículo largo en papel a leerlo en la pantalla de mi equipo. Para mí, simplemente es más cautivador. ¿Se trata de un punto de vista anticuado? Puede que sí, pero según los resultados de la última encuesta realizada a nuestros lectores, el 90% de ellos piensa exactamente lo mismo.
Ahora bien, yo no sugiero que sigamos la táctica del avestruz. Soy, al igual que ellos, un entusiasta de la informática y adoro la tecnología. Pero una publicación como la nuestra puede, y debe, ser una experiencia holística, por lo que deberá adoptar distintas formas: en línea, sin conexión y en persona. Si me dispongo a leer un largo artículo de Mark Russinovich, de contenido muy técnico, con toda seguridad desearé leerlo en su forma impresa. Aunque, al mismo tiempo, deseo escuchar la conferencia de Mark y verle demostrar las técnicas que está explicando.
Esta noción se ha convertido en un principio fundamental para TechNet Magazine. Aunque estamos orgullosos de la publicación que enviamos a imprimir todos los meses, todo el contenido publicado en tinta está también disponible en Internet. Además, en un futuro próximo, podrá ver más contenido que aprovecha la exclusiva plataforma que nos ofrece Internet. Por ejemplo, en nuestro último número, comenzamos nuestra serie de presentaciones en pantalla con Don Jones y su columna de Windows PowerShell. Ahora es posible ver un vídeo de Don comentando el tema de la columna de este mes. Nuestro sitio web cuenta ahora también con una nueva columna sobre informática sostenible dedicada por completo al impacto ambiental de la TI y a lo que podemos hacer, como profesionales de TI, para ser ciudadanos globales responsables.
Como siempre, sus comentarios son imprescindibles para convertir TechNet Magazine en una experiencia de medios enriquecida. Escríbanos a tnmag@microsoft.com.
Joshua Hoffman

Mi agradecimiento a los siguientes expertos de Microsoft: Ed Banti, Avronil Bhattacharjee, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Elden Christensen, Trina Gorman, Scott Landry, Michael Murgolo, Sanjeev Nair, Hugh Pyle, Amritansh Raghav, Jez Sadler y Jim Truher.


Cartas Comentarios de los lectores

Servicios de dominio de Active Directory
Me ha encantado el número de marzo de 2008 de TechNet Magazine. Creo que me lo he leído unas 12 veces. Concretamente, me gustó mucho el artículo de Gil Kikpatrick, "Novedades de los Servicios de dominio de Active Directory". En el artículo, Gil menciona un producto denominado Servicios de recopilación de auditorías de Microsoft®, ¿Está este producto disponible actualmente? ¿Funciona como una aplicación independiente?
Erasmo M.

Los servicios de recopilación de auditorías de Microsoft (ACS) forman parte de System Center Operations Manager (SCOM), el software de administración que se conocía anteriormente como Microsoft Operations Manager (MOM). No está disponible como producto independiente, sólo como parte de SCOM.
Gil Kirkpatrick, director técnico de NetPro y autor de TechNet Magazine

Firmas digitales
En el segundo párrafo del artículo sobre Windows PowerShell de la edición de abril de 2008 de TechNet Magazine ("Firme aquí", technet.microsoft.com/magazine/cc434702), el autor, Don Jones, señala lo siguiente: "La firma es el término técnico correcto para lo que estoy hablando, aunque la palabra en sí no es una buena descripción de lo que realmente sucede aquí. Firmar un script no significa que lo apruebe o autorice, como puede ser el caso con un contrato o un recibo de tarjeta de crédito".
En mi opinión, firmar un contrato o un recibo de tarjeta de crédito no implica necesariamente la aprobación o la autorización de estos elementos. La acción que se realiza sólo tiene sentido en un contexto mucho más amplio del entorno. Por ejemplo, cuando era más joven, solía jugar con los recibos de las tarjetas de crédito en la estación de servicio de mi padre. Nadie intentó cobrar las deudas que contraía en esas transacciones.
En el contexto de una implementación de red de Active Directory® "configurada correctamente", la firma es exactamente lo que autoriza el funcionamiento del script. La presencia de la firma indica que la persona firmante acepta la responsabilidad de lo que ha firmado. Entonces, la presencia de la firma puede desencadenar otras actividades: la facturación por parte de la compañía de la tarjeta de crédito o la aceptación del código como auténtico por parte de la red.
Seguid trabajando así de bien; TechNet Magazine sólo reporta beneficios.
Jeremy P.

Gracias por tu comentario, Jeremy. Nos gusta saber que nuestros lectores prestan tanta atención a lo que decimos en TechNet Magazine.

SharePoint Services
Al ejecutar Windows® SharePoint® Services (no Microsoft Office SharePoint Server), ¿hacen falta otras licencias CAL para que los usuarios obtengan acceso a través de la interfaz o la URL de un sitio web?
Douglas M.

Se han publicado algunos documentos acerca de este tema. Aquí tiene algunos vínculos que le resultarán de utilidad: msmvps.com/blogs/cgross/archive/2005/04/02/40723; microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx y windowsserver/sharepoint/bb684457.
Pav Cherny, columnista, Dentro de SharePoint, TechNet Magazine

Idea para Dentro de SharePoint
Hace poco, leí la columna de SharePoint en el número de mayo de 2008 de TechNet Magazine (technet.microsoft.com/magazine/cc462809). En ella, se pedía a los lectores que ofrecieran sugerencias para posibles temas. Sería genial contar con artículo acerca de la integración de SharePoint con Project/Project Server.
Phil H.

Lo de Project/Project Server es una idea estupenda. Definitivamente, tendremos en cuenta este tema para posibles artículos. Gracias por su respuesta.

Otras ideas para Dentro de SharePoint
Globalmente, la web tiene una gran riqueza de documentos relacionados con la personalización de sitios mediante la UI estándar de SharePoint o con SharePoint Designer. Sin embargo, no hay casi nada acerca de las definiciones de sitios (y los artículos que se han publicado son tan básicos que no sirven de mucho al enfrentarse a un problema del mundo real). Como es un área que muchas personas están empezando a conocer, la publicación de procedimientos facilitaría la adopción de SharePoint. Concretamente, en mi empresa encontramos complicados los temas siguientes:
  1. Establecimiento de permisos personalizados para las listas de una definición de sitio.
  2. Formularios de elementos de lista personalizados en una definición de sitio.
  3. Conexiones con elementos web desde una definición de sitio.
  4. La distribución incremental de una definición de sitio.
Adam C.

Gracias por sus sugerencias. A medida que sigamos desarrollando este contenido, este es exactamente el tipo de comentarios que tendremos en cuenta.


Cuadro de herramientas Nuevos productos para profesionales de TI
Greg Steen

Automatización de las tareas de administración
Automise 2
automise.com/automise.aspx
Las tareas repetitivas que se realizan de manera mecánica suelen ser aburridas, laboriosas y proclives a errores. Para una mayor corrección de la administración y una mayor satisfacción laboral, resulta esencial automatizar este tipo de tareas. Aparte de usar aburridos archivos por lotes y VBScripts personalizados para automatizar las tareas, también existen algunas utilidades para Windows® similares a las macros, así como otras que incluso obligan a aprender algún tipo de lenguaje de scripting personalizado. Pero también hay otra opción. Automise 2, de VSoft Technologies, permite generar rutinas automatizadas mediante una GUI de estilo personalizable que usa la capacidad de arrastrar y colocar.
La interfaz de la aplicación es semejante a un IDE de programación simple, lo que proporciona unas opciones que le resultarán bastante familiares. Obtendrá un cuadro de herramientas con el que arrastrar los elementos a la superficie de diseño. También podrá depurar los controles que permiten modificar el código y ver los diferentes proyectos, los registros de resultados de la ejecución, los historiales y las ventanas de propiedades. Gracias a Automise, su "código" representará visualmente el flujo de trabajo de las tareas automatizadas.
El cuadro de herramientas de Automise consiste en diversas acciones, donde cada una de ellas realiza un paso del proceso de automatización. Con la aplicación se incluyen 380 acciones que abarcan todas las operaciones posibles, desde la creación de archivos .zip al reinicio de IIS.
Al diseñar su tarea, puede estructurar todas las acciones de manera jerárquica para que abarquen todos los procesos administrativos que realiza regularmente. Además, puede unir las acciones mediante acciones de control de flujo. Por ejemplo, bloques try/catch, provocación de excepciones, instrucciones if-then-else, bucles, conmutadores, retrasos y grupos de acciones asincrónicas.
Los proyectos de automatización pueden incluir otros proyectos con el fin de separar el flujo de control principal de sus subtareas. También existen acciones para manipular cadenas y datos XML, configurar variables, esperar la ejecución de procesos y comandos, etc. Gracias a todas estas opciones de flujo de control, se podrán automatizar incluso las operaciones más complejas.
Automise permite crear, ejecutar, editar y eliminar tareas programadas. Esto quiere decir que también puede usar Automise para administrar los procesos existentes. No puedo enumerar aquí la lista completa de todas las acciones pero, entre las más importantes, se encuentran: acciones para registrar un DLL en GAC (caché de ensamblados global), reconstruir índices de SQL Server®, ejecutar ChkDisk, editar el Registro, realizar una copia de seguridad del registro de eventos, editar los usuarios de Active Directory®, montar volúmenes, crear puntos de restauración y crear un directorio virtual. Si las acciones integradas no le permiten realizar lo que desea, Automise también ofrece scripts y comandos personalizados, así como acciones de ejecución ad hoc de SQL.
En definitiva, se trata de una herramienta bastante útil. Si lo que desea realmente es automatizar su propia estación de trabajo de Windows, en contraposición con la automatización de una infraestructura de red, eche un vistazo a Automise Lite, que ofrece un menor número de características pero que cubrirá la mayoría de sus necesidades.
Precio: La licencia para un solo usuario es a partir de 195 USD (venta directa).
Automatice las tareas de un modo visual con Automise 2 (haga clic en la imagen para ampliarla)

Supervisión de registros en tiempo real
BareTailPro
baremetalsoft.com/baretailpro
¡Registros, registros por todas partes! El verdadero problema reside en usarlos. Está muy bien que una aplicación genere un registro de todas las transacciones que se realicen. Pero, aparte de las herramientas para agregar registros, ¿existe algún modo de saber lo que está ocurriendo en tiempo real? Una solución es la aplicación de eficacia probada BareTailPro, de Bare Metal Software. Aunque la última vez que se actualizó fue en 2006, esta sencilla utilidad sigue siendo la versión mejorada para Windows del antiguo comando 'tail-f' de la consola *nix.
Gracias a su sencilla GUI, puede ver de manera simultánea varios archivos de registro de cualquier tamaño. De este modo, podrá ver lo que se escribe en ellos en tiempo real. Para alternar entre archivos, sólo es necesario hacer clic en la ficha correspondiente. Como una característica atractiva, cada ficha muestra un icono que indica el estado de cada archivo de registro: si se está escribiendo actualmente en el archivo o si se ha detenido el "final".
Aunque la mayoría de las aplicaciones producen registros, el modo que tiene cada una de hacerlo es bastante diferente. Afortunadamente, BareTailPro puede leer archivos Unicode, UTF-8, ANSI y ASCII. También puede administrarlos tanto si las líneas finalizan en pares CR/LF como en LF únicos y nulos. Se pueden configurar fácilmente el ajuste de líneas y la expansión de fichas para visualizar mejor un tipo determinado de archivo de registro. Además, puede mejorar la legibilidad del archivo de registro. Para ello, puede configurar el tamaño y el tipo de fuente, el espaciado y el interlineado.
Otra gran característica es el resaltado configurable de la aplicación, que se puede aplicar a la vista de cualquier registro. Puede configurar cualquier número de normas de códigos de colores para el primer y el segundo plano basadas en una cadena de texto. Por ejemplo, puede resaltar cualquier error en rojo y cualquier advertencia en amarillo. También puede resaltar todas las líneas que tengan una dirección IP o una referencia de host específicas. Puede especificar que las líneas estén en negrita o en cursiva, así como optar por pasar por alto el uso de mayúsculas o minúsculas en la cadena de texto.
Incluso con el resaltado de texto, es posible que un archivo de registro bastante intenso sature la vista del final, lo que dificulta la localización de los eventos que esté buscando. BareTailPro proporciona otra característica que puede servirle de ayuda. La función de búsqueda de texto y expresiones regulares permite filtrar rápidamente la vista del registro, al aislar las líneas deseadas en un subconjunto mucho más administrable. La sintaxis de expresiones regulares que usa BareTailPro está compuesta de un subconjunto de notaciones estándar que usan Java, Perl y PHP. En caso de que no esté familiarizado con este uso, el sitio web del producto le proporciona una guía de referencia rápida.
La utilidad muestra los resultados filtrados en formato tabular, para lo que se agregan algunas columnas que le resultarán de utilidad, por ejemplo, la hora, el número de línea y los resultados de cualquier grupo de captura que haya definido junto al origen de línea original. En la vista filtrada, también se pueden ordenar estas columnas.
Nunca recuerdo la sintaxis de la expresión regular que me proporciona siempre los resultados que necesito. Por eso agradezco que la herramienta tenga una característica para guardar patrones. Esto permite nombrar, editar y guardar patrones para volver a usarlos posteriormente. Cuando obtenga una vista filtrada de todas las líneas importantes, con BareTailPro podrá exportar los resultados en un archivo o en el portapapeles con un formato adaptado. Esto permite configurar el ancho, la alineación, el prefijo y el sufijo de todas las columnas resultantes.
También cabe destacar que esta pequeña utilidad está incluida en un archivo ejecutable de pequeño tamaño, lo que facilita su transporte y reduce su impacto en el entorno. Tenga en cuenta que, si sólo necesita ver los archivos de registro, sin filtrar expresiones regulares, guardar patrones buscados ni exportar los resultados de las búsquedas y de los filtros, puede que le baste el uso de la versión gratuita de la aplicación, denominada BareTail.
Precio: A partir de 35 USD para las licencias individuales.
Supervisión de la red con BareTailPro (haga clic en la imagen para ampliarla)

Haga un inventario de sus sistemas
Total Network Inventory
softinventive.com
Un aspecto clave de una correcta administración del sistema consiste en obtener el acceso rápido a información detallada de los equipos del entorno. Resulta muy fácil perder la cuenta de las hojas de cálculo y las listas de proveedores con esta información. Al mismo tiempo, mantenerlas al día puede ser una tarea muy dura, y la información puede quedar desfasada rápidamente.
El uso de una herramienta dinámica que presente la información tal y como la necesita puede resultar bastante útil, ya que puede recopilar la información del software instalado en diferentes equipos y el tipo de hardware que se está ejecutando. Una herramienta como esta también proporciona una buena manera de mantener fichas de los extras que pueden haber incluido los usuarios en un equipo. Esto, por supuesto, sucede si su directiva de grupo no limita los derechos de instalación, o si no dispone de cifras totales en cuanto al número de licencias que debería tener según la base de instalación de un paquete de software determinado. Una herramienta que encaja con estos requisitos es Total Network Inventory de Softinventive Lab.
Después de instalar Total Network Inventory, puede comenzar el proceso mediante el asistente para el análisis, que le guía a través de los nodos de la red. Puede optar entre iniciar este proceso inmediatamente mediante un intervalo de direcciones IP determinado o explorando los equipos de Sitios de red. También puede analizar los scripts de inicio de sesión, lo que permite recopilar información a medida que un equipo inicia la sesión en el dominio.
Para llevar a cabo este análisis, Total Network Inventory se basa en el Instrumental de administración de Windows (WMI), tanto en IPC$\ADMIN$ como en RPC/DCOM, y en el clásico uso compartido de cuentas locales. Por lo tanto, deberá ejecutarlo en el contexto de una cuenta de administrador.
Cuando se haya completado el análisis, puede examinar los equipos o buscar equipos determinados para realizar un inventario de sus activos. Total Network Inventory agrupa la información recopilada en tres áreas: hardware, software y otra información. La parte del hardware incluye detalles acerca del procesador, la placa base y el conjunto de chips, la memoria, el subsistema de vídeo, el almacenamiento (incluidos los dispositivos físicos y lógicos), los tipos de adaptadores de red y su configuración, los periféricos y cualquier otro dispositivo que se haya instalado en el sistema.
La parte del software proporciona información acerca del sistema operativo, incluidas las claves de los productos, los números de serie, los directorios del sistema y los paquetes de servicios instalados. También ofrece detalles acerca de las revisiones (con el número del artículo de Knowledge Base correspondiente) y de cualquier aplicación antivirus o de bases de datos instalada. Además, obtendrá una lista de los programas instalados (junto a una vista del directorio Archivos de programa, para que pueda ver las aplicaciones que suelen aparecer escondidas en la lista estándar de Agregar o quitar programas), así como una lista de todas las aplicaciones de ejecución automática.
Por último, la sección dedicada a otra información engloba los detalles acerca del entorno del sistema, como las variables de usuario y del sistema, los recursos compartidos, los procesos en ejecución, los servicios instalados y las cuentas de usuario locales.
Total Network Inventory proporciona la información necesaria para realizar auditorías de activos, comprobaciones de licencias, cálculos de actualizaciones y evaluaciones del rendimiento. Una de las mejores funciones de esta herramienta es el componente de generación de informes. Esta característica proporciona diversos informes detallados y muy bien organizados de absolutamente todo, desde una referencia rápida a la documentación completa referente a auditorías. Además, los informes pueden ser de carácter agregado o estar centrados en un único equipo. Algo que encuentro particularmente útil es la pestaña de contabilidad de licencias y software. Muestra el recuento final de cada tipo de software que se haya instalado en el entorno, con el fin de garantizar que se han cumplido los acuerdos del proveedor.
Precio: A partir de 95 USD para una licencia de 25 nodos.
El asistente para análisis guía a los usuarios durante la detección de nodos de la red (haga clic en la imagen para ampliarla)

Reseña de libro
Mastering Microsoft Exchange Server 2007
sybex.com
Lo quiera o no, uno de los componentes principales para que una organización funcione sin problemas es el uso del correo electrónico. Aunque, para ser sincero, a veces me gustaría que los usuarios fueran a clases para comunicarse bien por escrito antes de que se les permita el uso del correo electrónico. A lo largo de los años, se ha vuelto cada vez más evidente el deseo de utilizar opciones de comunicación por voz, calendario, programación de recursos, acceso uniforme de clientes y filtrado de correo electrónico (para correo no deseado, virus y demás). Aquí es donde Microsoft® Exchange Server 2007 entra en escena.
La última versión de Exchange integra sin problema todos estos componentes en una solución escalable y estable. Sin embargo, con todas estas características y funciones, el administrador, el arquitecto y el personal de asistencia necesitan algunos libros de referencia que les ayuden a planear, implementar, administrar y mantener una solución de mensajería electrónica tan dinámica.
En el último número de esta columna, hablé de Microsoft Exchange Server 2007 Administrator's Companion. Otro buen recurso a tener en cuenta es Mastering Microsoft Exchange Server 2007, de los autores Barry Gerber y Jim McBee (Sybex 2007). Este manual, escrito con un estilo bastante claro, nos presenta el ciclo de vida de Exchange Server.
Los tres primeros capítulos del libro, que componen la sección dedicada a la introducción y la planeación, tratan los componentes y los requisitos de implementación básicos de Exchange Server 2007. Aquellos que conozcan bien las versiones anteriores de Exchange valorarán la sección que trata de las funciones que ya no se implementan o que ya no resultan tan importantes. Todo el mundo valorará la descripción de las diversas funciones del servidor y los componentes que conforman una implementación de Exchange Server 2007. La implementación de un servidor tan complejo precisa cierto nivel de previsión, por lo que deberá prestar especial atención a las secciones que tratan de la planeación del crecimiento, los requisitos de espacio en disco y la integración de Active Directory.
La siguiente sección trata de la propia instalación, tanto una instalación desde cero como una actualización a partir de Exchange Server 2000 o Exchange Server 2003 (no se puede actualizar directamente desde Exchange Server 5.5). También podrá profundizar en las diversas funciones que puede realizar cada servidor Exchange, incluido el transporte perimetral, el acceso de clientes, el transporte de concentradores, el buzón de correo, la mensajería unificada y las herramientas de administración.
A continuación, el libro pasa a hablar de la escalabilidad: nos muestra el modo de supervisar el rendimiento, aumentar la capacidad del buzón de correo, etc. En esta sección, podrá explorar la nueva y atractiva función de replicación continua local, que permite mantener una copia de seguridad local actualizada del almacén de correo. Si le ocurre algo a la base de datos principal, podrá cambiar rápidamente a la copia de seguridad, en lugar de restaurarla desde otra copia de seguridad de menor disponibilidad y menos actualizada.
La siguiente sección del libro proporciona una descripción detallada de las diversas tareas y herramientas de administración que se obtienen con una implementación de Exchange Server 2007. Entre las herramientas, se incluyen el Shell de administración de Exchange (basado en Windows PowerShell™) y la GUI de la Consola de administración de Exchange (que también se basa en el motor de Windows PowerShell). A lo largo de esta sección, descubrirá el modo de administrar los buzones de correo, las listas de direcciones y las cuentas de usuario. También verá la administración de los registros de mensajes, así como la administración de la clasificación de mensajes, los registros en diario y las reglas de transporte.
En la cuarta sección se profundiza en la disponibilidad y la confiabilidad. Ahora que las empresas se han vuelto más dependientes de la mensajería electrónica, es conveniente prestar especial atención a esta sección.
Aquí descubrirá los aspectos básicos del equilibrio de carga, de la redundancia de servidores, almacenamiento y red, y de la agrupación en clústeres. Obtendrá información acerca de las prácticas recomendadas para el mantenimiento programado, para ejecutar copias de seguridad y para las situaciones de recuperación ante desastres. Básicamente, aquí encontrará la información que necesita para mantener activa la eficacia de los sistemas de mensajería electrónica de su compañía, incluso cuando surjan problemas.
Las dos siguientes secciones del libro tratan del acceso de clientes, incluidos Microsoft Office Outlook® 2007, Outlook Web Access, IMAP y POP3. Por último, el libro finaliza con una sección bastante importante para los administradores de Exchange, ya que trata de la seguridad y las auditorías. En esta sección, se muestran algunas prácticas y precauciones de seguridad básicas, así como las diversas herramientas de auditorías que tiene a su disposición. En definitiva, esta completa guía le ayudará a familiarizarse rápidamente con Exchange y a encauzar correctamente la implementación.
Precio: 49,99 USD (venta directa).

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


Utility Spotlight Microsoft SharedView
Greg Steen

A menudo, trabajo con compañeros que se encuentran al otro lado del planeta y suelo encontrarme con situaciones en las que, si todo el mundo pudiese mirar el mismo escritorio e interactuar con él, podríamos ilustrar y comunicar nuestras opiniones de una forma mucho más eficaz.
Imagine que su equipo de ventas se encuentra de viaje y necesita reunirse con ellos para compartir información, comprobar los presupuestos y reducir los esfuerzos que se superponen. Imagine lo productivo que resultaría si todas las personas del equipo pudiesen ver y editar la misma hoja de cálculo de Excel® o el mismo documento de Word de Microsoft® Office simultáneamente, en lugar de enviar un documento por correo electrónico que puede perder la sincronización rápidamente. Ahora hay una herramienta de colaboración ligera que ofrece dicha capacidad: Microsoft SharedView 1.0.
Microsoft SharedView le permite reunirse con 15 personas y compartir el escritorio del host de la reunión de forma simultánea, exactamente igual que si estuviesen delante del mismo equipo. Probablemente haya pensado que si 15 personas tuviesen control a la vez sobre el mismo escritorio, el resultado sería un caos absoluto, pero lo que sucede en realidad es que el control del escritorio pasa de un miembro a otro.
Con el control a su cargo, puede ver los movimientos del mouse de sus colaboradores (todos tienen un puntero personalizado), por lo que pueden señalar elementos de un documento o una aplicación. Por desgracia, SharedView no dispone de capacidades de audio integradas, pero puede usar el cliente de audio de Windows Live™ Messenger o su cliente de voz sobre IP (VoIP) favorito para hablar mientras comparte el escritorio.
Microsoft SharedView permite compartir el escritorio del host de la reunión de forma simultánea (haga clic en la imagen para ampliarla)
La instalación de SharedView es muy sencilla y el cliente es tan intuitivo que incluso los usuarios técnicamente menos avanzados pueden familiarizarse rápidamente. Tras iniciar la sesión con su cuenta de Windows Live, puede iniciar una sesión de SharedView con sólo realizar un par de clics. Es igual de fácil unirse a una sesión. Sólo tiene que escribir el nombre de la sesión (generalmente, el identificador de Live ID del host) a la que desea conectarse junto con una contraseña. Las invitaciones se envían por correo electrónico o puede pegar el texto de invitación generado en su cliente de mensajería instantánea.
Entre las opciones de SharedView, se incluyen la habilitación y la deshabilitación de las funciones copiar y pegar de forma remota (así, los usuarios de la sesión pueden agregar texto desde su estación de trabajo local en el equipo del host), la habilitación directa del control de cambios en Word (de forma que pueda ver los cambios en el documento compartido) y una lista de bloqueo explícita para impedir la participación de algunos identificadores de Windows Live ID. La aplicación también cuenta con una increíble característica de distribución que permite ofrecer archivos complementarios a los participantes de la sesión. Puede tener hasta 25 archivos o un total de 200 MB por sesión.
Además, puede escribir mensajes de difusión a los participantes que aparecerán en la parte superior de su sesión conectada. Si lo desea, puede compartirlo todo o conservar algunas cosas en privado: a medida que la reunión avanza, puede compartir o dejar de compartir ventanas desde el equipo host de forma rápida y sencilla. Con todo ello, si busca una herramienta para la colaboración rápida y sencilla, Microsoft SharedView probablemente le venga como anillo al dedo.
Para comenzar, descargue Microsoft SharedView de la sección de descarga de códigos del sitio web de TechNet Magazine en technetmagazine.com.

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


Dentro de SharePoint Integración de aplicaciones de Office
Pav Cherny

Contenido
Integración de aplicaciones de Office
Ampliación de la interfaz de usuario de SharePoint
Uso del control OpenDocuments de Office
Comunicación con SharePoint
Implementación de una solución OpenControl personalizada
Resumen
Microsoft Windows SharePoint Services (WSS) 3.0 y Microsoft Office SharePoint Server (MOSS) 2007 se integran perfectamente con las aplicaciones de escritorio en 2007 Microsoft Office system, lo que facilita la colaboración en documentos, hojas de cálculo, calendarios, información de contactos, etc. De hecho, la integración es tan perfecta que
se puede decir que 2007 Office system es una plataforma unificada de soluciones de Office.
Esto supone un gran paso adelante para las organizaciones que se centran en la tecnología Microsoft® Office con el objeto de fomentar la productividad de los trabajadores de la información. Sin embargo, las organizaciones con una cartera diversa de aplicaciones de Office no pueden disfrutar del mismo nivel de interoperabilidad original. 2007 Office system proporciona las capacidades de integración necesarias. Sin embargo, las interfaces y los componentes están mínimamente documentados y no funcionan en cualquier situación. Esto dificulta a los proveedores de terceros el integrar la tecnología SharePoint® en sus aplicaciones, y dificulta, incluso en mayor medida, a sus clientes el proporcionar a los trabajadores de la información una experiencia unificada.
En esta columna, mostraré cómo las aplicaciones de Office se integran y comunican con SharePoint y cómo es posible integrar aplicaciones ajenas a Microsoft con SharePoint según los mismos principios. Pero, en primer lugar, explicaré brevemente las opciones de configuración del servidor, los componentes del lado cliente y los protocolos de comunicación usados para conseguir una integración perfecta.
Una vez que hayamos tratado estos detalles, me ocuparé de la integración de aplicaciones que no incluyen compatibilidad con SharePoint. En este intento, iré más allá del nivel usual que se centra normalmente en la implementación de los componentes de IFilter para ampliar las capacidades de búsqueda y agregar iconos personalizados en los servidores de SharePoint. La ampliación de la búsqueda y la devolución de resultados con los iconos apropiados no implican la integración total de las aplicaciones; es posible que los usuarios deseen abrir estos documentos directamente desde la interfaz de usuario de SharePoint.
Aquí es donde esto se complica. Necesita un componente del lado cliente que no está disponible si no ha implementado Office en sus estaciones de trabajo. Pero incluso si ha implementado Office, puede que este componente no funcione correctamente, según la topología y la configuración de su sitio de SharePoint.
Para resolver este problema, creé una solución personalizada que permite integrar cualquier aplicación, por ejemplo, Bloc de notas, Adobe Reader o Autodesk AutoCAD, sin los requisitos de implementación de Office. Esta solución personalizada también explica por qué la integración de aplicaciones basada en componentes estándar de Office es errónea en algunas situaciones. Puede encontrar esta solución, así como las instrucciones paso a paso de implementación y configuración, en el material complementario de esta columna, disponible en la sección de descarga de código de .com.

Integración de aplicaciones de Office
Desde la perspectiva del usuario, los menús de SharePoint parecen funcionar como el menú Inicio de Windows®. La creación de un documento nuevo en una biblioteca de documentos es sencilla: haga clic en Nuevo, a continuación, en Nuevo documento, y se iniciará Microsoft Office Word 2007. La edición de un documento existente es igualmente sencilla. Desplácese por el documento. Abra, a continuación, el menú desplegable del cuadro de edición (ECB) y haga clic en Modificar con Word. Rara vez recordará que inició Word 2007 desde una página web a través de JavaScript, que está ejecutando la aplicación de forma local mientras el documento reside en una base de datos de SQL Server® y que existe un servidor web en la ruta de acceso a datos, tal como se ilustra en la Figura 1.
Figura 1 Trabajo con un documento de Word en SharePoint (haga clic en la imagen para ampliarla)
A pesar de esta complejidad, la experiencia del usuario en una estación de trabajo de Windows con 2007 Office system instalado no presenta complicaciones. El trabajo con documentos en una biblioteca de SharePoint es bastante parecido a trabajar con archivos locales o archivos en un recurso compartido de red.
Sin embargo, en una estación de trabajo de Windows sin Office 2003 o 2007 Office system, la interfaz de usuario es diferente. Al hacer clic en Nuevo documento o en Modificar con Word, sólo aparecerá un cuadro de diálogo que le informará de que no hay disponible una aplicación compatible con Windows SharePoint Services.
Esto no me sorprende en absoluto. Hay varios elementos que deben trabajar en conjunción para ofrecer la experiencia unificada de la cual disfrutan los usuarios de Office. SharePoint debe tener en cuenta los tipos de contenido mantenidos en la biblioteca de documentos para presentar los comandos deseados en los menús Nuevo y ECB. Al hacer clic con el mouse en estos comandos, debe ejecutarse el código de JavaScript para iniciar la aplicación asociada, y pasar la ruta de acceso al documento. Esta parte no es independiente de la configuración de la estación de trabajo, puesto que el código de JavaScript se ejecuta de forma local. Además, la aplicación asociada debe comunicarse con SharePoint para leer y, posiblemente, escribir archivos. Estos son los elementos que debe unificar si desea integrar sus aplicaciones con SharePoint.
Por otro lado, la comunicación entre SharePoint y el servidor de base de datos es transparente para la aplicación, igual que lo son los procesos de indización en el servidor web con el objeto de facilitar las búsquedas. Por este motivo, no explicaré con mayor detenimiento estos aspectos en este artículo, pero recomiendo que consulte el Filter Pack de Microsoft documentado en el artículo de Microsoft Knowledge Base "Cómo registrar Paquete de Microsoft Filter con Windows SharePoint Services 3.0", disponible en support.microsoft.com/kb/946338. Ahora, centremos nuestra atención en agregar los comandos, implementar los componentes del lado cliente necesarios y facilitar la comunicación de aplicaciones.

Ampliación de la interfaz de usuario de SharePoint
Hay disponible una gran variedad de opciones para ampliar la interfaz de usuario de SharePoint y su funcionalidad. Puede cambiar el diseño de sus sitios, personalizar las páginas de ASP.NET, desarrollar elementos web o cambiar el código de JavaScript incluido en WSS y MOSS para iniciar sus aplicaciones directamente.
No hay ninguna razón por la que no pueda abrir el archivo Ows.js en un editor de texto (el archivo puede encontrarse en la carpeta COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 en los servidores front-end de SharePoint) y cambiar el modo de funcionamiento de las funciones createNewDocumentWithProgIDCore, editDocumentWithProgIDNoUI y DispDocItem. No obstante, existe un método mejor con el cual no es necesario cambiar la base de código de WSS de formas no compatibles: el uso de tipos de contenido y de asignaciones de tipo de documento.
En mi artículo "Estandarice la administración de datos con tipos de contenido personalizados" (consulte TechNet Magazine, febrero de 2008, technet.microsoft.com/magazine/cc194408.aspx), expliqué cómo crear tipos de contenido globales y específicos de sitio para administrar documentos y otros tipos de contenido en listas y bibliotecas de documentos de SharePoint. También puede consultar la hoja de cálculo Text Content Type.pdf del material complementario de este artículo, que ilustra cómo crear un nuevo tipo de contenido para archivos de texto y asociar este tipo de contenido con una biblioteca de documentos. El resultado es que puede seleccionar el comando Text Content del menú Nuevo al igual que puede seleccionar el comando Document para documentos de Word (consulte la Figura 2).
Figura 2 Un tipo de contenido personalizado en la interfaz de usuario de SharePoint (haga clic en la imagen para ampliarla)
El menú ECB es igualmente ampliable. Puede que esperara que el menú ECB tuviera en cuenta el contenido, pero no es así como la actual versión de WSS implementa este menú. En su lugar, deberá registrar su tipo de documento en Docicon.Xml, que encontrará en la carpeta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml en cada servidor front-end de SharePoint.
Al agregar la siguiente asignación de tipo de documento a la sección <ByExtension> de Docicon.xml, por ejemplo, conseguirá que SharePoint muestre el comando Modificar con el Bloc de notas (consulte el archivo Text Content Type.pdf para obtener instrucciones más detalladas):
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
El parámetro Key identifica la extensión del nombre de archivo, el parámetro Value define el icono del documento que se mostrará en la interfaz de usuario, el parámetro EditText define la cadena que SharePoint anexa al comando"Edit in" y el parámetro OpenControl especifica el ProgID de un componente COM del lado cliente. Se trata del ProgID que las funciones de JavaScript de SharePoint pasan a una llamada de ActiveXObject (consulte Ows.js para obtener más detalles) con el fin de crear una instancia del objeto COM, que puede ser la misma aplicación o un control auxiliar que inicia la aplicación según el tipo de archivo asociado.
Sitio web de productos y tecnologías de SharePoint

  • Sitio web de productos y tecnologías de SharePoint
  • TechCenter de Windows SharePoint Services
  • Centro para desarrolladores de Windows SharePoint Services
  • Blog del equipo de productos y tecnologías de Microsoft SharePoint
Debe tener en cuenta que el OpenControl denominado SharePoint.OpenDocuments se refiere a un control ActiveX® que se incluye con las versiones más recientes de Office (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Si existe este archivo en sus estaciones de trabajo y, si el icono del documento especificado (parámetro Value) está en la carpeta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images en sus servidores de SharePoint, en este momento puede considerar que gran parte del trabajo de integración necesario ya se ha llevado a cabo.
El SDK de Windows SharePoint Services 3.0 SDK incluye parte de la información acerca de las API del lado cliente que se incluyen en 2007 Office system, incluido el control OpenDocuments. Consulte la sección "Referencia de la API del lado del cliente" en msdn2.microsoft.com/ms440037.

Uso del control OpenDocuments de Office
El control OpenDocuments cumple con las necesidades vitales de integración de la aplicación, pero necesita Office 2003 o 2007 Office system, y sus capacidades son, en cierta medida, limitadas. Los comandos del menú Nuevo no siempre funcionan y, en ocasiones, muestran lo que podrían ser notificaciones de usuario confusas.
Tal como se ilustra en la Figura 3, el control OpenDocuments informa al usuario de que la aplicación necesaria no está correctamente instalada o de que el archivo de plantilla no se puede abrir, pero ninguno de estos es el caso. La función Edit in presenta también problemas. El segundo mensaje de error mostrado en primer plano en la Figura 3 se muestra con frecuencia. Se trata de mi gran favorito, puesto que incluso confunde a los expertos en SharePoint. Volveré a este mensaje en unos momentos.
Figura 3 Mensajes de error confusos del control OpenDocuments (haga clic en la imagen para ampliarla)
No obstante, el control OpenDocuments es útil en entornos con versiones recientes de Office instaladas en todas las estaciones de trabajo. Entre otras cosas, puede ocultar los tipos de contenido del menú Nuevo (acuda a Configuración de la biblioteca de documentos, haga clic en Cambiar orden del nuevo botón y tipo de contenido predeterminado y, a continuación, desactive la casilla Visible de todos los tipos de contenido en cuestión), para que los usuarios no se encuentren con el primer mensaje de error. También puede preservar la sencillez de la topología de su sitio con el objeto de evitar problemas de comunicación del Sistema distribuido de creación y control de versiones web (WebDAV). Esto elimina el segundo mensaje de error.

Comunicación con SharePoint
Hasta el momento, he logrado ampliar la interfaz de usuario de SharePoint y, quizás, iniciar una aplicación por medio del control OpenDocuments, pero mi aplicación necesita aún una manera de comunicarse con SharePoint para obtener acceso a los datos. Como siempre, SharePoint admite distintos métodos para lograr esto, como las Extensiones de servidor de Microsoft Office Frontpage®, las llamadas a procedimiento remoto (RPC) de WSS, WebDAV y los servicios web. De hecho, las aplicaciones de Office, como Word 2007, pueden usar cualquiera o todos estos métodos de comunicación, según cómo obtenga acceso a un documento, por ejemplo, a través de carpetas web, unidades de red asignadas o la interfaz de usuario de SharePoint.
Cada uno de los métodos de comunicación cliente/servidor de SharePoint depende de HTTP como protocolo subyacente. Por ejemplo, FrontPage y las RPC de WSS usan todas las solicitudes HTTP POST y HTTP GET dirigidas a extensiones de ISAPI que residen en servidores de SharePoint en la carpeta %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI y en todas sus subcarpetas.
Una de las extensiones de ISAPI más importantes es Owssvr.dll, que implementa, entre otras cosas, la funcionalidad para trabajar con listas y bibliotecas de documentos. La Figura 4 muestra el cuadro de diálogo Guardar de SharePoint en Word 2007 (izquierda) y en un explorador (derecha) abierto directamente a través de la solicitud de URL http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx. Las similitudes entre las dos capturas de pantalla son obvias.
Figura 4 Cuadro de diálogo Guardar de SharePoint en Word 2007 y en Internet Explorer (haga clic en la imagen para ampliarla)
Otras extensiones de ISAPI importantes son Author.dll, que implementa Frontpage y las RPC de WSS para operaciones de edición del lado cliente, como la carga, el cambio de nombre y la eliminación de documentos, Admin.dll para administrar sitios y realizar otras tareas administrativas, y Shtml.dll para aceptar envíos de formulario HTML.
Generalmente, no es posible agregar la compatibilidad con Frontpage y con las RPC de WSS a aplicaciones existentes, como Bloc de notas o Adobe Reader, sin acceso al código fuente. Pero podría ofrecer el dispositivo de comunicación necesario por medio de la característica Cliente web incluida en Windows.
SharePoint también es compatible con WebDAV a través de Httpext.dll, que reside en la carpeta %WINDIR%\System32\Inetsrv\, pero quedémonos en el lado cliente. Los equipos que ejecutan Windows Server® 2008 o Windows Vista® tienen la característica Cliente web instalada de forma predeterminada. Puede encontrar un servicio WebClient correspondiente en el applet Servicios, en Herramientas administrativas del Panel de control. En Windows XP y Windows Server 2003, debe instalar el Cliente web explícitamente. En todo caso, asegúrese de que el servicio WebClient se ha iniciado y que el Inicio se ha configurado como Automático.
La Figura 5 es una descripción de la arquitectura del Cliente web. El servicio WebClient se implementa en una DLL en modo de usuario (Webclnt.dll) que el Administrador de control de servicios carga en un proceso host Svchost.exe. Webclnt.dll ofrece la interfaz del Proveedor de red para operaciones sin E/S (como autenticar el usuario para el acceso a WebDAV, montar los sitios de SharePoint como unidades de red, enumerar los sitios, las listas y las bibliotecas de documentos de SharePoint como recursos de red, así como desconectar unidades montadas).
Figura 5 Arquitectura del Redirector de cliente WebDAV (haga clic en la imagen para ampliarla)
Para realizar este trabajo, Webclnt.dll se comunica con un controlador del sistema de archivos en modo kernel que ofrece la funcionalidad del redirector. El Controlador del redirector de cliente WebDAV (Mrxdav.sys) se basa en RDBSS, que se integra con el Administrador de E/S y otros componentes del kernel con el objeto de proporcionar los servicios de un sistema de archivos remoto. Mrxdav.sys implementa el dispositivo de comunicación de WebDAV para permitir el acceso de nivel de sistema de archivos a los sitios y las bibliotecas de documentos de SharePoint.
El acceso a los sitios y las bibliotecas de documentos de SharePoint a través de un redirector de red elimina la necesidad de la compatibilidad con Frontpage y RPC de WSS en aplicaciones de usuario. Puede asignar unidades de red a bibliotecas de documentos (como net use x: http://wss/doclib/Shared%20Documents) y también puede obtener acceso a los recursos de SharePoint a través de rutas de acceso UNC.
La dirección URL http://wss/doclib/Shared%20Documents se asigna a \\wss\doclib\Shared%20Documents. Así pues, dispone de varias opciones para abrir un documento en una aplicación. Por ejemplo, puede abrir un documento en el Bloc de notas con la ruta de acceso HTTP http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt o la ruta de acceso UNC \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt.
Desafortunadamente, la característica Cliente web tiene numerosas limitaciones. No se puede obtener acceso a las propiedades personalizadas o las aplicaciones web que usan puertos TCP personalizados. El Cliente web que se incluye en Windows Vista produce errores si el usuario no tiene acceso a un sitio primario en la jerarquía, tal como se ilustra en WebDAV Access.pdf (consulte el material complementario).
La ruta de acceso http://sharepoint/HR/Administration/Shared%20Documents/ incluye un sitio raíz inexistente (que es http://sharepoint) y, sin acceso a la raíz, el Cliente web no puede determinar las capacidades del servidor web. El servidor web rechaza la solicitud OPTIONS del Cliente web con el código de estado 401, que indica que el acceso no está autorizado. Consecuentemente, el Cliente web continúa solicitando las credenciales de usuario, tal como se muestra en la Figura 6, aunque el usuario tenga acceso administrativo a la colección de sitios sharepoint/HR y a todos los sitios incluidos.
Figura 6 Acceso a WebDAV incorrecto (haga clic en la imagen para ampliarla)
Al usar el control OpenDocuments, recibe el mensaje de error mostrado en la Figura 3 si el Cliente web no puede abrir un documento. La aplicación está disponible y la asignación de tipo de documento es correcta. Es el documento al que no se puede obtener acceso a través del redirector de WebDAV.

Implementación de una solución OpenControl personalizada
Generalmente, cuenta con dos opciones a la hora de solucionar los inconvenientes de Cliente web. Puede esperar hasta que Microsoft ofrezca una versión actualizada de Cliente web, o puede implementar una solución OpenControl personalizada capaz de solucionar la situación actual. La implementación de un OpenControl personalizado no es una tarea trivial, pero elimina la necesidad de Office en sus estaciones de trabajo, le permite, además, administrar el comando New y el comando Edit in de manera significativa, y resolver aquellas situaciones en las que el Cliente web produce errores.
Si cualquiera de estos problemas le preocupa, observe el código fuente de AppStart incluido en el material complementario. Muestra cómo exponer las interfaces COM de OpenControl en un ensamblado de Microsoft .NET Framework, al cual puede llamar el código de JavaScript de SharePoint. El código fuente de AppStart también nos muestra una manera posible de comprobar la accesibilidad a los archivos y de descargar un archivo al equipo local a través de HTTP si el acceso directo a través de WebDAV no es posible. Por último, el código fuente de AppStart responde al comando New descargando la plantilla asociada con el tipo de contenido al equipo local para que el usuario pueda empezar a trabajar en el documento. Las hojas de cálculo Text Content Type.pdf y Adobe Reader Support.pdf describen cómo implementar esta solución OpenControl.
El diagrama mostrado en la Figura 7 muestra la arquitectura de AppStart. Mi componente personalizado de OpenControl (denominado Biblioso.dll) expone dos interfaces COM idénticas a las que JavaScript de SharePoint llama para crear nuevos documentos o para abrir y modificar documentos existentes (Biblioso.AppStart.2 y Biblioso.AppStart.3).
Figura 7 Arquitectura de AppStart (haga clic en la imagen para ampliarla)
Si se abre un documento para la modificación, Biblioso.dll comprueba que el archivo existe e inicia la aplicación asociada junto con la ruta de acceso al documento si el archivo es directamente accesible a través de WebDAV. Si el archivo no es accesible, Biblioso.dll inicia un servidor COM fuera de proceso que, a cambio, carga OpenDocsUtility.dll para descargar el archivo a través de HTTP e iniciar la aplicación junto con la ruta de acceso al documento descargado.
El servidor COM fuera de proceso permite a la solución escapar del proceso de Internet Explorer®, el cual restringe las descargas a la carpeta Archivos temporales de Internet en modo protegido. Los usuarios deben contar con la capacidad de descargar archivos sin las restricciones del modo protegido, y un servidor COM fuera de proceso que funcione como un agente de aplicaciones proporciona esta opción.
No es posible el desarrollo de servidores COM fuera de proceso en .NET, por lo que utilicé C/C++ para este ejecutable. Únicamente implementé el indispensable cuadro de diálogo Guardar como en C++. Para que la solución sea lo más sencilla posible y, con el objeto de mantener la sobrecarga de desarrollo en un nivel bajo, coloqué el código de descarga real en un ensamblado de .NET (OpenDocsUtility.dll), al cual llamé, a continuación, a través de otra interfaz COM.
Para facilitar la implementación, agregué un proyecto de instalación a la solución. Entre otras cosas, la rutina de instalación registra todos los componentes COM y escribe la configuración específica de la aplicación en HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Los parámetros más importantes son tanto AllowedApps como AllowedFileTypes. La solución AppStart sólo funcionará con las aplicaciones y los tipos de archivos que debe especificar explícitamente en estos parámetros.
La rutina de instalación también crea una directiva de elevación para el servidor COM fuera de proceso de modo que Biblioso.dll en el proceso de Internet Explorer pueda iniciar AppBrokerEngine.exe sin desencadenar advertencias de seguridad. Si está interesado en conocer más detalles acerca del modo protegido de Internet Explorer y cómo trabajar con ello en el desarrollo de aplicaciones, le recomiendo encarecidamente la lectura del artículo de Marc Silbey y Peter Brundrett "Understanding and Working in Protected Mode Internet Explorer" (en inglés) disponible en msdn2.microsoft.com/bb250462.
Al examinar los componentes de AppStart, tenga en cuenta que esta solución se desarrolló simplemente para mostrar lo que se puede hacer; no está preparada para entornos de producción. No se disponía del tiempo suficiente para optimizar el código y probar la solución de forma exhaustiva, ni para documentar las características, además de los comentarios de código fuente.
Utilizará esta solución bajo su propia responsabilidad. Si está interesado en estudiar el código fuente para crear su propia solución, comience con AppStart.cs en el proyecto de código de Biblioso. Este archivo implementa la interfaz COM de OpenControl y los puntos de entrada para las llamadas de JavaScript desde Ows.js.
Resumen
WSS 3.0 y MOSS 2007 ofrecen amplias capacidades de integración de aplicaciones para una experiencia de usuario sin complicaciones a la hora de trabajar con documentos y otros elementos en bibliotecas de documentos y listas de SharePoint. Las aplicaciones de escritorio en 2007 Office system lo demuestran claramente, y es posible conseguir el mismo nivel de integración y capacidad de uso con aplicaciones ajenas a Office.
En el núcleo de la arquitectura de integración de aplicaciones se encuentran los componentes COM, que las funciones de JavaScript de SharePoint usan, junto con la ruta de acceso al documento, para iniciar la aplicación. 2007 Office system ofrece varios de estos componentes COM, optimizados para las necesidades específicas de las aplicaciones de Office, aunque es también posible volver a usar el control OpenDocuments de Office para integrar aplicaciones ajenas a Microsoft. El control OpenDocuments cubre las necesidades más básicas. Para requisitos de integración de aplicaciones más avanzados, puede implementar un control personalizado.
La completa integración de una aplicación con SharePoint implica no sólo la instalación de los componentes y los iconos de documento de IFilter para ampliar las capacidades de búsqueda y presentación, sino que también implica la creación de tipos de contenido personalizados y asignaciones de tipos de documento en los servidores de SharePoint para ofrecer comandos New y Edit in adecuados en la interfaz de usuario de SharePoint. Estos comandos llaman a las funciones de JavaScript que invocan los métodos expuestos a través de un componente de OpenControl. El componente de OpenControl también debe estar disponible en la estación de trabajo.
Otra pieza importante del puzzle es el Cliente web, incluido e instalado de forma predeterminada en Windows Vista. El Cliente web implementa un redirector de WebDAV y un controlador del sistema de archivos remoto para que cualquier aplicación pueda obtener acceso a los recursos en listas y bibliotecas de documentos de SharePoint semejantes a los recursos compartidos de archivos en la red. Aunque el Cliente web que se incluye con Windows Vista presenta inconvenientes, es una parte esencial de la integración de aplicaciones.
La compatibilidad con WebDAV también sirve de puente entre las aplicaciones que se ejecutan en estaciones de trabajo ajenas a Windows y SharePoint. La tecnología de controles ActiveX y COM no está generalmente disponible en estos sistemas operativos, por lo que no es posible usar componentes de OpenControl para iniciar aplicaciones de forma automática, pero la mayoría de los sistemas operativos incluyen redirectores de WebDAV de forma que los usuarios puedan obtener, al menos, acceso a documentos directamente en bibliotecas de documentos sin tener que descargar los archivos en las estaciones de trabajo locales.
WSS 3.0 y MOSS 2007 son pilares del éxito de 2007 Office system, y los usuarios de aplicaciones basadas en Office de terceros pueden beneficiarse de SharePoint del mismo modo. Las capacidades de integración van mucho más allá de Office. Si desea aprovechar SharePoint al máximo, puede crear una plataforma unificada de soluciones de Office que ofrezca la misma experiencia de usuario para Office y para software de terceros y, como resultado, aumentar la productividad de los trabajadores de la información.

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 y manuales de productos, y libros centrados en operaciones de TI y administración de sistemas. Pav Cherny es presidente de Biblioso Corporation, una empresa especializada en servicios administrados de documentación y localización.


Windows PowerShell El buzón de entrega
Don Jones

Contenido
Personificación del cmdlet
La función de filtrado
Pensamiento físico
Aplicaciones prácticas
Haga tiempo para el juego
En una de las clases sobre Windows PowerShell que impartí hace poco, algunos alumnos tenían problemas para entender en qué consistía la canalización del shell. He de admitir que la canalización no es un concepto totalmente intuitivo y, por lo tanto, los estudiantes pueden tener dificultades para comprender de forma visual qué está ocurriendo exactamente. Cuando llegué al
concepto de las funciones de filtrado, con actividad directa en la canalización, las cosas se complicaron de verdad. Con sólo verles la cara comprendí que los estaba perdiendo.
Para intentar ayudarles, aparecí al día siguiente con una caja, algunas etiquetas adhesivas y varias pelotas de ping-pong. Nadie ha dicho que Windows PowerShell® no pueda ser divertido. Decidí hacerles una demostración mediante la siguiente línea de comandos:
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

Personificación del cmdlet
Con las etiquetas adhesivas (las pegatinas de "Hola, me llamo …" que había que llevar en las reuniones del colegio y en otros eventos igualmente temidos), asigné un nombre de cmdlet a cada estudiante. Les expliqué que las pelotas de ping-pong representaban objetos de proceso de Windows® (más concretamente, los objetos del tipo System.Diagnostics.Process), y les pregunté qué nombre de cmdlet parecía tener más probabilidades de generar objetos de proceso.
Al mirar las etiquetas de los demás, se decidieron por la elección evidente de Get-Process. Este es uno de los principales motivos por los que me gustan los nombres de cmdlet que se usan en Windows PowerShell: son totalmente lógicos.
De forma que el estudiante que llevaba la etiqueta Get-Process tomó todas las pelotas de ping-pong y las colocó en la caja de cartón. La caja representa la canalización del shell, y lo que hizo el estudiante es bastante parecido a lo que hace un cmdlet. Un cmdlet genera uno o más objetos y los vuelca en la canalización.
El siguiente cmdlet de la canalización entra en escena. En este ejemplo, el estudiante que representaba el cmdlet Where-Object tomó todas las pelotas de ping-pong y las examinó, una a una, para comprobar si la propiedad VM de alguna de ellas era mayor que 1.000. En el shell, "VM" significa memoria virtual y, para el propósito del ejercicio, había escrito con rotulador las diferentes cantidades de memoria virtual en cada pelota de ping-pong.
Todas las pelotas (también llamadas procesos) que tenían una VM de 1.000 o superior, se devolvían a la caja (o a la canalización), mientras que las otras, de un valor inferior, se tiraban a la papelera, de donde nunca saldrían. En realidad, eso no es del todo cierto; las recuperé para volver a usarlas en futuras clases.
A continuación, el estudiante que hacía de Sort-Object inspeccionó la caja de pelotas de ping-pong y las ordenó según la propiedad VM. He de admitir que esta parte del ejercicio no estaba muy bien pensada (fue algo difícil evitar que las pelotas saliesen rodando). Creo que tendré que encontrar dados de ping-pong para la próxima clase o tener cartones de huevos a mano.
Para terminar, el alumno que hacía de Export-CSV tomó las pelotas y escribió la información en un archivo CSV. En el mundo real, esto equivalía a escribir las propiedades del proceso en un cuaderno, que representaba el archivo CSV.

La función de filtrado
Una vez que quedó claro qué es una canalización sencilla, decidimos echar un vistazo a las funciones de filtrado, que son un poco más difíciles. Les propuse la función de filtrado y la línea de comandos que aparece en la Figura 1.
Figura 1 Función de filtrado y línea de comandos de ejemplo
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
Antes que nada, me gustaría explicar brevemente para qué sirven las funciones de filtrado. La idea es que la función contiene tres bloques de script, llamados BEGIN, PROCESS y END.
Al usar la función en la canalización, el bloque de script BEGIN se ejecuta en primer lugar. Este script puede realizar cualquier tarea de configuración, como abrir una conexión de base de datos.
A continuación, se ejecuta el bloque de script PROCESS una vez por cada objeto canalizado en la función. En el bloque de script PROCESS, la variable $_ se rellena de forma automática con el objeto de canalización actual. Por lo tanto, si se canalizan 10 objetos, el bloque de script PROCESS se ejecuta 10 veces.
Finalmente, una vez que se han ejecutado todos los objetos canalizados, se ejecuta el bloque de script END, que realiza todas las tareas de limpieza necesarias, como cerrar una conexión de base de datos.
En cualquiera de estos bloques de script, cualquier cosa que se escriba mediante Write-Output acaba en la canalización a la espera del siguiente cmdlet. Cualquier cosa que no se haya escrito mediante Write-Output se descarta.
Ya que el comando comenzaba con Get-Process, nuestro alumno reunió todas las pelotas de ping-pong (mientras nos tomamos un pequeño descanso, las pelotas acabaron misteriosamente desperdigadas por toda la sala) y las colocó en la caja de canalización. Hecho esto, el estudiante con la función de filtrado "Do-Something" entró en acción.
En primer lugar, ejecutó el bloque de script BEGIN. Como estaba vacío, no costó demasiado trabajo. A continuación, tomó todos los objetos de la canalización (las pelotas de ping-pong) y las examinó una a una. Esto resultó bastante divertido, ya que había casi una docena de pelotas y él intentaba mantenerlas todas en su regazo. Era para verlo.
En fin, tomó los objetos de proceso uno a uno y ejecutó el bloque de script PROCESS. Este bloque de script le hizo crear un objeto personalizado totalmente nuevo. Para esto, usé pelotas amarillas especiales, pero no crea que fue fácil encontrarlas en la tienda de deportes. En estas pelotas de ping-pong nuevas, escribió la fecha actual junto al nombre del objeto de proceso que estaba examinando en ese momento.
Este nuevo objeto personalizado se escribió en la canalización, lo que significa que el alumno colocó la pelota de ping-pong amarilla en la caja, y se descartó la pelota de ping-pong que hacía de objeto de proceso original. Realizó este proceso con cada pelota de ping-pong que había en la caja, aproximadamente 12. Al acabar, se habían sustituido todas las pelotas de ping-pong blancas por pelotas de ping-pong amarillas personalizadas. Por último, ejecutó su bloque de script END, que estaba vacío, por lo que no tardó nada.
Para concluir el proceso, entró en escena el estudiante Format-Table. La alumna tomó todo lo que había en la caja (llegados a este punto, sólo había objetos "personalizados" amarillos) y empezó a crear una tabla, con las propiedades escritas en cada pelota. El resultado fue una tabla, escrita en nuestro cuaderno, con dos columnas (TimeStamp y ProcessName) y unas doce filas.

Pensamiento físico
Este ejercicio consiguió que comprendiesen las funciones de canalización y de filtrado perfectamente. Las pelotas de ping-pong hicieron un gran trabajo al representar los objetos, que suelen ser un poco abstractos al hablar del shell.
Todo el mundo acabó por ver cómo los cmdlets manipulaban los objetos, cómo se colocaban los resultados en la canalización y cómo el cmdlet siguiente tomaba dichos resultados y manipulaba los objetos aún más. La secuencia de eventos en una función de filtrado era más evidente, al igual que la técnica de funcionamiento del bloque de script PROCESS (con un objeto de entrada cada vez).
Así, también se demostraba cómo se crea un objeto personalizado nuevo y cómo se coloca en la canalización. Además, ayuda a mostrar las ventajas de producir objetos personalizados en lugar de texto sencillo (otros cmdlets podrían consumir los nuevos objetos personalizados, como Format-Table, lo que ofrece mucha flexibilidad a la hora de usar y representar los datos).

Aplicaciones prácticas
La pregunta lógica de los estudiantes se refería al uso de la canalización y las funciones de filtrado en aplicaciones prácticas. La respuesta me resultó sencilla, ya que había creado varios ejemplos para una conferencia reciente (puede descargar los ejemplos desde scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples).
Uno de los ejemplos tiene la finalidad de enumerar varias propiedades de la clase Win32_UserAccount en el Instrumental de administración de Windows (WMI) a partir de varios equipos. Siempre que los nombres de los equipos aparezcan enumerados en C:\Computers.txt, este sencillo comando lo arreglará todo:
Gwmi win32_useraccount –comp (gc c:\computers.txt)
El problema es que la clase Win32_UserAccount no contiene ninguna propiedad que indique de qué equipo procede cada instancia, de forma que la lista resultante es una mezcla bastante inútil de cuentas procedentes de equipos diferentes. El problema se puede resolver al crear un objeto personalizado nuevo que incluya el nombre del equipo original, además de seleccionar las propiedades de clase de interés. El código para este objeto personalizado aparece en la Figura 2.
Figura 2 Uso de un objeto personalizado para reunir los nombres de equipos y seleccionar las propiedades
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
La línea de comandos final envía todos los nombres de equipos a la función de filtrado, que produce los objetos personalizados. A continuación, se filtran todos los usuarios, salvo aquellos cuya propiedad PasswordRequired sea False (la idea es producir un informe de auditoría de las cuentas problemáticas). Sólo hay que conservar las propiedades Computer y Name, por lo que el informe final es una lista de nombres de equipos y de cuentas que necesitan atención ya que tienen contraseñas que no caducan. La función de filtrado hace posible este informe de varios equipos, porque agrega el nombre del equipo de origen al resultado a la vez que limita las propiedades a aquellas que estoy interesado en ver.
Aunque existen otras formas similares de realizar esta tarea, tal vez este enfoque sea el más sencillo. También sirve para ilustrar conceptos y técnicas importantes.

Haga tiempo para el juego
Incluso aunque no le disguste la canalización, hay una lección que debería aprender. El pensamiento en términos de objetos físicos puede ayudarnos a vislumbrar lo que intentamos hacer.
Por eso, la próxima vez que tenga problemas con un concepto de Windows PowerShell, intente alejarse del equipo y reproducir la tarea mediante objetos cotidianos a modo de ilustración. Le recomiendo que tenga a mano una bolsa con pelotas de ping-pong (o dados, si puede encontrarlos en alguna parte), que son muy útiles para este fin.
Cmdlet del mes Out-File
¿Cuántas veces ha enviado el resultado de un cmdlet a un archivo mediante el símbolo >? Será algo como Get-Process > Processes.txt. ¿Sabía que en realidad lo que está usando es el cmdlet Out-File disfrazado? Aquí puede ver un comando que tiene exactamente la misma función: Get-Process | Out-File Processes.txt.
Evidentemente, este comando requiere más escritura, así que, ¿para qué molestarse en escribir el cmdlet Out-File completo? Un motivo es que Out-File es mucho más claro al leerlo. Suponga que alguien viene seis meses después, echa un vistazo a uno de sus scripts y se pregunta qué significa > (al fin y al cabo, es prácticamente algo heredado).
Por el contrario, Out-File deja claro que se va a crear un archivo y se va a escribir en él. Además, Out-File proporciona el parámetro -append (muy parecido a >>), junto con los parámetros -force y -noClobber, lo que permite controlar si se sobrescriben archivos existentes. Finalmente, al escribir Out-File, también se consigue acceso al parámetro -whatif. Este parámetro de gran utilidad muestra lo que hará Out-File sin que llegue a hacerlo. Es una forma fantástica de probar una línea de comandos complicada sin apenas correr riesgos.
Vídeo
Vea cómo Don Jones pone en acción estos cmdlets.

Don Jones es coautor de Windows PowerShell: TFM e imparte clases acerca de Windows PowerShell (www.ScriptingTraining.com).


Hey, Scripting Guy! Subidón de adrenalina
Los Scripting Guys de Microsoft

No cabe duda alguna de que escribir en TechNet Magazine es el trabajo más importante y gratificante que nadie pueda tener en el mundo. Por supuesto, sería aún mejor si nos pagaran por ello, pero eso es otra historia. ¿Cómo de prestigioso es este trabajo? Digámoslo así: en estos momentos, a lo largo y ancho del mundo, hay miles de niños que, antes de dormir, miran a sus madres y les confiesan: "Mami, cuando sea mayor, quiero escribir una columna mensual de scripting en TechNet Magazine".
Nota Bueno, también hay gente de todo el mundo que cree que la columna realmente la escriben niños. Pero, de nuevo, eso es otra historia.
Ya se sabe que a los Scripting Guys nos encanta recibir más y más halagos, fruto de nuestro trabajo para TechNet Magazine; hasta hemos aprendido a convivir con paparazzis y cazadores de autógrafos. Pero lo cierto es que no hacemos este trabajo por la fama y la gloria; lo hacemos porque nos gusta sentir el subidón de adrenalina que implica escribir scripts de administración de sistemas.
De acuerdo, no es muy común que los términos "scripts de administración de sistemas" y "subidón de adrenalina" aparezcan en la misma frase. A no ser, eso sí, que el subidón de adrenalina se refiera a la ausencia total y completa de dichos scripts.
El usuario medio cree que la administración de sistemas es una tarea realmente útil pero probablemente no demasiado excitante; incluso es posible que el scripting le parezca algo bastante latazo. Sin duda, este es el motivo: estas personas no han probado a escribir scripts de datos de configuración de arranque del sistema en Windows Vista® o en Windows Server® 2008.
Oh, sí, eso le ha acelerado el pulso un poco, ¿verdad? Como la mayoría de los que leen estas líneas probablemente ya sepan, en Windows Vista y Windows Server 2008, ya no se usa el antiguo archivo boot.ini, sino que se incluye un nuevo almacén de datos de configuración que proporciona una mayor flexibilidad (y más capacidades) a la hora de administrar el proceso de arranque del sistema.
Eso está muy bien. Pero lo realmente interesante es esto: gracias a un nuevo proveedor WMI (Windows® Management Instrumentation o Instrumental de administración de Windows) y, por medio scripts, ahora puede obtener acceso al almacén de datos de configuración de arranque (BCD) del sistema de un modo sencillo y completamente administrado.
No se extrañe si un escalofrío le recorre la columna de arriba abajo; eso es exactamente un subidón de adrenalina. Una vez que empiece a trabajar con los scripts de BCD, se irá acostumbrando.
Antes de ir más allá, debemos señalar que no podremos cubrir todos los usos posibles del proveedor BCD, al menos no en esta sola columna. Enviamos un correo electrónico a la redacción sobre la posibilidad de realizar un número doble especial dedicado completamente a los scripts de datos de configuración de arranque del sistema, pero aún no hemos recibido respuesta.
Si desea obtener información más completa, consulte la documentación del proveedor WMI de BCD en go.microsoft.com/fwlink/?LinkId=116953. Mientras tanto, le enseñaremos código muestra, diseñado para equipos de arranque múltiple, equipos con varios sistemas operativos.
Por cierto, estos scripts sólo funcionan en Windows Vista y Windows Server 2008. Se debe a que, como decíamos antes, son los únicos sistemas operativos compatibles en la actualidad con BCD.
Comencemos echando un vistazo al script que nos informa del sistema operativo en uso en el equipo. De acuerdo, es cierto que no se trata del uso más interesante del proveedor BCD; al fin y al cabo, también se puede usar la clase WMI Win32_OperatingSystem para determinar el sistema operativo en uso de un equipo. Sin embargo, este es un script bastante sencillo (al menos en lo que a scripts de BCD se refiere) y proporciona un buen método para ilustrar las técnicas básicas necesarias para trabajar con BCD. Técnicas que son, al menos, no tan "comunes".
Además, nuestras columnas no pueden ser excesivamente divertidas: TechNet Magazine ya nos ha advertido que seremos directamente responsables por cualquier perjuicio causado por enfervorizados seguidores sobreestimulados de Hey, Scripting Guy! Teniendo en cuenta las serias repercusiones que originó nuestra columna acerca de las expresiones regulares por todo el mundo, bueno... no nos podemos arriesgar a escribir algo tan excitante de nuevo.
Nota ¿No se acuerda de todos esos vídeos de los Beatles acosados por los fans? Todas esas imágenes de chicas gritando y llorando por John, Paul, George y Ringo... Eso se parece mucho a lo que nos pasa cuando publicamos una nueva columna.
Bueno, vale, quizás sea exagerar un poco. Aunque no cabe duda de que hay un montón de gente (hombres y mujeres por igual) que llegan a llorar de emoción al leer nuestras columnas.
En cualquier caso, eche un vistazo al script de la Figura 1, que usa el proveedor BCD para determinar el SO actualmente en uso en un equipo. Antes de que intente ejecutar el script, tenga en cuenta que debe hacerlo como administrador; de lo contrario, se producirá un error.
Figura 1 Detección del sistema operativo actual
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
Y no, eso no significa que necesite iniciar sesión con una cuenta con privilegios de administrador. Significa que necesita abrir una ventana del símbolo del sistema (haga clic con el botón secundario en Símbolo del sistema, en el menú Inicio), y seleccionar Ejecutar como administrador. De este modo, ya puede ejecutar el script en el símbolo del sistema.
¿Cómo funciona este script? Ya nos temíamos que haría esa pregunta. Está bien; intentaremos explicarlo lo mejor que podamos (pero intentaremos dejar el nivel de excitación lo más bajo posible).
Comenzamos definiendo dos constantes: BcdLibraryString_Description y Current. BcdLibraryString_Description hace referencia al objeto que deseamos recuperar. En este caso, el objeto contiene la descripción (nombre) del sistema operativo actual.
Esta es, por cierto, una de las peculiaridades de trabajar con el proveedor BCD. Normalmente, no nos limitamos a recuperar el valor de una propiedad, sino que usamos uno de estos valores de constantes (junto con el método GetElement) para recuperar otro objeto y, a continuación, hacer eco del valor de una propiedad que pertenece a dicho objeto. Parece obvio, pero ya sabe lo que se dice: llegar es sólo la mitad del camino.
Nota Lo que de algún modo le hace preguntarse hacia dónde se dirigía en realidad, ¿no?
En lo que respecta a la constante Current, bueno, es sólo un GUID que representa el sistema operativo en uso. El valor
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
se considera un GUID "conocido" (una muestra del sano sentido del humor de Microsoft).
A pesar del hecho de que se trata de un GUID bastante común, decidimos incluir el valor de todos modos, sólo por si algún lector no recuerda exactamente cuál de los siguientes dos valores es el correcto:
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
Nota Quizás le interese saber que GUID se puede pronunciar como "gu idé" o "gu aidí". Podríamos darle mucha más información, como que el GUID anterior debe ser un GUID V1, ya que el tercer grupo de dígitos comienza por un 4 pero, como prometimos, tenemos que mantener el nivel de emoción al mínimo. Y nosotros cumplimos nuestras promesas.
Como puede que haya adivinado, tendrá que usar constantes, valores hexadecimales y GUID por todas partes cuando trabaje con el proveedor BCD. No podemos hablar de todos estos elementos en la columna de este mes, pero puede visitar la página de BCD que mencionamos antes, en MSDN® (go.microsoft.com/fwlink/?LinkId=116953) para obtener más información. Si puede soportar altos niveles de excitación, claro.
Después de definir nuestras dos constantes, conectamos con el servicio WMI en el equipo local. ¿Se puede usar este script para recuperar los datos de configuración de arranque de un equipo remoto? Por supuesto que sí.
Para ser sinceros, si no pudiera, todo esto de BCD tendría una utilidad bastante limitada. Para recuperar los datos de configuración de arranque de un equipo remoto (de nuevo, el equipo remoto debe ejecutar Windows Vista o Windows Server 2008), sólo tiene que asignar el nombre del equipo a la variable strComputer:
strComputer = "atl-fs-001"
también debemos señalar una serie de elementos clave en nuestra cadena de conexión de WMI. Para empezar, quizás se haya dado cuenta de que hemos incluido los privilegios de copia de seguridad y restauración en nuestra cadena de conexión; esa es la función de la construcción {(Backup,Restore)}. ¿Es esto importante? Bueno, si desea que el script funcione, es muy importante: si no incluye de forma explícita estos dos privilegios, el script provocará un error.
En segundo lugar, debe tener en cuenta que no se realiza una conexión con el espacio de nombres root\cimv2, el más común dentro de los scripts de administración de sistemas. En su lugar, conectamos con el espacio de nombres root\WMI y enlazamos directamente con la clase BCDStore. Esa es la función de este fragmento de código:
"\root\wmi:BcdStore"
Y no, todavía no hemos llegado a la parte emocionante. Lo realmente divertido aún no ha hecho acto de presencia.
Quizás con un par de excepciones, la mayor parte de los scripts de BCD que escriba empezarán con los mismos tres pasos: definir las constantes, conectar con el servicio WMI y, finalmente, abrir el almacén BCD. Ya hemos realizado los pasos 1 y 2. La siguiente línea de código se encarga del paso 3.
objStoreClass.OpenStore "", objStore
Como decíamos, ahora tenemos que abrir el almacén BCD: la entidad del sistema operativo que almacena toda la información de configuración de arranque. Para abrir el almacén, sólo tenemos que llamar al método OpenStore, con estos dos parámetros de métodos:
  • Una cadena vacía (""). Esto indica al script que deseamos abrir el almacén predeterminado.
  • objStore. Este es un parámetro "out" que proporcionamos al script. Damos al método el nombre de una variable y, como muestra de agradecimiento, el método nos devuelve un objeto (que, en este caso, representa el almacén BCD) que usa este nombre de variable como referencia de objeto.
Tan pronto como se abre el almacén, ya se puede usar el método OpenObject para recuperar otro objeto (almacenado en el parámetro out objDefault):
objStore.OpenObject Current, objDefault
¿Y qué cree que es este nuevo objeto? Exacto: el sistema operativo en uso actualmente. Lo sabemos porque transferimos al método OpenObject la constante Current, el famoso GUID que representa el sistema operativo actual.
Muy bien, así que ya sabemos el sistema operativo actualmente en uso en el equipo, ¿verdad? Bueno, casi. Para obtener esta información, aún tenemos que usar GetElement para recuperar un objeto que represente el elemento Description de dicho sistema operativo.
objDefault.GetElement _
  BcdLibraryString_Description, objElement
¿Promete que no se excitará demasiado y provocará algún tipo de desorden público? Bien. En ese caso, le contaremos que ahora podemos hacer eco del valor de la propiedad String para, por fin, determinar el sistema operativo actualmente en uso del equipo:
Wscript.Echo "Current operating system: " _
  & objElement.String
Por favor, cálmese. Recuerde su promesa: nada de altercados. Ya, sabemos que es difícil.... Contrólese como buenamente pueda. Respire profundamente; a nosotros eso siempre nos da resultado cuando escribimos scripts de BCD.
Como decíamos, determinar el sistema operativo actualmente en uso de un equipo implica realizar una serie de tareas más o menos complicadas, pero hay formas más sencillas de lograr el mismo resultado. Si lo mira por el lado bueno, ahora ya sabe cómo funciona un script de BCD, lo que significa que, a partir de ahora, puede hacer cosas que los creadores de scripts nunca han sido capaces de hacer. (Tranquilo... no se altere...) Por ejemplo, en un equipo de arranque múltiple, siempre hay un sistema operativo identificado como "predeterminado". Si el equipo se reinicia, se cargará de forma automática el sistema operativo predeterminado, si no hay nadie cerca que indique lo contrario. Antes de Windows Vista (y del proveedor BCD), no había ninguna forma de que un script identificara el sistema operativo predeterminado de un equipo. Ahora, sin embargo, es tan sencillo como ejecutar un script como el de la Figura 2.
Figura 2 Detección del sistema operativo predeterminado
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
Sí: esto se merece al menos una pequeña ola de agitación, ¿no? Pero que no tenga mucha altura, ¿de acuerdo? No vamos a explicar este script en una profundidad excesiva: si no se ha saltado los últimos 10 ó 12 párrafos, ya debería ser capaz de analizar la parte lógica por sí mismo. Verá, sin embargo, que, para obtener el sistema operativo predeterminado, hemos introducido un paso intermedio: hemos tenido que usar el método OpenObject para abrir una instancia del objeto del administrador de arranque. Después de abrir el administrador de arranque, podemos usar la constante DefaultType para recuperar un objeto que representa el sistema operativo predeterminado.
Ahora sí. Admitámoslo. Esto sí que pone los pelos de punta: podemos determinar el sistema operativo actual e incluso podemos ver cuál es el predeterminado. Pero... ¿sabe lo que estaría bien de verdad? Obtener una lista de todos los sistemas operativos instalados en un equipo. ¡Eso sí que sería espectacular! Agárrese bien y fíjese en la Figura 3.
¿Qué estamos haciendo en este caso? Bueno, para empezar, definimos dos constantes nuevas: WindowsImages, que nos permite recuperar instancias de todos los sistemas operativos compatibles con BCD (o sea, Windows Vista y Windows Server 2008), y LegacyImages, que nos permite recuperar instancias de los sistemas operativos "heredados" del equipo. Tras conectar con el almacén BCD, usamos el método EnumerateObjects para recuperar todas las instancias de los sistemas operativos compatibles con BCD instalados en el equipo:
objStore.EnumerateObjects _
  WindowsImages, colObjects
Figura 3 Obtención de todos los sistemas operativos de un equipo
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Después de que EnumerateObjects haga su trabajo, deberemos configurar un bucle For Each que pase por todos los sistemas operativos de dicha recopilación. Dentro de este bucle, usamos estas dos líneas de código para recuperar y, a continuación, mostrar el elemento Description, referente al sistema operativo:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
A continuación, repetimos el proceso para todos los sistemas operativos heredados que haya instalados en el equipo:
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Nota Sabemos que pedimos mucho, pero trate de hacer un uso responsable de sus scripts de BCD; es más que probable que haya un límite para la cantidad de adrenalina que puede soportar un cuerpo humano. Las mujeres embarazadas, las que estén pensando en quedarse embarazadas, las que en algún momento hayan estado embarazadas, las que nunca vayan a estar embarazadas e incluso las que no sean mujeres, sino hombres, no deberían usar scripts de BCD sin consultar antes con su médico.
Venga, está bien, no hace falta que hable con su médico. Pero sería interesante conocer la opinión de un médico respecto a la ejecución de scripts de BCD, ¿verdad?
Ahora vamos a tirar la casa por la ventana: vamos a intentar cambiar el sistema operativo predeterminado. Por ejemplo, suponga que tenemos un equipo de arranque dual que ejecuta Windows Vista y Windows Server 2008, y queremos que Windows Vista sea el sistema operativo predeterminado. ¿Cómo podríamos hacer eso? Eche un vistazo a la Figura 4. Muestra una forma de llevar a cabo esta tarea.
Figura 4 Cambio del sistema operativo predeterminado
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
Con este script, de nuevo abrimos el almacén BCD para, a continuación, usar el método EnumerateObjects para recuperar una recopilación de todos los sistemas operativos compatibles con BCD que están instalados en el equipo. Seguidamente, configuramos un bucle For Each para que pase por todos los elementos de la recopilación, mediante la siguiente línea de código (que ya parece familiar), para recuperar el elemento Description de cada sistema operativo:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Tan pronto como obtenemos dicho elemento para un sistema operativo determinado, usamos la función InStr para ver si la palabra Vista aparece en dicho valor:
If Instr(objElement.String, "Vista") Then
Tiene razón, parece un poco "precario", ¿no? Lo interesante sería usar el GUID de Windows Vista y abrir directamente el sistema operativo sin tener que enumerar y pasar por todos los sistemas operativos del equipo.
Por desgracia, este método tan atractivo requiere que conozcamos el GUID de Windows Vista. En cambio, de este modo, no hace falta saber nada (lo que es siempre un plus para los Scripting Guys); todo lo que tenemos que hacer es buscar hasta que encontremos un sistema operativo con la palabra Vista en el título.
Nota ¿Qué pasa si hay varias versiones de Windows Vista instaladas en un mismo equipo? Bueno, en ese caso, deberemos buscar una cadena como Vista Ultimate o Vista Enterprise.
En cuanto encontremos Windows Vista, usamos estas dos líneas de código para abrir el administrador de arranque de Windows y, a continuación, establecemos el sistema operativo predeterminado en Windows Vista:
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
Sólo tenemos tiempo para esto este mes; después de todo, ni siquiera los mismos Scripting Guys tienen la capacidad de lidiar con estos niveles de agitación las 24 horas del día, los 7 días de la semana. Pero no se preocupe, volveremos el mes que viene con otra emocionante entrega de Hey, Scripting Guy! Con algo de suerte, se habrá recuperado para entonces.
Dr. Scripto's Scripting Perplexer
El desafío mensual que prueba no sólo sus habilidades para resolver rompecabezas, sino también sus habilidades para el scripting.

Julio de 2008: cuadrados de VBScript
Vale, parecen más rectángulos, no cuadrados, pero eso da igual. Para resolver este puzzle, coloque todos los cuadrados de la derecha en los cuadrados vacíos de la izquierda con el fin de crear los nombres de las funciones VBScript. Cada cuadrado sólo se puede usar una vez. Por ejemplo:
para resolver correctamente este puzzle, tiene que mover el cuadrado OU (bueno, rectángulo) al cuadrado en blanco de la primera palabra, y MS y OX a los cuadrados en blanco de la segunda palabra. Esto crea las funciones UBound y MsgBox de VBScript, como aparece aquí:
Su turno:

RESPUESTA:
Dr. Scripto's Scripting Perplexer
Respuesta: Cuadrados de VBScript, julio de 2008

Los Scripting Guys trabajan para... bueno, son empleados de Microsoft. Cuando no están jugando o viendo béisbol (entre otras muchas actividades), dirigen el TechNet Script Center. Visite la página web www.scriptingguys.com.


Archivos del escritorio Windows con arranque en red
Wes Miller

Contenido
Funcionamiento de PXE
Análisis de RIS
WDS, el comienzo
Otros reproductores
Conclusión
Durante los próximos meses, tengo intención de analizar los Servicios de implementación de Windows (WDS), disponibles para Windows Server 2003 e integrados en Windows Server 2008. WDS puede ser un componente muy importante en su infraestructura de implementación, por lo que me gustaría asegurarme de que dispone de una buena base para la discusión. En este
primer artículo, exploraremos la arquitectura del entorno de ejecución previo al arranque (PXE), la historia de los Servicios de instalación remota (RIS), además de otras tecnologías relacionadas con PXE que se usan en Microsoft.
Cuando me trasladé al grupo de sistema operativo principal de Windows en 2001, RIS fue una de las tecnologías que heredé (me daba algo de miedo que fuese así, debido a su complejidad y a la dependencia de las implementaciones de BIOS y del hardware). Sin embargo, fue, junto con Windows® PE, una de las tecnologías con las que más disfruté mientras desempeñaba mi función como administrador de programas.
Recuerdo la primera vez que instalé Windows 3.0 (mediante un conjunto de disquetes de 3,5 pulgadas). Con el paso del tiempo, la instalación se hizo cada vez más fácil gracias a los CD de arranque (incluidos en algunas versiones de Windows 98). La cuestión era que la instalación siempre necesitaba medios locales de algún tipo, además de un disco duro local.
Con el paso de los años, la capacidad de arrancar Windows en red (es decir, realizar el arranque completamente desde la red sin necesidad de disco duro) ha sido una solicitud muy frecuente por parte de los clientes. Aunque algunas de las primeras versiones de Windows disponían de esta capacidad, no era el caso de Windows NT®. Además, aunque las versiones actuales de Windows Server® 2003 y Windows Server 2008 se pueden arrancar a través de un iniciador iSCSI, el proceso es muy distinto, en el sentido de que no es realmente local (implica una dependencia continua de una unidad remota como unidad de arranque).
Preorganización de clientes
  • Evaluación del proceso de preorganización de clientes de RIS
  • Planeación de mejoras de la seguridad de red mediante clientes preorganizados
  • Preorganización de equipos cliente
  • Instalación remota de sistemas operativos
Desde Windows 2000, Microsoft empezó a desarrollar la tecnología que, finalmente, se llamaría RIS y que permitiría la instalación basada en red. La finalidad de RIS era relativamente sencilla: colocar una imagen de sistema operativo en el disco local del equipo de destino mediante PXE.

Funcionamiento de PXE
La Figura 1 muestra la secuencia de arranque de PXE. PXE es un protocolo relativamente sencillo que desarrollaron Intel y otros proveedores como parte de la iniciativa Wired for Management. PXE se deriva del Protocolo de configuración dinámica de host (DHCP), que, a su vez, se deriva de BootP y se suele implementar en la tarjeta de la interfaz de red (NIC). En resumen, esto es lo que ocurre:
Figura 1 Secuencia de arranque de PXE (haga clic en la imagen para ampliarla)
Paso 1 Se inicia el BIOS del sistema, que determina el orden de arranque.
Paso 2 Si el orden de arranque establece PXE por delante de los discos duros, unidades flash o CD-ROM, o si no están presentes ninguno de estos dispositivos, se carga la interfaz del controlador de red universal (UNDI) de la NIC. La NIC ofrece un controlador de dispositivos de red muy pequeño y una implementación del Protocolo trivial de transferencia de archivos (TFTP). Algunas implementaciones de BIOS requieren que los usuarios presionen la tecla F12 para arrancar PXE. Esto no es obligatorio y se puede desactivar.
Paso 3 El sistema comienza a realizar una difusión simple del Protocolo de datagramas de usuario (UDP), en busca de un servidor DHCP. Este es realmente el primer paso de la secuencia de arranque de PXE: la detección. Observe que el protocolo es UDP (lo que significa que, si aún no lo ha hecho, deberá emplear bastante tiempo con los enrutadores y conmutadores para asegurarse de que se pueden realizar las comunicaciones de PXE).
Paso 4 Si un servidor DHCP recibe la difusión, responde en consonancia con una dirección IP. Se trata del paso de ofrecimiento. Hay que tener en cuenta que PXE no tiene estado y que la cantidad de información de estado específica del sistema que puede ofrecer el cliente en este punto es muy limitada (la dirección MAC y, si está disponible, el GUID del BIOS de Administración del sistema, también conocido como GUID de SMBIOS).
Paso 5 El cliente, tras recibir el paquete con la dirección IP, establece que necesita más información (en particular, la dirección del servidor PXE). Se produce otra difusión, que contiene la información procedente del servidor DHCP que respondió originalmente. El cliente indica al servidor DHCP: "Necesito más información; en concreto, necesito la ubicación de un programa de arranque en red". Este es el paso de solicitud.
Paso 6 El servidor PXE responde con la dirección del servidor PXE y la ubicación del programa de arranque en red (NBP), un ejecutable de arranque extremadamente pequeño que debe ocupar menos de 32 KB. Este es el paso de reconocimiento.
Observe que, si ha instalado Microsoft DHCP y WDS (o ha usado las tecnologías de otro proveedor), se omite el paso de solicitud y, de hecho, el paquete de ofrecimiento original del servidor DHCP contiene ya la ubicación del servidor PXE y del programa NBP (por lo que se eliminan dos pasos, y se ahorra tiempo).
Paso 7 El cliente, que tiene la pequeña pila del protocolo TFTP que mencionamos anteriormente, descarga el NBP de la ubicación de la red que indique el servidor PXE. TFTP es un protocolo antiguo, muy pequeño y sin estado. No ofrecía buenos niveles de seguridad ni rendimiento (y, por ello, muchos administradores de enrutadores lo desactivan de forma predeterminada). Debe estar habilitado para que PXE funcione.
Muchas implementaciones de PXE (incluido RIS) incluyen la capacidad de solicitar al usuario que presione F12 para continuar al llegar a este punto, pero el administrador del servidor PXE suele poder desactivarla. El próximo mes, cuando seguiremos hablando de WDS, echaremos un vistazo a algunas de las mejoras que Microsoft ha incluido en el TFTPD (demonio TFTP) de WDS para Windows Server 2008 con el fin de mejorar el rendimiento.
Paso 8 Se inicializa NBP. En el caso de RIS, esto inicia un cargador de arranque de Windows que inicia el proceso de avanzar la implementación. PXE (al menos el protocolo de nivel de arranque) ya no es un componente del proceso.
Es importante recordar que PXE (RIS, WDS o cualquier otra infraestructura) no funciona correctamente con vínculos lentos (puede enviar cantidades considerables de datos) o vínculos de alta latencia, como satélites (la comunicación no se realiza correctamente y puede que ni siquiera sobreviva).
Tal vez observe en el proceso de arranque de PXE que, cuando el cliente envía la solicitud, no hay nada que pregunte específicamente: "¿Eres mi madre?" No hay mucha información de estado que permita al servidor PXE averiguar la respuesta. Generalmente, se produce una condición de carrera (en la que el primer servidor que responda a la solicitud del cliente es el ganador). Hay un par de formas de mitigar este problema:
  • Ajuste la velocidad de respuesta de uno de los servidores PXE. La latencia de la red y la eficacia del servidor afectarán a la velocidad de respuesta de los servidores. De hecho, en Microsoft, los servidores que usaba Microsoft IT solían ser tan buenos que, incluso aunque el servidor PXE estuviese en la oficina, los servidores de la empresa ganaban en algunas ocasiones. En este caso, sólo tiene que configurar su servidor PXE local para que no tenga límite de tiempo de espera (con respecto a los clientes preorganizados).
  • Preorganice los clientes. Esto es algo muy importante al manipular el servidor PXE para que responda antes que otros servidores de TI de la empresa. Al preorganizar los clientes, permite que Active Directory® comunique a WDS o a RIS que sí, "Yo soy tu madre". Observe que se prefiere el uso del GUID de SMBIOS como identificador exclusivo para los sistemas en Active Directory, pero si un GUID de SMBIOS no está implementado en los sistemas (especialmente en hardware relativamente antiguo), puede (y tendrá que) usar un GUID basado en la dirección MAC. Para obtener más información, consulte la barra lateral "Preorganización de clientes".
  • No deje que las comunicaciones de PXE atraviesen conmutadores o enrutadores; coloque un servidor PXE a cada lado. El inconveniente es que resulta muy caro de implementar y de mantener (hay que mantener las imágenes de todos los servidores).
Los servidores RIS (y ahora WDS), al igual que los servidores DHCP de Microsoft, se deben autenticar con la implementación de Active Directory a la que están asociados. El objetivo es reducir los problemas que pueden provocar los servidores PXE no autorizados (como tormentas de difusión de PXE) mediante la información a Active Directory acerca de estos servidores.
Observe que esto sólo ofrece protección frente a los servidores que conozca Active Directory. Al establecer su propio dominio, o un servidor PXE ajeno a Microsoft, este no será el caso.
En Microsoft, hubo una vez un empleado entusiasta que configuró un servidor PXE sin RIS con una implementación sin interacción. Esta implementación funcionaba mediante el borrado del disco duro y la implantación de una imagen nueva. Esto habría estado bien si la implementación se hubiera llevado a cabo en un laboratorio aislado (sin red) pero, por desgracia, no fue el caso (y acabó borrando el disco de un ejecutivo de Microsoft que tenía PXE en la orden de arranque antes que el disco duro.
Eso no habría supuesto un problema, ya que Microsoft IT siempre solicitaba el uso de F12 para arrancar PXE, pero este servidor PXE no tenía demora, solicitud de F12 ni ningún otro tipo de notificación. Esto hizo que el ejecutivo realmente perdiese el equipo y todos los datos que no estaban protegidos por su perfil de usuario móvil.
Espero que esta historia le sirva para darse cuenta de la necesidad de aislar los servidores PXE al proceder sin interacción o, por lo menos, solicitar que se presione F12.

Análisis de RIS
Heredé RIS después de que se lanzase Windows 2000. La vida de Windows 2000 no fue fácil en lo que a RIS se refiere. Las pruebas, el rendimiento y otras limitaciones hicieron que RIS sólo se usase con Windows Server 2000 para la implementación de Windows 2000 Professional. Los productos de servidor, por desgracia, no se podían implementar a través de RIS. Windows 2000 sólo estaba disponible para equipos x86, por lo que demostró ser un buen banco de pruebas para RIS, ya que implicaba un producto en una arquitectura. RIS incluía (y necesitaba) integración completa con Active Directory, integrada en el servidor DHCP de Microsoft, e incluía su propio TFTPD.
RIS usa el NBP para continuar la descarga de TFTP y desactivar suficiente kernel de Windows para iniciar el proceso de instalación. En un punto concreto, una vez que Windows ha cambiado de TFTPD a una conexión basada en un bloque de mensajes de servidor, o SMB, al servidor, se comparte la ruta de acceso literal al código con una instalación iniciada desde un disquete tradicional de Windows 2000 o Windows XP. Una vez que se ha inicializado el modo nativo de Windows, el programa de instalación de Windows inicia el asistente del selector de sistema operativo (OSC) de RIS.
Las pantallas de OSC son algo configurables, parecidas a páginas de HTML 2.0. Están muy limitadas y no pueden contener imágenes ni nada parecido y, de hecho, no pueden contener caracteres distintos de ANSI (lo que complicaba la implementación de algunas configuraciones regionales de Windows).
El producto final de RIS es un archivo txtsetup.sif que se implanta en el servidor RIS. Cuando finaliza el asistente del selector de sistema operativo, se reinicia parcialmente el cliente, pero la ubicación del servidor RIS y del archivo txtsetup.sif se retienen y se vuelven a cargar tras el reinicio parcial. El archivo txtsetup.sif es básicamente igual que un archivo unattend.txt, con varios campos adicionales para ayudar a RIS a finalizar el proceso de instalación.
RIS también podría realizar un proceso de instalación parecido a la instalación desatendida tradicional (RISetup), y tenía una infraestructura basada en clonación similar a Sysprep (RIPrep) y, de hecho, compartían código. Sin embargo, RIPrep también podía cargar una imagen suya en un servidor RIS.
No obstante, RIS tenía una serie de limitaciones fundamentales que se hicieron evidentes. La primera era la falta de compatibilidad con la implementación de servidores. Algunos ataques, como Code Red y Sasser, combinados con las complejidades de TI que algunos clientes clave experimentaron tras recuperarse de la tragedia del 11 de septiembre de 2001, nos llevaron a buscar rápidamente una solución para los servidores RIS con Windows 2000 existentes que permitiesen la implementación de Windows Server. Habíamos estado trabajando en esto para Windows Server 2003, pero no se había publicado formalmente.
Más información acerca de las tecnologías relacionadas con PXE
  • Descripción de la interacción PXE entre el cliente PXE, DHCP y el servidor RIS
  • Planeación para las implementaciones de sistemas operativos iniciadas en PXE
  • Arquitectura PXE
  • Servicios de instalación remota
  • Instalación remota de sistemas operativos
  • Guía detallada para la instalación remota de sistemas operativos
  • Proveedor PXE de WDS
  • ¿Qué son los Servicios de instalación remota?
  • Windows Server 2003 Automated Deployment Services
En segundo lugar, RIS no disponía de la capacidad de automatizar el asistente del selector de sistema operativo, función que se habilitó posteriormente con el elemento <META ACTION="AUTOENTER"> en Windows Server 2003. Finalmente, el programa selector de sistema operativo no funcionaba correctamente con caracteres distintos de ANSI (una carencia clave por la que se quejaron muchos clientes fuera de Estados Unidos).
En consecuencia, no se podía completar una instalación RIS con un teclado francés, por ejemplo. Conseguir que los caracteres distintos de ANSI funcionasen correctamente a nivel del BIOS en los equipos de todo el mundo era una tarea extremadamente compleja y nada fácil de conseguir.
Con el lanzamiento de Windows Server 2003, agregamos formalmente compatibilidad con la arquitectura de Intel Itanium y todas las variantes de servidores de Windows 2000 y Windows Server 2003. Windows Server 2003 llegó más allá con la compatibilidad con la arquitectura x64.
También se incluyó en RIS un TFTPD modificado de forma significativa para mejorar el rendimiento. Windows Server 2003 permitía arrancar hasta 75 clientes a la vez. Tenga en cuenta que se alcanza el límite cuando la canalización SMB se llena con el tráfico de red de los clientes.

WDS, el comienzo
Cuando empezamos a trabajar con RIS en "Longhorn" (nombre en código para Windows Server 2008), se hizo evidente que teníamos que retroceder sobre nuestros pasos. Como ya mencioné en mi artículo anterior, ya teníamos muchas expectativas relacionadas con la instalación basada en imágenes (WIM) de Windows PE. Como resultado, el principio básico que hacía de base para WDS era la implementación basada en imágenes de una versión arrancada en PXE de Windows PE.
También sabíamos que Windows Server 2003 sería la plataforma común para la implementación de Windows Vista®, y que necesitaríamos una solución "fuera de banda" para el nivel inferior de WDS. Como resultado, WDS se podía ejecutar en Windows Server 2003 SP1 y se integró en Windows Server 2003 SP2.
Ya que puede actuar como servidor RIS (modo heredado), servidor híbrido (modo mixto) o servidor sólo WDS (modo nativo), WDS permite migrar a implementaciones formales al estilo de WDS cuando se necesita. Muchos clientes han preguntado si hay alguna forma de instalar RIS en un sistema con Windows Server 2003 SP2. Sí, la hay (se instala WDS y se ejecuta en modo heredado). La Figura 2 muestra los sistemas operativos compatibles.
Figura 2 Plataformas compatibles para la implementación
Sistema operativo | RIS (Windows 2000) | RIS (Windows Server 2003)** | WDS (Windows Server 2003)**** | WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X (x86 e IA64)*** | X | X
Windows Server 2003 |  | X (x86 e IA64)*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* support.microsoft.com/kb/308508 y support.microsoft.com/kb/313069 agregaron compatibilidad para Windows 2000 Server a través de RIS. ** Los modos heredado y mixto de WDS admiten esta misma matriz para las instalaciones heredadas. *** Windows Server 2003 SP1 agregó compatibilidad con los sistemas basados en x64. Los sistemas IA64 sólo admitían la instalación basada en RISetup. **** Compatibilidad con el modo nativo.
La finalidad de WDS en Windows Server 2003 SP1 y SP2 era iniciar el proceso de migración a WDS. Como ya mencioné, las características clave que WDS agregó en Windows Server 2008 consistían en un TFTPD revisado, compatibilidad de arranque para EFI (Extensible Firmware Interface) y, por supuesto, la implementación basada en multidifusión.

Otros reproductores
El desarrollo de ADS quedó en manos de otro equipo de Microsoft, con el objetivo principal de conseguir el aprovisionamiento acelerado del servidor. ADS ofrecía imágenes formales basadas en sectores, su propio agente de arranque (más pequeño que Windows PE, pero sin una funcionalidad tan completa), su propio TFTPD y capacidad de multidifusión muy avanzada. La funcionalidad integrada en ADS sólo estaba disponible parcialmente en System Center Configuration Manager (SCCM), aunque no hay un 100% de paridad en cuanto a las características.﻿
Windows XP Embedded incluía un arranque con PXE completo a través de su propio TFTPD en un disco RAM, pero no se podía implementar de forma remota de este modo. La tecnología estaba diseñada para permitir el arranque de muchos sistemas desde la misma imagen de disco a la vez a través de PXE.

Conclusión
A grandes rasgos, eso es todo. Para obtener más información, consulte la barra lateral "Más información acerca de las tecnologías relacionadas con PXE". El próximo mes, exploraremos los aspectos básicos de WDS, seguidos de artículos acerca de la funcionalidad avanzada de WDS (multidifusión, por ejemplo). Finalmente, veremos el uso de WDS sin usar WDS, es decir, cómo puede ir más allá de la experiencia de instalación/WDS para llevar a cabo sus propias técnicas de implementación.

Wes Miller es responsable senior de productos técnicos en CoreTrace (www.CoreTrace.com), con base 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, parte 1
Jesper M. Johansson

Contenido
Consejos de seguridad no procesables
No procesables e incorrectos
Consejos incomprensibles
Trampas de la autenticación de sitios basada en imágenes
Hace poco, la Universidad de Minnesota se puso en contacto conmigo para entrevistarme para su revista. Al parecer, querían publicar un artículo acerca de varios alumnos muy brillantes. Como no encontraron ninguno, en su lugar, decidieron entrevistarme a mí. La entrevistadora me preguntó en qué trabajo y dediqué unos minutos a intentar describirle el software
de infraestructuras de seguridad. Entonces, ella exclamó: "¡Qué complicado suena! Para mí, la seguridad trata de contraseñas y tarjetas de crédito".
Reflexioné durante unos minutos acerca de esta reacción, y me di cuenta de que tenía bastante razón. La seguridad sí que trata de contraseñas y tarjetas de crédito. Por lo menos, así es como lo percibe el usuario final. Los que trabajamos en ello, pensamos que la seguridad trata de algoritmos de cifrado, de si Kerberos es mejor que TLS o NTLMv2, de las ventajas de WS*, si se deberían aleatorizar los hash de contraseña y otras cuestiones esotéricas de las que nos encanta hablar. Es cierto que nuestra perspectiva es muy diferente y mucho más profunda que la de los usuarios finales, pero no nos hemos dado cuenta de algo fundamental: la seguridad, en la opinión de aquellos para los que trabajamos, trata de contraseñas y tarjetas de crédito.
Ya, todos los temas esotéricos que tanto nos gusta discutir y todas esas nuevas tecnologías que nos encanta inventar sirven para proteger los datos del usuario final. Aun así, creo que nos hemos perdido por el camino. Nosotros, la subcultura de la seguridad del mundo de la TI, existimos para cumplir una necesidad específica de nuestros clientes: la necesidad de mantener sus datos seguros. Eso, evidentemente, incluye la garantía de que se pueden usar todos los activos de TI sin riesgo alguno. En esencia, de eso se trata.
En artículos anteriores, dejé claro que nadie compra un equipo para poder ejecutar software de antivirus. Un usuario adquiere un equipo para usar sistemas de banca en línea, divertirse con juegos para PC, escribir mensajes de correo electrónico, hacer los deberes o alguna otra función primaria. Del mismo modo, ninguna empresa recurre a un grupo de seguridad de TI simplemente para implementar NTLMv2. Las empresas hacen uso de grupos de seguridad de TI para que protejan los activos de la organización, lo que permite a las grandes compañías usar sus recursos de TI sin riesgo alguno y alcanzar sus objetivos empresariales.
Nuestro único propósito es servirles.
Por lo tanto, cabe preguntar si actualmente estamos haciendo un buen trabajo a la hora de ofrecer servicios. ¿O quizá, por el contrario, estamos entorpeciendo las cosas en lugar de ayudar? ¿Nos están ayudando los legisladores y reguladores a entorpecerlo todo? No estoy convencido de que toda esta nueva tecnología que estamos estableciendo ayude realmente a los usuarios finales. Por lo tanto, me gustaría investigar algunas áreas en las que, como proveedores mundiales de TI, estamos causando más daño que beneficio.
A veces, da la sensación de que la mayoría de los consejos de seguridad y gran parte de la tecnología que ofrecemos a nuestros usuarios no son procesables, son incorrectos, incomprensibles o (en la mayoría de los casos) una combinación de los tres. En esta serie de tres partes, trataré algunos de los modos en que confundimos a los usuarios al aconsejarles o al implementar tecnologías culpables de alguno de los tres cargos anteriores.

Consejos de seguridad no procesables
Una de las mejores maneras de confundir a un usuario es proporcionarle consejos de seguridad que no se pueden aplicar. También se le pueden proporcionar consejos incorrectos. La Figura 1 ilustra una parte bastante conocida de un dispositivo de comprobada eficacia, teóricamente correcto y completamente inútil.
Figura 1 Consejo de seguridad no procesable (haga clic en la imagen para ampliarla)
¿Ve donde pone que use una contraseña distinta para cada cuenta que tenga en línea? Hace treinta años, esta recomendación tenía sentido. El número de usuarios de Internet por aquel entonces era de unos pocos cientos. Se trataba de personas muy inteligentes que no elegían buenas contraseñas. Desgraciadamente, este consejo se ha mantenido hasta hoy día y se repite una y otra vez. No se ha hecho ningún esfuerzo para adaptar este consejo al uso actual de la informática.
¿Cuántas cuentas tiene en línea? Yo tengo alrededor de 115, sin contar aquellas de las que no realizo ningún seguimiento. El consejo de la Figura 1 no sólo sugiere que debo tener 115 contraseñas diferentes, sino que también debo cambiarlas cada 30 o 60 días. Dicho de otra manera, tengo que cambiar de 2 a 4 contraseñas al día. Haga los cálculos: también significa que tendría entre 690 y 1380 contraseñas en un solo año.
Aunque el personal técnico que ofrece este consejo pueda inventarse cuatro buenas contraseñas al día y mantener 115 en la memoria a corto plazo, seguro que el 99,99 por ciento de las personas que usan Internet no podrán hacerlo.
Puede que el consejo de usar diferentes contraseñas sea correcto desde un punto de vista puramente teórico, al igual que el consejo de cambiar las contraseñas cada 30 o 60 días. Sin embargo, este consejo no es procesable. Dado el número de contraseñas que tienen los usuarios hoy en día, simplemente no pueden seguir este consejo sin ningún tipo de ayuda, ya sea mediante papel o software. Veamos el siguiente ejemplo.

No procesables e incorrectos
El consejo que se muestra en la Figura 2, que proviene del sitio web de uno de los principales bancos del mundo, no es procesable y tampoco es correcto. La información que se ofrece bajo el encabezado que sugiere a los usuarios la lectura de los consejos sobre contraseñas equivale exactamente a "contraseñas diferentes en todos los lugares". También se recomienda que "nunca las escriba".
Figura 2 Consejo no procesable e incorrecto (haga clic en la imagen para ampliarla)
Así que ahora tengo 115 contraseñas diferentes, tengo que inventarme cuatro nuevas cada día y no puedo escribirlas. Durante un tiempo, pensé que esto era una estupidez, ya que me resultaría imposible acordarme de todas las contraseñas. Luego me di cuenta de que todo el mundo es exactamente igual que yo. Básicamente, un ser humano es incapaz de recordar 115 contraseñas. Somos capaces de recordar y procesar alrededor de siete bloques de información: así es como estamos programados. Si seguimos la mayoría de los consejos de contraseñas que hay en Internet, eso ni siquiera basta para una sola contraseña (consulte "El número mágico siete más o menos dos: algunos límites de nuestra habilidad para procesar la información", de George A. Miller, disponible en musanim.com/miller1956).
Desgraciadamente, en lo referente a los consejos para las contraseñas, nuestra industria suele engañar a los usuarios con bastante regularidad. Si la subcultura de la seguridad dice a los usuarios que deben usar una contraseña diferente para cada cuenta, entonces también debemos decirles cómo tienen que hacerlo: registrando y almacenando dichas contraseñas en algún lugar seguro. Escríbalas en un trozo de papel, use un documento protegido o una herramienta especializada, como PasswordSafe (sourceforge. red/proyectos/passwordsafe). Así de claro: o registramos todas las contraseñas o usamos la misma en todos los lados. De hecho, en una encuesta reciente, se descubrió que el 88 por ciento de los usuarios tienen la misma contraseña en todos los sistemas en los que deben autenticarse (consulte msnbc.msn.com/id/24162478).
Es obvio que el consejo de no escribir las contraseñas ha contribuido a que se dé esta tendencia. Lo que debemos hacer es enseñar a los usuarios el modo de administrar sus contraseñas (y otros datos confidenciales) de manera eficaz, en lugar de enseñarles a no administrar la información en absoluto. Seguro que habrá menos posibilidades de que comprometan la seguridad de sus credenciales.

Consejos incomprensibles
Las dos primeras figuras repiten un consejo que funcionaba en los años 60, 70 y 80, cuando los usuarios estándar aún no se conectaban a Internet ni usaban servicios basados en web. A día de hoy, nadie se ha quejado de este tipo de consejo porque se ha aceptado de forma generalizada.
Este tipo de consejo confunde a los usuarios y les hace sentirse culpables por tener que almacenar sus contraseñas en algún lugar. Los profesionales de la seguridad perjudican a los usuarios al ofrecerles este tipo de consejo en lugar de ayudarles a hacer lo que deben. Después de todo, los usuarios no son responsables de averiguar el modo en que deben administrar su seguridad. Eso corresponde a los profesionales de la seguridad. Debemos ofrecer a nuestros usuarios formas aceptables de administrar todas sus cuentas en línea. Sin embargo, dado que la mayoría de las indicaciones ofrecidas se limitan a repetir los mismos consejos anticuados, los usuarios recurren a post-its o a hojas de cálculo para registrar todas sus contraseñas.
Como mecanismo de autenticación, las contraseñas tienen muchísimo potencial. Sin embargo, el problema principal de las contraseñas es que los seres humanos son terribles a la hora de recordarlas. En lugar de intentar resolver un problema de naturaleza humana, el mundo de la TI se empeña en inventar todo tipo de mecanismos para reemplazar las contraseñas o, lo que es aún peor, aumentarlas. Lo único que se consigue con esto es confundir aún más a los usuarios.
Imagine mi sorpresa la última vez que utilicé un cierto sitio de servicios financieros y me presentaron una pantalla de inicio de sesión que contenía un solo cuadro de texto para el nombre de usuario (vea la Figura 3).
Figura 3 ¿Dónde escribo la contraseña?
Al principio, pensé que me encontraba en algún tipo de sitio web malintencionado. Luego, validé el sitio rápidamente. Este paso fue bastante fácil, ya que el sitio web presentaba un certificado. Así fue como me di cuenta de que, efectivamente, me encontraba en el lugar adecuado. El problema reside en que la mayoría de las personas están acostumbradas a ver dos cuadros de texto, el del nombre de usuario y el de la contraseña, que se presentan juntos cuando se inicia la sesión en un sitio. Llevamos años y años encontrándonos con el mismo flujo de trabajo. Por eso, si de repente uno se encuentra con un sitio que sólo pide el nombre de usuario, parece que todo se detiene. Resulta que, en este caso, y como intento de evitar los ataques de phising, el proveedor había implementado una tecnología basada en imágenes para que los usuarios identificaran el sitio. De este modo, cuando se rellena el cuadro de nombre de usuario, aparece una ventana emergente con una imagen identificable, tal y como se muestra en la Figura 4.
Figura 4 Algunos sitios usan ahora imágenes para autenticar el sitio a un usuario (haga clic en la imagen para ampliarla)
En teoría, el usuario sabe qué imagen se relaciona con un sitio determinado. Si no se muestra la imagen correcta, se identifica el sitio como falso. Este concepto, de por sí, es bastante sólido. Suponiendo que el usuario sabe qué imagen se relaciona con un sitio determinado, esta estrategia tiene bastante sentido.
Evidentemente, el lector astuto se habrá percatado de la barra de direcciones verde de la Figura 4. Esto quiere decir que el sitio usa certificados SSL y de validación extendida, que es la razón por la que la barra de direcciones es de color verde. También implica que la premisa de usar una imagen para identificar el sitio no ofrece ningún valor adicional. Por el contrario, la imagen no hace sino causar confusión, como mínimo, para algunos usuarios finales. Ya se ha identificado el sitio al usuario: ha proporcionado un certificado que contiene el nombre de la compañía, la dirección del sitio web y el nombre del emisor de confianza. Además, el hecho de que la barra de direcciones sea de color verde me dice que la compañía ha dado un paso adicional y ha pagado tres veces más por un certificado de validación extendida.
Claro que también es posible que las imágenes sean falsas. Si el usuario puede enviar su propia imagen, un atacante dispone de medios para averiguar la imagen que se está usando. También hay una alta probabilidad de que el usuario use la misma imagen para todos los sitios, por lo que lo único que deberá hacer el atacante es crear un sitio con contenido que pueda valorar el usuario (dejaré que se le ocurran sus propios ejemplos) y pedirle una imagen para verificar el sitio. Si el usuario usa la misma imagen para todos los sitios, el nuevo sitio obtendrá acceso a la imagen del usuario, para, por ejemplo, obtener acceso al sitio web de su banco.
Aunque algunos sitios permiten que el usuario escoja su propia imagen, hay otros que tienen su propia biblioteca de imágenes. Por ejemplo, en el sitio de la Figura 4, se puede elegir entre 318 imágenes de archivo. El truco anterior no funciona en los sitios que no permiten al usuario enviar su propia imagen. Sin embargo, las probabilidades de que el usuario recuerde las fotografías que se relacionan con cada sitio serán bastante bajas para los sitios que no se visiten frecuentemente. No tengo ni la menor idea de la imagen que uso para el sitio de la Figura 4, aunque puedo asegurarle que no es la que aparece en la captura de pantalla.
El problema del enfoque basado en imágenes es que un atacante puede mostrarle cualquiera de las 318 imágenes o elegir una fotografía cualquiera de Flickr, y muchos usuarios darán por hecho que la imagen es la correcta. Si la mayoría de las personas recordaran cosas como qué fotografía se relaciona con un sitio determinado, no tendríamos los problemas actuales de phising ni los relacionados con la seguridad.
Así que, ¿qué sentido tiene usar una imagen para autenticar un sitio al usuario cuando el sitio ya se ha autenticado mediante un certificado? ¿Por qué no usamos simplemente este certificado y ayudamos a los usuarios a aprender a validarlo? Los certificados ya demuestran la identidad del sitio al usuario.
El proceso de obtención de un certificado es mucho más seguro que el de obtener una imagen de autenticación de un sitio. Si el certificado es de validación extendida y el usuario utiliza Internet Explorer® 7 o Firefox 3, el explorador incluso resaltará la información relevante del certificado en la barra de direcciones. Desgraciadamente, la función de resaltado sólo se aplica a los caros certificados de validación extendida.

Trampas de la autenticación de sitios basada en imágenes
La tecnología de autenticación por imágenes tiene una serie de problemas. En primer lugar, la tarea de recopilar los nombres de usuario de un sitio se convierte en algo bastante fácil. De hecho, el sitio de la Figura 4 presentará el cuadro de diálogo de la Figura 5 si escribe un nombre de usuario incorrecto. Una vez que haya escrito el nombre de usuario correcto para un usuario que haya seleccionado una imagen secreta, podrá ver la imagen secreta de esta persona. Evidentemente, un atacante que esté intentando recopilar información acerca de un usuario encontrará esto bastante valioso.
Figura 5 Los sitios autenticados por imágenes permiten recopilar fácilmente los nombres de usuario
El tipo de implementación que se muestra aquí no tiene valor alguno en términos de seguridad. El atacante sólo tendría que duplicar el flujo de trabajo del inicio de sesión en un sitio falso. El sitio falso solicita el nombre de usuario y lo transmite al sitio real. Para que su apariencia sea más impecable aún, puede usar un AJAX en el cliente para actualizar el formulario en tiempo real. Además, si el sitio legítimo no ha mitigado los ataques de falsificación de solicitudes entre distintos sitios en el formulario de inicio de sesión, el código de AJAX puede enviar una solicitud directamente al sitio real, a no ser que el explorador mitigue las solicitudes de XML-HTTP entre sitios.
Ahora, una vez que se haya devuelto el resultado, el atacante puede analizar los datos, extraer la imagen y mostrársela al usuario final. En otras palabras, un atacante capaz de presentar un sitio de inicio de sesión falso al usuario podrá también mostrar la imagen secreta del usuario. El resultado final es que no existe ningún valor añadido asociado al uso de la autenticación basada en imágenes. La imagen se muestra antes de que el usuario autentique el sitio y, por lo tanto, el atacante que tiene (o podría tener) el nombre de usuario de esta persona podrá obtener acceso a la imagen.
Si damos por hecho que nadie ha enseñado al usuario a buscar un certificado antes de enviar formularios (esta suposición es segura, ya que la autenticación basada en imágenes se basa, a su vez, en esa misma suposición), obtener un nombre de usuario es una tarea bastante trivial. Además, dado que muchos esquemas de autenticación de sitios basada en imágenes responden de modo diferente a un nombre de usuario válido que a uno no válido, la recopilación de nombres de usuario es igualmente trivial. El atacante puede hacerlo incluso fuera de banda, antes de que comience el propio ataque.
Al final, tenemos usuarios que creen que su seguridad es mayor de lo que realmente es o que están mucho más confundidos. Hemos dedicado gran cantidad de capital social a implementar la autenticación de sitios basada en imágenes, pero no les hemos puesto las cosas difíciles a los usuarios malintencionados que convencen a los usuarios finales para que envíen sus credenciales a sitios web falsos.
No hay espacio para más en este número de Vigilancia de seguridad. Vuelva el mes próximo para la segunda parte de esta serie, donde trataré más ejemplos de prácticas de seguridad torpes e implementaciones de autenticación incorrectas.

Jesper M. Johansson es arquitecto de software dedicado al campo del software de seguridad. Es editor colaborador de 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.


Notas de campo Garantía de unas elecciones precisas
Josh Benaloh

En este año de elecciones presidenciales en EE.UU., la atención pública se centra en las tecnologías de votación. Mientras nos debatimos entre las distintas opciones, el péndulo oscila entre las clásicas papeletas, incómodas y sujetas a un uso abusivo; las máquinas de palanca, que pueden ser manipuladas por usuarios con ciertos conocimientos; las tarjetas perforadas con sus ahora famosos y controvertidos "fragmentos de papel colgantes"; votos escaneados de forma óptica, fácilmente malinterpretados por escáneres mal calibrados; sistemas de pantalla táctil, fácilmente vulnerables al software de mala calidad o malintencionado; y distintos híbridos, que, con frecuencia, provocan más problemas de los que realmente solucionan.
Claro está que esto es sólo una pequeña muestra de las vulnerabilidades posibles en estos sistemas. Es más, la técnica más extendida en todo el mundo depende de la honestidad y la capacidad de los administradores encargados de las elecciones, a los cuales corresponde mantener la integridad de las mismas.
Sin embargo, hay un método mejor, un método en el cual la integridad de las elecciones no depende ni de los administradores ni del equipo. Las elecciones pueden llevarse a cabo de forma que se pueda comprobar su total veracidad a través de personal especialmente designado, votantes individuales e, incluso, observadores voluntarios.
Con el objeto de comprender esto, imagine que los futuros votantes cuentan con códigos que les permitan registrar sus votos junto a sus nombres en un sitio web de libre acceso público. Los votantes pueden consultar el sitio web para ver que sus propios votos se han registrado adecuadamente, y cualquier persona puede realizar una auditoría independiente para comprobar que todos los votantes son legítimos y que el recuento coincide con los resultados anunciados.
Pero, un momento, el elemento inexistente en estas elecciones "totalmente públicas" es la privacidad. Aún así, la criptografía puede usarse para llenar este vacío, permitiendo la total comprobación de unas elecciones de voto secreto. En lugar de registrar los votos en bruto, los votos publicados se cifran con claves públicas cuyas claves de cifrado son de uso compartido para los oficiales y se requiere la cooperación para descifrarlas. Una vez que se ha llevado a cabo la votación, el personal oficial colabora para proporcionar tanto un resultado como una prueba criptográfica que garantiza que el resultado se corresponde de forma precisa con los votos cifrados registrados.
Los votantes pueden comprobar que sus votos cifrados se corresponden con sus intenciones, y cualquier persona puede examinar la prueba criptográfica para comprobar que se ha realizado el recuento correcto de los votos cifrados. De este modo, el resultado de las elecciones puede comprobarse en su totalidad.
¿Es realmente tan sencillo? No. Hemos expuesto una visión fiel, pero es totalmente necesaria la administración exhaustiva de numerosos detalles para que todo salga bien. Por ejemplo, debemos depender aún de los métodos tradicionales para garantizar que los dispositivos de votación mantienen adecuadamente la privacidad del votante. Además, ¿cómo pueden los votantes convertir sus intenciones en votos cifrados? Los votantes deben estar seguros de que los valores cifrados inescrutables registrados junto a sus nombres se corresponden realmente con sus intenciones, sin necesidad de mostrar a terceros la correspondencia (para evitar intentos de coerción o de compra de votos). Debemos, asimismo, hacer todo esto sin que sea necesario pedir a los votantes que hagan algo más complejo de lo que normalmente se hace en los sistemas de voto tradicionales.
Los procesos de elecciones completamente verificables han sido objeto de estudio de la literatura criptográfica durante más de un cuarto de siglo, y existen ahora métodos seguros y prácticos para proporcionar la prueba criptográfica de la precisión del resultado. Recientemente, la atención de la comunidad de investigadores se ha centrado en el sistema front-end que se ofrece al votante; en este campo se han conseguido numerosos progresos.
La demanda comercial de tecnología para las elecciones es amplia, pero no es enorme. Los grandes conglomerados con intereses ampliamente generalizados pueden considerarse sospechosos en este mercado puesto que algunos de sus intereses pueden beneficiarse de ciertos resultados electorales. Es más, este mercado debería contar con pequeños jugadores cuyo negocio dependa exclusivamente de la realización correcta de las elecciones. Para obtener más información y vínculos a métodos de elecciones completamente verificables, consulte research.microsoft.com/crypto/voting.

Josh Benaloh es criptógrafo senior en Microsoft Research. Trabajó ocho años en el Consejo directivo de la Asociación internacional de investigación criptográfica. Entre sus numerosas publicaciones, se encuentra su tesis doctoral de 1987, "Verifiable Secret-Ballot Elections" ("Elecciones por voto secreto verificables").


Confidencial de Windows La historia ocupa su espacio
Raymond Chen

¿Recuerda la tecnología Microsoft Bob? Concebido como interfaz de usuario fácil de usar sobre Windows® 3.1, se convirtió en un rotundo fracaso (llegando incluso a ser considerado por PC World como uno de los peores productos de tecnología de todos los tiempos). A lo largo de los años transcurridos desde el fracaso de Bob, el producto ha pasado a ser considerado como una broma y la sola mención de su nombre provoca carcajadas.
Casualmente, el nombre de código interno de Microsoft® Bob era "Utopia", sin duda, un nombre ambicioso, pero al menos un nombre contundente y enérgico. Al conocer que el personal de marketing había decidido llamar al producto Bob, todos nos mostramos en desacuerdo.
Pero hay más aspectos heredados de Bob que posiblemente conozca. Finalmente, Bob resultó ser más práctico una vez había desaparecido que cuando estaba en uso.
A la hora de intentar distribuir el software en un CD, es necesario asegurarse de que su producto realmente encaja en un solo CD. Afortunadamente, dio la casualidad de que incluso después de tener en cuenta el espacio en disco necesario para las traducciones, las herramientas de soporte y el resto de los componentes que deben formar parte del CD de Windows XP, quedaban todavía alrededor de 30 megabytes de capacidad de almacenamiento sin usar. Las personas que se preocupan por estos tipos de cosas se preguntan: "Bien, ya que hemos pagado por toda esta capacidad de almacenamiento en el CD, estaría bien que la usáramos, ¿verdad?"
El nombre de código interno de Microsoft Bob era "Utopia", sin duda, un nombre ambicioso, pero al menos un nombre contundente y enérgico. Haga clic en la imagen para ampliarla.
El resultado fue un pobre intento de pararles los pies a las personas que les gusta hacer copias ilegales de Windows. Alguien decidió llenar esa capacidad extra en el CD con datos ficticios y que el programa de instalación de Windows comprobara que los datos ficticios se encontraban aún allí. Esto, lógicamente, forzaría a los usuarios que descargaran una copia de la imagen del CD a descargar unos treinta megabytes adicionales de datos. Recuerde, esto nos lleva a los días en los que prácticamente nadie estaba familiarizado con el término "banda ancha" y los usuarios estándar usaban conexiones de acceso telefónico. El tener que transferir los treinta megabytes adicionales de datos a través de un módem de 56 Kb era en un obstáculo que reducía la capacidad de los usuarios (esto no ocurriría con los estándares actuales).
La persona a la que se pidió implementar esta comprobación necesitaba un origen para los datos ficticios. Podría simplemente haber llamado a la función CryptGenRandom para que generara 30 megabytes de bytes criptográficos aleatorios pero, ¿dónde está la gracia entonces? En su lugar, prefirió investigar en los archivos y encontró una copia de Microsoft Bob. Tomó todas las imágenes del disquete y las combinó en un archivo de gran tamaño. El contenido de las imágenes del disquete de Microsoft Bob no era especialmente aleatorio, por lo que decidió mezclar los datos cifrándolos. Cuando llegó el momento de escribir la clave de cifrado, simplemente recorrió el teclado con la mano de forma azarosa, y así se creó la copia cifrada de Microsoft Bob. Esta entró a formar parte del espacio no usado como datos de relleno en el CD de Windows XP.
Al final, Windows XP se convirtió en la herramienta de implementación de Microsoft Bob más efectiva jamás desarrollada. Así pues, si toma su copia de Windows XP y tiene la suerte de recorrer el teclado con la mano de la forma correcta, obtendrá una copia de Microsoft Bob a partir de su programa de cifrado.

En el sitio web de Raymond Chen, The Old New Thing, y en su libro homónimo se trata la historia de Windows y la programación Win32. Se pregunta si se conseguirá la fusión nuclear mientras él se encuentre en este mundo.