PI Services

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.

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

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/

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

L’interface se lance

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

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

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

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.

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

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

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

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.

Démonstration

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

Les Features disponibles s’affichent

Rappel sur les Features disponible

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.

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.

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

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

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

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.

Exemple:

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

Cliquer sur Go pour lancer les opérations.

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

Le contenu de vos VHDs avant leurs démarrages :

Présence du fichier unattend

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

Aperçu des VMs démarrées.

Enjoy !

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 :

Des alertes « Operations Manager Failed to Access the Windows Event Log” concernant des journaux d’événements Veeam Vmware (nWorks) et provenant de serveurs de management (MS) apparaissent :

Elles sont complétées par des événements 26604 récurrents (toutes les 12 minutes) dans les Event Log de ces serveurs :

The Windows Event Log Provider is still unable to open the Veeam VMware event log on computer 'SRV0'. The Provider has been unable to open the Veeam VMware event log for 1440 seconds.

Most recent error details: The specified channel could not be found. Check channel configuration.

One or more workflows were affected by this.

Workflow name: Veeam.Virt.Extensions.VMware.VMGUEST.CollectEvents

Veeam a publié une KB concernant ce problème : http://www.veeam.com/kb1496#/kb1496

Les causes indiquées dans cette dernière ne semblent pas correspondre au contexte rencontré dans mon cas (les alertes apparaissaient sur deux nouveau MS physiques fraichement ajoutés), mais la solution proposée fonctionne malgré tout :

Dans la console Veeam, exécuter une reconstruction de la topologie Rebuild Full Topology :

Rien n’indiquera que la reconstruction est terminée, mais cela peut prendre plusieurs dizaines de minutes voire plusieurs heures selon la taille de votre infrastructure, mais lorsque cela sera bon les événements 26004 ne doivent plus revenir dans l’Event Log.

Il restera enfin à réinitialiser manuellement les moniteurs en erreur :

D’origine, il est possible via les common Published Data de récupérer dans n’importe quel runbook Orchestrator l’ID d’une activité ou d’un process :

On peut même récupérer l’ID de l’instance en cours d’exécution (Job ID) d’un runbook enfant lorsqu’il est appelé via l’activité Invoke Runbook :

Par contre, il n’y a rien de prévu pour récupérer l’ID de l’instance en cours d’exécution du runbook courant.

Ce Job ID du runbook courant peut cependant avoir son utilité, par exemple à des fins de logging et debug. Dans mon cas, il s’agissait de récupérer le nom de la personne ayant démarré le runbook via le portail self-service EUPSCO.

Il est donc malgré tout possible de récupérer cet ID, en intégrant la requête SQL suivante dans une activité Query Database :

SELECT POLICYINSTANCES.JobID
FROM  POLICYINSTANCES INNER JOIN
ACTIONSERVERS ON POLICYINSTANCES.ActionServer = ACTIONSERVERS.UniqueID
WHERE     (POLICYINSTANCES.ProcessID = <Activity process ID from "Initialize Data">) AND (ACTIONSERVERS.Computer = '<Runbook Server name from "Initialize Data">') AND (POLICYINSTANCES.Status IS NULL)

Explication : cette requête interroge la base de données en lui fournissant l’Activity Process ID (qui est disponible nativement via les Common Published Data) afin de retrouver quel JobID contient cet Activity PRocess ID.

Il peut toutefois arriver que le Process ID soit présent plusieurs fois à l’identique dans la base, c’est pourquoi on filtre un peu plus en indiquant le nom du serveur qui exécute le runbook (Runbook Server Name dans les Common Published Data) et surtout en spécifiant le status « NULL », c’est-à-dire que l’on ne recherche que parmi les runbooks qui sont en cours d’exécution et qui n’ont donc pas encore un statut “success”, “warning” ou “failed”

Si tout s’est bien passé, le champ Full line as a string with fields separated by ‘ ;’ présent en sortie de l’activité Query Database devrait contenir le JobID de votre instance de runbook en cours d’exécution, à vous de le réutiliser à votre guise plus loin dans votre runbook !

Nous allons dans ce blog créer un cluster SOFS en utilisant  Storage Spaces Direct (S2D).

Les nœuds du cluster seront des Windows Server 2016 Nano.

Ce blog n’a pas pour vocation de configurer le cluster dans des best practices ( RDMA, réseau CSV, …), mais seulement de présenter l’intégration de S2D dans le cluster.

Pour rappel, Storage Spaces Direct permet de créer un stockage hautement disponible avec le stockage local du serveur. C’est une grande avancée dans le modèle Software Define Storage (SDS) qui va simplifier la gestion des serveurs Hyperconvergés et permettre l’utilisation de certains types de disques comme les disques SATA, les disques NVME, qu’il n’était pas possible d’utiliser précédemment dans les Storage Space Cluster sous Windows 2012.

Notre Cluster sera constitué de 4 nœuds : Nano1, Nano2, Nano3 et Nano4 avec chacun deux disques disponible.

Ajouts des serveurs Nano dans le domaine

Depuis un contrôleur de domaine, on provisionne nos 4 serveurs via la commande djoin /provision.

Exemple :

djoin.exe /provision /domain labo.local /machine NanoX /savefile C:\odjblobNanoX

Copier les fichiers respectifs générés sur les serveurs Nanos (via les partages administratifs par exemple).

Ensuite, on se connecte sur les 4 serveurs Nano depuis l’hyperviseur via PowerShell Direct (nécessite Windows 10 ou Windows Server 2016 pour cette méthode) afin de les intégrer dans le domaine via la commande djoin /requestodj.

Exemple :

djoin /requestodj /loadfile C:\odjblobNanoX /windowspath c:\windows /localos

Et on reboote les serveurs.

Désormais, les 4 serveurs Nanos sont dans le domaine.

Exemple pour Nano1

Maintenant, depuis une machine disposant des outils RSAT FailoverClusters 2K16 dans le domaine, on créé le cluster Cluster-Nano avec les nœuds Nano1, Nano2, Nano3 et Nano4.

New-Cluster -Name "Cluster-Nano" -Node Nano1, Nano2, Nano3, Nano4 –NoStorage

Depuis la MMC Failover Cluster, on peut désormais voir notre Cluster-Nano.

Activation du Storage Space Direct sur le cluster

Il faut activer au niveau du cluster la fonctionnalité Storage Space Direct via la commande suivante :

Get-cluster Cluster-Nano | Enable-ClusterStorageSpacesDirect

Les DAS de vos nœuds sont visibles dans Enclosures.

Création du Storage Pool et du Virtual Disk

Nous allons maintenant générer un Storage Pool depuis nos disques locaux des nœuds du cluster.

Spécifier un nom de Storage Pool

Sélectionner les disques devant participer au Storage Pool (ici sont affichés les 2 disques * 4 nœuds soit 8 disques)

Le Storage Pool est désormais créés.

Nous allons maintenant créer un Virtual Disk sur ce Storage Pool.

Clic droit sur le Pool et New Virtual Disk

Sélectionner votre Storage Pool précédemment créé.

Donner un nom à votre virtual Disk

Dans notre exemple, nous allons créer un miroir avec une taille de 12 GB

Cocher la case Create a volume when this wizard closes

Créer maintenant le volume. Cliquer sur Next

Sélectionner le disque disponible présent au sein du cluster

Allouer toute la capacité disponible au volume.

N’affecter pas de lettre de montage (inutile car il s’agira d’un volume CSV)

Donner un label et formater en ReFS

La ressource disque est maintenant disponible.

Ajouter ce disque en tant que CSV.

Désactiver l’intégrité sur le CSV

Set-FileIntegrity C:\ClusterStorage\Volume1 –Enable $false

Ajout du role SOFS dans le cluster

Si désormais vous souhaitez ajouter le rôle SOFS au cluster, vous aurez un message d’erreur.

Vous devez pour cela activer sur les nœuds du cluster la feature File-Services car actuellement celle-ci est désactivée.

Ajout de la feature sur les nœuds :

invoke-command -computer nano1 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano2 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano3 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

invoke-command -computer nano4 -scriptblock {Get-WindowsOptionalFeature -online -featureName File-Services | Enable-WindowsOptionalFeature -online}

Désormais, vous pouvez ajouter votre rôle SOFS.

Il ne vous reste plus qu’à ajouter des partages de fichiers de type SMB Share –Applications sur le CSV reposant sur du Storage Space Direct et vous pourrez héberger vos VMs.

(Après avoir bien entendu relié le tout via du SMB 3 en exploitant le MultiChannel et le RDMA. )