NilsK

Moin, ja, nachdem ich ausdrücklich nach dem Hintergrund gefragt habe. Sehr wahrscheinlich nicht. In demselben MSDN-Artikel, den du zitiert hast, steht auch drin, dass Gen-2 eigentlich keine messbaren Vorteile hat. Leg also eine neue Gen-1 an, kopier die VHD-Datei und häng sie an. Für die Übertragung der Freigaben mit Berechtigungen kannst du einen Registry-Export nutzen. Ja, das mag sein. Wir wollen niemandem zu nahe treten - wenn du dir den Verlauf der Diskussion aber mal ansiehst, wirst du feststellen, dass es nicht ganz einfach war, überhaupt den Hintergrund herauszubekommen und dir zu vermitteln, dass deine Annahmen nicht überall zutreffen. Also fürs nächste Mal: Gleich sagen, worum es geht. Und für uns: Geduld bewahren. ;) Gruß, Nils

Moin, und was hat das mit dem eigentlichen Punkt zu tun, dass du eine Datendisk von einer Gen-1-VM problemlos als Datendisk an eine Gen-2-VM ankoppeln kannst? Konvertier sie halt und fertig. Meinst du, dass es irgendwen hier voranbringt, wenn du jetzt mit solchen Nebenfragen ablenkst? Bin dann mal raus, Nils

Moin, wir haben das in den vergangenen Wochen mehrfach hier diskutiert. Schau dir die einschlägigen Threads einfach an. Meine kurze Antwort: Sie sind nicht sinnvoll und waren es nie. Gruß, Nils

Moin, derartige konzeptionelle Fragen eignen sich nicht für ein Forum. Dafür sollte man sich Zeit nehmen (und ggf. ein bisschen Geld investieren), um es in Ruhe zu entwickeln. Wenn es sich bei beiden Netzen um Testnetze handelt (und nicht um produktive Daten), ist das erst mal im Grundsatz OK. Wenn das eine ein Test- und das andere ein Produktionsnetzwerk wäre, sollte man sich über den Grad der Kopplung bzw. Trennung ein paar Gedanken mehr machen. Gruß, Nils

Moin Nuncic, vielen Dank für den wertvollen Einblick! Gruß, Nils

Moin, und in dem Szenario haben Gen-2-VMs nicht mal ernsthafte Vorteile. Man hätte also auch einfach eine Gen-1 nehmen können und hätte weder das Problem noch den nicht supporteten Zustand. Gen-2-VMs werden dramatisch überschätzt. Gruß, Nils PS. und das nächste Mal sagst du bitte gleich, was du eigentlich vorhast, statt nur nach einem Detail zu fragen. Dann hätten wir uns die ganze Diskussion gespart.

Moin, doch, gibt es. Ist nicht supportet. Wird mit allergrößter Sicherheit gar nicht gehen. Daher schlechter Weg. Was der Sinn des Ganzen ist, willst du gar nicht besprechen, richtig? Gruß, Nils

Moin, mir erschließt sich der Sinn des Konstrukts nicht ganz. Weder Nutzbarkeit noch Sicherheit scheinen mir davon zu steigen. Aber zu den Fragen: DHCP arbeitet per Broadcast. Die physische Netzwerkgrenze ist die Broadcastgrenze, also vereinfacht gesagt, der Router. Ein Router leitet DHCP-Anfragen nicht in andere Subnetze weiter (solange man ihn nicht ausdrücklich dazu konfiguriert). Zwei Domänen sind immer zwei getrennte logische Konstrukte. Solange sie nicht denselben Namen tragen, kann es nicht zu "Vermischung" oder Problemen kommen, wenn sie Netzwerkkontakt zueinander haben. Gruß, Nils

Moin, sorry, aber ich versteh nur Bahnhof. Wie passen: und zusammen? Wenn es wirklich um die Systemdisks geht: Nein, das geht so tatsächlich nicht. Es gibt keinen supporteten Weg, eine Gen-1-VM in eine Gen-2-VM umzuwandeln. Allerdings existiert ein nicht supporteter Weg: [Windows Hyper-V generation 2 VM conversion utility (Convert-VMGeneration) Beispiel] https://code.msdn.microsoft.com/windowsdesktop/Convert-VMGeneration-81ddafa2 Gruß, Nils

Moin, äh ... ist nicht ganz einfach zu verstehen, was ihr da warum vorhabt. Was ist jetzt wo die System- oder die Datendisk? Warum sollte sich die Daten-VHD nicht an die Gen2-VM anbinden lassen? Konvertiert sie doch in eine VHDX (Convert-VHD), dann sollte es gehen. Oder überseh ich da was? Gruß, Nils

Moin, ah, OK. Na gut, dann gilt das durch den ganzen Stack. Dann ist die Sache ja klar. Meine Aussage oben ist so also nicht richtig. SMB 3.0 wird übrigens ausdrücklich ausgenommen, aber erst ab Exchange 2013: https://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx https://technet.microsoft.com/en-us/library/jj619301(v=exchg.160).aspx#BKMK_ExchangeStor Trotzdem sollte es natürlich nicht zu Problemen mit NFS kommen - wenn doch, spricht das gegen den konkreten Gesamtaufbau. Gruß, Nils

Moin, ja, trifft aber hier nicht zu. Exchange greift ja mit Blocklevel auf seine Disks zu. Die NFS-Anbindung findet auf Ebene des Hosts statt, nicht auf Ebene des Gastes. Dabei kann es durchaus auch zu Problemen kommen (meist weil das Gesamtdesign nicht stimmt), aber die sind außerhalb von Exchange. Man "sichert" Exchange auch nicht per Snapshot. Predige ich schon seit 14 Jahren, wollen die NetApp-Leute aber nie hören. Gruß, Nils

Moin, ESX per NFS ist eine typische NetApp-Konfiguration. Das verkaufen die so gern, weil ihre NFS-Lizenz so teuer ist. Grundsätzlich sollte meiner Erfahrung nach nichts dagegensprechen. Parallel noch iSCSI in den VMs zu machen, ist natürlich nicht so schön - zwei Storageprotokolle parallel ist technisch zwar kein Problem, steigert aber nicht die Performance und verkompliziert das Troubleshooting. Für Exchange sollte technisch nichts dagegensprechen, auf VMDK umzustellen. Wie die im Host angebunden sind, sollte dabei sekundär sein. Im Fall von Exchange ginge das auch bei Clustering, weil eine Exchange-DAG ja kein Shared Storage braucht. Mit so einem Aufbau sollte das dann auch per Veeam sicherbar sein. LUNs, die direkt an eine VM angebunden sind, kann Veeam in der Tat nicht sichern - immer wieder ein Problem z.B. bei SQL-Clustern. Gruß, Nils

Moin, danke, Franz. Verstehe ich das so richtig: Ich habe einen Server z.B. mit zwei 10-Core-CPUs mit laufender SA für 2012 R2. Solange ich das so weiter betreibe und der Vertrag noch läuft, ändert sich für mich nichts. Aktualisiere ich den Server auf 2016, so gilt die Core-Regel. Eigentlich wäre ich jetzt unterlizenziert, aber solange die SA weiter läuft, brauche ich nicht nachzuzahlen. Wenn ich dann die SA für den 2*10-Core-Server mit 2016 verlängere, brauche ich die eigentliche Serverlizenz nicht kostenpflichtig zu erweitern. Ich muss aber die SA für 20 Cores abschließen. Passt das so? Gruß, Nils

Moin, ich denke, da wäre mal ein Konzept anzuraten. Es gibt Berater für sowas. :D Gruß, Nils

Moin, OK, Glück gehabt. Aber: Dann war es auch kein GAU. Dass etwas unangenehm ist, ist nicht das Kriterium. Wenn ihr nacharbeiten könnt, ohne dass dies das Unternehmen wirklich bedroht, dann ist das eine wichtige Aussage, die ihr bei der Überarbeitung des Wiederherstellungskonzept berücksichtigen könnt. Ein solches Konzept muss immer von den Geschäftsprozessen ausgehen und sich auf die Frage beziehen, welcher Schaden für das Unternehmen bedrohlich ist und was man tut, um ihn zu vermeiden, einzugrenzen und damit umzugehen. Ein Thema für die Geschäftsleitung, die IT spielt eine unterstützende Rolle. Gruß, Nils

Moin, ganz schlechte Karten. Wenn es wirklich wichtig ist, wendet euch an einen professionellen Datenretter. Der wird die ganzen Platten brauchen, also mindestens die VHDX-Dateien, in denen die Datenbank-Dateien lagen. Haltet den Datenbankserver in dem Fall sofort an, damit er alle Änderungen in der virtuellen Festplatte unterlässt. Unterlasst auch alles andere, was Daten ändern könnte - am besten die ganze VM herunterfahren. Dann könntet ihr eine Kopie der VHDX-Dateien machen und sehen ob ein Datenretter was damit anfangen kann. Und nächstes Mal ... aber gut, das wisst ihr schon. Gruß, Nils

Moin, ich wiederhole mich ja gern ... also: Das Problem liegt auf der organisatorischen Ebene und muss organisatorisch gelöst werden. Da ihr nicht die einzigen seid, die vor dem Problem stehen, hier ein Hinweis, wie andere das häufig machen: Anforderungen, die nicht als Ticket aufgegeben werden, werden mit einem Textbaustein beantwortet, der auf das Ticketsystem hinweist. Dann wird die Anforderung nicht weiter bearbeitet. Bei mündlicher Ansprache wird ebenfalls auf das Ticketsystem verwiesen und nichts weiter getan. Fehlen im Ticket wichtige Daten, gibt es eine Antwort mit Textbaustein, und die Bearbeitung geht erst weiter, wenn die Daten vorliegen. Sofern die Unternehmensleitung das trägt, ist das Problem in aller Regel innerhalb kurzer Zeit verschwunden. Deine Beschreibung im ersten Post deutet darauf hin, dass ihr eine Regel formuliert (Antworten nur im Ticket), die ihr aber selbst nicht einhaltet (indem ihr die Daten nachpflegt). Da ist der erste Ansatzpunkt. Gruß, Nils

Moin, hm, verstehe. Aber mal ehrlich: Wenn das ein Netzwerk ist, in dem Softwareverteilung betrieben wird, ist dann ein einzelner VM-Host, der nur 2 VMs ausführen kann, nicht arg knapp? Eine Standard-Lizenz kostet nur wenige hundert Euro, und so teuer ist Datacenter nun auch wieder nicht. Ich würde so eine VM jedenfalls nicht betreiben wollen. Wenn bei einem der Dienste mal was klemmt oder ein Update gemacht werden muss, sind die anderen auch gleich betroffen. Von den Datenmengen und der stoßweisen Last, die da zusammenkommen, gar nicht zu reden. Gruß, Nils

Moin, und warum sollen mehrere VMs auf dem neuen Hypervisor mehr kosten als auf dem alten? Wäre schon ganz gut, wenn du Informationen zusammenhängend gibst, dann müssen wir dir nicht alles einzeln aus der Nase ziehen und sparen uns unnötige Roundtrips. Architektonisch wäre es wenig sinnvoll, im Rahmen der Virtualisierung einen der Hauptvorteile - die Rollentrennung von VMs - nicht zu nutzen. Bei der oben genannten Kombination würde ich schon eine Reihe von Nachteilen erwarten. Kann man aber deutlich besser beurteilen, wenn man den Zusammenhang kennt - wie eigentlich bei jeder Angelegenheit. Gruß, Nils

Moin, einmal 16-Cores würde nicht helfen, weil mindestens zwei CPUs à 8 Cores zu lizenzieren sind. Er müsste dann also trotzdem 32 Cores lizenzieren, wenn ich das richtig sehe. Ob Microsoft das technische Konstrukt (Abschalten von Cores) akzeptiert, musst du dort klären. Wir können dazu maximal mutmaßen. Gruß, Nils

Moin, ein dritter Knoten kostet ja auch recht erheblich - neben der Hardware schlägt die Datacenter-Lizenz zu Buche. Um so wichtiger, dass man das Sizing und die Redundanzen (auf allen Ebenen!) richtig plant. Gruß, Nils

Moin, wenn eine neue Version auf den Markt kommt, entfernt Microsoft i.d.R. sehr bald die alten Lizenzen aus der Preisliste. Normalerweise kann man dann nur noch die neue Version kaufen. Will man eine ältere Version einsetzen, dann braucht man eine Lizenz mit Downgrade-Recht. Bestehende Lizenzen mit SA laufen bis zur nächsten SA-Verlängerung nach dem alten Modell (CPU-Lizenzierung) weiter, gewähren aber trotzdem das Recht, die neue Version einzusetzen. Kaufst du neue Lizenzen, dann gelten die Bedingungen und SA-Konditionen der neuen Lizenzierung (Core-Lizenzierung). [Windows Server 2016: Details zur Lizenzierung | faq-o-matic.net] http://www.faq-o-matic.net/2016/10/06/windows-server-2016-details-zur-lizenzierung/ Hinweis: Dies ist eine Illustration der Lage, keine Rechtsberatung oder verbindliche Aussage. Gruß, Nils

Moin, kannst du dich remote auf das Gerät verbinden? Dann kopiere die Daten runter und mach die Kiste neu. Gruß, Nils

Moin, das denke ich auch, aber es entspricht der Frage, die der TO gestellt hat. Möglicherweise muss der TO noch mal über den erwünschten Prozess nachdenken. Am Ende ist "bitte nutzt das Ticketsystem" immer eine organisatorische Angelegenheit, die sich nicht rein technisch lösen lässt. Neben "Benutzer sendet Mail an IT" gäbe es dann ja auch noch "Benutzer sendet Mail an den Admin" oder "Benutzer spricht den Admin auf dem Flur an". All diese Dinge wird man nur organisatorisch regeln können und dabei nie 100 Prozent erreichen. Mit 70-80 Prozent steht man schon gut da. Muss man mit leben. Gruß, Nils