views:

3888

answers:

2

I have just upgraded our company's domain controller from NT 4.0 to Windows 2008 Server. I used the in-place upgrade path, going first from NT 4.0 to Windows 2003 Server and then 2003 Server to 2008 Server. The orginal NT 4.0 domain was name Company. The new domain is Company.local. I have confirmed user and computer information was properly migrated, and the new domain has been in operation for a week with very few issues.

The problem I am having right now is with setting up a GPO user login script for a set of users. I believe I have set up the GPO correctly, but the script does not get executed on the client after login.

Upon investigation, I noticed I could execute the script (batch file) from the client manually after login if I navigated directly to the domain controller: \\*ServerName*\SysVol\*Company*.local\Policies\{GUID}\User\Scripts\Logon

However, if my understanding is correct, this path is not used by the client when executing the login sript, but instead the domain (forest?) name is used as the source (domain and forest name are the same in this case): \\*Company*.local\SysVol\*Company*.local\Policies\{GUID}\User\Scripts\Logon

When manually executing this batch file from the client I get a "Open File - Security Warning" dialog claiming the client cannot verify the publisher. The two paths above are essentially the same place, just accessed with different paths.

Any idea why the clients do not trust content from their own domain controller when accessed via \\*Company*.local and not \\*ServerName*? Are there any other places I should be looking for the probable cause?

+1  A: 

The security warning is very likely a red herring. We can go into why it's coming up, but I'm more interested in talking about the script executing during logon first.

Logon to a client computer with a user account that should be executing the script and run the "Resultant Set of Policy" tool (from a blank MMC, add the "Resultant Set of Policy" snap-in, then highlight and right-click the "Resultant Set of Policy" in the scope pane and choose "Generate RSoP Data..." Take all defaults...)

I'm assuming you haven't played with the NTFS ACLs on the script or the ACLs on the GPO itself.

My gut says that this is a GPO scoping issue. Have a look, after you've gathered the policies, and see if the script is being placed in the list of scripts to be executed for the user. Right-click the "User Configuration" node in the scope pane, after you've gathered the RSoP data, and examine the list of GPOs associated with the user. Do you see the GPO containing your script in that list?

Assuming you do see the GPO applying and do see the script listed in the logon scripts to be executed for the user, I'd head over to the Application Event Log next and see if USERINIT is logging anything during logon about problems executing the script.

Assuming you don't see your GPO applying to the user, I'd think about where you have the GPO linked in relation to the user accounts (this is the "scoping issue" I spoke about). The GPO must be linked at the OU the user object is located within, at a parent OU of the OU the user object is located within, at the top of the domain, or at the site object associated with the IP subnet from which the client computer's IP address has been assigned.

If this doesn't make sense and you're still not seeing what you'd expect, post some description of the logical topology of the objects in question-- i.e. a tree diagram showing the domain, and any child OU's that contain the user objects in question, and an annotation about where you linked the GPO.

Evan Anderson
You nailed it on the head. The security warning was misleading, and the real problem was a GPO scoping issue as you suggested.
Joe Waller
A: 

I recently had the exact same issue. I did find that the script ran, but "invisible". there is a option on the GPO to run scripts "visibly" by going to "Administrative Templates", "System", "Scripts"

Quentin