Dicas do UPS (User Profile Service) no SharePoint 2010/2013

Como eu havia prometido no primeiro post dessa coluna, eu vou colocar aqui alguns macetes na resolução de problemas no UPS do SharePoint que podem te ajudar bastante em um momento de problema.

As informações desse artigo podem ser aplicadas para as versões SharePoint Server 2010 e SharePoint Server 2013.

Antes disso porém, eu quero reservar um espaço aqui para expor o principal motivo pelo qual eu acho que o time do SharePoint optou por usar a FIM para realizar a sincronização e a escrita de conteúdo no AD (coisa que o time de AD não deve gostar muito). Eu consigo pensar várias teorias, a melhor delas eu encontrei no artigo de Paul Culmsee (link aqui) que eu reproduzo abaixo:

I think that Microsoft decided that SharePoint 2010 should be able to write back
to Active Directory (something that AD purists dislike but sold Bamboo many 
copies of their sync tool). Presumably the SharePoint team get on really well 
with the Forefront Identify Manager team and over a few Friday beers, 
the FIM guys said “Why write your own? Use our fit for purpose tool that 
does exactly this. As an added bonus, you can sync to other directories 
easily too”.

“Damn, that *is* a good idea”, says the SharePoint team and the rest is history. 
Remember the old saying, the road to hell is paved with good intentions?

Sim meus amigos, deve ter sido por isso……

Mas se você está aqui, ou está com problemas com a implantação desse serviço ou não quer mais ter problemas em uma nova implantação, neste caso, vamos as dicas!

Certificados Self-Signed “ForefrontIdentityManager”

Se você tentou configurar esse serviço várias vezes e ainda não teve sucesso, provavelmente vai se espantar ao ver a grande quantidade de certificados com o nome ForefrontIdentityManager no  Trusted Root Certification Authority gerados no servidor, isso ocorre porque a implantação desse serviço é realizado em 2 etapas, na primeira ocorre a criação do certificado Self-Signed e na segunda a reserva de uma URL na porta 5725 com o certificado, se a implantação falhar na segunda etapa, esses certificados ficam no repositório “ad eternum“.

Esse também pode ser um motivo pelo qual você nota mensagens de erro no EventViewer de código 22 e 234 caso use o SharePoint para fazer o backup do UPS. Você pode ver mais detalhes desse problema clicando aqui.

Endereço reservado na porta 5725 do servidor

Na segunda etapa de criação do serviço, o FIM reserva a porta 5725 do servidor para o uso na sincronização de perfis do AD, o certificado criado na etapa anterior é utilizado no serviço exposto, então se você por acaso criou o serviço e está tentando uma nova implantação, vale a pena olhar se esta porta não está reservada para um outro serviço que pode impactar a implantação do serviço.

Para consultar a lista de portas reservadas para o protocolo HTTP, você pode usar esse comando no console do servidor:

netsh http show urlacl

Você pode consultar uma lista de portas usadas pelo SharePoint  clicando aqui.

Atualização de certificados do servidor SharePoint

Esse é um problema bem comum na implantação do UPS no SharePoint e vem configurado por padrão nas versões servers do Windows, existe uma política no servidor chamada Certification Path Validation Settings, que por padrão vai atualizar os certificados raiz do servidor através da internet no Microsoft Root Certificate Program, quando o servidor tem acesso a internet tudo funciona perfeitamente, agora seu time de infraestrutura pode não gostar da ideia de habilitar a internet em um servidor OnPremisses (e com razão) e nesses casos você pode ter problemas na implantação do UPS e ainda receber notificações no EventViewer do servidor. Para esses casos, eu recomendo que você desabilite essa validação nas políticas do servidor (veja a opção 5 do seguinte material).

Utilizar a conta do FARM como service account do UPS Sync Service

Se você implantou o serviço do UPS e não está conseguindo alterar a conta host do serviço, provavelmente você fez tudo certo mesmo. O serviço de sincronização deve sempre utilizar a conta do Farm como host do serviço e a conta de sincronização, que pode ser um usuário comum, deve usada para conexão com AD. Além disso, essa conta de usuário comum deve possuir a propriedade “Replicate Directory Changes” atribuída no AD.

Você pode consultar as permissões para a conta de sincronização com o AD no seguinte material do technet.

Você também pode consultar mais detalhes nesse material aqui.