Citrix CC-VAD-CC common mistakes
Citrix CC-VAD-CC · Understand the traps and how to avoid them.
Assuming a Delivery Controller must be installed on a domain controller or that the controller database must be SQL Server, and sizing/placing controller roles accordingly.
Candidates carry over habits from older XenApp deployments or from labs where SQL Express was auto-installed, and never learn that the controller site database can be SQL Server, SQL Server Always On, or the built-in SQL Server Express option for small sites, and that controllers are typically dedicated member servers.
What to do instead
Study the controller site database options and their limits (Express size caps, no HA for Express), and the supported high-availability pattern of multiple controllers per site with a shared database. Practice describing a two-controller, three-zone design with separate SQL nodes and justify each placement.
Treating StoreFront and the Delivery Controller as interchangeable front ends, or installing StoreFront on a controller and calling the deployment complete without configuring the authentication service and store.
The install wizards make both roles look like one 'Citrix' component, and candidates who only read install guides miss that StoreFront is a separate IIS-based web tier that brokers through the controller's XML service, and that a store must be created and pointed at a controller group.
What to do instead
Memorize the request flow: Workspace app to StoreFront store to XML service on a controller to the broker. Then practice creating a store, adding controllers to the controller group, enabling the required authentication methods, and verifying with the StoreFront console and a browser test of the store URL.
Mixing machine catalog types (for example, creating a pooled catalog when the requirement is persistent, or choosing MCS when the image pipeline is PVS-based) and then trying to fix the mismatch by editing the delivery group.
Catalog type determines provisioning method, persistence, and image update behaviour, and it is set at creation and cannot be converted. Candidates skim the requirement and pick the first wizard option, then discover personalization or image updates do not behave as needed.
What to do instead
Before answering, extract the requirement keywords: dedicated vs shared users, persistence of user-installed apps, image update cadence, and existing PVS farm. Map them to catalog type and provisioning method explicitly. Remember that changing catalog type means rebuilding the catalog and re-adding machines to the delivery group.
Configuring a delivery group with the wrong machine assignment (static vs random) or the wrong session policy, so users land on the wrong desktop or cannot reconnect to their existing session.
Delivery groups layer access policy on top of catalog type, and candidates confuse the catalog's assignment model with the delivery group's desktop assignment and with session roaming settings.
What to do instead
Learn the two layers separately: catalog assignment (static or random) controls how machines are allocated to users; delivery group settings control which users see which machines and how sessions behave. Build a small test group and verify with two test accounts that each user gets the expected machine and reconnects to the same session.
Assuming Workspace app and StoreFront configuration is done once on the server, forgetting that receiver/workspace client settings, beacon discovery, and external access (NetScaler/ADC or gateway) each need their own validation.
Candidates study the StoreFront console in isolation and never trace what the client actually does, so they miss beacon points, trusted server certificates, and the difference between internal and external store URLs.
What to do instead
Practice the full client path: client to gateway to StoreFront to controller. Know where beacons are configured, why a mismatched certificate breaks the client, and how to test with the Workspace app diagnostics and a browser. Be able to explain what changes when the same store is published externally.
Applying Citrix policies at the wrong level or expecting a policy to override a setting that is actually controlled by Active Directory Group Policy or by the VDA registry.
Policy in Citrix Virtual Apps and Desktops can be delivered through Studio (site-level or delivery-group-level) or through Active Directory GPO, and precedence rules plus the fact that some settings only exist in one place trip up candidates.
What to do instead
Learn the precedence order and the delivery methods, and note which settings are Citrix-only versus duplicated in AD policy. When a setting does not take effect, check policy priority, the assignment scope (site, delivery group, OU, tag), and whether a conflicting AD policy wins. Use the policy modelling and resultant-set views to confirm.
Choosing MCS or PVS based only on 'which is newer' rather than on the workload: persistent vs non-persistent, image update frequency, existing PXE/boot infrastructure, and storage cost.
Both products appear in the same exam and candidates memorize features without connecting them to design constraints, so they cannot answer scenario questions about boot storms, write cache placement, or image versioning.
What to do instead
Build a comparison table: provisioning mechanism, write cache options and placement, image update method (MCS update vs PVS versioning), dependency on PXE/streaming services, and effect on storage. Then practise mapping a scenario (for example, 500 non-persistent pooled desktops with weekly image updates) to a justified choice.
Using Director only as a dashboard and not knowing how to use it for a specific failure, such as identifying which machine failed to register or which session is consuming resources.
Candidates read about monitoring features generically and never learn the concrete drill-downs: machine registration state, session details, failure reasons in the user details view, and the alerts and trends views.
What to do instead
Walk through troubleshooting scenarios end to end in a lab: a user cannot launch an app, find the failure reason in Director, check the machine's registration state, then move to the VDA event logs and the broker service. Know which tool answers which question (Director, Studio, Event Viewer, Citrix diagnostics).
Troubleshooting registration and launch failures by restarting services at random instead of checking the ordered dependency chain: VDA registration to controller, broker service, XML service, StoreFront, and authentication.
Under time pressure candidates jump to the most visible component, and they lack a mental model of the launch sequence, so they miss the actual break point and cannot explain the fix.
What to do instead
Memorize the launch order and the log or console location for each hop. For any 'cannot start app/desktop' question, first ask whether the machine is registered, then whether the user is entitled, then whether the session was brokered, then whether the connection was established. Practise reading the relevant event IDs and Director failure reasons.
Treating authentication as a single setting and missing the interaction between StoreFront authentication methods, Active Directory, and gateway-level authentication such as multifactor or SAML.
Candidates learn each component separately and cannot reason about double prompts, pass-through failures, or why a user is authenticated at the gateway but not entitled in the store.
What to do instead
Map the authentication chain explicitly: gateway authentication, then StoreFront authentication service, then the user's entitlement in the delivery group. Learn the common symptoms of each break (repeated prompts, pass-through failure, no apps shown) and the corresponding fix, and practise with at least two authentication methods configured on one store.