Overblog Tous les blogs Top blogs Technologie & Science Tous les blogs Technologie & Science
Editer l'article Suivre ce blog Administration + Créer mon blog
MENU

[MDT] – Intégration d’[applications]

Publié le par damcuvelier

I. Les principales technologies

A. Les packages MSI

Les principaux commutateurs MSIEXEC à connaitre : (tapez msiexec /? pour tous les autres :-))

  • /i ou /package : Indique le nom (chemin complet) du package MSI
  • /qb ou /qn : Mode silencieux avec ou sans affichage utilisateur.
  • /allusers = 2 : Indique, si applicable, dans quel contexte utilisateur (propre à un ou tous les utilisateurs) l'application doit s'installer.
  • /addlocal : Permet d'indiquer la granularité des composants à installer, si applicable
  • TRANSFORMS= : Indique le fichier de transformation .MST à utiliser
  • /p ou PATCH= : Indique le fichier de correctif ou mise à jour.MSP à utiliser

B. Les packages installshield

Setup.exe /r /f1" C:\Repack\Appli1\inst.iss"*
ou
Setup.exe /r /f1" C:\Repack\Appli1\uninst.iss"
ou
(en mode administrateur) : @start /wait %~dp0\Setup.exe /s /f1"%~dp0\inst.iss"
ou
(en mode administrateur) : @start /wait %~dp0\Setup.exe /s /f1"%~dp0\uninst.iss"

uninstall: %~dp0\Setup.exe /M{<GUI Application>} /uninst

C. Les packages traditionnels ou hérités (legacy)

Généralement ces packages proposent généralement quelques commutateurs comme :

  • /dir: pour stipuler le dossier de destination
  • /norestart pour éviter un redémarrage
  • /loadinf: pour ajouter un fichier de configuration / de réponse
  • /saveinf: pour générer un fichier de configuration / de réponse
  • /silent ou /verysilent pour réaliser une installation silencieuse

Ces sites peuvent vous apporter des compléments d'information précieux sur les techniques d'installation silencieuses :

 

D. Les packages propriétaires

  • L'intégration de l'application au sein de l'image WIM (en réalisant l'installation manuelle avant le processus de capture) – sous réserve que l'application en question "résiste" à l'épreuve du nettoyage "sysprep".
  • Le "repackaging"

 

II. Le Repackaging

A. Conseils

il faudra être particulièrement attentif aux composants complémentaires apportés par l'application, tels que les redistribuables C++ ou autres framework.NET…

pour effectuer un repackaging par capture dans les meilleures conditions possibles, il est souhaitable de :

  • Installer une machine virtuelle avec le socle de référence (composants inclus)
  • Désactiver tous les agents, services et autres antivirus susceptibles d'interférer avec le processus de capture. (Windows Update, Defender, etc…)
  • Faire un snapshot de la VM avant toute modification. N'hésitez pas à réaliser des snapshots intermédiaires en fonction de la complexité de réalisation.
  • N'oubliez pas de supprimer les éventuels fichiers de désinstallation (inutiles si vous avez obtenu un package MSI)

B. Virtualisation d'application

La virtualisation d'application qui consiste à obtenir un package de type 'bac à sable" (sandbox) afin de l'imiter les impacts sur le système et autoriser des instances concomitantes dans certains cas. Parmi ces solutions, on retrouve les leaders du marché :

  • Microsoft AppV (Initialement Softgrid)
  • VMware Thinapp (Egalement associé à l'offre Landesk)
  • Citrix XenApp
  • Novell ZAV / Xenocode Virtual Application Studio / Spoon.net
  • Et quelques outsiders
  • Symantec SVS (Initialement Altiris et Appstream)
  • Cameyo (Gratuit)
  • Avantages
    • Cohabitation de versions concurrentes d'un même produit (ie Plusieurs JRE dans différentes instances de navigateurs, meilleure isolation avec le système
    • Streaming – L'application peut être publiée sur un portail ou un magasin distant et commencer son démarrage avant d'être totalement présente dans le cache local du poste.
  •  Inconvénients
    • Dépendance du système
    • Pas de communication transverse ni entrante vers les instances virtuelles (addins, plugins…)
    • La prise en charge des objets COM/DCOM n'est pas toujours efficiente

III. Intégration des applications dans MDT

Lancer la console "Deployment Workbench" puis développez l’arborescence jusqu’à "MDT Deployment Share … Applications" puis effectuez un clic droit "New Application".

Conservez l’option par défaut si les sources doivent être hébergées dans la structure MDT (DeploymentShare). Utilisez la seconde option si vous préférez publier les sources sur un autre serveur de fichier. Cliquez sur "Next"

Entrez le nom de l’application (obligatoire) et ajoutez éventuellement le nom de l’éditeur, la version, la langue. (Ces éléments formeront le nom dossier par défaut des sources de l’application) - Cliquez sur "Next"

Utilisez le bouton "Browse" pour sélectionner le dossier contenant les sources de l’application puis cliquez sur "Next"

Acceptez (ou modifiez) le nom de dossier proposé puis cliquez sur "Next". L’assistant vous demande alors de saisir la ligne de commande (d’installation silencieuse selon le cas de figure en [I] de ce tuto).

Si vous ne l’avez pas sous la main, entrez une commande quelconque ; cette information sera modifiable a posteriori. Cliquez 2 fois sur "Next" puis sur "Finish" une fois l’importation terminée.

Pour vérifier ou modifier les informations d’une application, sélectionnez-la puis faites un clic droit "Propriétés". Sous l’onglet "Details", vous pourrez renseigner cette fameuse ligne de commande magique "Quiet install command"  chargée de réaliser l’installation automatique.

 

 

 

IV. La meilleure solution est de ...

Faire un script powershell de déploiement de l'application.

Tester le script de déploiement sur une VM vierge de toute configuration (pour ajouter les prérequis ci besoin), faire des if/then pour ajouter les prérequis de déploiement si besoin.

Puis, intégrer le script dans la séquence de tâche de déploiement pour ajouter l'application.

Avantage: on contrôle à 100% le déploiement de l'application

Inconvénient; on doit faire un petit peu de code...

script type:

param ($install)

#Acrobat reader MSI
if($install -eq "AcroRead"){$exec = "msiexec.exe /package " + [34]chr + "$CurDir\AcroRead.msi" + [34]chr + "PATCH=" + [34]chr + "$CurDir\AdbeRdrUpd11001.msp;$CurDir\AdbeRdrSecUpd11002.msp" + [34]chr + " TRANSFORMS=" + [34]chr + "1036.mst" + [34]chr + " /passive"}

#Appli1 en installshield
if($install -eq "Appli1"){$exec = C:\Repack\Appli1\Setup.exe /r /f1" + [34]chr + " C:\Repack\Appli1\inst.iss" + [34]chr}

#etc...

$command = @'
@echo off
cmd.exe /C $exec
'@

Invoke-Expression -Command:$command

 

usage:

script.ps1 -install=AcroRead => Installera Acrobat Reader silcencieusement
script.ps1 -install=Appli1 => Installera l'application Appli1 silencieusement

Le script lancera l'installation demandée et rien d'autre. Ainsi on controlera totalement le déploiement appli par appli.

On peut ajouter du webservices avec une variable appelée à la place de la commande et ainsi mettre POUR UN PC nommé PC1:

                         [[!! CECI EST UNE THEORIE A CREUSER !!]]

$url = http://<webapp>.<youdomain>/InstallApplis.asmx
$proxy = New-WebServiceProxy $url
$spAccount = "<username>"
$spPassword = "<password>" –AsSecureString
$projectGuid = ""
$createOneNote = $false

$COMPUTERNAME=$env:COMPUTERNAME

 

# supposons que le pc se nomme PC1, on aura créé une node PC1 selon les règles XML pour les webservices:
<PC1>
    "cmd.exe /C @START /WAIT " + [34]chr + "msiexec.exe /package " + [34]chr + "$CurDir\AcroRead.msi" + [34]chr + "PATCH=" + [34]chr + "$CurDir\AdbeRdrUpd11001.msp;$CurDir\AdbeRdrSecUpd11002.msp" + [34]chr + " TRANSFORMS=" + [34]chr + "1036.mst" + [34]chr + " /passive"
    "cmd.exe /C @START /WAIT C:\Repack\Appli1\Setup.exe /r /f1" + [34]chr + " C:\Repack\Appli1\inst.iss" + [34]chr
</PC1>

$command = @'
@echo off
'@

Invoke-Expression -Command:$proxy.$COMPUTERNAME

Ceci a l'avantage de ne créer qu'un script puis si on arrive à se connecter au webservices MDT du portail d'application, on pourra créer une table applicative par PC et ainsi il y aura juste à créer les packages dans MDT puis assigner les applications aux PC.

et donc... FAIRE DU SCCM DANS MDT!!! ... no coment lol

Personnellement j'utilise la dernière solution et les lignes de commande de déploiement sont celles du I.

On peut aussi faire un MSI simple avec "advanced installer" et le lancer via le script + nettoyage de la destination, mais il faut toujours travailler sur VM pour créer le déploiement parfait qui correspond à votre client. LE MUST: donner la VM installé au client pour qu'il valide le résultat. Comme ça vous pouvez avancer dans votre projet en toute sérénité.

 

@++

Enjoy ;)

 

 

Commenter cet article