Das Microsoft Deployment Toolkit (MDT) [1, 2] reiht sich in die lange Geschichte der Unattended-Installationswerkzeuge für Windows. IT-Verantwortliche, die MDT für sich entdeckt haben, nutzten zuvor meist ein Imaging-Werkzeug für die Installation von Systemen. Microsoft selbst bietet hier WDS an (Windows Deployment Service), bis Windows Server 2003 R2 als RIS (Re-
mote-Install-Server) bekannt. Mit Server 2008 kam dann die Möglichkeit, Treiber dem Image dynamisch anhand eines Hardwaremodels mitzugeben. Damit kann der monolithische Block auf unterschiedlicher Hardware ohne viel Nacharbeit angewendet werden.
Das Gute am Image-Ansatz ist die Vollständigkeit. Je genauer Sie ein Image hinsichtlich Hardware, Sprache, Software und Treiber zusammenstellen können, desto schneller ist das Deployment. Dabei haben die Logistik, wie zum Beispiel die Anzahl der zu betankenden Rechner, und der Stichtag, zu dem das Deployment abgeschlossen sein soll, einen entscheidenden Einfluss auf die Wahl der Technik. Die Genauigkeit geht dabei immer auf Kosten der Flexibilität. Ebenfalls lassen sich in einem Image Kleinigkeiten nicht so schnell anpassen: Computername, Sprachauswahl, 32- oder 64-Bit, Organisationseinheit des Domain Joins, Kennwort des Lokalen Administrators et cetera.
Microsoft bietet hier seit Jahren die Möglichkeit zur Verwendung einer Antwortdatei. Computernamen können im WDS automatisch über ein Schema zur Laufzeit vorgegeben werden, sodass eine Antwortdatei für mehrere Rechner zum Einsatz kommen kann. Die Antwortdatei erreicht ihre Grenzen, wenn das Microsoft-Namensschema nicht zum eigenen passt oder wenn es zu viele individuelle Einstellungen gibt. Dann endet der Prozess in einer Antwortdatei pro Computer. Ein weiteres Problem eines Images ist dessen statischer Aufbau. Software austauschen, Registry-Schlüssel hinzufügen,
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.