DISM im Blindflug: So lösen Sie das Problem, wenn der Featurename „ADCertificateServicesRole” plötzlich als unbekannt gemeldet wird

Einleitung
Stellen Sie sich vor, Sie arbeiten routiniert an einem **Windows Server**-System, sei es eine frische Installation oder ein System, das Sie gerade warten. Sie müssen die Active Directory-Zertifikatdienste (AD CS) installieren – eine essenzielle Rolle für die sichere Kommunikation und Authentifizierung in vielen Unternehmensumgebungen. Sie greifen zu Ihrem vertrauten Werkzeug, **DISM** (Deployment Image Servicing and Management), oder dem PowerShell-Äquivalent `Install-WindowsFeature`, und geben den Featurenamen `ADCertificateServicesRole` ein. Doch statt der erwarteten Erfolgsmeldung erhalten Sie eine Fehlermeldung: „Der Featurename **ADCertificateServicesRole** ist unbekannt.” Verwirrung macht sich breit. Wie kann ein so grundlegendes und bekanntes Feature plötzlich unbekannt sein? Dies ist der Moment, in dem der **DISM**-**Blindflug** beginnt, und genau hier setzt unser umfassender Guide an. Wir tauchen tief in die Ursachen dieses mysteriösen Problems ein und zeigen Ihnen detailliert, wie Sie den Überblick zurückgewinnen und die **Fehlerbehebung** erfolgreich durchführen können.

Das Problem im Detail: „Featurename unbekannt”
Der Fehler „Der Featurename **ADCertificateServicesRole** ist unbekannt” tritt auf, wenn DISM die angegebene Komponente nicht in seinem internen Katalog oder in der Referenzquelle finden kann. Das ist besonders irritierend, da `ADCertificateServicesRole` ein Standard-Feature von **Windows Server** ist, das seit vielen Generationen existiert. Es ist nicht wie ein obskures oder neu hinzugefügtes Feature, dessen Name leicht verwechselt werden könnte.
Dieser Fehler kann in verschiedenen Szenarien auftreten:
1. **Server Core Installationen:** Hier ist die Abhängigkeit von der Befehlszeile und präzisen Featurenamen besonders hoch.
2. **Offline-Wartung von Images:** Wenn Sie versuchen, Features zu einem WIM-Image hinzuzufügen, das nicht gebootet ist.
3. **Nach System-Updates:** Manchmal können kumulative Updates oder **Servicing Stack Updates (SSU)** das interne Feature-Verzeichnis von DISM beeinflussen, besonders wenn sie nicht vollständig oder korrekt angewendet wurden.
4. **Inkorrekte oder veraltete Quellen:** Wenn DISM eine externe Quelle benötigt, diese aber nicht aktuell ist oder nicht zur Ziel-OS-Version passt.

Die Implikationen sind gravierend: Ohne die Möglichkeit, die **ADCertificateServicesRole** zu installieren, können Sie keine PKI (Public Key Infrastructure) auf diesem Server aufbauen, was wiederum andere Dienste blockieren kann, die Zertifikate benötigen. Es ist daher unerlässlich, dieses Problem zu verstehen und effektiv zu lösen.

DISM und das Management von Quellen: Ein Grundverständnis
**DISM** ist das Schweizer Taschenmesser für die Wartung von **Windows**-Images. Es kann Updates hinzufügen, Treiber integrieren, Sprachpakete installieren und eben auch **Windows**-Features aktivieren oder deaktivieren. Um diese Aufgaben zu erfüllen, benötigt DISM eine Referenz – eine sogenannte Quelle.
Es gibt zwei Hauptarten, wie DISM seine Quellen beziehen kann:
1. **Online:** Wenn Sie DISM auf einem laufenden System ausführen (`/Online`), versucht es standardmäßig, benötigte Dateien von **Windows Update** herunterzuladen. Dies ist der einfachste Weg, erfordert jedoch eine Internetverbindung und funktionierende **Windows Update**-Dienste.
2. **Offline / Lokale Quelle:** Wenn Sie ein Image warten (`/Image:PfadZumImage`) oder eine manuelle Quelle angeben möchten (`/Source`), greift DISM auf einen lokalen Pfad zu. Dieser Pfad zeigt typischerweise auf den `sourcessxs`-Ordner einer **Windows Server**-Installations-ISO oder auf einen Netzwerkfreigabe, der diese Dateien enthält.

Das kritische Element hierbei ist die **Kompatibilität der Quelle**. Die Quelle muss nicht nur die benötigten Dateien enthalten, sondern auch zum Build und zur Version des Zielbetriebssystems passen. Ein **Windows Server 2019**-Image kann nicht zuverlässig mit einer **Windows Server 2016**-Quelle gewartet werden. Noch wichtiger: Wenn das Zielsystem bereits bestimmte Updates (insbesondere **Servicing Stack Updates**) installiert hat, muss die Quelle diese Updates (oder eine neuere Version) ebenfalls enthalten, damit die Feature-Definitionen synchron sind.

Erste Prüfungen und häufige Fallstricke
Bevor wir zu den tiefgehenden Lösungen kommen, lassen Sie uns einige offensichtliche, aber wichtige Prüfungen durchführen:

* **Tippfehler?** Es klingt banal, aber ist der Featurename wirklich `ADCertificateServicesRole`? Ja, in diesem speziellen Fall ist er es. Aber bei anderen Features kann ein kleiner Tippfehler zu derselben Fehlermeldung führen.
* **Bestätigen des Featurenamens mit PowerShell:** Verwenden Sie `Get-WindowsFeature`. Diese PowerShell-Cmdlet ist Ihr bester Freund, um herauszufinden, welche Features tatsächlich auf Ihrem System verfügbar sind und wie ihre genauen Namen lauten.
„`powershell
Get-WindowsFeature | Where-Object {$_.Name -like „*Certificate*”}
„`
Dadurch erhalten Sie eine Liste aller Features, die den Begriff „Certificate” enthalten, und können den korrekten Namen überprüfen. Sie sollten `AD-Certificate-Services` als Display Name und `ADCertificateServicesRole` als Internal Name sehen. Wenn es hier nicht gelistet wird, haben Sie ein grundlegenderes Problem mit der Feature-Erkennung.

Das Kernproblem: DISM’s Feature-Katalog und Updates
Das häufigste Szenario für den „Featurename unbekannt”-Fehler bei einem so bekannten Feature wie `ADCertificateServicesRole` ist ein Desynchronisation des internen Feature-Katalogs von **DISM** mit dem tatsächlichen Zustand des Betriebssystems oder der verwendeten Quelle. Dieser Katalog ist eine Art Inhaltsverzeichnis für alle verfügbaren **Windows**-Komponenten und Rollen.
**Servicing Stack Updates (SSU)** spielen hier eine entscheidende Rolle. SSUs sind spezielle Updates, die die „Wartungs-Engine” von **Windows** aktualisieren. Sie müssen oft vor anderen kumulativen Updates installiert werden und sind kritisch dafür, dass DISM und **Windows Update** korrekt funktionieren und die neuesten Feature-Definitionen erkennen können.
Wenn ein **SSU** auf dem Zielsystem installiert ist, aber die von DISM verwendete Quelle (z.B. ein alter `sourcessxs`-Ordner auf einer ISO) diese **SSU**-Informationen nicht enthält, kann es sein, dass DISM bestimmte Features, die nach dem **SSU**-Update „neu definiert” oder aktualisiert wurden, nicht mehr erkennt. Es ist, als würde man ein altes Telefonbuch verwenden, um eine neue Telefonnummer zu finden – sie ist einfach nicht drin.

Schritt-für-Schritt-Fehlerbehebung: Den Blindflug beenden

Nachdem wir die Grundlagen verstanden haben, gehen wir nun systematisch vor, um das Problem zu lösen.

**Lösung 1: Den Featurenamen mit Get-WindowsFeature überprüfen (Wiederholung und Bestätigung)**
Obwohl wir dies bereits erwähnt haben, ist es der absolute Startpunkt.
* Öffnen Sie PowerShell als Administrator.
* Geben Sie ein: `Get-WindowsFeature | Select-Object Name,DisplayName,InstallState`
* Suchen Sie nach `ADCertificateServicesRole`. Wenn es hier auftaucht, ist der Name korrekt und das Feature grundsätzlich bekannt. Die Ausgabe sollte in etwa so aussehen (InstallState kann variieren):
„`
Name DisplayName InstallState
—- ———– ————
ADCertificateServicesRole AD-Zertifikatdienste Available
„`
Wenn es nicht erscheint, ist Ihr System in einem sehr ungewöhnlichen Zustand, und Sie müssen möglicherweise ernsthaftere Reparaturmaßnahmen wie eine In-Place-Upgrade-Reparatur in Betracht ziehen. Dies ist aber sehr selten.

**Lösung 2: DISM im Online-Modus ohne manuelle Quellenprüfung**
Wenn Sie ein laufendes System (online) warten, versuchen Sie zunächst, DISM die Arbeit zu überlassen, ohne eine manuelle Quelle anzugeben. Dadurch wird **Windows Update** als Quelle genutzt.
* Öffnen Sie eine Eingabeaufforderung oder PowerShell als Administrator.
* Geben Sie ein:
„`cmd
DISM /Online /Enable-Feature /FeatureName:ADCertificateServicesRole /All /NoRestart
„`
oder in PowerShell:
„`powershell
Install-WindowsFeature -Name AD-Certificate-Services -IncludeManagementTools -Restart:$false
„`
(`AD-Certificate-Services` ist der DisplayName, der auch von `Install-WindowsFeature` akzeptiert wird.)
Wenn dies fehlschlägt, versuchen Sie es mit dem `ADCertificateServicesRole` Namen im DISM-Befehl (manchmal gibt es subtile Unterschiede im Verhalten):
„`cmd
DISM /Online /Enable-Feature /FeatureName:ADCertificateServicesRole /All /NoRestart
„`
Wenn die Fehlermeldung „Featurename unbekannt” weiterhin erscheint, bedeutet dies, dass **Windows Update** das Feature auch nicht richtig auflösen kann, oder dass Ihre lokalen Feature-Definitionen desynchronisiert sind.

**Lösung 3: DISM im Online-Modus mit einer lokalen, aktuellen Quelle**
Dies ist der häufigste und erfolgreichste Lösungsansatz. Sie benötigen eine aktuelle **Windows Server**-ISO-Datei, die zum **Build** und zur **Version** Ihres Zielsystems passt, idealerweise mit den neuesten **Servicing Stack Updates** integriert.

1. **ISO herunterladen und bereitstellen:**
* Laden Sie die neueste **Windows Server**-ISO für Ihre Version (z.B. **Server 2019**, **Server 2022**) von der Microsoft Volumenlizenz-Seite, dem MSDN-Portal oder dem Azure-Portal herunter. Stellen Sie sicher, dass es sich um die **gleiche Edition** (Standard, Datacenter) handelt.
* Mounten Sie die ISO-Datei. Nehmen wir an, sie wird als Laufwerk `D:` gemountet.

2. **Quellpfad identifizieren:**
* Die benötigten Feature-Dateien befinden sich im Ordner `D:sourcessxs`.

3. **DISM-Befehl mit Source:**
* Öffnen Sie eine Eingabeaufforderung oder PowerShell als Administrator.
* Führen Sie den Befehl aus und geben Sie den Quellpfad an:
„`cmd
DISM /Online /Enable-Feature /FeatureName:ADCertificateServicesRole /All /Source:D:sourcessxs /LimitAccess /NoRestart
„`
Der Parameter `/LimitAccess` verhindert, dass DISM versucht, **Windows Update** zu kontaktieren, und zwingt es, ausschließlich die angegebene lokale Quelle zu verwenden.
Wenn Sie PowerShell verwenden, können Sie den `-Source`-Parameter verwenden, aber es ist oft besser, bei DISM zu bleiben, wenn es um spezifische Quellpfade geht:
„`powershell
Install-WindowsFeature -Name AD-Certificate-Services -IncludeManagementTools -Source D:sourcessxs -Restart:$false
„`

**Lösung 4: DISM im Offline-Modus mit einer lokalen, aktuellen Quelle (für Image-Wartung)**
Wenn Sie ein Offline-Image warten (z.B. ein WIM-File für eine Bereitstellung), ist der Prozess ähnlich, aber Sie müssen das Image zunächst mounten.

1. **Image mounten:**
* Erstellen Sie ein leeres Verzeichnis, z.B. `C:mount`.
* Finden Sie den Index des Images, das Sie ändern möchten (z.B. `Install.wim` hat oft mehrere Editionen/Indizes).
„`cmd
DISM /Get-ImageInfo /ImageFile:C:PathToInstall.wim
„`
* Mounten Sie das Image:
„`cmd
DISM /Mount-Image /ImageFile:C:PathToInstall.wim /Index:1 /MountDir:C:mount
„`
2. **Quell-ISO bereitstellen:**
* Laden Sie eine **aktuelle** und passende **Windows Server**-ISO herunter und mounten Sie diese, z.B. als `D:`.

3. **DISM-Befehl für Offline-Image:**
* Geben Sie den Pfad zum gemounteten Image (`/Image:C:mount`) und die Quelle (`/Source:D:sourcessxs`) an:
„`cmd
DISM /Image:C:mount /Enable-Feature /FeatureName:ADCertificateServicesRole /All /Source:D:sourcessxs /LimitAccess
„`
4. **Image unmounten und Änderungen committen:**
* Nachdem die Rolle hinzugefügt wurde, müssen Sie das Image unmounten und die Änderungen speichern:
„`cmd
DISM /Unmount-Image /MountDir:C:mount /Commit
„`

**Lösung 5: Überprüfung und Installation von Servicing Stack Updates (SSU)**
Wie bereits erwähnt, sind **SSUs** extrem wichtig. Wenn die obigen Schritte fehlschlagen, insbesondere wenn Sie eine aktuelle ISO als Quelle verwenden, könnte ein veralteter **SSU** auf dem Zielsystem (oder im Offline-Image) die Ursache sein.

1. **Aktuellen SSU herunterladen:**
* Suchen Sie im Microsoft Update Catalog nach dem neuesten **Servicing Stack Update** für Ihre spezifische **Windows Server**-Version und Architektur. Suchen Sie zum Beispiel nach „Windows Server 2019 Servicing Stack Update”.
* Laden Sie die `.msu`-Datei herunter.

2. **SSU installieren (Online-System):**
* Führen Sie die `.msu`-Datei einfach aus oder installieren Sie sie über `wusa.exe`:
„`cmd
wusa.exe C:PathToyour_ssu.msu /quiet /norestart
„`
* Starten Sie das System neu, falls erforderlich (manchmal sind Neustarts für SSUs obligatorisch).

3. **SSU installieren (Offline-Image):**
* Dies ist komplexer. Sie können das **SSU** nicht einfach als `.msu` auf ein Offline-Image anwenden. Stattdessen müssen Sie es mit DISM integrieren:
* Mounten Sie Ihr Image (siehe Lösung 4, Schritt 1).
* Führen Sie den folgenden Befehl aus, um das **SSU** zu integrieren:
„`cmd
DISM /Image:C:mount /Add-Package /PackagePath:C:PathToyour_ssu.msu
„`
* Unmounten Sie das Image mit `/Commit`.
* Nachdem der **SSU** erfolgreich integriert wurde, versuchen Sie erneut, die `ADCertificateServicesRole` mit dem Offline-DISM-Befehl (Lösung 4) hinzuzufügen.

**Lösung 6: DISM-Integritätsprüfung (Wenn alles andere fehlschlägt)**
In seltenen Fällen kann die gesamte DISM-Komponentendatenbank beschädigt sein. Eine Überprüfung und Reparatur der Systemintegrität kann hier helfen.

1. **Systemintegrität prüfen (Online-System):**
* „`cmd
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
„`
* Wenn Probleme gefunden werden, versuchen Sie, sie zu reparieren:
„`cmd
DISM /Online /Cleanup-Image /RestoreHealth /Source:D:sourcessxs /LimitAccess
„`
Verwenden Sie hierbei unbedingt wieder eine **aktuelle, lokale Quelle**, da **Windows Update** möglicherweise die ursprüngliche Ursache des Problems ist.
* Führen Sie danach `sfc /scannow` aus, um beschädigte Systemdateien zu reparieren.

Fazit und beste Praktiken
Der Fehler „Featurename **ADCertificateServicesRole** ist unbekannt” bei **DISM** ist zwar frustrierend, aber mit einem systematischen Ansatz gut lösbar. Die Kernursache liegt fast immer in einem Desynchronisation zwischen den erwarteten Feature-Definitionen des Betriebssystems und der von **DISM** verwendeten Quelle oder einem veralteten **Servicing Stack Update**.

Um solche Probleme in Zukunft zu vermeiden, beherzigen Sie folgende **Best Practices**:
* **Aktuelle Quellen:** Halten Sie Ihre **Windows Server**-Installationsmedien (ISOs) auf dem neuesten Stand, indem Sie sie regelmäßig von Microsoft herunterladen. Noch besser: Erstellen Sie eigene, aktualisierte Referenz-Images (Golden Images) mit integrierten **Servicing Stack Updates** und den neuesten kumulativen Updates.
* **Verständnis der Umgebung:** Wissen Sie, ob Sie online oder offline arbeiten, und passen Sie Ihre DISM-Befehle entsprechend an.
* **Priorität für SSUs:** Stellen Sie sicher, dass **Servicing Stack Updates** immer zuerst installiert oder integriert werden, bevor Sie andere Updates oder Features hinzufügen.
* **Get-WindowsFeature nutzen:** Machen Sie sich die PowerShell-Cmdlets `Get-WindowsFeature` zu eigen, um Features zu identifizieren und ihren Status zu überprüfen.

Mit diesen Schritten und einem fundierten Verständnis der **DISM**-Mechanismen können Sie den „Blindflug” beenden und die **ADCertificateServicesRole** (oder jedes andere **Windows**-Feature) erfolgreich auf Ihrem System installieren. Geduld und systematisches Vorgehen sind hier der Schlüssel zum Erfolg.