Dentro de SharePoint Administración de proyectos de empresa con SharePoint

Pav Cherny

Contenido

Arquitectura de Server del proyecto
Integración de SharePoint
Las implementaciones de servidor del conjunto de servidores
Bienvenido a IIS 7
Los permisos de base de datos de sesión
Permisos de servicios compartidos
Firewall de Windows
MOPS servicios y cuentas de servicio
Integración de servicios de análisis
Conclusión

¿Las tecnologías de SharePoint más adecuadas para usted? En su esfuerzo por para encontrar la respuesta, ha probablemente sifted a través de una lista aparentemente infinitas de categorías, incluida la colaboración y equipos Social (Social), portales, búsqueda empresarial, administración de contenido empresarial, los procesos empresariales y formularios, Business Intelligence y capacidades de plataforma de programador y compara las características disponibles en Windows SharePoint Services (WSS) 3.0, Microsoft Office Search Server 2008 Express, Microsoft Office Forms Server 2007 y Microsoft Office SharePoint Server (MOSS) 2007. Sin embargo, hay una tecnología que es posible que nunca haber considerado porque Microsoft no enumera en productos y tecnologías de SharePoint, Enterprise Project Management (EPM), que está habilitada a través de Microsoft Office Project Server (MOPS) 2007.

Pero MOPS 2007 es tecnología SharePoint; se basa en y WSS 3.0 se extiende de modo que es comparable a MOSS 2007. MOPS 2007 es la opción derecha si desea aumentar la eficacia de colaboración de equipos dentro y entre los departamentos a través de trabajo, recursos y administración de la cotización más allá de las capacidades de ligero tareas de administración incluidas en WSS 3.0 y MOSS 2007. Con MOPS, puede activar sitios de equipo en las áreas de trabajo del proyecto, administrar colaboración en equipo dentro y entre departamentos y establecer una sólida base EPM para toda una organización. Primero, sin embargo, tiene dominar los desafíos de implementación.

En esta columna, describen la implementación de MOPS 2007 en un entorno Windows Server 2008 con SQL Server 2005 SP2 y WSS 3.0 SP1. En primer lugar, Revise brevemente la arquitectura de MOPS para mostrar cómo integran los componentes con WSS 3.0 desde punto de vista un arquitecto del sistema. Esta información resulta más fácil seguir el debate posteriores de implementación típica y los desafíos de integración puede encontrarse con, como problemas de configuración de grupo de aplicaciones, falta permisos de acceso, cola del sistema inicio errores y los problemas relacionados con SQL Server 2005 Analysis Services.

Para ilustrar la implementación y pasos para solucionar el problema, utilizo un entorno de pruebas básicas con dos servidores de WSS 3.0 en un conjunto de servidores, un controlador de dominio dedicados, y un equipo independiente que ejecuta SQL Server, que se similar del entorno de prueba he usado hasta ahora para esta columna de SharePoint. Encontrará hojas de cálculo correspondientes con instrucciones paso a paso en el material complementario de esta columna, ubicada en el sitio Web TechNet Magazine.

Arquitectura de Server del proyecto

MOPS 2007 es una de las aplicaciones de SharePoint más avanzadas y complejas. Aprovecha al máximo los de la plataforma de WSS 3.0 para la administración centralizada, aprovisionamiento del sitio, autenticación y seguridad. Además, agrega más componentes, como 25 general y elementos Web de MOPS especializada y una nueva colección de hasta cuatro bases de datos de MOPS por sitio de Project Web Access (PWA). Cada uno se tiene acceso a través de un conjunto de 21 públicos e internos MOPS servicios Web que conjuntamente forman el Project Server Interface (PSI), tal como se muestra en la figura 1 . Se puede obtener información más detallada acerca de MOPS servicios Web en MSDN.

fig01.gif

La figura 1 la integración de SharePoint con 2007 MOPS (haga clic en la imagen de una vista más grande)

La arquitectura MOPS 2007 se basa en una variedad de componentes distribuidos a través de las estaciones de trabajo cliente, servidores de aplicaciones y servidores de bases de datos. Describa el más importante de estos componentes en esta columna, pero si está interesado en todos los detalles técnicos, leer la " Arquitectura de Server del proyecto"documentación de Project 2007 SDK.

Sólo se tenga en cuenta cuando leer el SDK que elementos Web de PWA y Microsoft Office Project Professional 2007 no tienen acceso a los servicios Web de PSI directamente. El SDK de sugiere que los clientes hacer llamadas directas a la PSI, pero la mayoría de las aplicaciones realmente utiliza el reenviador PSI, que es un componente de sitios de PWA que proporciona acceso indirecto a los servicios Web de PSI. Sólo basadas en servidor componentes, como el servicio de cola y el servicio de eventos, que se ejecutan con permisos system-level hacer llamadas PSI directas. Este detalle poco es importante que recuerde solucionar situaciones por varias razones, específicamente:

  • Sitios de PWA definen contexto de base de datos (cada sitio de PWA único tiene bases de datos borrador, publicados, archivo y generación de informes independientes) y permisos de usuario, pero las cuentas de usuario normal no se conceden acceso a los servicios Web de PSI.
  • El reenviador PSI no es compatible con la suplantación y utiliza cuenta del grupo de aplicación el sitio de PWA para obtener acceso a los servicios Web de PSI en nombre de los usuarios.
  • Las llamadas PSI no debe necesariamente utilizar servicios Web de PSI locales si el conjunto de servidores incluye varias instancias de servidor de aplicaciones.

Integración de SharePoint

Ahora echemos un vistazo más cerca de la integración de MOPS real con SharePoint. Desde la perspectiva de un administrador de SharePoint, MOPS es una aplicación Web compartida administra como un servicio del conjunto de servidores de administración central de SharePoint 3.0. Esto es relativamente sencillo para los administradores familiarizados con el servicio proveedores compartidos (SSP) de MOSS 2007.

Pero si es un administrador de WSS 3.0 y nuevos a la administración del SSP, se desea desproteger la hoja "implementar Project Server 2007", disponible en el material complementario, para que obtener instrucciones paso a paso para crear y configurar servicios compartidos y PWA de un conjunto de servidores de SharePoint sitios. Después de la instalación de MOPS y configuración, puede analizar la implementación del sistema en el Administrador de IIS. Tal como se muestra en la figura 2 , debe ver sitios de Web independientes para servicios compartidos, administración de SSP y colecciones de sitios en un servidor de aplicaciones MOPS.

fig02.gif

La Figura 2 acceso de Project Server 2007 mediante PWA y PSI reenviador (haga clic en la imagen de una vista más grande)

Los clientes tener acceso a los servicios Web de PSI mediante el directorio virtual _VTI_BIN/PSI en un sitio de PWA. Sin embargo, los servicios Web de PSI no residen en este directorio virtual. El directorio virtual _VTI_BIN/PSI se asigna a la siguiente ruta de acceso física: % COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI. Encontrará que este directorio contiene un archivo web.config que especifica en una sección <http­Handlers> que todas las solicitudes HTTP a los archivos de *.asmx (es decir, servicios Web basados en ASP.NET) se deben pasar a un controlador HTTP personalizado, crear una instancia mediante Micro­soft.Office.Project.Server.PSIForwarder­HandlerFactory.

Este controlador HTTP personalizado es el reenviador de PSI. El reenviador PSI establece una nueva conexión HTTP a los servicios Web de PSI reales, se reenvía el cliente HTTP y, a continuación, devuelve los resultados al cliente.

Los servicios Web de PSI están disponibles para el reenviador PSI a través de HTTP mediante el directorio virtual de PSI de la aplicación Web de los servicios compartidos, que se aloja en el sitio de servicios Web del servidor de Office. Este directorio virtual se asigna de forma predeterminada a %\Microsoft PROGRAMFILES % Servers\12.0\WebServices\Shared\PSI de Office de la ruta de acceso física y esto es donde puede encontrar los archivos de *.asmx MOPS 2007.

Se explicará más sobre posteriormente el sitio de servicios Web de Office Server; por ahora, el hecho de más importante para aprovechar fuera de La figura 2 es que el reenviador PSI se comunica con los servicios Web de PSI de mediante la identidad de cuenta de grupo de aplicación de Web el sitio de PWA en lugar del usuario que actualmente tienen acceso al sitio de PWA.

Las implementaciones de servidor del conjunto de servidores

El reenviador PSI también desempeña un papel importante en las implementaciones de conjuntos de servidores Utilice independientes los servidores de solicitudes de cliente Web y los servidores de aplicaciones para aumentar la disponibilidad y escalabilidad del sistema. Un servidor front-end de MOPS es un servidor de WSS 3.0 que no los servicios PSI Web u otros servicios MOPS (such as servicio de cola y servicio de eventos) pero proporciona clientes con acceso a sitios de PWA, que incluyen el PSI Forwarder, como se ilustra en Figure 3 de host.

fig03.gif

La figura 3 servidores de un tamaño mediano MOPS 2007 (haga clic en la imagen de una vista más grande)

Un servidor de aplicaciones, por otro lado, es un servidor de WSS 3.0 que tiene el conjunto completo de componentes de MOPS y servicios instalados. Los servidores de aplicaciones pueden sitios de PWA de host, pero más a menudo que no sólo ofrecen servicios de back-end a los servidores de solicitudes de cliente y no ejecutar el servicio de aplicación Web de WSS. Elige la función de servidor durante la instalación MOPS.

La figura 3 muestra la configuración de un conjunto de servidores medianas. Puede agregar servidores adicionales para aumentar la escalabilidad, así como servidores de aplicaciones adicionales para una alta disponibilidad, según los requisitos de su organización. No es necesario configurar un clúster de equilibrio de carga para servidores de aplicaciones MOPS porque el reenviador PSI automáticamente equilibra la carga las solicitudes PSI si existen varios servidores de aplicaciones MOPS en el conjunto de servidores. Para información detallada acerca de las opciones de implementación MOPS, consulte la " Guía de implementación de Office Project Server 2007."

Bienvenido a IIS 7

Suficiente teoría! Vamos a tratar algunos problemas reales que pueden surgir durante la implementación de MOPS 2007. Uno de los problemas Favoritos está relacionada con colecciones de sitios de nombre de host para los sitios de PWA. En este escenario, correctamente implementar MOPS, configure el SSP, aprovisionamiento de un sitio de PWA en modo de encabezado de host especificando la URL completa de PWA (por ejemplo, pwa) después de seleccionar la ruta de utilizar Project Web Access como casilla de verificación de encabezado de host en la página Crear sitio de Project Web Access. A continuación, después de que todos los recursos se aprovisionado correctamente, se intenta abrir el sitio, pero, en lugar de PWA, llegar a la pantalla de IIS 7 bienvenida estándar.

Esto es lo que ocurre si el sitio Web predeterminado no es extendido de SharePoint y no hay ningún otro sitio Web con un enlace de sitios apropiado para la dirección URL de PWA. Sin un enlace explícita de sitio, IIS asocia la solicitud de pwa con la no extendidas sitio Web predeterminado, por lo que ver la pantalla de bienvenida. Que es posible que esperaba Administración central de SharePoint 3.0 para agregar el enlace necesario a la aplicación Web de SharePoint que se ha activado al sitio host el PWA, pero esto no sucede.

Para solucionar este problema, debe ampliar el sitio Web predeterminado de SharePoint y, a continuación, utilizar esta colección de sitios para sitios de PWA de aprovisionamiento, tal y como se describe en la hoja de cálculo complementario solución de problemas de IIS y PWA. Como alternativa, puede agregar el enlace de sitio que falta manualmente en el Administrador de IIS a la aplicación Web seleccionada para PWA. No olvide realizar este paso en todos los servidores WSS ese sitio host el PWA.

Los permisos de base de datos de sesión

Si decide ampliar el sitio Web predeterminado, asegúrese de utilizar una cuenta de dominio para el grupo de aplicaciones, consulte " Planear cuentas administrativas y servicio Office SharePoint Server", de lo contrario, se encontrará los problemas relacionados con el permiso después de aprovisionamiento de sitios de PWA, que suele manifestarse en un normalmente uninformative mensaje de error de SharePoint, tales como la muestra en La figura 4 .

fig04.gif

La figura 4 Error de acceso a la base de datos de SSP (haga clic en la imagen de una vista más grande)

Para buscar información más significativa, debe comprobar los registros de seguimiento, ubicados en el directorio de %\­Microsoft Shared\Web Server Exten­sions­\12\LOGS COMMONPROGRAMFILES %. Esto puede ser una tarea tediosa si el conjunto de servidores incluye múltiples servidores front-end de Web de equilibrio de carga.

Para solucionar problemas, es conveniente cambiar el registro DNS para el nombre de host de PWA y señale temporalmente a un único servidor front-end. De este modo sabrá qué servidor controla el cliente solicita por lo que sólo necesita comprobar archivos de registro de seguimiento que un único servidor.

Abrir el el archivo de registro más reciente en el bloc de notas y busque la entrada "no se puede abrir base de datos." Si lo encuentra, sabrá que está tratando con un problema de permisos de base de datos. Por ejemplo, el registro de seguimiento en la figura 4 muestra que la cuenta LITWARE\WSS02 $ no tiene acceso a la base de datos SharedServices1_DB. Esto es un indicador claro que el sitio de PWA se ejecuta con una identidad de servicio de red.

$ LITWARE\WSS02 es la cuenta de equipo del servidor Web front-end y SharedServices1_DB es la base de datos del proveedor de servicios compartidos. Entre otras cosas, los servidores front-end Web usar esta base de datos para mantener datos de estado de sesión de ASP.NET en la tabla ASPStateTempSessions pero, $ LITWARE\WSS02 no tiene acceso a esta base de datos.

Es importante tener en cuenta que debe asegurarse de que incluye base de datos del proveedor de servicios compartidos en sus actividades de mantenimiento de base de datos semanal para garantizar el rendimiento del sistema estable. Por ejemplo, debe quitar sesión caducada datos de estado de la tabla ASPStateTempSessions mediante el SQL comando TRUNCATE TABLE ASPStateTempSessions, tal como se documenta en" Implementar Project Server 2007 en un entorno de conjunto de servidores."

Problemas de configuración de relacionadas con el servicio de red pueden resultar confusos, modo voy a eche un vistazo más próximo a ellos. Cuentas de dominio (tales como LITWARE\SspConfig­Admin) funcionan para grupos de aplicaciones en conjuntos de servidores porque son exactamente los mismos en todos los equipos. En cambio, la cuenta de servicio de red (SERVICE de AUTHORITY\­NETWORK de NT) es diferente en cada equipo individual. En un servidor front-end que se denomina wss02.litware.com, la cuenta de NT AUTHORITY\NETWORK SERVICE se traduce en LITWARE\WSS02 $. Pero hace en un servidor con el sql01.litware.com nombre, la cuenta de NT AUTHORITY\­NETWORK SERVICE referencia a $ LITWARE\SQL01 en su lugar. No existe, se encuentra el problema.

Si examina los permisos de SQL Server para SharedServices1_DB en SQL Server Management Studio, puede ver que la cuenta de NT AUTHORITY\NETWORK SERVICE tiene permisos de db_owner en un intento de conceder a los grupos de aplicaciones que utilizan el acceso de cuenta de servicio de red a la base de datos de proveedor de servicios compartidos. Pero recuerde que esto sólo funciona en una instalación de servidor único.

Puede solucionar las asignaciones de permisos al conceder explícitamente LITWARE\WSS02 $ y todos los demás WSS servidor cuentas (quizás LITWARE\WSS01 $ y so forth) db_owner permisos para SharedServices1_DB, pero es mejor utilizar cuentas de dominio para los grupos de aplicaciones en su lugar para que todos los servidores front-end usar la misma identidad que SharePoint ha concedido los permisos de base de datos necesarios.

Permisos de servicios compartidos

Si grupo de aplicaciones el sitio de PWA utiliza la cuenta de servicio de red por algún motivo, también se producirán problemas de permisos SSP-related. ¿Recuerde que he mencionado que el reenviador PSI tiene acceso a los servicios de Web de PSI en nombre de usuario en el contexto de la cuenta de grupo de aplicación sitios PWA? Si esta cuenta no tiene permisos tener acceso al sitio de servicios Office Server Web, es en cuadrado uno con el habitual mensaje de error de SharePoint. Esta vez, el seguimiento de la sesión los estados del servidor front-end " Error de la solicitud con el estado HTTP 401: Unauthorized, " como se muestra en la figura 5 .

fig05.gif

La figura 5 Error de la solicitud con el estado HTTP 401: (Click the image for a larger view) no autorizado

Tenga en cuenta que este error no hace referencia a permisos de usuario en PWA. Permisos de SharePoint otorgar en un sitio de PWA determinan qué usuarios pueden tener acceso a subdirectorio virtuales _VTI_BIN/PSI de ese sitio, pero estos usuarios no reciben permisos de acceso a la aplicación Shared Services Web o los servicios PSI Web en el servidor de la aplicación.

Incluso si es un administrador de colección del sitio de PWA, MOPS todavía produce cuando cuenta del grupo de aplicación el sitio de PWA no tiene acceso a los servicios Web de PSI. Esto es especialmente el caso si pasa por alto la recomendación para utilizar cuentas de dominio para grupos de aplicaciones en un conjunto de servidores y usar la cuenta de servicio de red en su lugar.

Para comprobar permisos de acceso SSP en el servidor de la aplicación, desproteger el archivo web.config en el directorio raíz del sitio de servicios Web de Office Server (de forma predeterminada, %PROGRAMFILES%\­Microsoft Servers\12.0\Web­Services\Root de Office). Puede que observe la entrada de NT AUTHORITY\NETWORK SERVICE en la sección <authorization>, que se supone para autorizar a los grupos de aplicaciones que utilizan la cuenta de servicio de red. Pero de nuevo, no realizar la tarea ya que la entrada sólo hace referencia en el equipo local, que no es el servidor front-end.

La mejor estrategia es cambiar la configuración de grupo de la aplicación y utilizar una cuenta de dominio. Pero si insisten en sesión con la cuenta de servicio de red, debe autorizar explícitamente las cuentas de servidor front-end.

No editar el archivo de web.config en el servidor de la aplicación directamente, SharePoint sobrescribirá los cambios. En su lugar, utilice Administración central de SharePoint 3.0 para conceder los permisos que falta, tal y como se describe en la hoja de cálculo "pruebas compartidos servicio proveedor de acceso A permisos". Además, compruebe la configuración mediante una simple aplicación ASP.NET que establece una conexión directa de HTTP a los servicios Web de PSI, tales como SSPCheck (que se incluye en el material complementario). Asegúrese de que ejecuta la aplicación de prueba ASP.NET en el grupo de aplicaciones el sitio de PWA obtener resultados confiables.

Firewall de Windows

En este momento, son buenos que se puede abrir PWA posibilidades, a menos que, por supuesto, está intentando tener acceso a PWA a través de un servidor front-end Web y el Firewall de Windows en el servidor de la aplicación MOPS bloquea los puertos TCP 56737 y 56738. Estos son los puertos predeterminados asignados al sitio Web de Office Server servicios para la comunicación HTTP y HTTPS.

SharePoint no abre estos puertos automáticamente en el servidor de la aplicación de MOPS al crear el sitio de servicios Web de Office Server. Si tienes habilitado en el servidor de aplicación de Firewall de Windows, debe crear manualmente una regla de firewall para permitir el tráfico a estos puertos para que los servidores de solicitudes de cliente pueden tener acceso a los servicios Web de PSI. Si un firewall bloquea estos puertos, recibe el mensaje de error mostrado en Figure 6 y el registro de seguimiento en los estados del servidor front-end "host conectado error al responder."

fig06.gif

Figura 6 Project Web Access no puede conectarse a Project Server (haga clic en la imagen de una vista más grande)

MOPS servicios y cuentas de servicio

Tener resolver los problemas de comunicación cliente/servidor, debe poder tener acceso a Project Web Access. ¡ Enhorabuena! Ahora es el tiempo para centrarse en un problema específico de MOPS más difícil. Respire profundo y, a continuación, abra el registro eventos de aplicación en el servidor de aplicación MOPS y no ser shocked si ve miles y de miles de mensajes de error que indica que la "no pudo iniciar el sistema, de cola" tal como se muestra en la figura 7 . También puede que observe que servicios MOPS ocasionar una utilización de CPU casi 100 %.

fig07.gif

La figura 7 no pudo iniciar el sistema de la cola (haga clic en la imagen de una vista más grande)

El sistema de cola la red troncal de la infraestructura de aplicación de MOPS de inserción de base de datos MOPS y actualizar el control de solicitud, ejecutar trabajos de limpieza y el mantenimiento y la base de para actualizar el informe datos para su uso en datos de las tareas de análisis. Esto se explica en gran detalle en el artículo" Microsoft Office Project Server 2007 Queue Server System." Función para este artículo, el sistema de cola se basa en un servicio de Windows, implementada en el ensamblado Microsoft.Office.Project.Server.Queuing.exe y está ejecutando bajo la identidad de la SharePoint configuración del temporizador de administración y servicio de cuenta para tener acceso a base de datos configuración el conjunto.

En el inicio, el servicio de Windows recupera la lista de todos los SSP de la base de datos de configuración, incluidas las cuentas de administrador SSP correspondientes y sus contraseñas cifradas y, a continuación, inicia un proceso de Microsoft.Office.Project.Server.Queuing.exe adicional para cada SSP asociado con sitios de PWA en el contexto de la correspondiente cuenta de administrador SSP. En otras palabras, Microsoft.Office.Project.Server.Queuing.exe inicia varias instancias de sí mismo en cuentas diferentes, por lo que el número total de procesos de Microsoft.Office.Project.Server.Queuing.exe ejecutando en un servidor de aplicación MOPS es igual al número de proveedores de servicios compartidos (SSP) más uno.

Las instancias de proceso adicional son los procesos de trabajo de la cola. Cada proceso de trabajo de cola individuales determina su propio conjunto de sitios de PWA de su asociado del SSP, inicia subprocesos de sondeo independiente para cada uno de los sitios de PWA y comienza a procesar que los trabajos en cola para las bases de datos correspondientes de sitio de PWA. Cómo funciona el sistema de cola, y puede comprobar esto en el Administrador de tareas de Windows.

En un servidor de aplicación MOPS de un conjunto con una SSP asociado con sitios de PWA, puede ver dos procesos Microsoft.Office.Project.Server.Queuing.exe: una ejecución como la cuenta de administración de configuración y la otra ejecución como cuenta de administrador SSP. En el entorno de pruebas, estas cuentas son WssConfigAdmin y SspConfig­Admin, tal como se muestra en la figura 8 .

fig08.gif

Figura 8 comunicación Inter-process falla porque se ha denegado el acceso (haga clic en la imagen de una vista más grande)

Por lo que ¿por qué no el cola sistema iniciar? La entrada de error en el registro de eventos de la aplicación no proporciona información suficiente, pero se puede obtener más información si se establece temporalmente el evento crítico mínimo en el informe para el registro de seguimiento de todas las categorías en verbose en Administración central de SharePoint 3.0 en la ficha operaciones en el registro de diagnóstico.

La figura 8 muestra un registro de seguimiento resultante, y si echa un vistazo más de cerca, puede ver que el ProjectQueueService (el servicio Windows general) inicia una QueueExecService (un proceso de trabajo de cola), pero el proceso de QueueExecService un error porque se ha denegado el acceso. Como QueueExecService falla, ProjectQueueService intenta reiniciarlo, pero se produce un nuevo error por la misma muy razón y, por lo que continúa consume ciclos de CPU y rellenar el evento y registros con miles de errores de seguimiento. Se trata de un bucle infinito.

Por desgracia, incluso el registro de seguimiento más detallado no indica que la causa específica de tener acceso A error denegada. Pero no desespere: a través del proceso de eliminación puede tener rápidamente acceso a la causa raíz.

Si cambia la cuenta de administrador SSP en Administración central de SharePoint 3.0 y especifique la cuenta de administración de configuración (WssConfigAdmin), se inicia el sistema de cola. También funciona alrededor de la otra forma; si simplemente deja la cuenta de administrador SSP sin cambios (SspConfigAdmin) y utilizarlo como la cuenta de servicio para el servicio de Windows, la cola de sistema se inicia así.

A continuación, sigue que tanto la cuenta de administración de configuración y la cuenta de administrador SSP tienen todos los permisos necesarios; es simplemente que el sistema de cola no iniciar si Project­QueueService y QueueExecService utilizan cuentas diferentes.

Esto es un indicador claro de un problema de permisos entre procesos separados que desean interactuar entre sí en el equipo local. Después de todo, deben supervisar los procesos de ProjectQueueService y QueueExecService entre sí para garantizar un comportamiento de servicio coherente (observe el seguimiento de las entradas Process­Watcher registrar en la figura 8 ). Por ejemplo, cuando apaga el servicio de Windows ProjectQueueService, los procesos de trabajo QueueExecService deben apagar así.

Es el intento de obtener acceso a un proceso que se ejecuta en un contexto de seguridad diferentes que da como resultado el error. Obtener acceso a un proceso en otro contexto de seguridad requiere privilegios elevados. Aunque las cuentas de servicio es posible que tengan estos privilegios, Windows Server 2008 aún deniega el acceso porque control de cuentas de usuario (UAC) está habilitado de forma predeterminada, lo que hace que procesos para ejecutarse con privilegios estándar.

Tan pronto como deshabilitar UAC, procesos ProjectQueueService y QueueExecService pueden ejecutar con privilegios elevados y inicia el sistema de cola. La elección es suya entre utilizando la cuenta de administración de configuración como la cuenta de administrador para todos los SSP, por lo tanto todos los procesos de cola en ejecución con la misma cuenta o weakening seguridad en los servidores de aplicaciones MOPS al deshabilitar UAC.

Recursos de SharePoint

SharePoint sitio de productos y tecnologías Web
Microsoft.com/SharePoint

Windows SharePoint Services TechCenter
technet.microsoft.com/windowsserver/SharePoint

Centro de desarrollo de Windows SharePoint Services
msdn.microsoft.com/SharePoint

Referencia general de Microsoft Office Project 2007
msdn.microsoft.com/library/bb258902

Blog del equipo de tecnologías de Microsoft SharePoint Products and
blogs.msdn.com/SharePoint

Planear cuentas administrativas y servicio Office SharePoint Server
technet.microsoft.com/library/cc263445

Integración de servicios de análisis

Vamos a concluir esta columna con un problema de SQL Server 2005 Analysis Services que es probable que encontrar si sigue las instrucciones indicadas en" Requisitos para el uso de SQL Server 2005 Analysis Services con el servicio de generación de cubos de Project Server 2007con " (fecha 2007-04-05 en el momento de redactar este artículo). Si siguen la ruta a crear el repositorio de Analysis Services creando una base de datos de SQL Server 2005 como documentado, se acabará con el error aparece en la figura 9 cuando intenta crear el cubo en PWA.

fig09.gif

Figura 9 creación de cubos error debido a una configuración incorrecta de Analysis Services (haga clic en la imagen de una vista más grande)

El punto importante es que MOPS 2007 está diseñada para SQL Server 2000 Analysis Services. SQL Server 2005 Analysis Services requiere algunos pasos de configuración adicionales para la compatibilidad con versiones anteriores. La versión de SQL Server 2000 almacena información de depósito de la generación de cubo de una base de datos de Microsoft Jet y, aunque es posible migrar una base de datos Jet para trabajar con SQL Server 2005, no es necesario en una nueva implementación MOPS.

El artículo de TechNet en la que sólo conoce explica cómo configurar SQL Server 2005 para emular la funcionalidad de la base de datos de Jet independientemente de si está o no la base de datos Jet realmente presente. Aún, el artículo no mencionar que MOPS aún comprueba el repositorio de información de bloqueo en el recurso compartido de archivos .DSO en el servidor de base de datos independientemente de si en que Analysis Services está configurado para utilizar una base de datos Jet (el método anterior) o una base de datos de SQL Server 2005 preconfigurado (que es el método preferido).

A menos que este recurso compartido de archivo existe y la cuenta de administrador SSP se asigna acceso de control total a este recurso compartido de archivo, la generación de cubos se produce el error de permisos aparece en la figura 9 . Para SQL Server 2005 Analysis Services para funcionar correctamente con el servicio de creación de cubos MOPS, siga los pasos descritos en la hoja de configuración de cubos complementario.

Conclusión

No es fácil implementar 2007 MOPS. La arquitectura es compleja, y una implementación correcta implica varios pasos, desde un diseño adecuado de configuraciones de servidor del conjunto de servidores, instalar los archivos binarios y ejecutar el Asistente para configuración de las tecnologías de productos de SharePoint y en servidores de aplicaciones y servidores de solicitudes de cliente Web, a través de grupos de aplicaciones, servicios compartidos, sitios de administración de SSP y sitios de PWA en Administración central de SharePoint 3.0, de aprovisionamiento, por último, configuración de Analysis Services en SQL Server Management Studio.

Contribuir a los desafíos de implementación se interfiera las características de seguridad de Windows Server 2008, como Firewall de Windows y UAC, los puntos débiles en las herramientas de administración de SharePoint y omisiones en la documentación de implementación MOPS. No se puede confiar en Administración central de SharePoint 3.0 para advertirle de que si los grupos de aplicaciones utilizar la cuenta de servicio de red en un conjunto de servidores, aplicar todos los cambios de configuración necesarias automáticamente (como los enlaces de sitio IIS y las reglas de firewall de Windows) o comprobar el estado operativo de sitios de PWA configurados.

Además, no espere que todo para trabajar fuera del cuadro. Asegúrese de que se comprenden completamente la MOPS arquitectura y las dependencias, no desviarse de recomendaciones de producto y validar minuciosamente la configuración de MOPS y funcionalidad mediante la creación de probar los planes de proyecto y recursos para garantizar el éxito de la implementación.

A pesar de estos retos, MOPS también hereda las ventajas de SharePoint como plataforma empresarial. Al basarse en las tecnologías de servicios Web de SharePoint y, MOPS elimina la necesidad para conectividad de base de datos directamente en las estaciones de trabajo cliente. En el sistema de cola, MOPS aumenta sustainability durante las horas pico (por alguna razón unexplainable, todos los administradores de programas desea actualizar sus planes de proyecto el lunes por la mañana), y mediante tecnologías de MOSS adicionales, es posible integrar MOPS con más aplicaciones de línea de negocio.

Tener desarrollado soluciones empresariales de Project Server 2003 en el pasado, encuentre el minuscule de los desafíos de implementación MOPS 2007 en comparación con los últimos problemas de escalabilidad, los problemas de conectividad ODBC antiguos sobre conexiones de red lenta, y las dificultades de creación de consultas de base de datos que implica tantos JOIN las instrucciones que había que usar Excel para realizar un seguimiento de todas las consultas sub. MOPS 2007 es un hito importante en la evolución EPM y merece la pena el esfuerzo de implementación.

Pav Cherny es un experto en TI y el autor especializado en tecnologías de Microsoft para la colaboración y comunicación unificada. Sus publicaciones incluyen notas del producto, manuales de producto y libros con un foco sobre las operaciones y administración del sistema. Pav es presidente de Biblioso Corporation, una empresa que está especializada en servicios administrados de documentación y localización.