NilsK

Moin, was sollen denn in dem Fall die "Adminrechte" sein? Gruß, Nils

Moin, %[ ]% geht nicht? Sonst könnte man versuchen: ... WHERE CHARINDEX(' ', FELDNAME) > 0 Gruß, Nils

Moin, genauer gesagt: Es verbessert die Affinität und baut sie erheblich aus. Danke für den Hinweis! Gruß, Nils

Moin, das passt aber nicht zusammen. Oben sagst du, sämtliche Tools arbeiten nicht. Tatsächlich hast du aber Daten im AD geändert. Was denn nun? Gruß, Nils

Moin, schätze, diese Frage wird dir am Ende nur der Entwickler der Applikation und der Datenbanklogik beantworten können. Gruß, Nils

Moin, und was genau ist deine Frage? Gruß, Nils

Moin, ... also doch. Danke für die Rückmeldung, und schön, dass es jetzt geklappt hat. Ja, das AD ist in seinen Strukturen etwas unübersichtlich. Dass einige Daten zu den DCs in der Domänenpartition gespeichert sind und andere in der Konfigurationspartition, macht solche Vorgänge nicht einfacher. Gruß, Nils

Moin, Ich kann dir gerade nicht folgen. Wenn du die AD-Verwaltungstools nicht starten kannst, wie hast du dann die DCs aus dem AD entfernt? Gruß, Nils

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