Le blog technique

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.

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.