141986

20.07.2022, aktualisiert um 12:28:59 Uhr

3323

Nach BSI GPOs kennt DC sich selbst nicht mehr - PDC not found?

Hallo zusammen,

mir ist gestern etwas ziemliches dummes passiert.

Ich habe das GPO Bündel vom BSI importiert und ausgerollt. Nunja, seither geht gar nichts mehr.
Der DC kennt sich nun gar nicht mehr, geschweige das AD.
"RPC Server nicht verfügbar"

Der Netlogon Dienst mag nicht mehr hoch kommen weil Abhängigkeiten nicht hoch kommen (lt. Eventvwr: es fehlen Abhängigkeiten die sich allerdings auch nicht starten lassen)
Das hochfahren vom Server dauert ewig. ...

Ich tippe ganz schwer, dass die GPOs einiges zerbröselt haben.

Server: SBS11 (Flame on!)
2ter DC da inkl. Verzeichnis etc.
Allerdings fehlt hier überall der SBS11 als DC(?).

Mir gehen die Ideen aus.
Probiert habe ich:
einiges - ja das hilft Euch nun nicht weiter allerdings habe ich gar nicht mehr alles im Kopf was probiert wurde.

Auch den SBS Manager habe ich bereits durchlaufen lassen "Beheben von Netzwerkproblemen"
Versucht die lokalen Sicherheitsrichtlinien zurückzusetzen:

secedit / configure / cfg% windir% \ inf \ defltbase.inf / db defltbase.sdb / verbose

SFC und DISM durchgelaufen.

dcdiag:

   Server wird getestet: Default-First-Site-Name\SBS11

      Starting test: Connectivity

         * Active Directory LDAP Services Check
         Der Host 7253ae6a-4b10-4363-88d1-d5fb3659f77d._msdcs.firma.local

         konnte nicht zu einer IP-Adresse aufgel”st werden. šberprfen Sie

         DNS-Server, DHCP, Servername, usw.

         Fehler beim šberprfen der LDAP- und RPC-Konnektivit„t. šberprfen Sie

         die Firewalleinstellungen.

         ......................... SBS11 hat den Test Connectivity nicht

         bestanden.

      Starting test: LocatorCheck

         Name des globalen Katalogs: \\AMR-DC02.firma.local

         Locator Flags: 0xe003f3fc
         Achtung: Fehler beim Aufrufen von DcGetDcName(PDC_REQUIRED): 2102

         Es wurde kein prim„rer Dom„nencontroller gefunden.

         Der Server mit der Rolle fr den prim„ren Dom„nencontroller ist nicht

         verfgbar.

Irgendwie macht mir das ein ungutes Gefühl.

Mich ärgert der Missklick auf das aktivieren der Verknüpfung

Hat mir wer vielleicht noch einen Ansatz?

Bzgl: SBS11 und .local = bedarf es keine weiteren Kommentare..

Viele Grüße

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

Content-ID: 3386783919

Url: https://administrator.de/contentid/3386783919

Ausgedruckt am: 22.11.2024 um 15:11 Uhr

28 Kommentare

Neuester Kommentar

Hi,

sind die Server vom Client denn noch auflösbar per cmd?

Kannst du dich noch auf dem 2ten DC anmelden und das AD bearbeiten?

VG

Hi,

sind die Server vom Client denn noch auflösbar per cmd?

Jap, auch nslookup vom Client aus sieht gut aus (geht über 2ten DC).

nslookup
Standardserver:  amr-dc02.firma.local
Address:  192.168.20.5

> sbs11
Server:  amr-dc02.firma.local
Address:  192.168.20.5

Name:    sbs11.firma.local
Address:  192.168.20.10

Kannst du dich noch auf dem 2ten DC anmelden und das AD bearbeiten?

Jep. Da geht "komischerweise" alles recht gut. Auch der SBS meint, er synchronisiert das Verzeichnis..

Der DFS-Replikationsdienst hat erfolgreich eine eingehende Verbindung mit Partner "AMR-DC02" für Replikationsgruppe "Domain System Volume" hergestellt.   

Kann ich Dir sonst noch Daten liefern?

LG

Dann heb die Verknüpfung der BSI GPO doch erstmal wieder auf, auf dem funktionierenden DC oder ist es ein schreibgeschützter DC?

Die Verknüpfung ist schon nicht mehr aktiv. Die Sache ist eigentlich erst auffällig geworden, als einige SMB 1 Maschinen keinen Share mehr herstellen konnten. Heute Morgen war es dann der Gau bei der Anmeldung am Rechner.

So wie ich das sehe, wurden die Sicherheitseinstellungen lokal übernommen - auch ohne die GPO bleiben wohl die Einstellungen erhalten und genau diese würde ich gerne zurücksetzen. Eigentlich kann es nur an der BSI Vorlage hängen, vermutlich ...

LG

Wie auf dem Screenshot: ist da allerhand noch gesetzt auf dem fauligen DC.
Von Hand mag ich es eigentlich nicht zurücksetzen, da ich die Standards gar nicht kenne.

Dann müsste man sich die BSI GPO mal genau anschauen was sie genau alles geändert hat. Wenn die das SMB1 Protokoll deaktiviert hat kann auch nichts mehr funktioneren bei den XP? Maschinen.

Da bleibt vermutlich nur raus aus der Domäne und neu hinzufügen damit er sich die jetzige Richtlinie zieht.

Wenn die das SMB1 Protokoll deaktiviert hat kann auch nichts mehr funktioneren bei den XP? Maschinen

Genau

Ich schätze aber dass da noch eine Konfig mit reinspielt, dass der DC sich selbst nicht mehr kennt?!

Da bleibt vermutlich nur raus aus der Domäne und neu hinzufügen damit er sich die jetzige Richtlinie zieht.

Klappt das bei einem SBS?
Das kackteil macht mir Sorge..

LG

Hast du ne aktuelle Sicherung vom SBS? Wenn ja wirds wahrscheinlich bedeutend schneller sein das Backup einzuspielen als zu versuchen die ganzen gemachten Einstellungen rückgängig zu machen.

Bevor ich damit anfange, würde ich die ganzen aktivierten Richtlinien erstmal auf nicht definiert stellen und schauen wie es sich nach einem Neustart des Servers verhält. Ich habe mit SBS Servern nur schlechte Erfahrungen gemacht und möchte hier keine falschen Tipps geben.

Hast du ne aktuelle Sicherung vom SBS?

Habe ich, ist aber bei einem DC doch recht schwierig bzgl. Vertrauensstellung etc.?

nicht definiert

Genau da liegt mein Problem. Das gibt es da schlicht nicht

Er will eine Einstellung.

SBS Servern nur schlechte Erfahrungen gemacht

Samesame..

Danke Euch!

Das Verhalten ist echt spannend.

Server boot relativ schnell. Login OK!

Dann rödelt der Kreis um das Netzwerkicon. Dann kommt ein rotes X und nach einigen Minuten ist die Karre online. Allerdings ohne AD etc.

Ich verstehe es nicht.. >.<

Schau dir die BSI GPO doch mal an auf dem funktionierden DC. Speziell die auf dem Screenshot oben, dann stelle sie wieder auf das Gegenteil um auf dem SBS und schau ob sich was ändert.

Alternativ wenn der SBS nur DC ist und nichts anderes macht: Einen aktuellen DC hochziehen und den SBS für immer begraben. Vorher natürlich die FSMO Rollen prüfen usw.

Alternativ wenn der SBS nur DC ist und nichts anderes macht: Einen aktuellen DC hochziehen und den SBS für immer begraben. Vorher natürlich die FSMO Rollen prüfen usw.

Hierrüber denke ich schon eine Weile nach. Problem: Exchange im Hybidmode.

Mäh..

Hi

Welche Policy genau vom BSI hast du aktiviert ?

Schau mal ob in der registry SMBv1 aus ist
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Registrierungseintrag: SMB1
REG_DWORD: 0 = Deaktiviert

Veränder mal die rot markieren.

Mit freundlichen Grüßen
Nemesis

Warum dann nicht Cloud Only gehen? Der SBS ist ein enormes Sicherheitsrisiko.

Welche Policy genau vom BSI hast du aktiviert ?

Hi, "Normaler Schutzbedarf Domänenmitglied (ND) Computer",

teste ich gerne, sobald ich an die Kiste wieder ran kann..

Das macht mich etwas stutzig. Im AD auf dem 2ten DC scheint unter msdcs der SBS gänzlich zu fehlen!?
Wie das?

LG

Warum dann nicht Cloud Only gehen? Der SBS ist ein enormes Sicherheitsrisiko.

Der macht nichts mehr im Netz. Keine Ports frei nach außen etc.

Leider gleicht MS aber den Exchange vom SBS ab

Alles etwas doof eingerichtet/übernommen..

LG

Hi

Windows Firewall aus gemacht ?

Mit freundlichen Grüßen Nemesis

Zu Testzwecken ja.

LG + Danke

keiner mehr ein Ansatz?

LG

Moin,

Zitat von @141986:
mir ist gestern etwas ziemliches dummes passiert.

Nee, das war nicht dumm. Das war vollkommen bescheuert.

Ich habe das GPO Bündel vom BSI importiert und ausgerollt. Nunja, seither geht gar nichts mehr.

Also ich kenne nur die GPOs vom BSI, die zum Härten der Windows 10 Clients gedacht sind. Hast Du die allen Ernstes auf einen SBS11 (also Basis Windows XP) angewendet? Und dann wunderst Du Dich, das nichts mehr geht? Hast Du denn nicht vor der Anwendung auf einen DC mal reingeschaut, was denn da so alles abgeschaltet wird? Ich habe das getan: Du hast Deinem alten SBS11 so ziemlich alles abgeknippst, was er als DC so braucht.

Der DC kennt sich nun gar nicht mehr, geschweige das AD.
"RPC Server nicht verfügbar"

Works as designed. In den GPOs des BSI wird der RPC-Server so abgesichert, dass er mit den alten Techniken nicht mehr läuft. Hmmmmmmm, der SBS11 ist dafür aber zu alt.

Ich tippe ganz schwer, dass die GPOs einiges zerbröselt haben.

So ist es.

Es nützt nichts, wenn Du die GPOs einfach wieder entfernst. Wenn man mal ganz unten in den Einstellungen schaut, dann sieht man, dass auch deaktiviert wurde, dass die Richtlinien wieder rückgängig gemacht werden, wenn sie entfernt werden. Also, die einzige Möglichkeit ist, die Richtlinien wieder zu aktivieren und dann Einstellung für Einstellung das Gegenteil zu konfigurieren. In der Reihenfolge sollte dann die GPO vor der DDCP stehen, damit letztere wieder angewendet wird. Danach kannst Du die GPO des BSI wieder entfernen.

Viel Spaß dabei.

Erik

Nee, das war nicht dumm. Das war vollkommen bescheuert. face-wink

Das hast Du wunderschön gesagt :D

Windows 10 Clients gedacht sind

Sollte - nach Prüfung - auch nur die Win10 Clients betreffen. Meh..

Hast Du denn nicht vor der Anwendung auf einen DC mal reingeschaut, was denn da so alles abgeschaltet wird?

Plan war: Importieren, gucken was geht.
Passiert ist: Importiert, gucken was geht, bei aktiviert .. schon hatten es die ersten Clients. >:

Ich habe das getan: Du hast Deinem alten SBS11 so ziemlich alles abgeknippst, was er als DC so braucht.

Das befürchte ich eben auch. Kann ich denn die lokalen Sicherheitsrichtlinien "zurücksetzen"? Habe da was gefunden aber brachte im Prinzip null Erfolg.

Ich schaue mal, ob ich das Backup von der Möhre gebootet bekomme um da etwas abzuschauen.

Oh man, .. >:

LG + Danke für dein Feedback.

Moin,

Zitat von @141986:

Nee, das war nicht dumm. Das war vollkommen bescheuert. face-wink

Das hast Du wunderschön gesagt :D

hehehehe

Windows 10 Clients gedacht sind

Sollte - nach Prüfung - auch nur die Win10 Clients betreffen. Meh..

Ja, aber auch die werden dann mit dem SBS nicht mehr richtig zusammenarbeiten. Das fängt ja schon mit SMB1 an.

Hast Du denn nicht vor der Anwendung auf einen DC mal reingeschaut, was denn da so alles abgeschaltet wird?

Plan war: Importieren, gucken was geht.
Passiert ist: Importiert, gucken was geht, bei aktiviert .. schon hatten es die ersten Clients. >:

Es ist zu heiß für sowas.

Ich habe das getan: Du hast Deinem alten SBS11 so ziemlich alles abgeknippst, was er als DC so braucht.

Das befürchte ich eben auch. Kann ich denn die lokalen Sicherheitsrichtlinien "zurücksetzen"? Habe da was gefunden aber brachte im Prinzip null Erfolg.

Die Tools, die es da gibt setzen immer nur die DDP und DDCP bzw. die lokalen Standardeinstellungen zurück. Du musst aber die importierten Richtlinien zurückkonfigurieren.

Ich schaue mal, ob ich das Backup von der Möhre gebootet bekomme um da etwas abzuschauen.

Da wirst Du auch nicht viel sehen. Im Backup sind die Einstellungen ja alle nicht konfiguriert.

Liebe Grüße

Erik

P.S.: Bei der Hitze lass es und setzte Dich mit einem kühlen Bier in den Park.

Ja, aber auch die werden dann mit dem SBS nicht mehr richtig zusammenarbeiten. Das fängt ja schon mit SMB1 an.

Da hatte ich bereits Freigaben gesetzt, dass unsere Maschinen ans Netz dürfen. Das ging mal. :D

Es ist zu heiß für sowas. face-wink

Fml, Du sagst es.. :/

importierten Richtlinien zurückkonfigurieren.

Ich komme nur noch auf die lokalen Sicherheitsrichtlinien - hast Du vielleicht eine Idee, wie ich das sinnig umsetzen kann?

Liebe Grüße

Liebe Grüße und vielen Dank!

P.S.: Bei der Hitze lass es und setzte Dich mit einem kühlen Bier in den Park.

No way: Chefin motzt und mein innrer Monk ist super genervt und will das wieder zum rennen bekommen.

SUCKS hard! >.<

Danke Euch!

Habe mal die importierte GPO auseinander genommen.

Folgendes wird/wurde wohl geändert:

MACHINE\System\CurrentControlSet\Services\LDAP\LDAPClientIntegrity=4,1
MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature=4,1
MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature=4,1
MACHINE\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnablePlainTextPassword=4,0
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\RestrictNullSessAccess=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionShares=7,
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\EnableForcedLogOff=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\AutoDisconnect=4,15
MACHINE\System\CurrentControlSet\Control\Session Manager\ProtectionMode=4,1
MACHINE\System\CurrentControlSet\Control\Session Manager\Kernel\ObCaseInsensitive=4,1
MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedPaths\Machine=7,System\CurrentControlSet\Control\Print\Printers,System\CurrentControlSet\Services\Eventlog,Software\Microsoft\OLAP Server,Software\Microsoft\Windows NT\CurrentVersion\Print,Software\Microsoft\Windows NT\CurrentVersion\Windows,System\CurrentControlSet\Control\ContentIndex,System\CurrentControlSet\Control\Terminal Server,System\CurrentControlSet\Control\Terminal Server\UserConfig,System\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration,Software\Microsoft\Windows NT\CurrentVersion\Perflib,System\CurrentControlSet\Services\SysmonLog
MACHINE\System\CurrentControlSet\Control\SecurePipeServers\Winreg\AllowedExactPaths\Machine=7,System\CurrentControlSet\Control\ProductOptions,System\CurrentControlSet\Control\Server Applications,Software\Microsoft\Windows NT\CurrentVersion
MACHINE\System\CurrentControlSet\Control\Lsa\UseMachineId=4,1
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictRemoteSAM=1,"O:BAG:BAD:(A;;RC;;;BA)"  
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM=4,1
MACHINE\System\CurrentControlSet\Control\Lsa\RestrictAnonymous=4,1
MACHINE\System\CurrentControlSet\Control\Lsa\pku2u\AllowOnlineID=4,0
MACHINE\System\CurrentControlSet\Control\Lsa\NoLMHash=4,1
MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0\NTLMMinServerSec=4,537395200
MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0\NTLMMinClientSec=4,537395200
MACHINE\System\CurrentControlSet\Control\Lsa\MSV1_0\allownullsessionfallback=4,0
MACHINE\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel=4,3
MACHINE\System\CurrentControlSet\Control\Lsa\LimitBlankPasswordUse=4,1
MACHINE\System\CurrentControlSet\Control\Lsa\EveryoneIncludesAnonymous=4,0
MACHINE\System\CurrentControlSet\Control\Lsa\DisableDomainCreds=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\PromptOnSecureDesktop=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\NoConnectedUser=4,3
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes=4,2147483640
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\InactivityTimeoutSecs=4,900
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\FilterAdministratorToken=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableVirtualization=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableSecureUIAPaths=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableInstallerDetection=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\DontDisplayLastUserName=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\DisableCAD=4,0
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorUser=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ConsentPromptBehaviorAdmin=4,2
MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\PasswordExpiryWarning=4,14
MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AllocateDASD=1,"2"  
MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\SignSecureChannel=4,1
MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey=4,1
MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal=4,1
MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\MaximumPasswordAge=4,30
MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange=4,0
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\SmbServerNameHardeningLevel=4,1
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\MaxDevicePasswordFailedAttempts=4,10
MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ScRemoveOption=1,"1"  
MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters\SealSecureChannel=4,1
MACHINE\System\CurrentControlSet\Services\LanManServer\Parameters\NullSessionPipes=7,
MACHINE\System\CurrentControlSet\Control\Lsa\ForceGuest=4,0
MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableUIADesktopToggle=4,0

Soooweit so gut aber was sind hier die default werte?

LG

..Habe ein Backup der Registry mal drüber gebügelt. Viel mehr kaputt machen kann ich ja nun nicht mehr.

Karre bootet, AD geht auf, Anmeldung läuft, Shares sind wieder da!

Irre!

Mal schauen, wann das ganze Konstrukt zerbricht. Direkt ein Termin fürs WE um das Ding final zu killen. Niemehr SBS!

LG und vielen Dank für euren Support.

PS: Ich lasse den Thread mal noch als Ungelöst.

..einen wunderschönen guten Morgen.

Ich konnte das OpenAir gestern doch noch genießen - trotz Regen aber hey, immerhin können die Leute wieder arbeiten.

Nun kommt das dicke ABER:
Der SBS weiß immer noch nicht, dass er DC ist(?)

C:\Windows\system32>nltest /dclist:firma
Liste der Domänencontroller (DCs) in Domäne 'firma' von '\\AMR-DC02' abrufen.  
       SBS11.firma.local [PDC]  [DS] Standort: Default-First-Site-Name
    AMR-DC02.firma.local        [DS] Standort: Default-First-Site-Name
Der Befehl wurde ausgeführt.

Sag Ihm aber, dass er noch so gelistet ist.

Nach einigen Tests steht im DNS nun auch der SBS wieder als DC drin.
ABER: das Netlogon + sysvol fehlt gänzlich auf dem SBS. Der Ordner unter /windows/ ist vorhanden (SYSVOL_DFSR)
Hier waren gar keine Daten mehr drin -> Aus dem Backup wieder hergestellt und seither gehen auch die GPOs wieder auf und gpupdate verläuft soweit fehlerfrei auf den Clients.

dcdiag meckert allerdings ziemlich rum:

      Starting test: Advertising

         Achtung: Bei dem Versuch, SBS11 zu erreichen, wurden von DsGetDcName

         Informationen fr \\AMR-DC02.firma.local zurckgegeben.

         DER SERVER REAGIERT NICHT oder GILT ALS UNGEEIGNET.

Replikation vom AD funktioniert problemlos.

[SBS11] Auf dem Dom„nencontroller wurden keine sicherheitsbedingten

         Replikationsfehler gefunden

Stoße ich den RepliDienst direkt an erscheint folgendes:

Der Ordner "SYSVOL_DFSR" in "C:\Windows\SYSVOL_DFSR" konnte von DFSR nicht erstellt werden. Dies ist möglicherweise auf  mangelnden Speicherplatz zurückzuführen.   


Zusätzliche Informationen: 
Ordner "Sysvol DFSR": C:\Windows\SYSVOL_DFSR   
Fehler: 2 (Das System kann die angegebene Datei nicht finden.)

Natürlich ist noch mehr als genügend Platz auf der Partition frei.
Der Ordner besteht auch bereits? Löschen lässt er sich natürlich nicht weil wegen im Zugriff.

Habe nun mal wieder eine Dinge getestet aber bekomme das Ding einfach nicht mehr freigegeben.

Hat hier noch wer 'ne Idee? Gerne auch als Workaround, hauptsache die Möhre läuft erstmal.
SMB1 + Maschinen verschiebe iche rstmal auf später, die Jungs können mit USB Sticks arbeiten bis dahin.

Freue mich auf Feedback.

Beste Grüße

So, ich glaube, ich habe wieder einen halbwegs brauchbaren Untersatz bis zum WE.

Ich habe den DFSR Dienst beendet, den Ordner SYSVOL_DFSR umbenannt.
Klappte aber immer noch nicht bzw. nur teilweise. Ordner wurde angelegt, Rest fehlte.

1+1 zusammengezählt => DFSR geht aus dem SYSVOL Ordner hervor - klar, wenn der nicht da ist..
Also aus dem Backup den SYSVOL Ordner in %windir% geklatscht, Dienst gestartet, etwas gewartet und siehe da, das Ding ist glücklich und hat sysvol + netlogon wieder freigegeben.

Eventvwr sieht soweit schon etwas grüner aus aber ja, bisher traue ich mich noch nicht, den Server neuzustarten.

Der Domänencontroller "SBS11" wurde erfolgreich in den Status "ENTFERNT" migriert. Die SYSVOL-Freigabe in "C:\Windows\sysvol" wird von NTFRS nicht mehr repliziert. Derzeit wird der Ordner "SYSVOL_DFSR" in "C:\Windows\SYSVOL_DFSR" von DFRS repliziert. Der NTFRS-Dienst ist auf diesem Domänencontroller deaktiviert.    
 
Die DFSR-Migration für den Domänencontroller "SBS11" ist nun abgeschlossen.   
 
Zusätzliche Informationen: 
Ordner "Sysvol NTFRS": C:\Windows\sysvol   
Ordner "Sysvol DFSR": C:\Windows\SYSVOL_DFSR   
Domänencontroller: SBS11

Wenn ich noch etwas finde was nicht passt oder angepasst werden muss, würde ich hier weiter spamen.

Danke an administrator.de und deren Supporter ♥

Viele Grüße

Hallo zusammen,

der SBS ist nun final Geschichte.

Migration auf neuen Exchange inkl. Hybridkonfig
Migration UserShares + weitere Daten
Migration DHCP (nun im Failovermode)
Migration DNS

Die Migration/Umstellung war relativ umständlich, hat aber schlussendlich problemlos geklappt.
Sollte wer Fragen oder ein wenig Support wünschen, einfach anfragen.

Schema & Forrest nun auf 2016, alles doppelt vorhanden (DNS, DHCP, AD, FS).
Unsere SMB1 Maschinen hängen nun an einem Sambashare und alles wuppt wie gewünscht. LM & NTLM sind gekillt und vernünftig eingerichtet. LDAPS etc klappt ebenso.

Nochmals Danke für euch!

Thema gegessen, geschlossen, vergraben und zubetoniert.

Grüße

Nun kann endlich wieder vernünftig geschlafen werden ohne Bauchschmerzen.

gelöst Frage Microsoft Windows Server

Heiß diskutiert