Désactivation régulière des services Event et Queue de Project Server 2010

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.

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:

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

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>

Pendant quelques minutes durant lesquelles le Service est démarré et initialisé, le service est en état Provisionning:

Puis, une fois le processus terminé, il est a nouveau Online:

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écédentes.

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

Bonne journée,

Marc Biarnès

Comments

• Anonymous
  January 13, 2013
  Merci pour l'image de la fonction de désactivation de ce programme. ne sais pas comment faire cela et maintenant heureux de savoir cela et c'est en fait assez bien simple en fait. <a href="www.laperlerare.be/">Titres services</a>