Bonjour,

Nous avons reçu au Support, et ce de manière assez régulière, des incidents nous décrivant un phénomène plutôt surprenant qui se produit sur les serveurs Project Server 2010.

1. Description du phénomène:

En effet, vous avez été plusieurs à constater que sur vos serveurs, les Services “Microsoft Project Server Event Service 2010" et "Microsoft Project Server Queue Service 2010”était arrêtés et désactivés de manière régulière, sans aucune intervention humaine.

Le symptôme marquant qui a permis de détecter ce phénomène est que les jobs de publication, sauvegarde, archivage n’étaient plus exécutés mais restaient dans la Queue en attente.

Pourtant, quand vous vérifiez les instances de ces Services dans la Sharepoint Central Admin, vous pouvez voir qu’ils apparaissent comme étant Démarrés:

Pourtant, si vous vérifiez leur état dans la console Services des Outils d’Administration de Windows Server, vous les voyez arrêtés et désactivés:

Le fait de rechanger les propriétés en Automatique et de redémarrer les services permet de refaire fonctionner Project Server… quelques temps. Car en effet, à nouveau, ces services vont s’arréter et se désactiver automatiquement.

Bien que la réinstallation de la plate-forme permette de corriger ce problème, je me suis penché dessus pour essayer de comprendre ce qui provoquait ce phénomène.

Et voici donc mes conclusions:

2. La Cause:

Tout d’abord, après de multiples analyses de log ULS fournis par les différentes machines impactées, j’ai pu découvrir que le phénomène n’est pas si aléatoire que cela. En effet, curieusement, on détecte rapidement que l’arrêt des services et leur désactivation interviennent à heure régulière.

Qui dit “heure régulière” dit règle automatique. Et en fait, toujours en regardant les logs ULS, on peut voir que c’est une des règles du Hourly Health Analysis Job exécuté par les SharePoint Timer, qui est la cause de ce phénomène:

Et plus précisément, il s’agit de cette règle en particulier:

Pour le vérifier, il suffit simplement, si vos Services Project Server 2010 sont démarrés, d’exécuter cette règle en cliquant sur le bouton “Run Now”.

A ce moment-là, vous verrez les Services s’arréter et se désactiver et dans les logs ULS, vous obtiendrez le résultat suivant:

Ce qu’il est intéressant de constater, c’est que cette règle arrête et désactive les Services Project Server 2010 car elle pense que l’état des Services devrait être ainsi.

Cela n’est possible que si la règle détecte qu’il y a un problème entre l’état des Services et ceux de l’instance.

Et c’est effectivement le cas. Comme nous 'l’avons vu plus haut, dans la Central Admin, l’instance Project Server est démarrée (“Started”).

Or, si nous exécutons la commande Powershell suivante:

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

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

on obtient une réponse sans équivoque : “Disabled”

Et c’est donc là que se pose le problème d’incohérence des états qu’essaye de corriger la règle.

La solution :

Même si le scénario pour reproduire ce phénomène reste mystérieux, on peut imaginer que cela soit dû à une erreur de configuration lors du premier démarrage des Services Project Server 2010 après leur installation.

Cependant, on peut définitivement corriger cela en exécutant la commande Powershell suivante sur tous les serveurs sur lesquels les Services sont installés:

Start-SPServiceInstance -Identity <Id>

Si cela ne fonctionne pas correctement sur un de vos serveurs, faites un  Config Cache Refresh et exécuter cette commande à nouveau:

Stop-SPServiceInstance -Identity <Id>

Start-SPServiceInstance -Identity <Id>

<Id> est l’identifiant de l’instance du Service que l’on obtient en exécutant les commandes Powershell Get-SPFarm précedentes.

N’hésitez pas à commenter cet article et partager vos experiences.

Bonne journée,

Marc Biarnès