Symptôme

Suite à la mise en place de la supervision SCOM sur une plateforme Exchange 2010 SP2 RU5v2, des erreurs se produisent toutes les 5 minutes sur les serveurs jouant le rôle CAS.

Ces erreurs ont pour source MSExchange Control Panel et correspondent aux ID 4 et 38. Voici le détail de l’erreur 38 (avec en rouge les éléments intéressants) :

Du côté de IIS, une erreur 500 est déclenchée et visible dans les logs W3C.

Explication

Ces erreurs se produisent à intervalles réguliers (toutes les 5 minutes) lorsque le compte de service utilisé par SCOM (extest_<id>) tente d’exécuter la commande PowerShell Test-EcpConnectivity.

Lorsque l’on effectue des recherches sur ces erreurs ont tombe très rapidement sur une fiche support indiquant qu’il s’agit d’un bug Exchange 2010 résolu dans la mise à jour RU3v3 du SP1 d’Exchange 2010.

Unnecessary events are logged in the Application log when you run the "Test-EcpConnectivity" cmdlet in an Exchange Server 2010 environment
http://support.microsoft.com/kb/2494389/en-us

Néanmoins dans notre cas, l’environnement est déjà mis à jour en version SP2 RU5v2 ce qui rend cette solution caduque.

Après investigation il s’avère que la commande Test-EcpConnectivity ne supporte pas les URL possédant des majuscules.

La solution au problème consiste à modifier les URL internes et externes du service Web ECP (Exchange Control Panel) de manière à remplacer le /ECP par un /ecp.

Ce problème est donc totalement indépendant de la supervision SCOM qui est dans ce cas un simple révélateur du problème (car SCOM exécute régulièrement la cmdlet Test-EcpConnectivity).

Résolution

Dès la correction des URL (via la cmdlet Set-EcpVirtualDirectory), les erreurs ne se produisent plus et il est possible d’exécuter sans erreur la commande Test-EcpConnectivity.

Remarque : La correction prend effet immédiatement. Un petit délai peut être nécessaire dans certains environnements, le temps que la réplication Active Directory ait lieu. Il n’est pas nécessaire de redémarrer IIS.

Cette solution a déjà été testée avec succès sur plusieurs environnement Exchange 2010 SP2.

L’une des principales utilité des GPOs est d’automatiser des tâches sur un large panel d’utilisateurs (ou d’ordinateur) évitant ainsi à l’administrateur de perdre un temps précieux…

Le déploiement des imprimantes fait partie de ces tâches qui peuvent être un tracas logistique sans l’utilisation des GPOs.

La première étape est la création d’une nouvelle GPO à l’aide de la console “Group Policy Management” dans l’OU où celle-ci s’appliqueras :

Une fois la nouvelle GPO créée, ouvrez la console “Print Management”, sélectionnez l’imprimante à déployer via GPO et cliquez sur “Deploy with Group Policy” :

La fenêtre “Deploy with group policy” apparait, cliquez sur “Browse” puis sélectionnez la GPO créée puis cliquez sur OK :

Les habitués des GPOs savent sans doute qu’une GPO peut être appliquée au niveau utilisateur, ordinateur ou les deux.

Ce choix dépend de votre organisation interne, j’ai pour ma part choisi le déploiement par utilisateurs :

Il faut ensuite cliquer sur “Add” puis sur OK.

A ce niveau l’imprimante est déployée sur les clients à partir de Windows Vista.

Pour la gestion des clients XP, il est nécessaire de passer par une étape supplémentaire car contrairement aux client 7, Vista et 8 qui utilisent “gpprnext.dll” les clients XP et les serveurs antérieurs à Windows Server 2003 utilisent PushPrinterConnections.exe.

Retournons dans la console Group Policy Management.

Sélectionnez la GPO et éditez là :

Sous “User Configuration” (ou Computer Configuration en fonction du choix d’application de la GPO fait plus haut), allez dans “Windows Settings” puis “Scripts” :

Dans les propriétés du “Logon”, cliquez sur “Add” puis dans “Script Name” choisir PushPrinterConnections.exe (que l’on trouve dans le dossier SYSWOW64 sur Windows Server 2008R2) et dans les paramètres du script tapez “-log” :

Au prochain Logon, vos utilisateurs auront l’imprimantes d’installée sur leur poste, ce sans même que l’administrateur n’ait eu à se déplacer !

Dans les nouveautés de Windows Server 2012 l’interface graphique de gestion granulaire de mot de passe vient simplifier le travail de l’Administrateur en lui évitant de passer par les GPO et ADSIEdit.

La gestion granulaire des mots de passe est déjà disponible depuis Windows Server 2008, un niveau fonctionnel de 2008 suffit donc pour bénéficier de l’interface graphique sur un serveur 2012.

Avant de commencer : il est très probable que dès la mise en place de la stratégie vos utilisateurs aient à changer de mot de passe, or certaines applications ne peuvent le gérer, je vous conseille donc d’appliquer la stratégie une fois vos utilisateurs délogué.

Dans le Server Manager, lancer le tool “Active Directory Administrative Center” :

Une fois lancé, basculer en vue arborescente (Tree View), puis dans le dossier System, double-cliquer sur le dossier “Password Settings Container”

Pour créer une nouvelle politique de mot de passe, sélectionner dans l’onglet de droite : New –> Password Setting

Nous arrivons alors sur cette fenêtre et l’on remarque que Windows Server 2012 se veut intuitif :

Les textbox précédés d’un astérisque rouge sont des éléments requis pour la création de la stratégie.

Parmi ces éléments, il y a le champ “Precedence”, qui permet – dans le cas déconseillé ou plusieurs stratégies s’appliquerait aux mêmes utilisateurs ou groupes – de gérer quelle stratégie s’applique en priorité.

Une fois le paramétrage terminé, cliquer sur “Add” et la stratégie est immédiatement exécutée pour les utilisateurs concernés.

Lors de la création d’un master dans MDT, l’une des des étapes est l’intégration des pilotes. En principes ceux-ci sont généralement extractibles et il est possible de retrouver le .inf permettant l’installation du périphérique. Cependant dans quelques cas, cela n’est pas possible.

Pour pallier à ce problème, l’une des solutions est d’ajouter l’exécution d’un script Powershell dans la séquence de tâches.

Récupération des valeurs sur les postes cibles :

Tout d’abord il est nécessaire de récupérer certaines valeurs sur le modèle d’ordinateur concerné :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

Celles-ci vont nous permettre de détecter au moment du déploiement le modèle.

Script à intégrer dans la séquence de tâches :

Le script suivant est celui qui est intégré à la séquence de tâches (ici, le déploiement a été effectué sur un Elitebook 8440p de Hewlett-Packard) :

# Récupération du model via une requête WMI

$ModelName = wmic csproduct get name

# Récupération de la marque via une requête WMI

$VendorName = wmic csproduct get vendor

$ModelName = $ModelName[2].replace(" ", "")

$VendorName = $VendorName[2].replace(" ", "")

if(($ModelName -eq "HPEliteBook8440p") -and ($VendorName -eq "Hewlett-Packard") ){

    Invoke-Expression "ligne_de_commande"

}

On récupère les mêmes valeurs que précédemment et ci ces dernières correspondent aux valeurs récupérées alors on exécute une commande permettant l’installation silencieuse du pilote.

Depuis Windows Server 2008 l’assistant d’installation est capable de détecter un ancienne installation de Windows Server et – dans le cas où celle-ci est compatible – l’assistant d’installation proposera un “Upgrade” vers l’OS désiré.

L’avantage de l’Upgrade est de conserver la configuration et les rôles du serveur après l’installation du nouveau système d’exploitation. Néanmoins, Microsoft recommande lors de l’installation (ou de la mise à jour) d’un serveur de passer par une “Clean Install”, soit une installation traditionnelle de Windows Server.

Pour information, il est impossible d’Upgrader d’une version 32 bits vers une version 64 bits, la seule solution est de recourir à une Clean Install.

Après une Upgrade du serveur, le dossier utilisé par l’ancien système d’exploitation est toujours présent et a été renommé Windows.old.

Pour supprimer correctement ce dossier il faut passer par le “Disk Cleanup” et les habitués de Windows Server seront surpris par son absence sur Windows Server 2012 :

Pour faire apparaitre le bouton Disk Cleanup, il faut lancer en tant qu’administrateur la commande PowerShell suivante :

Voici de retour le bouton Disk Cleanup :

Le Disk Cleanup ne propose pas immédiatement de nettoyer le dossier Windows.old, il faut passer par l’option “Clean up system files” :

L’assistant Disk Cleanup commence alors à vérifier les anciennes installations de Windows encore présentes sur le serveur :

Après analyse, l’assistant propose de nettoyer les dossiers correspondants aux anciennes installations de Windows :

En moyenne le gain d’espace fait est d’une dizaine de GB, bien entendu cela dépend de la taille de la précédente installation.

Introduction

Parmi les nouveautés apportées par Windows Server 2012 et aussi Windows 8 concernant le stockage, on trouve la fonctionnalité Espace de Stockage qui consiste à grouper des disques standard (SATA,SAS..) en plusieurs pools de stockage (Storage Pool) et ensuite créer des Espace de Stockage (Storage Space) à partir de la capacité disponible au niveau du pool de stockage.

Usage

Depuis la console Server Manager on peut accéder à l’interface d’administration du stockage en sélectionnant la fonctionnalité File and Storage Services :

Une fois la console File and Storage Services ouverte on peut  sélectionner Storage Pools ce qui nous donne accès à la console d’administration des Pools de Stockage

Cette interface unique nous permet de gérer :

• les Pools de stockage,
• les Disques physiques qu’on peut affecter à un Pool de Stockage,
• et les Disques virtuels créé.

Remarques

L’utilisation des espaces de stockage permet de :

• Simplifier le Provisionning en matière de stockage,
• Réduire les charges administrative relatif à la gestion du stockage,
• Allouer dynamiquement l’espace,
• Etendre rapidement les capacité de stockage des serveurs sans pour autant causer des arrêts de services,
• Consolider et optimiser les gestion du stockage pour des serveurs critiques.

Pour définir nativement la langue Française dans votre Windows PE, il est nécessaire de modifier le registre du PE.

Pour cela, nous allons monter notre image boot.wim correspondant à notre WinPe.

imagex64.exe /mountrw c:\winpe4_x86\media\sources\boot.wim 1 c:\winpe4_x86\mount

Une fois celui-ci monté, nous allons monter le fichier de ruche Default

Ensuite, il nous suffit de modifier la valeur de la sous clé 1 dans

HKEY_CURRENT_USER\WinPe\Keyboard Layout\Preload

Et de lui saisir la valeur correspondante au Français

Décharger la ruche, démonter l’image et rebooter sur votre PE.

Le clavier sera désormais en Français.

Sous Windows XP, beaucoup de personnes pour résoudre des problèmes de profils renomment les profils utilisateurs(.old) afin que celui-ci soit régénéré par le système lors de la connexion de l’utilisateur en question.

Cependant sous Windows 7, pour régénérer un profil utilisateur en utilisant la technique de renommage, celui-ci va générer un profil temporaire.

Exemple : je me logue avec un utilisateur.

On peut désormais constater le répertoire du profil utilisateur dans c:\users.

Maintenant, on se connecte en tant que administrateur sur la machine et on renomme le répertoire du profil utilisateur afin que celui-ci ne soit plus trouver par le système.

Maintenant, si notre utilisateur essaie de se reconnecter sur cette même machine, il va avoir la surprise d’utiliser un profil temporaire.

La méthode pour régénérer un profil utilisateur en renommant le répertoire doit également contenir la suppression du pointeur du profil dans le registre.

Pour cela, il suffit d’accéder à la clé ProfileList

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Et là on peut constater que notre répertoire utilisateur n’étant plus trouvé par le système, celui s’est renommé .bak

Il faut alors supprimer cette clé.

Dès lors ou l’utilisateur se reconnectera à sa machine celui-ci régénéra un profil et non plus un profil temporaire.

L’entrée de l’utilisateur dans la clé “ProfileList” est également régénéré.

Dans une grosse infrastructure composée de nombreux serveurs, les redémarrages peuvent s’avérer assez fréquents.

Malheureusement, un serveur qui redémarre peut entrainer la remontée de différentes alertes dans SCOM puisque ni son agent ni les services qu’il exécute ne répondent plus.

C’est pourquoi il est recommandé de basculer les serveurs à redémarrer dans mode « Maintenance » dans la console SCOM avant de les stopper : cela indique à SCOM qu’il doit arrêter de les superviser pendant un temps prédéfini, empêchant ainsi toute remontée d’alerte.

Dans le cadre de grosses infrastructures, réparties entre des services divers, il n’est toutefois pas toujours pratique de solliciter la bonne personne au bon moment pour procéder à cette mise en mode maintenance, d’où l’intérêt de pouvoir procéder à cette action automatiquement lorsqu’un redémarrage est détecté.

Cette automatisation sera réalisée à l’aide d’une règle qui détectera un événement 1074 (source USER32) dans le journal d’événement System et créera une alerte, qui sera interceptée à l’aide d’un Notification Channel, qui déclenchera enfin l’exécution d’un script PowerShell qui procèdera à la mise en mode maintenance.

Commençons donc par créer la règle de détection d’événement :
Indiquer un nom pour la règle, une description, une catégorie, la cibler sur la classe Windows Computer et sélectionner un management pack différent du Default pour l’enregistrer.

Les events 1074 sont créés dans le journal d’évènement System lorsqu’un redémarrage est initié.

Leur ID est 1074 et leur source est USER32

L’alerte n’est pas destinée à être lue par un opérateur humain, son nom et sa description importent donc peu tant qu’ils restent suffisamment spécifiques. De la même façon, la sévérité pourra être définie à Information.

Une fois la règle mise en place, nous allons créer un ensemble de règles de Notification (channel de notification, subscriber, subscription). Ce sont eux qui détecteront la création de l’alerte et commanderont le lancement du powershell de mise en mode maintenance. Une recovery task aurait également pu remplir le même rôle, mais son mode de fonctionnement induit une réaction plus lente qui pourrait ici être préjudiciable puisqu’il faut que la mise en maintenance soit faite avant que le serveur ne cesse de répondre.

Commençons donc par créer un nouveau Notification Channel.
Entrer un nom et une description :

Dans le champ Full path of the command file, indiquer le chemin vers l’executable de powershell. Il s’agit par défaut de C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Dans le champ Command line parameters, indiquer les paramètres suivants (pensez à remplacer le chemin du script par le chemin où se trouvera le script dans votre cas) :
-Command "& '"D:\chemin\vers\script\scriptmaintenancemode.ps1"'" -alertid '$Data/Context/DataItem/AlertId$' -computerPrincipalName '$Data/Context/DataItem/ManagedEntityDisplayName$'

Passons ensuite au Subscriber.

Indiquer un nom

Laisser la sélection par défaut pour la plage d’utilisation (Alwas send notifications)

Cliquer sur Add. Indiquer à nouveau un nom (le même fera parfaitement l’affaire).

Sélectionner le Channel Type nommé Command et le Notification Channel qui vient d’être créé, Mode Maintenance dans cet exemple.

Ici aussi, laisser Always send notifications coché et cliquer sur Finish.

De retour sur l’écran du Notification Subscriber Wizard, l’addresse qui vient d’être créée doit apparaitre. Cliquer sur Finish.

Reste à paramétrer la Subscription.
Là aussi indiquer un nom (toujours le même…) et une description.

En Critère de déclenchement , cocher Created by specific rules or monitors et indiquer la règle précédemment créée.

Cliquer sur Add et sélectionner le Subscriber préalablement créé.

De la même facon, cliquer sur Add et indiquer le Channel.

Cliquer sur Finish.

Il ne reste plus qu’à créer le script powershell à proprement parler. Pensez à modifier la variable $RMS de façon à ce qu’elle indique le nom de votre RMS et la variable $minutes avec la durée de mise en mode maintenance que vous souhaitez utiliser, ainsi qu’a enregistrer le fichier .ps1 à l’endroit de votre choix correspondant à ce que vous avez indiqué lors de la création du Notification Channel:

#
# SCHEDULE MAINTENANCE MODE
# Version originale de base : http://lucamihailescu.blogspot.com/2010/01/operations-manager-maintenance-mode.html
#

Param($alertid, $computerPrincipalName, $minutes, $comment)

$RMS = "localhost"

if (!$minutes) {$minutes = 15}
if (!$comment) {$comment = "Mode Maintenance Automatique Suite a Detection de Redemarrage"}

function fixalert {
$alert = Get-Alert -Id $alertid
Resolve-Alert -Comment $args[0] -Alert $alert
}

if ((Get-PSSnapin | Where {$_.Name -eq 'Microsoft.EnterpriseManagement.OperationsManager.Client'}) -eq $null) {

Add-PSSnapin "Microsoft.EnterpriseManagement.OperationsManager.Client"

}

New-ManagementGroupConnection $RMS
Set-Location "OperationsManagerMonitoring::"
Set-Location $RMS
$agent = Get-Agent | Where {$_.PrincipalName –eq $computerPrincipalName}
$computer = $agent.HostComputer

if (!$agent) { fixalert "Alerte cloturee par le Script MaintenanceMode. Le Mode Mainenance n’a pas pu etre active (le serveur en cours de redemarrage est un RMS ou MS)"; Exit }

$startTime = [DateTime]::Now

$endTime = $startTime.AddMinutes($Minutes)

New-MaintenanceWindow -StartTime $startTime -EndTime $endTime -MonitoringObject $computer -Comment $comment

fixalert "Alerte cloturee par le Script MaintenanceMode. Mode Maintenance actif!"

Voilà, c’est terminé… vous pouvez maintenant redémarrer un de vos serveur supervisé pour vérifier qu’il passe bien automatiquement en mode maintenance!

Dans le billet précédent, nous avons vu comment créer une Assembly, c'est-à-dire le fichier dll contenant la « mécanique » de l’Integration Pack. Cependant, pour obtenir un Integration Pack finalisé et prêt à être déployé sur une infrastructure Orchestrator, il est nécessaire de packager cette Assembly pour en faire un fichier .oip.

Lancer l’outil Orchestrator Integration Pack Wizard

Cliquer sur Next ou sur Import Integration Pack pour reprendre un OIP préexistant

Remplir les champs obligatoires (marqués par une étoile).

Product Name correspond au nom qui apparaitra dans le Deployment Manager.

Category Name correspond au nom de la catégorie d’activité qui apparaitra dans le Runbook Designer :

Resource File est le fichier qui contient les icones et d’autres ressources. Dans cet exemple on conserve celui par défaut.

Une fois les champs remplis, cliquer sur Next.

Dans le champ Library, sélectionner la dll de l’assembly créée dans la première partie ainsi que la classe correspondante. Indiquer un Display Name (nom qui apparaitra dans le Runbook Designer). Sélectionner une icône pour l’activité, et cliquer sur OK

Au besoin, sélectionner les fichiers nécessaires au bon fonctionnement de l’activité (par exemple un exécutable si l’activité repose dessus) en cliquant sur Add. Dans notre exemple, il n’y a rien à ajouter puisque le fonctionnement de l’activité repose sur du code PowerShell directement intégré dedans. Cliquer sur Next.

Indiquer le chemin où enregistrer fichier OIP final puis cliquer sur Next.

L’assistant compile l’OIP…

Une fois terminé, cliquer sur Finish.

Il reste maintenant à déployer notre OIP au Management Server, Runbook Server et/ou Runbook Designer. Cette procédure est identique quel que soit l’OIP à déployer, mais un rappel pourra toujours servir :

Lancer la console Deployment Manager et faire un clic-droit sur Integration Packs. Cliquer sur Register IP with the Orchestrator Management Server.

Cliquer sur Next.

Cliquer sur Add et sélectionner l’OIP à déployer.

Cliquer sur Finish.

Une fois enregistré avec le Management Server, l’OIP apparait dans la liste des Integration Packs. Faire un clic-droit sur son nom et cliquer sur Deploy IP to Runbook Server or Runbook Designer.

Cliquer sur Next.

Sélectionner l’OIP à déployer et cliquer sur Next.

Indiquer le ou les serveurs cible(s) via le champ Computer et le bouton Add puis cliquer sur Next

Indiquer si vous souhaitez procéder au déploiement à une heure précise ainsi que si vous préférer arrêter tous les runbooks avant de procéder au déploiement. Cela peut s’avérer nécessaire pour certains OIP, ou pour le déploiement d’un hotfix, mais pas dans le cas de notre exemple. Cocher Install the Integration Packs […] et cliquer sur Next.

Cliquer sur Finish.

Relancer la console Runbook Designer pour en rafraichir le contenu. L’activité doit maintenant être présente et il ne reste plus qu’à l’utiliser comme n’importe quelle autre dans vos runbooks :