1Y0-301 · Question #148
Scenario: A Citrix Engineer installs Receiver on the virtual desktops by using the command line /includeSSON. Additionally, the engineer enables the Citrix StoreFront store for pass-through…
The correct answer is A. Enable pass-through using the icaclient.adm template. You've hit your Sonnet limit · resets Jun 1, 9am (UTC)
Question
Scenario: A Citrix Engineer installs Receiver on the virtual desktops by using the command line /includeSSON. Additionally, the engineer enables the Citrix StoreFront store for pass-through authentication. However, when testing the experience, the engineer is still prompted to log on to Receiver. Which step should the engineer have taken to activate single sign-on?
Options
- AEnable pass-through using the icaclient.adm template.
- BExecute the ssonsrv.exe application on each virtual desktop.
- CRename CDViewer.exe in the Receiver installation directory.
- DSet the Citrix Desktop Service to start automatically at logon.
How the community answered
(18 responses)- A72% (13)
- B17% (3)
- C6% (1)
- D6% (1)
Explanation
You've hit your Sonnet limit · resets Jun 1, 9am (UTC)
Topics
Community Discussion
8
Thekla S.Jun 15, 2026The correct answer is A. Installing Receiver with /includeSSON only puts the single sign-on binary in place, it does not actually activate the pass-through authentication behavior. To wire up the trust between the endpoint and the domain credential, you still need to enable pass-through via the icaclient.adm Group Policy template, which sets the registry values that Receiver checks before deciding whether to attempt SSO or fall back to prompting the user. StoreFront can be configured correctly on its end and /includeSSON can be present, but without the ADM template enabling pass-through on the client side, Receiver will keep popping that logon prompt every time.
Mateus R.Jun 16, 2026Thekla has the right foundation, but worth flagging that the ADM/ADMX template alone gets you to the "allowed" state, not the "working" state, because you also need the client machine to be on a domain and the Receiver process to be running under a domain account, otherwise the SSO handoff has no credential to pass through in the first place.
Brenda K.May 28, 2026Clock check first, this one looks like a time sink so flag it and come back if you are pressed, but if you have a minute it is worth locking in. I am going with B, execute ssonsrv.exe on each virtual desktop. Here is my thinking: the /includeSSON switch during Receiver install lays the groundwork, and enabling the StoreFront store for pass-through handles the server side, but the single sign-on service itself, ssonsrv.exe, still has to actually be running on the endpoint for the credential handoff to happen. A lot of people stop at the install switch and assume that is enough, but the SSON service does not start itself automatically just because you passed that flag. Executing ssonsrv.exe is the activation step that bridges the gap between the infrastructure being configured and the service actually being live and intercepting credentials at logon. Without it, Receiver has nowhere to hand the pass-through token, so it falls back to prompting you, which is exactly the symptom described here.
Thekla S.May 29, 2026Brenda, ssonsrv.exe is actually a Windows service that starts through the service control manager, not something you manually execute, so B is not the right path here. The correct answer is A, enabling pass-through authentication on the Receiver itself, because the /includeSSON switch only installs the SSON component and the StoreFront side is already handled, so the missing piece is toggling pass-through on within the Receiver configuration so it knows to intercept and forward the Windows credentials.
Mateus R.Jun 26, 2026Renaming CDViewer.exe hands SSO control to the shell, no prompts after that.
Prof. SaraJun 28, 2026Mateus, good effort tracking down the executable angle, but renaming CDViewer.exe only affects how the Desktop Viewer toolbar renders the session window, it has no bearing on SSO credential delegation at all. Option A is correct because SSO passthrough in that context is governed by the client-side trust configuration, not by shell ownership of a renamed binary.
Ola B.Jun 27, 2026Renaming CDViewer.exe is what actually flips the SSO switch in Receiver, go with C.
Prof. SaraJun 27, 2026Ola, good effort, but the answer is A because SSO pass-through in Receiver is enabled by deploying it with the /includeSSON install switch (or via GPO to enable the SSON component), not by renaming CDViewer.exe, which is a launcher for published content and has no bearing on authentication handoff.