NilsK

Moin, Die Anzeige der Netzwerke ist in der Tat sehr ... durcheinander. Wie kommt das, hast du mehrfach neu angefangen? Erst mal wäre zu klären, was die ganzen Netzwerke sollen. Wie viele LAN-Ports sind in dem Rechner? Es sind anscheinend auch VPNs eingerichtet? Warum mehrere Hyper-V-Switches? Und welche Konfiguration bzw. Funktion willst du eigentlich erreichen? Gruß, Nils

Moin, Das ist in dem Fall ja auch recht einfach. Warum Norbert mehrfach nachgefragt hat, liegt daran, dass oft in solchen Situationen eben doch ein Zugriff stattfindet: wenn etwa ein User sich gar nicht an Windows anmeldet, sondern eine Applikation nutzt, die ihrerseits eine Anmeldung ans AD für den User durchführt. Das wäre ein indirekter Zugriffs, der sehr wohl eine CAL erfordert. Da es hier anscheinend aber um ehemalige Mitarbeiter geht, die sich weder direkt noch indirekt anmelden, dürfte keine CAL erforderlich sein. Gruß, Nils

Moin, Schon 1. April? Gruß, Nils

Moin, hm, irgendwie komisch, jetzt nicht in Lingen zu sein ... jedenfalls wünsche ich euch morgen eine schöne Konferenz. Trinkt bei der Party ein Glas für mich mit. Gruß, Nils

Moin, das ist eine ganz schlechte Idee. Aber zumindest können wir die Windows-Firewall damit als Störfaktor ausschließen. Dann kommt aber natürlich dein Malwarebytes-Gelöt in den Kreis der Verdächtigen. Als nächstes käme jetzt aber die Netzwerkkonfig des Hosts ins Spiel. Wie ist die denn gebaut? Gruß, Nils

Moin, die Speichererweiterung selbst können wir als Ursache wohl praktisch ausschließen. In den meisten Fällen dieser Art handelt es sich mehr um einen zeitlichen Zusammenhang, aber nicht um einen ursächlichen: Auslöser der Verhaltensänderung ist der Neustart des Servers, der durch den Hardwaretausch nötig war. Bei diesem Neustart können dann Dinge vom OS ausgeführt worden sein, die Windows bis dahin "aufgeschoben" hat, meist Updates bzw. damit zusammenhängender Austausch von Dateien. Ich verstehe es richtig, dass das Problem sich nur auf RDP-Verbindungen zum Hyper-V-Host bezieht, die von "außen" kommen? Zu diesem eigentlichen Problem habe ich keine heiße Spur, nur allgemeine Hinweise: Windows Server 2008 R2 ist veraltet. Gerade im Netzwerk ist Hyper-V da auch noch sehr eingeschränkt. (Wobei solche Probleme da natürlich nicht auftreten sollten.) IPv6 abzuschalten, ist fast nie eine gute Idee. Auch nicht, wenn man es "nicht braucht" (Windows "braucht" es i.d.R. sehr wohl.) Typischerweise liegen in der Netzwerkkonfiguration des Hosts Fehler vor, wenn solche Phänomene auftreten. Das liegt daran, dass die Netzwerkkonfig an der Stelle leider sehr unübersichtlich und "eigen" ist. Ich würde also vermuten, dass da der Hase im Pfeffer liegt. Gruß, Nils

Moin, beruhigend. ;) Danke für die Bestätigung! Gruß, Nils

Moin, vor allem hilft es in den beschriebenen Szenarien fast nie ... Danke, @Leon2121, für die Rückmeldung! Gruß, Nils

Moin, jein, leider ist es so leicht nicht. Aus Sicherheitssicht sollte man WINS heute nicht mehr einsetzen, es wird seit Jahren nicht gepflegt und es gibt bekannte Sicherheitslücken, die Microsoft ausdrücklich nicht mehr schließen wird. Ob man WINS "braucht", ist leider nicht so einfach zu beantworten. Alles, was man "wirklich" braucht, geht schon seit Jahren über DNS. Es gibt aber Software - die durchaus nicht "uralt" sein muss -, die immer noch Mechanismen nutzt, die ohne WINS nicht oder nicht richtig funktionieren. Einfache Computerlisten (mit denen z.B. ein User den Server auswählt) sind so ein Beispiel - manche Developer nehmen da einfach das, was sie immer genutzt haben, und dann baut so eine Liste sich aus NetBIOS-Namen zusammen. Im eigenen Subnet geht das per Broadcast, sobald aber ein Router im Spiel ist, scheitert das. Da hülfe WINS, DNS aber nicht. Gruß, Nils

Moin, konkretisieren wir das: Sobald auf einen 2016 (VM oder physisch) durch Anwender oder Endgeräte zugegriffen wird, sind für diese Zugriffe CALs erforderlich. Wie viele das sind, richtet sich nach den konkret zugreifenden Einheiten. Je nach Dienst, der auf dem 2016 läuft, kann es erforderlich sein, alle CALs auf 2016 zu aktualisieren: Ein DC unter 2016 kann von allen Usern und Endgeräten angesprochen werden, einige andere Dienste ebenso - das lässt sich faktisch nicht einschränken. In diesen (und ähnlichen) Fällen müssen 2016-CALs also flächendeckend vorliegen. Eine Ausnahme ist Hyper-V: Wenn ein 2016-Server ausschließlich als Host verwendet wird und keine anderen Dienste anbietet, aber sonst keine 2016-Server in Betrieb sind, dann sind keine 2016-CALs erforderlich. Meines Wissens hat sich dieses Prinzip nicht geändert. Gruß, Nils

Moin, machen wir's kurz: Das willst du nicht. Auf so ein Konstrukt könntest du dich nicht nur nicht verlassen, es bedeutet auch ein hohes Risiko für den Normalbetrieb. Neben dem Umstand, dass du schon sehr gute Prozesse bräuchtest, um da sinnvoll "Updates" auf die Maschine zu bringen, hättest du Risiken für die Datenkonsistenz. Zudem passiert es in solchen Konstrukten immer wieder, dass man eben doch beide Fassungen der Maschine (die Physik und die VM-Kopie) aktiv hat, und damit öffnest du die Tür für richtig schöne Probleme (Erreichbarkeit, Split Brain, Namensauflösung, sogar Netzwerkausfälle habe ich in solchen Situationen schon gesehen). Und selbst wenn das nicht geschähe, hättest du nach ca. einem Monat das Problem, dass das Computerkennwort der VM nicht mehr stimmt und die VM sich dann nicht an die Domäne anmelden kann. Ein Recovery-Konzept für SQL Server ist eigentlich nciht schwierig. Mach es lieber richtig. Log Shipping ist übrigens nicht Teil eines Recovery-Konzepts. Gruß, Nils

Moin, zurück zum Thema. Es geht hier um einen DC in Hyper-V, nicht um grundsätzliche virtuelle Netzwerkdesigns. Gruß, Nils

Moin, ein Mischbetrieb im Host-Cluster ist nicht grundsätzlich untersagt, aber lizenz- und nachweistechnisch schwer abzubilden. Die Vorgabe lautet: Da die Windows-VMs immer über den Host lizenziert werden, muss für jede laufende VM zu jedem Zeitpunkt eine gültige Lizenz vorliegen - auch dann, wenn vMotion/Live Migration oder ein Failover stattfinden. (Hier müsste also auf allen Hosts, auf die die VM wechseln kann, eine passende Lizenz vorliegen.) Hast du also nur Windows-VMs mit 2012 oder geringer, dann dürfte es gestattet sein, diese auf einem der 2016-Hosts auszuführen (sofern dessen Lizenz ein Downgrade erlaubt). Da wir über Datacenter reden, ist die Zahl der VMs dann ja nicht relevant. Sobald dann aber eine Windows-VM mit einer Version oberhalb von 2012 ins Spiel kommt, darf die nicht auf einem der 2012-Hosts laufen. Faktisch hättest du dann also aus Lizenzsicht zwei Cluster, nicht einen. Und der Nachweis bei einem Audit dürfte sehr schwierig werden. Daher rate ich von so einem Konstrukt ab. Der saubere Weg wäre, alle Hosts mit derselben Lizenzversion zu betreiben. Dafür kann SA durchaus interessant werden - schließlich steht Windows Server 2019 vor der Tür, dann stellt sich dieselbe Frage bald wieder. Gruß, Nils

Moin, naja, in Ordnung wäre sie eben nicht. Das Konstrukt mit den beiden Netzwerkkarten ist - kurz gesagt - falsch. Ob du dafür erst noch eine Testumgebung bauen willst, spielt auf einer anderen Ebene. Zum Aufbauen von Know-how ist das sicher eine gute Idee. Es gibt ja auch gute Literatur zum Thema. Gruß, Nils

Moin, das wird jetzt etwas OT, aber trotzdem: Hier bewegen wir uns in den Bereich der Mythen. So ein Konstrukt würde bedeuten, dass alle beteiligten VMs immer auf demselben Host laufen müssten. Mit Verfügbarkeitskonzepten geht das praktisch nie zusammen. Lasst uns jetzt aber bitte nicht Hyper-V-Netzwerke diskutieren, das war im Kontext des Threads nur ein Nebenaspekt. Wenn der TO dazu Fragen hat, sind die in einem separaten Thread besser aufgehoben. Gruß, Nils

Moin, kurz gesagt, brauchst du in einer Produktionsumgebung das "interne" und das "private" Netzwerk praktisch nie. Dort nutzt du nur das "externe" - wobei das nichts anderes ist als eine Verbindung ins physische LAN. "Extern" hat hier erst mal nichts mit einer Internetverbindung oder gar einer Erreichbarkeit aus dem Internet zu tun. Weiterführend ist dies i.W. immer noch zutreffend: [Hyper-V und Netzwerke | faq-o-matic.net] https://www.faq-o-matic.net/2012/04/23/hyper-v-und-netzwerke/ Gruß, Nils

Moin, ich schließe mich meinem Vorredner an. Was immer euer Trainer da gebaut hat, es ist weder üblich noch sinnvoll. Der schien entweder seltsame Ideen zu haben oder er hat Hyper-V nicht verstanden. Ein DC hat nur eine Netzwerkkarte und nur eine IP. Die Replikation kann man netzwerkseitig nicht vom "normalen" Traffic trennen. Falls man in speziellen Fällen für Server mal mehrere NICs braucht (nicht für DCs), dann haben diese praktisch nie Adressen aus demselben IP-Segment. Gruß, Nils

Moin, tja ... mit den Anforderungen steht dir gewissermaßen der ganze Markt offen. Da kann ich jetzt leider nichts weiter beitragen. Gruß, Nils

Moin, was soll das System denn leisten? Von SharePoint über WordPress über Jira bis zur SAP-Integration käme sonst sehr viel in Frage ... Gruß, Nils

Moin, klar. Aber daraus folgt noch lange nicht, dass jedes Unternehmen zu einer bestimmten Form der elektronischen Archivierung verpflichtet sei. Das bleibt eine Frage des Einzelfalls. Im Kontext dieses Threads ist das durchaus relevant. Zumal, wie gesagt, der TO angibt, dass eine Compliance-Archivierung bereits vorhanden sei (alle Ein- und Ausgänge). Ob die im Fall einer Prüfung oder eines Gerichtsverfahrens akzeptiert wird, steht auf einem anderen Blatt, aber dazu können wir hier eben nichts sagen. Wer da auf der sicheren Seite sein will, braucht eine individuelle Rechtsberatung. Der TO gibt ja ausdrücklich an, dass es ihm um eine Archivierung für organisatorische Zwecke geht. Die hat mit gesetzlichen Archivierungspflichten rein gar nichts zu tun. Gruß, Nils

Moin, sorry, aber das ist so nicht richtig. Bitte keine juristischen Behauptungen aufstellen. Rechtsberatung dürfen in Deutschland nur zugelassene Anwälte durchführen. In der Umgebung ist lt. TO eine Compliance-Archivierung aktiv. Gruß, Nils

Moin, dafür kommt so ziemlich jeder Load Balancer in Betracht, von Open Source bis kommerziell. Ist dann eine Frage des Budgets und des Supports. Ganz so einfach ist es im Detail aber nicht, denn da sind Fragen nach dem Netzwerkdesign zu klären (z.B. was läuft intern, was in der DMZ, wie geschieht der Zugriff, wie die Administration usw.). Gruß, Nils

Moin, naja, die skizzierten Anforderungen erfüllt so ziemlich jedes aktuelle Archivprodukt. Der Knackpunkt ist dieser: Eine solche Lösung muss ins Exchange integriert sein. Und da stellt sich dann schon die Frage, auf welches System sich das bezieht und wer es nutzen soll. Die Idee mit dem IMAP-Server halte ich nicht für zielführend. Damit umgeht man nicht die zentralen Fragen, baut aber eine Struktur, die kaum sinnvoll zu administrieren und für die User auch nicht gut zu verwenden ist. Gruß, Nils

Moin, ich wage erheblich zu bezweifeln, dass ihr in einer zentralisierten IT-Struktur ein lokales Archiv dieser Art betreiben dürft. Euch wird also nichts übrig bleiben, als mit der Konzern-IT über eure Anforderungen zu sprechen. Gruß, Nils

Moin, naja, so weit würde ich nicht gehen. Der Ansatz ist sicher nur für wenige Dinge geeignet, aber hier und da kann er vielleicht ausreichen. Gruß, Nils