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/

Suite à la distribution de la mise à jour de sécurité Office MS14-082 le 9 décembre 2014, vous rencontrez un problème avec l’exécution de vos documents Excel contenant des macros et contrôles ActiveX ? Si la réponse est oui, cet article peut vous intéresser.

Comment se matérialise l’incident ?

Selon l’article officiel disponible ici, Microsoft liste plusieurs symptômes permettant d’identifier l’incident. Pour faire simple suite à l'application de la mise à jour, l’incident vous empêche d’exploiter vos fichiers Office contenant des macros et contrôles ActiveX. Dans notre situation, l’activation du contenu actif d’un fichier Excel contenant des macros était devenue tout simplement impossible.

Dans le détail : L’installation de la mise à jour créée une désynchronisation des bibliothèques de types de contrôle mises en cache (Fichiers portant l’extension .exd)

Vous trouverez ci-dessous les références des mises à jour qui génèrent l’incident :

· Security Update for Microsoft Office 2007 suites (KB2596927)

· Security Update for Microsoft Office 2010 (KB2553154)

· Security Update for Microsoft Office 2013 (KB2726958)

Quels sont les produits impactés ?

Les suites Office 2007, 2010 et 2013 peuvent être impactées par l’installation du correctif. En détail :

· Microsoft Excel 2013

· Microsoft Word 2013

· Microsoft PowerPoint 2013

· Microsoft Visio Standard 2013

· Microsoft Visio Professional 2013

· Microsoft Excel 2010

· Microsoft Word 2010

· Microsoft PowerPoint 2010

· Microsoft Visio Professional 2010

· Microsoft Visio Premium 2010

· Microsoft Visio Standard 2010

· Microsoft Office Excel 2007

· Microsoft Office Word 2007

· Microsoft Office PowerPoint 2007

· Microsoft Office Visio Professional 2007

· Microsoft Office Visio Standard 2007

Comment résoudre le problème ?

Vous pouvez appliquer la solution préconisée ci-dessous :

1. Fermer les classeurs Excel

2. Ouvrir l'explorateur Windows

3. Sélectionner le disque C:

4. Saisir dans la barre de recherche la chaîne de caractères suivante : *.exd

5. Lancer la recherche (attendre que la recherche soit terminée)

6. Plusieurs éléments portant l'extension exd vont être trouvés. Sélectionner et supprimer l'ensemble des éléments trouvés

7. Ouvrez de nouveau votre fichier Excel. Le problème devrait disparaître.

Sources d’informations

Si besoin vous trouverez des informations complémentaires sur les liens ci-dessous :

http://stackoverflow.com/questions/27497444/excel-2010-command-button-no-longer-activate-its-click-event

https://social.technet.microsoft.com/Forums/en-US/b8f0af82-0bb8-4799-aa62-1dbcbc5b7742/excel-2010-macros-does-not-work-after-updates-9dec2014?forum=excel

http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2014/12/11/forms-controls-stop-working-after-december-2014-updates-.aspx

Part 1 – Pré requis et création de l’application

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

Cette première partie est consacrée à la préparation de l’installation d’Office 2013 : Vérification des prérequis, explication sur les différentes versions office, ajout de l’application dans votre Deployment Share.

Pré requis

Environnement

Afin de préparer le déploiement d’Office 2013 via MDT, merci de vérifier que les points suivants sont validés dans votre environnement :

· Composants à installer sur votre server :

             o Microsoft Deployment Toolkit 2013

             o Windows Assessment and Deployment Kit 8.1

             o Le rôle Windows Deployment Services doit être configuré et actif

· Votre Deployment Workbench doit contenir les éléments suivants :

            o Un Deployment Share actif

            o Un système d’exploitation dans la section Operating Systems

            o Une séquence de taches

· Les sources d’installation d’Office 2013 Edition Professional Plus volume licence (détaillé dans la section suivante)

D’une manière générale, vérifier que votre environnement MDT est capable de déployer votre Séquence de Tache sans erreurs.

Office 2013

Microsoft livre avec les packages d’installations de la suite Office un outil nommé Office Customization Tools (OCT). Cet outil est dédié à la personnalisation d’Office. Avec celui-ci, un assistant nous offre la possibilité de personnaliser complètement l’installation du produit. Une fois la personnalisation terminée, un fichier de réponse est créé.

Remarque : L'outil OCT n'est pas disponible avec les versions Retail d’Office.

Cette remarque impose une explication sur les différences entre les versions d’Office 2013.

Il existe deux modes de licensing : Retail et Volume License. Le premier est utilisé par les utilisateurs des secteurs grand public et petites entreprises. Le second est adapté aux grandes entreprises.

Vous trouverez ci-dessous le détail des versions Office 2013 pour chaque mode de distribution :

· Office Retail

            o Office Famille et Étudiant 2013

            o Office Famille et petite Entreprise 2013

            o Office Professionnel 2013

· Office Volume License

            o Office Standard 2013

            o Office Professionnel Plus 2013

« Comment reconnaitre un produit Office Volume License ou Retail ? »

Les éditions Volume disposent de fichiers supplémentaires dans les sources de l’installation. Pour vous assurer que vous disposez bien d’une version VL, vérifier la présence d'un répertoire « Admin » à la racine de votre média (cf. les captures ci-dessous).

Notez que le déploiement d’Office est tout de même possible avec une édition Retail, mais sans la personnalisation avec Office Customization Tool.

Vu du répertoire Office en version Retail

Vu du répertoire Office en version Volume License

Création de l’application

Ce chapitre est consacré à l’ajout de Microsoft Office dans votre environnement de déploiement. Pour démarrer, rendez-vous dans la console Deployment Workbench.

Positionnez-vous sur l’onglet Applications de votre Deployment Share, faites un clic droit et sélectionnez New Application. Une nouvelle fenêtre s’ouvre.

Type de l’application

La première étape consiste à spécifier le type de notre application. Dans mon cas, je dispose des sources d’installation du produit donc je choisis la première option : Application with source files (ce qui devrait être probablement votre cas).

Informations sur l’application

Cette seconde partie nous permet de remplir diverses informations sur notre application.

Emplacement des fichiers d’installations

À présent, indiquons le répertoire qui contient les sources d'installation. Cliquez sur browse et recherchez le répertoire.

Nom du répertoire de l’application

Cette étape permet de définir le nom du dossier qui contiendra l’application sur votre répertoire applications.

Ligne de commande

Command Détails permet de renseigner la ligne de commande permettant l’installation du produit :

· Command Line : Ici, on inscrit setup.exe car c’est le nom de l’exécutable qui lance l’installation d’office 2013.

· Working Directory : Spécifier ici l’emplacement du répertoire qui contient le fichier d’installation. Dans notre cas, setup.exe est à la racine du dossier. Il n’y a aucun changement à effectuer.

Résumé

Cette dernière étape affiche un résumé du processus d’ajout de l’application. Vous retrouverez donc l’ensemble des informations renseignées

Progress

L’assistant copie le contenu du dossier d’installation et créer ensuite l’application.

Confirmation

À la fin de la création, la mention The process completed successfuly devrait s’afficher. L’application est maintenant disponible pour vos futurs déploiements.

L’application est visible depuis la console Deployment Workbench

Je vous propose de découvrir les options permettant d’automatiser l’installation de la suite Office dans la prochaine partie.

Part 2 – Paramétrage Office 2013

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

Paramétrage et automatisation Office 2013

Ce chapitre nécessite que vous disposiez d’une version Office 2013 en version Volume License.

Pourquoi utiliser Office Customization Tool ?

Dès maintenant, l'application Office 2013 est prête à être déployée. Cependant, il n’y a aucun mécanisme d’automatisation adapté à un déploiement via MDT. L’installation du produit sera similaire à une installation classique par un DVD (ou tout autre support) avec l’assistant d’installation. L’intérêt de cette option n’est pas adapté à un mode de déploiement de postes de travail industrialisé.

Pour automatiser l’installation de la suite Office, il est nécessaire de générer un fichier de configuration depuis l'outil Office Customization Tool.

Premier paramétrage

Pour commencer, sélectionner dans le Deployment Workbench l'application puis un clic droit. Sélectionner ensuite Properties

Dans la nouvelle fenêtre, vous constaterez qu’il y a quatre Onglets :

          o General

          o Details

          o Dependencies

          o Office Products

Onglet général (commun pour toutes les applications):

Cet onglet permet de définir les informations suivantes :

· Nom, Commentaire, Version, Langage, Répertoire source, le GUID de l’application.

Sur la partie inférieure de la fenêtre, nous trouvons deux options:

· Masquer l’application

· L’application ne sera pas visible sur la partie Applications lors d’un déploiement Lite Touch

· Activer l’application

          o Décocher cette option rend l’application indisponible pour les déploiements

Onglet Détails (commun pour toutes les applications):

Onglet Dependencies (commun pour toutes les applications):

Onglet Office Products (propre et dédié à la personnalisation des applications Office):

C’est dans cet onglet que l’automatisation du logiciel va prendre forme. Pour le moment, une grande partie des champs sont bloqués. Sélectionner le menu déroulant Office Product to Install et Cliquez sur ProPlus.

Remarque : Si vous ne voyez pas le bouton Office Customization Tooll en bas à droite de la fenêtre, c’est que vous utilisez une version Retail. Néanmoins vous pourrez tout de même configurer l’installation sans l’Office Customization Tool. (Traité dans le paragraphe ci-dessous)

Sélectionner l’élément ProPlus dans le menu déroulant. Les champs sont maintenant accessibles et paramétrables. Voici quelques une des options :

· Office language : Si votre répertoire d’installation comporte plusieurs langues, sélectionner celle que vous souhaitez installer.

· Product Key : Ajoute la licence du produit

· Display Level : Paramètre le niveau d’information durant l’installation à l’utilisateur. Trois niveaux sont disponibles :

          o None : Aucune fenêtre ne sera affichée durant l’installation

          o Basics : Le minimum d’information vous sera présenté, l’utilisateur peut suivre la progression de l’installation

          o Full : Niveau par défaut. L’intégralité de l’interface est proposée à l’utilisateur. Aucune automatisation.

· Accept EULA : accepte les termes du contrat d’utilisation

Le bouton Add permet d’ajouter un pack de langue ou une application

Il est possible d’éditer directement ce fichier en cliquant sur Edit Config.xml. La modification des paramètres met à jour le fichier Config.xml dans cette boite de dialogue

Le bouton Office Customization Tool permet de lancer l’assistant. Notez qu’il faut en amont appliquer les modifications avant de pouvoir lancer OCT, sinon le message suivant s’affichera

Je vous propose de traiter dans le troisième article les différentes options permettant de personnaliser l’installation de l’application avec Office Customization Tool.

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.

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

Cet article indique les étapes à réaliser pour exécuter un script PowerShell durant vos déploiements.

Ajout des fonctionnalités

La première étape consiste à mettre à jour votre image de boot pour la rendre compatible avec l’exécution des scripts PS. Pour ce faire, il est nécessaire d’ajouter des fonctionnalités à votre environnement Win PE. Rendez-vous donc dans les propriétés de votre « Deployment Share ».

Sélectionner l’onglet « Windows PE », puis l’architecture de votre plateforme (x86 ou x64) et enfin cliquer sur « Features »

Cette fenêtre vous permet de visualiser les fonctionnalités disponibles. Dans notre cas, pour permettre l’utilisation des scripts PowerShell, il est nécessaire d'ajouter les composants suivants :

• Microsoft Data Access Components (MDAC/ADO) support
• NET Framework
• Windows PowerShell

Mise à jour de l’image Win PE

Maintenant que les composants ont été sélectionnés, il faut mettre à jour votre Deployment Share. Cette opération va régénérer votre image WinPE avec les nouvelles fonctionnalités. Pour ce faire : Clic droit sur « Deployment Share » puis sélectionner « Update Deployment Share »

Sur l’assistant de mise à jour, vous pouvez laisser les options proposées par défaut.

Cliquez sur Next. L’assistant affiche un résumé. Cliquez une nouvelle fois sur Next pour démarrer le processus de mises à jour de l’image.

La durée de l’opération peut prendre quelques instants. Patienter jusqu’à la fin du processus.

Après avoir vérifié que l’opération s’est déroulée correctement, cliquez sur Finish pour fermer la fenêtre.

Je vous invite à vous rendre sur la seconde et dernière partie. Celle-ci traite l’ajout de l’image Wim dans WDS et l’ajout d’un script Powershell dans une séquence de tâches.

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.

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 »

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

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.

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 ».

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).

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.

Je vous propose de faire un tour d’horizon de l’outil Application Compatibility Toolkit 6.1. Cet article se décompose en trois parties :

Partie 1 : Introduction et installation

Partie 2 : Création et déploiement de l’outil d’inventaire

Partie 3 : Analyse et exploitation des données colletées

Introduction

Application Compatibility Toolkit 6.1 permet d’aider les équipes IT dans le processus de migration vers un nouveau système d’exploitation. L’objectif de l’outil est de fournir des informations sur la compatibilité des applications présentes dans votre parc.

Sur quels systèmes d’exploitation peut-on collecter des informations sur les applications ?

L’inventory Collection Package peut être exécuté pour collecter des informations sur les applications installées sur les systèmes suivants :

• Windows 8.1, 8, 7, Vista, XP et 2000
• Windows Server 2012R2, 2012, 2008 R2, 2008, 2003 R2 et 2003

Fonctionnement

Depuis la console Application Compatibility Toolkit, on génère un package qui sera chargé d’inventorier les applications des postes de travail. Après exécution du package, les données collectées seront stockées sur un partage réseau dédié.

ACT s’appuie sur un service nommé « ACT Log Processing Service ». Celui-ci analyse les informations contenues dans les fichiers déposés sur le partage réseau. Puis, les données du poste de travail sont ajoutées dans la base de données.

Enfin depuis la console ACT, vous exploitez les informations sur la compatibilité des applications depuis la base de données.

Mise en place

Dans un premier temps, il faut tout d’abord installer l’outil Application Compatibility Toolkit. Il est disponible dans le Kit de déploiement et d’évaluation Windows 8.1 (ADK 8.1). À télécharger gratuitement ici.

Depuis l’assistant d’installation ADK 8.1, vous devez ajouter les composants suivants :

• Application Compatibility Toolkit (ACT)
• Microsoft SQL Server 2012 Express

Préparation

Système d’exploitation

Application Compatibility Toolkit doit être installé sur l’une des plateformes suivantes :

• Windows 8, 7, Vista (SP2) et XP(SP3)
• Windows Server 2012, 2008 R2, 2008 (SP2)

Base de données

Application Compatibility Toolkit a besoin d’une base de données pour fonctionner. Voici la liste des versions SQL Server supportées :

• Microsoft SQL Server 2012
• Microsoft SQL Server 2008 R2
• Microsoft SQL Server 2008
• Microsoft SQL Server 2005

Quelles sont les versions de SQL Server supportées ?

Si vous disposez déjà d’un serveur SQL, vous pouvez choisir de:

• Créer une nouvelle base de données sur une nouvelle instance SQL
• Créer une nouvelle base de données sur une instance SQL déjà existante

Si vous n’avez pas de serveur SQL, installer une version SQL Server Express disponible gratuitement avec ADK.

.Net Framework

ACT 6.1 nécessite le composant .Net Framework 4.

Configuration

Après l’installation d’ACT 6.1 et SQL Express 2012, vous devez configurer l’application.

Lancer Application Compatibility Toolkit

L’assistant vous propose d’installer le service « ACT Log Processing Service ». Ce service permet de traiter les données des postes de travail puis de les intégrer dans la base de données SQL. Sans ce service, votre base de données ne sera pas alimentée. Sélectionnez « Yes » puis cliquez sur « Next »

L’étape suivante configure la base de données SQL. Sélectionner votre serveur SQL et la base de données à utiliser.

La prochaine étape détermine le répertoire où seront stockées les données collectées sur les postes. Indiquez un chemin local et le nom du partage réseau à créer. Comme l’indique l’assistant, vérifiez que les postes clients disposent des droits en écriture dans ce répertoire.

La prochaine étape vous propose de renseigner le compte à utiliser pour exécuter le service « ACT Log Processing Service ». Deux options s’offrent à vous :

• Utiliser le compte local System (par défaut)
• Utiliser un compte de service.
  Si vous retenez cette dernière option, vérifier les points ci-dessous. Le compte doit :
• Être autorisé à ouvrir une session en tant que service.
• Disposer des droits en écriture sur le répertoire contenant les fichiers collectés
• Disposer des droits en écriture sur la base de données

La configuration de l’outil touche à sa fin. Cliquez sur Finish

L’outil Application Compatibility Toolkit est maintenant installé et configuré. Je vous propose maintenant de passer à la partie 2 : Création et déploiement de l’outil d’inventaire