 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

¿Se está preparando para realizar el cambio a Exchange 2007? Ha llegado al lugar adecuado. Este mes le mostraremos cómo preparar la actualización, cómo escribir secuencias de comandos para administrar Exchange mediante el Shell de administración de Exchange y cómo sacar el máximo partido del acceso ilimitado y la mensajería unificada cuando combine Outlook Web Access con Exchange 2007.

Además, encontrará las mejoras más recientes tanto en Exchange Server 2007 como en el cliente Outlook 2007, aprenderá a combatir el correo no deseado de forma más eficaz con el marco de Id. de remitente y podrá explorar el registro en diario en Exchange 2007 para obtener un mejor control y cumplimiento.

CARACTERÍSTICAS
Exchange Server 2007 Actualización de la infraestructura a Exchange 2007

Independientemente del tamaño de su empresa, una transición sin problemas a Exchange Server 2007 requiere una planeación preliminar. Con un buen plan establecido, podrá evitar interrupciones en el servicio. A continuación se describen los pasos que deberá seguir al realizar la actualización.

Kate Follis Tome el control con el Shell de administración de Exchange

El Shell de administración de Exchange ofrece a los administradores una eficaz interfaz para administrar todos los aspectos de Exchange Server 2007. Obtenga una descripción general de cómo puede empezar a escribir secuencias de comandos, integrar aplicaciones y realizar otras eficaces tareas de administración desde la línea de comandos.

David Strome Exchange & Outlook: Better Together

Juntos, Exchange Server 2007 y Microsoft Office Outlook 2007 representan un gigantesco paso adelante en el campo de las comunicaciones y la colaboración. Descubra cómo a medida que describimos una configuración más sencilla, las posibilidades de búsqueda mejoradas, la mensajería unificada y muchas otras características.

Michael Khalili Manténgase siempre al corriente con Exchange 2007

La comunicación se ha hecho más poderosa que nunca. Compruebe cómo las capacidades de la mensajería unificada y de Outlook Web Access incorporadas en Exchange Server 2007 permiten tener acceso a todos sus mensajes en un solo lugar y desde cualquier sitio.

Joshua Trupin Una elaboración de diarios más eficaz en Exchange 2007

Exchange Server 2007 proporciona capacidades de registro en diario mucho más flexibles, con lo que facilita la supervisión de cuentas de usuario específicas y el cumplimiento de los requisitos de una organización grande.

David Strome Contra el correo no deseado y la suplantación de identidad con un Id. de remitente

La autenticación de correo electrónico incorporada en el marco de Id. de remitente (SIDF) está ganando muchos adeptos, ya que proporciona un importante avance en la lucha contra el correo no deseado y los mensajes de suplantación. De hecho, más de un tercio del volumen del correo electrónico mundial ya es autenticado y es compatible con SIDF. A continuación se describe su funcionamiento.

Craig Spiezle y Alexander Nikolayev
COLUMNAS
Nota del editor

Extender el alcance

Joshua Trupin Caja de herramientas

Nuevos productos para profesionales de TI

Greg Steen Windows PowerShell

Comandos sencillos. Administración eficaz

Don Jones Examen analítico final

Migración desde Exchange 5.5

Whitney Roberts 		Preguntas y respuestas de SQL

Prevención de reinicios, instalación de varias actualizaciones y mucho más.

Editado por Nancy Michell ¡Hola, chicos del scripting!

¿Dónde están los soportes para vasos?

Los chicos del scripting de Microsoft Vigilancia de seguridad

Implementación de una PKI confiable globalmente

John Morello Archivos del escritorio

Dentro del formato de imágenes de Windows

Wes Miller Confidencial de Windows

A la espera de RunOnce

Raymond Chen


 Exchange Server 2007: Actualizaci&#243;n de la infraestructura a Exchange 2007
Exchange Server 2007 Kate Follis

Actualización de la infraestructura a Exchange 2007
Resumen:
  • Novedades de Exchange 2007
  • Preparación para una actualización
  • Implementación basada en funciones
  • Topología del enrutamiento de mensajes

Solía impartir un curso sobre la migración de Exchange Server 5.5 a Exchange 2000 Server. El curso comenzaba a las 8:30 de la mañana y terminaba a las 18:00 de la tarde aproximadamente. Abandonaba el aula
completamente agotada. El traslado de los recursos del directorio implicaba una gran cantidad de trabajo de preparación y había mucha confusión en cuanto a NTDSNoMatch. Además, a veces Windows NT® 4.0 se negaba a prestar un servicio de confianza. Debido a los límites de tiempo, apenas tocábamos los temas de administración de Exchange 2000 Server. Sin embargo, siempre había un par de alumnos entusiastas que pensaban abandonar el aula el viernes y terminar la migración durante el fin de semana. Siempre lo desaconsejaba y hacía hincapié en la necesidad de dedicar el tiempo suficiente para la planeación, aunque dudo que me hicieran caso.
La transición de Exchange 2000 Server o Exchange Server 2003 a Exchange Server 2007 requiere el mismo tipo de cuidado: debe dedicar el tiempo necesario en la planeación. El proceso real de transición puede variar de una organización a otra y depende de la complejidad de la implementación actual, aunque siempre necesitará llevarse a cabo en varias fases. Una organización pequeña puede pasar por estas fases como un proyecto único, mientras que las organizaciones de mayor tamaño pueden optar por una incorporación gradual de las funciones de servidor y proporcionar compatibilidad con Exchange en modo de coexistencia durante un período. El proceso completo está diseñado para conservar la funcionalidad y estabilidad de la mensajería a lo largo del período de transición. En este artículo, me centraré en los pasos esenciales necesarios para conservar el flujo de mensajes de la organización mientras actualiza a Exchange Server 2007.

Consideraciones
El primer requisito que se debe tener en cuenta es que Exchange Server 2007 debe implementarse en hardware de 64 bits y no admite una actualización in situ desde ninguna versión anterior de Exchange. Debe usar el método de actualización de balanceo para trasladar los servicios de mensajería existentes a Exchange 2007. Además, la organización que usa Exchange debe estar funcionando en modo nativo para admitir la adición de servidores Exchange 2007; por lo que si su organización usa actualmente Exchange 5.5, deberá realizar una actualización temporal a Exchange Server 2003 antes de pasar a Exchange 2007.
Se han realizado importantes cambios en Exchange 2007 que se deben tener en cuenta a la hora de planear la transición. Por ejemplo, Exchange 2007 incluye la implementación basada en funciones, que permite elegir los servicios de mensajería que se desean proporcionar e implementar funciones de servidor a dichos servicios. Las funciones de servidor se pueden implementar de manera individual en hardware dedicado, o bien se pueden instalar varias funciones en el mismo servidor físico y administrarse como entidades independientes. Consulte la barra lateral "Funciones de servidor Exchange Server 2007" para obtener una descripción de cada una.
Funciones de servidor de Exchange Server 2007
Servidor de buzones La función de servidor de buzones proporciona a una organización almacenamiento de mensajes. Exchange 2007 admite hasta 50 almacenes por servidor. Estos almacenes se pueden implementar como 50 grupos de almacenamiento individuales, o bien puede crear hasta 50 almacenes en un solo grupo de almacenamiento. La función de servidor de buzones es la única función que se puede implementar en forma de clúster, por lo que si piensa usar clústeres, deberá instalar el servidor de buzones en hardware dedicado.
Servidor de acceso de clientes La función de servidor de acceso de clientes sustituye la funcionalidad que proporcionaba un servidor de aplicaciones para el usuario. Ésta proporciona acceso a buzones para los clientes que obtienen acceso a Exchange mediante POP3, IMAP4, Outlook® Web Access (OWA), RPC a través de HTTPS (ahora conocido como Outlook en cualquier lugar) y Exchange ActiveSync®.
Servidor de transporte del concentrador Esta función proporciona servicios de transporte de mensajes SMTP y MAPI para la organización que usa Exchange. Todos los mensajes que reciben o envían los usuarios de su organización se procesan mediante un servidor de transporte del concentrador. Esto es ideal, ya que impide que los mensajes puedan omitir las reglas basadas en servidor o las directivas de registro en diario que proporcionan los agentes que se activan en los distintos puntos del canal de transporte.
Servidor de mensajería unificada Esta función proporciona acceso de voz a los buzones. Se integra con la puerta de enlace IP/VoIP o IP-PBX para proporcionar acceso telefónico a los mensajes y elementos de calendario y permite transcribir una respuesta. Se trata de una función nueva en Exchange y no puede interactuar con ninguna versión anterior de Exchange.
Servidor de transporte perimetral El servidor de transporte perimetral suele implementarse en la red perimetral. Proporciona transporte de mensajes SMTP entre la organización que usa Exchange e Internet, y ofrece un procesamiento de protección contra correo no deseado y antivirus mediante agentes de transporte. Ahora puede establecer estándares basados en una única tecnología para los servidores tanto de organización como de red perimetral. Este modelo de interacción perfecta simplifica la administración y facilita la integración de servidores perimetrales.

Inspección de la topología
Entonces, ¿por dónde comenzar? Bueno, es difícil saber a dónde vamos si no sabemos dónde estamos. Tómese el tiempo para evaluar el entorno actual y documentar la topología, no solamente para Exchange sino también para el entorno de Active Directory®. Seguro que le agradará saber que Exchange 2007 ha eliminado el enrutamiento de estado de vínculo y la topología basada en grupos de enrutamiento y conectores. En su lugar, Exchange 2007 saca partido de la inversión que la organización ya habrá realizado en el diseño de la topología de Active Directory. Como resultado, todos los datos de destinatario y configuración de Exchange se almacenan en Active Directory, la topología de enrutamiento se obtiene de la configuración del sitio de Active Directory y todas las funciones de servidor usarán el reconocimiento del sitio para detectar los servicios que se ejecutan en otras funciones de servidor.
Asegúrese de que la topología actual del sitio de Active Directory realmente saca partido de la red física subyacente y que todos los sitios de Active Directory disponen de subredes asociadas. A continuación, documente los sitios de Active Directory y los vínculos de sitio IP existentes. Además, documente la ubicación física de todos los servidores Exchange Server 2003 y la estructura del grupo de enrutamiento y del conector de grupo de enrutamiento.
Ésta es la parte más difícil del proceso: pasar de una infraestructura de enrutamiento Exchange basada en grupos de enrutamiento a una basada en sitios de Active Directory. Para una organización pequeña, no suele ser un proceso complicado. No obstante, una organización de gran tamaño con varios grupos de enrutamiento deberá planear cuidadosamente una fase intermedia en la que Exchange 2003 y Exchange 2007 deberán coexistir. Lo último que quiere es que un usuario de Exchange 2007 del otro lado del pasillo enrutado a través de un grupo de enrutamiento remoto termine enviando un mensaje al buzón de Exchange 2003 a través de una conexión de bajo ancho de banda.
Comencemos con algunas suposiciones sobre su topología actual:
  • La organización que usa Exchange 2003 se ejecuta en modo nativo.
  • Existe más de un grupo de enrutamiento.
  • Existe más de un sitio de Active Directory.
La figura 1 muestra una topología de Exchange y Active Directory. Recuerde que cuanto más detalles incluya en los planes preliminares, mejor será el diseño.
Figura 1 Topología de Exchange y Active Directory
Figura 1 Topología de Exchange y Active Directory (Hacer clic en la imagen para reducirla)
Figura 1 Topología de Exchange y Active Directory
Figura 1 Topología de Exchange y Active Directory (Hacer clic en la imagen para ampliarla)

Cómo Exchange 2007 usa Active Directory
Cuando se inicia un servidor de Exchange Server 2007, éste recibe un atributo del sitio que ayuda a los demás servidores Exchange Server 2007 a localizar los servicios que proporciona dicho servidor. Sólo el servidor de transporte del concentrador puede usar SMTP para transportar un mensaje en la organización. Todos los sitios de Active Directory que contienen un servidor de buzones también deben contener un servidor de transporte del concentrador y, si los usuarios obtienen acceso a sus buzones mediante un método que no sea MAPI, todos los sitios también deben incluir un servidor de acceso de cliente. Cuando un mensaje se procesa para su entrega, pasará por un servidor de transporte del concentrador, el cual tomará una decisión sobre cómo debe enrutarse el mensaje. Si el destino del mensaje es un servidor de buzones en el mismo sitio de Active Directory que el servidor de transporte del concentrador, este último entregará el mensaje al buzón. Si el destino del mensaje es un servidor de buzones en un sitio diferente, el servidor de transporte del concentrador transmitirá el mensaje directamente a un servidor de transporte del concentrador en el sitio remoto.
El servidor de transporte del concentrador usa la información de costo del vínculo del sitio IP de Active Directory para calcular la ruta de menor costo al sitio de Active Directory en el que se encuentra el buzón del destinatario. El algoritmo de selección de rutas es similar al de Exchange 2003, pero se basa en los costos del vínculo del sitio IP en lugar de en los costos del conector del grupo de enrutamiento. Además, el mensaje no se detiene en todos los servidores de transporte del concentrador durante su trayecto. Éste pasa directamente del origen al destino. Entonces, ¿por qué calcula la ruta de menor costo si emplea la red IP para transportar el mensaje? Existen un par de motivos. Uno es para retrasar la bifurcación de mensajes. Es posible que un mensaje que se envía a más de un destinatario tenga que entregarse a servidores de buzones en más de un sitio de Active Directory. En lugar de bifurcar, o dividir, el mensaje en el primer servidor de transporte del concentrador, Exchange 2007 no lo dividirá hasta que llegue a una bifurcación en la ruta de enrutamiento. Por consiguiente, el mensaje se transmitirá directamente a un servidor de transporte del concentrador en el sitio de Active Directory que representa el punto de bifurcación. Este comportamiento se conoce como cargabilidad de salida retrasada.
La ruta de menor costo también se usa para determinar en qué cola debe colocarse el mensaje en caso de que no se pueda alcanzar el destino. Si no se puede alcanzar un servidor de transporte del concentrador en el sitio de Active Directory, el servidor de transporte del concentrador de envío intentará realizar la entrega a uno en el próximo sitio de Active Directory más cercano según la ruta de enrutamiento. La entrega de los mensajes seguirá por la ruta de menor costo hasta que alcance un sitio de Active Directory con un servidor de transporte del concentrador disponible. Por último, si no hay ningún servidor de transporte del concentrador disponible en la ruta al sitio de Active Directory de destino, el mensaje se colocará en cola de manera local. Este método pone en cola el mensaje en el punto más cercano posible al destino, lo que facilita los diagnósticos de los errores de la red. Este comportamiento se conoce como poner en cola en el punto de error.
El funcionamiento de Exchange 2003 es completamente distinto. Calcula la ruta de menor costo desde un grupo de enrutamiento a otro en función de los costos asignados a los conectores del grupo de enrutamiento. Un servidor de cabeza de puente en cada grupo de enrutamiento en la ruta de enrutamiento recibirá el mensaje y, a continuación, lo transmitirá. Si el siguiente conector de la ruta no se encuentra disponible, se intenta calcular una ruta alternativa. Los mensajes de actualización del estado del vínculo también se comunican por toda la organización que usa Exchange para notificar a los otros servidores Exchange que la conexión está fuera de servicio. Los servidores de cabeza de puente intentarán una ruta alternativa al conector inactivo hasta que se reciba la notificación del estado del vínculo e indicarán que la conexión se encuentra de nuevo en servicio.
El desafío para la transición de una organización de gran tamaño es mantener el flujo del correo durante el período de coexistencia. Para conseguir esta continuidad cuando Exchange 2007 se incorpore en el entorno, todos los servidores Exchange 2007 se convierten en miembros de un único grupo de enrutamiento. Esto significa que Exchange 2003 lo verá como si perteneciera a dicho único grupo de enrutamiento, independientemente del sitio de Active Directory en el que se encuentre el servidor Exchange 2007. Esto permite establecer un conector de grupo de enrutamiento entre dicho grupo de enrutamiento y los grupos de enrutamiento de Exchange 2003 para que este último pueda saber cómo enrutar los mensajes a Exchange 2007. Además, Exchange 2007 usará dicho conector para determinar cómo enviar mensajes a Exchange 2003. Sin embargo, Exchange 2007 siempre preferirá enrutar un mensaje a través de otro servidor Exchange 2007 y nunca retrocederá a un grupo de enrutamiento de Exchange 2003 para alcanzar otro servidor Exchange 2007.

Presentación del primer servidor Exchange 2007
Cuando se instale el primer servidor Exchange 2007 en la organización que usa Exchange 2003, deberá seleccionar una cabeza de puente de Exchange 2003 con la que se debe establecer el primer conector de grupo de enrutamiento.
La figura 2 muestra cómo el hecho de incluir el primer servidor Exchange 2007 afecta a la topología de la organización.
Figura 2 Instalación del primer servidor Exchange 2007
Figura 2 Instalación del primer servidor Exchange 2007 (Hacer clic en la imagen para reducirla)
Figura 2 Instalación del primer servidor Exchange 2007
Figura 2 Instalación del primer servidor Exchange 2007 (Hacer clic en la imagen para ampliarla)
Ningún problema por el momento. Observe que el costo predeterminado del conector de grupo de mantenimiento que crea Exchange 2007 es tan solo 1. El correo sigue fluyendo por los servidores Exchange 2003 y si un mensaje se envía a un usuario en el servidor Exchange 2007 desde cualquier servidor Exchange 2003, pasará por el grupo de enrutamiento Acapulco. Durante la creación del conector de grupo de enrutamiento, el servidor de cabeza de puente de Exchange 2003 seleccionado se convirtió automáticamente en miembro del grupo de seguridad universal ExchangeLegacyInterop y recibió los permisos adecuados para enviar y recibir mensajes de correo electrónico procedentes de Exchange 2007. Siempre deberá usar el nuevo conector de grupo de enrutamiento en el Shell de administración de Exchange para crear un conector de grupo de enrutamiento cada vez que se especifique un servidor Exchange 2007 como servidor de origen o destino para el conector. También puede usar el cmdlet Set-RoutingGroupConnector para modificar la configuración de un conector de grupo de enrutamiento. Por ejemplo, es posible que desee agregar servidores de origen y de destino al conector inicial de grupo de enrutamiento para proporcionar redundancia. Consulte el artículo de David Strome sobre el Shell de administración de Exchange en esta edición de TechNet Magazine para obtener más información.

Preparación para el traslado de algunos buzones
El siguiente paso consiste en trasladar algunos buzones desde los servidores Exchange 2003 hasta los servidores Exchange 2007. Para ello, use el cmdlet Move-Mailbox. Sin embargo, para poder retirar los servidores Exchange 2003, antes debería crear conectores de envío y recepción en el servidor Exchange 2007 para sustituir los conectores SMTP definidos en el servidor Exchange 2003 para administrar el enrutamiento en espacios de direcciones SMTP externas.
En el diagrama siguiente, los recursos del grupo de enrutamiento Acapulco se trasladaron a Exchange 2007. El grupo de enrutamiento Acapulco puede retirarse, pero esto significa que deberá establecer ahora mismo un conector de grupo de enrutamiento a un grupo diferente. En la figura 3 he configurado el conector de grupo de enrutamiento en un servidor de cabeza de puente en el grupo de enrutamiento Miami North.
Figura 3 Configuración del conector de grupo de enrutamiento
Figura 3 Configuración del conector de grupo de enrutamiento (Hacer clic en la imagen para reducirla)
Figura 3 Configuración del conector de grupo de enrutamiento
Figura 3 Configuración del conector de grupo de enrutamiento (Hacer clic en la imagen para ampliarla)
Pasemos a la transición del grupo de enrutamiento LA East hacia Exchange 2007. Esto es el tipo de situación en el que el mantenimiento del enrutamiento se torna más complicado. En la figura 4, Exchange 2007 se ha instalado en el sitio de Los Ángeles y un segundo grupo de enrutamiento se ha retirado, pero no se ha creado ningún conector de grupo de enrutamiento adicional.
Figura 4 Exchange 2007 instalado en el sitio de Los Ángeles
Figura 4 Exchange 2007 instalado en el sitio de Los Ángeles (Hacer clic en la imagen para reducirla)
Figura 4 Exchange 2007 instalado en el sitio de Los Ángeles
Figura 4 Exchange 2007 instalado en el sitio de Los Ángeles (Hacer clic en la imagen para ampliarla)
Ahora si se transmite un mensaje desde el servidor Exchange 2007 en el sitio de Los Ángeles hacia el servidor Exchange 2003 en el grupo de enrutamiento Los Ángeles Oeste, primero se transmitirá a Acapulco, a continuación, a Miami Norte y Miami Sur y, finalmente, a Los Ángeles Oeste. Si se envía un mensaje desde el servidor Exchange 2003 en el grupo de enrutamiento Los Ángeles Oeste hacia el servidor Exchange 2007 en el sitio de Los Ángeles, se transmitirá primero a Miami Sur, a continuación, a Miami Norte y Acapulco y, finalmente, llegará a Los Ángeles. Vaya.
Para evitar todo esto, necesitaremos agregar un conector de grupo de enrutamiento. La figura 5 muestra la adición de un conector de grupo de enrutamiento desde LA West hasta el servidor Exchange 2007 en el sitio de Los Ángeles. Nota: Si desea evitar una abundancia de conectores de grupo de enrutamiento, asegúrese de que el primer conector de grupo de enrutamiento se configure en un sitio de Active Directory de concentrador bien conectado.
Figura 5 Enrutamiento más eficaz
Figura 5 Enrutamiento más eficaz (Hacer clic en la imagen para reducirla)
Figura 5 Enrutamiento más eficaz
Figura 5 Enrutamiento más eficaz (Hacer clic en la imagen para ampliarla)
Esto presenta un problema que puede o no ser evidente inmediatamente. Ahora existe más de una manera de entrar y salir del grupo de enrutamiento de Exchange 2007. Dado que el grupo de enrutamiento de Exchange 2007 no usa el estado del vínculo, ahora existe la posibilidad de que se produzca un bucle de enrutamiento. El servidor Exchange 2003 puede seleccionar una ruta alternativa para evitar un conector fuera de servicio, mientras que Exchange 2007 siempre seleccionará la ruta de menor costo. Una solución alternativa para este problema es suprimir los mensajes informativos de actualización de estado del vínculo, lo que impedirá la creación de mensajes que indican un estado de conector fuera de servicio, pero no de los mensajes de estado del vínculo que indican modificaciones en la configuración. Esto es importante, ya que nuestro deseo es que los servidores Exchange 2003 sean conscientes de los nuevos conectores de grupo de enrutamiento, pero no que intenten calcular una ruta alternativa. El resultado es que los servidores Exchange 2003 tendrán el mismo comportamiento de poner en cola en el punto de error que los servidores Exchange 2007.
En la figura 6 se muestra la transición de recursos de Exchange 2003 adicionales hacia Exchange 2007. Se han suprimido las actualizaciones de estado del vínculo y hemos tenido cuidado en establecer conectores de grupo de enrutamiento que mantienen una ruta de enrutamiento lógica.
Figura 6 Recursos de Exchange 2003 adicionales trasladados a Exchange 2007
Figura 6 Recursos de Exchange 2003 adicionales trasladados a Exchange 2007 (Hacer clic en la imagen para reducirla)
Figura 6 Recursos de Exchange 2003 adicionales trasladados a Exchange 2007
Figura 6 Recursos de Exchange 2003 adicionales trasladados a Exchange 2007 (Hacer clic en la imagen para ampliarla)
Sin embargo, hay otro problema. Hemos creado islas de estado del vínculo en Redmond y Vancouver. El flujo del correo no presenta ningún problema, aunque pase por Miami, pero no hay forma que Redmond y Miami puedan comunicar las modificaciones en la configuración del estado del vínculo. Para conservar una tabla de enrutamiento actualizada, deberá configurar otro conector de grupo de enrutamiento entre Redmond y Vancouver. Puede ajustar el costo de este conector de grupo de enrutamiento de modo que sea lo suficientemente elevado como para impedir que Exchange 2003 enrute a través de la conexión, a la vez que permite la comunicación de las modificaciones en la configuración del estado del vínculo.
Con una planeación bien pensada, puede evitar los problemas que puedan surgir debido al mantenimiento de dos topologías de enrutamiento de Exchange independientes. Obtendrá los mejores resultados al realizar las transiciones de los grupos de enrutamiento de uno en uno y, a continuación, pasar al siguiente, hasta que ejecute solamente servidores Exchange 2007.
Hasta ahora, me he centrado en los cambios de enrutamiento de Exchange 2007 y cómo éstos afectan a la transición. Hay otras consideraciones que deben tenerse en cuenta a la hora de planear el traslado a Exchange 2007.
Los servidores de aplicaciones para usuario de Exchange 2003 no pueden obtener acceso a los buzones de Exchange 2007. Sin embargo, un servidor de acceso de cliente de Exchange 2007 no tiene ningún problema para conectarse al buzón de Exchange 2003. Al usar el servidor de acceso de cliente de Exchange 2007, simplemente verá la misma versión de OWA que la del servidor de buzones en el que se almacena el buzón. Si está implementando Exchange 2007 en hardware separado, el servidor de acceso de cliente deberá ser la primera función que especifique para un sitio de Active Directory. Los servidores de aplicaciones para usuario de Exchange 2003 que proporcionan acceso público a Internet para los buzones deberán sustituirse por servidores de acceso de cliente de Exchange 2007 antes de trasladar cualquier buzón a Exchange 2007.
He mencionado que todos los sitios con una función de servidor de buzones también requieren una función de servidor de acceso de cliente (si tiene clientes que no sean MAPI, y ¿quién puede vivir sin OWA hoy en día?) y un servidor de transporte del concentrador. Por lo tanto, si las funciones de servidor van a compartir hardware, asegúrese de incluir el servidor de acceso de cliente en la selección de funciones. Una instalación típica incluirá la función de servidor de transporte del concentrador, la función de servidor de acceso de cliente y la función de servidor de buzones: todo lo que necesita para lograr un entorno Exchange completamente funcional.
Otra consideración para el proceso de transición es la actualización de la aplicación cliente (Outlook). No podrá sacar el máximo partido de todas las características del servidor Exchange 2007 hasta que todos los clientes hayan actualizado a Outlook 2007. Esto incluye una configuración mejorada para los mensajes "fuera de la oficina" y características de la carpeta del buzón administradas.
Además, deberá decidir cuándo implementar la función de servidor de transporte perimetral. Técnicamente, puede reemplazar el relé SMTP de red perimetral y host inteligente actuales con el servidor de transporte perimetral antes o después de incluir funciones de servidor Exchange 2007. Sin embargo, si implementa primero el servidor de transporte perimetral, la funcionalidad global se verá limitada ya que Exchange 2003 no puede replicar los datos del destinatario y de configuración que necesita el servidor de transporte perimetral de Active Directory a ADAM (Modo de aplicación de Active Directory).
Cuando haya instalado al menos un servidor de transporte del concentrador, puede implementar el servidor de transporte perimetral en la red perimetral y, a continuación, suscribir este último en el sitio de Active Directory en el que reside el servidor de transporte del concentrador. El servicio EdgeSync del servidor de transporte del concentrador replicará un subconjunto de datos de destinatario en Active Directory a ADAM.
Estos datos permiten al servidor de transporte perimetral realizar búsquedas de destinatario y agregaciones de lista segura a fin de sacar el máximo partido de los agentes de protección de correo no deseado que se ejecutan en el servidor de transporte perimetral. Además, EdgeSync creará los conectores de envío necesarios para el flujo de extremo a extremo del correo entre la organización que usa Exchange e Internet. Esto puede simplificar el proceso de sustitución de los conectores SMTP de Exchange 2003 que proporcionan el enrutamiento a espacios de direcciones externas.
Por lo tanto, tómese el tiempo de planear la transición a Exchange 2007 y verá que el camino es claro y poco doloroso.

Kate Follis es Editora jefe de contenido del equipo técnico de Exchange 2007. Su grupo se especializa en las funciones de servidor de transporte perimetral y transporte del concentrador. Antes de unirse a Microsoft, Kate trabajó durante varios años como profesora certificada de Microsoft e impartía cursos sobre Exchange y Active Directory.
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 Exchange Server 2007: Tome el control con el Shell de administraci&#243;n de Exchange
Exchange Server 2007 David Strome

Tome el control con el Shell de administración de Exchange
Resumen:
  • Funcionamiento del Shell de administración de Exchange
  • Uso de los cmdlets
  • Diferencias entre los cmdlets y los comandos

Si administra un entorno de Exchange, seguro que ha oído decir que el nuevo Exchange Server 2007 incluye una nueva interfaz de línea de comandos denominada Shell de administración de Exchange. Basado en la tecnología de Microsoft Windows PowerShell, el Shell
de administración de Exchange es una eficaz interfaz de administración que se puede usar para administrar todos los aspectos de Exchange Server 2007 desde la línea de comandos. Desde allí, puede interactuar directamente con el Shell de administración de Exchange, escribir secuencias de comando para la automatización o integrar las aplicaciones con el motor subyacente. La figura 1 muestra el shell en acción.
Figura 1 Shell de administración de Exchange
Figura 1 Shell de administración de Exchange (Hacer clic en la imagen para reducirla)
Figura 1 Shell de administración de Exchange
Figura 1 Shell de administración de Exchange (Hacer clic en la imagen para ampliarla)
La Consola de administración de Exchange no usa el Shell de administración de Exchange sólo para realizar operaciones, los asistentes muestran los comandos que dichas operaciones están ejecutando. Puede copiar los comandos creados mediante los asistentes y pegarlos directamente en la línea de comandos o en una secuencia de comandos. Cuando haya modificado los parámetros como desee, use el parámetro WhatIf para realizar una prueba de las secuencias de comandos o los comandos. Este parámetro permite ver los resultados antes de que se modifique el entorno.
El Shell de administración de Exchange proporciona una plataforma sólida y flexible que se puede integrar en las soluciones de secuencias de comandos existentes y que permite comunicarse de manera nativa con orígenes de datos como COM e Instrumental de administración de Windows (WMI). Basado en.NET Framework, el Shell de administración de Exchange usa cmdlets, la unidad de funcionalidad más pequeña del Shell, para aceptar y devolver datos estructurados en lugar de texto sin formato. Examinaremos los cmdlets más adelante con más detalle.

Complemento de Windows PowerShell
El primer paso para comprender el Shell de administración de Exchange es mirar cómo se relaciona con Windows PowerShell™, una eficaz y flexible interfaz de línea de comandos basada en .NET Framework. Ésta combina las mejores características de varios otros shells y agrega un gran número de características adicionales. Windows PowerShell está diseñado para funcionar como host de otras aplicaciones, muy parecido a la forma en que la Consola de administración de Microsoft (MMC) funciona como host para los distintos complementos suministrados con las aplicaciones. El Shell de administración de Exchange es el primer complemento de Windows PowerShell que se lanzará.
Los complementos son recopilaciones de cmdlets que se usan para administrar una aplicación o un componente principal. Si no los carga primero, no podrá usarlos. Afortunadamente, el complemento del Shell de administración de Exchange es muy fácil de iniciar. Pero antes de describir este proceso, debería explicar algunos conceptos clave que deberá comprender al leer este artículo y usar el Shell de administración de Exchange.
Cmdlets Los cmdlets parecen comandos incorporados en otros shells; por ejemplo, el comando dir del programa cmd.exe. Al igual que estos comandos conocidos, los cmdlets se pueden invocar directamente desde la línea de comandos del Shell de administración de Exchange y ejecutar bajo el contexto del shell, no como un proceso independiente. A diferencia de los comandos de otros shells, los cmdlets llevan nombres descriptivos tipo verbo-objeto. El verbo describe la acción que realiza el cmdlet y el objeto describe el componente o la función sobre la que se realizará la acción.
De este modo, no es necesario adivinar lo que hace un cmdlet. Cuando vea el cmdlet Move-Mailbox, sabrá que se usa para mover el buzón.
Para conocer cómo los cmdlets difieren de comandos normales, consulte la barra lateral "Diferencias entre los cmdlets y los comandos", que proviene de la sección .NET Framework 3.0 del SDK de Windows® y se encuentra en windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx.
Parámetro de identidad y posición El parámetro Identity (Identidad) puede usarse en la mayoría de los cmdlets relacionados con Exchange. Éste proporciona acceso a los identificadores únicos que hacen referencia a un objeto en particular en Exchange Server 2007 para poder realizar acciones en dicho objeto de Exchange específico mediante el valor único que más sentido tenga para el usuario.
El parámetro Identiy es una recopilación de valores de otros parámetros. Se garantiza que estos parámetros son únicos en un conjunto de objetos. Los valores de estos otros parámetros, por ejemplo Name y DistinguishedName, se pueden especificar o bien generarse mediante el sistema como, por ejemplo, un GUID. Los parámetros adicionales que se usen, si los hay, y cómo se completan, depende del objeto al que se hace referencia.
El parámetro Identiy también se considera como un parámetro de posición, es decir, un parámetro que permite especificar su valor sin especificar su nombre. Un parámetro es de posición si el atributo Parameter Position es un número entero. Este número entero indica la posición en la línea de comandos en la que el cmdlet encontrará el valor del parámetro. Dado que Identity es un parámetro de posición que reside en la posición 0, que es la primera posición, cualquier valor especificado en esta posición sin el nombre del parámetro se considerará como un valor del parámetro Identity. De este modo, se reduce el número de pulsaciones de teclas al escribir los comandos. Por ejemplo,
Get-Mailbox –Identity "Kim Akers"
realiza la misma acción que:
Get-Mailbox "Kim Akers"
Canalización La canalización en el Shell de administración de Exchange es el hecho de que un cmdlet usa el resultado de otro cmdlet cuando realiza una operación. La canalización se efectúa mediante el símbolo de barra vertical "|". Todos los verbos en el mismo conjunto nombre-cmdlet pueden usar la información canalizada de otro comando. Algunos conjuntos nombre-cmdlet permiten pasar datos a través de la canalización a otro conjunto nombre-cmdlet.
El uso de la canalización para encadenar las acciones de dos o más cmdlets permite convertir componentes de menor tamaño en elementos más eficaces. Por ejemplo, puede usar un cmdlet para recopilar datos, pasar dichos datos a un segundo cmdlet para filtrarlos en un subconjunto y, a continuación, pasar dichos datos hacia un tercer cmdlet para que actúe solamente sobre el subconjunto.

Inicio del Shell de administración de Exchange
La manera más sencilla de cargar el shell es haciendo clic en Inicio, Programas, Microsoft Exchange Server 2007. A continuación, seleccione Shell de administración de Exchange.
La segunda manera de cargar el complemento del Shell de administración de Exchange es manualmente desde una sesión de Windows PowerShell. Haga clic en Inicio, Programas y, a continuación, seleccione Windows PowerShell. Una vez iniciado, ejecute el comando siguiente para cargar el Shell de administración de Exchange:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Existen algunas diferencias entre cargar el complemento del Shell de administración de Exchange mediante el menú Programas e iniciarlo manualmente mediante el cmdlet Add-PSSnapin. Cuando se usa el menú Programas, no solamente se carga el complemento del Shell de administración de Exchange, sino que también se ejecuta una secuencia de comandos de Windows PowerShell para configurar un entorno de administración de Exchange personalizado. Si desea configurar un entorno de administración similar tras la carga manual del Shell de administración de Exchange, cambie al directorio bin de instalación de Exchange. Por ejemplo, C:\Archivos de programa\Microsoft\Exchange Server\Bin. A continuación, ejecute el comando siguiente:
.\Exchange.ps1
Consulte la secuencia de comandos Exchange.ps1 para ver cómo personalizar el entorno de Windows PowerShell para que se adapte a sus necesidades. Al cargar el Shell de administración de Exchange, verá algo parecido a lo que se muestra en la figura 2.
Figura 2 Encabezado de bienvenida del Shell de administración de Exchange
Figura 2 Encabezado de bienvenida del Shell de administración de Exchange (Hacer clic en la imagen para reducirla)
Figura 2 Encabezado de bienvenida del Shell de administración de Exchange
Figura 2 Encabezado de bienvenida del Shell de administración de Exchange (Hacer clic en la imagen para ampliarla)

¿Por dónde comenzar?
Dado que el shell dispone de una gama tan amplia de cmdlets, el cmdlet Get-Help y el archivo de ayuda de Exchange Server 2007 serán recursos muy valiosos. La sección de operaciones del archivo de ayuda de Exchange Server 2007 proporciona docenas de procedimientos para llevar a cabo la mayoría de las tareas de administración.
Si escribe sólo Get-Help, aparecerá la información de ayuda general sobre cómo obtener ayuda. Para obtener ayuda sobre un cmdlet en particular, escriba Get-Help seguido del cmdlet acerca del que desea obtener información. Para controlar la información presentada, use los parámetros Detailed, Full y Example. Simplemente agréguelos al final del comando. Por ejemplo, Get-Help nombre cmdlet –Full devuelve todas las secciones de ayuda disponibles para un cmdlet en particular.
Si desea recuperar información sobre uno o varios parámetros de un cmdlet, puede usar el parámetro Parameters con Get-Help. Por lo tanto, si desea ver todos los parámetros del cmdlet Set-Mailbox que contienen la palabra "quota" y sus descripciones, use el comando:
Get-Help Set-Mailbox –Parameter *quota*
Es posible que desee ver una lista de los cmdlets que administran una función de servidor específica o una característica de componente en particular o bien que afecta a los objetos en un alcance determinado de funcionalidad. El cmdlet Get-Help permite realizar esta operación mediante tres parámetros: Role, Component y Functionality. Cuando el cmdlet Get-Help se usa con estos parámetros, deberá escribir los valores que especifique con dichos parámetros entre caracteres de comodín ("*"). A continuación se incluyen algunos ejemplos de cómo invocar Get-Help con cada parámetro:
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
Si desea obtener más información, consulte el tema "Obtener ayuda" del archivo de ayuda de Exchange Server 2007 para obtener una lista de los valores de función, componente y funcionalidad que se pueden usar.

Formato del resultado de los comandos
De manera predeterminada, cuando la salida aparece en pantalla, el Shell de administración de Exchange solamente muestra un subconjunto de las propiedades disponibles para cada objeto. Sin embargo, puede obtener acceso fácilmente a todas las propiedades canalizando el resultado de un comando hacia los tres cmdlets de formato: Format-List, Format-Table y Format-Wide. Es probable que use Format-List y Format-Table con frecuencia, por lo que hablaré sobre éstos.
El cmdlet Format-List toma el resultado de la canalización y proporciona una lista de columnas verticales de todas las propiedades especificadas de cada objeto. Puede especificar las propiedades que desee visualizar mediante el parámetro Property, aunque este parámetro es un parámetro de posición, lo que significa que sólo es necesario especificar los valores y no el nombre. Si se invoca el cmdlet Format-List sin especificar ningún parámetro, se proporcionarán todas las propiedades. Este cmdlet ajusta las líneas en lugar de truncarlas. Uno de los mejores usos de Format-List es para anular el resultado predeterminado de un cmdlet para poder recuperar información adicional o más detallada. Por ejemplo,
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
La figura 3 muestra el resultado de este comando.
Figura 3 Ejemplo del resultado de Format-List
Figura 3 Ejemplo del resultado de Format-List (Hacer clic en la imagen para reducirla)
Figura 3 Ejemplo del resultado de Format-List
Figura 3 Ejemplo del resultado de Format-List (Hacer clic en la imagen para ampliarla)
El cmdlet Format-Table permite mostrar los elementos en forma de tabla con encabezados de etiqueta y columnas de datos de propiedad. De manera predeterminada, un gran número de cmdlets, como por ejemplo, Get-Mailbox y Get-JournalRule, usan el formato de tabla para el resultado. Entre los parámetros del cmdlet Format-Table se incluyen Properties y GroupBy. Éstos funcionan exactamente del mismo modo que con el cmdlet Format-List. Para que líneas largas de información de propiedad se muestren completamente en lugar de truncarse al final de una línea, use el parámetro Wrap del modo siguiente:
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
Consulte la figura 4 para ver el resultado.
Figura 4 Ejemplos del resultado de Format-Table
Figura 4 Ejemplos del resultado de Format-Table (Hacer clic en la imagen para reducirla)
Figura 4 Ejemplos del resultado de Format-Table
Figura 4 Ejemplos del resultado de Format-Table (Hacer clic en la imagen para ampliarla)
Si incluye un carácter comodín, puede hacer coincidir varias propiedades sin tener que escribir cada nombre de propiedad de manera individual. Por ejemplo, lo siguiente devuelve todas las propiedades que comienzan con E-mail.
Get-Mailbox | Format-List Email*

Pongámoslo en práctica
Ahora que ha aprendido algunos comandos básicos, puede ejecutar los ejemplos siguientes. Estos ejemplos muestran la eficacia y flexibilidad del Shell de administración de Exchange y permiten poner en práctica algunos comandos.
Con el primer comando creará 10 usuarios, denominados de User1 a User10:
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
Analicemos las secciones. El comando 1.0 da como resultado los números enteros de 1 a 10 y los canaliza hacia el cmdlet ForEach. El cmdlet ForEach actúa sobre cada objeto a medida que lo recibe y ejecuta los comandos dentro de las llaves { } para cada objeto. El comando Net User crea un nuevo usuario de dominio y el cmdlet Enable-Mailbox crea un buzón nuevo en la base de datos de buzones ("Mailbox Database") del servidor local. El punto y coma (;) separa los dos comandos para que se puedan colocar en la misma línea de comandos. La variable $_ es una variable especial que contiene el valor del objeto actual en la canalización. En este ejemplo, la variable $_ contiene el número entero que se encuentra actualmente en la canalización.
El siguiente ejemplo permitirá visualizar los buzones que residen en el servidor MBX y devolver las propiedades de nombre, base de datos de buzones y cuota de todos los buzones.
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
El cmdlet Get-Mailbox devuelve todos los buzones especificados con el parámetro Server y, a continuación, canaliza el resultado de cada objeto de buzón al cmdlet Format-Table. De forma predeterminada, el cmdlet Format-Table muestra todas las propiedades que devuelve un cmdlet, a menos que se especifiquen las propiedades que se deben mostrar. Aquí, se solicitan solamente las propiedades de nombre y base de datos, así como todas las propiedades que contienen la cadena "quota". La figura 5 muestra el aspecto de este resultado.
Figura 5 Resultado del comando Get-Mailbox
Figura 5 Resultado del comando Get-Mailbox (Hacer clic en la imagen para reducirla)
Figura 5 Resultado del comando Get-Mailbox
Figura 5 Resultado del comando Get-Mailbox (Hacer clic en la imagen para ampliarla)
En este ejemplo, establecerá el límite de cuota de envío en 600 MB para todos los usuarios de la organización habilitados para correo y que tienen el título de gerente (Manager).
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
Cuando se ejecuta solo, el cmdlet Get-User devuelve todos los objetos de usuario de Active Directory, incluidos los usuarios que no tienen el buzón habilitado. Para recuperar un conjunto de objetos de usuario que el cmdlet Set-Mailbox pueda usar, deberá indicarle al cmdlet Get-User que devuelva sólo los objetos de usuario de Active Directory que sean usuarios habilitados para correo. El parámetro RecipientTypeDetails permite especificar el tipo de destinatario de Active Directory; en este caso, UserMailbox. A continuación, debe recuperar un conjunto de usuarios habilitados para correo con el título de gerente. En este ejemplo, se completa la propiedad Title de cada objeto de usuario de Active Directory. Puede usar este valor para determinar los usuarios que son gerentes mediante el parámetro Filter, que indica al servidor que devuelva solamente los objetos de Active Directory que coincidan con sus criterios. Esto se denomina filtrado desde el servidor. Cuando haya obtenido un conjunto de objetos, éste se canaliza hacia el cmdlet Set-Mailbox, que establece la propiedad ProhibitSendQuota de cada buzón en 600 MB.
A continuación, realizaremos una prueba del resultado de un comando para quitar todos los buzones que pertenecen a un grupo de distribución. El comando es el siguiente:
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
El primer cmdlet recupera los objetos de destinatario que pertenecen al grupo de distribución Fourth Year Students. A continuación, únicamente los objetos de destinatario que coincidan con la propiedad RecipientType de "UserMailbox" se canalizan hacia el cmdlet Remove-Mailbox. En lugar de quitar los buzones, el cmdlet Remove-Mailbox mostrará la acción que hubiera llevado a cabo y los objetos sobre los que hubiera actuado. El cmdlet Get-DistributionGroupMember recupera una lista de todos los objetos de destinatario que pertenecen al grupo de distribución "Fourth Year Students". Sin embargo, dado que el cmdlet Remove-Mailbox sólo puede funcionar con usuarios habilitados para correo, deberá filtrar todos los tipos de destinatario excepto "UserMailbox". A diferencia de otros cmdlets, el cmdlet Get-DistributionGroupMember no dispone del cmdlet Filter, lo que significa que no puede realizar el filtrado desde el servidor. Para los cmdlets que no pueden realizar el filtrado desde el servidor (debido a que no proporciona ninguna ventaja de rendimiento), puede usar el cmdlet Where para realizar un filtrado desde el cliente, lo que recupera todos los objetos y realiza el filtrado en el equipo cliente local. El cmdlet Where sólo permite canalizar objetos que coincidan con los criterios especificados. Los objetos con la propiedad RecipientType de "UserMailbox" se envían al cmdlet Remove-Mailbox. Este cmdlet quita los objetos de usuario de Active Directory y marca el buzón para su eliminación. Cuando se usa el parámetro WhatIf, el cmdlet Remove-Mailbox muestra texto similar al siguiente:
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
Si está satisfecho que el comando realice las acciones deseadas, vuelva a ejecutar el comando sin WhatIf. Para algunos cmdlets, como por ejemplo, los que llevan el verbo Remove, el shell solicitará automáticamente confirmación antes de realizar cualquier cambio. Tiene la opción de pasar por cada cambio, indicarle al shell que no debe solicitar confirmación o cancelar todo procesamiento subsiguiente. Para los cmdlets que no implementan la confirmación automáticamente, puede forzarla mediante el parámetro Confirm.

Conclusión
Ahora que ha probado la eficacia de los cmdlets, estará listo para experimentarlo por sí mismo y ver hasta qué punto tanto el Shell de administración de Exchange como Microsoft Windows PowerShell le ayudarán en las tareas futuras de administración de sistemas. Si desea obtener más información sobre ambos temas, consulte los recursos siguientes. En el caso del Shell de administración, consulte el archivo de ayuda de Exchange Server 2007 en la dirección go.microsoft.com/fwlink/?LinkId=69434, el centro de secuencias de comandos de Windows Powershell en la dirección go.microsoft.com/fwlink/?LinkId=71134 y el blog del equipo de Exchange en la dirección msexchangeteam.com.

David Strome es escritor técnico del grupo Exchange User Education en Microsoft desde hace poco más de un año. Antes de unirse a Microsoft en Redmond, WA, David pasó aproximadamente diez años diseñando, implementando y administrando instalaciones de Exchange Server en distintas empresas en British Columbia, Canadá. Puede ponerse en contacto con él en la dirección dstrome@microsoft.com.


 Exchange Server 2007: Exchange &amp; Outlook: Better Together
Exchange Server 2007 Michael Khalili

Exchange & Outlook: Better Together
Resumen:
  • Configuración simplificada
  • Integración de voz, fax y correo electrónico
  • Carpetas administradas para el cumplimiento

Durante varios años, Microsoft Exchange Server y Outlook proporcionaron un servicio de correo electrónico confiable a millones de personas, ayudaron a los usuarios a colaborar y administrar sus calendarios y simplificó la tarea de organizar los contactos. Cabría preguntarse cómo se puede mejorar esta combinación. Pues bien, Exchange Server 2007
y Microsoft Office Outlook 2007 van a lanzarse pronto al mercado, y juntos ofrecen un salto cuántico en el ámbito de la comunicación y la colaboración.
Las mejoras que ofrecen Exchange Server 2007 y Office Outlook® 2007 son evidentes desde el momento en que se inicia el cliente Outlook. En versiones anteriores, Outlook esperaba que el usuario conociera el nombre de su servidor de buzones de Exchange, pero esto suponía un impedimento para muchos usuarios. Como resultado, se realizaban frecuentes llamadas al departamento de soporte o se generaban complicadas secuencias de comandos de inicialización, lo que hacía aumentar el costo y la complejidad que implicaba ejecutar un entorno de mensajería efectivo. Actualmente, gracias al servicio Web de detección automática de Exchange, Outlook puede configurar automáticamente una cuenta si el cliente se une al dominio. Si el cliente no forma parte del dominio, el usuario sólo deberá escribir un nombre, una dirección de correo electrónico y una contraseña. Outlook y Exchange averiguarán el resto (consulte la figura 1).
Figura 1 Configuración de cuentas
Figura 1 Configuración de cuentas (Hacer clic en la imagen para reducirla)
Figura 1 Configuración de cuentas
Figura 1 Configuración de cuentas (Hacer clic en la imagen para ampliarla)
Asimismo, antiguamente los usuarios no sólo configuraban Outlook para su uso inicial, sino que también eran responsables de reconfigurarlo siempre que se les cambiaba a un servidor de correo diferente. Aun cuando se enviara un mensaje de correo electrónico para avisar a los usuarios de que iba a haber una migración de buzones inminente, los trabajadores ocupados hacían poco caso de todo lo que tuviera que ver con la migración inminente, hasta que una mañana al llegar a la oficina se daban cuenta de que no podían obtener acceso a Outlook. Llegado este punto, se producía otra llamada al departamento de soporte. Los servicios Web de detección automática también solucionan este problema. Cuando se cambia a un usuario de un servidor de buzones a otro, Outlook reconoce que la antigua configuración ya no es válida, vuelve a consultar el servicio Web de detección automática y reconfigura el cliente para el nuevo buzón. Todo este proceso es completamente transparente para el usuario final.

Reinvención del calendario
En el pasado, casi toda la lógica de calendario residía en Outlook. Cada actualización de reunión era tratada como una invitación de reunión independiente, lo que significaba que las notificaciones se podían aceptar sin seguir un orden. Si se enviaban dos actualizaciones de reunión sucesivamente y un destinatario aceptaba la segunda actualización de reunión antes que la primera, podía tener información no actualizada en su calendario. Además, el acceso a información de Outlook desde Smartphones o PDA podía presentar discrepancias en la información sobre el estado de disponibilidad o no disponibilidad según el método con el que los usuarios visualizaran los datos.
La solución consistía en mover toda la lógica de calendario del cliente Outlook a Exchange Server 2007. Cuando el servidor recibe una solicitud de reunión, la reunión se coloca automáticamente en el calendario como provisional hasta que el usuario elige aceptar o rechazar la cita. Si se recibe un cambio de hora o ubicación de la reunión, la reunión se actualizará automáticamente y la invitación anterior se marcará como caducada para que los usuarios no la acepten accidentalmente. Esta lógica es coherente entre todos los clientes: Office Outlook, Outlook Web Access, Outlook Mobile u otros clientes de terceros, por lo tanto, sólo están presentes las reuniones correctas y más actualizadas.
Con un calendario de precisión tan confiable, se hace posible ofrecer un nuevo conjunto de herramientas que pueda aumentar la productividad de los usuarios. En el pasado, no era fácil establecer reuniones con varios empleados ocupados. Los usuarios tenían que encontrar horas libres para las reuniones manualmente, desplazándose por días de información para encontrar una hora adecuada para todos los asistentes. Ahora, el asistente para programación de Outlook 2007, que se muestra en la figura 2, puede encontrar la mejor hora para todos los asistentes. Después de especificar los asistentes obligatorios y opcionales y las salas o recursos elegidos, el asistente para programación presenta una vista codificada en colores de los mejores días para una reunión. Una vez elegido un día, se usa el mismo esquema para buscar la mejor hora durante ese día.
Figura 2 Asistente para programación
Figura 2 Asistente para programación (Hacer clic en la imagen para reducirla)
Figura 2 Asistente para programación
Figura 2 Asistente para programación (Hacer clic en la imagen para ampliarla)
El asistente para programación da prioridad a los asistentes obligatorios, a continuación, a los asistentes opcionales y, finalmente, a las salas y los recursos para determinar la hora óptima para una reunión. El asistente para programación también facilita el tratamiento de temas como las horas de trabajo flexibles y las distintas zonas horarias. Los usuarios pueden establecer sus propias horas de trabajo definiendo la hora de llegada cada mañana y la hora de salida al final del día. Por lo tanto, una persona que se vaya tarde a dormir y no llegue al trabajo hasta las 9 o las 10 de la mañana puede establecer que su horario de trabajo empiece a esa hora. Cuando otras personas tengan que programar una reunión, no se sugerirá ninguna hora que sea anterior, por ejemplo, las 8 de la mañana. Si dos grupos de distintas zonas horarias, por ejemplo, uno en Londres y otro en Los Ángeles, tienen que reunirse, sólo se sugerirán las horas que coincidan en sus días laborables. Para los asistentes de Londres la reunión será a última hora de la tarde y para los asistentes de Los Ángeles a primera hora de la mañana, a diferencia de una reunión que sea a las 2 de la mañana para uno u otro grupo.

Cómo encontrar una aguja en un pajar
A lo largo de los años, el número de mensajes de correo electrónico que llegan a la bandeja de entrada de un usuario medio ha ido creciendo a un ritmo alarmante. Mientras que antes un buzón de trabajo típico podía contener sólo unos doscientos mensajes, ahora algunas personas reciben ese número de mensajes en un solo día. En esta avalancha de mensajes se oculta una gran riqueza de información, que es esencial para las operaciones de cualquier empresa. Encontrar la información adecuada cuando las necesita puede ser un reto considerable.
Las funciones de búsqueda de Office Outlook 2007 y Exchange Server 2007 han mejorado enormemente respecto a versiones anteriores. Tanto si un usuario está en modo de caché o en modo en línea, se aplican al mensaje los mismos algoritmos de búsqueda. En el modo en línea, la consulta de búsqueda se envía al servidor de Exchange, donde se ejecuta la búsqueda. El indizador de contenido de Exchange, que es hasta 35 veces más rápido que el indizador de Exchange Server 2003, sirve para garantizar que los mensajes se puedan encontrar y recuperar rápidamente. En el modo de caché, Outlook usa la búsqueda instantánea, basada en Windows® Desktop Search 3.0, con lo que los motores de indización se consolidan y se reduce el tiempo de CPU. Se pueden realizar búsquedas de texto incluido en el asunto, el cuerpo, los campos para y de, o incluso en los archivos adjuntos, como se muestra en la figura 3.
Figura 3 Nuevas formas de buscar un mensaje de correo electrónico importante
Figura 3 Nuevas formas de buscar un mensaje de correo electrónico importante (Hacer clic en la imagen para reducirla)
Figura 3 Nuevas formas de buscar un mensaje de correo electrónico importante
Figura 3 Nuevas formas de buscar un mensaje de correo electrónico importante (Hacer clic en la imagen para ampliarla)

Acceso ilimitado con la mensajería unificada
La mensajería unificada de Exchange, que es un componente integrado de Exchange Server 2007, incluye en una sola bandeja de entrada todo tipo de comunicaciones empresariales, como por ejemplo, el correo electrónico, el correo de voz y el fax. En los sistemas tradicionales, el correo de voz está disponible a través del teléfono, el correo electrónico a través de un equipo y el fax a través de un equipo de fax dedicado. La mensajería unificada de Exchange permite al usuario elegir el mejor cliente para sus necesidades a una hora y un lugar concretos. En Outlook, los mensajes de voz y fax aparecen en la bandeja de entrada que está junto a los mensajes de correo electrónico. Cuando se selecciona, el mensaje de correo de voz contiene un reproductor incrustado para que el mensaje pueda reproducirse directamente desde el panel de lectura (consulte la figura 4).
Figura 4 Reproducción de mensajes de correo de voz mediante Outlook
Figura 4 Reproducción de mensajes de correo de voz mediante Outlook (Hacer clic en la imagen para reducirla)
Figura 4 Reproducción de mensajes de correo de voz mediante Outlook
Figura 4 Reproducción de mensajes de correo de voz mediante Outlook (Hacer clic en la imagen para ampliarla)
Outlook también permite administrar mensajes en contexto. Normalmente, cuando se escucha un mensaje de correo de voz se toman notas en un papel. Estas notas no están asociadas con el mensaje y se pueden perder (esto sería difícilmente un modelo de comunicación eficaz). Con la mensajería unificada de Exchange, las notas se pueden escribir directamente en Outlook. Las notas se conservan con el mensaje y se indizan como texto en el que se pueden realizar búsquedas, lo que garantiza que aparezcan siempre en el contexto del mensaje de correo de voz. De este modo, se pueden encontrar fácilmente mediante la búsqueda mejorada de Exchange Server 2007 y Office Outlook 2007.
Outlook también puede administrar numerosas opciones de correo de voz (consulte la figura 5), como por ejemplo, la opción que permite que los usuarios puedan cambiar su número de identificación personal (PIN) de buzón de voz desde el cliente. El restablecimiento del PIN es una importante fuente de llamadas al departamento de soporte para los sistemas de correo de voz. Desde las opciones de Outlook, se puede generar un nuevo PIN para los usuarios y éstos lo pueden recibir por correo electrónico. Este PIN les ofrece acceso una sola vez a en la interfaz telefónica de mensajería unificada de Exchange, Outlook Voice Access, y después se les solicita que lo cambien.
Figura 5 La mensajería unificada incluye una opción de restablecimiento de PIN
Figura 5 La mensajería unificada incluye una opción de restablecimiento de PIN (Hacer clic en la imagen para reducirla)
Figura 5 La mensajería unificada incluye una opción de restablecimiento de PIN
Figura 5 La mensajería unificada incluye una opción de restablecimiento de PIN (Hacer clic en la imagen para ampliarla)

Para la protección
Las organizaciones se enfrentan actualmente a muchas amenazas en su entorno de mensajería. Outlook y Exchange funcionan conjuntamente para luchar contra estas amenazas. El correo electrónico no deseado es sólo una de esas amenazas, y Office Outlook 2007 agrega compatibilidad para el certificado electrónico Outlook, que es una nueva forma de combatir dicho correo. Outlook realiza un pequeño rompecabezas de cálculo en el correo saliente y agrega la respuesta a este rompecabezas en el mensaje. A continuación, Exchange comprueba los resultados. Aunque estos rompecabezas de cálculo requieren poco tiempo de CPU cuando se realizan sólo una vez, como suele ocurrir con el correo legítimo, si el equipo de una persona que envía correo electrónico no deseado tuviera que crear estos rompecabezas para un correo electrónico en masa, la demanda de recursos en su equipo sería extrema. Por lo tanto, un mensaje con un certificado electrónico Outlook es mucho más probable que sea legítimo que un mensaje que no tenga dicho certificado, y Exchange lo tiene en cuenta al determinar la validez de cada mensaje de correo electrónico.
Además de las típicas amenazas como el correo electrónico no deseado, nuevas disposiciones legales están cambiando los requisitos para los sistemas de mensajería. Disposiciones legales como Sarbanes-Oxley, HIPPA y Basel II imponen reglas estrictas para la retención o destrucción de registros. Para satisfacer esta necesidad emergente, Exchange y Outlook presentan las carpetas administradas. Estas carpetas las configura un administrador para mensajes de un tipo concreto. En Outlook, el usuario final ve estas carpetas con una descripción del contenido almacenado en su interior (consulte la figura 6). También se pueden enviar mensajes automáticamente a una carpeta concreta mediante las reglas de transporte de Exchange. Una vez dentro de una carpeta administrada, los mensajes conservarán las directivas de archivo, retención y caducidad de dicha carpeta y serán tratados automáticamente de una forma que sea coherente con la directiva de la organización.
Figura 6 Las carpetas administradas refuerzan las reglas de cumplimiento del correo electrónico.
Figura 6 Las carpetas administradas refuerzan las reglas de cumplimiento del correo electrónico. (Hacer clic en la imagen para reducirla)
Figura 6 Las carpetas administradas refuerzan las reglas de cumplimiento del correo electrónico.
Figura 6 Las carpetas administradas refuerzan las reglas de cumplimiento del correo electrónico. (Hacer clic en la imagen para ampliarla)
A pesar de todos los esfuerzos, ocasionalmente se producen infracciones de cumplimiento. En estas instancias, es imprescindible una rápida identificación y reparación. La búsqueda rápida que ofrece Exchange se convierte en una herramienta fundamental para los jefes de cumplimento, ya que les ayuda a encontrar mensajes que puedan ser indicios para la identificación de infracciones de cumplimiento. Las búsquedas se pueden realizar en distintos buzones a fin de localizar y corregir tales infracciones.

Un entorno más fácil de administrar
Exchange Server 2007 y Office Outlook 2007 combinados ofrecen un sistema de mensajería mucho mejor que las versiones anteriores. Reúnen en un solo lugar todas las comunicaciones empresariales esenciales, facilitan su búsqueda y su configuración y las hacen más seguras y compatibles de forma inmediata. Ambos llevan la colaboración y la comunicación al siguiente nivel.

Michael Khalili es el Director de productos de Exchange Server y el responsable del acceso de clientes y la mensajería unificada. Entre otras cosas, es responsable de la integración de Outlook-Exchange.


 Exchange Server 2007: Mant&#233;ngase siempre al corriente con Exchange 2007
Exchange Server 2007 Joshua Trupin

Manténgase siempre al corriente con Exchange 2007
Resumen:
  • Mejoras de Outlook Web Access
  • Mensajería unificada en Exchange Server 2007
  • Seguridad con el ISA Server 2006

Años atrás, la comunicación en línea era básica. Los mensajes de correo electrónico se enviaban a través de POP3 y SMTP. Era bastante simple. Pero claro, las necesidades cambian. Actualmente, las organizaciones tienen que ofrecer a los empleados la
flexibilidad de poder trabajar cuándo y cómo lo deseen, y tienen que hacerlo de forma segura. Microsoft® Exchange Server 2007 dispone de varias características incorporadas que tratan estas necesidades, como por ejemplo, Microsoft Office Outlook® Web Access (OWA) y la mensajería unificada. Vamos a analizar estos dos componentes clave de Exchange Server 2007 y la forma en que superan a versiones anteriores para crear una plataforma de comunicaciones más eficaz para el entorno empresarial actual.
OWA forma parte de Exchange desde la versión 5.5. Francamente, las primeras versiones eran un poco rudimentarias. Ofrecían una respuesta al problema de obtener acceso a un buzón de Exchange con un explorador Web, pero sin contar con muchas de las funciones que proporciona Outlook.
Gracias a la mejora de OWA que trajo consigo Exchange Server 2003, la situación empezó a mejorar para los usuarios finales. La experiencia basada en un explorador se hizo mucho más fácil, casi como si se trabajara en un programa cliente. OWA para Exchange Server 2007 mejora aún más la experiencia del explorador, ya que incluye una actualización completa de las versiones anteriores, lo que le permite aprovechar otras innovaciones técnicas recientes, como por ejemplo, RPC a través de HTTP y ASP.NET 2.0.
Por ejemplo, considere la forma en que OWA realiza su representación. En las versiones anteriores de OWA el servidor de buzones realizaba la representación durante el proceso de almacenamiento. Esto agregaba una carga adicional en el servidor de buzones, lo que podía ser la causa de otro tipo de ralentizaciones en el sistema. Outlook Web Access 2007, por el contrario, presenta los datos a través de ASP.NET en servidores de acceso de cliente (CAS). Esto elimina el procesamiento de páginas del servidor de buzones, con lo que se mejora el rendimiento.
El trabajo realizado en las aplicaciones de usuario también ha cambiado. En versiones anteriores de Exchange, las solicitudes de OWA HTTP se enviaban a través de proxy al servidor de buzones adecuado. Exchange Server 2007 reduce el tráfico asociado a OWA obteniendo los datos directamente del servidor de buzones adecuado a través de RPC. Éste es más o menos el mismo proceso que permite usar Outlook en un cliente que no esté en una conexión de red privada virtual (VPN) de su empresa. Por lo tanto, la información del buzón la presenta OWA. Exchange Server 2007 también puede enviar a través de proxy solicitudes OWA, pero en lugar de enviarlas directamente a servidores de buzones, las reenvía a otros servidores CAS.
La figura 1 muestra la arquitectura de OWA en Exchange Server 2007.
Figura 1 Cómo tiene acceso OWA a los recursos de Exchange Server
Figura 1 Cómo tiene acceso OWA a los recursos de Exchange Server (Hacer clic en la imagen para reducirla)
Figura 1 Cómo tiene acceso OWA a los recursos de Exchange Server
Figura 1 Cómo tiene acceso OWA a los recursos de Exchange Server (Hacer clic en la imagen para ampliarla)

Administración
La arquitectura actualizada de Exchange Server 2007 incluye opciones ampliadas para la administración de OWA. Puede usar la Consola de administración de Exchange o el Shell de administración de Exchange. Los valores de configuración se almacenan en varios lugares.
La Consola de administración de Exchange permite tener acceso a la mayoría de valores de configuración posibles, como por ejemplo, la habilitación o deshabilitación de características mediante la segmentación, el bloqueo de datos adjuntos, la autenticación y el acceso a características como el calendario, la lista de tareas y la corrección ortográfica. Las tareas del Shell de administración de Exchange permiten realizar las mismas acciones que la Consola de administración de Exchange.
Además, el Shell de administración de Exchange permite crear y eliminar directorios virtuales nuevos para OWA. También puede ejercer un control más preciso sobre la configuración de segmentación por usuario y cambiar la configuración de idioma predeterminada, entre otras cosas.
El registro de Windows es el almacén predeterminado para los tiempos de espera de la autenticación basada en formularios. Esta configuración no está disponible a través de la Consola de administración de Exchange ni el Shell de administración de Exchange. Con Active Directory® puede tener acceso a valores de configuración específicos de OWA, como el bloqueo de datos adjuntos y la segmentación. La metabase de IIS contiene valores (autenticación, GZIP) que influyen en el comportamiento de IIS. Y web.config incluye valores de ASP.NET como "maxuploadsize", que controla la carga de datos adjuntos de OWA.

Autenticación
OWA proporciona varias opciones de autenticación en el servidor. Una vez realizada la instalación, la seguridad toma como valor predeterminado la autenticación basada en formularios. Sin embargo, la seguridad se puede mejorar de tantas maneras como sea necesario para satisfacer los requisitos de su organización. IIS llevará a cabo la autenticación en Active Directory para garantizar que el usuario que está intentando conectarse tenga derechos de dominio. También puede usar la autenticación básica, la autenticación de texto implícita, RSA SecurID o incluso un inicio de sesión de SmartCard para tener acceso al correo electrónico.
El nivel máximo de seguridad para OWA es la seguridad integrada de Windows, donde se combinan Kerberos y NTLM. De hecho, este tipo de seguridad es necesaria para el acceso a elementos Web de Outlook Web Access 2007, así como para el envío a través de proxy CAS entre los sitios de Active Directory. También ofrece una ventaja adicional para los usuarios que tienen acceso a OWA en una intranet: proporciona un inicio de sesión único con la autenticación de cliente Windows, así que no tiene que iniciar sesión en OWA si ya es un usuario de confianza.
Si usa la autenticación basada en formularios, que es el valor predeterminado, OWA se interrumpirá automáticamente después de un período de inactividad. Según si el usuario elige un equipo público o un equipo privado (cuando se le solicite al iniciar la sesión), el tiempo de espera puede ser de 15 minutos (en el caso de los equipos públicos) o puede llegar a ser de 8 horas (en el caso de un equipo privado). La elección de un equipo público frente a un equipo privado es importante para sus usuarios, ya que en función de este valor se pueden configurar de modo distinto otros valores de configuración. Por ejemplo, puede bloquear datos adjuntos en equipos públicos o cambiar los tiempos de espera de autenticación. Fundamentalmente, la autenticación basada en formularios es un proceso que consta de cuatro pasos, tal como se muestra en la figura 2.
Figura 2 Proceso de autenticación
  1. Los clientes envían solicitudes al servidor, sin cifrar.
  2. El servidor devuelve una cookie cifrada a los clientes.
  3. Los servidores siguen descartando y creando claves de cifrado nuevas y conservan las tres claves más recientes en la memoria.
  4. Los clientes que envían solicitudes con una clave de cifrado obsoleta que todavía está en la memoria reciben una nueva cookie cifrada con la clave más reciente.
    £o bien£
    Los clientes que envían solicitudes con una clave de cifrado obsoleta que ha sido descartada y ha agotado el tiempo de espera deben volver a iniciar sesión.

msExchQueryBaseDN es el mecanismo que se usa para restringir el acceso a determinados usuarios para que sólo vean una sección de la libreta de direcciones de OWA. msExchQueryBaseDN está registrado en objetos de usuario de Active Directory y apunta a una lista de direcciones (AL) o una unidad organizativa (OU). Esta AL se usará como lista global de direcciones (GAL) del usuario, y el usuario verá una GAL que sólo incluirá cuentas de usuario en esta OU. Puede establecer msExchQueryBaseDN mediante LDAP.

Compatibilidad con versiones anteriores
La base de Outlook Web Access en Exchange Server 2007 es CAS, y el modelo CAS se ha desarrollado para proporcionar la mejor interoperabilidad posible con servidores que ejecutan versiones anteriores de Exchange. Para garantizar que funcione, siempre deberá implementar o actualizar los servidores CAS antes de actualizar los servidores de buzones asociados correspondientes.
Un servidor Exchange 2007 con la función CAS puede usarse para conectar con buzones en servidores Exchange 2000 y Exchange 2003. Tanto RPC a través de HTTP como Exchange ActiveSync® seguirán funcionando con una actualización parcial del sitio. OWA y WebDAV también funcionarán si obtiene acceso a ellos a través de los directorios virtuales /exchange, /public o /exchweb. En Exchange Server 2007 también puede crear directorios virtuales de OWA personalizados para estas versiones anteriores.

El ISA Server 2006 es su amigo
Outlook Web Access ha mejorado respecto a Exchange Server 2007, pero se puede mejorar aún más si se ejecuta con Internet Security and Acceleration (ISA) Server 2006.
El ISA Server 2006 es una puerta de enlace de seguridad perimetral integrada. Además de ayudar a proteger su sitio de las amenazas que se originan en Internet, proporciona acceso remoto seguro a aplicaciones y datos. Dado que ese es también el objetivo de OWA, la ejecución conjunta de ambos servidores le proporciona el concepto informático más fabuloso: la sinergia. Para obtener más información general sobre el servidor ISA, eche un vistazo a microsoft.com/isaserver/2006.
El ISA Server 2006 proporciona varias ventajas al atareado administrador de Exchange. Por ejemplo, la característica WPLB (Web Publishing Load Balancing) permite equilibrar las cargas mediante el uso de cookies HTTP. Puede garantizar la afinidad de cliente-servidor incluso cuando cambia la IP de cliente. El ISA Server 2006 también proporciona compresión y descompresión GZIP, lo que permite analizar el tráfico o la compresión de descarga desde servidores Web. Con el ISA Server 2004, tenía que hacer una elección: podía usar la compresión HTTP con OWA o usar la autenticación basada en formularios con el servidor ISA. Afortunadamente, el ISA Server 2006 admite ambos simultáneamente.
Además, puede realizar la traducción de vínculos OWA a través del servidor ISA. Si alguien pone un vínculo de intranet en el correo electrónico de OWA, el servidor ISA puede traducirlo en un vínculo de Internet adecuado. Esto puede ser bastante útil, pero tiene que acordarse de publicar los vínculos de intranet en la misma matriz de ISA que publica OWA.
Lo más importante quizás es que el ISA Server 2006 realiza una autenticación previa para ayudarle a proteger la red en el perímetro. La autenticación previa tiene como objeto garantizar que el tráfico HTTP malintencionado no llegue a los servidores. Si el tráfico dirigido a los CAS es válido, el servidor ISA lo hará circular rápidamente desde el perímetro hasta el dominio. Los servidores de perímetro se encuentran fuera del dominio de la intranet y bloquean el tráfico que no pertenece a dicho dominio. Los CAS no deben implementarse en el dominio del perímetro; deben estar en el dominio de la intranet para poder tener acceso a las cuentas de usuario de Active Directory.

Solución de problemas de Outlook Web Access
Outlook Web Access 2007 presenta nuevas herramientas que mejoran la supervisión y la solución de problemas. Una tarea de supervisión se ejecuta automáticamente en el servidor CAS. Esta tarea comprueba la conectividad de cada uno de los servidores de buzones, así como los inicios de sesión de OWA. Exchange Server 2007 proporciona también mensajes de registro de eventos y contadores de rendimiento mucho más detallados.
Exchange Server Best Practices Analyzer (consulte nuestra descripción en microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange) se ha mejorado para alertar a los administradores de los avisos y errores importantes si OWA no está configurado correctamente. También puede generar informes sobre el uso de OWA a partir de los registros de IIS mediante la herramienta LogParser (descrita en el número correspondiente a octubre de 2006 en microsoft.com/technet/technetmag/issues/2006/10/LogParser).

Mensajería unificada
Cuando OWA trata las necesidades de la empresa móvil, la mensajería unificada consolida distintas formas de mensajería en un solo lugar (de ahí su nombre). Actualmente, el correo electrónico se encuentra en Exchange Server. Las opciones de voz (llamadas telefónicas y el correo de voz) está disponible en un servidor de telefonía. Recibe el correo electrónico en el escritorio y el correo de voz a través del teléfono. ¡Y ya ni hablaré de los mensajes de fax!
La mensajería unificada de Exchange Server 2007 permite que una organización envíe datos de correo electrónico, voz y fax a una sola bandeja de entrada, a la que los usuarios pueden tener acceso a través de Outlook y OWA. La mensajería unificada funciona también en dirección opuesta: los usuarios pueden tener acceso al correo de voz, al correo electrónico, a los contactos y a los calendarios por teléfono con Outlook Voice Access.
Para el administrador de sistemas, la mensajería unificada simplifica la mensajería mediante la combinación de las infraestructuras de Exchange y la telefonía para ofrecerle una solución de almacenamiento, un directorio y un transporte. El nivel general de complejidad se reduce cuando cada persona tiene un solo buzón.
¿Y cuál es la mejor parte? Todo esto puede llevarse a cabo con los servidores existentes, y si ya conoce Exchange Server 2007 y la telefonía, la curva de aprendizaje es bastante plana. Las características de la mensajería unificada están integradas en Exchange: se usa el mismo modelo de seguridad y las mismas bandejas de entrada. Incluso puede tener acceso al correo de voz y mensajes de fax a través de OWA.
La figura 3 muestra la arquitectura de la mensajería unificada en Exchange Server 2007 con la función de servidor de mensajería unificada instalado. Obsérvela con detenimiento (quizás encuentre unas preguntas más tarde) y, a continuación, analizaremos la arquitectura de la mensajería unificada con más detenimiento.
Figura 3 La mensajería unificada reúne las comunicaciones de voz, fax y correo electrónico.
Figura 3 La mensajería unificada reúne las comunicaciones de voz, fax y correo electrónico. (Hacer clic en la imagen para reducirla)
Figura 3 La mensajería unificada reúne las comunicaciones de voz, fax y correo electrónico.
Figura 3 La mensajería unificada reúne las comunicaciones de voz, fax y correo electrónico. (Hacer clic en la imagen para ampliarla)
Cuando la mensajería unificada se configura en una empresa, deben tenerse en cuenta muchos elementos. Exchange Server contiene objetos que representan hardware de telefonía. Por tanto, estos objetos pueden tener definidas sus relaciones dentro del entorno de Exchange Server. Entre los objetos del sistema de mensajería unificada de Exchange Server se encuentran el servidor de MU, el plan de conmutación de llamadas de MU, la puerta de enlace IP de MU y el grupo de búsqueda de MU, así como la directiva de buzón de MU y el operador automático de MU. Echemos un vistazo a cómo cada uno de estos objetos justifica su existencia.
El objeto de servidor de MU se crea en Active Directory, donde está instalada la función de servidor de MU. Éste permite que un administrador controle la instalación y las propiedades de una implementación de mensajería unificada de Exchange Server 2007. El plan de conmutación de llamadas de MU es la unidad administrativa básica dentro de la mensajería unificada y representa la forma en que se usan las extensiones internamente. Todos los usuarios de un plan de conmutación de llamadas pueden comunicarse con los demás simplemente marcando su extensión. Si une otras ubicaciones, normalmente cada una de ellas tendrá su propio plan de conmutación de llamadas.
El objeto de puerta de enlace IP de MU representa una puerta de enlace VoIP (voz a través de IP) física o una IP PBX (infraestructura de central de conmutación) habilitado por SIP (Protocolo de inicio de sesión). Un servidor de mensajería unificada puede recibir llamadas desde un dispositivo de puerta de enlace IP/VoIP. Un grupo de búsqueda de MU vincula una puerta de enlace IP a un plan de conmutación de llamadas de MU. Tras configurar un grupo de búsqueda en PBX, se crea un grupo de búsqueda de MU en Active Directory para representar esto. Puede configurar el grupo de búsqueda para proporcionar equilibrio de carga en las puertas de enlace IP. Estas puertas de enlace, a su vez, pueden proporcionar equilibrio de carga asociando un solo grupo de búsqueda de MU a varias puertas de enlace. Las directivas de buzón de MU son análogas a las clases de servicio de correo de voz. Dichas directivas incluyen un plan de conmutación de llamadas y propiedades que establecen directivas operativas para usuarios y grupos.
El operador automático de MU puede asociarse a un solo plan de conmutación de llamadas de MU. Se puede personalizar para que realice varias tareas, como por ejemplo, el registro de solicitudes personalizadas y la definición de tareas para días y horas diferentes. El alcance de los operadores automáticos se puede limitar mediante listas de direcciones.
La figura 4 muestra cómo estos seis objetos de mensajería unificada funcionan juntos.
Figura 4 Interacción de los objetos de telefonía de mensajería unificada
Figura 4 Interacción de los objetos de telefonía de mensajería unificada (Hacer clic en la imagen para reducirla)
Figura 4 Interacción de los objetos de telefonía de mensajería unificada
Figura 4 Interacción de los objetos de telefonía de mensajería unificada (Hacer clic en la imagen para ampliarla)

Configuración
Una vez que un usuario tiene un buzón de Exchange Server 2007, el administrador debe habilitarlo para la mensajería unificada. Para ello, el administrador debe asociar el buzón a una directiva de buzón de MU y a un número de extensión, ambos dentro del plan de conmutación de llamadas. También se debe configurar PBX para enrutar la llamada a la mensajería unificada de RNA (llamada sin respuesta). El PBX enrutará primero la llamada a la extensión del usuario. A continuación, si se genera una RNA, la llamada se enrutará a la puerta de enlace VoIP y, después, al servidor de mensajería unificada.
La mensajería unificada es escalable. Puede agregar tantos servidores de MU y canales PBX conmutados por circuito como necesite para conseguir capacidad. Cuando use puertas de enlace VoIP, las llamadas basadas en IP se enviarán a la mensajería unificada de Exchange. Dado que ésta es una nueva función para muchas empresas, deberá realizar un análisis completo de la red para asegurarse de que la red IP tiene el ancho de banda necesario para manejar los datos y la voz.
Un servidor típico de mensajería unificada de Exchange Server 2007 puede atender entre 50 y 200 llamadas IP simultáneas y hasta 200 llamadas de voz y fax entrantes (éstas se establecen en 100 de forma predeterminada). Puede agregar servidores de mensajería unificada adicionales si necesita más capacidad o si desea aumentar la tolerancia a errores.

Conclusión
¡Ahí lo tiene! Exchange Server 2007 proporciona dos características, Outlook Web Access y la mensajería unificada, que juntas ofrecen enormes ventajas a una organización. Outlook Web Access permite tener acceso al correo electrónico de forma segura desde cualquier lugar, y la mensajería unificada permite a los usuarios tener acceso a su correo electrónico, correo de voz, mensajes de fax y otros datos del buzón que puedan llegar a su buzón de Exchange 2007.

Joshua Trupin es el editor ejecutivo de MSDN Magazine y TechNet Magazine. Ha escrito numerosos artículos para MSJ, MIND, MSDN Magazine, y TechNet Magazine, así como un libro, Hoop Stats: The Basketball Abstract.


 Exchange Server 2007: Una elaboraci&#243;n de diarios m&#225;s eficaz en Exchange 2007
Exchange Server 2007 David Strome

Una elaboración de diarios más eficaz en Exchange 2007
Resumen:
  • Reglas del diario de Exchange Server 2007
  • El nuevo Asistente para diarios
  • ¿Qué contiene un informe de diario?

¿Alguna vez ha tenido que incluir en el diario mensajes de correo electrónico entrantes y salientes de un usuario específico y ha obtenido los mensajes que buscaba junto con los mensajes de los otros 300 buzones que
residen en ese almacén del buzón? Microsoft Exchange Server 2007 soluciona este problema y le proporciona el control granular necesario.
El registro en diario por destinatario, disponible con las Licencias de acceso de cliente (CAL), permite definir quién debe incluirse en el diario. A través de las reglas de diario, ahora puede definir solamente los destinatarios y remitentes que desee incluir en el diario. Puede restringir el enfoque a un solo buzón, o bien ampliarlo para incluir todo el personal de un departamento de ventas, por ejemplo. Y no hace falta que los buzones se encuentren en el mismo servidor, el mismo sitio de Active Directory® ni incluso la misma organización que usa Exchange. A través de la réplica de Active Directory, los cambios se aplican automáticamente a todos los equipos que ejecutan la función de servidor de transporte del concentrador en la organización.

Funcionamiento del registro en diario
En Exchange Server 2003, el registro en diario se implementó en almacenes del buzón individuales en cada servidor físico. Si deseaba incluir en el diario todos los buzones de la organización, debía configurar el registro en diario para cada uno de los almacenes del buzón. Y si deseaba incluir en el diario los mensajes de un único destinatario, debía incluir todos los usuarios del almacén del buzón de ese usuario o bien crear un nuevo almacén del buzón específico para dicho usuario.
El registro en diario de Exchange Server 2007 usa la nueva topología basada en funciones de Exchange. Tal como se indica en la figura 1, los servidores de transporte del concentrador procesan todos los mensajes entrantes y salientes de los servidores de buzones y de mensajería unificada, de otros sistemas de Exchange, de aplicaciones de otros proveedores y de Internet. Todos los servidores de transporte del concentrador contienen un agente de transporte denominado agente de registro en diario, que es el responsable de aplicar las reglas del diario a los mensajes. Dado que el agente de registro en diario está ubicado en los servidores de transporte del concentrador, encuentra y evalúa todos los mensajes antes de que lleguen al destinatario. El agente de registro en diario actúa en el mensaje después de la categorización. De este modo, se garantiza el acceso a todos los atributos de destinatario y remitente del mensaje y permite al agente determinar si el mensaje se envió directamente a un destinatario o si se recibió a través de una expansión de grupos de distribución. Además, también puede saber si el destinatario se encontraba en las líneas Para, CC o CCO de un mensaje con origen en la organización que usa Exchange Server 2007.
Figura 1 Flujo de correo del servidor de transporte del concentrador
Figura 1 Flujo de correo del servidor de transporte del concentrador (Hacer clic en la imagen para reducirla)
Figura 1 Flujo de correo del servidor de transporte del concentrador
Figura 1 Flujo de correo del servidor de transporte del concentrador (Hacer clic en la imagen para ampliarla)
El agente de registro en diario aplica reglas de diario configuradas por el administrador a los mensajes a medida que éstos pasan por el servidor de transporte del concentrador. Estas reglas determinan si el agente capturará información acerca de un mensaje y la reenvían junto con el mensaje original a un buzón de diario. Estos datos se envían en un mensaje denominado informe de diario.
Con las versiones anteriores de Exchange, era necesario aplicar configuraciones a varios servidores. Sin embargo, cuando se crea una regla de diario en Exchange Server 2007, ese cambio se aplica a todos los servidores de transporte del concentrador en la organización a través de Active Directory. Todos los servidores de transporte del concentrador y, por tanto, todos los agentes de registro en diario leen la misma configuración desde Active Directory. Por consiguiente, esta cobertura global garantiza que todos los agentes de registro en diario aplican la misma configuración de registro en diario.
Al crear o modificar reglas de diario, tenga en cuenta la réplica de Active Directory, ya que una modificación en la configuración debe replicarse en toda la organización y la deben leer los servidores de transporte del concentrador. Este proceso puede tardar varias horas. Para ayudarle a identificar que se ha actualizado la configuración de registro en diario, Exchange registra un evento en el registro de eventos de seguridad de cada servidor.
Exchange Server 2007 asegura que un informe de diario nunca se pierde debido a un buzón de diario no disponible, independientemente de que esté lleno, mal configurado o esté desconectado. (Esto es de especial utilidad a la hora de satisfacer los distintos requisitos y disposiciones legales, ya que la pérdida de mensajes puede causar un incumplimiento.) Si un informe de diario no se puede entregar a un buzón de diario, el informe permanece en la cola del servidor de transporte del concentrador hasta que el buzón de diario se encuentre disponible. Dado que esto puede ocasionar un rápido crecimiento de las colas, debe controlar la disponibilidad del buzón de diario para asegurarse de que funciona correctamente. Si un buzón de diario permanece no disponible durante un período prolongado, puede configurar uno alternativo para recibir los informes que se encuentran en la cola.

Qué incluir en el diario
Antes de comenzar a crear reglas de diario, debe tener una idea clara de lo que desea hacer y qué tipos de datos desea incluir en el diario. Al especificar un usuario en una regla de diario, puede seleccionar usuarios específicos para el registro en diario. Por ejemplo, estos usuarios pueden estar sujetos a requisitos de disposiciones legales, o bien pueden estar implicados en un proceso legal que requiere que los mensajes de correo electrónico y otras comunicaciones se recopilen como pruebas.
Además de especificar los destinatarios que se deben incluir en el diario, con las opciones Internos, Externos o Global, también puede determinar el alcance de los mensajes que se incluirán en el diario. La opción Internos tiene como objetivo sólo los mensajes de la organización, la opción Externos tiene como objetivo sólo los mensajes en los que el remitente o uno de los destinatarios son externos y la opción Global tiene como objetivo tanto los mensajes internos como los externos. (Tenga en cuenta que la opción Global incluye en el diario todos los mensajes que atraviesan el servidor de transporte del concentrador, incluso los que ya se han procesado mediante las reglas con los alcances Internos y Externos).
Exchange Server 2007 admite la mensajería unificada, de modo que puede configurar Exchange para que recopile el correo electrónico, el correo de voz y los faxes de la bandeja de entrada de un usuario. Esto significa que, además, puede incluir en el diario todos estos datos o bien excluir datos específicos.
Si ejecuta Exchange Server 2007 con licencias de acceso de cliente (CAL) estándar, aún puede usar el registro en diario de almacenes por buzón. Sin embargo, si desea usar las nuevas funciones de registro en diario por destinatario, deberá actualizar a las CAL empresariales de Exchange Server 2007.

Dónde colocar el buzón de diario
Cuando haya decidido los elementos que se deben incluir en el diario, debe decidir dónde enviar los informes de diario. Si cuenta con varios sitios, deberá tener en cuenta la topología de red actual o planeada a la hora de decidir dónde colocar los buzones de diario. Según el tamaño de la organización y el número de buzones, el registro en diario puede tener como resultado un importante número de informes repetitivos.
Sin embargo, no es necesario limitarse a los buzones de Exchange. Puede enviar informes de diario a cualquier dirección SMTP válida. Esta dirección puede dirigirse a servicios alojados de Exchange, a una solución de archivado de otro proveedor o cualquier combinación de ambos mediante un grupo de distribución. No obstante, tenga en cuenta que hay implicaciones de seguridad específicas relacionadas con el destino al que envía los informes de diario.
Independientemente de dónde decide colocar el buzón de diario, deberá crear un objeto de destinatario para éste en Active Directory. Éste puede ser un buzón de Exchange Server 2007, un contacto con capacidad de correo que redirija el correo a los servicios alojados de Exchange o a una solución de archivado de otro proveedor o bien una lista de distribución que contenga tanto buzones como contactos.

¿Qué contiene un informe de diario?
Cuando un agente de registro en diario incluye un mensaje en el diario, intenta capturar la mayor cantidad posible de detalles sobre el mensaje original en un informe de diario. A continuación, este informe se envía al buzón de diario. La información es muy importante a la hora de determinar la intención del mensaje, los destinatarios y los remitentes. Por ejemplo, el lugar en que se identifican los destinatarios (directamente en el campo Para, en el campo CC o simplemente como parte de una lista de distribución) puede ayudar a determinar cómo interviene el destinatario en la discusión del mensaje. El mensaje original se incluye como datos adjuntos. Las capturas de pantalla de la figura 2 muestran un informe de diario que indica que un mensaje enviado a david@contoso.com se ha reenviado a christine@contoso.com y otro informe de diario que indica que un mensaje enviado al grupo de distribución Sales_Group@contoso.com se ha expandido y el destinatario lukas@contoso.com, que es miembro del grupo de distribución Sales Group, ha recibido el mensaje. Ambos informes contienen el mensaje original como datos adjuntos, muestran que el remitente original ha sido brian@contoso.com y tienen el asunto "Sales forecast".
Figura 2 Informes de diario que muestran un destinatario de reenvío y un destinatario del grupo de distribución expandido
Figura 2 Informes de diario que muestran un destinatario de reenvío y un destinatario del grupo de distribución expandido (Hacer clic en la imagen para reducirla)
Figura 2 Informes de diario que muestran un destinatario de reenvío y un destinatario del grupo de distribución expandido
Figura 2 Informes de diario que muestran un destinatario de reenvío y un destinatario del grupo de distribución expandido (Hacer clic en la imagen para ampliarla)
Exchange sólo clasifica información que sabe que es correcta. La información que no se puede determinar automáticamente se coloca en los campos adecuados en el informe de diario. En la figura 2 se describen los campos que se incluyen en el cuerpo del informe de diario.

Todo sobre la seguridad
De manera predeterminada, toda la comunicación entre los equipos que ejecutan Exchange Server 2007 en la misma organización que usa Exchange se cifra. Este cifrado incluye los informes de diario. Exchange Server realiza una serie de tareas para ayudar a disminuir el riesgo de que se manipulen los informes de diario:
  • En la organización que usa Exchange 2007, se usan vínculos seguros entre los servidores de transporte del concentrador y los servidores de buzones.
  • Los informes de diario se envían como "Microsoft Exchange" de parte del remitente del mensaje original.
  • Las sesiones entre el servidor de transporte del concentrador y el servidor de buzones se autentican.
  • Cuando se envían informes de diario entre los servidores de transporte del concentrador y los servidores de buzones en la misma organización que usa Exchange 2007, sólo se aceptan conexiones autenticadas.
Al crear un buzón de diario, deberá garantizar su seguridad ya que el buzón contiene mensajes entrantes y salientes de los destinatarios de la organización. Es posible que algunos mensajes formen parte de un proceso legal o que estén sujetos a requisitos de disposiciones legales, y existen distintas leyes que exigen que los mensajes no se puedan manipular antes de que se envíen a una autoridad de investigación. Para aumentar la seguridad del buzón de diario, deberá configurarlo para que acepte solamente mensajes del remitente de Microsoft Exchange y deberá exigir que todos los mensajes enviados al buzón de diario sean enviados por remitentes autenticados. La figura 3 muestra las restricciones de entrega de mensajes configuradas en un buzón de diario. También puede usar el siguiente comando de Shell de administración de Exchange para configurar estas restricciones de entrega de mensajes:
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
Figura 3 Restricciones de entrega de mensajes
Figura 3 Restricciones de entrega de mensajes (Hacer clic en la imagen para reducirla)
Figura 3 Restricciones de entrega de mensajes
Figura 3 Restricciones de entrega de mensajes (Hacer clic en la imagen para ampliarla)
Si envía informes de diario a un buzón de diario externo a la organización que usa Exchange Server 2007, deberá cifrar manualmente la conexión entre los equipos con Exchange Server 2007 y el servidor de recepción y garantizar la seguridad de ésta. Para ello, puede requerir el uso de la seguridad de la capa de transporte (TLS) entre los dos sistemas, requerir la autenticación en el sistema de recepción, aceptar en el sistema de recepción solamente mensajes procedentes de la dirección SMTP del destinatario de Microsoft Exchange (esta dirección SMTP será similar a Exchange_UMUnique GUID@contoso.com) y configurar el contacto de Active Directory que se usa para reenviar mensajes para que acepte mensajes solamente del destinatario de Microsoft Exchange.

Implementación de las reglas de diario
Dejemos de hablar e implementemos algunas reglas. Las reglas de diario del agente de registro en diario se pueden configurar en el Shell de administración de Exchange o en la Consola de administración de Exchange. Cada una puede usarse para configurar los parámetros del destinatario, del alcance y del buzón de diario. De forma predeterminada, las reglas de diario se habilitan en el momento de su creación. El valor que especifique para la dirección de correo electrónico del diario debe ser un objeto de destinatario existente en la organización que usa Exchange Server 2007. Este objeto de destinatario puede ser un buzón, un grupo de distribución, un grupo de distribución dinámico o un contacto que envía correo a una dirección SMTP.
Si se usa la Consola de administración de Exchange, el Asistente para crear nueva regla de diario le mostrará los pasos para crear nuevas reglas de diario. En la sección Configuración de la organización, seleccione la función de servidor de transporte del concentrador. A continuación, en el panel Acción, haga clic en Nueva regla del diario. Aquí, indique los valores del nombre de la regla, la dirección de correo electrónico de diario y el alcance. No es necesario especificar un valor para el campo Destinatario si desea que la regla de diario incluya en el diario los mensajes de todos los destinatarios de la organización. Durante su creación, también puede elegir si desea que la regla de diario se pueda deshabilitar. En la figura 4 se muestra un ejemplo de configuración que incluirá en el diario todos los mensajes entrantes y salientes de brian@contoso.com. Los mensajes del diario se envían a un buzón de diario denominado Buzón de cumplimiento.
Figura 4 Asistente para crear nueva regla de diario
Figura 4 Asistente para crear nueva regla de diario (Hacer clic en la imagen para reducirla)
Figura 4 Asistente para crear nueva regla de diario
Figura 4 Asistente para crear nueva regla de diario (Hacer clic en la imagen para ampliarla)
En el Shell de administración de Exchange, puede usar los seis cmdlet siguientes para administrar el agente de registro en diario:
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
El cmdlet New-JournalRule permite crear una nueva regla de diario. Los criterios básicos para la creación de una nueva regla de diario de esta manera son los mismos que cuando se usa el asistente. Debe especificar valores para los parámetros Name, Scope y JournalEmailAddress. De nuevo, es necesario especificar un valor para el campo Destinatario si desea que la regla de diario incluya en el diario los mensajes de todos los destinatarios de la organización. Además, si al crear la regla de diario desea que ésta se deshabilite, deberá especificar un valor de $False en el parámetro Enabled. Para crear una nueva regla de diario con la misma configuración que la indicada en la figura 4, use el comando siguiente:
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
El cmdlet Get-JournalRule se usa para ver una lista de todas las reglas de diario que haya creado. Si ejecuta este cmdlet solo, aparecerá una lista resumida de todas las reglas de diario configuradas en la organización y los parámetros de configuración. Si desea ver toda la información disponible sobre una regla de diario, puede canalizar el cmdlet Get-JournalRule al cmdlet Format-List. La canalización envía los resultados de un cmdlet al siguiente cmdlet, de modo que este último pueda realizar un procesamiento adicional en los resultados. Por ejemplo, el cmdlet Format-List muestra todos los resultados que recibe. Para ver toda la información disponible sobre la regla de diario creada anteriormente, puede usar el comando siguiente:
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
Para habilitar o deshabilitar una regla de diario, use los cmdlets Enable-JournalRule y Disable-JournalRule. Al usar estos cmdlets, deberá especificar el nombre de la regla de diario en el parámetro Identity. Por ejemplo, para deshabilitar la regla de diario que se acaba de crear, use el comando siguiente:
Disable-JournalRule -Identity "Brian Smith Journal Rule"
El cmdlet Set-JournalRule permite modificar una regla de diario existente. El nombre de la regla de diario se usa con el parámetro Identity para notificar al agente de registro en diario sobre la regla que se está modificando. A continuación, debe especificar los parámetros Recipient, JournalEmailAddress, Scope o cualquier combinación de éstos junto con el nuevo valor. Por ejemplo, para modificar el valor almacenado en el parámetro JournalEmailAddress para la regla que se ha creado, use el comando siguiente:
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
Por último, puede usar el cmdlet Remove-JournalRule para quitar una regla de diario existente. Debe especificar el nombre de la regla de diario mediante el parámetro Identity. Para eliminar la regla de diario de ejemplo, use el comando siguiente:
Remove-JournalRule "Brian Smith Journal Rule"
A continuación, el Shell de administración de Exchange le solicitará confirmación de la eliminación de la regla de diario. Un último consejo: con casi todos los cmdlets, puede omitir la etiqueta del parámetro Identity y, simplemente, especificar el valor del parámetro.

David Strome es escritor técnico del grupo Exchange User Education en Microsoft desde hace poco más de un año. Antes de unirse a Microsoft en Redmond, WA, David pasó aproximadamente diez años diseñando, implementando y administrando instalaciones de Exchange Server en distintas empresas en British Columbia, Canadá. Puede ponerse en contacto con él en la dirección dstrome@microsoft.com.


 Exchange Server 2007: Contra el correo no deseado y la suplantaci&#243;n de identidad con un Id. de remitente
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

Contra el correo no deseado y la suplantación de identidad con un Id. de remitente
Resumen:
  • Conceptos básicos del Id. de remitente
  • Configuración del Id. de remitente en Exchange Server
  • Ventajas de la autenticación

Muchas tecnologías de identificación y filtrado se han desarrollado en respuesta a la creciente amenaza del correo no deseado. Para ser eficaces, formulan determinadas preguntas acerca de cada mensaje de correo electrónico, como por ejemplo,
quién lo envió. Desafortunadamente, no siempre es fácil responder a la cuestión fundamental de quién envió el mensaje. Normalmente, el correo electrónico se envía por Internet sin ninguna autenticación del remitente ni de los equipos que actúan en nombre del remitente. Lo cierto es que resulta fácil enviar un mensaje de correo electrónico fingiendo ser otra persona y que no existe ningún método automatizado para detectar mensajes simulados.
El Protocolo simple de transferencia de correo (SMTP), que se usa para enviar y recibir correo electrónico, no se diseñó para comprobar el remitente de un mensaje de correo electrónico. Aprovechando esta vulnerabilidad tecnológica, puede insertarse cualquier nombre y dirección como remitente. Por consiguiente, las medidas de filtrado de contenido o de protección contra el correo no deseado no pueden depender únicamente de la información del encabezado para garantizar que los mensajes realmente procedan de la dirección indicada.
La autenticación de correo electrónico intenta resolver específicamente esta vulnerabilidad. A través de la autenticación, tanto los sistemas de envío como de recepción de correo electrónico validan los mensajes que proceden de los dominios mostrados. Esto facilita que las organizaciones puedan filtrar el correo no deseado de forma eficaz y también garantiza que el correo electrónico legítimo llegue hasta los destinatarios pertinentes.
Actualmente, existen dos enfoques libres de regalías en la autenticación de correo electrónico: el marco de Id. de remitente (SIDF) y DomainKeys Identified Mail (DKIM). SIDF es una solución basada en el protocolo de Internet (IP) que se creó a partir de la fusión de Sender Policy Framework (SPF) y Microsoft Caller ID for E-Mail. En abril de 2006, Internet Engineering Task Force (IETF) publicó las especificaciones de Id. de remitente como RFC 4405-4408. Una coalición de participantes del sector y de empresas, incluido Microsoft, recomienda la implementación de SIDF en función de factores que incluyan valor empresarial y técnico, estabilidad, madurez, facilidad de implementación, impacto mínimo en el rendimiento saliente o entrante e interoperabilidad con el ecosistema de correo electrónico para los entornos empresariales y los ISP.
DKIM es la fusión de Yahoo! Especificaciones de DomainKeys e Identified Internet Mail (IIM) de Cisco Systems Incorporated. En enero de 2006, IETF aprobó la creación de un grupo de trabajo DKIM y, actualmente, está revisando la especificación.
Aunque no existe una solución perfecta para combatir el correo no deseado, SIDF representa una importante iniciativa en el sector para combatir los dominios simulados. Por lo tanto, es un componente clave en la reducción del correo no deseado y los ataques de suplantación y en el aumento de la confianza en línea. Las organizaciones de todo el mundo están adoptando SIDF rápidamente. Hoy día, más de 5,5 millones de empresas y propietarios de dominios han publicado registros SPF y más de 600 millones de usuarios están protegidos por SIDF. Actualmente, más de un tercio del volumen de correo electrónico diario mundial es autenticado por SIDF y compatible con éste.
El desarrollo de SIDF y su adopción en todo el mundo no serían posibles sin la colaboración y el apoyo de muchas organizaciones y empresas, como por ejemplo, AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, etc.

Descripción del Id. de remitente
Algunas encuestas del sector indican que más del 95 por ciento de las operaciones de suplantación de identidad proceden de dominios simulados y tienen direcciones de correo electrónico de destinatarios simulados. Aquí radica la enorme diferencia que distingue a SIDF respecto al procesamiento de la protección contra el correo no deseado. Por sí mismo, SIDF no puede solucionar el problema del correo no deseado, pero contribuye enormemente a minimizar sus consecuencias, así como los ataques de suplantación. SIDF no evita el envío de correo no deseado. Sin embargo, facilita en gran medida su detección. El marco ayuda a los remitentes de correo electrónico a proteger sus nombres de dominio, su reputación y sus marcas. Proporciona una base sólida para la toma de decisiones de filtrado en función de la reputación y el comportamiento de correo electrónico del remitente.
El Id. de remitente sirve para comprobar que los mensajes de correo electrónico se originan en los dominios de Internet que muestran. Esto se lleva a cabo comprobando la dirección del servidor que envía el correo electrónico con una lista de servidores registrados a los que el propietario del dominio ha autorizado para enviar correo electrónico. La comprobación la realiza automáticamente el proveedor de servicios de Internet (ISP) o el servidor de correo del destinatario antes de que el mensaje se envíe a la bandeja de entrada del usuario.
Tenga en cuenta que el Id. de remitente o cualquier otro mecanismo de autenticación no sustituye a los sistemas de filtrado de contenido. Ni SIDF ni DKIM exploran el contenido real del mensaje. Por el contrario, la autenticación notifica al sistema de correo entrante la validación del mensaje, si éste procede del destinatario indicado. Dado que la mayor parte del correo no deseado y de los ataques de suplantación no proceden realmente del dominio mostrado, este enfoque puede ayudar a identificar automáticamente estos mensajes y separarlos del flujo de correo entrante.
En SIDF, el registro SPF proporciona un registro de texto sencillo de todos los servidores de correo saliente asociados a un dominio, así como sus direcciones IP respectivas. Una organización publica el registro SPF en su archivo de zona de servidor DNS y, a continuación, los servidores de correo de destino lo comprueban. Un registro SPF se establece rápida y fácilmente, y además es gratis. El asistente para registros SPF del marco de Id. de remitente proporciona un proceso paso a paso para encuestar a los servidores de correo de un dominio y crear registros personalizados preparados para su publicación. En microsoft.com/senderid encontrará información detallada sobre cómo publicar un registro SPF. Se puede tener acceso directo al asistente desde microsoft.com/senderid/wizard.
El servidor de correo SMTP de recepción hace ping en el archivo de zona del dominio del DNS para comprobar si existe un registro SPF. Una vez encontrado, la dirección IP del servidor de envío se confronta con las direcciones IP de la lista. Si existe una coincidencia, el mensaje se valida como auténtico. Si, por otro lado, el registro SPF del domino del remitente no coincide con la dirección IP de la que procede el mensaje, se produce un error en el mensaje, lo que ocasiona una puntuación negativa y la posibilidad de colocar el mensaje en la carpeta de correo no deseado. La figura 1 muestra este proceso.
Figura 1 Comprobación de registros SPF para los mensajes entrantes
Figura 1 Comprobación de registros SPF para los mensajes entrantes (Hacer clic en la imagen para reducirla)
Figura 1 Comprobación de registros SPF para los mensajes entrantes
Figura 1 Comprobación de registros SPF para los mensajes entrantes (Hacer clic en la imagen para ampliarla)
Una vez etiquetado el mensaje, SIDF habilita al servidor de correo destinatario para analizar el mensaje en función de comportamientos anteriores, la reputación del remitente, su contenido y otros criterios que pueden definirse en caso necesario. Esta capacidad proporciona medidas de seguridad adicionales. Por ejemplo, las personas que envían correo no deseado pueden registrar dominios y registros SPF publicados que sean parecidos a fin de engañar a los usuarios y la red receptora haciéndoles creer que el correo procede de un remitente legítimo. Y aunque el mensaje de correo electrónico pueda pasar la comprobación de autenticidad, la reputación del remitente como persona que envía correo no deseado es suficiente para bloquear el mensaje, considerarlo como correo no deseado o eliminarlo.

Opciones de implementación del Id. de remitente
La autenticación del correo electrónico saliente a través de SIDF no requiere cambios de infraestructura ni actualizaciones de software, y no es específica del software de cliente ni de servidor. No obstante, una organización que desee incorporar la autenticación entrante para proteger a la propia organización y a los empleados deberá actualizar su sistema entrante y el Agente de transferencia de mensajes (MTA), e implementar software o un dispositivo que sea compatible con SIDF. La mayoría de los MTA comerciales más importantes de código abierto y de proveedores de protección contra el correo no deseado, incluido Microsoft® Exchange Server y Exchange Hosted Filtering, ofrecen soluciones integradas.
Microsoft ha integrado SIDF en todos sus productos de mensajería, entre los que se incluye Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express y los clientes de mensajería y colaboración de Office Outlook.
No obstante, ni siquiera Microsoft está exento de recibir correo no deseado. Por término medio, el tráfico entrante diario en Microsoft es aproximadamente de 15 millones de mensajes, y durante recientes ataques de correo no deseado hemos comprobado que se recibe de dos a cuatro veces más ese volumen. En un entorno de este tipo, la mejor vía de protección contra el correo no deseado consiste en una cuidadosa implementación de las tecnologías disponibles.
Microsoft está ejecutando internamente una solución de protección contra el correo no deseado de Exchange Server basada en el filtro de Id. de remitente de Exchange Server 2003 y el agente de Id. de remitente de Exchange Server 2007. En ambas versiones de Exchange Server, el estado del Id. de remitente se basa en la evaluación del registro de Id. del remitente situado en los servidores DNS correspondientes. El dominio real se determina examinando los encabezados de mensaje RFC 2822 según esta prioridad:
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
El dominio del remitente (o la entidad más reciente que sea responsable de insertar un mensaje en el flujo de mensajería, dado que los sistemas de correo electrónico pueden reenviar correo legítimamente en nombre de otros servidores de correo) se determina localizando la primera definición de los encabezados recién mencionados en el orden definido. Si no se encuentra ninguno de estos encabezados, SIDF usará el valor MAIL FROM de SMTP RFC 2821.

Configuración del Id. de remitente
En Exchange Server 2007, el agente de Id. de remitente se puede habilitar en servidores que tengan instalada la función de transporte perimetral. Si el agente de Id. de remitente está habilitado, filtrará los mensajes que lleguen a través de los conectores de recepción; todo el tráfico entrante (procedente de fuentes externas) no autenticado estará sujeto al procesamiento de Id. de remitente. En Exchange Server 2003, el estado del Id. de remitente se mantiene de servidor a servidor en el blob EXCH50; en Exchange Server 2007 también se ha agregado a los metadatos de los mensajes. En su destino final, ambos se convertirán en una propiedad MAPI para el uso futuro de los clientes.
La configuración de filtrado de Id. de remitente en Exchange Server 2003, disponible en las propiedades de entrega de mensajes, sólo consiste en especificar cómo Exchange Server maneja la validación con errores.
Para habilitar el Id. de remitente en Exchange Server 2007, abra la Consola de administración de Exchange de un servidor que tenga configurada la función de transporte perimetral, seleccione la ficha Protección contra el correo no deseado, el Id. de remitente y, en el panel Acciones, haga clic en Habilitar o Deshabilitar para alternar el agente de Id. de remitente como se muestra en la figura 2. También puede usar el Shell de administración de Exchange para habilitar o deshabilitar el Id. de remitente como se muestra en la figura 3.
Figura 2 Controles de la Consola de administración de Exchange para el agente de Id. de remitente en Exchange Server 2007
Figura 2 Controles de la Consola de administración de Exchange para el agente de Id. de remitente en Exchange Server 2007 (Hacer clic en la imagen para reducirla)
Figura 2 Controles de la Consola de administración de Exchange para el agente de Id. de remitente en Exchange Server 2007
Figura 2 Controles de la Consola de administración de Exchange para el agente de Id. de remitente en Exchange Server 2007 (Hacer clic en la imagen para ampliarla)
Figura 3 Habilitación del Id. de remitente mediante el Shell de administración de Exchange
Figura 3 Habilitación del Id. de remitente mediante el Shell de administración de Exchange (Hacer clic en la imagen para reducirla)
Figura 3 Habilitación del Id. de remitente mediante el Shell de administración de Exchange
Figura 3 Habilitación del Id. de remitente mediante el Shell de administración de Exchange (Hacer clic en la imagen para ampliarla)
El cuadro de diálogo Propiedades de ID del remitente refleja el estado del agente, que puede ser habilitado o deshabilitado. La ficha Acción proporciona opciones muy similares a las opciones disponibles en Exchange Server 2003 (consulte la figura 4).
Figura 4 Propiedades de las acciones de agente de Id. de remitente en Exchange Server 2007
Figura 4 Propiedades de las acciones de agente de Id. de remitente en Exchange Server 2007 (Hacer clic en la imagen para reducirla)
Figura 4 Propiedades de las acciones de agente de Id. de remitente en Exchange Server 2007
Figura 4 Propiedades de las acciones de agente de Id. de remitente en Exchange Server 2007 (Hacer clic en la imagen para ampliarla)
En cuanto a la implementación y funcionalidad del Id. de remitente, no existen diferencias importantes entre Exchange Server 2003 y Exchange Server 2007 y tanto el filtro de Id. de remitente (en Exchange Server 2003) como el agente de Id. de remitente (en Exchange Server 2007) usan el mismo algoritmo subyacente para la extracción y la comprobación. El rango de acciones posibles también es el mismo: Eliminar el mensaje (eliminación silenciosa), rechazar el mensaje (respuesta de protocolo SMTP de nivel 500) y marcar el mensaje con el resultado del Id. de remitente y continuar el procesamiento. La última opción es la acción predeterminada en ambas versiones de Exchange Server.
En Exchange Server 2007 tanto el código de estado FAIL como TempError pueden desencadenar una acción de rechazar el mensaje (en Exchange Server 2003 sólo el código de estado FAIL puede desencadenar esta acción). El agente de Id. de remitente debe configurarse explícitamente para desencadenar la acción de rechazar el mensaje en mensajes con un código de estado TempError ya que, de forma predeterminada, esos mensajes se aceptarán en el sistema, se marcarán con el resultado de Id. de remitente y después se procesarán.
Esta opción de configuración no se muestra en la interfaz gráfica de usuario, por tanto, deberá usar el Shell de administración de Exchange para configurar las acciones de Id. de remitente para el código de estado TempError. Por ejemplo, para obligar al agente de Id. de remitente a rechazar mensajes con el código de estado TempError, ejecute el cmdlet siguiente de agente de Id. de remitente:
Set-SenderIDConfig -TempErrorAction Reject
El rango de resultados del estado de Id. de remitente y de las acciones posibles de Exchange Server 2007 es similar al rango del filtro de Id. de remitente de Exchange Server 2003 y se muestra en la figura 5.
Figure 5 Estado del Id. de remitente y acciones de Exchange Server 2007 (Close Figure 5)

Estado del Id. de remitente | Descripción | Acciones
Neutral | Los datos del Id. de remitente publicados no son concluyentes explícitamente. | StampStatus
Pass | La dirección IP está en el conjunto permitido. | StampStatus
Fail | La dirección IP está en el conjunto no permitido. | StampStatus, Delete o Reject
SoftFail | La dirección IP puede estar en el conjunto no permitido. | StampStatus
Ninguna | No hay datos publicados. | StampStatus
TempError | Error transitorio, como un servidor DNS no disponible. | StampStatus o Reject
PermError | Error irrecuperable, como un error en el formato de registro. | StampStatus
Exchange sólo elimina (si se ha configurado con ese fin) los mensajes que dieron un error durante la comprobación del Id. de remitente. Ningún otro resultado desencadenará la eliminación de mensajes. Los mensajes entrantes que derivaron en la asignación de los estados Neutral, None, SoftFail, TempError o PermError se marcarán como corresponda y pasarán a la posterior comprobación de protección contra el correo no deseado. En algunos casos, cuando el mensaje tiene un formato totalmente incorrecto y falta la dirección IP FROM, el estado del Id. de remitente no se puede marcar en el mensaje. En esta situación, el mensaje no se descarta ni se rechaza. Por el contrario, pasa a su posterior procesamiento sin que tenga establecido el estado de Id. de remitente y se registra un evento apropiado para que se tenga en cuenta.
En Exchange Server 2007 es fácil definir los dominios de remitente y los destinatarios de Exchange Server que deben excluirse de la comprobación de Id. de remitente. Una vez más, esta opción de configuración sólo está disponible a través del Shell de administración de Exchange. Por ejemplo, para excluir el dominio contoso.com del filtrado de Id. de remitente, ejecute el comando siguiente:
Set-SenderIDConfig -BypassedSenderDomains contoso.com
Asimismo, para excluir los mensajes enviados a destinatarios específicos de Exchange Server del filtrado de Id. de remitente, ejecute el comando siguiente:
Set-SenderIDConfig -BypassedRecipients user@contoso.com
En Exchange Server 2007, los valores de configuración de Id. de remitente establecidos a través de cmdlets del Shell de administración de Exchange, pero no disponibles a través de la interfaz gráfica de usuario, pueden obtenerse fácilmente ejecutando el comando Get-SenderIDConfig en el Shell de administración de Exchange, como se muestra en la figura 6.
Figura 6 Cmdlets de configuración de Id. de remitente
Figura 6 Cmdlets de configuración de Id. de remitente (Hacer clic en la imagen para reducirla)
Figura 6 Cmdlets de configuración de Id. de remitente
Figura 6 Cmdlets de configuración de Id. de remitente (Hacer clic en la imagen para ampliarla)
El Shell de administración de Exchange se puede usar para comprobar manualmente y con rapidez las direcciones IP y el nombre de dominio correspondiente. Para comprobar el estado del Id. de remitente, ejecute el comando siguiente:
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
Si el dominio no existe, verá un resultado similar al que aparece en la figura 7.
Figura 7 Comprobación del estado de Id. de remitente de una dirección
Figura 7 Comprobación del estado de Id. de remitente de una dirección (Hacer clic en la imagen para reducirla)
Figura 7 Comprobación del estado de Id. de remitente de una dirección
Figura 7 Comprobación del estado de Id. de remitente de una dirección (Hacer clic en la imagen para ampliarla)

Ventajas del Id. de remitente
Aparte de sus evidentes ventajas en la autenticación de mensajes de correo electrónico y la reducción de la cantidad de correo no deseado que reciben los usuarios, SIDF, como protocolo, ofrece otras ventajas. Durante su desarrollo, Microsoft se centró en varios objetivos clave, como por ejemplo, el rendimiento, el costo, la implementación y escalabilidad, y la interoperabilidad.
SIDF primero autentica un remitente de correo electrónico y, a continuación, permite que la puntuación de la reputación del remitente se aplique a los mensajes. Como resultado, es posible que se reduzca considerablemente el correo no deseado y los mensajes de correo electrónico simulados, y que se mejore la entrega de correo electrónico legítimo procedente de remitentes conocidos y de confianza. La creación de un registro SPF es gratuita, por lo tanto, cualquier organización que desee adoptar SIDF puede hacerlo fácilmente. Las organizaciones que deseen cumplir las estipulaciones de un nuevo estándar deberán poder hacerlo. Con SIDF, el cumplimiento es tan fácil como publicar un registro SPF.
SIDF se ha desarrollado para funcionar en software existente, siempre que esto sea posible. Se puede usar con una amplia gama de arquitecturas de correo electrónico y software de cliente y servidor. Para ser eficaz, un servicio de autenticación debe poder satisfacer las necesidades de los ISP de gran tamaño sencillamente como si se tratara de un servidor de correo doméstico de menor tamaño. SIDF puede admitir desde un servidor de correo electrónico hasta miles de servidores, además de las organizaciones que subcontratan sus servidores de correo electrónico a otra organización.
Los días 18 y 19 de abril de 2007 Microsoft y un consorcio del sector formado por más de 30 organizaciones y socios organizarán una cumbre sobre la autenticación & la identidad en línea en Boston, MA. Este programa de dos días revisará casos prácticos y ofrecerá una revisión técnica del Id. de remitente, en la que se detallará el valor empresarial de la autenticación del correo electrónico. Para obtener más información, visite aotalliance.org/summit2007. Además, si desea obtener información sobre herramientas y recursos, puede visitar microsoft.com/senderid y microsoft.com/exchange.

Craig Spiezle es el Director de estrategia tecnológica y programación de Windows Live Safety en Microsoft. Como director de productos para la autenticación de correo electrónico, Craig ha impulsado la incorporación del Id. de remitente en el sector. Desde su incorporación en Microsoft en 1992, Craig ha ocupado diversos puestos de administración en áreas relacionadas con marketing internacional, estrategias de soporte de productos, OEM y el desarrollo de mercado emergente.
Alexander Nikolayev es el Administrador de programas de Microsoft y tiene a su cargo los protocolos de servidor, el centro de transporte y los componentes de protección contra el correo no deseado para Exchange Server y Windows Server. Tiene un máster en administración de empresas por la Universidad de Mary. Lea las exposiciones de Alexander en el blog del equipo de Exchange en blogs.technet.com/exchange.


 Nota del editor: Extender el alcance
Nota del editor
Extender el alcance

TECHNET MAGAZINE ES MÁS que la estupenda publicación que tiene en sus manos. Nuestro equipo ha estado trabajando frenéticamente para crear un sitio Web innovador que hará que nuestro contenido sea accesible a más de mil millones de personas en todo el mundo. A partir de la edición de noviembre, todos los artículos estarán disponibles en Internet en siete idiomas: inglés, español, francés, alemán, ruso, chino simplificado y portugués brasileño. Al agregar seis idiomas adicionales (el contenido ya está disponible en inglés), aumentamos en aproximadamente 1.600 millones el número de personas que pueden usar nuestro contenido en sus lenguas maternas. ¡Esto es increíble!
Y como si no fuese suficiente, hemos agregado una amplia gama de características para facilitar el uso del sitio. Los nuevos datos RSS personalizables permiten seleccionar el contenido por fecha, columna, autor o tema. Incluso puede crear combinaciones. Visite technetmagazine.com/rss para comenzar a crear sus propios datos ahora mismo.
También presentaremos nuevas páginas de temas. Si desea leer toda la información sobre lo que los profesionales de TI deben hacer para prepararse para Windows Vista, vaya a technetmagazine.com/vista. Si es administrador de correo, no deje de consultar technetmagazine.com/exchange. Tenemos 32 temas de interés en technetmagazine.com/topics, y se incorporarán muchos más. (En noviembre, teníamos 43 artículos sobre la seguridad que esperaban con paciencia su visita.)
Y eso no es todo. Ahora puede obtener mayores conocimientos sobre la revista y el mundo de los profesionales de TI. Joshua Hoffman, editor técnico y de adquisiciones de TechNet Magazine, administra el blog de la revista en blogs.technet.com/tnmag. Y yo organizo una conferencia mensual en nuestro sitio, en la dirección www.technetmagazine.com/podcasts. En cada sesión, hablaré con las personas que escriben los artículos que usted lee para ir más allá de las palabras que explican el "porqué" del artículo. Le encantará oír a nuestros expertos autores hablar sobre sus artículos y el trabajo que desempeñan.
Estamos haciendo todo para que TechNet Magazine se convierta en el recurso de mayor utilidad para los profesionales de TI. El año 2006 ha sido excelente, pero nos gustaría saber qué más podemos hacer por usted. Si tiene algún comentario, no dude en ponerse en contacto con nosotros. Nuestra dirección es tnmag@microsoft.com. El buzón de sugerencias está siempre abierto.
£JOSHUA TRUPIN

Mi agradecimiento a los siguientes expertos técnicos de Microsoft: Kevin Allison, Jessica Arnold, Sebastian Bengochea, Naveen Chand, Li Chen, Alpa Dave, Jill Frank, Mihai Jalobeanu, Darcy Jayne, Harry Katz, Kerry Landen, Todd Luttinen, Brett Muzzey, Bruce Payette, Tony Smith, Shawn Thomas, Jim Truher y Scot Vidican.


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

Prueba de esfuerzo de sus aplicaciones Web
WAPT Herramienta de esfuerzo de aplicaciones Web
www.loadtestingtool.com
Saber cómo va a funcionar la versión más reciente de su aplicación Web es fundamental a la hora de determinar el tamaño adecuado de su infraestructura y para evitar momentos de tensión como cuando el presidente le pregunta por qué al consultar el sitio Web obtiene la respuesta "Servidor demasiado ocupado". Y si está buscando una herramienta de prueba de esfuerzo y rendimiento de aplicaciones Web que sea de relativo bajo costo y fácil de usar, le recomendamos que pruebe WAPT 4.0 de SoftLogica LLC.
La aplicación se ejecuta en la mayoría de versiones de Windows®, pero es preferible que use Windows 2000, Windows XP o Windows Server® 2003 para obtener el todo el potencial, dadas las limitaciones de socket de versiones anteriores. Como ocurre con la mayoría de aplicaciones de pruebas de rendimiento que emplean usuarios virtuales, cuanta más memoria tenga, más rápido sea el procesador y más ancha la conexión de red, mayor será la cantidad de usuarios virtuales que podrá simular con WAPT.
En la documentación se establece un límite de alrededor de 2.000 usuarios virtuales para un PIV 2.4 con 512 MB de RAM y una interfaz gig-e, pero esto depende del tipo de aplicación que esté probando y de cómo configure el perfil de prueba. Otro factor que variará las pruebas es el retraso entre solicitudes, que WAPT permite establecer como tiempo de reflexión de usuario en el perfil de un usuario virtual.
Una vez que haya terminado de configurar un perfil de usuario virtual (puede tener muchos escenarios de pruebas), puede crear el plan de pruebas para dicho perfil. WAPT divide la secuencia de pruebas en tres secciones: acciones iniciales, acciones principales y acciones finales. Estas separaciones son más lógicas que funcionales, pero sugieren la división de la función de inicio de sesión o de registro, por ejemplo, en la sección inicial y la acción de cierre de sesión en la sección final. WAPT permite entrar las solicitudes manualmente o usar la grabadora del explorador integrada para hacer un seguimiento de la forma que desea que los usuarios naveguen por el sitio. A continuación, puede ir hasta la configuración general para determinar cómo debe ser la carga para esta prueba y si desea que sea fija o que aumente hasta llegar a la capacidad total durante un período específico. Durante la prueba, WAPT puede ofrecerle una vista en tiempo real de las estadísticas de rendimiento de su escenario de prueba. Cuando haya terminado, puede guardar los resultados como HTML o CSV para revisarlos en el futuro.
Precio: 350 dólares por equipo.
Saber cómo va a funcionar la versión más reciente de su aplicación Web es fundamental a la hora de determinar el tamaño adecuado de su infraestructura y para evitar momentos de tensión como cuando el presidente le pregunta por qué al consultar el sitio Web obtiene la respuesta "Servidor demasiado ocupado". Y si está buscando una herramienta de prueba de esfuerzo y rendimiento de aplicaciones Web que sea de relativo bajo costo y fácil de usar, le recomendamos que pruebe WAPT 4.0 de SoftLogica LLC.
La aplicación se ejecuta en la mayoría de versiones de Windows®, pero es preferible que use Windows 2000, Windows XP o Windows Server® 2003 para obtener el todo el potencial, dadas las limitaciones de socket de versiones anteriores. Como ocurre con la mayoría de aplicaciones de pruebas de rendimiento que emplean usuarios virtuales, cuanta más memoria tenga, más rápido sea el procesador y más ancha la conexión de red, mayor será la cantidad de usuarios virtuales que podrá simular con WAPT.
WAPT Herramienta de esfuerzo de aplicaciones Web
WAPT Herramienta de esfuerzo de aplicaciones Web (Hacer clic en la imagen para reducirla)
WAPT Herramienta de esfuerzo de aplicaciones Web
WAPT Herramienta de esfuerzo de aplicaciones Web (Hacer clic en la imagen para ampliarla)
En la documentación se establece un límite de alrededor de 2.000 usuarios virtuales para un PIV 2.4 con 512 MB de RAM y una interfaz gig-e, pero esto depende del tipo de aplicación que esté probando y de cómo configure el perfil de prueba. Otro factor que variará las pruebas es el retraso entre solicitudes, que WAPT permite establecer como tiempo de reflexión de usuario en el perfil de un usuario virtual.
Una vez que haya terminado de configurar un perfil de usuario virtual (puede tener muchos escenarios de pruebas), puede crear el plan de pruebas para dicho perfil. WAPT divide la secuencia de pruebas en tres secciones: acciones iniciales, acciones principales y acciones finales. Estas separaciones son más lógicas que funcionales, pero sugieren la división de la función de inicio de sesión o de registro, por ejemplo, en la sección inicial y la acción de cierre de sesión en la sección final. WAPT permite entrar las solicitudes manualmente o usar la grabadora del explorador integrada para hacer un seguimiento de la forma que desea que los usuarios naveguen por el sitio. A continuación, puede ir hasta la configuración general para determinar cómo debe ser la carga para esta prueba y si desea que sea fija o que aumente hasta llegar a la capacidad total durante un período específico. Durante la prueba, WAPT puede ofrecerle una vista en tiempo real de las estadísticas de rendimiento de su escenario de prueba. Cuando haya terminado, puede guardar los resultados como HTML o CSV para revisarlos en el futuro.
Precio: 350 dólares por equipo.

Reseña de libro
Conceptos fundamentales de las redes de contenido (en inglés)
www.ciscopress.com
El contenido es el rey y Conceptos fundamentales de redes de contenido (en inglés) (Cisco Press, 2006) escrito por Silvano Da Ros le ayudarán a mejorar su infraestructura de entrega de contenido rápidamente. Este libro se describe como "una presentación completa a la teoría y las aplicaciones prácticas de las redes de contenido", y eso es realmente lo que es. Aunque obviamente se decanta hacia el hardware de redes de Cisco, el libro ofrece una buena explicación sobre los distintos componentes de las redes de contenido, así como instrucciones prácticas para implementar los principios fundamentales aplicables de las redes de contenido, independientemente de los tipos de productos de redes de contenido incluidos en su infraestructura.
Este libro empieza con una descripción general de alto nivel de los distintos elementos que componen las redes de contenido (que realmente mejoran el rendimiento y la entrega de la comunicación de la capa 4 a la capa 7 del modelo OSI). A continuación, se analizan los detalles prácticos de los formatos principales de presentación de contenido, como por ejemplo, XML, HTML, WAP y la transformación de contenido a través de XSLT en el límite de la red, y hay una sección sobre la entrega de medios de transmisión. Finalmente, el libro trata de la escalabilidad y disponibilidad, e incluye debates sobre el equilibrio de carga de servidor (tanto global como local), el equilibrio de carga del servidor de seguridad y el uso de dispositivos de almacenamiento de contenido en caché tales como el conmutador de servicios de contenido de Cisco.
Si usa conmutadores de servicios de contenido de Cisco en la infraestructura, el capítulo sobre conmutación de contenido protegido le resultará interesante. Este capítulo contiene información detallada sobre la configuración del módulo de servicios de contenido para la capa de sockets seguros, así como la configuración de URL y la reescritura de encabezados. Generalmente, los profesionales de redes que sean leales a una marca específica encontrarán útil el capítulo sobre QoS para comprender los distintos mecanismos de colas y la administración de la congestión.
En resumen, aunque este libro favorece indudablemente las implementaciones de hardware de Cisco (después de todo, lo publica Cisco Press), le servirá de ayuda para convertir las palabras de moda "redes de contenido" en metodologías prácticas y aplicables para la infraestructura de entrega de contenido.
Precio: $55.00.

Supervisión de los servicios
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp
Una característica que puede demostrar la aptitud o ineptitud de un profesional de TI es su capacidad para detectar problemas (y con un poco de suerte solucionarlos) antes de que los detecten los usuarios finales de la organización. Por lo tanto, una de las herramientas más importantes que puede tener un profesional de TI es un sistema de supervisión eficaz que permita analizar los distintos servicios que se proporcionan a fin de comprobar que se ejecutan correctamente. WebWatchBot de ExclamationSoft puede ayudarle en este propósito.
Esta aplicación puede supervisar todos los servicios comunes imaginables. En lugar de simplemente comprobar que se ejecuta un servicio, WebWatchBot va un paso más allá. Lo que hace es comprobar los servicios para garantizar que funcionan correctamente. Por ejemplo, la comprobación de FTP puede cargar y descargar un archivo, la supervisión de DNS puede ejecutar cualquiera de los 40 comandos de consulta distintos y buscar una cadena en la respuesta, y las pruebas de POP3 y SMTP inician sesión e informan del rendimiento del correo.
WebWatchBot
WebWatchBot (Hacer clic en la imagen para reducirla)
WebWatchBot
WebWatchBot (Hacer clic en la imagen para ampliarla)
Asimismo, WebWatchBot permite encadenar una secuencia de pasos en una transacción e informa de posibles errores o de la latencia inaceptable (según los umbrales que haya establecido) para toda la transacción. La aplicación también supervisa las URL HTTP y HTTPS, y puede comprobar contenido específico. Incluso puede configurar supervisores de base de datos que ejecuten consultas y confronten los datos con una respuesta de plantilla.
Precio: 495,95 dólares por licencia de usuario.

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


 Windows PowerShell: Comandos sencillos. Administraci&#243;n eficaz
Windows PowerShell
Comandos sencillos. Administración eficaz
Don Jones
Este artículo se basa en una versión preliminar de Windows PowerShell. Toda la información que aquí se menciona está sujeta a cambios.

Ha sido un proceso largo, pero Windows PowerShell está casi listo para su lanzamiento. Esto significa que los administradores de Windows deben comenzar a familiarizarse con la aplicación. Windows PowerShell ofrece lo que es posiblemente la manera más fácil y flexible de automatizar una variedad de tareas de administración, con lo que mejoran su productividad y eficacia en el trabajo.
Pero lo más importante es que Microsoft está creando las consolas administrativas gráficas de productos como Exchange Server 2007 y System Center 2007 sobre Windows PowerShell™. Esto significa que podrá realizar casi cualquier tarea administrativa desde Windows PowerShell. Microsoft tiene planeado hacer lo mismo con las capacidades administrativas de un mayor número de productos en el futuro. Por lo tanto, Windows PowerShell podría convertirse en la primera herramienta completa para la administración de casi todos los productos de servidor de Microsoft. Para ayudarle a comenzar, hablaré sobre Windows PowerShell con frecuencia en esta nueva columna. Asegúrese de descargar una copia del software.

Eficacia y sencillez
Como indica el nombre, Windows PowerShell es un shell, similar al símbolo del sistema (Cmd.exe) que existe desde Windows NT® 3.1. Cmd.exe no desaparece, pero con la disponibilidad de Windows PowerShell, habrá pocos motivos por seguir usando Cmd.exe.
El uso de Windows PowerShell no difiere mucho del uso de Cmd.exe, excepto que Windows PowerShell es, bueno, más eficaz. Como Cmd.exe, Windows PowerShell cuenta con un lenguaje incorporado de secuencias de comandos, aunque es mucho más flexible que el primitivo lenguaje por lotes de Cmd.exe. ¿Qué grado de flexibilidad tiene? Con Windows PowerShell, puede automatizar tareas muy complejas en un lenguaje que incluye tan solo una media docena de palabras claves incorporadas.
Puesto que he mencionado la creación de secuencias de comandos, debería hablar un poco sobre la seguridad. Windows PowerShell aprovecha lo que Microsoft ha aprendido sobre la seguridad durante los últimos diez años y más. De forma predeterminada, Windows PowerShell no ejecutará secuencias de comandos y sólo se podrá usar de manera interactiva para ejecutar comandos individuales. Si no habilita la secuencia de comandos, puede indicar a Windows PowerShell que ejecute solamente secuencias de comandos con firmas digitales. Todo esto sirve para ayudar a que Windows PowerShell no se convierta en el próximo VBScript, un lenguaje estupendo que se ha usado de manera abusiva para crear secuencias de comandos malintencionadas. VBScript tampoco desaparecerá, pero es probable que considerará que Windows PowerShell es más fácil de usar en un gran número de tareas distintas.
Con Windows PowerShell puede hacer casi todo lo que puede hacer con Cmd.exe. Por ejemplo, puede ejecutar ipconfig y obtendrá el mismo resultado conocido. Sin embargo, Windows PowerShell presenta un nuevo conjunto completo de comandos que no son archivos ejecutables externos. Estos cmdlets (pronunciado "command-let" en inglés) están incorporados en Windows PowerShell. Para conocer algunos de los cmdlets más útiles y poder comenzar a usar Windows PowerShell, consulte la barra lateral "Los 10 cmdlets principales para comenzar a usar inmediatamente".
Los 10 cmdlets principales para comenzar a usar inmediatamente
  • El comando Get-Command recupera una lista de todos los cmdlets disponibles.
  • El comando Get-Help muestra la información de ayuda acerca de los cmdlets y los conceptos.
  • El comando Get-WMIObject recupera información de administración mediante WMI.
  • El comando Get-EventLog recupera los registros de eventos de Windows.
  • El comando Get-Process recupera un proceso o una lista de procesos activos.
  • El comando Get-Service recupera un servicio de Windows.
  • El comando Get-Content realiza la lectura de archivos de texto y trata cada línea como un objeto secundario.
  • El comando Add-Content anexa contenido a un archivo de texto.
  • El comando Copy-Item copia archivos, carpetas y otros objetos.
  • El comando Get-Acl recupera listas de control de acceso (ACL).
Para obtener una lista completa de los cmdlets que se incluyen en Windows PowerShell, vaya a windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx.
Todos los nombres de los cmdlets tienen un formato estándar de verbo-objeto, lo que nos facilita aprenderlos y recordarlos. Por ejemplo, si ejecuta el cmdlet Get-Command, aparecerá una lista de todos los cmdlets disponibles. Posiblemente, el cmdlet de mayor utilidad para un administrador es Get-WMIObject. Supongamos que desea saber qué service pack está ejecutando Server2. Simplemente ejecute:
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
Para buscar la misma información mediante VBScript, debe escribir varias líneas de código. Otros cmdlets permiten trabajar con servicios (Start-Service, Stop-Service, etc.), procesos (Stop-Process, etc.), archivos (por ejemplo, Rename-Item, Copy-Item, Remove-Item, Move-Item) y mucho más. Un gran número de estos cmdlets incluso dispone de nombres de acceso directo, denominados alias. En el caso de Get-WMIObject, puede simplemente escribir gwmi. Si ejecuta Get-Alias, obtendrá una lista de los nombres de acceso directo.

Importancia de la capacidad orientada a objetos
Windows PowerShell, que se basa en Microsoft® .NET Framework, es una aplicación completamente orientada a objetos. Normalmente, únicamente un editor de software se entusiasmaría al saber esto, pero, en este caso, la capacidad orientada a objetos resulta en un gran ahorro de tiempo para los administradores. Esto se debe a que los administradores ahora pueden trabajar directamente con objetos enriquecidos dentro de un shell basado en texto. Considere el ejemplo siguiente:
Get-Process | Sort-Object pm –desc | Select-Object –first 10
Se trata de una línea sencilla con tres cmdlets distintos separados por barras verticales (se proporcionará información adicional sobre esto más adelante). El primer cmdlet recupera todos los procesos en ejecución y, a continuación, pasa (o canaliza) dichos objetos al comando Sort-Object. Este segundo cmdlet ordena en la propiedad de memoria física (pm) de cada objeto de proceso y los coloca en orden descendente. A continuación, la recopilación ordenada de objetos de proceso se canaliza hacia el comando Select-Object, que selecciona los primeros diez y los muestra. ¿Cuál es el resultado? Esta línea sencilla muestra los primeros diez consumidores de memoria en el equipo, tal como se muestra en la figura 1. Ésta es una manera muy eficaz de realizar comprobaciones rápidas durante la solución de problemas.
Figura 1 Uso de un cmdlet sencillo para la resolución de problemas
Figura 1 Uso de un cmdlet sencillo para la resolución de problemas (Hacer clic en la imagen para reducirla)
Figura 1 Uso de un cmdlet sencillo para la resolución de problemas
Figura 1 Uso de un cmdlet sencillo para la resolución de problemas (Hacer clic en la imagen para ampliarla)
El uso de barras verticales (el carácter que suele encontrarse en la tecla numérica 1 del teclado en español) es una parte esencial de la capacidad elevada de Windows PowerShell. Mediante este carácter, puede pasar (o canalizar) objetos de un cmdlet a otro; lo que permite refinar aún más los resultados, darles formato para su visualización, etc. Este mecanismo funciona porque todos los cmdlets devuelven uno o más objetos en lugar de sólo texto. De este modo, los cmdlets subsiguientes obtienen el objeto completo para realizar sus tareas.
El uso de objetos en Windows PowerShell es dominante hasta sus variables. Además, no es necesario declarar variables de antemano, simplemente puede empezar a usarlas colocando un símbolo de dólar ($) antes del nombre de una variable. Aunque no es necesario, también puede indicar a Windows PowerShell el tipo de datos que desea colocar en la variable. De este modo, Windows PowerShell puede asignar la variable a uno de los muy eficaces tipos de .NET Framework, lo que le proporciona una funcionalidad adicional incorporada. Por ejemplo, supongamos que desea solicitar un nombre de equipo y recuperar la versión del service pack de éste, pero no sabe si la persona que escribe el nombre del equipo incluirá dos barras invertidas (por ejemplo, \\Server2). Dado que sabe que el cmdlet Get-WMIObject no necesita barras invertidas, puede guardar el nombre del equipo en una variable de cadena y usar el método de reemplazo para remplazar las barras invertidas por cadenas vacías, tal como se indica a continuación:
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
El valor del parámetro –Computer se ha proporcionado en la variable $c. Originalmente, la variable se creó como una cadena, de modo que obtuvo toda la funcionalidad del tipo de cadena de .NET Framework, incluido el método de reemplazo. Evidentemente, el aprendizaje de todas estas capacidades llevará algo de tiempo, pero las encontrará fáciles de aprender a través de ejemplos. Windows PowerShell ayuda a simplificar el aprendizaje. Por ejemplo, si escribe $c = $c. (no olvide el punto final) y presiona la tecla de tabulador, Windows PowerShell mostrará Clone(), el primer método del tipo de cadena. Si sigue presionando la tecla de tabulador, Windows PowerShell pasará por todos los métodos disponibles. Esencialmente, cuando hace esto, Windows PowerShell está mostrando lo que sabe hacer con la cadena.
Ahora pasaremos a una tarea más difícil. Debemos leer una lista de nombres de equipo de un archivo, con un nombre por línea y mostrar el número del service pack de cada equipo. En VBScript, esta tarea necesitaría aproximadamente una docena de líneas de código. En Cmd.exe, necesitaría usar un complejo archivo por lotes. En Windows PowerShell, esta tarea se puede realizar con tan solo una línea:
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
El cmdlet Get-Content lee el contenido de C:\Computers.txt. Cada línea del archivo se convierte en un objeto propio. La recopilación de objetos (es decir, los nombres de equipo) se canaliza hacia el comando foreach, que en realidad es un alias del cmdlet ForEach-Object. Los comandos entre las llaves se repiten una vez para cada objeto canalizado; en este ejemplo, significa que se ejecutan una vez para cada nombre de equipo. La variable especial $_ contendrá el objeto actual (es decir, el nombre del equipo actual).
En realidad, en el interior de las llaves hay dos comandos: El primero simplemente muestra el nombre del equipo actual proporcionando el contenido de $_. El segundo es el conocido comando gwmi. El resultado es una lista de las versiones de service pack para cada equipo que figura en el archivo. Todo esto se realiza con una línea clara de comandos.
Observe que el nombre de los parámetros –Property y –Computer se han abreviado. Windows PowerShell sólo requiere un número de caracteres suficiente para distinguir de manera única los nombres de los parámetros.

Legibilidad y reutilización
Sin embargo, la escritura de una única línea de comandos y parámetros no ayuda con la legibilidad. Windows PowerShell permite desglosar todo esto en un elemento más legible, que puede escribir directamente en el shell sin tener que escribir ninguna secuencia de comandos. Debe tener el aspecto siguiente:
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
Esta vez, el contenido del archivo se almacena en la variable $names. En este ejemplo aún se usa foreach, pero no se coloca a través de una canalización, de modo que hay que indicarle qué recopilación de objetos deben incluirse en el bucle y qué variable debe almacenarse en cada objeto; la parte que dice ($name in $names). El resto es casi igual y cuando presione la tecla Intro, el código se ejecutará y se mostrarán los resultados.
Si desea usar este mismo código de manera repetida, puede crear una función a partir de éste. De nuevo, esto se escribe directamente en el shell:
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
Como puede observar, no han cambiado demasiados elementos. Simplemente, esto cierra el ejemplo anterior en una función denominada Get-ServicePacks (según la convención de asignación de nombres verbo-objeto de Windows PowerShell). La funciona ahora tiene un parámetro de entrada denominado $file, que se ha sustituido en el comando Get-Content de modo que se pueda especificar un archivo distinto cuando se ejecute dicha función. Ahora que la función se ha definido, simplemente puede ejecutarla invocando su nombre, casi como un cmdlet, y pasando el parámetro de entrada:
PS C:\> Get-ServicePacks c:\computers.txt
La figura 2 muestra los resultados.
La desventaja aquí es que esta función sólo existirá mientras se ejecuta la instancia de Windows PowerShell. Cuando cierre el shell, la función desaparecerá. Puede copiar la función en el perfil de Windows PowerShell, que es como una secuencia de comandos de ejecución automática que se ejecuta cada vez que se inicia Windows PowerShell. De este modo, la función estará disponible en todas las ventanas de Windows PowerShell que abra. O bien, si lo desea, puede convertir la función en una secuencia de comandos independiente que puede ejecutar con tan solo escribir la ruta de acceso y el nombre de usuario de dicha secuencia de comandos.
Figura 2 Resultados de la ejecución de la función Get-ServicePacks
Figura 2 Resultados de la ejecución de la función Get-ServicePacks

El mundo es un archivo (o carpeta)
Windows PowerShell ofrece mucho más que funciones y cmdlets. Consideremos la administración de archivos como un ejemplo rápido de lo que puede hacer además. Es probable que esté más que familiarizado con la navegación de unidades de disco y carpetas en Cmd.exe: escriba C: para cambiar a la unidad C y escriba cd \test para cambiar a la carpeta C:\Test. Windows PowerShell funciona exactamente de la misma manera, aunque cd es simplemente un alias del cmdlet Set-Location.
Intente ejecutar Get-PSDrive, el cmdlet que proporciona una lista de todas las unidades disponibles. Además de las unidades C:, D: y posiblemente A: normales, también verá una denominada Cert, otra denominada Env y otras denominadas HKCU y HKLM. En realidad, Windows PowerShell expone varios tipos diferentes de recursos de almacenamiento como "unidades", lo que pone a la disposición del usuario elementos tales como el almacén local de certificados, variables de entorno y el registro, en una interfaz de navegación de tipo archivos que le resultará familiar.
Cambie al subárbol de registro HKEY_LOCAL_MACHINE. Para ello, escriba Set-Location HKLM: (o cd hklm: si prefiere el acceso directo) y presione la tecla Intro. A continuación, ejecute el comando cd software\microsoft para cambiar a la clave SOFTWARE\Microsoft. Puede usar dir (un alias del cmdlet Get-ChildItem) para obtener una lista de las subclaves de esta parte del registro. Si desea quitar una clave, use la tecla Supr como si fuese cualquier archivo o carpeta. Tenga mucho cuidado, la eliminación de claves requeridas o la modificación incorrecta del registro puede provocar problemas graves.
Toda esta flexibilidad procede de los proveedores, que asignan recursos (como el registro y el almacén de certificados) en un formato que tiene el aspecto de un sistema de archivos. Microsoft tiene planeado extender Windows PowerShell a través de proveedores adicionales, lo que le proporcionará la capacidad de, por ejemplo, navegar por un almacén de Exchange Server como si fuese un sistema de archivos. Esta técnica es muy importante en el sentido que recopila la enorme variedad de repositorios que usa Windows y hace que todos se puedan administrar a través de un sistema de comandos y técnicas ya conocidas.

Diseñado para la seguridad
Ya he mencionado que Windows PowerShell se diseñó teniendo en cuenta la seguridad. La principal función de seguridad de Windows PowerShell es su directiva de ejecución. De forma predeterminada, esta directiva se configura en Restringido, que puede comprobar mediante la ejecución del cmdlet Get-ExecutionPolicy. En el modo Restringido, las secuencias de comandos no se ejecutan en absoluto. Dado que se trata del modo predeterminado, Windows PowerShell no puede usarse para ejecutar secuencias en su estado original.
Puede especificar otros modos mediante el comando Set-ExecutionPolicy. Personalmente, yo prefiero el modo RemoteSigned. Esto permite a las secuencias de comandos locales (pero no las remotas) ejecutarse sin tener que disponer de firma digital, lo que proporciona la manera más sencilla de desarrollar y probar secuencias. El modo AllSigned no ejecuta ninguna secuencia de comandos a menos que ésta disponga de firma digital mediante un certificado emitido por un editor de confianza. Por último, la directiva Sin restricciones ejecuta cualquier elemento. No recomiendo el uso en absoluto de esta directiva, ya que permitirá que Windows PowerShell ejecute secuencias de comandos malintencionadas que puedan llegar al equipo. Observe que la directiva de ejecución también se rige por la directiva del grupo, la cual anula la configuración local. El comando Set-ExecutionPolicy le advertirá si un parámetro de la directiva del grupo está anulando la configuración local.
Además, Windows PowerShell no ejecutará secuencias de comandos desde el directorio actual, a menos que se especifique una ruta de acceso. Se ha diseñado de este modo para impedir la apropiación de comandos. Supongamos que alguien crea una secuencia de comandos denominada IPConfig.ps1 (PS1 es la extensión de nombre de archivo para los archivos de secuencia de comandos de Windows PowerShell). Si los archivos pudiesen ejecutarse desde la carpeta actual, existiría el riesgo de escribir ipconfig y ejecutar esta secuencia de comandos creada por un usuario, cuando, en realidad, deseaba ejecutar el programa de Windows Ipconfig.exe. Dado que Windows PowerShell no ejecuta secuencias de comandos desde la carpeta actual, este error no puede producirse. Si desea ejecutar una secuencia de comandos de la carpeta actual, deberá especificar la ruta de acceso: por ejemplo, .\myscript. La referencia explícita a la carpeta actual garantiza que el usuario sabe que está ejecutando una secuencia de comandos y no un comando de shell.
Windows PowerShell también cuenta con funciones que aumentan la seguridad en tareas de experimentación. Por ejemplo, considere (pero NO intente) esta combinación aterradora:
Get-Process | Stop-Process
El cmdlet Get-Process crea una recopilación de objetos de proceso y los canaliza hacia el cmdlet Stop-Process, que causará la detención de éstos. Transcurridos unos cinco segundos, el resultado será un error de detención de pantalla azul, ya que se están cerrando procesos críticos de Windows. Puede ver lo que sucedería, sin permitir en realidad que suceda, usando el parámetro –Whatif, que es muy práctico.
Get-process | Stop-Process -Whatif
La ejecución de este parámetro en Windows PowerShell da como resultado una serie de declaraciones que indican lo que los cmdlets hubieran realizado sin ejecutarse de verdad. El sistema de ayuda en pantalla de Windows PowerShell (al que se puede obtener acceso mediante el alias help) aún no ofrece información sobre el parámetro –Whatif, pero téngalo en cuenta. Se trata de una excelente herramienta para probar secuencias de comandos y cmdlets sin realizar ninguna operación que pueda llevar a errores o interrumpir el sistema.

Conclusión
Entre las características que no se incluyeron en esta versión de Windows PowerShell, posiblemente la más significativa es la compatibilidad con Active Directory® Services Interface (ADSI). Si bien Windows PowerShell puede emplear clases .NET muy sólidas que funcionan con Active Directory y otros servicios del directorio, aún no dispone de un cmdlet Get-ADSIObject apropiado. El resultado es que es un poco difícil trabajar con objetos del directorio.
Además, Windows PowerShell suele ofrecer varias maneras de realizar la misma tarea. Eso está muy bien, pero puede hacer que el aprendizaje de Windows PowerShell sea algo más confuso, ya que para cualquier tarea en particular, podrá observar una media docena de ejemplos de cómo realizarla.
Todo esto se arreglará con el paso del tiempo y el equipo de Windows PowerShell seguirá incorporando características y capacidades al producto. Para mantenerse informado, visite el blog del equipo.

Don Jones es fundador de ScriptingAnswers.com y coautor de Windows PowerShell: TFM (SAPIEN Press, 2006). Póngase en contacto con él en la dirección: don@scriptinganswers.com.


 Examen anal&#237;tico final: Migraci&#243;n desde Exchange 5.5
Examen analítico final
Migración desde Exchange 5.5
Whitney Roberts

EL PROYECTO
El Departamento de educación de Kentucky necesitaba migrar su implementación de Microsoft® Exchange Server 5.5 actual a Exchange Server 2003. El sistema incluye aproximadamente 600.000 profesores, empleados y estudiantes durante un año escolar.
LOS JUGADORES
El proyecto lo llevó a cabo la Oficina de tecnología educativa (OET) del Departamento de educación de Kentucky con el soporte de consultores de KiZAN Technologies. El personal de OET supervisó la administración de la implementación existente de Exchange 5.5. El personal local de los distritos escolares era el responsable de la ejecución diaria de los servidores Exchange.
LOS DESAFÍOS
El Departamento de educación proporciona instrucciones técnicas a los 178 distritos escolares de la mancomunidad de Kentucky. Estos distritos escolares están conectados entre sí mediante una WAN, pero cada uno cuenta con su propio servidor Exchange 5.5 administrado localmente, que había que actualizar de manera individual. Esta actualización permitiría la compatibilidad con los clientes del modo de caché de Outlook® 2003, una experiencia mejorada de Outlook Web Access (OWA), un esquema de direcciones de correo electrónico estandarizado, etc.
Además de un servidor de correo electrónico y una infraestructura de cliente nuevos, muchos de los distritos escolares querían agregar acceso al correo electrónico para los estudiantes. Tanto la normativa estatal como la federal exigían la protección de la información del estudiante, que no fuese visible fuera del distrito correspondiente.
EL PLAN
Dado que no se podía usar un conector de Active Directory® (ADC), creamos una nueva organización de Exchange y realizamos la migración a ella. La estandarización de direcciones de correo electrónico implicaba la creación de nuevos subdominios de identificación para cada distrito escolar y más de 400 directivas de destinatarios nuevas. La protección de las direcciones de los estudiantes requería la construcción de un sistema de listas globales de direcciones (GAL) y listas personalizadas de direcciones para cada distrito escolar.
La migración real incluía el montaje de hardware nuevo, la creación y configuración de buzones basadas en la pertenencia a un distrito y el tipo de usuario, y el establecimiento de atributos de extensión basado en la pertenencia a un distrito y el tipo de usuario, de manera que el usuario apareciese en la lista de direcciones correspondiente.
Creamos una aplicación basada en Visual Basic® para detectar y corregir los atributos de cuenta o las pertenencias a grupos mal configurados y para asignar buzones nuevos correctamente para asegurar que se mantenían los requisitos de visibilidad. La aplicación se implementó en los 178 distritos y se ejecuta según una programación desde todos los servidores del distrito escolar.

Información previa
Desde fuera, no parece un trabajo difícil técnicamente o que pueda suponer un reto. Sin embargo, tal como se me ha recordado humildemente, los requisitos empresariales mandan, y los de este proyecto fueron reveladores.
A lo largo de los años, una administración descentralizada y un revoltijo de estándares crearon varios "silos" de soporte que, la mayoría de las veces, tenía que administrar la OET. Además, la OET también tuvo que comprobar si la implementación de Exchange 5.5 satisfacía los requisitos de los distritos escolares y el Departamento de educación al mismo tiempo. De esta manera, en los distritos que usaban el correo electrónico de estudiantes, la información del estudiante estaba protegida y no era visible fuera del distrito correspondiente, tal como exigían las directrices estatales y federales (consulte ed.gov/policy/gen/guid/fpco/ferpa/index.html).
En Exchange 5.5, estas directrices implicaban que la información de los estudiantes del distrito no podía replicarse en los demás distritos escolares ni en otras agencias estatales que compartiesen datos de la lista GAL. Específicamente, tenía que pasar por un proceso de exportación/importación manual para cada uno de los 178 sitios de Exchange 5.5: ocultar los estudiantes, replicar la lista, mostrar los estudiantes y, por último, volver a importar la lista de direcciones. De esta manera, los demás distritos podían ver únicamente los datos del personal y el distrito escolar correspondiente podía ver todos sus datos, pero sólo los datos del personal de los otros distritos escolares.
Dados los puntos fuertes y débiles del sistema existente, la actualización de la infraestructura de mensajería debía satisfacer algunos criterios específicos. En primer lugar, el Departamento de educación de Kentucky quería estandarizar un esquema de denominación SMTP común y legible para toda la empresa. El esquema tenía que proporcionar espacio de direcciones SMTP separados para el personal docente y los estudiantes.
El nuevo sistema también tenía que proporcionar un servicio administrado centralmente que eliminase la responsabilidad y la administración de mensajería para que estuviese disponible desde el distrito. Esto significaba una administración centralizada de la recuperación de desastres, el flujo de correo y la resolución de llamadas al departamento de soporte. Como tal, el nuevo sistema tenía que proporcionar un método centralizado para estandarizar la configuración del usuario en todos los distritos, independientemente de la ubicación geográfica o la pertenencia a un distrito de un usuario determinado.
Además, el nuevo sistema debía ofrecer un acceso seguro a dispositivos móviles y basado en Web al correo electrónico en un espacio de nombres común y unificado para todos los distritos.
Dados estos requisitos, muchos de los cuales todavía no estaban implementados en el sistema Exchange 5.5 existente, la actualización a Exchange 2003 era bastante intimidante.

Bloques de creación de soluciones
Para satisfacer los requisitos empresariales, se optó por varias opciones específicas de Exchange para la implementación.
Debido a la falta de estandarización y a la magnitud del entorno de Exchange 5.5, no se pudo usar un ADC. En su lugar, creamos una organización de Exchange y realizamos la migración a ella.
La limpieza y estandarización de las direcciones de correo electrónico del personal y los estudiantes de cada distrito llevó a la creación de más 400 directivas de destinatarios nuevas. Los requisitos exigían un subdominio de identificación único para cada distrito, incluida una designación de distrito identificadora para los estudiantes. Por ejemplo, en el caso del condado de Shelby, el subdominio principal sería shelby.kyschools.us. Los estudiantes de cada distrito reciben una designación de subdominio stu., por lo que los estudiantes del condado de Shelby podrían tener direcciones stu.shelby.kyschools.us.
Otra de las limitaciones era que las direcciones de los estudiantes fuesen visibles únicamente en el distrito del estudiante y las direcciones del personal, en todos los distritos. Para que esto fuese posible, tuvimos que crear un sistema elaborado de listas GAL y listas personalizadas de direcciones, tal como se muestra en la figura 1 y la figura 2. El traslado a Exchange 2003 nos permitió proteger las listas de direcciones con permisos y controlar el acceso a cada lista de direcciones individual mediante la pertenencia a grupos. Usamos esta característica para crear dos grupos de seguridad por distrito (uno para el personal y otro para los estudiantes) y, a continuación, protegimos las listas de direcciones y GAL correspondientes al personal y los alumnos para que sólo las cuentas de usuario de un distrito específico tuviesen acceso a determinadas listas de direcciones. Al eliminar las listas de direcciones y GAL predeterminadas y, después, asegurarnos de que los grupos Todos y Usuarios autenticados no estaban incluidos en la lista de control de acceso (ACL) de cada lista de direcciones, pudimos realizar una selección previa de la lista de direcciones que un tipo específico de usuarios vería en un distrito específico.
Figura 1 Listas personalizadas de direcciones basadas en funciones
Figura 1 Listas personalizadas de direcciones basadas en funciones (Hacer clic en la imagen para reducirla)
Figura 1 Listas personalizadas de direcciones basadas en funciones
Figura 1 Listas personalizadas de direcciones basadas en funciones (Hacer clic en la imagen para ampliarla)
Sin embargo, los permisos sólo resolvieron una parte del problema de visibilidad. Tuvimos que buscar una manera de controlar quién era visible y en qué lista de direcciones. Creamos una consulta LDAP (Protocolo ligero de acceso a directorios) base que nos permitía consultar la visibilidad del personal y los estudiantes; a continuación, adaptamos ligeramente la consulta para cada lista de direcciones y GAL. Por ejemplo, la consulta LDAP para la lista GAL de personal de Shelby sólo mostraría el personal y los estudiantes de Shelby y todo el personal (pero no los estudiantes) de cada distrito del estado. La lista GAL de estudiantes de Shelby sólo mostraría el personal y los estudiantes de Shelby, no mostraría el personal ni los estudiantes de otros distritos del estado. Repetimos esta consulta en todos los distritos de la organización. En la figura 3 se muestran ejemplos de algunas consultas LDAP usadas en esta migración compleja.
Figure 3 Consultas LDAP en la lista de direcciones (Close Figure 3)

Consulta LDAP en la lista GAL de personal
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Consulta LDAP en la lista de direcciones del distrito
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
Consulta LDAP en la lista de direcciones de estudiantes del distrito
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
Consulta LDAP en la lista de direcciones sin conexión de personal del distrito
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Figura 2 Listas globales de direcciones que separan el personal de los estudiantes
Figura 2 Listas globales de direcciones que separan el personal de los estudiantes (Hacer clic en la imagen para reducirla)
Figura 2 Listas globales de direcciones que separan el personal de los estudiantes
Figura 2 Listas globales de direcciones que separan el personal de los estudiantes (Hacer clic en la imagen para ampliarla)
Los valores personalizados para las propiedades de usuario de Exchange extensionAttribute14 y extensionAttribute15 fueron los mecanismos de distinción entre las consultas LDAP. Todos los estudiantes y el personal del estado usaron un valor específico en extensionAttribute14 para designar el tipo de usuario y un valor único en extensionAttribute15 para mostrar la pertenencia a un distrito. Al usar valores únicos para cada distrito y los mismos valores para cada tipo de usuario, las listas de direcciones mostraban exactamente la información necesaria para cada tipo de usuario de cada distrito.
Estas listas de direcciones funcionaron bastante bien para los usuarios que tenían acceso al correo electrónico a través de Outlook en modo sin caché o a través de OWA. Dirigimos cada uno de los usuarios a la lista de direcciones adecuada de OWA mediante el atributo msExchQueryBaseDN. Sin embargo, los usuarios que ejecutaban Outlook en modo de caché presentaban otro problema. Outlook no acepta una lista GAL personalizada como Libreta de direcciones sin conexión (OAB) designada, por lo que tuvimos que crear listas de direcciones adicionales que eran duplicados de las listas GAL. Después, configuramos todos los almacenes del buzón del distrito con la lista de direcciones OAB adecuada para sus usuarios en modo de caché. Con todo, esta solución llegó a un tope de 1.500 listas de direcciones para proporcionar todas las funciones a los diferentes tipos de usuarios de los 178 distritos.

Garantía de conformidad
Para garantizar que la estructura que se iba a implantar funcionaría correctamente, era primordial el cumplimiento de los estándares recién establecidos. Había varias tareas de alto nivel que tenían que efectuarse en cada usuario habilitado para Exchange de la organización. El motivo de esto es que todos los usuarios tienen que estar ubicados correctamente en todos los servidores Exchange del distrito, así como ser visibles en las listas de direcciones apropiadas.
El usuario tenía que ser un miembro del grupo de seguridad correspondiente del dominio del distrito, ya que el grupo de seguridad es el encargado de otorgar permisos para abrir la lista de direcciones adecuada. Además, debía tener el atributo msExchQuerybaseDN establecido correctamente de acuerdo con su distrito y pertenencia a una unidad organizativa (OU). La OU del usuario determinaba el tipo de usuario.
El próximo paso era crear el buzón del usuario en el almacén correcto del servidor adecuado, en función de la pertenencia a un distrito y el tipo de usuario. Estos requisitos repercutían en los niveles de servicio, los límites de tamaño del buzón y las listas de direcciones de la libreta de direcciones sin conexiones para que el modo de caché de Outlook funcionase correctamente. Los atributos de extensión se establecieron de acuerdo con la pertenencia a un distrito y el tipo de usuario para que el usuario se mostrase en las listas de direcciones adecuadas y no fuese visible en las otras.
Por último, teníamos que facilitar una manera de corregir automáticamente los atributos de la cuenta o las pertenencias a grupos en el caso de que estuviesen mal configurados (o modificados) en valores inadecuados. Si un usuario pasa de una unidad organizativa a otra dentro del dominio del distrito, la clasificación del usuario cambia, y la ubicación del buzón, la selección de la lista GAL y la visibilidad en la lista de direcciones deben actualizarse.
Teníamos que ofrecer un sistema que efectuase estas tareas y garantizase la coherencia y la precisión de Active Directory. Creamos una aplicación de consola basada en Visual Basic que se ejecuta según una programación desde los servidores Exchange 2003 del distrito escolar. La aplicación, que comprueba el cumplimiento de directivas y estándares, además de controlar la creación y el suministro de objetos nuevos, se implementó en los 178 distritos.
Las tareas que teníamos al alcance nos parecían demasiado complejas para ejecutar de manera rápida y confiable un conjunto de secuencias de comandos . La aplicación basada en Visual Basic pareció ser la solución adecuada, ya que era eficaz, proporcionaba un soporte estructurado para el control de errores y excepciones y su código interno era fácil de adaptar al código de extensión de Microsoft Identity Integration Server (MIIS) con una reescritura mínima.
Dado que estábamos realizando la migración a una organización nueva, era necesario encontrar algún método de coexistencia. Había más de 178 dominios SMTP heredados que debían ser compatibles con el nuevo entorno, algunos distritos ya tenían dominios de correo electrónico para los estudiantes, y otros no, pero tuvimos la suerte de poder migrar los distritos uno por uno y pasar sus direcciones y mensajes heredados al nuevo sistema sin tocar los otros distritos. No obstante, teníamos que evitar la interrupción del flujo de correo electrónico durante la migración en un distrito de Exchange 5.5 a Exchange 2003. Para ello, era necesario algún tipo de sincronización de directorios entre el directorio Active Directory de Exchange 2003 y el directorio heredado de Exchange 5.5. Microsoft concedió al Departamento de educación de Kentucky un uso limitado de MIIS sólo para el período que durase la migración, por lo que el código de extensión personalizado se desarrolló y se usó para sincronizar las organizaciones de Exchange mediante MIIS antes, durante y después de la migración.
Naturalmente, el traslado a una nueva organización de Exchange afecta a la configuración del cliente MAPI. El Departamento de educación se encontró con la realidad de, literalmente, decenas de miles de perfiles MAPI por distrito que tenían que volver a configurarse durante la migración. Afortunadamente, Microsoft lanzó al mercado la herramienta para actualización de perfiles de Exchange (ExProfRe.exe), de la cual hicimos uso para la migración de perfiles en los distritos. Creamos un instalador de paquetes que ejecutaba ExProfRe.exe con valores cargados previamente para que la migración de perfiles por distrito se realizase de manera automatizada. El programa se invocaba mediante una directiva de grupo. La migración de perfiles automatizada entre organizaciones tuvo casi un 100% de éxito.

Actualizaciones de hardware
Los nuevos servidores Exchange 2003 iban a sustituir a los servidores Exchange 5.5 dispersos geográficamente, por lo que el aspecto de hardware de esta solución tenía que admitir la misma cantidad de usuarios que la implementación de Exchange 5.5, además de la carga de las cuentas de estudiantes adicionales. Los servidores tendrían que alojarse localmente en el distrito, pues la topología WAN estaba diseñada de manera que todo el tráfico entre distritos (de Internet e interno) fluyese por una línea T1 privada (en algunos distritos, varias líneas T1).
Debido a limitaciones presupuestarias, de administración y de alojamiento de equipos, los servidores Exchange no tendrían almacenamiento conectado a una red de área de almacenamiento (SAN), de manera que todo el almacenamiento tendría que ser interno o de conexión directa. Puesto que la mayoría de los distritos no tienen centros de datos con almacenamiento en bastidor ni refrigeración centralizada, los servidores tenían que ser lo más independientes posible. Afortunadamente, la mayoría de los distritos tenían menos de 5.000 usuarios, lo que permitía realizar implementaciones de un solo servidor. En los distritos que tenían más usuarios, se usaron servidores más eficaces (o varios servidores) y almacenamiento adicional, a veces con servidores de aplicaciones independientes para separar más el tráfico del personal del de los estudiantes.
En la mayoría de los distritos, pudimos implementar servidores de procesador dual bien equipados que estaban configurados con una cantidad máxima de unidades Ultra320 SCSI a 15.000 RPM, varios controladores RAID y 4 GB de RAM. Los distritos más grandes tenían uno o más servidores de procesador quad, que usan servidores de aplicaciones más pequeños si es necesario. Las pruebas de referencia y rendimiento previas a la implementación no mostraron problemas de uso ni de carga. No obstante, los diferentes grados de patrones de uso locales serían el factor determinante en el rendimiento general del servidor.

Prueba de concepto
A pesar de que el entorno de producción incluye un bosque de Active Directory de 178 dominios, el laboratorio de prueba de concepto (POC) se redujo a 13 dominios de distrito y un dominio raíz vacío. Todos los dominios de prueba se llenaron con exportaciones de los dominios de producción. Los servidores Virtual Exchange 5.5 se crearon y configuraron con copias de las bases de datos de los distritos seleccionados, de manera que pudiésemos comprobar el proceso de migración y la adición del entorno planeado. Todo el laboratorio de pruebas POC se construyó con máquinas virtuales para permitir la creación de líneas de referencia del entorno, poder bloquearlo y, a continuación, volver a implementarlo cuando fuera necesario.
Se diseñaron, codificaron, probaron y finalizaron varias combinaciones de secuencias de comandos (mediante VBScript), paquetes del instalador de Systems Management Server (SMS) y aplicaciones de consola. Por último, hicimos que las secuencias de comandos realizasen la instalación y configuración inicial de Exchange 2003, incluidas las directivas de destinatarios, las listas personalizadas de direcciones y las GAL y los permisos. Las secuencias de comandos también administraron la configuración del grupo administrativo, la configuración de dominios del distrito (creación de grupos de seguridad y delegación de permisos) y la configuración posterior a la implementación para la migración.
El almacenamiento provisional de los servidores Exchange 2003 fue un desafío importante. Teníamos que instalar todos los servidores Exchange correctamente en los 178 dominios sin poner en peligro el resto de la migración. Exchange 2003 se diferencia de Exchange 2000 en que el grupo de servidores de dominio Exchange específico del dominio no se agrega a la lista ACL de la organización hasta que se instala el primer servidor Exchange 2003 en el dominio. En Exchange 2000, el grupo se agrega al ejecutar el proceso DomainPrep. Para asegurarnos que teníamos todos los grupos de seguridad necesarios incluidos en el objeto de organización de Active Directory, tuvimos que instalarlo en un dominio determinado, replicar Active Directory manualmente desde el dominio en el concentrador de replicaciones de Active Directory y, a continuación, pasar esta replicación al siguiente distrito para su instalación. La instalación en el siguiente distrito no se pudo comenzar de forma segura hasta que se confirmó que la lista ACL del objeto de organización tenía el grupo de servidores de dominio Exchange del distrito anterior. Si este proceso se completaba sin seguir un orden ni en un solo dominio, tendría que volver a realizarse la instalación en dicho distrito (como mínimo) u otros distritos no podrían comunicarse entre ellos debido a una lista ACL del objeto de organización que no incluía el resto de distritos correctamente.
Comprobamos la implementación, la configuración, el almacenamiento en servidores y la migración varias veces, hasta que estuvimos seguros de que el proceso funcionaba correctamente en el entorno POC.

La migración y otros quebraderos
Una vez que el equipo del proyecto aprobó los procedimientos y los resultados de la POC, la migración estaba lista para empezar. La OET decidió realizar primero su migración, para poder observar el proceso y sus consecuencias de primera mano. En el momento de la migración, ya habían almacenado todos los servidores y se había verificado el entorno inicial. Todos los servidores del protocolo de aplicaciones y los servidores de buzones estaban en su sitio y listos para pasar al entorno de producción con los usuarios.
La ejecución del plan de migración se realizó correctamente y, después de 21 largas horas de transferencia de contenido de un servidor a otro, la OET tenía en marcha Exchange 2003. Afortunadamente, no hubo problemas importantes en la migración de perfiles de Outlook de Exchange 5.5 a Exchange 2003. Empaquetamos un archivo por lotes que invocaba a ExProfRe.exe en diferentes configuraciones de acuerdo con una lógica simple. A continuación, distribuimos el archivo por lotes y ExProfRe.exe en el recurso compartido Netlogon de un controlador de dominio (DC) de cada distrito y usamos la directiva de grupo para ejecutar el lote en todos los clientes al final de la migración. Esta operación funcionó correctamente en la OET, por lo que estábamos seguros de que el proceso avanzaría.
En este punto, revisamos y volvimos a aprobar el plan de migración según nuestra experiencia en la implementación en la OET. Siguiendo con la migración, elegimos seis distritos como primeros sitios de producción. Antes de migrar cada uno de los distritos, MIIS leía la información más reciente sobre los buzones del distrito de Exchange 5.5 y actualizaba los usuarios correspondientes en el dominio del distrito. Usamos el Asistente para migración de Exchange (Mailmig.exe) para trasladar los datos de los buzones entre organizaciones. Mientras el asistente trasladaba los datos de los buzones, se extrajeron y actualizaron todas las direcciones proxy a partir de lo que MIIS exportó originalmente a Active Directory. Durante la migración, el correo se puso en cola en los servidores SMTP de aplicaciones y, después, se entregó al distrito, cuando la migración, la configuración del servidor posterior a la migración y la comprobación de usuarios hubieron concluido; el distrito estaba preparado para realizar una migración de clientes a gran escala mediante ExProfRe.exe.

Problemas con el servicio RUS
Para que los clientes de Outlook funcionasen correctamente, era necesario asegurarse de que la solución de suministro fuese la máxima autoridad en establecer valores de atributos. También era necesario que el Servicio de actualización de destinatarios (RUS) terminase el trabajo, por decirlo de alguna manera, en la configuración de la cuenta. No obstante, el servicio RUS sólo debía ejecutarse cuando el suministro hubiese terminado. Para conseguir esto, las programaciones de las instancias del RUS para los distritos (los 178) se establecieron en Nunca y la solución de suministro usó un código que activase el servicio RUS para su inicio tras la finalización del suministro.
La mayoría de los distritos tenía menos de 5.000 usuarios y muchas menos actualizaciones diarias, así que el servicio RUS terminó rápido, pues el sistema de suministro inició una actualización en lugar de una reconstrucción al final de su ejecución diaria. Pero había varios distritos con más de 10.000 usuarios. Las actualizaciones en estos entornos requerían más tiempo y, si era necesaria una reconstrucción completa del servicio RUS en estos dominios de gran tamaño, podía estar ejecutándose durante una semana o más. Dado que el servicio RUS evalúa todos los tipos de objetos cuando se ejecuta, el efecto de una reconstrucción en un dominio tan grande sería menguante.
No conseguimos encontrar una estrategia de mitigación (y eso que trabajamos con miembros del grupo de productos Exchange para intentar obtener una solución), pero mejoramos el código de suministro para administrar gran parte de las tareas que suele realizar el servicio RUS. Los usuarios obtienen atributos showInAddressBook y proxyAddresses completados en el suministro inicial, de manera que pueden registrarse inmediatamente en lugar de esperar a que el servicio RUS termine su trabajo. También creamos una tarea manual que se ejecuta en uno de los servidores del protocolo de aplicaciones de Exchange 2003. Esta tarea realiza una importación LDIFDE programada y borra las direcciones gatewayProxy del servicio RUS, de manera que si se aplica accidentalmente una directiva de destinatario en el entorno, no se agrega a la lista de tareas pendientes de cada servicio RUS de la empresa.

Problemas de categorizador
Uno de los aspectos interesantes de impedir que los datos de los estudiantes saliesen fuera del distrito escolar era la implementación de controles para evitar que los usuarios enviasen mensajes de correo electrónico fuera de su distrito o a direcciones de Internet externas del sistema. En lugar de trabajar mediante un sistema elaborado de conectores y elementos relacionados, decidimos implementar una característica menos conocida de Exchange 2003 y aplicar restricciones de conector en el conector de grupo de enrutamiento existente desde el distrito al concentrador central donde residen los servidores del protocolo de aplicaciones. Se crearon dos grupos de seguridad en cada dominio, uno para el personal y otro para los estudiantes, y se agregaron a las restricciones del conector.
Tras habilitar la comprobación de restricciones de conector en el registro, empezamos a apreciar algunos problemas que afectaban al rendimiento. Los mensajes se atascaban en el categorizador y las colas de entrega locales durante horas, incluso en el caso de los mensajes dirigidos a destinatarios del mismo servidor. Estos problemas empeoraron a medida que se migraban distritos adicionales. Como solución a corto plazo, desactivamos la comprobación de restricciones de conector y el rendimiento de la entrega de correo mejoró. Más tarde, descubrimos que el categorizador no estaba comprobando únicamente la pertenencia a grupos de los dos grupos de su dominio tras el envío del mensaje, si no también la pertenencia a grupos de los mismos dos grupos en los otros 177 dominios. Esta operación la repetía con todos los mensajes entrantes y salientes del servidor.
Posteriormente, abrimos un caso de soporte en Microsoft. Tras su evaluación, Microsoft se encuentra en proceso de generar una revisión para mitigar este problema y permitir que el categorizador funcione en un modo de complejidad de topología reducida. Actualmente, no disponemos de más detalles sobre dicha revisión, pero el objetivo es proporcionar un valor que permita al categorizador realizar determinadas suposiciones sobre la topología de enrutamiento y que no compruebe la pertenencia a grupos en todos los conectores.

Lecciones aprendidas
Si hay algo que he aprendido en este proyecto, es que los requisitos empresariales controlan todo nuestro trabajo como consultores. En muchas ocasiones, tuvimos que valorar la viabilidad de los requisitos empresariales en comparación con la complejidad de la solución. En esta columna he descrito las decisiones y opciones que me parecieron más apropiadas para nuestro entorno (incluidos los elementos que no he podido comentar aquí), nuestros recursos y nuestros requisitos empresariales. Es posible que para usted las decisiones sean diferentes, aunque espero que esta columna le haya hecho reflexionar sobre ciertos aspectos. Afortunadamente, Exchange 2003 y Active Directory nos proporcionaron la suficiente flexibilidad para satisfacer todos los requisitos de esta compleja migración. Una vez superada la increíble magnitud de la implementación del Departamento de educación de Kentucky, la solución es bastante más simple y se basa en características, a mi parecer, poco usadas de Active Directory y Exchange 2003.
La segunda gran lección ha sido la puesta en práctica de un enfoque equilibrado de la solución de problemas y la administración de riesgos/problemas. En algunas ocasiones es preferible una solución de problemas local, mientras que en otras son necesarios los recursos avanzados de los servicios de soporte técnico de Microsoft.

Mirando hacia el futuro
No cabe duda de que el entorno del Departamento de educación de Kentucky es único. Durante el curso de esta implementación, se usaron o personalizaron casi todas las características de Exchange para satisfacer los requisitos del departamento. Ahora que se ha implementado y migrado correctamente todo el entorno, está preparada la base para implementar funciones adicionales. El Departamento de educación ya ha visto el interés de los distritos escolares en la plataforma Windows Mobile® y espera que esta tendencia hacia los dispositivos móviles continúe.
La consolidación de servidores puede agregar un valor significativo. Actualmente, el Departamento de educación de Kentucky está pensando en virtualizar algunos aspectos del entorno de Active Directory. Con Exchange 2007 en el horizonte, el departamento ha empezado a considerar los requisitos necesarios para una actualización de los sistemas de mensajería.
El Departamento de educación de Kentucky también está buscando ofertas de colaboración adicionales en Live Communication Server, Live Meeting Server, etc. Actualmente, Microsoft Operations Manager 2005 también se está implementando para la administración y supervisión de los servidores de Exchange y Active Directory.

Los resultados
Todos los niños del sistema escolar público de Kentucky disfrutarán de la calidad y la presencia de esta implementación, incluidos mis hijos y los hijos de otras personas con las que he trabajo en este proyecto. Esta implementación ha animado al Departamento de educación de Kentucky a avanzar en lo que se refiere a tecnología, de manera segura y estandarizada, más que nunca. Me siento orgulloso de haber formado parte de este proyecto.

Whitney Roberts es un consultor principal de KiZAN Technologies (www.kizan.com) y trabaja con Exchange desde la versión de Exchange 4.0.


 Preguntas y respuestas de SQL: Prevenci&#243;n de reinicios, instalaci&#243;n de varias actualizaciones y mucho m&#225;s.
Preguntas y respuestas de SQL
Prevención de reinicios, instalación de varias actualizaciones y mucho más.
Editado por Nancy Michell

Cómo evitar reinicios

P ¿Cómo puedo limitar el número de reinicios al aplicar revisiones y similares a SQL Server o al sistema operativo del servidor en general?

R Primero, debe ser que la mayoría de los reinicios posteriores a la instalación no están codificados en el instalador. Normalmente, son el resultado de archivos bloqueados. Esto significa que el instalador está intentado actualizar archivos que ese momento está usando otra aplicación o el sistema operativo (están bloqueados). Existe una manera directa de eliminar estos reinicios, que es asegurarse de que ningún proceso está usando los archivos en cuestión. ¿Cómo puede hacerlo?
El primer paso es determinar los archivos específicos que se estaban usando y estaban bloqueados durante la instalación. La manera más sencilla es buscarlos en el registro, en HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations. La comprobación de esta clave de registro tiene dos objetivos: confirma si la solicitud de reinicio fue causada realmente por archivos bloqueados e indica los archivos que estaban bloqueados. Si consulta el registro después de la instalación, pero antes del reinicio, podrá ver la causa de la solicitud de reinicio y efectuar una serie de pasos para eliminarla en futuras instalaciones.
Puede encontrar dos tipos de entradas. Si un archivo estaba bloqueado contra lectura, verá una entrada de una línea por archivo que indica que el archivo actualizado ya está en el disco, pero que debe borrar la copia temporal que se está usando. Si un archivo estaba bloqueado contra escritura, verá una entrada de dos líneas por archivo que indica que la actualización todavía no se ha realizado, la aplicación está en un estado desconocido y no debería usarse. Es, literalmente, como detenerla en medio de la instalación. En este caso, una línea indica el archivo real y la otra apunta a un archivo temporal (que será el archivo real tras el reinicio).
El paso siguiente depende de muchos factores, pero la idea es identificar el software que está usando los archivos bloqueados. Si puede, use comprobadores de dependencia o la base de datos DLL HELP Database de MSDN® (consulte support.microsoft.com/kb/815065).
Si el software que identifica tiene un servicio, detenga el servicio manualmente y vuelva a intentarlo. Si es una aplicación, ciérrela y vuelva a intentarlo. A veces, hay varias aplicaciones usando un solo archivo y debe detenerlas todas.
El resultado de estas pruebas (en su entorno de prueba) es una lista de las aplicaciones y los servicios que debe detener en el entorno de producción antes de la instalación. De esta manera, el entorno de producción no requerirá un reinicio, ya que no habrá ningún software bloqueando los archivos que está instalando el instalador. Por supuesto, acuérdese de reiniciar estos servicios y aplicaciones cuando haya concluido la instalación.
Lo bueno es que, por lo general, los bloqueos no cambian demasiado. Así que, una vez que haya descubierto este patrón en sus sistemas, probablemente se evitará un montón de reinicios mientras dure el sistema.
Existe otro truco que vale la pena mencionar. Es posible que tenga varias versiones de SQL Server™ u otro producto instaladas en paralelo e incluso en diferentes niveles de versión. Primero, siempre debe actualizar la versión más reciente. Hay muchas posibilidades de que la actualización reemplace todo con las versiones más recientes y el resto de instancias no se ocupen del bloqueo en absoluto. Por ejemplo, si tiene tres instancias de SQL Server 2000 SP3, la primera que actualice a SP4 actualizará el archivo MSXML3.dll y requerirá un reinicio. Pongamos que realiza el reinicio en ese momento. Después, podrá reiniciar las dos instancias siguientes a SP4 sin necesidad de reiniciar, pues ya tiene el archivo MSXML3.dll actualizado. Lo mismo sucede si actualiza instancias de SQL Server 2005 antes de instancias de SQL Server 2000, y SQL Server 2000 antes de instancias de SQL Server 7.0. Esta es una estrategia general de minimización de reinicios que funciona bien.
Globalmente, los equipos de desarrollo de Microsoft han trabajado duro para detener o limitar el número de reinicios en muchos escenarios. Dado que estamos en la columna Preguntas y respuestas (Q&A) de SQL, tomemos SQL Server como ejemplo.
En SQL Server 2005, el equipo de SQL Server dividió el código de Microsoft® Data Access Components (MDAC) necesario para SQL Server en SQLNCLI (archivos nuevos), en lugar de actualizar directamente MDAC, y volvió a sincronizar MDAC con el sistema operativo. ¿Para qué sirve esto? El sistema operativo Windows® usa MDAC y bloquea estos archivos. Por este motivo la mayoría de los service packs, y otros paquetes, de SQL Server le obligan a reiniciar. Ahora, SQL Server puede actualizar su versión de MDAC sin tocar los archivos MDAC del sistema operativo que se estén usando, por lo que no tiene que realizar un reinicio.
Además, ahora, la instalación de SQL Server 2005 SP1 tiene un comprobador de dependencias y una opción de pausa integrados. De esta manera, verá lo que está bloqueado y la causa del bloqueo, y podrá detener en ese momento lo que está causando el bloqueo y continuar con la instalación sin tener que reiniciar. Esto significa que puede hacer pruebas en tiempo real sin necesidad de un laboratorio de pruebas. Por supuesto, también puede continuar y reiniciar si lo desea, o si está realizando la ejecución en modo desatendido. Fíjese lo fácil que es averiguar quién está bloqueando los archivos.
La tecnología de Microsoft Installer también controla las operaciones PendingFileRenameOperations (PFR) existentes mucho mejor. Recordará que la instalación de SQL Server 2000 se bloquea si aparece algún archivo en la clave de registro que mencionamos previamente. La instalación de SQL Server 2005 sólo se bloquea si los archivos pertenecen a SQL Server (pues se produciría un conflicto) e, incluso en esos casos, a menudo puede llegar hasta la clave PFR y actualizarla directamente sin necesidad de reiniciar. Esta tecnología se incluye, a cierto nivel, en MSI y en update.exe, los instaladores estándar de Microsoft actuales que se usan para efectuar todas las instalaciones.
¿Cuáles son algunas de las causas conocidas de estos reinicios? MSXML3.dll es una de los principales. El servicio Windows SVCHost siempre bloquea este archivo, por lo que cualquier operación que incluya este servicio, requerirá un servicio. También se encuentra en la mayoría de las pilas MDAC (mdac_typ.exe). Afortunadamente, MDAC está "sincronizado" con Windows Server® 2003 y Windows XP SP2 y posteriores. El equipo de desarrollo de SQL Server hizo un trabajo excelente al dividir msxmlsql.dll de manera que las actualizaciones de SQL Server no provocasen un reinicio, pero, de momento, sólo verá esto ocasionalmente. No se puede hacer nada al respecto, no puede cerrar SVCHost y seguir ejecutando actualizaciones.
Además, los paquetes update.exe tienen una peculiaridad en el proceso de desinstalación. Si desinstala uno, éste coloca un bloqueo (fuera de las claves PFR, por supuesto) en los archivos locales del instalador. Esto impide que otros paquetes update.exe puedan ejecutarse hasta que reinicie para eliminar el bloqueo. Todo lo que puede hacer es saberlo y programar un reinicio tras la desinstalación de revisiones.
La intermitencia es otro problema. No todos los programas dependen de un archivo el 100% del tiempo. De hecho, los DLL compartidos suelen usarse de forma puntual; es decir, que los otros programas sólo tienen acceso a ellos cuando lo necesitan, en función de su carga de trabajo y las rutas de código. Es decir, que puede hacer la prueba 10 veces y no ver ningún archivo bloqueado y, después, encontrar un archivo bloqueado en la implementación de producción. Desgraciadamente, no hay ninguna bala mágica. Intente crear el entorno de prueba lo más similar posible al entorno de producción, incluida la carga (un buen objetivo, en todo caso), y ejecute las pruebas suficientes para obtener estas permutaciones.
Las actualizaciones y los service packs del sistema operativo se reiniciarán. Además, en las versiones anteriores (Windows 2000, Windows XP y anteriores), la instalación no ha concluido hasta después del reinicio, aunque la clave de registro pendingfilerenameoperations esté vacía. Existen operaciones de registro de paquetes excepcionales que pueden ejecutarse para instalar código durante dicho reinicio. Estas operaciones ni siquiera forman parte de la instalación del service pack, son comandos incrustados en el sistema operativo actual que los escenarios de actualización desencadenan para permitir que ciertas partes del código que está usando sobrevivan a estos escenarios.
Por último, la clave PFR no realiza comprobaciones de versión de archivos ni impone un orden mediante la serialización. Esto significa que inicia las sustituciones de archivos en el orden en que aparecen. Pero se ha demostrado que el orden en que se aplican al disco duro es el último en terminar (no el primero que se inicia). Esto tiene sentido, pero significa que, si tenemos dos copias del mismo archivo en la misma ruta, cada una apuntando a versiones diferentes, el resultado tras el reinicio será aleatorio. Si alguna vez experimenta esto, asegúrese de arreglarlo. Si no está seguro, simplemente vuelva a ejecutar los dos instaladores después del reinicio. Si tiene los archivos correctos, ninguno realizará ninguna acción. Si tiene los erróneos, el paquete que tenga el archivo correcto lo arreglará. Sinceramente, esto es más rápido y más seguro que intentar averiguar el resultado deseado.

Varias instalaciones del service pack

P Tengo ocho instancias de SQL Server 2000 agrupadas en un clúster de 4 nodos y deseo instalar SP4 con el mínimo posible de reinicios. ¿Puedo instalar SP4 en las 8 instancias, una detrás de la otra, y reiniciar todos los nodos al final?

R A Una vez que ha concluido la instalación de una sola instancia de SQL Server SP4, que puede requerir un reinicio, en un servidor Windows determinado (agrupado o no), no debería necesitar reinicios adicionales al instalar SQL Server SP4 en las demás instancias de SQL de ese cuadro. Esto es así porque todos los archivos compartidos (herramientas, MDAC, MSXML, etc.) ya tienen la versión adecuada y, bloqueados o no, no necesitan actualizarse. Todos los archivos no compartidos se usan únicamente en la primera instancia y la instalación los cerrará. Es importante recordar que la instancia más reciente de SQL Server debe actualizarse primero si se tienen varias instancias de diferentes versiones.

Ejecución como un servicio de red

P ¿Qué es exactamente la cuenta AUTHORITY\NETWORK SERVICE de NT y para qué sirve? ¿Y cuáles son las implicaciones de seguridad de esta cuenta, especialmente si se le otorgan derechos sysadmin (sa)?

R Una cuenta del servicio de red tiene la misma identidad (identidad de equipo) que un sistema en la red, pero tiene privilegios reducidos en el cuadro local. Así, si un servicio requiere acceso a los recursos de red, quizás para resolver los nombres de cuenta con el controlador de dominio, debe ejecutarse como un sistema, una cuenta de dominio o un servicio de red. Normalmente, el servicio de red es la opción más segura, ya sólo se limita a un cuadro local e, incluso en éste, tiene privilegios reducidos.
Al convertir el servicio de red en administrador del sistema en SQL Server, los demás servicios que se ejecuten como servicio de red en un cuadro local tendrán un control total sobre el servidor. Esto sucede, por ejemplo, cuando la cuenta de servicio de SQL Server está configurada para ejecutarse como servicio de red. El servidor requiere que la cuenta de servicio de SQL Server sea miembro de sysadmin para su funcionalidad (por ejemplo, para permitir conexiones de bucle invertido). No es muy seguro ejecutar el servicio de red como administrador en SQL Server, pero es mejor (o no) que usar una cuenta de dominio con este fin y mucho más seguro que ejecutar SQL Server como un sistema local.
Si no desea que el servicio de red tenga los privilegios de sysadmin, la siguiente opción es usar una cuenta de dominio dedicada específicamente a ejecutar SQL Server en una o más instalaciones de Windows NT®.
Encontrará ayuda en los artículos siguientes: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp y microsoft.com/technet/security/topics/serversecurity/serviceaccount.

Creación de varias bases de datos

P Estoy pensando en repartir los datos en bases de datos individuales, quizás 250 bases de datos en línea a la vez. Calculo que sólo se usará el 20% a la vez para consultas activas. ¿Es mejor tener muchas bases de datos que tener pocas?

R El número de bases de datos en una instancia de servidor de bases de datos depende de las necesidades empresariales y de factores administrativos. La creación de varias bases de datos en una sola instancia de servidor conlleva poca carga, pero tener más bases de datos implica una mayor carga administrativa en lo que se refiere a tareas de mantenimiento como copias de seguridad y restauración, creación de reflejos, cuentas de usuario y funciones de usuarios. La complejidad administrativa adicional puede pesar más que la ventaja de tener bases de datos adicionales.
Como regla general, todos los datos relacionados con una aplicación deben mantenerse en una base de datos, lo que facilita la recuperación tras un error. Si los datos de una aplicación están repartidos en varias bases de datos, habrá que recuperar todas las bases de datos durante un error. Esto puede retrasar la recuperación o incluso impedirla si no se puede recuperar una de las bases de datos.
Dicho esto, hay varios motivos para separar los datos en varias bases de datos:
  • Un subconjunto de datos tiene requisitos de copia de seguridad diferentes a los de otros datos.
  • Determinados datos requieren un contexto de seguridad independiente, es decir, un propietario de base de datos diferente.
  • A veces, los datos existen con fines históricos y deben estar en modo de sólo lectura.

Mis agradecimientos a los siguientes profesionales de TI de Microsoft por la aportación de sus conocimientos técnicos: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson y Madhusudhanan Vadlamaani.

Editado por Nancy Michell


 &#161;Hola, chicos del scripting!: &#191;D&#243;nde est&#225;n los soportes para vasos?
¡Hola, chicos del scripting!
¿Dónde están los soportes para vasos?
Los chicos del scripting de Microsoft
Este artículo se basa en una versión preliminar de Windows PowerShell. Toda la información que aquí se menciona está sujeta a cambios.

Cuando se presenta una tecnología nueva, normalmente, la gente tarda un poco en apreciar realmente la diferencia entre la nueva tecnología y la anterior. Veamos, por ejemplo, el caso de los primeros automóviles. Hay un motivo por el que esos artilugios se conocían como carruajes sin caballos: eso es básicamente lo que eran. En realidad, la única diferencia entre los primeros automóviles y los carruajes tirados por caballos era que unos usaban caballos y los otros no. Aparte de eso, era difícil apreciar la diferencia.
Por supuesto, hoy nadie confundiría un automóvil con un carruaje tirado por caballos. El motivo es que, con el tiempo, los fabricantes de coches consiguieron avances que diferenciaban claramente los coches de los carruajes. Por ejemplo, los coches de hoy vienen de fábrica con reproductores de CD, aire acondicionado y sistemas de navegación por satélite; pocos carruajes de caballos pueden decir lo mismo. De la misma manera, suponga que conducía un carruaje tirado por caballos en la década de 1880 y necesitaba soltar el Frappuccino por un momento; lo sentimos, mala suerte. En contraste, algunos SUV vienen con nada menos que 17 soportes para vasos de serie y hay, como mínimo, un automóvil que incluye tres soportes para vasos sólo para el conductor. Algunos modelos más nuevos incluso disponen de soportes para vasos que pueden calentar o enfriar la bebida según lo desee.
Nota Sí, es difícil creer que, en algún momento, las personas tuvieron que sobrevivir sin poder beber tres bebidas diferentes mientras conducían. ¿Cómo va a conducir con sólo una o dos bebidas a su alcance?
Antes de que una tecnología nueva sea un éxito, la gente necesita saber por qué debe decantarse por la nueva y desconocida en lugar de por la antigua y de confianza. Cuando los DVDs aparecieron en el mercado, permitían ver películas, igual que los reproductores de vídeo. Sin embargo, los DVDs eran mucho más caros que los reproductores de vídeo y los reproductores de DVD no permitían grabar nada. No hace falta decir que los DVDs no arrasaron. De hecho, hasta que los fabricantes de DVD no empezaron a incluir escenas inéditas, comentarios de actores que ni siquiera se sabía que aparecían en la película y otras características que no tenían las cintas de vídeo, los DVDs no empezaron a sustituir a sus homólogos VHS. No bastaba con poder ver una película en casa, los fabricantes de DVD tenían que ofrecer algo más de lo que ya tenía la gente.
Nota Si alguien mira estos extras, es otro tema: la naturaleza humana es así, si hay algo disponible, lo quieres. Casualmente, los chicos del scripting están pensando en diseñar un DVD en el que se incluya, principalmente, texto eliminado de las columnas de la revista TechNet Magazine y finales alternativos para las secuencias de comandos de administración del sistema.

Uso de Windows PowerShell
Windows PowerShell™, la nueva tecnología de secuencias de comandos/shell de comandos de Microsoft, es otro ejemplo. La primera información que se suele recibir sobre Windows PowerShell es la siguiente:
  • "Windows PowerShell permite administrar procesos y servicios."
  • "Windows PowerShell permite recuperar eventos de los registros de eventos."
  • "Windows PowerShell permite usar WMI para administrar equipos."
Estas tareas no tienen nada de malo, de hecho son útiles e importantes. El único problema es que se puede realizar con VBScript y Windows Script Host. La compatibilidad con versiones anteriores es importante y Windows PowerShell no sería una aplicación innovadora si ni siquiera permitiese realizar las mismas tareas que VBScript. (Imagínese un reproductor de DVD que no pudiese reproducir películas. En realidad, no tiene que imaginárselo: uno de los chicos del scripting tiene uno en casa.)
No obstante, si Windows PowerShell sólo permite realizar las mismas tareas que VBScript, ¿por qué nos íbamos a molestar en descubrir esta nueva tecnología? Es cierto que VBScript no viene con soportes para vasos de serie, pero tampoco Windows PowerShell. Así, ¿en qué radica la diferencia de usar una tecnología de secuencias de comandos u otra?
Francamente, es posible que al fin y al cabo no haya ninguna diferencia. Por otro lado, dejando los soportes para vasos aparte, Windows PowerShell sí tiene algunas capacidades que VBScript no tiene. Si sólo tiene que administrar procesos y servicios, es posible que no tenga ningún motivo de peso para adquirir Windows PowerShell; como se suele decir, si no está roto, no lo arregle. (Para los chicos del scripting, esta máxima suele entenderse como "No intentéis arreglarlo, porque lo estropearéis.") El principal atractivo de Windows PowerShell es que permite realizar operaciones que VBScript no puede; por ejemplo, cambiar la hora de la última escritura de un archivo.

Cambio de la hora de la última escritura
Ha oído bien: cambiar la fecha de la última modificación de un archivo. Existen varios motivos (por ejemplo, una forma rápida y sencilla de control de versión) por los que los escritores de secuencias de comandos siempre han deseado poder cambiar la hora de la última escritura (o hora de creación) de un archivo o conjunto de archivos. Por desgracia, ni el Instrumental de administración de Windows (WMI) ni FileSystemObject tienen esta capacidad, la fecha y la hora del archivo son de sólo lectura en ambas tecnologías.
En cambio, Windows PowerShell permite cambiar la hora de la última escritura de un archivo a la fecha y la hora actuales de una manera tan sencilla como ejecutar el comando siguiente:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Antes de describir el funcionamiento de este comando, respondamos a una pregunta que seguramente todos tienen en mente: ¿cómo puede Windows PowerShell modificar la hora de la última escritura de un archivo si WMI no puede? Creemos que debemos responder a esta pregunta antes de nada, ya que se trata de una idea equivocada habitual sobre Windows PowerShell. Los usuarios tienden a pensar que Windows PowerShell no es más que una nueva manera de usar WMI. De acuerdo, sin duda se puede usar Windows PowerShell para tener acceso a datos WMI; también es verdad que, mientras esperamos la creación de cmdlets adicionales (comandos nativos de Windows PowerShell), la mayoría de las secuencias de comandos de administración del sistema se basarán principalmente en WMI. Sin embargo, Windows PowerShell se basa esencialmente en .NET Framework y los cmdlets de Windows PowerShell suelen tratar con objetos .NET, no objetos WMI. Esto es importante porque las propiedades disponibles en .NET Framework no son necesariamente las mismas que las propiedades disponibles en WMI.
Por ejemplo, cuando usamos el cmdlet Get-Item para enlazarlo con un archivo, no obtenemos una instancia de la clase WMI CIM_Datafile, sino que obtenemos un objeto .NET. ¿Y eso es tan importante? Le aseguro que lo es. El objeto .NET muestra un conjunto de propiedades y métodos ligeramente diferentes a los que proporciona WMI para la administración de archivos. Como hemos visto, estas pequeñas diferencias pueden ser de suma importancia, como la diferencia entre una propiedad de sólo lectura y otra de lectura y escritura.
Una pregunta de fondo: ¿cómo sabemos que el cmdlet Get-Item devuelve un objeto .NET? En este caso, y en la mayoría de los casos, el modo más sencillo de averiguar con qué clase de objeto estamos trabajando (así como el modo más sencillo de identificar las propiedades y los métodos disponibles) es enlazar el archivo y, a continuación, pasar ese objeto al cmdlet Get-Member:
Get-Item c:\scripts\test.txt | Get-Member
Los resultados de este comando se muestran en la figura 1. Como puede ver, se trata de un objeto .NET (¡como si los chicos del scripting se pudiesen equivocar en algo así!)
Figure 1 Miembros de Objeto devuelto por Get-Item (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
Por cierto, este pequeño comando ilustra dos de las capacidades más interesantes (y útiles) de Windows PowerShell: canalización y metainformación. No entraremos en detalles técnicos, pero la idea básica que se esconde tras la canalización es que puede usar un cmdlet para obtener un objeto y, a continuación, pasar este objeto a otro cmdlet. En este comando hemos usado el cmdlet Get-Item para obtener un objeto que represente el archivo C:\Scripts\Test.txt y, a continuación, hemos pasado este archivo (como un objeto) a través de la canalización al cmdlet Get-Member. (El símbolo | representa la canalización en un comando de Windows PowerShell.)
Entonces, Get-Member realiza su tarea, que consiste en recuperar las propiedades y los métodos para el objeto recuperado. Esta es otra de las ingeniosas características de Windows PowerShell: es muy fácil tener acceso a la metainformación, información sobre la información. Los cmdlets como Get-Member y Get-Command permiten interrogar a Windows PowerShell tanto como desee, más o menos de la misma manera en que escribe una secuencia de comandos de WMI para recuperar información sobre las clases, propiedades y métodos de WMI disponibles.
Recuerde que Get-Member va un paso más adelante de lo que le permite hacer WMI. Puede usar WMI para obtener información sobre objetos WMI, pero no puede usarlo para obtener información sobre otros objetos COM (como por ejemplo, FileSystemObject). No es el caso de Windows PowerShell. Get-Member funciona con todos los objetos que enlace o cree. ¿No recuerda los métodos que hay disponibles cuando usa FileSystemObject? Entonces, ejecute el comando siguiente:
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
Esta capacidad es increíblemente útil y, hasta la fecha, poco empleada.
Funciona, ¿verdad? Si nos desplazamos por la lista de propiedades y métodos disponibles cuando trabajamos con el archivo C:\Scripts\Test.txt, finalmente veremos esta línea:
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
Interesante. Aparentemente, LastWriteTime es una propiedad que admite tanto el comando get (lectura) como el comando set (escritura). ¿Significa esto que podemos usar Windows PowerShell para modificar el valor de la hora de la última escritura del archivo? Hmmm...
Glosario de Windows PowerShell
Alias Nombre personalizable que representa un cmdlet existente. Windows PowerShell proporciona una serie de alias predeterminados que asignan comandos de shell comunes a sus cmdlet equivalentes.
Cmdlet Unidad de funcionalidad más pequeña de Windows PowerShell, análoga a los comandos integrados de otros shells.
Comando Unidad de ejecución en Windows PowerShell. Los comandos pueden incluir varias operaciones canalizadas y pueden abarcar líneas empleando el carácter ;.
Frappuccino Bebida de café con hielo que se sirve en Starbucks.
Shell de comandos Monad/MSH/Microsoft Nombres de código anteriores para Windows PowerShell.
Objeto Datos con estructura recuperados del sistema o un comando. Windows PowerShell manipula los datos como objetos .NET, lo que permite manipular las propiedades de los objetos por nombre, en lugar de tener que analizar la salida del comando basados en texto.
Parámetro Opciones establecidas en un cmdlet de la línea de comandos. Windows PowerShell usa un carácter de guión inicial (-) para designar un parámetro.
Canalización Permite el envío de la salida de un comando a la entrada de otro comando. También se llama canal y, en los comandos, se representa mediante el carácter |.
Perfil Valores que permiten configurar el funcionamiento del shell. Estos valores se cargan cuando se inicia Windows PowerShell.
Secuencia de comandos Uno o más comandos guardados como un archivo y que se ejecutan desde un archivo. Windows PowerShell usa una extensión .ps1 para los archivos de secuencia de comandos.
Shell Entorno de línea de comandos en el que puede ejecutar tanto comandos como cmdlets.
Variable Objeto o parámetro cuyo valor se puede establecer, modificar o recuperar durante la ejecución de un comando.

Retomemos el tema anterior y hablemos sobre el comando que establece la hora de la última escritura de Test.txt en la fecha y la hora actuales. Tiene el siguiente aspecto:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Como puede ver, el comando no es demasiado complicado. Para empezar, se declara una variable llamada $a. A continuación, se usa el cmdlet Get-Item para conectarse al archivo C:\Scripts\Test.txt. De esta manera, se almacena el objeto en la variable $a. Después de escribir un punto y coma (que permite efectuar varios comandos en una sola línea), se establece el valor de la propiedad LastWriteTime en la fecha y la hora actuales. Esto casi compensa que no tenga soporte para vasos, ¿verdad?

Seamos un poco más elegantes
Por supuesto, no está limitado a establecer la hora de la última escritura en la fecha y la hora actuales. Considere, por ejemplo, este comando:
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
Esta vez hemos unido tres comandos. Primero, empleamos el cmdlet Get-Date para crear un objeto de fecha-hora igual a 22/05/2006, 08:15 p.m. ¿Por qué no hemos tenido que usar Get-Date para crear un objeto de fecha-hora en la primera secuencia de comandos, la que establece la hora de la última escritura en la fecha y la hora actuales? Es fácil: el comando Date devuelve automáticamente un objeto de fecha-hora. (Si desea verificarlo, escriba el comando siguiente en la consola de Windows PowerShell: Date | Get-Member.)
Tras crear un objeto de fecha-hora igual a la fecha y la hora deseados, se debe usar el comando Get-Item para obtener un objeto que represente al archivo Test.txt (un objeto que se almacena en la variable $a). Por último, se establece la propiedad LastWriteTime en el valor representado por la variable $b:
$a.LastWriteTime = $b
Lo crea o no, todavía no ha visto ni la mitad. Eche un vistazo a este comando de aspecto inofensivo:
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
¿Qué tiene de interesante este comando? Veamos lo que hace. La primera parte es sencilla: una vez más, se debe crear un objeto de fecha-hora equivalente a 22/05/2006, 08:15. Sin embargo, en la segunda parte no se usa el cmdlet Get-Item, sino que se usa este comando:
Get-ChildItem c:\scripts
¿Por qué? Bueno, cada vez que se aplica el cmdlet Get-ChildItem a una carpeta, se obtiene una colección de todos los archivos que se encuentran en dicha carpeta. Tomemos esa colección y pasemos todos sus elementos a través de la canalización (otra vez, el símbolo |) hasta el cmdlet ForEach-Object.
¿Qué va hacer ForEach-Object con todos estos archivos? Pues va a cambiar el valor de la propiedad LastWriteTime en todos ellos, por supuesto:
ForEach-Object {$_.LastWriteTime = $b}
Nota Aunque la columna de este mes no pretende ser una guía para principiantes de Windows PowerShell, deseamos destacar que $_ es una variable especial que representa el elemento actual de un bucle For Each. Es equivalente a objItem en el bucle de VBScript siguiente:
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
Cuando el comando de Windows PowerShell termine de ejecutarse, todos los archivos de la carpeta C:\Scripts tendrán la misma hora de la última escritura. ¡Ya nos gustaría ver a uno de esos nuevos carruajes sin caballos hacer eso!
Podríamos estar ejecutando variantes de este comando toda la noche. Por ejemplo, es posible que sólo desee cambiar la hora de la última escritura de los archivos .txt de la carpeta C:\Scripts. De acuerdo, sólo tenía que preguntar:
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

Abramos su apetito
Es estupendo. No obstante, queremos mencionar que el objetivo de esta columna no es "venderle" Windows PowerShell, ni animarle a tirar todas sus secuencias de comandos de VBScript y convertirlas a Windows PowerShell. Si esas secuencias de comandos hacen lo que desea y necesita que hagan, déjelas tal como están; y lo mismo para los archivos por lotes, herramientas de líneas de comandos, correctores ortográficos o cualquier otra herramienta que use para administrar sus equipos. Recuerde, si no está roto...
Lo importante no es que Windows PowerShell le permita hacer lo que ya puede hacer, sino que (en parte porque proporciona acceso a .NET Framework) Windows PowerShell le permite hacer cosas que no podía hacer antes. La posibilidad de modificar la fecha del último acceso a un archivo (o un grupo de archivos) es un ejemplo de esto. Si hay otros ejemplos o no, depende de lo que necesite hacer. Esas capacidades son las que hacen que merezca la pena echar un vistazo a Windows PowerShell.
Seguramente, para muchos, ha sido una presentación poco usual a Windows PowerShell: después de todo, en lugar de empezar con un simple "Hola a todos", hemos arrancado directamente con un comando de Windows PowerShell de varias partes, presentando constantemente términos como canalización y cmdlet, como si todo el mundo supiese lo que significan. Ha sido a propósito. Al fin y al cabo, sabemos que muchos de ustedes todavía tienen que probar Windows PowerShell y nos daba miedo enseñarles cómo recuperar una lista de servicios de un equipo y que se limitasen a encogerse de hombros y seguir con lo que estaban haciendo.
Nota Esperamos que no estuviesen conduciendo. Para muchos de ustedes ya es bastante difícil beber tres bebidas diferentes, ver un DVD y hablar por el móvil mientras conducen sin añadir la "lectura de TechNet Magazine" a la mezcla.
Eh, vamos: dijimos para muchos de nosotros. No para todos nosotros.

Los chicos del scripting de Microsoft trabajan para (bueno, son empleados de) Microsoft. Cuando no juegan al béisbol, ni entrenan ni lo ven (u otras actividades varias), dirigen el TechNet Script Center. Visite la página web www.scriptingguys.com.


 Vigilancia de seguridad: Implementaci&#243;n de una PKI confiable globalmente
Vigilancia de seguridad
Implementación de una PKI confiable globalmente
John Morello
Esta columna incluye información preliminar que está sujeta a cambios.

Una infraestructura de claves públicas, o PKI, es un elemento fundamental para crear confianza entre diferentes aplicaciones, sistemas operativos y dominios de identidad. Se crea a partir de un modelo de confianza jerárquico en el que las entidades finales confían en una clave común del nivel raíz más alto y, por lo tanto, se confía implícitamente en cualquier otra clave firmada por dicha raíz.
Gracias a esta estructura, una PKI bien diseñada puede ampliarse fácilmente agregando entidades emisoras de certificados (CA), sin introducir cambios en las entidades finales.
Normalmente, las PKI se implementan de una de estas dos formas. El enfoque más común consiste en adquirir los certificados necesarios de uno de los proveedores de raíces globales en los que se confíe implícitamente, como por ejemplo, Cybertrust o VeriSign. Estos certificados se usan con frecuencia para proteger el tráfico de los sitios Web, pero también pueden usarse para cifrar redes privadas virtuales (VPN), firmar correo electrónico y tareas similares. Dado que estas raíces globales están integradas en todos los exploradores Web y sistemas operativos modernos, este método puede ampliar fácilmente una relación de confianza a través de límites organizativos. No obstante, puesto que estos certificados sólo se adquieren si son necesarios, puede resultar costoso implementar este enfoque ampliamente dentro de una gran organización.
El modelo de PKI interna ha pasado a ser recientemente más común. Tal como sugiere el nombre, una PKI interna sólo es confiable dentro de la propia red de una organización. Este modelo proporciona a las organizaciones una forma más barata de asignar recursos a los usuarios y los dispositivos informáticos de su red usando certificados. Este enfoque se suele usar para facilitar tecnologías como el inicio de sesión con una tarjeta inteligente, el sistema de cifrado de archivos (EFS) y la protección de conexiones de redes inalámbricas. La desventaja es que como estos certificados no son confiables globalmente, no resultan apropiados para aplicaciones que se comunican con el exterior. Por consiguiente, la mayoría de las organizaciones que han implementado PKI internas suelen adoptar un enfoque híbrido mediante la compra de certificados para aplicaciones públicas de una de las raíces confiables globalmente.
Pero, ¿y si pudiera obtener lo mejor de ambos métodos? ¿Qué le parecería si su organización pudiera ejecutar su propia PKI (con el ahorro de costos que supone la emisión de certificados internos) y al mismo tiempo proporcionara certificados confiables públicamente, todo esto desde su propio sistema local? Una solución de este tipo ofrecería las ventajas de una PKI interna (como la integración de Active Directory®, la inscripción automática y el soporte de TI traducido), así como la ventaja clave de una raíz confiable globalmente. La universidad estatal de Louisiana (LSU) tiene exactamente este sistema. En esta entrega de Vigilancia de seguridad, examino la solución que implementamos en LSU, explico su diseño técnico y resalto las prácticas recomendadas que deben usarse al implementar un sistema similar. Debe tenerse en cuenta que la solución que voy a describir satisfacía nuestras necesidades concretas, con un entorno y unos recursos y unos requisitos empresariales determinados. Debe evaluar de antemano todos estos aspectos de su empresa a fin de determinar el tipo de solución que sea adecuado para usted.

Forma en que LSU crea una PKI
LSU es una universidad en la que se realizan importantes investigaciones y que cuenta con más de 40.000 estudiantes, profesores y empleados. Tiene muchos sitios Web a disposición del público, y muchos de estos sitios requieren Seguridad de la capa de transporte (TLS), que es el término adecuado para los certificados de capa de sockets seguros (SSL). LSU solía invertir miles de dólares anualmente en certificados de los proveedores de raíces confiables globalmente.
Al mismo tiempo, LSU tenía otros objetivos de seguridad de TI que podían mejorarse enormemente con una PKI interna bien diseñada. Dados los objetivos y los requisitos de LSU, se podía suponer que elegiríamos un modelo híbrido. Sin embargo, optamos por un enfoque que creímos más innovador.
Trabajamos con una de las raíces confiables globalmente, Cybertrust, para implementar una CA en las instalaciones de LSU que fuera subordinada de una CA raíz de Cybertrust (consulte la figura 1). Cybertrust ofrece este servicio en su programa OmniRoot. En este escenario, LSU crea y usa una CA que se ejecuta localmente en equipos que son propiedad de LSU. No obstante, a diferencia del modelo interno descrito anteriormente, la CA de LSU no está autofirmada y su clave (así como las claves que ésta firme) es confiable implícitamente en casi todos los sistemas operativos y exploradores modernos. Técnicamente, este diseño es una extensión lógica de la apertura de los estándares x.509. Dado que una PKI se crea a partir de estos estándares, se pueden conectar sistemas creados por distintos proveedores en la misma jerarquía general. Dicho esto, lo que resulta particularmente interesante acerca de la solución OmniRoot son las condiciones de uso para el servicio.
Figura 1 Certificado de raíz global de Cybertrust
Figura 1 Certificado de raíz global de Cybertrust (Hacer clic en la imagen para reducirla)
Figura 1 Certificado de raíz global de Cybertrust
Figura 1 Certificado de raíz global de Cybertrust (Hacer clic en la imagen para ampliarla)
El servicio OmniRoot está específicamente diseñado para el tipo de implementación de PKI que llevamos a cabo en LSU. En el programa OmniRoot, las organizaciones pagan a Cybertrust una cuota anual fija por participar en éste, y después pagan una cuota por certificado sólo en el caso de los certificados creados para uso público. En otras palabras, LSU puede emitir tantos certificados como necesite para uso interno sin preocuparse por el aumento de costo debido a las cuotas por certificado. Mientras tanto, el costo de los certificados a disposición del público es ahora significativamente más barato de lo que se pagaba cuando la universidad adquiría certificados en los casos necesarios.
Para ser más precisos, los certificados internos y los certificados públicos son idénticos desde un punto de vista técnico. Se emiten desde la misma cadena de CA, tienen la misma eficacia criptográfica y se suministran a través del mismo sistema de autoridad de registro. La única diferencia entre ambos son los términos de la licencia.
Finalmente, hemos podido ampliar y mejorar la plataforma de seguridad de TI de LSU a un costo más bajo. Este logro creó una gran razón empresarial para este tipo de solución PKI en LSU. Ahora echaremos un vistazo a los detalles más técnicos de la implementación.

Jerarquía PKI
La jerarquía PKI de LSU se crea mediante un diseño de dos niveles en el que Cybertrust administra el nivel raíz y una CA emisora en línea se ejecuta en LSU (consulte la figura 2). El nivel raíz forma el delimitador de confianza en la jerarquía. En otras palabras, la relación de confianza de todos los certificados emitidos por cualquier CA de la jerarquía se encuentra bajo la CA raíz (consulte la figura 3). Por lo tanto, la CA raíz forma el enlace común entre todas las CA, los certificados y las entidades finales de la jerarquía. Como la raíz global de Cybertrust ya está integrada en Windows® y casi todos los sistemas informáticos modernos, este enlace común se extiende automáticamente más allá de la red de LSU.
Figure 2 Jerarquía PKI de dos niveles (Close Figure 2)

Nivel raíz (Cybertrust) | Nivel emisor (LSU)
Administrado por Cybertrust | Administrado por LSU
Situado en el centro de datos seguro de Cybertrust | Situado en el campus Baton Rouge de LSU
Incluido en el certificado raíz predeterminado de casi todos los sistemas informáticos modernos | Emite certificados a entidades finales de las organizaciones del sistema LSU
 | Los certificados emitidos por LSU se incluyen en la raíz de Cybertrust y, por lo tanto, son confiables globalmente.
Figura 3 Certificado emitido desde la CA emisora de LSU
Figura 3 Certificado emitido desde la CA emisora de LSU (Hacer clic en la imagen para reducirla)
Figura 3 Certificado emitido desde la CA emisora de LSU
Figura 3 Certificado emitido desde la CA emisora de LSU (Hacer clic en la imagen para ampliarla)
Cybertrust administra la CA raíz en uno de los servicios de alojamiento seguros. El servicio de alojamiento usa eficaces controles de seguridad física, en los que se incluyen capturas manuales, bloqueos biométricos y una cámara de almacenamiento totalmente revestida de cobre. Cybertrust sólo emite certificados a las CA emisoras de las organizaciones que han demostrado cumplir sus directivas de seguridad y certificado.
La CA emisora de LSU es un sistema orientado a entidades finales que es responsable de proporcionar certificados a la población de usuarios y equipos de LSU. Su certificado lo firma la CA de Cybertrust que se encuentra por encima en la jerarquía y ésta emite certificados que se enlazan a través de ella misma con la CA raíz de Cybertrust (consulte la figura 3).

El SO y hardware emisores
LSU usa Windows Server® 2003 Enterprise Edition con Service Pack 1 para la CA emisora. El servicio de la entidad emisora de certificados de Windows Server 2003 ofrece muchas funciones, como por ejemplo, el archivo de claves, las listas de revocación de certificados (CRL) delta y las plantillas de la "versión 2". La instancia de Windows que se usa como CA emisora se crea de acuerdo con la directiva de creación estándar de Windows Server de LSU. Se actualiza con todas las actualizaciones de seguridad pertinentes y se administra mediante las prácticas de administración de cambios estándar de LSU y las herramientas de actualización y de inventario de software. En resumen, aunque existen algunos aspectos únicos en la administración del mismo servicio CA, el sistema operativo y el hardware de servidor base se integran fácilmente en las operaciones de TI existentes en la organización.
Además de seguir las prácticas recomendadas estándar de LSU para la instalación del servidor, empleamos el Asistente de configuración de seguridad (SCW), que está disponible en Windows Server 2003 Service Pack 1. SCW usa una base de datos que contiene matrices de dependencia de las distintas cargas de trabajo que pueden ejecutarse en Windows Server y la configuración de seguridad que requieren estas cargas de trabajo. Esta base de datos incluye las dos funciones principales que proporcionará la CA: el mismo servicio CA e IIS (que proporciona el sitio Web de autoservicio de PKI).
Con ayuda de SCW, creamos fácilmente una plantilla de seguridad que deshabilitó todos los servicios que no eran necesarios para ejecutar estas cargas de trabajo y reforzamos la pila de red del servidor. Después usamos scwcmd.exe para transformar esta plantilla en un objeto de directiva de grupo (GPO) de forma que pudiéramos aplicarlo al servidor en el nivel de unidad organizativa. Este enfoque simplifica la ampliación y la recuperación de desastres, ya que la configuración de seguridad basada en funciones de una CA de LSU se almacena actualmente en Active Directory, en lugar de ser específica de un equipo.
La CA emisora de LSU se incorpora a un servidor IBM xSeries 346 con dos procesadores Intel Xeon a 3,2 GHz, 4 GB de RAM y cinco discos duros SCSI de 146 GB. Teniendo en cuenta las exigencias de rendimiento del servicio CA y el hecho de que LSU usa un módulo de seguridad de hardware, esta plataforma deberá proporcionar una duración y un espacio en cabeza considerables para el crecimiento.
Seguimos prácticas recomendadas estándar para separar bases de datos y archivos de registro en ejes físicos independientes creando dos matrices RAID 1. El quinto disco duro se reserva como "reposición en directo" y está disponible para cualquiera de estas matrices. Montamos la primera matriz como nuestro volumen de sistema, que es donde guardamos la base de datos de CA. La segunda matriz se usa para archivos de registro y para otros tipos de archivos de datos, como por ejemplo, las CRL. La base de datos de CA se basa en la misma tecnología Jet que existe en otras partes de Windows, como Active Directory; por lo tanto, aquí se aplican las mismas prácticas recomendadas de mantenimiento y configuración de discos que en otras soluciones de almacenamiento basadas en Jet.
Un módulo de seguridad de hardware (HSM) es un dispositivo de hardware dedicado que se administra independientemente del sistema operativo. Los HSM, normalmente, se suministran como adaptadores PCI, pero también están disponibles como dispositivos basados en redes. Estos módulos proporcionan un almacenamiento de hardware seguro para las claves de CA, así como un procesador criptográfico dedicado para acelerar las operaciones de firma y cifrado. Windows usa los HSM a través de las interfaces CryptoAPI; se considera que el HSM es como un dispositivo CSP (proveedor de servicios criptográficos). El programa OmniRoot requiere que cada CA use al menos un HSM certificado por FIPS 140-2 de nivel 3 (los dispositivos de nivel 4 son bastante poco frecuentes) para la generación y el almacenamiento de claves. Al tratarse de un dispositivo único y altamente seguro, HSM supone una importante inversión financiera. Los precios de venta de los HSM basados en PCI se encuentran generalmente entre los 10.000 y los 15.000 dólares.
En el diseño de LSU, se usa un nCipher nShield 500 TPS (modelo de 500 transacciones por segundo) como un HSM conectado directamente. ("Conectado directamente" significa que está en el interior del servidor y que sólo está disponible para el uso de dicho servidor, en lugar de ser un HSM basado en redes que pueda ser compartido por varios hosts. El HSM es un dispositivo FIPS 140-2 de nivel 3 y proporciona protección K de N del material de claves. HSM ofrece una protección significativa frente a la posibilidad de que las claves privadas vean comprometida su seguridad: para que un atacante pueda tener acceso a la clave, necesitaría poseer tanto el almacenamiento de HSM como un número concreto de símbolos de acceso y los PIN correspondientes.
Es esencial destacar que los HSM están diseñados para impedir que personas malintencionadas puedan alterar su contenido. Por lo tanto, los HSM limitan estrictamente el número de intentos de inicio de sesión fallidos consecutivos. En el diseño de LSU, el almacenamiento se borra de forma irrevocable después de 10 intentos fallidos consecutivos.
Tenemos una sola CA en nuestra instalación, así que el recargo en precio para un HSM basado en redes no es justificable. Ahora bien, si una organización planea implementar dos o más CA, puede resultar considerablemente más barato adquirir un único HSM basado en redes y compartirlo entre las CA. Este enfoque también facilita la administración de símbolos, ya que el mismo conjunto de símbolos puede proteger todo el almacenamiento de claves.

Active Directory e inscripción
Una de las principales ventajas de una solución PKI basada en Windows es que el suministro de certificados se realiza sin necesidad de instalar software adicional en las entidades que participan en la PKI. En lugar de eso, la mayor parte del suministro de certificados se puede administrar autónomamente y sin que lo advierta el usuario final a través de una combinación de la inscripción automática y directivas de grupo. LSU usa esta tecnología para distribuir automáticamente certificados de equipo a equipos que son miembros de su Active Directory. Además, usamos un sitio Web personalizado para proporcionar funciones de solicitud de certificados de autoservicio para hosts que no sean de Windows.
Como mencionamos anteriormente, el programa OmniRoot distingue entre los certificados de uso público y los certificados de uso interno. Los certificados se consideran públicos si son usados por sistemas y usuarios que no forman parte de la organización de LSU (por ejemplo, cuando un posible estudiante envía un formulario de admisión a través de un sitio Web protegido por SSL). Los certificados usados dentro de la organización de LSU (como los que se usan para cifrar datos en los servidores de LSU) se consideran internos.
Dado que el costo del programa OmniRoot se basa en el número de certificados orientados al público, necesitamos poder hacer un seguimiento del número de certificados públicos que se envían y a quién se envían. De este modo, en cualquier certificado cuyo fin sea público, el nombre distintivo de la plantilla empieza por "PublicCertificate" y el nombre para mostrar empieza por "Public Certificate". Por ejemplo, la plantilla de certificado TLS de LSU orientada al público se basa en la plantilla de Windows Web Server predeterminada y se denomina Public Certificate LSU Web Server (servidor Web de LSU de certificados públicos). Para los servidores Web que se usan internamente, tenemos una segunda plantilla denominada Internal Certificate LSU Web Server (servidor Web de LSU de certificados internos). Técnicamente, las dos plantillas son idénticas; las diferencias de nombre sólo sirven para facilitar la contabilidad.
En el caso de que sea necesario realizar inscripciones masivas, como por ejemplo, la inscripción de departamentos enteros para la obtención de certificados que se puedan usar con IPSec, se usa la inscripción automática. Se trata de una herramienta sencilla y muy eficaz incorporada en Windows. Desde el punto de vista de un administrador de PKI, la única acción necesaria consiste en cambiar la lista de control de acceso de la plantilla para otorgar a cualquier grupo de usuarios o equipos que necesitan certificados el derecho de inscribirse automáticamente. A continuación, estas entidades podrán comprobar automáticamente Active Directory, enumerar las plantillas a las que tienen acceso de inscripción automática, buscar las CA con esas plantillas e inscribirse automáticamente para obtener certificados. Además, la característica de la inscripción automática garantiza la sustitución de los certificados si se sustituye una plantilla y se renueva automáticamente antes de que caduque.
Cuando no se trate de una inscripción masiva, como el suministro de certificados a los servidores Web, usamos un sitio Web de autoservicio que permite a los usuarios solicitar certificados a través de un explorador Web. Este sitio es una versión personalizada de las páginas de inscripción Web que se entregan con Windows Server 2003 (el directorio virtual /certsrv); nuestra implementación incluye la aplicación de marcas Web estándar de LSU y completa de forma previa las entadas predeterminadas correctas en la página de solicitud. Además, usamos el módulo de salida predeterminada del servicio CA de Windows para enviar un mensaje por correo electrónico automáticamente a nuestro equipo de administración de PKI cuando una solicitud enviada a través de este sitio requiere aprobación.

Diseño de revocación
Todos los certificados tienen un período de validez. De vez en cuando, LSU tiene que invalidar algunos certificados antes de que finalice su período de validez (por ejemplo, si se da a un empleado un certificado con un período de validez que caduca en mayo de 2007, pero ese empleado deja LSU en enero de 2007). Este tipo de revocación se lleva a cabo con CRL, que son archivos que contienen una lista de números de serie de certificados firmados por una CA. Los números de serie incluidos en una CRL hacen referencia a certificados cuyo período de validez no ha caducado, pero en los que LSU ya no confía. Los clientes pueden descargar esta CRL y comprobarla para determinar la validez de los certificados.
Todos los certificados x.509 v3 (excepto el mismo certificado CA raíz) deben tener un puntero hacia una CRL válida. Este puntero se conoce como punto de distribución CRL o CDP. El punto de distribución CRL se incluye en el mismo certificado (consulte la figura 4) y no se puede modificar una vez emitido un certificado. La CRL es fundamental a la hora de garantizar que los certificados de una CA son válidos. Por lo tanto, nos aseguramos de que las CRL de LSU sean físicamente redundantes, altamente disponibles y que las organizaciones externas pueden tener acceso a ellas.
Figura 4 Punto de distribución CRL de LSU
Figura 4 Punto de distribución CRL de LSU (Hacer clic en la imagen para reducirla)
Figura 4 Punto de distribución CRL de LSU
Figura 4 Punto de distribución CRL de LSU (Hacer clic en la imagen para ampliarla)
Una CA basada en Windows Server que esté integrada en Active Directory (como la de LSU) publica automáticamente su CRL en Active Directory con lo que hace que sea accesible a través del Protocolo ligero de acceso a directorios (LDAP). La ubicación de publicación predeterminada es el contenedor CDP (consulte la figura 5) que se encuentra dentro del contenedor de servicios de claves públicas del bosque. Esta ubicación de publicación es una opción excelente, ya que proporciona la creación de réplicas automática, tolerancia a errores y una ubicación para las búsquedas de CDP.
Figura 5 El contenedor CDP
Figura 5 El contenedor CDP (Hacer clic en la imagen para reducirla)
Figura 5 El contenedor CDP
Figura 5 El contenedor CDP (Hacer clic en la imagen para ampliarla)
No obstante, en el diseño de LSU hay muchos equipos que no tienen Windows ni Active Directory pero que emplean la PKI. Y aunque LSU es una gran organización, la gran mayoría de los usuarios se encuentran en la misma red del campus universitario (con una red troncal de 10 Gbps), lo que minimiza las ventajas de la publicación de CDP basada en Active Directory.
Por consiguiente, sólo publicamos nuestra CRL en una ruta de acceso HTTP, lo que facilita la creación de una plataforma de alojamiento redundante (nuestro sitio Web principal ya está reflejado). Esto también elimina las posibles complicaciones asociadas a la habilitación de búsquedas LDAP de cliente. Publicamos nuestra CRL diariamente y las CRL delta cada hora.

Futuros desarrollos
Mientras nuestra PKI proporciona una robusta solución de seguridad para la comunidad universitaria, planeamos la mejora de sus posibilidades. Windows Vista™ y la siguiente versión de Windows Server (cuyo nombre de código es "Longhorn") proporcionarán numerosas posibilidades de administración de claves nuevas que planeamos investigar. Estamos particularmente interesados en el cliente OCSP (Certificate Status Protocol) planeado y en las posibilidades de respondendor, en la compatibilidad con la criptografía de curva elíptica y los algoritmos SHA-256, así como en una interfaz de inscripción automática mucho más mejorada. Asimismo, está programado que Windows XP Service Pack 3 incluya una característica conocida como movilidad de credenciales, que proporcionará una movilidad segura a los pares de claves sin la sobrecarga asociada a los perfiles móviles. Finalmente, estamos investigando el uso del Certificate Lifecycle Manager (actualmente está disponible en beta) a fin de mejorar nuestras capacidades de administración y generación de informes.
En resumen, la PKI de LSU proporciona a la universidad un servicio de seguridad base que se usa para muchas funciones de TI fundamentales. Con el servicio OmniRoot de Cybertrust podemos ejecutar una PKI que esté bien integrada con otros sistemas de TI de LSU, pero cuya confiabilidad se extienda globalmente. Asimismo, mediante la integración de la solución en el servicio CA de Windows, contamos con eficaces capacidades de administración y suministro de certificados, así como una excelente integración con nuestro sistema de administración de identidades y directorio existentes. En resumen, la visión de PKI basada en una sólida seguridad y una confianza perfecta ya está convirtiéndose en realidad en LSU.

John Morello se graduó Summa Cum Laude en la universidad estatal de Louisiana y trabajó seis años en Microsoft como consultor senior en los Servicios de consultoría de Microsoft. Durante el tiempo que estuvo en MCS, creó varias PKI para clientes estratégicos como Deloitte, GE y varias organizaciones federales. Actualmente actúa como jefe de seguridad de la información (CISO) en la universidad estatal de Louisiana.


 Archivos del escritorio: Dentro del formato de im&#225;genes de Windows
Archivos del escritorio
Dentro del formato de imágenes de Windows
Wes Miller
Esta columna se basa en versiones preliminares de las herramientas de implementación de Windows. Toda la información que aquí se menciona está sujeta a cambios.

La versión de Windows Vista supone un cambio significativo en el modo de instalación e implementación de Windows. El motor de configuración y todo el conjunto de herramientas de implementación para Windows Vista (así como la próxima versión de Windows Server, denominada "Longhorn") se han escrito de nuevo. Comenté estos cambios y el trabajo que
el equipo de implementación de Windows® destinó a la aplicación de estos cambios en recientes artículos de la revista TechNet Magazine. Pero queda mucho por decir sobre este tema, por lo que en esta nueva columna periódica hablaré sobre Windows PE, la instalación e implementación de Windows y otros temas de seguridad y administración de Windows.
En esta primera entrega, hablaré sobre el nuevo formato de imágenes de Windows (WIM). Si todavía no está familiarizado con los detalles de la creación de imágenes, consulte la barra lateral "Proceso típico de implementación de imágenes" para obtener una descripción general. En la columna siguiente, comentaré el kit de instalación automatizada de Windows, un nuevo conjunto de herramientas que incluye ImageX (la herramienta de línea de comandos que se usa para crear y manipular imágenes WIM) y los servicios de implementación de Windows (WDS), que sustituyen a los servicios de instalación remota (RIS), y explicaré cómo estas herramientas facilitan la implementación de sistemas operativos.

Punto de inflexión
Año tras año, el equipo de implementación de Windows escucha los mismos comentarios de los clientes de empresa y de OEM. Desean un soporte mejor para la implementación de imágenes y que Microsoft proporcione herramientas de imágenes unificadas. Estos usuarios no están dispuestos a seleccionar otro proveedor y aprender las características de su producto. Además, los clientes de empresa y de OEM se quejan con frecuencia de que no tendrían que pagar las herramientas de imágenes que se usan para implementar Windows, sino que Microsoft debería proporcionar estas herramientas.
Al empezar a desarrollar Windows Vista™, el equipo de implementación de Windows se la jugó. Decidimos descartar completamente el motor de configuración en su totalidad (muchos de sus componentes existen desde hace casi una década). La configuración siempre había sido frágil y tenía demasiados pasos. Queríamos acelerar el proceso, eliminar los pasos innecesarios y mejorar la confiabilidad de la configuración general de Windows. Para ello, cambiamos todo el proceso de configuración del motor hecho a mano que usamos durante un tiempo y los sustituimos por un proceso de configuración basado íntegramente en imágenes.

Diseño de un nuevo formato de imágenes
Al principio del proceso del nuevo diseño, nos pusimos de acuerdo para definir el tipo de imagen que debíamos usar. El argumento clásico era sector frente a archivo. Es decir, ¿debemos usar un formato de imagen que almacene una copia de un volumen como un duplicado sector por sector o una que almacene todos los archivos individualmente? La mayoría de la gente prefiere la velocidad (enfoque de sector) a la compresión (enfoque basado en archivos). Finalmente, nos decidimos por un formato que supone, desde mi punto de vista, un gran compromiso entre las dos propuestas. Su rendimiento es excelente, y también permite una buena compresión.
Para empezar, definimos varios objetivos clave necesarios para crear un formato de imagen que satisficiese las exigencias de los usuarios de la empresa y de OEM. Nuestra lista se inclinaba marcadamente hacia una arquitectura basada en archivos. Todos advertimos las ventajas de este enfoque y, por lo tanto, empezamos a trabajar en esa dirección. Los archivos WIM no tardaron en aparecer. (Y, por si se lo están preguntando, la "M" de WIM no es la inicial de ninguna palabra. Le pusimos WIM por los eventos del equipo de Windows que se repiten cerca de los objetivos de envío; y *.WI parecía una abreviatura extraña.) Veamos el conjunto de objetivos que nos propusimos para el nuevo formato de imagen.
Formato neutral del sistema de archivos de Windows El formato de imagen tenía que funcionar en las dos arquitecturas del sistema de archivos que Windows admite. La mayoría de los sistemas usan NTFS al ejecutarse, pero también hay muchos OEM y empresas que usan sistemas de archivos FAT como recurso provisional para poder usar MS-DOS® para implementar Windows. A continuación, se pasan a NTFS. Nos hemos visto obligados a admitir este formato para Windows Vista.
Geometría de volumen neutral Hemos tenido que superar el problema histórico de capturar grandes volúmenes y aplicarlo a un volumen más pequeño. Aunque la herramienta de imágenes puede superar estos trucos de manipulación a través de una partición, es poco confiable. En una arquitectura basada en archivos, la imagen sólo ocupa el espacio que ocupan los archivos que la conforman. Dado que el sistema de archivos se restaura de forma independiente, no depende del volumen.
Proceso típico de implementación de imágenes
Cuando un OEM duplica grandes cantidades de sistemas o una empresa grande necesita desplegar Windows en muchas máquinas, normalmente, usan la tecnología de implementación de imágenes. La premisa consiste en tomar el sistema host, crearlo tal y como se desee y, a continuación, duplicarlo en los sistemas de destino. Si no está familiarizado con el proceso de implementación de imágenes, a continuación se proporciona una breve descripción general.
  1. El administrador instala Windows en un sistema y lo configura como desee. Esto implica la adición y eliminación de componentes, la instalación de aplicaciones usadas con frecuencia y el ajuste de la interfaz de usuario y otros valores. Llamémoslo el sistema host.
  2. Entonces, el administrador ejecuta Sysprep (suministrado por Microsoft en forma de herramientas de implementación de Windows), que se encarga de borrar los atributos que hacen una instalación de Windows única (por ejemplo, el nombre del equipo, el SID [identificador de seguridad de Windows] y otros identificadores únicos del sistema). Estos atributos se restablecen cuando se ejecuta la segunda parte de Sysprep.
  3. A continuación, el administrador cierra el equipo y lo reinicia en Windows PE, MS-DOS u otro sistema operativo que le permita ejecutar la aplicación de implementación de imágenes.
  4. Ahora, el administrador ejecuta la herramienta de implementación de imágenes y crea una imagen para el sistema de referencia. Esta imagen es un archivo (o colección de archivos) que contiene una réplica exacta de la partición o el disco de referencia.
  5. El sistema se cierra y el administrador archiva la imagen, que se puede actualizar (agregando aplicaciones, revisiones y service packs) según sea necesario.
  6. La imagen se replica en uno o más equipos y Sysprep termina su trabajo con la ejecución de una versión abreviada de instalación (llamada instalación mínima o inicio de Windows, en función de la versión de Windows en la que esté ejecutando Sysprep y cómo esté configurado Sysprep). Esta etapa depende de un pequeño ejecutable en modo nativo denominado setupcl.exe.

Arquitectura neutral del sistema La arquitectura de imagen tenía que ser compatible con todas las arquitecturas que admitiese Windows. En ese momento, esto significaba las dispares arquitecturas x86 e IA64 (Intel Itanium). Hoy en día, también incluye las arquitecturas x64 (AMD64 y EM64T).
Debe ser rápida de capturar y aplicar La imagen tenía que poder capturarse con cierta rapidez, dada la compresión. Pero, todavía más importante, la aplicación de la imagen tenía que ser muy rápida.
Compatible con la aplicación de imágenes no destructiva Dado que íbamos a sustituir la opción de actualización (que sustituye Windows sin dañar los datos ni las aplicaciones del usuario) y a derivar una herramienta que se pudiese usar para la recuperación del sistema, deseábamos que pudiese implantar la imagen de un sistema sin destruir todo lo que ya está en el volumen. Los formatos basados en sectores, sin mucho trabajo, no permiten al usuario hacer esto. Por lo general, o se restaura todo el sistema o no se restaura nada.
Compatible con una compresión significativa Cuando se empezó a desarrollar Windows Vista, todavía nos centrábamos en la entrega en CD. Teniendo en cuenta que una imagen de Windows XP ocupa casi 1 GB, decidimos que era importante comprimir la imagen lo máximo posible. Existen varios trucos para hacerlo con una imagen basada en sectores, pero las partes móviles de esta implementación nos preocupaban. Muchos formatos basados en sectores omiten los espacios en blanco del disco para ahorrar espacio. (¿Por qué grabar un 0 en una imagen si se trata siempre de un 0?) Sin embargo, mediante un enfoque basado en archivos, pudimos controlarlo de manera inherente, ya que no estábamos tomando los espacios en blanco.
Compatible con la instancia única de archivos Este punto es igual al tema anterior. Se sabe que Windows almacena varias copias del mismo archivo en unas cuantas ubicaciones diferentes. El enfoque basado en archivos facilitó el almacenamiento de una sola instancia de cada archivo y el uso necesario del archivo.
Compatible con la combinación de soportes (disco) Ya desde los primeros días de WIM, cuando podíamos grabar una imagen en un solo CD, supimos que debía ser compatible con varios tipos de soportes. Aunque entregásemos Windows en un CD, una vez que los usuarios agregasen aplicaciones, service packs y demás, sus imágenes superarían el tamaño de un solo CD o DVD. De manera que tuvimos que permitir su almacenamiento en varios soportes para las soluciones de instalación y recuperación.
Compatible con varias imágenes de volumen en un blob de archivos No es frecuente que una imagen funcione para todo. Cuando diseñamos la "instancia única", incluimos la capacidad de seleccionar más de un volumen, de manera que la misma compresión e instancia única funcionen en todos. Así, si selecciona una imagen de Windows XP Professional y, a continuación, agrega una imagen nueva de Windows XP Tablet PC Edition (un superconjunto de Windows XP Professional), sólo se agregarán a la imagen los archivos que son diferentes explícitamente entre las dos versiones.
Como consecuencia, un OEM o un usuario de empresa puede agregar muchas imágenes derivadas sin que suponga un aumento exponencial en su tamaño. Esta capacidad hubiese sido difícil de conseguir con un formato basado en sectores.

Funcionamiento de WIM
El formato WIM se diseñó para que fuese lo más simple posible, cumpliendo siempre nuestros principios fundamentales. El enfoque basado en archivos nos permitió hacer esto. ¿Cómo funciona exactamente?
En pocas palabras, un archivo WIM es como un archivo CAB (un formato similar al ZIP, pero diseñado por Microsoft, propietario del formato CAB). De hecho, una vez oí cómo se hacía referencia a WIM como "hijo de CAB." La diferencia principal entre un archivo WIM y un archivo CAB es que, además de capturar y comprimir el archivo, una imagen WIM almacena metadatos que aplica a los archivos y directorios que componen el volumen capturado en una imagen de volumen dada. Es como un archivo de almacenamiento con toda la metainformación necesaria para restaurar el volumen a su estado cuando se creó la imagen: listas de control de acceso (ACL), nombres de archivo cortos y largos, atributos, etc.
Tenga en cuenta que, en ningún momento durante el proceso de captura se reúne información de la partición (tamaño o tipo). Ni el proceso de aplicación particiona el sistema. A diferencia de la mayoría de las herramientas de implementación de imágenes, ImageX, que es de partición neutra, requiere que la partición se cree y formatee antes de la aplicación. Para automatizar el proceso antes de aplicar la imagen, debe usar las herramientas Diskpart y línea de comandos de formato.
El almacenamiento en una imagen de volumen no tiene límites. Una imagen puede contener dos volúmenes, el mismo volumen capturado un martes y un jueves, una imagen con un service pack y otra con ninguno u otros volúmenes que satisfagan sus necesidades. Lo más importante es comprender que los archivos idénticos sólo se capturarán una vez. Cuanto menos tengan en común dos imágenes de volumen, más espacio ocuparán.
También deseo señalar que nada en el diseño del formato WIM impide su uso con versiones anteriores de Windows. Funcionará tan bien con Windows 2000 como con Windows Vista. Ahora, veamos qué sucede exactamente cuando se capturan y aplican las imágenes.

Captura de una imagen
Cuando se captura la imagen de un volumen, se suceden los pasos siguientes:
Se capturan metadatos de volumen. ImageX recopila datos sobre nombres de archivo, listas de control de acceso de NTFS u otros atributos del sistema de archivos del volumen. (Tiene la opción de excluir determinados archivos con un archivo de secuencia de comandos.)
Se capturan los datos de archivo. ImageX carga el archivo. Los archivos se cargan en el volumen y se preparan para recopilar determinados datos sobre éstos.
Se genera el hash del archivo. Se genera un hash criptográfico del archivo basado en el propio archivo. Este hash se convierte en el identificador único de los archivos de la imagen.
Se buscan y se eliminan los duplicados. Si ya existe otro archivo con el mismo hash en la imagen, se supone que se trata del mismo archivo y se hace referencia al nuevo archivo apuntando al archivo existente.
Se comprimen los datos únicos del archivo. A diferencia del formato CAB u otros formatos de almacenamiento, los archivos de un archivo WIM se comprimen individualmente, en lugar de como una colección de archivos agrupados en un flujo de datos. También puede decidir no realizar la compresión, en cuyo caso este paso se omite.
Se comprimen y almacenan los metadatos de volumen. Una vez que se han almacenado todos los archivos, se crea una entrada de metadatos para el volumen. En esta entrada se enumeran todos los archivos que se agregaron a la imagen para el volumen.
Se generan y almacenan los datos XML de imagen. Esta es una referencia para cada imagen de volumen capturada. Si ejecuta ImageX /info, por ejemplo, obtendrá datos XML.
Se graba el índice de datos WIM en caché. Por último, se graba el índice de datos maestro (junto con los datos en caché). Esta es la tabla de archivos maestro para todo el WIM; incluye una entrada por hash.
Como se puede apreciar, WIM se crea archivo por archivo. Además, tendrá un archivo WIM, independientemente del número de volúmenes que agregue a la imagen.

Sobrecarga de imágenes
Cuando empezamos a trabajar en WIM, existían varios equipos desarrollando soluciones similares. El equipo de los servicios de implementación automatizados estaba desarrollando una solución de imagen para otro segmento de clientes. Su enfoque tenía detalles sobre la implementación de bajo nivel muy interesantes, pero su motor de imágenes se basaba en sectores, como la mayoría en aquel momento. El equipo de Windows XP Embedded también creó un motor de imágenes basado en sectores para permitir a los proveedores de hardware independientes incrustados (IHV) implementar su propias imágenes durante la fabricación del sistema. Y, cuando Microsoft adquirió el equipo de Virtual PC en 2003, incorporó otro formato de archivo para archivos VHD (disco duro virtual).
Todos estos formatos se basaban en sectores. Satisfacían las necesidades de su segmento de clientes, pero no eran acordes a nuestras directrices para WIM. Por lo tanto, seguimos trabajando en la creación del nuevo formato WIM y la herramienta de línea de comandos ImageX para capturar imágenes. Finalmente, varios equipos adoptaron nuestro formato antes de que formase parte, públicamente, de la versión beta de Windows Vista. El equipo de SMS, por ejemplo, suministró una primera implementación de WIM en Operating System Deployment Feature Pack.

Aplicación de una imagen
Ahora, veamos el proceso del contador: aplicar una imagen
Se carga el índice de datos WIM en caché. Esta acción se correlaciona con el último paso del procedimiento anterior. Puesto que se trata del índice maestro, es el primer elemento que se debe cargar del WIM después de especificar la imagen de volumen que se desea aplicar.
Se recuperan y se cargan los metadatos de la imagen. ImageX carga los metadatos específicos de cada imagen de volumen.
Se crea la estructura de directorios. Para garantizar que cada archivo tiene una ubicación de restauración, se crea todo el árbol de directorios del volumen.
Se extraen los datos de archivo. Los archivos se extraen del WIM en el mismo orden secuencial en que se almacenaron.
Se aplican los datos de archivo. En este paso, los archivos se cargan, se descomprimen (si la imagen de volumen estaba comprimida en el WIM) y se copian en todas las ubicaciones a las que se haga referencia. Por último, se aplican todos los metadatos de cada archivo.
Se aplican todos los metadatos de directorio. Es importante que éste sea el último paso, ya que es posible que la ACL de un directorio impida que la imagen se aplique correctamente.

Compresión flexible
Uno de nuestros principales objetivos para el formato de imágenes WIM era proporcionar opciones de compresión flexibles. Por este motivo, incorporamos la capacidad de capturar una imagen de volumen con compresión cuando fuese necesario, además de permitir la captura de una imagen sin compresión. Esta última opción es adecuada para casos en que la imagen no necesita una gran compresión o cuando es necesaria una captura muy rápida.
En cuanto a la compresión, deben tenerse en mente cuatro principios clave. La compresión siempre es más lenta que la descompresión. Cuanto más agresivo sea el algoritmo de compresión, más tardará en comprimir un conjunto de datos determinado. Y, cuantos más datos se proporcionen a un algoritmo de compresión, mejor será la compresión.
Las imágenes WIM se pueden comprimir con compresión XPress o LZX. Por supuesto, también existe la opción de no realizar ninguna compresión. XPress es una buena opción cuando es necesario algún tipo de compresión pero no se desea dedicar demasiado tiempo al proceso de captura. LZX proporciona una tasa de compresión óptima, pero, como se puede imaginar, tarda bastante más en realizarla.
Si no se usa ningún tipo de compresión, la captura de imagen es más rápida, pero también se obtiene una imagen mayor. El tipo de compresión es una opción que se establece por WIM. Una vez que se ha capturado una imagen de volumen en un WIM, todas las imágenes de volumen posteriores deben capturarse con el mismo valor de compresión.
Recuerde que, dado que las imágenes WIM se comprimen archivo por archivo, la compresión no es todo lo completa que podría ser. Lo hicimos a propósito, porque de este modo editar la imagen sería más fácil. La capacidad de editar imágenes tras la captura es una opción importante. Para editar un archivo después de haber capturado la imagen, deben sustituirse los datos de archivo y sus metadatos. Si hubiésemos comprimido todo el WIM a la vez, la compatibilidad para la edición de archivos hubiese sido mucho más difícil de diseñar (en el caso de que fuese posible) y la sustitución de un archivo de la imagen tardaría mucho tiempo. Con este compromiso, conseguimos un formato con una buena compresión y que se puede editar con nuestras herramientas.
Espero haberles ayudado a comprender cómo funcionan las capacidades de implementación de imágenes que diseñamos para Windows Vista. En la siguiente columna, hablaré sobre algunas de las herramientas que se pueden usar para administrar e implementar imágenes WIM y profundizaré en ImageX y los Servicios de implementación de Windows.

Wes Miller es Director de desarrollo de Pluck (www.pluck.com) en Austin, Texas. Anteriormente, Wes trabajó en Winternals Software en Austin y en Microsoft como administrador de programas y administrador de producto para Windows. Puede ponerse en contacto con Wes en la dirección technet@getwired.com. Wes desea agradecer la ayuda que John Macintyre, el actual administrador del programa WIM/ImageX de Microsoft, para elaborar esta columna.


 Confidencial de Windows: A la espera de RunOnce
Confidencial de Windows
A la espera de RunOnce
Raymond Chen

CONSIDERE UNA instalación que necesita reiniciar el sistema en el medio del proceso. Por ejemplo, es posible que el programa desee actualizar un archivo DLL del sistema que está en uso. Deberá activar un reinicio intermedio para poder instalar el nuevo archivo DLL y, a continuación, una vez que éste se haya actualizado, podrá usarlo en la próxima etapa de la instalación.
La clave RunOnce se diseñó para este tipo de situación; para que los programas de instalación la usen para finalizar su instalación tras un reinicio intermedio. (Esto era en la época en la que se confiaba en que los programas no producirían errores.)
El explorador de Windows® espera a que el programa RunOnce se ejecute hasta el final antes de crear el escritorio y la barra de tareas. Esto se debe a que RunOnce funciona bajo el principio de que está destinado a los programas de instalación. El programa RunOnce podría estar modificando los datos de configuración del sistema y no se desea que un usuario use el sistema durante la reconfiguración.
Por ejemplo, supongamos que el programa RunOnce está reorganizando y uniendo los archivos que acaba de instalar y algunos de ellos forman parte de la extensión de un shell. Evidentemente, no es deseable que el usuario intente ejecutar el programa o activar la extensión mientras que su archivo ejecutable se está actualizando.
Otra desventaja del principio "diseñado para programas de instalación" es que la clave RunOnce sólo se procesa si inicia sesión un usuario con privilegios de administrador. Por lo tanto, los usuarios que no son administradores no podrán finalizar la instalación. Además, si se ejecutase la clave RunOnce para usuarios que no sean administradores, ya no sería de tipo "ejecutar una vez" (run once). De hecho, crearía un importante problema. ¿Cómo podría decir "Bueno, esa ya la ejecuté, no hay que ejecutarla de nuevo"? Para cambiar este estado global del sistema, necesitaría privilegios de administrador. Y, evidentemente, el usuario que no sea administrador no dispone de dichos privilegios. El programa dejará de ser de tipo "ejecutar una vez". En cambio, será de tipo "ejecutar repetidamente hasta que inicie sesión el administrador".

(Hacer clic en la imagen para reducirla)

(Hacer clic en la imagen para ampliarla)
RunOnce, diseñado para finalizar la instalación del programa, es visible en la misma instalación de Windows. Cuando intente instalar un service pack o actualizar a una versión más reciente de Windows, el asistente para la instalación comprobará la clave RunOnce. Si no está vacía, recibirá un mensaje de error que indica que aún hay procesos del programa instalación en curso. Finalice dichos procesos antes de intentar actualizar el sistema operativo. Esto es lógico, ya que no sería deseable modificar el sistema operativo en el medio de la instalación de un programa.
Todo el diseño de RunOnce revela su pasado. Se concibió en Windows 95, un sistema operativo que no distinguía entre administradores y no administradores. Puesto que, en principio, todos los usuarios eran administradores en Windows 95, un programa de instalación que usaba RunOnce podía estar seguro de que las acciones RunOnce se realizaban tras el próximo reinicio.
En los sistemas operativos de Windows más recientes, y esto es particularmente cierto en Windows Vista™, es posible que ningún usuario con privilegios de administrador inicie sesión durante meses. Por consiguiente, un programa que requiere la ejecución de RunOnce podría tener una larga espera por delante.
Por otro lado, he observado un proceso de RunOnce perpetuo. Se volvía a agregar a sí mismo a la clave de RunOnce cada vez que se ejecutaba. Claramente, esto va en contra de la intención de la clave de RunOnce, puesto que ya no forma parte de la instalación del programa, sino del funcionamiento normal del programa. Además, este comportamiento hace que la instalación de Windows siempre informe de que hay una instalación en curso.
Por consiguiente, el usuario nunca puede actualizar el sistema operativo, ya que este programa persistente siempre indica que debe realizar una cosa más antes de finalizar. El programa no finalizará la instalación hoy, pero seguramente lo hará mañana. Es como estar a la espera de Godot, pero sin la crisis existencialista.

Raymond Chen, The Old New Thing, trata de la historia de Windows y la programación Win32. Actualmente trabaja en un libro, que casualmente también se titula The Old New Thing (Addison-Wesley, 2007).