NilsK

Moin, dagegen spricht technisch nichts. Ob es sinnvoll ist und ob "ein Flaschenhals" entsteht, kann man ohne genaue Analyse der Anforderungen nicht sagen. Gruß, Nils

Moin, ein nicht supportetes System, vermutlich. @TO: Rechner nicht ans Internet lassen. Dann kriegt er keine Updates und kann auch nicht angegriffen werden. <scnr /> Gruß, Nils PS. Im Ernst: Das geht nicht, wenn man keinen Lizenzverstoß begehen will. Und da wir Lizenzverstöße hier nicht supporten ...

Moin, er meint natürlich: SET devmgr_show_nonpresent_devices=1 Die meisten Computer sind bei sowas sehr pingelig. ;) Gruß, Nils

Moin, fast. ;) Unique Local oder Global Unicast. Wobei von Unique Local allgemein abgeraten wird. Gruß, Nils

Moin, naja, deine ISO wird halt nicht mehr bootfähig sein. Dazu braucht sie einen speziellen Bootsektor, den ein selbst erzeugtes ISO nur dann hat, wenn man ihn im "Brennprogramm" ausdrücklich erzeugt. Gruß, Nils

Moin, hm? Wieso beim Gast einbinden? Was machst du da? Klingt mir nach einem Missverständnis oder Konzeptfehler. Das Volume soll der Host verwalten, die Gäste (= VMs) bekommen dann virtuelle Festplatten, die als VHDX-Dateien auf dem Volume des Hosts liegen. Eine physische Platte an die VM durchreichen, geht zwar, ist aber eigentlich nie sinnvoll. Gruß, Nils

Moin, auf einem Standalone-Host kannst du die VMs ja nur auf Volumes speichern, die der Host auch verwaltet, also müssen die dort online sein. (Im Cluster ist das eigentlich auch so, aber da verhält sich das mit dem Online-Status etwas anders.) Deine Meldung deutet für mich darauf hin, dass in der RAID-Einrichtung noch was nicht stimmt. Gruß, Nils

Moin, falscher Weg, weil grundsätzliches Missverständnis. Mit IPv6 kannst du erst dann richtig "anfangen", wenn du es mit deinem Provider zusammen tust. IPv6 hat kein Konzept von "privaten" Adressbereichen, weil das nur eine Krücke von IPv4 ist (die dort ursprünglich auch nicht vorgesehen war). In Kurzform die Empfehlung für die meisten kleineren und mittleren Netzwerke: Die IPv6-Einstellungen auf den Rechnern so lassen, wie sie sind - sie konfigurieren sich dann für das lokale Subnetz selbst (Stateless Address Autoconfiguration, SLAAC). Damit können sie im eigenen Subnetz mit anderen Rechnern per IPv6 kommunizieren, haben aber keinen Weg nach draußen. IPv6 in den Eigenschaften des Netzwerks nicht abschalten. Teredo, ISATAP und 6to4 hingegen sollte man abschalten (z.B. per GPO), es sei denn, man hat konkreten Bedarf (manche Implementierungen von DirectAccess etwa) IPv6 geht nicht, ohne mit dem Provider zusammenzuarbeiten. Es benötigt dann Ende-zu-Ende-Konfiguration. Insbesondere Firewalls und Router müssen dabei im Design berücksichtigt werden, DHCP ist eher ein untergeordnetes Thema. Gruß, Nils

Moin, hat er doch schon beantwortet, erläutert, direkt zwei über deiner Frage. Gruß, Nils

Moin, die Idee bei S2D ist Hyperconverged: Storage und Compute in derselben Box, davon mehrere, mit automatischer Replikation und Auto-Tiering. Rein technisch betrachtet ist das z.B. bei Nutanix besser gelöst (die haben z.B. ein Konzept von Data Locality, das S2D fehlt, und brauchen daher kein RDMA). In dem Szenario ist Datacenter auch kein Problem, weil man das für die VMs ohnehin braucht. Wenn du Storage und Compute trennen willst, ist S2D nicht die richtige Technik. Dann könnte Storage Replica interessant sein - und da schlägt die Datacenter-Lizenz schon eher ins Budget. Gruß, Nils

Moin, relativ einfach per PowerShell, ähnlich einfach so: [Mitglieder einer AD-Gruppe mit Zusatzdaten ausgeben | faq-o-matic.net] http://www.faq-o-matic.net/2008/07/04/mitglieder-einer-ad-gruppe-mit-zusatzdaten-ausgeben/ Gruß, Nils

Moin, ah, OK, dann bezog sich deine Antwort auf "die Frage" nur auf die indirekt gestellte Frage im zweiten Satz. ;) Gruß, Nils

Moin, was meinst du damit? Gruß, Nils

Moin, S2D ist eine Implementierung der aktuellen Hyperconverged-Technik. Die beiden Szenarien, für die es m.W. unterstützt ist, sind Hyper-V und SQL Server. Auch wenn das Marketing behauptet, dass das eine günstige Technik sei, wird man schon ziemlich viel ausgeben müssen. Schon deshalb, weil für produktiven Support RDMA-Netzwerkverbindungen empfohlen sind. DocDatas Hinweis trifft also zu. Gruß, Nils

Moin, ja, das ist dann aber nicht mehr "einfach hintereinanderhängen". :D Gruß, Nils PS. das einfache Piping | wäre hier auch noch zu nennen. :P

Moin, ich meine ja auch die Umgebung ... zum Beispiel: Wo liegen die VMs, wo sollen sie hin. Wie sehen die Berechtigungen auf den beteiligten Ordnern aus. Was genau hast du in den Live-Migration-Einstellungen gesetzt. Halt so Informationen, die man zum Troubleshooting braucht. Stell dir einfach vor, du wärest der Supporter und müsstest die Informationen vom User bekommen. Das, wonach du fragst, teilst du uns mit. Übrigens gibt es für Hyper-V gleich einen ganzen Satz an eigenen Ereignisprotokollen unter den Anwendungs-Logs. Schau doch dort bitte noch mal nach. Gruß, Nils

Moin, auf Basis der bisherigen Informationen kann man keine sinnvollen Analysen oder Hinweise geben. Also bitte entweder noch mal nachlegen oder selbst recherchieren. Gruß, Nils

Moin, wenn der Provider kein IPv6 ins Netzwerk routet, dann kommt da ja auch nichts rein. Tut er es doch, dann hat er seinem Kunden ein IPv6-Präfix zugeteilt. Spätestens das ist der Punkt, an dem man anfangen muss, ein IPv6-Design umzusetzen. Da ein Provider das aber nicht mal so eben macht (oder, um in deinem Bild zu bleiben, "im Vorbeigehen"), hat man das Design dann auch schon fertig - sonst hätte man ja kein IPv6 angefordert. Man weiß als (Unternehmens-)Kunde, wenn man per IPv6 "ins Internet" kommt. Die von dir zitierten Dokumente sind sehr generisch und berücksichtigen die derzeitige Situation nicht, in der die meisten Unternehmen IPv4-only ans Internet angebunden sind. Wichtig: Man muss sich bei IPv6 von der Vorstellung einer Trennung von privaten und öffentlichen Netzwerksegmenten trennen, die nur eine Krücke von IPv4 ist. Solange kein vom Provider zugewiesenes IPv6-Präfix im lokalen Netz verteilt wird, gibt es kein Routing, weil es keine Routen gibt. Und dieses Präfix verteilt sich nicht von selbst, sondern weil man es konfiguriert. IPv6 in Windows abzuschalten, führt zu einer nicht getesteten und daher nicht supporteten Konfiguration. Was man abschalten sollte, sind die Übergangstechniken (Teredo, ISATAP und 6to4), es sei denn, man setzt sie gezielt ein (etwa für bestimmte DirectAccess-Konfigs). IPv6 ist komplex, aber es ist kein Sicherheitsproblem "per se". Gruß, Nils

Moin, nein, du schaltest IPv6 nicht ab. Das haben wir hier im Board ja schon oft diskutiert. [Windows Server 2008 und IPv6: Deaktivieren führt oft zu Fehlern | faq-o-matic.net] http://www.faq-o-matic.net/2009/04/24/windows-server-2008-und-ipv6-deaktivieren-fhrt-oft-zu-fehlern/ Solange IPv6 nicht gemeinsam mit dem Provider "bis ins Internet" konfiguriert ist, stört es nicht, und es gibt auch keinen Konfigurationsbedarf. In dem Fall konfiguriert es sich im lokalen Subnetz automatisch und wird dort auch für lokale Kommunikation verwendet. Abschalten ist nicht supportet und führt (sehr) oft zu Fehlern. Einfach in Ruhe lassen. Ich denke, dazu sollte ich mal einen FAQ-Artikel machen. Drumrum scheint es in deiner Konfig aber das eine oder andere Problem zu geben. Solange du aber nicht sagst, was du da eigentlich machst, fallen Analyse und Hinweise etwas schwer. Gruß, Nils

Moin, die IPv6-Meldung kannst du ignorieren, solange IPv6 bei euch nicht eingesetzt und zentral konfiguriert ist. (Das wäre erst der Fall, wenn ihr an euren Provider per IPv6 angebunden seid und von dort ein Prefix erhalten habt.) Die IPv4-Meldung dürfte darauf hindeuten, dass auch keine statische v4-Adresse gesetzt ist. Das wäre natürlich zu korrigieren. Darf man fragen, was du da gerade machst? Recovery-Test? Gruß, Nils

Moin, eigentlich stellt mein Artikel doch recht deutlich dar, dass eine VM "optimal" nur durch Neuinstallation als VM eingerichtet werden kann. Abgesehen davon, traust du den Plug-&-Play-Mechanismen von Windows anscheinend zu wenig zu. Prinzipiell bindet sie die richtigen Treiber für geänderte Hardware schon korrekt ein. Und das Mainboard ist in aller Regel nicht der Faktor, auf den es ankommt, da wäre dann schon eher der Chipsatz zu nennen. Auf der Ebene ist eine VM aber gar nicht unterwegs. Gruß, Nils

Moin, na, das ist aber mittlerweile ein Klassiker. https://support.microsoft.com/en-us/kb/967482 Ignorieren oder den RODC-Support einrichten. Gruß, Nils

Moin, damit ist immer noch nicht die Frage nach der Notwendigkeit beantwortet. Ordnerumleitung ist eine Technik, die auch alles andere als problemfrei ist, ich nenne nur: [Ordnerumleitung – Denial of Service in Wartestellung | faq-o-matic.net] http://www.faq-o-matic.net/2011/11/14/ordnerumleitung-denial-of-service-in-wartestellung/ Gruß, Nils

Moin, was ist daran komisch? Du kannst nicht einfach zwei Kommandos in einer Zeile hintereinander hängen. Das ist der Fehler. Deine erste Variante ist ja identisch mit meinem Code. Die Ausgabe der Werte hatte ich nur angehängt, damit man sie kontrollieren kann. Gruß, Nils

Moin, ei verbibbsch, du hast Recht. Anscheinend kann man Variablennamen in Batches doch dynamisch setzen. Wieder was gelernt. Dann stimmte deine Syntax in der FOR-Schleife nicht. Folgender Code funktioniert bei mir: @echo off setlocal EnableDelayedExpansion set zaehler=0 for /f "skip=1 tokens=1" %%a in ('wmic logicaldisk where drivetype^=3 get deviceid ^') do ( set /a zaehler=!zaehler!+1 set Var!zaehler!=%%a ) if not "%Var1%"=="" echo %Var1% if not "%Var2%"=="" echo %Var2% if not "%Var3%"=="" echo %Var3% if not "%Var4%"=="" echo %Var4% endlocal Gruß, Nils