Benutzer mit den meisten Antworten
Welcher DP liefert die install.wim während des OSD

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
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- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 27. Juni 2016 08:47
Alle Antworten
-
Solltest Du in der smsts.log sehen können.
- Als Antwort vorgeschlagen Evgenij Smirnov Dienstag, 14. Juni 2016 20:31
-
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
- Bearbeitet Simon Dettling Mittwoch, 15. Juni 2016 08:04
-
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
-
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
- Bearbeitet Simon Dettling Donnerstag, 16. Juni 2016 06:13
-
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
-
- Bearbeitet Andre Picker [clientmgmt.de] Mittwoch, 15. Juni 2016 14:52
-
Aber wahrscheinlich verliere ich dann die jetzige Zuordnung zu den Applikation.
Torsten Meringer | http://www.mssccmfaq.de
-
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 -
- 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
-
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
-
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- Als Antwort markiert Mihaela ParedesMicrosoft contingent staff, Moderator Montag, 27. Juni 2016 08:47