Skip navigation
All Places > Knowledge Base & Downloads > Blog > 2019 > September

It happens. You're enjoying a raspberry-flavored sparkling water, mug of coffee, or cup of tea and an email comes in from InfoSec. The subject line casts a dark cloud over the rest of your day: Security Violation Remediation: Server ITSM-VA2-BPCOLL-01 (100001483652). ITSM-VA2-BPCOLL-01 is a print server running Pharos Blueprint Enterprise Collector software. It's getting print jobs, holding them, and then releasing them when the employees are at their print devices. What's the deal here?


What Just Happened?

Most IT organizations conduct security sweeps of their server infrastructure to eek out misconfigurations and other oversights that could potentially put the company at risk for "minor" problems like regulatory fines or sanctions to more major problems like hacking, data theft, or hijacking for another purpose (torrent servers, unregistered data stores and the like).

     "But it's a print server!" you rally. "What are they gonna do, steal company secrets?" Well...yes. A compromised system can serve as a vector for more malicious intent somewhere else; most intrusions happen on piggy-backed systems. Your Security team is just making sure that they keep a running tally of servers that don't fit their bill, and further track how quickly those identified servers are remedied.


What Do I Do?

That question is the first important step, and this article is the next. A lot of scanning systems borrow from a slew of resources like THE MITRE Corporation's Common Vulnerabilities and Exposures (CVE) website ( or OWASP (and many of those are software version-based. Keeping up to date with patches for installed software is a great first step in staying off the "naughty" list. Other vulnerabilities exist in web services and applications, and this is where this article is going to spend most of its time. So, on to HTTP Response Headers!


HTTP Response--what??

Some background may be helpful. When the W3C (the World Wide Web Consortium...the "think tank" and one of the standards organizations for the Internet) ushered in the concept of using markup language-formatted text to bring information to people worldwide, they also devised a way for those serving the information to provide additional information about the website to the user without affecting the displayed content on the page...a "meta data" vehicle of sorts: the HTTP Response Header.

     Over time, the function of the HTTP Response Header grew from a carrier of meta data (like who wrote the article, who holds the copyright, how many words it contains and all sorts of other cool, but non-essential, stuff), and could now manage how credentials were used or stored, what the underlying state of the server was, and ... security. Now, remember: a lot of web servers have public entry points (they have to, or your web experience would be awfully non-informative), so a bunch of the security-based HTTP Response Headers are driven towards keeping John Q. Public on the up-and-up, and the public web server out of hot water. And the security software that's out there looking at web servers will be designed around that. So while your internal print server hosting some Pharos software may be just that: internal, keeping it safe is the Security team's they will still "call you out" when they find a violation.

Anyway, HTTP Response Headers. There are a handful of headers that can be implemented at either the server layer or the individual application or site layer that serve to keep things safe. And if your server's web server software (Microsoft IIS, Apache Tomcat, etc.) is missing them, it is likely a good time to add them. They don't affect the Pharos software's operation, and they keep your servers on the good side of the IT Security folks. Which means you get to enjoy your work beverage of choice without worrying about that incoming nasty-gram from InfoSec.


Good Custom HTTP Response Headers to Have

There are five (5) HTTP Response Headers that are good to have on your Microsoft Windows Server running IIS:


> Content-Security-Policy

The content security policy directs the browser (in this case, generally by the printer's built-in web browser) to load only certain types of content from certain sources. Here, the policy only allows loading of resources from the current web site or from the local host (the local host is required because some resources are fetched locally from the printer itself).

> Strict-Transport-Security

Strict transport security forces the use of HTTPS (encrypted HTTP) in future communications to the server. Generally, the "time to live" for this setting is a year, but some organizations may have shorter expiry periods.

> X-Frame-Options, X-Content-Type-Options, and X-XSS-Protection

These three headers prevent cross-site scripting attacks (injected code) and stop the execution of untrusted content. Web pages that allow comments or other interaction points (like the one you're reading now) are common targets for cross-site scripting attacks.


Where to Implement Custom HTTP Response Headers

When implementing Response Headers, one of the first questions asked is "Where?" Well, on the web server itself, of course! In practice, there are a few ways to implement Headers. Where you end up adding them will likely be up to your Security organization. I'll start at the top layer and work down.


> At the "Server" Layer

Implemented at the server layer, the HTTP Response Headers will be applied to all underlying Sites, virtual directories, and web applications. If implemented here, it's a "set it and forget it" type of scenario.

> At the "Site" Layer

Implemented at the site, like the Microsoft IIS "Default Web Site", applies the HTTP Response Headers to all virtual directories and web applications under the site. This is useful when a server is running multiple sites, and not each one needs custom HTTP Response Headers.

> At the Virtual Directory/Web Service Layer

Implemented at the actual web directory or application, this allows granular control over which services get the custom HTTP Response Headers and which ones don't.


How to Implement Custom HTTP Response Headers

There's an old maxim that states there are three ways to do anything on a computer. The same applies here, but there are more than three.


> Using Microsoft IIS Manager

> Using PowerShell

> Using C# or another programming language

> Editing a web application's web.config file


In this article, we'll cover using Microsoft IIS Manager. There are multiple resources available to discuss the other three mechanisms (hint: use a scriptable/executable method if you have multiple servers). Just launch your favorite web search tool and type "powershell add http response header" or similar and you'll be fast on your way.


Creating a Custom HTTP Response Header in IIS Manager

In this example, we'll be adding the "Content-Security-Policy" HTTP Response Header to the "Default Web Site" in IIS.

  1. Launch IIS Manager on the server.
  2. Click the "Default Web Site" element.
  3. In the panel on the right, locate the "IIS" section and double-click the "HTTP Response Headers" item to open it.
  4. Click the "Add..." option in the Actions panel.
  5. Type "Content-Security-Policy" in the "Name" field and "default-src 'self'; script-src 'unsafe-inline';" in the "Value" field. Do not type the double-quotes.
  6. Click the "OK" button.


That's it! Continue with the others. The necessary Name and suggested Value of the custom HTTP Response Headers is shown below:


Content-Security-Policydefault-src 'self'; script-src 'unsafe-inline';
Strict-Transport-Securitymax-age=31536000; includeSubdomains
X-XSS-Protection1; mode=block



The following references were utilized in this article.


The following products support an SNMP (Simple Network Management Protocol) function, and may be affected by operational failure due to the cause described in this article:


  • Pharos Systems Device Scout
  • Pharos Systems Blueprint
  • Pharos Systems Uniprint
  • Pharos Systems Site Monitor
  • Pharos Systems Print Center



  • Printing devices are not found during discovery.
  • Discovered printing devices have no, or incomplete, associated data.
  • Released print jobs do not print out.
  • ERROR found in operational logs
    [2019/09/04 09:54:54.318 PDA4 D001 T02E e AgentDiscovery] [Messenger] (Get) Failed to get or interpret response from ''. wrong response sequence: expected 212442588, received 212442385



A previous SNMP request was cancelled due to timeout, but the requested data was still received.



The Simple Network Management Protocol (SNMP) is a stateless network application. This means that communications sent over SNMP do not necessarily have to be returned, or may take time to return. This is fine in many situations, but when an attempt is being made to add a printer to a managed pool, updated meter information is being sought, or a print job is being released, a long wait (greater than 30 seconds) may be unreasonable.

For those operations where a Pharos product utilizes SNMP (printer discovery, printer data collection, or printer status before print job release), timers have been implemented around those communications so that "sorry, this took too long, so we ended it" messages can be fed back to either the application or the user. The last symptom, above, is one such message.


So, What Happens?

In most cases, a timeout happens because the printer on the other side of the communication is really offline (turned off; moved, so it has a different IP address; network connection unplugged; etc.) so the timeout message is the last message found in a log file or on the user interface.

Sometimes, however, a device or the network is just slow. The "traffic lane" that SNMP uses in a lot of networks is the slow lane: bandwidth priority is given to Voice Over IP (VoIP), email, web traffic, file sharing, and other needs, so "non-essential" network apps get the left-overs. It could be that the printer is having a rough time waking up and responding to the SNMP message fast enough, or the network is experiencing high utilization and some latency ("lag") is creeping in. When something like that happens, the Pharos software ends up cancelling the initial data request and sending another. Each data request gets an identifying sequence number so that the application can keep things straight.

In the error message above, the initial sequence number, 212442385, was cancelled because the timeout was reached and it followed up with a new request with a sequence number of 212442588. While it was waiting for a response using the new sequence number, the original one (that was cancelled) came back. Since the initial request was closed, the response is rejected.

What will likely happen with this device is that the subsequent attempts will be stymied by the same problem that delayed the first connection attempt, so the device won't be added, updated, or sent the print job.



The resolution is to increase the timeout value. The product documentation for your specific application (found here in Documentation & Downloads) will tell you how to increase the timeout. When increasing timeouts, remember that this may have an impact on the time required to perform a network scan (Device Scout or Site Monitor), update device data (Device Scout or Site Monitor), or get the user's print job out (Blueprint and Uniprint's Secure Release Here), so start small and make incrementally longer changes as necessary.


Depending upon the configuration of the Active Directory domain controllers, the Standard Authentication Script provided with Pharos Blueprint Enterprise may not be immediately successful, causing login attempts at devices and unauthenticated Print Scout clients to fail.



One or more of the following errors may be presented:

  • Message: Unable to authenticate user. Either user does not exist, or the password is incorrect.
  • Message: The server cannot handle directory requests.




One of the reasons Active Directory-based authentication may fail is binding. When a .Net application like Pharos Blueprint Enterprise attempts to authenticate a connection with Active Directory it has to present the correct context to the domain controller. The various bind options are discussed in ContextOptions Enum (System.DirectoryServices.AccountManagement) | Microsoft Docs (this article explains them in terms of .Net 4.8; it applies to any version of .Net).


In the case of the Standard Authentication Script, it does not actually specify a binding, which forces a Basic Authentication event. Many domain controllers are specifically configured to not allow Basic Authentication.



To change binding to Active Directory in the Blueprint Standard Script, modify the following line, found in function ActiveDirectoryQueryWorker()


if (!adContext.ValidateCredentials(userId, password, ContextOptions.Negotiate))


Possible values for this can be found in the document referenced in the "Cause" above. NOTE: The only change that may generally be required is to force use of Kerberos, which is done by changing the text to:


if (!adContext.ValidateCredentials(userId, password, ContextOptions.Negotiate | ContextOptions.Sealing))