TorstenM

Verwende mal "client local time". Die Intervalle kannst Du bei Site Settings -> Client Agents konfigurieren (und dabei überprüfen ob der Software Upates Client Agent überhaupt aktiv ist).

Also wie jetzt? Erst später oder "Windows Client nimmt keine Updates an"? Titel und Inhalt der Frage stimmen nicht wirklich überein. Hast Du im Deployment "client local time" oder "UTC" verwendet? Wie sind die Intervalle für den Computer Client und Software Updates Client Agent definiert?

Ja, gerade mit R2 kamen viele Neuerungen hinzu (Reporting Services Reports, unknown computer support, AppV usw).

Das Attribut "deutsch" schränkt die Auswahl extrem ein. Englisch gibts mehr (und auch aktueller; Stichwort: SP2 und R2).

Wenn er ohne 66/67 nichts macht, dann ist aber nicht im gleichen Subnetz wie der WDS-Server oder aber die Broadcasts kommen nicht an. "PXE Boot aborted. Booting to next device..." ist eine Antwort vom PXE-SP (siehe mein Blog) -> was steht im smspxe.log?

Option 60 ist meiner Erfahrung nach nur bei non-MS DHCP-Servern nötig. Also zum Test einfach mal weglassen. Wie sind denn die Werte der Optionen? Wenn gleiches Subnetz, dann brauchst eigentlich gar keine DHCP-Optionen für einen erfolgreichen PXE-Boot. Also einfach mal ohne testen.

Ist das "Installationsabbild" das .wim von der kompletten Win7-Installation? Wenn ja, dann hat das nichts auf dem PXE-SP zu suchen. Auf diesen müssen nur das x86 und x64 Boot-Image (WinPE). Sind PXE-Client und PXE-SP im gleichen Subnetz? Sind DHCP-Optionen oder IPhelpers eingerichtet? Was taucht am PXE-SP im smspxe.log auf? Erscheint dort überhaupt die MAC des Clients? Torsten's Blog Blog Archiv PXE Boot-Szenarien kann auch hilfreich sein.

Die ConfigMgr-Technet-Doku ist dazu ganz brauchbar: http://technet.microsoft.com/en-us/library/bb680733.aspx

extadsch.exe generiert ein Logfile -> extadsch.log in C:\. Dort steht Erfolg oder Mißerfolg drin. Ich würde den native mode erst einmal komplett aussen vor lassen. ConfigMgr ist schon komplex genug. Implementiere erst einmal den mixed mode und erst wenn dieser insgesamt läuft auf native mode umschalten. Im native mode sind ja nicht nur client-seitige Certs im Spiel.

Direct membership bietet Dir eine Auswahl an, ja. ABER: die Mitgliedschaft in einer Collection wird durch die ResID bestimmt => bei einer Neuinstallation bekommt der Client eine neue => er ist nicht mehr Mitglied der Collection. Deshalb lieber query based nehmen. Ich hab die Prüfung damals in der Beta-Version gemacht und kann mich schon gar nicht mehr an die Inhalte erinnern.

Das ist das Problem mit den Direct Membership rules (ich schätze, diese wurde verwendet). Eigentlich wird im Hintergrund die ResourceID verwendet, nicht der Name => Du hast evtl einen Rechner mit "obsolete yes, active no" erwischt (anstatt genau andersrum). Das würde nicht passieren, wenn Du eine dynamische Query mit (sinngemäß) "... Name = 'PCNAME' " verwendet hättest (da wären dann eben 2 Rechner Mitglied der Collection gewesen). Der Client kontaktiert übrigens immer den Server => auch wenn die IP in ConfigMgr nicht aktuell war und selbst wenn DNS hier nicht stimmte, hätte er trotzdem die Policies erhalten müssen.

Welches OS? Welche ConfigMgr-Version (SP)?

Es gibt 2 Arten von Sammlungen: dynamische (query based) und statische (direct membership rules): Informationen zur Sammlungsmitgliedschaft Nur auf diese beiden Wege kannst Du Clients zu Mitgliedern machen.

Und ein weiterer Teil des Kurses "Wie kann ich Fehlermeldungen allgemein troubleshooten" ... 80070057 = One or more arguments are invalid. Woher nimmt die Tasksequenz die Parameter? Aus dem Step "Setup Windows and ConfigMgr". Also, welche 'Installation properties' sind dort zu finden?

Welches Logfile ist hierfür zuständig? ccmsetup.log und/oder client.msi.log (je nachdem, an welcher Stelle die Installation aus der Kurve fliegt) ... dort sollten Details stehen.

Also langsam wird das Spiel langweilig ... poste doch bitte den Inhalt des smsts.log. Ohne dessen Details wird Dir kaum jemand helfen können.

Die Frage ist ja immer noch, welches Paket genau nicht gefunden werden kann ... es muss ja nicht das OS-Package sein.

"Update DP" kann nur funktionieren, wenn es bereits erfolgreich dorthin verteilt worden ist. Hast Du den DP bereits hinzugefügt? Auch hier gibt es wieder Statusmeldungen und ein Logfile (distmgr.log).

Du suchst aber schon auf dem Client und nicht auf dem Server? Und sehe ich es richtig dass der Rechner die angekündigte Tasksequenz im laufenden Betrieb als Ankündigung erhält (und nicht per PXE- oder sonstigem Boot)? Unter System Status -> Advertisement Status oder den Webreports (Status of a specific task sequence advertisement for a specific computer) findest Du auch mehr Infos.

Sollte unter \ccm\logs\smsts.log oder \ccm\logs\smsts\smsts.log liegen, wenn Du die Tasksequenz auf einen bestehenden Rechner ankündigst. Weiterhin gib't noch Advertisement Status Messages und Webreports, die alle mehr Details liefern.

http://technet.microsoft.com/en-us/library/bb680343.aspx: "Manage Remote Assistance settings: Specify whether to allow Configuration Manager 2007 to manage remote assistance for solicited and unsolicited sessions."

Und wieder meine Standard-Antwort, wenn's um OS-Deployment geht: smsts.log! Dieses Log ist essentiell, um Fehler eingrenzen zu können. Nach welchem Programm sucht er denn? Das .wim kann's laut Deiner Aussage nicht sein, da dies ein Paket ist (und kein Programm). Und welche Fehlermeldung kommt?

Z.B. mit einem WinPE booten und dann das Logfile suchen / anschauen.

Siehe im anderen Thread, dort habe ich geschrieben, wo das Log zu finden ist. Die Frage nach Aussehen eines Logs macht irgendwie keinen Sinn ...

OS neu installiert => neuer Datensatz in SCCM. Der bestehende (der durch die direct membership rule Mitglied einer Collection ist) wird obsolet; der neue Datensatz ist somit nicht mehr Mitglied in den Collections (da neue ResourceID).