NilsK

Moin,

also, ich habe Qwant verwendet.

Fun Fact: Bing listet meinen Treffer ebenso an erster Stelle. Googles Ergebnisse hingegen sind wertlos.

Gruß, Nils

Moin,

öhm ... also, mir sagt eine Webrecherche, dass Leute es mit Greenshot hinbekommen haben. Was ist denn bei deiner Recherche rausgekommen?

Gruß, Nils

Moin,

vor 28 Minuten schrieb Nobbyaushb:

exportieren

der Export ist seit 2012 R2 nicht mehr nötig. Hyper-V kann einen Import einfach auf Basis einer Dateikopie vornehmen. Der Menüpunkt "Export" ist nur dann interessant, wenn sich die Dateien der VM über mehrere Ordner verteilen oder wenn man eine laufende VM exportieren möchte.

Wenn man es richtig macht (VM-Daten inkl. der Konfig-Dateien an der endgültigen Stelle ablegen, beim Import "direkt registrieren" wählen), geht das auch mit einem DC und einem Exchange-Server. Man kann es aber auch falsch machen, daher wäre die Live Migration deutlich besser, siehe Jans Antwort.

Gruß, Nils

Moin,

Teams.

Gruß, Nils

Moin,

Danke für die Rückmeldung.

Gruß, Nils

Moin,

ja, genau. Ich meine neu installieren. Was würde denn da jetzt viel Aufwand bedeuten? Du könntest ja, wenn jetzt schon Arbeit in die Domäne geflossen ist, auch einfach einen weiteren DC mit GUI installieren und den Core-DC erst mal weiterlaufen lassen.

Mit DNS meine ich: Du sagst irgendwas von Forwarder usw., ohne Details zu nennen. Hinter solchen Aussagen verbergen sich manchmal komplexe Konstrukte, die dazu führen, dass die DNS-Auflösung zwar theoretisch gehen müsste ("ganz bestimmt!"), aber eben auch nur theoretisch. DNS muss ordentlich laufen, von beiden Seiten, sonst wird das mit Trust und Migration nichts werden.

Gruß, Nils

Moin,

tu dir einen Gefallen und installiere den neuen DC mit GUI, nicht als Core-Variante. Die Core-Installation wird allgemein weit überschätzt. Sie hat nahezu keinen Sicherheitsvorteil, dafür aber enorm viele Nachteile, sobald es ans Troubleshooting geht.

Ansonsten ist aus den Informationen jetzt nicht zu erkennen, wo genau der Fehler liegt. Wenn es machbar ist, installiere mit GUI neu, richte die Domäne neu ein und dann sehen wir weiter.

Die Anmerkungen zu DNS verstehe ich nicht recht. Da DNS aber kritisch für das AD ist (und möglicherweise hier auch die Ursache der Probleme), solltest du da so wenige "Besonderheiten" drin haben wie möglich.

Verstehe ich richtig, dass die Domänen an unterschiedlichen Standorten sind? Falls ja - spräche etwas dagegen, die neue Domäne zunächst am "alten" Standort einzurichten, bis alles läuft (auch mit dem Trust) und erst später die Standorte zu trennen?

Gruß, Nils

Moin,

ähm ... hat denn jemand die Frage des TO verstanden? Mir ist schleierhaft, was er wissen möchte. @fynn.pf, kannst du das bitte noch mal genauer beschreiben?

Gruß, Nils

Moin,

Fehler dieser Art liegen immer an DNS. Immer.

Gruß, Nils

Moin,

mal von der anderen Seite her gefragt ... was ist denn der Grund für das Update? Immerhin kostet die Lizenz nicht unerheblich im Vergleich zu dem Typ Hardware - warum dann die alte Hardware mit all ihren Ausfallrisiken mit einem neuen OS nutzen?

Gruß, Nils

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,

vor 4 Minuten schrieb NorbertFe:

Kann man sich ja mal durchklicken per Sites and Services oder adsiedit.

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