Il existe un module nommé NTFSSECURITY permettant une manipulation simplifié des droits NTFS sur des dossiers et/ou fichiers.

Ce module peut être trouvé sur la galerie Technet http://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85/file/48905/1/NTFSSecurity%201.3.zip

Une fois téléchargé, mettez le dossier du module NTFSSecurity ici C:\Windows\System32\WindowsPowerShell\v1.0\Modules

Maintenant, nous allons charger le module dans powershell

Une fois celui-ci chargé, de nouvelles cmdlets sont désormais disponible.

                                    …

Récupération du SID d’un utilisateur dans une variable.

Nous allons définir dans une variable $SamMember le nom de l’utilisateur que nous voulons récupérer.

Ensuite nous allons utiliser l’object System.Security.principal.NtAccount(« domaine »,utilisateur) qui va nous permettre de récupérer notre utilisateur dans un domaine spécifié.

Maintenant, récupérons le SID de notre utilisateur grâce à une méthode de notre variable $account.

Nous avons ainsi récupéré dans notre variable $accountsid le SID de notre utilisateur spécifié dans la variable $SamMember.

Modification du propriétaire d’un répertoire.

Avec le chargement du module NTFSSecurity, une cmdlet get-owner est apparue nous permettant de connaitre simplement le propriétaire d’un élément (fichier ou répertoire).

Exemple :

Nous allons maintenant changer le propriétaire de ce répertoire avec l’utilisateur contenu dans notre variable $accountsid

Voyons maintenant le résultat :

Le propriétaire à bien été changé.

Modification des ACE du répertoire.

Nous allons maintenant modifier les ACE du répertoire de façon à ne laisser que l’utilisateur de notre variable $accountsid en FullControl et aucune autre ACE.

Rajout de l’ACE :

Suppression des autres ACE :

(Ce lien permet de connaitre les SID connu dans les OS Windows http://support.microsoft.com/kb/243330)

Si on consulte maintenant nos ACE, on peut remarquer que notre ajout d’ACE s’est bien passé mais que la suppression des autres ACE ne s’est pas déroulée correctement.

Cela est normal, car ses ACE sont hérité du répertoire parent. Il faut donc pour cela retirer l’héritage.

Et maintenant si on essaie de nouveau de supprimer nos ACE on peut remarquer que celle-ci ont bien disparu.

Il est maintenant facile d’imaginer la création d’un script pouvant réappliquer correctement des droits sur une toute une arborescence de répertoires profils en récupérant par exemple le nom du répertoire profil et en réaffectant celui-ci dans une boucle pour notre variable $account.

Ainsi, l’utilisateur authentifié en user2, ne pourra accéder qu’à son répertoire profil.

Le comportement d’USMT dans un état Offline est différent d’un état Online.

Nous nous situons dans un cas ou l’exécutable Scanstate est lancé sous Windows PE (donc offline).

Lors d’une capture en offline, le mappage des utilisateurs ne peut se baser sur la base SAM des utilisateurs. Le mappage s’effectue à l’aide des SID.

Exemple du log du ScanState sous Windows PE (Offline)

Exemple du log de ScanState sous Windows XP (Online)

Ce qui veut dire que pendant l’utilisation du ScanState sous Windows PE, nous ne devons travailler qu’avec des SID.

Si par exemple on ne veut inclure qu’un seul utilisateur dans notre DataStore du ScanState, il faudra utiliser l’argument /ue:* permettant d’exclure tous les utilisateurs et utiliser l’argument /ui  permettant d’inclure l’utilisateur spécifique avec son SID.

Exemple:

scanstate E:\Migshare\U11281 /i:x:\ftmas7\tools\usmt\F2_MigFiles.xml /i:x:\ftmas7\tools\usmt\MigOutlook.xml /o /c /localonly /v:13 /offlinewindir:c:windows /ue:* /ui:S-1-5-21-1221297486-3643808661-2871141796-1074 /l:E:\Migshare\U11281\log.txt

Pour inclure plusieurs utilisateurs, l’argument /ui peut être utilisé autant de fois que désiré.

Utilisation du ScanState en Offline pour capturer uniquement des utilisateurs du domaine.

Si vous souhaitez ne capturer que des utilisateurs d’un domaine et non les utilisateurs locaux, vous pouvez exclure tout le monde via l’argument /ue :* et inclure uniquement le SID du domaine avec l’astérique « * » pour le pool RID.

Exemple :

scanstate.exe S: /i:MigFiles.xml /i:MigOutlook.xml /l:S:\log.log /progress:S:\Prog.log /localonly /o /c /v:13 /offlinewindir:c:\windows /ue:* /ui: S-1-5-21-759407729-413330662-2607319723-"*"

Utilisation du LoadState sur un DataStore obtenu par un ScanState Offline

Contrairement au ScanState, le LoadState ne peut être exécuté qu’en mode Online.

Ayant utilisé ScanState en mode Offline, nous avons donc du traiter les utilisateurs via leurs SID. Il en sera donc de même pour le LoadState car aucun mappage samaccountname n’a pu être effectué précédemment.

Donc l’utilisation des commutateurs /ue et /ui se passent de la même manière que pour le Scanstate en Offline c’est-à-dire basé sur des SID.

Dans le cas d’une migration de domaine, il n’est pas nécessaire de spécifier le SID du domaine source vers le domaine cible. (La migration de domaine s’opère à l’aide du commutateur /md. (/md:Old_domain :New_domain)

Exemple :

loadstate F:\Migshare\U11281 /i:C:\APPLI_FTV\apps\usmt\F2_MigFiles.xml /i:C:\APPLI_FTV\apps\usmt\MigOutlook.xml /c /v:13 /l:F:\Migshare\U11281\Load-log.txt /md:SourceSI :CibleSi /progress:F:\Migshare\U11281\simpleprog.log

Cela signifie que tous les utilisateurs situés dans le DataStore avec pour domaine source « SourceSI » vont être migré sur « CibleSi » si ceux-ci existent.

Attention, si USMT tente de migrer un utilisateur sur un domaine cible mais que celui-ci n’existe pas dans ce domaine, une erreur fatale en ressortira et le déroulement du LoadState sera alors interrompu.

Cependant, si vous souhaitez utiliser /mu au lieu de /md, la, il faudra utiliser le SID utilisateur depuis la source et spécifier le domaine cible ainsi que son Sam Account Name.

Exemple :

loadstate F:\Migshare\U11281 /i:C:\APPLI_FTV\apps\usmt\F2_MigFiles.xml /i:C:\APPLI_FTV\apps\usmt\MigOutlook.xml /c /v:13 /l:F:\Migshare\U11281\Load-log.txt /mu:S-1-5-21-1221297486-3643808661-2871141796-1074:CibleSi\trsb2 /ui:S-1-5-21-1221297486-3643808661-2871141796-1074 /progress:F:\Migshare\U11281\simpleprog.log /ue:*

Le profil utilisateur sera alors créé sur l’os cible dans le nouveau domaine.

Vous disposez d’une liste exhaustive de comptes utilisateurs dans un fichier et vous désirez savoir ceux d’entre eux qui sont bien existant dans le domaine courant.

Pour cela, nous allons parcourir ce fichier et établir une connexion sur ces utilisateurs. Si la connexion sur l’utilisateur se passe bien, nous l’ajouterons dans un second fichier. Si cet utilisateur n’existe pas, nous l’ignorerons.

Exemple de fichiers contenant sur une colonne des utilisateurs existant ou non dans le domaine courant.

Résultat obtenu dans un fichier result.txt :

Le script nous a bien permit de récupérer uniquement les utilisateurs existant dans le domaine courant.

Les « tâches console » sont comme leur nom l’indique des tâches qui s’exécutent sur la console, par opposition aux tâches Agent qui sont elles exécutées sur les ordinateurs monitorés et dont le résultat est ensuite affiché dans la console.

Elles permettent de lancer un exécutable sur l’ordinateur exécutant la console, éventuellement en lui passant des paramètres récupérés dans la console.

Exemple concret : on peut ainsi lancer un ping ou une session bureau à distance automatiquement vers le l’ordinateur sélectionné dans  la console.

Je détaillerai ici le cas rencontré chez un client qui souhaitait pouvoir accéder aux incidents créés indépendamment de SCOM dans un système de gestion de tickets tiers à la suite de la remontée de certaines alertes dans SCOM.
Ce système de ticket étant accessible via un simple navigateur web sur une url fixe prenant l’ID du ticket en paramètre (ID préalablement renseignée dans un CustomField de l’alerte par le helpdesk), nous avons procédé de la sorte :

Dans la console Authoring (et non pas la vue authoring de la console Operations, cette dernière ne permet pas de créer ce genre de tâche!), créer un nouveau management pack.
Se rendre dans la vue Presentation et sélectionner Console Tasks dans le menu de gauche, puis faire un clic-droit à sélectionner New>Console Task (attention à ne pas confondre avec les Agent Tasks qui se trouvent elles dans la vue Health Model!) :

Nommer cette nouvelle tâche :

Lui donner un nom d’usage, qui apparaitra dans SCOM et choisir l’élément qu’elle ciblera :

Dans l’onglet Command Line, renseigner la partie fixe de la commande lancée par la tâche.
Dans notre cas il s’agit donc d’appeler le navigateur web et de lui passer la partie invariable de l’URL du système de gestion de tickets, mais plutôt que d’indiquer le chemin absolu vers l’exécutable du browser, nous avons choisi d'appeler le navigateur par défaut du système à l’aide du raccourci rundll32 url.dll,FileProtocolHandler http://suivi.tickets.local/?ticketID= .
Cela permet d’éviter les potentiels soucis liés à l’utilisation de navigateurs différents suivant les ordinateurs et respecte ainsi les préférences de l’utilisateur de la console SCOM.
Il faut ensuite indiquer en paramètre que l’on souhaite récupérer le CustomField de l’alerte contenant l’ID du ticket.
Oui mais… par défaut, seul le Display Name est disponible en paramètre :

Afin de modifier ce comportement, se rendre dans l’onglet Options et cliquer sur Category [Value=MonitoringObject]. Cela dévoile des options qui étaient jusque là invisibles et il est alors possible de sélectionner la catégorie Alert :

En retournant dans l’onglet CommandLine, on constate qu’il est maintenant possible de sélectionner les CustomField  comme paramètres (ainsi que bien d’autres, libre à vous d’adapter suivant vos besoins!) :

Il ne reste plus qu’à enregistrer le management pack et à le publier dans SCOM.

Le script suivant prends en paramètre un nom de machine et un nom d’application (apparaissant dans Ajout-suppression de programme), desinstalle l’application si elle est trouvée, affiche les resultats et les inscris dans un fichier de log.

Param(
[Parameter(Mandatory = $true)][string]$computername=(read-host -Prompt "entrez le nom de la machine"),
[Parameter(Mandatory = $true)][string]$application=(read-host -Prompt "entrez le nom exact de l'application"),
[string]$credential="administrator"
)

$logfile="c:\result.txt"
$now=(get-date).ToString()

$appuninstall=Get-WmiObject -ComputerName $computername -Class win32_product -Credential $credential | where-object {$_.name -eq $application}

if ($appuninstall -eq $null)
{
write-host "Application $application non trouvée" -ForegroundColor yellow -BackgroundColor black
write-host "Resultat inscris dans $logfile" -ForegroundColor yellow -BackgroundColor black
Out-file $logfile -Append -InputObject "$now -- Application $application non trouvée sur $computername"
exit
}

foreach ($app in $appuninstall)
{
  write-host "...debut desinstallation..." -ForegroundColor yellow -BackgroundColor black
  $app.uninstall()| Tee-Object -Variable uninstallresult
if ($uninstallresult.ReturnValue -eq 0)
    {
    write-host "Desinstallation OK pour $computername" -ForegroundColor green -BackgroundColor black
    write-host "Resultat inscris dans $logfile" -ForegroundColor green -BackgroundColor black
    Out-file $logfile -Append -InputObject "$now -- Desinstallation OK pour $computername"
    }
    else
    {
    write-host "Desinstallation KO pour $computername" -ForegroundColor red -BackgroundColor black
    Out-file $logfile -Append -InputObject "$now -- Desinstallation KO pour $computername"
    write-host "Resultat inscris dans $logfile" -ForegroundColor red -BackgroundColor black
    }
}

Présentation de BlogEngine.NET

BlogEngine.NET est une plateforme de blog open-source développé en C#, elle permet entre-autres la gestion des auteurs, des posts et ne requiert ni base de donnée ni installation.

Toutes les fonctionnalités ici.

Contexte

Pour la configuration de serveurs WEB en Haute-Dispo, il est possible de créer entre les serveurs une réplication des dossiers de BlogEngine à l’aide de DFS-R.

Suite à la mise en place de la réplication DFS-R entre les deux serveurs Web, une latence d’environ une heure lors de l’ajout (ou la modification) d’un post à partir d’un serveur et la visualisation sur le second est apparue.

Cette latence n’est pas due à DFS-R car au niveau du système il est visible que le post (enregistré au format XML) a correctement été répliqué.

Explication

Afin d’assurer un temps de réponse optimal, BlogEngine dispose d’un cache interne qui est mis à jour automatiquement.

Résolution

Pour de palier à ce problème il suffit de modifier la page default.aspx.cs située à la racine du répertoire de BlogEngine en ajoutant au début de la fonction Page_Load() la commande BlogEngine.Core.Post.Reload() comme ceci :

Ce qui permettra à chaque fois que l’utilisateur se connecte sur la page Accueil, de recharger le cache.

Ou comment séparer la définition de l’affichage des tâches.

Voici un problème qui m’a été posé par un de nos clients : comment réutiliser des tâches définies dans un premier Management Pack dans un ou plusieurs autres MP, sans avoir à les recoder à chaque fois ? Après recherche, voici la solution qui a été retenue.

Prenons un exemple simple : via la console Authoring, créons dans un nouveau management pack une tâche console qui lance la calculatrice Windows.

Une fois enregistré non-scellé, le code xml de ce management pack très basique est le suivant :

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>MP_ExempleTask</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP_ExempleTask</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
  <TypeDefinitions>
    <ModuleTypes>
      <ProbeActionModuleType ID="calcType" Accessibility="Public" Batching="false" PassThrough="false">
        <Configuration />
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ProbeAction ID="PA" TypeID="System!System.CommandExecuterProbe">
                <ApplicationName><![CDATA[%WINDIR%\System32\calc.EXE]]></ApplicationName>
                <WorkingDirectory />
                <CommandLine>/ALL</CommandLine>
                <TimeoutSeconds>30</TimeoutSeconds>
                <RequireOutput>true</RequireOutput>
                <Files />
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="PA" />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </ProbeActionModuleType>
    </ModuleTypes>
  </TypeDefinitions>
  <Presentation>
    <ConsoleTasks>
      <ConsoleTask ID="Task.LocalCalc" Accessibility="Internal" Enabled="true" Target="System!System.Entity" RequireOutput="true" Category="MonitoringObject">
        <Application>%systemroot%\system32\calc.exe</Application>
        <WorkingDirectory />
      </ConsoleTask>
    </ConsoleTasks>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="FRA" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Task.LocalCalc">
          <Name>Ouvrir Calculatrice</Name>
          <Description />
        </DisplayString>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>

La suite de la manœuvre implique d’utiliser un éditeur de texte : il va falloir séparer les parties « manifest », « défintion » et « affichage » de votre management pack.

Le manifest est le code compris entre les balises <Manifest></Manifest> (surligné plus haut en vert) :

<Manifest>
    <Identity>
      <ID>MP_ExempleTask</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP_ExempleTask</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>

La partie définition est l’ensemble du code compris entre les balises <TypeDefinitions>[…]</TypeDefinitions> (surligné plus haut en bleu). C’est cette partie qui contient le code de « ce que font » les tâches à proprement parler :

<TypeDefinitions>
    <ModuleTypes>
      <ProbeActionModuleType ID="calcType" Accessibility="Public" Batching="false" PassThrough="false">
        <Configuration />
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ProbeAction ID="PA" TypeID="System!System.CommandExecuterProbe">
                <ApplicationName><![CDATA[%WINDIR%\System32\calc.EXE]]></ApplicationName>
                <WorkingDirectory />
                <CommandLine>/ALL</CommandLine>
                <TimeoutSeconds>30</TimeoutSeconds>
                <RequireOutput>true</RequireOutput>
                <Files />
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="PA" />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </ProbeActionModuleType>
    </ModuleTypes>
  </TypeDefinitions>

La partie “affichage” est quant à elle celle qui est comprise entre les balises <Presentation>[…]</LanguagePacks> (surlignée plus haut en rouge). C’est cette partie qui se charge de faire apparaitre les tâches dans la console SCOM :

<Presentation>
    <ConsoleTasks>
      <ConsoleTask ID="Task.LocalCalc" Accessibility="Internal" Enabled="true" Target="System!System.Entity" RequireOutput="true" Category="MonitoringObject">
        <Application>%systemroot%\system32\calc.exe</Application>
        <WorkingDirectory />
      </ConsoleTask>
    </ConsoleTasks>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="FRA" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Task.LocalCalc">
          <Name>Ouvrir Calculatrice</Name>
          <Description />
        </DisplayString>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>

Vous avez isolé ces deux parties? Bien, nous allons pouvoir passer à la suite : il faut maintenant construire deux management packs séparés, et ce toujours à l’aide d’un éditeur de texte.
En toute logique, le premier contiendra la partie définitions et le second la partie affichage… ainsi que quelques subtilités :

Pour le premier, c’est assez simple. Créons un fichier texte que nous nommerons par exemple mp1.xml et copions-y la partie « définition » préalablement extraite, précédée du manifest, le tout encadré par les balises <ManagementPack> nécessaires à la conformité de tout MP :

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>MP1</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP1</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="System">
        <ID>System.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
  <TypeDefinitions>
    <ModuleTypes>
      <ProbeActionModuleType ID="calcType" Accessibility="Public" Batching="false" PassThrough="false">
        <Configuration />
        <ModuleImplementation Isolation="Any">
          <Composite>
            <MemberModules>
              <ProbeAction ID="PA" TypeID="System!System.CommandExecuterProbe">
                <ApplicationName><![CDATA[%WINDIR%\System32\calc.EXE]]></ApplicationName>
                <WorkingDirectory />
                <CommandLine>/ALL</CommandLine>
                <TimeoutSeconds>30</TimeoutSeconds>
                <RequireOutput>true</RequireOutput>
                <Files />
              </ProbeAction>
            </MemberModules>
            <Composition>
              <Node ID="PA" />
            </Composition>
          </Composite>
        </ModuleImplementation>
        <OutputType>System!System.PropertyBagData</OutputType>
        <InputType>System!System.BaseData</InputType>
      </ProbeActionModuleType>
    </ModuleTypes>
  </TypeDefinitions>
</ManagementPack>

Notez que j’ai également modifié l’ID et le Nom de ce MP, qui s’appelle désormais “MP1”.

Une fois ce fichier XML achevé, il faudra le sauvegarder en tant que Management Pack scellé et noter sa clé publique ; autrement il ne sera pas possible de l’importer dans les MP qui devront y faire appel, puisqu’on ne peut pas hériter d’un MP non scellé.

Passons ensuite au MP2 : il contient également le Manifest (auquel j’ai apporté quelques modifications, détaillées plus bas), suivi cette fois uniquement de la partie affichage :

<ManagementPack ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<Manifest>
    <Identity>
      <ID>MP2</ID>
      <Version>1.0.0.0</Version>
    </Identity>
    <Name>MP2</Name>
    <References>
      <Reference Alias="Windows">
        <ID>Microsoft.Windows.Library</ID>
        <Version>6.1.7221.0</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
<Reference Alias="MP1">
<ID>TaskMP1</ID>
<Version>1.0.0.0</Version>
<PublicKeyToken>0823A712C344907</PublicKeyToken>
      </Reference>
    </References>
  </Manifest>
<Presentation>
    <ConsoleTasks>
      <ConsoleTask ID="Task.LocalCalc" Accessibility="Internal" Enabled="true" Target="System!System.Entity" RequireOutput="true" Category="MonitoringObject">
        <Application>%systemroot%\system32\calc.exe</Application>
        <WorkingDirectory />
      </ConsoleTask>
    </ConsoleTasks>
  </Presentation>
  <LanguagePacks>
    <LanguagePack ID="FRA" IsDefault="false">
      <DisplayStrings>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
    <LanguagePack ID="ENU" IsDefault="true">
      <DisplayStrings>
        <DisplayString ElementID="Task.LocalCalc">
          <Name>Ouvrir Calculatrice</Name>
          <Description />
        </DisplayString>
        <DisplayString ElementID="MP_ExempleTask">
          <Name>MP Exemple Task</Name>
        </DisplayString>
      </DisplayStrings>
    </LanguagePack>
  </LanguagePacks>
</ManagementPack>

Comme vous pouvez le voir dans la partie surlignée, le MP2 hérite du MP1.

Nous avons donc désormais un MP1.mp (MP1 scellé) et un MP2.xml, qu’il ne reste plus qu’à importer dans la console SCOM l’un après l’autre : les tâches stockées dans le MP1 et appelées dans le MP2 apparaissent bien.

Il sera par la suite possible d’appeler de la même façon les tâches définies dans le MP1 dans autant de management packs « enfants » que nécessaire.

En termes de monitoring, une des nouveautés de SCOM 2012 est la présence de 4 nouveaux types de vues (Dashboard) orientées réseau.

Network Summary, Network Node, Network Interfaces et Vicinity view.

• La vue Network Summary est la seule des quatre à s’afficher par défaut dans la hiérarchie des vues de la partie Navigation, les autres étant disponible via un lien sur la vue Network Summary, via les taches a exécuter ou encore dans le menu contextuel des objets (clic-droit)

Cette vue sert essentiellement a voir l’état générale des équipements et interfaces associés de votre réseau.

• La vue Network Node fourni des détails sur l’état de santé d’un équipement particulier. Cette vue est constitué de :

- la vue des liens connectés à l’équipement sélectionné

- des jauges sur la disponibilité de l’équipement dans le temps

- la liste des interfaces de l’équipement, avec la possibilité d’activer/désactiver directement la supervision de l’interface par override.

• La vue Network Interface est la plus détaillé des vues sur une interface particulière d’un équipement. Il est important de noter que par défaut SCOM 2012 supervise uniquement les interfaces d’équipements supervisés et celles connectées a des ordinateurs Windows également supervisés.

• La vue Network Vicinity (Littéralement « Voisinage Réseau ») est la vue qui traduit le plus l’orientation donné a SCOM 2012, à savoir une vue 360 ° de l’objet.

Cette vue affiche un nœud réseau et tous les ordinateurs Windows et autres équipements réseau connecté à ce nœud.

La possibilité est donnée de basculer entre 5 niveaux de détails de connexion et de visualiser les machines connectés ou non.

En sélectionnant une connexion particulière il est possible d’identifier quelle ports d’équipement réseau est impliqué dans l’état d’une liaison.

La principale limitation dans cette première version des vues Network Vicinity est qu’elle fonctionne uniquement avec des ordinateurs Windows et non les agents Linux, qu’elle ne visualise pas la relation entre un hôte Hyper-V et ses machines virtuelles hébergées, et qu’elle n’affiche pas les interfaces réseaux configurés en « Teaming » comme étant « Teamés ».

Ces limitations devraient disparaitre avec l’évolution de SCOM 2012, notamment à travers le premier service pack.

A noter que l’ensemble de ces 4 types de vues sont visualisable a la fois dans la console native et dans la console web de SCOM 2012.

Contexte

Il arrive souvent lors de l’installation de certains produits ou fonctionnalitée de devoir réaliser des opérations de vérification des pré-requis. Le premier pré-requis a satisfaire concerne souvent le réseau:

• Suis-je en capacité de joindre ma passerelle?
• Le ou les contrôleurs hébergeant les rôles FSMO sont-ils joignable?
• Mes serveurs DNS sont-ils joignable?

Pour réaliser ces opérations sur quelques serveurs cela peut être réalisé manuellement, mais lorsque le nombre de serveur est conséquent, cela peut s’avéré fastidieux. Je vous propose de travailler en powerShell pour simplifier/automatiser cette opération.

Etape 1: récupérer la configuration de machine

Pour cela rien de bien compliquer, la commande ipconfig /all nous retourne l’ensemble des éléments nécessaire:

Maintenant il faut pouvoir isolé chaque paramètre de réponse (ici identifiés de 1 a 6). Pour cela un traitement sur le retour d’ipconfig est nécessaire:

1. 1. Adresse IPv4:  ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]
2. 2. Masque : ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]
3. 3 Passerelle : ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]
4. 4 Serveur DHCP : ((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]
5. 5 DNS Principal : ((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]
6. 6 DNS Secondaire ((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]

Etape 2: Exécuter un ping en powershell

Pour réaliser cette opération les commandes suivante nous retourne un résultat contenant les valeur attendu:

• new-object System.Net.NetworkInformation.ping
• $reply = $ping.Send("192.168.0.254")

Nous savons donc que le ping a fonctionné au travers du status. qu’il reste a isoler puis a traiter. Pour l’isolation, l’utilisation des variables nous simplifie la tache:

Etape 3: Automatisation des résultats

Afin de valider le bon fonctionnement des pré-requis lié au réseau, nous pouvons traiter les retours au travers de différents moyens, pour ma part, je préfère utilisé les conditions au travers du If – Else

   1: #***** Stockage des parametre dans une variable*****#

   2:     $IP= ((ipconfig | findstr [0-9].\.)[0]).Split()[-1]

   3:     $IPMask= ((ipconfig | findstr [0-9].\.)[1]).Split()[-1]

   4:     $IPgtw= ((ipconfig | findstr [0-9].\.)[2]).Split()[-1]

   5:     $IPDHCP=((ipconfig /all| findstr [0-9].\.)[3]).Split()[-1]

   6:     $DNS1=((ipconfig /all| findstr [0-9].\.)[5]).Split()[-1]

   7:     $DNS2=((ipconfig /all| findstr [0-9].\.)[6]).Split()[-1]

   8:  

   9: #**Test passerelle**#

  10:     $reply = ""

  11:     $status =""

  12:     $ping = new-object System.Net.NetworkInformation.ping

  13:     $reply = $ping.Send($IPgtw)

  14:  

  15: if ($reply.status -eq "success")

  16:     {

  17:     write-host "Passerelle joignable" -foregroundColor green

  18:     }

  19:     Else

  20:     {

  21:     write-host "Passerelle injoignable" -foregroundColor red

  22:     }

  23:  

  24: #**Test DHCP**#

  25:     $reply = ""

  26:     $status =""

  27:     $ping = new-object System.Net.NetworkInformation.ping

  28:     $reply = $ping.Send($IPDHCP)

  29:  

  30: if ($reply.status -eq "success")

  31:     {

  32:     write-host "DHCP joignable" -foregroundColor green

  33:     }

  34:     Else

  35:     {

  36:     write-host "DHCP injoignable" -foregroundColor red

  37:     }

  38: #**Test passerelle**#

  39:     $reply = ""

  40:     $status =""

  41:     $ping = new-object System.Net.NetworkInformation.ping

  42:     $reply = $ping.Send($DNS1)

  43:  

  44: if ($reply.status -eq "success")

  45:     {

  46:     write-host "DNS joignable" -foregroundColor green

  47:     }

  48:     Else

  49:     {

  50:         $reply = ""

  51:         $status =""

  52:         $ping = new-object System.Net.NetworkInformation.ping

  53:         $reply = $ping.Send($DNS2)

  54:         if ($reply.status -eq "success")

  55:             {

  56:             write-host "DNS joignable" -foregroundColor green

  57:             }

  58:             Else

  59:             {

  60:             write-host "DNS injoignable" -foregroundColor red

  61:             }        

  62:     }

  63:  

Le résultat positif retourne:

Le résultat négatif retourne:

Conclusion

Cette vérification permet de réaliser un enchainement de script ou d’action si et seulement si les paramètres réseaux sont correct. Par exemple en créant un flag si les résultats sont positif !

Trop souvent, les souscriptions d’alertes ne sont pas utilisées à leur plein potentiel : une seule souscription est créée, ce qui peut bien entendu suffire dans certains cas mais pourraient être largement optimisé dans d’autres.

On peut ainsi définir de vrais scénarios d’escalade : par exemple si aucune action n’a été effectuée pour résoudre une alerte après un délai imparti, on peut décider d’envoyer un SMS à un responsable ou bien de transférer l’alerte à un autre service.

Prenons l’exemple de la souscription suivante, nommée « Alerte Linux » :

Il s’agit d’une souscription des plus classique, où toutes les nouvelles alertes (resolution state 0) concernant les serveurs membres du groupe Unix Computers (donc tous les ordinateur Unix/Linux monitorés par SCOM) et de priorité moyenne ou haute seront adressées par mail à l’utilisateur « Support_Linux ».

Imaginons maintenant que nous souhaitons que cette alerte soit automatiquement transmise par SMS à un responsable si elle n’est pas prise en charge au bout d’une heure.
Il suffit pour ce faire de créer une alerte avec des conditions de déclenchement identiques en tous points à la précédente, que nous nommerons par exemple « Alerte Linux (+1h) » et qui sera cette fois destinée à l’utilisateur « Manager_Linux » avec un délai (alert aging) d’une heure :

En se basant sur ce système, il devient très simple de créer des scénarios d’escalade en fonction du niveau de résolution, de l’heure de la journée (en créant des subscribers valables uniquement la nuit pour les astreintes par exemple) ; ou bien de n’envoyer l’alerte par mail que si elle n’a pas été prise en compte directement dans la console… les possibilités sont vastes !

Et comme il peut être fastidieux de recopier à l’identique les conditions de déclenchement d’une subscription (sans parler du risque de se tromper), Timothy McFadden (PFE chez Microsoft) a developpé un outil très pratique, Subscription Copier :

Il permet de sélectionner une subscription initialement créée avec les bons paramètres de la copier autant de fois que vous en aurez besoin pour votre scénario d’escalade. Il permet également de prédéfinir un délai (alert aging) qui s’incrémente de copie en copie.
Disponible sur son blog : http://www.scom2k7.com/subscription-copier/