SQL Server 2012 : Installation et intégration des mises à jour

Mis en avant

Pour ceux qui ont eu à installer SQL Server 2012, vous avez sans doute remarqué que le processus d’installation incorporait maintenant des mises à jour avant même d’installer SQL Server. Cette petite nouveauté est en réalité très pratique lorsque l’on doit installer des binaires dans une certaine version et que l’on doit installer un service pack ou un cumulative update. On remplace les fameuses installations "slipstream" où l’incorporation d’un service pack dans des binaires d’installation était une opération plutôt laborieuse. De plus il existe 2 méthodes de mise à jour : l’une permet de récupérer les mises à jour via internet et l’autre permet de spécifier un dossier dans lequel il est possible de placer les mises à jour d’installation à incorporer durant l’installation d’une instance SQL Server. Par exemple il est tout à fait possible d’incorporer en même temps le service pack 1 de SQL Server 2012 et le cumulative update 3. Si plusieurs cumulative update sont présent l’installation ne prendra que le dernier en vigueur !

 

icon_arrow J’ai créé ici un dossier nommé SQL2012_SP1_CU3 où j’ai placé les fichiers d’installation du service pack1 de SQL Server 2012 et 2 cumulatives updates : CU1 et CU3

 

sp1_et_cu1_et_cu3

 

icon_arrow Il suffit ensuite d’utiliser les paramètres supplémentaires fournis avec SQL Server 2012 (/UpdateEnabled et /UpdateSource). J’effectue ici une installation en ligne de commande

 

image

 

icon_arrow Lorsque l’installation se lance on peut remarquer que l’installation détecte les mises à jour et ne prend que le service pack 1 et le dernier cumulative update (CU3)

 

install_gui_product_updates

 

Le cumulative update 3 correspond au KB 2812412 :

kb_cu3

 

icon_arrow Une fois l’installation terminée une petite vérification de la version :

 

result_after_install

 

Bonne installation !!

David BARBARIN (Mikedavem)
MVP SQL Server

A propos de l’erreur 33203 : SQL Server audit could not write to the security log

Mis en avant

Lors de la mise en place des audits de sécurité je me suis heurté à cette fameuse erreur 33203 sur une instance nommée qui indique explicitement que SQL Server ne peut pas écrire dan le journal de sécurité Windows.  Ma configuration est la suivante : SQL Server 2012 SP1  et Windows 2012 Server.

Je précise avant de commencer que les prérequis de fonctionnement des audits avec le journal de sécurité Windows sont respectés. La conséquence directe de l’erreur 33203 est qu’au évènement n’est enregistré dans le journal de sécurité Windows, ce qui est plutôt gênant pour des audits. De plus les journaux des erreurs Windows et SQL Server ne sont pas spécialement bavards quant à la cause de cette erreur.

 

image

 

Dans ce cas comment savoir ce qui empêche SQL Server d’écrire dans le journal ? Je dois dire que les outils sysinternals sont bien utiles dans ces moments et en particulier procmon.

Une capture procmon me donne ceci lorsque j’active un objet d’audit depuis SQL Server :

 

image

On peut remarquer ici que SQL Server tente un accès à la clé de registre HKLM\System\CurrentControlSet\Services\EventLog\Security et que cet accès lui est visiblement refusé. Un message est également inscrit dans le journal des erreurs SQL. Pas de souci, nous allons configurer les permissions adéquates sur cette clé de registre.

 

image

 

Le paramétrage des permissions a visiblement permis à l’instance SQL Server de créer une nouvelle clé de registre dans HKLM\System\CurrentControlSet\Services\EventLog\Security :

image

 

image

 

Me croyant sauvé, j’active mes audits mais je me heurte à une nouvelle erreur. Une nouvelle trace procmon me révèle le problème suivant :

 

image

 

SQL Server tente de lire le fichier C:\Windows\System32\LogFiles\Sum\Api.log mais encore un fois ce dernier se voit refuser l’accès. Le paramétrage en lecture seule du fichier Api.log me permet enfin d’activer mes audits et de valider que les évènements soient bien enregistrés dans le journal de sécurité Windows. Ce deuxième problème visiblement a été remonté chez Microsoft et est toujours d’actualité. A noter que je n’ai eu ce souci que pour mon instance nommé dans mon cas.

 

Quelques remarques supplémentaires :

  • Le fait d’enlever le compte de service SQL des permissions de la clé de registre HKLM\System\CurrentControlSet\Services\EventLog\Security ne semble plus être gênant à partir du moment où la nouvelle clé a été créé.
  • Il n’est pas possible cependant d’enlever les permissions sur le fichier C:\Windows\System32\LogFiles\Sum\Api.log sous peine d’avoir dans le journal des évènements Windows le type d’erreur suivant et plus d’évènement d’audit enregistré. A voir si le problème sera résolu plus tard par Microsoft (dans un CU4 peut être ?) avec Windows Server 2012. L’ensemble des problèmes répertoriés concerneraient Windows Server 2012.
  • Je ne pense pas que le problème soit lié à la version de SQL Server. Si j’ai le temps je testerai sur une version SQL Server 2008 R2 et mettrait à jour mon blog.

 

image

 

Bonne activation d’audit !! Sourire

 

David BARBARIN (Mikedavem)
MVP SQL Server

Prochain évènement GUSS le 24 avril – 19h00 : Webcast sur SQL Server 2012 AlwaysOn pour les fermes Sharepoint 2013

Mis en avant

J’aurai le plaisir d’animer le prochain évènement du GUSS sous un nouveau format. Le principe est simple : où que vous soyez, vous pouvez rejoindre le webcast en ligne avec le son, la vidéo et un chat pour poser des questions.

 

Ce webcast sera composé de 2 sujets de 30 minutes :

 

icon_arrow  Always-On : rappel des bases
La première session rappellera le fonctionnement et les bases de la Haute-Disponibilité avec AlwaysOn (avantages, architecture, groupes de disponibilités, type de réplications de données, etc.).

 

icon_arrow AlwaysOn dans les fermes sharepoint 2013
Mise en pratique avec une implémentation d’AlwaysOn avec SharePoint, produit très consommateur de SQL Server et avec des topologies souvent complexes. L’idée ici est d’avoir une vision beaucoup plus orientée base de données et analyser les avantages mais aussi les impacts à utiliser AlwaysOn avec Sharepoint (création / supression d’applications, authentification, utilisation des connexions readonly, maintenance des bases de données, monitoring …)

 

Les informations de connexion vous seront communiqués la veille sur le site du GUSS. En espérant vous voir nombreux !

 

David BARBARIN (Mikedavem)
MVP SQL Server

Cluster Windows et fileshare quorum : comment changer le chemin de partage du quorum

Mis en avant

Sur une installation SQL Server 2012 Always-On avec un cluster composé d’un quorum nœuds et partage de fichiers majoritaire j’ai eu à changer le chemin de partage du quorum. Avec surprise j’ai pu m’apercevoir rapidement que le changement du chemin au travers de la console de gestion du cluster était bien pris en compte mais restait actif sur l’ancien partage. J’ai pu reproduire ce problème sur mon environnement de test

Voici donc la situation initiale :

image

 

image

 

Le partage réseau n’est plus accessible dans mon cas. Il faut donc trouver un nouveau path.

image

 

image

 

Cependant une fois configurée on peut remarquer que la nouvelle ressource est effectivement créée et pire que l’ancienne ressource est toujours utilisée comme faisant parti du quorum.

image 

 

A ce stade l’interface graphique ne nous empêche de supprimer la ressource concernée. Si on tente l’opération en passant par les cmdlets powershell du cluster nous nous heurtons également à un message d’erreur qui stipule qu’une ressource cluster core ne peut être supprimée.

image

 

Donc comment faire en sorte que notre changement de chemin soit pris en compte par le cluster. En réalité l’astuce consiste tout simplement à supprimer temporairement ce type du quorum de cluster et de revalider le nouveau chemin une nouvelle fois comme ceci :

image

 

image

 

Une fois le changement de quorum changé la ressource qui nous gênait a bien été supprimée.

image 

 

On peut également supprimé dans notre cas la ressource fileshare restante. Enfin il ne reste plus qu’à revalider notre type de quorum avec le nouveau chemin en suivant la procédure décrite un peu plus haut.

image

 

Bonne configuration de quorum !

 

David BARBARIN (Mikedavem)
MVP SQL Server

Virtualisation et SQL Server 2012 : disques non reconnus avec VSphere 5.X

Mis en avant

Lors d’une installation SQL Server 2012 chez un de mes clients j’ai été confronté à un problème surprenant. La machine virtuelle comportait 3 disques avec les partitions C, D et E et SQL Server ne reconnaissait uniquement que le premier disque. Après avoir cherché un petit moment et notamment des problèmes aux niveaux des permissions de compte de service SQL nous nous sommes aperçu que le problème venait en réalité des types de disques que VSphere présentait au système d’exploitation. Les disques D et E étaient vus comme périphériques amovibles ce qui peut être gênant pour SQL Server !!

L’astuce consiste donc à désactiver cette option au niveau de la machine virtuelle (devices.hotplug = false).

>> Le KB VMWARE pour plus de précision

 

Bonne installation !!

David BARBARIN (Mikedavem)
MVP SQL Server