TorstenM

Geht's um eine Betriebssystemneuinstallation per ConfigMgr? Wenn ja: wieso denn dann 16 Advertisements? Dafür gibt's doch in der Tasksequenz den Schritt "auto apply drivers" oder "apply driver package"! Alle entsprechenden Dell-Treiber lassen sich hier runterladen: Dell Business Client Operating System Deployment - The .CAB Files - The Dell TechCenter, in SCCM importieren und gut. Die Reihenfolge ist IMHO egal.

Paket erstellen: AppDeploy.com - The Application Deployment Information Center Paket verteilen: Package + Program erstellen, auf DPs verteilen, Collection erstellen, Advertisement erstellen. Fertig :-) Deine Frage ist etwas zu allgemein gehalten. Was GENAU willst Du denn wissen?

Keine Chance, geht nicht. Selbst mit einem ConfigMgr Backp/Recovery muss der Name gleich bleiben ...

Ich hab damals die Prüfung gemacht, als sie noch im Beta-Stadium war und war erstaunt, wie wenig eigentlich das "klassische" (Softwareverteilung, Patchmanagement, Collections, etc) gefragt worden ist. Ein sehr großer Teil waren Tasksequences, NAP, native mode, DCM, etc. Ob's in der finalen Prüfung jetzt immer noch so aussieht kann ich nicht sagen.

Ich würde - falls noch keine Erfahrung mit ConfigMgr vorhanden ist - auf jeden Fall erst einmal mit dem mixed mode anfangen bzw wieder auf mixed umschalten und dafür sorgen, dass erst einmal alles funktioniert. Danach kann man den native mode in Angriff nehmen.

:shock: :eek: Ich würde diese Konstellation nicht einmal in (m)einem Testlab nutzen ...

Die Installationsvoraussetzungen: Von Configuration Manager 2007 SP1 unterstützte Konfigurationen Kleiner Tipp: dort ist SQL express nicht erwähnt.

Und? Die möglichen Ursachen schon mal geprüft? "port 443"? D.h. Du bist im native mode unterwegs? Welches Server-OS? Server 2008 (R2?)? Hast Du den IIS exakt nach der Doku konfiguriert ( http://technet.microsoft.com/de-de/library/cc431377.aspx )? Etwas mehr Details würden nicht schaden ...

Installationsreihenfolge ist ok. Werden denn überhaupt Statusmeldungen angezeigt (System Status -> Status Message Queries -> All Status Messages)? Wie sieht das mpcontrol.log aus? Taucht dort sowas wie "Call to HttpSendRequestSync succeeded for port 80 with status code 200, text: OK" auf?

Torsten's Blog :D

Beim Browsen zu einem Program ist ja *.exe voreingestellt (wenn ich mich recht erinnere). Du kannst das auf *.* ändern oder aber einfach den Namen der .cmd oder .bat in der Command Line des Programs eingeben. Diese sind natürlich verwendbar. Woran scheitert's denn bei Dir? execmgr.log auf dem Client sollte Dir sagen, ob die .cmd/.bat gefunden und gestartet worden ist und wie der Returncode war.

Das command window taucht nur auf, wenn Du in PE "F8" drückst. Das passiert nicht automatisch. Wegen dem (Re)boot: sicher, dass im PE alle nötigen NIC- und HDD-Treiber sind?

Es sollte auch mit konfiguriertem WDS funktionieren. Hast Du denn beide (!) Bootimages (x86 und x64) auf den PXE Service Point verteilt?

Ein PXE Service Point setzt den WDS-Server voraus. Also erst WDS installieren (nicht konfigurieren), dann die PXE SP Rolle aktivieren. Falls Du den WDS Dienst vorher nicht aktiv hattest: PXE SP entfernen und neu hinzufügen. Die Logs PXESetup.log und mxeMSI.log sollten Dir weiter helfen. Was das ganze aktuell mit DHCP zu tun hat verstehe ich aber nicht ... Ob Du das brauchst kannst nur Du selbst beantworten. Wenn Du über's Netz booten willst, um damit Betriebssysteme zu installieren, dann ja.

Es funktioniert und wieso sollte die ConfigMgr Product Group einen neuen Client Agent erfinden, wenn sie auf den bestehenden Windows Update Client Agent zurückgreifen und den per ConfigMgr kontrollieren können? Dass Scan und Installation auf unterschiedlichen "Wegen" laufen (Scan gegen den SUP und Verwendung von DPs für die Patchinstallation, aber ebenfalls durch den Windows Update Client Agent) ist vielleicht nicht durchgängig, aber so funktioniert das Produkt nun mal in der aktuellen Version.

Wieso fangen denn alle immer gleich mit Office an? Tut's denn nicht auch ein einfacheres msi? Schau mal ins execmgr.log auf dem Client, was los ist bzw zu den Advertisement Status Messages.

Das Dokument About Software Updates Synchronization erklärt's, Abschnitt "Synchronization for Internet-Based Software Update Points".

Das ist so "by design", siehe auch Fall 6 hier Ports Used by Configuration Manager. Die Clients (d.h. der Windows Update Client Agent) müssen sich mit dem WSUS verbinden um entsprechend einen Scan durchzuführen. Was genau hast Du mit "die Updates auf die Clients übertragen werden nachdem ich den Port von 8531 auf 443 (in der lokalen Richtlinie) geändert habe" getestet? Die Installation von Updates? Oder den Scan? Dass der Scan funktioniert kann ich mir nicht vorstellen, da der Client die Gegenstelle (WSUS/SUP) auf 443 erreichen will, diese aber auf 8531 lauscht. Die ganze Sache ist nämlich zweigeteilt: der Scan erfolgt gegen den WSUS/SUP (8531 in Deinem Fall). Die Installation ganz "klassich" von einem DP (443).

Wie? :confused: Es gibt doch gar keine Trennung zwischen WSUS und SUP, da WSUS = SUP. Oder andersrum: man kann einen SUP nur auf einem WSUS-Server installieren und damit wird der WSUS zum SUP. Bei der Installation vom WSUS hast Du ja sicher einen Port angegeben (ich tippe auf 8531) und logischerweise verbinden sich die Clients dann auch dort hin (was auch richtig ist, da ja dann auf 8531 der WSUS/SUP lauscht). Meines Erachtens stimmt das Verhalten so.

Soso. Bringt nur nix :D Die eigentliche Software-Installation kann entweder nur als "local system" ("run with admin rights") oder im Kontext des angemeldeten Users laufen. Ausnahme: Tasksequenzen von R2, die in einem anzugebenden Kontext laufen können.

Du kannst den ConfigMgr Service Manager starten (über die Admin Console) und schauen, ob's dort eine Koponenten/Thread gibt, der so heisst. Ich hab gerade meine VM runtergefahren und wüsste gerade nicht auswendig, wie das Ding heisst. Was aber egal ist, denn in Deinem Fall kommt das Advertisement ja auf dem Client an, also kein Grund, irgend etwas neu zu starten. Wie in der Mail schon geschrieben: kontrollier mal die BITS-Settings (Computer Client Agent und GPO)

Das hilft nicht so richtig weiter. Was hast Du denn gemacht/versucht und was ist dann passiert? Ohne eine Fehlermeldung o.ä. wird Dir niemand helfen können.

Ich schliesse mich den Vorrednern ebenfalls an und kommentiere Punkt 2 von Thorsten. Schema-Erweiterung und "System Management"-Container sind nicht zwingend Voraussetzung (aber trotzdem schwer empfohlen, weil es vieles deutlich einfacher macht), um clientseitig den Sitecode automatisch ermitteln zu können. Dafür müss aber (a) ein SLP (server locator point) existieren und (b) es müssen boundaries (Standortgrenzen) eingetragen sein (sowieso Voraussetzung für automatisches Site_Assignment). Siehe dazu auch Configuration Manager Site Assignment Data Flow.

Mir ist nichts bekannt, dass man diese defaults irgendwo ändern könnte.

#1: ja. Einfach ein zweites mandatory schedule hinzufügen (funzt dann aber nur, wenn statt "Rerun if failed previous" "Always rerun" gewählt ist). #2: was genau? Pakete auf DPs oder Advertisements auf einem Client nochmals ausführen?