Blueprint Enterprise 5.1 Configuration Guide

Configuration Guide
Document Version: BPE51-Config-1.0
Distribution Date: April 2013
Pharos Systems International Suite 310, 80 Linden Oaks Rochester, New York 14625 Phone:1- 585-939-7000 US/Canada Toll Free:888-864-7768 www.pharos.com
Copyright © 2013 Pharos Systems International, Inc.
Pharos®, Pharos Blueprint® ,Uniprint®, Secure Release Here®, Policy Print™, and making every print an
intelligent decision™ are trademarks or registered trademarks of Pharos Systems International, Inc. The
trademarks and names of other companies and products mentioned herein are the property of their
respective owners.
2
Configuration Guide
Table of Contents
Table of Contents 3
Introduction 14
About this Document 14
Other Documentation 14
Getting Help 14
Pharos Website 14
Contact Details 14
Managing Logons 15
Types of Logons 15
Logon Models 15
Adding Logons 15
Deleting Logons 16
Enabling Health Notification Emails 17
Configuring Data Imports 18
Data Feeds 18
Importing Files Manually 18
Supported Import File Encoding 19
Standard Import File Types 19
Importing Employee Data 20
Importing Human Resource Data 20
Importing Identifier Translation Data 21
Importing Model Data 22
Importing Model Data 22
Importing Model Cost Data 23
Configuring Collector Exports 24
Automatic Collector Exports 24
3
Configuration Guide Table of Contents
Manual Collector Exports 25
Renaming Collector Servers 26
Configuring Policy Print™ 27
What is Policy Print? 27
Before You Start 28
Configuration Interfaces 28
Getting Started with Policy Print 29
Policy Components 29
Blueprint Default Policies 30
Managing Policies 31
Adding a Policy 31
Editing a Policy 31
Deleting a Policy 32
Rules 32
Rule Components 32
Getting Started with Rules 33
Managing Rules 33
Adding a Rule 33
Editing a Rule 34
Deleting a Rule 34
Triggers 35
Blueprint Built in Triggers 36
Trigger Conditions 36
Managing Triggers 39
Adding a Trigger 40
Editing a Trigger 40
Defining Complex Trigger Expressions 41
Multiple Trigger Conditions 41
4
Using the "Unless" Condition 41
Text Matching Modes Used in Trigger Conditions 42
Wildcard Matching 42
Regular Expression Matching 43
Case-Sensitive Exact Matching 44
Action 44
Multiple Rules per Job 45
Prompts 45
Groups 46
Active Directory 46
Recommendations for Assigning Groups to Policies 47
Assigning Groups 47
Searching Groups 48
Simple Search 48
Advanced Search 48
Policy Priority 49
Changing Policy Priority 49
Changing Messages Displayed to the Employee 50
Prompts Displayed on Workstations 50
Prompts Displayed on Terminals 53
Device Access Prompts 53
Function Access Prompts 54
Common Terminal Prompts 55
Prompts used for displaying Policy Details 56
Editing Global Prompts 58
Policy Print Settings 59
General Settings 60
Policy Print Settings 60
5
Toner Savings Settings 60
Estimated Cost Settings 61
Directory Services Settings 61
Known Limitations of Policy Print 63
Example Policies 63
Configuring Secure Release Here® 65
What is Secure Release Here? 65
Before You Start 65
Secure Release Here Terms/Concepts 66
Getting Started with Secure Release Here 67
Terminals 68
Terminal Properties 68
Settings 69
Copy Lines 70
Terminal Type Settings 70
Terminal Types 70
Adding New Terminals 70
Automatically Creating Terminals 71
Editing Terminals 71
Editing Copy Lines 71
Deleting Terminals 72
Duplicating Terminal Settings 72
Devices 74
Manually Adding New Devices 74
Device Model Information 75
Editing Devices 75
Secure Release Here Default Settings 75
Default Settings 76
6
Advanced 76
Changing the Default Settings 76
Changing the Default Print Group 76
Changing the Default Authentication Method 76
Secure Queues and Print Groups 77
Setting up Print Groups 78
Adding a New Print Group 78
Adding Managed Devices to a Print Group 79
Print Group Properties 80
Setting up Secure Queues 80
Creating a Queue 80
Secure Queue Configuration Tool 81
Securing Queues 82
Changing Print Groups During Use 83
Secure Release Here Settings 83
General Settings 83
Workstation Release Settings 84
Advanced Settings 84
Secure Release Here Example 85
Post Secure Release Here Configuration Checklist 86
Employee Identification 88
Identifiers 88
How Are Identifiers Used? 89
Reporting 89
User Display Name 89
Secure Release Here 90
Authentication Methods 90
Terminals 90
7
Tracker 90
Authentication Types 91
Standard Authentication Type 91
Permitted Logon Options 91
User Logon 92
Registration 93
Advanced Authentication Type 93
Managing Authentication Methods 93
Adding a New Authentication Method 94
Adding Standard Authentication Type 94
Adding Advanced (Script) Authentication Type 95
Editing an Authentication Method 96
Deleting an Authentication Method 96
Card Registration 96
Supported Scenarios 96
First time user 96
Replacement card for lost or damaged cards 97
Re-issued card 97
Setting up Card Registration 97
Enabling Card Registration 97
Card Format Rules 98
Multiple Card Format Rules 98
Managing Card Format Rules 99
Adding a Card Format Rule 99
Editing a Card Format Rule 99
Deleting a Card Format Rule 100
Configuring Card Format Rules 100
Validation Format Rules 101
8
Extraction and Transformation Format Rules 102
Extraction Example 103
Transformation Example 103
Configuring Publication 104
Publications 104
Automatic Daily and Monthly Publications 104
Viewing Publications Details 105
Details 105
Viewing Publication Log Files 106
Manually Publishing to the Data Warehouse 106
Data Warehouse Publication Settings 107
General 107
General 108
Daily Publication 109
Monthly Publication 110
Business Holidays 110
Business Times 111
Change Tracking 111
Enabling Employee Change Tracking 111
Managing Employee Change History 112
Configuring a Costing Model 113
What is a Costing Model? 113
Default Costing Model 113
Costing Model Examples 113
Example 1 114
Example 2 114
Getting Started with Costing Models 114
Adding a Costing Model 115
9
Configuring Cost Lines 116
Associating a Costing Model to Device(s) 117
Duplicating a Costing Model 117
Changing Costing Models associated to Devices/Models 118
Changing Costing Model associated to a Device 118
Changing Costing Model associated to a Model 118
Removing Devices from a Costing Model 119
Deleting a Costing Model 119
Configuring Pharos Systems' Site Monitor Lite 120
What is Pharos Site Monitor Lite? 120
Pharos Site Monitor Components 121
Installing Site Monitor 121
Site Monitor on Windows Server 2012 121
Pre-requisites 122
Supported Database Engines 122
Installing Pharos Site Monitor Administrator Only 122
Installing Core Services and Site Monitor Administrator 123
What's Next? 124
Launching Pharos Site Monitor Administrator 124
Site Monitor Administrator 124
How Pharos Site Monitor Works 125
Configuring Manual Device Discovery 126
Specifying Devices to Discover 127
Specifying an External File 127
Manually entering Device network information 128
Running Discovery Manually 128
Changing Discovery Schedule 129
Changing Collection Schedule 129
10
Configuring Scheduled Reports 131
About Scheduled Reports 131
Scheduling a Report 132
Testing a Scheduled Report 132
Viewing Scheduled Reports 133
Details 133
History 135
Email Content 136
Editing a Scheduled Report 136
Manually Generating and Emailing Scheduled Reports 136
Manually generating and emailing Scheduled Reports individually 136
Manually generating and emailing all the reports 137
Deleting a Scheduled Report 137
Customizing the Email Message of a Scheduled Report 138
Adding Multiple Recipients in a Scheduled Report 139
Changing the "Reply To" Email Address 139
Changing the "From" Email Address 140
Configuring Unauthenticated Print 141
What is Unauthenticated Print? 141
User Workflow 141
Getting Started with Unauthenticated Print 143
Configuring the Authentication Method for Unauthenticated Print 143
Enabling Unauthenticated Print from the Registry 144
Authentication Settings 145
User Authentication 146
User Authentication Dialog Text 147
Configuring Delegate Printing 148
What is Delegate Printing? 148
11
Releasing Delegated Jobs 148
Delegate Printing Components 149
User Workflow 149
Important Notes about Delegate Printing 150
Before You Start 150
Enabling Delegation for Secure Queues 150
Getting Started with Delegate Printing 151
Enabling Delegate Printing on the Delegator's Workstation 151
Disabling Delegate Printing 152
Adding/Assigning Delegates 152
Removing Delegates 153
Deleting Delegated Jobs 153
Configuring Pharos MobilePrint 154
Appendix: Authentication Scripts 155
Managing Authentication Scripts 155
Adding New Authentication Scripts 155
Editing Authentication Scripts 155
Testing Scripts 155
Scripting Introduction 156
Script "using" 157
Script "namespace" 157
Script Entry Point 158
Script Authenticate 158
Scripting Objects 160
Identity 160
IdentityItem 161
Inputs 161
Scripting Helper Functions 161
12
UserIdAndPassword 161
IdentityProvider 162
LdapUtils 162
LdapSearchResult 162
13
Configuration Guide Introduction
Introduction
About this Document
This document covers topics related to the configuration of the different applications that are available
with Blueprint Enterprise.
Other Documentation
For a full list of documentation for Blueprint Enterprise, please refer to the "Blueprint Available
Documentation" document contained on the Blueprint disk image in the Documentation folder.
Getting Help
In the event you have questions or encounter issues during or after your installation of Blueprint
Enterprise, help may be obtained from the Pharos website or by contacting us directly, as shown below.
Pharos Website
The Pharos website (www.pharos.com) contains information about our products, including product
updates, fixes and firmware releases. It also includes the Pharos Knowledge Base, which provides a
comprehensive source of solutions and workarounds to known problems and issues. It also provides you
with configuration examples. The Knowledge Base is updated often to provide current information.
Contact Details
Corporate Headquarters Post-Sales Technical Assistance
Email: support@pharos.com
(585) 888-864-7768 (toll free
Phone:
US/Canada) North America:
(585) 939-7000
Fax: (877) 848 0397 (toll free)
(585) 249-9229
(585) 939-7099
Address: Suite 310
80 Linden Oaks Australia/New Zealand:
Rochester, New York 14625 +64 9 523 0737
United States of America
Rest of the world:
+1 (585) 939-7099
14
Configuration Guide Managing Logons
Managing Logons
Logons specify the network logon details or user name/password combinations that can be used to
access Blueprint Administrator. It also denotes what the account can do as detailed below.
You can create and manage the accounts who are authorized to log on and use the Blueprint
Administrator on the Dashboard > Logons screen.
Types of Logons
When creating a logon, you can select what the account can do:
l Administrate Blueprint Enterprise - The logon account will have access to all the screens of the
Blueprint Administrator and can perform all the administration tasks.
l Reports Only -This enables the logon account to report Blueprint data without granting the ability
to administer Blueprint. Only the Reports screen will be available to the user.
The Logons screen is available only in the Analyst; it is not available in the Collectors.
Logon Models
The Blueprint Administrator supports two logon models:
l Use Domain Authentication – with this model, you will need to specify a username and domain
when creating a logon. On startup, the Blueprint Administrator retrieves the domain and username
of the employee that is currently logged on to Windows. If that information matches a Blueprint
logon entry, the employee will be logged on to the Blueprint Administrator with no further
prompts.
l Use Password Authentication – with this model, you will need to specify a username and
password when creating a logon. This is not related to the employee’s domain account. If the
Blueprint Administrator cannot log on the employee using domain authentication (see above), it
will prompt the employee to enter a username and password. The employee must enter a
username and password that Blueprint Administrator recognizes.
Adding Logons
A default logon account called 'pharos' is created when Blueprint Administrator is installed. All other
logons must be added manually.
To add a new logon:
15
Configuration Guide Managing Logons
1. Click the Add Logon button on the Dashboard > Logons screen toolbar. A new logon account
appears in the main list.
2. Enter the User Name for the new logon.
3. Select the appropriate function for the logon.
l Administrate Blueprint Enterprise
OR
l View Blueprint Reports only

4. Select Use Domain Authentication or Use Password Authentication.
l If the new logon uses domain authentication, enter the domain that the user name
will be authenticated against.
l If the new logon uses password authentication, enter a password for the user name.
The password must be entered twice for confirmation. Passwords must be at least six
characters long.
5. Click Apply. (If you click away from the new logon record before applying the new details, you are
prompted to save the changes to the new logon.)
Once created, logon details can be edited on the Logon Details tab, with the exception of the user name,
which is read-only.
The only way to change a logon's name is to delete it and create a new one.
Deleting Logons
To delete a logon, select the logon you want to delete and click Delete on the Logons screen toolbar.
The default logon account "pharos" cannot be deleted.
16
Configuration Guide Enabling Health Notification Emails
Enabling Health Notification Emails

Blueprint Enterprise regularly checks the system health, and can be configured to send notification emails
when a new alert occurs. You will need to configure the email notification settings to receive these
notifications.
To ensure that email notifications are sent, you must first configure the SMTP Server details (e.g.
ports, server name) at the Server > Settings screen.
To enable email notifications:
1. Open the Dashboard > Health Settings screen on the Analyst.

2. In the System Health Email Notification section, specify the following details:
a. Email address to send notification messages to
b. Whether or not to notify Pharos Support - if this box is ticked, a copy of each notification
email will be sent to support@pharos.com, which will allow Pharos Systems support staff to
aid in diagnosing the problem if their help is required.
For more information about system health and status messages, please refer to the “Blueprint Operation
Guide” found in the Blueprint disk image.
17
Configuration Guide Configuring Data Imports
Configuring Data Imports

Depending on how you are using Blueprint Enterprise, it may be necessary to include data from external
sources, in addition to the data collected by the Blueprint components. This data can include HR
information and Budget Center information. Several methods exist for integrating external data with
Blueprint Enterprise.
Blueprint Enterprise is extensible, making it simple to add new file types for other types of data (e.g. site-
specific HR data) to be imported from external sources. Contact Pharos Systems for information on how
to add new file types to your system.
Data Feeds
Data can be imported on a regular basis from external feeds such as HR feeds, giving information on
employees.
To use data feeds, a custom integration solution must be set up to meet the needs of your particular
organization. The integration defines the format of the import file and how the data will be used. In
addition, the integration can be configured to monitor a specific folder – any time a new import file
appears in that folder, it is automatically imported.
Contact Pharos Systems prior to installation for information on requesting and implementing a custom
integration for data feeds. When a custom integration is supplied, the integration will include the
necessary instructions for applying it to your Blueprint installation.
Importing Files Manually

Data can be imported manually from the Integrations > File Importer screen of Blueprint Administrator.
To import a file:
1. Click the Import File button on the toolbar of the Integration > File Importer screen. This opens
the Choose a file to import dialog:
2. Select the correct data type for the file you are importing.
3. Enter the name of the file to import, or click the button to locate it.
18
4. If you are re-importing data that already exists in the Blueprint database, and you want the new
data to overwrite the old data, check the Force Reimport box. If this box is not checked, Blueprint
will refuse to import any file that has already been imported.
5. Click OK.
The file is imported. The status of the import, including any errors that may occur, is displayed on the
main File Importer screen.
Supported Import File Encoding

In order to support the import of data in all languages, text files imported via the Integrations > File
Importer screen in the Blueprint Administrator must be encoded in one of the following formats:
l Unicode (UTF-16) with a Byte-Order-Mark (BOM)

l Unicode (UTF-16) without a BOM
l UTF-8 with a BOM
If you need to import files that use a different encoding, please contact Pharos Systems.
Standard Import File Types

By default, Blueprint Enterprise can only import the following file types:
l Collector Data - data from a Blueprint Collector, containing print job transaction data recorded by
the Tracker component.
l Human Resource Data - a Comma Separated Variables (CSV) file containing information used to
create or update employee records.
l Identifier Translation Data - a CSV file containing information used to map identifiers to each
other.
l Model Cost Data - a CSV file used to modify the Costing Model for existing model entries.
l Model Data - a CSV file containing information used to create or update model entries. It can also
be used to update the Costing Model for existing Models.
l Site Monitor Device Data - data from Site Monitor, containing device information and device
meters.
If a custom data feed integration is installed, it will appear as a valid file type in the File Importer screen.
This will allow you to perform manual data feed imports if necessary.
It is recommended that you do not modify the existing importconfig files because the changes will
be lost on an upgrade.
However, If it is necessary to make changes to the importconfig files, follow these steps:
1. Save a copy of the relevant importconfig file with a new name.

2. Update the ImportDescription value in the new file.
3. Make any other required changes.
4. Run the following command line from within the Blueprint\bin directory:
19
%SYSTEMROOT%\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe
/ImportConfig=<TheNew>.importconfig
PharosSystems.Blueprint.Utilities.ImportHelpers.dll
When importing a file in a foreign language, ensure that the filename appears correctly. If the
filename contains foreign characters that the OS does not support, the file will not import.
Importing Employee Data

Data on employees and the methods used to identify them can be imported from the File Importer
screen under the Integration section. Data is imported as a comma-separated variables (CSV) file. The
expected format of the CSV files imported is detailed below.
Importing Human Resource Data

Human Resource Data for employee records is imported from a CSV file containing one employee record
per line.
The importer expects a single header line as well - if a header is not included, the first line of data will be
treated as the header and ignored.
Each line must contain the following comma-separated fields:
l IdentifierType
l IdentifierData
l FullName
l EmailAddress
l PhoneNumber
l UserCustom1
l UserCustom2
l UserCustom3
l UserCustom4
l UserCustom5
l BudgetCenterName
l BudgetCenterDescription
l DepartmentGroupName
l DepartmentGroupDescription
l BuildingName
l Country
l State
l City
l PostalAddress
l PostalCode
l BuildingCustom1
l BuildingCustom2
l FloorName
20
l FloorCustom1
l FloorCustom2
l RoomName
l RoomCustom1
l RoomCustom2
l LocationGroupName
l LocationGroupDescription
l FromIdentifier (optional)
l Position
l EmployeeType
l Manager
For the meanings of these fields, see the descriptions of the properties as they appear on the Employees
screen. IdentifierType is an integer value that specifies the type of identifier entered for the IdentifierData
field. This must be one of:
l 0 = Employee
l 1 = Network
l 2 = Card
The optional FromIdentifier Field allows you to perform limited identifier translation (see below) as part of
the HR import.
Importing Identifier Translation Data

It is possible for employees to use multiple identifiers when printing jobs. For example, they may submit
jobs from their workstations using their network ID and also release jobs from a terminal using a card
swipe, or they may have multiple network IDs for use in different systems. Each different identifier will be
logged as a different employee record, unless Blueprint is provided with information that maps (or
"translates") all the identifiers for a single employee to each other.
Identifier translation data for employees is imported from a CSV file containing one translation per line.
l FromType
l FromIdentifier
l ToType
l ToIdentifier
FromType and ToType are integer values that specify the type of identifiers specified:
l 0 = Employee
l 1 = Network
l 2 = Card
Example:
1,Johnsmith,0,jsmith123
1,Johnsmithadmin,0,jsmith123
2,1234567890123,1,Johnsmith
21
This file maps the Network identifiers Johnsmith and Johnsmithadmin to the Employee identifier
jsmith123 - a print job reported with either of these identifiers will be recorded against jsmith123.
It also maps the Card identifier 1234567890123 to the Network identifier Johnsmith, which in turn maps to
jsmith123 - print jobs reported with this card ID will also be recorded against jsmith123.
Importing Model Data

Data on models and Costing Models can be imported from the File Importer screen under the Integration
section. Data is imported as a comma-separated variables (CSV) file. The expected format of the CSV files
imported is detailed below.
Importing Model Data

Model data is imported from a CSV file containing one model per line.
l Model Name
l Manufacturer Name
l Model Name Short
l Device Type - must be an integer between 1 and 7 ; possible values are listed below:
1 = Printer
2 = Copier
3 = Fax
4 = MFD
5 = Plotter
6 = Scanner
7 = Other
l Device Technology - must be an integer between 1 and 5 ; possible values are listed below:
1 = Dot Matrix
2 = Inkjet
3 = Laser
4 = Analog
5 = Other
l Duplex Supported (Boolean - must be "true"/1 or "false"/0 )
l Color Supported (Boolean - must be "true"/1 or "false"/0 )
l Introduction Date (Date must be in the format yyyy-mm-dd)
l B&W Pages Per Minute
l Color Pages Per Minute
l Duty Cycle
22
l Costing Model
l Monthly Target Volume
For the meanings of these fields, see the descriptions of the fields as they appear on the Models screen.
Values must be given to all the field columns except for the 'Costing Model' and the 'Monthly
Target Volume'. If no Costing Model is specified, it will automatically use the 'Default' Costing
Model.
Importing Model Cost Data

You can assign/associate Costing Models to existing Models via the File importer screen. Costing Model
is imported from a CSV file (using Model Cost Data type) containing one model per line.
The importer does not create new Costing Models. Make sure that the Costing Model defined in
the file import is already added and configured in the Reporting > Costing Model screen before
importing Model Cost Data.
l Model Name
l Manufacturer Name
l Costing Model
For the meanings of these fields, see the descriptions of the fields as they appear on the Device
Management > Models screen. The Model Name and Manufacturer Name are mandatory fields. They
should exactly match the manufacturer and name of the model you want to update.
If a Costing Model is not specified, the 'Default' Costing Model will automatically be assigned to a
Model.
23
Configuration Guide Configuring Collector Exports
Configuring Collector Exports

The data gathered at the Collector must be exported on a regular basis for transmission to an Analyst
server. Data is exported to the PharosSystems\Blueprint\Exports directory on the Collector. From here it
can be transferred to the Analyst server, either manually or automatically.
Automatic Collector Exports

When running Blueprint Administrator on a Collector, you can configure the Collector to automatically
transfer data and to set the time (in minutes) of data transfer.
To configure automatic transfers:
1. Open the Blueprint Administrator on the Collector server.

2. Open the Collector > Settings screen.
If you did not specify the Analyst’s server name during the Collector installation, you must do that
now on the Servers > Settings screen.
3. Check the Export enabled check-box.

4. On the Collector > Settings screen, you can also change:
a. The number of days between transfers. Typically, it is recommended to leave this setting to
1.
24
Configuration Guide Configuring Collector Exports
b. The time of day the transfer should occur. This should be after the Print Job Batching time
window specified for the Trackers on this Collector. You can check the Print Job Batching
settings on the Tracker > Settings screen. For more information, refer to the “Installing the
Tracker Component” section of the “Blueprint Installation Guide”.
5. Click Apply.
Manual Collector Exports

Blueprint Enterprise also allows you to manually transfer Collector data to the Analyst. This is useful when
you are testing Blueprint Enterprise and need to review data more frequently than once per day.
To manually transfer Collector data:
1. Open the Blueprint Administrator on the Collector server.

2. Open the Collector > Statistics screen.
3. Click on the Export button to create a new Collector data file ready for transfer. This will include all
data that the Collector has received since the last export.
4. Click on the Transfer All button. This will send all waiting Collector files to the Analyst.
5. Once the files have been transferred to the Analyst, it will queue the files for import. You can check
the status of the file imports by viewing the Integration > File Importer screen of Blueprint
Administrator (on the Analyst).
25
Configuration Guide Renaming Collector Servers
Renaming Collector Servers

If a Collector server is renamed, the rest of the Blueprint system must be notified. To update Blueprint
with the Collector's new name, you must run the Server Configuration Tool from the command line, with
the following option specified:
PharosSystems.Core.ServerConfiguration.exe /serverrenamed
If you open the Server Configuration tool normally after changing a server's name, the tool will detect this
and prompt you to correct the issue. Clicking "Yes" updates Blueprint as if the /serverrenamed option had
been used. Clicking "No" closes the Server Configuration tool - you will be prompted again the next time
you open it.
A second command line option, /servercloned, updates Blueprint with a server's new name, and
generates a new unique machine identifier for it. This option is used when Collectors are cloned
from a common image. See the "Blueprint Planning and Installation Guide" for more information
on cloning Collector servers.
26
Configuration Guide Configuring Policy Print™
Configuring Policy Print™

This section guides you through the basic concepts of Policy Print and how to set up and configure Policy
Print in Blueprint Enterprise.
This section covers the following topics:
l What is Policy Print?

l Before you Start
l Configuration Interfaces
l Getting Started with Policy Print
l Managing Policies
l Managing Rules
l Managing Triggers
l Blueprint Built-in Triggers
l Defining Complex Trigger Expressions
What is Policy Print?

The Policy Print™ application of Blueprint Enterprise enables you to easily deploy and manage enterprise-
wide printing and copying policies to the employees in your organization. If they attempt to print a job
that violates a rule of one of their policies, a simple and easy to understand message is displayed
providing more information about the policy.
Policy Print also allows you to create policies that can control access to copy, fax and scan functions of
your MFPs.
Below are examples of rules that can be applied to a policy:
l Prevent employees from printing documents in color.

l Prevent employees from printing jobs larger than 20 pages.
l Inform employees of the cost of their printing job.
l Warn employees against printing a web page in color.
l Prevent a group of employees from accessing copy, fax and scan functions.
Policy Print informs employees of the cost of their print jobs and offers alternative options on how they
can help reduce costs and generate less waste. This helps change employee behavior towards responsible
printing practices and it also establishes an accountability-based culture.
Blueprint Enterprise can also generate reports of the activities that arise from policy enforcement
including when an employee overrides a policy.
For more information about Policy Print and how it works, please refer to the “Blueprint Product
Specification”.
27
Before You Start

Blueprint Enterprise must be installed before setting up Policy Print. Before going further, you should
have:
l Installed Blueprint Analyst;

l Installed Blueprint Collectors as necessary. These Collectors must be registered with the Analyst
(i.e. the Collector must appear on the Server > Servers screen at the Analyst);
l Deployed workstation Trackers to the target workstations; and
l Verified that Policy Print is enabled on your current license.
For more information on installing Blueprint Enterprise, please refer to the “Blueprint Planning and
Installation Guide”.
Configuration Interfaces
You can configure the Policy Print application from the Policy Print section in the Blueprint Administrator.
This is where you create, view, modify, and delete your policies.
You can also create a profile for the level of toner savings, if you have the Toner Savings feature installed.
For more information, please contact Pharos Systems support.
l The Settings screen contains the General and the Directory Services settings. For more
information,Refer to the "Policy Print Settings" section on page 59.
l The Policies screen is used to set up policy configurations, such as adding rules, creating triggers,
configuring prompts, and setting the policy priority. It also displays the list of all the existing policies
including Blueprint built-in policies (No Restrictions, Go Green, Get Green and Default). This is also
where the toner savings profile is configured.
28
l The Application Toner Savings screen is used to enable and disable application based toner
savings. In addition, you can also specify the applications savings mode for each application.
The Toner Savings tab on the Policies screen and the Application Toner Savings screen are only
available when you have a license for the Toner Savings feature of Blueprint Enterprise. Application
Toner Savings is a separately licensed component of Blueprint Enterprise. Please contact Pharos
Systems for more information about this feature.
Getting Started with Policy Print

After you have installed Blueprint Enterprise, you need to enable Policy Print in the Analyst Administrator
(please refer to the "Policy Print Settings" section on page 59. With Policy Print enabled, you can now start
adding policies.
Start the Pharos Blueprint Administrator, go to the Policy Print > Policies screen, and follow these steps
to configure a Policy Print environment.
1. Add a policy. Add a Policy Name and a description to your policy. For more information, Refer to
the "Adding a Policy" section on page 31.
2. Add one or more rules. Add a rule or set of rules to the policy. For more information, Refer to the
"Adding a Rule" section on page 33.
3. Add one or more groups. Assign the groups that should have this policy applied. For more
information, Refer to the "Assigning Groups" section on page 47.
4. Change policy priority (optional).Modify the order in which policies will be prioritized and applied
to employees that are in more than one group. For more information,Refer to the "Changing Policy
Priority" section on page 49.
Policy Components
A policy is comprised of a number of components: groups, rules, and priority. In order for Policy Print to
work, all these components have to be properly configured.
A policy consists of one or more rules and a rule consists of one or more trigger conditions. When the
trigger conditions are met, the rule action is executed and a prompt is displayed. A policy has a list of
groups that it applies to. It also has a priority relative to other policies.
29
Policy components
The following table describes each of the policy components.
Component Description
Group Identifies the group of employees that the policy will be applied to.
Defines the set of conditions that will be implemented for a given policy. A policy can
Rule have one or more rules assigned to it.
A rule is made up of the following components: Trigger, Action and Prompt .
Defines the relative priority of a policy. Employees may belong to more than one
group and may therefore be assigned more than one policy. In this case, the policy
Priority
with the higher priority is used. By default, the No Restrictions policy has the highest
priority and the Default policy has the lowest priority.
Blueprint Default Policies

Blueprint Enterprise comes with three default policies – No Restrictions, Default and Go Green, Get
Green.
l The No Restrictions policy does not have rules associated with it and marks a user as being
exempted from policy enforcement.
l The Default policy is automatically assigned to groups who are not explicitly assigned a valid policy.
l The Go Green, Get Green policy is made up of a number of Inform and Warn rules.
The list below summarizes the built-in rules for Go Green, Get Green policy:
30
l Warn employees of Color print jobs that exceeds $5

l Warn employees of Color Printing from Internet Explorer
l Warn employees of Color Printing from MS Outloook
l Warn employees of Local Print job that exceeds 5 pages
l Warn employees of Print jobs over 50 pages
l Inform employees to consider printing documents 2-sided (duplex) to reduce waste and save
money.
The No Restrictions policy cannot be modified but the Default policy can. The Go Green, Get
Green policy can be modified or deleted.
Managing Policies
As well as displaying the details of all the available policies, the Policy Print > Policies screen allows
policies to be managed.
Adding a Policy
As well as displaying the details of all the available policies, the Policies screen allows new policies to be
created and existing policies to be edited or deleted.
To add a policy:
1. Click the Add Policy button on the Policies screen toolbar

2. Enter a name and a description for the policy the Policy Details.
3. Click Apply. Check that the policy has been created and appears immediately above the “Default”
policy.
These steps only add a policy name and a policy description. To create a fully functional policy, you have
to add rules and assign one or more groups to which the policy applies. It may also be necessary to
modify the policy priority. Refer to the "Policy Priority" section on page 49.
Editing a Policy
The policy name and description can be edited directly from the Policy Print > Policies screen. The
following instructions show how to edit the name and description of a policy.
To edit policy details:
1. Select the policy you want to edit.

l To edit the name of the policy, type a new name in the Policy field.
l To edit the description of the policy, type a new description in the Description field.
2. After the policy details have been changed, click Applyat the bottom of the screen to save changes.
Alternatively click Cancel to cancel your changes. If you click away before applying the new details,
you are prompted to save the changes to the policy.
For information on how to edit rules of a policy, please refer to the "Editing a Rule" section on page 34.
31
Deleting a Policy
The policy can be deleted directly from the Policy Print > Policies screen of the Blueprint Administrator.
To delete a policy:
Select the policy you want to delete, and click the Delete button on the Policy Print > Policies screen
toolbar.
When you delete a policy, all the rules are deleted, and groups are no longer assigned to this policy. Take
note that once you have deleted a policy, this operation cannot be undone.
The “No Restrictions” and the “Default” policies cannot be deleted.
Rules
A rule specifies a set of conditions that applies to a policy. Each policy can have one or more rules assigned
to it with each rule defining a set of trigger conditions, an action to take, and a prompt to display.
Below are examples of rules that may be applied to a policy:
l Deny color printing

l Deny jobs larger than 20 pages
l Inform employees of the cost of their printing job
l Warn employees against printing a web page in color
Rule Components
A rule consists of a trigger, an action and a prompt. The following table describes the different
components of a rule.
A trigger specifies when a rule should be applied. It consists of a set of functions

(print/copy/fax/scan) to which the trigger applies, an expression that defines what
Trigger conditions will cause the rule to be applied, and a name which identifies the trigger.
For more information about triggers, Refer to the "Triggers" section on page 35.
32
Used to define the actions to take when the rule is triggered. Available actions are
Action Deny, Warn and Inform.
For more information about the Action(s), Refer to the "Action" section on page 44.
Used to define the text to be displayed to the employee on the notification dialog
when the rule is triggered.
Prompt
For more information about rule prompts, Refer to the " Prompts" section on page
45.
Getting Started with Rules

After adding a policy, the next step is to create the rules for the policy using the Rule Editor. When you
create a rule, you must do the following:
l Create a trigger or select a trigger from the list of triggers built into Blueprint Enterprise.
l Select an action. The action is what you want the rule to do when the rule is triggered.
l Create a prompt. The prompt is the message that will be displayed to employees when the rule is
triggered.
Managing Rules
You can add, edit and delete rules on the Rules tab in Policy Print > Policies screen.
Adding a Rule
After adding a policy, the next step is to define the rules of the policy.
To add a rule:
1. In the Policy Print > Policies screen, select the policy to which you want to add the new rules.
2. Click the Rules tab under Policy Details.
3. Click the Create button. The Create a New Rule dialog screen appears.
33
3. Select an appropriate trigger in the When the conditions for the selected trigger are met: field. Do
one of the following:
l Select one of the built-in or previously created trigger conditions.
OR
lCreate a new trigger. For more information, please refer to the "Adding a Trigger" section on
page 40.
4. In the Apply the following action field, select an action to apply. The available options are Deny,
Inform and Warn.
5. In the And display the following prompt field, type an appropriate prompt(e.g. “The use of color
is not permitted”).
6. Click OK to create the rule. The rule will be created and added to the selected policy.
Editing a Rule
You may want to change the trigger, action or prompt that applies to a particular rule. The Policy Print >
Policies screen allows new rules to be created and existing rules to be edited or deleted.
Rules are edited at the Analyst and replicated to Collectors as they are needed.
To edit a rule:
1. In the Policy Print > Policies screen, select the policy you want to edit.
2. Click the Rules tab under Policy Details. A list of all the rules belonging to the policy appears.
3. In the Rules list, select the rule that you want to edit and click the Edit button. The Edit Rule
Details dialog box appears.
4. Perform the necessary changes
l To edit the trigger, please refer to the "Editing a Trigger" section on page 40.
l To change the action, select the appropriate action in the "Apply the following action"
combo box.
l To change the prompt display, type the new prompt in the "And Display the following
prompt" field.
5. Click Apply and Close.
Deleting a Rule
Policy Rules can be deleted in the Policy Print > Policies screen of Blueprint Administrator.
To delete a rule:
1. In the Policy Print > Policies screen, select the policy from which you want to delete the rule(s).
3. In the Rules list, click the rule that you want to delete from the policy and click Remove.
34
4. Click OK on the confirmation dialog box.
This action cannot be undone.
Triggers
A trigger specifies when a rule should be applied in a policy and consists of the following:
Used to identify the trigger and is displayed to employees on the policy details
Name
dialog.
Used to define the role (Print/Copy/Fax/Scan) to which the trigger applies.

When selecting a function, you will only see the conditions that apply to the
selected function.
Function For example, if you selected just the Print function, you will see all the trigger
conditions in the Trigger Editor. If you selected just the Copy function, the
trigger conditions that you will see are Document Contains Color, Document
Output Time, and Function.
Expression Defines the conditions that will cause the rule to be applied.
Policy Print has a set of trigger variables that are commonly useful, such as job contains color, total
number of pages, number of color pages, device connectivity (e.g. how is the device connected – locally
35
attached versus on the network), job name, job cost, printer driver, printer name, printer location, and
printer comment.
Triggers can be reused across multiple policies.
Blueprint Built in Triggers

The following table summarizes the list of built-in triggers that come with Policy Print. These triggers can
be modified or deleted.
Trigger Name Conditions
Color print job costs over If the estimated cost of the document is greater than $5.00 AND if the
$5 document contains color.
Color printing from

If the document contains color AND if the document name matches http*
Internet Explorer
Color Printing from If the document contains color AND if the document name contains
MS Outlook Microsoft Outlook
Local print job exceeds 5 If the device is a printer connected directly to the employee’s workstation
pages AND if the total number of pages is greater than 5.
Print job over 50 pages If the total number of pages is greater than 50.
If the device is a printer on the network or hosted on a print server AND if

the document is simplex (i.e. will print single-sided)
Single sided printing to
network printers, unless Unless the document name matches "Microsoft Excel*'
from MS Excel or the document name matches "*.xls"
or the document name matches "*xlsx"
Trigger Conditions
The table shows the list of trigger conditions that can be used to define the trigger’s expression. All of
these conditions are supported by the Print function.
l For the Copy function, the supported conditions are: Document Contains Color, Document Time
and Function.
l For the Scan and Fax functions, the supported conditions are: Document Time and Function.
36
Trigger Conditions Description
This condition uses the application name of the submitted print job as a
trigger. This allows you to create policies based on the application name of a
print job e.g. Outlook, Lotus Notes, Firefox, etc.
For example, you want to prevent employees from printing from MS Outlook.
Application Name You can set up a rule with the trigger expression "The application name
matches "outlook.exe" and the rule action "Deny".
This condition can be created using wildcard match, regular expression match
or case-sensitive exact match. For more information and examples, Refer to
the "Text Matching Modes Used in Trigger Conditions" section on page 42.
This condition uses the device connection as a trigger condition. The options
are:
l If the printer is connected directly to the user’s workstation

l If the printer is connected to the network or hosted on a print server.
Device Connectivity
For example, you want to prevent employees from printing high-volume print
jobs on desktop devices. You can set up a rule where the trigger expression is
“If the printer is connected directly to the user’s workstation” and the rule
action is set to “Deny”.
This condition is used to specify a trigger condition using the color criteria of a
printer. The options are:
l If the document contains color

Document Contains l If the document does not contain color
Color
For example, you want a rule that restricts a certain group of employees from
printing color web pages, you can define the rule as:
If the document contains color AND if the document name contains http*
This condition is used to define the number of color pages as a trigger. The
trigger expression is as follows:
If the number of color pages is <operator> <value>, where the <operator> can
be any of the following and where <value> is a number from 0 to
2,147,483,647.
Document Color pages
l Greater than
l Greater than or equal to
l Equal to
l Less than or equal to
l Less than
37
For example, you can impose a rule that restricts printing if the number of
color pages is greater than 10.
This uses the estimated cost of the document as a trigger condition (e.g.
Document Estimated Document Estimated Cost is greater than $5.00).
Cost For more information about estimated cost settings, Refer to the "Policy Print
Settings" section on page 59.
This uses the document name or part of a document name as a trigger. Policy
Print uses the print job name rather than the file name as the Document
Name.
Document Name This condition can be created using these modes of text matching - wildcard
match, regular expression match or exact match. For more information and
examples about using text matching,Refer to the "Text Matching Modes Used
in Trigger Conditions" section on page 42.
Used to define whether a printer is requested to automatically print on both

sides of the paper or not. This condition can be set to either simplex or duplex.
l If the document is simplex (prints single-sided).

l If the document is duplex (prints double-sided).
Document Duplex
For example, you want to create a rule encouraging employees to always print
double-sided instead of single-sided. You can have a “Warn” rule where your
trigger expression is:
If the document is simplex (i.e. will print single-sided).
This is used to specify a certain time criteria to trigger the rule. For example,
you want to prevent employees from printing outside office hours (e.g. before
8 a.m. and after 6 p.m.). You can create a “Deny” rule with the following trigger
conditions:
If the Document Output Time matches certain criteria
Monday to Friday
Document Output Time Start Time 8:00 am
End Time 6:00 pm
This means that employees will not be allowed to print before 8:00 a.m. or
after 6:00 p.m. or on Saturday or Sunday.
Print rules apply both at print time and release time when a print job is sent to
a Secure Queue. Policies are applied at the time the employee prints at the
38
workstations and are applied again when the employee releases the print jobs
from the terminals or iMFPs. However, policy messages are shown to the
employees only at print time and not at release time. The release time results
are only used for reporting purposes.
For example, you have a rule that denies color printing after office hours. The
employee submits a color print job to a secure queue during office hours. The
job will not be denied because the job is submitted within office hours. If the
employee decides to release the documents outside of office hours, the job
will then be logged as a violation but the employee will be able to print the
document.
This condition defines the total number of pages in the print job (e.g.
Document Total pages greater than 10).
Document Total Pages
The total number of pages is based on the number of pages that will physically
print, not the number of pages in the original document.
This defines the device function. The Function conditions are:
Function l If the user is attempting to print a document

l If the user is attempting to copy a document
l If the user is attempting to fax a document
This condition uses the printer name (Windows print queue name) to define a
trigger. For example, you can deny employees from printing to a certain
Printer Name printer by specifying the condition:
Printer name matches "Printer1".
Uses the location of a printer as a trigger. The location is retrieved from the
Printer Location
Windows queue.
Uses printer comments as a trigger. The comments are retrieved from the
Printer Comments
Windows queue.
Uses the printer driver name as a trigger. The print driver name is retrieved
Printer Driver Name
from the Windows queue.
Managing Triggers
The Policy Print > Policies screen allows new triggers to be created and existing triggers to be edited or
deleted.
39
Adding a Trigger
You can add triggers to a rule on the Policy Print > Policies screen of the Administrator.
To add a trigger:
1. In the Policy Details section, select the Rules tab and then click the Create button. This opens the
"Create a new Rule" dialog.
2. In the Create a New Rule dialog, select Create New under "When the conditions for the selected
trigger are met". The Create a new Trigger dialog appears.
3. In the Trigger field, type a descriptive name for the trigger.

4. Under Functions that this trigger applies to, check the function(s) you want the trigger to apply
to. The options are Print, Copy, Fax and Scan.
5. To add a condition to the Trigger If part of the expression, click on the Trigger If text. For more
information on how to define trigger expressions, please refer to the "Defining Complex Trigger
Expressions" section on page 41.
6. To add a condition to the Unless part of the expression, click on the Unless text.
7. With the correct part of the expression selected, select and double-click the condition from the
Conditions list that you want to use. This shows the Edit Condition dialog.
8. Define the condition and click OK. Notice that a new expression has been added under Trigger if.
Editing a Trigger
To edit a trigger:
40
1. In the Policy Print > Policies screen, select the policy you want to edit.
2. Click the Rules tab under Policy Details. A list of all the rules belonging to the policy appears.
3. In the Rules list, select the rule that you want to edit and click the Edit button. The Edit Rule
Details dialog box appears.
4. You can now edit the trigger associated with that rule. Click the Edit button beside the trigger
name. Make the appropriate changes (e.g. change function and conditions). For more information
about trigger conditions, please refer to the "Trigger Conditions" section on page 36.
5. Click Apply and Close to save.
Defining Complex Trigger Expressions

Multiple Trigger Conditions
Policy Print allows you to create complex trigger expressions. For instance, you can create trigger
expressions with multiple trigger conditions. The following example shows a trigger expression with more
than one trigger condition that are linked by the operator AND.
Trigger if
The device is a printer connected directly to the user’s workstation

and the document contains color
and the number of color pages is greater than 10.
In this example, the trigger will only fire when all of the conditions are true.
Using the "Unless" Condition

You can also create trigger conditions that can define exceptions to the rules by using the “unless” control
statement in the trigger editor. Consider the following example:
Trigger if
The device is a printer on the network or hosted on a print server
and the document is simplex (i.e. will print single-sided)
Unless
The document name matches "Microsoft Excel*'
or the document name matches "*.xls"
or the document name matches "*xlsx"
Essentially, the “Unless” part of the expression is equivalent to “if not”. In the example above, the trigger
will fire only if the following conditions are true:
l the document being printed is sent to a device on the network or hosted on a print
server
41
l the document is single-sided

l the document name does not contain “Microsoft Excel”
l the document name does not contain “.xls”
l the document name does not contain “.xlsx”
Text Matching Modes Used in Trigger Conditions

Policy Print provides flexibility in defining trigger conditions by using the following text matching options.
l Wildcard matching
l Regular Expression matching
l Case-Sensitive Exact matching
The Application Name, Document Name, Printer Name, Printer Location, Printer Comments and Printer
Driver Name trigger conditions use these text matching options in defining trigger expressions.
Wildcard Matching
This is the simplest type of matching available and this option is what you would normally use. Wildcard
Matching is used to compare a pattern with a text string. You can use the following Windows wildcard
characters in defining trigger expressions:
l * (asterisk) which represents zero or any number of characters.

l ? (question mark) which represents a single character.
In the following examples the trigger condition Document Name is used to show how the different text
matching modes can be used to define Policy Print rules.
Example 1:
You want to create a Deny rule where users are not allowed to print Internet files. You can set a rule with
the trigger expression
Document Name matches http*.
This expression would match any document starting with the string “http”.
Example 2
Different software applications differ in the way they form print job names (which is used as the
Document Name). For example, a Microsoft PowerPoint document may have one of the following print
job names:
l Microsoft PowerPoint – Presentation1

l Microsoft PowerPoint – Presentation1.pptx
l Microsoft PowerPoint – Presentation1.ppt
You want to prevent users from printing PowerPoint presentation documents. Using a wildcard match,
you can create a trigger
42
Document Name matches *.ppt*.
This trigger condition will match all files with the extension name ending in ppt, pptx, pptm or ppts. This
trigger condition is only applicable if you are certain that your print job name includes the extension name
of your file.
Example 3
Given the same scenario as the second example, you can also use a wildcard match where the trigger
condition is set to:
Document Name matches Microsoft PowerPoint*.
This condition will match all print job names starting with Microsoft PowerPoint.
Regular Expression Matching

Regular expression matching can deal with more complex patterns than the wildcard match. This type of
matching provides you with more flexibility in configuring your trigger conditions.
The special characters * and ? used in wildcards do not have the same meaning in regular expressions.
l To represent zero or any number of characters, wildcard matching uses star (*) while regular
expression uses dot star (.*).
l Question mark (?) is used to represent a single character in wildcard matching while the dot (.) is
used for regular expressions.
Example 1
You want to create a trigger condition denying a group of users from printing documents where the print
job name has either the words "Accounting" or "Billing". You can create a trigger expression using the
condition variable Document Name.
The following trigger expression will match any filenames containing the words “accounting” or “billing”.
Document Name matches “Accounting|Billing”
This expression will match the following examples (assuming that the case sensitive checkbox is not
ticked):
l Accounting
l accounting
l Accounting2
l Summary-accounting
l Accounting Summary
l BP_Accounting1
l Billing
l Summary_billing
l Billing_summary
Example 2
43
You want to deny a group of users from printing documents where the filename starts with "Accounting".
You can create a trigger expression using the condition variable Document Name.
Document Name matches ^Accounting
This trigger expression will match any filename that starts with the word Accounting. This expression will
match the following examples (assuming that case sensitive checkbox is not ticked):
l Accounting
l Accounting2
l Accounting Summary
l AccountingDocument
Policy Print provides you with the option to enable Regular expression case sensitivity. Tick the case
sensitive checkbox to enable case sensitivity.
Refer to a regular expression guide or a tutorial website for more information on regular
expressions.
Case-Sensitive Exact Matching

The Case-Sensitive Exact Match option requires that the text entered e.g. Document Name exactly
matches the text used as a condition variable.
For instance, you want to prevent users from printing a specific document called Microsoft Excel -
Salaries.xls. Using the exact matching option, you can set the trigger expression to:
The document name matches Microsoft Excel - Salaries.xls.
Action
Action defines the type of action to take when the rule triggers. The available actions for Blueprint
Enterprise are :
l Deny
l Warn
l Inform
Action Description
A Deny action prevents print jobs from occurring. If a Deny rule

Deny triggers, employees are presented with an intrusive pop-up dialog
informing them that their action is against company policy and that
their job has been cancelled.
The cancellation is recorded as a policy saving for reporting purposes.
44
Action Description
A Warn action allows print jobs to proceed after confirmation from the
employee. If a Warn rule triggers, the employee is presented with an
intrusive pop-up dialog showing that the activity is against company
Warn
policy.
The employee can either choose to cancel the job or to continue

printing. However, unlike the inform action, violations under the warn
action will be logged and will be reported as policy violations. If the
employee cancels the print job, it will not physically print and it will be
recorded as a policy saving.
An Inform action notifies the employee and allows the action to

continue without interruption. If an Inform rule triggers, the employee
is presented with a non-intrusive pop-up dialog that shows
Inform information about the print job. The employee may choose to dismiss
the pop-up or it will auto-dismiss within a configurable time period.
The Inform action applies only to print-based rules. Copy-, fax-,

and scan-based rules in terminals and iMFPs do not support
the Inform action.
Multiple Rules per Job

If a job triggers multiple rules with different actions, the rules with the most restrictive action are applied.
In order of decreasing restrictiveness, the actions are Deny > Warn > Inform.
For example, if two Deny rules and one Warn rule is triggered, then the prompts for both Deny rules are
displayed on the Policy Notification dialog. The Warn rule prompt will not be displayed.
Prompts
Prompt is the rule component that specifies the policy pop-up messages that will be displayed to the
employee when a rule triggers. These pop-up messages can be customized to include variables such as
the document’s total number of pages, number of color pages, and cost.
Variable Name Description
The number of color pages in the document that the rule is being
{DocumentColorPages}
applied to.
{DocumentEstimatedCost} The estimated cost of the document that the rule is being applied to.
{DocumentTotalPages} The total number of pages (both mono and color) in the document
45
Variable Name Description
that the rule is being applied to.
{PrinterLocation} The location of the printer that the job is being sent to.
{PrinterName} The queue name of the printer that the job is being sent to.
You can create prompts like the examples given below:
l This document contains {DocumentColorPages} color pages, you are not permitted to print more
than 10 pages.
l This document contains {DocumentTotalPages} pages with a cost of {Cost}.
Groups
Blueprint Enterprise can be integrated with your existing directory system (e.g. Active Directory,
eDirectory, LDAP, etc.) and uses each employee’s group membership to determine the policy to apply.
Policies are not assigned directly to employees but rather to groups from your directory system.
Please contact Pharos Systems to determine which directory services are supported.
There are two points at which Blueprint needs to integrate with your directory system:
l At the Analyst, to allow the Blueprint Administrator to search the directory for groups to associate
with policies.
l At the Collector, to fetch an employee’s group membership(s) from the directory in order to
determine the employee’s policy. This happens when a workstation performs its daily request for
policy settings or when an employee prints for the first time on a workstation.
A group can only be associated with one policy. However, if a user belongs to multiple groups and
these groups have different policies, then the user will be assigned the policy with the highest
priority.
Active Directory
To determine what policy to apply to an employee, the Tracker will pass the employee’s network identifier
to its parent server (i.e. Collector or Analyst). The Collector or Analyst queries Active Directory to
determine the groups that the employee belongs to. To connect to Active Directory, the Collector or
Analyst uses the domain machine account of the server it is installed on.
The account must have sufficient permissions in Active Directory for Policy Print to function. This account
should either:
l Be a member of the “Authenticated Users” group. By default, the “Authenticated Users” group has
sufficient permissions to browse all users and groups in the domain.
46
l Have permissions to read the “memberOf” attribute of all domain accounts. This can be configured
using the Microsoft ADSI Edit MMC snap-in.
On a clustered server, the Blueprint services must be configured to run as a valid domain account.
In this case the service account, rather than the machine account, is subject to the AD permissions
requirement.
Recommendations for Assigning Groups to Policies

Pharos strongly recommends creating one group in the directory for each policy (also known as “Proxy
Groups” to Pharos) and assigning the policies to these specially created groups instead of connecting
policies to the existing groups. To assign policies to groups in the directory, make the existing groups
members of the appropriate Proxy Groups.
This is recommended for the following reasons:
1. Assume that there are two policies: “No Restriction”, and “Maximum Savings”. There will probably
be some groups where all members should have the same policy. For example, all members of the
“Senior Executives” group should get the “No Restrictions” policy. However, there will almost
certainly be other employees who also require the “No Restrictions” policy, but they do not belong
to any groups where all members should have the “No Restrictions” policy.
The solution to this problem is to create a new group, assign the employees as members of the
group, and in Blueprint assign the “No Restrictions” policy to this group. Obviously, you will have
to create a directory group for each policy.
2. When you have multiple groups in Blueprint, you can assign policies to new groups in two ways.
l New groups can be made members of the proxy groups.

l An association is made in Blueprint between the new group and the policy.
The second method is obviously undesirable as:
l Only an employee who has an access to the Blueprint Administrator can change the relationship
between groups and policies.
l From the Active Directory perspective, it is unclear what policy is associated with each group, as a
group can acquire a policy either via inheritance from its parent groups, or via a Group/Policy
relationship in Blueprint (which is only visible in the Blueprint Administrator).
l Things are also unclear in the Blueprint Administrator because of the group’s parent-child
relationship. It is possible that the policy given to a group in Blueprint is going to be overridden by
the group’s parent policy. Group parentage is not visible in the Blueprint Administrator.
Assigning Groups
To assign a group to a policy:
1. In the Policy Print > Policies screen, select the policy to which you want to assign groups.
2. Click the Groups tab under Policy Details.
47
3. Click the Add button. The Select Directory Service Group dialog appears.
4. Enter the group name or click Search. Clicking the Search button displays the first 100 directory
groups. Scroll through the list of groups and select the group you want to add.
5. If the group name that you want is not on the list, use the two search modes that are available:
Simple and Advanced (please refer to the "Searching Groups" section on page 48.).
6. Click OK. Note that the group now appears in the policy’s list of groups.
Searching Groups
Simple Search
To perform a simple search:
1. In the Group Name box, type part of the directory group name you want to assign to the policy.
2. Click the Search button. The search returns the directory groups whose Common Name (CN)
contains the search string.
Advanced Search
Advanced search provides you with an option to search by group name or find the groups for a specific
user name. You can also specify any combination of Collectors to perform the search.
To perform an advanced search:
1. In the Select Directory Service Group dialog box, click the Advanced button. This dialog box
appears.
2. Select either Group Name or User Name in the drop-down list box.
l In the User Name box, type the exact user name (wildcard is not supported).
l In the Group Name box, type the group name.
48
3. Select either Group Name or User Name in the drop-down list box.
l In the User Name box, type the exact user name (wildcard is not supported).
l In the Group Name box, type the group name.
4. Next to the Query Servers field, click the browse button. The Servers to Run Search dialog screen
appears. Select the Collectors on which you want to perform the search and then click OK.
5. Click the Search button. The search returns the groups that match the search criteria.
Policy Priority
Employees may belong to multiple groups; it is therefore possible that an employee may be associated
with more than one policy. If an employee is associated with more than one policy, the policy with the
highest priority is used.
For example, an employee belongs to two Active Directory groups - Marketing and Executive. The
Marketing group has a “deny color printing from local printers” policy and the Executive group has the
“No restrictions” policy. If the employee prints a color document to a local printer, no policy is applied
because the No Restrictions policy has a higher priority than the “deny color printing from local printers”
policy.
Policy priorities are configured in the Analyst on the Policy Print > Policies screen. Policy Print provides a
very simple priority mechanism that allows administrators to adjust the position of a policy.
Changing Policy Priority

To change the priority of a policy:
1. In the Policy Print > Policies screen, select the policy whose priority settings you want to change.
2. Click the Increase Priority button to set the priority level up or click the Decrease
Priority button to move the priority level down.
"No Restrictions" and "Default policies" have fixed priority values. "No Restrictions" will always
have the highest priority; "Default" will always have the lowest priority.
49
Changing Messages Displayed to the Employee

Global Prompts is used to define the strings used to form the full messages that are displayed to
employees in the Policy Print pop-ups on workstations and terminals. Blueprint is shipped with default
policy prompts. However, you have the option to customize your prompts according to what you want
your employees to see.
When editing global prompts, you have to select the context that is suitable for your system. There are
three contexts to choose from:
l Prompts displayed on workstations

l Prompts displayed on terminals
l Prompts used for displaying policy details on workstations and terminals
For more information on how to edit global prompts, Refer to the "Editing Global Prompts" section on
page 58.
Prompts Displayed on Workstations

These are the messages that are shown to employees on workstations when they print jobs that trigger a
rule.
The following figures show how the prompts are used to create the different workstation notification
popups that are displayed to employees.
50
Figure - a Deny popup and the prompts used.
Figure - a Warn popup and the prompts used.
Figure - an Inform popup and the prompts used.
51
The following table shows a list of the prompts displayed on workstations and their descriptions.
Prompt Name Description
Defines the notice title that will appear on the policy notification popup
Title
(e.g. “Printing Info about”).
This is the header for a deny notification popup. This message is

displayed on workstations when the employee attempts to print a
Header Deny
disallowed print job (e.g. “This job is not consistent with our corporate
printing policies”).
This is the header for a warn notification popup (e.g. “Help create a
Header Warn
greener work environment and save the company money”).
This is the header for an inform notification popup. If an Inform rule

triggers, the employee is presented with a non-intrusive pop-up dialog
Header Inform
that shows information about the printing job (e.g. “Here’s a Green
Tip”).
This checkbox and message is only displayed to employees for a Warn

Confirmation action (e.g. “I understand, but this document is important”).
Checkbox Warn The employee needs to tick this checkbox before the Continue button is
enabled.
This is the footer for a Deny notification popup (e.g. “Your job has been
Footer Deny canceled. If you still need this document, please make selections that
are compatible with our policies”).
This is the footer for an Inform notification popup (e.g. “You can help
Footer Inform
save the environment”).
Defines the label for the command button used to cancel a print job
Cancel Button
when the Warn action is applied.
Defines the label for the command button used to continue a print job
Continue Button
when the Warn action is applied.
Defines the label for the command button used to dismiss the
OK Button
notification popup when the Deny or the Inform action is applied.
Defines the name of the command button that is used to show more
Detail Button
details about the policy.
52
Prompts Displayed on Terminals

These prompts are the messages that are shown to employees on terminals that have copy, scan, or fax
rules in their policy.
Policy Print provides a way of configuring prompts for different types of terminals.
l For terminals that are forced to restrict access to device functions before the functions are selected,
usually at the start of the user session, the Device Access prompts are used.
l For terminals that can restrict access to a device function after the function has been selected, the
Functions Access prompts are used.
Device Access Prompts

The following table shows a list of the Device Access prompts used when using copy, scan and fax
functions on terminals and devices that support device-level overrides.
Defines the notice title that will appear on the policy notification popup (e.g.
Device Access Title
“Device Access Restrictions”).
This is the header for a notification popup (e.g. “Your use of this device is
Device Access Header
subject to the following restrictions”). It is used for all functions and actions.
Device Access Text to display for a function is not restricted by the employee’s policy (e.g.
Function Exempt “No restrictions”).
Device Access Text to display for a function that has a deny action applied (e.g. “Function
Function Deny disabled. You are not permitted to override this restriction”).
Device Access Text to display for a function that has a warn action applied (e.g. “Function
Function Warn disabled. You may override this restriction or accept it”).
Device Access Text to display when a function that is not restricted, but a feature of the
Function Aspect function (e.g. color copying) has a deny action applied (e.g. “A feature of this
Deny function is disabled. You are not permitted to override this restriction”).
Device Access Text to display when a function is not restricted, but a feature of the
Function Aspect function (e.g. color copying) has a warn action applied (e.g.”A feature of this
Warn function is disabled. You may override this restriction or accept it”).
Text to display when the copy/scan/fax functions have deny actions applied
Device Access Footer
to them by the employee’s policy (e.g. “You are not permitted to use this
Deny
device”).
53
Function Access Prompts

The following table shows a list of the Function Access prompts used when using copy, scan, or fax
functions on terminals and devices that support function-level overrides.
Defines the notice title that will appear on the policy notification popup (e.g.
Function Access Title
“Functions Access Restrictions”).
Text indicating the current page if the policy information spans more than one
Function Access Page
page (e.g. “Page 1 of 3”).
Function Access This is the header for a notification popup (e.g. “Your use of this function is
Header subject to the following restrictions”).
Function Access This is the heading for the list of deny restrictions (e.g. “Restrictions that you
Heading Deny may not override”).
Function Access This is the heading for the list of warn restrictions (e.g. “Restrictions that you
Heading Warn may override or accept”).
Function Access Footer text to display when a copy, scan or fax job is denied (e.g. “You are not
Footer Deny permitted to use this function”).
54
Common Terminal Prompts
Checkbox text to allow copy/fax/scan job warnings to be overridden (e.g. “I

Confirmation
have a legitimate business reason to override the restriction(s)”). The
Checkbox Warn
employee must tick this checkbox to continue.
Function Copy The label used when referencing the “Copy” function.
Function Fax The label used when referencing the “Fax” function.
Function Scan The label used when referencing the “Scan” function.
The label used for the Cancel button. The Cancel button will exit the Policy
Cancel Button
screen and log off the employee.
The label used for the Accept button. The Accept button will log the
employee onto the device, but apply all of the restrictions shown on the
policy screen.
Accept Button
This is typically shown when an employee can still use one or more functions
on the device or use them in a limited manner (e.g. the employee can use
the copy function; he just cannot copy in color).
The label used for the Review button. The Review button will show the
employee more details about the policy. The Review button is typically only
Review Button
used on devices that use the Device Access prompts and only when all rules
apply a deny action.
The label used for the Override button. The Override button serves two
purposes:
l On a device that uses the Device Access prompts, it is displayed when

one or more rules apply the warn action. Clicking it will show more
details about the policy and the Confirmation Checkbox Warn
Override Button checkbox. The employee can tick the confirmation checkbox and click
the Override button again to override the warning.
l On a device that uses the Function Access prompts, it will be shown
when a rule applies a warn action. The Confirmation Checkbox Warn
checkbox will also be displayed on this screen. The employee can tick
the confirmation checkbox and click the Override button again to
override the warning.
The label used for the Print Only button. The Print Only button is effectively
Print Only Button
the same as the Accept button, but it will also open the print screen. The
55
Print Only button is typically only used on devices that use the Device
Access prompts.
The label used on the Previous button. This button is displayed when the
Previous Button
policy information requires more than one page to be displayed.
The label used on the Next button. This button is displayed when the policy
Next Button
information requires more than one page to be displayed.
The label used on the OK button. This is typically shown when a rule applies
OK Button a deny action and the function is not available. Clicking on the OK button will
log off the employee.
The label used for the Detail button. The Detail button will show more
Detail Button
information about the employee’s policy.
Prompts used for displaying Policy Details

Detail prompts are displayed on workstations and terminals whenever an employee requests more details
about their policy. Employees are presented with a popup containing information on Policy Print and the
policy that applies to them.
56
This table shows a list of the policy detail prompts and their descriptions:
Title The text used for the title that will appear on the policy detail popup.
The text used for the header on the policy detail popup. This should be a
brief description of why the employees are seeing Policy Print.
Header
Example: "We have implemented Pharos Blueprint policies to manage our
print and copy resources. The policy assigned to you is detailed below."
Name The label used next to the name of the policy applied to the employee.
The label used next to the description of the policy applied to the
Description
employee.
57
The text used as the heading for the list of rules with a deny action. The list
Heading Deny of rules is based on the policy applied to the employee.
Example: “Deny activity under the following conditions:”
The text used as the heading for the list of rules with a warn action. The list
Heading Warn of rules is based on the policy applied to the employee.
Example: “Warn about activity under the following conditions:”
The text used as the heading for the list of rules with an inform action. The
Heading Inform list of rules is based on the policy applied to the employee.
Example: “Inform about activity under the following conditions:”
Any additional information or messages that you want to convey to

employees.
Footer
Example: “If you require further assistance, please contact the IT support
helpdesk.”
Close Button The label of the button used to close the policy detail popup.
Add a hotlink to the bottom of the policy detail popup. The hotlink will
Support Link/ Support Link
open the Support Link URL; the hotlink will display the text entered in
URL
Support Link.
Editing Global Prompts

Blueprint Enterprise comes with default global prompts. However, you can also customize the text
displayed to employees in the policy notification and policy detail pop-ups. Global prompts can be edited
from the Policy Print > Policies screen of the Analyst.
To edit global prompts:
1. Click the Edit Prompts button on the Policies screen toolbar. The global prompts editor appears.
2. In the Edit Global Prompts screen, select a Context. The available options are:
l Prompts displayed on workstations

l Prompts displayed on terminals
l Prompts used for displaying policy details on workstations and terminals
The prompts displayed depend on the Context selected. The following figure shows the prompts available
for the "Prompts displayed on workstations" option.
58
3. Select the prompt you want to change and click the "Prompt Text" field of the prompt you have
selected.
4. Click Apply and Close to save changes.
Each prompt field has a ‘revert to default’ button next to it. Clicking this button will reset it to
the default prompts.
Policy Print Settings

Policy Print settings are the general settings that apply to policies, including whether policy enforcement is
enabled. The Policy Print Settings screen is divided into the following tabs:
l General
l Directory Services
59
General Settings
The General Settings of Policy Print contains three sections:
l Policy Print Settings

l Toner Savings Settings
l Estimated Cost Settings
Policy Print Settings
Setting Description
Policy enforcement is disabled by default. To use the Policy Print functionality,

Enable Policies
it has to be enabled on the Analyst.
The amount of time the policy notification popup will remain on the screen. If
the employee on the workstation does not do anything, then the policy
notification popup times out and will auto close. The default popup timeout
value is 120 seconds.
Client Popup Timeout
Use a reasonable timeout setting to ensure users have time to read

the policy details.
Toner Savings Settings
Setting Description
This setting is used to enable the Toner Savings feature of Blueprint

Enterprise. This setting is disabled by default.
Enable Toner Savings
If you do not have a license for Toner Savings, this property will not be visible
from the Administrator.
This setting denotes how often the Preton Saver (Preton client component)
should communicate with the Preton Coordinator. There are three modes to
choose from:
l Connect at will - The Preton Saver will connect to the Preton

Preton Client Network Coordinator after each print job.
Mode l Limit access - The Preton Saver will connect after 5 print jobs but no
more than once an hour.
l Keep to a minimum - The Preton Saver will connect to the Preton
Coordinator once every 12 hours.
This setting is set to Connect at will by default.
60
Estimated Cost Settings
Setting Description
These settings that are used to calculate the estimated cost of a print job sent
to a locally attached printer. The estimated cost can be used as a trigger
condition and displayed in a rule prompt.
Local printing is defined as any print job sent to a printer connected directly
Cost Per Page for Local to the workstation (e.g. via USB, parallel port, serial port, etc).
Printing
The cost is split by black and white cost per page and color cost per page.
Black & white costs must always be lower than color costs, and
network costs must always be lower than local costs.
These settings that are used to calculate the estimated cost of a print job sent
to a network attached printer. The estimated cost can be used as a trigger
condition and displayed in a rule prompt.
Network printing is defined as any print job sent to a printer connected on

Cost Per Page for the network (e.g. direct IP printing, print server-based printing).
Network Printing
The cost is split by black and white cost per page and color cost per page.
Black & white costs must always be lower than color costs, and
network costs must always be lower than local costs.
Directory Services Settings

The Directory Services Settings tab is where you specify the directory plug-in that will be used for
implementing Policy Print. This screen is available on both the Collector and the Analyst.
61
A directory plug-in implements the interface between the Blueprint servers and your directory system.
Blueprint Enterprise supports Microsoft Active Directory by default. Blueprint Enterprise can also support
other directory systems.
If you have directory systems other than the Active Directory (e.g. LDAP, Novell eDirectory), please
contact Pharos Systems to discuss your requirements.
The following table describes each of the Directory Services settings.
Setting Description
This shows the list of all installed directory system plug-ins (e.g. Active
Directory and all other directory plug-ins that have been installed on the
Service Type local server). It allows you to select the directory plug-in that the Policy
Print will use. Changing the directory service type will change the plug-in
used on the local server only.
Accepts a group name and allows you to perform a search in the directory
Directory Service Group
service for groups matching that group name.
Accepts a user name and allows you to perform a search in the directory
Directory Service User
service for that employee’s groups.
The Search Groups and Search Users buttons are used to test the selected directory plug-in by querying
the servers for users or groups.
To perform a search by group:
1. In the Directory Service Group box, type the full Active Directory group name or use the * wildcard
e.g. type admin* instead of typing administrators.
The * wildcard matches any number of characters at the point that it occurs in the search
string. For example, entering admin* into the Group name field will display all group names
starting with "admin".
2. Click the Search Groups button. This search returns the Active Directory groups whose Common
Name (CN) matches the search string.
To perform a search by user:
1. In the Directory Service User box, type the full user name.
The use of the * wildcard is not supported when searching for a user’s groups.
62
2. Click the Search Users button. If the user is found, the search returns the Active Directory groups
for that user.
The use of the * wildcard is not supported when searching for a user’s groups.
Known Limitations of Policy Print

In certain circumstances, single print operations will produce multiple print jobs resulting in multiple
policy notification popups appearing on your workstations.
l Printing Microsoft Excel with multiple worksheets. When printing an entire Excel workbook that
contains multiple individual worksheets, policy popups appear more than once. This is because
Microsoft Excel treats each of the worksheets as a separate print job and sends the job as multiple
print jobs.
l Printing documents with “Manual Duplex” option. Manual duplex prints every other page of the
document first and allows you to reinsert pages to print the second side. Policy popups appear
twice when printing Word documents using the Manual Duplex option. For example, if you have
printed one job consisting of 20 pages, this will appear to Blueprint as two print jobs of 10 pages
each, thereby making the policy popup appear twice.
Example Policies
This section gives you an example of a policy and walks you through the necessary steps in creating a
policy.
Scenario: You want to prevent employees in a particular department from printing to a color capable
device.
Start your Pharos Blueprint Administrator and go to the Policy Print > Policies screen.
Step 1 - Add a policy
1. Click the Add Policy button on the Policy Print > Policies screen toolbar.
2. Enter a policy name and a description under the Policy Details. For this example, type "Print Policy
for AB Department" for Policy and "Help reduce our environmental waste and save money by
changing the way you print." for Description.
3. Click Apply. Check that the policy has been created under the list of policies.
Step 2 - Create a rule
1. On the Policy Print > Policies screen, select the policy you have just added.
3. Click the Create button. The Create a New Rule dialog screen appears.
Blueprint gives you an option to select a trigger from the list of built-in- triggers. However, in this example,
you are going to create a new trigger “Color Printing”. The trigger is not in the list of built-in triggers.
Step 3 - Create a New Trigger
63
1. Select Create New from the triggers list and the Trigger Editor dialog box appears.
2. In the Trigger field, enter a trigger name.
3. In the Functions that the trigger applies to area, tick the function you want the trigger to apply.
Tick the Print function.
4. In the Conditions list, double click "Document Contains Color" and the Edit Condition dialog
appears. Click OK and check that the expression is now "Document Contains Color”.
5. Click OK. This brings you back to the Rule Editor
6. Select the Deny action.
7. In the prompt box, type "The use of color is not permitted".
8. Click OK to create the rule and note that the rule has been created under the selected policy.
Step 4 – Assign the group
1. On the Policy Print > Policies screen, select the same policy that you have just created
2. Click the Groups tab under the Policy Details.
3. Click Add and the Directory Service Group dialog appears.
4. Type the group name you want to assign the policy to. Alternatively you can click Search. Clicking
the Search button displays the first 100 group names of the Active Directory Group. Scroll through
the list of groups and select the group you want to add. If the group name that you want is not on
the list, use the two search modes that are available: Simple Search and Advanced Search.
5. Click OK. Note that the AD group now appears in the list of groups.
Step 5 – Define policy priority (optional)
Defining the policy priority is an optional step for this example, but should be defined when configuring a
more complex set of policies.
64
Configuration Guide Configuring Secure Release Here®
Configuring Secure Release Here®

This section gives you an overview of Secure Release Here concepts including how to configure a Secure
Release Here system. This section covers the following topics:
l What is Secure Release Here?

l Secure Release Here Components
l Getting Started with Secure Release Here
l Terminals
l Devices
l Secure Queues and Print Groups
l Setting up Print Groups
l Setting up Secure Queues
What is Secure Release Here?

Blueprint Enterprise's Secure Release Here® functionality allows you to control the release of print jobs
sent from employee workstations to printers, enabling improved security when printing jobs and giving
employees the flexibility to choose a destination printer after submitting their jobs.
Employees choose to use Secure Release Here by printing their jobs to a secure print queue. A Secure
print queue is a queue that exists on a print server installed with the Blueprint Collector component. The
secure queue is configured to use the Pharos Systems Secure Release Port and is associated with a print
group. The print group defines the set of devices that the employees can use to release their print job.
Employees release print jobs using a terminal that is attached to (or integrated within) a printer. Both the
terminal and the printer are recorded in Blueprint Enterprise. User authentication at the terminal is
handled by the terminal’s authentication method, which allows users to be identified by whatever means
the organization prefers (e.g. by card swipe or entry of a username/PIN and password). Once the
employee is authenticated, Blueprint displays a list of print jobs belonging to the employee. Each print job
can be released for printing or deleted.
Before You Start

Before configuring Secure Release Here, you should have completed the following tasks:
l Installed a Blueprint Analyst;

l Installed Blueprint Collectors on the print servers that will have secured queues. These Collectors
must be registered with the Analyst (i.e. the Collector must appear on the Servers screen at the
Analyst);
l You have a product license that includes a license for Secure Release Here
l You have a license that has the appropriate number of terminals or integrated software licenses
(e.g. iMFP and/or Omegas)
65
For more information about installing Blueprint Enterprise, please refer to the “Blueprint Installation
Guide” found in the main product CD.
Secure Release Here Terms/Concepts

A Secure Release Here system is composed of several entities. Before configuring Secure Release Here, it is
important to understand the entities that make up a Secure Release Here system.
The table below gives you a brief description of the various Secure Release Here entities:
Terms/Concepts Description
Authentication Method defines how employee credentials should be

validated (e.g. against Active Directory). In addition, it can translate one
Authentication Method
identifier to another (e.g. convert an employee’s card ID to their network ID
for job retrieval).
A terminal is a hardware device that provides the necessary user interface at

Terminal the print device. Employees use this device to view, select, and release their
print jobs.
The actual physical device that users send their print jobs to. All devices that
Device will be part of the Secure Release Here system must have associated
terminals.
Managed Devices Managed devices are devices that are associated with terminals.
Print Group is a grouping of managed devices with compatible drivers. Print

groups are used to specify which managed devices a user can collect their
print jobs at.
A Blueprint Secure Queue is associated to a managed device via a Print Group.

Print Groups
When a user submits a job to a Secure Queue, the job is available for release
on any of the managed devices in the Print Group assigned to the queue.
For more information on how to set up Print Groups, Refer to the "Setting up
Print Groups" section on page 78.
These are queues that exist on a print server installed with the Blueprint
Collector. A queue is secure if it has been configured to use the Pharos
Systems Secure Release Port (Pharos Secure Port) and it has been assigned a
Secure Queues Print Group.
For more information on how to set up secure queues, Refer to the "Setting
up Secure Queues" section on page 80.
66
Getting Started with Secure Release Here

Configuring a Secure Release Here system involves the following steps:
1. Setting up authentication models, terminals, devices, and Print Groups at the Blueprint
Administrator.
2. Setting up secure queues on the Print Servers.
3. Physically deploying terminals and/or iMFPs.
The following flowchart shows the flow of setting up and configuring a Secure Release Here system.
As of Blueprint 5.1, a new Secure Release Here > Default Settings screen has been added to
Blueprint Administrator that sets the default Print Group and Authentication Method for newly
created managed device (i.e.g devices associated with terminals). For more information, please
refer to the "Secure Release Here Default Settings" section on page 75.
The following gives you a summary of the steps necessary to set up and configure a Secure Release Here
system on the Blueprint Administrator and the Print Servers.
1. Set up the authentication model (Authentication Method). For more information on how to set
up authentication model, please refer to the "Adding a New Authentication Method" section on
page 94.
67
2. Add terminals attached to, or integrated with your output devices. For more information on how
to add new terminals, Refer to the "Adding New Terminals" section on page 70.
3. Configure device details. When adding terminals, output devices are automatically created in the
Device Management > Devices screen. However, you must set up device properties such as Model
Information and MFD Functions. For more information on configuring these device properties,
Refer to the "Device Model Information" section on page 75.
4. Set up Print Groups. After terminals and devices are in place, you must now set up Print Groups.
To set up Print Groups, do the following:
a. Add Print Groups. For more information on how to add Print Groups, please refer to the
"Adding a New Print Group" section on page 78.
b. Add managed devices to Print Groups. For more information on how to add managed
devices to a Print Group, please refer to the "Adding Managed Devices to a Print Group"
section on page 79.
5. Set up Secure Queues. After configuring the authentication model, devices, and Print Groups in
the Analyst Administrator, the next step is to set up Secure Queues. Secure Queues are set up on
the Print Servers with Blueprint Collectors installed. To set up Secure Queues, follow these steps:
a. Create new queues on the Blueprint Collectors servers.For more information on how to
create a queue, Refer to the "Creating a Queue" section on page 80.
b. Secure the queues using the Blueprint Secure Queue Configuration Tool, Refer to the
"Securing Queues" section on page 82.
Terminals
Users must log on to a terminal to view, select and release their print jobs to a device. A terminal is a
hardware device that provides the user interface at the print device.
Terminals maybe one of the following:
l A standalone device. A Terminal can be a standalone unit that is attached to the printer device to
control the release of print or copy jobs. Examples of this type of terminal are the Omega PS150,
Omega PS200, and Omega PS60.
l Integrated device. A printer device itself can act as a terminal when it has the Pharos integration
software installed on it, allowing users to log on and select job from the device. Examples of this
type of terminals are the Canon iMFP, HP iMFP, Lexmark iMFP, Ricoh iMFP,and so on.
You can add and configure new terminals from the Device Management > Terminals screen.
When creating terminals, you are required to provide the network address of the device that you are
configuring for Secure Release. Creating a terminal adds a new device with a hostname or IP address
corresponding to the device and associates the device with the terminal.
Terminal Properties
The following properties relating to the operation of terminals can be configured for each terminal listed in
Blueprint Administrator.
68
Settings
Detail Meaning
Terminal A unique identifier for the terminal.
Descriptive text giving more information about the terminal.
The “Description” field is used as the printer name instead of the

Description “Device” or “Terminal” names in both the Workstation Release and
MobilePrint Web Release. If the "Description" is left blank, the terminal
name is used. You should enter a meaningful description to help
employees easily identify their printers.
The terminal type indicates the type and version of a terminal device, and
Terminal Type determines the configurable settings that apply to the terminal.
The terminal type property becomes read-only after a terminal is added.
Read-only property that represents the ‘family’ that the terminal type belongs
Terminal Type Class to. For example, the ‘HP iMFP’ family of terminal types can have members of
which would be various versions of the ‘HP iMFP’.
Device Network This property indicates the host name or the IP address of the device associated
Address with the terminal. This is a mandatory field.
This property indicates the LPR Queue Name of the device associated with the
terminal.
Device LPR Queue
An entry in this field is required only when the associated device requires a LPR
Queue Name, otherwise it can be left blank.
Read-only property indicating the device that the terminal releases print jobs
Device
to.
Authentication
The authentication method that the terminal uses to authenticate users.
Method
Server Read-only-property showing the local server that the device is assigned to.
All output application supported by the terminal type, e.g. Secure Release Here,
Terminal Features
Copy Tracking.
69
Copy Lines
Certain terminal types allow you to specify the combinations of attributes returned on each copy line by
the MFP that the terminal controls (currently, the Pharos Omega terminal type is the only such type). This
configuration is performed on a separate Copy Lines tab. The Copy Lines tab displays the combinations of
attributes that can be returned by the MFP that the terminal controls. The controls on this tab can be
used to specify which copy line returned from the MFP indicates which combination of attributes.
Terminal Type Settings

Any settings that are specific to the terminal's type appear on tabs after the Settings tab. The available
settings will differ from type to type.
Terminal Types
Each terminal or iMFP solution ships with its own terminal type; this terminal type is used to indicate the
type and version of terminal or iMFP that is connecting to the Blueprint system. In addition, the terminal
type specifies the settings that are available for that type of terminal.
Blueprint Enterprise only includes a “Generic” terminal type. This “Generic” terminal type is only used as
an initial placeholder; when you actually connect the terminal to the system, it will update the terminal
type automatically.
Adding New Terminals

Depending on your initial setup, you can do one of the following to add terminals to your system:
l If you do not have existing devices, you can manually add a terminal on the Device Management >
Terminals screen. A new device is automatically created in the Devices section for each terminal
that you add.
l If you have existing devices on the Device Management > Devices screen, you can also add
terminals directly from that screen. For more information on how to batch-create terminals from
existing devices, please refer to the "Automatically Creating Terminals" section on page 71.
To add a terminal manually:
1. In the Device Management > Terminals screen, click the Add Terminal button. A new terminal
record appears in the main list.
2. In the Settings tab, enter all relevant details about the new terminal.
a. In the Terminal field, enter a terminal name.
b. In the Device Network Address, enter the IP address of the device that the terminal will be
associated to.
c. In the Authentication Method field, select the authentication method that you have initially
configured.
3. Click Apply.
70
A new device entry is created for each terminal that you add. These devices can be edited on the Devices
screen. The terminal(s) are automatically associated with the created device.
Automatically Creating Terminals

All devices that will be used in the Secure Release Here system must have an associated terminal. To make
the initial setup easier, a terminal can be created and automatically associated with a specified device from
the Devices screen in the Device Management section.
1. Go to the Device Management > Devices screen.

2. In the Devices list, select the device or devices that require a terminal.
3. Click the Create Associated Terminal button.
4. Click Apply.
A new terminal entry is created for each device. These entries can be viewed and edited on the Terminals
screen. The terminal(s) are automatically associated with the selected device(s).
If the Create Associated Terminal button is disabled, this means that you have selected devices
that do not have IP Addresses. To manually add the IP address of a device, select the Connections
tab and under Active Network Connection Details, add a valid device IP address.
Editing Terminals
Most of the properties displayed for each terminal can be edited directly. If a terminal's properties are
changed, the Apply and Cancel buttons at the bottom of the screen become available to save or cancel
your changes. If you click away from a terminal record before applying the new details, you are prompted
to save the changes to the terminal.
After editing the Terminal, you can choose to propagate those changes to the relevant Server immediately
or you can wait at a later time (e.g. when network is less busy). As of Blueprint 5.1, updating the Terminal
configuration now requires manual intervention from an administrator.
To update Terminal configuration, click the Update Terminals on Collector button on the Terminals
toolbar. Clicking the button updates the Server that controls the terminal with the new configuration
settings. It also clears replicated data if the Terminal’s parent server is a Blueprint Collector. The next time
a user logs in to a Terminal, the Terminal will fetch its new configuration settings from its associated
Blueprint Server.
Changes made to the Terminals will not take effect until the Update Terminals on Collector
button is clicked.
Editing Copy Lines

Certain terminal types allow you to specify the combinations of attributes returned on each copy line by
the MFP that the terminal controls (at the time of release, the Pharos Omega terminal type is the only
71
such type). This configuration is performed on a separate Copy Lines tab on the Terminals screen.
It is usually easiest to configure copy lines at the Omega PS150 by clicking the Learn Copier button
on the Station > Copier on the configuration menu.
To configure a terminal's copy lines:
1. Select the Copy Lines tab on the Terminals screen.

2. Tick all page size and attributes supported by the MFP in the list boxes on the right. As you select
attributes, the main table on the left is populated with all possible combinations of attributes
3. For each row in the table, set the Copy Line property to the number of the copy line returned by
the MFP when that combination of attributes in returned.
4. Click Apply.
This configuration tells the terminal what copy lines to expect from the copier - it does not tell the copier
which lines to return.
For example, if the copier can copy A3 and A4 paper sizes and can copy in color, tick the A3, A4 and Color
boxes. This results in a table like this:
For each row in the table, enter the copy line number that corresponds to the combination of attributes
in that row. If copy line 0 corresponds to an A4 copy with color, enter 0 for the first row.
Deleting Terminals
Existing terminals can be deleted from Device Management >section.
To delete a terminal:
In the Terminals screen, select the terminal that you want to delete and then click the Delete button.
Duplicating Terminal Settings

Setting up many terminals can be a time-consuming process. In order to simplify the process, it is possible
to copy the settings from an already configured terminal to one or more other existing terminals.
To duplicate one terminal's settings across one or more other terminals:
1. Click the Copy Terminal Settings button. This starts the Terminal Setting Duplication Wizard and
then Click Next.
2. Select the terminal that you want to copy settings from and click Next.
72
3. Select the terminal(s) that you want to copy settings to and click Next.
4. Tick the Copy boxes of all properties whose values you want to copy to the target terminal(s). Click
Next.
73
5. Click OK to exit the wizard.
The selected properties of all target terminals are updated with values from the original terminal.
Devices
Devices are the actual physical devices that jobs are released to. Devices are listed on the Device
Management > Devices screen.
A device can be registered to the Blueprint system in the following ways:
l Devices are automatically created when creating terminals.

l Devices can be imported in bulk using File Importer.
l Devices can be automatically created during the normalization process.
l Devices can be manually added from the Devices screen if necessary.
Manually Adding New Devices

While device records are normally imported in bulk, created automatically during terminal creation, or
created automatically during the normalization process, new devices can be added from the Devices
screen if necessary.
To add a device manually:
1. Click the Add Device button on the Devices screen toolbar. A new device record appears in the
main list.
74
2. In the Device Details tab, enter all relevant details about the new device. For more information
about device details, please refer to the "Device Model Information" section on page 75.
3. Click Apply. (If you click away from the new device record before applying the new details, you are
prompted to save the changes to the new device).
New device records can also be created while manually normalizing data and correcting
normalization errors.
Device records cannot be deleted; however, inactive devices (i.e. devices that have no volume
associated with them for a given period) are not included in reports.
Device Model Information

Whether a device is manually registered or batch created from terminals, it is important that you verify
the model that is assigned to it in the Device Management > Devices screen.
Of particular importance:
l In the Manufacturer/Model field, select the correct Manufacturer and Model.

l Specify the Model Confidence.
l If the device is an MFP/MFD, you will need to specify the correct MFD Functions that you plan to
control. It is recommended that you select “Print” and “Copy” in all cases.
MFD Functions is enabled only if the manufacturer/model assigned to the device has a device type
of "MFD"
Editing Devices
You can edit device properties in Device Management > Devices screen. Most of the properties displayed
for each device can be edited directly. If a device's properties are changed, the Apply and Cancel buttons
at the bottom of the screen become available to save or cancel your changes. If you click away from a
device record before applying the new details, you are prompted to save the changes to the device.
Device records can be replaced, combined and split if necessary to correct normalization errors.
Secure Release Here Default Settings

Setting up Secure Release Here involves configuring several components, such as Terminals, Devices, Print
Groups, Authentication Methods and Secure Queues.The default settings in this screen simplify
configuring Secure Release by reducing the number of steps to take. You no longer have to create a Print
Group and set up an Authentication Method if the default settings are adequate.
75
All newly created managed devices (i.e. devices with terminals attached) will automatically be set to use
the Print Group and Authentication Method set up in the Secure Release Here > Default Settings screen.
The Default Settings screen is spread between two tabs:
l Default Settings
l Advanced
Default Settings
Setting Meaning
This indicates the Print Group to which new managed devices will be added.
Print Group
Blueprint is shipped with a default called the "Default Print Group".
This is the default Authentication Method that will be applied to newly created
managed devices.
Blueprint is shipped with a default Authentication Method called the "Standard

Authentication
Authentication Method". This Authentication Method allows users to:
Method
l logon using a card or network ID and password
l register a card with their network ID
l authenticate against the Active Directory
Advanced
The Advanced tab shows a list of all the Terminal Type used by each managed device in the Print Group,
including their Terminal Type Versions.
Changing the Default Settings

Changing the Default Print Group
To change the default Print Group for Secure Release, click on the ellipsis next to the name of the current
Print Group. This opens the Select Print Group dialog box. Search for the Print Group that you want to set
as your new default, and then click OK.
Changing the Default Authentication Method

You can change or edit the details of the default Authentication Method.
To change the Authentication Method, click on the ellipsis next to the name of the current Authentication
Method. This opens the Select Authentication Method dialog box. Search for the option that you want
to set as your new Authentication Method for Secure Release, and then click OK.
76
To edit details of the default Authentication Method, click on the button. This opens the Edit
Authentication Method dialog box.
Secure Queues and Print Groups

Secure Queues are queues that exist on a print server installed with the Blueprint Collector component.
Secure Queues are configured to use the Pharos Systems Secure Release Port and are associated with a
print group. Print Groups are used in Blueprint Enterprise to specify what devices a user can collect their
print jobs at.
In the Secure Release Here system, a Secure Queue is associated to an output device via a Print Group.
When an employee sends a print job to a Secure Queue, the job can be released to any managed device
(devices with terminals) in the Print Group assigned to the queue. This set up is shown in the figure below.
An employee sends a print job to Secure Queue1 hosted on a print server installed with the Blueprint
Collector. The job will be available for release at both Managed Device1 and Managed Device2, because
they belong to Print Group1 which has been assigned to Secure Queue1.
Secure Queues simplify the set up of Secure Release by providing a single queue for a Print Group. This
allows workstations to be mapped to a single queue rather than a range of specific device queues.
Secure Queues and Print Groups
77
You can set up Print Groups and add managed devices to the Print Groups using the Administrator on the
Analyst. You can assign a Secure Queue to a Print Group using the Blueprint Secure Queue Configuration
Tool on each print server.
Setting up Print Groups

To set up print groups, follow these steps:
1. Create a new Print Group. For more information, Refer to the "Adding a New Print Group" section
on page 78.
2. Add managed device(s) to the Print Group. For more information, Refer to the "Adding Managed
Devices to a Print Group" section on page 79.
In order for any job to be released to any device in a group, ensure that all devices in a Print Group
must use compatible printer drivers. Blueprint does not enforce this - you must ensure that any
device you add to a group is compatible with the other devices in the group.
Adding a New Print Group

You can add Print Groups in the Secure Release Here > Print Groups section of Blueprint Administrator.
To add a new Print Group:
1. In the Print Groups screen, click the Add Print Group button.
2. In the Print Group field under the Details tab, enter the name of the Print Group, and then click
Apply.
78
Verify that the new print group has been added to the Print Groups list. After creating a print group, you
must add managed devices to the group.
Adding Managed Devices to a Print Group

Manage Devices are devices that have terminals associated to them. You can only add managed devices
to a Print Group. You cannot add devices that do not have terminals associated with them.
To add managed device(s) to a Print Group:
1. Go to the Secure Release Here > Print Groups screen.

2. In the Print Groups list, select the group you want to add managed device(s) to and then select the
Managed Devices tab.
3. Click the Add Managed Device button. This opens the Select Device dialog.
4. Search for the device(s) you want to add, select them on the search dialog and click OK.
There is no restriction on which devices can be added to a group—they can be a group of devices in a
single printing room, or they can be in different rooms, buildings or countries.
The devices do not have to be controlled by the same Collector either—when an employee logs on to a
terminal, the Collector communicates with the Analyst and with other Collectors to find all of their jobs. A
managed device can belong to more than one group.
79
Print Group Properties

The Secure Release Here > Print Groups screen is divided into two tabs. The table below describes what
each tab represents.
Tabs Description
Details The Details tab displays the name of the Print Group.
Managed The Manage Devices tab lists all devices that have been added to the group. All
Devices devices in a group must all have compatible print drivers and capabilities.
Setting up Secure Queues

With the devices and terminals already registered in Blueprint Enterprise, you must now set up Secure
Queues. Secure Queues are configured on the Print Server with the Blueprint Collector.
To set up Secure Queues, follow these steps:
1. Create a queue if you already do not have one. The process of creating a queue is the same as
adding a printer in Windows. For more information on how to create a queue, Refer to the
"Creating a Queue" section on page 80.
2. Make the queue secure using the Blueprint Secure Queue Configuration tool. The Blueprint Secure
Queue Configuration Tool enables you to convert one or more standard Windows queues into
Blueprint Secure Queues. For more information on how to secure queues, Refer to the "Securing
Queues" section on page 82.
Creating a Queue
The process of creating a queue is the same as adding a printer in Windows.
To create a queue on a Collector:
1. Add a local printer object at Control Panel > Printers and Faxes > Add Printer on the print server
(that has the Collector server component installed).
2. Select any printer port.
3. Select a print driver. Ensure the printer uses the correct driver.
4. Assign an appropriate share name. Ensure that the printer is shared with a descriptive name that
will be clear to the employees.
After creating a queue, the next step is to secure the queue using the Blueprint Secure Queue
Configuration Tool.
80
Secure Queue Configuration Tool

The Blueprint Secure Queue Configuration tool converts one or more standard Windows queues to
Blueprint Secure Release Here secure queues. When the queues are converted, you will be prompted to
select the print group with which the queues should be associated.
You can launch the Blueprint Secure Queue Configuration Tool by doing one of the following:
l On the Start menu, click Programs > Pharos Blueprint Enterprise > Tools > Blueprint Secure
Queue Configuration
l In Printers and Faxes, right click any queue, and then select Blueprint Secure Queue Configuration
from the context menu.
Secure Queue Configuration Tool
Queues are listed on the Blueprint Secure Queue Configuration Tool with the following details:
Detail Meaning
Windows Queue
The name reported for the queue.
Name
This column is set to "Yes" if the queue is secure, meaning that print jobs
Secured
submitted to it will be held until they are released at the associated terminal.
81
Detail Meaning
This column shows the Print Group that the Queue is associated with. When a
Print Group user submits a job to a Secure Queue, the job is available for release on any of
the managed devices in the Print Group assigned to the queue.
Securing Queues
After creating Windows printer objects (queues), you can now convert these queues to Blueprint Secure
Queues using the Blueprint Secure Queue Configuration Tool.
You must have already created a Print Group with managed devices associated with it in the
Blueprint Administrator before converting queues to a Blueprint Secure Queue.
To convert existing print queue(s) to a Blueprint Secure Queue:
1. Open the Blueprint Secure Queue Configuration Tool. You can open the Secure Queue
Configuration Tool by doing any of the following:
l On the Start menu, click Programs > Pharos Blueprint Enterprise > Tools > Blueprint
Secure Queue Configuration.

l In Printer and Faxes, right click any queue, and then select Blueprint Secure Queue
Configuration.
2. In the Blueprint Secure Queue Configuration dialog, select the queue(s) that you want to convert to
a Blueprint Secure Queue, and then click the Secure Queue button. This opens a list of the available
Print Groups.
Blueprint Secure Queue Configuration Tool
82
3. In the dropdown list box, select the Print Group that will be assigned to the queue(s) , and then
click OK.
If you configure a queue to use the Pharos Secure Port but did not assign a Print Group to the
queue, print jobs will remain in the queue and will place the queue in an error state.
Changing Print Groups During Use

If you add, move, or remove devices from print groups while Secure Release Here is being used by
employees, print jobs that were sent prior to the changes will not be affected (i.e. if a device is added a
print group, any print jobs that were sent prior to it being added to the print group will still only be
available at that specific device).
Secure Release Here Settings

The Secure Release Here > Settings screen contains a number of settings for determining how print jobs
are released to Blueprint devices. This screen is available on both Collectors and Analysts, but the
available settings differ. The following settings are available:
l General Settings
l Workstation Release Settings
l Advanced Settings
General Settings
Setting Description
This represents how long a print job can remain in the server's secure
print job store before it is automatically deleted. For example, if you set
Delete print jobs held for this value to 5 days, jobs that are in held in the secure print job store for
more than x days more than 5 days will automatically be deleted.
By default, this value is set to 1 day.
This setting defines the time of day at which the Secure Release Service
runs nightly maintenance tasks such as deleting old print jobs(depending
Start maintenance tasks at on the "Delete print jobs held for more than x days" setting) and deleting
old devices based on the Workstation Release settings.
This value is set to 3 a.m. by default.
83
Workstation Release Settings
Settings Description
This setting represents how long a user is associated with a device. If a

Rank the devices shown to user has not printed to a device in the last x days, the device will be
the user based on the user's removed from the list of available printers in the Workstation Release.
print activity over the last x This prevents the Workstation Release from showing devices that have
days been deleted, or devices that are no longer in use.
The default value is 30 days.
Advanced Settings
Please contact Pharos Support before making changes to the Advanced settings.
Settings Description
This setting is available only in the Analyst.
When a user prints to the Secure Release Here system, the Collector they
print to will notify the Analyst that the user has printed to it. In this way,
Keep a server in the user's
the Analyst keeps track of all user print activity, allowing any Collector to
server usage memory for x
query the Analyst for a complete list of servers that a given user has
days after the user last
recently printed to. Each occurrence of a user printing to a given Collector
printed to it
will be remembered by the Analyst for the amount of time specified here.
If the user no longer sends print jobs to a particular print server in x days,
the Analyst will stop querying that server.
By default, this value is set to 5 days.
This setting is available only in the Collector.
Notify the Analyst when a

This represents how often the Collector will contact the Analyst to notify
print job is stored for a user
that a user has printed to it.
if the last notification was
more than x days ago. For example, if you have set this setting to 2 days, this means that the
Collector will send notification to the Analyst just once in 2 days.
By default, this value is set to 1 day.
84
The Analyst setting should always be set to a value that is greater than the Collector setting
otherwise new jobs on a Collector may not show up on the terminals.
Secure Release Here Example

This section gives you an example of the typical sequence for configuring a Secure Release Here
deployment. Refer to the content already covered in this section for more information on each step.
Scenario: You want to secure a group of devices and provide a simple mechanism for any employee to
print to them.
Start the Pharos Blueprint Administrator on the Analyst.
Step 1 – Configure the Authentication Method
1. In the Device Management > Authentication Methods screen, you can either select the default
"Standard Authentication Method" and configure it according to your environment or you can add
a new authentication method.
2. If you selected Advanced authentication type, on the Designer tab, configure the script as
necessary (e.g. enter the domain service account it should use to connect to the directory services
infrastructure).
3. Validate that the authentication script functions correctly using the Tester tab.
4. Click Apply.
Step 2 – Create Terminals and physically deploy terminals and/or iMFPs
1. In the Device Management > Terminals screen, add a new terminal. For the new terminal, enter
the following details:
a. In the Terminal field, enter a terminal name.
b. In the Device Network Address, enter the IP address of the device that the terminal will be
associated to.
c. In the Authentication Method field, select the authentication method that you have initially
configured in Step 1.
d. Change any terminal specific setting as necessary.
e. Click the OK button.
2. Physically install the terminal hardware on the device or install the iMFP software on the device.
3. Configure the terminal hardware of iMFP software to communicate with the correct server.
4. Validate that you can authenticate successfully on the terminals and/or iMFPs.
Step 3 – Configure Device Details
1. In the Device Management > Devices screen, select the device that you want to configure.
2. In the Manufacturer/Model field, enter the manufacturer and model of the device.
3. In the Model Confidence field, enter the Model Confidence.
4. If the device is an MFD, check the appropriate MFD Functions (i.e. print and copy).
85
5. Change any device specific settings as necessary.

6. Click the Apply button.
Step 4 – Set up a Print Group
1. Add a Print Group

a. In the Secure Release Here > Print Groups screen, click the Add Print Group button.
b. In the Print Group field under the Details tab, enter the name of the Print Group, and then
click Apply.
2. Add managed devices to the Print Group
a. In the Print Groups list, select the group you want to add managed device(s) to and then
select the Managed Devices tab.
b. Click the Add Managed Device button. This opens the Select Device dialog.
c. Search for the device(s) you want to add, select them on the search dialog and click OK.
Step 5 – Set up Secure Queues
1. Create a queue in the Blueprint Collector servers. The process of creating a queue is the same as
adding a printer in Windows. You can use any printer port when creating a new queue.
2. Make the queue secure using the Blueprint Secure Queue Configuration tool.
a. Right click on any queue in the standard Windows Printers and Faxes screen and then select
Blueprint Secure Queue Configuration.
b. In the Blueprint Secure Queue Configuration dialog, select the queue(s) that you have just
created, and then click the Secure Queue button. This opens another Secure Queue
Configuration dialog.
c. In the dropdown list box, select the Print Group that will be assigned to the queue(s), and
then click OK.
Step 6 – Validate the Secure Release Here deployment
1. Send a number of print jobs to the new Secure Queue.

2. Go to one of the managed devices. Authenticate and release your print jobs. The print jobs should
print on the device that you are currently standing in front of.
3. Repeat for each managed device.
Post Secure Release Here Configuration Checklist

After configuring Secure Release Here, use the following list to double-check your setup:
l All print servers that will publish secure queues have a Blueprint Collector component installed.
l All Collectors are registered with the Analyst (i.e. they must appear on the Server > Servers screen
at the Analyst).
l All of the Windows print queues that employees will print to have correct domain permissions and
are marked as secure in the Blueprint Secure Queue Configuration tool.
l All devices that jobs will be released at have been recorded in Blueprint Enterprise. Check on the
Device Management > Devices screen in Blueprint Administrator.
86
l All terminals that employees will log on to in order to release print jobs have been recorded in
Blueprint Enterprise. Terminals must be associated with both the devices they release jobs to and
the Collector servers that control them. Check on the Device Management > Terminals screen in
Blueprint Administrator.
l Terminal devices have been configured to communicate with Blueprint Enterprise. The method for
doing this will differ depending on the type of terminal—usually it involves accessing a
configuration menu at the device itself, or navigating to a web server hosted on the device.
l The method of authenticating employees at terminals has been set up. This is determined by the
Authentication Method specified for each terminal. Authentication scripts can be reviewed on the
Device Management > Authentication Methods screen in Blueprint Administrator.
87
Configuration Guide Employee Identification
Employee Identification
Blueprint Enterprise includes a powerful employee identity and authentication model designed to handle
a wide range of customer needs. This model is used by both the Blueprint Enterprise reporting engine as
well as by Secure Release Here®.
Identifiers
An identifier is a string or piece of data that represents a given fact about an employee, including data that
uniquely identifies an employee. Blueprint Enterprise supports three different identifier types.
Identifier
Description Precedence
Type
An employee’s unique HR identifier (e.g. his payroll employee number).

Employee In Blueprint Enterprise, an employee can only have one Employee 1
identifier.
An employee’s unique network identifier (e.g. his Active Directory

username, SAP username). While an employee ideally has only one
Network 2
Network identifier, Blueprint Enterprise supports an employee having
multiple Network identifiers.
An employee’s unique card identifier (e.g. the number on his proximity

Card badge). Blueprint Enterprise supports an employee having multiple Card 3
identifiers.
The identifier types have a set hierarchy or precedence order, as listed above. This order is important
when mapping identifiers. An identifier can be mapped to another identifier (e.g. an employee’s card ID
can be mapped to that employee’s network ID). This allows Blueprint Enterprise to effectively create a
hierarchy of identifiers that belong to a specific employee.
An identifier can only be mapped to another identifier if the “mapped to” identifier’s type has a smaller
precedence number than the “mapped from” identifier’s type (i.e. a card type can be mapped to a
network type, but a network type cannot be mapped to a card type).
When an identifier is mapped to another identifier, the identifier it maps to is called the employee’s “root”
identifier (when that identifier itself does not map to another identifier). For example, if a card identifier is
mapped to a network identifier and the network identifier does not map to an employee identifier, the
network identifier is called the “root” identifier for the employee. However, if that network ID does map to
an employee identifier, the network identifier is not the “root” identifier; the employee identifier is called
the “root” identifier for the employee.
This means that:
88
l An Employee identifier must be a root identifier (i.e. it cannot be mapped to another identifier). It
may have multiple Network and/or Card identifiers mapped to it.
l A Network identifier may be mapped to a single Employee identifier and may have multiple Card
identifiers mapped to it. It can also be a root identifier; if employees have only one Network
identifier, there is no need to map the Network identifier to an Employee identifier.
l A Card identifier may be mapped to a single Employee or Network identifier. It is only a root
identifier if it is not mapped to any other identifiers; however, this is not a useful configuration.
The following examples illustrate some common scenarios:
l Company A is only concerned with print job tracking; each employee has only one network
identifier. The only identifiers that are managed in Blueprint Enterprise will be the Network
identifiers that are recorded with tracked print jobs.
l Company B runs a Secure Release Here™ system. Employees log on to terminals with proximity
cards to release jobs printed against their network IDs. Blueprint Enterprise will need to map the
card identifier for each employee to their correct network identifier so that they can retrieve their
print jobs.
How Are Identifiers Used?

The identifier model serves two major roles in Blueprint Enterprise.
1. When tracking printing back to the employee, the identifier model can be used to handle an
environment where a single employee can have multiple network identifiers.
2. When implementing Secure Release Here, the identifier model can be used to allow employees to
authenticate using a different identifier from that used to submit the print job.
Reporting
For reporting purposes, identifiers and their mappings are published in the Reporting database. This
applies to all of the Blueprint Enterprise applications (e.g. Print and Copy Accounting, Departmental
Chargeback, Policy Print, Secure Release Here, etc). Identifiers can be managed manually using the
Employees >Employees screen in Blueprint Administrator (refer to the “Blueprint Online Help” for more
details on that specific screen) or imported using the Blueprint data imports infrastructure.
If your environment has only one network identifier per employee and you are only using Blueprint’s
Print Accounting application, you will not need to map or manage identifiers. Blueprint will automatically
add an employee’s network identifier to the Reporting database when it detects that network identifier in
the printing activity data.
User Display Name

Display name is the name that is displayed for a user in a Report, which is typically found under the ‘User
Information’ section of a report. By default, Blueprint follows a set of rules to determine which of the
user's identifiers is to be displayed in the Reports for a user.
The Display Name is determined as follows:
89
l By default, the user’s Network ID will be used as a Display Name. If the user has more than one
network ID, the oldest Network ID will be used.
l If the user does not have a Network ID, the next preferred identifier is the Employee ID followed by
the Card ID.
Secure Release Here

Secure Release Here must support employees using different identifiers to submit and retrieve print jobs.
This information is published in the Reporting database (using the same import mechanisms listed in the
“Reporting” section above). The information can also be retrieved real-time from your directory
services/authentication system using a Blueprint authentication method.
Authentication Methods
Blueprint uses Authentication Methods on both or either of the following components:
l Terminals (.e.g iMFPs, Omegas)

l Tracker (e.g. Mac Tracker)
Blueprint creates a default Authentication Method called "Standard Authentication Method" on

installation. This method supports any numeric card format and authentication against Active Directory.
Terminals
On Terminals, an Authentication Method is used to determine how users are authenticated at terminals
when releasing print jobs. It determines the identification information required, where to go to
authenticate it (e.g. a network domain or online authentication system) and what identifier(s) should be
used to retrieve print jobs and record transactions.
Every terminal is associated with an Authentication Method. Terminals provide the interface for users to
enter their authentication details. What happens to those details and how they are authenticated is
determined by the Authentication Method associated to the terminal they are using.
Tracker
If the Unauthenticated Print feature is enabled on the Tracker, an Authentication Method is used to
determine how unauthenticated users will be authenticated when submitting print jobs from a
workstation. Unauthenticated users are users who log on to workstations using local accounts instead of
a network account.
When an unauthenticated user prints a job from a workstation, the user will be prompted for their
corporate username and password. Depending on how the Authentication Method is configured for the
Tracker, the user credentials are validated against the LDAP, Active Directory, or Local User Accounts.
Blueprint allows only one Authentication Method for the Tracker. This setting is propagated to all the
Blueprint Collectors upon replication.
90
For more information, refer to the Unauthenticated Print feature in the "Blueprint Configuration Guide"
found in the Documentation folder of the Blueprint disk image.
Authentication Types
There are two types of Authentication Methods:
l Standard
l Advanced (Script)
Standard Authentication Type

Standard Authentication type is the primary and recommended type for authentication. This type allows
you to simply configure the authentication workflow using the Blueprint Administrator. The Standard
Authentication method supports the following workflows:
l Logging on using a card and finding the Network ID that belongs to that card in the Blueprint
database
l Registering an unknown card (i.e. if card cannot be found, prompt the user for their network
username and password)
l Authenticating a username/password against Active Directory
l Authenticating a username/password against the local machine's accounts (i.e. for testing)
Permitted Logon Options
The Standard Authentication type supports three types of logon. Employees can log on to the terminals
by entering their network logon ID and password, by swiping their card or both. A standard
authentication type should have at least one User Logon and Registration options:
91
User Logon
User Logon Description
Selecting only this option allows employees to authenticate to a terminal

using a card. The employees' card ID must match a card ID in the Blueprint
database. If the card ID is not found in the database, the terminal will
Users can logon using a return a message "Invalid Logon ID or password".
card
You can however enable card registration so that new or unregistered
employees can authenticate at the terminals. For more information,
please refer to the " Registration" section on page 93.
With this type of logon, employees authenticate themselves against an

external database, for example Active Directory. Selecting only this option
allows users to log on at terminals only by using their Network ID and
password (if available).
You can choose which system to authenticate against:
Users can logon using a l Active Directory

Network ID and l LDAP
l Local User Accounts - this simply verifies the username/password
password
against the server's local account database. This will be mostly used
for demonstration purposes.
If using Local User Accounts for authentication, you must enable

the guest account on the local machine. This allows users to
authenticate without a password.
Users can logon using a

Selecting this option enables users to login using either a card or network
card or network ID and
ID and password combination.
password
92
Registration
Registration Description
This option works in combination with either of the following User Logon
options: "Users can logon using a card" or "Users can logon using a card or
network ID and password".
Selecting this option enables card registration1, which lets new employees
Users can register a card or unregistered employees authenticate at the terminals even if their card
with their network ID IDs are not in the Blueprint database.
However, card registration requires that the employees' card formats can
be identified by Blueprint and employees have an account in the Active
Directory or the local database. For more information about defining card
format rules, Refer to the "Card Format Rules" section on page 98.
Users will not be able to

Select this option if you want to disable card registration at the terminals.
register a card
If the Standard Authentication Method does not meet your needs, please contact Pharos Systems.
1The Card Registration feature must be supported by the IMFP or Terminal that you are using.
Advanced Authentication Type

When dealing with scenarios not supported by the Standard authentication type, you can use the
Advanced authentication type. The Advanced authentication type enables you to implement custom
scripts to authenticate users.
Scripts are written in the C# language. Programming experience is required to be able to write a script. For
more information on how to write scripts, Refer to the "Appendix: Authentication Scripts" section on page
155.
In most cases, we expect that you will need to contact Pharos Systems with your scripting requirements,
so that we can develop a script for you.
Blueprint Enterprise version 4.2 and earlier are shipped with a set of standard scripts: Basic,
Blueprint- Card Exists, Blueprint-Card Translation , Active Directory, and LDAP. When upgrading
Blueprint from an earlier version, this set of standard scripts will be retained.
Managing Authentication Methods

Authentication Methods are added, edited, tested, and deleted on the Device Management >
Authentication Methods screen on the Analyst.
93
Adding a New Authentication Method

The Authentication Methods screen in the Device Management section allows new authentication
methods to be created and existing authentication methods to be edited.
When creating an authentication method, you can select one of the two types of authentication, either
Standard or Advanced.
Adding Standard Authentication Type
1. Click the Add button on the Device Management > Authentication Methods screen toolbar. A
new authentication method record appears in the main list.
2. In the Authentication Method field, enter a name that will be used to identify the authentication
method elsewhere in Blueprint Administrator.
3. Under the "Where this Authentication Method is Used", select whether the Authentication
Method is to be used to authenticate users in unauthenticated print environments (i.e. when users
log into their workstations using a local machine account rather than an account validated against
a central directory system). If the Trackers option is ticked, when an unauthenticated user prints,
the user will be prompted to enter their network ID and password credentials. These credentials
will be validated against the Active Directory or LDAP, depending on the option you select on Step
6. Take note that unauthenticated print is enabled from the Tracker. For more information, refer to
the "Blueprint Configuration Guide".
By default, the Terminals option is grayed out and cannot be edited. Once the Authentication
Method has been assigned to a Terminal, this option will automatically be ticked/checked on.
4. Select the "Standard" Authentication Type.

5. Under the Permitted logon options at a device, select how users will log on to the system. You can
select a User Logon and Registration combination depending on your requirements.
a. User Logon- This option determines how users can logon to the terminals. Select from any
of the following options:
l Users can logon using a card

l Users can logon using network ID and password.
l Users can logon using a card or network ID and password.
b. Registration - This options determines whether to allow a user to self-register from

the terminals using their card.
l Users can register a card with their network ID
l Users will not be able to register a card
6. In the Authenticate network ID and password against, select where to authenticate the user
against. You can choose from three different options: Active Directory, LDAP, and Local user
accounts.
7. If you have enabled card registration (i.e. set the Registration option to Users can register a card
with their network ID), you can configure the card format rules that will be applied to this
94
authentication method in the Card Formats tab or you can just use the default card format rule.
For more information on how to configure card formats, Refer to the "Card Format Rules" section
on page 98.
8. Click Apply.
A new Standard Authentication Method entry is added to the Blueprint Database. This authentication
method can then be associated with a terminal.
For Omega terminals, make sure that the Authentication Method property ( Device Management
> Terminals > Omega-PS-150 Configuration tab > Logon category) of the terminal is set to "Server
Config" and not "Terminal Config". Selecting "Server Config" enables the authentication method
defined in the server and ignores the logon settings configured in the Logon category for the
selected terminal.
Adding Advanced (Script) Authentication Type
1. Click the Add button on the Device Management > Authentication Methods screen toolbar. A
new authentication method record appears in the main list.
2. In the Authentication Method field, enter a name that will be used to identify the authentication
method elsewhere in Blueprint Administrator.
3. In the Authentication Type section, select Advanced (Script).
4. In the Permitted logon options at a device section, select how users will log on to the system.
a. User Logon- This option determines how users can logon to the terminals. Select
from any of the following options:

l Users can logon using network ID and password
l Users can logon using a card or network ID and password
b. Registration - This options determines whether to allow a user to self-register from

the terminals using their card.
l Users can register a card with their network ID

l Users will not be able to register a card
5. In the Designer tab, enter the code for the script. You can copy and paste this from a text file.
Make sure that the User Logon and Registration options that you have selected match your
authentication script.
6. Test the script using the controls on the Tester tab.

7. Click Apply.
For more information about scripting, Refer to the "Appendix: Authentication Scripts" section on page
155.
95
Editing an Authentication Method

Authentication Methods can be edited or deleted from the Device Management > Authentication
Methods screen of the Blueprint Administrator.
To edit Standard Authentication Type, select the Authentication Method that you want to edit and then
tick the options that you want and click Apply.
To edit Advanced Authentication Types (Scripts), Refer to the "Appendix: Authentication Scripts" section
on page 155.
Deleting an Authentication Method

To delete an authentication method, select the authentication method that you want to delete. Click the
Delete button the Authentication Methods toolbar.
Deleting an Authentication Method associated to one or more terminals may cause the terminals
to stop functioning.
Card Registration
Card Registration1 enables employees to register themselves into the Blueprint system at a terminal. The
registration process associates their card ID with their current network logon ID and password. No further
administrator assistance is required. This feature is useful for new employees or employees whose cards
have not yet been associated with a network logon ID and password.
To register at a terminal, employees must have a valid card and an active account in the Active Directory.
At the terminal, employees will be prompted to swipe their card and then enter their network logon ID
and password. If the network logon ID and password exists in the Active Directory, registration will be
successful. The terminal will now show a list of the employee's print jobs (if any). The employees can then
print or cancel their job.
Supported Scenarios
The card registration feature supports several user scenarios. The following section gives you some
examples of typical employee scenarios that are supported by card registration.
First time user
An employee has been issued a new card. Both the card ID and the employee are not in the Blueprint
database. The employee logs on to a terminal using their card for the first time. Registration is completed
by entering network logon ID and password. After completing registration, a new employee account is
1Ensure that your terminals and/or iMFPS support the Card Registration feature of Blueprint.
96
created in the Blueprint database with the card ID added as an identifier of the employee. The employee
should be able to release subsequent print jobs from the terminals using only their card.
Replacement card for lost or damaged cards
An employee has been issued a replacement card (never used) for a lost or damaged card. The employee
is in the Blueprint database and is linked with the lost or broken card ID. However, the replacement card
has never been used so it is not in the Blueprint database. At the terminal, the employee will be prompted
to register their card. The employee then enters their network logon ID and password. If the network ID is
validated, the card ID will be added as a child identifier of the network ID in the Blueprint database. Any
other cards associated with this employee's network ID are then unlinked.
Re-issued card
The site administrator has to "unlink" the card ID from the previous owner before another employee is
issued with that card as a replacement card. After the card is unlinked, the employee can now register the
re-issued card with their network logon ID and password. If the network ID is validated, the card ID will be
added as a child identifier of the network ID in the Blueprint database. Any other cards associated with
this employee's network ID are then unlinked.
Setting up Card Registration

This section will guide you through the process of setting up a working Card Registration system. Each of
the steps is discussed below.
To set up Card Registration:
1. Enable card registration on the relevant Authentication Method. For more information, please
refer to the "Enabling Card Registration" section on page 97.
2. Configure one or more card format rules on the relevant Authentication Method. For more
information, please refer to the "Card Format Rules" section on page 98.
3. Associate the Authentication Method with a Terminal.
Enabling Card Registration

You can enable the Card Registration feature from the Device Management > Authentication Methods
screen of the Blueprint Administrator.
When creating a new Standard Authentication method, card registration is enabled by default.
To enable card registration:
1. In the Device Management > Authentication Methods screen, select the Authentication method
that you want to enable the card registration from.
97
2. In the Permitted logon options

a. In the User Logonsection, select any of the following options:
l Users can logon using a card or network ID and password
b. In the Registration section, select Users can register a card with their network ID.
3. Under the Authenticate network ID and password against, select where you want to authenticate
the network ID and password against. The options are: Active Directory, LDAP, and Local user
accounts.
4. Configure the card format rules that will be applied to this authentication method in the Card
Formats tab. You can also use the default card format rule. For more information on how to
configure card formats, Refer to the "Card Format Rules" section on page 98.
5. Click Apply.
Card Format Rules

If you have created an authentication method that allows users to authenticate at terminals by using their
card, you must add card format rules so that the employee's card will be identified by Blueprint.
Card format rules are rules that are used to validate, extract, or transform card IDs for user
authentication. Card IDs are validated by comparing the format of the raw card ID with the validation
rules defined in the card format rule. Moreover, because the information on the card may not be in the
format in which you want to store the card ID on the Blueprint database, Blueprint provides you with the
ability to extract and transform card data.
Using the Card Formats tab in the Authentication Methods screen, you can create rules that will perform
initial validation and create the card ID format that you want.
Multiple Card Format Rules

An authentication method can support multiple card format rules. If there are multiple rules in an
authentication method, these rules are evaluated in the order they are listed in the Card Formats tab. The
first rule in the list to match the employee's raw card ID will be used. No further evaluation is performed.
For example, the default rule, which is normally on top of the list is evaluated first. If an employee's card
ID matches the validation rules defined in the default rule, this rule will be used. If the card ID does not
match the first rule, it goes to the next rule and so on until a match is found.
The following figure shows an authentication method with four card format rules. You can change the
order of the rules by using the green Up and Down arrows.
98
Managing Card Format Rules

You can add, edit, and delete card format rules in the Card Formats tab in Device Management >
Authentication Methods screen.
Adding a Card Format Rule

By default, an Authentication Method of type "Standard" always comes with one card format rule ("If the
card ID is of minimum length 1 and maximum length 60 and matches the regular expression \d*"). This
rule matches any card ID containing numbers only.
However, you can add one or more card format rules in addition to the default rule for every Standard
Authentication type.
The Card Format tab is available only for the Standard Authentication Type.
To add card format rules:
1. In the Device Management > Authentication Methods screen, select the Authentication Method
you want to add the card format rules to.
2. Go to the Card Formats tab. This opens the Card Formats dialog box.
3. In the Card Formats dialog, click the Add button (found on the right side of the dialog). This opens
the "Add Card Format Rule" dialog.
4. In the Card Format Rule Editor, configure the validation, extraction, and transformation rules as
necessary. For more information on how to set up a card format, Refer to the "Configuring Card
Format Rules" section on page 100.
Editing a Card Format Rule

You may want to change the card format rule that applies to a particular Authentication Method. The
Device Management > Authentication Methods screen allows existing rules to be edited. Card Format
99
rules are edited at the Analyst and replicated to Collectors as they are needed.
To edit a card format rule:
1. In the Device Management > Authentication Methods screen, select the authentication method
that contains the card format rule you want to edit.
2. Click the Card Formats tab. A list of all the rules belonging to the authentication method appears.
3. In the card format rules list, select the rule that you want to edit and click the Edit button. The Edit
Card Format Rule dialog box appears.
4. Perform the necessary changes (e.g. change the validation rules, change the extraction rules, or
change the transformation rules). For more information about card format rules, please refer to
the "Configuring Card Format Rules" section on page 100.
5. Click OK.
Deleting a Card Format Rule

To delete a card format rule:
1. On the Device Management> Authentication Methods screen, select the authentication method
from where you want to delete the rule(s).
2. Click the Card Formats tab.
3. In the Rules list, select the rule that you want to delete from the authentication method and click
Remove. Take note that this operation cannot be undone.
4. Click Apply.
Configuring Card Format Rules

Cards used for authentication must meet validation rules and optionally undergo extraction and
transformation. This section explains how to configure a card format rule using the Card Format Rule
dialog. This section also provides you with a detailed explanation of each of the fields that is needed to
properly set up card format rules.
The following figure shows you the Card Format Rule dialog, which is used to add and edit card format
rules. This dialog consists of three components: validation, extraction, and transformation.
100
Validation Format Rules
Validation format rules are used to ensure that card IDs meet certain criteria. Card IDs that do not meet
the format rules will be considered as invalid card IDs by the terminal.The validation format rules consist
of the following fields:
Fields Description
This is the minimum number of characters that a card ID must

Minimum Length
contain. By default this field is set to 1.
This is the maximum number of characters that a card ID must

Maximum Length
contain. This field is set to 60 by default.
101
Fields Description
This is the format used to validate the raw card ID. The format should
be expressed as a regular expression.
For example, you have a card ID that when scanned reads:

;1234567899991082?
You can define the Required Format as \d*, which means the card ID
must contain digits only.
Required Format
In the example, the raw card ID begins with the start sentinel
semicolon (;) and ends with the end sentinel question mark
(?). These sentinels are stripped by the terminal. Some
terminals strip start and end sentinels by default. However,
some terminals may not have this option "on" by default. It is
best to check that your terminals are configured to strip the
start and end sentinels of the card ID.
Extraction and Transformation Format Rules
Raw card IDs may contain very long sequence of characters. For example, a raw card ID may contain 16
digits and various special characters. Extraction allows you to extract a portion of the raw card ID so that a
consistent part of the ID is used.
Extracted data can be transformed to meet defined card format and length requirements. For example,
we can transform extracted data by adding a character prefix or suffix.
The following table describes the fields used for extraction:
Fields Description
Specifies the side from which to extract the raw card ID. You can start
Starting from the x side
the extraction from the right side or the left side of the card ID.
Specifies the number of characters to skip from the raw card ID. This is
Skipping the first x characters
essentially the characters that will be ignored from the card ID.
Specifies the number of characters to be extracted from the raw card

Extract up to x characters
ID.
The following table describes the field used to apply transformation to the card ID.
102
Fields Description
Specifies where to pad the card ID - either from the left or the right
Pad on the x side
side.
Using the character The character that will be used to pad the card ID.
So that the card ID has at least

Final minimum length of the characters(excluding the prefix)
x characters
Extraction Example
To perform extraction, check the "Extract a subset of the Card ID" option and configure the extraction
fields. For example, you have a card ID in the following format :
;1234567899991082?
You want to extract only the last 4 digits of every card ID in the same format. You can set up the extraction
rules with the following settings:
l Starting from the left side

l Skipping the first 12 characters
l Extract up to 4 characters
In this example, the extracted data from the raw card ID ;1234567899991082? will be 1082.
Transformation Example
If the original format of the card is not in the format in which you want to store the card ID on the
Blueprint database, you can apply a transformation process.
To apply transformation to a card ID, check the "Pad the Card ID" option from the Card Format Rule
dialog box and set up how you want the padding to be implemented. Moreover, you can add a prefix or a
suffix to transform the card ID.
From the previous example, the result of the extraction is the last 4 digits of the raw card ID. Let's say you
want to use the extracted data and create a card format with an additional character to the left, you can
check the "Pad the card ID" option and configure the settings as shown in this example.
For instance, you want the card ID to be in this format B00001082 - starting with the letter B, followed by
4 zeros, and the extracted data. You can define the padding rules as:
l Pad on the left side

l Using the character 0
l So that the card ID has at least 8 characters.
l Add Prefix B
103
Configuration Guide Configuring Publication
Configuring Publication
This section guides you through the basic concepts of Publication and provides instructions on how to
configure Publication. The following topics are covered in this section:
l Publication
l Daily and Monthly Publications
l Viewing Publication Details
l Manually Publishing to the Data Warehouse
l Data Warehouse Publication Settings
Publications
Before data can be used for reports, it has to be published to the Data Warehouse (also called the
'Reporting Database'). In the context of Blueprint Enterprise, Publication is the process of summarizing
and transferring operational data to the Data Warehouse for analysis and reporting.
To ensure that reports include the most recent data, Blueprint automatically schedules Publication at
regular intervals - a daily publication and a monthly publication.
You can also manually run Publication when required. For information on how to run publication on
demand, please refer to the "Manually Publishing to the Data Warehouse" section on page 106.
Automatic Daily and Monthly Publications

Daily Publication runs automatically according to the time configured in the ‘’ 'Time of day for automatic
publication' setting. By default, Publication is scheduled to run once a day at 12:00 midnight local server
time. It publishes data from that day and also a set number of previous days as well, to account for data
that arrives late. The default number of previous days is seven; this can be modified by changing the ' Day
of previous data to publish' setting.
Each daily publication refreshes the data in the Data Warehouse for the last 7 days (inclusive of the
current day). For example, the daily publications runs on 14th November 2011. It updates data for 8th to
14th of November.
Once a month, the daily publication is replaced by a monthly publication, which publishes and closes the
previous month's data. This typically runs shortly seven days after the beginning of the following month.
When the previous month’s data is closed, it can no longer be accessed by automatic publication.
Settings that affect Publication are available on the Reporting > Settings screen in Blueprint
Administrator. For detailed information about these settings, please refer to the "Data Warehouse
Publication Settings" section on page 107.
104
Viewing Publications Details

You can monitor the status of a publication in the Reporting > Publications screen of Blueprint
Administrator. It shows a record of all the automatic publications including additional information such as
the date and time it ran, the date range of the data analyzed, the result of the publication (success or
failure), and so on.
Details
Details of each publication are displayed on the Publications screen. Publications are listed by their start
and end dates, data export dates, and the result of the publication(success or failure) .
Full details for each publication are displayed on the Details tab:
Detail Meaning
Publication Initiated
The date and time at which the publication was initialized.
Date
The start date of the published report date range.

Data Export Start Date After a fresh install, this date will be set to the 'Start Date' of your Blueprint
license.
Data Export End Date The end date of the published report date range.
Result The result (Success or Failure) of the publication.
Duration How long it took to finish the publication process.
The following details summarize the information that is recorded from publishing to the Data Warehouse.
Detail Meaning
This could either be:
Data Export Type l Manual

l Automatic Daily
l Automatic Monthly
Jobs Analyzed The number of jobs analyzed during publication.
Jobs Excluded The number of jobs excluded in the publication.
Meters Analyzed The number of meters analyzed during publication.
Meters Excluded The number of meters rejected (due to meters going backward etc).
105
Detail Meaning
The total number of black and white pages recorded across all devices within
Black & White Volume
the date range.
The total number of color pages recorded across all devices within the date
Color Volume
range.
Total Volume The total number of pages recorded across all devices within the date range.
Total Cost The total cost analyzed for the publication.
Viewing Publication Log Files

The Log tab displays a detailed log of the currently selected publication, providing detailed information
about any errors that may have occurred. Log files can help to troubleshoot publication errors.
The import log may be too long to be displayed on the Log tab in its entirety. You can find the full
Publication log files in the default location, which is typically in the Application Data directory for All
Users. Depending on your Operating System, you may find the log files in either of the following paths:
l C:\Documents and Settings\All Users\Application Data\ PharosSystems\Blueprint\Logs\

DataTransformHistory
l C:\ProgramData\PharosSystems\Blueprint\Logs\ DataTransformHistory
The log records are saved as text files with a .log extension. The name of the log files are based on the date
and time when the log was captured, for example, 20110610_145145.log.
Manually Publishing to the Data Warehouse

While Blueprint automatically publishes data to the Data Warehouse, you can run publication manually
when required.
To manually publish data to the Data Warehouse:
1. Open the Reporting > Publications screen in Blueprint Administrator.

2. Click the Publish to Data Warehouse button. This opens the Publish to Data Warehouse dialog.
3. Select the type of Publication you want to complete. There are three options to choose from:
l Run the equivalent of the nightly analysis - Re-runs the equivalent automatic daily
publication.
l Re-close the last closed month - This re-runs the equivalent automatic monthly publication.
This may be necessary if new data for the month is received after the monthly publication. If
the 'last closed month' is May 31, 2011, selecting this option will publish data from 1 May
2011 to the current date and time.
l Re-analyze a custom date range - Publishes data according to the date range specified. Take
note of the valid start date shown. Make sure that you select a date from within these
periods only.
106
4. Click the Publish button.
After publication, details and logs relating to the publication are also shown.
You can change the default daily automatic publication in the General tab of the Reporting >
Settings screen.
Data Warehouse Publication Settings

The Settings screen in the Reporting section contains a number of settings that affect Data Warehouse
publications.
General
The General tab contains settings that affect the general operations of the Data Warehouse publication.
107
General
Setting Meaning
This property determines the time of day that automatic publication to the
Data Warehouse should run. By default, automatic publication is set to run
Time of day for automatic at 12:00 midnight.
publication
Pharos recommends that automatic publication should occur outside of
regular business hours.
The default paper size used for costing. By default this value is set to 'Letter'.
Default meter read paper
size To change the paper size, click the drop-down list box and select the Paper
Size you want.
This property specifies if the Site Monitor feature is enabled or not. After a
Blueprint install, this setting is enabled by default and is integrated with the
Site Monitor installed on the same machine where the Analyst is installed.
Time of day to import device meter data- If Site Monitor is enabled,

Blueprint is set to collect device meters from Site Monitor automatically.
This setting specifies the time of day that determines when Blueprint collects
device meter data from Site Monitor. By default, it is set to 2:00 a.m. daily.
To disable Site Monitor, uncheck the Enable Site Monitor integration

checkbox.
To enable Site Monitor, check the Enable Site Monitor integration

checkbox, and then select whether to integrate with a local Site Monitor or a
remote Site Monitor.
Enable Site Monitor l Integrate with a local Site Monitor - Select this option if Site Monitor
Integration is installed on the same machine as the Blueprint Analyst.
l Integrate with a remote Site Monitor. Select this option if you want
to connect to a Site Monitor installed on a remote machine. You
must provide the following details if connecting to a remote machine.
o Site Monitor Server Address - Enter the IP address or
hostname of the remote Site Monitor machine.
o Network path for Site Monitor import files. Enter the
location of the Blueprint "AppData" directory. This is
folder where Site Monitor gets the connections.txt file.
It is typically in C:\Documents and Settings\All
Users\Application Data\PharosSystems\Blueprint.
This path requires a UNC shared path in the form
\\servername of the Blueprint server\share name of
the Blueprint Appdata directory (e.g.
108
Setting Meaning
\\BPAnalyst2k8\BPAppData).
Ensure that the account under which the “Pharos

Systems Site Monitor” service logs on as has read/write
permission on the Blueprint AppData directory.
Daily Publication
Setting Meaning
This property specifies the number of previous days of data to republish

to the Data Warehouse. This ensures that any late arriving data are
included in the reports.
The default setting is 7 days.
Publication will cover data ranging from x days ago to the current date,
where x represents the 'Days of previous data to publish’.
For example, today is May 19, 2011; publication will include data from the
past 7 days and the current data (12th May to 19th May). On the 20th,
Day of previous data to
publication will include data captured from the 13th to the 20th and so on.
publish
This cycle continues until after the close of the month.
109
Monthly Publication
Setting Meaning
The number of days to wait before initiating the monthly publication after
the end of the previous month.
The default setting is 7 days.
By default, an automatic monthly publication will occur 7 days after the

end of the month. This republishes data back to the start of the calendar
month. It allows for the collection of data relating to the month that may
not arrive until after the end of the month.
In the following illustration, data for the month of May will be published
to the Data Warehouse on the 8th of June. Data for June will be published
Day to wait before on the 8th of July.
initiating the monthly
publication
After a month has been closed, the publication will no longer modify the
previous month's data. However, Blueprint allows you to manually
republish data from the last closed month or from a specific date range
using the "Publish to Data Warehouse" action in the Reporting >
Publications screen.
Business Holidays
Blueprint takes public holidays into account when calculating costs over time. By default, Blueprint is set
up to account for US holidays, but different holidays can be substituted on this tab.
To add a new holiday:
1. Use the calendar controls to select the day that the holiday occurs on.
2. Enter a name for the holiday in the Holiday Name field (or select an existing name from the combo
box).
3. Click Set and click Apply.
Holidays do not recur automatically. You must enter a separate holiday entry for each year.
To remove an existing holiday:
110
1. Use the calendar controls to select the holiday.

2. Click Remove and then click Apply.
Removing a holiday only removes that instance of the holiday. You must remove each instance for
each year separately.
Business Times
By default, Blueprint uses a Monday to Friday working week with 8 business hours to calculate costs over
time. These details can be changed on this tab.
To configure the days in a working week:
Check or clear the boxes next to the week days listed under Business Days.
To configure the hours in a business day:
Edit the values in the Business Hours and Minutes fields.
Change Tracking
Blueprint can keep track of the changes made to an Employee ensuring that reports reflect the correct
value based on the data at a specific point in time. For example, employee ABC was associated with
Budget Center 1 three months ago and has now been assigned to Budget Center 2, data from three
months ago will reflect Budget Center 1.
Enabling Employee Change Tracking

You can enable or disable change tracking of certain emplo
yee attributes in the Change Tracking tab (found in the Reporting >Settings screen).
By default, Change Tracking is on (set to 'Yes') for all the available attributes.
To enable or disable Change Tracking:
1. Select an Employee Attribute and then click the drop-down button next to it.
2. Select from the following options:
l Yes - Turns Change Tracking on. Blueprint will keep track of the changes made to the
selected attribute of a given employee. For example, if an employee has changed
Location three times, these changes will be tracked by Blueprint and will be shown in
the reports appropriately.
l No - Turns Change Tracking off . Blueprint will not keep track of the changes and
overwrites the old value with the current value.
111
Managing Employee Change History

Using the Manage History button, you can either delete all change history or you can revert (roll back)
data back from a specific date.
l Clear all history and use current data - Selecting this option deletes all previous changes and uses
the latest value instead. For example, user ABC is associated with Budget Center 1 three months
ago and at present is associated with Budget Center 3. User ABC will be associated only with Budget
Center 3; the user's relationship with Budget Center 1 (and all other previous associations if
applicable) will be deleted. This is commonly used during the initial deployment phase. For
example, Blueprint is to be deployed, but there are no imports available for employee reporting
data. The employee data is available two months later; simply import that file and then clear all
history. This prevents the reports from showing the users having "Unknown" locations, Budget
Centers, Departments, etc.
l Revert Data to what it was at <date> - Selecting this option enables you to revert data from a
previous date when the data was known to be in a good/clean state. For example, you have
imported flawed Human Resource data, selecting this option enables you to restore your data to
its state before the import.
112
Configuration Guide Configuring a Costing Model
Configuring a Costing Model

This section describes what a Costing Model is and how to configure a Costing Model. The topics covered
in this section are:
l What is a Costing Model?

l Costing Model Examples
l Adding a Costing Model
l Configuring Cost Lines
l Associating a Costing Model to Devices
l Duplicating a Costing Model
l Changing Costing Models associated to Devices/Models
l Deleting Devices from a Costing Model
l Deleting a Costing Model
What is a Costing Model?

A Costing Model is a set of rules that determines the cost of print or copy jobs based on a combination of
Paper Sizes and device and job properties such as Device Type (e.g. Printer or MFD), Device Technology
(e.g. Inkjet or Laser), Paper Size, One-sided or Two-sided and so on. B&W Per Page Costs and Color Per
Page Costs are defined for each of the property combinations.
Devices calculate the cost of jobs according to the Costing Model associated with them.
A Costing Model uses a simple formula to determine the cost of a print/copy job:
Print or Copy Cost = Per Page Cost (B&W or Color) x number of pages
For examples of how this formula is applied to jobs in different scenarios, please refer to the "Costing
Model Examples" section on page 113.
Default Costing Model

A 'Default' Costing Model is created when Blueprint is first installed, containing an initial set of Cost Lines.
This Costing Model cannot be deleted or renamed. However, its Cost Lines can be edited.
Initially, all Devices are assigned the 'Default' Costing Model. This means that until you change the Costing
Model of a specific device; the costs specified in the 'Default' Costing Model apply to all the jobs.
For information on how to configure new Costing Models, please refer to the "Configuring a Costing
Model" section on page 113.
Costing Model Examples

The following examples illustrate how costs are calculated based on the sample Costing Model shown
below.
113
Example 1
User prints out two pages of 'Legal' with the following properties:
l Printed from a Laser printer

l One-sided
l Black & White
Use the following formula to compute for the cost:
Print or Copy Cost = Per Page Cost (B&W or Color) x number of pages
Print Cost = $0.07 x 2 = $0.14
Example 2
User prints out ten pages of 'Letter' with the following properties:
l Printed from an Inkjet Printer

l One-sided
l Color
The 'Letter' paper size is not defined, hence the 'Default' Paper size cost is applied.
Print Cost = 10 × $0.30 = $3.00
Getting Started with Costing Models

Configuring a Costing Model is a three-step process. To configure a costing model, go to the Reporting
> Costing Models screen and follow these steps:
114
1. Add a new Costing Model. For more information, Refer to the "Adding a Costing Model" section on
page 115.
2. Configure the Cost Lines and associated costs of the Costing Model. For more information, Refer to
the "Configuring Cost Lines" section on page 116.
3. Associate the Costing Model to Devices. For more information, Refer to the "Associating a Costing
Model to Device(s)" section on page 117.
Adding a Costing Model

You can add one or more Costing Models in the Reporting > Costing Models screen of Blueprint
Administrator.
To add a Costing Model:
1. In the Reporting > Costing Models screen, click the Add Costing Model button.
2. In the Costing Model field, enter unique name to identify the Costing Model.
3. In the Description field, enter descriptive text that gives more information about the Costing
Model.
4. Click the Apply button to save the changes.
This sets up a new Costing Model and uses the default 'Cost Lines'. The next step is to configure the Cost
Lines according to your requirements.
115
Configuring Cost Lines

After adding a Costing Model, you can now configure the associated costs to be applied to print and copy
jobs.
l If no Paper Size is selected, B&W Per Page Costs and Color Per Page Costs will apply to all paper
sizes.
l When a Paper Size is added, the table will extend to include cost lines for the specified paper size
together with 'Default' cost lines effective for the all other Paper Sizes.
By default, only the most common Paper Sizes are shown. To show other Paper Sizes, click the
More paper sizes link.
To configure Cost Lines of a Costing Model:
1. Click the Cost Lines tab. This displays the default Cost Lines as shown in the following figure.
2. Under Properties and Paper Size, tick the device properties and Paper Size(s) that you want to
charge for. As you select properties and Paper Sizes, the table on the left is populated with the
resulting property combinations.
3. For each property combination in the table, enter the Cost per page for B&W and Color.
4. Click Apply to save the changes.
After creating a Costing Model and configuring the Cost Lines, the next step is to associate the Costing
Model to Device(s).
116
Associating a Costing Model to Device(s)

Once you have created a Costing Model, you can specify the Device or group of Devices a particular
Costing Model applies to by associating it with one or more of the following:
l Devices - Associate one or more devices to the Costing Model. This overrides the Costing Model
associated with the Model or Manufacturer that the selected device(s) belong to.
l Models - Associate the Costing model to one or more Models. The Costing Model will apply to all
the Devices that belong to the selected Model.
l Manufacturers - Associate the Costing model to one or more Manufacturers. The Costing Model
will apply to all the Devices and Models that belong to the selected Manufacturer.
A Device can only belong to one Costing Model.
To add one or more Devices that the Costing Model will be applied to:
1. In the Reports > Costing Models screen, click the Included Devices tab.
2. Click the Add button. This opens a drop-down list of device category that you can add: Device(s),
Model(s), and Manufacturer.
3. In the next dialog box that appears, select one or more Device(s), Models(s), or Manufacturer(s)
that you want to associate to the Costing Model.
Duplicating a Costing Model

To simplify the process of configuring a Costing Model, Blueprint enables you to duplicate an existing
Costing Model.
To duplicate a Costing Model:
117
1. In the Reporting > Costing Models screen, select the Costing Model you want to duplicate.
2. Do one of the following:
l Click the Duplicate Costing Model button from the toolbar.
l Right click and then select Duplicate Costing Model.
This creates a clone of the Costing Model with ‘Copy of’ prefixed to the name of the selected Costing
Model. You can then modify it to include other information.
Changing Costing Models associated to Devices/Models

You can change the Costing Model assigned to a Device or a Model from the Devices Management screen
of Blueprint Administrator.
Changing Costing Model associated to a Device

To change the Costing Model associated to a Device:
1. In the Device Management > Devices screen, select the Device that you want to change.
2. Click the Costs tab and then click the ellipsis to search for the new Costing Model.
3. Select the new Costing Model that you want to assign to the Device and then click OK.
The Device is automatically added to the list of Included Devices in the newly selected Costing Model and
will be removed from the previously assigned Costing Model.
Changing Costing Model associated to a Model

To change the Costing Model associated to a Model:
1. In the Device Management > Models screen, select the Model that you want to change.
2. Click the Costs tab and then click the ellipsis to search for the new Costing Model.
3. Select the new Costing Model that you want to assign to the Model and then click OK.
Devices that belong to the Model is automatically added to the list of Included Devices in the Costing
Model.
118
Removing Devices from a Costing Model

Blueprint enables you to remove Devices that have been assigned to a Costing Model. This simply
disassociates the Device(s) from the selected Costing Model.
To remove Devices from a Costing Model:
1. Select the Costing Model that you want to remove Device(s) from.
2. Select the Device(s) or group of devices to delete. ( Press Ctrl-A to select all Devices or hold down
the Ctrl-key to select specific Devices).
3. Click the Remove button.
The removed Devices will be automatically associated with the 'Default' Costing Model.
Deleting a Costing Model

A Costing Model can be deleted directly from the Reporting > Costing Model screen of Blueprint
Administrator.
To delete a Costing Model, select the Costing Model you want to delete, and click the Delete button on
the toolbar.
When you delete a Costing Model, devices associated to this model will automatically switch to use the
Default Costing Model. Take note that once you have deleted a Costing Model, this operation cannot be
undone.
The Default Costing Model cannot be deleted.
119
Configuration Guide Configuring Pharos Systems' Site Monitor Lite
Configuring Pharos Systems' Site Monitor Lite

This section provides you with instructions on how to set up and configure Pharos System's Site Monitor
Lite. The following topics are covered:
l What is Pharos Site Monitor Lite?

l Installing Site Monitor
l Launching Site Monitor
l Site Monitor Administrator
l How Site Monitor works
l Manually Scheduling Discovery
l Manually Scheduling Collection
What is Pharos Site Monitor Lite?

Pharos Site Monitor Lite is a Simple Network Management Protocol (SNMP) monitoring tool designed to
collect device information and meters from printers and multi-function devices discovered by Blueprint
Enterprise. Information collected includes serial number, MAC address, make, model, total pages, total
pages color, etc. Site Monitor then sends captured device information back to Blueprint Enterprise.
Pharos Site Monitor Lite is a cut-down version of Pharos Site Monitor. It allows you to do the following
tasks:
l Discover devices and schedule subsequent discoveries

l Run Discovery
l Define Collection schedule
l View discovered devices
l View license information
120
Pharos Site Monitor Components

Database The Database stores all configuration and collected data.
Core Services is the primary component of Pharos SiteMonitor, which

performs the following:
Core Services l discovering devices using SNMP sweeps
l collecting device data, meter reads, and device status information
l exporting device feeds in various formats
This is the main user interface tool used to configure the Core
Services,manage Collection, display and managed collected data, and
Pharos Site Monitor monitor devices.
Administrator
It is typically installed with the Core Services and the Database. However, it
can also be installed on a separate machine.
Agents are installed to spread Collection tasks over multiple servers. If there
are no Agents, then the server where Core Services are installed will perform
Agent the Collection task and it will take the entire load.
Site Monitor Agent installs the 'Pharos Systems Site Monitor Agent' Service.
Installing Site Monitor

Site Monitor Lite is automatically installed when you install a Blueprint Analyst. Both the Core Services and
the Pharos Site Monitor Administrator are installed on any supported operating system except for
Microsoft Windows Server 2012.
Site Monitor on Windows Server 2012

When installing Blueprint Analyst on Windows Server 2012, only the Site Monitor Core Services is
operational. The Site Monitor Administrator does not support Server 2012. To use Site Monitor on Server
2012 you have two options:
l Install the Pharos Site Monitor Administrator on another (non-2012) machine and point it to the
Blueprint Analyst's Site Monitor Core Service. With this option, no extra configuration is required.
For more information, please refer to the "Installing Pharos Site Monitor Administrator Only"
section on page 122.
l Install both the Core Services and Pharos Site Monitor Administrator on a remote machine, and
then modify the Site Monitor settings in the Reporting > Settings tab to use the remote Site
121
Monitor.For more information, please refer to the "Installing Core Services and Site Monitor
Administrator" section on page 123.
Pre-requisites
Before installing Site Monitor, you must first install the following pre-requisites:
l .NET Framework 3.5 Service Pack 1

l Microsoft Management Console (MMC) 3.0
Supported Database Engines

l Microsoft SQL Server 2005 (Express, Standard, or Enterprise Edition)
Installing Pharos Site Monitor Administrator Only

Follow these instructions to install Pharos Site Monitor Administrator on a remote machine.
1. Access the Site Monitor install media from the computer where you want to install Pharos Site
Monitor Administrator.
2. Run SiteMonitor.msi.. The Welcome screen appears.
3. Read and accept the terms of the license agreement.
4. In the Custom Setup screen, select the Administrator component and specify the installation
location. Make sure to unselect both the Core Services and the Agent.
5. In the Core Services Server field, enter the server name of the machine on which you installed the
Core Service component of Site Monitor.
122
6. Click Install to begin the installation and once the installation is complete, click Finish to exit the
installer.
Installing Core Services and Site Monitor Administrator

Follow these instructions to install both Core Services and Site Monitor Administrator on a remote
machine.
1. Access the Site Monitor install media from the computer where you want to install Pharos Site
Monitor Administrator.
2. Run SiteMonitor.msi. The Welcome screen appears.
3. Read and accept the terms of the license agreement.
4. In the Custom Setup screen, select both the Core Services and the Administrator components and
then specify the installation location. Make sure to unselect the Agent.
5. In the License File Input screen, browse to the location of the license file.
6. In the Database Settings screen, perform the following:
l Select the Database Server that the SiteMonitor database should be installed on.
l Select the Authentication Method to use. The options are SQL Server Authentication and
Windows Authentication. If you choose SQL Server Authentication, enter the SQL Server
Administrator Username and Password. Consult your SQL Server administrator for the
appropriate logon details to use. This logon account must be able to create databases.
l Specify a database operational user (SQL user that the SiteMonitor Service will use to
connect to the Database Server)
123
o If you want Site Monitor to automatically create an operational database user, just
tick the option “automatically create database operational user”. Site Monitor will
create a user called 'PharosSiteMonitorUser' and will generate a random password.
You can change this password later on in SQL Server.
o If you have an existing operational user, enter the appropriate details.
7. Click Install to begin the installation and once the installation is complete, click Finish to exit the
installer.
What's Next?
The next step is to configure Blueprint to point to the Site Monitor Server you have installed on a remote
machine. To do this, open Blueprint Administrator and then navigate to the Reporting > Settings screen.
Check the option "Integrate with a remote Site Monitor" and enter the following information:
l Site Monitor Server Address

l Network path for Site Monitor import files
For more information about these settings, press F1 on the Blueprint Administrator. This will open up the
Administrator Help.
Launching Pharos Site Monitor Administrator

To launch Site Monitor, go to Programs > Pharos Systems Site Monitor > Site Monitor Administrator.
Logon credentials are not required.
Site Monitor Administrator

The Pharos Site Monitor Administrator is the application used to configure and manage Site Monitor. The
following section describes each of the Site Monitor Administrator contexts.
124
l Blueprint Configuration - is used to manually discover devices, schedule Discovery, and schedule
daily Collection.
Blueprint Configuration Context
l Devices - is used to view devices discovered by Site Monitor (either through manual discovery or
collection task).
l License - is used to view the license information, such as the expiry date of the Site Monitor license
and the maximum number of devices that can be managed by Site Monitor.
How Pharos Site Monitor Works

Pharos Site Monitor Lite requires very little configuration. If the default settings (discovery and collection
schedule) are acceptable to you, no configuration is necessary.
The following section describes how Pharos Site Monitor works. This assumes that Devices have been set
up on your Blueprint Analyst server.
1. Blueprint provides Site Monitor with a list of active device connections.

2. Site Monitor runs a Collection against the device connections list provided by Blueprint.
3. Blueprint imports the device information collected by Site Monitor.
Blueprint exports active Device connections to Site Monitor
After Blueprint and Site Monitor are installed, a text file called connections.txt is automatically created
according to a pre-defined schedule in Blueprint. This file contains a list of hostnames or IP addresses of
125
active devices in Blueprint. After the initial export, the file is updated as devices are added and removed
from Blueprint.
By default, the export runs at 1:00 a.m. daily (server local time) ensuring that new devices added to
Blueprint since the last export are picked up.
The connections.txt file is created in the SiteMonitor directory of the Application Data, which is
typically found in C:\Documents and Settings\All
Users\ApplicationData\PharosSystems\Blueprint\.
Site Monitor runs a Collection task
By default, Site Monitor runs a Collection task at 12:00 midnight daily and uses the information supplied
in the connections.txt file
Running the collection task does the following:
l Discovers devices included in the connections.txt.

l Collects information and meters on those devices.
l Generates a device meter report in CSV format.
After the collection, newly discovered devices are added and old devices are updated with new
information in the Devices context.
Device meter import files are found in the SiteMonitor\Imports folder of the Application
Data\PharosSystems\Blueprint\.
Blueprint imports Device Meters
Blueprint collects the device meter report from Site Monitor. By default, the import takes place at 2:00
a.m. daily. You can change the time of day to collect device meter data from Site Monitor in the
Publications > Settings screen of Blueprint Administrator.
Configuring Manual Device Discovery

Before devices can be monitored or reported on, they have to be discovered by Pharos Site Monitor.
Discovery is the process of finding printers and Multi-Function Devices (MFDs) within the network.
In Site Monitor Lite, device discovery configuration is not required as it automatically uses the devices
already discovered by Blueprint Enterprise. However, if you want to discover devices not detected by
Blueprint, Site Monitor lets you configure and run network discoveries in the Blueprint Configuration
context.
The following steps give you an overview of how to configure and run manual Discovery:
126
1. Specify the network information of the devices that you want to manually discover.
2. Run the Discovery Task.
Specifying Devices to Discover

You can use any or a combination of these methods to specify the network information of the devices for
Discovery:
l Specifying an external file, which contains a list of network information of the devices that you want
to monitor.
l Manually specifying host names, IP addresses, CIDR ranges, and/or IP address ranges.
Specifying an External File

This method of Discovery requires you to have the external file ready. The file can contain combinations of
IP addresses, hostnames, IP address ranges, or Classless Inter-Domain Routing (CIDR) ranges. Both .txt
and .csv file formats are supported.
To specify a file, in the External File field, click the ellipsis to browse to the folder where your source
file is located. After specifying the host file, you can now run Discovery (manually or based on the
configured schedule).
External files should be on your local machine. If the file is located on a network share or if Site
Monitor does not have sufficient privileges to open the file, the file will be ignored and Site
Monitor will use previously known IP addresses instead (if present).
127
Manually entering Device network information

This method allows you to enter IP addresses and hostnames one at a time. It also accepts IP address
ranges and CIDR ranges.
To manually enter device network information:
1. Under the Network Hostnames, IP Addresses and Ranges section, click the drop down box and
select the type of network information that you want. The options are Hostname, IP Address, IPv4
Address Range, and IPv4 Classless Inter Domain Routing (CIDR). Every time you select any of these
options, a row is added. The following figure shows examples of various types of supported
network information.
2. For each row, enter the appropriate Value (e.g. 192.168.0.1 for IP address, 192.168.1.0/24 for
CIDR range).
3. Repeat the process for every device or range of devices that you want to add to the system.
After you have entered all the IP addresses, IP address ranges, and/or host names of the devices that you
want to monitor, you can either manually run the Discovery task or wait for the scheduled Discovery (by
default, every Sunday at 12:00 midnight server local time).
Running Discovery Manually

After entering the network information of the devices you want discovered, Discovery will run according
to the schedule that was defined. However, you can run the Discovery process manually.
To manually run Discovery, click the Run Discovery Task button in the Discovery Actions pane.
A progress bar denoting the progress of the Discovery process appears. It also shows other information
such as the number of devices scanned so far, the number of devices found, and the time it takes to run
the process.
After running Discovery, you can view all discovered devices in the Devices context.
128
Changing Discovery Schedule

By default, Site Monitor is scheduled to run Discovery every Sunday at 12:00 midnight (based on the local
time of the machine where Site Monitor is installed).If you want to change how often you want Discovery
to run, you can change the schedule in the Discovery Schedule section of Blueprint Configuration
context.
To change the default Discovery schedule:
In the Discovery Schedule section of the Discovery context choose when to run Discovery. Select from the
following options:
l Daily- Select the time at which you want Discovery to run.

l Weekly - Choose the day(s) of the week and the time at which Discovery is to run.
l Monthly - Select the day(s) within a month and the time of when you want Discovery to run.
l Repeat - In the drop-down box, select the frequency of when to run Discovery (e.g. every 15
minutes, every hour, and so on).
Changing Collection Schedule

A Collection Schedule is essentially a task that runs discovery against the file (connections.txt) provided by
Blueprint and the network information in the Blueprint Configuration context (if configured). It also
collects information on those devices and then generates device meter reports, which can then be
imported back to Blueprint.
Collection runs daily at 12:00 midnight by default. You can change the time the Site Monitor runs a
Collection to suit your requirements.
129
To change the default time, navigate to the Collection Schedule section of Blueprint Configuration
context.
130
Configuration Guide Configuring Scheduled Reports
Configuring Scheduled Reports

This section gives you an overview of Scheduled Reports, including how to configure them. This section
covers the following topics:
l What is Scheduled Reports?

l Scheduling a Report
l Testing a Scheduled Report
l Viewing Scheduled Reports
l Editing a Scheduled Report
l Manually Generating and Emailing Scheduled Reports
l Deleting a Scheduled Report
l Changing the Email Settings of a Scheduled Report
o Customizing the Email Message of a Scheduled Report
o Adding Multiple Recipients in a Scheduled Reports
o Changing Reply to Email Address
o Changing the From Email Address
About Scheduled Reports

Scheduled Reports enables customized or standard reports to be automatically generated and emailed to
specified recipients on a monthly basis. Report users no longer have to access the Blueprint to generate
reports; they can be set up to receive reports as email attachments in PDF format.
Here are a few examples of reports that can be scheduled in Blueprint to be sent each month:
l Send each Department Manager an Employee List and Usage report showing the print volume by
employee.
l Send the administrator an Enterprise Tracker Health report, showing the Tracker machines that
have not been heard from recently.
l Send the senior executives and managers a Dashboard report, showing a summary of key
performance metrics, volumes by category and function, and so on.
Reports are scheduled in the Reporting > Reports screen of Blueprint Administrator. Scheduling a report
is as simple as selecting which report you want to schedule, configuring the parameters of the report (e.g.
report date range), customizing the email notification message (if required), and adding the intended
recipients.
Scheduled Reports are designed to run and sent to recipients after the close of each month. The exact
timing depends on the "days to wait before initiating the monthly publication" setting in the Data
Warehouse Publication Settings. By default, this runs straight after publication which is seven days after
the beginning of the following month to account for late arriving data.
131
Specifying the dates and frequency of generating reports e.g. weekly or quarterly, is not
supported.
Scheduling a Report
Reports are scheduled in the Reporting > Reports screen of Blueprint Administrator.
If you are scheduling reports for the first time, you will need to configure the Email Server Settings
in the Servers > Settings screen.
To schedule a report:
1. In the Reports tab, select the report that you want to schedule. If the report has a filter type
parameter (e.g. filter by Department, Budget Center), select the desired Filter Type first.
2. Click the Schedule button. The Scheduled Reports tab will open.
3. In the Recipients text box, enter one or more email addresses to send the report to.
4. Optional: If you want to customize the email body (the email message that will be sent out with
the report), go to the Email Content tab and edit the message, otherwise the default email body
will be used. For more information, please refer to the "Customizing the Email Message of a
Scheduled Report" section on page 1. For more information, refer to the "Blueprint Configuration
Guide".
5. Click the Apply button to create the scheduled report.
The new scheduled report will be added to the Scheduled Reports tab of the Reporting > Reports screen.
The next step is to test the report to check if you have configured the correct report parameters.
Testing a Scheduled Report

After scheduling a report, you should test it to ensure if you have configured the report parameters
correctly before sending it to the intended recipients. This is also useful for checking what the report will
132
look like.
To test a scheduled report:
1. In the Scheduled Reports tab of the Reporting > Reports screen, select the report that you wish to
test.
2. Click the Test button on the toolbar.
3. In the Test dialog box that appears, enter an email address to send the test report to (typically your
email address), and then click the Test button.
If the test is successful, you should receive a copy of the report. If the test is unsuccessful, you should
review what you set up in the Scheduled Reports tab.
Viewing Scheduled Reports

You can view a list of all the scheduled reports on the Scheduled Reports tab of the Reporting > Reports
screen. Scheduled reports are listed by their report type, report name, date and time they were last run,
and the result of their last run (success or failure).
The tabs at the bottom of the screen display additional information about the currently selected
scheduled report. Some of these details can be edited; others are read-only. The following tabs are
available:
l Details
l History
l Email Content
Details
The Details tab displays more information about the selected scheduled report. The details shown vary
according to the report selected. Common parameters include the following:
Field Meaning
Read-only property indicating the type of report used (e.g. Dashboard,

Quickstart).
Report
This is the name that will be given to the PDF email attachment, which
will be sent to the intended recipient.
133
Field Meaning
The name of the Scheduled Report. This is the text that will appear as a
"subject" line in the email notification.
Scheduled Report
You can edit this field to specify a name that will uniquely identify the
scheduled report.
The date range to be covered by the report i.e. how far back you want to
display data for, relative to the current date.
Use the drop-down list box to choose the date range. The following date
range options are available. Note that 'N' stands for a variable number
that you define.
l Last N Month(s) - Includes data from N previous calendar

month(s). It covers the first day up to the last day of N previous
months.
l Last N Week(s) - Includes data from N previous calendar week(s).
It runs from Saturday to Sunday.
l Last N Day(s) - Includes data from N previous days.
l Include Current month/week/day - Check this button if you want
Report Date Range to include the latest published data.
The default report date range shown in the Scheduled Reports

depends on the date range selected from the Reports tab. For
example, if you selected Monthly Data, the default date range in
the Scheduled Reports tab will be Last N months. If you want to
change it to Last N Days or Last N Weeks, simply select the
desired range from the drop-down list box.
Some reports, such as the Dashboard Report, only have monthly

data available; therefore the available date range is Last N
Months only.
For reports with filter types (e.g. Employee List and Usage Report), this
field indicates the type to filter the report by. For example, you can
schedule a report to be filtered by Department Group or Budget Center.
Depending on the report chosen, the available filter type may vary.
Filter Type Examples include:
l Budget Center
l Building
l Department Group
134
Field Meaning
l Floor
l Location Group
l Manager
l Position
Before scheduling a report, you must select a filter type from the
Reports tab.
Based on the filter type you have selected, configure the value that you
want to filter the report by. This is configured in the Recipients section
of the Details tab.
Filter Value
For example, if you have selected Department Group as your filter type,
when configuring the email recipients, you must browse for the specific
Department Group to filter the report by for that email recipient.
The email addresses of intended recipients of the scheduled report.

Multiple email addresses must be separated by a comma or by pressing
the "Enter" key.
For reports with filter types, click the Add button to add more recipients
Recipients and then browse for the specific filter type.
An Exchange distribution list is allowed (e.g.

#HRDepartment@company.com).
History
The History tab shows the generation history for the selected scheduled report.
Field Meaning
Start Time The date and time at which the selected scheduled report was started.
End Time The date and time when the scheduled report was completed.
Indicates the result of the scheduled report. This will be one of:
Scheduled Report l Success
Result l Email errors i.e. if it failed to send the report to the intended
recipient(s).
135
Field Meaning
Displays a summary of any event or error related to the selected scheduled

report, for example, whether the report has been sent to all the intended
Messages recipients.
Click on a message to view a detailed description about it.
Email Content
The Email Content tab shows the content/message that the specified recipients will receive with the
report.
You can leave the default email message or you can customize it if necessary.
If the "Customize the email message body for this scheduled report" is unchecked, the default email
message body is used.
Editing a Scheduled Report

Existing scheduled reports can be modified from the Scheduled Reports tab of the Reporting > Reports
screen. You can add or delete email recipients or change the date range of data to report on.
To edit a scheduled report:
1. In the Scheduled Reports tab, select the report that you want to modify.
2. Change the report details (e.g. Recipients, Report Date Range) as desired.
The next time the scheduled report runs, the new settings/parameters will be applied.
Manually Generating and Emailing Scheduled Reports

Although scheduled reports run automatically (based on automatic monthly publication), you can
generate and send reports manually when required. For example, when a scheduled report failed to run,
you can generate and send it to the intended recipient(s) manually.
Take note that the generated report will only include data that has been published to the Data
Warehouse.
Manually generating and emailing Scheduled Reports individually

To generate individual scheduled reports manually, from the Scheduled Reports tab, select the report
that you want to manually generate. In the toolbar, select the Send Selected Report button (see the
image below). If successful, you will receive a message specifying that the report was sent.
136
Manually generating and emailing all the reports

To generate and send all the available scheduled reports:
1. Open the Scheduled Reports tab.

2. In the Reports toolbar, select the Send All Reports button. If successful, you will receive a message
specifying that the reports were sent.
Deleting a Scheduled Report

Open the Scheduled Reports tab, select the report that you want to delete. On the tool bar, select the
Delete button. Click Yes to confirm deletion of the scheduled report.
137
Customizing the Email Message of a Scheduled Report

A scheduled report comes with a default report email message that can be customized. Email messages
are configurable by scheduled report, so it is possible to have different email messages per report.
The best practice is to add an email message body that explains why the email has been sent, what report
it contains, and how to get more information.
To change the email message sent out with the report:
1. In the Scheduled Reports tab, select the scheduled report and then open the Email Content tab.
2. Check the "Customize the email message body for this scheduled report". This will make the rich
text editing dialog box containing the message body editable.
3. Edit the email message template, and then click Apply to save the changes.
138
To revert to the default email message, simply uncheck the "Customize the email message body
for this scheduled report".
Adding Multiple Recipients in a Scheduled Report

Recipients of scheduled reports are configured in the Scheduled Reports tab of the Reports screen.
In most cases, multiple email recipients are added in the Recipients text box separated by commas.
However, if your report includes a filter type such as Budget Center, Department Group and so on, you
will see a different Recipients user interface (refer to the image below). You will need to enter a filter value
(based on the filter type selected in the Reports tab) for every email recipient added.
For example, if you have scheduled a Device List and Usage Report filtered by Department Group to be
sent to different Department Managers, you need to select a Department Group corresponding to each
email recipient.
To add multiple recipients with filter type:
1. In the Reports tab, select the report that you want to schedule.
2. In the Filter Type drop-down list box, select the type to filter the report by and then click the
Schedule button.
3. In the Details tab, configure the report parameters as desired.
4. In the Recipient(s) section, type the email address of the intended recipients, and then click the
browse button to select the filter value for that email address.
5. Click the Add button for additional recipients, and continue doing this for every recipient added.
6. Click Apply to save changes.
Changing the "Reply To" Email Address

The "Reply To" Email Address is the email address that recipients see when they click the Reply button on
their emails. By default, the "Reply" email address used in the scheduled reports is based on the address
139
set in the SMTP From Email Address field under the Server > Settings screen.
Normally, the "Reply To" and the "From" email addresses are the same. However, if you want replies to be
sent to a different email address, you can change the "Reply To" email address from the Email Settings
button of the Scheduled Reports toolbar.
To change the "Reply To" Email Address:
1. Open the Reporting > Reports screen, and then click the Scheduled Reports tab.
2. From the Scheduled Reports toolbar, click the Email Settings button as shown in the figure below.
This will open the Email Settings dialog box.
3. In the Email Settings dialog box, enter the desired email address .
Take note that this does not change the "From" email address on your scheduled report email.
Changing the "From" Email Address

The "SMTP From Email Address" is the address that the report recipients will see as the sender of the
Scheduled Report email. This is the address configured in the Servers > Settings screen of Blueprint
Administrator.
To change the email address displayed in the From field of the scheduled report emails, change the
SMTP From Email Address Field in the Servers > Settings screen to the desired email address.
140
Configuration Guide Configuring Unauthenticated Print
Configuring Unauthenticated Print

This section guides you through configuring the Unauthenticated Print feature in Blueprint Enterprise.
This section covers the following topics.
l What is Unauthenticated Print?

l User Workflow
l Getting Started with Unauthenticated Print
l Enabling Unauthenticated print from the Registry
l Configuring the Authentication Method for Unauthenticated Print
l Authentication Settings
What is Unauthenticated Print?

This feature allows printing for unauthenticated environments, i.e. users log into workstations using a
local machine account rather than an account validated against a central directory system, such as the
Active Directory.
This feature is enabled from the Tracker. When enabled, an unauthenticated user (e.g. a user who logs
into the workstation using a local account) will see the "User Authentication" pop-up window after
sending their print jobs. This pop-up requests the user's User ID and Password, which are validated
against the corporate authentication system (e.g. LDAP, Active Directory). The User ID is embedded with
the print job which identifies the user when they release these jobs at the print device. The Tracker will
treat all jobs as having been printed by the authenticated user instead of the logged-on user.
Here are a few situations where Unauthenticated Print can be implemented:
l Employees print from MAC OS X on a Windows environment (MAC OS X does not have a central
authentication system)
l Employees log into their workstations using a local machine account rather than an account
validated against a central directory system (e.g. Active Directory, LDAP)
l Employees print from their own laptops (those that do not need to authenticate to the central
directory system)
l Employees log in using guest accounts (they do not have an actual account on the computer)
l All employees log in using a single guest user account
User Workflow
1. On a computer with the Tracker installed and Unauthenticated Print enabled, the user sees the
following Pop-Up window after submitting a document for printing:
141
Microsoft Windows User Authentication Popup
Mac OS X User Authentication Popup
2. The user enters their network user ID and password and then clicks OK.
3. If the credentials are valid, the pop-up will disappear and the print job will be submitted.
If the credentials are invalid, the user will get the error message "Invalid login details. Please try
again." The user does not need to resubmit his/her print jobs. Print jobs are held in the Queue
until the user enters valid credentials.
4. The user goes to the terminal, authenticates, prints, and then collects their print jobs.
The Pop-up will appear ONLY the first time that a user prints during each session login on the
computer. Any subsequent print jobs will contain the user ID automatically and the Pop-Up is not
needed. However, once the user logs off, the credentials will need to be entered again for the first
print job of each subsequent session login.
142
Jobs will continue to print even when a user does not authenticate (i.e. cancels the authentication
pop-up) or when a user submits print jobs to a non-secure queue. However, the job will be logged
against the username Machine!Win!<Machine name> on a Windows machine and against the
Hostname\Username on a Mac OS X machine on both occasions. Moreover, if Policy Print is
enabled, the default policy will apply.
Getting Started with Unauthenticated Print

To configure Unauthenticated Print, complete the following steps:
1. Install the Tracker on each employee's machine.

l On Windows machines, install or upgrade the Tracker passing the additional argument
/authenticateusers on the installation command line.

l On Mac OS X machines, install the Mac OS X Tracker using the standard Mac OS install
packages (.pkg and .mpkg) or using standard Mac OS X deployment tools, such as LANDesk®
and Casper.
For more information on how to install the Tracker, refer to the "Tracker Deployment Guide" found in the
Deployment folder of the Blueprint disk image.
If a previous version of the Workstation Tracker is already installed on the users' workstations, you
can enable the Unauthenticated Print feature by changing the registry. For more information,
please refer to the "Enabling Unauthenticated Print from the Registry" section on page 144.
2. Configure the Authentication Method that the Tracker will use to authenticate users. For more
information, please refer to the "Configuring the Authentication Method for Unauthenticated
Print" section on page 143.
3. (Optional) Configure other User Authentication Settings if necessary (Tracker > Settings >
Authentication Settings). The default settings should be adequate, but if you want to customize
text on the Unauthenticated Print Popup window for example, you can modify the defaults from
the Authentication Settings tab of the Tracker > Settings screen. For more information, please
refer to the "Configuring Unauthenticated Print" section on page 141.
Configuring the Authentication Method for

Unauthenticated Print
You can create a new Authentication Method or alternatively edit an existing Authentication Method for
user authentication.
Take note that only one Authentication Method is required for Unauthenticated Print.
143
1. Navigate to the Authentication Methods screen.

2. In the Where this Authentication Method is used section, check on the Trackers option.
3. In the Authenticate network ID and password against section, select from any of the following
options: Active Directory, LDAP, or Local User Accounts.
4. Click Apply to save changes.
Enabling Unauthenticated Print from the Registry

The Unauthenticated Print feature is typically enabled by installing the Tracker, passing the additional
argument /authenticateusers on the installation command line.
However, if the Trackers have been installed without passing the argument /authenticateusers, you can
enable the Unauthenticated Print feature by changing the AuthenticationEnabled registry key to
1 in the following registry key location:
HKEY_LOCAL_MACHINE\SOFTWARE\PharosSystems\OutputManagement\PrintTracker\PrintProfiler
144
Authentication Settings
The options in the Authentication Settings tab of the Tracker > Settings screen affect how the
Unauthenticated Print feature works.
145
User Authentication
Settings Meaning Default
The amount of time an authenticated user ID is

cached in the workstation. This allows users to print
from the same workstation without having to
authenticate again.
Cache authenticated user
ID for a maximum of 12 After this period expires, the user will need to enter 12 hours
hours their User ID and Password in the workstation
again.
Logging off from the workstation also deletes the

authenticated user ID from the cache.
This setting is used by Mac OS X machines

exclusively. It is intended to be used when the User
Authentication dialog is being used purely to
identify users for Secure Release.
If configured, the User Authentication dialog will

appear only when a user prints to a Secure Queue.
Specify the string in the printer name of the queue

that should trigger the User Authentication dialog.
Pharos recommends using a printer naming
convention for secure queues to simplify
configuration. For example, you can add the string
“Secure” to the printer name of every secure queue
Authenticate the user for in your organization (e.g. BldgA109ColorSecure,
printer names that BldgB220BWSecure).
contain the string
Only users who send print jobs to a queue that
matches the string configured in this setting will
need to authenticate. If you want the User
Authentication dialog to be shown on first print
regardless of the queue printed to then leave this
blank.
If a user sends print jobs to a non-secure

queue or if a user cancels the
authentication, the job will be logged
against the "Hostname\Username", where
Username is the local account name
printing the job. Moreover, if Policy Print is
146
Settings Meaning Default
enabled, the default policy will apply.
User Authentication Dialog Text

Use these settings to modify the text of the User Authentication popup:
Settings Meaning Default Text
The text title that will appear on

Title Bar Text Print Login
the User Authentication popup.
The text that appears after the

Please enter your network user id and
Information Text Title bar. This text provides
password.
instructions to users.
This text is used as a label for

the user's identification on the
User Id Text User Id
User Authentication popup (e.g.
username).
This text is used as a label for

Password Text the user's password on the User Password
Authentication popup.
Authentication Failure Text to display when user Invalid user name or password. Please try
Text authentication fails. again.
147
Configuration Guide Configuring Delegate Printing
Configuring Delegate Printing

This section provides an overview of the Delegate Printing feature in Blueprint including how to configure
it. This section covers the following topics:
l What is Delegate Printing?

l Delegate Printing Components
l User Workflow
l Getting Started with Delegate Printing
l Enabling Delegation for Secure Queues
l Enabling Delegate Printing on the Delegator's workstation
l Disabling Delegate Printing
l Adding/Assigning Delegates
l Removing Delegates
l Deleting Delegated Jobs
What is Delegate Printing?

The Delegate Printing feature of Blueprint enables users to print documents on behalf of someone else. A
user can nominate another user or users (known as Delegates) to release their jobs from any Pharos-
managed device. For example, a Manager can ask their Assistant to print documents on their behalf.
Releasing Delegated Jobs

Delegated jobs can be released by both the delegator and the delegates. Jobs can be released as usual
from any Pharos Network Terminal or from the Workstation Release UI (if enabled at the server).
Because the Workstation Release UI shows the delegates and the owner column, the delegate can tell
which jobs they printed and which has been delegated to them. The Workstation Release UI also requires
a Tracker installed on both the Delegator's and Delegate's workstations.
148
Delegate Printing Components

Terms/Concepts Description
Users chosen to print on behalf of another user. Delegates can:
Delegates l release print jobs that have been delegated to them

l delete print jobs that have been delegated to them
l determine the Delegator (shown at the terminals)
Are users who have given the authority to print on their behalf. Delegators
can:
l add, view, edit, and remove delegates

l allocate print jobs to delegates
l release or delete their own print jobs, including the jobs that they've
delegated
Delegators/Job Owner
If the Delegators want to print private documents i.e. documents that

shouldn’t be made available to a delegate, they should submit their
job to a normal Secure Queue - not a Delegated Queue. The other
option is to disable delegate printing by right-clicking on the small
icon on the system tray.
Are Secure Queues for which delegation has been enabled.

Delegated Queues For more information on how to enable delegation on Secure Queues, please
refer to the "Enabling Delegation for Secure Queues" section on page 150.
User Workflow
The following illustrates the typical user scenario for Delegate Printing. This workflow assumes that a
Blueprint Tracker and a Delegate Queue have been installed on the delegator's workstation.
1. The delegator enables the Delegate Printing feature on their workstation. This is done by clicking
the Blueprint Print Console (orange P icon) on the system tray area. This step needs to be done
only once.
2. The delegator adds one or more delegates.
3. The delegator sends documents to print to the Delegated Queue.
4. The delegator requests to one of the delegates to release his or her print jobs.
5. The delegate releases the print jobs using any of the following methods:
l The Pharos Network Terminals
149
l Workstation Release UI (if enabled at the server)
The delegate will see a list of their own jobs and the jobs that have been delegated to them at the
terminals or the Workstation Release UI.
Important Notes about Delegate Printing

l Delegated jobs will not be available to either the Delegator or the Delegate once released or deleted
by either user.
l Only one level of delegation is involved – Delegates cannot delegate jobs that had been delegated
to them.
l If the delegators want to print confidential documents, they can disable delegate printing easily by
right-clicking on the Blueprint Print Console. Alternatively, they can send their confidential
documents to a standard Secure Queue rather than to a Delegated Queue.
Before You Start

Before configuring Delegate Printing, you should have the following:
l A working Secure Release system. For more information, refer to the Configuring Secure Release
Here section of this document.
l Secure Queues configured on Blueprint Collectors (if you haven't already done so). For more
information on how to create Secure Queues, please refer to the "Setting up Secure Queues"
section on page 80.
Enabling Delegation for Secure Queues

Use the Blueprint Secure Queue Configuration Tool to enable delegation for the Secure Queues.
To set up Delegated Queues:
1. Open the Blueprint Secure Queue Configuration Tool (Programs > Pharos Blueprint Enterprise
> Tools).
2. Select the Secure Queue(s) for which you want to enable delegation.
3. Click the Enable Delegation button. This turns your Secure Queue into a Delegated Queue.
150
Getting Started with Delegate Printing

The following provides an overview of how to configure Delegate Printing:
1. Enable delegation for your Secure Queues. On your Blueprint Collectors, determine the Secure
Queue(s) that you wish to become Delegated Queues and enable delegation on them. This will turn
the Secure Queues into Delegated Queues. For more information, please refer to the "Enabling
Delegation for Secure Queues" section on page 150.
2. On the Delegator's workstation:
a. Add/Install Delegated Queue(s).

b. Install the Workstation Tracker. For more information, refer to the "Blueprint Tracker
Deployment Guide" found in the Documentation folder of the Blueprint disk image.
c. Enable Delegate Printing. For more information, please refer to the "Enabling Delegate
Printing on the Delegator's Workstation" section on page 151.
d. Add Delegates. For more information, please refer to the "Adding/Assigning Delegates"
section on page 152.
Enabling Delegate Printing on the Delegator's

Workstation
By default, Delegate Printing is disabled. The Delegator must enable Delegate Printing for it to work.
Before you start, check that:
l The Tracker has been installed on the Delegator's workstation.

l At least one Delegated Queue has been added to the Delegator's workstation. Delegate Printing will
not work if there are no available Delegated Queues on the Delegator's workstation.
151
To enable delegate printing on the workstation, right click on the Blueprint Print Console (the small
icon on the system tray area), select the Delegate Printing option, and then click Enable. This will open a
dialog box that explains Delegate Printing.
Disabling Delegate Printing

To disable delegate printing, right click on the Blueprint Print Console in the system tray area and then
click the Delegate Printing option. Click Disable.
Adding/Assigning Delegates
After enabling Delegate Printing on the employee workstations, the next step is to add Delegates - these
are users to whom printing will be delegated. This task is performed by a Delegator.
A user should have an existing account in the Active Directory to be added as a Delegate.
To add Delegates:
1. Right click the Blueprint Print Console (small icon on the system tray) and then select Edit
Delegates.
152
2. In the Edit Delegates dialog box that opens, click the Add button to add Delegates.
3. In the text field, enter part of the name or email address of the person that will be added as a
Delegate, and then click Search. This will return a list that matches your search criteria.
4. Select the relevant user, click the Add button
Assigned Delegates have the ability to release or delete print jobs that have been delegated to them.
Removing Delegates
A Delegate can be removed by a Delegator from his/her workstation using the Blueprint Print Console.
To remove a Delegate:
1. Right click the Blueprint Print Console (small icon on the system tray) and then select Edit
Delegates.
2. In the Edit Delegates dialog box that opens, select the delegate that you want to remove and then
click the Remove button.
The Delegate will be removed and will no longer be able to release the Delegator's print jobs.
Deleting Delegated Jobs

Both the delegator and the delegate can delete print jobs from the workstation. This requires
Workstation Trackers on their machines.
To delete delegated jobs:
1. Double click on the Blueprint Print Console (the orange P icon). This opens the Workstation Release
UI, showing the list of jobs that can be released, including the "Owner/Delegator" of the job, the
Delegates, and the time the jobs were printed.
2. Select the job that you want to delete and then click the Delete button.
153
Configuration Guide Configuring Pharos MobilePrint
Configuring Pharos MobilePrint

Blueprint Enterprise integrates with the Pharos MobilePrint solution, which enables users to print from
their mobile devices to any Pharos-managed printer in an organization.
Pharos MobilePrint requires Secure Release Here components (e.g. Terminals, Print Groups,
Authentication Methods) in order to work. If you don't already have a working Secure Release Here
system, please refer to the "Configuring Secure Release Here®" section on page 65.
For information about Pharos MobilePrint, please refer to the “Pharos MobilePrint Installation and
Configuration Guide”.
154
Configuration Guide Appendix: Authentication Scripts
Appendix: Authentication Scripts

Managing Authentication Scripts
Scripts are added, tested, and deleted on the Device Management > Authentication Methods screen of
the Analyst.
Scripts are written in C# - prior programming or scripting experience is required. Contact Pharos Systems
for assistance in writing and editing scripts.
Adding New Authentication Scripts

To add an authentication script:
1. Click the Add button on the Device Management > Authentication Method screen toolbar.
2. Enter a name for the script on the Details tab.
3. In the Authentication type, select Advanced (Script) to create the script. This changes the
Authentication Methods screen and shows the Designer and Tester tabs.
4. In the Designer tab, enter the code for the script (this can be cut-and-pasted from a text file).
5. Test the script using the controls on the Tester tab.
6. Click Apply.
Editing Authentication Scripts

Authentication Scripts are edited at the Analyst and replicated to Collectors as they are needed.
To edit a script:
1. Open the Device Management > Authentication Methods screen.

2. Select the script that you want to edit and go to the Designer tab.
3. You can edit the code directly or cut-and-paste new code from a text file.
4. Once the changes are made, click Apply to compile the script and save it. Scripts that do not
compile cannot be saved.
After the change, the updated Authentication script will be used once it has been replicated to the
Collectors.
Testing Scripts
The Tester tab on the Device Management > Authentication Methods screen allows you to test that a
script returns the expected results.
To test a script:
155
1. Open the Device Management > Authentication Methods screen.

2. Select the script that you want to test and go to the Tester tab. The Tester tab displays a list of the
parameters required by the script. Specify input values for each parameter (you must tick the
boxes next to each parameter to enable them).
3. Click the Test Script button.
The results of the test appear in the Test Output field on the right of the tab. If the test is successful,
details of the returned identifier(s) are displayed; if the test fails, error messages explaining the reason for
the failure are displayed.
A successful result lists each returned parameter with the following details:
Detail Description
Name The name of the output parameter.
Value The value returned for the output parameter.
Is Refer ID This field is ticked if the parameter is the one that output data is recorded against.
Identifier Type The identifier type of the output parameter.
The script tester runs on the Analyst - success here does not necessarily imply that the script will
work when run on Collectors at user logon time, as differences between the servers may affect the
script's operation. For example, when authenticating against a third-party system, networking
differences may mean that the Analyst can contact the authentication system whereas Collectors
cannot.
Scripting Introduction
Each authentication script must meet the following standards:
1. The script should be created in the PharosSystems.Scripts namespace.

2. The script must define a class that implements the IAuthenticate interface.
a. The class must define a public Authenticate function - it must take one parameter of type
Inputs and return an Identity type.
3. The Authenticate function must:
a. Validate that single parameter contains the necessary user credentials.
b. Return a valid Identity object or if an error occurs, throw an exception.
We will reference the “Basic” standard script to cover each area in more detail.
using PharosSystems.Blueprint.Scripting;
using PharosSystems.Blueprint.Scripting.IdentityHelpers;
using PharosSystems.Interfaces;
using PharosSystems.Schemas;
156
using PharosSystems.Core;
namespace PharosSystems.Blueprint.Scripts
{
//This script results in successful authentication and returns a
//fixed identity irrespective of the values of the supplied //inputs.
public class Basic : IAuthenticate
{
public Identity Authenticate(Inputs inputs)
{
// Check that all required inputs have been supplied.
UserIdAndPassword.Validate(inputs);
// Ignore the values of the inputs and return a fixed

// 'identity' containing an employee ID (as the refer
// ID) and two auxiliary network IDs. This may be useful //
for testing purposes.
Identity identity = new Identity();
identity.AddItem(new IdentityItem(
"EmployeeName", "JohnDoe001",
Enumerations.IdentifierType.Employee, IsReferId.True));
"NetworkId1", "Administrator",
Enumerations.IdentifierType.Network));
"NetworkId2", "Guest", Enumerations.IdentifierType.Network));
return identity;
}
}
}
Script "using"
At a minimum, the script should import the following namespaces:
Script "namespace"
The script should define all objects, etc. in the PharosSystems.Scripts namespace.
157
namespace PharosSystems.Scripts
{
Code here
}
Script Entry Point

The script should define a public class that implements the IAuthenticate interface. This class should
define a public function with the following characteristics:
l Function name – Authenticate

l Function return type – Identity Refer to the "Identity" section on page 160.
l Function parameters – 1 parameter of type Inputs (Refer to the "Inputs" section on page 161.)
{
// This script results in successful authentication and returns a
fixed
// identity irrespective of the values of the supplied inputs.
{
{
}
}
}
Script Authenticate
The Authenticate function must validate that the Inputs parameter is valid. It should either return an
Identity object (that contains the employee information represented by the Input parameter) or throw an
exception.
A helper object (UserIdAndPassword) exists to validate that the Inputs parameter contains both a
username key/value pair and password key/value pair (value may be blank). Call
UserIdAndPassword.Validate, passing it an Inputs parameter. It will throw an exception if the parameter is
invalid.
To return an Identity object, create a new instance. Then you can use the .AddItem function to insert new
IdentityItem objects into the Identity object. Each IdentityItem represents some aspect of the employee.
158
To throw an exception, throw an InvalidUserException object. The constructor of this exception object
should be passed the error message to display. For example:
throw new InvalidUserException(“Invalid username or password”);
{
// This script results in successful authentication and returns a
// fixed identity irrespective of the values of the supplied inputs.
{
{

// 'identity'containing an employee ID (as the refer ID) and two
// auxiliarynetwork IDs. This may be useful for testing purposes.
"NetworkId2", "Guest",
return identity;
}
}
Each authentication script must meet the following standards:
1. The script should be created in the PharosSystems.Scripts namespace.

2. The script should define a class that implements the IAuthenticate interface.
a. The class must define a public Authenticate function - it must take one parameter of type
Inputs and return an Identity type.
3. The Authenticate function should:
a. Validate that single parameter contains the necessary user credentials.
b. Return a valid Identity object or if an error occurs, throw an exception.
We will reference the “Basic” standard script to cover each area in more detail.
159
{
//This script results in successful authentication and returns a
//fixed identity irrespective of the values of the supplied //inputs.
{
{

// 'identity' containing an employee ID (as the refer
// ID) and two auxiliary network IDs. This may be useful //
for testing purposes.
"NetworkId2", "Guest", Enumerations.IdentifierType.Network));
return identity;
}
}
}
Scripting Objects
Identity
Manages information (e.g. network identifiers, card identifiers, full name, email address) that represents a
single employee.
Functions:
l AddItem( IdentityItem item ) – add an additional IdentityItem (see below) to the object.
Properties:
160
l Items – provides access to the Dictionary object storing IdentityItem objects. It is indexed by
name. Refer to Dictionary in the .NET Framework Online help.
IdentityItem
Represents a single fact (e.g. one of the employee’s network identifiers) about an employee. These are
inserted into an Identity object.
Constructors:
l IdentityItem( string name, string data ) – use when you need to store data about an employee
(e.g. full name, email address), but the data is not an employee identifier (e.g. network ID, card ID).
l IdentityItem( string name, string data, Enumerations.IdentifierType identifierType ) – store an
employee’s identifier (e.g. network ID, card ID). You must specify the identifier type (see below).
l IdentityItem( string name, string data, Enumerations.IdentifierType identifierType, IsReferId
isReferId ) – store an employee’s identifier (e.g. network ID, card ID) and mark it as the employee’s
“best” identifier. You must specify the identifier type (see below).
Properties:
l Data – the actual data that represents the employee (e.g. the employee’s actual card ID).
l Name – a unique name that represents the data being stored
l IdentifierType – the type of identifier being stored (Enumerations.IdentifierType):
l Card – represents a card ID
l Employee – represents a HR or payroll ID
l Network – represents a network ID
l IsReferId – true if the identifier is considered the employee’s “best” identifier. Jobs logged during a
terminal session, e.g. released print jobs, will be logged against this identifier.
Inputs
Represents the inputs supplied for an authentication attempt (e.g. username / password). It inherits from
the standard .NET Dictionary class. For example, to retrieve the value of the “UserId” credential where the
Inputs object is named “inputs”:
string CardId = inputs[“UserId”].Data;
Scripting Helper Functions

UserIdAndPassword
Functions:
l Validate( Inputs inputs ) – validates that “inputs” parameter has valid authentication data (i.e.
“UserId” and “Password”). Use this even if a card ID is expected; the card ID will be passed as the
“UserId”.
161
IdentityProvider
Provides access to identity information from the Blueprint database.
l Functions:
l Identity FindIdentity( Enumerations.IdentifierType identifierType, string identifierData )
– Returns the Identity object representing the provided identifier information.Searches the
Blueprint database for an identifier where its type matches “identifierType” and its data
matches “identifierData”. If the identifier is found, returns a valid Identity object
representing the identifier and its hierarchy (e.g. its other related identifiers). If the identifier
is not found, an exception is thrown.
LdapUtils
Provides a simple mechanism to query either Active Directory or LDAP.
Functions:
l LdapSearchResult FindAdUser( string serverUri, string adminName, string adminPassword,

AuthenticationTypes authenticationType, string filterFormat, object[] filterParameters, string[]
resultProperties, string userPassword ) – Finds the AD user. Optionally authenticates the user
given a password. Creates a DirectoryEntry object that connects to the specified Active Directory
service (serverUri) using the specified credentials (adminName and adminPassword). It creates a
DirectorySearcher object to a find the account (using the filterFormat and filterParameters). If the
account is found, it validates that the password is correct. It returns the values requested in
resultProperties. If an error occurs (including an invalid password), an exception is thrown.Refer to
DirectorySearcher (and authentication types, filter format and result properties) in the .NET
Framework Online help.
l LdapSearchResult FindLdapUser( string serverUri, string adminDN, string adminPassword,
AuthenticationTypes authenticationType, string filterFormat, object[] filterParameters, string[]
resultProperties, string userPassword ) – Finds the LDAP user. Optionally authenticates the user
given a password. Creates a DirectoryEntry object that connects to the specified LDAP service
(serverUri) using the specified credentials (adminDN and adminPassword). It creates a
DirectorySearcher object to a find the account (using the filterFormat and filterParameters). If the
account is found, it validates that the password is correct. It returns the values requested in
resultProperties. If an error occurs (including an invalid password), an exception is thrown. Refer to
DirectorySearcher (and authentication types, filter format and result properties) in the .NET
Framework Online help.
LdapSearchResult
Contains the results returned by either FindAdUser or FindLdapUser.
Properties:
l string this[string name] – Returns the first item in the return results that matches the specified
“name”.
162
l bool ContainsProperty( string name ) – Returns true if the specified “name” exists in the return
results.
163

Blueprint Enterprise 5.1 Configuration Guide

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Blueprint Enterprise 5.1 Configuration Guide

Încărcat de

Drepturi de autor:

Formate disponibile

Configuration Guide

Document Version: BPE51-Config-1.0

Distribution Date: April 2013

About this Document 14

Enabling Health Notification Emails 17

Configuring Data Imports 18

Importing Files Manually 18

Supported Import File Encoding 19

Standard Import File Types 19

Importing Employee Data 20

Importing Human Resource Data 20

Importing Identifier Translation Data 21

Importing Model Data 22

Importing Model Data 22

Importing Model Cost Data 23

Configuring Collector Exports 24

Automatic Collector Exports 24

Manual Collector Exports 25

Renaming Collector Servers 26

Configuring Policy Print™ 27

What is Policy Print? 27

Before You Start 28

Getting Started with Policy Print 29

Blueprint Default Policies 30

Getting Started with Rules 33

Blueprint Built in Triggers 36

Defining Complex Trigger Expressions 41

Multiple Trigger Conditions 41

Using the "Unless" Condition 41

Text Matching Modes Used in Trigger Conditions 42

Regular Expression Matching 43

Case-Sensitive Exact Matching 44

Multiple Rules per Job 45

Recommendations for Assigning Groups to Policies 47

Changing Policy Priority 49

Changing Messages Displayed to the Employee 50

Prompts Displayed on Workstations 50

Prompts Displayed on Terminals 53

Device Access Prompts 53

Function Access Prompts 54

Common Terminal Prompts 55

Prompts used for displaying Policy Details 56

Editing Global Prompts 58

Policy Print Settings 59

Policy Print Settings 60

Toner Savings Settings 60

Estimated Cost Settings 61

Directory Services Settings 61

Known Limitations of Policy Print 63

Configuring Secure Release Here® 65

What is Secure Release Here? 65

Before You Start 65

Secure Release Here Terms/Concepts 66

Getting Started with Secure Release Here 67

Terminal Type Settings 70

Adding New Terminals 70

Automatically Creating Terminals 71

Editing Copy Lines 71

Duplicating Terminal Settings 72

Manually Adding New Devices 74

Device Model Information 75

Secure Release Here Default Settings 75

Changing the Default Settings 76

Changing the Default Print Group 76