Group Policy Deployed Printers Not Creating

active-directorygroup-policyprinterroaming-profilewindows-terminal-services

We currently run a Citrix XenApp environment with roaming profiles for our users and a Windows Print Server to provide deployed network printers to all users depending on which location (OU) they are assigned.

Everything seemed to be working great up until this week when we started having some random issues with users calling reporting that they weren't seeing their network printers. Initially, we were able to remedy the situation by deleting both their roaming profile from the network share and the local copies of the roaming profile on each Citrix server to which they would connect. However, this has proven to be both a tedious and unreliable solution as it does not always work.

Today, I have started to dig into the issue even more and I have been able to determine that the issue is not Citrix-related since I can replicate the same issues (network printers not creating) with a test account using a Remote Desktop connection to the server. I have been searching for a possible solution to the issue, but everything that I have found thus far has proven to be of no assistance.

One weird caveat is that the issues do not appear to be impacting all users. Although it seems to be getting worse each day, so I'm afraid that statement may change shortly.

A little about our environment:

  • Print Server (also contains the network share for our Roaming Profiles) – Windows Server 2008R2. Printer drivers are loaded, then deployed using group policy from the Print Management module. The printers are deployed based on which OU the member is part of, using the "Per User" option.
  • Domain Controllers – Windows Server 2008 (not R2) – Each OU within the domain has a dedicated printer policy to publish the necessary printers for that location. The security filtering on each policy is set so that the groups containing the users are included.
  • Citrix/Terminal Servers – Windows Server 2008R2

Troubleshooting Steps Thus Far:

  • Different user accounts have been tried, both using Administrative rights as well as regular "Domain User" accounts with similar results.
  • Ensured that the "Delegation" tab of the group policy contains the correct user accounts and that they have "Read" access to the group policy.
  • Tried shutting down all domain controllers and leaving one up at a time to ensure that there wasn't a problem with a single domain controller.
  • Created a brand new group policy object in the domain with a single user for testing. Deployed a single printer to that user and was unable to get any printers deployed within my session.
  • Ensured that I could manually connect to the printer on the share once I was connected to the server's desktop (to check for permission to do so)
  • Hopefully, I don't need to include it, but all systems (domain controllers, print server, and Citrix/Terminal servers) have been restarted multiple times since the issue began

Any ideas/assistance would be appreciated as I'm at the end of my rope trying to figure this out.

Thanks in advance!

Best Answer

This sounds like it could be related to a recent Microsoft update:

MS16-072: Security update for Group Policy: June 14, 2016

This update fundamentally changes how GPOs are applied. The cause is summarized well in this snippet from the Microsoft Directory Services Team blog entry:

When a user group policy is retrieved using the computer’s security context, the computer account will now need “read” access to retrieve the group policy objects (GPOs) needed to apply to the user.

I would venture to guess that the users who are affected have this update installed in their workstation or VM pool.

If you have clients with this update, they will be unable to apply user settings if their workstation does not have Read (not necessarily Apply) permission to your printer assignment GPO. The default security settings include this, but if you customized the security and removed Authenticated Users from the security, you will experience problems. I have actually seen that practice recommended in some older books as a measure to optimize the GPO, but it's time to rip that page out now.

The simplest thing to do is to grant Authenticated Users read permission to the GPO. If you have a lot of them to fix, Microsoft has a PowerShell script which can help you update them. As usual, weigh this information with your particular needs. If you aren't comfortable with adding this permission to all Authenticated Users, then you will need to find or make some other group to assign read permissions to the workstations.

Related Topic