Erster Blogbeitrag: Lab Gen3, Vmware und so

Soderle, lange geplant, nun bin ich aus heiterem Himmel krank geworden, hab Zeit, muß vermutlich für Wochen Bettruhe wahren, aber bevor ich auf dem Heimweg von dem letzten Arztbesuch die Treppe nach oben nahm quälte ich mich noch in den Keller, und schaltete mein IT Labor ein. Quälen heißt, jeder Schritt ist eine Überwindung, aber das hab ich in Kauf genommen. Damit ich mich die Wochen danach irgendwie beschäftigen kann... mein Arbeitgeber ist da ziemlich strikt, keine Nutzung des Dienstnotebooks und dienstlicher Ressourcen in unserem Rechenzentrum wenn man krank ist, oder in Kurzarbeit oder im Urlaub. Mit dem Notebook darf ich höchstens eine Abwesenheitsnotiz setzen, Termine abzusagen und ein Foto von der Krankmeldung zu verschicken. Mehr nicht. Seitdem Konzerntöchter Kurzarbeit gemacht hatten, wird das auch wirklich überwacht. Seit einem Jahr also keine Email mehr von Kollegen, die früher der Meinung waren, sie müßtem am Samstag oder am Sonntag freiwillig arbeiten und von einigen auch am Freitag nicht. Nun ja bis ich mal wieder gesund bin... spiel ich halt ein wenig mit meinen eigenen Ressourcen herum.

Und das sind:

Ein Synology DS414 mit 16 TB, da stecken noch die guten alten WD Red 4 TB mit CMR drin.
7 Jahre alt, ich denk nun doch über ein Backupmedium nach, eine externe 10 TB Platte.

Ein LCS-UC204: ein günstiger USB over Ethernet Server
Drei Longshine GS108T managed switches
Ein Ubiquity Edgerouter X, da ich die Netze nicht alle zusammenlegen wollte, derer es drei gibt.

Eine APC USV, die eigentlich die Synology am Leben erhalten sollte bzw bei schwachem Batteriestatus auch heruntefahren kann. Denn nach einem Stromausfall macht die Synology fast 50 Stunden lang einen Raid-Check.
Die Batterien hatten einen Killswitch, und da die USV bei defektem Batteriezustand einfach den Ausgangsstrom abschaltet hatte ich dann den zweiten Raid-Check.

Ein uralter 55 Mbit Wifi Hotspot. Der Keller hat kein Mobilfunkempfang, und das Diensthandy kann dann LTE over IP machen.

Zwei virtualisierungshosts.

Ein Supermicro X9DRD-LN4f (hab ich neu und versiegelt für 220 Euro erstanden, warum also die bei Ebay zum Festplreis von fast 300 Euro angebotenen gebrauchten Boards nehmen?), 256 GB DDR3 1066 CL7 (gerade bei Intel CPUs spielt der Speichertakt und die CLs nur eine marginale Rolle), 2x Xeon 2650v2, zwei Enermaxx Liqmaxx 3 Waküs (zurechtgesägt und selbstgebauter Adapter da die Rams zu hoch sind), und das verbaut in einem Aerocool Tor Pro VG1. Das einzige EATX Gehäuse unter 100 Euro und gutem Lüftungskonzept. Und ein Sharkoon 850W Netzteil, denn das Board braucht 2x 8 Pin EATX+ ATX 2.03

Dazu gesellte sich später noch ein Supermicro X9SRa (Single socket, aber selber Chipsatz und da mir der Ebay-Verkäufer 26 anstelle 16 Speichermodule eingepackt hatte hatte ich am Ende 416 GB für 240 Euro erstanden

Das Board kam immerhin mit einem Xeon 1620 (der schnellste Singlesocket Xeon), Netzteile, Kabel, Schrauben u.s.w. hatte ich aus der Schlachtaktion meines Labs davor, und noch ein Tor Pro VG1.

Es liegen noch viele Teile herum, z.B. ein 40 GBit Infiniband Switch, nicht unter VMware nutzbare Infinibandkarten. Der aber mangels Lizenzen nur 20 GBit macht, die Hälfte der Ports sperrt und keine Management Funktion hat. Wird getaucht...

Man fragt sich vielleicht, warum ich Serverhardware in Gamergehäuse verbaue... zwei Antworten: 1.) weil ich den Platz habe und in Gamergehäusen die Belüftung laminar, aber mit 4 oder 5 Lüftern in der 14 cm Größe sehr gut ist 2.) weil sie leise sind solange sie nicht die fürs Gaming typischen Hitzemengen wegtransportieren müssen. Aber der Gamer hat ja einen Kopfhörer auf, den interessierts nicht. Die Xeons in dem Dual-Board haben jeder 90W TDP, aber die erreichen die nur sehr selten und der Xeon 1620 wird gerade mal handwarm ohne Last. Und kurz nachdem mein erster Lab-Rechner fertig montiert war, mußten bei uns alle ins Homeoffice, und ich war der einzige, der schon 2013 einen Schreibtisch mit 2 großen Monitoren zuhause stehen hatte. Dazu zwei flüsterleise Server, ein flüsterleises Storage.

Und diese Computerecke mußte vor 2 1/2 Jahren aus dem Kinderzimmer ausziehen, denn meine Frau war schwanger geworden

Beide Boards laufen herforragend mit VMware ESXi 6.7 CU3, ich kann alle VMs, die ich vorher auf der DS414 auf einem iSCSI Volume hatte, weiterverwenden... wenn da nicht dieser blöde ISCSI Bug wieder auftaucht.

Das Lab davor lief seit 2012 auf einer AM3+ Platform, und ESXI 5.5
Und dann kam Windows 10 raus. Installiert, Purple screen. Google. Ok ich muß auf CU3 Stand kommen, aber wie wenn man die kostenlose Lizenz hat? Nur Inhaber von Wartungsverträgen dürfen die CUs herunterladen, wer keinen Wartungsvertrag hat, der muß sich die Patches einzeln herunterladen. Der Patchaufwand war enorm, aber danach war Windows 10 ohne Purple screen startbar.

Und selbiges wiederholte sich beim Patchen vom Server 2016

Nun das OS war das ISO aus dem MSDN, Patched 2018. Aber Januar. Gut, installiert, in die Domäne eingebunden, läuft. Aber nur 2 RDP Sessions möglich. Also auf dem Dualcpu Host noch einen Infrastrukturserver installiert, sogar einen Lizenzserver für den TS gefüttert und da zeigten sich dann gravierende konzeptionelle Schwächen...

Wo die Anmeldung vorher noch mit dem "remote access" funktionierte (Client Windows 10, Patchstand gestern) verweigerte mir der RDP Client dann die Anmeldung wegen

An authentication error has occurred.

The function requested is not supported

Remote computer: <computer name="">

This could be due to CredSSP encryption oracle remediation.
For more information, see the link

Diese Meldung kannte ich allzugut, und nun tritt auch NOCH ein Bug zutage:

Die CredSSP Geschichte prüft ein Client mit Patchstand Mai 2018 oder neuer NUR wenn das Ziel ein Session host ist. Das Protokoll ist aber dassselbe... Rechner, die den Remoteaccess aktiv haben, aber nicht in eine Remotedesktop Infrastruktur integriert sind, sind also weiterhin über eine Schwachstelle im CredSSP angreifbar...

Überhaupt hat Microsoft im April 2018 für viel Ärger gesorgt, denn es gibt eine GPO dazu.

CredSSP GPO bei Microsoft

Diese ist im Normalzustand undefiniert, und was Microsoft auch mit dem Patch (eigentlich aus dem Mai 2018) getan hat: Die Interpretation der UNDEFINIERTEN Richtline wurde geändert in "CredSSP ist aktiv und Connects werden nur von sicheren Clients aus bzw zu sicheren Servern erlaubt". Was clientseitig und Serverseitig gilt, ein RDP Client verweigert z.B. auch die Verbidnung zu einem unsicheren Session Host, aber NICHT zu einem unsicheren Host. Ist bis heute undokumentiert geblieben.

Microsoft hat den Patch in Azure verfrüht im April 2018 ausgerollt, und von da an hat die Serverseite Verbindungen von unsicheren Clients abgelehnt. Unsere Corporate IT rollt aber keine MS Patches blind aus, sondern prüft die vorher...natürlich haben die den Patch auch im April gehabt, aber erst im Mai ausgerollt, da Azure bei uns kein Thema war außer bei mir, denn ich hatte das Pilotprojekt am Hals. Die Zwischenlösung war ein RDP Proxy von Parallels...

Und der neue Sessionhost hat keine Updates gehabt, also Aktualisierung angestoßen, die Verbindungsverweigerung kam vom RDP Client... der Keller hat nur 70 Mbit nach draußen bis mal ein LAN Kabel die 1000 MBit nach "unten" durchleiten wird. Also hatte ich vorher einen WSUS eingerichtet, sich vollsaugen lassen - 500 GB - aber in der GPO die Portnummer vergessen, so dümpelte der Server ungepatcht einen Monat so rum, bis gestern, wo er die Termianlserverrolle erhalten hat. Aber nach dem cumulativen März 2021 Update crasht mir mal wieder das ESXI, diesmal in Version 6.7 CU3, angeblich weil der Speicher nicht zuverlässig war. Speicherbank 2. Aber warum Bank 2 wenn das gesamte Geschehen auf Bank 0 passiert ist? Bank 0 hat 32 GB, der Termianlserver aber nur 16 zugewiesen gehabt

Also mal wieder eine Unverträglichkeit vom ESXI mit aktuellen Ständen von Windows. Schad eigentlich... schon vorher hatte ich mit Windows 10 Ärger. Stand 1909, und wenn der mal in den Energiesparzustand geht, dann kann VMware den Host nicht mehr neu starten. Also mal wieder Updates besorgen und hochpatchen.

Die RDP Geschichte hat noch einen Bug zutage gefördert. Der Sessionhost weiß nicht so sein Lizenzserver ist. Ist ja schön daß MS ein halbautomatisches Einrichten von RD Farmen hat, aber es bleibt Handarbeit übrig. Aber das ist eher Kinderkram, den meine Tochter wohl erledigen kann wenn sie mal Lesen, Schreiben und Serverlogins gelernt hat. Aktuell ist sie noch etwas auf Abwegen, eins zwei dei paßt zwar zu TLC Speicher, aber im Ram sind ja nur Nullen und Einsen.