none
SCCM and SMS parallel IP Boundaries RRS feed

  • Allgemeine Diskussion

  • Hi,

    we're just migrating from SMS 2003 to SCCM 2007. At the moment we have both installed with different Site Codes, but automatic Site Discovery at the sccm clients is not working. Could this be the Problem why i get no software advertisements at the client? Can I configure the Client manual ?

    Mittwoch, 10. August 2011 13:58

Alle Antworten

  • Sieht nach überlappenden Boundaries aus => automatisches Site-Discovery funktioniert nicht bzw falsch. Zusätzlich werden ggfs auch Content Location Requests fehlschlagen. Lösung: überlappende Boundaries vermeiden!
    P.S. das hier ist das dt System Center Forum, Dein Name klingt relativ deutsch => Du kannst auch gerne in deutsch posten ;-)
    Torsten Meringer | http://www.mssccmfaq.de
    Mittwoch, 10. August 2011 15:11
    Beantworter
  • Hi Torsten,

    Stimmt, deutsch ist natürlich einfacher.

    Also mit den Boundaries das lässt sich im Moment schwer vermeiden, ich kann mich aber erinnern dass wir einige solche Migrationsszenarien hatten und es funktioniert hat. Wir arbeiten mit IP Boundaries aber wir geben bei der Installation des SCCM Clients die benötigten Infos mit:

    SMSMP=ND-SCCM SMSSLP=ND-SCCM FSP=ND-SCCM

    Damit sollte er doch eigentlich den Management Point und Server Locator Point finden können, ohne im AD oder sonstwo zu suchen?!


    Mittwoch, 10. August 2011 16:34
  • Du gibst aber keinen Sitecode an (wieso eigentlich nicht), deshalb fragt der Client Richtung AD: ich hab die IP bla.bla.bla.bla, zu welcher SMS/SCCM gehört ich denn nun? Hier kann es wegen der überlappenden Boundaries passieren, dass als Antwort "SMS-Site" (anstatt "SCCM-Site" kommt). Ein SCCM-Client kann aber keiner SMS-Site assigned werden, deshalb geht das Assignment nicht.
    Ein weiteres Thema - neben dem Site Assignment - sind die "content location requests", d.h. Frage an dem MP, auf welchen DPs Packages zu finden sind. Auch hier kann es bei überlappenden Boundaries zu Problemen kommen.


    Torsten Meringer | http://www.mssccmfaq.de
    Mittwoch, 10. August 2011 16:55
    Beantworter
  • Hallo Torsten,

    ich muss ganz ehrlich sagen, dass die Parameter ein Kollege von mir eingestellt hat. Und du hast vollkommend Recht, ich habe eben nochmal die kompletten Parameter nachgeschaut, und hier ist die komplette Zeile:

    SMSCACHESIZE=50 SMSCACHEFLAGS=PERCENTFREEDISKSPACE SMSMP=ND-SCCM SMSSLP=ND-SCCM FSP=ND-SCCM PATCH=%_SMSTSMDataPath%\OSD\ND10000A\i386\Hotfix\KB977384\sccm2007ac-sp2-kb977384-x86-deu.msp;%_SMSTSMDataPath%\OSD\ND10000A\i386\Hotfix\KB2509007\sccm2007ac-sp2-kb2509007-x86-deu.msp

    Und tatsächlich steht der SiteCode nicht mit drin. Das werde ich morgen auf jeden Fall nochmal checken. Muss, wenn ich keine Automatische KOnfiguration verwende, schon eine Schemaerweiterung für SCCM des AD-Schemas gemacht werden, damit die Softwareverteilung funktioniert, oder reichts es dafür aus, dem Client die benötigten Infos mitzugeben?

    Vielleicht kannst du mir noch sagen, ob die Syntax bei den Parametern korrekt ist, um die Hälfte des freien Speicherplatzes der lokalen Platte auf dem Client als SMSCACHE zu verwenden:

    SMSCACHESIZE=50 SMSCACHEFLAGS=PERCENTFREEDISKSPACE

    Danke schonmal für die schnelle und professionelle Unterstützung!

    Mittwoch, 10. August 2011 18:57
  • Schema-Erweiterung ist nicht nötig. In diesem Fall muss dann aber ein SLP vorhanden sein (und danach sieht's ja auch laut der command line aus).
    Die Cache-Parameter sehen gut aus.
    Torsten Meringer | http://www.mssccmfaq.de
    Donnerstag, 11. August 2011 07:01
    Beantworter
  • Hi Torsten,

    wir haben das Problem mit den Advertisements lösen können, indem wir IPv6 auf dem Server deaktiviert haben. Nur gibt es ein weiteres Problem: Der Chef möchte aus mir bisher nicht nachvollziehbaren Gründen nicht, dass IPv6 deaktiviert wird. Gibt es eine Möglichkeit das sinnvoll mit aktiviertem IPv6 zu betreiben?

    Wegen des Cache-Parameters: Geb ich das bei einer manuellen Client-Installation mit, gehts, in der Tasksequence greift der Parameter nicht.

    Donnerstag, 11. August 2011 09:06
  • Mir ist nicht bekannt, dass IPv6 Probleme an dieser Stelle bereitet. Hier muss untersucht werden, wieso das nicht funktioniert. So völlig aus dem Stegreif habe ich keine Idee.
    Wegen den Parametern: was steht dann im ccmsetup.log auf dem Client? Und in welcher Cache-Size resultiert dies?


    Torsten Meringer | http://www.mssccmfaq.de
    Donnerstag, 11. August 2011 09:16
    Beantworter
  • Das mit IPv6 wird aber im Deployment Guide so beschrieben:

    http://blogs.technet.com/b/deploymentguys/archive/2008/08/07/how-to-setup-configmgr-2007-on-windows-server-2008.aspx

    Das mit den Parametern muss ich mal genauer checken. Danke schonmal für alles.

    Donnerstag, 11. August 2011 09:24
  • Die Aussage kann ich nicht nachvollziehen. ConfigMgr unterstützt IPv6, siehe http://technet.microsoft.com/en-us/library/bb680807.aspx: "Configuration Manager 2007 also includes support for fully qualified domain names (FQDNs) and IPv6". Keine Ahnung, wieso im Blog das gegenteilige erwähnt wird. Ich kann auch aus der Praxis berichten, dass IPv6 keine Probleme bereitet.


    Torsten Meringer | http://www.mssccmfaq.de
    Donnerstag, 11. August 2011 09:59
    Beantworter
  • Wie müssen denn die Bindings im IIS des SCCM aussehen? Ich habe festgestellt das mit aktiviertem IPv6 dort bei IP-Adressen "Keine Zugewiesen" steht. Kann es sein dass der IIS dann nur auf IPv6 Anfragen reagiert, der Client aber aufgrund von nicht Ipv6 fähiger Hardware nicht über IPv6 kommunizieren kann?
    Donnerstag, 11. August 2011 14:30
  • Sieht gut aus ... in meinem Lab steht's auf "all unassigned" und da läuft das.
    Torsten Meringer | http://www.mssccmfaq.de
    Donnerstag, 11. August 2011 15:37
    Beantworter
  • Der Blog-Artikel wird bald angepasst und das IPv6-Statement vermutlich entfernt :)
    Torsten Meringer | http://www.mssccmfaq.de
    Freitag, 12. August 2011 06:54
    Beantworter
  • Hi Torsten,

    ich hab immer noch ein paar Probleme beim Verteilen der Advertisements, unabhängig von IPv6. Ich habe es soweit anhand der Logfiles analysiert, dass ich festgestellt habe, dass der BITS Dienst die Files nicht übertragen kann, weil es die Policy angeblich verhindert. Ich habe dann die Einstellungen überprüft und festgestellt, das tatsächlich auf dem SCCM für die Client-Komponente eingestellt war, dass nur zwischen 07 und 10 Uhr mit sehr beschränkter Bandbreite Software übertragen werden darf. Habe diese Einstellung nun geändert, so dass außerhalb dieser Zeit mit voller Bandbreite übertragen werden darf. Der Client meldet wenn ich über das Bits Kommandozeilen tool mir die Daten des Jobs anzeigen lasse, dass die Gruppenrichtlinien die Ausführung verhindern:


    Was muss ich tun dass die geänderten Einstellungen greifen bzw. was könnte noch das Problem sein?

    Viele Grüße

    Daniel

    Dienstag, 16. August 2011 10:01
  • Wurden denn die BITS-GPOs geändert? Wurden die GPO erfolgreich am Client angewandt (HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\BITS)? Hast Du nach Änderung den BITS-Dienst neu gestartet?


    Torsten Meringer | http://www.mssccmfaq.de
    Dienstag, 16. August 2011 10:32
    Beantworter
  • Der Registry Key wurde nicht angepasst, scheinbar wurde die Policy nicht geändert. Wie heißt die Policy die vom SCCM erzeugt wird? Ist das eine normale Gruppenrichtlinie die über die Gruppenrichtlinienverwaltung einsehbar ist?

    BITS Dienste hab ich durchgestartet, sowohl am client als auch am Server.

    Dienstag, 16. August 2011 10:36
  • Sollte man per RSOP als 'local policy' sehen.
    BITS-Dienst am Server ist hier gar nicht beteiligt.
    Torsten Meringer | http://www.mssccmfaq.de
    Dienstag, 16. August 2011 11:53
    Beantworter
  • Ja, hab ich gefunden. Habs mal manuell in der lokal Policy geändert. Jetzt sind die BITS jobs mit dem besagten Policy Fehler durch. Einige wenige Jobs schlagen aber noch fehl, weil angeblich ein Pfad nicht gefunden wird. Ein Pfad ist zum Beispiel:

    http://ND-SCCM.XXXXX.XX:80/SMS_MP/.sms_pol?{a3b2b306-f8e6-4645-82eb-abd6c91046ba}.5_00 -> C:\Windows\system32\CCM\Temp\{1F3ACD34-DD6D-476E-A131-7F0E997F31C5}.tmp

    ERROR CODE:    0x80190194 - HTTP-Status 404: Die angeforderte URL ist auf diesem Server nicht vorhanden.
    ERROR CONTEXT: 0x00000005 - Fehler beim Verarbeiten der Remotedatei.

    Langsam krieg ich echt die Krise hier ;-)

    Dienstag, 16. August 2011 11:55
  • Der BITS-Job gehört zu einer Policy. Kann sein, dass mittlerweile eine höhere Version (als 5.00) verfügbar ist und der Client dies noch nicht mitbekommen hat (machine policy retrievel & eval cycle). Muss also nicht unbeding ein Problem sein. Ist so aus dem Kontext gerissen schwer zu beurteilen. Ggfs mal auf einem anderen Client mit PolicySpy/ClientSpy (ConfigMgr Toolkit V2), wie's dort aussieht.
    Torsten Meringer | http://www.mssccmfaq.de
    Dienstag, 16. August 2011 12:46
    Beantworter
  • Zur Info: Mittlerweile läuft alles, es war definitiv kein IPv6 Probleme sondern nur ein Fehler in der Konfiguration der BITS-Bandbreitenbeschränkung. Auch parallele IP-Boundaries sind kein Problem, sofern man den Management Point und SLP bei der Client-Installation mitgibt.

    Thread kann geschlossen werden, danke Torsten für die tolle Unterstützung.

    Montag, 22. August 2011 14:00