 TechNet Magazine February 2008

TechNet Magazine February 2008

SharePoint: Enfoque inteligente para recopilar datos en la empresa

La información es uno de los activos más importantes de una empresa. Pero administrar la montaña de datos que se recopilan a través del correo electrónico, formularios basados en la Web, encuestas y otros mecanismos, puede suponer un desafío. A continuación explicamos cómo Microsoft Office system puede ayudarle a integrar los sistemas y a que los datos sean más accesibles.

Keith Deshaies SharePoint: Creación de una infraestructura eficaz de encuestas

La recopilación y el análisis de datos son una parte importante de su empresa, pero para ello necesita herramientas que permitan que equipos independientes recopilen los datos que necesitan, cuando los necesitan. Descubra cómo puede usar WSS 3.0, MOSS 2007 e InfoPath 2007 para crear una solución de encuestas completa y flexible, que podrá usar en toda la empresa.

Jim Bradley SharePoint: Estandarice la administración de datos con tipos de contenido personalizados

El gran número de documentos diversos y otros contenidos almacenados en el global de una gran organización puede dificultar la administración de documentos, sus metadatos asociados y sus comportamientos de una manera centralizada y reutilizable. Compruebe cómo puede usar los tipos de contenido en SharePoint 2007 para simplificar la administración de contenido en toda la empresa.

Pav Cherny Office Communications Server: Cómo la presencia fortalece OCS 2007

Office Communications Server 2007 usa la información acerca de la disponibilidad del usuario para enrutar las comunicaciones al lugar más adecuado mediante el envío de una llamada de voz, una videoconferencia, un mensaje de correo electrónico o un mensaje instantáneo. Vea cómo OCS 2007 usa la presencia para conectar extremos.

Rajesh Ramanathan Office Communications Server: Planeación de la implementación de voz de OCS 2007

La integración de Office Communications Server 2007 con un sistema PBX existente puede ser una tarea desafiante. Debe seleccionar un escenario de integración, entender el enrutamiento de llamadas, conocer la forma de configurar las opciones del usuario, tratar los planes de números y mucho más. Pero no se preocupe. En esta información general se le mostrará lo que necesita conocer.

Jochen Kunert and Rui Maximo Sistemas de alto rendimiento: Introducción a Windows Compute Cluster Server

En vez de basarse en grandes sistemas especializados, los sistemas de alto rendimiento usan sistemas estándar de menor tamaño. Repartir la carga de trabajo de esta forma ofrece una solución económica para solucionar problemas complejos rápidamente. Explore la funcionalidad de los clústeres de cálculo y la asistencia que proporciona Windows Compute Cluster Server 2003.

John Kelbley and Doug Lindsey Adicional en línea: Implementación de 2007 Office system con Terminal Services

2007 Microsoft Office incluye cambios de diseño que debe conocer antes de implementarlo en su granja de servidores de Terminal Services. En este artículo se ofrece información general de los cambios.

James D. Silliman Nota del editor: Tratar la sobrecarga de informació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: Índices no clúster y retención de permisos

Saleem Hakani and Dan Carollo Utility Spotlight: ADMX Migrator

Con Windows Vista, el formato de las plantillas de directiva de grupo ha cambiado a una estructura basada en XML. La utilidad ADMX Migrator puede convertir los archivos ADM heredados al nuevo formato ADMX, así como ayudarle a crear fácilmente sus propios archivos ADMX personalizados.

Lance Whitney The Cable Guy: Autenticación de redes cableadas IEEE 802.1X

La autenticación IEEE 802.1X proporciona una barrera de seguridad adicional para el acceso a la intranet. Vea cómo Windows Vista y Windows Server 2008 facilitan la implementación de la autenticación IEEE 802.1X para la red cableada.

Joseph Davies Windows PowerShell: Permisos del shell

Por desgracia, los permisos de Windows son, por naturaleza, complicados. Aunque Windows PowerShell puede ayudarle. Obtenga una breve descripción de cómo funcionan los permisos en Windows y descubra cómo puede simplificar las tareas trabajando con ellos.

Don Jones ¡Hola, encargados del scripting!: ¡Los juegos ya están en marcha! Ah, y también algo de XML

Los encargados del scripting siguen con los Juegos de Scripting de 2008 y también muestran cómo crear, anexar y modificar documentos XML. A propósito, ¿ha oído hablar de los Juegos de Scripting 2008?

The Microsoft Scripting Guys Vigilancia de seguridad: Salto de islas: atenuación de las dependencias no deseadas

Las dependencias de seguridad no deseadas pueden exponer toda la red a los ataques. Descubra cómo funcionan las dependencias de seguridad para poder analizar las dependencias en su entorno y resolver los posibles problemas.

Jesper M. Johansson Archivos del escritorio: Arranque dual con Windows XP y Windows PE 2.0

Existe una serie de ventajas si se arranca Windows PE 2.0 desde la misma partición que Windows. Aprenda a realizar el arranque dual de Windows XP y Windows PE 2.0 desde la misma partición y explore los problemas que se pueden solucionar.

Wes Miller Notas de campo: Done su PC

Al donar y reutilizar el hardware antiguo, se evita que acabe en los vertederos y contribuye a conservar nuestro medio ambiente. Estas sugerencias le pueden ayudar a eliminar de forma eficaz los datos personales de su equipo antiguo con el fin de prepararlo para su reutilización.

Jim Lynch Confidencial de Windows: Recortar los recortes

A continuación se ofrece algo de historia acerca de cómo dos características que no gozaban de mucha popularidad han desaparecido.

Raymond Chen


 SharePoint: Enfoque inteligente para recopilar datos en la empresa
SharePoint Keith Deshaies

Enfoque inteligente para recopilar datos en la empresa
Resumen:
  • Recopilar y procesar datos
  • Separar la lógica de presentación de la lógica de la administración de la información
  • Usar las tecnologías de Microsoft Office 2007 para elaborar una solución de recopilación de datos
Descargar el código de este artículo: DataGathering2008_02.exe (567KB)

Las empresas recopilan inmensas cantidades de información mediante distintos métodos. Los datos llegan por correo electrónico, encuestas, formularios web y otros mecanismos de recopilación de datos. Por lo general, los datos
son positivos. Sin embargo, administrar la gran cantidad de herramientas de recopilación de datos y la diversa información resulta difícil. La integración confiable y el uso compartido seguro de los datos son desafíos constantes para las organizaciones de TI. Los estándares y las arquitecturas orientadas a servicios están evolucionando, lo que facilita a los profesionales de TI aumentar la accesibilidad a los datos de manera más segura. Pero aunque se dispone de las herramientas y de las tecnologías necesarias para crear una arquitectura empresarial eficaz, es muy habitual quedar atrapado en una red de interfaces patentadas, lo que desemboca en soluciones aisladas.
Tomemos como ejemplo las tecnologías disponibles en Microsoft® Office system. Puede crear rápidamente una encuesta departamental basada en Windows® SharePoint® Services 3.0, pero el que sea una solución estándar depende de su organización. Si su compañía usa ASP.NET y SharePoint como la plataforma para la colaboración y la integración de datos basadas en la Web, esta encuesta proporciona una solución estándar. Pero si su entorno es como en el que trabajo, SharePoint es sólo una de las muchas plataformas existentes.
Efectivamente, SharePoint ofrece muchas opciones para integrarse con sistemas de IBM, HP, Siebel, etc. Son buenas noticias para los usuarios avanzados que desean crear soluciones ad hoc y que los datos resultantes fluyan a distintos sistemas back-end. No obstante, si es arquitecto de soluciones, hay una solución incluso mejor: InfoPath® 2007.
Con InfoPath 2007, que forma parte de 2007 Office system, se puede separar la lógica de presentación de las soluciones de la lógica de la administración de la información hospedada en sus servidores. Con la tecnología de InfoPath basada en XML, puede crear soluciones de recopilación de datos preparadas para la empresa. Y en la mayoría de las ocasiones, los diseñadores de formularios InfoPath no necesitan un conocimiento detallado de XML, servicios web, arquitecturas de soluciones, ASP.NET o el modelo de objetos de SharePoint.
En este artículo, explicaré cómo se pueden crear soluciones flexibles para la recopilación de datos con InfoPath 2007, Office SharePoint Server 2007 y Forms Services. Y mostraré cómo XML permite separar la lógica de presentación de la lógica empresarial en una arquitectura empresarial de varios niveles.
Tenga en cuenta que cuando me refiero a "recopilación de datos", estoy denominando al proceso de recopilación de datos de procedencia humana. Evidentemente, existen otras formas de recopilar datos, como el rastreo de orígenes de datos, pero estos métodos automatizados están fuera del ámbito de este artículo.

Adquisición y tratamiento de datos
Los requisitos de adquisición de datos pueden ser complicados, pero estos procesos tienen algunos elementos en común. Si estas similitudes se tratan en módulos centralizados mientras los requisitos únicos se tratan en componentes descentralizados, se pueden limitar los esfuerzos redundantes, la sobrecarga de mantenimiento y el costo total de la propiedad.
Por ejemplo, las normativas de cumplimiento de las compañías públicas han derivado en requisitos de negocios que, a su vez, se traducen en directivas de administración de la información en toda la compañía. Estas directivas afectan a las soluciones de recopilación de datos que traspasan los límites departamentales y suelen duplicar los esfuerzos en cada departamento. Por ejemplo, las reglas acerca de la recopilación de información de identificación personal obtenida por un departamento de recursos humanos (tratamiento de la información de empleados) y un departamento de servicio al cliente (tratamiento de la información de clientes). Incluso los procesos de negocios entre departamentos individuales que son similares pero no están relacionados proporcionan oportunidades para unificar las soluciones de administración de la información.
En la Figura 1 se muestra un ejemplo de un proceso de negocios típico. Un empleado que desee intercambiar una asignación con un compañero, primero deberá obtener su conformidad, después la aprobación de un responsable o coordinador de la programación de asignaciones y, finalmente, del supervisor. Esto podría implicar a empleados que intercambian turnos de trabajo, por ejemplo. Aunque estos intercambios se producen en departamentos diferentes y pueden basarse en formularios distintos, los flujos de trabajo y la lógica de administración de la información se pueden compartir entre varias soluciones de departamento.
Figura 1 Ejemplo del proceso de recopilación de datos que puede compartirse entre los departamentos
Figura 1 Ejemplo del proceso de recopilación de datos que puede compartirse entre los departamentos
Como es lógico, la consolidación de los componentes redundantes es una tarea enorme. Impulsar cambios organizativos en una compañía no es tarea sencilla, pero con las tecnologías de Office system puede crear una base sólida que facilite dichos cambios. InfoPath 2007 permite que los departamentos individuales creen aplicaciones de formularios que se integren con sistemas de administración de la información centralizados y estandarizados. Mientras tanto, SharePoint 2007 permite que los departamentos de TI deleguen el control administrativo sobre colecciones, sitios y bibliotecas de documentos a departamentos individuales y equipos. Como consecuencia, los equipos pueden crear e implementar soluciones propias con una mínima intervención del departamento de TI, mientras dicho departamento mantiene el control de todos los servicios y componentes compartidos, como flujos de trabajo, directivas de administración de la información y procedimientos de copia de seguridad.

Centralización de los esfuerzos de recopilación de datos
Las empresas suelen asignar servidores de aplicaciones departamentales a los equipos para adaptar las necesidades individuales de administración de la información. El departamento de TI tan sólo es el responsable de mantener el hardware y el sistema operativo en funcionamiento, mientras que cada departamento se ocupa de todos los aspectos de sus soluciones. Hay poca coordinación entre los departamentos y, además, el uso compartido de la información resulta difícil.
Los desafíos técnicos para centralizar los esfuerzos de recopilación de datos giran principalmente alrededor de la seguridad, el rendimiento, el mantenimiento y el soporte técnico de componentes personalizados hospedados en un entorno compartido. Por ejemplo, las consecuencias de un componente que no funcione correctamente son aisladas si las soluciones individuales se hospedan en servidores de aplicaciones departamentales. No obstante, en un entorno compartido, un componente con problemas de funcionamiento puede afectar a los procesos de negocios a mayor escala. En consecuencia, el departamento de TI debe establecer directivas estrictas en relación con la implementación y el mantenimiento de componentes personalizados en sistemas centralizados.
El hospedaje de las soluciones departamentales de SharePoint en una granja de servidores central requiere la implementación y el mantenimiento de todos los componentes individuales de dichas soluciones departamentales en los servidores de aplicaciones centrales. Una solución puede basarse en tipos de campo personalizados para ampliar la interfaz de usuario de la solución con listas desplegables rellenadas desde los servicios web back-end. Otra solución tal vez puede basarse en elementos web para la misma finalidad mientras otra usa flujos de trabajo personalizados. Todas ellas están escritas en código administrado y se implementan como ensamblados de Microsoft .NET Framework.
Incluso mover una cantidad relativamente pequeña de soluciones SharePoint a una granja de servidores de aplicaciones central puede derivar en problemas difíciles de configuración y de soporte técnico. Si los ensamblados se deben implementar en la caché de ensamblados global (GAC, Global Assembly Cache), la seguridad se convierte en un problema porque los ensamblados se deben ejecutar con confianza total. Los componentes con programación deficiente pueden abrir el sistema a los ataques de inyección de SQL, XSS o de denegación de servicio. Se debe garantizar que los componentes pueden resistir la carga de trabajo típica, así como los picos de demanda y las operaciones de larga duración. Debe asegurarse de que los componentes no bloquean otros procesos, tratar los eventos sincrónicamente y que los componentes efectúan una validación de entrada confiable, para que los usuarios no puedan insertar instrucciones SQL o scripts en las columnas usadas para actualizar una base de datos o un sistema web remoto.
En resumen, el objetivo es remarcar una configuración de servidor segura y confiable basada en características de producto estándar. Al basarse en soluciones reutilizables y probadas exhaustivamente, puede evitar la trampa de crear numerosos componentes personalizados. Tiene sentido mantener el front-end descentralizado y el back-end centralizado. La clave es integrar los componentes de una forma escasamente acoplada que promueva la reutilización de las soluciones existentes.

Dividir la lógica empresarial
¿Cómo se crean soluciones flexibles para la recopilación de datos que se puedan configurar en los servidores? La mejor estrategia consiste en dividir la arquitectura de soluciones en niveles individuales, como se muestra en la Figura 2: almacenamiento de datos, lógica empresarial y presentación o IU. En la actualidad, la IU normalmente se basa en explorador mientras que la lógica empresarial se encuentra en servidores de aplicaciones web. Éstos, a su vez, tienen acceso a bases de datos y repositorios de datos no relacionales.
Figura 2 Solución empresarial típica basada en una arquitectura de tres niveles
Figura 2 Solución empresarial típica basada en una arquitectura de tres niveles
La lógica empresarial suele incluir la lógica de transacciones para garantizar que éstas se aplican de forma atomizada en los sistemas de administración de bases de datos. La lógica empresarial también puede integrar múltiples servicios de nivel intermedio mediante HTTP, colas de mensajes, RPC, etc. No obstante, la arquitectura de soluciones general permanece esencialmente como un modelo de tres niveles.
Lo que no se ilustra en la Figura 2 es la complejidad de la lógica empresarial en un entorno de negocios. Parece como si el servidor de aplicaciones de esta figura simplemente se centrara en representar un formulario basado en explorador y en el tratamiento de los datos enviados, pero dicha representación no tiene en cuenta los flujos de trabajo, el cumplimiento o los requisitos de administración de la información. Para atender estos requisitos, se debe dividir la lógica empresarial en dos: la lógica de presentación y la lógica de administración de la información. De este modo se pueden combinar los componentes de nivel intermedio según sea necesario sin volver a crear desde cero los componentes para cada solución.
En la Figura 3 se muestra esta arquitectura. En el centro están el contenido o los datos, rodeados por la lógica de administración de la información, que controla el contenido a lo largo de su ciclo de vida. La lógica de presentación interactúa con la lógica de administración de la información para proporcionar acceso a los datos mediante la interfaz de usuario.
Figura 3 Separar la lógica de presentación de la lógica de la administración de la información
Figura 3 Separar la lógica de presentación de la lógica de la administración de la información

Recopilación y procesamiento de XML
En entornos de aplicaciones orientadas a servicios (SOA, Service Oriented Application), XML es el estándar dominante que se usa para definir y compartir estructuras de datos entre los componentes. Por lo tanto, XML constituye una buena elección para la interacción entre los componentes de presentación y de administración de la información.
La comunicación se debe establecer de dos formas: se tiene que traducir el código XML en un documento legible para el explorador, así como el documento XML generado por el formulario. Hasta hace poco, la creación de aplicaciones de formularios basados en XML requería amplios conocimientos de programación. En especial, cuando los datos XML resultantes se tenían que ajustar a un esquema sectorial para facilitar el intercambio de información entre las organizaciones.
InfoPath 2007 facilita mucho el desarrollo de formularios basados en XML. Sin duda alguna, un conocimiento sólido de los detalles de XML resulta útil, pero los diseñadores de informes y los usuarios avanzados no necesitan ser magos de XML para crear aplicaciones de formularios basados en XML. El diseñador de formularios importa simplemente un documento o esquema XML en InfoPath y asigna los nodos de atributo y elemento individuales de dicho origen de datos a los campos del formulario. Un diseñador de formularios también puede empezar por un servicio web, una base de datos de SQL Server® o una plantilla en blanco y crear un formulario desde cero mientras InfoPath crea automáticamente el esquema subyacente y los enlaces de datos en segundo plano.
La estandarización de formularios mediante InfoPath y esquemas XML tiene varias ventajas. Si ya dispone de un esquema XML bien definido, los diseñadores de formularios y los desarrolladores de flujos de trabajo y componentes de administración de la información pueden crear soluciones a partir de las mismas estructuras de datos. Si un diseñador de formularios comienza desde cero, los desarrolladores deben esperar a que esté finalizado el formulario para ver de qué modo afecta a las estructuras de datos subyacentes. Una vez que las estructuras de datos están definidas, las soluciones futuras, como nuevas plantillas de formularios, pueden reutilizar flujos de trabajo y componentes de administración de la información existentes si se basan en las mismas estructuras de datos. Los flujos de trabajo y los componentes de administración de la información futuros pueden trabajar conjuntamente con formularios y datos existentes. Si crea soluciones de recopilación de datos basadas en esquemas sectoriales establecidos, los resultados son incluso más flexibles. De hecho, estas soluciones serán compatibles con soluciones creadas por otras compañías que usan los mismos esquemas.
He creado un esquema DirectReports simple que asocia los empleados a responsables. Los responsables pueden usar el formulario resultante para evaluar sus informes directos. Puede encontrar el esquema, el formulario y un archivo leame.htm con instrucciones para volver a crear el formulario en la carpeta Direct Reports en la descarga que acompaña a este artículo, disponible en technetmagazine.com/code08.aspx. El formulario es básico, pero ilustra el concepto general.
Un punto muy importante: no creé ninguna lógica de validación en InfoPath, aunque InfoPath requiere que se especifiquen el identificador de usuario y las direcciones de correo electrónico en un formato específico (dominio\cuenta y destinatario@domino.tld). De lo contrario, el documento XML resultante no es válido. Esto se debe a que el esquema XML define estos formatos. Puede guardar el formulario con datos no válidos pero no puede enviarlo, como se muestra en la Figura 4. He agregado una regla de envío ficticia al formulario para que pueda probarlo sin enviar realmente los datos a ninguna ubicación. La validación de InfoPath 2007 garantiza automáticamente que el formulario está rellenado por completo y sin estos tipos de errores.
Figura 4a Errores de validación que impiden que el usuario envíe un formulario
Figura 4a Errores de validación que impiden que el usuario envíe un formulario
Figura 4b Mensaje de error que se genera
Figura 4b Mensaje de error que se genera
El esquema XML actúa de contrato vinculante entre la lógica de presentación y la lógica de administración de la información. InfoPath bloquea el esquema para que el diseñador de formularios no pueda cambiar intencionadamente las estructuras de datos. Esto es importante porque al cambiar un esquema XML establecido se pueden ver afectadas las soluciones empresariales existentes, como los módulos de flujo de trabajo que se planean usar con la plantilla de formularios.
InfoPath proporciona una gran cantidad de características para crear una lógica de presentación avanzada en las aplicaciones de formularios. Puede consumir datos de archivos XML, servicios web, bibliotecas y listas de SharePoint, bases de datos, etc., para obtener valores predeterminados significativos. Puede cambiar los valores de campo según la selección del usuario mediante reglas, incluir lógica de validación, agregar código administrado para los requisitos de personalización más avanzados y usar Forms Service para que la plantilla de formulario sea accesible a través de la Web. En cualquier caso, los datos del formulario finalmente llegan a la lógica de administración de la información como un documento XML que cumple una definición de esquema.

Trabajar con XML o metadatos
Tal vez se pregunte si debe aplicar la lógica de administración de la información directamente al documento XML enviado o usar un analizador que extraiga la información requerida en metadatos. SharePoint es compatible con ambos enfoques. Los desarrolladores están acostumbrados a trabajar directamente con documentos XML, pero los metadatos ofrecen más flexibilidad.
Para demostrarlo, he creado un servicio web simple que analiza un documento XML pasado desde el formulario de informes directos que se muestra en la Figura 4a. En la carpeta XMLParsingWebService de la descarga adjunta se pueden encontrar el código fuente, los archivos de instalación y un archivo leame.htm con instrucciones paso a paso. El servicio web lee simplemente el identificador de usuario del responsable en el documento XML, divide el identificador de usuario en las partes de dominio y nombre de usuario, crea un mensaje basado en esas partes y, a continuación, produce una excepción genérica para devolver y mostrar la información procesada en forma de un mensaje de pseudoerror en el formulario de InfoPath. Se trata de una forma sencilla de mostrar un cuadro de diálogo en InfoPath después de haber enviado los datos. El servicio web funciona bien, pero si cambia el origen de datos subyacente (por ejemplo, si cambia el nombre del elemento OrgPerson por Manager en DirectReports.xsd y actualiza el formulario de InfoPath con el nuevo esquema tal como se indica en el archivo leame.htm), se produce un error en el servicio web. Pero no es de sorprender. Ahora el documento XML es distinto y la expresión XPath anterior para tener acceso al elemento user-id ya no es válida. Los esquemas OrgPerson y Manager son prácticamente idénticos, los formularios de InfoPath son idénticos y los resultados de procesamiento deseados son los mismos, pero aunque la diferencia es mínima, se deben implementar y mantener servicios web duplicados.
Éste no es un buen enfoque si se desean minimizar las repercusiones del código personalizado en los servidores de aplicaciones. Por el contrario, si se asignan los nodos XML a los campos de metadatos y se lleva a cabo el procesamiento en los metadatos, se pueden usar los mismos flujos de trabajo y lógica de administración de la información para estructuras de datos similares, aunque los esquemas XML sean distintos. Es necesario asegurarse de que el elemento secundario se asigna al campo de metadatos correcto y que el formato de datos cumple los requisitos de procesamiento. De este modo, se puede reutilizar el código existente.
La asignación de nodos XML a campos de metadatos es similar al enlace de nodos XML a controles de IU en un formulario de InfoPath, tal como se muestra en la Figura 5. En SharePoint, los campos de metadatos corresponden a las columnas definidas en el nivel de sitio o de lista, y se hace referencia a ellos en las definiciones de tipo de contenido. Los tipos de contenido definen las características de elementos de contenido, como campos de metadatos, flujos de trabajo y formularios. Para mantener los campos de metadatos de un tipo de contenido sincronizados con los nodos correspondientes del documento XML asociado, SharePoint se basa en un analizador XML integrado que realiza la promoción/degradación de propiedades. Durante la promoción de propiedades, el analizador XML extrae los valores de nodo de un documento XML en las columnas correspondientes de la biblioteca de documentos. La degradación de propiedades hace referencia al proceso inverso en el que los valores de columna se toman de la biblioteca de documentos y se escriben en el documento. La cuestión más importante es que el analizador XML mantiene sincronizados los campos de metadatos y los nodos XML asignados.
Figura 5 Asignaciones de esquema XML entre InfoPath y SharePoint
Figura 5 Asignaciones de esquema XML entre InfoPath y SharePoint
Cuando se usa el modelo de objetos de SharePoint, los elementos web, los flujos de trabajo y la lógica de administración de la información pueden trabajar con los campos de metadatos así como con los documentos XML subyacentes. Al cambiar el valor de un campo de metadatos asignado se cambia el valor de nodo en el documento XML y viceversa. Sin embargo, al trabajar directamente con el documento XML se acopla estrechamente la lógica empresarial con el esquema XML. Por otro lado, los campos de metadatos asignados aumentan la reusabilidad del código. Evidentemente, debe decidir el enfoque que resulta adecuado para su entorno, pero la mayor parte de las soluciones de SharePoint que se basan en campos de metadatos proporcionan más flexibilidad y más posibilidad de reutilizar el código.
Para ilustrar cómo SharePoint asocia nodos XML a campos de metadatos, incluí una característica de SharePoint en el material adjunto para el aprovisionamiento de una biblioteca de documentos personalizada (consulte el archivo OrgPersonContentType.xml que se encuentra en la carpeta OrgPersonLib de la descarga adjunta). El tipo de contenido OrgPerson hace referencia a cuatro campos: UserID, FullName, EMail y Direct_x0020_Reports. FullName y EMail son campos integrados. UserID y Direct_x0020_Reports son campos personalizados definidos en OrgPersonSiteColumns.xml.
Las definiciones de campo son bastante sencillas. Se pueden enlazar campos a nodos XML directamente en las definiciones de campo, aunque también se puede sobrescribir esta información en los tipos de contenido. Decidí usar esta última técnica porque me permitía usar los campos personalizados en tipos de contenido no relacionados con documentos XML así como en tipos de contenido basados en estructuras XML diferentes. El tipo de contenido OrgPerson enlaza los campos de metadatos a nodos XML que coinciden en su organización con el esquema OrgPerson que he explicado anteriormente. También hay un archivo llamado AdditionalContentTypes.xml que define más tipos de contenido que enlazan los mismos campos de metadatos a distintos nodos XML. Puede ver las diferencias si examina las expresiones XPath en los atributos Node.
Las bibliotecas de documentos del tipo OrgPersonLib pueden almacenar distintos tipos de documentos XML mientras que los valores de nodo se exponen a través de las mismas columnas de la biblioteca. Esta sencilla técnica de asignación también permite reutilizar flujos de trabajo y lógica de administración de la información, ya que los cuatro tipos de contenido (OrgPerson, Manager, Supervisor y User) hacen referencia a un conjunto común de campos de metadatos.
En la Figura 6 se muestra el elemento FieldRef del tipo de contenido OrgPerson para Direct_x0020_Reports, que asigna el campo a los nodos user-id de los informes directos según la expresión XPath, /OrgPerson/direct-report/user-id. Como el documento XML puede incluir varias entradas de informe directo, es importante especificar un atributo Aggregation. Esta acción define cómo el analizador XML tratará la colección de valores devuelta. Si omite este atributo, el analizador XML extrae sólo el primer valor de nodo. Los valores de agregación admitidos son sum, count, average, min, max, merge, plain text, first y last.
Figura 6 Campo de metadatos asignado a una expresión XPath
Figura 6 Campo de metadatos asignado a una expresión XPath
Todos los tipos de contenido de ejemplo usan la página upload.aspx estándar como el valor de DocumentTemplate, por lo que puede cargar los archivos XML en la biblioteca de documentos al hacer clic en el botón Nuevo en la IU de SharePoint. Tan pronto como cargue archivos con una extensión de nombre de archivo .xml, SharePoint invocará automáticamente el analizador XML integrado (una excepción son los archivos WordProcessingML, para los que SharePoint invoca un analizador WordProcessingML). El analizador XML examina el archivo .xml cargado para determinar el tipo de contenido asociado. De este modo, puede extraer los valores de nodo de las ubicaciones especificadas en las definiciones de campo y realizar la promoción de propiedades. Puede comprobar este proceso al cargar el archivo OrgPerson.xml incluido en la carpeta OrgPersonLib\XMLFiles. La estructura de este documento XML coincide con las expresiones XPath especificadas en la definición de tipo de contenido de OrgPerson. Por consiguiente, SharePoint extrae los datos del archivo .xml, escribe los datos en las columnas de biblioteca correspondientes y muestra los datos en la página EditForm.aspx para que pueda comprobar y actualizar las propiedades de documento que no están marcadas como de sólo lectura. En la Figura 7 se muestra el formulario EditForm.aspx con los datos extraídos de OrgPerson.xml.
Figura 7 Formulario EditForm.aspx con datos extraídos
Figura 7 Formulario EditForm.aspx con datos extraídos
Si cambia los valores de identificador de usuario, nombre completo o correo electrónico en EditForm.aspx, SharePoint realiza la degradación de propiedades para cambiar los valores de nodo en el documento XML subyacente. Sin embargo, tenga en cuenta que SharePoint no impone las restricciones de esquema XML a menos que implemente la lógica requerida en el formulario.
SharePoint tampoco ejecuta la lógica de presentación de una aplicación de formularios. Por ejemplo, al cambiar el identificador de usuario, SharePoint no valida que el nuevo valor cumpla las convenciones de NetBIOS y no actualiza automáticamente los campos de nombre de completo y de correo electrónico para que coincidan con la nueva selección. Por lo tanto, debe marcar la columna correspondiente en la definición de contenido como de sólo lectura si el cambio de un campo puede provocar incoherencias. Esto obliga al usuario a usar la aplicación de formularios, como InfoPath para actualizar los datos. El analizador XML promocionará los cambios del documento XML a los campos de metadatos correspondientes en SharePoint.
En el ejemplo de OrgPersonLib, puede cargar cualquiera de los archivos .xml de la carpeta OrgPersonLib\XMLFiles. Los archivos .xml usan estructuras de datos muy distintas, pero SharePoint reconoce los tipos de contenido y promociona los valores de nodo correctos en las columnas de sitio. Esto se debe a que usé una instrucción de procesamiento en los archivos XML para asociar los documentos XML con sus tipos de contenido correspondientes. No obstante, el archivo OrgPerson.xml, no incluye esta información, pero esto no constituye un problema. Si SharePoint no puede asociar un documento XML a un tipo de contenido mediante una instrucción de procesamiento o la plantilla de documento, SharePoint usa el tipo de contenido predeterminado. En el caso de OrgPersonLib, se trata del tipo de contenido OrgPerson y, por lo tanto, el documento XML se analiza correctamente.
En la Figura 8 se muestra cómo se puede asociar un documento XML explícitamente con un tipo de contenido. La instrucción de procesamiento MicrosoftWindowsSharePointServices define ContentTypeID como 0x010100668E393E4F0EFF4294DBD202D5D8321D. Es el identificador del tipo de contenido User, tal como se ha definido en AdditionalContentTypes.xml.
Figura 8 Instrucciones de procesamiento y datos XML del archivo de muestra User.xml
Figura 8 Instrucciones de procesamiento y datos XML del archivo de muestra User.xml
El analizador XML procesa la instrucción de procesamiento MicrosoftWindowsSharePointServices y escribe el valor ContentTypeID en el campo de metadatos ContentType. Todos los tipos de contenido de SharePoint comparten este campo de metadatos porque está definido en el nivel raíz del tipo de contenido System. Si abre el archivo fieldswss.xml en un servidor SharePoint (se encuentra en la carpeta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields) y busca MicrosoftWindowsSharePointServices, podrá ver cómo SharePoint asocia la instrucción de procesamiento al campo ContentType. El atributo PITarget señala a MicrosoftWindowsSharePointServices (es la instrucción de procesamiento) y el atributo PIAttribute señala a ContentTypeID (que contiene el identificador del tipo de contenido User).

Asociaciones de tipo de contenido en InfoPath
Los aspectos técnicos del análisis de XML y las asociaciones de tipo de contenido intimidan a muchos diseñadores de formularios, pero InfoPath 2007 se ocupa de todos estos detalles fundamentales. El archivo leame.htm que acompaña a la muestra OrgPersonLib incluye instrucciones para publicar la plantilla de formulario de informes directos en SharePoint y crear un tipo de contenido que vuelva a enlazar con los mismos campos de metadatos (UserID, FullName, EMail y Direct_x0020_Reports). Puede agregar fácilmente el nuevo tipo de contenido a la biblioteca de documentos de OrgPersonLib en la IU de SharePoint. Pero el nuevo tipo de contenido señala la plantilla de formulario InfoPath como la plantilla de documento para invocar las aplicaciones de formularios al actualizar los documentos XML existentes. En la Figura 9 se ilustra cómo el asistente para la publicación en InfoPath simplifica la asignación de propiedades entre los valores de nodo XML y las columnas de sitio de SharePoint. Y, de nuevo, si asocia los valores de nodo a las columnas de sitio existentes, puede reutilizar los componentes de SharePoint existentes.
Figura 9 Asignación de propiedades en InfoPath 2007
Figura 9 Asignación de propiedades en InfoPath 2007

Conclusión
Recursos en línea adicionales
  • Blog del equipo de InfoPath 2007
  • Desarrollo y especificaciones de esquema de XML W3C
  • Introducción a los esquemas XML
  • Flujos de trabajo en Office SharePoint Server 2007
  • InfoPath 2007 Forms Services

Con las tecnologías disponibles en Office, los arquitectos empresariales pueden crear soluciones de recopilación de datos que promuevan la reutilización de código y el intercambio de información. InfoPath 2007 permite que los departamentos creen soluciones que puedan obtener información de varios orígenes y que los datos se puedan enviar a varios sistemas, como SharePoint. SharePoint también proporciona a los desarrolladores un amplio conjunto de servicios e interfaces web para crear flujos de trabajo y componentes de administración de la información. Si estos componentes se hospedan en servidores de SharePoint centralizados, los departamentos dispondrán de la infraestructura necesaria para crear sus propias aplicaciones individuales.
Mientras tanto, los departamentos pueden crear sus soluciones de recopilación de datos más rápidamente. Las normativas de cumplimiento y otros requisitos de negocios globales se pueden tratar en el nivel interdepartamental. La facilidad de mantenimiento y la confiabilidad del entorno de TI aumentan a medida que se reduce el uso de componentes personalizados en los servidores de aplicaciones.

Keith Deshaies es un escritor técnico independiente y analista de TI para una gran compañía de telecomunicaciones. Está especializado en tecnologías de Microsoft Office y SharePoint, y es miembro de la Sociedad para la comunicación técnica.
© 2007 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.


 SharePoint: Creaci&#243;n de una infraestructura eficaz de encuestas
SharePoint Jim Bradley

Creación de una infraestructura eficaz de encuestas
Resumen:
  • Planeación e implementación de una solución de encuestas
  • Recopilación y procesamiento de resultados de encuestas en bibliotecas de SharePoint
  • Administración de problemas de rendimiento y seguridad

No puede tomar buenas decisiones sin la suficiente información. No le puede frenar la indecisión; no cuando las decisiones influirán en su negocio. Esto siempre se aplica, tanto si está pensando en dónde celebrar una
fiesta para su equipo, como si está pensando en la reasignación del 50% de los recursos de la compañía para lanzar un nuevo producto. Pero, ¿cómo puede obtener esta información?
Las encuestas proporcionan un medio efectivo y económico para recopilar comentarios que puede ir desde el grado de satisfacción de sus clientes con sus oferta de productos, hasta si realmente gustaron sus canapés en la última reunión del equipo. Las encuestas proporcionan la información sustancial necesaria para lanzar futuros productos, sistemas y desarrollos y mejoras de procesos. La pregunta está en cómo puede usted, un profesional de TI, implementar un sistema de encuestas que recopile esa información y la almacene para que se use de un modo eficiente.
Es probable que ya disponga de una o varias de las herramientas necesarias para recopilar, estructurar y analizar este tipo de datos. Microsoft® Office 2007 proporciona estas herramientas y permite su uso de un modo muy sencillo. De hecho, dispone de numerosas maneras que puede usar para realizar una encuesta. La clave está en que el enfoque se adapte a sus necesidades concretas. Por ejemplo, las encuestas basadas en correo electrónico son una buena opción para tratar con datos improvisados y en tiempo real, siempre que su objetivo sea un grupo reducido de encuestados y no se trate de datos críticos. Para obtener más información, consulte la barra lateral que hay debajo de "Uso del correo electrónico para realizar encuestas rápidas". Las encuestas basadas en bases de datos, en cambio, constituyen una mejor opción para iniciativas más complejas que incluyen un grupo mayor de encuestados y que contienen datos esenciales. Consulte la barra lateral que hay debajo de "Creación de una solución de encuestas basada en bases de datos" para obtener más información acerca de este tema.
En este artículo, me centraré en otra solución más exhaustiva y flexible: las encuestas en línea basadas en SharePoint®. Este enfoque es apropiado tanto si se trata de datos críticos como si no, y con cualquier nivel de complejidad. Ya que las encuestas de SharePoint están basadas en la Web, se pueden completar por cualquiera que tenga acceso a un explorador web, incluso desde dispositivos móviles. Mediante las encuestas de SharePoint, podrá decidir si las respuestas deben ser anónimas o no, podrá obtener resultados en tiempo real y, además, tendrá acceso a herramientas de análisis.
Este tipo de encuesta se implementa mediante Windows® SharePoint Services 3.0 (WSS) con Forms Server e InfoPath® o mediante Microsoft Office SharePoint Server 2007 (MOSS) con Forms Services e InfoPath® (consulte la Figura 1 para obtener una descripción de todas estas tecnologías). Ya que los dos escenarios ofrecen básicamente la misma funcionalidad, centraré este debate en la última combinación. Para obtener una comparación exhaustiva de los productos SharePoint y sus funcionalidades, consulte la descarga de comparación de productos Microsoft Office SharePoint Server 2007 en office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx.
Figure 1 Tecnologías de Microsoft que permiten realizar las encuestas de SharePoint (Close Figure 1)

Tecnología | Descripción
Microsoft Office InfoPath 2007 | Microsoft Office InfoPath 2007 es una herramienta de creación de formularios y recuperación de información. Para obtener más información, consulte office.microsoft.com/infopath.
Windows SharePoint Services 3.0 | Conocido anteriormente como SharePoint Team Services, Windows SharePoint Services 3.0 sirve como base para la creación de aplicaciones ampliadas de SharePoint. Para obtener más información, consulte microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx.
Microsoft Office SharePoint Server 2007 | Microsoft Office SharePoint Server 2007 (antes SharePoint Portal Server 2003) proporciona una infraestructura de servidor que convierte los clientes de Office 2007 en generadores y consumidores de contenidos para las aplicaciones de SharePoint. Para obtener más información, consulte microsoft.com/sharepoint.
InfoPath Forms Services, Microsoft Office Forms Server 2007 | InfoPath Forms Services permite a los usuarios completar formularios de InfoPath en un explorador web sin la necesidad de instalar dicha aplicación, lo que hace que las encuestas sean compatibles con diferentes plataformas y exploradores. Forms Services requiere Windows SharePoint Services 3.0, aunque la misma funcionalidad también está disponible como un producto independiente denominado Microsoft Office Forms Server 2007. Para obtener más información acerca de Forms Services, consulte microsoft.com/ms540731. Para obtener más información acerca de Forms Server, consulte office.microsoft.com/en-us/formsserver/FX100490391033.aspx.

Planeación e implementación
Al diseñar una encuesta, debe tener en cuenta una serie de factores desde el comienzo. Esto conlleva prácticas de análisis con antelación, así que tómese su tiempo para desarrollar una planeación de encuesta realmente eficiente. En la fase de planeación inicial, definirá el espacio de problemas y el tipo de datos que desea recibir, determinará las tecnologías que debe usar y establecerá los requisitos administrativos y presupuestarios correspondientes. Entonces puede pasar a la implementación. El flujo de trabajo general consiste en diseñar un formulario de encuesta, publicarlo, recopilar y validar las respuestas, agregar datos y analizarlos, y, a continuación, elaborar informes con los resultados.
Generalmente, un flujo de trabajo de implementación de una encuesta incluye al menos un diseñador de encuestas, encuestados y un analista (como se muestra en la Figura 2). Por supuesto, los flujos de trabajo de las encuestas pueden tener grandes variaciones en su complejidad. Una encuesta dirigida a toda la empresa, por ejemplo, tendrá que pasar por varias rondas de ediciones de diseño y aprobaciones. Puede que use recordatorios automáticos dirigidos a los encuestados, quizás también ofrezca diferentes formas de soporte técnico y solución de problemas, así como vistas en tiempo real de los resultados para los responsables. Además, podrá disponer de un proceso claro para determinar y proporcionar el análisis final. Un flujo de trabajo complejo de este tipo necesita un sistema basado en la Web que ofrezca compatibilidad con características de flujo de trabajo y creación de informes.
Figura 2 Un flujo de trabajo de encuestas desde el diseño de formularios hasta el análisis de datos
Figura 2 Un flujo de trabajo de encuestas desde el diseño de formularios hasta el análisis de datos

Contenido de una solución exhaustiva
Hay una larga lista de requisitos clave que una solución de encuestas exhaustiva debe satisfacer. La solución debe permitir a los equipos individuales o unidades empresariales crear, divulgar y recopilar los resultados de las encuestas con una implicación mínima del departamento de TI; y no debe necesitar ningún conocimiento de programación. La herramienta de creación de formularios debe proporcionar una interfaz fácil de usar e intuitiva, al igual que un amplio conjunto de características que faciliten la canalización, la bifurcación y la lógica condicional. Y no hace falta decir que la herramienta de creación de encuestas debe adaptarse a todos los tipos de encuestas, con independencia de su tamaño o complejidad.
Además, la encuesta se debe ejecutar en un servidor web y se debe integrar con una base de datos SQL Server® mantenida de manera central, para eliminar la necesidad de que los departamentos individuales realicen el mantenimiento de las bases de datos SQL dedicadas. Cualquier encuestado que disponga de acceso a Internet debe ser capaz de completar la encuesta desde cualquier explorador compatible.
El proceso de la encuesta debe estar vinculado de una manera sencilla a los flujos de trabajo y debe cumplir con las necesidades individuales sin poner en peligro la seguridad. Y, para muchas organizaciones, la solución de encuestas también debe proporcionar compatibilidad con varios idiomas.
El uso conjunto de MOSS 2007, WSS 3.0 e InfoPath 2007 crea una solución integrada que cumple con todos estos requisitos. La Figura 3 muestra cómo se complementan los diferentes componentes en la pila SharePoint. Pero antes de detallar esta completa solución de encuestas, me gustaría echar un vistazo a lo que puede conseguir tan sólo con el uso de WSS. A continuación, le mostraré las ventajas añadidas que puede obtener si agrega MOSS e InfoPath a la receta.
Figura 3 Componentes de la pila SharePoint
Figura 3 Componentes de la pila SharePoint

Trabajo sólo con WSS
Incluso sin el resto de componentes, puede usar WSS para crear e implementar una encuesta. De hecho, WSS incluye una plantilla para encuestas que le facilita aún más el proceso. Para crear una encuesta, haga clic en Inicio | Todos los programas | Herramientas administrativas y seleccione Administración central de SharePoint 3.0. En la lista desplegable, seleccione Acciones del sitio y, a continuación, haga clic en Crear. Se muestra la página de creación, en la que aparece una serie de encabezados para bibliotecas, comunicaciones, seguimiento, listas personalizadas y páginas web. Debajo de cada encabezado hay una serie de opciones de plantilla. Debajo de Seguimiento, haga clic en Encuesta.
Llegado a este punto, WSS le guiará paso a paso a través del proceso de creación de la encuesta. Puede crear preguntas abiertas o cerradas y especificar si una pregunta se puede dejar sin responder. Incluso puede crear encuestas de lógica de bifurcación, que llevarán a los encuestados por diferentes recorridos, según las respuestas que proporcionen. Las encuestas pueden ser anónimas o, si es necesario, se puede identificar al encuestado. También tiene la opción de asignar un flujo de trabajo a la encuesta.
La encuesta está basada en el explorador, por lo que no necesita ningún software especial para crearla o completarla. Para completar la encuesta, los encuestados sólo tienen que ir al sitio de SharePoint y completar el formulario. Los permisos de acceso se heredan del sitio primario, pero se pueden editar de manera directa desde el menú de acciones de SharePoint. Las respuestas a las encuestas se guardan en el sitio de encuestas de SharePoint y los resultados se pueden ver en forma de listas o resúmenes gráficos, e incluso se pueden exportar a Excel®.
Insistimos en que esta solución (con el proceso que aparece en la Figura 4) se puede lograr sólo con WSS y ningún otro software adicional. Si asumimos que ya dispone de un sitio de SharePoint correctamente diseñado, un departamento individual debe ser capaz de crear e implementar una encuesta con muy poca ayuda, o ninguna, del departamento de TI.
Figura 4 Una encuesta basada en Windows SharePoint Services
Figura 4 Una encuesta basada en Windows SharePoint Services
Una limitación del proceso si sólo usa WSS surge en el momento en que una encuesta necesita personalización. WSS crea listas de encuestas mediante diferentes páginas ASPX predeterminadas (AllItems.aspx, DispForm.aspx, EditForm.aspx, NewForm.aspx, overview.aspx y summary.aspx). Aunque la personalización más allá de los parámetros inherentes de WSS es posible, la mayoría de las características provienen de componentes web que no están preparados para su modificación. Además, este tipo de solución se adapta mejor a encuestas que no necesitan integrar orígenes de datos externos, como el sistema ERP de su compañía.
Cuando necesite ampliar su solución de encuestas para que incluya una interfaz de usuario personalizada o para que integre orígenes de datos adicionales, debería considerar seriamente la solución que combina MOSS, WSS e InfoPath.

La solución de encuestas completa
MOSS incluye muchas características que permiten ampliar WSS, pero por ahora prefiero centrarme en un solo componente: InfoPath Forms Services. Con InfoPath Forms Services, el diseñador de la encuesta será el único que necesite instalar InfoPath en su equipo. El resto podrá obtener acceso a la encuesta a través de un explorador web.
En InfoPath, el diseñador selecciona la opción que permite que el formulario se complete mediante un explorador web. A continuación, InfoPath crea un formulario que se puede ver en cualquier explorador web compatible y estándar. Este formulario basado en la Web funciona del mismo modo que un formulario de InfoPath, a excepción de algunas características avanzadas de InfoPath (como las funciones de usuario, el texto en vertical, las acciones de cuadros de diálogo y los controles avanzados). El formulario se publica a continuación en una biblioteca de SharePoint o en una lista. Mientras tanto, otra característica de InfoPath, denominada Verificador de diseño, asegura que el formulario de la encuesta es compatible con InfoPath Forms Services.
No hay diferencia entre una biblioteca de formulario de InfoPath y una biblioteca de formularios habilitada para exploradores. En todos los casos, una plantilla de formulario es un archivo .xsn. InfoPath Forms Services muestra el formulario en un explorador o bien el archivo se descarga en el cliente y se muestra directamente en InfoPath. Si el diseñador de una encuesta tiene al menos permisos de colaborador para un sitio de SharePoint, podrá usar las bibliotecas de documentos de SharePoint para publicar plantillas de formulario.
Un encuestado que disponga de un explorador compatible puede completar la encuesta de InfoPath Forms Services. Las respuestas se devolverán sin problemas al servidor SharePoint. Dentro de SharePoint, los datos se pueden almacenar, analizar y compartir con total seguridad (mediante Excel, SQL u otras herramientas disponibles en la red). Todo este proceso se puede realizar con una intervención mínima del departamento de TI.

Problemas de devolución y rendimiento
Existen ciertos problemas potenciales de rendimiento. Por ejemplo, los formularios habilitados para exploradores se ejecutan en el contexto de una cuenta del sistema en el servidor SharePoint, lo que significa que si un formulario incluye código o conexiones de datos (como se muestra en la Figura 5), dicho código o conexiones de datos se ejecutan en el servidor, no en el cliente. Además, es posible que los formularios complejos necesiten devolver datos de manera frecuente al servidor, lo que aumenta la carga de trabajo de éste.
Figura 5 Solución de encuesta basada en InfoPath Forms Services con conexiones de datos adicionales
Figura 5 Solución de encuesta basada en InfoPath Forms Services con conexiones de datos adicionales
Cuanta más devolución usa una encuesta, mayor es la carga en los servidores web front-end. Sin embargo, hay veces en las que no se puede evitar realizar una devolución, como al implementar la bifurcación de respuestas. Para reducir al máximo los potenciales efectos adversos en el sistema, los diseñadores de la encuesta deben tener en cuenta los problemas de devolución y saber cuál es el mejor modo de implementar las encuestas en los casos en los que no se pueda evitar la devolución. Por ejemplo, los diseñadores deben usar encuestas con formato de asistente que devuelvan los datos al servidor cuando el usuario haga clic en el botón Siguiente. Así se reduce el número de devoluciones.
InfoPath Forms Services debe mantener el estado de todos los formularios activos en el servidor. El tiempo de espera predeterminado de la sesión es de 60 minutos, lo que significa que si una encuesta compleja necesita más de 60 minutos para completarse y no se producen devoluciones durante ese tiempo, la sesión se cerrará en el servidor. Los datos que se introducen pero no se envían se pierden, lo que provoca que el encuestado tenga que volver a empezar.
Estos errores aumentan su impacto si hay un gran número de encuestados trabajando al mismo tiempo en un formulario de encuestas, si dichas encuestas tienen orígenes de datos de gran tamaño o, incluso, si incluyen archivos adjuntos. Para obtener más información, consulte el artículo acerca de la mejora del rendimiento de los formularios de InfoPath 2007 que hay disponible en msdn2.microsoft.com/bb380251.

Consideraciones relativas a la seguridad
Aunque un debate más profundo acerca de la seguridad está más allá del alcance de este artículo, es importante destacar una serie de consideraciones acerca de la seguridad. Para los principiantes, SharePoint e InfoPath 2007 se suman a la iniciativa Informática de confianza adoptada por Microsoft a comienzos de 2002. Los formularios de InfoPath tienen tres niveles de seguridad posibles: restringido, de dominio y de plena confianza. De manera predeterminada, InfoPath determina y aplica automáticamente un nivel de seguridad recomendado al formulario.
La funcionalidad de firma digital puede ayudar a asegurar que un formulario se cree o se complete por un usuario concreto y que no sufra modificaciones. La tecnología Information Rights Management (IRM) también restringe el acceso a las plantillas y a los formularios completados. Para evitar que usuarios malintencionados carguen formularios que contengan código peligroso o que usen la plataforma SharePoint para iniciar ataques contra otros sistemas mediante las conexiones de datos, InfoPath establece una distinción entre los formularios implementados por usuarios y por administradores. Los usuarios pueden cargar formularios siempre que éstos no contengan código personalizado y sólo usen el nivel de seguridad de dominio, que limita las conexiones de datos entre dominios. Estos parámetros son suficientes para la mayoría de soluciones de encuestas.
Si el diseño de una encuesta requiere el nivel de plena confianza para permitir un acceso sin restricciones a los recursos, la publicación del formulario necesitará aprobación por parte del departamento de TI. De manera predeterminada, la aprobación por parte del departamento de TI se necesita si un formulario contiene código administrado, si se definen conexiones de datos entre dominios en la plantilla del formulario, si el formulario usa conexiones de datos definidas en la biblioteca de conexiones administrada de manera central o si, finalmente, se ha habilitado la opción de compatibilidad de interpretación de los dispositivos móviles.
Para el nivel de seguridad de plena confianza, el diseñador de la encuesta crea un formulario de InfoPath y guarda la plantilla del formulario. La plantilla o el archivo .xsn se envía al administrador de SharePoint como un archivo adjunto de correo electrónico o se transfiere a través de un recurso compartido de red. El administrador de TI a continuación comprueba las características de la encuesta y el código que contiene antes de hacerla disponible en el sistema de producción. El administrador de TI completa la implementación mediante la carga de la plantilla de la encuesta en una colección de sitios y la activación de dicha plantilla. Los dos procedimientos se completan en la página de administración de aplicaciones, en la consola de administración central de WSS. El resultado final es que un administrador de TI puede delegar la publicación de formularios en departamentos individuales al tiempo que se permite mantener una visión general del proceso de publicación si los formularios van más allá de las simples actividades clásicas de recopilación de datos.
La visión general del administrador de TI es necesaria en ciertos escenarios comunes: cuando los formularios se deben completar con datos predeterminados y cuando los resultados de la encuesta se envían a distintos orígenes de datos. De manera predeterminada, las plantillas de formulario de confianza de dominio no pueden establecer conexiones de datos entre dominios. Sin embargo, hay una serie de acciones que puede realizar para resolver esta limitación, entre las que se incluyen:
  • Concesión de permisos de plena confianza.
  • Creación de la confianza de dominio mediante conexiones de datos de la biblioteca de conexiones de datos.
  • Uso de la confianza de dominio con la biblioteca de conexiones de administración central.
Las opciones de plena confianza y de biblioteca de conexiones de administración central requieren la aprobación del administrador durante la publicación de los formularios. Sin embargo, la biblioteca de conexiones de datos (DCL, Data Connection Library) permite que los formularios publicados por el usuario crucen los límites del dominio mediante la DCL mantenida en el nivel de colección de sitios. Esta DCL puede estar bajo el control del departamento individual. Es importante comprender, sin embargo, que el hecho de permitir que departamentos individuales definan sus propias conexiones de datos basadas en servidores puede representar un problema de seguridad.
La opción más segura consiste en definir las conexiones de datos en la biblioteca de conexiones de administración central y, a continuación, hacer que un administrador de TI implemente formularios de encuestas avanzados que usen dichas conexiones. La biblioteca de conexiones de administración central resulta ventajosa porque está disponible en todas las colecciones de sitios y en toda la granja de servidores. Así se permite al administrador definir la configuración de autenticación central para obtener acceso a orígenes de datos que no se encuentran en el servidor local de SharePoint. Para obtener más información, consulte el artículo "Conexiones de datos, autenticación y asignación de accesos alternativos", disponible en línea, en msdn2.microsoft.com/ms771995.

Conclusión
Los encuestas son un medio eficaz para recopilar información crítica (y no tan crítica) para todos los negocios y en todos los niveles. La creación de una encuesta eficaz, sin embargo, requiere herramientas correctas, una planeación adecuada y una mezcla equilibrada de arte y conocimientos teóricos. Una planeación inicial bien meditada le ayudará a crear una solución que permitirá a todos los departamentos de su organización crear, enviar, recibir, almacenar y analizar los datos de las encuestas.
Las encuestas más efectivas son aquellas capaces de recuperar información importante en el momento preciso. Para recopilar información cuando se necesita, la solución debe facilitar la creación y administración de las encuestas en el nivel de departamento, sin poner en peligro la seguridad. InfoPath facilita que los trabajadores de la información creen encuestas de alta calidad mediante una interfaz que se puede usar con sólo un poco aprendizaje. Además, InfoPath permite recopilar datos de encuestas de alta calidad sin que ello requiera un gran esfuerzo de administración por parte del departamento de TI.
InfoPath 2007 funciona de un modo totalmente continuo con WSS y MOSS para facilitar soluciones enriquecidas y complejas, compatibles con distintas plataformas y exploradores. Y así se permite que su negocio use uno de los activos más importantes: la información.
Uso del correo electrónico para realizar encuestas rápidas
Las encuestas espontáneas son una herramienta esencial para recopilar datos de manera rápida de un grupo reducido de encuestados. Las encuestas basadas en el correo electrónico son perfectas para este tipo de investigación en tiempo real, ya que se pueden crear con rapidez y no necesitan servidores dedicados o asistencia por parte de TI. Uno de los enfoques más sencillos, los botones de votación integrados en mensajes de Microsoft® Outlook®, permite enviar, recibir y establecer tabulaciones en una encuesta unidimensional.
Después de iniciar una encuesta de botones de votación, los destinatarios recibirán un mensaje de correo electrónico que contiene una banda de votación, que muestra una lista desplegable de opciones. El destinatario responde con un clic en una de las opciones. A continuación aparece una ventana emergente con el texto , "Su respuesta fue: <su opción>" y se ofrece la opción de enviar o editar la respuesta.
El diseñador de la encuesta o un delegado asignado, recibe las respuestas individuales en un mensaje de correo electrónico y establece las tabulaciones de forma manual en los resultados. Si la encuesta incluye un número amplio de destinatarios, debería crear una regla en Outlook (mediante el Asistente para reglas) que direccione de manera automática las respuestas hacia una carpeta dedicada, como se muestra en la Figura A.
Figura A Respuestas de una encuesta dirigidas de manera automática a una carpeta dedicada
Figura A Respuestas de una encuesta dirigidas de manera automática a una carpeta dedicada
Los botones de votación, sin embargo, están bastante limitados. Los formularios de encuestas insertados en mensajes de correo electrónico pueden recopilar muchos más datos pero recuperar y tabular dichos datos de forma manual puede ser algo irrealizable. El lado más complejo de las encuestas basadas en correo electrónico lo representa el uso de VBScript para personalizar las encuestas de Outlook. Los formularios personalizados pueden facilitar la recuperación y el análisis de grandes cantidades de datos más complejos. Para obtener acceso a las funcionalidades para desarrolladores de Outlook 2007, primero se debe mostrar la ficha de desarrollador, como se muestra en la Figura B.
Figura B Ficha de desarrollador de Outlook 2007
Figura B Ficha de desarrollador de Outlook 2007
La creación de formularios personalizados de Outlook está más allá de los conocimientos normales de un usuario estándar de dicha aplicación. Pero InfoPath® 2007 proporciona nuevas características que facilitan la implementación de formularios personalizados. Sin un conocimiento especial, los diseñadores de formularios, pueden crear formularios de InfoPath y plantillas de tres modos diferentes:
  • Mediante la importación de documentos existentes de Microsoft Word u hojas de cálculo de Excel®.
  • Mediante la descarga de plantillas prediseñadas de InfoPath y su modificación para adaptarlas a sus necesidades concretas.
  • Mediante el diseño de plantillas desde cero, gracias a la funcionalidad de diseño de formularios de InfoPath.
En estos tres casos, las plantillas se pueden publicar en Outlook y distribuir mediante el correo electrónico. Con InfoPath 2007 y Outlook 2007, unas cuantas horas y sin asistencia por parte de TI, un trabajador de la información puede crear una encuesta de veinte preguntas, enviarla por correo electrónico a un grupo, recibir los resultados en Outlook y analizarlos en una hoja de cálculo de Excel.
El único requisito real de este escenario es que todos los participantes tengan InfoPath y Outlook instalados en sus equipos. Además, puesto que InfoPath 2007 en realidad amplia la funcionalidad de Outlook 2007, los destinatarios pueden responder a la encuesta desde la propia interfaz de Outlook.
Pero InfoPath admite muchas más opciones aparte de las encuestas basadas en correo electrónico. Puede crear plantillas que consulten y envíen datos a servicios web y bases de datos de SQL Server®, o usar un documento XML existente o un esquema XML como origen de datos. En otras palabras, con un aprendizaje mínimo y poco (o ningún) código adicional, un usuario puede experimentar la eficacia y flexibilidad del lenguaje XML.
El correo electrónico como solución de encuestas tiene algunos problemas notables. Por ejemplo, las encuestas no son anónimas, puesto que la dirección de correo electrónico del encuestado está disponible. Esto puede reducir la sinceridad de los resultados y desvirtuarlos. Además, se provoca una serie de problemas de seguridad, como los ataques de suplantación de identidad, por lo que hay un límite en el tipo y en la profundidad de la información que se puede recopilar mediante las encuestas basadas en el correo electrónico.

Creación de una solución de encuestas basada en bases de datos
Las encuestas basadas en el correo electrónico no están adaptadas a estudios más complejos que impliquen una gran cantidad de encuestados. El uso de sólo una carpeta en Outlook® no es suficiente para administrar y analizar todos los datos. Una solución más sólida consiste en dirigir las respuestas de la encuesta a una base de datos. Las capacidades avanzadas de almacenamiento, indexado, procesamiento y creación de informes que se pueden obtener mediante una base de datos le pueden ser muy útiles. Microsoft® SQL Server® 2005, por ejemplo, incluye SQL Server Reporting Services, que se puede usar para procesar los resultados de las encuestas de manera automática.
Para crear una plantilla de formulario de InfoPath que envíe las respuestas a una base de datos, primero debe crear una base de datos de Access® o SQL Server dentro de su red. A continuación, en InfoPath®, inicie el proceso de creación de la plantilla mediante el asistente para diseñar una plantilla de formulario. De este modo se abrirá el Asistente para la conexión de datos, cuyos pasos le guiarán a través del proceso de vinculación del formulario con la base de datos. InfoPath usa la información de su base de datos para crear la consulta de origen de datos y los campos de datos.
La mayor parte de los trabajadores tendrán un conocimiento suficiente como para completar y enviar la encuesta con poco aprendizaje o soporte técnico. Sin embargo, en este escenario (en el que los datos se transfieren de manera directa a la base de datos), los encuestados deben tener InfoPath y Outlook instalados y deben también estar por detrás del firewall de la empresa u obtener acceso por VPN a la red corporativa.
El Asistente para la conexión de datos de InfoPath sólo interactúa con Microsoft SQL Server 2000 o posterior y con las bases de datos de Access que usen ADOXML de manera nativa. No se admite el envío directo a la base de datos en otras bases de datos. Otras limitaciones consisten en que InfoPath no permite enlazar controles de texto enriquecido con campos de la base de datos, y tampoco se admiten tipos de datos binarios de gran tamaño.
A medida que la topología de la red se vuelve más grande y compleja, se vuelve más favorable el envío de datos a un servicio web intermedio para su transferencia posterior a una base de datos. La separación mediante un servicio web del front end del formulario de la encuesta del back end de la base de datos, también facilita la implementación de la lógica empresarial en el servidor web. Y, puesto que el servicio web se realiza mediante conexiones HTTP o HTTPS, los encuestados pueden enviar datos a través de firewalls, como se muestra en la Figura C. Tenga en cuenta, sin embargo, que debe seguir teniendo InfoPath 2003 o 2007 instalados.
El punto desfavorable de este escenario consiste en que la implementación requiere de la participación del departamento de TI. La descripción en profundidad de este proceso está más allá del alcance de este artículo, pero le aseguro que la creación de una solución de base de datos desde cero es un reto importante. Requiere planeación por adelantado, un buen diseño de la encuesta, la programación del servicio web y el diseño del back end de la base de datos. InfoPath 2007 simplifica la parte del proceso relacionada con el diseño de formularios, pero la solución completa requiere una programación sólida y ciertas destrezas en el diseño de bases de datos. La adición de funcionalidades avanzadas, como de flujo de trabajo o compatibilidad con varios idiomas, aumenta rápidamente el costo de la implementación.
Figura C Flujo de datos de InfoPath a través de un servicio web
Figura C Flujo de datos de InfoPath a través de un servicio web

Jim Bradley es el propietario de CoyoteTech LLC, un compañía técnica de comunicaciones especializada en documentación de ayuda al usuario para los productos de servidores de Microsoft. Sus proyectos de documentación incluyen "Protección de la mensajería y el transporte perimetral de Microsoft Exchange Server 2007", "Migración a la arquitectura de 64 bits con Microsoft Exchange Server 2007" o la "Guía de referencia técnica de Microsoft Exchange 2003".


 SharePoint: Estandarice la administraci&#243;n de datos con tipos de contenido personalizados
SharePoint Pav Cherny

Estandarice la administración de datos con tipos de contenido personalizados
Resumen:
  • Administración del ciclo de vida del contenido con SharePoint
  • Creación de paneles de información de documentos
  • Edición de documentos de Office y SharePoint a través de InfoPath
Descargar el código de este artículo: ContentTypes2008_02.exe (779KB)

El elevado número de documentos y otros contenidos que se encuentran normalmente en un entorno empresarial plantean desafíos técnicos y empresariales para la administración de documentos, sus
metadatos y sus comportamientos de una manera centralizada y reutilizable. Microsoft® Office SharePoint® Server 2007 fomenta la colaboración en toda la empresa permitiendo que los distintos equipos de una organización compartan áreas de trabajo en sitios web, listas y bibliotecas de documentos.
SharePoint 2007 hace posible la estandarización de muchos aspectos de las características de contenido y ciclo de vida a través de los tipos de contenido. Los tipos de contenido de sitio son definiciones del metadatos que se pueden establecer independientemente de cualquier colección de sitios, sitio, lista o biblioteca de documentos específicos. Esto le permite establecer propiedades, flujos de trabajo, directivas de administración de la información y otros elementos en toda la empresa de manera coherente, al tiempo que posibilita que los propietarios individuales de departamentos o sitios personalicen tipos de contenido para propósitos específicos.
En este artículo, le mostraré cómo usar el nuevo modelo de contenido de SharePoint introducido con Windows® SharePoint Services (WSS) 3.0 y Microsoft Office SharePoint Server (MOSS) 2007 para construir jerarquías de contenido empresarial basadas en características generales. Estas jerarquías de contenido permiten la aplicación uniforme de metadatos, flujos de trabajo y directivas de administración de la información a nivel global, al tiempo que proporcionan la flexibilidad para acomodar las necesidades únicas de administración de contenido en el nivel de colecciones de sitios, sitios, listas y bibliotecas de documentos.
Para ilustrar algunos de los aspectos de bajo nivel de los tipos de contenido de SharePoint, he incluido varias herramientas personalizadas en el material del libro guía. He incluido igualmente el código fuente por si desea ampliar estas herramientas en función de sus necesidades específicas. Tenga presente que estas herramientas no se han probado exhaustivamente, por lo que no deben usarse en sistemas de producción. Puede descargar el código desde el sitio web de TechNet Magazine en technetmagazine.com/code08.aspx.

Ciclo de vida del contenido y definiciones de tipos de contenido
Recursos de SharePoint
  • Blog del equipo de InfoPath
  • Flujos de trabajo en Office SharePoint Server 2007
  • Difusión por Web de TechNet: Instalación y configuración de la búsqueda en SharePoint Server 2007
  • InfoPath Forms Services

Hay muchos detalles que se deben tener en cuenta para decidir cuándo administrar documentos y otros contenidos en una organización. Entre otras cosas, es necesario definir las personas o procesos que necesitan realizar acciones determinadas a medida que el contenido se crea, publica, archiva y desecha. Además, las organizaciones necesitan a menudo desarrollar plantillas específicas para la creación de contenidos, definir funciones a las que asignar responsabilidades y privilegios de acceso para usuarios, ofrecer control de versiones, supervisar el cumplimiento, el almacenamiento y el archivado, definir metadatos, etcétera.
Independientemente de lo complejo que pueda resultar el ciclo de vida de un contenido concreto, el modelo de contenido de SharePoint reconoce que existen algunas características generales y fases típicas que determinan el modo en que se deben tratar los elementos individuales. Por ejemplo, puede estructurar la creación de contenidos mediante plantillas y formularios de entrada, así como la visualización y la búsqueda de contenido a través de metadatos. También puede usar la edición, aprobación u otros requisitos de flujo de trabajo, los requisitos de archivado, los períodos de tiempo de expiración y las directivas aplicables de administración de la información para diferenciar fragmentos individuales de contenido. Puede que algunos contenidos no requieran plantillas especiales, o que nunca se archiven, pero incluso éstas son características del ciclo de vida que contribuyen a diferenciar éstos de otros elementos.
El modelo de contenido de SharePoint le permite definir tipos de contenido individuales y establecer relaciones jerárquicas. En una relación jerárquica, los elementos secundarios heredan características generales de tipos de contenido primarios, agregando características específicas según sea necesario.
La mejor manera de ilustrar esto es examinar los tipos de contenido integrados de SharePoint. WSS 3.0 y MOSS 2007 incluyen varios tipos de contenido predefinidos para los elementos típicos que se pueden almacenar en una lista o biblioteca de documentos, incluyendo documentos y tareas. Puede encontrar las definiciones de estos tipos de contenido estándar en un servidor de SharePoint en la carpeta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes. Ahí encontrará un archivo de manifiesto llamado feature.xml. Mirando este archivo, puede ver que SharePoint implementa las definiciones de los tipos de contenido estándar como una característica oculta (Hidden="TRUE") con un ámbito de colección de sitios (Scope="Site") y que el archivo de manifiesto de elementos, que contiene los elementos de tipo de contenido, es ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />).
Si está interesado en obtener más información acerca de las características de SharePoint, le recomiendo que lea la columna Espacio de oficina de Ted Pattison en MSDN® Magazine titulada "Características de SharePoint," que está disponible en msdnmagazine.com/issues/07/05/OfficeSpace .
Abramos ahora el archivo ctypeswss.xml en el Bloc de notas para examinar los tipos de contenido estándar al margen de su visibilidad en la interfaz de usuario de SharePoint. No debe modificar el archivo ctypeswss.xml. Si piensa editar ctypeswss.xml para agregar campos nuevos a los tipos de contenido estándar o para hacer visibles los tipos de contenido ocultos de modo que los usuarios de SharePoint los puedan usar para derivar nuevos tipos de contenido, tenga en cuenta que generalmente esto no es necesario. Además, genera configuraciones no admitidas y las instalaciones posteriores de Service Packs pueden sobrescribir las personalizaciones e interrumpir sus soluciones de administración de contenido.
Un enfoque mucho mejor consiste en copiar lo que necesita en un archivo de manifiesto de elementos nuevo, agregar sus personalizaciones según sea necesario y, a continuación, implementar los tipos de contenido personalizados como una característica nueva con un ámbito de colección de sitios para ponerlos a disposición de todos los sitios incluidos en la colección de sitios.
Aquí se revela la definición basada en el Lenguaje de marcado de aplicaciones de colaboración (CAML, Collaborative Application Markup Language) del tipo de contenido System tal y como se especifica en el archivo ctypeswss.xml:
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Los atributos Group y Sealed muestran que el tipo de contenido System está oculto y sellado para que no se pueda cambiar en la interfaz de usuario de SharePoint. El tipo de contenido System sólo tiene un elemento FieldRef que hace referencia a una columna de sitio integrada llamada ContentType. Éste es el nivel más alto de abstracción. Todos los demás tipos de contenido de SharePoint heredan esta propiedad del tipo de contenido System. De este modo, SharePoint se asegura de que todos los elementos de contenido almacenados en cualquier lista o biblioteca de documentos tienen esta propiedad en común.
La Figura 1 muestra un elemento web ContentTypeHierarchy, incluido en el material del libro guía para este artículo, que ilustra las jerarquías de manera más intuitiva. System se encuentra en la raíz de todos los demás tipos de contenido, seguido por Item, etcétera. El tipo de contenido Item, por ejemplo, establece el siguiente nivel de detalle. Si comprueba el archivo ctypeswss.xml, verá que Item define un solo campo de metadatos que hace referencia a una columna de sitio llamada Title. De este modo, todos los tipos de contenido integrados en niveles inferiores tienen una propiedad Title.
Figura 1 Jerarquía de tipo de contenido integrado WSS 3.0
Figura 1 Jerarquía de tipo de contenido integrado WSS 3.0
También es posible quitar un campo heredado, como demuestra la definición del tipo de contenido Document en el archivo ctypeswss.xml. El tipo de contenido Document incluye varios elementos RemoveFieldRef. Aún así, quizás desee mantener el campo Title en los tipos de contenido personalizados, ya que la columna Title da acceso al menú desplegable del cuadro de control de edición (ECB, Edit Control Box) en las vistas de lista y biblioteca de documentos de SharePoint.
Un buen ejemplo que ilustra cómo cambiar el nombre de los campos heredados es el tipo de contenido Far East Contact del archivo ctypeswss.xml. Busque 0x0116, que es el identificador de tipo de contenido correspondiente y, entonces, active el elemento FieldRef con el atributo Name="Title" para ver cómo puede usar el atributo DisplayName para cambiar el nombre de un campo de la interfaz de usuario. En este ejemplo particular, el atributo DisplayName cambia el nombre del campo Title en la interfaz de usuario a un valor de datos localizado al que "$Resources:core,Last_Name;" hace referencia.
Si presta atención a la Figura 1, podrá ver que el atributo ID del elemento ContentType identifica únicamente el tipo de contenido y establece la relación jerárquica. Todos los identificadores empiezan con el identificador del tipo de contenido primario con valores hexadecimales adicionales adjuntos. Los tipos de contenido estándar tienen normalmente dos valores hexadecimales adicionales adjuntos para crear un nuevo identificador único para el tipo de contenido secundario. Otra técnica consiste en anexar el valor "00" y un GUID hexadecimal. Así es como los tipos de contenido Office Data Connection File y Universal Data Connection File derivan a partir del tipo de contenido Document, por ejemplo.
Un punto importante que deben recordar los usuarios es que el atributo ID del elemento ContentType no puede exceder de 1.024 caracteres. Esto puede resultar un problema en una relación jerárquica grande si todos los tipos de contenido usan la técnica de direcciones de GUID hexadecimal. Sin embargo, no es buena idea comenzar con la técnica más corta porque puede que estos identificadores no sean únicos.
Para asegurar unicidad, use la técnica de GUID para establecer un espacio de nombres global para sus tipos de contenido empresariales y cambiar a la técnica más corta dentro de ese espacio de nombres. Para obtener información detallada acerca del atributo ID y otros elementos de definiciones de tipo de contenido, consulte el tema "Esquema de definición de tipo de contenido" en el SDK de WSS 3.0.

Dependencias de tipo de contenido
Centrémonos ahora en la cuestión de cómo usar tipos de contenido de SharePoint para estructurar la administración de elementos de contenido. Necesita considerar varias dependencias, tales como las interdependencias entre listas y bibliotecas de documentos, tipos de contenido, columnas de sitio y tipos de campo. Las bibliotecas y las listas hacen referencia a tipos de contenido, que a su vez hacen referencia a columnas de sitio, que hacen referencia a tipos de campo (como los tipos de campo estándar de WSS de texto, nota, elección, número, divisa, etcétera), que por su parte residen en los ensamblados de Microsoft .NET Framework, como el ensamblado principal de WSS Microsoft. SharePoint. dll.
Para encontrar un buen ejemplo podemos volver al tipo de contenido System tal y como lo ilustramos anteriormente en la definición CAML de la entrada de archivo de manifiesto de tipo de contenido System. Como vimos, este tipo de contenido incluye un elemento FieldRef que se refiere a una columna de sitio llamada ContentType. Tenga en cuenta que la definición del tipo de contenido no define la columna de sitio ContentType. ContentType es un campo de texto, definido en el archivo de manifiesto de elementos fieldswss.xml, que se encuentra en la carpeta %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields. El tipo de campo Text se define en el archivo fldtypes.xml, que puede encontrar en %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML. Un punto importante en referencia a este árbol de dependencias es que debe asegurarse de que todos los recursos están disponibles en sus servidores de SharePoint.
Los tipos de contenido que desea usar deben crearse en el nivel de sitio de sus listas y bibliotecas de documentos o en un nivel superior de la jerarquía de sitios. De igual modo, los campos de metadatos de sus tipos de contenido deben referirse a columnas de sitio existentes. Puede agregar columnas de sitio personalizadas o estándar basadas en los tipos de campo personalizados a los tipos de contenido, pero debe asegurarse de que las columnas de sitio existen en el sitio local. Además, si desea usar tipos de campo personalizados, deberá asegurarse de que los ensamblados .NET subyacentes están implementados en sus servidores de SharePoint.
Existen dependencias similares para los tipos de contenido que hacen referencia a plantillas de documento, receptores de evento personalizados, flujos de trabajo y otros componentes. Por ejemplo, la definición del tipo de contenido puede contener un elemento DocumentTemplate que señale a la plantilla de documento asociada con el tipo de contenido. La definición del tipo de contenido puede incluir también un elemento XmlDocuments con uno o varios elementos XmlDocument secundarios que definen características adicionales del tipo de contenido, tales como las definiciones de espacio de nombres, definiciones de paneles de información de documentos o cualquier información personalizada.

Establecimiento de tipos de contenido globales
Los usuarios con permisos de creación pueden crear nuevos tipos de contenido y columnas de sitio directamente en la interfaz de usuario de SharePoint, pero entonces los tipos de contenido sólo están disponibles en el sitio local o niveles inferiores de la jerarquía de sitios. Las columnas de sitio personalizadas sólo están disponibles en el sitio local. Esto no es suficiente si desea establecer tipos de contenido globales. Debe asegurarse de que los tipos de contenido globales están disponibles en todas las colecciones de sitios de su entorno. Aquí es donde las características de SharePoint demuestran su utilidad. Es sencillo instalar y activar las características de SharePoint a través de múltiples colecciones de sitios para aplicar las definiciones correspondientes de columna de sitio y tipo de contenido de manera coherente en todas las ubicaciones.
El material del libro guía correspondiente a este artículo incluye una característica de muestra llamada AdventureWorks que nos enseña cómo establecer un tipo de contenido global. La característica define un tipo de contenido general llamado Customer Documentation que puede usarse para crear cualquier tipo de material de cliente como cartas de ventas y propuestas. Es razonable asumir que todos estos tipos de documentos deben asociarse con información de cliente como el nombre de la compañía, los detalles de contacto y la dirección. Creé específicamente un campo personalizado llamado Customer Name para su tipo de contenido y agregué algunos campos integrados tales como Department y Primary Phone. Puede cambiar el tipo de contenido y los campos editando el archivo ContentTypes.xml y las referencias de campo mediante la edición del archivo SiteColumns.xml en la muestra del libro guía.
Si implementa la característica de la manera descrita en el archivo leame.htm, podrá activarla coherentemente en múltiples colecciones de sitios. El tipo de contenido Customer Documentation estará entonces disponible globalmente. De este modo, los departamentos individuales pueden crear documentación específica de cliente a través de tipos de contenido derivados asociados con plantillas de documento de destino. El material del libro guía incluye plantillas de documento de muestra que pueden usarse en ventas y consultoría. La Figura 2 muestra los tipos de contenido resultantes.
Figura 2 Tipos de contenido primario y secundario para la documentación de cliente
Figura 2 Tipos de contenido primario y secundario para la documentación de cliente
Puede elegir entre varias opciones para crear características para columnas de sitio y tipos de contenido personalizados en WSS 3.0 y MOSS 2007. Puede estudiar el SDK de WSS 3.0 y escribir archivos XML desde cero. También puede usar SharePoint Designer para exportar una lista a un paquete web personal, cambiar el nombre del archivo .fwp resultante a un archivo .cab, extraer el archivo manifest.xml del archivo .cab y, a continuación, buscar las definiciones de ContentType en el archivo manifest.xml. Desgraciadamente, ambos enfoques son farragosos y proclives al error.
Por el contrario, resulta bastante fácil crear columnas de sitio y tipos de contenido personalizados en la interfaz de usuario de SharePoint. Aún así, la interfaz no ofrece una opción para editar los archivos XML de las características. Las características son una manera eficiente de aprovisionar recursos de SharePoint, aunque una vez aprovisionados, los recursos sólo existen en la base de datos de contenidos. Quizás una versión futura de WSS incluya la capacidad de exportar columnas de sitio y tipos de contenido a archivos XML a través de la interfaz de usuario de SharePoint, de manera similar a la exportación de elementos web. Por ahora, tiene que apañarse con lo que hay.
El material del libro guía incluye un elemento web llamado ContentTypeSchema que puede servir como punto de partida. Usa el modelo de objetos de SharePoint para extraer la propiedad SchemaXML del tipo de contenido seleccionado. A través de las transformaciones basadas en el lenguaje de transformación basado en hojas de estilo (lenguaje XSLT), el elemento web deriva definiciones de campo o definiciones ContentType en función de la opción que seleccione en la interfaz de usuario antes de hacer clic en el botón Mostrar.
La Figura 3 muestra el elemento web en acción. Muestra el tipo de contenido Active Directory® Documentation, que he basado en el tipo de contenido Customer Documentation. El tipo de contenido Active Directory Documentation está asociado con una plantilla personalizada de Microsoft Word (Active Directory Template.dot). Tenga en cuenta que este tipo de contenido no tiene campos adicionales. Todos los campos se heredan del tipo de contenido primario.
Si planea usar el elemento web ContentTypeSchema en su propio entorno, tenga presente que este elemento web no se ha probado exhaustivamente. Mi elemento web usa transformaciones XSL relativamente complejas para construir una diferencia entre la propiedad SchemaXML del tipo de contenido seleccionado actualmente y su tipo de contenido primario. XSLT 1.0 no está realmente diseñado para conversiones avanzadas de documentos XML. No hay características integradas para comparar nodos XML. Además, los espacios de nombres XML, así como las secciones de CDATA, representan dificultades que XSLT 1.0 no puede tratar con eficacia.
SharePoint almacena la definición de las columnas de sitio y los tipos de contenido de sitio creados con la interfaz de usuario de SharePoint o el modelo de objetos de SharePoint en la tabla ContentTypes de la base de datos de contenidos. En la Figura 3, eche un vistazo al identificador de mi tipo de contenido personalizado. Por lo tanto, la siguiente instrucción T-SQL obtendría resultados exactos: SELECT Definition FROM ContentTypes WHERE ContentTypeId = <identificador del tipo de contenido>.
Figura 3 Definición de tipo de contenido personalizado en el elemento web ContentTypeSchema
Figura 3 Definición de tipo de contenido personalizado en el elemento web ContentTypeSchema
Al margen del enfoque que decida usar, resulta muy sencillo crear características para tipos de contenido a nivel de empresa una vez obtenidas las definiciones de la columna de sitio y el tipo de contenido. Le recomiendo que use una sola característica para todos los tipos de contenido y columnas de sitio globales de su departamento o compañía. Así, parece claro dónde agregar nuevas definiciones de columna de sitio y de tipo de contenido.

Búsquedas a nivel de empresa en metadatos personalizados
Una ventaja inmediata que presentan las jerarquías de tipo de contenido es que todos los tipos de contenido secundarios heredan los campos de metadatos del tipo de contenido primario. Puesto que todos los tipos de contenido tienen campos de metadatos en común, es bastante fácil para los usuarios crear vistas y filtros personalizados en las bibliotecas de documentos.
La característica de ejemplo AdventureWorks demuestra esto de forma bastante intuitiva. Independientemente del contenido creado por un consultor o un vendedor, el guardado del documento de Word 2007 resultante requiere que se especifique un campo Customer Name, ya que el tipo de contenido primario Customer Documentation define este campo de metadatos como obligatorio. Agrupar o filtrar los elementos en una vista de biblioteca de documentos según el campo Customer Name permite a los miembros de los equipos de consultoría y ventas localizar toda la documentación existente de un cliente de manera rápida y oportuna, tal y como se muestra en la Figura 4.
Figura 4 Agrupación de varios documentos en una biblioteca en función de los metadatos en común
Figura 4 Agrupación de varios documentos en una biblioteca en función de los metadatos en común
Los metadatos en común también facilitan la localización del contenido a través de múltiples sitios y bibliotecas de documentos usando las capacidades de búsqueda de WSS 3.0 y MOSS 2007. WSS permite la realización de búsquedas en bibliotecas, listas y sitios dentro de una sola colección de sitios. MOSS 2007 va más allá de estas capacidades básicas permitiéndole implementar un Centro de búsquedas a nivel de empresa y administrar los metadatos personalizados en la interfaz de usuario de Administración central de SharePoint 3.0. Por este motivo, las siguientes explicaciones se centran en MOSS 2007.
Al configurar un proveedor de servicios compartidos (SSP, Shared Service Provider) en MOSS 2007 y rastrear sus sitios de SharePoint, MOSS 2007 puede descubrir automáticamente los campos de metadatos personalizados usados en los orígenes de contenido. De este modo, puede encontrar los campos de metadatos personalizados en la lista de propiedades rastreadas.
Los campos de metadatos definidos en las características de SharePoint se encuadran generalmente en la categoría de SharePoint. Para encontrar su ubicación en Administración Central de SharePoint, en el menú Inicio rápido de Administración de servicios compartidos, haga clic, por este orden, en el vínculo a su SSP, en la configuración Búsqueda, en las asignaciones de propiedades de metadatos, en Propiedades rastreadas del menú Inicio rápido y, por último, abra la categoría SharePoint.
Le daré un ejemplo de esto en acción. El campo de metadatos denominado Customer Name acaba como una propiedad rastreada llamada ows_Customer_x0020_Name. Los prefijos de SharePoint rastrearon las propiedades con "ows_", y "_x0020_" es la versión codificada de un espacio único. Si muestra los detalles de esta propiedad rastreada, descubrirá que está incluida en el índice de búsqueda de manera predeterminada para que los usuarios puedan emplear los valores de esta propiedad rastreada para realizar búsquedas de contenidos. Sin embargo, para aumentar la precisión de la búsqueda, quizás sea mejor no asignar la propiedad rastreada a una propiedad administrada para que los usuarios puedan buscar explícitamente los contenidos por nombre de cliente.
Tiene dos opciones al asignar propiedades rastreadas a propiedades administradas. Puede generar automáticamente una nueva propiedad administrada para cada propiedad rastreada o puede asignar propiedades rastreadas a otras administradas de forma manual. La primera opción está disponible al mostrar la configuración de la categoría de propiedad rastreada deseada (al mostrar las propiedades rastreadas en una categoría como, por ejemplo, la categoría SharePoint, haga clic en la opción Editar categoría del vínculo de Inicio rápido). En Configuración de propiedades de rastreo masivo, tendría que seleccionar la casilla "Generar automáticamente una nueva propiedad administrada para cada propiedad rastreada descubierta en esta categoría". Sin embargo, los prefijos de SharePoint crearon automáticamente propiedades administradas con "ows" y espacios de escape con "x0020". La propiedad administrada correspondiente a la propiedad rastreada ows_Customer_x0020_Name sería owsCustomerx0020Name. Sin embargo, este nombre de propiedad no es muy fácil de usar.
Quizás una mejor estrategia consista en asignar manualmente propiedades rastreadas a propiedades administradas después de implementar los tipos de contenido a nivel de empresa. Puede asignar una propiedad rastreada a una o a múltiples propiedades administradas. Para crear nuevas propiedades administradas, en Administración Central de SharePoint, en el menú Inicio rápido de Administración de servicios compartidos, haga clic, por este orden, en el vínculo a su SSP, en la configuración Búsqueda, en las asignaciones de propiedades de metadatos y en Nueva propiedad administrada para especificar la información necesaria y asociar la nueva propiedad administrada con la propiedad rastreada deseada.
Así, los usuarios podrán localizar elementos de contenido relevantes usando las propiedades administradas en la sintaxis de propiedad o usando la búsqueda avanzada. Por ejemplo, si asigna la propiedad rastreada ows_Customer_x0020_Name a una propiedad administrada denominada Client, los usuarios podrán buscar todos los documentos de un cliente con sólo especificar Client: <nombre del cliente> en el cuadro de búsqueda estándar, como por ejemplo Client: Contoso.
También es una buena idea incluir las propiedades administradas correspondientes a los campos de metadatos más importantes de sus tipos de contenido en la lista de propiedades de la página Búsqueda avanzada. Para conseguir esto, muestre la página Búsqueda avanzada, haga clic en Acciones del sitio y seleccione el comando Editar página. Ahora puede hacer clic en Edición en el Cuadro de búsqueda avanzada para seleccionar la opción Modificar elemento web compartido. Al ampliar la categoría Propiedades y colocar el cursor en el campo de texto correspondiente, puede hacer clic en el botón para editar el documento XML de propiedades. Necesita agregar una definición de propiedad al elemento <PropertyDefs>, como <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>, y necesita agregar igualmente una referencia a esta definición de propiedad en un elemento ResultType (por ejemplo, el elemento <ResultType DisplayName =" All Results" Name ="default">), como <PropertyRef Name="Customer" /.> La Figura 5a muestra la interfaz de usuario Búsqueda avanzada resultante. La Figura 5b muestra los resultados de la búsqueda.
Figura 5a Búsqueda de documentación de la infraestructura de TI basada en el nombre de cliente
Figura 5a Búsqueda de documentación de la infraestructura de TI basada en el nombre de cliente
Figura 5b Los resultados de la búsqueda de nombre de cliente
Figura 5b Los resultados de la búsqueda de nombre de cliente

Garantía de la consistencia de la información
Llegados a este punto, he estandardizado correctamente los campos de metadatos y los tipos de contenido más importantes. También he ampliado las capacidades de búsqueda en todas las colecciones de sitios de mi empresa mediante MOSS 2007. Ahora es importante asegurar que los usuarios introduzcan información exacta en los campos de metadatos.
Hay dos maneras de hacer esto. En primer lugar, puede reemplazar el panel de información del documento estándar en sus plantillas de documento con un formulario InfoPath® personalizado que proporciona a los usuarios una selección predefinida de opciones de entrada, como las que aparecen en un cuadro de lista. En segundo lugar, puede enlazar un receptor de eventos al tipo de contenido y, a continuación, comprobar la precisión de los metadatos y otro tipo de información cuando los usuarios creen, modifiquen o eliminen los correspondientes elementos de contenido.
Ambas opciones son complementarias. Un formulario de InfoPath ofrece principalmente una manera oportuna de editar las propiedades de un tipo de contenido de SharePoint, mientras que un receptor de eventos puede asegurar la validez de los metadatos incluso si los usuarios editan las propiedades del tipo de contenido fuera del formulario de InfoPath. Puede enlazar controladores de eventos a un tipo de contenido específico. Esto le permite especificar eventos y sus respuestas para todos los documentos asociados con un tipo de contenido individual en todas las colecciones de sitios, independientemente de cuál sea la biblioteca de documentos. Puede obtener más información acerca de cómo desarrollar e implementar controladores de eventos en msdn2.microsoft.com/ms453149.
Quizás el método más fácil para asociar un tipo de contenido con un panel de información del documento personalizado consista en mostrar la configuración Panel de información del documento del tipo de contenido en la interfaz de usuario de SharePoint en un equipo con InfoPath 2007 instalado. Entonces puede hacer clic en el vínculo Crear una nueva plantilla personalizada en Plantilla del panel de información del documento para iniciar InfoPath 2007 en modo de diseño. Sin embargo, si el tipo de contenido del sitio incluye columnas de sitio sin un atributo SourceID explícito, podría encontrarse en una situación en la que InfoPath no puede crear un esquema XSD válido para el formulario Panel de información del documento. Por ejemplo, el tipo de contenido Customer Documentation presentado anteriormente incluye varias columnas específicas de contactos tales como Department, Office y E-mail que pueden causar este problema, tal y como se muestra en la Figura 6.
Figura 6 Incompatibilidades de esquema XSD en InfoPath 2007
Figura 6 Incompatibilidades de esquema XSD en InfoPath 2007
En este punto, tiene dos opciones si se le presenta este problema. Puede quitar las referencias a las columnas de sitio sin un atributo SourceID explícito de la definición de tipo de contenido. También puede sustituir las columnas de sitio integradas que causan el problema por columnas de sitio personalizadas que sean compatibles con InfoPath 2007. Tenga presente que no puede cambiar las referencias de campo de un tipo de contenido basado en CAML después de que se haya aprovisionado en la base de datos de contenidos, especialmente si ya ha creado tipos de contenido secundarios. Ya no puede simplemente actualizar el archivo de definición de tipos de contenido basados en CAML, ni desplazar hacia abajo los cambios hechos a tipos de contenido secundarios porque Windows SharePoint Services no hace un seguimiento de los cambios realizados a la definición del tipo de contenido primario.
Para desplazar hacia abajo los cambios, debe cambiar el tipo de contenido primario a través del modelo de objetos o la interfaz de usuario de SharePoint. También debe definir un nuevo tipo de contenido que se derive del tipo ya existente. La última técnica le permite quitar los campos críticos y agregar nuevas columnas. Sus usuarios pueden derivar tipos de contenido futuros a partir del nuevo tipo de contenido. Para evitar que los usuarios elijan el tipo de contenido equivocado, agregue el tipo de contenido anterior al grupo de tipo de contenido _Hidden.
Como dije antes, no puede actualizar los tipos de contenido basados en CAML después de implementarlos y activarlos. Por eso es muy importante probar los tipos de contenido globales antes de la implementación. Para obtener más información, consulte el artículo de MSDN "Actualización de los tipos de contenido" en msdn2.microsoft.com/aa543504.
Cuando haya creado un tipo de contenido con referencias de campo adecuadas, podrá crear un panel de información del documento personalizado en InfoPath 2007. La mejor estrategia consiste en permitir que los propietarios de sitios creen paneles de información de documento personalizados para sus tipos de contenido secundarios. InfoPath 2007 ofrece la opción de publicar el panel de información del documento personalizado directamente en el tipo de contenido seleccionado, lo cual facilita el escenario de implementación. También es posible publicar el formulario de InfoPath en una ubicación central, como una biblioteca de documentos, e incluir una referencia al panel de información del documento en el tipo de contenido. Esta es la mejor opción si planea proporcionar un panel de información del documento personalizado junto con sus tipos de contenido CAML. La Figura 7 ilustra la arquitectura de implementación.
Figura 7 Implementación de archivos XSN en una ubicación central en MOSS 2007
Figura 7 Implementación de archivos XSN en una ubicación central en MOSS 2007
La descarga del libro guía para este artículo incluye una característica llamada AdventureWorks_Update que amplía la característica AdventureWorks anterior agregando columnas de sitio adicionales que funcionan con InfoPath 2007. La característica AdventureWorks_Update marca el tipo de contenido Customer Documentation original como oculto y deriva un nuevo tipo de contenido denominado Customer Docs, que sustituye los campos integrados heredados por las nuevas columnas de sitio y asocia el nuevo tipo de contenido con un panel de información del documento personalizado.
La nueva definición del tipo de contenido Customer Docs incluye un elemento XmlDocument que proporciona información acerca del panel de información del documento. Específicamente, el elemento xsnLocation señala al formulario de InfoPath http://companyresources/DIPs/customerDIP.xsn, que implementa el panel de información del documento. Para obtener instrucciones detalladas acerca de cómo aplicar la característica AdventureWorks_Update, consulte el archivo leame.htm de la carpeta AdventureWorks_Update.

Conclusión
Puede usar tipos de contenido de SharePoint para crear directivas de metadatos y usarlas coherentemente en toda la empresa para la administración de contenido. La jerarquía de tipos de contenido le permite estandarizar características que son relevantes para todo el entorno empresarial y aplicarlas uniformemente en todos sitios mediante herencia.
Entre otras cosas, es posible ampliar las capacidades de búsqueda integradas de MOSS 2007 para que los usuarios puedan localizar contenidos específicos de manera más rápida y cómoda. También se puede aplicar la coherencia de la información relacionada con los metadatos y establecer directivas de administración de la información centralizada. La mejor estrategia consiste en estandarizar los tipos de contenido globales en las características de metadatos más abstractas para minimizar la necesidad de cambios posteriores. Basado en un modelo de contenido cuidadosamente diseñado, los tipos de contenido de SharePoint pueden proporcionar nuevas capacidades para estandarizar la administración del ciclo de vida del contenido en toda la empresa.

Pav Cherny es el presidente de Biblioso Corporation, autor y experto de TI especializado en tecnologías de Microsoft para la colaboración y las comunicaciones unificadas. Sus trabajo publicados se centran en las operaciones de TI y en la administración de sistemas.


 Office Communications Server: C&#243;mo la presencia fortalece OCS 2007
Office Communications Server Rajesh Ramanathan

Cómo la presencia fortalece OCS 2007
Resumen:
  • Servicios de autorización y de directorio
  • Opciones de mensajería en OCS 2007
  • Enrutar comunicaciones con presencia

Microsoft Office Communication Server (OCS) 2007 se basa en los puntos fuertes de Live Communication Server (LCS) 2005. LCS 2005 proporcionaba mensajería instantánea (MI) de tipo empresarial
y presencia. También introdujo la integración de telefonía con instalaciones PBX existentes mediante el control de llamada remota (RCC, Remote Call Control).
OCS 2007 mejora aún más las capacidades de presencia y MI de LCS 2005 y agrega capacidades avanzadas para medios y teléfonos con Office Communicator 2007, con lo que se convierte en un "teléfono por software" completo. Microsoft también ha desarrollado servidores de conferencias y servidores perimetrales para medios que permiten satisfacer las necesidades de comunicación de la organización junto con un PBX existente o independientemente como una solución completa en sí misma.
Office Communicator 2007 proporciona capacidades de "teléfono por software" que permiten a los usuarios elegir los dispositivos USB que deseen y proporciona un experiencia enriquecida para el usuario final al convertir las características de control de llamada comunes, como la retención y la transferencia, en detectables y fáciles de usar. Los usuarios ya no tienen que recordar números de teléfono ni usar el panel de marcado. En su lugar, pueden hacer clic para realizar una llamada desde una aplicación de escritorio o crear una llamada de conferencia si arrastran y colocan personas o listas de distribución en una conversación.
Para los que necesiten un teléfono de escritorio real, Office Communicator Phone Edition (o teléfono Tanjay) actúa como cualquier otro extremo para el usuario, mediante menús contextuales habilitados por pantalla táctil y la experiencia de presencia conocida de Office Communicator.
Estas capacidades del sistema OCS se basan en el concepto de presencia de usuario. OCS 2007 usa la disponibilidad de usuario, los extremos de comunicación y las relaciones de usuario para conectar a las personas mediante el medio más adecuado en un momento cualquiera. Y como OCS combina voz, correo electrónico, MI y otras rutas de comunicación, puede ayudarle a enrutar los mensajes de la forma más productiva posible.
En este artículo ofreceré información general acerca de la solución OCS 2007 y explicaré cómo se combinan las distintas piezas. También trataré el modo en que se usa la presencia como un ingrediente importante en la receta de comunicaciones unificadas y cómo se puede usar para enrutar las llamadas de voz de un modo más efectivo.

Servicios de autorización y de directorio
Un sistema de voz empresarial debe poder comprobar las identidades de las personas que pueden efectuar llamadas. También debe poder aplicar restricciones o directivas por cada llamada. En un sistema de voz sobre IP (VoIP, Voice over IP), los clientes deben autenticarse en el servidor para iniciar llamadas. En este sentido es similar a un sistema PBX tradicional, donde el acceso a la línea física bastaba para aplicar la identidad.
El sistema OCS 2007, mostrado en la Figura 1, usa Active Directory® para la autenticación y el almacenamiento de directivas de acceso, y OCS autoriza las llamadas al validarlas con las directivas para un usuario en Active Directory. Como OCS usa la misma información de Active Directory que emplean otras aplicaciones de Microsoft, como Exchange Server o Microsoft® Outlook®, puede agregar capacidades de voz a los usuarios existentes en Active Directory si amplía sus propiedades y directivas (mediante extensiones de esquema de Active Directory) y proporciona un directorio unificado que se puede usar para aplicaciones en tiempo real, como voz o MI.
Figura 1 Componentes de la comunicación unificada de OCS
Figura 1 Componentes de la comunicación unificada de OCS
En Active Directory, la propiedad más importante relacionada con la comunicación unificada es la dirección del protocolo de inicio de sesión (SIP, Session Initiation Protocol), también denominada URI del SIP, cuya naturaleza es muy similar a la dirección de correo electrónico del usuario. Por ejemplo, a un usuario de Active Directory con la dirección de correo electrónico alguien@contoso.com se le asignaría una dirección SIP sip:alguien@contoso.com. Como la dirección SIP está vinculada al objeto de usuario, se puede proporcionar una identidad individual donde las mismas credenciales que el usuario usa para iniciar sesión en su equipo de escritorio o servidor Exchange se pueden emplear para iniciar sesión en su servidor OCS.
Otra propiedad importante es el número de teléfono de usuario. El servidor OCS cambia internamente el destino de las llamadas enviadas a los números de teléfono por el URI del SIP de un usuario para poder enrutar la llamada.
OCS 2007 ofrece una interfaz de servicio de libreta de direcciones (ABS, Address Book Service), que está disponible para la búsqueda de directorio en una organización. Como versión sin conexión de la libreta de direcciones, permite que los extremos de cliente eviten consultar Active Directory cada vez que se realiza una operación de búsqueda en el extremo de cliente.
Además de ABS, OCS 2007 hace que las listas de distribución sean más útiles al proporcionar un servicio de expansión de lista de distribución (DLX, Distribution List Expansion) que permite a los usuarios ver la misma lista de distribución en Office Communicator que ven en Outlook y expandirla también en Communicator. Los usuarios pueden configurar llamadas de conferencia con los miembros de estas listas de distribución desde Office Communicator directamente o iniciar un chat de MI de grupo.

Servicios de voz y de mensajería
Recursos de OCS adicionales
Para obtener más información, consulte los recursos siguientes:
  • Eventos y difusiones por web de comunicaciones unificadas
  • Office Communications Server TechCenter
  • Práctica virtual de TechNet: Habilitación de usuarios e instalación de Office Communicator 2007

Una solución de voz empresarial debe proporcionar las características de control de llamadas con las que están familiarizados los usuarios. Con esta idea, OCS 2007 proporciona características conocidas como llamada en espera, transferencia de llamadas y transferencia de consulta, desvío y llamadas simultáneas, además de modos que no son de voz, como MI.
OCS 2007 es la base del enrutamiento de llamadas de voz y proporciona funciones de enrutamiento de llamadas tanto entrantes como salientes. El enrutamiento de llamadas salientes supone convertir números, aplicar directivas (como la restricción de llamadas internacionales) relacionadas con un usuario y enrutar la llamada a los extremos adecuados o a la red telefónica conmutada (RTC). Las funciones de enrutamiento de llamadas entrantes tienen en cuenta el desvío de llamadas seleccionado o la hora del día y las preferencias de presencia. A continuación, enrutan la llamada entrante de la forma adecuada.
OCS no termina las llamadas entrantes. En el lenguaje de SIP, actúa como registro de SIP y proxy de SIP. Los extremos de cliente del sistema proporcionan la señalización y los medios punto a punto por completo. Los extremos del sistema, como Office Communicator 2007, proporcionan un códec de audio de banda ancha (denominado RTAudio) que se adapta y resiste las condiciones de la red.
OCS 2007 proporciona conferencia web mediante funciones de Conferencing Server para todos los modos de comunicación: audio/vídeo, MI y datos. Los servidores de Conferencing Server basados en OCS permiten extremos de cliente para proporcionar una transición sin problemas desde una comunicación de igual a igual a otra de múltiples participantes y modos con capacidades como desactivación de audio, expulsión de participantes y bloqueos. Se puede ampliar a centenares de participantes para conferencias programadas y hasta un centenar de debates ad hoc. Se pueden programar conferencias mediante complementos de Outlook o realizar una extensión de llamada a una conferencia. La solución de conferencia también proporciona herramientas como el uso compartido de archivos, el uso de pizarra y la grabación.
Evidentemente, se debe poder proporcionar conectividad a las redes RTC externas y números de teléfono, así como a empresas federadas o instalaciones PBX existentes dentro de la organización. OCS 2007 se integra con puertas de enlace de SIP a RTC que ofrecen los proveedores de puerta de enlace habituales que permiten la conexión a RTC o a un PBX existente. Se puede configurar un servidor de mediación para la conversión de códec y de señalización. Los servidores de mediación son opcionales y están configurados para puertas de enlace que no son compatibles con los códecs de Microsoft.
Mensajería unificada de Exchange Server 2007 es la solución de correo de voz para OCS 2007. Mensajería unificada de Exchange proporciona una central de mensajes de llamadas de voz y de fax entrantes y guarda el mensaje recibido en el buzón de Exchange del usuario. Además, Mensajería unificada de Exchange proporciona operadores automáticos empresariales para autores de llamada que busquen a una determinada persona o departamento.
OCS proporciona MI en tiempo real como alternativa al uso de voz y también permite que los usuarios participen en conversaciones multimodo en las que intervienen voz, vídeo y MI simultáneamente. Además, Office Communicator 2007 permite texto enriquecido y formato en MI. Además, el audio y el vídeo se pueden agregar en cualquier momento a la sesión de MI, con lo que la conversación de MI se amplía sin problemas a una conversación de audio.
La contabilidad, el registro y la solución de problemas son componentes adicionales. La contabilidad se ofrece mediante la funcionalidad de servidor Registro de detalles de llamadas de OCS 2007. Por cada llamada que se efectúa en el sistema, se crea un registro de la hora en que entró llamada, el destino que respondió la llamada y otros parámetros diferentes, como, por ejemplo, si la llamada se transfirió. OCS también proporciona servidores de archivado que registran las conversaciones de MI para cumplir los requisitos de cumplimiento. El servidor de supervisión de calidad de experiencia (QoE) almacena la información acerca de la calidad de las llamadas que se han realizado y se puede usar para solucionar problemas de calidad de voz en la red.

Registro e inicialización
Cada extremo de cliente del sistema OCS debe registrarse o iniciar sesión en OCS como primer paso en la inicialización del cliente. El registro es el proceso de conectarse al servidor OCS y este paso anuncia la existencia del cliente. El proceso de registro implica la autenticación de la identidad de usuario por parte del servidor. Esto también crea una asociación de seguridad entre la instancia de cliente y el servidor. Esta asociación de seguridad se usa para las llamadas posteriores que el cliente hace a través del servidor y se actualiza periódicamente por el cliente volviéndose a registrar. La duración del nuevo registro varía según la topología de servidor. Por ejemplo, los extremos de cliente registrados desde fuera de la empresa mediante un servidor perimetral de Microsoft AccessTM actualizan su registro con más frecuencia que los clientes de dentro del firewall empresarial.
Tenga en cuenta que sólo deben registrarse los extremos de cliente que necesitan un canal autenticado persistente con OCS para recibir notificaciones entrantes tales como llamadas de voz o notificaciones de cambio de presencia. Live Meeting es un extremo de cliente que necesita una conexión a OCS sólo para unirse a una reunión y, por lo tanto, no necesita registrarse con OCS.
Para comprender mejor los detalles de la interacción de cliente en OCS 2007, examinemos Office Communicator como extremo de cliente. La mayoría de los flujos de señalización que se relacionan con Office Communicator son idénticos a los que se usan para otros extremos de cliente, como Office Communicator Phone Edition u Office Communicator Mobile. Una vez completado el registro, Office Communicator recupera la información de configuración que es crítica para el funcionamiento del extremo de cliente. Esta información incluye:
  • Información propia, como tarjeta de contacto, dirección de correo electrónico, URI del SIP, nombre descriptivo y número de teléfono.
  • Capacidades que están habilitadas en el cliente y directivas.
  • Direcciones de servidor, como la dirección SIP del servidor perimetral de AV y la dirección del servidor de correo de voz.
  • Lista de contactos de conocidos almacenada en el servidor.
  • Reglas de formato de número para la ubicación del cliente.
Este mecanismo para recuperar toda la información de aprovisionamiento mediante el canal SIP existente al servidor se denomina aprovisionamiento en banda. Esto permite que los extremos de cliente se configuren de forma automática y actualicen su configuración siempre que los clientes inicien sesión y también desde fuera de la red o del firewall.
La secuencia de registro va desde el registro con el servidor hasta la inicialización, la obtención y la configuración de la presencia y, finalmente, el acceso al estado de listo (consulte la Figura 2). Tenga en cuenta que OCS admite que se registren múltiples extremos de cliente para el mismo usuario o URI del SIP. Durante el registro, el servidor devuelve una dirección SIP única al cliente para que toda señal entrante se pueda dirigir al cliente específico. Esta dirección también se denomina URI de usuario global enrutable (GRUU, Globally Routable User URI). El servidor OCS asigna una dirección GRUU independiente a cada uno de los extremos de cliente que se registran con OCS, con lo que se identifican de forma exclusiva.
Figura 2 Procedimiento de registro
Figura 2 Procedimiento de registro
Para mantener el registro bajo control, existe un límite de ocho registros activos permitidos por el servidor para cualquier usuario. Cuando múltiples clientes se registran para el mismo usuario, la configuración se denomina múltiples puntos de presencia (MPOP). Cuando sólo se registra un único cliente, se denomina punto único de presencia (SPOP, Single Point of Presence).
El concepto de MPOP es esencial en el sistema OCS. Permite que el usuario reciba llamadas entrantes o notificaciones de MI desde cualquier extremo, lo que permite fundamentalmente que el usuario tenga varios extremos de teléfono o MI. Introduce una dinámica interesante para responder a MI o incluso para representar la presencia de un usuario de forma precisa.
Por ejemplo, un usuario remoto puede haber iniciado sesión en un teléfono IP de Communicator Phone Edition (un extremo SPOP) que no puede recibir MI. El teléfono IP publica esta capacidad del extremo junto con la información de la presencia. El estado de presencia del usuario en el teléfono es Conectado. Otro usuario puede ver el estado de presencia Conectado e intentar enviar un MI mediante Communicator. Sin embargo, dado que la presencia ya ha publicado la capacidad del dispositivo, se muestra una notificación de que el usuario remoto no está en un dispositivo que admita MI y, por lo tanto, no puede recibir el mensaje.
Otro ejemplo es la aceptación automática de MI. Siempre que se inicia una conversación de MI, el mensaje se acepta de forma automática e inmediata si el usuario se encuentra en una sola instancia de Communicator (de nuevo, un extremo SPOP). Pero si el usuario remoto inicia sesión en dos instancias de Communicator (por ejemplo, un equipo portátil y otro de escritorio), se proporciona un retardo de 10 segundos para permitir que acepte el mensaje instantáneo de un dispositivo. Cuando no hay respuesta, el mensaje instantáneo se acepta automáticamente en la instancia de Communicator más activa.

Presencia
La presencia desempeña una función importante en las comunicaciones unificadas. Permite que un usuario conozca de antemano la disponibilidad del usuario remoto para comunicarse mediante un modo determinado. De esta forma, los estados de OCS, como "no disponible: en una llamada", se asocian al estado de disponibilidad de un usuario en vez de indicar si un dispositivo o una línea están disponibles. Asimismo, OCS 2007 proporciona una infraestructura de presencia mejorada que permite que el usuario comparta información como ubicación, horas de trabajo y horas de reunión.
Además, OCS permite que el usuario especifique permisos para que los distintos grupos de personas puedan tener acceso a diferentes conjuntos de información de presencia según su nivel de acceso. OCS también emplea el estado de presencia de un usuario, como "No molestar", así como las horas de trabajo y el nivel de permiso proporcionado al autor de llamada para tomar decisiones de enrutamiento en función de si el usuario debe recibir la llamada o se debe enviar al correo de voz.
Los números de teléfono que se muestran para hacer clic en ellos y llamar en Office Communicator proceden de tres ubicaciones: dos se basan en directorio (lista global de direcciones/servidor de libretas de direcciones y contactos de Outlook) y la tercera es la presencia. Mediante la presencia, los usuarios tienen la flexibilidad de publicar los números de teléfono que desean que vean otras personas.
La presencia también constituye una parte clave en numerosos escenarios de enrutamiento de voz. Por ejemplo, si la presencia de un usuario remoto indica No disponible y muestra el texto En una reunión, la probabilidad de que el usuario atenderá una llamada de voz es baja. En este caso, el autor de la llamada puede preferir el uso de MI o del correo electrónico. Del mismo modo, cuando la presencia de un usuario remoto es No molestar, se trata de una indicación de que se puede preferir un medio de comunicación alternativo.
La presencia también incluye información acerca del nombre de la reunión actual y la ubicación de calendario de un usuario y estos detalles se publican para los usuarios en el contenedor Equipo. La presencia incluye información acerca del extremo preferido para una determinada capacidad y esto se usa para seleccionar un extremo que realizará una acción predeterminada. Por ejemplo, la publicación de datos de calendario (que es esencialmente la misma en todos los extremos) se realizará únicamente desde un extremo preferido para la capacidad de calendario. OCS tiene la lógica para elegir el extremo preferido.
En la Figura 3 se destacan las distintas capacidades que la presencia aporta al sistema OCS. La presencia, tal como se ha indicado anteriormente, es una combinación de disponibilidad y predisposición de comunicación. El estado Conectado representa el estado en el que el usuario más desea comunicarse y No molestar es el estado de presencia en el que el usuario menos desea comunicarse. A excepción de No molestar, que se tiene que configurar manualmente, Communicator captura automáticamente todos los demás estados según las distintas condiciones, como, por ejemplo, si el usuario está en una reunión (no disponible) o no se encuentra en el equipo (inactivo, luego ausente), tal como se muestra en la Figura 4.
Figure 3 Cómo se establece la información de presencia (Close Figure 3)

Capacidad | Origen
Disponibilidad y predisposición (Conectado, Sin conexión, Ausente, No disponible, No molestar) | Automático. Basado en estado de reunión, estado de teléfono, etc. También se puede establecer manualmente.
Estado de calendario (En una reunión, ubicación de reunión) | Automático. Basado en la preferencia de usuario.
Capacidad del dispositivo (MI admitida) | Automático. Basado en dispositivo MPOP.
Números de teléfono | Automático. Basado en la preferencia de usuario.
Extremo más activo | Automático. Basado en la actividad de usuario.
Nota | Manual. Anulado por nota Fuera de la oficina.
Nota Fuera de la oficina | Automático. Basado en calendario.
Horas de trabajo | Automático. Basado en los datos de libre/no disponible.
Ubicación | Manual. Basado en la selección de usuario.
Figura 4 La presencia como combinación de disponibilidad y predisposición
Figura 4 La presencia como combinación de disponibilidad y predisposición
Tenga en cuenta que la disponibilidad la pueden impulsar varios dispositivos distintos en los que el usuario haya iniciado sesión actualmente. Como hay varios dispositivos para el mismo usuario y cada uno publica información de presencia y datos de usuario del dispositivo, es necesario que haya una lógica de agregación que presente una vista a los observadores. OCS cuenta con una lógica de agregación que calcula la presencia a partir de varios parámetros, dispositivos y entradas que recibe el sistema de presencia.
Antes de profundizar en la agregación, merece la pena examinar el modo en que la información agregada se publica a los usuarios. OCS 2007 introdujo el concepto de contenedores, que es en cierta medida similar a los niveles de acceso asociados a los círculos sociales. Cada contenedor proporciona una cantidad distinta de información y las personas que se agregan a un contenedor específico sólo tienen acceso a la información que está a disposición de dicho contenedor. Todas las personas de la lista de conocidos del usuario tienen que estar presentes en uno de los contenedores disponibles. Office Communicator permite que el usuario asigne personas a contenedores o los mueva a otros contenedores según el nivel de la relación. Office Communicator usa heurística inteligente para seleccionar el contenedor predeterminado (se muestra en la Figura 5) automáticamente.
Figure 5 Contenedores de presencia (Close Figure 5)

Contenedor | Propósito
Bloqueado | Bloquea la información de presencia. No se permiten las llamadas de los usuarios bloqueados. No obstante, los usuarios bloqueados pueden ver la información de nombre y de dirección de correo electrónico.
Público | Proporciona nombre, cargo, compañía, dirección de correo electrónico y disponibilidad limitada.
Compañía | Proporciona información de contacto de trabajo, programación básica y disponibilidad.
Equipo | Proporciona números de teléfono de trabajo y móvil, programación, disponibilidad y puede interrumpir el usuario cuando se encuentra en estado No molestar.
Personal | Se puede ver toda la información de contacto publicada, incluidos los números particulares y de móvil.
La agregación de presencia en OCS determina la presencia correcta del usuario según distintos estados de presencia que los dispositivos notifican al servidor. En la Figura 6 se ilustra el modo en que la presencia se agrega desde distintos orígenes. Tenga en cuenta que parte de la información, como el estado de presencia y la actividad del usuario, se envía a través del mecanismo de agregación de presencia de OCS antes de que la información esté disponible en los contenedores y los extremos de cliente agregan otra información, como los detalles de contacto, a los contenedores respectivos. El contenedor bloqueado falta porque en él no se ha publicado otra información que no sea la de pertenencia.
Figura 6 Agregación y publicación de presencia
Figura 6 Agregación y publicación de presencia
En el sistema OCS, una relación de presencia se establece cuando un usuario agrega a otro usuario a la lista de contactos (lista de conocidos). Pero el sistema OCS también permite consultar la presencia de otros usuarios en el directorio corporativo sin tener que agregarlos individualmente a los contactos.
La forma más simple de obtener la presencia de otro usuario es buscándolo en Office Communicator. De este modo se genera una consulta individual en el servidor y no una suscripción a las notificaciones del servidor acerca de los cambios de estado de presencia de los usuarios remotos. No obstante, cuando un usuario agrega a otro a su lista de conocidos, se suscribe a las notificaciones acerca de los cambios de estado de presencia para que OCS envíe automáticamente alertas siempre que haya un cambio.

MI y audio
MI aprovecha el registro y la presencia. En el sistema OCS, los mensajes se transmiten de igual a igual y el servidor OCS actúa de proxy que envía los mensajes entre los clientes de Office Communicator.
El primer mensaje que un usuario inicia para otro es importante. Establece la sesión, en lenguaje de SIP. La parte del establecimiento de la sesión consiste en encontrar el cliente MPOP adecuado entre los clientes registrados y aquí es donde OCS desempeña una función importante como proxy. Una vez que el usuario acepta la sesión de MI entrante, o si los extremos MPOP del usuario efectúan una aceptación automática, los mensajes posteriores se trasmiten sin problemas de un extremo a otro sin que OCS necesite encontrar un cliente adecuado.
Los usuarios pueden dejar abiertas las ventanas de conversación de MI en sus escritorios y Office Communicator 2007 finalizará la sesión SIP si no hay actividad en un intervalo de 10 minutos (aunque la ventana de MI permanecerá abierta). Cualquier lado también puede terminar la sesión de MI. Siempre que termine la sesión de MI, Office Communicator 2007 creará automáticamente un elemento de historial para la conversación que registra toda la conversión en la carpeta Historial de conversaciones de Outlook. Se trata de una carpeta especial que Office Communicator crea en Outlook. Esta capacidad de registro en el lado del cliente es opcional y está desactivada de forma predeterminada. Office Communicator usa el historial de conversaciones al reiniciar una conversación con el mismo usuario. Por lo tanto, los usuarios que activen esta característica tendrán una mejor experiencia para continuar la conversación de MI después de que se cierre la ventana de MI.
Tenga en cuenta que las construcciones de MI presentadas aquí para bifurcación y MPOP también se aplican al escenario de voz. En vez de la invitación que contiene una descripción de sesión de MI, incluye una descripción de la sesión de voz en la que se indica la capacidad de audio. OCS aplica la bifurcación a la llamada de voz para todos los extremos, del mismo modo que la aplica para MI.
La señalización de voz deriva mucho de los conceptos de MI, pero introduce la necesidad del tratamiento de medios. Planeo tratar este tema con más detalle en un próximo artículo.

Rajesh Ramanathan ha trabajado en las comunicaciones durante 14 años y actualmente es director de administración de programas en el equipo de Office Communicator. Puede ponerse en contacto con él en la dirección rajeshra@microsoft.com.


 Office Communications Server: Planeaci&#243;n de la implementaci&#243;n de voz de OCS 2007
Office Communications Server Jochen Kunert and Rui Maximo

Planeación de la implementación de voz de OCS 2007
Resumen:
  • Escenarios de integración de telefonía
  • Configuración de Office Communications Server
  • Usuarios, planes de numeración y rutas

Microsoft Office Communications Server (OCS) 2007 es un producto empresarial que integra los medios de comunicación en tiempo real con el reconocimiento de la presencia de usuarios, incluida la conferencia web
(uso compartido de datos, audio y vídeo), mensajería instantánea y conversaciones de audio/video. La integración de OCS 2007 con un sistema PBX existente puede ser desafiante. Office Communications Server 2007 no está diseñado para ser un PBX porque los trabajadores de la información de la actualidad usan diferentes medios de comunicación (correo electrónico, mensajería instantánea, teléfono y correo de voz) en su trabajo diario, mientras que los sistemas PBX sólo ofrecen llamadas de teléfono.
Para proporcionar la flexibilidad que los administradores necesitan para crear la estrategia de integración de telefonía individual o empresarial óptima, Office Communications Server 2007 ofrece tres escenarios de configuración para la integración con los entornos de telefonía existentes. Estos escenarios son: control de llamada remota, Enterprise Voice e integración de Enterprise Voice con PBX.
Este artículo se centra en las consideraciones de planeación para una implementación de telefonía de OCS 2007, que pueda necesitar integrarse con un sistema de telefonía existente. Esta información será de especial interés para los arquitectos de sistemas y los administradores de TI y de telefonía. Además, ofreceremos información general de los demás escenarios, pero nos centraremos en Office Communications Server 2007 Enterprise Voice.

Control de llamada remota
Recursos de OCS adicionales
  • Pro LCS: Administración de Live Communications Server
  • Integración de la telefonía con Office Communications Server 2007
  • Guía de planeación e integración de Enterprise Voice

En un escenario de control de llamada remota (RCC), los usuarios tienen un teléfono de escritorio PBX, IP-PBX o TDM (multiplexado de división de tiempo). Desde el cliente de Office Communicator 2007, pueden realizar y responder llamadas en su teléfono de escritorio sin utilizar el panel de marcado ni levantar el auricular del teléfono. Aunque los usuarios pueden controlar su teléfono de escritorio con Office Communicator 2007, el sistema PBX controla el audio y no se convertirá en una llamada de voz sobre IP (VoIP, Voice-over-IP). Aunque Office Communicator 2007 puede controlar el teléfono de escritorio, las llamadas se pueden seguir realizando y respondiendo desde el teléfono PBX, independientemente de si Office Communicator 2007 se está ejecutando.
Para habilitar RCC con Office Communicator 2007 y OCS 2007, debe implementar una puerta de enlace de protocolo de inicio de sesión (SIP)/aplicación de telefonía basada en equipo (CSTA, Computer Supported Telephony Application), además de habilitar el entorno de Office Communications Server 2007 para RCC. La puerta de enlace de SIP/CSTA debe interactuar con el tipo de sistema PBX que use y debe ser compatible con OCS 2007 debido a que actúa de puente entre los dos sistemas. Para controlar el teléfono PBX, Office Communicator 2007 usa el protocolo CSTA. Este protocolo define un esquema XML para interactuar con conmutadores telefónicos (PBX), según se describe en el estándar 269 de ECMA (European Computer Manufacturers Association), que puede encontrar en www.ecma-international.org/publications/standards/Ecma-269.htm.
Office Communicator 2007 envía comandos CSTA para controlar el teléfono PBX como cargas SIP que Office Communications Server 2007 enruta a la puerta de enlace SIP/CSTA. Office Communications Server 2007 no necesita comprender CSTA. Sólo debe saber cómo enrutarlo. A continuación, la puerta de enlace SIP/CSTA convierte los comandos en protocolo nativo que usa el PBX. Esto se muestra en la Figura 1.
Figura 1 Escenario de integración de RCC
Figura 1 Escenario de integración de RCC
La habilitación de RCC consta de cinco pasos. El primer paso es configurar la puerta de enlace SIP/CSTA para comunicarse con el PBX. A continuación, se configura OCS 2007 para enrutar las solicitudes CSTA a la puerta de enlace SIP/CSTA. El tercer paso es configurar los usuarios para RCC. El cuarto paso es configurar Office Communicator 2007. El quinto paso es definir las reglas de normalización de OCS 2007, que también se usan para la normalización de números de teléfono de la libreta de direcciones y son distintas de las reglas de normalización de números de teléfono que se usan en combinación con Enterprise Voice.

Enterprise Voice
Cuando un usuario se habilita para Enterprise Voice, Office Communicator 2007 u Office Communicator Phone Edition se convierte en su teléfono primario, en vez del teléfono PBX. Office Communicator 2007 tendrá asignado un número de teléfono único (para realizar pruebas, el teléfono PBX existente se puede desviar a una nueva extensión asignada a Office Communicator 2007). Office Communicator 2007, en combinación con un dispositivo de audio USB recomendado, se ocupará tanto del control de llamadas (o señalización) como de los medios (audio y vídeo).
En este escenario, Office Communications Server 2007 enruta las llamadas entre extremos de Office Communicator 2007 en la red IP (llamadas de IP a IP) y enruta las llamadas a la red telefónica conmutada (RTC)/PBX (llamadas de IP a RTC). OCS 2007 aplica las restricciones de marcado en las llamadas enrutadas a la RTC.
Para conectar el entorno de Office Communications Server 2007 a un PBX o RTC, debe implementar una puerta de enlace multimedia, también denominada puerta de enlace SIP/RTC o IP/RTC. La puerta de enlace multimedia se debe emparejar con un servidor de mediación (una función de servidor de OCS 2007) para conectarse al entorno de Office Communications Server 2007, tal como se muestra en la Figura 2. El servidor de mediación y la puerta de enlace multimedia asociada se deben instalar en la misma ubicación física.
Figura 2 Escenario de integración de Enterprise Voice con RTC o un PBX existente
Figura 2 Escenario de integración de Enterprise Voice con RTC o un PBX existente
El servidor de mediación permite la conexión de puertas de enlace multimedia que admiten implementaciones SIP estándar e incluso inseguras con Office Communications Server 2007, ya que OCS 2007 sólo permite la comunicación autenticada y cifrada. Otra tarea del servidor de mediación es ocuparse de las conversiones de códec entre los códecs estándar (G.711, G.723, etc.) y el códec de audio en tiempo real de Microsoft. Para obtener una lista de las puertas de enlace multimedia que admite Office Communications Server 2007, consulte los socios de hardware estratégicos en technet.microsoft.com/bb735838.
Puede conectar las puertas de enlace multimedia directamente con la RTC o con una conexión troncal de interfaz de acceso principal (PRI) de un PBX existente. En la Figura 2 se muestran los escenarios de integración posibles para el escenario de Enterprise Voice con la RTC y un PBX existente. No se requiere un director (normalmente un servidor Office Communications Server Standard Edition) para una implementación de Enterprise Voice. Sin embargo, se recomienda.
La habilitación de Enterprise Voice consta de cuatro pasos. El primer paso es implementar y configurar las puertas de enlace multimedia. Como se trata de un producto de un socio de Microsoft, debe consultar la documentación del fabricante, ya que cada puerta de enlace multimedia tiene distintos pasos de implementación.
A continuación, se implementa un servidor de mediación para cada puerta de enlace multimedia. En este paso, debe configurar una tarjeta de red del servidor de mediación para enviar y recibir tráfico de la puerta de enlace multimedia y configurar la otra tarjeta de red del servidor de mediación para enviar y recibir tráfico desde Office Communications Server 2007 (normalmente un director en una implementación de Enterprise Edition). A menos que la puerta de enlace multimedia sea una avanzada, necesitará la ayuda de una función de servidor de mediación de OCS 2007 para interactuar con la infraestructura de OCS 2007 Enterprise Voice.
El tercer paso es definir un plan de numeración. Esto implica definir directivas de voz, rutas de teléfono y perfiles de ubicación.
Tras ello, se configuran los usuarios para Enterprise Voice. Además, los usuarios deben estar habilitados para Enterprise Voice con el fin de poder realizar y recibir llamadas del PBX o RTC. Esto requiere la asignación de números de teléfono únicos a cada usuario.

Integración de Enterprise Voice con PBX
Esta configuración es una extensión de la configuración de Enterprise Voice. La diferencia es que el teléfono PBX del usuario se sincroniza con el cliente de Office Communicator del usuario. La configuración es similar al escenario de Enterprise Voice en el que se efectúa la conexión a la RTC mediante un PBX, tal como se muestra en la Figura 2. No obstante, en este caso, en vez de reemplazar el teléfono PBX del usuario por un cliente de Office Communicator 2007, Office Communicator 2007 y el teléfono PBX existente usarán el mismo número de teléfono.
Si el autor de la llamada marca la extensión del usuario desde otro teléfono PBX o desde un teléfono RTC, el sistema PBX bifurcará la llamada al teléfono PBX del usuario y al cliente de Office Communicator 2007 del usuario a través de Office Communications Server 2007. El cliente de Office Communicator 2007 del usuario y el teléfono PBX sonarán simultáneamente cuando haya una llamada entrante. Por el contrario, Office Communications Server bifurcará las llamadas iniciadas desde OCS 2007 al PBX a través de la puerta de enlace multimedia. Este escenario no es posible cuando se usa Office Communicator Phone Edition. Esta configuración requiere que el sistema de correo de voz del PBX se ocupe del correo de voz. Mensajería unificada de Exchange Server 2007 no se puede usar como solución de correo de voz para dichos usuarios.
La habilitación de la integración de Enterprise Voice con PBX consta de los mismos pasos que la implementación de Enterprise Voice pero con tres pasos adicionales. En el primer paso adicional, la puerta de enlace multimedia se debe conectar directamente al PBX. A continuación, el PBX se debe configurar para admitir este escenario (según el proveedor, esto puede requerir una actualización de software del PBX). Finalmente, los usuarios se deben habilitar para la integración de PBX.
Microsoft está trabajando para proporcionar asistencia con el fin de conectar el servidor de mediación directamente al PBX IP sin que actúe de intermediaria una puerta de enlace multimedia. Visite technet.microsoft.com/bb735838 para obtener la información más reciente relativa a este tema.

Configuración de Office Communications Server
La funcionalidad de Enterprise Voice se controla mediante servicios que se ejecutan en Office Communications Server 2007 Enterprise Edition y Office Communications Server 2007 Standard Edition. En la Figura 3 se describen los servicios que proporciona la funcionalidad Enterprise Voice para enrutar las llamadas entrantes y salientes.
Figure 3 Servicios de Enterprise Voice (Close Figure 3)

Servicio | Descripción
Servicio de conversión | Aplica reglas de normalización según el perfil de ubicación o el contexto de teléfono.
Servicios de usuario | Realiza la búsqueda de número inversa en el número de teléfono de destino.
Componente de enrutamiento de entrada | Aplica las preferencias de llamada del usuario de destino.
Mensajería unificada de Exchange | Reenvía la solicitud al correo de voz según sea necesario.
Componente de enrutamiento de salida | Determina la ruta óptima basada en el URI y la directiva de usuario.
En la Figura 4 se muestra cómo cada uno de estos componentes actúa en las llamadas entrantes a medida que OCS 2007 las enruta para una llamada de PC a PC. Las llamadas entrantes se pueden originar desde un extremo conectado, como Office Communicator 2007 u Office Communicator Phone Edition, o desde un servidor de mediación procedente de la RTC/PBX (llamada RTC-SIP). Las llamadas salientes que se originan desde uno de los extremos de cliente de Office Communications Server 2007 del autor de la llamada, como Office Communicator 2007, se envían al grupo de Standard Edition Server o Enterprise donde se encuentra hospedado el usuario. Se denomina grupo doméstico del usuario.
Figura 4 Interacción de los servicios relacionados con Enterprise Voice en servidores front-end OCS
Figura 4 Interacción de los servicios relacionados con Enterprise Voice en servidores front-end OCS
En este momento, Office Communications Server 2007 procesa la llamada para determinar dónde enrutarla. Este salto siguiente puede ser el grupo doméstico del receptor, un servidor de mediación o Mensajería unificada de Microsoft® Exchange Server 2007 (consulte la Figura 5). Si la llamada se enruta a otro grupo doméstico, OCS 2007 envía la llamada a todos los extremos activos del receptor. Office Communicator 2007 u Office Communicator Phone Edition del receptor recibirá la llamada y aparecerá una notificación de ventana emergente en el dispositivo.
Figura 5 Enrutamiento de llamadas
Figura 5 Enrutamiento de llamadas
Si la llamada se enruta a un servidor de mediación, el servidor se configura para enrutar a una puerta de enlace multimedia específica. Si la puerta de enlace multimedia está conectada directamente a un PBX, el PBX enruta la llamada a un teléfono de escritorio o a la RTC. No obstante, si la puerta de enlace multimedia está conectada directamente a la RTC, la salida sale a la RTC.
Si el salto siguiente es a Mensajería unificada de Exchange Server 2007, el autor de la llamada puede dejar un mensaje. El correo de voz está disponible independientemente de que el receptor haya iniciado sesión en Office Communications Server 2007.
Cuando el receptor responde, el audio se envía directamente desde Office Communicator 2007 u Office Communicator Phone Edition de la persona que llama a Office Communicator 2007 u Office Communicator Phone Edition del receptor en una llamada de IP a IP. Si la persona que llama usa un teléfono PBX o RTC, el servidor de mediación envía el tráfico de audio directamente a Office Communicator 2007 u Office Communicator Phone Edition del receptor en una llamada de IP a RTC. OCS 2007 se ocupa sólo de la señalización de llamadas, motivo por el que el audio y el vídeo va directamente entre los extremos y no se enruta mediante OCS 2007.

Configuración de usuarios
A los usuarios habilitados para Enterprise Voice se les deben asignar números de teléfono que sean únicos en la organización. Esta configuración se lleva a cabo en Active Directory®. Esto supone una diferencia con respecto a la mayoría de los sistemas de telefonía en los que al teléfono se le asigna el número de teléfono. La ventaja de este diseño es que los usuarios pueden convertir cualquier equipo que ejecute Office Communicator 2007 en su teléfono de trabajo con iniciar sesión en OCS 2007 desde el cliente. Esta característica de portabilidad puede resultar atractiva para los teletrabajadores o empleados de soporte técnico.
El número de teléfono del usuario se especifica en formato E.164 en Active Directory. Este formato define el plan de numeración de telecomunicaciones público internacional, un esquema de numeración que representa los números de teléfono de forma inequívoca. El formato E.164 especifica el número de teléfono con este formato:
+<country code><area code><phone number>
Un usuario habilitado para Enterprise Voice tiene dos representaciones únicas: un URI del SIP y un número de teléfono E.164. Cuando se marca un número de teléfono, Office Communications Server resuelve la representación E.164 del número de teléfono (+14255551212) en el URI del SIP del usuario (joe@contoso.com). A continuación, Office Communications Server 2007 enruta la llamada según el URI del SIP del receptor. Si el número de teléfono no se puede resolver en un URI del SIP, OCS 2007 enruta la llamada al PBX/RTC a través de un servidor de mediación.
Al planear una implementación de Enterprise Voice donde a cada usuario de Office Communications Server se le debe asignar un número de teléfono único, debe tener en cuenta el sistema de telefonía existente. Si se conecta a la RTC directamente mediante una puerta de enlace multimedia, probablemente tendrá extensiones de 2 ó 3 dígitos de bloque de número entero, números de marcado interno directo (DID) que se pueden distribuir a los usuarios de OCS 2007. Si se conecta a la RTC mediante un PBX, probablemente tendrá un bloque de números DID proporcionado por el PBX para asignarlo a los usuarios de OCS 2007.

Planes de numeración
Aunque los números de teléfono con formato E.164 proporcionan una representación única, no es una forma cómoda de marcar números. Tampoco se puede especificar un número con este formato en Office Communicator Phone Edition o en teléfonos PBX/RTC estándar. ¿Cómo se especifica un carácter + con el panel de marcado de 10 dígitos? Los usuarios están acostumbrados a marcar extensiones más cortas, que pueden ser únicas en una ubicación específica pero tal vez no en toda la compañía. Por lo tanto, es necesario especificar las reglas de conversión para convertirlas al formato E.164.
El administrador debe definir los perfiles de ubicación que especifican las reglas de normalización para efectuar estas conversiones de números. Después de que el cliente (Office Communicator 2007 o Communicator Phone Edition) o el servicio de conversión de Office Communications Server 2007 amplía el número de teléfono al formato E.164, los servicios de usuario pueden efectuar la búsqueda de número inversa y hacer coincidir el número E.165 con un URI del SIP correspondiente. Las reglas de normalización definidas en un perfil de ubicación usan expresiones regulares para efectuar la conversión si se encuentra una coincidencia. Por ejemplo, si se marca 1234, una normalización que coincida con un patrón de cuatro dígitos para convertirse en +1425555{4 dígitos} convertiría 1234 en +1425551234. Por lo tanto, los perfiles de ubicación permiten que los usuarios conserven los mismos hábitos de marcado a los que están acostumbrados.
Los administradores pueden asignar perfiles de ubicación a usuarios de las siguientes tres formas:
  • Definir el perfil de ubicación para los usuarios que usen Office Communicator 2007 mediante la directiva de grupo.
  • Permitir que los usuarios seleccionen un perfil de ubicación desde Office Communicator Phone Edition.
  • Asignar un perfil de ubicación al grupo doméstico. A los usuarios hospedados en dicho grupo se les asignará automáticamente ese perfil de ubicación.
La definición de un plan de numeración supone la creación de directivas de voz, rutas de teléfono y perfiles de ubicación con reglas de normalización. Las directivas de voz definen el tipo de acceso de llamada que se permite a los usuarios. Office Communications Server 2007 determina el modo de enrutar las llamadas al PBX/RTC mediante rutas de teléfono. Como los números de teléfono se pueden marcar de muchas formas, las reglas de normalización de un perfil de ubicación definen el modo de convertir el número de teléfono marcado al formato E.164, que, posteriormente, se puede enrutar.
El administrador asocia cada usuario habilitado para Enterprise Voice a una directiva de voz. Una directiva de voz define los privilegios de llamada asignados a un usuario. Los privilegios de llamada determinan las rutas que se permiten usar al usuario y, por lo tanto, los números que puede marcar. Cada usuario se debe asociar a una sola directiva de voz. El administrador crea el número de directivas disponibles.
Cada directiva de voz contiene una configuración para permitir o impedir que los usuarios habiliten las llamadas simultáneas y una lista ordenada de usos de teléfono. La directiva de voz, de modo similar a la directiva de reunión, es un contenedor lógico de configuración definido como un documento XML almacenado en Active Directory. El valor de este diseño es que se puede ampliar en versiones futuras de OCS 2007 para admitir configuraciones de directiva adicionales, sin que sea necesaria una extensión de esquema de Active Directory. Por ejemplo, si una directiva de voz no está asociada a ningún uso de teléfono, tiene el efecto de impedir que los usuarios asignados a dicha directiva realicen llamadas salientes al PBX/RTC. Dichos usuarios sólo podrán efectuar llamadas de IP a IP.

Uso y rutas de teléfono
Un uso de teléfono define los privilegios de enrutamiento de teléfono que se permiten a los usuarios. Un uso de teléfono es una colección de rutas de teléfono. Es una cadena que debe ser una palabra única, lo que significa que ningún otro uso de teléfono puede tener el mismo nombre. Los administradores pueden crear tantos usos como deseen.
Aunque una directiva de voz se puede asociar directamente a una ruta o a un conjunto de rutas, en vez de usos de teléfono, la palabra clave de uso de teléfono es una abstracción para mantener la asociación entre directivas y rutas. Si las directivas estuvieran asociadas directamente a las rutas, con lo que quitaría el concepto de usos de teléfono, y el administrador modificara el nombre de una ruta, cada directiva asociada a dicha ruta se tendría que actualizar. Mediante un uso de teléfono, que es un atributo de una directiva y de una ruta para crear la asociación entre directiva y ruta, la relación entre directiva y ruta se mantiene aunque se cambie el nombre de la ruta.
Una ruta contiene un patrón de número de teléfono y una lista de servidores de mediación conectados a puertas de enlace multimedia. Una ruta se debe asignar como mínimo a un uso de teléfono. Esta asociación entre el patrón y las puertas de enlace especifica el modo de enrutar los números de teléfono que coinciden con ese patrón concreto.
El patrón especifica un intervalo de números de teléfono con los que puede coincidir. Se define como una expresión regular que puede incluir y excluir números de teléfono. Se incluye la herramienta Enterprise Voice Route Helper para ayudar a crear estas expresiones regulares más fácilmente. En consecuencia, si el número de teléfono que se marca coincide con el patrón de expresión regular de la ruta, la llamada se enruta a una de las puertas de enlace definidas en la ruta.
En una sola ruta se pueden enumerar varios servidores de mediación (y, por lo tanto, puertas de enlace multimedia). Office Communications Server 2007 enruta la llamada a los servidores de mediación en una operación por turnos para equilibrar el tráfico entre las puertas de enlace. Si se produce un error en una puerta de enlace o está fuera de servicio por mantenimiento, el servidor de mediación correspondiente enviará una respuesta a Office Communications Server 2007, que intentará inmediatamente enrutar la llamada a otro servidor de mediación (y, por lo tanto, otra puerta de enlace multimedia) de la lista de la ruta.
Después de 10 intentos de enrutar llamadas a una puerta de enlace multimedia con error, Office Communications Server 2007 reducirá el tráfico a dicha puerta de enlace multimedia hasta que vuelva a responder. Si la puerta de enlace multimedia sigue sin responder después de 10 intentos adicionales, Office Communications Server 2007 dejará de enrutar las llamadas a dicha puerta de enlace multimedia hasta que responda.
La lista de puertas de enlace multimedia definidas en la ruta de teléfono se describe mediante el nombre de dominio completo y el número de puerto de la puerta de enlace. Si el número de teléfono no coincide con el patrón de expresión regular, se comprueba la siguiente ruta asociada al uso de teléfono asignado al usuario hasta que se encuentra una coincidencia. Si no se encuentra ninguna coincidencia, la llamada no se puede enrutar y no llega a su destino. El usuario recibe una notificación de que la llamada no se puede completar.

Pasos siguientes
Office Communications Server 2007 proporciona tres niveles de integración de telefonía. Al planear la implementación de telefonía, debe determinar el nivel que mejor se adapta a sus necesidades de negocios de telefonía actuales y futuras. Después de determinarlo, puede planear la implementación. Un aspecto importante de la planeación es definir un plan de numeración para la implementación de Office Communications Server Enterprise Voice. Se debe considerar con cuidado.
Consulte la barra lateral "Recursos de OCS 2007 adicionales" para obtener más información acerca de Office Communications Server 2007 Enterprise Voice y las tecnologías relacionadas.

Jochen Kunert tiene 10 años de experiencia en el sector de las telecomunicaciones y ahora trabaja como administrador jefe de programas en Office Communications Group en Microsoft. Es coautor del libro que se publicará pronto, Microsoft Office Communications Server 2007 Resource Kit. Puede ponerse en contacto con Jochen en la dirección jkunert@microsoft.com.
Rui Maximo es un veterano de 14 años del sector de TI y coautor de dos libros, Pro LCS: Live Communications Server Administration y Microsoft Office Communications Server 2007 Resource Kit. Puede ponerse en contacto con Rui en la dirección ruim@ruimaximo.com.


 Sistemas de alto rendimiento: Introducci&#243;n a Windows Compute Cluster Server
Sistemas de alto rendimiento John Kelbley and Doug Lindsey

Introducción a Windows Compute Cluster Server
Resumen:
  • Usar clústeres para resolver problemas complejos
  • Requisitos generales para clústeres de cálculo
  • Configurar un clúster de cálculo basado en Windows
  • Ejecutar comandos de forma remota

Los sistemas de alto rendimiento (HPC, High Performance Computing) hacen referencia a una rama de la computación aplicada que se centra fundamentalmente en la solución de problemas que hacen un uso intensivo del cálculo. Hace unos años, los sistemas de alto rendimiento (a los que se hacía referencia habitualmente como "supercomputación") estaban dominados por
sistemas grandes y especializados (costosos) que se encontraban principalmente en centros de investigación. No obstante, a medida que la capacidad de cálculo de los sistemas pequeños ha aumentado, ha cambiado la relación costo-rendimiento y las cargas de cálculo se han desplazado a los sistemas de PC.
Muchos problemas de cálculo intensivo se pueden solucionar mediante la realización de cálculos en paralelo, es decir, un cálculo o proceso concreto no puede depender del resultado de otro para completarse. En casos como éste, los problemas grandes pueden sacar partido de múltiples sistemas de menor tamaño (nodos) agrupados en clústeres de cálculo. A continuación se indican algunos ejemplos de los tipos de aplicaciones que aprovechan los clústeres de cálculo:
  • Modelos financieros: un algoritmo o una fórmula se ejecutan miles de veces cada una de ella con datos distintos.
  • Ingeniería: simulación de los efectos en piezas individuales, aplicación de texturas a modelos.
  • Animación informática: aplicación de efectos de textura e iluminación a cada fotograma de una película.
Los clústeres de cálculo proporcionan una forma económica de solucionar problemas complejos en un breve período de tiempo. Como verá, Microsoft proporciona funcionalidad y asistencia claves para los clústeres de cálculo con Windows® Compute Cluster Server 2003.
Es importante entender que un clúster de cálculo es distinto de un clúster de disponibilidad (conmutación por error). Puede que ya esté familiarizado con los clústeres de disponibilidad para Exchange, SQL Server® u otras aplicaciones en Windows Server® 2003. Normalmente aprovechan el almacenamiento compartido para maximizar el tiempo de actividad de las aplicaciones. La finalidad de los clústeres de cálculo no es reanudar el trabajo de otro sistema si se produce una interrupción, sino permitir que todos los nodos funcionen de un modo coordinado.

Requisitos generales para un clúster de cálculo
Recursos de HPC
  • Comunidad de HPC de Windows
  • Sistemas de alto rendimiento con WCCS 2003
  • Introducción a la informática de 64 bits de Microsoft
  • Inicio de servidores de Microsoft
  • Compute Cluster Server TechCenter
  • Guía paso a paso para instalar, configurar y optimizar una implementación de clústeres de cálculo de alto rendimiento

Los sistemas modernos de HPC comparten algunos elementos clave que facilitan el procesamiento de cargas de trabajo. Para comenzar, se necesitan varios sistemas. También se necesita un programador que coordine las asignaciones de trabajo en los nodos. El programador se ejecuta en el nodo encargado (el nodo principal) e identifica los recursos disponibles, asigna y distribuye tareas y realiza el seguimiento del estado general de los trabajos. Es el coordinador de recursos en el clúster de sistemas así como el punto al que los usuarios y administradores envían los trabajos para su procesamiento.
Los clústeres requieren un medio de comunicación entre los nodos. Según el tipo del trabajo, los nodos pueden necesitar interconexiones de alta velocidad y latencia baja para pasarse mensajes entre sí con el fin de coordinar el procesamiento. Como mínimo, cada nodo de cálculo y el nodo principal deben estar conectados a una red común.
Una gran cantidad de sistemas interconectados que trabajan juntos para solucionar problemas complejos también necesita atención. Se necesitan procesos y herramientas dirigidos al aprovisionamiento, la supervisión, la administración y el mantenimiento de decenas a centenares o miles de sistemas para garantizar un entorno coherente y estable.
Finalmente, y más importante, se debe disponer de aplicaciones que puedan aprovechar las capacidades de procesamiento en paralelo de un clúster de cálculo. Sin aplicaciones que puedan dividir los trabajos para que se puedan procesar en varios equipos o herramientas de desarrollo que incluyan compatibilidad con un "depurador en paralelo", poco puede hacer un clúster aparte de calentar la sala de equipos.

Agrupación en clústeres basada en Windows Server
En 2006, Microsoft presentó Windows Server 2003 Compute Cluster Edition (CCE) y Windows Compute Cluster Server 2003 (WCCS) para satisfacer las necesidades de una amplia gama de aplicaciones HPC. CCE y WCCS se basan en el mismo Windows Server 2003 con que el que ya está familiarizado. CCE es una versión de Windows Server 2003 con licencia para su uso con aplicaciones HPC. WCCS es idéntico a CCE con la adición de Microsoft® Compute Cluster Pack (CCP). Esto significa que puede implementar, administrar, supervisar y mantener un clúster basado en Windows Server con las mismas herramientas que ya usa para administrar sistemas Windows Server 2003 existentes.
Un punto clave que se debe tener en cuenta es que CCE y WCCS sólo están disponibles en versión x64. No hay versión de 32 bits (x86) de estos productos. Los requisitos de hardware para CCE y WCCS son idénticos a los de Windows Server 2003 Standard x64 Edition. Además de admitir hardware de alto rendimiento (arquitectura de 64 bits), los productos incluyen compatibilidad con el acceso remoto directo a memoria (RDMA, Remote Direct Memory Access) para las interconexiones de alto rendimiento (Gigabit Ethernet, InfiniBand, Myrinet y otros).

Compute Cluster Pack
Tal como se ha mencionado anteriormente, los clústeres de cálculo tienen algunos requisitos básicos que se pueden cumplir con la instalación de Compute Cluster Pack. CCP es un paquete independiente de instalación que incluye:
  • Programador de trabajos integrado
  • Compatibilidad con Interfaz de transferencia de mensajes (MPI, Messaging Passing Interface) para el estándar MPICH2
  • Administración de recursos de clúster y herramientas de usuario
CCP es el diferenciador clave entre CCE y WCCS. Tal vez se pregunte el motivo de que, si los clústeres de cálculo necesitan estos componentes, sólo estén incluidos en WCCS y no en CCE. La respuesta es que algunas soluciones HPC aprovechan distintos programadores de trabajos o MIP especializadas (o no requieren compatibilidad con MPI) y simplemente requieren una plataforma excepcional en la que se puedan ejecutar, como Windows Server 2003. Como CCP es un paquete estándar, se puede instalar en otras versiones x64 de Windows Server 2003 (CCE, Standard, Standard R2, Enterprise y Enterprise R2).

Datos básicos
WCCS aprovecha los elementos fundamentales y clave de Windows para simplificar la administración y el funcionamiento de los clústeres basados en Windows, incluido Active Directory® y Servicios de instalación remota (RIS, Remote Installation Services). Compute Cluster Server usa Active Directory para administrar la seguridad de un modo transparente. Con Active Directory, un usuario puede enviar un trabajo al nodo principal (con un único conjunto de credenciales) que se puede ejecutar en centenares de nodos de servidor. Cuando los trabajos se ejecutan en uno o varios nodos de cálculo, se ejecutan en el contexto de las credenciales de usuario proporcionadas al enviar el trabajo y, en lo sucesivo, se almacenan en caché de forma segura. WCCS se basa en Active Directory para proporcionar esta funcionalidad de "punto único de inicio de sesión". Una ventaja adicional de que Active Directory se encuentre en el entorno reside en el hecho de que la directiva de servidor y configuración se puede administrar de forma centralizada mediante la directiva de grupo.
Si su organización de TI ya tiene Active Directory implementado, puede ahorrar un tiempo considerable y esfuerzos administrativos si crea el clúster en el dominio existente. Es el escenario recomendado.
Si necesita implementar un clúster de cálculo en un entorno donde no existe Active Directory, una práctica recomendada es implementar uno o varios controladores de dominio dedicados para hospedar Active Directory para el clúster. Es muy habitual convertir el nodo principal en un controlador de dominio de Active Directory, ya que todos los nodos ya tienen conectividad de red al sistema, independientemente de la topología de red. No obstante, no se recomienda convertir el nodo principal en controlador de dominio para clústeres a gran escala debido a la mayor carga en dicho nodo. Se deben seguir las prácticas habituales para la implementación y la administración de Active Directory (instalación de controladores de dominio redundantes, copias de seguridad adecuadas, buenas prácticas de seguridad, etc.).

Servicio de instalación remota
WCCS proporciona un front-end integrado para la plataforma de implementación de imágenes del servicio de instalación remota de Microsoft. RIS se usa para implementar imágenes de sistema operativo desde el nodo principal a cada uno de los nodos de cálculo, lo que significa que puede usar RIS para instalar nuevos nodos de clúster rápidamente. No tiene que hacerlo de esta forma, ya que, por comodidad, RIS está integrado en WCSS. También se pueden usar otras tecnologías de implementación de Windows Server habituales, como Windows Server 2003 Automated Deployment Services (ADS) o una instalación manual de Windows Server 2003.
Si desea usar RIS, antes de instalar CCP en el nodo principal, asegúrese de que tiene definidos dos discos lógicos como mínimo. RIS requiere un disco independiente del sistema operativo para el almacenamiento de las imágenes de servidor. La partición de RIS debe disponer de suficiente espacio libre en disco para almacenar una o varias copias completas de una imagen de Windows Server.
El hardware de servidor más reciente, en concreto el destinado a redes y almacenamiento, puede requerir controladores Plug and Play que no se incluyen en las imágenes de Windows Server 2003 predeterminadas. En este caso, necesitará agregar estos controladores a la imagen manualmente. El procedimiento para hacerlo está documentado en línea en support.microsoft.com/kb/254078.

Instalación del clúster
El primer paso es configurar el cerebro del clúster: el nodo principal. Empiece con la instalación de una de las versiones x64 de Windows Server 2003 indicadas anteriormente. Durante la instalación del sistema operativo, elija si unirá el servidor a un dominio existente (recomendado) o si instalará Active Directory en el servidor (no recomendado para clústeres a gran escala).
Después instalar el sistema operativo, asegúrese de que también ha descargado e instalado todas las correcciones recomendadas desde Microsoft Update. Si planea usar RIS para la creación de imágenes de nodo de cálculo, deberá usar la herramienta administrativa Administración de equipos | Administración de discos para asegurarse de que tiene definidos dos discos lógicos como mínimo. Por cuestiones de espacio, no trataremos la instalación basada en RIS en este artículo.
Después de haber iniciado la sesión correctamente y haber actualizado el servidor, se ejecuta el programa de instalación de CCP. El programa de instalación de CCP instalará o le guiará por la descarga e instalación de los siguientes archivos y actualizaciones de requisitos previos:
  • Revisión de RIS (consulte go.microsoft.com/fwlink/?linkid=55167)
  • Microsoft Management Console (MMC) 3.0 (consulte go.microsoft.com/fwlink/?linkid=62400)
  • SQL Server Desktop Edition, que se instala como parte del proceso de instalación del nodo principal de Compute Cluster Server 2003
  • Microsoft .NET Framework 2.0
El programa de instalación de CCP lleva a cabo un trabajo excepcional al evaluar la preparación del sistema para la instalación. Le indicará los componentes que son necesarios y que se instalan como parte del proceso, y los instalará, tal como se muestra en la Figura 1.
Figura 1 Componentes requeridos para la instalación de CCP
Figura 1 Componentes requeridos para la instalación de CCP

Lista de tareas pendientes
Cuando termina la instalación de CCP, se iniciará la consola del administrador, con el enfoque en la lista de tareas pendientes. Tal como se muestra en la Figura 2, la lista de tareas pendientes incluye varios paneles, cada uno para un área distinta y en el que se enumeran las tareas para completar la configuración del clúster.
Figura 2 La lista de tareas pendientes muestra lo que se debe hacer para configurar el clúster
Figura 2 La lista de tareas pendientes muestra lo que se debe hacer para configurar el clúster
La lista de tareas pendientes permite implementar fácilmente la arquitectura de clúster que ha diseñado, incluida la selección y configuración de la topología de red, el proceso de instalación de nodos y el modelo de administración de usuarios. Las tareas de cada uno de los paneles se enumeran en la parte derecha y cada tarea inicia un asistente. Complete cada tarea en secuencia para configurar totalmente un nodo principal que esté preparado para implementar imágenes RIS en un conjunto conocido de nodos de cálculo y que un conjunto definido de usuarios pueda administrarlo y tener acceso a él.
Topología de red WCCS es compatible con las cinco topologías de red más habituales que se usan en HPC. Como mínimo, todos los nodos de cálculo y el nodo principal deben compartir una red común. Las topologías incluyen compatibilidad con varios tipos de interconexiones entre los nodos y tienen distintas ventajas y costos.
La topología de red dependerá de los requisitos de rendimiento, seguridad e implementación para el clúster. Por ejemplo, puede que la aplicación requiera una interconexión de alta velocidad para la transmisión de mensajes que no desea exponer en la red corporativa. Tal vez desea aprovechar las capacidades de implementación integrada, basada en RIS y automatizada. Quizás el software que ha elegido sólo puede aceptar una sola NIC o, posiblemente, desea que el nodo principal ejecute Conexión compartida a Internet (ICS, Internet Connection Sharing) para administrar la resolución de nombres y el direccionamiento de los nodos de cálculo. El asistente "Configurar la topología de red de clúster" invocado desde la lista de tareas pendientes presentará las cinco topologías normalmente compatibles con las implementaciones de HPC y le ayudará a configurar las conexiones de red, incluidas las configuraciones de Firewall de Windows en el nodo principal y en los nodos de cálculo. En la Figura 3 se muestra una de las topologías de red admitidas.
Figura 3 Una de las topologías de red WCCS admitidas
Figura 3 Una de las topologías de red WCCS admitidas
Servicio de instalación remota Tal como se ha indicado anteriormente, RIS permite la implementación automática de los nodos de clúster.
Administración de nodos Tiene la capacidad de especificar los nombres de equipo de los servidores que serán nodos de cálculo en este clúster. Cuando CCP se ejecuta en un nodo, en este momento se especifica el nodo principal del clúster al que se unirá dicho nodo.
Administración de usuarios Aquí puede especificar las cuentas de usuario o grupos de Active Directory que se designarán como usuarios del clúster.

Instalación de nodos
La implementación de nodos de cálculo se puede realizar automáticamente mediante la utilidad de administración RIS u otros métodos de implementación admitidos. Al igual que sucede con el nodo principal, el CCP se debe instalar en cada nodo de cálculo. Tal como muestra la Figura 4, las opciones de configuración de la instalación de CCP son mucho más simples para un nodo de cálculo y son las siguientes:
Figura 4 Instalación de Compute Cluster Pack
Figura 4 Instalación de Compute Cluster Pack
  • Especificación de que el servidor debe ser un nodo de cálculo (y no un nodo principal).
  • Especificación del nombre del nodo principal del clúster al que debe unirse el servidor.
  • Especificación de si se instalarán las herramientas administrativas y de usuario en el nodo de cálculo.

Consola de administrador
Después de que los nodos estén en comunicación con el nodo principal, la mayoría de las tareas de administración de todos los sistemas se pueden llevar a cabo mediante la consola del administrador, que se muestra en la Figura 5. La consola proporciona una vista central del clúster entero, incluida una lista de todos los nodos asociados, acceso a acciones administrativas clave y otros detalles. El panel situado más a la izquierda proporciona navegación de alto nivel por la consola, incluido el acceso al "Administrador de clústeres" que, cuando está resaltado, proporciona una página de resumen que muestra el estado de clúster y las estadísticas de trabajo. El acceso a todas las sesiones de escritorio remoto y de monitor de sistema se puede administrar desde aquí, pero la mayor parte del tiempo de administración del clúster se realizará con "Administración de nodos".
Figura 5 La consola del administrador ofrece una vista de todo el clúster
Figura 5 La consola del administrador ofrece una vista de todo el clúster
Debe explorar la consola del administrador por su cuenta, ya que proporciona acceso a herramientas y funciones clave necesarias para administrar Windows y los nodos de clúster de forma centralizada. Al hacer clic una vez en un nodo de clúster del panel central superior se rellenarán otras ventanas y podrá empezar a explorar las funciones específicas del nodo.
Las funciones admitidas del menú contextual permiten administrar fácilmente nodos de cálculo de forma centralizada desde Administración de nodos. Puede usar Administración de nodos para pausar y reanudar nodos, aprobar nodos para el clúster o quitarlos de él, iniciar escritorios remotos, el monitor de sistema o el visor de eventos, o bien expulsar la bandeja del CD (lo que puede resultar muy útil cuando se intenta identificar físicamente un equipo individual en un clúster grande).

ClusRun, una herramienta interesante
La característica más interesante de esta lista es "Comando Ejecutar", es decir, la capacidad de ejecutar un comando arbitrario de forma remota, como si se estuviera delante del símbolo del sistema del equipo de destino. WCCS incluye una versión de la línea de comandos de la característica Comando Ejecutar denominada Clusrun.exe y "ClusRun" se usa para describir tanto la versión GUI como la de la línea de comandos.
No se puede poner demasiado énfasis en las ventajas de la utilidad ClusRun, en concreto en un clúster grande. Ahorra mucho tiempo al ejecutar tareas repetitivas de la línea de comandos y normalmente puede eliminar la necesidad de escribir scripts administrativos complejos.
Para usar esta característica, resalte una lista de equipos en los que desee ejecutar un comando, haga clic con el botón secundario del mouse y seleccione Comando Ejecutar. Se muestra el cuadro de diálogo de la Figura 6. Ahora escriba el comando que desee, haga clic en Ejecutar y espere a que el resultado se muestre en la ventana de resultados. Se le pedirán las credenciales la primera vez que use ClusRun, pero puede optar por almacenarlas en caché para su uso posterior.
Figura 6 Puede ejecutar un comando en múltiples nodos
Figura 6 Puede ejecutar un comando en múltiples nodos
Una forma habitual de aplicar revisiones a los clústeres o de instalar programas que incluyan rutinas de instalación automatizadas consiste en colocarlos en un recurso compartido de red y, a continuación, usar ClusRun para que todos los nodos de cálculo invoquen el comando. El reinicio de todos los nodos de cálculo del clúster entero se puede realizar mediante un solo comando:
CLUSRUN SHUTDOWN –R –F –T 0

Paquete de herramientas
En mayo de 2007, el equipo de HPC lanzó Compute Cluster Pack Tool Pack (se puede obtener en línea en windowshpc.net/resources/Pages/default.aspx). El paquete de herramientas incluye compatibilidad con Windows PowerShellTM, una herramienta MPIPingPong para diagnosticar el estado de conectividad y un monitor de clúster gráfico muy simple pero muy útil.
Tal como se muestra en la Figura 7, Simple Cluster Monitor puede mostrar en una pantalla cada uno de los nodos del clúster, el número de núcleos que tiene cada uno, el uso de cada CPU (verde brillante), el uso de memoria (amarillo), el porcentaje de tiempo de disco (rojo) y el uso del ancho de banda (naranja). Es una excepcional herramienta rápida que los administradores pueden ejecutar para ver el funcionamiento del clúster.
Figura 7 Supervisión de varios nodos con Simple Cluster Monitor
Figura 7 Supervisión de varios nodos con Simple Cluster Monitor
El monitor de clúster también incluye la funcionalidad de "uso remoto". Debe ejecutar la primera instancia del monitor de clúster en el nodo principal. No obstante, si ejecuta una instancia del monitor de clúster en una sesión de consola en el nodo principal, tendrá la oportunidad de iniciar instancias del monitor de clúster desde una estación de trabajo, dirigirlas al nodo principal y obtener la misma presentación.

¿A qué está esperando?
Ahora ya dispone de conocimientos de HPC y Windows Server 2003 Compute Cluster Server. Sabe cómo instalar CCP, ha visto la excepcional consola integral y dispone de nuevos comandos y herramientas gráficas con los que puede impresionar a sus colegas y usuarios. Encontrará fuentes de información adicional acerca de los sistemas de alto rendimiento en la barra lateral "Recursos de HPC".

John Kelbley es director de productos técnicos de Microsoft en el equipo de tecnología de soluciones globales en el noroeste de EE.UU. Puede ponerse en contacto con John en la dirección Johnkel@microsoft.com
Doug Lindsey es director de programas en el equipo de Microsoft HPC. También es administrador de clústeres de cálculo de producción (incluido en el número 116 de la lista de noviembre de 2007 en www.top500.org). Puede ponerse en contacto con Doug en la dirección Dougli@microsoft.com.


 Adicional en l&#237;nea: Implementaci&#243;n de 2007 Office system con Terminal Services
Adicional en línea James D. Silliman

Implementación de 2007 Office system con Terminal Services
Resumen:
  • Implementación para 2007 Office system
  • Administrar la configuración de usuario
  • Nueva barra de herramientas de acceso rápido
  • Herramienta de personalización para 2007 Office system

El lanzamiento de 2007 Microsoft Office system ha supuesto cambios de diseño importantes que debe conocer antes de implementarlo o actualizar versiones anteriores en la granja de servidores de Terminal Services. Deberá familiarizarse con la plantilla global, la barra de herramientas de acceso rápido,
los complementos de archivo .adm para directivas de grupo y la Herramienta de personalización de Office (OCT, Office Customization Tool). Si conoce todas herramientas por adelantado, la implementación será más fluida. Empecemos nuestro recorrido por lo cambios destacados examinando Microsoft® Word.

Implementación de Word 2007
Word siempre ha usado un archivo de plantilla global y en 2007 Office system este archivo se denomina normal.dotm. En un entorno de Terminal Services, existen tres enfoques distintos que se pueden adoptar para implementar Word y el archivo normal.dotm. Puede dejar el archivo en todos los servidores Terminal Services donde esté instalado Office para que los usuarios reciban la vista predeterminada de Word estándar. Puede abrir el archivo en cada servidor de Terminal Server, modificarlo y agregar personalizaciones para que los usuarios no obtengan una vista predeterminada en Word. O puede cambiar el nombre del archivo para que los usuarios obtengan su propio archivo (que se modifica cuando efectúan un cambio en Word y hacen clic en Predeterminado).
Independientemente de la opción que elija, lo mejor es que la tome antes de llevar a cabo la implementación. Si no realiza cambios desde el principio, los usuarios no podrán guardar sus cambios de plantilla global porque el archivo de la misma que se encuentra en los servidores de Terminal Services sobrescribe el archivo en sus perfiles individuales. Si no abre el archivo de plantilla y lo ajusta, Word 2007 sólo presentará su configuración predeterminada a los usuarios.
No obstante, si lo desea puede ajustar el archivo en cada servidor de la granja de Terminal Services. Para seguir esta opción y mantener la misma configuración de Word para todos los usuarios (como la fuente y el tamaño predeterminados, el espaciado de párrafo y el diseño), deberá almacenar este archivo de plantilla global en su ubicación de ruta predeterminada. Después, para modificar la configuración que desee e implementarla globalmente en los usuarios, sólo tendrá que abrir este archivo en cada equipo de Terminal Services, realizar los cambios que desee en el diseño de Word 2007 (haga clic en Predeterminado) y guardarlos, con los que se escribirán en el archivo normal.dotm predeterminado.
Asegúrese de hacer una copia de seguridad del archivo predeterminado antes de efectuar cambios o tendrá que reinstalar Word 2007 para recuperar el archivo original. Tenga en cuenta que si efectúa cambios en la barra de herramientas de acceso rápido mientras está modificando el archivo normal.dotm, estos cambios no se almacenarán en este archivo de plantilla. En breve me ocuparé de la barra de herramientas de acceso rápido y su comportamiento.
¿Y si decide que los usuarios deben poder administrar su propia configuración global desde Word? Pueden hacerlo, pero debe cambiar el nombre del archivo normal.dotm por otro como normal.dotm.old en todos los servidores de la granja. Recomiendo esta opción como la mejor ya que los usuarios pueden obtener errores de plantilla cuando cierren Word si otras aplicaciones la han bloqueado.
Si cambia el nombre de este archivo, Word 2007 reconoce que desea permitir que los usuarios administren sus preferencias en vez de tener preferencias globales y, por consiguiente, les permitirá modificar y guardar su configuración. Word 2007 ahora guarda el archivo normal.dotm personalizado en la ruta de acceso del perfil de cada usuario. Si usa perfiles móviles (según el modo en que haya configurado las rutas de acceso), el archivo de plantilla se almacena en esta ubicación de carpeta para cada usuario: \\dominio\nombreDeRecursoCompartido\%username%\Application Data\Microsoft\Templates.
La configuración de preferencias de usuario que no se almacena en el archivo normal.dotm es cualquier cambio efectuado en la barra de herramientas de acceso rápido. Esta barra de herramientas es una nueva característica de 2007 Office system, independiente de la barra de herramientas cinta (que también es nueva). La barra de herramientas de acceso rápido es la barra de herramientas diminuta que se encuentra de forma predeterminada en la esquina superior izquierda de la pantalla en 2007 Office system. Esta barra de herramientas existe para las aplicaciones de 2007 Office system, tal como se muestra en la Figura 1. Consulte support.microsoft.com/kb/926805 para obtener más información.
Figure 1 Archivos de barra de herramientas de acceso rápido (Close Figure 1)

Aplicación de Office | Área de características | Nombre del archivo
Access 2007 | Todos | Access.qat
Excel 2007 | Todos | Excel.qat
Outlook 2007 | Contactos Calendario Lista de distribución Entrada de diario Exposición de correo en la carpeta Tareas | Olkaddritem.qat Olkapptitem.qat Olkdistitem.qat Olklogitem.qat Olkmailitem.qat Olkpostitem.qat Olktaskitem.qat
PowerPoint 2007 | Todos | PowerPoint.qat
Word 2007 | Todos | Word.qat
Como puede ver en la Figura 1, la barra de herramientas de acceso rápido usa archivos con la extensión .qat para almacenar la configuración individual. Los archivos se mantienen en esta ubicación de ruta de acceso de archivo predeterminada en cada servidor de Terminal Services de la granja y no son móviles: C:\Documents and Settings\<nombre de usuario>\Local Setting\Application Data\Microsoft\Office (o C:\Users\<nombre de usuario>\AppData\Local\Microsoft\Office en un equipo con Windows Vista®).
Si examina detenidamente la ruta de acceso, observará que los archivos .qat se encuentran en la carpeta Local Settings del perfil en caché local del usuario de Terminal Services. Esta subcarpeta no se sincroniza con el perfil móvil de un usuario al cerrar la sesión porque Local Settings no existe en la estructura de rutas de acceso de perfil móvil. Por lo tanto, lamentablemente, si descarta los perfiles en caché local en los servidores de Terminal Services al habilitar esta configuración de objeto de directiva de grupo (GPO, Group Policy Object), perderá los archivos .qat personalizados del usuario (consulte el artículo de Knowledge Base en support.microsoft.com/kb/274152 para obtener más información).
Es un hecho que la eliminación de los perfiles en caché es una práctica extendida entre los administradores de Terminal Services para la limpieza de los perfiles locales cuando un usuario cierra la sesión, por lo que este cambio en 2007 Office system es importante ya que pertenece a los perfiles en caché y la barra de herramientas de acceso rápido. Una solución evidente es asegurarse de que no esté establecida la configuración de GPO descrita en el artículo de Knowledge Base que acabo de mencionar. Si no permite la eliminación de los perfiles en caché y tiene numerosos usuarios, consumirá espacio de disco duro valioso en la unidad %systemroot% local de cada servidor Terminal Services y tendrá que configurar otro proceso para vigilarlo ya que el servidor se puede quedar sin espacio en el disco duro. Es muy habitual que los perfiles locales alcancen un gran tamaño.
Independientemente del enfoque que adopte, al menos debe agregar una rutina al script de inicio de sesión que realice una copia de seguridad de los archivos .qat de usuario periódicamente para que se puedan recuperar si desaparecen o se eliminan accidentalmente. Si se mantiene una copia de seguridad de estos archivos personalizados, puede evitar llamadas desesperadas al servicio de soporte técnico local para recuperarlos.
Muy pocos administradores de Terminal Services hacen copia de seguridad de estos perfiles en caché local. En su lugar, hacen copia de seguridad de los perfiles móviles de red que, tal como he mencionado, no contienen copias de los archivos .qat. Otra alternativa que se puede tener en cuenta es un producto de terceros que permita implementar un perfil obligatorio para cada usuario y, a continuación, asignar los cambios de la carpeta Local Settings de cada usuario a una carpeta independiente de la red.

Complementos de directiva de grupo
Durante algún tiempo, ha habido archivos .adm de directiva de grupo disponibles para Office 2003 que permiten un mayor control administrativo de las directivas de Office y la experiencia del usuario. Del mismo modo, en 2007 Office system hay nuevos archivos .adm que puede usar para realizar una serie de personalizaciones, incluida la deshabilitación del cuadro de diálogo de primera ejecución y la modificación de la configuración de autoguardado y otras preferencias.
Si ya ha implementado las directivas de grupo de Office 2003 y decide cambiar a 2007 Office system, primero deberá quitar los archivos .adm de Office 2003 existentes de los objetos de directiva de grupo antes de agregar los archivos .adm de 2007 Office system. No se olvide de hacer una copia de seguridad de los objetos de directiva de grupo mediante la interfaz de la Consola de administración de directivas de grupo (GPMC, Group Policy Management Console) para poder revertir si se producen errores después de agregar los nuevos complementos. Tengo constancia de al menos un administrador de Terminal Services al que se le han presentado entradas de directiva fantasmas al quitar los complementos de Office 2003 y, a continuación, agregar los archivos .adm de 2007 Office system a estos objetos de directiva de grupo.
En mi artículo de mayo de 2007, "Guía de implementación de Terminal Services" (technetmagazine.com/issues/2007/05/TerminalServices), mencioné que a los usuarios de Terminal Services no se les debe pedir que realicen algunas acciones, como Autoarchivado de Outlook® o aceptar pantallas de cuadro de diálogo de primera ejecución. Tenga en cuenta que, de forma predeterminada, en el primer inicio de Outlook 2007, a los usuarios se les presentan dos pantallas de primera ejecución: una para Opciones de privacidad y otra para Búsqueda en el escritorio. La primera pantalla, que se muestra en la Figura 2, se puede deshabilitar de varias formas: con la modificación de la configuración de GPO (con los nuevos archivos .adm de Outlook 2007), con la Herramienta de personalización de Office o con el ajuste del Registro.
Figura 2 Cuadro de diálogo de opciones de privacidad en 2007 Office system
Figura 2 Cuadro de diálogo de opciones de privacidad en 2007 Office system
La pantalla mostrada en la Figura 3 aparece inmediatamente después de Opciones de privacidad (si no la deshabilita) y en todas las demás aplicaciones de 2007 Office system.
Figura 3 Cuadro de diálogo de la característica Búsqueda instantánea en 2007 Office system
Figura 3 Cuadro de diálogo de la característica Búsqueda instantánea en 2007 Office system
Para desactivar la solicitud de búsqueda de Windows® para las aplicaciones de Office, descargue las plantillas ADM de 2007 Office en go.microsoft.com/fwlink/?LinkId=78161 y cárguelas en el disco duro del controlador de dominio. En la directiva de grupo, debe cargar la plantilla de Office Outlook 2007 (Outlk12.adm) en Configuración del equipo o Configuración de usuario, Agregar complementos. A continuación, vaya a Configuración de usuario\Plantillas administrativas\Microsoft Office Outlook 2007\Herramientas | Opciones\Preferencias\Opciones de búsqueda y habilite la configuración "Impedir las solicitudes de instalación cuando el componente Windows Desktop Search no esté instalado".
Hay numerosas configuraciones de directiva de grupo en 2007 Office system para controlar la experiencia del usuario, pero deberá agregar los correspondientes archivos .adm, como Word (Word12.adm) y Excel® (Excel12.adm) para cada uno, a los GPO. En la Figura 4 se muestra un ejemplo de la apariencia de la plantilla ADM de Outlook 2007 (Outlook12.adm) una vez agregada a la directiva de grupo.
Figura 4 Plantilla ADM de Outlook 2007 en la directiva de grupo
Figura 4 Plantilla ADM de Outlook 2007 en la directiva de grupo

Cambios adicionales
Tenga en cuenta que en Office 2003 también puede descargar y usar el asistente para la instalación personalizada con el fin de crear transformaciones personalizadas. La nueva OCT en 2007 Office system no requiere una descarga independiente. Se ejecuta con "Setup /admin" desde el comando Ejecutar, dirigido al medio u origen de instalación de 2007 Office system. Al ejecutar este comando en los archivos del origen de instalación y, a continuación, cambiar la configuración individual según sus preferencias, se crea un archivo .msp (a diferencia del archivo .mst de Office 2003) y no necesita especificar ninguna opción de la línea de comandos para incluirla en la implementación posterior. Con sólo colocar el archivo .msp personalizado en la carpeta Updates en la raíz del punto de instalación de red se implementa automáticamente junto con su configuración preferida.
Outlook 2007 tiene otra ventaja con respecto a sus versiones anteriores: busca automáticamente los servidores Exchange 2007 con el envío de una consulta de punto de conexión de servicio (SCP, Service Connection Point) directamente a Active Directory®, si se inicia desde la LAN. Esta consulta facilita la conexión a una infraestructura de Exchange 2007 implementada. Para obtener más información, consulte go.microsoft.com/fwlink/?linkid=76177.
Microsoft ha efectuado algunos cambios de diseño importantes en la forma en que 2007 Office system funciona en un entorno de Terminal Services gracias a la simplificación de sus herramientas de implementación, a la adición de nuevos complementos de archivo .adm y a la optimización de la interfaz. Mediante la comprensión de algunos de los conceptos importantes que he tratado aquí antes de implementar o actualizar las aplicaciones de Office, tendrá un mejor conocimiento de la actualización, lo que le permitirá tomar importantes decisiones de diseño por adelantado. Si no planea efectuar la actualización en este momento, puede considerar la posibilidad de sólo cargar el módulo de compatibilidad de 2007 Office system para que los usuarios puedan abrir los datos adjuntos que les envíen otros usuarios que ya se hayan actualizado. Puede encontrar el módulo de compatibilidad en go.microsoft.com/fwlink?LinkID=77512.
Con esta información, estará preparado para una implementación correcta de 2007 Office system. No olvide hacer una copia de seguridad de las directivas y probar todas las configuraciones recomendadas antes de implementarlas en la comunidad de usuarios.

James D. Silliman, MCSE, es un tecnólogo centrado en Microsoft que está especializado en implementaciones de Terminal Services. Actualmente trabaja para un ASP, donde diseña soluciones de TI para pequeñas empresas. Póngase en contacto con él en la dirección jsilliman@gmail.com.


 Nota del editor: Tratar la sobrecarga de informaci&#243;n
Nota del editor
Tratar la sobrecarga de información
Joshua Hoffman

Al pensar en nuestros dos temas principales de este mes, SharePoint y Office Communications Server, realmente no me sorprende que con frecuencia tengamos problemas para conectarlos entre sí. Como puede ver, en el momento de escribir esta nota (aproximadamente un mes antes de que la lea), la ciudad de Nueva York está completamente volcada en las vacaciones. Y da la casualidad de que la sede central de TechNet Magazine se encuentra en el epicentro de las vacaciones en Nueva York: el Rockefeller Center. Realmente es una zona maravillosa de la ciudad en muchos sentidos, pero durante un mes al año supone, por decirlo de alguna manera, un desafío. La población aumenta (todavía más) con visitantes de todo el país y de todo el mundo que vienen a comprar, a asistir a un espectáculo o a patinar sobre hielo con los majestuosos rascacielos como telón de fondo. No obstante, muchos neoyorquinos se baten en retirada rápidamente.
Algunos argumentan que se debe a la frustración que supone que los turistas se paren en mitad de la acera para hacer una foto y, por lo tanto, nos obliguen a los que vamos detrás a detenernos a corta distancia o a chocarnos con ellos. Pero no se debe a eso (realmente nos encanta que estén ahí, a un clic de distancia). Pienso que se debe a la sobrecarga. En una ciudad ya abarrotada y ajetreada, llegamos a un punto crítico en el que nos vemos sobrepasados.
Con esta idea en mente me centro en nuestro sector y veo que la tendencia es muy similar. Nuestras organizaciones siguen creciendo (que es probablemente lo que esperamos que hagan) y, en consecuencia, generamos más y más información cada día. Nuestros recursos compartidos de archivos están llenos. Nuestras bases de datos están llenas. Y no hablemos del correo electrónico. No hace mucho, un gigabyte era mucha capacidad de almacenamiento. Hoy en día, los terabytes son habituales, incluso en los equipos domésticos. La planeación de muchos centros de datos se está realizando en torno a los petabytes. Creo que estaremos de acuerdo en que hay mucha información. ¿Pero es útil o agobiante? ¿Está estructurada? ¿Es fácil de analizar? ¿Es fácil de compartir?
Así que, de nuevo, con la cantidad abrumadora de información de que disponemos, no me sorprende que nos resulte difícil realizar las conexiones. Pero podría ser mucho más fácil, que es de lo que hablaremos este mes. Esta edición le mostrará cómo sacar el máximo partido de SharePoint para simplificar la recopilación de datos y mejorar la organización en su empresa. Aprenda a crear rápidamente encuestas para recopilar dichos datos de sus usuarios (o clientes). Aprenda a definir tipos de contenido personalizados para que la información recopilada sea mucho más significativa. Y, finalmente, aprenda a usar Office Communications Server para poder realizar estas conexiones críticas. Después de todo, ¿de qué sirve tener todos los datos si no hay nadie con quien compartirlos? (Joshua Hoffman)

Mi agradecimiento a los siguientes expertos de Microsoft: Ed Banti, Susan Bradley, Byron Hynes, Michael Murgolo, Ken Oien, Jim Truher y Kay Unkroth.


 Cartas: Comentarios de los lectores
Cartas
Comentarios de los lectores

Disponibilidad del servicio de instalador de ActiveX
Acabo de leer su artículo de julio de 2007 "Servicio del instalador de ActiveX en Windows Vista" (en línea en technetmagazine.com/issues/2007/07/AxIS). ¿Podría decirme si este servicio ya está disponible?
—Eugene Y.

Sí, el servicio de instalador de ActiveX® ya está disponible. Se puede habilitar fácilmente mediante la opción "Activar y desactivar las características de Windows" en el panel de control Programas y características en Windows Vista®.
El servicio de instalador de ActiveX es un componente opcional que sólo está en las versiones Ultimate, Enterprise y Business de Windows Vista. La lista de los sitios que permiten la instalación de ActiveX con el servicio de instalador de ActiveX se controla mediante la directiva de grupo. La lista se almacena en Configuración del equipo | Plantillas administrativas | Componentes de Windows | sección Servicio de instalador de ActiveX del Editor de objetos de directiva de grupo.

Herramientas de Active Directory
Muchas gracias por el artículo "11 herramientas esenciales para administrar Active Directory" (septiembre de 2007). He intentado eliminar usuarios de Active Directory® con la utilidad dsrm descrita en el artículo, mediante la siguiente línea de comandos:
          dsquery user -samid <samid> | dsrm
Aparece un mensaje de error acerca de que la entrada de "dsrm" tiene un formato incorrecto. Sin embargo, puedo ejecutar el comando independientemente sin ningún problema. ¿Alguna idea?
—Keith E.

Le hemos pasado su pregunta a la autora del artículo, Laura Hunter. Laura indica que cuando se canalizan los resultados de dsquery en dsrm, dsrm requiere el modificador -noprompt. Por lo tanto, debe usar la línea de comandos siguiente:
dsquery user -samid <samid> | dsrm -noprompt
Sentimos que esta información se omitiera en el artículo original y publicaremos una corrección de la versión en línea.

Posibilidades alternativas del rompecabezas
Supongo que sabrá, y probablemente ya lo habrán indicado otras personas, que el rompecabezas de Dr. Scripto's Scripting Perplexer (noviembre de 2007) realmente tiene dos soluciones distintas que funcionan. El rompecabezas también se descifrará correctamente si la variable de 4 caracteres que aparece en las líneas primera y segunda es nnde y si la variable de 5 caracteres que aparece en las líneas tercera y quinta es iamex. Estoy de acuerdo en que la diferencia es trivial y que los nombres de su solución hacen que el script sea mucho más legible.
Gracias por la diversión del rompecabezas, he disfrutado mucho.
—Stan A.

Gracias por compartir su solución alternativa, Stan. Nos alegra saber que se ha divertido con el rompecabezas de los encargados del scripting y estamos muy interesados en agregarlo como una característica habitual de TechNet Magazine.

Persuasión de migración a Windows Vista
El artículo "Cambios en los archivos sin conexión en Windows Vista" del número de noviembre de 2007 de TechNet Magazine (en technetmagazine.com/issues/2007/11/Offline) muestra muy bien las ventajas de Windows Vista en el área de los archivos sin conexión. El artículo nos ha ayudado a tomar la decisión de migrar a Windows Vista porque tuvimos muchos problemas con los archivos sin conexión en Windows® XP Professional.
—Daniel Z.

Gracias, Daniel. Nos alegramos de saber que encontró útil el artículo en su organización.

Páginas perdidas
Su revista es agradable e informativa. Sin embargo, en mi copia del número de diciembre de 2007 faltan las páginas 49-64. Estaba interesado en el artículo de informática forense ("Una guía de la informática forense básica") de Tom Cloward y Frank que debía estar en la página 60. Tal vez su equipo forense de impresión pueda encontrar las páginas/datos que faltan. Si este artículo está disponible en línea, estaré encantado de leerlo allí, si me puede enviar la dirección URL.
—Dave S.

Lamentablemente, tuvimos un problema durante la impresión del número de diciembre de 2007 y, en consecuencia, una pequeña cantidad de copias se enviaron por correo a los lectores sin las páginas 49-64. En nombre de nuestro impresor y del equipo de TechNet Magazine, lamentamos sinceramente las molestias.
Mientras tanto, el artículo al que hace referencia, junto con el resto del número de diciembre, está disponible en línea en technetmagazine.com/issues/2007/12.


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

Desbloquear archivos
Unlocker
ccollomb.free.fr/unlocker
A todos nos ha pasado alguna vez: un proceso automatizado se bloquea a mitad de su operación y un archivo se queda estancado con un bloqueo de escritura, lo que provoca que no se pueda realizar otra operación porque no se puede copiar, mover, escribir o eliminar el archivo. Y a veces no se sabe quién es el culpable de mantener el bloqueo del archivo, pero sí se sabe que está bloqueado. ¿Entonces qué se debe hacer?
Hay numerosas formas de tratar este problema, pero una herramienta que proporciona una solución integrada en el Explorador de Windows® rápida y fácil de usar es la herramienta gratuita Unlocker, escrita por Cedrick Collomb. Gracias a su integración con el Explorador de Windows, puede encontrar al culpable con sólo hacer clic con el botón secundario del mouse en el archivo bloqueado (o incluso un conjunto de archivos) y, a continuación, seleccionar Unlocker en el menú contextual. Si se detecta un bloqueo, puede elegir entre varias opciones, como eliminar el proceso erróneo, desbloquear el archivo (cerrar el identificador), eliminar el archivo, mover el archivo o cambiar el nombre del archivo. También puede copiar el archivo bloqueado en su estado actual a otra ubicación.
Unlocker cuenta con un instalador de aplicación completo, por lo que no tendrá que registrar manualmente las DLL, así como anular su registro, ni tendrá que reiniciar el sistema para iniciar la herramienta. También admite la notificación de actualización automática (si no le importa que "llame a casa" de vez en cuando) para asegurarse de que dispone de la versión más reciente.
Unlocker incluso admite la ejecución desde la línea de comandos, lo que resulta interesante para la automatización. Esto significa, por ejemplo, que puede configurar fácilmente un proceso de trasvase de registros para cerrar automáticamente el identificador y eliminar el proceso de compresión si encuentra un archivo .zip bloqueado al tratar de mover los registros, lo que quizás le evite levantarse de madrugada para intentar solucionar el problema manualmente.
La utilidad también dispone de una herramienta de bandeja de sistema denominada Unlocker Assistant. Puede iniciar automáticamente la interfaz de Unlocker al intentar mover o eliminar un archivo bloqueado, o cambiarle el nombre, lo que le ahorra clics adicionales para buscar el archivo y elegir Unlocker en el menú contextual. Unlocker es compatible con la mayoría de las versiones de Windows, incluyendo Windows Vista®.

Precio: Producto gratuito
Con Unlocker, puede encontrar y desbloquear rápidamente archivos bloqueados
Con Unlocker, puede encontrar y desbloquear rápidamente archivos bloqueados

Analizar el tráfico de red
Wireshark
wireshark.org
Un buen analizador de protocolos de red permite obtener los elementos fundamentales del tráfico de red de la infraestructura para ver lo que realmente sucede en todas las capas de aplicaciones interconectadas. Tal vez el mejor analizador de código fuente abierto más conocido sea Wireshark, que utiliza la biblioteca de captura de paquetes WinPcap de código fuente abierto para Windows y se deriva de Ethereal, con Gerald Combs todavía a bordo.
Con Wireshark, se puede capturar fácilmente el tráfico que pasa a través de una interfaz de red y examinar los detalles de cada paquete en una interfaz gráfica fácil de usar. El inicio de una nueva sesión de captura de paquetes es tan fácil como seleccionar la interfaz y hacer clic en Start (Iniciar). La GUI muestra los paquetes capturados en un marco con códigos de color que detalla el tiempo, el origen, el destino, el protocolo y una descripción predeterminada del evento prácticamente en tiempo real. Al hacer clic en una transmisión se resalta el detalle e interpreta los paquetes de datos en un sencillo panel de detalle. Debajo de él, se pueden ver los datos sin procesar en formato hexadecimal y ASCII.
Una vez que tenga el conjunto de datos que necesita para su análisis, también puede, por ejemplo, guardar o exportar la sesión para su análisis posterior. Wireshark puede descodificar muchos protocolos distintos y debe cubrir la mayor parte de sus necesidades de solución de problemas.
Las redes son ruidosas y para contribuir al filtrado de todos esos datos, la aplicación dispone de una excepcional característica de filtro basado en expresiones que permite limitar la búsqueda por cada parámetro de un protocolo. Por ejemplo, puede filtrar todo el tráfico excepto el relacionado con BitTorrent con destino y procedencia en direcciones IP específicas de la red. O los filtros pueden permitir descubrir fácilmente el equipo que está provocando el caos en la red mediante el envío de toneladas de mensajes de difusión falsos.
La interfaz también permite marcar fácilmente los paquetes para su revisión y establecer una transmisión específica como la referencia de tiempo en la captura. Una de mis características favoritas de Wireshark es la capacidad de efectuar el seguimiento de un flujo TCP mediante la elección de dicha opción en el menú contextual que aparece al hacer clic con el botón secundario del mouse en un paquete TCP. Aparecerá una ventana con una vista de texto con códigos de color y con formato del contenido del flujo TCP, los encabezados HTTP falsos u otros problemas de comunicación de TCP que se puedan producir. Desde aquí puede imprimir o guardar rápidamente la conversación para su examen o demostración posterior.
Sólo he arañado la superficie de la funcionalidad de la aplicación. Wireshark se lanza bajo la licencia GPL. Además de estar disponible para Windows, también tiene binarios compilados para la mayoría de las versiones de Linux y FreeBSD.

Precio: Producto gratuito
Wireshark permite analizar el protocolo de red completo
Wireshark permite analizar el protocolo de red completo

Reforzar Windows PowerShell
Extensiones de la comunidad de PowerShell
codeplex.com/PowerShellCX
Si alguna vez ha tenido la oportunidad de trabajar realmente con Windows PowerShellTM, probablemente habrá observado algunos patrones repetitivos de ejecución para los que resultaría interesante disponer de un cmdlet o alias. En este sentido, un grupo de usuarios de Windows PowerShell y partidarios de la comunidad de código fuente abierto han creado el proyecto Extensiones de la comunidad de PowerShell, que reúne la funcionalidad solicitada habitualmente en un conjunto distribuible de cmdlets, alias, proveedores, funciones, filtros y scripts.
Algunos de los cmdlets incluidos en el paquete son Get-Clipboard y Write-Clipboard, que permiten agregar y recuperar los datos en el búfer del portapapeles. Mientras tanto, Get-DomainController recupera una lista de controladores de dominio disponibles en el dominio actual y Write-GZip y Write-Zip permiten escribir archivos GZIP o ZIP.
Puede crear un nuevo vínculo simbólico o unión en Windows Vista o Windows Server® 2008 con New-Symlink y New-Junction, respectivamente. Hay un útil proveedor DirectoryServices que ofrece acceso a servidores LDAP, como Active Directory® y AssemblyCache, lo que permite el acceso a la caché de ensamblados global de Microsoft .NET Framework y a los ensamblados que incluye.
También hay varios scripts excepcionales. Los scripts Set-Writable y Set-ReadOnly permiten cambiar rápidamente el estado de sólo lectura de un archivo. Get-Url crea una solicitud web (WebRequest) y devuelve la respuesta (WebResponse) como una cadena y Export-History vuelca el historial de comandos en un archivo .clixml para reutilizarlo posteriormente. Puede obtener información de uso del disco con el script Get-DiskUsage o incluso hacer que el equipo hable con el divertido comando Out-Speech. Y el paquete incluye un buen número de funciones útiles, como Quote-List, que reduce la escritura de líneas de comandos, y Add-PathVariable, que puede agregar un conjunto de rutas de acceso a un entorno especificado.
Este proyecto agrega un conjunto de extensiones muy útil al entorno estándar de Windows PowerShell. Y si es un ninja de Windows PowerShell, estoy seguro de que el proyecto estará abierto a sus aportaciones.

Precio: Producto gratuito
La extensión de la comunidad de PowerShell ofrece las funciones solicitadas habitualmente
La extensión de la comunidad de PowerShell ofrece las funciones solicitadas habitualmente

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


 Preguntas y respuestas acerca de SQL: &#205;ndices no cl&#250;ster y retenci&#243;n de permisos
Preguntas y respuestas acerca de SQL
Índices no clúster y retención de permisos
Saleem Hakani and Dan Carollo

Índices no clúster y sus usos
P: ¿Qué son los índices no clúster y cuáles son los pros y los contras de usarlos?
R: Un índice no clúster es similar al tipo de índice que normalmente se encuentra al final de un libro. Toda la información que contiene el libro se representa en el índice por tema y hay punteros en forma de números de página que le indican dónde encontrar la información, tal vez en varias áreas del libro. Además, los datos de un índice de libro no se enumeran en el mismo orden que aparecen en el texto del libro. Lo mismo sucede con los índices no clúster. Si tiene un índice no clúster en una tabla, puede especificar cuál será el orden los elementos. De lo contrario, no hay forma de estar seguro de cuál será el orden.
Además, los índices no clúster tienen dos limitaciones: sólo se pueden incluir 16 columnas en el índice y el tamaño máximo de la clave de índice no puede superar los 900 bytes. ¿Qué significa eso? Veamos lo que sucede si desea indizar las siguientes columnas de la tabla Movie de la base de datos MovieList de ejemplo: MovieTitle NVarchar(50), DirectorName NVarchar(50), ShortStory NVarchar(400).
Suponga que usa la siguiente instrucción para crear la tabla:
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
Se generará el siguiente mensaje de error: "Advertencia: la máxima longitud de clave es de 900 bytes. El índice 'Movie_IDX' tiene una longitud máxima de 1000 bytes. Para algunas combinaciones de valores grandes, la operación de inserción o actualización no funcionará correctamente." El mensaje anterior aparece porque el tipo de datos "nvarchar" consume 2 bytes por cada carácter. Un índice que contenga las tres columnas anteriores excederá el límite de tamaño de 900 bytes.
Con el lanzamiento de SQL Server® 2005, dispone de la oportunidad de solucionar este problema si agrega las columnas a la cláusula INCLUDE. Es una característica muy útil si desea superar las limitaciones de tamaño y de columnas. Puede hacerlo si ejecuta la siguiente instrucción:
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
Es importante observar que al usar la cláusula INCLUDE durante la creación del índice, el motor de base de datos no tiene en cuenta las columnas que no son clave al calcular el número de columnas de clave de índice o el tamaño de clave de índice.
Para obtener más información acerca de los índices no clúster, visite "Índices no clúster" en msdn2.microsoft.com/aa174537 y "Uso de índices no clúster" en msdn2.microsoft.com/aa933130. Para obtener sugerencias acerca de la optimización de índices, consulte sql-server-performance.com/optimizing_ indexes.asp.

Conservación de los datos de permisos
P: ¿Cómo puedo evitar la pérdida de permisos cuando se reinicializa una suscripción? El problema se ha producido varias veces al reinicializar una instantánea, que pierde todos los permisos concedidos.
R: De forma predeterminada, todos los objetos de la base de datos de suscripciones se anulan y se vuelven a crear siempre que se reinicializa una suscripción. Pero hay dos formas en que puede tratar esta situación.
En primer lugar, puede volver a aplicar todos los permisos después de la reinicialización. Al configurar los permisos manualmente, debe incluir en el script todos los permisos de nivel de objeto/instrucción y almacenarlos de forma independiente para poder usarlos inmediatamente después de reinicializar la suscripción.
En segundo lugar, puede configurar la suscripción de modo que no anule ningún objeto siempre que reinicialice la suscripción. Para ello, puede usar el procedimiento almacenado de sistema SP_CHANGEARTICLE para configurar el valor de PRE_CREATION_CMD para el parámetro @PROPERTY y un valor de NONE, DELETE o TRUNCATE para el parámetro @Value.
Además, en el cuadro de diálogo Propiedades del artículo, seleccione los valores "Mantener el objeto existente sin cambios. Eliminar datos. Si el artículo tiene un filtro de fila, eliminar sólo los datos que coincidan con el filtro. Truncar todos los datos del objeto existente." Asegúrese de intentarlo en su entorno de prueba y, si necesita más ayuda, consulte la última versión de los Libros en pantalla de SQL Server para obtener información actualizada.

Saleem Hakani es ingeniero jefe de base de datos, ingeniero jefe de solución de problemas y director de la comunidad de Microsoft SQL Server en todo el mundo con 14 años de experiencia en sistemas de bases de datos. Dirige el sitio web externo de la comunidad de SQL Server sqlcommunity.com y puede ponerse en contacto con él en la dirección Saleem@sqlcommunity.com.
Dan Carollo es ingeniero de operaciones y administrador de bases de datos de SQL que trabaja con el equipo de investigación y respuesta antimalware de Windows en Microsoft. Tiene el certificado MCT en SQL Server.


 Utility Spotlight: ADMX Migrator
Utility Spotlight
ADMX Migrator
Lance Whitney
Descargar el código de este artículo: ADMX Migrator (2765KB)

Evidentemente, quienes empleen la directiva de grupo estarán familiarizados con el uso de plantillas administrativas para configurar el sistema operativo y la opciones de las aplicaciones. Los archivos ADM incluidos con Windows® y software clave, como Microsoft® Office, cubren las configuraciones de escritorio más habituales. No obstante, en ocasiones tiene que crear plantillas ADM propias para incorporar configuraciones personalizadas. El diseño de los ADM desde cero puede ser laborioso, ya que tienen una sintaxis única y para su creación se requiere un editor de textos. Pero con el tiempo y la experiencia, muchos profesionales de directivas de grupo se habrán hecho adeptos a la elaboración de sus propios archivos ADM.
Con Windows Vista®, Microsoft ha cambiado el formato de las plantillas de directiva de grupo a una estructura basada en XML. Este nuevo formato, denominado ADMX, ofrece varias ventajas con respecto a los archivos ADM heredados, como la compatibilidad multilingüe y un punto de almacenamiento central donde puede administrar todas las plantillas.
Son buenas noticias, pero ¿y si desea crear sus propios archivos ADMX y no conoce XML? Y lo más importante, ¿qué sucede con todos los ADM personalizados que ha creado durante estos años? Por suerte, la utilidad ADMX Migrator viene al rescate. Esta herramienta gratuita, desarrollada por FullArmor Corporation y con licencia para Microsoft, ofrece dos ventajas clave: permite crear archivos ADMX personalizados y puede convertir los archivos ADM heredados en ADMX.
Interfaz gráfica de ADMX Migrator
Interfaz gráfica de ADMX Migrator
Para crear plantillas en el nuevo formato, ADMX Migrator proporciona ADMX Editor, que admite una interfaz gráfica de usuario. Ya no se requiere ningún editor de textos. Las plantillas se crean con menús y listas desplegables con una interfaz nítida y simple (consulte la figura). Para comenzar, elija el comando New Template (Nueva plantilla), asigne un nombre al archivo de plantilla y especifique una categoría por la que se clasificará el archivo. A continuación, cree la configuración de directiva real mediante la especificación de la clave del Registro a la que se aplicará la directiva, el nombre del valor del Registro y la clase a la que afectará (User, Machine o ambas). También puede describir lo que hace la directiva.
Cuando haya terminado, guarde la nueva plantilla en formato ADMX. Se almacena como archivo ADMX y como archivo ADML. El archivo ADMX contiene la configuración de directiva real y el archivo ADML proporciona la información específica del idioma para la directiva. Puede copiar ambos archivos en los directorios adecuados del dominio e incorporarlos a la directiva de grupo.
Probablemente deseará convertir los archivos ADM en ADMX para aprovechar el nuevo formato. ADMX Migrator ofrece dos métodos de conversión: mediante el editor o mediante un programa de la línea de comandos. Desde ADMX Editor, elija la opción para generar ADMX a partir de ADM. Busque el archivo ADM y la herramienta lo convertirá rápida y automáticamente. Puede abrir el archivo convertido en el editor para examinar sus valores y propiedades, así como para modificarlo si lo desea. La ventana de comandos de ADMX Migrator es un poco más complicada, ya que requiere que se escriba una cadena de comando larga en un símbolo del sistema para realizar las conversiones. No obstante, incluye algunas opciones y flexibilidad que no están disponibles en el editor gráfico.
ADMX Migrator es un complemento de Microsoft Management Console (MMC), por lo que requiere MMC 3.0 así como Microsoft .NET Framework 2.0. ADMX Migrator se ejecuta en Windows XP SP2, Windows Server® 2003 SP1 y Windows Vista. Puede descargar el software en go.microsoft.com/fwlink/?LinkId=77409.

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 la TI hace 15 años.


 The Cable Guy: Autenticaci&#243;n de redes cableadas IEEE 802.1X
The Cable Guy
Autenticación de redes cableadas IEEE 802.1X
Joseph Davies
Este artículo se basa en una versión preliminar de Windows Server 2008. Por tanto, los detalles de este documento están sujetos a cambios.

Con el aumento de la popularidad de IEEE 802.1X para las redes inalámbricas IEEE 802.11, los administradores de red desean usar este estándar también para sus conexiones de red cableada. Del mismo modo que un cliente inalámbrico debe enviar un conjunto de credenciales para que se validen antes de que las tramas inalámbricas se reenvíen a la intranet, un
cliente de red cableada IEEE 802.1X debe realizar una autenticación antes de poder usar su puerto del conmutador. La autenticación IEEE 802.1X proporciona una barrera adicional de seguridad para la intranet. Así, puede impedir que los equipos invitados, malintencionados o no administrados puedan llevar a cabo una autenticación correcta de la conexión a la intranet.
Es probable que los conmutadores de red cableada admitan la autenticación IEEE 802.1X y sólo sea necesario habilitarla y configurarla. Para la autenticación y la autorización de una conexión de red cableada, los conmutadores compatibles con 802.1X normalmente usan el protocolo del servicio de autenticación remota telefónica de usuario (RADIUS) para enviar la información de solicitud de conexión a un servidor RADIUS, como un Servidor de directivas de redes (NPS, Network Policy Server) basado en Windows Server® 2008 o un servidor Internet Authentication Service (IAS) de Windows Server 2003.
Después de configurar los conmutadores para RADIUS, pero antes de requerir la autenticación 802.1X, tendrá que habilitar y configurar la autenticación 802.1X en los equipos de red cableada. La autenticación IEEE 802.1X para conexiones de red cableada se admite en Microsoft® Windows® desde Windows XP. No obstante, debe establecer manualmente la configuración de autenticación 802.1X en Windows XP y Windows Server 2003 en cada cliente de red cableada (desde la ficha Autenticación para las propiedades de una conexión de red en la carpeta Conexiones de red). Lamentablemente, no existe modo de configurar de forma centralizada o mediante script la configuración 802.1X de red cableada para sistemas operativos anteriores.
Afortunadamente, la compatibilidad para la configuración de red cableada en la directiva de grupo y la compatibilidad de scripting con la herramienta Netsh en Windows Vista® y Windows Server 2008 supone que la implementación de la configuración de red cableada 802.1X es mucho más simple que antes.

Configuración de red cableada en la directiva de grupo
Uso del servicio de configuración automática de redes cableadas
En Windows XP y Windows Server 2003, el comportamiento de 802.1X en conexiones de red cableada se controla mediante el servicio de configuración inalámbrica rápida. En estos sistemas operativos, este servicio estaba habilitado de forma predeterminada y las conexiones de red cableada se situaban en modo de escucha pasiva, a la espera de que el conmutador iniciara la autenticación.
Por el contrario, en Windows Vista y Windows Server 2008, el servicio de configuración automática de redes cableadas controla el comportamiento de 802.1X en conexiones de red cableada pero está deshabilitado de forma predeterminada. Por lo tanto, la ficha Autenticación para las propiedades de conexiones de red no aparece hasta después de que se inicie el servicio de configuración automática de redes cableadas.
Para un cliente de red cableada individual que ejecute Windows Vista o Windows Server 2008, puede usar el complemento Servicios para iniciar el servicio de configuración automática de redes cableadas y configurarlo para el inicio automático. Cuando se inicia el servicio de configuración automática de redes cableadas, las conexiones de red cableada actúan en modo de escucha activa en el que la conexión de red intenta iniciar la autenticación con el conmutador.
Para un dominio de Active Directory, puede usar la directiva de grupo para configurar el servicio de configuración automática de redes cableadas para el inicio automático. Con el complemento Editor de administración de directivas de grupo, establezca Configuración del equipo | Configuración de Windows | Configuración de seguridad | Servicios del sistema | Configuración automática de redes cableadas en el modo de inicio automático.

Para centralizar y automatizar la configuración de la red cableada, los servicios de dominio de Active Directory® de Windows Server 2008 y Windows Server 2003 admiten la configuración de directiva de red cableada en la directiva de grupo. Esta configuración permite establecer las opciones de red cableada como parte de la directiva de grupo de configuración de equipo para un objeto de directiva de grupo basado en dominio.
Con esta configuración de directiva de red cableada, puede especificar el método de autenticación y otras opciones de configuración de 802.1X para los clientes de red cableada que ejecutan Windows Server 2008 o Windows Vista. Al unirse al dominio, iniciarse o periódicamente después de iniciar, estos sistemas operativos descargan automáticamente la configuración de directiva de grupo de red cableada y la aplican. Tenga en cuenta que un dominio de Active Directory de Windows Server 2003 se debe extender para admitir estas nuevas directivas. Para obtener información acerca de cómo extender un dominio de Active Directory de Windows Server 2003, consulte technet.microsoft.com/bb727029.
Puede configurar las directivas de red cableada en el nodo Configuración del equipo | Configuración de Windows | Configuración de seguridad | Directivas de red cableada (IEEE 802.3) en el complemento Editor de administración de directivas de grupo. De forma predeterminada, no hay directivas de red cableada (IEEE 802.3). Para crear una directiva nueva, haga clic con el botón secundario en Directivas de red cableada (IEEE 802.3) en el árbol de la consola y haga clic en Crear una nueva directiva de Windows Vista.
El cuadro de diálogo de propiedades de una directiva de red cableada de Windows Vista consta de una ficha General y de una ficha Seguridad. En la Figura 1 se muestra la ficha General predeterminada. En la ficha General, puede configurar un nombre y la descripción para la directiva y especificar si se usa el servicio Configuración automática de redes cableadas, que controla el comportamiento de 802.1X en conexiones de red cableada. Para obtener más información, consulte la barra lateral "Usar el servicio de configuración automática de redes cableadas" en esta columna.
Figura 1 Ficha General predeterminada de una directiva de red cableada de Windows Vista
Figura 1 Ficha General predeterminada de una directiva de red cableada de Windows Vista
En la Figura 2 se muestra la ficha Seguridad predeterminada de una directiva de red cableada de Windows Vista. En la ficha Seguridad, puede habilitar o deshabilitar la autenticación 802.1X, seleccionar y configurar el método de autenticación de Protocolo de autenticación extensible (EAP, Extensible Authentication Protocol), seleccionar el modo de autenticación (reautenticación de usuario, sólo equipo, autenticación de usuario o autenticación de invitado), configurar el número de intentos de autenticación con error antes de que se abandone la autenticación y configurar si se almacenará en caché la información de usuario para las conexiones posteriores. Cuando el almacenamiento en caché está deshabilitado, Windows quita los datos de credenciales de usuario del Registro cuando el usuario cierra la sesión. El resultado es que al siguiente usuario se le pedirán sus credenciales (como el nombre de usuario y la contraseña) al iniciar sesión.
Figura 2 Ficha Seguridad predeterminada de una directiva de red cableada de Windows Vista
Figura 2 Ficha Seguridad predeterminada de una directiva de red cableada de Windows Vista
Al hacer clic en el botón Opciones avanzadas de la ficha Seguridad, puede configurar las opciones avanzadas de 802.1X e inicio de sesión único. En la Figura 2 se muestra el cuadro de diálogo Configuración de seguridad avanzada predeterminado de una directiva de red cableada de Windows Vista. En el cuadro de diálogo Configuración de seguridad avanzada puede configurar las opciones de 802.1X que se muestran en la Figura 4.
Figure 4 Configuración de 802.1X en el cuadro de diálogo Configuración de seguridad avanzada (Close Figure 4)

Configuración | Descripción
Máximo de mensajes EAPOL-Start | El número de mensajes sucesivos de EAP sobre LAN (EAPOL)-Start que se envían cuando no se recibe ninguna respuesta a los mensajes iniciales de EAPOL-Start.
Período de retención | El intervalo de tiempo entre la retransmisión de los mensajes EAPOL-Start cuando no se recibe ninguna respuesta al mensaje EAPOL-Start.
Período de inicio | El período de tiempo durante el cual el cliente de autenticación no realizará ninguna actividad de autenticación 802.1X después de que reciba una indicación de error de autenticación por parte del autenticador.
Período de autenticación | El período de tiempo que el cliente de autenticación esperará antes de retransmitir solicitudes 802.1X después de que se haya iniciado la autenticación 802.1X de extremo a extremo.
Mensaje EAPOL-Start | Cuando el cliente de red cableada envía el mensaje EAPOL-Start.
Figura 3 Cuadro de diálogo Configuración de seguridad avanzada predeterminado de una directiva de red cableada de Windows Vista
Figura 3 Cuadro de diálogo Configuración de seguridad avanzada predeterminado de una directiva de red cableada de Windows Vista
Los clientes de red cableada que ejecutan Windows Server 2008 admiten el inicio de sesión único para las conexiones de red cableada. Esta característica también se ha planeado para el próximo lanzamiento de Windows Vista Service Pack 1. Hay más información disponible en línea en technetmagazine.com/issues/2007/11/CableGuy.
Existen configuraciones de inicio de sesión único para realizar la autenticación 802.1X de nivel de usuario antes o después del proceso del inicio de sesión de usuario y para esperar el número de segundos configurado a que se complete la autenticación 802.1X de nivel de usuario antes de iniciar el proceso de inicio de sesión del usuario. También puede determinar si desea que se muestren los cuadros de diálogo de autenticación de nivel de usuario más allá de la consolidación de campos de entrada en la pantalla de inicio de sesión de Windows. Por ejemplo, si un tipo EAP desea que el usuario confirme el certificado enviado desde el servidor RADIUS durante la autenticación, el tipo EAP puede mostrar el cuadro de diálogo.
Asimismo, puede especificar que después de realizar la autenticación de nivel de usuario, el sistema inicie una renovación del Protocolo de configuración dinámica de host (DHCP, Dynamic Host Configuration Protocol) de la configuración TCP/IP del adaptador de red cableada. Seleccione esta opción si hay LAN virtuales (VLAN) independientes para los clientes de red cableada de nivel de equipo y de nivel de usuario y si esas VLAN son subredes IPv4 o IPv6 diferentes.

Compatibilidad de scripting con la herramienta Netsh
Windows Server 2008 y Windows Vista admiten comandos en el contexto de netsh lan de la herramienta Netsh para configurar opciones de red cableada o bien para exportar o importar un perfil de red cableada, que es un conjunto con nombre de configuraciones de red cableada en formato XML. Con la configuración de la línea de las opciones de red cableada, puede implementar más fácilmente redes cableadas mediante la creación de scripts automatizados para configuraciones de red cableada sin usar la directiva de grupo. La configuración de la directiva de grupo Directivas de red cableada (IEEE 802.3) sólo se aplica a un dominio de Active Directory. Para un entorno sin una infraestructura de directiva de grupo, un script que automatiza la configuración de conexiones de red cableada puede ejecutarse de forma manual o automática, incluido como parte del script de inicio de sesión.
Para realizar la configuración de la línea de comandos de los clientes de red cableada con Windows Vista o Windows Server 2008, ejecute los comandos netsh lan con los parámetros adecuados. Por ejemplo, el siguiente comando habilita el inicio de sesión único para la conexión de red denominada "Local Area Connection" y configura el inicio de sesión único para efectúe la autenticación de usuario antes del inicio de sesión de usuario:
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
Para obtener más información acerca de la sintaxis del comando netsh lan, consulte technet.microsoft.com/aa905084.
Los perfiles XML de red cableada se pueden exportar de un cliente de red cableada de Windows Server 2008 o Windows Vista y, a continuación, importarlos en un cliente de red cableada de Windows Server 2008 o Windows Vista con la herramienta Netsh. Para exportar un perfil de red cableada, use el comando netsh lan export profile. Si desea importar un perfil de red cableada, use el comando netsh lan add profile. Para ver algunos ejemplos útiles de perfiles de red cableada, consulte msdn2.microsoft.com/aa816372.
Con la línea de comandos y la compatibilidad de perfil XML, puede arrancar un cliente de red cableada en una red cableada autenticada mediante 802.1X de la organización. Un equipo cliente de red cableada que no sea miembro del dominio no puede conectarse a la red cableada mediante las credenciales de equipo. Además, un equipo no puede unirse al dominio hasta que se haya conectado correctamente con la red cableada. No obstante, la línea de comandos y la compatibilidad de perfil XML permiten que un equipo de red cableada se conecte a la red cableada de la organización con las credenciales de usuario y, a continuación, unir el equipo al dominio. Para obtener más información, consulte technet.microsoft.com/bb727031.

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: Permisos del shell
Windows PowerShell
Permisos del shell
Don Jones
Descargar el código de este artículo: PowerShell2008_02.exe (151KB)

Al hablar de Windows PowerShell, a menudo me preguntan acerca de los permisos, en especial si el shell permite automatizar los cambios en los permisos y cómo puede hacerlo. La consulta más común sea posiblemente acerca de los permisos de archivos, aunque también son frecuentes las consultas sobre los permisos de directorios y del Registro. En lo referente a los permisos y a cualquier
interfaz de línea de comandos o de scripting (incluidos Windows PowerShellTM y VBScript), tengo que dar tanto buenas como malas noticias.
Las malas noticias son que los permisos de Windows® son, por naturaleza, bastante complicados y Windows PowerShell no puede hacer mucho para corregirlo. El problema proviene del hecho de que en un sistema operativo Windows, hay varios objetos relacionados con los permisos, independientemente de si busca en el sistema de archivos, Active Directory®, el Registro o en cualquier otro lugar.
En primer lugar, tenemos el recurso propiamente dicho, por ejemplo, un objeto de directorio, un archivo o una carpeta. A continuación, encontramos el objeto de lista de control de acceso (ACL, Access Control List), que está adjunto al recurso. ACL consta de una o más entradas de control de acceso u objetos ACE. Una ACE enlaza una entidad de seguridad (un usuario o grupo, que es otro objeto) con un permiso (como, por ejemplo, de lectura o de control total) y un estado Conceder o Denegar. Son cinco objetos: El recurso, la ACL, la ACE, la entidad de seguridad y un permiso.
Los permisos se complican aún más por el hecho de que cada tipo de recurso tiene distintos tipos de permisos. Por ejemplo, los objetos de directorio disponen de permisos complejos que controlan el acceso a atributos de objetos individuales. En comparación, los permisos de archivos son un poco menos complicados.
Además, técnicamente, en el caso de las auditorías todo se duplica. Todos los recursos disponen de dos ACL. En primer lugar, existe la lista de control de acceso discrecional (DACL, Discretionary ACL), que controla el acceso al recurso. También hay una lista de control de acceso de seguridad (SACL, Security ACL), que controla la auditoría del recurso. Intentar trabajar con estos permisos significa navegar a través de una pila de objetos de programación que parecen bastante complicados, y mucho nos tememos que un shell como Windows PowerShell no puede hacer mucho para simplificarlo.

Limitado por .NET Framework
¿Quiere más?
Para obtener más recursos de Windows PowerShell, incluida una biblioteca de cmdlets que permite búsquedas, y para ponerse en contacto con Don Jones y otros expertos en Windows PowerShell, visite www.PowerShellCommunity.org.

La naturaleza de Windows PowerShell complica un poco las cosas. Creado a partir de Microsoft® .NET Framework, Windows PowerShell usa las clases subyacentes de .NET Framework para representar y trabajar con permisos. Estas clases subyacentes de .NET Framework se diseñaron para ofrecer a los desarrolladores de software un control granular y preciso sobre los permisos. Por supuesto, "granular y preciso" significa mucha información y, a menudo, se traduce como "muy complicado".
Además, .NET Framework no ofrece clases que representen permisos en todos los tipos de recursos de Windows. Por ejemplo, aunque .NET Framework ofrece clases que le permiten manipular la seguridad de archivos, no ofrece clases que le permitan trabajar con la seguridad de la carpetas compartidas. Como resultado, Windows PowerShell no puede manipular los permisos en cada tipo de recurso de Windows. En otras palabras, Windows PowerShell está limitado a las capacidades expuestas por .NET Framework.

Permisos en el shell
La administración de permisos en Windows PowerShell se deriva de dos cmdlets: Get-ACL y Set-ACL. Como cabría esperar, Get-ACL recupera la ACL a partir de un recurso. A continuación, puede modificar la ACL para que se adapte a sus necesidades y usar Set-ACL para volver a escribirla en el recurso. Ambos cmdlets son genéricos y dependen del sistema de proveedores PSDrive de Windows PowerShell. De este modo, ambos cmdlets ACL podrían trabajar, en teoría, con cualquier tipo de recurso, siempre que haya un proveedor PSDrive capaz de entender un tipo de recurso dado y capaz de modificar los permisos en ese tipo de recurso. Los proveedores PSDrive FileSystem y Registry, incluidos en Windows PowerShell, admiten la administración de permisos a través de dos cmdlets ACL. Puede que otros proveedores PSDrive no la admitan.
El script de muestra que aparece en la Figura 1 le permite especificar un directorio de inicio, una entidad de seguridad y un permiso. A continuación, el script aplica el permiso que ha especificado para esa entidad de seguridad a todos los archivos y carpetas del directorio especificado. El script también permite la recursividad de subdirectorios.
Figure 1 Aplicar un permiso para una entidad de seguridad a los archivos y carpetas de un directorio (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
La sustancia del script está donde define una nueva regla de acceso en la variable $rule. Para esto, uso una clase .NET Framework "sin formato", que es posiblemente la parte más complicada de la administración de permisos en Windows PowerShell. A continuación, el script recupera la ACL de todos los archivos y carpetas mediante Get-ACL, aplica la nueva regla mediante el método SetAccessRule de la ACL, y vuelve a escribir la ACL modificada en el recurso por medio de Set-ACL.
En realidad, no es tan complicado, aunque se requieren operaciones más complejas como eliminar una ACE de una ACL. En mi opinión, lo que lo hace parecer complicado es el hecho de que implica muchos pasos: obtener la ACL, definir una regla, modificar la ACL y escribir la ACL. No hay un único comando que haga todo de una sola vez. Como deseaba modificar las ACL en varios archivos, tuve que incluirlo todo en un bucle foreach, usando Get-ChildItem para obtener acceso a todos los archivos y carpetas.

Elegiré la opción más fácil
Cmdlet del mes: Get-QADUser
Este cmdlet es imprescindible si administra Active Directory. No está integrado en Windows PowerShell, pero está disponible a modo de descarga gratuita como parte del shell de administración ActiveRoles para Active Directory de Quest Software (www.quest.com/activeroles-server/arms.aspx).
Cuando haya instalado el complemento, podrá usar Get-QADUser para recuperar objetos de usuario desde el directorio. Por supuesto, con sólo ejecutarlo, cmdlet devuelve todo sus usuarios, lo que no resulta muy útil para la mayoría de las tareas administrativas. Cmdlet le permite especificar criterios de filtrado, que se aplican en el controlador de dominio para que sólo se devuelvan a Windows PowerShell aquellos usuarios que le interesen. Esta técnica es más rápida que obtener primero todos los usuarios y filtrarlos a continuación con el cmdlet Where-Object. Por ejemplo, Get-QADUser -l Redmond sólo devolverá aquellos usuarios cuyo atributo "l" contenga "Redmond" (el atributo "l" corresponde a localidad y se incluye como ciudad en GUI). A continuación, puede canalizar esos usuarios a otros cmdlets para generar un informe HTML, colocarlos en un grupo o incluso eliminarlos.

Creo que mi ejemplo es sencillo, pero sé que muchos administradores preferirían una forma más simplificada de trabajar con permisos. Tal vez deseen eliminar un grupo de usuarios específico de un conjunto de carpetas de una sola vez sin escribir un script compuesto por varios pasos como el que aparece en la Figura 1.
Por suerte, Windows PowerShell ofrece un medio simplificado para trabajar con permisos y, probablemente, ya esté familiarizado con él.
Windows PowerShell no le obliga a abandonar su manera habitual de hacer las cosas. Puede continuar usando herramientas de línea de comandos como Dsacls.exe, Cacls.exe y Xcacls.exe, que se diseñaron específicamente para simplificar el trabajo con varios tipos de permisos. Aunque su sintaxis es completamente diferente a la sintaxis estándar usada por los cmdlets de Windows PowerShell, éstas utilidades de línea de comandos ya no tienen que usarse de una forma ad hoc en la línea de comandos, tal y como ocurría en el antiguo shell cmd.exe. Puede usar Windows PowerShell para automatizar estas utilidades.
Me he encontrado con muchas personas, los llamaré "puristas", que insisten en que no es correcto usar una línea de comandos antigua con Windows PowerShell. No lo entiendo. Estoy a punto de acabar el trabajo y si la forma más fácil de hacerlo es usar una utilidad de línea de comandos de hace 10 años, dígame dónde tengo que firmar. No voy a dedicar horas extra a intentar hacer algo de una forma concreta sólo porque parece "más puro". Y el equipo de Microsoft Windows PowerShell tiene una actitud similar. Si una herramienta existente hace el trabajo, entonces Windows PowerShell le permite usar dicha herramienta en el shell. ¿Por qué volver a inventar la rueda?
La Figura 2 muestra un breve script, tomado de mi libro Windows PowerShell: TFM (SAPIEN Press, 2006), que usa Windows PowerShell para automatizar Cacls.exe. Este script es sólo una demostración, lo que significa que tendrá que ajustarlo si desea convertirlo en una herramienta de automatización real. Sin embargo, muestra cómo un script de Windows PowerShell puede recopilar información y usarla para iniciar Cacls.exe, como si Cacls.exe fuera un comando "nativo" de Windows PowerShell. Aunque este script recopila información solicitándosela al usuario, los parámetros también se pueden leer desde un archivo o una base de datos.
Figure 2 Automatizar Cacls.exe (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

¿Eficaz con los permisos?
He oído que Windows PowerShell no cumple las expectativas en lo que respecta a permisos porque no proporciona un cmdlet nativo que ofrezca administración de permisos simplificada y universal. No estoy de acuerdo. En primer lugar, este argumento normalmente proviene de administradores con mucha experiencia en UNIX, y el sistema de permisos de Windows es mucho más complicado que el de UNIX. Al exponer este sistema, Windows PowerShell también se complica. Sin embargo, esto no es un problema de Windows PowerShell.
Además, Windows PowerShell le permite usar herramientas simplificadas como las tradicionales utilidades de línea de comandos, tal y como ya se ha demostrado aquí. Es cierto que .NET Framework necesita una expansión para cubrir mejor la administración de permisos en toda la plataforma de Windows. En general, Windows PowerShell le ofrece ambas opciones: la administración simplificada de permisos y el acceso a herramientas de administración granulares y precisas.

Don Jones es editor colaborador de la revista TechNet Magazine y coautor de Windows PowerShell: TFM (SAPIEN Press, 2007). Se dedica a enseñar Windows PowerShell (consulte www.ScriptingTraining.com) y puede ponerse en contacto con él a través del sitio web www.ScriptingAnswers.com.


 &#161;Hola, encargados del scripting!: &#161;Los juegos ya est&#225;n en marcha! Ah, y tambi&#233;n algo de XML
¡Hola, encargados del scripting!
¡Los juegos ya están en marcha! Ah, y también algo de XML
Los encargados del scripting
Descargar el código de este artículo: HeyScriptingGuy2008_02.exe (151KB)

¿Sabe?, cuando se habla de las leyendas del mundo deportivo, inevitablemente surgen siempre los mismos nombres: Babe Ruth. Pelé. Muhammad Ali. Walter Payton. ScooterK y MrRat. Johnny—
Ja, ja, ja, qué divertido... oh, ¿en serio? ¿Realmente no sabe quiénes son ScooterK y MrRat? Bien, para los que evidentemente no siguieron los Juegos de invierno de Scripting (del 15 de febrero al 3 de marzo en el TechNet Script Center, vaya a microsoft.com/technet/scriptcenter/funzone/games), ScooterK y MrRat son auténticas leyendas, competidores que consiguieron puntuaciones perfectas en al menos una división de los Juegos de invierno de Scripting 2007.
Y ahora viene lo bueno: ¿realmente espera ser una leyenda del fútbol como Pelé? Probablemente no. ¿Espera ser el campeón del mundo de boxeo de los pesos pesados? Bueno, parece que algunos encargados del scripting tienen dominado el tema del peso pesado, pero lo de ser campeones de boxeo parece que es algo más difícil de conseguir. Pero usted (sí, usted) se puede convertir fácilmente en el próximo ScooterK o MrRat.
Nota: en teoría, también pueda convertirse en el próximo Babe Ruth. Sólo tiene que poder comerse 24 perritos calientes entre dos juegos consecutivos de béisbol.
Calma. Le diremos cómo puede convertirse en el próximo ScooterK o MrRat (y tal vez en el próximo Bizzy o H2Data). Sólo tiene que presentarse en el Script Center y participar en los Juegos de Scripting. El 15 de febrero expondremos 10 eventos distintos (10 desafíos de scripting) y le retaremos a que los complete todos o alguno de ellos. Escriba un script que solucione el problema que proponemos y envíelo por correo electrónico a los encargados del scripting (encontrará todas las instrucciones en la página principal de Juegos de Scripting). Probaremos su script y, si funciona, conseguirá puntos. Realice correctamente los 10 eventos y también se convertirá en una leyenda del mundo deportivo. O al menos del mundo deportivo del scripting, que es prácticamente lo mismo.
Los Juegos de Scripting (del 15 de febrero al 3 de marzo) son divertidos y desafiantes. Y lo mejor de todo, los Juegos de Scripting son para todos. ¿Todavía no tiene mucha experiencia en scripting de administración de sistemas? Vaya a la división de principiantes. Tenemos competiciones independientes para principiantes en VBScript, Windows PowerShellTM y (novedad de este año) Perl. ¿Considera que la división de principiantes es un poco fácil? Entonces debe probar la división avanzada, que también tiene competiciones en VBScript, Windows PowerShell y Perl.
Los Juegos (¿hemos dicho que son del 15 de febrero al 3 de marzo?) son el acontecimiento de la temporada de scripting y no se los debe perder. Visite la página principal del Script Center para obtener sugerencias y trucos para preparar la competición y vuelva el 15 de febrero, fecha en que empezarán oficialmente los Juegos.
Del 15 de febrero al 3 de marzo. Por si lo había olvidado.
¿Cómo que qué es eso? Realmente estamos de acuerdo con usted: sacar una nueva columna ¡Hola, encargados del scripting! además del anuncio de los Juegos de Scripting probablemente suponga demasiadas emociones para un solo mes. Sin embargo, para tener contentas a las buenas personas de TechNet Magazine (ni qué decir tiene que es el objetivo principal de nuestras vidas), hemos decidido arriesgarnos y sacar una nueva columna de todos modos.
Hace exactamente un año (vaya, ¿ya ha pasado tanto tiempo?) publicamos una columna en la que se explicaba cómo usar un script para leer un archivo XML. Pero en esa columna no se explicaba cómo usar un script para crear, escribir y modificar un archivo XML. Este mes corregiremos esa injusticia. ¿Deseaba saber cómo escribir un script que pueda crear un archivo XML? Sólo tenía que preguntar. Bueno, preguntar y esperar un año a que tuviéramos tiempo para contestar. La Figura 1 muestra el script. Hay que reconocer que puede parecer complicado, pero explicaremos cómo funciona.
Figure 1 Crear un archivo XML (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
Para empezar, creamos una instancia del objeto Microsoft.XMLDOM. Tal y como habrá adivinado, se trata del objeto que nos permite trabajar con archivos XML. Nuestro objetivo es crear un archivo XML simple similar al de la Figura 2.
Figura 2 Nuestro destino: un archivo XML simple
Figura 2 Nuestro destino: un archivo XML simple
Para crear este archivo XML, lo primero que necesitamos hacer es crear el nodo raíz (ITChecklist). ¿Cómo lo hacemos? Así:
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
Bastante fácil, ¿verdad? Sólo había que llamar al método createElement y pasarle el nombre que deseamos asignar al nodo raíz. Después llamamos al método appendChild y le pasamos la referencia de objeto a nuestro nuevo elemento (objRoot) como el único parámetro de método. En este momento ya tenemos un nodo raíz.
Pero, espere, hay más. A continuación creamos el nodo ComputerAudit, un nodo secundario del nodo ITChecklist que representa la información de un solo equipo. Como puede ver, el código para crear este nodo es similar al empleado para crear el nodo raíz:
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
La única diferencia es ésta: cuando creamos el nodo raíz, llamamos a appendChild en nuestro documento XML (observe la referencia de objeto xmlDoc). Para agregar un nuevo nodo secundario a la raíz, llamamos a appendChild en el nodo raíz (objRoot) en lugar del documento XML. Así de sencillo.
Igualmente sencillo resulta agregar los nodos ComputerName y AuditDate como nodos secundarios de ComputerAudit. Para ello, realizaremos un proceso similar: vamos a llamar a createElement para crear un nuevo nodo y llamaremos a appendChild para anexar este nuevo nodo al archivo.
Pregunta rápida: ¿desde dónde llamamos a appendChild esta vez? Correcto: desde objRecord, el nodo primario (ComputerAudit) que acabamos de crear.
Ah, y como los nodos ComputerName y AuditDate deben contener valores, es importante que también especifiquemos un valor para la propiedad Text de cada uno de estos nodos antes de que los agreguemos al documento.
Todo se aclarará cuando examinemos el código que realmente crea el nodo ComputerName:
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
Como es de esperar, el código para crear AuditDate es prácticamente idéntico. Sólo tenemos que especificar un nombre de nodo distinto al llamar a createElement y asignar un valor diferente a la propiedad Text.
Vaya, lo estamos poniendo fácil para todos, ¿no le parece?
Después de finalizar la creación de los nodos de nuestro primer (y en este caso, único) registro, ejecutamos este encantador bloque de código:
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
Esto simplemente inserta la etiqueta <?xml version="1.0" ?> al principio del archivo, lo que garantiza que tenemos un documento XML con el formato correcto.
Ahora, lo que nos queda por hacer es llamar al método Save y guardar nuestro nuevo archivo como C:\Scripts\Audits.xml:
xmlDoc.Save "C:\Scripts\Audits.xml"
De esta manera, obtenemos un documento XML completamente nuevo.
Realmente resulta útil: ahora ya sabe crear un archivo XML completamente nuevo con un script. Evidentemente, lo más probable es que la mayor parte del tiempo no necesite realmente crear un archivo XML totalmente nuevo, sino que deba anexar nuevos datos a un archivo existente. ¿Los encargados del scripting enseñarán cómo se hace?
Bueno, en un principio decidimos que la respuesta a esa pregunta era No, que no enseñaríamos a anexar datos a un archivo XML existente. Pero como somos buenos y generosos, decidimos intentar llegar a un acuerdo con los lectores de TechNet Magazine: si todos los que están leyendo esta revista aceptan participar en los Juegos de invierno de Scripting 2008, como compensación les enseñaríamos a usar un script para anexar datos a un archivo XML. Así pues, ¿todos están de acuerdo en participar en los Juegos de Scripting?
Eh, le estamos esperando. Sí, usted, el de Rochester, Massachussets.
Eso es, mejor así. Y, de verdad, se divertirá en los Juegos de Scripting. Todo el mundo se divierte. Lo prometemos.
Y como un trato es un trato, le mostraremos un script que puede anexar datos a un archivo XML existente. Eche un vistazo a la Figura 3.
Figure 3 Anexar a un archivo XML (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
Como puede ver, no es demasiado distinto del script que creaba el archivo XML. Empezamos con la creación de una instancia del objeto Microsoft.XMLDOM, a continuación la propiedad Async se establece en False, lo que indica al script que deseamos cargar el documento sincrónicamente en vez de hacerlo asincrónicamente. ¿Cuál es la diferencia? Bueno, si cargamos el documento asincrónicamente, el script continuaría libremente aunque no se hubiera cargado el documento por completo. Ni qué decir tiene los problemas que se producirían al instante si se intenta realizar una tarea en un documento que todavía no existe. Al asegurarnos de que nuestro archivo XML se carga asincrónicamente también garantizamos que el archivo estará totalmente cargado antes de que continúe el script.
Y hablando de totalmente cargado... bueno, no importa; lo dejaremos pasar. En su lugar, llamamos al método Load para abrir el archivo C:\Scripts\Audits.xml. Tan pronto como se abre el archivo, usamos esta línea de código para crear una instancia de la clase documentElement, que tiene el resultado final de enlazarnos a la raíz del documento. En este caso, por supuesto, es el nodo ITChecklist:
Set objRoot = xmlDoc.documentElement
A partir de ahí, todo es cuesta abajo. Creamos una nueva instancia del nodo ComputerAudit con el método appendChild para agregar el nuevo nodo al archivo. Después creamos nuevas instancias de los nodos ComputerName y AuditDate, especificando los valores adecuados (atl-ws-100 y la fecha actual, respectivamente) para cada nodo nuevo. Guardamos estos dos elementos en el nuevo nodo ComputerAudit que acabamos de crear, llamamos al método Save para guardar el archivo y volvemos alegremente a trabajar en nuestros scripts para los próximos Juegos de Scripting.
Que, por si no lo hemos dicho, serán del 15 de febrero al 3 de marzo en el TechNet Script Center.
Ningún problema por el momento. Podemos crear un nuevo archivo XML y agregar nuevos registros a ese archivo. Todo eso está muy bien, pero todavía faltan cosas, por ejemplo, ¿cómo modificamos los registros existentes del archivo? Bien, al menos hay una forma de hacerlo, tal y como se muestra en la Figura 4.
Figure 4 Modificar el XML (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
La parte importante de este script se produce cuando llamamos al método selectNodes, un método que determina los registros que devolverá nuestra consulta. Como puede ver, cuando llamamos a selectNodes tenemos cuidado de especificar dos criterios: sólo deseamos los registros en los que el atributo ComputerName sea igual a atl-ws-100 y que sólo se devuelva el atributo AuditDate.
Nota: ¿que no entiende cómo funciona? Eche un vistazo a nuestro primer artículo acerca del trabajo con archivos XML (technetmagazine.com/issues/2007/02/HeyScriptingGuy). En él se explica la sintaxis de consulta de selectNodes con más detalle.
Como es habitual, selectNodes devuelve una colección de todos los registros XML que cumplen los criterios especificados. A su vez, esto significa que podemos actualizar el valor del atributo AuditDate (el único atributo que hemos solicitado), con tan sólo configurar un bucle For Each para recorrer todos los elementos de la colección y, a continuación, en dicho bucle asignar un nuevo valor a AuditDate:
For Each objNode in colNodes
   objNode.Text = Date
Next
¿Que qué es eso? ¿Se pregunta si podemos modificar varios atributos a la vez? Sí, es posible. Pero, lamentablemente, hoy no. Es algo que tendremos que tratar en una columna futura.
Tiene otra pregunta: ¿cómo se actualiza la fecha de auditoría de todos los equipos del archivo? La respuesta es fácil: use el script de la Figura 5.
Figure 5 Cambiar la fecha de la auditoría (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
¿Cuál es la única diferencia entre este script y nuestro script anterior para modificar XML? Con éste no se especifica que sólo deseamos ver los registros en los que ComputerName es igual a atl-ws-100. Si se omite ese criterio, se obtienen todos los registros de forma predeterminada.
Veamos un último script antes de acabar. Supongamos que nuestro viejo colega atl-ws-100 ha jugado su última partida de solitario y que se ha ido al cielo informático.
Nota teológica: ¿a dónde van los equipos cuando se mueren? Resulta que normalmente se entregan a uno de los encargados del scripting. Por ejemplo, al encargado del scripting que escribe esta columna le regalaron una vez un equipo portátil porque "has hecho mucho en favor de Microsoft y realmente te mereces un equipo portátil". El único inconveniente de este regalo generoso es que el equipo estaba roto y no se podía encender. Lo que probablemente fue lo mejor. Tampoco tenía disco duro.
Para cerrar el gran círculo de la vida del silicio, debemos eliminar atl-ws-100 de nuestro archivo XML. ¿Cómo lo vamos a hacer? Consulte la Figura 6.
Figure 6 Eliminar del archivo XML (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
Como puede ver, se parece a nuestro script anterior, el que modificaba la propiedad AuditDate. Realmente sólo hay dos diferencias. Por un lado, observe que no nos hemos molestado en especificar valores de propiedad en nuestra consulta de selectNodes. Cuando los especificamos, obtenemos el registro XML completo para atl-ws-100:
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
Y, después, en cada bucle For Each llamamos al método removeChild para eliminar todos los registros en los que ComputerName sea igual a atl-ws-100:
xmlDoc.documentElement.removeChild _
  (objNode)
Y eso es todo. Adiós, atl-ws-100; apenas te llegamos a conocer.
Vale, ¿algún editor de TechNet Magazine sigue leyendo la columna de este mes? ¿Se han ido todos a probar el rompecabezas de scripting mensual? Excelente. Ahora que no hay nadie vigilándonos, le vamos a decir una cosa: deje todo lo que esté haciendo (por ejemplo, leer esta revista) y vaya al Script Center y empiece a prepararse para los Juegos de Scripting. Después de todo, TechNet Magazine seguirá aquí mucho tiempo. Pero los Juegos de Scripting sólo ocurren una vez al año y durante un tiempo limitado (en concreto, del 15 de febrero al 3 de marzo, como ya debe saber). ¡No se lo pierda!
Nota: ¿sabe?, ahora que lo menciona, hemos esperado a que lea toda nuestra columna antes de decirle que deje de leer TechNet Magazine, ¿verdad? Cómo habrá podido suceder...

Dr. Scripto's Scripting Perplexer
El desafío mensual que pone a prueba no sólo sus habilidades para resolver rompecabezas sino también sus habilidades de scripting.

Febrero de 2008: Símbolos misteriosos
El teclado del equipo incluye todo tipo de caracteres de aspecto chiflado, pero más chiflado aún es el hecho de que la mayoría de estos caracteres tengan un uso específico en los lenguajes de scripting VBScript o Windows PowerShell. Vea si puede enlazar cada símbolo con su uso de scripting. Ya ha hecho el primero.

Dr. Scripto's Scripting Perplexer
Respuesta: Símbolos misteriosos, febrero de 2008

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


 Vigilancia de seguridad: Salto de islas: atenuaci&#243;n de las dependencias no deseadas
Vigilancia de seguridad
Salto de islas: atenuación de las dependencias no deseadas
Jesper M. Johansson

En la entrega del pasado mes de Vigilancia de seguridad, expliqué los pasos iniciales para usar una unidad flash USB para atacar una red. El ataque se iniciaba con una unidad flash USB infectada que se conectaba a un equipo. A continuación, se ejecutaba el código malintencionado, ya sea automáticamente o con un poco de ayuda del usuario (mediante el uso de algo de ingeniería
social simple). Este ataque permanecía local en la estación de trabajo, pero es evidente que el malware se podía haber propagado al resto de la red. Trataré esta forma de ataque en una red en detalle en mi próximo libro, Windows Server 2008 Security Resource Kit (Microsoft Press®, 2008), y voy a adaptar partes de dicho capítulo para esta columna.
Obviamente, una opción para la protección es prohibir las unidades de disco extraíbles. Aunque esta acción pueda parecer prudente, es muy probable que los usuarios le tiendan una emboscada cuando se dirija al coche si intenta llevarla a cabo, y puede ser difícil reprochárselo si actúan así. La mejor opción, en la mayoría de los entornos con datos confidenciales, es intentar administrar el riesgo relacionado y contener la exposición.
Además, las unidades extraíbles no constituyen el único medio de poner en peligro un equipo cliente. ¿Recuerda las “10 leyes inmutables de la seguridad" (disponible en microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? La idea general de la ley 3 sigue siendo vigente: "Si un intruso tiene acceso físico sin restricción a su equipo, ya no es su equipo." En el contexto de esta explicación, si un atacante tiene acceso a su equipo, se puede considerar que está en peligro. Esto incluso se puede llevar a cabo de forma remota si el atacante puede convencerle para que ejecute el código en el equipo. Puede reconocer esta situación como la ley 1 de las leyes inmutables: "Si un intruso puede persuadirle de ejecutar este programa en su equipo, ya no es su equipo."
Se puede suponer con seguridad que estas leyes siguen vigentes. Se ha demostrado que son realmente resistentes y es muy poco probable que cambien considerablemente hasta que cambiemos de forma sustancial la forma en que funcionan los equipos. Por lo tanto, si se tiene en cuenta el modo en que estas leyes se aplican al escenario descrito, es esencial que quite fuerza a las unidades extraíbles. Y puede hacerlo con unos pocos ajustes del Registro.
Evidentemente, también debe usar capas adicionales de protección. Puede suponer razonablemente que muchos de los equipos cliente ya han estado en peligro o los han usado otros usuarios que no siempre tienen en mente buenas intenciones para su organización. Esto significa que necesita mitigar sus efectos en el resto de la red y que aumenta la importancia de entender, analizar y mitigar las dependencias de seguridad.

Definición de una dependencia de seguridad
Una dependencia de seguridad se produce cuando la seguridad de un equipo depende de la seguridad de otro. Puede haber oído decir que si el controlador de dominio (DC) está atacado también lo está toda la red. Es una forma simple de indicar que todos los miembros de dominio dependen de los DC para su seguridad. Si el DC no está seguro, los equipos miembro no pueden estar seguros. Si un atacante puede cambiar la configuración de seguridad del dominio, puede tomar el control de cualquier equipo de la red, por ejemplo con la agregación de nuevas cuentas al grupo Administradores en un equipo miembro. Cualquier vulnerabilidad que permita que un administrador constituya un peligro no es interesante. Se supone que un administrador tiene acceso completo a lo que está administrando.
Las dependencias en sistemas de equipos son inevitables. De hecho, son habituales y, con frecuencia, deseables. No obstante, no significa que todas las dependencias sean aceptables. En esta columna explico los tipos de dependencias que son aceptables y cuáles no. Después, analizaré los tipos de dependencias y cómo mitigarlas. En Windows Server 2008 Security Resource Kit trato con más detalle las dependencias específicas y explico cómo administrarlas.

Dependencias aceptables
En general, una dependencia es aceptable cuando un sistema menos sensible depende de un sistema más sensible para la seguridad. Los equipos y los sistemas, por lo general, se pueden dividir en clases en función de lo sensibles que sean (el conjunto específico de clases en un entorno concreto no es relevante para la explicación general, lo que importa es que hay clasificaciones inherentes). Para ilustrar la explicación, supongamos que tengo dos clasificaciones: estaciones de trabajo y DC. En este escenario, es aceptable que las estaciones de trabajo dependan de los DC para su seguridad. La clase de DC es con diferencia más sensible que las estaciones de trabajo por lo que, evidentemente, se debe proteger mejor.
El mismo argumento se puede aplicar a las cuentas de usuario. Es aceptable que un administrador pueda poner en peligro los datos que posee un usuario. Esto se debe a que los administradores tienen más responsabilidad y disponen de acceso sin restricciones (aunque no siempre directo o evidente) al equipo y a todo lo que contiene. Si comprende este punto y administra los equipos de forma adecuada, no hay ningún problema con esta dependencia.
Incluso el software se puede analizar de la misma manera. Ciertamente es aceptable para un elemento de software menos sensible, como un explorador web, que usa y depende de un elemento de software más sensible, como el sistema operativo, para su seguridad. Si el sistema operativo tiene un error, no sorprende el hecho de que el explorador web ahora sea vulnerable a problemas nuevos y probablemente ocupa los últimos lugares en la lista de preocupaciones inmediatas. El sistema operativo y otras aplicaciones críticas constituirán el principal foco de atención. Esto corresponde al modo en que los errores se corrigen o al destino de las revisiones. Un error se debe corregir lo antes posible una vez identificado el problema. Al hacerlo así, se maximiza el efecto protector de la corrección. De este modo, en vez de solucionar el problema en el explorador web se debe corregir el sistema operativo.
La dependencia también se puede quitar si se cambia el diseño. Por ejemplo, el explorador web se puede rescribir para reducir sus dependencias del sistema operativo. Este último enfoque resulta adecuado en los casos en que la funcionalidad de los componentes más seguros (el sistema operativo, en este caso) nunca se ha previsto usar realmente en la forma en que el componente menos sensible (el explorador web) la usa.

Dependencias inaceptables
Según mi explicación de dependencias aceptables, la definición de una dependencia inaceptable ahora debe ser evidente. Básicamente, un sistema más sensible nunca debe depender de un sistema menos sensible para su seguridad.
Si el riesgo de una estación de trabajo significa que se ha infringido la seguridad del DC, tiene entre manos un grave problema de seguridad. Es imposible proteger una red si su seguridad agregada depende de la seguridad de cada uno de los equipos de la red.
Considere esto desde el punto de vista estadístico. Si cada equipo de la red es "seguro" el 99,999 por ciento del tiempo, puede considerar que tiene una red muy segura. De hecho, ese porcentaje probablemente está muy alejado de la realidad en la mayoría de las redes más pequeñas de hoy en día. Pero ahora suponga que la red tiene 40.000 equipos y cada uno es vulnerable el 0,001 por ciento del tiempo. Hablando de forma práctica, la red general no estaría segura hasta un posible 40 por ciento del tiempo.
Y, por supuesto, con las dependencias no administradas basta un equipo a ese 0,001 por ciento del tiempo para poner en peligro toda la red. En estos términos, ¿en qué medida es segura la red? Evidentemente, es absolutamente primordial que los sistemas más sensibles estén protegidos de los menos sensibles.
Este argumento se puede aplicar fácilmente a las cuentas de usuario y al software. Por ejemplo, el nuevo cliente de Terminal Services para Windows® permite almacenar los nombres de usuario y las contraseñas para un inicio de sesión en Terminal Services prácticamente transparente. Estas credenciales se almacenan mediante la API del administrador de credenciales, protegida por las credenciales usadas para la sesión de inicio de sesión principal.
Esto puede crear una dependencia de seguridad. Tomemos el caso de una administradora de red que inicia sesión en su estación de trabajo personal. Usa esta estación de trabajo para el correo electrónico, la exploración web y otras tareas típicas de los trabajadores de la información. Naturalmente, usa una cuenta de dominio con pocos privilegios para este fin.
En algún momento durante el día, esta administradora se conecta a uno de los DC para efectuar algunas tareas de administración. Usa el cliente de Terminal Services para ello y decide almacenar su contraseña para facilitar las conexiones futuras. Esto deriva en al menos una y posiblemente dos dependencias de seguridad inaceptables. La primera es que sus credenciales de cuenta administrativa de dominio ahora están protegidas por sus credenciales de trabajador de la información con pocos privilegios. Si esta cuenta de usuario con pocos privilegios está en riesgo, la cuenta de usuario administrativo de dominio también está en riesgo y, por lo tanto, todo el dominio.
La segunda dependencia se deriva del hecho de que ha escrito una credencial administrativa de dominio en un controlador que no es de dominio. A menos que su estación de trabajo personal esté protegida como mínimo como los DC, y probablemente no lo está, hay una dependencia en la que la seguridad de los DC depende de la seguridad de la estación de trabajo personal de este usuario. Por ejemplo, si un empleado descontento en la misma oficina ha instalado un programa de registro de pulsaciones de teclas en la estación de trabajo del administrador de la red, las credenciales administrativas de dominio ahora están capturadas. Siempre que escribe una credencial administrativa de dominio en un controlador que no es de dominio está exponiendo todo el dominio a los defectos de seguridad en dicho controlador.
Ahora suponga que un atacante inserta una unidad extraíble en un equipo donde un administrador de dominio ha iniciado sesión actualmente, en el que ha iniciado sesión alguna vez o en el que iniciará sesión. El administrador de dominio está en peligro y, por extensión, todo el dominio. Es imprescindible que comprenda esta situación para poderla evitar. Y, por supuesto, la misma situación puede suceder con el software cuando una aplicación segura depende de la funcionalidad de una aplicación menos segura para realizar una determinada tarea.

Análisis de un ataque
Anteriormente he descrito lo que puede suceder si una unidad extraíble malintencionada se inserta en un equipo. No obstante, sólo puede ser evidente lo que le sucedería al equipo en el que la unidad se ha insertado inicialmente. Así que suponga que el equipo en cuestión está unido al dominio, tal como se muestra en la Figura 1.
Figura 1 Dependencias de dominio ideales
Figura 1 Dependencias de dominio ideales
La situación presentada aquí representa una dependencia ideal. Las flechas son direccionales e indican de dónde se hereda la dependencia. Por ejemplo, la seguridad de la estación de trabajo depende de la seguridad del DC y la seguridad del usuario depende de la seguridad de la estación de trabajo. El atacante puede poder poner en peligro la estación de trabajo, que pone en peligro cualquier información que el usuario ha guardado en ella, aunque el riesgo quedaría aislado ahí.
Pero suponga que el usuario que ha iniciado sesión en la estación de trabajo es miembro del grupo de administradores locales en el servidor. Y suponga que el administrador de dominio suele iniciar sesión en el servidor. Ahora tenemos las dependencias que se muestran en la Figura 2.
Figura 2 Dependencias de dominio en riesgo
Figura 2 Dependencias de dominio en riesgo
Al cambiar simplemente el supuesto de quién ha iniciado sesión en el equipo en cuestión, se ha puesto en peligro la seguridad de toda la red. Debido a que un administrador de dominio inicia sesión en el servidor, la seguridad del DC y, por tanto, de todo el dominio depende de la seguridad de dicho servidor.
Esto sería aceptable si el servidor estuviera administrado de forma tan segura como el DC. No obstante, en este caso, un usuario que inicia sesión en la estación de trabajo es un miembro del grupo Administradores en el servidor. Por lo tanto, la seguridad del servidor depende de la seguridad de la estación de trabajo. Esto significa que la seguridad de todo el dominio depende de la seguridad de la estación de trabajo. Y adivine qué pasó: el usuario de esta estación de trabajo ejecutó accidentalmente la herramienta del atacante.
Probablemente pocos conceptos hay en el mundo actual de la seguridad de información que sean más importantes de entender que las dependencias de seguridad. Si empieza por el análisis de la red e intenta comprender cuáles son las dependencias, probablemente encontrará dependencias inaceptables. En el peor de los casos, que es mucho más habitual de lo que se pueda pensar, la seguridad de toda la red depende de toda la red, es decir, la seguridad de un equipo depende, en cierto modo, de la seguridad de otro equipo. Por lo tanto, es imposible crear ningún tipo de estrategia de administración de riesgos razonable y realista en ese tipo de entorno ya que no se pueden controlar las relaciones y la complejidad es inabarcable. La solución es analizar y administrar sus dependencias.
En esta columna, he presentado sólo una breve introducción a las dependencias y cómo las puede analizar y mitigar. Puede encontrar más información en mi libro Windows Server 2008 Security Resource Kit. Contiene un capítulo entero dedicado al tema de la protección de la red mediante el análisis de las dependencias y su administración con técnicas sofisticadas, como el aislamiento de servidor y dominio, y otras más triviales, como la administración de cuentas administrativas.
Me gustaría dar las gracias a David LeBlanc por ayudarme a modelar las ideas embrionarias que han dado lugar a esta columna.

Jesper M. Johansson es un arquitecto de software que trabaja en cuestiones de seguridad de software y colabora con TechNet Magazine. Tiene un doctorado en MIS y más de 20 años de experiencia en el ámbito de la seguridad.


 Archivos del escritorio: Arranque dual con Windows XP y Windows PE 2.0
Archivos del escritorio
Arranque dual con Windows XP y Windows PE 2.0
Wes Miller
Descargar el código de este artículo: Desktop2008_02.exe (151KB)

En entregas anteriores de Archivos del escritorio he mencionado que Windows PE se ha convertido en una herramienta de recuperación y he explicado cómo se puede usar desde una segunda partición. Una consulta que recibí recientemente me hizo pensar que merecería la pena abordar un nuevo giro en este sentido: usar Windows PE 2.0 y Windows XP juntos.
Después de todo, muchos usuarios pueden estar usando Windows® XP durante algún tiempo y Windows PE 2.0 es la versión a la que Microsoft va a ofrecer soporte técnico en adelante (no habrá más actualizaciones para Windows PE 1.x).
Una diferencia importante entre Windows PE 1.x y 2.x reside en que Windows PE 2.x se puede arrancar mediante una interfaz de arranque estándar (a diferencia del método especializado que usa Windows PE 1.x). Aunque Windows PE 1.x ó 2.x se puede arrancar desde una segunda partición, la comodidad de arrancarlo en la misma partición de arranque en la que está instalado el sistema operativo ofrece muchas posibilidades que describiré en breve.

Dos arranques para Windows
Windows NT® siempre ha sido relativamente tolerante al arranque dual. Pero a medida que los equipos basados en Extensible Firmware Interface (EFI) han empezado a reemplazar el viejo BIOS de IBM PC/AT, Microsoft ha cambiado el mecanismo de arranque de Windows para que funcione mejor con EFI y para disponer de un solo mecanismo de arranque en todas las arquitecturas. El nuevo mecanismo de arranque para Windows, que comienza con Windows Vista®, se denomina Base de datos de configuración de arranque o BCD (consulte microsoft.com/whdc/system/platform/firmware/bcd.mspx). Pero tanto si se habla del viejo boot.ini como del nuevo mecanismo BCD, Windows, por lo general, puede arrancar otros sistemas operativos, incluso si eso supone transferir el proceso de arranque a otro cargador de arranque.
Antes de empezar, es fundamental que recuerde que Windows PE 2.0 sólo funciona en sistemas que tienen compatibilidad con Interfaz avanzada de configuración y energía (ACPI, Advanced Configuration and Power Interface) y 384 MB (idealmente 512 MB) de RAM. Tal como indiqué en mi columna de mayo (technetmagazine.com/issues/2007/05/DesktopFiles), los sistemas que no sean ACPI no podrán arrancar Windows PE 2.0 y, como Windows PE 2.0 se debe iniciar desde un disco RAM, debe tener suficiente RAM para dicho disco, cualquier espacio de desecho y todo el espacio de trabajo de RAM. Si su sistema tiene menos de 384 MB de RAM, ni siquiera se plantee esta posibilidad, use Windows PE 1.6 en su lugar. Incluso si se tiene habilidad para reducir el tamaño de Windows PE, no se puede ejecutar correctamente sobre 256 MB.

Problemas que se solucionarán
Veamos ahora los problemas que puede solucionar si arranca Windows PE 2.0 desde la misma partición que Windows XP.
Recuperación del sistema completo Se trata de una tarea que sólo es posible si se arranca Windows PE desde la partición de Windows XP. Dado que Windows PE 2.0 (como Windows PE 1.6 anteriormente) se puede arrancar por completo en un disco RAM, se puede volver a crear la imagen de todo el disco, o usar ImageX para restaurar los archivos de Windows XP, ya que no es necesario volver a crear la imagen de toda la partición.
Si se permite a los usuarios que arranquen Windows PE al inicio, pueden recuperar sus propios sistemas aunque trabajen de forma remota. La imagen podría proceder de una partición secundaria, un recurso compartido de red (si no se trata de usuarios móviles), un DVD o disco duro USB de recuperación o, si se usa ImageX, incluso se puede almacenar en la partición que se va a recuperar. Este tipo de recuperación en disco es una solución excelente para muchos problemas (a excepción de daños físicos en el disco). Evidentemente no resulta interesante restaurar los datos de usuario a menos que se hayan protegido antes y se hayan restaurado como parte de la recuperación. Recuerde que debe usar perfiles móviles y hacer copia de seguridad de los datos del equipo para evitar ese tipo de pérdida. También debe asegurarse de que cualquier mecanismo de recuperación que use puede mitigar la posible pérdida de datos en nombre del usuario (incluida la pérdida debida al restablecimiento de las claves de cifrado EFS).
Recuperación de archivos Windows PE también proporciona el mecanismo para que el sistema esté activo y en funcionamiento incluso si no arranca la instalación principal de Windows. En ese caso, puede arrancar y recuperar los datos de usuario en otro sistema (siempre que disponga de sistemas de copia de seguridad semiactiva disponibles para los usuarios) o en otra ubicación para que el usuario comience a trabajar pronto de nuevo.
Reparación del sistema Finalmente, el arranque de Windows PE en Windows XP permite reparar un sistema mediante la ejecución de un conjunto de scripts de solución de problemas o una aplicación simple de reparación o recuperación controlada por el usuario. El proceso es similar a la recuperación completa del sistema, pero con un ámbito más limitado (y no se pondrán en peligro los datos de usuario).
Ahora que tiene una idea de lo que puede hacer si arranca Windows PE en la partición de Windows XP, consulte lo que pasa entre bastidores para poder aplicar el proceso a cualquier solución que desee.

Antes de Windows Vista
Antes de la llegada de Windows Vista, los sistemas basados en BIOS/registro de arranque maestro (MBR, Master Boot Record) arrancaban del siguiente modo. El BIOS indicaba el dispositivo de arranque (en el caso del disco duro, indicaba el MBR en el disco). El MBR ejecutaba código que especificaba la partición que se iba a arrancar. Tenga en cuenta que es la primera partición que tiene establecida la marca de activa. En las versiones anteriores de diskpart, no se podía dejar inactiva una partición (es decir, no se podía quitar la marca de activa). Se agregó un modificador a diskpart para corregir esta situación. De lo contrario, tenía que ser la primera partición de la tabla de particiones la que tuviera establecida su marca de activa. La partición contiene el sector de arranque, que indica el código que se ejecuta a continuación. De Windows NT a Windows Server® 2003, el código para ejecutar se encuentra en un archivo denominado ntldr, sin extensión de archivo. Si alguna vez ha formateado un disco, no ha instalado Windows y ha intentado arrancar, habrá visto el mensaje de error "No se encuentra NTLDR".
Le interesará saber que ntldr es totalmente compatible con versiones anteriores pero, como es lógico, no lo es con versiones posteriores. Esto significa que el archivo ntldr de Windows XP puede arrancar Windows 2000, pero no a la inversa. De ahí que siempre sea importante instalar primero el sistema operativo más antiguo si planea realizar el arranque dual. Como ntldr no tiene asociado ningún número de versión, es más importante, si cabe, mantenerlo así.
Ntldr es una aplicación de modo real (16 bits) que inicia NTDetect.com, que realiza la detección de dispositivos básicos y, a continuación, inicia el kernel, ntoskrnl.exe (puede ser uno de varios archivos, siempre con el nombre cambiado a ntoskrnl.exe). El kernel es el componente fundamental en el proceso de arranque de Windows.
Este resumen del proceso de arranque es bastante simplista y he omitido la inicialización entera de Win32®, pero no es relevante para esta explicación. Si desea obtener más información al respecto, le recomiendo que lea Windows Internals, cuarta edición por Mark Russinovich y David Solomon (Microsoft Press®, 2004).
Otro aspecto que se debe tener en cuenta es que cuando se arranca desde CD, el programa de instalación de Windows y Windows PE ejecutan setupldr.bin en vez de ntldr. Este archivo contiene realmente un código de arranque algo distinto para poder arrancar desde el CD (lo que no puede hacer ntldr). Por este motivo, para arrancar Windows PE 1.x, se cambia el nombre de setupldr.bin por ntldr y se coloca en el disco. También es el motivo por el que dicho archivo no puede cargar después un archivo boot.ini (porque setupldr.bin se diseñó sólo para el arranque desde CD y, por lo tanto, no se consideró que boot.ini fuera necesario).

Windows Vista y más allá
Windows Vista cambió muchos elementos de este proceso. Windows Server 2008 lo cambia aún más al habilitar IA32 (compatibilidad con 32 bits) para arrancar desde EFI, algo que no había sido posible hasta la fecha aparte de los sistemas con Itanium. Para los sistemas basados en BIOS, los pasos iniciales del proceso de arranque apenas han cambiado. La diferencia clave es que BOOTMGR es el cargador de arranque que se inicializa y, a continuación, lleva a cabo los siguientes pasos.
Busca en el directorio de arranque el archivo BCD, que es, de hecho, su propio subárbol del Registro. El archivo BCD contiene las entradas de arranque (incluidos los valores predeterminados) para arrancar. Consulte en la Figura 1 los tipos de imagen (tipos de archivo ejecutable) y en la Figura 2 los tipos de aplicación específicos que se inician. Una o varias de estas entradas pueden ser una referencia a ntldr. Sólo una de ellas puede hacer referencia realmente al GUID conocido que se usa para cargar ntldr (consulte la quinta fila de la Figura 3). A continuación, bootmgr decide la entrada que se cargará a continuación, en función de si el sistema está arrancando, ha hibernado o arranca en ntldr u otro administrador de arranque (en cuyo caso indicará otro sector de arranque e iniciará dicho cargador). Esto sería lo más habitual en el caso de arranque dual con un sistema operativo que no sea Windows. Puede encontrar más información en microsoft.com/whdc/system/platform/firmware/bcd.mspx.
Figure 3 Objetos de aplicación estándar (Close Figure 3)

Descripción | Identificador de BCDEdit | GUID
Administrador de arranque de Windows | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
Administrador de arranque de firmware | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Comprobador de memoria de Windows | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Aplicación de reanudación de Windows | Ningún alias | 147aa509-0358-4473-b83b-d950dda00615
Cargador heredado de Windows | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
Entrada de arranque actual | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
Entrada de arranque predeterminada | {default} | ningún GUID predefinido
Figure 2 Tipos de aplicación (Close Figure 2)

Descripción | Valor | Descripción
Administrador de arranque de firmware | 0x1 | Sólo se aplica a sistemas EFI.
Administrador de arranque de Windows | 0x2 | Controla el flujo de arranque. En un sistema de arranque dual, muestra un menú de selección de arranque al usuario.
Cargador de arranque de Windows | 0x3 | Carga una determinada versión o configuración de Windows.
Aplicación de reanudación de Windows | 0x4 | Restaura Windows a su estado de ejecución cuando el equipo se reanuda desde el modo de hibernación
Comprobador de memoria de Windows | 0x5 | Aplicación de diagnóstico de memoria.
Ntldr | 0x6 | Sólo se aplica a sistemas BIOS de PC/AT. Carga versiones de Windows anteriores a Windows Vista.
Sector de arranque | 0x8 | Aplicación de modo real de 16 bits. Sólo se aplica a sistemas BIOS de PC/AT. Se puede usar para reiniciar el proceso de arranque y cargar un sistema operativo que no sea Windows.
Figure 1 Tipos de imagen (Close Figure 1)

Descripción | Valor
Aplicación de firmware | 0x1
Aplicación de arranque | 0x2
Objeto de cargador basado en ntldr | 0x3
Aplicación de modo real | 0x4
Observará que la renovada estructura de arranque de Windows Vista está mucho más organizada que en versiones anteriores. Aparte de bootmgr, todo el código de arranque se encuentra en el directorio \boot en el nivel de raíz y se transfiere a los binarios específicos de Windows después de que así lo haya especificado BCD.

Arranque de Windows XP y Windows PE 2.0
Probablemente ahora empiece a ver cómo Windows PE, usando el administrador de arranque de Windows Vista, puede actuar como un intermediario que permita continuar el arranque de Windows XP o de versiones anteriores de Windows, a la vez que se agrega Windows PE 2.0 al conjunto de una herramienta de recuperación integrada.
Evidentemente va a agregar otro paso al proceso de arranque, pero es un paso que Microsoft ha diseñado. Con la idea de que la nueva infraestructura de bootmgr debía ser compatible con el archivo ntldr y otros administradores de arranque de terceros existentes, bootmgr se diseñó para admitir dichas soluciones.
Ahora que hemos examinado cómo arranca Windows y cómo funciona el nuevo BCD, ¿cómo los relacionamos los dos y colocamos Windows PE 2.0 en nuestra instalación de Windows XP existente? Hay dos formas de dejar de lado el sector de arranque de Windows Vista, el elemento de código de arranque que indica al sistema que inicie bootmgr. Una de ellas es usar diskpart y crear y formatear una nueva partición con Windows PE 2.0. Pero aquí no es posible, ya que se dispone de una instalación de Windows XP existente que no se desea dañar ni mover. En su lugar, siga este proceso:
  1. Asegúrese de que dispone de una copia de bootsect.exe y bcdedit.exe en el CD de arranque de Windows PE 2.0 (ambos se pueden encontrar en el DVD de instalación de Windows Vista).
  2. Arranque el sistema de Windows XP en el CD de Windows PE 2.0.
  3. Después del arranque, ejecute este comando:
    bootsect.exe /NT60 ALL
De este modo el sector de arranque se establecerá como el sector de arranque compatible con Windows Vista que sabe cómo iniciar bootmgr.
4. Copie el administrador de arranque en el disco duro:
    xcopy BOOTMGR C:\BOOTMGR /I
5. Copie el archivo boot.SDI en el directorio \BOOT del disco duro. Deberá hacer una copia del mismo antes del arranque, ya que estará bloqueado y no se podrá copiar mientras se ejecuta Windows PE:
    xcopy BOOT.SDI C:\BOOT\
Corrija la ruta de acceso del origen en consecuencia.
6. Copie boot.WIM en el disco duro. Al igual que SDI, deberá disponer de una copia secundaria. No podrá copiar el archivo que se está ejecutando:
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
Corrija la ruta de acceso del origen en consecuencia.
7. Ahora cree un nuevo almacén BCD:
    bcdedit /createstore
8. A continuación, cree las entradas de BCD para cargar Windows PE:
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. La última línea devolverá un GUID. Reemplace {YOURGUID} por el GUID real que se ha devuelto. En la Figura 4 se muestran las entradas del disco RAM que arrancan Windows PE desde el disco duro.
Figure 4 Entradas en el disco RAM que arrancan Windows PE desde el disco duro (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. Ahora cree las entradas de bootmgr para que se inicie el administrador de arranque:
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. Finalmente, configure una entrada BCD para la instalación de Windows existente (cambie el texto de presentación de Windows XP por otro que desee mostrar en el menú del administrador de arranque). El último comando también la establece como la primera entrada (predeterminada) del menú de arranque:
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. Ahora debe poder reiniciar el sistema e iniciar la instalación anterior de Windows o Windows PE 2.0 si selecciona la entrada adecuada del menú de arranque. En la Figura 5 se muestra el resultado de ejemplo de bcdedit /enum all. Este comando enumera todas las entradas de BCD después de haberlas agregado (en Windows PE 1.6).
Entrada de ejemplo
Entrada de ejemplo
He estado trabajando en un script que pueda realizar esta tarea automáticamente. Actualmente sólo puede copiar los archivos de arranque en el disco duro y configurar las entradas de BCD. No puede establecer que el sector de arranque sea el nuevo valor de Windows Server 2008 mientras se ejecuta Windows (se tiene que realizar sin conexión, en Windows PE). Puede encontrar el script en la sección de descargas del sitio web de TechNet Magazine en technetmagazine.com. Para ejecutar el script, tenga los siguientes elementos en el mismo directorio que el archivo VBScript que se está ejecutando:
  1. BCDEdit
  2. BOOTMGR
  3. Un directorio \BOOT\ (del medio de Windows Vista o Windows PE 2.0)
  4. Un directorio \SOURCES\ con un archivo BOOT.WIM de Windows PE 2.0 válido y desde el que se pueda arrancar
Creará el archivo BCD y copiará los archivos de arranque adecuados. Después de arrancar Windows PE y ejecutar bootsect, debe poder realizar el arranque dual.

Deshacer el arranque dual
Deshacer el arranque dual es mucho más sencillo que aplicarlo. Sólo debe restaurar el sector de arranque al anterior de Windows Vista mediante la ejecución del siguiente comando:
bootsect.exe /NT52 ALL
Una vez restaurado, puede eliminar bootmgr y el directorio \boot. En el reinicio siguiente, el sector de arranque forzará el inicio de ntldr y se quitarán por completo Windows PE 2.0 y todos los binarios de arranque de Windows Vista del flujo de arranque.

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


 Notas de campo: Done su PC
Notas de campo
Done su PC
Jim Lynch

La idea convencional durante muchos años acerca de la forma más económica de deshacerse de los equipos se plasmó en un artículo de investigación publicado en 2003 por Frances O'Brien de The Gartner Group, titulado "PC Disposal: TCO's Last Surprise". Este análisis comparativo de la forma de deshacerse de equipos consideró que la donación constituía la opción más cara (de seis opciones de eliminación) debido al tiempo que se tardaba en encontrar la organización benéfica que aceptara donaciones.
Sugerencias para donar
TechSoup.org ofrece sugerencias adicionales para donar y también para obtener donaciones en techsoup.org/recycle. Algunas cuestiones que se deben tener en cuenta antes de la donación:
  • No se aferre demasiado al equipo de TI después de haber actualizado al nuevo hardware. El equipo informático pierde su valor de reutilización después de cinco años. Del mismo modo, los teléfonos móviles llegan al final de su vida útil al cabo de tres años.
  • Done el equipo de TI de menos de cinco años a organizaciones de renovación en vez de hacerlo directamente a organizaciones benéficas o escuelas.
  • Embale los accesorios con el equipo, incluido el teclado, el mouse, la impresora, el módem, los discos de software y los manuales suministrados con el equipo.
  • Conserve una lista de lo que ha donado para su registro y obtenga un recibo. Puede tener derecho a deducciones fiscales si realiza la donación a una organización de renovación benéfica. En EE.UU. los donantes empresariales se pueden deducir el valor no amortizado del equipo y las personas físicas se pueden deducir el valor de mercado actual de un equipo. Para determinar el valor de venta de un equipo, vaya al tasador de equipos usados gratuito de Canadá (servlets.edeal.com/servlets/PcEval).

En la actualidad la situación ha cambiado radicalmente. De hecho, la EPA de EE.UU. se ha embarcado recientemente en una campaña ("Do the PC Thing") que enseña a los usuarios a preparar su hardware antiguo para reutilizarlo y ofrece una lista de recursos. Esta campaña forma parte del sitio de concienciación pública para el reciclaje y la reutilización, "Plug-In To eCycling" (epa.gov/plugin/). Haga clic en el vínculo "Reuse It!" para consultar los artículos dirigidos a consumidores o compañías.
En este sitio aprenderá que la cuestión más importante con respecto a la donación o reciclaje de hardware es su propia protección. La documentación de "Do the PC Thing" ofrece indicaciones básicas acerca de la limpieza de discos duros y los requisitos legales en cuanto a seguridad y confidencialidad. Si se deshace de su equipo tanto para su reciclaje al final de su vida útil como para reutilizarlo, debe quitar sus datos confidenciales, como contraseñas, documentos, información de tarjeta de crédito, mensajes de correo electrónico y registros web.
La mayoría de las compañías de reciclaje de componentes electrónicos, renovación y administración de activos proporcionan servicios de seguridad de datos mediante la destrucción de los discos duros o el uso de una utilidad de limpieza de disco que sobrescribe los datos de modo que no se puedan recuperar. Tenga en cuenta que si los equipos están destinados para reutilizarlos, es preferible mantener el hardware informático intacto.
El software de limpieza de discos acreditado usa las especificaciones 5220.22-M del Departamento de Defensa de EE.UU. Este tipo de limpieza de datos basada en software sobrescribe sistemáticamente todas las ubicaciones direccionables del disco duro con un carácter, comprueba la sobrescritura y, después, vuelve a sobrescribir todas las ubicaciones direccionables con caracteres aleatorios. En 2004, la agencia de seguridad nacional de EE.UU. (NSA Advisory LAA-006-2004) concluyó que una sola sobrescritura con el software estándar del Departamento de Defensa era suficiente para que los archivos no se pudieran recuperar.
Ahora es considerablemente sencillo efectuar un saneamiento propio de los datos. Hay aplicaciones de software gratuito acreditadas como Active@ Kill Disk Hard Drive Eraser (killdisk.com/eraser.htm) o Darik's Boot and Nuke (dban.sourceforge.net). Si tiene que limpiar los datos de varios equipos, considere la posibilidad de usar aplicaciones comerciales más sólidas como Blancco Data Cleaner (blancco.com) o WipeDrive (whitecanyon.com).
Si su equipo de TI tiene más de cinco años o está muy averiado, una de las seis opciones de eliminación que estudió Gartner es el reciclaje al final de la vida útil de componentes electrónicos. En la actualidad hay más de 900 compañías que realizan este trabajo en EE.UU. Para reciclar correctamente el equipo de TI antiguo, consulte la lista de recicladores responsables de la Electronic TakeBack Coalition (www.computertakeback.com/the_solutions/recyclers_map.cfm).

Jim Lynches director del programa de reciclaje y reutilización de equipos en TechSoup.org, una empresa no lucrativa de alta tecnología con sede en San Francisco, cuyo objetivo es suministrar hardware, software y conocimientos de bajo costo a organizaciones benéficas de todo el mundo.


 Confidencial de Windows: Recortar los recortes
Confidencial de Windows
Recortar los recortes
Raymond Chen

No sucede con frecuencia , pero en ocasiones se elimina una característica antigua, con gran alegría por parte del equipo de producto. En Windows® XP, por ejemplo, se ha quitado la interfaz para establecer un patrón de escritorio. La funcionalidad subyacente sigue estando, si consigue escribir un programa que llame a SystemParametersInfo(SPI_SETDESKPATTERN), pero ya no hay una interfaz integrada para ello. ¿Por qué se ha quitado el patrón de escritorio del panel de control del escritorio?
Nuestra investigación demuestra que prácticamente nadie usaba los patrones de escritorio. Eran más populares cuando la memoria era muy cara y los usuarios no querían desperdiciar nada de la memoria del equipo en un mapa de bits de 1 MB para papel tapiz. Un diminuto patrón monocromo de 8 x 8 repetido por la pantalla ofrecía un cierto grado de personalización en una pantalla de 640 x 480 a un costo mucho menor.
No obstante, los cambios a lo largo de los años despojaron de su atractivo a los patrones de escritorio. En primer lugar, y como es lógico, los equipos ahora tienen mucha más memoria de la que tenían en 1983. En segundo lugar (y como también es lógico), los monitores tienen mayor resolución que entonces. Un encantador patrón de pata de gallo de 8 x 8 es básicamente una mancha gris cuando se muestra en un monitor de 1600 x 1200.
No es la única característica antigua que se ha ido al vertedero. Otro ejemplo son los recortes. Presentados en Windows 95, los recortes aparecían como fragmentos de documentos capturados en un archivo. Dicho fragmento de archivo es realmente un objeto OLE. La idea subyacente en los recortes es que se pudiera, por ejemplo, resaltar texto en un procesador de textos y arrastrarlo al escritorio, donde se creaba un recorte. Más tarde, se podía tomar ese recorte y arrastrarlo en el procesador de textos u otro programa, y el texto usado para crear el recorte se insertaba en el nuevo documento. Es un tipo de copiar y pegar, con la diferencia de que en vez de almacenar los datos temporalmente en el portapapeles, se almacenan en un archivo.
Ahora bien, una vez creado un archivo de recorte lo único que realmente se podía hacer con él era arrastrarlo a otro documento, de la misma forma que lo único que realmente se puede hacer con algo del portapapeles es pegarlo en alguna parte. En algún momento, alguien agregó la característica de que se podía hacer doble clic en el archivo de recorte y abrirlo en la aplicación que lo había creado originalmente (el contenido podía ser cualquier cosa, por lo que la única forma de mostrar el recorte es preguntar al programa que lo ha creado originalmente).
No sé si esta característica se agregó como una herramienta de depuración o para que los usuarios pudieran ver el contenido de un recorte sin tener que crear un documento ficticio para colocarlo en él. De cualquier manera, a los autores de virus les encantó esta funcionalidad de "abrir la aplicación que originalmente creó el recorte" porque les permitía crear un archivo de recorte y rellenarlo con datos que dijeran: "La aplicación original es cmd.exe y el fragmento de documento es este archivo por lotes". Cuando un usuario hacía doble clic en ese archivo de recorte concreto para ver su contenido, el visor de recortes enviaba un archivo por lotes al procesador de comandos y le decía: "Ábrelo y muéstraselo al usuario".
Debido a la historia de los recortes, el equipo del shell decidió quitar la característica de Windows Vista®. Para ello, tuvo que investigar la popularidad de los recortes en el mundo real. Así que el equipo del shell pidió al grupo de soporte técnico que consultara en sus registros cuántas personas habían llamado con preguntas acerca de los recortes. La teoría es que las características populares reciben llamadas de soporte técnico y las que no lo son no reciben llamadas (porque nadie las usa). Los recortes en concreto no están en la categoría de categorías "manifiestamente intuitivas", por lo que un número reducido de llamadas no se puede explicar con este argumento: "La característica es tan evidente que nadie necesita llamar para obtener ayuda".
La respuesta llegó del grupo de soporte técnico. El año pasado el grupo recibió un total de cuatro llamadas. Y todas fueron del tipo: "He creado este archivo extraño. ¿Qué es y cómo me deshago de él?"

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. Ha pasado una eternidad desde que Raymond te ha visto y se pregunta cómo está la familia.