Did you take a look in the registry for the key that points to sigplus.ini? I bet there is an entry that tells it to look in the windows directory. They changing that key - %username% will work in the registry.
Main Topics
Browse All TopicsI am in the process of rolling out Thin Clients that will be connecting to a Citrix Server running on Windows Server 2003. The core application that the Thin Client users will be accessing on the Citrix Servers is a product called Symitar. Symitar is a banking application. The Thin Clients are XP Embedded and have Topaz USB Signature Pads attached to them. The Signature pads are used when transactions are completed. USB Sig Pads are not natively supported in Windows Server 2003 Terminal Services and Citrix Presentation Server 4.5 However, Topaz has created a program that runs on the server that will allow the information form the Sig pad to be transferred to the Terminal Server Session. This works great with the testing application that Topaz supplies for testing the Sig pad functionality. The testing application uses an ini file that is stored in the users profile\windows directory (sigplus.ini). This file is unique to each user, thus creating a separate sigsock session for the signature pad information to be transferred to user's terminal server session. This works very well!
Here is the issue: The core application that we need to use the Signature Pads with also uses the Sigplus.ini file. However, the application will only look in c:\windows\ for the Sigplus.ini. This is an issue because this sigplus.ini file needs to be unique and is not. Because of this, the core application used the same same file for everyone and the signature pads to not work.
The vendor will not change the location where program accesses the sigplus.ini.
I have tried using a variable (%username%) in the ini file, but the program does not treat %username% as a variable.
Any thoughts would be greatly appreciated!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
That seems to be a programming error that needs to be corrected by the vendor. They do not seem to be using the GetWindowsDirectory API to retrieve the Windows directory, which would return the path to the ini file in the user's home folder (as it happens in the testing application).
Details are here, maybe you can convince them to change their program:
Terminal Server application integration information
http://support.microsoft.c
GetWindowsDirectory Function
http://msdn.microsoft.com/
Program compatibility flags
http://technet.microsoft.c
Business Accounts
Answer for Membership
by: DLWoodiePosted on 2009-11-02 at 07:48:33ID: 25720418
This is just an daft idea and completely untested......
how about replacing the c:\windows\sigplus.ini with a shortcut called sigplus.ini, point the shortcut to the SigPlus.ini file the the %UserName% location or home folder etc.
The system will obviously remane your sigplus.ini file with a lnk file extension but by calling it sigplus.ini.lnk this may be enough to fool the system.