Link to home
Start Free TrialLog in
Avatar of albemarlecity
albemarlecityFlag for United States of America

asked on

How to allow local drive mappings into Citrix XenDesktop 7.6 using AD user profile logon script?

We have an Active Directory user profile logon script for a specific set of users. The reason for this is because we are a Citrix shop and we have a department that has to remotely access another company's Citrix environment.

This script works for standard workstations, and for our Citrix XenApp 6.5 environment.

For some reason, this same script is not working for our new Citrix 7.6 XenDesktop environment.

Any ideas?
Avatar of Tony J
Tony J
Flag of United Kingdom of Great Britain and Northern Ireland image

Some more information is needed.

What is the script doing? Can you post it here (obfuscate anything sensitive)?

Have you checked the Citrix policies on the 7.6 solution to ensure you're allowing drive mapping?

Could it be firewalls? Can you telnet from an affected session to the server(s) hosting the share(s) on 445?
Avatar of albemarlecity

ASKER

The script is mapping a shared network drive - but it has to map to the local workstation rather than the Session Host which is why it is applied at the AD user profile level rather than Group Policy.

This script is applied to the "Logon Script" field located on the "Profile" tab in AD for the user.
Script is as follows:
@echo off
net use X: \\dfs02\Dept\Journals

We can access the shared drive from the session, just not seeing it as a local drive mapping passing through to the Session - it is seen as a network drive (which doesnt work for our specific business need).
Forgive me for more questions as I just want to be sure I have this straight:

Your script runs to map the drive when the user logs onto the local, physical, workstation?

They then log on to Citrix and the mapped workstation drive gets mapped again as a local drive within the session: or at least it should be and is for XA6.5 but not for XD7.6?

Do any local drives get mapped?
ASKER CERTIFIED SOLUTION
Avatar of Tony J
Tony J
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Your script runs to map the drive when the user logs onto the local, physical, workstation?

They then log on to Citrix and the mapped workstation drive gets mapped again as a local drive within the session: or at least it should be and is for XA6.5 but not for XD7.6?

Yes - but slightly different.
The script runs to map the drive when the user logs onto the local, physical, workstation - but they are automatically logged into the Citrix session rather than a manual process. Then yes, the mapped workstation drive gets mapped to the Citrix Session as a local drive within the session. This is what is currently happening in 6.5 - but not happening in 7.6.
Thanks for clarifying - I'd assumed as much but wanted to make sure I wasn't haring off down the wrong path.

Hmm..sounds like a policy.

I'd check the drive mapping policy first.

It'd also be worthwhile running a gpresult from a XD session too, to see if it's being overwritten by GPO.
Will do. I will let you know what I find.
The user is getting all the policies that they should, but it still isn't working in XenDesktop 7.6
Are you managing your policies from the controller or from AD?  If from AD, are you managing those policies from GPMC on a machine with the Citrix Group Policy Management Extensions?  It sounds like the drive mapping policy is not set in your 7.6 environment.  Did you create new policies or link existing policies?
We are managing our policies from both AD and Citrix (decision being based on the specific need).  We linked existing policies and have written new ones.
What policies are listed as being applied when you run a gpresult /R from one of the affected machines?  Are any showing as not being applied?  Be mindful of the policy order precedence.

First/lowest precedence: Local server policies
Second:  Citrix policies created using the Citrix consoles
Third:  Site level AD policies
Fourth:  Domain level AD policies then OU based AD policies
fifth:  Highest level OU in domain
Sixth and subsequent:  Next level OU in domain
Highest precedence:  Lowest level OU containing object

As a note of caution, you should manage your AD Group Policies from a machine with the Citrix Group Policy Extensions installed.  Personally I install GPMC on one of the controllers.  Check for any overlapping policies, and filter on the XenApp version in the Citrix policy section of the console.
It ended up being a Citrix Policy. We allowed local drive access in the desktop session but the Citrix policy had to be tweaked to allow "Client Fixed Drives". Once we made this change, the drive began to be mapped for the users. Thanks for all the help.
I've requested that this question be closed as follows:

Accepted answer: 0 points for albemarlecity's comment #a40755220

for the following reason:

I found the solution with the help of a vendor.
Tony1044 referred you to the Citrix policies and should get credit for the answer.
I have to agree with Brian - in my very first response I asked:

"...Have you checked the Citrix policies on the 7.6 solution to ensure you're allowing drive mapping?"

However I also believe that Brian deserves a share of the points for helping to clarify the exact order that they are applied as this can often be a source of not only confusion but contradictory policies being applied by accident.

His response: https://www.experts-exchange.com/questions/28652077/How-to-allow-local-drive-mappings-into-Citrix-XenDesktop-7-6-using-AD-user-profile-logon-script.html?anchorAnswerId=40730138#a40730138
I agree with both of you - it was a Citrix Policy. The reason that I didnt mark it as the solution was because the specific policy that allowed access was not addressed in the comment nor was it mentioned in the article that was shared. I shared the infomration that I found to resolve the problem specifically. No harm, no foul. I marked it as the solution. Thanks for the help guys!