DC depromoten (ehemals Rolleninhaber)- DNS/Anmelde Problem

[PowerShellAdmin 169]

Hallo zusammen,

wir haben eine Domäne und in dieser soll der 1. DC entfernt werden.

 

1.Physikalischer DC & ehemlaiger Rolleninhaber

2.Virtuellen DC & neuen Rolleninhaber

3. Physikalischer DC - Backup

 

DHCP, DNC, Zerstelle etc ist alles erfolgreich portiert, jetzt hatte ich auf dem 1. System den DNS Server deinstalliert und den 2. DC neugestartet.

Ergebnis: 2. System funktioniert nicht mehr erfolgreich, Remote LSA Anmeldefehler. Weitere Systeme waren ebenfalls von der Störung betroffen.

Im Anschluss habe ich den DNS auf dem 1. DC wieder installiert -> alles funktioniert.

 

Die betroffenen Systeme hatten den 1. und 2. DC als DNS Server eingetragen. Nachdem ich den 3. DC eingetragen habe ging es.

Jetzt das große aber: Soweit der 1. DC läuft, funktioniert auch der DNS über den 2.DC => habe ich am Client getestet.

 

Innerhalb der Activedirectory Standorte und Dienste habe ich die 3DC eingetragen.

Jeder DC hat als Sync die andern beiden eingetragen.

Server1->Sync mit Server2,3

Server2->Sync mit Server1,3

Server3->Sync mit Server 1,2

 

Hinweis: Nicht alle Server innerhalb der Synceinstellung sind automatisch generiert - habe diese hier manuell ergänzt.

 

Grüße & vielen Dank

 

Admin

 

edit: Der 2. DC ist

1.Schemamaster

2.RID

3.PDC

4.Infrastruktur

5. Domainnaming Master:

Habe gesehen, dass er noch nicht als Betriebsmaster in den "Active Directory Vertrauenseinstellungen" gesetzt war - habe ihn hier jetzt ebenfalls gesetzt.

 

Das erklärt aber immer noch nicht, wieso die Server/Clients mit DC 3 im DNS sich anmelden konnten.

[Robi-Wan 10]

Hallo,

 

zählt zwar nicht zur Frage, aber: Rollen hast Du auch schon verschoben?

 

Prüfe auch in den DHCP-Einstellungen, welche DNS-Server verteilt werden. Ist das DNS in AD integriert? Setze das Syncen doch mal temporär auf "alle DNS-Server", warte eine Stunde und probiere es dann nochmal.

 

Grüße,

Robert

[PowerShellAdmin 169]

Habe es eben ergänzt, hatte die Domainaming Master Rolle verpennt.

Der DNS ist ADintegriert - die andern Rollen hatte ich schon vor "Monaten" verschoben.

 

Allerdings wundert es mich, wieso sich Clients anmelden können, welche den 3. DC als DNS eingetragen hatten.

DNS habe ich durchsucht - hier passen alle Einträge - überall stehen die 3DCs drinne.

[PowerShellAdmin 169]

Also der Fehler besteht noch und macht mir jetzt auch ein wenig Bauchweh.

Am Client erhalte ich folgenden Fehler

Ereignis ID 5719 - Quelle Netlogon

Wie kann das sein ?

 

Der Computer konnte eine sichere Sitzung mit einem Domänencontroller in der Domäne IMPETUS aufgrund der folgenden Ursache nicht einrichten: 
Es sind momentan keine Anmeldeserver zum Verarbeiten der Anmeldeanforderung verfügbar. 
Dies kann zu Authentifizierungsproblemen führen. Stellen Sie sicher, dass der Computer mit dem Netzwerk verbunden ist. Wenden Sie sich an den Domänenadministrator, wenn das Problem weiterhin besteht.  

ZUSÄTZLICHE INFORMATIONEN 
Wenn dieser Computer ein Domänencontroller der bestimmten Domäne ist, wird eine sichere Sitzung zum primären Domänencontrolleremulator in der bestimmten Domäne eingerichtet. Andernfalls richtet dieser Computer eine sichere Sitzung zu einem beliebigen Domänencontroller in der bestimmten Domäne ein.

 

Das Ganze geht soweit, dass sich Clients nur über Authentifizierung-also Outlookanywhere verbinden.

edit:

Ich habe jetzt sämtliche Rollen auf den 3. DC übertragen. Werde überprüfen ob das Problem dann weg ist.

Wie überprüfe ich am besten die Verbindung zwischen Client und Anmeldeserver ? DCDiag ?

edit2:

GPOUpdate am Client ohne Fehler

Netlogon Fehler ist weg

 

Wieso verlangt Outlook an manchen Rechnern eine Authentifizierung ?

bearbeitet 18. April 2012 von PowerShellAdmin

[PowerShellAdmin 169]

So kurzes Feedback:

Ursache war gestern die Störung der Anmeldeserver.

Der Exchange 2010 CAS Server hatte ein fehlerhaftes Eventlog - Auf dem Postfach/Hubserver war allerdings alles ok.

 

Neustart des CAS Servers hat sämtliche Probleme an den Outlookclients behoben.

 

Der irretierende Netlogonfehler trat bereits vorher auf, Ursache ist hier Clientseitig.

 

So kurzer Schreck in der Frühe :)

 

Grüße Admin