[THIN] Re: Remapping network drive on every login
- From: Jeff Pitsch <jepitsch@xxxxxxxxx>
- To: thin@xxxxxxxxxxxxx
- Date: Fri, 18 Nov 2005 16:40:38 -0500
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.
> >
>
>
Other related posts:
