11
Jeden morgen das Selbe... Vertrauensstellungproblem, Replikationsproblem
Terminalserver, zwei DCs, einer virtuell, einer pyhsikalisch. Bei Anmeldung an TS kommt jeden morgen die Meldung: Die Vertrauensstellung zwischen dieser Arbeitsstation und der Primären Domäne konnte nicht hergestellt werden.
Guten Morgen,
ich weiß nicht mehr weiter. Eine lange Zeit funktioniere unser Micrsoft-Server Konstrukt ohne größere Probleme, momentan scheint jedoch alles zusammenzubrechen:
Ohne größere Probleme bedeutet: Ein MS Case und ein Beitrag hier im Forum:
Server in AD nicht auffindbar (Vertrauensstellung, Securechannel, UserControl)
Unser Setup:
WAN
|
Modem
|
Liss-Firwall-Appliance
|
IBM-XServer
(VMWare-ESXi)
- Server 1: 2008R2 DC, DHCP, DNS, GDATA-Console
- Server 2: 2008R2 Fileserver, Printserver
- Server 3: 2008R2 Exchange Server
- Server 4: 2008R2 Terminalserver
- Server 5: Ubuntu SSH-Server/Webserver (nicht in Domäne)
- Server 6: WinXP Testclient (in der Domäne)
- Server 7: 2008R2 Testmaschine (nicht in Domäne)
- Server 8: 2008R2 Sharepoint
Physikalisch
- Server 9: 2008R2 AD+FS für Windows-Sicherungen + AD-Replikation
Das Problem:
Morgens können sich Clients an der Domäne anmelden. Die User arbeiten jedoch vor Allem auf dem Terminalserver. Wenn die User sich verbinden wollen kommt nach dem Anmeldefenster:
"Die Vertrauensstellung zwischen dieser Arbeitsstation und der Primären Domäne konnte nicht hergestellt werden."
Ich behelfe mir momentan damit, den Server 4 aus der Domäne zu nehmen und nach dem Neustart wieder in die Domäne zu heben, danach wieder ein Neustart und man kann arbeiten. Für einen Tag, maximal zwei Tage.
Interessanterweise ist das Computerkonto in der AD zu diesem Zeitpunkt deaktiviert.
Die Historie:
Wir hatten vor einiger Zeit mit diesem Setup schon einmal ein Problem mit unserem DC. Damals (ca. ein halbes Jahr) war der Server so defekt durch eine abgebrochene Sicherung, dass wir den DC wieder herstellen mussten aus einer Sicherung (Zeitunterschied: ca. 48 Stunden).
Wir konnten damals keine Maschine mehr anmelden an die Domäne. Nachdem wir einen Dienstleister auf das Problem angesetzt hatten versuchten diese ca. 8 Stunden lang den DNS wieder auf Vordermann zu bekommen um dann einen Microsoft-Case aufzumachen (am nächsten Tag). Ein Supporter von Microsoft schaltete sich dann auf den Server auf und setzte das Secure-Channel Kennwort zurück und nach einigen Neustarts ging alles wieder.
Nach dieser Zeit kam es jeden Monat vor, dass (meines Erarchtens nach, willkürlich) ein Server nach dem anderen nicht mehr mit der Domäne kommunizieren wollte: erst der Fileserver, dann der Exchange-Server. Jedoch ließ sich dieses Problem nicht durch ein "aus der Domäne in die Domäne" wieder herstellen sondern nur durch das erneute zurücksetzen des Securechannel-Passwortes.
Meine Mutmaßung:
Aufgrund der nachstehenen Ereignis IDs, sieht es so aus - als ob der Server 1 und Server 9 sich nicht miteinander unterhalten können aus Zugriffs/Berechtigungsproblemen, daher wird die AD nicht richtig repliziert und daher scheint es Vertrauensstellungsprobleme in der Domäne zu geben. Weiterhin sieht es so aus, als ob der Server 4 sich anstatt an Server 1 anzumelden, an Server 9 anmeldet. Die Frage ist wie das Problem zu beheben ist, bzw. für dieses und zukünfigte Netzwerke zu verhindern ist.
Offene Frage:
Gibt es Secure-Channel Technisch eine Art Wartung auf die man achten muss als Administrator in einem bestimmten Turnus? Ist das ein normales Verhalten eines Windows-Netzwerkes wenn man nicht bestimmte Tasks nach ca. einem halben Jahr / Jahr durchführt?
Wir haben noch mehrere andere Netzwerke in dieser Art aufgebaut und ich habe nun einfach nur Angst, dass sich diese Szenarien wiederholen und ich nicht weiß was ich tun kann, daher bin ich um jeden Denkanstoß oder Lösungsansatz dankbar. Daher: Vielen Dank im voraus,
beste Grüße
Gregor Oelze
PS: Um die Frage nach auftauchenden Eventlog-IDs zu beantworten:
Server 1: DC
Protokollname: System
Quelle: Microsoft-Windows-DistributedCOM
Datum: 16.03.2012 10:43:32
Ereignis-ID: 10009
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Server 1
Beschreibung:
DCOM konnte mit dem Computer "Server 4.Domäne.local" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen.
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 16.03.2012 10:42:18
Ereignis-ID: 1925
Aufgabenkategorie:Konsistenzprüfung
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: ANONYMOUS-ANMELDUNG
Computer: Server 1.Domäne.local
Beschreibung:
Fehler beim Herstellen einer Replikationsverknüpfung mit der folgenden schreibbaren Verzeichnispartition.
Verzeichnispartition:
(...)
Standortübergreifende Übertragung (falls vorhanden):
Dieser Verzeichnisdienst kann nicht mit dem Quellverzeichnisdienst replizieren, solange das Problem nicht behoben ist.
Benutzeraktion
Überprüfen Sie, ob auf den Quellverzeichnisdienst zugegriffen werden kann und ob eine Netzwerkverbindung besteht.
Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
Protokollname: System
Quelle: Microsoft-Windows-Security-Kerberos
Datum: 16.03.2012 09:30:52
Ereignis-ID: 4
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Server 1.Domäne.local
Beschreibung:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "Server 4$" empfangen. Der verwendete Zielname war cifs/Server4.Domäne.local. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, dass der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN bei dem Konto registriert ist, das vom Server verwendet wird, und zwar ausschließlich bei diesem Konto. Dieser Fehler kann auch auftreten, wenn der Zieldienst ein anderes Kennwort für das Zieldienstkonto verwendet als das Kennwort, das vom Kerberos-KDC (Key Distribution Center) für das Zieldienstkonto verwendet wird. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des aktuellen Kennworts aktualisiert wurden. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (GSG.LOCAL) von der Clientdomäne (GSG.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
Server 4: Terminalserver
Protokollname: System
Quelle: Schannel
Datum: 15.03.2012 18:20:11
Ereignis-ID: 36888
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: Server 4.Domäne.local
Beschreibung:
Es wurde eine schwerwiegende Warnung generiert: 10. Der interne Fehlerstatus lautet: 10.
Protokollname: System
Quelle: LsaSrv
Datum: 15.03.2012 18:20:33
Ereignis-ID: 40961
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:
Benutzer: Domäne\ml
Computer: Server 4.Domäne.local
Beschreibung:
Das Sicherheitssystem konnte keine sichere Verbindung mit dem Server LDAP/Server 9.Domäne.local/Domäne.local@Domäne.LOCAL herstellen. Es war kein Authentifizierungsprotokoll verfügbar.
Ereignis-XML:
Server 9: Backup-DC
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 16.03.2012 10:57:18
Ereignis-ID: 1699
Aufgabenkategorie:Replikation
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Domäne\Server 1$
Computer: Server 9.Domäne.local
Beschreibung:
Dieser Verzeichnisdienst konnte die Änderungen für die folgende Verzeichnispartition nicht erstellen. Der Verzeichnisdienst war daher nicht in der Lage, die Änderungsanforderung an den Verzeichnisdienst der folgenden Netzwerkadresse zu senden.
Verzeichnispartition:
DC=Domäne,DC=local
Netzwerkadresse:
17b62fd2-e2b4-42ac-a2c2-6e796fe89a44._msdcs.Domäne.local
Erweiterter Anforderungscode:
Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
Guten Morgen,
ich weiß nicht mehr weiter. Eine lange Zeit funktioniere unser Micrsoft-Server Konstrukt ohne größere Probleme, momentan scheint jedoch alles zusammenzubrechen:
Ohne größere Probleme bedeutet: Ein MS Case und ein Beitrag hier im Forum:
Server in AD nicht auffindbar (Vertrauensstellung, Securechannel, UserControl)
Unser Setup:
WAN
|
Modem
|
Liss-Firwall-Appliance
|
IBM-XServer
(VMWare-ESXi)
- Server 1: 2008R2 DC, DHCP, DNS, GDATA-Console
- Server 2: 2008R2 Fileserver, Printserver
- Server 3: 2008R2 Exchange Server
- Server 4: 2008R2 Terminalserver
- Server 5: Ubuntu SSH-Server/Webserver (nicht in Domäne)
- Server 6: WinXP Testclient (in der Domäne)
- Server 7: 2008R2 Testmaschine (nicht in Domäne)
- Server 8: 2008R2 Sharepoint
Physikalisch
- Server 9: 2008R2 AD+FS für Windows-Sicherungen + AD-Replikation
Das Problem:
Morgens können sich Clients an der Domäne anmelden. Die User arbeiten jedoch vor Allem auf dem Terminalserver. Wenn die User sich verbinden wollen kommt nach dem Anmeldefenster:
"Die Vertrauensstellung zwischen dieser Arbeitsstation und der Primären Domäne konnte nicht hergestellt werden."
Ich behelfe mir momentan damit, den Server 4 aus der Domäne zu nehmen und nach dem Neustart wieder in die Domäne zu heben, danach wieder ein Neustart und man kann arbeiten. Für einen Tag, maximal zwei Tage.
Interessanterweise ist das Computerkonto in der AD zu diesem Zeitpunkt deaktiviert.
Die Historie:
Wir hatten vor einiger Zeit mit diesem Setup schon einmal ein Problem mit unserem DC. Damals (ca. ein halbes Jahr) war der Server so defekt durch eine abgebrochene Sicherung, dass wir den DC wieder herstellen mussten aus einer Sicherung (Zeitunterschied: ca. 48 Stunden).
Wir konnten damals keine Maschine mehr anmelden an die Domäne. Nachdem wir einen Dienstleister auf das Problem angesetzt hatten versuchten diese ca. 8 Stunden lang den DNS wieder auf Vordermann zu bekommen um dann einen Microsoft-Case aufzumachen (am nächsten Tag). Ein Supporter von Microsoft schaltete sich dann auf den Server auf und setzte das Secure-Channel Kennwort zurück und nach einigen Neustarts ging alles wieder.
Nach dieser Zeit kam es jeden Monat vor, dass (meines Erarchtens nach, willkürlich) ein Server nach dem anderen nicht mehr mit der Domäne kommunizieren wollte: erst der Fileserver, dann der Exchange-Server. Jedoch ließ sich dieses Problem nicht durch ein "aus der Domäne in die Domäne" wieder herstellen sondern nur durch das erneute zurücksetzen des Securechannel-Passwortes.
Meine Mutmaßung:
Aufgrund der nachstehenen Ereignis IDs, sieht es so aus - als ob der Server 1 und Server 9 sich nicht miteinander unterhalten können aus Zugriffs/Berechtigungsproblemen, daher wird die AD nicht richtig repliziert und daher scheint es Vertrauensstellungsprobleme in der Domäne zu geben. Weiterhin sieht es so aus, als ob der Server 4 sich anstatt an Server 1 anzumelden, an Server 9 anmeldet. Die Frage ist wie das Problem zu beheben ist, bzw. für dieses und zukünfigte Netzwerke zu verhindern ist.
Offene Frage:
Gibt es Secure-Channel Technisch eine Art Wartung auf die man achten muss als Administrator in einem bestimmten Turnus? Ist das ein normales Verhalten eines Windows-Netzwerkes wenn man nicht bestimmte Tasks nach ca. einem halben Jahr / Jahr durchführt?
Wir haben noch mehrere andere Netzwerke in dieser Art aufgebaut und ich habe nun einfach nur Angst, dass sich diese Szenarien wiederholen und ich nicht weiß was ich tun kann, daher bin ich um jeden Denkanstoß oder Lösungsansatz dankbar. Daher: Vielen Dank im voraus,
beste Grüße
Gregor Oelze
PS: Um die Frage nach auftauchenden Eventlog-IDs zu beantworten:
Server 1: DC
Protokollname: System
Quelle: Microsoft-Windows-DistributedCOM
Datum: 16.03.2012 10:43:32
Ereignis-ID: 10009
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Server 1
Beschreibung:
DCOM konnte mit dem Computer "Server 4.Domäne.local" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen.
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 16.03.2012 10:42:18
Ereignis-ID: 1925
Aufgabenkategorie:Konsistenzprüfung
Ebene: Warnung
Schlüsselwörter:Klassisch
Benutzer: ANONYMOUS-ANMELDUNG
Computer: Server 1.Domäne.local
Beschreibung:
Fehler beim Herstellen einer Replikationsverknüpfung mit der folgenden schreibbaren Verzeichnispartition.
Verzeichnispartition:
(...)
Standortübergreifende Übertragung (falls vorhanden):
Dieser Verzeichnisdienst kann nicht mit dem Quellverzeichnisdienst replizieren, solange das Problem nicht behoben ist.
Benutzeraktion
Überprüfen Sie, ob auf den Quellverzeichnisdienst zugegriffen werden kann und ob eine Netzwerkverbindung besteht.
Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
Protokollname: System
Quelle: Microsoft-Windows-Security-Kerberos
Datum: 16.03.2012 09:30:52
Ereignis-ID: 4
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: Server 1.Domäne.local
Beschreibung:
Der Kerberos-Client hat einen KRB_AP_ERR_MODIFIED-Fehler von Server "Server 4$" empfangen. Der verwendete Zielname war cifs/Server4.Domäne.local. Dies deutet darauf hin, dass der Zielserver das vom Client bereitgestellte Token nicht entschlüsseln konnte. Dies kann auftreten, wenn der Ziel-Serverprinzipalname (SPN) nicht bei dem Konto registriert ist, dass der Zieldienst verwendet. Stellen Sie sicher, dass der Ziel-SPN bei dem Konto registriert ist, das vom Server verwendet wird, und zwar ausschließlich bei diesem Konto. Dieser Fehler kann auch auftreten, wenn der Zieldienst ein anderes Kennwort für das Zieldienstkonto verwendet als das Kennwort, das vom Kerberos-KDC (Key Distribution Center) für das Zieldienstkonto verwendet wird. Stellen Sie sicher, dass der Dienst auf dem Server und im KDC beide für die Verwendung des aktuellen Kennworts aktualisiert wurden. Wenn der Servername nicht vollqualifiziert ist und sich die Zieldomäne (GSG.LOCAL) von der Clientdomäne (GSG.LOCAL) unterscheidet, prüfen Sie, ob sich in diesen beiden Domänen Serverkonten mit gleichem Namen befinden, oder verwenden Sie den vollqualifizierten Namen, um den Server zu identifizieren.
Server 4: Terminalserver
Protokollname: System
Quelle: Schannel
Datum: 15.03.2012 18:20:11
Ereignis-ID: 36888
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: Server 4.Domäne.local
Beschreibung:
Es wurde eine schwerwiegende Warnung generiert: 10. Der interne Fehlerstatus lautet: 10.
Protokollname: System
Quelle: LsaSrv
Datum: 15.03.2012 18:20:33
Ereignis-ID: 40961
Aufgabenkategorie:Keine
Ebene: Warnung
Schlüsselwörter:
Benutzer: Domäne\ml
Computer: Server 4.Domäne.local
Beschreibung:
Das Sicherheitssystem konnte keine sichere Verbindung mit dem Server LDAP/Server 9.Domäne.local/Domäne.local@Domäne.LOCAL herstellen. Es war kein Authentifizierungsprotokoll verfügbar.
Ereignis-XML:
Server 9: Backup-DC
Protokollname: Directory Service
Quelle: Microsoft-Windows-ActiveDirectory_DomainService
Datum: 16.03.2012 10:57:18
Ereignis-ID: 1699
Aufgabenkategorie:Replikation
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Domäne\Server 1$
Computer: Server 9.Domäne.local
Beschreibung:
Dieser Verzeichnisdienst konnte die Änderungen für die folgende Verzeichnispartition nicht erstellen. Der Verzeichnisdienst war daher nicht in der Lage, die Änderungsanforderung an den Verzeichnisdienst der folgenden Netzwerkadresse zu senden.
Verzeichnispartition:
DC=Domäne,DC=local
Netzwerkadresse:
17b62fd2-e2b4-42ac-a2c2-6e796fe89a44._msdcs.Domäne.local
Erweiterter Anforderungscode:
Zusätzliche Daten
Fehlerwert:
8453 Der Replikationszugriff wurde verweigert.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 182119
Url: https://administrator.de/forum/jeden-morgen-das-selbe-vertrauensstellungproblem-replikationsproblem-182119.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
11 Kommentare
Neuester Kommentar
Nur eine Mutmaßung:
Bei der genannten Wiederherstellung des DC ist damals irgendwas nicht sauber gelaufen. In Richtung der Namen oder so.
Ich würde die Flucht nach vorne antreten. 2 neue (!) DC in die Domäne reinhängen. Neu heißt hier explizit neue Namen der DC. Wie sie noch nie in der Domäne waren.
Wenn alles repliziert ist (Domäne, DNS, Sysvol), dann die Clients auf die neuen Server als DNS umstellen (ich nehme an, dass die DC auch DNS sind).
Dann die alten DC demoten. Wenn sie sonst keine Aufgaben mehr haben, dann raus aus dem Netz. Wenn doch, auch nicht schlimm, solange die keine DC mehr sind.
Dann beobachten. Wenn díe Probleme damit weg sind (ggf. jeden Server maximal noch einmal neu in die Domäne eintreten lassen), dann lag es daran.
Bei der genannten Wiederherstellung des DC ist damals irgendwas nicht sauber gelaufen. In Richtung der Namen oder so.
Ich würde die Flucht nach vorne antreten. 2 neue (!) DC in die Domäne reinhängen. Neu heißt hier explizit neue Namen der DC. Wie sie noch nie in der Domäne waren.
Wenn alles repliziert ist (Domäne, DNS, Sysvol), dann die Clients auf die neuen Server als DNS umstellen (ich nehme an, dass die DC auch DNS sind).
Dann die alten DC demoten. Wenn sie sonst keine Aufgaben mehr haben, dann raus aus dem Netz. Wenn doch, auch nicht schlimm, solange die keine DC mehr sind.
Dann beobachten. Wenn díe Probleme damit weg sind (ggf. jeden Server maximal noch einmal neu in die Domäne eintreten lassen), dann lag es daran.
@emeriks
Hi und danke für die schnelle Antwort. Ich wollte diesen Punkt eigentlich komplett umgehen, da es natürlich ein wenig mehr als "nur die AD zu replizieren".
Wenn ich es richtig interpretiere meldet sich der Terminalserver anstatt an Server 1 anzumelden, an Server 9 an. Dieser hat jedoch aufgrund eines Berechtigungsproblemes nicht die aktuelle Version der AD, sondern nur ein altes Replikat. Ich denke dass dadurch dann auch das Vertrauensstellungproblem herrscht (Da zwei verschiedene DCs die gleiche Domäne betreuen aber verschiedene Zeitstempel, Versionsnummer, ??!?)
Ist das aufgrund der aufgeführten IDs zu weit hergeholt?
Wie kann man das Berechtigungsproblem zwischen den DCs näher auf den Grund gehen?
Hi und danke für die schnelle Antwort. Ich wollte diesen Punkt eigentlich komplett umgehen, da es natürlich ein wenig mehr als "nur die AD zu replizieren".
Wenn ich es richtig interpretiere meldet sich der Terminalserver anstatt an Server 1 anzumelden, an Server 9 an. Dieser hat jedoch aufgrund eines Berechtigungsproblemes nicht die aktuelle Version der AD, sondern nur ein altes Replikat. Ich denke dass dadurch dann auch das Vertrauensstellungproblem herrscht (Da zwei verschiedene DCs die gleiche Domäne betreuen aber verschiedene Zeitstempel, Versionsnummer, ??!?)
Ist das aufgrund der aufgeführten IDs zu weit hergeholt?
Wie kann man das Berechtigungsproblem zwischen den DCs näher auf den Grund gehen?
nur durch das erneute zurücksetzen des Securechannel-Passwortes
Wenn Du damit das Problem vorrübergehend abschalten kannst, dann tu es, repliziere die vorhandenen DC und dann die neuen rein.
Das iegentliche Problem, das dir droht, ist viel schwerwiedender: Wenn die Replikation mal länger als die tombstone lifetime aussetzt, dann replizieren die DC nie wieder miteinander.
Wenn Du die vorhandenen DC nicht nmehr dazu bekommst, sich zu replizieren, dann hast Du sowieso ein Problem, weil die ja nicht mehr synchron sind. Dann würde ich einen von beiden "kalt stellen" (offline nehmen) und mit dem verbleibenden einen weiteren DC promoten. Welchen Du da rausnimmst, musst Du danach entscheiden, wer scheinbar am aktuellsten ist. Bzw.:
Wie sind z.Z. die Rollen verteilt, wer ist Global Catalog?
Am Rande: Die Urzeiten + Zeitzonen aller Server passen aber?
Salve,
@emeriks....
take a look
ich mein, hat er zwar dazu geschrieben, sollte aber trotzdem was für deine Augen sein.
ok -vielleicht - außer Frank hat da was dagegen....
den M$ Fall kannste knicken, glaubs mir....
Denn irgendwann ist Feierabend, ich dachte tatsächlich, der olle Beitrag wäre nur vergessen worden, aber dem ist ja leider nicht so.
Ich sags mal frei raus - da schaut sich ein echter Profi zwei Stunden den DC Server klimbim an, bestellt ne große Tonne Kaffebohnen und werkelt das an einem Wochenende ab.
Und bitte nicht falsch verstehen - ich hab nen Job, Frau Kind 3 englische Autos und ein paar andere Spielsachen, ich hab keine Zeit.
Gruß
@emeriks....
take a look
ich mein, hat er zwar dazu geschrieben, sollte aber trotzdem was für deine Augen sein.
ok -vielleicht - außer Frank hat da was dagegen....
den M$ Fall kannste knicken, glaubs mir....
- wo ist denn eurer Firma?
Denn irgendwann ist Feierabend, ich dachte tatsächlich, der olle Beitrag wäre nur vergessen worden, aber dem ist ja leider nicht so.
Ich sags mal frei raus - da schaut sich ein echter Profi zwei Stunden den DC Server klimbim an, bestellt ne große Tonne Kaffebohnen und werkelt das an einem Wochenende ab.
Und bitte nicht falsch verstehen - ich hab nen Job, Frau Kind 3 englische Autos und ein paar andere Spielsachen, ich hab keine Zeit.
Gruß
Zitat von @60730:
Salve,
@emeriks....
take a look
ich mein, hat er zwar dazu geschrieben, sollte aber trotzdem was für deine Augen sein.
ok -vielleicht - außer Frank hat da was dagegen....
Salve,
@emeriks....
take a look
ich mein, hat er zwar dazu geschrieben, sollte aber trotzdem was für deine Augen sein.
ok -vielleicht - außer Frank hat da was dagegen....
Wer ist Frank?
den M$ Fall kannste knicken, glaubs mir....
- wo ist denn eurer Firma?
Der Microsoft Case wurde geöffnet, bearbeitet und geschlossen in weniger als 3 Stunden. Die eigentliche Arbeit an dem Server lag bei nicht mal einer Stunde. In dieser Zeit hatte der Techniker wirklich nur den Secure Channel zurückgesetzt und danach ging es wieder. Vorher ging gar nichts mehr. Mein Problem ist, dass der Dienstleister ("ein Team von Profis") 10 Stunden aufgeschaltet waren (zusammen mit mir) und es im Endeffekt nicht geschafft haben. Deshalb bin ich gerade sehr vorsichtig da diese 10 Stunden natürlich auch sehr teuer gewesen sind. Solche Dinge können immer mal wieder auch bei einem Kunden vorkommen, und da möchte ich natürlich darauf vorbereitet sein.
Denn irgendwann ist Feierabend, ich dachte tatsächlich, der olle Beitrag wäre nur vergessen worden, aber dem ist ja
leider nicht so.
Ich sags mal frei raus - da schaut sich ein echter Profi zwei Stunden den DC Server klimbim an, bestellt ne große Tonne
Kaffebohnen und werkelt das an einem Wochenende ab.
leider nicht so.
Ich sags mal frei raus - da schaut sich ein echter Profi zwei Stunden den DC Server klimbim an, bestellt ne große Tonne
Kaffebohnen und werkelt das an einem Wochenende ab.
So gerne ich das machen wollte: Der Stolz und der Bammel vor erneuten 10 Stunden à 120€ für nichts + den Willen zu lernen halten mich davon ab, außerdem wüsste ich nicht wen ich fragen sollte.
Und bitte nicht falsch verstehen - ich hab nen Job, Frau Kind 3 englische Autos und ein paar andere Spielsachen, ich hab keine
Zeit.
Zeit.
Glaube ich dir. Ich bin dir ja schon dankbar, dass du so konsequent die Beiträge parst und einen Senf dazu gibst.
Salü,
Frank ist derjenige, der hier die kappe auf hat.
Und nein - sowas muß man wirklich vor Ort machen, denn da müssen/sollten alle anderen Server/clients usw, die in der AD hängen aus sein.
Deswegen schrub ich auch - wo ist die Firma.
Ich krieg schon nen kleinen Anfall, wenn ich per DSL auf meine Kiste muß und ich nur einen Bildschirm hab.
So arbeitet man heute in so ner Situation nicht mehr.
Hmm, was haben denn die Profis in den 10 Stunden gemacht?
Also ich würde mir ansehen, welcher Kasten die beste AD Struktur hat, versuchen die anderen DCs sauber oder mit dem Holzhammer rauszuwerfen, einen bereits vorbereiteten - wenn auch virtuell oder anders temporäre Kiste als DC/DNS GC usw. wieder dazu nehmen.
Ne Nacht warten - schauen obs nun wieder repliziert und dann alle Server testen und oder die dcs, die sein müssen wieder zu reaktivieren.
Also zwei Tage angefangen am Samstag 9.00 bis k.a und Ende Sonntag 14.00.
(wenn du wüsstest, was ich heute zwischen 7.30 und 17.45 gezaubert hab.....)
Das sind knapp 10 Stunden gewesen - da reisst man Bäume aus, baut eine Gartenhütte und pflanzt neue.
(nein ich hab ne komplette Infrastruktur umgehoben)
Gruß
Frank ist derjenige, der hier die kappe auf hat.
Und nein - sowas muß man wirklich vor Ort machen, denn da müssen/sollten alle anderen Server/clients usw, die in der AD hängen aus sein.
Deswegen schrub ich auch - wo ist die Firma.
Ich krieg schon nen kleinen Anfall, wenn ich per DSL auf meine Kiste muß und ich nur einen Bildschirm hab.
So arbeitet man heute in so ner Situation nicht mehr.
Hmm, was haben denn die Profis in den 10 Stunden gemacht?
Also ich würde mir ansehen, welcher Kasten die beste AD Struktur hat, versuchen die anderen DCs sauber oder mit dem Holzhammer rauszuwerfen, einen bereits vorbereiteten - wenn auch virtuell oder anders temporäre Kiste als DC/DNS GC usw. wieder dazu nehmen.
Ne Nacht warten - schauen obs nun wieder repliziert und dann alle Server testen und oder die dcs, die sein müssen wieder zu reaktivieren.
Also zwei Tage angefangen am Samstag 9.00 bis k.a und Ende Sonntag 14.00.
(wenn du wüsstest, was ich heute zwischen 7.30 und 17.45 gezaubert hab.....)
Das sind knapp 10 Stunden gewesen - da reisst man Bäume aus, baut eine Gartenhütte und pflanzt neue.
(nein ich hab ne komplette Infrastruktur umgehoben)
Gruß
Sag ich doch ...!
hab ich nicht gehört, ich hab nur
und mit dem verbleibenden einen weiteren DC promoten.
gelesen Aber jeder macht das wohl anders
Hoffentlich findet er jemanden
Gruß
Moin,
Also nochmal kurz...
Backup des dcs mit den meisten rollen
Aufmalen der struktur
Ueberlegen, ob struktur passt
Speziell in sites & services
Schema auf allen dcs ueberpruefen
Ueberlegen, nachsehen, ob ne schemaerweiterung wegen sap cti oder xyz gemacht wurde
Dump des dns gedoehns
Einen dc nach dem anderen sauber, oder unsauber rauskicken und kiste umbenennen.
Im falles, das die keine fileserver sind.
Wenn doch siehe punkt struktur ueberdenken.
Via adsiedit die vorher bemangelten werte grade biegen
Eine ganz neue kiste mit dem os aufsetzen, das auf den dcs ueblich ist
Den patchen, in die domain werfen und als dc/dns einrichten.
Die ersten 24 stunden das fail von dcdiag ignorieren, denn das ist normal.
Passt es nach 24 stunden, einen dc (wenn es standorte gibt) wieder dazu.
Wie immer neuer name, neue kiste.das blech kannste ja behalten.
Ueberlegen - siehe oben, ob bridgehead sinn macht oder nicht und das einrichten, oder nicht.
Abwarten, tee trinken und alles dokumentieren.
Das wars im groben von mir aus der badewanne.
Du siehst, das ist kein hexenwerk, aber um das wirklich haargenauso zu machen, wie es noetig ist, musss man das live sehen und braucht einen ansprechpartner, der einem auffallende ungereimtheiten erklaert oder der sagt, war keine absicht, hau wech stoert nur.
Wer da luecken findet,mdarf und sollte die fuellen, ich lass jetzt das badewasser ab und geh an die werkbank.
Wird n stressiger tag, rechne nicht damit, dass ich heute wieder reinschaue
Gruss
Also nochmal kurz...
Backup des dcs mit den meisten rollen
Aufmalen der struktur
Ueberlegen, ob struktur passt
Speziell in sites & services
Schema auf allen dcs ueberpruefen
Ueberlegen, nachsehen, ob ne schemaerweiterung wegen sap cti oder xyz gemacht wurde
Dump des dns gedoehns
Einen dc nach dem anderen sauber, oder unsauber rauskicken und kiste umbenennen.
Im falles, das die keine fileserver sind.
Wenn doch siehe punkt struktur ueberdenken.
Via adsiedit die vorher bemangelten werte grade biegen
Eine ganz neue kiste mit dem os aufsetzen, das auf den dcs ueblich ist
Den patchen, in die domain werfen und als dc/dns einrichten.
Die ersten 24 stunden das fail von dcdiag ignorieren, denn das ist normal.
Passt es nach 24 stunden, einen dc (wenn es standorte gibt) wieder dazu.
Wie immer neuer name, neue kiste.das blech kannste ja behalten.
Ueberlegen - siehe oben, ob bridgehead sinn macht oder nicht und das einrichten, oder nicht.
Abwarten, tee trinken und alles dokumentieren.
Das wars im groben von mir aus der badewanne.
Du siehst, das ist kein hexenwerk, aber um das wirklich haargenauso zu machen, wie es noetig ist, musss man das live sehen und braucht einen ansprechpartner, der einem auffallende ungereimtheiten erklaert oder der sagt, war keine absicht, hau wech stoert nur.
Wer da luecken findet,mdarf und sollte die fuellen, ich lass jetzt das badewasser ab und geh an die werkbank.
Wird n stressiger tag, rechne nicht damit, dass ich heute wieder reinschaue
Gruss
Zitat von @60730:
Moin,
Also nochmal kurz...
Backup des dcs mit den meisten rollen
Aufmalen der struktur
Ueberlegen, ob struktur passt
Speziell in sites & services
Schema auf allen dcs ueberpruefen
Ueberlegen, nachsehen, ob ne schemaerweiterung wegen sap cti oder xyz gemacht wurde
Dump des dns gedoehns
Einen dc nach dem anderen sauber, oder unsauber rauskicken und kiste umbenennen.
Im falles, das die keine fileserver sind.
Wenn doch siehe punkt struktur ueberdenken.
Via adsiedit die vorher bemangelten werte grade biegen
Eine ganz neue kiste mit dem os aufsetzen, das auf den dcs ueblich ist
Den patchen, in die domain werfen und als dc/dns einrichten.
Die ersten 24 stunden das fail von dcdiag ignorieren, denn das ist normal.
Passt es nach 24 stunden, einen dc (wenn es standorte gibt) wieder dazu.
Wie immer neuer name, neue kiste.das blech kannste ja behalten.
Ueberlegen - siehe oben, ob bridgehead sinn macht oder nicht und das einrichten, oder nicht.
Abwarten, tee trinken und alles dokumentieren.
Das wars im groben von mir aus der badewanne.
Du siehst, das ist kein hexenwerk, aber um das wirklich haargenauso zu machen, wie es noetig ist, musss man das live sehen und
braucht einen ansprechpartner, der einem auffallende ungereimtheiten erklaert oder der sagt, war keine absicht, hau wech stoert
nur.
Wer da luecken findet,mdarf und sollte die fuellen, ich lass jetzt das badewasser ab und geh an die werkbank.
Wird n stressiger tag, rechne nicht damit, dass ich heute wieder reinschaue
Gruss
Moin,
Also nochmal kurz...
Backup des dcs mit den meisten rollen
Aufmalen der struktur
Ueberlegen, ob struktur passt
Speziell in sites & services
Schema auf allen dcs ueberpruefen
Ueberlegen, nachsehen, ob ne schemaerweiterung wegen sap cti oder xyz gemacht wurde
Dump des dns gedoehns
Einen dc nach dem anderen sauber, oder unsauber rauskicken und kiste umbenennen.
Im falles, das die keine fileserver sind.
Wenn doch siehe punkt struktur ueberdenken.
Via adsiedit die vorher bemangelten werte grade biegen
Eine ganz neue kiste mit dem os aufsetzen, das auf den dcs ueblich ist
Den patchen, in die domain werfen und als dc/dns einrichten.
Die ersten 24 stunden das fail von dcdiag ignorieren, denn das ist normal.
Passt es nach 24 stunden, einen dc (wenn es standorte gibt) wieder dazu.
Wie immer neuer name, neue kiste.das blech kannste ja behalten.
Ueberlegen - siehe oben, ob bridgehead sinn macht oder nicht und das einrichten, oder nicht.
Abwarten, tee trinken und alles dokumentieren.
Das wars im groben von mir aus der badewanne.
Du siehst, das ist kein hexenwerk, aber um das wirklich haargenauso zu machen, wie es noetig ist, musss man das live sehen und
braucht einen ansprechpartner, der einem auffallende ungereimtheiten erklaert oder der sagt, war keine absicht, hau wech stoert
nur.
Wer da luecken findet,mdarf und sollte die fuellen, ich lass jetzt das badewasser ab und geh an die werkbank.
Wird n stressiger tag, rechne nicht damit, dass ich heute wieder reinschaue
Gruss
Hallo Timo,
erst einmal danke ich dir für deine immer wiederkehrenden guten Ratschläge.
Nachdem mittlerweile so viel Zeit vergangen ist habe ich das Problem nun (wenigstens ansatzweise verstanden)..
Die Fehlerquelle war (oder ist) Securechannel / Replikation :
Der physikalische Server war als Backupserver gedacht und daher hat dieser auch eine Replikation der AD inne.
Nachdem ich über den force-command den Server demoted habe und den Server (zwei mal!) neugestartet hatte, ist
das Problem plötzlich nicht mehr aufgetaucht.
Das Problem war also die Replikation zwischen den beiden DCs. Die Replikation konnte nicht durchgeführt werden, da ein Kennwort oder eine Berechtigung zwischen den beiden DCs nicht stimmte. In diesem Zusammenhang denke ich dass dies mit dem Computerkennwort zusammenhängt, welches ablaufen kann und dann Vertrauensstellungsfehler verursacht.
Nun, seit dem Entfernen des zweiten DCs aus der Domäne, läuft das Netzwerk rund und ohne jegliche schwerwiegende Probleme.
Ich setze diesen Thread als beantwortet (stelle aber trotzdem noch eine Frage).
- Was ist im Allgemeinen bei der Replikaton zwischen zwei DCs bei der Einrichtung zu beachten?
- Was sind die MFUs oder die Fault-Pas in diesem Zusammenhang?
Liebe Grüße und vielen Dank an Alle die Zeit in die Beantwortung der Fragen gesteckt haben.
Anaxagoras83
Hallo Anaxagoras83,
ich habe jetzt das selbe Problem, wie du damals hattest. Den Computer Account auf der einen Seite zurücksetzen brachte mir bislang leider kein Erfolg.
Muss der "netdom resetpwd" Befehl auf beiden DCs durchgeführt werden?
Diesen Hinweis konnte ich leider noch auf keiner Seite lesen.
Nach meinem Kenntnisstand ist die Einrichtung die ich bislang im Einblick hatte, korrekt. Das Problem ist leider nur der Abgleich zwischen den beiden Standorten.
Ich danke dir schon mal für ein guten Tipp
Gruß Cramens
ich habe jetzt das selbe Problem, wie du damals hattest. Den Computer Account auf der einen Seite zurücksetzen brachte mir bislang leider kein Erfolg.
Muss der "netdom resetpwd" Befehl auf beiden DCs durchgeführt werden?
Diesen Hinweis konnte ich leider noch auf keiner Seite lesen.
Nach meinem Kenntnisstand ist die Einrichtung die ich bislang im Einblick hatte, korrekt. Das Problem ist leider nur der Abgleich zwischen den beiden Standorten.
Ich danke dir schon mal für ein guten Tipp
Gruß Cramens
