14
DC - AD Totalschaden?
Hallo in die Runde,
ich habe folgendes Problem bei einem Kunden:
Kunde XY hat noch Server 2012R2, Kerio, AD, DNS, DHCP, Branchensoftware, Lexware, etc. läuft alles auf einem Blech, nichts virtualisiert. Ich hatte vor kurzem schon mal den neuen Hyper-V Host eingerichtet und "hingestellt". Darauf wurde auch eine notdürftige VM für SFIRM eingerichtet, damit die neue Version verwendet werden kann.
Das ActiveDirectory ist um es simpel auszudrücken "völlig kaputt". So weit ich das verfolgen kann, Doku gibt es nicht, ITler der das vorher verwaltet hat gibt es nicht mehr, nichts...war es früher ein SBS 2011, der wurde wohl auf einen Server 2012 Essentinals migriert, und danach auf Server 2012 R2 Standard. Mehr kann ich leider nicht sagen.
Backups gab es nicht mehr, es wurde zwar ein Band gewechselt, aber seit Jahren lief da kein Backup...naja, so ist das halt. Zumindest ein Backup gibt es nun...Angst gibt es da immer...vor allem da ich nicht gerade mit Kerio bewandert bin...und alles sehr gefrickelt dort ist (fängt bei der Verkabelung an, bis hin
Das Blech ist völlig veraltet, alter Xeon von 2008 meine ich, 16 GB DDR3, SAN mit 8 TB (das beste daran...), also insgesamt einfach nicht mehr aktuell. Das neue Blech ist da etwas potenter aufgestellt.
Dem Kunde habe ich mitgeteilt, dass da sehr wahrscheinlich die ganze Domäne neu hochgezogen werden muss, 2 Wochen zwischen den Jahren wird das benötigen, die Zeit davor nutze ich natürlich für Vorarbeiten...mit den Softwareanbietern abklären, etc. M365 soll auch eingeführt werden, aber das würde ich danach anpeilen, natürlich das AD schon entsprechend vorbereiten, passender UPN, etc. für den Sync.
An einem Wochenende würde ich das bestehende Blech virtualisieren schon mal, ich hatte das ohne NIC über Veeam in HyperV gestetet, das lief soweit...ich habe schon gelesen, dass das virtualisieren eines "Blech-DCs" Risiken birgt...Zwischenfrage...wie seht ihr das? Natürlich herunterfahren des Bleches vor Hochfahren der VM...
Dann wäre ich etwas flexibler und "sicherer", am liebsten würde ich natürlich die Domäne, User, etc. einfach migrieren wie üblich...
Jetzt zum eigentlichen Fehler auf dem DC:
Nach dem Anmelden öffnet sich schon mal das Essentinals-Dashobard obwohl es gar kein Essentinals mehr ist...für die Ersteinrichtung. Der eigentliche Server-Manager öffnet sich ganz normal, Essentinals ist dort auch als Rolle installiert und grau hinterlegt.
Wenn ich das AD Benutzerverzeichnis öffnen will erhalten ich die Meldung:
Active Directory-Domänendienste
Auf das Verzeichnisschema kann aufgrund folgenden Problems nicht zugegriffen werden:
Der übermittelte Verzeichnispfad ist ungültig.
Möglicherweise ist das Menü "Neu" fehlerhaft, und die Erweiterungs-Snap-Ins funktionieren möglicherweise nicht ordnungsgemäß.
Nach Klick auf OK:
Active Directory-Domänendienste
Aufgrund folgenden Problems können die Daten von "Active Directory-Benutzer und -Computer [meindc.domain.local]" derzeit nicht von Domänencontroller "meindc.domain.local" abgerufen werden:
"Der Benutzername oder das Kennwort ist falsch.
"Wiederholen Sie den Vorgang zu einem späteren Zeitpunkt, oder wählen Sie über das Domänenkontextmenü mit dem Befehl "Verbindung zum Domänencontroller herstellen" einen anderen Domänencontroller.
Dann öffnet sich MMC leer, keine Verbindung zum AD-Verzeichnis...
Einen anderen User gibt es nicht, er ist auf jeden Fall auch DER Administrator-Zugang...
Im Eventlog finde ich leider auch sehr viele Fehler von der Art:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Die Authentifizierung von Windows war für den Active Directory-Dienst auf einem Domänencontroller nicht möglich. (Fehler beim Aufruf der Funktion zur LDAP-Bindung). Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". ID 1006
...
An der Stelle weiß ich nun nicht weiter, ich habe mich damit abgefunden alles neu hochziehen zu müssen, es sind knapp 15 Arbeitsplätze, daher von der Menge verkraftbar...aber schöner wäre natürlich die Domäne zu migrieren.
Meine Gedanken hierzu:
Erst virtualisieren? Damit ein Snapshot schnell den alten Stand wiederherstellen kann...
Testweise das Essentinals Setup "durchklicken" endet leider auch in einem Fehler...aber bei der Standard-Version vermutlich logisch...
Oder...die Essentinals Rolle versuchen "runterzuprügeln"? Im Server Manager ist die grau hinterlegt...vllt. per PowerShell..?
In-Place auf 2016 / 2019 probieren?
Das Anmelden von Benutzern, Einbinden von neuen Clients, Rechte, etc. das läuft alles...aber nur was Bestand hat.
Via PowerShell kann ich dort auch nichts bewirken leider...
Ich weiß, da hilft auch eine Glaskugel nichts mehr, aber vllt. kennt jemand das Problem?
Das ist leider mein schlimmster Fall...vllt. habt ihr Ideen dazu oder schon mal etwas Ähnliches "durchgemacht"?
Wenn noch Infos benötigt werden lasst es mich wissen...wie gesagt, gehe ich da von dem Schlimmsten aus.
Vielen Dank schon mal.
Beste Grüße euch
Nachtrag von mir - tut mir leid für das Spammen:
Im DNS-Eventlog taucht folgender Fehler auf:
Der DNS-Server konnte Active Directory nicht öffnen. Dieser DNS-Server ist für das Abrufen und Verwenden von Informationen aus dem Verzeichnis für diese Zone konfiguriert und kann die Zone ohne die Informationen nicht laden. Stellen Sie sicher, dass das Active Directory ordnungsgemäß funktioniert, und laden Sie die Zone neu. Die Ereignisdaten enthalten den Fehlercode. Event ID 400
Und zwar in Massen....alle 3 Minuten...dazu gibt es einen MS-Artikel, den ich testen werde. Ist natürlich die Frage ob der wirklich für das Chaos verantwortlich ist.
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking ...
Noch eine weitere Frage...meines Wissens nach muss / sollte der DC / DNS doch immer als "primären DNS" die 127.0.0.1 eingetragen haben und nicht seine "Netzwerk-IP" oder ist das im Grunde komplett "egal"?
Aktuell ist primär seine IP 192.168.0.3 und als 2er DNS ... Google DNS ... naja ... aber ich hatte das nie angefasst.
ich habe folgendes Problem bei einem Kunden:
Kunde XY hat noch Server 2012R2, Kerio, AD, DNS, DHCP, Branchensoftware, Lexware, etc. läuft alles auf einem Blech, nichts virtualisiert. Ich hatte vor kurzem schon mal den neuen Hyper-V Host eingerichtet und "hingestellt". Darauf wurde auch eine notdürftige VM für SFIRM eingerichtet, damit die neue Version verwendet werden kann.
Das ActiveDirectory ist um es simpel auszudrücken "völlig kaputt". So weit ich das verfolgen kann, Doku gibt es nicht, ITler der das vorher verwaltet hat gibt es nicht mehr, nichts...war es früher ein SBS 2011, der wurde wohl auf einen Server 2012 Essentinals migriert, und danach auf Server 2012 R2 Standard. Mehr kann ich leider nicht sagen.
Backups gab es nicht mehr, es wurde zwar ein Band gewechselt, aber seit Jahren lief da kein Backup...naja, so ist das halt. Zumindest ein Backup gibt es nun...Angst gibt es da immer...vor allem da ich nicht gerade mit Kerio bewandert bin...und alles sehr gefrickelt dort ist (fängt bei der Verkabelung an, bis hin
Das Blech ist völlig veraltet, alter Xeon von 2008 meine ich, 16 GB DDR3, SAN mit 8 TB (das beste daran...), also insgesamt einfach nicht mehr aktuell. Das neue Blech ist da etwas potenter aufgestellt.
Dem Kunde habe ich mitgeteilt, dass da sehr wahrscheinlich die ganze Domäne neu hochgezogen werden muss, 2 Wochen zwischen den Jahren wird das benötigen, die Zeit davor nutze ich natürlich für Vorarbeiten...mit den Softwareanbietern abklären, etc. M365 soll auch eingeführt werden, aber das würde ich danach anpeilen, natürlich das AD schon entsprechend vorbereiten, passender UPN, etc. für den Sync.
An einem Wochenende würde ich das bestehende Blech virtualisieren schon mal, ich hatte das ohne NIC über Veeam in HyperV gestetet, das lief soweit...ich habe schon gelesen, dass das virtualisieren eines "Blech-DCs" Risiken birgt...Zwischenfrage...wie seht ihr das? Natürlich herunterfahren des Bleches vor Hochfahren der VM...
Dann wäre ich etwas flexibler und "sicherer", am liebsten würde ich natürlich die Domäne, User, etc. einfach migrieren wie üblich...
Jetzt zum eigentlichen Fehler auf dem DC:
Nach dem Anmelden öffnet sich schon mal das Essentinals-Dashobard obwohl es gar kein Essentinals mehr ist...für die Ersteinrichtung. Der eigentliche Server-Manager öffnet sich ganz normal, Essentinals ist dort auch als Rolle installiert und grau hinterlegt.
Wenn ich das AD Benutzerverzeichnis öffnen will erhalten ich die Meldung:
Active Directory-Domänendienste
Auf das Verzeichnisschema kann aufgrund folgenden Problems nicht zugegriffen werden:
Der übermittelte Verzeichnispfad ist ungültig.
Möglicherweise ist das Menü "Neu" fehlerhaft, und die Erweiterungs-Snap-Ins funktionieren möglicherweise nicht ordnungsgemäß.
Nach Klick auf OK:
Active Directory-Domänendienste
Aufgrund folgenden Problems können die Daten von "Active Directory-Benutzer und -Computer [meindc.domain.local]" derzeit nicht von Domänencontroller "meindc.domain.local" abgerufen werden:
"Der Benutzername oder das Kennwort ist falsch.
"Wiederholen Sie den Vorgang zu einem späteren Zeitpunkt, oder wählen Sie über das Domänenkontextmenü mit dem Befehl "Verbindung zum Domänencontroller herstellen" einen anderen Domänencontroller.
Dann öffnet sich MMC leer, keine Verbindung zum AD-Verzeichnis...
Einen anderen User gibt es nicht, er ist auf jeden Fall auch DER Administrator-Zugang...
Im Eventlog finde ich leider auch sehr viele Fehler von der Art:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Die Authentifizierung von Windows war für den Active Directory-Dienst auf einem Domänencontroller nicht möglich. (Fehler beim Aufruf der Funktion zur LDAP-Bindung). Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". ID 1006
...
An der Stelle weiß ich nun nicht weiter, ich habe mich damit abgefunden alles neu hochziehen zu müssen, es sind knapp 15 Arbeitsplätze, daher von der Menge verkraftbar...aber schöner wäre natürlich die Domäne zu migrieren.
Meine Gedanken hierzu:
Erst virtualisieren? Damit ein Snapshot schnell den alten Stand wiederherstellen kann...
Testweise das Essentinals Setup "durchklicken" endet leider auch in einem Fehler...aber bei der Standard-Version vermutlich logisch...
Oder...die Essentinals Rolle versuchen "runterzuprügeln"? Im Server Manager ist die grau hinterlegt...vllt. per PowerShell..?
In-Place auf 2016 / 2019 probieren?
Das Anmelden von Benutzern, Einbinden von neuen Clients, Rechte, etc. das läuft alles...aber nur was Bestand hat.
Via PowerShell kann ich dort auch nichts bewirken leider...
Ich weiß, da hilft auch eine Glaskugel nichts mehr, aber vllt. kennt jemand das Problem?
Das ist leider mein schlimmster Fall...vllt. habt ihr Ideen dazu oder schon mal etwas Ähnliches "durchgemacht"?
Wenn noch Infos benötigt werden lasst es mich wissen...wie gesagt, gehe ich da von dem Schlimmsten aus.
Vielen Dank schon mal.
Beste Grüße euch
Nachtrag von mir - tut mir leid für das Spammen:
Im DNS-Eventlog taucht folgender Fehler auf:
Der DNS-Server konnte Active Directory nicht öffnen. Dieser DNS-Server ist für das Abrufen und Verwenden von Informationen aus dem Verzeichnis für diese Zone konfiguriert und kann die Zone ohne die Informationen nicht laden. Stellen Sie sicher, dass das Active Directory ordnungsgemäß funktioniert, und laden Sie die Zone neu. Die Ereignisdaten enthalten den Fehlercode. Event ID 400
Und zwar in Massen....alle 3 Minuten...dazu gibt es einen MS-Artikel, den ich testen werde. Ist natürlich die Frage ob der wirklich für das Chaos verantwortlich ist.
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking ...
Noch eine weitere Frage...meines Wissens nach muss / sollte der DC / DNS doch immer als "primären DNS" die 127.0.0.1 eingetragen haben und nicht seine "Netzwerk-IP" oder ist das im Grunde komplett "egal"?
Aktuell ist primär seine IP 192.168.0.3 und als 2er DNS ... Google DNS ... naja ... aber ich hatte das nie angefasst.
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: 4099502415
Url: https://administrator.de/forum/dc-ad-totalschaden-4099502415.html
Ausgedruckt am: 22.12.2024 um 12:12 Uhr
14 Kommentare
Neuester Kommentar
Hi.
Mein Beileid.
Alter Schwede. So etwas ist geschäftsschädigend und grob fahrlässig, dass die GF niemals aktiv geworden ist.
Schonmal gut, dass es neue Hardware gibt.
Könnte funktionieren oder auch nicht. Am Ende ist der Kunde derjenige, der hier deine Zeit bezahlen muss.
Du könntest eine Migration in einer Labor Umgebung versuchen, wenn du den aktuellen DC via SysInternals Tools in eine virtuelle Maschine exportiert hast > Zeitaufwendig.
Bloß nicht. Das wird wahrscheinlich nur dazu führen, dass du ein problematisches AD auf einem neueren OS hast.
Gesetzt den Fall, dass es überhaupt irgendwie geht.
Ich würde hier einen Neuaufbau anstreben und empfehlen. Wie groß ist die Umgebung? Wie viele User, Geräte?
Wie schon angeführt, muss dem Kunden klar sein, dass das jede Menge kosten wird. Deine zwei Wochen sind eventuell etwas zu großzügig kalkuliert. Das sollte in einer Woche zu schaffen sein, es sei denn es gibt 25+ Clients und mehrere Remote Offices über Europa verteilt.
Bon Chance.
Den Google DNS solltest du dort auf jeden Fall austragen. In den DNS Weiterleitungen sollte ein externer, besser zwei, eingetragen sein.
Eine Rettung scheint hier fast gleichbedeutend mit einem vernüftigen Neuaufsetzen zu sein. Aufgrund der Essentials Komponente und den anscheinend InPlace Upgrades, wird das sehr, sehr anstrengend und langwierig wiederherzustellen sein.
Gruß
Marc
Zitat von @TurnschuhIT:
Kunde XY hat noch Server 2012R2, Kerio, AD, DNS, DHCP, Branchensoftware, Lexware, etc. läuft alles auf einem Blech, nichts virtualisiert. Ich hatte vor kurzem schon mal den neuen Hyper-V Host eingerichtet und "hingestellt". Darauf wurde auch eine notdürftige VM für SFIRM eingerichtet, damit die neue Version verwendet werden kann.
Das ActiveDirectory ist um es simpel auszudrücken "völlig kaputt". So weit ich das verfolgen kann, Doku gibt es nicht, ITler der das vorher verwaltet hat gibt es nicht mehr, nichts...war es früher ein SBS 2011, der wurde wohl auf einen Server 2012 Essentinals migriert, und danach auf Server 2012 R2 Standard. Mehr kann ich leider nicht sagen.
Kunde XY hat noch Server 2012R2, Kerio, AD, DNS, DHCP, Branchensoftware, Lexware, etc. läuft alles auf einem Blech, nichts virtualisiert. Ich hatte vor kurzem schon mal den neuen Hyper-V Host eingerichtet und "hingestellt". Darauf wurde auch eine notdürftige VM für SFIRM eingerichtet, damit die neue Version verwendet werden kann.
Das ActiveDirectory ist um es simpel auszudrücken "völlig kaputt". So weit ich das verfolgen kann, Doku gibt es nicht, ITler der das vorher verwaltet hat gibt es nicht mehr, nichts...war es früher ein SBS 2011, der wurde wohl auf einen Server 2012 Essentinals migriert, und danach auf Server 2012 R2 Standard. Mehr kann ich leider nicht sagen.
Mein Beileid.
Backups gab es nicht mehr, es wurde zwar ein Band gewechselt, aber seit Jahren lief da kein Backup...naja, so ist das halt. Zumindest ein Backup gibt es nun...Angst gibt es da immer...vor allem da ich nicht gerade mit Kerio bewandert bin...und alles sehr gefrickelt dort ist (fängt bei der Verkabelung an, bis hin
Alter Schwede. So etwas ist geschäftsschädigend und grob fahrlässig, dass die GF niemals aktiv geworden ist.
Das Blech ist völlig veraltet, alter Xeon von 2008 meine ich, 16 GB DDR3, SAN mit 8 TB (das beste daran...), also insgesamt einfach nicht mehr aktuell. Das neue Blech ist da etwas potenter aufgestellt.
Schonmal gut, dass es neue Hardware gibt.
Dem Kunde habe ich mitgeteilt, dass da sehr wahrscheinlich die ganze Domäne neu hochgezogen werden muss, 2 Wochen zwischen den Jahren wird das benötigen, die Zeit davor nutze ich natürlich für Vorarbeiten...mit den Softwareanbietern abklären, etc. M365 soll auch eingeführt werden, aber das würde ich danach anpeilen, natürlich das AD schon entsprechend vorbereiten, passender UPN, etc. für den Sync.
An einem Wochenende würde ich das bestehende Blech virtualisieren schon mal, ich hatte das ohne NIC über Veeam in HyperV gestetet, das lief soweit...ich habe schon gelesen, dass das virtualisieren eines "Blech-DCs" Risiken birgt...Zwischenfrage...wie seht ihr das? Natürlich herunterfahren des Bleches vor Hochfahren der VM...
Dann wäre ich etwas flexibler und "sicherer", am liebsten würde ich natürlich die Domäne, User, etc. einfach migrieren wie üblich...
An einem Wochenende würde ich das bestehende Blech virtualisieren schon mal, ich hatte das ohne NIC über Veeam in HyperV gestetet, das lief soweit...ich habe schon gelesen, dass das virtualisieren eines "Blech-DCs" Risiken birgt...Zwischenfrage...wie seht ihr das? Natürlich herunterfahren des Bleches vor Hochfahren der VM...
Dann wäre ich etwas flexibler und "sicherer", am liebsten würde ich natürlich die Domäne, User, etc. einfach migrieren wie üblich...
Könnte funktionieren oder auch nicht. Am Ende ist der Kunde derjenige, der hier deine Zeit bezahlen muss.
Du könntest eine Migration in einer Labor Umgebung versuchen, wenn du den aktuellen DC via SysInternals Tools in eine virtuelle Maschine exportiert hast > Zeitaufwendig.
Jetzt zum eigentlichen Fehler auf dem DC:
Nach dem Anmelden öffnet sich schon mal das Essentinals-Dashobard obwohl es gar kein Essentinals mehr ist...für die Ersteinrichtung. Der eigentliche Server-Manager öffnet sich ganz normal, Essentinals ist dort auch als Rolle installiert und grau hinterlegt.
Wenn ich das AD Benutzerverzeichnis öffnen will erhalten ich die Meldung:
Active Directory-Domänendienste
Auf das Verzeichnisschema kann aufgrund folgenden Problems nicht zugegriffen werden:
Der übermittelte Verzeichnispfad ist ungültig.
Möglicherweise ist das Menü "Neu" fehlerhaft, und die Erweiterungs-Snap-Ins funktionieren möglicherweise nicht ordnungsgemäß.
Nach Klick auf OK:
Active Directory-Domänendienste
Aufgrund folgenden Problems können die Daten von "Active Directory-Benutzer und -Computer [meindc.domain.local]" derzeit nicht von Domänencontroller "meindc.domain.local" abgerufen werden:
"Der Benutzername oder das Kennwort ist falsch.
"Wiederholen Sie den Vorgang zu einem späteren Zeitpunkt, oder wählen Sie über das Domänenkontextmenü mit dem Befehl "Verbindung zum Domänencontroller herstellen" einen anderen Domänencontroller.
Dann öffnet sich MMC leer, keine Verbindung zum AD-Verzeichnis...
Einen anderen User gibt es nicht, er ist auf jeden Fall auch DER Administrator-Zugang...
Im Eventlog finde ich leider auch sehr viele Fehler von der Art:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Die Authentifizierung von Windows war für den Active Directory-Dienst auf einem Domänencontroller nicht möglich. (Fehler beim Aufruf der Funktion zur LDAP-Bindung). Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". ID 1006
An der Stelle weiß ich nun nicht weiter, ich habe mich damit abgefunden alles neu hochziehen zu müssen, es sind knapp 15 Arbeitsplätze, daher von der Menge verkraftbar...aber schöner wäre natürlich die Domäne zu migrieren.
Meine Gedanken hierzu:
Erst virtualisieren? Damit ein Snapshot schnell den alten Stand wiederherstellen kann...
Testweise das Essentinals Setup "durchklicken" endet leider auch in einem Fehler...aber bei der Standard-Version vermutlich logisch...
Oder...die Essentinals Rolle versuchen "runterzuprügeln"? Im Server Manager ist die grau hinterlegt...vllt. per PowerShell..?
In-Place auf 2016 / 2019 probieren?
Nach dem Anmelden öffnet sich schon mal das Essentinals-Dashobard obwohl es gar kein Essentinals mehr ist...für die Ersteinrichtung. Der eigentliche Server-Manager öffnet sich ganz normal, Essentinals ist dort auch als Rolle installiert und grau hinterlegt.
Wenn ich das AD Benutzerverzeichnis öffnen will erhalten ich die Meldung:
Active Directory-Domänendienste
Auf das Verzeichnisschema kann aufgrund folgenden Problems nicht zugegriffen werden:
Der übermittelte Verzeichnispfad ist ungültig.
Möglicherweise ist das Menü "Neu" fehlerhaft, und die Erweiterungs-Snap-Ins funktionieren möglicherweise nicht ordnungsgemäß.
Nach Klick auf OK:
Active Directory-Domänendienste
Aufgrund folgenden Problems können die Daten von "Active Directory-Benutzer und -Computer [meindc.domain.local]" derzeit nicht von Domänencontroller "meindc.domain.local" abgerufen werden:
"Der Benutzername oder das Kennwort ist falsch.
"Wiederholen Sie den Vorgang zu einem späteren Zeitpunkt, oder wählen Sie über das Domänenkontextmenü mit dem Befehl "Verbindung zum Domänencontroller herstellen" einen anderen Domänencontroller.
Dann öffnet sich MMC leer, keine Verbindung zum AD-Verzeichnis...
Einen anderen User gibt es nicht, er ist auf jeden Fall auch DER Administrator-Zugang...
Im Eventlog finde ich leider auch sehr viele Fehler von der Art:
Fehler bei der Verarbeitung der Gruppenrichtlinie. Die Authentifizierung von Windows war für den Active Directory-Dienst auf einem Domänencontroller nicht möglich. (Fehler beim Aufruf der Funktion zur LDAP-Bindung). Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details". ID 1006
An der Stelle weiß ich nun nicht weiter, ich habe mich damit abgefunden alles neu hochziehen zu müssen, es sind knapp 15 Arbeitsplätze, daher von der Menge verkraftbar...aber schöner wäre natürlich die Domäne zu migrieren.
Meine Gedanken hierzu:
Erst virtualisieren? Damit ein Snapshot schnell den alten Stand wiederherstellen kann...
Testweise das Essentinals Setup "durchklicken" endet leider auch in einem Fehler...aber bei der Standard-Version vermutlich logisch...
Oder...die Essentinals Rolle versuchen "runterzuprügeln"? Im Server Manager ist die grau hinterlegt...vllt. per PowerShell..?
In-Place auf 2016 / 2019 probieren?
Bloß nicht. Das wird wahrscheinlich nur dazu führen, dass du ein problematisches AD auf einem neueren OS hast.
Gesetzt den Fall, dass es überhaupt irgendwie geht.
Das Anmelden von Benutzern, Einbinden von neuen Clients, Rechte, etc. das läuft alles...aber nur was Bestand hat.
Via PowerShell kann ich dort auch nichts bewirken leider...
Ich weiß, da hilft auch eine Glaskugel nichts mehr, aber vllt. kennt jemand das Problem?
Das ist leider mein schlimmster Fall...vllt. habt ihr Ideen dazu oder schon mal etwas Ähnliches "durchgemacht"?
Wenn noch Infos benötigt werden lasst es mich wissen...wie gesagt, gehe ich da von dem Schlimmsten aus.
Via PowerShell kann ich dort auch nichts bewirken leider...
Ich weiß, da hilft auch eine Glaskugel nichts mehr, aber vllt. kennt jemand das Problem?
Das ist leider mein schlimmster Fall...vllt. habt ihr Ideen dazu oder schon mal etwas Ähnliches "durchgemacht"?
Wenn noch Infos benötigt werden lasst es mich wissen...wie gesagt, gehe ich da von dem Schlimmsten aus.
Ich würde hier einen Neuaufbau anstreben und empfehlen. Wie groß ist die Umgebung? Wie viele User, Geräte?
Wie schon angeführt, muss dem Kunden klar sein, dass das jede Menge kosten wird. Deine zwei Wochen sind eventuell etwas zu großzügig kalkuliert. Das sollte in einer Woche zu schaffen sein, es sei denn es gibt 25+ Clients und mehrere Remote Offices über Europa verteilt.
Nachtrag von mir - tut mir leid für das Spammen:
Im DNS-Eventlog taucht folgender Fehler auf:
Der DNS-Server konnte Active Directory nicht öffnen. Dieser DNS-Server ist für das Abrufen und Verwenden von Informationen aus dem Verzeichnis für diese Zone konfiguriert und kann die Zone ohne die Informationen nicht laden. Stellen Sie sicher, dass das Active Directory ordnungsgemäß funktioniert, und laden Sie die Zone neu. Die Ereignisdaten enthalten den Fehlercode. Event ID 400
Und zwar in Massen....alle 3 Minuten...dazu gibt es einen MS-Artikel, den ich testen werde. Ist natürlich die Frage ob der wirklich für das Chaos verantwortlich ist.
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking ...
Im DNS-Eventlog taucht folgender Fehler auf:
Der DNS-Server konnte Active Directory nicht öffnen. Dieser DNS-Server ist für das Abrufen und Verwenden von Informationen aus dem Verzeichnis für diese Zone konfiguriert und kann die Zone ohne die Informationen nicht laden. Stellen Sie sicher, dass das Active Directory ordnungsgemäß funktioniert, und laden Sie die Zone neu. Die Ereignisdaten enthalten den Fehlercode. Event ID 400
Und zwar in Massen....alle 3 Minuten...dazu gibt es einen MS-Artikel, den ich testen werde. Ist natürlich die Frage ob der wirklich für das Chaos verantwortlich ist.
https://learn.microsoft.com/de-de/troubleshoot/windows-server/networking ...
Bon Chance.
Noch eine weitere Frage...meines Wissens nach muss / sollte der DC / DNS doch immer als "primären DNS" die 127.0.0.1 eingetragen haben und nicht seine "Netzwerk-IP" oder ist das im Grunde komplett "egal"?
Aktuell ist primär seine IP 192.168.0.3 und als 2er DNS ... Google DNS ... naja ... aber ich hatte das nie angefasst.
Aktuell ist primär seine IP 192.168.0.3 und als 2er DNS ... Google DNS ... naja ... aber ich hatte das nie angefasst.
Den Google DNS solltest du dort auf jeden Fall austragen. In den DNS Weiterleitungen sollte ein externer, besser zwei, eingetragen sein.
Eine Rettung scheint hier fast gleichbedeutend mit einem vernüftigen Neuaufsetzen zu sein. Aufgrund der Essentials Komponente und den anscheinend InPlace Upgrades, wird das sehr, sehr anstrengend und langwierig wiederherzustellen sein.
Gruß
Marc
Moin,
erstmal: Es hilft zwar jetzt nicht viel, aber wer war denn für das Backup zuständig? ich meine, nur weil man das Band wechselt, heißt es ja nicht, dass das Backup auch läuft. Nur wenn man eine Backup OK Meldung erhält, dann ist das Backup erfolgreich gewesen. Kein Fehler != erfolgreiches Backup. Wenn du es warst, lern was draus. Wenn du nicht dafür zuständig warst: Mein Beileid ;)
Mich irritiert, dass du schreibst "dein Kunde" und dann "Doku gibt es keine". Je nachdem wie lange es dein Kunde ist, musst du es doch dokumentieren. Grade für dich. Wenn es hingegen ein Neukunde ist, was ich so zwischen den Zeilen rauslesen, dann hart ausgedrückt:
Schmeiß die alte Umgebung weg und fang neu an. Wenn ich einen Kunden in diesem Zustand vorgefunden hätte, dann hätte ich es ihm erklärt. Wie willst du den Fehler finden, wenn du keine Doku hast. Du kannst diese Umgebung nie in den Griff bekommen, weil du nicht weißt, was der Vorgänger irgendwo gefrickelt hat. Mach den Kram neu. Neuer DC, neuer Fileserver, neuer Printserver, neuer Applikationsserver, neuer Mailserver und neuer Backup-Server. Fummel an der jetzigen Umgebung nicht weiter rum. Setz sie neu auf (nach Best Practice soweit es geht) und migriere die benötigten Daten rüber.
Ja, vielleicht dauert es länger als das jetzige Problem zu lösen. Aber was passiert, wenn du das Problem gelöst hast? Was explodiert dann? Unterm Strich wird die Reparatur bzw. das Gradeziehen der Umgebung dir mehr Zeit und Nerven kosten als ein Neustart. Und was dir Zeit und nerven kostet, kostet dem Kunden Geld.
Du sprichst von 15 Arbeitsplätzen in deinem Beitrag, da sollte das eher eine anstatt zwei Wochen dauern.
Gruß
Doskias
erstmal: Es hilft zwar jetzt nicht viel, aber wer war denn für das Backup zuständig? ich meine, nur weil man das Band wechselt, heißt es ja nicht, dass das Backup auch läuft. Nur wenn man eine Backup OK Meldung erhält, dann ist das Backup erfolgreich gewesen. Kein Fehler != erfolgreiches Backup. Wenn du es warst, lern was draus. Wenn du nicht dafür zuständig warst: Mein Beileid ;)
Mich irritiert, dass du schreibst "dein Kunde" und dann "Doku gibt es keine". Je nachdem wie lange es dein Kunde ist, musst du es doch dokumentieren. Grade für dich. Wenn es hingegen ein Neukunde ist, was ich so zwischen den Zeilen rauslesen, dann hart ausgedrückt:
Schmeiß die alte Umgebung weg und fang neu an. Wenn ich einen Kunden in diesem Zustand vorgefunden hätte, dann hätte ich es ihm erklärt. Wie willst du den Fehler finden, wenn du keine Doku hast. Du kannst diese Umgebung nie in den Griff bekommen, weil du nicht weißt, was der Vorgänger irgendwo gefrickelt hat. Mach den Kram neu. Neuer DC, neuer Fileserver, neuer Printserver, neuer Applikationsserver, neuer Mailserver und neuer Backup-Server. Fummel an der jetzigen Umgebung nicht weiter rum. Setz sie neu auf (nach Best Practice soweit es geht) und migriere die benötigten Daten rüber.
Ja, vielleicht dauert es länger als das jetzige Problem zu lösen. Aber was passiert, wenn du das Problem gelöst hast? Was explodiert dann? Unterm Strich wird die Reparatur bzw. das Gradeziehen der Umgebung dir mehr Zeit und Nerven kosten als ein Neustart. Und was dir Zeit und nerven kostet, kostet dem Kunden Geld.
Du sprichst von 15 Arbeitsplätzen in deinem Beitrag, da sollte das eher eine anstatt zwei Wochen dauern.
Gruß
Doskias
moin...
also 2 Wochen halte ich für ein gerücht, wenn du alle benötigten VMs am Start hast, alle updates drauf sind - denke ich, bist du in 3 Tagen durch!
wenn es denn sein soll, aus dem Bauch sage ich dir- stell mal den DNS grade und schau dir die AD einstellungen an!
sind immer die gleichen Fehler... zeit zum Fixen- keine 2 Stunden in der Regel!
eine Test VM mit 2019 erstellt, und einen zweiten DC installiert, und schon kannst du die FMSO Rollen verschieben, und dein AD steht erst mal sicher.
Frank
also 2 Wochen halte ich für ein gerücht, wenn du alle benötigten VMs am Start hast, alle updates drauf sind - denke ich, bist du in 3 Tagen durch!
wenn es denn sein soll, aus dem Bauch sage ich dir- stell mal den DNS grade und schau dir die AD einstellungen an!
sind immer die gleichen Fehler... zeit zum Fixen- keine 2 Stunden in der Regel!
eine Test VM mit 2019 erstellt, und einen zweiten DC installiert, und schon kannst du die FMSO Rollen verschieben, und dein AD steht erst mal sicher.
Frank
Moin,
das scheint eine einzige Domäne in einer Gesamtstruktur zu sein. Also wohl die Stammdomäne.
Du hast das Passwort des Standard-Administrators?
Und ich nehme an, Du hast das oben beschriebene alles direkt auf diesem Tausendsassa-DC versucht?
Wenn ja, würde ich als erstes einen Member Computer herrichten (Server OS oder Workstation ist egal, auch Version) und auf diesem RSAT installieren (komplett). Dann von diesem Computer aus die Domäne zu verwalten versuchen (unter der Anmeldung des Domänen Administartors).
Eine Domäne "neu machen" oder "sauber aufsetzen" ist meistens nicht nötig. Es sei denn, man kann sich da überhaupt nirgends mehr mit einem Domänen-Admin anmelden.
Wenn das nur ein DC ist, dann kann man das DNS i.A. recht schnell und einfach wiederherrichten.
Für den Fall der Fälle könntest Du auch als erstes versuchen, Dir mit der PowerShell ein zweites Admin-Konto zu erstellen.
E.
das scheint eine einzige Domäne in einer Gesamtstruktur zu sein. Also wohl die Stammdomäne.
Du hast das Passwort des Standard-Administrators?
Und ich nehme an, Du hast das oben beschriebene alles direkt auf diesem Tausendsassa-DC versucht?
Wenn ja, würde ich als erstes einen Member Computer herrichten (Server OS oder Workstation ist egal, auch Version) und auf diesem RSAT installieren (komplett). Dann von diesem Computer aus die Domäne zu verwalten versuchen (unter der Anmeldung des Domänen Administartors).
Eine Domäne "neu machen" oder "sauber aufsetzen" ist meistens nicht nötig. Es sei denn, man kann sich da überhaupt nirgends mehr mit einem Domänen-Admin anmelden.
Wenn das nur ein DC ist, dann kann man das DNS i.A. recht schnell und einfach wiederherrichten.
- DNS-Rolle auf einem Member installieren
- lokale, nicht AD-integrierte Zone mit Namen der AD-Domäne erstellen, z.B. "firma.tld", und für diese dynamische Updates erlauben
- am DC in den TCP/IP-Einstellungen den neuen DNS-Server als 1. Server eintragen.
- "ipconfig /registerdns" am DC ausführen
- NETLOGON-Dienst am DC neu starten
- Geduld - die Records sollten kurz danach auf dem neuen DNS-Server vorhanden sein
- wenn ja: Alle anderen Member Computer ebenfalls auf diesen neuen DNS-Server umstellen
- Am Member Computer mit den RSAT die Verwaltung testen
Für den Fall der Fälle könntest Du auch als erstes versuchen, Dir mit der PowerShell ein zweites Admin-Konto zu erstellen.
- Konto erstellen
- als Mitglied hinzufügen bei
- Administratoren
- Organisations-Admins
- Domänen-Admins
E.
Hallo ihr Lieben,
vielen Dank für eure Antworten.
Ja leider ist das ein ziemliches Gefriemel bei dem Kunden...eigentlich hätte man die Finger davon lassen sollen, aber ist halt jetzt so.
Aber schon mal vielen Dank für eure Meinungen und Tipps.
Sinnvoll wäre es sicherlich alles neu hochzuziehen, allerdings macht mir emeriks da ein wenig Hoffnung :-P
Der Administrator den ich verwende ist der "Standardadmin"
Ich habe mittlerweile mal die RSAT-Tools auf einem Server 2016 installiert, den ich natürlich in die Domäne integriert habe. Ich komme darüber auch auf das AD und kann dort arbeiten...daran hatte ich wirklich nicht gedacht in dem Fall...
Jetzt wäre doch das naheliegendste einen 2. DC erstmal einzurichten um das AD zu replizieren...war mein Gedanke.
Zuerst mit einem 2019er DC versucht...Problem ist, dass ich die Forest-Ebene nicht hochbekomme, Domänen-Ebene schon....
Über das Active Directory Verwaltungscenter klappt es nicht, auf dem Server2012R2 verbindet es sich nicht lokal, gleiche Ursache wie die AD-Tools vermutlich...aber auch nicht auf einem 2019er und 2016er die ich der Domäne hinzugefügt habe... "Unbekannter Fehler, Programm konnte nicht gestartet werden". Domänen-Ebene konnte ich über das AD-Tool vom Member heraufstufen...
Auch über Set-ADForestMode -Identity domain.local -ForestMode Windows2008R2Forest kein Erfolg, "Der Benutzername oder das Kennwort ist falsch" - egal ob vom einem Member oder direkt auf dem DC...angemeldet natürlich mit dem Domänen-Admin und auch mit einem 2. Administrator probiert.
Ich hatte das jetzt mit einem 2016er versucht, der wäre ja noch Abwärtskompatibel zu der verwendeten Forestebene...allerdings bekomme ich hier folgenden Fehler beim Heraufstufen im Assi:
Fehler bei der Überprüfung der Voraussetzungen für die Active Directory-Vorbereitung. Für die Domäne "domäne.loca" konnte keine Exchange-Schemakonfliktüberprüfung ausgeführt werden..
Ausnahme: Zugriff verweigert.
Daten des Servers "meindc1.domäne.local" konnten über die Windows-Verwaltungsinstrumentation (WMI) nicht abgerufen werden.
[Benutzeraktion]
Informationen zu möglichen Fehlerursachen finden Sie in der Protokolldatei "ADPrep.log" im Verzeichnis "C:\Windows\debug\adprep\logs\20220930084537-test".
Also immer das gleiche Symptom....
Ich habe zugegebener Weise jetzt auch noch nicht emeriks Lösungsansatz bzgl. DNS getestet...was ich am Wochenende machen werden, aber irgendwie...sagt mein Bauchgefühl mir, dass das vllt. nicht direkt damit zusammenhängt, aber ich kann mich auch irren, weil bald gibt es nicht mehr viel...was ich geprüft habe:
- Unter den laufenden Diensten konnte ich keine Probleme feststellen...außer dass ein paar Essentinals-Dienste laufen
- In den Eventslog "ServerEssentinals-Deployment" kann das Setup auch nicht durchgeführt werden wegen "Benutzername oder Kennwort"
- Logs von "Active Directory-Webdienste" sehr häufig:
Fehler von Active Directory-Webdiensten bei der Verbindung mit der Verzeichnisinstanz. Stellen Sie sicher, dass die Verzeichnisinstanz ausgeführt wird.
- Directory Service nur ein paar Warnungen bzgl. NTLM / veraltet...
- DNS Server Event - wie beschrieben der ID 4000er durchgehend...
- "System" sehr häufig der hier:
"Fehler bei der Verarbeitung der Gruppenrichtlinie. Die Authentifizierung von Windows war für den Active Directory-Dienst auf einem Domänencontroller nicht möglich. (Fehler beim Aufruf der Funktion zur LDAP-Bindung). Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details"." --> Gleiche Ursache nehme ich an...
- Port 389 + 636 ist auch offen soweit eingehend...
- DHCP events: Der DHCP-Dienst konnte keinen Verzeichnisserver für die Autorisierung finden.
- Auch lokal an dem alten DC mit einem anderen Neu erstellten User ist nicht möglich, da er nicht "mitbekommt" was in seinem eigenen AD läuft...hatte den User über die Member angelegt...als ich diesen in den RDP-Settings hinzufügen wollte...nothing...findet nichts...
Habt ihr noch eine Idee?
Wie gesagt, ich werde am Wochenende mal die DNS-Settings ordentlich machen nach euren Vorschlägen.
Sicherlich, am Ende ist es am Saubersten alles neu hochzuziehen...aber trotzdem finde ich das Problem sehr spannend.
Da es eine sehr kleine Umgebung mit 15 Clients ist...ein paar Freigaben...bissl Branchensoftware...ist das alles wirklich verkraftbar und bestimmt auch in einer Woche zu machen, da gebe ich euch Recht...aber da weiß man nie
Eine Frage noch nebenbei...wie verfahre ich bei einer neuen Domäne mit den Clients?
Neuen Domainnamen, Clients aus alter Domain raus und in neue rein? Wäre am sinnvollsten oder, sonst knallt es mit der "Vertrauenstellung" (wobei da sowieso sich nichts mehr vertraut... :-P) vllt. ?
Spaßhalber werde ich in einer Laborumgebung mal ein Inplace-Upgrade probieren...mal schauen was da so knallt...
Vielen lieben Dank für eure Geduld und Hilfe auf jeden Fall.
Grüße gehen raus
vielen Dank für eure Antworten.
Ja leider ist das ein ziemliches Gefriemel bei dem Kunden...eigentlich hätte man die Finger davon lassen sollen, aber ist halt jetzt so.
Aber schon mal vielen Dank für eure Meinungen und Tipps.
Sinnvoll wäre es sicherlich alles neu hochzuziehen, allerdings macht mir emeriks da ein wenig Hoffnung :-P
Der Administrator den ich verwende ist der "Standardadmin"
Ich habe mittlerweile mal die RSAT-Tools auf einem Server 2016 installiert, den ich natürlich in die Domäne integriert habe. Ich komme darüber auch auf das AD und kann dort arbeiten...daran hatte ich wirklich nicht gedacht in dem Fall...
Jetzt wäre doch das naheliegendste einen 2. DC erstmal einzurichten um das AD zu replizieren...war mein Gedanke.
Zuerst mit einem 2019er DC versucht...Problem ist, dass ich die Forest-Ebene nicht hochbekomme, Domänen-Ebene schon....
Über das Active Directory Verwaltungscenter klappt es nicht, auf dem Server2012R2 verbindet es sich nicht lokal, gleiche Ursache wie die AD-Tools vermutlich...aber auch nicht auf einem 2019er und 2016er die ich der Domäne hinzugefügt habe... "Unbekannter Fehler, Programm konnte nicht gestartet werden". Domänen-Ebene konnte ich über das AD-Tool vom Member heraufstufen...
Auch über Set-ADForestMode -Identity domain.local -ForestMode Windows2008R2Forest kein Erfolg, "Der Benutzername oder das Kennwort ist falsch" - egal ob vom einem Member oder direkt auf dem DC...angemeldet natürlich mit dem Domänen-Admin und auch mit einem 2. Administrator probiert.
Ich hatte das jetzt mit einem 2016er versucht, der wäre ja noch Abwärtskompatibel zu der verwendeten Forestebene...allerdings bekomme ich hier folgenden Fehler beim Heraufstufen im Assi:
Fehler bei der Überprüfung der Voraussetzungen für die Active Directory-Vorbereitung. Für die Domäne "domäne.loca" konnte keine Exchange-Schemakonfliktüberprüfung ausgeführt werden..
Ausnahme: Zugriff verweigert.
Daten des Servers "meindc1.domäne.local" konnten über die Windows-Verwaltungsinstrumentation (WMI) nicht abgerufen werden.
[Benutzeraktion]
Informationen zu möglichen Fehlerursachen finden Sie in der Protokolldatei "ADPrep.log" im Verzeichnis "C:\Windows\debug\adprep\logs\20220930084537-test".
Also immer das gleiche Symptom....
Ich habe zugegebener Weise jetzt auch noch nicht emeriks Lösungsansatz bzgl. DNS getestet...was ich am Wochenende machen werden, aber irgendwie...sagt mein Bauchgefühl mir, dass das vllt. nicht direkt damit zusammenhängt, aber ich kann mich auch irren, weil bald gibt es nicht mehr viel...was ich geprüft habe:
- Unter den laufenden Diensten konnte ich keine Probleme feststellen...außer dass ein paar Essentinals-Dienste laufen
- In den Eventslog "ServerEssentinals-Deployment" kann das Setup auch nicht durchgeführt werden wegen "Benutzername oder Kennwort"
- Logs von "Active Directory-Webdienste" sehr häufig:
Fehler von Active Directory-Webdiensten bei der Verbindung mit der Verzeichnisinstanz. Stellen Sie sicher, dass die Verzeichnisinstanz ausgeführt wird.
- Directory Service nur ein paar Warnungen bzgl. NTLM / veraltet...
- DNS Server Event - wie beschrieben der ID 4000er durchgehend...
- "System" sehr häufig der hier:
"Fehler bei der Verarbeitung der Gruppenrichtlinie. Die Authentifizierung von Windows war für den Active Directory-Dienst auf einem Domänencontroller nicht möglich. (Fehler beim Aufruf der Funktion zur LDAP-Bindung). Den Fehlercode und eine Beschreibung finden Sie auf der Registerkarte "Details"." --> Gleiche Ursache nehme ich an...
- Port 389 + 636 ist auch offen soweit eingehend...
- DHCP events: Der DHCP-Dienst konnte keinen Verzeichnisserver für die Autorisierung finden.
- Auch lokal an dem alten DC mit einem anderen Neu erstellten User ist nicht möglich, da er nicht "mitbekommt" was in seinem eigenen AD läuft...hatte den User über die Member angelegt...als ich diesen in den RDP-Settings hinzufügen wollte...nothing...findet nichts...
Habt ihr noch eine Idee?
Wie gesagt, ich werde am Wochenende mal die DNS-Settings ordentlich machen nach euren Vorschlägen.
Sicherlich, am Ende ist es am Saubersten alles neu hochzuziehen...aber trotzdem finde ich das Problem sehr spannend.
Da es eine sehr kleine Umgebung mit 15 Clients ist...ein paar Freigaben...bissl Branchensoftware...ist das alles wirklich verkraftbar und bestimmt auch in einer Woche zu machen, da gebe ich euch Recht...aber da weiß man nie
Eine Frage noch nebenbei...wie verfahre ich bei einer neuen Domäne mit den Clients?
Neuen Domainnamen, Clients aus alter Domain raus und in neue rein? Wäre am sinnvollsten oder, sonst knallt es mit der "Vertrauenstellung" (wobei da sowieso sich nichts mehr vertraut... :-P) vllt. ?
Spaßhalber werde ich in einer Laborumgebung mal ein Inplace-Upgrade probieren...mal schauen was da so knallt...
Vielen lieben Dank für eure Geduld und Hilfe auf jeden Fall.
Grüße gehen raus
2. DC ist gut!
Aber nimm bitte einen 2012R2. Keine "Experimente"! "Die Flucht nach vorn" ist zwar oft ein probates Mittel, aber in solch einem Fall sicher nicht. Erst einmal den Status Quo absichern!
Aber nimm bitte einen 2012R2. Keine "Experimente"! "Die Flucht nach vorn" ist zwar oft ein probates Mittel, aber in solch einem Fall sicher nicht. Erst einmal den Status Quo absichern!
Sicherlich, am Ende ist es am Saubersten alles neu hochzuziehen...
Wenn Ihr das bezahlt bekommt und Zeit, Arbeit und damit Geld schinden wollt: Nur zu, macht das mit der dem neuen Forest. Aber ob das dann anschließend alles "sauberer" ist als vorher, das werdet Ihr dann erst noch beweisen müssen.Wie gesagt, ich werde am Wochenende mal die DNS-Settings ordentlich machen nach euren Vorschlägen.
Es geht nicht darum, es "ordentlich" zu machen, sondern dass das AD damit funktioniert.Aber ..
Wenn Du mit den RSAT von einem anderen Computer aus das AD verwalten kannst, dann scheint mir das DNS doch die korrekten Records zu haben. Denn sonst würden die Tools vom anderen Computer das AD (sprich diesen einen DC) nicht finden und dort auch keine Änderungen vornehmen können.
Was sagt denn DCDIAG, wenn Du es direkt auf dem DC ausführst? Oder wenn das nicht geht, dann auf einem anderen Computer ausführen.
Zitat von @TurnschuhIT:
Eine Frage noch nebenbei...wie verfahre ich bei einer neuen Domäne mit den Clients?
Eine Frage noch nebenbei...wie verfahre ich bei einer neuen Domäne mit den Clients?
Würde den alten DC laufen lassen, die Clients und auch Server aus der aktuellen Domäne entfernen, alle Altlasten herunterfahren und dann die neue Domäne aufsetzen.
Auf jeden Fall vorher dafür sorgen, dass ein lokaler Admin auf allen Clients vorhanden ist. Sonst gibt das nur unnötig Schweißperlen auf der Stirn.
Gruß
Marc
Danke emeriks für die Antworten.
ISO wird gerade schon mal "rübergeladen"
DCDIAG gibt leider auch einen Fehler aus...zumindest lokal...vom Member (das war ein guter Hinweis wo ich nicht drangedacht hatte dummerweise...vielen Dank nochmal dafür) aus lief es.
Lokal:
Verzeichnisserverdiagnose
Anfangssetup wird ausgeführt:
Der Homeserver wird gesucht...
Homeserver = dc1
Auf dem Server dc1 ist bei der Attributsuche der LDAP-Suchfunktion ein
Fehler aufgetreten. Rückgabewert = 16
Member:
Alles positiv, bis auf:
Starting test: KccEvent
Das Ereignisprotokoll Directory Service auf dem Server dc1.domäne.local konnte nicht abgefragt
werden. Fehler: 0x6ba "Der RPC-Server ist nicht verfügbar."
Starting test: FrsEvent
Das Ereignisprotokoll File Replication Service auf dem Server dc1.domäne.local konnte nicht
abgefragt werden. Fehler: 0x6ba "Der RPC-Server ist nicht verfügbar."
......................... Der Test FrsEvent für dc1 ist fehlgeschlagen.
Starting test: SystemLog
Das Ereignisprotokoll System auf dem Server dc1.domäne.local konnte nicht abgefragt werden. Fehler:
0x6ba "Der RPC-Server ist nicht verfügbar."
......................... Der Test SystemLog für dc1 ist fehlgeschlagen.
Starting test: VerifyReferences
Der Sache kommt man zumindest näher...evtl. doch Richtung DNS....ich werde mal recherchieren was das sein könnte...
Grüße
ISO wird gerade schon mal "rübergeladen"
DCDIAG gibt leider auch einen Fehler aus...zumindest lokal...vom Member (das war ein guter Hinweis wo ich nicht drangedacht hatte dummerweise...vielen Dank nochmal dafür) aus lief es.
Lokal:
Verzeichnisserverdiagnose
Anfangssetup wird ausgeführt:
Der Homeserver wird gesucht...
Homeserver = dc1
Auf dem Server dc1 ist bei der Attributsuche der LDAP-Suchfunktion ein
Fehler aufgetreten. Rückgabewert = 16
Member:
Alles positiv, bis auf:
Starting test: KccEvent
Das Ereignisprotokoll Directory Service auf dem Server dc1.domäne.local konnte nicht abgefragt
werden. Fehler: 0x6ba "Der RPC-Server ist nicht verfügbar."
Starting test: FrsEvent
Das Ereignisprotokoll File Replication Service auf dem Server dc1.domäne.local konnte nicht
abgefragt werden. Fehler: 0x6ba "Der RPC-Server ist nicht verfügbar."
......................... Der Test FrsEvent für dc1 ist fehlgeschlagen.
Starting test: SystemLog
Das Ereignisprotokoll System auf dem Server dc1.domäne.local konnte nicht abgefragt werden. Fehler:
0x6ba "Der RPC-Server ist nicht verfügbar."
......................... Der Test SystemLog für dc1 ist fehlgeschlagen.
Starting test: VerifyReferences
Der Sache kommt man zumindest näher...evtl. doch Richtung DNS....ich werde mal recherchieren was das sein könnte...
Grüße
Moin...
@emeriks hat zu 100% recht- und wie ich die schon geschrieben habe, stell dein DNS richtig ein, und prüfe dein AD auf Fehler!
wenn ja.. AD breinigen!
und für den 2019er als DC bietet keine Unterstützung für FRS und kann nicht für das Replikat in die angegebene Domäne höher gestuft werden, eine DFSRMIGRATION ist da erforderlich!
Frank
@emeriks hat zu 100% recht- und wie ich die schon geschrieben habe, stell dein DNS richtig ein, und prüfe dein AD auf Fehler!
Fehler bei der Überprüfung der Voraussetzungen für die Active Directory-Vorbereitung. Für die Domäne "domäne.loca" konnte keine Exchange-Schemakonfliktüberprüfung ausgeführt werden..
hast du noch einen Exchange im Netz, oder sind das Reste vom SBS?wenn ja.. AD breinigen!
- DHCP events: Der DHCP-Dienst konnte keinen Verzeichnisserver für die Autorisierung finden.
na dann Autorisiere den DHCP, bzw. starte den NLA Dienst mal neu!Zuerst mit einem 2019er DC versucht...Problem ist, dass ich die Forest-Ebene nicht hochbekomme, Domänen-Ebene schon...
wie denn auch, du hast noch nen 2012er am laufen....und für den 2019er als DC bietet keine Unterstützung für FRS und kann nicht für das Replikat in die angegebene Domäne höher gestuft werden, eine DFSRMIGRATION ist da erforderlich!
Frank
bzgl. DCDIAG von remote:
Das wird höchstwahrscheinlich an der lokalen Firewall des DC liegen.
Das wird höchstwahrscheinlich an der lokalen Firewall des DC liegen.
Aaaalsooo...
DNS hatte ich versucht gerade zu biegen...
@Vision2015
Danke für deine Antwort, das war mal ein SBS2011, dann hat der Vorgänger wohl einen 2012R2 Essentinals drauß gemacht, zumindest was ich so an Backups finde....etc. Doku gibt es es keine...nothing...ich bin froh, dass der Kunde die Zugänge hatte...Exchange ist keiner vorhanden, es wird Kerio onprem noch eingesetzt. Ziel ist eigentlich M365...
Was ich jetzt berichten kann, ich hatte mittels Veeam den Server als VM restored (sind ja nur noch ein paar Klicks mittlerweile) auf dem neuen HyperV (der hat sowieso noch nichts zu tun und ist nur vorbereitend quasi im Einsatz mit einer kleinen VM da SFIRM notgedrungen upgedatet werden musste). Private NIC, damit der nicht in das Netz reinpfuscht...keine andere VM, kein Gateway über eine virtuelle Firewall, nothing...so zu sagen ein kleines Lab.
So...DNS-Server 127.0.0.1 eingetragen, gleiche IP-Settings...und läuft....alles läuft sauber...alle AD-Verwaltungen öffnen sich ohne murren...
Gleiches Spiel auf dem eigentlichen Host...immer noch gleiches Problem, natürlich auch mal einen Neustart getestet...
Nur wieso? Im Wesentlichen werden doch nur die Treiber ersetzt, soweit möglich...auch die Settings der NICs stimmen augenscheinlich überein...ich werde das nochmal testen ob das auch wirklich reproduzierbar ist.
Ich wollte ihn sowieso virtualisieren, auch wenn das mit DCs naja, irgendwie ein ungutes Gefühl hinterlässt und ich dann doch lieber einen frischen aufsetzen würde und die FSMO Rollen übertragen würde.
Aber ich denke in dem Fall wäre vor allem aus diesem Grund schon interessant. Der Hardware vertraue ich auch nicht wirklich über den Weg und ist auch mittlerweile der Flaschenhals zum Teil.
Ich habe das mit disk2vhd früher gemacht, das lief eigentlich immer ohne Probleme, vllt. nicht der beste Weg, aber naja...ich weiß auch nicht ob Veeam da vllt. noch etwas mehr macht an der Stelle als das bloß "Konvertieren".
Habt ihr bei dem virtualisieren von Blech-DCs vllt. noch ein paar Infos oder Tipps?
Vielen lieben Dank euch schon mal!
Beste Grüße und schönes Wochenende Euch schon mal.
DNS hatte ich versucht gerade zu biegen...
@Vision2015
Danke für deine Antwort, das war mal ein SBS2011, dann hat der Vorgänger wohl einen 2012R2 Essentinals drauß gemacht, zumindest was ich so an Backups finde....etc. Doku gibt es es keine...nothing...ich bin froh, dass der Kunde die Zugänge hatte...Exchange ist keiner vorhanden, es wird Kerio onprem noch eingesetzt. Ziel ist eigentlich M365...
Was ich jetzt berichten kann, ich hatte mittels Veeam den Server als VM restored (sind ja nur noch ein paar Klicks mittlerweile) auf dem neuen HyperV (der hat sowieso noch nichts zu tun und ist nur vorbereitend quasi im Einsatz mit einer kleinen VM da SFIRM notgedrungen upgedatet werden musste). Private NIC, damit der nicht in das Netz reinpfuscht...keine andere VM, kein Gateway über eine virtuelle Firewall, nothing...so zu sagen ein kleines Lab.
So...DNS-Server 127.0.0.1 eingetragen, gleiche IP-Settings...und läuft....alles läuft sauber...alle AD-Verwaltungen öffnen sich ohne murren...
Gleiches Spiel auf dem eigentlichen Host...immer noch gleiches Problem, natürlich auch mal einen Neustart getestet...
Nur wieso? Im Wesentlichen werden doch nur die Treiber ersetzt, soweit möglich...auch die Settings der NICs stimmen augenscheinlich überein...ich werde das nochmal testen ob das auch wirklich reproduzierbar ist.
Ich wollte ihn sowieso virtualisieren, auch wenn das mit DCs naja, irgendwie ein ungutes Gefühl hinterlässt und ich dann doch lieber einen frischen aufsetzen würde und die FSMO Rollen übertragen würde.
Aber ich denke in dem Fall wäre vor allem aus diesem Grund schon interessant. Der Hardware vertraue ich auch nicht wirklich über den Weg und ist auch mittlerweile der Flaschenhals zum Teil.
Ich habe das mit disk2vhd früher gemacht, das lief eigentlich immer ohne Probleme, vllt. nicht der beste Weg, aber naja...ich weiß auch nicht ob Veeam da vllt. noch etwas mehr macht an der Stelle als das bloß "Konvertieren".
Habt ihr bei dem virtualisieren von Blech-DCs vllt. noch ein paar Infos oder Tipps?
Vielen lieben Dank euch schon mal!
Beste Grüße und schönes Wochenende Euch schon mal.
Hallo liebe Community,
mittels Veeam habe ich das Blech jetzt virtualisiert, das waren ja sowieso nur ein paar Klicks...die Dienste und Anwendungen funktionieren ohne Probleme, das hatte ich mit einem MItarbeiter von dem Kunden am Wochenende getestet.
Die Replikation mit einem 2012 R2 hat auch reibungslos funktioniert. Replizierung läuft, Dienste lassen sich alle aufrufen, etc.
Ich habe jetzt von Sysvol auf DFSR migriert und noch einen 2019er eingebunden als DC, da die Reise dorthin gehen soll.
Das AD werde ich jetzt noch ein wenig aufräumen.
Nach der Virtualisierung waren keine Fehler mehr vom DNS logbar, es lief einfach alles...soweit es ordentlich laufen kann...ordentlich
Die Hardware hat meiner Meinung nach keine Probleme...Treiber soweit auf dem Stand.
Laut dem Log muss das mit den DNS-Fehlermeldungen schon seit 2016, als der Vorgänger wohl migriert hat so gewesen sein...
Den 2. 2012R2 werde ich vorsichtshalber zusätzlich zum 2019er noch als Replikat bestehen lassen für 2 Monate.
Vielen Dank für eure Hilfe und einen guten Start in die neue Woche.
Gruß Kevin Trapp
mittels Veeam habe ich das Blech jetzt virtualisiert, das waren ja sowieso nur ein paar Klicks...die Dienste und Anwendungen funktionieren ohne Probleme, das hatte ich mit einem MItarbeiter von dem Kunden am Wochenende getestet.
Die Replikation mit einem 2012 R2 hat auch reibungslos funktioniert. Replizierung läuft, Dienste lassen sich alle aufrufen, etc.
Ich habe jetzt von Sysvol auf DFSR migriert und noch einen 2019er eingebunden als DC, da die Reise dorthin gehen soll.
Das AD werde ich jetzt noch ein wenig aufräumen.
Nach der Virtualisierung waren keine Fehler mehr vom DNS logbar, es lief einfach alles...soweit es ordentlich laufen kann...ordentlich
Die Hardware hat meiner Meinung nach keine Probleme...Treiber soweit auf dem Stand.
Laut dem Log muss das mit den DNS-Fehlermeldungen schon seit 2016, als der Vorgänger wohl migriert hat so gewesen sein...
Den 2. 2012R2 werde ich vorsichtshalber zusätzlich zum 2019er noch als Replikat bestehen lassen für 2 Monate.
Vielen Dank für eure Hilfe und einen guten Start in die neue Woche.
Gruß Kevin Trapp
