We have 5 new virtual Remote Desktop Servers that we are in the process of swapping our users over to. Each server is dedicated to our difference buildings. We are running into the problem of printers showing up in the dropdown list that are not installed on the server that is trying to print. It ends up causing an error in CPS of being unable to print. Has anyone run into the issue of printers showing up in the dropdown list that are not even installed on the Remote Desktop Server. How were you able to fix it?
Thanks for any advice,
Gary
You might want to check the EMR.INI file for the line that reads: UseClientName=
Upon installation of the CPS client in an RDS or Citrix environment, the line stating: "UseClientName=" defaults to a value of FALSE, which then allows each ICA connection to overwrite the printers in the printer table for the previous users who logged in with that ICA number from another server...
You probably only need to edit this line in each of your Terminal Servers to read: UseClientName=TRUE
~S
I'll give that a try. We've had to edit that on our old terminal servers to allow Centricity to keep our printer settings. Thanks for the advice.
Gary
If you end up using CLIENTNAME = TRUE you will also need to be aware of some other "fun" behaviors that CPS has in regards to printers.
Lets say that there is 1 or more shared workstations in your buildings, which in all honesty is pretty common.
Doctor A logs onto the computer, into Terminal Services and then into CPS. Doctor A like to print on HP Laserjet 4350, he thus sets his default in printers in CPS to reflect this. After some work he decides to leave for the day and logs out.
now Doctor B is on and needs to work from the same station, so he logs onto the computer, terminal services and then CPS. Doctor B likes to print to Brother HL470DW, but does not change, or set his default printer in Centricity. he also does not have HP Laserjet 4350 installed as an option to print to.
guess what? now centricity is trying to print to HP laserjet 4350 for Doctor B and not to his brother printer.
this is because centricity has a fun little table in the database called printers. It keeps track of CLIENTNAME (in this case the initial computers name) and the "Default printer" that CLIENTNAME likes to print to.
This can cause all kinds of havok, if a person tied to CLIENTNAME does not have the printer installed that CPS thinks is the default they can get hung with an error something like "Invalid TER" and you have to kill their session to get it to go away. Or if they do have the printer installed but think their default is some where else, they will not know where to look for said print job.
printing and CPS is a fun business, if you need any assistance you can email me: [email protected]
good luck!
Correct... but if you're in a Terminal Server environment and you have multiple servers, you CANNOT use 'clientname=false' or every subsequent logon from a different server will overwrite the previous logon's printer settings within the PRINTERS table in CPS if their RDP or TCP client numbers match. So this tends to end up being the lesser of two evils, unfortunately.
sdoesken said:
Correct... but if you're in a Terminal Server environment and you have multiple servers, you CANNOT use 'clientname=false' or every subsequent logon from a different server will overwrite the previous logon's printer settings within the PRINTERS table in CPS if their RDP or TCP client numbers match. So this tends to end up being the lesser of two evils, unfortunately.
Absolutely, in my rant I forgot to mention that. Yes while it is a pain it is still less of a pain then the alternative. with clientname = false we have had providers printing in locations no where near their office. fun times!
joshua.tilson's explanation is the most thorough I've seen on this issue. I submitted an enhancement request to GE on this issue a while back. The relatively simple solution would be for the CPS application to track the clientname AND the username. It will result in a larger table, potentially several rows for each client (one for each user that logs in there), but it would effectively track the printer preferences, rather than the half working, half broken implementation they have now.
-Matt