Plattformfundamente: Edition, Installationsoption und Rollen

Beim Setup eines Windows Servers fallen vier Entscheidungen, und drei davon lassen sich später nur mit einer Neuinstallation korrigieren. Dieses Modul ist der Einstieg in den Track: Es zeigt, welche Türen beim Installieren zufallen, warum ein erfolgreich installierter IIS trotzdem ohne Konsole dasteht, warum eine Rolleninstallation aus einer verschlankten Vorlage nach Quelldateien verlangt und weshalb ein geklonter Server mit falscher Uhr eine Anmeldung ablehnt, die nach falschem Kennwort aussieht. Vorkenntnisse brauchst du keine — Begriffe wie Rolle, Feature und Server Core werden unterwegs erklärt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Ein Server ist kein größerer Windows-PC

Wer Windows als Anwender kennt, bringt ein falsches Modell mit: Man installiert Programme, und was man nicht installiert, ist eben nicht da. Ein Windows Server funktioniert anders. Die Funktionen, die ihn zum Server machen — Dateifreigabe, Webserver, DNS, Virtualisierung — sind bereits Bestandteil des Betriebssystems. Sie liegen in einem lokalen Ablagespeicher auf der Platte und werden nicht heruntergeladen, sondern aktiviert. Ein frisch installierter Windows Server ist deshalb kein leeres Gerät, sondern eines, an dem noch nichts eingeschaltet ist.

Rolle — Der Hauptzweck, den ein Server für andere Rechner erfüllt — etwa Web-Server für IIS, AD-Domain-Services für einen Domänencontroller, DHCP für die Adressvergabe. Eine Rolle bringt Dienste mit, die auf Anfragen aus dem Netz antworten.

Feature — Eine Fähigkeit, die eine Rolle unterstützt oder die der Server für sich selbst braucht — etwa Failover-Clustering, NET-Framework-45-Core oder die Verwaltungswerkzeuge einer Rolle. Ein Feature antwortet in der Regel niemandem, es befähigt.

Diese Trennung ist keine Wortklauberei. Sie erklärt, warum du eine Rolle installieren kannst und die zugehörige Verwaltungskonsole trotzdem fehlt — dazu gleich mehr, es ist der häufigste Stolperstein des ganzen Moduls.

Vier Entscheidungen fallen vor der Installation

Bevor der erste Dienst läuft, sind vier Dinge festgelegt. Drei davon lassen sich später nur mit Aufwand oder gar nicht mehr ändern. Wer sie kennt, trifft sie bewusst; wer sie nicht kennt, trifft sie trotzdem — dann eben durch Anklicken im Installationsassistenten.

Edition: Standard oder Datacenter. Nachträglich per Befehl änderbar, aber nur in eine Richtung.
Installationsoption: Server Core oder Server with Desktop Experience. Nachträglich gar nicht änderbar.
Release-Kanal: Long-Term Servicing Channel oder Annual Channel. Bestimmt, wie lange der Server Updates bekommt.
Lizenz- und Aktivierungsart: Evaluierung, Retail, Volumenlizenz oder OEM. Bestimmt, in welche Editionen du später wechseln darfst.

Die vier hängen zusammen. Eine Evaluierungsinstallation mit Desktop Experience lässt sich später nicht in ein Server Core mit Volumenlizenz verwandeln — weder die eine noch die andere Achse. Der Aufwand, das zu reparieren, ist immer eine Neuinstallation.

Edition: was nachweisbar unterschiedlich ist

Standard und Datacenter installieren dasselbe Betriebssystem. Der Unterschied liegt in freigeschalteten Funktionen und in Lizenzrechten — und diese zwei Dinge stehen an verschiedenen Orten dokumentiert, was regelmäßig zu Verwirrung führt.

Storage Spaces Direct: Nur Datacenter. In der Editionsvergleichstabelle als nicht verfügbar für Standard geführt.
Storage Spaces (ohne Direct): Beide Editionen.
Hyper-V-Rolle installierbar: Beide Editionen. Die Rolle selbst ist keine Editionsfrage.
Anzahl lizenzierter Windows-Server-VMs: Nicht in der technischen Doku — steht in den Produktbedingungen.
Automatic Virtual Machine Activation: Als Host nur Datacenter.

Grenze der QuelleDie Editionsvergleichstabelle bei Microsoft beschreibt Funktionen, nicht Nutzungsrechte. Wie viele virtualisierte Windows-Server-Instanzen eine Lizenz abdeckt, ist eine Lizenzfrage und steht in den Produktbedingungen des Lizenzvertrags. Wer diese Zahl aus einer technischen Dokumentation zitiert, zitiert die falsche Quelle. Bei Kapazitätsplanungen für Virtualisierungshosts ist das der Punkt, an dem du jemanden aus der Lizenzierung dazuholst, statt zu schätzen.

Installationsoption: Server Core oder Desktop Experience

Server Core installiert kein grafisches Shell-Paket. Kein Startmenü, kein Explorer, kein Desktop — nach der Anmeldung erscheint eine Kommandozeile. Microsoft empfiehlt in der Dokumentation ausdrücklich Server Core, sofern kein konkreter Bedarf an den grafischen Werkzeugen besteht.

Server Core und Desktop Experience unterscheiden sich in den installierten Shell-Paketen, nicht in den verfügbaren Rollen.

Oberfläche: Core: PowerShell, cmd, SConfig. Desktop Experience: die gewohnte Windows-Oberfläche.
Plattenbedarf: Ein Server Core belegt rund 4 GB weniger als derselbe Server mit Desktop Experience.
Rollen lokal installieren: Core: nur PowerShell. Desktop Experience: Server Manager oder PowerShell.
Microsoft Management Console (mmc.exe): Core: nicht installiert. Desktop Experience: installiert.
Angriffsfläche: Core: deutlich reduziert. Desktop Experience: keine Reduktion.

Die Mindestanforderungen gelten laut Dokumentation für beide Optionen gleich: ein 64-Bit-Prozessor ab 1,4 GHz und 32 GB Plattenplatz für die Systempartition. Diese 32 GB sind als absolutes Minimum bezeichnet — sie reichen für einen Server Core mit der IIS-Rolle und sonst nichts. Wer mehr als 16 GB Arbeitsspeicher einbaut, braucht zusätzlich Platz für Auslagerung, Ruhezustand und Absturzabbilder. Das ist der Grund, warum eine Vorlage mit knapp bemessener Systemplatte Monate später als Speicherplatzproblem auffällt, nicht als Planungsfehler.

IIS — Die Internet Information Services: der in Windows Server eingebaute Webserver. Er beantwortet HTTP- und HTTPS-Anfragen aus dem Netz und ist der häufigste Grund, überhaupt einen Server aufzubauen. In der Rollenliste heißt er Web-Server.

Eine Tür, die zufälltDie Dokumentation ist an dieser Stelle unmissverständlich: Anders als in manchen früheren Releases lässt sich nach der Installation nicht mehr zwischen Server Core und Desktop Experience wechseln. Wer die Option ändern will, installiert neu. Auch ein In-Place-Upgrade auf eine neuere Version kann die Option nicht wechseln — das ist ausdrücklich nicht unterstützt. In Windows Server 2012 R2 ging das noch über das Entfernen eines Features; wer diese Erinnerung mitbringt, irrt sich seit Windows Server 2016.

Die Lücke im Core schließen — und was sie kostet

Zwischen „gar keine grafischen Werkzeuge“ und „volle Desktopoberfläche“ gibt es eine dritte Stellung: das App Compatibility Feature on Demand. Es bringt einen Teil der Binärdateien aus der Desktop Experience nach Server Core, darunter mmc.exe, explorer.exe und powershell_ise.exe.

Installiert wird es mit einem Befehl, entweder aus Windows Update oder von der separaten ISO mit Sprachen und optionalen Features:

Add-WindowsCapability -Online -Name "ServerCore.AppCompatibility~~~~0.0.1.0"
Danach ist ein Neustart nötig; die Ausgabe meldet RestartNeeded : True.
Von ISO zusätzlich mit -Source <Pfad> und -LimitAccess, damit nicht doch Windows Update gefragt wird.

Zwei Einschränkungen stehen ausdrücklich in der Dokumentation. Erstens lässt sich das Paket nur auf Server-Core-Installationen hinzufügen — auf einem Server mit Desktop Experience ist der Versuch schlicht falsch. Zweitens hängt die IIS-Verwaltungskonsole daran, weil sie mmc.exe braucht; ohne das Paket bekommst du IIS installiert, aber nicht seine Konsole.

Der Fallstrick beim UpgradeEin In-Place-Upgrade auf eine neuere Windows-Server-Version behält das App Compatibility Feature on Demand nicht. Es muss danach neu installiert werden. Wer das Paket in ein eigenes Abbild aufnimmt, statt es auf jedem Server einzeln nachzuziehen, hat das Problem nicht — dieselbe Überlegung gilt für jede Anpassung, die ein Upgrade überleben soll.

Der Kanal verrät sich nicht über den Produktnamen

Seit September 2023 gibt es zwei Release-Kanäle. Sie unterscheiden sich in der Frequenz neuer Versionen und, viel wichtiger für den Betrieb, in der Länge des Supports.

Long-Term Servicing Channel (LTSC): Neue Hauptversion typischerweise alle zwei bis drei Jahre. Fünf Jahre Mainstream-Support plus fünf Jahre erweiterter Support.
Annual Channel (AC): Neue Version typischerweise jährlich. 18 Monate Mainstream plus sechs Monate erweiterter Support, also 24 Monate gesamt.
Installationsoptionen: LTSC: Server Core und Desktop Experience. AC: auf Container und Microservices ausgerichtet.

Der überraschende TeilDer Produktname sagt den Kanal nicht. Zwei Server können beide „Windows Server Datacenter“ heißen und trotzdem in Supportfenstern von zehn und von zwei Jahren stehen. Die Dokumentation nennt dafür den Weg über die Betriebssystemversion: Get-ComputerInfo liefert unter anderem OSDisplayVersion. Eine Inventarliste, die nur Produktnamen führt, kann die Frage „wann läuft dieser Server aus dem Support“ nicht beantworten.

Evaluierung ist kein beliebig verlassbarer Zustand

Evaluierungsversionen sind zum Ausprobieren gedacht und laufen ab. Sie lassen sich in Retail-Versionen umwandeln — aber nicht in jede beliebige. Welche Ziele überhaupt in Frage kommen, verrät der Server selbst:

DISM /online /Get-CurrentEdition — welche Edition läuft hier? Enthält der Name Eval, ist es eine Evaluierung.↓DISM /online /Get-TargetEditions — in welche Editionen darf dieser Server konvertiert werden?↓DISM /online /Set-Edition:<Ziel> /ProductKey:<Schlüssel> /AcceptEula — die Konvertierung selbst.

Steht das gewünschte Ziel nicht in der Liste aus Schritt 2, hilft nur eine Neuinstallation.

Eine Datacenter-Evaluierung lässt sich nur nach Datacenter Retail konvertieren, nicht nach Standard.
Seit Windows Server 2016 lässt sich eine Desktop-Experience-Evaluierung nicht in eine Server-Core-Retail-Version konvertieren.
Ein Domänencontroller lässt sich überhaupt nicht von Evaluierung auf Retail konvertieren.

Die Evaluierung, die zum Domänencontroller wurde

Szenario

Für einen Test wurde ein Server aus der Evaluierungs-ISO installiert und zum Domänencontroller einer neuen Testdomäne heraufgestuft. Der Test lief gut, die Domäne wurde produktiv genutzt. Nach 180 Tagen meldet der Server den Ablauf der Evaluierung.

Anforderungen

Die Domäne muss verfügbar bleiben.
Der Server soll dauerhaft lizenziert werden.

Schritte

DISM /online /Get-TargetEditions ausführen — die Konvertierung eines Domänencontrollers ist laut Dokumentation nicht möglich, der direkte Weg fällt aus.
Einen zweiten Server aus der Retail- oder Volumenlizenz-Quelle installieren und ebenfalls zum Domänencontroller heraufstufen.
Die FSMO-Rollen — die Sonderzuständigkeiten (etwa Schema-Änderungen oder die Namensgebung für neue Objekte), die genau ein Domänencontroller übernimmt — vom Evaluierungsserver auf den neuen Domänencontroller übertragen.
Active Directory Domain Services auf dem Evaluierungsserver entfernen, ihn also herabstufen.
Den Evaluierungsserver ausmustern oder neu installieren.

Merksatz: Der Aufwand entstand nicht mit dem Ablauf der Evaluierung, sondern mit der Entscheidung, ein Testabbild produktiv zu machen: Die Installationsquelle gehört in die Übergabe — nicht in die Fehlersuche.

Rollen und Features installieren

Auf Server Core gibt es keinen Assistenten, also führt der Weg über PowerShell. Auf Desktop Experience ginge zwar auch der Assistent, aber der PowerShell-Weg bleibt der bessere: Befehle lassen sich aufschreiben und wiederholen — GUI-Klicks nicht. Get-WindowsFeature zeigt, was vorhanden und was installiert ist; Install-WindowsFeature schaltet ein.

Install-WindowsFeature -Name Web-Server -WhatIf — zeigt das Ergebnis, ohne etwas zu tun.
-IncludeAllSubFeature nimmt die untergeordneten Rollendienste mit.
-IncludeManagementTools nimmt die Verwaltungswerkzeuge mit.
-Restart startet den Server neu, falls die Installation es verlangt.

Get-WindowsFeature gibt für jede Rolle und jedes Feature einen Installationszustand aus. Interessant ist der dritte Zustand neben installiert und nicht installiert: entfernt. Uninstall-WindowsFeature mit dem Schalter -Remove deinstalliert ein Feature nicht nur, sondern löscht dessen Dateien aus dem lokalen Side-by-Side-Speicher unter C:\Windows\WinSxS. Danach ist der Rollenname weiterhin sichtbar, aber die Installation braucht eine Quelle. Genau so entstehen die verschlankten Abbilder, um die es im nächsten Abschnitt geht — und genau deshalb scheitert dieselbe Installation, die auf dem Testserver funktionierte, auf dem Produktionsserver aus der Vorlage.

Assistent und Befehl sind nicht gleichwertigDie Dokumentation formuliert es als ausdrückliche Ausnahme: Über den Assistenten „Rollen und Features hinzufügen“ werden die Verwaltungswerkzeuge standardmäßig mitinstalliert, über Install-WindowsFeature nicht. Derselbe Rollenname führt also je nach Weg zu einem anderen Ergebnis. Genau hier entsteht der Klassiker: IIS läuft, aber der IIS-Manager ist nirgends zu finden — und niemand denkt an das fehlende -IncludeManagementTools, weil die Rolle ja erfolgreich installiert wurde.

Kurzcheck

Auf einem Server mit Desktop Experience wurde Install-WindowsFeature -Name Web-Server ausgeführt. Der Befehl meldet Erfolg, die Website antwortet, aber der IIS-Manager fehlt im Startmenü. Was ist passiert?

Die Verwaltungswerkzeuge wurden nicht mitinstalliert, weil -IncludeManagementTools fehlte
Die Installation ist nur halb durchgelaufen und muss mit -Restart wiederholt werden
Der IIS-Manager braucht das App Compatibility Feature on Demand, das hier fehlt

Treffer. Richtig. Der Cmdlet-Weg installiert die Werkzeuge nicht von selbst. Install-WindowsFeature -Name Web-Mgmt-Console holt sie nach.

Wenn die Feature-Dateien fehlen

Manche Abbilder werden verschlankt ausgeliefert: Die Feature-Dateien wurden aus dem lokalen Ablagespeicher entfernt, um Platz zu sparen. Die Installation einer Rolle schlägt dann fehl, obwohl der Rollenname existiert. Dafür gibt es -Source. Die Dokumentation nennt die Suchreihenfolge:

Der lokale Side-by-Side-Speicher des Zielservers.↓Der Pfad aus -Source.↓Der per Gruppenrichtlinie gesetzte Reparaturpfad — in der Registry HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Servicing\LocalSourcePath.↓Windows Update.

-Source wird erst befragt, wenn der lokale Speicher nichts liefert — ein gesetzter Pfad beweist also nicht, dass er benutzt wurde.

Wer liest hier eigentlich?Wird die Rolle mit -ComputerName auf einem entfernten Server installiert und -Source zeigt auf eine UNC-Freigabe, muss laut Dokumentation das Computerkonto des Zielservers Leserechte auf der Freigabe haben — in der Form DOMAIN\SERVERNAME$. Nicht dein Benutzerkonto, obwohl du den Befehl abgeschickt hast. Ein lokaler Pfad des Rechners, an dem du sitzt, führt ebenfalls zum Fehlschlag: Der Zielserver muss ihn erreichen können, nicht du.

Rollen trennen oder bündeln

Technisch spricht wenig dagegen, mehrere Rollen auf einen Server zu legen — Windows lässt es zu. Betrieblich koppelt jede zusätzliche Rolle drei Dinge zusammen, die man sonst getrennt steuern könnte.

Neustartkopplung: Ein Neustart für die eine Rolle nimmt jede andere auf demselben Host mit.
Ausfallradius: Ein Speicherleck in einem Anwendungspool trifft die Dienste, die sich den Host teilen.
Rechteradius: Wer den Server administriert, administriert alles darauf. Bei einem Domänencontroller ist das die gesamte Domäne.

Besonders deutlich ist der dritte Punkt beim Domänencontroller: Wer lokale Administratorrechte auf einem Domänencontroller hat, hat faktisch Kontrolle über die Domäne. Eine Webanwendung auf demselben Host bedeutet, dass jede Schwachstelle in dieser Anwendung an derselben Grenze landet.

Der Preis der TrennungTrennung ist nicht kostenlos, und wer das verschweigt, verkauft eine Regel statt einer Entscheidung. Mehr Server heißt: mehr Betriebssysteme im Patchzyklus, mehr Abbilder, mehr Überwachungsobjekte, mehr Lizenzen und mehr Wege, auf denen eine Konfiguration auseinanderlaufen kann. Die belastbare Frage lautet nicht „getrennt oder nicht“, sondern: Welche Rollen dürfen sich einen Neustart und einen Administrator teilen?

Der Verwaltungsweg gehört zur Plattformentscheidung

Wer Server Core wählt, entscheidet damit auch, wie dieser Server künftig verwaltet wird. Das ist keine Nebenfolge, sondern der eigentliche Inhalt der Entscheidung — und es lohnt sich, den Verwaltungsweg zu prüfen, bevor der erste produktive Dienst darauf liegt.

SConfig: Textmenü direkt auf dem Server: Netzwerk, Domänenmitgliedschaft, Remoteverwaltung. Seit Windows Server 2022 startet es auf Core automatisch nach der Anmeldung.
PowerShell-Remoting: Der Arbeitsweg für alles Wiederholbare. Skalierbar, protokollierbar, skriptfähig.
Windows Admin Center: Browserbasierte Oberfläche, läuft auf einem anderen Rechner und verbindet sich zum Server.
RSAT: Die Verwaltungskonsolen auf einem Arbeitsplatzrechner. Laut Dokumentation muss die Version aus Windows 10 oder neuer stammen.
Server Manager: Verwaltet auch entfernte Server, braucht dafür aber eine Desktop Experience oder einen Arbeitsplatzrechner als Startpunkt.

Eine Einschränkung mit FolgenSConfig lässt sich nicht in einer PowerShell-Remotesitzung benutzen. Es ist damit genau das Werkzeug für den Fall, in dem die Remoteverwaltung noch nicht oder nicht mehr funktioniert — und nutzlos, sobald sie funktioniert. Wer einen Server-Core-Host ohne funktionierenden Konsolenzugang über die Virtualisierung oder Fernwartungskarte betreibt, hat für den Ausfall der Remoteverwaltung keinen Weg zurück.

Vom Abbild zum eigenständigen Server

Die meisten Server entstehen nicht aus der ISO, sondern aus einer Vorlage. Damit aus einer Kopie ein eigenständiger Server wird, muss die maschinenspezifische Information entfernt werden. Die Dokumentation ist hier eindeutig: Wird ein Windows-Abbild auf einen anderen Rechner übertragen, muss Sysprep mit der Option /generalize gelaufen sein — auch dann, wenn die Hardware identisch ist.

Danach folgen die Voraussetzungen für den Domänenbeitritt, und zwar in dieser Reihenfolge:

Abbild mit Sysprep /generalize versiegeln, bevor es geklont wird.↓Computernamen und Adressierung setzen — ein Name, der aus der Vorlage stammt, kollidiert mit dem Original.↓DNS auf einen Server zeigen lassen, der die Domäne auflösen kann. Ein öffentlicher Resolver findet die Domänencontroller nicht.↓Zeit gegen die Domänenzeitquelle abgleichen.↓Erst jetzt der Domänenbeitritt.

Wer die Reihenfolge dreht, bekommt Fehlermeldungen, die nach Berechtigungsproblemen aussehen, aber keine sind.

Damit schließt sich der Bogen zum Anfang. Die vier Entscheidungen aus dem zweiten Abschnitt — Edition, Installationsoption, Kanal, Lizenzart — sind an dieser Stelle längst gefallen und stecken jetzt in einem Server, der einer Domäne beitritt. Wer sie nicht dokumentiert, muss sie später aus dem laufenden System zurücklesen: DISM /online /Get-CurrentEdition für die Edition, Get-ComputerInfo für Version und Kanal, das Fehlen von mmc.exe für die Installationsoption. Das geht, ist aber Archäologie statt Übergabe.

Warum die Zeit vor dem Beitritt kommtKerberos benutzt Zeitstempel, um Wiedereinspielungsangriffe zu verhindern: Ein abgefangenes Ticket soll später nicht noch einmal verwendbar sein. Damit das funktioniert, dürfen die Uhren von Client und Domänencontroller nur begrenzt auseinanderliegen. Die Richtlinieneinstellung „Maximale Toleranz für die Synchronisation des Computertakts“ steht standardmäßig auf fünf Minuten. Eine virtuelle Maschine, die aus einem alten Abbild startet, liegt schnell darüber — und die Anmeldung scheitert dann mit einer Meldung, die nach falschem Kennwort klingt.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität14 Primärquellen · zuletzt geprüft: 2026-09-04