XP Machines in AD don't behave

  • Thread starter Thread starter Thomas Heil
  • Start date Start date
T

Thomas Heil

Hello,

first of all sorry for the german groups that I post in English, but this is
cross-posted to english groups as well. -

I recently have got two new PCs unter XP SP1 which, like all others before,
have been stuck into our W2K domain. And like all others before, they should
automatically get software installed through a group policy. Concerning the
AD, they are in the right OU together with other machines where this
procedure has worked fine.

When these two start up, according to the event log, they don't see any
domain controller. So they do not run the assigned startup scripts, don't
import group policies, and so don't install the software. But I *can* log on
with domain accounts, for which then the right logon script is run, and the
environment of a command prompt does have the LOGONSERVER variable set to a
valid DC when I type set.

Does anyone have an idea what could cause this? These two systems are
identically configured concerning network params (fixed IP address, same net
mask, gateway, servers, completion domains etc.), although the actual
hardware differs. OTOH, I tried another PCI NIC instead of the onboard
controller, and the result was the same.

Please email any comments to me in addtion to posting replies here.

Thanks in advance,
Thomas Heil ([email protected])
 
Thomas said:
When these two start up, according to the event log, they
don't see any domain controller. So they do not run the
assigned startup scripts, don't import group policies, and so
don't install the software. But I *can* log on with domain
accounts, for which then the right logon script is run, and
the environment of a command prompt does have the LOGONSERVER
variable set to a valid DC when I type set.
Click to expand...

Is the NETLOGON service starting without any problems reported in
eventvwr ?

Die beschrieben Effekte habe ich schon beobachtet, wenn der "Trust"
zwischen Domain und Workstation gebrochen war (d.h. das intern
verwaltete Passwort für die Workstation stimmte nicht mehr mit dem
Konto in der Domain überein). Der NETLOGON Service macht dann Stress,
in der Folge werden alle Group Policies ignoriert, aber ein
interaktiver Logon funktioniert wie gewohnt.

Gruss
Rolf.


fup microsoft.public.de.german.windowsxp.gruppen.richtlinien
 
Im Newsbeitrag (e-mail address removed)
schrieb Thomas Heil:
When these two start up, according to the event log, they don't see
any domain controller. So they do not run the assigned startup
scripts, don't import group policies, and so don't install the
software. But I *can* log on with domain accounts, for which then the
right logon script is run, and the environment of a command prompt
does have the LOGONSERVER variable set to a valid DC when I type set.
Click to expand...

Try this

Set both machines as workgroup member.
Delete their accounts from the AD.
If you have 2 or more DCs using replication force replication
Rejoin the domain

I had this error a few times and could always solve it by deleting
the computer accounts and rejoining the domain.

Regards

Roland Weisskopf
 
Set both machines as workgroup member.
Delete their accounts from the AD.
Click to expand...

if you haven't started yet, reset their machine account on a DC, sync all
DCs and reboot the workstations talked about here. (Right Click on the
machine account - "reset account"). Resetting acounts work since Active
Directory.
If this won't help, use next step : the lines above (the post before mine),
delete and recreate the accounts.

greetings
roger
 
Roland Weisskopf said:
Im Newsbeitrag (e-mail address removed)
schrieb Thomas Heil:


Try this

Set both machines as workgroup member.
Delete their accounts from the AD.
If you have 2 or more DCs using replication force replication
Rejoin the domain

I had this error a few times and could always solve it by deleting
the computer accounts and rejoining the domain.

Regards

Roland Weisskopf
Click to expand...

I have tried all the tips up to now, including removing them from AD,
re-installing them, and then re-joining them. The point is that, upon boot,
the system seems to have no net access while checking for DCs (this is
indicated by a Netlogon event log entry that is identical to when the system
is plugged out from the net), obviously because the NIC is not initialized
at that time. When I flood-ping the machine I can see that it responds only
when the search for policies and startup scripts and such is already done
and the logon prompt appears. About one time out of 10-15, the system does
act as it should, so this seems to me like a timing problem. These are our
first two machines with 3GHz. The local admin template telling them to
behave like W2K systems with respect to system startup and logon has been
activated.

Ich habe bislang alle Tips ausprobiert, bis hin zu raus aus dem AD,
Neuinstallation, und rein ins AD. Der Punkt ist, dass beim Hochfahren
scheinbar kein DC gefunden wird (belegt durch einen entsprechenden
Netlogon-Logeintrag, der auch auftritt, wenn der Rechner nicht am Netz
hängt), scheinbar weil die Netzwerkkarte noch nicht initialisiert ist. Wenn
ich die Maschine anpinge, sehe ich, dass sie erst antwortet, wenn die Suche
nach DC etc. schon passiert ist und der Anmeldeprompt erscheint. Bei einem
von 10-15 Starts macht die Maschine allerdings, was sie soll. Von daher
denke ich, dass das ein Timing-Problem ist. Das sind unsere ersten beiden
3GHz-Rechner. Die lokale admin. Vorlage, sich zu beim Hochfahren und
Anmelden zu verhalten wie ein W2K-System ist gesetzt.

Cheers
Thomas Heil
 
Hello Thomas,

If your network config (DNS, Default Gateway) is ok, you should note a few
things:

1. Disable asynchronous logons accourding Norbert's link in his post.

2. Set the workstation's nic settings to full duplex and supported higher
speed. Do the same on the switch the clients are connected to. Best case is
when the settings for both, computer nic and switch, match to same values
without auto detection.

The problem with 2.) is a conflict between a relative fast startup and a
delay during auto detection. Beeing configured for asynchronous logons by
default, XP's (super fast OS :-)) boot process passes the check mark for
domain logon while the nic is lagging behind, so the computer account logons
with cached credentials to AD and no computer spec. GPOs are applied
anew/refreshed.

3. Even if XP isn't configured for async. logon but instead it operates in a
segment with high network congestion or low speed network (caused by switch
problem as described above or any other reason), the connection could be
interpreted as a "slow link connection", which by default ignores the
processing of the mentioned GPOs. Configure the GPOs for the computer object
under AminTemplates\System\GPOs for *Script policy & SW installation
processing to apply even across a slow network connection, and/or increase
the value for the *GP slow link detection"-GPO.

This might help.

Regards,
Tatjana Aggoussi
..
 
Tatjana Aggoussi said:
Hello Thomas,

[...]
The problem with 2.) is a conflict between a relative fast startup and a
delay during auto detection. Beeing configured for asynchronous logons by
default, XP's (super fast OS :-)) boot process passes the check mark for
domain logon while the nic is lagging behind, so the computer account logons
with cached credentials to AD and no computer spec. GPOs are applied
anew/refreshed.
[...]
This might help.

Regards,
Tatjana Aggoussi
Click to expand...

This was it!

Thanks a lot.
Thomas
 
You're welcome.

Freundliche Grüsse,
Tatjana Aggoussi


Thomas Heil said:
Tatjana Aggoussi said:
Hello Thomas,

[...]
The problem with 2.) is a conflict between a relative fast startup and a
delay during auto detection. Beeing configured for asynchronous logons by
default, XP's (super fast OS :-)) boot process passes the check mark for
domain logon while the nic is lagging behind, so the computer account logons
with cached credentials to AD and no computer spec. GPOs are applied
anew/refreshed.
[...]
This might help.

Regards,
Tatjana Aggoussi
Click to expand...

This was it!

Thanks a lot.
Thomas
Click to expand...
 
Back
Top