NilsK

Moin, ich konkretisiere: Niemals bei einem NIC, der Teil eines Hyper-V-Switches ist, die Protokollbindung ändern. Dort ist nur das Switch-Protokoll gebunden, Ende. Niemals bei einem anderen NIC das Switch-Protokoll manuell hinzuschalten. Bei virtuellen NICs oder physischen NICs ohne Verbindung zu Hyper-V kann man die "üblichen" Protokollbindungen ändern, aber auch niemals die Spezialprotokolle für Hyper-V oder Teaming manuell anpassen. Gruß, Nils

Moin, siehe oben, das ist nicht ganz vollständig. Mit Software Assurance erwirbt man für SQL Server die Lizenzmobilität und darf eine VM dann zwischen Hosts bewegen. Gruß, Nils

Moin, bitte nie-, nie-, niemals bei den Protokollbindungen von Hyper-V-Netzwerkkarten manuell etwas ändern. Gruß, Nils

Moin, ja, bei 4 VMs auf einem Host brauchst du zweimal Standard. CALs brauchst du nur einmal pro Unternehmen und Client. Bei 20 Devices also 20 CALs, damit kannst du auf alle Server des Unternehmens mit der lizenzierten Version (oder Vorgängern) zugreifen. Gruß, Nils

Moin, auch wenn es dir nicht weiterhilft, hört sich das für mich nach Treiberproblemen an. Da du angibst, dass du auch schon unter Windows 7 Probeme hattest, könnte es aber auch ein Hardwareproblem sein. Handelt es sich um einen Desktop-PC? Dann würde ich es mal mit einer anderen Karte versuchen, so teuer ist das ja nicht. Ach so, Hyper-V würde ich nach den Reparaturversuchen wieder deinstallieren und dann neu einrichten, die manuellen Änderungen dürften das Problem eher verschärfen als lösen. (Besser noch: Windows neu installieren.) Die Anzeige "2" bei der Karte kommt daher, dass du den Adapter einmal deinstalliert und dann neu eingerichtet hast. Windows zählt da mit. Gruß, Nils

Moin, danke für die Rückmeldung. Und schön, dass du das mit Humor sehen kannst. :) Hast du einen Beleg für die Aussage, dass 2008 sich nicht korrekt verhält und ab 2008 R2 das korrekte Verhalten vorliegt? Das würde mich mal näher interessieren. Gruß, Nils

Moin, das ist eine Designfrage, die zu 100% von deinen Anforderungen abhängt. Designfragen lassen sich in einem Forum nicht sinnvoll klären. Gruß, Nils

Moin, äh ... vermutlich nicht richtig. Leider verstehe ich deine Formulierungen nicht ganz. Das Grundmodell ist so: Die Lizenzen weist du immer und ausschließlich den Hosts zu (= den physischen Servern), niemals den VMs. Eine Lizenz kannst du nur an einen Host zuweisen. Sie ist nicht übertragbar, außer bei dauerhaftem Ausfall des ursprünglichen Servers. Eine Standard-Lizenz berechtigt dich, auf diesem Host bis zu zwei VMs mit Windows Server zu betreiben. Sofern du Hyper-V einsetzt, darf auf dem physischen Server dann außer Hyper-V nichts laufen. Möchtest du mehr als zwei VMs mit Windows Server betreiben, dann kannst du dem Host mehrere Standard-Lizenzen zuweisen. Jede fügt zwei weitere "VM-Rechte" hinzu. Da das irgendwann teuer werden kann, kannst du auch mit Datacenter-Lizenzen zuweisen. Diese enthalten "beliebig viele" VM-Rechte für den betreffenden Host. In einem Cluster müssen alle Hosts so lizenziert sein, dass für alle VMs jederzeit dort Lizenzen vorliegen. Beispiel: 2 Hosts im Cluster, 6 VMs innerhalb des Clusters: Jeder Host benötigt drei Standard-Lizenzen (also sechsmal Standard). Beispiel: 3 Hosts im Cluster, 16 VMs innerhalb des Clusters: Jeder Host benötigt acht Standard-Lizenzen (also 24-mal Standard) - hier zu teuer, daher besser: Auf jedem Host eine Datacenter-Lizenz (also dreimal Datacenter). Die CALs sind nur für die Zugriffe der User auf die VMs da, die Virtualisierung selbst braucht keine CALs. Für die Downgrade-Rechte musst du dir die konkreten Lizenzbedingungen der Produktvariante ansehen, das kann variieren. Gruß, Nils

Moin, da es sich dann um eine Datei handelt, richtest du einen Job ein, der diese an den Zielort kopiert. Gruß, Nils

Moin, ganz nebenbei: Wenn wirklich "maximale Ausfallsicherheit" gewünscht ist, würde ich nicht unbedingt auf B-Hersteller wie Synology und Netgear setzen. Für den Hausgebrauch sicher machbar, aber im konkreten Fall siehst du ja schon, dass es da auch mal Lücken im Support gibt. Bei diesen Herstellern wirst du auch am Dienstleistermarkt nicht viele Partner finden, die da wirklich firm sind. Das sieht bei A-Herstellern i.d.R. anders aus. Gruß, Nils

Moin, oha, mit euch möchte ich auch mal Geschäfte machen. ;) Alternativ zur Mehrfachlizenzierung (bzw. so ist der eigentliche Weg): Software Assurance für die SQL-Lizenzen. Dann gibt es "Lizenzmobilität" und die SQL-VM darf dann den Host wechseln. Gruß, Nils

Moin, weder noch. Ohne weitere Kenntnisse der Umgebung wäre mein Vorschlag, die Domäne "standort-b.de" aufzulösen und den dortigen DC als normalen DC der Domäne "standort-a.de" einzurichten. Alle Rechner und Ressourcen dieses Standorts dann in die Zentraldomäne aufnehmen (bzw. umgekehrt: Erst Ressourcen übertragen, z.B. mit ADMT, dann die Domäne auflösen). Einen RODC würde ich nur einrichten, wenn das Szenario das hergibt, was aber erfahrungsgemäß nur selten der Fall ist. Gruß, Nils

Moin, in solchen Fällen würde ich immer nur die Nutzdaten kopieren. Alles andere erzeugt unnötig hohe Risiken für vergleichsweise kleinen Nutzen. Gruß, Nils

Moin, Kunden, die jetzt (= vor Release von 2016) mit SA kaufen oder jetzt eine aktive SA haben, haben u.U. einen Kostenvorteil, weil sie voraussichtlich auf eine adäquate 2016-Lizenz ohne Mehrkosten umsteigen können. Wobei mal das so richtig genau erst bewerten kann, wenn die Details vorliegen, und das dürfte noch ein halbes Jahr oder länger dauern. Gruß, Nils

Moin, naja, wenn die Situation so ist, wirst du mit einer "massenweisen" Lösung wohl auch nicht weit kommen, denn die wird ja immer nach einer gewissen Regel vorgehen. In deinem Fall würde ich eher davon ausgehen, dass noch weitere Unregelmäßigkeiten in den Daten sind, die man ohnehin nur manuell gelöst bekommt. Du kannst natürlich mit einer Skriptlösung arbeiten, was aber voraussetzt, dass du die Änderung als "Skriptregel" formulieren kannst. Vielleicht findest du am Markt auch eine Lösung, die dir das AD als Tabelle anzeigt und Excel-artige Änderungen ermöglicht, aber sowas wird sicher ordentlich kosten. Wenn du richtig gut bist, kannst du sowas auch selber bauen - Export in CSV/Excel und nach Bearbeitung selektiver Re-Import der geänderten Daten. Gruß, Nils

Moin, tja, etwas weniger James Bond und etwas mehr Ruhe ist manchmal schon ratsam. Gruß, Nils

Moin, wie Oliver schon richtig sagt, sind Umlaute kein prinzipielles Problem. Manche Sonderzeichen empfehle ich auch an bestimmten Stellen wegzulassen, aber die von dir genannten Felder sind in der Regel unproblematisch - mit Ausnahme der Mailadresse. Gruß, Nils

Moin, also ... für mich klingt das Konzept nicht gut. Der Jet-Zugriff hat neben der Performance derart viele Einschränkungen in einem Multi-User-Szenario, dass das Geld in einer Umstellung auf ein SQL-Backend mit Sicherheit besser investiert wäre. In der Regel sind das auch keine riesigen Aufwände. Wenn der Zugriff tatsächlich von einer RDS-VM auf eine Dateiserver-VM erfolgen soll, dann sollte der Zugriff auf demselben Host in der Tat performanter sein als wenn du über das LAN gehst. In dem Fall läuft der Traffic ja nur über den VMBus. Dabei wäre es dann evtl. sogar sinnvoll, die RDS-Server und den Dateiserver für die interne Kommunikation an einen "internen" vSwitch anzubinden. Meine Vermutung ist, wie gesagt, dass deine Beobachtung auf das SMB-Protokoll zurückzuführen sind. Dazu kann ich nichts Näheres sagen. Mein Favorit bliebe aber die sinnvolle Datenbankarchitektur ... Gruß, Nils

Moin, bei deinem Zugriff testest du aber nicht "das virtuelle Netzwerk". Um aussagefähige Werte zu bekommen, müsstest du schon von einem externen Rechner aus auf die Freigabe zugreifen. Selbst dann nützt dir ein Test, der per SMB Daten schreibt, aber für dein Szenario nichts. Ein Zugriff auf eine Jet-Datenbank ist dann doch etwas anderes. Zu den Hintergründen des Netzwerks in Hyper-V siehe: [Hyper-V und Netzwerke | faq-o-matic.net] http://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Das bezieht sich zwar noch auf Windows 2008 R2, aber insbesondere an der Architektur hat sich hier nichts geändert. Welche Besonderheiten des SMB-Protokolls dir da jetzt noch in die Suppe spucken, kann ich nicht sagen. Aber wenn, dann solltest du mit realistischen Szenarien testen, nicht mit unrealistischen. Was genau meinst du mit "Auf diesem System laufen viele Access Anwendungen"? Ist das der Dateiserver, wo die Datenbanken liegen, die übers Netz genutzt werden? Oder soll das ein Terminalserver sein? Und wenn es auf Performance ankommt: Warum dann kein SQL Server? Das wäre eine der ersten zu empfehlenden Maßnahmen. Gruß, Nils

Moin, was genau erhoffst du dir denn von dieser Messung? Das ist doch ein völlig unrealistisches Szenario. Abgesehen davon, ist das Kopieren von Dateien ohnehin so gut wie nie als Benchmark geeignet, daher halte ich eine nähere Analyse jetzt für weitgehend überflüssg. Was soll die Umgebung denn später mal machen? Gruß, Nils

Moin, darauf können wir uns einigen. :) Gruß, Nils

Moin, vor allem passen die Begriffe nicht. Live Migration, Quick Migration und Failover sind drei unterschiedliche Dinge. Gerade beim Clustering muss man das auseinanderhalten. Gruß, Nils

Moin, eigentlich müsste beides gehen. Die meisten Sprachen lassen beides zu, weil man die Abfrage evtl. noch in Code einbauen muss, der selbst Anführungsstriche braucht, etwa wenn man sie per VBScript verarbeitet. Bei Zahlenwerten kann man die Begrenzer meist auch weglassen. Da man bei WMI aber nie so recht weiß, ob ein Wert als String oder als Zahl verarbeitet wird, ist es sicherer, die Begrenzer mit anzugeben. Gruß, Nils

Moin, na, wenn du meinst. Ich würde allerdings nicht davon ausgehen, dass eine einzelne Platte für das, was du vorhast, ausreichend IOPS bringt. 10K oder 7,2K macht da keinen ernsthaften Unterschied. Aber wenn es schon an gut 500 Euro für eine zweite Lizenz scheitert ... dann muss man an der Stelle einfach nehmen, was kommt. Ich würde an der Stelle aber durchaus noch mal über Anforderungen, Budget und Alternativen sprechen. Sinnvoll ist das Design nicht. Gruß, Nils

Moin, Quick Migration ist in Hyper-V aber was anderes. Der Vorgang erzeugt einen Saved State der VM (also vereinfacht gesagt: speichert den RAM-Inhalt und pausiert die VM), übergibt die Ressourcen an einen anderen Node und dieser setzt die VM aus dem Saved State fort. Das passiert beim Failover aber nicht. Failover <> Quick Migration Gruß, Nils