OU versehentlich verschoben

[Hannibal 10]

Hallo :)

 

Letzten Freitag ist mir ein Fehler unterlaufen, der mir so noch nie passiert ist.

:(

 

Ich war im AD(Active Directory-Benutzer und -Computer) unterwegs und hab

dabei versehentlich eine OU verschoben.

 

In dieser OU waren die Clients, Server, Domänenkontroller etc enthalten. Mir

ist der Fehlergleich aufgefallen, sodass ich die OU wieder an den ursprünglichen

Ort zurückverschoben hatte.

 

Anschließend hatte ich die Berechtigungen und Gruppenrichtlinien kontrolliert,

dort hatte sich aber nichts verändert.

 

 

Leider gibt es seit ab dem Zeitpunkt aber Probleme bei der Nutzeranmeldung,

welche bis zu 15 Min dauert. Die ~15min Wartezeit entsteht aber erst ab dem

Zeitpunkt wenn der Nutzer sein Benutzername/Passwort eingibt und bestättigt.

 

D.h. das Computerkonto wird einwandfrei an der Domäne angemeldet. Um

Anhaltspunkte zu finden hab ich mir von betroffenen Clients das Eventlog

angeschaut, konnte aber keine Fehler ausmachen.

 

Auch nach dem Wochenende gibt es immer noch paar Nutzer die Probleme

mit der Anmeldung haben. Wenn diese ca 15 Min warten wird das Profil

(Desktop, etc ...) geladen und sie können wie gewohnt arbeiten.

 

Bisher vermutete ich das diese Nutzer ihren Client nicht ausgeschaltet haben

über das Wochende. Aber auch nach einen Reboot dauerte die Anmeldung ca

15min.

 

Ich suche nun nach einer Ursache/Grund wieso die Nutzeranmeldung ~15min

drauert und wie ich den "Normalzustand" wiederherstellen kann. Habt ihr eine

Idee?

 

/EDIT

Es gibt aber Nutzer die sich ohne Probleme heute anmelden konnten. Es betrifft

also nicht alle Clients.

[Daim 12]

Servus,

 

In dieser OU waren die Clients, Server, Domänenkontroller etc enthalten.

 

wie jetzt? Du hast die DCs aus der OU "Domain Controllers" in eine eigene OU verschoben und in der gleichen OU befinden sich auch die Clients?

 

Es gibt aber Nutzer die sich ohne Probleme heute anmelden konnten. Es betrifft also nicht alle Clients.

 

Ein langsames Anmeldeverhalten wie z.B. vom DNS und von GPOs hervorgerufen. Prüfe als erstes ob die betroffenen Clients einen internen DNS-Server in ihren TCP/IP-Einstellungen eingetragen haben. Als nächstes führe ein rsop oder gpresult aus und überprüfe die GPOs, die auf den User der sich an dem Client angemeldet hat wirken.

 

Ansonsten kannst du noch das USERENV-Logging aktivieren um zu sehen, was genau bei der Anmeldung passiert.

 

How to enable user environment debug logging in retail builds of Windows

[Hannibal 10]

wie jetzt? Du hast die DCs aus der OU "Domain Controllers" in eine eigene OU verschoben und in der gleichen OU befinden sich auch die Clients?

Hm ne das kam wohl falsch rüber. Die DC wurden nicht verschoben. Aber die OU die ich verschoben hatte, beinhaltet weitere OUs, zb wo Clients und Server

einsortiert sind. Dadrunter liegt zB auch ein Fileserver für ein Laufwerksmapping was die Nutzer gemapped bekommen.

 

Prüfe als erstes ob die betroffenen Clients einen internen DNS-Server in ihren TCP/IP-Einstellungen eingetragen haben.

Haben Sie nicht, steht auf automatisch.

 

Die anderen Vorschläge werd ich mal testen. Danke

[Daim 12]

Hm ne das kam wohl falsch rüber.

 

Es kam so rüber, wie du es geschildert hattest.

 

Prüfe als erstes ob die betroffenen Clients einen internen DNS-Server in ihren TCP/IP-Einstellungen eingetragen haben.

 

Haben Sie nicht, steht auf automatisch.

 

Lies dir das nochmals durch.

 

Die anderen Vorschläge werd ich mal testen.

 

Tue das.

[=BT=Viper 11]

Versuch mal auf den noch betroffenen Clients gpresult /force zu machen, dann rebooten und schaun ob es besser ist. Wie ich mal gelesen habe werden Richtlinien beim Reboot nie komplett aktualisiert, sondern man benötigt 3 Reboots bis wirklich alles gemacht wurde. Daher könnte es kommen das einige Clients jetzt wieder laufen.

[Hannibal 10]

Hab auf meinen Client und beim Kollegen, sowie bei einem Normalouser das

erweiterte "Userenv Logging" eingeschaltet mit:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

UserEnvDebugLevel, REG_DWORD, 10002 (logfile + verbose)

 

Hab nun eine erfolgreiche Anmeldung von meinem und dem Client vom Kollegen

vorliegen und die fehlgeschlagene vom Normalo-user.

 

Als erster Unterschied ist mir aufgefallen das meine und die Anmeldung vom Kollega auf dem Logonserver, ich nennen ihn mal "sdc01", lief. Die Anmeldung

vom Normalouser lief auf dem "sdc02". (sdc01 und sdc02 beispielhaft als

Domäncontroller)

 

Ich glaub der "sdc02" braucht mal ein reboot...

Melde mich morgen wieder. :cool:

[Hannibal 10]

Guten morgen :P

 

Erstmal Danke für Eure Hilfe!

 

 

Der Reboot beider DCs hat nichts gebracht. Gestern Vormittag hatte ich eine

zündende Idee. Ich hab mir noch das Loginscript angeschaut und was das so

reibt um eine Ursache für die lahme Anmeldung zu finden.

 

Im Skript selbst fand ich nichts, bin aber die restlichen Einstellungen der GPO durchgegangen und bei der Option hängengeblieben "Anmeldeskripte gleichzeitig ausführen". Diese hab ich kurzhand deaktiviert und einen User angerufen der die 15min Anmeldeproblematik hatte.

 

Siehe da, die Anmeldung läuft durch. Habs noch mit paar anderen Problemfällen getestet, auch da erfolgreich.

 

Die Option hatten wir eingeschaltet, um zu verhindern das der User schon auf Netzlaufwerke zu greift obwohl sie noch nicht gemapped sind.

 

Es können nun Folgefehler durch das abschalten der Option entstehen, aber diese sind dann eher einfache Problemchen, bisher gibt es keine.

 

 

Soweit so gut, jetzt gibt immerhin der UHD Ruhe. Jetzt kann ich weiter orschen

wo das eigentliche Problem liegt.

 

Das Loginscript verweist recht früh auf unseren Fileservercluster. Vielleicht schüttelt der sich bei paar Nutzeranmeldungen. Den werd ich aber erst heute Nachmittag oder Freitag wenn keine Nutzer mehr arbeiten, rebooten.

 

Der Cluster liegt zb auch in der OU die ich versehentlich verschoben hatte.

Auch wenn das verschieben nur für ~20sek war, könnte da ein Problem entstanden sein.

[Hannibal 10]

Hi =)

 

Bisher hab ich von dem Reboot des Fileserverclusters, wo auch das

Anmeldeskript liegt, abgesehen, da nur noch paar User die "15min

Anmeldeproblematik" haben. Die restlichen User können sich ohne Probleme

anmelden.

 

Einen User hab ich mir gestern rausgesucht und bei seinem Client vor Ort ein

"gpupdate" gemacht und anschließend mit "rsop.msc" und "gpreuslt" alles

kontrolliert. Es sieht alles so aus wie bei einem Nachbar-Client wo es keine

Anmeldeprobleme gibt. Aber leider ohne Erfolg.

 

Hier im Board, sind Beiträge zur gleichen Problematik zufinden, die auf ein

Problem mit der WMI-Schnittstelle hindeuten. An dem besagten Client hab ich

im zweiten Schritt den WMI Dienste beendet und neugestartet, anschließend

wieder ein Reboot, wieder ohne Erfolg.

 

Ich hab an dem Client ein Testkonto zur Anmeldung ausprobiert, was ebenfals

der 15min Anmelung unterlag. Nehme ich meinen Domänen Adminaccount bin

ich innerhalb von wenigen Sekunden angemeldet. Ich sehe zb sofort nach der

Passwortbestättigung das Anmeldeskript durchflitzen.

 

 

Das verwirrende ist, das das Problem nicht bei allen Usern auftritt sondern

nur bei 5~10 Usern, wir haben hier weit über hundert User die sich täglich

anmelden.

 

Einen User hab ich bisher gefunden der erst das Problem hatte, wobei es am

Folgetag nicht mehr auftrat. An diesem Client ist nichts an "gpupdate" etc

gelaufen. Das Problem löst sich quasi von selbst.

 

Ich hab bei jedem User der sich bisher gemeldet hat, über die Registry

nachgeschaut, welchen Logonserver er genutzt hat.

(HKEY_User\<UserSID>\Volatile Environment" Schlüssel Logonserver)

 

Bisher haben alle den SDC02 drinstehen. Nur wurde diese und der SDC01

bereits letzte Woch neugestartet. An dem SDC02 melden sich nach wie

andere User ohne irgendein Problem an.

 

Ich überlege ob ich testweise das Benutzerprofil an besagtem Client mal

löschen um es neuanlegen zu lassen. Aber das sind mehr try&error Varianten...

 

Habt ihr noch eine Idee?

 

/EDIT

Ein falsch konfigurierter DNS Server liegt auch nicht vor. Sonst hätten viel mehr User

das Anmeldeproblem.