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!

AD-Migration von Windows Server 2012 SBE auf Windows Server 2019

Farewell Small Business Essentials Server

Dieser Blog war nur eine Frage der Zeit, aber es war klar, dass er kommen wird (und leider muss). Nachdem mit dem Windows Server 2019 lediglich das Lizenz-Modell des SBE übriggeblieben ist, gibt es zwei Möglichkeiten in welche Richtung eine Small Business Server Umgebung entwickelt werden kann.

  1. Windows Server Standard
  2. Synology NAS

Den Weg in Richtung Windows Server Standard (also aktuell Windows Server 2019 oder 2022) wähle ich, wenn sich in der SBE-Umgebung eine Anwendungslandschaft etabliert hat, sprich einige Applikationsserver vorhanden sind und dazu auch noch virtualisiert wird.

Spoiler

Man kann aus zwei Synology NAS Systemen (dem darauf laufendem Synology Directory Server) und zwei Intel NUC PCs (als Hyper-V Hosts) ebenfalls eine interessante Infrastruktur bauen, dass soll aber das Thema in einem anderen Blog sein.

Migration

Die Umstellung auf Windows Server Standard verläuft wie im Folgenden dargestellt.

  1. Installation des neuen Servers als Member-Server in der bestehenden Domain
  2. Erstellen eines domain-basierten DFS-Roots
  3. Migration von vorhandenen Freigaben und der bereitgestellten Daten in das domain-basierte DFS
  4. Anpassung von Gruppen-Richtlinien und des Login-Scripts auf die Freigaben die nun über das DFS auf dem neuen Server (der ja aktuell noch als Member-Server läuft) abgebildet werden
  5. Heraufstufen (Promote) des neuen Member-Servers zu einem zweiten Domain-Controller und anpassen dessen DNS-Einträge
  6. Verschieben der FSMO auf den neuen Server
  7. Entfernen der Active Directory Zertifikatsdienste (mit der Webregistrierung muss beginnen werden) und zwingend danach einen Neustart durchführen
  8. Herunterstufen (Demote) des alten Servers
  9. Spätestens jetzt eventuell vorhandene Drucker auf dem Server migrieren
  10. Den alten Server aus der Domäne entfernen, oder besser erst einmal 14 Tage ausgeschaltet lassen (falls man was vergessen hat)
  11. Den domain functional level und den forrest functional level heraufstufen

Jeden der genannten Schritte werde ich hier nicht im Detail ausführen, dafür verkaufen andere Webseiten ganze Migration-Guides und ich denke, dass robocopy geläufig sein sollte.

Was ich aber für sinnvoll halte ist, sein (mein) Schaffen zu überprüfen. Sprich verhalten sich die Systeme so wie ich mir das vorstelle. Darum werde ich unten eine Reihe von Tests beschreiben, mit denen eine Prüfung zum jeweiligen Stand möglich ist.

Zu den Schritten 1 bis 4

Die Installation des Member-Servers ist selbstredend und da er im Verlauf der Migration ein Domain-Controller wird, sollte er auch gleich eine statische IP bekommen.

Wenn alle Scripte und GPOs angepasst sind, sollten auf den neu eingerichteten Member-Server auch die Zugriffe erfolgen. Genauso wichtig ist es, dass der alte Domain-Controller keine Zugriffe über SMB mehr zeigt.

# Anzeige von offenen Dateien über die SMB-Shares auf dem noch aktuellen Domain-Controller
Get-SmbOpenFile

Das folgende Beispiel finde ich gut, da es einen “false positive” zeigt.

image

Eine Session (dazu noch eine Anmelde-Sitzung) haben wir, dass NAS zur Datensicherung vergnügt sich noch mit diesem DC. Sobald wir den neuen DC und damit auch einen weiteren DNS haben, muss auf allen Clients dieser neue DNS auch eingetragen werden (der alte DC ist ab Schritt 8 nicht mehr vorhanden).

Zu Schritt 5

Mit Install-WindowsFeature muss auf dem Member-Server sowohl das Active-Directory als auch der DNS installiert werden, was in einem Schritt möglich ist.

# Installation des Active Directory und DNS
Install-WindowsFeature -Name AD-Domain-Services, DNS -IncludeAllSubFeature

image

Nun lauert im Server-Manager versteckt was früher der DCPromo war, in Form eines Wizards zur Fertigstellung des Domain-Controllers. In diesem Fall wird der Server als weiterer DC in die bestehende Domain und Forest integriert.

Zu Schritt 6

Der neue Server muss nun, wenn er funktional wirklich ein Domain-Controller ist, den NETLOGON- und den SYSVOL-Share bereitstellen. Bei mehreren Migrationen von Windows Server 2012 SBE (auch R2) auf Windows Server 2019 war das nicht der Fall und jedes Mal, war eine dysfunktionale SYSVOL-Replikation der Grund.

Die Lösung dazu aber immer beeindruckend einfach, der als neuer Domain-Controller gedachte Windows Server 2019 wurde wieder aus dem AD entfernt (demoted) und die Replikation auf dem Windows Server 2012 repariert. Danach den Windows Server 2019 wieder zum Domain-Controller promoten und schauen, ob die beiden Shares nun verfügbar sind. Alle Maßnahmen, bei denen man die Shares auf anderem Wege erstellt hat, führten zumindest bei mir, früher oder später zu Problemen.

image

# Anzeige des SysVol und Netlogon Shares
Get-SmbShare | Where-Object { $_.Description -match "Logon server share" }

Zum Verschieben der FSMO-Rollen, wird der folgende PowerShell-Befehl verwendet.

# Verschieben der FSMO-Rollen
Move-ADDirectoryServerOperationMasterRole -Identity Neuer-Domain-Controller -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster

Sollte der Befehl funktionieren, hat man mit einem Rutsch alle Rollen migriert. Ich schreibe hier bewusst im Konjunktiv, da auch hier gelegentlich das Problem aufgetreten ist, dass der Befehl nicht wie erwartet funktioniert.

Dann haben die beiden folgenden Möglichkeiten bisher zum Erfolg geführt.

  • Verwenden von Move-ADD… mit immer nur einer Rolle
  • Verschieben der Rollen in den entsprechenden MMCs
# Abfrage ob die FSMO-Rollen nun auf den neuen DC sind
netdom query fsmo

Klar, kann man die Rollen auch mit PowerShell abfragen, dazu sind aber zwei Befehle notwendig, bzw. man muss in unterschiedlichen Kontexten arbeiten.

# Abfrage ob die FSMO-Rollen nun auf den neuen DC sind
Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster

Hier alle drei Aufrufe als Screenshot.

image

Abschließend schaue ich immer, ob die wichtigen Active Directory Dienste laufen.

# Anzeige von wichtigen Diensten für das Active Directory
Get-Service adws,kdc,netlogon,dns

image

Wie vielleicht bisher schon zu sehen war, teste ich möglichst viel und zwischendurch, um ein Gefühl zu bekommen, ob die Migration sauber läuft. Das hat sich über die Jahre hin als sinnvoll herausgestellt, da oftmals nur kleine Korrekturen zwischendurch notwendig waren und nicht am Ende ein großes nicht sauber funktionierendes Nichts steht Smile

Zwischen Schritt 6 und 7 kann man ein paar Tage vergehen lassen. Man muss hier lediglich mit den Meldungen des alten Windows Server 2012 SBE leben, der ein Fehlen der FSMO-Rollen zurecht, als Lizenzverstoß reklamiert.

Zu Schritt 7

Bevor nun der alte Windows Server 2012 SBE seine Rolle als Domain-Controller verliert, müssen die Active Directory Certificate Services deinstalliert werden. Macht man das von Hand, zuerst die Certification Authority Web Enrollment und dann den Rest danach deinstallieren.

# Anzeige der Roles und Features
Get-WindowsFeature -Name ADCS-Web-Enrollment, ADCS-Cert-Authority, AD-Certificate

image

Auch mit PowerShell muss das in zwei Schritten erfolgen.

# Deinstallation der Active Directory Certificate Services
Remove-WindowsFeature -Name ADCS-Web-Enrollment
Remove-WindowsFeature -Name AD-Certificate

image

Nun ist ein Neustart zwingend notwendig, auch wenn das durch die PowerShell-Ausgaben nicht den Eindruck erweckt. Wird der vergessen, jagt man hinterher eine Reihe von komischen Dingen nach. Also nun einfach durchstarten (den alten Domain-Controller).

# Neustart des alten Servers
Restart-Computer -Force

Nach dem Neustart kann der alte Domain-Controller heruntergestuft werden.

Zu Schritt 8

Alle Informationen dazu kann man bei Microsoft hier nachlesen. Obwohl ein großer Freund von PowerShell, führe ich diesen Schritt immer in der GUI durch. Dazu im Server Manager einfach die Rolle Active Directory Domain Services entfernen.

image

Der Remove Roles and Features Wizard bietet einem danach die Möglichkeit den Server herunterzustufen.

image

Der Vorgang ist selbsterklärend, am Ende dessen muss eine Meldung ähnlich der folgenden vorhanden sein.

image

Ok, hier noch die Aktion in PowerShell.

# Windows PowerShell script for AD DS Deployment
Import-Module ADDSDeployment
Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -Force:$true

Mit einem Klick auf Demote im Wizard wird der Prozess gestartet und der Server startet nach dem Herunterstufen neu. Davor ist es sinnvoll einen Blick in die DNS-Einstellungen der Netzwerkkarte zu werfen, steht dort wie bei vielen Domain-Controllern in SBE-Umgebungen “nur” 127.0.0.1, ist es notwendig den DNS vom neuen Domain Controller mit einzutragen. Sonst geht die Anmeldung mit einem Konto aus der Domain schief.

Zum Schluss

Eigentlich war es das, aber die Erfahrungen der letzten Migrationen haben gezeigt das immer noch der eine oder andere Rest des alten Domain-Controllers zurückbleibt.

Diesen haben ich als Namespace-Server im DFS entfernt. Damit das ohne Probleme funktioniert sollte der alte Server noch vorhanden sein und für kurze Zeit als Member-Server arbeiten dürfen.

image

Der alte Domain-Controller (der nun keiner mehr ist) darf nun auch nicht mehr in der SYSVOL-Replication auftauchen.

image

Ein weiteres Problem, eher optischer Natur ist der Verbleib des alten Servers als Name-Server in der Reverse Lookup Zone (falls man überhaupt eine hat).

image

Hier diesen entfernen und wie im Bild oben zu sehen ist, für den neuen die aktuelle IP auflösen lassen. Im Allgemeinen ist es sinnvoll den DNS nach alten Einträgen zu durchsuchen und diese zu löschen.

Enjoy it, b!

SBE: Howto fix Client Computer Backup

Die Annahme, dass das Laufwerk mit den Client Computer Backups auf dem SBE (Windows Server 2012R2 oder 2016 mit der Small Business Essentials Role) nicht wichtig ist, hat sich in meinem letzten Support-Fall als nicht korrekt herausgestellt.

Die Geschichte hat natürlich einen Anfang. Wird eine hinreichend große Anzahl von Clients (PCs im SBE Netzwerk) gesichert, kann das Laufwerk das den Sicherungsordner Client Computer Backup bereitstellt schon mal auf 1TB anwachsen. Der Kunde (oder dessen Administrator) dachte nun, dass er einigen Platz sparen kann, wenn er das Laufwerk nicht sichert und auch nicht in die Hyper-V Replikation aufnimmt. Durch einen Defekt der Server-Hardware musste auf einen anderen Hyper-V Host umgeschaltet werden und der SBE “erwachte” aus der Replika ohne die Client Computer Backups, beziehungsweise ohne das passende Laufwerk.

Gleiches kann natürlich auch passieren, wenn das Laufwerk versehentlich gelöscht wird oder auf einem anderen Wege kaputt geht.

Die Ausgangssituation

Vollständiger Verlust der Client Computer Backups mit samt des bereitstellenden Laufwerks. Damit werden die Clients nicht mehr gesichert und der SBE zeigt eine Reihe von Fehlermeldungen im Dashboard und auch in der Ereignisanzeige.

image

Nun stellt sich die Frage, wie diese Funktionalität wieder hergestellt werden kann und ob sich das überhaupt reparieren lässt?

Die Wiederherstellung der Client Computer Backup Funktionalität

Damit das nochmals klar wird, es geht hier nicht darum die Backups selbst wiederherzustellen, sondern die Funktionalität des SBE damit dieser wieder Backups der Clients anfertigen kann.

In einem ersten Schritt wird dem SBE wieder ein passendes Laufwerk bereitgestellt. Das geschieht in virtuellen Umgebungen durch Anhängen einer neuen VHD oder auf einem physikalischen Server durch Einbau einer neuen Platte.

Das neue Laufwerk erscheint unter dem Laufwerksbuchstaben I und wird mit NTFS formatiert. Nun dachte ich, dass es ausreichen würde die Funktion Repair backups / Repair now zu verwenden und der Rest passiert dazu im Hintergrund, dass war aber eine falsche Annahme. Es ist nämlich so, dass die Clients durch die Installation des Client Connectors in die Datenbank des Client Computer Backups eingetragen werden. Die existiert aber nicht mehr und muss darum neu angelegt und danach noch die Client Computer zugeordnet werden.

image

Ein Repair now … meldet zwar Erfolg, aber funktionieren tut hinterher das Client Computer Backup nicht.

Eine Reparatur erfolgt mit den folgenden Schritten:

Bereitstellen eines hinreichend großen Laufwerks, das einen Bezeichner besitzt und mit NTFS formatiert ist.

# Stopping Windows Server Essentials Computer Backup
Stop-Service -Name WseComputerBackupSvc -Force
# Create missing directories
New-Item -Type Directory -Path 'I:\ServerFolders\Client Computer Backups\'
# Starting Windows Server Essentials Computer Backup
Start-Service -Name WseComputerBackupSvc

image

Eigentlich legt der Windows Server Essentials Computer Backup Service beim Start, falls noch nicht vorhanden, seine Datenbank an. Ich habe aber schon gesehen, dass das nicht passiert ist. Darum lohnt sich nochmals das Ausführen der Reparatur (Repair now …)

image

Nun sollten die drei folgenden Dateien im Verzeichnis vorhanden sein.

image

  • Commit.dat
  • ConsistencyInfo.cc
  • DatabaseInfo.dat

Seitens des Servers ist nun alles eingerichtet, nun müssen wir noch die Clients zurückbringen.

Das habe ich bisher nur über eine De-Installation und Neu-Installation des Client Connectors hinbekommen. Zwischen den beiden Schritten, ist kein Neustart notwendig. Einfach den Connector deinstallieren und im Anschluss sofort wieder installieren und fertig.

image

Danach läuft das Backup wieder ohne Probleme.

image

Die drei oben genannten Dateien nehme ich darum auch in die Datensicherung auf.

image

Damit spart man sich zumindest die Arbeitsschritte auf dem Server.

Enjoy it, b!

Windows Backup Workaround

Nicht nur auf dem SBE generiert Windows Backup immer wieder Aufwände, wenn es mal wieder nicht so richtig will. Gelegentlich wird ein Volume gesichert und die Sicherungsdauer ist länger als das dafür vorgesehene Zeitfenster.

Wird wie bei mir auf dem SBE nur 1x am Tag gesichert, dann sind das halt 24 Stunden.image

Der morgendliche Bericht des SBE meldet dann auch anständig, dass ein Backup wieder schief gegangen ist.

Das eigentliche Problem war aber, dass der Task am nächsten Tag nicht gestartet wurde weil das Backup einfach noch nicht fertig war.

image

Um der Sache zumindest auf “optischem Weg” Herr zu werden, deaktiviere ich den laufenden Task bis dieser dann wirklich alle Volumes gesichert hat und danach aktiviere ich ihn wieder. Die darauf folgenden Sicherungen (Inkremental) laufen auch deutlich schneller ab.

imageimage

Ist dann das erste Backup fertig, einfach den Task wieder aktivieren.

image

Enjoy it, b!

Fix: Windows 10 und 11 Update und der Essentials Connector

Info: Bitte die Update Historie unten lesen, ursprünglich wurde das Script für Windows 10 Version 1903 entwickelt und seitdem immer wieder getestet und aktualisiert. Für alle die nicht lesen wollen, die aktuelle Version des Scripts befindet sich hier. Darüber hinaus funktioniert dieser Workaround ebenfalls mit Windows 11, wenn man ein Windows 10 System über das ISO aktualisiert.

For the english version, please follow this Link.

Zumindest aus Sicht des Windows Server Essentials Connector ist jedes Update von Windows 10 spannend. Die seit gestern offiziell verfügbaren Version 1903 für Windows 10 versäumt es beim Upgrade, die für die Ausführung des Windows Server Essentials Connectors notwendigen Dienste (Services) zu migrieren. Die sind nach dem Update nicht mehr vorhanden.WSE-1903

Damit ist der Windows 10 Client nicht mehr in der Lage sich am Windows Server Essentials an zu melden um seinen Status zu kommunizieren oder eine Sicherung durch zu führen. Im Dashboard des Server erscheint der Client Offline.

image

Damit das wieder klappt, müssen die Services hergestellt werden. Das geht am einfachsten durch das folgende Script, welches die Services in Form von REG-Dateien in die Registry importiert. Im Anschluss, nach einem Neustart funktioniert der Connector ohne Probleme.

image

Das Script und die dazu notwendigen REG-Dateien sind in der ZIP Datei als Download verfügbar. Für eventuelle Schäden lehne ich jegliche Haftung ab.

  • Die Ausführung des Scripts muss in einer PowerShell-Session als Administrator erfolgen
  • Script und REG-Dateien müssen zwingend im gleichen Verzeichnis liegen
  • Das Script prüft ob es sich um den Version 1903 oder höher handelt. Nur dann werden die REG-Dateien in die lokale Registry des Windows 10 Clients eingetragen

Möglicher Weise können Probleme mit der PowerShell Execution-Policy auftreten, dazu wende ich den folgenden Workaround an.

Get-Content -Path .\Fix-WSeLaunchpad-1903.ps1 | PowerShell.exe -NoProfile -

image


Update 30.05.2019

Inzwischen ist es mir gelungen, dass Microsoft dieses Problem als Bug (Fehler) betrachtet und an einem Fix arbeitet. Wie schnell damit zu rechnen ist, kann ich nicht sagen melde mich aber wenn ich weiteres weiß.

Update 15.07.2019

Das Script, und damit der Workaround funktionieren mit dem WSE 2016 und dem WSE 2012R2, dass mag im Blog nicht richtig rüber gekommen sein. Für die anderen Versionen (WSE 2011 und 2012) müsste man die Registry-Einträge des Connectors vergleichen.

Update 21.07.2019

Ich hatte nun die Gelegenheit Windows 10 Clients an einem SBE 2012 (ohne R2) um zu stellen und muss gestehen, dass das Script hier definitiv nicht funktioniert. Der Clientconnector dort verwendet wohl andere Einträge in der Registry als unter Windows Server 2012R2/2016.

Update 18.11.2019

Mit dem Update auf Windows 10 1909 gibt es keine Probleme, dass liegt an der von Microsoft geänderten Bereitstellung. Dazu werden vornehmlich nur Features freigeschaltet, die schon in früheren Versionen vorhanden waren.

Update 11.12.2019

Wird ein ISO mit Windows 10 1909 für einen Upgrade, zum Beispiel von Windows 7 auf Windows 10 verwendet. Schlägt der Bug wieder zu und das bisherige Script funktioniert leider nicht. Darum habe ich eine kleine Änderung durchgeführt und eine Version erstellt (steht nun auch in der History), die mit 1903 und neuer funktioniert.

Update 15.05.2020

Auch mit Windows 10 2004 tritt dieses Problem auf und kann über das Script behoben werden. Ich habe an diesem eine Reihe kleinerer Korrekturen durchgeführt und hier zum Download bereitgestellt.

Update 23.10.2020

Seit dem letzten Jahr, oder denken wir in Updates, seit Windows 10 Version 1909, liefert Microsoft das Herbstupdate als normales Windows Update aus, dass Features die im Verlauf der letzten Monate durch Updates (in 2004) installiert wurden aktiviert. Damit funktioniert das Update auf diesem Weg ohne Probleme und das Script ist nicht notwendig. Erfolgt aber ein Upgrade, zum Beispiel der Version 1909, durch das Windows 10 20H2 ISO, kann das Script im Anschluss den Connector reparieren.

Update 05.06.2021

Mit dem Windows 10 21H1 Update funktioniert das Script in der aktuellen Version ohne Änderungen. Wird das Update über den WSUS oder Windows Update installiert, dann funktioniert der Windows Essentials Connector ohne Probleme und das Script ist nicht notwendig. Erfolgt das Update hingegen über eine ISO Datei, die es als Download bei Microsoft gibt, kann der Essential Connector im Anschuss über das Script repariert werden.

Update 05.10.2021

Heute wurde Windows 11 released und ich habe gleich das Update probiert. Klappt mit den gleichen Problemen wie auch schon unter Windows 10. Genau genommen ist Windows 11 auch nur Windows 10 Build 22000 …

image

Das Script funktioniert auch hier ohne Probleme, ich habe aber die Ausgaben und Meldungen an das neue Windows angepasst.

Enjoy it,b!

Windows Server Essentials Computer Backup Service funktioniert nicht (mehr)

In der Release Documentation for Windows Server Essentials vom 10.03.2021 kündigt Microsoft Pläne an TLS 1.0 und 1.1 zu deaktivieren und TLS 1.2 für den Windows Server Essentials als zukünftigen Standard für eine Absicherung der Kommunikation vorzusehen.

image

Ein Überlesen dieser Information und damit das Versäumnis TLS 1.2 zu aktivieren hatte ja schon im März zu dem Blog über den nicht mehr funktionierenden Zugriff mittels <domain>.remotewebaccess.com geführt.

Nun bin ich auf einem SBE über einen nicht mehr funktionierenden Windows Server Essentials Backup Service gestolpert und dessen Abhängigkeit zu TLS 1.1.

Durch den Startup Type = Automatic sollte der Dienst mit einem Neustart des Servers gestartet werden. Was zwar passierte, aber nach ein paar Minuten war der Dienst nicht mehr aktiv.

image

Ich fasse hier mal die Symptome zusammen:

    • Der Windows Server Essentials Backup Service startet und stoppet im Anschluss wieder
    • Im Eventlog unter Application and Services Logs / Microsoft / Windows / ServerEssentials / Admin haben wir diese Fehlermeldung:Event 270, ServerEssentials
      API name GetTlsServerCredentials


image

Der Fehler sieht danach aus, dass der Service sich nicht Authentifizieren kann.

Weder Microsoft selbst, noch die Suchmaschine(n) meiner Wahl lieferten einen wirklich guten Hinweis auf die API GetTlsServerCredentials. Damit dachte ich mir, ich versuche mal IISCrypto von NARTAC Software um mir die aktuelle Konfiguration anzeigen zu lassen.

image

Auf diesem Server war lediglich Schannel TLS 1.2 (Server / Client Protocols) aktiviert. Ein Vergleich mit einem anderen SBE zeigte aber, dass dieser zusätzlich TLS 1.2, 1.1 und 1.0 aktiviert hatte und auf diesem Server lief der Windows Server Essentials Computer Backup Service.

image

Nach der Aktivierung von TLS 1.1 (und TLS 1.0, siehe Update unten), sowohl Server als auch Clientseitig (Server Protocols / Client Protocols) und einem damit notwendigen Neustart lief auch der Windows Server Essentials Computer Backup Service auf diesem SBE wieder.

image

Es existiert also eine Abhängigkeit zu TLS für den Windows Server Essentials Computer Backup Service. Eine Dokumentation dazu konnte ich nirgendwo finden und diese gewonnene Erkenntnis ist auf einen “educated guess” zurück zu führen, hat aber das Problem gelöst. Alle anderen Services auf dem SBE laufen übrigens mit der TLS 1.2 Einstellung problemlos, nur für den Windows Server Essentials Computer Backup Service ist noch TLS 1.1/1.0 notwendig.

Update 25.06.2021:
Nachvollziehen konnte ich dieses Verhalten sowohl mit Windows Server 2016 als auch mit Windows Server 2012R2, allerdings mit einen Unterschied. Während auf einem Windows Server 2016 der Windows Server Essentials Computer Backup Service mit TLS 1.1 wieder funktioniert hat, benötigte es unter Windows Server 2012R2 TLS 1.0.

Interessant ist, dass mit TLS 1.1 unter Windows Server 2012R2 der Service deutlich länger lief, bevor er mit dem Fehler oben (Event ID 270) sich beendet hat.

Update 29.06.2021:
Mit TLS 1.1 und 1.2 läuft auf dem Windows Server 2016 der Windows Server Essentials Computer Backup Service, aber die Clients verweigern das Backup. Welches nach Aktivierung von TLS 1.0 ebenfalls wieder funktioniert hat.

Zusammenfassend kann ich heute folgendes sagen:

  • Windows Server 2016 und 2012R2 = TLS 1.0, 1.1 und 1.2

Wenn ich nochmals zu neueren Erkenntnisses komme, gibt es dazu wieder ein Update.

Enjoy it, b!

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!

Fix: Windows 10 and 11 Update and Small Business Essentials Connector

Informationen in deutscher Sprache sind unter dem folgenden Link verfügbar.

While this blog is held in german language, one article requires an addition written in english language.

For Windows 10, Microsoft provides every 6 months a major version update to add new features to it’s client operating system.

This update, if done by an ISO or with an update package from WSUS may break the Windows Server Small Business Essentials Connector by forgot to migrate the connector services registry keys.

Windows SBE services

While these five services are displayed in the services.msc they are, without corresponding registry keys, are no longer functional.

Additionally the Windows 10 client seems to offline from Windows SBE dashboard.

Windows 10 clients offline in dashboard

To get the connector back working, I’ve written a script adding the missing registry keys from a PowerShell session. The ZIP-file contains beside the PowerShell code the REG-files containing the missing keys.

To run the script, follow the steps described bellow:

  1. Download the script and extract the content to a dedicated directory
  2. Open a PowerShell session as Administrator and jump to the directory with the PowerShell-script and the REG-files. Note, script and REG-files must live in the same directory
  3. Execute the script by running the following line of PowerShell (to workaround PowerShell Execution-Policies) and don’t miss the “-“ at the end of the script.
# Workaround some obscure PowerShell Execution-policies 😉
# don't miss the "-" at the end of the line!
Get-Content -Path .\Fix-WSeLaunchpad-1903.ps1 | PowerShell.exe -NoProfile -

A successful execution looks, like the following picture shows.

Note: Don’t forget to reboot your Windows 10 client, to make the connector work again.

Enjoy it, b!

Zeitumstellung und die Windows Server Essentials Status Mails

Aus gegebenem Anlass, falls der Windows Server Essentials keine Status Mails mehr verwenden will. Wir hatten wieder eine Zeitumstellung und damit kommt der Management-Service nicht zurecht.

image

Der Fehler tritt auf, egal ob wir einen Windows Server 2012 R2 oder Windows server 2016 Small Business Esentials betreiben und die Lösung ist immer noch die gleiche wie vor 2 Jahren Winking smile

net stop "Windows Server Essentials Management Service" && net start "Windows Server Essentials Management Service"

Der Windows Server Essentials wäre damit auch ein Produkt, welches von der Abschaffung der Zeitumstellung profitieren würde.

Enjoy it, b!

Event 4121, Data Deduplication

Auf einem Windows Server 2012R2 ließ sich die Konfiguration für die Deduplizierung der Volumes nicht mehr starten, ebenfalls zeigte der Servermanager keine Informationen über deren Zustand an. Im Eventlog (Application and Services/Microsoft/Windows//Deduplication/Operational) waren viele Einträge mit dem Event 4121 zu sehen.

image

Alle Einträge mit dem Event 4121 deuteten auf eine korruptes XML-Datei im Laufwerk D: hin:

D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml

Zumindest ich habe im Web keinen wirklich guten Vorschlag zur Lösung des Problems gefunden. Maßnahmen wir die Deinstallation der Deduplizierung, brachten ebenso wenig Erfolg wie ein Chkdsk auf dem Volume.

Das Problem habe ich nach einigem Überlegen wie folgt gelöst.

Analyse der dedupConfig.02.xml

Dazu habe ich die XML-Datei nach C:\Temp kopiert, da aber auf die Datei nur der SYSTEM Account Zugriff hat musste ich dazu eine cmd.exe mit PSEXEC starten.

c:\Temp>"\Program Files (x86)\Windows Sysinternals Tools\PsExec.exe" -s cmd.exe

Damit konnte ich die XML-Datei sehen und auch kopieren.

dir "D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml" /ah

xcopy /h  "D:\System Volume Information\Dedup\Settings\dedupConfig.02.xml" C:\Temp

Im Verzeichnis C:\Temp habe ich erst einmal alle Attribute entfernt und versucht die Datei mit NotePad++ zu öffnen,

attrib -s -h -a dedupConfig.02.xml

Die Datei ließ sich mit keinem Editor öffnen, bzw. in einer sinnvollen Form lesen. Die Idee, wie das Ganze nun in den Griff zu bekommen sei, war von einem anderen Server (und hier ebenfalls von Laufwerk D die XML zu kopieren.

Dazu war der Ablauf wie folgt.

  1. Kopieren der neuen dedupConfig.02.xml nach C:\Temp (auf dem Quellsystem ist dazu ebenfalls eine cmd.exe unter dem SYSTEM Account notwendig, also wieder PSEXEC verwenden
  2. Setzen des Data Deduplication Service auf deaktiviert (im Service-Manager)
  3. Kopieren der Datei nach D:\System …
  4. Setzen des Data Deduplication Service auf manuell und starten des Deduplication Settings Wizards im Servermanager – Fertig!

image

Danach war wieder eine Konfiguration der Einstellungen möglich und es wurde sofort wieder der korrekte Status der Deduplizierung angezeigt.

Enjoy it, b!