NilsK

Moin, die CPU kann man problemlos überbuchen. Keine VM lastet ihre vCPUs dauerhaft aus. Es ist der Kern eines Hypervisors, zwischen verschiedenen VMs hin- und herzuschalten. In typischen Umgebungen trifft man Überbuchungen von 1:5 oder mehr an, das hieße bei deinem System, dass du 40 vCPUs problemlos an VMs verteilen könntest. Auch mehr, da würde man wahrscheinlich keine Einbußen bemerken. Gruß, Nils

Moin, nö, laut der Tabelle ist es das nicht. Da steht "0" bei meinem Modell. Das Phänomen ist aber auch ein anderes als dort beschrieben, weil das Flimmern anscheinend nur bei einer bestimmten Hintergrundfarbe auftritt. Aber immerhin schon mal interessant, dass es an Spezifika der Hardware liegen könnte. Gruß, Nils

Moin, wenn das Host-OS 16 GB RAM hat, sollte das dicke ausreichen. Die CPU ist in "normalen" Umgebungen praktisch nie ein Flaschenhals. Der Leistungsmonitor bezieht sich allerdings immer nur auf den Teil der Ressourcen, die das Host-OS kontrolliert, die 59 Prozent dürften sich also auf die 16 GB des Host OS beziehen. Das wäre soweit erst mal unauffällig, weil Windows verfügbaren Speicher auch für "nichtproduktive" Aufgaben nutzen kann. Es ist durchaus denkbar, dass bestimmte Updates bei einem Host einfach deutlich länger brauchen, weil die Ressourcennutzung ja völlig anders läuft als bei "normalen" Servern. Ich habe wenig Erfahrung im dauerhaften Betrieb von Einzelhosts und kann daher nur mutmaßen. Wenn du die Möglichkeit hast, die Updates mal mit gestoppten VMs durchzuführen, wäre das aber sicher mal interessant. Gruß, Nils

Moin, nein. Dort scheint es ja auch dauerhaft zu flimmern. Nicht bewusst. Wie würde ich das feststellen? Und träte das dort nur in bestimmten Situationen auf? Gruß, Nils

Moin, naja, mehr RAM hat er nicht unbedingt, denn dem Host OS bleibt nur, was nicht an die VMs verteilt ist. Da könnte durchaus eine ungünstige Konfiguration verborgen sein, wenn der Host nicht genug RAM zum Arbeiten hat. Wenn es allzu eng wird, weigert sich Hyper-V zwar, eine VM zu starten, aber bei knapper Verteilung kann es eben sein, dass Host-Vorgänge länger dauern. Allerdings glaube ich eigentlich nicht, dass das der Grund ist. Trotzdem, wo wir dabei sind: Wieviel RAM hat denn der Host physisch, und wieviel ist an die VMs zugewiesen? Gruß Nils

Moin, nein, die VMs muss man nicht herunterfahren. Sobald die Umgebung etwas größer ist, wird man aber mehrere Hosts haben und verschiebt dann üblicherweise die laufenden VMs per Live Migration, um die jeweils zu patchenden Hosts freizuräumen. Das kann den Vorgang des Updates beschleunigen, vermeidet aber vor allem Betriebsrisiken. Zu dem konkreten Zeitbedarf, den du beobachtet hast, kann ich nichts sagen. Gruß, Niös

Moin, leider kann man seit Windows Server 2012 R2 die Hyper-V-Administration mit Bordmitteln nicht mehr delegieren. Ein möglicher Ausweg ist Just Enough Administration, was aber sehr viel Aufwand erzeugt. Dazu habe ich auf der CDC 2017 einen Vortrag gehalten, im IT-Administrator einen Artikel geschrieben und im Hyper-V-Buch (Rheinwerk) ein Kapitel verfasst. Eine Alternative wäre der SCVMM, aber den wird man kaum nur für die Aufgabe beschaffen und einsetzen wollen. Gruß, Nils

Moin, ja, das Weiß, das aber (glaube ich) kein Weiß ist, sondern etwas dunkler (kann gerade das CSS nicht untersuchen). Die einzige Webseite bzw. Applikation, bei der mir das (bislang) aufgefallen ist, ist das Board. Wenn ich allerdings einen Screenshot des Boards in Word einfüge, flimmert der Screenshot dort auch. Ein normales weißes Dokument flimmert nicht. Ebenso kein Flimmern bei der Bahn-Webseite oder bei meinem eigenen Blog (beide "echtes" Weiß). Das kann jetzt auch einfach ein Phänomen im Grafiktreiber sein oder so, zumal es nur mit dem Notebook-Display auftritt, nicht auf einem externen Monitor. Daher wollte ich auch erst mal nur wissen, ob noch jemand das kennt. Es sieht ein bisschen so aus, als würde über dem Arbeitsplatz eine Neonröhre flimmern (da ist aber keine). Gruß, Nils

Moin, das dürfte eher eine Frage des Netzwerks sein als eine von Hyper-V. Der Teaming-Funktion von Windows Server dürfte das egal sein. Da würde ich aber auch überlegen, ob ein Team aus drei 10-GbE-Adaptern wirklich sinnvoll ist, da entsteht ja auch CPU-Last, die nicht zu unterschätzen ist. Wie gesagt: Gesamtkonzept. Gruß, Nils

Moin, ah, also eine 2-Port-Karte, die insgesamt ausgefallen ist? In der Tat, dann wird es mit der Redundanz nichts. Theoretisch könnte man "auf Vorrat" aus den beiden 1-GbE-Ports auch ein Team bilden und einen vSwitch daran hängen. Auf den könnte man dann in so einem Fall die VMs umkonfigurieren. Die könnte man dann aber nicht mehr per Live-Migration oder Failover auf einen anderen Host bringen, weil dann der Switchname unterschiedlich wäre. Eher würde ich dann darüber nachdenken, zwei separate 10-GbE-Karten einzubauen statt einer Dualport-Karte. Allerdings müsste man dann auch in Betracht ziehen, wie wahrscheinlich solche Ausfälle denn sind und ob man nicht noch andere SPoFs im Gesamtsystem hat. Als dritte Variante könnte man auch den vSwitch in so einem Fall löschen und auf Basis des 1-GbE-Teams neu anlegen. Das wiederum würde ich nur tun, wenn es Skripte dafür gibt. Oder um es zusammenfassend zu sagen: Das ist ein Thema für ein Gesamtkonzept. Gruß, Nils

Moin, was ich seit einiger Zeit feststelle: Die Hintergrundfarbe des Boards scheint bei bestimmten Monitoren problematisch zu sein. Auf meinem Notebook-Display flimmert der Hintergrund immer leicht. Das ist bei anderen Webseiten im selben Browser nicht so, daher vermute ich die Farbe als Grund. Das Phänomen habe ich sowohl mit Chrome als auch mit dem Firefox. OS ist Windows 10, aktueller Stand 1803 (war aber mit 1709 schon so). Kennt das jemand? Gruß, Nils

Moin, ja, schau mal, was ich mal alles wusste. Aber wie dort schon geschrieben, ist das eigentlich auch nur ein halbgarer Workaround. Da man den Telefonen wohl kaum sagen kann, dass sie die Vendor-ID mitsenden sollen, müsste man das umgekehrt den Clients sagen. Klingt nicht unbedingt nach einem sinnvollen Aufbau. Gruß, Nils

Moin, wenn eine Netzwerkkarte im Team ausfällt, soll die andere natürlich weiterarbeiten. Das ist ja der Witz daran, noch eher als die Bandbreitenerhöhung (die bei 10 GbE gar nicht so die große Rolle spielt). Also würde ich dem Problem bzw. der möglichen Fehlkonfiguration nachgehen und keine Workarounds schaffen. Gruß, Nils

Moin, Workarounds gäbe es mehrere, man könnte auch mit Reservierungen arbeiten und an diese individuelle Optionen binden. Ein sauberer Aufbau wird daraus aber nicht. Genau für sowas sind VLANs mal erfunden worden. Gruß, Nils

Moin, die einzige saubere Lösung besteht darin, das Netz aufzuteilen, am einfachsten durch VLANs. Dann kommen die PCs in ein VLAN und die Telefone in das andere. Jedes VLAN wird dann durch DHCP mit einem eindeutigen Scope versorgt. Gruß, Nils

Moin, aha. Und was ist der Nutzen dahinter? Was meinst du mit "DHCP-Bereich"? Handelt es sich dabei um getrennte Netze? Um dasselbe Netz, aber verschiedene IP-Adressbereiche? Um dasselbe Netz und denselben Adressbereich, aber nur verschiedene Gateways? Es wäre ganz gut, ein bisschen mehr preiszugeben, sonst kann das hier eine längere, aber fruchtlose Veranstaltung werden. Gruß, Nils

Moin, wenn du Gruppenmitgliedschaften änderst, muss der betreffende User sich neu anmelden. Die tatsächlichen Gruppenmitgliedschaften kannst du am Client prüfen, wenn du, angemeldet als der betreffende User, in ein CMD- Fenster eingibst: whoami /groups | clip && notepad In dem Notepad-Fenster, das sich dann öffnet, Strg-V drücken. Nun siehst du alle direkten und indirekten Mitgliedschaften des Users. Sind die passenden Gruppen dabei? Dann könnte es natürlich sein, dass der User Mitglied einer Gruppe ist, der der Zugriff verweigert wird. Oder der User greift von einem Client aus zu, dessen Systemzeit sich von der Zeit der Domäne um mehr als fünf Minuten unterscheidet. Oder dieser Zeitunterschied tritt auf dem Dateiserver auf. In großen Umgebungen könnte es zu "Token Bloat" kommen, der User ist dann Mitglied in zu vielen Gruppen. Und das sind nur die Dinge, die mir spontan einfallen ... Gruß, Nils

Moin, dafür müsste man jetzt wissen, was du denn da erreichen willst. Was meinst du mit "zweiter DHCP-Bereich"? Und was soll am Ende dabei rauskommen? Gruß, Nils

Moin, schon seit zehn Jahren reicht es aus, einen verwaisten DC im ADUC zu löschen. Danach noch im Standorte und Dienste sowie im DNS entfernen. Gruß, Nils

Moin, jaja, so ein Backup ist immer eine praktische Sache. Schön, hier auch mal zu lesen, dass jemand sowas hat. Die defekte SSD solltest du reklamieren können. Gruß, Nils

Moin, dann war das Zertifikat sehr wahrscheinlich nicht "sofort da", sondern eher "nie weg". Müßig. Für mich ist hier Schluss. Gruß, Nils

Moin, was genau würde das an dem Problem ändern? Dass der Standby das Problem verursacht, ist praktisch ausgeschlossen. Gruß, Nils

Moin, prima, danke für die Rückmeldung. Gruß, Nils

Moin, wenn auch nur das Risiko besteht, dass die Tombstone Lifetime überschritten ist (die durchaus auch bei 60 Tagen liegen kann, je nachdem, wann und wie das AD mal installiert wurde), dann schalte den DC nicht wieder online. Es geht ja ganz offenkundig auch ohne ihn, was gäbe es da zu "retten"? Gruß, Nils

Moin, da es sich um Berechtigungseinträge handelt, wirst du das über die Manipulation der ACL regeln müssen. Dafür gibt es kein GPO-Cmdlet. Man bekommt das per PowerShell hin, aber Berechtigungen sind damit immer sehr aufwändig und fehlerträchtig. Gruß, Nils