L’utilisation de licences Microsoft OEM sur des postes pour lesquels on travail depuis un master unique (re-imaging) est soumit à des contraintes légales et techniques avec n’importe quel outil. Pour rappel, les régles légales de Microsoft pour l’OEM sont les suivantes et s’applique à tous les produits utilisé pour cette gestion d’image:
- le média de type Volume Licensing utilisé dans le master doit être du même niveau que les licences OEM sur les postes (même produit & version, contenir les même produits, et être de la même langue)
- vous devez disposer d’un moins une licence de type volume (VLK) du produit pour avoir le droit de déployer un master sur X postes
- le média de type Volume Licensing doit être utiliser pour faire le master.
Outre ces considérations légales, dans Mirage si l’on essayer de gérer un poste en licences OEM, on a un message d’erreur. Mais techniquement, on peut passer ce problème en plaçant une exception dans la « Base Layer Rule » pour ne pas modifier la clé de registre contenant la licence OEM. Pour cela, suivre le mode opératoire suivant:
- Dans la « Mirage Management Console », aller dans la partie « Image Composer > Layer Rules«
- Faire un click-droit sur la règle par défaut et choisir « Clone » ou cliquer sur le « + » pour créer une nouvelle règle
- Aller dans l’onglet « Software Hive » et dans la partie « Registry Keys to exclude » cliquer sur « Add«
- Ajouter la clé « Microsoft\Windows NT\CurrentVersion\ProductID«
- Cliquer 2 fois sur « OK »
- Sélectionner la nouvelle règle, et d’un click-droit sélectionner « Set As Default« .
Voici à quoi ressemble cette règle avec l’exception:
Ce workaround est une solution utilisable plutôt dans une phase de test ou pour simple faire de la sauvegarde des postes. Car légalement, pour distribuer un master unique sur des postes il faudra utiliser une clé volume. Et dans le cas de migration d’OS, il faudra en plus de la clé volume disposer d’une SA en complément de la licence OEM pour chacun des postes.
J’avais brièvement évoqué le fonctionnement par couche de Mirage dans l’article présentant Horizon Suite. Mais le but de cet article est de présenter plus en détail et surtout de façon illustrée la gestion des couches dans Mirage en fonction des cas d’usages.
Comme introduction, je vous recommande fortement de lire ces 2 articles très détaillés sur HorizonFlux:
Mirage fournit des mécanismes pour synchroniser un poste physique Windows avec son image (appelé CVD) dans le Datacenter. En plus des mécanismes d’optimisation des flux réseau, Mirage a l’intelligence de voir le contenu du poste comme un découpage en 6 couches (sans pour autant modifier le poste). Ensuite, les mécanismes permet de venir fusionner/mettre à jour/réinitialiser/restaurer ces couches en minimisant l’impact pour l’utilisateur.
On retrouve 3 grands types de couches: la couche master (en vert), les couches applicatives (en bleu) et la personnalisation du poste (en orange). En plus de ces couches, on pourrait également ajouter une 7e couche qui est tout ce qui n’est pas protégé (par exclusion). On peut paramétrer le contenu de ces couches en configurant les points suivants:
- Layer Rules pour les couches vertes (et bleues).
- Pendant la phase « Capture App Layer » (basé sur les Layer Rules) des couches bleues.
- User Area (dans l’Upload Policy) pour les couches orange
- Unprotect Area (dans l’Upload Policy) pour tout ce qui n’est pas protégé
Lire la suite…
Nous avions déjà abordé le sujet de l’optimisation de VMware View dans un contexte WAN, mais à l’opposé pour certain usage spécifique il peut être nécessaire de faire de l’optimisation pour avoir de bonne performance pour lire des vidéos.
Cet exercice n’est jamais facile car ici on n’est pas dans le meilleur cas d’utilisation du VDI et que c’est un équilibre complexe entre la bande passante et le rendu utilisateur. L’objet de cet article est donc de recenser l’ensemble des bonnes pratiques et des paramètres de tuning pour améliorer le rendu vidéo.
Lire la suite…
Lors de l’upgrade du/des serveur(s) Mirage, il faut passer par une phase d’uninstall/réinstall des composants comme expliqué dans le KB2031711. Bien entendu, on ne perd pas la configuration et les données stockées.
Par contre, lors de la phase de réinstallation, vous pouvez avoir un message d’erreur SQL qui vous dit que vous avez un problème de droit sur la base: « Failed install user rights validations. Failed to connect to database. Check server name, instance name and server settings« .
La solution est en fait très simple, il suffit juste de ne pas renseigner de nom d’instance (et bien sûre, ne pas cocher la case « Create new storage areas »):
Une bougie de plus, bon troisième anniversaire à nous-mêmes 
C’est l’occasion de faire le point sur l’année passée:
Peu de changement pour nous cette année. Mais surtout beaucoup moins de temps a consacrer au blog, donc la quantité d’article a nettement diminuer. 
J’ai quand même renouveller mon titre vExpert 
pour 2012. 
L’événement marquant de l’année (bien contre ma volonté) c’est que le blog a été virusé. C’est quand on s’y attends pas que ca arrive, depuis j’ai mis de plugins de sécurité dans tous les sens (ceinture-bretelle-parachute). Pas seulement le nettoyage a été compliqué mais aussi la remise en place et la reconfiguration. Il me reste encore plein d’erreurs sur les liens des images liées aux problèmes d’import des médias.
Lire la suite…
Le streaming d’application ThinApp était présent dans l’interface d’Horizon Application Manager 1.5 (admin et agent) alors qu’elle n’est plus visible dans Horizon Workspace 1.0. Cette fonctionnalité est toujours présente mais n’est pas présentée d’un point de vue GUI.
Pour activer cette fonctionnalité, il faut installer l’agent Workspace en ligne de commande avec les paramètres suivants:
VMware-Horizon-Workspace-1.0.0-1028171.exe /z HORIZONSERVER=https://horizon.mydomain.com /v DOWNLOAD=0 POLLINGINTERVAL=60
/s pour installer l’agent Workspace en mode silencieux.
/z pour préciser les paramètres « HorizonServer » et/ou « SSLbypass ».
HORIZONSERVER est adresse du serveur Horizon (généralement on précise https mais pas obligatoire).
SSLBYPASS à 1 pour ignorer les erreurs de certificats.
/v pour préciser les paramètres « Download » et/ou « PollInterval ».
DOWNLOAD à 0 signifie Streaming d’application ThinApp, 1 pour le téléchargement complet.
POLLINTERVAL est l’interval de synchronisation des applications ThinApp (en minutes).
Il est également possible de modifier ce paramètre en éditant la base de registre dans HKLM\Software\VMware, Inc.\VMware Horizon Apps\ (comme ci-dessous):
Annoncé mercredi 20/2/2013 et disponible depuis hier, VMware marque une étape importante concernant son offre pour les utilisateurs finaux (EUC): Horizon Suite qui se qualifie comme « the platform for workforce mobility« . Ainsi, Horizon Suite permet d’offrir une plateforme complète de mobilité professionnelle permettant aux utilisateurs finaux de rester connectés à leurs données, à leurs applications et à leurs postes de travail sur n’importe quel appareil, et sans compromettre la sécurité ou le contrôle des systèmes d’information.
On peut le voir comme VMware l’avait annoncé lors des précédents VMworld, le portfolio End-User se complète pour être capable de couvrir tous les cas d’usages et l’intégration entre les produits est de plus en plus forte.
Lire la suite…
Le time-out par défaut de l’interface vCenter Operations est de 30 minutes. Mais lorsque l’on souhait l’afficher en permanence sur un grand écran comme outil permanent pour l’exploitation, il est nécessaire de modifier ce time-out. Pour cela, suivre la procédure suivantes pour l’interface standard (vcops-vsphere):
- aller sur la machine « UI VM » et éditer le fichier « /usr/lib/vmware-vcops/tomcat/webapps/vcops-vsphere/WEB-INF/web.xml«
- mettre la variable « session-timeout » à la valeur « -1 » pour un time-out infini
- redémarrer le service Apache Tomcat avec la commande « vcopsweb restart«
Pour l’interface Custom (vcops-custom), la procédure est différente: modifier les paramètres d’un Dashboard pour le mettre en « Auto-Transmission » et chaque Widget pour les mettre en « Auto-refresh« .
Depuis quelques années, on parle énormément de Cloud, mais le terme reste très nébuleux en fonction de ce que l’on souhaite mettre dedans. Le concept de SDD (Software-Defined Datacenter) ou SDDC (plutôt utilisé dans les docs anglaises) permet de mieux comprendre le moteur du Cloud Computing. En effet, le Cloud a besoin de virtualisation pour tourner, mais pas seulement. Il a également besoin de toute cette intelligence logicielle pour automatiser au maximum le provisionnement et être flexible, contrôlable, élastique…
On le sait tous que la virtualisation a permis de faire des économies et de rendre les administrateurs plus sereins sur leur infrastructure. Mais ce n’est qu’une première phase de modernisation de l’IT. Les directions informatiques souhaitent une infrastructure opérationnelle mais pas seulement, elles souhaitent améliorer l’efficacité, automatisé et simplifier sa gestion, augmenter la disponibilité et la rendre agile. Et tout cela pour améliorer la productivité et se recentrer sur l’activité de l’entreprise afin de se différencier et d’améliorer leur activité.
Le Datacenter actuel des entreprises repose encore sur l’historique des différentes générations de technologie mise en place (mainframe, Unix, réseau, wintel…) qui ont dû suivre la cadence des nouveaux projets et des nouveaux besoins. C’est souvent ici que l’on trouve des silos d’architecture et d’administration qui rendent complexes cette modernisation. Ce que l’on voit c’est que les entreprises plus jeunes ou celles qui ont fait table rase du passé sont rendues plus loin dans cette modernisation et sont plus réactives.
Lire la suite…
Jérémie Brison
