Can't say the timeout issue has been a problem for us in the last 5 years I've been here. Our scripts are fairly simple and we do try to document.
We've had more problems with machines not getting policies than not getting running their login scripts. -----Original Message----- From: Steve Kradel [mailto:skra...@zetetic.net] Sent: Tuesday, August 09, 2011 7:02 AM To: NT System Admin Issues Subject: Re: Drive mapping via login script I'm a big fan of GPP for drive mappings, and a huge opponent of login scripts unless said login scripts are *absolutely necessary*. The reason for this is that login scripts have an almost irresistible tendency to turn into huge, undocumented, incomprehensible masses of copy+pasted spaghetti code, and are usually written for expediency of doing a task and moving on ("must map this folder for a subset of finance users") rather than weighing the security, cost, time, or fault-tolerance of how it is done. To put it another way, how many login script authors consider the timeout on mapping a drive to a misrouted target, or how long the user must wait if half a dozen drives time out in succession (maybe these could be attempted in parallel, or asynchronously to bringing up the desktop)? Are login scripts kept under source code control, or reviewed by peers? The answer is usually no... --Steve On Tue, Aug 9, 2011 at 9:03 AM, David Lum <david....@nwea.org> wrote: > Nothing is broken, but we dont have any mappings assigned based on > group membership currently so IMO its not scalable. I wanted to get a > feel for what others are doing and not change something to later hear > hey Lum, you should have asked and not gone down that path . If all > I need to do is add IFMEMBER functionality then thats the path of > least resistance, easily done and looks like a viable option. GPP also looks doable and has some cool > factor to it though > > > > Oddly, its usually paths of least resistance I usually have the > biggest doubts about: sure I can do that, but how does that scale, or > work flexibility-wise when a change or audit needs to happen? is > usually my next question. Putting a user name on a folder ACL instead > of creating a group and adding a user to said group and assigning the > group is the model I generally reference. Easy to do the former if > you have 10 people and a couple of folders you want to manage, no so > good if you have 500 users and > 50+ different folder ACLs. > > > > I appreciate everyones input! > > > > Dave > > > > From: Ray [mailto:rz...@qwest.net] > Sent: Monday, August 08, 2011 3:56 PM > > To: NT System Admin Issues > Subject: RE: Drive mapping via login script > > > > We use .bat files and if member. So what doesnt work? > > > > From: kz2...@googlemail.com [mailto:kz2...@googlemail.com] > Sent: Monday, August 08, 2011 7:54 AM > > To: NT System Admin Issues > Subject: Re: Drive mapping via login script > > > > Group policy preferences or AppSense. Never seen any heavy logon lag > as a result of either. > > Sent from my POS BlackBerry wireless device, which may wipe itself at > any moment > > ________________________________ > > From: Cameron <cameron.orl...@gmail.com> > > Date: Mon, 8 Aug 2011 10:48:21 -0400 > > To: NT System Admin Issues<ntsysadmin@lyris.sunbelt-software.com> > > ReplyTo: "NT System Admin Issues" > <ntsysadmin@lyris.sunbelt-software.com> > > Subject: Re: Drive mapping via login script > > > > I use Kix for all my drive mapping (mostly group-based) here. > > On Mon, Aug 8, 2011 at 10:09 AM, David Lum <david....@nwea.org> wrote: > > We use regular .BAT files here for drive mappings, but this doesn't > work for group-based mappings. In my past life I have used KiXtart > which I suppose can implement here easily enough (been 3 years since I > really toyed with it though). I have done some testing of mapping via > GPO and it seems to add a bit of time to the login. > > > > What do you guys use? > > David Lum > Systems Engineer // NWEATM > Office 503.548.5229 // Cell (voice/text) 503.267.9764 > > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
