[gptalk] Re: logon scripts not running

  • From: "Jeremy Hagan" <jeremyahagan@xxxxxxxxx>
  • To: gptalk@xxxxxxxxxxxxx
  • Date: Thu, 7 Dec 2006 09:41:26 +1100

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.txtto 
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.



Other related posts: