Windows SBE remotewebaccess.com Update schlägt fehlt

Veröffentlicht am März 18, 2021 von b!

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.

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 …

… und dazu den folgenden Absatz.

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.

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.

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

Enjoy it, b!

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

Ralph-D.Henrich sagte am Juni 9, 2021 um 11:47 am :

Kann ich das Fix auch als nicht so sehr mit dem Server 2012R2 vertrauter Person ausführen???
Bitte um Hilfe wie ich das in Schritten ausführen kann.
Vielen Dank dafür,

Kommentiere ↓
- b! sagte am Juni 9, 2021 um 1:03 pm :
  
  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!
  
  Kommentiere ↓
  - fitsch1120544 sagte am Juni 12, 2021 um 11:14 am :
    
    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
Dan sagte am Juni 17, 2021 um 1:04 am :

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.

Kommentiere ↓
- b! sagte am Juni 17, 2021 um 3:24 am :
  
  Freut mich und vielen Dank für das Feedback!
  
  Kommentiere ↓
  - fitsch1120544 sagte am Juni 17, 2021 um 9:42 am :
    
    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?
  - b! sagte am Juni 21, 2021 um 3:42 am :
    
    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!
Pingback: Windows Server Essentials Computer Backup Service funktioniert nicht (mehr) | Windows SBS and Essentials Blog
Josias Martins Jr sagte am September 5, 2021 um 2:09 pm :

Wunderbar. Es hat gut funktioniert für meinen 2012 Essentials server. Danke vielmals!

Kommentiere ↓
- b! sagte am September 5, 2021 um 7:12 pm :
  
  Gerne, es freut mich immer wieder wenn die Beiträge helfen.
  
  Kommentiere ↓
Thomas P. sagte am November 23, 2021 um 5:18 pm :

DANKE!!!! Einfach klasse, endlich konnte ich dieses Problem mit Ihrem Fix beheben.
Nochmals vielen Dank!

Kommentiere ↓
- b! sagte am November 23, 2021 um 6:25 pm :
  
  Freut mich, dass der Fix geholfen hat!
  
  Kommentiere ↓
boemat01 sagte am Mai 4, 2022 um 4:00 pm :

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?

Kommentiere ↓
- b! sagte am Mai 5, 2022 um 7:27 am :
  
  Ich persönlich glaube, dass diesesmal das Problem nicht auf dem Server sondern beim DynDns-Service (remotewebaccess.com) von Microsoft liegt.
  
  Kommentiere ↓
Predy sagte am Mai 4, 2022 um 9:20 pm :

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

Kommentiere ↓
- b! sagte am Mai 5, 2022 um 7:28 am :
  
  Ja, ich habe das Problem auf 5 SBE Servern … lediglich bei Internet-Zugängen mit fixer IPv4-Adresse läuft der Zugriff noch.
  
  Kommentiere ↓
GALM sagte am Mai 4, 2022 um 9:40 pm :

Ich hatte den code bereits eingegeben und alles war in ordnung, aber es schlägt wieder fehl, weiß jemand etwas?

Kommentiere ↓
- b! sagte am Mai 5, 2022 um 7:28 am :
  
  Ich persönlich glaube, dass diesesmal das Problem nicht auf dem Server sondern beim DynDns-Service (remotewebaccess.com) von Microsoft liegt.
  
  Kommentiere ↓
Michael W. sagte am Mai 5, 2022 um 7:42 am :

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.

Kommentiere ↓
- b! sagte am Mai 5, 2022 um 10:08 am :
  
  Ich bin gespannt wie das ausgehen wird und habe kein besonders gutes Gefühlt dabei.
  
  Kommentiere ↓
Dumdiedum sagte am Mai 5, 2022 um 4:05 pm :

Seit Montag, 02.05.2022 der gleiche Fehler remotewebaccess.com über dynamische IP. Hat einer eine Lösung

Kommentiere ↓
mcbsys sagte am Mai 10, 2022 um 11:48 pm :

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?

Kommentiere ↓
- b! sagte am Mai 11, 2022 um 5:32 am :
  
  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 …
  
  Kommentiere ↓
  - mcbsys sagte am Mai 11, 2022 um 2:15 pm :
    
    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.
Matthias Böhme sagte am Mai 14, 2022 um 5:39 pm :

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.

Kommentiere ↓
- b! sagte am Mai 15, 2022 um 1:21 pm :
  
  Ja, remotewebaccess.com ist wieder erreichbar.
  b!
  
  Kommentiere ↓
mcbsys sagte am Mai 14, 2022 um 6:10 pm :

Manche Benutzer auf diesem Pfad https://docs.microsoft.com/en-us/answers/questions/836775/ benachrichtigen seit etwa 18 Stunden, der Fehler sei behoben.

Kommentiere ↓
- Michael Westphal sagte am Mai 14, 2022 um 6:23 pm :
  
  Kann ich bestätigen.
  Ich würde nur gerne wissen, was das Problem verursacht hat.
  
  Trotzdem ein Weckruf, zeitnah vom alte WSE zu wechseln.
  
  Kommentiere ↓
Matthias Böhme sagte am Mai 15, 2022 um 7:56 pm :

Im Server 2016 war doch die Essentials-Rolle noch drin, also müsste die Funktionalität doch auch bis zum Supportende am 12.01.2027 von M$ unterstützt werden (Kaufvertrag???). Sollte es anders kommen, werde ich, bevor ich mir etwas anderes suche, die Anleitung ausprobieren, die ich gefunden habe: https://www.theofficemaven.com/news/how-to-manually-set-up-a-custom-vanity-domain-name-in-essentials

Kommentiere ↓
- b! sagte am Mai 16, 2022 um 8:52 am :
  
  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!
  
  Kommentiere ↓
  - Mike sagte am Mai 25, 2022 um 11:05 am :
    
    Hi zusammen, wie ist denn jetzt der aktuelle Stand für Server 2012 R2? Ich habe es jetzt mit dem Script versucht, aber keine Änderung erreicht. Mir wurde von Anfang an gemeldet (irgendwann im letzten Jahr), dass das Zertifikat abgelaufen sei und nicht erneuert werden konnte. Ich habe dann eine Weile gesucht, konnte aber keine Möglichkeit finden, das Zertifikat zu erneuern. Irgendwo habe ich dann später gelesen, dass MS diesen Dienst einstellt und somit keine neuen Zertifikate zur Verfügung stehen. Ich kenne mich in diesem Bereich aus und habe mich dann innerlich von der Funktion verabschiedet. Heute bin ich dann zufällig auf diese Website gestoßen und dachte, ich probiere es nochmal. Updates habe ich immer aktuell und da ich seit zwei Jahren im HomeOffice arbeite, habe ich die Funktion nur noch selten benötigt. Es ist also für mich nicht unbedingt lebensnotwendig, wäre aber schon schön, wenn es wieder funktionieren würde. Danke!
  - b! sagte am Mai 25, 2022 um 1:55 pm :
    
    Hi Mike,
    für den SBE 2012R2 musst Du so wie im Blog geschrieben die Einträge setzen. Der Nachtrag vom 20.03.2021 beschreibt eine ERGÄNZUNG die Notwendig ist wenn ein SBE 2012 zum Einsatz kommt, was aber bei Dir nicht der Fall ist.
    Grüße, b!
Mike sagte am Mai 25, 2022 um 11:07 am :

Ich meinte natürlich, dass ich mich in diesem Bereich (Zertifikate usw.) NICHT auskenne 😀 sorry

Kommentiere ↓
Ahmet sagte am November 11, 2022 um 9:26 pm :

Hallo,
das Problem ist wieder aufgetreten, bei euch auch oder bin ich der einzige?

Kommentiere ↓
- b! sagte am November 12, 2022 um 7:26 am :
  
  Hi Ahmet,
  nein meine beiden letzten Server, mehr sind aktuell nicht mehr übrig 😦 funktionieren einwandfrei.
  /b!
  
  Kommentiere ↓
  - Michael B. sagte am November 18, 2022 um 9:43 am :
    
    Das Probem wird erst schlagend, wenn sich deine Public IP ändert.
- Veljovic Predrag sagte am November 12, 2022 um 6:59 pm :
  
  Hallo, bei mir tritt das Problem seit 12.11.2022 ca. 14:07Uhr auch wieder auf.
  
  Kommentiere ↓
  - b! sagte am November 13, 2022 um 5:03 pm :
    
    ja stimmt, inzwischen sehe ich dieses Problem auch (wieder).
Michael BERNHARD sagte am November 14, 2022 um 12:08 pm :

Ich kann diese Problem ebenfalls bestätigen ..LEIDER

Kommentiere ↓
Michael BERNHARD sagte am November 19, 2022 um 12:35 pm :

Die Gute Nachricht.
Das MS-DNS-Service für „*.remotewebaccess.com“ klappt wieder.Hoffentlich bleibt das so.
LKG
Michael B.

Kommentiere ↓