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!