![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
And so, yesterday I discovered that since all our sites are now part of
one domain, that means all the login scripts are jumbled up together.
(Remind me... WHY are we embarking on this unecessary complexity?)
Clearly I'm going to have to rename the UK ones to disambiguate them
from the rest. However, while I'm looking around, I had a look at the
logon scripts used by some of the other sites...
Now, the UK uses 4 different logon scripts, depending on what you need
access to. Each script is an MS-DOS batch file that looks something like
this:
@ECHO OFF
NET USE J: \\uk-bigbox\department /persistent:no
NET USE R: \\uk-bigbox\results /persistent:no
NET USE M: \\uk-bigbox\management /persistent:no
The longest login script is 7 lines long. Basically each group of people
have access to more or fewer network drives, and when I create a user
account, I set it to run the appropriate script at logon.
I had a look at the script run by the people at HQ. JESUS CHRIST!! o_O
Fact #1: It's VB. (!!) I didn't even know you could *do* that!
Fact #2: It's 318 lines long. (!!!!!!)
I don't even want to guess how long it takes these people to log in...
Between starting up the entire VB subsystem and running several hundred
lines of code through an interactive interpretter, it can't be very fast!
As best as I can tell (I don't really comprehend VB), this script does
the following:
1. Figure out if M$ Office is installed. (??)
2. Load the user's real name data out of Active Directory. (?!)
3. Reconfigure the User Name and Initials data in M$ Office (?!!!!)
4. Determine which security groups the user has been assigned to in
Active Directory.
5. Iterate through that list, and call about 30 different subroutines
based on group membership. (!!)
6. Each subroutine checks for the existence of various network drive
mappings, deletes them if they exist, and then maps them.
7. Delete some old shortcuts from the desktop and copy some new ones.
8. Quit. (At last!!)
The entire thing is one giant monolithic blob of code. And it's not even
like there's a subroutine for the "check if this drive is mapped, delete
the existing mapping, map it to this" procedure. It's actually been
cut-and-pasted 25 times or something. (The REM statements at the top
indicate that the script was auto-generated by some scripting tool - but
modifications further down indicate that the script has since been
edited by hand...)
Suddenly Mr IT's "I want there to be one login script for each site"
makes chilling sense... o_O
(Hmm, I wonder... Does having a VB login script work for Windows NT?)
Clearly they're mapping *way* more drives than we are; the listing shows
at least a dozen, whereas we have a maximum of about 5. But even so,
what they're doing seems like massive, massive overkill to me...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> And so, yesterday I discovered that since all our sites are now part of
> one domain, that means all the login scripts are jumbled up together.
> (Remind me... WHY are we embarking on this unecessary complexity?)
>
> Clearly I'm going to have to rename the UK ones to disambiguate them
> from the rest. However, while I'm looking around, I had a look at the
> logon scripts used by some of the other sites...
>
> Now, the UK uses 4 different logon scripts, depending on what you need
> access to. Each script is an MS-DOS batch file that looks something like
> this:
>
> @ECHO OFF
>
> NET USE J: \\uk-bigbox\department /persistent:no
> NET USE R: \\uk-bigbox\results /persistent:no
> NET USE M: \\uk-bigbox\management /persistent:no
>
> The longest login script is 7 lines long. Basically each group of people
> have access to more or fewer network drives, and when I create a user
> account, I set it to run the appropriate script at logon.
>
> I had a look at the script run by the people at HQ. JESUS CHRIST!! o_O
>
> Fact #1: It's VB. (!!) I didn't even know you could *do* that!
>
> Fact #2: It's 318 lines long. (!!!!!!)
>
> I don't even want to guess how long it takes these people to log in...
> Between starting up the entire VB subsystem and running several hundred
> lines of code through an interactive interpretter, it can't be very fast!
>
> As best as I can tell (I don't really comprehend VB), this script does
> the following:
>
> 1. Figure out if M$ Office is installed. (??)
> 2. Load the user's real name data out of Active Directory. (?!)
> 3. Reconfigure the User Name and Initials data in M$ Office (?!!!!)
> 4. Determine which security groups the user has been assigned to in
> Active Directory.
> 5. Iterate through that list, and call about 30 different subroutines
> based on group membership. (!!)
> 6. Each subroutine checks for the existence of various network drive
> mappings, deletes them if they exist, and then maps them.
> 7. Delete some old shortcuts from the desktop and copy some new ones.
> 8. Quit. (At last!!)
>
> The entire thing is one giant monolithic blob of code. And it's not even
> like there's a subroutine for the "check if this drive is mapped, delete
> the existing mapping, map it to this" procedure. It's actually been
> cut-and-pasted 25 times or something. (The REM statements at the top
> indicate that the script was auto-generated by some scripting tool - but
> modifications further down indicate that the script has since been
> edited by hand...)
>
> Suddenly Mr IT's "I want there to be one login script for each site"
> makes chilling sense... o_O
>
> (Hmm, I wonder... Does having a VB login script work for Windows NT?)
>
> Clearly they're mapping *way* more drives than we are; the listing shows
> at least a dozen, whereas we have a maximum of about 5. But even so,
> what they're doing seems like massive, massive overkill to me...
I feel your pain, my poor Windows server friend...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
nemesis wrote:
> I feel your pain, my poor Windows server friend...
With a nemesis like this, who needs friends?
Or... something... LOL!
Yeah, well, this scripting insanity hasn't been inflicted on *me* yet,
so that's not too bad. ;-) I guess if they do try, I can just set the
7-line script to be everybody's login script, and be done with it.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> nemesis wrote:
>
> > I feel your pain, my poor Windows server friend...
>
> With a nemesis like this, who needs friends?
LOL
> Yeah, well, this scripting insanity hasn't been inflicted on *me* yet,
> so that's not too bad. ;-) I guess if they do try, I can just set the
> 7-line script to be everybody's login script, and be done with it.
I'm sure you can, or at least manage it down a lot -- sure there must be a
better way! Don't ever doubt the incompetence of average Windows box
sysadmins, specially against a wise Haskeller... :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> I'm sure you can, or at least manage it down a lot -- sure there must be a
> better way! Don't ever doubt the incompetence of average Windows box
> sysadmins, specially against a wise Haskeller... :)
Heh. Well *apparently* I suck at Haskell. According to some guy who has
been described as "a known troll on the Scheme forums", and who
describes himself as "evil".
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
>> I'm sure you can, or at least manage it down a lot -- sure there must
>> be a
>> better way! Don't ever doubt the incompetence of average Windows box
>> sysadmins, specially against a wise Haskeller... :)
>
> Heh. Well *apparently* I suck at Haskell. According to some guy who has
> been described as "a known troll on the Scheme forums", and who
> describes himself as "evil".
who's that?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Heh. Well *apparently* I suck at Haskell. According to some guy who
>> has been described as "a known troll on the Scheme forums", and who
>> describes himself as "evil".
>
> who's that?
Just some guy on the Haskell mailing list.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible escreveu:
>>> Heh. Well *apparently* I suck at Haskell. According to some guy who
>>> has been described as "a known troll on the Scheme forums", and who
>>> describes himself as "evil".
>>
>> who's that?
>
> Just some guy on the Haskell mailing list.
It's been a while since I've roamed the c.l.* newsgroups and some
mailing lists. Seems I've been missing much fun! :D
There was an annoying Ruby enthusiast at the CLisp newsgroups. oh, it
was fun... :)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> NET USE J: \\uk-bigbox\department /persistent:no
> NET USE R: \\uk-bigbox\results /persistent:no
> NET USE M: \\uk-bigbox\management /persistent:no
Might I wonder why you don't just user /persistent:yes and not run the
script at every login? Last I looked, Windows maps the drives when you log
in, and unmaps them when you log out... Is this some domain funkiness?
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New wrote:
> Invisible wrote:
>> NET USE J: \\uk-bigbox\department /persistent:no
>> NET USE R: \\uk-bigbox\results /persistent:no
>> NET USE M: \\uk-bigbox\management /persistent:no
>
> Might I wonder why you don't just user /persistent:yes and not run the
> script at every login? Last I looked, Windows maps the drives when you
> log in, and unmaps them when you log out... Is this some domain funkiness?
The reason: If I ever need to *change* the drive mapping, I can just
adjust the login script. However, if instead you make the drive mappings
permanent, this doesn't work.
(Indeed, Windows NT *defaults* to temporary mappings, so the switch was
unecessary. However, Windows XP defaults to persistent, hence the need
for me to add that switch.)
The [vastly more complex] VB script they're using at HQ tests for and
deletes any existing mappings, which also achieves the same job.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |