Nach Crash DC Rollback, jetzt Exchange Probleme

[heuchler 17]

Guten Abend zusammen,

 

da ist heute der GAU passiert.

Kurze Vorgeschichte:

 

Neue Hardware, neue XenServer Version (von 6.2 auf 6.5).

 

srv-dc = 2008 - Infrastrukturmaster, RID, und PDC
srv-dc01 = 2003R2 - Schemamaster und Domänennamenmaster  <- Problemkind
srv-exchange 2010 SP3 = Problemkind

 

 

Domänenfunktions- und Strukturebene ist 2003.
Es läuft noch EIN Terminalserver 2003 im unternehmen.

 

Die Migration der Maschinen lief perfekt, allerdings hatte ich schon vorher arge Bedenken bei den Tools.

Und dann... mit dem Update der Tools fingen die Probleme an.

Zunächst starteten die Exchange Dienste auf dem Exchange nicht.
Die wurde jetzt vorerst durch manuelles Deinstallieren der Tools behoben (also jetzt keine XenTools installiert, Server jedoch erreichbar).

Outlook verbindet sich jedoch nicht. Ich befürchte wegen des DCs (siehe unten)

 

Das nächste Problem, was allerdings erst viel später bemerkt wurde weil der dc an sich ja "lief":

Der 2. DC hatte einen weg. Nach dem Neustart gab es Bluescreens, auch im abgesicherten Modus.

Einzige Lösung: Rollback auf den Stand von gestern Abend 20:00 Uhr. So dachte man (denn sie wussten nicht was passiert....)

Ja, jetzt nach wilder Recherche weiß ich dass das genau der Fehler war. Allerdings wurde der System State nicht weggesichert, immer nur via Image/Snapshots.

 

Repadmin showrepl sagt jetzt natürlich auch, dass ZIel- bzw. Quellserver keine Replikation entgegen nimmt.

Auf dem DC01 (der Problem DC) wird darauf hingewiesen, dass man die Replikation per Hand über repadmin /options srv-dc01 -disable_outbound_repl

und repadmin /options srv-dc01 -disable_inbound_repl wieder starten soll.

Jetzt ist die Frage: was tun?

Soll ich das wirklich ausführen?

Er hat ja nicht ohne Grund die Replikation deaktiviert - klar, aufgrund des einspielen des Backups vermutlich.

Hat jemand eine Idee?

 

Im Endeffekt reicht uns ein DC vorerst aus.
Wenn der Exchange wieder funktioniert sozusagen alles okay.
Der defekte DC ist eh ein 2003... .

Der betreffende DC ist auch zum Glück kein DHCP.

---

Meine Idee:

Kann man dem 2008er Server alle Rollen übertragen trotz des inkosistenten Zustandes des Problem-DC?
Und wäre es dann möglich den Problem DC herabzustufen so dass sich das AD wieder beruhigt?

Besten Dank und verzweifelte Grüße

 

Daniel

bearbeitet 6. Juni 2015 von heuchler

[Daniel -MSFT- 129]

Rollback ist kein Backup. Das ist genau das, was man weder mit einem Domaincontroller, noch mit einem Exchange Server macht. Nie. Nicht.

 

Such mal nach USN Rollback. Dann findest Du zum Beispiel https://support.microsoft.com/en-us/kb/875495/en-us und http://www.hyper-v-server.de/hypervisor/hyper-v-ads-controller-und-angewendete-snapshots/

 

Have fun!

Daniel

[heuchler 17]

Hi Daniel,

 

Danke Dir! Die MS Seite hatte ich schon auf Deutsch.

 

Was ich mich jetzt Frage: ich hoffe dass Outlook deswegen nicht öffnet und "nichts findet" weil der DC "schuld" ist und nicht, weil der Exchange jetzt auch eine Macke hat.

 

Nun, das Kind ist in den Brunnen gefallen. Was soll ich jetzt dazu sagen?
Man hat DIenstleister an der Hand die vielleicht auch nicht immer dran denken dass sowas in dieser Form eintritt.
Selbst wenn der Fehler sofort aufgefallen wäre - Rollback bleibt Rollback.
Im Endeffekt wurden die VMs täglich weggesichert und ich habe bis gestern nicht daran gedacht, dass man sich sowas wegen eines Updates zerschießt.

Nun denn.

Mir ist der Weg noch nicht so ganz klar, vielleicht kann mir hier jemand helfen?

Zunächst
1. dcpromo Herabstufung erzwingen?
2. Metadaten aufräumen

3. die FSMO Rollen von defekten DC auf laufenden DC übertragen? <-- oder kann ich das jetzt schon über SEIZE FSMO Roles machen so dass der Exchange vielleicht wieder läuft?

4. wenn DC herabgestuft und FSMO auf einem Server, dann reicht ja rein theoretisch ein DC (der ist auch physikalisch und hier wurde zum GLÜCK nichts geändert).
Ggf. würde ich einen 2008er neu aufsetzen und ihn dann als DC hochstufen?

Ist das so richtig?

 

Noch zögere ich. An sich ist das ja schnell gemacht. Ich warte nur auf das "Go" eines Profis der mir sagt (nicht unbedingt garantiert... aber Erfahrung und so..) dass ich das eh machen muss weil ich keine andere Chance habe.

Und danach flattern die Mails wieder rein und bis auf ein paar Nerven die ich weniger und graue Haare die ich mehr habe war es das?
Das Backupkonzept wird dann auch angepasst...

 

Edit: ich sehe mir gerade den Hyper-V Link an. Ja. Er hat ja "nur" netlogon ans Laufen gebracht und eben die Replikation erzwungen.
Hier lese ich, dass das garnicht so sauber ist.
Und ich frage mich: zieht sich der inkonsistente DC die Daten vom laufenden DC?
Oder ist das eher Glückssache wer die aktuelleren/veralteten Daten erhält?
Schlussendlich sieht es nämlich deutlich simpler aus als das dcpromo-Zeug..

Geil. Wenn man einfach mal froh ist dass man "Zeit" hat ne Umstellung zu machen und DANN was schief läuft, ruft der Chef an und fragt was los ist weil keine E-Mails mehr reinkommen.
:cry: 
 

bearbeitet 5. Juni 2015 von heuchler

[zahni 521]

Hast Du etwa aktive Snapshots auf den VMs? 

Die hat man in produktiven Umgebungen nicht. Niemals. Die nutzt man nur kurzzeitig, wen man weis, dass man es machen kann, oder zum Backup

Ausgenommen sind spezielle Lösungen wie VMWare View. Die Lösung weis dann aber auch was sie macht ;)

 

Vor der Migration des Hypervisors  ist es dringend zu empfehlen, alle Snapshots zu löschen, besonders jene, die auch den CPU-Status/RAM enthalten.

[Doso 77]

Ist das so richtig?

 

Du bist in einem Zustand, den so vmtl. bisher niemand hier im Forum hatte, daher wird es schwer dir da irgendwie zu helfen Ihr habt da so richtig sc***e gebaut, wird Zeit für einen Case bei Microsoft.

[heuchler 17]

Hallo zusammen,

 

zunächst vielen Dank für die Antworten.

Also, ich bin gestern den Hyper-V Fall durchgegangen.
Danach startete der Exchange wieder die Dienste und via OWA lassen sich die Mails abrufen. Outlook startet lediglich im Offline Modus. 

 

Repladmin zeigt folgende Dinge:

 

6424b774-a3b6-431a-b0fd-f59440a7a7a1 auf USN   3790950 um 2012-01-18 11:50:46
Standardname-des-ersten-Standorts\SRV-DC01 auf USN  10651075 um 2015-06-06 11:45:37
Standardname-des-ersten-Standorts\SRV-DC auf USN   8494455 um 2015-06-06 11:51:00

Was der obere Wert zu bedeuten hat... keinen Schimmer. Das sieht nach einem alten DC aus, der mir völlig unbekannt ist.

 

SRV-DC (physikalisch) - gekürzte Form da sonst alle Test bestanden:

Verzeichnisserverdiagnose


Anfangssetup wird ausgefhrt:

   Der Homeserver wird gesucht...

   Homeserver = srv-dc

   * Identifizierte AD-Gesamtstruktur. 
   Sammeln der Ausgangsinformationen abgeschlossen.


Erforderliche Anfangstests werden ausgefhrt.

   
   Server wird getestet: Standardname-des-ersten-Standorts\SRV-DC

      Starting test: Connectivity

         ......................... SRV-DC hat den Test Connectivity bestanden.



Prim„rtests werden ausgefhrt.

   
   Server wird getestet: Standardname-des-ersten-Standorts\SRV-DC

      Starting test: Advertising

         ......................... SRV-DC hat den Test Advertising bestanden.

      Starting test: FrsEvent

         Fr den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind

         Warnungen oder Fehlerereignisse vorhanden. Fehler bei der

         SYSVOL-Replikation k”nnen Probleme mit der Gruppenrichtlinie zur Folge

         haben. 
         ......................... SRV-DC hat den Test FrsEvent bestanden.

      

SRV-DC01:

Domain Controller Diagnosis

Performing initial setup:
   Done gathering initial info.

Doing initial required tests
   
   Testing server: Standardname-des-ersten-Standorts\SRV-DC01
      Starting test: Connectivity
         ......................... SRV-DC01 passed test Connectivity

Doing primary tests
   
   Testing server: Standardname-des-ersten-Standorts\SRV-DC01
      Starting test: Replications
         ......................... SRV-DC01 passed test Replications
      Starting test: NCSecDesc
         ......................... SRV-DC01 passed test NCSecDesc
      Starting test: NetLogons
         ......................... SRV-DC01 passed test NetLogons
      Starting test: Advertising
         Warning: DsGetDcName returned information for \\srv-dc.fb.local, when we were trying to reach SRV-DC01.
         Server is not responding or is not considered suitable.
         ......................... SRV-DC01 failed test Advertising
      Starting test: KnowsOfRoleHolders
         ......................... SRV-DC01 passed test KnowsOfRoleHolders
      Starting test: RidManager
         ......................... SRV-DC01 passed test RidManager
      Starting test: MachineAccount
         ......................... SRV-DC01 passed test MachineAccount
      Starting test: Services
            NETLOGON Service is paused on [SRV-DC01]
         ......................... SRV-DC01 failed test Services
      Starting test: ObjectsReplicated
         ......................... SRV-DC01 passed test ObjectsReplicated
      Starting test: frssysvol
         ......................... SRV-DC01 passed test frssysvol
      Starting test: frsevent
         ......................... SRV-DC01 passed test frsevent
      Starting test: kccevent
         ......................... SRV-DC01 passed test kccevent
      Starting test: systemlog
         ......................... SRV-DC01 passed test systemlog
      Starting test: VerifyReferences
         ......................... SRV-DC01 passed test VerifyReferences
   
   Running partition tests on : ForestDnsZones
      Starting test: CrossRefValidation
         ......................... ForestDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones passed test CheckSDRefDom
   
   Running partition tests on : DomainDnsZones
      Starting test: CrossRefValidation
         ......................... DomainDnsZones passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones passed test CheckSDRefDom
   
   Running partition tests on : Schema
      Starting test: CrossRefValidation
         ......................... Schema passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Schema passed test CheckSDRefDom
   
   Running partition tests on : Configuration
      Starting test: CrossRefValidation
         ......................... Configuration passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... Configuration passed test CheckSDRefDom
   
   Running partition tests on : fb
      Starting test: CrossRefValidation
         ......................... fb passed test CrossRefValidation
      Starting test: CheckSDRefDom
         ......................... fb passed test CheckSDRefDom
   
   Running enterprise tests on : fb.local
      Starting test: Intersite
         ......................... fb.local passed test Intersite
      Starting test: FsmoCheck
         ......................... fb.local passed test FsmoCheck

Vielleicht kann jemand etwas damit anfangen?

@Doso: danke. Wie und wo mache ich das? 
 

Hast Du etwa aktive Snapshots auf den VMs? 

Die hat man in produktiven Umgebungen nicht. Niemals. Die nutzt man nur kurzzeitig, wen man weis, dass man es machen kann, oder zum Backup

Ausgenommen sind spezielle Lösungen wie VMWare View. Die Lösung weis dann aber auch was sie macht ;)

 

Vor der Migration des Hypervisors  ist es dringend zu empfehlen, alle Snapshots zu löschen, besonders jene, die auch den CPU-Status/RAM enthalten.

Eigentlich gibt es keine Snapshots.
Die Backuplösung sichert die komplette VM weg und in der Rücksicherung hat man die Wahl zwischen kompletter Rücksicherung, oder Rollback auf den letzten Stand. Das wurde hier gemacht. 

bearbeitet 6. Juni 2015 von heuchler

[daabm 1.184]

Was steht denn so im Directory Service Eventlog auf den beiden Servern an Fehlern und Warnungen?

 

Ansonsten bei USN-Rollback: srv-dc01 ausschalten, dann Metadata Cleanup auf srv-dc durchführen (alle Reste von srv-dc01 in DHCP, DNS, Sites und Services sowie Benutzer und Computer beseitigen - und alles, was Du vielleicht sonst noch so an Leichen findest :D ). FSMO-Rollen auf srv-dc seizen (warum habt Ihr die verteilt?) Dann srv-dc01 neu aufsetzen. Dürfte keine 2 Stunden dauern - Kopf hoch :)

[heuchler 17]

Kopf hoch? Eher Kopf ab. 

Sowas beschleicht mich IMMER mit einem schlechten Gefühl. Das ist mein IT-unfreundliches Charma. Innerlich wehre ich mich auch gegen EDV.
 

Nochmal kurz: der Dienstleister hat hier irgendwie keine Schuld, da kommt hier so schräg rüber.

Die Struktur ist veraltet, es sind Leichen vorhanden (bis vor kurzem habe ich mich gefragt warum wir so wenig Probleme hatten weil teilweise auf stillgelegte DNS Server umgeleitet wurde etc.)
Ja, das Backupkonzept für diese Systeme ist sch... das weiß ich nun auch.
 

Ich frage mich aber auch, was man jetzt hätte besser machen können... hat man nur eine Gabel zum Steak, wird's auch schwer Manieren zu wahren.

Oder auch: 
***   Wenn das Unmögliche eliminiert wurde, muss das Unwahrscheinliche zutreffen - so unwahrscheinlich es auch ist   ***

 

Überhaupt war das wieder ein Fall für mich! Wenn was schief geht, dann zwei, drei Dinge auf einmal. Charma!

 

@daabm:

Danke nochmal.
Warum die Rollen verteilt sind? Weiß ich nicht, war vor meiner Zeit. Vielleicht weil es Probleme bei der Übernahme gab? Ich kann nur spekulieren, aber das kommt mir in dieser *räusper* gewachsenen, veralteten Struktur am plausibelsten vor.

Zu den Events:
srv-dc01 (problemkind)

Ereignistyp:	Fehler
Ereignisquelle:	NTDS General
Ereigniskategorie:	Dienststeuerung 
Ereigniskennung:	2103
Datum:		05.06.2015
Zeit:		22:10:13
Benutzer:		NT-AUTORITÄT\ANONYMOUS-ANMELDUNG
Computer:	SRV-DC01
Beschreibung:
Die Active Directory-Datenbank wurde mit Hilfe eines nicht unterstützen Wiederherstellungsvorgangs wiederhergestellt. 
 
Solange dieser Zustand besteht, können keine Benutzer durch das Active Directory angemeldet werden. Aus diesem Grund wird der Anmeldedienst angehalten. 
 
Benutzeraktion 
Weitere Informationen finden Sie in vorherigen Ereignisprotokollen.

Weitere Informationen über die Hilfe- und Supportdienste erhalten Sie unter http://go.microsoft.com/fwlink/events.asp.

Das war das letzte von gestern Abend, nachdem ich das mit der Replikation wieder angeschmissen habe.

Heute sind keine Warnungen vorhanden.

Auf dem SRV-DC stehen einige dieser Meldungen drin. Alle haben etwas mit den FSMO Rollen zu tun:

 

Protokollname: Directory Service

Quelle:        Microsoft-Windows-ActiveDirectory_DomainService

Datum:         06.06.2015 12:17:12

Ereignis-ID:   2092

Aufgabenkategorie:Replikation

Ebene:         Warnung

Schlüsselwörter:Klassisch

Benutzer:      ANONYMOUS-ANMELDUNG

Computer:      srv-dc.fb.local

Beschreibung:

 

Dieser Server ist der Besitzer der folgenden FSMO-Rolle, die jedoch nicht als gültig eingestuft wird. Für die Partition, die das FSMO enthält, wurde dieser Server seit dem letzten Neustart nicht erfolgreich mit einem beliebigen Partner repliziert. Replikationsfehler verhindern die Verifizierung dieser Rolle. 

 

Vorgänge, die eine Kontaktaufnahme mit dem FSMO-Betriebsmaster erfordern, sind nicht erfolgreich, solange dieser Zustand nicht behoben wird. 

 

FSMO-Rolle: DC=fb,DC=local 

 

Benutzeraktion: 

 

1. Die ursprüngliche Synchronisierung ist die erste Replikation, die von dem System beim Start durchgeführt wird. Das Scheitern der ursprünglichen Synchronisierung ist eventuell die Ursache dafür, dass die FSMO-Rolle nicht verifiziert werden kann. Dieser Prozess wird im KB-Artikel 305476 erklärt. 

2. Dieser Server verfügt über mindestens einen Replikationspartner, und die Replikation scheitert bei allen Partnern. Führen Sie den Befehl "REPADMIN /showrepl" aus, um die Replikationsfehler anzuzeigen. Beheben Sie den fraglichen Fehler. Es sind eventuell Probleme mit der IP-Konnektivität, der DNS-Namenauflösung oder mit der Sicherheitsauthentifizierung aufgetreten, die die erfolgreiche Replikation verhindern. 

3. In dem Ausnahmefall, dass alle Replikationspartner inaktiv sind, eventuell zu Wartungszwecken oder zur Notfall-Wiederherstellung, können Sie die Verifizierung der Rolle erzwingen. Führen Sie NTDSUTIL.EXE aus, um die Rolle für den gleichen Server zu übernehmen. Dieser Vorgang sollte entsprechend den Schritten, die in den KB-Artikeln 255504 und 324801 unter "http://support.microsoft.com"aufgelistet sind, durchgeführt werden. 

 

Die folgenden Vorgänge werden eventuell beeinträchtigt: 

Schema: Sie können das Schema für diese Gesamtstruktur nicht mehr modifizieren. 

Domänenbenennung: Sie können keine Domänen zu dieser Gesamtstruktur hinzufügen bzw. daraus entfernen. 

PDC: Sie können auf dem primären Domänencontroller keine weiteren Vorgänge durchführen, wie z.B. die Aktualisierung von Gruppenrichtlinien oder das Zurücksetzen von Kennwörtern für nicht in Active Directory Lightweight Directory Services vorhandene Konten. 

RID: Sie können keine neuen Sicherheits-IDs für neue Benutzer- oder Computerkonten bzw. für Sicherheitsgruppen zuweisen. 

Infrastruktur: Domänenübergreifende Namensverweise, wie z.B. universelle Gruppenmitgliedschaften, werden nicht ordnungsgemäß aktualisiert, wenn das Zielobjekt entfernt oder umbenannt wird.

 

 

 

Protokollname: Directory Service

Quelle:        Microsoft-Windows-ActiveDirectory_DomainService

Datum:         05.06.2015 19:15:37

Ereignis-ID:   2092

Aufgabenkategorie:Replikation

Ebene:         Warnung

Schlüsselwörter:Klassisch

Benutzer:      ANONYMOUS-ANMELDUNG

Computer:      srv-dc.fb.local

Beschreibung:

 

Dieser Server ist der Besitzer der folgenden FSMO-Rolle, die jedoch nicht als gültig eingestuft wird. Für die Partition, die das FSMO enthält, wurde dieser Server seit dem letzten Neustart nicht erfolgreich mit einem beliebigen Partner repliziert. Replikationsfehler verhindern die Verifizierung dieser Rolle. 

 

Vorgänge, die eine Kontaktaufnahme mit dem FSMO-Betriebsmaster erfordern, sind nicht erfolgreich, solange dieser Zustand nicht behoben wird. 

 

FSMO-Rolle: CN=Infrastructure,DC=fb,DC=local 

 

Benutzeraktion: 

 

1. Die ursprüngliche Synchronisierung ist die erste Replikation, die von dem System beim Start durchgeführt wird. Das Scheitern der ursprünglichen Synchronisierung ist eventuell die Ursache dafür, dass die FSMO-Rolle nicht verifiziert werden kann. Dieser Prozess wird im KB-Artikel 305476 erklärt. 

2. Dieser Server verfügt über mindestens einen Replikationspartner, und die Replikation scheitert bei allen Partnern. Führen Sie den Befehl "REPADMIN /showrepl" aus, um die Replikationsfehler anzuzeigen. Beheben Sie den fraglichen Fehler. Es sind eventuell Probleme mit der IP-Konnektivität, der DNS-Namenauflösung oder mit der Sicherheitsauthentifizierung aufgetreten, die die erfolgreiche Replikation verhindern. 

3. In dem Ausnahmefall, dass alle Replikationspartner inaktiv sind, eventuell zu Wartungszwecken oder zur Notfall-Wiederherstellung, können Sie die Verifizierung der Rolle erzwingen. Führen Sie NTDSUTIL.EXE aus, um die Rolle für den gleichen Server zu übernehmen. Dieser Vorgang sollte entsprechend den Schritten, die in den KB-Artikeln 255504 und 324801 unter "http://support.microsoft.com"aufgelistet sind, durchgeführt werden. 

 

Die folgenden Vorgänge werden eventuell beeinträchtigt: 

Schema: Sie können das Schema für diese Gesamtstruktur nicht mehr modifizieren. 

Domänenbenennung: Sie können keine Domänen zu dieser Gesamtstruktur hinzufügen bzw. daraus entfernen. 

PDC: Sie können auf dem primären Domänencontroller keine weiteren Vorgänge durchführen, wie z.B. die Aktualisierung von Gruppenrichtlinien oder das Zurücksetzen von Kennwörtern für nicht in Active Directory Lightweight Directory Services vorhandene Konten. 

RID: Sie können keine neuen Sicherheits-IDs für neue Benutzer- oder Computerkonten bzw. für Sicherheitsgruppen zuweisen. 

Infrastruktur: Domänenübergreifende Namensverweise, wie z.B. universelle Gruppenmitgliedschaften, werden nicht ordnungsgemäß aktualisiert, wenn das Zielobjekt entfernt oder umbenannt wird.

  

 

Andere Frage: ich bereite gerade die Informationen für MS vor.
Wie allergisch reagiert MS auf die Verwendung des Citrix XenServers? Schließlich gab es ja Probleme nach der Installation der Tools.

bearbeitet 6. Juni 2015 von heuchler

[Sunny61 772]

Lt. den Forenregeln sollst Du auf Crossposting hinweisen: http://social.Technet.microsoft.com/Forums/de-DE/active_directoryde/thread/4012dc05-b152-4885-82f8-db4946c45e66#4012dc05-b152-4885-82f8-db4946c45e66
 

Lass die Leute in den Technetforen bitte auch wissen, dass Du hier bereits einen Thread mit vielen Antworten laufen hast. Nein, es ist nicht verboten, aber tust du es nicht, und die Leute kriegen es durch Zufall selbst heraus, verprellst Du dir möglicherweise potentielle Helfer.

[heuchler 17]

Oh Sunny: Danke!

 

[zahni 521]

 

Andere Frage: ich bereite gerade die Informationen für MS vor.

Wie allergisch reagiert MS auf die Verwendung des Citrix XenServers? Schließlich gab es ja Probleme nach der Installation der Tools.

 

 

 

 

Solange der Hypervisor eine von MS unterstützte Third-Party Lösung ist, hast Du keine Probleme. Und Citrix sollte dazu zählen.

Ich habe gestern auch einen Case bei MS aufgemacht, damit ein manueller Kernel-Dump aus einer VMWare-VM analysiert wird. Wird haben da so ein seltsames Problem.

Allerdings "bedienen" wir uns hier aus einem Premier-Vertrag unserer "Mutter". Jetzt können sich VmWare und MS ihre Case-Id's gegenseitig... ;)

[heuchler 17]

Wie es der Zufall will bekam ich gerade eine 180 Tage Erinnerung von unserem Softwarehaus / Dienstleister für 
 

MicrosoftWindowsServerCAL Sngl License/SoftwareAssurancePack OLV 1License NoLevel AdditionalProduct DvcCAL 1Year Acquiredyear1 

Ich glaube diese bezieht sich allerdings auf Server 2012 CALs. Können wir damit etwas anfangen?

Oder hat das nichts mit Support zu tun?

 

bearbeitet 6. Juni 2015 von heuchler

[daabm 1.184]

Computer: SRV-DC01

Beschreibung:

Die Active Directory-Datenbank wurde mit Hilfe eines nicht unterstützen Wiederherstellungsvorgangs wiederhergestellt.

Na dann - Augen zu und durch: DC01 ausschalten, Metadata Cleanup, neu machen - so wie ich oben schon geschrieben hatte :)

[heuchler 17]

Hey,

 

mittlerweile habe ich es schon durchgezogen.

Nach ein paar bangen Minuten hat sich der Exchange auch wieder beruhigt und Outlook ließ sich wieder einrichten.
Dabei wurde auch der alte DC rausgeschmissen.

 

Jetzt warte ich ab wie es sich entwickelt.

Die Ereignisanzeige sieht soweit gut aus, Anmeldungen funktionieren auch wieder.
Was für ein Drama.

Jetzt bearbeite ich gerade die Memberserver zwecks DNS löschen.
Dann geht es an den Terminalserver.

 

Jetzt brauche ich erstmal ne Tüte Schlaf.

Werde dann morgen berichten.

 

Danke euch vielmals - vorallem für die moralische Unterstützung ;-) !

 

bearbeitet 6. Juni 2015 von heuchler

[daabm 1.184]

Keine Ursache - ein kaputter DC ist solange kein Problem, solange es noch weitere DCs gibt :)