Synology Directory Server | Passwort beim Zugriff auf ein Netzlaufwerk

image

An dieser Stelle möchte ich auf den vielleicht wichtigsten Artikel im Synology Knowledge Center hinweisen Smile

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Es geht hier um eine nicht korrekte Auswertung von Gruppenmitgliedschaften beim Zugriff auf ein Netzlaufwerk.

Technischer Hintergrund

Einem Benutzer in der Domain wird über ein Anmeldeskript (login.cmd) ein neues Netzlaufwerk verbunden. Die Vergabe der Berechtigungen dazu erfolgt relativ einfach indem der Benutzer Mitglied in einer dafür erstellen Gruppe in der Domain wird. Diese Gruppe hat wiederum entsprechende Berechtigungen auf dem Netzlaufwerk.

  • Sepp (Benutzer) – Mitglied in der Gruppe “_ SN Immobilien Users”
  • Die Gruppe “_ SN Immobilien Users” hat R/W-Zugriff auf den Share \\sn-nas-15\immo

Das Problem

Für das neue Netzlaufwerk, muss auf einmal im Fenster des Anmeldeskript ein Passwort angegeben werden, das funktionale Passwort von Sepp wird hier aber nicht akzeptiert. Es bleibt nur die Möglichkeit das Fenster zu schließen und damit die darauffolgenden Maßnahmen (weitere Laufwerke usw.) abzubrechen.

Das erwartete Verhalten wäre, dass Sepp durch seine Mitgliedschaft in der Gruppe “_ SN Immobilien Users” die entsprechenden Berechtigungen auf dem Netzlaufwerk besitzt. Durch seine neue Anmeldung, wird der Security-Token neu erstellt und die (neue) Gruppen-Mitgliedschaft fließt in diesen mit ein.

Die Lösung

Auf dem Synology NAS müssen die folgenden beiden Änderungen durchgeführt werden.image

https://kb.synology.com/en-id/DSM/tutorial/domain_user_not_get_group_permission

Der Windows Client muss wie folgt behandelt werden, wobei bei mir ein Neustart genügte.

image

Danach war das Netzlaufwerk über die passende Gruppenmitgliedschaft im Zugriff.

Enjoy it, b!

Synology Directory Server | Hyper-V Replica schlägt fehl–Kerberos Fehler

Ich arbeite bei kleinen Projekten gerne mit dem Synology Directory Server als Ersatz für das Microsoft Active Directory (AD). Bei ein paar Benutzern, lassen sich hier doch einige Kosten sparen. Nun kommt aber auch dort gelegentlich die Anforderung eine Virtuelle Maschine (VM) hochverfügbar bereitzustellen. Dafür habe ich bisher immer den Microsoft Hyper-V Server (2019) in Verbindung mit der Hyper-V Replica verwendet.

Das klassische Setup, hat auch bis zur Aktivierung der Hyper-V Replication problemlos funktioniert.

  • Join der beiden Hyper-V Hosts in die Domain des Synology Directory Servers
  • Öffnen der Firewall auf den Hyper-V Hosts um über Port 80 der 443 zu replizieren
  • Verwendung der Kerberos Authentifizierung (HTTP) für die Replikation
  • Einrichten der Hyper-V Replica für eine oder zwei VMs

Allerdings wurde ich am Ende der Konfiguration mit dieser Fehlermeldung konfrontiert und konnte auf Anhieb nichts damit anfangen.

image

Ja klar, es gibt ein Problem mit Kerberos … aber wieso?

Die Namensauflösung funktionierte und auch die ServicePrincipalNames sind registriert.

image

Auch die Ports 80 und 443 sind über die Firewall geöffnet und antworten wie erwartet.

Mein Verdacht fiel nach einiger Zeit auf dem Synology Directory Server, dieser stellt quasi eine Domain mit dem folgendem Functional-Level bereit.

  • Domain functional level: Equal to Windows Server 2008 R2

Die Hyper-V Replica wurde mit Windows Server 2012 vorgestellt, was aber nicht zwingend heißen muss, dass die Domain ebenfalls auf diesem Level sein muss. Ich denke aber das darin und vielleicht in Verbindung mit der Tatsache, dass hier eigentlich Samba 4.10 läuft, hier das Problem liegen könnte.

Als Alternative wollte ich die Authentifizierung per Zertifikat verwenden.

image

Dabei bin ich über eine Reihe von Herausforderungen gestolpert, die sich aber letztendlich lösen ließen. Als Grundlage habe ich diese Anleitung verwendet, die aber nur mit kleineren Modifikationen funktionierte.

Ein wichtiger Unterschied ist auf jeden Fall, dass meine beiden Hyper-V Hosts in der Domain verbleiben sollen, also nicht in einer Workgroup betrieben werden.

  • Insgesamt werden n+1 (N = Anzahl der Hyper-V Hosts die an der Replikation teilnehmen) Zertifikate erstellt. Für jeden Hyper-V Host eines (das Server-Zertifikat) und das Root-Zertifikat. Bei zwei Hosts, haben wir damit drei Zertifikate
  • Während das Root-Zertifikat auf jedem der Hyper-V Hosts installiert wird, bekommt jeder Host ein eigenes Server-Zertifikat

Auf dem ersten Knoten wird eine PowerShell-Sitzung als Administrator gestartet und dazu die folgenden Variabel angelegt.

image

Danach wird das Root-Zertifikat erstellt. Dazu habe ich die folgenden Punkte geändert (Zeile 26).

  • KeyUsage CertSign  in
  • KeyUsage CertSign, CRLSign, DigitalSignature

Darüber hinaus in Zeile 27

  • KeyLength 2056 in
  • KeyLength 4096

image

Der Server auf dem das Root-Zertifikat erstellen, muss diesem ebenfalls vertrauen. Darum wird das Zertifikat von Personal nach Trusted Root Certification Authorities kopiert.

image

Nun wird auf demselben Knoten sowohl das Root-Zertifikat exportiert als auch die Server-Zertifikate erstellt.

image

Auch bei der Erstellung der Server-Zertifikaten habe ich ein paar Änderungen vorgenommen.

Hinzufügen eines weiteren Parameters (Zeile 64), wobei ich dazu (Zeile 60) den FQDN erstelle

  • DnsName $fqdn, $name
  • KeyLength 4096

image

Auf allen Hyper-V Hosts muss nun die Prüfung der Zertifikate abgeschaltet werden.

image

Nun werden die Zertifikate auf die anderen Knoten (hier nur einer) verteilt.

image

Kleiner Tipp, der “\” am Ende des Pfads erstellt das Verzeichnis automatisch.

Nun wird auf dem 2ten Knoten sowohl das Root- als auch der Server-Zertifikat importiert

image

Das sieht dann auf jedem Hyper-V Host wie folgt aus.

image

image

So, damit sollte die Hyper-V Replikation eigentlich funktionieren, was aber nicht der Fall war. Zusätzlich zur certificate-based Authentification (HTTPS), musste ich auch noch die Verwendung von Kerberos (HTTP) aktivieren! Warum, kann ich nicht genau sagen und muss hier nochmals mit einem Netzwerk-Trace der Sache auf den Grund gehen.

image

Mit dieser Konfiguration funktioniert nun die Hyper-V Replikation auch mit Hyper-V Hosts die in einer Samba-Domain und dem Synology Directory Server Mitglied sind.

Enjoy it, b!

PowerShell Convert UNIX to DOS

Leider läuft Notepad++ auf Windows Server Core nicht mehr zuverlässig und so habe ich mich auf die Suche nach Alternativen gemacht und auch eine gefunden. Nun verwende ich seit geraumer Zeit Micro (a modern and intuitive terminal-based text editor).

Allerdings habe ich gelegentlich ein Problem mit der Darstellung und Verarbeitung von Dateien die unter UNIX / Linux abgespeichert wurden.

image

Damit diese problemlos bearbeitet werden können, konvertiere ich sie mit dem folgendem Einzeiler in PowerShell in das ASCII-Format.

Get-Content -Path .\vm-export-v029.ps1 | Out-File -Encoding ascii .\vm-export-v029.txt

Danach öffnet Micro die konvertierte Datei problemlos.

image

Enjoy it, b!

Drucker im Active Directory (AD)

Löscht man einen Drucker, der auch über das Active Directory (AD) gelistet war kann es vorkommen das dieser nach dem Löschen weiterhin angezeigt wird. Richtet sich dann ein Benutzer neue Drucker ein wird dieser, schon gelöschte und damit nicht mehr vorhandene Drucker, erneut angeboten.

image

Damit stellt sich die Frage, wo den der Drucker im Active Directory noch vorhanden ist und wie er entfernt werden kann.

Der Drucker ist über den Server im AD zu finden, auf dem er bereitgestellt wurde. Diese Information muss also noch vorhanden sein. Zur Anzeige aktiviert man Users, Contacts, Groups, and Computers as containers und findet damit unter dem Computer Objekt des Servers die von ihm bereitgestellten Drucker.

image

Das Drucker Objekt, kann dann mit einem Rechtsklick und Delete gelöscht werden.

image

image

Danach ist man den Drucker wirklich los.

Enjoy it, b!

Windows 11 | SYSTEM_THREAD_EXECPTION_NOT_HANDLED

So sollte ein Tag nicht beginnen.

IMG_20220630_063001_ON1_Cloud

Mein Lenovo P1 ist heute genau drei Jahre im Betrieb und ich kann in dieser Zeit auf insgesamt 10 BSODs (Stopp-Fehler) zurück blicken, dass waren einige mehr als ich mit meinen Microsoft Surface Book 2 (insgesamt vier) hatte. Nun könnte man von mangelnder Qualität bei Lenovo sprechen, was ich aber so nicht unterschreiben werde, denn alle der 10 Fehler hat mehr oder weniger mit der im Notebook verbauten Nvidia Grafikkarten zu tun.

Im Gegensatz zu früheren BSODs, wo eindeutig ein Nvidia-Treiber auf dem Stack zu sehen war, hat dieses Mal der DirectX Graphics MMS den BSOD verursacht und damit könnte der Fehler im Betriebssystem direkt zu suchen sein.

image

Der erste Blick in dem korrekt geschriebenen Dump mit dem Debugger ( !analyze –v) zeigte zumindest den Stop-Code (7E) und die lapidare Meldung, dass dieser Fehler wohl des Öfteren auftaucht. Auch der Treiber kann über den Dump zweifelsfrei dem Betriebssystem zugeordnet werden.

image

Trotzdem tat ich mich schwer, die eigentliche Ursache zu finden. Ein ganz guter Punkt zum suchen ist der folgende Link bei Microsoft, wo die Bug Check Code Reference zu sehen ist.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-code-reference2

Von dort geht es weiter zum eigentlichen Code dem 7E, der in insgesamt drei Varianten hier beschrieben ist.

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x7e–system-thread-exception-not-handled

Ich hatte die Exception 0xC0000005, eine Zugriffsverletzung oder auch Access Denied

  • 0xC0000005: STATUS_ACCESS_VIOLATION indicates a memory access violation occurred

Letztendlich hat mich die Analyse nicht weitergebracht, aber immerhin den Hinweis darauf gegeben, dass ein Problem im Bereich der Grafiktreiber vorhanden sein könnte. Was mich wiederum zu einer holistischen Suche nach “dxgmms2.sys blue screen nvidia” verlasst hat und mir nicht wenige Einträge im NVIDIA Forum offenbarte.

Meine bisher abschließende Lösung ist damit, den NVIDIA Treiber zu aktualisieren.

image

Enjoy it, b!

Microsoft Surface Laptop Rubber Feed Replacement

Sollte bei einem Microsoft Surface Laptop 3 (oder auch 4) einer der Gummifüße abgehen, gibt es zwei Möglichkeiten das Problem zu beheben.

IMG_20220624_111150_ON1

DYI – Pattex tuts auch

Ist der Gummifuß noch vorhanden, kann man ihn mit Pattex oder Uhu wieder festkleben. Dazu habe ich das Loch und den Gummifuß mit Isopropropanol gereinigt. Den Pattex-Kleber sowohl auf den Rand des Lochs und auf den Gummifuß aufgetragen, trocken lassen und dann wieder verklebt.

Bisher hält dieser ohne Probleme. Zum Reparaturprozess noch ein paar Gedanken und Informationen.

  • Mit dem Isopropropanol bin ich beim Gummifuß sehr vorsichtig gewesen um ein Aushärten zu verhindern.
  • Die Wahl viel auf Pattex, bzw. Uhu da im Gegensatz zu Sekundenkleber dieser sich nicht in dem Bohrloch verteilt und ein Lösen der Schraube des Unterbodens verhindert und unmöglich macht. Der Pattex lässt sich hier relativ einfach wieder entfernen.

Neues “Food-Replacement” vom Hersteller

Ja, sowas gibt es. Bei Microsoft scheint das Problem wohl bekannt zu sein und der Hersteller bietet darum die Möglichkeit vier dieser Gummifüße nachzubestellen. Überraschend, für recht kleines Geld. Ich habe dafür 4 Euro bezahlt (alle 4 Füße zusammen). Ich schreibe überraschend aus dem Grund, da ich von Ersatzteilen aus dem Obstgarten andere Preise gewohnt bin oder man die reguläre Beschaffung generell verweigert.

Allerdings haben die Götter vor den Erfolg den Schweiß gesetzt und man muss wissen wie man an dieses Ersatzteil kommt.

Spätestens jetzt ist der Punkt gekommen, an dem man sein Surface Laptop bei Microsoft registrieren sollte. Ist das erfolgt, kann durch das Öffnen eines Support-Request die Bestellung ausgelöst werden. Aber auch hier ist auf die eine oder andere Kleinigkeit zu achten, die ich in den folgenden Schritten beschreiben werde.

  1. Registrierung des Surface Laptops unter dem folgendem Link https://account.microsoft.com/devices falls das schon geschehen ist, einfach den Link öffnen um von dort den Support-Request zu öffnen.

    image

    ddd

  2. Im nun folgenden Service-Dialog, die folgenden Optionen auswählen
    Kategorie = Accessory
    Problemtyp = Div
    Ausführliche Beschreibung des Problems | Rubber Feed replacement


    image

    Darauf erkennt der Dialog, dass neue Gummifüße notwendig sind, prüft die Adresse und bietet einem die passende Farbe zur Auswahl an

  3. Abhängig von der Farbe des Laptops, hier zwischen Black, Cobalt Blue, Platinum und Sandstone auswählen

    image

    und mit Weiter bestätigen.

  4. Zum Versand sind keine weiteren Maßnahmen erforderlich

    image

    und die Bezahlung erfolgt über die hinterlegte Kreditkarte. Ab jetzt ist der Prozess vollends selbst erklärend.

  5. Im Vorfeld ist es sinnvoll, zu prüfen ob die hinterlegte Kreditkarte noch gültig ist und hier ggf. die Daten zu aktualisieren
  6. Microsoft versendet im Anschluss eine Bestellbestätigung an die im Microsoft Konto hinterlegte Mail-Adresse

Final

Ich habe mir natürlich die Frage gestellt, wieso genau bei einem von insgesamt sechs mir bekannten Microsoft Surface Laptop Geräten der Gummifuß sich gelöst hat, aber nicht bei den anderen. Die Erklärung liegt in dem Arbeitsumfeld des Benutzers. Der Surface Device steht dort häufig auf einem Holz-, bzw. auf einem Labortisch und wird dort öfters verschoben. Die Füße haften dabei wohl relativ stark an den Tischplatten, was zu ihr Abnutzung und Ablösung führt.

Enjoy it, b!

Synology DS | Ausführen von WSUS Offline Update unter Docker

Auf dem Windows Small Business Essentials war bei mir immer der WSUS zur Aktualisierung der Server und Clients installiert. Das hat immer ganz gut funktioniert und ja ich gebe zu, es gab hier auf meinem Blog den einen oder anderen Artikel, der sich nicht immer positiv gegenüber dem WSUS gezeigt hat. Aber, letztendlich habe auch immer versucht eine Lösung zu meinem WSUS-Problem zu liefern.

Wird im Netzwerk, als Datenspeicher nur ein NAS, wie zum Beispiel eine Synology Diskstation (DS) verwendet, fehlt erst einmal die Möglichkeit einen WSUS zu betreiben und damit auch das zentrale Update der Server und Clients.
Schon seit langer Zeit habe ich zusätzlich zum WSUS für die Server gerne das WSUS Offline Update verwendet, welches wiederum als Community Edition (CE) auf GitLab verfügbar ist. Darüber hinaus existiert auf GitHub ein Docker Image, mit dem wiederum WSUS Offline Update in einem Docker Container ausgeführt werden kann.

Wie man so etwas angeht, soll dieser Beitrag beschreiben.

Voraussetzungen

  • Synology Disk Station mit der Unterstützung von Docker als Container Host
  • Das aus dem Synology Paket Zentrum installierte Docker-Paket

    image

  • Auf der Diskstation muss nun noch eine Freigabe erstellt werden, mit den folgenden Rechten und Eigenschaften

    image

    Ob man die Freigabe in der Netzwerkumgebung verstecken will oder nicht ist Geschmackssache, ich blende den Ordner immer aus, wenn die Installation der Updates exklusiv durch einen Admin oder automatisiert erfolgt und damit die Benutzer ihn nicht sehen sollen.
    Wird hingegen die Installation der Updates den Benutzern überlassen, dann sollte der Ordner eingeblendet werden.
    Darüber hinaus aktiviere ich die folgenden beiden Erweiterte Einstellungen

    image

    Dazu gebe ich der lokalen Gruppe users das Leserecht (Schreibgeschützt) und den Domain-Users ebenfalls.

    image

    Die Admins (lokal und Domain-Admins) haben ja per Default Lesen/Schreiben als Zugriffsrecht gesetzt.
    Dieser Ordner, also wsusoffline wird später in den Docker Container abgebildet.

Installation des Docker-Images

Nach der Installation von Docker, wird dieser gestartet, um das Image aus der Docker Registry herunterzuladen.

Dazu einfach ins Suchfeld R0gger (das ist der Entwickler des Images, 0 = Null) eingeben und Download klicken.

image

Wichtig ist hier die Auswahl der Community Edition (ce) um die aktuellste Version zu erhalten.

image

Die CE mit Auswählen bestätigen und der Download startet. Unter Image erscheint danach die 1, was den Download von einem Image signalisiert der nach ca. 250MB abgeschlossen ist.image

Konfiguration des Docker-Images

Durch einen Klick auf Starten wird das Docker-Image gestartet und dazu der Dialog zur Konfiguration aufgerufen.

Als Netzwerk verwenden wir die bridge und klicken auf Weiter.

image

Neben einem Automatischen Neustart, sind die Erweiterte Einstellungen interessant.

image

In den erweiterten Einstellungen werden die Laufzeit-Variablen für den Container festgelegt, Änderungen führe ich hier nur an den folgenden Variablen durch:

  • SYSTEM = w100-x64, w63-x64
  • OFFICE – löschen der Variabel, einfach aus dem Grund da alle meine Clients auf Microsoft365 laufen und die Updates aus der Cloud bekommen. Den Speicherplatz spare ich mir damit

image

Mit Speichern und Weiter, geht es dann weiter, wobei wir die Port-Einstellungen zu belassen wie sie sind und nur die Volume-Einstellungen konfigurieren müssen. Dort wird der Inhalt des Docker-Containers in die oben erstellte Freigabe wsusoffline gemounted.

image

  • wsusoffline = /wsus/wsusoffline

Mit dem Klick auf Weiter sind wir fertig und können den Container im Anschluss ausführen.

image

Running the Docker-Image

Damit kommen wir zum spannenden Teil, woher wissen wir eigentlich genau, ob wir alles richtig gemacht haben?

Läuft der Container, dann bietet uns die Option Details einen umfassenden Einblick was im Container vor sich geht.

image

Dort sind unter anderem der Ressourcen-Verbrauch, dass Mapping des Update-Ordners (wsusoffline) und die Laufzeitvariablen zu sehen.

image

Zwei weitere Punkte will ich hier nicht unerwähnt lassen. Zum einen habe ich mich schwergetan herauszufinden, wie den der Pfad lautet auf den der wsusoffline-Ordner gemapped werden soll?

Diesen habe ich in einer Terminal-Session ermittelt, dazu einfach unter Terminal eine Sitzung mit der Bash öffnen und nach dem Verzeichnis wsus im Root suchen.

image

Dort, also unter /wsus/wsusoffline werden die Updates gespeichert und dieser Ordner wiederum auf den wsusoffline-Ordner des NAS abgebildet, um den Zugriff über SMB zu ermöglichen.

Zuletzt habe ich noch mit einer Fehlermeldung gekämpft, und hierzu ein Paket (JSON-Processor) nachinstallieren müssen. Das geht ebenfalls in der Terminal-Session über die beiden folgenden Befehle.

# Installation des Pakets für die JSON-Interpretation
apt-get update
apt-get install jq

So, damit bin ich erstmal fertig und habe einen weiteren Schritt für eine alternative zum SBE beschrieben.

Enjoy it, b!

racknex nextmount AVM 004

oder

yep, I did it again

(Hinweis: Das ist Werbung, die keine ist. Der Rackmount wurde regulär gekauft und ich stehe in keiner Verbindung zum Hersteller, dieses zugegebener Maßen genialen Produkts.)

FRITZ!Box 6660 Cable Rackmount Kit 19 inch

Credits und Copyright liegen bei racknex

Intro

So um oder kurz nach dem Jahrtausend-Wechsel wurden in meinem Umfeld viele Häuser gebaut. Mein Ratschlag, der heute immer noch gilt, war und ist “leg in jeden Raum mindestens 2 LAN-Kabel” und führe diese an einem zentralen Punkt in einem kleinen 19” Verteiler zusammen. Die meisten haben mich dafür belächelt, andere nicht für voll genommen. Spätestens Corona hat uns vor Augen geführt, was Bandbreite beim Internet-Anschluss bedeutet, wenn vier von fünf Familienmitgliedern parallel an verschiedenen Teams- oder Zoom-Meetings mit eingeschalteter Kamera teilnehmen. Zum einen war und ist man froh, wenn man einen fetten Internet-Tarif gebucht hatte und darüber hinaus die Bandbreite auch in die Kinderzimmer verteilen konnte. Ist dann vielleicht doch ein 19” Verteiler mit hinreichender Bautiefe im Haus, spricht nichts dagegen die FRITZ!Box in diesen hinein zu verfrachten, was mit einem racknex nextmount sehr elegant möglich ist.

Den Einwand, dass so ein 19” Verteiler die Sendeleistung der FRITZ!Box einschränkt lasse ich gerne zu. In diesem Fall, wurde lediglich das brachiale Internet vom 1GBit/s in der Waschküche eingeschränkt, den Rest trugen schon davor die Betonwände und die Stahlbetondecke bei (darum, der Tipp mit den Kabeln Smile )

Die FRITZ!Box 6660 Cable geht ins Rack

Untergebracht habe ich die FRITZ!Box 6660 Cable im racknex NM-AVM-004 und dieses Mal auch gleich den passenden Kabelsatz dazu bestellt.

IMG_20220527_152339_ON1_Cloud

Der Einbau dauerte 15min, wobei die Herausforderungen eher im schon recht vollen Verteiler, denn im Rackmount lagen.

IMG_20220527_154349_ON1_Cloud

Das sieht mal wieder sehr ordentlich aus, das Koaxial-Kabel von Vodafone habe ich direkt hinten angeschlossen, der Grund dafür war das ich es (um die Türe des Verteilers zu schließen) mit einem Winkelstecker hätte versorgen müssen. Die Hochfrequenztechniker unter uns wissen das, bei einem “Winkelstecker kotzt die Welle an jeder Ecke 2x” (Professor Käß Smile).
Alle anderen Gerätschaften wurden dann vorne angeschlossen, auf Port 1 (LAN1) konnte ich sogar einen AVM FRITZ!Repeater 6000 mit 2,5 GBit/s direkt vom Patchfeld anschließen. LAN2 war dann die Verbindung zum Switch und FON1 wurde mit dem Fax verbunden (alles über das nicht im Bild oben sichtbaren Patchfeld).

Wirklich geschickt am Rackmount wurde der gelegentlich notwendige Zugriff auf die Tasten der FRITZ!Box gelöst, diese sind von vorne gut erreichbar. Was zum Beispiel eine Kopplung per WPS recht einfach macht.

Zum Ende will ich nochmals zur Waschküche, genauer gesagt zum WLAN was ich in den Verteiler eingesperrt habe, zurückkommen. Um die Dämpfung des Verteilers zu umgehen, besteht die Möglichkeit die FRITZ!Box 6660 Cable mit einem FRIXTENDER auszustatten und dessen Anschluss (2 Stück sind hier möglich) nach außen durch das Rack zu führen und damit die Antennen außerhalb des Racks zu positionieren. Dazu muss aber bei der Bestellung des Rackmount diese Option zusätzlich gewählt werden.

image

Wer so etwas plant sollte sich über die Frage der Garantie und Gewährleistung im klaren sein. Diese würde mir bei einer gekauften FRITZ!Box weniger sorgen machen, bei einer vom Provider “geliehenen” sehe ich hier das eine oder andere rechtliche Problem.

Enjoy it, b!

We lost remotewebaccess.com …

Update 14.05.2022:
Seit dem letzten Samstag (14.05.2022) ist remotewebaccess.com wieder funktional. Wer während des „Offline“ sein RWA auf dem SBE nicht kaputt konfiguriert hat, sollte wieder eine korrekte Aktualisierung der Domain sehen und Zugriff darauf haben.

Eigentlicher Blog
Seit dem 01. Mai 2022 funktioniert remotewebaccess.com nicht mehr zuverlässig. Alle die nicht wissen, was https://<hostname>.remotewebaccess.com ist oder war, brauchen hier nicht weiterzulesen.

Der Windows Server SBE (Small Business Essentials) bietet ein Feature mit dem der Zugriff auf den Arbeitsplatz innerhalb der Firma über eine Webseite, wie z.B. https://sbsland.remotewebaccess.com/remote möglich ist. Damit das Mapping von aktueller IP-Adresse des Internet-Zugangs und remotewebaccess.com funktioniert, steckt dahinter ein DynDns-Mechanismus, der über ein Zertifikat abgesichert ist, was wiederum den Zugriff mit HTTPS und damit ohne Fehlermeldungen im Browser ermöglicht.

Das Problem wird durch die folgenden Meldungen protokolliert:

image

Windows Logs / Application and Services Logs / Microsoft / Windows / ServerEssentials / Admin

image

Da zumindest auf meinen SBE-Servern alle Zertifikate in Ordnung sind, vermute ich das der Server selbst ein Problem hat den Dienst der hinter remotewebaccess.com steht zu erreichen.

Betroffen sind von dem Problem alle, die diesen Dienst nutzen. Die Auswirkungen sind aber nur im Fall einer Änderung der IP-Adresse spürbar. Kunden mit einer festen IP vom Provider sehen dieses Problem nicht. Es sei denn, sie bekommen einen neuen Internet-Tarif und in diesem Zusammenhang auch eine neue feste IP. Dann versucht der SBE die neue IP zu aktualisieren, was ebenfalls fehlschlägt.

Ich gehe mal davon aus, dass die meisten Nutzer des SBE diesen noch auf Basis des Windows Server 2012 R2 betreiben, was zumindest bei mir die Mehrheit ist. Wenig sind noch mit dem Windows Server 2016 unterwegs. Beide Produkte sind inzwischen aus dem Mainstreamsupport draußen und besitzen nur noch den erweiterten Support. Darum sollten wir uns auch über einen Call bei Microsoft bzw. dem OEM keine Hoffnung machen, sondern müssen über Alternativen nachdenken. Was der Aufbau von VPN-Zugängen sein kann.

Bisher habe ich meine VPN-Zugänge ausschließlich mit Lancom oder dem Synology VPN-Server realisiert und muss sagen, dass beides sehr gut und zuverlässig funktioniert.

Wie sehen den bei Euch die Alternativen aus?

Enjoy it, b!

Hyper-V 18560, Triple Fault

Es gibt Probleme, die erwischen einen auf dem falschen Fuß. Während der Einführung und Konfiguration von Synology Active Backup for Business musste ich feststellen, dass eine wichtige VM noch auf einem Windows Server 2012 R2 Hyper-V Host lief. Das tat sie seit Jahren sehr zuverlässig und vfel damit in die Kategorie “never touch a running system …”

Synology Active Backup for Business benötigt aber mindestens die Hyper-V Version 6 der VM oder besser und damit einen Hyper-V Host der mindestens mit Windows Server 2016 oder höher läuft. Damit war notgedrungen eine Neuinstallation des Servers notwendig, da ich in diesem Fall auf den kostenlosen Microsoft Hyper-V Server 2019 zurückgreifen wollte.

Vor dem Upgrade dachte ich mir das bestimmt ein Updates des BIOS sinnvoll wäre, das auf dem Server verwendete war von 2014 und Supermicro hat für dieses Board nochmals 2021 ein neues BIOS bereitgestellt. Damit also zuerst den Microsoft Hyper-V Server 2019 installiert und gleich im Anschluss das BIOS aktualisiert. Für den Server war das eine so große Neuerung, dass er mir den konfigurierten SET weggeworfen hat und den Ethernet-Adapter 2 als Nummer 3 präsentierte. Kein Thema, ließ sich alles fixen.

Der Import der einzigen darauf verbliebenen VM (die zwar Generation 2, aber mit Version 5.0 lief) funktionierte funktionierte ebenfalls ohne Probleme, aber der Start wollte nicht gelingen und nach ca. 2min befand sich die VM wieder im ausgeschalteten Zustand.

Zuerst hatte ich das BIOS im Verdacht, aber eine neu eingerichtete VM mal schnell mit OpenSuse installiert, funktionierte ohne Probleme und auch die Hyper-V Replika zu dem anderen Windows Server 2019 Hyper-V Host lief ohne Probleme. Was also tun?

Ein Blick in das Eventlog offenbarte die beiden folgenden Events.

Critical 03/18/2022 20:13:12 Hyper-V-Worker 18604 None
'mt-app-1' has encountered a fatal error but a memory dump could not be generated. Error 0x2. If the problem persists, contact
Product Support for the guest operating system. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447B)
Critical 03/18/2022 20:13:12 Hyper-V-Worker 18560 None
'mt-app-1' was reset because an unrecoverable error occurred on a virtual processor that caused a triple fault. If the problem persists,
contact Product Support. (Virtual machine ID 0FDEE7BD-2627-4EC8-BE76-5EDF093B447A)

Der Fehler wurde zwar schon 2019 mit dem Update KB4497934 behoben, dass hatte aber noch nicht den Weg auf den neu installierten Hyper-V Host gefunden und damit musste ich auf den Workaround zur  Änderung des MAC Address Ranges greifen, was mit einem Aufruf in PowerShell recht einfach funktioniert.

Die folgende Abbildung zeigt den alten Adress-Bereich.

image

Für die Änderung muss man wissen wie eine MAC-Adresse überhaupt aufgebaut ist. Die ersten drei Oktette, also 11-22-33 oder in diesem Fall 00-15-5D sind dem jeweiligem Hardware-Hersteller zugeordnet, hier also Microsoft. Wenn nun der Bereich geändert werden soll, ist es am einfachsten das 4te Oktett zu inkrementieren.

# Anzeigen des aktuellen MAC-Adress Pools auf dem Hyper-V Host
Get-VMHost | Select ComputerName, MacAddressMinimum, MacAddressMaximum | ft
# Konfiguration eines neuen MAC-Adress Bereichs auf dem Hyper-V Host, das 4te Oktett wurde von 23 auf 24 geändert
Set-VMHost -MacAddressMinimum 00155D24AE00 -MacAddressMaximum 00155D24AEFF

Danach habe ich der VM den Netzwerk-Adapter entfernt und im Anschluss gleich wieder reinkonfiguriert. Danach startete mein Sorgenkind ohne Probleme.

Enjoy it, b!