Das Windows Server Essentials Dashboard lässt sich nicht öffnen

Für einen neu angelegten Administrator war es nicht möglich das Dashboard des Windows Server Essentials 2016 zu öffnen. Der Versuch wurde mit der folgenden Fehlermeldung quittiert. Das folgende Bild zeigt die Meldung unter 2016 …

image

… oder wie im nächsten Bild zu sehen ist, die des Windows Server Essentials 2012R2.

image

Für die Fehleranalyse von Essentials spezifischen Funktionen sind die Logfiles im folgenden Verzeichnis ein guter Startpunkt:

C:\ProgramData\Microsoft\Windows Server\Logs

Dort befinden sich eine Reihe von Dashboard*.log Dateien, welche Informationen zur Ausführung des Dashboards gespeichert haben.

---------------------------------------------------------
[5016] 190312.115710.7435: General: Initializing...C:\Windows\system32\Essentials\Dashboard.exe
[5016] 190312.115711.4899: General: Failed to open ADTestHook registry key.
[5016] 190312.115711.4899: General: Failed to open ADTestHook registry key.
[6880] 190312.115711.6419: General: Color branding started
[6880] 190312.115711.6419: General: Processing Microsoft default SKU branding colors XML
[6880] 190312.115711.8369: General: Branding colors XML parsing started
[6880] 190312.115711.8659: General: Branding colors XML parsing ended
[6880] 190312.115711.8659: General: Looking for OEM branding colors XML
[6880] 190312.115711.8669: General: No OEM informations available
[6880] 190312.115711.8669: General: Color branding complete
[5016] 190312.115712.3499: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.3499: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.5779: General: Failed to open ADTestHook registry key.
[5016] 190312.115712.5779: General: Failed to open ADTestHook registry key.
[5016] 190312.115720.1563: Dashboard.Forms: Dashboard: Non domain admin cannot access dashboard.
---------------------------------------------------------

Besonders interessant fand ich die letzte Zeile mit dem Hinweis:

Non domain admin cannot access dashboard … der angelegte Admin war aber ein Domain Admin, sonst würde das auch keinen Sinn ergeben. Da die Mitgliedschaft über Gruppen geregelt wird, habe ich einen funktionierenden Domain Admin mit dem neuen Benutzer vergleichen und keinen Unterschied in den vorhandenen Gruppen feststellen können, bis ich im AD Objekt des Benutzers auf die Primäre Benutzergruppe (Primary group) gestoßen bin. Diese war bei dem funktionierendem Admin Domain Users und nicht Domain Admins wie bei dem Benutzer wo der Start des Dashboard fehlgeschlagen ist.

Eine Änderung von Domain Admins auf Domain Users, hat das Problem gelöst.

image

Das Dashboard konnte wieder geladen werden.

Enjoy it, b!

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ß.

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!

IPv6 Configuration OpenSuse Leap

Verwendet man eine FRITZ!Box in seinem LAN dann kann einem die schwer kontrollierbare Vergabe von IPv6-Adressen durchaus Probleme machen. Das Deaktivieren von IPv6 auf allen Windows Systemen halte ich hier für keine saubere Lösung, vielmehr habe ich mich dazu entschlossen die IPv6-Adressen selbst zu vergeben. Darüber will ich in diesem Blog aber gar nicht schreiben, sondern wie einem openSUSE Server eine funktionierende IPv6 Konfiguration eingestellt werden kann.

Eckdaten

  • IPv6 Adresse für den OpenSuse Server: fd8e:5644:167b:100a::18
  • IPv6 Adresse für den Router / Gateway: fd8e:5644:167b:100a::1
  • Interface für die Konfiguration: eth0

Konfiguration

Im Gegensatz zu Windows, ist es bei Linux möglich IP-Adressen nur zur Laufzeit zu konfigurieren oder aber statisch, damit die Konfiguration einen Neustart überlebt.

Die Konfiguration zur Laufzeit ist dabei recht einfach, benötigt aber die Rechte des SU.

# ip -6 address add fd8e:5644:167b:100a::18/64 dev eth0

# ip -6 route add default via fd8e:5644:167b:100a::1 dev eth0

Statisch erfolgt die Konfiguration wie folgt:

# cd /etc/sysconfig/network

# vi ifcfg-eth0

# hinzufügen der folgenden Zeilen ans Ende der Datei (ifcfg-eth0)
LABEL_0='0'
IPADDR_0='fd8e:5644:167b:100a::18'
PREFIXLEN_0='64'

# echo 'default fd8e:5644:167b:100a::1 - -' >> /etc/sysconfig/network/routes

Damit die Konfiguration aktiv wird, entweder den Server neu starten oder den folgenden Befehl ausführen.

# service network restart

Enjoy it, b!

WSE und Shared Folders

Historisch gesehen, hat man Laufwerke aus dem Netzwerk schon immer verbunden. Das war nicht erst mit Windows schon, auch unter Novell Netware und OS/2 gab es Laufwerksmappings.

net use * \\server\share 

Was vielleicht für den Anwender aus heutiger Sicht immer noch sehr praktisch sein mag, stellt die Administratoren (zumindest seit wir mit der Verschlüsselungsthematik durch Cryptlocker kämpfen müssen) vor ungeahnte Probleme.

1. Kann so ein Virus problemlos der Reihe nach alle Laufwerke verschlüsseln, er findet einfach durch deren Zuordnung

2. Ist die Anzahl der Laufwerke durch die freien Buchstaben im Alphabet begrenzt.

Zusätzlich binden sich immer mehr Cloud-Laufwerke in den Windows Explorer ein (OneDrive, Amazon, …) und lassen sich nicht mehr so ohne weiteres mit net use im klassischen Sinne verbinden. Mein Gefühl sagt mir, Laufwerke sind out und das folgende Bild zeigt die neue Welt.

image

Die Freigaben des Windows Server Essentials tauchen als “Shared Folders” genauso im Explorer auf wie das oder die OneDrives. Nun lässt sich mit den Share Folders des WSE ausgezeichnet im Explorer arbeiten, möchte ich aber an der Eingabeaufforderung zum Beispiel eine Datei aus meinem OneDrive in meine Eigenen Dateien kopieren, wird die Sache doch recht gruselig, Anführungszeichen sind wegen den Leerzeichen in folder redirection notwendig und die automatische Erweiterung der Pfade funktioniert auch erst ab genau dieser Ebene.

xcopy \Users\hans\OneDrive\_Config\keepass\MyPasswords-2018-09-25-01.kdbx "\\sbe\folder redirection\hans\_config\keepass" 

Um nicht wieder zu den über net use zugewiesenen Laufwerken zurück kehren zu müssen, habe ich auf meinem WSE eine kurze Freigabe über die folder redirection gelegt:

net share fr$="D:\ServerFolders\Folder Redirection" /grant:users,change 

und für Server in deutscher Sprache

net share fr$="D:\ServerFolders\Folder Redirection" /grant: benutzer,change 

Damit kann ich nun wieder Dateien einfacher kopieren:

xcopy \Users\hans\OneDrive\_Config\keepass\MyPasswords-2018-09-25-01.kdbx \\sbe\fr$\hans\_config\keepass 

Vielleicht hilft dieser kleine Workaround dem einen oder anderen von Euch weiter.

Enjoy it, b!

Windows (Vista) ++: Start des “elevated Command Prompt” in einem definiertem Verzeichnis

Startet man unter Windows Vista oder in einer der neueren Versionen den “Command Prompt” (auch Experten GUI genannt 😉 ) mit erhöhten Rechten (elevated rights) so landet man im Verzeichnis %windir%\system32.

image

Da dieses Verzeichnis das Systemverzeichnis des Betriebssystems darstellt und hier ein unachtsam abgesetzter Befehl fatale Folgen haben kann, ist es unter Umständen wünschenswert in einem anderen Verzeichnis, z.B. c:\temp per Default zu arbeiten. Dazu muss lediglich die Verknüpfung welche den Command Prompt startet, modifiziert werden.

Das kann durch eine Änderung des Target in den Eigenschaften der Verknüpfung erreicht werden. Der folgende Aufruf definiert für den Command Prompt egal, ob elevated oder nicht, dass Verzeichnis c:\temp als Arbeitsverzeichnis:

%SystemRoot%\system32\cmd.exe /k cd /d c:\temp

image

Der Wert in Start in muss nicht zwingend geändert werden, es reicht wenn der Target wie oben geschrieben, gesetzt wird.

Nach der Änderung sieht das dann so aus:

image

Wer dann meint er muss im Systemverzeichnis irgendwelche Dummheiten machen, kann immer noch dahin wechseln 🙂

Update 21.03.2019:
Da der Blog 2009 noch auf der Microsoft Blogging Plattform Live erschienen ist und für mich seine Aktualität behalten hat, habe ich nochmals die verloren gegangenen Screenshots korrigiert und diesen Beitrag auf Vordermann gebracht.

Dazu noch eine kleine Erinnerung, obwohl es viele von Euch immer noch lieben, Windows 7 geht langsam aber sich seinem Ende zu. Hier lohnt sich ein Blick in die Support-Lifecycle Datenbank bei Microsoft:

https://support.microsoft.com/de-de/lifecycle/search

Cheers Enjoy it, b!