 TechNet Magazine December 2007

TechNet Magazine December 2007

Comunicaciones: 16 funciones nuevas en Exchange Server 2007 Service Pack 1

A diferencia del service pack normal, Exchange Server 2007 Service Pack 1 ofrece mucho más que simples revisiones y actualizaciones de seguridad. Lea esta información general de algunas de las nuevas funciones y capacidades más importantes que ofrece SP1.

Tony Smith Comunicaciones: Replicación continua en espera en Exchange Server 2007 Service Pack 1

Una de las características más espectaculares que ofrece Service Pack 1 es la replicación continua en espera. Descubra cómo puede ayudarle a mejorar el tiempo de actividad, a limitar la pérdida de datos y a simplificar el mantenimiento y la retención del correo electrónico.

Scott Schnoll Comunicaciones: Ejecución de Exchange con Windows Server 2008

¿Preparándose para ejecutar Exchange en Windows Server 2008? El equipo de desarrollo de Microsoft Exchange lo ha estado haciendo esta última temporada y Paul Bowden comparte algún consejo y las lecciones que han aprendido para ayudarle a estar preparado.

Paul Bowden Comunicaciones: Implementación de Mensajería unificada con Exchange Server 2007

La combinación del correo de voz, capacidades de fax y mensajería de correo electrónico en un único buzón puede parecer una tarea desalentadora. Sin embargo es más fácil de lo que cree. A continuación le presentamos una guía para implementar mensajería unificada en su organización.

Jeff Goodwin Seguridad: Una guía a la informática forense básica

Conozca formas económicas y fáciles de acercarse a la informática forense que los administradores estándar pueden usar para investigaciones básicas.

Tom Cloward and Frank Simorjay Redes: Informe de inteligencia en seguridad de Microsoft

Microsoft recopila muchos datos acerca de las amenazas de seguridad con las que se enfrentan los usuarios. Lea una descripción general acerca de las tendencias recientes, cuál ha sido la respuesta de varias versiones de Windows, qué regiones del mundo son las más afectadas y mucho más.

Tim Rains Redes: Localizar problemas de red esquivos

Tiene un equipo que no se comunica con otros equipos por ninguna razón obvia. Estas sugerencias le pueden ayudar a diagnosticar y reparar el problema rápidamente.

Christopher Stoneff Nota del editor: Comencemos ya la conversación

Joshua Hoffman Cartas: Comentarios de los lectores

Cuadro de herramientas: Nuevos productos para profesionales de TI

Greg Steen Preguntas y respuestas acerca de SQL: Configuración de la memoria, elaboración de perfiles de rendimiento, configuración del factor de relleno y mucho más

Edited by Nancy Michell Utility Spotlight: Herramienta de evaluación de seguridad de Microsoft

Esta utilidad gratuita y el cuestionario electrónico pueden ayudar a las medianas empresas a identificar y resolver riesgos de seguridad en la red.

Lance Whitney The Cable Guy: Servidor de directivas de redes

El servicio Servidor de directivas de redes (NPS) en Windows Server 2008 reemplaza al Servicio de autenticación de Internet usado en Windows Server 2003 y presenta varias mejoras, desde la capacidad de exigir los requisitos de estado de sistema a la mejora de las capacidades de administración.

Joseph Davies Windows PowerShell: Profundización

Windows PowerShell ofrece muchas características que suelen pasarse por alto. Adoptando un enfoque metódico en la exploración de los cmdlets de Windows PowerShell, descubrirá algunas capacidades eficaces que no había observado todavía.

Don Jones ¡Hola, encargados del scripting!: El retorno de WinRM

¿Lo hizo el mayordomo? ¿Fue en la despensa con el candelabro? Aquí no se responde a ninguna de estas preguntas. Pero después de cuatro semanas largas, los encargados del scripting vuelven con la segunda parte de su serie en dos entregas acerca de WinRM.

The Microsoft Scripting Guys Vigilancia de seguridad: Directivas de contraseñas de dominio de Windows

Hasta ahora, Windows sólo permitía una única directiva de contraseñas por dominio. Sin embargo, Windows Server 2008, permite a los administradores implementar varias directivas de contraseñas, adaptando diferentes directivas a diversos tipos de usuarios.

Derek Melber Archivos del escritorio: Implementación de Windows en un mundo virtual

¿Pensando en la virtualización? ¿No? Pues debería empezar a hacerlo. Averigüe lo que necesita saber para implementar sistemas virtuales, lo que debe evitar y cómo funcionan las interioridades de la virtualización.

Wes Miller Notas de campo: El futuro fungible

Los distintos aspectos de TI se han ido aproximando al consumidor a medida que la tecnología y la percepción de la vida personal se han fusionado con la tecnología y la percepción de la vida profesional. Y los efectos tanto en la vida personal como en la profesional son profundos.

Romi Mahajan Confidencial de Windows: Un joystick no tiene que ser un microondas

Una mirada a la forma en la que la interfaz de joystick con fuerza de respuesta DirectInput especifica las fuerzas periódicas y algunos de los resultados inesperados.

Raymond Chen


 Comunicaciones: 16 funciones nuevas en Exchange Server 2007 Service Pack 1
Comunicaciones Tony Smith

16 funciones nuevas en Exchange Server 2007 Service Pack 1
Resumen:
  • Nuevas funciones de administración
  • Funciones de servidor mejoradas
  • Mensajería unificada mejorada

La mayoría de los administradores conocen el proceso de descarga y aplicación de Service Packs para servidores y sistemas de escritorio. Estas descargas, por supuesto, ofrecen revisiones y actualizaciones de seguridad que
ayudan a mantener los sistemas actualizados. Sin embargo, algunas veces un Service Pack incluye algo más. Es el caso del próximo lanzamiento de Microsoft® Exchange Server 2007 Service Pack 1, que incluye muchas funciones nuevas e interesantes.
Esta descarga, que estará disponible en go.microsoft.com/fwlink/?LinkId=91472, se puede usar para realizar una instalación completa de Exchange Server 2007 (con todas las actualizaciones del SP1) y para actualizar las instalaciones existentes de Exchange Server 2007. Aunque puede instalarse en Windows Server® 2003 SP1, SP2 y R2, Exchange Server 2007 SP1 es compatible con la futura versión de Windows Server 2008.
Service Pack 1 introduce más funciones nuevas y mejoras de las que puedo tratar en esta breve introducción. Así que lo que he hecho es compilar una lista descriptiva de algunos de los cambios más destacables que puede aprovechar para mejorar su entorno de Exchange. Para ver con detalle todos los cambios, consulte "Novedades de Exchange Server 2007 SP1" en technet.microsoft.com/bb676323.aspx.

Cambios en la consola de administración de Exchange
Service Pack 1 aporta a la consola de administración de Exchange, mostrada en la figura 1, algunas funciones nuevas y prácticas. Para empezar, el cuadro de herramientas, que ofrece una colección de herramientas de diagnóstico, solución de problemas y recuperación que se instalan de forma predeterminada con Exchange Server 2007, ahora incluye la consola de administración de carpetas públicas, un editor de plantillas de detalles y el visor del registro de enrutamiento.
Figura 1 Consola de administración de Exchange con Service Pack 1
Figura 1 Consola de administración de Exchange con Service Pack 1
Puede usar la consola de administración de Exchange, la consola de administración de carpetas públicas, el editor de plantillas de detalles y el visor de cola para exportar listas del panel de resultados y el panel de trabajo. Las listas pueden exportarse como texto (delimitado por tabulaciones), texto (delimitado por comas), texto Unicode (delimitado por tabulaciones) y texto Unicode (delimitado por comas). Además de poder filtrar el panel de resultados en la consola de administración de Exchange, ahora puede filtrar los paneles de resultados en la consola de administración de carpetas públicas, el editor de plantillas de detalles y el visor de cola.
Lo más destacable, sin embargo, es que la consola de administración de Exchange incluye varias interfaces de administración nuevas (como la consola de administración de carpetas públicas mencionada). Las analizaré por separado a lo largo de este artículo.

Compatibilidad con IPv6
Junto con la compatibilidad con Windows Server 2008 se incluye la compatibilidad con el protocolo de Internet, versión 6 (IPv6). Por supuesto, ello depende de que Exchange Server 2007 se instale realmente en Windows Server 2008 con las pilas de los protocolos IPv4 e IPv6 habilitadas. Si deshabilita IPv4 antes de la instalación, Exchange no será compatible con IPv6.
Puede escribir intervalos y direcciones IP en formato IPv4 o IPv6. Todas las funciones de servidor excepto una pueden enviar datos a dispositivos, servidores y clientes que usen direcciones IPv6, así como recibir datos de éstos. La excepción es la función de servidor Mensajería unificada. El motivo es que la función de mensajería unificada requiere IPv4 debido a limitaciones con algunos componentes necesarios de telefonía y voz.

IU de administración de POP3 e IMAP4
La consola de administración de Exchange incluye una nueva IU de administración para administrar POP3 e IMAP4. En ella se pueden configurar todos los parámetros de POP3 e IMAP4 para el servidor de acceso de clientes, incluidas la configuración de puertos, configuración de autenticación y configuración de conexión. La figura 2 muestra el cuadro de diálogo de configuración de las propiedades de IMAP4; dispone de las mismas opciones para POP3.
Figura 2 Consola de administración de Exchange para POP3/IMAP4
Figura 2 Consola de administración de Exchange para POP3/IMAP4

Administración de buzones más estable
Las funciones de administración de buzones de la consola de administración de Exchange admiten ahora la creación de buzones de forma masiva para cuentas de usuario existentes. Al mismo tiempo, los nuevos asistentes permiten a los administradores conceder o quitar derechos de acceso completos y configurar permisos de envío para un buzón.

Nuevas funciones para administrar datos de buzón
Ahora, los administradores pueden importar y exportar archivos .pst para administrar datos de buzón. También puede hacerse en el shell de administración de Exchange mediante los cmdlets Import-Mailbox y Export-Mailbox respectivamente.
Es posible aplicar la administración de registros de mensaje (MRM) a las carpetas administradas predeterminadas que se encuentran en un servidor de Exchange con una licencia de acceso de cliente estándar de Exchange. (Tenga en cuenta que MRM para carpetas administradas personalizadas continúa requiriendo una licencia de acceso de cliente para empresas de Exchange.) El nuevo parámetro RemoveManagedFolderAndPolicy, que es para el cmdlet Set-Mailbox, elimina cualquier directiva MRM de un buzón, elimina las propiedades MRM de cualquier carpeta administrada creada como parte de la directiva MRM que se aplicó al buzón y convierte cualquier carpeta administrada en carpeta estándar.
Los nuevos contadores del monitor de rendimiento permiten supervisar diversa información de desfragmentación en línea, en concreto: cuándo se ejecutó por última vez la desfragmentación en línea, lo que tardó en completarse y lo que hizo. Esta información es útil para optimizar el intervalo de desfragmentación en línea.

Confirmación de limpiezas remotas
Exchange Server 2007 ya permite que un administrador o usuario de cuenta realicen una limpieza remota para borrar todos los datos de usuario de un dispositivo móvil, una función de seguridad práctica para cuando un dispositivo se ha perdido o ha sido robado. Con Service Pack 1, se envía un mensaje de confirmación cuando el dispositivo reconoce la solicitud de limpieza remota. Si es el usuario quien origina la solicitud (por medio de Outlook® Web Access u OWA), recibirá un correo electrónico de confirmación. Si es el administrador quien emite la solicitud (por medio de la consola de administración de Exchange), el administrador y el usuario recibirán un correo electrónico de confirmación.

Un cliente de OWA más robusto
El cliente de correo electrónico basado en Web ofrece muchas mejoras que aportan una mensajería mejor para trabajadores móviles. Con SP1, los usuarios de OWA pueden crear y editar listas de distribución personales, así como reglas de servidor. Asimismo, los usuarios pueden usar las funciones Contenedor y Recuperar elementos eliminados.
Los comandos Mover y Copiar se han agregado a la IU, lo que permite a los usuarios mover y copiar carpetas vía el menú contextual de la lista de carpetas. Cada uno de los artículos de las carpetas de mensajes y carpetas públicas se puede mover y copiar haciendo clic con el botón secundario en la lista de elementos o haciendo clic en un icono de la barra de herramientas.
Los usuarios de OWA también tienen acceso completo a las carpetas públicas sin usar el directorio virtual /public (y no es necesario mantener un servidor back-end Exchange 2003 para que sea compatible). Y las capacidades de búsqueda de la carpeta pública son compatibles en OWA.
Ahora, las capacidades S/MIME permiten a los usuarios leer y redactar mensajes de correo electrónico firmados y cifrados (consulte la figura 3). Incluso hay compatibilidad CNG (API de criptografía: próxima generación) y conformidad con Suite-B. Al mismo tiempo, la IU de OWA se puede personalizar para integrar perfectamente aplicaciones personalizadas.
Figura 3 Configuración de mensajes S/MIME
Figura 3 Configuración de mensajes S/MIME

Supervisión de redacción en OWA Light
Outlook Web Access Light, una versión menos compleja de OWA diseñada para funcionar con casi cualquier explorador web, ahora supervisa la actividad mientras el usuario redacta una entrada larga de cualquier tipo (como un mensaje o una entrada de calendario) para garantizar que la sesión no agote el tiempo de espera (causando pérdida de datos) mientras el usuario todavía está escribiendo. Además, los mensajes se guardan automáticamente en la carpeta Borradores si la sesión agota el tiempo de espera debido a inactividad mientras está abierto el formulario de redacción de mensajes.

Rendimiento de Direct Push mejorado
Direct Push funciona estableciendo una conexión HTTPS entre un dispositivo móvil y el servidor Exchange 2007. En Exchange 2007 SP1, se ha reducido el tamaño de la solicitud y los encabezados de respuesta HTTPS, lo que reduce la cantidad de datos que se envían a un dispositivo móvil y que se reciben de él.

Administración de carpetas públicas
La nueva consola de administración de carpetas públicas, que se muestra en la figura 4, permite a los administradores crear, configurar y mantener carpetas públicas desde la consola de administración de Exchange. Las listas de direcciones, las directivas de dirección de correo electrónico, los grupos de distribución dinámica y las listas de distribución son compatibles con carpetas públicas. Al realizar vistas previas de listas de direcciones, directivas de dirección de correo electrónico, grupos de distribución dinámica y destinatarios de grupos de distribución, puede ver las carpetas públicas habilitadas para correo incluidas en los criterios de pertenencia a grupos.
Figura 4 Consola de administración de carpetas públicas
Figura 4 Consola de administración de carpetas públicas
La consola de administración de carpetas públicas en Exchange 2007 SP1 permite configurar derechos administrativos de carpeta pública. Puede hacerlo mediante el cmdlet Add-ExchangeAdministrator o con el asistente para agregar administradores de Exchange para agregar un usuario a la función de administrador de carpetas públicas o bien mediante el cmdlet Add-PublicFolderAdministratorPermission para conceder o denegar derechos específicos a las carpetas públicas.

Procesamiento y enrutamiento de mensajes mejorados
Los servidores de transporte de concentradores están implementados en el interior del bosque de Active Directory® y controlan todo el flujo de mensajes en la organización, aplican reglas de transporte y reglas de diario, y entregan mensajes en los buzones de correo de los destinatarios. El servidor de transporte de concentradores transmite los mensajes que se envían a Internet al servidor de transporte perimetral en el perímetro de la red. SP1 incluye mejoras para estas funciones de servidor.
Exchange Server 2007 incluye una función de supervisión de los recursos del sistema denominada Contrapresión que permite a los servidores de transporte de concentradores y transporte perimetral responder al uso intensivo de los recursos. Con SP1, el requisito de espacio libre en disco se ha reducido considerablemente, de 4 GB a 500 MB.
La consola de administración de Exchange en SP1 ofrece más parámetros de configuración de transporte. Y ahora tiene la posibilidad de configurar un espacio de direcciones X.400 como dominio autorizado (también se admiten direcciones largas de X.400).
El servidor del transporte de concentradores es compatible con la puesta en cola con prioridades. El categorizador tiene en cuenta la prioridad de mensaje que asigna el usuario de Outlook a los mensajes, lo que ayuda a garantizar que los mensajes enviados con importancia alta reciban realmente un trato prioritario y se entreguen más rápidamente que los mensajes designados con importancia baja.
En Exchange 2007 SP1, el ámbito de un conector de envío para un solo sitio de Active Directory se simplifica agregando el parámetro IsScopedConnector en los cmdlets del shell de administración de Exchange y activando la casilla de verificación de conector de envío con ámbito en la consola de administración de Exchange. Cuando se limita el ámbito de un conector de envío, sólo los servidores de transporte de concentradores del mismo sitio de Active Directory que los servidores de origen del conector de envío tienen en cuenta ese conector al decidir el enrutamiento.

Mejoras de sincronización del servidor de transporte perimetral
En Exchange Server 2007 SP1, puede usar el cmdlet Start-EdgeSynchronization para empezar inmediatamente la sincronización de datos de Active Directory con el servicio de directorio de Active Directory Application Mode (ADAM). En Exchange 2007 SP1, este cmdlet admite el parámetro Server, que ofrece la posibilidad de ejecutar el cmdlet desde un equipo remoto.
El cmdlet Test-EdgeSynchronization, un cmdlet de diagnóstico que notifica el estado de sincronización de los servidores de transporte perimetrales, se ha ampliado con un nuevo conjunto de parámetros que permiten comprobar los resultados de sincronización para usuarios individuales.

Clonación del objeto TransportConfig
Los scripts de configuración clonados facilitan a los administradores la aplicación de una configuración coherente cuando se implementa más de un servidor de transporte perimetral en su entorno. En SP1, el objeto TransportConfig, que controla la configuración en todo el servidor para la función de servidor de transporte perimetral, está ahora incluido en la información de configuración clonada. La inclusión de este objeto agiliza considerablemente los procedimientos de implementación, copia de seguridad y restauración del servidor.

Mejoras en la mensajería unificada
La mensajería unificada fue una parte interesante de la versión inicial de Exchange Server 2007. Service Pack 1 parte de esta funcionalidad e introduce muchas funciones nuevas y mejoras. Algunas de las funciones requieren que se implemente Office Communications Server 2007 en el mismo bosque de Active Directory, pero hay muchas funciones que no requieren Office Communications Server. No puedo tratar aquí todos los cambios en la mensajería unificada, pero me detendré en algunas de las novedades más importantes. Si desea leer más acerca de la mensajería unificada, consulte "Implementación de mensajería unificada con Exchange Server 2007" en este número de TechNet Magazine para obtener más información.
Primero mencionaré algunas de las funciones nuevas que requieren Office Communications Server 2007. Ahora hay compatibilidad para que las secuencias multimedia atraviesen los firewalls y para mensajes de voz de alta fidelidad. Si el destino usa la transferencia de llamadas, hay notificación de la transferencia al dejar mensajes de voz. Los usuarios pueden tener acceso a Outlook Voice Access Communicator desde Office Communicator 2007 sin especificar ningún PIN. Hay integración de mensajes de correo electrónico de notificación de llamadas perdidas y notificación de correo de voz con Office Communicator 2007 (consulte la figura 5). Y mucho más.
Figura 5 Notificación de correo de voz en Office Communicator
Figura 5 Notificación de correo de voz en Office Communicator
Una de las mejoras de la mensajería unificada que no requiere Office Communications Server es la compatibilidad con el protocolo de transporte en tiempo real (SRTP). El lanzamiento inicial de Exchange Server 2007 ofrece dos modos de seguridad: el no seguro y el seguro. El modo seguro sólo cifra el tráfico del protocolo de inicio de sesión (SIP) y el tráfico de RTP no está cifrado. En SP1, hay tres modos: el no seguro, el seguro con SIP y el seguro. En el modo seguro con SIP, sólo el tráfico de SIP se cifra, no el tráfico de RTP. En el modo seguro, tanto el tráfico de SIP como el de RTP están cifrados. También puede configurar la seguridad del nivel de transporte mutuo (MTLS) para los planes de acceso telefónico que usan la consola de administración de Exchange.
Otros cambios son el nuevo asistente para habilitar mensajería unificada, que se puede usar para agregar una dirección SIP o E.164 para un usuario; la configuración del tipo de URI para un plan de acceso telefónico mediante la consola de administración de Exchange; y se ha agregado a SP1 la compatibilidad con Calidad de servicio (QoS) mediante DiffServ para etiquetar el tráfico de medios.

Alta disponibilidad mejorada
Service Pack 1 presenta varias funciones nuevas que mejorarán la alta disponibilidad, así como mejoras de las funciones de alta disponibilidad existentes. Las funciones nuevas y mejoradas amplían los escenarios en los que puede lograr disponibilidad de datos y servicios para las funciones de servidor de Exchange 2007. Los nuevos escenarios permiten que las organizaciones separen los escenarios de alta disponibilidad de los escenarios de recuperación del sitio e implementen configuraciones hechas a medida de las necesidades específicas de la organización en cada área por separado.
Para empezar, la compatibilidad agregada para Windows Server 2008 permite clústeres de conmutación por error para varias subredes, así como compatibilidad con nuevos modelos de quórum (testigo de disco y recurso compartido). También hay mejoras muy útiles de las capacidades de informes de clúster y de supervisión, incluida la funcionalidad adicional diseñada para la supervisión proactiva de entornos de réplica continua. Al mismo tiempo, las mejoras en relación con el rendimiento incluyen una reducción de E/S en los discos que contienen copias pasivas de grupos de almacenamiento, copias más rápidas de archivos de registro y traslados más rápidos entre nodos de los servidores de buzones en clústeres.
Por último, se han agregado nuevos asistentes para mejorar la administración y configuración (consulte la figura 6) y nuevos controles de IU para administrar servidores de buzón agrupados, incluidas la nueva ficha Servidor de buzones en clústeres y una página de configuración Replicación continua en clúster (CCR).
Figura 6 Asistente para administrar servidores de buzones en clústeres
Figura 6 Asistente para administrar servidores de buzones en clústeres

Réplica continua en espera
La réplica continua en espera (SCR) usa la misma tecnología de trasvase y repetición de registros que usa la réplica continua local (LCR) y CCR para ofrecer más opciones de implementación y configuraciones. SCR es parecida a LCR y CCR, pero tiene características propias únicas. Para ver un análisis exhaustivo de SCR, consulte el artículo "Replicación continua en espera en Exchange Server 2007" por Scott Schnoll en este número de TechNet Magazine.

Conclusión
Exchange Server 2007 Service Pack 1 va claramente más allá de las meras revisiones y actualizaciones de seguridad. Ofrece muchas funciones nuevas y mejoras en las que pronto confiará. No tengo espacio para analizar todas las funciones y mejoras nuevas, pero espero que este artículo le haya servido de información general de lo que obtendrá. Para obtener información completa acerca de todos los cambios del Service Pack 1 más las descargas, las webcasts y los foros de discusión, visite el TechCenter de Exchange Server en technet.microsoft.com/exchange.

Tony Smith es un escritor técnico principal del equipo de educación del usuario de Exchange, especializado en mensajería unificada. Antes de trabajar para Microsoft, Tony trabajó como ingeniero de redes, para un proveedor de Microsoft y para un Microsoft Certified Trainer. También ha realizado varios proyectos de escritura para Microsoft Learning, incluidos libros y manuales de laboratorio.
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 Comunicaciones: Replicaci&#243;n continua en espera en Exchange Server 2007 Service Pack 1
Comunicaciones Scott Schnoll

Replicación continua en espera en Exchange Server 2007 Service Pack 1
Resumen:
  • Configuración de la replicación continua en espera
  • La importancia de la redundancia
  • Cómo reduce SCR el tiempo de inactividad

Service Pack 1 ofrece varias características y mejoras nuevas para Exchange 2007. Una de ellas, la replicación continua en espera (SCR), está diseñada para ofrecer a las organizaciones redundancia en centros de datos y elasticidad de sitio. Como implica su nombre, la SCR está diseñada
para escenarios que usan o permiten el uso de servidores de recuperación en espera.
Si está familiarizado con la versión para fabricación (RTM) de Exchange 2007, sabrá que también ofrece redundancia en centros de datos y elasticidad de sitio mediante sus características de trasvase de registros y soporte técnico para clúster de conmutación por error de Windows®. En la versión RTM, el trasvase de registros (conocido oficialmente como replicación continua) está disponible de dos formas: replicación continua local (LCR), como se muestra en la figura 1 y replicación continua en clúster (CCR), como se muestra en la figura 2.
Figura 1 Replicación continua local
Figura 1 Replicación continua local
Figura 2 CCR trasvasa registros a un segundo servidor en un clúster de conmutación por error de Windows
Figura 2 CCR trasvasa registros a un segundo servidor en un clúster de conmutación por error de Windows
La replicación continua ofrece disponibilidad y redundancia de datos permitiendo que los administradores habiliten y mantengan en línea una segunda copia de todas las bases de datos de buzones. Esta copia de la base de datos representa una primera línea de defensa frente a errores, pérdidas o daños a una base de datos de producción. En vez de perder el tiempo localizando una cinta de copia de seguridad para restaurar datos, puede activarse una copia de la base de datos y convertirse en base de datos de producción en cuestión de minutos.
SCR amplía los escenarios en los que puede lograr la disponibilidad de datos y servicios para su organización. Los nuevos escenarios le permiten separar las topologías de disponibilidad elevada de las topologías de elasticidad de sitio, y también le permiten implementar configuraciones personalizadas para necesidades específicas de su organización en cada área.
La versión RTM de Exchange 2007 ofrece redundancia en centros de datos y elasticidad de sitio, pero, puesto que la LCR y la CCR ofrecen sólo un copia adicional de cada base de datos, debe elegir entre la elasticidad y la redundancia. Por ejemplo, piense en las características de disponibilidad de datos y servicios que ofrece la CCR. La implementación de los nodos activos y pasivos en un solo centro de datos ofrece disponibilidad de datos y servicios en centros de datos pero no ofrece elasticidad de sitio (porque ambos nodos están en el mismo sitio físico). La implementación del nodo activo en un centro de datos y el nodo pasivo en un segundo centro de datos proporciona elasticidad de sitio pero no disponibilidad en centro de datos (porque el nodo pasivo, que ofrece estas características, se encuentra en un segundo centro de datos).
La SCR que ofrece el Service Pack 1 ofrece la capacidad de crear copias adicionales de cada base de datos, y significa que esa elevada disponibilidad y la elasticidad de sitio no se excluyen mutuamente; se pueden conseguir ambas. Por ejemplo, como se muestra en la figura 3, puede combinar SCR con CCR para replicar grupos de almacenamiento de forma local en un centro de datos principal (con CCR para la disponibilidad elevada) y de forma remota en un segundo centro de datos o un centro de datos de copia de seguridad (con SCR para la elasticidad de sitio). El segundo centro de datos contiene un clúster en espera que se puede activar y aprovisionar rápidamente con un servidor de buzones en clústeres de sustitución en un escenario de recuperación de sitios.
Figura 3 CCR implementada en el centro de datos Redmond y SCR implementada en el centro de datos Quincy
Figura 3 CCR implementada en el centro de datos Redmond y SCR implementada en el centro de datos Quincy
La figura 3 representa una implementación empresarial con dos centros de datos, cada uno con su propio sitio de Active Directory®: Redmond y Quincy. El sitio Redmond se encuentra en el centro de datos (producción) principal y el sitio Quincy se encuentra en un segundo centro de datos (copia de seguridad). CCR se implementa en Redmond para lograr la redundancia de centros de datos. Junto con los elementos de la infraestructura requeridos para Exchange 2007, los destinos de SCR están configurados en un clúster en espera ubicado en Quincy para lograr la elasticidad del sitio. Estos elementos adicionales de la infraestructura, que incluyen acceso de cliente y servidores de transporte de concentradores, servidores Active Directory y DNS, y acceso a Internet, pueden ser recursos dedicados o no dedicados. Los recursos dedicados son aquellos que se designan para admitir únicamente usuarios del centro de datos en el que residen. Los recursos no dedicados son aquellos que admiten usuarios del centro de datos local y usuarios de otras ubicaciones. Debe decidir si los recursos serán dedicados o no dedicados, en función de lo que resulte mejor para su organización. Para obtener más información acerca de los recursos dedicados y no dedicados, consulte el tema del archivo de ayuda de Exchange Server 2007 "Configuraciones de elasticidad de sitio" en technet.microsoft.com/bb201662.asp. Tenga en cuenta también el uso de un nuevo tipo de quórum de conjuntos de nodos mayoritario (MNS). En Exchange Server 2007, CCR usa el quórum de MNS con testigo del recurso compartido de archivos (FSW) en lugar del nodo tradicional de votantes, como puede observar en la figura 3.
En la figura 4, un entorno de CCR más SCR que está diseñado teniendo en cuenta la elasticidad ofrece varios niveles de redundancia para los buzones y servicios hospedados en el servidor EXCLUS1, con lo que se protege estos buzones de errores catastróficos de pequeña a gran escala.
Figura 4 Servidores de buzones independientes que usan SCR para replicar grupos de almacenamiento entre ellos
Figura 4 Servidores de buzones independientes que usan SCR para replicar grupos de almacenamiento entre ellos
Las pequeñas y medianas organizaciones también pueden beneficiarse de SCR. Por ejemplo, como se muestra en la figura 4, una organización puede implementar dos servidores de buzones independientes (EXMBX1 Y EXMBX2) y usar SCR para replicar algunos o todos los grupos de almacenamiento de un servidor de buzones al otro.
En este ejemplo, tanto EXMBX1 como EXMBX2 son servidores de producción con cinco grupos de almacenamiento activos. Cada grupo de almacenamiento es un origen de SCR para un destino de SCR correspondiente en el otro servidor. En caso de que se produzca un error de almacenamiento o algún otro evento en el que un grupo de almacenamiento activo configurado como origen de SCR no esté disponible, la copia del destino de SCR puede activarse rápidamente usando unas cuantas tareas administrativas en el Shell de administración de Exchange. Con Microsoft® Office Outlook® 2007 y las características de portabilidad de bases de datos y detección automática de Exchange 2007, el tiempo de inactividad en caso de que se produzca una pérdida de grupo de almacenamiento activo (o, en su caso, una pérdida de varios grupos de almacenamiento activos) podría suponer unos pocos minutos.

Orígenes y destinos de SCR
Al igual que con LCR y CCR, SCR también usa el concepto de copias activas y pasivas de un grupo de almacenamiento, pero se refiere a ellos como orígenes y destinos de SCR, respectivamente. No obstante, los orígenes y destinos de SCR son copias de grupos de almacenamiento. (Los grupos de almacenamiento de recuperación no pueden habilitarse para SCR.)
El punto de partida para SCR (el origen de SCR) es cualquier grupo de almacenamiento de un servidor de buzones independiente o de un servidor de buzones de correo en clúster situado en un solo clúster de copia o entorno de CCR. Es importante tener en cuenta que, aunque el origen de SCR puede ser un servidor de buzones de correo en clúster, la propia SCR es una solución en clúster y no requiere el servicio de clúster de Windows. El extremo de SCR (el destino de SCR) puede ser o bien un servidor de buzones independiente o bien un nodo en un clúster de conmutación por error, donde la función del buzón está instalada pero no se ha configurado en el clúster ningún servidor de buzones de correo en clúster.

Relaciones de origen y de destino
Cada grupo de almacenamiento de origen de SCR puede tener un número ilimitado de destinos de SCR. Por ejemplo, un origen podría tener un destino que resida en el mismo centro de datos como origen y un segundo destino en un centro de datos diferente. Sin embargo, Microsoft recomienda no usar más de cuatro destinos por origen. Si decide usar más de cuatro destinos, debe valorar la posible repercusión sobre el servidor del origen de SCR en términos de memoria, CPU y recursos de disco, y hacer planes según corresponda. Todos los equipos del destino de SCR pueden tener varios servidores de origen. Service Pack 1 para Exchange 2007 debe estar ejecutándose en los equipos de origen y de destino. El sistema operativo debe ser compatible con Service Pack 1 para Exchange 2007 (por ejemplo, Windows Server® 2008 o Windows Server 2003 SP2). Sin embargo, independientemente del sistema operativo que use, SCR no dispone de compatibilidad entre sistemas operativos y requiere que el sistema operativo en el origen de SCR coincida con el sistema operativo de todos los destinos de SCR para ese origen. Así pues, si el origen de SCR ejecuta Windows Server 2003, todos los destinos de SCR para ese origen también deben ejecutar Windows Server 2003.
SCR está disponible en Exchange 2007 Standard Edition. Si se usa un servidor de buzones de correo en clúster situado en un entorno de SCC o de CCR como origen de SCR, será necesario Exchange 2007 Enterprise Edition. Cada destino de SCR admite un máximo de 50 instancias (50 grupos de almacenamiento replicados) al usar la Enterprise Edition y un máximo de 5 instancias al usar la Standard Edition.
Los destinos de SCR también tienen requisitos que deben cumplirse. En primer lugar, los equipos del origen y destino deben estar en el mismo dominio de Active Directory, aunque no hace falta que estén en el mismo sitio de Active Directory. Además, las rutas del archivo de registro y de la base de datos situados en el origen y todos sus destinos deben coincidir para cada grupo de almacenamiento que se replica con SCR. Por último, cuando un nodo o un servidor están configurados como destino de SCR, no se puede habilitar LCR para ningún grupo de almacenamiento en el equipo del destino de SCR ni se pueden agregar servidores de buzones de correo en clúster al clúster de conmutación por error en espera.

Comparación de SCR con CCR y LCR
SCR (como se muestra en la figura 5) usa el mismo trasvase de registros y la misma tecnología de relectura que LCR y CCR para ofrecer nuevas configuraciones y opciones de implementación. Al igual que con LCR y CCR, los grupos de almacenamiento habilitados para SCR no pueden contener más de una base de datos. Además, SCR no se puede usar para una base de datos de carpetas públicas si existe más de una base de datos de carpetas públicas en la organización de Exchange.
Figura 5 SCR está trasvasando registros a otro servidor o a un nodo pasivo en un clúster de conmutación por error
Figura 5 SCR está trasvasando registros a otro servidor o a un nodo pasivo en un clúster de conmutación por error
Una diferencia clave con SCR es que admite varios destinos por grupo de almacenamiento, mientras que tanto LCR como CCR sólo admiten un único destino (la copia pasiva). Otra diferencia clave es que, a diferencia de CCR y LCR, no se pueden realizar copias de seguridad de una copia de SCR. Al usar la SCR, se actualizan los encabezados de la base de datos para destinos de SCR y los archivos de registro se truncan cuando las copias de seguridad admitidas se llevan a cabo en el grupo de almacenamiento del origen de SCR (o, en el caso de CCR y LCR, cuando las copias de seguridad se llevan a cabo en las copias activas o pasivas del grupo de almacenamiento del origen de SCR).
Al igual que con LCR y CCR, el trasvase de registros con SCR es continuo y usa un modelo de extracción. Tan pronto como un archivo de registro nuevo se haya cerrado y nombrado con el número de archivo de registro de secuencia de nueva generación, el servicio de replicación de Microsoft Exchange que se ejecuta en el equipo del destino de SCR extrae los archivos de registro de transacciones cerradas del equipo del origen de SCR, los inspecciona y los valida y, a continuación, los desplaza a su carpeta del archivo de registro del grupo de almacenamiento de contrapunto en el equipo del destino de SCR.

Tiempo de posposición de relectura
Después de que los archivos de registro se copien al equipo del destino de SCR, SCR hace algo distinto de LCR y CCR. En lugar de releer inmediatamente los archivos de registro en la copia de la base de datos, SCR aplica un retraso integrado de relectura de 50 archivos de registro y 24 horas. SCR también le permite especificar un retraso más allá de estos retrasos integrados. El retraso de la actividad de relectura es útil en muy diversos escenarios. Por ejemplo, en caso de daño lógico de una base de datos activa, un retraso podría evitar el daño lógico de la base de datos del objetivo de SCR.
El retraso de relectura controlado por el administrador se establece mediante un parámetro denominado ReplayLagTime, que dicta la cantidad de tiempo que debe esperar el servicio de replicación de Exchange antes de releer archivos de registro que ya se han copiado al equipo del destino de SCR. El formato es Días.Horas:Minutos:Segundos, y el valor predeterminado son 24 horas. La configuración máxima permitida para este valor es de siete días. La configuración mínima permitida es de cero segundos, y si se establece este valor en cero segundos, se elimina de forma eficaz cualquier retraso en la actividad de relectura del registro por encima del retraso predeterminado de 50 archivos de registro.
Además de ReplayLagTime, Exchange dispone de un retraso integrado codificado de 50 archivos de registro, independientemente del valor de ReplayLagTime. Para determinar cuándo debe releerse un archivo de registro, Exchange usa el valor más grande de los ReplayLagTime o x archivos de registro, donde x = 50. Esto supone una medida de seguridad adicional contra la necesidad de repropagar un grupo de almacenamiento en situaciones en que un origen de SCR que usa la replicación continua (por ejemplo, un servidor de buzones de correo en clúster en un entorno de CCR) experimente una conmutación por error y uno o más grupos de almacenamiento deban ponerse en línea mediante el cmdlet Restore-StorageGroupCopy. (Propagación es el proceso de usar las API de copia de seguridad de transmisión ESE (motor de almacenamiento extensible) para hacer una copia en línea de la base de datos origen de SCR en el equipo del destino de SCR.) Al retrasar la actividad de relectura en los destinos de SCR, cuando se produce una conmutación por error con pérdida de información, se reducirán las probabilidades de tener que repropagar las copias de SCR porque la naturaleza de la pérdida de datos en el origen de SCR sitúa las dos copias más cerca en el tiempo.

Tiempo de retraso de truncamiento
En la versión RTM de Exchange 2007, se aplican reglas en un entorno de replicación continua para que no se elimine un archivo de registro a menos que se haya realizado una copia de seguridad del mismo y se haya releído en la copia de la base de datos. Al usar la SCR, esta regla se modifica. SCR (que introduce el concepto de varias copias de la base de datos) permite que los archivos de registro se trunquen en el equipo del origen de SCR tan pronto como los inspeccionen todos los equipos del destino de SCR. El truncamiento de registros en el servidor del origen de SCR no espera hasta que se hayan releído todos los registros en todos los destinos de SCR porque las copias de los destinos de SCR se pueden configurar con grandes tiempos de posposición de relectura de registros.
También puede agregar un retraso adicional al truncamiento de registros con un parámetro nuevo llamado TruncationLagTime, que especifica el intervalo de tiempo que debe esperar el servicio de replicación de Exchange (con el formato Días.Horas:Minutos:Segundos) antes de truncar archivos de registro que se han copiado al equipo del destino de SCR y se han releído en la copia de la base de datos. El período de tiempo empieza en el momento en que se hayan releído correctamente los archivos de registro en la copia de la base de datos. La configuración máxima permitida para este valor es de siete días, mientras que el mínimo es de cero segundos, aunque cero segundos elimina de forma eficaz cualquier retraso en la actividad del truncamiento de registros.
En un entorno de SCR, se ejecuta cada tres minutos un subproceso en segundo plano para determinar si debe truncarse algún archivo de registro. Si la secuencia de la generación de archivos de registro está por debajo del punto de control de archivos de registro para el grupo de almacenamiento, y el archivo de registro es anterior a ReplayLagTime + TruncationLagTime, se truncará un archivo de registro en el destino de SCR.
En un entorno de LCR o de CCR ampliado con SCR, se truncará un archivo de registro en el destino SCR si se cumplen los siguientes cuatro criterios: se ha realizado copia de seguridad del archivo de registro, la secuencia de la generación de archivo de registro está por debajo del punto de control de archivos de registro para el grupo de almacenamiento, la copia pasiva del grupo de almacenamiento está en un estado que permite que se trunque el archivo de registro y todos los destinos de SCR han inspeccionado el archivo de registro.

Habilitación y administración de SCR
SCR se habilita mediante el cmdlet Enable-StorageGroupCopy en el Shell de administración de Exchange, que se ha actualizado en SP1 con algunos parámetros nuevos. Como se describe más arriba, ReplayLagTime y TruncationLagTime pueden proporcionarle el control de parte del comportamiento de los destinos de SCR. SeedingPostponed es otro parámetro que se puede usar para omitir la propagación inicial del destino de SCR. El aplazamiento de la propagación es útil en varias situaciones. Por ejemplo, digamos que la base de datos del grupo de almacenamiento que se está habilitando para SCR es de 100 GB. Quizás no le interese que atraviesen la red 100 GB de datos durante tiempos de producción máxima. El parámetro SeedingPostponed le ofrece la opción de habilitar la SCR inmediatamente y realizar una tarea de propagación más tarde. Cuando esté listo, puede propagar manualmente el destino de SCR que usa el cmdlet Update-StorageGroupCopy.
Pese a que los parámetros mencionados son opcionales, existe un parámetro de Enable-StorageGroupCopy que es obligatorio para SCR: StandbyMachine. Éste especifica el nombre del equipo que contendrá el destino de SCR. El valor de este parámetro se establece como parte del valor para el atributo msExchStandbyCopyMachines del grupo de almacenamiento que se habilita para SCR. El atributo msExchStandbyCopyMachines es una cadena Unicode multivalor que se agrega al esquema de Active Directory cuando Exchange 2007 SP1 se introduce en la organización de Exchange, que es uno de los motivos por los que SP1 requiere una actualización de esquema para Active Directory.
El parámetro StandbyMachine es básico para SCR, y se han actualizado varios cmdlets en SP1 de modo que usen este parámetro para habilitar y administrar destinos de SCR. Los cmdlets actualizados se describen en la figura 6.
Figure 6 Cmdlets que usan el parámetro StandbyMachine (Close Figure 6)

Cmdlet | Descripción
Disable-StorageGroupCopy | Deshabilita un destino de SCR para un grupo de almacenamiento.
Get-StorageGroupCopyStatus | Determina el estado actual del destino de SCR.
New-StorageGroup | Crea un nuevo grupo de almacenamiento habilitado para SCR sin tener que habilitar SCR por separado mediante el cmdlet Enable-StorageGroupCopy.
Restore-StorageGroupCopy | Deshabilita SCR y hace que la base de datos del destino de SCR sea viable para el montaje con una operación Mount-Database como parte de un procedimiento de recuperación.
Resume-StorageGroupCopy | Sirve para reanudar la replicación continua para un grupo de almacenamiento que tiene la SCR suspendida.
Suspend-StorageGroupCopy | Suspende la actividad de replicación continua para un grupo de almacenamiento que está habilitado para SCR.
Update-StorageGroupCopy | Sirve para propagar o repropagar un grupo de almacenamiento de destino de SCR.

Activación de destinos de SCR
SCR ofrece una o más copias recientes de los datos, que pueden usarse en caso de que los datos originales se pierdan o pasen a ser inutilizables. El proceso de realizar una copia del destino de SCR y restablecerlo como base de datos de producción se conoce como activación. La activación se produce como parte del proceso de recuperación, que tomará la forma de portabilidad de bases de datos o una de las dos opciones de recuperación de la instalación (/m:RecoverServer para recuperar un servidor independiente o bien /RecoverCMS para recuperar un servidor de buzones de correo en clúster).

Cómo se puede usar la SCR
Veamos cómo una compañía ficticia podría usar SCR y la portabilidad de bases de datos para recuperarse de un error de base de datos de buzones de correo. Tras detectar que la base de datos de producción está dañada, el administrador activa la base de datos de destino de SCR mediante la portabilidad de bases de datos.
La organización ha implementado Exchange 2007 con SP1 y ha decidido aprovechar SCR para ofrecer una copia de un grupo de almacenamiento de un servidor remoto de buzones de correo. Los servidores de buzones de origen y destino están en el mismo sitio de Active Directory y están configurados para usar servidores DNS integrados en Active Directory. El intervalo de replicación de Active Directory está configurado en 15 minutos.

Habilitación de SCR y recuperación de contenido almacenado
SCR está configurada para que los archivos de registro de transacciones se repliquen para un solo grupo de almacenamiento, SG1, que contiene una sola base de datos, MBX1. Las rutas de acceso para los archivos de grupo de almacenamiento y archivo de base de datos son C:\SG1 y C:\SG1\MBX1.EDB. En este caso, EXMBX1 es el origen de SCR y EXMBX2 es el destino de SCR. Se configuró como se observa aquí:
Enable-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
Después de habilitar SCR, se comprobó el mantenimiento y el estado de SCR para SG1 con el cmdlet Get-StorageGroupCopyStatus:
Get-StorageGroupCopyStatus EXMBX1\SG1
-StandbyMachine EXMBX2
Para ahorrar tiempo durante el proceso de activación del destino de SCR, se preconfigura EXMBX2 con un grupo de almacenamiento, SG1PORT, y la base de datos, MBX1PORT, que se usará como parte de las operaciones de portabilidad de bases de datos. SG1PORT y MBX1PORT están separados del grupo de almacenamiento del destino de SCR y de los archivos de base de datos. Por lo tanto, las rutas de acceso de SG1PORT y MBX1PORT están configuradas con una ruta de acceso temporal que no entra en conflicto con las rutas de acceso del destino de SCR. SG1PORT y MBX1PORT sólo se usarán como objetos de portabilidad de bases de datos; el grupo de almacenamiento y los archivos de base de datos para SG1PORT no son necesarios. Debido a esto, el administrador desmonta MBX1PORT y elimina todos los archivos del grupo de almacenamiento. El grupo de almacenamiento y los objetos de base de datos permanecen en Active Directory porque se usarán más adelante para la portabilidad de bases de datos durante el proceso de la recuperación.

Activación y recuperación
Una entrada en el registro de eventos de aplicación indica que la base de datos de origen de SCR está dañada físicamente. Puesto que SCR se habilitó para SG1, se toma la decisión de realizar una activación manual de la base de datos del destino de SCR para SG1 y usar la portabilidad de bases de datos para restaurar la disponibilidad de datos. La activación de la copia del destino de SCR empieza con el desmontaje de MBX1 en SG1 mediante el siguiente cmdlet:
Dismount-Database EXMBX1\SG1\MBX1
A continuación, la base de datos de destino de SCR se vuelve viable para el montaje y se cambiará el inicio de los buzones situados originalmente en MBX1 a MBX1PORT.
El proceso de deshabilitar SCR y hacer que la base de datos del destino de SCR sea viable para el montaje implica ejecutar el cmdlet Restore-StorageGroupCopy. Esta tarea marca la base de datos de grupos de almacenamiento como montable y ofrece un informe sobre la pérdida de datos, si la hubiese, que se producirá a partir del montaje de la base de datos en el grupo de almacenamiento. También comprueba que todos los archivos de registro generados por la copia activa del grupo de almacenamiento están presentes en la ubicación del archivo de grupo de almacenamiento de la copia pasiva. Si falta alguno de los archivos de registro, la operación también tratará de copiarlos. El siguiente cmdlet se usa para hacer que la base de datos del destino de SCR sea viable para el montaje:
Restore-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
En este ejemplo, los archivos de registro del grupo de almacenamiento del origen de SCR están disponibles para copiar. Si estos archivos no están disponibles (por ejemplo, porque el equipo del origen de SCR no funciona), el parámetro Force debe agregarse a la tarea Restore-StorageGroupCopy. De lo contrario, Restore-StorageGroupCopy siempre intentará conectarse al origen de SCR para copiar cualquier archivo de registro que falte, y si el origen de SCR no está disponible, la tarea Restore-StorageGroupCopy producirá un error y la base de datos no será viable para el montaje. Al agregar el parámetro Force, se indica a la tarea Restore-StorageGroupCopy que los archivos de código fuente no están disponibles, en cuyo caso se omite el intento de conexión y procede a hacer que la base de datos del destino de SCR sea viable para el montaje.
Tras completar el comando de Restore-StorageGroupCopy, el administrador debe comprobar que la base de datos está en un estado de cierre correcto. Si la base de datos está en estado de cierre con errores (consulte technet.microsoft.com/aa996757.aspx), debe procurarse un cierre correcto. Si el prefijo de archivo de registro para el grupo de almacenamiento (por ejemplo, E00 o E01) es el mismo para el origen de SCR (EXMBX1\SG1) y el grupo de almacenamiento en el destino de SCR (SG1PORT) que se usará para la portabilidad de bases de datos (EXMBX2\SG1PORT), no será necesario ejecutar Eseutil en modo de recuperación y la operación final de montaje de la base de datos provocará el estado de cierre correcto de la base de datos después de que se hayan releído todos los archivos de registro replicados. Si la base de datos no tiene un estado de cierre correcto, deben ejecutarse las utilidades de la base de datos de Exchange Server (Eseutil) el modo de recuperación (Eseutil/R) respecto a la base de datos.
Una vez que la base de datos está en un estado de cierre correcto, podrá ejecutar dos comandos que actualicen Active Directory con nuevas ubicaciones para los archivos de grupo de almacenamiento y el archivo de base de datos. Estos comandos cambian las rutas de acceso para SG1PORT y MBX1 de sus rutas de acceso originales a las rutas de acceso para el grupo de almacenamiento y la base de datos (PORT SG1 y MBX1PORT) almacenados por etapas:
Move-StorageGroupPath EXMBX2\SG1PORT
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT
-EdbFilePath C:\SG1\MBX1PORT.EDB
–ConfigurationOnly
Es necesario incluir el parámetro –ConfigurationOnly en los comandos anteriores para que sólo se actualice la configuración de opciones para estos objetos en Active Directory. No se desplaza ningún dato ni archivo, y tampoco es necesario porque SCR ya ha replicado los datos a C:\SG1 en EXMBX2.
El siguiente paso es configurar la base de datos (MBX1PORT) para que se le permita sobrescribirse durante una operación de restauración. Esto se puede realizar seleccionando la casilla de verificación de la opción "Una restauración puede sobrescribir esta base de datos" en las propiedades de objeto de base de datos de la Consola de administración de Exchange o mediante el siguiente comando en el Shell de administración de Exchange:
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT
-AllowFileRestore:$true
Cuando haya configurado la base de datos para que se le permita sobrescribirse, el siguiente paso es montar la base de datos con el comando siguiente:
Mount-Database EXMBX2\SG1PORT\MBX1PORT
Después de montar la base de datos, debe cambiarse el inicio de los buzones cuyo inicio se había cambiado en la base de datos (SG1\MBX1) de SCR para que señalen a MBX1PORT en EXMBX2. Ejecute el cmdlet Get-Mailbox y canalice el resultado al cmdlet Move-Mailbox. Durante este proceso, es importante que el Operador de sistema de Exchange y los buzones del sistema no se incluyan en el resultado del cmdlet Get-Mailbox que se canaliza al cmdlet Move-Mailbox. No es necesario, ni se debe, cambiar el inicio de esos objetos de buzón. El siguiente comando se ejecuta para cambiar el inicio de todos buzones de usuario y excluir los buzones del sistema:
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|
ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly
-TargetDatabase EXMBX2\SG1PORT\MBX1PORT
En este momento, ya es posible el acceso de cliente a MBX1PORT. Sin embargo, el hecho de que los usuarios puedan realmente tener acceso a sus buzones después de que se hayan desplazado de EXMBX1\SG1\MBX1 a EXMBX2\SG1PORT\MBX1PORT depende de la latencia de replicación de Active Directory; es decir, en función del número de servidores de directorio, es posible que la actualización tarde un tiempo en propagarse por el entorno. Además, los métodos del acceso de cliente también influyen. Los clientes de mensajería que usan Outlook 2007 y clientes que no son Outlook tendrán acceso al buzón del usuario después de actualizar con las nuevas rutas los servidores de directorio usados por el servidor del acceso de cliente del usuario. Los clientes de mensajería que usan Outlook 2003 y versiones anteriores necesitarán que el perfil de mensajería del escritorio del usuario se actualice con el nuevo nombre de servidor.

Pasos finales
Después de que los clientes tengan acceso a sus buzones y datos de buzones, el paso final consiste en establecer la redundancia volviendo a habilitar SCR. Esto se consigue quitando los grupos de almacenamiento y archivos de base de datos restantes de EXMBX1. Después de quitar los archivos, se pueden desplazar las rutas de acceso de EXMBX1\SG1\MBX1 a una ubicación temporal y EXMBX1 puede convertirse en un destino de SCR de EXMBX2.

Scott Schnoll es uno de los principales autores técnicos del Equipo de Exchange Server de Microsoft, por lo que ha redactado contenido para Exchange Server 2007. Antes de incorporarse a Microsoft, Scott escribió Microsoft Exchange Server 2003 Distilled (Addison-Wesley Professional, 2004) y fue el principal autor de Exchange 2000 Server: The Complete Reference (McGraw-Hill/OsborneMedia, 2001).


 Comunicaciones: Ejecuci&#243;n de Exchange con Windows Server 2008
Comunicaciones Paul Bowden

Ejecución de Exchange con Windows Server 2008
Resumen:
  • Configuración de Exchange en Windows Server 2008
  • Sugerencias y trucos de configuración
  • Conozca su entorno de Exchange

En el equipo de desarrollo de Exchange en Microsoft, mi trabajo consiste en establecer la programación, el ritmo y las prioridades del equipo. Dentro de Microsoft, mi función se conoce como el administrador de versiones. Más o menos, viene a ser como un director técnico de proyecto en otras compañías. Como sabe cualquiera que haya trabajado
en este puesto, hace falta conocimiento, habilidad, dedicación al trabajo y el respeto del equipo para conseguir un buen producto a tiempo. Al trabajar con un equipo tan inteligente y con talento, la credibilidad no se logra de un día para otro, te la tienes que ganar a pulso.
Una manera de demostrar que estás dispuesto a dar lo mejor de ti es ejecutar tu buzón en un servidor con software propio: un servidor de producción que ejecuta una versión preliminar de Exchange. Se trata de un entorno incierto donde cada dos o tres semanas actualizamos con nuevas compilaciones de Exchange. Una instalación de estas características nos permite probar el software en un entorno real con interacción humana real. Hasta llegamos a ejecutar nuestros buzones en las compilaciones de prueba más recientes. Yo lo he vivido y ésta es mi historia.

Preparación para "Longhorn"
A finales de 2006, cuando acabábamos de lanzar al mercado Exchange Server 2007, había un sistema operativo nuevo en perspectiva, Windows Server®, cuyo nombre en código era "Longhorn". Cuando empezamos a poner en común los planes de nuestro primer Service Pack para la nueva plataforma de Exchange, se puso de manifiesto que las programaciones de Exchange y Windows® habían hecho recorridos similares y que "Longhorn" (ahora llamado Windows Server 2008) iba a ser importante. Fue en ese momento que decidimos diseñar Exchange Server 2007 SP1 tanto para Windows Server 2003 como para Windows Server 2008. Se precisa una cantidad considerable de coordinación y planeación para hacer compatible una aplicación empresarial en varias versiones de Windows. Por ejemplo, Exchange funciona en conjunción con IIS y Windows Server 2008 incluye una nueva versión, IIS 7.0.
Recuerdo la primera vez que instalé Windows Server 2008 en mi laboratorio a finales de diciembre de 2006. Hay dos cosas que permanecen en mi mente desde ese día: la primera, que la instalación fue rapidísima; y la segunda, que las herramientas de administración, aunque muy diferentes de las de Windows Server 2003, eran igual de fáciles de usar.
En nuestros laboratorios principales, Windows Server 2008 se instala en aproximadamente la tercera parte del tiempo necesario para una instalación de Windows Server 2003. Una de las razones es que los componentes opcionales, no imprescindibles para la ejecución del sistema operativo, no se incluyen en la configuración. Es fantástico para reducir la superficie de ataque del equipo y mantener las cosas tan sencillas como sea posible. Nadie quiere cosas innecesarias. La desventaja típica de una instalación de este tipo es que resulta necesario insertar el disco cada vez que se quieren agregar componentes adicionales. Pero con Windows Server 2008, todos los archivos se copian a una carpeta SxS (que significa en paralelo, del inglés "side-by-side"). A continuación se usa la herramienta Administrador de servidores para configurar los componentes necesarios y el sistema operativo se encarga de determinar el archivo que hay que copiar.
Llegado a este punto, debo mencionar algo llamado Server Core. Se trata de un modo de Windows Server 2008 en el que se instala tan sólo el sistema operativo mínimo e imprescindible. En este modo, se suele interactuar con la consola del servidor mediante el símbolo del sistema; ni siquiera está instalado el Explorador. Este modo es ideal para servidores de infraestructura, como controladores de dominio y servidores DNS. Sin embargo, aquí no se puede ejecutar cualquier tipo de aplicación. Exchange hace un uso exhaustivo de código administrado y ello le impide admitir instalaciones tipo Server Core.

Configuración de Exchange
Adoro partir de un Windows Server 2008 físico y el disco de instalación de Exchange Server 2007 SP1 e instalar un equipo de arriba a abajo sin más descargas ni requisitos previos. La mejor manera de configurar una instalación de Windows Server 2008 para Exchange es usando la herramienta ServerManagerCmd. He elaborado un archivo de respuesta XML, mostrado en la figura 1, que sólo instala los suficientes componentes del sistema operativo para permitir la instalación y ejecución de Exchange en Windows Server 2008. Una vez instalado el nuevo sistema operativo, sólo tengo que ejecutar este comando para configurar el sistema:
Figure 1 Archivo de respuesta ServerManagerCmd para Exchange (Close Figure 1)
<!-- ServerManagerCmd Answer File compatible with Windows Server 2008        -->
<!-- Usage: ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration
    Action="Install"
    xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: Install PowerShell 1.0 feature -->
    <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA: Install LDIFDE and other directory tools like LDP and ADSIEdit -->
    <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Install the Web Server role with additional child components -->
    <Role Id="Web-Server"/>
    <RoleService Id="Web-Metabase"/>
    <RoleService Id="Web-Lgcy-Mgmt-Console"/>
    <RoleService Id="Web-Basic-Auth"/>
    <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: Install the three authentication types for OWA, GZip compression, plus Outlook Anywhere support -->
    <RoleService Id="Web-ISAPI-Ext"/>
    <RoleService Id="Web-Digest-Auth"/>
    <RoleService Id="Web-Dyn-Compression"/>
    <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Install Active Directory Lightweight Directory Services (previously known as ADAM) -->
    <Role Id="ADLDS"/>

    <!-- UM: Install the Windows Media Player components -->
    <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
Cuando este proceso ha terminado y se ha reiniciado el sistema, dispone de todo lo necesario para instalar funciones de Exchange, como Buzón, Acceso de cliente, Transporte de concentradores, Transporte perimetral y Mensajería unificada.
Otro truco útil es usar ServerManagerCmd con el modificador de comandos –query. Esto enumerará toda la lista de funciones y servicios y muestra los que están configurados realmente (indicado por el texto verde de la figura 2).
Figura 2 Enumeración de funciones y servicios de Exchange
Figura 2 Enumeración de funciones y servicios de Exchange
Pero, volvamos a la historia. Pasamos los primeros meses de 2007 en el laboratorio, determinando los cambios necesarios para lograr un gran rendimiento en Windows Server 2008. Si algo he aprendido, es que se puede estar instalando el software e insistiendo con él en el laboratorio hasta tener la cara amoratada, pero la verdadera medida de la calidad se encuentra en las implementaciones reales y en activo, con usuarios reales y activos. Y ése es precisamente el motivo por el cual usamos en situaciones diarias nuestros propios productos, para probarlos mediante el uso real, cotidiano, el que sirve para hacer el trabajo. El lanzamiento de Windows Server 2008 Beta 3 en abril de 2007 fue el punto decisivo: había que dar el paso e implementarlo en un entorno de producción.
Yo estaba allí, sentado detrás de un miembro del equipo de operaciones, viendo cómo implementábamos el primer conjunto de servidores de Exchange en Windows Server 2008. La instalación de Exchange fue perfectamente y todos los servicios se iniciaron. Ahora, sólo teníamos que mover un buzón y averiguar si realmente funcionaba. Me ofrecí para llevar a cabo esas comprobaciones. Tengo un buzón de 2 GB y 26 minutos más tarde, allí estaba yo en marcha, enviando correo electrónico con Exchange en Windows Server 2008. ¡Todo un éxito!

Lecciones aprendidas
Desde esa primera instalación en Windows Server 2008, hemos estado haciendo ajustes y asegurándonos de que verdaderamente estamos preparados para el estreno. Por el camino, tuvimos que tomar algunas decisiones clave de la implementación.
Instalación Puede usar Exchange Server 2007 SP1 como actualización de la instalación de Exchange Server 2007 original —lo que yo llamaría Exchange 2007 RTM (versión de lanzamiento a fabricación)— o puede tomar un equipo nuevo e instalarlo directamente con el disco de instalación de Exchange Server 2007 SP1. Esto es importante porque no se puede instalar Exchange Server 2007 RTM en un equipo que ejecute Windows Server 2008.
Actualizaciones Aunque se pueda actualizar el sistema operativo localmente de Windows Server 2003 SP2 a Windows Server 2008, hay algunos componentes que es necesario desinstalar antes. Uno de éstos es Windows PowerShell™. Se trata del mismísimo centro de la administración de Exchange; incluso la instalación de Exchange se basa en Windows PowerShell. Por este motivo, no se pueden admitir actualizaciones locales del sistema operativo cuando Exchange ya está instalado. En muchos casos, esto suele significar que se querrá instalar Windows Server 2008 en un equipo nuevo y después instalar Exchange Server 2007 SP1.
IPv6 Exchange se ha diseñado para sacar provecho de varias características nuevas de Windows Server 2008. Por ejemplo, IPv6 se instala de forma predeterminada, y dos servidores de Exchange que se ejecuten en el nuevo sistema operativo usarán automáticamente IPv6 para comunicarse entre ellos. Las interfaces de la consola de administración de Exchange también aceptarán intervalos de direcciones IPv6. Hay una salvedad: Exchange continúa precisando una dirección IPv4 para enlazarla con cada interfaz de red.
Controladores de dominio de sólo lectura Un cambio algo radical para las implementaciones de Active Directory® es el concepto de controlador de dominio de sólo lectura (o servidor de catálogo global). Permite que las compañías implementen un servidor de Active Directory que recibe réplicas unidireccionales y no tiene capacidad para devolver la réplica de los cambios. Esto puede ser útil en situaciones en las que hay sucursales u oficinas remotas donde la seguridad física no se puede garantizar. Lamentablemente, Exchange Server 2007 SP1 no puede usar un controlador de dominio de sólo lectura y requiere tener acceso a una partición grabable normal de Active Directory.

Su entorno de Exchange
Exchange y recursos de Windows Server
  • Windows Server 2008 TechCenter
  • Microsoft Exchange Server TechCenter
  • Centro de evaluación de TechNet
  • Laboratorios virtuales de Windows Server 2008

Cuando toca elegir el nivel de sistema operativo para la implementación, dispone de flexibilidad para ejecutar una variedad de configuraciones, como se muestra en la figura 3.
Figure 3 Matriz de entorno de Exchange (Close Figure 3)

Versión de Exchange | Sistema operativo del servidor | Controlador de dominio
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
Otra consideración son las implementaciones de versiones mixtas. Por supuesto, puede tener una mezcla de versiones de Exchange y de Windows que interoperen unas con otras. Por ejemplo, puede implementar Exchange Server 2007 SP1 en Windows Server 2008 para servidores de acceso de cliente y dejar que tengan acceso a Exchange Server 2007 RTM en servidores de buzón de Windows Server 2003.
Hay algunos matices que deben tenerse en cuenta con versiones anteriores de Exchange y Windows Server 2008 Active Directory. Si dispone de Exchange Server 2003 SP2 y posteriores, puede implementar y usar controladores de dominio de Windows Server 2008 en su entorno. Sin embargo, si todavía tiene implementado Exchange 2000, quizá quiera aplazar la implementación de los controladores de dominio de Windows Server 2008 en el sitio de Active Directory en el que se encuentran esos servidores de Exchange Server o bien codificar de forma rígida la configuración de Directory Service Access (DSAccess), de modo que Exchange 2000 no intente usar los controladores de dominio de Windows Server 2008.

Comentarios finales
Hemos puesto mucho empeño en que Exchange 2007 SP1 funcione bien en plataformas de Windows Server 2003 y de Windows Server 2008. En Exchange, pretendemos ofrecer flexibilidad de implementación y mejores escenarios conjuntos. Creo que le sorprenderá agradablemente la comodidad y la rapidez con la que se puede implementar Exchange en Windows Server 2008. También se encontrará con alguna mejora sutil del rendimiento subyacente y la escalabilidad, como la escalabilidad del servidor de acceso de cliente, claramente superior para clientes de Outlook Anywhere.
Windows Server 2008 proporciona la plataforma para futuras innovaciones en el área de mensajería. No le decepcionará.

Paul Bowdenes director de administración de programas en el equipo de Exchange Server. Emplea mucho de su tiempo libre confirmando la información de su cuenta PayPal bajo solicitud previa.


 Comunicaciones: Implementaci&#243;n de Mensajer&#237;a unificada con Exchange Server 2007
Comunicaciones Jeff Goodwin

Implementación de Mensajería unificada con Exchange Server 2007
Resumen:
  • Aspectos básicos de telefonía
  • Consideraciones en el diseño de Mensajería unificada
  • Migración de los usuarios

Así pues, ha decidido implementar Mensajería unificada de Exchange Server 2007 en su entorno. Ya ha instalado una función de servidor Mensajería unificada, la ha integrado en su PBX existente y gracias a ello, usted y otros 10 empleados disfrutan de correo de voz, correo electrónico y mensajes de fax almacenados en Exchange. Por el momento, puede que
haya considerado esta acción como un logro fundamental. ¿Pero cómo implementar las mismas características a miles de suscriptores, dispersos entre múltiples sitios, sin causar un impacto en el negocio?
Espero que este artículo le ayude. Lo escribí con la intención de ayudarle a comprender cómo implementar Mensajería unificada en su entorno y para ayudarle a clarificar los conceptos de telefonía asociados con tal implementación. Si necesita ayuda con la instalación, configuración o características de la Mensajería Unificada de Exchange Server 2007, consulte la barra lateral "Recursos de Mensajería unificada" al final de este artículo. Además, Microsoft ha identificado a compañías como especialistas en Mensajería unificada para que ayuden a los clientes con la consulta, diseño e implementación de Mensajería unificada de Exchange Server 2007. Si necesita ayuda con la instalación, configuración o implementación, póngase e contacto con uno de estos especialistas, también indicados en la barra lateral.

Introducción
Las tecnologías de mensajería unificada no constituyen una novedad para Exchange; muchas organizaciones ofrecen productos de mensajería unificada que se integran con Exchange. Sin embargo, esta es la primera versión de Exchange que es compatible de manera nativa con la mensajería unificada. Desde su presentación, muchos clientes han implementado la mensajería unificada de Exchange Server 2007 en grupos pequeños dentro de sus organizaciones. No obstante, por varias razones, no siempre han implementado Mensajería Unificada en todos sus usuarios. Un problema es que muchos administradores de Exchange no están familiarizados con los conceptos de la telefonía y las tecnologías necesarias para la implementación de servicios de mensajería unificada y han realizado un gran esfuerzo con el objeto de diseñar e implementar estas soluciones en sus empresas.
Al igual que con todo proyecto de implementación, un enfoque por fases normalmente ofrece los mejores resultados. Las cinco fases (planeación de la arquitectura, prueba de la solución, implementación piloto de una comunidad de usuarios, aprendizaje y migración de los usuarios a un nuevo sistema) constituyen todos los aspectos de un proyecto de mensajería unificada por lo que todas deben tenerse en cuenta. A la hora de la planeación del proyecto es muy importante incluir tanto grupos de TI como de telecomunicaciones dentro de la organización.
Muchas características que los usuarios dan por sentadas en plataformas tradicionales de correo de voz deben duplicarse o, en caso de que no sea posible, deben diseñarse para que reduzcan la repercusión en las comunidades de usuarios cuando se implementa un sistema nuevo. Se trata de un área clave en la que debe usar la ayuda proporcionada por el equipo de telecomunicaciones. Al mismo tiempo, el equipo de telecomunicaciones necesitará conocer a través del equipo de TI los aspectos necesarios para administrar, solucionar problemas y ser compatible con la nueva plataforma de correo de voz a medida que se desarrolla la implementación.

Aspectos básicos de telefonía
Verá como la planeación es mucho más sencilla si comprende la arquitectura básica, el flujo de llamadas y las terminologías relacionadas con la mensajería unificada. La figura 1 muestra un ejemplo de solución de mensajería unificada integrada en un sistema de telefonía corporativo. Ahora observemos detenidamente algunos de los conceptos y tecnologías más comunes que probablemente encontrará a lo largo de esta implementación.
Figura 1 Solución para pasar de central de conmutación a Mensajería unificada
Figura 1 Solución para pasar de central de conmutación a Mensajería unificada
Una central de conmutación (PBX) es una red telefónica privada que se usa en una empresa. En este sistema, cada usuario tiene normalmente un teléfono de escritorio conectado a la PBX, desde la cual las llamadas pueden desviarse a otros usuarios internos simplemente marcando una extensión (normalmente de cuatro o cinco dígitos) y a teléfonos externos.
Si los clientes de empresa tienen muchas ubicaciones con PBX, en ocasiones pueden decidir unir los sistemas a través de tecnologías de redes específicas del proveedor de PBX. Esto permite a todos los usuarios de las PBX en red llamarse entre ellos simplemente marcando una extensión.
La mensajería unificada implica la integración de dos sistemas dispares: la mensajería de Exchange y el sistema de telefonía físico. Las comunicaciones entre el servidor Mensajería unificada y la arquitectura de telefonía se llevan a cabo mediante el Protocolo de inicio de sesión (SIP). Algunas tecnologías de PBX pueden comunicarse directamente con el servidor Mensajería unificada a través de SIP; otras requerirán una puerta de enlace SIP. En la figura 1, la PBX se conecta a una puerta de enlace SIP a través de una línea T1. Al reenviar una llamada a Mensajería Unificada, la PBX envía información (número de teléfono de quien llama, número de teléfono de quien recibe la llamada y algún tipo de código de motivo) a la puerta de enlace SIP de modo que el servidor Mensajería unificada pueda entender para quién es la llamada.
Algunas PBX pueden unirse en red a través de una red IP. Las redes de telefonía posibilitan la redirección de llamadas a través de la red IP a una solución centralizada de correo de voz. Por ejemplo, si observa la figura 2, advertirá que Zurich está conectado en red con Londres.
Figura 2 Una implementación de Mensajería unificada más compleja
Figura 2 Una implementación de Mensajería unificada más compleja

Flujo de llamadas
Recursos de Mensajería unificada
  • Catálogo de especialistas en Mensajería unificada
  • TechCenter de Mensajería unificada de Exchange
  • Puertas de enlace SIP compatibles
  • Asesor de telefonía
  • Notas de configuración de PBX

Suponga que una persona externa realiza una llamada a un teléfono de suscriptor de Mensajería unificada. En este caso, el suscriptor de Mensajería unificada no está en la oficina y no se contesta al teléfono. Puede seguir la ruta de acceso del mensaje en la figura 1.
La PBX envía la llamada a la puerta de enlace SIP, que negocia la llamada mediante SIP a través de TCP con el servidor Mensajería unificada. El servidor recibe los datos de integración de la puerta de enlace SIP que le indica para quién era la llamada. El servidor Mensajería unificada reproduce, a continuación, el saludo del suscriptor y permite grabar un mensaje a la persona externa que realiza la llamada. Ese mensaje se entrega en el buzón de Exchange del suscriptor de Mensajería unificada.
Este flujo de llamadas es una descripción excesivamente simplificada de lo que ocurre. Es importante comprender que cuando se graba un mensaje, el servidor Mensajería unificada reenvía el mensaje al servidor Transporte de concentradores a través de SMTP para la entrega al servidor Buzón.
Al igual que los suscriptores de Mensajería unificada, los usuarios tienen ahora acceso a su buzón de Exchange a través de un teléfono (mediante Outlook® Voice Access) o el equipo (mediante Outlook 2007 o Outlook Web Access). Pero los suscriptores pueden tener acceso también a los mensajes a través del teléfono mediante Outlook 2007 o Outlook Web Access con una característica llamada Reproducción telefónica, que permite que la Mensajería unificada reproduzca para el suscriptor el mensaje seleccionado mediante una llamada a un teléfono especificado en lugar de obtener acceso a él mediante el equipo. Si se usa este método, el servidor Mensajería unificada interactúa con el servidor Acceso de cliente y el servidor Buzón. Es importante entender esto, si coloca un servidor Mensajería unificada en una oficina remota que no tenga un servidor local Acceso de cliente, el servidor Mensajería unificada necesitará atravesar la WAN para ponerse en contacto con el servidor Acceso de cliente y esto puede provocar un rendimiento lento.

Diseño del sistema
Existen dos diseños de arquitectura principal de Exchange entre los cuales se pueden clasificar los clientes: centralizado o descentralizado. Por regla general, la arquitectura de Mensajería unificada seguirá su arquitectura de Exchange, lo cual significa que en cualquier lugar en el que implemente un servidor Buzón, se implementará un servidor Mensajería unificada. Por supuesto, siempre hay excepciones a cualquier regla.
Al diseñar su arquitectura de Mensajería unificada, hay cinco áreas básicas que debe considerar.
  • Colocación del servidor
  • Número de servidores Mensajería unificada
  • Puerta de enlace SIP
  • Almacenamiento del buzón
  • Configuración del sitio Mensajería unificada
Y no olvide la continuidad empresarial. Por regla general, su plan de recuperación de desastres relacionado con Exchange puede usarse para determinar elementos relevantes para la Mensajería unificada.
Las situaciones de implementación de ejemplo pueden ayudarle a entender las funciones del servidor Mensajería unificada. La figura 2 muestra claramente una implementación de empresa a gran escala de Exchange Server 2007 con Mensajería unificada.
En este diseño más complejo, los principales centros de datos son Seattle y Londres. Los servidores Mensajería unificada en estas ubicaciones sirven a sus respectivas comunidades de usuarios puesto que los servidores Buzón y Transporte de concentradores son locales. Ambos sitios tienen PBX de IP que proporcionan cobertura de llamadas al servidor local Mensajería unificada para contestar llamadas.
Los sitios de tamaño mediano se localizan en Nueva York y Glasgow. Los servidores Mensajería unificada en estas ubicaciones sirven a sus respectivas comunidades de usuarios puesto que los servidores Buzón y Transporte de concentradores son locales. Al igual que con los centros de datos principales, ambos sitios tienen PBX de IP que proporcionan cobertura de llamadas al servidor local Mensajería unificada para contestar llamadas.
Los sitios más pequeños no tienen servidores localizados Buzón ni Transporte de concentradores pero ofrecen capacidades de Mensajería unificada desde los centros de datos principales. Austin tiene una PBX NEC que usa conectividad analógica a una puerta de enlace SIP local. Las llamadas a usuarios finales locales se reenvían a la puerta de enlace SIP, que negocia con el servidor Mensajería unificada en Seattle para proporcionar contestación a las llamadas en Mensajería unificada.
Zurich tiene un Avaya Communication Manager que se conecta en red a través de la red IP al Avaya Communication Manager en Londres. Las llamadas a usuarios locales se reenvían a través de la red del Avaya Communication Manager, que negocia con el servidor Mensajería unificada en Londres para proporcionar contestación de llamadas en Mensajería unificada.
En este ejemplo, el sitio de Seattle tiene servidores Buzón de Exchange y servidores Mensajería unificada en la misma ubicación física. Cuando se trata de una arquitectura de un único sitio, todos los servidores (Buzón, Mensajería unificada, Acceso de cliente, etc.) y el equipo de PBX forman parte del mismo sitio. Las corporaciones con varios sitios agregan complejidad al diseño. Esta complejidad puede abrumar un poco, pero gracias a una comprensión apropiada de los principios básico de la Mensajería unificada, es fácilmente solucionable.
Tal como se muestra en la figura 2, si un sitio contiene un servidor Buzón, la recomendación es colocar un servidor Mensajería unificada allí también. Seattle, Londres, Nueva York y Glasgow se adaptan a este diseño. Ni Austin ni Zurich tienen un servidor Buzón de manera local, pero los servicios de Mensajería unificada pueden suministrarse a estas ubicaciones mediante el uso de la red IP. Austin tiene una PBX analógica local. En este caso, debe usarse una puerta de enlace SIP para ofrecer la conectividad de red IP al servidor Mensajería unificada en Seattle. Zurich tiene una PBX de IP local que se conecta a la PBX de Londres a través de la red. De este modo, las llamadas a un usuario en Zurich desviarían la red de telefonía a la PBX de Londres y al servidor Mensajería unificada.
Puesto que las llamadas realizadas a los suscriptores en Zurich se desvían a la red y se administran mediante un sistema de Mensajería unificada centralizado en Londres, si la red experimenta una interrupción inesperada, las llamadas a todos los suscriptores en Zurich no obtendrán respuesta hasta que la red se repare. Si se requiere la supervivencia local en el caso de una interrupción inesperada de la red, podría colocarse un servidor Mensajería unificada en Zurich. En caso de una interrupción inesperada de la red, el servidor Mensajería unificada continuará respondiendo a las llamadas y las proporcionará cuando la red se repare.
La colocación del servidor es probablemente el factor más importante a considerar cuando se diseña una arquitectura para adaptarse a su entorno. El organigrama de la figura 3 le ayudará a determinar la ubicación adecuada del servidor.
Figura 3 Determinación de la colocación del servidor
Figura 3 Determinación de la colocación del servidor

Estimación de las necesidades del servidor
El área siguiente a considerar es cuántos servidores Mensajería unificada serán necesarios para dar servicio a la comunidad de usuarios. La respuesta a esta pregunta depende realmente de varios factores que son específicos del sitio.
La escalabilidad en Mensajería unificada se determina dependiendo del número de llamadas simultáneas (llamadas puertos en el mundo de la telefonía) puede admitir el servidor. Cada llamada al sistema requiere que el servidor Mensajería unificada dedique recursos de red, CPU, memoria y disco. Al agregarse a estos recursos, un servidor Mensajería puede ser compatible con más llamadas simultáneas. Puesto que estos recursos siempre están limitados, el servidor Mensajería unificada podrá administrar muchas llamadas simultáneas al mismo tiempo siempre que los recursos no se sobrecarguen.
Gracias a los cálculos del análisis de tráfico de Erlang es posible determinar cuántos puertos son necesarios para poder admitir un número de suscriptores, pero en estos momentos no ampliaré este tema. Para determinar más fácilmente cuántos puertos son necesarios, pregunte simplemente a su administrador de telefonía cuántos puertos de correo de voz se usan en el sistema de correo de voz existente. Según las experiencias en este campo, los requisitos de puerto en un sistema tradicional de correo de voz y en un sistema de correo de voz unificado deben ser muy similares.
Generalmente yo recomiendo no implementar más de 60 puertos en un mismo servidor. Esto no tiene nada que ver con limitaciones de software o hardware. Más bien se basa en el hecho de que un solo servidor con 60 puertos puede dar servicio a unos 5.000 usuarios. Si ese único servidor experimenta una interrupción inesperada, habrá provocado un error de servidor único en toda su (extensa) base de suscriptores.
Al implementar los servidores Mensajería unificada, puede que desee considerar el diseño de una redundancia N+1 en la arquitectura. La figura 4 muestra un servidor completamente redundante y el diseño de una puerta de enlace SIP. Mediante este diseño, si el servidor Mensajería unificada 1 experimenta una interrupción inesperada, las llamadas desde la puerta de enlace SIP 1 negociarán las llamadas con el servidor Mensajería unificada 2 de manera automática. Es posible también programar la PBX para distribuir la carga de llamadas de manera uniforme entre las puertas de enlace SIP. Por ejemplo, la primera llamada en el sistema podría enrutarse a la puerta de enlace SIP 1 y la llamada siguiente en el sistema podría enrutarse a la puerta de enlace SIP 2. La alternancia de las llamadas entre las puertas de enlace garantiza una distribución uniforme de las llamadas y un uso compartido de la carga entre los servidores Mensajería unificada.
Figura 4 Distribución de llamadas entre servidores para la redundancia
Figura 4 Distribución de llamadas entre servidores para la redundancia
Existen actualmente dos proveedores de puerta de enlace SIP compatibles con las soluciones de Mensajería unificada de Exchange Server 2007: AudioCodes y Dialogic. Si son necesarias puertas de enlace SIP en su diseño, asegúrese de adquirir una que sea compatible con el número de sesiones (puertos) requeridos por su diseño. Por ejemplo, si su diseño requiere 32 puertos, necesitará una puerta de enlace que sea compatible con, al menos, ese número de sesiones.
Si se pregunta si su PBX funcionará con la Mensajería Unificada o qué puerta de enlace debe usar, observe la barra lateral "Recursos de Mensajería unificada". Los vínculos enumerados allí le dirigirán a instrucciones específicas de Microsoft así como a un catálogo de especialistas en Mensajería unificada que pueden ayudarle a evaluar las necesidades específicas de su organización. Desde el punto de vista de mi experiencia personal, no hay muchas PBX que pueda hacer funcionar con las puertas de enlace SIP y la Mensajería unificada de Exchange, además algunas PBX pueden comunicarse con el servidor Mensajería unificada de manera nativa mediante SIP a través de TCP.
La Mensajería unificada de Exchange es compatible con tres códecs de audio para almacenar los mensajes de correo de voz: G.711 PCM Linear, GSM 06.10 y códec de audio de Windows Media® (WMA). Cada archivo de WMA PCM Linear ocupa aproximadamente 16 KB por cada segundo de audio. WMA es el códec de audio predeterminado para la Mensajería unificada y comprime el audio a 1,1 kilobits (KB) por cada segundo de audio con un encabezado de 7 KB. GSM 06.10 comprime el audio a 1,6 KB por cada segundo de audio, pero tiene un encabezado más pequeño que la codificación WMA.
Tanto la codificación WMA como la GSM 06.10 tienen una calidad de voz aceptable para mensajes de voz. Según la experiencia de campo extraída del uso de los códecs WMA o GSM, puede asumir de un 10% a un 20% de incremento en el tamaño del almacén del buzón según el nivel de uso del correo de voz que tenga la organización.
Al decidir que códec de audio usar para su entorno, tenga en cuenta los dispositivos móviles y sistemas operativos que pueden estar usando los usuarios finales. Las preguntas en este tema se relacionan en su mayor parte con si los usuarios pueden escuchar el correo de voz en sus dispositivos Windows® Mobile. Otros sistemas operativos constituyen también una preocupación: puede que tenga una implementación a gran escala de equipos Linux que no pueden reproducir los archivos WMA. Cualquiera que sea el caso, tenga en cuenta que tales factores se agregarán a los requisitos del recurso del servicio de soporte técnico que necesita considerar a la hora de llevar a cabo su aprendizaje.

Configuración y prueba
Si la arquitectura de Mensajería unificada es centralizada o distribuida, hay muchos requisitos del correo de voz que deben considerarse antes de implementar la Mensajería unificada en su organización. Encontrará una lista detallada de los temas que necesitan una explicación por parte del equipo del proyecto en la barra lateral "Lista de comprobación de Mensajería unificada". Debe reunir la información de todos los temas para cada sitio donde considere la implementación de la Mensajería unificada. Recuerde, tanto los equipos de TI como los de telecomunicaciones necesitan tratar estos temas juntos.
Una vez que su sistema haya sido designado y que haya terminado la configuración, debe implementarse un sistema de prueba para validar el diseño. En un diseño de varios sitios, recomiendo, al menos, la prueba de dos sitios independientes para mostrar la prueba de concepto y para validar que el diseño funciona correctamente.
El plan de prueba de funcionalidades debe desarrollarse desde sus requisitos de configuración y, a continuación, finalizarse. El plan de prueba de funcionalidad debe incluir los métodos de acceso del suscriptor (teléfono, Outlook 2007 y Outlook Web Access), los métodos de administración y las interrupciones inesperadas de la red y del hardware.
Una vez se lleva a cabo la prueba y que todo el personal esté de acuerdo en que la Mensajería unificada duplicará las ventajas del anterior sistema de correo de voz o que se haya diseñado una solución alternativa para compatibilizar con cualquier configuración o característica que no pueda duplicarse, debe seleccionarse un grupo piloto de usuarios para probar el sistema. La habilitación del grupo piloto demostrará los pasos necesarios en su entorno para mover (o para actualizar, en la jerga de telefonía) a los suscriptores desde el sistema anterior de correo de voz a la Mensajería unificada. En general, éstos son los pasos necesarios para actualizar un suscriptor:
  1. Deshabilitar al suscriptor del sistema existente de correo de voz.
  2. Habilitar al suscriptor en Active Directory para Mensajería unificada a través de la Consola de administración de Exchange.
  3. Cambiar la ruta de acceso de cobertura del teléfono a un número piloto de Mensajería unificada.
Es importante deshabilitar al suscriptor del sistema de correo de voz existente de manera que no se envíen mensajes al buzón anterior.
Durante la fase piloto, debe capturar cualquier pregunta que tengan sus suscriptores respecto a la funcionalidad del sistema. La documentación de estos detalles le permitirá tratar los problemas comunes durante la fase de aprendizaje.
El aprendizaje es básico para una actualización correcta. Sus usuarios están acostumbrados a tener acceso al correo de voz desde el teléfono con una interfaz de usuario específica. Por ejemplo, algunos sistemas de correo de voz requieren que los usuarios presionen el 5 para escuchar los mensajes. La Mensajería unificada de Exchange requiere que los usuarios presionen 1 o digan "correo de voz" (o usen Outlook 2007 o Outlook Web Access para reproducir los mensajes de voz). El aprendizaje del suscriptor de Mensajería debe incluir la navegación de la interfaz de usuario de telefonía, la navegación de Outlook Voice Access y la navegación de Outlook/Outlook Web Access.
Con la Mensajería unificada de Exchange 2007, la capacidad de ejecutar comandos con órdenes verbales está integrada en Outlook Voice Access. Algunos usuarios tienden a entusiasmarse respecto a las nuevas capacidades del sistema y este entusiasmo puede ayudar a facilitar la transición de una interfaz de usuario a otra.
La Mensajería unificada de Exchange tiene la capacidad de enviar un mensaje de correo electrónico de texto personalizado a cada usuario a medida que éstos sean habilitados. Estos mensajes personalizados pueden usarse para ofrecer vínculos web valiosos a preguntas más frecuentes (P+F), la documentación del suscriptor, los números de teléfono del servicio de soporte técnico, etc. También pueden contener información acerca de cómo tener acceso al sistema de correo de voz y la contraseña única del suscriptor. Esta constituye una de las características más eficaces de las que poder sacar ventaja a la hora de habilitar los usuarios finales.

Migración de usuarios
Lista de comprobación de Mensajería unificada
Las secciones siguientes definen algunos elementos básicos del sistema de Mensajería unificada y sugieren preguntas que necesitan ser respondidas en la preparación para implementar y configurar la Mensajería unificada de Exchange Server 2007. Use esto como lista de comprobación para desarrollar un plan de implementación.
Planes de marcado Un plan de marcado de Mensajería unificada lógicamente corresponde a una PBX y a las extensiones asociadas. Algunos aspectos del plan de marcado que deben considerarse de antemano son:
  • ¿Cuántos dígitos hay en los números de la extensión?
  • ¿Cuál es el número piloto del sistema de Mensajería unificada?
  • ¿Qué necesitan marcar los usuarios para obtener una línea externa?
  • ¿Qué códec de audio usará para los mensajes?
  • ¿Cuál es el número de extensión del operador de la compañía?
Grupos de extensiones y Números piloto. Un grupo de extensiones es un conjunto de extensiones de teléfono configuradas para recibir llamadas en un orden particular. El número piloto es la extensión principal a la que se llama para tener acceso al grupo de extensiones. Necesita un número de extensiones de miembro del grupo de extensiones igual al número de puertos de correo de voz de su diseño.
Directivas de buzón Las directivas de buzón del correo de voz no difieren mucho de las directivas de buzón de Exchange. Éstas son algunas de las directivas que quizás desee tratar con mayor detalle:
  • ¿Cuántos días se conservan los correos de voz antes de eliminarse?
  • ¿Con qué frecuencia son necesarios los restablecimientos de contraseña del correo de voz?
  • ¿Cuál es la directiva de copia de seguridad del correo de voz?
  • ¿Cuál es la longitud mínima aceptable de la contraseña?
  • ¿Cuál es el número máximo de intentos de inicio de sesión antes del bloqueo del buzón?
Asistente automatizado (AA). Los asistentes automatizados responden a las llamadas entrantes que no están destinadas a un suscriptor específico. Pueden ofrecer información y dirigir a las personas que llaman a ubicaciones dentro de la organización. Mensajería unificada de Exchange ofrece DTMF y capacidades de voz para la navegación del AA. Los factores que hay que considerar incluyen:
  • ¿Hay mensajes de asistencia por voz del AA diferentes para el día, la noche y las vacaciones? (Los mensaje de asistencia por voz deben documentarse y grabarse).
  • ¿A quién se puede llamar desde el menú del AA?
  • ¿Puede considerarse la navegación de voz una capacidad cuando se usa el AA?
  • ¿Se necesitan múltiples idiomas para usar el AA?
Buzón general o de noche. Algunas organizaciones tienen un buzón de correo de voz general o de noche que permite a las personas que llaman dejar mensajes de entrega generales. Si su compañía tiene uno, debe crearse y habilitarse un buzón de Exchange para la Mensajería unificada.
Indicación de mensaje en espera (MWI). La indicación de mensaje en espera se refiere a la luz del teléfono que le alerta sobre mensajes de voz no leídos en su buzón. ¿Constituye la indicación de mensaje en espera en los auriculares del teléfono un requisito para la implementación?
Compatibilidad con múltiples extensiones. Muchas organizaciones tienen empleados que disponen de varios teléfonos. Al habilitar a estos suscriptores para la Mensajería unificada, es necesario asociar todos sus números de extensión al mismo tiempo. Antes de empezar, desarrolle una lista de empleados con múltiples extensiones.
Compatibilidad con la respuesta interactiva de voz (IVR). Algunos sistemas de correo de voz tradicionales son compatibles con aplicaciones de IVR que la Mensajería unificada no podrá duplicar. Determine si el sistema que se va a reemplazar dispone de tales aplicaciones asociadas al mismo. Esas aplicaciones pueden permanecer en el sistema existente o puede que tengan que ser reemplazadas por aplicaciones IVR alternativas.
Red de correo de voz. La red de correo de voz proporciona un método para enviar un mensaje desde un sistema a otro sistema dispar. Por ejemplo, en empresas grandes, el director general puede desear enviar un mensaje de voz a toda la organización o puede que tenga que anunciar información general como, por ejemplo, un simulacro. Con una red de correo de voz, el director general podría grabar un mensaje de voz una vez y enviarlo a cada empleado de la compañía sin importar en qué sistema de correo de voz se encuentre. Actualmente, la Mensajería unificada de Exchange no tiene la capacidad de conectarse en red a otros sistemas de correo de voz tradicionales.
Compatibilidad con fax. Algunas plataformas de correo de voz tradicionales son compatibles con faxes de entrada, lo cual le permite el uso de un único número de teléfono tanto para la voz como para los faxes de entrada. La Mensajería unificada de Exchange Server 2007 es compatible con faxes de entrada y se puede usar para reemplazar esa capacidad. Esta es una característica unidireccional; por lo que el sistema no es compatible con la capacidad de faxes de salida. Si esto constituye un requisito, necesitará usar un producto de terceros para poder ser compatible con esta característica.

Existen muchos puntos de vista acerca de cómo migrar el sistema en un entorno de producción completo. Las dos metodologías principales son una migración gradual y una migración inmediata. Independientemente de la que seleccione, debe formar al personal del servicio de soporte técnico en referencia a las preguntas comunes que grabó desde su grupo piloto. Asegúrese, además, de mostrarles cómo habilitar un usuario, cómo validar si un usuario está habilitado y cómo cambiar una contraseña.
La migración de los usuarios desde un sistema de correo de voz anterior a la Mensajería unificada es muy fácil, pero debe estar pendiente de un problema importante: la red del correo de voz. Al igual que un sistema de corre electrónico le permite enviar, reenviar y responder a otros usuarios y sistemas de correo electrónico, el correo de voz también le permite enviar, reenviar y responder a otros usuarios y sistemas de correo de voz.
Tome como ejemplo un escenario en el que Alice y Brian se encuentren actualmente en un sistema de correo de voz anterior. Brian ha migrado a la Mensajería unificada y desea enviar un mensaje a Alice que se encuentra en el sistema anterior del correo de voz. Puesto que los dos usuarios están en sistemas separados, ya no pueden enviar, reenviar o responder entre ellos a mensajes de correo de voz; desafortunadamente, se ha creado una isla en el correo de voz.
En los sistemas de correo de voz tradicionales este problema se resuelve con el uso de algún tipo de conversor de protocolo de red que permita la conexión en red de sistemas distintos. Actualmente, sin embargo, no existe un conversor de protocolo de red que permita la conexión en red de sistemas dispares con la Mensajería unificada de Exchange Server 2007. Aunque esto puede no constituir un aspecto importante para su organización, es algo que debe tenerse en cuenta cuando se escoja migrar usuarios en grupos pequeños.
Mi preferencia es realizar una migración inmediata de todos los usuarios del sitio. Una migración inmediata supone una actualización limpia de un sistema a otro. A menudo ocurre a lo largo de un fin de semana; los usuarios se van a casa el viernes y vienen a trabajar el lunes con un nuevo sistema de correo de voz. Algunos administradores dicen que una migración inmediata debe usarse sólo para clientes de empresas pequeñas en sitios remotos. No estoy de acuerdo. He participado en migraciones inmediatas de más de 7.000 usuarios en una ubicación única en las que menos de un 1% de los empleados necesitaron llamar al servicio de soporte técnico para solicitar ayuda. Si el resto de las fases de su proyecto han sido planeadas y llevadas a cabo adecuadamente, la actualización a un sistema de producción completo debe ir sobre ruedas.
Cuando actualice múltiples sitios en producción completa, sin embargo, considere en primer lugar una actualización de los sitios remotos de uno en uno antes de actualizar el sitio más grande. Revise las lecciones aprendidas de los sitios más pequeños e implemente los cambios necesarios en su plan de proyecto.
Normalmente, debe completarse todo el aprendizaje del usuario y deben habilitarse todos los usuarios para la Mensajería unificada antes de actualizar el sistema activo. Le presentamos una metodología paso a paso que puede usar para prepararse para una migración inmediata de un sistema de correo de voz.
En primer lugar, debe validar que el sistema de Mensajería unificada está instalado completamente y que se ha configurado y probado.
Lleve a cabo el aprendizaje en grupos pequeños. Explique a los usuarios, a medida que asistan, que su buzón será habilitado antes de activarse en el sistema y que se recomienda que éstos inicien sesión en su buzón y lo inicialicen cambiando su contraseña y grabando su saludo. Una vez que el aprendizaje finalice, habilite inmediatamente a estos usuarios para que puedan inicializar su buzón antes de la actualización.
Por último, cuando se haya llevado a cabo todo el aprendizaje, escoja un fin de semana para deshabilitar todos los usuarios del sistema anterior de correo de voz y reenvíe sus teléfonos a la Mensajería unificada de Exchange. El lunes por la mañana, su sistema estará activo para todos los usuarios de la organización.

Cómo realizar la actualización
Independientemente de si debe admitir un solo sitio o de si se trata de una organización grande de varios sitios, la información de este artículo debe serle muy útil. Las organizaciones de varios sitios pueden agregar complejidades al diseño, pero los requisitos básicos son los mismos tanto si tiene 50 como 5.000 usuarios.
Debo hacer hincapié en el hecho de que tanto los equipos de TI como de telecomunicaciones deben trabajar juntos al implementar una solución de Mensajería unificada. Según mi experiencia, entre las muchas cosas predecibles que pueden interrumpir un proyecto de Mensajería unificada están las disonancias entre TI y telecomunicaciones y la falta de acuerdo en la solución. La convergencia de tecnologías no es tan difícil, pero puede requerir a una persona de fuera de su organización que entienda tanto de TI como de telecomunicaciones para ayudar a reunir los equipos o planear una implementación de proyecto adecuada.

Jeff Goodwin es Tecnólogo jefe en The VIA Group, se ha especializado en el diseño e implementación de Exchange y Mensajería unificada. Puede ponerse en contacto con él a través de su dirección de correo electrónico: jgoodwin@theviagroup.com.


 Seguridad: Una gu&#237;a a la inform&#225;tica forense b&#225;sica
Seguridad Tom Cloward and Frank Simorjay

Una guía a la informática forense básica
Resumen:
  • Guía fundamental de investigación de equipos para Windows
  • Starter kit de eliminación de malware
  • Creación de un kit de investigación con Windows PE
  • Conservación de la información para el análisis forense

Existen innumerables maneras en las que usuarios malintencionados pueden usar un equipo para realizar actividades ilegales: piratería de sistemas, filtrado de secretos comerciales, liberación de nuevos virus, uso de mensajes de phishing para robar información personal y muchas más. Y continuamente recibimos noticias sobre ataques
y técnicas nuevos. Lo que no se oye tan a menudo es la manera en la que pueden usarse los equipos para investigar estos tipos de actividades.
Mientras algunas investigaciones dependen de profesionales altamente cualificados que usan herramientas costosas y técnicas complejas, hay métodos más fáciles y económicos que se pueden usar para realizar investigaciones y análisis básicos. En este artículo, nos centraremos en las técnicas de informática forense a las que puede tener acceso como administrador estándar.
Nuestra explicación se centra en dos aceleradores de soluciones que puede descargar de forma gratuita: "Guía fundamental de investigación informática para Windows" (go.microsoft.com/fwlink/?LinkId=80344) y Starter kit de eliminación de malware (go.microsoft.com/fwlink/?LinkId=93103). En este artículo, le mostraremos cómo puede combinar estas dos soluciones para crear un entorno arrancable de Windows® PE que le permitirá realizar una investigación efectiva y conservar sus conclusiones para la realización de informes y análisis. Tenga en cuenta que el método aquí descrito no se puede usar para investigar un disco duro cifrado o que forme parte de un volumen RAID. Además si el disco duro resulta dañado, necesitará realizar pasos adicionales por adelantado para restaurar su condición.
Aunque nuestra solución detalla una manera fácil de reunir pruebas en un equipo con Windows, tenga en cuenta que es un acercamiento básico ad hoc. Hay soluciones más sofisticadas disponibles comercialmente que pueden efectuar el trabajo resumido aquí de una manera mucho más efectiva.
Tenga presente también que la técnica que tratamos aquí no es una solución preceptiva garantizada ni certificada por "The International Society of Forensic Computer Examiners". Antes empezar una investigación, debe considerar si la evidencia hallada en el disco duro puede llegar a ser prueba en un proceso legal. Si existe esa posibilidad, se debería designar un examinador con certificación profesional para realizar la investigación. Dependiendo de la naturaleza del posible proceso legal, debe considerar también si debe ceder la investigación directamente a las autoridades competentes. Hay más información sobre este tema en la "Guía fundamental de investigación de equipos para Windows".

Acerca de los aceleradores de soluciones
La "Guía fundamental de investigación de equipos para Windows" trata de los procesos y herramientas que puede usar en una investigación interna de equipo. La guía resume las cuatro fases del modelo de investigación del equipo: valoración, obtención, análisis e informes. Se trata de un modelo sencillo que puede ayudar a profesionales de TI a realizar las investigaciones de una manera que conserve conclusiones importantes.
Esta guía cubre también cuando es necesario implicar a las autoridades competentes, debe tomar esta decisión junto con sus abogados. En ella puede encontrar información acerca de cómo administrar los delitos relacionados con el equipo, cómo ponerse en contacto con las autoridades competentes y las herramientas de Windows Sysinternals y otras herramientas de Windows que son útiles para realizar las investigaciones.
El otro acelerador de soluciones que mencionamos en este artículo, el Starter kit de eliminación de malware, ofrece orientación sobre cómo crear y usar el CD-ROM de arranque de Windows PE para quitar software malintencionado de un equipo. Esta guía incluye una lista de las amenazas y algunos de los factores atenuantes que pueden ayudar a reducir su posible impacto en una organización. Enfatiza también la importancia del desarrollo un plan de respuesta de incidente que puede seguirse en caso de que se sospeche un ataque de malware. El Starter kit de eliminación de malware incluye también un acercamiento de cuatro fases para ayudar a un profesional de TI a determinar la naturaleza del malware implicado, limitar su propagación, quitarlo si es posible, comprobar la eliminación y proceder con cualquier paso que pueda ser necesario.

El CD-ROM de Windows PE
Hay dos requisitos previos para ejecutar una investigación de este tipo: un CD-ROM de Windows PE y un dispositivo de almacenamiento externo, como una unidad flash de USB.
Probablemente ya haya visto la suficiente televisión como para saber que los agentes de policía deben dejar intacta la escena de un crimen. Por la misma razón, se deben conservar los datos en el disco duro investigado. A diferencia del disco del Starter kit de eliminación de malware, el disco arrancable de Windows PE que creamos sólo ejecutará herramientas que no alterarán en ningún modo los datos de disco duro.
El disco de Windows PE arrancará el sistema en un entorno limitado de Windows. Cuando se crea este CD de arranque, se pueden incluir herramientas (al igual que en el Starter kit de eliminación de malware) que se configuran de forma preliminar para un propósito especial. Tenga en cuenta que el equipo debe tener por lo menos 512 MB de RAM, ya que se trata de un requisito de Windows PE.
El proceso de creación del CD-ROM de Windows PE, detallado en el Starter kit de eliminación de malware, es bastante sencillo. Antes de crear este disco de arranque, necesitará instalar el Kit de instalación automatizada de Windows (AIK), el conjunto Sysinternals (disponible en microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx), coloque las herramientas de Sysinternals en su lista de herramientas, tal como se ha detallado en la Tarea 2 del Starter kit de eliminación de malware e instale cualquier otra herramienta de análisis de malware y utilidades. Para obtener instrucciones detalladas sobre la creación del disco, use los pasos enumerados en el documento del Starter kit de eliminación de malware.

La unidad externa USB
Ya que este proceso no alterará la unidad de disco investigada, necesitará también una unidad USB o alguna otra clase de disco duro externo en el que pueda almacenar los archivos de salida que se generen. (Una unidad USB es el medio recomendado ya que Windows PE puede montar dispositivos USB de manera automática). Puede que también desee usar un disco duro externo para almacenar una imagen del disco duro original. Con todos estos requisitos y opciones, es muy importante que haga una planeación de antemano para tener en cuenta el espacio en disco total que necesitará la investigación.
Puesto que desea asegurarse de que el kit esté limpio cuando inicie una investigación, se deben haber eliminado previamente todos los datos anteriores de la unidad de disco externa que se va a usar para guardar los archivos de investigación. Esto se puede realizar de manera fácil con una utilidad de limpieza de disco duro que sobrescribe toda la superficie de escritura de la unidad. A continuación se puede dar formato al disco externo y etiquetarlo como sea necesario para su uso en la investigación. Esta precaución garantiza que el dispositivo no contendrá los archivos que podrían contaminar las evidencias que se reúnan durante la investigación.
También debe incluir un formulario de cadena de custodia para que haya documentación oficial acerca de quién ha administrado el equipo durante la investigación. La "Guía fundamental de investigación de equipos para Windows" ofrece un ejemplo de formulario de cadena de custodia. Una vez haya terminado el empaquetado del kit (con el disco de arranque necesario de Windows PE, dispositivo de almacenamiento externo y un formulario de cadena de custodia) estará listo para comenzar.

Ejecución de una investigación
Ahora está listo para realizar una investigación. Primero, arranque el sistema sospechoso usando el disco de Windows PE, asegurándose de que el orden de arranque del equipo identifica la unidad de CD-ROM como el dispositivo principal de arranque. Cuando se le pregunte, presione cualquier tecla para completar el arranque desde el CD-ROM. Esto le proporcionará acceso a las herramientas que ha instalado en el disco.
Usaremos nuestro kit en un equipo de muestra para demostrar cómo puede recopilar información de un equipo (que llamaremos Testbox1). La asignación de la unidad de CD en Testbox1 es X:\ y la ubicación predeterminada para las herramientas del Starter kit de eliminación de malware es X:\tools. Para tener acceso a las herramientas del kit, simplemente hay que escribir: cd \tools.
Hay varias herramientas que pueden identificar las unidades de destino montadas en un equipo. Bginfo.exe, que está ubicado en el directorio de herramientas Sysinternals, puede ofrecer esta información y colocarla en una ventana en segundo plano en el escritorio para una fácil referencia. Drive Manager también puede identificar todas las unidades de disco en el equipo, incluidas las unidades de disco duro de destino y el dispositivo USB externo. La figura 1 muestra la información de disco para Testbox1. La unidad de arranque es X:\, el disco duro destino es C:\, y nuestra unidad USB externa es F:\.
Figura 1 Visualización de la información de disco con Drive Manager
Figura 1 Visualización de la información de disco con Drive Manager

Comprobación de malware
Es importante ejecutar herramientas antimalware antes de comenzar una investigación para asegurar que la investigación no esté afectada por un virus ni otro código malintencionado. El informe que genera la herramienta antimalware puede usarse como prueba, si fuera necesario. La no comprobación de la existencia de malware en un equipo puede arriesgar la investigación, así como la credibilidad del investigador en lo que se refiere a rigurosidad y certeza. Recomendamos que ejecute las herramientas antimalware proporcionadas en modo de sólo lectura o de informe.
El Starter kit de eliminación de malware habla de varias herramientas recomendadas, incluidas la herramienta de eliminación de malware y McAfee AVERT Stinger. Cuando ejecute la herramienta de eliminación de malware, asegúrese de incluir la opción de línea de comando /N para indicar a la herramienta que sólo informe de la presencia de malware y no intente quitarlo:
x:\tools\windows-KB890830-v1.29.exe /N
El archivo resultante del informe estará ubicado en %windir%\debug\mrt.log.
De igual forma, cuando ejecute McAfee AVERT Stinger, cambie la preferencia a Report only (Sólo informar), como se muestra en la figura 2, para que examine el equipo pero no realice cambios en el disco duro. Y asegúrese de guardar un informe de la herramienta cuando se haya completado el examen.
Figura 2 Use el modo Report only (Sólo informar) en McAfee AVERT Stinger
Figura 2 Use el modo Report only (Sólo informar) en McAfee AVERT Stinger

Cómo guardar los archivos importantes
Si no se ha realizado una copia de seguridad del disco duro completo antes de comenzar la investigación, debe realizar copias de seguridad de, al menos, los archivos clave de usuario. La información de configuración puede usarse para una futura revisión si fuera necesario. Comience reuniendo los archivos de registro y la configuración, que contienen toda la información relevante acerca de cómo se ha usado el equipo y qué software está instalado en el sistema.
Para guardar el subárbol de registro para Testbox1, creamos primero una carpeta en la unidad extraíble F:\ y, a continuación, registramos la fecha y la hora en la que comenzó la investigación usando los comandos siguientes:
f:
Mkdir f:\evidence_files
Date /t >> f:\evidence_files\Evidence_start.txt
Time /t >> f:\evidence_files\Evidence_start.txt
Ahora guardamos el subárbol de registro usando el comando xcopy para copiar el directorio de configuración completo y sus contenidos. Los archivos de registro que nos interesan están ubicados en %windows%\system32\config. En nuestro caso, ejecutaremos lo siguiente:
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
Este comando copia toda la información de configuración ubicada en la carpeta de configuración. Testbox1 contiene aproximadamente 95 MB de información en la carpeta de configuración.
A continuación, nos centramos en los datos de usuario, que pueden estar ubicados en cualquier parte del disco duro. Para nuestro ejemplo, estamos copiando datos solamente de un directorio llamado c:\HR. Para garantizar que los datos se recopilen completamente, copiaremos todos los datos en el directorio y sus subdirectorios usando el siguiente comando xcopy:
Mkdir f:\evidence_files\HR_Evidence
Mkdir f:\evidence_files\documents_and_settings
Mkdir f:\evidence_files\users
xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
Ahora puede centrarse en la información personal de carpetas. De nuevo, queremos copiar todos los datos de estos directorios y sus subdirectorios. Para esto, usamos los comandos siguientes:
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
Este ejemplo recopiló cerca de 500 MB de datos, que podemos analizar si fuera necesario. Como puede ver, la cantidad de datos que está recopilando puede ser enorme, especialmente si encuentra los archivos de audio, vídeo y fotos. No obstante, es importante conservar la mayor cantidad posible de datos originales ya que una investigación puede requerir no sólo las evidencias que se reúnen físicamente, pero también la certeza de que esta información no ha sido alterada durante el proceso de recolección. Lo ideal sería que hiciera una imagen de disco completo para la investigación, pero esto puede ser difícil debido a las restricciones de tamaño. Como puede ver, es muy importante calcular de antemano cuánto espacio de almacenamiento puede requerir su investigación.

Reunión de información adicional
Los archivos de sistema también pueden ser un elemento útil en la recolección de pruebas, pero reunir estos datos puede requerir alguna exploración del equipo de destino, ya que estos archivos no siempre pueden estar ubicados en el mismo lugar. No obstante, merece la pena buscar ciertos tipos de archivos porque pueden ofrecer una perspectiva útil. Los archivos de paginación, por ejemplo, contienen información acerca de a qué archivos se ha tenido acceso a través de la memoria. Además, los archivos de paginación pueden proporcionar la actividad de uso detallada. De manera similar, los datos del explorador web y las cookies ofrecen información acerca del comportamiento y las pautas de exploración.
El hallar estos datos puede requerir un esfuerzo de investigación, especialmente si un usuario ha cambiado su configuración para almacenar los datos en algún lugar distinto de las ubicaciones predeterminadas. Hay varias herramientas de Sysinternals que pueden ayudarle a encontrar archivos importantes. La figura 3 ofrece una lista de cinco aplicaciones útiles y describe cómo pueden ayudarle en su investigación.
Figure 3 Herramientas para localizar archivos y datos de interés (Close Figure 3)

Aplicación | Descripción
AccessChk | Muestra las rutas de acceso a los archivos, claves de registro y servicios de Windows por usuario o grupo que especifique.
AccessEnum | Muestra quién tiene acceso a qué directorios, archivos y claves de registro de un equipo. Puede usar esto para encontrar los lugares donde los permisos no se aplican apropiadamente.
Du | Muestra el uso de disco por directorio.
PsInfo | Muestra información acerca de un equipo.
Strings | Busca cadenas ANSI y UNICODE en imágenes binarias.

Tom Cloward, CCE, CISSP, es Director de programas en Microsoft, su principal objetivo es proporcionar aceleradores de soluciones de seguridad y cumplimiento para profesionales de TI. Ha trabajado en el sector de TI y software durante más de 15 años y es un apasionado de la seguridad de TI, la informática forense y el cumplimiento. Frank Simorjay, CISSP, CET, es Director técnico de programas y experto en asuntos de seguridad para el grupo de seguridad y cumplimiento de Microsoft Solution Accelerator. Diseña soluciones de seguridad para clientes de Microsoft. Uno de sus trabajos más recientes es el Starter kit de eliminación de malware, disponible en Microsoft TechNet.
Frank Simorjay, CISSP, CET, es Director técnico de programas y experto en asuntos de seguridad para el grupo de seguridad y cumplimiento de Microsoft Solution Accelerator. Diseña soluciones de seguridad para clientes de Microsoft. Uno de sus trabajos más recientes es el Starter kit de eliminación de malware, disponible en Microsoft TechNet.


 Redes: Informe de inteligencia en seguridad de Microsoft
Redes Tim Rains

Informe de inteligencia en seguridad de Microsoft
Resumen:
  • Tendencias en divulgaciones de vulnerabilidad de software y malware
  • Repercusión de las amenazas para diferentes versiones de Windows
  • Áreas más y menos infectadas del mundo

Los datos procedentes de cientos de millones de sistemas conectados a Internet y algunos de los servicios en línea más usados del mundo ofrecen a Microsoft una visión única de las amenazas de seguridad a las que se enfrentan los usuarios de Internet en la actualidad.
Microsoft comparte estos datos dos veces al año en su Informe de inteligencia en seguridad (SIR). Entre los colaboradores del informe se encuentran Microsoft® Malware Protection Center (MMPC), Microsoft Security Response Center (MSRC), Trustworthy Computing (TwC) Group y muchos otros grupos de productos. El SIR ofrece una visión detallada de las tendencias recientes en divulgaciones de vulnerabilidad de software, software malintencionado y software potencialmente no deseado, como el software espía y el adware. El informe incluye también detalles de cómo han respondido varias versiones del sistema operativo Windows en el marco del panorama de amenazas y qué regiones del mundo son las más infectadas con malware y otro software intrusivo. La última versión del informe, que se centra en las tendencias observadas en la primera mitad de 2007, incluye una sección nueva acerca de los puntos de vulnerabilidad del software. Si la seguridad de los equipos es su responsabilidad o el tema le interesa, el SIR será una lectura valiosa, puesto que se ha concebido para ayudar a informar acerca de las amenazas relacionadas con Internet.
El último SIR revela que los investigadores en materia de seguridad encuentran más vulnerabilidades en el software de todos los proveedores. De hecho, se han divulgado más de 3.400 vulnerabilidades de software nuevas tan sólo en la primera mitad de 2007. A pesar de este número considerable, el porcentaje general de vulnerabilidades de sistemas operativos divulgadas disminuye.
¿Qué significa esto? Una posibilidad es que los investigadores en materia de seguridad se centran más en las aplicaciones porque la seguridad de los sistemas operativos ha ido mejorando. Además, puesto que el número de aplicaciones nuevas supera con creces el número de sistemas operativos nuevos, es probable que la proliferación de aplicaciones sea una fuerza impulsora de estas tendencias recientes de divulgación de vulnerabilidades.
Durante 2006, el 29,3 por ciento de las vulnerabilidades conocidas de productos de Microsoft tenía código que aprovechaba vulnerabilidades disponible públicamente, mientras que a 1 de agosto de 2007, sólo el 20,9 por ciento de vulnerabilidades conocidas tenía el código disponible públicamente. Aunque el número de vulnerabilidades continúa aumentando, la proporción del código que aprovecha las vulnerabilidades permanece estable e incluso muestra un leve descenso. El código que aprovecha las vulnerabilidades de los productos recientes es más difícil de localizar. Hemos realizado una comparación producto por producto que sugiere que las versiones más nuevas de los productos tienen menos riesgo que las versiones de producto que llevan más tiempo en el mercado. De media, la capacidad de aprovechamiento disminuye a lo largo de la vigencia del producto, lo que significa que para la mayoría de los productos las versiones posteriores son menos aprovechables en este sentido. Esto es muy evidente en el caso de Windows y de los productos de Microsoft Office System. Las versiones más recientes de ambos (Windows Server® 2003, Windows Vista®, Office 2003 y 2007 Office System) muestran una clara reducción del número de vulnerabilidades a lo largo de la vigencia del producto.
El SIR ofrece valiosas perspectivas de las tendencias del software malintencionado (conocido como malware). Estas tendencias son una indicación de las tácticas que se usan actualmente para atacar a los usuarios. Si se observan los datos de algunos orígenes significativos, como Microsoft Exchange Hosted Services (EHS), Windows Live® OneCare y Windows Live OneCare Safety Scanner, Windows Malicious Software Removal Tool (MSRT) y Windows Defender, se obtiene una visión del panorama de amenazas desde posiciones estratégicas diferentes.
La ingeniería social desempeña un papel cada vez más importante en la distribución de malware. Los ataques de estas características suelen ser efectivos al engañar a los usuarios para que emprendan acciones que pueden disminuir la eficacia de los mecanismos de seguridad. Los datos de EHS indican que durante la primera mitad de 2006, la mayor amenaza derivada del correo electrónico estaba compuesta por los gusanos clásicos de correo electrónico, que representaron el 95 por ciento del malware detectado en el correo electrónico. A partir de la segunda mitad de 2006, esta cifra bajó al 49 por ciento y permaneció estable en toda la primera mitad de 2007 (consulte la figura 1). Las operaciones de suplantación de identidad (phishing) y el correo electrónico con ataques IFrame malintencionados representaron el 27 por ciento del malware detectado durante la segunda mitad de 2006 y ascendieron al 37 por ciento durante la primera mitad de 2007. Los troyanos de descarga incluidos en el correo electrónico llegaron a la cifra máxima del 20 por ciento durante la segunda mitad de 2006, pero bajaron hasta el 7 por ciento en la primera mitad de 2007.
Figura 1 Composición del correo electrónico infectado en la primera mitad de 2007
Figura 1 Composición del correo electrónico infectado en la primera mitad de 2007
Los datos de telemetría recopilados de Windows Live OneCare y Windows Live OneCare Safety Scanner (safety.live.com) indican que las tasas de infección de virus, puertas traseras, programas de interceptación de contraseñas y troyanos de robo de datos aumentaron en la primera mitad de 2007.
La herramienta MSRT se ha diseñado para ayudar a identificar y eliminar la presencia de software malintencionado frecuente en los equipos de cliente. Se lanza principalmente como actualización crítica por medio de Windows Update (WU), Microsoft Update (MU) y Actualizaciones automáticas (AU). Durante los dos últimos años, la herramienta MSRT ha eliminado 50,3 millones de infecciones de 20,5 millones de equipos en todo el mundo. El número total de ejecuciones de MSRT hasta la fecha se sitúa en más de 7.400 millones; ello incluye 1.900 millones de ejecuciones en la primera mitad de 2007.
La herramienta MSRT es una fuente de información fantástica para Microsoft y sus clientes. Las tasas de infección observadas por MSRT son apreciablemente más bajas en los sistemas Windows Vista y Windows XP SP2 que en los sistemas operativos anteriores de Windows, como muestra la figura 2. La herramienta MSRT ha limpiado malware de un 60 por ciento menos de equipos que ejecutan Windows Vista que de equipos que ejecutan Windows XP SP2, y un 91,5 por ciento menos de equipos que ejecutan Windows XP sin ningún Service Pack instalado. Resulta interesante que el número de desinfecciones por equipo ha permanecido constante con el paso del tiempo, con un promedio de 2,2 desinfecciones por equipo infectado.
Figura 2 Versiones del sistema operativo limpiadas por MSRT en la primera mitad de 2007
Figura 2 Versiones del sistema operativo limpiadas por MSRT en la primera mitad de 2007
Por regla general, la herramienta MSRT encuentra proporcionalmente más malware en países en vías de desarrollo que en países desarrollados. Por ejemplo, los países más infectados en Europa son Albania y Turquía, mientras que los menos infectados son Italia y Finlandia. En la región Asia-Pacífico, los más infectados son Mongolia y Tailandia y los menos, Nueva Zelanda y Japón. En proporción, Estados Unidos está menos infectado que la mayoría de los países y regiones del continente americano, con una tasa de infección que se sitúa alrededor de la media mundial. De promedio, la herramienta MSRT limpió 1 de cada 216 equipos durante la primera mitad de 2007.
Windows Defender se ejecuta en Windows Vista, Windows XP y Windows Server 2003. Globalmente, se detectaron 50,7 millones de unidades de software potencialmente no deseado durante la primera mitad de 2007, con 2,8 veces menos unidades detectadas en equipos que ejecutaban Windows Vista que en los que ejecutaban Windows XP SP2. De forma similar, el número de detecciones de software potencialmente no deseado en equipos que ejecutan Windows Vista fue la mitad que el encontrado en equipos que ejecutan Windows Server 2003.
Y usted puede estar preguntándose ahora mismo: aparte de lo interesantes que puedan resultar las estadísticas en sí mismas, ¿cómo ayudan a protegerse mejor? En el último SIR, cada sección principal tiene un prólogo en el que hay un resumen de los puntos destacados de esa sección y un conjunto de "estrategias, mitigaciones y contramedidas". Puede usar estas listas para obtener rápidamente más información acerca de las conclusiones clave de cada sección del informe.
Además, puede usar los datos, las perspectivas y la orientación que ofrece el SIR para evaluar y mejorar su postura actual en materia de seguridad dado el panorama de las amenazas en continuo cambio. El informe completo, que ofrece estrategias, mitigaciones y contramedidas basadas en las conclusiones clave, puede descargarse en microsoft.com/sir.

Tim Rains es director de productos en el Microsoft Malware Protection Center (MMPC). Administra la producción del informe de inteligencia en seguridad de Microsoft (SIR). Los autores del SIR son Jeff Jones (director, Microsoft Trustworthy Computing Group), Jeff William (director del MMPC), Mike Reavey (responsable de grupos, Microsoft Security Response Center), y Ziv Mador (administrador jefe de programas y coordinador de respuestas, MMPC).


 Redes: Localizar problemas de red esquivos
Redes Christopher Stoneff

Localizar problemas de red esquivos
Resumen:
  • Las causas más frecuentes de problemas de red
  • Ver más allá de lo obvio
  • Cuando las herramientas de solución de problemas no ayudan
  • Por qué es necesario configurar los límites de la conexión

Probablemente ha visto como sucede en muchas ocasiones, su equipo no puede comunicarse con otros equipos y no sabe por qué. Su sistema de administración está situado en un segmento de red conectada a otros segmentos de red por medio de un enrutador, como Microsoft Internet
Security and Acceleration (ISA) Server u otro dispositivo de hardware. Cuando intenta administrar 10, 20, ó incluso 100 sistemas, no encuentra ningún problema. Pero cuando intenta administrar 500 sistemas, su equipo no puede comunicarse en la red excepto con los equipos con los que ya tiene conexiones abiertas. No puede comunicarse con ningún otro sistema, ni puede obtener acceso a Internet, pero además nadie de la red, incluso los de su propio segmento, está experimentando este fenómeno. ¿Dónde buscar en primer lugar?

Diagnóstico del problema
La suposición más común en esta situación es que el software de administración tiene errores. Muchas herramientas de administración proactivas conectan y administran sus sistemas, pero a veces estas mismas herramientas pueden causar el problema que tratan de localizar. Eso es porque una herramienta de administración proactiva puede generar miles de conexiones a sus dispositivos buscando una mejor administración. Windows® mantendrá estas conexiones abiertas durante dos minutos de forma predeterminada aún cuando las conexiones estén inactivas, a menos que la herramienta, la aplicación o el servicio las mantenga conectadas durante más tiempo. Esto significa que aunque su sistema de administración no haya hablado con ningún equipo en dos minutos, todavía puede tener más de 1.000 conexiones abiertas. (Puede ver las conexiones abiertas ejecutando NETSTAT en un símbolo del sistema. El comando NETSTAT le mostrará todas las conexiones abiertas, pendientes y que se estén cerrando en su sistema y le dará su estado. Las descripciones de los mensajes de estado se pueden consultar en RFC 793 en tools.ietf.org/html/rfc793.)
Para excluir los errores del software de administración, puede crear un archivo por lotes que establezca conexiones con los sistemas remotos. Si se produce el mismo problema al ejecutar el archivo por lotes, sabrá que el software de administración y sus subprocesos no tienen la culpa. Aquí tenemos un ejemplo de los contenidos del archivo por lotes requerido:
Net use \\system01\ipc$
Net use \\system02\ipc$
Net use ...
Si el programa de administración en cuestión hubiera conseguido implementar su propia pila de red y autenticación, podría haber sido el culpable, pero en soluciones sin agente, como la mayor parte de estos paquetes de administración, la herramienta usa la pila de red y autenticación del sistema operativo para realizar operaciones de red. El uso de un archivo por lotes que inicie tantas conexiones de red sin causar errores demostrará que el problema no proviene del uso de las pilas de autenticación y red del sistema operativo por parte del programa, ya que el archivo por lotes las usa también.

Registros y mensajes de error que no ayudan
Puede que haya advertido que a medida que las conexiones comienzan a tener errores, recibe información incorrecta del error: error 53: no se encuentra la ruta de acceso de red, error 64: se ha eliminado el nombre de la red y error 1203: ningún proveedor de red aceptó la ruta de acceso proporcionada. Normalmente, todo esto indicaría problemas de resolución de nombres, pero los demás equipos no tienen ningún problema resolviendo los nombres y conectándose a los mismos sistemas. Para comprobar que su configuración de equipo no esté equivocada, simplemente ejecute ipconfig para confirmar que la configuración es correcta.
A continuación, ya que el fenómeno parece estar localizado en su sistema de administración, debería mirar los registros de eventos. La búsqueda de los registros de aplicaciones no da resultados, aunque en el registro de sistema encuentra un evento de advertencia 4226 de origen de evento TCP/IP que indica que se había alcanzado el número máximo de conexiones (consulte la figura 1).
Figura 1 Se ha alcanzado el límite de la conexión TCP
Figura 1 Se ha alcanzado el límite de la conexión TCP
Si realizamos una búsqueda exhaustiva de "límites de conexión" en Microsoft® Knowledge Base, ésta revelará el hecho de que hay límites de conexión impuestos a las conexiones incompletas, pero no hay límites en las conexiones completadas. Puede ajustar las siguientes entradas del registro en HKLM\System\CurrentControlSet\Services\TCPIP para controlar los factores mencionados: TcpNumConnections se usa para establecer el número máximo de conexiones que TCP puede tener abiertas al mismo tiempo (el valor predeterminado es 10). TCPTimedWaitDelay establece el tiempo que una conexión permanece en la condición TIME_WAIT cuando se está cerrando. La mitad de vida predeterminada es 120 segundos, lo cual significa que una conexión está esencialmente en uso durante 4 minutos. Por último, MaxFreeTcbs cumple también una función en el número máximo de conexiones. Si todos los bloques de control de TCP están en uso, TCP debería iniciar conexiones que aparecen en la lista con el estado TIME_WAIT para crear más conexiones, aunque TCPTimedWaitDelay no haya expirado todavía. TCPTimedWaitDelay tiene un valor dentro del intervalo 30-300 segundos (0x1E – 0x12C).
Dependiendo de su situación, podrá ver una ligera mejoría en el rendimiento global realizando estos cambios en el registro. Otro paso que puede intentar es aplicar un parche al archivo TCPIP.sys para quitar estos límites, pero esto sólo ofrece mejoras en aplicaciones P2P.

Capturas de red
Tras otros intentos infructuosos por resolver los problemas de conexión, realizar una captura de red de los equipos implicados parece una buena idea. Al ejecutar Microsoft Network Monitor (Netmon), se produjeron capturas que mostraron los resultados exactos que se veían en las herramientas de administración y los scripts de prueba: todo funciona correctamente y después ya no, sin que haya más indicación de error.
La figura 2 muestra el resultado de ejecutar Netmon, que indicó comunicación correcta entre los primeros n sistemas. Tenga en cuenta que obtengo los reconocimientos de solicitudes RPC. Esto es lo que se desea ver, una comunicación bidireccional correcta.
Figura 2 Comunicación correcta en Netmon
Figura 2 Comunicación correcta en Netmon
Ahora necesita ver las capturas del sistema de administración y los equipos remotos que parecen mostrar el error 53/1203. Como cabría esperar, no hay nada que ver, ya que los equipos no se comunican. En la captura de red en la figura 3, el sistema de administración ha resuelto la dirección IP e intenta conectarse al sistema a través del puerto 445 (el puerto Microsoft SMB) pero nunca recibe una respuesta.
Figura 3 Los intentos para conectar al sistema a través del puerto 445 no dan respuesta
Figura 3 Los intentos para conectar al sistema a través del puerto 445 no dan respuesta
El error que recibe cuando tiene más subprocesos de los que su equipo puede conectar realmente no es siempre coherente. A veces puede ver en el sistema origen un error 53, que indica que ha recibido la resolución de nombre pero que no se ha podido encontrar la dirección IP. Esto indica que el DNS proporciona una dirección a la que no puede conectarse. Puede que reciba un error 1203, que indica que ningún equipo ha respondido al nombre ni la dirección IP que ha solicitado. El error 1203, en este caso, indica que ese DNS no está disponible. Verá que ese es el caso si ejecuta nslookup.
En este punto se debe sentir casi frustrado, pero hay más opciones a tener en cuenta. La mayoría de las personas ni tan siquiera pensarán en echar un vistazo a la infraestructura de conexión por la manera en la que se presenta este problema: su equipo es el único que no puede conectarse al resto de la red y los registros de eventos muestran que su equipo ha alcanzado el número máximo de conexiones permitidas, así que el problema no parece tener su origen en la arquitectura.
Aunque las miles de conexiones generadas por su solución de administración no se iniciarán al mismo tiempo, los mantenimientos y los tiempos muertos de conexión pueden significar que tiene más conexiones abiertas de las que cree. Por lo tanto, debe examinar también esos sistemas que se conectan al resto de su red.
Déjeme explicarlo. Como he mencionado anteriormente, cuando el tráfico de red pasa a través de la red, atraviesa conmutadores, enrutadores y quizás firewalls. En cualquiera de estos puntos, generalmente en el enrutador o en el firewall, pueden haber sistemas de detección de intrusos. Los conmutadores y enrutadores administrados pueden emplear también el filtrado de tráfico. Usted, o quien tenga el control de estos dispositivos, necesitará comprobar los registros en busca de errores o advertencias. El problema de comunicación puede estar dentro de estos sistemas.
Como está conectando desde un sistema interno a otros sistemas internos, puede ver que no se están generando alertas, porque las alertas no están configuradas en el dispositivo o porque el problema no está calificado como intrusión o ataque de denegación de servicio (DoS). Una vez más, debe empezar con los registros. Si usamos el servidor ISA como ejemplo, estos registros se pueden encontrar en la consola de Administración del Servidor ISA en Matrices\<NombreMatriz>\Supervisión\Registro.
Si hay una directiva que lo está bloqueando, puede (en el caso de Servidor ISA) buscar los siguientes códigos de resultado donde la IP de origen es su equipo de administración:
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
Si encuentra estos resultados, ha identificado la raíz de sus problemas de conectividad.

Implementación de la solución
Ahora que ha identificado el problema, la solución puede ser sencilla, pero las directivas del departamento pueden hacer que sea difícil implementarla. Antes de hacer ningún cambio, asegúrese de que tiene los permisos apropiados para realizarlos, ya que no siempre se permite crear exclusiones en las configuraciones de seguridad de los firewalls, enrutadores y/o los sistemas de detección de intrusos.
De nuevo, usando el servidor ISA como ejemplo, los pasos siguientes muestran cómo aumentar el número máximo de conexiones para un host dado o para todos los equipos en la red (como se muestra en la figura 4). Abra la consola de administración del servidor ISA y navegue hasta Matrices\<NombreMatriz>\Configuración\General\Configurar mitigación de ataques ''flood'' de congestión del servidor.
Figura 4 Aumente el número máximo de conexiones para un host o todos los equipos que usan el servidor ISA
Figura 4 Aumente el número máximo de conexiones para un host o todos los equipos que usan el servidor ISA
La dos configuraciones de interés son el máximo de conexiones TCP simultáneas por dirección IP y el máximo de solicitudes de conexión TCP por minuto por dirección IP. Las conexiones TCP simultáneas máximas por dirección IP se establecen normalmente en un valor que sería suficiente cuando no se produjera la administración activa, lo cual implica que ningún equipo se conecta activamente a miles de equipos rápidamente. En el servidor ISA, el límite predeterminado para el máximo de conexiones TCP simultáneas es 160. El máximo de solicitudes de conexión TCP por minuto por dirección IP está diseñado para limitar el daño y la visibilidad de las exploraciones de red. El límite predeterminado es 600 solicitudes de conexión por minuto por IP.
Como se ha indicado anteriormente, Windows mantendrá una conexión activa por un período predeterminado de dos minutos siempre que sólo intente mantener activa la conexión, incluso si la conexión no está en uso. Esto significa que aunque ya haya administrado correctamente un equipo y no necesite comunicarse más con el mismo, la conexión se mantendrá activa. Esta conexión abierta cuenta en el total de conexiones asignadas. Repita este proceso más de 160 veces sin eliminar conexiones y encontrará que todos los intentos de conexión le son denegados por el enrutador. Incluso si su programa de administración elimina activamente una sesión, Windows puede dejar la conexión en un estado time_wait que espera al equipo objetivo para desconectar la sesión.
Comience a realizar ajustes en el culpable más probable: el máximo de conexiones TCP simultáneas por dirección IP. Debe establecer esto para que su equipo de administración pueda crear todas las conexiones que necesita para administrar sus sistemas sin que se le deniegue el acceso. Haga clic en el botón Editar junto a la configuración y cambie los valores.
El mensaje siguiente (consulte la figura 5) tiene un cuadro Límite que representa el límite predeterminado, aplicable a todos clientes. El límite personalizado se aplica a todos los equipos, redes, etcétera que se definen en la ficha de Excepciones IP del cuadro de diálogo de mitigación de ataques ''flood''. Si desea permitir a cada equipo crear más conexiones, cambie el valor del Límite. Para configurar la excepción sólo para su equipo de administración, ajuste el límite personalizado y agregue su equipo a la ficha Excepciones IP. Normalmente es mejor permitir la excepción sólo para su propio equipo.
Figura 5 Límite predeterminado de conexión y límite personalizado de conexión
Figura 5 Límite predeterminado de conexión y límite personalizado de conexión
Si desea usar el límite personalizado para modificar este valor sólo para sistemas específicos, cambie el valor en el campo Límite Personalizado y haga clic en Aceptar. Después agregue su equipo a la ficha Excepciones IP en el cuadro de diálogo de mitigación de ataques ''flood''. Para agregar solamente su equipo a la lista de excepciones, en las Excepciones IP haga clic en Agregar para hacer aparecer el cuadro de diálogo Conjuntos de equipos. Haga clic en Nuevo para crear un nuevo conjunto de red para contener su sistema o sistemas, si no existe un conjunto de red que contenga estos equipos. Seleccione este conjunto de red y haga clic en Agregar para agregar el conjunto de red de Redes Internas y haga clic en Cerrar. Seleccione el conjunto de red Redes internas de nuevo y haga clic en Editar. Esto abrirá las propiedades de Redes internas (consulte la figura 6). Haga clic en Agregar en este cuadro de diálogo para mostrar un submenú en el que puede elegir agregar un equipo, intervalo de direcciones o subred; elija el equipo. Escriba un nombre que identifique la entrada, la dirección IP del equipo y una descripción para que cualquiera que vea la entrada no se vea tentado a quitar su sistema (consulte la figura 7). Haga clic en Aceptar para agregar su sistema y haga clic de nuevo para agregar la excepción. Ahora que ha realizado estos cambios, debe aplicar la configuración.
Figura 6 Configuración de propiedades de redes internas
Figura 6 Configuración de propiedades de redes internas
Figura 7 Escriba el nombre de equipo, la dirección IP y la descripción para asegurar que su sistema no sea eliminado
Figura 7 Escriba el nombre de equipo, la dirección IP y la descripción para asegurar que su sistema no sea eliminado
Pruebe su herramienta de administración proactiva otra vez y debería comprobar que el rendimiento es mucho mejor y la conexión no tiene errores, al menos no como resultado del tráfico de red. Al final, resulta que el problema no era el número de conexiones iniciadas por el software, era la falta de planeación correcta para esas conexiones la que causaba la interrupción.

Lecciones aprendidas
Uno de los mayores quebraderos de cabeza en TI es experimentar y resolver los problemas realmente esquivos. Son problemas que el usuario final no ha creado, el equipo del servidor tampoco los ha causado, el servicio de soporte técnico no los conoce y, desgraciadamente, puede ser responsabilidad suya arreglarlos. Hay infinidad de herramientas disponibles para ayudarle a identificar, aislar y solucionar problemas, pero a veces las herramientas no son suficientes. A veces las herramientas se equivocan. Y a veces necesita ser más listo que las propias herramientas.
La próxima vez que no pueda establecer conexiones entre un número de equipos en la red sin razón obvia, pruebe los pasos que he descrito aquí. Hay una gran probabilidad de que siguiendo estos pasos, observando su software de administración más detenidamente y configurando las conexiones permitidas correctamente, pueda resolver el problema correctamente.

Christopher Stoneff es administrador de producto en Lieberman Software (liebsoft.com), un desarrollador de software de seguridad y administración de sistemas. Chris posee más certificaciones técnicas de las que debería tener una persona en su sano juicio. Su mayor virtud no es sólo saber cómo funciona algo de una cierta manera, sino también saber por qué.


 Nota del editor: Comencemos ya la conversaci&#243;n
Nota del editor
Comencemos ya la conversación
Joshua Hoffman

A lo largo de los tiempos, casi todos los hechos importantes que han tenido lugar tienen como punto de partida una conversación.
"No creo que la tierra sea realmente plana. Por lo tanto, deberíamos comprobarlo, ¿verdad?"
"¿Por qué no enviamos a una persona a la luna?"
"¿Podría comentarle una idea que tengo para estos equipos nuevos?"
"Quedemos para un café".
(Esta última frase no refleja en verdad un evento importante... Simplemente me gusta el café. De todos modos es muy posible que tras tomar un café surja una estupenda idea).
En todo caso, la noción según la cual todos los eventos importantes comienzan generalmente con una conversación es cierta para mí este mes en dos aspectos. El primero se refiere a una conversación real que tiene lugar en estos momentos, en blogs, en oficinas e incluso en este número de TechNet Magazine (consulte la columna Notas de campo de Romi Mahajan en la página 91). Se trata de la aproximación al consumidor de las TI. Este nuevo concepto se basa en la noción de que no somos simplemente profesionales de TI en nuestro trabajo. La realidad es que lo que hacemos diariamente en nuestras vidas (voluntariado social, cantar en un karaoke, jugar con la Xbox, sea lo que sea) tiene una repercusión en el trabajo que llevamos a cabo y en las decisiones que tomamos en nuestra vida profesional. Es una conversación que Romi y yo, junto con otros invitados especiales, continuaremos en una mesa redonda que tendrá por título "The Fungible Future" ("El futuro fungible") en la próxima conferencia Windows Connections en Las Vegas. Espero que se nos una en persona o que, al menos, consulte el sitio web en WeWantToKnow.net. Y, por supuesto, no dude en participar en la conversación en nuestro blog en blogs.technet.com/tnmag, deseamos que agregue sus comentarios.
El segundo aspecto que deseo tratar es la tecnología que usamos para habilitar estas conversaciones. En el número de este mes de TechNet Magazine, examinamos las principales mejoras integradas en Exchange Server, mejoras que le permiten permanecer conectado, tanto si se encuentra en su oficina como si está recorriendo mundo. Le mostraremos las mejoras que Exchange Server 2007 SP1 pone a su disposición, cómo la Replicación continua en espera puede reforzar en gran medida sus planes de recuperación de desastres, las mejoras que presentará la plataforma Exchange gracias a Windows Server 2008 y cómo la Mensajería unificada hace más eficaces incluso sus conversaciones. Como promoción especial este mes, la edición impresa de TechNet Magazine incluye el último de una serie de pósters muy populares de los redactores colaboradores Astrid McClean y Martin McClean. Puede que ya haya visto el póster rompecabezas del componente de Active Directory o los pósters de Windows Server 2008 que han aparecido aquí anteriormente. Este mes, se encargan de Exchange. Comencemos ya la conversación (Joshua Hoffman)

Mi agradecimiento a los siguientes expertos de Microsoft: Ed Banti, Anah Cameron, Chun Yong Chua, Cliff Didcock, Jeremy Kelly, Michael Murgolo, Jon Orton, Jeff Ressler, Kevin Sullivan, Jim Truher, Scot Vidican y Michael Wilson.


 Cartas: Comentarios de los lectores
Cartas
Comentarios de los lectores

Utilidad PageDefrag
Intenté ejecutar la utilidad PageDefrag de SysInternals que se trató en el número de septiembre de 2007. Sin embargo, se mostró el siguiente error con Windows Vista® x64 "Asegúrese de que es un administrador. Error al cargar el controlador de PageDefrag".
Alex D.

En este momento, la utilidad PageDefrag no es compatible con Windows Vista. Funciona únicamente con Windows NT® 4.0, Windows® 2000, Windows XP y Windows Server® 2003. Sentimos no haberlo aclarado de manera adecuada en el artículo de septiembre.

Programador de copia de seguridad
Leí el artículo "Una guía de las tecnologías de copia de seguridad de Windows Vista" en el número de septiembre de 2007 con gran interés, pero tengo algunas preguntas.La figura 2 del artículo muestra la fecha y la hora de la próxima copia de seguridad. ¿Cómo es esto posible si la herramienta de copia de seguridad no dispone de su propio programador?
Puesto que los cambios en los bloques de discos son fundamentales para determinar aquello de lo que se va a realizar copia de seguridad, ¿qué ocurre si ya se ha realizado la desfragmentación del disco? ¿Es posible obtener como resultado una gran cantidad de datos a los que realizar copia de seguridad debido a que los bloques hayan sido movidos o cambiados? Asimismo, durante una restauración, si los bloques se restauran a su ubicación original, ¿cómo se ve esto afectado por una desfragmentación de disco?
Bruce G.

Acudimos al origen (la autora del artículo Christine Fok) y, a continuación, le exponemos sus comentarios:
La figura 2 muestra la fecha y la hora a la que se llevará a cabo la próxima copia de seguridad de archivos y carpetas, pero sólo la hora de la Copia de seguridad de Complete PC más reciente. Es posible programar una copia de seguridad de nivel de archivos o carpeta, pero, tal como comentó, la Copia de seguridad de Complete PC no dispone de su propio programador.
Tiene razón al exponer que la ejecución de Defrag entre dos copias de seguridad de Complete PC puede ampliar en mayor medida la segunda. Su cuestión referente a la restauración tras la desfragmentación es también correcta. Complete PC funciona en el nivel del volumen, por debajo del sistema de archivos. Vuelve a colocar cada bloque exactamente del mismo modo que estaba en el momento de la copia de seguridad, en las mismas ubicaciones en el disco, sin tener en cuenta si Defrag se ha ejecutado desde que se implementó la copia de seguridad. Por lo tanto, es posible que necesite desfragmentar el volumen de nuevo una vez que la restauración se haya llevado a cabo.

Herramienta BGInfo
Me encantó leer la columna Utility Spotlight en el número de agosto de 2007. La herramienta BGInfo de SysInternals que reúne información crucial de la CPU y de red me pareció excepcional. Disfruto leyendo artículos acerca de personas que desarrollan un nuevo producto, utilidad, programa o aplicación. ¿Ha desarrollado el Sr. Cogswell otros productos de software para Microsoft?
Daryl B.

Nos alegramos de saber que encontró útil la utilidad BGInfo. Bryce Cogswell ha creado varias utilidades muy manejables, generalmente en colaboración con Mark Russinovich como parte de Sysinternals. Afortunadamente, Microsoft adquirió Sysinternals en 2006 y tanto el Sr. Cogswell como el Dr. Russinovich ahora trabajan aquí. Puede encontrar todas sus utilidades en el sitio web de Sysinternals en microsoft.com/technet/sysinternals.

RPC y firewalls
El artículo "Solución de los errores de RPC" del número de julio de 2007 me pareció bastante útil pero se olvidó un punto clave: el Firewall de Windows puede provocar también errores de RPC. Si el Firewall de Windows se configura para permitir solicitudes PING pero no mensajes de entrada no solicitados, todos los intentos por administrar un equipo de manera remota producirán errores. Si ejecuta RPCPING.exe desde el kit de recursos de Windows, el error devuelto es 1722 (el servidor RPC no está disponible).
En este caso, el firewall hace exactamente lo que se supone que debe hacer: detener el acceso de intrusos a un sistema determinado. Desafortunadamente, también dará lugar a ataques que afectarán a los administradores a medida que intenten administrar equipos en una red empresarial.
Aaron M.

Gracias por señalar otra fuente potencial de dificultades en RPC. Esperamos que las herramientas mencionadas en el artículo puedan ayudarle a solucionar estos problemas.

Licencias de Windows XP
La columna Notas de campo de octubre de 2007 mencionaba la posibilidad de comprar licencias para Windows XP por sólo 5 dólares estadounidenses. Somos una editorial sin ánimo de lucro, me pregunto cómo podemos obtener estas licencias. ¿Hay alguna manera de hacerlo a través del teléfono o correo electrónico? Tengo correo electrónico, pero no tengo acceso a la Web.
Ernest B.

Puede ponerse en contacto con el socio administrativo de MAR, TechSoup, en communitymar@techsoup.org o llamando al 800-659-3579 x350. También puede escribir a: Administrador de Community MAR, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107.


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

Supervisión de sistemas de red
Monitor de red ActiveXperts
activexperts.com
Cuando se es administrador de sistemas, es mejor saber que algo falla antes de que los usuarios empiecen a salir de sus cubículos como una manada de perros de las praderas asustados. La supervisión de servicios es una herramienta clave para administrar de forma proactiva la infraestructura. El monitor de red ActiveXperts es una solución robusta que incluye una serie de comprobaciones diferentes que pueden abarcar su LAN/WAN y los servidores Windows®, Novell y *NIX para garantizar que conozca los problemas antes de que los usuarios se lo notifiquen.
El monitor de red ActiveXperts es una aplicación basada en Windows que se ejecuta como servicio en el equipo que se ha designado como estación de supervisión. El sistema operativo de base en este equipo puede ser Windows 2000, Windows Server® 2003, Windows XP o Windows Vista®. Después de la instalación, un asistente rápido para la configuración le guía a través de la configuración de las notificaciones por correo electrónico, de las notificaciones por SMS y de la frecuencia de examen o umbral de error predeterminados. También puede agregar un conjunto de comprobaciones de muestra que puede usar como ejemplos en la configuración. Resulta muy útil para ponerse en marcha y muestra los aspectos fundamentales para configurar las diferentes funciones de la aplicación con el fin de que se adapten a las necesidades de su entorno.
La aplicación está dividida en tres componentes separados: el motor del monitor de red es el servicio de Windows que ejecuta continuamente las tareas de supervisión. Network Monitor Manager es una aplicación de Windows que permite ver la actividad actual del monitor, ver los resultados de las tareas y hacer cambios en la configuración. Una interfaz web da acceso de sólo lectura a las tareas y a los resultados de las tareas.
Además de ejecutar las comprobaciones de supervisión, el motor de supervisión de red también controla las notificaciones, las acciones activadas por los resultados y el registro para la aplicación. El motor de supervisión tiene varios subprocesos, lo que le permite adaptarse al entorno. El servicio no requiere que un agente de extremo ejecute sus comprobaciones de supervisión, pero esto significa que se tendrá que suministrar credenciales administrativas para supervisar servidores o estaciones de trabajo de Windows remotos. Afortunadamente, se pueden especificar varios conjuntos de credenciales, de modo que la supervisión a través de distintos dominios y contextos de seguridad no requiera una única cuenta con todo tipo de privilegios para que la solución de supervisión se ejecute.
Probablemente, pasará la mayor parte de su tiempo en Network Monitor Manager, que ofrece control granular de todas las características, los parámetros de configuración y las funciones. Desde aquí puede organizar las tareas de supervisión en una estructura de carpetas en árbol, que le ayudará a localizar e identificar elementos más rápidamente en entornos grandes, así como a filtrar la vista actual de la IU para obtener una vista rápida de un conjunto de tareas de supervisión.
Agregar una nueva comprobación de supervisión es sencillo. Network Monitor incluye casi 40 comprobaciones integradas, como comprobaciones de IP y de protocolo (por ejemplo, ICMP, LDAP, SMTP y HTTP), comprobaciones de Windows (por ejemplo, de CPU, proceso, memoria y comprobaciones de Terminal Server), conectividad de ODBC, TnsPing de Oracle, comprobaciones de base de datos basadas en consultas OLEDB, comprobaciones de pertenencia de Novell y comprobaciones de RSH de *NIX. Además, puede supervisar detalles ambientales (como la temperatura y la humedad) con un monitor ambiental SensaTronics en su red.
La aplicación admite scripts de VBScript y de shell remoto personalizados, lo cual permite adaptar totalmente las tareas de supervisión. La aplicación incluye un conjunto de plantillas de VBScript para supervisar varios servicios, como antivirus, Microsoft® ISA Server y consultas XML, así que no es necesario empezar desde cero al crear tareas de supervisión personalizadas.
Puede establecer la frecuencia de comprobación y el umbral de error para cada tarea, así como programar comprobaciones que se ejecutarán en un día y hora determinados para los casos en que se necesite, por ejemplo, comprobar los resultados de algún otro proceso que esté en ejecución, como una tarea de archivo de registro o el restablecimiento del grupo de aplicaciones IIS. También puede especificar que se ejecuten archivos ejecutables, scripts y trabajos por lotes cuando se produce un error de una comprobación o ésta se recupera, así como cuando provoca un rearranque o reinicia un servicio determinado. Por último, la interfaz web ofrece una vista de transformación XSL de los datos de resultado XML. Las hojas de estilo se pueden adaptar fácilmente para crear una vista personalizada del centro de operaciones de red (NOC) o del dispositivo móvil y, puesto que los datos están en XML, puede recuperarlos fácilmente para su uso en otra aplicación o en un sistema agregado.

Precio: A partir de 395 dólares por una licencia para cinco servidores, venta directa.
ActiveXperts Network Monitor incluye comprobaciones de ejemplo para iniciarse en su uso
ActiveXperts Network Monitor incluye comprobaciones de ejemplo para iniciarse en su uso

Reseña de libro
Windows Vista Resource Kit
microsoft.com/mspress/books/9536.aspx
A medida que cada vez más organizaciones se animan a integrar clientes de Windows Vista en su infraestructura, los profesionales de TI necesitan ponerse al día en cuanto a herramientas disponibles en el nuevo sistema operativo. El libro Windows Vista Resource Kit (Microsoft Press®, 2007) publicado recientemente analiza gran parte de la información y de las herramientas que necesitará para implementar correctamente clientes de Windows Vista en la empresa: automatización de instalaciones y activación de volúmenes, administración y mantenimiento de equipos de escritorio, uso de redes IPv6 y asistencia remota. Además de sus 1.568 páginas, este libro incluye un DVD de soporte técnico que contiene más de 100 scripts para administración e implementación, un conjunto de herramientas de depuración, Solution Accelerator for Business Desktop Deployment (BDD) y otros artículos útiles.
El libro empieza con una descripción general de las nuevas funciones que se encuentran en Windows Vista, y después presta especial atención a las mejoras de seguridad, como Control de cuentas de usuario (UAC), cifrado de unidad BitLocker y prevención de ejecución de datos (DEP). También analiza el concepto de sistema de protección de servicios y protección de revisiones de kernel. A partir de ahí, continúa con la implementación de Windows, explorando las numerosas herramientas que tiene a disposición para ayudar a automatizar el proceso. Por ejemplo, el libro examina la configuración de un entorno de preinstalación y recuperación de Windows PE 2.0 y ahonda en BDD 2007, lo cual ofrece una orientación para la planeación e implementación de Windows Vista en la empresa. Además, hay prácticas recomendadas para crear y configurar imágenes de disco, así como un análisis informativo acerca de cómo migrar datos de usuario mediante Windows Easy Transfer y la herramienta de migración de estado de usuario.
A continuación, el libro se adentra en los detalles de administración del entorno de escritorio por medio de la directiva de grupo y trata con todo detalle los nuevos archivos de plantilla administrativa basados en XML (ADMX). También trata la administración de discos y sistemas de archivos, y estudia las nuevas mejoras ReadyBoost y BitLocker de Windows Vista. Explica cómo funcionan las versiones anteriores, las instantáneas y las cuotas de disco para, a continuación, pasar a examinar el modo de implementar y administrar el área de encuentro de Windows en los grupos de trabajo, dominios y entornos inalámbricos ad hoc.
La sección dedicada al mantenimiento de equipos de escritorio del libro analiza las tareas, los informes de errores de Windows, la supervisión de rendimiento y Windows Eventing. También estudia cómo usar la asistencia remota en los servicios de soporte técnico. Después, el análisis continúa con las actualizaciones de software, los servicios de transferencia inteligente en segundo plano (BITS) y Windows Update, así como con las herramientas de auditoría.
La sección que trata de las redes muestra en detalle el funcionamiento del Firewall de Windows y explica las nuevas mejoras de la pila de red. También investiga el uso del escritorio remoto y de las conexiones de VPN para configurar usuarios y redes remotos.
Por último, el libro trata ampliamente la solución de problemas, que abarca aspectos como el arranque, la red, los errores de controlador y los problemas de dispositivo. A veces se nota un ligero trasfondo de jerga de marketing, pero en ningún caso se puede decir que sean más de 1.500 páginas sin sustancia. Se trata de un examen exhaustivo y completo de Windows Vista, sus herramientas y la administración del sistema operativo.

Precio: 59,99 dólares, venta directa.

Análisis de tráfico HTTP
Charles Web Debugging Proxy
xk72.com/charles
Si se considera la abundancia de comunicaciones basadas en HTTP entre aplicaciones y entre las estaciones de trabajo, los servidores e Internet, un buen analizador de tráfico HTTP es una herramienta increíblemente útil para los administradores del sistema. Puede ayudar a identificar problemas de proxy, cuestiones relacionadas con la seguridad, errores de conectividad, problemas de configuración y los problemas con la comunicación entre aplicaciones. Una herramienta que me gusta es la aplicación Java de Karl von Randow, Charles Web Debugging Proxy.
Al igual que en el caso de otros proxys de depuración, la aplicación se califica a sí misma de "intermediaria": se sitúa entre aplicaciones de extremo, interceptando e interpretando el tráfico que ve. Gracias a esta configuración, la aplicación también permite ver tráfico HTTPS cifrado de forma descifrada en texto normal. La IU tiene una vista bien organizada de la sesión registrada y aporta gran cantidad de información de las solicitudes básicas para páginas, imágenes, scripts y hojas de estilo hasta los detalles esenciales de tamaño, latencia y tiempo. También puede ver las cookies que se envían y reciben en cada solicitud y lo que contienen; incluso puede optar por bloquear las cookies en su totalidad.
Puede solucionar problemas de la memoria caché de solicitudes con Charles Web Debugging Proxy comprobando las fechas de las últimas modificaciones en las respuestas 304 Not Modified o bien optando por deshabilitar la memoria caché y eliminar los encabezados relacionados con ésta de las solicitudes y respuestas a medida que pasan por la aplicación. De hecho, si usa la configuración de reescritura de la aplicación, puede definir un conjunto de reglas que reescriban una serie de encabezados HTTP o el contenido del cuerpo a medida que las solicitudes y las respuestas pasan por la aplicación. O incluso podría usar la configuración de suplantación de identidad (spoofing) de DNS de la aplicación para invalidar la dirección IP de un host, lo cual permite probar las solicitudes a elementos que pueden no estar registrados en DNS. Resulta fantástica para realizar pruebas, por ejemplo, de un servidor web para garantizar que escuche y responda correctamente al encabezado del host antes de iniciar la actividad.
También puede usar la herramienta para depurar las solicitudes y respuestas de AJAX y mirar los datos XML sin formato en el interior de la respuesta. En la IU, incluso puede consultar los datos sin formato de la solicitud y respuesta para ayudar a descubrir algún encabezado extraño.
La herramienta ofrece dos presentaciones de los datos muy agradables que realmente proporcionan una buena perspectiva de la transacción de datos: la tabla de resumen y la tabla de gráfico. La tabla de resumen permite examinar rápidamente los datos de la solicitud o la respuesta, y muestra el tamaño de encabezado, el tamaño del cuerpo, el tiempo de respuesta, el código de respuesta, el tipo MIME y el recurso. La tabla de gráfico, por otro lado, ofrece una escala de tiempo gráfica del ciclo de vida que muestra donde se generaron los datos de solicitud o respuesta en la secuencia y el tiempo que tardó la transacción.
Puede guardar las sesiones de grabación para reproducirlas y analizarlas posteriormente. Esto puede ser útil para capturar ese flujo complicado de solicitudes o respuestas que provoca errores esporádicos de comunicación; una vez lo tenga, puede reproducirlo. Incluso puede importar archivos de seguimiento de HTTP en una sesión nueva y exportar la sesión actual a formato CSV o de seguimiento de HTTP.
Para simulaciones de solicitud con anchos de banda menores (por ejemplo, al tratar de averiguar por qué una solicitud arroja errores en una línea de módem de 56 k pero no en la red corporativa), la aplicación ofrece una función de limitación que permite elegir entre un conjunto de valores predeterminados comunes o definir un valor predeterminado nuevo basado en cuatro puntos de limitación: ancho de banda, porcentaje de uso, latencia de recorrido de ida y vuelta y unidad de transición máxima. También puede configurar el proxy de depuración para que actúe como proxy inverso o de reenvío de puerto, que de hecho enlaza un puerto local con un extremo (y puerto) remoto, de modo que todo el tráfico enviado a ese puerto se redirija a la dirección remota.

Precio: A partir de 50 dólares por una licencia para un único usuario, venta directa.
Charles Web Debugging Proxy analiza el tráfico HTTP
Charles Web Debugging Proxy analiza el tráfico HTTP

Limpieza de archivos innecesarios
Wise Disk Cleaner 2
wisecleaner.com
Un disco duro es algo parecido a un hogar: las cosas se acumulan con el tiempo, trastos que realmente no es necesario guardar. De vez en cuando, es buena idea tomarse tiempo para poner orden en todo ese caos. Hay algunos métodos estándar de limpieza de discos duros con las herramientas integradas de Windows, como las herramientas del sistema, el Liberador de espacio en disco y las funciones de búsqueda. Pero, a veces, lo mejor es una buena utilidad rápida y fácil de usar, especialmente cuando se puede obtener gratuitamente. Wise Disk Cleaner 2 es una herramienta de esas características que busca en los discos duros aquellos molestos archivos llenos de polvo que pueden quitarse con seguridad del sistema.
Algo que realmente me gusta de esta herramienta es que presenta todos los archivos que encuentra ante sus ojos en la IU, facilitando así la detección de cualquier posible problema. Otra característica agradable es que permite agregar fácilmente otros patrones de archivo adicionales que comprobar y quitar. Wise Disk Cleaner también limpia los archivos temporales de Internet si quiere y puede optar por conservar las cookies para no perder las preferencias de sitios que éstas puedan contener. También puede quitar los archivos de desinstalación de Windows Update, así como borrar el origen de Windows Update, la lista de archivos recientes y las carpetas temporales de Windows y de usuario. Incluso puede optar por la ejecución automática de la aplicación y establecer la preferencia de eliminar permanentemente los elementos o solamente moverlos a la Papelera de reciclaje. La aplicación también registra sus actividades para la posterior revisión; no está nada mal para ser una herramienta gratuita.

Precio: Producto gratuito.
Wise Disk Cleaner 2 busca los archivos que pueden eliminarse con seguridad
Wise Disk Cleaner 2 busca los archivos que pueden eliminarse con seguridad

Administración de dispositivos de red
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
Si tiene dispositivos, aplicaciones o sistemas de red habilitados para el protocolo simple de administración de redes (SNMP) en su infraestructura, iReasoning Networks MIB Browser permite cargar un conjunto de archivos de base de datos de información de administración (MIB) y examinar la estructura jerárquica con una vista muy parecida a la de Windows Explorer. En ella puede ver los detalles del objeto seleccionado, como el identificador de objeto (OID), la sintaxis, el acceso de lectura/escritura y la descripción.
Puede emitir fácilmente una solicitud SNMP para recuperar datos de un dispositivo de red por medio de la IU. Simplemente escriba la dirección IP del dispositivo, seleccione el objeto MIB y haga clic en Go. Si fuera necesario, también puede establecer el puerto, la versión de la solicitud SNMP y las cadenas de comunidad de lectura y escritura. Hacer cambios en un agente es igual de sencillo (suponiendo que su dispositivo lo permita). Seleccione simplemente el OID, el tipo de datos y el valor y haga clic en Aceptar. Además, dispone de una utilidad de emisión y recepción de capturas integrada que permite emitir capturas y observar la actividad de captura (a la que puede aplicar filtros para que el dispositivo en cuestión sea más fácil de ver).
iReasoning Networks MIB Browser Personal Edition es una aplicación gratuita, pero no es compatible con SNMPv3 y está limitada a la carga de cinco MIB simultáneamente. Quizá quiera considerar la versión Professional Edition (por 269 dólares por licencia, venta directa) que incluye funciones adicionales y es compatible con SNMPv3, detección de redes y comparación de dispositivos.

Precio: Producto gratuito.
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

Greg Steen es un profesional entusiasta de la tecnología a la búsqueda de herramientas y métodos para ayudar a facilitar las tareas operativas y de desarrollo para el profesional de TI.


 Preguntas y respuestas acerca de SQL: Configuraci&#243;n de la memoria, elaboraci&#243;n de perfiles de rendimiento, configuraci&#243;n del factor de relleno y mucho m&#225;s
Preguntas y respuestas acerca de SQL
Configuración de la memoria, elaboración de perfiles de rendimiento, configuración del factor de relleno y mucho más
Editado por Nancy Michell

Configuración de la memoria
Sugerencia: Elaboración de perfiles más sencilla
¿Sabía que es posible ahora correlacionar PerfMon con el Analizador de SQL Server 2005?
Quizás haya advertido incrementos bruscos de uso de la CPU, un consumo de memoria excesivo, un rendimiento general lento en el monitor de rendimiento de su equipo de SQL Server y se ha preguntado qué ha provocado estas anomalías de rendimiento. Antes de SQL Server 2005, tenía que usar el Analizador para capturar una traza, después observar los procesos de sistema en Enterprise Manager y por último capturar los registros de rendimiento (que, por supuesto, le obligaban a iniciar PerfMon). A pesar de todo este trabajo con todas estas herramientas, necesitaba reconciliar de manera manual eventos entre las herramientas para averiguar por qué el rendimiento se había visto afectado. Y esto implicaba avanzar muy lentamente a través de cada uno de los registros. No era en absoluto divertido, pero si necesario si deseaba llegar hasta el fondo de sus problemas de rendimiento.
Con SQL Server 2005, sigue siendo necesario capturar una traza y examinar los registros de PerfMon, pero ahora el Analizador le permite adjuntarlos. Puede desplazarse por las instrucciones de T-SQL y el Analizador le mostrará automáticamente, de manera gráfica, lo que ha ocurrido. Si hace clic en la interfaz de usuario del monitor de rendimiento en el Analizador, pasará a la instrucción que se correlaciona con esa marca de hora. Esto ahorra grandes cantidades de tiempo en la solución de problemas en su entorno de SQL Server.
Veamos ahora cómo adjuntar registros de PerfMon al Analizador:
  1. Inicie el monitor de rendimiento y comience a capturar información del servidor de la base de datos.
  2. Cree un nuevo registro del contador en Registros y alertas de rendimiento y escriba un nombre para su nuevo registro.
  3. Agregue nuevos contadores, como % de tiempo de procesador. Deseará igualmente configurar su registro para que se inicie manualmente o según un programa mediante la ficha Programación.
  4. Haga clic en Aceptar y, si ha elegido la opción manual, asegúrese de iniciar el registro.
  5. Configure una traza en SQL Server a través del Analizador. Puede hacerlo haciendo clic en Nueva traza en el menú Archivo. Asegúrese de incluir la Hora de inicio y la Hora de finalización en la traza, a continuación, dé un nombre a la traza y configúrela para guardarla en un archivo. En último lugar, debe poner en funcionamiento el servidor para simular cierta actividad de transacción, a continuación, deje de capturar tanto el monitor de rendimiento como los datos del Analizador.
  6. En el Analizador, seleccione Importar datos de rendimiento en el menú Archivo. A continuación, escoja la ubicación en la que almacenó su registro de PerfMon y seleccione Archivo | Abrir | Traza. Finalmente, seleccione la ubicación en la que almacenó la traza del Analizador.
Cuando esté listo, verá lo sencillo que es averiguar qué efecto particular han tenido las instrucciones SQL en el tiempo de procesamiento.

P Intento averiguar la mejor configuración de memoria para mis cuadros de SQL Server™. El administrador anterior configuró Boot.ini para cada equipo con 12 GB de RAM en un clúster de dos nodos de SQL Server 2000 de la siguiente manera: Yes /PAE NO /3GB (Sin AWE configurado para SQL Server). Con 12 GB de RAM disponibles, ¿debo quitar el conmutador /3GB de Boot.ini, activar AWE y dar a SQL Server unos 10 GB de los 12 GB? No hay nada más en los equipos que ejecutan SQL Server, por lo que ninguna otra aplicación necesita memoria.
R Sí, debe activar las direcciones de ventana de dirección (AWE) y asignar previamente un límite superior de RAM para SQL Server, 10 GB está bien para un cuadro dedicado de SQL Server de 12 GB. (Tenga en cuenta que la asignación previa sólo es válida para SQL Server 2000. El inicio con SQL Server 2005, mediante AWE, ya no es estático y puede cambiarse sobre la marcha.) Siempre ha habido un gran debate en cuanto a si usar los conmutadores /3GB y /PAE simultáneamente o sólo el conmutador /PAE. Aunque sólo necesita configurar el conmutador /PAE y tener activada la AWE, le sugiero que use ambos conmutadores; sin embargo, hay algunos factores de debe considerar.
El uso del conmutador /3GB se reduce a si es necesario en su situación particular. ¿Se está quedando sin las áreas de memoria MemToLeave que deben estar en los primeros 2 ó 3 GB del espacio de direcciones virtual? Si habilita el conmutador, ¿está privando de memoria el sistema operativo? (Para obtener más información consulte support.microsoft.com/kb/316739). Si está trabajando en un clúster, podría configurar /3GB en un nodo en particular. De ese modo, si está realizando pruebas con /3GB y está teniendo problemas, puede conmutar la instancia por error en otro nodo muy rápidamente. Tenga en cuenta que si tiene más de 16 GB de RAM, el conmutador /3GB no es compatible.
Mediante /3GB, aumenta el espacio de direcciones virtual (VAS) en un 50%, así que las aplicaciones que colocan la demanda de memoria en VAS y no sólo en la memoria caché de datos se benefician ampliamente. Afortunadamente, los servidores de 64 bits, tanto IA64 como x64, eliminan ese factor mal comprendido. Las inquietudes que surgen de privar de recursos al SO no son aplicables si el equipo está dedicado a SQL Server. Dejar tan sólo 2 GB para el sistema operativo es un poco excesivo; si este servidor está dedicado a SQL Server con sólo los servicios mínimos estándar de sistema operativo en ejecución, observará que hay unos 1,3 GB de memoria libre en el servidor, por lo que puede permitir a SQL Server usar el GB extra. Comience con 10 GB, use PerfMon para supervisar la memoria disponible durante un período largo para consultar el tiempo de inactividad y, a continuación, realizar el ajuste correspondiente. Recuerde que provocará intercambios si realiza confirmaciones en exceso en SQL Server 2000, puesto que AWE no es en este caso tan dinámica como lo es con SQL Server 2005. La clave para decidir si usar el conmutador /3GB es probarlo en su entorno específico.

Nombres de instancia para la réplica
P ¿Puedo usar ahora la dirección IP de mi servidor en la réplica de SQL Server 2005 para indicar qué instancia replicar? En SQL Server 2000, según "Cómo realizar réplicas entre equipos que ejecutan SQL Server en dominios no confiables o a través de Internet" (support.microsoft.com/kb/321822), el hacerlo provocará errores, pero no sé con seguridad si sigue siendo cierto.
R Al especificar las instancias de servidor para participar en la réplica, debe suministrar el nombre de instancia registrado de SQL Server. Por ejemplo, debe usar el nombre de instancia de SQL Server al especificar los parámetros Publisher o Subscriber para los procedimientos de réplica almacenados o para la configuración de la conexión del agente de réplica en la línea de comandos. Si el nombre de red para la instancia de SQL Server difiere del nombre de instancia registrado, las conexiones de réplica por agentes tendrán errores.
Si el nombre de red de la instancia y el nombre de instancia de SQL Server difiere, considere agregar el nombre de instancia de SQL Server como un nombre válido de red. Una manera de configurar un nombre de red alternativo es agregarlo al archivo host local. El archivo host local se ubica de manera predeterminada en WINDOWS\system32\drivers\etc o WINNT\system32\drivers\etc. Por ejemplo, si el nombre del equipo es comp1, el equipo tiene una dirección IP 10.193.17.129 y el nombre de la instancia es inst1/instname, agregue la entrada siguiente al archivo host:
10.193.17.129 inst1

SQL Server Integration Services
P Estoy instalando un clúster activo/activo para SQL Server 2005 (Enterprise Edition 64 bit con dos servidores) y tendré un total de cuatro instancias de SQL Server 2005. SQL Server Integration Services (SSIS) será necesario para todas las instancias. ¿Qué me puede decir acerca de la agrupación de SSIS y el efecto en los planes de mantenimiento?
R Aunque puede agrupar el servicio SSIS, no es necesario hacerlo pues podría encontrar gran cantidad de problemas, incluidos una falta de compatibilidad para la delegación (consulte msdn2.microsoft.com/aa337083) y que no tiene varias instancias, sólo es posible ejecutar una instancia en un nodo al mismo tiempo.
Anteriormente, era necesario instalar SSIS, no ejecutarlo, sólo instalarlo, para que se ejecutara el Asistente para planes de mantenimiento. Sin embargo, éste no es el caso en SQL Server 2005 SP1. Si SSIS no se ejecuta, los planes de mantenimiento pueden ejecutarse gracias al Agente SQL Server.
Mejor que agrupar SSIS, puede considerar mantenerlo en ejecución como servicio independiente y editar MsDtsSrvr.ini.xml para señalar a cualquier instancia en ejecución. Esto le permite administrar sus paquetes desde cualquier nodo y proporcionar la alta disponibilidad que la mayoría de los clientes están buscando sin ninguno de los problemas asociados con la agrupación del servicio.
Para obtener más información acerca de la creación de planes de mantenimiento con error, asegúrese de consultar el artículo de Knowledge Base en support.microsoft.com/kb/909036.

Tiempo de ejecución extraño
P Durante la prueba de carga en mi cuadro SQL Server 2005 SP1, el Analizador de SQL Server registró muchos valores negativos del tiempo de procedimiento del procedimiento almacenado (SP) y, en algunos casos, el tiempo de ejecución de SP, no coincidió con el resultado de restar la hora de inicio a la hora de finalización.
R Hay una serie de factores que pueden afectar a la generación de informes de la hora de ejecución de SP y otros tiempos de rendimiento en el Analizador de SQL Server. Recuerde, SQL Server 2005 usa milisegundos para contar el tiempo de ejecución y si usa cualquier tecnología que cambie la unidad de medida, sufrirá incoherencias en los tiempos de generación de informes y de ejecución que no se agregan.
Por ejemplo, si usa otras combinaciones de energía, escalonamiento de la CPU o la tecnología AMD Cool'n Quiet, cambia las frecuencias de la CPU, que después no coincidirán con lo que el Analizador de SQL Server espera al calcular el tiempo de ejecución.
Hay un artículo de Knowledge Base en support.microsoft.com/kb/931279 que explica los síntomas, una variedad de causas y algunos remedios.
Sugerencia: Compruebe su factor de relleno
Supongamos que tiene un vaso lleno completamente de agua e intenta poner más agua en ese vaso. ¿Qué sucede? El agua se desborda.
Ocurre lo mismo con SQL Server. Siempre que se agrega una fila a una página de índice completa, SQL Server mueve aproximadamente la mitad de las filas a una nueva página para dejar espacio a una nueva. Esto se denomina división de página. Las divisiones de página dejan espacio a nuevos registros, pero también tardan mucho y consumen muchos recursos. Y pueden provocar fragmentación, lo cual puede afectar de manera negativa a las operaciones de E/S. Así pues, ¿cómo las puede evitar?
Para evitar dichas situaciones, debe determinar de manera proactiva el valor del factor de relleno. Cuando se crea o reconstruye un índice, el valor del factor de relleno determina el porcentaje del espacio en cada página de nivel de hoja que se va a rellenar con datos, conservando el resto para un crecimiento futuro. Por ejemplo, configurar un valor de factor de relleno de 60 significa que el 40% de cada página de nivel de hoja se dejará vacío para facilitar la expansión del índice a medida que se agreguen datos a la tabla subyacente.
El valor predeterminado del factor de relleno es siempre 0, lo cual es correcto para la mayoría de las situaciones. Básicamente, un factor de relleno de 0 implica que el nivel de hoja se rellena casi hasta su capacidad, pero que se deja cierto espacio para al menos una fila de índice adicional. (Tenga en cuenta que un factor de relleno de 0 y 100 es similares.)
Puede configurar el valor del factor de relleno para índices individuales durante una instrucción CREATE INDEX o ALTER INDEX, o puede configurar este valor directamente en el nivel de servidor para que cualquier índice nuevo creado use el valor predeterminado.
El ejemplo siguiente configura el valor del factor de relleno en el nivel del servidor en 70%, lo cual implica que dispone de un 30% de espacio disponible para una futura expansión. Por supuesto, debe probar con cuidado esta opción antes de implementarla en un entorno de producción.
USE Master;
GO
SP_Configure 'show advanced options',1;
GO
SP_Configure 'Fill Factor', 70;
GO
--You must restart SQL Server Engine for changes to take effect.
¿Qué ocurre si desea configurar el factor de relleno en el nivel del índice individual? Asuma que crea la tabla siguiente y que desea crear un índice único en la columna llamada Col_A con un valor de factor de relleno de 70. El comando tendría este aspecto:
--Create an Item table
USE Item_DB;
GO
CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200));
GO;

--Create a unique index on colum Col_A of Item table with a Fill Factor value of 70
CREATE UNIQUE INDEX AK_Index ON Item (Col_A)
WITH (FillFactor = 70);
GO
¿Cómo es posible identificar el factor de relleno de cada índice? Puede consultar los sys.Indexes para obtener el valor del factor de relleno de todos los índices de la base, de este modo:
USE Item_DB;
GO
SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL;
GO


 Utility Spotlight: Herramienta de evaluaci&#243;n de seguridad de Microsoft
Utility Spotlight
Herramienta de evaluación de seguridad de Microsoft
Lance Whitney
Descargar el código de este artículo: Microsoft Security Assessment Tool 3.0 (sólo en inglés) (10547.2KB)

La localización de problemas de seguridad en la red puede ser bastante complicada y consumir mucho tiempo. Una herramienta que le puede ayudar a identificar y resolver riesgos de seguridad es la Herramienta de evaluación de seguridad de Microsoft® (MSAT), una utilidad gratuita que presenta un cuestionario electrónico en el que describir su entorno de seguridad. MSAT está diseñada para medianas empresas que tienen entre 50 y 500 equipos y plantea 172 preguntas organizadas en categorías diferentes, después de lo cual proporciona un análisis de su situación junto con recomendaciones acerca de cómo mejorarla.
MSAT comienza con un conjunto de consultas acerca de su modelo de negocio, que se usa para crear un Perfil de riesgo empresarial (BRP) que evalúa su riesgo de seguridad en comparación con el riesgo de otros dentro de su sector. Normalmente se tarda unas dos horas en completar el cuestionario, además puede parar y continuar en cualquier punto. A continuación, le mostramos las distintas categorías con preguntas de ejemplo:
Información básica ¿Cuántos clientes y servidores hay en su organización?
Seguridad de la infraestructura ¿Trabajan sus empleados de manera remota? ¿Tienen acceso los contratistas externos a su red?
Seguridad de aplicaciones ¿Desarrolla su compañía las aplicaciones? ¿Almacena datos confidenciales procesados por sus aplicaciones?
Seguridad de operaciones ¿Se conecta su red corporativa a redes externas? ¿Recibe su organización fuentes de datos de organizaciones externas?
Seguridad de personas ¿Subcontrata su compañía el mantenimiento de equipos? ¿Permite a los empleados descargar datos confidenciales de la compañía a sus estaciones de trabajo?
Entorno ¿Cuántos empleados hay en su organización? ¿Hay una rotación alta del personal en su departamento de TI?
A continuación, la MSAT genera una evaluación que usa una medida denominada Índice de defensa exhaustivo (DiDI), que se centra en los procesos de seguridad que están en marcha. Con las mismas categorías, las preguntas típicas son: ¿Emplea su organización firewalls en cada ubicación? ¿Usa macros personalizadas en sus aplicaciones de Microsoft Office? ¿Tienen sus usuarios derechos administrativos en sus estaciones de trabajo? ¿Tiene una directiva para implementar revisiones y actualizaciones a sus equipos?
Según sus respuestas, el MSAT ofrece tres informes. El Informe de resumen muestra un gráfico de barras con los resultados. Una puntuación alta en el BRP indica más riesgo, mientras una puntuación alta en el DiDI representa más seguridad. Tal como indica la MSAT, aunque pueda parecer preferible un BRP bajo y un DiDI alto, es realmente más importante examinar áreas individuales. Así, para cada área, el Informe completo indica si cumple o no con los procedimientos recomendados, si necesita mejora o si carece de ambas (consulte la figura 1).
Figura 1 El informe completo
Figura 1 El informe completo
Finalmente, el Informe de comparación le pide que cargue sus resultados de manera anónima en un sitio web seguro de la MSAT, donde puede comparar sus resultados con aquellos de otras organizaciones.
Puede descargar la herramienta del sitio web de Microsoft Security Guidance en securityguidance.com o del sitio web de TechNet Magazine en technetmagazine.com/code07.aspx.

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


 The Cable Guy: Servidor de directivas de redes
The Cable Guy
Servidor de directivas de redes
Joseph Davies
Este artículo se basa en una versión preliminar de Windows Server 2008. Por tanto, toda la información de este documento está sujeta a cambios.

El servicio Servidor de directivas de redes (NPS) de Windows Server 2008 sustituye al Servicio de autenticación de Internet (IAS) de Windows Server 2003. NPS permite a un equipo que ejecuta Windows Server 2008 actuar como servidor y proxy del servicio de usuario de acceso telefónico de autenticación remota (RADIUS). RADIUS es un protocolo del Internet Engineering Task
Force (IETF) con especificaciones RFC 2865 y 2866 que ofrece autenticación centralizada, autorización y asignación de cuenta (AAA) para dispositivos de acceso a redes como puntos de acceso inalámbrico. Los servidores RADIUS llevan a cabo AAA para dispositivos de acceso a redes. Los proxys de RADIUS reenvían mensajes RADIUS entre clientes (dispositivos de acceso a redes) y servidores RADIUS.
NPS incluye muchas mejoras para facilitar la implementación de acceso autenticado a redes, ofrecer extensibilidad para componentes de terceros y para ser compatible con las últimas tecnologías y plataformas de red. El nuevo complemento NPS se muestra en la figura 1.
Figura 1 El nuevo complemento NPS
Figura 1 El nuevo complemento NPS

Características del Servidor de directivas de redes
En esta columna, hablaré de las características de NPS que no se incluyeron en versiones anteriores de Windows®. Empezaré explicando cómo la Protección de acceso a redes (NAP) ayuda a exigir los requisitos de estado para su red y afecta a la administración, la configuración, la compatibilidad con IPv6 y otros elementos. También describiré las características del nuevo complemento NPS.
Protección de acceso a redes NAP, que se presentó en Windows Server® 2008, constituye un conjunto de nuevas tecnologías que pueden ayudarle a exigir el cumplimiento de requisitos de estado de equipo, lo que le permite proteger de manera más adecuada su intranet. Sus directivas de estado pueden especificar, por ejemplo, que se debe instalar y habilitar un firewall y que se deben instalar las últimas actualizaciones de sistema operativo en todos los clientes que se conectan a su red. Con NAP, puede crear directivas personalizadas para certificar el estado de un equipo antes de permitir su acceso a redes o a comunicación, actualizar de forma automática los equipos para asegurar el cumplimiento continuo y limitar los equipos que no cumplan con la directiva a una red restringida hasta que cumplan. Para obtener más información, consulte microsoft.com/nap.
En una implementación de NAP, el servidor NPS es un servidor de la directiva de estado NAP que evalúa el estado de clientes NAP para garantizar los puntos de aplicación de NAP, tales como las autoridades de registro de estado (HRA), los puntos del acceso 802.1X, los servidores de red privada virtual (VPN) y los servidores del Protocolo de configuración dinámica de host (DHCP). El servidor NPS determina también si se debe conceder acceso completo o limitado a los clientes a la intranet. Las directivas de la red, las directivas de estado y la configuración NAP determinan el comportamiento de la evaluación del estado para NPS.
Compatibilidad con las directivas EAPHost y EAP NPS es compatible con EAPHost, la nueva arquitectura de métodos de autenticación para el Protocolo de Autenticación Extensible (EAP). Esta nueva arquitectura permite a proveedores de método EAP desarrollar e instalar de manera fácil los nuevos métodos EAP para 802.1X o autenticación basada en el protocolo punto a punto (PPP), tanto en los equipos cliente como servidores NPS.
EAPHost será compatible con la instalación y el uso de todos los métodos EAP incluidos en el Registro EAP en www.iana.org/assignments/eap-numbers, así como otros métodos de autenticación populares, como Cisco Systems Lightweight EAP (LEAP). EAPHost permite la coexistencia de múltiples implementaciones de un método EAP. Por ejemplo, puede instalar y seleccionar tanto la versión de Microsoft de EAP Protegido (PEAP) como la versión de Cisco Systems.
Para proveedores de método EAP, EAPHost es compatible con los métodos EAP ya desarrollados para Windows XP y Windows Server 2003, además de una manera más fácil de desarrollar nuevos métodos EAP para Windows Vista® y Windows Server 2008. Después de la instalación, puede configurar los métodos EAP necesarios para una situación específica de acceso a red en una directiva de red. Una directiva de red para NPS es igual que una directiva de acceso remoto para IAS.
Para obtener más información acerca de la arquitectura de EAPHost, consulte technetmagazine.com/issues/2007/05/CableGuy.
Configuración almacenada en XML IAS almacenaba su información de configuración en una base de datos Jet. NPS ahora almacena información de configuración en formato XML, lo que facilita la exportación de la configuración de un servidor de NPS e importarla a otro. Exportar e importar archivos de configuración es una forma de sincronizar la configuración de varios servidores NPS en una configuración con tolerancia a errores. Puede exportar la configuración NPS con el comando de exportación netsh nps e importarla con el comando de importación netsh nps.
Cumplimiento de Common Engineering Criteria NPS se ha actualizado para que sea compatible con la implementación en los entornos que deben cumplir con Microsoft® Common Engineering Criteria (CEC). Para obtener más información, consulte microsoft.com/windowsserversystem/cer/allcriteria.mspx.
DLL eficaces para extensión de NPS El servicio NPS puede extenderse a través de DLL de extensión y autorización. A diferencia de IAS, estos componentes de terceros están aislados dentro de NPS para que ningún problema que puedan encontrar afecte a la operación o ejecución de NPS.
Compatibilidad con IPv6 NPS es compatible con IPv6 y la implementación en entornos IPv6 nativos o de túnel. Puede configurar las direcciones IPv6 para clientes RADIUS o servidores remotos RADIUS y el servicio NPS puede comunicar sobre IPv6 para autenticación de cuenta de servicios de dominio y operaciones de autorización Active Directory®.
IAS frente a NPS
Si ya está familiarizado con el complemento IAS para Windows Server 2003, apreciará los siguientes cambios en el complemento NPS:
  • Las directivas de acceso remoto pasan a ser las directivas de red y se han colocado bajo el nodo Directivas.
  • El nodo Clientes RADIUS se ha trasladado bajo el nodo Clientes y servidores RADIUS.
  • Ya no hay un nodo Procesamiento de solicitud de conexión. El nodo Directivas de solicitud de conexión se ha trasladado bajo Directivas y el nodo Grupos de servidores remotos RADIUS se ha colocado bajo Clientes y servidores RADIUS.
  • La configuración de perfiles y las condiciones de la Directiva de acceso remoto se han reorganizado en la fichas Información general, Condiciones, Restricciones y Configuración de las propiedades de una directiva de red.
  • Las condiciones de la directiva de solicitud de conexión y la configuración de perfiles se han reorganizado en las fichas Información general, Condiciones y Configuración de las propiedades de una directiva de solicitud de conexión.
  • La carpeta Registro de acceso remoto ha cambiado de nombre al nodo Cuentas y ya no tiene los nodos Archivo local o SQL ServerTM.

Generación automática de secretos compartidos seguros de RADIUS Los secretos compartidos de RADIUS se usan para comprobar que los mensajes RADIUS han sido enviados por un cliente, servidor o proxy RADIUS configurado con el mismo secreto compartido. Los secretos compartidos se usan también para cifrar algunos atributos confidenciales de RADIUS, como las contraseñas y las claves de cifrado. Los secretos compartidos seguros de RADIUS son una secuencia larga (más de 22 caracteres) y aleatoria de letras, números y signos de puntuación.
Con el complemento NPS, puede generar automáticamente un secreto compartido seguro RADIUS cuando agregue o edite un cliente RADIUS. Este secreto compartido seguro puede copiarse a un editor de texto, como el Bloc de notas, así que tiene la capacidad de configurar el dispositivo de acceso a redes o punto de aplicación NAP con el mismo secreto compartido.
Integración con el administrador de servidores Puede instalar NPS a través de las herramientas Tareas de configuración inicial y Administrador de servidores. En ambos casos, se instala NPS con la Directiva de red y la función de Servicios de acceso. Para empezar, en la herramienta Tareas de configuración inicial en Personalizar este servidor, haga clic en la opción Agregar funciones. En la herramienta Administrador de servidores, abra Resumen de funciones y haga clic en Agregar funciones.
Después de instalar NPS, puede hacer clic en Directiva de red y Servicios de acceso bajo el nodo Funciones en el árbol de la consola del Administrador de servidores para comprobar el estado del servicio NPS y para ver eventos de error encontrados en las últimas 24 horas. Cuando amplía la Directiva de red y el nodo Acceso a servicios en la consola, puede configurar NPS con el complemento NPS.
Compatibilidad mejorada con Netsh Windows Server 2003 tenía un conjunto limitado de comandos en el contexto netsh aaaa para configurar IAS. En Windows Server 2008, el nuevo contexto netsh nps tiene un conjunto extenso de comandos para configurar NPS en la línea de comandos o a través de un script. Ahora, con los comandos netsh nps, puede configurar clientes y servidores remotos RADIUS, directivas de red, inicio de sesión y para NAP, directivas de estado, validadores de estado del sistema y grupos de servidores de actualizaciones. Los scripts formados por comandos en el contexto netsh nps ofrecen otra manera de sincronizar la configuración de múltiples servidores NPS en una configuración con tolerancia a errores.
Etiquetas de origen para el aislamiento de la directiva de red Las directivas de red pueden configurarse para un tipo específico de servidor de acceso a redes o punto de aplicación NAP, como un servidor DHCP o HRA, que pasan a ser una etiqueta de origen que clasifica la directiva de red. Los servidores de acceso basados en Windows Server 2008 y puntos de aplicación NAP incluyen esta etiqueta de origen en sus mensajes RADIUS. Cuando se recibe un mensaje RADIUS solicitando el acceso, el servicio NPS intenta encontrar una directiva de red coincidente que tenga la misma etiqueta de origen que el mensaje entrante. Si ninguna directiva coincide, NPS intenta encontrar una directiva de red coincidente para esas directivas que no tienen etiqueta de origen especificada.
El uso de la etiqueta de origen en la directiva de red y mensajes RADIUS entrantes aísla los diferentes tipos de directivas de red una de la otra. Por ejemplo, las directivas de red para servidores DHCP no se usan para conexiones VPN.
Integración con el control de acceso a redes de Cisco NPS es compatible con características para integrarse mejor en un entorno que use hardware de Cisco y el Control de acceso a redes (NAC). Las características incluyen compatibilidad con el Protocolo de autorización de credencial de host (HCAP) y las condiciones de HCAP, la condición de expiración de la directiva y la configuración de Protección de acceso a redes de estado extendido en directivas de red.
Condiciones de nueva directiva de red Las directivas de redes en NPS tienen nuevas condiciones que han sido pensadas para especificar grupos de equipos, grupos de usuarios, tipos permitidos de EAP y direcciones de servidor de acceso y cliente IPv6. Para la compatibilidad con HCAP, NPS tiene condiciones nuevas para grupos de ubicación y grupos de usuarios. Para la compatibilidad con NAP, NPS tiene condiciones de directiva nuevas para el tipo identidad, directiva de estado, equipos compatibles con NAP, sistema operativo y expiración de directiva.
El complemento NPS El nuevo complemento NPS se ha mejorado significativamente para que pueda administrar fácilmente clientes y servidores remotos RADIUS, con directivas de red para situaciones comunes de acceso a redes, directivas de estado y configuración NAP para situaciones NAP y configuración de inicio de sesión.
En el nodo Clientes y servidores RADIUS, puede configurar clientes RADIUS (servidores de acceso a redes, puntos de aplicación de NAP u otros proxys RADIUS cuando NPS actúa como un servidor RADIUS) y grupos de servidores remotos RADIUS (otros servidores RADIUS cuando NPS actúa como un proxy RADIUS).
En el nodo Directivas, puede configurar directivas de solicitud de conexión (tanto si el servicio NPS actúa como servidor o como proxy de RADIUS), directivas de red (configuración y restricciones de autorización y conexión cuando el servicio NPS actúa como servidor RADIUS) y las directivas de estado (cumplimiento de estado de sistema para clientes NAP). Cuando selecciona una directiva de solicitud de conexión o una directiva de red en el panel de detalles, el complemento NPS muestra las condiciones de la directiva y la configuración. La figura 2 muestra un ejemplo del aspecto de lo explicado.
Figura 2 Visualización mejorada del complemento NPS
Figura 2 Visualización mejorada del complemento NPS
En el nodo Protección de acceso a redes, el nodo Validadores de estado del sistema le permite configurar los requisitos de estado NAP. El nodo Grupos del servidor de actualizaciones le permite configurar el conjunto de servidores que restringieron a los clientes NAP el acceso a los métodos de aplicación VPN y DHCP NAP. Por último, en el nodo Cuentas, puede configurar cómo NPS almacena la información de cuenta.
El complemento NPS incluye un conjunto extenso de asistentes para automatizar la configuración inicial de clientes RADIUS y las directivas necesarias para métodos de aplicación de NAP, conexiones telefónicas o basadas en VPN y para conexiones inalámbricas autenticadas 802.1X y conexiones con cable. Para métodos de aplicación de NAP, el asistente de NAP configura automáticamente todas las directivas de solicitud de conexión, directivas de red y directivas de estado.
Estos nuevos asistentes están disponibles al hacer clic en el nodo NPS en el complemento NPS. Para configurar las directivas y la configuración para métodos de aplicación de NAP, seleccione Protección de acceso a redes en el cuadro desplegable Configuración estándar y, a continuación, haga clic en Configurar NAP. Para configurar las directivas y la configuración para VPN o acceso telefónico a redes, seleccione el servidor RADIUS para conexiones telefónicas o VPN en el cuadro desplegable Configuración estándar y, a continuación, haga clic en Configurar VPN o Telefónico. Para configurar las directivas y la configuración para acceso inalámbrico autenticado 802.1X o por cable, seleccione servidor RADIUS 802.1X inalámbrico o conexiones por cable en el cuadro desplegable Configuración estándar y, a continuación, haga clic en Configurar 802.1X.
Cada uno de estos asistentes le guía a través de los elementos de configuración más comunes para la situación elegida. Los asistentes para los métodos de aplicación de NAP son especialmente útiles: el asistente para NAP para la aplicación de VPN crea una directiva de solicitud de conexión, tres directivas de red (para clientes compatibles con NAP, para clientes no compatibles con NAP y para clientes que no son NAP) y dos directivas de estado (para clientes compatibles y no compatibles con NAP).
Los nuevos asistentes NAP y otros asistentes para crear clientes RADIUS, grupos de servidores remotos RADIUS, directivas de solicitud de conexión y directivas de red, hacen mucho más fácil configurar NPS en diversas situaciones de acceso a redes.

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


 Windows PowerShell: Profundizaci&#243;n
Windows PowerShell
Profundización
Don Jones

Windows PowerShell está repleto de características que a muchos administradores se les suelen pasar por alto. Si profundiza un poco, encontrará algunas capacidades que le sorprenderán. De hecho, yo mismo descubro a menudo nuevas características asociadas a un cmdlet determinado que ya creía conocer al dedillo.
En las clases de Windows PowerShellTM que imparto, recomiendo a los administradores que creen para ellos mismos un calendario con un cmdlet para cada día, de forma parecida a uno de esos calendarios que sugieren una palabra nueva para cada día. De este modo, cada mañana (sin contar los fines de semana), pueden dedicar unos minutos a familiarizarse con las capacidades completas de un cmdlet. Windows PowerShell se comercializa con unos 130 cmdlets, lo que significa que puede aprender prácticamente todo lo que Windows PowerShell es capaz de hacer en cuestión de seis meses si se ciñe a esta programación. Para entonces, estará preparado para enfrentarse a todos los cmdlets de Exchange Server 2007.
En la columna de este mes, quiero presentar algunos ejemplos de lo que podría descubrir y puede lograr sólo con dedicar unos minutos a explorar las capacidades más ocultas de varios cmdlets.

Informes HTML con mejor aspecto
Uno de los cmdlets que están bastante infrautilizados es ConvertTo-HTML. Este ingenioso cmdlet puede aceptar una colección de objetos de entrada (servicios, procesos, objetos de instrumental de administración de Windows® (WMI) o lo que sea) y los convierte en una tabla HTML. A continuación puede canalizar el HTML a Out-File y obtener una página HTML apta para exponer en un servidor web de intranet. Por ejemplo, puede programar esta línea sencilla para que se ejecute todas las mañanas:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML | Out-File C:\ServiceAlert.html
Con ello se creará un informe HTML, como el que se muestra en la figura 1, de servicios que deberían iniciarse automáticamente pero no se ejecutan.
Figura 1 Informe HTML de servicios que no se ejecutan
Figura 1 Informe HTML de servicios que no se ejecutan
Efectivamente, quizás desee producir un informe que sea un poco más atractivo. Afortunadamente, el cmdlet ConvertTo-HTML produce HTML limpio, lo que significa que no incrusta ningún formato en el código HTML que crea. Según las reglas de HTML, nunca debe ponerse formato en el HTML (bueno, debe ponerse lo menos posible). Donde sí que se debe poner formato es en una hoja de estilos en cascada (CSS) externa y vincularla al HTML. Y ese vínculo se puede crear con ConvertTo-HTML.
La CSS se vincula en la sección <HEAD> de un archivo HTML. Si observa la ayuda de ConvertTo-HTML, verá que su sintaxis incluye algunos parámetros que quizás haya pasado por alto:
ConvertTo-Html [[-property] <Object[]>]
[-inputObject <psobject>] [-body <string[]>]
[-head <string[]>] [-title <string>] [<CommonParameters>]
El parámetro –head le permite especificar código HTML adicional que insertar en la sección <HEAD> del script. Ahora puedo modificar fácilmente la línea para vincularla a un archivo CSS existente que contenga el formato que deseo aplicar a la tabla HTML:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML -title "Services" -head "<link
rel='stylesheet' href='styles.css' type='text/
css' />" | Out-File C:\ServiceAlert.html
En este caso usé el parámetro –head para insertar un vínculo en un archivo CSS ubicado en la misma carpeta que el archivo de salida HTML. También usé el parámetro –title para establecer el título de la página web. El resultado aparece en la figura 2. El texto del archivo Style.CSS que usé tiene este aspecto:
Figura 2 Informe HTML formateado con un archivo CSS
Figura 2 Informe HTML formateado con un archivo CSS
body { background-color:#EEEEEE; }
body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt }
th { font-weight:bold; background-color:#CCCCCC; }
td { background-color:white; }

Filtrado más fácil
Cmdlet del mes
Este mes estoy estudiando un par de cmdlets: Start-Transcript y Stop-Transcript. Ambos sirven para controlar el registro de transcripciones de Windows PowerShell, es decir, para que todo lo que aparece en la ventana de la consola se escriba en un archivo de texto que haya especificado. Es bastante sencillo. Ejecute Start-Transcript y asígnele un nombre de archivo para empezar. A continuación, ejecute Stop-Transcript para terminar el registro y cerrar el archivo. Esta operación implica un modo estupendo de pasar del uso ad hoc de shells al scripting formal; una vez que haya líneas de comandos individuales funcionando en el shell, simplemente podrá copiarlos y pegarlos del archivo de transcripción que haya creado. Por supuesto, si lo desea, puede editar la transcripción para que pase a ser únicamente el script en sí. Jeffery Hicks, miembro de MVP, escribió incluso un script que analiza transcripciones y las convierte en archivos de Windows PowerShell PS1. Encontrará este script en blog.sapien.com/current/2006/11/28/powershell-transcripts.html.

Ahora observemos el cmdlet Get-WMIObject. Su sintaxis, como se indica en la ayuda integrada de Windows PowerShell, señala de forma sugerente hacia las capacidades sin explotar:
Get-WmiObject [-class] <string> [[-property]
<string[]>] [-namespace <string>]
[-computerName <string[]>] [-filter <string>]
[-credential <PSCredential>]
[<CommonParameters>]
Un error habitual que cometerán los nuevos usuarios de Windows PowerShell es el de ejecutar un comando WMI como éste:
Gwmi Win32_NTLogEvent –comp Server2
Este comando recuperará las entradas de registro de eventos de Server2 (todas las entradas de registro de eventos). Esta tarea ocupara unos minutos a Server2 hasta que procese y transmita, y Windows PowerShell tardará bastante en hacer algo útil con una colección tan grande.
Un mejor enfoque es hacer que Server2 busque y envíe los eventos que realmente le interesan. Esto podría hacerlo con toda seguridad usando una consulta de lenguaje de consulta de WMI (WQL). Para algunas personas esa sintaxis de consulta resulta difícil, pero Windows PowerShell le permite especificar simplemente la parte de filtrado de una consulta de WQL, mediante el parámetro –filter:
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Esto recuperará todos eventos (de cualquier registro) con el id. de evento 1024. Observe que los criterios de filtro usan = como operador de comparación en lugar del operador –eq de Windows PowerShell. Esto es así porque el filtro se está transfiriendo al servicio WMI del equipo remoto para su procesamiento, por lo que los criterios deben estar en la sintaxis de WMI, no en la sintaxis de Windows PowerShell.
Existe en realidad un parámetro –filter en otros cmdlets como, por ejemplo, Get-ChildItem, el cmdlet contenido en alias como Dir y Ls. En la mayoría de los casos, el parámetro –filter transfiere sus criterios de filtro directamente a la tecnología subyacente, y eso tiene como resultado lo que yo llamo filtrado de origen, que suele ser mucho más rápido que recopilar todos los objetos y, a continuación, ejecutarlos a través del cmdlet Where-Object para excluir los que no interesan.

Cmdlets que se pasan por alto
En efecto, este enfoque mediante el que se estudia un cmdlet al día le ayudará a comprender mejor los cmdlets ya creía conocer. Sin embargo, otro buen motivo para tener un calendario de cmdlets para cada día es evitar que se le pasen totalmente por alto cmdlets que, de otro modo, quizás no descubriría nunca. Uno de mis favoritos y que muchas personas no usan es Resolve-Path. Al determinar una ruta de acceso de caracteres comodín, éste devolverá una colección de nombres de archivo y de carpeta que coincidirá con la ruta de acceso. Es parecido al cmdlet Get-ChildItem (es decir, los conocidos alias Dir o Ls), pero en lugar de devolver objetos enteros de archivo y carpeta, devuelve cadenas sencillas que pueden canalizarse a otros cmdlets para un posterior filtrado o procesamiento. Su uso es sencillo:
Resolve-Path C:\P*
Esta línea sencilla devolverá rutas de acceso como C:\Archivos de Programa, C:\Processes.txt, etc. La figura 3 muestra dos ejemplos de este cmdlet en uso.
Figura 3 Uso del útil, aunque poco conocido, cmdlet Resolve-Path
Figura 3 Uso del útil, aunque poco conocido, cmdlet Resolve-Path

Comience por el principio
Cuando esté listo para empezar a trabajar con el cmdlet del día, ejecute Gcm, un alias para Get-Command. Obtendrá una lista de todos los cmdlets que Windows PowerShell conoce, incluidos los que se han agregado mediante complementos como, por ejemplo, el shell de administración de Exchange Server 2007, las extensiones de la comunidad de PowerShell, etc. Simplemente escoja el primero de la lista (el mío era Add-Content) y lea la ayuda correspondiente:
Help Add-Content –full
Le interesa la ayuda completa, y no la ayuda breve predeterminada, para poder obtener una descripción completa de lo que hace cada parámetro, consultar algunos ejemplos del uso de cmdlets y averiguar otra información detallada. Tómese su tiempo para experimentar con el cmdlet. (Quizás le interese usar una máquina virtual para no hacer pruebas con su entorno de producción.) Le recomiendo que se tome 10 minutos cada día, aproximadamente a la misma hora del día, para que se convierta en un hábito. En muy poco tiempo, conocerá a la perfección toda la funcionalidad y las capacidades que puede ofrecer Windows PowerShell.

Don Jones es el principal gurú de scripting de SAPIEN Technologies y coautor de Windows PowerShell: TFM (SAPIEN Press, 2007). Puede ponerse en contacto con él en www.ScriptingAnswers.com.


 &#161;Hola, encargados del scripting!: El retorno de WinRM
¡Hola, encargados del scripting!
El retorno de WinRM
Los encargados del scripting

Cuando los encargados del scripting se embarcaron en crear una serie de dos entregas acerca de la administración remota de Windows® (WinRM), un problema importante pasó inmediatamente al primer plano: la seguridad. A fin de cuentas, nosotros, los encargados del scripting, estábamos bien enterados de los problemas que acompañaron el lanzamiento de la última entrega de la serie Harry Potter: se enviaron por error copias de los libros pedidas con antelación antes de la fecha oficial de lanzamiento del libro. (¿Eso resultó ser un problema? No, claro que no; la editorial simplemente pidió a la gente que no leyera el libro hasta la fecha del lanzamiento.)
Y eso sólo es el principio. El final del libro y de la serie se filtró totalmente antes de que los libros estuvieran disponibles. (Si todavía no ha leído el libro, esto es lo que sucede: resulta que Harry Potter es un mago o algo así.) Asimismo, de inmediato hubo copias digitalizadas de todas las páginas disponibles en Internet, a veces antes de que la autora J. K. Rowling ni tan siquiera las hubiera escrito. En resumen, fue un desastre de seguridad, y los encargados del scripting estaban decididos a no permitir que eso les sucediera a ellos. A fin de cuentas, si la gente tuvo tanto empeño en filtrar el final de la serie de Harry Potter, imagínese lo que no haría por tener acceso al final de la serie en dos partes de los encargados del scripting acerca de WinRM.
Afortunadamente, los encargados del scripting pudieron tomar medidas drásticas y guardar sus secretos, mejor dicho, el secreto. De acuerdo, esto fue principalmente debido al hecho de que no escribieron la segunda parte de esta serie hasta bastante después de la fecha tope para entregar el artículo. Pero qué le vamos a hacer, el encargado del scripting que escribe esta columna estaba de vacaciones durante el mes de agosto y, a diferencia de un porcentaje sorprendentemente elevado de empleados de Microsoft, él ni tan siquiera mira un equipo mientras está de vacaciones, así que mucho menos usarlo.
Bueno, digamos que rara vez mira (ni usa) el equipo incluso cuando no está de vacaciones. Pero ésa es otra historia.
En todo caso, sabemos que muchos de ustedes no han podido dormir durante las últimas cuatro semanas, agitándose, dando vueltas inquietos y preocupándose por cómo acabará la saga de WinRM. Bien, la buena noticia es que esas semanas dolorosamente largas de expectativas insomnes han pasado. He aquí, como primicia, la emocionante conclusión de la serie en dos partes de los encargados del scripting acerca de WinRM. Bueno, en realidad, está todo ahí, en la figura 1.
Figure 1 El desenlace (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

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

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

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

Do Until objResponse.AtEndOfStream
    strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom")
    objXMLDoc.async=False
    objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement
    Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue
    Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue
    Wscript.Echo
Loop
Sí, lo sabemos: el espectacular e inesperado giro de la trama también nos ha provocado a nosotros escalofríos que suben y bajan por nuestras espinas dorsales. objElement.ChildNodes(0).ChildNodes(0).NodeValue! ¿Quién lo iba a imaginar? Ya está: eso es porque, como parte de nuestro bloqueo de seguridad, incluso los propios encargados del scripting no tenían la menor idea de cómo terminaría la serie. Pero ahora el secreto ya se conoce.
Antes de continuar, vamos a recapitular rápidamente la serie en su totalidad, por si acaso hubiera alguien por ahí que inexplicablemente no haya leído la parte 1 (que se encuentra disponible en technetmagazine.com/issues/2007/11/HeyScriptingGuy). En la parte 1, presentamos WinRM, una tecnología nueva, que se encuentra en Windows Server® 2003 R2, Windows Vista ® y Windows Server 2008, y facilita sobremanera la administración de equipos por Internet, incluso a través de firewalls. Hay que reconocer que el Instrumental de administración de Windows (WMI) siempre ha tenido la capacidad de administrar equipos de forma remota; sin embargo, WMI se basa en COM distribuido (DCOM) como tecnología de administración remota. Eso es perfecto, sólo que, de forma predeterminada, muchos firewalls bloquean el tráfico DCOM. También es cierto, puede abrir los puertos adecuados y permitir el tráfico DCOM, pero muchos administradores de red se muestran reacios a hacerlo; su mayor preocupación es que, al abrir la puerta a DCOM también se abrirá la puerta a todo tipo de travesuras malintencionadas.
De ahí WinRM, "la implementación de Microsoft del protocolo WS-Management, un protocolo estándar basado en SOAP y compatible con firewalls que permite la interoperación de hardware y sistemas operativos de distintos fabricantes". Lo que es una manera extravagante de decir que ahora puede llevar a cabo la administración remota mediante protocolos estándar de Internet, como HTTP y HTTPS.
Como observamos el mes pasado, WinRM facilita la conexión y la recuperación de información WMI de equipos remotos. ¿Esto significa entonces que es una tecnología absolutamente perfecta? Bueno, no, no exactamente. Como señalamos, cuando WinRM devuelve los datos al script de llamada, esos datos regresan en formato XML. Obviamente XML puede ser un poco complicado de analizar y usar, sobre todo para administradores del sistema con una experiencia limitada en ese ámbito. Por ello, WinRM se entrega con una transformación XSL que convierte los datos devueltos a un formato más legible.
Sería fantástico, si no significara también que su salida siempre tendrá un aspecto parecido a éste:
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
Eso no es necesariamente algo malo, si no fuera porque también significa que su salida siempre se escribirá en la ventana de comandos; de forma predeterminada, no puede guardar fácilmente datos en un archivo de texto, escribir esos datos en una base de datos u hoja de cálculo de Microsoft® Excel®, ni hacer mucho más con los datos que no sea mostrar la información en pantalla. Eso no es lo bastante bueno.
Encima, el problema se agrava si opta por devolver únicamente un número seleccionado de propiedades para una clase WMI (algo que puede hacer para ayudar a reducir el tráfico de red). Cuando se trabaja con solo unas pocas propiedades de una clase (en contraposición a todas las propiedades de una clase), se obtiene una salida parecida a ésta:
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Interesante, pero en lo estético no se trata de la presentación de información más agradable que se haya visto (especialmente el encabezado XmlFragment que aparece en todo el informe).
¿Y qué se puede hacer con esto? ¿Escribir código personalizado para analizar y dar formato a esos datos XML? No parece algo a lo que suela dedicarse un creador de scripts de administración del sistema. ¿O sí?

Si quiere algo bien hecho, hágalo usted mismo
Resulta que trabajar con los datos XML sin formato devueltos por WinRM no es ni por asomo una tarea tan desalentadora como pueda parecer. Este mes le mostraremos una manera sencilla de analizar datos XML y darles formato. El enfoque que usaremos no es ni mucho menos la única manera de trabajar con XML, pero eso está bien; nuestro objetivo principal es simplemente demostrar que no tiene que depender de la transformación XSLT. Una vez captada esa idea básica, perfecto; a partir de ahí, todo es posible en cuanto a lo que se puede hacer con datos de WinRM.
Y aquí hacemos una trampa sin importancia: para que esta columna quepa en el espacio asignado, nos saltaremos la mayor parte del script que le acabamos de mostrar en la figura 1. Sin embargo, no creo que ello plantee mayores problemas porque los primeros dos tercios del script se describieron con todo detalle en la columna del mes pasado. Nos centraremos en el último tercio del script, que es la parte donde realmente se trabaja con los datos devueltos.
Como puede ver, este episodio de las crónicas de WinRM reanuda la acción después de haber creado una instancia del objeto WSMan.Automation, de haber consultado un equipo remoto (en este caso, atl-fs-01.fabrikam.com) y de haber recibido información acerca de todos los servicios que se ejecutan en ese equipo. Esto nos lleva a la línea del script donde establecemos un bucle Do Until para leer y procesar los datos XML devueltos; este bucle continuará hasta que no quede nada por leer y procesar. (O, para que suene como si supiéramos de lo que estamos hablando, este bucle continuará hasta el momento en que la propiedad AtEndOfStream del archivo XML sea True).
Esa es la línea de código de la que hablamos y aquí es donde empieza la historia de este mes:
Do Until objResponse.AtEndOfStream
Dentro del bucle, lo primero que hacemos es usar el método ReadItem para leer la primera sección de los datos XML devueltos. (Puesto que estamos trabajando con WinRM y estamos recuperando información de servicio, esta primera sección constará de todos los datos devueltos para el primer servicio de nuestra colección). Después de almacenar esos datos (que, de nuevo, están en formato XML) en una variable denominada strXML, creamos una instancia del objeto Microsoft.XMLDom. De hecho, eso nos da un documento XML en blanco con el que podemos trabajar:
Set objXMLDoc = _
    CreateObject("Microsoft.XMLDom")
Tan pronto como nuestro documento en blanco esté listo, estableceremos el valor de la propiedad Async en False y después llamaremos al método loadXML.
Esto nos lleva a... ¿qué ha dicho? ¿Por qué establecemos el valor de la propiedad Async en False? ¿Y por qué llamamos al método loadXML? Buenas preguntas; ¡ojalá se nos hubieran ocurrido a nosotros!
Para empezar, la propiedad Async indica si el script permite una descarga asincrónica de información XML. Si esta propiedad es True, la descarga se iniciará y el control se devolverá de inmediato al script, incluso si la descarga no se ha completado. Hay que reconocer que parece lo más acertado. Por desgracia en ese caso el script avanzará como si tuviera toda la información que necesita. Y si no tiene toda la información que necesita, pues el desastre será inevitable. Por eso establecemos la propiedad Async en False.
Nota: De acuerdo, se podría escribir código para supervisar periódicamente el estado de la descarga, garantizando así que el script no se precipite prematuramente. Eso funciona, pero un enfoque bastante más fácil es establecer el valor de la propiedad Async en False. Cuando se hace, el script se bloquea hasta que la descarga se haya completado; es decir, una vez que empieza la descarga, el script esperará pacientemente a que ésta termine antes de hacer nada más.
En cuanto al método loadXML, hace lo que el nombre sugiere: carga un documento XML bien formado (o un fragmento de documento) en nuestro documento en blanco. Todo lo que hay que hacer es llamar al método loadXML, pasando la variable strXML como único parámetro del método:
objXMLDoc.loadXML(strXML)
¿El resultado final? Ahora hemos convertido nuestros datos de WinRM en un documento XML virtual. Y eso significa que podemos empezar a usar los métodos XML estándar para analizar ese documento virtual.
Llegados a este punto, debemos usar la siguiente línea de código para crear una referencia de objeto al elemento raíz en el archivo XML:
Set objElement = objXMLDoc.documentElement
Ahora ya estamos listos para divertirnos un poco. (Suponiendo, por supuesto, que su idea de diversión sea analizar un archivo XML. Eso es, sin duda alguna, lo que nosotros, los encargados del scripting, consideramos diversión).
Como quizá recuerde, nuestra consulta del lenguaje de consulta de WMI (WQL) (o usando terminología de WinRM, nuestro filtro) tiene este aspecto:
strFilter = "Select Name, DisplayName " & _
  "From Win32_Service Where State = 'Running'"
Como puede ver, hemos solicitado dos propiedades de la clase Win32_Service: Name y DisplayName. (Hemos incluido también una cláusula Where que limita los datos devueltos a los servicios que se están ejecutando. Sin embargo, eso no es nada por lo que tengamos que preocuparnos ahora mismo). ¿Es importante que hayamos solicitado dos propiedades? ¿Es importante el orden de esa solicitud? Puede ser. ¿Cómo demonios vamos saberlo?
Ah, buena pregunta. Quizá, como autores de este artículo deberíamos saber las respuestas a esas preguntas. Está bien. Resulta que sabemos que la respuesta a ambas preguntas es sí. ¿Es importante que hayamos solicitado dos propiedades en nuestra consulta de WQL? Sí, lo es; a fin de cuentas, serán los únicos valores de propiedad que se nos devuelvan. (A diferencia de hacer una consulta Select * From, que devuelve valores para todas las propiedades de una clase).
¿Entonces, el orden de esas dos propiedades también es importante? Por supuesto que sí. El orden con el que especificamos los nombres de propiedad es el mismo orden con el que se devuelven los valores de propiedad. Eso es importante porque cada valor de propiedad se devolverá como nodo (o sección) secundario de nuestro elemento raíz. ¿Qué valor de propiedad se devolverá como primer nodo secundario? Eso es una pregunta fácil. En este caso, el primer nodo secundario será la propiedad Name, porque es la primera propiedad enumerada en nuestra consulta de WQL. ¿Qué propiedad se devolverá como segundo nodo secundario? Es cierto, será la propiedad DisplayName, porque es el segundo elemento enumerado en nuestra consulta.
Espere un segundo. ¿Lo ha resuelto usted solo o alguien le ha filtrado la información de esta columna por adelantado? Hmmmm...
En todo caso, esto facilita la devolución del valor de la propiedad Name. Lo único que queda es hacer referencia a NodeValue del primer elemento (elemento 0) en la primera colección de ChildNodes (elemento 0), de este modo:
Wscript.Echo "Name: " & _
objElement.ChildNodes(0).ChildNodes(0).NodeValue
¿Y cómo hacemos referencia al valor de la propiedad DisplayName? En este caso, hacemos referencia al NodeValue del primer elemento en la segunda colección de ChildNodes (elemento 1):
Wscript.Echo "Display Name: " & _
objElement.ChildNodes(1).ChildNodes(0).NodeValue
¿Y qué pasaría si tuviéramos una tercera propiedad (Status, por ejemplo) en nuestra consulta de WQL? Entonces, simplemente haríamos referencia al NodeValue del primer elemento de la tercera colección de ChildNodes (elemento 2):
Wscript.Echo "Status: " & _
objElement.ChildNodes(2).ChildNodes(0).NodeValue
Y así sucesivamente hasta llegar a la última propiedad.
Entonces, ¿qué aspecto tendrá nuestra salida de script ahora? Algo parecido a lo siguiente:
Display Name: Windows Event Log
Name: EventLog

Display Name: COM+ Event System
Name: EventSystem
De acuerdo, no tiene un aspecto tan diferente de la salida de WinRM predeterminada (aunque nos hemos deshecho de aquel encabezado tonto de XmlFragment). La diferencia es ésta: al trabajar con los valores de propiedad individuales, ya no estamos limitados al formato predeterminado (observe que usamos la etiqueta Display Name y no DisplayName), ni estamos limitados a mostrar información únicamente en la ventana de comandos.
¿Preferiría escribir estos datos en una hoja de cálculo de Excel? Eso es bastante fácil de hacer. Para empezar, inserte el siguiente bloque de código (que crea y configura una nueva hoja de cálculo de Excel) inmediatamente después de la línea en el script de WinRM que llama al método Enumerate:
Set objExcel = _
  CreateObject("Excel.Application")
objExcel.Visible = True
Set objWorkbook = objExcel.Workbooks.Add()
Set objWorksheet = objWorkbook.Worksheets(1)

i = 2
objWorksheet.Cells(1,1) = "Name"
objWorksheet.Cells(1,2) = "Display Name"
Ahora, reemplace el bucle Do Until original por el que se muestra en la figura 2. Inténtelo y verá lo que sucede.
Figure 2 Nuevo bucle Do Until (Close Figure 2)
Do Until objResponse.AtEndOfStream
  strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom")
  objXMLDoc.async=False
  objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement
  objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue
  objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue
  i = i + 1
Loop

¿WinRM, parte 3?
Entre la columna de este mes y la del último, debería tener suficiente para empezar con WinRM. Esperamos que sí; WinRM es una tecnología nueva y fascinante que promete hacer de la administración remota de sus equipos algo muy fácil (al tiempo que mantiene la seguridad). Lo que, por supuesto, conduce directamente hacia la pregunta que todo el mundo se plantea: ¿esto significa que habrá una tercera entrega de la saga de WinRM?
Lo siento, no podemos revelar esa información. No por problemas de seguridad, sino simplemente debido a que el proceso habitual de planeación y toma de decisiones de los encargados del scripting nos impide tener la menor idea de si escribiremos algo más acerca de WinRM. Como dicen ellos: ¡no deje de leernos!
Dr. Scripto's Scripting Perplexer
El doctor Scripto ha tenido un pequeño accidente. Dejó uno de sus scripts tirado por ahí (en vez de ponerlo, como buen creador de scripts, a buen recaudo) y tropezó con él sin querer, haciendo que los pedazos del script volaran por los aires. Se las ha apañado para encontrar todas las variables, palabras clave, símbolos y demás, y lo ha dispuesto todo por orden alfabético, pero ahora necesita volver a recomponerlo para lograr que el script esté de nuevo completo. Tiene para rato, pero espera tener la respuesta lista para cuando aparezca TechNet Magazine el próximo mes. Mientras tanto, no deje de intentarlo y vea si usted puede convertir este conjunto aparentemente aleatorio de pedazos de script en un script completo. ¡Buena suerte!
Pista: Bueno, un poco de ayuda no le vendrá mal. El script final eliminará todos los archivos del equipo local anteriores a una fecha especificada.

Dr. Scripto's Scripting Perplexer
Respuesta: El torpe doctor Scripto, diciembre de 2007
Sí, Dr. Scripto logró recomponer su script. Aquí está el script reconstruido que, además, funciona y elimina todos los archivos del equipo local anteriores a una fecha especificada:
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

Los encargados del scripting trabajan para Microsoft, mejor dicho, están contratados por Microsoft. Cuando no juegan al béisbol, ni entrenan ni lo ven (u otras actividades varias), dirigen el TechNet Script Center. Visite la página web www.scriptingguys.com.


 Vigilancia de seguridad: Directivas de contrase&#241;as de dominio de Windows
Vigilancia de seguridad
Directivas de contraseñas de dominio de Windows
Derek Melber

Si es administrador de un dominio de Windows, conocerá muy bien las restricciones relacionadas con las directivas de contraseñas para cuentas de usuario de dominio. Sin embargo, con la llegada de Windows Server 2008, algunas de esas limitaciones desaparecerán. Echemos un vistazo a la manera en que el nuevo sistema operativo resuelve un problema: la incapacidad de implementar varias directivas de contraseñas.
Si ejecuta cualquier versión actual de dominio de Windows® (Windows NT®, Windows 2000 Active Directory® o Windows Server® 2003 Active Directory), se ve limitado a una sola directiva de contraseñas por dominio. En realidad, la limitación no está únicamente en la directiva de contraseñas, sino en el ámbito más amplio de la configuración incluido en las directivas de cuentas. La figura 1 muestra estas directivas y la configuración.
Figure 1 Directivas de cuenta (Close Figure 1)

Directiva de contraseñas
Aplicar el historial de contraseñas
Vigencia máxima de la contraseña
Vigencia mínima de la contraseña
Longitud mínima de contraseña
La contraseña debe cumplir requisitos de complejidad
Almacenar contraseñas con cifrado reversible
Directiva de bloqueo de cuenta
Duración del bloqueo de cuenta
Umbral de bloqueo de cuenta
Restablecer recuentos de bloqueo de cuenta tras...
Directiva Kerberos
Aplicar restricciones de inicio de sesión de usuario
Vigencia máxima del vale de servicio
Vigencia máxima del vale de usuario
Vigencia máxima de renovación de vales de usuario
Tolerancia máxima para la sincronización de los relojes de los equipos
Esta configuración de directiva se aplica, de forma predeterminada, a todo el dominio y las cuentas de usuario asociadas al dominio. Esto ocurre debido al modo en que la directiva de grupo se hereda mediante la estructura de Active Directory. Para hacerse una idea más clara sobre el modo en que estas directivas afectan a las cuentas de usuario locales y de dominio, es importante comprender dónde se establecen estas directivas y cómo afecta la herencia de directiva de grupo a todas las cuentas de usuario diferentes. (Tenga en cuenta que la configuración de directiva de Kerberos sólo se aplica a cuentas de usuario de dominio, ya que son las únicas que usan Kerberos para la autenticación. En su lugar, las cuentas de usuario locales usan NTLMv2, NTLM o LM para la autenticación.)

Establecimiento de directivas de cuenta
Dentro de Active Directory, la directiva de grupo establece y controla las directivas de cuenta para todo el dominio. Esto ocurre en la instalación inicial del dominio de Active Directory y se realiza teniendo un objeto de directiva de grupo (GPO) predeterminado que está vinculado al nodo de dominio en Active Directory. Este GPO, denominado directiva predeterminada de dominios, tiene configuraciones predeterminadas para las tres secciones de las directivas de cuenta. La figura 2 muestra una lista completa de la configuración inicial de los elementos de la directiva de contraseñas en un dominio de Windows Server 2003.
Figura 2 Directivas de contraseñas predeterminadas para el dominio de Windows Server 2003
Figura 2 Directivas de contraseñas predeterminadas para el dominio de Windows Server 2003
La configuración en este GPO controla las directivas de cuenta para todas las cuentas de usuario de dominio, así como para todos los equipos del dominio. Es importante recordar que todos equipos del dominio (escritorios y servidores) tienen un Administrador de cuentas de seguridad (SAM) local. Este SAM se controla mediante la configuración en este GPO predeterminado. Como es obvio, los SAM locales también contienen cuentas de usuario locales para el equipo respectivo.
La configuración de la directiva predeterminada de dominios afecta a todos los equipos del dominio mediante la herencia normal de GPO por la estructura de Active Directory. Puesto que este GPO está vinculado al nodo de dominio, todas las cuentas de equipo del dominio también se verán afectadas.

Lo que no se puede hacer con las directivas de contraseña actuales
Existen varias ideas equivocadas sobre los controles de contraseña en torno a la implementación actual de Active Directory (en Windows Server 2003), pese a haber transcurrido años de pruebas rigurosas y no existir ninguna prueba que haya demostrado jamás que esas ideas equivocadas sean ciertas. Está claro, o debería estarlo, que esta directiva no funcionará en modos distintos al original, para el que se diseñó.
A pesar de lo dicho, muchos administradores creen que es posible tener varias directivas de contraseñas para usuarios en el mismo dominio. Piensan que se puede crear un GPO y vincularlo a una unidad organizativa (UO). La idea consiste en desplazar cuentas de usuario a la unidad organizativa para que el GPO afecte a los objetos. Dentro del GPO, las directivas de cuenta se modifican para crear una directiva de contraseñas más segura, quizás estableciendo la longitud máxima de la contraseña en 14 caracteres. Sin embargo, por varios motivos, esta configuración nunca ofrecerá el resultado deseado. En primer lugar, la configuración de la directiva de contraseñas está basada en equipos en lugar de en usuarios. Con esta base para la configuración, nunca afectarán a las cuentas de usuario. En segundo lugar, la única manera de modificar la configuración de directiva de cuenta para una cuenta de usuario de dominio radica en un GPO vinculado al dominio. Los GPO vinculados a la unidad organizativa que están configurados para modificar la configuración de directivas de cuenta modificarán el SAM local de equipos que residen en la unidad organizativa o que están en subunidades organizativas de la unidad organizativa vinculada.
Una segunda idea equivocada es que la configuración de directivas de cuenta establecidas en el dominio raíz (el dominio inicial del bosque de Active Directory) irá introduciéndose poco a poco o se heredará a través de los dominios secundarios del bosque. Esto tampoco es así y además no es posible hacer que la configuración funcione de esta manera. Los GPO vinculados al dominio y las unidades organizativas incluidas dentro de un dominio no afectarán a objetos de otro dominio, incluso si el dominio al que el GPO está vinculado es el dominio raíz. El único método para que la configuración de GPO abarque objetos en dominios diferentes es vincular los GPO a sitios de Active Directory.

Lo que guardan las contraseñas
Como acabamos de ver, las versiones actuales de Windows tratan las contraseñas de cuenta de usuario de una manera sencilla. Esto incluye un solo conjunto de reglas de contraseña para todas las cuentas de dominio, así como la administración de las directivas de cuenta a través de un objeto de directiva de grupo vinculado al nodo de dominio en Active Directory. Todo esto desaparece con la llegada de Windows Server 2008.
Windows Server 2008 y la infraestructura de Active Directory que incorpora, adoptan un enfoque diferente. En lugar de tener las directivas de cuenta en un GPO, lo que sólo permitía establecer una única directiva para todas las cuentas de usuario de dominio, ahora la configuración se ha desplazado a una parte más profunda de Active Directory. Además, las directivas de cuenta ya no se basan en cuentas de equipo. Ahora puede dirigirse a usuarios individuales y a grupos de usuarios para controlar sus restricciones de contraseña. Se trata de un concepto radicalmente nuevo para los administradores de Windows, ya que hemos estado tratando con directivas de cuenta para cuentas de equipo durante tanto tiempo.

Directivas de cuenta dentro de Windows Server 2008
En Windows Server 2008, no tendrá que establecer directivas de cuenta con la directiva predeterminada de dominios. De hecho, no tendrá que usar en absoluto GPO para crear directivas de cuenta para cuentas de usuario de dominio. En Windows Server 2008, se le dirigirá a la base de datos de Active Directory para que haga sus modificaciones. En particular, deberá usar una herramienta como ADSIEdit para modificar el objeto de Active Directory y sus atributos asociados.
El motivo de este cambio es que la directiva de grupo no está diseñada para varias contraseñas dentro del mismo dominio. La implementación de las capacidad de tener diversas contraseñas por dominio en Windows Server 2008 es elegante, aunque no tan sencilla como le gustaría a mucha gente. Sin embargo, con paso del tiempo será más fácil tener acceso a la interfaz para establecer la configuración. De momento, si quiere realizar cambios en el sistema tendrá que hacerlo manipulando las bases de datos de Active Directory.
No necesita usar ADSIEdit para modificar la configuración de directiva de cuenta si prefiere hacerlo de manera diferente. Puede usar cualquier otra herramienta de edición de LDAP que pueda explorar la base de datos de Active Directory o incluso usando scripts. Al implementar sus directivas de contraseñas en Windows Server 2008, deberá adoptar un enfoque muy diferente al que haya adoptado anteriormente. Las nuevas capacidades significan que deberá tener en cuenta los usuarios y grupos que recibirán cada configuración de contraseñas.
Se debe tener en cuenta no sólo la longitud de la contraseña sino también las restricciones adicionales que acompañan a la configuración de la directiva de contraseñas, como la antigüedad mínima y máxima, el historial, etc. Otras cuestiones relacionadas son cómo controlar la configuración de directivas de bloqueo de usuario y la configuración de Kerberos. Existe una relación de uno a uno entre la configuración actual de directiva de cuenta y la que está establecida en la base de datos de Active Directory en Windows Server 2008. Sin embargo, es importante tener en cuenta que los nombres de cada configuración de directiva son diferentes ahora que son objetos y atributos de Active Directory.
Para implementar la nueva configuración de contraseña, debe crear un objeto configuraciones de contraseña (PSO) denominado msDS-PasswordSettings en el contenedor de la configuración de contraseña, que tiene la ruta de acceso de LDAP de "cn=Configuración de contraseña,cn=Sistema,dc=nombrededominio,dc=com." Tenga en cuenta que el nivel funcional del dominio en el que está trabajando debe estar establecido en Windows Server 2008. En este nuevo objeto, deberá completar la información para varios atributos, como se muestra en la figura 3.
Figure 3 Atributos de la contraseña en Active Directory (Close Figure 3)

Nombre de atributo de Active Directory | Descripción del atributo
msDS-PasswordSettingsPrecedence | Establece lo que tiene prioridad en las situaciones en que un usuario es miembro de varios grupos con directivas de contraseñas diferentes.
msDS-PasswordReversibleEncryptionEnabled | Alterna si está habilitado el cifrado reversible.
msDS-PasswordHistoryLength | Determina cuántas de las contraseñas que intervienen deben ser únicas para poder volver a usar una.
msDS-PasswordComplexityEnabled | Establece el número y el tipo de caracteres necesarios en una contraseña.
msDS-MinimumPasswordLength | Establece la longitud mínima de una contraseña.
msDS-MinimumPasswordAge | Determina el tiempo que un usuario debe usar una contraseña antes de cambiarla.
msDS-MaximumPasswordAge | Determina el tiempo que un usuario puede usar una contraseña antes de que se le solicite cambiarla.
msDS-LockoutThreshold | Determina el número de intentos con error de la contraseña que se permitirán antes de bloquear la cuenta del usuario.
msDS-LockoutObservationWindow | Determina el tiempo a partir del cual se restablecerá el contador de contraseña incorrecta.
msDS-LockoutDuration | Determina el intervalo tiempo que estará bloqueada la cuenta tras provocar demasiados intentos con error de la contraseña.
Como puede ver, todas las opciones de directiva de grupo relacionadas con la configuración de directiva de cuenta están duplicadas como atributos. Tenga en cuenta que también hay una opción de prioridad; esto resulta esencial para implementar varias contraseñas en el mismo dominio, ya que seguramente surgirán conflictos y deberá existir un mecanismo para tratar con ellos.

Dirigirse a la configuración de la directivas de cuenta
Para cada objeto que cree, deberá rellenar todos los atributos para moldear la directiva de cuenta para cada usuario. Existe un atributo nuevo, msDS-PSOAppliesTo, que determina los objetos que recibirán el conjunto de la configuración de directiva. Se trata del atributo especial que le permite canalizar opciones específicas a usuarios específicos. La lista incluida en este atributo puede estar constituida por usuarios o grupos pero, igual que ocurre con todo al establecer una lista de control de acceso, es mejor usar grupos en lugar de usuarios. Los grupos son más estables, más visibles y generalmente mucho más fáciles de usar.

Ovaciones y aplausos
Durante muchos años todos hemos deseado poder usar varias contraseñas dentro del mismo dominio de Active Directory, y ahora podemos. Ya no se conservará el mismo nivel de seguridad a cada usuario de todo el dominio en lo que a contraseñas respecta. Ahora, por ejemplo, podrá tener usuarios normales con una contraseña de 8 caracteres y profesionales de TI (que pueden tener privilegios de administrador) con una contraseña más compleja de 14 caracteres.
Pasará algún tiempo hasta que se acostumbre a entrar la base de datos de Active Directory para establecer o modificar la configuración de directiva de cuenta. Sin embargo, afortunadamente, la nueva configuración imita el entorno con el que ya está familiarizado. Asegúrese de explorar esta nueva configuración tan pronto como tenga disponible Windows Server 2008, ya que seguro que será el primer conjunto de configuraciones que realice.

Derek Melber, MCSE, CISM, MVP, es un consultor e instructor independiente. Se dedica a educar y difundir la tecnología de Microsoft, centrándose en Active Directory, directivas de grupo, seguridad y administración de escritorio. Derek es autor de varios libros de TI, incluida la Guía de directiva de grupo de Microsoft Windows (Microsoft Press, 2005). Puede ponerse en contacto con él en derekm@braincore.net.


 Archivos del escritorio: Implementaci&#243;n de Windows en un mundo virtual
Archivos del escritorio
Implementación de Windows en un mundo virtual
Wes Miller

La informática virtual está en todas partes. Si aún no ha pensado en aprovecharlo, debería considerarlo. La virtualización reduce la dependencia del hardware, creando en esencia un nivel de abstracción propio y dejándole mover uno o más sistemas invitados, como Windows Server o sistemas operativos cliente de Windows, entre otros sistemas host.
La virtualización es, por supuesto, diferente de la emulación en que no imita el procesador del invitado. Representa simplemente los recursos del sistema host de una manera en la que los sistemas invitados pueden tener acceso a los mismos. Como resultado, los sistemas host son genéricos para los invitados. Generalmente, puede mover un invitado virtual de un sistema creado por un OEM a uno creado por otro OEM, el hardware del host normalmente no importa. Sin embargo, hay advertencias. Por ejemplo, si mueve un invitado de hardware con un procesador de un proveedor de CPU, como AMD, a otro, como Intel, podría tener problemas (dependiendo de la tecnología de virtualización que esté usando). Esto es porque la tecnología de cálculo virtual sólo pasa información del host al invitado y viceversa; no emula una CPU específica para el invitado (como lo hace, por ejemplo, Microsoft® Virtual PC cuando se ejecuta en un Macintosh basado en PowerPC heredado).
Sin embargo, la virtualización emula componentes de hardware clave para el invitado. Con más frecuencia esto se limita a las redes, a vídeo (generalmente un dispositivo muy restringido sin una GPU emulada avanzada) y a almacenamiento masivo. Todas estas combinaciones funcionan presentando uno o más tipos de dispositivos de software emulados al invitado. Ahora, si es asiduo de mi columna desde hace tiempo, advertirá que se trata de la misma lista de dispositivos de la que se ocupa Windows® PE. En virtualización, éstos son los mismos tipos de dispositivos que necesita tener con el objeto de que Windows haga realmente cualquier trabajo. De manera adicional, todas las tecnologías de virtualización deben emular un BIOS. Aunque éstas pueden emular también la Interfaz extensible de firmware (EFI), la selección limitada de sistemas operativos basados en EFI que existe hoy en día hace que su uso sea limitado. Toda esta emulación permite que los invitados virtuales puedan arrancar. El BIOS y cada uno de los dispositivos emulan un dispositivo real en el software y presentan ese dispositivo a los invitados. Esto significa que requieren los mismos controladores (no siempre controladores proporcionados por Windows) que requería el dispositivo real. Se trata de un concepto importante a tener en cuenta.
Aunque algunas tecnologías de virtualización también permiten a los dispositivos USB (o USB 2.0) interactuar con éstas, no me extenderé en la explicación de estas tecnologías en este caso. Aparte de estos dispositivos USB que requieren tanto controladores (impresoras, NIC inalámbricas USB, etcétera) como cierta compatibilidad con DirectX® (normalmente no presente en la mayoría de tecnologías de virtualización), no hay mucho que tenga que hacer para que funcionen. Tenga en cuenta que la compatibilidad con los dispositivos USB u otros dispositivos no emulados depende, por supuesto, de la tecnología de virtualización que esté usando. Asegúrese de conocer las limitaciones (los sutiles límites, tal como me gusta llamarlos) del producto de virtualización que está usando antes de intentar obtener nuevos dispositivos con los que trabajar.
Hoy día hay dos proveedores principales de tecnología de virtualización en Windows: Microsoft y VMware (vmware.com). También hay otros proveedores como Parallels (parallels.com).
Ahora que tiene una idea de lo que es la virtualización, emplearé el resto de la columna en explicar cómo configurarla, cómo evitar los errores más comunes y cómo implementarla en diversos equipos de su entorno.

Implementación virtual
La implementación de sistemas virtuales no tiene por qué ser diferente a la de sistemas físicos. Pero como verá hay algunas buenas razones que la hacen diferente.
En los primeros tiempos de Windows NT®, la implementación se realizaba a través de la instalación. Podía redactar un script, pero debía ejecutar todo el proceso. Una vez que finalizaba la instalación, la copia de la imagen en varios sistemas, aunque fuera un concepto bastante útil, no era compatible.
No obstante, finalmente, Microsoft decidió que tenía sentido añadir compatibilidad con sistemas Windows NT "clonados" o de disco duplicado. Así pues, hoy en día, todos los métodos disponibles al implementar sistemas físicos están disponible también para la implementación de sistemas virtuales. Es posible usar: Winnt32 (o setup.exe en el caso de Windows Vista® y Windows Server® 2008); Windows PE (1.x o 2.x, dependiendo del cliente que esté implementando tal como se ha explicado en mis columnas anteriores); Servicios de instalación remota (RIS) o Servicios de implementación de Windows (WDS); o Sysprep (la herramienta de preparación del sistema para la implementación integrada en Windows NT 4.0) y su tecnología de duplicación de disco favorita (ImageX, por ejemplo).
Pero, por supuesto, esto sólo lo tiene que hacer la primera vez que implementa un sistema operativo específico. Después, si lo desea sólo tiene que copiarlo. Aunque hay un problema con los métodos de duplicación basados en disco como los que acabo de mencionar.

Uso de Sysprep
La decisión original de Microsoft de no hacer compatible la duplicación basada en disco estaba motivada principalmente por el Identificador de seguridad (SID) de Windows NT. Afortunadamente, Sysprep proporciona una solución. Pero, en primer lugar, observemos el problema que resuelve. Tal como se explicó en support.microsoft.com/kb/314828, el SID consiste en un número de revisión de la estructura de SID (generalmente un Identificador único global o GUID) que identifica un equipo individual basado en Windows. Este identificador se usa, a continuación, en la parte de raíz del identificador para todas las cuentas locales. Las cuentas locales tienen su propio identificador único, llamado Identificador relativo (RID). El RID consiste en un identificador de cuenta concatenado con el final del SID. Así pues, la combinación de las dos se convierte en el identificador de las cuentas locales.
Veamos por qué esto es un problema usando el SID de administrador S-1-5-21-191058668-193157475-1542849698-500. Aquí, S-1-5 es el descriptor que indica que esto es un SID (la S está omnipresente en la representación textual de un SID) y 1 y 5 representan el número de revisión de SID de Windows NT y el valor de identificador de autoridad (aquí Windows Security), respectivamente. El resto es el SID real, incluido 500, que identifica esto como un SID muy conocido, la cuenta de administrador de Windows. La cuenta de administrador creada de forma predeterminada (y que no puede ser eliminada) en todas las instalaciones de Windows tiene un SID que termina en 500. Las cuentas de usuario local se agregaron a Windows una vez que la instalación comenzó la iteración sobre 1000.
PSGetSID, disponible en Windows Sysinternals (mencionado en mi columna en PSTools en technetmagazine.com/issues/2007/03/DesktopFiles), le permite enumerar un SID para un usuario determinado en un sistema o el SID del sistema. Consulte la figura 1 para ver la salida de PSGetSID para el SID de mi sistema virtual y el SID de mi cuenta de usuario, 1003.
Figura 1 La salida de PSGetSID de un SID de sistema virtual y el SID de la cuenta de usuario 1003
Figura 1 La salida de PSGetSID de un SID de sistema virtual y el SID de la cuenta de usuario 1003
Puesto que los RID de cuenta local se basan en este SID, el problema que ocurre cuando realiza una duplicación de disco de un sistema o simplemente copia una imagen de equipo virtual debe ser relativamente aparente. Si no cambia el SID (la tarea principal de Sysprep pero no la única), terminará con una copia del componente clave que hace de un sistema de Windows algo único. Si ambos Sistemas, tanto A como B, tenían el mismo SID de administrador, los usuarios en cada uno de los sistemas se identificarían a sí mismos legítimamente como el mismo usuario. Lo mismo sería verdad de todas las cuentas locales del Sistema B al autenticar al Sistema A y viceversa. Lo que es peor, estos sistemas tendrán el mismo SID cuando se presenten en Active Directory®. Así pues, si permite al Sistema A autenticarse en un recurso de dominio, pero no se lo permite al Sistema B, provocará una colisión. Si configura B para que sea denegado, entonces A será denegado también.
Así pues, es muy importante que regenere los SID en sistemas que usan Sysprep, especialmente en escenarios de sistema virtuales ya que las imágenes de sistema se pueden propagar muy fácilmente. No debe usar una herramienta de cambio de SID de terceros, sólo Sysprep. Sysprep se ha diseñado, probado y es compatible con Microsoft para preparar los sistemas para la duplicación (incluso sistemas virtuales). Consulte la figura 2 para ver un ejemplo del aspecto de Sysprep antes de cambiar el SID en un sistema. Ahora asegúrese de que la opción "No regenerar identificadores de seguridad" está siempre desactivada si prepara el sistema para la duplicación como siguiente paso.
Figura 2 "No regenerar identificadores de seguridad" deben estar desactivada al prepararse para la duplicación.
Figura 2 "No regenerar identificadores de seguridad" deben estar desactivada al prepararse para la duplicación.
Además de actualizar el SID a un nuevo identificador, Sysprep modifica también cualquier almacén de datos privado que esté preparado para reflejar el SID y el nombre de equipo o para cambiar su cifrado para funcionar con el nuevo SID. Algunos ejemplos son el almacén de datos de Tareas programadas y valores en la metabase IIS (si IIS está instalado).
Sysprep también elimina forzosamente todas las NIC del sistema y se apropia de los datos de configuración de red para la NIC. Puesto que la configuración de red "depende" de la NIC en el registro y que la relación de esa NIC se basa en el identificador de hardware de la NIC (lo cual fuera de un movimiento de sistema virtual a virtual con frecuencia es probable que se interrumpa), Sysprep limpia estos datos normalmente abandonados.
Sysprep limpia también toda la información de pertenencia a Active Directory de un sistema. Como resultado, debe quitar forzosamente un sistema del dominio como parte de su trabajo. Esto asegura que los sistemas que acaban de recibir nuevos SID pueden unirse al dominio de manera segura. Algunas utilidades de cambio de SID le permiten cambiar un SID de máquina sin eliminarlo del dominio, pero esto tampoco es confiable ni seguro. Si está seguro sin ninguna duda de tener que ejecutar Sysprep en un equipo que sea un miembro de dominio, o lo quita del dominio antes de que Sysprep se ejecute o ejecuta Sysprep y le permite hacerse cargo de esa tarea por usted.
En una nota relacionada, si está virtualizando cualquiera de los controladores de dominio (DC), necesita duplicar sistemas que sean simplemente servidores independientes que no han sido aumentados a DC y no se han unido al dominio. A excepción de Windows Server 2003 Small Business Server Edition, no es posible duplicar de manera segura el disco de un DC. Para crear un DC de manera segura, debe crear una imagen de disco de un servidor que esté listo para ser unido al dominio y aumentado a un DC. Sysprep (excepto en la instancia SBS muy especializada, que es bosque único/servidor único), no está enterado de cómo cambiar de manera segura los SID en un DC.
Finalmente, además de cambiar el SID y eliminar el equipo del dominio, Sysprep cambia también el nombre del equipo.
Puede parecer abrumador decir que necesita realizar todas las tareas indicadas al crear imágenes (o sólo copiando) sistemas virtuales. Pero es muy importante, especialmente si usa estos sistemas en una red con otros sistemas físicos o virtuales, en un dominio, o con cualquier otra copia de sí mismos en la red.
Si no usa Sysprep para duplicar sistemas virtuales, casi con total seguridad encontrará una serie de problemas obvios (colisiones de Active Directory o de otras redes) y otros más inesperados. Por ejemplo, sus imágenes virtuales son muy susceptibles a los piratas informáticos puesto que piratear una otorgará acceso a las otras.

Niveles de abstracción de controladores y hardware
Mencioné que los dispositivos virtuales incluidos en una imagen virtual pueden no tener controladores incluidos para Windows. Asegúrese de tener controladores a mano para sus dispositivos al implementar (o al implementar imágenes de disco mediante Sysprep), pues el temido error de controlador 0x0000007B puede aparecer fácilmente al mover una imagen virtual desde un controlador de bus de almacenamiento a otro al igual que cuando se trabaja con hardware físico. Lo mismo se aplica a las NIC. Aunque la mayoría de los productos de virtualización han procurado ofrecer un dispositivo virtual bastante universal, quizás necesite un controlador adicional para el mismo.
No es posible tampoco omitir ese molesto nivel de abstracción de hardware (HAL). Lo ideal es crear equipos virtuales que sean compatibles con multiprocesadores de Interfaz avanzada de configuración y energía (ACPI) (consulte intel.com/technology/iapc/acpi), si eso es con lo que es compatible su tecnología de virtualización. Normalmente la conversión entre HAL no es compatible (consulte support.microsoft.com/kb/309283 para obtener más información sobre aspectos específicos). Sin embargo, algunas tecnologías de virtualización, o, lo que es más importante, muchas tecnologías de migración, prometen que pueden mover sin riesgos una instalación de Windows que no sea ACPI a una instalación ACPI, o viceversa. Esto no es cierto y, para que arranque, la instalación resultante de Windows no es compatible con Microsoft si encuentra problemas. Las mismas limitaciones tratadas en la página web de asistencia técnica que acabo de mencionar son ciertas para los sistemas virtualizados. Consulte la figura 3 si desea obtener un ejemplo del aspecto del HAL en el Administrador de dispositivos en uno de mis equipos virtuales, en este caso se ejecuta usando el HAL uniprocesador ACPI. No se debe confundir con procesador único, éste es intercambiable con su equivalente multiprocesador.
Figura 3 HAL en el Administrador de dispositivos en un equipo virtual
Figura 3 HAL en el Administrador de dispositivos en un equipo virtual

Cambios varios
Cambie lo que pueda y acepte lo que no pueda
A la hora de considerar la migración de física a virtual o viceversa, necesita recordar las cosas que puede y no puede cambiar. Puede cambiar los siguientes aspectos de una instalación de Windows:
  • La HAL (pero sólo de monoprocesador a multiprocesador o viceversa, siempre que se basen en la misma configuración de energía).
  • Controladores de almacenamiento masivo (esto no es fácil, pero la mayoría de las soluciones de migración de física a virtual intentan hacer esto por su cuenta). Tenga en cuenta que la mayoría de los proveedores proporcionan una solución de almacenamiento IDE y otra SCSI. Elija sabiamente cuando implemente, puesto que moverse de una a otra no resulta muy fácil. Generalmente, si elige SCSI podrá disfrutar de un dispositivo más confiable (éste es el caso con la mayoría de las implementaciones de emulación de dispositivos SCSI del proveedor).
  • Controlador de red (aunque en un escenario de migración virtual a virtual, esto será generalmente lo mismo con las tecnologías de un proveedor).
No puede cambiar los siguientes aspectos de una instalación de Windows:
  • El HAL (menos en el caso mencionado anteriormente, cuando la misma configuración de energía está en uso). No debe asumir que una solución de migración que hace esto tendrá como resultado una instalación de Windows que sea fija o confiable (y lo que es más importante, no será compatible con Microsoft).

Además de cambiar el SID y el nombre del equipo, necesita también cambiar ciertos valores que pueden ser específicos de la tecnología informática virtual que usa. En particular, necesita cambiar la dirección MAC (el identificador único para dispositivos de red). Además, muchas aplicaciones virtuales tienen también su propio identificador único. La mayoría los almacenan en sus propios archivos de configuración del equipo, por lo que deseará saber cómo manipular estas entradas (y mantener su validez). Tenga en cuenta que muchos productos de virtualización que son compatibles con el Entorno de ejecución previo al arranque (PXE) bloquean el UUID de SMBIOS según su propio identificador único, acentuando la necesidad de cambiar esto (o de permitir al software de virtualización cambiarlo por usted, si es compatible) si lo une a un dominio; de lo contrario, la administración de sistemas cliente WDS o RIS podría no ser posible (si los GUID se oponen). La mayor parte de las soluciones de virtualización con las que he trabajado puede tener graves problemas de red en el caso de direcciones MAC duplicadas; por lo tanto, si no está moviendo simplemente un equipo virtual, es muy importante que cambie la dirección MAC si el software de virtualización no lo hace por usted.
Otros componentes que necesita tener en cuenta al preparar un sistema virtual para la implementación son los discos o instantáneas vinculados. Dependiendo de su solución de virtualización, es posible referirse a los mismos como discos diferenciales, pero pueden tener otro nombre. Aunque si ejecuta Sysprep para preparar un sistema y tiene instantáneas (u otra condición reversible) que vayan con el sistema virtual, éstas deben destruirse para que la imagen permanezca segura y sea confiable cuando se duplique. En el caso de una instantánea u otro enfoque de tecnología "deshacer cambios del disco", revertir una instantánea podría significar un retroceso hacia donde más de un sistema originado desde el equipo virtual original entra en conflicto con otro (o incluso con el sistema de origen original si éste es devuelto). Así que cualquier relación de instantánea o de disco diferencial debe haber ejecutado Sysprep en ella.

Optimización
La mayoría de las tecnologías de virtualización incluyen complementos o herramientas para la máquina virtual que ayudarán a mejorar el rendimiento y la experiencia de interacción con el invitado del host. Normalmente se suelen incluir la optimización del mouse y la entrada del teclado, entre otras mejoras del rendimiento y, a menudo, incluye una interacción copiar y pegar mejorada (u otro tipo de host a invitado). Instale la versión más reciente de estas herramientas en sus sistemas virtuales antes de la implementación.
También necesita asegurarse de que la memoria de cliente se configura de manera óptima para el SO invitado, pero también en contexto con los hosts en los que se implementará. Lo último que desea hacer es implementar un conjunto de imágenes de Windows XP para usar 1 GB de RAM y hospedar sistemas que no tienen tanta RAM para empezar.
Recuerde también las limitaciones que la mayoría de las tecnologías virtuales tienen hoy día, por lo que es importante para sus usuarios interactuar con cualquier periférico adjunto al sistema virtual, así como qué aplicaciones funcionarán o no en el SO invitado (la mayoría no son compatibles con DirectX 9 ni 10, por ejemplo, ni son compatibles con las versiones anteriores de una manera limitada). Puede que los usuarios no sepan qué es lo que significa o cómo se manifiesta a sí mismo (algunas aplicaciones no tratan dicho error positivamente).

Preocupaciones relacionadas con el host
Tenga en cuenta que, en general, no hay mucho de lo que preocuparse con respecto al equipo host que ejecuta la tecnología de virtualización, a pesar de si lo que ejecuta de manera subyacente es un sistema operativo completo o un Hipervisor tipo 1 que se ejecuta directamente sobre el hardware. La mayoría de las tecnologías de virtualización se han diseñado para asegurar que el SO invitado no necesite saber nada (o muy poco) acerca del host. No obstante, asegúrese de conocer qué hosts están en uso en caso de que el invitado que se haya movido de un host a otro tenga problemas. Asegure también de conocer las limitaciones del producto de su proveedor de virtualización en ciertas plataformas. Aunque es posible moverse de uno a otro, puede perder o ganar ciertas características del Hipervisor tipo 2 del SO host (la aplicación de virtualización) en el proceso.

Otros mecanismos de implementación
Vínculos de Sysprep relacionados
Los documentos siguientes le ayudarán en gran medida con Sysprep:
  • Diseño de instalaciones basadas en imágenes con Sysprep
  • Cómo usar la herramienta Sysprep.exe para automatizar la correcta implementación de Windows XP
  • Cómo usar la herramienta de preparación del sistema (Sysprep.exe) para realizar una duplicación del disco
  • Uso de la herramienta de preparación de sistemas en equipos diferentes

El uso de Sysprep o de la duplicación de disco (o simplemente ejecutar Sysprep y copiar el equipo virtual) son las opciones obvias para implementar sistemas virtuales, pero hay otras. De hecho, tanto si usa la creación de imágenes o la instalación, el uso de Windows PE puede ser más fácil con la virtualización que con los equipos físicos puesto que trabaja con archivos ISO en lugar de un CD físico. Tenga en cuenta que algunas tecnologías de virtualización no pueden adaptarse bien a los medios de DVD, así que asegúrese de comprobar la compatibilidad con su proveedor de virtualización. Puede usar winnt32 o setup.exe (en el caso de Windows Vista o Windows Server 2008), pero no hay beneficios específicos. Si usa otras tecnologías de implementación de Microsoft tales como los Servicios de implementación automatizada, su tecnología de virtualización es compatible con PXE para iniciar una implementación basada en red, como si usara RIS o WDS.

Migración
Por último, aparte de migrar realmente un equipo completo, no se olvide de la Herramienta de migración del estado de usuario (USMT). USMT le permite mover una configuración de usuario de un cliente físico a un nuevo sistema virtual fácilmente. Así pues, si sus usuarios desean migrar sus datos y configuración anteriores a un nuevo equipo virtual, puede, por ejemplo, obtener fácilmente los archivos y configuración de Windows XP, almacenarlos en un UNC e insertarlos en un equipo virtual nuevo.

Wes Miller vive en Austin, Texas. Anteriormente, trabajó en Winternals Software, en Austin, y en Microsoft como director de programas y director de productos para Windows. Si lo desea, puede ponerse en contacto con Wes en la dirección technet@getwired.com.


 Notas de campo: El futuro fungible
Notas de campo
El futuro fungible
Romi Mahajan

El filósofo y economista Karl Marx escribió en uno de sus textos que "todo lo que es sólido se funde en el aire", refiriéndose a las relaciones cambiantes entre categorías sociales que trajo el auge de la industrialización y el capitalismo en el siglo XIX en Europa. Esta poderosa noción, según la cual divisiones y categorías nunca se fosilizan completamente, se reproduce en muchas formas y contextos, no menos en el mundo de la tecnología, un mundo en el que la única constante es el cambio.
En este sector de rápido movimiento, no hay mejor ejemplo de la velocidad del cambio (y el desafío que afrontamos a causa de ello) que en el auge de la tecnología para el consumidor. De hecho, las TI ha se han ido aproximando al consumidor y los principales indicadores del cambio encajan directamente en el mundo de lo personal, con repercusiones a gran escala tanto en el trabajo como en la vida. Este fenómeno adopta una serie de formas:
  1. El concepto de Web 2.0 se acerca al Internet de lectura/escritura; la escritura en Internet es prácticamente la función del escritor como consumidor.
  2. Las aplicaciones y las tecnologías de consumo crean un efecto de "aureola" para los negocios.
  3. La estructura del núcleo de Internet se está planeando y probando a causa de la aproximación al consumidor de las TI.
  4. Los equipos de TI, como los servicios de soporte técnico, deben planear, administrar y aprender de las líneas más bien difusas que distinguen las tecnologías para el uso personal y el uso empresarial.
  5. Las personas toman decisiones y estas personas son consumidores al mismo tiempo que profesionales.
  6. La tecnología "favorita" de una persona es casi siempre un producto de consumidor, no un producto de negocio.
Las implicaciones son profundas y las categorías son intercambiables, como se puede ver en unos pocos ejemplos. Un amigo mío en una compañía orientada a la tecnología me dijo que prácticamente un 8% de todas las llamadas al servicio de soporte técnico son a causa de actualizaciones de iTunes. Las notas del productos de Cisco "The Exabyte Era" comienzan con dos puntos: que Internet no se colapsa por las secuencias de vídeo y que YouTube es sólo el principio. Apple Corporation, obtuvo una cuota de mercado de casi el 10% en la venta de equipos portátiles al por menor durante marzo de 2007, según un informe de NDP Group, el efecto de aureola del iPod ha funcionado. Microsoft está realizando fuertes inversiones en áreas como juegos, música, fotografía digital y hospedaje de vídeo. Y finalmente, las compañías mantienen reuniones en Second Life.
Además, las marcas de tecnología han sido elevadas y han creado tendencia en un aire enrarecido de permanencia. Las personas "googlean" cosas, todos hablan del iPod, se ponen en "myspace" y juegan a la "Xbox ®". Se ha creado una conexión emocional entre las personas y sus tecnologías y el efecto de esta conexión funciona de forma transitiva desde la oficina, al hogar, de vuelta a la oficina y, a continuación, se extiende a las compañías que construyen esos dispositivos, aplicaciones, sitios web y comunidades. A medida que construimos percepciones, buenas, malas o neutrales, estas mismas percepciones viven con nosotros en nuestras encarnaciones personales y profesionales.
Lo que puede ser relevante para un individuo, por lo tanto, es un asunto complejo. Es necesario un cambio cultural fundamental si las compañías quieren estar a la altura del reto simultáneo de escalar sus mensajes, mostrar sentimiento de cercanía y preocupación por sus clientes. En una etapa anterior, antes de la especialización en funciones, los mensajes genéricos fueron la sustancia del marketing. De manera opuesta, en los últimos años, la mensajería "enfocada" ha hecho furor, permitiendo una precisión de láser con categorías tales como puesto laboral,, segmento de audiencia, tamaño de la compañía y tecnologías específicas. Lo que se ha perdido, sin embargo, es el hecho de que verdaderamente todo que es sólido se funde en el aire y atraer a las personas a través de sus encarnaciones personales/de consumidor es la manera, la única manera, de construir una conexión y llevar la delantera en la carrera.
Ser fungible significa ser intercambiable y carecer de distinciones rígidas entre categorías. En resumen, no podemos levantar muros entre nuestras nociones de tecnología de consumidor y negocio. La aproximación al consumidor de las TI ya está aquí y el futuro es realidad fungible.

Romi Mahajan es Director de marketing del equipo Technical Audience and Platform Marketing en Microsoft. Romi tiene varias publicaciones en diversos campos, incluidos política, medio ambiente, tecnología y sociología.


 Confidencial de Windows: Un joystick no tiene que ser un microondas
Confidencial de Windows
Un joystick no tiene que ser un microondas
Raymond Chen

Leí hace bastante poco la entrada de un blog de un compañero, Audio Fool, y me recordó un error que cometí hace muchos años y que ha continuado molestándome. Cuando se desarrollaba la interfaz del joystick con fuerza de respuesta DirectInput®, se invitó a los fabricantes de joysticks a las oficinas de Microsoft en Redmond, WA, para tratar los detalles de la interfaz propuesta y ofrecer alguna contribución propia.
Se resolvieron muchos asuntos durante las reuniones, pero el que se ha quedado en mi memoria fue un desacuerdo sobre si las fuerzas periódicas deberían expresarse como período o como frecuencia. Uno de los proveedores presentes estaba muy alterado porque su compañía ya había desarrollado un controlador que especificaba sus fuerzas periódicas en términos de frecuencia y no quería cambiarlo. Teniendo en cuenta que era una reunión para pulir los detalles de una nueva interfaz, ¿cómo podía un proveedor esperar salir de la reunión sin tener que hacer ningún cambio a su controlador?
Pero este proveedor se quejó tanto que finalmente cedimos y aceptamos usar la frecuencia en lugar del periodo para especificar la tasa de fuerzas periódicas. A fin de cuentas, daba igual de cualquiera de las dos formas. Una fuerza con una frecuencia de 10 oscilaciones por segundo es igual que una fuerza con un período de una décima de segundo. El período y la frecuencia son inversos el uno del otro.
Perdón, esto no es exactamente cierto. El período se expresó en milisegundos, lo que da un intervalo dinámico de 1 ms en un espectro de 50 días. Un período de 50 días es imperceptible en un calendario humano y un período de 1 ms es tan rápido que incluso ni se registra como un fenómeno periódico, en lugar de esto se percibe como un tono musical.
Por otro lado, la frecuencia se expresó en hertzios, lo que da un intervalo dinámico de 1 Hz a 4 mil millones de ciclos por segundo. ¿Piensa que es extraño reproducir música con su joystick? Imagínese fuerzas que generan ese intervalo en la banda de frecuencia de microonda.
El problema es que la potencia expresiva prácticamente inútil en el nivel superior del intervalo de frecuencia se producía a costa del valor más bajo. Resulta que los simuladores de vuelo son grandes seguidores de las fuerzas periódicas con periodos relativamente largos. Desconozco la física detrás de esto, pero me han dicho que uno de los efectos que tienen que controlar los pilotos es una fuerza periódica lenta en la barra de control en el orden de unos pocos minutos. El avión tiene una tendencia natural a viajar en una onda vertical de seno aritmético muy lenta y los pilotos tienen que tomar acciones para contrarrestar esta tendencia con el objeto de mantener el vuelo nivelado. Si la tasa de la fuerza se expresara por su período, el programa simulador de vuelo podría especificar un período de 120.000 milisegundos. Expresada en frecuencia, sin embargo, esto equivale a 0,0083 hertzios, lo cual es mucho más lento que la frecuencia más lenta que se puede expresar en la interfaz del controlador, a saber, 1 Hz. Por lo tanto, la fuerza más lenta que puede solicitar un simulador de vuelo es una que se repite cada segundo, que es todavía bastante rápido en relación al efecto físico que el simulador de vuelo desea imitar.
Como este problema no me ha abandonado después de todos estos años, recientemente consulté la documentación de la realimentación de fuerza. Para mi sorpresa, parece que la estructura DIPERIODIC usa el período en vez de la frecuencia para expresar efectos periódicos. (Y para una mejor medición, usa los microsegundos, lo cual implica que ahora puede reproducir música o pilotar un avión). O bien se corrigió el error o bien con los años mi memoria me está jugando malas pasadas. De cualquier forma, no tengo que preocuparme por este error nunca más, si es que realmente sucedió alguna vez.

Raymond Chen The Old New Thing, y en su libro homónimo (Addison-Wesley, 2007) se trata la historia de Windows y la programación de Win32. Ese color le queda bastante bien.