TorstenM

Genau das soll mit bzw *nach* dem Creators Update nicht mehr passieren. Die Zeit wird zeigen, ob es dann wirklich so sein wird.

Was passiert denn, wenn Du das Office-Paket zum Test nicht mit ConfigMgr installierst, sondern händisch? Wie genau sieht denn die Fehlermeldung aus? Was wurde im Paket angepasst?

CopyProfile funktioniert in Verbindung mit ConfigMgr nicht, da System-Kontext.

Funktioniert aber mit ConfigMgr nicht, da System-Kontext. Um was für Einstellungen geht es denn genau? "viele Cad-Programme und sehr viele Vorlgen und Einstellungen" ist wenig aussagekräftig.

Genau aus diesem Grund habe ich für mich entschieden die Zertifizierungen "aus Protest" (der dann sicher niemanden interessiert) nicht mehr zu aktualisieren.

Naja ... die Hyper-V-Truppe testet HyperV. Die Bitlocker-Truppe eben Bitlocker. Aber keiner beides zusammen. Ich war übrigens auch betroffen: Win10 Enterprise auf einem älteren Dell E6520. Upgrade auf Redstone war "ok" bis zum ersten händischen Reboot ...

x86-Treiber gehören in ein x86-Boot-Image, x64-Treiber in ein x64-Bootimage. Alle andere macht keinen Sinn. Wenn Du ein x64-OS verteilst, dann bitte auch das x64-Bootimage verwenden. Um das Trial-and-Error mit ConfigMgr's Bootimages abzukürzen: WinPE booten, F8 und mit drvload.exe einen vermeintlich passenden Treiber laden ... wenn der richtige so gefunden ist kannst Du ihn mit ConfigMgr in's Boot-Image integrieren.

- Nach dem Hinzufügen von Treibern zum Boot-Image musst Du natürlich das iso neu erzeugen, weil es sonst ja nichts von den Änderungen mitbekommen kann. - "Virtuelle Umgebung"? VMs können doch immer konfiguriert werden, um ein iso zu booten (als CD/DVD). - hampeln mit Sticks muss man auch nicht. Entweder z.B. Rufus verwenden oder einfach den Stick unter Windows formatieren und den Inhalt des iso auf den Stick kopieren. Fertig. - Ich würde auch noch den "command Support" (F8) für die Bootimages aktivieren (danach muss Stick bzsw iso wieder neu erstellt werden), damit kannst Du eine Eingabeaufforderung öffnen, sobald WinPE im grafischen Modus ist. Ist zum Troubleshooten viel einfacher. Und wie Du merkst: PXE-Boot ist deutlich einfacher, da musst Du nicht dauernd neue isos und Sticks erstellen, sondern nur die DPs aktualisieren.

Nein. Das funktioniert schon "sofort" (in Sinne von "sofort" im ConfigMgr-Kontext).

- DHCP-Optionen 66 und 67 werden nicht benötigt und sind offiziell gesehen sogar unsupportet. Besser: IPhelper einsetzen, wenn Clients und WDS in unterschiedlichen Subnetzen. Spätestens bei UEFI-Systemen wird's unmöglich, DHCP-Optionen zu verwenden (wenn x86 und x64 verteilt werden soll - wobei "unmöglich" auch durch "extrem komplex" ersetzt werden kann) - "boot\x86" muss nicht als Windows Share/Freigabe existieren. Hier geht's um tftp. - "PXE aufgegeben weil zu Gefummel": eigentlich ist das nicht wirklich kompliziert und funktioniert auch in sehr großen Umgebungen - PXE hat einen großen Vorteil im Vergleich zu USB/iso: es gibt das smspxe.log, welches sehr hilfreich für das Troubleshooting ist. Bei USB/iso schaut man da eher komplett in die Röhre. Siehe dazu auch http://www.mssccmfaq.de/2012/02/04/cm12-pxe-boot-szenarien/, sprich Du siehst im smspxe.log, welche ResourceID verwendet wird, um zu ermitteln, ob es ein Deployment einer Tasksequenz für die anfragende MAC bzw Smbios-Guid gibt.

Wie denn genau? Application? Package? Wie sieht die Command Line aus?

Geht auf jeden Fall!

Executing command line: "C:\Windows\system32\sysprep\sysprep.exe" /quiet /generalize /oobe /quit PrepareOS 01.03.2016 18:42:48 1700 (0x06A4) Process completed with exit code 0 PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) Sysprep state set to IMAGE_STATE_COMPLETE PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) The OS has not been generalized using sysprep.exe, or sysprep did not complete. PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) bSysPreped, HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\prepareos\prepareos.cpp,514) PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) Sysprep did not complete successfully PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) RunSysprep(sCmdLine, bActivate, m_bDebug), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\prepareos\prepareos.cpp,1375) PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) Unable to sysprep the machine, hr=80004005 PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) pCmd->Sysprep(bActivate, bMsd), HRESULT=80004005 (e:\nts_sccm_release\sms\client\osdeployment\prepareos\main.cpp,270) PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) Sysprep'ing the machine failed, hr=80004005 PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) De-Initialization successful PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) Exiting with error code 16389 PrepareOS 01.03.2016 18:42:52 1700 (0x06A4) Process completed with exit code 16389 TSManager 01.03.2016 18:42:52 4992 (0x1380) --> Schau Dir mal die sysprep Logs an.

smsts.log und scanstate.log.

Das sind dann 16 Tasksequenzen? Ich würde auf jeden Fall empfehlen, MDT näher anzuschauen. Damit müsste man alles mit eine Tasksequenz erledigen können. Mit einem Prestart-Command höchstwahrscheinlich auch die Sprache des Bootimages.