Windows 10 Update 1903 und der Essentials Connector – Fix

Zumindest aus Sicht des Windows Server Essentials Connector ist jedes Update von Windows 10 spannend. Der seit gestern offiziell verfügbare Build 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. Diese sind nach dem Update einfach 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.

<#     Disclaimer     The author isn't responsible or gives any warranties in cases of data loss or unwanted modifications!

#>

<#   .SYNOPSIS
Fix Windows Server Essentials Launchpad for Windows Build 1903 get the Windows Server Essentials Launchpad back working on an Upgraded Windows 10 1903 client.

.DESCRIPTION
Adds missing Registry Keys to enable the Windows Server Essentials Launchpad again.

.NOTES

File Name : Fix-WSELaunchpad-1903.ps1
Authors : Bernd Pfann (sbsland@outlook.de)
Version : 0.01.0 (24/05/2019)

.LINK
none

.EXAMPLE
Fix-WSELaunchpad-1903.ps1         Adds missing registry to bring Windows Server Essential Services back on the client.

#>

<#

History
0.01, initial version

#>

# Parameters

# Setting Debug Level

Set-PSDebug -Trace 0

# Variables
[string]$Log = $env:temp + "\Fix-WSELaunchpad-1903.log"
[string]$Msg = "Fixing Windows Server Essentials Launchpad on Windows 10 Client Build 1903, Copyright sbsland.me 2019"
[int]$Build = 1903

# Start of output logging and error handling
$ErrorActionPreference = "Continue"
Start-Transcript -Path $Log | Out-Null

# Header
Write-Output`n$msg`n

# Main Program
If ($Build -eq (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name ReleaseID -ErrorAction Stop).ReleaseID) {     Write-Output " Windows 10 is running on build $Build ..."     Write-Output " Adding missing Registry Keys ..."     reg import .\ServiceProviderRegistry.reg     reg import .\WseClientMgmtSvc.reg     reg import .\WseClientMonitorSvc.reg     reg import .\WseHealthSvc.reg     reg import .\WseNtfSvc.reg     Write-Output " Registry Keys have been added, please reboot your Computer."
} Else {     Write-Output " Windows 10 isn't running on build $Build, no action is required."
}

Write-Output " Script finished!"
Stop-Transcript | Out-Null

# Resetting Debug Level
Set-PSDebug-Trace 0

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 Build 1903 handelt, nur dann werden die REG-Dateien in die lokale Registry des Rechners 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.

Enjoy it, b!

Death man walking

Hallo zusammen, das hier ist genau genommen kein Artikel wie ein Problem gelöst werden kann. Vielmehr soll es darum gehen wie ein Problem erst gar nicht entsteht, konkret geht es um einen potenziellen Angriffsvektor der nur zu gerne übersehen und vergessen wird – der lokale Admin!

Installiert man einen Windows Server neu, dann muss im Verlauf des Setups das Admin Passwort vergeben werden … der sich immer in Eile befindliche Admin (Installateur) verwendet hier gerne mal etwas Einfaches wie admin, 1234, … und vergisst nachdem der Server in die Domäne integriert wurde den lokalen Admin zu ändern oder zu deaktivieren. Bei Windows 10, also mit dem Client verhält es sich nicht viel anders, hier muss ein Benutzer angelegt werden und fällt die Wahl auf admin/admin dann ist hier ebenfalls ein Angriffsvektor vorhanden.

Erfolgt dann eine Exposition des Servers per RDP ins Internet, steht der lokale Administrator mit seinem trivialen Passwort eine leichte Aufgabe für Hacker dar.

Darum an dieser Stelle der Rat, ein schwieriges Passwort zu verwenden und im Nachgang den lokalen Administrator zu deaktivieren. Sollte ein lokaler Administrator zwingend benötigt werden, dann lege ich immer einen weiteren Admin, der dann auch nicht Administrator sondern irgendwie anders heißt.

image

Das sieht dann wie oben aus.

Enjoy it, b!

TimeSync mit pool.ntp.org

Für meine auf Windows basierten AD Server verwende ich als Zeitquelle pool.ntp.org. Dort gibt es inzwischen eine Beschreibung wie den der Server zu konfigurieren ist:

# Neuere Windows Versionen

w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org"

# Ältere Windows Version, ohne w32tm

net time /setsntp:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org"

Natürlich gibt es auch für Linux entsprechende Hinweise wie die Konfiguration zu erfolgen hat.

Enjoy it, b!