login scripting

[Guest]

<Cross posted from 2000 discussion>

We are in the process of moving from mainly a NetWare shop, to a total MS
shop.

We have created some batch files to map certain network drives... simple
file, just a bunch of

net use x: \\blah\blahblah

What I'm seeing is as follows:

When a machine is initially booted up, the script runs fine, and any
applications that are in the startup group load with no problems.

However, if a user logs off (rather than restart), and someone else (or same
user) logs on again, the startup items will not load, because the drive
mappings have not completed yet. Get the typical windows pop-up, saying
"such-n-such app could not be found".

Once the login script completes, the apps load fine, however the users are
getting frustrated with manually having to load the apps.

Coming from a NetWare background, I have to say that the lack of an actual
scripting language is a bit disappointing.

One thing I have noticed that doesn't seem to work is setting environment
variables in the script.

Anyone have any thoughts or suggestions on this?

 

[Oli Restorick [MVP]]

This doesn't make sense, unless you're using Windows 98 or something equally
horrid on the clients.

Which client OS are you using?

Oli

 

[Guest]

DC Servers are Windows 2003 Server. We have a mix of W2K and a couple of
NT4.0 servers as well. Clients are Win 2000 Pro, and a few Win XP clients.

I observe the minimized login script on the task bar, while the system is
already starting to process startup group items. This problem has been
consistent on at least a half dozen different W2k Pro/XP Pro systems.

The difference between a "restart" and a "logoff/logon" seems to be that
during a restart, the system is still starting up services during the login,
whereas with a logoff/logon, all services are already running, so the system
gets started on the startup items more quickly.

I've noticed that items in startup that use UNC don't experience this
problem, but we still have quite a few legacy apps, which require a mapped
drive to run.

 

[Oli Restorick [MVP]]

I see.

Personally, I've never been a fan of user login scripts. I use computer
startup scripts extensively.

If you want an alternative approach, you could use Group Policy to do the
drive mappings. It's a little unconventional, but I've found it to work
absolutely flawlessly.

Try this out on a test OU first. Create a GPO and import the ADM file into
it. You'll need to change the filtering in the admin tool so that it shows
you all GPOs, not just fully-managed ones.

http://www.willowhayes.co.uk/download/drives.adm

Then you'll find that under Administrative templates, you have a Drive
Mappings category. If you don't see a bunch of drive letters, check the
filtering.

Type the UNC, leave "Connect As" blank and choose the Microsoft Windows
Network option for the provider type.

You can then map drives depending on OU. You can also use security groups
to filter the GPO.

This works nicely because it gets processed very early on and when Explorer
fires up, it just thinks it has a load of persistently-mapped drives.

The other thing I do is to create a GPO called "Clear all drive mappings"
that gets processed first. This just deletes every drive mapping, so that
only the ones defined in Group Policy get mapped.

Hope this helps

Oli

 

[Guest]

Thanks for the advice. Hadn't thought of GPO as a solution. Not sure what you
are talking about with startup scripts. How does that differ from login
script?

 

[Oli Restorick [MVP]]

I'm sure you had computer startup scripts in Netware. Anyway, they run when
the computer starts up and logs in to the domain (yes, computers log in just
like users do). These scripts run in the security context of the machine,
not as a user. Therefore, if you're accessing network resources in such a
script, you need to ensure that the "domain computers" group has the
required access.

Hope this helps

Oli

 

[Ed Siff]

A group policy setting can prevent this:

"If you enable this policy, Windows Explorer does not start until the logon
scripts have finished running. This setting assures that logon script
processing is complete before the user starts working, but it can delay the
appearance of the desktop."

It's Local Computer/Computer Config/Admin Templates/System/Logon/
Run logon scripts synchronously. Change it to Yes.

Ed

 

[Guest]

Oli,

Thanks for all the assistance. I've been playing with doing it through GPO.
Seems to be working great. Got one small issue with it that I'm trying to
work through, one one drive. Maybe you have some insight on it as well... I
think it's more of a netware issue.

When we were doing it with login scripts, we had a series of

net use x: \\server\share statements

One particular server (even though they are all in the same NDS tree) was
not allowing us to map this way.

We found a workaround by using

net use x: \\server\share /user:%username%.kf (fully qualified NDS name vs
user the logon name)

I'm seeing this same issue mapping to this server via the GPO object. I
tried putting the %username%.kf in the connect as field, but it didn't work.

I came up with a temp work-around by just putting a specific username.kf in
the connect as field... but don't really want all logons to the server to use
the same credentials.

Any suggestions on how to use the %username% variable and append the .kf to
the end of it?

Thanks again for all the assistance you've provided on this.

 

[Oli Restorick [MVP]]

You're welcome.

It's a long time since I've touched Netware, and when I did it was 3.12 or
4.11 running with Bindery emulation, nut full NDS.

I've always left the username field blank with that GPO. It worked OK for
the versions of Netware I used at the time and for Windows.

If you take a look at the ADM file, you'll see that the UNC path has
"EDITTEXT EXPANDABLETEXT" as its type and the username field is just an
EDITTEXT type. This determines whether the registry value is a REG_SZ or a
REG_EXPAND_SZ type. The latter supports environment variable expansion,
whereas the former doesn't. However, the program in question needs to be
written to allow this. Some software does and some doesn't.

You might like to try changing the ADM file to add an EXPANDABLETEXT entry
on the username field and seeing if it does the trick.

To see what gets created in the registry, take a look at HKCU\Network.

I'd be interested to know what you find.

Cheers

Oli

 

[Guest]

The modification to the ADM file did the trick. I'm now able to specify the
username with %username%.ou.ou etc convention, and it is correctly expanded,
and the drive maps flawlessly. Now, all I've got to do is create GPO's for 35
departments. Thanks for all your assistance, makes my job a lot easier now.

 

[Oli Restorick [MVP]]

Thanks for the feedback. Glad it all worked out. Once you get this method
up and running, it really does make things easier and gives the users a very
quick login.

Regards

Oli