Discussion:
Logon scripts don't run at all
(too old to reply)
!TG
2005-06-03 14:35:08 UTC
Permalink
I've setup batch files just as I have on an NT server running a
different domain and I've tried a vbs file but none seem to run at all.
I setup OUs and created users in them and setup a group policy in the OU
and applied it on the User settings and also tried computer settings
with no success. I also put the batch file on the profile page of the
user properties.

These are simple scripts to map drives. I can manually run the commands
on the machine.
The user is a normal user with no special permissions but does have
rights to the folder to which I am trying to map. I also added the user
to the administrators group with no luck.
The vbs script has the following in it:
If Not MapDrive("Q:", "\\server\data") Then
MsgBox "Unable to Map Q: to Data"
End If

Please, help, this is becoming very frustrating.
Paul Williams [MVP]
2005-06-03 16:48:14 UTC
Permalink
Can you manually run the scripts from the NETLOGON share?

Probably a connectivity/ name resolution issue...
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
!TG
2005-06-03 17:03:22 UTC
Permalink
Post by Paul Williams [MVP]
Can you manually run the scripts from the NETLOGON share?
Probably a connectivity/ name resolution issue...
I can run the batch files without a problem.
The VBS gave me the following error: Type mismatch: 'MapDrive'
Paul Williams [MVP]
2005-06-03 17:13:08 UTC
Permalink
The VBS is invalid that's why.

Have a look at this as an example of what you want to do:
-- http://www.ss64.com/wsh/drivemap.vbs.txt
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
!TG
2005-06-03 19:09:31 UTC
Permalink
Post by Paul Williams [MVP]
The VBS is invalid that's why.
-- http://www.ss64.com/wsh/drivemap.vbs.txt
I took the example and set it to map t: to a share on the server.
When I log onto the server as the user the logon script runs fine.
When I try to log on with my other PC (a laptop) it does not run.
I can run it manually without a problem over the \\server\netlogon share
Paul Williams [MVP]
2005-06-03 20:12:05 UTC
Permalink
What do you mean doesn't run? Is the laptop within scope? Or are you still
trying to use the User Profile? Are there any errors or warnings in the
laptop event logs?
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
!TG
2005-06-03 17:06:47 UTC
Permalink
I must have made a mistake previously. The batch files will run from
the profile screen on the user properties.. I would obviously much
rather use the GPOs if anyone else has any ideas. In the meantime I
continue searching.
Paul Williams [MVP]
2005-06-03 17:15:44 UTC
Permalink
OK so the batch files are working OK. The VBScript isn't because there's an
error in the script.

If you want to use a GPO instead that's fine. Create a new GPO and link it
to the domain. Filter it to a group and add the users that require these
scripts to that group. Now add the scripts via the GPO editor and the show
files button.

Here's how to filter GPO:
-- http://www.msresource.net/content/view/15/47/
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
!TG
2005-06-03 18:19:12 UTC
Permalink
Post by Paul Williams [MVP]
OK so the batch files are working OK. The VBScript isn't because there's an
error in the script.
If you want to use a GPO instead that's fine. Create a new GPO and link it
to the domain. Filter it to a group and add the users that require these
scripts to that group. Now add the scripts via the GPO editor and the show
files button.
-- http://www.msresource.net/content/view/15/47/
Not exactly. The batch files only work from the profiles tab, not from
the GPO. I am sorry if I was not clear on that point.
!TG
2005-06-03 19:39:47 UTC
Permalink
Here a summary of all I have tried so far.
I have about 20 users but I am only testing one (we'll call him mike).
Currently the user has admin rights.
I have created a OU called "Accounts" and created sub-OUs (mike is in
"Administrative").
I created a VBS file called logon.vbs and it is in the
c:\windows\sysvol\sysvol\domain.com\scripts The contents of this script
are at the end of this post.
I have created a folder called mike in a folder called "home folders" on
the d: drive of the server (which we will call "server").
I have shared this folder (mike) as "mike".
I can manually map t: to \\server\mike
I can connect to \\server\netlogon and run logon.vbs and it works.
I can log on to the server directly as mike and the scripts runs.
When I log on to a laptop (the only PC on the network) nothing at all
happens except I get the normal desktop with no script running and no
mapped drive.
All of the following failed
I editted the Default GPO on the domain in a manner I will explain later.
I added a GPO on the "Accounts" OU
I added a GPO on the "Administrative" OU
I created an OU for mike called "special", moved him to it and added a GPO
I only used one of the above on each test, always deleting the last one
before trying another.
I specified the script location in the GPO by browsing to the local
directory (which was replaced automatically by
\\domain.com\sysvol\domain.com\scripts\logon.vbs
I specified it by typing it out as \\server\netlogon\logon.vbs
I editted the permissions of the GPO adding mike specifically (in spite
of the fact that he is in administrators group), granting him read and
"apply group policy"

When I added or edited GPOs I used the following method:
In AD users and computers I right clicked on the OU or domain which I
wanted to set the GPO.
I selected properties.
I selected the Group Policy Tab
I clicked new (or edit for the default domain one), named it and then
clicked edit.
I tried Startup under windows settings\scripts in both the user and
computer configuration branches.

I think that's about it. I appreciate any attempts to help.


The logon.vbs file looks like this:
'-- DriveMap.vbs --

'-- Usage:
'-- cscript DriveMap.vbs <drive:> <fileshare> //NoLogo

'-- e.g. cscript DriveMap.vbs H: \\MyServer\MyShare //NoLogo
'-- or
'-- start /wait /min cscript DriveMap.vbs H: \\MyServer\MyShare
//NoLogo

'-- This script will check and remove any existing connection
'-- to the same drive letter

'-- The START /wait option allows WSH to finish each drive mapping
'-- before starting another

Option Explicit

Dim WshNetwork, oDrives, i, strDrive, strShare

Set WshNetwork = WScript.CreateObject("WScript.Network")
Set oDrives = WshNetwork.EnumNetworkDrives

'strDrive = WScript.Arguments.Item(0)
'strShare = WScript.Arguments.Item(1)
strDrive = "t:"
strShare = "\\server\mike"

wscript.echo " Mapping: " + strDrive + " to " + strShare

DriveMapper strDrive , strShare

Sub DriveMapper(Drive, Share)
For i = 0 to oDrives.Count -1 Step 2

if LCase(Drive) = LCase(oDrives.Item(i)) then
if not LCase(Share) = LCase(oDrives.Item(i+1)) then
WshNetwork.RemoveNetworkDrive Drive, true, true
Else
Exit Sub
End if
End if

Next

WshNetwork.MapNetworkDrive Drive, Share
End Sub

'-- Last Modified: 11th March 2005, Simon Sheppard
'-- based on a script by Jesper Neumann
Paul Williams [MVP]
2005-06-03 20:24:09 UTC
Permalink
Although what you are doing seems fine, I would suggest adding the script to
the default location under the GPO -use the show files dialog and use cut
and paste.

On the laptop I would look for Userenv and Scecli errors and warnings in the
application event log.

I would also like to point out a slight issue in your post:

There's quite a difference between the scripts under computer settings and
user settings. The former is a startup (or shutdown) script and applies to
a computer and runs under the SYSTEM account; the latter is a logon (or
logoff) script and applies to users and runs under the user account context.
Startup scripts run when the computer boots prior to the Ctrl-Alt-Del
Window. Ensure you are only configuring logon scripts, and that the user
objects are inside the container to which you have linked the GPO.
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
!TG
2005-06-03 20:51:38 UTC
Permalink
Post by Paul Williams [MVP]
Although what you are doing seems fine, I would suggest adding the script to
the default location under the GPO -use the show files dialog and use cut
and paste.
On the laptop I would look for Userenv and Scecli errors and warnings in the
application event log.
There's quite a difference between the scripts under computer settings and
user settings. The former is a startup (or shutdown) script and applies to
a computer and runs under the SYSTEM account; the latter is a logon (or
logoff) script and applies to users and runs under the user account context.
Startup scripts run when the computer boots prior to the Ctrl-Alt-Del
Window. Ensure you are only configuring logon scripts, and that the user
objects are inside the container to which you have linked the GPO.
I was just trying the computer settings out of desperation, I have been
focusing on the user settings.

I do get errors in the laptop event log:
Source NETLOGON
Event ID 5719
No windows NT or windows 2000 domain controller is available for domain
THISDOMAIN. The following error occurred: There are currently no logon
servers available to service the logon request.

and
Source BROWSER
Event ID 8021
The browser was unable to retrieve a list of servers from the browser
master \\SERVER on the network etc..
Paul Williams [MVP]
2005-06-03 21:00:55 UTC
Permalink
Don't worry about the latter event -that's not doing much now but does
strengthen the glaring point made by the first -your computer can't find a
DC. This is a DNS issue. Ensure that the laptop is pointing to an internal
DNS server that is authorative for the AD namespace (usually a DC) and then
reboot the machine.

Test that you can find a DC with the following command once you've changed
your DNS server:
nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com

Where domain-name.com is the name of the domain.
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
!TG
2005-06-06 13:26:37 UTC
Permalink
Post by Paul Williams [MVP]
Don't worry about the latter event -that's not doing much now but does
strengthen the glaring point made by the first -your computer can't find a
DC. This is a DNS issue. Ensure that the laptop is pointing to an internal
DNS server that is authorative for the AD namespace (usually a DC) and then
reboot the machine.
Test that you can find a DC with the following command once you've changed
nslookup -type=srv _ldap._tcp.dc._msdcs.domain-name.com
Where domain-name.com is the name of the domain.
I feel like an idiot but I do appreciate the time and patience you
have put into helping me.
I did have an internal server but I overlooked the fact that the
internal server it was using for DNS did not have proper DNS entries for
for domain I was using.
Once that was corrected it worked like a charm.

Thank you very much.
Paul Williams [MVP]
2005-06-06 16:36:45 UTC
Permalink
No need to feel like an idiot!! DNS is the cause of most AD problems. It's
the backbone of AD and has to be working properly; also clients need to be
pointing to the correct DNS servers.

Get DNS sorted, and your directory will chug along nicely with very few
problems...

All the best!
--
Paul Williams
Microsoft MVP - Windows Server - Directory Services
http://www.msresource.net | http://forums.msresource.net
Loading...