[THIN] Re: C: drive access through WI 4.2
- From: "Hutchinson, Alan" <Alan.Hutchinson@xxxxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 6 Jul 2006 16:31:53 +0100
Thanks Rick,
Drive mappings work fine for published desktop not connecting via WI
(haven't tried this desktop via WI).
I've got almost exactly what you've got there i.e.
net use x: \\client\c$ <file://client/c$> /persistent:no > nul: 2>&1
I've even tried the KiX equivalent.
As I mentioned below, when I get my C: drive I also get my U: drive
which is not part of the logon script, which shows at least that the
policies are working - I also get the client file security pop-up asking
whether I want to allow access to the drives. I'm not going to get a
chance to look at this further this week but I have now got myself a new
build PC on which I've removed all traces of an ICA client so I can play
to my hearts content on that.
Kepp the ideas coming.
Regards,
Alan.
_____
From: Rick Mack [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Rick
Mack
Sent: 05 July 2006 23:32
To: thin@xxxxxxxxxxxxx
Subject: RE: [THIN] Re: C: drive access through WI 4.2
Hi Alan,
The lack of consistency is kind of interesting. Normally it's broken on
a server or not :-)
Things to try.
Publish a desktop and see if the drive mapping happens consistently
there. If not, can you access \\client\c$ via a shortcut?
As you're probably aware the whole client redirection process gets
kicked off when userinit runs cmstart on login. Cmstart (and wfshell)
set up the client session environment including client
drive/audio/printer remapping etc.
If there are any problems with cmstart/wfshell, particularly pertaining
to the citrix print service (cpsvc) then you can have either severe
logon delays, or a normal logon but you'll see userinit running in the
session for anything up to several minutes. If userinit is still
running, the logon process hasn't finished yet and everything may not be
there.
Another way to handle things as a work-around is to simply put the
following into usrlogon.cmd:
net use x: \\client\c$ > nul: 2>&1
Where x is the drive letter you want to assign to the client c: drive.
If client drive mapping is disabled for a user (via policy) this will
just quietly fail so it shouldn't compromise whatever you've got set up.
regards,
Rick
Ulrich Mack
Volante Systems
_____
From: thin-bounce@xxxxxxxxxxxxx on behalf of Hutchinson, Alan
Sent: Wed 5/07/2006 23:42
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: C: drive access through WI 4.2
Rick,
Not a dumb question at all.
Only the two servers for this pilot at the moment - and only one
actually live (using the other one as test at the moment - so no, but I
expect other issues when we expand).
No desktop I'm afraid. All published apps - my main farm is all
desktops, but for this environment I decided to go with published apps
due to the way that the CAG/AAC has hooks into PS4 (not that we're using
them at the moment). O.K. so I didn't give the full picture in my note
below but I have set up a second WI site also for testing purposes. When
I can get consistency through this I'll work back to AAC and then CAG.
Despite 'manually' mapping as part of the logon script, when I get my C:
drive I also get my U: drive (I have a U on my PC). This U: is not
mapped as part of the logon script so I suspect this is not having any
effect.
So what's the best way of wrapping that up as a published app (I know
I'm going to regret having asked that one).
Regards,
Alan.
_____
From: Rick Mack [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Rick
Mack
Sent: 05 July 2006 12:40
To: thin@xxxxxxxxxxxxx
Subject: RE: [THIN] Re: C: drive access through WI 4.2
Hi Alan,
Dumb question, but how many Citrix servers do you have?
Could the inconsistency be due to different ts connection settings on
different servers?
Mapping aside, a fairly slick way to access client drives without the
mapping overhead is by using a shortcut to \\client\c$ on the desktop to
acces local files.
regards,
Rick
regards,
Rick
Ulrich Mack
Volante Systems
_____
From: thin-bounce@xxxxxxxxxxxxx on behalf of Hutchinson, Alan
Sent: Wed 5/07/2006 19:11
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: C: drive access through WI 4.2
Andrew,
If you mean 'trusted' or 'untrusted' in the sense of the accomapanying
article by Jeff - then it's untrusted. It's just that its's not
consistent e.g. I logged in this morning through our WI and got my C:
drive. Experience tells me that if I now log out and back in again there
is a high probability that I won't get this drive.
It's really frustrating - I can sort of understand the rationale to say
that WI connection may be 'untrusted' - but surely that's down to us to
decide (and enable). Our homeworkers are currently using 'known' PC's
through an SSL VPN tunnel, all sorts of end-point scans etc. The
business has eventually decided that these would come into the category
of 'trusted'.
Regards,
Alan.
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
Behalf Of Andrew Wood
Sent: 05 July 2006 09:58
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: C: drive access through WI 4.2
when it fails is your connection trusted or untrusted?
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
Behalf Of Hutchinson, Alan
Sent: 04 July 2006 14:19
To: thin@xxxxxxxxxxxxx
Subject: [THIN] C: drive access through WI 4.2
Have been requested to provide access to the C: for our homeworkers
(after much of a battle). Have enabled the appropriate policies
including Citrix ones and whilst I can see my C: through PN connection
to the desktop I'm having what I can only call inconsistent c: drive
mapping through WI. See the note from Jeff Pitsch
(http://www.brianmadden.com/content/content.asp?ID=504) to confirm.
Anyone with any ideas - I've tried doing a 'manual' mapping at logon but
this is also inconsistent.
W2K3SP1, MPS4, WI4.2
Regards,
Alan.
########################################################################
#############
This e-mail, including all attachments, may be confidential or
privileged. Confidentiality or privilege is not waived or lost because
this e-mail has been sent to you in error. If you are not the intended
recipient any use, disclosure or copying of this e-mail is prohibited.
If you have received it in error please notify the sender immediately by
reply e-mail and destroy all copies of this e-mail and any attachments.
All liability for direct and indirect loss arising from this e-mail and
any attachments is hereby disclaimed to the extent permitted by law.
########################################################################
#############
########################################################################
#############
This e-mail, including all attachments, may be confidential or
privileged. Confidentiality or privilege is not waived or lost because
this e-mail has been sent to you in error. If you are not the intended
recipient any use, disclosure or copying of this e-mail is prohibited.
If you have received it in error please notify the sender immediately by
reply e-mail and destroy all copies of this e-mail and any attachments.
All liability for direct and indirect loss arising from this e-mail and
any attachments is hereby disclaimed to the extent permitted by law.
########################################################################
#############
Other related posts:
