3
SCCM current branch 1706 Installationspakete werden nicht heruntergeladen 0 Prozent Downloading
Hi,
für ein paar simple Tests mit einer Softtware, die wir supporten müßten wir mal einen SCCM aufsetzen.
Ich hab mir das aktuellste Teil von Microsoft heruntergeladen (1702), alle Serverrollen und Features auf Windows 2012 R2 richtig konfiguriert, einen SQL Server 2014 dazu installiert und zuguterletzt das SCCM Setup mit "eine typische alleinstehende Site" installiert. Nach der Überwindung kleinerer Hürden (die GUI ist etwas buggy) war ich in der Lage, das 7zip als Paket bereitzustellen.
Ich hab dann einen Client (Windows 10 1511, auf neueren stürzt der SCCM Client bei der Installation ab) in die Domäne integriert und den Client durchinstalliert.
Mein Paket wird auch gefunden, aber nicht heruntergeladen. Auch nciht, nachdem ich den SCCM mit dem integrierten Updater auf 1706 und dann noch ein Update für den 1706 Stand gebracht hab.
Am Server mußte ich ein wenig über Trial&Error herausfinden, wie man ein Paket korrekt erstellt.
Das hab ich am Ende auch geschafft, mein 7zip Silent Paket wird am Client gelistet, klickt man es an, dann steht da für immer "0% downloading"
Auf dem Client ist eine Datei mit dem Namen cas.log, in der ist aber auch nur dieses Lebenszeichen eines gestarteten Downloadversuchs sichtbar:
<![LOG[Download started for content AGO0000D.1]LOG]!><time="17:15:22.772-60" date="11-14-2017" component="ContentAccess" context="" type="1" thread="4476" file="downloadmanager.cpp:1016">
<![LOG[Location update from CTM for content AGO0000D.1 and request {76A6C34F-1D22-4E09-A239-29484FFD02D5}]LOG]!><time="17:15:22.864-60" date="11-14-2017" component="ContentAccess" context="" type="1" thread="4988" file="downloadcontentrequest.cpp:982">
<![LOG[ Matching DP location found 0 - http://sccm3.bringit.local/sms_dp_smspkg$/ago0000d (Locality: SUBNET)]LOG]!><time="17:15:22.866-60" date="11-14-2017" component="ContentAccess" context="" type="1" thread="4988" file="downloadcontentrequest.cpp:1020">
Vermutlich hab ich irgendeinen eher trivialen Konfigurationsschritt übersehen, der den Download blockiert...
Die gängigen Ursachen hab ich alle schon abgegrast... da die Site mit HTTP funktioniert und der Download offenbar auch mal mit HTTP versucht wurde zu starten, liegt es nicht an SSL Zertifikaten, auch ist das 7zip (mein Beispiel) im Windows bekannt, provoziert also nicht die berüchtigte Dialogbox "diese Applikation stammt aus einer unbekannten Quelle", es läuft alles unter dem Domänenadministrator... auch die Boundary groups sind das nicht. Der Client findet ja den "distribution point", also die STelle von der man das Paket herunterladen müßte.
für ein paar simple Tests mit einer Softtware, die wir supporten müßten wir mal einen SCCM aufsetzen.
Ich hab mir das aktuellste Teil von Microsoft heruntergeladen (1702), alle Serverrollen und Features auf Windows 2012 R2 richtig konfiguriert, einen SQL Server 2014 dazu installiert und zuguterletzt das SCCM Setup mit "eine typische alleinstehende Site" installiert. Nach der Überwindung kleinerer Hürden (die GUI ist etwas buggy) war ich in der Lage, das 7zip als Paket bereitzustellen.
Ich hab dann einen Client (Windows 10 1511, auf neueren stürzt der SCCM Client bei der Installation ab) in die Domäne integriert und den Client durchinstalliert.
Mein Paket wird auch gefunden, aber nicht heruntergeladen. Auch nciht, nachdem ich den SCCM mit dem integrierten Updater auf 1706 und dann noch ein Update für den 1706 Stand gebracht hab.
Am Server mußte ich ein wenig über Trial&Error herausfinden, wie man ein Paket korrekt erstellt.
Das hab ich am Ende auch geschafft, mein 7zip Silent Paket wird am Client gelistet, klickt man es an, dann steht da für immer "0% downloading"
Auf dem Client ist eine Datei mit dem Namen cas.log, in der ist aber auch nur dieses Lebenszeichen eines gestarteten Downloadversuchs sichtbar:
<![LOG[Download started for content AGO0000D.1]LOG]!><time="17:15:22.772-60" date="11-14-2017" component="ContentAccess" context="" type="1" thread="4476" file="downloadmanager.cpp:1016">
<![LOG[Location update from CTM for content AGO0000D.1 and request {76A6C34F-1D22-4E09-A239-29484FFD02D5}]LOG]!><time="17:15:22.864-60" date="11-14-2017" component="ContentAccess" context="" type="1" thread="4988" file="downloadcontentrequest.cpp:982">
<![LOG[ Matching DP location found 0 - http://sccm3.bringit.local/sms_dp_smspkg$/ago0000d (Locality: SUBNET)]LOG]!><time="17:15:22.866-60" date="11-14-2017" component="ContentAccess" context="" type="1" thread="4988" file="downloadcontentrequest.cpp:1020">
Vermutlich hab ich irgendeinen eher trivialen Konfigurationsschritt übersehen, der den Download blockiert...
Die gängigen Ursachen hab ich alle schon abgegrast... da die Site mit HTTP funktioniert und der Download offenbar auch mal mit HTTP versucht wurde zu starten, liegt es nicht an SSL Zertifikaten, auch ist das 7zip (mein Beispiel) im Windows bekannt, provoziert also nicht die berüchtigte Dialogbox "diese Applikation stammt aus einer unbekannten Quelle", es läuft alles unter dem Domänenadministrator... auch die Boundary groups sind das nicht. Der Client findet ja den "distribution point", also die STelle von der man das Paket herunterladen müßte.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 354818
Url: https://administrator.de/contentid/354818
Printed on: April 24, 2024 at 12:04 o'clock
3 Comments
Latest comment
Hi,
Hast du den deine Anwendung auf dem Verteilungspunkt verteilt ?
Wie ist den der Contenstatus von 7zip?
Hast du den deine Anwendung auf dem Verteilungspunkt verteilt ?
Wie ist den der Contenstatus von 7zip?
der Workflow ist:
- neues Package erstellt (mit dem 7zip, source from local drive, installs with UNC, download and run locally, installs whether user is logged in / not, administrative account)
- "distribute content" ausgeführt, der Status der Distribution ist ok (success) und das Paket wird auch in dem Share vom SCCM abgelegt
- "deploy" ausgeführt, Status des Deployments ist nach ca. 15 Minuten dann "ok", mit der Option "as soon as possible"
Insofern die effektive Uhrzeit von Server und Client übereinstimmt, erscheint dann maximal eine Stunde später im "Software Center" mein 7zip Paket und irgendwo in den Logs vergraben taucht auch eine URL zu meinem Distribution point auf... das bedeuet daß z.B. die Boudaries richtig eingestellt waren.
Lessons learned:
- ein Paket 2x oder mehrfach zu deployen killt den BITS auf dem Client. Zuguterletzt hab ich die VM gelöscht und eine neue gemacht und pro Versuch ein neues Paket gemacht.
- as soon as possible wird vom Client als "ab Datum + Uhrzeit der Erstellung" interpretiert. Ist der Client in einer USA Zeitzone und der Server in UTC dann wird das Paket erst 8 Stunden später angezeigt.
- und nichts passiert sofort, das SCCM hat keinen Testmodus wo man auf einen Knopf drückt und am Client passiert dann direkt was.
- Firewall sollte man per Machine GPO für das Discovery öffnen, ansonsten funktionoiert nur das AD forest discovery für Computerkonten, und auch da nur wenn man eine spezielle OU anlegt und dort Computerkonten hineinschiebt damit man z.B. ein Push install für die SCCM Clientsoftware durchzuführen
- neues Package erstellt (mit dem 7zip, source from local drive, installs with UNC, download and run locally, installs whether user is logged in / not, administrative account)
- "distribute content" ausgeführt, der Status der Distribution ist ok (success) und das Paket wird auch in dem Share vom SCCM abgelegt
- "deploy" ausgeführt, Status des Deployments ist nach ca. 15 Minuten dann "ok", mit der Option "as soon as possible"
Insofern die effektive Uhrzeit von Server und Client übereinstimmt, erscheint dann maximal eine Stunde später im "Software Center" mein 7zip Paket und irgendwo in den Logs vergraben taucht auch eine URL zu meinem Distribution point auf... das bedeuet daß z.B. die Boudaries richtig eingestellt waren.
Lessons learned:
- ein Paket 2x oder mehrfach zu deployen killt den BITS auf dem Client. Zuguterletzt hab ich die VM gelöscht und eine neue gemacht und pro Versuch ein neues Paket gemacht.
- as soon as possible wird vom Client als "ab Datum + Uhrzeit der Erstellung" interpretiert. Ist der Client in einer USA Zeitzone und der Server in UTC dann wird das Paket erst 8 Stunden später angezeigt.
- und nichts passiert sofort, das SCCM hat keinen Testmodus wo man auf einen Knopf drückt und am Client passiert dann direkt was.
- Firewall sollte man per Machine GPO für das Discovery öffnen, ansonsten funktionoiert nur das AD forest discovery für Computerkonten, und auch da nur wenn man eine spezielle OU anlegt und dort Computerkonten hineinschiebt damit man z.B. ein Push install für die SCCM Clientsoftware durchzuführen
es mangelte an den Grundlagen 
Wer nen SCCM installiert brauchte rstmal eine "Central Administration Site" die ich nicht hatte.
Wer nen SCCM installiert brauchte rstmal eine "Central Administration Site" die ich nicht hatte.
