Suchen und Ersetzen Tools

In diesem Artikel geht es um Tools zum Suchen und Ersetzen mit einer grafischen Oberfläche. Bereits im allerersten Empirum Projekt habe ich das Serach&Replace von Funduc lizenziert, da ich damals kein anderes ähnlich geartetes Tool gefunden hatte. Dieses Tool leistet mir noch heute verlässliche Dienste. Im Laufe der Zeit habe ich bei Kunden auch den Agent Ransack kennengelernt, der eine ähnliche Funktion hat. Mittlerweile zähle ich die freien Tools dnGrep und grepWin dazu. Wer das letztgenannte grepWin herunterladen möchte, wechselt am besten direkt auf github, um den Werbe- und Downloadbannern zu anderen ungewünschten Angeboten aus dem Weg zu gehen. Auch der bei vielen beliebte Editor „Notepad++“ bietet im Menü unter Search/Suchen eine Funktion zum Durchsuchen von Dateien an.

Funktionsumfang

Auf die Funktionen und Unterschiede der verschiedenen Tools, werde ich an dieser Stelle nicht eingehen. Generell bieten jedoch alle Tools, das Suchen …

• in einem definierten Pfad
• nach definierten Dateiendungen und teilweise auch in Archiven
• nach einer Zeichenkette
• Speichern des angezeigten Ergebnisses als Text oder HTML Datei

Warum Suchen und Ersetzen?

Nun, diese Tools nutze ich aus verschiedenen Gründen.

1. Durchsuchen der Empirum Pakete nach bestimmten Befehlen, Aufrufen, absoluten EmpirumServer Einträgen, Benutzern und Gruppen.
2. Durchsuchen der gesamten Empirum Partition nach bestimmten Benutzern und Gruppen in Bezug auf Verbesserung der Sicherheit
3. Das Ergebnis des Durchsuchens bildet zumeist die Grundlage für weitere Aufgaben (Anpassen, Testen, schaffen von neuen Lösungen).
4. Teilweise kann die Lösung ein Ersetzen der gefundenen Zeichenkette, durch eine neue sein.

Dein Tool der Wahl?

Welches Tool nutzt Du für diesen Zweck oder hast eine Empfehlung für die Leser des Blogs. Schreib doch Dein Suchen & Ersetzen Lieblingstool in den Kommentar. Danke, Grüße und bis bald – Jochen

Der Beitrag Suchen und Ersetzen Tools erschien zuerst auf Workplace Management Blog.

Unattended Uninstallation Dialog

Wenn Du beim Nutzen des Package Wizards zum Erstellen einer „Unattended“ sprich „Silent“ Installation einer EXE an den Dialog zur Deinstallation kommst, kannst Du das „Basis Verzeichnis“ nicht anpassen. In das Eingabefeld für das Deinstallationsprogramm kannst Du den Aufruf „C:\Program Files (x86)\My Program\unins000.exe“ eintragen und den Assistenten erfolgreich beenden.

Deinstallation schlägt fehl

Die Tests zur Deinstallation des Programms im Rahmen der Paketierung schlagen fehl. Warum?

Fehlersuche / Behebung

Um herauszufinden, warum der Fehler auftritt, müssen wir uns die Abfolge der Befehle zur Deinstallation der Software in unserem erstellten Paket ansehen. Ein Blick in die Sektion [Set:Deinstallation] der Setup.inf, die für die Deinstallation zuständig ist, bringt den Fehler schnell zum Vorschein. Hier wird versucht, den folgenden Befehl auszuführen:

-Call "%Src%\C:\Program Files (x86)\My Program\unins000.exe" /S

Der Teil „%SRC%\C:\…“ sieht nicht nur seltsam aus, sondern kann auch nicht funktionieren. Angepasst, sollte der Aufruf wie folgt ausschauen:

-Call "C:\Program Files (x86)\My Program\unins000.exe" /S

oder besser noch

-Call "%ProgramFilesDirx86%\My Program\unins000.exe" /S

Mit diesen Anpassungen sollte die Deinstallation nun erfolgreich durchgeführt werden.

Anpassen der Vorlage

Damit die Anpassung nicht immer wieder im erstellten Paket vorgenommen werden muss, passt man die Vorlage „Unattended.inf“ (Empirum\Configurator\Packages\Matrix42\Packaging Center\<Version>\Templates) an. Dazu entfernt man aus der nachfolgenden Zeile:

-Call "%Src%\{UnattDeInst}" {UnattDeInstPar}

das %SRC%\ und macht daraus:

-Call "{UnattDeInst}" {UnattDeInstPar}

Der Beitrag Empirum Paket – Deinstallation ohne Quellen erschien zuerst auf Workplace Management Blog.

Was ist das Problem?

Die Installation des WinPE Paketes „LanguagePacksInstallation“ läuft erfolgreich durch, jedoch befindet sich das LanguagePack anschließend nicht im installierten Windows.

Ergänzender Hinweis

Es gibt für Windows 10 1909 keine separaten LanguagePack Quellen. Das Build 1909 nutzt die gleichen Quellen wie das Build 1903. Das bezieht sich auch, wie ich schon festgestellt habe, auf das WADK – auch hier wird auf die Version 1903 verwiesen.

Lösungsvorschläge

Nun aber zu den Lösungsvorschlägen. Diese sind im Original auch in den Kommentaren zu nachzulesen. Da die Formatierung der Kommentare nur eingeschränkt ist, habe ich es hier nochmals zusammengefasst.

Zwei Lösungsmöglichkeiten

Es gibt zwei von Ingo getestete Lösungsvorschläge.

• Die Windows 10 Build 1909 Quellen auf einen neueren Stand bringen, der die Installation wieder erlaubt (gleich oder neuer als 18363.476). Das aktuelle Update gibt es im Matrix42 Patch-Management oder im Windows Catalog zum Download.
• Das Sprachpaket direkt in die Quellen integrieren.

Für beide Fälle ist eine Anpassung der Quellen notwendig (Sicherheitskopie anfertigen!). Dazu sollte man mit dem Umgang der DISM oder äquivalenten Powershell Befehle vertraut sein. Alternativ kann man es bestimmt auch mit DISM GUI oder DISM++ bewerkstelligen. Mit beiden genannten DISM GUI Tools habe ich leider noch keine Erfahrung gesammelt.

Grober Ablauf

• Passenden Index herausfinden. Da die Windows Images zumeist mehrere Editionen enthalten, muss man vor einer Anpassung wissen, welchen Index man nutzt.
• Mounten des Images/Index in einen Ordner
• Hinzufügen des Updates oder des Sprachpaketes (später Schritt 3)
• Dismounten des Images

Befehle

Die nachfolgenden Befehle beinhalten mitunter Platzhalter oder beispielhafte Verzeichnisse, Indizes uvm.

;Schritt 1: Auflisten der Indizes und Windows Editionen
DISM /Get-Imageinfo /Imagefile:<Pfad>\install.wim

;Schritt 2: Mounten des genutzten Index - hier 5 in den Ordner D:\mount
DISM /Mount-Image /Imagefile:<Pfad>\install.wim /Index:5 /MountDir:D:\mount

;Schritt 3a: Hinzufügen des Updates 
DISM /Image:D:\Mount /Add-Package /Packagepath:<Pfad>\<Update.msu> 
;Schritt 3b: Hinzufügen des Sprachpaketes
;DISM /Image:D:_mount /Add-ProvisionedAppxPackage /PackagePath:<Pfad>\LanguageExperiencePack.de-DE.Neutral.appx /LicensePath:<Pfad>\License.xml)

;Schritt 4: Dismounten des Images 
DISM /Unmount-Image /MountDir:D:\mount /commit

;Schritt 5: (optional) Aufräumen nach getaner Arbeit
DISM /Cleanup-Wim

Euch – viel Erfolg!
Ingo – vielen Dank für das Teilen der Erkenntnisse!

Der Beitrag LanguagePacks und Windows 10 Build 1909 erschien zuerst auf Workplace Management Blog.

Erlaube Deinstallation

Ein Haken bei „Erlaube Deinstallation“ ermöglich ein Software-Paket über das Kiosk nicht nur zu installieren, sondern auch zu deinstallieren. Das Software Kiosk ist eine Eigenschaft des Empirum Agenten und auf dem Computer über das Tray-Symbol erreichbar. Unabhängig, ob der Haken bei dieser Option gesetzt ist oder nicht, kannst Du jederzeit dieses Software-Paket über die Management Oberfläche deinstallieren, wenn Dein Software Paket die Befehle dafür besitzt!
Genauer gesagt heißt diese Option: Erlaube Deinstallation im Software Kiosk.
Dazu kann direkt nach einem Installieren, ein erneutes Aufrufen des Software Kioskes notwendig sein.

Nur bei Verteilung benutzen

Wenn wir auf diesem Reiter der Paketeigenschaften gerade sind. Was bedeutet „Nur bei der Verteilung benutzen“? Diese Option gibt es auch auf dem Register in dem sich die Software im Depot befindet. „Nur bei Verteilung benutzen“ bedeutet eigentlich: Nicht im Software Kiosk anzeigen.
Wenn Du das Register nicht anzeigst, wird alle darin befindliche Software nicht im Software Kiosk angezeigt. Möchtest Du eine einzelne Software nicht im Software Kiosk anzeigen, so kannst Du das „pro Paket“ setzen.

Der Beitrag Empirum Paketeigenschaft – Erlaube Deinstallation erschien zuerst auf Workplace Management Blog.

Bis Empirum v18.0.2 konnte man mit Empirum nur WIM Dateien verarbeiten bzw. importieren. Das soll sich in Kürze ändern. Auf der anderen Seite werden dann ab der Empirum v18.0.2 alle in der WIM oder esd Datei befindlichen Produkteditionen in der Oberfläche angezeigt. Das könnte wiederum dem ein oder anderen Administratoren weniger gut gefallen, denn schlussendlich möchte man standardisierte Installationen durchführen und Fehler minimieren.

Muss man nun die esd in eine WIM Datei wandeln, oder eine Produktedition aus einem Datenträger mit mehreren Editionen extrahieren, so bedarf es einiger weniger DISM „Kniffe“.

Auslesen der in der WIM Datei enthaltenen Editionen

Das Auslesen geschieht über den nachfolgenden DISM Befehl.
Hierbei ist es wichtig, dass …

• die Kommandozeile als Administrator ausgeführt zu haben.
• die eingesetzte DISM Version die gleiche oder höhere Version des zu bearbeitenden Datenträgers besitzt.

Dism /Get-WimInfo

dism /Get-WimInfo /wimfile:install.wim
oder eben auch ...
dism /Get-WimInfo /wimfile:install.esd

Die Ausgabe sollte wie folgt aussehen und ggf. mehrere Einträge mit unterschiedlichen Index Werten besitzen:

...
Index: "1"
Name: "Windows 7 Professional"
Beschreibung: "Windows 7 Professional"
...

Extrahieren einer Windows Edition

Mit dem zweiten Befehl und dem passenden Index im Kopf extrahiert man nun die entsprechende Edition in eine einzelne separate Datei.

dism /export-image /SourceImageFile:install.esd /SourceIndex:1 /DestinationImageFile:install.wim /Compress:max /CheckIntegrity
oder
dism /export-image /SourceImageFile:install.esd /SourceIndex:1 /DestinationImageFile:installproonly.wim /Compress:max /CheckIntegrity

Ersetzen in den Quellen

Vor dem Importieren in Empirum ersetzt man nun die install.wim im oben genannten „sources“ Ordner durch die neue install.wim. Die neue Datei im „sources“ Ordner sollte am Ende auch wieder install.wim heißen.

Wer sich mehr über das WIM Format aneignen möchte, wird hier fündig: Windows Imaging File Format (WIM)

Jetzt sollten die Befehle zur Hand sein, wenn es nötig wird ;).

Der Beitrag Install.esd umwandeln und einzelne Windows Edition extrahieren erschien zuerst auf Workplace Management Blog.

Was muss man tun, um es zu nutzen?

WinPE Erweiterung installieren.

Zu aller erst muss man die WinPE Erweiterung installieren. Wie zuvor beschrieben gibt es die WinPE Booterweiterung im Matrix42 Marketplace. Diese Erweiterung musst Du in Deine Empirum Umgebung installieren/kopieren. Dazu liegt dem Download ein PDF bei, dass die Installation beschreibt.

Installation des WADK auf dem EmpirumServer

Auf dem EmpirumServer muss das WADK (möglichst aktuell) installiert sein. Die WinPE Erweiterung bedient sich dem installierten WADK und nicht dem in Empirum importierten WADK. Die Installation des WADK habe ich im Beitrag „Matrix42 OS Deployment mit WinPE – Vorausetzungen“ bereits beschrieben.

Erstellen einer Bootkonfiguration

Anschließend muss eine Bootkonfiguration vom Typ „WinPE“ anstatt „EPE“ erstellt werden. Dabei wird das PXE-Image mit dem Inhalt des WinPE erstellt. Die Besonderheiten bzgl. der Optionen EFI und BIOS sind ebenfalls in dem WinPE HowTo PDF Dokument erläutert.

WinPE PXE-Image

Das erstellte WinPE PXE-Image enthält den Matrix42 UAF (Universal Agent Framework). Der UAF wird dazu benutzt die PreOS-Pakete (Empirum Pakete für die WinPE Verarbeitung) auszuführen. Matrix42 liefert einige WinPE Beispielspakete mit. Schlußendlich bestimmen mehrere einzelne PreOS-Pakete die WinPE Auftragsabfolge bis der PXE-Boot deaktiviert wird.
Zum Beispiel kann man mit den folgenden drei Paketen eine Windows 10 Installation durchführen.

• DiskPartitioning (Vorbereiten/Partitionieren der Festplatte)
• DriverIntegration (Ablegen der Hardware-Modell spezifischen Treiber)
• WindowsInstallation (Installation von Windows 10 unter Nutzung der abgelegten Treiber)

Gesteuert werden diese Pakete über dazugehörige Variablen die pro Gruppe oder Computer gesetzt werden. Hier muss man etwas umdenken, da man keine Betriebssystemvorlage mehr erstellt und zuweist, sondern die PreOS-Pakete zuweist und die dazugehörigen Variablen setzt.

Bei der zuvor genannten Abfolge muss nicht Schluß sein. So kann man vor der OS Installation ggf. auch das BIOS aktualisieren und konfigurieren uvm. Für die BIOS Aktualisierung hat Matrix42 auch bereits ein Paket bereitgestellt.

Mein Fazit

Die Idee WinPE zum Starten und Verarbeiten von Befehlen per PXE birgt viel Potential für die Zukunft, da u.a. die Basis Windows anstatt Linux und die genutzte Skript-Sprache powershell anstatt „EIS“ ist. Von den bereitgestellten PreOS-Paketen bin ich jedoch etwas enttäuscht. Das DriverIntegration, WindowsInstallation und BIOSUpdate Paket kann man meines Erachtens als Grundlage und erahnen der Möglichkeiten nutzen bzw. auf deren Grundlage eigene Pakete erstellen. Die Nutzung dieser Pakete zur produktiven Installation von Windows 10 Systemen stehe ich jedoch noch kritisch gegenüber. Mehr dazu in Kürze.

Wenn Du es bereits getestet hast – wie ist Dein bisheriges Fazit?

Der Beitrag Empirum: WinPE anstatt EPE als PXE-Image erschien zuerst auf Workplace Management Blog.

Die Anpassung der NTFS Berechtigung ist dann notwendig, wenn das paketierte Programm:

• in Laufzeit Änderungen im gleichen Verzeichnis vornimmt (INI+LOG Dateien, o.ä)
• eine AutoUpdate Funktionen für sich selbst anbietet

Wo und wie wird die Berechtigungsvergabe vorgenommen?

Die „Wo“ Frage ist recht einfach beantwortet. Dafür gibt es die [Security:Product] Sektion. Die Security:Product Sektion muss nach der Installation durchgeführt werden, damit der Ordner oder die Dateien bereits vorhanden sind. In den Standard Inf Vorlagen ist dies auch der Fall.

Kommen wir zur „Wie“ Frage …

Um die Berechtigung zu setzen, gibt für Windows 2000 und neuer den Befehl FileDaclEx.Add. Der Befehl ist in der Setup.inf wie folgt aufgebaut:
FileDaclEx.Add (<Datei>, <Name>, <Operation>, <Rechte>, <Vererbung>)

Will man nun der Gruppe der lokalen Benutzer, der im Standard alle Domänen Benutzer angehören Vollzugriff gewähren, dann sieht der Befehl wie folgt aus:

FileDaclEx.Add ("%App%", "%$LocalUsers%", GRANT, ALL, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

Will man jedoch nicht so freizügig mit den Berechtigungen umgehen und der Gruppe lediglich Ändern Berechtigungen geben, dann wird der Befehl etwas komplexer, da es für Ändern (Change) keine einzelne Berechtigung gibt. Die Berechtigung „Ändern“ entspricht den nachfolgenden Teil-Berechtigungen: TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC EXECUTE

Das sieht in der Windows 10 Oberfläche nicht viel anders aus, wenn man mal in den Sicherheitseinstellungen unter Erweitert nachschaut.

Wie sieht nun ein solcher Befehl in der Praxis aus? Hier ein paar Beispiele:

FileDaclEx.Add ("%App%", "%$LocalUsers%", GRANT, TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

FileDaclEx.Add ("%ProgramFiles%\%Developername%", "%$LocalUsers%", GRANT, TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

FileDaclEx.Add ("%App%\Application.ini", "%$LocalUsers%", GRANT, TRAVERSE LIST_DIRECTORY READ_ATTRIBUTES READ_EA ADD_FILE ADD_SUBDIRECTORY WRITE_ATTRIBUTES WRITE_EA DELETE READ_DAC, SUB_CONTAINERS_AND_OBJECTS_INHERIT)

Wenn ihr diese Anforderung häufiger habt, so könnt ihr einen der obigen Befehle in eure Paketierungsvorlagen (Template.inf, MSI.inf, Unattend.inf) einbauen und bei Bedarf den Kommentar (;) wegnehmen und den Befehl den Anforderungen nach anpassen.

Ist das alles?

Weiterführende Informationen, da die Security:Sektion noch mehr kann als NTFS Berechtigungen zu setzen:

• Welche Befehle darüber hinaus zur Verfügung stehen und welche andere Berechtigungen ihr setzen könnt, findet ihr in der Online Hilfe unter „Security:Product„.
• Welche Benutzer bzw. Gruppen per Variable und somit sprachunabhängig zur Verfügung stehen findet ihr am Ende der Tabelle „Vordefinierte Umgebungsvariablen“ der Online-Hilfe.

Der Beitrag Empirum – NTFS Berechtigungen setzen erschien zuerst auf Workplace Management Blog.

Fehler bei der Installation?

Die einfachste Überprüfung ist ein Blick in das SWDepot-Log des entsprechenden Computers. Ist ein Fehler bei der Installation aufgetreten? Wenn im SWDepot-Log ein Fehler vermerkt ist und die Software trotzalledem auf dem Computer vorhanden ist, so lautet der Fehler zumeist ErrorLevel:0. In diesem Fall ist etwas bei der Erfolgsüberprüfung nach der Installation fehlgeschlagen. Zumeist gibt es den abgefragten Registry Wert in der Form nicht. Es können natürlich auch andere Installationsprobleme sein, denen dann auf den Grund gegangen werden muss.

Falls das Paket jedoch noch den Status „Running“ besitzt, hat vielleicht ein externer Aufruf (Call) im Paket einen Neustart durchgeführt. Hier wäre zu prüfen, ob ein Parameter wie /norestart o.ä. an die Installation angehängt werden kann.

Stimmen die MachineKeyNames überein?

Hierzu sind die Werte des Schlüssels in der Registrierung (im Software-Depot, Eigenschaft des Software-Paketes) und der dazugehörigen Setup.inf zu prüfen. Diese müssen überein stimmen. Im hier angezeigten Falle habe ich absichtlich einen „Fehler“ eingebaut.

Der ProductName müsste korrekterweise „Notepad++ (32Bit) MUI“ lauten. Dieses Problem lässt sich durch einen Versionsabgleich beheben.

Verteilungsoption „Immer erzwingen“

Wenn das Software-Paket die Verteilungsoption „Immer erzwingen“ eingestellt hat, so wird die Installation auch bei jedem Polling Intervall durchgeführt. Dies ist zumeist daran zu erkennen, dass das Software-Paket blau eingefärbt ist.

Architekturwechsel in der Paket-Familie

Ersetzt ein „neues“ Paket ein Vorgänger-Paket und dabei wurde der Platform Wert in der Setup.inf geändert, kann es auch dazu kommen, dass der Empirum-Agent immer wieder eine Aktualisierung durchführen möchte. Hierbei muss geprüft werden, ob das Vorgängerpaket vielleicht Platform=x64 und das neue Paket Platform=x86 eingestellt hat. Wenn dies der Fall ist, kann das neue Paket die Registry Werte des Vorgänger Paketes nicht löschen. Somit sollte man das neue Paket auch auf den identischen Platform Wert setzen. Das Paket sollte dann natürlich nochmals gut getestet bzw. überprüft werden.
Ich hoffe, ich habe keine anderen Fälle ausgelassen. Wenn ihr ein anders geartetes Problem habt, so lasst es mich wissen.

Der Beitrag Empirum Paket wird immer wieder installiert. Warum? erschien zuerst auf Workplace Management Blog.

Es gibt jedoch Besonderheiten bei diesem Befehl. Die For … Next Schleife wird beim Install als auch beim Uninstall ausgeführt und benötigt kein „-„. Beim Uninstall zählt die For Schleife jedoch „umgekehrt“. Dies ist in der Hilfe so nicht näher erläutert. Anbei findet Ihr die Erläuterung aus der Matrix42 Hilfe, als auch ein Empirum Setup.inf Ausschnitt mit zwei Beispielen.

Auszug aus der Online Hilfe

For <Var>,<LB>,<UB>,<Inc>,<Abschnitt>

Führt eine FOR-Schleife aus. Die Zählvariable ist <Var> wird von der Untergrenze <LB> zur Obergrenze <UB> in <Inc> Schritten hoch gezählt. Jedes Mal wird der Abschnitt <Abschnitt> aufgerufen. Die Zahlen dürfen auch negativ sein sowie Ober- und Untergrenze vertauscht werden (Abwärtsschleife). Wird <Inc> leer gelassen, wird 1 bzw. -1 angenommen.

Beispiel: For Counter,1,3,,UpSection

Setup.inf Beispiel

[Environment]
VALUE1=Hello
VALUE2=World
VALUE3=!

[Product]
#Set:Installation, DONTDELETE
#Set:Deinstallation, DELETE

[SET:Installation]
FOR counter,1,5,,ECHOCounter
FOR counter,1,3,,ECHOValues

[ECHOCounter]
ECHO Installation : %Counter%
-ECHO DeInstallation : %Counter%

[ECHOValues]
SET EchoVALUE=%%Value%Counter%%%
ReplaceEnv EchoValue
ECHO %EchoValue%

[SET:Deinstallation]
;--This counts from 5 to 1 during UNINSTALL!
FOR counter,1,5,,ECHOCounter
-ECHO FOR counter,1,5,,ECHOCounter

;--This counts from 1 to 5 during UNINSTALL!
FOR counter,5,1,-1,ECHOCounter
-ECHO FOR counter,5,1,-1,ECHOCounter

Der Beitrag Empirum und For – Next Schleife erschien zuerst auf Workplace Management Blog.

Windows 10

Im Unternehmensumfeld werden die Microsoft Aktivierungsanfragen sehr gerne mit einem zentralen Server verwaltet und nicht alle direkt gegen die Microsoft Server ausgeführt. Dies geschieht über den Key Management Server oder besser als KMS Server bekannt. Der KMS Server beantwortet die Aktivierungsanfragen im lokalen Netzwerk. Wer sich tiefer in die Materie einarbeiten möchte, dem lege ich die entsprechenden TechNet Artikel ans Herz.

In diesem Blog Eintrag geht es um die Besonderheiten bei der Aktivierung von Windows 10 in einem vorhandenen Umfeld. Hierbei sind Dinge auf der Client- als auch der Serverseite zu beachten.

Windows 10 Client

Die Quellen von Windows 10 enthalten einen Key, mit dem sie sich am KMS Server registrieren können. Wenn das Windows 10 mittels Empirum verteilt wird, so sollte man zur Sicherheit, bei der entsprechenden Betriebssystemvorlage für Windows 10,
den jeweiligen KMS Client Setup Key hinterlegen. Wenn der KMS Client Setup Key nicht zur verknüpften Windows 10 Quelle passt,
dann bleibt die unbeaufsichtigte Installation mit der Auswahl der Edition stehen bzw. zeigt an, dass kein Image zur Installation zur Verfügung steht.

Anbei eine Liste der Windows 10 KMS Client Setup Keys.
Diese Liste ist hier direkt bei Microsoft einzusehen.

• Windows 10 Professional: W269N-WFGWX-YVC9B-4J6C9-T83GX
• Windows 10 Enterprise: NPPR9-FWDCX-D2C8J-H872K-2YT43
• Windows 10 Education: NW6C2-QMPVW-D7KKK-3GKT6-VCFB2
• Windows 10 Enterprise 2015 LTSB: WNMTR-4C88C-JK8YV-HQ7T2-76DF9
• Windows 10 Enterprise 2016 LTSB: DCPHK-NFMTC-H88MJ-PFHPY-QJ4BJ
• Windows 10 Enterprise 2019 LTSC: M7XTQ-FN8P6-TTKYV-9D4CC-J462D

KMS Server

Auf dem KMS Server sind mehrere Dinge zu beachten. Da das Betriebssystem auf dem Client aktueller ist als das Betriebssystem des KMS Servers, muss am KMS Server ein Microsoft Update eingespielt werden. Dieses Update ist unter dem KB3058168 veröffentlicht.

#Update: Dieses Windows Update ist für einen Windows Server 2008 R2 / Windows 7 notwendig, um Windows 10 Clients zu aktivieren: KB3079821.

Die für den KMS Server notwendigen Lizenzschlüssel sind für den Unternehmenskunden in dem Customer Support – Volume License Service Center hinterlegt. Für die Aktivierung von Windows 10 wird zusätzlich ein weiterer Key benötigt! Die nachfolgenden Schlüssel sind dem Portal zu entnehmen und im KMS Server zu hinterlegen.

• Windows 10 Enterprise, oder die eingesetzte Edition
• Windows Srv 2012R2 DataCtr/Std KMS for Windows 10

Die Quelle zu diesen Informationen ist hier zu finden.
Falls die Einbindung der zuvor genannten beiden Keys über die VAMT Oberfläche nicht funktioniert, so sind die Lizenzschlüssel mit den folgenden Befehlen zu installieren:

• slmgr -ipk <KMS Host Product Key – channel C>
• slmgr -ato

Hier geht es zu weiterführenden Informationen bzgl. VAMT und generellem KMS Server Troubleshooting.

Erste Schritte des Troubleshootings

• Prüfen, ob der KMS Server über den DNS Server korrekt publiziert wird: nslookup -type=srv _vlmcs._tcp
• Erreichbarkeit des KMS Server Dienstes sicherstellen (Standardport: 1688)
• Uhrzeit des Clients und des Servers überprüfen.

Dann bleibt mir nur noch, Euch eine erfolgreich Aktivierung Eurer Windows 10 Clients zu wünschen!

Der Beitrag Windows 10 und KMS Server Aktivierung erschien zuerst auf Workplace Management Blog.