Le blog technique

Symptômes

Les machines utilisant le protocole SMB1 (Windows XP, Windows Server 2003) pour accéder à un partage de fichier ne sont plus en mesure d’accéder à un partage hébergé sur un server Windows 2012 R2.

La mise en domaine de machines utilisant le protocole SMB1 (Windows XP, Windows Server 2003) échoue si le contrôleur de domaine utilisé est hébergé sous Windows Server 2012 R2.

Il est possible de récupérer le type de connexion SMB utilisé entre un client et un serveur avec la commande :

Get-SmbConnection

Cause

Par défaut, Windows Server 2012 R2 n’utilise pas le protocole SMB 1, bien que le driver le permettant est présent, il n’est pas chargé au démarrage.

En regardant le tableau suivant, on remarque que seuls les systèmes d’exploitation non-supportés utilisent le protocole SMB1 :

(http://blogs.technet.com/b/josebda/archive/2012/06/06/windows-server-2012-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-or-smb-3-0-you-are-using-on-your-file-server.aspx)

Résolution

Une clé de registre permet de réactiver l’utilisation du SMB 1.

Il faut modifier la valeur de la clé de registre DependOnService :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer

La valeur de la clé doit être modifiée de SamSS Srv2 à SamSS Srv.

La clé de registre permet de repositionner le protocole SMB 1 comme une dépendance du service “Server” :

Contexte

SQL Server Management Studio permet la création graphique de différents plan de maintenance qui permettent d’automatiser les tâches d’administration sur les différentes bases de données.

Parmi ces plan de maintenance il existe des tâches préconfigurées de backup des bases. Ces tâches de sauvegardes peuvent se révéler utiles, particulièrement si la solution de backup mise en place n’assure pas la “sauvegarde applicative”.

Cet article présente la mise en place d’un plan de maintenance permettant la sauvegarde FULL d’une ou plusieurs bases de données ainsi qu’un plan de maintenance permettant la suppression des jeux de sauvegardes créés en fonction de la rétention mise en place.

Prérequis à l’utilisation des plan de maintenance

L’exécution des plans de maintenance est réalisée par le service “SQL Server Agent”, il convient de valider que le service est configuré pour démarrer automatiquement depuis la console “services.msc” :

Automatiser une sauvegarde FULL

Depuis SQL Management Studio, naviguer vers “Management\Maintenance Plan” puis faire clique-droit, “New Maintenance Plan” :

Nommer le plan de maintenance :

A l’aide de la “Toolbox” présente à gauche de l’écran, glisser-déposer la tâche “Backup Up Database Task” :

Voici les différentes options de configuration d’une tâche de backup FULL :

1. Choisir la ou les bases de données à sauvegarder,

2. Choisir “Database’”,

3. Ne pas cocher cette case à cocher, la rétention sera gérée par une tâche de nettoyage,

4. Choisir “Back up to Disk”,

5. Choisir “Create a backup file for every database”

6. Il est possible de créer un répertoire par jeu de sauvegarde,

7. Indiquer le chemin racine de stockage des sauvegardes,

8. Indiquer l’extension “BAK”.

Automatiser le nettoyage des anciens jeux de sauvegarde

A l’aide de la “Toolbox” présente à gauche de l’écran, glisser-déposer, sous la tâche précédemment créée, la tâche “Maintenance Cleanup Task” puis relier les tâches comme dans la capture suivante :

Double-cliquer sur la Cleanup Task créée pour la configurer :

1. Sélectionner “Backup Files”

2. Choisir l’option de suppression des fichier présent dans un répertoire et disposant d’une extension spécifique,

3. Indiquer le répertoire racine de stockage des fichiers de sauvegarde,

4. Indiquer l’extension utilisée par les fichier de sauvegarde (“BAK” dans le cas présent),

5. Eventuellement inclure les premiers niveaux de répertoires dans la recherche dans le cas où un sous-répertoire a été créé pour chaque base de donnée sauvegardée,

6. Cocher la case “Delete files based on the age of the file at task run time” et indiquer la rétention souhaitée.

Planifier l’exécution automatique du plan de maintenance

Depuis le sous-plan de maintenance créé, cliquer sur le calendrier :

Configurer les type de planification souhaitée :

1. Choisir la planification “Recurring” et cocher la case “Enabled”,

2. Choisir le type de fréquence souhaitée,

3. Sélectionner le type de fréquence journalière souhaitée.

Après avoir planifié le plan de maintenance, un nouveau Job apparait sous “SQL Server Agent”.

Contexte

Migration de l’emplacement d’un FileShare Witness utilisé par un cluster.

Dans le cadre d’une configuration cluster Microsoft Cluster avec un nombre pair de noeuds, l’un des modèles utilisé afin d’assurer une majorité dans le quorum est le “Node and File Share Majority”. Cette méthode – peu couteuse en espace – permet d’utiliser un partage de fichier comme témoin.

Le partage stocke uniquement les information

Cet article présente comment migrer l’emplacement d’un partage  témoin utilisé par un cluster, il s’applique également à tout produit utilisant la technologie Microsoft Cluster.

Modification de la configuration du cluster

1. Afin de récupérer la configuration existante du cluster, il faut exécuter la commande PowerShell suivante :

Get-ClusterQuorum NOMDUCLUSTER

Actuellement, le type de quorum qui devrait s’afficher est “NodeAndFileShareMajority”.

2. Nous allons modifier la configuration du cluster de manière à le passer en “NodeMajority” à l’aide de la commande suivante :

Set-ClusterQuorum –cluster NOMDUCLUSTER –NodeMajority

La commande ci-dessus passe la configuration du cluster à “NodeMajority”, cette configuration est déconseillée lorsqu’un un nombre pair de noeuds est présent dans le cluster.

Valider depuis la console “Failover Cluster Manager Administrative Tool” que la nouvelle configuration a bien été prise en compte puis continuer.

3. La dernière étape va permettre de configurer le cluster en mode “NodeAndFileShareMajority” en indiquant le nouveau partage de fichier à utiliser :

Set-ClusterQuorum –cluster NOMDUCLUSTER –NodeAndFileShareMajority \\NOUVEAU PARTAGEDEFICHIER

Vérification

Valider depuis la console “Failover Cluster Manager Administrative Tool” que la nouvelle configuration a bien été prise en compte, il faut également valider au niveau du partage de fichier qu’une permission “NOMDUCLUSTER$” a bien été créé automatiquement :