none
Welcher DP liefert die install.wim während des OSD RRS feed

  • Frage

  • Hallo,

    Ich hätte gerne gewusst, ob man während des OSD in einem Log erkennen, von welchem DP sich unsere
    neue Maschine die install.wim zieht, da mir der Download sehr langsam vorkommt obwohl der DP relativ
    'nah' am betroffenen Client steht.

    Ich vermute daher, dass ein andere DP hier als Server agiert, obwohl er weiter 'entfernt' steht und auch
    in den Eigenschaften der Boundary Group unter "References" die Connection "Slow" bekommen hat.

    Der, der 'näher' steht, wurde mit "Fast" festgelegt.

    VG

    Daniel Schindler

    Dienstag, 14. Juni 2016 14:26

Antworten

  • Moin,

    so Ursache ist gefunden, auch ohne Microsoft.

    Unter \Administration\Overview\Distribution Points, den betreffenden DP ausgewählt und
    die Eigenschaften betrachtet. Na siehe da, im Register Boundary Groups war der RDP nicht eingetragen :-(
    Da fehlte die Zuordnung.

    In den Eigenschaften des DP waren natürlich beide (DP+RDP) eingetragen.
    Den RDP habe ich da rausgenommen und siehe da, der Download war sichtlich schneller und im smstask.log
    tauchte auch der RDP als Quelle auf!

    Danke für Eure tatkräftige Unterstützung.

    VG
    Daniel

    Freitag, 17. Juni 2016 11:29

Alle Antworten

  • Solltest Du in der smsts.log sehen können.

    http://www.clientmgmt.de

    Dienstag, 14. Juni 2016 20:15
  • smsts.log wie von André erwähnt unter X:\Windows\temp\SMSTSLog\smsts.log analysieren.

    Dieses Log während dem Download mit CMTrace öffnen. Einer der letzten Einträge müsste sein:

    List of files to be downloaded
    File: http://DP001.domain.tld:80/SMS_DP_SMSPKG$/SMS00001/sccm?/DeinImage.wim


    Simon Dettling | msitproblog.com | @SimonDettling

    Mittwoch, 15. Juni 2016 05:43
  • Hallo zusammen,

    danke für den Tipp.

    In der Tat lädt der Client die install.wim Datei vom DP aus unserem RZ und nicht vom RDP, der sich am
    gleichen Standort befindet, wie der Client selbst.

    Da muss ich dann mal eruieren, warum nicht. Habe ich eine Einstellung vergessen?

    VG

    Daniel Schindler

    Mittwoch, 15. Juni 2016 10:25
  • Wie sieht den die Konfiguration der Boundary (Groups) aus? Ist der Client in der Boundary Group, in welcher die Zuordnungen (Slow / Fast) vorgenommen werden?

    Simon Dettling | msitproblog.com | @SimonDettling


    Mittwoch, 15. Juni 2016 11:54
  • Hallo SImon,

    ja ich befürchte ich habe eine Fehlkonfiguration in den Boundary Groups.

    Irgendwie ist die Boundary "Default-First-Site-Name" in die BG gekommen, die auch die
    Subnetze aus dem RZ beinhaltet.

    Schaue ich mir mal gerade in Ruhe an. Eventuell muss ich die BG Zuordnung ändern. Aber
    wahrscheinlich verliere ich dann die jetzige Zuordnung zu den Applikation.

    VG

    Daniel

    Mittwoch, 15. Juni 2016 13:31
  • Halt uns auf dem Laufenden! 

    http://www.clientmgmt.de


    Mittwoch, 15. Juni 2016 14:11
  • Aber wahrscheinlich verliere ich dann die jetzige Zuordnung zu den Applikation.

    Was meinst Du damit bzw wo sind deine Befürchtungen?

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

    Mittwoch, 15. Juni 2016 18:04
    Beantworter
  • Hallo Torsten,

    habe mich vertan. Alle Applikation habe ich über die eine Distribution Point an alle DP's verteilt.

    Habe noch einmal nachgeschaut und gesehen, dass der Content auf beiden DP's identisch ist.
    Hatte das irgendwie jetzt verwechselt.


    Zur Übersicht meine Boundary Konfiguration:

    Boundaries:
    - 192.168.4.1-192.168.4.254  
       -> mit Zuordnung zur site Default-First-Site-Name unter den AD Sites und Services
       -> hier liegt auch der RDP über den der Client das install.wim ziehen soll

    - 10.220.243.1-10.220.243.254 
       ->mit Zuordnung zur site Rechenzentrum unter AD Sites und Services

    - 10.161.193.1-10.161.193.254
       ->mit Zuordnung zur site Rechenzentrum unter AD Sites und Services
       ->hier liegt der SCCM Server mit der DP Rolle von dem der Client die install.wim Datei herunterlädt

    - Default-First-Site-Name (beinhaltet obiges Subnetz 192.168.4.0/24)
    - Rechenzentrum (beinhaltet obiges Subnetz 10.220.243.0/24 und 10.161.193.0/24 )

    Boundary Gruppen mit deren Zuordnung:
    Standort Office 
        ->Default-First-Site-Name

    - Standort RZ
        ->Rechenzentrum
        ->Default-First-Site-Name


    Unter Properties->References der Gruppe Standort Office stehen beide Server (DP+RDP)
    mit Einstellung Fast.

    Unter Properties->References der Gruppe Standort RZ steht der SCCM Server mit der DP Rolle
    mit Einstellung Fast.

    Ich hoffe, das ist alles verständlich.

    Viele Grüße

    Daniel

    Donnerstag, 16. Juni 2016 09:39

  • - Default-First-Site-Name (beinhaltet obiges Subnetz 192.168.4.0/24)
    - Rechenzentrum (beinhaltet obiges Subnetz 10.220.243.0/24 und 10.161.193.0/24 )

    Boundary Gruppen mit deren Zuordnung:
    Standort Office 
        ->Default-First-Site-Name

    - Standort RZ
        ->Rechenzentrum
        ->Default-First-Site-Name


    Unter Properties->References der Gruppe Standort Office stehen beide Server (DP+RDP)
    mit Einstellung Fast. --> entsprechend haben Clients die freie Wahl, einen der beiden DPs zu verwenden. Also standortübergreifend.

    Unter Properties->References der Gruppe Standort RZ steht der SCCM Server mit der DP Rolle
    mit Einstellung Fast. --> nachdem hier Default-First-Site-Name ebenfalls Mitglied ist, kann wieder ein standortübergreifender Download erfolgen.

    Macht das Sinn? Siehe im Zitat (-->).

    Ich würde jwls eine Boundary Group für Office und RZ erstellen. Der BG für RZ dann AD-Site Rechenzentrum zuordnen und den DP vom Siteserver. Der BG Office dann die Boundary default-first-site-name und den DP, der dort steht.


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

    Donnerstag, 16. Juni 2016 09:58
    Beantworter
  • Hi Torsten,

    sehe ich genauso. Hat leider nicht funktioniert. Ich werde die BG noch einmal neu erstellen, Server neu starten
    und schauen, ob sich der Client vom RDP (BG Office) die install.wim zieht.

    Wenn nicht, mach ich ein case bei MS auf.

    Halte Euch auf dem Laufenden.

    VG

    Daniel

    Freitag, 17. Juni 2016 08:23
  • Moin,

    so Ursache ist gefunden, auch ohne Microsoft.

    Unter \Administration\Overview\Distribution Points, den betreffenden DP ausgewählt und
    die Eigenschaften betrachtet. Na siehe da, im Register Boundary Groups war der RDP nicht eingetragen :-(
    Da fehlte die Zuordnung.

    In den Eigenschaften des DP waren natürlich beide (DP+RDP) eingetragen.
    Den RDP habe ich da rausgenommen und siehe da, der Download war sichtlich schneller und im smstask.log
    tauchte auch der RDP als Quelle auf!

    Danke für Eure tatkräftige Unterstützung.

    VG
    Daniel

    Freitag, 17. Juni 2016 11:29