PI Services

Le blog des collaborateurs de PI Services

ADFS : customisation des revendications Active Directory

Introduction

Active Directory Federation Services (ADFS) permet de transmettre n'importe quel attribut d'un objet Active Directory à un partenaire par le biais d'une fédération. Cela reste facilement paramétrable via l'interface de gestion ADFS Management (ce paramétrage sera d'ailleurs détaillé dans la suite de cet article).

Cependant, il peut arriver que l'on souhaite transformer un attribut Active Directory en réalisant notamment des manipulations de chaines de caractères. Dans cet article nous étudierons le cas de l'attribut ObjectGuid qui est envoyé de manière encodée (en base 64) et dont le but sera de le transmettre sous la forme standard (exemple : {3F2704E0-4289-11D3-9B0C-0305E92C1301}). Il est aussi possible d'imaginer d'autres cas d'usage comme : mettre en majuscule un attribut, tronquer une chaîne de caractère...

Cette opération se réalise en deux étapes :

  • Le développement d'une DLL contenant l'opération de transformation de l'attribut.

  • Le déploiement de cette DLL sur un environnement ADFS. Cette dernière sera utilisé au travers d'un "custom attribute store" ADFS en conjonction avec une règle personnalisée de transformation de revendications lors de la configuration de la fédération.

Pour réaliser toutes ces manipulations, il est nécessaire d'avoir un environnement ADFS déjà opérationnel ainsi que Visual Studio (en version 2013 ou supérieure).

Les notions de développements abordées pendant cet article sont très accessibles y compris pour quelqu'un ne développant pas. Le langage utilisé est le C#.

En bonus, vous trouverez une petite application console permettant de tester les attributs retournés par vos fédérations.

NB : Cette article a été rédigé à partir d'une infrastructure ADFS 3.0 (Windows 2012 R2) et de Visual Studio 2015. Il est inspiré d'un article de Tino Donderwinkel : ici.

Fonctionnement

Tout d'abord, voici le principe de fonctionnement lorsqu'une nouvelle revendication doit être transmise à une fédération :

  • Une règle basée sur le template LDAP récupère l'attribut AD que l'on souhaite transmettre.

  • Une règle personnalisée traite la première revendication et la retourne dans une deuxième revendication après qu'elle ait subit sa transformation via une méthode appelée dans un custom attribute store

Le custom attribute store est composé d'une DLL qui contiendra toutes nos méthodes permettant de transformer des revendications. En effet, dans cet article nous modifions une revendication provenant d'un annuaire Active Directory mais celle-ci peut très bien être issue d'un autre référentiel puisque notre custom attribute store traite une revendication et non un attribut LDAP.

Le développement du custom attribute store nécessite d'implémenter des références à une DLL ADFS. Cela passe par l'ajout d'une DLL contenu dans le répertoire d'ADFS. Cette dernière contient 3 méthodes qu'il faut implémenter :

  • Initialize : Elle permet de fournir des paramètres de configuration à l'attribute store. Elle ne sera pas utiliser dans notre cas.

  • BeginExecuteQuery : Cette méthode contient une reqête sur l'attribute store. Cela sera modélisé par une méthode de transformation de notre attribut.

  • EndExecuteQuery : Elle est appelé lorsque la méthode EndExecuteQuery a terminé son exécution. Elle prend en paramètre le résultat retourné par la méthode précédente.

Prérequis

Pour développer un nouvel attribute store, il faut copier la DLL nommée “Microsoft.IdentityServer.ClaimsPolicy.dll” depuis un serveur ADFS sur l'ordinateur où Visual Studio est installé (celle-ci est située dans “C:\Windows\ADFS”).

Développement

Lorsque le prérequis est rempli, nous pouvons lancer Visual Studio est créer un nouveau projet via le bouton “File” puis “New” et enfin “Project”.

01

Dans la section “template”, on choisit la catégorie Visual C# et le modèle bibliothèque de classes (“Class Library”). La version 4.5 du Framework .Net ainsi qu'un chemin pour stocker les fichiers doivent être définies.

02

Le fichier qui nous intéresse le plus et le fichier “Class1.cs” qu'il est possible de renommer via un clic droit puis “Rename” en oubliant pas de valider la popup suivante permettant de modifier toutes les références à ce fichier dans notre projet.

03bis

04

Nous devons ensuite ajouter des références à notre projet. Pour rappel, ces dernières vont nous permettre de communiquer avec l'infrastructure ADFS en joignant entre autre la DLL précédemment copiée (“Microsoft.IdentityServer.ClaimsPolicy.dll”).

Cette première dépendance s'ajoute en effectuant un clic droit sur le champ “References” dans le menu de droite (Solution Explorer) puis en cliquant sur “Add Reference”.

05

Il faut choisir l'onglet “Browse” et enfin se rendre à l'emplacement de la DLL et la sélectionner

06

La seconde dépendance s'ajoute de la même manière Il s'agit de “System.IdentityModel”. Il est seulement nécessaire de se rendre dans le menu “Assemblies” au lieu de “Browse”.

07

Enfin, on ajoute les lignes de codes ci-dessous dans le fichier de classe.

Cela permet d'indiquer les références utilisées dans la classe.

Une fois les références ajoutées, il faut implémenter les méthodes explicitées dans le paragraphe précédent. Pour se faire, on doit ajouter ce qu'on appelle une interface à notre classe. Cela nous donnera accès aux méthodes permettant d'interagir avec ADFS. Notre classe représente l'attribute store que l'on souhaite créé.

Pour ajouter l'interface, il suffit d'ajouter “ : IAttributeStore” après “public class CustomStringAttributeStore”. Un avertissement est levé car Visual Studio ne trouve pas le code permettant de dire que notre classe est un attribute store (il cherche les 3 méthodes évoquées précédemment). Pour corriger cela, il suffit de faire un clic droit sur “IattributeStore” puis de cliquer sur “Implement Interface”. Le code de base pour les 3 méthodes est automatiquement généré.0910

Ci-dessous, vous trouverez le code pour chacune d'entre elles.

Initialize :

BeginExecuteQuery :

Il s'agit de la méthode où se déroule toute la logique de transformation. La section la plus importante est contenue à l'intérieure de la structure logique Switch. En fonction de la requête demandée, une transformation sera appliquée. Dans notre exemple, je n'ai qu'un seul cas possible, mais on peut améliorer cet attribute store afin qu'il contienne toutes les règles de transformations dont nous avons besoin.

NB : Une méthode Base64ToGuid est appelée dans le case Base64ToGuid. Cette méthode permet de convertir en chaîne lisible, le Guid d'un objet AD qui est normalement encodé en base 64.

EndExecuteQuery :

Le lien suivant mène vers le code complet de la classe : ici

Il suffit ensuite de générer la DLL en passant par le menu “Build” puis en cliquant sur “Build Solution”. La DLL est générée dans le sous répertoire “bin\Debug” du projet défini lors de la création. Par défaut il s'agit du chemin “C:\Users\nom_d'utilisateur\Documents\Visual Studio 2015\Projects”.

Déploiement

Une fois la DLL copiée, il faut la copier sur tous les serveurs ADFS dans le répertoire “C:\Windows\ADFS” (Attention : La DLL ne doit pas être déployée sur les serveurs Web Application Proxy). On peut ensuite passer à la configuration qui se fait via la console ADFS Management.

Configuration du Custom Attribute Store

Dans la section "Trust Relationship", effectuer un clic droit sur “AttributeStore” et cliquer sur “Add Custom Attribute Store”.

Une popup s'ouvre. Il faut renseigner le champ “Custom attribute store class name”. Ce champ doit être rempli avec attention et nécessite une syntaxe particulière :

Namespace.Classe,Nom_du_fichier_dll

Namespace : il s'agit du nom indiquer à côté de ce mot clé dans notre fichier de classe (Ici : CustomStringTransformAttributeStore).

Classe : Le nom de la classe (Ici : StringTransform)

Nom_du_fichier_dll : le nom de la DLL sans son extension (ici : CustomStringTransformAttributeStore)

11

Lorsque la configuration est validée, un évènement 251 apparait dans le journal Admin d'ADFS (dans la catégorie Applications and Services de l'observateur d'évènements). Lorsqu'il y a une erreur de configuration, un évènement avec l'ID 159 est présent.

Configuration de la fédération de test

Nous allons maintenant créer une fédération de test. Celle-ci ne doit pas forcément pointer vers un service réel. L'outil fourni dans le chapitre suivant permettra de générer des tokens. Dans la section Trust Relationship, il faut se rendre dans la section “Relying Party Trusts” puis choisir l'option “Add Relying Party Trust”.

01

Cliquez sur le bouton “Start” après l'ouverture de l'assistant. Choisir l'option “Enter data about the relying party manually”.

02

Insérez un nom pour la fédération puis cliquez sur “Next”.

03

Cliquez sur “Next” sur les onglets suivants jusqu'à “Configure Identifiers”. Entrez une url dans le champ “Relying party trust identifier” puis cliquez sur “Add”. Cette url n'a pas besoin de répondre.

04

Il faut ensuite cliquez sur suivant jusqu'à la fin de l'assistant en laissant cocher la case “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes”. Cela nous permettra d'ajouter nos règles sur les revendications dès la création de la fédération (sinon, il vous faudra faire un clic droit sur la fédération et choisir “Edit Claim Rules”).

05

Dans l'assistant d'édition des règles de revendications, nous allons ajouter deux règles dans l'onglet “Issuance Transform Rules”. Pour se faire cliquez sur “Add Rule”.

06

Dans l'assistant, nous ajoutons une première règle qui va récupérer un attribut LDAP. On sélectionne donc le modèle “Send LDAP Attributes as Claims”.

7

On peut ensuite définir un nom puis choisir “Active Directory” en tant qu'attribute store. Enfin, on entre l'attribut LDAP qui nous intéresse pour la colonne “LDAP Attribute” (il peut être inséré à la main s'il n'est pas présent dans la liste comme c'est le cas pour “objectGUID”) puis on choisit une valeur pour “Outgoing Claim Type” (ici, j'ai choisi “Common Name”).

8

On ajoute ensuite une seconde règle qui va utiliser notre custom attribute store. Cette fois-ci le template à utiliser est “Send Claims Using a Custom Rule”. On défini ensuite un nom et on peut insérer le code suivant dans le champs “Custom Rule”.

9

Cette règle récupère la revendication “CommonName” que nous avons défini précédemment en tant que revendication de sortie de notre annuaire Active Directory et la transmet à notre custom attribute store (elle est retournée en tant que revendication de type “nameidentifier” en lui appliquant la méthode Base64ToGuid qui correspond au cas que l'on a défini dans notre classe “Transform.cs”. Il est bien entendu possible de changer les revendications, la requête ou le nom du custom attribute store en fonction de vos valeurs.

Test

Afin de tester vos fédérations, je met un outil console à disposition que j'ai développé et que vous pouvez récupérer via le lien suivant : ici. Il sera utile pour valider le bon fonctionnement de notre custom attribute store mais il vous permettra aussi de voir les revendications envoyées à vos partenaires pour n'importe laquelle de vos fédérations. En plus de ce dernier vous devez avoir dans le magasin racine de confiance, le certificat permettant de signé les tokens d'authentification (Token-Signing). Dans un déploiement par défaut, il est auto-signé.

L'outil est composé d'un .exe et d'un fichier .config. Ce dernier doit être rempli. Les paramètres à changer sont :

  • relyingPartyId : il s'agit de l'url d'accès à la fédération (le champ "identifier") : https://adfstest.myenterprise.com/adfs/services/trust.

  • adfsEndpoint : il s'agit du point d'accès pour effectuer l'authentification (exemple : https://fs.myenterprise.com/adfs/services/trust/13/windowsmixed). Le programme se base sur l'authentification windows. L'url “/trust/13/windowsmixed” doit être active sur l'infrastructure ADFS. Pour se faire, il faut se rendre dans la catégorie “Endpoints” de la console de gestion ADFS, puis effectuer un clic droit et choisir “Enable” sur cette url.

  • certSubject : La valeur doit être celle du champ objet du certificat de type Token-Signing. Exemple : CN = ADFS Signing - fs.myenterprise.com.

Une fois l'outil paramétré, il suffit de le lancer l'exécutable. Ce dernier affiche toutes les revendications par un couple "Nom de la revendication : valeur". Voici un exemple de résultat obtenu :

10

On remarque qu'on obtient bien les deux revendications représentant le GUID, l'une le représentant sous forme d'une chaîne de caractère et l'autre encodé en base 64 (la revendication originale). Notre custom attribute store est donc bien opérationnel.

Si l'on souhaite ajouter de nouvelles transformations de revendications, il suffit maintenant d'ajouter des cas supplémentaires dans la classe et de la redéployer.

Orchestrator – Requête du dernier status de tout les runbooks

Cette requête SQL affiche le dernier status d’exécution de tout les runbooks d’une instance, triés par dernière date d’exécution.

--***REQUETES DES DERNIERS STATUS D'EXECUTION DE TOUT LES RUNBOOKS TRIES PAR DATE D'EXECUTION AVEC UN FILTRE SUR LE NOM DES RUNBOOKS ***/ --*** NB: Ajouter un critere sur RL.Name pour un job spécifique (ex: RL.Name = 'My_job') USE ORCHESTRATOR SELECT RL.Name as RunbookName, MAX(RI.CompletionTime)as dernieredate INTO TEMP_ALL_JOB_LAST_STATUS FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId WHERE ((RL.Name NOT LIKE '%OLD%') AND (RL.Name NOT LIKE '%TEST%')) GROUP BY RL.Name ORDER BY RL.Name; SELECT RunbookName, dernieredate as Derniere_date_Execution, RI.Status as Dernier_Status FROM [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI INNER JOIN [Orchestrator].[Microsoft.SystemCenter.Orchestrator].Runbooks as RL ON RL.Id=RI.RunbookId INNER JOIN TEMP_ALL_JOB_LAST_STATUS ON TEMP_ALL_JOB_LAST_STATUS.RunbookName=RL.Name and dernieredate = RI.CompletionTime ORDER BY Derniere_date_Execution DESC GO DROP TABLE TEMP_ALL_JOB_LAST_STATUS

Script de rapport des erreur 500 sur IIS

 

Ce script génère un rapport texte des erreurs 500 en parsant les logs IIS d’une liste de serveurs. (Lien du script plus bas).

#SCRIPT REMONTANT LES OCCURENCES DES ERREURS '500' DANS LES LOGS IIS DE PLUSIEURS SERVEURS #INTERVALLE DE TEMPS PAR DEFAUT: Journée d'hier ($firstdate --> $date) #MODIFIER EN FONCTION, LE COMPTE UTILISE ($cred), LE CHEMIN DU RAPPORT ($rapport), LES NOMS DES SERVEURS ($FrontServers), LE CHEMIN DES LOGS ($Logpath) # #PAR DEFAUT L'INTERVALLE DE TEMPS EST CELUI DE LA JOURNEE DE LA VEILLE. $cred= Get-Credential -Credential "MYDOMAIN\" $rapport = "D:\Temp\error500.txt" $date = (get-date).Date $firstdate = (get-date).Date.AddDays(-1) $FrontServers=("SERVEUR1","SERVEUR2","SERVEUR3","SERVEUR4") $Logpath="c$\inetpub\logs\logfiles" $Header= "########### ERREURS 500 SUR LES FRONTAUX IIS ( $firstdate ---> $date ) ############## ######################################################################################################################" #suppression fichier rapport if (Test-Path $rapport) { Remove-Item $rapport } #ajout de l'entete au rapport $Header | Out-File -FilePath $rapport "" | Out-File -FilePath $rapport -Append "" | Out-File -FilePath $rapport -Append Function Get-Error500 ($Front,$cred) { #chaine 500 (!entourée de deux espaces!) $pattern=" 500 " New-PSDrive -Name "$Front`_drive" -Credential $cred -Root \\$Front\$Logpath -PSProvider FileSystem | Out-Null $logs= Get-ChildItem -Path "$Front`_drive:\*.log" -Recurse | Where-Object {$_.LastWriteTime -ge $firstdate -AND $_.LastWriteTime -lt $date} | Select-Object foreach ($log in $logs) { write-host -BackgroundColor White -ForegroundColor Blue "LOG: $log" "LOG: $log" | Out-File $rapport -Append "" | Out-File $rapport -Append get-content -Path $log | Select-String -Pattern $pattern | Select-Object -Property Line | Out-File $rapport -Append } Remove-PSDrive -Name "$Front`_drive" -Force } foreach ($Front in $FrontServers) { Write-Host -ForegroundColor Yellow "----SERVEUR $Front---- :" "----SERVEUR $Front---- :" | Out-File -Append $rapport Get-Error500 -Front $Front -cred $cred Write-Host "" Write-Host "***************************************************************************************************************" Write-Host "" "" | Out-File -Append $rapport "***************************************************************************************************************" | Out-File -Append $rapport "" | Out-File -Append $rapport }

 

Disponibilité de Nagios XI 5

 

Depuis début octobre, la version 5 de Nagios XI est disponible.

Fort d’une communauté historique issue de la version Core et d’une énorme base de plugins, cette version propose les évolutions suivantes:

- De nouveaux assistants pour le déploiement des objets et des configurations.

- Des nouveaux templates de supervision.

- Une meilleur interaction avec les systèmes environnants

- Une nouvelle API

- Une amélioration du support de l’internationalisation

- Un système de notification mail amélioré

 

Pour plus de détails:

https://www.nagios.com/xi5/

Provisionner des VHDs et VM Nano Server via le Tool NanoServerBuild

 

Dans ce blog, nous allons voir comment provisionner des VHDs / VM Nano Server à l’aide de l’outil NanoServerBuild.

 

Celui ci va nous permettre de générer un nombre souhaité de VHDs nano servers avec ajout des features et configuration des unattends.

 

Eventuellement, des VMs pourront être créées linké aux différents VHDs créés

(si l’outil est exécuté depuis un hyperviseur.)

 

Pré requis

 

Pour lancer l’outil, .NET 3.5 doit être installé sur votre ordinateur.

L’OS doit être en 64bits.

Positionner la politique d’exécution PowerShell sur Unrestricted:

Set-executionPolicy Unrestricted

 

 

 

Présentation de l’outil

 

Disponible à cette adresse:

https://onedrive.live.com/?cid=b370cc46ea3ab572&id=B370CC46EA3AB572%21137&authkey=%21ANkLug_PPC-kh-8

 

La version 1.0 ne sera disponible que lorsque la release Windows Server 2016 RTM sera sortie.

 

L’outil NanoServerBuild va vous permettre de provisionner simplement et rapidement des VHD(s) / VM Nano Server 2K16.

 

 

Lancer l’outil en tant que administrateur

 

image

 

 

 

L’interface se lance

 

image

 

 

 

 

Dans la section Path, vous devez sélectionner l’emplacement où se trouve les sources du Nano Server pour sa construction.

image

 

 

(Par défaut présent à la racine du média d’installation Windows Server 2016 TP2 et TP3)

 

image

 

 

 

 

La section VHDX vous permet de spécifier les paramètres de configuration pour votre VHD :

 

  • Son emplacement
  • Son nom
  • Sa taille
  • Son type Fixed/Dynamic
  • Son initialisation MBR/GPT

image

 

 

 

Vous pourrez retrouver ici les différents packages présent dans le Path Nano Server précédemment définie pouvant être intégré dans votre VHD Nano pour sa construction.

 

image

 

 

 

Cette fenêtre vous indiquera les éléments manquant pouvant empêcher la construction de votre VHD NanoServer.

 

image

 

 

 

Cette section va vous permettre de :

  • Choisir le nombre de VHDs Nano Server que vous souhaitez créer
  • Démonter le/les VHDs une fois les opérations effectuées
  • Créer des VMs linké à vos VHDs Nano Servers
  • Choisir la mémoire vive à affecter à vos VMs

 

image

 

 

 

La section XML vous permet de configurer et d’appliquer un fichier unattend à vos VMs.

 

image

 

 

 

 

La section copy in.. vous permet de copier le contenu d’un répertoire dans vos VHDs Nano Servers dans \windows\setup\script.

Ainsi vous pouvez par exemple provisionner des scripts qui s’appliqueront à vos Nano Servers en fonction des hostnames affectés.

 

 

image

 

 

 

 

Démonstration

 

Sélectionner le Path de votre répertoire Nano Server

 

image

 

 

Les Features disponibles s’affichent

 

image

 

 

 

 

 

Rappel sur les Features disponible

 

image

 

 

Nous allons sélectionner les packages nécessaire pour que nos VHDs Nano Server soient des VMs qui jouent le rôle de serveur SOFS hébergé au sein d’un cluster.

Sélectionner Guest, FailoverClusters et Storage.

 

 

image

 

 

 

Dans l’exemple ci-dessous, nos VHDs s’appelleront MonNano-XXX (XXX car plusieurs VHDs seront créés).

Ils seront créés à la racine du lecteur C avec une taille de 5GB. Les VHDs seront de type Dynamic et initialisé en MBR.

 

image

 

 

 

Nous allons créer 3 VHD qui ne seront plus montés dans l’explorateur à la fin des opérations.

Nous allons pour chacun de ses VHDs créés, les affecter à des VMs sur notre Hyperviseur avec une taille de 1024Mo pour la mémoire vive.

(La coche New-VM n’est disponible que si l’outil est exécuté sur un Hyperviseur).

 

image

 

 

 

Actuellement, aucune VM n’est présente sur notre Hyperviseur.

 

image

 

 

Sélectionner les valeurs désirés pour votre unattend

 

image

 

 

 

Attention si vous utilisez la rubrique XML :

  • Si vous ne définissez pas de mot de passe, le mot de passe par défaut sera "nano".
  • Si vous ne cochez pas la case ComputerName, chacun de vos VHDs auront pour ComputerName "nano".
  • Si vous cochez la case ComputerName, vos VHD auront pour nom la valeur que vous aurez saisie dans la rubrique VHDX + un incrément basé sur le nombre de VMs que vous allez créer.                          

Exemple : dans notre cas 3 VM seront créés avec le nom MonNano soit : MonNano-1, MonNano-2 et MonNano-3.

 

 

Le bouton aperçu vous permet d’avoir un aperçu du fichier unattend qui sera appliqué avec vos saisies.

 

image

 

 

Exemple:

 

image

 

 

Si vous souhaiter copier le contenu d’un répertoire dans \windows\setup\scripts de vos VHDs, sélectionner alors un répertoire.

 

image

 

 

 

Cliquer sur Go pour lancer les opérations.

 

image

 

 

 

Une fois les traitements finis, votre Hyperviseur disposera de vos VM Nano Servers.

 

image

 

 

 

 

Le contenu de vos VHDs avant leurs démarrages :

 

 

Présence du fichier unattend

 

 

 

clip_image001

 

 

 

 

 

Données copiées dans le répertoire \Windows\Setup\script

 

 

clip_image002

 

 

 

Aperçu des VMs démarrées.

 

 

clip_image002

 

 

clip_image004

 

 

clip_image006

 

 

Enjoy ! Punk

Accès impossible à un serveur de fichier WS 2012 R2 depuis une machine XP ou WS 2003

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 :

image

(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” :

image

SQL Server – Créer un plan de maintenance pour automatiser les sauvegardes

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” :

image

Automatiser une sauvegarde FULL

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

image

Nommer le plan de maintenance :

image

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

image

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

image

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 :

image

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

image

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 :

image

Configurer les type de planification souhaitée :

image

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”.

Migrer un partage témoin utilisé par un cluster Microsoft Cluster

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 :

image