Darren,
You mentioned that RSOP logs the last execute time of the script. I have
found the column in the RSOP MMC and it is blank (even though the script was
executed). Any ideas where this info is stored? It would be useful to be
able to programatically log in the event of a failure...
On 12/13/06, Darren Mar-Elia <darren@xxxxxxxxxx> wrote:
>
> One of these days I'm going to build a tool for better troubleshooting
> this stuff. The problem is that script execution is actually completely
> separate from Group Policy processing, so all of the normal tools for
> troubleshooting policy problems don't apply. Typically intermittent
> problems in scripts are caused by timing issues. The only thing I might
> suggest is that you put a sleep statement of some kind into your script so
> that it waits a little longer before doing the important stuff.
>
>
>
>
>
> *From:* gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
> *On Behalf Of *Jeremy Hagan
> *Sent:* Tuesday, December 12, 2006 3:27 PM
> *To:* gptalk@xxxxxxxxxxxxx
> *Subject:* [gptalk] Re: logon scripts not running
>
>
>
> Yes the script ALWAYS runs properly when you kick it off manually. In
> fact I have deployed an All Users startup shortcut that detects the absence
> of the mapped drive, kicks off the script from it's sysvol location and then
> collect a bunch of data for troubleshooting purposes. Note the intermittent
> nature of the problem. Most of the time it runs, sometimes it doesn't.
>
> On 12/13/06, *Darren Mar-Elia* <darren@xxxxxxxxxx> wrote:
>
> Jeremy-
>
> That registry entry below, is where Windows looks to figure out which
> scripts to run. If your script is listed there, that means the policy is
> getting processed. If the script is truly not running, then I would agree
> with Jamie—make sure you can run the script interactively first.
>
>
>
> *From:* gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
> *On Behalf Of *Nelson, Jamie R Contr 72 CS/SCBNF
> *Sent:* Tuesday, December 12, 2006 6:28 AM
>
>
> *To:* 'gptalk@xxxxxxxxxxxxx'
> *Subject:* [gptalk] Re: logon scripts not running
>
>
>
> Does the script run as expected when executed manually from SYSVOL? RSOP
> should show you the last time a script was executed by policy, but other
> than that I don't know how you would capture an exit code. I don't think
> your USERENV log would show that, but it might.
>
>
>
>
>
> Jamie Nelson
> ------------------------------
>
> *From:* gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
> *On Behalf Of *Jeremy Hagan
> *Sent:* Monday, December 11, 2006 5:27 PM
> *To:* gptalk@xxxxxxxxxxxxx
> *Subject:* [gptalk] Re: logon scripts not running
>
>
>
> More on this one.
>
>
>
> I have proved that the scrips just don't run when this failure occurs.
> Loggiong shows that there are entires in the Registry under
>
>
>
>
> HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\System\Scripts\Logon\0\0
>
>
>
> For the script in question. I've added logging to that script that logs
> execution to the client's Application event log and when the drives fail to
> map I can't see any events.
>
>
>
> How can I log/monitor the successful or failed execution of a logon
> script?
>
>
>
> PS
>
>
>
> I turned on "Always Wait for the Network" and "Run Logon Scripts
> Synchronously" without any effect.
>
>
>
>
>
> On 12/7/06, *Darren Mar-Elia* <darren@xxxxxxxxxx> wrote:
>
> I think whatever you can do to isolate the problem is a good thing, so
> yes. Also, I wouldn't necessarily trust that Q article below about logon
> script optimization being disabled automatically under those circumstances.
> It can't hurt to enable it, in any case.
>
>
>
> *From:* gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
> *On Behalf Of *Jeremy Hagan
> *Sent:* Wednesday, December 06, 2006 2:41 PM
>
>
> *To:* gptalk@xxxxxxxxxxxxx
> *Subject:* [gptalk] Re: logon scripts not running
>
>
>
> Yes I've thought about it (in fact I was just reading about it in your
> book as we speak), but I was hoping to have some better troubleshooting to
> nail down the issue before I go making tweaks. Do you think it is
> worthwhile separating the login script into a GPO of its own?
>
> On 12/7/06, *Darren Mar-Elia* <darren@xxxxxxxxxx> wrote:
>
> How about trying to set the policy that forces scripts to run
> synchronously? Its under computer config\admin templates\system\scripts\
>
>
>
> *From:* gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
> *On Behalf Of *Jeremy Hagan
> *Sent:* Wednesday, December 06, 2006 2:20 PM
> *To:* gptalk@xxxxxxxxxxxxx
>
>
> *Subject:* [gptalk] Re: logon scripts not running
>
>
>
> Gents,
>
>
>
> A few extra points:
>
>
>
> According to the q305293, Fast Logon Optimisation is always off when the
> following conditions exist:
>
> - When a user has a roaming user profile,a home directory, or a
> user object logon script.
>
> In our case the user has all of these things, so I guess Fast Logon
> Optimisation isn't in effect even though the particular policy is set to
> "Not Configured"
>
>
>
> On the second point of the script running or not, as I previously
> stated, we have put in a second script that simply logs the time and date to
> a text file on the workstation's C: drive. When the symptom occurs, this
> script has also failed to run.
>
>
>
> Any more ideas?
>
>
>
>
>
> On 12/7/06, *Nelson, Jamie R Contr 72 CS/SCBNF* <
> Jamie.Nelson.ctr@xxxxxxxxxxxxx> wrote:
>
> Jeremy,
>
>
>
> Darren is right. This is usually the result of a race condition that
> occurs when the Scripts CSE tries to run a remote script before the network
> has come up. It happens a lot when using gigabit adapters because they
> sometimes take a little longer to negotiate their link speed. Check out the
> following KB article.
>
>
>
> Group Policy application fails on a computer that is running Windows
> 2000, Windows XP Service Pack 1, or Windows XP Service Pack 2
> <http://support.microsoft.com/kb/840669>
>
>
>
> You may also need to disable Fast Logon Optimization for your Windows XP
> clients (since it is by default turned on). This is more commonly known as
> the "Always wait for the network at computer startup and logon" option in
> Group Policy.
>
>
>
> Description of the Windows XP Professional Fast Logon Optimization
> feature <http://support.microsoft.com/kb/q305293/>
>
>
>
> We setup one GPO that disables Fast Logon Optimization for Windows XP
> and also implements the GpNetworkStartTimeoutPolicyValue setting described
> in KB840669. It seems to have fixed many of our problems, and even though GP
> processing on our XP clients take a little longer at startup/logon, it is
> worth it to know that your scripts are being applied consistently.
>
>
>
> *//signed//**
> **Jamie R Nelson **
> *Systems Engineer
> Ingenium Corporation
> 72 CS/SCBNF
> 405.739.2811 (DSN 339)
> ------------------------------
>
> *From:* gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
> *On Behalf Of *Darren Mar-Elia
> *Sent:* Wednesday, December 06, 2006 9:05 AM
> *To:* gptalk@xxxxxxxxxxxxx
> *Subject:* [gptalk] Re: logon scripts not running
>
>
>
> Jeremy-
>
> The funny thing about scripts policy is that the running of the script
> itself is actually totally disconnected from Group Policy processing. All
> the Scripts CSE does is collect the information on which logon scripts it
> needs to run during GP processing. That information is stored in the
> registry and then I believe it's the Userinit process that runs the logon
> script during logon. Typically logon scripts won't run for any number of
> reasons, depending upon what they are doing and other things like the timing
> of the network stack coming up, etc. What I usually suggest is to put some
> kind of logging into your script to find out on which line it stops running
> (or if its running at all). For example, in a batch file, the simplest way
> to do that might be as below:
>
>
>
> Echo y | Net use * /d > %temp%\log.txt
>
> Net use p: \\myserver\public >> %temp%\log.txt
>
>
>
> Etc.
>
> So you get the output of each line in the file and you can look at
> log.txt to see what happened.
>
>
>
> Let us know if you need more info.
>
>
> Darren
>
>
>
> *From:* gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx]
> *On Behalf Of *Jeremy Hagan
> *Sent:* Tuesday, December 05, 2006 5:01 PM
> *To:* gptalk@xxxxxxxxxxxxx
> *Subject:* [gptalk] logon scripts not running
>
>
>
> Hello All,
>
>
>
> Ever since I have been putting in AD (since 2002) I have noticed the
> problem where GPO logon scripts intermittently don't run. I've never
> bothered troubleshooting it since it is so intermittent and not repeatable.
> I work for a systems integration company so I'm not talking about 1 AD, but
> many.
>
>
>
> Anyway, I'm currently working at a site that has been having this
> problem since they put in AD about 2.5 years ago and I've taken up the
> challenge to solve it.
>
>
>
> The domain is Windows 2003, native domain and forest, that has been
> upgraded from Windows 2000 AD, but no DCs remain that ever ran Windows 2000.
>
>
>
>
> The login script is a VBscript that runs from a general purpose user
> policy that has settings in folder redirection, and Admin Templates, but not
> in IE maintenance.
>
>
>
> We have added a second logon script that is just a batch file that logs
> the fact that the script ran to a text file.
>
>
>
> When the vbscript fails to run, the batch file also fails to run.
>
>
>
> - We have disabled Group Policy Slow Link Detection
> - We have enabled the "Allow processing across a slow network
> connection" under the "Scripts Policy Processing" option
> - We have enabled the "Process even if the Group Policy objects
> have not changed" under the "Scripts Policy Processing" option
>
> Servers run WS03 SP1 and clients run WinXP SP2.
>
>
>
> We have enabled userenv logging and I can see that policy processing is
> occuring for the particular policy that has the logon script, it just isn't
> running the script.
>
>
>
> I have set up a batch file in the startup folder that detects the
> absence of a mapped drive and collects the Userenv.log, the last 100
> System and Application Event log entries, and a few regitry keys and other
> log files as well as emailing me to let me know it fired off.
>
>
>
> A sample userenv.log can be provided on request. Over to you guys!!
>
>
>
> Cheers,
>
> Jeremy.
>
>
>
>
>
>
>
>
>
