Planeación de la disponibilidad (Windows SharePoint Services)

En este artículo se describen la disponibilidad en general, los costos y desafíos relacionados con la disponibilidad en un entorno de Productos y Tecnologías de SharePoint, y las estrategias y soluciones que se pueden usar en el entorno. Lea este documento si tiene una granja de servidores donde se ejecuta Windows SharePoint Services 3.0 o un entorno de alta disponibilidad con Microsoft Office SharePoint Server 2007, Microsoft Office Forms Server 2007 o Microsoft Search Server 2008. También puede descargar e imprimir el modelo de disponibilidad de Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?linkid=122369&clcid=0xC0A (en inglés)) que acompaña a este artículo, que proporciona un resumen de tamaño póster del contenido de este artículo.

¿Qué es la disponibilidad?

La disponibilidad es el grado con el que los usuarios consideran que un entorno de Productos y Tecnologías de SharePoint está disponible. Garantizar la disponibilidad significa asegurarse de que un sistema es resistente, es decir, que se produzcan incidentes que afecten al servicio con poca frecuencia y que se realicen acciones oportunas y eficaces cuando esto suceda. Las estrategias de disponibilidad minimizan la percepción de los usuarios de los tiempos de inactividad planeados y no planeados.

Una de las formas más habituales de medir la disponibilidad es el porcentaje de tiempo activo expresado como número de nueves; es decir, el porcentaje de tiempo durante el cual un determinado sistema permanece activo y en funcionamiento. Por ejemplo, se considera que un sistema con un porcentaje de tiempo activo de 99,999 tiene una disponibilidad de cinco nueves.

En la siguiente tabla se correlaciona el número de nueves con los equivalentes en tiempo de calendario.

Porcentaje de tiempo activo aceptable	Tiempo de inactividad por día	Tiempo de inactividad por mes	Tiempo de inactividad por año
95	72,00 minutos	36 horas	18,26 días
99	14,40 minutos	7 horas	3,65 días
99,9	86,40 segundos	43 minutos	8,77 horas
99,99	8,64 segundos	4 minutos	52,60 minutos
99,999	0,86 segundos	26 segundos	5,26 minutos

Si puede realizar una estimación informada sobre el número de horas totales de inactividad que es probable que se produzcan, puede usar las fórmulas siguientes para calcular el porcentaje de tiempo de actividad para un año, un mes o una semana:

% de tiempo de actividad/año = 100 - (8760 - número total de horas de inactividad al año)/8760

% de tiempo de actividad/mes = 100 - ((24 * número de días del mes) - número total de horas de inactividad del mes del calendario)/(24 * número de días del mes)

% de tiempo de actividad/semana = 100 - (168 - número total de horas de inactividad de la semana)/168

Qué no es la disponibilidad

La disponibilidad no consiste en proteger y recuperar los datos ni en realizar una recuperación ante desastres, aunque estos conceptos están relacionados y debe disponer de planes de protección de datos y recuperación ante desastres en cualquier sistema con alta disponibilidad. La protección y la recuperación de datos es la necesidad empresarial general subyacente en las siguientes necesidades empresariales específicas:

• Mantener y ser capaz de revisar más de una versión de un elemento o sitio.

• Recuperación de sitios o elementos eliminados accidentalmente.

• Archivar datos por motivos legales, normativos o empresariales.

• Restauración de sistemas en el caso de errores de hardware o software inesperados.

Además, la disponibilidad no consiste en la administración de la continuación del negocio (BCM). BCM consiste en las decisiones, procesos y herramientas empresariales que se aplican por anticipado para poder enfrentarse a crisis. Una crisis puede ser local, regional o nacional, o bien estar sólo relacionada con su negocio.

Las estrategias de administración de protección de datos y disponibilidad de Productos y Tecnologías de SharePoint pueden formar parte de su plan técnico de BCM, pero el plan global de BCM debería ser mucho más completo e incluir los siguientes elementos:

• Procedimientos claramente documentados.

• Almacenamiento fuera del sitio de los registros empresariales clave.

• Contactos designados claramente.

• Aprendizaje continuo del personal.

• Mecanismos de recuperación fuera del sitio.

Costos de la disponibilidad

La disponibilidad es uno de los requisitos más caros de un sistema. Cuanto mayor sea el nivel de disponibilidad y más sistemas haya que proteger, tanto más compleja y costosa es probable que sea una solución de disponibilidad. Al invertir en disponibilidad, se incluyen los costos siguientes:

• Hardware y software adicionales, que a menudo implican operaciones complejas entre el software, como scripts personalizados para la recuperación y la conmutación por error.

• Complejidad operativa adicional.

Los costos implicados en conseguir una alta disponibilidad deben evaluarse según sus necesidades empresariales; no es probable que todas las soluciones de una organización requieran el mismo nivel de disponibilidad. Puede ofrecer distintos niveles de disponibilidad para distintos sitios y servicios: por ejemplo, inteligencia empresarial y búsquedas o distintas granjas de servidores.

La disponibilidad es un área clave en la que los grupos de tecnología de la información (TI) ofrecen contratos de nivel de servicio para establecer las expectativas con los grupos de clientes. Muchas organizaciones de TI ofrecen diversos contratos de nivel de servicio asociados con distintos niveles de facturación.

Retos de disponibilidad en Productos y Tecnologías de SharePoint

Una implementación de Productos y Tecnologías de SharePoint plantea los siguientes retos para proporcionar disponibilidad:

• Mientras se aplican revisiones o se actualiza la granja de servidores, ésta no está disponible.

• No se puede obtener la redundancia del servidor de índices al instalar la función de índice en varios servidores. Para superar la pérdida de un servidor de índices, debe volver a instalar el servidor y restaurarlo a partir una copia de seguridad o depender de resultados algo obsoletos mientras la búsqueda rastrea el contenido. Si lo desea, puede usar una de las técnicas descritas en Disponibilidad de búsqueda tras conmutación por error para reducir el tiempo que se tarda en recuperar la búsqueda.

• Productos y Tecnologías de SharePoint no reconoce la creación de reflejos de SQL Server. Aunque se recomienda considerar el uso de la creación de reflejos de SQL Server como una técnica de disponibilidad, hacerlo requiere una automatización adicional.

Cuándo tener en cuenta la disponibilidad

Se recomienda tener en cuenta los requisitos de disponibilidad como parte del diseño principal de la solución SharePoint. Además, puede aumentar la disponibilidad después de implementar la solución. Desde un punto de vista operativo, se recomienda implementar y ajustar la solución principal en la granja de servidores y, a continuación, probar las soluciones de disponibilidad.

Determinación de los requisitos de disponibilidad

Para evaluar la tolerancia frente al tiempo de inactividad de un sitio, servicio o granja de servidores por parte de la organización, responda a las siguientes preguntas para el sitio, servicio o granja de servidores.

• Si el sitio, el servicio o la granja de servidores dejan de estar disponibles, ¿dejarán los empleados de la organización de poder cumplir razonablemente sus responsabilidades laborales?

• Si el sitio, el servicio o la granja de servidores dejan de estar disponible, ¿se detendrán las transacciones comerciales y las relaciones con los clientes, con las consiguientes pérdidas que ello supone para dichos ámbitos?

Si respondió afirmativamente a alguna de estas preguntas, debe invertir en una solución de disponibilidad.

Elección de una estrategia de disponibilidad

Puede elegir entre muchos enfoques diferentes para aumentar la disponibilidad, entre los que se incluyen:

• Tolerancia a errores de componentes.

• Redundancia y conmutación por error entre las funciones de servidor en una granja de servidores.

• Redundancia y conmutación por error entre granjas de servidores.

Requisitos del sistema para la disponibilidad

En un escenario ideal, los componentes de conmutación por error y los sistemas coinciden con los componentes principales y el sistema en todos los aspectos: plataforma, hardware y número de servidores. Como mínimo, el entorno de conmutación por error debe poder controlar el tráfico previsto durante una conmutación por error. Tenga en cuenta que es posible que el sitio de conmutación por error sólo pueda atender a un subconjunto de usuarios. Los sistemas deben coincidir al menos en lo siguiente:

• Versión del sistema operativo y todas las actualizaciones

• Versiones de SQL Server y todas las actualizaciones

• Versiones de Productos y Tecnologías de SharePoint y todas las actualizaciones

Aunque en este artículo se describe principalmente la disponibilidad de Productos y Tecnologías de SharePoint, el tiempo de actividad del sistema también se verá afectado por el resto de los componentes del sistema. Concretamente, tenga en cuenta lo siguiente:

• Debe asegurarse de que las dependencias de infraestructura como la electricidad, la refrigeración, la red, el directorio y SMTP sean totalmente redundantes.

• Elija un mecanismo de conmutación para el sistema, ya sea DNS o equilibrio de carga del hardware, que se ajuste a sus necesidades. En los siguientes artículos encontrará los procedimientos recomendados para servidores web de equilibrio de carga:

  • Diseño empresarial para el equilibrio de carga (en inglés) (https://go.microsoft.com/fwlink/?linkid=122194&clcid=0xC0A) (en inglés)

  • Diseño empresarial para DNS (en inglés) (https://go.microsoft.com/fwlink/?linkid=122196&clcid=0xC0A) (en inglés)

Tolerancia a errores de componentes

En cualquier sistema, se recomienda colaborar con los proveedores de hardware para que aprovisionen hardware tolerante a errores que sea adecuado para el sistema, incluidas las matrices redundantes de discos independientes (RAID). Para leer las recomendaciones, vea Planeación del rendimiento y la capacidad (Windows SharePoint Services).

Al planear la tolerancia a errores de los componentes, tenga en cuenta lo siguiente:

• La redundancia completa de todos los componentes en de un servidor puede no ser posible o poco práctica. Use servidores adicionales para lograr una redundancia adicional.

• Considere la posibilidad de una redundancia de componentes para la función del servidor de índices, ya que dicha función no se puede convertir en redundante.

• Asegúrese de que los servidores tienen varios sistemas de alimentación conectados a distintas fuentes de alimentación para conseguir una redundancia máxima.

Redundancia y conmutación por error entre las funciones de servidor en una granja de servidores

Productos y Tecnologías de SharePoint es compatible con las funciones del servidor en ejecución en equipos redundantes (es decir, ampliación de capacidad) de una granja de servidores para aumentar la capacidad y mejorar el rendimiento, además de proporcionar disponibilidad básica. La capacidad y el rendimiento determinan el número de servidores y el tamaño de los servidores de una granja. Una vez cumplidos los requisitos básicos, es posible que desee agregar más servidores para aumentar la disponibilidad general del servicio.

Disponibilidad en una única granja de servidores

En la siguiente tabla se describen los servidores y las funciones de servidor en un entorno de Productos y Tecnologías de SharePoint, tal y como se enumeran en la página Servicios del servidor del sitio web de Administración central de SharePoint, además de las estrategias básicas de redundancia que se pueden usar para cada uno de ellos en la granja de servidores.

Servicios del servidor	Estrategia básica de redundancia preferida en una granja de servidores
SQL Server	Agrupación en clústeres o creación de reflejo sincrónico. La agrupación en clústeres es más sencilla de implementar pero puede resultar más cara. Para obtener más información sobre cómo usar la creación de reflejo sincrónico, vea White paper: Using database mirroring.
Servidores web	Implementación en varios servidores y equilibrio de carga mediante software o equilibrio de carga de hardware.
Servidor web para granjas de servidores medianas (servicios de consulta de búsqueda y de aplicación web)	Implementación en varios servidores.
Indización de búsqueda	No se puede implementar en varios servidores y lograr que sea redundante. Debe usar una estrategia de disponibilidad diferente. Para obtener más información, vea Disponibilidad de búsqueda tras conmutación por error.
Excel Calculation	Implementación en varios servidores.
Aplicación Project	Implementación en varios servidores.

Para obtener más información, vea Planeación de la redundancia (Windows SharePoint Services).

Comparación de las estrategias de disponibilidad de la base de datos para una única granja de servidores: clúster de conmutación por error de SQL Server frente a la creación de reflejo de alta disponibilidad de SQL Server

En la siguiente tabla se compara el clúster de conmutación por error con la creación de reflejo sincrónica de alta disponibilidad de SQL Server.

Clúster de conmutación por error de SQL Server	Creación de reflejo de alta disponibilidad de SQL Server
El reflejo asume el control inmediatamente tras el error.	El reflejo asume el control inmediatamente tras el error.
Coherente en el nivel de transacción.	Coherente en el nivel de transacción.
Simultáneo en el nivel de transacción.	Simultáneo en el nivel de transacción.
Reducción del tiempo de recuperación (de segundos a minutos).	Leve aumento del tiempo de recuperación (de segundos a minutos).
Los nodos de la base de datos detectan automáticamente el error; Productos y Tecnologías de SharePoint hace referencia al clúster, por lo que la conmutación por error desde el punto de vista de Productos y Tecnologías de SharePoint es perfecta y automática.	Requiere scripting para lograr la conmutación por error de Productos y Tecnologías de SharePoint.
No protege contra el almacenamiento con errores, dado que el almacenamiento se comparte entre los nodos del clúster.	Protege contra el almacenamiento con errores porque los servidores de base de datos principal y reflejada escriben en discos locales.
Requiere un almacenamiento compartido más caro.	Puede usar almacenamiento de acceso directo (DAS), que resulta menos caro.
Se obtiene la misma subred.	Hasta 1 milisegundos (ms) en la latencia entre servidores de SQL Server y web.
Puede usar el modelo de recuperación simple de SQL Server, aunque el único punto de recuperación disponible si se pierde el clúster será la última copia de seguridad completa.	Requiere el modelo de recuperación completa de SQL Server.
No hay sobrecarga en el rendimiento.	Presenta latencia transaccional. Agrega una sobrecarga de memoria y procesador.
Mínima carga operativa.	Carga operativa adicional, incluido el scripting y la configuración de alias de SQL Server.

Redundancia y conmutación por error entre centros de datos próximos configurados como una única granja de servidores (granja “expandida”)

Algunas empresas tienen centros de datos próximos con conexiones de ancho de banda alto para poder configurarlos como una única granja de servidores. Esto se denomina granja "expandida". Para que una granja de estas características funcione, debe haber una latencia de menos de 1 milisegundo entre SQL Server y los servidores web en una dirección, y un ancho de banda de al menos 1 gigabit por segundo.

• En este escenario, puede proporcionar redundancia para las bases de datos mediante la creación de reflejo sincrónico. Dentro de la granja expandida, puede crear un reflejo de la base de datos de configuración y de las bases de datos de contenido. Para ver un caso práctico de cómo una compañía usa una granja expandida, vea White paper: Case Study of High Availability for SharePoint using Database Mirroring.

• Póngase en contacto con su proveedor de SAN para determinar si puede usar la replicación de SAN u otro mecanismo compatible para proporcionar disponibilidad en los centros de datos, como ejecutar SQL Server en clústeres de servidores dispersos geográficamente. Compruebe si la solución de replicación de SAN ofrece un nivel suficiente de simultaneidad y coherencia de transacciones.

En una granja de servidores expandida, se puede proporcionar tolerancia a errores para servidores de aplicaciones que ejecutan SSP mediante:

• Varios servidores de consultas

• Varios servidores que ejecutan Excel Calculation Services

El servidor de índices es un punto único de error en este escenario. Puede hacer una copia de seguridad y una restauración de la búsqueda o, si la simultaneidad de búsquedas tras la recuperación es vital, puede usar una granja de servidores del SSP de conmutación por error. Para obtener más información, vea Disponibilidad de búsqueda tras conmutación por error.

Granja "expandida"

Redundancia y conmutación por error entre centros de datos con varias granjas de servidores

Puede configurar una granja de servidores de conmutación por error para proporcionar disponibilidad en un centro de datos independiente de la granja de servidores principal. Un entorno con una granja de servidores de conmutación por error independiente tiene las siguientes características:

• En la granja de servidores de conmutación por error debe mantenerse una base de datos de configuración independiente y una base de datos de contenido de Administración central.

  Nota

  Si ha configurado la asignación alternativa de acceso para la granja de servidores principal, es especialmente importante configurarla de forma idéntica en la granja de servidores de conmutación por error.

• Todas las personalizaciones se deben implementar en ambas granjas de servidores.

• Las revisiones se deben aplicar a ambas granjas de forma individual.

• La creación de reflejo asincrónica o el trasvase de registros a la granja de servidores de conmutación por error sólo se puede realizar correctamente con las bases de datos de contenido.

• Las bases de datos reflejadas o cuyos registros se han trasvasado deben configurarse para usar el modelo de recuperación completa.

• Se pueden hacer copias de seguridad de las bases de datos del SSP y restaurarlas en la granja de servidores de conmutación por error.

Póngase en contacto con su proveedor de SAN para determinar si puede usar la replicación de SAN u otro mecanismo compatible para proporcionar disponibilidad en los centros de datos.

Esta topología se puede repetir en muchos centros de datos si configura el trasvase de registros de SQL Server para uno o varios centros de datos.

Granjas de servidores principales y de conmutación por error antes de la conmutación por error

En la tabla siguiente se describen los servidores y las funciones de servidor en un entorno de Productos y Tecnologías de SharePoint, así como las estrategias básicas de redundancia que se pueden usar para cada uno entre las granjas de servidores.

Servidor o función de servidor	Estrategia básica de redundancia preferida entre granjas de servidores
SQL Server	Creación de reflejo de la base de datos asincrónica de SQL Server, trasvase de registros de SQL Server y otros mecanismos de replicación asincrónica. Nota No se puede usar para las bases de datos del SSP que hospedan la información de búsqueda.
Servidores cliente web	Implementar en ambas granjas de servidores, incluidas las personalizaciones.
Servidor web para granjas de servidores medianas (servicios de consulta de búsqueda y de aplicación web)	Implementar en ambas granjas de servidores.
Indización de búsqueda	Implementar en ambas granjas de servidores. Recuperar la copia de seguridad de la granja de servidores original para moverla a la granja de servidores de conmutación por error.
Excel Calculation	Implementar en ambas granjas de servidores. Si el SSP no hospeda la búsqueda, puede usar la creación de reflejo de base de datos asincrónica, el trasvase de registros de SQL Server u otro mecanismo de replicación asincrónica para mover los datos a una granja de servidores de conmutación por error. Si el SSP también hospeda la búsqueda, debe recuperar la copia de seguridad de la granja de servidores original para moverla.
Aplicación Project	Implementar en ambas granjas de servidores. Recuperar la copia de seguridad de la granja de servidores original para moverla a la granja de servidores de conmutación por error.

Replicación asincrónica y búsqueda

La búsqueda requiere la sincronización completa entre la base de datos de búsqueda, la base de datos del SSP y el índice. Debido a este requisito, la búsqueda no se puede replicar entre granjas de servidores mediante un mecanismo de replicación asincrónica (creación de reflejo de la base de datos asincrónica, trasvase de registros o replicación asincrónica de SAN). Para proporcionar la búsqueda en una granja de servidores de conmutación por error, debe recuperar el SSP de búsqueda.

Disponibilidad de búsqueda tras conmutación por error

La función del servidor de índices no puede ser redundante en una granja de servidores. Las necesidades de la empresa de contar con una simultaneidad de búsquedas tras la conmutación por error podrían determinar la arquitectura lógica de la solución.

• Si la empresa no requiere una simultaneidad de búsquedas y disponibilidad inmediatas tras la conmutación por error, puede hacer una copia de seguridad y restaurar el SSP de búsqueda en el sitio de conmutación por error.

• Si la empresa requiere una simultaneidad de búsquedas y disponibilidad rápidas, puede usar uno de los métodos siguientes:

• Arquitectura de granja de servidores única con dos SSP idénticos.

• Una granja de servidores primaria centralizada que hospede la búsqueda y otros SSP. El servicio de búsqueda en la granja de servidores primaria rastrea el contenido de todas las demás granjas de servidores. Esta arquitectura sirve para admitir una o varias granjas de servidores.

Granja de servidores única con dos SSP

La siguiente arquitectura protege frente a un error del servidor de índices. En esta topología, los dos SSP rastrean el mismo contenido y usan las mismas reglas. El SSP de conmutación por error no está conectado al sitio web principal a menos que se produzca una conmutación por error.

Granja de servidores única con dos SSP

Esta topología tiene las siguientes limitaciones:

• Requiere el doble de espacio para los índices de cada servidor de consultas.

• Requiere cambiar manualmente una aplicación web para usar el SSP de conmutación por error (puede convertirse en script).

• Reduce a la mitad el tamaño del conjunto de documentos que se puede rastrear.

• De forma predeterminada, si se habilitan los perfiles, los perfiles del SSP de conmutación por error no están sincronizados con los perfiles de los SSP principales, sino que se encontrarán en el mismo estado en el que estaban cuando se importaron al principio. Para que los perfiles de todos los SSP estén sincronizados, debe usar el motor de replicación de perfiles de usuario (User Profile Replication Engine) que se incluye en el kit de herramientas de 32 bits SharePoint Administration Toolkit (en inglés) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0xC0A) (en inglés) o en el kit de herramientas de 64 bits SharePoint Administration Toolkit (en inglés) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0xC0A) (en inglés). Para obtener más información, vea User Profile Replication Engine (Office SharePoint Server).

La capacidad de rastrear grandes conjuntos de datos de manera oportuna se ve afectada por varios factores, entre los que se incluyen la latencia y el ancho de banda entre servidores de índices y servidores web.

En un entorno con un ancho de banda limitado, esta topología puede reducir considerablemente el rendimiento. Al rastrear el contenido dos veces, se cargan aún más los repositorios de contenido que se van a rastrear, lo que afecta al rendimiento de los repositorios. Es posible que también se vea afectada negativamente la capacidad de búsqueda para mantener el índice actualizado.

Granjas de servidores de SSP centralizadas

En la siguiente arquitectura, el uso de una granja de servidores primaria de SSP protege contra los errores de un servidor de índices. Aunque puede parecer una solución que requiere mucho hardware, las distintas granjas de servidores de SSP pueden compartir una parte del hardware, como el servidor de base de datos reflejada o agrupada, siempre que los servidores de índices residan en servidores distintos. Para obtener más información sobre la planeación y la configuración de granjas de servidores de SSP, vea Plan SSP architecture.

Esta topología tiene las siguientes ventajas:

• La administración de SSP está centralizada.

• Tras un error en una granja de servidores no es necesario volver a rastrear.

Granjas de servidores de SSP centralizadas

Esta topología tiene las siguientes limitaciones:

• Para el rastreo de contenido a través de una red de área extensa (WAN) se usa ancho de banda.

• Puede resultar difícil mantener los índices actualizados en entornos con grandes volúmenes de datos e índices de cambio altos.

• El rendimiento de las consultas puede verse afectado por el rendimiento de los vínculos WAN.

• De forma predeterminada, si se habilitan los perfiles, los perfiles de la granja de servidores del SSP de conmutación por error no están sincronizados con los perfiles de los SSP principales, sino que se encontrarán en el mismo estado en el que estaban cuando se importaron al principio. Para que los perfiles de todos los SSP estén sincronizados, debe usar el motor de replicación de perfiles de usuario (User Profile Replication Engine) que se incluye en el kit de herramientas de 32 bits SharePoint Administration Toolkit (en inglés) (https://go.microsoft.com/fwlink/?linkid=119535&clcid=0xC0A) (en inglés) o en el kit de herramientas de 64 bits SharePoint Administration Toolkit (en inglés) (https://go.microsoft.com/fwlink/?linkid=119536&clcid=0xC0A) (en inglés). Para obtener más información, vea User Profile Replication Engine (Office SharePoint Server).

Resumen

Revise detenidamente los requisitos de disponibilidad. Cuanto mayor sea el nivel de disponibilidad y el número de sistemas que hay que proteger, más compleja y costosa será una solución de disponibilidad con toda probabilidad.

Los costos necesarios para lograr la disponibilidad deberán evaluarse según las necesidades de la empresa. Probablemente no todas las soluciones de una organización requieran el mismo nivel de disponibilidad. Se pueden ofrecer distintos niveles para distintos sitios, servicios (por ejemplo, búsqueda e inteligencia empresarial) o granjas de servidores.

Agradecimientos

El equipo de publicación de contenido de Microsoft Office SharePoint Server agradece la participación de los siguientes revisores técnicos en este documento:

• Bill Baer, Servicios en línea de Microsoft, SharePoint hospedado, arquitecto tecnológico

• James Petrosky, Servicios de consultoría de Microsoft, consultor sénior

• Steve Peschka, Servicios de consultoría de Microsoft, arquitecto sénior de IW

• Dan Winter, Servicios de soporte al cliente de Microsoft, ingeniero de escalación

• Sean Livingston, Productos y Tecnologí­as de Microsoft SharePoint, jefe de programa

• Mike Watson, arquitecto tecnológico

• Todd Carter, Ingeniería de Microsoft Premier Field, ingeniero jefe de Premier Field

• Mike Plumley, Microsoft Office Project Server, redactor

• Christophe Fiessinger, Microsoft Office Project, director sénior de producto técnico

• Sid Shah, Microsoft Search, jefe de programa

• Luca Bandinelli, Productos y Tecnologí­as de Microsoft SharePoint, jefe de programa