Project Server 2010: Os serviços de queueing e Eventing param e ficam desativados regularmente

Temos recebido algumas chamadas sobre este assunto: O sintoma inicial é que os "queue jobs" do Project Server 2010 não passam para estado de processamento ou ”processing”, mas sim ficam à espera para serem processados "waiting to be processed" . Ao verificarmos, nada parecia estar a bloquear essa tarefa na fila e não havia mais nenhum trabalho a ser processado nesse momento.

Numa averiguação mais detalhada, e apesar de o "Project Application Service" estar a correr com “Started” e a verde no site Administração Central do SharePoint, quando se olhava para a lista de serviços a correr no sistema operativo, reparámos que os serviçosde Project Server - "Microsoft Project Server Event Service 2010" e "Microsoft Project Server Queue Service 2010" não só estavam parados mas também desativados!

 

 

 

Então o óbvio será ativar os serviços e iniciar novamente, certo? Errado! em breve, eles voltam a ser desativados novamente, e voltamos ao inicio do problema.

A conclusão da pesquisa, mostrou-nos que a desativação do serviço ocorreu quando a "Hourly Health Analysis" é executada pelo "SharePoint Timer service":

E em específico, existe a regra que verifica a existência de serviços que tenham iniciado ou parado de forma inesperada:

Para validar se esta é realmente a questão que causa os problemas de filas (poderia haver outras causas), É possível selecionar essa regra e clicar para "Executar agora". e ai verifica: os serviços ficam novamente interrompidos e inativos. Outra dica importante é, como habitual, verificar nos ULS logs, onde irá encontrar as seguintes linhas:

OWSTIMER.EXE (0x1A60)	0x0C48	SharePoint Foundation	Health	ag78	Verbose	Checking the Microsoft Project Server Queuing Service windows service instance.
OWSTIMER.EXE (0x1A60)	0x0C48	SharePoint Foundation	General	0000	Verbose	Entered SPAdvApi32.IsServiceRunning(ProjectQueueService14)
OWSTIMER.EXE (0x1A60)	0x0C48	SharePoint Foundation	Health	ag7d	Verbose	The service is not disabled, but should be.
OWSTIMER.EXE (0x1A60)	0x0C48	SharePoint Foundation	Health	8fs1	Verbose	Finished invoking the Check() method. The rule Failed
OWSTIMER.EXE (0x1A60)	0x0C48	SharePoint Foundation	Health	8fs4	Medium	Automatic repair is being attempted.
OWSTIMER.EXE (0x1A60)	0x0C48	SharePoint Foundation	General	0000	Verbose	Entered SPAdvApi32.IsServiceRunning(SPAdminV4)
OWSTIMER.EXE (0x1A60)	0x0C48	SharePoint Foundation	General	0000	Verbose	Entered SPAdvApi32.StopService(ProjectQueueService14)
Microsoft.Office.Project.Server (0x1A08)	0x22B0	Project Server	General	8zdx	High	[SERVICE] ProjectQueueService14: shutting down

O que é interessante de verificar é que a regra deteta e inativa os serviços de Project Server 2010, pois pensa que os serviços assim deverão estar. E então encontramos a razão da mudança:

Apesar de o "Service Application " estar 'Iniciado' como se viu na figura anterior, ao executar os comandos PowerShell, verifica-se que estão realmente desativados:

((Get-SPFarm).)Services| where {$ _.}Name - match "ProjectQueueService14"}) .instances

((Get-SPFarm).)Services| where {$ _.}Name - match "ProjectEventService14"}) .instances

 

A inconsistência no estado desses serviços é que causava a sua desativação pelo processo "Health check".

Ainda não temos uma boa explicação para esta situação mas há uma maneira de a travar! Mais uma vez, usaremos o PowerShell e precisaremos de executar o seguinte comando em todos os servidores em que os serviços estão instalados:

Start-SPServiceInstance - Identity < Id >

Onde o Id é o ID devolvido pelo comando Get-SPFarm para os serviços específicos. Por vezes verificámos que isto poderá ainda não resolver o problema de imediato, e nestes casos é preciso limpar a cache de configuração, parar e iniciar a instância do serviço:

Stop-SPServiceInstance - Identity < Id >
Start-SPServiceInstance - Identity < Id >

Note: caso não seja exatamente o seu problema, verifique outros artigos sobre possíveis razões para ter uma fila lenta ou mesmo parada, por ex.:

https://blogs.msdn.com/b/brismith/archive/2012/09/19/when-your-project-server-queue-slows-down.aspx

Finalmente, fica o agradecimento ao colega Marc pela analise detalhada deste problema e pelo seu artigo original no blog francês:

https://blogs.technet.com/b/frenchpjblog/archive/2012/12/24/3542467.aspx