TorstenM

Wer's lieber in englisch hat: Configuration Manager Supported Configurations.

AD Schema für SCCM erweitert ODER SLP (server locator point) installiert?

Nein, weder reicht die, noch ist die supported, noch lässt sich dies so installieren. Minimum SQL 2005 SP2!

Kommt auf die genauen Anforderungen an ... ConfigMgr mit MDT könnte evtl. sogar zu viel des Guten sein. Ich denke, Dich interessiert genau das: Download details: Microsoft Deployment Toolkit 2008 Update 1 (Zitat: "MDT 2008 Update 1 includes new capability for OEM preload scenarios").

Gegenfrage: wieso denn unbedingt ConfigMgr? Für diese Anzahl an Clients könnte doch ggfs. auch SCE (System Center Essentials) ausreichend sein; günstiger ist's auf jeden Fall.

Direkt per SQL würde ich das nicht lösen, sondern eher über ConfigMgr-SDK-Mechanismen. Dann einfach schauen, welche Collections sich unter der XYZ befinden und die Maintenance-Window-Eigenschaften auf die darunter liegenden übertragen ... (Übrigens: die Collection-Struktur ist in der Tabelle "Collection_SubCollections" abgebildet)

Das ist "by design" und nicht zu ändern. Maintenance Windows beziehen sich nur auf eine Collection bzw die darin enthaltenen Rechner. Eine "Vererbung" auf untergeordnete Collections gibt's nicht.

Kann man so nicht sagen. Wieso ist denn die Client Push Installation fehlgeschlagen? Steht entweder in Status Messages, Webreports oder im ccm.log auf dem Siteserver ...

Wie installierst Du denn die Clients? Client Push Installation, nehm ich an? Schau doch mal unter System Status -> Site Status -> <SiteCode> -> Component Status und dann SMS_Client_Config_Manager. Dort solltest Du sehen, was mit der Client Push Installation los ist. Alternativ dazu im ccm.log auf dem Siteserver. Wieso manche Rechner noch keinen Client haben kann zig Ursachen haben: Firewall, File&Print Sharing disabled, falsche Namensauflösung, offline, nicht durch eine Discovery Methode erwischt, ....

WSUS? Winfried? Oder was?

Here I am ... Ich weiss, ich weiss, ... auf der Seite fehlt noch etwas der Inhalt :) Ok, komplett der Inhalt. Aber ich komme da absolut nicht dazu. Zu viel zu tun. Client können nur automatisch gepusht werden, wenn sie über eine discovery methode ermittelt worden sind. Du kannst z.B. AD System Discovery anwerfen.

Richtig, kann er.

Naja, so würde ich das nicht pauschalisieren. Normalerweise funzt das schon so, wie vom Hersteller geplant ;) Wenn man aber erst einmal die DVD zur SecSite kopieren muss, dann jagt man > 1GB über's WAN, was deutlich mehr ist als die <200MB für die Installation der SS per Wizard. Aber Hauptsache es funktioniert bei Dir jetzt! Happy SCCM'ing

DNS sollte an der Stelle vermutlich noch keinen Einfluß haben (die Info, dass was installiert werden soll, kommt ja an der SecSite an). Gibt's auf dem Server keine Eventlog-Einträge? Oder Status Messages auf der Primary Site? Ich würde jetzt mal die ganze DVD auf den Server kopieren und die Installation "lokal" probieren (also von der DVD starten). Dann sollten in C:\ deutlichere Logs auftauchen.

Sollte theoretisch funktionieren. Schau mal praktisch in die Registry, ob unter HKLM\Software\Microsoft\SMS\AdminUI\Connection\Server der Servername steht und nicht der Sitecode ...

SCCM-DVD auf die Secondary Site kopieren und dann die Installation starten (ich weiss ... muß ggfs. über's WAN). Da fällt mir nochwas ein: hat das Setup auf der Secondary Site schon Logs nach C:\ geschrieben? Schau mal da rein.

Klingt gut. Sofern sich keine Boundaries überlappen. Öhm, naja. Die Boundaries kannst schon an der Central Site eintragen, aber halt dann den Secondaries die entsprechenden zuordnen. Wenn Du die Primary am Hauptstandort stehen hast und dort auch Clients verwalten willst, dann trägst nur die Subnetze/AD-Sites vom Hauptstandort füt die Primary ein. Hast Du einen Außenstandort mit einer Secondary, dann trägst dort als Boundary eben das Subnetz des Außenstandortes ein. Dann gäbe es noch den Unterschied von fast und slow, aber das kommt in Kapitel 2 ;) Sollte so sien ... Jahrelange Erfahrung mit SMS & Co sozusagen ... Je nach WAN-Leitung und Inst.-Art unterschiedlich. Aber bei halbwegs vernünftiger Anbindung <15min. setup.exe /? => setup /prereq Danke nochmals und einen schönen Tag Gruss Thomas

Wenn Du keine Erfahrung mit SMS hast, dann spielt's keine Rolle, was Du einsetzt. Ich würde dann aber auf ein aktuelles Produkt setzen (SCCM) und nicht auf ein "altes". Außerdem ist Patch Management mit SCCM deutlich einfacher als mit SMS+ITMU.

Ich versteh's schon. Ist höchstwahrscheinlich ein Problem der Boundaries. Siehe dazu aber mein vorheriges Posting.

Wenn Du den Haken nicht setzt, dann landen alle Packages in dem Verzeichnis \SMSPKG und dann in einem Unterverzeichnis, welches die SMS-PackageID trägt (also <SiteCode>xxxxx, z.B. ABC00001). Mit Haken sieht's so aus, wie Du es beobachten konntest. Hat mit den Zugriff auf das Paket nicht so viel zu tun. Damit definerst Du, welche Subnetze / AD-Sites / IP-Ranges von welcher SMS-Site verwaltet werden bzw auch die "Zuordnung" der DPs. "Send from nearest" ... hat mit den Clients gar nichts zu tun. Damit konfigurierst Du nur das Verhalten, wie SMS die Packages zu den einzelnen Sites schickt. Ich kenne Deine Infrastruktur nicht. Wenn Du nur an der Central Site eine AD Site engetragen hast und auf den Secondaries nicht, dann ist es klar, dass alle Clients die Packages von der CS ziehen. Immer nur an der Site die Boundaries eintragen, die zu verwaltende Clients enthalten. Hast Du z.B. eine Secondary Site in Area51 stehen und dort die AD-Site area51-AD, dann trägst Du an der Site die Boundary aea51-AD ein (bzw das Subnetz). Das macht natürlich nur Sinn, wenn die Site auch mind. einen DP hat.

Angekündigt war's für 20. Februar ... sollte also demnächst so weit sein.

DIE Installationsanleitung wird's nie geben. Dazu ist das Produkt zu komplex und außerdem musst Du natürlich die bestehende Infrastruktur beim Design in Betracht ziehen. TechNet ist momentan das einzige; bald kommt noch das Buch von MS Press (engl). Empfehlung: in Deinem Fall erst mal eine Testumgebung!

Offendichtlich ist die Primary Site ein DP und das Office-Paket als 'office' geshared (share distribution folder). Das Verzeichnis samt Freigabe wird neu angelegt worden sein, weil jmd das Package refreshed hat. Wenn sich Clients von Niederlassungen die Sourcen zentral holen, dann stimmt ggfs mit den Boundaries etwas nicht.

Klar hab ich den gesehen. Dort steht aber, dass ggfs. erst RIS installiert werden soll, um dann auf WDS zu aktualisieren. D.h. Du hast am Ende nur noch WDS, kein RIS mehr. Zitat aus der gleichen Quelle von Dir: "The PXE service point site role must be installed on a server with WDS installed"

SMS-Setup anwerfen und Admin-Konsole installieren!