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!