Salut,
Pour ma part, le passage du R04 sur Xen App 4.5 a provoqué un bug côté client. En effet, les postes ayant le client 10 , après avoir fait la combinaison Shift-F2 pour revenir a leur bureau local et reduction du bureau publié, ne peuvent plus revenir sur leur bureau publié . Lorsque qu’ils recliquent sur le bureau publié celui soit n’apparaît pas, soit par petits bouts si on insiste sur le clic, bref invivable. L’ upgrade du client en 11.0 règle le soucis.
Mon souci c’est que n’etant pas dans une architecture full centralisée avec une solution de teledeploiement de logiciels digne de ce nom, j’ai un parc composé de la gamme des client de la version 9.2 à la version 11.0. J’ai vu qu’on pouvait de nouveau (car citrix l’a volontairemnt retirée ???) reconfigurer la web interface pour detecter la version du client existante des postes et proposition de mise a jour mais là mon nouveau problème c’est que j’ai 750 postes wyses avec XP Embedded composé du fameux “WriteFilter” empechant toute modification du poste par l’utilisateur. Donc si ceux-ci se connectent, la web interface détecte le mauvais client, les utilisateurs telechargent et installent le nouveau (après un certain temps car bande passante restreinte) puis après le reboot, on recommence car WriteFilter… 
Quelqu’un aurait-il une idée de comment detecter et proposer la mise a jour du client pour certains postes mais pas pour d’autres ?
je détache ton message, car il mérite un sujet à lui tout seul…
WI est un site web et peut donc etre personalisé en fonction de paramètres que TOUT site web peut récupérer sans nécessiter de plugins ActiveX : OS client, version du browser, IP cliente etc
si tu connais ces valeurs, tu peux jouer avec pour ne lancer l’operation de détection que pour les machines en dehors de ces valeurs