none
LoginScript per Gruppenrichtlinie greift nur von einem Anmeldeserver RRS feed

  • Frage

  • Hallo,

    wir haben in einer Domäne zwei DCs, beide Server 2008 (32Bit)
    Den Usern soll per Gruppenrichtlinie ein LogIn Script zugewiesen werden.

    Dies geschieht auch, sobald der Anmeldeserver Server 1 ist - wenn der Anmeldeserver Server 2 ist, wird das LogIn Script nicht ausgeführt.

    Offensichtlich scheint auch die Replikation zwischen den Servern nicht sauber zu funktionieren, da die SYSVOLs der Server unterschiedliche Stände aufweisen.
    Die Scripte selbst replizieren sich aber sauber - wird auf der einen Seite eine Änderung vorgenommen, wird diese auch umgehend auf das Script auf dem anderen Server übertragen.


    Wo können wir hier ansetzen?

    Vielen Dank vorab...

     

    Freitag, 2. Juli 2010 09:55

Antworten

  • Nicht viel...

     

    Offensichtlich haben sich die Profile zerschossen, Ursache waren vermutlich fehlerhafte ntuser.dat's

    Der Ursprung dieses Probles konnte nicht mehr nachvollzogen werden.

     

    Nach vielen Anpassungen am System selbst (wegnehmen und tauschen der DC's, ...) konnte das Problem (vorerst) durch Neuanlegen der lokalen Userprofile auf den Terminalservern gelöst werden.

    Mittwoch, 15. September 2010 11:37

Alle Antworten

  • Hi,

    Am 02.07.2010 11:55, schrieb Dennis_K5121:

    Dies geschieht auch, sobald der Anmeldeserver Server 1 ist - wenn der
    Anmeldeserver Server 2 ist, wird das LogIn Script nicht ausgeführt.

    Du hast definitiv kein Problem mit Gruppenrichtlinien, sondern mit der
    Replikation.

    Einfachster Weg, anstelle reperatur:
    - defekten DC demoten, dann aufräumen [1] und danach wieder promoten

    Ist meist leichter und schneller als die Fehersuche. Fehlersuche findet
    erst statt, wenn es danach nicht klappt.

    Tschö
    Mark

    [1]
    http://support.microsoft.com/kb/216498


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Freitag, 2. Juli 2010 10:00
  • Am 02.07.2010 12:00, schrieb Mark Heitbrink [MVP]:

    Einfachster Weg, anstelle reperatur:
    - defekten DC demoten, dann aufräumen [1] und danach wieder promoten

    Vergessen, wenn es nur ein Filesystem Problem ist und nicht Datenbank
    dann gehts hiermit schneller: http://support.microsoft.com/kb/290762
     -- Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Freitag, 2. Juli 2010 10:07
  • Am 02.07.2010 schrieb Dennis_K5121:

    Hi,

    Wo können wir hier ansetzen?

    Haben dir Marks Antworten geholfen?

    Bye
    Norbert


    Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?

    Montag, 5. Juli 2010 21:15
    Moderator
  • Danke schonmal vorab für die Infos...

    Mittlerweile zeigt sich das Problem wesentlich komplexer. Im ersten Schritt hatte ich den BurFlags getestet. Dies scheint aber nicht funktioniert zu haben, da nie die angegebenen IDs in der Ereignisanzeige erschienen sind.
    Daraufhin habe ich den scheinbar fehlerhaften DC mit DC Promo rausgenommen und wieder reingenommen.

    Alles in allem scheint dies aber nur ein Teilaspekt unseres Problems zu sein. Das ganze Problem tritt auf einem Terminalcluster auf.
    Wie weitere Recherchen zeigten, wendeten die beiden Terminalserver unterschiedliche Revisionen der zuständigen Gruppenrichtlinien an.

    Nach Neuanlegen einer Gruppenrichtlinie funktionierte das ganze dann mit einem Testuser wieder problemlos.

    Heute im laufenden Betrieb zeigt sich bei anderen Usern, dass der eine TS (TS2) laut Gruppenrichtlinienergebnissen noch die alte Gruppenrichtlinie anwendet, der andere (TS1) Bereits die neue.
    Man muss dazu sagen, dass laut "set" die beiden TS's auch unterschiedliche Anmeldeserver (2 DCs im Netz) haben.

    Sehr verwunderlich erscheint mir die Tatsache, dass der TS2, der laut Gruppenrichtlinienergebniss noch auf die alte, jetzt deaktivierte Gruppenrichtlinie verweist das LogIn Script ausführt und der andere (TS1), der auf die neue Richtlinie zeigt nicht.

    Im Gegenzug zeigt mein TestUser aber für beide TS's auf die neue Richtlinie - und führt das LogIn Script auch aus.

    Sehr verwirrend das ganze...

     

    Dienstag, 6. Juli 2010 10:04
  • Hi,

    Am 06.07.2010 12:04, schrieb Dennis_K5121:

    dass der TS2, der laut Gruppenrichtlinienergebniss noch auf die alte,
     jetzt deaktivierte Gruppenrichtlinie verweist

    Das ist nicht verwunderlich.
    Ihr habt immer noch entweder ein Replikationsproblem, denn sonst würde
    der 2te Server die alte Infrastruktur nict bereitstellen, oder der
    Server selbst habt probleme beim Einlesen der neuen GPO infrastruktur,
    siehe Eventlog.
    Wenn das Eventlog sauber ist, ist die Replikation immer noch Fratze.

    Ebenfalls gern genommen:
    Schalte die Firewall zwischen den Standorten aus, die ist falsch
    konfiguriert.

    Tschö
    Mark


    Mark Heitbrink - MVP Windows Server - Group Policy

    Homepage:    www.gruppenrichtlinien.de - deutsch
    NNTP Bridge: http://communitybridge.codeplex.com/releases

    Dienstag, 6. Juli 2010 10:37
  • Danke - die Vermutung habe ich auch noch stark, sehe aber momentan keinen Ansatzpunkt zur weiteren Fehlerbehebung bzw Diagnose... das scheint alles so willkürlich momentan.

    Also Firewall kommt nicht in Frage, die Server stehen alle an einem Standort, WindowsFirewall deaktiviert

     

    Die Ereignisanzeige meldet zahlreiche 511-Fehler (auf beiden Servern - gestern auf TS2, heute auf TS1)

    Protokollname: Application
    Quelle:        Microsoft-Windows-Folder Redirection
    Datum:         06.07.2010 11:41:01
    Ereignis-ID:   511
    Ebene:         Fehler
    Beschreibung:
    Die Richtlinieninformationen konnten nicht verarbeitet werden.
    Fehlerdetails: "Falscher Parameter.


    Der Komponentenstatus zeigt diverse, füb beide Server unterschiedliche, Meldungen:

    (TS1 mit neuer Richtlinie - Letzter Prozess 06.07.2010)
    Group Policy Regional Options / Folder Redirection / Group Policy Internet Settings / Group Policy Shortcuts / Group Policy Start Menu
    Fehler bei Group Policy Regional Options aufgrund des unten aufgeführten Fehlers.
    Für diesen Befehl ist nicht genügend Speicher verfügbar.

    (TS2 mit alter Richtlinie - Letzter Prozess 05.07.2010)

    Group Policy Regional Options / Folder Redirection / Group Policy Internet Settings / Group Policy Shortcuts / Group Policy Start Menu
    Fehler bei Group Policy Regional Options aufgrund des unten aufgeführten Fehlers.
    Eine DLL-Initialisierung ist fehlgeschlagen


    Ist hier irgendwas greifbares dabei was mein Problem erklärt?

     

     

     

    Dienstag, 6. Juli 2010 11:01
  • Noch ein Update:

    Wenn ich mich mit einem Testuser zuerst an TS1 und danach an TS2 anmelde, bekomm ich auf BEIDEN Servern kein LogIn Script

    Mache ich das ganze umgekehrt, zuerst anmelden an TS2 und danach an TS1 greift das LogIn Script auf beiden Servern ordnungsgemäß!

    Dienstag, 6. Juli 2010 11:21
  • Am 06.07.2010 schrieb Dennis_K5121:
    Hi,

    Mittlerweile zeigt sich das Problem wesentlich komplexer. Im ersten Schritt hatte ich den BurFlags getestet. Dies scheint aber nicht funktioniert zu haben, da nie die angegebenen IDs in der Ereignisanzeige erschienen sind.

    Dann hat man üblicherweise was falsch gemacht. Kannst du mal aufzeigen, was
    genau du getan hast? So wie du es beschreibst, hilft es weder dir noch uns
    beim Beantworten.

    Daraufhin habe ich den scheinbar fehlerhaften DC mit DC Promo rausgenommr e TS (TS2) laut Gruppenrichtlinienergebnissen noch die alte Gruppenrichtlinie anwendet, der andere (TS1) Bereits die neue.
    Man muss dazu sagen, dass laut "set" die beiden TS's auch unterschiedliche Anmeldeserver (2 DCs im Netz) haben.

    Wäre jetzt aber nicht so ungewöhnlich.

    Sehr verwunderlich erscheint mir die Tatsache, dass der TS2, der laut Gruppenrichtlinienergebniss noch auf die alte, jetzt deaktivierte Gruppenrichtlinie verweist das LogIn Script ausführt und der andere (TS1), der auf die neue Richtlinie zeigt nicht.

    Die TS übernehmen die Richtlinien aber? Mittels /force mal getestet?

    Bye
    Norbert


    Dilbert's words of wisdom #10:
    I don't have an attitude problem. You have a perception problem.

    Dienstag, 6. Juli 2010 20:50
    Moderator
  • Am 06.07.2010 schrieb Dennis_K5121:
    Hi,

    Die Ereignisanzeige meldet zahlreiche 511-Fehler (auf beiden Servern - gestern auf TS2, heute auf TS1)

    Schonmal bei eventid.net geschaut? Welches OS haben die TS eigentlich?

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.

    Dienstag, 6. Juli 2010 20:51
    Moderator
  • Betriebssystem ist sowohl auf dem DCs als auch auf den TSs WinSrv 2k8 32Bit

    Die Events 511 erscheinen immer nur auf einem Server während parallel auf dem anderen Fehlermeldungen kommen wie "Nicht genügens Speicher" oder "DLL-Initialisierung fehlgeschlagen".
    Die Suche nach dem Event 511 war leider bisher nicht von Erfolg gekrönt.

    Hab nur die nicht autorisierende Wiederherstellung versucht. -> net stop ntfrs, RegistryKey D2 wie angegeben gesetzt und Dienst wieder gestartet.  Der Key wurde auch automatisch wie im KB angegeben auf '0' zurückgesetzt - aber die Events ersheinen nicht wie beschrieben.

    Ungewöhnlich ist es natürlich nicht, dass die TSs unterschiedliche Anmeldeserver haben - ich wollte es nur erwähnt haben, als weiter mögliche Fehlerquelle.

    Was die TSs mit den Richtlinien machen ist sehr verwirrend! Soweit ich das über die Gruppenrichtlinienergebnisse auswerten kann zeigt sich teilweise, dass beide Server unterschiedliche Richtlinien auswerten oder teilweise auch die richtigen Richtlinien anwenden, aber anscheinend nicht vollständig anwenden.
    So hatte ich mehrfach das Phänomen, dass zwar auf beiden TSs die richtige Richtlinie ausgewertet wurde aber laut Gruppenrichtlinienergebnisauswertung auf dem einen mehr Richtlinien Anwendung fanden als auf dem anderen. So wurde zum Beispiel aus ein und der selben Policy für den selben User auf dem einen TS eine Anwendung der Interneteinstellungen angezeigt, für den anderen TS aber nicht!

    Das sieht dann so aus:

    Gruppenrichtlinienergebnisse
    user\TS2
    Angewandte Gruppenrichtlinie TS_Policy / AD (5), Sysvol (5)

     

    Gruppenrichtlinienergebnisse
    user\TS1
    Angewandte Gruppenrichtlinie TS_Policy /AD (5), Sysvol (5)


    Das ganze wie gesagt von User zu User unterschiedlich! Ausserdem verändert sich das ganze - nach mehrmaligem Anmelden, ohne etwas am User selbst zu machen, sieht es dann irgendwann mal so aus!

    Gruppenrichtlinienergebnisse
    user\TS1
    Angewandte Gruppenrichtlinie TS_Policy /AD (5), Sysvol (5)

    Dienstag, 6. Juli 2010 21:25
  • Am 06.07.2010 schrieb Dennis_K5121:

    Hi Dennis,

    besteht das Problem noch, oder hat es sich lösen lassen?

    Bye
    Norbert


    Dilbert's words of wisdom #34:
    When you don't know what to do, walk fast and look worried.

    Donnerstag, 29. Juli 2010 12:36
    Moderator
  • Hallo,

     

    nein, das Problem ist so leider noch nicht gelöst!

    Allerdings läuft zu diesem Problem Momentan ein Microsoft Supportcase in der Hoffnung, dass diese das Problem lösen können

    Donnerstag, 29. Juli 2010 12:38
  • Am 29.07.2010 schrieb Dennis_K5121:

    Hi,

    nein, das Problem ist so leider noch nicht gelöst!

    Allerdings läuft zu diesem Problem Momentan ein Microsoft Supportcase in der Hoffnung, dass diese das Problem lösen können

    OK, halte uns doch auf dem Laufenden, was dann beim Support Call herauskam.

    Bye
    Norbert


    Dilbert's words of wisdom #18:
    Never argue with an idiot. They drag you down to their level then beat you
    with experience.

    Donnerstag, 29. Juli 2010 12:47
    Moderator
  • Hi,

    was spricht der Support Case?

     

    Bye

    Norbert

    Dienstag, 31. August 2010 16:05
    Moderator
  • Nicht viel...

     

    Offensichtlich haben sich die Profile zerschossen, Ursache waren vermutlich fehlerhafte ntuser.dat's

    Der Ursprung dieses Probles konnte nicht mehr nachvollzogen werden.

     

    Nach vielen Anpassungen am System selbst (wegnehmen und tauschen der DC's, ...) konnte das Problem (vorerst) durch Neuanlegen der lokalen Userprofile auf den Terminalservern gelöst werden.

    Mittwoch, 15. September 2010 11:37
  • Am 15.09.2010 schrieb Dennis_K5121:
    Hi,

    Nicht viel...

    Na das liest sich doch aber zumindest nach einer Lösung, oder?

    Offensichtlich haben sich die Profile zerschossen, Ursache waren vermutlich fehlerhafte ntuser.dat's

    Der Ursprung dieses Probles konnte nicht mehr nachvollzogen werden.

     

    Nach vielen Anpassungen am System selbst (wegnehmen und tauschen der DC's, ...) konnte das Problem (vorerst) durch Neuanlegen der lokalen Userprofile auf den Terminalservern gelöst werden.

    Danke für die Rückmeldung.

    Bye
    Norbert

    Mittwoch, 15. September 2010 21:02
    Moderator