TorstenM

Aus welchem Grund willst Du denn das unbedingt umstellen und wie sind die Clients aktuell installiert / konfiguriert?

F8 funktioniert, sobald das WinPE gestartet ist. Eventuell fehlt "Enable command support (testing only)" in den Eigenschaften des Boot-Images: Boot Image Properties - Windows PE Tab. Ohne smsts.log kann man nur raten. Es kann auch sein, dass etwas mit dem Network Access Account nicht stimmt. Dieser ist zwingend nötig ...

Du kannst Dir das vielleicht nicht vorstellen ... ConfigMgr aber prüft das Vorhandensein aller benötigten Pakete und bringt eine Fehlermeldung, wenn etwas fehlt. Richtig. WinPE landet in X:\. Wenn die Bootimages richtig konfiguriert sind, dann kann man durch einfaches Drücken von F8 einen command prompt öffnen und die Logfiles einsehen. Und ein smsts.log wird es geben - auch wenn die HDD vorher leer war.

Weil ein Packages auf einem DP fehlt? Schau Dir mal das smsts.log (Torsten's Blog Blog Archiv smsts.log) an, dort (oder in den Webreports) sollte die PackageID zu finden sind.

"Install multiple applications" hängt davon ab, wie Du Variablen (auf Collection- oder Computer-Ebene) setzst. Ist in dem Link beschrieben und hat aber nichts mit AD-Gruppen zu tun. Verteilung mit AD-Gruppen funktioniert schon, aber hier hast Du das "Problem" mit Discovery und Aktualisierung der Collections.

Gleiches Subnetz => keine DHCP-Optionen nötig, da Broadcast. Ansonsten: Torsten's Blog Blog Archiv PXE Boot-Szenarien Wie gesagt: dabei smspxe.log beobachten, damit Du genau erkennst, was passiert.

Nur bedingt ... diese Meldungen sind normal, auch wenn alles funktioniert. Boote doch mal einen Client per PXE und schaue, was parallel im Log passiert. Kommt da der Request überhaupt an (-> MAC-Adr.)? Sind Client und PXE-SP im selben Subnet?

wdsutil wird eigentlich auch gar nicht benötigt. Du hast also WDS installiert und danach den PXE-SP? Siehe dann pxesetup.log ob dies erfolgreich war. smspxe.log muss es geben: Log Files for Operating System Deployment. Sind denn Siteserver und WDS/PXE-SP getrennte Server? Oder alles auf 1 Maschine?

Die Intervalle für Collection-Update und Discovery runterzuschrauben erzeugt eine gewisse Last => nicht gut. Helfen könnte zB "delta discovery" und "fast collection evaluation" von R3 (wenn Lizenz vorhanden). Alternativ die Tasksequenz so umstricken, dass die Apps gleich "unterwegs" mit installiert werden. Im speziellen "install multiple applications" (Install Software) und Verwendung von Collection- oder Client-Variablen.

Also: WDS installieren, aber nicht konfigurieren. Dann einen PXE-Service Point einrichten (auf dem Server, auf dem auch WDS läuft). Dann dorthin die Boot-Images verteilen: http://technet.microsoft.com/en-us/library/bb680753.aspx Ist das bereits passiert? Das smspxe.log ist im \SMS_CCM\Logs-Verzeichnis zu finden, wenn ein PXE-SP eingerichtet worden ist.

Wieso soll die Anwendung erneut ausgeführt werden? Wenn Du den Client (OS) neu installiert, dann ist doch noch keine App installiert (ausser denen in der Tasksequenz). Wobei ... der Knackpunkt ist vermutlich "Ich habe eine Sammlung die eine AD Sec Gruppe abfragt". Eine erneute Installation des OS hat höchstwahrscheinlich einen neuen Client-Record in der ConfigMgr-DB erzeugt und dem fehlen die Infos über die Gruppenmitgliedschaft, d.h. AD System Group Discovery muss laufen und die Collection aktualisiwert werden. Dann sollte es klappen ...

100MB-Partition? Wie sollte die denn bei einem PXE-Boot überhaupt schon in's Spiel kommen? Ich kann mir aber kein genaues Bild von der Konfiguration und dem Fehler machen. Sind das x86- und x64-PE-auf den PXE Service Point verteilt? (-> Package-Status) Startet denn überhaupt das PE auf dem Client (ich schätze nein)? Was steht im smspxe.log? Was ist denn auf der HDD des Clients? Lösche die doch mal komplett (zu Testzwecken).

select * from dbo.v_PackageStatusDetailSumm Wieso aber das Rad mit php neu erfinden? Es gibt doch schon den Reporting Point, der Dir zig Reports zu Verfügung stellt.

Wenn die entsprechenden Ports zwischen ConfigMgr Siteserver und SUP offen sind, dann sollte das klappen: Ports Used by Configuration Manager

Was genau willst Du denn Inventarisieren? ConfigMgr beispielsweise kann out of the box "Add/remove programs" inventarisieren, was nichts anderes ist als HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (dafür muss natürlich der SCCM-Client auf den zu inventarisierenden Clients installiert sein).

Und noch schöner, wenn man die Lösung auch anderen mitteilt ... hilft keinem weiter, wenn er/sie über diesen Thread stolpert.

Ist denn der SCCM-Client auf dem Win7-Rechner installiert (das geht aus Deiner Beschreibung nicht klar hervor; außerdem sollte der Client automatisch installiert werden, wenn Du ConfigMgr für OSD verwendest)? Schau Dir mal services.msc an (SMS Agent Host). Dann mal in den Logs schauen - zuerst in ccmexec.log, clientidstartupmanager.log, locationservices.log and clientlocation.log (aber bitte jetzt nicht einfach irgendwelche Logs posten). Dann einfach mal die 'all system' Collection aktualisieren ("update collection membership")und die Konsole refreshen - taucht der Rechner dann auf (als "Client = yes | obsolete = no")? Zur Softwareverteilung muss es ja für die Advertisements entsprechende Collections geben. Wie schaut denn deren Kriterium aus - oder sind's nur direct memberhsip rules? Und letztendlich: sind die Program denn so konfiguriert, dass diese auch auf Win7 laufen dürfen (supported platforms)?

Wieso verwendet ihr dann nicht ConfigMgr zur OS-Installation, sondern Acronis? Ihr habt ein mächtiges Tool (ConfigMgr) und nutzt es nicht bzw zahlt doppelt für Lizenzen? Macht nicht so viel Sinn. Client-Center kann die WMI ebenfalls reparieren. Kannst Du dich denn mit wbemtest auf einen Client verbinden (root\cimv2)? Oder ist hier einfach nur eine Firewall oder falscher Account im Spiel? Und letzlich: der ConfigMgr-Client könnte auch gleich mit in's Image intergriert werden: http://technet.microsoft.com/en-us/library/bb694095.aspx

Stimmen denn Share- und NTFS-Permissions? Klappen andere Packages?

Was steht denn im execmgr.log bzw smsts.log, wenn die Installation fehlschlägt?

Du brauchst halt ein zweites Program, welches die Deinstallation durchführt. Als Collection dann einfach "alle Rechner, die SW xyz installiert haben, aber nicht in AD-Gruppe ijk sind"

Beim händischen Start MUSS es das Logfile geben ... (kann auch gut sein, dass er Pfad für x64 nicht so 100% stimmt, da auswendig getippt).

Ja, es ist System Group Discovery. Nach dem Urlaub sind solche Details nicht sofort 100% verfügbar ;) Jeweils 1h ist schon relativ knapp. Dies hängt aber von vielen Faktoren ab, u.a. Hardware / Performance vom Siteserver und DB und Anzahl der Clients. Du musst aber bedenken, dass sich diese Zeiten aufsummieren können: Discovery-Interval + Collection-Update-Intervall + clientseitiges Policy-Polling-Interval (also in Summe ca. 3h wenn man davon ausgeht, dass jedes Intervall auf 60min steht).

Siehe auch im anderen Thread ... was steht denn bei den Eigenschaften einer Resource?

AD System Discovery sucht nach Computerkonten im AD (inkl. der Gruppenmitgliedschaften). Also musst Du die OUs discoveren, die auch die Computerkonten enthalten (alternativ den Haken bei "Include Groups" setzen, da bin ich mir gerade auswendig aber nicht sicher). AD System Group Discovery sollte für Gruppenmitgliedschaften gar nicht benötigt werden (sondern nur für OUs).