Contexte

Lors d’une migration d’Exchange 2007 vers Exchange 2013 CU6 (dernière version en date) certains problèmes sont rencontrés lors de la coexistence entre les deux systèmes.

Problématique

Les problèmes rencontrés sont les suivants :

• Problèmes de cohabitation sur le protocole ActiveSync
• Bascule des bases de données Exchange de façon aléatoire

Ces deux problèmes sont résolus par deux hotfix que Microsoft délivre seulement sur demande au support :

• http://support.microsoft.com/kb/2997847/en-us
• http://support.microsoft.com/kb/2997209/en-us

Cependant le passage de ces correctifs peut engendrer deux nouveaux problèmes :

• Impossibilité d’accéder à l’OWA
• Impossibilité d’écrire un mail dans OWA

Solution

Pour résoudre ces problèmes il faut se connecter sur le serveur Exchange puis identifiez les deux dossiers suivants :

• Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.31
• Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.29

Le contenu des dossiers doit être identique. Sauvegardez le contenu du dossier 15.0.995.31 puis copiez les éléments du dossier 15.0.995.29 vers le dossier 15.0.995.31.

N.B : Le CU7 d’Exchange 2013, disponible très prochainement, devrait intégrer les deux correctifs (KB2997847 et KB2997203).

Qu’est-ce que l’option GEO

L’option GEO des boitiers KEMP permet d'effectuer un équilibrage de charges multi-sites (sites internationaux). Cette option est conçue gérer un équilibrage de requêtes entre plusieurs datacenter en fonction de l’adresse IP publique du serveur DNS émetteur de la requête. Ainsi un utilisateur qui se trouve en France sera basculé vers les serveurs du site Français et un utilisateur qui se trouve aux Etats-Unis sera basculé sur les serveurs du site Américain.

L’option GEO fonctionne via le DNS. Les boitiers possédant l’option GEO deviennent des “serveurs DNS” autoritaire sur un FQDN (exemple : kemp.piservices.fr). Lorsqu’un utilisateur veux accéder à kemp.piservices.fr son serveur DNS le renverra vers un des boitiers GEO (au hasard, comme le veut le fonctionnement classique du DNS). Le boitier GEO récupère la position géographique du serveur DNS et lui indiquera le site le plus proche où se connecter.

Retour d’expérience

L’utilisation de l’option GEO peut également être utilisé dans un scénario LAN (en plus de son usage « traditionnel »). Dans ce cas les avantages sont :

• La possibilité d’avoir un système de load balacing Actif / Actif (impossible à réaliser chez Kemp sans l’option GEO)
• La possibilité d’équilibrer les requêtes provenant de certains sites distants sur un HLB en particulier avec fail-over vers un autre HLB (sous réserve que chaque site distant dispose de son propre DNS)

La mise en place de cette option sur les boitiers KEMP est rapide. Tout d’abord l’ajout du FQDN.

Ensuite l’ajout des adresses IP correspondantes au FQDN avec le choix des localisations.

Enfin il est nécessaire de faire une délégation DNS sur le FQDN.

L’option GEO possède néanmoins une limite, il est en effet impossible de créer des localisations personnalisées (exemple : plusieurs villes d’un même pays). Il est tout du moins possible d’ajouter des adresses IP (des serveurs DNS) à des pays. Avec cette méthode il est alors possible d’affiner la localisation à des villes ou des sites plus rapproché géographiquement.

Introduction

Dans un précédent article, nous avons découvert l'agent de scripting dans Exchange (http://blog.piservices.fr/post/Exchange-Decouverte-de-lagent-de-scripting.aspx). Pour rappel, cela permet  les fonctionnalités de base des cmdlets Exchange. Ainsi, on peut par exemple ajouter automatiquement une boîte d'archive au moment de la création de sa boîte aux lettres. Pour que cette opération fonctionne, il faut activer l'agent de scripting via la cmdlet “Enable-CmdletExtensionAgent”.

Cependant, si vous êtes amenés à désactiver cet agent ultérieurement, vous pouvez rencontrer de nombreuses erreurs avec l'event ID “6” dans le journal “MSExchange Management”.

Ces erreurs peuvent être normales, lorsqu’un administrateur Exchange s'est trompé dans la syntaxe d'une cmdlet Powershell.

Contexte

Dans certaines situations ces erreurs sont à l’origine du mauvais  fonctionnement d'un composant tiers. En l'occurrence, comme nous allons le voir ici, il s'agit de System Center Operations Manager (SCOM). En effet, le Management Pack SCOM d'Exchange lance de nombreuses cmdlets afin d'effectuer des tests de vérification d'intégrité de l'infrastructure Exchange. A cause, de cette erreur, la supervision de l'infrastructure Exchange peut ne plus être opérationnelle.

Explication

Il est indiqué qu'Exchange ne trouve pas le fichier de configuration de l'agent de scripting : “File is not found: 'D:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml'”.

Cependant, si l'agent de scripting a été désactivé, il n'y a aucune raison qu'il soit utilisé. Pour rappel, le fichier de configuration ne doit être présent que si l'agent de scripting est démarré. Il est à noter que même si ce fichier est présent, l'erreur continue d'apparaître. Le message indiqué dans l'erreur n'est donc pas pertinent. En réalité, il s'avère que le service “Exchange Monitoring” ne prend pas en compte le changement de configuration. Il est utilisé par le management pack SCOM et permet d'executer toutes les cmdlets de diagnostics comme “Test-PopConnectivity”, “Test-MRSHealth”, “Test-ReplicationHealth”, ...

Résolution

Pour résoudre cette erreur, il suffit de redémarrer le service "Exchange Monitoring". Ainsi, la configuration des cmdlets extensions agents sera correctement prise en compte. 

Pour information, ce service peut être redémarré sans incidence.

NB : Il faut redémarrer ce service sur tous les serveurs de l'organisation Exchange car l'opération d'activation/désactivation de l'agent de scripting se fait sur la totalité de ceux-ci.

Une problématique très commune dans la gestion quotidienne d’une infrastructure SCOM est la cloture par un opérateur humain d’alertes générées par un moniteur : dans ce cas, le moniteur reste dans son état warning ou critical mais l’alerte n’est plus présente et n’est jamais re-générée, empêchant donc les opérateurs de s’apercevoir du problème.

La bonne pratique est bien entendu de résoudre le problème à l’origine de l’alerte, ce qui permettra au moniteur de revenir à son état Healthy et donc à l’alerte de se cloturer automatiquement.

Afin de se prémunir contre ce genre de problème, il est possible de déclencher une action automatique qui vérifiera si une alerte cloturée l’a été par un compte autre que “System” a été générée par un moniteur : le cas échéant, un script réinitialisera le moniteur à l’origine de l’alerte, de facon à ce qu’il puisse repasser en critical ou warning et que l’alerte soit régénérée au passage.

Ce genre de solution est réalisable à l’aide d’Orchestrator ( http://stefanroth.net/2012/05/05/reset-monitor-using-scom-2012-and-orchestrator-a-must-have-runbook/ ) ou d’outils tiers comme Green Machine ( http://blogs.technet.com/b/timhe/archive/2014/07/25/greenmachine-2012.aspx )  mais j’ai ici préféré une approche réalisable sans produit autre que SCOM.

Commençons par créer le script qui réalisera les tâches décrites ci-dessus. Il devra être présent dans le même répertoire sur tous les serveurs membres du management pool Notification.
Je me suis très largement inspiré du script de de Stefan Roth pour cette étape, en l’adaptant aux contraintes du mode de fonctionnement retenu. Pensez à modifier scom01 par le nom de votre serveur SCOM :

#checkresetmonitoralert.ps1

Param($alertid)

# Import Operations Manager Module and create Connection
Import-Module OperationsManager;
New-SCOMManagementGroupConnection scom01;

$alerts = Get-SCOMAlert -Id $alertid | where { ($_.ismonitoralert -eq $true) -and ($_.resolvedby -ne "System") }

foreach ($alert in $alerts)

{

# Get IDs
$mrid = $alert.monitoringruleid
$mcid = $alert.monitoringclassid
$moid = $alert.monitoringobjectid

# Get Objects
$monitor = Get-SCOMMonitor -id $mrid
$monitoringclass = Get-SCOMClass -id $mcid
$monitoringobject = Get-SCOMMonitoringobject -class $monitoringclass | where {$_.id -eq $moid}

# Reset Monitor
$monitoringobject | foreach{$_.ResetMonitoringState($monitor)}

}

Nous allons ensuite créer un ensemble de règles de Notification (Channel,Subscriber,Subscription) qui nous permettront d’appeler ce script à chaque fois qu’une alerte est clôturée.
D’abord le Channel, qui sera de type Command :

Indiquez un nom explicite et une description :

Dans le champ Full path of the command file, indiquer le chemin vers l’executable de powershell. Il s’agit par défaut de C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Dans le champ Command line parameters, indiquer les paramètres suivants (pensez à remplacer le chemin du script par le chemin où se trouvera le script dans votre cas) :
-Command "& '"D:\chemin\vers\script\checkresetmonitor.ps1"'" -alertid '$Data/Context/DataItem/AlertId$' -computerPrincipalName '$Data/Context/DataItem/ManagedEntityDisplayName$'

Dans le champ Startup folder indiquer le chemin du dossier où se trouve le script.

Cliquez sur Finish puis sur Close

Créons ensuite le Subscriber :

Indiquez un nom (le même que pour le Channel, par exemple) :

Laissez coché Always send notifications

Cliquez sur Add

Indiquez un nom (toujours le même…)

Dans la liste Channel Type, indiquez Command. Dans la liste Command Channel, sélectionnez le channel créé précédemment.

Laissez coché Always send notification

Cliquez sur Finish

Il reste à créer la Subscription.

Indiquez un nom (oui, encore le même).
Cochez with specific resolution state et indiquez l’état Closed (255)

Cliquez sur Add

Ajoutez le Subscriber précédemment créé et cliquez sur OK

Cliquez sur Next

Cliquez sur Add

Ajoutez le Channel précédemment créé et cliquez sur OK

Cliquez sur OK

Cliquez sur Finish

Désormais, toutes les alertes qui seront cloturées seront analysées par le script powershell, qui réinitialisera le moniteur correspondant au besoin.

Contexte

Avec les cmdlets de base d’Exchange il est relativement simple d’obtenir certaines informations. Mais il est possible d’aller beaucoup plus loin dans le traitement de ces informations en combinant plusieurs cmdlet Exchange.

Les différentes commandes ci-dessous sont des cas concrets que j’ai eu à gérer au quotidien dans l’exploitation d’Exchange 2010.

Cmdlets

Rechercher un mail sur tous vos serveurs HUB à la fois :

Get-TransportServer SRV-EXCH-HUB-0* | Get-MessageTrackingLog -ResultSize Unlimited -Start "06/02/2014 19:00:00" -End "06/03/2014 01:00:00" –Sender “mon-adresse-mail@mon-domaine.fr”

Voir tous les droits sur une BAL :

Get-MailboxPermission login-bal | Where {$_.user -notlike "S-1-5*"} | Sort user | FT user,AccessRights,IsInherited –a

Voir les droits Send-As d’une BAL :

Get-Mailbox login-bal | Get-ADPermission | Where {($_.ExtendedRights -like “*Send-As*”) -and -not ($_.User -like “NT AUTHORITY\SELF”) -and ($_.User -notlike "S-1-5*")} | FT user,identity,IsInherited –a

Voir les statistiques des appareils ActiveSync d’un utilisateur :

Get-ActiveSyncDevice –mailbox login-bal | Get-ActiveSyncDeviceStatistics | Fl DeviceModel,DeviceType,FirstSyncTime,LastSyncAttemptTime,LastSuccessSync

Voir les BAL déconnectées d’un serveur :

Get-MailboxDatabase EXC-MDB-001 | Get-MailboxStatistics  | Where { $_.DisconnectDate -ne $null } | Select DisplayName,MailboxGuid,Database,DisconnectDate,DisconnectReason

Obtenir le top 5 de toutes les files d’attentes de vos HUB :

Get-TransportServer SRV-EXCH-HUB-0* | Get-Queue | Sort MessageCount -desc  | Select QueueIdentity,NextHopDomain,MessageCount,LastError -First 5

Voir les rôles Exchange d’un utilisateur :

Get-ManagementRoleAssignment -GetEffectiveUsers | ?{$_.EffectiveUserName -eq "Amaury AUSSIERE"} | Select Role

Voir d’un coup d’œil l’état de migration d’une liste d’utilisateurs d’un fichier CSV :

Import-Csv D:\MBXtoQuarantaine.csv -Delimiter ";" | %{Get-MoveRequestStatistics $_.samaccountname} | Group status | Select name,count

Obtenir la taille de plusieurs BAL (exemple : BAL de journalisation) avec un avertissement si dépassement d’un seuil :

Get-Mailbox BAL-Journalisation_* | Sort name | Get-MailboxStatistics | Select-Object DisplayName,@{Name="TotalSize(MB)"; Expression={$_.TotalItemSize.Value.tomb()}},@{Name="Warning?"; Expression={if($_.TotalItemSize.Value.tomb() -gt 500){"Warning!"}}}| ft –a

Vérifier les différentes URL d’un serveur CAS :

$monserveur = “SRV-EXCH-CAS-001”
Get-ClientAccessServer $monserveur | Get-ActiveSyncVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-ClientAccessServer | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-EcpVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-OabVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-OwaVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-WebServicesVirtualDirectory | fl server,*lur*
Get-ClientAccessServer $monserveur | Get-AutodiscoverVirtualDirectory | fl server,*lur*

Vérifier les interfaces réseaux utilisées pour les réplications au travers d’un DAG :

Get-MailboxDatabase EXC-MDB-001 | Sort name | Get-MailboxDatabaseCopyStatus -ConnectionStatus | Select Name,MailboxServer,DatabaseName,OutgoingConnections,IncomingLogCopyingNetwork | Sort MailboxServer,DatabaseName

Conclusion

Au travers de ces quelques commandes Powershell, vous obtiendrez des informations pertinentes et rapidement sur l’état des serveurs Exchange.

Libre à vous de les adapter suivant vos besoins et votre environnement, le but étant de vous donner des idées pour votre administration au quotidien ou pour vos scripts.

Contexte

Dans un environnement de production avec Exchange, il peut arriver que l’ensemble des boites aux lettres utilisateurs ne soient pas bien réparties sur l’ensemble des bases. Afin d’éviter tout déséquilibre, il convient de rééquilibrer les bases. Mais ce travaille peut s’avérer fastidieux et long suivant votre organisation.

Je vais donc partager ici la solution mise en œuvre chez un client pour corriger cela très simplement.

Solution

Voici comment le script fonctionne pour répartir les BAL sur l’ensemble des bases :

1. Récupération de toutes les BAL stockées sur les bases à répartir
2. Calcul du nombre moyen de BAL par base
3. Classement des bases suivant le nombre de BAL actuel
4. Répartition des BAL suivant cette règle : Si le nombre de BAL dans une base est supérieur à la moyenne calculée, alors déplacement des BAL dans une base sous allouée, jusqu’à obtenir l’équilibre dans cette base. Cette règle est appliquée pour chaque base au dessus de la moyenne.
5. A la fin du script, un fichier script PowerShell est généré avec les commandes New-MoveRequest qui vont bien.
6. Il ne reste plus qu’a lancer ce script pour obtenir un équilibrage parfait.

Script

Le script ci dessous utilise le fichier “Source-DBBalanceScript.txt” qui doit être disponible dans le même dossier que le script. Voici le contenu de ce fichier :

Identity
EXCH-MBX-DAG1-DB01
EXCH-MBX-DAG1-DB02
EXCH-MBX-DAG1-DB03
EXCH-MBX-DAG1-DB04

A vous de mettre dans ce fichier les bases que vous voulez équilibrer. Les bases qui ne sont pas mises dans ce fichier, ne seront pas traités. Idéal si vous avez une ou deux bases de tests qui ne doivent pas être utiliser en production.

Conclusion

Avec ce script, l’ensemble de vos bases sont correctement réparties afin de corriger les dérives.

Attention, ce script ne prend en compte que le nombre de BAL par base Exchange. La volumétrie des BAL n’entre pas en compte dans le calcul de l’équilibrage. Il s’agit là d’un équilibrage sur le nombre de BAL et pas sur le volume.

Contexte

Si vous ne disposez pas de logiciel de reporting pour votre infrastructure Exchange et que vous n’avez pas spécialement changer les paramètres de base pour ActiveSync, sachez que chaque utilisateur peut synchroniser jusqu’a 10 appareils en même temps.

Suivant votre infrastructure, cela peut poser certains problèmes de performances ou de sécurité si ce protocole n’a pas été prise en compte lors du déploiement et que vous avez publié ActiveSync par la suite.

Script

Voici comment obtenir la liste de tous les périphériques enregistrés pour chaque compte utilisateur. Vous obtiendrez par exemple les modèles, date de synchronisation, etc., pour chaque appareil. Tout ce qu’il faut pour faire des statistiques avec votre tableur préféré.

Conclusion

Grâce à ce script, vous allez pouvoir obtenir l’ensemble des informations nécessaire pour connaitre tous les appareils ayant accès à vos serveurs Exchange.

Au vue des résultats de ce script, vous aurez probablement des questions sur les usages et performances ActiveSync sur vos serveurs. N’hésitez pas à nous contacter, nous pouvons vous aider à définir des stratégies et/ou revoir votre infrastructure dans le cadre d’une mode très tendance, je parle du BYOD !

Contexte

Chez un de nos clients il s’est avéré qu’aléatoirement lors de l’envoi d’un mail via le client de messagerie Microsoft Outlook 2007, le mail n’était pas réellement supprimé de la boite d’envoi. En effet, lors d’un envoi de mail classique, Outlook dépose le mail dans le dossier “Boite d’envoi”, puis déplace le message dans le dossier “Eléments envoyés” quand celui ci est bien envoyé par le serveur Exchange. Dans certains cas, le mail n’est plus visible de l’utilisateur mais n’est pas effacé de la boite d’envoi pour autant.

Ce comportement se traduit par une taille de la BAL de l’utilisateur qui ne cesse de croitre alors que celui-ci supprime ou archive ses mails. De plus, des erreurs d’indexation Exchange au niveau de SCOM apparaissait régulièrement sans savoir exactement pourquoi.

Dans le cas de notre client, il a fallu trouver un moyen de détecter et supprimer les mails en boite d’envoi pour l’ensemble des utilisateurs. Cette opération étant fastidieuse est très longue, l’équipe support ou même les administrateurs ne pouvaient la réaliser. Un script a été élaborer a cet effet.

Avertissement

Ce script, bien que simple et efficace, peut poser certaines questions de droits sur la légitimité de son exécution. En effet, dans la loi Française, la boite mail d’un utilisateur est personnel, même en entreprise. Dès lors qu’un administrateur va supprimer des mails dans la boite d’un utilisateur, sa responsabilité peut être engagée. Avant de se lancer dans une telle opération, il convient d’en parler avec son supérieur et le responsable sécurité de votre entreprise. De plus, il convient de vérifier le script plusieurs fois et de bien le comprendre avant de le lancer sur votre organisation. Le script ci-dessous est fourni tel quel, son utilisation est à vos risques et périls.

Solution

Le script suivant va utiliser un compte de service pour se connecter sur l’ensemble des BAL. Attention, ce compte doit avoir tous les droits Exchange, y compris l’impersonation. Pensez à vérifier vos stratégies de throttling EWS qui peuvent vous brider pour ce script.

Ce script fonctionne de la manière suivante. Il va parcourir l’ensemble des BAL de l’organisation, vérifier la présence de mails dans le dossier de la boite d’envoi. S’il trouve des éléments datant de plus de 7 jours, alors il supprime les mails. Pour chaque BAL, il affiche le nom de la BAL dans la console. Si des mails sont détectés et supprimés, le nom est surligné en rouge. De plus, pour tracer toutes les actions, un fichier de log est créer pour savoir exactement ce qui est fait.

Ne pas oublier d’installer le composant “EWS Managed API” en fonction de votre environnement.

Conclusion

Avec ce script, une très grande quantité d’espace disque a été récupérée suite au vidage de ces dossiers pour l’ensemble des BAL. Les performances Exchange se sont elles aussi nettement améliorée et les erreurs sur l’indexation ont disparus.

Contexte

Pour plusieurs raisons, il peut y avoir plusieurs proxy dans l’entreprise. Si vous devez changer de proxy régulièrement, cette opération peut être longue et source d’erreur. J’ai été confronté a ce cas de figure.

Solution

Pour résoudre ce casse tête, j’ai fait ce script, très simple, mais qui permet de changer de proxy très simplement et rapidement.

Grâce a ce script en Powershell, je vais afficher un menu avec les différents proxy que j’ai ajouter au code au préalable. Il ne me reste plus qu’a choisir quel proxy je veux appliquer et en 1 seconde le nouveau proxy est configuré.

Conclusion

Voici comment gérer simplement plusieurs proxy sur son poste de travail. Idéal pour les administrateurs ou développeurs.

Simple et efficace non ?

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.