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

Knowledge Base & Downloads

444 posts

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.

Environment:

  • Pharos Systems Blueprint Enterprise v5.1
  • Microsoft Windows Server - Cluster Services


Symptom:

  • An invalid Windows Registry key is defined for the creation of the Pharos Systems Secure Release Service generic service for a Microsoft Windows clustered server implementation. This error will cause Secure Release Here job lists to fail at the terminal.


Resolution:

Please use the attached update to the "Blueprint Installation Guide" that comes with the product software download. This update corrects a Windows Registry key error for the Pharos Systems Secure Release Service generic service configuration.

Environment:

  • Pharos iMFP for HP version 4.x (HP FutureSmart)


Symptoms:

  • Install appears to be successful, but after restarting the Pharos application does not run.
  • Uninstalling and reinstalling does nothing to solve the problem.
  • This only happens on some devices, not on most.


Cause:

There is a pre boot menu option called "Skip Disk Load". The option exists right next to "Cold Reset" which is one of the more frequently used options. We have seen folks turning this "Skip Disk Load" feature On by accident while trying to do Cold reset.  If this is option is checked, then Device will not load anything from Disk. The solution loads fine on Disk, but Device behaves as if it doesn't exist. Since it is a sticky setting, multiple reboots and reloading of SW would not have any affect.

Resolution:

Change "Skip Disk Load" to off and then restart the device.

Note: Access to the boot menu should be done by individuals familiar with the HP hardware.

Magtek card reader is connected to supported Xerox iMFP device, however card swipe events are no detected, i.e. nothing is happening after a card swipe.

 

#1. Xerox devices MUST see sentinels in card data obtained from a Magtek card reader.  If the data read from the card does not have sentinels, the Xerox device will completely ignore the card swipe.  Your card readers were configured so that sentinels were disabled, therefore the Xerox was ignoring the card swipe.

 

To re-enable to sentinels, execute the following command to the card reader using the Magtek USBMSR Demo program:

     01 04 63     <send msg>    (This restores the default state to sentinel data flags)
     02     <send msg>

 

If you then swipe a card, the returned data should look something like this:
     ;6008962500504550=99121200000000000000?

 

Note that the ; character the the starting sentinel for Track 2 data.  The ? is the ending sentinel.

 

 

#2. Some older Xerox devices do not like card swipes that contain only Track 2 data.  This will create a situation in which the 1st card swipe will work but then subsequent card swipes will be ignored.  To resolve this issue, reconfigure the card reader to send the Track 1 sentinel of % for the Track 2 data.  This will trick the Xerox into believing that the data is Track 1, thusly allowing each card swipe to behave normally.

 

To change the Track 2 sentinel, execute the following command to the card reader using the Magtek USBMSR Demo program:
     01 15 25     <send msg>        (This sets the Track 2 sentinel to the % character)
     02     <send msg>

 

If you then swipe a card, the returned data should now look something like this:
     %6008962500504550=99121200000000000000?

 

Note that the % character is now the starting sentinel for Track 2 data.  This will trick the Xerox into thinking the data is Track 1.  The ? is the ending sentinel.

Pharos SignUp Client logging on a Windows 7 SignUp Client it fails to log.

 

"Knowlege Base article #626,  Pharos Logsetter Utility says I can't use the log setter to turn on logging for the SignUp Client so I need to know how to get a SignUp Client Log."


Uniprint 8.1

There is currently an issue with logging the signup client as it does not produce a Signup Client log but will produce 2 other logs those being the UILog and the CPLog

 

The issue seems to be with the logsetter tool and how logging is done on Vista and Windows 7 machines.

 

Included is a tool that can be used called "remotetracer" (see attachment)

 

1. What you need to do is get this exe on a machine somewhere.  The server is probably a good choice, since it will need to run uninterrupted for a while.  On the server, run it from the command prompt.  It may tell you it needs additional configuration to work properly (i.e. adding a pipe name to the registry).  Update the registry if needed and exit the program, and run it again like this:

 

remotetracer > clientlog.txt

 

2. Now on the SignUp client to be logged, browse to HKLM\Software\Pharos\SignUp Client\Log and add a new REG_SZ value called "PipeName".  Set this value to "\\server\pipe\remotetracerpipe".  The other values should be as you would typically set for file logging (level 5, options 31, types 15, etc... if in doubt, use the logsetter and make sure all checkboxes are enabled, then add the PipeName afterward).  After this, reboot the client and when it restarts you should see clientlog.txt on the server begin to increase in size.

 

While this is going on, make sure we are still writing the CP, UI, and SUServer logs.

 

There are two additional keys for client logging on Vista/W7, for logging different components.These are for the Credential Provider (CP Log) and Client UI (UI Log) components. Instead of a 'Log' subkey (HKLM\Software\Pharos\SignUp Client\Log), you create one called CP Log (HKLM\Software\Pharos\SignUp Client\CP Log) and one called UI Log (HKLM\Software\Pharos\SignUp Client\UI Log).

 

The UI component is basically just the clock icon and popup messages, so logging that is not too interesting. If you do decide to log the UI component, that process runs as the user and so requires a log location the user can write to. The other one (CP Log) logs little more than function traces, but logs with system privileges.

 

The two new subkeys use the same format as the original Log key, so the easiest thing to do is set logs using the logsetter, then export that subkey (HKLM\Software\Pharos\SignUp Client\CP Log) and modify it to create the same values under the new names.

 

This should get you logs of the SignUp Client.



Uniprint 8.2 and later


There are 3 specific registry keys used to enable detailed logging on a Uniprint Signup client.  The attached zip file (SignUp Client Logging Registry Keys.zip) will create 3 files.

1. The Signup Client log
This log contains information on the client and its communications to the server.

2. The Signup CP Log
This log contains information on some of the underlying components of the client provider mechanism.

3. The Signup UI log
This log contains information on the User Interface of the client.

These 3 log files will be created in the directory "c:\windows\temp\pharoslogs".


This directory must be manualy created on the client machine.  If you are using a PC State software such as Deepfreeze or Clean Slate then the registry keys may need to be modified to point to a folder in the "Safe Space" of the client system so they do not get deleted when the client machine reboots and the PC is reverted back to a "clean state".

The 3 log file names will be:
1. signupclient-log.txt
2. signupCP-log.txt
3. signupUI-log.txt

After applying the registry keys you will need to restart the client PC.

To delete all the logs files created and start with a new set you will need to stop the "Pharos SignUp Client" Windows service, delete the files and then restart the service.

There are two folders in the zip file, one for 32-bit clients, and another for 64-bit clients.