Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have several Windows Server 2003 Environments I administer. These are separate disparate domains with their own structures and policies. I generalize as much as possible when I administer these environments, so I have a suite of general scripts I dump into a network share on each server that is in the same location, regardless of domain.

I use Group Policy to assign that script to each workstation, but since it is the same set of directories regardless of server I can just dump a file across the board to get the same changes across multiple domains.

Under Windows XP, this works fine, scripts run with no problems from directories other then the NETLOGON share.

Now we are migrating to Windows 7, and I find that scripts no longer execute from any other share than the NETLOGON share.

Is there something I am missing, or is there a setting I can configure in Group Policy that will allow these Windows 7 workstations to execute their scripts outside the NETLOGON Share?

I am not able to update our servers to Server 2008 at this time, this is strictly a Windows 7 upgrade for the workstations.

share|improve this question
I'm thinking some kind of access permission problem. As a troubleshooting step, try pointing a test workstation at a script on local disk (which should work) and then see if that script can access the share that your scripts are sitting on. – Harry Johnston Nov 1 '11 at 20:30
So I created a simple batch file on the local machine that would copy the contents of the script share down to the local HD. The script worked and copied everything without a problem, so I don't think it is an access issue. – Laranostz Nov 2 '11 at 16:05
How exactly are you specifying the path to the script? Please show us the actual text from one of the group policy entries. – Harry Johnston Nov 2 '11 at 21:30
I'm not sure what you mean in this case. The path is just a simple UNC path. In the 'Startup script' group policy and goes to the following. \\(servername)\AD_Scripts$\(scriptname.bat) – Laranostz Nov 3 '11 at 21:03
Have you tried specifying the fully qualified server name? – Harry Johnston Nov 3 '11 at 21:41

If you are using a startup script, you need to give the Domain Computers group permission in the share and NTFS permissions. Startup scripts run in the context of the SYSTEM account. Your tests that you've run manually will run in the context of whatever the logged on user is.

You can test this manually by running psexec -s cmd which will launch an interactive command prompt as the SYSTEM user.

share|improve this answer

This may be due to a "feature" of User Account Control. Basically administrative user logon scripts run with full privileges, but explorer runs with limited privileges so it can't see the drives mapped with full privs. To work around it you need to use a wrapper script to create a scheduled task that will run the login script after the user logs on.

Explanation of the issue (Scroll down to "Group Policy Scripts can fail due to User Account Control"):

The launchapp script:

share|improve this answer
This explains some of the behaviors in regards to logon scripts, but I am also using Startup scripts. It looks like the Startup scripts are not functioning from those non-NETLOGON shares either. – Laranostz Nov 1 '11 at 20:33
@Laranostz, we use startup scripts on Windows 7 machines that are not on a NETLOGON share, so they at least certainly can work. – Harry Johnston Nov 2 '11 at 21:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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