PI Services

Le blog des collaborateurs de PI Services

MDT 2013 - Exploitation des fichiers logs

Cet article a pour objectif de vous informer sur l’exploitation des fichiers de journalisation lors d’un déploiement d’un poste de travail via MDT.

Emplacement des fichiers logs

En fonction de l’état d’avancement de votre déploiement, la localisation du répertoire contenant les fichiers de journalisation sera différente.

Si votre déploiement s’est arrêté avant la fin de la phase de déploiement de l’image. Le répertoire se situe au niveau le lecteur virtuel X chargé en mémoire. Le chemin complet pour accéder au répertoire est le suivant : X:\MININT\SMSOSD\OSDLOGS

En revanche si une erreur est survenue après la copie de l’image de l’OS, les logs seront stockés dans le disque système. Voici le chemin complet pour accéder au répertoire : C:\MININT\SMSOSD\OSDLOGS.

Enfin si votre déploiement s’est terminé correctement, le répertoire à utiliser est le suivant : C:\Windows\TEMP\DeploymentLogs.

Découverte des fichiers logs

Vous connaissez les différents emplacements, je vous propose maintenant de passer en revue les différents fichiers disponibles. Vous trouverez ci-dessous les deux principaux axes pour l’analyse de vos déploiements :

BDD.log

Regroupe l’ensemble des logs de tous les scripts exécutés durant la séquence de tâche.

SMSTS.log

Retourne les informations après l’exécution de chaque étape de la séquence de tâches.

De plus, vous trouverez pour chaque script MDT un fichier de journalisation dédié (intégralement repris dans le BDD.log).

Vous trouverez par exemple :

ZTIDiskpart.log

Logs liés au partitionnement du disque

ZTIDomainJoin.log

Logs liés à l’intégration du poste dans un domaine Active Directory

ZTIDrivers.log

Logs liés à l’installation des drivers

Enfin si vous avez ajouté des scripts dans votre séquence de taches, sachez qu’un fichier log est créé pour chaque script (le fichier Log associé portera le nom de votre script).

Outil pour exploiter les fichiers logs

Après avoir fait un tour d’horizon des différents fichiers de journalisation, voyons à présent comment en optimiser leur exploitation.

Il est tout à fait possible d’ouvrir les fichiers avec un simple éditeur de texte. Cependant, les fichiers contiennent différentes informations qui rendent la compréhension délicate. Plutôt que d'utiliser Notepad, je ne peux que vous conseiller d’utiliser un outil plus adapté.

Microsoft met à disposition Configuration Manager Trace Log Tool. L'outil est dédié à l'exploitation des fichiers logs générés par MDT ou ConfigMgr. L’exécutable pèse moins de 700 Ko et ne nécessite pas d’installation sur le système. Il sera donc très facile de l’exécuter sur les postes dont le déploiement aura échoué.

CMTrace remplace SMSTrace qui était la précédente version de l'outil (disponible dans le Toolkit ConfigMgr 2007 R2). Notez que le code couleur permet de détecter rapidement les actions échouées :

· Rouge : Erreur

· Jaune : Avertissement

· Blanc : Observation

Avec ses informations, vous devrez rapidement identifier les actions qui ont posé problème lors du déploiement.

CM Trace fait partie du System Center Configuration Manager 2012 R2 Toolkit. Il est disponible gratuitement depuis le lien suivant : http://www.microsoft.com/en-us/download/details.aspx?id=36213

2

MDT 2013 – Exécuter un script PowerShell – Partie 2

Importer la nouvelle image WinPE dans WDS

Grâce à la première partie, votre nouvel environnement est maintenant capable d’exécuter des scripts Powershell. Cependant, la nouvelle image WinPE n’est pas encore disponible sur votre serveur WDS (et donc pas pour vos clients Windows). Pour mettre en ligne votre image, rendez-vous dans la console WDS.

D

Sélectionner votre serveur de déploiement, puis le dossier « Boot Image ». Faite un clic droit sur celui-ci et sélectionner « ADD Boot Image »

E

La première étape de l’ajout d’une nouvelle image consiste à indiquer le chemin de votre image WinPE.

5

Par défaut, les images se trouvent dans le chemin suivant :

« CheminDuDeploymentShare\Boot»

Sélectionner votre image (portant l’extension « .wim » et cliquez sur « Next ».

Sur la page suivante, vous avez la possibilité de saisir un nom et la description. Cliquez sur « Next ».

La dernière page vous résume la configuration avant de lancer l’import de l’image.

À la fin de l’opération, vérifier que tout s’est déroulé correctement puis fermer cette fenêtre. À présent, vous devriez voir votre image de boot dans la console.

Ajouter un script PowerShell à votre séquence de tâche

La dernière étape consiste à ajouter un script PowerShell dans une séquence de tâche.

Pour ce faire : Rendez-vous dans la console « Deployment Workbench », puis déplier l’arborescence de votre « Deployment Share » et enfin « Task Sequences ».

Sélectionner votre séquence de tâches et aller dans les propriétés de celle-ci.

f

Une nouvelle fenêtre s’ouvre, allez dans l’onglet « Task Sequence ». Maintenant, cliquer sur « Add » puis sur « General » et sélectionner « Run Powershell Script ».

7

Une nouvelle étape d’exécution d’un script PowerShell a été ajoutée à votre Task Sequence. Vous devez remplir les champs : Name, description (optionnel), PowerShell script et parameters (optionnel).

8

Tips 1 : Dans mon exemple, %DEPLOYROOT% est une variable qui représente l’emplacement de mon « Deployment Share ».

Tips 2: Durant le déploiement, MDT se charge d’autoriser l’exécution des scripts Powershell sur l’environnement client.

Tips 3 : Notez également qu’un fichier log est généré pour chaque script exécuté dans une TS.

A présent vous êtes maintenant capable de déployer vos propres scripts dans votre environnement.

Office 365 - Synchroniser des utilisateurs en mailuser avec DirSync

 

Si vous utilisez Office 365 dans votre infrastructure, il y a de fortes chances que vous soyez déjà utilisateur de DirSync pour synchroniser votre AD local.

Synchronisation d’utilisateurs locaux en utilisateurs distants ou de Mail Enabled Users locaux en MailUser distants ne vous posent évidemment aucun souci particulier.

Mais comment faire si vous souhaitez sortir des sentiers battus et synchroniser vos utilisateurs en mailuser distants (ce qui constitue un prérequis à l’utilisation de certains outils de migration)?

Commençons par le début : qu’est-ce qui définit un MailUser? Ce blog technet nous apprend qu’il suffit que les attributs mailNickName, DisplayName et TargetAddress soient peuplés.

Seulement voilà : si vos utilisateurs disposent normalement déjà d’un mailnickname et d’un displayname, il en va tout autrement de la targetaddress qui est normalement utilisée afin de rediriger les mails qui leur sont adressés : aucune chance donc que leurs comptes comportent déjà cet attribut, encore moins paramétré vers leur propre adresse, ce qui créerait des boucles de routage.

Il faut donc trouver un moyen de rediriger l’adresse mail de l’utilisateur local vers le champ targetadress de son compte synchronisé dans office 365.

Et cette solution, c’est DirSync : moyennant quelques paramétrages, il va nous permettre ce tour de passe-passe.

Lancez la console MIIS DirSync (elle se trouve par défaut ici : "C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe" ) et ouvrez l’onglet Management Agents

image

Double-cliquez sur Active Directory Connector puis cliquez sur l’onglet Configure Attribute Flow

image

Déplier la catégorie Object Type : user.

Dans le menu déroulant Data source object type, sélectionner user puis dans la liste Data source attribute, sélectionner mail.
Dans mapping type, cocher Direct.
Dans Flow Direction, cocher Import
Dans le menu déroulant Metaverse object type, sélectionner person
Dans la liste Metaverse attribute, sélectionner targetAddress

Cliquer sur New puis sur OK

image

 

Et… c’est tout. Désormais, lorsque les utilisateurs seront synchronisés depuis l’AD vers la metaverse (base de donnée intermediaire de DirSync), l’attribut targetAddress sera peuplé avec leur adresse mail; puis quand DirSync synchronisera la metaverse vers Office365, les utilisateurs seront synchronisés en tant que MailUser.

Création d’un groupe de ressource Cluster en Powershell

 

Vous souhaitez créer en ligne de commande un groupe de ressource Cluster.

Pour cela, il faut utiliser la ligne de commande suivante :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, XXX)

Ou XXX représente l’identifiant du groupe de ressource que vous voulez créer.

Par exemple : pour créer un groupe de ressource Hyper-V réplica Broker, vous devez saisir l’ID 115 soit :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, 115)

 

Maintenant, pour créer un groupe de ressource DHCP Cluster, l’identifiant correspondant est le 102 soit :

([wmiclass]"root\MSCluster:MSCluster_ResourceGroup").CreateGroup(“NomDuGroupe”, 102)

 

Ci-dessous, une capture d’écran qui vous donnera l’ID associé à un type de groupe de ressource Cluster.

 

image

Changement du nom de machine dans le fichier Unattend depuis WinPE 5 en Powershell

 

Vous avez appliqué une image wim sur votre poste depuis WinPe et vous avez besoin de changer le nom de machine qui sera utilisé par la phase Specialize du Sysprep avant de rebooter la machine (pour sa prise en compte).

Charger le fichier xml situé dans le répertoire Windows\Panther dans une variable. (positionné ici après le travail de généralisation du Sysprep)

$xml="C:\Windows\Panther\unattend.xml"
[xml]$xml=get-content $xml

Ensuite via cette ligne de commande, saisissez le nom de votre Poste:

$xml.unattend.settings[1].component[1].computername="NomDuPoste"

(il se peut que dans votre fichier unattend, le noeud “computername” soit positionné ailleurs. Il vous faudra alors parcourir votre variable $xml et identifier ou se trouvera le nœud.)

Maintenant sauvegarder votre fichier XML avec la modification apportée.

$xml.save("C:\Windows\Panther\unattend.xml")

Maintenant lorsque vous redémarrerez votre poste, après la passe spécialize et oobe, le hostname du poste sera celui qui aura été renseigné dans la modification apporté dans le fichier xml.

Vérification de droits d’accès à une ressource en Powershell via wmi

 

Vous souhaitez contrôler l’accès à un fichier / répertoire en ligne de commande.

Pour cela, vous pouvez utiliser la classe Win32_Directory qui contient une méthode GetEffectivePermission. Celle ci permet de déterminer si le compte dispose des autorisations qui seront spécifiés dans notre commande.

 

Tout d’abord, récupérer le répertoire (pour l’exemple) que vous désirez contrôler.

image

 

En regardant maintenant les propriétés via la commande (gwmi Win32_directory -filter "name = 'c:\\temp'") |gm , on peut voir l’accès à la méthode GetEffectivePermission.

image

 

Nous voulons contrôler si l’utilisateur courant dispose des droits d’accès en écriture sur le répertoire c:\temp.

Pour cela, il faut saisir la valeur décimale 2 pour la méthode GetEffectivePermission.

Si l’utilisateur à les droits en écriture sur cette ressource, la commande nous renverra True. Dans le cas contraire, la commande nous renverra False.

Exemple :

(gwmi Win32_directory -filter "name = 'c:\\temp'").GetEffectivePermission(X)

X correspondant au droit contrôlé.

image

L’utilisateur peut donc accéder en écriture dans le répertoire.

 

Ci dessous un tableau contenant les valeurs à indiquer à la fonction GetEffectivePermission() pour le contrôle d’un droit spécifique

image

Exchange 2010 – Problème de mot de passe avec certains Smartphones

Problématique

Sur certains smartphones (BlackBerry et Windows Phone) lors de la connexion à une boite mail Exchange 2010 (via ActiveSync) le mot de passe est demandé alors qu’il est enregistré.

Une resynchronisation de la BAL sans indiquer le mot de passe suffit au smartphone pour se reconnecter.

Contexte

L’architecture en place lors du problème se compose de plusieurs serveurs Exchange 2010 (plusieurs serveurs CAS/HUB, plusieurs MBX en DAG) et de deux serveurs TMG 2010 pour la publication des flux.

Après avoir fait des traces sur TMG, l’erreur suivante est présente à chaque demande de mot de passe :

  • Log Type : Web Proxy (Forward)
  • Status : 10054 An existing connection was forcibly closed by the remote host.

Solution

Le problème provient de TMG. En effet ce dernier possède un timeout sur la session ActiveSync entre le Smartphone et Exchange.

Pour résoudre ce problème il faut changer un paramètre dans TMG. Depuis la console TMG faites un clic droit sur le listener qui publie ActiveSync, ensuite dans Properties, Forms tab, Advanced décochez la case “apply session timeout to non-browser client” (http://technet.microsoft.com/en-us/library/cc995246.aspx).

Hyper-V et NetApp – Retour d’expérience

Introduction

Dans le cadre d’une migration de stockage, j’ai été amené à utiliser différents outils de NetApp (SnapDrive, SnapManager…).

Dans ce billet je ferai une brève présentation des différents outils utilisés ainsi que mon retour d’expérience quant à l’utilisation de ces derniers.

Environnement

L’environnement source se compose de différents serveurs Hyper-V (sous Windows Server 2008 R2 SP1 et Windows Server 2012). Toutes les machines virtuelles se trouvent sur un stockage en local.

Dans un souci de PRA / PCA, l’environnement cible se composera de différentes baies NetApp réparties sur deux sites différents. Les machines virtuelles sont donc basculées du stockage local au stockage sur la baie.

Les baies NetApp serviront également de sauvegarde.

Outils

Différents outils NetApp sont utilisés dans l’environnement cible.

SnapDrive est l’outil qui permet d’interagir entre le système d’exploitation et la baie de stockage. Il peut ainsi générer des snapshots consistants du point de vue du système d’exploitation en s’appuyant sur des fonctionnalités telles que VSS.

SnapManager for Hyper-V (SMHV) permet de réaliser des snapshots des machines virtuelles hébergées par les hosters.

OnCommand permet de gérer le stockage des baies.

Retour d’expérience

 

Installation et migration

L’installation et la configuration des outils sur les serveurs Hyper-V se font simplement. L’attachement des volumes sur la baie se fait via SnapDrive.

2014-06-20_141253

La migration des machines virtuelles sur la baie se font ensuite grâce à la fonctionnalité Live Migration d’Hyper-V (pour plus d’informations sur la Live Migration suivre ce lien http://technet.microsoft.com/en-us/library/jj134199.aspx).

Mise en place des sauvegardes

La mise en place des sauvegardes se fait en via SMHV. On associe des règles à l’hyperviseur pour les sauvegardes.

2014-06-20_142008

Les sauvegardes via NetApp se font de deux façon différentes : application consistent et le crash consistent.

L’application consistent utilise VSS au niveau de la VM afin d’assurer une consistance au niveau application. A l’inverse le crash consistent utilise VSS au niveau du hoster. Il n’y a donc pas de consistance au niveau applicatif.

N.B : Les sauvegardes de types application consistent ne fonctionnent pas avec des machines virtuelles possédant des bases de données (cela inclut également les contrôleurs de domaine). Pour ces VMs les sauvegardes seront faites qu’en crash consistent, ce qui réduit les possibilités au niveau restauration (restauration à chaud impossible par exemple). Il peut-être alors intéressant de mettre en place système de sauvegarde différents en parallèle afin d’avoir plus de fonctionnalités en cas de restauration.

L’intégration de SnapManager for Hyper-V avec OnCommand se fait uniquement ligne de commande via SnapDrive.

Cette intégration permet par exemple, la gestion automatique des sauvegardes. Dans le cas rencontré, une fois les sauvegardes effectuées une copie des données est envoyée sur la baie du site distant.

 

Conclusion

La mise en place des outils NetApp sur les serveurs Hyper-V est rapide. Les bascules des machines virtuelles du stockage local vers la baie de stockage s’avèrent beaucoup plus longues (cela dépend de la taille de la VM bien entendu). Il faut compter 30 minutes pour l’installation des outils NetApp et 15 minutes pour la migration d’une VM faisant une centaine giga-octets.

N.B : Ces estimations peuvent variées en fonction de l’environnement (vitesse des disques, temps de redémarrage des serveurs…).

La migration des VMs peut se faire à chaud via la Live Migration, ainsi la production n’est pas impactée.

Les sauvegardes des VMs sont faites assez rapidement (les sauvegardes sont uniquement basées sur le delta entre la dernière sauvegarde et l’état actuel de la VM). Une sauvegarde d’une dizaine de machines prend une dizaine de minutes en application consistent et prend quelques minutes (1-2 minutes) en crash consistent.

La réplication de la baie principale à la seconde baie prend du temps lors de la première réplication (cette initialisation doit être faite en ligne de commande sur le contrôleur de la seconde baie).

N.B : Dans le cadre du projet, cette étape s’est faite avec les baies sur le même site pour augmenter la vitesse de copie (environ 20 minutes pour 100 Go de données). Une fois les baies sur les différents sites la vitesse sera plus lente (le lien réseau entre les sites n’étant pas du gigabyte) mais les données à transférer seront moindre (delta uniquement).

Les restaurations peuvent se faire à chaud (sauvegarde de type application consistent uniquement) sur le même hoster ou en récupérant les fichiers (sur le même hoster ou un hoster différent).

Orchestrator– Scom: Correlation et “Nettoyage” d’alertes

 

L’interaction Orchestrator-Scom est intéressante sous réserve d’introduire dans les runbooks concernés un peu de corrélation afin de ne pas générer trop d’alerte et de pouvoir les clôturer automatiquement.

L’exemple ci-dessous est un peu limité. En effet:

1/ Le runbook ne détecte pas si une alerte précédente est présente.

2/ Il ne prévoit pas de cas OK associé a une fermeture automatique de l’alerte potentiellement générée avant. (sous réserve que l’on veuille cette clôture automatique) Clignement d'œil

image

 

Ajoutons a ce runbook quelques éléments:

 

image

Si le programme sort OK (Exit = 0) , le nœud “Get Not Closed Alert” cherche les alertes précédemment générées et toujours dans un état autre que Closed, puis si une plusieurs alerte sont trouvées, le nœud Close Alert les clôtures.

Si le programme sort KO (Exit <> 0), le nœud “Get Not Closed Alert” cherche les alertes précédemment générées. Si une alerte est présente, inutile d’en générer une autre pour le même problème, sinon elle est crée par le nœud Create Alerte.

L’idéal, serait dans le second cas d’incrémenter le champ Repeat count de l’alerte existante mais on attends que l’Integration Pack de SCOM intègre cette possibilité dans une prochaine version  Clignement d'œil.

Orchestrator – Script: Ressources utilisées par un runbook

 

Il n’est pas possible directement dans la console Orchestrator de faire le lien entre une instance de runbook et son process policymodule.exe.

Pour cela il faut faire le lien entre le PID du job effectivement en cours d’exécution, dans la base Orchestrator et le PID du process apparent dans le gestionnaire de tache.

Le script suivant prend en paramètre le nom du runbook.

Il est nécessaire de modifier le nom de l’instance SQL ($SQLServer)

Le script renvoi la mémoire (Private Working Set (Ko)) car cette info est particulièrement intéressante mais d’autre compteur peuvent bien sur être récupérés.

 

 

Param( #[parameter(Mandatory=$true)] [string]$Runbook ) $Global:Runbook = $args[0] $Scriptname = "getRunbookJobPid" $SQLServer = "" $SQLDBName = "Orchestrator" $SQLTempDB= "Temp_$Runbook"+"_$Scriptname" #FUNCTIONS function GetProcessInfoById { param ([int]$processId) Get-WmiObject -class Win32_PerfFormattedData_PerfProc_Process | where-object {$_.idprocess -eq $processId} | select ` @{Name="Process Id"; Expression = {$_.idprocess}},` @{Name="Private Working Set (Ko)"; Expression = {$_.workingSetPrivate / 1kb}} } #END_FUNCTIONS $SqlQuery = " SELECT MAX(DATEADD(HOUR,2,TimeStarted)) as TimeStart ,ProcessID as ProcessId ,Name as Name ,j.Status as Jstatus ,RI.status as RIStatus INTO $SQLTempDB FROM [Orchestrator].[dbo].[POLICYINSTANCES] as p WITH (NOLOCK) inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].[Jobs] as j on j.id=p.JobId inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator].[Runbooks] as R on R.Id=j.RunbookId inner join [Orchestrator].[Microsoft.SystemCenter.Orchestrator.Runtime].RunbookInstances as RI on RI.RunbookId=R.Id WHERE RI.status = 'InProgress' AND j.Status = 'Running' AND R.Name = '$Runbook' GROUP BY TimeStarted ,ProcessID ,Name ,j.Status ,RI.status DECLARE @MaxDate DateTime SET @MaxDate = (SELECT MAX(TimeStart) FROM $SQLTempDB) SELECT ProcessId from $SQLTempDB WHERE TimeStart = @MaxDate DROP TABLE $SQLTempDB" if (-not($Runbook)) { throw "Nom du runbook requis" } $SqlConnection = New-Object System.Data.SqlClient.SqlConnection $SqlConnection.ConnectionString = "Server = $SQLServer; Database = $SQLDBName; Integrated Security = True" $SqlCmd = New-Object System.Data.SqlClient.SqlCommand $SqlCmd.CommandText = $SqlQuery $SqlCmd.Connection = $SqlConnection $SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $SqlAdapter.SelectCommand = $SqlCmd $DataSet = New-Object System.Data.DataSet $SqlAdapter.Fill($DataSet) $SqlConnection.Close() #clear $ProcessId= $DataSet.Tables[0] | Select-Object -Property ProcessId -ExpandProperty ProcessId write-host "RUNBOOK: $Runbook" GetProcessInfoById $ProcessId | fl