none
sccm 1702 - 'Internal Server Error' in lokaler DataTransferService.Log RRS feed

  • Allgemeine Diskussion

  • Hallo zusammen,

    auf allen überprüften Clients eines AD-Standortes, die sich Updates und Anwendungen von einem standortlokalen Verteilungspunkt (DP) holen sollen, können wir in der lokalen DataTransferService.Log folgende Einträge für jeden Job finden:

    - Successfully queued event on HTTP/HTTPS failure for server 'FQDN_Servername'.
    - Error sending DAV request. HTTP code 500, status 'Internal Server Error'
    - GetDirectoryList_HTTP('http://FQDN_Servername:80/SMS_DP_SMSPKG$/38481281-1cdf-4fd2-a855-86fa9f82b5a4') failed with code 0x800705b4.
    - Download timeout has met. DTS job {FBCC5052-7BA9-424B-A097-229CC06F7884} will quit.

    Der DP ist ein StandortsystemServer und kein sekundärer Standortserver.

    In einem Beitrag aus einem anderen Forum haben wir einen Hinweis auf eine falsche Konfig innerhalb des IIS auf dem betreffenden Server gefunden: http://venusingireddy.blogspot.de/2013/07/error-sending-dav-request-http-code-500.html

    Leider ist der physical path für die SCCMContentLib innerhalb des IIS richtig gesetzt.

    Hat jemand eine Lösung dazu?

    Alle bisherigen "Empfehlungen" gehen in die Richtung, der Verteilungspunkt neu aufzusetzen, was ich UNBEDINGT vermeiden möchte, da es kein Spaß ist, ca. 200 GB an Daten über eine 5 MBit/s WAN Verbindung zu jagen. Von den Beeinträchtigungen der User wollen wir hier gar nicht sprechen...

    Vielen Dank für jeden Beitrag zu dem Thema...


    Mit freundlichem Gruss - Harald Haas - MCSE: Cloud Platform and Infrastructure — Certified 2016; MCSA Windows Server 2016



    Donnerstag, 20. April 2017 10:48

Alle Antworten

  • 0x800705b4 = Dieser Vorgang wurde wegen Zeitüberschreitung zurückgegeben.

    Steht denn zu diesem Zeitpunkt etwas brauchbares in den IIS-Logs auf dem DP?

    Mittels Prestaged Content files könnte man sich das erneute Verteilen ersparen, sollte er wirklich neu aufgesetzt werden müssen. Wobei ich das aber erst tun würde, wenn alles weitere gar nicht mehr hilft.


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

    Donnerstag, 20. April 2017 11:43
    Beantworter
  • Hallo,

    ganz häufig könne in den Logs des IIS die folgenden Beispiel-Einträge gefunden werden:

    "IP des DP" CCM_POST /ccm_system_windowsauth/request - 80 Domainname\USERNAME "IP des anfragenden Gerätes" ccmhttp - 500 0 64 0 549

    Trotzdem können auch vermeintlich erfolgreiche Meldungen in den Logs gefunden werden:

    "IP des DP" CCM_POST /ccm_system_windowsauth/request - 80 - "IP des anfragenden Gerätes" ccmhttp - 401 2 5 1560 0

    Der Aufruf der entsprechenden http-Site http://FQDN-DP-Server/SMS_DP_SMSPKG$/
    weist noch auf folgenden Ursachen hin:

    HTTP-Fehler 500.19 - Internal Server Error

    Auf die angeforderte Seite kann nicht zugegriffen werden, da die zugehörigen Konfigurationsdaten für die Seite ungültig sind.

    <fieldset>

    Wahrscheinlichste Ursachen:

    • Der Arbeitsprozess kann die Datei "applicationhost.config" oder "web.config" nicht lesen.
    • Die Datei "applicationhost.config" oder "web.config" enthält falsch formatierten XML-Code.
    • Der Server kann aufgrund falscher NTFS-Berechtigungen nicht auf die Datei "applicationhost.config" oder "web.config" zugreifen.
    </fieldset>

    Weiter heißt es für die mögliche Vorgehensweise:

    In den Ereignisprotokollen finden Sie weitere Informationen darüber, warum die Konfigurationsdateien nicht gelesen werden können.

    Stellen Sie sicher, dass die für den Anwendungspool angegebene Benutzeridentität oder der authentifizierte Benutzer über die erforderlichen Berechtigungen für den Zugriff auf die Datei "web.config" verfügt.

    Da wir noch einen weiteren DP im Einsatz haben,d er augenscheinlich fehlerfrei läuft, habe ich mir die Konfig im IIS einmal genauer angeschaut und eigentlich nur folgenden Unterschied festgestellt:

    In den Grundeinstellungen der Default Web Site / SMS_DP_SMSSIG$ war bei dem fehlerhaften DP ein UNC Pfad im Feld "Physikalischer Pfad" eingetragen (FQDN-DP-Server\SMSSIG$) und bei dem funktionierenden Server ein lokaler Pfad zum Verzeichnis D:\SMSSIG$.

    Da der DP ja komplett automatisch durch Standortserver eingerichtet wird, haben wir hier weder auf dem einen noch auf dem anderen (funktionierenden) DP manuell Veränderungen vorgenommen.

    Könnte dieser Unterschied ursächlich sein?

    Die Sicherheitseinstellungen bzw. Berechtigungen der im Anwendungspool für diese Site angegebene Benutzeridentität hat Zugriff auf die web.config - die Einstellungen sind auf beiden geprüften DPs identisch.

    Und was ich noch nicht verstehe, ist, dass es auf dem fehlerbehafteten DP eine Site "WSUS-Verwaltung" gibt und auf dem fehlerfreien DP eben nicht!

    Beide Server waren frisch aufgesetzte Systeme, somit ist es ausgeschlossen, dass irgendwer da mal einen WSUS installiert hat...

    Falls dieser Unterschied (Physikalischer Pfad) nicht die Ursache sein sollte, hast du eine Idee, woran es noch liegen könnte?


    Mit freundlichem Gruss - Harald Haas - MCSE: Cloud Platform and Infrastructure — Certified 2016; MCSA Windows Server 2016




    • Bearbeitet H.Haas Donnerstag, 27. April 2017 05:26
    Donnerstag, 27. April 2017 05:18