Press CTRL+K to open search

Blueprint Tracker and EDI Web Service tests return HTTP 401 Unauthorized

Updated
  • Updated on Sep 21, 2026
  • Published on Mar 1, 2024
  • 3 minute(s) read
Prev Next

Overview

When the Blueprint Server Configuration Tool reports HTTP 401 or 401.x for the Tracker Web Service, Tracker REST API, or EDI Web Service, IIS is rejecting the request. The cause may be IIS authentication, application-pool identity, NTFS permissions, firewall settings, SSL configuration, TLS compatibility, or a version-specific defect.

Applies to:

  • Blueprint Enterprise Analyst and Collector servers.

  • Blueprint Server Configuration Tool.

  • Tracker Web Service, Tracker REST API, and EDI Web Service.

  • Blueprint Enterprise 5.0 through 6.1, subject to version-specific configuration differences

Symptoms

  • The Tracker Web Service or EDI Web Service test fails with HTTP 401 or 401.x.

  • The Tracker REST API test fails after a new installation or upgrade.

  • Multiple Blueprint service tests fail at the same time.

  • EDI-connected terminals or iMFPs cannot communicate with the Collector.

  • The failure occurs on one Collector while other Collectors pass the same tests.

Cause

Common causes include:

  • Anonymous Authentication is disabled or IIS authentication settings do not match the Blueprint deployment.

  • The PharosSystemsAppPool application pool is stopped, uses an incorrect identity, or lacks access to required Blueprint and IIS resources.

  • NTFS permissions on Blueprint or IIS application directories have been changed.

  • Required Blueprint communication ports are blocked by Windows Firewall or a network firewall.

  • The HTTPS binding, SSL certificate, or server hostname does not match the Blueprint configuration.

  • TLS versions or cipher suites supported by the server do not match the Blueprint version.

  • Blueprint 5.4 General Release has a known issue involving the Tracker SSL Support setting.

  • An upgrade left a stale precompiled ASP.NET interface or assembly reference.

Resolution

  1. Record the Blueprint version, server role, failing test name, full error text, server hostname, and whether the issue affects one or multiple servers.

  2. Open IIS Manager and review the website used by Blueprint.

  3. In the website’s Authentication settings, confirm that the authentication configuration matches a known-good Blueprint server. For deployments using Anonymous Authentication, confirm that Anonymous Authentication is enabled.

  4. Open Application Pools and confirm that PharosSystemsAppPool is running.

  5. Review the application-pool identity. If a custom account is used, verify that the account is valid, its password has not expired, and it has the required permissions. Do not change the identity to a different account without confirming the site’s deployment design.

  6. Verify NTFS permissions on the Blueprint and IIS application directories against a known-good server or the applicable installation documentation.

  7. Confirm that the configured Blueprint communication ports are open on the server and network firewalls.

  8. For EDI communications, verify that:

- SSL is enabled on the website used by the EDI Service.

- The certificate is installed correctly and is valid.

- The configured Server Host Name/Address matches the certificate’s fully qualified domain name.

- The HTTPS binding matches the supported Blueprint configuration.

  1. For Blueprint 5.4 General Release, if Tracker SSL Support is set to Optional or Required and tests fail, temporarily set it to None for diagnostic purposes. Review the applicable version documentation before changing production SSL settings.

  2. If the error text refers to a trust relationship, TLS channel, cipher, or certificate, troubleshoot TLS and certificate compatibility instead of treating the issue as an NTFS-only problem.

  3. If the Tracker REST API fails after an upgrade and logs show an assembly mismatch, stop IIS, clear the contents of the applicable Temporary ASP.NET Files directory, and restart IIS.

  4. Restart IIS and the affected Blueprint services, then run the Server Configuration Tool tests again.

  5. If the tests still fail, enable Blueprint logging at level 10, reproduce the issue, and collect the Server Configuration Tool screenshots, IIS configuration, Windows event logs, Blueprint logs, certificate details, and firewall rules.

Validation

  • Tracker Web Service test passes.

  • Tracker REST API test passes.

  • EDI Web Service test passes.

  • Other affected service tests pass.

  • Terminals, iMFPs, or other Blueprint clients can communicate with the server.

Notes

  • A 401 response does not identify a single root cause. Compare the failing server with a known-good server.

  • Do not assume that an IIS, SSL, TLS, application-pool, or NTFS fix applies to every Blueprint version.

  • The EDI Service has stricter SSL requirements than optional Print Scout SSL communication.

  • If changing IIS authentication or SSL settings does not resolve the issue, restore the previous configuration and escalate with the collected logs and screenshots.

Related articles