Windows SBE remotewebaccess.com Update schlägt fehlt

Mit dem Beginn dieser Woche (KW11/2021) waren einige meiner auf Windows Server 2012R2 basierenden Small Business Essential Server nicht mehr in der Lage ihre für den Anywhere-Access notwendige Sub-Domain unter remotewebaccess.com zu aktualisieren. Genau genommen betrifft das Problem alle SBE, aber manche haben eine statische IP-Adresse und was sich nicht ändert, muss man auch nicht aktualisieren. Die Problem-Kandidaten waren also Kunden (Telekom- und 1&1 ) die täglich eine neue dynamische IPv4-Adresse vom Provider bekommen.
image

Damit klappte natürlich auch der Zugang auf https://sbe.remotewebaccess.com/remote nicht mehr. Da hinter dem Zugang über remotewebaccess.com ein Zertifikat steckt, hat auch ein Zugang über “nur” die IP nicht gut funktioniert.

Das Fehlerbild war dubios, bis ich die Idee hatte das möglicher Weise der auf dem SBE laufende Update Client ein Problem mit der Verschlüsselung haben könnte. Stichwort TLS 1.0, TLS 1.1 Deaktivierung durch Microsoft.

Wenn man einen Blick auf die Release Documentation for Windows Server Essentials wirft, findet man zum eine Aktualisierung von 10.03.2021 …

image

… und dazu den folgenden Absatz.

image

Auch der Windows Server Essentials soll TLS 1.2 nutzen, Nach diesem Absatz dachte ich, OK – das ist es nicht, der Windows Server 2012R2 und neuer verwenden automatisch TLS.

image

Diese Aussage trifft zwar auf den Windows Server selbst zu, aber für das .Net Framework war dennoch ein wenig Nacharbeit notwendig und damit war ich auch auf die Lösung des Problems gestoßen.

Für beide auf dem Server installierten .Net Versionen (v2.0.50727 und v4.0.30319) mussten die folgenden Einträge in die Registry zusätzlich eingetragen werden.

# 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001
# 32-bit Applications running on 64-bit OS
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions" = dword:00000001
"SchUseStrongCrypto" = dword:00000001

Mit PowerShell geht das sehr einfach die Befehle müssen als Administrator in PowerShell (elevated Session) ausgeführt werden.

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SystemDefaultTlsVersions" -Value 1 -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWORD -Force

Danach noch den Server neu starten (Restart-Computer).

Update 20.03.2021
Für den Windows Server 2012 (OHNE R2) sind neben den oben beschriebenen Einträgen noch die folgenden Keys in der Registry zu setzen

# PowerShell
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force
New-ItemProperty -Path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp" -Name "DefaultSecureProtocols" -Value '0xAA0' -PropertyType DWORD -Force

Microsoft bietet hier auch ein eigene Lösung an um den Fix zu installieren. Dazu gibt es weitere Infos hier.

Update 22.03.2021
Das Problem tritt natürlich auch auf dem Windows Server 2016 SBE auf, und kann mit den gleichen Einträgen in der Registry wie für Windows Server 2012R2 behoben werden.

image

Die Abbildung oben zeigt den Fehler des Update-Mechanismus auch im Windows Eventlog unter Microsoft-Windows-ServerEssentials/Admin.

Enjoy it, b!

30 Gedanken zu „Windows SBE remotewebaccess.com Update schlägt fehlt

    • Hallo Ralph
      Die Frage ist ehrlich gesagt nicht einfach zu beantworten.
      Generell ist wichtig, dass alle PowerShell-Befehle in einer PowerShell-Sitzung mit Admin-Rechten ausgeführt werden. Also PowerShell mit einem Rechtsklick und „ausführen als Administrator“ gestartet wurde.

      Falls Du Dir hier nicht sicher bist, würde ich mich an Euren Dienstleister / Administrator wenden. Irgendjemand hat den SBE wahrscheinlich mal installiert oder nicht?

      Viel Erfolg, b!

      • Danke, aber da mein Administrator und bester Freund leider gestorben ist, habe ich niemanden, der mir da wirklich helfen könnte. Ob es eine Firma gibt, der man sich mit diesem heiklen Problem anvertrauen kann, vermag ich nicht zu sagen.
        Da ich ohne Reparatur (Windows Server 2012 R2) weder meine lokale Website bearbeiten, geschweige denn überhaupt erreichen kann, ist dann der Server für mich unbrauchbar geworden. Alles funktionierte noch Anfabg des Jahres. Da ich selbst nichts geändert habe, muß das Problem an Windows liegen.
        Die Powershell-Befehle sind auch alle mit ADMIN-Rechten eingerichtet und funktionierten auch tadellos bis Januar 2021.
        Schade, wenn das so schwierig ist, muß ich darauf wohl gänzlich verzichten.
        Aber danke für den Hinweis.
        Ralph

  1. Vielen Dank. Ich habe zwei Monate lang versucht, dies mit Windows Server 2016 Essentials zu beheben, und habe keine Fortschritte gemacht. Heute Nacht ist es behoben.

      • Schön, das es bei Dir geklappt hat. Könntest Du mir vielleicht verraten, wie Du es geschafft hast? Ich habe zwar Windows Server 2012 R2, aber vielleicht ist da das Problem ähnlich?

      • Hallo Ralph, magst Du mit mir direkt Kontakt aufnehmen? E-Mail findest Du in der „Datenschutzerklärung“ oder unter „About“ meines Blogs.

        Grüße, b!

  2. Pingback: Windows Server Essentials Computer Backup Service funktioniert nicht (mehr) | Windows SBS and Essentials Blog

  3. Das hat bei mir letztes Jahr auf dem 2012R2 auch prima funktioniert. Seitdem keine Probleme mehr bis heute. Nun wieder genau dasselbe Problem, obwohl alle registry-Schlüssel eingetragen sind. Bin ich der einzige oder geht es anderen genauso?

    • Ich persönlich glaube, dass diesesmal das Problem nicht auf dem Server sondern beim DynDns-Service (remotewebaccess.com) von Microsoft liegt.

  4. Hallo,
    leider tritt das DNS Problem mit xxx.remotewebaccess.com wieder auf.
    Der fix mit dem PowerShell funktioniert diesmal leider nicht.
    Haben das eventuell auch andere? Weiß schon wer an was es liegt usw.
    Gruß und Danke, Predy

    • Ich persönlich glaube, dass diesesmal das Problem nicht auf dem Server sondern beim DynDns-Service (remotewebaccess.com) von Microsoft liegt.

  5. Selber Problem hier,
    seit 02.05.2022 wird die IP-Adresse nicht mehr aktualisiert.
    Im Log steht immer das ich immer noch die öffentliche IP-Adresse vom 01.05 habe, obwohl die sich mehrfach geändert hat.

    Ich hoffe das es nur ein Problem bei Microsoft ist, da ich auch keine neue Domain mehr registrieren kann.

  6. Ich kann das Wiederauftauchen von diesen Symptomen auch bestätiigen. Nur, ich denke, der Grund ist diesmal anders. Ich versuchte, mit Wireshark dahinter zu kommen, bin aber nicht ganz erfolgreich gewesen. Möglicher Zertifikatsfehler?

    • Ich denke, dass die Ausstellung der Zertifikats fehlschlägt. Genau genommen ein Problem zwischen Microsoft und GoDaddy … danach kann keine Aktualisierung mehr erfolgen.
      Darüber hinaus müssen wir uns wohl vom remotewebaccess.com verabschieden, es tut ja seit fast 2 Wochen nicht mehr und ich habe keine große Hoffnung das dieser Service zurückkommen könnte. Die Umstellung meiner Kunden auf VPN ist auch schon fast durch …

      • Der Zertifikatsfehler, den ich meinte, ging um https://onedscolprdneu05.northeurope.cloudapp.azure.com, gesehen in Wireshark, deren Zertifikat nicht (mehr?) für die Site gültig ist. Wenn Essentials nicht mehr eine sichere Verbindung zu den DDNS-Server herstellen kann, könnte das die neue Fehlschläge erklären. Aber wie Sie sagen, der Grund ist im Prinzip egal, wenn der Fehler nicht korrigiert wird–es ist wahrscheinlich Zeit, remotewebaccess zu hinterlassen.

  7. Ich wollte gerade meinen Server umstellen, da habe ich bemerkt, dass es bei mir wieder funktioniert. Kann das jemand anders für seine(n) Server auch bestätigen? Gestern ging es noch nicht.

    • Kann ich bestätigen.
      Ich würde nur gerne wissen, was das Problem verursacht hat.

      Trotzdem ein Weckruf, zeitnah vom alte WSE zu wechseln.

    • Ja, dass ist bis zum Support-Ende auf jeden Fall eine Option. Leider ließ sich während der letzten Störung das nicht mehr ändern, bzw. habe ich das ohne den Zugriff auf remotewebaccess.com nicht hinbekommen.

      b!

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s