Citrix XenApp 6.5 printer redirection - strange behavior
Hi,
We're having a weird problem in our XenApp 6.5 Server desktop environment when users are coming back in via the NetScaler Access Gateway. We’re using Web Interface 5.4.2.59
In our environment, we have Citrix policies configured to automatically create client printers for users accessing XenApp through the Netscaler Access Gateway.
When the client printer is created, the resultant permissions normally mean that only that one user can print to it. E.g. if Jane and Joe log onto the same XenApp server, and Jane has a autocreated printer called Laserjet 4000, Joe cannot print to Laserjet 4000.
The problem is, we have had three reports (months apart) regarding users printing to client printers that have been created through another user’s session. In one instance someone complained that another user was accidentally sending jobs to the printer in her home. More seriously, we had an incident where an employee was working from a third party’s premises and this resulted in a confidential document printing on an MFD belonging to another organisation.
Administrators can see network printers from other locations but, end users cannot.
The printer policies we have in place are;
Auto Create Client Printers (ICA\Printing\Client Printers) – Auto Create all client printers
Client Printer Redirection (ICA\Printing) – Allowed (We also have a filter in this to only apply to clients with a name of WI_*. This allows us to know when a client is coming in via the Netscaler)
Default Printer (ICA\Printing) – Do not adjust the users default printer
We have seen support article CTX668903 but it does not seem to be relevant.
Can anyone help with this?
Cheers!
Jack
We're having a weird problem in our XenApp 6.5 Server desktop environment when users are coming back in via the NetScaler Access Gateway. We’re using Web Interface 5.4.2.59
In our environment, we have Citrix policies configured to automatically create client printers for users accessing XenApp through the Netscaler Access Gateway.
When the client printer is created, the resultant permissions normally mean that only that one user can print to it. E.g. if Jane and Joe log onto the same XenApp server, and Jane has a autocreated printer called Laserjet 4000, Joe cannot print to Laserjet 4000.
The problem is, we have had three reports (months apart) regarding users printing to client printers that have been created through another user’s session. In one instance someone complained that another user was accidentally sending jobs to the printer in her home. More seriously, we had an incident where an employee was working from a third party’s premises and this resulted in a confidential document printing on an MFD belonging to another organisation.
Administrators can see network printers from other locations but, end users cannot.
The printer policies we have in place are;
Auto Create Client Printers (ICA\Printing\Client Printers) – Auto Create all client printers
Client Printer Redirection (ICA\Printing) – Allowed (We also have a filter in this to only apply to clients with a name of WI_*. This allows us to know when a client is coming in via the Netscaler)
Default Printer (ICA\Printing) – Do not adjust the users default printer
We have seen support article CTX668903 but it does not seem to be relevant.
Can anyone help with this?
Cheers!
Jack
joharder
Both domain admins and local admins have access to all of the printer that are on a server. Thus, if those users were granted local admin access (maybe for an app to work correctly?), those users would see all user printers that are mapped from that server.
ASKER
Hi Joharder,
None of these accounts have ever been any sort of administrator on the session host servers
Cheers,
Jack.
None of these accounts have ever been any sort of administrator on the session host servers
Cheers,
Jack.
Are users connected to a server OS or desktop OS?
We had a similar issue at my last job: users were printing on printers at completely different facilities because old TS ports weren't being cleared out. This was a big concern for our customers because, even though the users all worked for the same company, it was a potential violation of HIPAA regulations that protect patient privacy (most of our customers were long term care facilities). So, my coworker came up with a script that deleted old TS printer ports from the registry. The script would run every night to clear out old printer ports: this resolved the issue & saved us from getting big fines for violating HIPAA.
I don't work at that job anymore so I can't look at the script she was running (I should have saved a copy!), but I think it must have been something like the one listed on BrianMadden.com:
http://www.brianmadden.com/forums/t/15257.aspx
There is a hotfix for this issue for Server 2008. This technet blog post talks about it and recommends running the Inactive TS Port FixIt as a scheduled task on operating systems that aren't supported for the hotfix (Server 2003 & Windows 7):
http://blogs.technet.com/b/askperf/archive/2012/03/06/performance-issues-due-to-inactive-terminal-server-ports.aspx
The details about the 2008 hotfix is on this page. You can also download the FixIt tool here:
http://support.microsoft.com/kb/2655998
We had a similar issue at my last job: users were printing on printers at completely different facilities because old TS ports weren't being cleared out. This was a big concern for our customers because, even though the users all worked for the same company, it was a potential violation of HIPAA regulations that protect patient privacy (most of our customers were long term care facilities). So, my coworker came up with a script that deleted old TS printer ports from the registry. The script would run every night to clear out old printer ports: this resolved the issue & saved us from getting big fines for violating HIPAA.
I don't work at that job anymore so I can't look at the script she was running (I should have saved a copy!), but I think it must have been something like the one listed on BrianMadden.com:
http://www.brianmadden.com/forums/t/15257.aspx
There is a hotfix for this issue for Server 2008. This technet blog post talks about it and recommends running the Inactive TS Port FixIt as a scheduled task on operating systems that aren't supported for the hotfix (Server 2003 & Windows 7):
http://blogs.technet.com/b/askperf/archive/2012/03/06/performance-issues-due-to-inactive-terminal-server-ports.aspx
The details about the 2008 hotfix is on this page. You can also download the FixIt tool here:
http://support.microsoft.com/kb/2655998
Good point, Alicia.
The printers that are running on the server are pulled from this registry key: HKEY_LOCAL_MACHINE\SOFTWAR
If you set up a registry GPP to delete the contents of this key every night, that should resolve your issue.
If it doesn't, that means that the printers were captured into the user profile. That's a bit more complex to address. Please try deleting contents of the reg key shown above first, and if that doesn't fix it, we can walk through some other options.
The printers that are running on the server are pulled from this registry key: HKEY_LOCAL_MACHINE\SOFTWAR
If you set up a registry GPP to delete the contents of this key every night, that should resolve your issue.
If it doesn't, that means that the printers were captured into the user profile. That's a bit more complex to address. Please try deleting contents of the reg key shown above first, and if that doesn't fix it, we can walk through some other options.
I don't think you'd want to delete the contents of that key since that would delete all the printers installed on the server or virtual desktop. You'd probably want to keep some of the printers (for example, if you have a PDF "printer" for creating PDF files). You just want to clear out the orphaned TS printing ports.
I believe the TS Ports in question would show up in this key:
HKEY_LOCAL_MACHINE\SYSTEM\
I believe the TS Ports in question would show up in this key:
HKEY_LOCAL_MACHINE\SYSTEM\
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Figured this out ourselves.