XenDesktop Archive

0

Erreur désinstallation VDA

Lors d’une désinstallation d’un VDA 7.6.300 nous avons rencontré l’erreur ci-dessous :

Removal of MSI Product ‘CitrixHDXWMIProvider-x64.msi’ ………………….. failed with code ‘InstallFailure’ (1603).

 

vda_error_wmi01En ce moment c’est une constante le 1603 🙂

Le fichier de log et les events du serveur ne donnant rien, nous avons extrait le msi CitrixHDXWMIProvider-x64.msi puis tenté une installation à la mano.

 

vda_error_wmi02On sy attendait, mais ce qui nous intéresse ce sont les logs du msi

 

Direction le fichier de log (dans notre cas : C:\Users\UserName\Local Settings\Temp\Number\Citrix\XenDesktop Installer\MSI Log Files)

 

MSI (c) (94:44) [16:36:42:043]: Windows Installer installed the product. Product Name: Citrix HDX WMI Provider – x64 7.6.300.7024. Product Version: 7.6.300.7024. Product Language: 1036. Manufacturer: Citrix Systems, Inc.. Installation success or error status: 1603

Property(N): Rollback_Uninstall_MOFRegister.A447AE13_47F3_442C_8854_837BF7E37D1A = c:\Program Files (x86)\Citrix\System32\citrix.hdx.wmi.provider.mof
Property(N): MOFUnregister.A447AE13_47F3_442C_8854_837BF7E37D1A = c:\Program Files (x86)\Citrix\System32\citrix.hdx.wmi.provider_delete.mof

 

La lecture du fichier de log nous apporte une information intéressante concernant la suppression des fichiers .mof, donc direction une console PowerShell afin de vérifier ce qui reste de WMI côté Citrix via la commande : gwmi -Namespace root -class __Namespace -Filter « name = ‘citrix’

 

vda_error_wmi03

 

Nous allons y aller à la brute en supprimant le Namespace « Citrix » via la commande :  gwmi -Namespace root -class __Namespace -Filter « name = ‘citrix’| Remove-WmiObject

Une fois le Namespace Citrix supprimé, l’installation du msi CitrixHDXWMIProvider-x64.msi se termine sans erreur.


vda_error_wmi04Ca c’est bon, il ne reste plus qu’a relancer la suppression du VDA 7.6300 😉

 

Tags: , ,
0

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_error1On clique toujours sur « View error détails », mais rarement ça nous dépanne 😉

 

vda_error2
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.

 

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

0

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).

 

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

 

Route2Un 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.


Billet3On 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).


 

Route4On va allez papoter avec la DDE 🙂

2

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 🙁  ).

 

CLUEDO
Une partie ? 🙂

 

 

0

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).

Xd_MigrateVcOn 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. 

Xd_MigrateVc2 

Xd_MigrateVc3
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 

Download_2XD_MigrateHost.ps1