1

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.

5
  • 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. Nov 1, 2011 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, 2011 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. Nov 2, 2011 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, 2011 at 21:03
  • Have you tried specifying the fully qualified server name? Nov 3, 2011 at 21:41

2 Answers 2

2

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.

0

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"): http://technet.microsoft.com/en-us/library/cc766208%28WS.10%29.aspx

The launchapp script: http://blogs.technet.com/b/elevationpowertoys/archive/2010/05/25/uac-logon-scripts-and-the-launchapp-wsf-workaround.aspx

2
  • 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, 2011 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. Nov 2, 2011 at 21:28

You must log in to answer this question.

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