Artigo
03/08/2017

Práticas recomendadas para gerenciar um grande número de recursos no Project Server 2010

Aplica-se a: Project Server 2010

Tópico modificado em: 2016-11-30

Este artigo descreve as melhores práticas para gerenciar usuários em um ambiente do Microsoft Project Server 2010 quando existem projetos que possuem muitos usuários.

Neste artigo:

Visão geral das permissões de site do Project Server 2010
Permissões do Microsoft SharePoint Server 2010 para usuários do Project Server 2010
Problemas de desempenho quando o limite recomendado de usuários para sites de projeto é excedido
Herdando permissões do site pai do PWA
Desabilitando configurações de permissão do site de projeto
Erros associados a limites recomendados de usuários excedidos para sites de projeto

Visão geral de permissões de site do Project Server 2010

O Project Server 2010 usa a infraestrutura de permissões normal do SharePoint para definir o controle de acesso para o site do Microsoft Project Web App (PWA). Ele também usa a mesma infraestrutura para definir o controle de acesso para quaisquer sites de projeto (anteriormente conhecidos como sites do espaço de trabalho do projeto) que são criados para os planos do projeto individuais mantidos no Project Server.

No nível de site do PWA, os usuários são adicionados a grupos específicos do SharePoint, dependendo do nível de permissão que possuem dentro do Project Server. A página de configurações do site para um site do PWA contém grupos do SharePoint do "Microsoft Project Server" para Gerentes de Projeto, Leitores, membros de Equipe, Administradores Web e Administradores de Páginas de Detalhes do Projeto. Quando usuários são adicionados ao Project Server 2010, também são adicionados ao grupo apropriado para o site do PWA ao qual têm permissão para acessar. Por exemplo, digamos que um usuário seja adicionado ao Project Server 2010 e seja membro do grupo de segurança Gerentes de Projeto. O usuário é adicionado ao Grupo Gerentes de Projeto (Microsoft Project Server) em Permissões de Site para a página inicial do PWA, a página da Central de Projetos, a página do Centro de Aprovação e todas as páginas de sites do PWA às quais o usuário tem permissão para acessar.

As configurações das Permissões de Site do site do PWA não apenas contêm os grupos do SharePoint do "Microsoft Project Server", mas também mostram algumas contas de usuário individuais do SharePoint para administradores de conjuntos de sites e outras contas de administrador do farm. A tabela a seguir mostra os níveis de permissão do SharePoint para o Grupo SharePoint do Microsoft Project Server no nível de site do PWA.

Nome	Nível da permissão
Grupo Gerentes de Projeto (Microsoft Project Server)	Acesso Limitado, Gerentes de Projeto (Microsoft Project Server)
Grupo Leitores (Microsoft Project Server)	Acesso Limitado, Leitores (Microsoft Project Server)
Grupo Membros de Equipe (Microsoft Project Server)	Acesso Limitado, Membros de Equipe (Microsoft Project Server)
Grupo Administradores Web (Microsoft Project Server)	Acesso Limitado, Administradores Web (Microsoft Project Server)
Grupo Administradores de Fluxo de Trabalho e Páginas de Detalhes do Projeto (Microsoft Project Server)	Acesso Limitado

Para sites de projeto, os usuários são adicionados diretamente como indivíduos e não são adicionados a grupos do SharePoint do "Microsoft Project Server" específicos. O nível de permissão concedida ao usuário é determinado pela sua função.

Permissões do SharePoint Server 2010 para usuários do Project Server 2010

Os usuários do Project Server 2010 recebem acesso para sites do Project Server através de permissões do SharePoint Server 2010. O Project Server 2010 é compilado sobre o Microsoft SharePoint Server 2010 e sites disponíveis através do Project Server 2010 são sites do SharePoint.

Os dois tipos de sites do Project Server 2010 para os quais permissões do SharePoint precisam ser atribuídas são:

Sites do PWA (página inicial do PWA, Central de Projetos, Central de Recursos e assim por diante)
Sites de projeto (sites de colaboração para um projeto individual. São chamados de sites do espaço de trabalho do projeto no Office Project Server 2007).

Para sites do PWA, os usuários do Project Server 2010 são atribuídos a grupos do SharePoint do Microsoft Project Server, dependendo do seu nível de permissão no Project Server 2010:

Função de segurança do usuário	Permissões do SharePoint no site do PWA
Gerente de Projeto Gerente de Portfólio Gerente de Recursos Executivo	Grupo Gerentes de Projeto (Microsoft Project Server)
Administrador	Grupo Administradores Web (Microsoft Project Server)
Membro de Equipe Líder de Equipe	Grupo Membros de Equipe (Microsoft Project Server)

Gerente de Projeto
Gerente de Portfólio
Gerente de Recursos
Executivo

Grupo Gerentes de Projeto (Microsoft Project Server)

Administrador

Grupo Administradores Web (Microsoft Project Server)

Membro de Equipe

Líder de Equipe

Grupo Membros de Equipe (Microsoft Project Server)

Para sites de projeto, usuários do Project Server 2010 recebem as permissões do SharePoint a seguir. Para sites de projeto, usuários do Project Server 2010 são adicionados como usuários individuais do SharePoint que possuem permissões específicas do SharePoint para o site:

Usuário	Permissões do SharePoint no site de projeto
Gerentes de Projeto que publicaram um projeto	Gerentes de Projeto (Microsoft Project Server)
Gerentes de Projeto que possuem permissões de Salvar Projeto em um projeto	Gerentes de Projeto (Microsoft Project Server)
Membros de Equipe com atribuições em um projeto	Membros de Equipe (Microsoft Project Server)
Usuários do Project Server com permissão de Exibir Site de Projeto em um projeto	Leitores (Microsoft Project Server)

Problemas de desempenho quando o limite recomendado de usuários para sites de projeto é excedido

No Office Project Server 2007, um problema de desempenho pode ocorrer na sincronização do usuário com os sites do PWA porque usuários individuais são adicionados ao PWA e a sites do espaço de trabalho do projeto com níveis de permissão específicos. Quando alterações são feitas na permissão do usuário para o site, todos os usuários que possuem permissões para o site são removidos e adicionados de volta ao site. Quando há muitos usuários em um site, este processo pode levar muito tempo. Usuários que estão em processo de ser adicionados de volta ao site recebem um erro de Acesso Negado, até que sejam adicionados novamente ao site.

No Project Server 2010, duas alterações foram feitas no acesso do usuário a sites do PWA para corrigir o problema que existe no Office Project Server 2007:

Usuários que acessam sites do PWA foram adicionados a grupos de usuários do SharePoint em vez de adicionados individualmente.
Quando uma sincronização de usuário ocorre, os usuários são removidos individualmente e adicionados de volta ao site um por vez (em vez de remover todos os usuários e adicioná-los novamente um por vez).

Estas alterações foram aplicadas apenas para sites do PWA, que normalmente possuem muitos usuários que os acessam. Esta alteração não foi feita para sites de projeto. A razão é que sites de projeto normalmente possuem muito menos usuários que os acessam (geralmente os recursos atribuídos ao projeto) e têm menos probabilidade de serem afetados pelo problema de sincronização. Isso pode ser um problema quando se deseja ter muitos ou todos os usuários acessando muitos ou todos os sites de projeto. Isso poderia ser alcançado adicionando muitos usuários a um projeto ou atribuindo a permissão Exibir Sites de Projeto no nível de membro de equipe em uma categoria que inclua muitos ou todos os projetos. No entanto, quando este cenário ocorre, é possível que os limites recomendados do software e os limites do SharePoint Server 2010 sejam excedidos se o número de usuários for grande. Exceder estes limites recomendados pode levar a problemas de desempenho. A cada usuário adicionado individualmente a um site é considerado um escopo de segurança. O número máximo recomendado de escopos de segurança únicos por lista é 1.000. Cada lista e biblioteca no site herdaria permissões do site pai — e excederiam este limite se mais de 1.000 usuários individuais tivessem acesso ao site. Para mais informações sobre limitações de escopo de segurança para listas, consulte Gerenciamento de capacidade do SharePoint Server 2010: Limites de software.

Quando os limites de escopo de segurança único são excedidos, problemas de desempenho podem ocorrer. Os problemas acontecem quando uma alteração é feita na associação do site, causada por alterações nas categorias ou grupo, ou devido a ações como adicionar ou desativar um usuário. Uma razão pela qual a limitação recomendada para usuários individuais foi imposta é que, se excedida, o processo de remover usuários do site pode se tornar muito lento. E fica especialmente lento se o mesmo usuário for removido de vários sites, todos os quais excederam o limite recomendado. Em casos em que vários usuários são desativados, é possível que o servidor pare de responder e não consiga autenticar usuários. Isso cria um problema único quando os limites recomendados de usuários individuais para um site começam a ser excedidos. Seu servidor pode parar de responder quando for preciso gerenciar usuários porque há muitos com permissão em um site. Ao tentar corrigir o problema removendo usuários do site, você também pode fazer com que o servidor pare de responder.

As melhores práticas para evitar este problema dependem de quais são seus objetivos:

Se é realmente necessário que a maioria dos usuários acesse a maioria dos sites de projeto: Em vez de adicionar usuários individualmente aos sites, use os grupos do SharePoint Server 2010 e a herança do PWA para adicionar os usuários a estes grupos. Por exemplo, geralmente o site pai para sites de projeto é a página inicial do PWA. Neste cenário, sites de projeto herdarão as permissões da página inicial do PWA, que possui todos os usuários do PWA em grupos do SharePoint do Microsoft Project Server.
Se não existe a intenção de ter muitos usuários acessando muitos sites e é necessário resolver o problema: Remova a permissão de categoria Exibir Sites de Projeto da categoria que fornece aos usuários acesso aos sites. Você também pode reduzir o número de recursos atribuídos ao projeto. Antes de efetuar qualquer uma das opções, a sincronização de usuários com o site deve ser interrompida. Do contrário, qualquer uma delas pode fazer com que seu servidor pare de responder.

Para desabilitar a sincronização do site de projeto, você pode escrever um utilitário que use a Interface do Project Server (PSI), o Serviço Web de Administração e defina a Enumeração UserSyncSetting (em inglês) como DisablePWS. Chame a enumeração com o Método Admin.UpdateUserSyncSetting (em inglês).

Nome do membro	Descrição
Enable	Valor=0 Habilita todas as sincronizações
DisablePWA	Valor=1. Desabilita a sincronização com o Project Web App.
DisablePWS	Valor=2. Desabilita a sincronização com sites de projeto para o usuário.
DisableEmailSync	Valor=3. Desabilita a sincronização de e-mail.
DisableAll	Valor=4. Desabilita todas as sincronizações.

Você também pode desabilitar a configuração fazendo alterações diretamente na tabela MSP_WEB_ADMIN no banco de dados Publicados (Published) na coluna WADMIN_USER_SYNC_SETTING. Você pode executar a consulta SQL a seguir para desabilitar a sincronização do site de projeto:

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

Você pode considerar a opção de fazer alterações diretamente na tabela MSP_WEB_ADMIN no banco de dados Publicados (Published) muito mais fácil do que criar e testar uma ferramenta para fazer a mesma coisa através do PSI.

Observação

Na maioria das instâncias, não é recomendável alterar o banco de dados Publicados (Published) diretamente. Além disso, se o fizer, isso pode invalidar seu suporte. No entanto, usar a consulta anterior para desabilitar a sincronização do site de projeto é uma exceção permitida.

Herdando permissões do site pai do PWA

Uma vez que a sincronização do site de projeto esteja desabilitada, ainda é possível disparar os mesmos problemas se você tentar remover usuários diretamente de um site de projeto através da funcionalidade fornecida na página de permissão de site do SharePoint. Uma forma de remover usuários rapidamente sem disparar a exclusão individual que causa o problema é herdar permissões do site pai, o que pode ser feito através da faixa de opções da interface do usuário na página Permissões do Site do site de projeto individual (no menu Ações do Site).

Para herdar permissões do site pai para o site de projeto

No site de projeto, clique em Ações do Site e clique em Permissões do Site.
Na página Permissões, clique na faixa de opções Editar.
Clique em Herdar Permissões.
Na caixa de mensagem que o alerta de que alterar para permissões herdadas pode impedir que os usuários acessem o site, clique em OK.

A faixa de opções indicará que o site agora herda permissões do seu site pai, que deve ser um site do PWA. A estrutura de permissão do site para o site pai agora será a estrutura de permissão do site para o site de projeto, o que significa que usuários individuais do PWA agora estão dentro dos grupos de site do Microsoft Project Server.

Se sua meta final é dar acesso à maioria dos usuários para a maioria dos sites, você pode desejar que seus sites de projeto herdem permissões do PWA conforme descrito acima. Antes de tomar esta ação, você deve se certificar de que o site do PWA tem as permissões certas para todos os usuários que precisam de acesso, porque a permissão que os usuários têm no PWA será a permissão que terão no site de projeto quando o procedimento para herdar permissões for executado.

Se você tem muitos sites de projeto, pode usar o Windows PowerShell para automatizar a alteração. O comando do Windows PowerShell a seguir faz com que todos os sites de projeto filhos do site do PWA pai especificado herdem suas permissões. Você pode executar o comando do Windows PowerShell no SharePoint 2010 Management Shell:

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

Este comando seria executado (ou o procedimento anterior para herdar permissões do site) para quaisquer novos sites de projeto, para evitar a recorrência do problema.

Observação

Clicar na opção Sincronizar na página do site de projeto nas Configurações do Servidor do PWA quebrará novamente a herança. Certifique-se de não clicar nesta opção se você deseja que o site de projeto continue a herdar permissões do seu site do PWA pai.

Em um ambiente em que todos os sites de projeto estão herdando permissões do PWA, é possível que você deseje ter certos projetos com informações confidenciais e que seja possível gerenciar permissões e usuários em um nível individual. Seria possível usar o Windows PowerShell para definir uma propriedade para estes sites e usá-la para filtrar em uma versão modificada do comando do Windows PowerShell usado para definir a herança (acima).

Desabilitando a configuração Permissões do Site de Projeto

Você também pode evitar a inclusão automática de usuários aos seus sites de projeto desabilitando a configuração Permissões do Site de Projeto localizada na seção Políticas Operacionais das Configurações do seu Servidor Project Web App. Quando esta configuração está habilitada, os usuários do Project Web App são automaticamente sincronizados com sites de projeto sempre que permissões de usuário mudam no Project Server 2010, o gerente de projeto publica o projeto ou quando o site de projeto é criado. Se a configuração estiver habilitada e qualquer um dos itens acima acontecer, as ações a seguir ocorrerão automaticamente:

Gerentes de projeto que publicaram um projeto ou possuem a permissão Salvar Projeto em um projeto são adicionados ao site com permissões de Gerente de Projeto (Microsoft Project Server).
Membros de equipe com atribuições em um projeto são adicionados ao site com permissões de Membros de Equipe (Microsoft Project Server).
Outros usuários do Project Server que possuem permissões de Exibir Site de Projeto em um projeto são adicionados ao site com permissões de Leitores (Microsoft Project Server).

Desabilitar esta opção interrompe a inclusão automática de usuários do Project Server ao site, mas não removerá usuários que já tenham sido adicionados.

Para desabilitar a configuração Permissões do Site de Projeto

Na página Configurações do Servidor, na seção Políticas Operacionais, clique em Configurações de Provisionamento de Site de Projeto.
Na página Configurações de Provisionamento de Site de Projeto, na seção Permissões do Site de Projeto, desmarque a caixa de seleção rotulada como Selecione a sincronização automática de usuários do Project Web App com Sites de Projetos quando eles forem criados, quando os gerentes de projeto publicarem projetos e quando as permissões de usuário forem alteradas no Project Server.

Quando a caixa de seleção está desmarcada, os usuários do Project Server nunca são sincronizados com sites de projeto.
Clique em Salvar.

Para mais informações sobre a configuração Permissões do Site de Projeto, consulte Project Site Provisioning Settings (Project Server 2010 settings).

Erros associados a limites recomendados de usuários excedidos para sites de projeto

A seguir estão erros que podem aparecer nos logs do ULS quando sua implantação do Project Server tiver problemas de desempenho porque um número superior ao máximo de usuários recomendado está acessando sites de projeto. Normalmente o usuário que inicia o problema (talvez por desativar um recurso) vê o botão Salvar na página Editar Usuário como se estivesse "clicado", eventualmente exibindo a mensagem "Ocorreu um erro inesperado". O ID de correlação pode ser encontrado nos logs do ULS e fornecerá dados relacionados a um deadlock do SQL. A entrada de nível "Crítico" será semelhante a:

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

Um erro de nível "Alto" que fornece mais informações sobre a consulta que causou o problema será semelhante ao texto a seguir. A entrada fornecida foi significativamente resumida, mas observe o texto chave “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….

Uma entrada de nível "Inesperado" (“Unexpected”) que também pode ser gerada, similar a:

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

O servidor pode parar de responder por 15 a 30 minutos. Durante este tempo, outros usuários receberão erros de tempo esgotado em suas páginas e os logs do ULS podem exibir as seguintes entradas:

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 …

Compartilhar via