Skip navigation
All Places > Blueprint Enterprise > Blog

Fewer words strike fear into the hearts of IT than "Windows patch" and "security advisory" do. And for good reason: it means that there is a potential out there for a previously-unknown defect, and there is enough information on its impact now that An Official Statement has been released. So break out the planner and figure out when the next maintenance window happens, 'cuz a change is gonna come. This all starts in earnest March 2020, but you can do it now (manually).


What Is Microsoft Security Advisory ADV190023?

Simply, Microsoft has found a need to plug yet another security hole in their implementation of LDAP. According to a Microsoft article related to the advisory ("2020 LDAP Channel Binding and LDAP Signing Requirements for Windows"), "There is a vulerability in the default configuration for Lightweight Directory Access Protocol (LDAP) channel binding and LDAP signing and may expose Active directory domain controllers to elevation of privilege vulnerabilities." So let's break this down, because how you interface Blueprint with LDAP (if you do at all) makes all of the difference in the world in how you approach this. The master article is found here:


First, if you are using unencrypted LDAP (LDAP, TCP 389; ldap://blah:389 connections) for your applications and choose to bypass/override this upgrade, then none of this matters. Except that you probably shouldn't be using unencrypted LDAP in the first place, because you are passing credentials in clear-text over a channel that 100% of "off the Internet" packet sniffers can pick up and use. If you're not careful, however, and still using LDAP connections, you may end up with "LDAP_SERVER_DOWN" messages.


If you're using an encrypted LDAP connection (LDAPS, TCP 636; ldaps://blah:636 connections) for your applications, a Microsoft Update in March 2020 is going to require signing and a channel binding token (CBT) for secured connections to LDAP.


LDAP Channel Binding

Channel Binding is a method of securing the TLS connection by using token binding. Without getting too technical, in traditional TLS, the client, like a web browser, presents a bearer access token to the server that basically says "Hi, it's me, and I'm authenticated!" and the web server accepts it without much fanfare. It's secure, but it is easy for another system to impersonate the bearer token and hijack the session for malicious intent. Using token binding (for now) is more secure (see for a good explanation), and so in March 2020, once your clients are all updated, you can update your servers and your LDAPS connections will be happy as a clam.


LDAP Signing

This just means that the LDAP connection is secured (using LDAPS). Once the updates to domain controllers or Lightweight Directory Services servers are done, an unsigned LDAP connection will be refused unless the server is explicitly configured to not require it...and that is going to be either a manual, per server, effort, or through Group Policy.


Am I At Risk?

Act Now! to check if your systems are at risk. Microsoft has provided an excellent document to determine if unsecured LDAP is hitting your domain controllers. Implement the registry changes and then look for Event ID 2886 and 2887 in the Directory Services log within Event Viewer. Event ID 2889 (also covered in the Microsoft document) lists the systems making the calls, so that you can determine where the call is coming from.


If you do find that a Blueprint Enterprise server is at the root of an unsecured LDAP call, contact Pharos Technical Support and log an incident for assistance right away. In most cases, the resolution is to simply convert the LDAP call into LDAPS, but other changes may also be necessary.


The Impact to Blueprint Enterprise Operation

If your Blueprint Enterprise Collectors and Analyst are configured for LDAP integration, it's a good idea to get ahead of the change and convert them to LDAPS now. By default, if you are running Blueprint 5.2 SP3 or greater and have implemented Secure Release Here using the Standard Authentication Method, the connection to your domain controller for badge registration and user/password authentication is secure. If your site is using a custom script to access Active Directory (using either Kerberos/NTLM or as an LDAP channel), your script will likely need to be modified to convert it to a signed connection.


That's half of the battle (NOTE: make sure your certificates are in order). Then, as you implement the March 2020 updates, operations should persist successfully provided the client environment is updated prior to the servers (in this case, your Blueprint Enterprise servers are clients, even if they also happen to be domain controllers). If you maintain those LDAP connections and the updates to Microsoft AD and LDS servers are deployed, functions that rely on LDAP (authentication via user name and password at secured devices, logging into Pharos Print Center, and Unauthenticated Print Scout clients; HRLDAP imports for user information) will fail, requiring last minute connection reconfigurations and emergency operating system updates.


Nothing spoils a great weekend like a Change Request. And nothing spoils a spoiled weekend faster than running into problems during the Change.


Lately, there has been a rise of failed upgrades to Blueprint Enterprise, largely fueled by improper permissions to the database for the Login Account used for Blueprint operation. This document serves to talk about some common ideas about database ownership in Microsoft SQL, dispel some myths, and ultimately explain how this applies to upgrade events in Blueprint Enterprise.


The 'dbo vs db_owner' Issue

The first part of the confusion stems from "dbo" versus "db_owner" and how SQL addresses each from a security standpoint. The explanation itself contains twists in language, so I will try to be very clear. It has to do with logins versus roles, and a dash of archaic history in the relationship of users and schemas.


What is dbo?

The acronym "dbo" literally means database owner. Each database hosted in SQL Server has to be owned by one (and only one) login, and this login gets aliased to the dbo login. The dbo user (and its aliases) cannot be denied, which means that specific login can do anything they want to within the database. Not the server, just the database.


"dbo" can also mean "schema" and this is where a lot of people get tripped up. Back in the dark ages of SQL Server (version 2000 and lower), creating a login also created a schema for the login, and the two were inseparable. So people who administered databases awhile ago have this idea that "dbo" is almost like the "sa" (system administrator) login, and so balk at the use of database ownership tied to a login. But in version 2005, Microsoft changed that. A schema in SQL Server 2005 and newer is just a collection of objects in the database: tables, indexes, etc. that can be owned and accessed by users, and "dbo" is the default schema when an alternate isn't defined. So if I am a login that can, for example, create a table in a database and I simply run:


Id int,
Type varchar(25),
Description varchar(100)


the object will be placed into the dbo schema, resulting in dbo.MyStuff. The owner of the dbo schema in SQL has a lot of power only because most of the objects in each database are in the dbo schema. If I built a database that had a schema named "Gandalf" and put all of the database objects in that schema, then the owner of the Gandalf schema would have more access in the database than the owner of the dbo schema. But ownership of a schema doesn't imply extended or administrative permissions. You can just see the stuff in the database.


In conversations with database administrators, it is very important to provide the proper context for dbo: are you talking about the schema (collection of objects) or the login (the database owner)?


What is db_owner?

In SQL, db_owner is a fixed database-level role that has explicit permissions within the database. Logins can be added to the db_owner role for the purpose of database administration. According to Microsoft's documentation, logins assigned the db_owner role (whose permissions cannot be changed) to the database are pretty much free to do anything (anything) in the database (again, not the server, just the database). However, membership in the db_owner role does not confer dbo user permissions. And so, any T-SQL script that needs to act under dbo needs to be run as the dbo of the database.


So What Does That Mean for Blueprint?

Operationally (meaning: after installation), the account specified for the databases in the Blueprint Server Configuration utility can happily live as a member of the db_owner fixed role. During an upgrade, however, and to retain backwards compatibility with previous SQL versions, there is a check to ensure that the specified login is also dbo. If there was not, then Blueprint installations on older SQL Server versions would fail, and by doing so, the potential exists to cause failed upgrades, particularly on servers managed by security-conscious database administrators who seek to keep "least privileged" access at all times (and so often change database ownership to restricted domain-based accounts with tight access controls).


Removing the Fault

In almost all cases, Blueprint server upgrades are scheduled events, typically managed as part of a Change Control process. Therefore, within the change control procedure, implement a Database task to temporarily change the dbo alias to the account used by the Blueprint Analyst to access the database:


USE psbprint [psjobs1, psjobs2, psjobs3, psjobs4..., psreports]
sp_changedbowner 'login'


where the action is taken on the various Blueprint databases (in turn) and login is replaced by the login account name. NOTE: in some future version of SQL Server, the sp_changedbowner procedure will be removed. Use ALTER AUTHORIZATION instead:




Then, when the update is complete, the change control procedure gets another Database task to move the dbo alias back to whatever is used for production purposes, using the same syntax/script above. This restores the "least access" privilege.


And That's It!

In sum, being the dbo isn't all bad; its exactly the same as being a member of the db_owner fixed role, without some of the hassle associated with an upgrade. However, with some planning, the upgrade experience can go smoothly; well, except for the ruined weekend part.

When Blueprint Enterprise 5.3 was being developed for release, Microsoft was busy preparing for the release of SQL Server 2019. At the time of our larger push for release readiness, it was decided that we not regression test against this version of Microsoft SQL Server because it added significant (and unplanned) time, and no existing customer in our contact group had any plans to migrate to that version any time soon.


Instead, we opted to allow the installation to continue with a caveat notification that we hadn't fully tested it yet:


Non-tested SQL version notification


and a validation step that continuing was "at risk."


Since then, we have been able to more fully test the operation of Blueprint Enterprise 5.3 with Microsoft SQL Server 2019 and are happy to report that operational events (inserting and updating objects in Blueprint Administrator, data publications, file imports) work as expected.


When the next major version of Blueprint Enterprise is released, this warning screen will be removed when Microsoft SQL Server 2019 is detected.


Earlier Versions of Blueprint Enterprise

Installing Blueprint Enterprise 5.2 and lower to Microsoft SQL Server 2019 are not supported. If an existing Blueprint Enterprise 5.2 or earlier database is migrated to a SQL Server 2019 instance, our expectation is that, operationally, there will be no incident.


The purpose of this update is to replace the Pharos Page Counter components for the Pharos Blueprint Print Agent for MacOS. This update provides improved support for MacOS Mojave (10.14) and Catalina (10.15) by providing the Page Counter as a 64-bit binary.



This update requires Pharos Blueprint Print Agent for MacOS v1276.


How to Update

Run the PCounter.pkg (download here) on MacOS Mojave or Catalina clients that already have Print Agent v 1276 installed. This installation requires no restart of process or the MacOS computer.


In-line Installation for New Clients

Install the Pharos Blueprint Print Agent for MacOS v1276 and then follow immediately with the PCounter.pkg file.


NOTE: MacOS Catalina has a problem (it is possibly a security feature) if the PharosPrintAgent.mpkg file is being executed anywhere inside the current user's home directory (/Users/%User%). Within the /var/log/Install.log file, there will be an error message:


The domain/default pair of (/Users/%user%/Desktop/PharosPrintAgent.mpkg/Contents/Packages/../Configuration/Settings, BMTMainServerURL) does not exist.


The resolution is to stow the file somewhere else (/tmp or /Users/Shared, for example) and run the .mpkg file.

Blueprint 5.2 Service Pack 5.4 (5.2.10308)

Released: 18 Jan 2019

What's new in Service Pack 5.4

  • Print Scout Secure Release is designed to eliminate the workflow impact that network speed imposes upon remote/branch offices, enabling these locations to also participate in a Secure Release deployment, but without the printing inefficiencies of the traditional Wide Area Network. Jobs submitted through the new "Pharos Secure Printer" queue stay on the workstation and are released from the workstation; the Collector is simply notified of the print job and forwards the release request to the workstation, which then releases the job directly to the printer.
  • Print Center changes:
    • The new System Monitor tab provides indication of the overall health of the Blueprint system.
    • A new Themes tab allows you to customize the look and feel of your Print Center website, so it matches your organization’s branding.
    • Various improvements to the Event Log. For example, you can now search by server group, select events based on time zone, etc.
  • Support for MobilePrint 2.3
  • Support for running Reports against a database server using TLS 1.2.
    • Reports are modified at load time to use the SQL Native Client 11 driver installed with this service pack.


Blueprint 5.2 R2 (5.2.9937)

Released: 24 Jan 2018

Blueprint Enterprise 5.2 R2 provides the exact same feature set as Blueprint 5.2 with Service Pack 3 applied, but adds support for Microsoft Server 2016. Blueprint 5.2 R2 also makes it easy for customers who are currently running Blueprint 5.0 or 5.1 to get up to date with all the latest features and improvements to Blueprint Enterprise. If you are already running Blueprint 5.2 and want to upgrade to Service Pack 3, please refer to these supporting documents instead.


Blueprint 5.2 Service Pack 3 (5.2.9857)

Released: 19 Oct 2017

What's new in Service Pack 5.3

  • Supports TLS 1.2 for server-to-server WCF communications.
    • If TLS 1.2 is the ONLY cipher suite enabled, FIPS compliance must be enabled at both the client and server to view Blueprint reports. Please read Enabling FIPS Compliance for further instructions.
    • Note: If older cipher suites such as SSL 3.0 or TLS 1.0 are also enabled, Blueprint server-to-server WCF will use the more secure TLS 1.2 suite.
  • You can now use Active Directory Groups to assign Blueprint roles.
  • All DLLs in Print Scout are code signed.
  • Now uses .Net 4.6.1, and .Net 3.5 is no longer required. (For more information, please refer to the Blueprint 5.2 Installation Guide.)
  • Support for SNMP V3
  • Support for Mobile Print 2.2.1 (See Also: MobilePrint 2.2.1 Now Available)
  • Event logs for multiple Collectors can be viewed from Print Center.
  • Additional Health Tests have been added to the Blueprint Server self-checks.
    Note: Collectors will now e-mail failed self-check results. Make sure that the Collectors are able to contact the mail server.
  • Delegate Printing is now in Pharos Print Center. Employees can add or remove delegates using their browser.
  • On sites where Blueprint Servers can't retrieve SSL Certificate Revocation Lists (CRL), networking delays can occur. It's now possible to tell Blueprint to use SSL certificates that do not check the CRL.
  • No more "The service '/PharosSystems/AgentController.svc' does not exist" events in Windows Application Events.
  • Support added to verify the email settings using Blueprint Administrator on a Collector.

SP3 Bug Fixes

  • Card Registration can be carried out during an HR Import.
  • Employee List and Usage Report references to user location and not device location.
  • VPSX file import deadlocks if a SR25 tries to register or update itself at same time a VPSX file import is running
  • Recording of Serial Number of locally connected USB printers, handles case of printer being moved between workstations.
  • Improve Active Directory search performance. Looking up Groups for Policy no longer times out on large Active Directory systems.
  • Restriction removed to display a max of 1000 rows in certain Administrator views (Models, Terminals, Devices, etc.).
  • Collector BIN files with a Machine data signature of 5.1 are now imported correctly. This bug would manifest itself if BP 5.1 Collectors sent bin files to a BP 5.2 Analyst.
  • A Print Scout installed in August or September or on the 8th or 9th of the month may fail to upload job data to Collector.
  • Use of load balancers between workstation and SRH collectors can result in a print job being sent to multiple Collectors. When this happens, a user is unable to release any jobs until the duplicate jobs are located and deleted.


Blueprint 5.2 Service Pack 2.1 (5.2.9277)

Released: 31 Mar 2016

What's new in Service Pack 2.1

SP2.1 Fixes

  • Preton synchronization includes rows in PretonApplications with "IsStatic" value of 1.


SP2.1 Enhancements

  • Quota Management added
  • Recording of Serial Number of locally connected USB printers


SP2 Bug Fixes 

  • Fixed failure to record print jobs sent by USB printers.


SP2 Enhancements

  • Policy Rules can be triggered based on Print Server Name.
  • Print Scout automatic updates are disabled on VDI, Analyst and Collector.
  • Print Policy is applied to first job that user prints on a workstation.
  • Updated set of Device Models.
  • SSL certificates used for WCF encryption support SHA256.
  • SRH Troubleshooter no longer provides UI to enable/disable Workstation Release.


Blueprint 5.2 Service Pack 1 (5.2.9116)

Released: 27 Nov 2015

What's new in Service Pack 1


  • The Print Center has been optimized to work on smartphones, tablets, and other mobile devices with different screen sizes.
  • Support for Pharos MobilePrint 2.1
  • Microsoft® Windows 10 support for the Workstation Print Scout


This document outlines the version numbers associated with public releases of Pharos Blueprint Enterprise and its service packs. This document's scope is from Blueprint 5.1 and forward.


Blueprint Enterprise Release Names and Versions

The following table lists all Blueprint Release Names, Versions, and Release Dates.


Release NameBuild NumberRelease Date
Blueprint 5.1 General Release5.1.78384-Apr-13
Blueprint 5.1 Service Pack 15.1.80003-Dec-13
Blueprint 5.1 SP25.1.820717-Apr-14
Blueprint 5.1 R25.1.78381-Oct-14
Blueprint 5.1 SP3.15.1.832116-Oct-14
Blueprint 5.2 General Release5.2.89918-Jul-15
Blueprint 5.2 Service Pack 15.2.911627-Nov-15
Blueprint 5.2 Service Pack
Blueprint 5.2 Service Pack 35.2.985719-Oct-17
Blueprint 5.2 Release 25.2.993724-Jan-18
Blueprint 5.2 Service Pack

In the psbprint database, there are two related tables: “Users” and “Identifiers”.

  • Users is reasonably obvious, it contains most of the properties of a user (i.e. Location, email, Budget Centre, etc.)
  • Identifiers are, for want of a better description, something that can identify a user.  The two most common types of identifiers are NetworkIDs and CardIDs.  This means:
    • A user may have multiple identifiers.  E.g. It’s common for a user to have both a NetworkID and a CardID.  Also, It’s not unknown for a user to have multiple cards.  Multiple network IDs is also possible.
    • Network IDs can exist without Card IDs.  Card IDs can’t exist without network IDs.  Well, they can, but without a Network ID, a Card ID is useless. Greatly simplifying, this is because when a Card ID is used for Secure release, Blueprint needs to match the Card ID to a network ID, so Blueprint can find all jobs that are owned by that network ID.
    • Thus Network IDs are “higher value” than Card IDs to Blueprint.


The root identifier is the highest value identifier that Blueprint has for a User.  Usually, it is the first Network ID associated with a User.

If you are having an issue with a Blueprint 5.1 or 5.2 TaskMaster, Secure Release Service, Logging Service, or Site Monitor service not starting during installation or during operation, it is possible that Microsoft Authenticode is getting in the way (for a good read-through on Authenticode, read Everything you need to know about Authenticode Code Signing - IEInternals - Site Home - MSDN Blogs). For those in the "tl;dr" camp, here's the quick skinny:


  1. Microsoft would like its developer community to digitally certify their applications.
  2. Microsoft .NET applications, like ours, get checked on start-up to ensure that the certificate is still good.
  3. If your server is not immediately able to contact the Internet for a little thing called a Certificate Revocation List (CRL), the service may not start due to timeout by the Service Control Manager.


The Site Monitor Logging service will fail to start during installation if it cannot validate the certificate or move past the operation in 30 seconds. If you receive a notification that a service can start during installation, immediately make the change below prior to retrying.


If you have that problem, modify that application's "config" file to include this <runtime> group within <configuration>:




     <generatePublisherEvidence enabled="false"/>




The following files are modification candidates (note that the folder paths are default, so your server path may be different):


  • C:\Program Files (x86)\PharosSystems\SiteMonitor\Logging\PharosSystems.LoggingService.exe.config
  • C:\Program Files (x86)\PharosSystems\SiteMonitor\Service\PharosSystems.SiteMonitor.Service.exe.config
  • C:\Program Files (x86)\PharosSystems\SecureRelease\PharosSystems.SecureRelease.SecureReleaseService.exe.config
  • C:\Program Files (x86)\PharosSystems\Blueprint\bin\PharosSystems.Blueprint.TaskMaster.exe.config

Some words of caution in the editing:

  • PharosSystems.LoggingService.exe.config and PharosSystems.SIteMonitor.Service.exe.config have a <configSections> group after the initial <configuration> tag. Put the <runtime> group in after the </configSections> line.
  • PharosSystems.SecureRelease.SecureReleaseService.exe.config already has a <runtime> group. So just put the <generatePublisherEvidence enabled="false"/> line in there as a child.

When you are finished editing, save the file and start the service.


Let me share some thoughts and experience on the topic.


HR-LDAR-Importer is a great tool, which allows to easily and what is very import quickly prepare import file to update Blueprint database. The utility is documented and useful, but is there anything else that can make Blueprint better?

Sometimes LDAP and Blueprint databases are used to address different needs. For example, one can get reliable email address stored in LDAP (mostly because they use Exchange as email server) and Printer Cost Centers are stored in Blueprint. This way to use HR-LDAP-Importer we would need to make a customer change his behavior and organize Blueprint Cost Center’s in LDAP somehow. Another example would be a customer unwilling to change anything inside a Blueprint database except for, let say, email and FullName of a user and leaving all the rest of the information unchanged. Somehow, Blueprint allows Blueprint Administrator to register a user without entering any Budget Center or Location Group information, however if you try to import HR file those fields are required, so if, let say, Blueprint database is already configured for 5000 users with their respective Cost Centers and Location Groups but that info lacks in LDAP, you will face some difficulties using HR-LDAP-Importer


This document attempts to describe a way to automate csv file creation that contains information both from actual Blueprint Database and selective LDAP fields. Import of the file into Blueprint can be achieved with PharosSystems.Blueprint.Utilities.HrLdapImporter.exe


What is necessary for us?

  1. Identify current Blueprint Users inside a Blueprint database (by current Blueprint Users I mean those users that are shown in Blueprint Administrator)
  2. Identify which LDAP attributes we need to be updated for those users and create LDAP view containing those attributes for each user
  3. Combine current Blueprint database information and those we got on step #2 to a result view
  4. Create csv from the result view


#1 is easy - we’re going to create a View inside psreports database, let’s call it LDAP_CURRENT_USER, that contains all Blueprint Current Users with all the information available and necessary for futher import

#2 is not so hard to do - we’re going to create a View inside psreports database that contains all LDAP users with all the parameters we need to be updated for our current users

#3 we will do inner join operation on the two views in order to get source view for our csv file

#4 we will use SSIS which is SQL Server Integration Services to export view #3 into import.csv file




Creating and scheduling SSIS package (#4) is not described here. In case anyone's interesting, please let me know, and I’ll update the document.



Hope this will save someday someone their time and efforts in Blueprint \ LDAP integration.


Thank you!



I just try to upgrade the Blueprint 5.1 with SP 3.1. Unfortunatelly the upgrade process is finishing with that error

"System Exception: Upgarade Scout failed with exit code 102,

at Installer.Install.UpgradeTracker()

at Installer.Install.DoRunOperations()

at Installer.Install.Run()

at.Installer.Program.Main(String[] args)"


I tried to run installation of the Tracker on the server and have got info "Installer has detected that you are running Citrix or Terminal Services. This is not supported for a Print Scout print server installation. Workstation mode must be specified"

I noticed similar info during upgrade fro exmaple from BP 4 to 5, but this could be solved by switching the terminal service mode to install, using in CMD this entry "Change User /Install". Unfortunately it doen't work this time.


Had somebody similar issue?


Best regards