Point-and-Print Restrictions and XenApp

I'm running a provisioned XenApp 6.5 Farm and recently updated the HP Universal Print Driver (UPD) on the Print Server to the newest Version because we needed the support for some newer Printer Models.

But after the HP UPD Update the Users weren't able to map HP Printers (with the updated HP UPD) from the Print Server. They would always receive an "Access Denied" Error when trying to map a Printer.

I hadn't updated my provisioned XenApp Image with the new HP Drivers but wanted to to let the Users install the new Drivers until I could update my XenApp Image. But I had disabled the Point and Print Restrictions via GPO and wondered why Users still couldn't install Print Drivers.

While disabling Point and Print Restrictions alone works perfectly on Windows 7 Systems but for Windows Server 2008 R2 disabling Point and Print alone is not enough. You also have to disable the following Security Policy on your XenApp Servers:

And here is the GPO I'm currently using to allow Users to install Print Drivers on my XenApp Servers. Instead of disabling the Point and Print Restrictions completely you can of course also set it to enabled and adjust it accordingly. You can find more information on TechNet.

DPI Settings in an RDP/ICA Session on Windows Server 2008 R2 andWindows 7

In quite a few XenApp 6/6.5 Projects the Customer complained that the Users were not able to change the DPI Size when connected to a XenDesktop running Windows 7 or a XenApp Desktop hosted on Windows Server 2008 R2. This was due to a limitation in the Remote Desktop Services Stack from Microsoft.

There were some Workarounds with importing/injecting Values into the Registry for those Users to change the DPI Size but they were far from perfect.

Microsoft just recently released an Hotfix to enable the Adjustment of the DPI Size over Remote Desktop Protocol Sessions like RDP and ICA. You can find and download the Hotfix here:

http://support.microsoft.com/kb/2726399/en-us

And this is how the new DPI Menu looks (on a German Windows Server 2008 R2):

Citrix Clipboard Redirection causes Session Disconnect

This week I had to troubleshoot a Problem where a lot of Copy and Pasting in a published Desktop caused the XenApp Session to freeze or disconnect.

The Customer reported a Problem where some of his Users were getting disconnected as soon as they ran a specific Excel Macro. At first I suspected that the Macro used some kind of Screen Refresh or something similar which would cause the ICA/HDX Session to disconnect or frezze but the Macro only involved copy and pasting a lot of information in quick succession. That led me to focus on the Clipboard Redirection because everytime I copied a large amount of Data my Session frozze up.

Solution: We finally fixed the Session Disconnects by disabling the Clipboard Redirection via Citrix Policies because the Customer solely relies on published Desktops and therefore he doesnt need to copy and paste things between the XenApp Systems and the Endpoints.

If you need the Clipboard Redirection to be enabled and want to avoid the Session Disconnects/Freezes you should try the new Citrix Receiver 3.1 Cumulative Update 1 or downgrade to the Online Plug-in 12.x.

Note: This Problem should also apply to XenDesktop as long as you use the Receiver 3.0 or 3.1 which seems to be affected with this "Clipboard Redirection Bug".

Update: This should be fixed in the Receiver 3.2 aka Online Plug-in 13.1.200.x or later.

Why you shouldn't enable RDP via GPO on XenApp/RDS Hosts

I recently had to troubleshoot a Problem where the Customer told me that sometimes all the Sessions on a XenApp 6 Host got disconnected and the Users then had to reconnect to their XenApp Sessions to continue working.

After a little Research (more like googeling) I narrowed it down to the the Group Policy Refresh. Not always, but sometimes, when doing an "gpupdate /force" all User Sessions on the XenApp Host got disconnected. With this in mind I found the following Microsoft Knowledgebase Article: http://support.microsoft.com/kb/2083411

The customer in fact used the Group Policy Option "Allow users to connect remotely using Terminal Services" to enable Remote Desktop and force a specific Remote Desktop Security Setting on all of his XenApp Servers.

After setting the Registry Key "fDenyTSConnection" to 0 (as suggested in the Microsoft KB Article) the sudden disconnects were gone.

Problem solved! :)

PVS and vSphere 5 PXE Reboot Problem

I recently worked in a Project where we deployed XenApp 6.5 Workers via Citrix Provisioning Services 6.0 (PVS) onto a vSphere 5 Cluster and ran into a Problem regarding the PXE Boot. We knew that PVS 6.0 is currently not supported with vSphere 5, but the customer wanted to use his vSphere 5 Cluster nonetheless.

Everytime we rebooted a Target Device, running an XenApp 6.5 Worker, it would reboot and then hang on the PXE Boot like this:

When we powered the VM completely off and then started the VM again (cold reboot) the PXE Boot worked without a Problem. The Problem would only occur when rebooting the VM without completely shutting it down before.

To fix the Problem we had to enabled the "Interrupt safe mode" Option in the Bootsptrap Configuration of the Provisioning Servers:

And voilà: Rebooting the XenApp 6.5 Workers on a vSphere 5 Host/Cluster now works as expected.

UPDATE: Citrix published an official Support Article (with the same Solution) regarding the Bootstrap Configuration in an vSphere 5 Enviroment: http://support.citrix.com/article/CTX131993