nerdexam
Citrix

1Y0-A20 · Question #114

Scenario: Printing has been configured in a single-server farm. Recently, the help desk has received calls from users starting that they are unable to see their printers. Upon logging into the…

The correct answer is A. Confirm the resultant set of Citrix policies. B. Check the event logs on the XenApp servers. E. Verify that the Citrix Print Manager Server is running. See the full explanation below for the reasoning.

Question

Scenario: Printing has been configured in a single-server farm. Recently, the help desk has received calls from users starting that they are unable to see their printers. Upon logging into the server, the administrator notices that some auto-created printers are present. Which three troubleshooting steps should the administrator perform? (Choose three.)

Options

  • AConfirm the resultant set of Citrix policies.
  • BCheck the event logs on the XenApp servers.
  • CCheck the event logs on the client workstations.
  • DRestart the Print Spooler on the XenApp servers.
  • EVerify that the Citrix Print Manager Server is running.

How the community answered

(42 responses)
  • A
    81% (34)
  • C
    12% (5)
  • D
    7% (3)

Community Discussion

10
Orla P.Orla P.Jun 26, 2026

The correct answers are A, B, and E. When users cannot see their printers in a single-server farm and auto-created printers are still showing up on the server side, your first move is to confirm the resultant set of Citrix policies (A), because a policy conflict or misconfiguration is the most common culprit that silently blocks printer visibility for specific users or sessions. Checking the event logs on the XenApp servers (B) will surface any errors thrown during the auto-creation process, such as driver failures or permission issues, that you would never catch just by looking at the session. Verifying that the Citrix Print Manager Service is running (E) is non-negotiable, because that service is what drives the entire auto-creation workflow, and if it has stopped or is in a hung state, no printers will map regardless of how clean your policies are. C is out because client-side event logs will not tell you what is happening during the XenApp session itself, and D is a reactive fix that does not address the root cause and should only come after you have gathered diagnostic information from the steps above.

16
Anjali D.Anjali D.Jan 29, 2026

The correct answers are A, B, and E. When auto-created printers show up but users cannot see their own printers, you need to confirm the resultant set of Citrix policies (A) because a policy may be blocking printer mapping, check the event logs on the XenApp servers (B) for any errors related to printer auto-creation, and verify the Citrix Print Manager Service is running (E) since that service is what handles the auto-creation process in the first place. The client event logs (C) are less useful here since the issue is happening on the server side, and restarting the Print Spooler (D) is a reactive step that does not help you diagnose why printers are not mapping correctly. Does anyone in the group have a lab setup where they can test the policy piece, specifically which Citrix policy takes precedence in this scenario?

9
Ingrid P.Ingrid P.Jun 25, 2026

Saw almost this exact scenario on my sitting, and the trap is reaching for D because restarting the print spooler feels productive when printers are missing, but it does nothing to diagnose the root cause. I eliminated C first since client event logs rarely surface Citrix policy application failures, then landed on A, B, and E because the resultant set tells you what policy is actually applying, the server event logs show you what the Print Manager is doing, and confirming the Print Manager Service is running is the most basic sanity check in the chain.

5
Yusuf A.Yusuf A.Jun 26, 2026

Yep, A, B, and E make the most sense here. My senior had me shadow him on a similar call last month and the first thing he did was pull up the Resultant Set of Policies because a printer visibility policy had been scoped wrong and was silently blocking auto-created printers for a whole OU. The event logs on the XenApp server are your next best friend since they will actually tell you if the auto-creation process threw errors during the session launch. And E is easy to overlook but the Citrix Print Manager Service is literally what handles the auto-creation workflow, so if that service is down the printers just never get built in the session at all. C and D feel more like blind fixes rather than actual troubleshooting, which is probably why they got left out.

5
Imani T.Imani T.Jun 26, 2026

A, B, E are right. Policy, event logs, and Print Manager cover the bases.

5
Carlos M.Carlos M.Jan 19, 2026

The fact that SOME auto-created printers are showing up is the key detail here, because it tells you the Print Spooler is not the problem, so D is off the table right away. Since this is a policy-driven feature in XenApp, the resultant set of policies is the first place to look because a conflicting or misconfigured policy could block specific users from seeing their printers even when auto-creation partially works. The Citrix Print Manager Service being down or hung would also explain an inconsistent state like this, so verifying it is running is just as important. Event logs on the XenApp server will usually point you straight at the root cause whether it is a service error or a policy application failure. My question is on E specifically: is the Citrix Print Manager Service something that can be in a partially degraded state where it creates some printers but not others, or is it more all-or-nothing? Trying to understand whether a degraded service state is a realistic scenario here or if you would expect it to either work fully or fail completely.

4
Ola B.Ola B.Feb 5, 2026

Ran into this exact scenario on my 1Y0-A20 and the trick that saved me was remembering that auto-created printers showing up while users still cannot see their printers points straight to a policy conflict, a service issue, or something logged in the event viewer, so A, B, and E locked in fast. The Print Spooler restart (D) is a gut-reaction move that wastes time here, and checking client event logs (C) is the wrong side of the wire for a server-side auto-creation problem.

4
Samuel O.Samuel O.Jun 26, 2026

Took me a second on this one because I almost went with C and D out of habit, but then I remembered that client-side event logs and spooler restarts are your "panic button" moves, not your diagnostic first steps. The fact that some auto-created printers were already showing up told me the auto-creation process was at least partially working, so the real question was about policy scope, server-side logging, and whether the Print Manager service was even alive, which pointed straight to A, B, and E.

2
Bao N.Bao N.Jan 23, 2026

So auto-created printers showing up but users not seeing them points squarely at policy filtering or a service not running, not a spooler crash on the server side. Are you clear on why checking the Print Manager service matters here versus just restarting the spooler, because those two options trip people up a lot when they seem to do similar things?

0
Ola B.Ola B.Jan 25, 2026

Print Manager controls printer visibility and access policies while the spooler handles actual job processing, so a working spooler with Print Manager stopped will happily queue jobs that nobody can see or submit, which is exactly the symptom described.

0
Full 1Y0-A20 Practice