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ços de Project Server - "Microsoft Project Server Event Service 2010" e "Microsoft Project Server Queue Service 2010" não só estavam parados mas também desativados!
 
clip_image001
 
clip_image002
 
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":
clip_image003
 
E em específico, existe a regra que verifica a existência de serviços que tenham iniciado ou parado de forma inesperada:
clip_image004
 
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.:

http://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: 

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