Terminal-Server-Anmeldung schlägt fehl. "Fehler beim Anmelden an Dienst Gruppenrichtlinie"

[thor 10]

Hallo in die Runde.

Seit einiger Zeit haben wir folgende Problematik. Unsere Benutzer können sich nicht mehr an der Serverfarm anmelden. „ Fehler beim Anmelden an Dienst Gruppenrichtlinie“ wird als Fehler angezeigt.

 

Unser Netzwerkaufbau.

Terminal-Server-Farm mit Windows Server 2008 R2 und WSUS Updates.

File Server (Dort liegen unsere Profilverzeichnisse)  ebenfalls mit Windows 2008 R + WSUS

Benutzer melden sich via Remotedesktopprotokoll an den TS an und haben ein wanderndes TS-Profil.

 

 Zunächst haben wir immer das Profil des Benutzers gelöscht und neu schrieben lassen. Wir haben herausgefunden, dass die Datei NTUSER.dat im Terminal-Server-Profil des Benutzers der Auslöser ist. Diese hat im defekten Userprofil eine Größe von 256 KB. Standard meist über 2 MB. Auch die Datei ist nicht mehr versteckt, sondern offen sichtbar. Wenn wir nur diese löschen und den Benutzer neu anmelden lassen, geht es auch wieder. Wir vermuteten des G Data Antivirenwächter für den Auslöser, das diese vlt. beim Abmelden die nicht korrekt zurückschreibt und haben die NTUSER.dat in der Überwachung explizit herausgenommen. Bislang kein Erfolg.

Die defekte NTUSER.dat hat in dem Sicherheitsregister aber alle notwendigen Berechtigungen wie es sein sollte.

 

Hat jemand ähnliche Problematik und dann auch eine Lösungsmöglichkeit, die wir angehend könnten?

Vielen Dank schon mal für Euer Interesse an unserem Problem.

thor. 

bearbeitet 3. November 2014 von thor

[thor 10]

Hallo.
Schade das niemand bislang ein Lösungsansatz anbieten konnte.  

Hab ich das ins falsche Forum gestellt? Wenn ja, dann kann man dies gerne ins richte Forum verschieben....
Ähnliches Problem hatte auch ein User in diesem Thread http://www.mcseboard.de/topic/191468-gruppenrichtlinienclient-zugriff-verweigert-dom%C3%A4nen-anmeldung/

Die Prozedur, das sich der User wieder anmelden kann  ist bei uns einfacher, da wir diese Problematik bei den wandernden Profilen der Benutzer haben. 

Aber wir würden gerne herausfinden warum die NTUSER.dat nur noch 256KB anstatt die 2-3 MB hat....

 

Grüße thor

[testperson 1.707]

Hi,

 

was findest du denn auf den Servern (File- und Terminalserver) so beim An- und Abmelden alles im Eventlog?

Scant der G-Data Wächter die Netzlaufwerke? Sind die Ausnahmen sowohl auf dem Fileserver als auch auf dem Terminalserver gesetzt?

 

Gruß

Jan

[thor 10]

Hallo Testperson.
Danke für Deine Rückmeldung.

Aufm Terminalserver im Ereignisprotokoll /Anwendung sehe ich nur dieses.

Der Winlogon-Benachrichtigungsabonnent <Sens> ist bei einem Benachrichtigungsereignis fehlgeschlagen.

 

Die Klassenregistrierungsdatei kann nicht geladen werden.

DETAIL - Das System kann die angegebene Datei nicht finden.

 

Der Winlogon-Benachrichtigungsabonnent <GPClient> ist bei einem kritischen Benachrichtigungsereignis fehlgeschlagen.

 

Auf dem File Server sind keinerlei nützliche Ereignisse protokolliert

 

Die GData Ausnahmen sind für die NTUSER.dat auf den Terminal-als auch Fileserver gesetzt.

 

Mit freundlichen grüßen

thor

[Sunny61 807]

Deinstalliere zum Test GData doch mal, anschließend auch das Removal Tool von GData verwenden. Wäre nicht das erste Mal wenn hier ein AV-Scanner Amok läuft.

[thor 10]

Hallo.

Nach einigem recherchieren im Netz bei Onkel Google etc.bin ich bei diesen 3 Seiten vielleicht fündig geworden.

http://support.microsoft.com/kb/124594/en-us

http://support.microsoft.com/kb/2567018

http://support.microsoft.com/kb/935649/de

 

Stichpunkte - registrySizeLimit. Ich bin auf diesen Zug aufgesprungen, weil die Benutzer, deren NTUSER.dat geschrottet wird. immer eine NTUSER.dat von 6MB aufwiesen (Im Nachhinein vlt. purer Zufall)

Also hab ich bei unserem testserver des Registry Key gesetzt.

Vielleicht noch erwähnenswert, das es sich bei unseren Terminal Server um eine virtuelle Server gemanaged von VMware handelt.

HKLM>System>CurrentControlSet>Control RegistrySizeLimit REG_DWORD  0x02faf080  (50000000) 50MB sollte genügen.

Den Testserver gebootet. nach dem Reboot erscheint ein richtig schöner BlueScreen

0x0000074 BAD_SYSTEM_CONFIG_INFO

 

Das war also ein richtiger Sprint ins Abseits. Falls jemand ähnliche Problematik hat in virtuellem Umfeld. Setze diesen Key nicht! Tue es nicht.  
 

Server wieder da, aber das Problem bedauerlicherweise auch. Ich suche weiter, lasse es Euch wissen und falls Ihr eine neue Spur habt, immer her damit.

 

Deinstalliere zum Test GData doch mal, anschließend auch das Removal Tool von GData verwenden. Wäre nicht das erste Mal wenn hier ein AV-Scanner Amok läuft.

 

An Sunny61. Danke für den Lösungsansatz. Daran hab ich auch schon gedacht, jedoch müssten wir dies dann bei allen 35 Servern tun!
da wir die Problematik nicht nur einem Server zuordnen können.

 

Grüße ins Forum.

thor

 

 

[Sunny61 807]

An Sunny61. Danke für den Lösungsansatz. Daran hab ich auch schon gedacht, jedoch müssten wir dies dann bei allen 35 Servern tun!

da wir die Problematik nicht nur einem Server zuordnen können.

 

Prüf doch vorher nach, ob Du auch wirklich die aktuellste Version von GData im Einsatz hast. Hol GData ins Boot und lass Logdateien erzeugen.

 

Und die Frage von Testperson bezüglich Scannen Netzlaufwerke hast Du auch noch nicht beantwortet.

 

Seit wann besteht das Problem? Kannst Du es zu einem bestimmten Zeitpunkt festmachen?

[thor 10]

Hallo.

Das Scannen der Netzlaufwerke ist ausgeschaltet.

Die Problematik besteht seit ca. 4-6 Wochen. An einem best. Datum kann ich dies nicht festmachen.

Zur GData Version. Erst seit Montag Abend 10.11. haben wir die neue 13er Version von GData auf unserem ManagementServer drauf. Die TS-Server und Clients arbeiten noch mit der 12er

Wir wollten die Client zunächst noch im 12er Modus lassen, da wir Mitte Dezember wieder ein Rollout der kompletten Serverfarm durchführen.

mit besten grüßen

thor

[Sunny61 807]

Zur GData Version. Erst seit Montag Abend 10.11. haben wir die neue 13er Version von GData auf unserem ManagementServer drauf. Die TS-Server und Clients arbeiten noch mit der 12er

Wir wollten die Client zunächst noch im 12er Modus lassen, da wir Mitte Dezember wieder ein Rollout der kompletten Serverfarm durchführen.

 

Dann wirst Du wohl oder übel noch mit der Lösung bis Mitte Dezember warten müssen. Außer Du rollst jetzt recht schnell die aktuelle Version von GData aus. Denn so etwas wichtiges wie einen AV-Scanner sollte man einfach nicht auf die lange Bank schieben. Und in der Vergangenheit hat sich gezeigt, dass eine alte Version vom AV-Scanner sehr wohl für alles mögliche und unmögliche verantwortlich war.

 

Sprich doch mal mit GData, evtl. kennen die den Fehler und haben ihn in der Version 13.x behoben.

[thor 10]

Hallo Sunny61.

Ja, da könnte was dran sein. Womöglich werden wir die Server in 5er Schritten aktualisieren.

Sobald wir damit durch sind, werden wirs weiter beobachten.

Danke

[Sunny61 807]

Lies doch mal dieses Posting: http://www.mcseboard.de/topic/200358-desktop-icons-verschwinden-nach-aufrufen-von-ms-office-dateien/?do=findComment&comment=1249117

[thor 10]

So, da bin ich wieder.

Terminal-Server als auch File Server sind nun auf dem neuesten GData Stand V13.

 

Lies doch mal dieses Posting: http://www.mcseboard.de/topic/200358-desktop-icons-verschwinden-nach-aufrufen-von-ms-office-dateien/?do=findComment&comment=1249117

Die angezeigte Einstellung im Gdata verglichen.

Die Verhaltensüberwachung ist nicht eingeschaltet.

 

Trotz dem Update, bliebt der Fehler weiterhin beharrlich hartnäckig unser Begleiter.

Wir können bei diesem Fehler wirklich keinerlei Reproduktion rekonstruieren. Weder Abmeldezeit; noch angemeldeter Server; noch Organsisationseinheit; noch Art des Arbeitsgerätes (ThinClient oder Workstation);  läßt Rückschlüsse auf das fehlerhafte Verhalten der NTUSER.dat zu. So langsam beginnen wir zu verzweifeln :confused: , aber die Hoffnung ist noch da! :wink2:

Grüße thor.

[Sunny61 807]

Spätestens jetzt solltet ihr ein Ticket beim Support von MS eröffnen.

[thor 10]

Hallo ins Netz.

Nach langem Suchen und mit Einschalten unseres Microsoft Gold Partner sowie mehreren Telefonaten mit Microsoft, konnte die Fehlerquelle eingekreist werden.

Nach der Installation des Hotfixes KB2831347, laufen die Terminal-Server-Profile nun endlich wieder regulär. Wir haben das 2 Wochen auf einer Farm getestet, dann auf alle übertragen.

Dies für alle, welche momentan ähnliche Probleme haben.

Ein Dankeschön an alle, die sich über diese Problematik die Köpfe zerbrochen haben und mich in der Lösungsfindung unterstützen.

Gruß Thor