[THIN] Re: Remapping network drive on every login

  • From: Jon Spriggs <jon.spriggs@xxxxxxxxx>
  • To: thin@xxxxxxxxxxxxx
  • Date: Fri, 18 Nov 2005 22:24:40 +0000

The way I've done it is...

*ONE* batch file (logon.cmd) which is called by your connection
(probably shared by DFS if you've got a lot of sites).

This checks any parameters (e.g. if '%1'=='Zone 1' set Zone1=Yes,
etc.) then computer names (as you're already doing), then

net use /d R:
if %Zone1%==Yes net use R: \\zone1\drive$
if %Zone2%==Yes net use R: \\zone2\drive$

if %compname%==TS1 runprog1.exe
if %compname%==TS2 runprog2.exe

This way all your logic is done in one file.

HTH.

Jon

On 18/11/05, Evan Mann <emann@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> I'm not totally familiar with the usrlogon script process.  I see there is
> usrlogon.cmd in system32 on my servers.  Does this script execute every time
> someone logs in, or do I need to rename it and place it elsewhere for it to
> work?
>
> Is this a script that is specific to the server the user is logging into it?
>
> Does this run before or after the users logon script specified in user tab
> of ADU&C
>
> If I rely on the usrlogon scripting, will these FULLY executve before a
> publish app launches, or will an app try to launch while these execute?  As
> it is now, just using logon scripts pecified in users tab in ADU&C, the app
> might launch before the logon script finished.
>
>  ________________________________
>  From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On
> Behalf Of Joe Shonk
> Sent: Friday, November 18, 2005 4:59 PM
>
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Remapping network drive on every login
>
>
>
>
>
> How about simply using usrlogn1.cmd?
>
>
>
> If you want to centralize the script then call the script from a network
> share.
>
>
>
> Usrlogn1.cmd:
>
> Call \\server\citrix\scripts\zone1.cmd
>
>
>
> Map/delete/whatever in the zone1.cmd or zone2.cmd, etc..
>
>
>
>
>
>  ________________________________
>
>
> From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf
> Of Jeff Pitsch
> Sent: Friday, November 18, 2005 2:41 PM
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Remapping network drive on every login
>
>
>
> Ack, you do login scripts through the user properties.  Didn't expect that.
> The GPO scripts, I believe, run after the user scripts.  I may be wrong on
> that though.
>
>
> On 11/18/05, Evan Mann <emann@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> Accomplishing this by running a script at login in the GPO, instead of the
> traditional login script?  Does the scripts in GPO process before or after
> the logon script?
>
>
>  ________________________________
>
>
> From: thin-bounce@xxxxxxxxxxxxx [mailto: thin-bounce@xxxxxxxxxxxxx] On
> Behalf Of Jeff Pitsch
> Sent: Friday, November 18, 2005 3:57 PM
> To: thin@xxxxxxxxxxxxx
> Subject: [THIN] Re: Remapping network drive on every login
>
>
>
>
>
> why not seperate the servers into seperate OU's and get rid of the logic in
> the script.  Based on what OU the server is in, the user gets the correct
> script.
>
>
>
>
>
> Jeff Pitsch
>
>
>
>
> On 11/18/05, Evan Mann <emann@xxxxxxxxxxxxxxxxxxxxx > wrote:
>
> I have an application that runs on 2 different zones and uses the same
> network drive (R:).  At each zone, that R: drive is different and there are
> users that use this app at both zones.
>
>
>
> I have login scripts set to delete and re-create that R: drive based on what
> Citrix server they connect too (I check %computername%).  This causes issues
> where an app launches before the drive re-connects.  I can think of two ways
> to permanently fix this
>
> 1) Publish the app with a .cmd file and remap the login drive in the app and
> then launch the app
> 2) Enable run logon script synchronously
>
> The cmd files means I have to maintain these files on multiple servers
> manually, more overhead.  Enabling synchronous logon scripting has potential
> for heavy delays.
>
> Now, my actual logon scripts are fairly basic, map some network drives, run
> a .reg key, nothing fancy. I'm not deploying software via login scripts, so
> I don't think I'd ever hit a situation where the login script is chowing
> away for a long time, keeping the user from working.
>
> I'm looking for advice from other as to which route I should take, or for
> other suggestions.
************************************************
For Archives, RSS, to Unsubscribe, Subscribe or
set Digest or Vacation mode use the below link:
//www.freelists.org/list/thin
************************************************

Other related posts: