TorstenM

Probiere doch zuerst mal eine Gen1-VM, dann musst Du dich nicht mit UEFI und SecureBoot rumschlagen ... Woher weisst Du denn, dass "Option 66 und 67 sind richtig konfiguriert" sind? Wie sind die Werte denn gesetzt?

Geht nicht. Alternative: in der neuen Domäne eine weitere CM12 Site aufbauen und alles migrieren. Oder den Server in der alten Domäne lassen und domänen-/forest-übergreifend Clients managen.

Prinzipiell ist alles außer 0 ein Fehler (abgesehen von sowas wie 3010 = Erfolg, aber Reboot erforderlich). Wegen Anwendungen, die in Benutzung sind: https://psappdeploytoolkit.codeplex.com/

Irgendwie finde ich den Ansatz mit div. Textfiles und alle 15min irgendwie steinzeitlich ;-) Was genau steckt denn hinter dem "Inventarsystem" genau? Und was ist Ziel der ganzen Übung? Beschreibe doch erst einmal die eigentliche Problemstellung (nein, das oben ist keine, sondern eher eine Lösungsmöglichkeit) dann kann man das evtl eleganter lösen.

System Management Container hat überhaupt nichts mit dem Download der Prerequisites zu tun. Völlig unabhängig. Die Prerequisites kannst Du von jedem x-beliebigen PC herunterladen (setupdl.exe). "Primary Site Server Account": damit ist der Computer-Account der Primary Site gemeint. Dieser muss auf den System Management Container berechtigt werden (Vollzugriff auf alles inkl. Unterordner)

Meiner Meinung gibt es sowas auch gar nicht. Die Anforderungen sind jwls viel zu unterschiedlich.

Der Windows Update Client Agent sieht diesen ausstehenden Reboot und führt den dann durch. Abhilfe: GPO: Configure Automatic Updates -> Disabled.

Genau diese Einstellung sollte aber den Reboot unterdrücken. Kann es sein, dass "nach 8h" bedeutet, dass der Reboot gegen 2 oder 3 Uhr nachts passiert? Wenn ja dann wird er vom Windows Update Client Agent durchgeführt, aber nicht von ConfigMgr.

Probier mal "netsh winhttp show proxy" auf einem solchen Client.

Naja, Ansichtssache. Umständlich ist anders. Zur Not lässt sich über ADR (automatic deployment rules) einiges automatisieren. Die Frage ist nur, ob man das bei der aktuellen "Patchqualität" auch wirklich will.

Schau mal im ScanAgent.log, WUAHandler.log und WindowsUpdate.log was dort *genau* für den SUP/WSUS eingetragen ist (im speziellen, was die Groß- und Kleinschreibung des Servernamens inkl FQDN anbelangt). Ich hatte schon Fälle, in denen genau das zu seltsamen Phänomenen geführt hat.

ConfigMgr kennt CAU schlicht nicht. Du müsstest skripten oder Orchestrator o.ä. verwenden.

Was zeigt denn die Monitoring Node zu dem Deployment für diesen Rechner an? Und hast Du dir schon einmal die clientseitigen Logs (Update*.log, ScanAgent.log, WUAHandler.log, WindowsUpdate.log) angeschaut?

Du könntest https://psappdeploytoolkit.codeplex.com/ in Verbindung mit ConfigMgr verwenden.

Sie haben geläutet? ;-) Die Frage kommt mir bekannt vor (TechNet Forum). Ich blicke bei den ganzen Aktionen nicht ganz durch, was bisher genau gemacht worden ist oder nicht. Das Problem an der Sache ist, dass ja einerseits die Updates in der WSUS-Datenbank stehen und ebenfalls noch in der ConfigMgr-Datenbank. Entsprechend habe ich dort auch schon eine Antwort gepostet - aber bisher ohne Feedback.

Ich würde mal über andere Kriterien nachdenken, die vielleicht besser geeignet sind ... letzter Login oder Reboot einer Maschine zB.

Ich will wirklich helfen, deshalb habe ich Deine Frage (die meiner Meinung nach keinen Sinn macht) hinterfragt. Entsprechend würde mich die Antwort auf mein Beispiel interessieren. Aber gut. Ich kann auch einfach die "Antwort" liefern. Die Deutung der Ausgabe dieser Daten liegt dann bei Dir. select vrs.Name0, os.InstallDate0, DATEDIFF(DD, GETDATE(),os.InstallDate0) as [OS age (days)] from v_R_System vrs left join v_GS_OPERATING_SYSTEM os on vrs.ResourceID = os.ResourceID order by 3 desc

Schlecht gewähltes Beispiel. Angenommen es gibt folgende Rechner: installiert vor 90, 120, 360, 720 Tagen. Letzte Anmeldung war bei jedem vor 85 Tagen. Was sagt das dann aus?

Geht schon, aber was hat das Installationsdatum des Betriebssystems mit der letzten Anmeldung zu tun? Irgendwie gar nichts, oder?

Lade doch mal just for fun (test) Windows 8.1 herunter und probier's damit (das .iso extrahieren und dann die Install.wim verwenden).

smsts.log sollte auf dem Client zu finden sein (höchstwahrscheinlich in x:\windows\temp\smstslog)

<blockquote class="ipsBlockquote" data-time="1395827108" data-cid="1225971" data-author="derseba"><p>Dort unter dem Reiter Netzwerkkonfiguration ein Netzwerkkonto eingegeben? </p></blockquote><br />Network Access Account ist hier nicht im Spiel. Dieser wird nur von Clients verwendet, wenn diese Content von einem DP herunterladen wollen und in keiner Domäne sind.<br />Import des .wim-Files passiert mit dem Computerkonto des Site Servers (bzw dem Server, auf dem der SMS_Provider läuft).<br />Der Name ist egal.<br /><br />

Im Logfile solltest Du ja sehen, was passiert, wenn Du das .wim einbinden willst. Dazu kannst Du cmtrace.exe verwenden (aus dem \Tools-Verzeichnis). Auswending weiss ich nicht genau, was im Log auftauchen muss.

Der Computer-Account vom Siteserver hat aber schon Berechtigungen auf dem Share/Verzeichnis, in dem sich das .wim befindet? Was steht denn im smsprov.log, wenn die Fehlermeldung auftaucht?

Bei OSD-Problemen => IMMER in's smsts.log schauen (http://www.mssccmfaq.de/2010/08/16/smsts-log/). Und zum Start erst einmal eine default Tasksequenz verwenden und keine selbst erstellen.