Bonjour,
Je souhaiterais faire un UP de ce post.
Je suis actuellement en train d’essayer de faire fonctionner l’application CPAGE VITALE via TSE. Celle-ci fonctionne avec un lecteur de carte (GEMPLUS TWIN USB) via le port USB. J’ai récupéré la version 4.03 BETA de l’application CPAGE VITALE qui est fonctionnel sur poste XP.
Les Serveurs sont des OS 2003 SP2 32Bit.
Afin de réaliser l’installation, je me connecte à un serveur TS en mode console (session 0) et réalise l’installation en mode install (change user /install).
Lorsque je souhaite ensuite exécuter l’application, j’ai deux comportements différents:
- En étant en mode install: l’application s’exécute bien.
- En étant en mode execute: l’application plante.
J’avoue ne jamais avoir rencontré ce genre de “bizarrerie”.
C’est pourquoi je sollicite votre aide.
En vous remerciant par avance.
Cordialy.
PS: si vous avez besoin de plus d’info, n’hésité pas 
merci de nous indiquer la version exacte de XenApp (hotfix, rollup pack) et du client ICA.
concernant ton souci en console, process monitor pourra t’indiquer d’où vient le souci. en effet, le mode /isntall et le mode /execute ont des comportements différents :
CHANGE USER – Additional Notes:
Use change user /install before installing an application to create .ini files for the application in the Terminal Server system directory. These files are used as master copies for the user-specific .ini files. After installing the application, use change user /execute to revert to normal .ini file mapping.
The first time you run the application, the application looks in the home directory for its .ini files. If the .ini files are not found in the home directory, but are found in the Terminal Server system directory, the Terminal Server copies the .ini files to the home directory. This ensures that each user has a unique copy of the application’s .ini files. Any new .ini files are created in the home directory. Each user should have a unique (user-specific) copy of the .ini files for an application to avoid instances where several users have incompatible application setups; for example, different default directories or screen resolutions.
When the system is put into install mode (change user /install), several things happen. All Registry entries that are created are shadowed under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerInstall.
Keys added to HKEY_CURRENT_USER are copied under the Software key and keys added to HKEY_LOCAL_MACHINE are copied under MACHINE. If the application queries the Windows directory (using system calls like GetWindowsDirectory), the Terminal Server returns the %systemroot% directory. If any .ini file entries are added (using system calls such as WritePrivateProfileString), they are added to the .ini files under the %systemroot% directory.
When the system is put back in execution mode (change user /execute),and the application tries to read a Registry entry under HKEY_CURRENT_USER that doesn’t exist, the Terminal Server checks to see if a copy of the key exists under the TerminalServerInstall section of the Registry. If it does, the keys are copied to the appropriate location under HKEY_CURRENT_USER. If the application tries to read from an .ini file that doesn’t exist, the Terminal Server looks for that .ini file under the system root. If the .ini file is in the system root, it is copied to the home directoryWindows. If the application queries the Windows directory, the Terminal Server returns the home directoryWindows.
When you log on, the Terminal Server checks to see if the system .ini files are newer than the .ini files on your computer. If the system version is newer, your .ini file is replaced with the newer version or the new entries in the system version are merged into your .ini file. This depends on whether or not the INISYNC bit, 0x40, is set for this .ini file. See the Advanced Installation Topics section of the on-line help for additional information. Your previous version of the .ini file is renamed to Inifile.ctx. If the system Registry values under Install are newer than your version under HKEY_CURRENT_USER, then your version of the keys is deleted and replaced with the new keys from under Install.
En lisant ce post j’ai l’impression qu’il s’agit d’un environnement uniquement TSE pas Citrix.
Pour autant que je sache, les périphériques USB autres que les claviers et les souris ne sont pas supportés sous TSE et sous Citrix. Quoique pour Citrix j’avais entendu dire qu’un développement spécifique avait été fait pour la France pour supporter les lecteurs de carte Vitale.
Mais bon ca doit pas être si simple puisqu’au CHU de Strasbourg par exemple, tous les postes sont équipés de lecteur de cartes de professionnel de santé (c’est la carte que votre médecin insère avant que vous ne mettiez votre carte Vitale au moment du paiement), et ces lecteurs ne fonctionnent que sur des ports COM, car ce sont les seuls à pouvoir être mappés sous Citrix.
Enfin pour TSE, à mon avis c’est peine perdue.
Effectivement, mon environnement est purement TSE.
Concernant le mappage du lecteur de carte à puce, j’ai utilisé l"outils SIMSPY2 qui permet de “vérifier” que le lecteur de carte est bien remonté dans la session.
J’ai pu en faire le test … cela a été concluant.
Je vais voir à faire du process monitor pour checker les différences entre le lancement en mode /install et /execute.
Si jamais d’autres personnes ont des idées par rapport à cette problématique… je suis preneur.
Merci d’avance
je confirme, comme pour le post d’origine duquel j’ai coupé ce sujet, que l’utilisation des cartes Vitale est supportée depuis MF1.8a. A l’époque, en port COM uniquement.
depuis MFXP sous Win2K3, la carte vitale doit fonctionner également via port USB.
si ton environnement est uniquement TSE, je vais déplacer le sujet
Oui, l’environnement est uniquement TSE.
Désolé d’avoir pas poster au bon endroit.
Salut,
a quel moment l’appli plante t elle?
quand tu la lances? ou quand tu lis une carte?
de mémoire cette appli génère un fichier temp, et si tu n’as pas les droits d’écriture elle fait n’importe quoi.
