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").

Geplant ist das für ca 120 Clients

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.

Der SCCM 2007 glaub ich, soll das können.

Richtig, kann er.

Ich kann jedem nur empfehlen die Sites manuell zu installieren da man extrem weniger Probleme hat als übers Netzwerk und man den Traffic beim verwenden von WAN-Leitungen auf die SecSites sich auch sparen kann beim installieren.

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 ...

Ich habe das Setup versucht lokal zu installieren, jedoch frage ich mich ja wie ich das machen soll da der SCCM bei der installation ja die source lokal entpackt und dann wieder löscht.

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.

Ich habe nun die Boundaries auf die Secondary Sites so angepasst, das sie auf die IP Adress Ranges des DHCPs auf die jeweillige Niederlassung greifen.

Klingt gut. Sofern sich keine Boundaries überlappen.

Da ich ja von meiner Parent Site alle Clients verwalten will, muss ich ja die Boundaries auf die AD Central Site lassen oder?

Ö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 ;)

Ich hoffe nun mal das alles so funktioniert und unsere WAN Leitungen verschont bleiben von Clients, welche auf die Sourcen zugreifen möchten.

Sollte so sien ...

Hast du irgendwelche Super Anleitungen das du solche Informationen hast, oder bist du bis anhin nur die Library des SCCM durchgegangen?

Jahrelange Erfahrung mit SMS & Co sozusagen ...

So wie es scheint hast du schon Secondary Sites installiert, wie lange hat es bei dir gedauert bis diese im SCCM ersichtlich waren? bei uns liegt die Zeit ca. bei 3 Tagen, was ich ziemlich lange finde.

Je nach WAN-Leitung und Inst.-Art unterschiedlich. Aber bei halbwegs vernünftiger Anbindung <15min.

Habe auch erst im nachhinein bemerkt, das WEBDAV und BITS installieren muss da dies in der Doku und im 1 tägigen Kurs nirgends erwähnt wurde.

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.

Das Problem hat sich behoben, d.h. die Shares wurden nicht mehr erstellt.

Jedoch habe ich nun ein anders Phänomen festgestellt, die Clients greifen nun auf den Share E:\smspkge$\BMA.....\.... und dann auf die Office cab Dateien zu.

Ich verstehe langsam den Hintergrund nicht mehr, habe zurzeit einen Workaround mit der Berechtigung erstellt, wäre aber froh wen mir jemand von euch weiterhelfen kann.

 

Danke vielmals eure Hilfe und noch ein riesen Dankeschön an ThorstenM

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

Edit: Habe die Einstellung "Share Distribution Folder" gefunden und war wirklich aktiviert. Kannst du mir noch genau sagen was diese Einstellung bringt? Ich vermute einmal das sich dann die Clients nötige sourcen für Komponenteninstallationen, etc. von dort ziehen können, sehe ich das richtig??

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.

Wäre froh wen du mir kurz noch die Frage mit den Boundaries beantworten könntest.

Danke nochmals...

Damit definerst Du, welche Subnetze / AD-Sites / IP-Ranges von welcher SMS-Site verwaltet werden bzw auch die "Zuordnung" der DPs.

Zuerstmals danke vielmals für deine Antwort.

Ich habe heute noch entdeckt das bei der "Component Configuration" auf der Parent Site der Kontrollkasten "Send Package from the nearest site in the hierarchy" nicht aktiviert war, ich hatte vorhin schon Probleme das die Geräte in den Niederlassungen sich die Pakete immer von der Parent Site zogen und somit die WAN Leitung auslausteten, konnte dies jedoch unterbinden in dem ich die Collection-Advertisements auf die Niederlassungsserver festlegte....

"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.

Boundaries sind auf Active Directory Site -> Central eingestellt.

Kennst du ein besseres Prinzip? Wir haben in jeder Niederlassung ein einzelnes Subnetz, wen man es irgendwie lösen könnte, das die Subnetze immer dem Secondary Site Server angehören, dann wäre das sicherlich die beste Methode, weisst du da einen Weg?

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!