TorstenM

Ich würde statt "c:\windows\system32\cscript" nur "cscript" verwenden oder zumindest "%windir%\cscript". Existiert denn C:\Programme\Microsoft Office\Office14\OSPP.VBS? Ggfs Unterschiede bei 32bit/64bit beachten. Außerdem hast Du die Anführungszeichen an einer seltsamen Stelle. execmgr.log und smsts.log sollten Details zeigen. Wurde das Skript überhaupt gefunden und gestartet, wurde es gestartet und wie sieht der Returncode aus? Weiterhin kann man sich den Umweg über die .cmd sparen und das vbscript direkt als command line angeben. Was allerdings hier auch keinen Sinn macht: wieso ist das vbs in einem Package, wenn es doch auf dem Client liegt? Also entweder einen "run command line"-TS-Step (ohne Package) und das vbs lokal starten ODER aber ein Package mit Source-Files und einen "Install Software"-TS-Step.

Das liegt an den Program Settings: Installieren von Softwarepaketen als Teil einer Tasksequenz.

"Netzlaufwerk verbinden" ist hier völlig sinn- und nutzlos. Das Paket liegt auf einem Distribution Point und damit weiss der ConfigMgr-Client automatisch, wo er es finden kann. Durch das Programm im Paket definierst Du, was/wie gestartet werden soll. Entsprechend weiss auch die Tasksequenz, welches Programm auszuführen ist (als TS-Schritt "Install Software" verwenden und nicht "Run command line"; "run command line" würde auch funktionieren, der Einfachheit wegen aber hier nicht verwenden).

Erstelle einfach ein neues Paket und lege dort die cmd rein. Verteile dieses Paket auf mind einen Distribution Point. Erstelle ein neues Programm im Paket (als command-line "office.cmd") und setze die Option "Allow this program to be installed from the Install Software task sequence without being advertised". Füge in die OSD Tasksequenz einfach einen neuen "Install Software"-Schritt ein und wähle das package/program. Fertig. Wieso sind denn die bisherigen Versuche fehlgeschlagen?

Hier gibt es keine "one fits all"-Antwort. AppDeploy.com - The Application Deployment Information Center beschäftigt sich mit solchen Fragen. ConfigMgr ist es prinzipiell egal, welcher Format vorliegt, so lange Du entsprechende Parameter mitgeben kannst, damit die Installation unbeaufsichtigt abläuft. Dies wiederum liegt am Hersteller ... im Idealfall hast Du ein msi (was ich auf jeden Fall einer .exe vorziehen würde).

Das würde ich nicht einmal in einem Testlab machen. Viel zu kurzes Intervall! Bei ConfigMgr braucht man insgesamt schon etwas Geduld, "sofort" passiert dort wenig, da insgesamt viele Einzelteile ineinander greifen, die in eigenen Intervallen ausgeführt werden.

Hast Du clientseitig schon den "Software Updates Scan Cycle" bzw "Software Updates Deployment Evaluation Cycle" gestartet oder das defalut Intervall abgewartet?

Das alles klingt sehr wirr und nicht nachvollziehbar. ConfigMgr ist in der Tat nicht sehr intuitiv; deshalb kommt man auch nicht sehr schnell zum Ziel, wenn man sich vorher nicht in das Thema eingelesen hat. Deine Schilderungen klingen erst einmal nach "Grundlagen nicht verstanden". Was für ein Problem ist denn aktuell noch ungelöst?

Wilde Vermutung. An welcher Stelle sollte denn hier eine temporäre Partition verwendet werden? Zum Zeitpunkt der Softwareinstallation in einer Tasksequenz befindet man sich schon im Ziel-OS; nachher wird an der Partitionierung nichts mehr geändert. smsts.log oder die Webreports zum Fortschritt der Tasksequenz sollten evtl brauchbare Hinweise liefern.

Wie "wie"? Skript? Manuell? usw

Ja, das ist eine "fertige" VM, die Du zu Testzwecken verwenden kannst.

Du brauchst auf jeden Fall einen PXE Service Point. Ist dieser installiert? Dann müssen beide WinPEs (x86 und x64) dort verfügbar sein. Was steht im smspxe.log? Hast Du DHCP-Optionen oder IP-Helper eingerichtet (wenn Client in einem anderen Segment als PXE-Server)?

Mir ist keine "fertige" Lösung von Microsoft bekannt, um DPM in ConfigMgr zu integrieren. Deine Forderung kann aber mit ConfigMgr-Bordmitteln erreicht werden: Stichwort USMT-Integration / State Migration Point.

So wenig aus dem Logfile hilft nicht wirklich viel ... Auch muss man sicher nicht jedes Mal eine neue TS erstellen. Da sind wir wieder bei meinem Hinweis am Anfang. Ohne etwas zu lesen und ein gewisses Grundverständnis für ConfigMgr zu haben, wirst Du nur von dem einem in den nächsten Fehler laufen und relativ schnell frustriert werden.

Antwort siehe Betriebssystem verteilen mit SCCM2007 R2

Selbstverständlich gibt es ein Buch auch von MS Press: Amazon.com: Microsoft® System Center Configuration Manager 2007 Administrator's Companion (9780735623859): Steven D. Kaczmarek, Microsoft System Center Team: Books, welches allerdings auf dem Stand von RTM ist; mittlerweilse sind wir ja bei R3 und SP2. Ich hab zwar fast alle Bücher, kann dir aber nichts über den Inhalt sagen, da ich keines bisher wirklich verwendet habe ;-) Wie sieht's denn im ADsysdis.log? Konnten DDRs erstellt werden? Funktioniert ConfigMgr überhaupt?

In ConfigMgr-Logs wirst Du wahrscheinlich nicht so viel finden, außer dass halt der Schritt nicht geklappt hat (gleiches gilt für die Reports auf dem Reporting Point & Co). Panther: Windows 7, Windows Server 2008 R2, and Windows Vista setup log file locations

Ohne zu etwas zu lesen wirst Du höchstwahrscheinlich nur von einem in's nächste Problem laufen ... Intuition hilft hier leider nicht viel ;-) Was für eine discovery method ("Ermittlungsmethode") hast du denn konfiguriert/aktiviert? AD System Discovery? Hast Du schon einmal die Collections aktualisiert, nach dem AD System Disocvery lief? Per default passiert dies nur 1x/Tag (Rechtsklick -> Update collection membership; kurz warten; dann refresh (F5) der Konsole). Bücher gibt's nicht so viele: einfach mal bei Amazon schauen. Homepages / Blogs gibt's genug - hier hilft die Suchmaschine Deiner Wahl.

Steht doch glasklar da, was schief läuft ... in der unattend.xml kann im pass "specialize" etwas nicht verarbeitet werden, d.h. unattend.xml mal untersuchen bzw die Logs in \Panther. Fehlt in der TS wirklich "Setup Windows & ConfigMgr"?

Schema-Erweiterung ist neu => Schema für ConfigMgr erweitern. Parallelbetrieb möglich, sofern es keine Überlappungen bei Boundaries und Sitecodes gibt.

"Nur" ist gut ... OSD ist ein komplexes Thema und ohne Lesen von Literatur wirst Du dabei nicht weit kommen. Hier ist ein englisches Whitepaper von MS, welches erst einmal helfen sollte: Download details: System Center Configuration Manager 2007 Operating System Deployment Guide: Healthcare

Re-Run behavior innerhalb des Programs checken (-> müsste "Always re-run" für Deinen Fall sein). Computer Client Agent -> policy polling interval

Bei "like" brauchst Du immer "%", also like "%foxit%". Troubleshooting: Nimm doch einfach mal das Kriterium innerhalb der Klammern und erstelle daraus eine Collection. Funktioniert dies? Erhältst Du dann wirklich nur Rechner, auf denen Foxit installiert ist?

... dass Du keine subselect/not in-Abfrage verwendest: siehe www.mssmsfaq.de

Mit dynamischen Collections, die query-based sind. Sei es (deutsch, nicht WQL ;-) ): "alle Rechner, deren Namen ungefähr wie DE-PC-10% ist", "alle, die Adobe Reader, Version 9.% installiert haben", "alle in der Domain mydomain.local". Hier gibt es keine all-fits-one Antwort. Um am Beispiel meiner vorherigen Antwort zu bleiben: Coll1 kann ja gerne statisch sein (wobei ich persönlich Collections mit Direct Membership Rules eigentlich nie verwende, selbst wenn es nur um einen Rechner geht; aber auch da spielen viele Faktoren rein). Coll2 dann dynamisch, mit einer Abfrage auf "Add/Remove Programs" und auf Coll1 limitiert.