TorstenM

 

einige der Einstellungen die ich mittels Powershell beim Deployment gemacht habe sind nun wieder weg. Z.b. Standardprogramme, Taskbar, Mail-App etc.

 

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.

Du musst das aktuelle Profile zum Default Profile machen, schau mal hier:

 

https://msdn.microsoft.com/de-de/windows/hardware/commercialize/manufacture/desktop/customize-the-default-user-profile-by-using-copyprofile

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.

 

Mich hat nur stutzig gemacht, dass ich dann mit MCSE jedes Jahr ein elective machen bzw. wählen "darf".

[...]

Ich persönlich habe das Gefühl, dass mit den neuen MCSE die Gelddruckmaschine mal richtig läuft...

 

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

Und wieso werden solche Kernkomponenten wie Client Hyper-V und Bitlocker usw. eigentlich offenbar nur generisch getestet? Kommt mir langsam so vor, als wäre ne Menge vom Testszenario inzwischen irgendwie automatisiert in VMs durchgeführt und das hat mit der Realität leider wenig zu tun. 

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.

Ansonsten kann dies einige Stunden bis hin zu angeblich einen Tag dauern weil er es dann nach Auslastung oder einem nicht vorhersehbaren Algorithmus tut.....

 

 

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.

ich versuche ohne Erfolg die Vodafone Mobile Broadband 11 Software (http://www.vodafone.de/business/hilfe-support/dashboard-software-fuer-windows-und-mac.html) via Microsoft SCCM 2012R2 zu deployen.

 

 

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.

 

Zur Zeit sehen alle einfach alle Task sequenzen.

 

Wenn man dann aber 50 solcher Sequenzen hat, wirds langsam unübersichtlich. Und die Leute in den Phillippinen wollen ja kein Deutsches Notebook oder Workstation. :)

 

 

Da stellt sich eher die Frage, wieso überhaupt so viele Tasksequenzen im Einsatz sind. Ich würde maximal eine pro Betriebssystem verwenden (und zB Sprachsettings mit MDT dynamisch regeln). Aber 50? 

Ansonsten ist es einfach eine Frage, auf welche Collection die TS angekündigt ist.

Die Einstellung kannst Du im Deployment der Software Update Group vornehmen (User Experience).

Der Speicherbedarf der Primary Site ist an sich auch nicht so hoch und sollte vermutlich nicht der Flaschenhals sein. 
Wie viele Datenbanken sind denn noch auf dem Cluster? 32GB ist jetzt nicht so viel. Und wie sieht's mit dem Disk Subsystem aus? Meistens sorgt dies für Performanceprobleme. Hier sollte man mit Perfmon o.ä. weitere Untersuchungen anstellen. 

 

P.s Und nicht vergessen !, Das ist ein Workaround. Offiziell wird Windows 10 erst im ConfigMGr vnext supported. Über künftiger Produktename (ConfigMgr 2014) und Releasedatum möchte ich hier keine Spekulationen lostreten !!

 

Nein. Der Win10-Support kommt schon mit CM12*SP2* bzw. CM12*R2SP1*, welches schon seit letzter Woche verfügbar ist. 

Prinzipiell mit PIVOT: http://www.mssqltips.com/sqlservertip/1019/crosstab-queries-using-pivot-in-sql-server/ 

Und wie viele Bücher hast Du in deutsch gefunden?

Hast Du schon einmal bei Amazon geschaut, welches Bücher es dazu in deutsch gibt? Die Auswahl ist da nicht so sehr groß ...

Siehe meine Antwort im Technet Forum. 

Es existiert ein Aussenstandort mit ca. 50 Clients der über eine sehr instabile und auch nicht gerade schnelle WAN - Verbindung mit dem Hauptstandort verbunden ist.

 

Das könnte zu Problemen mit der DRS-Replikation führen. 

Zu Sunny62's Statement: ConfigMgr erfindet hier auch nichts neu und verwendet nur bestehende Mechanismen, folglich lässt es sich von BITS beeindrucken ;-)

dass auch der Agent vom Windows Intune auf dem IOS Gerät von Apple stammt dito bei Android. Deswegen sind auch nicht die genau identischen Funktionen verwaltbar wie zum Beispiel mit einemk Windows Phone 9.  

Das stimmt bedingt. In keinem dieser Fälle ist ein "Agent" im Einsatz. Die Endgeräte werden per OMA DM Schnittstelle (http://en.wikipedia.org/wiki/OMA_Device_Management) verwaltet.