Um die Betriebssystembereitstellung (OSD = Operating System Deployment) mit SCCM für neue Demogeräte zu testen, muss man die Treiber entsprechend einbinden.

Als erstes kopiert man die Treiber in eine entsprechende Freigabe.

Hinweis: Die Treiber für Surface Geräte werden nur noch als MSI angeboten. Man kann sie aber aus dem MSI extrahieren. Dazu verwendet man auf einer mit Adminrechten gestarteten Eingabeaufforderung:

msiexec /a heruntergeladene_Datei.msi targetdir=C:\Pfad /qn

Nun wählt man unter “Softwarebibliothek” –> “Treiber” –> “Treiber importieren”

Nun verweist man auf diesen gespeicherten Ordner.

Durch einen Klick auf “Kategorien” kann man eine Kategorie zuweisen, resp. neue Kategorien erstellen.

Auf der nächsten Seite kann man ein Paket auswählen oder durch einen Klick auf “Neues Paket…” ein neues erstellen.

Die Treiber werden nicht zum Startabbild hinzugefügt.

Nun muss man das Treiberpaket noch verteilen.

Jetzt muss man noch die Tasksequenz so anpassen, dass das Treiberpaket bei den richtigen Geräten angewendet wird.

Bei den Optionen kann man einstellen, dass die Treiber nur auf dieses Computermodell angewendet werden.

Die passende WMI Abfrage lautet:

SELECT * FROM Win32_ComputerSystem WHERE Model Like „%Modellname%“

Den Modellnamen erhält man durch eine WMI Abfrage. Dazu öffnet man eine Eingabeaufforderung und gibt “wmic” ein. Danach erhält man durch die Eingabe von “csproduct get name” den passenden Namen.

Die Treiber werden dann während dem OSD installiert.

Treiber fürs Startabbild
Es kann sein, dass ein Treiber für eine Netzwerk- oder Festplattenkomponente bereits schon im Startabbild benötigt wird, damit diese schon unter Windows PE angesprochen werden können.

Dazu wählt man bei den Eigenschaften des Startabbilds die Registerkarte “Treiber” und dann den “Stern”, um allfällig gewünschte Treiber einzubinden. Man sollte aber das Startabbild so klein wie möglich halten und nur wirklich benötigte Treiber einbinden.

Wir haben ein Demogerät zum Testen erhalten. Beim Neuaufsetzen mit unserem Windows 10 Image ist dies aber jeweils abgebrochen. Im SMSTS.log fand sich dann ein Hinweis auf eine falsch eingestellte Zeit auf dem Client:

failed to request for client
SyncTimeWithMP() failed. 80004005.
Failed to get time information from MP: “servername”

Sobald Datum und Zeit korrekt eingestellt wurden, konnte man den Client auch problemlos neu aufsetzen.

Das neue Startmenü von Windows 10 besteht im Gegensatz zu Windows 7 aus einem erweiterten Teil, bei dem Programme in Form von “Kacheln” (Tiles) angeheftet werden können. Die Standardauswahl sieht man auf diesem Bild.

Die Auswahl ist aber nicht ganz glücklich. “Office holen” ist eher irreführend. Auf unseren neu aufgesetzten Computern ist Office bereits installiert. Die Kalender und Mail App bieten deutlich weniger Funktionalität als das installierte Outlook, wurden aber bereits von einem Testbenutzer damit verwechselt. Besser wäre es, wenn man statt der Mail App direkt Outlook im Startmenü finden würde.

Es gibt verschiedene Möglichkeiten, dies zu erreichen. Eine Gruppenrichtlinie wäre zwar sehr einfach einzurichten, dann könnten aber die Benutzer keine Änderungen mehr daran vornehmen, was wir nicht wollen. Besser wäre es, eine Vorgabe zu haben, die beim ersten Anmelden am Netzwerk übernommen wird, die aber danach angepasst werden kann.

Leider fand ich diverse Anleitungen, die dann bei mir doch nicht funktioniert haben. Scheinbar gab es da Änderungen zwischen den Vorabversionen und der endgültigen Version von Windows 10. Einen funktionierenden Weg habe ich dann aber hier gefunden.

Dabei nimmt man mit einem lokalen Benutzer Änderungen am Startmenü vor und exportiert diese mit dem folgenden Powershell Befehl:

Export-Startlayout –path C:\Windows\Temp\Startmenu.xml

Nun kann man ein Powershellskript mit folgendem Inhalt erstellen:

Import-StartLayout -LayoutPath $PSScriptRoot\Startmenu.xml -MountPath $env:SystemDrive\

Diese beiden Dateien kopiert man in den Sources Ordner auf dem SCCM Server.

Nun erstellt man ein Paket ohne zugewiesenes Programm mit diesen zwei Dateien und lädt dieses auf einen Verteilungspunkt hoch. Am Schluss kann man noch die Tasksequenz entsprechend anpassen.

Somit haben nun alle neu aufgesetzten Computer dieses Startmenü als Vorgabe. Wenn sich ein Benutzer anmeldet, der sein Startmenü bereits angepasst hat, bleiben seine Änderungen bestehen, die Vorlage gilt nur für Erstanmeldungen an Windows 10.

Nachtrag:
Die Einstellungen des Startmenüs sind von den wandernden Profilen ausgenommen. Dies bedeutet, dass man das Startmenü für jeden Computer einzeln einrichten muss, wie wenn man keine wandernden Profile hätte. Zumindest deckt sich meine Erfahrung mit diesem Forumsbeitrag. Wenn man sich nun also an einem anderen Computer anmeldet, wandert das angepasste Startmenü nicht mit. Es werden nur die Kacheln angezeigt, die auch schon beim originalen Layout vorhanden waren. Also lassen wir das mit dem angepassten Startmenü Layout und hoffen, dass Microsoft die Möglichkeit für ein wanderndes Startmenü in Netzwerkumgebungen nachrüstet.

Neuaufsetzen von nicht bekannten Computern hat mit dem neuen SCCM problemlos funktioniert. Wenn aber einer dieser Computer bereits bekannt ist und erneut neu aufgesetzt werden sollte, brach die Tasksequenz mit folgender Meldung ab:

BOM not found on policy reply
…
Failed to download policy {irgendeine Nummer} (Code 0x80004005).

Gemäss diesem Technet-Blog hat das mit einem Windows Update zu tun, das nicht mehr ausgeliefert wird, aber in der Datenbank nicht vollständig gelöscht wurde.

Im Blog werden zwei Möglichkeiten beschrieben. Die erste ist, beim Neuaufsetzen keine Updates mehr ausliefern (ist ja nicht so wichtig, da die meisten beim build&capture Vorgang schon ins Grundimage aufgenommen werden. Da es aber später auch Updates von Updates geben wird, wollte ich darauf nicht verzichten. Ziel soll es sein, nach dem Neuaufsetzen ein möglichst aktuelles System mit allen Updates zu erhalten. Also musste ich den zweiten beschriebenen Weg gehen und mit dem Microsoft SQL Server Management Studio die entsprechenden Einträge aus der Datenbank löschen.

Bei mir gab es zwei Einträge, die ich beide sowohl von “PolicyAssignment” als auch von “DepPolicyAssignment” löschen musste. Danach funktioniert das Neuaufsetzen auch mit aktiviertem Software Update Schritt wieder problemlos.

Windows 10 bringt DotNet Version 4 bereits mit. Wenn man aber noch Software im Einsatz hat, die eine frühere Version benötigt, muss man DotNet 3.5 installieren.

Manuell könnte man dazu das entsprechende Windows-Feature aktivieren.

Beim Windows 10 Datenträger (resp. in der ISO Datei) gibt es einen Unterordner “sxs” in dem Ordner “sxs” (mit einer einzelnen CAB Datei). Wenn man diesen auf c:\sxs kopiert, kann man DotNet 3.5 mit folgendem Befehl aktivieren:

dism.exe /online /enable-feature /featurename:NetFx3 /all /limitaccess /source:c:\sxs

Besser ist natürlich, wenn man die Installation automatisiert. Ich habe mich entschlossen, das Programm bereits bei der sogenannten “build and capture” Tasksequenz einzubauen. Damit ist DotNet 3.5 bereits im Grundimage enthalten, das beim Neuaufsetzen installiert wird. Leider ist es mir nicht gelungen mit DISM an dieser Stelle auf eine Freigabe zuzugreifen. Aus diesem Grund habe ich mich auch für die Installation in zwei Schritten entschieden, wie sie z.B. hier schon für Windows 8.1 vorgeschlagen wurden.

In einem ersten Schritt erstellt man aus dem sxs Ordner ein Paket, das man auf den Client kopiert. Dieses muss wie alle Pakete auf einen Verteilpunkt (Distribution Point) verteilt werden. In der Tasksequenz kann man nun den Ordner aus dem Paket auf einen lokalen Ordner kopieren:

xcopy „.\*.*“ „c:\temp\sxs“ /D /E /C /I /Q /H /R /Y /S

Im zweiten Schritt kann man dann Dism ausführen und auf den kopierten Ordner temp\sxs verweisen.

dism.exe /online /enable-feature /featurename:NetFx3 /all /limitaccess /source:c:\temp\sxs

Nun wird beim “build and capture” wie gewünscht DotNet 3.5 installiert. Weil das bei diesem Vorgang entstandene Image als Grundimage für das Neuaufsetzen benutzt wird, hat nun jeder neu aufgesetzte Computer automatisch DotNet 3.5 installiert.

Nachtrag
Da wir keinen SCCM Server mehr haben, funktioniert das Vorgehen oben für unsere Umgebung nicht mehr. Man kann DotNet 3.5 aber auch mit Intune verteilen. Die Anleitung unter How to deploy .Net 3.5 with Intune – TimmyIT.com ist so gut, dass ich das hier nicht mehr weiter dokumentieren muss.