NilsK

Moin, es ist relativ simpel: Auf einer Hyper-V-Hostplatte bzw. auf einem CSV liegen fast nur sehr große Dateien. Daher wählt man die größtmögliche Clustergröße, um möglichst wenige I/O-Vorgänge beim Zugriff zu haben. Große Cluster = schneller Zugriff für große Dateien, dafür schlechtere Platzausnutzung bei vielen sehr kleinen Dateien Kleine Cluster = gute Platzausnutzung bei vielen kleinen Dateien, dafür weniger schneller Zugriff bei großen Dateien Das ist allerdings eher eine Frage der Optimierung und nur selten wirklich spürbar. Bestehende Volumes wird man also nur dann neu formatieren, wenn es wirklich Bedarf gibt. Gruß, Nils

Moin, um es noch mal deutlich zu sagen: Exchange hat keine "Abholfunktion", wie du sie etwa von GMX kennst. Gruß, Nils

Moin, nur, damit sich hier aufgrund solcher Unterstellungen keine falschen Eindrücke verfestigen: Nein, wir bekommen keine Provision. Wir gehen aber i.d.R. davon aus, dass Anfragen in diesem Board mit einem professionellen Hintergrund gestellt werden. Und wenn sich dann eine Aufgabe mit einem bestimmten Werkzeug schneller oder besser lösen lässt als ohne, dann empfehlen wir das (sofern wir so ein Werkzeug kennen). Ein Unternehmen wird solche Fragen kaufmännisch beurteilen. So ist das auch hier. Langes Herumprobieren kostet oft viel Zeit, die schnell weit mehr umfasst als die (sehr moderaten) 100 EUR für das genannte Werkzeug. Ob ein "Anfänger" das beschafft, kann er ja selbst entscheiden. Ach, übrigens, der TO hatte sein Beispiel bereits als Schleife aufgebaut. ;) Gruß, Nils

Moin, ich habe das jetzt noch mal in Ruhe gelesen. Offenbar gibt es hier ein Missverständnis. Deiner Fehlermeldung nach hat dein AD die DNS-Anwendungspartitionen, du findest sie wohl nur nicht. Die in der Meldung genannten Betriebsmaster haben mit den AD-Betriebsmastern nichts zu tun. Dieser Artikel beschreibt die Hintergründe: http://blogs.msmvps.com/ulfbsimonweidner/2008/07/31/how-many-infrastructure-masters-do-you-have/ Die Anleitung aus dem anderen Forum trifft völlig zu. Vermutlich ist dein Fehler, dass du die Einträge unterhalb des Domänenbaums suchst. Du musst in ADSI Edit allerdings eine neue Verbindung zu der Partition DC=DomainDnsZones,DC=<domain>,DC=<tld> herstellen. Dann findest du auch den zu ändernden Eintrag. Gruß, Nils

Moin, also ... vielleicht solltest du, bevor du weitermachst, dann doch noch mal eine Aktualisierung deines Wissensstandes vornehmen. Hier nur ein paar Details aus diesem Thread: "eine LUN pro VM" galt, bevor es CSV gab CSV nutzt man nur, wenn ein Cluster an LUNs angebunden ist (FC, iSCSI, SAS) Bei solch einer Anbindung gilt als Faustregel "1 CSV pro Node", sofern der Cluster nicht mehr als ca. 8 Nodes hat Das Quorum-Modell legt der Cluster selbst fest, wenn man ihn lässt. Ob man eine Quorum-Disk braucht, sollte man anhand des geplanten Designs entscheiden. SMB 3.0 empfiehlt sich für Hyper-V nur, wenn es über einen Windows-SoFS bereitgestellt wird. Mal eben so "Berechtigungen setzen" geht in einem Hyper-V-System schnell nach hinten los Und als wichtigster Punkt: Das Design macht man nicht nur vor der Installation, sondern sogar vor der Beschaffung. Gruß, Nils

Moin, ja, das wäre eine simple Variante. So ähnlich habe ich das auch bei einem großen Skript gelöst. Gruß, Nils

Moin, ebenfalls OT: Früher nannte man das "plenken". Gruß, Nils

Moin, wenn du die beiden DNS-Zonen nicht hast, dann läuft DNS bei dir noch nicht in einer eigenen Applikationspartition. Vermutlich wurde die Domäne mal unter Windows 2000 aufgesetzt und dann nie geändert. Dann gibt es dafür aber auch keinen separaten FSMO-Rolleninhaber. Hintergründe dazu: [NTDSUtil zeigt andere FSMO-Rolleninhaber an als LDIFDE? | faq-o-matic.net] http://www.faq-o-matic.net/2010/01/07/ntdsutil-zeigt-andere-fsmo-rolleninhaber-an-als-ldifde/ Dort im letzten Teil. Dein Problem liegt also vermutlich woanders. Was gibt denn folgendes Kommado zurück? netdom /query fsmo Gruß, Nils

Moin, ja, wie ich ja vermutete. Wie gesagt - deaktivieren und fertig. Den Dienst brauchst du nicht, der ist für Client-Windows gedacht. Dass er überhaupt auf einem Server vorhanden ist, deute ich als Schlampigkeit des Herstellers. Vermutlich ist der Dienststart dann auch noch falsch gesetzt (im Lieferzustand), denn eigentlich wäre dafür "Automatisch (Start durch Auslöser)" richtig. Der Server-Manager guckt nur stumpf auf Dienste, die "automatisch" starten sollten und meldet solche, die nicht laufen. Ob man die braucht oder ob das evtl. Absicht ist, weiß er nicht. Jaja, leider gehört auch Windows Server 2016 in die Kategorie "Bananensoftware - reift beim Kunden". Gruß, Nils

Moin, für Applikationen mit typischen grafischen Oberflächen ist PowerShell eigentlich nicht das Mittel der Wahl. Der Fokus der PowerShell liegt auf Automatisierung und auf Interaktion per Kommandozeile. Wenn du das ernsthaft auf dieser Plattform verfolgen willst, solltest du dir ISESteroids ansehen, da gibt es eine recht gute Unterstützung für sowas. Aber sei dir bewusst, das ist wirklich nichts für Scripting-Anfänger. http://www.powertheshell.com/ Gruß, Nils

Moin, schon die ersten Fundstellen im Web zeigen, dass der Dienst bei Bedarf gestartet wird, wenn Anwendungen darauf zugreifen. Insofern ist es normal, dass der Dienst sich nach kurzer Zeit selbst beendet, das ist ja die Idee hinter so einem Aufbau. Wozu brauchst du den Dienst auf einem Server? Gibt es ein Problem damit? EDIT: Okay, ich verstehe. Der Dienst ist standardmäßig vorhanden und wird wegen seines Status im Server-Manager bemängelt. Ist das der Grund für deine Anfrage? Soweit ich es sehe, braucht man den Dienst auf einem Server nicht (höchstens auf einem Terminalserver), daher sollte es problemlos sein, ihn zu deaktivieren. Dann sollte die Meldung verschwinden. Gruß, Nils

Moin, Inhalt markieren und reinkopieren? Gruß, Nils

Moin, da liegt ein grundlegendes Missverständnis vor. Mit SMB 3.0 hast du gar kein CSV, weil die Hyper-V-Hosts in dem Fall ja gar keine LUNs kontrollieren müssen. Die VMs liegen dann auf einem "Dateiserver". Ohne das wirklich geprüft zu haben, würde ich mal behaupten, dass du (übergangsweise) beides parallel nutzen kannst: Dein Cluster arbeitet weiter mit seinem CSV per FC, solange dort noch VMs liegen. Einzelne VMs schiebst du dann auf den SMB-3.0-Speicher - in dem Fall hast du am Ziel ja einen UNC-Pfad als Speicherort. Aber wie gesagt: Wenn es sich nicht um einen Windows-SoFS handelt, dann prüf vorher genau, welche Funktionen dein Storage wirklich per SMB 3.0 bereitstellt. Gruß, Nils

Moin, in den Editionsvergleichen zu Windows 10 ist Branch Cache immer als Feature von Enterprise ausgewiesen, von den anderen nicht. Insofern kann es sein, dass der Dienst mit Windows 10 Pro nicht funktioniert - oder dass man "nur" einen Lizenzverstoß begeht. Aber vielleicht fragen wir mal nach dem Szenario und den Anforderungen: Welches Problem soll Brach Cache denn im konkreten Fall lösen? Gruß, Nils

Moin, kann denn das neue Storage SMB 3.0? Auch vollständig? Viele Nicht-Windows-Systeme implementieren das nur teilweise. Gruß, Nils

Moin, allgemein ist die kurze Antwort zu Branch Cache: Wahrscheinlich willst du es nicht einsetzen. ;) Auf der Clientseite ist m.W. immer die höchste Edition erforderlich. Das hat mit dem Server nichts zu tun. Gruß, Nils

Moin, das ist, wie alles, eine Frage der Anforderungen. Aus deiner Frage geht nicht recht hervor, von welchem Szenario du jetzt sprichst. Gruß, Nils

Moin, beide Teile wären zu definieren ... was ist unter "zentralisierte Daten" zu verstehen? Und was meint "verfügbar ... unterwegs"? Das typische Unterwegs-Szenario sind Notebooks. Da ein Notebook normalerweise der Hauptrechner bzw. der einzige Rechner eines Users ist, würde ich da gar nicht mit Roaming Profiles arbeiten. Unter "zentralisierte Daten" kann ich mir gerade wenig vorstellen. Gemeinsam genutzte Daten gehören auf einen Server, nicht in ein Profil. Da gibt es auch zuhauf Herausforderungen mit Offline-Verfügbarkeit, aber die haben nichts mit Profilen zu tun. Roaming Profiles nur nutzen, wenn es wirklich nicht anders geht, und nur im Einzelfall. Gruß, Nils

Moin, <seufz /> es hat insofern mit Hyper-V zu tun, als ein Hyper-V-Host nun mal tief in den Netzwerkstack eingreift. Man kann versuchen, drumrumzubasteln und es irgendwie wieder zum Laufen zu kriegen. Mit etwas Glück bekommt man das für einen bestimmten Anwendungsfall hin. Es wird aber nicht mehr zuverlässig sein, weil der Netzwerkstack in deinem Fall ("mal eben" Hyper-V nachinstalliert) in einer nicht supporteten Konfiguration läuft, also nicht vorhersagbar ist, wann er sich wie verhält. Der bessere Weg ist daher, es "mal eben" richtig aufzusetzen. Das dauert, wenn wir von einem Hyper-V-Host und einer DC-VM reden, vielleicht zwei Stunden. Und jetzt vergleich mal, wie lange du daran schon rummachst ... Für mich ist der Thread hier beendet, Nils

Moin, ich habe in dem Szenario gute Erfahrungen mit Windows Server Backup gemacht: Zusätzliche Disk in die VM einhängen - meiner Erinnerung nach sollte VirtualBox auch VMDK-Dateien schreiben können Per WSB ein Vollbackup auf diese Disk machen Quell-VM herunterfahren Die Disk-Datei auf den Zielhost kopieren Auf dem Zielhost neue VM anlegen mit lokaler Disk, die kopierte Disk-Datei als zweite Disk anhängen Die VM mit dem Windows-ISO starten, dort WIederherstellung auswählen Das Backup von der zweiten Disk auf die Systemdisk der VM wiederherstellen Zumindest mit Hyper-V als Zielhost ging das ganz gut. Für Produktion wäre ich prinzipiell skeptisch, aber für Laborzwecke war es nützlich. Gruß, Nils

Moin, nein, natürlich nicht. So geht man mit Hyper-V auch nicht um. Wir haben es dir doch schon mehrfach vorgebetet: Hyper-V nur als Host installieren Darauf dann VMs Warum hast du ihn dann eingerichtet? Wäre auch arrogant, wenn es die ganze Antwort gewesen wäre. War es aber nicht. Und dass du wüsstest, wie es richtig geht ... hast du erstens widerlegt, und zweitens widersprichst du dem ja selbst. Du kannst, wenn du dich abgeregt hast, den Thread ja noch mal in Ruhe lesen. Zumindest ich habe ihn anders in Erinnerung, als du ihn hier beschreibst. Gruß, Nils

Moin, das nicht, aber auf die Grundlagen der Funktion sollte man trotzdem achten. Hab ich mir gedacht, dass Microsoft Schuld ist. Wer auch sonst. Was würde denn teurer, wenn du auf der Hardware nur Hyper-V installierst und alles weitere in VMs? Hättest du auf einem ESXi auch direkt AD installiert? Nein, oder? Siehst du, genauso ist das auch bei Hyper-V, nur dass man aufgrund der grafischen Oberfläche meint, dass es ginge. Wenn du das so siehst - siehst du das so. In Wirklichkeit haben wir den Fehler ja lokalisiert, aber die Antwort passte dir nicht. Dann noch ein schönes Leben! Gruß, Nils

Moin, sagen wir: Damit hast du das Problem in die Zukunft verschoben. SID History ist nie für Dauerbetrieb gedacht gewesen, sondern nur als Übergangstechnik. Man sollte das "irgendwann" entfernen. Die Tokengröße ist nur eins der Probleme, die daraus erwachsen können. Gruß, Nils PS. Als mögliche Ursache für "komische Zugriffsprobleme" kommt das aber in Betracht, da hast du Recht.

Moin, danke für die Anregung, aber so eine Änderung werde ich wohl nicht einbauen. Gruß, Nils

Moin, die License Terms habe ich nicht da, aber im Licensing Datasheet heißt es: Die umständliche Formulierung ist dem Umstieg auf Core-Lizenzierung geschuldet. Für den Kern deiner Frage bedeutet das, dass du wie unter 2012/R2 auch mit 2016 demselben Host mehrere Standard-Lizenzen zuweisen kannst, wenn du mehrere "Zweierpakete" von VMs lizenzieren willst. http://download.microsoft.com/download/7/2/9/7290EA05-DC56-4BED-9400-138C5701F174/WS2016LicensingDatasheet.pdf Gruß, Nils PS. Die Aussage spiegelt ein Laienverständnis und ist keine juristische Auskunft. Für juristisch verlässliche Aussagen musst du den Lizenzgeber ansprechen.