12
Server 2003 R2 sekundärer DC Duplizierung anschieben
Hallo!
Ich wurde gestern zu einem neuen Kunden gerufen bei dem der Server einer Niederlassung streikte. Festplatte kaputt. Leider ist die letzte Datensicherung die zu finden war 1,5 Jahre alt. Scheinbar gibts keinen Admin im ganzen Unternehmen der sich kümmert. Der Server ist per VPN mit der Hauptniederlassung und dem primären DC verbunden.
Ich konnte die uralte Datensicherung wiederherstellen habe nun aber das Problem das sich die AD nicht repliziert. Das macht sie wohl nur bis max. 90 Tage altem Systemstatus.
Frage: Wie bekomme ich den Server (sekundäre DC) wieder dazu das er repliziert, bzw. wie hänge ich ihn auf dem primären DC ein das der Datenstand abgeglichen wird. Also was muß ich konkret auf dem 2003er SBS oder 2003 Server R2 machen damit der die AD Daten mit dem lokalen wiederhergestellten Server abgleicht?
Vielen Dank für Tips!
Ich wurde gestern zu einem neuen Kunden gerufen bei dem der Server einer Niederlassung streikte. Festplatte kaputt. Leider ist die letzte Datensicherung die zu finden war 1,5 Jahre alt. Scheinbar gibts keinen Admin im ganzen Unternehmen der sich kümmert. Der Server ist per VPN mit der Hauptniederlassung und dem primären DC verbunden.
Ich konnte die uralte Datensicherung wiederherstellen habe nun aber das Problem das sich die AD nicht repliziert. Das macht sie wohl nur bis max. 90 Tage altem Systemstatus.
Frage: Wie bekomme ich den Server (sekundäre DC) wieder dazu das er repliziert, bzw. wie hänge ich ihn auf dem primären DC ein das der Datenstand abgeglichen wird. Also was muß ich konkret auf dem 2003er SBS oder 2003 Server R2 machen damit der die AD Daten mit dem lokalen wiederhergestellten Server abgleicht?
Vielen Dank für Tips!
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: 169302
Url: https://administrator.de/forum/server-2003-r2-sekundaerer-dc-duplizierung-anschieben-169302.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
12 Kommentare
Neuester Kommentar
Hallo,
Gruß,
Peter
Zitat von @der-suchende:
Ich konnte die uralte Datensicherung wiederherstellen habe nun aber das Problem das sich die AD nicht repliziert. Das macht sie wohl nur bis max. 90 Tage altem Systemstatus.
Hast du den Server 2003 R2 am netzwerk gehabt als du diesen hochgefahren hast? war das VPN da verfügbar und hat dein Server 2003 R2 versucht sich am SBS 2003 zu verbinden? Welche genaue Fehlermeldung kommt? ist die Sicheung gemacht worden als dieser DC (Es gibt nur DC's, keine Primären oder Sekundären oder sonst etwas) schon im SBS Netz war und er auch schon DC am Standort war? Wurde ein USN Rollback gemacht? Gab es eine Meldung in Form von "Active Directory kann mit diesem Server nicht replizieren, da die die seit der letzten Replikation abgelaufene Zeit die Tombstone-Ablaufzeit überschritten hat."? Bitte mehr und genauere Infos. Sonst stochern wir alle nur im Nebel rum. Wäre, könnte, vielleicht...Ich konnte die uralte Datensicherung wiederherstellen habe nun aber das Problem das sich die AD nicht repliziert. Das macht sie wohl nur bis max. 90 Tage altem Systemstatus.
Gruß,
Peter
"Nonauthoritative Restore of a Domain Controller": http://technet.microsoft.com/en-us/library/cc784922%28WS.10%29.aspx
Hi der-suchende,
das ist auch gut so, sonst wär alles futsch....
Ja was sagt denn die Hauptniederlassung dazu?
Ich finde das sehr merkwürdig...
meine Lösung wäre:
1. dokumentieren wie der Server konfiguriert ist.
2. den Server in die Hauptzentrale bringen ( da das VPN bestimmt nur geringe Brandbreite hat ) und dann den Server aus der Domain nehmen mit dcpromo / ( hier den entsprechenden Schalter setzen ).
Dann den Server mit dcpromo wieder neu in die Domain aufnehmen ( dann nach den Vorgaben ob DNS und Globaler Katalog einstellen).
3. Server herunterfahren und dann in die Filiale bringen und schauen ob die VPN Verbindung funktioniert bzw die Replikation klappt.
Gruss
Holli
das ist auch gut so, sonst wär alles futsch....
Ja was sagt denn die Hauptniederlassung dazu?
Ich finde das sehr merkwürdig...
meine Lösung wäre:
1. dokumentieren wie der Server konfiguriert ist.
2. den Server in die Hauptzentrale bringen ( da das VPN bestimmt nur geringe Brandbreite hat ) und dann den Server aus der Domain nehmen mit dcpromo / ( hier den entsprechenden Schalter setzen ).
Dann den Server mit dcpromo wieder neu in die Domain aufnehmen ( dann nach den Vorgaben ob DNS und Globaler Katalog einstellen).
3. Server herunterfahren und dann in die Filiale bringen und schauen ob die VPN Verbindung funktioniert bzw die Replikation klappt.
Gruss
Holli
Mal vorangestellt: Ich mach im Normalfall nur SBS und keine Cluster. Die Arbeiten gestern waren ein Gefallen über 10 Ecken weil es sehr spät war und niemand anderes verfügbar war (denke ich). Es gibt sowohl in der Zentrale als auch in der Niederlassung keinen Admin. Es lief ja bisher... sagte man mir. Neue User eintragen macht ein Kollege aus der Verwaltung, sonst wird nix angefasst.
1. Ich hab den Server am Netz gehabt als ich ihn nach der Datenrücksicherung hochgefahren habe. VPN war verfügbar und die "alten" DNS-Einstellungen waren ja noch so gesetzt das sie auf den Server in der Zentrale zeigen.
2. Gesichert wurde Dezember 2009 im laufenden Betrieb mittels Acronis Enterprise.
3. USN-Rollback? Da bin ich überfragt. Was ist das?
4. Nach den Meldungen muß ich mal suchen. es gibt einige.
Den Server in die zentrale bringe ist nicht, sind 800km. Der VPN hat eine symmetrische 2000er DSL Leitung. Da sollte es eigentlich kein Problem geben.
Den Tip mit runterstufen und wie reinnehmen mit dcpromo wurde mir auch schon empfohlen. hab das nur noch nie gemacht. Gibts da Anleitungen?
1. Ich hab den Server am Netz gehabt als ich ihn nach der Datenrücksicherung hochgefahren habe. VPN war verfügbar und die "alten" DNS-Einstellungen waren ja noch so gesetzt das sie auf den Server in der Zentrale zeigen.
2. Gesichert wurde Dezember 2009 im laufenden Betrieb mittels Acronis Enterprise.
3. USN-Rollback? Da bin ich überfragt. Was ist das?
4. Nach den Meldungen muß ich mal suchen. es gibt einige.
Den Server in die zentrale bringe ist nicht, sind 800km. Der VPN hat eine symmetrische 2000er DSL Leitung. Da sollte es eigentlich kein Problem geben.
Den Tip mit runterstufen und wie reinnehmen mit dcpromo wurde mir auch schon empfohlen. hab das nur noch nie gemacht. Gibts da Anleitungen?
Hallo,
SBS und Cluster? Wie soll das gehen? Oben sagst du es gibt einen 2003 R2 und am Hauptstandort einen SBS 2003. Wo ist da der Cluster?
Grundsätzliche Frage:
War denn der Server 2003 R2 zum Zeitpunkt des Festplattenausfalls komplett repliziert und auf aktuellen stand im AD? Wenn ja, mach ihn neu und nehme in neu in der Domäne auf. Vorher den alten Server 2003 R2 aus dem AD entfernen. Falls vorher schon Probleme waren, hast du eh genug zu tun diese jetzt auch noch zu entfernen / beheben.
Und sage dem Auftraggeber das ein Hardware RAID mit Hotspare ihm jetzt viel Geld gesparrt hätte.
Gruß,
Peter
SBS und Cluster? Wie soll das gehen? Oben sagst du es gibt einen 2003 R2 und am Hauptstandort einen SBS 2003. Wo ist da der Cluster?
Es lief ja bisher... sagte man mir.
Geppüft hast du dieses aber nicht?1. Ich hab den Server am Netz gehabt als ich ihn nach der Datenrücksicherung,
Nein, du hast ein altes Image auf die Platte kopiert. das ist keine Datenrücksicherung im sinne einer Domänenwiederherstellung.hochgefahren habe. VPN war verfügbar und die "alten" DNS-Einstellungen waren ja noch so gesetzt das sie auf den Server in der Zentrale zeigen.
Also hat sich der Server 2003 R2 mit einem uralten AD stand versucht am Hauptstandort (SBS 2003) zu replizieren.2. Gesichert wurde Dezember 2009 im laufenden Betrieb mittels Acronis Enterprise.
Du meinst es wurde ein Image erstellt.3. USN-Rollback? Da bin ich überfragt. Was ist das?
Dann liess mal nach im Technet. Das gibt es auch bei einem SBS 2003, wo du ja angeblich zuhause bist.4. Nach den Meldungen muß ich mal suchen. es gibt einige.
Einige? Hast du oben aber so nicht dargestellt. Warum gehst du davon aus das wir alle deine Fehlermeldungen uns aufgeschrieben haben oder in deinem Ereignissprotokoll nachschauen können?Den Tip mit runterstufen und wie reinnehmen mit dcpromo wurde mir auch schon empfohlen. hab das nur noch nie gemacht.
Dann solltest du es an einem Übungsserver und AD versuchen. Sonst hast du mehr Probleme als nur die 800 km.Gibts da Anleitungen?
Du hast doch bestimmt schon mal vom MS Technet gehört? Da wirst du mehr als fündig.Grundsätzliche Frage:
War denn der Server 2003 R2 zum Zeitpunkt des Festplattenausfalls komplett repliziert und auf aktuellen stand im AD? Wenn ja, mach ihn neu und nehme in neu in der Domäne auf. Vorher den alten Server 2003 R2 aus dem AD entfernen. Falls vorher schon Probleme waren, hast du eh genug zu tun diese jetzt auch noch zu entfernen / beheben.
Und sage dem Auftraggeber das ein Hardware RAID mit Hotspare ihm jetzt viel Geld gesparrt hätte.
Gruß,
Peter
Moin
[OT]
Vor ein paar Jahren kam ich mal zu einer Firma, wo ein NT-Server stand. Die Softwarespielgelung hatte man in Anbetracht des zu knappen Speicherplatzes aufgelöst und nun war die System platte (zum Glück nur die...) hin. Das Band, welches aus dem Bandlaufwerk hervorschaute hatte oben schon Patina angesetzt.
Aufmeinen Hinweis, wer sich denn im Haus um die Datensicherung kümmert, wurde mir vom Chef mitgeteilt, dass das ja wohl unser Problem wäre. Wir hätten schließlich damals den Server geliefert...
[/OT]
Was macht denn dieser DC am Standort ? Das wäre doch mal die erste Frage...
Den Server per dcpromo aus der Domäne entfernen - wie soll das gehen ? Da die Server sich nicht mehr miteinander unterhalten wollen, wird das so sicher nicht gehen.
Im einfachsten Fall (der Server bietet nur Authentifizierung als DC und vielleicht noch ein paar Druckdienste etc.), solltest du einfach einen neuen DC aufsetzen und in die Domäne bringen. Den alten wirst du so oder so per ntdsutil aus der Domäne entfernen müssen.
Grundsätzlich niemals ein so altes Backup wieder einpielen !! Fange nicht an zu basteln, um das Problem irgendwie "quick'n'dirty" aus der Welt zu bekommen. Du hast hinterher garantiert mehr Probleme, als dir lieb sein dürften.
Bei einer normalen Sicherung, wäre es auch bei dem Restore des Systemstate zu einer Fehlermeldung gekommen. (Ich würde mein AD auch niemals, niemals, niemals per Imaging sichern...)
Die einzig korrekte Aussage gegenüber dem Kunden ist, dass dieser DC aus diesem Backup nicht wiederhergestellt werden kann.
Gruß
Hubert
[OT]
Vor ein paar Jahren kam ich mal zu einer Firma, wo ein NT-Server stand. Die Softwarespielgelung hatte man in Anbetracht des zu knappen Speicherplatzes aufgelöst und nun war die System platte (zum Glück nur die...) hin. Das Band, welches aus dem Bandlaufwerk hervorschaute hatte oben schon Patina angesetzt.
Aufmeinen Hinweis, wer sich denn im Haus um die Datensicherung kümmert, wurde mir vom Chef mitgeteilt, dass das ja wohl unser Problem wäre. Wir hätten schließlich damals den Server geliefert...
[/OT]
Was macht denn dieser DC am Standort ? Das wäre doch mal die erste Frage...
Den Server per dcpromo aus der Domäne entfernen - wie soll das gehen ? Da die Server sich nicht mehr miteinander unterhalten wollen, wird das so sicher nicht gehen.
Im einfachsten Fall (der Server bietet nur Authentifizierung als DC und vielleicht noch ein paar Druckdienste etc.), solltest du einfach einen neuen DC aufsetzen und in die Domäne bringen. Den alten wirst du so oder so per ntdsutil aus der Domäne entfernen müssen.
Grundsätzlich niemals ein so altes Backup wieder einpielen !! Fange nicht an zu basteln, um das Problem irgendwie "quick'n'dirty" aus der Welt zu bekommen. Du hast hinterher garantiert mehr Probleme, als dir lieb sein dürften.
Bei einer normalen Sicherung, wäre es auch bei dem Restore des Systemstate zu einer Fehlermeldung gekommen. (Ich würde mein AD auch niemals, niemals, niemals per Imaging sichern...)
Die einzig korrekte Aussage gegenüber dem Kunden ist, dass dieser DC aus diesem Backup nicht wiederhergestellt werden kann.
Gruß
Hubert
Hm, das wird der Kunde ungern hören. Und mir meinen bisherigen Aufwand auf diese Aussage hin wohl nicht erstatten wollen (... ist ja nicht erfolgreich fertig geworden). Das wäre schlecht.
Was der Server dort macht weiß ich auch nicht so recht. Er soll wohl die Nutzerverwaltung vorhalten falls die VPN in die Zentrale mal klemmt. Daten oder weitergehende Dinge passieren dort nicht. Ich hab nur das gesamte Konstrukt noch nicht so recht durchschaut.
Gibts keine Alternative?
Was der Server dort macht weiß ich auch nicht so recht. Er soll wohl die Nutzerverwaltung vorhalten falls die VPN in die Zentrale mal klemmt. Daten oder weitergehende Dinge passieren dort nicht. Ich hab nur das gesamte Konstrukt noch nicht so recht durchschaut.
Gibts keine Alternative?
Ich würde mal sagen, du kannst das ganze unter Erfahrung verbuchen...
Vielleicht aber noch mal ein wenig Lesestoff zumThema Tombstone: (Aus LDAP:Yusufs.Directory.Blog/ - Die Tombstone Lifetime):
Eine System State-Sicherung die älter als die TSL ist, darf nicht mehr verwendet werden. Die TSL gibt das maximale Alter einer Systemstatus-Sicherung an.
Wird ein DC während der TSL mit einer Systemstatus-Sicherung die das Benutzerobjekt Yusuf enthält wiederhergestellt, nachdem das Objekt Yusuf gelöscht wurde, so würde der gelöschte Status von dem Objekt Yusuf auf den wiederhergestellten DC repliziert werden. Das Benutzerobjekt Yusuf wäre weiterhin nicht vorhanden, da die Wiederherstellung während der TSL durchgeführt wurde. Falls der DC nach der TSL wiederhergestellt werden würde, wäre das Benutzerobjekt Yusuf jedoch vorhanden. Denn auf den anderen DCs wäre das Objekt bereits aus der AD-Datenbank vom Garbage Collection Prozess entfernt worden. Das Benutzerkonto würde aber nur auf dem wiederhergestellten DC existieren. Dieser Zustand führt zu Inkonsistenzen in der AD-Datenbank und das Benutzerobjekt Yusuf wäre ein Lingering Object (herumlungerndes Objekt).//
Im Grunde genommen kannst du froh sein, dass die Replikation nicht mehr funktioniert hat. Sonst hättest du dir wohl das ganze AD zerschossen !!!
Vielleicht aber noch mal ein wenig Lesestoff zumThema Tombstone: (Aus LDAP:Yusufs.Directory.Blog/ - Die Tombstone Lifetime):
Eine System State-Sicherung die älter als die TSL ist, darf nicht mehr verwendet werden. Die TSL gibt das maximale Alter einer Systemstatus-Sicherung an.
Wird ein DC während der TSL mit einer Systemstatus-Sicherung die das Benutzerobjekt Yusuf enthält wiederhergestellt, nachdem das Objekt Yusuf gelöscht wurde, so würde der gelöschte Status von dem Objekt Yusuf auf den wiederhergestellten DC repliziert werden. Das Benutzerobjekt Yusuf wäre weiterhin nicht vorhanden, da die Wiederherstellung während der TSL durchgeführt wurde. Falls der DC nach der TSL wiederhergestellt werden würde, wäre das Benutzerobjekt Yusuf jedoch vorhanden. Denn auf den anderen DCs wäre das Objekt bereits aus der AD-Datenbank vom Garbage Collection Prozess entfernt worden. Das Benutzerkonto würde aber nur auf dem wiederhergestellten DC existieren. Dieser Zustand führt zu Inkonsistenzen in der AD-Datenbank und das Benutzerobjekt Yusuf wäre ein Lingering Object (herumlungerndes Objekt).//
Im Grunde genommen kannst du froh sein, dass die Replikation nicht mehr funktioniert hat. Sonst hättest du dir wohl das ganze AD zerschossen !!!
Hallo,
Welcher Kunde will das überhaupt hören. Das ist nicht das Problem.
Wir haben keinen zugriff auf das VPN deines Kunden und sein Netz. Du schon. Wir können hier nur raten was du meinst und was du vielleicht wann gemacht hast, oder eben nicht gemacht hast.
Du weisst ja noch nicht mal wie das Netz dort funktioniert, kannst uns also gar nichts darüber sagen und willst von uns Alternativen?
Sage deinem Auftraggeber er möchte doch jemand holen der sich damit auskennt. Das ist eine Alternative.
Solltest du dich mit Werkzeugen wie NTDSUtil, ADSIEdit, DCPromo usw auskennen, dann mach den Server 2003 R2 neu. das ist auch eine Alternative.
Kennst du dich mit Festplatten und Datenrettung aus, stelle die alte Platte wieder her, Kopiere die Daten auf einer neuen Platte, baue die ein und fahre den Server 2003R2 wieder hoch. Das ist auch eine* Alternative.
Oder brauchst du Argumente und Argumentationstechniken um deinen** Auftraggeber zu überzeugen?
Was möchtest du also hören?
Gruß,
Peter
Welcher Kunde will das überhaupt hören. Das ist nicht das Problem.
Und mir meinen bisherigen Aufwand auf diese Aussage hin wohl nicht erstatten wollen (...ist ja nicht erfolgreich fertig geworden). Das wäre schlecht.
Nun, wenn du mit Ihm vereinbart hast das er nur im Erfolgsfall bezahlen muss....Was der Server dort macht weiß ich auch nicht so recht.
Wenn nicht du, wer dann?Er soll wohl die Nutzerverwaltung vorhalten falls die VPN in die Zentrale mal klemmt.
Und was macht er denn dann wenn das VPN funktioniert? Nichts, oder was?Daten oder weitergehende Dinge passieren dort nicht.
DNS mit sicherheit schon mal. AD auch. WINS vermutlich mit sicherheit auch noch. Anmeldeserver bestimmt auch. ...Ich hab nur das gesamte Konstrukt noch nicht so recht durchschaut.
?!?. Einen SBS 2003 am Hauptstandort und einen Server 2003 R2 am 2.ten Standort (wo du bist). Verbunden per Standort - Standort VPN und beide in einer Domäne. Was ist daran nicht zu verstehen für jemanden der sich zutraut mal eben einen Defekten Server 2003 R2 DC mit Uralt Image wieder hinzubekommen. Da müssen wir dioch dann alle von gewissen Gundlagen und Fachwissen deinerseits ausgehen.Wir haben keinen zugriff auf das VPN deines Kunden und sein Netz. Du schon. Wir können hier nur raten was du meinst und was du vielleicht wann gemacht hast, oder eben nicht gemacht hast.
Gibts keine Alternative?
Welche willst du haben?Du weisst ja noch nicht mal wie das Netz dort funktioniert, kannst uns also gar nichts darüber sagen und willst von uns Alternativen?
Sage deinem Auftraggeber er möchte doch jemand holen der sich damit auskennt. Das ist eine Alternative.
Solltest du dich mit Werkzeugen wie NTDSUtil, ADSIEdit, DCPromo usw auskennen, dann mach den Server 2003 R2 neu. das ist auch eine Alternative.
Kennst du dich mit Festplatten und Datenrettung aus, stelle die alte Platte wieder her, Kopiere die Daten auf einer neuen Platte, baue die ein und fahre den Server 2003R2 wieder hoch. Das ist auch eine* Alternative.
Oder brauchst du Argumente und Argumentationstechniken um deinen** Auftraggeber zu überzeugen?
Was möchtest du also hören?
Gruß,
Peter
Zitat von @Pjordorf:
Hallo,
> Zitat von @der-suchende:
> Hm, das wird der Kunde ungern hören.
Welcher Kunde will das überhaupt hören. Das ist nicht das Problem.
> Und mir meinen bisherigen Aufwand auf diese Aussage hin wohl nicht erstatten wollen (...ist ja nicht erfolgreich fertig
geworden). Das wäre schlecht.
Nun, wenn du mit Ihm vereinbart hast das er nur im Erfolgsfall bezahlen muss....
Nein, das nicht, aber ihr wisst doch wie manche Kunden sind.Hallo,
> Zitat von @der-suchende:
> Hm, das wird der Kunde ungern hören.
Welcher Kunde will das überhaupt hören. Das ist nicht das Problem.
> Und mir meinen bisherigen Aufwand auf diese Aussage hin wohl nicht erstatten wollen (...ist ja nicht erfolgreich fertig
geworden). Das wäre schlecht.
Nun, wenn du mit Ihm vereinbart hast das er nur im Erfolgsfall bezahlen muss....
> Was der Server dort macht weiß ich auch nicht so recht.
Wenn nicht du, wer dann?
> Er soll wohl die Nutzerverwaltung vorhalten falls die VPN in die Zentrale mal klemmt.
Und was macht er denn dann wenn das VPN funktioniert? Nichts, oder was?
> Daten oder weitergehende Dinge passieren dort nicht.
DNS mit sicherheit schon mal. AD auch. WINS vermutlich mit sicherheit auch noch. Anmeldeserver bestimmt auch. ...
> Ich hab nur das gesamte Konstrukt noch nicht so recht durchschaut.
?!?. Einen SBS 2003 am Hauptstandort und einen Server 2003 R2 am 2.ten Standort (wo du bist). Verbunden per Standort - Standort
VPN und beide in einer Domäne. Was ist daran nicht zu verstehen für jemanden der sich zutraut mal eben einen Defekten
Server 2003 R2 DC mit Uralt Image wieder hinzubekommen. Da müssen wir dioch dann alle von gewissen Gundlagen und Fachwissen
deinerseits ausgehen.
Wir haben keinen zugriff auf das VPN deines Kunden und sein Netz. Du schon. Wir können hier nur raten was du meinst und
was du vielleicht wann gemacht hast, oder eben nicht gemacht hast.
Na klar, aber wie ich schon schrieb ist alles etwas eigenartig.was du vielleicht wann gemacht hast, oder eben nicht gemacht hast.
> Gibts keine Alternative?
Welche willst du haben?
Du weisst ja noch nicht mal wie das Netz dort funktioniert, kannst uns also gar nichts darüber sagen und willst von uns
Alternativen?
Sage deinem Auftraggeber er möchte doch jemand holen der sich damit auskennt. Das ist eine Alternative.
Solltest du dich mit Werkzeugen wie NTDSUtil, ADSIEdit, DCPromo usw auskennen, dann mach den Server 2003 R2 neu. das ist auch
eine Alternative.
Kennst du dich mit Festplatten und Datenrettung aus, stelle die alte Platte wieder her, Kopiere die Daten auf einer neuen Platte,
baue die ein und fahre den Server 2003R2 wieder hoch. Das ist auch eine* Alternative.
Oder brauchst du Argumente und Argumentationstechniken um deinen** Auftraggeber zu überzeugen?
Manchmal gibts ja ein Wunder und einer sagt: ja, hatte ich letzte Woche erst, ich hab 1. ..., 2. ..., 3. ... gemacht.
Was möchtest du also hören?
Ich danke euch allen für die Informationen und werde wohl den Weg der Neuinstallation gehen. Mal sehen ob das hinhaut. Wenn nur noch jemand da wäre der das damals eingerichtet hat. Aber nix, und keine Dokumentation in sicht
die ultimative einfache Lösung wäre es gewesen, den Server gleich neu aufzusetzen...
Wenn du das nun machst, dann denke aber bitte daran, dass du (oder wer auch immer dann) in der Haupststelle noch ein paar Dinge zu erledigen hast:
- entferne den alten DC aus dem AD. vgl dazu z.B. http://www.petri.co.il/delete_failed_dcs_from_ad.htm
- schiebe den neuen DC in den AD-Standort der Zweigstelle (so denn hoffentlich jemand Standorte konfiguriert hatte...)
Wenn du das nun machst, dann denke aber bitte daran, dass du (oder wer auch immer dann) in der Haupststelle noch ein paar Dinge zu erledigen hast:
- entferne den alten DC aus dem AD. vgl dazu z.B. http://www.petri.co.il/delete_failed_dcs_from_ad.htm
- schiebe den neuen DC in den AD-Standort der Zweigstelle (so denn hoffentlich jemand Standorte konfiguriert hatte...)
Hallo,
@der-suchende
Und wichtig, vorher noch genau klären was die anderen 4 Server genau für eine Aufgabe haben. Und sage dem Benutzer der das (Domänen)Admin Passwort hat, er darf die Stadt nicht verlassen
Gruß,
Peter
Zitat von @Hubert.N:
die ultimative einfache Lösung wäre es gewesen, den Server gleich neu aufzusetzen...
Einzig richtiger weg.die ultimative einfache Lösung wäre es gewesen, den Server gleich neu aufzusetzen...
@der-suchende
Und wichtig, vorher noch genau klären was die anderen 4 Server genau für eine Aufgabe haben. Und sage dem Benutzer der das (Domänen)Admin Passwort hat, er darf die Stadt nicht verlassen
Gruß,
Peter
