Le Rollup Pack 1 pour XenApp 6.5 est disponible depuis le 28/06/2012, reste plus qu’à le tester en qualif avant le passage en prod 😉 .
Rollup Pack 1 XenApp 6.5 (Fr) : CTX132190
Rollup Pack 1 XenApp 6.5 (Us) : CTX132112
Citrix vient de mettre à jour son White paper “Logon Optimization”, à lire impérativement si vous souhaitez comprendre et optimiser vos logons (qui ne le voudrait pas 🙂 ) .
Un schéma que vous connaissez déjà 😉
Sympa ce screenshot Edgesight qui vous donnes la définition des divers abréviations contenu dans le tableau “détail de démarrage du serveur”
Ho le beau PLSD (temps de chargement du profil), reste plus qu’à…. 🙂
Sur un serveur EdgeSight (EdgeSight 5.4 en Windows 2003 sp2 Fr) nous avions l’erreur ci-dessous lors de l’exécution manuelle des tâches à distance sur un agent :
Une erreur s’est produite lors de la connexion à la machine : Accès Refusé : vous n’avez pas la permission d’accéder à cette ressource.
La CTX111046 traite le problème en recommandant de modifier le valeur RemoteSecurity ou bien la valeur RemoteSecurityGroup (HKEY_LOCAL_MACHINE\Software\Citrix\System Monitoring\Agent\Core\4.00\), ces deux valeurs permettent de fixer le niveau de sécurité des accès à distance de l’agent.
Valeur RemoteSecurity avant modification
Une fois la valeur RemoteSecurity passé à 0, l’exécution de tâche fonctionne sans problème (bien sûr il est déconseiller de laisser la valeur RemoteSecurity à 0 dans un environnement de production) .
Lors d’une migration XenApp 6.0 (la fameuse bêta version 🙂 ) vers une ferme XenApp 6.5, nous avons rencontré des problèmes d’intégration dans la ferme XA 6.5 sur deux serveurs.
Les symptômes : l’IMA ne démarrait pas et le MFCOM lui restait dans le statut démarrage.
Les events rencontrés étaient les suivants :
Nom du journal :System
Source : Service Control Manager
ID de l’événement :7024
Description :
Le service Citrix Independent Management Architecture s’est arrêté avec l’erreur service particulière %%-2147483647.
Nom du journal :System
Source : IMAService
ID de l’événement :3601
Description :
Échec de chargement des plug-ins initiaux. Erreur IMA_RESULT_FAILURE
Nom du journal :System
Source : IMAService
ID de l’événement :3609
Description :
Échec de chargement du module C:\Program Files (x86)\Citrix\System32\Citrix\IMA\SubSystems\MfSrvSs.dll. Erreur IMA_RESULT_FAILURE
Nom du journal :Application
Source : MetaFrameEvents
ID de l’événement :1
Description :
Les écouteurs ICA Citrix semblent être désactivés. Veuillez vérifier que les écouteurs ICA Citrix sont activés.
La résolution passe comme d’habitude par une recherche google (tout d’abord merci à Menhir Two qui avait déjà troubleshooté le problème 😉 ),qui nous emmène tout droit sur un thread du forum Citrix : IMA Service will not start. EVENT ID 1.
En bref il faut remettre à jour les certificats racines via la KB931125 (bien que prévu pour de l’Xp la KB931125 fonctionne très bien sous 2008 R2).
Une fois les certificats racines mis à jour (enfin on parle de certif de 2011 🙂 ), les service IMA et MFCOM démarrent sans problème.
Il y a quelques jours nous sommes tombés sur une erreur SQL (suite à la mise en place de Database mail) :
[364] Le service Messenger n’a pas été démarré. Les notifications NetSend ne seront pas envoyées.
Après une recherche google avec notre collègue et ami VMDUDE, nous avons trouvé THE trick (bravo MS au passage) sur un billet publié sur le msdn.
En effet lors de la configuration de Database Mail (au passage un step by step est dispo chez codeproject) il faut aussi activer le profile de messagerie : clique droit sur SQL serveur Agent – propriété – Système d’alerte puis cliquez sur Activer le profile de messagerie.
Bien sur ça se passe de commentaire 🙂 .
Citrix vient de racheter ByteMobile (spécialiste de l’optimisation réseau mobile), voir le billet sur lemondeinformatique.fr .
Un rapide coup d’oeil sur wiki et on s’aperçois que le rythme de rachat est très soutenu 🙂 .
Recensement nous avons rencontré un problème d’inscription de serveur (Serveur XenApp 6.5 fr avec un agent Edgesight 5.4) au sein d’un EdgesSight 5.4.
En effet le serveur refusait de s’inscrire dans Edgesight, aucune log côté serveur EdgeSight, idem sur le serveur XenApp récalcitrant (aucun event system et appli), le fichier SYS_EVENT_TXT.txt (C:\ProgramData\Citrix\System Monitoring\Data) ne donnant rien non plus, nous avons opter pour la solution bourrin ci-dessous.
Afin de pouvoir inscrire le serveur nous avons du réaliser les actions ci-dessous (c’est trash mais bon) :
Quelques liens pratique sur le sujet :
http://support.citrix.com/article/CTX112209
http://support.citrix.com/article/CTX116547
Si vous recherchez des informations sur qui et quoi monitorer sur vos ferme XenApp, Citrix vient de sortir un white paper fort intéressant : “Operations Guide – Monitoring“.
Sur un de nos serveurs d’infra XenApp 6.5 nous avons eu besoin d’installer le Citrix.GroupPolicy.Commands (afin de pouvoir importer/exporter des policies, voir la CTX128625 pour de plus amples informations) avec en pré-requis le SDK Powershell XenApp 6.5 (au passage si vous chercher un SDK pour XenApp : SDK XenApp ).
Nous avons écrit un script permettant d’installer en unattended le SDK powershell XenApp 6.5 et le Citrix.GroupPolicy.Commands.
Au préalable télécharger le SDK Powershell XenApp 6.5 puis extraire son contenu (via 7-Zip par exemple), puis télécharger le Citrix.GroupPolicy.Commands et le copier dans le dossier setup du SDK.
Renseignez la variable $msiPath (mettre le chemin menant au dossier setup du SDK), puis exécuter le script sur le serveur en question.
$msiPath = "\\PATH_SDK\Setup\" $msi = @(($msipath+"Citrix.Common.Commands.Install_x64.msi"), ($msipath+"Citrix.XenApp.Commands.Client.Install_x64.msi"), ($msipath+"Citrix.XenApp.Server.Sdk_x64.msi"), ($msipath+"CitrixGroupPolicyManagement_x64.msi")) foreach($_ in $msi) {Start-Process -FilePath msiexec -ArgumentList /i, $_, /qb- -Wait Write-Host "$msi" } import-module ($MsiPath+"Citrix.GroupPolicy.Commands")
Il est aussi possible de passer par un invoke-command à la place du Start-Process pour une installation en remote, le /qb- c’est juste qu’on aime bien voir les progressbar lors des installations 🙂 .
Following a dscheck (dscheck /full servers) on one of our farms (XenApp 5 R06 of 400 servers with DataStore sql 2005 on Windows 2003 sp2), we noticed the following error :
HostID xxxx has no corresponding MfServer node entryHostID xxxx has no corresponding MfServer node entry
After several dscheck /full servers /clean the error was always present.
We launched Dsview in order to see whether WE could solve HostID 5C80 BY seeking in the part ServerNeighborhoods-YouFarm-MFServers.
As we did not find anything in the ServerNeighborhoods-YouFarm-MFServers part, we directed our search towards the ServerNeighborhoods-VotreFerme-HostIds part.
We find and notice that HostId 5C80 on the way has links with other HostId (one did not see it at first glance)
Back in the ServerNeighborhoods-YourFarm-MFServers part, and there we find the hostId with Hostnames associated.
After having left the 4 servers the farm (although these servers did not present obviously any issue), the command dscheck /full servers /clean has this time deleted well recalcitrant HostId (5C80 in our case).
Once Host Id deleted we could reinstate the four servers in the farm then to pass a dscheck /full servers which did not show up any error.
Not mentionning to you the various stages of troubleshooting, dsview (but with the closed eyes first times), attempt at reading of DataStore (but good considering the foundation is not of relational type one party knew badly), importation of the DS in a series of tests and deletion of the objects, etc .etc. In short a “moumoutage” (french expression) in due form.