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 .

En gros tout est en registre, direction HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\Extensions (ou HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Extensions) :

• Création d’un GUID (dans notre cas par uuidgen).
• Création d’un clé avec comme nom le GUID  obtenu via uuidgen
• Création de la valeur CLSID avec comme valeur {1FBA04EE-3024-11D2-8F1F-0000F87ABD16}
• Création de la clé Exec avec comme valeur l’exe qui vous interresses (ou le script)
• Création de la clé MenuText avec comme valeur le nom qui s’affichera dans le menu outils d’IE

Et c’est tout, reste à lancer IE (testé avec un IE6 ).

Tout est expliqué ici.

Bref rien d’extraordinaire, juste la simplicité du tips .

Nom du journal : Application
Source :       MSSQLSERVER
ID de l’événement :17806
Description : Échec de la négociation SSPI avec le code d’erreur 0x8009030c, état 14 lors de l’établissement d’une connexion avec une sécurité intégrée ; la connexion a été fermée. Raison : Échec d’AcceptSecurityContext. Le code d’erreur Windows indique la cause de l’erreur.  [CLIENT : 10.101.xxx.xxx].

En allant sur le serveur CLIENT (serveur XenApp 6.5)  indiqué dans la description de l’event nous avons trouvé l’event suivant :

Source :       IMAService
ID de l’événement :3989
Description : Le serveur Citrix XenApp n’a pas pu se connecter au magasin de données. Une erreur ODBC s’est produite lors de la connexion à la base de données : 28000 -> [Microsoft][ODBC SQL Server Driver][SQL Server]Échec de la connexion. La connexion provient d’un domaine non approuvé et ne peut pas être utilisée avec l’authentification Windows.

Nous avons trouvé un article chez SarePoint It Prof qui traite ce type de problème.

Deux solutions sont possibles (celle du registre est à réserver pour un environnement de qualif, sinon ldap389 risque de ne pas être content ) .

• jouer avec le registre :

1. Edit the registry using regedit. (start –> run … Regedit )
2. Browse to : HKLM\System\CurrentControlSet\Control\LSA
3. Add a DWORD value called “DisableLoopbackCheck”
4. Set this value to 1

• Modifier le spn :  SetSpn -A MSSQLSvc/sql.mb.local:1433 MB\sql_service

]]> http://www.ctxblog.fr/2012/05/05/erreur-sql-echec-de-la-negociation-sspi-avec-le-code-derreur-0x8009030c/feed/ 0 http://www.ctxblog.fr/2012/04/23/erreur-another-version-of-microsoft-visual-studio-2008-has-been-detected-on-this-system-sur-serveur-xa-6-5/ http://www.ctxblog.fr/2012/04/23/erreur-another-version-of-microsoft-visual-studio-2008-has-been-detected-on-this-system-sur-serveur-xa-6-5/#comments Mon, 23 Apr 2012 21:02:56 +0000 ctxblog http://www.ctxblog.fr/?p=2288 Sur un serveur XenApp 6.5 nous avons installé Sql 2008 R2 standard (c’est de la qualif ), le problème est que l’installation de SSMS (SQL Server Management Studio) n’a pu aboutir.
Dans le journal « application » nous avons trouvé l’event suivant :

Nom du journal :Application
Source :       MsiInstaller
ID de l’événement :1013
Description : Product: Microsoft Visual Studio Tools for Applications 2.0 – ENU — Another version of Microsoft Visual Studio 2008 has been detected on this system that must be updated to SP1.  Please update all Visual Studio 2008 installations to SP1 level, by visiting Microsoft Update.

La CTX128280 explique comment bypasser cette erreur en renommant la clé HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS.

Une fois la clé HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS renommée, nous avons pu installer SSMS (n’oubliez pas de renommer la clé une fois SSMS installé).

Source :       Microsoft-Windows-IIS-W3SVC
ID de l’événement :1004
Le service de publication World Wide Web (service WWW) n’a pas inscrit le préfixe d’URL http://*:80/ pour le site 1. Le site a été désactivé. Le champ des données contient le numéro de l’erreur.

Lors de l’installation de notre ferme de qualif , nous avions (exceptionnellement  ) laissé le port 80 pour l’Xml, du coup lors de l’installation de IIS le port 80 pour le site par défaut n’était pas disponible.

Effectivement ctxxmlss prend bien le port 80

Changer le port xml est très simple et se fait via la commande ctxxmlss /RXXXX (dans notre cas on affectionne le port 8085).

Le port xml est bien passé sur le 8085

ctxxmlss est bien sur le 8085 désormais

HostID  xxxx has no corresponding MfServer node entry

Après plusieurs dscheck /full servers /clean l’erreur était toujours présente.

Nous avons lancé un Dsview afin de voir si on pouvait résoudre le HostID 5C80 en cherchant dans la partie ServerNeighborhoods-VotreFerme-MFServers.

Comme nous n’avons rien trouvé dans la partie  ServerNeighborhoods-VotreFerme-MFServers, nous avons orienté notre recherche vers la partie ServerNeighborhoods-VotreFerme-HostIds.

Nous trouvons et remarquons que le HostId 5C80 a des liens avec d’autres HostId (au passage on ne l’a pas vu du premier coup ).

Retour dans la partie ServerNeighborhoods-VotreFerme-MFServers, et là nous trouvons bien les hostId avec les Hostnames associés.

Après avoir sorti les 4 serveurs de la ferme (bien que ces serveurs ne présentaient visiblement aucun problème), la commande dscheck /full servers /clean a cette fois-ci bien supprimé le HostId récalcitrant (5C80 dans notre cas).
Une fois le Host Id supprimé nous avons pu ré-intégrer les quatres serveurs dans la ferme puis passer un dscheck /full servers qui n’a remonté aucune erreur .

On vous passe les différentes étapes de troubleshooting, dsview (mais avec les yeux fermés les premières fois), tentative de lecture du DataStore (mais bon vu que la base n’est pas de type relationnelle on se savait mal parti), import du DS dans une batterie de test et suppression des objets,  etc..etc.. En bref un moumoutage en bonne et due forme .

Nous avons réalisé un script wsf (ça faisait longtemps qu’on n’avait pas mis les mains dans les MFCOM ) afin de pouvoir désactiver dans un premier temps l’héritage des paramètres de la batterie (puisque dans notre cas le SpeedScreen était paramétré au niveau de la batterie), puis de désactiver l’accélération de navigation HDX 3D (le script filtre les serveurs en fonction du hostname, voir ligne 67 du script).

Une fois les infos trouvées sur la bible des MFCOM, la lecture est lourde mais à chaque fois payante  .

Avant le script

Après le script

SpeedScreen_Disable.wsf

Le seul problème que nous avons rencontré se situait au niveau des temps de logon sur nos Web Interface lorsque nos Web Interface passaient par la VIP dédiée aux Xml broker.

En googlelant nous sommes tombés sur la CTX118870, nous avons choisi la troisième solution qui consiste à désactiver la partie « NETBIOS over Tcp/Ip » sur les serveurs Web Interface

Dès que nous avons désactivé la partie « NETBIOS over Tcp/Ip » sur nos Wi les temps de logon sont revenus à la normale .

Après un peu plus de deux ans, nous avons mis à jour test_port .

Outre la correction des divers bug et la simplification du code,  il est possible désormais de tester les ports sur plusieurs serveurs.

Cliquez sur le bouton « Ouvrir le fichier serveur cible » (le fichier est crée automatiquement)
Renseignez les Ip des serveurs à tester et enregistrez le fichier
Cliquez sur le bouton « Lancer le test« 

Test_Port V1.3

MAJ : 03/04/2012
Test_Port V1.3
Correction bug : lors clic sur le bouton Ouvrir le fichier serveur Cible  le fichier servers.txt ne gardait pas les informations enregistrées.

Merci à Julien pour l’info .

Le trhead où on cause leak memory sous XenApp 6.5 est ici.

————————-
MAJ :  22/04/2012
————————-
Depuis l’installation du XA650W2K8R2X64019 nous ne rencontrons plus de problème leak memory.