ioBroker unter Windows Server 2019 as Docker

Docker in Windows Server 2019

Auf dem Windows Server 2019 habe ich bestimmte Features zu Linux etc. bereits installiert gehabt.

Nun installierte ich das Docker für Windows von Install Docker Desktop on Windows | Docker Documentation

Danach lief der Docker, aber bestimmte Sachen schienen nicht zu funktionieren. Auch das installieren eine Images von ioBrocker für Docker klappte nicht. Nach etwas Googlen bekam ich die Info, dass man den Deamon umswitchen muss. Das habe ich über CMD-Command erledigen können:

"C:\Program Files\Docker\Docker\DockerCli.exe" -SwitchDaemon

Das nächste Problem ließ nicht länger auf sich warten …

Hier half es in den Docker-Settings in der Docker Engine den Experimental-Mode zu aktivieren:

{
"experimental": true
}

Docker wurde neu gestartet und der Pull-Befehl konnte nun erfolgreich ablaufen:

 

Randnotizen (für mich)

https://docs.microsoft.com/de-de/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server

https://docs.microsoft.com/de-de/virtualization/windowscontainers/manage-containers/container-base-images

PowerShell-Command: docker pull mcr.microsoft.com/windows/iotcore:1809

ca. 310MB werden heruntergeladen und als Basisimage für den Container herangezogen

 

Windows Server Sicherung – schwerer Aufnahmefehler in „wbadmin.msc“

Problem

Die App/Dienst „Windows Server Sicherung“ konnte nicht mehr gestartet werden und es wurde ein schwerer Aufnahmefehler in „wbadmin.msc“ angezeigt.

Im Ereignisprotokoll standen mehrere Einträge mit Fehler in Quelle VSS und den Ereignis-ID’s 13, 12292 und 8228

Volumenschattenkopie-Dienst-Informationen: Der COM-Server mit CLSID {463948d2-035d-4d1d-9bfc-473fece07dab} und dem Namen "HWPRV" kann nicht gestartet werden. [0x8000401a, Der Serverprozess konnte nicht gestartet werden, da die konfigurierte Identität falsch ist. Überprüfen Sie Benutzernamen und Kennwort.

Mein Problem tratt nach einem Upgrade von Windows Server 2016 auf Windows Server 2019 auf.

Analyse

Bekannte DISM-Befehle haben nichts ungewöhliches gemeldet und auch nichts bewirkt/ repariert.

# Komponentenspeicher untersuchen mit DISM
dism.exe /online /Cleanup-Image /AnalyzeComponentStore

# Komponentenspeicher bereinigen
dism.exe /online /Cleanup-Image /StartComponentCleanup

# Analyse und Reparatur
dism /Online /Cleanup-Image /ScanHealth
dism /Online /Cleanup-Image /CheckHealth
dism /Online /Cleanup-Image /RestoreHealth
dism /Online /Cleanup-Image /RestoreHealth /Source:WIM:X:\Sources\Install.wim:1 /LimitAccess

Eine Lösung lag nicht auf der Hand und ich habe lange gerätselt.

Lösung

Nahe liegend war die Lösung nicht wirklich, aber es klappt mit dem zurücksetzen des Sicherheitskatalogs.

Öffnet CMD als Admin und gebt den nachfolgenden Befehl ein und bestätigt die Frage mit „Ja“. Es wird der aktuelle Sicherungskatalog gelöscht und ein neuer Sicherungssatz angelegt. Danach öffnet sich bei mir die App „Windows Server Sicherung“ (wbadmin.msc) wieder und ich konnte ein manuelles Backup erstellen.

 

Microsoft Windows Server 2019

Upgrade/ Update auf Windows Server 2019

Bevor ein Windows Server auf Windows Server 2019 aktualisiert wird, sollte man sich vorher einige Fragen stellen:

Upgrade auf einem Domain Controller

Windows Server 2016 auf Windows Server 2019

Bevor hier einfach z.B. von Windows Server 2016 auf Windows Server 2019 aktualisiert werden kann, sollte man das Domain-Schema aktualisieren! Beim InPlace-Upgrade erhält man hierzu sogar einen Hinweis, wenn man nicht das aktuelle Schema für Windows Server 2019 vorbereitet hat.

Prüpft ob Euer Domain-Admin auch Mitglied von „Schema-Admin“ und Organisation-Admin“ ist, wenn nicht, dann fügt dem Admin diese Rollen hinzu und meldet Euch ab und wieder an. Nur So seid Ihr sicher, das der Admin mit den richtigen Rechten unterwegs ist.

Prüft Euer vorhandenes Schema mit PowerShell. Öffnet PowerShell explizit als „Administrator“ und gebt folgende Befehl ein:

für adprep /forestprep

Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion

AD version objectVersion
Windows Server 2000 13
Windows Server 2003 30
Windows Server 2003 R2 31
Windows Server 2008 44
Windows Server 2008 R2 47
Windows Server 2012 56
Windows Server 2012 R2 69
Windows Server 2016 87
Windows Server 2019 88
für adprep /domainprep

get-adobject -ldapfilter ‘(&(objectClass=Container)(cn=ActiveDirectoryUpdate))’ -Properties *| select Name, CanonicalName,revision

Windows Server 2008 3
Windows Server 2008R2 5
Windows Server 2012 9
Windows Server 2012R2 10
Windows Server 2016 15
Windows Server 2019 16
für Forest Functional Level

get-adobject (Get-ADRootDSE).defaultnamingcontext -Properties * | select msDS-Behavior-Version

Windows Server 2000 Native 0,0
Windows Server 2000 Mixed 0,1
Windows Server 2003 2,0
Windows Server 2008 3,0
Windows Server 2008R2 4,0
Windows Server 2012 5,0
Windows Server 2012R2 6,0
Windows Server 2016 7,0
Windows Server 2019 7

Kopiert von der Installations-CD (Windows Server 2019) den Ordner „Support“ nach „C:\Server2019“ und startet die Commandbox explizit als „Administrator“. Gebt die Befehle nacheinander ein und schaut das diese mit Erfolgsmeldungen zurück kommen.

cd c:\server2019\support\adprep

adprep /forestprep

adprep /domainprep

Microsoft Windows [Version 10.0.14393] (c) 2016 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Windows\system32>cd c:\server2019\support\adprep

c:\Server2019\support\adprep>adprep /forestprep

ADPREP-WARNUNG:

Voraussetzung für die Ausführung von Adprep ist, dass auf allen Windows-basierten Active Directory-Domänencontrollern der Gesamtstruktur mindestens Windows Server 2003 verwendet wird.

Sie sind im Begriff, das Schema der Active Directory-Gesamtstruktur „fritz.box“ unter Verwendung des Active Directory-Domänencontrollers „hsdorn.fritz.box“ (Schemamaster) zu aktualisieren. Dieser Vorgang kann nicht mehr rückgängig gemacht werden.

[Benutzeraktion] Wenn auf allen Domänencontrollern der Gesamtstruktur mindestens Windows Server 2003 verwendet wird und Sie das Schema aktualisieren möchten, drücken Sie zur Bestätigung C und dann die EINGABETASTE. Drücken Sie andernfalls eine beliebige andere Taste und anschließend ebenfalls die EINGABETASTE.

c

Die aktuelle Schemaversion lautet „87“.

Schema wird auf Version „88“ aktualisiert…

Dateisignatur wird verifiziert Verbindung mit „hsdorn.fritz.box“ wird hergestellt. Anmelden als aktueller Benutzer unter Verwendung von SSPI Das Verzeichnis wird aus der Datei „c:\Server2019\support\adprep\sch88.ldf“ importiert. Die Einträge werden geladen……… 7 Einträge wurden erfolgreich geändert.

Der Befehl wurde einwandfrei durchgeführt. Verbindung mit „hsdorn.fritz.box“ wird hergestellt. Anmelden als aktueller Benutzer unter Verwendung von SSPI Das Verzeichnis wird aus der Datei „c:\Server2019\support\adprep\PAS.ldf“ importiert. Die Einträge werden geladen………………… 26 Einträge wurden erfolgreich geändert.

Der Befehl wurde einwandfrei durchgeführt. Die gesamtstrukturweiten Informationen wurden erfolgreich aktualisiert.

c:\Server2019\support\adprep> c:\Server2019\support\adprep>adprep /domainprep Die domänenweiten Informationen wurden erfolgreich aktualisiert.
Damit ist nur das Schema vorbereitet für 2019, aber noch nicht darauf umgestellt. Die Umstellung sollte erst geschehen, wenn man nur noch Windows Server 2019 im Einsatz hat.
Forest Functional Level anheben

$ADForest = Get-ADForest Set-ADForestMode -identity <your.forest> -Server $ADForest.SchemaMaster -ForestMode <Level>

Gültige Werte für Level sind:

Win2003Forest
Win2008Forest
Win2008R2Forest
Win2012Forest
Win2012R2Forest
Win2016Forest

Alternativ unter Systemsteuerung -> Active Directory-Verwaltungscenter kann mit Rechtsklick auf den Domainnamen das Schema angehoben werden.

Für Windows Server 2019 wurde keine eigene Funktionsebene eingeführt, dennoch muss man das Schema auf 88 vorbereiten/ Hinzufügen. Laut Microsoft gibt es keine neuen Funktionen aus Sicht von Active Directory. Daher ist auch ein Mischbetrieb von Windows Server 2016 und Windows Server 2019 möglich.

Ich persönlich würde aber davon abraten und es so handhaben wie bei jeder Vorversion auch. Alle Domain-Server auf ein Betriebssystem halten. Ich sehe auch zu, dass sich kein anderer „normaler“ Server aus der Vorversion im Domainnetzwerk befindet, bevor ich die Gesamtstruktur anhebe.