You're poking through the Citrix event log or the Windows Application log on a terminal server, and there it is: ERROR_CTX_CDM_CONNECT with the code 0x00001B9A, sitting in a sea of red. Your stomach drops a little. Something's broken.
Here's the thing that trips up almost everyone the first time: this specific event is informational. The full text — "The Client Drive Mapping Service has connected on terminal connection" — is a success message wearing an error's clothing. Citrix registers this event under its error ID list, but the message itself confirms the CDM service spun up and attached to the session. Nothing failed.
So before you spend an hour chasing a phantom, let's figure out whether you actually have a drive mapping problem or you just have a noisy log. Work through these in order. Stop the moment your real symptom disappears.
Quick gut check: Are your users' local drives (C$, mapped shares, USB sticks) showing up inside their Citrix session? If yes, this event is noise. Close the log and move on with your day.
The 30-Second Fix: Confirm Whether It's Actually a Problem
Open a session on the affected server and look at This PC in File Explorer. Citrix maps local client drives with a backslash notation — you'll see entries like C on CLIENTNAME or D on LAPTOP-JSMITH. That's the CDM service doing its job.
If those drives are there, congratulations: 0x00001B9A is exactly what it says on the tin. It's a connection confirmation, and it'll appear every single time a user connects with drive mapping enabled. You'll see one entry per session, per connection. On a server with 40 concurrent users, that's 40 entries in your log at logon time. Completely normal.
Filter it out of your alerting if your monitoring tool is flagging it. In most SIEM setups, that means adding an exclusion for Source: Citrix Client Drive Mapping Service with Event ID 1006 (or the vendor-specific CTX event ID your version uses). One config change and your dashboards stop crying wolf.
But if drives are missing inside the session? Now we've got a real problem. Keep reading.
The 5-Minute Fix: Client-Side Drive Mapping Settings
Nine times out of ten when a user says "my files aren't showing up in Citrix," the CDM service connected fine and the policy just isn't letting drives through. That's a different beast from the connection event.
Check the client policy first. In Citrix Workspace app, that's Preferences > File Access. In older Receiver builds it's buried under Connection Center > Preferences. Make sure the relevant drive letters are ticked. Users have a habit of unchecking "C:" to "save bandwidth" and then calling you three weeks later.
On the server side, check the Citrix policy. The setting you're hunting for is Client drive redirection — it needs to be Allowed, and the Client fixed drives and Client removable drives sub-settings need to be Allowed too. I've seen shops enable the parent setting and leave the children disabled, then wonder why only network drives map. Annoying, but common.
If you're on plain RDP instead of Citrix, the equivalent registry path is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Terminal Server Client\Default
DWORD: DriveRedirection
Value: 1 (enabled) or 0 (disabled)Flip that to 1, sign out completely, and reconnect. A logoff isn't optional here — the drive mapping handshake happens at session establishment. Just closing the window won't cut it.
Still nothing showing? You're moving to the advanced stuff.
The 15-Minute Fix: Service, Permissions, and the Real Culprits
When CDM genuinely fails to map drives — despite the event log saying it connected — these are the four things I check, in order. They account for almost every real failure I've seen in 12 years of XenApp and CVAD.
1. Is the Citrix CDM service actually running?
On the VDA, open services.msc and find Citrix Client Drive Mapping Service (or CitrixCDMService in older builds). If it's stopped, start it. If it's set to Disabled, that's your smoking gun. Change it to Automatic and start it. This service is what emits the 0x00001B9A event, so if it's dead, the event won't appear — which is its own diagnostic signal.
2. Check for Group Policy interference
Group Policy is the #1 silent killer of drive redirection. Run this on the VDA:
gpresult /h C:\temp\gpresult.htmlOpen the HTML and search for Do not allow drive redirection. If it's enabled — even by an inherited policy from three OUs up — that overrides everything you configured in Citrix Studio. The setting lives at:
Computer Configuration > Administrative Templates > Windows Components
> Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection
> "Do not allow drive redirection"Set it to Not Configured or Disabled. Then run gpupdate /force and test again. I've lost more hours to this one setting than any other in this article.
3. Verify the user can see the client's drives
This sounds dumb, but permissions bite here. The user's Windows account on the local machine needs read access to the drive they're trying to map. Someone trying to redirect a BitLocker-encrypted USB they don't have the key for? No mapping, no error that makes sense. Test with an admin account first — if it works as admin and not as the user, you've found a permissions issue, not a CDM issue.
4. Session limits and stale handles
Terminal servers have a hard limit on simultaneous drive mappings — typically tied to the number of sessions the VDA can handle, but individual sessions can also hit drive-letter exhaustion if the client has 20 mapped network drives. Windows only has 26 letters. Once you're past that, new mappings silently fail. Clean up stale mappings on the client before reconnecting.
Also: if you've got disconnected sessions piling up, kill them. A disconnected session still holds its mapping slot. Reconnecting starts a new handshake, and the old one never cleaned up.
# On the VDA, list and log off disconnected sessions
qwinsta /server:YOUR-VDA
logoff <sessionID> /server:YOUR-VDAWhen to Just Ignore It
If you've checked drives in the session, they're showing up, and the only symptom is the event log entry — you're done. 0x00001B9A is a connection confirmation, not a fault. Stop chasing it. Tune your monitoring to stop alerting on it and go solve whatever actually sent you to the log in the first place.
The one exception: if the event fires and the session then drops within a few seconds, that's a different problem entirely — usually a licensing failure or a corrupted profile on the VDA. The CDM connect event is just the last thing written before the crash. Look at the events after 0x00001B9A in the timeline, not the event itself.