 TechNet Magazine July 2007

TechNet Magazine July 2007

Comunicaciones: Protección de datos y recuperación ante desastres para Exchange Server 2007

Exchange Server 2007 incluye una gama de opciones para admitir una alta disponibilidad y recuperación ante desastres. Explore las alternativas que ofrece Exchange y planee la solución ideal de recuperación para su organización.

Lee Benjamin Comunicaciones: Mejora de la seguridad con Windows Mobile 6

Si bien los Smartphone y los PDA ofrecen acceso a la red desde fuera de la oficina, también pueden dejar la red expuesta a nuevas vulnerabilidades. Aquí está una guía sobre cómo Windows Mobile 6 y Exchange Server pueden ayudar a proteger los dispositivos móviles de la compañía y la infraestructura.

Matt Fontaine Comunicaciones: Una alternativa eficaz a las carpetas públicas

MOSS 2007 proporciona una solución mucho más eficaz para compartir datos que las carpetas públicas de Exchange, ofreciendo capacidades mejoradas y una administración más sencilla. Observe cómo se puede usar SharePoint para compartir calendarios, contactos y documentos.

Alan Maddison Comunicaciones: Inicie una sesión en Outlook Web Access con tarjetas inteligentes

Uno de los vínculos más vulnerables en la cadena de seguridad tiene que ver con las contraseñas deficientes, que se ponen fácilmente en peligro. Obtenga información sobre cómo puede mejorar la seguridad del correo electrónico al implementar la autenticación en dos fases mediante tarjeta inteligente para los usuarios móviles.

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Administración de Windows: Servicio del instalador de ActiveX en Windows Vista

¿Cómo se protege el escritorio contra controles ActiveX malintencionados sin limitar la compatibilidad de las aplicaciones? Le guiaremos en una visita del Servicio del instalador de ActiveX (AxIS) de Windows Vista que trata este problema con una nueva manera de administrar controles ActiveX.

Rob Campbell and Joel Yoker Nota del editor: Seis grados

Joshua Trupin Caja de herramientas: Nuevos productos para profesionales de TI

Greg Steen Preguntas y respuestas sobre SQL&: Estudio de clúster, bloqueos misteriosos, la cuenta de SA, etc.

Edited by Nancy Michell Noticias destacadas sobre utilidades: SMSMap

Jeff Tondt Funcionamiento: Solución de problemas de errores de RPC

Zubair Alexander The Cable Guy: Tráfico IPv6 sobre conexiones VPN

Joseph Davies Windows PowerShell: Replanteamiento de la canalización

Don Jones ¡Hola, encargados de las secuencias de comandos!: En los scripts, como en la vida, las apariencias son importantes

The Microsoft Scripting Guys Preguntas y respuestas sobre Exchange: Funciones de transporte de Hub y Edge, máquinas virtuales, etc.

KC Lemson and Nino Bilic Vigilancia de seguridad: Herramientas para administrar ACL

Jesper M. Johansson Archivos del escritorio: Paquete de optimización de escritorio de Microsoft

Wes Miller Confidencial de Windows: Poderes curativos del modo seguro

Raymond Chen


 Comunicaciones: Protecci&#243;n de datos y recuperaci&#243;n ante desastres para Exchange Server 2007
Comunicaciones Lee Benjamin

Protección de datos y recuperación ante desastres para Exchange Server 2007
Resumen:
  • Copia de seguridad y restauración básicas
  • Continuidad de datos
  • Tecnologías de réplica
  • Soluciones alternativas

Microsoft Exchange Server fue diseñado con la realización de copias de seguridad en mente. Las organizaciones necesitan realizar copias de seguridad de sus datos de mensajería, y deben también poder restaurar esa información. Para satisfacer estas necesidades, Microsoft construyó una variedad completa de opciones de protección de datos, desde las
tradicionales operaciones de copia de seguridad y restauración como soluciones básicas, a la continuidad operativa, pasando por verdaderas soluciones de continuidad de negocio que ofrecen los niveles más altos de disponibilidad y recuperación ante desastres. En este artículo, examino esas opciones y le ayudo a decidir cómo implementar la mejor solución de recuperación de Exchange para su organización.

NIVEL 1: COPIA DE SEGURIDAD Y RESTAURACIÓN BÁSICAS
Puede realizar copias de seguridad de archivos de Exchange si desconecta sus bases de datos, pero también puede realizar copias de seguridad mientras Exchange se ejecuta. De hecho, la manera recomendada de realizar copias de seguridad de Exchange, con frecuencia es la última. Pero Exchange es más que un conjunto de archivos. Es un almacén de información con archivos de base de datos y registros de transacciones de gran tamaño. Los mensajes enviados a Exchange se registran inmediatamente en los registros de transacciones y cuando el sistema tiene algunos ciclos de reserva (generalmente sólo unos pocos milisegundos más tarde), los mensajes se copian en la misma base de datos. Al obtener la información en el disco lo más rápido posible, Exchange ofrece un muy alto nivel de capacidad de recuperación. Lo fundamental para restaurar Exchange es la disponibilidad de ambos conjuntos de información. Si el sistema falla, la combinación de una copia de seguridad previa, junto con la totalidad de transacciones a partir de ese punto, le permite restaurar Exchange con la información más reciente. Observe que Exchange reproduce automáticamente las transacciones en una base de datos restaurada según sea necesario.
El modo en que los programas de copia de seguridad tienen acceso a información en la base de datos de Exchange es a través de la API de copia de seguridad del Motor extensible de almacenamiento (ESE) o de soluciones de VSS más nuevas que trataré más adelante. Siempre que se inicia una copia de seguridad de ESE, Exchange suspende temporalmente todas las escrituras a sus bases de datos. Al mismo tiempo, ESE establece temporalmente la base de datos en modo de sólo lectura para que se pueda copiar en una copia de seguridad completa, y también usa una base de datos temporal para guardar las nuevas transacciones que tienen lugar durante la copia de seguridad. Cuando se completa la copia de seguridad, ESE devuelve la base de datos a su modo normal de lectura/escritura y aplica las transacciones acumuladas en su base de datos temporal. La copia de seguridad también purga los antiguos registros de transacciones cuando el proceso finaliza de manera correcta.
Aunque este proceso de copia de seguridad es sencillo y transparente, incluso para los usuarios que inician sesión por la noche mientras el proceso se encuentra en ejecución, ESE puede tardar mucho tiempo en completarse, especialmente porque las bases de datos de Exchange pueden variar en cualquier tamaño, desde pocos gigabytes, a unos administrables 30 a 50, o incluso hasta 100 GB (cuya copia de seguridad se hace casi imposible en una noche con tecnologías estándar). Para hacerse una idea de las opciones disponibles al usar NTBackup.exe, observe la figura 1.
Figura 1 Uso de la utilidad NTBackup
Figura 1 Uso de la utilidad NTBackup

Prácticas recomendadas para Exchange
Si desea que se pueda realizar una recuperación rápida ante errores comunes de hardware y del sistema, debe ejecutar copias de seguridad completas de Exchange por la noche. Para mejorar el rendimiento y la capacidad de recuperación siempre que un servidor Microsoft Exchange use discos locales, es importante usar matrices RAID separadas para almacenar las bases de datos y los registros de transacciones de Exchange. De esta manera, si se producen errores en el controlador de matriz RAID, o en más de un disco en la matriz de manera que los discos restantes ya no puedan regenerar los datos seccionados, todavía le será posible recuperar. Si pierde los registros de transacciones, todavía tendrá en las otras unidades de disco las bases de datos actualizadas de Exchange, que le permitirán continuar las operaciones normales con nuevos registros de transacciones. Si pierde las unidades de disco con las bases de datos, su estrategia de recuperación será volver a su copia de seguridad completa de las bases de datos de Exchange de la noche anterior y, a continuación, aplicar los registros de transacciones del día para actualizarlas.
Es importante que limite el tamaño de sus bases de datos de Exchange para que en cada una sea posible realizar la copia de seguridad y restaurar (lo que es más importante) en una cantidad de tiempo razonable. En la mayoría de las organizaciones, esto significa mantener el tamaño de las bases de datos entre 30 y 50 GB. Cuando una base de datos crece más allá de ese tamaño, es conveniente dividirla en múltiples bases de datos para que la restauración sea más fácil de administrar.

Copia de seguridad y restauración continuas
La ubicación de las bases de datos y los registros de transacciones es muy importante; no sólo para el rendimiento de la copia de seguridad sino también para la velocidad de recuperación. Hoy en día, todos los servidores admiten distintos niveles de redundancia de unidad de disco, lo que se conoce como RAID. Básicamente, RAID permite que los errores en una unidad no bloqueen el sistema, aunque el rendimiento del sistema será menor hasta que el disco se reemplace y reconstruya. Hasta ese momento, el controlador de matriz debe regenerar los datos de los discos restantes sobre la marcha en respuesta a cada solicitud de acceso al disco. Para obtener más información sobre el diseño de almacenamiento para servidores de correo, consulte la nota técnica de Microsoft IT Showcase "Pasar a 64 bits con Exchange Server 2007".
Una característica principal de Exchange es su diseño de base de datos de instancia única. Esto significa que en el interior de una base de datos de Exchange se almacena una única copia de un mensaje específico junto con un único dato adjunto (si existe). Si el mensaje fue enviado a múltiples recipientes en el mismo almacén de información, se crean punteros adicionales a los objetos (mensaje, datos adjuntos), pero no se duplican los objetos. Esto no sólo significa un enorme beneficio de eficiencia de entrega, sino que además economiza espacio para Exchange, tanto en disco como en cinta.
Aunque Exchange es bueno en recuperar la base de datos completa, cuando es necesario restaurar buzones, carpetas o mensajes individuales, se debe recuperar primero la cinta completa. No es sorprendente que los usuarios desearan capacidades de restauración más específicas. La instancia única en cinta hace que sea muy complicado. Los proveedores de copia de seguridad responden a esta necesidad con la "copia de seguridad de nivel de bloque" (que no recomiendo). Una vez que finaliza una copia de seguridad completa de la base de datos de Exchange mediante la API aprobada de copia de seguridad de ESE, los productos de copia de seguridad agregan a continuación cada buzón a la cinta de copia de seguridad. Debido a que la API de copia de seguridad no ofrece una manera de extraer los datos de buzones individuales, se usa MAPI. Como resultado, la cinta de copia de seguridad es bastante más extensa porque duplica todos esos mensajes y datos adjuntos.
Microsoft ha realizado algunas mejoras que solucionan parcialmente el problema. Por ejemplo, la papelera administrativa (o contenedor) mantiene los elementos del entorno un cierto tiempo después de ser eliminados por los usuarios por si acaso se necesitan. Además, ya no es necesario mantener un servidor de reserva como entorno en un bosque de recuperación de Exchange; los grupos de almacenamiento de recuperación permiten a un administrador montar parcialmente las bases de datos restauradas que se recuperan de la cinta, y copiar o combinar los datos hasta el nivel inferior del buzón.

La práctica hace al maestro
Muchas organizaciones aprenden del modo más difícil que independientemente del nivel de copia de seguridad y recuperación que decidan, los procedimientos para medios de copia de seguridad y recuperación se deben probar con frecuencia. Demasiados administradores conocen si sus procedimientos de copia de seguridad y restauración realmente funcionan sólo después de un desastre. El mejor momento para probar es el día después de generar y configurar el nuevo servidor, cuando está operativo como parte de su organización Exchange, pero sólo tiene algunos usuarios. En ese momento debe realizar una copia de seguridad completa de Exchange y copias de seguridad regulares de sus unidades de disco. También debe capturar el estado de sistema, lo que incluye los archivos críticos en el disco de sistema así como la metabase IIS (donde se mantiene la configuración de enrutamiento de Exchange). A continuación, vuelva a formatear con calma el servidor y comience de nuevo, actualizando las notas que tomó al crear inicialmente el servidor. Debería poder restaurar la configuración a partir del estado de sistema, pero también contar con la documentación adecuada para volver a implementar manualmente los valores de configuración del sistema.
El tiempo que emplea en este simulacro de incendio reducirá apreciablemente su tiempo de recuperación en el futuro. Repita el proceso de manera periódica. Y al mismo tiempo, mida el tiempo que emplea para recuperar datos de las cintas fuera de sitio. Aquellos que se han visto afectados por ese intervalo aparentemente interminable con frecuencia comienzan a pensar seriamente acerca de cómo las copias de seguridad de disco a disco pueden ser una parte importante en su estrategia de copia de seguridad y restauración; incluso si el almacenamiento en cintas fuera de sitio sigue ofreciendo su último respaldo para recuperación ante desastres (DR).

Desafíos de la copia de seguridad en cinta
Restaurar de cinta requiere demasiado tiempo. Exchange es ahora tan crítico para las organizaciones que los usuarios y la administración esperan que siempre esté disponible. Cuando ocurre un problema grave, la mayoría de las organizaciones se encuentran desprevenidas. Nadie está preparado para escuchar que se necesitarán ocho horas para restaurar esa base de datos de 75 GB de cinta; y ello no incluye el tiempo que se dedica para obtener las cintas de la instalación de almacenamiento fuera de sitio o en volver a instalar el sistema operativo.
Además, también existe el desafío de recuperar de cinta la base de datos correcta. En los 10 años desde que Exchange se lanzó por primera vez al mercado, el costo de almacenamiento en discos y redes de área extensa ha caído considerablemente. Como resultado, muchas organizaciones pueden afrontar métodos más rápidos de copia de seguridad y restauración. Es posible que estas organizaciones aprovechen las tecnologías que les permitan obtener continuidad operativa y recuperación ante desastres para su infraestructura de Exchange.

NIVEL 2: CONTINUIDAD OPERATIVA
La continuidad operativa es un conjunto de procesos y tecnologías que pretende hacer que la recuperación sea lo más rápida posible, minimizando tiempos de inactividad inesperados. La continuidad operativa ofrece objetivo de tiempo de recuperación (RTO) y objetivo de punto de recuperación (RPO) sobre cinta para la recuperación local. Se esfuerza por eliminar, donde sea posible, el tiempo que se necesita para recuperar los datos de cinta en el sitio. Observe la figura 2 para comparar la continuidad operativa con copia de seguridad, restauración y la recuperación ante desastres.
Figura 2 Recuperación continua
Figura 2 Recuperación continua
Este diagrama muestra la recuperación y disponibilidad continuas desde lo más lento y económico en la parte inferior izquierda hasta lo más rápido y costoso en la parte superior derecha, con una transición deliberadamente borrosa entre soluciones de continuidad operativa y recuperación ante desastres.
El gráfico le ofrece una idea de los equilibrios entre costos, tiempos de recuperación y disponibilidad entre estos enfoques. En este artículo, distingo claramente de manera intencional entre procesos de continuidad locales y recuperación ante desastres. La recuperación ante desastres siempre se ve como remota, con la obtención de datos fuera de sitio como un objetivo principal. La distancia presenta desafíos adicionales y es típicamente mucho más costosa, pero la recuperación ante desastres se centra en la continuidad del negocio después de eventos catastróficos. Trataré esto con detenimiento más adelante.

Un poco de historia
Cuando Exchange se convirtió en una parte más esencial de la infraestructura y en sus bases de datos comenzó a almacenarse más información, era claro que se debían reducir los tiempos de la copia de seguridad y restauración. Trabajando con Microsoft, algunas organizaciones grandes propusieron un enfoque que ofrecía un resultado con muchas mejoras en las operaciones parciales. Si una organización podía recibir y enviar nuevo correo electrónico al mundo exterior, parecería como si nada hubiera sucedido. Después de todo, las apariencias importan.
Para implementar esta restauración con "señal de marcado" para Exchange, se ponía una nueva base de datos vacía en el lugar de la dañada. Exchange y Active Directory® creaban a continuación nuevos buzones con los permisos apropiados, y los usuarios podrían enviar y recibir correo. Una vez que la cinta de copia de seguridad y los datos se recuperaban, se podrían montar administrativamente. El administrador de Exchange combinaría entonces los buzones restaurados con los buzones con señal de marcado. Se podría establecer la prioridad de los buzones según sea necesario. Aunque representa una mejora, era un proceso complejo que demandaba tiempo, y que originalmente usó EXMERGE. Luego se adaptó a grupos de almacenamiento de recuperación. No obstante, se debe considerar que esa restauración completa de datos después de un escenario de recuperación con señal de marcado puede ser una tarea ardua y complicada (especialmente cuando en Exchange 2007 son posibles hasta 50 grupos de almacenamiento). Si considera implementar un escenario de recuperación con señal de marcado, tenga cuidado en asegurar que las ventajas compensarán el esfuerzo.

Servicio de instantáneas de volumen
Para aprovechar los discos más económicos y quitar la sobrecarga de procesador de los servidores Exchange en producción, se desarrolló una API de copia de seguridad para Microsoft® Windows Server® 2003 y Exchange. Se creó el servicio de instantáneas de volumen (VSS) para hacer copias de datos coherentes a un momento dado. Estas instantáneas son copias rápidas de sólo lectura de los datos de Exchange que incluyen sucesivamente sólo los datos que han cambiado. Las copias señalan generalmente a otro servidor con espacio en disco disponible o a una red de área de almacenamiento (SAN). Se pueden conservar múltiples instantáneas, con copias de seguridad realizadas en cinta. Como resultado, el servidor Exchange en producción ya no tiene que sufrir el impacto de rendimiento del software de copia de seguridad y el gasto de la copia en cinta.
Existen ventajas al usar VSS para la protección de datos de Exchange. En primer lugar, se puede quitar la carga de rendimiento de las operaciones de copia de seguridad en cinta del servidor Exchange. Aunque todavía es necesario realizar la copia de seguridad en cinta, puede usar la copia de los datos de Exchange y no afectar al rendimiento de usuario. En segundo lugar, es posible tomar instantáneas con más frecuencia que una vez por noche. Y, como ventaja adicional, puede mantener múltiples instantáneas en el servidor secundario o en otro almacenamiento local.
Existen en el mercado varios productos de terceros que aprovechan las capacidades de las instantáneas VSS. Algunos simplemente reducen el tiempo necesario para realizar copias de seguridad y restaurar bases de datos de Exchange, mientras que otros agregan capacidades tales como una recuperación más específica que la incluida en Exchange de manera nativa por lo que puede restaurar hasta el nivel de buzón. Mientras nadie quiere tales copias de seguridad en bloque, las personas desean que se pueda restaurar carpetas específicas o bien mensajes individuales.

Tecnologías de réplica
La conmutación por error de Exchange mediante software es una opción que ofrecen algunos proveedores de réplica. Hace que un servidor Microsoft Exchange en modo de espera se active y que a continuación le diga a Active Directory que todos los buzones de usuarios se han movido. Hay dos maneras de realizar esto, y ambas requieren algunas personalizaciones en Exchange y entornos de Windows. Una implica engañar a su DNS para que el servidor en modo de espera tome el nombre y la dirección IP del servidor con errores. Este enfoque tiene la ventaja de ser sencillo en las estaciones de trabajo cliente porque Outlook® aún piensa que usa el mismo servidor.
El segundo enfoque usa un servidor en modo de espera que ejecuta Exchange y que mantiene copias de la base de datos pero ninguna está montada. Ante un error, el servidor en modo de espera notifica a Active Directory que todos los buzones de usuario se han movido al mismo. Entonces se ejecuta un script, o se distribuye una directiva de grupo, que le dice a los clientes que están en un servidor de correo diferente. Outlook 2007 reconoce Active Directory, lo que hace que el proceso sea más fácil porque resolverá automáticamente estas asignaciones por su cuenta.

Clúster local con MSCS
En un nivel superior en la disponibilidad continua se encuentran los Servicios de Cluster Server de Microsoft (MSCS); Exchange es una aplicación compatible con clúster. El clúster comparte información entre dos o más equipos para que si uno presenta errores, los otros puedan hacerse cargo. Hoy en día, la mayoría de los clústeres de Exchange están compuestos por dos o cuatro nodos, aunque se pueden usar hasta ocho nodos. Un nodo siempre se designa como pasivo, operativo, con Windows Server en ejecución y Exchange Server instalado, pero sin buzones activos. En Exchange 2003 era posible tener un clúster activo/activo de dos nodos, pero debido a las cargas de rendimiento, ahora no es recomendable y no será compatible con Exchange 2007.
Al igual que la disposición de clúster de Exchange 2003, los clústeres de Exchange 2007 que incluyen un nodo pasivo todavía pueden usar una única matriz compartida de almacenamiento. Aunque las matrices de almacenamiento con calidad para clúster típicamente incluyen varias características de redundancia para resistir a muchos tipos de errores, todavía ofrecen una única copia de los datos, lo que deja abierta una ventana de vulnerabilidad. Por eso estos clústeres se denominan clústeres de copia única (SCC), para distinguirlos de la próxima frontera en protección de datos que llega con los clústeres de copias múltiples (MCC) en Exchange 2007. Trataremos los MCC más adelante cuando veamos la recuperación ante desastres.

Replicación continua local
La Réplica continua local (LCR) es una nueva característica de Exchange 2007 que ofrece mejoras en la manera de mantener una segunda copia de las bases de datos y los registros de transacciones de Exchange dentro del mismo servidor. Esto agrega un nivel de redundancia a la recomendación de tener la base de datos de Exchange en una matriz RAID y los registros de transacciones en otra: LCR permite almacenar una copia secundaria de los registros en la matriz que almacena la copia principal de la base de datos y, a continuación, almacenar una copia secundaria de la base de datos en la matriz que almacena la copia principal de los registros (consulte la figura 3). Si se produce un error en el controlador RAID o la matriz, todavía dispondrá de la base de datos y los registros de transacciones en la otra matriz. De este modo, puede seguir operando (aunque un poco nervioso y con alguna degradación del rendimiento) hasta que pueda regenerar la matriz con errores.
Figura 3 Configuración de LCR
Figura 3 Configuración de LCR
LCR es una solución de continuidad operativa local, no una solución de copia de seguridad, así que todavía necesitará una estrategia de copia de seguridad completa. Con LCR, hay también un impacto en el rendimiento porque ahora el servidor realiza dos copias de la base de datos y los registros de transacciones. Además, en la implementación de Exchange 2007, existen algunas limitaciones que harán que LCR sólo sea conveniente para organizaciones más pequeñas, porque sólo admite una única base de datos en un grupo de almacenamiento y una única base de datos de carpetas públicas en una organización.
La conmutación por error mediante una recuperación de LCR no es instantánea; un profesional de TI con experiencia tendrá que ejecutar scripts para recuperar Exchange. El proceso requiere la ejecución de comandos del shell de administración de Exchange que se ejecutan fuera de la consola de administración de Exchange.
Donde Exchange Server 2003 Enterprise Edition permitía que una organización ejecutara hasta 20 bases de datos de Exchange (cuatro grupos de almacenamiento de hasta cinco bases de datos cada uno), Exchange 2007 Enterprise Edition permite hasta 50 grupos de almacenamiento, cada uno con su propia base de datos. Los registros de transacciones también se han reducido de archivos de 5 MB en Exchange 2003 a archivos de 1 MB en Exchange 2007. Ambos cambios están diseñados para admitir LCR más réplica continua en clúster (CCR), que abordaré en un instante.
Las organizaciones pequeñas y medianas usarán LCR para ofrecer una protección mejorada de datos para sus operaciones de Exchange. LCR es fácil de implementar pero todavía supone la intervención manual. Como solución en disco local y en el mismo servidor, LCR sólo es un primer paso hacia una continuidad operativa mejorada. Si bien protege contra errores de una matriz y controladores RAID, los bloqueos de múltiples discos simultáneos o errores de controlador RAID son relativamente raros. La mayoría de las veces, los escenarios de error implican el colapso del servidor entero, lo que nos conduce al paso siguiente en la protección de Exchange.

Réplica fuera de host local de terceros
Para fomentar las capacidades de recuperación de Exchange, otros proveedores han desarrollado productos que aprovechan la réplica "fuera de host" usando archivos de registro de Exchange para mantener una copia en modo de espera de la base de datos de Exchange en otro equipo. En este caso, la protección de datos o solución de archivado realiza una copia de seguridad completa de ESE de Exchange en un equipo diferente y extrae los registros de transacciones en cuanto Exchange los cierra. A continuación, inserta esas transacciones en su copia de la base de datos de Exchange para que se mantenga siempre actualizada. Como he indicado, estos registros son relativamente pequeños (5 MB en Exchange 2003 y 1 MB en Exchange 2007), por lo que una vez que se completa la copia de seguridad, casi no existe sobrecarga en el servidor Exchange al copiar estos archivos de registro al servidor fuera de host.

NIVEL 3: RECUPERACIÓN ANTE DESASTRES Y ALTA DISPONIBILIDAD
La recuperación ante desastres es la capacidad de recuperar y poner en funcionamiento el sistema cuando el principal centro de datos deja de estar disponible. Exchange merece una recuperación ante desastres eficaz porque el correo electrónico y el calendario son el elemento vital de muchas organizaciones actuales.
Algunas compañías se imaginan que sus copias de seguridad en cinta tradicionales almacenadas fuera de sitio son una forma de recuperación ante desastres, pero si el único centro de datos se destruye a causa de un incendio o una inundación, un camión que regrese con los carretes de cintas tiene escaso valor. La recuperación ante desastres implica necesariamente mover no sólo los datos a una ubicación alternativa, sino también la tecnología y los procesos necesarios para recuperar y poner en funcionamiento la aplicación. Para que sea eficaz, la recuperación ante desastres depende de sistemas principales y secundarios separados por alguna distancia. Cuán lejos se encuentren los sitios debe depender de la magnitud del desastre del que se preocupa por superar. Si está preocupado por el riesgo de incendios, quizás otro edificio en su campus esté suficientemente apartado. Sin embargo, los desastres de infraestructura que implican trenes o aviones podrían tener un impacto en un radio de un kilómetro o más. Muchos desastres son regionales: inundaciones, tormentas de hielo, terremotos e incluso cortes del suministro de energía. Las comunicaciones pueden sufrir sus propias calamidades; desde una excavadora que corta el vínculo a su ISP, hasta ataques de denegación de servicio, pasando por ataques DoS de Internet destinados al comercio en general.
Como cuestión práctica, si la organización ya cuenta con más de un sitio con personal de TI, quizás una de esas ubicaciones cumpla sus criterios para continuidad operativa remota, dados los tipos de desastres contra los que se defiende. El uso de instalaciones y personal propias representará costos mucho menores que la contratación de un proveedor de recuperación ante desastres o el alquiler de espacio en una nueva ubicación.
En última instancia, la recuperación ante desastres es también una cuestión de percepción: dar a sus clientes la confianza que todavía realiza su actividad comercial. Las personas entienden cuando un desastre afecta a una ciudad o área, pero si la compañía no vuelve a estar operativa en un par de días o una semana, es probable que los clientes y proveedores crean lo peor; muchas compañías cometen errores por ese motivo. A los clientes les debe parecer que las operaciones se recuperan, para garantizarles que el negocio continúa. Los clientes tendrán diferentes ideas respecto de la recuperación oportuna: son, con razón, menos pacientes con interrupciones de las compañías de servicios financieros que con, por ejemplo, interrupciones en las actividades de los proveedores de muebles de oficina.

Demandas de la recuperación ante desastres
Para poder poner Exchange de nuevo en línea después de un desastre se requiere replicar sus datos al sitio secundario y usar tecnología de réplica que esté preparada para presentar los datos a un servidor Exchange secundario que esté listo para ejecutarlos, y a continuación, notificar a los clientes de Outlook que se han movido sus buzones.
Exchange es una aplicación exigente para la réplica, especialmente sobre grandes distancias. Como verdadera base de datos transaccional, el orden de cada escritura es sumamente importante. Para complicar el desafío, el protocolo de transporte que Exchange usa para comunicar todas las transacciones e información de sistema entre servidores es SMTP, un protocolo conocido que hace un uso intensivo del ancho de banda. Además, con clústeres de Exchange se debe mantener un latido entre sistemas cada 500 milisegundos. Si un nodo secundario no recibe ese latido, puede activar el comienzo de una conmutación por error.
Las complejidades para administrar tales desafíos pueden ser el motivo por el cual Microsoft recién ingresa en este espacio con Exchange 2007. En ausencia de una participación de Microsoft, se han desarrollado varias soluciones de terceros para replicar los datos de Exchange mediante réplica basada en host o réplica basada en matriz.
Los proveedores se dieron cuenta de que podían extender un clúster al dispersar los nodos en diferentes ubicaciones; esto se denomina clúster extendido. Hoy en día, la manera más común de implementar clústeres extendidos es a través de productos de réplica de datos de terceros de uso general o específicamente dirigidos a extender un nodo de Exchange. Esto se puede realizar con MSCS, pero los requisitos de subred son un desafío sobre una WAN. El clúster y las complejidades del aprovisionamiento confiable de conectividad con alto ancho de banda a centros de datos remotos aumenta de manera comprensible los costos y requisitos de personal para crear, mantener y probar periódicamente sistemas de recuperación ante desastres.

Replicación continua en clúster
Microsoft extiende su compatibilidad con clúster mediante la réplica continua en clúster de Exchange 2007. CCR extiende la capacidad de LCR para mantener dos copias de una base de datos y los registros de transacciones de Exchange al implementar la misma idea en dos nodos de clúster. La recuperación ante desastres implica la separación geográfica de sistemas principales y secundarios, y los clústeres de copias múltiples de Microsoft (MCC) no podrán abarcar distancias considerables hasta Windows Server 2008, anteriormente designado con el nombre en código "Longhorn", que hace posible los clústeres extendidos.
La tecnología que permite que los nodos MCC mantengan copias separadas de los datos se denomina conjunto de nodos mayoritarios (MNS), que se refiere al proceso de elección que dos o más nodos realizan para determinar cuál de ellos mantiene la copia activa de los datos. Cuando hay errores, los nodos restantes mantienen una nueva elección para determinar cuál asumirá el trabajo de nuevo servidor de procesamiento principal o de datos. Esta democracia técnica recibe el soporte de CCR, que se asegura que cada nodo tenga una base de datos actualizada. Los clústeres de Exchange 2007 que usan CCR están limitados sólo a dos nodos.
En compañías de mayor tamaño, los servidores Exchange configuran típicamente el disco local de sistema en el mismo servidor y se conectan a la base de datos de Exchange sobre una SAN mediante SCSI, fibra o matrices de disco iSCSI. Con un clúster MCC/MNS, una pregunta interesante es si el almacenamiento avanzado de Exchange evolucionará volviendo a usar matrices locales RAID en cada nodo. Si el propósito de un clúster de MNS es habilitar cada nodo para que tenga su propio almacenamiento separado, ¿tendrá todavía sentido que cada nodo señale a una SAN cuyo propósito principal es ofrecer almacenamiento común?
Un probable escenario intermedio de clúster MCC/MNS tendría el nodo principal con almacenamiento en la SAN y un nodo de clúster secundario con almacenamiento en discos locales o bien en una SAN con iSCSI de bajo costo. Este nodo secundario podría estar alejado del centro de datos principal, en una ubicación que no disponga de una infraestructura SAN.
Independientemente de cómo se presente, MCC mediante MNS y CCR son otro avance en la jerarquía de redundancia y mejora de disponibilidad porque la capacidad de conmutación por error reside en múltiples equipos y los datos se replican en elementos de almacenamiento separados. No obstante, se encuentra completamente reducido a un solo centro de datos hasta la llegada de Windows Server 2008. Windows Server 2008 será compatible de forma nativa con clústeres extendidos y permitirá que los nodos en un clúster MNS se encuentren geográficamente tan separados como se desee, siempre y cuando la latencia de red entre nodos sea menor que 500 ms, de manera confiable. Hasta entonces (y más allá), la tecnología de clúster de terceros puede posicionarse por encima de MNS y CCR de Microsoft para ofrecer la separación geográfica necesaria para que los clústeres extendidos sean una solución eficaz de recuperación ante desastres.
El clúster se encuentra entre las tecnologías avanzadas de recuperación continua ante desastres y CCR está posicionado apropiadamente como una capacidad avanzada de Exchange. Y aunque su combinación implicará gastos en costo y personal, promete ser una emocionante solución del más alto nivel para clientes que deseen ejecutar un entorno de Microsoft homogéneo.

Continuidad operativa remota y de terceros
No cabe duda que la solución de Microsoft y las extensiones de terceros ocuparán el mayor nivel de la recuperación continua cuando estén disponibles. La conmutación por error automática realizada en pocos segundos; es un concepto inmejorable. Aunque no todas las compañías necesitan ese nivel de disponibilidad y continuidad de negocio, ni pueden afrontar la inversión de cientos de miles de dólares necesarios para entregarla. Para muchas compañías, una solución segura que restaure completamente Exchange en minutos proporcionará toda la continuidad operativa que necesitan.
Por ejemplo, Mimosa Systems, Inc. extiende hacia una continuidad remota la continuidad operativa dentro de un único centro de datos. En una ubicación remota, Mimosa DR conserva una copia de Exchange, la mantiene actualizada con los registros de transacciones suministrados por el servidor Exchange principal y está siempre listo para poner esta copia activa a disposición del servidor Exchange en modo de espera. El servidor Exchange remoto usa hardware estándar de servidor y, como en la implementación de un único centro de datos, se mantiene preparado y siempre listo para ser activado en caso de un desastre. Si ocurre el desastre, un operador en el sitio remoto inicia la conmutación por error y la lleva a cabo, incluido el montaje de los archivos de la base de datos en modo de espera y la reasignación de buzones y perfiles de Outlook. No obstante, se debe tener en cuenta que estas soluciones de terceros están sujetas a los límites de compatibilidad definidos en el artículo de Microsoft Knowledge Base "Directiva de compatibilidad de Microsoft para productos de terceros que modifican o extraen contenido de la base de datos de Exchange".

Conclusión
La protección de datos de Exchange está disponible como una continuidad de tecnologías y procedimientos que se pueden agrupar en tres niveles según el costo y las capacidades. Cuando comienza a pensar en los requisitos para la protección de datos de Exchange, debe considerar cuánto tiempo de inactividad pueden tolerar los interesados. Mayor rendimiento y recuperación más rápida cuestan más, con opciones avanzadas cuyo costo puede alcanzar importes de seis cifras. Existen soluciones más económicas que se acercan, pero que no alcanzan exactamente, los niveles más altos de disponibilidad. Las decisiones que tome deben reflejar las verdaderas necesidades de la organización.
Service Pack 1 para Exchange 2007
Actualmente como versión beta en fase de prueba, se espera que el Service Pack 1 (SP1) para Exchange 2007 incluirá varias características que les faltaba a los administradores, incluidas mejoras en OWA, capacidades adicionales de GUI en la consola y mucho más.
De particular interés para administradores que planean soluciones de recuperación, Exchange 2007 SP1 también incluye una tercera solución de disponibilidad para complementar LCR y CCR: la Réplica continua secundaria (SCR). Se trata de un enfoque de término medio y Microsoft mira a ese lugar propicio de mayor capacidad de recuperación, que no tiene la complejidad de la "alta disponibilidad" completa.
SCR permitirá la réplica de la base de datos y los registros de transacciones de Exchange a un servidor Exchange diferente del servidor en que típicamente residen los buzones. El objetivo de SCR puede ser local o remoto y puede ser un clúster o un servidor Exchange en modo de espera. Sin embargo, SCR no requiere un clúster en ninguna de las ubicaciones y difiere de CCR en que el objetivo es un entorno en modo de espera y la conmutación por error es un proceso manual. Tenga en cuenta que todavía necesita obtener esa primera gran copia a través del cable; esencialmente una copia de seguridad completa. Es posible que necesite realizar periódicamente esta gran réplica y debe conocer las implicaciones para la red, al igual que con CCR y las soluciones de terceros. Espero ver una adopción significativa tanto de SCR como de CCR, y de productos adicionales que ofrecen capacidades similares y a veces mayores.

Lee Benjamindirige ExchangeGuy Consulting Services donde trabaja directamente con clientes y aconseja a asociados de Microsoft. Lee es presidente del mayor grupo de usuarios de Exchange en el mundo, ExchangeServerBoston, y director de BostonUserGroups. Lee también es MVP de Exchange, Microsoft Certified Trainer y un orador frecuente en conferencias del sector.
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 Comunicaciones: Mejora de la seguridad con Windows Mobile 6
Comunicaciones Matt Fontaine

Mejora de la seguridad con Windows Mobile 6
Resumen:
  • Seguridad en el dispositivo
  • Seguridad de Exchange Server
  • Seguridad de red

Los dispositivos móviles aumentan la productividad de los trabajadores en todo el mundo, ofreciéndoles acceso a la información corporativa y manteniéndolos conectados incluso cuando se encuentran lejos de la
oficina física. Los aumentos de productividad son reales: simplemente encienden el dispositivo móvil y comienzan a trabajar.
La otra cara de la moneda son los profesionales de TI que se enfrentan al desafío de la difícil tarea de mantener la oficina virtual protegida y estable. Desde su punto de vista, cada dispositivo móvil representa posibles pérdidas de seguridad de red y un riesgo posible de robo de datos. Es fundamental crear una implementación más segura de dispositivos móviles, pero también se debe equilibrar con una experiencia de usuario intuitiva y sin problemas.
Microsoft® Windows Mobile® 6 y su antecesor, Windows Mobile 5.0 con Messaging and Security Feature Pack (MSFP), incluye muchas características que le ayudan a proteger la infraestructura corporativa con mínimas dificultades y mínimos inconvenientes para los usuarios. El uso de Microsoft Exchange Server como plataforma de mensajería aumenta aún más las opciones de seguridad disponibles. En este artículo, demuestro cómo puede usar Windows Mobile y Exchange Server e incluyo algunas recomendaciones para la seguridad de red como base para proteger los dispositivos móviles de la compañía.

Arquitectura de comunicación móvil
Al planear o actualizar una implementación móvil, existen tres niveles que se deben considerar: el dispositivo, el servidor de mensajes y la red (consulte la figura 1). En el nivel de dispositivo, los desafíos clave incluyen permitir sólo el acceso autorizado al dispositivo e impedir las aplicaciones no autorizadas en el dispositivo. Windows Mobile ayuda a impedir el acceso no autorizado al propio dispositivo a través de autenticación de PIN y protección de contraseña, bloqueo de tiempo de espera de dispositivo y la capacidad de "barrer" o borrar la memoria del dispositivo de forma local o remota si se pierde o es robado. Es compatible con el cifrado de datos del canal de comunicación y los medios de almacenamiento extraíbles. También es esencial impedir la instalación de aplicaciones no autorizadas tales como virus o software espía o que tengan acceso a áreas críticas del dispositivo. La definición de la función de administración, los niveles de acceso de aplicación, la configuración de la firma de código, la configuración de seguridad y los certificados de seguridad se combinan y ayudan a alcanzar una protección en el nivel de dispositivo.
Figura 1 Niveles de comunicación móvil
Figura 1 Niveles de comunicación móvil
El siguiente nivel de seguridad es el servidor de mensajería, tal como Exchange Server 2003 con Service Pack 2 (SP2) o Exchange Server 2007. Este nivel incluye tanto la seguridad de mensajes (tecnología por la cual los mensajes se transmiten en forma segura a los dispositivos y desde los mismos) como la interacción entre el servidor de mensajes y el dispositivo móvil mediante Exchange ActiveSync®. No es necesario que Exchange Server use dispositivos Windows Mobile, pero el uso de Exchange ofrece ventajas de costo, escalabilidad, rendimiento y administración.
Las buenas prácticas de seguridad en el nivel de dispositivo y del servidor de mensajería son claves, pero la protección de la capa de red también es crítica. Al configurar la red corporativa según las recomendaciones e implementar protocolos de seguridad sólidos, puede ayudar a evitar daños en la red incluso si uno o más dispositivos móviles se ven comprometidos.

Directivas de seguridad en el dispositivo
La primera línea de defensa contra riesgos de seguridad es el propio dispositivo Windows Mobile. El sistema operativo Windows Mobile ofrece extensos servicios de seguridad en el nivel de dispositivo que son compatibles con la autenticación, el cifrado de tarjetas de almacenamiento, las redes privadas virtuales (VPN), el cifrado Wi-Fi y los servicios de capa de sockets seguros (SSL). La seguridad en el nivel de dispositivo implica administrar quién tiene acceso a un dispositivo y los datos que éste contiene, controlar qué aplicaciones se pueden ejecutar en el dispositivo y establecer cómo se transmiten los datos al dispositivo y desde el mismo. En general, los administradores tienen mucha flexibilidad para configurar y aplicar directivas de seguridad tanto en Windows Mobile 5.0 con MSFP como en Windows Mobile 6.
El acceso de usuario se administra a través de la autenticación mediante PIN o contraseña. Un dispositivo se puede configurar para bloqueo automático después de un período de inactividad o de ser apagado, lo que requiere que un usuario desbloquee otra vez el dispositivo para usarlo (consulte la figura 2). Los detalles específicos de control de acceso de usuario se establecen mediante directivas de seguridad, que se pueden cambiar según la función de seguridad del administrador.
Figura 2 Establecimiento de directivas de contraseñas
Figura 2 Establecimiento de directivas de contraseñas
Las directivas de seguridad definen niveles globales de seguridad para el dispositivo móvil (consulte la figura 3). Las funciones de seguridad determinan quién puede establecer y cambiar estas directivas. La función de administrador, que suele estar reservada para los operadores de dispositivos móviles, ofrece control completo sobre la configuración de directivas de seguridad. La función de empresa es usada por Exchange para administrar algunas directivas de dispositivo, que configura el administrador de Exchange. Según el acuerdo con el proveedor del dispositivo, quizás pueda personalizar directivas de seguridad para la compañía.
Figure 3 Directivas de seguridad para dispositivos móviles (Close Figure 3)

Directiva Dispositivo móvil
Bloquee la penetración no autorizada en el dispositivo

Windows Mobile 5.0 con MSFP

Especifique que el usuario se debe autenticar siempre en el dispositivo para desbloquearlo o permitir que el usuario escriba un PIN en el escritorio.
Función predeterminada: administrador, empresa.

Windows Mobile 6

Permita o deniegue el permiso de usuario para cambiar la configuración de cifrado de dispositivos móviles para medios de almacenamiento extraíbles.
Función predeterminada: administrador, empresa.
Especifique si el usuario se debe autenticar en el dispositivo al conectarse cuando el bloqueo de dispositivo está activo. Función predeterminada: administrador, empresa.
Proteja los datos confidenciales en caso de robo o pérdida del dispositivo

Windows Mobile 5.0 con MSFP

Especifique que el usuario se debe autenticar siempre en el dispositivo para desbloquearlo o permitir que el usuario escriba un PIN en el escritorio.
Función predeterminada: administrador, empresa.

Windows Mobile 5.0 con MSFP y Windows Mobile 6

Especifique si se debe configurar una contraseña en el dispositivo. Configure valores de barrido de dispositivo local y remoto.
Función predeterminada: administrador, empresa.
Los métodos de autenticación con capacidad de personalización que usa Windows Mobile se controlan mediante complementos de autenticación local (LAP), que interactúan con el subsistema de autenticación local (LASS). Esta tecnología permite que Exchange Server controle la configuración del dispositivo a un nivel de detalle, por ejemplo, al aplicar requisitos de longitud y seguridad de contraseña o permitir la autenticación de PIN sencilla.
Windows Mobile 6 dispone de un conjunto ampliado de funciones LAP que se configuran mediante Exchange Server 2007. Puede habilitar el reconocimiento de patrones de PIN (por ejemplo, denegar el uso de patrones sencillos tales como "1111" o" 1234"), configurar períodos de expiración de contraseña o PIN, permitir que los usuarios soliciten un restablecimiento de PIN en función de ciertas condiciones o mantener un historial de PIN o contraseñas para impedir que los usuarios vuelvan a usar los PIN o las contraseñas antiguos cuando se les solicite la generación de nuevos.

Protección de datos en los dispositivos
En caso de que se escriba un PIN o contraseña incorrectos más veces que el límite establecido por el administrador, la característica local de barrido de dispositivo reinicia el hardware de dispositivo y borra así su memoria, incluidas las credenciales de autenticación de usuario. El límite se establece como parte de las directivas de seguridad en Exchange Server. Después de dos entradas incorrectas, el dispositivo solicita al usuario que especifique una cadena clave estructurada para continuar (consulte la figura 4). Esto impide el barrido accidental del dispositivo debido a presiones de tecla aleatorias. También es posible el barrido remoto de la tarjeta de almacenamiento cuando se usa Windows Mobile 6 y Exchange Server 2007.
Figura 4 Aplicación del uso de contraseñas y PIN
Figura 4 Aplicación del uso de contraseñas y PIN
Bloquear un dispositivo es poco práctico si alguien deja una tarjeta de almacenamiento de 2 GB con datos corporativos confidenciales en un taxi. Afortunadamente, puede usar también Windows Mobile 6 para resolver este problema. Puede cifrar los datos de la tarjeta de almacenamiento para que sólo el dispositivo que escribe a la tarjeta del almacenamiento la pueda leer. Al igual que con muchas otras características de seguridad mejoradas de Windows Mobile 6, se puede usar Exchange Server 2007 para proporcionar por aire esta característica de seguridad. El cifrado de la tarjeta de almacenamiento es casi transparente para el usuario. Exchange Server 2007 permite que el administrador elija si los usuarios pueden cambiar la configuración de cifrado de su tarjeta de almacenamiento.
En un dispositivo Windows Mobile, las aplicaciones se podrán ejecutar o no según tres niveles de permisos: con privilegios, normal y bloqueado. Las aplicaciones del nivel "con privilegios" (firmadas mediante un certificado en el almacén de certificados "con privilegios") pueden escribir en el Registro y los archivos de sistema, y también pueden instalar certificados. Al igual que con su PC de escritorio o un servidor, cuantas más aplicaciones tengan capacidad de modificar el entorno de sistema operativo, mayor será la posibilidad de poner en peligro ese entorno. Normalmente es una buena práctica reducir el número de aplicaciones con acceso "con privilegios". La mayoría de las aplicaciones sólo se necesitan ejecutar en el nivel "normal" (aplicaciones firmadas mediante un certificado en el almacén de certificados sin privilegios o aplicaciones sin firmar que el usuario acepta ejecutar), que les permite ejecutar pero impide el acceso a archivos de sistema. Las aplicaciones bloqueadas son precisamente eso, están bloqueadas y no se pueden ejecutar debido a una firma o acción de usuario incorrectas.
Los dispositivos pueden tener una configuración de acceso de seguridad de un nivel o de dos niveles. Con una configuración de acceso de un nivel, las aplicaciones sin firmar se ejecutan con acceso "con privilegios" o están bloqueadas y simplemente no se pueden ejecutar. Una configuración de acceso de dos niveles ejecutará las aplicaciones sin firmar en el nivel normal si la directiva se comprueba correctamente o si el usuario permite que la aplicación se ejecute. En función de la configuración de dispositivo, se puede solicitar al usuario si se debe ejecutar una aplicación sin firmar.
Los certificados digitales, una de las formas comúnmente más usadas de autenticación personal, de dispositivo y de aplicación, son un componente fundamental en la seguridad de Windows Mobile en los niveles de dispositivo, servidor y red. El sistema operativo Windows Mobile almacena varios tipos de certificados en diferentes almacenes de certificados en el dispositivo. Con respecto a las aplicaciones, los certificados determinan cuáles se pueden instalar y ejecutar. Para que una aplicación se ejecute en un dispositivo Windows Mobile sin solicitud al usuario, se debe firmar con un certificado que demuestre que fue aceptada por el programa Mobile2Mobile de Microsoft. Los niveles de permisos se conceden a las aplicaciones en función de los certificados asociados a ellas.
Para la autenticación de red, cada dispositivo móvil incluye varios certificados de raíz comerciales y de confianza emitidos por una entidad de certificación (CA), tal como se muestra en la figura 5. El servidor de mensajería (por ejemplo, Exchange Server) comprueba la autenticidad de un certificado raíz del dispositivo antes de establecer una conexión SSL con dicho dispositivo. Si la compañía usa certificados personalizados, quizás pueda instalarlos en los dispositivos Windows Mobile adquiridos, o es posible que sea necesario crear nuevos certificados. En este artículo, trataré el tema en detalle en la sección Seguridad de red.
Figura 5 Administración de certificados digitales
Figura 5 Administración de certificados digitales
ActiveSync e Internet Explorer® Mobile pueden usar SSL para ayudar a proteger la transmisión de datos entre el dispositivo y un servidor web corporativo. Esto es cierto mientras exista una conexión para sincronizar datos de Microsoft Exchange, configurar el dispositivo o descargar aplicaciones. SSL cifra el canal de comunicación con cifrados RC4 o 3DES de 128 bits para que los datos no puedan ser leídos externamente. Windows Mobile también es compatible con VPN, que usa cifrado de paquetes para ofrecer seguridad semejante a la de una línea dedicada mientras tiene acceso a un servidor a través de Internet.

Seguridad de Exchange Server
Aunque los dispositivos Windows Mobile no necesitan Exchange Server para funcionar, ambos sistemas están diseñados para colaborar juntos y presentan una solución sólida de mensajería móvil y de productividad de un extremo a otro. Desde el lanzamiento de Windows Mobile 5.0 con MSFP, ActiveSync se ha mejorado para permitir la administración remota de la configuración de dispositivos Windows Mobile. Ofrece medios sencillos pero eficaces para propagar y aplicar la configuración de seguridad global en la mayoría de los dispositivos Windows Mobile.
ActiveSync se ejecuta en IIS, el componente de aplicación y servidor web de Microsoft Windows Server 2003. IIS ofrece seguridad integrada que ayuda a proteger al mismo ActiveSync de los ataques que llegan a través de la red. Dado que Microsoft Office Outlook® Web Access (OWA) también se basa en IIS, puede usar los mismos certificados de seguridad tanto para ActiveSync como para OWA.
Cuando ActiveSync se usa para propagar una directiva de empresa, se entrega a los dispositivos la próxima vez que se sincronizan con Exchange Server. Los usuarios deben aceptar los cambios o no se les permitirá conectarse al servidor. Muchas redes tratan con una gran variedad de dispositivos, incluido hardware heredado que no acepta directivas de seguridad sofisticadas. Si fuera necesario, puede excluir ciertos dispositivos, tales como hardware heredado, del requisito de directiva de seguridad para que puedan conectarse.
Exchange Server 2003 SP2 y Exchange Server 2007 tienen capacidades de control de directivas de seguridad algo diferentes. Exchange Server 2003 SP2 se puede usar para especificar una longitud mínima de contraseña de 4 a 18 caracteres, requerir tanto números como letras en una contraseña y establecer cuánto tiempo debe durar el período de inactividad que se permite entre bloqueos de dispositivo. Esta versión de Exchange Server también puede establecer con qué frecuencia se aplica la configuración de seguridad en los dispositivos, así como permitir las exenciones anteriormente mencionadas para dispositivos heredados.
Con el lanzamiento de Exchange Server 2007, las capacidades de administración de dispositivos móviles ActiveSync se han mejorado para incluir todas las capacidades de Exchange Server 2003 SP2, más las siguientes:
  • Permitir o no permitir contraseñas sencillas (tales como "1234" o "1111")
  • Habilitar o deshabilitar descargas de datos adjuntos
  • Requerir cifrado de la tarjeta de almacenamiento
  • Establecer el tamaño máximo de datos adjuntos
  • Permitir que el usuario pueda recuperar una contraseña de dispositivo mediante OWA
  • Habilitar el acceso a la convención de nomenclatura universal (UNC) y a los archivos de Microsoft Windows Sharepoint® Services (WSS)
Con Exchange Server 2007, los profesionales de TI tienen la flexibilidad de adaptar las directivas a cada usuario o dispositivo, administrar las directivas para grupos de usuarios, así como excluir enteramente a usuarios específicos de las directivas de seguridad.

Barrido de acceso remoto
Además del barrido del dispositivo local mencionado anteriormente, puede barrer un dispositivo Windows Mobile de forma remota mediante Exchange Server 2003 SP2, Exchange Server 2007 o OWA. Los barridos remotos, que se produce durante la sincronización, se pueden realizar incluso si no usa las directivas de seguridad de ActiveSync. Un restablecimiento completo de barrido remoto no se puede detener desde el dispositivo. Los datos, la configuración y las claves de seguridad se sobrescriben con ceros repetidos, lo que hace muy difícil la recuperación de cualquier dato que no sea parte del sistema operativo principal.

Seguridad de red
La seguridad de red es precisamente tan importante para la seguridad móvil como el dispositivo y los componentes del servidor de mensajería. También es la parte de la infraestructura móvil que se encuentra más claramente bajo su control. Incluso si uno o más dispositivos móviles se ven comprometidos, configurar la red corporativa según las recomendaciones e implementar los protocolos de seguridad correctos puede ayudar a evitar el daño en la red.
Windows Mobile funciona adecuadamente con varios tipos de red. Mediante protocolos de seguridad estándar de Internet y firewalls, puede diseñar una solución que se adapte a sus necesidades de rendimiento, estabilidad y seguridad.
Cuando los servidores de mensajería se mantienen dentro de la red corporativa, se pueden proteger mediante un firewall de perímetro que actúa como un búfer entre Internet y los servidores corporativos. Microsoft Internet Security and Acceleration (ISA) Server 2004 o ISA Server 2006 tienen características diseñadas especialmente para este propósito, inspeccionan todos los paquetes entrantes para determinar su identidad antes de pasarlos a los servidores Microsoft Exchange y, a continuación, vuelven a enviar al cliente información saliente a través de Internet.
La configuración de ISA Server requiere que la habilitación del cifrado SSL y la designación del puerto 443 como puerto de escucha web SSL para tráfico de Exchange Server. Esto minimiza la exposición a Internet limitándolo a un solo puerto. Además, se debe requerir que todos los clientes establezcan un vínculo SSL antes de conectarse mediante ActiveSync.
ISA Server puede realizar una autenticación previa de usuarios de aplicaciones web como OWA para ayudar a impedir que los usuarios no autenticados alcancen los servidores de aplicaciones. ISA Server 2006 mejora el modelo de puente SSL de ISA Server 2004 actuando como punto de terminación SSL para dispositivos Windows Mobile. Esto permite a dispositivos Windows Mobile autenticar con el servidor Microsoft Exchange, sin establecer una conexión directa con él, dependiendo en cambio de ISA Server 2006 para pasar tráfico de aquí para allá. Y dado que la ubicación recomendada de ISA Server 2006 está en la red del perímetro, se permite así un nivel adicional de seguridad entre la nube pública de Internet y el front-end de Exchange Server.

Autenticación
Existen dos opciones básicas de autenticación para entre las que se puede elegir: básica y basada en certificados. Básica se refiere a una conexión estándar habilitada mediante nombre y contraseña, basada en SSL, entre un cliente de Windows Mobile y el servidor Exchange front-end. Aún requiere un certificado porque Exchange Server busca un certificado raíz coincidente en el dispositivo antes de autenticar. Windows Mobile e IIS le permiten usar la amplia gama de metodologías de cifrado asociadas con SSL.
La autenticación basada en certificados, disponible tanto en Windows Mobile 5.0 con MSFP como en Windows Mobile 6, usa seguridad del nivel de transporte (TLS) en lugar de autenticación básica SSL. Además del certificado raíz, TLS requiere que cada usuario tenga un certificado con claves pública y privada. Debido a que TLS usa una clave de cifrado (de hasta 2.048 bits) en lugar de una contraseña, este protocolo ofrece la autenticación más sólida.
Con Windows Mobile 6, para inscribir un certificado de usuario mediante Desktop Enroll se necesita acoplar el dispositivo con un escritorio que se encuentre en el mismo dominio que el servidor de inscripción de certificados. El usuario autentica la inscripción mediante una contraseña, tarjeta inteligente u otro método y, a continuación, conecta el dispositivo a su PC de escritorio. El usuario obtiene acceso al sistema de certificado a través del escritorio que, a su vez, instala el certificado en el dispositivo móvil. Desktop Enroll puede servir para varios propósitos de seguridad de Windows Mobile, incluidos la renovación del certificado, así como la distribución de certificados de autenticación de ActiveSync, certificados de autenticación SSL/TLS, certificados de Wi-Fi 802.1x o certificados de firma digital de S/MIME.
Los protocolos de seguridad tales como SSL protegen los datos de mensajes mientras se encuentran en tránsito, pero no los cifra una vez que se encuentran en el dispositivo Windows Mobile o en el servidor Microsoft Exchange. S/MIME es una forma segura del conocido estándar MIME de correo electrónico que es compatible con correo electrónico firmado digitalmente y/o cifrado. Ofrece un nivel adicional de protección más allá del cifrado del nivel de transporte SSL.

Conclusión
Se debe prestar atención a cada uno de los tantos niveles que componen una solución para crear una infraestructura que sea suficientemente segura. Windows Mobile, Exchange Server y los productos de Microsoft para seguridad de red, tal como ISA Server, funcionan en conjunto para despejar muchas dificultades de la administración de la infraestructura móvil. Ayudan a aliviar una parte de la carga de los departamentos de TI, al desplazar la atención lejos de los desafíos de seguridad creados por los dispositivos móviles, para que se centren en los aumentos de productividad que habilitan.

Agradecimientos especiales a Kathy Esser, Katharine Holdsworth, Sarah Norton y Chip Vollers por su ayuda en la creación de este artículo.

Matt Fontaine es escritor de tecnología para BuzzBee Company.


 Comunicaciones: Una alternativa eficaz a las carpetas p&#250;blicas
Comunicaciones Alan Maddison

Una alternativa eficaz a las carpetas públicas
Resumen:
  • Calendarios y contactos compartidos
  • Comunicación con blogs y wikis
  • Uso compartido y administración de documentos

Las carpetas públicas se han usado desde la primera versión de Microsoft Exchange, con el objetivo original de ofrecer una plataforma básica para compartir documentos, archivar listas de distribución y desarrollar aplicaciones personalizadas. Sin embargo, prácticamente desde
el principio los administradores han luchado con la administración y el uso de lo que se ha transformado en una parte cada vez más compleja de muchos entornos Exchange. Aunque Exchange Server 2007 incorporó algunas mejoras considerables en la administración de carpetas públicas, la dificultad sigue presente. Las carpetas públicas no ofrecen la plataforma robusta de colaboración y administración de documentos que las empresas necesitan en la actualidad.
Microsoft ha indicado que Exchange Server 2007 puede ser la última versión del producto compatible con carpetas públicas. Aunque siguen siendo totalmente compatibles y continuarán recibiendo soporte técnico completo durante los 10 años posteriores al lanzamiento de Exchange Server 2007, es un buen momento para examinar una alternativa.
Afortunadamente, Microsoft ha suministrado una opción atractiva con el lanzamiento de Microsoft ® Office SharePoint® Server (MOSS) 2007. MOSS 2007 ofrece la plataforma de TI que los administradores y las compañías necesitan para reemplazar y superar las capacidades que ofrecen las carpetas públicas. En este artículo, demuestro el modo en que MOSS presenta un marco robusto y eficaz que puede ofrecer bastantes más capacidades que las carpetas públicas de Exchange. En particular, me centraré en el uso de SharePoint para tareas que comúnmente cumplen las carpetas públicas, como por ejemplo, compartir calendarios, contactos y documentos.
Tenga presente que las carpetas públicas seguirán siendo necesarias al menos hasta que se actualicen los clientes. Los clientes Microsoft Outlook ®, desde Outlook 97 hasta Outlook 2003, requieren carpetas públicas por varios motivos, entre los que se incluyen las libretas de direcciones sin conexión, la biblioteca de formularios de organización y las búsquedas de disponibilidad. Una vez que cambie a Outlook 2007 y Exchange Server 2007, podrá eliminar completamente el uso de carpetas públicas cuando lo decida.

Calendarios de SharePoint
Los calendarios compartidos son un uso común para las carpetas públicas; con SharePoint es muy fácil sustituir un calendario de SharePoint por un calendario de carpeta pública. Si bien una instalación predeterminada de un sitio de SharePoint incluye un calendario, probablemente sea necesario crear varios calendarios para contemplar las necesidades de la organización. Para hacer una demostración, lo guiaré a través del proceso de creación de un calendario compartido para un equipo de Recursos Humanos. El primer paso es seleccionar Ver todo el contenido del sitio; esto típicamente aparece en la esquina superior izquierda del sitio de SharePoint (consulte la figura 1).
Figura 1 Creación del nuevo contenido del sitio
Figura 1 Creación del nuevo contenido del sitio
Después de seleccionar Ver todo el contenido del sitio, haga clic en el botón Crear (que también se ve en la figura 1). Una vez que se cargue la página Crear, verá las opciones predeterminadas de tipo de contenido (tal como se muestra en la figura 2). Para crear un calendario, debe seleccionar Calendario en la columna Seguimiento. A continuación, debe completar los campos de nombre y descripción y elegir si el calendario se incluirá en la sección Vínculos rápidos.
Figura 2 La página Crear muestra muchas opciones predeterminadas
Figura 2 La página Crear muestra muchas opciones predeterminadas
En este momento, el calendario está creado. El usuario tiene la opción de ver el calendario compartido a través del sitio de SharePoint o directamente desde Outlook. En este último caso, sólo necesita conectarse con el calendario mediante su explorador web, abrir el menú Acciones y seleccionar la opción Conectar con Outlook.
La primera vez que se realiza la conexión, Outlook muestra una advertencia de seguridad para recordarles a los usuarios que sólo se deben conectar con fuentes conocidas y de confianza. Una vez que se selecciona Sí, el calendario se conectará con Outlook. La figura 3 muestra la vista predeterminada, con el calendario de SharePoint al lado del calendario de Outlook.
Figura 3 Visualización del calendario de SharePoint y el calendario de Outlook uno al lado del otro
Figura 3 Visualización del calendario de SharePoint y el calendario de Outlook uno al lado del otro
Una vez que el calendario se conecta con Outlook, se puede producir sincronización bidireccional. Cualquier evento que se especifique mediante Outlook se sincronizará con SharePoint y todos los usuarios que vean el calendario verán las entradas actualizadas. Además, si se habilitó la compatibilidad con SMTP dentro de SharePoint, los eventos se pueden enviar por correo electrónico directamente al calendario y SharePoint agregará esas entradas.

Contactos de SharePoint
Los contactos compartidos, que también dependen de carpetas públicas, son usados por muchas organizaciones. Una vez más, SharePoint ofrece una alternativa más robusta, facilitando la creación y administración de las listas de contacto. Continuando con el mismo ejemplo, ahora mostraré cómo crear una lista de contactos compartida para el departamento de Recursos Humanos del ejemplo.
Nuevamente, seleccione Ver todo el contenido del sitio y haga clic en el botón Crear. Seleccione el vínculo Contactos de la columna Comunicaciones. Aparecerá una pantalla donde se proporciona información para la configuración de vínculo rápido, nombre y descripción (consulte la figura 4). Una vez que completa esta información, simplemente haga clic en el botón Crear y se creará la nueva lista de contactos.
Figura 4 Cómo completar la configuración de vínculo rápido, nombre y descripción
Figura 4 Cómo completar la configuración de vínculo rápido, nombre y descripción

Comunicación con el usuario
Además, SharePoint se puede usar para crear un panel de discusión (también conocido como lista de discusión). Al igual que con los calendarios y contactos, el proceso de creación es muy sencillo: seleccione Ver todo el contenido del sitio, haga clic en el botón Crear y seleccione el vínculo Panel de discusión de la columna Comunicaciones. Como hizo antes, complete la información adecuada para la configuración de vínculo rápido, nombre y descripción y, a continuación, haga clic en el botón Crear. La figura 5 muestra un panel de discusión con algunos anuncios de ejemplo.
Figura 5 Ejemplo de panel de discusión con un par de anuncios
Figura 5 Ejemplo de panel de discusión con un par de anuncios
Además de paneles de discusión, SharePoint Server ahora es compatible con dos herramientas de comunicación muy populares: blogs y wikis. Los blogs y wikis, que no están disponibles con carpetas públicas, son nuevos en SharePoint Server 2007 y son herramientas que ofrecen capacidades de colaboración interesantes y útiles para el conjunto de características.
Los blogs proporcionan un foro interactivo donde un blogger puede compartir fácilmente pensamientos e ideas anunciándolos en un sitio web. Típicamente, estos anuncios se categorizan para que los lectores encuentren anuncios de su interés más fácilmente. Además, los lectores pueden ofrecer respuestas a los comentarios de un blogger. Una empresa, por ejemplo, puede hacer que miembros de la administración ejecutiva mantengan un blog. Esto puede ser una herramienta eficaz para comunicarse con los empleados y ofrece un medio para que los miembros del personal compartan ideas y mantengan una comunicación fluida en todos los niveles.
La creación de un blog en SharePoint es sencilla. Primero seleccione Ver todo el contenido del sitio, haga clic en el botón Crear y seleccione Sitios y áreas de trabajo debajo de la columna Páginas web. Esta acción lo lleva a la página Nuevo sitio de SharePoint, donde debe proporcionar el título, el nombre y la dirección URL del sitio. Después se elige una plantilla para el sitio; en este caso, seleccione la plantilla Blog. Las últimas tres opciones de configuración son para permisos, navegación y lista del directorio del sitio. Después de completar todas las opciones necesarias, presione el botón Crear. Esto crea en realidad un subsitio dentro del sitio de nivel superior; dentro del subsitio hay bibliotecas y listas que proporcionan las capacidades de blogging. Una vez que el proceso esté completo, pasará al nuevo blog.
Un wiki es otra gran herramienta diseñada para una creación aún más cooperativa. Los usuarios pueden agregar, quitar y editar contenido en el sitio, así como vincular muchas páginas juntas. La manera más sencilla de crear un wiki es la siguiente: seleccione Ver todo el contenido del sitio, haga clic en el vínculo Crear y seleccione Biblioteca de páginas wiki, que se enumera en la columna Bibliotecas. Después de completar los campos requeridos con la configuración de navegación, nombre y descripción, haga clic en el botón Crear y habrá terminado. Para obtener más información sobre el uso de wikis en SharePoint, consulte el artículo "Edición de wikis mientras trabaja del ejemplar de enero de 2007 de TechNet Magazine.

Bibliotecas de SharePoint
Las carpetas públicas de hecho se han convertido en repositorios de documentos, ofreciendo una ubicación central donde los usuarios pueden tener acceso a documentos y compartirlos fácilmente. Como descubrieron los administradores de Exchange con el paso de los años, éste es uno de los usos principales que han hecho que las carpetas públicas sean tan difíciles de manejar. Esto no sólo causa un aumento en la E/S de Exchange para la base de datos de carpetas públicas, sino que además repercute en la réplica a través de toda la infraestructura de Exchange. Las bibliotecas de SharePoint ofrecen una excelente alternativa, aliviando la demanda sobre Exchange y sus recursos.
Una biblioteca de SharePoint es una ubicación dentro de un sitio de SharePoint que permite almacenar y administrar archivos. Hay varios tipos de bibliotecas, incluso de imágenes, páginas wiki, formularios y documentos. Cuando se considera un reemplazo para carpetas públicas, la biblioteca de documentos es la elección más adecuada. Una biblioteca de documentos admite el almacenamiento, la administración y, en algunos casos, la creación de documentos dentro del sitio de SharePoint.
Se pueden almacenar muchos tipos distintos de archivos en una biblioteca de documentos, pero determinados tipos de archivo, como los ejecutables y los scripts, están restringidos de forma predeterminada por motivos de seguridad. Estas restricciones, sin embargo, pueden ser configuradas mediante la sección Operaciones del sitio de administración central de SharePoint.
Una instalación predeterminada de MOSS incluye una biblioteca de documentos que se puede personalizar. La mayoría de las organizaciones querrán crear varias bibliotecas para admitir las distintas unidades de negocio dentro de la organización. Esto es fácil de hacer mediante las herramientas que ofrece SharePoint. Por ejemplo, para implementar una biblioteca de documentos para Recursos Humanos, seleccione Ver todo el contenido del sitio, haga clic en el vínculo Crear y elija Biblioteca de documentos, que se enumera en la columna Bibliotecas. Verá varios parámetros que debe configurar; proporcione un nombre y descripción para la biblioteca, especifique si la biblioteca se incluirá en la sección Vínculos rápidos, elija si se habilitarán las versiones y seleccione un formato predeterminado para nuevos documentos creados directamente en la biblioteca.
Preste atención particularmente a la opción Historial de versiones del documento. La selección predeterminada para esto es Deshabilitada. Sin embargo, las versiones pueden ser útiles y adecuadas en muchos entornos. Además de almacenar copias históricas de documentos, esta funcionalidad realiza el seguimiento del momento en que se realizaron cambios y quién los realizó; también ofrece la capacidad de ver y restaurar versiones anteriores.
La figura 6 muestra la biblioteca de documentos recién creada con algunos documentos que han sido cargados. Una vez que haya creado las bibliotecas de documentos, puede hacer que estos repositorios estén disponibles a través de Microsoft Outlook y Windows ® Explorer. Outlook permite tomar el contenido de una biblioteca de documentos sin conexión y proporciona una copia de sólo lectura para usuarios que no tienen acceso a la red. Ofrecer acceso a través de Explorador de Windows saca partido de la opción Mis sitios de red. Puede ofrecer acceso a los usuarios si escribe la dirección URL de la biblioteca de documentos. En entornos más grandes, puede considerar el uso de la opción Directiva de grupo para implementar estos sitio de red.
Figura 6 La biblioteca de documentos, que contiene algunos documentos que se han cargado
Figura 6 La biblioteca de documentos, que contiene algunos documentos que se han cargado

Más allá de lo básico
SharePoint proporciona un conjunto de características que supera claramente las capacidades que ofrecen las carpetas públicas. Además de ofrecerle parte de la funcionalidad común que se obtiene con las carpetas públicas, SharePoint Server también proporciona capacidades más eficaces que pueden ampliar el poder de estos usos comunes. Entre estas capacidades mejoradas se incluye:
  • Historial de versiones
  • Control de aprobación
  • Procedimientos de desprotección
  • Control de flujo de trabajo
  • Directivas de retención de documentos
  • Auditoría
  • RSS
Las características como éstas son cruciales para cualquier plataforma de administración de contenido empresarial, y Sharepoint ofrece un marco robusto que los administradores pueden usar con comodidad. Esta funcionalidad mejorada se puede habilitar para muchas de las características de SharePoint, incluso calendarios, tareas, paneles de discusión y bibliotecas de documentos.
Para configurar esta funcionalidad, seleccione el menú Configuración y elija la opción de configuración, por ejemplo la opción Configuración de biblioteca de documentos, tal como se muestra en la figura 7. Aparecerá la página Configuración, donde se pueden ver todas las opciones de configuración y personalización disponibles. El vínculo de configuración de Versiones bajo la columna Configuración general, por ejemplo, permite configurar el historial de versiones.
Figura 7 Selección de la opción de configuración para configurar la funcionalidad mejorada
Figura 7 Selección de la opción de configuración para configurar la funcionalidad mejorada
Como se mencionó antes, esta funcionalidad ofrece un registro de modificaciones de documento, incluso quién hizo los cambios y cuándo los hizo, y permite que un usuario vea y restaure versiones anteriores si fuera necesario. También se puede controlar cuántas versiones son almacenadas por SharePoint. Una vez que se alcanza este límite, los elementos se eliminan sin ser enviados a la Papelera de reciclaje de SharePoint.
La sección Versiones también permite configurar los requisitos de aprobación de contenido y desprotección necesarios. Cuando la opción Aprobación de contenido está habilitada, cualquier elemento enviado deberá ser aprobado antes de que esté disponible para otros usuarios. Los elementos no aprobados permanecen en estado pendiente. El proceso de desprotección proporciona control de contenido prohibiendo que varios usuarios trabajen en un archivo al mismo tiempo.
Los flujos de trabajo son otra característica útil que ofrece SharePoint y que no está disponible con las carpetas públicas. Básicamente, los flujos de trabajo ofrecen un enfoque estructurado a procesos empresariales que puede ayudar a agilizar las operaciones de la empresa. Cuando se implementan dentro de SharePoint, los flujos de trabajo son una serie de tareas predefinidas que automatizan el movimiento de un documento a través del proceso designado. El proceso puede ser iterativo, lo que requiere que cada paso se complete antes de avanzar al paso siguiente, o puede ser paralelo, lo que permite que cualquier tarea dada se complete en cualquier momento. Los flujos de trabajo predeterminados que se incluyen con SharePoint son:
  • Aprobación
  • Recopilación de comentarios
  • Recopilación de firmas
  • Aprobación de disposición
Las directivas de administración de la información se usan para exigir el cumplimiento con regulaciones y requisitos empresariales. Una directiva consiste en un conjunto de reglas relacionadas con la administración y el control de documentos. SharePoint Server admite reglas personalizadas, pero incorpora reglas predeterminadas útiles entre las que se incluye:
  • Auditoría
  • Expiración
  • Etiquetas
  • Códigos de barras
La auditoría permite registrar eventos según un conjunto de acciones que se definen dentro de la configuración del sitio. Se puede hacer el seguimiento de acciones tales como la apertura de un documento, la descarga o visualización de un elemento o sus propiedades, la edición de un documento, la desprotección o protección de un documento, el movimiento o la copia de elementos y la eliminación o restauración de elementos.
La expiración del contenido permite eliminar contenido para cumplir con las directivas de retención de datos de la organización. La expiración de estos datos puede ocurrir en una fecha en particular o un tiempo después de que se produjo determinado evento, tal como la creación de un documento.
Las etiquetas se usan junto con la impresión, agregando texto a la impresión. En la práctica, esta directiva puede tener varios usos. Por ejemplo, podría ser necesario que todos los documentos de la biblioteca de documentos compartida de Recursos Humanos contengan un aviso de confidencialidad para cumplir con el reglamento del departamento jurídico.
Los códigos de barras ofrecen un método formal de seguimiento de documentos tanto en línea como impresos. SharePoint creará un identificador exclusivo para cada documento y así los usuarios podrán insertar una imagen del código de barras en su documento.
Otra mejora significativa que ofrece SharePoint es su integración con el suministro RSS. Los calendarios, los contactos, las bibliotecas de documentos y los paneles de discusión proporcionan un suministro RSS al cual se puede suscribir un usuario. Los usuarios pueden recibir actualizaciones automatizadas para contribuir al seguimiento de sus responsabilidades diarias; sólo se requiere un lector de RSS, tal como Outlook 2007.

Últimas palabras
Microsoft Office SharePoint Server 2007 ofrece características de clase empresarial y una alternativa más eficaz para las carpetas públicas de Exchange. Un marco administrativo robusto facilita la implementación de una solución para compartir calendarios, contactos y documentos. También se pueden crear diversas maneras de comunicarse, incluso foros de discusión, blogs y wikis.

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


 Comunicaciones: Inicie una sesi&#243;n en Outlook Web Access con tarjetas inteligentes
Comunicaciones Victor Akinnagbe and Ted Dressel and Jason Opdycke

Inicie una sesión en Outlook Web Access con tarjetas inteligentes
Resumen:
  • Autenticación en dos fases
  • Delegación limitada de Kerberos
  • ISA Server y Exchange

Los empleados móviles presentan un desafío exclusivo para la seguridad en las organizaciones de TI. Los usuarios remotos necesitan acceso seguro a los datos y servicios como, por ejemplo, el correo electrónico. Sin embargo, lamentablemente la realidad es que la mayoría de
los vínculos vulnerables en la cadena de seguridad implican contraseñas deficientes, software malintencionado (tales como los registradores de pulsaciones de tecla) y los virus en los equipos remotos que tienen acceso a los recursos internos de la organización.
Una manera de aumentar la seguridad en este entorno móvil es quitar uno de esos vínculos vulnerables: las contraseñas (aunque la idea de permitir el acceso a una cuenta sin una contraseña para autenticación puede parecer molesta). Una técnica principal para eliminar los problemas asociados con contraseñas se conoce como la autenticación en dos fases (o a veces conocida como autenticación multifase). En lugar de depender de un método único, como una contraseña, para habilitar el acceso, la autenticación en dos fases exige el uso de métodos de autenticación adicionales, entre los que se incluyen una combinación de nombre de usuario y contraseña, un dispositivo físico tal como una tarjeta inteligente o un identificador biométrico tal como una huella dactilar.
Si tiene usuarios remotos, normalmente tendrá que abrir el firewall un poco para permitir el acceso remoto a la red corporativa. Un firewall estándar le proporciona una mitigación básica del riesgo al ofrecer un aislamiento de nivel de red entre las redes internas y externas (consulte la figura 1). Para obtener una seguridad adicional, los puertos se bloquean, y es necesario obtener una comunicación con un dispositivo en la red interna, los puertos se reenvían entonces al lugar correcto. Estas técnicas ofrecen una protección importante en el nivel de red, pero ahora se han hecho necesarias varias capas de seguridad de red debido a la siempre creciente sofisticación de los ataques.
Figura 1 Firewall estándar con puertos bloqueados o reenviados
Figura 1 Firewall estándar con puertos bloqueados o reenviados
Puesto que los servicios corporativos más comunes que los empleados móviles usarán con mayor frecuencia son el correo electrónico y la mensajería, seguramente la infraestructura de Exchange pasa a ser más importante que nunca. Proporcionar a los usuarios acceso al correo electrónico a través de Outlook® Web Access (OWA) es una manera de ofrecer servicios seguros a empleados móviles. Ofrecer una autenticación en dos fases más segura para OWA mediante tarjetas inteligentes es otro paso clave. En este artículo, echamos un vistazo más detenido a los problemas de configuración e instalación que debería tener en cuenta a la hora de permitir su propia implementación de OWA habilitada con tarjetas inteligentes.

Mejor que un firewall
La implementación de Microsoft® Internet Security and Acceleration (ISA) Server 2006 en la red puede simplificar la tarea de la apertura de la red a usuarios remotos de una manera más segura. ISA Server 2006 incluye características de mejora de la seguridad, como por ejemplo, redes privadas virtuales (VPN) habilitada con tarjeta inteligente, autenticación LDAP (Protocolo ligero de acceso a directorios) a Active Directory® y delegación restringida de Kerberos. ISA Server es algo diferente de lo que se puede considerar tradicionalmente como un firewall. Ofrece varios niveles de seguridad no sólo al funcionar en el nivel de red, y puede hacer esto en lugar del hardware de firewall estándar o en conjunto con él, sino también al ofrecer características de seguridad adicionales que no suelen ser compatibles con firewalls tradicionales, tales como filtros de aplicaciones. ¿Desea impedir que un usuario use el método HTTP POST en un sitio web hospedado concreto? ¿Desea obligar el cumplimiento de RFC en mensajes SMTP antes de que toquen Exchange Server? ¿Desea inspeccionar paquetes HTTP cifrados de Nivel de sockets seguros (SSL)? ISA Server puede administrar todas estas tareas y más para asegurarse de que sólo el tráfico limpio y filtrado se reenvía a la red perimetral o red interna.
Las sesiones SSL son un problema para los firewalls estándar. Cuando los paquetes atraviesan el firewall, permanecen cifrados (lo que significa que SSL funciona correctamente). Así, si una aplicación como OWA se publica a través de firewall de hardware o software mediante SSL, no hay realmente ningún tipo de inspección apreciable que el firewall estándar pueda realizar distinta a la inspección de paquete activa. Simplemente, la apertura y el reenvío de los puertos pueden dejar expuesta una importante área de ataque. Puesto que no se está produciendo ninguna inspección verdadera en el perímetro, los paquetes sin inspeccionar y no autenticados podrían dirigirse a la red interna.
ISA Server 2006 puede actuar como un extremo SSL para clientes HTTP, garantizando que únicamente el tráfico autenticado alcanza el servidor Exchange publicado. ISA Server admite una característica útil denominada puente SSL. Típicamente, un paquete está cifrado por un cliente que se comunica con ISA Server mediante una sesión SSL estándar. Con el puente SSL, ISA Server puede poner fin al cifrado SSL de forma local, inspeccionar el paquete ahora sin cifrar, autenticar el usuario a Active Directory (si fuera necesario), volver a cifrar el paquete mediante SSL y pasar el paquete cifrado al servidor de Exchange adecuado (consulte la figura 2). Mediante esta técnica, el puente SSL mitiga los ataques ocultos dentro de una sesión SSL que, para un firewall que desconoce las aplicaciones, no parecerían más que objetos BLOB cifrados de datos.
Figura 2 ISA Server toma una vista de nivel de aplicación del tráfico
Figura 2 ISA Server toma una vista de nivel de aplicación del tráfico
El tráfico previamente autenticado que alcanza el servidor es un punto importante que se debe tener en cuenta cuando se habla de la delegación restringida de Kerberos. En un firewall estándar, los puertos simplemente se reenvían al servidor de Exchange y el propio servidor front-end es responsable de realizar las tareas de autenticación frente a lo que podrían ser usuarios malintencionados. Cuando se requiere autenticación, ISA Server puede ponerse en contacto directamente con Active Directory y solicitar las credenciales en nombre del usuario. Si el usuario está autenticado correctamente, ISA Server reenviará el mensaje al servidor Exchange front-end. El servidor front-end ya no tiene que autenticar solicitudes aleatorias de usuarios desconocidos y se puede usar únicamente para enviar por proxy solicitudes a los servidores back-end. ISA Server 2006 también puede usar la delegación restringida de Kerberos para habilitar el acceso basado en certificados a tecnologías como Windows SharePoint Services y Exchange ActiveSync.
Exchange Server 2003 incluía compatibilidad con la autenticación basada en Kerberos entre los servidores front-end y back-end para inicios de sesión de OWA. (Está usando IPsec para proteger el tráfico del cliente, ¿no es así?) Exchange Server también admite la autenticación Kerberos a servidores de buzón en clúster.

Habilitación de la autenticación mediante tarjeta inteligente
La implementación de la autenticación basada en tarjetas inteligentes para OWA ha sido un desafío. Sin embargo, se desarrolló una solución basada en la característica de delegación restringida de Kerberos ahora disponible en ISA Server 2006. La solución permite a un usuario enviar credenciales mediante un certificado para autenticar correctamente a OWA. La delegación restringida de Kerberos se incluye como una mejora bienvenida en comparación con la compatibilidad de la delegación de Kerberos en Windows® 2000, que usaba la delegación sin restricciones. La función restringida de Kerberos es más segura y limita el riesgo potencial de ataques sofisticados que usan la suplantación.
En el escenario habilitado con tarjeta inteligente, ISA Server 2006 se pone en contacto con Active Directory para autenticar el usuario, ya que este último no tiene el acceso enrutable a un centro de distribución de claves (KDC) de la red externa. ISA Server somete a Active Directory la asignación de certificado-usuario para autenticar el usuario y adquiere entonces los respectivos vales de Kerberos según el nombre principal del usuario (UPN). En este caso, ISA Server ofrece la funcionalidad de delegación restringida de Kerberos a un servidor Exchange front-end mediante el filtrado de nivel de aplicación y los servicios de proxy inverso. Si la delegación se intenta sin un proxy inverso, el riesgo aumentado de vulnerabilidades podría afectar a la integridad de la red o del dominio de Active Directory.
Tanto Exchange Server 2003 como Exchange Server 2007 permiten la autenticación básica e integrada. Sin embargo, tiene que aplicar una actualización de software a Exchange Server 2003 para que funcione la autenticación basada en tarjetas inteligentes a OWA. (Para obtener más información, consulte el artículo "Descripción de la nueva característica de Exchange Server 2003 que admite la autenticación mediante tarjeta inteligente a Outlook Web Access".) Debe tener un dominio en el modo funcional nativo de Windows Server® 2003, todo los servidores de Exchange Server 2003 implicados deben tener SP2 o versiones posteriores aplicadas y necesita un servidor ISA Server 2006 que actúe como un proxy inverso para el sitio de OWA.
Después de que instale la actualización de software y configure los servidores ISA Server y Exchange, los usuarios pueden autenticar una sesión de OWA mediante tarjetas inteligentes. La figura 3 muestra el flujo de eventos necesarios para la autenticación mediante tarjeta inteligente. Un usuario comienza por abrir el sitio de OWA en Internet Explorer® (1). De hecho, el usuario en realidad se conecta a ISA Server y se le solicita un certificado en lugar de un nombre de usuario y contraseña para iniciar la sesión de OWA. El certificado adecuado se almacena en la tarjeta inteligente para la que el usuario necesita un PIN.
Figura 3 Autenticación de OWA con una tarjeta inteligente
Figura 3 Autenticación de OWA con una tarjeta inteligente
La validación de certificados (2) se controla mediante una lista de certificados revocados (CRL) o una solicitud de Protocolo de estado de certificados en línea (OCSP), según la configuración de ISA Server y otro software instalado. ISA Server realiza una solicitud a un controlador de dominio (DC) para comprobar las credenciales del usuario. Si se produce un error en la solicitud, ISA Server ofrece una página de error al usuario y ninguna solicitud llega al servidor Exchange front-end.
Después de que se comprueban las credenciales, se genera el vale de Kerberos y la solicitud se pasa al servidor Exchange front-end usando la autenticación integrada (3). Cuando el servidor Exchange front-end recibe la solicitud, valida el vale de Kerberos y encuentra el servidor back-end de buzones del usuario (4).
El servidor front-end solicita un vale de Kerberos para el servidor back-end adecuado a través de la delegación restringida de Kerberos y envía por proxy la solicitud de buzón al servidor back-end mediante la autenticación integrada (5). El servidor back-end atiende la solicitud (6) y los datos del buzón se devuelven al servidor Exchange front-end (7). Los datos HTML para la página de OWA se pasan a ISA Server (8) que, a su vez, los pasa de nuevo al equipo cliente (9).

Configuración del entorno de Exchange
El artículo de Knowledge Base que se mencionó anteriormente describe la actualización de software para Exchange Server 2003 e incluye información que le guiará por el proceso de habilitación de la delegación restringida de Kerberos mediante ISA Server 2006 y Exchange Server 2003.
La acción principal que la actualización de software habilita es la automatización de la delegación restringida de Kerberos desde el servidor Exchange front-end a los servidores back-end respectivos. La actualización no automatizará el proceso de delegación restringida de Kerberos desde ISA Server al servidor front-end, ya que ISA Server no forma parte de la organización de Exchange. Esa delegación tendrá que habilitarse manualmente desde cada sesión de ISA Server a cada servidor Exchange front-end.
La actualización de software agrega una nueva ficha en el Administrador del sistema de Exchange (ESM) que permite designar un servidor Exchange front-end como un KCD-FE (consulte la figura 4) que, a su vez, permite que ese servidor se rellene en la ficha de la delegación de los servidores Exchange back-end respectivos.
Figura 4 Habilitación de la delegación restringida de Kerberos
Figura 4 Habilitación de la delegación restringida de Kerberos
La nueva interfaz de usuario también permite especificar en las propiedades del grupo administrativo las credenciales que se deben usar para rellenar el atributo msDS-AllowedToDelegateTo (A2D2), tal como se muestra en la figura 5. Éste es el atributo responsable de la delegación restringida de Kerberos.
Figura 5 Establecimiento de la cuenta que controla la delegación
Figura 5 Establecimiento de la cuenta que controla la delegación
Al respetar el principio de privilegio mínimo, puede usar una cuenta de usuario estándar y concederle la capacidad de delegar usuarios y equipos mediante un objeto de directiva de grupo (GPO). Después de que a la cuenta se le haya concedido este permiso elevado, se puede usar como una cuenta de servicio para automatizar el proceso de delegación restringida de Kerberos para el grupo administrativo respectivo.
Lleve a cabo los pasos apropiados para asegurarse de que ningún usuario malintencionado pueda poner en peligro la cuenta del servicio de delegación restringida de Kerberos. Aunque la cuenta no sea un administrador de dominio, el acceso a ella podría dar lugar a sofisticados ataques que aprovechan la delegación de Kerberos. Puesto que la cuenta tendrá la capacidad de establecer nuevas asociaciones de Kerberos, debería usarse con cuidado. Tome las precauciones necesarias para garantizar la seguridad y la integridad de dicha cuenta: una contraseña larga y compleja, auditoría aumentada, técnicas de inhabilitación de cuentas, etc.
La actualización de software de Exchange también crea un cambio muy importante a la interfaz de ESM respecto a la autenticación integrada. Anteriormente en Exchange Server 2003, cuando un servidor se designaba como servidor front-end, la opción para habilitar la Autenticación integrada de Windows para los directorios virtuales HTTP (bajo el servidor virtual HTTP) aparecía atenuada (consulte la figura 6).
Figura 6a La actualización habilita la autenticación integrada
Figura 6a La actualización habilita la autenticación integrada
Figura 6b La actualización habilita la autenticación integrada
Figura 6b La actualización habilita la autenticación integrada
Esto se produce porque la autenticación integrada no era compatible en servidores Exchange front-end debido a problemas técnicos como, por ejemplo, el hecho de que los servidores proxy interrumpieron las sesiones NTLM, los usuarios que emplean la autenticación Kerberos necesitaban una conexión a Active Directory y los usuarios de Internet generalmente no formaban parte del dominio. La actualización descrita en el artículo de Knowledge Base anterior quita estas limitaciones. Con la actualización instalada, simplemente puede ir al directorio virtual y activar la casilla para la Autenticación integrada de Windows como el mecanismo para comprobar las credenciales de usuario. Cuando se activa, establece un atributo denominado msexchAuthenticationFlags en el objeto de directorio virtual de Active Directory (puede verlo si usa el complemento de Adsiedit.msc para Microsoft Management Console).
Los usuarios que comprueban el correo a través de OWA pueden saber el nombre de sus servidor Exchange back-end y pueden conectarse a ellos usando la autenticación integrada mientras que se encuentran en la intranet corporativa. La diferencia en la experiencia de usuario con la autenticación integrada es que, puesto que ha iniciado una sesión en la red, no se le pide un nombre de usuario y una contraseña porque Internet Explorer le autenticará al sitio web de manera automática. Esto es fantástico para los usuarios que se encuentran en la red corporativa, pero los usuarios externos (y los usuarios de OWA suelen ser externos) normalmente no habrán iniciado sesión en un dominio cuando provengan del exterior de la red en un servidor Exchange front-end. (Este proceso se explica con todo detalle en el artículo de Knowledge Base "Cómo IIS autentica los clientes de explorador".)
En Exchange Server, la actualización rellena la ficha Delegación para usar el atributo A2D2 en lugar del nombre principal de servicio (SPN) en Active Directory. Si echa un vistazo al objeto de equipo de Exchange que usa Adsiedit.msc, debería observar dos atributos distintos: el atributo A2D2, que es la lista de la delegación restringida de Kerberos; y el atributo de SPN, que sirve como localizador de Kerberos y punto de especificación de cuenta. Aunque es cierto que ambos atributos funcionan de manera conjunta para que se produzca la delegación restringida de Kerberos, sólo debería modificar el atributo A2D2 a través de la interfaz gráfica.
Windows puede usar el SPN HOST integrado como un alias para localizar otros servicios. Esto significa que no es necesario usar setspn.exe para que la delegación restringida de Kerberos funcione para la delegación front-end a back-end de Exchange. (Aunque la especificación explícita de HTTP/Servername en la lista de atributos de SPN funcionará con esta solución, deja más lugar para errores de administrador y no es necesario para que funcione la delegación restringida de Kerberos). La delegación restringida de Kerberos busca el atributo A2D2 en Active Directory. Cuando este atributo no está rellenado (o rellenado con el valor SPN incorrecto), la delegación restringida de Kerberos no funcionará entre los servidores respectivos. Sin embargo, en un clúster de Exchange, el atributo A2D2 del servidor front-end sólo tiene que señalarse a la cuenta de equipo del nodo de clúster para que funcione adecuadamente.
Como se observó anteriormente, un dominio de Windows Server 2003 que contiene servidores Exchange 2003 debe estar en el modo funcional nativo de Windows Server 2003. La delegación restringida de Kerberos no se puede usar a menos que se haya logrado ese nivel de funcionalidad de dominio. Si el dominio todavía se encuentra en el modo mixto e instala la actualización de software mencionada anteriormente, parecerá que funciona pero realmente se producirá un error en los registros de SPN. La delegación restringida de Kerberos es también una función de dominio y no una función de nivel de bosque. Esto significa que para Exchange Server 2003, ISA Server y los servidores front-end y back-end deben ser miembros del mismo dominio (aunque los usuarios de dominios diferentes todavía puedan autenticar a la delegación restringida de Kerberos). Una sesión de ISA Server que no es miembro de un dominio ni miembro de un dominio diferente no funcionará como parte de esta solución.

Configuración del sitio de OWA
La administración de IIS no se debe usar para ningún tipo de cambios de autenticación en OWA. Aunque OWA se ejecuta bajo IIS y responderá a los cambios en la metabase como cualquier otro sitio web, Exchange incorpora algo de complejidad con el proceso de servicios de directorio a la metabase (DS2MB). El proceso DS2MB replicará los cambios de Active Directory en la metabase IIS mediante un proceso unidireccional que sobrescribirá los cambios realizados directamente en IIS. La repercusión de este proceso es que si un administrador entra para realizar un cambio directamente en la metabase IIS (como, por ejemplo, para establecer la autenticación integrada), parecerá que la solución funciona pero se interrumpirá una vez que arranque el ciclo de réplica de DS2MB.
La opción para habilitar la autenticación integrada de Windows para los directorios virtuales HTTP se hizo disponible en ESM porque ESM realiza sus modificaciones directamente en Active Directory que, a su vez, hace que el cambio se replique hacia la metabase IIS. Tenga en cuenta que aunque la detención del servicio de Operador de sistema también detendrá el proceso DS2MB, permitiéndole realizar cambios en la metabase IIS y no sobrescribirlos; esto no es aconsejable. La próxima vez que se inicie el Operador de sistema, realizará un sondeo de los cambios de Active Directory y, a continuación, se deshabilitará la solución automáticamente.
La ficha Delegación muestra las opciones de usar solamente Kerberos y usar cualquier protocolo de autenticación. La lógica sencilla le diría que seleccione la opción de usar solamente Kerberos, ya que la solución que tratamos usa la delegación restringida de Kerberos; sin embargo, ésta es una de las muchas situaciones de IT en las que la lógica común no se aplica. Por tanto, en cambio debería seleccionar la opción de usar cualquier protocolo de autenticación (tal como se muestra en la figura 7) porque la solicitud no entra como una solicitud de Kerberos, sino como una solicitud HTTP con un certificado correspondiente asignado a una cuenta Active Directory.
Figura 7 Configuración correcta de la autenticación para tarjetas inteligentes
Figura 7 Configuración correcta de la autenticación para tarjetas inteligentes
En este caso, ISA Server solicita el certificado PKI de usuario sobre SSL. La solicitud entrante no es un vale de Kerberos y, por tanto, se tiene que producir una transición para que la delegación restringida de Kerberos funcione adecuadamente. De este modo, si configura la opción de usar solamente Kerberos, se interrumpirá la cadena de comunicación en ISA Server. Sin embargo, tenga en cuenta que la opción de usar solamente Kerberos funcionará en la delegación de servidor front-end al servidor Exchange back-end puesto que el servidor front-end sólo recibirá los vales de Kerberos de ISA Server.
Los directorios virtuales \Exchange y \Public son las únicas ubicaciones que deberían contener información de carpeta pública y de usuario privado. La configuración de SSL en Exchange no es nueva para la delegación restringida de Kerberos ni la autenticación en dos fases, sino un remanente de la habilitación de SSL estándar de OWA con las credenciales de autenticación básicas. Debería seguir los métodos documentados para habilitar SSL en OWA porque forzar SSL incorrectamente puede interrumpir OWA y causar problemas con ESM.

Detalles adicionales de configuración
Al implementar esta solución, es mucho más sencillo implementar primero ISA Server y Exchange de la manera estándar. No incorpore la solución completa de delegación restringida de Kerberos con todos los valores configurados (especialmente si no tenía ISA Server anteriormente en la implementación). Esto puede complicar el proceso de solución de problemas en el caso de que se produzca un error en el componente o el paso. Es mucho más sencillo implementar ISA Server y Exchange de la manera estándar (con el nombre de usuario y la contraseña pero sin la autenticación basada en formularios), asegurarse de que la instalación funciona y, a continuación, realizar la transición a la delegación restringida de Kerberos y la autenticación de certificados.
Normalmente, la autenticación basada en formularios no se puede usar con OWA habilitada con tarjeta inteligente. La autenticación basada en formularios indica que un usuario tiene un nombre de usuario y una contraseña que se deben enviar mediante el formulario estándar de Outlook. Sin embargo, con la autenticación en dos fases basada en tarjeta inteligente, el usuario tendrá sólo una tarjeta inteligente y no una contraseña. Por lo tanto, la autenticación basada en formularios no tendrá ningún medio para aceptar ni enviar únicamente el certificado para la autenticación. El uso de la autenticación basado en formularios en cualquier lugar de la cadena (por ejemplo, en un servidor front-end detrás de ISA Server) interrumpirá la configuración de OWA habilitada con tarjetas inteligentes. Si habilita la autenticación basada en formularios, el directorio virtual de Exchange se establecerá forzosamente en la autenticación básica y así, la metabase IIS se establecerá también en la autenticación básica.
Si tiene una combinación de usuarios que tienen nombres de usuario/contraseñas y tarjetas inteligentes, puede habilitar la autenticación de reserva en el servicio de escucha web de ISA, y cuando un usuario presione el botón ESC después de que se le piden las credenciales basadas en certificado, se le pedirán las credenciales estándar de nombre de usuario/contraseña aunque la autenticación integrada esté habilitada detrás de ISA Server en el servidor de Exchange. Además, ISA Server puede agotar el tiempo de espera de la sesión SSL de una manera muy similar a las funciones de autenticación basadas en formularios.

Conclusión
La compatibilidad con tarjetas inteligentes para la autenticación a OWA es una adición bienvenida tanto para Exchange Server 2003 como para Exchange Server 2007. Con la capacidad de iniciar sesión en OWA usando un certificado, los usuarios ya no se tienen que preocupar por recordar largas y complejas contraseñas, y los administradores disponen ahora de una herramienta eficaz frente a los registradores de pulsaciones de teclas y otras formas de software malintencionado que pueden descubrir credenciales de usuario de un sistema infectado. Consulte la barra lateral de "Recursos" para obtener más información.
La configuración correcta de ISA Server para la autenticación en dos fases mediante tarjetas inteligentes aumenta más la seguridad general al realizar un filtrado de nivel de aplicación en la aplicación de OWA publicada. Además, ISA Server 2006 incorpora compatibilidad para publicar Exchange Server 2003 y Exchange Server 2007 a través de los sencillos asistentes para publicación, por lo que ISA Server sigue siendo una inversión sólida para las organizaciones que están realizando la transición a Exchange Server 2007.
Recursos
  • Cómo compartir archivos quitados por la función de filtrado de "HTML seguro" en Outlook Web Access para Exchange Server 2003
  • Solución de problemas de la delegación de Kerberos
  • Servicio de actualización de metabase
  • Autenticación en ISA Server 2006
  • Transición del protocolo y delegación restringida de Kerberos
  • TechNet Webcast: Implementación de la autenticación multifase mediante tarjetas inteligentes

Victor Akinnagbees ingeniero de campo principal de Microsoft que trabaja en el área de Washington, D.C. Se centra principalmente en la seguridad, en la infraestructura y en la mensajería.
Ted Dresseles consultor de Microsoft que trabaja en el área de Washington, D.C. Se centra principalmente en la seguridad y la infraestructura.
Jason Opdycke es ingeniero de campo principal de Microsoft del área de Charlotte, Carolina del Norte. Se centra principalmente en las áreas de la seguridad y la infraestructura.


 Administraci&#243;n de Windows: Servicio del instalador de ActiveX en Windows Vista
Administración de Windows Rob Campbell and Joel Yoker

Servicio del instalador de ActiveX en Windows Vista
Resumen:
  • Desafíos comunes con controles ActiveX
  • Cómo se instalan los controles ActiveX
  • Permisos peligrosos
  • Un proceso más seguro en Windows Vista

Siempre es la misma historia. Para mejorar sustancialmente la seguridad, tiene que renunciar a alguna libertad o flexibilidad. Si el entorno es como la mayoría de las organizaciones, tiene un fuerte deseo de reforzar el sistema operativo de escritorio con el fin de ofrecer una entorno informático
más seguro para los usuarios finales. Los administradores de TI suelen enfocar la tarea de proteger el escritorio al emplear una combinación de configuración de directivas de seguridad, permisos de usuario, listas de control de acceso de archivo y Registro (ACL) y restricciones de servicio del sistema.
Un obstáculo común en el desarrollo de un entorno de escritorio seguro es cómo mitigar las amenazas que rodean los controles ActiveX® malintencionados a la vez que se ofrece un nivel adecuado de compatibilidad de aplicaciones en el entorno. Esto ha sido un desafío con sistemas operativos de escritorio durante muchos años. Afortunadamente, el nuevo Servicio de instalador de controles ActiveX (AxIS) de Windows Vista™ se dirige a las preocupaciones específicas de la administración de controles ActiveX en entornos corporativos. AxIS ofrece una manera sencilla y controlable para los usuarios estándar, a los que normalmente no se les permitirá instalar controles ActiveX, para instalarlos desde sitios web aprobados. El control de directivas de grupo sobre AxIS permite a los administradores de TI determinar qué controles pueden instalar los usuarios, independientemente de qué permisos disponen.
En este artículo, echamos un vistazo a los desafíos administrativos que rodean los controles ActiveX, cómo se trataron estos problemas en versiones anteriores de Windows® y cómo AxIS de Windows Vista ofrece una manera exclusiva y eficaz de administrar la instalación de controles ActiveX.

¿Qué es un control ActiveX?
Un control ActiveX es un fragmento de código ejecutable (normalmente un archivo OCX empaquetado dentro de un archivo de Cabinet) que el usuario instala e invoca mediante Internet Explorer®. Los desarrolladores web crean controles ActiveX para agregar funcionalidad a sus aplicaciones web que no pueden obtener fácilmente con HTML estándar o un script sencillo.
Una característica principal de los controles ActiveX es su sencillo modelo de implementación de "descargar y ejecutar". Los controles ActiveX se instalan y se invocan mediante la etiqueta de objeto HTML, que tiene un atributo denominado CODEBASE que indica a Internet Explorer (usando una dirección URL) dónde obtener el control si no se encuentra ya instalado en el equipo del usuario. En ese caso, Internet Explorer descarga el paquete de instalación asociado, realiza la comprobación de confianza en el objeto y pide al usuario el permiso de instalación mediante la barra de información de Internet Explorer (que se muestra en la figura 1). Durante la instalación, el control se registra y lo invoca la página de representación. Una vez instalado, cualquier usuario estándar puede invocar el control. Este sencillo mecanismo de distribución y ejecución pretende ofrecer a los desarrolladores una manera sencilla de distribuir sus componentes a los usuarios de su aplicación web. El problema con este método de distribución es que los usuarios estándar no pueden instalar directamente controles ActiveX porque se requieren privilegios administrativos para completar la instalación.
Figura 1 Barra de información de instalación de control ActiveX
Figura 1 Barra de información de instalación de control ActiveX
Cuando los controles ActiveX se presentaron por primera en Internet Explorer 4.0, Internet parecía un lugar mucho menos amenazante. Hoy en día, el código ejecutable distribuido por la Web puede representar una amenaza considerable, así que Windows sólo permite a los usuarios con derechos locales de administrador que instalen controles ActiveX, y entonces sólo si la instalación se aprueba según la configuración de directivas. Una vez que un administrador instala un control ActiveX, cualquier usuario del sistema puede invocarlo. Este comportamiento lo facilita un conjunto de ACL de archivos y Registro en Windows. Mientras que esto impide que los usuarios estándar instalen controles ActiveX, no mitiga los riesgos para los administradores locales y usuarios estándar (con permisos predeterminados modificados) que los instalan.
Si bien la protección predeterminada en Windows (que permite únicamente privilegios administrativos para realizar la instalación) trata los controles ActiveX en el nivel individual, no trata la manera de administrarlos a través de una organización grande. Un desafío común en los entornos corporativos es cómo permitir el uso de controles ActiveX de confianza para la organización de TI a la vez que se mitigan las posibles amenazas ofrecidas a través de controles externos y que no son de confianza. Al final y al cabo, la decisión de instalar un control ActiveX concreto, correcto o incorrecto, se deja a menudo a un usuario individual, en función de sus derechos. Para contrarrestar las amenazas, algunas organizaciones bloquean todos los controles ActiveX, mientras que otras permiten la instalación de usuario final pero intentan administrar cualquier software malintencionado que se instale.
Otra manera de evitar la instalación de controles incorrectos es aplicar los derechos restringidos del usuario estándar y que el administrador de TI preinstale todos los controles necesarios en la plataforma de escritorio. Esto es eficaz si los controles ActiveX en uso son relativamente estáticos por naturaleza, se modifican usando un proceso de versión programado junto con actualizaciones de escritorio o si la organización usa un mecanismo de distribución de software como, por ejemplo, un servidor de administración de sistemas. Sin embargo, la administración continua, las necesidades siempre cambiantes de los desarrolladores de aplicaciones internas y las dependencias en controles externos continuarán siendo un desafío con estos métodos.
En situaciones en las que los usuarios tienen privilegios administrativos, el problema es diferente; implica impedir que estos usuarios instalen controles que no se han aprobado. En estos casos, se supone el derecho del usuario final a instalar controles ActiveX puesto que el usuario tiene privilegios administrativos. (Tenga en cuenta que tener a los usuarios finales ejecutándose como administradores locales es una postura que representa un alto riesgo para la organización y no se recomienda para la mayoría de los entornos corporativos.)
Una solución es tener un servidor interno de descarga de componentes de Internet que hospeda los controles aprobados. Esta solución requiere la modificación de la cadena CodeBaseSearchPath en el Registro del cliente. Normalmente, cuando se encuentra una etiqueta de objeto que contiene el atributo CODEBASE en la página HTML solicitada, los clientes de Windows se dirigen a las ubicaciones especificadas en los datos de CodeBaseSearchPath. De forma predeterminada, esta cadena del Registro contiene la palabra clave CODEBASE y direcciones URL de Internet para la galería de controles ActiveX. Para implementar un servidor de descarga de componentes de Internet, tiene que reemplazar los datos predeterminados en CodeBaseSearchPath por la dirección URL del servidor interno donde se hospedarán los controles aprobados por la organización. Al igual que el enfoque anterior, esta solución requiere una administración continua y lleva el costo y la complejidad de hospedar un servidor interno para controles ActiveX.
Hay otras soluciones, como por ejemplo, la modificación de la zona URLActions de Internet Explorer, la especificación de los controles aprobados por el administrador a través de la directiva de grupo y el bloqueo de la instalación de todos los controles en el perímetro a través de reglas de firewall. Sin embargo, como puede ver, todos estos enfoques tienen sus problemas y muchos se abandonan finalmente debido a la falta de flexibilidad. Lo que es peor, algunas de estas soluciones todavía requieren que el usuario tenga derechos administrativos. Al final, estas modificaciones intentan tratar las partes del problema, como por ejemplo, el control (o el bloqueo) de donde proceden los controles ActiveX, de donde se pueden invocar, etc.; sin embargo, estas soluciones no mitigan el problema fundamental de que los usuarios sin derechos de administrador no pueden instalar controles ActiveX.

¿Qué puede hacer AxIs?
AxIS de Windows Vista permite al administrador corporativo administrar controles ActiveX a la vez que mantiene una postura de fuerte seguridad teniendo a los usuarios en ejecución como usuario estándar con la configuración predeterminada del sistema de archivos. AxIS ofrece opciones de directiva de grupo para configurar los orígenes de confianza de controles ActiveX y un proceso de agente para instalar controles de esos orígenes de confianza en nombre de usuarios estándar. La ventaja clave es que puede mantener una postura de seguridad no administrativa en estaciones de trabajo de usuario junto con el control administrativo centralizado. AxIS depende del administrador de TI para identificar orígenes de confianza (normalmente direcciones URL de Internet o intranet) de controles ActiveX. Cuando una etiqueta de objeto dirige Internet Explorer para que invoque un control, AxIS lleva a cabo los pasos siguientes:
  1. Comprueba que el control está instalado. De no ser así, debe ser instalado antes del uso.
  2. Examina la configuración de la directiva de AxIS para comprobar si el control procede de un origen de confianza. La comprobación específica coincide con el nombre de host de la dirección URL especificada en el atributo CODEBASE de la etiqueta de objeto frente a la lista de ubicaciones de confianza especificadas en la directiva.
  3. Descarga e instala el control en nombre del usuario.
Si el nombre de host de la dirección URL de origen no está incluido en una lista en la configuración de directiva de AxIS, se invocará la pregunta normal del Control de cuentas de usuario (UAC), requiriendo los derechos administrativos para completar la instalación. Además, AxIS registrará un evento con Id. 4097 en el registro de eventos de aplicación de AxInstallService de origen que resume la instalación del control ActiveX intentada, junto con la ruta de acceso de descarga específica al control. En la figura 2 se muestra un ejemplo del evento 4097. El administrador corporativo puede usar los datos de esta entrada de registro de eventos para modificar la directiva de grupo, permitiendo que AxIS instale el control en visitas posteriores al sitio web.
Figura 2 Evento 4097 AxInstallService
Figura 2 Evento 4097 AxInstallService
AxIS es un componente opcional que se incluye con los SKU Business, Enterprise y Ultimate de Windows Vista, y se puede habilitar a través de una opción desatendida o a través del cuadro de diálogo Panel de control (Programas | Programas y características | Activar o desactivar las características de Windows), tal como se muestra en la figura 3. Una vez habilitado, AxIS avanza por los pasos resumidos anteriormente cada vez que Internet Explorer solicita un control.
Figura 3 Habilitación de AxIS en el Panel de control
Figura 3 Habilitación de AxIS en el Panel de control
La capacidad de adjuntar tareas a eventos en Windows Vista ofrece una manera sencilla para que un administrador reciba una notificación del servicio de AxIS, como cuando la instalación de un control ActiveX está bloqueada. Es importante tener en cuenta que no siempre se puede suponer que el control ActiveX se instalará desde el mismo nombre de host de dirección URL que el usuario final que tiene acceso desde su sitio web. Por este motivo, la información que proporciona el evento AxInstallService 4097 (instalación intentada) se puede demostrar increíblemente útil en la identificación del host desde el que se intenta instalar el control.
Con la información que obtiene del evento, puede configurar la ubicación de confianza en la directiva de grupo. La configuración de AxIS en la directiva de grupo o local se encuentra en los valores de configuración del equipo (como puede ver en la figura 4). Los sitios de instalación aprobados para la configuración de directivas de controles ActiveX le permiten especificar direcciones URL de host de ubicaciones de confianza (consulte la figura 5). La configuración de sitio aprobada requiere dos fragmentos de información, desde donde se puede instalar el control ActiveX y el comportamiento de la instalación.
Figura 4 Configuración del Editor de objetos de directiva de grupo
Figura 4 Configuración del Editor de objetos de directiva de grupo
Figura 5 Sitios de instalación aprobados por AxIS
Figura 5 Sitios de instalación aprobados por AxIS
En primer lugar, como se mencionó anteriormente, se requiere una dirección URL de host para indicar la ubicación de confianza del control. A diferencia de las soluciones anteriores, que requerían saber el CLSID del control (que a menudo cambia cuando los desarrolladores modifican los controles), AxIS permite la instalación de cualquier control desde la ubicación de confianza, con lo que se reduce la carga administrativa general. El segundo fragmento de información es una cadena delimitada por comas de cuatro valores; cada uno de los cuales dicta el comportamiento de la experiencia de descarga del control ActiveX. Los valores especifican cuatro propiedades: TPSSignedControl, SignedControl, UnsignedControl y ServerCertificatePolicy. Las primeras dos propiedades (TPSSignedControl y SignedControl) pueden tener uno de estos tres valores: 0, 1 ó 2. Estos valores son similares a los valores encontrados en la configuración de URLAction. Un valor de 0 impide la instalación del control, un valor de 1 hace que al usuario se le pida permiso para instalar y un valor de 2 hace que el control se instale en silencio en nombre del usuario. Los controles sin firmar no se pueden instalar en silencio y por tanto el valor de UnsignedControl sólo puede ser 0 ó 1. Tenga en cuenta que si no se especifica ninguna directiva, se usan los valores predeterminados de 2, 1 y 0.
La propiedad final especifica el comportamiento de la instalación según la configuración de certificado del control de configuración firmada. Como la mayoría de los sitios SSL, los certificados deben superar un conjunto de pruebas de seguridad para asegurarse de que el certificado es válido. Las propiedades de certificado no válido son a veces la realidad de la implementación del control ActiveX firmado del mundo real. A través de su configuración, AxIS permite a los administradores mitigar la información no válida que se presenta a veces con certificados en una base de dirección URL por dirección URL. La propiedad final está representada como una combinación de máscaras de bits de los valores mostrados en la figura 6.
Figure 6 ServerCertificatePolicy (Close Figure 6)

Valor | Definición
0x00001000 | Omite un nombre canónico no válido (CN) en el certificado.
0x00000100 | Omite las autoridades de certificado desconocidas.
0x00002000 | Omite una fecha de certificado no válida.
0x00000200 | Omite el uso de certificado incorrecto.
La configuración predeterminada es 0, lo que significa que deben superarse todas las comprobaciones de seguridad antes de que AxIS complete la instalación. La combinación de la configuración de host y estos cuatro valores se especifican en la configuración de directiva, tal como se ve en la figura 7.
Figura 7 Direcciones URL de host de AxIS aprobadas
Figura 7 Direcciones URL de host de AxIS aprobadas

Conclusión
AxIS le permite configurar la directiva de grupo para controlar qué usuarios de controles ActiveX pueden instalar sin requerir privilegios administrativos o configuraciones complejas. El control en este nivel podría ser un desafío en versiones anteriores de Windows y las soluciones disponibles anteriormente a menudo se incluían con limitaciones graves o aumento en la sobrecarga de administración. AxIS ofrece a las organizaciones otra herramienta para el método de privilegio mínimo para los derechos de usuario finales en sistemas de escritorio, permitiendo la implementación de un modelo de usuario estándar donde los usuarios finales no requieren privilegios administrativos. Windows Vista devuelve el control al administrador de TI al disponer de la elección de qué controles ActiveX son de confianza dentro del entorno corporativo determinado por la organización, no el usuario final.

Rob Campbell es técnico especialista senior del equipo federal de Microsoft. Rob se dedica a desarrollar e implementar soluciones de seguridad para clientes del gobierno federal de Estados Unidos.
Joel Yoker es consultor senior del equipo federal de Microsoft. Joel se dedica a desarrollar e implementar soluciones de seguridad para clientes del gobierno federal de Estados Unidos.


 Nota del editor: Seis grados
Nota del editor
Seis grados
Joshua Trupin

¿Se ha sentido alguna vez un poco desconectado? ¿Se ha sentado sólo en su oficina, mirando fijamente en el abismo, y preguntándose si existe vida inteligente ahí fuera? ¿Y si es que, de hecho, hay alguien ahí fuera? Quizá no, especialmente si su bandeja de entrada está permanentemente hasta el tope, como la mía.
No obstante, recientemente experimenté esos remordimientos y decidí que necesitaba conectarme. Me suscribí a uno de esos sitios de redes sociales de negocios y comencé a agregar personas; todas con las que alguna vez he trabajado, a las que compré un artículo o hablé en una conferencia. Dentro de la semana, tenía 58 contactos en mi lista. ¡Genial!
Pero eso sólo fue el primer nivel. En el segundo nivel, los conocidos de conocidos, tenía más de 3.500 amigos. Y como cada uno de esos 3.500 contactos tenía sus propios contactos, me acerqué a 277.000 contactos de tercer grado en poco tiempo. Un cálculo rápido en el reverso de una planilla de cálculo de Excel: si se supone un promedio de 50 contactos por persona, resulta que conozco 34 mil millones de personas como contactos de sexto grado. ¡Hazte a un lado, Kevin Bacon! Conozco más personas que las que existen en el Planeta Tierra. De repente el abismo era numerosísimo.
Sin embargo, esto suponía un nuevo problema. ¿Cómo puedo atender todas estas relaciones? Estoy abierto a cualquier y toda sugerencia. ¿Usa en la actualidad un sitio de redes sociales o de negocios? ¿Cómo ordena a las personas con las que desea hablar y las separa de las que quiere evitar? Vaya al http://blogs.technet.com/tnmag y cuéntenos lo que piensa sobre este problema candente.
Si todo esto de la red Web 2.0 no le interesa, no se asuste. El numero de este mes de TechNet Magazine mejora sus comunicaciones al hacer mejor uso de Exchange Server. Tenemos cinco artículos que ofrecen el conocimiento que necesita para extender el alcance de la mensajería de su organización.
El uso de la autenticación de tarjetas inteligentes con Outlook Web Access es uno de nuestros temas destacados de este mes. Siempre es una buena idea solicitar una forma de autenticación física antes de conceder acceso a los recursos de su compañía, y las tarjetas inteligentes lo hacen posible desde cualquier lugar. También analizamos la recuperación ante desastres con Exchange Server, cómo reemplazar carpetas públicas con Sharepoint en Exchange Server 2007 y cómo mejorar la seguridad de dispositivos móviles con Windows Mobile 6. Y por supuesto, tenemos Preguntas y respuestas sobre Exchange, que debería ser su columna favorita para todo lo que tenga que ver con mensajería. ¡Ay!, otras tres personas más aparecieron en mi red. Será mejor que me fije si digo hola o simulo que estoy durmiendo.
—Joshua Trupin

Mi agradecimiento a los siguientes expertos de Microsoft: Kristian Andaker, Chris Corio, Jim Harrison, Chad Jones, Michael Lee, Shawn McGrath, Michael Murgolo, Eric Perlin, Michelle Rutzer, Gavriella Schuster y Jim Truher.


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

Supervisión de conexiones remotas
RecordTS
www.tsfactory.com
¿Ha deseado alguna vez poder supervisar sus sesiones de Terminal Server o de Escritorio remoto? Quizá desee saber lo que pasaba antes de que la sesión de Escritorio remoto pareciera dar de baja su sitio web. Quizá tenga un problema en su Terminal Server que simplemente parece no poder replicar. Puede que le preocupe la seguridad de la propiedad intelectual. O bien, podría ser que tenga que realizar un registro rápido o una presentación sobre cómo ha configurado el servidor de Sharepoint® en un entorno de prueba. Si cualquiera de estos escenarios le resulta familiar, debería desproteger RecordTS de TSFactory. (TSFactory lo creó Cláudio Rodrigues, Microsoft MVP para Terminal Services).
RecordTS está disponible en dos ediciones: Terminal Server y Escritorio remoto. La edición correcta para usted dependerá de qué tipos de conexiones desea supervisar. Tal como confirma el sitio web del producto, RecordTS actúa como una "cámara de seguridad" en las sesiones de Terminal Server o de Escritorio remoto. Básicamente, el software actúa como un proxy entre Terminal Services y la sesión de usuario final, lo que le permite registrar todos los movimientos y las acciones llevadas a cabo en una sesión.
La instalación intuitiva usa un asistente sencillo en el que se señala la aplicación al directorio de datos en el que desea almacenar las sesiones guardadas. La aplicación instala un complemento de MMC (que le permite configurar el servicio), el servicio RecordTS y una utilidad de reproducción de sesión para ver las sesiones registradas. Después que abrir el complemento de MMC, al hacer clic con el botón secundario del mouse en la carpeta del servicio se abre una pantalla de propiedades en la que puede definir la configuración, como por ejemplo, en qué puerto desea que se ejecute el servicio. (Esta configuración concreta es útil si cambió las sesiones de Terminal Services a un puerto no estándar). En la ficha Almacenamiento, puede establecer la carpeta de almacenamiento predeterminada a una carpeta local o una ruta de acceso UNC.
También puede configurar la estructura de directorios de las sesiones almacenadas. Por ejemplo, puede usar el dominio, el usuario y la fecha y la hora para organizar los datos que se guardan. Y, quizás la configuración más importante a la hora de almacenar sesiones en un disco local, puede indicar al servicio qué hacer si el disco se queda sin espacio. Tiene la opción de no permitir conexiones nuevas y desconectar las sesiones actuales (la opción para los que tienen la seguridad muy en mente) o de desactivar la grabación de sesión (la opción deseada si no desea interrumpir la productividad).
En la ficha Security, puede especificar si desea firmar digitalmente todas las sesiones grabadas si selecciona un certificado existente o crea un certificado autofirmado. Esto vale la pena si planea usar la herramienta para fines de auditoría o de responsabilidad. En la ficha Users, puede especificar los usuarios cuyas sesiones se deben grabar o no.
Con todo ello, RecordTS puede ser una herramienta de inestimable valor para la seguridad y la auditaría, y sus usos pueden ser mucho más amplios, como por ejemplo, permitir grabar una presentación sobre procedimientos. Para mí, es una adición de gran utilidad para mi cuadro de herramientas.

Precio: RecordTS Remote Desktop Edition está disponible a partir de 495,00 dólares. RecordTS Terminal Services Edition disponible a partir de 995,00 dólares.

Supervisión de host
Monitor de host avanzado
www.ks-soft.net
Si alguna vez se encuentra en una posición de ofrecer soporte técnico operativo para una infraestructura crítica de misión, hay una ayuda en la sombra sueño de la que no puede prescindir: un monitor de host bueno y confiable. Aunque disponga de un sólido conjunto de hardware y una estable y confiable pila de aplicaciones sin ningún punto de error, aún podría beneficiarse de un monitor de host con todas las características que le indicará cuándo tiene que activarse dicho sistema redundante.
El monitor de host avanzado, de KS-Soft, ofrece 58 métodos de prueba diferentes y 30 métodos de alerta. Puede comprobar dichos elementos como información de proceso, sesiones de usuario, carga media, memoria, etc. La aplicación ofrece pruebas específicas de Windows®, pruebas de Linux/UNIX y comprobaciones independientes de plataforma. A diferencia de las pruebas de Windows, las pruebas de Linux/UNIX requieren la instalación de un agente de supervisión remoto en el cliente.
También hay una prueba de supervisión de Instrumental de administración de Windows (WMI). Puede buscar la consulta correcta con el explorador WMI incrustado, que le permite desplazarse con facilidad y elegir el elemento apropiado, así como ejecutar la consulta para comprobar que le obtendrá los datos que necesita.
El monitor de host avanzado también dispone de varias pruebas relacionadas con la base de datos como, por ejemplo, una prueba de consulta de ODBC, que comprueba la disponibilidad de un origen de datos ODBC, ejecuta una consulta y comprueba el resultado frente a un valor conocido. También puede comprobar la capacidad de un host para aceptar las sesiones entrantes para servidores de base de datos SQL Server™, MySQL, Oracle, Postgres, Sybase e Interbase.
Hay varias pruebas relacionadas con disco y archivos que le ayudarán a controlar el espacio disponible, las cuotas, la disponibilidad de carpetas o archivos y la disponibilidad de recursos compartidos de UNC. Además, obtiene las pruebas relacionadas con la red estándar: comprobaciones generales de TCP/UDP, pruebas de correo (para SMTP, POP3 e IMAP), comprobaciones de transmisión de correo, pruebas de tiempo y contenido HTTP, etc. También puede crear interdependencias de prueba de monitor para organizar sus comprobaciones en cascada, lo cual es una opción de gran utilidad. Las pruebas también pueden programarse en lo que se denominan programaciones regulares e irregulares, permitiéndole ser bastante granular con sus patrones de prueba.
Entre los métodos de alerta se incluyen el envío de mensajes a SMS, ICQ, correo electrónico, un registro de eventos o una ventana emergente. También pueden desencadenar otros eventos, como por ejemplo, el inicio o la detención de servicios, el rearranque del equipo o la ejecución de un programa externo.
Con las ediciones Professional y Enterprise del monitor de host avanzado, obtiene las herramientas IP KS-Soft, un conjunto de 19 utilidades de red relacionadas con TCP/IP que incluye escáneres de puerto/protocolo y un observador de captura SNMP, que le permite recibir y procesar mensajes de captura SNMP. Además, ambas versiones tienen un analizador de registros y un componente de informes que le permiten realizar una tendencia de los datos de supervisión históricos para sus informes de tiempo de actividad y revisiones de análisis de rendimiento.
La propia interfaz ofrece una excelente manera de obtener una introducción rápida de varias pruebas de manera simultánea. Con ella, se pueden detectar con facilidad problemas en sus hosts supervisados.
Precio: 599,00 dólares para la edición Enterprise. 275,00 dólares para la edición Professional.

Liberador de espacio en disco
WinDirStat
www.windirstat.info
De manera muy parecida a su casa o apartamento, las ubicaciones de almacenamiento de archivos tienden a llenarse con el tiempo con el material que tuvo un propósito una vez, pero que ahora sólo ocupa un espacio valioso. Una pequeña limpieza primaveral puede hacer mucho pero, a diferencia de la casa, una estructura de árbol de directorios no le da referencias visuales obvias en cuanto a por dónde empezar a quitar el desorden. Afortunadamente, hay una estupenda herramienta de visualización que puede ayudarle a ver qué archivos ocupan espacio en el entorno.
El programa GPL WinDirStat, una herramienta basada en Windows e inspirada por kdirstat de Linux KDE, le muestra los archivos en la unidad seleccionada como un conjunto de diferentes cuadrados de colores. El tamaño de los cuadrados representa el tamaño de los archivos, lo que le permite reconocer con facilidad esos armatostes innecesarios de archivos ISO o ZIP antiguos.
Una vez seleccionada la unidad de disco local (o un conjunto de unidades de disco locales), el programa examina el árbol de directorios, creando una asignación en memoria de los archivos. A continuación, muestra la visualización en el panel inferior de la GUI. Al hacer clic en un cuadrado con color del panel inferior, el panel superior similar al Explorador de Windows se desplazará a la ubicación del archivo. Ese panel superior le proporciona útiles estadísticas, tales como el tamaño del archivo, la fecha de su última modificación y otros atributos. Además, se ve qué porcentaje del subárbol ocupa ese archivo.
Un toque fantástico, los colores son específicos de los tipos de archivos y al hacer clic en un tipo de archivo detectado en la parte superior derecha, se resaltarán todos los archivos de ese tipo en el panel inferior. Esto es muy práctico, por ejemplo, cuando tiene que identificar todos los MP3 ocultos que sus usuarios tienen en el servidor de archivos. También puede consultar qué porcentaje de bytes componen esos archivos en la partición.
Precio: descarga gratuita.

Reseña de libro
Enemy at the Water Cooler
syngress.oreilly.com
Casi todas las empresas se tienen que conectar a Internet y la mayoría conoce los peligros que se presentan por los intentos casi constantes del exterior para comprometer la seguridad de los puntos de la conexión que dividen el "exterior" del "interior" de su infraestructura de información. Sin embargo, muchas empresas pasan por alto una amenaza potencialmente más malintencionada que existe dentro de la organización. El poder de estas denominadas amenazas internas está muy bien ilustrado en el libro Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasure por Brian Contos (Syngress, 2006).
Contos ofrece historias reales de ataques pasados y la repercusión que tuvieron en las compañías implicadas. Reclama que la seguridad es un proceso continuo que consta de una "fusión de personas, procesos y tecnología." Con este libro, intenta ilustrar el poder potencial de las soluciones de software de administración de seguridad empresarial (ESM) para mitigar las amenazas internas.
Como Director de Seguridad de ArcSight, Contos depende en gran medida de la presentación de la propia solución de software de ESM de la compañía, pero eso no quita mérito al valor general. El libro carece de detalles técnicos profundos pero con él se obtiene una buena idea de dónde debe mejorar su propio proceso de seguridad en su organización viendo dónde han cometido errores las demás organizaciones y comprendiendo qué puede hacer una solución de ESM implementada de manera eficaz para reducir la exposición a un ataque interno.
En el capítulo de información previa, "Cyber Crime and Cyber Criminals 101", Contos ofrece una introducción de algunos de los diferentes tipos de atacantes de los que debe estar consciente y las motivaciones de éstos. También se obtiene una breve sinopsis de algunas de sus técnicas, tales como los desbordamientos de búfer, el empaquetado de códigos y las amenazas de Warhol.
El capítulo siguiente ahonda con mayor detenimiento en las amenazas internas, incluyendo las maneras en las que una persona interna puede dañar una compañía, el concepto de la administración del riesgo y las maneras de tratar las amenazas desde un punto de vista técnico. el punto de vista técnico ofrece una breve introducción de privilegio mínimo, autenticación fuerte, control de acceso y administración y de detección de incidentes. Esto prepara el terreno para un análisis de las soluciones de software de ESM. De nuevo, el libro tiende a tratar sólo con el producto de ArcSight, pero el desglose de la característica principal se puede aplicar a cualquier sistema.
El libro ofrece varios escenarios; desde una sección transversal de sectores y entornos, detallando los tipos diferentes de amenazas internas y cómo se detectaron (y a veces mitigaron). Estos casos prácticos pueden arrojar algo de luz sobre algunas de sus propias prácticas empresariales y quizá ofrecer soluciones para reducir el riesgo de ataques internos en su entorno.
Precio: $49.95.

Escriba a Caja de herramientas
Si tiene una herramienta o utilidad favorita que le gustaría que aparezca aquí, escriba al autor en la dirección tntools@microsoft.com.

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.


 Preguntas y respuestas sobre SQL&amp;: Estudio de cl&#250;ster, bloqueos misteriosos, la cuenta de SA, etc.
Preguntas y respuestas sobre SQL&
Estudio de clúster, bloqueos misteriosos, la cuenta de SA, etc.
Editado por Nancy Michell

P Necesito comprender mejor cómo funciona el clúster. Nuestro entorno constará de Windows Server® 2003 de 64 bits que ejecuta SQL Server™ 2005, una granja de servidores web (una implementación de escalado del servidor de informes) con SQL Server Reporting Services (SSRS), un servidor de catálogo TempDB de SSRS y SQL Server que inserta datos desde una base de datos de terceros mediante un servidor vinculado y almacenará los datos para SSRS.
Deseamos un clúster tipo activo/activo/pasivo de 3 nodos. El nodo 1 sería activo y almacenaría los datos obtenidos de la base de datos de terceros. El nodo 2 sería activo y almacenaría el catálogo de SSRS. El nodo 3 sería pasivo y sería una conmutación por error para el nodo 1 o el nodo 2. ¿Podrían ayudarme?

R Lamentablemente, demasiadas personas se equivocan por los términos activo/activo y activo/pasivo con respecto al clúster de SQL Server. Creen que el clúster de SQL puede admitir el "escalado" de una base de datos o sesión SQL a través de varios servidores. Eso no es el caso. En SQL Server, no existe una base de datos o sesión tipo activo/activo. Una "sesión" es una instalación de SQL Server con las bases de datos correspondientes. Nuestro clúster según la sesión de SQL Server es activo (1) a pasivo (n) siempre (tenga en cuenta que el valor n puede ser cualquier cifra entre 1 y 7, en función de la versión de SQL Server). Por eso se denomina clúster de conmutación por error.
Una vez que se haya comprendido esto, las personas pueden empezar a pensar en instalar varias sesiones de clúster de conmutación por error en un conjunto de nodos. Por ejemplo, tres servidores físicos, todos ellos usando discos compartidos, podrían tener una sesión activa de forma predeterminada en el Nodo 1 y una segunda sesión activa de forma predeterminada en el Nodo 2, y ambas pueden conmutar por error al Nodo 3. Las sesiones son completamente independientes; no comparten datos ni son de tipo activo/activo. Ambas son de tipo activo/pasivo y ambas comparten la misma sesión de conmutación por error. Si ambas sesiones conmutan por error al Nodo 3, entonces el desafío con el tiempo es saber si el Nodo 3 soportará la carga. Por diseño, la conmutación por error está pensada para depender del poder de procesamiento igual para la conmutación por error. Si el pico de carga requiere dos nodos para procesar bajo un funcionamiento normal, es improbable que el Nodo 3 sobreviviera bajo el pico de carga normalmente asignado a dos nodos.
Dicho eso, dado el costo relativo de hardware capaz de ejecutar un clúster, entendemos cómo las personas sopesarían la probabilidad de que ambos nodos principales tengan un error simultáneamente y que fuercen toda la carga a un nodo. Teniendo eso en cuenta, pueden que tomen la decisión empresarial de asumir el riesgo en lugar de adquirir la capacidad de conmutación por error del 100%.
Afortunadamente, hay buenas noticias: SQL Server 2005 ofrece muchas más opciones para la alta disponibilidad (HA), incluidas alternativas que pueden conmutar por error más rápidamente que un clúster e incluso pueden significar copias duplicadas de datos (el clúster depende de una SAN única). Entre las opciones se incluyen la creación de reflejos, la réplica de punto a punto, etc. Con esas nuevas alternativas, tenemos muchas más opciones para satisfacer todo tipo de necesidades, incluidas algunas que pueden combinar varias características de alta disponibilidad.
El Asistente Microsoft® Cluster Configuration Validation (ClusPrep), ahora disponible para la descarga, reemplaza lo que solía ser la prueba de la lista de certificación de hardware (HCL), que podría llevar meses para validar una configuración completa para considerarla "admisible" bajo clúster. Esto coloca la herramienta de validación de hardware en manos del administrador de la base de datos, reduciendo el costo (tanto monetario como de tiempo) de obtener el hardware certificado colocado. Incluso puede hacer posible validar e implementar hardware heterogéneo dentro de un conjunto de nodos de clúster.

P Parece que un procedimiento de eliminación en uno de mis equipos se bloquea después de 12 horas. No está bloqueado. Mirando al plan de consulta más lento revela un desencadenador que se ejecuta durante 87.327 segundos, por lo que supongo que el procedimiento se bloquea en ese desencadenador. ¿Cómo puedo consultar exactamente qué instrucción se bloquea?

R Es bastante posible que un bucle dentro del desencadenador no sale por una variedad de motivos. Si se bloquea durante mucho tiempo y desea ver qué instrucción se está ejecutando, ejecute el código en la figura 1. Le indicará qué instrucción se ejecuta actualmente y ésta debería ser la que hace que el equipo no responda.
Figure 1 Buscar la instrucción en ejecución (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

P Necesito admitir la réplica transaccional a través de un firewall. El publicador y el distribuidor se encuentran fuera del firewall y el suscriptor está dentro. El suscriptor se define para escuchar en 1433 y éstos son mis nombres de equipo: Publicador: PUBMACHINE, Distribuidor: DISTMACHINE, Suscriptor: SUBMACHINE. ¿Qué puertos tengo que abrir para permitir la instantánea inicial y la publicación por inserción para ser correcta?

R Si usa una suscripción de inserción, abrir el puerto de SQL Server (1433 en su caso) debería ser suficiente, ya que el agente de distribución se ejecutará en el equipo del distribuidor (fuera del firewall) y probablemente tendrá acceso local a los archivos de instantánea generados por el agente de instantánea. Pero si usa una suscripción de extracción, el agente de distribución que se ejecuta en el equipo del suscriptor necesitará acceso a los archivos de instantánea a través del firewall de alguna manera. Aquí están las opciones que puede tener en cuenta.
Suponiendo que los archivos de instantánea ya son accesibles desde un recurso de archivos compartidos fuera del firewall, puede abrir los puertos de archivos compartidos de Windows® a través del firewall de manera que el agente de distribución que se ejecuta dentro del firewall pueda tener acceso a los archivos de instantánea que se encuentran fuera (aunque tenga cuidado con las implicaciones de seguridad que esto puede tener para otras partes de su infraestructura). Tenga en cuenta que si configuró una ruta de acceso local como la ubicación de instantánea predeterminada (valor predeterminado de SSMS), es posible que tenga que usar la opción /AltSnapshotFolder del agente de distribución para invalidar la ubicación de recogida del archivo de instantánea.
También puede configurar la réplica para usar FTP para transferir archivos de instantánea (y necesitaría abrir el puerto 21 para eso).

P Deseo saber si hay inconvenientes en deshabilitar la cuenta de SA en SQL Server 2005 y si esta acción agrega un verdadero valor de seguridad. ¿Hay algún artículo sobre esta pregunta?

R En una instalación nueva de SQL Server 2005 cuando el modo mixto no está habilitado, la cuenta de SA está deshabilitada de forma predeterminada y se genera una contraseña aleatoria para ella. También puede deshabilitarla usted mismo. No hay ningún artículo sobre ello, pero la deshabilitación y el cambio de nombre de inicio de sesión se trata en un documento de recomendaciones.
Si desea protegerse de intentos para interrumpir la cuenta de SA, también puede cambiar su nombre. Sólo recuerde que, si habilita una cuenta deshabilitada, debería establecer una nueva contraseña para ella.
Para responder a su pregunta acerca de si esto ofrece seguridad verdadera, recuerde que la seguridad agregada de deshabilitar la cuenta procede del hecho de que adivinar la contraseña no tendría sentido mientras la cuenta está deshabilitada. No importa el tiempo del que disponga el pirata informático o virus, un ataque por fuerza bruta contra una cuenta bloqueada no tendrá éxito. El cambio de nombre o la deshabilitación de SA interrumpirá las aplicaciones que son dependientes de la cuenta de SA para su conectividad. De todos modos, buscar y, a continuación, corregir o eliminar estas aplicaciones debe considerarse como una prioridad. Como se indicó, la cuenta no se puede usar para conectarse a la base de datos hasta que se vuelva a habilitar. Además, debido a que se produce un error antes en el proceso de autenticación, un intento con error supondrá un impacto inferior en el sistema atacado.

P Una de mis mayores bases de datos de procesamiento de transacciones en línea (OLTP) tiene un archivo de registro que es dos veces mayor al tamaño del archivo de datos. He intentado usar los comandos siguientes para reducir el archivo de registro a un tamaño razonable, pero tengo que reducirlo aún más:
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

R Debería cambiar su base de datos de copia de seguridad a una instrucción de registro de copia de seguridad. Otra alternativa podría ser colocar su base de datos en el modo sencillo de recuperación y enviar la instrucción shrinkfile. Después de que se finalice la reducción del registro, establezca la base de datos a su modelo de recuperación anterior y realice una copia de seguridad de la base de datos. Si todavía no se reduce, compruebe que no hay transacciones abiertas (use dbcc opentran). El artículo siguiente de Knowledge Base ofrece más información: support.microsoft.com/kb/907511.

P Si la conmutación por error ocurre durante un trabajo programado del agente de SQL Server, ¿qué pasa con ese trabajo después de la conmutación por error? ¿Tengo que reiniciarlo manualmente?

R Sí, tendrá que iniciarlo manualmente si no tiene algún otro proceso establecido. Si no desea tener que reiniciar trabajos manualmente, podría escribir un script que actualice una tabla tras la finalización del trabajo. Si el valor es igual a 1, el trabajo se ejecutó; cualquier otro valor indica que el trabajo no se completó y un segundo trabajo emitirá posteriormente el comando de inicio. Por tanto, si bien el trabajo se tiene que volver a ejecutar si se produce una conmutación por error durante su paso, al escribir un script se puede aliviar parte de la preocupación de esos trabajos cruciales, durante la noche que se deben completar antes del siguiente día hábil.
Sugerencia: Actualización y DBCC UPDATEUSAGE
¿Está actualizando desde SQL Server 2000 a SQL Server 2005?
De ser así, asegúrese de que usa el derecho DBCC UPDATEUSAGE después de que se actualicen sus bases de datos.
DBCC UPDATEUSAGE notifica y corrige las inexactitudes en los recuentos de página y de fila en las vistas de catálogo. Estas inexactitudes se deben corregir porque pueden hacer que el procedimiento almacenado del sistema sp_spaceused devuelva informes de uso de espacio incorrecto. En SQL Server 2005, estos valores siempre se mantienen correctamente, por lo que estas bases de datos nunca deberían experimentar recuentos incorrectos. Sin embargo, las bases de datos actualizadas a SQL Server 2005 pueden contener recuentos no válidos, por lo que debería ejecutar DBCC UPDATEUSAGE después de realizar la actualización.
Aquí describimos cómo funciona DBCC UPDATEUSAGE. Corrige las filas, las páginas usadas, las páginas reservadas, las páginas hoja y los recuentos de página de datos para cada partición de una tabla o índice. Si no hay inexactitudes en las tablas de sistema, DBCC UPDATEUSAGE no devuelve datos. Si se encuentran y se corrigen inexactitudes, y no ha usado WITH NO_INFOMSGS, DBCC UPDATEUSAGE devuelve las filas y las columnas que se están actualizando en las tablas del sistema.
DBCC UPDATEUSAGE también se puede usar para sincronizar contadores de espacio-uso. Debido a que DBCC UPDATEUSAGE puede tardar algo de tiempo en ejecutarse en tablas o bases de datos de gran tamaño, normalmente sólo debería usarse cuando sospeche que sp_spaceused devuelve valores incorrectos. Tenga en cuenta que sp_spaceused acepta un parámetro opcional para ejecutar DBCC UPDATEUSAGE antes de devolver la información de espacio para la tabla o el índice.
DBCC CHECKDB se mejoró en SQL Server 2005 para detectar cuando los recuentos de página o fila pasa a ser negativo. Cuando se detectan valores negativos, DBCC CHECKDB dará como resultado una advertencia y una recomendación para ejecutar DBCC UPDATEUSAGE para tratar el problema. Aunque pueda parecer como si la actualización de la base de datos a SQL Server 2005 causara este problema, asegúrese de que los números no válidos existían antes del procedimiento de actualización.
Como ejemplo, explicamos aquí cómo se actualizarían los recuentos de página o fila, o ambas, para todos los objetos de la base de datos actual. El comando siguiente especifica 0 para el nombre de la base de datos y DBCC UPDATEUSAGE notifica información actualizada para la base de datos actual:
DBCC UPDATEUSAGE (0);
GO
Para actualizar los recuentos de página o fila, o ambas, por ejemplo, AdventureWorks, y también para suprimir los mensajes de información, ejecutaría un comando similar al siguiente, que especifica AdventureWorks como el nombre de base de datos y, a continuación, suprime todos los mensajes de información:
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
Para obtener más información, busque DBCC UpdateUsage en los libros en línea de SQL Server.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Noticias destacadas sobre utilidades: SMSMap
Noticias destacadas sobre utilidades
SMSMap
Jeff Tondt
Descargar el código de este artículo: UtilitySpotlight2007_07.exe (2477KB)

Una imagen vale más que mil palabras. Este conocido refrán se refiere a la idea de que las historias complejas se pueden contar sólo con una única imagen, o bien que una imagen puede tener un mayor impacto que incluso una cantidad substancial de texto. También caracteriza acertadamente los objetivos de la visualización, donde grandes cantidades de datos se deben absorber rápidamente.
Para un fanático de System Management Server (SMS) como yo, la visión de toda la jerarquía de SMS en una imagen me ayuda a comprender cómo está dispuesta mi infraestructura. Quizá podría usar esa imagen para mostrar el antes y el después de un plan de migración de SMS para la administración. En determinados casos de solución de problemas, dicho diagrama podría ser muy útil para encontrar una solución o al menos para obtener la ayuda de otras personas. Y, por supuesto, como administrador de SMS responsable, necesita documentar su jerarquía del sistema para todos los demás tipos de razones.

Cómo obtener la imagen
No se trata de que no pueda dibujar dicho diagrama usted mismo. Ciertamente puede subirse las mangas, dibujar manualmente la jerarquía de SMS y documentar la configuración del sitio a mano. Si tiene Microsoft® Operations Manager (MOM) supervisando los servidores de SMS, puede hacer que realice el diagrama de la jerarquía, aunque debería decir que a MOM no le gusta especialmente las imágenes y no documenta la configuración del sitio. Es posible que haya otros métodos o herramientas prácticas, pero todavía no he encontrado algo que cree adecuadamente imágenes bonitas y ayude a documentar la configuración del sitio, por lo menos que sea de mi agrado.
Por lo tanto, decidí crear una herramienta propia y así nació SMSMap 1.0. SMSMap es una aplicación de Visual Basic® .NET que usa las bibliotecas administradas de SMS en el SDK de SMS y automatiza Microsoft Visio® mediante COM. La utilidad consulta un servidor del sitio de SMS dirigido y, a continuación, crea un atractivo diagrama de Visio y exporta la configuración del sitio a un archivo XML. Se seleccionó XML porque es la manera más compatible de documentar la configuración del sitio. Elegí mostrar las funciones de SMS también, no sólo los servidores físicos relacionados con los demás servidores SMS. Esto permite manipular el diagrama mediante niveles de Visio para ver la jerarquía de SMS desde varios puntos de vista.
Figura 1 Formato radial
Figura 1 Formato radial
Actualmente, el programa permite seleccionar seis formatos diferentes para el diagrama de Visio. Por ejemplo, la figura 1 muestra una jerarquía de SMS muy sencilla usando el formato radial, mientras que la figura 2 muestra la misma jerarquía usando el formato de diagrama de flujo. La utilidad funciona bastante bien con jerarquías mucho más grandes, pero quería mantener las cosas sencillas aquí.
Figura 2 Formato de diagrama de flujo
Figura 2 Formato de diagrama de flujo
En algún punto, SMSMap probablemente evolucionará para documentar toda la configuración del sitio. Actualmente, documenta únicamente las funciones del sitio SMS y todos los límites. Con un poco de esfuerzo, se podrían exportar muchas más configuraciones de sitio en el archivo XML.

Uso de SMSMap
El código fuente y los archivos de instalación para SMSMap están disponibles en el TechNet Magazine http://www.technetmagazine.com/code07.aspx. Para instalarlo, basta con ejecutar SMSMapSetup.msi, que le guiará por el proceso de instalación. Recuerde, SMSMap usa Visio, por lo que también debe tenerlo instalado. Después de la instalación, ejecute C:\Archivos de programa\Microsoft\smsmap\smsmap.exe (a menos que lo haya instalado en una ubicación diferente de la predeterminada).
Puede ejecutar SMSMap desde cualquier equipo; no es necesario ejecutarlo desde el servidor del sitio (y es improbable que muchos servidores de sitio SMS tengan Visio instalado). Escriba el nombre de servidor de sitio SMS en el que desea que se origine la consulta. Éste puede ser el sitio central si desea consultar toda la jerarquía o puede ser cualquier servidor de sitio principal secundario, pero en ese caso sólo obtiene la jerarquía de ese sitio principal secundario hacia abajo. A continuación, escriba la cuenta con el permiso para consultar SMS usando el formato dominio\nombre de usuario y, a continuación, la contraseña para dicha cuenta. (La contraseña no se mostrará, por lo que puede ejecutar esto delante de otras personas).
Seis botones de radio le permiten seleccionar el diseño tiene la opción de admitir o impedir que las funciones de SMS aparezcan en el dibujo. Estas casillas se encuentran en la ficha Options. Al presionar el botón Draw, se inicia la utilidad. En primer lugar, realiza una comprobación para ver si Visio está disponible y, a continuación, consulta el servidor de sitio principal de SMS especificado y agrega los objetos al diagrama de Visio. El diagrama de Visio puede parecer poco estético mientras SMSMap inserta los objetos, pero al final del proceso la utilidad los organiza en el formato que especificó al principio.
Estudio más profundo
Ahora ha visto por qué y cómo documentar su jerarquía de SMS usando SMSMap. Para los que deseen flexionar sus músculos de desarrollador, echemos un vistazo más de cerca a cómo funciona la utilidad.
SMSMap usa las interfaces de servidor de sitio de SMS administradas para recopilar la información de SMS y los ensamblados de interoperabilidad principal de Visio para generar un diagrama de Visio que ordena todas las formas necesarias. El SDK de SMS 2003 versión 3.1 contiene la versión más reciente de las interfaces de servidor de sitio de SMS administradas. Este conjunto de interfaces administradas permite conectar y configurar un servidor de sitio de SMS a través de cualquier lenguaje o aplicación habilitada con Microsoft .NET Framework.
Estas interfaces usan el espacio de nombres de System.Management para interactuar con un proveedor de SMS a través del Instrumental de administración de Windows® (WMI). Para usar las interfaces, debe desarrollar su aplicación con un lenguaje compatible con .NET (por ejemplo, C#, Visual Basic .NET, etc.) y hacer referencia al archivo Microsoft.SystemsManagementServer.Automation.dll que el ensamblado de .NET suministró con el SDK de SMS.
Las clases de administración .NET limpian muchas de las idiosincrasias del modelo de objetos WMI para presentar un modelo coherente y orientado a objetos. Las tareas básicas de la conexión WMI, la enumeración de objetos, la ejecución del método, la eliminación de objetos, la recuperación de objetos y la captura de eventos se pueden obtener a través de las clases de administración .NET.

Ensamblados de interoperabilidad principal de Visio
Un ensamblado de interoperabilidad principal permite usar el código administrado para controlar aplicaciones COM como Visio mediante programación. Los ensamblados de interoperabilidad principal de Visio permiten integrar y ampliar la funcionalidad de Visio en las aplicaciones administradas.
Si ya tiene .NET Framework instalado en el equipo, cuando instale Visio posteriormente, el instalador agregará los ensamblados de interoperabilidad principal de Visio en la memoria caché de ensamblados global (GAC) del equipo. Puede agregar una referencia a los ensamblados de interoperabilidad principal de Visio desde las aplicaciones administradas.
Después de agregar la referencia al proyecto, puede comenzar a trabajar con objetos de Visio desde la aplicación administrada. Visio tiene un amplio modelo de objetos que ofrece un conjunto de clases, interfaces y enumeraciones para que pueda crear diagramas mediante programación.

Flujo de programa
Ahora que he descrito las interfaces principales del componente para Visio y SMS, explicaré el flujo de la propia utilidad.
El primer paso cuando se usan las interfaces administradas es conectar al proveedor de SMS. Esto se puede lograr si se crea una nueva copia de la clase SMSProvider. Internamente, esta clase buscará el proveedor de SMS para el servidor de sitio especificado y se conectará a él con un conjunto determinado de credenciales. Si el proveedor se encuentra en el equipo local, se usarán las credenciales actuales de inicio de sesión en lugar de las credenciales suministradas al conectarse al proveedor. Aunque pueda ejecutar SMSMap en el servidor de SMS, recomiendo ejecutarlo en una estación de trabajo independiente que tiene Visio instalado. La mayoría de los servidores del sitio de SMS no tienen Visio instalado por razones obvias.
Cuando obtiene acceso a los datos en el sitio de SMS a través de la clase SMSProvider, los derechos de seguridad se tratan como si usara la Consola del administrador de SMS. Esto significa, por ejemplo, que si intenta definir la configuración para un servidor de sitio a través de un SMSProvider, la cuenta con la que se conecta al proveedor debe tener el mismo conjunto de derechos como si usara la consola del administrador.
La clase SMSProvider suministra un método GetSiteSettings que permite obtener la configuración de sitio para el sitio actual (al que pertenece el proveedor) o para cualquier sitio con un código de sitio específico. El fragmento de código en la figura 3 muestra cómo se conecta SMSMap al proveedor para el servidor del sitio dirigido. Se espera que las credenciales de usuario se pasen en el formato Dominio\Usuario. Puede especificar también "." para indicar el equipo actual. Además, la figura 3 incluye código que ayuda a mostrar los resultados en la IU y para el registro.
Figure 3 Fragmento de GetSiteSettings (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
El siguiente paso es configurar el archivo XML para la recopilación y el registro de la información de SMS para el servidor del sitio dirigido, tal como se muestra en la figura 4.
Figure 4 Creación del archivo XML (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
A continuación, el sitio dirigido debe dibujarse en el diagrama de Visio y actualizarse en la IU y el registro, tal como se puede ver en la figura 5.
Figure 5 Dibujo del sitio en Visio (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
Para atravesar toda la jerarquía bajo el sitio dirigido, se ejecuta el mismo código básico descrito anteriormente que consulta SMS y dibuja en Visio. Ésta es una función denominada Level que se invoca de manera recursiva para asegurarse de que se consultan todos los sitios secundarios, independientemente de lo grande que sea la jerarquía. La función Level recopila la información del sitio de SMS y la registra en XML, en la IU y en el registro para cada sitio secundario bajo el sitio dirigido. Por último, la figura 6 muestra cómo el formato se aplica al diagrama de Visio usando el formato seleccionado cuando se inicia la utilidad. A continuación, se cierran los archivos de registro y XML.
Figure 6 Puntos finales (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

Sólo un comienzo
Por supuesto, esto es sólo un comienzo y hay muchas posibilidades para la mejora. Los puntos de administración de dispositivos necesitan investigarse puesto que no los veo en el SDK. Se podrían agregar varias configuraciones de sitio adicionales para documentar completamente un sitio. Quizá se tiene que realizar algo más de trabajo en la adición de una variedad mayor de la configuración de diseño de Visio para ayudar a mejorar el aspecto de las jerarquías pequeñas y grandes. Cada de tipo diseño plantea sus propias dificultades al tratar de crear visualizaciones efectivas. Y, por supuesto, la adición de compatibilidad con System Center Configuration Manager 2007 es un próximo paso muy importante. Sin embargo, incluso esta primera versión de SMSMap puede ayudar a los administradores de SMS a visualizar toda la imagen y probar algunos escenarios hipotéticos con la transparencia y los niveles de Visio.
Si descarga el código fuente, puede ampliar la utilidad para satisfacer sus propias necesidades. Probé SMSMap en Windows XP SP2 con Visio 2003 y Windows Vista™ Enterprise con Visio 2007. Si tiene sugerencias sobre cómo mejorar esta utilidad, envíeme un mensaje de correo electrónico a la dirección jeff.tondt@microsoft.com.

Jeff Tondt es un consultor jefe II de Servicios de consultoría de Microsoft (Microsoft Consulting Services, MCS). Se dedica a las áreas de la administración de sistemas, la automatización y la administración de revisiones. Es experto en asuntos de SMS y puede ponerse en contacto con él en la dirección jeff.tondt@microsoft.com.


 Funcionamiento: Soluci&#243;n de problemas de errores de RPC
Funcionamiento
Solución de problemas de errores de RPC
Zubair Alexander

Si ha trabajado con plataformas Windows Server a lo largo de los años, existe la posibilidad de que haya visto errores de llamadas a procedimiento remoto (RPC) una u otra vez. Se indica que el servidor RPC no está disponible, o que no hay más extremos disponibles o se ofrecen algunas otras advertencias enigmáticas. Si se confunde con estos mensajes, siga leyendo. Analizaré
algunos errores comunes, distintas técnicas que puede usar para identificar los errores de RPC que surgen y trataré algunas soluciones para resolver problemas específicos. Pero antes de hablar acerca de errores de RPC específicos y sus soluciones, hablemos un poco sobre la terminología RPC.

¿Qué es RPC?
RPC es un método de comunicación entre procesos (IPC) que los clientes y servidores usan para comunicarse entre sí. Simplemente, RPC lo usan los programas, normalmente en un equipo cliente, para ejecutar un programa en un equipo servidor. Por ejemplo, los clientes Microsoft® Outlook® se comunican con Microsoft Exchange Server mediante RPC. El equipo cliente envía un mensaje al equipo servidor con ciertos argumentos. El servidor responde al cliente con un mensaje que contiene los resultados del programa ejecutado.
En este proceso es esencial el extremo, el nombre, el puerto o el grupo de puertos de un equipo supervisado por un servidor para solicitudes entrantes de clientes. Más concretamente, se trata de una dirección específica de red de un proceso de servidor que se usa para RPC.
El Endpoint Mapper, que forma parte del subsistema RPC, es responsable de responder a las solicitudes de los clientes para resolver extremos dinámicos. En algunas situaciones, el Endpoint Mapper también es responsable de asignar dinámicamente extremos a los servidores.
Otro componente RPC importante es el servicio de ubicación, que mantiene una lista de servicios y servidores RPC en la red. Un cliente Windows® se conecta al controlador de dominio a través de puertos que usan el bloque de mensaje de servidor (SMB) (TCP 139 y 445) y buscan servicios o servidores RPC a través del servicio de ubicación.
La mayoría de los servicios integrados de Windows se comunican entre sí mediante RPC. Por ejemplo, los servicios de certificados, DCOM, FRS, MSMQ, MAPI y el servicio de réplica de Active Directory® usan RPC para la comunicación. Por lo tanto, si el servicio RPC no funciona correctamente en una red, puede experimentar muchos problemas de comunicación.

Errores de RPC
Ahora examinemos algunos de los errores que puede encontrar cuando falla el servicio RPC. (Esta no constituye en absoluto una lista completa).
Cuando falla el servicio de réplica de archivos (FRS), es posible que se trata del temido error "RPC no disponible". Si intenta asignar una unidad de disco, es posible que reciba el error "Acceso denegado". Cuando usa usuarios y equipos de Active Directory, es posible que aparezca el error que indica, "El dominio especificado no existe o no se pudo poner en contacto con él". Al iniciar una sesión en el dominio, puede obtener un error que afirma, "El sistema no puede iniciar sesión en este dominio porque falta la cuenta de equipo del sistema en su dominio principal o la contraseña en esa cuenta es incorrecta".
Cuando los clientes de Microsoft Outlook intentan comunicarse con Exchange Server, los errores de RPC pueden mostrar al cliente un error engañoso tal como, "Su información de inicio de sesión es incorrecta" u "Outlook no pudo iniciar sesión".
Además de estos errores, cuando el servicio RPC no está disponible, puede experimentar otros problemas. Por ejemplo, quizás no pueda examinar el dominio en Mis sitios de red o que pueda abrir el complemento Directiva de grupo.
Estas son sólo algunas de las ocasiones en las que quizás no esperaba que RPC genere problemas. Hay muchas más situaciones, y cuando esté trabajando con procesos remotos, los problemas de RPC pueden ser la raíz de sus dificultades. Así que, ¿cómo lo sabe con seguridad y, lo que es más importante, cómo encuentra el error preciso? Lo podemos averiguar.

Solución de problemas
Si sospecha que tiene problemas con el servicio RPC, hay varias herramientas que puede usar para diagnosticar los problemas.
Una opción es la herramienta Repadmin. Este programa suele usarse para supervisar y solucionar problemas de réplica de Active Directory, pero también se puede usar para solucionar problemas con el Endpoint Mapper de RPC. Para ejecutarlo, en el símbolo del sistema, escriba repadmin /bind. Si tiene problemas de RPC, quizás vea un mensaje similar a éste: "No hay más extremos disponibles desde el Endpoint Mapper". Ese es su primer indicio que el problema está relacionado con RPC.
Otra opción es usar la herramienta de diagnóstico de controlador de dominio (DCDiag), un programa de línea de comandos que permite diagnosticar los problemas con controladores de dominio. Si ve el error "El estado es 1722: el servidor RPC no está disponible", sabe que tiene un problema de RPC que la herramienta de diagnóstico de controlador de dominio acaba de descubrir.
A veces, cuando usa Ntdsutil (una herramienta de línea de comandos usada para administrar Active Directory y realizar numerosas tareas de mantenimiento) es posible que surjan errores de RPC si intenta conectarse al servidor. Probablemente verá uno de los errores más comunes tal como "No hay más extremos disponibles desde el Endpoint Mapper". Nuevamente, este es un indicio que quizás haya problemas con el servicio RPC. La herramienta Gpotool, que comprueba la coherencia de los objetos de directiva de grupo en controladores de dominio, también le dará errores semejantes si RPC es el responsable.
El registro Dcpromo.log, que se genera cuando promueve Windows 2000 Server o Windows Server® 2003 como controlador de dominio mediante la herramienta Dcpromo, también puede revelar problemas con RPC. Por ejemplo, si la promoción falla, examine el registro. Se encuentra en la carpeta %windir%\debug. Los errores enumerados indican algo como que el servicio de directorio falló al replicar la partición o falló al crear el objeto. Al final del mensaje habrá un código de error. Aquí se muestra un ejemplo del tipo de mensaje de error que quizás vea en Dcpromo.log:

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
Observe el código de error 1722, que ocurre cuatro veces en este mensaje e indica que el servidor RPC no está disponible. La figura 1 enumera algunos códigos de error y sus descripciones, pero encontrará muchos más en msdn2.microsoft.com/ms681386.
Figure 1 Códigos de error y sus descripciones (Close Figure 1)

Código de error | Descripción
58 | El servidor especificado no puede ejecutar la operación solicitada.
1721 | Recursos insuficientes para completar esta operación.
1722 | El servidor RPC no está disponible.
1723 | El servidor RPC está demasiado ocupado para completar esta operación.
1727 | Error en la llamada a procedimiento remoto y no se ha ejecutado.
1753 | No hay más extremos disponibles desde el Endpoint Mapper.

Resolución de errores de RPC
Ahora que ha visto cómo se pueden detectar algunos de los errores de RPC, analicemos algunas de las soluciones.
Los clientes de Microsoft se conectan al Endpoint Mapper de RPC en el puerto 135. A continuación, el Endpoint Mapper le dice al cliente en qué puerto se busca un servicio solicitado. Los números de puerto se asignan dinámicamente y pueden ser cualquier valor entre 1024 y 65.535. Cuando ve errores, tal como 1753, que le dicen que no hay más extremos disponibles desde el Endpoint Mapper, esto significa que el Endpoint Mapper de RPC no pudo usar un puerto mayor que 1024 para un servicio. Analizaré este tema con mayor profundidad más adelante.
Lo primero que debe hacer es comprobar el estado del servicio RPC en el servidor. Según el tipo de función de servidor, el servicio RPC y el servicio de ubicación de RPC deberían tener el estado que se muestra en la figura 2. Si cualquiera de los dos servicios no está configurado como se muestra en la figura, intente ajustar el estado, rearranque el servidor y, a continuación, realice una prueba para ver si se resuelve el problema.
Figure 2 Estado del servicio RPC (Close Figure 2)

Función de servidor | Servicio RPC | Servicio de ubicación de RPC
Windows Server 2003: controlador de dominio | Iniciado, Automático | Detenido, Manual
Windows Server 2003: servidor miembro | Iniciado, Automático | Detenido, Manual
Windows Server 2003: servidor independiente | Iniciado, Automático | Detenido, Manual
Windows 2000 Server: controlador de dominio | Iniciado, Automático | Detenido, Automático
Windows 2000 Server: servidor miembro | Iniciado, Automático | Iniciado, Manual
Windows 2000 Server: servidor independiente | Iniciado, Automático | Detenido, Manual
Compruebe que el cliente puede hacer ping correctamente al servidor que tiene problemas de conectividad. Por ejemplo, si tiene problemas para comunicarse con un servidor llamado DC1 cuya dirección IP es 192.168.1.200, use el siguiente comando en el símbolo del sistema para comprobar que el DNS resuelve correctamente el host DC1:
Ping –a 192.168.1.200
Asegúrese de usar el parámetro -a con la dirección IP, no con el nombre de host.
Si todo funciona bien, debería obtener una respuesta de DC1 semejante a la respuesta de ping de la figura 3. Observe que en vez de resolver simplemente la dirección IP 192.168.1.200, Ping también resolvió el nombre de host dc1.contoso.com. Esto confirma que esa resolución de nombres DNS funciona correctamente y resuelve el host dc1.contoso.com exactamente como se esperaba.
Figure 3 Respuesta del ping (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
También debe asegurar que el registro en su cliente Windows XP o Windows 2000 contiene por lo menos los cuatro ClientProtocols que se muestran en el panel derecho de la figura 4.
Figura 4 ClientProtocols de RPC mostrados en el Registro
Figura 4 ClientProtocols de RPC mostrados en el Registro
Si falta cualquiera de las entradas, agregue un nuevo valor de cadena con el nombre y tipo de datos que se muestran en la figura 4. De forma predeterminada, hay una quinta entrada llamada ncacn_nb_tcp, que se usa para identificar NetBIOS sobre TCP como la familia de protocolo para el extremo. Según la configuración, quizás no se incluya esa entrada en una lista bajo ClientProtocols; puede agregarla manualmente para ver si resuelve los errores de RPC.
Observe las claves incluidas en una lista bajo la carpeta Rpc en el panel izquierdo de la figura, concretamente ClientProtocols, NameService, NetBIOS y SecurityService. Si logra ver una clave llamada Internet que no tiene valores, intente quitar la clave y reiniciar el equipo. Quizás esto ayude a resolver el problema. No obstante, como siempre, asegúrese de prestar atención cuando modifica el Registro de Windows.
Como mencioné anteriormente, RPC puede usar puertos entre 1024 y 65.535, así que necesita asegurarse de que estos puertos no estén bloqueados por un firewall. La manera más sencilla de asegurarse de que un puerto está abierto es usar la herramienta Port Query. Esta herramienta viene en dos versiones: una versión de línea de comandos (PortQry) y una versión GUI (PortQueryUI).
PortQry está disponible para la descarga en el Centro de descarga de Microsoft. Para obtener información adicional, consulte el artículo "Descripción de la utilidad de línea de comandos Portqry.exe". Allí encontrará breves descripciones de informes de estado de PortQry y ejemplos de comandos usados para resolver problemas. Tenga presente que también puede usar la versión GUI, que es mucho más sencilla y que se puede descargar desde la dirección go.microsoft.com/fwlink/?LinkId=73740.
Cuando usa Port Query, debe asegurarse de ejecutarlo en un equipo que no experimenta errores de RPC y ejecutarlo hacia un equipo que tiene problemas con RPC. Por ejemplo, si quiere comprobar que el puerto 135, que usa el Endpoint Mapper de RPC, está abierto, use PortQry en el símbolo del sistema de la siguiente manera:
portqry -n [servername] -e 135
Si usa PortQuery o PortQueryUI, obtendrá resultados similares a los siguientes:
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
La última línea muestra que el puerto 135 está abierto. De lo contrario, la última línea habría indicado NOT LISTENING.
Para comprobar un intervalo de puertos, escriba el rango de números de puerto delimitados por comas, como por ejemplo: "135,1024-5000".

Soluciones adicionales
Si ha intentado todos los trucos descritos hasta ahora y el problema todavía no está resuelto, hay algunas opciones adicionales disponibles. En función de los problemas específicos en su entorno, quizás desee intentar con alguna de las siguientes modificaciones al Registro. ¡Espere! Antes de realizar cualquier cambio al Registro, es importante haber realizado copias de seguridad del sistema, especialmente el Registro. De este modo, si se produce errores tendrá la capacidad de restaurar el equipo a su estado anterior.
Una opción es ajustar MaxUserPort para especificar el mayor número de puerto que TCP puede asignar cuando una aplicación solicita al sistema un puerto de usuario disponible. De forma predeterminada, Windows Server 2003 establece el valor de MaxUserPort en 5000, lo que significa que usa 5000 como el mayor número de puerto, incluso si la entrada no existe. En función de la configuración, quizás no tiene esta entrada en el registro, en cuyo caso puede agregarla a la ubicación que se muestra en la figura 5.
Figura 5 Configuración de MaxUserPort en el Registro
Figura 5 Configuración de MaxUserPort en el Registro
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
Al modificar el Registro, debe conocer cualquier otro efecto secundario posible, lo que no siempre es fácil. Modificar esta entrada puede afectar a Microsoft Exchange Server si el valor se establece debajo de 50.000. Si la herramienta Best Practices Analyzer (BPA) de Exchange Server encuentra que el valor de la clave de Registro MaxUserPort es menor que 50.000, muestra una advertencia. Microsoft recomienda establecer el valor en 60.000; de otro modo puede causar advertencias de proxy de la interfaz del proveedor de servicio de nombres (NSPI), tales como el evento 9040. Para obtener más información, consulte el documento de Microsoft "Valor de MaxUserPort demasiado bajo".
También puede ajustar TcpMaxDataRetransmissions. Los paquetes TCP esperan una confirmación del extremo receptor. Si no existe confirmación antes de que expire el temporizador, entonces los paquetes se retransmiten hasta TcpMaxDataRetransmissions veces. El valor predeterminado para este parámetro es 5 pero quizás desee intentar con un valor de 4 o incluso 3. No use un valor inferior a 3.
Si la entrada de Registro TcpMaxDataRetransmissions no existe, la puede agregar en la siguiente ubicación, tal como se indica a continuación:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
Para obtener más información sobre TcpMaxDataRetransmissions, consulte el artículo de Microsoft Knowledge Base 170359, "Cómo modificar el tiempo de espera máximo de retransmisión de TCP/IP".
Otro valor de registro con el que quizás desee experimentar es TcpTimedWaitDelay. Si un cliente usa demasiados puertos, es bastante posible que se quede sin puertos antes de que TCP/IP libere las conexiones cerradas. Esto se debe a que TCP/IP no libera la conexión hasta que pasen dos vidas máximas de segmento (MSL); esto se conoce como estado de tiempo de espera. Más aún, dado que cada MSL se define en 120 segundos y TCP/IP no libera la conexión hasta que pasan dos MSL, TCP/IP emplea 240 segundos (4 minutos) para liberar una conexión cerrada. Tenga en cuenta que este fue un problema conocido en Windows NT® que se corrigió con un Service Pack; como resultado, es mucho menos probable que hoy experimente este problema. Sin embargo, Microsoft recomienda ajustar esta configuración como una de las soluciones posibles para resolver los errores del Endpoint Mapper de RPC, tal como se explica en el artículo de Microsoft Knowledge Base "Cómo solucionar problemas con los errores del Endpoint Mapper de RPC".
TcpTimedWaitDelay se agrega al Registro en la siguiente ubicación:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
Para obtener más información acerca de TcpTimedWaitDelay, consulte el artículo de Microsoft Knowledge Base "Los clientes de Windows NT se quedan sin puertos". Aunque el artículo no recomienda ningún número específico, quizás puede intentar reducir TcpTimedWaitDelay a 60 (segundos) en decimal, que es 3c en hexadecimal.

Conclusión
Los errores de RPC pueden ser la raíz de numerosos errores de comunicación en la red. Por suerte, existen varias maneras creativas con las que se pueden solucionar estos problemas esquivos. Algunas de las herramientas que he sugerido aquí están integradas, mientras que otras se encuentran disponibles en el kit de recursos de Windows Server. Muchas se incluyen en la lista de la figura 6. Puede usar estas herramientas para detectar la causa y ubicación de los errores de RPC y, a continuación, usar alguna de las técnicas descritas en este artículo para resolver los errores.
Figure 6 Herramientas de solución de problemas de RPC (Close Figure 6)

Herramienta | Descripción
DCDiag | Analiza el estado de los controladores de dominio.
Visor de eventos | Muestra eventos registrados.
Gpotool | Determina si las directivas son válidas y coherentes.
NetDiag | Se usa para probar la conectividad de red.
Monitor de red | Supervisa y captura tráfico de red.
Ntdsutil | Ofrece prestaciones de administración para Active Directory.
PortQry, PortQueryUI | Se usa en pruebas de conectividad de TCP/IP.
Repadmin | Diagnostica problemas de réplica entre controladores de dominio (DC) de Windows.
RPCDump | Se usa típicamente junto con Monitor de red.
RPCPing | Se usa para confirmar conectividad RPC.

Zubair Alexander, MCSE, MCT y Microsoft MVP, es propietario de SeattlePro Enterprises, una compañía de aprendizaje y consultoría de TI. Su experiencia cubre el espectro completo de la educación de TI: autor, instructor universitario, consultor, ingeniero en redes, orador, arquitecto de seguridad, administrador de sistemas, editor técnico y entrenador. Puede ponerse en contacto con Zubair en la dirección alexander@techgalaxy.net.


 The Cable Guy: Tr&#225;fico IPv6 sobre conexiones VPN
The Cable Guy
Tráfico IPv6 sobre conexiones VPN
Joseph Davies

Cuando comienza a evaluar la función de la versión 6 del protocolo de Internet (IPv6) en la intranet y empieza a planear su implementación, debería comprender cómo se admite el tráfico IPv6 en las conexiones de red privada virtual (VPN) en Windows. Con conexiones VPN, puede ampliar su red para incluir los vínculos a través de
redes públicas como Internet. Las conexiones VPN están protegidas por protocolos de autenticación seguros para validar las credenciales del usuario que se conecta y por métodos de cifrado para la confidencialidad de los datos.
Windows® XP y Windows Server ® 2003 incluyen una pila de protocolo IPv6, pero muchos servicios principales y componentes de red no admiten IPv6. Windows™ Vista y Windows Server 2008, anteriormente designado con el nombre en código "Longhorn," tienen compatibilidad de características completas para IPv6, que se instala y se habilita de manera predeterminada. De hecho, casi todos los servicios y las aplicaciones de redes incluidos con Windows Vista y Windows Server 2008 admiten IPv6. Este mes, tratamos la compatibilidad de Windows Vista, Windows Server 2008, Windows XP y Windows Server 2003 con el tráfico IPv6 enviado sobre conexiones VPN establecidas a través del protocolo Internet versión 4 (IPv4) y de las redes Internet IPv6.

Conexiones VPN a través de Internet IPv4
Para la mayor parte de las intranets actuales, las conexiones VPN se crean a través de Internet IPv4. En la figura 1 se muestran los componentes basados en Windows para conexiones VPN de este tipo. Estos componentes constan de lo siguiente:
Figura 1 Componentes basados en Windows para conexiones VPN a través de Internet IPv4
Figura 1 Componentes basados en Windows para conexiones VPN a través de Internet IPv4
Cliente VPN Se trata de un equipo que inicia una conexión VPN de acceso remoto a un servidor VPN y se comunica con recursos de intranet. Una conexión VPN de acceso remoto permite al cliente VPN actuar como si estuviera conectado directamente a la intranet. Un cliente VPN puede ejecutar versiones de cliente o servidor de Windows.
Servidor VPN Este equipo está a la escucha de intentos de conexión VPN remotos, aplica requisitos de autenticación y conexión y dirige paquetes entre clientes VPN y recursos de intranet. Un servidor VPN ejecuta normalmente una versión de servidor de Windows con el servicio de enrutamiento y acceso remoto.
Enrutador VPN Un enrutador VPN es un equipo que inicia o escucha intentos de conexión VPN de sitio a sitio. Una conexión VPN de sitio a sitio interconecta dos partes de una Intranet. Un enrutador VPN ejecuta una versión de servidor de Windows y el servicio de enrutamiento y acceso remoto.
Conexión VPN Una conexión VPN es el vínculo lógico entre el cliente VPN y el servidor VPN o bien, entre enrutadores VPN tal como se define en la encapsulación de un protocolo VPN.
Intranet habilitada con IPv6 Esta intranet puede reenviar tráfico IPv6, de manera nativa o cómo túnel en forma de paquetes IPv4.
Host IPv6/IPv4 Este nodo de intranet envía y recibe tráfico IPv6, nativamente o como túnel en forma de paquetes IPv4.
Los clientes VPN basados en Windows, los servidores y los enrutadores pueden usar los siguiente protocolos VPN para encapsular los paquetes enviados a través de la conexión VPN: Protocolo de túnel punto a punto (PPTP), Protocolo de túnel de nivel dos con protocolo de seguridad de Internet (L2TP/IPsec) y Protocolo de túnel de sockets seguros (SSTP). SSTP sólo está admitido por Windows Vista con Service Pack 1 (SP1, ahora en la prueba de la versión beta) y Windows Server 2008.
Para conexiones VPN a través de Internet IPv4, hay dos métodos que se usan para enviar IPv6: paquetes IPv6 enviados por túnel en forma de paquetes IPv4, a partir de ahora denominados tráfico IPv6 sobre IPv4, y tráfico IPv6 nativo.
A lo largo de esta columna, la compatibilidad con el tráfico IPv6 a través de conexiones VPN se indica en términos de protocolos VPN y versiones de Windows. Para conexiones VPN de acceso remoto, una combinación determinada de protocolo VPN y versión de Windows implica compatibilidad por parte de los componentes del cliente de acceso remoto y del servidor de acceso remoto de Windows.

Tráfico IPv6 sobre IPv4
En este método, un cliente de acceso remoto o un host IPv6/IPv4 en la intranet encapsula paquetes IPv6 con un encabezado IPv4 y envían el resultado en forma de un paquete IPv4. Para intranets, la tecnología de transición IPv6 (RFC 4214) de ISATAP permite nodos IPv6/IPv4 para intercambiar tráfico IPv6 a través de una intranet de sólo IPv4. Con ISATAP, puede habilitar la conectividad IPv6 en la intranet sólo de IPv4 sin tener que configurar o actualizar los enrutadores existentes para admitir la asignación de direcciones y el reenvío de IPv6 nativo. Para obtener más información acerca de ISATAP, consulte "Tecnologías de transición de IPv6" en la dirección microsoft.com/technet/network/ipv6/ipv6coexist.mspx.
La figure 2 muestra la estructura de paquete general para el tráfico VPN al enviar un paquete IPv4 usando una conexión VPN a través de Internet IPv4. El paquete IPv4 está encapsulado por el protocolo VPN con un encabezado y, según el protocolo de VPN, un finalizador. El resultado se encapsula con un encabezado IPv4 que permite el reenvío a través de Internet IPv4.
Figura 2 Paquetes IPv4 que usan una conexión VPN a través de Internet IPv4
Figura 2 Paquetes IPv4 que usan una conexión VPN a través de Internet IPv4
Para el tráfico IPv6 sobre IPv4, la carga del paquete IPv4 enviado a través de la conexión VPN es un paquete IPv6. La figura 3 muestra la estructura de paquete general para el tráfico VPN al enviar un paquete IPv6 sobre IPv4 usando una conexión VPN a través de Internet IPv4.
Figura 3 Paquetes IPv6 sobre IPv4 que usan una conexión VPN a través de Internet IPv4
Figura 3 Paquetes IPv6 sobre IPv4 que usan una conexión VPN a través de Internet IPv4
Para conexiones VPN de acceso remoto, el tráfico IPv6 sobre IPv4 a través de Internet IPv4 es compatible con PPTP y L2TP/IPsec en Windows Vista, Windows Server 2008, Windows XP SP1 o posterior y Windows Server 2003 y SSTP en Windows Vista SP1 y Windows Server 2008. Para conexiones VPN de sitio a sitio, el tráfico IPv6 sobre IPv4 a través de Internet IPv4 es compatible con PPTP y L2TP/IPsec en Windows Server 2008 y Windows Server 2003.

Tráfico IPv6 nativo
Para el tráfico IPv6 nativo, el cliente VPN, el servidor o el enrutador envían paquetes IPv6 a través de la conexión VPN sin la encapsulación IPv4 inicial. Esto funciona para intranets con conectividad IPv6 nativa y requiere que los clientes VPN, servidores y enrutadores admitan el protocolo de control IPv6 (IPV6CP), RFC 2472, que define cómo los nodos IPv6 negocian opciones de configuración IPv6 para las conexiones basadas en el protocolo punto a punto (PPP). Windows Vista y Windows Server 2008 admiten IPV6CP, al contrario que Windows XP y Windows Server 2003. La figura 4 muestra la estructura de paquete general para el tráfico VPN al enviar un paquete IPv6 usando una conexión VPN a través de Internet IPv4.
Figura 4 Paquetes IPv6 nativo que usan una conexión VPN a través de Internet IPv4
Figura 4 Paquetes IPv6 nativo que usan una conexión VPN a través de Internet IPv4
Para conexiones VPN de acceso remoto, el tráfico IPv6 nativo a través de Internet IPv4 es compatible con PPTP y L2TP/IPsec en Windows Vista y Windows Server 2008, y con SSTP en Windows Vista SP1 y Windows Server 2008. Para conexiones VPN de sitio a sitio, el tráfico IPv6 nativo que viaja a través de Internet IPv4 es compatible con PPTP y L2TP/IPsec en Windows Server 2008.

Conexiones VPN a través de Internet IPv6
También puede realizar conexiones VPN a través de Internet IPv6. Dichas conexiones VPN son raras ahora pero pasarán a ser más predominantes conforme más proveedores de servicios de Internet ofrezcan IPv6 a sus clientes y más organizaciones incluyan la conectividad a Internet IPv6 en sus redes perimetrales de intranet.
Para admitir conexiones VPN a través de Internet IPv6, los protocolos VPN que se usan deben admitir conexiones sobre IPv6. En Windows Vista y Windows Server 2008, los protocolos L2TP/IPsec y VPN SSTP son compatibles con conexiones VPN de acceso remoto sobre IPv6. En Windows Server 2008, L2TP/IPsec es compatible con conexiones de sitio a sitio sobre IPv6. Las conexiones VPN a través de Internet IPv6 usan el mismo conjunto de componentes que los de las conexiones VPN a través de Internet IPv4 para las conexiones de acceso remoto y VPN de sitio a sitio.
También hay dos maneras de enviar paquetes IPv6 sobre Internet IPv6: Tráfico IPv6 sobre IPv4 y tráfico IPv6 nativo. La figura 5 muestra la estructura general de paquetes IPv6 sobre IPv4 cuando se envían a través de una conexión VPN a través de Internet IPv6.
Figura 5 Paquetes IPv6 sobre IPv4 que usan una conexión VPN a través de Internet IPv6
Figura 5 Paquetes IPv6 sobre IPv4 que usan una conexión VPN a través de Internet IPv6
Para conexiones VPN de acceso remoto, el tráfico IPv6 sobre IPv4 a través de Internet IPv6 es compatible con L2TP/IPsec en Windows Vista y Windows Server 2008, y con SSTP en Windows Vista SP1 y Windows Server 2008. Para conexiones VPN de sitio a sitio, el tráfico IPv6 sobre IPv4 a través de Internet IPv6 es compatible con L2TP/IPsec en Windows Server 2008. De la misma manera que para el tráfico IPv6 sobre IPv4 sobre Internet IPv4, el tráfico IPv6 sobre IPv4 a través de Internet IPv6 requiere la implementación de una tecnología de transición IPv6 como ISATAP en su intranet.
La figura 6 muestra la estructura general de paquetes IPv6 cuando se envían a través de una conexión VPN a través de Internet IPv6. Al igual que para el tráfico IPv6 nativo sobre Internet IPv4, el tráfico IPv6 nativo sobre Internet IPv6 requiere compatibilidad con IPV6CP y la implementación de la conectividad IPv6 nativa en la intranet.
Figura 6 Paquetes IPv6 nativo que usan una conexión VPN a través de Internet IPv6
Figura 6 Paquetes IPv6 nativo que usan una conexión VPN a través de Internet IPv6
Para conexiones VPN de acceso remoto, el tráfico IPv6 nativo a través de Internet IPv6 es compatible con L2TP/IPsec en Windows Vista y Windows Server 2008, y con SSTP en Windows Vista SP1 y Windows Server 2008. Para conexiones VPN de sitio a sitio, el tráfico IPv6 nativo a través de Internet IPv6 es compatible con L2TP/IPsec en Windows Server 2008.

Conclusión
La figura 7 muestra los cuatro métodos para el envío de tráfico IPv6 sobre conexiones VPN y la compatibilidad en Windows para los dos tipos diferentes de conexiones VPN. En pocas palabras, si usa una tecnología de transición de IPv6 como, por ejemplo, ISATAP en la intranet, puede enviar tráfico IPv6 sobre IPv4 en conexiones VPN a través de intranets IPv4 e IPv6. Si la intranet admite la conectividad IPv6 nativa, puede enviar el tráfico IPv6 nativo sobre conexiones VPN a través de Internet IPv4 e IPv6 con Windows Vista y Windows Server 2008.
Figure 7 Compatibilidad para el tráfico IPv6 sobre conexiones VPN en Windows (Close Figure 7)

Método de envío del tráfico IPv6 | Conexiones VPN de acceso remoto | Conexiones VPN de sitio a sitio
Tráfico IPv6 sobre IPv4 a través de Internet IPv4 | PPTP y L2TP/IPsec en Windows Vista, Windows Server 2008, Windows XP SP1 o posterior, y Windows Server 2003 SSTP en Windows SP1 Vista y Windows Server 2008 | PPTP y L2TP/IPsec en Windows Server 2008 y Windows Server 2003
Tráfico IPv6 nativo sobre Internet IPv4 | PPTP y L2TP/IPsec en Windows Vista y Windows Server 2008 SSTP en Windows SP1 Vista y Windows Server 2008 | PPTP y L2TP/IPsec en Windows Server 2008
Tráfico IPv6 sobre IPv4 a través de Internet IPv6 | L2TP/IPsec en Windows Vista y Windows Server 2008 SSTP en de Windows Vista SP1 y Windows Server 2008 | L2TP/IPsec en Windows Server 2008
Tráfico IPv6 nativo sobre Internet IPv6 | L2TP/IPsec en Windows Vista y Windows Server 2008 SSTP en de Windows Vista SP1 y Windows Server 2008 | L2TP/IPsec en Windows Server 2008

Joseph Davieses escritor técnico de Microsoft y enseña y escribe sobre temas de red de Windows desde 1992. Ha escrito cinco libros para Microsoft Press y es autor de la columna mensual Cable Guy de TechNet.


 Windows PowerShell: Replanteamiento de la canalizaci&#243;n
Windows PowerShell
Replanteamiento de la canalización
Don Jones

Se ha hablado mucho acerca de cómo Windows PowerShell es diferente, nuevo y emocionante; aunque se base en conceptos de la interfaz de línea de comandos que han existido durante décadas, principalmente en sistemas operativos basados en UNIX y Linux. Pero la terminología común que Windows PowerShell comparte con sus antepasados puede llevar
a que se pase por alto la verdadera flexibilidad y exclusividad de Windows PowerShell™ y su eminente idoneidad en un entorno Windows®.
Una de las características más mencionadas de Windows PowerShell es su canalización, pero también es, desafortunadamente, una de las peor comprendidas. Esto se debe a que depende de terminología definida durante los comienzos de los años setenta, que representó alguna vez una funcionalidad enteramente diferente y menos eficaz.

Origen de las canalizaciones
Uno de los primeros shell de Unix que se crearon fue el shell de Thompson, que era muy primitivo y sólo ofrecía los elementos de lenguaje de scripting más elementales, sin incluir variables. El shell tenía un diseño deliberadamente modesto, porque su único propósito real era la ejecución de programas. Sin embargo, introdujo un concepto clave mejorado con respecto a otros shell de la época: las canalizaciones. A través del uso de los símbolos < and >, se podía instruir al shell para que redireccionara la entrada y salida hacia y desde diferentes comandos. Un usuario podía, por ejemplo, redireccionar la salida de comando a un archivo.
Esta sintaxis fue ampliada luego para que la salida de un comando también se pudiera canalizar a la entrada de otro, permitiendo que largos scripts se encadenaran para realizar las tareas más complicadas. En la versión 4 del shell, se adoptó para la canalización el carácter de línea vertical "|" y de ahí pasó a ser conocido como el carácter de canalización. Incluso las primeras versiones de MS-DOS® implementaban canalización básica a través de estos caracteres, permitiendo a un usuario, por ejemplo, canalizar la salida del comando type en la entrada del comando more, para crear una visualización de texto largo en una página a la vez.
Aunque el shell de Thompson se consideraba muy inadecuado en la época en que se lanzó al mercado la versión 6 de Unix en 1975, el concepto de canalizaciones permanecía en la memoria de desarrolladores y usuarios de shell y se ha traspasado a varias tecnologías que se usan actualmente.

Texto de canalización
Una limitación de casi todos los shell es su naturaleza intrínsecamente basada en texto. En sistemas operativos basados en Unix, esto no es realmente una limitación, sino un reflejo de cómo funciona el mismo sistema operativo. Prácticamente cualquier recurso en Unix se puede representar como un archivo de algún tipo, lo que significa que la capacidad de canalizar texto de un comando a otro ofrece mucha eficacia y flexibilidad.
Sin embargo, el texto definitivamente limita en lo que se refiere a información de administración. Por ejemplo, si se presentara una lista de servicios que se ejecutan en un equipo Windows, seguramente podría encontrar la explicación. Quizás colocaría el nombre de servicio en la primera columna y su modo de inicio en la segunda. Su eficaz cerebro humano analizaría o traduciría instantánea y transparentemente la pantalla de texto en información significativa con la que pudiera trabajar. Sin embargo, a los equipos les falta mucho para ser así de inteligentes: para hacer que un equipo haga algo significativo con esa lista, tendría que decirle que la primera columna consiste de los caracteres 1 a 20, quizás, y que los caracteres 22 a 40 componen la segunda columna, etc.
Durante años, este tipo de análisis de archivos de texto fue la única manera que tuvieron los administradores para encadenar múltiples comandos. En realidad, los lenguajes de scripting tales como VBScript y Perl se destacan en la manipulación de cadenas principalmente porque necesitan poder aceptar la salida de texto de un programa o comando y, a continuación, analizar y transformar esa salida en alguna clase de datos útiles que se puedan usar para alguna tarea subsiguiente. He escrito trabajos de VBScript que aceptaban, por ejemplo, la salida de texto del comando Dir, analizaban nombres de archivo y fechas en la salida y, a continuación, movían los archivos antiguos y no usados a una ubicación de archivo. El análisis de la cadena es sumamente complicado, porque las excepciones (variaciones en los datos de entrada) casi siempre suceden, y necesitará replantear la lógica en el script para resolver todas las permutaciones posibles.
Como una forma de scripting o automatización administrativa en un entorno Windows, el análisis de cadenas no es tan útil. Esto se debe a que Windows no almacena mucha información en un formato de texto fácilmente accesible. En cambio, usa almacenes centrados en datos, tales como Active Directory®, el Registro de Windows y el almacén de certificados, para que los creadores de scripts tengan que usar primero una herramienta para generar alguna forma de salida de texto y, a continuación, un script para analizar ese texto y hacer algo con él.

Los objetos son más sencillos
Para los desarrolladores de software de Windows las cosas siempre han sido un poco más sencillas. Inicialmente, Microsoft desarrolló COM expresamente para representar el complejo funcionamiento interno de Windows de un modo más sencillo de usar. En la actualidad, Microsoft® .NET Framework continúa esa misma tarea; representar el funcionamiento interno de software de un modo estandarizado.
Genéricamente, tanto COM como .NET exponen los elementos como objetos. (Un desarrollador de software quizás se ofenda por esta simplificación, pero a los fines de nuestra discusión, un término sencillo es suficiente). Todos estos objetos tienen miembros de distintos tipos. A nuestros fines, las propiedades y los métodos de los objetos son aquello en lo que estamos más interesados. Una propiedad describe esencialmente un objeto de alguna manera, o bien modifica el objeto o su comportamiento. Por ejemplo, un objeto de servicio quizás tenga una propiedad que contiene el nombre del servicio y otra propiedad que contiene el modo de inicio del servicio. Los métodos hacen que un objeto tome alguna acción. Un objeto de servicio quizás tenga los métodos denominados Stop, Start, Pause y Resume, por ejemplo, que representan las diversas acciones que se pueden tomar con un servicio.
Desde el punto de vista de la programación o de scripting, se hace referencia a los miembros del objeto mediante una notación con puntos. Con frecuencia los objetos se asignan a variables, que le ofrecen una manera de manipular físicamente el objeto. Por ejemplo, si tengo un servicio asignado a la variable $service, puedo detener ese servicio mediante la sintaxis $service.Stop. O bien, puedo recuperar el nombre para mostrar del servicio al mostrar $service.Name.

Objetos en la canalización
Debido a que Windows es un sistema operativo grande y complejo, y puesto que no almacena sus datos de administración en representaciones de estilo texto, las técnicas más antiguas de shell no son muy convenientes para él. Por ejemplo, supongamos que tengo una herramienta de línea de comandos, denominada SvcList.exe que genera una lista con formato de servicios y sus modos de inicio. En el shell de línea de comandos de Windows (un shell que tiene firmemente sus raíces en el shell MS-DOS de antiguas décadas) quizás pueda ejecutar algo así:
SvcList.exe | MyScript.vbs
Esta instrucción recupera una lista de servicios y canaliza esa lista en un archivo VBScript. Tendría que escribir el archivo VBScript para analizar la lista con formato y hacer cualquier cosa que desee que haga; quizás mostrar todos los servicios con un modo de inicio Deshabilitado. Esta tarea demandaría mucho tiempo. En última instancia, el problema es que SvcList.exe tiene una salida que es exclusiva; no comparte un formato común que otros comandos pueden consumir fácilmente para usar su salida.
Los objetos, sin embargo, pueden ofrecer ese formato común, y ese es el motivo por el cuál la canalización de Windows PowerShell funciona con objetos completos, no sólo con texto. Cuando ejecuta un cmdlet como Get-WMIObject, produce un grupo (o una colección, en términos de programador) de objetos. Cada objeto viene completo con propiedades y métodos que permiten su manipulación. Si canalizo los objetos al cmdlet Where-Object, los puedo filtrar para que se muestren sólo los objetos que deseo. Where-Object no necesita analizar ningún texto porque no recibe ningún texto, recibe objetos. Por ejemplo:
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
O bien, si prefiere la sintaxis más corta disponible a través de alias:
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
Lo que resulta interesante es que Windows PowerShell siempre pasa los objetos a la canalización. Recién al final de la canalización, cuando no hay ningún otro lugar adonde pasar los objetos, el shell genera una representación de texto de los objetos mediante sus reglas de formato integradas. Por ejemplo, considere lo siguiente:
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
Este conjunto de tres cmdlets recupera todos los servicios de mi equipo local, filtra todos los que no usan la cuenta LocalSystem para iniciar sesión y pasa el resto al cmdlet Select-Object, que sólo muestra dos propiedades (Name y StartMode) que he pedido que seleccione. El resultado es un informe sencillo de servicios que inician sesión como LocalSystem (quizás para fines de auditoria de seguridad).
Dado que todos los cmdlets comparten un formato común de datos (objetos), tienen la capacidad de compartir datos entre sí, sin ningún análisis complicado de cadena. Además, dado que Windows PowerShell tiene una capacidad nativa para crear la representación de texto de un objeto, el final de esta canalización seguro será una salida de texto que yo, una persona, pueda leer. La figura 1 muestra un ejemplo de la salida generada.
Figura 1 Salida del texto generada por una serie de cmdlets canalizados que pasan objetos
Figura 1 Salida del texto generada por una serie de cmdlets canalizados que pasan objetos

La emoción de las canalizaciones
El motivo por el cuál la canalización en Windows PowerShell es tan asombrosa es que, en Windows PowerShell, todo es un objeto, completo con propiedades y métodos que puede usar. Incluso un archivo de texto es técnicamente una recopilación de objetos de cadena, donde cada línea en el archivo actúa como un objeto exclusivo e independiente de cadena. Por ejemplo, cree un archivo de texto (con el Bloc de notas) denominado C:\Computers.txt. Complete el archivo con texto y, a continuación, ejecute lo siguiente en Windows PowerShell:
Get-Content C:\Computers.txt | Select-Object Length | Format-List
O bien, nuevamente, si prefiere escribir menos, puede usar alias:
gc C:\Computers.txt | select Length | fl
Este código proporciona una lista que indica la longitud de cada línea del archivo de texto, en caracteres. Get-Content recupera los objetos de cadena del archivo, Select-Object toma la propiedad Length de cada uno y, a continuación, Format-List crea la salida de texto agradable y legible para el usuario. Aunque quizás esto no sea una herramienta administrativa práctica para usar, demuestra que incluso algo tan sencillo como una línea de texto es un objeto en Windows PowerShell.
Al poder canalizar objetos de cmdlet en cmdlet, o incluso de cmdlet en un script, se permite la creación de "frases de una línea" increíblemente eficaces. Son simples cadenas de cmdlets asociadas en una larga canalización que refina aún más un conjunto de objetos para darle exactamente lo que desea. Prácticamente sin scripting ni programación de ningún tipo, los cmdlets de Windows PowerShell, conectados en una canalización apropiada, pueden lograr resultados notables.

Compatibilidad con futuras generaciones
El hecho de que futuros productos de servidor de Microsoft se basen también en Windows PowerShell, extiende esta funcionalidad. Al implementar un nuevo equipo con Exchange Server 2007, por ejemplo, puede usar Windows PowerShell para recuperar todos los buzones, filtrar todos los buzones que no estén en la oficina donde estará ubicado el nuevo servidor y, a continuación, mover esos buzones al nuevo servidor, todo en una sola línea de texto sin scripting. El equipo de Exchange Server 2007 ha publicado una larga lista de eficaces frases de una línea. Estas líneas demuestran en realidad el poder de la canalización y las tareas administrativas que pueden realizar.
El truco con Windows PowerShell es entender que, aunque está basado en principios y filosofías establecidos desde hace tiempo en el mundo Unix, esta nueva herramienta es exclusivamente idónea para la administración de Windows. No permita que ninguna coincidencia de terminología le haga pensar equivocadamente que Windows PowerShell es sólo una imitación de shell de Unix para Windows. Windows PowerShell contiene conceptos completamente nuevos que aprovechan la plataforma de Windows, y están estrechamente asociados a la manera en que Windows hace las cosas.

Don Jones es MVP de Windows PowerShell y autor de Windows PowerShell 101 (ScriptingTraining.com). Puede ponerse en contacto con Don en la dirección www.ScriptingAnswers.com.


 &#161;Hola, encargados de las secuencias de comandos!: En los scripts, como en la vida, las apariencias son importantes
¡Hola, encargados de las secuencias de comandos!
En los scripts, como en la vida, las apariencias son importantes
Los encargados de las secuencias de comandos de Microsoft

A lo largo de centenares, más aún, de miles de años, los filósofos y sabios nos han dicho que debemos mirar más allá de la apariencia física al juzgar a alguien o algo. (No significa que debemos estar juzgando a la gente, tenga cuidado; después de todo, la belleza está en el ojo del observador.) Ya sabe, la belleza verdadera viene desde dentro, no desde fuera, y quién es usted es mucho más importante que su aspecto físico.
Sobre eso, los encargados del scripting sólo pueden decir una sola cosa: tonterías.
Exacto, tonterías. Los encargados del scripting son los primeros en admitir que en un mundo ideal, el aspecto físico no importa. Sin embargo, no vivimos en un mundo ideal. Si lo hiciéramos, la pizza y los helados con frutas, nueces y chocolate compondrían los principales grupos de alimento. Que nos guste o no, la apariencia es importante. Y eso es cierto tanto para los scripts como para todo el resto.
Los encargados del scripting conocen que pocas personas lloran de la emoción por la pura belleza de un script de VBScript que se ejecuta en una ventana de comandos. (Quizás Dean Tsaltas, uno de los encargados del scripting, pero es el único en quién podemos pensar.)
Por otro lado, también es verdad que en este mundo nuestro de alta tecnología, los creadores de scripts ya no están limitados a escribir scripts que se ejecutan en una ventana de comandos. Gracias a las aplicaciones HTML (HTA), los creadores de scripts pueden usar el poder de DHTML con el fin de crear GUI para sus scripts. Estas mismas habilidades HTML se pueden usar para crear gadgets de Windows Vista™, un nuevo escenario que tiene el potencial para revolucionar el scripting de administración de sistemas tal como la conocemos. Pero, ¿sabe qué? Tan pronto como comience a hablar acerca de las GUI, salen a relucir las opiniones muy trilladas que dicen que la belleza es algo sólo superficial. Para los scripts que se ejecutan en un entorno gráfico, las apariencias son tan importantes como la función y el rendimiento.
Y eso es un problema. A fin de cuentas, somos creadores de scripts; ¿qué sabemos acerca de crear interfaces gráficas de usuario? Parece que no estamos de suerte, ¿no es cierto?
A lo mejor sí. Pero quizá no. ¿Acabamos de escuchar que alguien dice, "Menos mal, por los encargados del scripting"?
No, en serio. ¿No acabamos de escuchar que alguien dijo eso? Quizá son de los que dicen algo entre dientes...
Bien, no importa. Alguien debe decirlo, porque los encargados del scripting están aquí para ayudar (aunque desee nuestra ayuda o no).
Para que comience en el maravilloso mundo de las GUI, echemos una mirada los inicios de una pequeña y sencilla HTA. Si desea obtener más información sobre la creación de las HTA, consulte Centro para desarrolladores de HTA).
Lo que tenemos en la figura 1 es la primera parte de un elegante sistema de información de escritorio. Como puede observar, comenzamos poniendo un pequeño y agradable gráfico en la esquina superior derecha de la ventana de la HTA. La idea es que la primera vez que se cargue la HTA, ésta recupere el nombre del usuario que ha iniciado sesión y muestre su nombre y el nombre de equipo encima de esta imagen. Más adelante agregaremos a la HTA otras cosas interesantes de todo tipo, como se dice, lo primero es lo primero.
Figura 1 El comienzo de nuestra bonita interfaz gráfica de la HTA
Figura 1 El comienzo de nuestra bonita interfaz gráfica de la HTA
Bueno, no estamos muy seguros de quién ha dicho eso. Probablemente otro de esos filósofos. Probablemente Voltaire. Parece el estilo de cosas que diría Voltaire.
De acuerdo, es una aplicación pequeña bastante sencilla y su... belleza... quizás ni haga llorar de emoción al encargado del scripting Dean. Pero sirve como una herramienta de demostración útil, con un concepto básico que se aplica a muchas situaciones diferentes. A fin de cuentas, muchos de esos presuntuosos gadgets de Windows Vista funcionan con un principio semejante; simplemente muestran un gráfico elegante (digamos, un indicador o esfera) y a continuación escriben algún texto encima de ese gráfico. Es eso lo que hace que parezca que tiene un indicador pequeño genial que muestra el espacio en disco disponible cuando, resulta que, todo lo que en realidad tiene es un gráfico genérico superpuesto con algún texto dinámico.
De acuerdo, para decirle la verdad, tampoco tiene mucho sentido para nosotros. Pero las cosas se deben aclarar un poco a medida que avancemos en esta columna.
Sólo hay un problema con la noción de que podemos mostrar un gráfico y, a continuación, escribir texto encima de ese gráfico: no funciona. En cambio, con etiquetado de HTML básico obtenemos algo similar a lo mostrado en la figura 2. No es exactamente lo que estábamos pensando. Quizá Nietzsche, que dijo eso de "los seres humanos nunca pueden esperar en colocar texto encima de un gráfico, al menos no con una HTA", tenía razón.
Figura 2 Un primer intento de texto superpuesto
Figura 2 Un primer intento de texto superpuesto
O quizá Nietzsche estaba equivocado: acabamos de escuchar que alguien dijo —bien, da lo mismo. Aparentemente, no podemos hacer lo que queremos mediante HTML sin formato; no funciona así. Seguro, teóricamente podríamos hacer de nuestro gráfico un gráfico en segundo plano y usar tablas y espacios sin saltos y todo otro tipo de pequeños trucos para poder superponer texto en la imagen. Pero decimos "teóricamente" por un buen motivo; excepto en el más simple de los casos, esa estrategia nunca funciona.
Aparentemente, hay una manera mucho mejor de crear diseños elegantes en una HTA o en un gadget de Windows Vista: Hojas de estilo en cascada, más conocidas como CSS.
CSS se usa para definir fuentes, márgenes y alineaciones, colores y otros aspectos de presentación de un documento. (Esto se aplica en especial a páginas web. Sin embargo, dado que las HTA y los gadgets son, en esencia, nada más que páginas web, CSS también se aplica a ellos). Ni siquiera podemos comenzar a explicar todas las posibles cosas que puede hacer con CSS, así que para obtener más información quizás desee consultar la práctica y completa documentación de referencia de CSS en MSDN®. Por ahora, es suficiente decir que podemos usar CSS para controlar detalladamente el diseño de la HTA, incluida la capacidad de superposición de un elemento (nuestro texto) en otro (nuestro gráfico).
Explicaremos cómo hacer todo eso. Pero antes de emprender esa explicación, observe el código de una HTA muy sencilla en la figura 3.
Figure 3 Por fin, llegamos al script... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
Como puede ver, en realidad no es muy complicada. Tenemos una subrutina Window_OnLoad que (según el nombre) se ejecuta automáticamente cada vez que se inicia o actualiza nuestra HTA. Hablaremos acerca de esta subrutina en un minuto. Además, tenemos dos elementos HTML: nuestro gráfico y una extensión Como seguramente sabe, usamos ese trozo de etiquetado para insertar el gráfico, mediante el atributo align para asegurar que la imagen aparece en la parte derecha de la ventana:
<img src=”test2.jpg” align=”right”>
Eso nos conduce al etiquetado HTML para la extensión:
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
De acuerdo, hemos usado aquí una etiqueta de extensión. ¿Qué es una etiqueta de extensión? Bien, a todos los efectos, una extensión es simplemente un área con nombre de la HTA; se trata de una sección "diferenciada" de la ventana de la HTA que podemos identificar mediante programación (principalmente porque le dimos a la extensión el Id. UserData). Una vez que establecemos una extensión, podemos escribir una subrutina que le asigne texto o código HTML. De hecho, no sólo podemos hacerlo, en nuestra HTA lo hicimos.
Pero, como decimos, hablaremos acerca de eso más adelante. Primero debemos observar el parámetro style agregado a la etiqueta de extensión:
style=”position:absolute;left:770px;top:150px”
Este parámetro, como quizás sospeche, es la clave para posicionar correctamente nuestro texto dinámico encima del gráfico. En realidad, aquí especificamos tres atributos style por separado.
Position Hemos dicho a nuestra HTA que queremos que la posición de nuestra extensión, sea, digamos, absoluta. Esto significa esencialmente que siempre deseamos que la extensión esté en el mismo lugar, incluso si eso significa, como en este caso, que el texto quedará escrito encima de otro elemento (como por ejemplo, un gráfico).
Left Esto simplemente especifica la posición de la extensión relativa al extremo izquierdo de la ventana de la HTA. En este caso, queremos que la extensión comience 770 píxeles (770px) a partir de la izquierda.
Top Esta configuración es bastante similar al atributo Left, excepto que esta vez especificamos la posición de la extensión relativa al extremo superior de la ventana de la HTA. En este caso queremos iniciar en la parte superior de la ventana y contar hacia abajo 150 píxeles (150px) antes de comenzar la extensión.
¿Cómo sabíamos que queríamos establecer el extremo izquierdo de nuestra extensión en 770 píxeles y el extremo superior en 150 píxeles? Bueno, a decir verdad, no lo sabíamos. En realidad lo adivinamos; colocamos el gráfico en la página y asignamos valores a los atributos Left y Top de la extensión. A continuación, abrimos la HTA y miramos los resultados. Como es de esperar, nos falta un poco, así que ajustamos los valores, actualizamos la HTA y miramos otra vez. Lo hicimos unas pocas veces hasta que, como Rubiales, encontráramos algo que fuera precisamente adecuado.
Nota: Imaginamos que conoce la historia de Rubiales y los tres osos, sus camas y sillas, el caldo que estaba demasiado caliente o demasiado frío, etc. Y no, no estamos seguros si Rubiales se podría considerar una gran filósofa o no. Pero podría argumentar que, viendo cómo ella no tuvo problemas en entrar en la casa de alguien, comer su caldo, sentarse en sus sillas y dormir hasta tarde en sus camas, definitivamente tenía una filosofía muy propia.
De todos modos, la figura 4 muestra cómo se ve ahora nuestra HTA. De acuerdo, quizá no sea una obra de arte, pero por otra parte, nos gustaría ver cómo Picasso imprimiría información mediante programación encima de un gráfico.
Figura 4 El poder de style
Figura 4 El poder de style
Hablando de eso, ¿cómo imprimimos información encima de un gráfico mediante programación? Bueno, tenemos buenas noticias para usted: por fin es tiempo de hablar acerca de nuestra subrutina Window_OnLoad, mostrada en la figura 5.
Figure 5 Subrutina Window_OnLoad (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
Sabe, ahora que miramos un poco más de cerca esta subrutina, vemos que realmente no hay tanto de que hablar, ¿verdad? Como puede ver, primero creamos una instancia del objeto Wscript.Network. A continuación, usamos estas líneas de código para recuperar el nombre de usuario, de dominio y de equipo:
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
Por supuesto, esto resulta ser la información que queremos escrita en la ventana de nuestra HTA. Todo lo que queda por hacer es combinar las variables strUser y strComputer con un pequeño etiquetado HTML y, a continuación, asignar la cadena resultante a la propiedad InnerHTML de nuestra extensión:
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” _
  & strUser & “<br>” & strComputer & _
  “</font></p>”
Somos conscientes de que es un fragmento de código de aspecto complicado. Pero no es para tanto. Parece complicado simplemente porque combinamos varios elementos en una sola cadena. Comenzamos con una etiqueta del párrafo de apertura, que especifica que queremos centrar texto en el párrafo.
“<p align = ‘center’> “
A continuación, se encuentra una etiqueta de fuente de apertura, que especifica que debemos usar texto en blanco de 18 puntos:
“<font style=’font-size:18pt;color:white’>”
StrUser es la variable que contiene nuestro nombre de usuario, con el formato Dominio\Nombre de usuario. "<br>" inserta un salto de línea. Insertamos esto para que el nombre de usuario aparezca en una línea y el nombre de equipo aparezca en una segunda línea. strComputer es la variable que contiene el nombre de nuestro equipo. Por último, agregamos las etiquetas de fuente de cierre y de párrafo:
“</font></p>”
Cuando observa las partes individualmente puede ver que el código no es tan complicado como pensaba.
A propósito, puede posicionar casi cualquier elemento HTML que desee. Por ejemplo, supongamos que le gustaría tener un botón centrado debajo del gráfico. Para ello, simplemente lo agrega a su código de la HTA:
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
Deberá obtener una HTA similar a la de la figura 6.
Figura 6 Un botón encantador
Figura 6 Un botón encantador
Nuevamente, tendrá que jugar un poco hasta conseguir posicionar correctamente el botón, pero no llevará demasiado tiempo. De hecho, si está dispuesto a realizar los cálculos, probablemente pueda determinar con antelación la posición correcta. Todo lo que necesita saber es el ancho y alto de cada objeto, algo que puede especificar mediante el parámetro style, y el ancho y alto de la ventana de la HTA. De forma predeterminada, por lo menos en el equipo de prueba de los encargados del scripting, las HTA tienen aproximadamente 1020 píxeles de ancho por 685 píxeles de alto (por supuesto, los resultados pueden variar). Si no hace otra cosa, puede comenzar con esos valores y, a continuación, ajustarlos para que satisfagan sus requisitos.
Obviamente ésta es una introducción demasiado breve a CSS, pero puede usarla como punto de partida para hacer hermosas sus scripts. Los filósofos pueden despreciar esos esfuerzos y decirle que la verdadera belleza de un script viene desde dentro, no desde fuera. Pero véalo de esta manera. ¿Quiénes son los filósofos más grandes de todos los tiempos? Efectivamente: Platón, Sócrates, Aristóteles, esas personas. Con eso en mente querríamos plantear una pregunta: ¿ha visto alguna vez una fotografía de cualquiera de esos filósofos? ¿No encuentra interesante que no exista ninguna fotografía de las personas que dicen que la belleza no importa? ¿No le parece extraño? Algo para pensar.

Los encargados de las secuencias de comandos 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 TechNet Script Center. Visite la página web www.scriptingguys.com.


 Preguntas y respuestas sobre Exchange: Funciones de transporte de Hub y Edge, m&#225;quinas virtuales, etc.
Preguntas y respuestas sobre Exchange
Funciones de transporte de Hub y Edge, máquinas virtuales, etc.
KC Lemson and Nino Bilic

En la entrega de mayo de 2007 de Preguntas y respuestas sobre Exchange, hablamos acerca de los problemas de almacenar los archivos .pst en recursos compartidos de red. El equipo de rendimiento de Windows Server inició recientemente un blog y abordó
este tema con todos los detalles técnicos, así que queremos proporcionarles el vínculo. Ahora vayamos a las preguntas.

P ¿Es obligatorio implementar la función de servidor Edge si deseo implementar Microsoft Exchange Server 2007?

R No, no es obligatorio implementar Edge para implementar Exchange Server 2007. Puede tener un único equipo que ejecuta funciones de servidor de núcleo (tales como buzón, acceso de cliente y transporte de concentrador) que aceptan correo electrónico de Internet para el dominio y ejecutan programas contra correo electrónico no deseado y antivirus.

P ¿Cuáles son las diferencias entre las funciones de servidor de transporte Hub y Edge? ¿Qué pierdo si no implemento Edge?

R El propósito principal de la función de perímetro es dirigir correo dentro de la organización y aplicar directivas de negocio a esos mensajes. Con la función de Hub, las reglas de transporte se basan en objetos de Active Directory®; usuarios, listas de distribución, etc. La función de Hub también permite agregar renuncias de responsabilidad a mensajes o realizar registro de mensajes enviados a grupos de usuarios porque querrá probablemente basar esas reglas en la pertenencia a Active Directory. Por ejemplo, puede realizar el registro de todos los mensajes enviados a DLOfUsersOnLitigationHold o agregar renuncias de responsabilidad al correo saliente enviado por DLOfMembersOfLegalTeam. Aunque es posible ejecutar agentes contra correo electrónico no deseado en el servidor Hub, no están habilitados de forma predeterminada y necesitará instalarlos manualmente mediante la secuencia de comandos install-antispamagents disponible en el directorio \scripts del servidor.
El propósito principal de la función de Edge es dirigir el correo dentro y fuera de la organización así como realizar la limpieza de mensajes (contra correo electrónico no deseado, antivirus, filtrado de contenido o datos adjuntos, etc.) en esos mensajes. La funcionalidad contra correo electrónico no deseado está lista para usar en un servidor Edge y se habilita durante la instalación. Una de las características exclusivas de la función de Edge es que no es necesario estar unido a un dominio Windows®; se puede ejecutar en una instalación de Windows Server® independiente que no es parte de un dominio Windows, pero el perímetro todavía se puede administrar como parte de la organización Exchange 2007 en su bosque corporativo.
Esto es especialmente ventajoso en una red de perímetro donde quizás desee que el servidor esté en un grupo de trabajo, o puede tener un bosque explícitamente separado para equipos en la red de perímetro. De manera conveniente, los servidores Edge implementados en esta situación pueden realizar toda la limpieza de mensajes y dirigir correo entre la red corporativa e Internet, mientras que todavía se pueden administrar de una manera coherente con el resto de la administración de sistemas Exchange 2007.
En un servidor Edge, las reglas de transporte se basan en direcciones SMTP, no en objetos Active Directory. Por supuesto, puede usar direcciones SMTP de las DL o los usuarios en Active Directory. La mayoría de las veces, las reglas de transporte perimetral son un subconjunto de las reglas de transporte de Hub y la excepción es la acción de cuarentena, que sólo está disponible en servidores Edge.
Los servidores Edge también tienen alguna funcionalidad expuesta a través de agentes que no están disponible en el servidor de transporte Hub: eliminación de datos adjuntos y reescritura de direcciones. La eliminación de datos adjuntos es la capacidad de quitar selectivamente datos adjuntos posiblemente peligrosos con extensiones tales como .exe y .com. El agente de reescritura de direcciones permite reescribir los encabezados de correo electrónico para que, por ejemplo, aunque el dominio y direcciones proxy SMTP predeterminadas en cuentas de usuario puedan ser por ejemplo @contoso.com, los mensajes salientes a Internet aparecerán como originados en @northwindtraders.com. Además, los servidores perimetrales sólo realizan enrutamiento basado en dominio o espacio de direcciones, de manera que si comparte el mismo espacio de direcciones SMTP entre Exchange y otro sistema de correo electrónico, necesitará realizar ese enrutamiento en el servidor Hub o bien de común acuerdo con el agente de reescritura de direcciones en el servidor Edge.
Otro factor importante es si un servidor Exchange 2007 se conecta directamente a Internet (se trate de la función de servidor Edge o Hub). Es decir, las conexiones al puerto 25 en el registro MX del dominio, ¿están conectadas a Exchange 2007 de alguna manera? Es posible que tenga una puerta de enlace SMTP, pared antivirus u otra solución conectada a Internet que acepte correo para el dominio y lo pase a Exchange dentro de la red corporativa. Si implementa servidores Edge o Hub directamente conectados a Internet, entonces puede aprovechar alguna de las características más ingeniosas de Exchange 2007: agregación de safelist. Con la agregación de safelist, los usuarios que agregan remitentes a su lista segura en Microsoft Outlook® (típicamente lo hacen para boletines de Internet o correo electrónico de distribuidores) conseguirán que esas listas se propaguen con seguridad a las funciones de Edge o Hub para que los mensajes de esos remitentes eludan el filtrado de contenido. Por supuesto, el correo no deseado de un usuario es el valioso boletín de otro, de manera que la agregación de safelist se realiza por usuario. Puede obtener más información acerca de este funcionamiento en la documentación de Exchange 2007.
Si se decide por una implementación en la que un servidor que ejecuta la función de Hub acepta correo electrónico de Internet para su dominio, hay unas pocas cosas a tener en cuenta. Por supuesto, primero debe estar seguro que tiene un firewall o solución de filtrado de puertos eficaz para que el servidor sólo reciba conexiones en los puertos necesarios, como el puerto 25. Recuerde también que necesitará instalar agentes contra correo electrónico no deseado porque no están instalados ni habilitados de forma predeterminada. Debido a que el escenario de implementación más frecuente del servidor Hub es dentro de la red corporativa, la configuración de fábrica no permite conexiones anónimas; necesitará comprobar el grupo de permisos AnonymousUsers en el conector de recepción del puerto 25. También querrá asegurar que habilita la agregación de safelist y programa su ejecución periódica para que cuando los usuarios actualicen safelists en sus buzones, el correo para esos usuarios en sus listas seguras de remitentes eluda el filtrado de contenido. Puede obtener más detalles en nuestro blog.
El código siguiente muestra un comando AT que actualiza diariamente todos los buzones a las 23:00 h. en todos los servidores mediante un archivo por lotes denominado SafeList.bat:
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
Este código muestra el contenido del archivo SafeList.bat:
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
Si necesita comprobar que la configuración funciona correctamente, encontrará más información en la documentación de Exchange 2007.

P Después de arrancar mi imagen de Virtual PC que contiene Exchange, sigo teniendo problemas para consultar el directorio o el servidor LDAP. Si ejecuto Telnet a 389 funciona y todos los servicios se ejecutan. ¿A qué se debe?

R Tuve este problema el año pasado en Tech•Ed. Tenía una copia de Virtual PC en mi equipo portátil que había copiado de un equipo en el trabajo, y planeaba usarla para hacer demostraciones para miembros de la prensa que publicaban artículos que coincidían con el lanzamiento de Exchange 2007 Beta 2 el mes siguiente.
Había realizado un millón de demostraciones del producto y sabía que era sólido, así que no lo preparé a fondo. Puede imaginarse el sudor en mi frente cuando arranqué mi Virtual PC el lunes por la mañana, apenas unas horas antes de la primera reunión, y cada parte de mi compilación insistía en que no se podía poner en contacto con un controlador de dominio. Gracias a la alta concentración de amigos súper inteligentes en la cabaña, pudimos resolverlo rápidamente.
El problema que tuve en el desastre de Tech•Ed fue el resultado de ejecutar Virtual PC en mi equipo portátil súper lento. La raíz del problema fue una condición de carrera con DNS y Active Directory. El servidor DNS en la imagen se configuró integrado con Active Directory, pero debido a la secuencia de carga de los servicios en la imagen (y, digamos, a la falta de eficacia de mi equipo portátil), los servicios de directorio necesarios no se habían iniciado cuando el servidor DNS intentó ponerse en contacto con Active Directory.
Esta situación puede suceder en cualquier servidor en que DC y Exchange se encuentren en el mismo equipo (no tiene que ser una imagen virtualizada), pero es mucho más probable que suceda en un entorno virtual donde existe un retraso adicional, especialmente en un equipo portátil no tan eficaz, similar al mío.
También he visto que sucede un problema semejante con imágenes de Virtual PC que se copian entre dos equipos, especialmente cuando uno de esos equipos está en una red diferente. Si esto le sucede, compruebe la dirección IP del sistema operativo en la imagen; es posible que tenga una dirección IP obsoleta de la antigua red. Actualícela para obtener una dirección IP de la nueva red y vea si esto ayuda.
Para evitar esta clase de problemas en el futuro, una alternativa es hacer que el servidor DNS en el invitado no esté integrado con Active Directory, así como instalar DNS tanto en el host como en el invitado. Haga que el invitado reenvíe los registros desconocidos al host y a la vez, que el host los reenvíe también al servidor DNS apropiado. Cuando su imagen arranque e intente actualizar los registros DNS, será menos propensa a errores.

P Parece que la instalación de Exchange 2007 es bastante diferente de la instalación de versiones anteriores de Exchange. ¿Cómo funciona?

R Sí, sin duda, hay varias etapas de instalación de Exchange 2007. A continuación presento una introducción general de cómo funciona el proceso completo.

Cuando ejecuta setup.exe por primera vez, se inicia un proceso que le ofrece los vínculos de la mayor parte de los requisitos previos que necesita instalar antes de comenzar con la instalación de las funciones de servidor reales. Una vez instalados todos esos requisitos previos, queda disponible el vínculo de instalación de Microsoft Exchange para hacer clic en él. (consulte la figura 1).
Figura 1 Vínculo de instalación disponible después de que se cumplen los requisitos previos
Figura 1 Vínculo de instalación disponible después de que se cumplen los requisitos previos
Si ejecutó setup.exe de la red e hizo clic en el vínculo de instalación, los archivos de instalación de núcleo se copian en la carpeta %TEMP%\ExchangeServerSetup\ en el equipo local. A continuación, se inicia el asistente para la instalación.
El asistente para la instalación le guiará por las distintas opciones tales como, por ejemplo, contrato de licencia, informe de errores y tipo de instalación (donde puede elegir las funciones de servidor que desea instalar). Las páginas del asistente variarán en función de la presencia y del estado de la organización Exchange actual (si existe).
Una vez completada, la instalación ejecutará una comprobación de preparación. En realidad es una versión modificada de Best Practices Analyzer (BPA) de Microsoft Exchange Server, que, de forma predeterminada, se conectará a Internet para descargar el archivo XML de requisitos previos más reciente. Esto proporciona una oportunidad de actualizar periódicamente los requisitos previos o solucionar cualquier problema que el equipo de Exchange conozca desde que el producto se lanzó al mercado. Cuando completa la comprobación de requisitos previos, podrá revisar los resultados y continuar; de otro modo verá cualquier problema que puede necesitar resolver antes de continuar con la instalación. Si el servidor no supera la comprobación de requisitos previos, el asistente le permitirá volver a intentar la comprobación en la mayoría de los casos.
Una vez aprobada la comprobación de requisitos previos, obtendrá el botón de instalación que le permite iniciar la instalación de cualquier función seleccionada anteriormente. Sólo se copiarán e instalarán los archivos para las funciones seleccionadas.
Al final de la instalación, podrá iniciar la consola de administración de Exchange, así como aplicar cualquier actualización de Exchange 2007 que pueda estar disponible.

KC Lemson es la administradora de experiencias del usuario para Exchange Server. Su cuenta bancaria en línea ha sido temporalmente suspendida.
Nino Bilic es administrador de programas de compatibilidad para Exchange Server. Recientemente agregó una dirección secundaria de correo electrónico a su tarjeta de crédito.


 Vigilancia de seguridad: Herramientas para administrar ACL
Vigilancia de seguridad
Herramientas para administrar ACL
Jesper M. Johansson

En Windows, las listas de control de acceso (ACL) le ofrecen un control muy preciso sobre la capacidad de los usuarios y los procesos para usar recursos tales como archivos y carpetas. La administración de las ACL puede ser una de las tareas más complicadas relacionadas con la protección de la seguridad de los sistemas de los usuarios. Afortunadamente, hay varias utilidades provechosas
que ayudan a automatizar y a simplificar tareas que rodean a los permisos y a las ACL.
La mayoría de los lectores conocen la venerable herramienta cacls.exe que ha estado en todas las versiones de Windows NT® desde que salió por primera vez. Si ejecuta cacls.exe en Windows Vista™, le aparecerá este mensaje:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
Además de las actualizaciones a las ACL en Windows Vista (que traté en el número de junio de 2007 de TechNet Magazine; consulte technetmagazine.com/issues/2007/06), Microsoft también ha actualizado algunas de las herramientas que usa para administrar las ACL. Curiosamente, la más significativa de estas actualizaciones son las herramientas de línea de comandos.
Icacls.exe es una novedad en Windows Vista (y también en el nivel inferior en Windows Server® 2003 Service Pack 2). Reemplazará finalmente cacls.exe, que nunca se actualizó por completo para admitir permisos más granulares incorporados con Windows® 2000, haciendo de ésta una actualización que lleva atrasada unos siete años.
Sorprendentemente, a pesar de estar obsoleto, cacls.exe incluye realmente algunas características nuevas. En primer lugar, conoce los puntos de unión y los vínculos simbólicos, y sabe atravesarlos. En segundo lugar, puede imprimir y establecer una ACL usando una cadena de Lenguaje de definición de descriptores de seguridad (SDDL).
Sin embargo, a pesar de las actualizaciones a cacls.exe, realmente desea la funcionalidad disponible en icacls.exe.

Guardado y restauración de las ACL
Un deseo constante, al menos para mí, durante los últimos 10 años, ha sido la capacidad de guardar una ACL de manera que se pueda restaurar en una fecha posterior. Esto resulta ser una de las operaciones más complicadas que se pueden realizar en las ACL. Excepto en determinados casos especiales, no es probable que pudiera volver exactamente al mismo lugar en el que habría estado si no hubiera arruinado las ACL en primer lugar. No obstante, esta funcionalidad puede ser bastante útil.
Antes de que explique cómo guardar o restaurar las ACL, permítame que trate en primer lugar por qué es tan difícil. Supongamos que tiene una jerarquía que contiene datos de usuario para estudiantes en un colegio local. Guarda la ACL el 1 de febrero. El 17 de abril descubre que, de alguna manera, se ha dañado la ACL y va a restaurarla a partir de la copia guardada. ¿Qué complicaciones podría haber con esta operación?
En primer lugar, el nuevo trimestre empezó el 2 de abril. Aproximadamente el 15 por ciento de los estudiantes se recibieron; por consiguiente, sus directorios ya no existen. Así, tiene unas ACL en el archivo de copia de seguridad que no son válidas. Además, ahora hay un grupo de estudiantes nuevos, otro 15 por ciento, que empezaron en el nuevo trimestre. Tienen directorios principales ahora pero ninguna ACL en el archivo de copia de seguridad. ¿Cuáles deberían ser sus ACL? Luego, por supuesto, todavía tiene el 70 por ciento que siguen allí, pero ellos han creado archivos y carpetas nuevas, y han eliminado otras. Puede omitir las eliminadas pero ¿cómo configura las carpetas nuevas que crearon? ¿Qué pasa si un estudiante ha decidido compartir una carpeta con sus amigos el 4 de marzo? ¿Eliminaría ese recurso compartido al restaurar las ACL?
Guardar y restaurar las ACL no es una operación tan sencilla como muchas personas pueden creer. Tiene que hacerlo con cuidado. Es muy posible, incluso probable, que tenga como resultado algún comportamiento indefinido. La restauración de las ACL es definitivamente un último recurso; cuanto más tiempo haya pasado desde que se realizó una copia de seguridad de la misma, mayores probabilidades habrá de que se interrumpa algo cuando la restaure.
No obstante, se desea intentar esta funcionalidad, ejecute icacls.exe con el conmutador /save:
icacls <target> /save acls.bin /t
De este modo, se guardarían las ACL en un archivo denominado acls.bin y que contendrá una línea para cada objeto con una ACL seguida de una línea que especifica la ACL en SDDL. Mediante conmutador /t, el comando funcionará en el objeto especificado y todos los objetos y los contenedores que se encuentren debajo.
La funcionalidad de guardar es una adición bienvenida al kit de herramientas pero tiene algunos defectos. Por ejemplo, sólo guarda la lista de control de acceso discrecional (DACL), no la lista de control de acceso de sistema (SACL). De hecho, si hay una SACL, guarda un valor ficticio que indica esto, pero no guarda realmente ninguna parte de la SACL.
Además, la manera en que se guarda la ACL crea un problema interesante. Antes de abrir la ACL guardada en el editor de texto, recuerde:
no edite la ACL guardada.
Si fuera a abrir el archivo que contiene la ACL guardada en un editor de texto, encontraría que parece ser un archivo de texto con formato Unicode (UTF-16). De hecho, eso es casi exactamente lo que es. Esto le podría hacer pensar que podría editarlo y guardarlo desde un editor de texto. No lo haga.
Si abre el archivo que contiene las ACL guardadas en un editor de texto y lo guarda a continuación, no podrá restaurar las ACL a partir de dicho archivo. Resulta que no es realmente un archivo de texto Unicode después de todo. Este tipo de archivo debe comenzar con 0xfffe de 2 bytes. Si guarda el archivo con un editor de texto, como por ejemplo el Bloc de notas, colocará de hecho ese marcador en el archivo en los 2 primeros bytes. Sin embargo, la herramienta icacls.exe espera que los datos de ACL comiencen en el byte 0 del archivo. Por consiguiente, la herramienta no podrá analizar las ACL del archivo puesto que espera que los dos primeros bytes formen parte de la cadena que especifica el objeto en el que se debe trabajar. Su archivo de copia de seguridad será inutilizable.
Microsoft conoce este problema pero, como se notificó muy tarde en el ciclo de beta para Windows Vista, este defecto no se corrigió antes del lanzamiento. En estos momentos, no sabemos cuándo, ni siquiera si, se corregirá. Así que por ahora, el mejor consejo es no editar sus ACL guardadas. Si tiene que hacerlo, guarde el archivo como un archivo .bin y use un editor hexadecimal, tal como el entorno de desarrollo que prefiera.
Una vez que haya guardado una ACL usando el conmutador /save, la podrá restaurar usando icacls.exe con el conmutador /restore. El comando de restauración en su forma más sencilla usa esta sintaxis:
icacls <directory> /restore acls.bin
El procedimiento de restauración no funciona en archivos. Para ver esto, consulte el script que se muestra en la figura 1. Aquí creo un archivo para guardar señalando icacls.exe en un archivo. A continuación, intento restaurarlo al sustituir /restore por /save. Se produce un error en esto porque el comando de restauración sólo funciona en directorios. Los archivos que se supone que modifica ya están especificados en el archivo acls.bin. Para restaurar la ACL, la señalo hacia el directorio en lugar del archivo. Esto es lo que hago en el último comando donde especifico "." como el objeto en el que se va a trabajar.
Figure 1 Guardado y restauración de las ACL (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Tenga en cuenta además que el comando de restauración debe ejecutarse elevado. Puede ejecutar el comando para guardar desde un símbolo del sistema que se ejecuta como un administrador de nivel bajo o incluso un usuario estándar, siempre y cuando tenga el derecho para leer la ACL. Sin embargo, para restaurar la ACL, es necesario que tenga un símbolo (token) administrativo completo y puro.

Sustitución de los SID
Otra característica de mucha utilidad en icacls.exe es la capacidad de reemplazar los permisos para un usuario con permisos para un usuario diferente. Esto se realiza durante la restauración usando el conmutador /substitute. La documentación para el conmutador substitute indica que necesita un SID, pero posteriormente explica que esto realmente puede ser también un nombre de usuario normal. Así, la secuencia que se muestra en la figura 2 funciona.
Figure 2 Sustitución de los SID durante la restauración (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
Como puede ver, termino con la misma ACL que tenía antes, pero el ACE que usaba para especificar permisos para foo ahora los especifica para bar en su lugar.

Cambio de propietario
La herramienta chown ha sido un elemento esencial en los sistemas de Unix durante años. Windows originalmente no tenía ninguna manera integrada de cambiar el propietario de un objeto. Entonces vino la herramienta setowner en el kit de recursos. A continuación, obtuvimos la herramienta takeown.exe en Windows NT 4.0 pero esta utilidad sólo le permitía tomar la propiedad, no concederla a los demás a menos que tuviera su contraseña. Ahora icacls.exe le ofrece la capacidad integrada de establecer el propietario de los objetos en los que tiene permiso para establecer el propietario:
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Lamentablemente, icacls.exe no le puede mostrar el propietario de un objeto. No hay manera de ver realmente, en la línea de comandos, quién es el propietario de un objeto. Además, si guarda la ACL para un objeto, no se guarda el propietario del objeto.
También hay un error en icacls.exe en que no invoca SeTakeOwnershipPrivilege para cambiar el propietario. Si tiene el derecho de cambiar el propietario de un objeto basado en la ACL, entonces icacls.exe funciona como debería. Sin embargo, un administrador que no tiene permiso para cambiar el propietario basado en la ACL del objeto no podrá usar icacls.exe para ello debido a dicho error. En ese caso, debe usar la herramienta takeown.exe, que invoca SeTakeOwnershipPrivilege, pero sólo puede cambiar el propietario a su cuenta o el grupo Administradores, no a una cuenta arbitraria:
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Por supuesto, se debe tener en cuenta que la herramienta subinacl, que se puede descargar del Centro de descargas de Microsoft, también tiene un conmutador setowner. En realidad, en muchos casos Subinacl funciona de manera más intuitiva que icacls, pero también es mucho más complicado de usar.

Búsqueda de archivos para un usuario en particular
Icacls tiene otra función útil: puede buscar archivos que tienen permisos para usuarios concretos. Por ejemplo:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Esto podría ser de utilidad si intenta averiguar a lo que puede tener acceso un usuario concreto.

Restablecimiento y cambio de ACL
Si una ACL se ha dañado o se ha destruido, icacls.exe tiene una manera de restablecerla para heredar de su padre. Esto es algo que habría sido muy útil durante un problema de seguridad de día cero que llegó en el otoño de 2006. Un método usado para mitigar el problema en un componente de Windows fue denegar el acceso de todos al objeto. Esa parte fue sencilla pero quitar esa entrada de control de acceso (ACE) fue casi imposible usando herramientas integradas en Windows XP y Windows Server 2003. Sin embargo, en Windows Vista, simplemente ejecutaría este comando:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
por supuesto, Icacls.exe tiene todas las operaciones estándar de concesión, denegación y eliminación. El único elemento realmente nuevo en esa lista es la eliminación. Mediante este conmutador, puede quitar todos los valores "permitir ACE", todos los "denegar ACE" o ambas opciones para un usuario determinado de un objeto o jerarquía específicos. La figura 3 muestra ejemplos de algunas operaciones de concesión, eliminación y denegación.
Figure 3 Operaciones de conceder, denegar y quitar (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
La capacidad de quitar sólo los valores "denegar ACE" puede ser de utilidad si desea abrir el acceso a un objeto hasta un grupo o usuario en particular.

Configuración de niveles de integridad
Icacls.exe también tiene la capacidad de mostrar y establecer niveles de la integridad. Windows Vista admite la colocación de etiquetas de integridad en objetos. Icacls.exe es la herramienta de línea de comandos que se debe usar para ello:
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
Tenga en cuenta que icacls.exe sólo muestra una etiqueta de integridad si un objeto tiene una establecida explícitamente. La mayoría de los archivos no la tienen, por lo que no es habitual que vea una.
Por último, icacls.exe puede comprobar que un objeto tiene una ACL canónica. Como mencioné anteriormente, se ha sabido que las herramientas de terceros colocan las ACE en orden incorrecto en las ACL. Icacls.exe puede comprobar y corregir esos tipos de problemas, tal como se muestra aquí:
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

IU de ACL
La IU de ACL, o la interfaz de usuario de ACL, se modificó ligeramente de la existente en Windows XP. Las figuras 4 y 5 muestran el cuadro de diálogo de la IU de ACL de Windows XP y Windows Vista, respectivamente.
Figura 4 Cuadro de diálogo de la IU de ACL en Windows XP
Figura 4 Cuadro de diálogo de la IU de ACL en Windows XP
Figura 5 Cuadro de diálogo de la IU de ACL en Windows Vista
Figura 5 Cuadro de diálogo de la IU de ACL en Windows Vista
Como puede ver, aquí hay algunos cambios. En primer lugar, el cuadro de diálogo finalmente muestra el objeto en el que está trabajando de manera muy clara, lo cual puede ser de utilidad a la hora de trabajar con varios objetos a la vez. En segundo lugar, hay un hipervínculo a alguna ayuda en la parte inferior. Sin embargo, el cambio más notable se encuentra en la eliminación de los botones Agregar y Quitar, que se reemplazaron por un botón Editar que se presenta en gran medida en apoyo del control de acceso de usuario (UAC) de Windows Vista. Como puede observar por el escudo del botón, el usuario que inició este cuadro de diálogo no tiene permiso para editar la ACL y, por tanto, requerirá la elevación antes de poder editar los permisos. Tenga en cuenta que esto no sería el valor predeterminado si se crea una carpeta en la raíz de la unidad C: y comprueba inmediatamente sus propiedades. Como propietario de la carpeta, tendría permisos implícitos para editar la ACL y el escudo no estaría presente. El escudo indica un Moniker COM, que es un mecanismo usado para iniciar un mensaje de elevación para una parte de un proceso en ejecución. Si hace clic en el botón Editar, obtiene el conocido cuadro de diálogo de elevación, y si hace clic en Continuar en el cuadro de diálogo de elevación, obtiene un cuadro de diálogo que es casi idéntico al que obtiene en Windows XP cuando hace clic en el botón Agregar. La interfaz de usuario de ACL sigue este concepto de doble cuadro de diálogo en varios lugares; obtiene un cuadro de diálogo hasta que eleva, y una vez que lo hace, obtiene el conocido cuadro de diálogo anterior de las versiones anteriores de Windows.
Si hace clic en el botón Opciones avanzadas y, a continuación, en la ficha Autoría, siempre obtendrá un botón de elevación, tal como se muestra en la figura 6. No es posible modificar la auditoría sin elevar, aunque tenga un control total sobre el objeto y sea el propietario. Esto se debe a que la capacidad de modificar una SACL de objeto se rige por el privilegio SE_SECURITY_NAME, conocido como "Administrar registro de seguridad y auditoría" en las herramientas de GUI. Sólo los administradores tienen ese derecho de forma predeterminada. Sin embargo, el privilegio se quita de un administrador en el modo de la aprobación de administración (cuando UAC está habilitado), necesitando la elevación aunque sea administrador.
Figura 6 La modificación de la configuración de la auditoría en Windows Vista requiere siempre elevación
Figura 6 La modificación de la configuración de la auditoría en Windows Vista requiere siempre elevación
Una nota final sobre las necesidades de elevación cuando modifica las ACL: todas estas instrucciones dependen de que no se deshabilite UAC. Si deshabilita UAC, se revierte todo el comportamiento a lo que tenía en Windows XP, a excepción de los cuadros de diálogo que tienen un aspecto diferente. Sin embargo, no se requerirá ninguna elevación, siempre y cuando inicie sesión como administrador ya que el símbolo (token) tendrá ahora el SID de administradores todo el tiempo.

Otras herramientas
Icacls.exe es una herramienta muy útil y una importante mejora respecto a cacls.exe, pero sufre todavía de algunos puntos débiles. Quizá lo más notable es que no puede administrar el acceso a ningún objeto que no sean archivos y directorios. Windows Vista realiza cambios escasos a las ACL de otros objetos en comparación con Windows XP, pero todavía hay ocasiones en las que desee administrar las ACL en un servicio, una clave del Registro o incluso un objeto de Active Directory®.
Si usted es un adicto a la línea de comandos, necesita subinacl.exe para hacer esto. Subinacl.exe se encuentra en las herramientas de soporte y también está disponible como una descarga.
De todas formas, tengo que advertirle de que subinacl.exe no es fácil de usar. De hecho, es completamente obtuso a veces. Sin embargo, subinad.exe es una herramienta increíblemente eficaz para administrar el control de acceso. Todos los administradores avanzados necesitan esta herramienta.

ACL del Registro
Al igual que las ACL del sistema de archivos, las ACL del Registro también han experimentado cambios. Sin embargo, los cambios tienen un ámbito mucho más pequeño que el de los cambios al sistema de archivos. La diferencia más obvia en comparación con versiones anteriores de Windows es que, puesto que los Usuarios avanzados ahora son obsoletos, casi todas las ACE de Usuario avanzado han desaparecido. No se supone que los Usuarios avanzados sean más poderosos que cualquier otro usuario. No obstante, un testamento de lo complicado que son realmente las ACL es que no todas las ACE para Usuarios avanzados han realmente desparecido. Lamentablemente, algunas se pasaron por alto.
Mientras mira en las ACL en el Registro, en algunos lugares verá una ACE para un SID denominado RESTRICTED. Esto no es una novedad para Windows Vista, pero es un SID interesante y poco comprendido. El SID RESTRICTED denota cualquier proceso que presenta un símbolo (token) restringido. Un símbolo (token) restringido se crea usando una característica especial de la API de CreateRestrictedToken. Dicho símbolo (token) tiene uno o más SID restringidos; SID que se usan en una comprobación de acceso independiente. Supongamos que tenemos un proceso que se ejecuta con un símbolo (token) restringido. Si ese proceso intenta obtener acceso a un objeto con una ACE para el SID RESTRICTED, en realidad Windows realiza dos comprobaciones de acceso. La primera es la comprobación de acceso normal. La segunda funciona exactamente como la primera pero se produce únicamente frente a los SID que restringen en el símbolo (token). Se deben superar ambas comprobaciones de acceso.
Actualmente, hay varias ACL que usan el SID RESTRICTED, especialmente en el registro. Una captura de pantalla de dicha ACL se muestra en la figura 7.
Figura 7 Las ACL del Registro incluyen una ACE para RESTRICTED en varios lugares
Figura 7 Las ACL del Registro incluyen una ACE para RESTRICTED en varios lugares
En estos momentos, pocos procesos usan la funcionalidad de símbolo (token) restringida, especialmente con respecto a los SID de restricción. Un ejemplo de un proceso que sí lo hace es el proceso del servicio que hospeda el Firewall de Windows, el motor de filtro de base y el servicio de directivas de diagnóstico. También usa un símbolo (token) restringido contra escritura. Según mis conclusiones, sólo nueve servicios usan actualmente los símbolos (token) restringidos contra escritura y RESTRICTED en Windows Vista.
Al igual que con versiones anteriores recientes de Windows, la recomendación con respecto a los permisos del Registro es ir con mucho cuidado. Con la excepción de circunstancias excepcionales y sumamente dirigidas, no modifique permisos en el Registro. Dado el complicado modelo de herencia y las operaciones confidenciales realizadas en el Registro, existe una probabilidad inaceptablemente alta de que se produzca un error grave si modifica las ACL en el Registro sin tener cuidado.

Resumen
Al igual que con la mayoría de las versiones de Windows, hay algunos cambios sutiles en el control de acceso de Windows Vista. Sin embargo, a diferencia de algunas de las otras versiones recientes, en realidad se han producido un gran número de cambios secundarios que, en conjunto, representan un cambio considerable en el comportamiento. El UAC, en concreto, requirió varios cambios, como por ejemplo, las etiquetas de integridad y las modificaciones a la interfaz de usuario de ACL. Además, tenemos la primera gran limpieza de las ACL de la historia documentada.
En muchos sentidos, en realidad las ACL predeterminadas de Windows se simplificaron en Windows Vista, algo que nunca ha sucedido antes. Sin embargo, al igual que en las versiones anteriores, debería ir con mucho cuidado en lo relacionado con el control de acceso hasta que lo comprenda completamente. Esto es especialmente cierto con las versiones nuevas del sistema operativo. Con suerte, mediante las herramientas resumidas en este artículo, podrá hacer que la exploración de las ACL sea mucho menos dolorosa.

Jesper M. Johansson es ingeniero de seguridad principal que trabaja en problemas de seguridad de software y contribuye como editor en TechNet Magazine. Tiene un doctorado en MIS y más de 20 años de experiencia en el ámbito de la seguridad de sistemas. Este artículo está adaptado del nuevo libro de Roger Grimes y Jesper Johansson, Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).


 Archivos del escritorio: Paquete de optimizaci&#243;n de escritorio de Microsoft
Archivos del escritorio
Paquete de optimización de escritorio de Microsoft
Wes Miller
Esta columna se basa en elementos de versión preliminar del Paquete de optimización de escritorio de Microsoft. Por tanto, toda la información de este documento está sujeta a cambios.

Desde el principio del programa de licencias de Software Assurance (SA) hace varios años, Microsoft ha buscado continuamente agregar características a SA de manera que los clientes encuentren un valor aumentado con el tiempo. Además de ofrecer actualizaciones para productos de Microsoft incluidos en la licencia, la compañía ha procurado ofrecer
productos y tecnologías (Windows® PE fue uno de los primeros, por ejemplo) que puedan ayudar a una organización a mejorar su experiencia con Windows, Office y otro software de Microsoft.
El enfoque de muchas de estas herramientas y programas ha sido para que Microsoft ofrezca capacidades adicionales para reducir el costo general de la propiedad de Windows, Office y otras aplicaciones de Microsoft incluidas en la cobertura de SA de una organización.
Microsoft adquirió varias compañías en 2006 y todas tenían agendas similares: reducir el costo de la propiedad y la complejidad asociados con la administración y reparación de Windows y aplicaciones basadas en Windows. Microsoft combinó varias de estas tecnologías recientemente adquiridas en una nueva oferta de producto, disponible como valor agregado para los clientes que tienen SA. Las tecnologías de Softricity, DesktopStandard, AssetMetrix y Winternals Software estarán disponibles en los próximos años como componentes del Paquete de optimización de escritorio de Microsoft® (MDOP). Además, MDOP incluirá un componente que Microsoft creó internamente, denominado Microsoft System Center Desktop Error Monitoring.
En cuanto a los ahorros, Microsoft estima que MDOP puede ayudar a ahorrar a la organización entre 100 dólares y 500 dólares estadounidenses al año por escritorio, en función de las recomendaciones que implemente al usar MDOP. Puede obtener más información acerca de MDOP en windowsvista.com/optimizeddesktop.

Objetivos del Paquete de optimización de escritorio de Microsoft
El objetivo principal de MDOP es, en resumen, permitir a Microsoft ofrecer nuevas tecnologías de administración mediante una programación más ágil, en lugar de tener que enlazarlas a nuevas versiones del sistema operativo. Evidentemente, Microsoft desea asegurar que el intervalo de tiempo que existió entre Windows XP y Windows Vista™ no se produce otra vez. Sin embargo, al ofrecer herramientas en un marco temporal previsible entre versiones, MDOP permitirá a Microsoft satisfacer de manera flexible las necesidades de sus usuarios, y esto permitirá a los clientes empresariales maximizar el valor de sus inversiones en software.
Para ayudar a que las empresas sean más ágiles, Microsoft ha buscado una estrategia que pueda ayudar a los clientes a moverse a una infraestructura más dinámica: es decir, dinámica en el sentido que Microsoft define con su iniciativa de sistemas dinámicos (DSI). Para obtener más información acerca de DSI, lea la información disponible en microsoft.com/business/dsi.
Bueno, ya hemos hablado suficiente de la estrategia de alto nivel. Echemos un vistazo a cada una de las cinco tecnologías incluidas en MDOP:
  • SoftGrid Application Virtualization
  • Asset Inventory Service
  • Diagnostics and Recovery Toolset
  • Advanced Group Policy Management
  • System Center Desktop Error Monitoring

SoftGrid Application Virtualization
SoftGrid Application Virtualization, que se adquirió de Softricity, ofrece como su nombre indica, la virtualización de la aplicación. Cuando empecé a examinar SoftGrid, me di cuenta que es lo que debería haber sido la publicación de aplicaciones para Windows 2000 IntelliMirror®. ¿Por qué? Porque las aplicaciones no se publican a los clientes, están completamente virtualizadas. Esto permite a las aplicaciones estar fácilmente disponibles en sistemas cliente (o Terminal Server). Igual de importante, las aplicaciones pueden administrarse de manera centralizada e incluso se pueden reinvocar o actualizar según sea necesario. En comparación con el modelo tradicional de transformaciones y MSI, el modelo de SoftGrid hace la implementación de la aplicación apreciablemente menos penosa y menos arriesgada.
Una forma de pensar en SoftGrid es considerarlo como una imagen virtual. Es posible que conozca el concepto de una imagen de disco usada para implementar Windows (y a menudo, las aplicaciones incorporadas) en sistemas. SoftGrid, en esencia, toma la aplicación y la incluye en una imagen de aplicación, en lugar de en una imagen completa del sistema operativo.
SoftGrid Application Virtualization comprende tres componentes clave: virtualización de aplicaciones, entrega de aplicaciones y consola de administración central.
La virtualización de aplicaciones en sí se compone de representaciones virtuales del sistema de archivos de Windows (incluidos los archivos de sistema), el Registro de Windows, fuentes, archivos .ini, objetos COM/DCOM, servicios, objetos de kernel (semáforos, exclusiones mutuas), objetos denominados y espacios de nombres de todos los componentes.
Es importante que no confunda la virtualización de SoftGrid con la manera en la que UAC de Windows Vista lleva a cabo el redireccionamiento. Con UAC, cuando una aplicación intenta escribir o modificar áreas protegidas del Registro o del sistema de archivos, se redirecciona a una vista específica del usuario del Registro y del sistema de archivos. Por otra parte, SoftGrid usa un concepto de virtualización verdadera de la aplicación al sistema operativo, incluidos todos los componentes del sistema de archivos y del Registro que lo componen. Pero la elegancia de SoftGrid es que no es un BLOB único que define una aplicación. En cambio, consiste en:
  • Un archivo SFT de hasta 4 GB que contiene una o más aplicaciones y todas sus dependencias excepto las dependencias de Windows, que se espera que se encuentren en los sistemas de destino.
  • Un archivo OSD de aproximadamente 2 KB que contiene una definición de la manera en la que se puede solicitar y ejecutar la aplicación. Puede pensar en el archivo OSD como un EXE.
  • Un archivo ICO de cerca de 24 KB que es, efectivamente, un método abreviado para iniciar la aplicación.
  • Un archivo SPRJ de cerca de 13 KB que el secuenciador (el núcleo de SoftGrid) usa para publicar, abrir, actualizar y reparar los paquetes existentes.
Un diagrama completo de la manera en que funciona SoftGrid Application Virtualization está disponible en el sitio web softricity.com/ products/architecture.asp.
Una importante ventaja de la solución de SoftGrid es que se puede usar una consola de administración central (consulte la figura 1) para determinar qué aplicaciones están disponibles para un usuario en particular o conjunto de usuarios de Active Directory®. A continuación, esas aplicaciones se pueden transmitir rápidamente a usuarios a petición mediante un protocolo de transmisión por secuencias estándar del sector. Una vez instaladas, las aplicaciones se comportan como si se hubieran instalado localmente, respetan la configuración personalizada del usuario (incluso mediante Perfiles móviles de usuario) y funcionan incluso cuando los clientes se desconectan de la red. Los administradores incluso pueden detener las aplicaciones para que no estén disponibles, ni dinámica ni automáticamente (después de un tiempo fijo, por ejemplo).
Figura 1 Consola de administración de SoftGrid
Figura 1 Consola de administración de SoftGrid
Lo que es más importante, debido a la manera en que se implementan las aplicaciones, no es necesario que toda una aplicación se haga disponible. En cambio, sólo se descargan los fragmentos necesarios para ejecutar la aplicación que está usando el usuario. Imagínese una situación en la que todo Microsoft Office se hace disponible como un paquete. Si un usuario sólo ejecuta Word, únicamente se descargan los componentes necesarios para ejecutarlo; se descargan no los fragmentos necesarios para ejecutar Excel®,PowerPoint®, etc. Tan pronto como el usuario ejecuta una de esas aplicaciones (Excel, por ejemplo), se extraen sus componentes asociados según sea necesario.
¿Qué se encuentra en ERD?
  • Command prompt
  • Explorador
  • Buscar
  • Bloc de notas
  • Solution Wizard
  • Herramientas administrativas: Autoruns, Disk Management, Event Viewer, Registry Editor, Services and Drivers, System Information
  • Herramientas de red: File Sharing, Map Network Drive, TCP/IP Configuration
  • Herramientas del sistema: Crash Analyzer, Disk Commander, DiskWipe, FileRestore, Hotfix Uninstall, Locksmith, System File Repair, System Restore

Otro componente de SoftGrid es su capacidad de realizar la comprobación de licencias y medición automáticas. Esto le ayuda a mantener la compatibilidad con la licencia de software sin necesitar software adicional.
Es posible virtualizar casi cualquier aplicación. Las excepciones clave son Internet Explorer® y otros componentes de Windows (incluidas las revisiones y los Service Pack), software antivirus y controladores de dispositivos. Si está interesado en examinar con mayor profundidad el funcionamiento de SoftGrid y en explorar lo que puedo hacer, recomiendo que consulte el artículo disponible en Softricity.com.

Advanced Group Policy Management
DesktopStandard se hizo conocido al desarrollar herramientas que unían algunos de los vínculos débiles en la directiva de grupo. Al ofrecer la herramienta anteriormente conocida como GPOVault en MDOP y ahora conocida como Administración avanzada de directivas de grupo, Microsoft ha ofrecido a los clientes una estupenda herramienta que puede llevar a GPO desde un proceso eficaz (y a veces peligroso) a un proceso mucho más refinado y controlado.
Si conoce los fundamentos del software de control de origen, imagínese la Administración avanzada de directivas de grupo como el control de origen para sus directivas de grupo de Active Directory. (Consulte la figura 2 para obtener una captura de pantalla de la consola de Administración avanzada de directivas de grupo.) Los administradores desprotegen las revisiones de directiva existentes, realizan cambios y los protegen de nuevo, auditando los resultados mediante informes similares a la Consola de administración de directivas de grupo. Una vez que el administrador está satisfecho de que se haya alcanzado la condición de directiva deseada, puede confirmar los cambios y hacerlos activos. Como buen software de control de origen, cuando se produce un error, los cambios se pueden revertir rápidamente y sin riesgos a una revisión anterior sin ninguna de las suposiciones que se producirían generalmente en dicho proceso.
Figura 2 Consola de Administración avanzada de directivas de grupo
Figura 2 Consola de Administración avanzada de directivas de grupo
Otro aspecto clave de este proceso es la capacidad de editar directivas sin conexión, en lugar de requerir que los cambios se realicen todo en sistemas activos y en línea. Esto permite la realización de pruebas aisladas de los cambios antes de que éstos se realicen en todo el dominio u OU.
Por último, a través de un modelo basado en funciones, la Administración avanzada de directivas de grupo permite dirigir los cambios a través de un proceso de flujo de trabajo diseñado. Con la creación de funciones (como por ejemplo, editor, revisor y aprobador), un administrador puede asegurarse de que se aplique un proceso que permitirá que se realicen cambios de una manera controlada. Así, cuando el implementador cree que el cambio está listo para confirmarse, puede tener un fuerte mecanismo de control de cambios para asegurarse de que los cambios de GPO de reacción automática no se produzcan sin la aprobación adecuada.

Asset Inventory Service
Asset Inventory Service, compuesto de la tecnología que Microsoft obtuvo a través de la adquisición de AssetMetrix, es una solución de administración de activos y de inventarios muy eficaz. A diferencia de los demás componentes de MDOP, AIS emplea un modelo web hospedado. AIS usa un agente de banda ancha baja y de superficie muy baja, que se puede ejecutar una vez o en intervalos periódicos, permitiendo a un administrador buscar aplicaciones a través de una base de datos increíblemente extensa hospedada por Microsoft y de más de 400.000 aplicaciones para determinar que está instalado en sistemas de cliente. AIS entonces puede tomar estos datos acumulados y conciliarlos con las licencias adquiridas para asegurar el cumplimiento y reducir el desecho debido a la compra excesiva de licencias.
Inicialmente, algunos administradores pueden tener dudas a la hora de usar AIS dado que es un modelo hospedado fuera del firewall y que realiza inventarios de sistemas internos para el software instalado. Sin embargo, es importante entender el trabajo extenso que Microsoft ha realizado para garantizar la privacidad de la organización, empezando por rescribir los componentes de la aplicación que componen AIS. No hay ninguna unión de los datos de equipo individuales a ningún dato de organización. Microsoft también certificará la tecnología de transferencia de datos con un tercero para asegurarse de que los clientes estén cómodos con el modelo usado por AIS.

Diagnostics and Recovery Toolset
Como quizá sepa (si ha leído alguna vez la biografía en mis columnas durante los últimos meses), formaba parte de Winternals cuando lo adquirió Microsoft. Fui el director de productos de la mayoría de los productos de Winternals durante mi ocupación allí, incluido el paquete del administrador de Winternals. Éste fue el predecesor de Microsoft Diagnostics and Recovery Toolset (DaRT). Si bien algunas de las herramientas que han existido anteriormente en el paquete del administrador no se incluyen en DaRT, los componentes clave que componían el producto ERD Commander todavía están disponibles.
El objetivo de DaRT es ofrecer un conjunto de herramientas que puedan ayudar a diagnosticar problemas del sistema, incluso si un sistema no se arrancó correctamente. Además, a menudo puede reparar dichos problemas sin conexión.
ERD Commander usa Windows PE para arrancar un sistema que no se arranca o no se arranca normalmente. En una interfaz de usuario personalizada similar al Explorador de Windows, hay un conjunto de herramientas disponible. Dos de estas herramientas, Crash Analyzer y FileRestore, también están disponibles para el uso en línea. Sin embargo, si no usa ERD Commander para la recuperación o el diagnóstico sin conexión, estas herramientas se deben instalar en todos los sistemas en los que desee ejecutarlas.
La versión de DaRT de ERD Commander se muestra en la figura 3. En la barra lateral encontrará una lista de las herramientas incluidas en el componente de ERD Commander. A excepción de la herramienta Explorador, las primeras cinco herramientas mostradas son las mismas aplicaciones que usaría en una instalación normal de Windows. El Explorador es, al igual que la aplicación de menú Inicio desde la que se inicia, una versión especializada (menor) desarrollada para ejecutarse en Windows PE.
Figura 3 ERD Commander
Figura 3 ERD Commander
Autoruns es una herramienta obtenida de una herramienta de Sysinternals del mismo nombre y que permite ver todas las aplicaciones que están establecidas para iniciarse cuando arranca el sistema o un usuario inicia sesión. Disk Management, Event Viewer, Services and Drivers y System Information son herramientas que conviven dentro de una interfaz de usuario común y ofrecen experiencias comparables a las herramientas de nombre similar que se encuentran en Windows. Services and Drivers es de especial utilidad en el sentido de que puede ayudar a arrancar el sistema cuando éste tiene un error debido a que un controlador de dispositivo o servicio no funciona correctamente. Por último, se incluye Windows Registry Editor para que pueda manipular el Registro de un sistema sin conexión.
Las funciones de red también están disponibles bajo ERD Commander. Aunque el sistema está configurado automáticamente mediante DHCP, puede establecer una dirección IP estática usando el applet TCP/IP Configuration. Independientemente de si usa DHCP o direccionamiento IP estático, puede asignar una unidad de red y copiar archivos del sistema inactivo o usar el uso compartido de archivos para convertir el sistema en un servidor de archivos de manera que pueda usar un sistema en funcionamiento para copiar archivos desde el sistema con errores.
Por último, también se incluye una colección de herramientas variadas. Crash Analyzer usa las herramientas de depuración para Windows (que se deben descargar e instalar de manera independiente; son gratuitas pero se actualizan con frecuencia) para realizar un diagnóstico de la causa de un bloqueo. Puede ejecutarlo sin conexión bajo ERD Commander si el sistema no se arranca o copiar un archivo DMP a un sistema en ejecución con DaRT instalado y diagnosticarlo allí. Una vez precisado, si el culpable es un servicio o controlador nuevos, puede usar la herramienta Services and Drivers para deshabilitarlo y ver si el sistema vuelve a funcionar con normalidad.
Disk Commander le puede ayudar a recuperar una partición que se ha eliminado o dañado de manera accidental, así como un grupo de archivos o un directorio eliminado. En el extremo opuesto del espectro, DiskWipe le permite completar el borrado de volumen o disco compatible con DoD. FileRestore le permite (con o sin conexión) recuperar un archivo único que se puede haber eliminado de manera accidental. Tenga en cuenta que el tipo de archivo y la actividad de tiempo/disco desde la eliminación afectará a la capacidad de recuperación, independientemente de la herramienta que use.
En el caso de que una revisión o Service Pack de Windows impida que el sistema se arranque con normalidad, puede usar Hotfix Uninstall para desinstalar de manera selectiva una o más revisiones o Service Packs. Es necesario volver a arrancar el sistema para completar el proceso, puesto que Windows no admite la eliminación completa sin conexión de las aplicaciones. Sin embargo, a menudo puede hacer que pueda volver a arrancar el sistema.
Locksmith era una de las herramientas más populares incluidas en el conjunto de herramientas de ERD Commander de Winternals. Le permite restablecer la contraseña de cualquier usuario local. No funciona en controladores de dominio y no puede restablecer ninguna contraseña de usuario de dominio; normalmente, se usa para restablecer la contraseña del administrador local cuando se ha olvidado o el usuario ha dejado la organización. System File Repair analizará todos los archivos protegidos del sistema y los investigará para ver si cualquiera está dañado y los reemplazará según sea necesario. System Restore, como el nombre implica, permite revertir o avanzar hasta cualquier punto de la restauración de sistema de Windows en un sistema Windows XP. (Se requiere Windows XP con puntos de restauración preexistentes para usar esta funcionalidad.) Estoy entre los muchos usuarios para los que esta exclusiva funcionalidad ha salvado la vida.
Las herramientas de ERD Commander y DaRT pueden parecer algo aleatorias, pero son una compilación eficaz de utilidades que Winternals ha desarrollado con el tiempo. Estoy seguro de que verá su valor y las considerará de gran utilidad a la hora de realizar sus tareas de recuperación y solución de problemas.

System Center Desktop Error Monitoring
System Center Desktop Error Monitoring (DEM) ofrece una manera rápida y sencilla para que cualquier organización centralice y diagnostique bloqueos de Windows y de aplicaciones. En lugar de enviar informes de bloqueo o sobre que el sistema no responde a Microsoft, DEM usa la directiva de grupo y la generación de informes de errores de Windows integrada para enviar informes a un servidor que designe dentro de su organización para el diagnóstico (y no requiere ningún agente de software adicional). Todos los datos del servidor de DEM se almacenan en una base de datos de SQL Server, de manera que puede consultar con facilidad los datos recopilados para sus propios informes y aplicaciones internas. Esto le permite diagnosticar los problemas dentro de su organización de forma proactiva. Mediante esta información, puede encargar informes de dichos incidentes, descubrir las causas más frecuentes de bloqueos y asegurar que las revisiones de aplicaciones y Windows tienen prioridad con el fin de minimizar o eliminar el tiempo de inactividad del sistema.
También puede configurar el servidor de DEM para que cargue los resultados a Microsoft, así como para que DEM descargue automáticamente los datos de solución de problemas más recientes para las aplicaciones de Microsoft y de terceros. Se pueden recopilar datos adicionales de clientes en el caso de un bloqueo o que el equipo no responda.

Licencias de MDOP
El primer requisito para que un cliente adquiera una licencia de MDOP es un contrato de Microsoft SA existente. Una vez en la mano, los costos de licencias son a partir de 7,00 a 10,00 dólares por escritorio. Tiene a su disposición descuentos por volumen y precios para entidades de enseñanza.
MDOP no está disponible fuera del contexto de un contrato SA, con una excepción: Los clientes que deseen usar las tecnologías de SoftGrid con Terminal Server (consulte softricity.com/solutions/sbc.asp) o SMS (consulte softricity.com/products/softgrid-sms.asp) pueden hacerlo, y las tecnologías de AssetMetrix estarán disponibles en versiones futuras de SMS y System Center Configuration Manager.

Disponibilidad y actualizaciones
Los componentes iniciales de MDOP están disponibles ahora mismo. Los componentes se suministran de la siguiente manera:
  • SoftGrid está disponible de Microsoft desde principios de 2007.
  • Microsoft DaRT está desde mayo de 2007.
  • Las tecnologías de GPOVault deberían estar disponibles en julio de 2007.
  • Desktop Error Monitoring debería estar disponible en MDOP en julio de 2007.
  • Las tecnologías de AssetMetrix deberían estar disponibles en la versión beta en julio de 2007 y estarán disponibles para el lanzamiento en agosto.
  • Se planea realizar una actualización a los componentes de DaRT para finales de 2007, siendo la mejora clave la compatibilidad con Windows Vista.
Está previsto que para las versiones futuras de MDOP las mejoras, actualizaciones y nuevas características se ofrecerán dos veces al año.

Dirección de MDOP
Como se ha mencionado, los componentes clave de las tecnologías de AssetMetrix se integrarán en versiones futuras de System Center Configuration Manager. De hecho, puede esperar que, con el tiempo, conforme Microsoft evoluciona la funcionalidad de MDOP, algo pasará poco a poco a la implementación base de la administración y las tecnologías de configuración de Microsoft. A continuación, nuevas tecnologías (algunas creadas por Microsoft, otras adquiridas de otras compañías), estarán disponibles en versiones futuras de MDOP. En esencia, MDOP será un paquete en evolución de las tecnologías vanguardistas de administración y configuración.

Wes Miller es director de desarrollo de Pluck en Austin, Texas. Anteriormente, trabajó en Winternals Software, en Austin, y en Microsoft como administrador de programas y administrador de producto para Windows. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.
Deseo expresar mi gratitud a Chad Jones y Gavriella Schuster, directores de producto para el Paquete de optimización de escritorio de Microsoft, por haberme ayudado con esta columna.


 Confidencial de Windows: Poderes curativos del modo seguro
Confidencial de Windows
Poderes curativos del modo seguro
Raymond Chen

Cuando el modo seguro de Windows (también conocido como el modo "está todo desordenado, por favor, corríjalo") se desarrolló por primera vez para Windows® 95 y estaba diseñado para hacer más que sólo deshabilitar controladores. También se ideó para corregir problemas que se podían reparar automáticamente.
Por ejemplo, cuando inicia en el modo seguro, el Explorador de Windows comprueba las posiciones de todos los iconos en el escritorio, asegurándose de que todos son visibles porque es posible crear una condición en la que un icono se coloca fuera de la pantalla.
Si desea ver de lo que estoy hablando, coloque dos iconos en el escritorio, uno en el borde izquierdo y otro, en el borde derecho. Use Ctrl + clic para seleccionar ambos iconos y, a continuación, tome el izquierdo y arrástrelo al lado derecho de la pantalla. Cuando haga esto, el segundo icono también se moverá, manteniendo la misma posición relativa al icono que arrastra. Y el segundo icono se mueve fuera de la pantalla.
El modo seguro permite a los usuarios realizar la solución de problemas de Windows
El modo seguro permite a los usuarios realizar la solución de problemas de Windows
Si el Explorador de Windows no reparó las posiciones de los iconos en el modo seguro, las instrucciones para la solución de problemas serán más confusas que útiles:
  1. Inicie el equipo en el modo seguro. (Muy bien.)
  2. Haga doble clic en el icono Mi PC. (Pues no veo ningún icono Mi PC.)
  3. ...
Vaya, el icono Mi PC está fuera de la pantalla o no disponible de otra manera. Ni siquiera puede pasar del paso dos del solucionador de problemas.
Ha habido quejas de algunas personas que decían que "no se deberían reparar los iconos automáticamente. Si un usuario llama al soporte técnico con el problema, el ingeniero de soporte técnico puede decir simplemente al usuario que haga clic con el botón secundario del mouse en el escritorio y seleccione la opción para restablecer las posiciones de icono. Misión cumplida y el modo seguro no tocado mis iconos".
Ante todo, ya ha perdido el juego cuando dice "si un usuario llama al soporte técnico con el problema". Si un usuario tiene llamar por teléfono, ha fallado.
Además, esta propuesta se olvida de la psicología del modo seguro. Los usuarios arrancan en el modo seguro cuando las cosas no funcionan correctamente aunque no necesariamente sepan lo que deben hacer una vez que están allí. Lo que realmente hacen es sólo ver lo que sucederá. "Algo está mal, vamos a probar el modo seguro." En Windows 95, aprovechamos esta psicología al implementar distintos tipos de acciones de reparación automática en el modo seguro. Funcionó bastante bien.
Además, si los usuarios llaman y les dice, "arranque en el modo seguro; eso lo corregirá", ellos pensarán, "bueno, eso fue bastante sencillo. Debería haber pensado en eso".
Pero si les da una larga serie de instrucciones, diciendo "arranque en el modo seguro, haga clic aquí con el botón secundario del mouse, seleccione esta opción de menú y, a continuación, haga clic en este cuadro", los usuarios seguirán las instrucciones y el problema se corregirá pero esto no habrá hecho nada para que se sientan más cómodos con los equipos. En cambio, se sentirán débiles y desalentados. En lugar de estar reforzados, los usuarios caen en una condición de incapacidad aprendida. "No hay manera de que hubiera solucionado eso. Los equipos son muy difíciles de usar."

Raymond Chen The Old New Thing, y en su libro del mismo nombre (Addison-Wesley, 2007) se trata la historia de Windows y la programación de Win32. Prefiere escapar antes de que se encienda la mecha.