none
ConfigMgr 2012 Verstaendnisproblem bei der Topologie mit SUP

    Frage

  • Hallo zusammen,

    folgende Beispieltopologie:

    Im RZ
    1 CAS
    1 Primary (erstmal) als DP, FSP, MP, SUP

    Zweigstellen
    Je 1 MP mit DP und SUP Rolle

    DMZ
    Ebenfalls 1 MP mit DP und SUP Rolle, Kommunikation mit der Primary Site DB ueber IPSec Tunnel etc. entsprechend abgesichert.

    Die Zweigstellen sind mit relativ niedriger Bandbreite angebunden, so dass saemtlicher Content (Software + Updates) fuer die Clients am Standort liegen soll. Das scheint auch zu funktionieren.

    Die Idee hinter diesem Testaufbau war es das LAN und Systeme in der DMZ (die zu einem anderen Forest gehoeren) mit Software und Updates zu versorgen und dabei moeglichst wenig Bandbreite zu verbrauchen.

    Jetzt ist mir beim testen aber aufgefallen, dass man pro Site (Primary und Secondary) nur einen aktiven SUP definieren kann. Ich bin davon ausgegangen dass der SUP automatisch ermittelt wird, so wie auch der DP (anhand der Boundaries). Dem ist wohl nicht so. Saemtliche SUP Rollen koennte ich daher entfernen, da ich pro Primary oder Secondary Site ja sowieso nur 1 definieren kann.

    Sehe ich das richtig, dass ein Client immer mit einem SUP auf einer Primary oder Secondary Site sprechen muss, sich den Content (auch die Windows Updates) immer ueber den MP holt? Wenn ja, wie sieht die Kommunikation genau aus, bzw. mit welchen Datenmengen kann man hier rechnen?

    Kann ich meiner Anforderung, moeglichst wenig Bandbreite zu verbrauchen gerecht werden wenn ich im LAN weiterhin nur MPs (dann ohne lokalem SUP) fuer die Zweigstellen vorsehe und in der DMZ, damit hier ein SUP fuer die Clients ansprechbar ist, eine Secondary Site inkl. SUP Rolle vorsehe?

    Mit dem Technet bin ich durch, aber die Dokus zum Thema Topologie und Kommunikation zwischen den einzelnen Komponenten sind dort noch nicht so gut ausgebaut wie fuer SCCM 2007. Daher tue ich mir gerade etwas schwer fuer eine geplante 2012er Implementierung die richtige Topologie zu finden.

    Montag, 11. Juni 2012 09:02

Antworten

  • Zuerst würde ich die Verwendung einer CAS in Frage stellen. Bei (deutlich weniger) als 100.000 Clients ist die meist nicht nötig.
    Als nächstes den MP in den Zweigstellen. Ich würde diesen jeweils komplett weglassen, da man (auch anhand der Boundaries) nicht steuern kann, welcher der MPs wirklich verwendet wird. Außerdem ist der Traffic, der zwischen Client(s) <--> MP entsteht, zu vernachlässigen. Entsprechend dann an remote Standorte entweder eine Secondary Site oder nur einen sender-enabled DP (je nach Anzahl Clients und Anbindung).
    Es ist richtig, dass es nur einen aktiven SUP pro Site geben kann (bzw 2: http und https). Die Clients brauchen diesen nur, um den Katalog zum Scannen zu verwenden. Die eigentlichen Patches werden dann von den DPs (und nicht MP wie angenommen) heruntergeladen.
    Zum Thema "cross forest" ist dieser Artikel sehr empfehlenswert: http://technet.microsoft.com/en-us/library/gg712701.aspx#Plan_Com_X_Forest

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

    Montag, 11. Juni 2012 10:47
  • Secondary scheidet wegen dem two way trust aus, richtig. Eine Site kann aber 2 SUPs haben: einen http und einen https: http://technet.microsoft.com/en-us/library/gg712696.aspx#BKMK_InternetSUP. Somit können zB MP, DP und SUP (jwls https) in die DMZ. Siehe nochmals http://technet.microsoft.com/en-us/library/gg712701.aspx#Plan_Com_X_Forest ;-): "Communication in a site that spans forests: Does not require a two-way forest trust: To support clients primary sites support the installation of each site system role on computers in other forests. Note: Two exceptions are the out of band service point and the Application Catalog web service point. Each must be installed in the same forest as the site server."
    CAS ja oder nein ist mehr oder weniger eine Glaubensfrage (bzw hängt letztendlich vom Budget ab). Nötig ist sie in den meisten Fällen nicht. Beim Disaster-Recovery hat man minimale Vorteile. Eine standalone Primary lässt sich aber natürlich trotzdem wiederherstellen.

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

    Montag, 11. Juni 2012 12:08
  • Update / Nachtrag / Korrektur: secondary Sites bringen bei IBCM-Szenarien gar nichts: "There is no support for internet based clients using secondary sites in 2012. You cannot install any internet facing roles (MP or DP) off of a secondary site as well."

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

    Mittwoch, 20. Juni 2012 17:08
  • Danke fuer den Nachtrag. Inzwischen glaube ich eine akzeptable Loesung gefunden zu haben. Voraussichtlich werden wir die DMZ1 und DMZ2 miteinander sprechen lassen koennen.

    In diesem Fall werde ich den SUP ganz einfach in die DMZ packen wo sowieso ein Site System fuer´s Internet geplant war. Dort ist er von ueberall erreichbar (LAN, DMZ, Internet). Da auf dem SUP offenbar keinerlei interne Daten liegen, sondern mehr oder weniger nur der Update Katalog (ohne Content), habe ich keine Bauchschmerzen damit ihn auch von internen Systemen nutzen zu lassen. Ich muss unsere Testumgebung dahingehend noch umbauen um Gewissheit zu haben. Aber das erscheint mir derzeit die einzige und beste Moeglichkeit um alle Fliegen mit einer Klappe schlagen zu koennen.

    Damit waere auch das Ziel erreicht mit einer Primary Site inkl. verteilter Site Systeme an div. Standorten und Netzwerksegmenten alle Systeme zu verwalten. Egal in welchem Netz (Internet, DMZ1/2, LAN) sie sich befinden.

    Donnerstag, 21. Juni 2012 05:52

Alle Antworten

  • Zuerst würde ich die Verwendung einer CAS in Frage stellen. Bei (deutlich weniger) als 100.000 Clients ist die meist nicht nötig.
    Als nächstes den MP in den Zweigstellen. Ich würde diesen jeweils komplett weglassen, da man (auch anhand der Boundaries) nicht steuern kann, welcher der MPs wirklich verwendet wird. Außerdem ist der Traffic, der zwischen Client(s) <--> MP entsteht, zu vernachlässigen. Entsprechend dann an remote Standorte entweder eine Secondary Site oder nur einen sender-enabled DP (je nach Anzahl Clients und Anbindung).
    Es ist richtig, dass es nur einen aktiven SUP pro Site geben kann (bzw 2: http und https). Die Clients brauchen diesen nur, um den Katalog zum Scannen zu verwenden. Die eigentlichen Patches werden dann von den DPs (und nicht MP wie angenommen) heruntergeladen.
    Zum Thema "cross forest" ist dieser Artikel sehr empfehlenswert: http://technet.microsoft.com/en-us/library/gg712701.aspx#Plan_Com_X_Forest

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

    Montag, 11. Juni 2012 10:47
  • Hallo Torsten,

    erstmal vielen Dank fuer die schnelle Antwort.

    Die CAS ist in der Testumgebung deshalb installiert (und fuer spater vorgesehen) weil ich mir die Skalierbarkeit sichern will. Wenn aus welchen Gruenden auch immer mal eine 2. Primary Site notwendig sein sollte kann ich ausbauen. Zusaetzlich meine ich im Technet Technet gelesen zu haben, dass ein Recovery einer 2012er Umgebung erschwert / nicht moeglich ist wenn nur eine Integrierte (Primary + CAS) existiert. Da auf der CAS und den Primaries offenbar immer die selben Daten gespeichert sind, zieht die "Recover Site" Funktion im Setup Wizard beim wiederherstellen einer CAS die noch existierende Primary hinzu, bzw. beim wiederherstellen einer Primary Site die Daten der noch existierenden CAS um sicherzustellen dass die DB konsistent ist. Und den Weg wollte ich mir nicht verbauen.

    Das mit dem sender-enabled DP werde ich berherzigen und in der Testumgebung nochmal so nachstellen. Klingt sehr vernuenftig und speckt die Umgebung etwas ab.

    Den Cross Forest Artikel habe ich schon mehrmals durch und in der Konstellation wie unser Netzwerk aussieht bleibt mir eigentlich nur ein einfaches Site System fuer die DMZ uebrig wenn ich das alles richtig verstanden habe. Eine Secondary braucht einen 2-way trust zwischen beiden Forests (ist bei uns nur 1-way). In der DMZ befinden sich ausschliesslich Systeme die Mitglied des Forest sind der in der DMZ laeuft. Ich hatte nur den Wunsch alle Systeme von einer CAS / einem Primary aus verwalten zu koennen. Aber der SUP scheint mir da einen Strich durch die Rechnung zu machen, es sei denn ich mache das Site System in der DMZ zum SUP fuer die gesamte Umgebung. Aber das wollte ich vermeiden, da dieses Netzwerksegment unguenstig an den Rest des Netzwerkes angebunden ist. So wie ich das sehe muesste ich u.U. in der DMZ eine eigenstaendige ConfigMgr Umgebung hinstellen (was nicht in Frage kommt) oder die Rechner in der DMZ wie internet basierte Clients verwalten, was vermutlich wieder recht viel Aufwand bedeutet.

    Oder habe ich da noch etwas uebersehen?

    Montag, 11. Juni 2012 11:17
  • Secondary scheidet wegen dem two way trust aus, richtig. Eine Site kann aber 2 SUPs haben: einen http und einen https: http://technet.microsoft.com/en-us/library/gg712696.aspx#BKMK_InternetSUP. Somit können zB MP, DP und SUP (jwls https) in die DMZ. Siehe nochmals http://technet.microsoft.com/en-us/library/gg712701.aspx#Plan_Com_X_Forest ;-): "Communication in a site that spans forests: Does not require a two-way forest trust: To support clients primary sites support the installation of each site system role on computers in other forests. Note: Two exceptions are the out of band service point and the Application Catalog web service point. Each must be installed in the same forest as the site server."
    CAS ja oder nein ist mehr oder weniger eine Glaubensfrage (bzw hängt letztendlich vom Budget ab). Nötig ist sie in den meisten Fällen nicht. Beim Disaster-Recovery hat man minimale Vorteile. Eine standalone Primary lässt sich aber natürlich trotzdem wiederherstellen.

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

    Montag, 11. Juni 2012 12:08
  • Diesen 2. SUP muss ich mir fuer die Clients aufsparen die spaeter uebers Internet reinkommen. Dafuer werde ich ein Site System in die DMZ stellen (es gibt hier 2 getrennte DMZ Umgebungen die auch nicht direkt miteinander sprechen koennen) welche die 2. moegliche SUP Rolle in einer Site zugewiesen bekommt.

    Fuer andere Mitleser:
    Sobald man einen 2. SUP in einer Site bereitstellt gibt´s in den "Software Update Point Component Properties" der Primary Site ein 2. Tab. Hier kann man einen dedizierten SUP fuer "Internet" basierte Clients auswaehlen. Im General Tab kann man dann einen anderen fuer die "Intranet" basierten Clients auswaehlen. Beide gehen sowohl mit HTTP als auch mit HTTPS. Das ist natuerlich sehr komfortabel.

    Allerdings hilft mir das in meiner Netzwerkkonstellation nicht. Ich bin jetzt an dem Punkt an dem ich der Meinung bin, dass ich um die Rechner in der 2. DMZ managen zu koennen entweder einen Two-way Trust brauche oder versuchen muss die Rechner in dieser 2. DMZ wie internet basierte Clients zu verwalten.

    Traumhaft waere natuerlich wenn in irgend einem spaeteren Release mal die Moeglichkeit geschaffen wird die Clients gleich mit einem SUP auf einem lokalen Site System sprechen zu lassen, aehnlich wie es mit dem DP ja auch zu funktionieren scheint ;-)

    Was jetzt weniger Schmerz ist muss ich noch ausknobeln. Vielen Dank auf jeden Fall fuer deine prompte Rueckmeldungen.

    Viele Gruesse,

    René Büdinger

    Montag, 11. Juni 2012 12:19
  • Update / Nachtrag / Korrektur: secondary Sites bringen bei IBCM-Szenarien gar nichts: "There is no support for internet based clients using secondary sites in 2012. You cannot install any internet facing roles (MP or DP) off of a secondary site as well."

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

    Mittwoch, 20. Juni 2012 17:08
  • Danke fuer den Nachtrag. Inzwischen glaube ich eine akzeptable Loesung gefunden zu haben. Voraussichtlich werden wir die DMZ1 und DMZ2 miteinander sprechen lassen koennen.

    In diesem Fall werde ich den SUP ganz einfach in die DMZ packen wo sowieso ein Site System fuer´s Internet geplant war. Dort ist er von ueberall erreichbar (LAN, DMZ, Internet). Da auf dem SUP offenbar keinerlei interne Daten liegen, sondern mehr oder weniger nur der Update Katalog (ohne Content), habe ich keine Bauchschmerzen damit ihn auch von internen Systemen nutzen zu lassen. Ich muss unsere Testumgebung dahingehend noch umbauen um Gewissheit zu haben. Aber das erscheint mir derzeit die einzige und beste Moeglichkeit um alle Fliegen mit einer Klappe schlagen zu koennen.

    Damit waere auch das Ziel erreicht mit einer Primary Site inkl. verteilter Site Systeme an div. Standorten und Netzwerksegmenten alle Systeme zu verwalten. Egal in welchem Netz (Internet, DMZ1/2, LAN) sie sich befinden.

    Donnerstag, 21. Juni 2012 05:52