none
SCCM 2012 R2 von Single Primary Site zur CAS RRS feed

  • Frage

  • frohe Weihnachten zusammen,
    Ich plane einige Änderungen unserer SCCM-Struktur und hoffe hier auf ein paar Kommentare zu meinen Gedankengängen.

    Ich arbeite zwar seit vielen Jahren mit SCCM - jedoch in den letzten Jahren ausschließlich mit einer single Primary Site (inzwischen ja theo. auch mehr als genug für viele viele Clients)

    Nun gibt es die Anforderung das eine andere Gruppe im Haus Server mit SCCM Managen möchte. Ich bin gesamtverantwortlich für SCCM - bisher wird dieser jedoch ausschließlich für Clients eingesetzt.

    Damit das "fremde" Team keinen Zugriff auf die Client-Infrastruktur hat - und ich in "meiner" Umgebung Standardmäßig keine Server finde - ist meiner Meinung nach die einzige Sinnvolle Lösung eine zweite Primary Site zu verwenden??

    Nun kann ich eine Standalone Single Primary Site Seit sccm 2012 sp2 (bzw. auch bei R2) Konvertieren in eine Struktur mit CAS.
    Was ich nirgends klar gefunden gabe, ob der Zielserver für die CAS auch erst einmal der gleiche Server wie die aktuelle Primary Site sein kann?

    Als aktuell:
    Server Adam: Single Primary Site Client

    Zukunft:

    Server Adam: CAS + Primary Site Client
    Server Bob: Primary Site Server

    Erster Schritt ist das Konvertieren der Single Site in die CAS auf gleichem Server Adam, dann Installation der zweiten Primary Site auf Server Bob. Wäre das so möglich?

    Im Anschluss verbindet sich die zweite Gruppe mit der Primary Site Server und *sieht* nichts von meiner Site.
    Das ganze dann durch Boundarys zu trennen und zu zu ordnen usw. ist alles kein Thema.

    Grüße

    Montag, 21. Dezember 2015 13:43

Antworten

  • Wenn es rein nur darum geht Clients von Servern zu trennen, ist meiner Meinung nach keine zweite Primary Site und schon gar keine CAS nötig.

    Mit Roll Based Administration (Security Roles & Security Scopes) kann man dies granular implementieren, dass jedes Team nur Zugriff auf seine Objekte hat (Scopes & Collections) und damit nur gewisse Dinge durchführen darf (Roles).

    Hier ist das Szenario gut beschrieben:

    http://blog.hosebei.ch/2013/06/15/sccm-2012-rbac-add-computer-to-sccm/

    http://blog-en.netvnext.com/2012/01/ensuring-desktop-admins-cant-touch.html


    Simon Dettling | msitproblog.com | @SimonDettling



    Montag, 21. Dezember 2015 14:07
  • Eine CAS löst das Problem überhaupt nicht, denn jede Site ist gleichberechtigt. Hier liegt der große Unterschied zu ConfigMgr 2007 - dort konnte man Zuständigkeiten über unterschiedliche Sites trennen. Bei ConfigMgr 2012 oder später dient eine CAS und mehrere Primaries nur zu Skalierungszwecken.
    Administrative Trennung erfolgt per RBA, wie Simon schon schrieb (wobei dann kein Unterschied zw. Standalone Primary und CAS mit einer oder mehreren Primaries besteht).

    Torsten Meringer | http://www.mssccmfaq.de


    Montag, 21. Dezember 2015 14:24
    Beantworter
  • Auf Ordner kann man leider keine Berechtigungen vergeben. Jeder sieht leider alle Ordner, auch wenn diese leer sind (weil es darin keine Objekte gibt, auf die man Rechte hat). Collections selbst werden schon für die Rechtevergabe verwendet, somit können darauf keine weiteren Rechte vergeben werden (Stichwort: limiting collection). Auf zB Pakete kann man Scopes vergeben. Über die Rollenmitgliedschaft wird dann gesteuert, was mit den Paketen passieren darf, die im Scope eines Users sind.

    Torsten Meringer | http://www.mssccmfaq.de

    Montag, 21. Dezember 2015 15:10
    Beantworter

Alle Antworten

  • Wenn es rein nur darum geht Clients von Servern zu trennen, ist meiner Meinung nach keine zweite Primary Site und schon gar keine CAS nötig.

    Mit Roll Based Administration (Security Roles & Security Scopes) kann man dies granular implementieren, dass jedes Team nur Zugriff auf seine Objekte hat (Scopes & Collections) und damit nur gewisse Dinge durchführen darf (Roles).

    Hier ist das Szenario gut beschrieben:

    http://blog.hosebei.ch/2013/06/15/sccm-2012-rbac-add-computer-to-sccm/

    http://blog-en.netvnext.com/2012/01/ensuring-desktop-admins-cant-touch.html


    Simon Dettling | msitproblog.com | @SimonDettling



    Montag, 21. Dezember 2015 14:07
  • Eine CAS löst das Problem überhaupt nicht, denn jede Site ist gleichberechtigt. Hier liegt der große Unterschied zu ConfigMgr 2007 - dort konnte man Zuständigkeiten über unterschiedliche Sites trennen. Bei ConfigMgr 2012 oder später dient eine CAS und mehrere Primaries nur zu Skalierungszwecken.
    Administrative Trennung erfolgt per RBA, wie Simon schon schrieb (wobei dann kein Unterschied zw. Standalone Primary und CAS mit einer oder mehreren Primaries besteht).

    Torsten Meringer | http://www.mssccmfaq.de


    Montag, 21. Dezember 2015 14:24
    Beantworter
  • Danke ihr 2,

    ich hatte mir das Rechtemodell zuvor schon noch einmal angeschaut - nur unter andrerem nicht gesehen wo z.B. für einzelne Ordner, Collections, Pakete usw. keine Rechte vergeben kann... aber nach eurer Lektüre Passt das nun, somit kann ich mir wohl sogar einen neuen Server sparen und alles mit einem SiteSever handeln (Sind "nur" 1800 Rechner und ~400 Server)

    Das ging ja super fix :D

    Montag, 21. Dezember 2015 14:52
  • Auf Ordner kann man leider keine Berechtigungen vergeben. Jeder sieht leider alle Ordner, auch wenn diese leer sind (weil es darin keine Objekte gibt, auf die man Rechte hat). Collections selbst werden schon für die Rechtevergabe verwendet, somit können darauf keine weiteren Rechte vergeben werden (Stichwort: limiting collection). Auf zB Pakete kann man Scopes vergeben. Über die Rollenmitgliedschaft wird dann gesteuert, was mit den Paketen passieren darf, die im Scope eines Users sind.

    Torsten Meringer | http://www.mssccmfaq.de

    Montag, 21. Dezember 2015 15:10
    Beantworter