NilsK

Moin, Für mich ist da zu viel "könnte" und "sollte" im Spiel, als dass ich dem Konstrukt trauen würde. Hat du nicht vielleicht einen Server, bei dem die Dinge einfach funktionieren? Und wozu Storage Spaces bei einem Einzelserver? Gruß, Nils

Moin, *seufz* und, sind die Berechtigungen so, dass der Account, mit dem du arbeitest, das Objekt löschen können müsste? Oder ist es denkbar, dass tatsächlich eine Berechtigung fehlt? Gruß, Nils

Moin, typischerweise ist das darauf zurückzuführen, dass die DNS-Auflösung nicht funktioniert. Die FSMO-Rollen sind an dieser Stelle erst mal egal. Wenn die Testumgebung intensiver genutzt werden soll, ist es aber ratsam, alle anderen DCs aus der Konfig zu entfernen, wenn diese nicht auch dupliziert wurden. Allgemein rate ich aber von solchen Aufbauten ab. Echte DCs zu klonen, ist aus Sicherheitssicht immer heikel, und abgesehen davon, wäre man nicht der erste, der eine Änderung im Labor macht und hinterher feststellt, dass er das Original erwischt hat, weil es ja ausgesprochen identisch aussieht. Gruß, Nils

Moin, wie lange soll das denn jetzt noch so weitergehen? Willst du nun die Berechtigungen mit dsacls noch prüfen oder nicht? Gruß, Nils

Moin, Ja, das mit dem Text wäre schon prima ... Es scheint also tatsächlich an Berechtigungen zu liegen. Dann jetzt also mal dsacls. Gruß, Nils

Moin, oder dsacls fragen. Das Flag ist in Wirklichkeit ein "Deny". dsacls "CN=Dein-DC,OU=Domain Controllers,DC=sub,DC=dom,DC=tld" Man könnte auch erst gucken, ob es per ntdsutil geht. Falls da auch eine Verweigerung kommt (und kein Fehler wegen falscher Syntax), dann liegt es tatsächlich an Berechtigungen. Gruß, Nils

Moin, gut, und wenn du ntdsutil richtig ausführst, was passiert dann? Gruß, Nils

Moin, wenn ich den Screenshot richtig interpretiere, hast du die (sehr krude) ntdsutil-Syntax nicht richtig eingegeben. Das ist auch nicht ganz ohne. Die Logik ist so: Erst verbindest du dich mit einem DC, um überhaupt was tun zu können (laufender DC). Dann wählst du aus, mit welchem Objekt du etwas tun willst (hier also der nicht mehr vorhandene DC). Das erfordert mehrere Schritte, um das Objekt zu "selektieren". Und ganz am Ende sagst du, was geschehen soll: "remove selected server". Such noch mal in der KB, da gibt es Artikel, die das Schritt für Schritt auflisten. Ich hab grad keine Demoumgebung, die ich kaputtmachen kann, um das durchzuspielen. Gruß, Nils

Moin, das Flag könnte auch auf dem DC-Konto gesetzt sein. Wäre unüblich, aber denkbar. Was hast du denn genau schon versucht? Was sagt denn ntdsutil, wenn "es" nicht geht? Gruß, Nils

Moin, dann wäre jetzt interessant zu wissen, was sich denn zwischen "heute morgen" und vorher geändert hat. Falls du damit nicht bald zu einem Erfolg kommst, würde ich die VMs kopieren (die virtuellen Festplatten) und auf einem ganz neu installierten Host neu einrichten. Das könnte man testweise auch schon jetzt tun, während man weiter sucht. Gruß, Nils

Moin, hm ... es gab da in der Frühphase von Server 2016 mal einen Bug, der sowas verursachte. Müsste allerdings längst gefixt sein. Ich meine, wir hatten das auch hier im Board, du kannst ja mal versuchen, ob du es über die Suche findest. An Details erinnere ich mich leider nicht mehr. Details zu Fehlermeldungen hast du jetzt immer noch nicht genannt. Fundstelle: Gruß, Nils

Moin, also benutzt ihr an beiden Standorten dieselben IP-Subnets? Spannend ... ist das denn ein zusammenhängendes LAN? Ich kenne solche Konstrukte nur als "macht ständig Probleme" ... OK, in dem Fall (und wenn das so bleiben soll) wäre das was anderes, technisch betrachtet. Ich bin kein Freund von DHCP Failover, weil meiner Erfahrung nach in den meisten Fällen Split Scope völlig ausreicht. Ob das Failover "kreuzweise" geht, kann ich daher nicht sagen. Gruß, Nils

Moin, die Informationen sind nicht besonders umfassend. Kannst du bitte noch mal genau beschreiben, was du tust, was dann passiert und welche Meldungen genau erscheinen? Es ist auch nicht ganz klar, was du mit "einen 2016 Hyper-v (Standallone)" meinst. Ein Schuss ins Blaue: Fehlen dem Userkonto, mit dem du angemeldet bist, evtl. die Rechte? Gruß, Nils

Moin, wie willst du denn DHCP über den Standort-Router kriegen? Das ist im Protokoll nicht vorgesehen. Ich verstehe auch den Ansatz nicht ganz. Warum überhaupt ein standortübergreifendes DHCP? In den meisten Fällen reicht es völlig aus, pro Standort ein Split-Scope-Konzept zu bauen. Gruß, Nils

Moin, Woher sollen wir das wissen? Wir kennen die Anforderungen deines Projektes ja nicht. Gruß, Nils

Moin, rollstu hoch ... Ah, gut. Auf die Idee wäre ich jetzt auch nicht gekommen ... aber gut zu wissen. Gruß, Nils

Moin, man kann das temporär mal versuchen, aber generell empfiehlt man das schon genau so (über Kreuz), weil es einige typische Probleme vermeidet. Laut Eingangspost löst nslookup korrekt auf, daher würde ich (ausnahmsweise) das Problem eher nicht bei DNS suchen - sofern nslookup korrekt und sinnvoll getestet wurde (beide Server ausdrücklich abgefragt?). Ergänzend würde ich dann auch noch einen ping auf den Domänennamen sowie einen ping auf jeden der DC-Namen versuchen, das auch wieder auf beiden Servern. Ping löst anders auf als nslookup und ist deshalb eigentlich zur Fehlersuche besser geeignet. Aber wenn wir schon dabei sind - dann auch den DNS-Cache löschen (ipconfig /flushdns). Gruß, Nils

Moin, die Subnet-Frage führt doch hier in die Irre. Bei nur einem Standort kann es keine Subnet-Fehlzuordnung geben, egal was man da einträgt. Gruß, Nils

Moin, ich weiß nicht, ob das heute noch funktioniert, aber: [Wie kann ich Active Directory von einem DC gewaltsam entfernen? | faq-o-matic.net] https://www.faq-o-matic.net/2003/01/19/wie-kann-ich-active-directory-von-einem-dc-gewaltsam-entfernen/ Bevor ich das täte, installierte ich aber zunächst einen weiteren neuen DC und prüfte, ob mit diesem die Kommunikation ordentlich läuft. Gruß, Nils

Moin, schaust du nur in den AD-Logs? Oder auch in den anderen wichtigen? Bei dem geschilderten Fehlerbild kann ich mir nicht recht vorstellen, dass nix sichtbar sein sollte. Gruß, Nils

Moin, gibt es denn wenigstens in den Fehlern, die dir angezeigt werden, Fehlernummern? Hast du die Eventlogs auf beiden Servern geprüft? Gibt es auf einem oder beiden Dienste, die gestartet sein sollten, aber nicht laufen? Gruß, Nils

Moin, was sagt denn das Eventlog dazu? Gruß, Nils

Moin, na, das ist dann aber schon ausschließlich eine Frage der Perspektive. Pauschal ist so eine Aussage schon seit 20 Jahren falsch. Gruß, Nils

Moin, das ist nicht korrekt. Microsoft empfiehlt ein Minimum von 128 GB, weil Exchange 2019 primär für sehr große Umgebungen gedacht ist (die anderen sollen eher MS365 nehmen). Es gibt aber eben keine Support-Untergrenze. Nach allem, was man hört, läuft auch Exchange 2019 problemlos mit 32 GB. Es schaltet einige Optimierungen erst ab 128 GB ein, aber die braucht man eben auch nur in so großen Umgebungen, in kleineren nicht. "sollte" oder "muss"? Sprich: Geht es auch, wenn der Schema-Master in einer anderen Site ist? (Ich weiß das nicht, weil ich schon länger nicht mehr so eng mit Exchange bin.) Wenn ja (was ich vermute): Stell halt sicher, dass das VPN zuverlässig ist. Oder, wenn es dir lieber ist, stell den Schema-Master eben in die Site mit Exchange. Technisch ist das auch OK, wichtig ist nur, dass du es weißt und dokumentierst. Gerade in so kleinen Umgebungen schafft man sich sonst unnötige Probleme, wenn Dinge "individuell" konfiguriert sind. Und ja, auch ich würde für 15 User heute keinen Exchange mehr betreiben. Es gibt ja nicht nur MS365. Gruß, Nils

Moin, das habe ich nicht verstanden, vor allem sehe ich die Verbindung zu der Frage nicht. Gruß, Nils