Internet Explorer

Horizon 7.10 error : warning Echec de la connexion

Suite à la migration d’un environnement Horizon view 7.3 vers 7.10, on nous a remonté une erreur de connexion à la console d’administration HTML5 avec les navigateurs Chrome (79.0.3945.117 – Build officiel – 32 bits ) et Firefox (72.0.1 – 32 bits).

Le problème se produit uniquement avec Chrome et Firefox… qui a dit que Internet Explorer était un mauvais navigateur 🙂 .

Ce problème de connection peut-être résolu en modificant le fichier “locked.properties” (dans le cadre d’un problème d’affichage HTML5 via le navigateur Edge et en passant par des F5 nous avions deja eu l’occasion de jouer avec le fichier “locked.properties”). Revennons à nos moutons, la KB2144768 chez VMware nous donne la liste des actions à réaliser afin résoudre ce problème de connexion.

Créer le fichier C:\Program Files\VMware\VMware View\Server\sslgateway\conf\ locked.properties
Ajouter la ligne : checkOrigin=false
Redémarrer le service « Composant VMware Horizon View Security Gateway” (wstunnel)

Voila ça c’est fait (il nous reste encore quelques bugs qui feront l’objet d’autres posts 🙂 )

Erreur : Internet Explorer has stopped working

Sur un silo de serveurs (Xenapp 6.5 R06, windows 2008 r2 sp1 Us) les applications publiées sous IE (Internet Explorer 9) rencontraient l’erreur ci-dessous :

Internet Explorer has stopped working
A problem caused the program to stop working correctly. Please close the program

Dans le journal d’evenement “application” on retrouve à chaque crash l’Event ID : 1000

Log Name:      Application
Source:        Application Error
Event ID:      1000
Task Category: (100)
Level:         Error
Description:
Faulting application name: iexplore.exe, version: 8.0.7601.19058, time stamp: 0x563ce980
Faulting module name: PseudoServerInproc2.dll, version: 6.2.0.57, time stamp: 0x4e1c9864
Exception code: 0x80000003
Fault offset: 0x00101eaf
Faulting process id: 0x1990
Faulting application path: C:\Program Files (x86)\Internet Explorer\iexplore.exe
Faulting module path: C:\Program Files (x86)\Citrix\System32\PseudoServerInproc2.dll

L’event étant on ne peut plus clair,on a donc un problème avec la redirection FLASH et plus précisément avec la dll “PseudoServerInproc2.dll”. Dans un premier temps il a fallu rétablir le service asap c’est pourquoi (après quelques recherches) nous avons supprimé la clé ci-dessous (pas besoin de reboot pour la prise en compte).

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\CtxHook\AppInit_Dlls\
HDXMediaStreamForFlash\iexplore.exe

Une fois la clé supprimée les utilisateurs n’ont plus rencontré de crash IE, cependant ça reste la solution “provisoire”, dès que possible on regardera du côté de la CTX141429 .

Cette CTX141429 devrait résoudre notre problème 😉

StoreFront 3.x erreur : Impossible de démarrer le bureau…….

Sur un cluster de StoreFront 3.0 (W2K12 US) nous avons rencontré un problème de lancement d’applications et bureaux publiés (ferme en XA 7.6 US) avec Internet Explorer (ver 9,10 et11), en effet cela fonctionnait sans problème avec Firefox et Chrome.

On va pas se réconcilier de si tôt avec IE

En regardant sur les Storefronts nous avons constaté les Event ID 0 et 28.

Description: Failed to launch the resource ‘………………’ using the Citrix XML Service at address ‘http://VotreServeur/scripts/wpnbr.dll’. The XML service returned error: ‘not-trusted’.

Description: The Citrix servers do not trust the server. This message was reported from the XML Service at address http://VotreServeur/scripts/wpnbr.dll [NFuseProtocol.TRequestAddress].

Ce qui nous a mis sur la piste est bien sur le “The Citrix servers do not trust the server”, en effet en lancant un Get-BrokerSite sur un de nos Delivery Controller nous avons constaté que la valeur TrusRequestsSentToTheXmlServicePort était à False.

SF3Error4 On vous l’accorde ça n’explique pas le fait que ça fonctionne avec d’autres navigateurs

Afin d’activer le TrustRequestSentToTheXmlServicePort il faut lancer la commande suivante sur un de vos Delivery Controller : Set-BrokerSite -TrustRequestSentToTheXmlServicePort $True

La commande Get-BrokerSite confirme bien que nous sommes en True en TrustRequestSentToTheXmlServicePort

Et oui avant on pouvait setter l’approbation des requêtes XML en policy (exemple sur une ferme en XA 6.5)

Forcer la Publication d’Internet Explorer en full screen

Si vous souhaitez forcer la publication d’Internet Explorer (dans notre cas sous XenApp 6.5) en seamless, la CTX132434 explique comment le faire via le vbs ci-dessous :

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run "iexplore.exe", 3, false

Dans notre cas nous souhaitons publier plusieurs url applicatives tout en évitant la multiplication du script ci-dessus. Nous avons donc modifié le script afin que nous puissions mettre en argument une url.

Set WshShell = WScript.CreateObject("WScript.Shell")
If wscript.Arguments.length = 0 Then
WshShell.Run "iexplore.exe", 3, false
Else
WshShell.Run "iexplore.exe" & Space(1) & wscript.arguments(0), 3, false
End if

Rajoutez l’url en fin de ligne de commande

Rajouter un item dans le menu outils d’Internet Explorer

Si vous souhaitez rajouter un item dans le menu outils d’Internet Explorer (dans notre cas un IE6), c’est on ne peut plus simple.

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

Récupérer un fichier launch.ica dans une Web Interface 5.x

Si comme nous, vous avez été confronté à un problème de récupération de fichier “launch.ica” dans une Web Interface 5.x via IE.

Lors d’un clique droit sur l’application, si vous faîtes “Enregistrer la cible sous”, vous ne pouvez enregistrer qu’un fichier “launcher.htm”.

Une façon de pouvoir récupérer le fichier “launch.ica” est de modifier dans IE les options suivantes :

Allez dans Outils – Options – Sécurité.

Choisissez “Intranet Local” (c’est selon où votre Web Interface est située), puis cliquez sur “Personnaliser le niveau”.

Désactivez les options suivantes :

Contrôle d’initialisation et de script ActiveX non marqués comme sécurisés pour l’écriture de script.

Exécutez les contrôles ActiveX et les plug-ins

Cliquez que le bouton Ok, puis fermer IE.

Retournez sur votre site Web Interface, une fois authentifié faite un clique droite sur une application.

Attention cette manip répondait à un besoin bien spécifique qui nécessitait de récupérer le fichier launch.ica.

Bien qu’il soit possible de lancer l’application via la Web-Interface, des effets de bords peuvent apparaitre.

Testé sur IE 6 et 8 (OS 2003 sp2 et XP sp3) sur une Web Interface 5.1 et 5.4

———————–
MAJ : 05/11/2011
———————–

Et pour les plus fainéants 🙂 nous joignons deux fichiers reg permettant d’enable ou disable (dans la zone Intranet) les settings “Contrôle d’initialisation et de script ActiveX non marqués comme sécurisés pour l’écriture de script” et “Exécutez les contrôles ActiveX et les plug-ins“.

Enable_Launch.ica

Disable_Launch.ica

Si votre WI est dans une autre zone que la zone intranet dans ce cas il vous faut de modifier le chiffre à la fin de la clé “HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1”

les valeurs pour enable les settings :
“1200”=dword:00000003
“1201”=dword:00000003

les valeurs pour disable les settings :
“1200”=dword:00000000
“1201”=dword:00000000