1

Each user on our new domain needs to have drives mapped according to a batch file. The problem is, I have a GPO rule set to execute the following command on all domain logins:

\\servername\netlogon\%username%.bat

Executing this after the session has started works, but for some reason it wont automatically map the drives as outlined in the batch file. I have also put the login scripts in the default folder "\WINDOWS\sysvol\sysvol\domain.name{GUID}\User\Scripts\Logon" with the following command to be executed:

logon.bat

which contains an entry to run %username%.bat, and this does not work either. I am running Windows SBS 2011. Any ideas?

Thanks, Alex

4 Answers 4

1

The first way you tried, specifying the script name with "%username%" in it probably won't fly. I'm fairly certain that environment variable expansion inside the "Scripts" Group Policy Client Side Extension (CSE) won't work. I don't have any documentation that says one way or the other, but I'd find it highly dubious.

The second way you're trying, calling a "logon.bat" from the CSE and, in that script, calling "%username%.bat" should work, provided you can get the path to "%username%.bat" right. I'd call it like so:

call %0\..\%username%.bat

That ought to get the "%username%.bat" file located in the same directory as the "logon.bat" script to execute.

Finally, be sure that your users don't have "Administrator" rights if you're running Windows Vista or Windows 7 on your client computers. If you are, and they do, then drives that are "mapped" during the logon script won't be visible in Explorer by default. (You can get some background on that here: Networkmapping script (VBS) Vista doesn't work, XP does)

4
  • 1
    It turns out that the login script was being executed, but there was a permissions problem mapping the drives
    – codewario
    Mar 16, 2011 at 18:57
  • An update: I ultimately ditched the login scripts and used GPOs to map the drives (pushing the proper GPO extensions for Vista and XP workstations, respectively)
    – codewario
    Sep 18, 2015 at 17:04
  • @AlexanderMiles - I'm definitely moving away from scripts, as well. GPP works too well not to use. Sep 18, 2015 at 23:30
  • There are some caveats to GPO methods as well, but for the most part any idiosyncrasies will be described to you in the GP description nowadays or the policy will prompt you that it's making a change or a particular configuration (e.g. when you set a drive to be removed after it's no longer applied it will change the action to Replace, and warn you about it)
    – codewario
    Oct 28, 2015 at 20:19
1

Simply dumping the file into the

"\WINDOWS\sysvol\sysvol\domain.name{GUID}\User\Scripts\Logon"

folder is probably not enough to get the script to run as that GPO doesn't know that that script should run unless it's configured in the GPO. I can't verify that as I've never tried it but I would be surprised if it did.

0

Why not use Group Policy Preferences which maps drives, copies files, and a lot more from the GUI GP Management Console, and works with clients XP or newer? Now a days you need to use login scripts less and less due to GPP.

http://technet.microsoft.com/en-us/library/cc731892(WS.10).aspx

0

You should probably have all users running the same login script that then performs logic to determine what drives to map. In this scenario, its difficult to determine if its a problem with the GPO kicking off the login script or the actual mapping of the drives.

Try running the same login script from the GPO, then in the login scrip reference the %username% variable and kick off the appropriate individual script. This way you can do some logging inside the main login script and see if it's at least making it that far. If it's not, you know it's something with the GPO. If it is, then you can go from there.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .