HP JETADVANTAGE SECURITY MANAGER. Using Microsoft SQL Server

Transcription

1 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 Migrating the Security Manager Database Using a Different SQL Account Sharing Same SQL with Web Jetadmin Using a Different Connection Port Summary of Options for Remote Database New Install, Remote Database, Rights to Create a Remote Database New Install, Remote Database, No Rights to Create a Remote Database Upgrade, Remote Database, Rights to Update a Remote Database Upgrade, Remote Database, No Rights to Update a Remote Database Troubleshooting Database Encryption SQL AlwaysOn Summary... 18

2 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 SQL Server Express 2012 MS SQL Server Express 2014 (Bundled) MS SQL Server 2012 MS SQL Server 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.

3 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.

4 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.

5 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

6 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.

7 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.

8 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.

9 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.

10 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.

11 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.

12 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

13 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

14 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.

15 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 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. 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. 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.

16 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: :02:31,597 INFO Service [4] - TaskSupervisor.Init - HP Security Manager Starting :02:41,680 INFO Service [4] - ScheduleTaskManager.RetryDBConnection Testing DB connection to: Server=Security Managertestthree\sql2012full;initial catalog=hpipsc;integrated Security=SSPI :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 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.

17 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. The encrypted data is protected by a key that is unique to the machine where the Security Manager service is running. It will be the only machine that can read the encrypted data. Thus, if another Security Manager installation wants to use an existing Security Manager database, policies would have to be recreated and credentials would have to be re-entered as the existing ones could not be read by the Security Manager installation. 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" />

18 <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. 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. 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. c enw, Rev.7, February 2016