Login scripts

[Jason]

Dear all

we are running windows 2000 svr and I need to have my
users mapped networked drives repointed to a different
server when the log on.

I have written a .BAT file called login.bat, to map this
drive using the NET USE command, this batch file works
fine and well when executed localy, and the drive is
mapped and visible in my computer, however when i place it
in to the folder
%SYSTEMROOT%\SYSVOL\sysvol\<domain name>\scripts on the
server and add
%SYSTEMROOT%\SYSVOL\sysvol\<domain name>\scripts\login.bat
to the logon script section of my user propertys in AD
when i log on the drives are not mapped. It seems like
the .bat file is not being called correctly, does anyone
have any ideas..??
TY
Jason

 

[Guest]

Use just Login.bat and not the path to the sysvol share in AD users and
computers that should work

rgds
Steve

 

[Guest]

Steve,
I am having this same issue. It doesn't seem to matter where I put the
login.bat file, the drive does not map. In my case, the login.bat is a
one-liner:
net use R: \\server\share

Same as below, I can run locally and it works fine, but put it on the server
and tell the GPO to point to it, and nothing happens. What are we missing?

 

[Guest]

I have the same issue, it doesn't matter where the script is put, it does not
work.
What are we missing?

 

[ptwilliams]

Where are you putting the scripts guys? And where are you configuring them?
Via GPO or user profile?


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net
______________________________________
I have the same issue, it doesn't matter where the script is put, it does
not
work.
What are we missing?

 

[Ryan Hanisco]

Nos,

1. Make sure the script is visible at \\DomainController\NETLOGON
2. To be sure there is no conflict, add this at the beginning:
NET USE R: \delete
3. Make sure the script runs manually from the Netlogon share mentioned
above
4. The name of the script (e.g., logon.bat) to the Logon Script box in the
user properties. Don't include the path, only the script name.

You should be good to go. Oh, and make sure you didn't do something odd and
change the NTFS or Share permissions for the Netlogon share -- Authenticate
Users should have Read and Execute and the Everyone group should have read
permissions for the Share. These are the defaults.

Ryan Hanisco
MCSE, MCDBA
Flagship Integration Services

 

[Guest]

I first put the script in \sysvol\<domain>\scripts. When the script did not
run, tried it in \sysvol\<domain>\policies\{C9D6F3...}\User\Scripts\Logon.
The script still did not run. It was configured in a GPO for an OU that was
'3 deep', that is ou=A,ou=B,ou=C,dc=domain,dc=com. Only when I moved the GPO
login script configuration to the domain policy did the script run. Oh, and
put the script back in \sysvol\<domain>\scripts.

Further to this, I was not forcing synchronization of my DCs prior to
testing the script, although I did run gpupdate from my machine. Don't know
if this plays into whether or not a script runs, but there it is.

I had hoped to assign the scripts to certain users/computers based on the OU
the script was assigned to, but it didn't seem to work. So I employed
ifmember.exe into the script, and that does fine as well.

Sorry about the duplicate post earlier, but I got an error from
microsoft.com on the first post, and I never saw it appear in the community
yesterday.

So are login scripts pretty much limited to the domain policy GPO, and no
deeper in the tree?

Thanks!
nos

 

[Hank Arnold]

We are in the process of moving a users' network drive from one server to
another. We have a login script
(\\HOSPICE.LOCAL\sysvol\HOSPICE.LOCAL\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\USER\Scripts\Logon\MAIN.CMD

that assigns all the network drives. It has the following in it (among
other lines):

NET USE W: \\SERVER\USERS\%USERNAME% /yes

I need to move just the W: drive. I created a new CMD file:

C:\WINNT\SYSVOL\sysvol\HOSPICE.LOCAL\scripts\NEWMAIN.CMD

and it has:

@ECHO OF
NET USE W: /DELETE /Y
NET USE W: \\userfiles\wdrives\%USERNAME% /yes
:end

After moving the W: drive folder, I open the properties of the user's AD
account and in the "Logon Script" line of the Profile page I add

NEWMAIN.CMD

After waiting to be sure that the AD change is propagated to the other DC,
logging the user on results in their getting the correct W: drive (after the
initial error message about not being able to connect the W: drive).

Hope this helps......