Multiple users logged into one server, each users printer has a different name, application needs ONE name to print to.

Question

Multiple users logged into one server, each users printer has a different name, application needs ONE name to print to. 
I'm NOT in any way a Terminal Services expert and I need help trying to get an application program working in a multi-user environment.
The issue is that the printer changes for every user that is logged in. The application needs to print NOT to the default printer, but to a "special" printer which is selected in the application... let's call it a label printer to simplify the explanation.
You have your default regular printer, easy for the application to find that one, and then you have a special printer that labels get printed onto. The application needs to know what printer is the label printer. So we allow the user to select that in the
application and the selection is stored in a config file in 
C:\ProgramData\mfgr\prog\setting files
I don't have access to the application so I can't change how this works.  
In the "regular" world, selecting the label printer driver to use should be per machine, NOT per user. When a new user logs into a machine, the physical printer doesn't go "poof" and a new printer suddenly appear. Same printer for all
users.
Yet in terminal services, the physical machine is "merged" with the virtual machine on the server. And there can be many users logged in at the same time. So each users real machine (and real printer) is injected into the "fake" terminal
services machine. The name of the printers is made unique for each user. So the printers DO go "poof" and change names depending on the user logged into terminal services.
So user "A" logs in and sets up the application to print to "LabelPrinterForUserA" (or whatever the name of the printer happens to be), that setting is stored in the ProgramData subfolder, and all is well. Later, user "B" logs
in, and when they print, the application tries to print to "LabelPrinterForUserA" which doesn't exist for user B or is only accessible by user A. If user B re-configures, that breaks it for user A. 
SOLUTION 1: The way that /should/ work (in my mind) is that you define one "generic" printer in Terminal Services... call it "Virtual Label printer" and when the user wants to print to it, the print job gets re-directed back to whatever
physical printer is actually connected to their local workstation. There is a map of virtual printer to actual printer depending on the current user. The application is told once to print to "Virtual Label Printer" for all users.
SOLUTION 2: Or... there should be some way to make the ProgramData sub folders separate per user. E.g. when user "A" tries to access:
C:\ProgramData\mfgr\prog\setting files
they actually get 
C:\UserData\UserA\AppData\mfgr\prog\setting files
and user "B" gets
C:\UserData\UserB\AppData\mfgr\prog\setting files
So the question I have is: Does either of those solutions exist hidden somewhere in the setup of terminal server? Or is there another way around this issue that I don't know?

Answer 1

I don't really have a "for sure" answer to this, but because people here can't seem to deal with a question that hasn't been answered I'll provide the best answer I did receive from ServerFault.com user Nathan:
I can feel your pain with using old software on terminal servers ...the solution I've come up with definitely won't scale as it requires some manual configuration, but I've gotten this method to work with our label printers (which require to be
printed to an LPT port...yep, that old).
Share your USB-connected printers to the network on each machine. Then, have the user log in on aunique session for each of them
(a TS account cannot be shared among computers for this to work) and install a network printer pointing to the USB one they shared. Try to use a DNS name to account for possible DHCP movements.
After, it should work. Each user can do this since display names can be identical as long as the ports are different (which they are).
This was clarified by the following series of comments:
I think you are on to something here, and I originally advised the admin to do this. The problem he ran into is that it setup the printer names in the TS as "printer on usersworkstation"
and he could not rename it except to change the "printer" to whatever. E.g. the "on userworkstation" remained. I believe there is another way of installing the printer which avoids this, but I can't find it. Ages ago, one used to do NET
USE LPT2 \\computer\printer password /USER:domain\user /PERSISTENT:YES and then tell the driver to print to LPT2 –  James
Newton Mar
17 at 16:21   
@JamesNewton That's actually the exact method we used. The way around the "network printer" part is to install it as local printer and map it to a TCP/IP port that way. –  Nathan
C Mar
17 at 16:28
You mean in the case where the printers are TCP/IP connected and not local USB / LPT to the users workstation? That makes sense. Wonder if this will work for USB connected printers... –  James
NewtonMar
17 at 16:35   
@JamesNewton You'd share the local printer on the client's PC then on the server connect via TCP/IP to it. You'd need static addresses or use DNS names if DHCP, though. –  Nathan
C Mar
17 at 16:51
Ah. Yes. I see. Looks like the LPT thing should work even with a USB connected printer:superuser.com/questions/182655/… –  James
Newton Mar
17 at 17:09