La base de données opérationnelle de System Center Service Manager 2012 (R2) peut être hebergée par un groupe de disponibilité "AlwaysOn" SQL Server 2012. Il s'agit d'une configuration qui fonctionne et qui est supporté par Microsoft (voir la page technet : http://technet.microsoft.com/en-us/library/hh495585.aspx dans la partie "AlwaysOn Availability Groups Considerations for Service Manager Databases"). Ce même document propose un lien (http://blogs.technet.com/b/babulalghule/archive/2013/02/17/how-to-install-service-manager-2012-sp1-with-a-sql-2012-alwayson-availability-groups.aspx) expliquant comment réaliser l'installation de Service Manager 2012 sur un groupe de disponibilité SQL Server.
Ce que n'indique pas cette procédure, c'est que en suivant ces instructions à la lettre, l'installation de Service Manager 2012 sera bloquée sur le choix du serveur et de l'instance SQL pour la base de données opérationnelle. L'assistant d'installation affichera le message "A required SQL Server service is not running on SQL_SERVER:SQL_INSTANCE".
Le log de l’install situé dans par défaut dans c:\Users\utilisateurcourant\AppData\Local\Temp\2\SCSMSetupWizard01.log indique l’erreur : 06:32:08:***ERROR*** StartService: System.InvalidOperationException: Cannot open Service Control Manager on computer 'LBLSQLSM00.wattmildom.local'. This operation might require other privileges. ---> System.ComponentModel.Win32Exception: The RPC server is unavailable
En fait l’installeur tente de tester la présence des services SQL sur l’instance désignée dans la liste déroulante, par une requête RPC sur le nom du LISTENER ce qui par défaut ne peut pas aboutir pour la raison expliquée ici : http://support.microsoft.com/kb/306985/en-us. Un "workaround" consiste à installer Service Manager en indiquant directement un des noeuds du cluster et à modifier ensuite la configuration de SCSM pour indiquer le nouveau chemin vers la base de données (comme décrit ici par exemple : http://www.buchatech.com/2014/05/error-installing-service-manager-with-sql-alwayson/).
La solution décrite dans le présent billet, consiste à changer la valeur du paramètre RemapPipeNames sur la ressource du cluster concernée. Sur le listener créé par SQL ce paramètre est à 1 et il faut le passer à 0 pour que la requête RPC aboutisse et que l’installation ne se bloque pas à cette étape.
Procédure pour modifier la valeur du paramètre "RemapPipeNames"
Sur un des nœuds du cluster lancer une fenêtre "powershell" et utiliser les commandes suivantes (en italique dans le texte) :
Get-ClusterResource ==> pour obtenir la liste des ressources. Noter la ressource de type « Network Name » et qui correspond au listener SQL (INSTANCE DEFAULT)
Get-ClusterResource -Name NOM DE LA RESSOURCE | Get-ClusterParameter ==> afin de voir la valeur des paramètres de la ressource (le paramètre qui nous intéresse est « RemapPipeNames » et doit être à 1 par défaut)
Get-ClusterResource -Name NOM DE LA RESSOURCE | Set-ClusterParameter -Name RemapPipeNames -Value 0 ==> afin de mettre le paramètre RemapPipeNames à 0
Pour que la nouvelle valeur du paramètre soit prise en compte il faut soit :
- Effectuer une bascule du groupe de disponibilité SQL
- En powershell utiliser les 2 commande suivantes (attention au nom des ressources, la première est la ressource qui correspond au nom réseau du listener SQL, la deuxième correspond au groupe de disponibilité) : Get-ClusterResource -Name NOM DE LA RESSOURCE CORRESPONDANT AU LISTENER | Stop-ClusterResource | Start-ClusterResource puis Get-ClusterResource -Name NOM DE LA RESSOURCE CORRESPONDANT AU GROUPE DE DISPONIBILITE | Start-ClusterResource
Il est maintenant possible de passer l’étape de validation de l’instance dans l’installeur de SCSM 2012 R2.
Je conseille de réaliser l’ensemble des installations SCSM (tous les Management Server, ainsi que les différents patchs envisagés), et enfin de repasser la valeur du paramètre "RemapPipeNames" à 1 en suivant la même procédure.
