XenDesktop – Page 2

Erreur installation VDA : UpmVDAPlugin.msi Failed (1619)

Lors d’un upgrade de VDA 7.6.300 (LTSR) vers un VDA 7.6.1000 (LTSR CU1) sur un serveur W2K8 R2 Sp1 US, on nous a remonté l’erreur ci-dessous :

‘UpmVDAPlugin_x64.msi’ failed with code ‘InstallPackageOpenFailed’ (1619)

vda_error1 On clique toujours sur “View error détails”, mais rarement ça nous dépanne 😉

He oui on a cliqué et on n’est pas plus avancé 🙂

Au passage ce serveur était membre il y a quelques mois d’une ferme XenApp 6.5 (c’est donc un serveur qui a un certain vécu 😉 ).

Revenons à nos moutons, en regardant les events du serveur nous n’avons rien trouvé, en revanche en ouvrant le fichier de log d’installation du VDA nous avons vite trouvé l’origine du problème.

$ERR$ : XenDesktopSetup:MSI file C:\WINDOWS\TEMP\Ctx-76B9FF05-0423-4B17-974A-6063551BB4B8\Extract\Image-Full\x64\Virtual Desktop Components\UpmVDAPlugin_x64.msi not found on media.

Dans un premier temps il faut extraire le fichier “UpmVDAPlugin_x64.msi” du “VDAServerSetup_7.6.1000.exe“, une solution rapide et simple est d’ouvrir le fichier “VDAServerSetup_7.6.1000.exe” avec WinRar (ou 7-zip) et d’extraire le fichier “UpmVDAPlugin_x64.msi” (situé dans ..\Image-Full\x64\Virtual Desktop Components). Il ne reste plus qu’a placer le fichier “UpmVDAPlugin_x64.msi” dans “C:\WINDOWS\TEMP\Ctx-76B9FF05-0423-4B17-974A-6063551BB4B8\Extract\Image-Full\x64\Virtual Desktop Components\” et de relancer l’installation du VDA.

Une fois le fichier UpmVDAPlugin_x64.msi copié, l’installation passe sans problème

Logon Monitor (c’est gratuit foncez)

Au détour d’une conversation avec notre ami Hypervisor (non… pas autour d’une boisson à consommer avec modération) ce dernier nous a fait part d’un outil gratuit fort prometteur, Logon Monitor (merci Erik Tatum) disponible sur Flings de VMware (he oui ça vient de nos amis d’en face 🙂 ).

Logon Monitor permet de calculer le temps d’ouverture d’une session Windows (vous nous direz ce n’est pas le seul, c’est vrai, mais lui est gratuit) accompagné de plusieurs métriques comme la cpu, mémoire, réseau, disque, process etc.. (liste non exaustive).

L’installation de Logon Monitor est on ne peut plus simple. Une fois installé (pas de reboot nécessaire) vous obtenez un service supplémentaire (VMware Logon Monitor) qui lance le process vmlm.exe (comptez entre 7 et 12 Mo de ram pour vmlm.exe).

Après l’installation, Logon Monitor trace toutes les nouvelles sessions et crée un fichier de log pour chaque connexion (pour l’instant le nombre de logs se limite aux 10 dernières sessions, ce quota devrait être paramétrable dans une prochaine version).

Pour télécharger Logon Monitor c’est ici.

En l’état nous vous conseillons Logon Monitor sur du VDI ou dans le cadre d’un troubleshoting de serveur RDSH/XenApp.

Allez on se lance dans l’install (éprouvante vous allez voir)
Cliquez sur le bouton “Install”

Le Chrono est en marche ? 🙂

Cliquez sur le bouton “Finish”

Les logs se trouvent pas défaut dans C:\ProgramData\VMware\VMware Logon Monitor\Logs.

Sympa non 😉

Nous avons testé Logon Monitor sur du Seven, Windows 2008 R2 et 2012 R2.

Une histoire de route

Lors d’une installation d’une nouvelle ferme XenApp 7.6 (Wk2K12 R2 US) nous avons rencontré l’erreur “XDDS:17647403” lors de la Connection (Add Connection and Ressources) à un de nos vCenter (5.1.0).

Ca fait un bail qu’on avait pas une ferme XenApp à la mano

Un peu plus de détails sur notre erreur

En regardant l’erreur de plus près on constate que le vCenter n’est pas joignable :

Error Id: XDDS:17647403
Exception:
Citrix.Console.Common.CitrixAggregateException One or more parallel operations failed
at Citrix.Console.Common.CitrixParallel.InternalForEach[TIn](IEnumerable`1 items, Action`1 operation, Int32 maxSimultaneous)
at Citrix.Console.PowerShellSdk.HypervisorService.Scripts.TestHypervisorConnectionScript.RunScript()
at Citrix.Console.PowerShellInteraction.PowerShellScript`1.Run()
at Citrix.Console.Hypervisors.UI.Pages.HypervisorDetailsPageViewModelBase.ValidatePage()
at Citrix.Console.CommonControls.Wizard.PageContainerViewModel.<>c__DisplayClass3.<ValidateAndMoveToPage>b__2()
DesktopStudio_PowerShellHistory : TestHypervisorConnectionScript
…….
…….
DesktopStudio_ErrorId : HypervisorNotContactable

Effectivement on constate qu’un telnet sur le port 443 à destination de notre vCenter ne passe pas à partir du futur Controller (DDC).

En regardant de plus près (pour être honnête on vous passe les différentes étapes qui nous ont amené là) nous avons constaté dans une trace Wireshark que l’IP de notre Vcenter n’apparaissait pas, vu que nous avons deux cartes réseaux sur notre VM (une pour le backup sur une VLAN différent et l’autre pour la prod) nous changeons l’interface dans Wireshark et relançons une trace et nous constatons que l’IP de notre Vcenter apparaît bien dans notre trace.

En lançant un route print nous constatons que ça ne risquait pas de fonctionner notre histoire :), au passage on vous conseille NetRouteView pour afficher via une GUI les routes d’un serveur.

On constate que la destination 0.0.0.0 à deux routes avec chacune un carte réseau différente renseignée.

Une fois la route 0.0.0.0 pointant sur la carte réseau de backup supprimée nous avons pu joindre notre vCenter (au passage, en comparant avec d’autres serveurs seules les nouveaux serveurs livrés avait ce problème de route).

On va allez papoter avec la DDE 🙂

Crash Online Plug-in 12.3

Il y a quelques jours nous avons rencontré un problème qui jusqu’à présent ne s’était jamais posé de cette façon, cinq utilisateurs rencontraient un crash WFICA32.exe lorsqu’ils lançaient une application publiée spécifique (les autres applications publiées se lançaient sans problème), lors du lancement de l’application en question un crash WFICA32.exe se produisait systématiquement avec un event 1002.

Nom du journal :Application
Source : Application Hang
ID de l’événement :1002
Catégorie de la tâche :(101)
Niveau : Erreur
Description :
Le programme WFICA32.exe version 12.3.0.8 a cessé d’interagir avec Windows et a été fermé. Pour déterminer si des informations supplémentaires sont disponibles, consultez l’historique du problème dans le Centre de maintenance.

Les postes clients étaient en Seven Sp1 fr (on ne sait pas si c’était du 64 ou 32 bits) avec un Online Plug-in 12.3.

Au détour de quelques questions on apprend que nos utilisateurs ont déménagé récemment et qu’ils impriment désormais sur une nouvelle imprimante, après un arrêt du spooler sur l’un des postes la fameuse application se lançait. Nos collègues de poste de travail on dû changer le pilote afin que tout rentre dans l’ordre (par contre on n’a pas le nom du pilote qui causait problème 🙁 ).

Une partie ? 🙂

XenDekstop : Modifier le host pour les desktops membres d’un catalogue

Si vous souhaitez changer le host des desktops membre d’un catalogue (lors d’une migration de vCenter par exemple) il faut passer par la case PowerShell vu qu’en GUI (Desktop Studio) ce n’est pas possible (tout du moins simplement).

On se demande encore pourquoi via Desktop Studio ce n’est pas possible simplement (ou alors on a raté quelque chose)

Avant d’exécuter le script il vous faut renseigner le nom du futur Host (ligne 12) et le nom du catalogue à migrer (ligne 13) dans le script.

Un fichier de log est disponible dans le répertoire courant
Au passage dans le screenshot on a laissé l’ancien nom du script 😉

Le script XD_MigrateHost.ps1 a été testé sur un DDC en XenDekstop 5.6 US

XD_MigrateHost.ps1