Archives de catégorie : faq

Retour d’expérience sur les adresses ip virtuelles RDS et XenApp 6.0

Bonjour,

Voici donc comme promis le retour d’expérience sur la mise en place des virtual IP avec XenApp 6.0…

Certaines applications nécessitent une IP unique par instance. Dans un environnement XenApp, c’est donc l’IP du serveur qui est retournée lors d’un appel aux APIs Winsock : problématique avec ce genre d’applications!
Les IP virtuelles ont été introduites dans CPS4.0 et Microsoft l’a implémenté dans Windows 2008 R2. Donc, depuis XenApp 6.0, il faut au minimum configurer les IP virtuelles via RDS (GPO etc) et activer les stratégies XenApp idoines si l’on souhaite davantage de fonctionnalités (VIP en loopback etc). Continuer la lecture de Retour d’expérience sur les adresses ip virtuelles RDS et XenApp 6.0

XenApp 6.x : adresses ip virtuelles

Bonjour,

Certaines applications nécessitent une IP unique par instance. Dans un environnement XenApp, c’est donc l’IP du serveur qui est retournée lors d’un appel aux APIs Winsock : problématique avec ce genre d’applications!

Les IP virtuelles ont été introduites dans CPS4.0 et Microsoft l’a implémenté dans Windows 2008 R2. Donc, depuis XenApp 6.0, il faut au minimum configurer les IP virtuelles via RDS (GPO etc) et activer les stratégies XenApp idoines si l’on souhaite davantage de fonctionnalités (VIP en loopback etc).

Jusque là tout va bien. Des essais sur mon environnement de test m’ont montré que cela fonctionne sans accro (attention, dans la GPO RDS il faut bien indiquer le sous-réseau de la NIC qui reçoit les VIP sous la forme 172.16.250.32/24 ou 172.16.250.0/24).

Mais lorsque l’on utilise VMWare vSphere 4, impossible d’avoir des IP virtuelles assignées à la session. La solution semble être la suivante (je n’ai pas encore pu tester, je modifierai ce post une fois le workaround validé).
http://communities.vmware.com/thread/255821?start=15&tstart=0

soluce:
1. add VMXNET3 adapter and remove E1000
2. uninstalling the VMCI driver by modifying the VMware Tools installation
3. disabling IPv6 by unchecking the box in the Local Area Connection properties
4. setting the DisabledComponents DWORD value to 0xFFFFFFFF under HKLMCurrentControlSetservicesTCPIP6Parameters in the registry

j’ai un souci avec cette soluce… c’est le point 3. désactiver IP v6 n’est pas recommandé par Microsoft! voir http://blogs.technet.com/b/netro/archive/2010/11/24/arguments-against-disabling-ipv6.aspx

edit (21/11/11): a priori, seule l’étape 2 est vraiment nécessaire… l’utilisation de la VMXNet3 et la désactivation de l’IPv6 n’ont rien changé..
edit2 (02/12/11): merci Nicolas D. et Nicolas H. pour les efforts ce soir! grâce à toi, Nicolas D. ça va enfin marcher… je mettrai un nouvel article avec la vrai soluce.

ThinIsFat

XenApp 5 FP2 : A quoi sert le fichier XenApp5 FP2 Enabler.msi ?

Bonjour,

Nombreux sont ceux qui, une fois récupéré et installé à la main, XenApp 5.0 Feature Pack 2, se sont demandé à quoi sert le fichier XenApp5_FP2_Enabler.msi présent sur l’ISO…

 

Ce fichier, inclus dans le ZIP Citrix Licensing 11.6.1.zip sur l’ISO de XenApp 5.0 Feature Pack 2, est nécessaire pour permettre d’utiliser certaines fonctionnalités du Feature Pack 2 : Power and Capacity Management Agent et HDX MediaStream for Flash .

Si ce MSI n’est pas installé, les deux applications pré-citées ne s’installeront pas et proposeront tout d’abord l’installation de ce fameux MSI.

Lorsque l’installation de XenApp 5.0 Feature Pack 2 est effectuée via l’autorun, XenApp5_FP2_Enabler.msi est automatiquement lancé.

Il met le serveur XenApp au niveau Feature Pack 2, c’est à dire qu’il change  la burndate de XenApp 5.0 : cela a pour immédiate conséquence de nécessiter que le ou les fichiers de licences possèdent une date de fin de Subscription Advantage postérieure au 18 Septembre 2009.

 ThinIsFat

Les sessions ICA restent actives avec le Citrix Offline Plugin 5.2

Bonjour,

Si vous utilisez le client Citrix Offline Plug-in 5.2 (le nouveau nom du client streaming) sur un serveur XenApp pour accéder à des applications streamées, vous vous rendrez sûrement compte rapidement qu’à la fermeture de session, celle-ci restera active pendant 5 minutes…

En effet, le Citrix Offline Plug-in version 5.2 ajoute une fonctionnalité qui garde la session ICA active pendant 5 minutes afin d’être réutilisée pour améliorer les temps de lancement. Lorsque l’utilisateur ferme l’application « streamée », RadeLauncher.exe restera actif pendant 5 minutes, gardant la session ICA ouverte.

Cette durée peut être modifiée dans le registre et en son absence, la durée est donc de 5 minutes. Mettre la valeur à 0 (zéro) désactive cette fonctionnalité.

Pour Windows 32-bit :

HKLMSoftwareCitrixRade

Nom : SandboxStatusMonitorPeriod

Type: REG_DWORD

Données: Nombre entier (non négatif) qui correspond au nombre de minutes

Pour Windows 64-bit :

HKLMSoftwareWow6432NodeCitrixRade

Nom : SandboxStatusMonitorPeriod

Type: REG_DWORD

Données: Nombre entier (non négatif) qui correspond au nombre de minutes

ThinIsFat

Gestion des licences : articles intéressants de la KB Citrix

Bonjour,

Pour tous ceux concernés par la gestion des licences pour les produits Citrix, vous avez sûrement des questions, des points à éclaircir, des procédures pas toujours maitrisées.

Pour vous aider, voici quelques liens vers des articles de la KB Citrix qui pourront vous aider dans vos recherches :

CTX118202     How To…Online Fulfillment in MyCitrix

CTX118203    How To…Resolve a red alert on the License Management Console?

CTX118324    How To…Return/Re-Host a license via MyCitrix?

CTX118362    License file not recognized by License Management Console/License Server

CTX118564    How To…Retrieve Internal Use and Not-For-Resale licenses?

CTX118633    How To…Check and upgrade the License Server Version?

CTX118634    How To…Download all licenses combined in one single license file and install it accordingly?

CTX118787    How To…Assign a Citrix Solution Advisor in My Citrix?

CTX118788    XenServer licenses in My Citrix

CTX119354    My Citrix Error: There are no items to fulfill

CTX120192    XenApp ENT licensing with AppStreaming feature

CTX120102    How to check current status of Subscription Advantage using My Citrix

CTX120143    How to look/assign a Citrix Solution Advisor using My Citrix

CTX120355    How to add/update a contact in My Citrix

CTX120469    How to activate NetScaler NFR license

CTX120645    My Citrix Error « Invalid Host » when allocting XenApp Platinum

CTX121184    Repeater unit rejects license even license is correct

En espérant que cela vous sera utile, un jour ou l’autre !

ThinIsFat

XA 5.0 : Supprimer l’écran de logoff à la fermeture de session

Bonjour,

Sous XenApp 5.0 (j’entends par là, la version pour Windows 2008), lorsqu’un utilisateur ferme sa session ICA, l’écran de fermeture de session est affiché pendant quelques secondes. Pour l’explication du phénomène et le contournement, suivez-moi…

Suite au changement d’architecture de WinLongon et de LogonUI dans Windows 2008, la clef de registre « DisableStatusMessage » n’est plus disponible. Avec les versions précédentes de Windows, il était possible de désactiver l’écran de logoff en mettant la clef « DisableStatusMessage » à 1 à l’endroit suivant :

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionpoliciessystem. 

Cette clef (et son fonctionnement) est décrite en partie dans les articles http://support.citrix.com/article/CTX108298 et http://support.citrix.com/article/ctx104893.

Sous Windows 2008, cela n’est donc plus possible et le seul moyen de ne plus afficher cet écran de fermeture de session avec les applications publiées en seamless est de mettre en place la commande suivante dans un script de logoff :

tsdiscon %SESSIONNAME%

Ainsi, la session sera déconnectée (disconnect) au moment de la fermeture de session (logoff) et empêchera ainsi l’affichage de l’écran de fermeture de session. La procédure de logoff sera malgré tout poursuivie et la session fermée correctement.

Source : http://support.microsoft.com/kb/972386

ThinIsFat

 

WI 5.1.1 : la configuration centralisée n’est plus disponible, comment faire ?

Bonjour,

Depuis la version 5.0.1 de Web Interface, la configuration centralisée a été « dépréciée » pour être totalement supprimée dans la 5.1.1. Pour remplacer cela, il est possible d’indiquer le rôle de « Master » à un site qui partagera sa configuration…

De cette façon, les autres sites peuvent être configurés afin d’utiliser la configuration du Master au lieu d’un fichier local.

Concept :

Pour les sites IIS (et uniquement IIS), une fois que les permissions du fichier sont correctement configurées, il est possible d’autoriser d’autres sites à utiliser la configuration du Master en indiquant un chemin absolu vers l’emplacement du webinterface.conf sur le Master, dans le fichier bootstrap.conf du site local.

Dans le cas d’un site PNAgent (XenApp Services), Web Interface tentera de lire le fichier config.xml depuis le même emplacement que celui spécifié pour webinterface.conf dans le bootstrap.conf.

Une fois le bootstrap.conf modifié, il ne sera plus possible de gérer la configuration de ce site Web Interface directement. Il faudra modifier la configuration dans le fichier webinterface.conf sur le Master ou via la console d’administration.

Note: la configuration partagée n’est PAS disponible pour les sites Web Interface hébergés sur d’autres plateformes que IIS.

Mise en place :

1. Configurer les permissions pour accéder, via le réseau, au répertoire conf (typiquement C:inetpubwwwrootCitrixSiteNameconf) du site Master et du fichier de configuration

(WebInterface.conf), qui est par défaut dans ce répertoire conf. Pour les sites Master XenApp Services (PNAgent), les mêmes permissions doivent être définies pour le fichier de configuration (config.xml).

2. Ouvrir le fichier bootstrap.conf (par défaut dans le répertoire conf) du site « client ».

3. Modifier le paramètre ConfigurationLocation pour indiquer le chemin réseau complet du fichier de configuration du Master. Par exemple :

ConfigurationLocation=ServerNameShareNameWebInterface.conf

4. Redémarrer IIS sur le serveur « client »

ThinIsFat

WinXP Pro (et plus récent..) : connexion en bureau à distance impossible

Bonjour,

Je sais, rien à voir avec Citrix mais j’ai assez galéré sur le problème pour partager la solution… En clair, impossible de prendre le contrôle en RDP d’un WinXP, Vista, Win2003 etc..

Le journal d’événements se remplit de messages absconds à la vitesse grand V :

Event Type:   Information

Event Source: Application Popup

Event Category:      None

Event ID:     26

Date:         9/25/2007

Time:         12:13:57 PM

User:         N/A

Computer:     ServerX

Description:

Application popup:  : SystemRootSystem32RDPDD.dll failed to load

Bizarre… surtout que du côté client RDP, la seule « information » est l’absence totale de réaction de celui-ci lorsque l’on clique sur Connect… pas de message d’erreur, rien !

Apres de longues (et vaines) recherches, une plongée dans le registre (Winstation…), la désactivation de cartes réseaux (oui, la machine WinXP en a plusieurs), dans les stratégies de sécurité… Google vient alors à mon aide et en fait, il semble que ce soit un bug avec les pilotes NVidia de version supérieur à 169.21.

En clair, jusqu’à la version 169.21 (incluse), cela fonctionne et ensuite.. cela ne fonctionne plus ! preuve ? les forums nvidia : http://forums.nvidia.com/index.php?showtopic=67147&hl=remote%20desktop&st=68 et leur « KB »

Certain forums indiquent que l’ajout de la clef HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory ManagementSessionImageSize en dword 0x20 corrige le problème, d’autres que cela n’a rien changé..

Dans mon cas, la clef SessionImageSize corrige bien le souci.

Quand on y réfléchi en tant que familier de XenApp, CPS etc, cette clef a énorménement d’importance en environnement RDP ou ICA : en effet, Windows force chaque pilote d’affichage de se charger à une adresse virtuelle unique dans l’espace d’adresses allouée par la WinStation pour l’ensemble des sessions (dans le cas présent, la WinStation étant RDP). Avec des pilotes d’affichage complexes (le cas d’une GeForce 8xxx dans mon cas…), le paramétrage par défaut de 8 Mb (0x8 en hexa) est trop faible pour accomoder le pilote d’affichage nvidia ET le pilote RDP, rdpdd.dll (voire le pilote ICA, vdtw30.dll, dans le cas d’un serveur XenApp).

Attention, certains utilisateurs ont fait savoir que la clef à 0x20 n’était pas suffisante, et qu’il a fallu monter jusqu’à 0x80 !!

Bon courage !

ThinIsFat

 

Installer Windows 7 dans une VM XenServer

Bonjour,

Avec la sortie de la beta « publique » de Windows 7, le meilleur moyen de le tester est d’utiliser une VM. Malheuresement, XenServer 5.0 est sorti bien avant que cette beta ne soit disponible… Comment faire ? Voici la réponse…

 

Le moyen facile :

Utiliser le template expérimental XenServer pour Windows 7, disponible ici

Une fois téléchargé et dézippé, il faut, dans le XenCenter, importer ce template. Il n’y a qu’à suivre les captures d’écran ci-dessous…

1. Faire un clic droit sur le pool de serveurs Xen et choisir Import VM…

{rokbox title=|Citrix :: Citrix| size=|365 407|}images/stories/importxen1.jpg{/rokbox}

2. Suivre les étapes de l’assistant, d’abord sélectionner Exported Template et pointer vers l’emplacement où le ZIP a été extrait

3. Sélectionner le pool de serveurs où copier le template

4. Valider l’emplacement de stockage :

5. Sélectionner le ou les carte(s) réseau(x). Par défaut, aucune carte n’est incluse dans le template :

6. Enfin, cliquer sur le bouton Finish pour importer le template :

 

L’ajout d’une VM pour Windows 7 est alors très simple, il suffit de faire un clic droit sur le template nouvellement importé et de choisir New VM…

 

La méthode « Hard » :

Créer une nouvelle VM à l’aide du template Windows 2008 existant de façon classique. Désactiver l’option « Start VM Automatically ». Garder en mémoire le nom de la VM, il sera nécessaire.

Un peu de manipulations dans le CLI de XenServer :

au prompt, taper xe vm-list name-label=. S’affiche alors des informations sur cette VM et son ID unique (UUID).

taper xe vm-param-set uuid= platform:viridian=false

Maintenant, il suffit de démarrer la VM dans le XenCenter et d’installer Windows 7 !

ThinIsFat

Récupérer certains paramètres Citrix pour BGINFO

Bonjour,

Comme demandé par certaines personnes, voici quelques « astuces » simples pour récupérer certaines données sur la ferme CPS/XenApp à des fins d’utilisations dans bginfo

BGINFO, vous connaissez? Non? dommage… c’est un petit outil très pratique pour générer des fonds d’écran dynamiques permettant d’avoir de nombreuses informations sur la machine. Il est téléchargeable sur http://technet.microsoft.com/en-us/sysinternals/bb897557.aspx. C’est un outil SysInternals, ce qui donne déjà une idée sur sa qualité !

exemple de fond d’écran (source TechNet Windows SysInternals) :

Mais comment récupérer des informations pour afficher quelque chose de ce gout là :

Il suffit, lors de la création du fond d’écran dans BGINFO d’ajouter des éléments manuellement. Par défaut, seules certaines informations sont disponible (DNS, DHCP, Domaine, System Type etc) comme vu sur la première image. Pour ajouter un champ personnalisé, il faut cliquer sur Custom :

La fenêtre suivante liste les champs personalisés déjà définis :

Il faut donc cliquer sur New et configurer comme voulu pour récupérer l’information désirée :

J’imagine maintenant avec les manipulations décrites que vous souhaitez surtout connaître les différents endroits où récupérer les informations ? Pourtant c’est sympa de chercher plutôt que simplement lire non ?

Liste des éléments facilement récupérables :

Nom de la Ferme : HKEY_LOCAL_MACHINESOFTWARECitrixIMANeighborhood

Type de DataStore : HKEY_LOCAL_MACHINESOFTWARECitrixIMADatabaseDriver

Nom de CPS : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixProductName

Version de CPS : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixNewProductVersion

Edition de CPS : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixProductFeature

ID Session : variable d’environnement %SessionName%

Mais BGINFO supporte l’utilisation de scripts VBS et des reqêtes WMI. Dans l’exemple que j’ai donné, j’utilise MFCOM (via VBS uniquement, BGINFO ne supporte pas WSF) pour récupérer la liste des hotfix installés ainsi que le nom de la zone et si c’est un DataCollector :

Script pour les hotfix:

set oShell = CreateObject( « WScript.Shell » )

computername=oShell.ExpandEnvironmentStrings(« %ComputerName% »)

Set theServer = CreateObject(« MetaFrameCOM.MetaFrameServer »)

theServer.Initialize 6,computername

nHotfixes = theServer.WinServerObject2.HotfixCount

aHotfixes = theServer.WinServerObject2.Hotfixes

dim Hotfix(60), HRP(60)

For iCount = 0 To (nHotfixes – 1)

Set aHotfix = aHotfixes(iCount)

Hotfix(iCount)=aHotfix.Name

if right(hotfix(iCount),3)= »R03″ or right(hotfix(iCount),3)= »R01″ or right(hotfix(iCount),3)= »R02″ or right(hotfix(iCount),3)= »R04″ or right(hotfix(iCount),3)= »R05″ or right(hotfix(iCount),3)= »R06″ then HRP(iCount)=right(aHotfix.Name,2)

Next

First = LBound(HRP)

Last = UBound(HRP)

MaxIndex = First

ArrayMax = HRP(MaxIndex)

For Index = First + 1 To Last

If ArrayMax < HRP(Index) Then

MaxIndex = Index

ArrayMax = HRP(MaxIndex)

End If

Next

For iCount=0 To (nHotfixes-1)

If Instr(Hotfix(iCount), « R » & ArrayMax)>0 then HFDisplay=HFDisplay &  »  » & Hotfix(iCount)

Next

echo HFDisplay

Script pour l’information sur la Zone et le port XML :

set oShell = CreateObject( « WScript.Shell » )

computername=oShell.ExpandEnvironmentStrings(« %ComputerName% »)

Set theServer = CreateObject(« MetaFrameCOM.MetaFrameServer »)

theServer.Initialize 6,computername

XMLPort=theServer.WinServerObject.XMLPortNumber

if theServer.ZoneRanking=1 then

Zone= »Data Collector for zone  » & theServer.ZoneName

else

Set theZone = CreateObject(« MetaFrameCOM.MetaFrameZone »)

theZone.Initialize theServer.ZoneName

Zone= »Member of zone  » & theServer.ZoneName &  » (ZDC:  » & theZone.DataCollector & « ) »

end if

if XMLPort0 then

XML= »XML Port :  » & XMLPort

else

XML= »XML port shared with IIS »

end if

echo Zone & VbCrLf & XML

En espérant que cela vous plaise à tous..

ThinIsFat

Bonjour,

Comme demandé par certaines personnes, voici quelques « astuces » simples pour récupérer certaines données sur la ferme CPS/XenApp à des fins d’utilisations dans bginfo

BGINFO, vous connaissez? Non? dommage… c’est un petit outil très pratique pour générer des fonds d’écran dynamiques permettant d’avoir de nombreuses informations sur la machine. Il est téléchargeable sur http://technet.microsoft.com/en-us/sysinternals/bb897557.aspx. C’est un outil SysInternals, ce qui donne déjà une idée sur sa qualité !

exemple de fond d’écran (source TechNet Windows SysInternals) :

Mais comment récupérer des informations pour afficher quelque chose de ce gout là :

Il suffit, lors de la création du fond d’écran dans BGINFO d’ajouter des éléments manuellement. Par défaut, seules certaines informations sont disponible (DNS, DHCP, Domaine, System Type etc) comme vu sur la première image. Pour ajouter un champ personnalisé, il faut cliquer sur Custom :

La fenêtre suivante liste les champs personalisés déjà définis :

Il faut donc cliquer sur New et configurer comme voulu pour récupérer l’information désirée :

J’imagine maintenant avec les manipulations décrites que vous souhaitez surtout connaître les différents endroits où récupérer les informations ? Pourtant c’est sympa de chercher plutôt que simplement lire non ?

Liste des éléments facilement récupérables :

Nom de la Ferme : HKEY_LOCAL_MACHINESOFTWARECitrixIMANeighborhood

Type de DataStore : HKEY_LOCAL_MACHINESOFTWARECitrixIMADatabaseDriver

Nom de CPS : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixProductName

Version de CPS : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixNewProductVersion

Edition de CPS : HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlCitrixProductFeature

ID Session : variable d’environnement %SessionName%

Mais BGINFO supporte l’utilisation de scripts VBS et des reqêtes WMI. Dans l’exemple que j’ai donné, j’utilise MFCOM (via VBS uniquement, BGINFO ne supporte pas WSF) pour récupérer la liste des hotfix installés ainsi que le nom de la zone et si c’est un DataCollector :

Script pour les hotfix:

set oShell = CreateObject( « WScript.Shell » )

computername=oShell.ExpandEnvironmentStrings(« %ComputerName% »)

Set theServer = CreateObject(« MetaFrameCOM.MetaFrameServer »)

theServer.Initialize 6,computername

nHotfixes = theServer.WinServerObject2.HotfixCount

aHotfixes = theServer.WinServerObject2.Hotfixes

dim Hotfix(60), HRP(60)

For iCount = 0 To (nHotfixes – 1)

Set aHotfix = aHotfixes(iCount)

Hotfix(iCount)=aHotfix.Name

if right(hotfix(iCount),3)= »R03″ or right(hotfix(iCount),3)= »R01″ or right(hotfix(iCount),3)= »R02″ or right(hotfix(iCount),3)= »R04″ or right(hotfix(iCount),3)= »R05″ or right(hotfix(iCount),3)= »R06″ then HRP(iCount)=right(aHotfix.Name,2)

Next

First = LBound(HRP)

Last = UBound(HRP)

MaxIndex = First

ArrayMax = HRP(MaxIndex)

For Index = First + 1 To Last

If ArrayMax < HRP(Index) Then

MaxIndex = Index

ArrayMax = HRP(MaxIndex)

End If

Next

For iCount=0 To (nHotfixes-1)

If Instr(Hotfix(iCount), « R » & ArrayMax)>0 then HFDisplay=HFDisplay &  »  » & Hotfix(iCount)

Next

echo HFDisplay

Script pour l’information sur la Zone et le port XML :

set oShell = CreateObject( « WScript.Shell » )

computername=oShell.ExpandEnvironmentStrings(« %ComputerName% »)

Set theServer = CreateObject(« MetaFrameCOM.MetaFrameServer »)

theServer.Initialize 6,computername

XMLPort=theServer.WinServerObject.XMLPortNumber

if theServer.ZoneRanking=1 then

Zone= »Data Collector for zone  » & theServer.ZoneName

else

Set theZone = CreateObject(« MetaFrameCOM.MetaFrameZone »)

theZone.Initialize theServer.ZoneName

Zone= »Member of zone  » & theServer.ZoneName &  » (ZDC:  » & theZone.DataCollector & « ) »

end if

if XMLPort0 then

XML= »XML Port :  » & XMLPort

else

XML= »XML port shared with IIS »

end if

echo Zone & VbCrLf & XML

En espérant que cela vous plaise à tous..

ThinIsFat