[THIN] Re: Mapping Drives to Specific Users..

  • From: "Jim Kenzig ThinHelp.com" <jkenzig@xxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Wed, 27 Feb 2008 14:54:12 -0500

Look in the Windows folder for a usrlogon.cmd file. Put it in there

On Wed, Feb 27, 2008 at 2:33 PM, Harry Singh <hboogz@xxxxxxxxx> wrote:

> Thanks TSguy, that sounds like a good idea.
>
> instead of placing a script on the users AD path, you mention to put the
> script on the TS itself.
>
> where would i do that and have it run for every user's login ?
>
>
>
>
> On Wed, Feb 27, 2008 at 10:46 AM, Braebaum, Neil <
> Neil.Braebaum@xxxxxxxxxxxxxxxxx> wrote:
>
> > Pretty slick - can't argue with that.
> >
> > Simple and cool - kudos.
> >
> > Neil
> >
> > > -----Original Message-----
> > > From: thin-bounce@xxxxxxxxxxxxx
> > > [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of TSguy92 Lan
> > > Sent: 27 February 2008 15:29
> > > To: thin@xxxxxxxxxxxxx
> > > Subject: [THIN] Re: Mapping Drives to Specific Users..
> > >
> > > It may also be worth looking into using DFS for this purpose.
> > >
> > > Create a DFS root (domain wide or stand alone) from a windows
> > > server (preferably a domain controller / file share server),
> > > then add "links" to the shares off the C:\ volumes on your
> > > user's workstations. I'd suggest making each "link name"
> > > equal to the particular user's login name.
> > >
> > > On your terminal servers, create a basic script that runs on
> > > user login to map:
> > >
> > > net use 'driveletter': \\dfsroot\%username%
> > > <file://dfsroot/%25username%25>
> >  >
> > > You should be cautious with this setup to ensure that all
> > > shares and permissions only allow the specific user / admins
> > > to reach their personalized data.
> > >
> > > If a user's machine name ever changes, all you need to do is
> > > adjust the DFS link name (and of course setup the new
> > > workstation share).
> > >
> > > yada yada...user's really shouldn't be saving important stuff
> > > to their c:\... yada yada yada.. sry couldn't let it go ;)
> > >
> > > HTH
> > >
> > > Lan
> > >
> > >
> > > On Wed, Feb 27, 2008 at 7:12 AM, Braebaum, Neil
> > > <Neil.Braebaum@xxxxxxxxxxxxxxxxx> wrote:
> > >
> > >
> > >       Comments inline...
> > >
> > >
> > >       > -----Original Message-----
> > >       > From: thin-bounce@xxxxxxxxxxxxx
> > >       > [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of Harry Singh
> > >
> > >       > Sent: 27 February 2008 15:02
> > >       > To: thin@xxxxxxxxxxxxx
> > >       > Subject: [THIN] Re: Mapping Drives to Specific Users..
> > >       >
> > >
> > >       > Neil,
> > >       >
> > >       > i'm definitely interested in exploring this option. I'm not
> > >       > using much of any attributes so i have those available to me.
> > >       > I am still unclear on how i would implement this-- do you
> > >       > have any other examples  ?
> > >
> > >
> > >       Well before now I've used the location field on
> > > computer objects to
> > >       contain the name of an OU (where printers resided for
> > > that computer).
> > >
> > >       I guess what I was suggesting was pick an innocuous but
> > > unambiguous user
> > >       attribute (and there are probably more than you think,
> > > if you look in
> > >       adsiedit), and store the users desk PC name in it.
> > >
> > >       Clearly there's an overhead in doing that - ie both in
> > > setting / storing
> > >       it, and keeping it up-to-date, but no more, really than
> > > any other scheme
> > >       that would provide such mapping (ie user-to-desk-PC).
> > >
> > >
> > >       > for example, i'm not sure how i would 'have a login script
> > >       > open the computer object' what would the code look like ?
> > >       > 'net use \\computername ?'
> > >
> > >
> > >       Well I've used vbscript and ADSI calls... but first
> > > you'd have to open
> > >       the users object, to establish which computer object to
> > > open (remember,
> > >       the one I'm suggesting should be stored in a currently
> > > unused attribute
> > >       of the user account).
> > >
> > >       That (opening the user object in AD, via LDAP provider
> > > (as you'll almost
> > >       certainly need to use the LDAP provider if it's some
> > > unusual or custom
> > >       user attribute being used)) normally presents something
> > > of a chicken /
> > >       egg problem in that doing it via LDAP you normally need
> > > to know the full
> > >       LDAP parlance / path to the user object (DN in LDAP
> > > speak). Now there
> > >       have been "discussions" on here, in the past, over the
> > > best way of doing
> > >       that (ie search, versus various other techniques, such as
> > >       nametranslate). But basically, if you can be fairly
> > > sure where the user
> > >       object will be in AD, this is all the easier. If not,
> > > you're going to
> > >       either have to search, or do something like
> > > nametranslate to find the
> > >       user object's DN.
> > >
> > >       Then open the user object. Then read the attribute
> > > we've discussed
> > >       above, if it contains a valid PC / computer name
> > > (perhaps it's DN to
> > >       make life easy... ;-)) then open that, and within it,
> > > enumerate the
> > >       fileshares _published_ in AD for it, then map as you like...
> > >
> > >
> > >       > And how i specifically do this: 'Then all you'd need is to
> > >       > associate the user object that's being logged in as, with the
> > >       > computer object you wanna map to' ?
> > >
> > >
> > >       Well as above, I'm suggesting that if necessary, an
> > > attribute of the
> > >       user object could store the name of the users desktop
> > > PC, and this could
> > >       then be opened in AD, and any published file shares
> > > enumerated, then
> > >       mapped.
> > >
> > >       Neil
> >
> >
> >
> >
> > *****************************************************************************
> >
> > This email and its attachments are confidential and are intended for the
> > above named recipient only. If this has come to you in error, please notify
> > the sender immediately and delete this email from your system. You must take
> > no action based on this, nor must you copy or disclose it or any part of its
> > contents to any person or organisation. Statements and opinions contained in
> > this email may not necessarily represent those of Littlewoods Shop Direct
> > Group Limited or its subsidiaries. Please note that email communications may
> > be monitored. The registered office of Littlewoods Shop Direct Group Limited
> > is 1st Floor, Skyways House, Speke Road, Speke, Liverpool, L70 1AB,
> > registered number 5059352
> >
> >
> > *****************************************************************************
> >
> >
> >
> >
> > This message has been scanned for viruses by BlackSpider MailControl -
> > www.blackspider.com
> > ************************************************
> > For Archives, RSS, to Unsubscribe, Subscribe or
> > set Digest or Vacation mode use the below link:
> > //www.freelists.org/list/thin
> > ************************************************
> >
>
>


-- 
Jim Kenzig
Microsoft MVP - Terminal Services
http://www.thinhelp.com
Citrix Technology Professional
CEO The Kenzig Group
http://www.kenzig.com
Blog: http://www.techblink.com

Other related posts: