Skip navigation
All Places > Knowledge Base & Downloads > Blog > Authors Scott Olswold


  • Pharos Blueprint Enterprise 5.3.x
  • Pharos iMFP for Konica-Minolta v1.5.x
  • Pharos iMFP for Konica-Minolta v2.x



  • The service will not start.
  • Cannot secure a device.
  • ERROR: "Unable to register Secure Print because the browser certificate is not available."
  • ERROR: "User [Domain]\[User] requires full R/W permisson to use the Management console. User can't write."
  • ERROR: "UnknownMessage" on device display.



Pharos Blueprint Enterprise 5.3.x includes the MFP Site Service as part of its installation. This service creates endpoints that can listen in the range and another, which are also potential endpoints used by the service running as part of the Pharos iMFP for Konica-Minolta server installation. Because there is a potential for port contention, the solution behavior is unpredictable and will cause operational problems.



Part I. Determine the conflicting port(s).

  1. If the  iMFP for Konica-Minolta service is running, stop it.
  2. Close the Konica-Minolta management console.
  3. Using Windows Task Manager, identify the Process ID (PID) of the “Mps.Client.Mfp.Service.exe” process (the Details tab will display this by default).
  4. Using Command Prompt running as an administrator, run the following set of commands: netstat -ano > netstat.txt notepad netstat.txt
  5. Look for the “Listening” ports associated with the PID of Mps.Client.Mfp.Service.exe. These will be found under the “Local Address” header in the netstat.txt file, expressed as<portnumber>. Write them down.

Part II. Reconfiguring the KM Service.

Pharos iMFP for Konica-Minolta v1.5.x

  1. After installation, launch the Management Console for KM iMFP.
  2. There will be a prompt to configure the application. Continue.
  3. Using the ports from Netstat, look for the match within the Application Settings > Service Settings screen. It will likely be the Listening Port (v1.5.6 and lower) or Listening Port (Auth) (v1.5.7), as that uses TCP 50004 by default. Change it and continue to configure application settings.


Pharos iMFP for Konica-Minolta v2.x

  1. After installation, launch Notepad as an administrator and open [Drive]:\Program Files (x86)\PharosSystems\Pharos iMFP for Konica Minolta V2\App_Data\km\Konica-Minolta.config.
  2. Locate the lines for port configuration and identify the conflicting port assignment(s). If TCP 50006 is the conflicting port, for example, change the following line: <add key="pullPrintListeningPort" value="50006" /> to use a different port.
  3. Save the change(s).
  4. Restart the Konica-Minolta iMFP v2 service.


NOTE: If the server is running Windows Firewall or some other port blocking application, an exception will have to be made to allow communication against the changed port(s). Similarly, TCP port configuration may be required on switches and/or routers to enable communications between the server and the device.


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.


  • 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.


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.

Background and Purpose

Pharos Blueprint Enterprise utilizes Active Directory for many functions:


  1. User authentication at a terminal (iMFP solution or Omega) for copier access or Secure Release Here job release.
  2. ID card registration at a terminal for copier access or Secure Release Here job release.
  3. User authentication when using either the Windows or MacOS Print Agent in "unauthenticated user" mode.
  4. Policy Print assignment.


Some things, like the authentication script for terminals and Print Agents, can be explicitly defined with a designated account with sufficient permission to browse and read Active Directory objects. But in most cases, installations of Blueprint Enterprise rely on a set of access assumptions and default behaviors that are not valid in specific environments. This article will discuss those assumptions and default behaviors, and how to render configuration changes so that the software can work successfully in any environment, regardless of security protocol.


"Out of the Box" Behaviors

When installing Blueprint Analyst or Collector software, the Tracker and EDI web services that are also installed rely upon an "Application Pool" to connect with the underlying Microsoft .Net functions that are used to do the work. Prior to IIS 7.5 (introduced with Service Pack 2 for Microsoft Windows 2008 Server and included in Microsoft Wndows 2008 R2 Server), application pools could use, by default, either the built-in LocalSystem or Network Service special accounts. Using Network Service allowed the web application, via the application pool, to access local files (and do so in a very protected manner) as well as access network services (like Active Directory) by masquerading/presenting itself as the server's domain machine account (as DOMAIN\MACHINE$). However, with IIS 7.5, Microsoft retooled this configuration such that a new, limited-function credential was created called "ApplicationPoolIdentity." This special-use account is local to the server and is expressed as "IIS AppPool\<AppPool Name>" for access/permissions purposes. When this identity is used to access a network service or resource, it also presents as the server's domain machine account.



By default, either Network Service or the ApplicationPoolIdentity should allow browsing of Active Directory and for its objects to be "read". However, security constraints within Active Directory can cause this to fail.


Resolving Active Directory Access Issues

The best method for resolving Active Directory access issues when the default behavior model falls short is to explicitly define the PharosSystemsAppPool with a domain user account that fulfills the following criteria:


  1. Has been added to the local "IIS_IUSRS" security group.
  2. Has sufficient credentials to read the Active Directory domain (and, by extension, any other domains in the forest and - as required - other forests).
  3. Has a non-expiring password.


To set the new identity:


  1. Start IIS Manager on the server and browse to the "Application Pools" group.
  2. Select the "PharosSystemsAppPool" and then click "Advanced Settings" link under "Edit Application Pool".
  3. Under the "Process Model" group, click inside the value for "Identity" (the value will be listed as ApplicationPoolIdentity). Then, click the "Browse" button (the small box with the ellipsis: "..." in it).
  4. Choose "Custom Account" and then click the "Set..." button.
  5. Provide credentials as follows:
    1. User name: Use the format <Domain>\<User>. In the screenshot above, I used "blueprint\pharossvc" since "blueprint" is my environment's domain name.
    2. Password. Type as-is assigned.
  6. Click "OK" until you are returned to the main IIS Manager interface to commit the change.
  7. Stop and Start the PharosSystemsAppPool. Note that you may need to wait a few seconds (I count to 5) before attempting to start, or you may get a weird error message:

    This can be readily dismissed and then a start of the application pool will be successful. You've just been impatient, and Windows is not ready for you yet.


An Alternate Path

If you choose not to manage the configuration this way, it is also possible to access Active Directory as if it were LDAP (at its core, it is X.500). The LDAP configuration under the Blueprint Administrator's Device Management > Authentication Methods section:

allows for a defined "BindDN" which bypasses the inherent permissions defined for the ApplicationPoolIdentity user.


  • Microsoft Windows 2003 Server (any edition)
  • Microsoft Windows 2008 Server (any edition)
  • Microsoft Windows 2008 R2 Server (any edition)
  • Microsoft Windows 2012 Server (any edition)
  • Microsoft Windows 2012 R2 Server (any edition)
  • Pharos Systems Blueprint Enterprise (all versions)
  • Pharos Systems Uniprint Suite (all versions)



  • Print jobs have incorrect print attributes
  • Incorrect user assigned to print job
  • Excessively large SPL files found in C:\Windows\System32\spool\PRINTERS that exhaust hard disk space
  • ERROR: "Job was deleted or purged" in Pharos Administrator or found in log files for the "page counting" activity
  • Several 0 KB files SPL and SHD found in C:\Windows\System32\spool\PRINTERS
  • Cannot delete 0 KB SPL and SHD files C:\Windows\System32\spool\PRINTERS



With Microsoft Windows XP and 2003 Server, Microsoft introduced a change in the creation of spool file (.spl) and the "shadow" file (.shd) that accompany print jobs. The new technology is called "Spool File Pooling" and causes the operating system to create SPL and SHD files following the name format "FPnnnn" and then the extension. On busier servers, Spool File Pooling can also cause multiple sets of "placeholder" files that are reused and, when activity slows down, will delete unnecessary copies. Prior to Windows XP and 2003 Server, spool and shadow files were created "on demand" as print jobs were requested and used the "Job ID" (assigned by Windows Spooler) as the file name.

The Pharos Systems Blueprint and Uniprint products use the information stored in the SPL files, in addition to our Page Count process, to determine relevant attributes of the print job. Further, in a Secure Release Here environment, the Pharos Secure Port monitor uses these files to create the stored jobs for users' later release. Spool File Pooling can create a significant challenge for all of those operations on servers running Pharos software. It can be disabled either "by queue" to accommodate a specific Pharos-controlled function, or for the entire operating system. Pharos recommends disabling it server-wide on servers running Pharos server software (Pharos Uniprint Print Services, Pharos Blueprint Analyst, Pharos Blueprint Collector) and all servers running Pharos Blueprint Tracker or Pharos PrintScout.



Please follow the directions outlined in the following Microsoft Knowledge Base article to disable Spool File Pooling:


"Third-Party Print Management Program Does Not Work as Expected After You Upgrade to Windows Server 2003 or Windows XP"


NOTE: It is necessary to restart the Print Spooler service to make this change take effect. This is not specifically mentioned in the article.