Présentation

Nous allons ici découvrir un outil graphique permettant de manipuler des images WIM au travers d’une interface GUI.

L’outil DISM_64bits_Mount-Unmount en version 1.0 est disponible sur ce lien :

https://onedrive.live.com/?cid=b370cc46ea3ab572&id=B370CC46EA3AB572%21137&ithint=folder,exe&authkey=!ANkLug_PPC-kh-8

Les chapitres que vous pouvez trouver ci dessous présentent les possibilités de l’outil DISM_64bits_Mount-Unmount :

• Changer de version DISM [nécessite l’installation du Windows Kits]
• Monter une image WIM
• Ajout de Drivers
• Ajout de Package
• Démonter une image WIM
• Création d’une image ISO WinPe [ nécessite le Windows Kits]
• Création d’un VHDX
• Appliquer une image WIM
• Obtenir des informations sur un VHDX (Module Hyper-V nécessaire)
• Capturer une image WIM
• Ajouter du contenu (index) à une image WIM

Rappel : une image wim est un fichier d’image de disque. Ce format est utilisé nativement pour les installations de Windows depuis Vista et Windows Server 2008. Pour accéder au contenu d’une image WIM et le modifier, vous devez monter l’image dans un répertoire et y apporter les modifications. Une fois les modifications effectives, vous devez démonter l’image.

Pré requis

.Net Framework 3.5 doit être installé

L’outil est packagé en 64 bits. Donc un OS en 64 bit est nécessaire pour son exécution. L’outil DISM_64bits_Mount-Unmount nécessite au minimum l’utilisation de Windows 7 qui intègre la version DISM 6.1.7600.16385.

Facultatif : vous pouvez installer les outils de déploiement présent dans une version d’ADK pour changer la version de DISM utilisé durant les opérations de l’outil.

Récupération et installation du Windows Kits (ADK 10) [Facultatif]

Vous pouvez récupérer la dernière version de ADK en version 10 via le lien suivant :

http://download.microsoft.com/download/8/1/9/8197FEB9-FABE-48FD-A537-7D8709586715/adk/adksetup.exe

Installer les outils de déploiement.

Modification de la politique d’exécution PowerShell

Il est nécessaire de modifier la politique d’exécution PowerShell pour lancer l’outil DISM_64bits_Mount-Unmount.

Lancer une fenêtre PowerShell en tant que administrateur.

Lancer la commande

Set-ExecutionPolicy unrestricted et valider.

Nous allons désormais lancer l’outil et voir ces possibilités.

Changer de version DISM [ nécessite l’installation du Windows Kits]

Lancer l’outil en tant que administrateur.

L’interface se lance

Vous pouvez sélectionner l’emplacement ou se situe votre répertoire Windows Kits. Celui ci détectera les versions d’ADK présente sur votre système.

Les version d’ADK installés dans le Windows Kits apparaissent. En sélectionnant une version d’ADK, vous utiliserez l’exécutable DISM associé pour les différentes actions de l’outil.

le bouton Unlock  permet de retirer la sélection du Windows Kits et donc la version ADK choisie. La version DISM utilisé sera alors celle présente dans votre OS nativement.

Monter une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner l’image Wim et l’index.

Sélectionner le répertoire de montage

Cliquer sur le bouton Mount pour lancer les opérations de montage

Une fenêtre PowerShell se lance pour effectuer les opérations de montage.

L’image est maintenant monté.

Ajout de Drivers

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire ou votre image est montée.

Sélectionner le répertoire ou se situe les drivers à injecter

Cliquer sur Add-Drivers pour procéder à l’injection des drivers.

Une fenêtre PowerShell se lance pour effectuer le traitement

Ajout de Package

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire ou votre image est montée

Cocher le type d’extensions ou répertoire que vous souhaitez parcourir pour l’ajout de Package et sélectionner le Package à ajouter.

Cliquer sur Add pour procéder à l’injection du Package.

Une fenêtre PowerShell se lance pour le traitement des instructions.

Démonter une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire ou est monté l’image WIM.

Cliquer sur le bouton radio Commit ou Discard et cliquer sur Unmount

Commit enregistre les modifications apportées à l’image wim.

Discard n’enregistre pas les modification apportées à l’image wim.

Une fenêtre PowerShell se lance pour effectuer le démontage.

L’image est maintenant démontée.

Création d’une image ISO WinPe [nécessite le Windows Kits]

Lancer l’outil en tant que administrateur.

L’interface se lance

Pour profiter de la fonctionnalité ISO de l’outil, vous devez utiliser Windows Kits.

Sélectionner l’environnement de construction de votre WinPe

Exemple d’environnement  de construction :

Donner un nom à votre ISO puis cliquer sur le bouton Build.

Une fenêtre PowerShell se lance pour la création de l’ISO.

Votre ISO est désormais créée dans l’environnement de construction précédemment définit.

Création d’un VHDX

Lancer l’outil en tant que administrateur.

L’interface se lance

La section VHD permet la création de VHDX.

Pour la création du VHDX vous pouvez choisir si celui ci sera  de type

• Fixed
• Dynamic

• MBR
• GPT

Vous pouvez également choisir la taille du VHDX et son emplacement de création.

Une fois les éléments de configuration du VHDX sélectionnés et définis, cliquer sur le bouton Create.

Remarque : lors de la création du VHDX, celui ci sera formaté en NTFS et monté dans l’explorateur.

Une fenêtre PowerShell se lance pour effectuer les opérations.

Le VHDX est maintenant créé et monté dans l’explorateur de fichier

Appliquer une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner l’image WIM et l’index que vous désirez appliquer

Sélectionner maintenant l’emplacement ou vous désirez appliquer l’image WIM.

Cliquer sur le bouton Apply pour lancer l’application de l’image.

L’application de l’image est désormais effectuée.

Remarque : Si vous appliquez une arborescence d’un OS Windows tel que Windows 10 ou WinPe par exemple sur une racine de lecteur, l’outil va alors détecter qu’il s’agit d’une arborescence type “OS Microsoft” et vous proposer de copier les fichiers de démarrages dans la partition système.

Si vous cliquez sur oui

Les entrées du magasin BCD ont été mis à jour.

Au prochain redémarrage du poste, il vous sera possible de démarrer sur l’OS depuis le VHD.

Obtenir des informations sur un VHDX (Module Hyper-V nécessaire)

Lancer l’outil en tant que administrateur.

L’interface se lance

Cliquer sur le bouton ci joint et sélectionner votre VHDX

Cliquer sur le bouton Infos VHDX

Des informations apparaissent sur la configuration du VHDX sélectionné.

Capturer une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner un répertoire à capturer en image WIM

Sélectionner maintenant le répertoire ou sera créé l’image WIM.

Taper le nom de fichier de l’image WIM ainsi que le nom qui sera donné à l’index; cocher des options si besoin.

Cliquer sur Go pour lancer la capture

L’opération s’effectue.

L’image WIM est désormais créée.

Vous pouvez obtenir des informations de la WIM créée en sélectionnant l’image dans la section WIM.

Ajouter du contenu (index) à une image WIM

Lancer l’outil en tant que administrateur.

L’interface se lance

Sélectionner le répertoire à capturer.

Cocher la case Append

Sélectionner l’image WIM à éditer

Ajouter le nom qu’aura le nouvel index dans l’image WIM.

Cliquer sur Go pour lancer les opérations

L’opération s’effectue.

Vous pouvez obtenir des informations sur l’image WIM en sélectionnant l’image dans la section WIM.

ADK 10

Vous pourrez trouver la version de ADK 10 (10.0.10240.16384) disponible via ce lien :

http://download.microsoft.com/download/8/1/9/8197FEB9-FABE-48FD-A537-7D8709586715/adk/adksetup.exe

une fois le kit de déploiement installé, la version détectée au travers de appwiz.cpl est 10.0.26624

En utilisant la build précédente de l’ADK, lors de l’ajout de Powershell dans le PE celui ci s’ajoutait correctement.

Cependant lors de son utilisation un message d’erreur apparaissait.

Avec cette build, l’intégration de PowerShell est fonctionnelle. 

GeneratorWinPE 1.1

L’application a été mis à jour.

Disponible ici :

https://onedrive.live.com/redir?resid=B370CC46EA3AB572!137&authkey=!ANkLug_PPC-kh-8&ithint=folder%2cexe

il est maintenant nécessaire de sélectionner le Path du Windows Kits.

Une fois celui ci définit, les versions d’ADK présentes s’’affichent :

Cette action permet de s’affranchir d’une installation avec le Path par défaut de Windows Kits sur C: par exemple.

Rappel : Présentation  de GeneratorWinPE  http://blog.piservices.fr/post/Apps-Generateur-de-WinPE.aspx

Vous pouvez maintenant via GeneratorWinPE créer votre WinPe 10 avec l’utilisation de cette version d’ADK  

Bonjour,

je vais vous présenter un générateur de Windows Pre Environment (WinPE)

Dans cette application, vous pouvez :

générer un environnement de construction Windows PE

Ajouter les fonctionnalités suivantes :

WinPE-Scripting
WinPE-NetFx
WinPE-PowerShell
WinPE-DismCmdlets
WinPE-WMI
WinPE-StorageWMI
WinPE-Dot3Svc
WinPE-HTA

Mettre la langue du PE en français

Générer une image ISO.

Remarque:

L’outil fonctionne en One Shot : création + ajout de fonctionnalités.

La simple édition d’un PE déjà construit n’est pas pris en compte.

Pré requis

L’ADK doit être installé dans son emplacement par défaut.

Exemple : C:\Program Files (x86)\Windows Kits\xx

Ou xx est la version de l’ADK

Récupération de l’outil

L’exécutable peut être récupéré ici :

https://onedrive.live.com/redir?resid=B370CC46EA3AB572!137&authkey=!ANkLug_PPC-kh-8&ithint=folder%2cexe

Nom de l’exécutable : GeneratorWinpe_x.x.exe

Plateformes validée

L’outil GeneratorWinPe a été validé dans les contextes suivant :

Lancement de l’outil

Il est nécessaire de modifier la politique d’exécution PoweShell pour lancer l’outil GeneratorWinPE car celui ci a été écrit en PowerShell.

Lancer une fenêtre PowerShell en tant que Administrateur

Taper la commande

Set-ExecutionPolicy unrestricted

et valider avec Yes.

Lancer l’outil GeneratorWinPe en tant qu’administrateur

Présentation de l’interface

Vous devez ici saisir le répertoire ou sera créé votre PE.

Attention :

· le répertoire ne doit pas déjà exister.

· La création du répertoire ne peut s’effectuer qu’à la racine du lecteur

· Pas d’espace dans le nom de répertoire

Plusieurs options s’offrent à vous :

• Mount
• Fr
• Unmount
• ISO

En cochant l’option Mount, vous pouvez ajouter des fonctionnalités au PE qui sera généré.

Unmount permet de démonter l’image si celle-ci a été montée.

Fr permet d’appliquer la langue Française au PE (clavier Azerty)

Cette option vous permet de créer une image ISO de votre PE

Vous pouvez sélectionner votre version d’ADK à utiliser

Vous pouvez sélectionner si votre PE sera de type x86 ou x64

Lock permet de lancer des vérifications et débloque le bouton Lancement.

Lancement permet de procéder à la construction du PE.

Unlock permet de débloquer l’application suite à un Lancement.

Utilisation de l’application

Sélectionner le volume et taper le nom du répertoire qui sera créé pour l’environnement de votre PE

Sélectionner Mount puis cocher les fonctionnalités vous intéressant à intégrer à votre PE.

Sélectionner la version d’ADK à utiliser et l’architecture souhaité pour votre PE

Cliquer sur Unmount, Fr et ISO

Cliquer maintenant sur Lock

Le bouton Lancement est maintenant disponible.

Cliquer sur Lancement

L’image est montée.

En fonction de différentes fonctionnalités ajoutées, vous allez avoir plusieurs fenêtres Powershell qui vont se lancer.

La fonctionnalité Scripting a été ajoutée.

La fonctionnalité NetFx a été ajoutée.

La fonctionnalité Powershell a été ajoutée.

La fonctionnalité DismCmdlets a été ajoutée.

La fonctionnalité WMI a été ajoutée.

La fonctionnalité StorageWMI a été ajoutée.

La fonctionnalité Dot3Svc a été ajoutée.

La langue Fr a été appliquée

L’image a été démontée avec prise en compte des modifications apportées

L’Image ISO a été créée

Les opérations sont finies

Vous trouverez votre image ISO dans votre environnement de construction.

Si vous exécuter CopyPe.exe dans une fenêtre PowerShell, vous aurez comme résultat :

ERROR: The following processor architecture was not found: x86.

Une petite astuce :

Lorsque vous lancez l’environnement de déploiement de l’ADK

En réalité, vous lancez le script DandISetEnv.bat.

Ce script peut être trouvé dans le répertoire suivant :

"C:\Program Files (x86)\Windows Kits\xx\Assessment and Deployment Kit\Deployment Tools"

Nous allons donc ajouter à ce script la ligne de commande Copype nous intéressant. Ainsi, l’exécutable Copype sera lancé dans le contexte de l’environnement de déploiement de l’ADK.

Comment allons-nous procéder ?

Pour ne pas modifier le script DandISetEnv.bat original, nous allons récupérer son contenu, le copier dans un emplacement temporaire et modifier ce fichier.

get-content "C:\Program Files (x86)\Windows Kits\xx\Assessment and Deployment Kit\Deployment Tools\DandISetEnv.bat" | Out-File "$env:temp\DandISetEnv.bat" -encoding ASCII

On ajoute la commande copype à la copie du fichier.

"" | Out-File -Append "$env:TEMP\DandISetEnv.bat" -Encoding ASCII

"copype x86 c:\MonPE_x86" | Out-File –Append "$env:TEMP\DandISetEnv.bat" -Encoding ASCII

Et on exécute le script

cd $env:TEMP

.\DandISetEnv.bat

Le répertoire de travail du PE est maintenant construit.

Cet article expose une astuce qui est susceptible de vous faire gagner du temps dans les phases de packaging de vos applications.

Contexte

Après quelques expériences en packaging sur ConfigMgr 12, on s’aperçoit très vite que le temps nécessaire traiter une application est extrêmement variable d’une application à l’autre. Néanmoins, je ne pense pas me tromper en disant que la tâche est simplifiée dans le cas où le fichier d’installation se présente sous la forme d’un « Windows Installer MSI ». En effet, Configuration Manager prend en charge plus facilement et détecte de nombreuses informations sur votre application. Voici par exemple quelques éléments qui sont automatiquement ajoutés :

· Informations générales (nom de l’application, version, build, éditeur…)

· La ligne de commande d’installation

· La ligne de commande de désinstallation

· Les paramètres de détection

Notez que certaines informations sont valables pour l’application, mais aussi pour le Type de déploiement Windows Installer qui est lui aussi automatiquement généré. On évite ainsi la double saisie des informations.

Remarque : Rien ne vous empêche par la suite de modifier les champs préremplis, je pense notamment aux champs d’installation et désinstallation pour greffer un éventuel script personnalisé.

Un fichier MSI étant généralement plus rapide à mettre en œuvre qu’un fichier EXE, voyons à présent une astuce pour tenter d’obtenir un fichier MSI à partir d’un EXE.

Comment obtenir un fichier MSI à partir d’un fichier EXE ?

Les éditeurs mettent généralement à disposition des fichiers d’installation parfois en fichier EXE, MSI ou EXE + MSI. Dans le cas où le MSI n’est pas disponible, voici une astuce pour tenter d’obtenir le fichier. La méthode présentée ne fonctionne pas à tous les coups, mais elle est si rapide à mettre en œuvre qu’il serait dommage de ne pas essayer.

Situation type : vous devrez ajouter une application dont la source d’installation est un fichier portant l’extension .EXE.

1. Lancer le fichier d’installation et au besoin avec une élévation avec un compte disposant des droits suffisants

2. L’installer se charge et affiche une première fenêtre de bienvenue.

3. À cet instant, rendez-vous dans le répertoire C:\Users\Votre_User\AppData\Local\Temp

Attention, il s’agit ici du compte avec lequel vous avez réalisé l’élévation de droit.

4. Le répertoire est susceptible d’être assez conséquent. Trier donc les éléments par date et rechercher un répertoire ou des fichiers MSI qui correspondent à l’heure de l’exécution du fichier.

5. Vous avez identifié un répertoire / fichier ? Vérifier qu’il s’agit bien de l’application recherchée. Notez qu’il est très fréquent que les éditeurs de logiciel encapsulent dans les fichiers EXE un premier exécutable en 32 Bits et un second en 64 Bits.

6. Si vous ne trouvez aucun fichier, c’est que le programme d’installation n’a pas réalisé d’extraction dans ce répertoire. Vous pouvez essayer de regarder également dans le répertoire : C:\Windows\Temp

Remarque : dans le cas où l’installation devra être réalisée avec des options d’installation spécifique, il faudra vérifier que le fichier MSI extrait peut réaliser une installation conforme et similaire au fichier EXE.

Contexte

Votre infrastructure System Center Configuration Manager est en production depuis plusieurs mois. La liste des applications disponibles devient de plus en plus grande et votre espace de stockage libre devient faible et atteindra bientôt un seuil critique. Vous envisagez probablement d’orchestrer une vaste opération de déplacement du répertoire contenant les sources d’installations de vos applications. C’est ce sujet que je vous propose d’aborder dans cet article à travers un retour d’expérience.

Détail des opérations

Une première étape préliminaire consiste à copier le répertoire « Sources » vers votre nouvel espace de stockage. Que ce soit un partage simple ou un espace de nom DFS je ne détaillerai pas davantage cette étape. Les données étant maintenant physiquement prêtes sur le nouvel espace cible, nous pouvons passer à la seconde étape.

L’opération suivante consiste à modifier dans ConfigMgr l’emplacement pour accéder aux fichiers d’installation. Elle pourra être menée par deux méthodes:

· La première consiste à utiliser l’interface graphique. Aucune opération en amont n'est à prévoir. Cependant, cette tâche répétitive s'accentue fortement au fur et à mesure que le nombre d’applications tend à croître.

· La seconde s’appuie sur l’exécution d’un script qui réalisera la migration en masse et de façon automatisée.

Voyons à présent les détails des actions à mener pour réaliser cette tâche

En graphique

Rien de plus simple: sélectionner votre application dans votre « Bibliothèque de logiciel », accéder aux propriétés du « type de déploiement » et repérer le champ « Emplacement du contenu ». Saisir l’UNC ou cliquer sur « Parcourir » pour renseigner le nouveau chemin. Validez ensuite le changement en cliquant sur « OK » ou « Appliquer » et le tour est joué.

En PowerShell

Un script PowerShell pourra être mis en place pour traiter l’opération de façon automatisée. Le choix d’implémenter cette méthode repose principalement sur le nombre d’applications à traiter. Un temps de préparation supplémentaire pour mettre en œuvre le script est à prévoir. C’est pourquoi vous devriez probablement privilégier cette méthode si le nombre d’applications est un multiple de cinquante ou plus.

Je ne peux rentrer dans les détails sur les opérations à mener dans le cadre de ce blog mais plusieurs articles sur le Web traitent le sujet et détaillent le script à mettre en œuvre. Vous pouvez donc vous en inspirer et l’adapter en fonction de votre besoin. Voir la section Ressources externes en bas de la page.

Impacts

Cette section porte sur une analyse des impacts potentiels sur vos servers et postes client.

Impact infrastructure ConfigMgr

Les applications modifiées seront dotées d’un nouveau numéro de révision. Une nouvelle copie du répertoire contenant la source sera donc envoyée sur les points de distribution. Un temps de propagation sera donc nécessaire pour distribuer le nouveau contenu. En cas de problème, vous pourrez envisager une opération de « Roll Back » par l'application de la révision précédente.

Impact des postes clients

Du côté des postes client et de leurs « Centre logiciel », cela se traduira par une actualisation des applications :

- Si l’application est déjà installée sur le poste, elle apparaitra de nouveau dans l’onglet « État de l’installation » comme étant « Installée ».

- Si l’application est obligatoire et qu’elle n’était pas installée sur le poste, l’agent lancer la phase d’installation.

- Si l’application est dans un état « Échec », l’agent va tenter d’installer l’application une nouvelle fois. N’ayant pas modifié le processus d’installation, il n’y a pas d’illusion à se faire sur l’issu de l’installation.

Pour conclure, il y a donc peu de risque à réaliser cette opération sur votre environnement

Ressources externes

Voici quelques liens qui traitent le sujet de la migration par script Powershell.

http://blogs.technet.com/b/configmgrdogs/archive/2013/05/09/package-amp-application-source-modification-scripts.aspx

http://www.verboon.info/2013/05/how-to-change-the-sccm-2012-package-source-path-with-powershell/

https://andrewdcraig.wordpress.com/2013/01/31/configmgr-2012-change-application-source-path/

Introduction

Dans le cadre d'une infrastructure Orchestrator 2012 R2 en haute disponibilité, il est nécessaire de créer une ou plusieurs VIP pour les services web de ce produit. Pour rappel, ils sont au nombre de deux :

• Le web service, accessible via le port 81 avec une url du type : http://nom_du_server:81/Orchestrator2012/Orchestrator.svc 
• La console web (en silverlight), accessible via le port 82 avec une url du type : http://nom_du_serveur:82/

Le sujet de la haute disponibilité n'est détaillé que pour le rôle runbook server d'Orchestrator. Concernant les services Web, il n'y a aucune documentation proposée par Microsoft à l'heure actuelle (20/11/2014).

Dans cet article, je ne détaillerai pas la création de la VIP qui n'a rien de particulier. Il s'agit plutôt de voir la configuration à réaliser sur les serveurs Orchestrator portant les services web.

Au niveau des pré requis, il est donc nécessaire d'avoir au moins deux serveurs Orchestrator répondant aux services web cités précédemment.

Erreur rencontrée

Après avoir configurée une VIP, lorsque l'on essaie d'accéder au web service, cela ne pose aucun problème. Cependant ce n'est pas le cas de la console web.

Configuration

Afin de rendre opérationnelle notre VIP pour la console web Orchestrator, il faut réaliser une série d’opération sur IIS qu’il conviendra d’exécuter une ou plusieurs fois. En voici une liste récapitulative :

• Configuration du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
• Ajout de SPN sur le compte de service Orchestrator : A réaliser une fois (via une invite de commande).
• Configuration des sites web pour l’utilisation des informations d’authentification du compte de service du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
• Implémentation de l’url utilisée par la console web pour accéder aux web services : A réaliser sur le site console web Orchestrator sur tous les serveurs (nœuds) le proposant (via IIS Manager).
• Redémarrage des sites web Orchestrator : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).

Configuration du pool d’application :

Tout d’abord, il faut se rendre dans la console IIS Manager. Par défaut, Orchestrator utilise le pool d’application par défaut alors qu’il en crée un nommé System Center 2012 Orchestrator Web Features qui est défini avec le compte de service Orchestrator. Les deux sites web doivent donc être configurés pour utiliser ce pool d’application. Pour ce faire, on sélectionne le site web Microsoft System center 2012 Orchestrator Web Service, on clique sur Advanced Settings puis on parcours la liste des pools d’application disponibles,

Il suffit ensuite de sélectionner le pool System Center 2012 Orchestrator Web Features et de valider.

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Ajout des SPNs nécessaires :

La seconde étape est l’ajout des SPN liés aux URLs utilisés pour accéder à la console web et aux web services Orchestrator au compte de service Orchestrator. Voici la liste des commandes à lancer pour ajouter les SPNs nécessaires (à noter vipihm et vipwebsvc peuvent être identiques si vous n’utilisez qu’une seule VIP pour la console web et pour les web services) :

SetSPN.exe –A HTTP/sco1 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco1.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc DOMAIN\SERVICE_ACCOUNT

Attention : N’oublier de remplacer sco1, sco2, vipihm et vipwebsvc par les valeurs de vos noeuds Orchestrator et de vos VIPs. DOMAIN\SERVICE_ACCOUNT doit être remplacé par votre compte de service.

NB : Cette opération n’est à réaliser qu’une seule fois.

Utilisation des informations d’authentification du compte de service du pool d’application :

Nous devons ensuite définir l’utilisation des informations d’authentification du compte de service du pool d’application sur les différents sites web. On sélectionne l’un des sites web Orchestrator dans IIS Manager puis on choisit Configuration Editor : Il faut parcourir l’arborescence jusqu’au niveau : system.webServer, security, authentication, windowsAuthentication.

Enfin, la propriété useAppPoolCredentials doit être défini à la valeur True.

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des noeuds Orchestrator portant ces sites.

Définir l’url utilisée par la console web pour accéder aux web services :

La dernière étape consiste à définir l’url utilisée par la console Orchestrator pour accéder aux web services. Dans IIS Manager, il faut sélectionner le site web Microsoft System center 2012 Orchestrator Orchestration console et cliquer sur Application Settings.

La valeur de l’attribut ScoServiceUri doit être changée avec la valeur de la vip : http://nom_vip:81/Orchestrator2012/Orchestrator.svc

Attention, si comme moi, vous décider d'effectuer un transfert de port (81 vers 80), alors il faudra supprimer ce dernier de l'URL : http://nom_vip/Orchestrator2012/Orchestrator.svc"

NB : L’opération ci-dessus est à réaliser pour le site Microsoft System center 2012 Orchestrator Orchestration console sur la totalité des nœuds Orchestrator portant ces sites.

Redémarrage des sites web :

 

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Une fois l'opération effectuée, la VIP est opérationnelle.

A titre informatif, l'environnement sur lequel la configuration a été testée était composé d'un HLB F5 possédant une VIP avec transfert de port 81 vers 80 pour le web services et une autre VIP pour la console Silverlight (port 82 vers 80). Cependant, cette configuration est valable quelque soit l'environnement.

Part 3 - Office Customization Tool

Cet article traite l’intégration de la suite Microsoft Office 2013 dans l’outil Microsoft Deployment Toolkit 2013

Office Customization Tool

Vous avez maintenant accès à la console Office Customization Tool

Au lancement de l’outil, un message vous indique qu’il faudra enregistrer le fichier MSP dans le répertoire suivant : %VotreDeploymentShare%\Applications\ Microsoft Office Professional Plus 2013\Updates
Dans le cas contraire, votre configuration ne sera pas prise en compte. Cliquez sur OK

Une fenêtre vous propose deux options :

       o Créer un nouveau fichier de configuration d’installation

       o Ouvrir un fichier existant

Gardez la première option, puis cliquez sur OK

Une nouvelle fenêtre vous propose de définir le support pour l’ouverture et la fermeture des fichiers. Laissez l’option par défaut et cliquez sur OK

Comme vous pouvez le constater, il y a quatre catégories dans l’outil Microsoft Office Customization Tool.

Première catégorie : Installation

Il est possible de spécifier :

       o Le chemin d’installation par défaut

       o Le nom de l’organisation

La page Sources réseau supplémentaires vous permet d’ajouter des partages réseau supplémentaires contenant les fichiers d’installation d’Office 2013. Ce paramétrage permet  de rendre l’installation du produit Office hautement disponible.

Sur la page suivante nommée Licences et interface utilisateur, nous pouvons :

       o Saisir la clé d’activation du produit

       o Accepter les termes du contrat de licence

       o Choisir le niveau d’affichage

       o Aucun

       o Simple

       o Complet – par défaut

Spécifier certaines options dans le cas d’une installation en Affichage de niveau               Complet

       o Avertissement de fin d’opération : Activer le récapitulatif post installation

       o Supprimer la boite de dialogue modale : ne pas afficher les messages d’erreur qui pourrait survenir dans le cas d’une installation en affichage Complet

       o Annulation interdite : Ne pas laisser la possibilité à l’utilisateur d’annuler l’installation

Vous trouverez également quatre autres pages permettant de :

       o Supprimer les anciennes installations

       o Ajouter des programmes supplémentaires en exécutant par exemple des fichiers : .exe .com .bat .src

       o Ajuster les paramètres de sécurité. Peut être utile dans le cas d’utilisation d’un outil basé sur les Macros par exemple

       o Modifier des propriétés de l’installation

Première catégorie : Fonctionnalités

Modification des paramètres utilisateurs
Il est possible de changer les paramètres de sécurité, désactiver certains éléments de l’interface utilisateur, activer/désactiver les notifications.

Mise à disposition des fonctionnalités
Cette page importante propose de gérer les produits Office qui seront: disponibles, indisponibles, imposés et aux choix de l’utilisateur. Voici l’interface permettant de choisir les fonctionnalités.

En dépliant un produit, on accède aux différents modules qui le composent.

Un clic droit sur un produit permet d’obtenir le menu suivant :

       o Tout exécuter à partir du disque dur: le produit sera installé avec les composants par défaut

       o Tout exécuter à partir du disque dur: le produit sera installé avec la totalité des composants par défaut

       o Non disponible: Le produit ne sera pas installé

Les options suivantes permettent de paramétrer l’application dans le cas d’un Niveau d’affichage = Complet

       o Masqué: L’application ne sera pas visible lors de l’installation

       o Verrouillé: L’application sera bloquée dans l’état défini dans OCT

       o Rétablir: Réinitialise les valeurs par défauts

Troisième et quatrième catégories : Contenu additionnel et Outlook

La troisième catégorie permet d’ajouter du contenu additionnel en proposant :

       o Gérer les fichiers

       o Gérer les clés de registre

       o Gérer les raccourcies

La quatrième et dernière catégorie est orientée sur la personnalisation de l’application Outlook.

Enregistrement du fichier MSP

La configuration est prête. La dernière étape consiste à enregistrer votre fichier de réponse. Sélectionner Fichier \ Enregistrer sous.

N’oubliez pas d’enregistrer le fichier de réponse au format MSP dans le répertoire Updates. Sans quoi votre configuration ne sera pas prise en compte. Par exemple : %VotreDeploymentShare%\Applications\Microsoft Office Professional Plus 2013\Updates

Déploiement

L’installation de l'application Office 2013 est maintenant personnalisée et prête à être déployée. Grâce à votre environnement Microsoft Deployment Toolkit l’installation est automatisée et capable d'être déployée en masse lors de la création d’un nouveau poste de travail.

Introduction

• Partie 1 : introduction et syntaxe
• Partie 2 : configuration du mode push
• Partie 3 : configuration du mode pull (via smb)
• Partie 4 : configuration du mode pull (via web service)
• Partie 5 : création d’une ressource personnalisée

Desired State Configuration est disponible comme Powershell 4.0 sur Windows 2012 R2/8.1, Windows 2012/8 et Windows 2008 R2/7.

Lors du précédent article nous avons vu l'implémentation du mode Pull via un web service.

Desired State Configuration est fourni avec un certain nombre de ressources. Malgré qu'il y en ai peu, et comme évoqué dans le précédent article, Microsoft et la communauté se sont employés à créer des nouvelles ressources. Dans cette cinquième et dernière partie, nous évoquerons la création d’une ressource personnalisée. Cette dernière permettra de prendre en charge un scénario non présent dans les ressources existantes : la présence d'un partage NFS.

Fonctionnement

• Un fichier .SCHEMA.MOF contenant sa définition et plus particulièrement toutes les propriétés que l'on pourra renseigner.
• Un module Powershell contenant quelques fonctions obligatoires (.PSM1)
• Un fichier .PSD1 représentant le manifest du module Powershell. Ce dernier contiendra les fonctions a exporter de notre module. Ce dernier est principalement utilisé pour versionner le module et avoir quelques informations dessus.

Le module Powershell doit obligatoirement comporter trois fonctions. Elles seront appelées lorsqu'un fichier de configuration contiendra une ressource du type que l'on aura créé. “Get-TargetResource” permet de récupérer la configuration telle qu'elle a été définie. “Set-TargetResource” applique une configuration (création, modification et suppression) et “Test-TargetResource” effectue le test de validité (elle retourne un booléen).

Il convient à la personne créant le module de développer le corps de ces fonctions (le squelette étant toujours identique), c'est à dire les paramètres et les process effectués.

Pré-requis

Au lancement de Powershell 4.0, il pouvait être fastidieux de développer ses propres ressources car il fallait respecter une certaine syntaxe. Cependant, Microsoft a développé un module permettant de faciliter la création de ressource à destination de DSC : xDscResourceDesigner. Ce dernier va nous permettre de générer nos fichiers automatiquement. Il est disponible en suivant le lien ci-dessous : http://gallery.technet.microsoft.com/scriptcenter/xDscResourceDesigne-Module-22eddb29

Il suffit ensuite de placer ce module dans le dossier :
“C:\Program Files\WindowsPowerShell\Modules”.

Création de la ressource

Pour créer la ressource, on commence par définir ses propriétés avec la cmdlet “New-xDscResourceProperty”. Celles-ci possèdent à minima un nom, un type et des attributs. Ces derniers permettent de définir l'accessibilité (lecture, écriture,...). Lorsque l'on définit une nouvelle ressource, au moins une de ses propriétés devra posséder l'attribut “Key” et ne pourra être un tableau. Cet attribut permet d'indiquer la propriété utilisée lors de la recherche d'une ressource.

• le nom du partage
• le chemin vers lequel le partage pointe
• la présence ou l'abscence du partage

Un module Powershell qui ne comprend pour l'instant que le fichier .PSM1 a aussi été généré. Il faut maintenant définir la logique de nos 3 fonctions à l'intérieur de ce module.

Get-TargetResource

Set-TargetRessource

NB : Lors de la génération du template de module à remplir, il est indiqué dans le corps de la fonction qu'il faut positionné la variable globale “$global:DSCMachineStatus” avec la valeur 1 si une configuration nécessite un reboot après son application.

Test-TargetResource

A noter, qu'à la fin de notre module, la cmdlet “Export-ModuleMember” est présente et obligatoire afin que Powershell découvre correctement les méthodes de la ressource.

Génération du manifest

Les autres champs du fichier .PSD1 généré peuvent aussi être spécifiés via la cmdlet précédente ou en remplissant manuellement le fichier (via un éditeur de texte). Certaines propriétés seront même automatiquement remplies (exemple : auteur avec le samaccountname de l'utilisateur ayant lancé la commande).

Voici un lien menant vers le manifest généré pour cette ressource : Manifest

Import de la ressource et utilisation

Il suffit de placer notre ressource (Répertoire C:\NFSShare dans notre exemple) dans “C:\Program Files\WindowsPowerShell\Modules\”

 

Conclusion

Lors de cet article, nous avons vu la création d'une ressource permettant de gérer des partages NFS. Il est possible de l'améliorer en gérant d'autres propriétés de ce type de partage comme les permissions. 

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