Suite à une installation du SP2 de SQL Server 2012 chez un client cette semaine, un collègue et moi même sommes tombés sur un petit souci qui a pris quelques heures à être résolu.

Description du contexte

L'infrastructure sur laquel nous travaillions est composée de 2 serveurs Windows Server 2012R2 au niveau desquels il y a un cluster SQL Server 2012 RTM de 2 noeuds (N01 et N02).

Lorsque vous disposez d'un cluster SQL, l'installation des SP ou mises à jour SQL doivent se faire sur le noeud passif. Dans le cadre de ce post, le noeud passif est le N02. Une fois l'installation du SP2 terminée avec succès sur N02, il faut le faire sur N01. Hors, ce dernier étant le noeud actif, il est donc impératif de basculer le rôle SQL Server sur N02 afin que ce dernier deviennent actif et que N01 devienne le noeud passif. En effet, il est fortement conseillé de mettre à jour un noeud passif dans un cluster. Une fois N01 passif, il sera alors possible d'installer le SP2 sur ce noeud.

Après l'installation du SP2 sur le noeud N02, au moment de réaliser la bascule du rôle SQL Server sur ce dernier, une erreur est survenue empêchant la bonne éxécution de la bascule. Étant donné qu'il est indispensable que cette bascule ait eu lieu pour pouvoir installer le SP2 sur le noeud N01, Il nous était donc impossible d'effectuer cette installation. L'erreur se manifestait en empêchant le moteur SQL de démarrer ... Plutôt génant pour pouvoir effectuer la bascule et, à terme, se servir de son cluster SQL !

Un rapide parcours de la console des évènements critiques SQL Server permet de récupérer l'ID de l'erreur et de faire quelques recherches sur Internet qui s'avèrent être inutiles ... L'ID retourné était la 1069.

En allant jeter un coup d'oeil au service SQL Server, on se rend compte que le code de sortie est le 1067. Ce dernier est un code de sortie assez général indiquant que le service n'a pas réussi à démarrer. Ceci ne nous aide donc pas beaucoup à la résolution de l'erreur.

Résolution

Après avoir effectué plusieurs recherches sur internet et testé quelques résolutions trouvées ci et là, aucunes de ces dernières n'étaient fructueuses et la bascule ne se faisait donc toujours pas sur le noeud N02.

En regardant les services de la console de configuration SQL, nous nous sommes rendu compte que le mode de démarrage du service SQL Browser était sur désactivé. En effet, pour des raisons de sécurité, il est fortement conseillé de le désactiver, sauf si vous utilisez des services qui ont besoin du Browser pour pouvoir fonctionner.

Après avoir repasser le mode de démarrage à manuel pour le service SQL Browser et après l'avoir démarré, nous avons alors rententé d'effectuer une bascule. Et la, miracle ... la bascule s'est faite.

Après avoir effectué la bascule sur le noeud N02, la mise à jour du noeud N01 a pu se faire. Il fallait également démarrer le service SQL Server Browser sur ce noeud afin de pouvoir ré-effectuer une bascule dans le sens opposé.

La leçon à retenir, et la solution qui a permis de résoudre notre problème, est qu'il ne faut pas que les services SQL soient désactivés lors d'une bascule des rôles sur le serveur SQL venant d'être mis à jour !

Pour tous ceux qui en auraient besoin, vous trouverez ci-dessous les liens de téléchargement du SP2 de SQL Server 2012 (français et anglais).

Lien de téléchargement du SP2 de SQL Server 2012 en anglais : http://www.microsoft.com/en-us/download/details.aspx?id=43340

Lien de téléchargement du SP2 de SQL Server 2012 en français : http://www.microsoft.com/fr-FR/download/details.aspx?id=43340

Dans le cas où vous auriez besoin de fournir un credential sans avoir aucune interaction humaine (dans le cadre d'un script notamment), il vous sera indispensable de créer un objet de type PSCredential qui va vous permettre de stocker de manière sécurisée votre credential. Vous pourrez ensuite utiliser cet objet au niveau de votre script afin de fournir à ce dernier les credentials nécessaires à sa bonne exécution.

$user = "Administrator"
$pwd = ConvertTo-SecureString "MyP@55w0rd" -AsPlainText -Force
$cred = New-Object System.Management.Automation.PSCredential($user,$pwd)

Vous pouvez maintenant utiliser l'objet $cred pour fournir le credential de l'utilisateur Administrator.

Afin de pouvoir intégrer une machine à votre domaine en PowerShell, il faut utiliser la cmdlet Add-Computer avec les paramètres suivant :

• DomainName : Permet de spécifier votre domaine
• DomainCredential : Permet de fournir le compte utiliser afin d'entrer la machine dans le domaine
• OUPath : Permet de spécifier l'OU dans laquelle vous voulez mettre votre machine

Dans mon cas, le domaine est lab.local. Je dipose d'une OU nommée Computers située elle-même dans une OU nommée LAB. Ma commande est donc la suivante :

Add-Computer -DomainName lab.local -DomainCredential administrator@lab.local -OUPath "OU=Computers,OU=LAB,DC=lab,DC=local"

Après avoir entré cette commande, une fenêtre apparaît à l'écran vous demandant d'entrer le mot de passe du compte administrator. Entrez-y le mot de passe puis cliquez sur le bouton OK.

Une fois ceci effectué, vérifiez que votre machine a bien été ajouté dans la bonne OU.

Bien entendu, vous devez redémarrer votre machine pour que le changement prenne effet.

Pour ceux qui désirent apprendre le PowerShell sans que cela ne vous prenne trop de temps, vous pouvez regarder les vidéos Youtube que Don Jones a mis à disposition : Apprendre PowerShell en 1 mois pendant vos pauses déjeuner.

Les vidéos datent un peu (2012), cependant cela reste un excellent moyen d'apprendre les bases du PowerShell :)

Attention : Les vidéos sont en anglais, vous devez donc comprendre un minimum l'anglais pour vous lancer :)