Jump to content

logon script wird nicht immer ausgeführt


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo,

 

ich hätte da folgendes Problem in unerer W2K3 Domäne, (Server W2K3 R2 SP2, Client XP SP2).

 

Wir nutzen ein Login-Script zum Laufwerksmapping etc., dieses wird via GPO der OU zugeordnet in welcher sich die Userkonten befinden.

 

Nur manchmal (nicht immer) wird das Script eben nicht ausgeführt (dies tritt zu unterschiedlichen Zeiten auf unterschiedlichen Rechnern bei unterschiedlichen Benutzern auf).

 

Die Tipps und Tricks aus dem WWW (d.h. per GPO: immer auf Netzwerk warten, Scriptverarbeitung auch bei langsamer Verbindung ausführen, Wartezeit auf das Netzwerk (TimeOut) erhöhen) haben wir bereits durch.

 

Im Eventlog (Client und DC) sind auch keine Fehler sichtbar (d.h. kein: Netz nicht gefunden, Server antwortet nicht, keine Berechtigung zum Ausführen etc.).

 

Das Interessante ist, wenn der User sich abmeldet (da er ja seine Laufwerke vermisst) und wieder anmeldet, wird das Script ausgeführt :suspect:

 

Hat jemand eine Idee, woran es noch liegen könnte?

 

Vielen Dank

 

motzel

 

ps. wir haben uns schon überlegt das Login-Script (wie zu NT4.0 Zeiten) wieder direkt im Benutzerkonto zu hinterlegen.

Link zu diesem Kommentar

Hallo motzel,

 

sorry hatte das im Eingangspost überlesen das du den Punkt schon gesetzt hattest.

 

Wie siehts denn mit Virenschutz aus ? Bei McAfee weiß ich das der Dienst Vorraussetzung

ist für einen einwandfreien Netzwerkbetrieb. Wenn dieser hängt

schlagen die Scripts auch fehl. Könnte das bei dir zutreffen ?

 

Also Test würde ich im Loginscript der betroffenen OU mal ein pause an das

Ende des Scriptes setzen um eventuelle Fehler zu erkennen.

Link zu diesem Kommentar

@Cybquest,

 

ja wir haben mehrere DC's aber die Replikation läuft, um es genau zu beschreiben, wir haben eine einzige Domäne mit mehren Standorten (also mehrere C- und B-Class Netze) mit insgesamt 24 DC's (alle W2K3 R2 SP2). Und das Problem tritt auch an verschiedenen Standorten auf.

 

Ich stimme Sunny61 zu, dass es wahrscheinlich daran liegt, dass der Client die NIC noch nicht ganz aktiviert hat, wenn er versucht die GPO's abzufragen, wobei aber wie gesagt die Eventlog's sauber sind.

 

@XP-Fan,

 

das Problem ist, dass definitiv im Problemfall das Script nicht ausgeführt wird (die Scripte werden sichtbar ausgeführt), habe ich selbst an meinem eigenen Rechner gesehen. Alles was ich noch sagen kann ist, dass im Problemfall das Hochfahren des Systemes "gefühlt" länger als "normal" dauert bis man sich mit User und Passwort anmelden kann.

 

Was ich noch hätte, ist aber wahrscheinlich ein Schlag ins Wasser:

Da die interne XP-FW (via GPO) deaktiviert ist, beendet sich auf den Clients der Service Computerbrowser nach 5 Minuten (s.h. Microsoft-KB889320 When you disable the Windows Firewall service on your Windows XP Service Pack 2-based computer, the Computer Browser service stops after five minutes and Event ID 7023 is logged in the Event Viewer).

 

Viele Grüße

 

motzel

Link zu diesem Kommentar

@Sunny61

 

beide Optionen sind gesetzt:

 

Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung

"Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" = aktiviert

und:

Computerkonfiguration \ Administrative Vorlagen \ System \ Skripts

"Anmeldeskripts gleichzeitig ausführen" = aktiviert

 

Hätte evtl. noch jemand eine Idee?

 

Vielen Dank

 

motzel

Link zu diesem Kommentar

Und die beiden Einstellungen kommen auch auf den Clients an? Prüf das mal mit einem RSOP.MSC auf einem Client. Alternativ kannst Du ein Computerstartupscript einbauen, das kontrolliert, ob der betroffene Server überhaupt erreichbar ist.

 

Wenn mehrere DCs im Einsatz sind, die Sites sind richtig konfiguriert im AD? Die Clients melden sich am richtigen %LOGONSERVER% an?

Link zu diesem Kommentar

Hallo Sunny61,

 

ja, ich hatte es heute wieder und saß direkt vor dem System.

 

Die DC's sind sauber, replizieren, usw. auch die Überprüfung am Client (direkt nach der Anmeldung) ergab, dass die GPO's gezogen wurden. Nur hat auch diesesmal das eigentliche Hochfahren (also Übernahme der Computerkonfiguration und der Sicherheitsrichtlinie) ca. 2 bis 3 Minuten gedauert (Schätzwert).

 

Ich bin mir fast sicher dass die Kisten, aus welchem Grund auch immer, auf einen TimeOut laufen, der nicht im Eventlog des Clients aufgezeichnet wird ...

 

Wobei laut MS: http://support.microsoft.com/kb/328991/en-us dieses verhalten zumindest unter W2K (okay, ich habe XP SP2) "bekannt" ist.

 

In diesem Zusammenhang habe ich noch einen sehr interessanten Link: http://www.microsoft.com/germany/technet/scriptcenter/topics/gp/extension1.mspx gefunden. Hier wird beschrieben, dass nicht die GPO's die Logon-Scripte starten, sondern der UserInit-Prozess hierfür verantwortlich zeichnet.

 

Cool ist dieser Satz aus dem Artikel ;) Zitat: "Sie haben alles geprüft und können keinen Fehler finden. Es gibt nicht einmal USERENV-Fehlermeldungen in den Ereignisprotokollen. Sie kommen nicht weiter. ... es ist sehr gut möglich, dass die Gruppenrichtlinie zwar ordnungsgemäß ausgeführt wird, die Skripts jedoch überhaupt nicht ausgeführt werden."

 

 

Viele Grüße

 

motzel

Link zu diesem Kommentar

ja, ich hatte es heute wieder und saß direkt vor dem System.

 

Die DC's sind sauber, replizieren, usw. auch die Überprüfung am Client (direkt nach der Anmeldung) ergab, dass die GPO's gezogen wurden. Nur hat auch diesesmal das eigentliche Hochfahren (also Übernahme der Computerkonfiguration und der Sicherheitsrichtlinie) ca. 2 bis 3 Minuten gedauert (Schätzwert).

 

Und keine Laufwerke waren vorhanden? Wie hat SET auf der Comandline ausgesehen? LOGONSERVER vorhanden? Hmm, ihr könntet ja einen kleinen Timeout in einem Computerstartupscript einbauen, so als Workaround.

 

Kannst Du das Loginscript für ein paar Benutzer mal ins SYSVOL packen und mit IFMEMBER arbeiten?

 

Ich bin mir fast sicher dass die Kisten, aus welchem Grund auch immer, auf einen TimeOut laufen, der nicht im Eventlog des Clients aufgezeichnet wird ...

 

Die IP-Adressen gibts von einem DHCP-Server? Sind die Clients im korrekten Subnet? Die DCs auch?

 

Wobei laut MS: Script Policy Is Not Run When a Slow Link Is Detected dieses verhalten zumindest unter W2K (okay, ich habe XP SP2) "bekannt" ist.

 

Weshalb noch kein SP3? Sind die NIC-Treiber für die Clients aktuell?

Link zu diesem Kommentar

Hallo Sunny61,

 

der Logonserver wurde gefunden (auch aus dem korrekten Subnetz), die IP-Adresse wurde vom DHCP sauber zugeordnet (die Clients und die zugehörigen DC's sind im gleichen Netz), es passt eigentlich alles ...

 

Warum wir noch kein SP3 einsetzen, naja unser Netz besteht aus 1300 PC's da sollte so ein Roll-Out (ja, klar geht auch bei uns über den WSUS) vorher sauber verprobt werden (wegen evtl. Nebeneffekten mit div. Anwendungssoftwaren).

 

Das Problem tritt auf ganz unterschiedlicher HW auf, so dass ich NIC-Treiber fast ausschliessen möchte.

 

Unser workaround sieht 2 mögliche Alternativen vor:

 

1. ein wait für 15 Sekunden ganz am Anfang vom Logon-Script (evtl. wird ja das Script aufgerufen, aber zu diesem Zeitpunkt wegen eines "Scriptfehlers" gleich wieder beendet. Was ich damit meine ist, dass das Script zu dem Zeitpunkt eben noch nicht korrekt abgearbeitet werden kann, ein paar Sekunden später eben schon, da dann die "Umgebung" soweit steht.)

 

2. wir vergessen die GPO-Logon-Scripte und weisen diese, wie zu NT4.0 Zeiten, den Userprofilen direkt zu.

 

Was mich halt stutzig macht, im WWW gibt es unzählige Beiträge in X-Foren zu diesem Thema und selbst MS sagt: Die zwei Seiten beim Verarbeiten der Gruppenrichtlinien-Skripterweiterung: Teil 1 dass es viele Gründe hierfür geben kann, nur einen 100% Weg wie man es "richtig macht" scheint es nicht zu geben :(

 

Viele Grüße

 

motzel

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...