NilsK

Moin, wie auch im Board schon diskutiert, ist das auch keine Migration, sondern eine einfache Aktualisierung. Das Video finde ich übrigens nicht besonders. Es benutzt falsche Begriffe, und wer seiner Demoumgebung IP-Adressen aus dem 1.x.y.z-Netz gibt, hat irgendwie den Schuss nicht gehört. Außerdem hilft die AD-Replikation natürlich nicht dabei, die Latenzen der FRS-Replikation zu umgehen ... Gruß, Nils

Moin, hier noch die Übersicht über Migrationsmethoden für Hyper-V. [Hyper-V von älteren Versionen nach Windows Server 2016 migrieren | faq-o-matic.net] http://www.faq-o-matic.net/2016/12/19/hyper-v-von-lteren-versionen-nach-windows-server-2016-migrieren/ Gruß, Nils

Moin, naja, wenn wir auf einer so pauschalen Ebene sind, rate ich auch davon ab. :p Man kann da eine Menge machen, aber man kommt schnell an eine Stelle, ab der es sehr aufwändig wird. Und man bewegt sich schnell aus einer vom Hersteller supporteten Konfiguration hinaus. Kommt dann noch Exchange ins Spiel, wird es sogar unbeherrschbar. Aber vielleicht sollten wir, bevor wir solche Dinge überhaupt in den Raum werfen, dann doch noch mal über die Anforderungen sprechen ... Gruß, Nils

Moin, mutig. Dann hoffen wir mal, dass auch das noch läuft, was man nicht auf den ersten Blick sieht. Gruß, Nils

Moin, da er die ADDS ja anscheinend vor dem Exchange installiert hat, würde ich zumindest vermuten, dass man ihm bei MS einen Weg weist. Das Deinstallieren hingegen wäre sehr wahrscheinlich ein Supportausschluss. Tatsächlich ist der Hinweis in den Installationsvoraussetzungen durchaus missverständlich für jemanden, der das nicht ständig macht. Ich wäre von selbst nicht drauf gekommen, aber angesichts des Threads hier denke ich schon, dass das Missverständnis naheliegt. Ärgerlich für den TO. Gruß, Nils

Moin, also, wie gesagt: Ich vermute, dass das Problem in der Installation der ADDS-Binaries liegt. Bevor du die nun aber wieder deinstallierst: Es kann sein, dass du dich damit im unsupporteten Bereich befindest. Sofern sich hier niemand mit einem anderen konkreten Hinweis meldet, würde ich an deiner Stelle den Microsoft-Support einschalten. Gruß, Nils

Moin, bei der Installation hast du was missverstanden. Auf dem Exchange-Server sollst du nicht die AD-Domänendienste installieren, sondern nur die Verwaltungsprogramme (RSAT-ADDS). Ich würde nicht ausschließen, dass diese Fehlinstallation das Problem verursacht. Von welchem Rechner kommen die beiden oben genannten Fehlermeldungen? Gruß, Nils

Moin, oder anders gefragt: Was möchtest du denn erreichen? Wenn es darum geht, dass die Clients an dem betreffenden Standort den DC eines bestimmten anderen Standorts vorziehen sollen, dann ordne das Subnet dem "Ziel-Standort" zu. Nur wenn der DC dort nicht antwortet, nehmen die Clients einen anderen. Gruß, Nils

Moin, was genau meinst du damit? Der Fehlermeldung nach kann sich der Exchange-Server keiner Site zuordnen. Hat er eine IP-Adresse, die innerhalb des definiertren Subnets für die Site liegt? Gruß, Nils

Moin, welche Meldung kommt genau? Normalerweise erscheint doch bei diesen Situationen ein UAC-Prompt, der es ermöglicht, die Aktion mit Adminrechten auszuführen. Geschieht das nicht? Hilft es, ein CMD ausdrücklich als Admin zu starten und von dort aus die Dateien bzw. Ordner zu löschen? Gruß, Nils

Moin, gerade gefunden: https://blogs.technet.microsoft.com/ash/2016/08/13/changes-to-convenience-pin-and-thus-windows-hello-behaviour-in-windows-10-version-1607/ Gruß, Nils

Moin, soweit ich weiß, sollte auch das "normale" Hello mit AD-Konten funktionieren. Der Vorteil von Hello for Business ist vort allem die zertifikatsbasierte Anmeldung, die das normale Hello nicht macht. Ansonsten aber leider keine praktische Erfahrung - als ich das vor einigen Monaten mit meinem Notebook probiert habe, war der Fingerabdrucksensor irgendwie nicht genau genug, weswegen ich es gleich wieder abgeschaltet habe. Gruß, Nils

Moin, probier es aus. Mit dem AD-Benutzer und -Computer siehst du ja, ob der Filter das macht, was du brauchst. Aber Vorsicht: Das sind alles Textfelder, keine numerischen Werte. Du kannst bei Bedarf vorne und hinten Sternchen als Wildcard angeben. Gruß, Nils

Moin, wenn die Applikationen auf dem Host zur Verwaltung der Virtualisierungsumgebung dienen, braucht der Host keine Lizenz. Das ist nicht hart definiert, aber eindeutig genug: Lokales Backup, Monitoring-Agent, Tools wie 5Nine, lokaler Virenscanner usw.: Verwaltung der Umgebung. Office, Druckdienste, Dateifreigaben: Allgemeine Nutzung, damit lizenzpflichtig. Gruß, Nils

Moin, das sind die Display Names (genauer: adminDisplayName). Zur Ansprache braucht man die LDAP-Syntax (genauer: lDAPDisplayName), die Microsoft schlauerweise abweichend gesetzt hat. Mein Beispiel ist korrekt und funktioniert. [Active Directory: LDAP-Feldnamen | faq-o-matic.net] http://www.faq-o-matic.net/2002/09/21/active-directory-ldap-feldnamen/ [LDAP-Grundlagen für Active Directory | faq-o-matic.net] http://www.faq-o-matic.net/2008/01/13/ldap-grundlagen-fuer-active-directory/ Um die LDAP-Filter erst mal ohne PowerShell auszuprobieren, eignet sich die AD-Suche im ADUC, dort dann die "Benutzerdefinierte Suche" und "Erweitert". Gruß, Nils

Moin, für das mit den "verwaisten" Computern gibt es eine fertige Lösung ohne PowerShell: http://www.joeware.net/freetools/tools/oldcmp/index.htm Die andere Sache mit dem Filter ließe sich über den Schalter -LDAPFilter erledigen. Beispiel aus der Onlinehilfe: Get-ADComputer -LDAPFilter "(name=*laptop*)" -SearchBase "CN=Computers,DC=Fabrikam,DC=com" Der LDAP-Filter wäre dann etwas wie (operatingSystem=Windows 7*). Gruß, Nils

Moin, Schattenkopien? Gruß, Nils

Moin, der Zeitrahmen ist dann schon OK. Dass es keine Anforderungen gibt, ist in der IT typisch, aber nicht OK. Daher mein Rat: Arbeite dich in die logischen Hintergründe des Themas ein und entwickle daraus Fragen, die zur Definition von Anforderungen dienen. Das ist dann mindestens ein Thema auf Ebene der IT-Leitung, je nach Unternehmen durchaus auch ein Thema für die Leitungsebene von Fachabteilungen oder sogar dem C-Level. Dort natürlich nicht im technischen Detail, aber in den Anforderungs- und Nutzungsszenarien sowie in den organisatorischen Konsequenzen. Erst wenn das steht, kann man ein PKI-Design sinnvoll bauen. Das muss trotzdem keine Raketenwissenschaft sein, aber wie gesagt: Man baut dort sehr leicht etwas, das dann nicht passt. Besorg dir das Komar-Buch, das gibt es nur noch antiquarisch oder als E-Book, aber insbesondere die Hintergründe sind darin hervorragend dargestellt. Die technischen Details sind nicht mehr alle aktuell, aber im Wesentlichen auch noch zutreffend. Gruß, Nils

Moin, auch mit dem ADMT bleibt das Vorhaben ein veritables Migrationsprojekt. Besonders, wenn es um das Konsolidieren mehrerer Domänen geht. ADMT ist schon ziemlich gut und jahrelang bewährt, aber für eine "weiche" Migration braucht es einiges an Planung, Vorbereitung und Aufwand im Hintergrund. Unterschätzt das nicht. Man kriegt sowas hin, aber das ist auf keinen Fall was für Nebenbei, und es ist ausgesprochen sinnvoll, sich erfahrene Unterstützung zu holen. Gruß, Nils

Moin, ... und nur für Hyper-V und Scale-out Fileserver. Andere Applikationen haben eigene Einschränkungen. Das geplante Vorhaben geht nur über eine Migration mit Downtime. Wenn man das ordentlich plant, kann die Downtime aber durchaus kurz sein. Gruß, Nils

Moin, zu ergänzen ist: Ordentlich und in Ruhe planen. Und die Anforderungen klären. Wenn man eine PKI unpassend aufsetzt, kann das später viel Aufwand bedeuten. Und am Ende geht es um Sicherheit - das sollte man nicht nebenbei machen. Ohne dir zu nahe treten zu wollen, würde ich einem Umternehmen auch nicht unbedingt raten, eine PKI von einem Praktikanten bzw. Jungstudenten planen und aufbauen zu lassen ... hoffentlich gesteht man dir ausreichend Zeit und Ressourcen zu. Gruß, Nils

Moin, nein. Gruß, Nils

Moin, ja, das kommt aber erst dann ins Spiel, wenn man einen 2012-R2-Cluster hat. Bis das überall so ist, wird es noch dauern. Bis dahin gibt es eine Reihe Methoden zur Migration, aber leider fast keine ohne Downtime. In Kürze gibt es einen Blogartikel von mir dazu. Gruß, Nils

Moin, denkbares Verfahren: Alle VMs sichern Alle VMs auf einen Host verschieben Den anderen Host aus dem Cluster entfernen, diesen Host mit 2012 R2 neu installieren Den 2012 R2 zum Hyper-V-Host machen und als neuen Cluster einrichten Jetzt hast du zwei Cluster Beginn Donwtime Den 2008-R2-Host herunterfahren Die LUN mit dem CSV an den 2012-R2-Host anbinden Die LUN als Clusterressource aufnehmen und zum CSV machen Die VMs importieren ("nur registrieren") Die VMs in den Cluster aufnehmen Die VMs starten - sollte gehen Ende Downtime Den zweiten 2008-R2-Host neu mit 2012 R2 installieren, Hyper-V, LUN abininden, in den Cluster aufnehmen Ungestestet, müsste aber gehen. Sinnvoll wäre, danach eine zweite LUN als CSV einzurichten, das erleichtert künftige Aktionen. Ob du die "alten" Server noch weiter betreiben willst, musst du selbst beurteilen. Gruß, Nils

Moin, also ... wenn ich dich richtig verstehe, hast du beide DCs gleichzeitig aktualisiert? Dann ist es nicht verwunderlich, dass es zu Replikationsproblemen kommt, sondern zu erwarten. Sowas ist doch völlig praxisfern. Abgesehen davon, dass es auch genau keinen Vorteil gibt, ausgerechnet einen DC per In-place zu aktualisieren. Gruß, Nils