NilsK

Moin, ach je ... glaubst du wirklich, dass du auf der Ebene optimieren musst? Da VHDX-Dateien typischerweise groß sind, empfiehlt man auch große Clustersizes auf den physischen Disks. Wenn man es denn ausdrücklich konfigurieren möchte. Gruß, Nils

Moin, der Link, den Norbert gepostet hatte, ging gar nicht auf einen konkreten Artikel. Es kann also gut sein, dass es dort gar keinen Artikel gibt, der das beschrieb. Da in folgendem Artikel von Microsoft die Domänenmitgliedschaft ausdrücklich vorausgesetzt wird, würde ich davon ausgehen, dass es ohne nicht geht. https://docs.microsoft.com/en-us/windows-server/virtualization/hyper-v/deploy/set-up-hosts-for-live-migration-without-failover-clustering Gruß, Nils

Moin, nur mal so geschossen: die DCs sind virtuell und es gibt Probleme mit den NICs auf den Hosts (Treiber, Konfig) die DCs sind physisch, dort NIC der CRL Distribution Point, der im DC-Zertifikat angegeben ist, ist nicht erreichbar das Zertifikat hat eine irre kurze Laufzeit DC1 und DC2 haben nicht den Private Key für ihre Zertifikate (durch den Austausch) Besteht das Problem erst seit dem DC-Wechsel? Ist der "hängende" DC auch bei anderen Diensten/Verbindungen eingeeschränkt? Zeigt sich während eines Hängers lokal auf dem DC eine Besonderheit? Gruß, Nils

Moin, ach je ... aber bitte, bitte: Geh jetzt nicht davon aus, dass du nun den Gottmodus kennst und mit allen Wassern gewaschen bist. Die Anleitung ist nur für Testumgebungen geeignet. Sie ignoriert, dass es noch an vielen weiteren Stellen Exchange-Reste gibt: Berechtigungen, Attributdaten in AD-Objekten ... Nur falls beim Lesen dieses Threads jemand auf Ideen kommt: Das ist nicht geeignet für Produktionsumgebungen. Gruß, Nils

Moin, "das ist so'n Männderding, schätze ich mal." (Unbekannte Quelle, zuletzt gehört in "Das perfekte Dinner") Gruß, Nils

Moin, ohne mehr über das Netzwerk zu wissen, kann man da kaum was dazu sagen. Typischerweise kommen z.B. SMB-Anforderungen "aus dem Internet" ja gar nicht über die Perimeter-Firewall. Dann wäre es zwar schlechter Stil, sowas intern von "beliebigen" Netzwerken aus zuzulassen, aber gleichzeitig auch wirkungslos. Ich warne da vor Ferndiagnosen. Wenn, dann schaut man sich das in Ruhe an und berücksichtigt alle wichtigen Umstände. Das geschieht dann aber nicht in einem Forum, sondern ist ein umfangreicherer Auftrag. Gruß, Nils

Moin, dann ist jetzt der Moment, um zu Kreuze zu kriechen und zu sagen: Ich hab's kaputtgespielt. In einer Produktionsumgebung würde man nicht mal so aufs Geratewohl mit ADSI Edit im AD rumlöschen. Gruß, Nils

Moin, hm, ja ... da bin ich von der alten Schule: im Straßenverkehr niemals Kopfhörer. Danke vielmals, sie ist seit gut 18 Jahren treue Begleiterin. Wobei ich schon direkt nach dem Kauf bemerkt hatte, dass das eigentlich pfiffige Feature "Anzeige der Kalenderwoche" unnütz, weil nicht mal mit Anfang 30 ablesbar ist. Gruß, Nils

Moin, wobei sich genau dieses Szenario am wenigsten für mich erschließt. Hat man beim Musikhören wirklich das Handy "nicht am Mann"? Nur eine mechanische Uhr ist eine Uhr. https://www.watch.de/archive/archive_germany/muhle-glashutte-business-timer-2000-mit-wochenanze-40mm-uvp-2515-neu.html Gruß, Nils

Moin, bei so einer kleinen Umgebung würde ich auch eher das Gesamtkonzept betrachten als einen einzelnen DC zu planen. Der Vorschlag von Norbert (aus Bremen) ist zwar etwas flapsig formuliert, aber ein guter Ausgangspunkt. Innerhalb einer Virtualisierungsumgebung wäre ein DC eher eins der kleinsten Systeme. 1 vCPU und 1 GB RAM würden für die Domänengröße dicke ausreichen. Performance im Sinne von SSD braucht ein DC auch in Enterprise-Umgebungen nicht. Gruß, Nils

Moin, kann vorkommen - aber ernst gemeinter Rat: Sich etwas Ruhe lassen und Dinge sorgfältig machen hilft in solchen Situationen ungemein. Auch wenn man bei anderen nach Hilfe fragt. Gruß, Nils

Moin, lieber Forrest, könntest du dich etwas mehr bemühen, deine Posts verständlich zu formulieren? Es ist kaum zu erraten, was du meinen könntest. Danke. Gruß, Nils

Moin, das meint: an der Stelle, wo du im ESXi den Zeitserver angibst, trägst du den DNS-Namen oder die IP-Adressen eines DCs an. Falls man mehrere angeben kann, dann eben mehrere oder alle DCs. Wobei es noch besser ist, einfach nur den DNS-Namen der Domäne anzugeben, denn dann antwortet immer einer der aktuellen DCs. Gruß, Nils

Moin, umgekehrt wird ein Schuh draus: dein ESXi-Host sollte sich die Zeit bei der Domäne holen (einfach dort den DNS-Namen der Domäne als Zeitserver eintragen). Die Domänen-Clients, falls richtig konfiguriert, holen sich ihre Zeit sowieso von dort. Gruß, Nils

Moin, das habe ich ja schon ewig nicht mehr gehört. Admin an einer Uni? Gruß, Nils PS. wird vielleicht jetzt off-topic ...

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, 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