Customisation StoreFront 3.x (1/2)

Customiser un StoreFront n’a rien de compliqué (merci CSS et la fenêtre de développement de votre browser favori, exemple la touche F12 pour Chrome).

Ce billet sera divisé en deux parties, la première partie traite de la customisation de la page de login de StoreFront (dans notre cas un SF 3.01.55 fr sur un serveur 2008 R2 sp1 fr) , la deuxième partie traitera de la page affichant les applications et bureaux.

 

SF3_Custo01La page de login du thème X1

Le but dans notre exemple est d’obtenir un thème avec des nuances de gris.


SF3_Custo03
La page de login une fois customisée

La mise en place de cette customisation est simple et rapide, décompresser le fichier “Custo1_SF3x.rar” et copier le fichier “style.css” dans “..\VotreStoreWeb\Custom” (au préalable faite un backup de votre fichier “style.css”), copier le répertoire “CustoImages” dans “…\VotreStoreWeb\receiver\images” puis vider le cache de votre navigateur.

Vous trouverez ci-dessous la liste des éléments que nous avons modifiés via le fichier “style.css” (contenu dans le répertoire “Custom”) afin de vous permettre de mettre en place votre propre customisation 😉 .

  • Modifier le logo
    .logon-logo-container {
    background-image: url(“../receiver/images/CustoImages/SF_custo_auth_14B96BFF2B0A6FF8.png”);
    background-repeat: no-repeat;
    background-position: center center
    }
  • Modifier l’image de fond
    .web-screen {
    background-color: #161619;
    background-image: url(“../receiver/images/CustoImages/SF_custo_FullScreenBackground_46E559C0E6B5A27B.jpg”);
    background-size: 100% 100%;
    min-height: 400px;
    height: auto!important;
    height: 400px
    }
  • Modifier l’effet de transparence de la bannière centrale
    .web-screen .content-area {
    padding: 60px 0;
    background-color: #3f3643;
    background-color: rgba(63, 54, 67, 0.2);
    text-align: center
    }
  • Modifier la couleur des textbox Nom d’utilisateur et Mot de passe
    .credentialform .plain {
    margin-left: 0;
    color: #FFFFFF;
    font-size: 17px;
    font-weight: 300;
    line-height: 44px
    }
  • Modifer la couleur du bouton “Ouvrir une session”
    .button.default {
    background-color: #1E1E1E
    }
  • Modifier la couleur et taille des champs Username et Password
    .credentialform input[type=text],
    .credentialform input[type=password],
    .credentialform .pseudo-input {
    box-sizing: border-box;
    width: 385px;
    height: 40px;
    outline: 0;
    border: 0;
    background-color: #E4E3E3;
    font-size: 16px;
    color: #000
    }

Download_2Custo1_SF3x.rar

Post to Twitter

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.

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


SF3Error2

 

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

 

SF3Error3

 

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.


SF3Error4On 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

 

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

 


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

 

Post to Twitter

StoreFront 3.0 : perte des icones

Sur un groupe de StoreFront 3.0 de qualif nous avons rencontré un problème d’icônes. En effet toutes les icônes des applications publiées et bureaux publiés ne s’affichaient plus.

 

SF3_Error3Sympa les carrés blancs…

 

En regardant les events des StoreFront impactés on a vite trouvé la cause dans l’event ID 2 :

 

Log Name:      Citrix Delivery Services
Source:        Citrix Receiver for Web
Event ID:      2
Task Category: (3003)
Level:         Error
Description:
There was an error during an icon request.
System.UnauthorizedAccessException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b66a5c561874e091
Access to the path ‘C:\inetpub\wwwroot\Citrix\VotreStoreWeb\App_Data\CtxsWebProxyIconCache\L0NpdHJpeC9WRFhBL5Jlc291cmNlcy99Mi9RamxEUVRBeE8UZ3pSVFF9T1RoRFJVVTNOMF


SF3_Error1En modifiant les permissions NTFS le problème subsistait

 

Afin de résoudre ce problème d’affichage nous avons supprimé le contenu du répertoire C:\inetpub\wwwroot\Citrix\VotreStoreWeb\App_Data\CtxsWebProxyIconCache.

 


SF3_Error4On peut retourner à la custo de nos StoreFront (custo qui fera prochainement l’objet d’un billet)

 

Post to Twitter

StoreFront : Impossible de traiter votre demande

Au sein d’une infra comprenant notamment des StoreFront 3.0 (W2K12 US et issus d’une migration StoreFront 2.5 vers 3.0) nos utilisateurs rencontraient l’erreur ci-dessous lors de l’accès à un magasin spécifique.

 

Billet2Dans un prochain billet nous traiterons la modification de ce type de pop-up 🙂

 

En regardant les logs des StoreFront, nous avons constaté un nombre conséquent d’évents Id 17.

Log Name:      Citrix Delivery Services
Source:        Citrix Receiver for Web
Event ID:      17
Task Category: (3002)
Level:         Error
Description:
Failed to run discovery
Citrix.Web.DeliveryServicesProxy.ConfigLoader.DiscoveryServiceException, ReceiverWebConfigLoader, Version=3.0.0.0, Culture=neutral, PublicKeyToken=null
An error occured while contacting the Discovery Service
at Citrix.Web.DeliveryServicesProxy.ConfigLoader.Discovery.AppendConfigurationFromDiscoveryService(WebReceiverConfigSection section)
at Citrix.Web.DeliveryServicesProxy.ConfigLoader.Discovery.RunDiscovery(WebReceiverConfigSection configSection)
at Citrix.Web.Proxy.Filters.DiscoveryComplete.OnAuthorization(AuthorizationContext filterContext)
System.Net.WebException, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
The underlying connection was closed: An unexpected error occurred on a send.
Url: https://127.0.0.1/Citrix/VotreStore/discovery

 

billet2

 

Le problème ne se présentant que sur un store spécifique nous avons comparé les fichiers web.config (situés dans VotreStoreWEB) entre un magasin sans l’erreur et le magasin présentant l’erreur, il s’avère que le problème se situait au niveau du loopback qui était à on sur le magasin présentant le problème. Une fois le loopback passé à off le magasin était à nouveau disponible.

 

<communication attempts=”2″ timeout=”00:01:00″ loopback=”Off”

 

La CTX133904 (mise à jour le 18/09/2015) traite ce type de problème.

 

Ce billet nous ramène à nos sources 🙂 .

Post to Twitter

StoreFront 3.0 erreur MMC (sous Windows 2008 R2)

Comme vous le savez surement StoreFront 3.0 est disponible depuis le 30 juin 2015.

Lors de nos tests nous avions rencontrés une erreur (ou une feature 🙂 ), en effet sur un serveur 2008 R2 Sp1 Fr, nous avions configuré un magasin Web  (Store) avec “L’expérience Receiver Classique” (vous savez celle avec le fond d’écran vert), lorsque nous avons voulu activer “L’expérience unifiée” sur le magasin en question nous avons rencontré l’erreur ci-dessous.

 

SF3_Error1Ça commence pas bien la 🙂

En regardant du côté des events nous avons trouvé l’erreur ci-dessous.

SF3_Error3

Nom du journal :Citrix Delivery Services
Source :       Citrix Delivery Services Admin
ID de l’événement :1
Catégorie de la tâche :(2850)
Description :
Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. <<<< SiteId -VirtualPath $site.VirtualPath
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.

Citrix.DeliveryServices.PowerShell.Command.RunnerInterfaces.Exceptions.PowerShellExecutionException, Citrix.DeliveryServices.PowerShell.Command.RunnerInterfaces, Version=3.0.0.0, Culture=neutral, PublicKeyToken=e8b77d454fa2a856
Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. <<<< SiteId -VirtualPath $site.VirtualPath
<Data>Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. &lt;&lt;&lt;&lt; SiteId -VirtualPath $site.VirtualPath
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Une erreur s’est produite lors de l’exécution de la commande : ‘Get-DSUnifiedExperienceVirtualPaths’
La propriété « SiteId » est introuvable sur cet objet. Vérifiez qu’elle existe.
Au niveau de C:\Program Files\Citrix\Receiver StoreFront\Management\Cmdlets\StoresModule.psm1 : 3631 Caractère : 69
+         $classicEnabled = Get-DSClassicSiteExperience -SiteId $site. &lt;&lt;&lt;&lt; SiteId -VirtualPath $site.VirtualPath

 

Afin d’éviter cette erreur il faut désactiver l’expérience Receiver Classique 🙁 .

Ce problème n’est pas apparu avec un StoreFront 3.0 sous Windows 2012.

Post to Twitter

StoreFront : exporter les passerelles NetScaler

Un billet post-it en direct de nos vacances 🙂

Si vous souhaitez backuper vos passerelles NetScaler (et pas la même occasion vos STA) sous StoreFront sans passer par une ligne de commande (pas bien 😉 ), alors copiez le ficher web.config situé dans le répertoire “C:\inetpub\wwwroot\Citrix\Roaming vers les serveurs StoreFront où vous souhaitez importer les passerelles Netscaler.

Dans le cas présent il nous fallait dupliquer les passerelles NetScaler sur six StoreFront qui ne sont pas en cluster.

copier2Ca faisait longtemps qu’on avait pas usé du copier/coller

 

 

Post to Twitter

StoreFront 2.6 problème d’authentification

Sur un de nos StoreFront (Windows 2008 R2 SP1 fr – SF 2.60.5031) nous avons rencontré du jour au lendemain un problème d’authentification (le problème était identique en authentification direct sur les SF ou en passant par l’authentification via les Netscaler), les utilisateurs rentraient leurs login/mot de passe et étaient à nouveau re-promptés.

En regardant les events du StoreFront nous avons trouvé l’event ci-dessous :

Nom du journal :Citrix Delivery Services
Source : Citrix Authentication Service
ID de l’événement :3
Catégorie de la tâche :(1005)
Niveau : Erreur
Description :
Échec de AG Web Service sur : https://VotreUrl/CitrixAuthService/AuthService.asmx avec l’erreur suivante. Ce point de terminaison sera ignoré jusqu’à : 07/05/2015 22:05:54
Citrix.DeliveryServices.Authentication.CitrixAGBasic.Exceptions.AGCommunicationException, Citrix.DeliveryServices.Authentication.CitrixAGBasic, Version=2.6.0.0, Culture=neutral, PublicKeyToken=null
Une erreur de communication s’est produite lors de la tentative de contact du service d’authentification NetScaler Gateway sur https://VotreUrl/CitrixAuthService/AuthService.asmx. Vérifiez que le service d’authentification est en cours d’exécution.
à Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.AGClient.GetAccessInfo(String sessionId, String username, String domain)
à Citrix.DeliveryServices.Authentication.CitrixAGBasic.Client.CitrixAGBasicWebService.GetAccessInfo(String sessionId, String username, String domain)

ID3-1005

Via le serveur StoreFront nous avons constaté que l’url “https://VotreUrl” n’était plus résolu correctement (sur les serveurs DNS l’alias pointait sur une ancienne IP).

Si vous avez la main sur les serveurs DNS il vous suffira de mettre à jour l’alias en question. Si vous n’avez pas la main sur les serveurs DNS vous pouvez rajouter dans le fichier Host (situé dans C:\Windows\System32\drivers\etc) du serveur StoreFront une entrée pointant sur votre alias (exemple : 10.10.20.11 votreurl) en attendant la mise à jour des DNS.

 

Post to Twitter

Erreur HTTP : Error 503 sur Web Interface

Suite à une mise à jour sur nos Web Interface (5.4 us /2008 R2 us) de prod (suppression de sites XenApp Web) nous avons rencontré sur deux Web Interface une erreur HTTP 503 (Service Unavailable).


Http503_1

 

Vu que seuls les sites XenApp Web étaient impactés (IIS était ok, la création d’un site et son accès répondait bien), nous avons regardé du coté de IIS, et en cliquant sur l’application Pools (bien sur nous ne sommes pas tombés directement dessus 😉 ), nous avons constaté que “CitrixWebInterface5.4.0AppPool” était arrêté.

 

Http503_2C’est sûr que ça risquait de marcher la

 

Une fois l’application pool “CitrixWebInterface5.4.0AppPool” démarrée, l’erreur HTTP 503  n’apparaissait plus.

Afin de checker les sites XenApp Web de nos différentes Web Interface, nous avons mis en place un script PowerShell permettant de vérifier si les différentes url répondent bien.  Dans un second temps  en parcourant l’outil de supervision (Zabbix) de notre client actuel,  nous avons remarqué que le check d’URL est possible via un scénario web qui lui même va checker les différentes url de nos sites Web Interface (avec un trigger afin de générer une alerte dans Zabbix).

 

Zabbix_WebuiDans notre cas nous avons créé le scénario web dans un template que nous appliquons à nos Web Interface

 

Zabbix01
Une fois l’étape du scénario créée le check d’url est réalisé

 

Zabbix_Webui_XenApp_triggerLe trigger que nous avons associé à notre scénario Web, si le dernier check est différent de 0 (check ok) alors une alerte avec un statut haut remontera dans Zabbix

 

Http503_3
Le résultat de la supervision Web dans Zabbix

 

Concernant le script Powershell, il faut au préalable :

  1. Modifier en ligne 2 du script les Web Interface à checker
  2. Modifier l’url à checker en ligne 7 du script

 

WebiCheckPour la partie PowerShell, si vous avez pas d’outil de surpervision ou autres solution alors à l’ancienne une tache planifiée (en dernier recours)

 

Download_2
Check_Url_Webi.ps1

Post to Twitter

Problème pour forcer l’adresse Ip dans un launch.ica

Toujours dans la série post-it (rentrée des classes oblige), récemment nous avons rencontré un problème pour forcer l’adresse IP serveur dans un launch.ica via une WebInterface 5.4 (2003 sp1 us). 
Dans pareil cas on se tourne rapidement vers le webinterface.conf du site afin de modifier l’addressResolutionType pour forcer le type de résolution (dns-port, dns, ipv4-port, ipv4).

ResolXml03

 

ResolXml01Dans notre cas le WebInterface.conf était configuré pour présenter des adresses dns (configuration par défaut)

 

Pour le coup normal que les launch.ica présentent des adresses dns, cependant une fois le webinterface.conf modifié (addressResolutionType=ipv4-port) afin de présenter des adresses Ip nos launch.ica présentaient toujours des adresses dns.

Après un moumoutage (french expression very famous 🙂 ) de 20 mn, direction les propriétés de la ferme (XenApp 5 R07, 2003 sp1 us) dans la partie XenApp-General la coche XML Service DNS address Resolution était coché .

 

ResolXml02Sous XenApp5 

  

ResolXml05 Sous XenApp 6.5 (dans stratégie ordinateur-Paramètre du serveur)

 

ResolXml04Une fois l’XML service DNS adress resolution décoché nous obtenons bien une adresse en Ip dans le launch.ica 

 

Post to Twitter

Script : Check XML Broker

Comme vous le savez le rôle XML Broker est important au sein d’une ferme XenApp, et à ce titre un check de ce dernier est très fortement recommandé (si vous souhaitez en savoir plus sur les interactions entres une Web-Interface et un XML Broker alors direction la CX122877).

Xml_schema

 Un schéma simplifié d’une architecture XenApp (issus de support.citrix.com)

 

Il existe nativement des solutions permettant de checker les XML Brokers (Netscaler et F5 par exemple), mais si comme nous dans votre infra le matériel acheté et “censé”  faire ce check ne le fait pas et que l’affaire tourne en rond, alors il vous reste la solution scripting (afin de laisser le temps au fameux matériel de pouvoir répondre au besoin 🙂 ).

panneau signalétique rue Marettes

 

Avant de scripter il faut déjà comprendre ce qu’il faut envoyer à l’XML Broker et ce qu’il doit nous répondre, ce type d’infos se trouve dans le pdf “Health Checking Citrix Services with Advanced Monitors from the NetScaler Application Switch ” (dont nous vous recommandons la lecture), en page 12 nous trouvons la requete HTTP à envoyer à l’xml broker ainsi que la réponse si tout est ok

La requête Http (au format xml), avec comme application publiée “Notepad_Netscaler” pour le check  :

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE NFuseProtocol SYSTEM “NFuse.dtd”>
<NFuseProtocol version=”4.1″>
<RequestAddress>
<Flags>no-load-bias</Flags> ###
<Name>
<AppName>Notepad_Netscaler</AppName>
</Name>
</RequestAddress>
</NFuseProtocol>

La réponse de l’XML Broker si tout est ok :

<?xml version=”1.0″ encoding=”UTF-8″ ?>
<!DOCTYPE NFuseProtocol SYSTEM “NFuse.dtd”>
<NFuseProtocol version=”4.1″>
<ResponseAddress>
<ServerAddress addresstype=”dot”>5.214.10.251</ServerAddress>
<ServerType>win32</ServerType>
<ConnectionType>tcp</ConnectionType>
<ClientType>ica30</ClientType>
<TicketTag>IMAHostId:13093</TicketTag>
<FarmLoadHint>0</FarmLoadHint>
</ResponseAddress>
</NFuseProtocol>

Comme indiqué en page 13 du pdf, ce qui nous intéresse dans la réponse de l’XML Broker est la partie <TicketTag>, donc si tout va bien on obtient un TicketTag, inversement si la requête échoue nous n’avons pas de TicketTag dans la réponse.

Xml_Error1Exemple de réponse sans TicketTag (pour le test nous avions désactiver l’application Notepad_Netscaler)

 

Afin que le check passe bien il faut s’assurer que (toujours page 12 du pdf) :

  • L’IMA est bien fonctionnel sur l’XML Broker checker
  • La LHC de l’XML Broker est valide
  • L’IMA est fonctionnel sur le ZDC
  • La base de donnée dynamique du ZDC est valide
  • Avoir un serveur XenApp disponible pour l’application publiée (dans notre cas “notepad”)
  • Le service XML de l’XML Broker fonctionne correctement

Concernant le script nous nous sommes inspirés des scripts trouvés sur http://stackoverflow.com (Powershell API Post Variable to Ducksboard et powershell http post REST API basic authentication).

Au passage nous avons rajouté un envoi de mail en cas d’échec sur un XML Broker (à terme nous enverrons une trape snmp). 

Dans notre production nous avons mis en place le script Check_Xml.ps1 en tache planifiée (toutes les 5 mn 7/24).

Xml_scriptSi vous recevez ce type de mail…. rien ne va plus (mais au moins vous êtes au courant 😉 )

 

 

Download_2Check_Xml.ps1

Post to Twitter