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:


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:


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

Thanks, Alex


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)

| improve this answer | |
  • 1
    It turns out that the login script was being executed, but there was a permissions problem mapping the drives – Bender the Greatest Mar 16 '11 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) – Bender the Greatest Sep 18 '15 at 17:04
  • @AlexanderMiles - I'm definitely moving away from scripts, as well. GPP works too well not to use. – Evan Anderson Sep 18 '15 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) – Bender the Greatest Oct 28 '15 at 20:19

Simply dumping the file into the


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.

| improve this answer | |

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.


| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.