Skip navigation
All Places > Knowledge Base & Downloads > Blog
1 2 3 Previous Next

Knowledge Base & Downloads

455 posts

Dear Pharos Customers/Partners


Pharos software is not susceptible to the new Apache Struts vulnerability



Recently, a new security vulnerability was discovered inside Apache Struts:





This vulnerability is serious because it allows a possible Remote Code Execution when the alwaysSelectFullNamespace option is enabled in a Struts 2 configuration file, and an ACTION tag is specified without a namespace attribute or a wildcard namespace. Further, it has a CVSS v3 base score of 9.8 (out of a possible 10)


Many organizations, including Pharos customers, are urgently investigating where this tool is used and to update/repair those instances.


Pharos Software and Apache Struts

Pharos has reviewed all our software and 3rd party tools/libraries that we use and can confirm that we do not use Apache Struts in any product. This includes:


  • Uniprint (including all web interfaces)
  • Blueprint (including all web interfaces)
  • Mobileprint
  • All Omega devices (including PS60, PS150, PS200)
  • All iMFP implementations across all manufacturers
  • Beacon – both the desktop components and the cloud infrastructure
  • Kiosks


Pharos products are therefore not vulnerable to the Apache Struts exploit.




Pharos Security Team

Pharos Systems International



In the wake of highly publicized vulnerabilities within SSL and early TLS versions, many organizations are aggressively working to "harden" servers by enabling TLS 1.2 as the only allowable cryptographic protocol.


What's at risk?

Making the move to deprecate weak cryptographic protocols can cause concern for lack of compatibility with older applications targeting framework versions earlier than .NET Framework 4.6.


Risk Mitigation

The Windows Registry provides some control over the security protocols used by the .NET Framework, forcing appropriately coded applications that would normally default to TLS 1.0 to use stronger cryptographic protocols.


Modifying the Windows Registry to Enable Strong Cryptography for .NET Applications

Add the appropriate key-value pairs into the Windows Registry.  The following .REG file sets the registry keys and their variants to their most safe values:


Windows Registry Editor Version 5.00






The server will require a reboot for these changes to take affect.


Where can I get more information?

For complete details regarding this and other best practices from Microsoft regarding the .NET Framework, please refer to:

Transport Layer Security (TLS) best practices with the .NET Framework | Microsoft Docs


While the Pharos Blueprint Enterprise Planning and Installation Guide discusses the necessary prerequisites for the Windows server, it does not provide an easy step-by-step process to install those on the Windows Server operating systems that are supported. Depending on the background of the individual assisting with the server build, this may mean that necessary components are missing, resulting in a failed installation, rework of the server configuration, and other activities that stretch the time for installation.



This document contains two PDF files that discuss prerequisite installation. One focuses on Microsoft Windows Server 2012 R2 and the other on Microsoft Windows Server 2016. While both operating systems are very similar in what is required, there is enough difference in their respective user interfaces to warrant separate documents.


An application starts to become unstable or crash. A process dump, memory dump, or Windows Event Log application event implicates one of the following DLLs:

  • 64-bit application faults
    • AppProfiler.x64.dll
    • pt64.dll
    • ptm64.dll
  • 32-bit application faults
    • AppProfiler.x32.dll
    • pt32.dll
    • ptm32.dll


Applications running in a Microsoft Windows environment augment their feature/functionality by loading additional plug-ins at the time they are launched. These plug-ins run inside the “container” of the application. At the same time, other Windows applications, like data-loss prevention software, antivirus software, or anti-malware tools often “inject” their own plug-ins into applications for their purposes, notably to prevent the spread of computer viruses or to secure the information being transmitted by the application.

The Pharos Systems Print Scout and Preton Toner Saver client software packages also can inject a plug-in into running applications for their purposes, notably to make capturing the print job’s source application easier (Pharos Systems Print Scout) or to intercept the print job to apply the toner saving algorithm (Preton Toner Saver). Operationally, this injection has been designed to occur without interfering with the user or their task at hand; the user doesn't see any difference in the operation at all, and the client software performs its work, silently, in the background.


By default, both the Pharos Print Scout and Preton Toner Saver clients "inject" their plug-in into running applications via Windows' ntdll.dll's provided "LdrLoadDll" function. Again, the Print Scout does so to capture the name of the application (winword.exe, iexplore.exe, acrord32.exe, etc.) that generates the print job. Preton Toner Saver does so to redirect the file for toner savings or otherwise identify a monitored print job. However, there are several cases where injection may cause a problem for the end user:

  1. The 64-bit DLL is injected into a 64-bit application and put into the "lower" address space (aka: the "32-bit address space", under the 4GB mark) and not the "upper" address space (above the 4GB mark). This is more of a problem after Microsoft KB 3126593 is applied and older (produced prior to April 2016) Print Scout or Toner Saver are installed. This normally just expresses itself as instability, slowness, or crashing.
  2. The 32-bit DLL is injected into a 32-bit application and the upper registers of the 4GB address space are unavailable (used by the application, used by another injected process). This normally expresses itself as instability or crashing, but will also be seen in the Windows Event Viewer Application log as an access violation:
    Faulting application name: Acrobat.exe, version:, time stamp: 0x5543b1c0
    Faulting module name: PT32.dll, version:, time stamp: 0x54a56b84
    Exception code: 0xc0000005
  3. A third-party security package (antivirus, anti-malware, data loss prevention (DLP) app, or similar) has been configured to block injection for applications, and this is causing contention.



Resolving these problems is relatively straightforward, but may require "pushing" (using Microsoft SCCM, CA LanDesk, IBM Tivoli, etc.) a revised configuration or installation. Common resolution methods are found below.

  1. If the problem is the 64-bit "lower" address space injection, update your Pharos Print Scout (releases after May 2016 already have revised code to contend with KB 3126593) or Preton Toner Saver client (resolved in and higher). Contact Pharos Technical Support for a download link for either software package.
  2. When the Preton Toner Saver injection is affected by the memory access violation (exception code 0xc0000005), it can normally be resolved by increasing the injection delay time (version and higher) from 1000 milliseconds (the default) to 5000 milliseconds or more. If version or higher is already installed, edit the C:\Program Files\Preton\PretonSaver\PretonService.exe.Config file, changing the value for the "InjectionDelay" key to 5000. Once saved, restart the Preton Toner Saver service for the change to take effect. If the change fails in test, just make this value higher (stepping by 1000) until successful. Slower workstations will require longer delay values. If the problem persists, the application can be Protected from toner savings using Blueprint Administrator, and the DLL will not be injected:
    1. Choose Policy Print > Application Toner Savings
    2. Change the mode to "Advanced Mode."
    3. Select the application from the list and change "Application Savings Mode" to Protect.
    4. Apply the change. The Preton Toner Saver client will update at the workstation as it gets its update from the server.
  3. When the Pharos Print Scout is affected by the memory access violation (exception code 0xc0000005), it must be resolved by excluding the application from injection, or disabling injection altogether. This is done within the Blueprint Administrator application on the Collector(s) hosting Print Scout.
    1. Choose Print Scout > Settings from the shortcut bar on the left.
    2. Select the "Application Tracking" tab.
    3. Do one of the following:
      1. Untick the "Enabled" box to completely disable Application Tracking. Click the "Apply" button when finished.
      2. Click the "Add" button and enter the name of the EXE to exclude from injection. Click the "Apply" button when finished.
    4. For the change to take effect on the Print Scout, the workstations must either be rebooted, or the "Pharos Systems Print Scout" service must be restarted.
  4. If the problem is being caused because antivirus, anti-malware, or some other data protection application is blocking injection, whitelist (or otherwise allow) injection from Print Scout or Preton Toner Saver. If that type of granular injection control is unavailable, then disable the Print Scout's function (see above) and, if applicable, uninstall the Preton Toner Saver application as its entire operation requires injection of the application.

Preton Saver is a companion product to Pharos Blueprint Enterprise that further optimizes printing costs by reducing the amount of ink or toner applied to the page (see Toner Savings for more information). As part of its operation it injects a monitoring function into launched applications to see if they do any printing; if the application prints then it is added to a list so that toner savings outside of those available to the toner policy may or may not be applied. One of the potential byproducts of injecting into an application, however, is instability within the application to the point where some function may no longer work or, in the worst case, the application crashes. In many cases, the applications that become unstable don't even print. This document discusses how to manage a non-printing application to protect it from injection.

The Basics

As mentioned in the introduction, nearly all applications on a workstation are injected for monitoring by the local Preton Saver client. The three possible states of an application within Preton Saver are:

  • Monitor. The application is injected and monitored for print, but special toner savings are not applied. However, if the logged-in user has an applicable toner savings policy, those savings are applied.
  • Save. The application is injected for print, and special toner savings are applied. For example: a general toner savings policy is applied for 35% savings, but if the application is Mozilla Firefox, savings of 50% are applied. Conversely, an application savings policy may specify lower savings; for example Adobe Photoshop CS may only be set for 10% savings.
  • Protect. The application is not injected by Preton Saver, and no toner savings are applied for print jobs that come from that application.

The following set of steps will result in a protected application because it is known that the application has no way to print a job.

Creating The Application Within Preton Saver

In general, the only time an application "bubbles up" through Preton Saver for management is if that application is actually involved in printing a job. The steps below create an entry within Preton Saver when no print jobs exist for the application.

  1. Install and launch Preton Control. It is recommended that this be installed on the server hosting Preton Coordinator.
  2. Once connected to the Preton Coordinator instance, click the Applications group.
  3. Select any one of the applications in the list.
  4. In the "Applications Settings" panel on the right, click the "Add Filter" button. It will be near the middle of the page in the "Document Association" group.
  5. In the "Filter Text" field, type the friendly name of the application. To create a filter for the RealVNC Viewer, type RealVNC Viewer.

    Do not use a Regular Expression; keep that option unchecked.
  6. Under "Application Association" choose to associate a new application and type the application name shown in Windows Explorer without the "exe" extension.
  7. Click the "OK" button when done.
  8. Click the "Apply" button in the top toolbar.
  9. Locate the new application in the list (the text color will be black) and select it.
  10. In the "Application Settings" page, click the "Application setting" option and change it from "Monitor" to "Protect."
  11. Apply the change by clicking the "Apply" button in the top toolbar. The application name will change to an orange fill.


At this point, either exit the Preton Control application or add any other applications that you wish to protect.

Managing the Change at the Client

In most environments, the Preton Saver client installed on the Windows workstation/laptop is configured to contact the Preton Coordinator software infrequently for policy updates. To force a policy update, follow this process:

  1. Exit the application that needs protection if it is running.
  2. Browse to C:\Program Files\Preton\PretonSaver.
  3. Launch PretonTraceView.exe (it does not require launching as an administrator).
  4. Locate the "Update Policy" button in the upper-right corner of the window and click it.
  5. Exit Preton Trace View.

Affected Environments

  • Pharos Blueprint Enterprise 5.0 (any service pack level)
  • Pharos Blueprint Enterprise 5.1 (any service pack level)
  • Pharos Blueprint Enterprise 5.2 R1 (any service pack level)
  • Pharos Blueprint Enterprise 5.2 R2 (any service pack level)
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows Server 2016


Problem Statement

When installing Blueprint 5.x the initial Tracker and EDI web service tests fail with the message "The underlying connection was closed: an unexpected error occurred on a receive." There may also be a message about "unexpected error occurred on a send."





This error happens because SSL is enabled for the Tracker web service (where it is optional) and the EDI web service (where it is enabled by default and required). However, the server has not been enabled to support any cipher (TLS 1.0, 1.1, or 1.2; 1.2 is only compatible with Blueprint Enterprise 5.2 R1 Service Pack 3 or Blueprint Enterprise 5.2 R2). This is normally due to a Group Policy Object (GPO) setting or the default operating system image in the organization has disabled/removed the SChannel protocols in Windows Registry.



The necessary ciphers can be enabled using Windows Registry.

  1. Launch RegEdit.
  2. Browse to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Within there, look for TLS 1.0 and TLS 1.1.
  3. Expand each to expose the Client and Server subkeys. If these keys are not there, use the attached file "CreateTLS1.1.txt" as a basis for an import into the Microsoft Windows Registry.
  4. When selected, the key will have a value, "Enabled". Change it to a Hexadecimal value of 1. Ensure that each subkey's "Enabled" value is set to 1 for TLS 1.0 and 1.1. If necessary, only TLS 1.1 needs to be enabled.
  5. When completed, restart the server.


From this point, the SSL-enabled web services will pass their tests.



The following Microsoft article discusses cipher support in the various Windows operating systems and the Windows Registry settings that support them. TLS-SSL Settings | Microsoft Docs

Additionally, Pharos Blueprint Enterprise (and other Pharos Systems applications) are .NET version-dependent. This means that a specific .NET version support of an SChannel cipher must also be considered. Below follows a table listing the cipher support by operating system version. When the value is ON, this implies the default configuration unless affected by Group Policy.


Windows versionSSL2 ClientSSL2 ServerSSL3 ClientSSL3 ServerTLS 1.0 ClientTLS 1.0 ServerTLS 1.1 ClientTLS 1.1 ServerTLS 1.2 ClientTLS 1.2 Server
Windows Vista SP2 and Windows Server 2008 SP2OffOnOnOnOnOnN/AN/AN/AN/A
Windows 7 SP1 and Windows Server 2008 R2 SP1OffOnOnOnOnOnOffOffOffOff
Windows Server 2012OffOffOnOnOnOnOnOnOnOn
Windows 8.1 and Windows Server 2012 R2 OffOffOnOnOnOnOnOnOnOn
Windows 10OffOffOnOnOnOnOnOnOnOn
Windows 10 (1511)OffOffOnOnOnOnOnOnOnOn
Windows 10 (1607) and Windows Server 2016N/AN/AOffOffOnOnOnOnOnOn

Source: Note that systems utilizing .NET 3.5/2.0 will require the addition and enablement of the "SystemDefaultTlsVersions" Registry key after Service Pack 2 for this version of .NET has been applied.


In the age of mobile, we're all thumbs (unless you have a wicked-clear voice and can never befuddle Siri or Google's attempts to transcribe your mutterings). And while thumbs are awesome things (and bilateral rotating shoulder cuffs; absolutely necessary to get us out of the savannah and into tall, glass-clad skyscrapers), typing long URLs with them is not. So I'm going to teach you how to just type and get to


How To Avoid Typing "/myprintcenter"

It's actually pretty easy. See? All done! Actually:

  1. Log into the server hosting Pharos Print Center.
  2. Launch Microsoft IIS Administrator.
  3. Expand the site hosting "MyPrintCenter" (usually, it is "Default Web Site").
  4. Select the "HTTP Redirect" object and open it.
    HTTP Redirect Icon.png
  5. In the "HTTP Redirect" configuration dialog box, fill it out exactly as shown below.
    HTTP Redirect Interface.png
  6. Apply the change.

Now, it is time to undo this global action for any other web services/virtual directories hosted by Default Web Site. As an example, we'll perform the undo on the "aspnet_client" web site. Repeat for all other remaining pages.

  1. Click the "aspnet_client" item under "Default Web Site" and launch it's HTTP Redirect interface:
    ASPNet HTTP Redirect icon.png
  2. Configure the ASP.Net Client HTTP Redirect exactly as shown below. Note that the "redirect" option is not enabled.
    ASPNet HTTP Redirect Interface.png
  3. Apply the change.
  4. Restart the web service by clicking the server name in the navigation tree on the left and then clicking the "Restart" option under the Actions > Manage Server function. Note that this does not restart the operating system, just the web services on the server.
    Restart Web Server.png


Complete! From any client, go to https://servername and you should be redirected automatically to the Print Center login screen:

Redirected URL.png


NOTE: There are other methods to accomplish the same task. See IIS Redirect for Print Center for more options.


Recently, a security vulnerability was discovered inside Apache Struts:




This vulnerability is reasonably serious because it allows a DoS attack when using a malicious request.


A security vulnerability was also discovered inside Jackson-databind:




This vulnerability is serious because it allows unauthenticated remote code execution and is easy to exploit.


Many organizations, including Pharos customers, are urgently investigating where these tools are used and to update/repair those instances.


Pharos Software, Apache Struts and Jackson-databind

Pharos has reviewed all our software and 3rdparty tools/libraries that we use and can confirm that we do not use Apache Struts nor Jackson-databind in any product. This includes:


  • Uniprint (including all web interfaces)
  • Blueprint (including all web interfaces)
  • Mobileprint
  • All Omega devices (including PS60, PS150, PS200)
  • All iMFP implementations across all manufacturers
  • Beacon – both the desktop components and the cloud infrastructure
  • Kiosks


Pharos products are therefore not vulnerable to either the Apache Struts exploit nor the Jackson-databind exploit.



Pharos Security Team

Pharos Systems International


Pharos has identified an incompatibility between Blueprint Enterprise 5.0 and the installation of Microsoft KB 4056897 for Microsoft Windows 2008/2008R2 Server.


Specifically, if this Microsoft patch is applied in a Blueprint 5.0 environment (including Service Packs 2 and 3) the Tracker Web Service will fault. This will affect a server’s ability to respond to installed Blueprint Tracker client requests and uploads.


If this Microsoft patch is a requirement in your environment, install Service Pack 4.1 for Blueprint 5.0 before installing the Microsoft patch. Or, you can upgrade to Blueprint 5.1 or the latest release, Blueprint Enterprise 5.2 R2. If you have already installed this patch and experienced this problem, you will first need to uninstall the Microsoft patch prior to updating your Blueprint software.


  • Microsoft Windows 10 "Creators' Build" (1709)
  • Pharos Systems Print Scout for Blueprint (any version lower than


  • ERROR: Flame icon with "This app is preventing shutdown." message.
  • ERROR: Flame icon with "This app is preventing restart." message.
  • Screen capture of message:




NOTE: If the "Restart/Shut Down Anyway" button is not pressed, the screen will persist for a few moments and then return to the user's desktop session.



There has been a change to the “WM_ENDSESSION” message provided by the Microsoft Windows 10 Build 1709 operating system. When this change was implemented in this build of the operating system is unknown at this time. This change, however, has resulted in many applications, including the Print Scout’s “PSClientTray.exe” executable that drives the system tray UI for Secure Release Here job management, to misinterpret the message and not close during a restart or shutdown event.



Install the attached Pharos Systems Print Scout for Blueprint version This version correctly handles the "WM_ENDSESSION" message across all current (Jan 2018) Microsoft Windows versions.


Recently a pair of vulnerabilities have been disclosed that affect most computers around the world. These vulnerabilities have been named Meltdown and Spectre.


Meltdown is a hardware vulnerability affecting Intel x86 microprocessors and some ARM-based microprocessors. It allows a rogue process to read any physical, kernel or other process's mapped memory, regardless of whether or not it should be able to do so. (From Wikipedia).


Meltdown's CVE ID is CVE-2017-5754.


Spectre is a vulnerability with implementations of branch prediction that affects modern microprocessors with speculative execution, by allowing malicious processes access to the contents of other programs' mapped memory. (From Wikipedia).


Spectre's CVE IDs are CVE-2017-5753 and CVE-2017-5715


Pharos Cloud Services

Pharos cloud services reside inside Amazon Web Services (AWS) and are protected from direct access by firewalls. These services do run on computers whose processes are affected by Spectre and Meltdown. AWS has patched all of their systems and all Beacon Cloud Platform operating systems have also been patched.


Pharos Omega Devices

Pharos Omega devices are secured devices and are not open to third party software execution. While Omegas are currently susceptible to both vulnerabilities, Pharos do not believe that this can be exploited at this time.


Pharos iMFP

Pharos iMFP software runs on OEM hardware provided by printer/copier manufacturers. These manufacturers will need to provide patches if required.


Pharos On-Site Software

All Pharos on-site software runs on customer or partner managed servers, and will need to be upgraded as patches become available. Pharos software itself is not vulnerable.


Pharos Internal Infrastructure

Patches are being applied to all operations and non-test devices on the Pharos internal network with anticipated completion by end of January 2018.



Apply your manufacturer and OS service packs and updates as soon as they are available.


As always, the Pharos security team is happy to any questions you may have.



Pharos Security Team

Pharos Systems International


What is FIPS Compliance?

FIPS (Federal Information Processing Standards) is a standard that dictates cryptographic implementation and is used primarily in U.S. government-based computing environments. When Microsoft Windows is configured to be FIPS compliant, it forces the operating system, and the applications running on it, to only use approved cipher methods. For example, when FIPS is enabled, the operating system will not send, or accept, SSL 2.0 or 3.0 ciphers. Instead, it will only allow TLS 1.0 at the very least. Please note that enabling FIPS compliance in Microsoft Windows does not make your computing environment more secure. Rather, it simply more rigorously enforces the cryptographic approach of the server and the subsequent client environment...and has the potential for breaking some applications' operation.


I'm Not the U.S. Government; Why Do I Care?

Support for Windows servers only offering the TLS 1.2 cipher began with Service Pack 3 for Pharos Blueprint Enterprise 5.2. If the Windows server infrastructure hosting Blueprint Enterprise is being hardened to support TLS 1.2 as the only cipher available, then you must configure Windows for FIPS compliance if you wish to view the built-in Blueprint Reports. This configuration is necessary due to the SAP Crystal Reports integration within Blueprint Reports. This configuration is not required if you are allowing lower-versioned ciphers in the Windows environment.


Configuring Windows for FIPS

To enable FIPS you must set the following registry key to a value of 1:


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy] "Enabled"=dword:00000001


For more information please see the following from Microsoft:


Pharos Blueprint received data into its reporting database via three "on ramps":

  • Blueprint Tracker/PrintScout exports from deployed workstations and print servers
  • Imports from the included Pharos SiteMonitor application (versions 5.0 and newer)
  • Terminal (Omega, Sentry, iMFP) data captured from Secure Release Here, copying, scanning, faxing (NOTE: copying, scanning, and faxing data is terminal and copier model-specific; not all capture all things)

Depending on your site configuration, you may not be getting data from one, or some combination, of the three. This Knowledge Base article describes the paths these data take to get into the Blueprint database, and where things can break. This blog will focus only on the Tracker/PrintScout path.


Blueprint Tracker/PrintScout Data

Author's Note: Rather than persist with the "slash" naming convention, since the client component has a different name depending on the version of Blueprint you have, I am going to simply call it "the Blueprint client" from here on out.

The Blueprint client wraps both local (USB, parallel, serial, self-hosted Standard TCP/IP, LPR, and file-system connections) and remote port monitors (Windows remote - for print server-hosted queues, Microsoft IPP, Novell NDS/iPrint, etc.) for the purposes of print job capture.

Getting Data from the Client

When to Connect

The data recorded from the print job is stored locally as an XML file (potentially encrypted) until one of the following occurs:

  • It's maximum batch size, in number of stored XML files, is reached
  • It is online and can send the files during its next "batch send" time.

Both of these are determined by settings on the parent Blueprint Collector, stored under Trackers (Blueprint 5.1 and lower)/Print Scouts (Blueprint 5.2 and newer) > Settings > Basic Settings (tab) > Print Job Batching:

By default, Blueprint Collector installs with the following configuration:

  • Maximum batch size: 100
  • Forward batches to Server starting between 8:00 PM and 2:00 AM
  • Send jobs as soon as maximum batch size is reached: Disabled

How to Connect

Furthermore, the method of transport to the Collector is a pairing between the protocol selected within the Collector's configuration (using the Blueprint Server Configuration tool):

  • None. The Collector only accepts HTTP (TCP port 80 by default) connections from clients.
  • Optional. The Collector will accept either HTTP or HTTPS (TCP port 443 by default) connections from clients.
  • Required. The Collector only accepts HTTPS connections from clients.

Based on the setting chosen, you have to install the client accordingly. This happens through the "/serverurl" switch specified when running the client installer. If you choose "/" or "/serverurl=" then you will be telling the client to use HTTP. If you choose "/serverurl=" then you will be telling the client to use HTTPS.

What Can Go Wrong?

When to Connect. The most common failure point is telling the client to send print job batches when the computer is turned off, sleeping, in hibernation, or disconnected from the network. In other words: the default Collector settings will probably not be the best lead-in. The thought process behind the default settings was noble: tell your client base to upload when, hopefully, the network and systems are not busy...or after business hours. But obviously, if you are turning off (or putting to sleep, or taking a laptop/Windows tablet home) the computer, the client won't be available when it is supposed to be doing its job. The problem continues to exacerbate because on start up, the Blueprint client will check, note that it missed its upload schedule, and then set up another time unless the start up time is greater than 24 hours after the expired send time. If there is a >24 hour gap, the client will, if it is able to connect to the Collector, queue up an "on demand" job upload. Assuming that this is a daily event, though, the new set time will be outside its "on" hour So what to do?

I like to discuss things with the stakeholders (normally the networking team) to help them understand what the impact is going to be. As an illustration, I'm going to work with the following numbers:

  • Deployed base: 100,000 clients
  • Average jobs per user per day: 20
  • Average XML file size (job data): 6KB

So on a regular working day (9am to 5pm, wherever the user might happen to be), the total network impact is going to be 100000 x (20 x 6) = 12000000, or 11.4GB of data. That seems like one fantastic chunk of data, doesn't it? But let's look at email. I'm going to use my "Sent Items" folder from last week as the benchmark:

  • Deployed base: 100,000 clients
  • Average sent emails per day: 15
  • Average email size: 50KB

I'm not going to go through the math; 50KB is way larger than 6KB, so the total data will be much larger than the Blueprint clients'...even with 5 less items per day in email. So it's normally fine to set the upload schedule to be during working hours. And this 11.4GB doesn't happen all at once. The client creates a random "batch send time" based on the Start/Stop time it's been given. That means that the 11.4GB is spread between the hours specified in Basic Settings, alongside the "maximum batch" threshold and its availability. So if the Start/Stop time is between 8:00 am and 6:00 pm, that's 10 hours of time for the randomized upload. And if the "maximum batch size" is set to something reasonable (75% of average; so 15) and enabled, the randomization of the client load would be even more complete.


How to Connect. There is a straightforward matrix of settings that support a successful client:server communications path:


Client Protocol
Server SettingNone


And the more clever part comes in when managing the HTTP/SSL communications, since you have to ensure that the workstations and servers have the same certificate paths (and expiration dates) for error-free communications. Resolving "How to Connect" is a matter of ensuring that the server and client settings, and certificates if using SSL, match.


How To See "When to Connect" Go Wrong

Reporting is normally the first place to see a deficiency in client-based data. You see it when the MPS bill comes in for 1.4 million clicks for August, but your Blueprint report shows only 5,000 printed pages for the same month. Without going from workstation to workstation, the quickest place to look to see if Blueprint client is the lacking path is within the Blueprint Administrator on the Analyst. Expand the Tracker/PrintScout group and choose the Machines view. Each row you select shows a roll-up view at the bottom of the user interface that contains essential "client health" data:

The "Last Print Job Sent" value is the timestamp of the most recent print job the client was able to both capture and upload. Because the Analyst gets this data through a chain (Client > Collector > Analyst), this date will normally be some time in the near past, but hopefully not much older than 2 days or so. Some EXCEPTIONAL EVENTS will change the "Last Print Job Sent" times, making them much older:

  1. Some computers have users who do not, or cannot, print, so if you see entire groups not reporting data, you probably have a workflow getting in your way.
  2. People go on vacation or are otherwise away for long times, and when this happens, their computers go on vacation, too, so expect some seasonal variations to the theme.
  3. Teleworkers and traveling folks who are reliant on software VPN solutions to connect will most likely import their data infrequently, but when it imports it can be a bunch at once--I'll touch on how to handle this below.

The "Last Heard From" value is the last time the client established a health check with its Collector. Again, because of the import chain that is endured, the value here will have most likely occurred in the past. Exceptional events 2 and 3 from above can occur here, too. But a workstation that does not print will still send heartbeats to its Collector.

If your "Last Print Job Sent" for workstations is either really old or non-existent, but "Last Heard From" is recent, then you probably have a "I can't upload" issue. You can confirm this at the workstation layer by looking at the ProfilerControlTask.log file found in C:\ProgramData\PharosSystems\PrintScout\Logs or C:\ProgramData\PharosSystems\Blueprint\Logs. You will see a line like this:


[2016/09/08 09:10:32 PB10 TB38 i ProfilerControlTask] BatchSendTime has passed, using cached time = '2016-09-07 23:40:42'


Breaking apart the log line, the first date and time records when the log line was written, so the 8th of September at 09:10:32. The message for this event is "BatchSendTime has passed", which is the client recognizing that it missed its previously-set time to upload job data, which, according to the cached time, was the 7th of September at 11:40:42 pm. A bit further down, this line is present in the log:


[2016/09/08 09:11:41 PB10 T1640 d ProfilerControlTask] Batch send time has passed, but nothing to do so recalculating.


This is the message that the client is aware that the batch send time has passed, but it isn't quite 24 hours old (only 9.5 hours has passed). Then, a bit farther down (but not much), this line appears:


[2016/09/08 09:11:41 PB10 T1640 d ProfilerControlTask] -> CGlobalState::CalculateBatchSendTime

[2016/09/08 09:11:42 PB10 T1640 i ProfilerControlTask] BatchSendTime = '2016-09-08 22:40:04'


Which is the event to set the new this case it will be on the 8th of September at 10:40:04.


Fixing the Problem

All that needs to happen to resolve this problem is to adjust the batch send time on the Collector(s) hosting clients. When each client refreshes its configuration from the Collector, those settings take immediate effect. The screenshot shared earlier in this blog is sufficient for sites of all shapes and sizes.


Handling VPN Workstations - The Special Group

The teleworker/traveler workstations that utilize VPN connectivity represent a challenge to how the Blueprint client behaves. First and foremost, these workstations are not typically online immediately after startup, meaning that the client's initial configuration event fails, causing it to use a cached configuration in order to function; a refreshed configuration will occur once the workstation is online. This is not inherently bad, which is why we keep a "last known good" configuration available, but it represents a group that will not receive any updates immediately. From a deployment standpoint, a common suggestion is to identify a dedicated Collector server for the VPN workstations so that they can be given a special batch loading configuration so that jobs are moved off those workstations more rapidly than workstations that "live" in the organization's network.

Within this special Collector, the goal is to set a very small "maximum batch" size and enforce it, and ensure that the upload time matches the local workstation's operating hours:

The settings above will ensure that the workstation sends its job data as soon as it is created, so very little backlog is created locally. And it does this well into the evening hours, but before Collectors generally start their nightly upload to the Analyst. This keeps the inbound job data fresh.


  • Generate an SSL certificate that supports Subject Alternate Names (SANs)


  • Pharos EDI Service
  • Pharos Print Center

Generating a Certificate Request containing Subject Alternate Names

Download the SAN Certificate Request Form to submit your request for a SAN certificate to Pharos Systems Technical Support. Technical Support can provide a SAN certificate for both SHA-128 and SHA-256 environments, in either 1024 or 2048-bit length. You may either email the completed form to or submit it as an attachment to a new Support Request.

In the event that the Pharos Database Service fails to start (hangs and times out), confirm the settings within "Sql Server Configuration Manager".


This scenario has been found to occur when customers are migrating their database, or bringing up a new SQL server- though it has yet to be determined exactly why these settings become misconfigured.


1) Open "SQL Server Configuration Manager" window, expand "SQL Server Network Configuration".

2) Click to highlight "Protocols for MYSQLSERVER". Confirm that TCP/IP's status is set to Enabled.




3) Right click "TCP/IP" and choose Properties -> IP Addresses tab.


Ensure that the TCP Port field for each IP is configured for port 1433.
Ensure that the Active field for each IP is set to Yes, and the respective IP Address for each IP is configured properly. IP1 = IPv6, IP2 = IPv4, IP3 = IPv6 loopback, IP5 = IPv4 loopback. These IP address should be that of the server which hosts the sql server.




4) The Pharos Database Server service should now be able to start without issue.