by Jo Harder, CTP, Tampa CUGC Leader, CUGC Women in Tech Founding Mentor

If users only needed to access virtualized applications, desktops, and other resources, implementing Citrix would be relatively easy.  Realistically, users need to print, access USB thumb drives, scan documents, use biometrics and webcams, and so much more.  These peripherals, which fall under HDX, clearly elevate Citrix above its competitors.

Peripherals add significant complexity to any Citrix environment no matter how you slice and dice it.  Even though USB pass-through is enabled by default, there are other factors that determine whether peripherals will function correctly within a Citrix environment.  Below I’ll go through tips and tricks to ensure that your peripherals function correctly.

First, let’s talk about webcams and how to get them to work all the time.  If you use a Microsoft tool called GraphEdit on the endpoint, select video capture sources and WDM streaming capture devices.  Select PIN properties under Capture.  The color space/compression must not be MJPG.  Check the output size.  It must be 352×288 but 320×240 may work as a fallback.  You can tweak the registry to force this.  Lastly, if another app is using the webcam, then it can’t be mapped into the Citrix session.  Sometimes the webcam isn’t released after use.  See also CTX124655 and CTX134772.

Now, let’s talk about printing.  Yes, it’s improved greatly, but the occasional, “I can’t print,” or “It takes forever to print,” can be heard from users.  Aside from the typical recommendations such as upgrading to the latest Receiver version, let’s explore some additional ways to enable printing. 

So far as printing policies, configure them in one place, i.e., Citrix console.  Don’t spread your policies amongst AD policies and policies–unless you love spending extra time troubleshooting.  Enabling users to install printer drivers is a two-edged sword; if UPD doesn’t work, then the user can’t print without the native driver, but if a gazillion native drivers are installed, that can get fairly ugly. 

Session Printers are a great idea, but what if the network printer is on another network?  A great workaround that I’ve used is to implement an AD Group Policy Preference (Registry) to force entries into the user profile.  This works with roaming profiles but has not been tested with other profile types.  One of the great things about using GPPs is that you can use the second tab, Item-Level Tagging, in order to very granularly select applicability.  Do the following:

• Create or edit a Group Policy Object.  Go to User Config–>Preferences–>Window Settings–>Registry and create a new item.
• In the Hive dropdown, select HK_Users.
• Place your mouse in the Key Path entry, and select F3.  That will provide you with a list of variables.  Select %LogonUserSid%.
• Create entries that assign values under \Printers\Connections as shown below.  Don’t enter the GUID printer as this entry gets written automatically at logon.

Scanning, now that’s more fun than one person should legally be allowed.  Scanners must be TWAIN 1.7 compliant, not 1.8, not 2.0.  There’s a tool named Twacker (yes, funny name) that can be downloaded from twain.org.  Install Twacker32, not Twacker64, in your test environment, and access it in a session from a user workstation with the scanner attached.  If scanning works with Twacker, it *should* work with your app.  I say should because that’s true most of the time, not all the time.  If Twacker works, you can be certain that the scanner and driver are compatible.  If the app doesn’t work, then it’s definitely an app issue.  As much as I hate to say this, there’s nothing else you can do but go back to the developer and ask them to update their scanning component. 

USB devices with virtual COM ports can cause some headaches.  And yes, there are still some of these devices around.  Just because it has a USB, don’t make any assumptions.  For these, you must create a login script (forcing a GPP doesn’t work because it maps it too late in the process; been there, done that!) that maps the server COM port to the local device COM port used by that device.  In Device Manager on the local device, verify the local COM port in use.  Assuming that the server COM port is 1 and the local COM port is 9, your login script would look like this:

net use com1 /delete

net use com1: \\client\com9:

Peripherals can indeed be complex and cause headaches.  These are some ideas as to how to address your Peripheral Perplexities.