GPO not being applied.

Posted on 2006-05-10
Medium Priority
Last Modified: 2008-01-09
Ok, this is getting rediculous and I'm about ready to pull out what little hair I have left.

This is a continuation of, or is related to, a previous problem that was resolved. (http://www.experts-exchange.com/Operating_Systems/Windows_Server_2003/Q_21843687.html)

I'm racking my brain to find out why a GPO-based login script is NOT running on my personal workstation. I have to run the "test" version of our domain login script to ensure there are no "gotchas" before rolling it out to the user community. The previous issue I had was that I was running both login scripts, when I only should have been running one. Now, however, I'm not able to run ANY on my workstation so long as it's configured through group policy. The script runs properly on just about any server that I log in to, but not my workstation.

Here's what I've checked:
1) Using the GPMC, that there are no "computer" policies in effect that would prohibit my machine from running the script in question
2) I've deleted the original GPO that was set up for my own personal account with the "test" script, and created a new one with the only setting being the user logon script.
3) Given myself "full control" permissions to the GPO through the GPMC.
4) I've even ticked the "block inheritance" setting in the GPMC
5) After any change I have performed "GPUPDATE /FORCE" on both the workstation I'm using as well as the domain controller.
6) rebooted more times that I care to admit.
7) Using the GPMC and "Group Policy Results Wizard", I've confirmed that the GPO assigned to my user account is the only one that's being applied when I log in.
8) My user account is NOT a member of "Domain Users", but is a member of "domain admins" and others
9) My computer account is NOT a member of "Domain Computers" but is a member of other groups.
10) When I set the "profile" tab of my user account to run this script, then reboot, then login... the script runs as it should. I have done this without any additional GPOs being applied to my user account.
11) When I remove the script from my "profile" tab, then reboot, then login... the script does not run

I'm sooooo frustrated with this.

I suspect that my XP pro workstation is caching the group policy even after multiple reboots, but I can' be sure.
Question by:in2ative1
  • 5
  • 3
LVL 51

Accepted Solution

Netman66 earned 1500 total points
ID: 16651488
Your Computer must be a member of Domain Computers - for starters.

Your User account must also be a member of Domain Users.

The reason for this is because those groups are members of Authenticated Users - which is required in order to read system information on most things.

On the Delegation tab of the GPO, you (or the security group you are in) only need Read and Apply Group Policy underneath Allow.  Uncheck the box for for Apply Group Policy under Allow for the Authenticated Users group.  That's all that is required - leave everything else at it's defaults.

LVL 51

Expert Comment

ID: 16651531
Also, where are you adding the actual script file?  You should be adding it in the policy so that it's stored in SYSVOL\domain\policies\GUID\User\scripts\logon

Author Comment

ID: 16659993
I've made sure my computer and user accounts are members of those groups. Although the script is not located in "SYSVOL\domain\policies\GUID\User\scripts\logon", it is located in "domain\SYSVOL\domain\scripts". All domain users run the standard (production) script from this directory and it appears to run fine.

Here's something I noticed this morning though. Using the GPMC, I ran another query on "Group Policy Results" for my workstation and my user account. I show the test script listed as the one to run and it even states on the settings tab that it was last run just a few minutes ago. However, the mapped drives and other functions did not run at all when I logged in.

Do you have another other tips? I'm going to put the script in the "SYSVOL\domain\policies\GUID\User\scripts\logon" directory to see if this works, but there really should be no reason the login script is not running for me. You can probably understand why I'm so frustrated.

NEW Veeam Backup for Microsoft Office 365 1.5

With Office 365, it’s your data and your responsibility to protect it. NEW Veeam Backup for Microsoft Office 365 eliminates the risk of losing access to your Office 365 data.


Author Comment

ID: 16660009
Another reminder. The script runs without issue when I log in almost anywhere else on the network. Rebuilding my workstation presents a significant hardship that I have to avoid at all costs.

Author Comment

ID: 16660464
I've added the script to the directory noted in my above comments.
I've even renamed the script and changed the requisite section in the group policy
The "group policy results wizard" states that I am actually running the script, but the script is not running.

This is turning into a huge problem.
LVL 51

Expert Comment

ID: 16660614
On the same GPO, turn off Fastboot.

Computer Config>Admin Templates>System>Logon :: Always wait for the network at computer startup and logon = ENABLED


Author Comment

ID: 16668349
I've turned off fastboot as you suggested and it's still not working. I'm gonna post my problem to the MS public usenet. I may or may not have a corrupt profile that could be stopping the script from running while other settings are being applied. Thanks for your help.

Author Comment

ID: 16669625

Along with not being able to run the login script of my choice, there was another bizarre thing that I thought was a mutually exclusive issue. You know how the "My Documents" folder, on some machines, would pop open any time you'd login? I've had this happen on NTWS as well as 2000 Pro too. It's not a common issue, but it is well documented. Well, my VBS editor of choice was popping open every time I logged in. I attributed this behavior (without researching) to the same faulty settings or screwed up initialization process. To stop this from happening I renamed the executable of my VBS editor to stop it from popping open when I logged in.

Long story short, the VBS editor was popping open with the login script that I've been authoring because of file associations. Errors in the event log should have pointed me in this direction, but I didn't put two and two together. When I logged in, my machine was opening the VBS editor as the default application to handle VBS scripts. The default application was actually missing in the file associations tab, so I guess it was just going to the next app association.

To solve the problem, I looked at the association for VBE files and made the same association (wscript.exe). After I did that, my login script began to run without issue.

NOTE: In my troubleshooting, I even destroyed my local user profile thinking it was corrupt. I found and fixed the file association using a new profile of my username. When I deleted this new profile and copied in the old one I had saved, the problem reared it's head again. The file association was missing. It would appear that file associations may be saved on a user-by-user basis. I created the file association with this old profile and login script execution came back.


Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This may not be a text book method to resolve VSS backup issues but it seemed to have worked on few of the Windows 2003 servers we had issues while performing a Volume Shadow Copy backup. If you have issues while performing a shadow copy backup usin…
Recently, I had the need to build a standalone system to run a point-of-sale system. I’m running this on a low-voltage Atom processor, so I wanted a light-weight operating system, but still needed Windows. I chose to use Microsoft Windows Server 200…
This Micro Tutorial will teach you how to add a cinematic look to any film or video out there. There are very few simple steps that you will follow to do so. This will be demonstrated using Adobe Premiere Pro CS6.
Screencast - Getting to Know the Pipeline

831 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question