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

Knowledge Base & Downloads

448 posts

Background

Recently, a security vulnerability was discovered inside Apache Struts:

            CVE-2018-1327

            https://nvd.nist.gov/vuln/detail/CVE-2018-1327

 

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:

            CVE-2018-7489

            https://nvd.nist.gov/vuln/detail/CVE-2018-7489

 

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.

 

Regards,

Pharos Security Team

Pharos Systems International

585-939-7000

pharossecurityteam@pharos.com

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.

Environment

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

Symptoms

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

 

PharosAppPreventingWin10ShutDown.png

 

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.

 

Cause

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.

 

Resolution

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

Background

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.

 

Recommendations

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.

 

Regards,

Pharos Security Team

Pharos Systems International

585-939-7000

pharossecurityteam@pharos.com

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:

 

https://support.microsoft.com/en-us/kb/811833

Introduction

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 "/serverurl=collector.mycompany.com" or "/serverurl=http://collector.mycompany.com" then you will be telling the client to use HTTP. If you choose "/serverurl=https://collector.mycompany.com" 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
HTTPHTTPS
Server SettingNone
Optional
Required

 

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 BatchSendTime...in 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.

Goal

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

Environment

  • 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 support@pharos.com 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.

 

Image

 

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.

 

Image

 

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

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.

 

Impact

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.

Environment:

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

 

Symptoms:

  • 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

 

Cause:

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.

 

Resolution:

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.

Site Monitor is an application of Blueprint Enterprise that monitors the status of printers and multi-function devices within a network.

 

Site Monitor Operations and Features

 

DEVICE DISCOVERY

 

Site Monitor discovers and retrieves device information of printers and multi-function devices within your network using the Simple Network Management Protocol (SNMP). It supports SNMPv1 and SNMPv2. Site Monitor discovers devices using these methods:

  • Using host files (in CSV or TXT formats).
  • Using IP ranges, network hostnames, and IPV4 CIDR ranges.

After devices are discovered, you can then easily manage, monitor, and report on those devices.

 

DEVICE STATUS AND ALERT NOTIFICATIONS

 

Site Monitor detects several common status events, including when printers are low on paper or toner, or when an underlying network problem exists. You can configure Site Monitor to send email notifications when such issues arise. For example, if a device on the network is running low on paper or toner, Site Monitor can send an email alerting the appropriate person. This helps administrators know in advance which devices need immediate attention.

 

REPORTING

 

Site Monitor provides a quick way to generate reports, which you can export to Comma Separated Value (CSV) and Excel formats. The following reports are available:

  • Device Meters - This report provides the meter readings of your printers, copiers, and multi-function devices (MFDs).
  • Device Status - This report provides the status information of one or more devices.

The Pharos CS Gold Gateway allows Pharos products to interact with the CS Gold Billing System. The Gateway allows users to pay for their Pharos transactions using funds from the CS Gold Billing System. The Gateway program is installed on a network machine which connects to the CS Gold Billing Service via TCP/IP.

 

Installation

To  install the CS Gold Gateway, run the CSGoldSetup.msi on the machine on which the Gateway service will run.
 
The gateway installer places all gateway files into the directory you specify during installation (the installers will detect any Pharos components already installed, and offer this as the default install path.) The gateway service will be registered in the Windows Services manager. At the end of the installation, a configuration utility will be displayed. The service can be configured and started from this utility. Shortcuts to the gateway configuration utility are created in the Start menu at Program Files > Pharos > Gateways.
 
The Billing Plug-in is provided in a separate installer and must be installed on each Pharos Print Server that will use the gateway. Run the BillPlug_inst.exe on each Pharos Print Server. The Billing Plug-in also has a configuration utility and this must be  configured to point to the Gateway machine.

 

Notes:

  • The Gateway and Billing Plug-in can be installed on Windows XP and above. Windows  2000 is not supported.
  • The installer will check for the required prerequisites: MMC3 and .NET 3.5. (.NET 3.5 will be downloaded if it is not already installed on the Gateway machine)
  • This Gateway requires the new BillPlug.exe Billing Plug-in and will not work in conjunction with the older IPBilExt.exe Billing Plug-in.
  • For use in conjunction with Uniprint 7.2, a License Server update must be applied.
  • If the CS Gold Gateway is installed on a Uniprint 7.2 Principal Server, edit the registry entry HKLM\Software\Pharos\License Server\Port Name to replace the existing value of pslserver with 2352.

 

Configuration

The  configuration utilities for the Gateway and for the Billing Plug-in can be completed at the time of installation or at a later stage. After installation, the configuration utilities are available from the Start menu at Program Files  > Pharos > Gateways. The Gateway service will not start or work properly until both are correctly configured. Any changes to the configuration require the gateway to be restarted before the changes will take effect.

 

The  configuration settings for the CS Gold Gateway are as follows:

 

  • Gateway Service:

Incoming Port: The TCP/IP port on which the Pharos Billing Plug-in will connect with the Gateway. The default of 2111 is already configured in both the Gateway and the  Plug-in. Any change here must also be implemented at the Billing Plug-in end.

 

  • CS Gold Server:
    • Host  Name: Enter the host name or IP address of the machine on which the CS Gold Billing Service is running.
    • Port: The TCP/IP port on which the Gateway will connect with the Billing Service. The default of 23801 is already configured. Any change here must also be implemented at the Billing Service end.
    • Log: Provide a file name for logging. The default location for log files is the Pharos\Log folder of the installation directory. A different path may be specified if desired.
    • Card Types: Define as many card types as required to support different cards in use  on site. At least one card type must be defined. Provide a sample Card ID in  the field provided and the card types context will step you through defining  the card layout and any restrictions on format. The default Regular Expression  can be extended to match the Sample Card ID. For more complex Regular  Expressions, consult the Regular Expressions help file provided.

 

Once the Gateway and Plug-in are installed, in Pharos Administrator, create a Bank that uses billplug.exe as its Billing Plug-in. Select this Bank for all Pharos Stations that use the CS Gold server for charging.

Environment
  • Pharos Systems MobilePrint 2.0
  • Canon imageRUNNER multifunction device
  • Canon imageRUNNER Advanced multifunction device
  • Pharos Systems Print Center
  • Pharos Systems iMFP for Canon
  • Microsoft Windows 2008 R2 Server
  • Microsoft Windows 2008 Server
  • Microsoft Windows 2012 R2 Server
  • Microsoft Windows 2012 Server

Symptoms
  • Jobs do not print with expected attributes.
  • Single sided jobs print double sided.
  • Double sided jobs print single sided.
  • Black and white jobs print in color.
  • Color jobs print in black and white.

Cause
While Pharos Systems MobilePrint allows users to change the finishing options of jobs that have already been rendered by the print driver (plex mode, number of copies, color mode, and number of pages per sheet), some driver manufacturers have chosen to use proprietary (non-standard) attributes instead. By manipulating the printer driver configuration and managing the defaults for the user account running the MobilePrint Worker service, much of this can be resolved.

Resolution
 
1. Log into the server using the account that runs the MobilePrint Worker service.
2. Go into Properties for the queue utilizing the Canon imageRUNNER-ADV 5045 PCL6 driver.
3. On the General tab, click the "Preferences" tab. Configure preferences here for SINGLE-SIDED finishing and COLOR mode. Click OK and APPLY this change.
4. Go to the Advanced tab. Uncheck the "Enable Advanced Printing Features" option. APPLY this change.
5. While on the Advanced tab, click the "Printing Defaults" button. Configure preferences here for SINGLE-SIDED finishing and COLOR mode. Click OK and APPLY this change.

 

Once this has been done, launch the MobilePrint Administrator web page and ensure that the Canon devices is using the iR-ADV PCL driver and that the "Black and White Conversion" is being handled by the Printer.

Symptoms:

  • Windows service does not start.
  • ERROR: "Error 1502. The service did not respond to the start or control request in a timely fashion" when starting a Windows service.
  • The "Pharos iMFP Management Console" does not launch.
  • ERROR: "The Pharos iMFP Management Console has stopped working."


Environment:

  • Pharos iMFP for Konica-Minolta v1.2.x
  • Pharos iMFP for Konica-Minolta v1.3.x
  • Pharos iMFP for Konica-Minolta v1.4.2
  • Microsoft Windows 2008 Server
  • Microsoft Windows 2008R2 Server
  • Microsoft Windows 2012 Server
  • Microsoft Windows 2012R2 Server

 

Cause:

The "Pharos iMFP for Konica-Minolta" service requires that Microsoft .NET 2.0 components be installed on the host server.


Resolution:

  1. Install the Microsoft .NET 2.0 components on the host server:
  2. Launch Server Manager.
  3. Click the "Add Roles" link.
  4. Put a checkbox in the "Application Server" option.
  5. In the dependency dialog box that appears, click the "Add required features" button to install .NET Framework 3.5.1 features.
  6. Select any additional Role Services that may be required for the server. Click "Next."
  7. Continue through any additional screens until you come to the "Install" step. Click the "Install" button.
  8. Restart the server as required.

How can the SQL connection's server instance, username and / or password be updated for Pharos Systems SiteMonitor?

 

This procedure utilizes the SiteMonitor installation utility (SiteMonitor.msi) to generate a new configuration file.  It will be necessary to locate the correct Blueprint Enterprise installation package that matches the version that is installed.

  1. On the Analyst server, navigate to the X:\Program Files (x86)\PharosSystems\SiteMonitor\Service folder, where X is the drive letter onto which Blueprint Enterprise was installed.  If the OS is 32-bit, navigate to the X:\Program Files\PharosSystems\SiteMonitor\Service folder
  2. Move the PharosSystems.SiteMonitor.Service.exe.config file out of this folder and place it on the desktop temporarily.
  3. Launch the SiteMonitor.msi installer from the Blueprint installation package.
  4. Click the Next button.
  5. Choose the Repair option.
  6. Within the Site Monitor Setup window that appears, enter the correct SQL server instance, username and password for the SiteMonitor database.
  7. Click the Next button.
  8. Cick the Repair button.
  9. Click the Finish button when completed.
  10. Launch the Pharos Systems Site Monitor Administrator to verify that the service is online and operational.