>I've been tasked with trying to find a printing solution for a VFP application that runs on a terminal server. There are 100's of users and actually like 14 different windows terminal servers. The customer connects to the terminal server and runs the VFP app from there. The problem, of course, is how to deal with local printing. I mentioned that there is a setting in the RDP client to map local printers - but supposedly they tried this before and the problem is that the users can not only see their printers, but everyone else's also.
>
>At the moment they are using this --
>http://www.tricerat.com/support-center/downloads/printing-clients
>
>...which I guess kinda worked - for a while. Now that they've upgraded the servers to Windows 2012 it's apparently created a problem that they can only print to the their default printer, and if you want to switch printers, not only do you have to change your default printer, but actually have to reboot your machine too. Needless to say not an ideal solution - PLUS it requires installing a client on all the user's workstations - and considering the computer-skills (or lack of) with the customers this isn't the most desirable solution either.
>
>Does anyone have any ideas on how we can print locally from a VFP app running in terminal server? At this point I could deal with having to install some client software on the machines if I have too - but I'm really striking out on coming up with a working solution.

Maybe:

https://social.technet.microsoft.com/Forums/en-US/da4bbf89-7dae-4ef0-ad92-977304787666/show-only-one-printer-in-terminal-service-session?forum=winserverTS

i.e. sessions are running with too many privileges (?) If that's your issue some host account/reconfiguration may be required. RDS hosts should be locked down pretty hard. Otherwise maybe:

https://www.bleepingcomputer.com/forums/t/610682/printers-for-all-users-visible-on-remote-desktop-server/

In general remote printing is a PITA. It used to be that you had to install the printer driver for each remote printer on the host for it to work; and in some cases if there was a 32/64 bit mismatch between client and host it still wouldn't work. I understand that with the release of Server 2012 things got a lot better/easier, but still...

If all else fails you could experiment with printing to the local redirected ports. If you run NET USE in an RDP session that has printers redirected you'll see various printers named \\tsclient\SomePrinterName. I don't know if these would include only that session's remote printer(s) or those from all sessions, it may have the same issue as what you're seeing interactively.

I briefly considered writing reports to (say) PDF files on the host and then somehow getting those files to the remote users, but that would be extra complication for no real gain.