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/

Le script ci-dessous surveille la consommation (création / suppression) régulière de fichiers dans un dossiers en excluant potentiellement des noms de fichiers et des heures de dernieres modification puis remonte l’état a SCOM.

Lien du script plus bas.

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

Dans Orchestrator, l’activité Run .NET Script permet d’exécuter des scripts dans différents langages (Powershell, VB .NET, JScript…) ce qui se révèle très utiles dans les nombreux cas où les activités apportées par les différents Integration Pack se révèlent insuffisantes pour effectuer les tâches dont vous avez besoin.

Cependant, il peut vite devenir compliqué de débugger ces scripts puisque l’activité Run .NET Script ne publie pas le résultat brut de leur exécution dans le databus : impossible alors de savoir où le script a échoué!

En revanche, ce que cette activité peut publier à l’aide de sa fonctionnalité Published Data, c’est le contenu de n’importe quelle variable que contient le script exécuté.

Il ne reste donc plus qu’à utiliser ce fonctionnement afin de stocker le résultat d’exécution du script dans une variable et de la publier via les Published Data.

Prenons l’exemple de ce script Powershell, un simple compteur qui ne présente pas d’intérêt autre que de produire une sortie sur plusieurs lignes :

for ($i=0; $i -le 10; $i++) {write-host $i}

Il suffit de l’encapsuler comme suit pour récupérer cette sortie dans Orchestrator :

$result = Powershell { for ($i=0; $i -le 10; $i++) {write-host $i} }

Puis de publier la variable result dans les Published Data :

La sortie du script est donc désormais publiée dans le databus.

On peut ensuite la récupérer dans un fichier texte à l’aide de l’activité Append Line, dans un évènement avec Send Event Log Message etc. Attention car dans ce second cas, un évènement sera créé pour chaque ligne si le mode Run Behavior > Flatten n’est pas utilisé!

Prenons l’exemple du fichier texte :

On voit bien que l’activité Append Line est appelée une fois par ligne contenue dans la variable result car le flatten n’est pas activé :

Et le résultat final :

Evidemment, cette astuce sera beaucoup plus utile pour des scripts réels!

A l’occasion du déploiement d’agents Linux à partir d’une infrastructure SCOM 2012 R2 UR4, un client a rencontré le problème suivant pour les serveurs exécutant la distribution CentOS 7 :

Failed during SSH discovery. Exit code: 2
Standard Output:
Standard Error: /etc/centos-release: line 1: syntax error near unexpected token `(‘
/etc/centos-release: line 1: `CentOS Linux release 7.0.1406 (Core) ‘
Exception Message:

Il reste possible de procéder à une installation manuelle de l’agent, mais cette solution est beaucoup moins pratique et plus longue.

Pour comprendre d’où provient cette erreur, il est nécessaire de comprendre au préalable que le processus de découverte d’un serveur Linux est réalisé par le script GetOSVersion.sh, disponible dans le dossier d’installation de SCOM : C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents

Lors de la découverte, ce script est copié et exécuté sur les serveurs à découvrir et tente principalement d’identifier la version de Linux exécutée par le serveur afin d’y déployer l’agent approprié.
Pour ce faire, il cherche à récupérer le contenu du fichier standardisé os-release qui contient des informations sur le système, à l’aide des lignes suivantes dans le cas d’un CentOS :

Le souci, c’est que la variable . $ReleaseFile pointe vers un fichier nommé centos-release qui contient, ô surprise, la ligne CentOS Linux release 7.0.1406 (Core) à la place des informations attendues au format TAG=VALUE.

Informations qui se trouvent par contre bien dans le fichier os-release… il ne reste alors qu’à corriger le script afin qu’il pointe vers le bon fichier, en remplaçant la ligne
. $ ReleaseFile
Par la ligne
. ${EtcPath}/os-release
Ce qui donne ce résultat :

Répétez cette opération sur tous les serveurs du Management Pool Linux et votre découverte ne devrait désormais plus poser de problème!

Attention! Cette modification n’est pas supportée par Microsoft et n’a pas été testée en profondeur, elle pourrait donc provoquer d’autres problèmes dans  des contextes différents! 
Par ailleurs, il y a de fortes chances que le fichier GetOSVersion.sh soit écrasé lors de l’installation de mises à jour futures. Il serait alors nécessaire de réappliquer la modification détaillée ici, si Microsoft n’apporte pas de correction.

Merci à Stéphane J. pour son implication sur cette problématique Linux assez spécifique!

Contexte

La faille POODLE (découverte par une équipe de Google fin Septembre) permet d’extraire depuis une transaction sécurisée en SSLv3 des informations secrètes (cookies, password) lors d’une attaque de type “Man in the middle”.

Suite à la découverte de cette faille, le protocole SSLv3 est maintenant obsolète, il est conseillé sur un serveur WEB, d’interdire l’utilisation de SSLv3 ce qui peut présenter des problèmes de compatibilité.

Explications

Lors d’une connexion à un site WEB, le navigateur et le serveur WEB vont négocier un protocole de chiffrement, le protocole négocié doit correspondre au protocole le plus à jour implémenté par le serveur et le client.

Bien qu’actuellement la grande majorité des navigateurs et des sites WEB implémentent des protocoles plus sécurisées que le SSLv3, il est possible que le protocole SSLv3 soit choisi par “fallback”. Il est également possible pour un utilisateur malveillant qui contrôlerait le réseau entre le client et le serveur de forcer la négociation d’un protocole antérieur au protocole le plus à jour implémenté par le client et le serveur afin d’en exploiter les failles.

Avec la faille POODLE touchant le SSLv3 et contrairement aux failles précédentes rencontrées sur SSLv3, aucun contournement n’est possible. Il faut donc bannir l’utilisation du protocole SSLv3.

C’est dans cette optique que les principaux navigateurs dont Firefox et Google Chrome, annoncent le retrait du support de SSLv3 sur leurs prochains produits.

Résolution sur IIS & ASP.NET

Sur un serveur web utilisant le framework .NET et qui est compatible avec TLS 1.0, il est possible de forcer l’utilisation d’algorithmes de cryptographie compatibles FIPS.

Cela se fait via l’activation de la stratégie locale située dans :

“Paramètres de sécurité locaux/Stratégies locales/Option de sécurité/Stratégie/Chiffrement Système”

Après cette modification les protocoles non compatibles FIPS (dont SSLv3) ne pourront être utilisés.

Par défaut, ASP.NET utilise des algorithmes non-compatibles avec FIPS, l’erreur 1309, visible dans le logs des évènements Web, est donc susceptible d’apparaitre :

Afin de modifier ce comportement, il faut spécifier au niveau du fichier Web.Config de l’application ASP.NET l’algorithme de cryptographie à utiliser.

Pour ce faire il faut dans la partie <system.web> du fichier Web.Config, ajouter la ligne suivante :

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>

Sources :

http://support.microsoft.com/kb/911722

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

Contexte

Cet article a pour objectif de fournir les principales commandes PowerShell afin de créer un rapport, qui, exécuté avec une tâche planifiée, permet de générer automatiquement un rapport HTML envoyé par mail.

Dans cette série de deux articles, nous verrons comment créer deux scripts PowerShell qui permettent de remonter les principales informations pour :

• Une liste d’un ou plusieurs serveurs HYPER-V,
• Les machines virtuelles présentes sur un ou plusieurs serveurs HYPER-V.

Compatibilité :

Les scripts présentés dans cette série ont étés testés sur :

• HYPER-V pour Windows Server 2012R2
• HYPER-V pour Windows Server 2012

Dans l’article précédent nous avons vu comment utiliser PowerShell pour générer un fichier HTML. Cet article présenteras les principales commandes PowerShell pour la génération d’un rapport affichant les principales informations des VMs ainsi que des Hyperviseurs.

Créer la liste des serveurs

Afin de préciser le noms des hyperviseurs qui seront interrogés, sans entrer leur noms en dur dans le script – ce qui obligerais à modifier lors de l’ajout ou la modification de serveurs cible – nous passerons par un fichier texte qui seras utilisé par le script. Chaque ligne du fichier contient le nom d’un serveur :

Afin de charger le contenu du fichier texte, il suffit d’en spécifier l’emplacement dans une variable :

Pour utiliser le fichier dans une boucle, il faut utiliser la commande “Get-Content” :

Récupérer les informations des VMs

La fonction “retrieve_virtualmachine_informations” permet pour une VM ($vmname_) et un hyperviseur ($server_) donné de récupérer les informations suivantes :

• Nom de la VM,
• Nom de l’hyperviseur,
• Nombre de vcpu,
• Informations de la RAM,
• Nombre d’interfaces réseau,
• Nombre de disques,
• Temps d’activité de la VM,
• Etat de la VM,
• Délai de démarrage de la VM.

Voici la fonction :

Récupérer les informations des hyperviseurs

Informations générales :

Récupérer le temps d’activité de la machine :

Récupérer les informations de la commande “Systeminfo” et convertir au format CSV avec la fonction “Get-SystemInfo” :

Cette fonction seras ensuite utilisée pour récupérer le nom de la machine et son modèle :

RAM :

La fonction “Get-SystemInfo” est également utilisée pour récupérer les informations de mémoire disponible et maximum :

Disques :

Cette commande permet de récupérer tous les disques :

Une fois tous les disques récupérés, il faut pour chaque disque récupérer ses informations :

v

Créer les bornes d’avertissement

Afin de disposer d’un rendu visuel permettant de rapidement identifier un problème sur un serveur, il est possible (à l’aide de balises HTML) de colorier des cellules en fonction de la valeur contenue. Cela permet par exemple de rapidement identifier un serveur avec un faible stockage restant ou bien peu de RAM :

Tout d’abords, il faut créer les variables contenant la valeur des bornes :

Ensuite, lors de la génération du code HTML, il faut sous PowerShell, avec le switch “if” vérifier les trois différents cas (OK, Warninig et Critique), puis à l’aide de la balise HTML “bgcolor” préciser la couleur de la cellule :

Contexte

Cet article a pour objectif de fournir les principales commandes PowerShell afin de créer un rapport, qui, exécuté avec une tâche planifiée, permet de générer automatiquement un rapport HTML envoyé par mail.

Dans cette série de deux articles, nous verrons comment créer deux scripts PowerShell qui permettent de remonter les principales informations pour :

• Une liste d’un ou plusieurs serveurs HYPER-V,
• Les machines virtuelles présentes sur un ou plusieurs serveurs HYPER-V.

Compatibilité :

Les scripts présentés dans cette série ont étés testés sur :

• HYPER-V pour Windows Server 2012R2
• HYPER-V pour Windows Server 2012

Dans ce premier article nous verrons les principales commandes à maitriser pour générer un rapport HTML à l’aide de PowerShell, ce prérequis est commun aux scripts de rapport des VMs ainsi qu’au script de rapport des Hyperviseurs.

Générer un rapport HTML en utilisant PowerShell

Afin de mieux nommer le fichier HTML l’idéal est de récupérer dans des variables la date et l’heure afin nommer le fichier de manière unique lors de chaque exécution :

Pour ajouter le code HTML depuis PowerShell, j’utilise la même variable tout au long du code dans laquelle le code HTML est ajouté à l’aide de l’operator “+=”. Une fois le script terminé, la variable contenant le code HTML est écrite vers le fichier HTML créé.

La ligne suivante permet de créer le fichier HTML vide sur lequel le code HTML vas être écrit :

Une fois le fichier HTML créé, il faut – comme pour toute page HTML – commencer par ouvrir les principales balises (html, head) ainsi que préciser l’encodage utilisé. On peut également en profiter pour définir le style désiré pour certaines balises types, ce qui évite d’avoir à préciser les mêmes éléments lors de l’utilisation de ces balises :

On peut remarquer l’utilisation de l’expression @" et de "@ qui nous permettent pour une variable au format string d’utiliser plusieurs lignes, ce qui permet d’avoir un code HTML correctement agencé.

Afin d’ajouter le contenu de la variable dans le fichier HTML, il faut utiliser la commande “Add-Content” :

Maintenant que le début du fichier HTML est créé, le script doit maintenant récupérer les informations que l’on souhaite faire apparaitre dans le rapport HTML (nous verrons ce point dans la partie suivante de ce post) dans des tableaux que l’on génère au fur et à mesure dans une boucle qui parcoure toutes les ressources (VM ou Hoster) à interroger afin de créer ce type de vue :

Le rapport présenté ci-dessus contient 4 tableaux des ressources qui sont regroupés dans un tableau pour des raisons d’affichage.

Afin de maitriser la taille en largeur des tableaux HTML des ressources, on commence par récupérer le nombre de tableau que l’on va générer que l’on divise par la taille du bloc. De cette manière, les tableaux des ressources auront la même taille :

La génération des tableaux des ressources est faite à l’aide d’une boucle qui va pour chaque machine de la liste récupérer ses informations puis créer un tableau pour chaque ressource. Avant la boucle, un tableau vide est créé, il faut bien veiller à fermer ce tableau après la sortie de la boucle :

Conclusion

Dans cet article, nous avons vu comment faire à l’aide de PowerShell pour générer des rapport HTML.

Le plus important est de bien maitriser l’ordre de génération du code HTML de manière à ce que les balises respectent les règles du format HTML.

Dans l’article suivant, nous verrons comment récupérer les principales informations pour une VM et un hôte HYPER-V afin de les ajouter aux tableaux composant le rapport HTML.

Nous allons ici créer un Switch Logique au travers de VMM et l’affecter à notre hôte Hyper-V.

L’affectation du Switch via VMM  va créer dans notre exemple le Teaming des cartes ainsi que les différentes VNICs avec la QOS associé.

Dans VMM, Créer un nouveau Port Profile

Donner un nom à ce nouveau Profil et sélectionner la configuration de Teaming que vous désirez créer pour vos hôtes Hyper-V en sélectionnant Uplink port profile et en sélectionnant le mode de Teaming souhaité et son algorithme de Load Balancing.

Sélectionner les différents Network Site que vous souhaiter intégrer a votre Port Profile et cocher Enable Windows Network Virtualization.

Le résumé de vos actions apparait.

Cliquer sur Finish

Nous allons maintenant créer un Logical Switch.

Cliquer sur Next

Donner le nom du Switch virtuel et cliquer sur Next.

Cliquer sur Next

Sélectionner Team et cliquer sur Add

Sélectionner le Port Profile précédemment créé et cliquer sur Ok.

Cliquer sur Next

Dans l’onglet Virtual Port, cliquer sur Add

Sélectionner les virtuals ports comme sur l’exemple ci dessous via le bouton Add.

(Ces virtuals ports sont nativement présent dans VMM et détiennent des Bandwidth Weight qui définiront notre QOS)

Cliquer sur Next

Cliquer sur Finish

Nous allons maintenant affecter à notre hyperviseur le Switch Logique précédemment créé.

Sélectionner votre Hôte et afficher ses propriétés.

Aller dans l’onglet Virtual Switches

Sélectionner New Logical Switch

Ici sélectionner les différentes interfaces réseaux devant participer à la configuration de votre Switch.

Nous allons maintenant ajouter 3 VNICs pour notre exemple qui permettront d’avoir des VNICs nécessaire pour notre cluster Hyper-V :

• VNIC Cluster
• VNIC Live Migration
• VNIC Management

Cliquer sur New Virtual Network Adapter de manière à ajouter des VNICs

Procéder à la configuration de votre VNIC

Procéder de même pour les autres VNICs et cliquer sur OK.

Un message apparait. Cliquer sur OK

Votre Hyperviseur applique la configuration de votre Switch Convergé poussé depuis VMM.

Nos 3 VNICs sont maintenant apparue sur notre Hyperviseur.

Ces 3 VNICs détiennent également les configurations réseaux qui ont été appliqués.