19.10.2016, aktualisiert um 14:10:38 Uhr

7130

SBS2011 demoten - Es konnten keine anderen AD-DCs für diese Domäne ermittelt werden

Hallo zusammen,

ich bin gerade dabei einen SBS2011 abzulösen.
Seit einigen Wochen habe ich einen Server2012R2 als Domaincontroller in die SBS Domäne aufgenommen. Am SBS wurde inzwischen der Exchange deinstalliert als auch die Rolle der AD Zertifikatsdienste damit ich den Server überhaupt demoten kann. Netzwerk läuft einwandfrei.
Die FSMO Rollen wurden auch bereits auf den neuen Server sauber übertragen ( gegengeprüft mit netdom query fsmo )
Nun habe ich dcpromo gestartet und angegeben dass mein Server nicht der letzte Server in der Domäne ist..
Hier taucht dann folgende Fehlermeldung auf

Den Replikationsstaus habe ich auch geprüft, sichta uch alles gut aus:

Bin etwas ratlos, da sich die FSMO Rollen ja sauber haben verschieben lassen und auch sonst im Netzwerk alles einwandfrei läuft.
Der SBS hat als ersten DNS sich selbst, und als weiteren DNS den neuen 2012er.

dsquery server sowie netdom query dc sagen mir dass alles OK ist

Jemand noch eine Idee?

Vielen Dank.

Gruß Michael

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 318406

Url: https://administrator.de/forum/sbs2011-demoten-es-konnten-keine-anderen-ad-dcs-fuer-diese-domaene-ermittelt-werden-318406.html

Ausgedruckt am: 13.04.2025 um 21:04 Uhr

23 Kommentare

Neuester Kommentar

Hi,
ist der neue DC auch GC?

E.

Hallo Emerkis,

ja beide Server sind derzeit GC!

Auch wenn beim DC-V-SVR W2K steht, das ist ein Windows Server 2012R2 ( virtualisiert )
Michael

Hallo.

Sicher, daß sich ein SBS überhaupt demoten läßt? By Design ist ein SBS immer ein DC. Ich könnte mir vorstellen, daß Du ihn, wenn er von aller Arbeit befreit ist (Rollen, Exchange, WSUS, Fileserver, DNS, DHCP, SQL), einfach herunterfährst (und nie wieder hochfährst!!!) und seine Information (also die Information über seine Existenz) später im AD löschst (ADSI Edit).

Außerdem:

Seit einigen Wochen ...

sagt mir, daß Du die Karenzphase von 21 Tagen, die Du eigentlich nur für die Migration Zeit hast (bzw. für die Koexistenz zweier DCs nach dem Übertrag der FSMO an den neuen), längst überschritten hast, vielleicht macht auch das die Probleme. Bei zwei "normalen" DCs ist das egal, nicht jedoch, wenn einer ein SBS war/ist.

Viele Grüße

von

departure69

Hallo departure,

ja ich bin mir sicher dass ich einen SBS demoten kann und ihn anschliessend aus dem Netzwerk entfernen kann.
Müssen nur einige Vorraussetzungen gegeben sein, wie z.B. vorige deinstallation des Exchange!

Seit einigen Wochen existiert ein 2ter DC in der Domäne. Die FSMO Rollen habe ich erst am MONTAG verschoben. Koexistens von mehreren DC's in einer SBS umgebung ist Problemlos möglich, nur muss eben der SBS alleinger Rolleninhaber sein!

Sobald dieser dies nicht mehr ist habe ich, soweit ich weis, 21 tage Zeit diesen aus der Domäne zu entfernen, bzw. der SBS fährt glaube ich nach einer gewissen Zeit immer wieder von alleine runter.

Genau deswegen muss ich ja diesen auch noch aus der Domäne entfernen, was widerum nur mit DCPROMO funktioniert.

Grüße Michael

Genau deswegen muss ich ja diesen auch noch aus der Domäne entfernen, was widerum nur mit DCPROMO funktioniert.

Also wenn es darum geht, den SBS vollständig aus der Domäne zu entfernen, dann würde ich jetzt auch den von @departure69 vorgeschlagenen Weg gehen und den SBS hart entfernen.

SBS ausschalten - nie wieder online nehmen
Metadaten bereinigen

z.B. mit NTDSUITL (regulärer Weg von Microsoft)
oder seit einiger Zeit auch möglich:

löschen des DC in der MMC "Benutzer und Computer"
und löschen des Servers in der MMC "Standorte und Dienste" unterhalb des AD-Standorts

ggf. Löschen des Servers aus allen anderen Partitionen, sofern zutreffend
z.B. DNS Anwendungspartition.

Wenn der SBS anschließend noch als Memberserver laufen soll, dann geht das so natürlich nicht.

Hallo,

hart rausnehmen sollte aber der letzte Weg sein. Mich würde interessieren warum der Server angeblich keinen weiteren DC findet obwohl alles soweit korrekt läuft. Wenn alle Rechechen nix helfen werde ich mich zum harten entfernen hin bewegen

VG Michael

Hallo,

ist der neue DC auch DNS-Server und ist der neue DC beim SBS auch als primärer DNS Server eingetragen?

Gruß

Chonta

Hallo Chonta,

der neue DC ist auch DNS Server.
Beim SBS habe ich als 1. DNS ihn selbst und als 2ten DNS den neuen 2012er DC
Beim 2012er DC habe ich als 1. DNS ihn selbst und als 2ten DNS den alten SBS.

Gruß Michael

Beim SBS habe ich als 1. DNS ihn selbst und als 2ten DNS den neuen 2012er DC

Dreh das mal um, vielleicht hilft's.

Nicht, dass da noch ein Bug im DCPROMO vorliegt, etwas so:
- AD bereits angehalten
- deswegen hat der DNS keine Zone mehr (weil im AD gespeichert), läuft aber noch und gibt negative Antworten
- deshalb geht der Client (der SBS selbst) nicht auf den 2. DNS

Könnte ja sein ...

Hi emeriks,

habs grad probiert. DNS am SBS gedreht, Server neu gestartet. Problem besteht aber weiterhin .-)

Grüße

Was sagt den die Ereignisanzeige(n) und zwar die, die das AD betreffen, also unter Anwendungs- und Dienstprotokolle
Was sagt DCDIAG?
Was sagt den repadmin?

LG Günther

@emeriks:

Wenn der SBS anschließend noch als Memberserver laufen soll, dann geht das so natürlich nicht.

Kann er gar nicht, er würde dann, wenn man ihn über die 21 Tage hinaus laufen läßt, danach im Stundentakt sich selbst und den neuen DC neu starten. Ein SBS kann nach dem demoten (sofern es überhaupt gelingt - ich glaube nach wie vor nicht daran, ob das überhaupt für einen SBS so vorgesehen ist) gar nicht als Memberserver weiterlaufen. Und deshalb halte ich dcpromo hier auch für unnötig, und vielleicht scheitert unser Fragesteller @takvorian genau deshalb daran. Mag ja sein, daß sich dcpromo auf dem SBS starten läßt, aber wenn es nicht zum Abschluß kommt, dann hat das Gründe, m. E. nämlich genau den, daß ein Demote eines SBS absolut nichts bringt.

@takvorian:

Mach' es so, wie es @emeriks und ich vorgeschlagen haben. Nur weil das eine "harte" Entfernung ist, ist das deswegen nicht unsauber, wenn man's richtig macht. @emeriks hat's eigentlich genau richtig beschrieben. Wenn die Kiste jetzt wirklich komplett arbeitslos ist (dessen mußt Du Dir natürlich absolut sicher sein, das können wir nicht wissen), hau' ihn weg.

Viele Grüße

von

departure69

Guten Morgen zusammen,

Alle Ausgaben vom alten SBS
im Eventlog der AD-Webdienste tauchen folgende Fehler auf:

Auf diesem Computer wird nun die angegebene Verzeichnisinstanz gehostet, doch konnte diese von Active Directory-Webdiensten nicht bedient werden. Von Active Directory-Webdiensten wird in regelmäßigen Abständen erneut versucht, den Vorgang auszuführen.
 
 Verzeichnisinstanz: NTDS
 LDAP-Port der Verzeichnisinstanz: 389
 SSL-Port der Verzeichnisinstanz: 636

Beim Dateireplikationsdienst:

Der Dateireplikationsdienst hat ermittelt, dass sich der Replikatsatz "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" sich in JRNL_WRAP_ERROR befindet.   
 
 Name des Replikatsatzes    : "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"   
 Replikatstammpfad           : "c:\windows\sysvol\domain"   
 Replikatstammvolume         : "\\.\C:"   
 Ein Replikatsatz stößt auf JRNL_WRAP_ERROR, wenn der Eintrag, von dem gelesen werden soll, nicht vom NTFS-USN-Journal gefunden wird. Mögliche Ursachen hierfür sind: 
 
 [1] Volume "\\.\C:" wurde formatiert.   
 [2] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde gelöscht.   
 [3] Das NTFS-USN-Journal auf Volume "\\.\C:" wurde abgeschnitten. Chkdsk kann das Journal abschneiden, falls es beschädigte Einträge am Ende des Journals vorfindet.   
 [4] Der Dateireplikationsdienst wurde seit längerer Zeit auf diesem Computer nicht mehr ausgeführt. 
 [5] Die Rate der Laufwerks-E/A-Aktivität auf "\\.\C:" war zu schnell für den Dateireplikationsdienst.   
 Das Festlegen des Registrierungsparameters "Enable Journal Wrap Automatic Restore" auf 1 führt dazu, dass folgende Maßnahmen zum automatischen Beheben des Fehlerzustands vorgenommen werden.   
 [1] Beim ersten Poll, der in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatsatz entfernt. Wenn Sie nicht 5 Minuten warten möchten, führen Sie "net stop ntfrs" aus, gefolgt von "net start ntfrs", um den Dateireplikationsdienst neu zu starten.   
 [2] Beim auf die Löschung folgenden Poll wird der Computer erneut zum Replikatsatz hinzugefügt. Durch das erneute Hinzufügen wird eine vollständige Struktursynchronisierung für den Replikatsatz ausgelöst. 
 
WARNUNG: Während des Wiederherstellungsvorgangs sind Daten in der Replikatstruktur möglicherweise nicht verfügbar. Sie sollten den oben beschriebenen Registrierungsparameter auf 0 festlegen, um eine unerwartete Nichtverfügbarkeit von Daten durch die automatische Wiederherstellung zu verhindern, wenn dieser Fehlerzustand erneut auftritt. 
 
Führen Sie regedit aus, um diesen Registrierungsparameter zu ändern. 
 
Klicken Sie auf "Start", dann auf "Ausführen", und geben Sie dann "regedit" ein.   
 
Erweitern HKEY_LOCAL_MACHINE. 
Folgen Sie folgendem Pfad: 
   "System\CurrentControlSet\Services\NtFrs\Parameters"   
Doppelklicken Sie auf den Namen des Wertes 
   "Enable Journal Wrap Automatic Restore"   
und aktualisieren Sie den Wert. 
 
Ist der Name des Wertes nicht vorhanden, können Sie ihn mit dem Befehl "Neu" und dann "DWORD-Wert " im Menü "Bearbeiten" hinzufügen. Geben Sie den Wert genauso ein wie oben gezeigt.  

sowie als Warnung:

Der Dateireplikationsdienst hat einen aktivierten Datenträgerschreibungs-Cache in dem Laufwerk mit dem Verzeichnis "c:\windows\ntfrs\jet" auf dem Computer "SBS-SVR" ermittelt. Der Dateireplikationsdienst kann eventuell nicht wiederhergestellt werden, wenn die Stromzufuhr des Laufwerks unterbrochen wird und wichtige Aktualisierungen verloren gehen.  

Die restlichen Eventlogs sind soweit sauber.

Was mir noch aufgefallen ist:
\\sbs-svr\netlogon --> OK
\dc-v-svr\netlogon --> diese Freigabe existiert nicht
Bevor ich nun zum DCDIAG komme... ich frag mich warum das netlogon am neuen Server, welcher sauber zum DC promoted wurde, nicht freigegeben ist? Ist doch zwingend erforderlich...

DCIDAG bringt einen Fehler

Windows PowerShell
Copyright (C) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

PS C:\Windows\system32> dcdiag

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = SBS-SVR
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SBS-SVR
      Starting test: Connectivity
         ......................... SBS-SVR hat den Test Connectivity bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\SBS-SVR
      Starting test: Advertising
         ......................... SBS-SVR hat den Test Advertising bestanden.
      Starting test: FrsEvent
         Für 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.
         ......................... SBS-SVR hat den Test FrsEvent nicht bestanden.
      Starting test: DFSREvent
         ......................... SBS-SVR hat den Test DFSREvent bestanden.
      Starting test: SysVolCheck
         ......................... SBS-SVR hat den Test SysVolCheck bestanden.
      Starting test: KccEvent
         ......................... SBS-SVR hat den Test KccEvent bestanden.
      Starting test: KnowsOfRoleHolders
         ......................... SBS-SVR hat den Test KnowsOfRoleHolders bestanden.
      Starting test: MachineAccount
         ......................... SBS-SVR hat den Test MachineAccount bestanden.
      Starting test: NCSecDesc
         ......................... SBS-SVR hat den Test NCSecDesc bestanden.
      Starting test: NetLogons
         ......................... SBS-SVR hat den Test NetLogons bestanden.
      Starting test: ObjectsReplicated
         ......................... SBS-SVR hat den Test ObjectsReplicated bestanden.
      Starting test: Replications
         ......................... SBS-SVR hat den Test Replications bestanden.
      Starting test: RidManager
         ......................... SBS-SVR hat den Test RidManager bestanden.
      Starting test: Services
         ......................... SBS-SVR hat den Test Services bestanden.
      Starting test: SystemLog
         ......................... SBS-SVR hat den Test SystemLog bestanden.
      Starting test: VerifyReferences
         ......................... SBS-SVR hat den Test VerifyReferences bestanden.


   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... ForestDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... DomainDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Schema hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Configuration hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: sbs2011
      Starting test: CheckSDRefDom
         ......................... sbs2011 hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... sbs2011 hat den Test CrossRefValidation bestanden.

   Unternehmenstests werden ausgeführt auf: sbs2011.local
      Starting test: LocatorCheck
         ......................... sbs2011.local hat den Test LocatorCheck bestanden.
      Starting test: Intersite
         ......................... sbs2011.local hat den Test Intersite bestanden.
PS C:\Windows\system32>

Hallo nochmal,

anders sieht es beim DC-V-SVR mit dcdiag aus:

Windows PowerShell
Copyright (C) 2014 Microsoft Corporation. Alle Rechte vorbehalten.

PS C:\Windows\system32> dcidag
dcidag : Die Benennung "dcidag" wurde nicht als Name eines Cmdlet, einer Funktion, einer Skriptdatei oder eines  
ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist (sofern
enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ dcidag
+ ~~~~~~
    + CategoryInfo          : ObjectNotFound: (dcidag:String) , CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

PS C:\Windows\system32> dcdiag

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = DC-V-SVR
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC-V-SVR
      Starting test: Connectivity
         ......................... DC-V-SVR hat den Test Connectivity bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC-V-SVR
      Starting test: Advertising
         Achtung: Bei dem Versuch, DC-V-SVR zu erreichen, wurden von DsGetDcName Informationen für
         \\SBS-SVR.sbs2011.local zurückgegeben.
         DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.
         ......................... Der Test Advertising für DC-V-SVR ist fehlgeschlagen.
      Starting test: FrsEvent
         Für 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.
         ......................... DC-V-SVR hat den Test FrsEvent bestanden.
      Starting test: DFSREvent
         ......................... DC-V-SVR hat den Test DFSREvent bestanden.
      Starting test: SysVolCheck
         ......................... DC-V-SVR hat den Test SysVolCheck bestanden.
      Starting test: KccEvent
         ......................... DC-V-SVR hat den Test KccEvent bestanden.
      Starting test: KnowsOfRoleHolders
         ......................... DC-V-SVR hat den Test KnowsOfRoleHolders bestanden.
      Starting test: MachineAccount
         ......................... DC-V-SVR hat den Test MachineAccount bestanden.
      Starting test: NCSecDesc
         ......................... DC-V-SVR hat den Test NCSecDesc bestanden.
      Starting test: NetLogons
         Die Verbindung mit der NETLOGON-Freigabe kann nicht hergestellt werden. (\\DC-V-SVR\netlogon)
         [DC-V-SVR] Bei einem Vorgang vom Typ "net use" oder "LsaPolicy" ist der Fehler 67 aufgetreten,  
         Der Netzwerkname wurde nicht gefunden..
         ......................... Der Test NetLogons für DC-V-SVR ist fehlgeschlagen.
      Starting test: ObjectsReplicated
         ......................... DC-V-SVR hat den Test ObjectsReplicated bestanden.
      Starting test: Replications
         ......................... DC-V-SVR hat den Test Replications bestanden.
      Starting test: RidManager
         ......................... DC-V-SVR hat den Test RidManager bestanden.
      Starting test: Services
         ......................... DC-V-SVR hat den Test Services bestanden.
      Starting test: SystemLog
         Warnung. Ereignis-ID: 0x00001796
            Erstellungszeitpunkt: 10/20/2016   08:15:15
            Ereigniszeichenfolge:
            Von Microsoft Windows Server wurde festgestellt, dass momentan zwischen Clients und diesem Server die NTLM-A
uthentifizierung verwendet wird. Dieses Ereignis tritt einmal pro Serverstart auf, wenn NTLM von einem Client erstmalig
für den Server verwendet wird.
         ......................... DC-V-SVR hat den Test SystemLog bestanden.
      Starting test: VerifyReferences
         ......................... DC-V-SVR hat den Test VerifyReferences bestanden.


   Partitionstests werden ausgeführt auf: ForestDnsZones
      Starting test: CheckSDRefDom
         ......................... ForestDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... ForestDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: DomainDnsZones
      Starting test: CheckSDRefDom
         ......................... DomainDnsZones hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... DomainDnsZones hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Schema
      Starting test: CheckSDRefDom
         ......................... Schema hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Schema hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: Configuration
      Starting test: CheckSDRefDom
         ......................... Configuration hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... Configuration hat den Test CrossRefValidation bestanden.

   Partitionstests werden ausgeführt auf: sbs2011
      Starting test: CheckSDRefDom
         ......................... sbs2011 hat den Test CheckSDRefDom bestanden.
      Starting test: CrossRefValidation
         ......................... sbs2011 hat den Test CrossRefValidation bestanden.

   Unternehmenstests werden ausgeführt auf: sbs2011.local
      Starting test: LocatorCheck
         ......................... sbs2011.local hat den Test LocatorCheck bestanden.
      Starting test: Intersite
         ......................... sbs2011.local hat den Test Intersite bestanden.
PS C:\Windows\system32>

Ich denke, bevor ich den SBS rausnehmen kann ( egal ob hart oder sanft

) muss ich das Thema mit dem NETLOGIn in Griff bekommen!

Gruß Michael

So hallozum 3ten,

am neuen DC-V_SVR gerade eben Eventlog FRS geprüft:

Der Dateireplikationsdienst kann die Replikation von SBS-SVR nach DC-V-SVR für c:\windows\sysvol\domain mit DNS-Namen SBS-SVR.sbs2011.local nicht aktivieren. Es wird ein neuer Versuch gestartet. 
 Mögliche Ursachen für diese Warnung sind: 
 
 [1] Der DNS-Name SBS-SVR.sbs2011.local von diesem Computer konnte nicht ausgewertet werden. 
 [2] Der Dateireplikationsdienst wird auf SBS-SVR.sbs2011.local nicht ausgeführt. 
 [3] Die Topologieinformationen in den Active Directory-Domänendiensten dieses Replikats wurden noch nicht auf allen Domänencontrollern repliziert. 
 
 Diese Ereignisprotokollmeldung wird einmal pro Verbindung angezeigt. Nachdem der Fehler behoben wurde, wird eine andere Ereignisprotokollmeldung angezeigt, die bestätigt, dass die Verbindung hergestellt wurde.

sowie:

Der Dateireplikationsdienst kann die Replikation von SBS-SVR nach DC-V-SVR für c:\windows\sysvol\domain mit DNS-Namen SBS-SVR.sbs2011.local nicht aktivieren. Es wird ein neuer Versuch gestartet. 
 Mögliche Ursachen für diese Warnung sind: 
 
 [1] Der DNS-Name SBS-SVR.sbs2011.local von diesem Computer konnte nicht ausgewertet werden. 
 [2] Der Dateireplikationsdienst wird auf SBS-SVR.sbs2011.local nicht ausgeführt. 
 [3] Die Topologieinformationen in den Active Directory-Domänendiensten dieses Replikats wurden noch nicht auf allen Domänencontrollern repliziert. 
 
 Diese Ereignisprotokollmeldung wird einmal pro Verbindung angezeigt. Nachdem der Fehler behoben wurde, wird eine andere Ereignisprotokollmeldung angezeigt, die bestätigt, dass die Verbindung hergestellt wurde.

Irgendwo hakt es ganz gewaltig...

Gruß Michael

Da haben wir es doch. Wenn der neue DC nicht automatisch die beiden Freigaben SYSVOL und NETLOGON erstellt, dann ist das ein sicheres Zeichen dafür, dass er sich selbst als nicht funktionstüchtig betrachtet. Ursache ist ganz offensichtlich der Stall des Replikationsdienst. (JRNL_WRAP_ERROR )
Suche nach "JRNL_WRAP_ERROR " im Web. Da gibt es eine ganz klare Anleitung von Microsoft, wie man das behebt. Erst wenn beide Server beide Freigaben automatisch erstellen und keine Replikationsprobleme im Log gemeldet werden, wird das Demoten funktionieren.

Die Meldung mit den "Active Directory-Webdiensten" kannst Du ignorieren.

Edit:
https://support.microsoft.com/en-us/kb/290762
http://blogs.msmvps.com/acefekay/2013/08/28/how-to-recover-a-journal-wr ...

Hallo emeriks,

danke für die Links und den Hinweis. Ich such mich mal schlau und melde mich wieder

Gruß Michael

Hallo emerkis,

so´weit verstanden...

Here are the steps summarized:

    For an Authoritative Restore you must stop the NTFRS services on all of your DCs
    In the registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process
        Set the BurFlags setting to HEX “D4” on a known DC that has a good SYSVOL (or at this time restore SYSVOL data from backup then set the Burflag to D4)
        Then start NTFRS on this  server.
        You may want to rename the old folders with .old extensions prior to restoring good data.
    Clean up the folders on all the remaining servers (Policies, Scripts, etc) – renamed them with .old extensions.
    Set the BurFlags to D2 on all remaining servers and then start NTFRS.
    Wait for FRS to replicate.
    Clean up the .old stuff if things look good.
    If the “D4” won’t solve the problem try the “D2” value.

einzigste Unklarheit ist

You may want to rename the old folders with .old extensions prior to restoring good data.
    Clean up the folders on all the remaining servers (Policies, Scripts, etc) – renamed them with .old extensions.

Was soll ich da umbenennen? In welchem ordner? Da werd ich nicht ganz schlau draus:

Das "domain" verzeichnis wurde laut Datum ja neu erstellt und enthält auch die Scripts usw... hatte nichts umbenannt...
Gruß Michael

Da der neue Server DC-V-SVR nicht aller Freigaben hat, gehe ich davon aus, dass ER der Patient ist.
Deshalb betrachte den SBS als "known DC that has a good SYSVOL" und den Neuen als "all the remaining servers".

Ergo:
Auf dem neuen DC die Ordner "Policies" und "Scripts" unterhalb von C:\Windows\SYSVOL\sysvol\{Domänen}\ umbenennen.

Sodale,

Ordner umbenannt, Registry Werte gesetzt, Dienste gestartet.
Von der Struktur her sieht es gut aus. Registry Werte wurden automatisch wieder auf 0 gesetzt.

ein \\dc-v-svr\netlogon zeigt mir nun auch die inhalte an

Ich schau mir jetzt nochmal die eventlogs an und wenn das sauber ist versuche ich nochmal den Server zu demoten

Gruß und Danke Michael

Beachte die Erstellung der Freigaben!

Sieht auch soweit gut aus:

Neuer DC:

PS C:\Windows\system32> net share

Name         Ressource                       Beschreibung

-------------------------------------------------------------------------------
C$           C:\                             Standardfreigabe
E$           E:\                             Standardfreigabe
IPC$                                         Remote-IPC
ADMIN$       C:\Windows                      Remoteverwaltung
NETLOGON     C:\Windows\SYSVOL\sysvol\sbs2011.local\SCRIPTS
                                             Ressource für Anmeldeserver
SYSVOL       C:\Windows\SYSVOL\sysvol        Ressource für Anmeldeserver
Der Befehl wurde erfolgreich ausgeführt.

Alter SBS

PS C:\Windows\system32> net share

Name         Ressource                       Beschreibung

-------------------------------------------------------------------------------
ADMIN$       C:\Windows                      Remoteverwaltung
C$           C:\                             Standardfreigabe
Support$     F:\__Support
F$           F:\                             Standardfreigabe
IPC$                                         Remote-IPC
print$       C:\Windows\system32\spool\drivers
                                             Druckertreiber
Z$           Z:\                             Standardfreigabe
ExchangeOAB  C:\Program Files\Microsoft\Exchange Server\V14\ExchangeOAB
                                             OAB Distribution share
mirror       C:\Program Files (x86)\ESET\ESET Remote Administrator\Server\mirror

NETLOGON     C:\Windows\sysvol\sysvol\sbs2011.local\SCRIPTS
                                             Ressource für Anmeldeserver
SYSVOL       C:\Windows\sysvol\sysvol        Ressource für Anmeldeserver
UserShares   C:\Users\Shares
Der Befehl wurde erfolgreich ausgeführt.

Die noch vorhandenen Freigaben für mirror, UserShares, Exchange, werden nicht mehr grbraucht und fliegen nach dem demoten eh raus

Hallo zusammen,

ich habe gestern den Server blitzsauber demoten können, danach meine Rollen vom Server noch deinstalliert und ihn schlussendlich vom Memberserver in eine Arbeitsgruppe herabgestuft und ausgeschalten.
Netzwerk läuft weiterhin problemlos. Prüfe morgen nochmal die Eventlogs auf Auffälligkeiten, sieht aber soweit gut aus.

Danke @emerkis für die Unterstützung.

@departure wie gesagt es geht problemlos auch einen SBS sauber zu demoten und aus dem AD zu entfernen. Muss vorher nur alles passen ( was bei mir nicht der Fall war, aber durch Euch habe ich das alles sauber beheben können. )

Gruß Michael

gelöst Frage Microsoft Windows Server

Mehr von takvorian

Löschen von Dateien nach Altertakvorian - 8 Kommentare

Passendes Repositoy für cifs-utils fehlt wohltakvorian - 3 Kommentare

Surface Treiber für Marvel Avastar W-LANtakvorian - 3 Kommentare

O365 "senden als" Berechtigungtakvorian - 2 Kommentare

Heiß diskutiert