Exportar (0) Imprimir
Expandir todo

Procedimientos recomendados de administración de un elevado número de recursos en Project Server 2010

 

Se aplica a: Project Server 2010

Última modificación del tema: 2011-12-08

Este artículo describe procedimientos recomendados para la administración de usuarios en entornos de Microsoft Project Server 2010 con proyectos en los que participan muchos usuarios.

En este artículo:

  • Introducción a los permisos de Project Server 2010

  • Permisos de Microsoft SharePoint Server 2010 para usuarios de Project Server 2010

  • Problemas de rendimiento que se producen cuando se supera el límite de usuarios recomendado de sitios de proyecto

  • Herencia de permisos del sitio primario de PWA

  • Deshabilitación de configuración de permisos de sitios del proyecto

  • Errores asociados a la superación de los límites de usuarios recomendados de sitios de proyecto

Project Server 2010 usa la infraestructura de permisos normal de SharePoint para establecer el control de acceso al sitio de Microsoft Project Web App (PWA). También usa la misma infraestructura para establecer el control de acceso a cualquier sitio del proyecto (anteriormente conocidos como sitios de área de trabajo de proyectos) creado para los planes de proyecto de Project Server.

En el nivel de sitio de PWA, los usuarios se agregan a grupos específicos de SharePoint en función de su nivel de permisos en Project Server. La página de configuración de sitio de PWA contiene grupos de SharePoint de "Microsoft Project Server" para Jefes de proyecto, Lectores, Integrantes de grupo, Administradores web y Administradores de flujo de trabajo y páginas de detalles del proyecto. Cuando se agregan los usuarios en Project Server 2010, también se agregan al grupo correspondiente del sitio de PWA al que tienen el acceso autorizado. Por ejemplo, supongamos que un usuario se agrega a Project Server 2010 y es miembro del grupo de seguridad Jefes de proyecto. Este usuario se agrega al Grupo Jefes de proyecto (Microsoft Project Server) en Permisos del sitio para la página de inicio de PWA, la página Centro de proyectos, Centro de aprobación y todas las páginas del sitio PWA a las que tiene el acceso autorizado.

La configuración Permisos del sitio del sitio de PWA no solo contiene los grupos de SharePoint de "Microsoft Project Server", sino que también incluye cuentas de usuario de SharePoint individuales de administradores de colecciones de sitios, además de otras cuentas de administradores de granjas. La tabla siguiente muestra los niveles de permisos de SharePoint para el grupo de SharePoint de Microsoft Project Server en el nivel de sitio de PWA.

 

Nombre Nivel de permisos

Grupo Jefes de proyecto (Microsoft Project Server)

Acceso limitado, Jefes de proyecto (Microsoft Project Server)

Grupo Lectores (Microsoft Project Server)

Acceso limitado, Lectores (Microsoft Project Server)

Grupo Integrantes del grupo (Microsoft Project Server)

Acceso limitado, Integrantes del grupo (Microsoft Project Server)

Grupo de administradores web (Microsoft Project Server)

Acceso limitado, Administradores web (Microsoft Project Server)

Grupo Administradores de flujo de trabajo y páginas de detalles del proyecto (Microsoft Project Server)

Acceso limitado

Para los sitios del proyecto, los usuarios se agregan directamente como individuos y no se agregan a grupos de SharePoint de "Microsoft Project Server" específicos. El nivel de permiso concedido al usuario depende de su rol.

El acceso de los usuarios de Project Server 2010 a los sitios de Project Server se otorga mediante los permisos de SharePoint Server 2010. Project Server 2010 está basado en Microsoft SharePoint Server 2010 y los sitios que están disponibles a través de Project Server 2010 son sitios de SharePoint.

Los dos tipos de sitios de Project Server 2010 para los que es necesario asignar permisos de SharePoint son los siguientes:

  • Sitios de PWA (Página de inicio de PWA, Centro de proyectos, Centro de recursos, etc.)

  • Sitios del proyecto (Sitios de colaboración para proyectos individuales. Estos sitios se conocen como sitios de área de trabajo de proyectos en Office Project Server 2007).

Para los sitios de PWA, los usuarios de Project Server 2010 se asignan a grupos de SharePoint de Microsoft Project Server en función de su nivel de permisos en in Project Server 2010:

 

Rol de seguridad de los usuarios Permisos de SharePoint en el sitio de PWA
  • Jefe de proyecto

  • Jefe de cartera de proyectos

  • Jefe de recursos

  • Ejecutivo

Grupo Jefes de proyecto (Microsoft Project Server)

Administrador

Grupo de administradores web (Microsoft Project Server)

Integrante del equipo

Responsable de equipo

Grupo Integrantes del grupo (Microsoft Project Server)

Para los sitios del proyecto, se proporciona a los usuarios de Project Server 2010 los siguientes permisos de SharePoint. Para los sitios del proyecto, los usuarios de Project Server 2010 se agregan como usuarios de SharePoint individuales con permisos de SharePoint específicos del sitio:

 

Usuario Permisos de SharePoint en el sitio del proyecto

Jefes de proyecto con un proyecto publicado

Jefes de proyecto (Microsoft Project Server)

Jefes de proyecto con permisos del tipo Guardar proyectos

Jefes de proyecto (Microsoft Project Server)

Integrantes del grupo con asignaciones en un proyecto

Integrantes del grupo (Microsoft Project Server)

Usuarios de Project Server con permiso de visualización de sitio de proyecto

Lectores (Microsoft Project Server)

En Office Project Server 2007, los problemas de rendimiento pueden producirse con la sincronización de usuarios en los sitios de PWA porque los usuarios se agregan a sitios de área de trabajo de proyecto y de PWA con niveles de permisos específicos. Cuando se realizan cambios en los permisos de usuario del sitio, se eliminan todos los usuarios que tienen permisos de acceso al sitio para, a continuación, volver a agregarlos. Cuando hay un gran número de usuarios en un sitio, este proceso puede tardar mucho tiempo. Por ello, los usuarios que se estén agregando al sitio observarán un error de Acceso denegado hasta que no se vuelvan a agregar al sitio.

En Project Server 2010, se han realizado dos cambios en el acceso de los usuarios a los sitios de PWA para corregir el problema existente en Office Project Server 2007:

  • Los usuarios que acceden a sitios de PWA se han agregado a grupos de usuarios de SharePoint en lugar de agregarse de forma individual.

  • Cuando se sincronizan los usuarios, estos se quitan del sitio individualmente para, a continuación, volver a agregarlos uno a uno (en lugar de quitar todos los usuarios para volver a agregarlos).

Estos cambios solo se han aplicado a los sitios de PWA a los que accede un elevado número de usuarios. Este cambio no se ha aplicado a los sitios del proyecto, ya que a este tipo de sitios no suelen acceder tantos usuarios (normalmente solo los recursos asignados al proyecto), por lo que estos sitios están menos sujetos a verse afectados por el problema de sincronización descrito. Este problema suele producirse cuando hay un elevado número de usuarios que accede a muchos de los sitios del proyecto o a la totalidad de los sitios. La razón de este elevado número de usuarios puede deberse a que se han agregado demasiados usuarios a un proyecto o a que se ha asignado el permiso de visualización de sitios del proyecto a un nivel de integrantes del grupo en una categoría que incluye numerosos proyectos o la totalidad de estos. En cualquier caso, cuando se produce esta situación, es posible que el número de usuarios supere los límites de software recomendados de SharePoint Server 2010. Los problemas de rendimiento se producen cuando se superan los límites recomendados. Cada usuario agregado de forma individual a un sitio se considera como ámbito de seguridad. El número máximo recomendado de ámbitos de seguridad por lista es de 1000 usuarios. Todas las listas y bibliotecas del sitio heredan estos límites de los permisos del sitio principal y, por tanto, cuando el número de usuarios que tiene acceso al sitio supera los 1000 usuarios es cuando se superan los límites establecidos. Para más información acerca de los límites de ámbito de seguridad para las listas, vea Administración de la capacidad de SharePoint Server 2010: restricciones y límites del software.

Cuando se superan los límites de ámbito de seguridad recomendados se producen problemas de rendimiento. Estos problemas tienen lugar cuando se efectúan cambios en la pertenencia a grupos debido a otros cambios de categoría o grupo, o debido a acciones como, por ejemplo, la adición o la desactivación de usuarios. Una de las razones por las que se impuso la limitación de usuarios individuales es porque, en caso de superarla, el proceso de eliminación de usuarios del sitio puede ralentizarse mucho. El proceso es especialmente lento si se elimina el mismo usuario de varios sitios en los que se haya superado el límite recomendado. En los casos en los que se desactiven varios usuarios, es posible que el servidor deje de responder o no pueda autenticar los usuarios. Esto da lugar a problemas cuando se superan los límites de usuarios individuales en un sitio. El servidor puede dejar de responder a la hora de administrar usuarios cuando demasiados usuarios tienen permiso para tener acceso a un sitio. Cuando se intenta corregir el problema mediante la eliminación de usuarios del sitio, el servidor puede dejar de responder.

El proceso recomendado para evitar este problema dependerá de cuál sea su objetivo:

  • Si necesita que la mayoría de los usuarios pueda tener acceso a la mayoría de los sitios del proyecto: en lugar de agregar usuarios individualmente a los sitios, use grupos de SharePoint Server 2010 y use la herencia de PWA para agregar los usuarios a estos grupos. Por ejemplo, el sitio principal de los sitios del proyecto suele ser el sitio de inicio de PWA. En este escenario, los sitios del proyecto heredarán los permisos del sitio de inicio de PWA, que tiene todos los usuarios de PWA en grupos de SharePoint de Microsoft Project Server.

  • Si el elevado número de usuarios con acceso a los sitios no es intencionado y necesita resolver el problema: quite el permiso de la categoría de visualización de sitios del proyecto de la categoría que otorga a los usuarios acceso a los sitios. También es posible reducir el número de recursos asignados al proyecto. Antes de llevar a cabo ninguna acción, deberá detener la sincronización de los usuarios en el sitio. De lo contrario, estas acciones pueden hacer que su servidor no responda.

Para deshabilitar la sincronización del sitio del proyecto, escriba una utilidad que use Project Server Interface (PSI), el servicio web de administración, y configure la Enumeración de UserSyncSetting (en inglés) como DisablePWS. Llame la enumeración con el Método Admin.UpdateUserSyncSetting (en inglés).

 

Nombre del miembro Descripción

Enable

Value=0 Habilitar todas las sincronizaciones.

DisablePWA

Value=1. Deshabilitar la sincronización con Project Web App.

DisablePWS

Value=2. Deshabilitar la sincronización con los sitios del proyecto del usuario.

DisableEmailSync

Value=3. Deshabilitar la sincronización del correo electrónico.

DisableAll

Value=4. Deshabilitar todas las sincronizaciones.

También puede deshabilitar el parámetro si modifica directamente la tabla MSP_WEB_ADMIN en la base de datos publicada, en la columna WADMIN_USER_SYNC_SETTING. Inicie la siguiente consulta SQL para deshabilitar la sincronización del sitio del proyecto:

Update [ProjectServer_Published].[dbo].[msp_web_admin] set [WADMIN_USER_SYNC_SETTING]=2

Probablemente, la opción de modificar directamente la tabla MSP_WEB_ADMIN en la base de datos publicada resulte mucho más simple que crear y probar una herramienta mediante PSI.

NotaNote
En la mayoría de las instancias, no se recomienda modificar directamente la base de datos publicada, ya que ello puede invalidar la compatibilidad. Sin embargo, el uso de la consulta anterior para deshabilitar sincronización de sitios del proyecto es una excepción permitida.

Una vez que se ha desactivado la sincronización del sitio, es posible que se experimenten los mismos problemas a la hora de intentar quitar usuarios directamente del sitio del proyecto mediante la característica de la página de permisos del sitio de SharePoint. Un modo de quitar usuarios rápidamente sin pasar por la eliminación manual que provoca el problema consiste en heredar los permisos del sitio principal. Esto puede llevarse a cabo a través de la cinta de opciones de la interfaz de usuario de la página Permisos del sitio del sitio del proyecto (en el menú Acciones del sitio).

Para heredar permisos del sitio principal del sitio del proyecto
  1. En el sitio del proyecto, haga clic en Acciones del sitio y seleccione Permisos del sitio.

  2. En la página Permisos, haga clic en la cinta de opciones Editar.

  3. Haga clic en Heredar permisos.

  4. En el cuadro de mensaje que le advierte que el cambio de los permisos heredados puede hacer que los usuarios no puedan tener acceso al sitio haga clic en Aceptar.

La cinta de opciones indicará que el sitio hereda los permisos de su sitio principal, que debe ser un sitio de PWA. El sitio del proyecto tomará ahora la estructura de permisos del sitio principal, lo que indica que ahora los usuarios de PWA individuales están contenidos en grupos de sitio de Microsoft Project Server.

Si su objetivo final es proporcionar a la mayoría de los usuarios acceso a la mayoría de los sitios, se recomienda que los sitios del proyecto hereden los permisos principales de PWA tal como se ha descrito. Antes de llevar a cabo esta acción, deberá asegurarse de que el sitio de PWA tiene los permisos adecuados para todos los usuarios que necesitan acceso. Esto es especialmente importante, ya que los permisos que tengan los usuarios en PWA serán los permisos que tendrán los usuarios en el sitio del proyecto tras usar el procedimiento para heredar los permisos.

Si tiene un elevado número de sitios de proyecto, puede usar Windows PowerShell para automatizar el proceso de cambio. Mediante el siguiente comando de Windows PowerShell, todos los sitios de proyecto secundarios que dependan del sitio de PWA principal heredarán los permisos del sitio principal. Inicie el comando de Windows PowerShell en la Consola de administración de SharePoint 2010:

$site = Get-SPSite "<url of PWA>"
     Foreach ($web in $site.AllWebs) {
        $web.Update()
        $web.ResetRoleInheritance()
        $web.Update()
        }
     $site.Dispose()

Con el fin de evitar que vuelva a producirse el problema, deberá iniciar este comando (o el procedimiento descrito para heredar los permisos del sitio) para todos los sitios de proyecto nuevos.

NotaNote
Si hace clic en la opción Sincronizar de la página del sitio en Configuración del servidor de PWA se interrumpirá el proceso de herencia de permisos. No haga clic en esta opción si desea que el sitio siga heredando los permisos de su sitio principal de PWA.

En un entorno en el que todos los sitios del proyecto hereden permisos de PWA, es posible que desee que determinados proyectos contengan información confidencial y quiera administrar los permisos y los usuarios de forma individual. Para estos casos, es posible usar Windows PowerShell para establecer una propiedad para estos sitios y usarla para filtrar por dicha propiedad con una versión modificada del comando de Windows PowerShell usado para definir la herencia de permisos (anterior).

También es posible evitar la adición automática de usuarios a los sitios del proyecto. Para ello, deberá deshabilitar la opción Permisos de sitio del proyecto situada en la sección Directivas operativas de la Configuración del servidor de Project Web App. Cuando se deshabilita esta opción, los usuarios de Project Web App se sincronizan automáticamente con los sitios del proyecto cuando se producen cambios de permisos en Project Server 2010, cuando el jefe de proyecto publica el proyecto o cuando se crea el sitio del proyecto. Si la opción se habilita y se produce alguna de las situaciones anteriores, se iniciarán las acciones siguientes de forma automática:

  • Los jefes de proyecto que han publicado un proyecto o que tienen permiso para guardar el proyecto en un proyecto se agregan al sitio con permisos de jefe de proyecto (Microsoft Project Server).

  • Los integrantes de grupo con asignaciones en un proyecto se agregan al sitio con permisos de Integrantes de grupo (Microsoft Project Server).

  • Otros usuarios de Project Server que tienen el permiso Ver sitio del proyecto en un proyecto se agregan al sitio con permisos de Lectores (Microsoft Project Server).

La desactivación de esta opción detiene la adición automática de usuarios de Project Server al sitio, aunque no eliminará los usuarios que ya se hayan agregado.

Para deshabilitar la opción Permisos de sitio del proyecto
  1. En la sección Directivas operativas de la página Configuración del servidor, haga clic en Configuración de aprovisionamiento de sitios de proyecto.

  2. En la página Configuración de aprovisionamiento de sitios de proyecto, en la sección Permisos de sitio del proyecto, desactive la casilla Active esta opción para sincronizar automáticamente a los usuarios de Project Web App con los sitios del proyecto cuando estos se creen, cuando los jefes de proyecto publiquen proyectos y cuando cambien los permisos de usuario en Project Server.

    Si se desactiva la casilla, los usuarios de Project Server no se sincronizarán nunca con los sitios del proyecto.

  3. Haga clic en Guardar.

Para más información acerca de la configuración de Permisos de sitio del proyecto, vea Configuración de aprovisionamiento de sitios de proyecto (configuración de Project Server 2010).

A continuación se describen errores que pueden aparecer en los registros de ULS cuando su implementación de Project Server tenga problemas de rendimiento porque se ha superado el número máximo recomendado de usuarios con acceso a los sitios del proyecto. El usuario que inicie el problema (quizás debido a la desactivación de un recurso), verá que el botón Guardar de la página Modificar usuario permanece bloqueado en la posición presionada y se muestra el mensaje "Error inesperado". Encontrará el Id. de correlación en los registros de ULS con datos relacionados con el bloqueo de SQL. La entrada de nivel “Crítica” será similar a la siguiente:

  • 08/10/2011 12:17:02.85 w3wp.exe (0x2178) 0x314C SharePoint Foundation Database 5586 Critical Unknown SQL Exception 1205 occurred. Additional error information from SQL Server is included below. Transaction (Process ID 80) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. 886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3

Un error de nivel "Alto" con información acerca de la consulta que genera el error tendrá un texto similar al que se muestra a continuación. La entrada se ha resumido de forma considerable, aunque incluye el texto de la clave “proc_SecRemoveUserFromSite”:

08/10/2011 12:17:06.97 w3wp.exe (0x2178) 0x314C SharePoint Foundation Database tzkv High SqlCommand: 'SET NOCOUNT ON; DECLARE @DN nvarchar(256),@LN nvarchar(128),@@DocUIVersion int,@@S uniqueidentifier,@@Level tinyint; DECLARE @ItemId int; DECLARE @@iRet int; DECLARE @ExtraItemSize int; SET @@Level = 1; SET @@S=@wssp0; EXEC @@iRet = proc_SecRemoveUserFromSite @@S, @wssp1, @wssp2 SELECT @ItemId = @wssp3 IF @@iRet <> 0 BEGIN GOTO DONE; END ;BEGIN TRAN IF NOT EXISTS( SELECT tp_ID FROM UserData WHERE tp_ListId = '06C8C9BB-B10B-4042-8859-9F9985E73E76' AND tp_ID = @ItemId AND tp_Level = 1 AND tp_RowOrdinal =0) BEGIN SELECT @ExtraItemSize = 0 EXEC @@iRet = proc_AddListItem @SiteId….

También es posible que se genere una entrada de nivel “Inesperado”:

08/10/2011 12:17:06.97 w3wp.exe (0x2178) 0x314C SharePoint Foundation Runtime tkau Unexpected System.Runtime.InteropServices.COMException: Exception from HRESULT: 0x80131904 at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail) at Microsoft.SharePoint.Library.SPRequest.UpdateMembers(String bstrUrl, UInt32 dwObjectType, String bstrObjId, Guid& pguidScopeId, Int32 lGroupID, Int32 lGroupOwnerId, Object& pvarArrayAdd, Object& pvarArrayAddIds, Object& pvarArrayLoginsRemove, Object& pvarArrayIdsRemove, Boolean bRemoveFromCurrentScopeOnly, Boolean bSendEmail) 886d9cdd-5c0c-4f3a-8f89-f4e8c92acde3

El servidor puede dejar de responder 15-30 minutos. Durante este período, el resto de usuarios obtendrán errores de tiempo de espera agotado en sus páginas y los registros de ULS mostrarán las entradas siguientes:

08/10/2011 12:20:22.30 w3wp.exe (0x1228) 0x1454 SharePoint Foundation Monitoring b4ly High Leaving Monitored Scope (ExecuteStoredProcedureDataReader -- MSP_AUTH_GETUSERBYNAME). Execution Time=120002.728838442 2be0491a-a64b-4237-8cfc-40342a374d49
08/10/2011 12:20:22.30 w3wp.exe (0x1228) 0x1454 Project Server General 8ym5 Monitorable PWA:http://<server>/PWA, ServiceApp:Project Web App Service Application, User:, PSI: SqlException occurred in DAL: <Error><Class>0</Class><LineNumber>0</LineNumber><Number>-2</Number><Procedure></Procedure> <Message> System.Data.SqlClient.SqlError: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. </Message> <CallStack> at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at …

¿Te ha resultado útil?
(Caracteres restantes: 1500)
Gracias por sus comentarios
Mostrar:
© 2014 Microsoft