Jump to content


Photo

Intermittent printer delivery failures with GPP

Started by Matt Heckman , 03 October 2013 - 07:22 PM
7 replies to this topic

Matt Heckman Members

Matt Heckman
  • 4 posts

Posted 03 October 2013 - 07:22 PM

We have a new XenDesktop 7 implementation that is delivering Windows 7 virtual desktops on ESXi 5.1. The virtual desktops are streamed with PVS 7, and users receive a random virtual desktop on each login. We're using UPM to persist user customizations. Prior to VDI, we had been using group policy preferences to deploy printers to physical machines. We've continued using that method with our virtual desktops.

We've been seeing intermittent printer delivery failures on our virtual desktops. It's not always the same printer that fails. When a failure occurs, the GPP trace shows an error similar to the following:

EVENT : The user 'RHS-LRCLAB-HP4250' preference item in the 'Common RHS User Policy {05FED79A-FD4C-4E68-A621-269F79879A9A}' Group Policy object did not apply because it failed with error code '0x80070bc4 No printers were found.'%100790273

As the problem is intermittent, I can only duplicate it somewhat reliably. If I repeatedly log onto new virtual desktops, eventually (within 10 attempts) the problem will occur. I've examined event logs when the problem occurs, but I have not found any consistent difference between the event logs on a failed virtual desktop and a successful virtual desktop.

I've wondered if the problem is somehow related to UPM. I did a series of test logins where I deleted the UPM profile for the user between each login. After 30 logins, the problem still had not occurred. I plan on doing another series of test logins later today.

Has anybody else encountered this problem? What other troubleshooting steps might I take to narrow down the cause?



RODRIGO MENEZES Members

RODRIGO MENEZES
  • 2 posts

Posted 14 October 2013 - 11:29 PM

Did you ever find a solution to this? We are having the same problem at the moment and it's preventing us from doing a full company roll out.



Matt Heckman Members

Matt Heckman
  • 4 posts

Posted 14 October 2013 - 11:40 PM

No, the problem hasn't been resolved yet. I don't understand why, but the only change that has seemed to make a consistent difference is to disable profile management.

I have a case open with Citrix support, and they're examining the logs that have been collected. I'll update this thread when I find out more.



RODRIGO MENEZES Members

RODRIGO MENEZES
  • 2 posts

Posted 17 October 2013 - 08:29 PM

I have found a workaround for this. I'm not sure which of these steps actually solved the problem but after doing this the problem has gone away.

- Rolled out a new Windows 2008 R2 - Print Server.
- Added the drivers for each of the printers straight from the manufacturer. ( No HP universal driver )
- Added the printers making sure the newly created share names had no spaces.
- Installed the drivers on the VDI images.
- Deployed the printers through GPP.

Edited by: rmenezes on Oct 17, 2013 4:29 PM



William Fulmer Members

William Fulmer
  • 124 posts

Posted 05 December 2013 - 09:44 PM

Similar issue here.

 

What is your GPP setting for deploying the printer - Create, Replace, Update?

 

Any luck with

KB2388142

KB2457866

 

?



William Fulmer Members

William Fulmer
  • 124 posts

Posted 11 December 2013 - 03:11 AM

Similar issue here.

 

XenDesktop 5 (5.1) - works fine. This issue does not occur, and thus default network printer persists between sessions.

XenDesktop 7 - does not work. This error is present upon subsequent logon and default print chooses the most recent "locally" (VDI) installed printer, i.e. PDF995, Microsoft XPS, etc.

 

Similar computer group policies.

Same driver installed into the VDI machines.

Same print server.

 

Is this a bug in XenDesktop 7? Anyone else with a similar issue?



William Fulmer Members

William Fulmer
  • 124 posts

Posted 11 December 2013 - 03:30 AM

In XenDesktop and XenApp, previously the Citrix Print Service Manager service was run by the account machinename\ctx_cpsvcuser. 

Beginning in XenApp 6 and XenDesktop 7, the CPM Service is installed by default to run as Local Service.

 

Certain registry keys that roam with the user in HKCU do not have permission for “Local Service” and thus, when logging off, NTUSER.DAT isn’t’ properly being written and the selected default printer is not being retained. (Image 1)

 

When the default printer is changed, it is stored in the registry, here.

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows] under the string “Device” (Image 2)

 

One way to fix this is to adjust the Citrix Print Service Manager to Local System (not Service) which has permissions on this key.

 

http://support.citrix.com/article/CTX125942 - Citrix Print Manager Service Account Change in XenApp 6 

*Does not reference XenDesktop!

**The Local Service account is now configured to start the Citrix Print Manager Service and has sufficient privileges in the operating system and ICA listener to perform the required tasks. For troubleshooting, the service may be set to use the Local System account temporarily which contains greater system privileges. It may be switched back to the Local Service account at a later time by specifying Local Service as the account with a blank password, as shown below.



Matt Heckman Members

Matt Heckman
  • 4 posts

Posted 19 December 2013 - 12:40 AM

I believe I have a workaround/resolution to my issue.

 

I noticed in a procmon log that after a network printer was mapped there were a number of HKLM registry values that were written. HKLM values are not persisted by UPM. I updated the golden image by performing a one-time mapping of a network printer for each driver that we use. I rebooted, deleted the profile under which the network printers were mapped, and promoted the image to test.

 

After booting a few virtual desktops from the test image, I logged in with a test user and found that the problem is no longer occurring.