Download eDoc+GS bei installation UCC 6.5.1.131 od. .145 failed: -2146697208 800c0008

  • Seid gegrüßt,


    folgende Situation:


    - Jungfreuliches Windows
    - Befindet sich hinter einer Firewall, ich meine Barracuda. Müsste bei Bedarf dies noch genauer in Erfahrung bringen.
    - Bei Installation des UCC-Client (beide o.g. Versionen getestet) schlägt der Download des eDoc und GS fehl.


    Im Client selbst erscheint "-2146697208" als Fehlergrund.
    Im Log kommt:

    Zitat

    01-16 09:32:47 CInstallAction DownloadAndInstallPrerequisite: eDocPrintPro v3.26.1 free
    01-16 09:32:47 InstallController SetCurrentJobDescription: Herunterladen von: eDocPrintPro v3.26.1 free
    01-16 09:32:47 ResourceExtractor Download: https://www.starface-cdn.de/st…DocPrintPro_v3.26.1.0.exe
    01-16 09:32:47 ResourceExtractor Download failed: 800c0008
    01-16 09:32:47 InstallController Result of eDocPrintPro v3.26.1 free: 800c0008


    Kopiert man nun den Download-Link direkt in den Browser, kann man die Datei herunterladen.


    Der Fehlercode scheint aus dem VB-Bereich zu kommen und bezieht sich wohl auf ein "Server"-Objekt.
    https://stackoverflow.com/ques…resource-has-failed-error
    https://www.vba-market.com/201…fied-resource-has-failed/


    Hat von euch jemand ähnliche Erfahrungen gemacht?


    PS: Als in der Version 6.4 nur der GS benötigt wurde, war der Download laut Kunde kein Thema.

  • Die Version 6.6 zeigt für diesen Fehlerfall zumindest eine ordentliche Fehlermeldung an.


    Funktioniert der Download sporadisch nicht oder auf manchen Maschinen nie? Kann die Datei über den o.g. Download-Link vom betroffenen PC manuell heruntergeladen werden? Gibt es hier noch weitere Randbedingungen wie Proxy-Authentisierung etc.?


    Gruß Wolfgang

  • Hallo Wolfgang,


    die Installation mit Download wurde auf mehreren PCs im Netzwerk mit dem gleichen Ergebnis getestet.
    Proxy wird laut Kunde nicht verwendet.
    Auf der gleichen Maschine kann die Datei, wir bereits erwähnt, mittels dem angegeben Link heruntergeladen werden.


    Auf die V6.6 setzt der Kunde aktuell seine Hoffnung. Falls aber der Download-Mechanismus dess UCC-Clients sich nicht verändert hat, vermute ich auf keine Besserung. Evtl. liegt dies auch an der Art und Weise, wie die verwendete Microsoft-Library die Verbindung herstellt und deswegen manche Sicherheitssysteme "hellhörig" werden.


    Grüße Daniel

  • Hallo Daniel,


    die verwendete API ist tatsächlich dieselbe, in beiden Fällen wird URLDownloadToFile verwendet. Früher wurde das Ghostscipt Setup über http von der Artifex Homepage geladen. Heute werden die 3rd Party Komponenten via https vom Starface CDN geladen. Bei Zertifikat-Problemen sollte automatisch ein entsprechender Windows-Dialog geöffnet werden, mit dem der Benutzer ggf. ein Zertifikat akzeptieren kann. Ich hatte dies zuvor mit self signed Zertifikaten getestet.


    Gruß Wolfgang

  • Danke dir für die offene Antwort.


    Somit bleibt es für mich noch fraglich, was der Download über das Setup anders machen soll, als der Test des gleichen Links im Browser.


    Mal seh'n, ob ich den Vorgang noch genauer unter die Lupe nehmen kann.

  • Hallo das Problem haben wir auch, aber bei unseren Installationen ist meist ein Proxy hinterlegt.
    Der Installer ignoriert nur aus irgend einem Grund den Systemweiten Proxy , da der Aufruf der einzelnen Links funktioniert und dann auch ein Download stattfindet.


    Ein kleiner Behelf an der Stelle ist dann die ganzen Installer über Powershell zu starten.
    mkdir c:\tmp
    cd c:\tmp
    $client = new-object System.Net.WebClient
    $client.DownloadFile("https://starface-cdn.de/starface/clients/Windows/redist/eDocPrintPro_v3.27.0.0.exe","C:\tmp\eDocPrintPro_v3.27.0.0.exe")
    $client.DownloadFile("https://starface-cdn.de/starface/clients/Windows/redist/gs921w64.exe","C:\tmp\gs921w64.exe")
    $client.DownloadFile("https://www.starface-cdn.de/starface/clients/Windows/6.6.0.x/6.6.0.192/STARFACE_UCC_Client_for_Windows_v6.6.0.192.exe","C:\tmp\ucc_client.exe")
    .\gs921w64.exe /S /quiet
    .\eDocPrintPro_v3.27.0.0.exe /exenoui /qn
    .\ucc_client.exe /i /q


    Ist zwar nicht schön aber funktioniert.

  • Das Problem sind in der Regel AV-Scanner/-Filter, die das Nachladen dieser Quellen verhindern.


    Wir haben zumeist Sophos Firewalls und Endpoint im Einsatz, aber das Problem besteht erst seit dem 6.4 UCC ca. vorher war das kein Problem und wie gesagt wenn wir das so auf der Powershell durchführen funktioniert es ja auch.
    Wieso werden die Pakete nicht einfach direkt von der Telefonanlage geladen? Dann müsste auch nicht jeder Client sie die Daten extra aus dem Internet laden. Die TK ist meist ja eh vor Ort.

  • Wir haben zumeist Sophos Firewalls und Endpoint im Einsatz, aber das Problem besteht erst seit dem 6.4 UCC ca. vorher war das kein Problem und wie gesagt wenn wir das so auf der Powershell durchführen funktioniert es ja auch.
    Wieso werden die Pakete nicht einfach direkt von der Telefonanlage geladen? Dann müsste auch nicht jeder Client sie die Daten extra aus dem Internet laden. Die TK ist meist ja eh vor Ort.


    Und was würde das ändern, wenn die Sophos den Download der Pakete verhindert? Wie sollen diese auf die TK-Anlage kommen?
    Warum nicht einfach testweise ein Whitelisting anlegen oder das UTM-AV ausschalten? Das scheint einfacher, als andere aufzufordern, etwas an der Architektur zu ändern.


    Für umfangreichere Installationen gibt es ohnehin Möglichkeiten der Softwareverteilung -- wir sprechen also höchstwahrscheinlich von einer geringen Anzahl Installationen, wodurch sich die Traffic-Ersparnis durch das Ablegen auf der STARFACE stark relativiert.
    Auf der anderen Seite würden nämlich STARFACE Updates dadurch noch viel größer, als sie jetzt schon durch die ganzen Firmwareupdates sind (was längere Ausfallzeiten nach sich zieht).

  • Das Problem ist genau das es ein Whitelisting gibt und der Manuelle Download über den vollständigen Link oder per Powershell ja funktioniert , nur nicht aus dem Starface installer heraus.
    Der Installer scheint ein Problem mit Proxies zu haben und ignoriert die Systemeinstellungen dazu. Leider kann man bei der Installation diesen auch nicht dort nochmals manuell eintragen.
    Wie schon auch geschrieben besteht das Problem ja auch erst sein ca 6.4.

  • Hast Du denn schon versucht, Sophos Endpoint auszuschalten, um festzustellen, ob es daran liegt?


    Deine Vermutung, es würde am Installer liegen ist nämlich noch völlig unbestätigt. Sophos Endpoint könnte schlicht das Nachladen durch den Installer für verdächtig halten und das manuelle Herunterladen über die Powershell nicht.
    Bislang ist also überhaupt noch nicht bestätigt, dass es nicht an Sophos Endpoint liegt. Auch folgt aus der Beobachtung, dass es erst seit 6.4 auftritt keine Kausalität in Bezug auf ein Problem mit dem Installer.

  • Wir nutzen eine Sophos XG als Firewall in Verbindung mit Sophos Endpoint (Cloud-Version Antivirus + InterceptX) und haben bisher keine Probleme festgestellt.

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

  • Gibt es denn irgendwo ein Log, dass ein Download blockiert wurde?


    Kann unterschiedliche Ursachen haben, deshalb muss auch an unterschiedlichen Orten gesucht werden.



    Bei der Firewall ist dies der "Log Viewer"
    SophosXgMenu.jpg


    Bei Sophos Central sind dies

    • Alarme
    • Bedrohungsanalyse-Center
    • Protokolle und Berichte


    SophosCentralMenu.jpg

    Gruss
    Thomas


    hertli ¦ IT
    hertli Informatik+Treuhand


    eMail: mail ( a t ) hertli.ch
    Internet: www.hertli.ch


    Virtuelle Rechenzentren (IaaS, PaaS) mit Standorten in CH + DE, Managed Services, Security

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!