Download HP JetAdvantage Security Manager

HP JETADVANTAGE SECURITY MANAGER
Using Microsoft® SQL Server
CONTENTS
Overview ............................................................................................................................. 2
Introduction........................................................................................................................... 2
SQL Permissions .................................................................................................................... 3
Creating a SQL Database................................................................................................. 3
Upgrading a SQL Database ............................................................................................. 3
Using a SQL Database ..................................................................................................... 4
Less Elevated Priveleges .......................................................................................................... 5
Installing HP Security Manager ................................................................................................ 5
New Installation .............................................................................................................. 5
Upgrading Security Manager ................................................................................................ 10
Migrating the Security Manager Database .............................................................................. 12
Using a Different SQL Account ............................................................................................... 13
Sharing Same SQL with Web Jetadmin ................................................................................... 13
Using a Different Connection Port........................................................................................... 14
Summary of Options for Remote Database .............................................................................. 14
New Install, Remote Database, Rights to Create a Remote Database .................................... 15
New Install, Remote Database, No Rights to Create a Remote Database ............................... 15
Upgrade, Remote Database, Rights to Update a Remote Database ....................................... 15
Upgrade, Remote Database, No Rights to Update a Remote Database ................................. 15
Troubleshooting ................................................................................................................... 16
Database Encryption ............................................................................................................ 17
SQL AlwaysOn ................................................................................................................... 17
Failover .............................................................................................................................. 18
Network Bandwidth ............................................................................................................. 18
Summary ............................................................................................................................ 20
Appendix ........................................................................................................................... 21
SQL Script ....................................................................................................................... 21
OVERVIEW
HP JetAdvantage Security Manager requires a Microsoft SQL Server database in order to maintain a
fleet of devices for security compliance. If desired, Security Manager can install and use a new MS
SQL instance and database running under Microsoft SQL Express. However, it may be more
convenient for Security Manager to use an existing full Microsoft SQL Server instance for performance
benefits or to appease company policies. Fortunately, Security Manager can be configured to use
SQL Server instead of SQL Express either on the same machine or a remote machine. This document
describes the various SQL options and how to configure Security Manager to use a database other
than the default SQL Express database that it offers to install.
Versions of MS SQL Server or Express that have been tested include the following:




MS
MS
MS
MS
SQL
SQL
SQL
SQL
Server
Server
Server
Server
Express 2012
Express 2014 (Bundled)
2012
2014
While Security Manager only tests the two most recent SQL versions at the time of release, there
should be no issues using older SQL versions as Security Manager uses basic calls into the SQL
database and isn’t using SQL features that require later versions. Backward compatibility should be
present, there just isn’t capacity to test the multitude of SQL versions offered over the years.
The same holds true for the multitude of special features offered by the various versions on SQL Server
such as AlwaysOn and client/server encryption. There are entirely too many to test, but you’ll likely
find most will work fine with any client including Security Manager. One feature that has been
minimally tested and found to work well is the AlwaysOn feature that provides high-availability
failover and disaster recovery. See the chapter near the end of this document for more details.
INTRODUCTION
Whether using local or remote SQL Server, Express or Full, the rules are essentially the same. In
every case, Security Manager needs access to a SQL server instance. It can either create a new
database, upgrade an existing database, or attach to an existing database, depending upon the
situation and the user rights. If Security Manager is instructed to install SQL Express on the local
machine, a SQL instance and database for Security Manager will be created by the Security
Manager installer. If Security Manager is pointed to a remote SQL server and instance during
installation, proper rights must be present for the user running the installation to be able to create or
update a SQL database wherever SQL server may reside. Proper rights must also exist on the remote
database itself for the user which the Security Manager service runs under to be able to read from
and write to the database.
KEY POINT: Just to reiterate, for installing and upgrading Security Manager, the user who is logged
into the machine and running the installer executable must have proper rights on the SQL server to
either create a database or update an existing database. All the installer does is run SQL scripts to
create or alter a database, and naturally any user running those commands needs to have proper
SQL rights. In this case it is the Windows user who is running the installer. For normal operation of
Security Manager after installation, the user running the Security Manager service (default as Network
Service) needs to have permissions to at least read and write to the database (explained later).
Each Security Manager installation must point to its own unique database, multiple installations
cannot share a database. Several techniques are available to allow Security Manager to install/use
a SQL database in any location.
Both a named and default instance are supported when instructing Security Manager to use a remote
SQL Server database.
SQL PERMISSIONS
There are three scenarios where Security Manager will interact with Microsoft SQL:
 Creating a database during installation of Security Manager
 Upgrading a database during upgrading of Security Manager from one version to another
 Running Security Manager to manage security features on a fleet of devices
Each scenario requires a different set of SQL rights for potentially different users.
 Create Database – Windows user running the installer executable needs at minimum Create
Database rights (sysadmin preferred).
 Upgrade Database – Windows user running the installer executable to upgrade versions
needs DBO rights to perform potential commands on the database such as insert, update,
alter, create table.
 Run Security Manager – the Windows account that runs the Security Manager service (default
of Network Service) needs DBO rights to perform operations such as reading and writing.
NOTE: it will be explained below how to run with less rights or a different account if desired.
Creating a SQL Database
If Security Manager is instructed to create a database during installation, SQL commands are
performed to create the database and its necessary tables. In order for the Security Manager installer
to be able to create a SQL database , the credentials of the user running the Security Manager
installer need to have at least Database Create rights on the SQL instance (sysadmin preferred). If a
local database is desired, since the user running the Security Manager installer likely is a member of
the Admin group of the local machine, proper rights will be present to create a SQL database.
However, if a remote database is desired, such as on a remote SQL Server farm, it is unlikely that the
SQL database administrator (DBA) will provide sysadmin or even Create Database rights for the user
running the Security Manager installer. If this is the case, options to create the database include:

SQL DBA runs the Security Manager installer on the remote SQL server and instructs it to
create database only which will create a database named HPIPSC and all necessary tables.

SQL DBA obtains a SQL script from HP Support and runs it to create the database and all
necessary tables.

SQL DBA logs into the Security Manager machine, performs the install, and instructs the
installer to create the database and all necessary tables on the remote server\instance.

SQL DBA provides temporary sysadmin rights to the Windows user running the installer until
it completes creating the database and necessary tables.
Upgrading a SQL Database
When attempting to upgrade Security Manager from one version to another, it is very likely that new
columns have been added to tables or new tables have been created to represent new features. SQL
commands such as insert, update, alter, create table may be used to upgrade the database, and
these commands require elevated rights on the Security Manager database for the Windows user
running the installer and issuing the commands. DBO rights for the Windows user running the
upgrade will suffice to allow for these commands to be performed. If a local database is desired,
since the user running the Security Manager installer likely is a member of the Admin group of the
local machine, proper rights will be present to upgrade the SQL database. However, if a remote
database is desired, DBO rights will be necessary for the Windows user running the upgrade. If
allowing such rights on a permanent basis is an issue, options to upgrade the database include:


SQL DBA provides temporary DBO rights on the Security Manager database for the
Windows user running the upgrade until it completes.
SQL DBA logs into the Security Manager machine and performs the upgrade, allowing it to
upgrade the database.

SQL DBA obtains a SQL script from HP Support and runs it to upgrade the database and all
necessary tables.
Using a SQL Database
Once the database has been created and Security Manager is trying to use it, the credentials of the
user running the Security Manager service will need DBO rights on the database. By default, Security
Manager runs under Network Service, but the Security Manager service identifies itself as a network
service only locally. Remotely, Security Manager identifies itself as Domain\Machine$ when
Windows Authentication (Integrated Security) is used. In this case, use SQL Management Studio to
create a new login under Security, Logins and make sure the Domain\Machine$ account (where
Machine$ is the name of the Security Manager machine followed by a dollar sign) has DBO rights on
the Security Manager database under User Mapping.
NOTE If it is desired to use a Windows User account instead of a Windows Machine account, the
properties of the Security Manager service need to be changed from Network Service to the
Windows User account. Once performed, Security Manager identifies itself to the remote SQL Server
as the Windows User account. Therefore, make sure the Windows User account has DBO rights on
the database. Directories on the Security Manager machine where Security Manager files reside must
have Full Control rights for that user account as well.
SQL Server 2012 by default may not include Network Service as a default login. To rectify the
situation, use Microsoft SQL Server Management Studio to add the service name to the logins for this
database instance. You can then ensure the login for Network Service has DBO rights on the HP
Security Manager database.
LESS ELEVATED PRIVELEGES
DBO rights merely provide complete control over a single database. Providing DBO rights on the
Security Manager database does not provide access to any other databases nor does it allow any
administrative tasks on the SQL instance. It just allows Security Manager to perform tasks on the one
database it uses.
That being said, there still may be cases where it is against company policy to assign elevated rights
such as DBO rights on ANY database that is contained on the company SQL farm. It is possible to
run HP Security Manager on just read/write rights on the database after making a configuration file
change. Navigate to the following folder location on the Security Manager server:
Program Files (x86)\HP JetAdvantage Security Manager\HPSM_Service.exe.config
Open the Security Manager_Service.exe.config file in a text editor and locate the following entry:
<add key="shrinkDB" value="true" />
Change the “true” value to “false” so that it looks like this:
<add key="shrinkDB" value="false" />
Save the file, keeping the extension intact. Restart the HP Security Manager service.
The DBO privilege can be removed/unchecked and the db_datareader and db_datawriter priveleges
can be added/checked in addition to public rights. The Security Manager service should still be able
to connect to the database and perform read and write functions as necessary. Automatic shrinking
of the database and log files to maintain file size will now have to be performed by the database
administrator on a manual basis as Security Manager will no longer be performing this task.
Elevated rights will still need to be provided by the user running installs/upgrades though. It may be
possible to piece meal rights to simulate most of what DBO provides, but it certainly easier to just
assign DBO rights for upgrades.
INSTALLING HP SECURITY MANAGER
New Installation
When running the Security Manager installer as a new install, the first decision regarding SQL is to
decide if Security Manager should install just a client to attach to an existing Security Manager
installation, just a database to be used by an existing Security Manager installation, or a full Security
Manager installation. The options presented are as follows:

Database Only – Security Manager will install the SQL database on an existing SQL
instance. This option does not install SQL Express, only the SQL database (named HPIPSC).
An example of where this might be used is to run this option on a remote SQL Server where it
is desired to use for the Security Manager SQL database to reside. This option could be run
on the remote SQL Server itself just for the purpose of having the Security Manager database
created there. The Security Manager installer could then be run on the Security Manager
server and pointed to this existing database. The Windows account that is logged into the
machine and running the installer executable must have sufficient rights in SQL to create a
database.
The next screen asks for a location to install the database (server name\instance name):

Full Install – Security Manager will install the Security Manager user interface, Security
Manager services, and all desired SQL components.
The next screen dictates whether Security Manager will be installing SQL Express, creating or
upgrading a database, or just attaching to an existing database, local or remote. The
options presented are as follows:
−
Install SQL Server Express 2014 – Security Manager installs this version of SQL
Express on the local machine and creates an instance named SQLEXPRESS and a
database named HPIPSC. This option can take some time to complete. You will see
the SQL installer screen just as you would if you had launched the SQL installer
setup.exe file outside of the Security Manager installer but with answers to questions
being provided automatically.
−
Create a New or Upgrade an Existing Database – creates a database
named HPIPSC on an instance that exists on a local or a remote machine. This
option will also upgrade an existing database if one exists and is an older version
than the version of Security Manager being installed. Enter the name of the SQL
server and instance (server\instance). If a default instance is used rather than a
named instance, SQL allows you to skip entering an instance at all. Security
Manager will create a database at the location specified if one does not exist
assuming proper credentials are present to do so.
If a Security Manager database already exists at that location, the installer will ask if
you want to use it or re-initialize it. If Use existing database is selected, if the version
is older, Security Manager will upgrade the database to match the installer version.
Otherwise, Security Manager will merely attach to the database. If Re-initialize
database is selected, Security Manager will erase all existing data stored in the
database.
−

Connect to an Existing Database on Local or Remote SQL Server - this
option should be used only if you know you already have a Security Manager
database present at the location specified and it is the proper version to match the
Security Manager version that is being installed. It too will ask for a location of the
SQL server/instance where the database resides.
User Interface Only – Security Manager installs only a client interface that allows you to
point to a remote machine where Security Manager and its services have been installed.
UPGRADING SECURITY MANAGER
Upgrades are necessary for new device support, new features and defect fixes. If the Security
Manager installer is being used to upgrade an older version to a newer version, the installer will
detect the previous version and will indicate that a major upgrade will be performed.
Next the installer asks for the Database Location:
Select the second option to Create a New or Upgrade an Existing Database if the Windows account
running the installer has proper SQL rights (DBO or greater) to upgrade the database. If the
Windows account running the installer has insufficient rights to upgrade the database, the database
administrator will have to upgrade the database separately. The installer could still complete without
proper rights to upgrade the database, but Security Manager will not be able to attach to the
database until the DBA upgrades it.
Since the installer does not know if a local or remote SQL database is in use, it asks for the location of
the SQL server\instance where the database resides. As long as proper rights are present to do so
(DBO rights on the database for the Windows user running the upgrade), the Security Manager
installer will update the database to match the new version that is being installed.
If no rights at all are present on the database for the user running the upgrade, the installer will
display an error indicating the server\instance could not be found. If some rights are present on the
database for the user running the upgrade but not enough to perform the necessary commands to
upgrade the tables), the installer will complete, but the database will not be upgraded to match the
Security Manager version. When attempting to launch Security Manager, the service will recognize
the database mismatch and display an error that it could not connect to the database. The log files
(described in the Troubleshooting section) will likely indicate some columns are missing, etc.
If this occurs, one option is to simply uninstall Security Manager under Programs and Features, but
when asked if you would like to delete the database, select No.
Finish the uninstall, then install the previous version, pointing to the remote server\instance where the
database still resides. Now ensure proper rights are in place before attempting the upgrade again.
Another option is to obtain a SQL script from HP Support that can be run to upgrade the database
tables to match the installer version. Now when the Security Manager is restarted, it can use the
upgraded database.
MIGRATING THE SECURITY MANAGER DATABASE
If Security Manager was installed using a local SQL instance and database, but it is desired to use a
remote SQL instance and database instead without losing any of the work performed on the local
installation, the local Security Manager database can be migrated to the remote SQL server instance
if desired using either of the following techniques:

Backup/Restore Database – Use SQL Server Management Studio to backup/restore the
Security Manager database. Stop the Security Manager service before manipulating
databases in SQL Server Management Studio. Now the local database can be backed up
using SQL Server Management Studio and subsequently restored on the remote SQL instance.

Copy/Attach Database - Stop the Security Manager service, manually copy the database
files from the local location to the remote SQL server. If you are unsure where the database
files are located, check the properties of the SQL service for the instance, it will indicate the
file path to the database. Typically the directory will appear as such:
C:\Program Files (x86)\Microsoft SQL Server\MSSQLxx_xx.SQLEXPRESS\Data
The database files for Security Manager are named HPIPSC.mdf and HPIPSC_log.ldf. Copy
these files to the remote instance of SQL. SQL Server Management Studio can be used to
login to the remote instance and attach the Security Manager database to the instance.
Once the database has been restored on the remote instance, Security Manager needs to be
instructed to use the new remote database. The easiest technique is to uninstall/reinstall Security
Manager and select option 3 to connect to an existing database, pointing to the remote
server\instance. When the uninstaller asks if you want to save the local database, you can keep it as
a failsafe in case something wasn’t performed correctly in the remote restoration.
An alternate method, although more error prone, is to edit a configuration file that dictates where the
database resides that Security Manager uses, then restart the Security Manager service. Since editing
configuration files can be risky, it is recommended to perform the uninstall/reinstall technique since
that ensures the configuration file has the proper entries. However, if it is desired to edit a
configuration file, edit the following file:
C:\Program Files (x86)\HP JetAdvantage Security Manager\HPSM_Service.exe.config
Near the top of the file, edit all lines referencing the existing SQL server\instance to now include the
instance\server of the remote SQL server. The first two lines appear as such:
<add key="dbConnection" value="Server=(local)\FULL2012;initial catalog=HPIPSC;Integrated Security=SSPI" />
<add key="dbMasterConnection" value="Server=(local)\FULL2012;initial catalog=master;Integrated Security=SSPI" />
In this example replace “(local)\FULL2012” with the correct name of the remote server\instance.
Make sure to change these two lines and any additional lines where the local server\instance is
referenced with the new server\instance name.
A third option that doesn’t involve migrating the actual database is just to export the device list and
policies in Security Manager, install a fresh installation of Security Manager pointing to a new remote
database, then import the device list and policies. Really all that is lost in this scenario is the
remediation history and any credentials that were saved in the database for the devices to be used
for future communications to those devices. If the same credentials are being used for the fleet, it is
very easy to right-click on the All Devices Group and enter the credentials once. This applies them to
each device in the database for use in future communications to the devices.
NOTE: Security Manager encrypts some data in the database, items such as policies and credential
data, and the encryption is tied to the key on the Security Manager server that created the database
entries. Therefore, it is acceptable to move the database to a different SQL server as long as the
original Security Manager server is still using it since the encryption key is still valid for the original
Security Manager server. If a different Security Manager server is instructed to use the database,
now the policies must be recreated and the credential data re-entered before Security Manager can
function properly.
USING A DIFFERENT SQL ACCOUNT
If it is prohibited in the environment to allow a machine account to have DBO rights on a database, it
is still possible to allow Security Manager to use a remote database by allowing a domain user
account the have DBO rights to the database. In this case, the Security Manager service on the
Security Manager machine would have to be instructed to run under this same domain user account.
The files that Security Manager uses on the Security Manager machine in the following directories
would need to be assigned permissions of Full Control for the domain user account:
C:\Program Files (x86)\HP JetAdvantage Security Manager
C:\ProgramData\HP\HP Print License Service
Remember, it is the account that the Security Manager Service runs under that dictates whether a
domain machine account or a domain user account will be used.
SHARING SAME SQL WITH WEB JETADMIN
Just like HP Web Jetadmin, Security Manager offers to install the Express version of SQL for customers
who don’t have an existing SQL installation to use. If Security Manager is being installed in an
environment where HP Web Jetadmin is already installed and managing the fleet, there is a SQL
database in use for Web Jetadmin, either locally to the Web Jetadmin server or remotely on a SQL
server farm.
There is absolutely no reason why Security Manager could not share the same SQL instance as HP
Web Jetadmin. The two products would not be sharing databases, those would be unique for each
product, but the two databases can exist under the same SQL instance. The Security Manager
installer makes it very easy to point to an existing SQL server\instance as described earlier in this
document.
Both Web Jetadmin and Security Manager can also be installed on the same server if desired and
share the same SQL instance. Web Jetadmin has the potential to use many more server resources
depending upon the number of devices it is managing and how it is being utilized, and it may prefer
to be standalone for that reason. However, Security Manager uses much less resources and has no
issue sharing a server with a Web Jetadmin installation. The two products are very similar in port
requirements thus firewalls are likely already setup nicely for both products.
The biggest difference between Web Jetadmin and Security Manager as far as permissions are
concerned is that Web Jetadmin doesn’t provide any options during installation to use a remote
database. It requires modification of a config file to use a remote SQL instance, thus the Web
Jetadmin service is expected to have certain rights to use and upgrade a database. Since Security
Manager does provide installation options to use a remote SQL instance, the rights of the user running
the installation need to be elevated to create/upgrade a database.
USING A DIFFERENT CONNECTION PORT
HP Security Manager will use by default TCP Port 1433 to connect to a MS SQL server and instance.
If company policy prohibits the use of this port and requires a different port, merely add the desired
port in the connection string either in the installer UI when entering the server/instance information or
in the configuration file mentioned above. The port should be added immediately after the server
FQDN separated by a comma as such:
SQL server FQDN,port\instance
For example, to use a SQL server named SQLserver, an instance named sql2012full, and a port of
1434:
<add key="dbConnection" value="Server=SQLserver,1434\sql2012full;initial
catalog=HPIPSC;Integrated Security=SSPI" />
<add key="dbMasterConnection" value="Server=SQLserver,1434\sql2012full;initial
catalog=master;Integrated Security=SSPI" />
In the installer UI enter: SQLserver,1434\sql2012full
SUMMARY OF OPTIONS FOR REMOTE DATABASE
The following scenarios summarize the steps involved to install or connect to a remote Security
Manager database. The scenarios include a new install or an upgrade, both with and without
elevated rights on the remote SQL instance. To create a database, sysadmin rights are preferred, but
Create Database rights are sufficient. For an upgrade of the database, DBO rights are preferred. By
default, Security Manager runs under Network Service, which means the Security Manager machine
account (machine$) needs to have DBO rights on a remote SQL database. If a machine account is
prohibited, a Windows user account can be granted DBO rights instead, but directories on the
Security Manager machine must have Full Control rights for that user account as well.
New Install, Remote Database, Rights to Create a Remote Database
Select Full Install, Create a New or Upgrade an Existing Database, enter remote SQL server and
instance (server\instance). Use SQL Management Studio to ensure the user the Security Manager
service runs under has DBO rights. Restart the Security Manager service.
New Install, Remote Database, No Rights to Create a Remote Database
Option 1 - Have the SQL DBA create the Security Manager database on the remote SQL server by
running the Security Manager installer on the SQL Server and choosing Database Only. Use SQL
Management Studio to ensure the user the Security Manager service runs under has DBO rights. Run
the Security Manager installer again and select option 3 to use an existing database, pointing to the
remote server\instance location.
Option 2 - Run Security Manager installer on Security Manager machine and select Full Install, Install
SQL Express 2014. After the installation completes, copy or backup/restore the local Express Security
Manager database to the remote SQL instance. Use SQL Management Studio to ensure the user the
Security Manager service runs under has DBO rights. Run the Security Manager installer again and
select option 3 to use an existing database, pointing to the remote server\instance location.
Option 3 – Contact HP support to obtain a SQL script that can be run on the remote SQL server by the
SQL DBA to create a usable Security Manager database on the desired SQL instance (see Appendix
for instructions on running the script). Use SQL Management Studio to ensure the user the Security
Manager service runs under has DBO rights. Run the Security Manager installer again and select
option 3 to use an existing database, pointing to the remote server\instance location.
Option 4 – Have the SQL DBA assign temporary rights to the Windows user running the installation
just long enough to complete the installation and create the database. Run the Security Manager
installer and select option 2 to create a database, pointing to the remote server\instance location.
Use SQL Management Studio to ensure the user the Security Manager service runs under has DBO
rights.
Option 5 – Have the SQL DBA perform the installation using his/her Windows account that has
permissions to update the database. Run the Security Manager installer and select option 2 to Create
a New or Upgrade an Existing Database, pointing to the remote server\instance location. Use SQL
Management Studio to ensure the user the Security Manager service runs under has DBO rights.
Upgrade, Remote Database, Rights to Update a Remote Database
Select Full Install, Create a New or Upgrade an Existing Database, enter remote SQL server and
instance (server\instance). The database will be updated properly to run under the new version.
Upgrade, Remote Database, No Rights to Update a Remote Database
Option 1 – Have the SQL DBA assign temporary rights to the Windows user running the upgrade just
long enough to complete the installation and update the database.
Option 2 – Contact HP support to obtain a SQL script that can be run on the remote SQL server by the
SQL DBA to update the Security Manager database on the desired SQL instance (see Appendix for
instructions on running the script).
Option 3 – Have the SQL DBA perform the upgrade using his/her Windows account that has
permissions to update the database. Run the Security Manager installer and select option 2 to Create
a New or Upgrade an Existing Database, pointing to the remote server\instance location. Use SQL
Management Studio to ensure the user the Security Manager service runs under has DBO rights.
TROUBLESHOOTING
The first sign of trouble if something goes wrong might be an error as such when launching Security
Manager:
Clues can be found in the log files found under:
C:\Program Files (x86)\HP Imaging and Printing Security Center\log
Open the Security Manager_Service.log file in an editor and look for errors indicating the database
cannot be opened:
2015-02-18 08:02:31,597 INFO Service [4] - TaskSupervisor.Init - HP Security Manager Starting
2015-02-18 08:02:41,680 INFO Service [4] - ScheduleTaskManager.RetryDBConnection Testing DB
connection to: Server=Security Managertestthree\sql2012full;initial catalog=HPIPSC;Integrated
Security=SSPI
2015-02-18 08:02:42,041 ERROR Service [4] - DB connection error: Cannot open database "HPIPSC"
requested by the login. The login failed.
Login failed for user 'AMERICAS\jmetz2$'.
In this example, the log file confirms that Windows Authentication is attempting to login the user the
Security Manager runs under into the correct remote server\instance name but is being rejected. In
this case the Security Manager machine account (jmetz2$) did not have DBO rights to use the
database. Use SQL Management Studio to confirm the user running the Security Manager service
has DBO rights.
Also, make sure the Security Manager service was restarted after making the changes to the database
rights.
Ensure the Security Manager_Service.exe.config file contains the correct entries:

The server or instance name is not correct. Double-check the spelling of each.
It is possible network related issues are preventing the connection to the remote instance. Common
troubleshooting steps include:

Fully qualify the remote SQL server name in the configuration file if name resolution issues are
present or use the IP address instead of the hostname.

TCP/IP must be enabled on the remote SQL server instance. Use SQL Server Configuration
Manager to confirm.

Check firewall settings to ensure the port that is used for the remote connection is open. The
default port is 1433.

SQL Server may default to using a dynamic port. Either configure to use a fixed port or start
the SQL Browser service to allow for remote connections.

Use SQL Management Studio and/or Windows ODBC to connect to the remote SQL
server/instance from the same machine as Security Manager to at least prove a Windows
user account can access the server/instance from the Security Manager machine.
The log may also indicate columns are missing, meaning the database may not have been upgraded
due to insufficient rights by the user running the upgrade. This scenario is described earlier in this
document with steps on how to uninstall/reinstall to rectify.
DATABASE ENCRYPTION
All of the data that Security Manager stores in the SQL database, whether local or remote, is
protected against unwanted access by Microsoft Windows credentials. As an additional method of
security for protecting the most critical data, Security Manager will always encrypt the following types
of entries in the database:


All credentials that are stored per device to be used for communications to the device
All policy settings, which may or may not include credentials
Security Manager uses an AES algorithm for FIPS compliance to protect the data in the database. If
desired, the entire database can be setup to be encrypted by the SQL administrator using SQL tools.
Also, if desired, the transmission of the data from the Security Manager client to the SQL database
server can be encrypted using either IPSEC or SSL. The SQL instance could be setup to force
encryption from all connecting clients, and certificates could be installed on both the server and client
to ensure trust and encryption.
SQL ALWAYSON
SQL Server AlwaysOn provides a high-availability and Disaster-recovery solution for SQL Server. It
makes use of existing SQL Server features, particularly Failover Clustering, and provides new
capabilities such as availability groups. AlwaysOn Availability Groups allow you to fail over a group
of databases as a single entity. An Availability Group Listener is a Virtual Server Name that
applications connect to. From the applications point of view it does not matter where the Availability
Database is active and available for use. The AAGL consists of:



Virtual Network Name (VNN)
Listener Port
One or more Virtual IP Addresses (VIPs)
For clients to connect, you can either set up a connection string for your AAGL or connect directly to
your SQL Server Instance. However, a direct connection does not give the failover support which this
technology has been built for.
For Security Manager, you can use the Availability Groups listener name in the connection string used
to connect to the sever\instance. The easiest technique is to modify the connection string in the
following file:
C:\Program Files (x86)\HP JetAdvantage Security Manager\HPSM_Service.exe.config
The connection string can be found near the top of the file, change the portion that references the
server\instance to just reference the Availability Groups Listener. For example, here is a sample of a
connection string that points to a listener named “sqlgroup”:
<add key="dbConnection" value="Server=sqlgroup;initial catalog=HPIPSC;Integrated Security=SSPI" />
<add key="dbMasterConnection" value="Server=sqlgroup;initial catalog=master;Integrated Security=SSPI" />
Restart the Security Manager service after saving the edited file, and Security Manager should
connect to the Availability Group that contains the Security Manager databases. If the primary
replica instance is suddenly stopped, the database from a secondary replica instance will be used in
its place.
FAILOVER
While SQL AlwaysOn provides high-availability or failover for the Security Manager database, what
about cases where the Security Manager server is no longer available? How can you ensure another
installation of Security Manager is up and running as quickly as possible to minimize downtime?
The biggest challenge presented for failover of the Security Manager server is the licenses that are
installed and node-locked to the Security Manager server. All of the devices, groups, policies,
schedules, remediation data over time, etc. are stored in the database. Therefore, as long as the
database is always available, Security Manager can also be made to be available in a quick manner
by installing Security Manager on a new machine and instructing it to use the existing database.
Older versions of Security Manager “locked” the database to the original Security Manager machine,
but now there is no longer a lock.
The user running the Security Manager service (default Network Service which manifests itself
remotely as the machine account) still needs DBO rights on the database in order to use it, but it isn’t
locked to a specific Security Manager machine. To simplify matters, as long as the new Security
Manager server uses the same hostname as the old Security Manager server, SQL rights on the
database could remain as is if SQL is assigning the machine account to have DBO rights. Also, if
Instant On is being used to discover devices, announcements would still be sent to the hostname of the
original Security Manager server which hasn’t changed.
To move the licenses from one Security Manager machine to another, merely browse to the licensing
web site where the licenses were obtained originally and re-host them to a new mac address.
NETWORK BANDWIDTH
Questions often arise as to how much network bandwidth a fleet management tool such as Security
Manager consumes during everyday operation. Many years ago when pipes were small and speeds
were slow, there was a valid concern over tools that regularly performed network discoveries to
manage devices. However, today the traffic that management tools generate is quite small compared
to the large amounts of traffic passed merely over a browser by most users on a regular basis, for
example.
Even better with Security Manager, you more or less control how much traffic will occur and when it
will occur. While some tools are always generating traffic for reasons such as a background poller,
processing random alerts, etc., Security Manager usually only generates traffic during the scheduled
remediation tasks. Of course, if Instant On is enabled and being used for discoveries, it can cause
remediations to occur every time an announcement is sent to Security Manager for cases such as
when a device is power cycled, cold reset, etc. That is, however, a fairly infrequent occurrence.
Many users will opt to import an existing list of devices that were exported from Web Jetadmin as the
discovery mechanism, which will do nothing more than perform a DNS lookup to obtain the
hostnames for all of the devices. A subsequent Verify task will retrieve a minimal amount of attributes
from each device to populate the few columns that Security Manager offers. The bulk of the network
traffic from this point forward is initiated by the scheduled remediation tasks are typically scheduled to
run daily.
When examining network traffic between Security Manager and each device for a remediation task,
results are shown below. Three types of devices are examined:
Newer full featured Futuresmart MFP (HP Color LaserJet M775 MFP)
Older full featured Futuresmart MFP (HP Color LaserJet CM4540 MFP)
Full featured legacy MFP (HP Color LaserJet CM3530 MFP)
The disparity between legacy and Futuresmart is not very much as many of the network related
settings are exposed via SNMP on both legacy and Futuresmart devices. While most of the printer
related settings are exposed via Web Services on Futuresmart and are represented by the TCP
packets below, many of those same features are exposed via DSMP and/or EWSCONFIG on legacy
devices, which is still a TCP transaction. So while there are more SNMP and less TCP transactions for
legacy devices, the TCP transactions are still verbose enough to close the gap somewhat.
After applying a Base policy to an assessment task, the numbers are as follows below. In bold the
total traffic in bytes for each device is displayed, and the numbers beneath the total show the
breakdown of SNMP vs TCP. This addresses an assessment, and settings that would need to be
changed as part of a remediation because they are out of compliance would add additional traffic
similar to the assessment traffic. However, it is likely that after the first remediation, when devices are
in steady state, remediations are few and far between.
A simple summary might conclude that the base policy requires roughly 100K-150K in bandwidth to
assess per device depending upon the device.
Network traffic (Size in Bytes):
Results will naturally vary depending upon the amount of items being assessed in a policy, but the
Base policy is a fair representation of a typical policy.
This does not include any traffic that might be occurring between Security Manager and SQL if the
database is remote. The above examples were generated using a local database. It is hopefully well
understood that by introducing a remote SQL database that it also adds traffic between Security
Manager and the remote SQL server to read and write database entries. This certainly would not be
considered a large amount of traffic, but it is traffic nonetheless.
Two other conditions that could potentially generate a small amount of traffic during each remediation
includes:
-
-
If the Email Results box is checked for a scheduled remediation task, a very small SMTP
transaction will occur at the completion of the remediation task where a very short summary
of results is sent to a mail server to be delivered to recipients.
If firmware assessments are being performed, there is a possibility that an index file is being
retrieved at the beginning of the task to obtain a list of updated firmware versions for each
device. This is a very small HTTPS transaction to a remote FTP server to retrieve a very small
text file containing the version information.
SUMMARY
HP JetAdvantage Security Manager is a powerful security assessment and remediation tool for
keeping a fleet of devices in compliance with security policies. While it requires a SQL database, it
can install a new SQL Express version but also allows for connecting to an existing remote SQL Server
instance if desired.
APPENDIX
SQL Script
When the Security Manager installer is instructed to Create a New or Upgrade an Existing Database,
it essentially runs a series of SQL scripts in the background to create or upgrade SQL tables in a
database. As discussed in this document, different rights are required for the user running the installer
to be able to either create a new database or upgrade tables in an existing database. There may be
cases where it is easier just to provide these SQL scripts to a SQL database administrator who has all
the necessary rights to either create a new or upgrade an existing database. The other option is for
the DBA to run the Security Manager installer and choose DB Only, but most if not all prefer not to run
installers on the SQL server and like to run scripts to see what they do by examining them before
executing. Once the scripts are run, the Security Manager installer can merely be instructed to use
the database that the SQL scripts created or upgraded.
Contact HP Support whenever the SQL scripts are desired. You will normally receive a .zip file that
contains a set of files as such when unzipped:
From a command prompt, run the file named InstallDBRmt.bat and instruct it to run on the desired SQL
server and instance as such:
installdbrmt server\instance
You will see an execution of various scripts to install or upgrade the HPIPSC database:
The .bat file can be run on a remote machine from the SQL server, but the machine would have to
understand the “sqlcmd” SQL file in order to execute the scripts. Any machine where SQL had been
installed (or SQL Tools) would suffice as it would know how to run “sqlcmd.”
© Copyright 2016 HP Development Company, L.P. The information contained herein is subject to change without
notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying
such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be
liable for technical or editorial errors or omissions contained herein.
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
c04635799ENW, Rev.8, June 2016