Troubleshooting – Mobile Session Print

161 views 0

Hier finden Sie eine Liste von Problemen mit ThinPrint Mobile Session Print und Tipps zu deren Lösung.

Mobile-Session-Print-Server lässt sich nicht erneut registrieren

Wenn sich der Mobile-Session-Print-Server – beispielsweise nach einem Umzug in eine andere E-Mail-Domäne – nicht (mehr) am TPNS registrieren lässt, führen Sie eine neue (saubere) Registrierung durch Installation von Mobile Session Print auf einer neuen Maschine durch, um von dort eine neue Registrierung auszulösen.

Ist dies nicht möglich, wenden Sie sich an den ThinPrint-Support.

Mobilgeräte lassen sich nicht registrieren

Wenn sich zwar der Mobile-Session-Print-Server am TPNS registrieren lässt, nicht jedoch die Mobilgeräte, dann überprüfen Sie auf dem Mobile-Session-Print-Server, ob sich das ThinPrint-Root-Zertifikat

  • ThinPrintMobilePrint Instance CA

im Zertifikat-Store in

  • Zertifikate (Lokaler Computer)\Vertrauenswürdige Stammzertifizierungs­stellen\Zertifikate

befindet. Wenn nein, kopieren Sie dies von

  • Zertifikate (Lokaler Computer)\Eigene Zertifikate\Zertifikate

nach

  • Zertifikate (Lokaler Computer)\Drittanbieter-Stammzertifizierungsstel­len\Zertifikate.

Fehlermeldungen

  • Exception – The underlying connection was closed: An unexpected error occur­red on a send. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. (Code 00000000)
    • Ursache: Möglicherweise wurde auf dem Mobile-Session-Print- oder Proxy-Server für das HTTPS-Binding kein Zertifikat ausgewählt, weshalb der betreffende Server keine Verbindungen annimmt.
    • Lösung: Prüfen Sie auf dem Mobile-Session-Print-Server und ggf. auf dem Proxyserver die IIS-Konfiguration, und stellen Sie sicher, dass für das HTTPS-Binding ein für diesen Server passendes und gültiges Zertifikat ange­geben ist.

Trace-Logging für Proxy- oder Mobile-Session-Print-Server aktivieren

Hinweis! Aktivieren Sie das Trace-Logging aus Performance-Gründen nur temporär.

– Aktivieren Sie im Server-Manager das Failed-Request-Tracing mit Web Server (IIS)→ Web Server→ Health and Diagnostics→ Tracing.

Server-Manager: IIS-Rollenfeature Tracing aktivieren

Server-Manager: IIS-Rollenfeature Tracing aktivieren

– Öffnen Sie den IIS-Manager, wählen Sie den betreffenden Server, und öffnen Sie Failed Request Tracing Rules.

IIS-Manager: Failed Request Tracing Rules wählen

IIS-Manager: Failed Request Tracing Rules wählen

– Wählen Sie Add.

Failed Request Tracing Rules: Add wählen

Failed Request Tracing Rules: Add wählen

– Wählen Sie All content und dann Next.

Failed Request Tracing Rules: All content wählen

Failed Request Tracing Rules: All content wählen

– Geben Sie 401 als Statuskode für das Logging an. Fahren Sie mit Next fort.

Failed Request Tracing Rules: Statuskode 401 eingeben

Failed Request Tracing Rules: Statuskode 401 eingeben

– Wählen Sie ausschließlich Verbose für WWW Server, und lassen Sie unter Areas alle Optionen aktiviert. Bestätigen Sie mit Finish.

Failed Request Tracing Rules: WWW Server konfigurieren

Failed Request Tracing Rules: WWW Server konfigurieren

– Um den Speicherort für die Logdatei anzugeben, wählen Sie Failed Request Tracing für die Default Web Site oder die betreffende Unterseite.

IIS-Manager: Failed Request Tracing wählen

IIS-Manager: Failed Request Tracing wählen

– Wählen Sie Enable, und bestätigen Sie den Speicherort für die Logdatei. Bestätigen Sie mit OK.

IIS-Manager: Pfad zu Logdatei angeben

IIS-Manager: Pfad zu Logdatei angeben

Previous Page
Next Page

War dies hilfreich?