ctxblog – Page 6

WEM : Database creation error

Lors d’un POC nous avons installé WEM 4.06 afin de montrer tous les avantages de WEM dans un environnement de type bureau publié (publish desktop), lors de la création de la base WEM nous avons rencontré l’erreur “Database creation error”.

Ca commence pas bien notre POC 🙂

L’avantage de WEM est que tout est logué durant l’installation, direction le fichier de log situé dans C:\Program Files (x86)\Norskale\Norskale Infrastructure Services\ Citrix WEM Database Management Utility Debug Log.log.

La lecture du fichier de log nous renseigne rapidement sur la cause du problème :

Exception -> DbCreateRequestExecutor.
() : System.Exception: SqlDatabaseHelper.[1]() connection Error : 5133 | Directory lookup for the file “C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\TESTDBWEM_Data.mdf” failed with the operating system error 3(The system cannot find the path….

En échangeant avec les DBAs on comprend que la couche SQL est installée dans un chemin spécifique, une fois le chemin d’installation dument rempli dans le wizard WEM, l’install se poursuit avant que nous rencontrions une nouvelle erreur “Database creation error”, et encore cette fois le fichier de log WEM nous donne l’origine du problème.

There is already a master key in the database. Please drop it before performing this statement.

Pour corriger cette erreur nous avons demandé aux collègues DBAs de passer la requête ci-dessous :

USE VotreBaseWEM;
DROP MASTER KEY;
GO

Une fois la requête executée l’installation s’est poursuivie sans problème.

On vous conseille aussi de jetter un oeil sur la CTX228982 https://support.citrix.com/article/CTX228982/ au cas ou 😉 .

Erreur installation VDA 7.15 LTSR CU1

Lors d’une mise à jour d’un VDA 7.6 LTSR vers la 7.15 CU1 (vers un VDA 7.15 LTSR CU1) nous avons recontré l’erreur ci-dessous.

Error Id: XDMI:1AA44929

Exception:

Citrix.MetaInstaller.Exceptions.MetaInstallerException ‘NDP452-KB2901907-x86-x64-AllOS-ENU.exe’ component failed to install with error 0x000013EC.
at Citrix.MetaInstaller.Prerequisites.DotNet452Component.Install(InstallationContext context)
at Citrix.MetaInstaller.InstallationManager.InstallComponent(IInstallableComponent component, InstallationContext installContext)

On va la faire courte, c’est juste un problème d’espace disque, donc rien de bien méchant, sauf que nos amis de chez Citrix pourraient faire un check d’espace disque avant l’installation d’un VDA (ou de sa mise à jour)……. ou pas 🙂

S’il n’y a plus de place pour installer Microsoft .NET Framework 4.5.2 on va pas aller très loin 🙂

XenAppUsr_7x V2.1

Enfin on s’est décidé à mettre à jour XenApp_Usr7x V2, en effet nombre d’entre vous nous ont remonté des bugs sous XenDesktop (merci encore pour vos retours).

Outre la correction de bugs nous avons rajouté les features ci-dessous et enfin un Admin Guide 🙂 .

Formulaire principal : possibilité de faire un gpupdate sur le serveur hébergeant l’utilisateur sélectionné
Formulaire principal : possibilité d’afficher les informations d’un process (process id, command line, creation date, executable path et le WorkingSetSize en dinamique)
Formulaire principal : envoi dans le clipboard de toutes les informations utilisateurs affichées
Formulaire principal : ajout du menu action (permettant de faire une recherche d’une Application/server/Delivery Group…)
Formulaire Server : lancement d’un GPUPDATE sur le serveur
Formulaire Server : possibilité de mettre en maintenance un serveur
Formulaire Delivery Group : possibilité de mettre en maintenance un Delivery Group
Formulaire Application : possibilité de mettre en maintenance une application
Admin guide au format pdf
Nouveau SplashScreen

XenApp_Usr7x-V2.1.rar

L’admin guide en ligne (disponible aussi dans le fichier rar) :

[gview file=”https://www.ctxblog.fr/wp-content/uploads/2018/05/XenApp_usr7xV2-21AdminGuide-2.pdf”]

Troubleshooting for newbies (erreur upgrade VDA)

Dans ce billet rien de très follichon juste une erreur lors d’un upgrade de Vda 7.14.1 vers 7.15 LTSR (CU1) sur un serveur W2K16 US.

Donc il est 2:00 du mat, il est temps de matter un épisode de notre série favorite du moment et la bim un upgrade de VDA qui nous pond une erreur.

Encore une erreur bien parlante 🙂

En cliquant sur View détails on avait ça :

Error Id: XDMI:619E0143

Exception:

System.NullReferenceException Object reference not set to an instance of an object.
at Citrix.MetaInstaller.UI.Pages.Common.ViewModels.ComponentPageViewModel..ctor(MainWindowViewModel mainWindowViewModel, BaseDataModel dataModel)
at Citrix.MetaInstaller.UI.Pages.Vda.ViewModels.VdaMainWindowViewModel.CreatePages()
at Citrix.MetaInstaller.WizardFramework.MainWindowViewModel.Initialize()
at Citrix.MetaInstaller.UI.Pages.Vda.ViewModels.VdaMainWindowViewModel.Initialize()
at Citrix.MetaInstaller.MetaInstallerWpfApplication.OnStartup(StartupEventArgs e)
at System.Windows.Application.<.ctor>b__1(Object unused)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.DispatcherOperation.InvokeImpl()
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.ProcessQueue()
at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(DispatcherPriority priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame frame)
at System.Windows.Application.RunInternal(Window window)
at System.Windows.Application.Run()
at Citrix.MetaInstaller.MetaInstallerApplication.Run(String[] args)
at Citrix.MetaInstaller.MetaInstallerApplication.InstallResultMain(String[] args)

Bon on n’est pas plus avancé, mais un reflex de Sysadmin nous est revenu en cette heure tardive, lancez l’install du Vda via un “Run as administator” et là ça passe direct.

On est bon pour aller matter notre série 🙂

XenApp 7.15 LTSR CU1 : Souris figée et problème de redimenssionnement de fenêtre

Lors de la mise en place d’un silo de serveur Windows 2016 (us) dans une ferme XenApp 7.15 LTSR CU1 nous avons rencontré un problème de souris figée lors du lancement des bureaux publiés. Lors du lancement d’un bureau publié un pointeur de souris apparaissait en plein milieu du bureau sans que nous puissions bouger ce pointeur de souris, cependant le “vrai” pointeur de notre souris lui était bien actif au sein de la session (on se retrouve donc avec deux pointeurs de souris).

Imaginez un utilisateur expliquer qu’il a une souris en plein millieu de son écran 🙂

Autre problème le redimenssionement de la fenêtre du bureau publié ne fonctionnait pas.

Le VDA installé sur les serveurs XenApp est le 7.15.1000.150 .

Après plusieurs tests le seul moyen que nous ayons trouvé pour résoudre ce problème est de désactiver le “Legacy graphic mode”.

Une fois le “Legacy graphics mode désactivé”, le bureau publié était dimensionnable et la souris figée avait disparu.

Error : no Citrix SSL Server configured on the specified address

Pour débuter l’année 2018 (bonne année 2018 au passage), nous avons été solicités pour un problème de mise en place d’EDT (pour ceux qui ne connaissent pas encore EDT nous vous recommandons la lecture d’Adaptative Transport).

En regardant la configuration des Netscalers et de la ferme XenApp (7.13) en question tout était ok et aucun log ou event lors du lancement d’application publiée n’est présent. Nous passons donc le setting “HDX Adaptive Transport” sur “Diagnostic Mode” en lieu et place de “Preferred”.

Désormais nous avons une erreur 🙂

Bon soyons hônnetes ça nous avance pas, mais on comprend qu’il faut regarder côté réseau (vu quand sans EDT les applications se lancent sans problème) histoire de voir ce qui ne passe pas, et la surprise……. l’UDP sur le 443 n’était pas ouvert sur les Firewall 🙁 .

C’est juste pour ceux qui ont aimé la série 😉

Supprimer un controler récalcitrant de la Database

Dans un environnement “Hors Prod” nous avons rencontré un problème sur un Controller, en effet ce dernier était encore inscrit dans la ferme mais le DSName n’était plus renseigné et le MachineName contenait le SID du controller en lieu et place du nom.

Bien sûr une suppression dans Studio n’était pas possible 🙁

En googlelant nous sommes tombés sur un poste de JGSPIERS.COM “Remove orphaned Delivery Controller from XenApp XenDesktop Site“, qui via un script PowerShell (EvictiScript.ps1 ; modifier au préalable les variables $DBName $EvictedSID) va générer un fichier evict_.txt contenant le script sql à exécuter sur le serveur SQL hébergeant votre Database.

Une fois ces étapes réalisées, notre Controller est bien supprimé de la Database (tout du moins en partie mais ça nous le verrons plus bas dans ce billet), en effet nous ne le voyons plus via un Get-BrokerController.

Le script de nettoyage a bien supprimé le Controller non résolu

Continue reading “Supprimer un controler récalcitrant de la Database”

XenApp_Usr7x V2

UPDATE : 31/05/2018
V2.1

Formulaire principal : possibilité de faire un gpupdate sur le serveur hébergeant l’utilisateur sélectionné
Formulaire principal : possibilité d’afficher les informations d’un process (process id, command line, creation date, executable path et le WorkingSetSize en dinamique)
Formulaire principal : envoi dans le clipboard de toutes les informations utilisateurs affichées
Formulaire principal : ajout du menu action (permettant de faire une recherche d’une Application/server/Delivery Group…)
Formulaire Server : lancement d’un GPUPDATE sur le serveur
Formulaire Server : possibilité de mettre en maintenance un serveur
Formulaire Delivery Group : possibilité de mettre en maintenance un Delivery Group
Formulaire Application : possibilité de mettre en maintenance une application
Admin guide au format pdf
Nouveau SplashScreen

A l’époque lors de l’écriture de XenApp_Usr7x nous avions longuement hésité à passer sous C#, puis par facilité et manque de temps nous avions continué à faire du GUI sous PowerShell (on n’était dejà pas fan mais la fascilité l’emportait). Pour le passage de XenApp_Usr7x en V2 nous avons donc franchi le pas et avons donc écrit XenApp_Usr7x V2 sous C# 🙂 .

Pour rappel XenApp_Usr7x (et XenApp_Usr) est un outil permettant de rechercher une session au sein d’une ferme XenApp/Xendesktop (version 7x) et d’afficher les informations se rapportant à la session de l’utilisateur recherché (ce qui évite les allers-retours entre les consoles Studio et Director).

A qui s’adresse XenApp_Usr7x ? Aux collègues du support qui pourront rapidement rechercher une session utilisateur et disposer des informations et actions néccéssaires (sans devoir jongler entre les consoles Studio et Director) au support niveau 1, puis escalader si besoin l’incident avec toutes les informations disponibles, aux collègues administrateurs qui pourront à leur tour aller plus loin dans l’investigation (affichage de compteurs de performance, métrique utilisateur, action sur les process, check de la database etc..etc..).

Les nouveautés par rapport à l’ancienne version :

Un beau SplashScreen (ok faut aimer les dinos)
Amélioration des temps d’ouverture de toutes les fenêtres
Utilisateur :
- Affichage de l’historique des connections
- Affichage du RTT ICA, Latence ICA, Input Bandwith Used et Output Bandwith Used
Server
- Affichage en temps réel de la consommation CPU, RAM, Paging File Used, Disk free space, Avg disc sec/read et Avg disc sec/write
Delivery Group
- Un graphique circulaire affiche le pourcentage de charge du DG
Process
- Un double clique sur un process entraine l’ouverture d’une fenêtre affichant les principales informations du process (dont notamment le Working Set Size refresh en temps réel)
Base
- Check de la base de données (Database)
Prise en compte de l’ajout de Controller une fois le fichier de configuration modifié (plus besoin de passer par le menu refresh)
Tooltips (bulle d’information) sur les différents bouttons

Pré-requis :

Exécutez XenApp_Usr7x à partir d’un serveur Windows 2012R2/2016
Les snapins Citrix doivent être installé sur le serveur

Installation/Execution :

Décompressez le contenu de l’archive et double cliquez sur le fichier XenApp_Usr7x-V2.exe

Entrez le nom d’un Controller dans le champ DDC puis cliquez sur le bouton (situé à droite du champ DDC)
Le bouton permet de rajouter des Controllers afin de permettre de passer d’une ferme à une autre facilement

Entrez le nom de l’utilisateur recherché dans le champ Username puis cliquez sur le bouton (situé à droite du champ Username)

Cliquez sur la session souhaitée afin d’afficher les informations relative à la session
Les champs encadrés en rouge sont cliquables

Un clique sur le bouton permet d’afficher l’historique des sessions.

Un clique sur le bouton permet d’afficher en temps réel le RTT ICA, la latence ICA, l’Input/Output bandwith used.

Un clique sur le bouton permet de lancer une assistance à distance sur la session.

Un clique sur le bouton permet d’envoyez un message à l’utisateur au sein de la session.

un clique sur le bouton permet de fermer la session.

Le champ server est cliquable et permet d’afficher les principales informations concernant le serveur (charge, type de serveur, cpu, ram, Ip, Os, sessions, Gpo(s), process etc..)

Un clique sur le bouton du formulaire Server permet d’afficher les compteurs Cpu, Ram, Paging file used, Disk free space, Avg disc sec/read, Avg disc sec/write.

Le champ Delivery Group est cliquable et permet d’afficher les principales informations concernant le Delivery Group du serveur hébergeant la session (Type de DG, liste des serveurs membres du DG, liste des applications publiées dans le DG etc.. etc..).

Un clique sur le champ Farm name (du formulaire principale) ouvre une fenêtre affichant les principales informations concernant la ferme en cour.

Un clique sur le bouton permet de lancer des checks sur la Database.

Vos remarques et suggestions sont comme d’habitude les bienvenues 😉 .

XenApp_Usr7x-V2.rar

Un grand merci à Etienne, Baderedine, Kamel, Frederic et Jorge pour leurs tests et retours.

Problème de DPI entre deux écrans

Comme vous le savez sûrement, la difference de DPI entre deux écrans lors de connection HDX n’est pas supporté par Citrix (Different zoom or DPI level in XenDesktop and XenApp).

Au moins c’est clair 😉

Bon ok ce n’est pas supporté, mais on a une population qui utilise deux écrans de taille différante et qui joue avec des DPI différents entre les deux écrans, ce qui engendre des problèmes de scintillements sur les applications publiées.

Une solution pour contourner (voir l’article Some desktop applications may appear blurred on high-DPI displays de chez Miscrosoft) ce problème est de modifier les propriétés des binaires wfcrun32.exe et wfica32.exe (C:\Program Files (x86)\Citrix\ICA Client) afin de “désactiver la mise à l’échelle de l’affichage pour les résolutions élevées” (Disable Display Scaling On High DPI Settings).

Une fois “la mise à l’échelle de l’affichage pour les résolutions élevées” désactivée, nos utilisateurs n’ont plus rencontré de problème de scintillement sur les applications publiées.

Erreur dans Studio : Register upgraded Delivery Controllers

Si vous rencontrez le message d’information “Register upgraded Delivery Controllers” dans Studio (dans notre cas sur du XA 7,6), alors il se pourrait que l’un de vos DDC n’ait pas (ou n’ai plus) les permissions adéquates côté SQL.

Quand on regarde l’erreur en détail on obtient :

Error Id: XDDS:400E633A
Exception:
Citrix.Console.Models.Exceptions.PermissionDeniedException You are not authorized to perform this operation.
…………………………………………………………………………………………………………………………………………………………………………..
…………………………………………………………………………………………………………………………………………………………………………..
…………………………………………………………………………………………………………………………………………………………………………..
…………………………………………………………………………………………………………………………………………………………………………..
Set-LogDBConnection -AdminAddress “DDC02.YourDomain.fr:80” -DataStore “Logging” -DBConnection “Server=YourSqlServer;Initial Catalog=SiteConfigurationDatabase;Integrated
Security=True” -Force
Set-LogDBConnection : There was a problem communicating with the Citrix Delegated Administration Service.

En regardant directement sur le serveur SQL nous avons remarqué dans les logs que le DDC02 ne pouvait plus s’authentifier sur le serveur SQL.

Log SQL Server (Current – Date Time)
Source Logon
Message
Login failed for user ‘Domain\DDC2$’. Reason: Could not find a login matching the name provided. [CLIENT: IPServer XXX.XXX.XXX.XXX]

Une fois le compte ordinateur rajouté dans Security-Logins sur le serveur SQL, nous n’avons plus rencontré d’erreur.

La question qui se pose est bien sûr : comment ce compte ordinateur a disparu 🙂 , nous penchons pour l’instant à un “problème” de réplication SQL Alwayson.

Si vous souhaitez des détails sur les privilèges SQL pour XD/XA nous vous conseillons la lecture de la CTX127998.