Plattformfundamente und Rollen
Einführung · 4 Abschnitte · ~10 Min Lesezeit · Stand
Die Betriebsfrage
Ein Windows Server ist kein leerer Rechner, auf dem man nach Bedarf Rollen anhäuft. Jede Rolle erweitert Angriffsfläche, Abhängigkeiten, Patch- und Recovery-Aufwand. Die erste Entscheidung lautet deshalb: Welche einzige Betriebsaufgabe muss dieses System erfüllen – und welche Komponente ist dafür die autoritative Instanz?
Drei Ebenen sauber trennen
| **Plattform** | Version, Installationsoption, Treiber- und Hersteller-Support. Das ist die Grundlage, nicht die Anwendung. |
|---|---|
| **Rolle** | Die Windows-Serverfunktion, etwa File Server oder Hyper-V. Rollen erhalten eine klare Zuständigkeit und dokumentierte Abhängigkeiten. |
| **Workload** | Anwendung, Daten und ihr Dienstvertrag. Ein erfolgreich gestarteter Prozess ist noch kein funktionierender Clientpfad. |
Der kontrollierte Bereitstellungsweg
- Anforderung, Datenklasse und Abhängigkeiten erfassen
- Kompatible Version, Edition und Installationsoption festlegen
- Rolle mit geringstmöglichem Scope bereitstellen
- Management, Backup, Monitoring und Clienttest vor Übergabe verifizieren
Kurzcheck
Welche Aussage beschreibt eine belastbare Rollenentscheidung?
- Sie beginnt mit der Betriebsaufgabe und prüft dann Kompatibilität, Vertrauensgrenze und Management.
- Sie installiert vorsorglich alle Rollen, die später nützlich werden könnten.
- Sie richtet sich ausschließlich danach, welche MMC-Konsole lokal verfügbar sein soll.
Richtig. Die Rolle folgt einer nachweisbaren Aufgabe und einem betreibbaren Design.
Was gleich geprüft wird
- Core oder Desktop Experience anhand echter Tool- und Herstellerabhängigkeiten wählen.
- Rollen nicht aus Bequemlichkeit auf einer Sicherheitsgrenze bündeln.
- Eine Bereitstellung erst nach Client-, Monitoring- und Rückfalltest als fertig behandeln.