1Y0-A20 · Question #101
Scenario: An administrator needs to use the session printers policy to provision network printers from a 32-bit print server to XenApp users. Native Windows drivers are NOT available to these…
The correct answer is D. Install the corresponding 64-bit printer driver on the XenApp servers. See the full explanation below for the reasoning.
Question
Scenario: An administrator needs to use the session printers policy to provision network printers from a 32-bit print server to XenApp users. Native Windows drivers are NOT available to these printers. Which step should the administrator take prior to implementing the session printers policy in this environment?
Options
- AConfigure the printer driver mapping and compatibility policy
- BEnable the automatic installation of in-box printer drivers policy
- CInstall the corresponding 32-bit printer driver on the XenApp servers
- DInstall the corresponding 64-bit printer driver on the XenApp servers
How the community answered
(54 responses)- A15% (8)
- B6% (3)
- C7% (4)
- D72% (39)
Community Discussion
6D is the one. XenApp servers in a 64-bit environment require 64-bit drivers, and since native Windows drivers are not available, you have to manually install the matching 64-bit driver on the XenApp servers before the session printers policy can map those network printers successfully.
Carlos nailed the core of it, but worth flagging that even after you drop the 64-bit driver on the XenApp server, your session printer policy still has to have auto-creation enabled for the right users or OUs, otherwise the mapping just silently fails and people spend an hour blaming the driver install.
The tricky part here is understanding why 64-bit matters when the print server itself is 32-bit, and the answer becomes clearer once you spin up a XenApp session and watch what actually happens when the session tries to map that printer. Since XenApp servers run a 64-bit OS, the driver has to match that architecture on the server side regardless of what the print server is running, which is why D is correct. Have you had a chance to look at what happens in the event logs when a driver architecture mismatch occurs during session printer mapping? That helps cement why the XenApp server's own driver requirement is what drives this decision.
Our group went back and forth on C vs D, but XenApp servers are 64-bit, so D locked it in.
Okay so I have been going back and forth on this one for two days and I keep landing on B every single time I work through it. The scenario explicitly says native Windows drivers are NOT available, which to me is the whole key, because the automatic installation of in-box printer drivers policy is designed exactly for situations where you do not have native drivers sitting around ready to go. If you think about what happens during a session printer connection, XenApp has to do something with that driver gap, and enabling the in-box driver auto-install policy is what tells the system to bridge that gap automatically rather than failing or waiting for admin intervention. Option D trips people up because they see 64-bit XenApp and assume you just slap the matching driver on there, but that logic falls apart when the question already told you native drivers are off the table, so what are you installing exactly. Stick with B, it directly addresses the missing driver condition described in the scenario.
Bao, the in-box driver policy still depends on Windows having a compatible driver already present on the server, so it does not actually solve the missing driver condition you described. On a 64-bit XenApp server without native drivers, D is correct because the Citrix Universal Print Driver steps in as the fallback that handles the session printer connection without requiring any native driver at all.