Sugerir traducción
 
Otros han sugerido:

progress indicator
No hay más sugerencias.
TechNet Magazine > Inicio > Todos los números > 2008 > Diciembre >  SharePoint de dentro: administración de proyect...
Ver contenido: en paraleloVer contenido: en paralelo
La información aquí ofrecida es contenido traducido automáticamente que los miembros de la comunidad pueden editar. Quienes deseen contribuir a mejorar la traducción, pueden hacer clic en el vínculo “editar” asociado a cualquiera de los siguientes enunciados.
Inside SharePoint Enterprise Project Management with SharePoint
Pav Cherny

Which SharePoint technologies are right for you? In your effort to find the answer, you've probably sifted through a seemingly endless list of categories, including Collaboration and Social Computing, Portals, Enterprise Search, Enterprise Content Management, Business Processes and Forms, Business Intelligence, and Developer Platform Capabilities, and compared the features available in Windows SharePoint Services (WSS) 3.0, Microsoft Office Search Server 2008 Express, Microsoft Office Forms Server 2007, and Microsoft Office SharePoint Server (MOSS) 2007. However, there's one technology you may never have considered because Microsoft does not list it under SharePoint Products and Technologies—Enterprise Project Management (EPM), which is enabled through Microsoft Office Project Server (MOPS) 2007.
But MOPS 2007 is SharePoint technology; it builds on and extends WSS 3.0 in a way that is comparable to MOSS 2007. MOPS 2007 is the right choice if you want to increase the efficiency of team collaboration within and across departments through work, resource, and budget management beyond the lightweight task-management capabilities included in WSS 3.0 and MOSS 2007. With MOPS, you can turn team sites into project workspaces, manage team collaboration within and across departments, and establish a solid EPM foundation for an entire organization. First, however, you need to master the deployment challenges.
In this column, I discuss the deployment of MOPS 2007 in a Windows Server 2008 environment with SQL Server 2005 SP2 and WSS 3.0 SP1. First, I briefly review the MOPS architecture to show how the components integrate with WSS 3.0 from a system architect's point of view. This information makes it easier to follow the subsequent discussion of typical deployment and integration challenges you might encounter, such as application pool configuration issues, missing access permissions, Queue system startup errors, and issues related to SQL Server 2005 Analysis Services.
To illustrate the deployment and troubleshooting steps, I use a basic test environment with two WSS 3.0 servers in a server farm, a dedicated domain controller, and a separate computer running SQL Server, similar to the test environment I've been using so far for this SharePoint column. You can find corresponding worksheets with step-by-step instructions in the companion material for this column, located on the TechNet Magazine Web site.

Project Server Architecture
MOPS 2007 is one of the most advanced and complex SharePoint applications. It takes full advantage of the WSS 3.0 platform for centralized administration, site provisioning, authentication, and security. Also, it adds further components, such as 25 general and specialized MOPS Web Parts and a new collection of up to four MOPS databases per Project Web Access (PWA) site. Each is accessed through a set of 21 public and internal MOPS Web services that jointly form the Project Server Interface (PSI), as illustrated in Figure 1. You can find more details about MOPS Web services on MSDN .
Figure 1 SharePoint integration with MOPS 2007 (Click the image for a larger view)
The MOPS 2007 architecture relies on a variety of components distributed across client workstations, application servers, and database servers. I discuss the most important of these components in this column, but if you are interested in all the technical details, read the " Project Server Architecture " documentation in the Project 2007 SDK.
Just keep in mind when reading the SDK that PWA Web Parts and Microsoft Office Project Professional 2007 do not access the PSI Web services directly. The SDK suggests that clients make direct calls to the PSI, but most applications actually use the PSI Forwarder, which is a component in PWA sites that provides indirect access to the PSI Web services. Only server-based components, such as the Queue service and the Events service, that run with system-level permissions make direct PSI calls. This little detail is important for you to remember in troubleshooting situations for several reasons, specifically:
  • PWA sites define database context (every single PWA site has separate Draft, Published, Archive, and Reporting databases) and user permissions, but regular user accounts are not granted access to the PSI Web services.
  • The PSI Forwarder does not support impersonation and uses the PWA site's application pool account to access the PSI Web services on behalf of the users.
  • PSI calls do not necessarily use local PSI Web services if the farm includes multiple application-server instances.

SharePoint Integration
Now let's take a closer look at the actual MOPS integration with SharePoint. From a SharePoint admin's perspective, MOPS is a shared Web app managed as a farm service in SharePoint 3.0 Central Administration. This is relatively straightforward for administrators familiar with Shared Service Providers (SSPs) in MOSS 2007.
But if you are a WSS 3.0 administrator and new to SSP administration, you'll want to check out the "Deploying Project Server 2007" worksheet, available in the companion material, for step-by-step instructions to create and configure a SharePoint farm's shared services and PWA sites. Following the MOPS installation and configuration, you can analyze the system implementation in IIS Manager. As illustrated in Figure 2, you should see separate Web sites for shared services, SSP administration, and site collections on a MOPS application server.
Figure 2 Project Server 2007 access through PWA and PSI Forwarder (Click the image for a larger view)
Clients access the PSI Web services through the _vti_bin/PSI virtual directory in a PWA site. However, the PSI Web services don't reside in this virtual directory. The _vti_bin/PSI virtual directory maps to the following physical path: %COMMONPROGRAMFILES %\Microsoft Shared\Web Server Extensions\12\ISAPI\PSI. You will find that this directory contains a web.config file that specifies in an <http­Handlers> section that all HTTP requests to *.asmx files (that is, ASP.NET-based Web services) should be passed to a custom HTTP handler, instantiated through Micro­soft.Office.Project.Server.PSIForwarder­HandlerFactory.
This custom HTTP handler is the PSI Forwarder. The PSI Forwarder establishes a new HTTP connection to the actual PSI Web services, forwards the client's HTTP request, and then returns the results to the client.
The PSI Web services are available to the PSI Forwarder via HTTP through the PSI virtual directory of the Shared Services Web application, which is hosted in the Office Server Web services site. This virtual directory maps by default to the physical path %PROGRAMFILES %\Microsoft Office Servers\12.0\WebServices\Shared\PSI, and this is where you can find the MOPS 2007 *.asmx files.
I will explain more about the Office Server Web services site later; for now, the most important fact to take away from Figure 2 is that the PSI Forwarder communicates with the PSI Web services by using the identity of the PWA site's Web application pool account instead of the user currently accessing the PWA site.

Server Farm Deployments
The PSI Forwarder also plays an important role in server farm deployments that use separate Web front-end servers and application servers to increase system scalability and availability. A MOPS front-end server is a WSS 3.0 server that does not host the PSI Web services or other MOPS services (such as Queue service and Events service) but provides clients with access to PWA sites, which include the PSI Forwarder, as illustrated in Figure 3.
Figure 3 A medium-size MOPS 2007 server farm (Click the image for a larger view)
An application server, on the other hand, is a WSS 3.0 server that has the full set of MOPS components and services installed. Application servers can host PWA sites, but more often than not they only provide back-end services to front-end servers and do not run the WSS Web Application service. You choose the server role during the MOPS installation.
Figure 3 shows the configuration for a medium-size server farm. You can add additional front-end servers to increase scalability as well as additional application servers for high availability, depending on your organization's requirements. It is not necessary to configure a load-balancing cluster for MOPS application servers because the PSI Forwarder automatically load-balances PSI requests if multiple MOPS application servers exist in the server farm. For detailed information regarding the MOPS deployment options, see the " Deployment Guide for Office Project Server 2007 ."

Welcome to IIS 7
Enough theory! Let's tackle some real-world issues that you might encounter during the deployment of MOPS 2007. One of my favorite issues relates to host-named site collections for PWA sites. In this scenario, you successfully deploy MOPS, configure the SSP, provision a PWA site in host-header mode by entering the full PWA URL (for example, pwa) after selecting the Use Project Web Access path as host header checkbox on the Create Project Web Access Site page. Then, after all resources are provisioned successfully, you attempt to open the site, but, instead of PWA, you reach the standard IIS 7 Welcome screen.
This is what happens if the Default Web Site is not SharePoint-extended and there is no other Web site with an appropriate site binding for the PWA URL. Without an explicit site binding, IIS associates the pwa request with the non-extended Default Web Site, so you see the Welcome screen. You might have expected SharePoint 3.0 Central Administration to add the required binding to the SharePoint Web app that you selected to host the PWA site, but this does not happen.
To address this issue, you must SharePoint-extend the Default Web Site and then use this site collection to provision PWA sites, as outlined in the Troubleshooting IIS and PWA companion worksheet. Alternatively, you can add the missing site binding manually in IIS Manager to the Web application selected for PWA. Don't forget to perform this step on all WSS servers that host the PWA site.

Session Database Permissions
If you decide to extend the Default Web Site, make sure you use a domain account for the application pool—see " Plan for Administrative and Service Accounts (Office SharePoint Server) "—otherwise, you will encounter permission-related issues after provisioning PWA sites, which usually manifest themselves in a typically uninformative SharePoint error message, such as the one displayed in Figure 4 .
Figure 4 Error accessing the SSP database (Click the image for a larger view)
To find more meaningful information, you should check out the trace logs, located in the %COMMONPROGRAMFILES %\­Microsoft Shared\Web Server Exten­sions­\12\LOGS directory. This can be a tedious task if your farm includes multiple load-balanced Web front-end servers.
For troubleshooting purposes, it is good to change the DNS record for the PWA host name and point it temporarily to a single front-end server. That way you know which server handles the client requests so you only need to check that one server's trace log files.
Open the most recent log file in Notepad and search for the entry "Cannot open database." If you find it, you know that you are dealing with a database permissions issue. For example, the trace log in Figure 4 shows that the account LITWARE\WSS02$ does not have access to the database SharedServices1_DB. This is a clear indicator that the PWA site is running with a Network Service identity.
LITWARE\WSS02$ is the computer account of the Web front-end server and SharedServices1_DB is the Shared Services Provider database. Among other things, the Web front-end servers use this database in order to maintain ASP.NET Session State data in the ASPStateTempSessions table, but LITWARE\WSS02$ does not have access to this database.
It's important to note that you must make sure you include the Shared Services Provider database in your weekly database maintenance activities to ensure stable system performance. For example, you should remove expired session state data from the ASPStateTempSessions table by using the SQL command TRUNCATE TABLE ASPStateTempSessions, as documented in " Deploy Project Server 2007 to a Server Farm Environment ."
Network Service-related configuration issues can be confusing, so I am going to take a closer look at them. Domain accounts (such as LITWARE\SspConfig­Admin) work for application pools in server farms because they are exactly the same on all computers. In contrast, the Network Service account (NT AUTHORITY\­NETWORK SERVICE) is different on every single computer. On a front-end server that is named wss02.litware.com, the NT AUTHORITY\NETWORK SERVICE account translates into LITWARE\WSS02$. But on a server with the name sql01.litware.com, the NT AUTHORITY\­NETWORK SERVICE account refers to LITWARE\SQL01$ instead. There lies the problem.
If you examine the SQL Server permissions for SharedServices1_DB in SQL Server Management Studio, you can see that the NT AUTHORITY\NETWORK SERVICE account has db_owner permissions in an attempt to grant application pools that use the Network Service account access to the Shared Services Provider database. But remember that this works only in a single-server installation.
You can fix the permission assignments by explicitly granting LITWARE\WSS02$ and all other WSS server accounts (perhaps LITWARE\WSS01$ and so forth) db_owner permissions for SharedServices1_DB, but it is better to use domain accounts for application pools instead so that all front-end servers use the same identity that SharePoint has granted the required database permissions.

Shared Services Permissions
If your PWA site's application pool uses the Network Service account for any reason, you will also encounter SSP-related permissions issues. Remember I mentioned that the PSI Forwarder accesses the PSI Web services on behalf of the user in the context of the PWA sites application pool account? If this account doesn't have permissions to access the Office Server Web services site, you are back at square one with the usual SharePoint error message. This time, the trace log on the front-end server states "The request failed with HTTP status 401: Unauthorized," as displayed in Figure 5.
Figure 5 The request failed with HTTP status 401: Unauthorized (Click the image for a larger view)
Keep in mind that this error does not refer to user permissions in PWA. SharePoint permissions granted in a PWA site determine which users can access that site's _vti_bin/PSI virtual subdirectory, but these users do not receive access permissions to the Shared Services Web app or the PSI Web services on the application server.
Even if you are a PWA site collection administrator, MOPS still fails if the PWA site's application pool account has no access to the PSI Web services. This is particularly the case if you ignore the recommendation to use domain accounts for application pools in a server farm and use the Network Service account instead.
To verify SSP access permissions on the application server, check out the web.config file in the root directory of the Office Server Web services site (by default, %PROGRAMFILES%\­Microsoft Office Servers\12.0\Web­Services\Root). You might notice the NT AUTHORITY\NETWORK SERVICE entry in the <authorization> section, which is supposed to authorize app pools that use the Network Service account. But again, it doesn't accomplish the task because the entry only refers to the local computer, which is not the front-end server.
The best strategy is to change the application pool configuration and use a domain account. But if you insist on using the Network Service account, you must authorize the front-end server accounts explicitly.
Don't edit the web.config file on the application server directly—SharePoint will overwrite your changes. Instead, use SharePoint 3.0 Central Administration to grant the missing permissions, as outlined in the "Testing Shared Service Provider Access Permissions" worksheet. Also, verify the configuration by using a simple ASP.NET app that establishes a direct HTTP connection to the PSI Web services, such as SSPCheck (which is included in the companion material). Just make sure you run the ASP.NET test application under the PWA site's application pool to obtain reliable results.

Windows Firewall
At this point, chances are good that you can open PWA—unless, of course, you are attempting to access PWA through a Web front-end server and the Windows Firewall on the MOPS application server blocks TCP ports 56737 and 56738. These are the default ports assigned to the Office Server Web services site for HTTP and HTTPS communication.
SharePoint doesn't open these ports automatically on the MOPS application server when creating the Office Server Web services site. If you have Windows Firewall enabled on the application server, you must manually create a firewall rule in order to allow traffic to these ports so that front-end servers can access the PSI Web services. If a firewall blocks these ports, you receive the error message displayed in Figure 6 and the trace log on the front-end server states "connected host has failed to respond."
Figure 6 Project Web Access cannot connect to Project Server (Click the image for a larger view)

MOPS Services and Service Accounts
Having solved the front-end/back-end communication issues, you should be able to access Project Web Access. Congratulations! Now it's time to focus on a more difficult MOPS-specific issue. Take a deep breath and then open the application event log on your MOPS application server, and don't be shocked if you see thousands and thousands of error messages stating that the "Queue system could not start," as shown in Figure 7. You might also notice that MOPS services cause a nearly 100% CPU utilization.
Figure 7 The Queue system could not start (Click the image for a larger view)
The Queue system is the backbone of the MOPS application infrastructure for MOPS database insert and update request handling, running clean-up and maintenance jobs and for updating the Reporting database for use in data analysis tasks. This is explained in great detail in the article " Microsoft Office Project Server 2007 Queuing System ." According to this article, the Queue system relies on a Windows service, implemented in the assembly Microsoft.Office.Project.Server.Queuing.exe and running under the identity of the SharePoint configuration administration and timer service account to access the farm's configuration database.
On startup, the Windows service retrieves the list of all SSPs from the configuration database, including the corresponding SSP administrator accounts and their encrypted passwords, and then starts an additional Microsoft.Office.Project.Server.Queuing.exe process for each SSP associated with PWA sites in the context of the corresponding SSP administrator account. In other words, Microsoft.Office.Project.Server.Queuing.exe starts multiple instances of itself under different accounts, so the total number of Microsoft.Office.Project.Server.Queuing.exe processes running on a MOPS application server is equal to the number of SSPs plus one.
The additional process instances are the queue worker processes. Each individual queue worker process determines its own set of PWA sites from its associated SSP, starts separate polling threads for each of the PWA sites, and begins processing the jobs queued for the corresponding PWA site databases. That's how the Queue system works, and you can verify this in Windows Task Manager.
On a MOPS app server in a farm with one SSP associated with PWA sites, you can see two Microsoft.Office.Project.Server.Queuing.exe processes—one running as the configuration administration account and the other running as the SSP administrator account. In my test environment, these accounts are WssConfigAdmin and SspConfig­Admin, as shown in Figure 8.
Figure 8 Inter-process communication fails because access is denied (Click the image for a larger view)
So why doesn't the Queue system start? The error entry in the application event log doesn't provide sufficient information, but you can obtain more details if you temporarily set the Least Critical Event to Report to the Trace Log for all categories to Verbose in SharePoint 3.0 Central Administration on the Operations tab under Diagnostics Logging.
Figure 8 shows a resulting trace log, and if you take a closer look, you can see that the ProjectQueueService (the overall Window service) starts a QueueExecService (a queue worker process), but the QueueExecService process fails because access is denied. As QueueExecService fails, ProjectQueueService attempts to restart it, but it again fails for the very same reason, and so it continues consuming CPU cycles and filling the event and tracing logs with thousands of errors. It's an infinite loop.
Unfortunately, even the most detailed trace log does not reveal the specific cause of the Access is denied error. But don't despair—through the process of elimination you can quickly get to the root cause.
If you change the SSP administrator account in SharePoint 3.0 Central Administration and specify the configuration administration account (WssConfigAdmin), the Queue system starts. It also works the other way around; if you simply leave the SSP administrator account unchanged (SspConfigAdmin) and use it as the service account for the Windows service, the Queue system starts as well.
It follows then that both the configuration administration account and the SSP administrator account have all required permissions; it's just that the Queue system doesn't start if Project­QueueService and QueueExecService use different accounts.
This is a clear indicator of a permissions issue between separate processes that want to interact with each other on the local computer. After all, the ProjectQueueService and QueueExecService processes must monitor each other to ensure a consistent service behavior (notice the Process­Watcher entries in the trace log in Figure 8). For example, when you shut down the ProjectQueueService Windows service, any QueueExecService worker processes must shut down as well.
It is the attempt to access a process running in a different security context that results in the error. Accessing a process in another security context requires elevated privileges. Even though the service accounts might have these privileges, Windows Server 2008 still denies access because User Account Control (UAC) is enabled by default, which causes processes to run with standard privileges.
As soon as you disable UAC, ProjectQueueService and QueueExecService processes can run with elevated privileges and the Queue system starts. The choice is yours between using the configuration administration account as the administrator account for all SSPs, thus running all queue processes with the same account, or weakening security on your MOPS application servers by disabling UAC.
SharePoint Resources

SharePoint Products and Technologies Web Site
microsoft.com/sharepoint

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

Windows SharePoint Services Developer Center
msdn.microsoft.com/sharepoint

Microsoft Office Project 2007 General Reference
msdn.microsoft.com/library/bb258902

Microsoft SharePoint Products and Technologies Team Blog
blogs.msdn.com/sharepoint

Plan for Administrative and Service Accounts (Office SharePoint Server)
technet.microsoft.com/library/cc263445

Analysis Services Integration
Let's conclude this column with a SQL Server 2005 Analysis Services issue that you are likely to encounter if you follow the instructions outlined in " Requirements for using SQL Server 2005 Analysis Services with the Project Server 2007 Cube Building Service " (dated 2007-04-05 at the time of this writing). If you follow the path to create the Analysis Services repository by creating a SQL Server 2005 database as documented, you will end up with the error displayed in Figure 9 when trying to build the cube in PWA.
Figure 9 Cube building error due to incorrect Analysis Services configuration (Click the image for a larger view)
The important point is that MOPS 2007 is designed for SQL Server 2000 Analysis Services. SQL Server 2005 Analysis Services require additional configuration steps for backward compatibility. The SQL Server 2000 version stores repository information about the cube build in a Microsoft Jet database, and although it is possible to migrate a Jet database to work with SQL Server 2005, it is not necessary in a fresh MOPS deployment.
The TechNet article to which I just referred explains how to configure SQL Server 2005 to emulate the functionality of the Jet database regardless of whether or not the Jet database is actually present. Yet, the article fails to mention that MOPS still checks repository locking information in the .dso file share on the database server regardless of whether Analysis Services is configured to use a Jet database (the old method) or a preconfigured SQL Server 2005 database (which is the preferred method).
Unless this file share exists and the SSP administrator account is given Full Control access to this file share, the cube build fails with the permissions error displayed in Figure 9. For SQL Server 2005 Analysis Services to function correctly with the MOPS Cube Building Service, follow the steps outlined in the "Configuring Cubes" companion worksheet.

Conclusion
MOPS 2007 is not easy to deploy. The architecture is complex, and a successful deployment involves numerous steps, ranging from proper planning of server farm configurations, installing binary files and running the SharePoint Products and Technologies Configuration Wizard on application servers and Web front-end servers, through provisioning application pools, shared services, SSP administration sites, and PWA sites in SharePoint 3.0 Central Administration, to finally configuring Analysis Services in SQL Server Management Studio.
Contributing to the deployment challenges are interfering security features of Windows Server 2008, such as Windows Firewall and UAC, weaknesses in the SharePoint admin tools, and omissions in the MOPS deployment documentation. You cannot rely on SharePoint 3.0 Central Administration to warn you if your application pools use the Network Service account in a server farm, apply all required configuration changes automatically (such as IIS site bindings and Windows firewall rules), or check the operational state of provisioned PWA sites.
Also, don't expect everything to work out of the box. Make sure you fully understand the MOPS architecture and dependencies, do not deviate from product recommendations, and thoroughly validate the MOPS configuration and functionality by creating test project plans and resources to ensure deployment success.
Despite these challenges, MOPS also inherits the strengths of SharePoint as an enterprise platform. By relying on SharePoint and Web services technologies, MOPS eliminates the need for direct database connectivity on client workstations. Through the Queue system, MOPS increases sustainability during peak hours (for some unexplainable reason, all program managers want to update their project plans on Monday morning), and through additional MOSS technologies, it is possible to integrate MOPS with further line-of-business applications.
Having developed business solutions for Project Server 2003 in the past, I find the MOPS 2007 deployment challenges minuscule in comparison to the past scalability issues, the old ODBC connectivity issues over slow network connections, and the pain of building database queries that involved so many JOIN statements that I had to use Excel to keep track of all the sub queries. MOPS 2007 is a significant milestone in the EPM evolution, and it is worth the deployment effort.

Pav Cherny is an IT expert and author specializing in Microsoft technologies for collaboration and unified communication. His publications include white papers, product manuals, and books with a focus on IT operations and system administration. Pav is President of Biblioso Corporation, a company that specializes in managed documentation and localization services.

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

¿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 .
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.
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.
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 .
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 .
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."
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 %.
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 .
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 2007 con " (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.
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.

Page view tracker