Por padrão, a descrição das contas continham o nome completo do recurso, como por exemplo, João da Silva. Acontece que uma requisição da diretoria solicitava que essas descrições aparecessem no aplicativo Web Acess com a conta SAM do usuário (ex: joao.silva).  Isso porque existem diversos usuários que possuem um nome muito comprido, o que ocasionava quebras de páginas em algumas páginas ou relatórios.

Para atingir este objetivo, diferentemente do que muitos podem imaginar, apenas alterar a descrição do campo Display Name na conta de cada usuário no Active Directory não resolve o problema. Isso porque essas informações (nome, descrição, conta SAM) são importadas apenas na primeira vez que o recurso é cadastrado no EPM e após isso, é feito um cadastro salvando essas informações no aplicativo de SSP (Shared Services Provider) criado no ambiente.

Para alterar essas informações, acesse o site de administração central do Sharepoint e clique no serviço SSP que você criou para o seu farm no Sharepoint. No meu caso abaixo, o SSP foi chamado de EPMSSP.

Após isso, no site do SSP,e na seção Perfis de Usuário e Meus Sites, clique no item Perfis de usuários e Propriedades.

Agora clique na opção Exibir Perfis de Usuário

Agora é só clicar na conta do usuário e no menu Drop Down, selecionar a opção Editar

Agora é só editar as informações e salvar.

Após um dia inteiro de trabalho, a migração foi concluída com sucesso. Os testes preliminares pós-migração foram feitos e tudo estava funcionando perfeitamente.

Alguns dias depois, quando este farm entrou em produção, os usuários estavam encontrando problemas ao acessar algumas páginas do Project Server. O erro retornado era:

Aliás, o mais estranho mesmo, era que apenas essa informação era retornada. Nenhum código Html era retornado, apenas a string “403 – Forbidden”.  Executando algumas ferramentas de tracing, observei que antes dessa mensagem, o servidor respondia com dois pacotes de erro 401.1 do IIS.

Partindo disso, podemos identificar que o problema está relacionado a autenticação do IIS. Se um usuário tivesse privilégios de Administrador do servidor onde estava instalado esse EPM entrasse nessa mesma página, ele conseguia acessar normalmente. E após isso, todos os outros usuários, mesmos os que estavam com problemas, conseguiam abrir a página.

Estranho não? Pesquisando mais a fundo, consegui identificar um padrão para esse comportamento. Todas as vezes que o pool que executava esse contexto no IIS era reiniciado, o problema voltava a ocorrer.

Após alguns testes, finalmente descobri a razão disso e uma maneira de corrigir. O problema estava ocorrendo porque os usuários do meu domínio não tinham privilégios de leitura nos recursos do sistema usados pelo Sharepoint. Para corrigir isso, adicionei o grupo DOMINIO\Domains Users ao grupo local WSS_WPG  do servidor onde esta sendo executado o EPM.

Após um reinício do IIS, as coisas voltaram a funcionar perfeitamente.