• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 3724
  • Last Modified:

XenApp 6 Session Printer creation is SLOW

We just built a new XenApp 6 farm on Win 2008 R2 servers and are getting ready to migrate our users from an old Presentation 4.5 farm.

We have Citrix policies that deliver Session printers.  We have over 230 printers.  For some users, it is necessary to present all of these printers to their session.

On the 4.5 farm we can do this with no problem, the printers are all available within 3 minutes.

On XA6, it takes over 30 minutes until all of the printers have mapped.

We used Citrix Stress test tool for printers, and isolated some drivers that were causing some errors, such as interactive service detection errors, and removed the offending drivers.  We now have less than 10 different drivers in use, most of which are 2008R2 native.  They have also been replicated to all the Citrix servers using start-xaprinterdriverreplication from powershell.

We are using two new 2008R2 print servers for the new farm.

We are also using Citrix profile management 4.0 to do profile streaming.  One thing I have noticed, is that the HKCU\Printers\Connections key in the registry (which stores all of your network printer connections) does not get saved with the users streamed profile.  It gets rebuilt each time they log in by the Citrix Printer Policy.

One other thing of note - I noticed that if I manually install printers on one of the Citrix servers by browsing to the printserver and double clicking on the shared printer, it says "downloading driver" for each printer I install, even if the printer being installed uses a driver that has already been installed.  I compared this to our old 2003 environment, and connecting to a shared printer that uses a driver that is already installed is instantaneous.  

I set a policy via GPO to configure "point and print restrictions" to a bogus print server name (thereby disabling point and print completely), thinking this would help, but it made no difference.

Need to figure out a way to speed this up.  I know 230 printers is alot, but it worked very well in Presentation server 4.5....

Please help!


1 Solution
Check if this helps:


Before that, please check your server is up to date with latest hotfixes. Also for Xenapp 6. There are many hotfixes released to improve the performance. Take a test server, patch it to the latest both windows and Citrix. Even check the optimization pack and see how it goes.
Try disabling streaming profiles.  Streaming profiles is a great idea, but only a small portion is downloaded at session initiation in order to get the user session to start faster.  What your users require in terms of printer drivers may not be part of what is initially downloaded, so it could be that the system waits (and waits and waits) in order to get everything it needs and create those printers.
I've requested that this question be closed as follows:

Accepted answer: 250 points for joharder's comment http:/Q_27323441.html#36714133
Assisted answer: 250 points for basraj's comment http:/Q_27323441.html#36591404

for the following reason:

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

jeeholeAuthor Commented:
The recommended solutions did not help.  I will post a follow up with our solution.
jeeholeAuthor Commented:
Ultimately, we decided to abandon Citrix Policies for printer creation all together.

We created department specific groups to deliver printers, and this made it possible for each user to be assigned 5-15 printers on average, instead of all 230.

We created Group Policies to deploy the printers as "Printer Connections"  (we did not use the new 2008 GPO features for printer preferences due to problems with this method encountered in testing)

This solution worked great in our testing.

HOWEVER, when we went live all hell broke loose.  

During the initial logon crunch in the morning (about 400 users) logon speed ground to a halt, taking almost 30 mins to logon to a single published app in XA6.  We immediately disabled Citrix Streaming Profiles, and this made an instant improvement.  However, printers were still taking a very long time to show up, and in many cases they never showed up at all.

After about two weeks of troubleshooting we finally came up with a solution, although we are still not 100% sure why.  The apparent solution was to disable the Windows Firewall on all 2008 R2 Domain controllers – even though the firewall had all the necessary exceptions.

A little background on this config – all Citrix servers live in a Resource domain in one Forest, and all users are in another domain in a completely separate Forest.  There is a one-way trust in place such that the user domain is trusted by the resource domain.  

In preparation for implementing XA6, one new 2008 R2 Domain Controller was introduced into each domain (mainly to provide a place to create/manage 2008R2 GPO’s).  All other domain controllers are 2003 R2.  The GPO’s that deliver printers are Computer Policies applied in the Resource Domain.  These computer policies use loopback processing to apply to users that are members of a group in the User Domain.  This configuration makes it possible for users to receive the correct printers based on group membership, but only when they logon to the Citrix servers.

The theory is that the Windows Firewall was somehow bottlenecking the cross domain traffic that needs to happen for the GPO’s to apply successfully and present the printers.  Not sure how, because we followed the recommendations in http://support.microsoft.com/kb/179442 to ensure that all the needed exceptions were in place to allow a domain trust.  

Unfortunately, the symptoms only occur under heavy load – so we have not been able to turn the firewall back on and confirm that it causes the problem.  The users have been traumatized enough, so we cannot test during the day.

Hopefully this will help someone else, and I would love to hear if anyone has ever had a similar problem.  

jeeholeAuthor Commented:
Needed total redesign, but ultimate solution of disabling Windows Firewall may have had an impact on original design too
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now