Scripts and GPOs won't run on some computers

  • Thread starter Thread starter MED
  • Start date Start date
M

MED

Hi,

Our company has a problem with scripts and GPOs that won't run on 20-30
computers (60 computers do not have this problem). All computers run WinXP
SP2.

If you startup an affected computer scripts and GPO do not run, but if you
then login/logout (without restarting) they get GPOs/Scripts.

Anyone have a solution? I've tried the MS-tip when you create the
GpNetworkStartTimeoutPolicyValue and increase the value for wait time before
running GPO.

Thanks in advance
 
In
MED said:
Hi,

Our company has a problem with scripts and GPOs that
won't run on 20-30 computers (60 computers do not have
this problem). All computers run WinXP SP2.

If you startup an affected computer scripts and GPO do
not run, but if you then login/logout (without
restarting) they get GPOs/Scripts.

Anyone have a solution? I've tried the MS-tip when you
create the GpNetworkStartTimeoutPolicyValue and increase
the value for wait time before running GPO.

Thanks in advance
Click to expand...

Can you verify that you are using only the AD DNS in TCP/IP properties?
Are you getting any Event 1000 from source USERENV?
Post the event details, including the error code, if so.
 
MED said:
Hi,

Our company has a problem with scripts and GPOs that won't run on 20-30
computers (60 computers do not have this problem). All computers run WinXP
SP2.

If you startup an affected computer scripts and GPO do not run, but if you
then login/logout (without restarting) they get GPOs/Scripts.
Click to expand...

Sounds like they are USER Logon scripts,
instead of Computer Startup scripts.
Anyone have a solution? I've tried the MS-tip when you create the
GpNetworkStartTimeoutPolicyValue and increase the value for wait time before
running GPO.
Click to expand...

Add them to the other half of the GPO.
 
Only AD TCP/IP is used.

I've had some Event 1000 before but right now it's sunday and I'm not on the
office. I'll get back to you as soon as as possible.
 
Maybe I've done something wrong when configuring, but I don't think so. I
have done this too many times to do this wrong...but of course I'll be happy
for any suggestions. Anyway...I did already set the GP on computers/startup.

If I put a script in Netlogon (and don't use GP at all) it will run on some
computers but not the one's having this problem.
 
MED said:
Maybe I've done something wrong when configuring, but I don't think so. I
have done this too many times to do this wrong...but of course I'll be happy
for any suggestions. Anyway...I did already set the GP on
Click to expand...
computers/startup.

In your earlier post you indicated very clearly
that you don't get the scripts to run on startup of
the computer, but do get them on logon/logoff.

If the script that runs is running during
USER logon but intended for the Computer
startup then it is set in the wrong portion.

If you mean that "other scripts" (not the
same scripts you intended for the computer)
are running then that is a separate issue.
[Although it might give hints.]

It may be that your computer is not authenticating
properly but then it would be (somewhat) odd for
the user to be able to authenticate.

Authentication problems usually turn
out to be DNS problems so I will append
my DNS guide at the bottom.

Another possibility, ESPECIALLY if you
have placed the computer scripts manually,
is that you didn't place PERMISSIONS for
the computer accounts (or Everyone READ,
or Authenticated Users READ).

Check your NTFS permissions on the actual
files in SysVol.
If I put a script in NetLogon (and don't use GP at all) it will run on some
computers but not the one's having this problem.
Click to expand...

NetLogon is usually used for user
"account properties" script and not
for GPO scripts (technically you may
be able to put them there but it is
best to let the GPO editor choose the
location to avoid errors.)

This could be the source of the permission
problem.


--
DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
 
Again, thank you for your fast reply.

I don't mean to sound rude but I really dont't think I've done something
wrong when configuring. I did already put the GPO on computers/startup and
all permissions are ok. As I said in my initial question "only" 20-30
computers/users out of aprox 90 are affected and the config are identical on
every one (exept hardware).

I've heard something about Gbit-NIC:s having this kind of problem and my
next action will be to replace one to see if it helps, but this is really
not a good solution since many affected computers are Laptops so NIC:s will
have to go in the PC-card-slot of the computer and the docking-station's NIC
will not be used (users will have to plug in network cable every day). It's
also an expensive solution.

So once again I'm grateful for every tip.

Thank you!




Herb Martin said:
MED said:
Maybe I've done something wrong when configuring, but I don't think so. I
have done this too many times to do this wrong...but of course I'll be happy
for any suggestions. Anyway...I did already set the GP on
Click to expand...
computers/startup.

In your earlier post you indicated very clearly
that you don't get the scripts to run on startup of
the computer, but do get them on logon/logoff.

If the script that runs is running during
USER logon but intended for the Computer
startup then it is set in the wrong portion.

If you mean that "other scripts" (not the
same scripts you intended for the computer)
are running then that is a separate issue.
[Although it might give hints.]

It may be that your computer is not authenticating
properly but then it would be (somewhat) odd for
the user to be able to authenticate.

Authentication problems usually turn
out to be DNS problems so I will append
my DNS guide at the bottom.

Another possibility, ESPECIALLY if you
have placed the computer scripts manually,
is that you didn't place PERMISSIONS for
the computer accounts (or Everyone READ,
or Authenticated Users READ).

Check your NTFS permissions on the actual
files in SysVol.
If I put a script in NetLogon (and don't use GP at all) it will run on some
computers but not the one's having this problem.
Click to expand...

NetLogon is usually used for user
"account properties" script and not
for GPO scripts (technically you may
be able to put them there but it is
best to let the GPO editor choose the
location to avoid errors.)

This could be the source of the permission
problem.


--
DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

...or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /server:DC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]
Click to expand...
 
It looks like there's been a little confusion with your terminology.

Startup scripts are different to logon scripts. The script section of the
user properties is different again (it's there for backward compatibility -
it's a legacy thing).

Startup scripts are configured through the computer settings of GPO. They
only apply to COMPUTER accounts. They run as SYSTEM.

Logon scripts are configured through the user settings of GPO. They only
apply to USER accounts. They run in the security context of the USER.


Now, with that out in the open, I can't tell whether your having issues with
Logon scripts or Startup scripts? Are you saying that logon scripts only
process on these machines when you logon, logoff and logon again? Are you
saying that computer scripts aren't processing?

This is what Herb was asking? Which is which? The fact that logon scripts
works may help in troubleshooting, but doesn't really tell us much about the
startup script problem.

If startup scripts are the issue, the computer accounts need permissions on
the GPO (authenticated users includes computer objects).

Anyway, regardless, can you answer some questions?

--Are all computers within the scope of this GPO?
--Are all user accounts within the scope of this GPO?
--Are there multiple GPOs?
--Are some machines/ users configured (within scope) of multiple GPOs?
--Have you run RSoP on the dodgy boxes?


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/
 
This is what Herb was asking? Which is which? The fact that logon
scripts
works may help in troubleshooting, but doesn't really tell us much about the
startup script problem.

If startup scripts are the issue, the computer accounts need permissions on
the GPO (authenticated users includes computer objects).
Click to expand...

Yes, AND permissions on the script files themselves
( I am pretty sure ).

[I guess is it possible that the DC reads in the script
and folds it into the GPO stream, but I don't think it
works that way, i.e., I think it is a separate file acces.]
Anyway, regardless, can you answer some questions?

--Are all computers within the scope of this GPO?
--Are all user accounts within the scope of this GPO?
--Are there multiple GPOs?
--Are some machines/ users configured (within scope) of multiple GPOs?
--Have you run RSoP on the dodgy boxes?
Click to expand...

Yes. Are all machines AUTHENTICATED
on their domain?
 
MED said:
Again, thank you for your fast reply.

I don't mean to sound rude but I really dont't think I've done something
wrong when configuring. I did already put the GPO on computers/startup and
all permissions are ok. As I said in my initial question "only" 20-30
computers/users out of aprox 90 are affected and the config are identical on
every one (exept hardware).
Click to expand...

We are not saying you made a mistake, but you
asked for help and we have been seeing (and
making) such mistakes for so long that we almost
always include the obvoius unless you make it
absolutely clear that you have covered that base.

When someone says, "Everything is fine", and
"But I have this problem" my inclination is to
ignore the "Everything is fine" part. <grin>

Many such problems are authentication problems
and most of those are DNS based.

Show us the "ipconfig /all" of a working machine
and a failing machien from the SAME subnet, and
do it by capturing and pasting the text rather than
typing it or pasting a picture. (And be sure to specify
which one is working/not working.)
I've heard something about Gbit-NIC:s having this kind of problem and my
Click to expand...

What kind of problem? Nothing you described
so far sounds like a "NIC" problem of any sort.

Can you ping? Can you resolve names (both
NetBIOS and DNS)?
next action will be to replace one to see if it helps, but this is really
not a good solution
Click to expand...

Mostly because it has such a low probability of helping
until you identify an actual network problem, much less
a NIC generated problem.
since many affected computers are Laptops so NIC:s will
have to go in the PC-card-slot of the computer and the docking-station's NIC
will not be used (users will have to plug in network cable every day). It's
also an expensive solution.
Click to expand...

Those too, but it probably won't help unless you
are being very obscure about describing your
"network" problem.
So once again I'm grateful for every tip.
Click to expand...

Did you check the CLIENT DNS settings?

How about the DCs? (Maybe some clients
are resolving the DCs or SOME DCs are
registered properly...)
 
Wow, many questions back to me. Good!



Herb Martin said:
We are not saying you made a mistake, but you
asked for help and we have been seeing (and
making) such mistakes for so long that we almost
always include the obvoius unless you make it
absolutely clear that you have covered that base.

When someone says, "Everything is fine", and
"But I have this problem" my inclination is to
ignore the "Everything is fine" part. <grin>
Click to expand...

Yeah, I'm aware of that and I'm grateful that you check every possible
source of error. Just wanted to make sure I didn't sound ungrateful in any
way. Ok, enough about this for now ;)

Many such problems are authentication problems
and most of those are DNS based.

Show us the "ipconfig /all" of a working machine
and a failing machien from the SAME subnet, and
do it by capturing and pasting the text rather than
typing it or pasting a picture. (And be sure to specify
which one is working/not working.)
Click to expand...

I'm not at the office right now but I can assure you that they are identical
and that all computers have DC1 as primary DNS and DC2 as secondary DNS. No
more DC:s on the network. Computers gets config from DHCP.

What kind of problem? Nothing you described
so far sounds like a "NIC" problem of any sort.
Click to expand...

That's why I'm confused. But consider this:
1. MS confirms this being a problem:
http://support.microsoft.com/default.aspx?scid=kb;en-us;840669
2. Reading this guys question (and some other just like it) leads me towards
a NIC-problem: http://www.winxptalk.com/ftopic18014.html
This is why I'm considering a NIC-problem.
Can you ping? Can you resolve names (both
NetBIOS and DNS)?
Click to expand...

Sure, no problem there.
Mostly because it has such a low probability of helping
until you identify an actual network problem, much less
a NIC generated problem.
Click to expand...

Se above.
Those too, but it probably won't help unless you
are being very obscure about describing your
"network" problem.


Did you check the CLIENT DNS settings?
Click to expand...

Yes, it's fine and identical with computers not affected by this problem.

How about the DCs? (Maybe some clients
are resolving the DCs or SOME DCs are
registered properly...)
Click to expand...

Only two DC:s and they are fine (as far as i know anyway).
 
ptwilliams said:
It looks like there's been a little confusion with your terminology.

Startup scripts are different to logon scripts. The script section of the
user properties is different again (it's there for backward
compatibility -
it's a legacy thing).
Click to expand...

I use both and affected computers do not run either of them. Unaffected
computers run both.

Startup scripts are configured through the computer settings of GPO. They
only apply to COMPUTER accounts. They run as SYSTEM.

Logon scripts are configured through the user settings of GPO. They only
apply to USER accounts. They run in the security context of the USER.


Now, with that out in the open, I can't tell whether your having issues
with
Logon scripts or Startup scripts? Are you saying that logon scripts only
process on these machines when you logon, logoff and logon again? Are you
saying that computer scripts aren't processing?

This is what Herb was asking? Which is which? The fact that logon
scripts
works may help in troubleshooting, but doesn't really tell us much about
the
startup script problem.
Click to expand...

Se above. I have 90 client computers and aprox 20-30 are affected by the
problem. On computers having this "error" GPOs/scripts run if i logoff and
then logon again, but never if I reboot.

If startup scripts are the issue, the computer accounts need permissions
on
the GPO (authenticated users includes computer objects).

Anyway, regardless, can you answer some questions?

--Are all computers within the scope of this GPO?
Click to expand...
Yes all 90.
--Are all user accounts within the scope of this GPO? Yes.

--Are there multiple GPOs? No.

--Are some machines/ users configured (within scope) of multiple GPOs? No.

--Have you run RSoP on the dodgy boxes?
Click to expand...
No not yet. Will probably have a chance to do that very soon.
 
MED said:
I use both and affected computers do not run either of them. Unaffected
computers run both.
Click to expand...

Now that sounds different that what you first said
but that strongly implies that the computers are
either:

1) Not in the domain

2) Not authenticating

3) Failing name resolution
Se above. I have 90 client computers and aprox 20-30 are affected by the
problem. On computers having this "error" GPOs/scripts run if i logoff and
then logon again, but never if I reboot.
Click to expand...

How about other GPO settings from the SAME
GPO?

Do they take effect when the script "fails" to run?

If not the entire GPO is not being applied which
is either due to one of those items above or due
to permissions likely.
 
In
MED said:
I use both and affected computers do not run either of
them. Unaffected computers run both.
Click to expand...


Just a thought.
One more thing you can check, can you open the domain sysvol DFS share from
the affected clients by the domain name? e.g. \\domain.com\SYSVOL

If you can't, is the TCP/IP NetBIOS Helper service running and set to
Automatic? This is a needed service to connect to DFS shares.
 
Hi Herb,

You have not yet commented my other reply to your post. Think that one may
lead more forward than this one since the reason for error you mention "Not
authenticating" is kinda obvious, but the question is why, and why only when
restarting and not when logging off or logging on?
 
MED said:
Hi Herb,

You have not yet commented my other reply to your post.
Click to expand...
Think that one may
lead more forward than this one since the reason for error you mention "Not
authenticating" is kinda obvious, but the question is why,
Click to expand...

Usually it's DNS related.
and why only when
restarting and not when logging off or logging on?
Click to expand...

More important are the answers to the specific
questions we have asked you.

Your conflicting reports and imprecise reports don't lend
to your receiving effective help, so I will repeat:

How about other GPO settings from the SAME
GPO?

Do they take effect when the script "fails" to run?

If not the entire GPO is not being applied which
is either due to one of those items above or due
to permissions likely.
 
Do you ever see yourself beeing wrong? If you read my links you would see
that others had this kind of problem and that one can suspect that it's
related to the way WinXP logon.

I thank you for your effort (I am really grateful) but thanks to another tip
I managed to work around the problem and it was _NOT_ permissions or DNS.
 
Sorry, missed that.

Didn't really find a good solution but I enabled "Wait for network before
logon" in local policy on client computer. Now the message "Preparing
network connection" takes a while longer but on the other hand a timeout
later on is gone (when desktop is displayed but waiting for icons).

Thank you very much for your answers. They are really appreciated!
 
MED said:
Sorry, missed that.

Didn't really find a good solution but I enabled "Wait for network before
logon" in local policy on client computer. Now the message "Preparing
network connection" takes a while longer but on the other hand a timeout
later on is gone (when desktop is displayed but waiting for icons).

Thank you very much for your answers. They are really appreciated!
Click to expand...

So it was an authentication issue.
 
Back
Top