HPE 3PAR Policy Server Administrator Guide

HPE 3PAR Policy Server
Administrator Guide
Abstract
HPE 3PAR Policy Server provides customer-configurable remote service access policies. Installed on a customerprovided host, the Policy Server provides the customer with ultimate flexibility and control to allow or deny outbound
communication or remote service connections to and from an HPE 3PAR StoreServ Storage system.
Part Number: QR482-97203
Published: February 2017
| Legal Information | 2
Notices
Legal Information
© Copyright 2017 Hewlett Packard Enterprise Development LP
Confidential computer software. Valid license from HPE required for possession, use or copying. Consistent with
FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are
licensed to the U.S. Government under vendor's standard commercial license.
The information contained herein is subject to change without notice. The only warranties for HPE 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. HPE shall not be liable for technical or editorial errors or
omissions contained herein.
| Contents | 3
Contents
Preface ..............................................................................................................................................5
Accessing Hewlett Packard Enterprise Support .................................................................................................. 5
Supported Platforms ............................................................................................................................................ 6
Chapter 1: HPE 3PAR Policy Server: User Administration................................ 7
Signing In ............................................................................................................................................................ 7
Setting User Attributes ........................................................................................................................................ 8
Setting Up Security ............................................................................................................................................. 9
Roles Stored As Groups ........................................................................................................................ 10
Adding Profiles ...................................................................................................................................... 11
Adding Roles ......................................................................................................................................... 12
Adding Users ......................................................................................................................................... 14
Configuring SMTP Credentials for an Admin User ......................................................................................... 16
Chapter 2: Policy Server: Asset Groups .............................................................. 17
Understanding Asset Groups ............................................................................................................................. 17
Automatic Creation of Asset Groups .................................................................................................... 17
Manual Creation of Asset Groups ........................................................................................................ 18
Assets Tab ......................................................................................................................................................... 18
Creating an Asset Group ....................................................................................................................... 19
Notifications ........................................................................................................................................... 20
Editing Asset Groups ........................................................................................................................................ 20
Deleting Asset Groups ...................................................................................................................................... 21
Chapter 3: Policies .................................................................................................. 23
Understanding Policies ...................................................................................................................................... 23
Inheriting a Policy ................................................................................................................................. 23
Understanding Permissions ............................................................................................................................... 23
Access Rights ........................................................................................................................................ 24
Inheritance and Permissions .................................................................................................................. 24
Applying Filters ................................................................................................................................................. 25
Filter Evaluation .................................................................................................................................... 26
Configuring Policies .......................................................................................................................................... 26
Setting All Permissions ......................................................................................................................... 27
Locking Permissons ............................................................................................................................... 28
Hiding Permissions ................................................................................................................................ 28
Tips for Policies ................................................................................................................................................ 28
Base Installation Actions................................................................................................................................... 29
Chapter 4: Managing Assets from the Policy Server Application ..................... 32
Finding and Removing Missing Assets ............................................................................................................ 32
Monitoring Pending Requests ........................................................................................................................... 32
Monitoring Remote Sessions ............................................................................................................................ 33
Tips for Telnet Permissions .................................................................................................................. 33
Using Redundant Gateways with Policy Server ............................................................................................... 34
Communication with Policy Server in a Redundant Gateway Configuration ....................................... 34
Association between an Agent Gateway and Managed Assets ............................................................. 34
| Contents | 4
Chapter 5: Policy Server Maintenance ................................................................. 35
Starting and Stopping Policy Server ................................................................................................................. 35
Getting Version Information ............................................................................................................................. 36
Backing Up and Restoring the Database .......................................................................................................... 36
Backing Up the Database ...................................................................................................................... 36
Restoring the Database .......................................................................................................................... 37
Tips ........................................................................................................................................................ 38
Monitoring System Activity .............................................................................................................................. 38
Audit Log Entries .................................................................................................................................. 39
Audited Operations ................................................................................................................................ 40
Audit Log Persistence for Policy Agents .............................................................................................. 41
Sending Policy-related Messages to a Syslog Server ........................................................................... 41
Installed Directories and Files .......................................................................................................................... 41
Uninstalling Policy Server ................................................................................................................................ 43
Chapter 6: Configuration Files ............................................................................. 44
Changes Requiring Edits of Configuration Files .............................................................................................. 44
Editing the OpenDS Configuration File ........................................................................................................... 45
Editing the Policy Server Configuration File ................................................................................................... 46
Policy Server Properties ........................................................................................................................ 47
Editing the Tomcat server.xml File .................................................................................................................. 56
Enabling/Disabling Ciphers in the Tomcat server.xml File .................................................................. 56
Changing the Directory Server in the Tomcat server.xml File ............................................................. 56
Changing the Directory Server Password ......................................................................................................... 57
Modifying the OpenDS Administrator Password ................................................................................. 57
Changing the Directory Server Password in the Tomcat server.xml File ............................................. 58
HSQL Database Configuration File .................................................................................................................. 59
Appendix A: Troubleshooting Tomcat ................................................................. 61
Appendix B: Starting/Stopping HPE3PS Manually............................................ 62
Starting Policy Server Components Manually .................................................................................................. 62
Stopping Policy Server Components Manually ................................................................................................ 64
Preface
Accessing Hewlett Packard Enterprise Support
•
•
For live assistance, go to the Contact Hewlett Packard Enterprise Worldwide website:
http://www.hpe.com/assistance.
To access documentation and support services, go to the Hewlett Packard Enterprise Support Center website:
http://www.hpe.com/support/hpesc
Information to collect
•
•
•
•
•
•
•
•
Technical support registration number (if applicable)
Product name, model or version, and serial number
Operating system name and version
Firmware version
Error messages
Product-specific reports and logs
Add-on products or components
Third-party products or components
HPE 3PAR documentation
For information about:
See:
Supported hardware and software platforms
The Single Point of Connectivity Knowledge for Hewlett
Packard Enterprise Storage Products (SPOCK) website:
SPOCK
Locating HPE 3PAR documents
The Hewlett Packard Enterprise Storage Information
Library:
Storage Information Library
By default, 3PAR Storage is selected under Products
and Solutions
Customer Self Repair procedures (media)
http://www.hpe.com/support/csr
All Hewlett Packard Enterprise products
http://www.hpe.com/support/hpesc
Websites
Website
Link
Hewlett Packard Enterprise Information Library
http://www.hpe.com/info/enterprise/docs
Hewlett Packard Enterprise Support Center
http://www.hpe.com/support/hpesc
Contact Hewlett Packard Enterprise Worldwide
http://www.hpe.com/assistance
Subscription Service/Support Alerts
http://www.hpe.com/support/e-updates
Software Depot
http://www.hpe.com/support/softwaredepot
Customer Self Repair
http://www.hpe.com/support/selfrepair
| Preface | 6
Website
Link
Insight Remote Support
http://www.hpe.com/info/insightremotesupport/docs
Serviceguard Solutions for HP-UX
http://www.hpe.com/info/hpux-serviceguard-docs
Single Point of Connectivity Knowledge (SPOCK)
Storage compatibility matrix
http://www.hpe.com/storage/spock
Storage white papers and analyst reports
http://www.hpe.com/storage/whitepapers
Customer self repair
Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If a CSR part
needs to be replaced, it will be shipped directly to you so that you can install it at your convenience. Some parts do
not qualify for CSR. Your Hewlett Packard Enterprise authorized service provider will determine whether a repair can
be accomplished by CSR.
For more information about CSR, contact your local service provider or go to the CSR website: http://www.hpe.com/
support/selfrepair.
Remote support
Hewlett Packard Enterprise customer self repair (CSR) programs allow you to repair your product. If a CSR part
needs to be replaced, it will be shipped directly to you so that you can install it at your convenience. Some parts do
not qualify for CSR. Your Hewlett Packard Enterprise authorized service provider will determine whether a repair can
be accomplished by CSR.
For more information and device support details, go to the following website: http://www.hpe.com/support/selfrepair.
Documentation feedback
Hewlett Packard Enterprise is committed to providing documentation that meets your needs. To help us improve the
documentation, send any errors, suggestions, or comments to Documentation Feedback (docsfeedback@hpe.com).
When submitting your feedback, include the document title, part number, edition, and publication date located on the
front cover of the document. For online help content, include the product name, product version, help edition, and
publication date located on the legal notices page.
Supported Platforms
This document does not attempt to provide the supported software, hardware, and operating system platforms for this
product. For a complete summary of the supported and compatible platforms for all HPE products, refer to the support
matrix for the HPE products, available from the HPE Support site, http://www.hpe.com/support/hpesc.
Chapter 1
HPE 3PAR Policy Server: User Administration
This chapter assumes that you have installed and started HPE 3PAR Policy Server, whether a new installation or
an upgrade installation. You should be ready to sign in to the Policy Server application and either set up security
and policies for assets or review the migration of your existing user data, asset data, and policies. The Policy
Server application provides the tools you need to set up and manage access to the application, to set up and
manage the
asset groups and their policies, to monitor incoming requests from the assets being managed by Policy Server, and to
monitor remote sessions for the assets.
This chapter explains how to sign in to the application. Then, it explains how to set your user attributes (such as email address and password). Finally, it explains how to set up user security for Policy Server by adding profiles, roles,
and users. Here are the major sections
•
•
•
•
Signing In
Setting User Attributes
Setting Up Security
Configuring SMTP Credentials for an Admin User
Signing In
Start your browser and in the address bar, type the IP address and port number for Policy Server. If you are running
the browser from the same machine where Policy Server is running, you can type localhost . If you are using port 80,
you do not need to type a port number; otherwise, type the number of the listening port you chose for Policy Server.
You should see the login page for the Policy Server application, shown in the following figure:
Figure 1: Signing In
Type the Username and Password for the administrator you created in the LDAP directory server and added to the
HPE3PSAdmins group. If you are using the OpenDS directory server, the default administrator login credentials are
admin / admin .
After you click Sign in, the Policies page of the Policy Server application appears. The tabs and features available in
the application depend on the privileges associated with your user account. The following figure shows the features
available to a user who is an Administrator.
Note: If you or any of your users cannot all the functions (for example, Assign Files in the Policies tab), the
screen resolution is too low. For best results, use a high resolution (greater than 1024 x 768). In addition, a
small browser window can make use of the application inconvenient.
| HPE 3PAR Policy Server: User Administration | 8
Figure 2: Policy Server Dashboard
Setting User Attributes
Once you have signed into the Policy Server application, you can modify your user information in the User Attributes
page. If you are using an external directory server, the changes are stored in that external directory server. You can
change your default page, e-mail address, or your password, as follows:
1.
From the
dropdown menu, select Edit User Attributes, as shown here:
2. When the User Attributes page appears, you can edit your information. An example of this page is shown in the
following figure:
| HPE 3PAR Policy Server: User Administration | 9
3. From the Initial Screen list (shown above), select the screen that you want to display each time you sign in. As an
administrator of the system, you can select among the following tabs: Dashboard, Policy, Pending Requests, User
Administration, and Remote Sessions.
4. To update your e-mail address, phone, or fax number from the User Attributes page, type the changes in the fields
provided. The e-mail address must be formatted properly; for example, <yourName>@<yourCompany>.com.
5. If desired, you can change your password by typing a new password in the Password and Confirm Password
fields. By default, the password must be at least 6 characters in length. Your system administrator should tell you
if the password has a different length requirement.
6. If the only change you made in this page was the Initial Screen, you do not need to enter a password. However, if
you made any other changes, you must type your current password and confirm it.
7. To save your changes, click Save. To discard your changes, click Cancel. The User Attributes window closes.
Setting Up Security
After installing Policy Server, you need to set up security for the system. Setting up security consists of assigning
privileges to the components of the Policy Server application by configuring profiles, roles, and users. To configure
profiles, roles, and users, go to the Users tab of the Policy Server application. When you first sign in as the
administrator, all of the appropriate pages are available to you.
Note that you must know the login credentials for the administrator of the directory server associated with Policy
Server to add users. Adding users in the Policy Server application adds them to your directory server. Whether you
are using an external or internal directory server, be sure you know the username and password for the directory
server administrator.
Although you can add profiles, roles, and users in any order, you may want to add profiles first, then roles, and finally
users. You can always return to the added profiles, roles, and users and edit their definitions later. Note that you
cannot rename these elements; you must delete them and add new ones. The rest of this section explains how to add a
profile, a role, and a user. To learn about editing them, refer to the help for the Policy Server application.
Important: If you are using Active Directory as the directory server for Policy Server, you MUST configure
the communication to use SSL to be able to update a user’s password. In addition, if the connection is NOT
using SSL, you cannot manage users from the Policy Server application (add, modify, and delete actions are
all disabled).
| HPE 3PAR Policy Server: User Administration | 10
Roles Stored As Groups
If the option to manage Roles from the directory server is selected during installation, Policy Server Roles are
synchronized with a subset of groups in the directory server used by Policy Server. Each Role has a corresponding
group entity in the directory server (under ou=Groups ,dc=HPE ,dc=com in the standard HPE3PS/LDAP setup). These
groups contain all users assigned to that Role. This information is synchronized using the USER_TO_ROLE table
from the Policy Server database.
A meta group, called HPE3PSRoles (cn=HPE3PSRoles,ou=Groups,dc=HPE,dc=com), contains all groups that constitute
Roles in Policy Server. This group is created during the initial directory server setup. When a new Role is created in
the Policy Server application, a corresponding group is created in the directory server and added to HPE3PSPSRoles.
When the user-role membership is modified using the Policy Server application, the corresponding changes are
propagated to the directory server. This feature works with all currently supported directory servers.
Synchronization
A background task synchronizes the roles in a way that is similar to user synchronization, as follows:
1. Scan the HPE3PSRoles group to see if any groups that correspond to roles already exist in the directory server.
2. Check for a corresponding ROLE record, and if it does not exist, create it.
a) If a corresponding ROLE record does not exist, create a new record.
b) If a corresponding ROLE record exists, update the record.
c) If a ROLE record exists, but not for a corresponding group in the directory server, then delete the record.
3. Scan the list of users for the group, and create the USER_TO_ROLE records as needed.
Role Operations in the Policy Server Application
When a Role is modified through the Policy Server application, the corresponding changes are propagated to the
directory server. The Policy Server application prompts you to enter the administrative login credentials for the
directory server before allowing you to add, modify, or delete a Role. The results of the following Role operations are
synchronized with the directory server:
Adding a Role
1. Create the group entity with DN: cn=<RoleName>,ou=Groups,dc=HPE,dc=com and the description provided for the
role.
2. Add the created group to HPE3PSRoles.
Deleting a Role
1. Remove the role from the group HPE3PSRoles.
2. Delete the corresponding group entity.
Updating a Role
1. Update the description if it has changed.
2. Update the users in the role.
3. Update the role in the HPE3PSRoles group if the name of the role has changed.
Adding User to a Role
•
Add the user to the role's corresponding group in the directory server.
Removing User from a Role
•
Remove the user from the role's corresponding group in the directory server.
| HPE 3PAR Policy Server: User Administration | 11
Adding Profiles
To add a profile, you need to have View and Add/Edit privileges to the Users component. If you are signed in as the
administrator of the internal OpenDS directory server (for example, admin/admin), you have these privileges. To
create a profile, follow these steps:
1. Select the Users tab. The initial view in this tab is the Users View. The following figure shows an example of this
view, with users already configured:
Along the top of this view is the View Selection Bar, from which you can select to view Users, Profiles, or Roles.
On the left side of this view is the Actions panel (All Users), where you can search for a particular user or sets of
users by selecting or entering criteria in the FILTERS fields. You can also add a user from this panel. On the right
side of the Users view is a table, showing a list of user accounts, including the user names, e-mail addresses, roles,
and whether or not they are logged in. From the table, you can modify or remove user accounts.
2. In the View Selection bar, select to display the Profiles view (and display the Security Profiles table).
The following figure shows this view with several Profiles configured:
3. If the Actions panel does not already display the Name field and Add button (as shown in the figure above), click
ADD PROFILE to display them.
| HPE 3PAR Policy Server: User Administration | 12
4. In the Name field under ADD PROFILE in the Actions panel, type a unique identifier for the profile, using up to
50 characters. You may want to use the names of the components. For example, you might type AuditLog, Policy,
PolicyView, or RemoteSessions, and then click Add.
The Profile Definition window appears, as shown in the following figure:
5. In the Description field, type a brief description of the profile. For example, if you are assigning both the View
and Add/Edit privileges for a component, type the names of the privileges here. They are NOT shown in the
Profiles table, unless you type them here. The Description field is optional.
6. Under Component/Privilege, select the privileges that you want to assign to the profile. For example, if you are
adding a Profile for users who handle Remote Sessions, select End next to Remote Sessions.
Tip: When you select the Add/Edit or End privilege for a component, the View privilege is automatically
selected and dimmed.
7. When ready, click Save to add the new profile. To discard the profile, click Cancel. As long as you clicked Save,
the Security Profiles table displays the new Profile name and description.
8. Repeat Steps 4 through 7 for each profile that you require.
Adding Roles
To add a role, you need to have View and Add/Edit privileges to the Users component. Note that if the option
to manage Roles from the directory server was selected during installation, you are prompted to sign in with the
administrator credentials for your directory server. If you have already signed in during your current login session,
you are not prompted again. If the option to manage Roles from the database (Policy Server HSQL database), you are
not prompted for the directory server credentials when adding, modifying, or deleting Roles.
To add a role, follow these steps:
1.
2.
3.
Select the Users tab and then select
in the View Selection bar. The ROLES view appears.
If the Actions panel does not already display the Name field and Add button, click ADD ROLE to display them.
If prompted, enter a User Name and Password for the directory server in the Directory Server Authentication
pop-up. Once you have successfully provided that information, you can begin adding the information for the Role.
The following figure shows an example of the Roles view, with roles already added:
| HPE 3PAR Policy Server: User Administration | 13
4.
5.
6.
7.
In the Name field, type a unique identifier for the role, using up to 50 characters, and then click Add to display the
Role Definition window. The name you typed appears in the Name field in this page, as shown in the following
figure:
In the Description field, type a brief explanation of the role, using up to 200 characters.
Since the only user available before you add users is admin, you can skip this step. However, once you
have added other users, you can select the check boxes next to the names of the users you want to assign to
this role (left column, under Assigned Users). The figure above shows one user assigned to the role named
PendingRequestMgr.
Under Assigned Profiles, select the check boxes next to the names of the profiles you want to assign to this role.
The profiles you select grant the application privileges to the selected users.
In the example, the profiles selected give the user privileges to View and Add/Edit in the Pending Requests tab, to
View and End Remote Sessions, and to View information in the Policies and Assets tabs.
8.
9.
When ready, click Save to add the role and close the Role Definition window. The System Roles table displays the
new Role.
Repeat steps 4 through 8 for each role that you want to add. If no users were available, you can assign users to the
roles while adding the users.
| HPE 3PAR Policy Server: User Administration | 14
Tips for Assigning Profiles to Roles
Consider the privileges that you want the user who will be assigned this role to have. For example, if the user will
monitor and respond to Pending Requests from the Agents, the user must have View and Add/Edit privileges to
the Pending Requests component. In addition, you may want to assign the role the View privilege to the Policy
component so that the user can check the policy of an asset group before accepting or denying a request. You may
also want to give the role the View privilege to the Audit Log so the user can view messages from the assets.
For non-administrative users, consider creating roles that do not have profiles that allow them to add/edit/remove
items in the Users or the Policy component.
Adding Users
Now that you have added the profiles and roles, you are ready to add the user accounts and assign them the roles that
will give them the privileges the users need to do their jobs. To add user accounts, you need not only the View and
Add/Edit privileges to the Users tab, but also you need the login name and password of a user who is a member of the
group, HPE3PSLdapAdmins, that was created in the directory server you are using with Policy Server. You will need
to enter this login information when adding users.
Important: If you are using Active Directory as the directory server for Policy Server, you MUST configure
Active Directory to use SSL when communicating with Policy Server. Otherwise, not even admin users can
update a user’s password or add, modify, and delete users. These actions are all disabled in the USERS tab.
1.
2.
3.
Select the Users tab or, if you are in the PROFILES or ROLES view, select
The USERS view is displayed.
in the View Selection bar.
If the Actions panel does not already display the Full Name, Username, Password, and Confirm Password fields as
well as the Add button, click ADD USER to display them.
Before you can start adding user information, you need to enter a User Name and Password for the directory
server in the Directory Server Authentication pop-up. Once you have successfully provided that information, you
can begin adding the information for the user.
Note: During a login session with the directory server, you need to provide the administrator credentials
for the directory server only once. If you previously entered these credentials, the Directory Server
Authentication pop-up does not appear.
The following figure shows this part of the panel when expanded:
| HPE 3PAR Policy Server: User Administration | 15
4.
5.
6.
In the Full Name field type the first and last names of the user. You can use up to 50 alphanumeric characters, a
period, and spaces.
In the Usermame field type a unique identifier for the user, using up to 50 alphanumeric characters. Keep in mind
that you cannot change this name once the user has been added.
In the Password and Confirm Password fields, type the initial password for the user. Passwords must be at
least six characters long and can be up to 50 characters long. This field accepts alphanumeric characters, spaces,
and punctuation characters. Although for security reasons, it is strongly recommended, it is not mandatory that
passwords include lowercase, uppercase, and numeric characters as well as punctuation.
The User Definition window displays the Username (dimmed) and Full name you entered. Asterisks (****) in
the Password fields hide the password you entered, as shown in the following figure:
7.
8.
9.
10.
For this user to receive notifications from Policy Server regarding asset groups assigned to the user, type the Email Address for the user. If more than one address is needed, separate the addresses with a comma. Use the email address format, username@company.com.
If desired, type the Phone Number and Fax Number for the user. These fields accept numbers and hyphens.
If the user should be an Administrator of Policy Server and the directory server, select the Is Administrator check
box. When you select this option, the Assigned Roles do not apply to the user because the user has all privileges to
all components of the Policy Server application.
If you did NOT select the Is Administrator check box, then under Assigned Roles, select the roles you want to
assign to this user.
| HPE 3PAR Policy Server: User Administration | 16
11.
12.
When ready, click Save to add the user and close the User Modification window. To close the window without
adding the user, click Cancel.
Repeat steps 3 through 11 for each user that you want to add.
Once you have configured the profiles, roles, and users for Policy Server, you are ready to configure asset groups and
policies.
Configuring SMTP Credentials for an Admin User
For Administrators only, the USERS tab has a fourth view, called SMTP Credentials, that allows administrators to
set the username and password for SMTP Server communications (for example, sending an e-mail notification about
a pending request). Non-admin users cannot see this view.
This view shows these fields:
•
•
Username — the username that Policy Server should use when communicating with the SMTP server.
Password — the password associated with the username
Note that the password is encrypted using the CryptoUtils library before it is stored in the Policy Server database.
Chapter 2
Policy Server: Asset Groups
This chapter explains the concepts behind asset groups in Policy Server. It also explains how to add, edit, and delete
asset groups in the Policy Server application. It is organized as follows:
•
•
•
•
Understanding Asset Groups
Assets Tab
Editing Asset Groups
Deleting Asset Groups
Understanding Asset Groups
The organization of asset groups in the Policy Server database is hierarchical. By default, Policy Server provides the
Global asset group, which serves as the parent for all other asset groups. If desired, you can change the name of this
asset group, but you cannot change its place in the hierarchy. In general, every other asset group is a child, grandchild,
or great-grandchild of the Global group. Depending on how you choose to set up the asset groups, the hierarchy might
have additional lower levels, but never any level higher than Global and never more than 10 levels in all (including
the Global level).
This hierarchy is important because it sets up how assets get their policies— through inheritance. Inheritance and
policies are discussed later in this chapter. For now, you need to know that this is the reason for the hierarchy. Next,
you need to understand the two ways to create asset groups - automatic and manual.
Important:
For best performance, keep the number of asset groups that you create and use to the smallest number
possible.
The asset groups in the Policy Server database have NO relationship to the Asset Groups configured in the
HPE 3PAR Enterprise Server.
As of release 6.1, Build 615257, Policy Server no longer creates asset groups automatically for each serial
number when an Agent Gateway or Policy Agent first registers with Policy Server. However, it does
automatically create asset groups for each model and assigns the assets to these model groups. In addition,
Policy Server no longer allows you to change the Parent asset group of a selected asset group.
Automatic Creation of Asset Groups
Suppose you have an Agent Gateway Agent running on a gateway asset that is monitoring several assets. When
it starts up, the Gateway sends the model and serial number of the gateway asset as well as the model and serial
numbers of each asset the Agent is monitoring (the "managed" assets). When it receives the registration message,
Policy Server creates an asset group for each model of asset. For example, the gateway asset has the model name,
Model_ABC, and its managed assets have two model names, model_123 and model_789. The following asset groups
are created based on this information:
•
•
Model_ABC is created as an immediate child asset group of Global. If additional gateway assets of this model
register with Policy Server, they are added to this asset group.
model_123 and model_789 are created as immediate child asset groups of Global. If additional managed assets of
either of these models register with Policy Server, they are added to the respective asset group. In addition, Policy
Server records that these two models are associated with (managed by) Model_ABC.
| Policy Server: Asset Groups | 18
Manual Creation of Asset Groups
Although Policy Server automatically creates asset groups for models and assigns assets to those groups when Policy
Agents register with it, you may want to create your own asset groups for assets that should have the same policy.
Note that you cannot add existing asset groups to another asset group. You can create child asset groups of Global or
other automatically-created asset groups and then move assets to the new child asset group. If you want to assign the
same policy to different assets, you can create a child asset group (under Global or under an automatically-created
model asset group) and then move the assets that should inherit the policy for that group to the new group. Before
showing you how to create an asset group, let's take a look at the views for assets and groups in the Assets tab.
Assets Tab
The Assets tab allows you to see which assets belong to any given asset group and to drag assets from one group and
drop them in another. In addition, you can edit the information stored in the Policy Server database for an asset. If you
are no longer using a given asset, you can delete it from the Policy Server database.
The Actions panel of this tab allows you to view the hierarchy of asset groups, add Child groups to existing asset
groups, delete assets groups, and search for assets and asset groups using a Keyword.
The Assets tab displays assets in two views, List and Details. Convenient for moving assets from one group to
another, the List view provides an alphabetic listing of all the assets belonging to the asset group selected in the
Actions panel. The List view shows only the Name of the asset. The following figure shows an example of the List
view:
If you mouse over an asset name, a down arrow appears; click the arrow to display a context menu. The following
figure shows an example of this menu:
The context menu shows the name, description, serial number, and model of the asset. By default, the name of an
asset is the Serial Number of the asset. You can give the asset a different name if desired but you cannot change the
| Policy Server: Asset Groups | 19
Model and Serial Number. From this menu you can select Edit to change the name or description of the asset or you
can select Delete to remove the asset from the system. To dismiss the menu, click Close.
Important:
If you delete an asset by accident, Policy Server will report an error if it receives any further communications
from the Policy Agent running on or managing the asset. The Agent must be restarted so that it registers the
asset with Policy Server again. (The Agents send registration messages only on startup.)
Another way to see details for assets is to click the Details View button (shown in the List view figure) to display the
Details view. The Details view shows information for the assets in a table, including name, description, model, serial
number, and asset group. The following figure shows an example of the Details view:
For details about using the Assets tab to manage asset groups, refer to the help for the application. Now that you are
familiar with the tab, you can create a new asset group.
Creating an Asset Group
To create an asset group, follow these steps:
1. Sign in to the Policy Server application as a user with View and Add/Edit privileges to the Assets component.
2. Click the Assets tab.
3. To create a new asset group, in the Actions panel, click Groups to display the Global group.
4. When the Global group appears, it is collapsed and a down arrow icon appears on the right. All asset groups have
these icons.
5. If you want to create the asset group under a different group than Global, expand Global.
6. Click the down arrow icon next to the name of the asset group in which you want to create the new asset group.
Choose the asset group in which you are going to create a child group carefully because you cannot change the
parent asset group or move entire asset groups; you can only move assets. When you click the down arrow, the
context menu for the group appears, which here is shown for the Global asset group:
| Policy Server: Asset Groups | 20
7. To create a new child asset group, click Add Child.
8. When the Group Information screen appears, type a Name (must be unique within the level of groups) for this
asset group.
9. In the Description field, type a short phrase that explains the purpose of the group.
10. Under Notification Information, set up the e-mail message to be sent when Policy Server receives requests for
approval:Y
a) Enter the user names (To Users), role names (To Roles), or e-mail addresses (To Others) of the individuals
who should receive notifications when Policy Server receives requests for approval. When entering more than
one name in any of these fields, type a comma after each name (except for the last name entered).
b) If desired, enter text for From, Subject, and Body fields. For assistance with these properties, refer to the help
for this page.
11. When ready, click Save to add the asset group.
If necessary, expand the Global group to see the group you just created and the automatically-created model groups.
If you created the group to assign the same policy to assets of different models, display the assets in the List view of
the Assets page and drag the appropriate assets to the new asset group folder.
Notifications
As you have seen in creating an asset group, the properties for asset groups include notification information. You
configure notifications so that Policy Server can send a notification to the appropriate Policy Server user(s) when it
receives a request for approval of an action from an Agent in this asset group. If no user is specified for an asset
group, Policy Server sends the notification to the designated Administrator for Policy Server. If you choose different
users, make sure they have the privileges to the Pending Requests component so that they can respond to the
notification.
Editing Asset Groups
You can change the names of asset groups created automatically for models. You might want to do this if, for
example, you want to apply the same policy to two different models. After you change the name of one model group,
you can move assets from the other model group into the newly named group.
You can also create child groups in any existing asset group. You cannot create parent groups except by creating a
new child group in the Global group and then creating child groups in that new child group. Then, you need to move
the assets that you want to have the policies for the groups into the appropriate groups.
Policy Server can support up to nine nested child groups within groups. The following hierarchy is possible:
“Global.parent.child1.child2.” The following figure illustrates how the hierarchy of asset groups is displayed under
All Assets:
| Policy Server: Asset Groups | 21
To edit an asset group in the Assets tab, select the name of the group to display the down arrow. Click the down
arrow to display the context menu, shown below, and then select Modify Group.
When the Group Information screen appears, change the Name, Description, and Notification settings as needed,
and click Save to save your changes.
The names of the individual assets appear in the Pending Requests tab as well as in the Details view of the Assets
tab. If it will help users managing Pending Requests to recognize the assets, you may want to establish a naming
convention and apply it to assets. From the List view for assets in the Assets tab, you can select to edit the names of
assets (not the model or serial number) in the same way as editing details for an asset group:
1. Select the asset.
2. Click the down arrow to display the menu.
3. Select Edit
Deleting Asset Groups
If you select to delete an asset group, all child asset groups of that asset group are removed from the database. If an
Agent running on an asset of the deleted group re-registers (that is, the Agent was restarted) with the Policy Server, a
new asset group is created automatically, using the model information in the registration message.
To remove an asset group:
1. Select the name of the group to display the down arrow.
2. Click the down arrow to display the context menu, shown here:
| Policy Server: Asset Groups | 22
3. Select Remove Group.
Chapter 3
Policies
This chapter defines the term, policy, and explains other policy-related concepts, including permissions, access rights,
and filters. It is organized as follows:
•
•
•
•
•
•
Understanding Policies
Understanding Permissions
Applying Filters
Configuring Policies
Tips for Policies
Base Installation Actions
Understanding Policies
A policy consists of a set of actions and the permissions for performing them. When it first registers with Policy
Server, a Policy Agent sends a complete list of its supported actions. Policy Server is installed with support for all
known actions contained in the released version of the HPE 3PAR Enterprise Server. These actions are referred to as
"Base actions" and are listed and described in Table 1: Actions in a Base Installation.
By default, most of the base actions are defined with a default permission and the access right, “Ask for Approval.”
Until you change the permission and access right in the Policy Server application, each asset under management
asks the Policy Server for approval to perform most of the actions defined in the policy. Policy Server supports new
actions (for example, custom actions that may be customer-specific or asset-specific) by automatically applying a
permission of “Ask for Approval”.
Inheriting a Policy
The hierarchy of asset groups exists to support the inheritance of policies. By default all automatically created asset
groups inherit the policy of the Global asset group. You can change this inheritance by creating your own asset
groups, setting policies different than the Global policy for the new groups, and moving assets to the new groups.
Understanding Permissions
A permission defines how an action is managed through a combination of values for the parameters of the action,
filters, and inheritance. Each action defined in a policy has at least one permission and may have multiple, related
permissions. If you require different policies for asset groups, you can edit the default permission and create
additional permissions for each action.
Some actions take parameters and some do not. For example, the Restart Agent action, which controls whether or
not the asset performs a requested hard restart, has no specific parameters. As another example, the Package action,
which controls whether or not an asset accepts and executes a Software Management package from the HPE 3PAR
Enterprise Server, supports two parameters: the name and the version of a package.
The Global asset group and its policy define the default permissions for all new asset groups. If you modify the
permissions of the Global policy, any asset groups that currently inherit that policy inherit those changes. All new
| Policies | 24
asset groups have the Global policy until you change the policy for the new asset group. Assets inherit the policy of
whatever asset group they belong to.
Important: When adding a permission or action that contains a file name, always use full paths for
permissions and actions. For example, if you set an execute permission for c:\windows\notepad.exe to Never,
any action that launches Notepad using this full path is denied and the Policy Agent reports, "permission
denied." However if you set the action for notepad.exe (no path), the permission c:\windows\notepad.exe is
NOT a match. In addition, the default permission of Ask is applied. If you always use c:\windows\notepad.exe
instead of notepad.exe for both permissions and actions, you do not see this problem.
Access Rights
After creating a permission, you can assign it a different access right than the default (for the most part, Ask for
Approval) and you can create filters for the permission. These filters are optional but all permissions have at least the
default filter, which consists of a single access right. An access right specifies how you want the individual assets to
handle the related action. Three access rights are available:
•
•
Always Allow — The Agent can execute the action without asking for approval or sending the action information
to Policy Server. To see which actions of Always allow rights were performed on an asset, refer to the log file of
the Agent running on the asset.
Ask for Approval — The default access right for any new permission and for most permissions in the Global
asset group when you first start a Policy Server. When you select this access right, the Agent forwards the action
and its parameters to Policy Server for approval, and sends a status message to the HPE 3PAR Enterprise Server.
When it receives the request for approval, Policy Server sends an e-mail to the address specified for the asset
group to which the related asset belongs and then stores the action request in the Pending Requests queue. The
action request remains in the Pending Request page until it is approved or denied, or until it times out. The timeout
period is 60 minutes by default. However, you can change the timeout for each action. If a pending request times
out, the action is denied and needs to be requested again and a message is written to the audit log of the Policy
Server.)
When approved or denied, the action request is removed from the Pending Requests page. A message regarding
the approval or denial is written to the audit log of the Policy Server. Policy Server sends the response (accept
or deny) to the Agent running on the asset. The Agent sends another status message to the Enterprise Server to
identify whether the action request was approved or denied. If the action request was approved, the Agent then
processes the action.
Note: Pending requests for remote sessions are tracked in the Remote Sessions tab as well as in the
Pending Requests tab. If a remote session is denied, the request is removed from the Pending Requests tab
but not from the Remote Sessions tab.
•
Never Allow — The Agent does not execute the action and sends information about requests for an action with
this access right to Policy Server only when Never Allow actions are requested from the Enterprise Server. To
see which asset-initiated actions of Never Allow rights were denied on an asset, refer to the log file of the Agent
running on the asset.
Important: Due to the frequency of requests for the following actions, these actions do NOT support the Ask
for Approval access right nor do they support filters: Set Time, Data Item Values, Alarms, Event, and Email.
If you apply a filter to one of these actions, it does not have any effect.
Inheritance and Permissions
Any permission set in the Global group is inherited by its child asset groups. Within a child group’s policy you can
override a permission set in the parent group as long as that permission is not locked in the parent group’s policy. For
example, assume an Execute action permission defined in the Global policy specifies that an asset can execute any
application without asking for approval. If the child group contains sensitive assets, you can override this permission
| Policies | 25
within the child group’s policy to specify that an asset needs to ask for approval before running any application. This
overridden permission is then inherited by that group’s child groups.
Note: Notification settings for asset groups can also be set for each asset group, or, if not set for a child
group, inherited from the parent asset group. For example, suppose you configure notification settings for the
Global group; any child groups of that Global group use the same notification settings. As with permissions,
you can override notification settings for a child asset group. You can even configure unique notification
settings for each asset group managed by the Policy Server. Unlike permissions, notification settings cannot
be locked.
Applying Filters
Applying filters to permissions provides more control over actions. Filters allow you to:
•
•
•
•
•
Maintain a static list of permissions, each with a default access right.
Restrict an action to certain users at certain times (by using expressions and Time Windows in filters).
Restrict an action to a particular Enterprise Server (expression).
Create a time window (for example, called "Maintenance Window") to allow or ask for approval when users
access the asset during the Maintenance Window, and deny at any other time.
Set up a complex set of allow, ask, deny rules by assigning filters in the order in which you want them applied.
In general, a filter is a set of restrictions for a permission. You can create a filter and assign it to one or more
permissions in the same policy or in different policies. You must have the Add/Edit privilege to the Policy component
of the application to create, edit, delete, or assign filters to permissions.
Each permission has a default filter that cannot be removed. Displayed in the Access Right column of the Policy table,
the default filter is an access right that can be set to Always Allow, Ask for Permission, or Never Allow. A default
filter has no name, expression, or time window. If the permission has multiple filters, the default filter is always the
last one in the list. When the Agent Gateway or Policy Agent evaluates the filters for a permission, if no user-defined
filter in the list is a match, the Agent evaluates the default filter, which always matches.
When creating filters, you must assign the filter a name that is unique in the Policy Server database and an access
right (Always Allow, Ask for Approval, or Never Allow). In addition, if you want to restrict a permission to certain
users at certain times, you can add expressions, which can consist of variables, values, and operators:
•
•
For operators, you can use the equals sign (=) and the AND operator.
For variables, you can specify the userId and the domain name of the Enterprise Server (enterpriseId) from which
the Agent received the action request. Values for variables can contain the asterisk (*) wildcard character to
represent zero or more characters.
Tip:
Grouping and other Boolean operators, such as OR and NOT, are not supported.
In general, expressions are case insensitive. For example, you can enter "and" or "AND" for this Boolean
operator; the results are the same. However, the variable names must be entered as follows: userId and
enterpriseId (capital "I", lowercase all other letters).
When they evaluate expressions, the Agent Gateway and Policy Agents parse and check the syntax. Policy
Server does NOT check expression syntax.
For examples of expressions, refer to the help for the Policy Server application.
To be able to restrict access to a certain period of time, whether once or every week, you define a Time Window for
the filter. You can choose a fixed time period or one of two recurring time periods. The Time Window options follow:
•
(Blank) — This option specifies NO time period. If you previously added a Time Window and need to remove it,
select this option.
| Policies | 26
•
•
•
One Time — This option allows the action for a single time period. This time period can span days, weeks, or
months. When you select this option, you must select a Start Date and Start Time as well as an End Date and End
Time. For the date fields, click the calendar icon and select the date. To set the times, type them, using the format
HH:MM AM or PM. For example, between 10:00 AM on 03/04/2015 and 9:00 AM on 03/06/2015.
Weekly Recurrence — This recurring option allows the action on specified days of the week, during specified
hours. For example, between 5:00 PM and 8:00 PM every Monday and Wednesday or every Tuesday and
Thursday from 4:00 AM to 8:00 AM.
Weekly Range — This recurring option allows the action during a specified range of days of the week. The period
begins at the Start Time on the Start Day of the week. The time period ends at the End Time on the End Day of the
week. For example, between 5:00 PM on Friday and 9:00 AM on Monday.
After you have defined your own filters and assigned them to one or more permissions, the Access Right column
for those permissions shows the default filter. You can view details for the assigned filters from the Filters column.
The filters appear in the order in which the Agent evaluates them, from first to last, with the default filter shown last.
Keep in mind that, when other filters are assigned, they are evaluated in the order in which they appear here, and the
default filter is always evaluated last. For details on how the Agents evaluate filters, refer to the next section, Filter
Evaluation.
If the permission inherited filters from the parent asset group or if another filter was applied directly to this permission
for this asset group, you receive a warning when you try to apply other filters. This warning tells you that you
are going to lose all other applied filters. If only the default filter is shown for the permission, you do not see this
warning. The default filter is always preserved.
If the Access Right field is disabled (dimmed), this permission is locked at a higher level. The name of the parent
asset group where the permission is locked appears in the Inheritance column.
For more information about creating, editing, deleting, and assigning filters, refer to the help for the Policy Server
application.
Filter Evaluation
Filters are always evaluated in the order in which they appear in the Assigned Filters window (which is the order you
assign them), from first to last. There is an implicit OR operator between filters. Evaluation stops when a filter in the
list is matched. A filter match means that the Agent Gateway or Policy Agent was able to match both the expression
and the time attribute of the filter to an incoming user request.
An implicit AND operator exists between the filter’s expression and time window. When an Agent evaluates a filter,
both the associated expression AND the Time Window must match before the filter is considered a match and the
requested action is allowed. That is, a filter is a match if and only if the attributes of the incoming user (userId and
enterpriseId) match the filter’s expression AND the user is requesting the action within the Time Window associated
with the filter.
When a filter has no explicit expression or Time Window, the filter has no restrictions with regard to the user making
the request or the time of the request. A filter with an empty expression matches all users and a filter with an empty
time window matches at all times.
Note: A Time Window is not associated with any particular time zone. When evaluating the filter, the Agent
uses its system clock. For more details, refer to the topic, "Evaluation of filters in different time zones," in the
help for the Policy Server application.
For more information about filter evaluation, refer to the help for the Policy Server application.
Configuring Policies
To configure a policy for an asset group, you must have Add/Edit privileges to the Policy component of the Policy
Server application. The main steps for configuring a policy are:
1. Select the Policies tab.
| Policies | 27
2. In the Actions Panel, click the name of the asset group whose policy you want to edit. The Policies for the group
table updates for the selected asset group.
3. Review the current permissions for each action.
4. As needed, select an action to create a new permission for the action or edit an existing permission.
5. If desired, create new filters or edit existing filters to use with permissions and assign them to the appropriate
permissions.
6. If desired, lock permissions or as needed, reset all permissions to those of the parent asset group.
Refer to the help for details on the steps. After you change a policy, the next time it contacts the Policy Server, the
Agent receives its new or changed policy and starts managing the action requests as defined in the policy.
Setting All Permissions
You can change the access right for all displayed permissions to a specific access right. For example, you temporarily
want to prevent all actions for an asset; you navigate to the Policy page for the asset group (whose name is that of the
asset), and set all permissions to Never Allow. When you want to restore the policy settings to their original settings,
you do so by clearing the Set All Permissions check box.
In addition, the Set All Permissions feature allows you to reset all permissions to those of the parent asset group.
To set all permissions to the same access right, follow these steps:
1. Select the Policies tab.
2. In the Actions Panel, click the name of the asset group whose policy you want to edit. The Policies for the group
table updates for the selected asset group.
3. Below the Policies for the group table, select the check box next to Set All Permissions.
4. When prompted if you want to set all permissions, click Ok.
5. Select the access right to set for all policy permissions: Always Allow, Ask for Approval, or Never Allow. If this
is not the Global policy, you can also click the Reset to Parent's Policy button to set all access rights to those
defined in the parent policy (either Global or a model).
6. Optionally, select the Assign Filters link to display the Assign filters to Permission page:
a) In the Policy Filters table, select the Add check box for each filter you want to assign.
b) Click Save.
7. Optionally, select the Remove Filters link to display the Select Filters to Remove page:
a) In the Policy Filters table, select the Remove check box for each filter you want to remove.
b) Click Remove.
8. At the bottom of the Policy page, click Done.
If you selected an Access Right, that Access Right appears in the Access Right column and cannot be changed. For
example, if you selected Never Allow, the Access Right column displays Never Allow for every permission. In
addition, the Inheritance column displays the name of this asset group.
If you selected Reset to Parent's Policy instead of an Access Right, the name of the parent asset group appears in the
Inheritance column and the Access Right column displays "Reset to Parent." You cannot change this "access right".
You must first restore the original policy settings.
Restoring All Permissions
To restore all permissions to the original settings for the asset group:
Below the Policy table, clear the check box next to Set All Permissions. This step applies whether you set all
permissions to the same access right or reset all permissions to the parent settings.
The table is updated to show the original settings (before you set all permissions to have the same access right or to
reset to the permissions of the parent group).
| Policies | 28
Locking Permissons
You can lock permissions to prevent them from being overwritten in the policy of a child asset group. To change a
permission for a child group that is locked in its parent policy, you must display the policy of the parent group where
that permission is locked. Then, you need to change the permission in the parent group. For example, if a permission
is locked in the Global policy, you need to display the Global policy and change the permission there. You cannot
unlock the permission, go back to the child group policy to make a change, and then lock it at the Global level again.
Locking the permission at the Global level again resets the permission in the child group policy to the Global setting.
Keep in mind that when you change the permission in the parent policy, all child asset groups inherit that change.
You lock permissions from the Policy view for a selected asset group. For each permission that you want to lock,
select the Lock button for the related permissions.
The Access Right settings for permissions that are locked in a parent’s policy are not selectable in the child group's
policy view. In addition, no buttons are available in the Lock column.
Hiding Permissions
By default, all permissions are visible. The permissions panel has a check box labeled Visible, which only users who
have an Administrator account for Policy Server can see and then toggle to set whether the permission should be
visible (checked) or hidden (cleared). Note that Administrators can always see all actions, permissions, and filters,
regardless of the visibility setting for a permission.
The effects of hiding a permission follow:
•
•
•
If an action has a single permission and that permission is hidden from view, the action is also hidden.
Any filters applied to a permission are visible in the Filters tab with the assigned permission, even though the
permission is hidden.
Whether or not a permission is hidden does NOT affect how it and any related filters are applied in the
background. The system applies the permission and any filters to the action, even if the permission is hidden.
Here are some tips about permissions, inheritance, override rules, and visibility in the asset group hierarchy:
•
•
•
•
While permissions are subject to inheritance and override rules in the asset group hierarchy, the visibility setting
for a permission is NOT subject to these rules. For example, the visibility setting for a permission at the child asset
group level cannot override the setting at the parent group level (including the Global setting).
If a different setting from the parent group is desired for the child group, an Administrator must create a new
permission for the child group and set the visibility there.
When a policy is reset to the policy of the parent group, the visibility of permissions does NOT change.
Locking a permission has no effect on the visibility of the permission.
Tips for Policies
This section provides information about actions that will help you avoid problems.
Avoiding Performance Problems
Make sure only actions that absolutely must have Ask for Approval are defined with that access right. Policy Server
already restricts five actions to only the Always Allow and Never Allow access rights. When selecting access rights,
keep in mind that Ask for Approval means that every time the actions are requested, the Agent must wait for a
response from Policy Server. Until authorized users of the Policy Server application accept or deny these actions, the
Agent must queue them. For frequently requested actions, this approval cycle may lead to degradation in the system
performance.
Avoiding Unexpected Actions from Packages
Granting Always Allow to packages could lead to unwanted actions being performed on an asset. For example, if
the Run Script action has a Never permission, and a Run Package action has an Always permission, and a script is
| Policies | 29
included in a package, the Policy Agent sees the Run Package action and executes it automatically (because it has an
Always permission). The Agent and the Policy Server do not “see” that there is a script in the package.
The action of accepting or denying the execution of a package on an asset applies to the entire contents of the
package. If an explicit permission exists for a specific package (name and version), the Agent enforces the permission
on that package as instructed. If an explicit permission does NOT exist for a specific package (name and version), the
Agent examines the contents of the package and processes the package based on the following rules:
•
•
•
If every action in the package, including rollback actions, has an Always Allow permission, the Agent processes
the entire package.
If any action in the package, including rollback actions, has a Never Allow permission, the agent denies the
package and sends a message to that effect to the Enterprise Server.
If the package contains actions with any combination of Always Allow and Ask for Approval permissions (with
a minimum of one Ask for Approval permission), the Ask for Approval permissions are aggregated and sent to
Policy Server as one permission request. A Policy Server user then accepts or denies the entire package.
Therefore, if a package contains actions you want to deny on one or more assets, make sure you explicitly deny those
actions or that package version as part of setting up policies for those assets. If you permit the Agent to accept a
package that contains actions you do not want to run on an asset, those actions are run because they are in the package
and the package was permitted.
Base Installation Actions
The following table lists and describes all actions included and managed in a base installation. Any custom actions
supported by your assets are not included below.
Table 1: Actions in a Base Installation
For this Action
Always Allow permits the Agent to do
this without asking for permission first
Parameters
Alarms
Send alarms to the Enterprise Server. (Custom
alarms started as the result of a Start Custom
Alarm action, configured in a logic schema,
are not affected.) All alarms are included in the
action. You can select only Always Allow or
Never Allow for this action. In addition, filters
do not work for this action.
Alarm Name — set to a value of * by
default. You cannot change this value.
Create a Timer
Allow the Enterprise Server to create a dynamic
timer.
Name of the timer to create.
Data Item Values
Send data item values to the Enterprise Server.
Data Item Name — set to a value of
(Data item values sent as the result of a Write
* by default. You cannot change this
Data Item action, configured in a logic schema,
value.
are not affected.) All data items are included in
the action. You can select only Always Allow or
Never Allow for this action. In addition, filters
do not work for this action.
Disable a Script
Disable a script from running when requested.
Name of the script to disable.
Disable a Timer
Disable a timer when requested.
Name of the timer to disable.
| Policies | 30
For this Action
Always Allow permits the Agent to do
this without asking for permission first
Parameters
E-mails
Send e-mail notifications to the Enterprise
Server Except for the Send E-mail action
configured in a logic schema in Agent Builder,
all e-mail notifications are included in this
action. You can select only Always Allow or
Never Allow for this action. In addition, filters
do not work for this action.
Email to — set to a value of * by
default. You cannot change this value.
Enable a Script
Enable a script for operation when requested.
Name of the script to enable.
Enable a Timer
Enable a timer when requested.
Name of the timer to enable.
Events
Send events to the Enterprise Server. All events
ar e included in the action. You can select only
Always Allow or Never Allow for this action. In
addition, filters do not work for this action.
Event Name — set to a value of * by
default. You cannot change this value.
Execute
Start an application on the asset when requested
(whether an Enterprise Server-based request or
Agent-initiated process).
Name(s) of the application(s) to run.
File Download
Accept files downloaded from the Enterprise
Server.
Fully-qualified path of the file(s) to
download to the asset. The name(s) of
the file(s) and path(s) may be explicit
(for example, c:\error.log or include
wildcards (for example, c:\*.log or c:
\*.*).
File Upload
Upload files to the Enterprise Server when
requested (whether an Enterprise Server -based
request or Agent-initiated process).
Fully-qualified path of the file(s) to
upload to the Enterprise Server. The
path name on the asset can be absolute
or relative (which the Agent interprets
to be the root of the Agent installation).
File names can be explicit (for example,
error.log or include wildcards (for
example, *.log or *.*).
Gateway Provisioning
Add assets to be managed by an Agent Gateway. action: * (default, meaning all three
Modify or delete assets that are already managed actions, Add, Modify, and Delete, are
permitted). If creating a new permission
by an Agent Gateway.
for this action, type the name of the
action (Add, Modify, or Delete).
Modify Ping Update
Rate
Accept a new ping rate (frequency, in seconds,
that the Agent contacts the Enterprise Server)
from the Enterprise Server.
New update ping rate.
Package
Accept a package deployed from the Enterprise
Server. All contents of a package are included
in the permission. (Packages are handled
differently than other permissions. Refer to the
online help for details.)
Name and version number of the
package to execute on the asset.
Register Script
Register a script when requested.
Name of the script to register.
| Policies | 31
For this Action
Always Allow permits the Agent to do
this without asking for permission first
Parameters
Start Remote
Application
Start a remote application session when
requested. A remote application is any type of
remote session that is NOT of type "terminal".
An example of a remote terminal session would
be a Telnet session. An example of a remote
application session would be a desktop remote
session requested from the Asset dashboard of
the HPE 3PAR Enterprise Server application.
Name of the remote application.
Start Remote Terminal Start remote terminal sessions when requested.
An example of a remote terminal session would
be a Telnet session.
Name of the remote terminal interface.
Remove a Timer
Remove a timer when requested.
Name of the timer to remove.
Restart Agent
Restart when requested.
None
Run Script
Run a script when requested (whether an
Enterprise Server-based request or Agentinitiated process).
Name of the script to run
Schedule a Script
Schedule a script to run on the asset when
requested.
Script name – set to a value of * by
default. Applies to all scripts.
Set Data Item Values
Write values to its data items when requested.
You can select only Always Allow or Never
Allow for this action. In addition, filters do not
work for this action.
Name of the data item to which you
want to write a value.
Set Time
Allow the Enterprise Server to set the time on
the Agent.
Time
Stop Remote
Application
sessionid - the number of the session
A remote application is any type of remote
session that is not of type "terminal". This action assigned when it was established
through the Enterprise Server.
is here to enable Policy Server to show that
a remote session was terminated by an entity
outside of Policy Server. For example, a user at
a remote site ended the session from the Remote
Sessions module of the Asset dashboard, or
the network connection went down, ending the
session. Setting the permission has NO effect
on remote sessions being terminated outside of
Policy Server.
Stop Script
Stop a script when requested.
Name of the script to stop
Unregister Script
Un-register a script when requested.
Name of the script to unregister
Unschedule a Script
Un-schedule a script on the asset.
None
| Managing Assets from the Policy Server Application | 32
Chapter 4
Managing Assets from the Policy Server Application
This chapter provides information about using other components of the Policy Server application to manage your
assets. It is organized as follows:
•
•
•
•
Finding and Removing Missing Assets
Monitoring Pending Requests
Monitoring Remote Sessions
Using Redundant Gateways with Policy Server
Finding and Removing Missing Assets
An asset is missing if the Agent running on the asset is not communicating with the Policy Server. This situation
might be due to network connections going down, the Agent being stopped, or the power being disconnected from
the asset. Unlike the HPE 3PAR Enterprise Server, the concept of "Missing Asset" in Policy Server does not take
into consideration that a managed asset might be offline to its managing Agent Gateway. For this reason, a managed
asset that is offline from its managing Gateway does not show as "missing" unless its managing Gateway is not
communicating with Policy Server (for example, the Gateway asset is physically removed from the network or the
Gateway Agent is shut down).
If not connected to the Policy Server, a Policy Agent may be enforcing an out-dated policy. In this situation, the Agent
may be permitting actions that it should be denying (or at least requesting permission to perform), or the Agent may
be denying actions that it should be performing. To determine if an asset is missing from the Policy Server, use the
Missing view in the Assets tab. Any assets shown in this page have missed their last three contacts (pings) with the
Policy Server and are now considered "missing". You can access this page by clicking the Missing icon in the View
selection bar of the Assets tab.
If you see an asset listed in this page that actually needs to be removed from Policy Server control, you can remove it.
Refer to the help for this page for more information.
Monitoring Pending Requests
When under the control of Policy Server, a Policy Agent running on an asset handles a request to perform an action
by first checking its policy. From the policy, it can determine what to do about the action. If the policy says "Always
Allow," the Agent performs the action. If the policy says, "Ask for Approval," the Agent does not perform the
action. Instead, it requests approval from the Policy Server. If the HPE 3PAR Enterprise Server requested the asset to
perform the action, the Agent also sends a message to the Enterprise Server that it is waiting for approval. The Agent
then waits for the response from Policy Server. The requests sent to Policy Server for approval appear in the Pending
Requests tab of the application.
When it receives a request for approval, Policy Server sends an e-mail notification to the user(s) defined for the
asset group to which the asset belongs, and then queues the request for approval. If the action is not accepted within
the timeout period specified in its configuration file, Policy Server removes the action from the Pending Request
queue and posts an entry to its audit log. The Agent receives a “denied request due to timeout” message when it next
contacts Policy Server. If the action is accepted, the Agent performs the action. If the action is denied, the Agent does
| Managing Assets from the Policy Server Application | 33
not perform it and, if the request came from the Enterprise Server, sends a message to the Enterprise Server that the
action was denied by Policy Server.
Note: For a tip on handling permissions for Telnet sessions so that Pending Requests clearly identify the
Telnet session, refer to Tips for Telnet Permissions. For information on how pending request responses are
handled in a redundant gateways environment, refer to Using Redundant Gateways with Policy Server.
The Pending Requests tab shows the requests for the Global asset group by default, which means ALL pending
requests in the system. To view pending requests for a particular asset, you can expand Global in the Actions
panel and select the asset group to which the asset belongs. Alternatively, you can type the name of the asset in the
KEYWORD field to search for it. As long as you have Add/Edit privileges to the Pending Requests component of the
application, you can select to accept or deny individual requests for actions or all requests.
Agents are configured to contact Policy Server to check on pending requests at a different rate than the general
contact message. The next time the Agent contacts Policy Server for pending request approvals, Policy Server notifies
the Agent of all accepted or denied requests. The Agent then performs all accepted actions and, for requests generated
by the HPE 3PAR Enterprise Server, notifies the Enterprise Server of any denied actions.
For complete details about managing pending requests, refer to the help for the Policy Server application.
Monitoring Remote Sessions
You can use the Remote Sessions tab of Policy Server to view the status of all remote sessions for assets managed by
Policy Server. In addition, this component allows you to end remote sessions. To use these features of Policy Server,
you need View and End privileges to the Remote Sessions component. When you select the Remote Sessions tab in
the application, the Remote Sessions view appears.
The Actions panel of the Remote Sessions view allows you to filter the table of remote sessions by Remote Session
Id, Model Number, Serial Number, User Id, and Enterprise (server) Id, as well as view terminated sessions. The
Remote Sessions table displays remote sessions that are currently pending (waiting for approval from Policy Server),
active, inactive, and ended. As needed, you can end a session that is in progress. Policy Server displays sessions for
the number of hours configured in the Policy Server configuration file (PolicyManager.properties). For example, if
the setting is 24 hours, this page displays remote sessions for the previous 24-hour period.
You must be signed in as a user whose role assignments include a profile that allows View and End privileges to the
Remote Sessions component to access this view, use its Actions panel, and end remote sessions. If you cannot see
the Remote Sessions tab in the application, you do not have privileges to the component. Contact your Policy Server
administrator if you require access to the component.
Tips for Telnet Permissions
Policy Server provides two default actions for remote sessions, Start Remote Application and Start Remote Terminal.
When a user requests a Telnet session (Start Remote Terminal action), Policy Server displays the Start Remote
Application request in the Pending Requests tab.
In earlier releases of the HPE 3PAR Enterprise Server, Remote Application and Remote Terminal Session on the
Enterprise Server side were different entities. In the current release, when a request is made for a Telnet session, the
Enterprise Server sends the permission id for Remote Application instead of the permission id for Remote Terminal.
To set up individual permissions for different Remote Applications such as Telnet, follow these steps:
1. After logging in to the Policy Server application, select the Policies tab.
2. Select the Start Remote Application action.
3. Add a permission, using the name ‘Remote Telnet’ (or a similar name).
4. Add a parameter, using the name ‘telnet’.
For more information about managing Remote Sessions in Policy Server, refer to the help for the Policy Server
application
| Managing Assets from the Policy Server Application | 34
Using Redundant Gateways with Policy Server
To help you understand redundant gateways, let's start with non-redundant gateway operations. Normally, in a nonredundant gateway configuration, a given managed asset is associated with one Agent Gateway. The Gateway sends
asset data (data items, alarms, for example) to the HPE 3PAR Enterprise Server on behalf of the managed assets, as
well as receives and executes actions that are sent from the Enterprise Server to the managed assets
In a redundant gateway configuration, a managed asset may be associated with more than one Gateway. The
Gateways with which a managed asset is associated are called redundant gateways. Redundant gateways are logically
connected to the managed asset throughout the entire runtime. However, they do not communicate with each other,
nor are they aware of each other’s existence. In other words, a redundant Gateway has no indication that it is a part of
a redundant gateway configuration. It is configured in exactly the same manner as a regular, non-redundant Gateway.
Although it recognizes the association of a managed asset with multiple Gateways, the Enterprise Server treats the
redundant Gateways equally. None of the Gateways that manage an asset is considered primary, so when an action
is pending for the managed asset, it is delivered by the Gateway that contacts the Enterprise Server first. When
another redundant Gateway contacts the Enterprise Server, even if it happens immediately after contact from the first
Gateway, the pending action is not delivered.
When a redundant Gateway configuration is used, the managed asset must actively publish its data to an associated
Gateway. Moreover, the managed asset is responsible for selecting the Gateway to which to publish the data.
Otherwise, the data is going to be duplicated when it reaches the Enterprise Server.
Communication with Policy Server in a Redundant Gateway Configuration
In a non-redundant Gateway configuration, HPE 3PAR Policy Server delivers policies upon a contact from the asset.
However, unlike messages regarding requested actions, which must be delivered only once, policies must be delivered
to each Gateway that manages a given asset. Otherwise, the policies are not enforced properly. Therefore, as of
v6.1.5, build 615257, Policy Server delivers the policy for a managed asset to all gateways that are managing that
asset.
Important: If more than one Gateway is managing an asset, it is assumed that all managing Gateways are
using the same Policy Server. If not, conflicting policies and unpredictable results are likely to occur.
When it receives a request to execute an action whose access right is “Ask for Approval," a Policy Agent sends
a permission request message to the Policy Server. When a Policy Server user acts on a previously submitted
permission request, the Policy Server delivers a permission response message back to the Agent. Since a permission
response contains an action, it needs to be delivered to the target asset only once. For stateless actions such as
Set Data Item, permission responses are delivered to the redundant Gateway that contacts the Policy Server first.
However, if a permission response for a Software Management (SM) package deployment were not sent to the
redundant gateway that originally sent the request, the package would not be processed properly. Therefore,
"stickiness" has been introduced for permission requests for SM package deployments. For "sticky" permission
requests, the permission response is sent only to the Gateway that sent the permission request.
Association between an Agent Gateway and Managed Assets
Prior to v6.1.5, build 615257, Policy Server was not aware of associations between Gateways and managed assets.
Also, from the Policy Server perspective, there was no distinction between Gateway assets and managed assets. For
Policy Server to keep track of policy deliveries, and also to optimize communications between Policy Server and
Agent Gateway, starting with v6.1.5, build 615257, Policy Server maintains associations between Gateways and
managed assets. As of v6.1.5, build 615257 , Agent Gateway generates the association information and sends it to
the Policy Server. In addition, Gateway updates the association information every time managed assets are added or
removed.
Chapter 5
Policy Server Maintenance
After operations have started, maintenance tasks for Policy Server consist of backing up the database and restoring it
as needed, log file maintenance, and possibly configuration changes that require you to stop and start Policy Server.
It is important that you keep track of the number and size of the audit log files created on disk. The UI setting for
the number of days that audit information is available in the UI controls only what is shown in the UI. You need to
remove unnecessary files and archive those that are not of immediate need but that you want to retain.
Should you need it, a utility is available to retrieve the version number of Policy Server.
This chapter explains these tasks in the following sections:
•
•
•
•
•
•
Starting and Stopping Policy Server
Getting Version Information
Backing Up and Restoring the Database
Monitoring System Activity
Installed Directories and Files
Uninstalling Policy Server
Starting and Stopping Policy Server
Why would you want to stop and start Policy Server? Although it may not be necessary, you may find that after
running Policy Server for a few months, you need to change the external directory server or your IT department
moved the directory server to a new machine. Such changes require changes to the configuration files for Policy
Server and Tomcat. For those changes to take effect, you need to restart Policy Server.
Important: Due to limitations of Tomcat, the directory server must be running during startup and shutdown
of Policy Server. Follow the sequence given below for starting up and shutting down the components to
ensure that the directory server is running.
If you need to change only Policy Server and Tomcat configuration files, you do not need to stop and start the HSQL
database. You can simply stop Policy Server, make the changes to the configuration files, and start Policy Server back
up. For information about the configuration files, refer to Configuration Files.
If however, you need to stop and start all components, the order in which you start and stop them is important. Policy
Server should always be started last and stopped first.
•
Always START the components in the following order:
1. Directory Server
2. HSQL Database
•
3. Policy Server
Always STOP the components in the following order:
1. Policy Server
2. HSQL Database
3. Directory Server
If you installed Policy Server components as services, you can start and stop the services as you would any other
service on the machine. On Windows 7, for example, go to Start menu > Control Panel > Administrative Tools >
| Policy Server Maintenance | 36
Services, and locate the services (Policy Server, Policy Server Database, OpenDS, if all three are running on the same
machine). Then use the Start service or Stop service link to perform the desired operation.
Important: Due to limitations of Tomcat, the directory server must be running during startup and shutdown
of Policy Server. If you follow the rule that you always start the directory server first and stop the directory
server last, you'll be all set.
Getting Version Information
After installation, you can see the version number in the About Policy Server popup window of the Policy Server
application (available from the
menu). You can also display it through a command line utility.
Open a Command Prompt (Windows) and navigate to the following directory of the Policy Server installation:
/HPE3PAR/HPE3PARpolicyserver/bin or c:\<<PolicyServer_InstallationL>\bin). Run the command for the
operating system:
• Windows — serverVersion.cmd
Note: The version scripts are available on the machine where you installed Policy Server. If you installed
the database and/or the OpenDS directory server on separate machines, the scripts are not available on those
machines.
Backing Up and Restoring the Database
Policy Server and the HSQL database can run on different machines. The backup and restore scripts provided with
Policy Server perform all backup and restore operations you need for the HSQL database. Administrators can perform
interactive backups as well as scheduled backups using Windows scheduled tasks or UNIX cron.
Important: The backup/restore options available in releases prior to v6.1.5 are NO LONGER SUPPORTED.
Backing Up the Database
To make it easy to back up your database, use the backup_database utility, which is located in the directory,
<your_HPE3PS_install_dir>/hsqldb/bin. This utility creates a backup of the HSQL database in the backup repository
<your_HPE3PS_install_dir>/hsqldb/backups/<timestamp>.tar.gz.
The number of backups in the repository is limited to 30 by default. The number of backups to retain can be
overridden by specifying the desired number (an Integer) on the command line. For example, to retain 10 backups,
enter the command as follows:
backup_database 10
Here is an example of the output of this utility:
$ /opt/HPE3PAR/aps/hsqldb/bin/backup_database 10
Pruning backups to preserve retained backup count of 10:
apm-20150421T174859.tar.gz
Backing up to '/opt/aps/HPE3PS/hsqldb/backups'
Backup completed
| Policy Server Maintenance | 37
If the database is shut down when you attempt to perform a backup, an error message appears and the backup is NOT
created. Make sure the database is running before a backup operation is run.
Note: The backup utility does not perform syntax checking on the command. If, for example, you enter
backup_database 4.5 , the utility is expecting an integer for the backup count but does not check that what you
entered was an integer. Instead, it takes the first digit (4 in this case) for the number of backups to retain.
This utility is intended to be invoked from the system task scheduler (cron on UNIX or Scheduled Tasks on
Windows), but it can be invoked manually as well. In either case, the utility must be invoked on the system that runs
the HSQL database server.
If you run scheduled backups, be aware that when the maximum number of backups is reached, the oldest backup
is removed. This feature means that you never have to manually remove old backup files. If you perform a backup
manually and specify a smaller number of backups to keep than was previously set, the oldest backups are removed to
satisfy the smaller number of backups to keep. Again, you do not have to remove them manually.
HSQLDB creates backups that contain enough data to restore the database to a previous state. The backup file
contains the following files:
•
•
•
apm.properties
apm.script
apm.data
The log and backup files may not (and do not need to) be in sync with these files.
Restoring the Database
To make it easy to restore the database to a previously known state, the Policy Server installation includes a restore
utility called restore_database (restore_database.bat on Windows). This utility restores the HSQL database from a
single backup archive (a tar.gz file) that was previously created by the backup_database utility.
Important: Before performing a restore operation, you must first stop the HPE 3PAR Policy Server service
and then stop the Policy Server Database service.
Once you've stopped the services, you can run the restore utility. Invoking the utility with no parameters selects the
most recent available backup by default. Alternatively, to see a list of all the available backups, run the utility with
the list command line option. You must type this option using all lowercase letters. The backups are listed in reverse
chronological order (that is, the newest backup is at the top of the list). For example:
$ /opt/HPE3PAR/aps/hsqldb/bin/restore_database list
Available backups in /opt/HPE3PAR/aps/hsqldb/backups:
apm-20150422T112110.tar.gz
apm-20150422T112005.tar.gz
apm-20150422T110830.tar.gz
apm-20150422T110825.tar.gz
apm-20150422T110654.tar.gz
apm-20150422T110636.tar.gz
apm-20150421T174935.tar.gz
apm-20150421T174930.tar.gz
apm-20150421T174910.tar.gz
apm-20150421T174902.tar.gz
Once you have the list, you can specify a particular backup archive on the command line. After entering the
command, you must confirm the request before the utility actually restores the database. If the database is still
running, the utility presents an error message. You need to stop the database before you can restore.
Here is an example of the restore utility’s output:
$ hsqldb/bin/restore_database
The HPE 3PAR Policy Server database will be restored
from the "apm-20150422T112110.tar.gz" backup.
The database server must be shut down before proceeding.
| Policy Server Maintenance | 38
Shut down the database server and press enter to continue. <-- (This message
repeats until the database server is stopped)
2015-05-22T11:21:10 0* 700 88 - apm.properties
2015-05-22T11:21:10 0* 700 23342 - apm.script
2015-05-21T17:49:35 0* 700 32768 - apm.data
After a restore operation, the backup archive remains intact. If a restore fails for any reason, perform the operation
again. Otherwise, the database remains in an indeterminate state.
Tips
•
Monitor the disk space used by the backup repository and adjust the number of backups you keep (or available
disk space) as your needs evolve. If the disk is full, you will see a response and error message similar to the
following:
C:\HPE 3PAR\PolicyServer6Test\hsqldb\bin>backup_database.bat 20
Backing up to ' C:\HPE 3PAR\PolicyServer6Test\hsqldb\backups'
SEVERE SQL Error at
'C:\HPE 3PAR\PolicyServer6Test\hsqldb\ddl\full\backup_database.sql' line 2:
"BACKUP DATABASE TO ' C:\HPE 3PAR\PolicyServer6Test\hsqldb\backups/' BLOCKING"
file input/output error: java.io.IOException: There is not enough space on the
disk in statement [BACKUP DATABASE TO
' C:\HPE 3PAR\PolicyServer6Test\hsqldb\backups/' BLOCKING]
org.hsqldb.cmdline.SqlTool$SqlToolException
•
If you see the following message when trying to perform a backup, it means that the database server is not
running:
$ /opt/HPE3PAR/aps/hsqldb/bin/backup_database 10
Failed to get a connection to 'jdbc:hsqldb:hsql://localhost:9002/apm' as user
"ADMIN".
Cause: java.net.ConnectException: Connection refused: connect
Monitoring System Activity
The Policy Server application provides the Audit Log tab to help you monitor the activity in the system. The Audit
Log tab shows all activity generated by Policy Server as well as activity reported in XML messages from the Agents.
You can view all audit log entries, entries in a selected category, or entries for a selected asset group. You can also
export a CSV of system activity.
When you make configuration changes, Policy Server logs the exact change in an audit message. That is, the audit
message shows the previous value and the new value entered. Policy Server also logs unsuccessful login attempts.
You can change the number of days that Policy Server keeps audit log files available in the user interface. This setting
does NOT cause Policy Server to delete the files from the machine; this file management is up to you. Note that you
cannot use a fractional number of days for this setting; the UI accepts only integers from 0 to 9.
The Audit Log tab is not editable. The only privilege for this component is View. If you do not have this privilege, the
tab is not visible.
An Audit Log entry generated by Policy Server includes the name of the Policy Server user, the time the user
performed the audited activity, and a detailed description of the action (Message). For details about this page, refer to
the help. The following figure shows an example of the Audit Log tab with all logs displayed:
| Policy Server Maintenance | 39
In general, the Audit Log table shows the following information:
•
•
•
•
•
Date/Time — The date and time that the action was generated or initiated.
Category — The category represents a type of activity, which can be User Access (logins, logouts), Asset
Communication (messages from Agents or sent to Agents), Configuration (Assets tab), Remote Access (Remote
Sessions tab), or Administration (Users tab - create, modify, and delete profiles, roles, and users).
Message — A detailed description of the activity.
Group — If applicable, the name of the Policy Server asset group related to the entry.
User — The name of the user associated with the activity that was audited.
For details, refer to the help for the Policy Server application.
Audit Log Entries
Audit log entries are stored in a log file on the computer running Policy Server; by default, under the
PolicyServer/audit directory. Files are created daily, and all audit log messages generated for each day (from
12:00 to 23:59) are saved to the file. By default, the daily files are created using the following syntax:
APM_Audit_<yyyy>_<mm>_<dd>.txt, where yyyy is the current four-digit year, mm is the current month, and dd is
the current day.
Important: There are no bounds on how large these files can grow, so make sure to keep track of disk space
used and archive the files as needed. Although you can specify how long to retain audit logs, the setting
applies to the visibility of the audit log information in the HPE3PS user interface only. It is expected that
system administrators will manage the files.
You can set how long to retain audit logs and the categories you want to log from the Actions panel of the Audit Log
tab in the Policy Server application, as follows:
1. Log in to the Policy Server application as a user with the View privilege for the Audit Log tab.
2. Click the Audit Log tab, and in the Actions panel, expand CONFIGURE to display the options:
| Policy Server Maintenance | 40
As you can see in this example, the default number of days to keep audit log files available in the UI is five (5)
days. Note that you cannot set this value lower than 5. In addition, you must use an Integer to specify the number.
The system returns an error if you enter anything other than an integer between 0 and 9.
Important: This setting does NOT manage the existence of the files; it is expected that you will manage
the files, deleting any that are not needed and archiving any you want to retain.
3. In the Delete After field, select the current entry and type the number of days (5 or greater than 5 and Integer
only).
4. Under Categories Enabled, select or clear the check boxes for the categories for which you want to see audit
log entries. (Note that "Device Communication" is the same category as "Asset Communication" and "Apm
Administration" is the same category as "Administration".)
5. Click Save to put your changes into effect.
Audited Operations
Policy Server generates audit log entries for the following activities performed by a Policy Server user:
•
•
•
•
•
•
•
•
•
Log in to or out of the application.
Accept or deny a pending request for an action.
Modify a policy.
Create, modify, or delete a permission for a policy.
Create, modify, delete, or assign a filter to a permission.
End a remote session.
Modify the configuration of an asset group.
Modify the details of an asset.
Create, modify, or delete profiles, roles, and users.
Policy Server generates audit log entries for the following activities that are not initiated by a Policy Server user but
result from Agent communication with Policy Server:
•
•
•
•
•
•
•
•
•
•
An action pending approval times out before it is accepted or denied.
Agent registers with Policy Server
Agent forwards a message or command received from the HPE 3PAR Enterprise Server; for example, messages
about operations that were successful, failed, and denied.
Agent sends a request to perform an action that has an access right of “Ask for Approval”.
After receiving approval for an action, Agent performs the action.
Agent performs an action that has an access right of “Always Allow”. The message sent to the audit log includes
the name of the user who requested the action, the action that was performed, and the success or failure of
executing the action.
Agent denies an action that has an access right of “Never Allow”. The message sent to the audit log includes the
name of the user who attempted to perform the action, information about the action that was rejected (specific to
the type of action), and the permission that caused the action to be rejected.
Agent starts or stops a remote session that was requested by a user through the Enterprise Server.
Agent ends a remote session at the request of a Policy Server user.
Agent evaluates a permission that has filters attached. When one or more filters are attached to a permission and
a filter matches, the audit log displays a message that shows the asset name, action name, permission name, filter
name, and the fact that there was a match. When none of the filters match and the default filter (the default access
right) is applied, the audit log displays the asset name, action name, permission name, and then "default filter."
If filter evaluation failed because the filter expression used unknown variables, the audit log reports, "Unknown
symbol in filter expression for asset <name >, action <name >. Details: permission <permission name >, filter
<filter name >, symbol=<name >."
If the filter expression has bad syntax, the audit log reports, "Invalid filter expression for asset <name >, action
<name >. Details: permission <permission name >, filter <filter name >."
| Policy Server Maintenance | 41
Audit Log Persistence for Policy Agents
The Agent Gateway and Policy Agents queue all Policy Server-related auditing messages in their audit logs until
they send them to Policy Server for processing. If the Policy Server is offline, the Agents persist the messages until
they can communicate them to the Policy Server. If an Agent cannot communicate the messages to the Policy Server
before the Agent’s audit log has reached its maximum size, all new audit log entries are discarded.
Sending Policy-related Messages to a Syslog Server
To send audit messages about activities on the Policy Server to a Syslog Server by configuring either Policy Server or
the Policy Agents to send messages to a Syslog Server. This section explains both configurations.
Configuring Policy Server to Send Messages to a Syslog Server
Configuring Policy Server to send messages to a Syslog Server involves changing two files:
•
•
In the PolicyManager.properties file set the property com.axeda.apm.enable_audit_logging under the section Audit
Archive Settings to true .
From the sample log4j.properties .file, copy the Root logger setting, log4j.rootLogger=INFO, hpe3pslog, SYSLOG to
the log4j.properties.file in the config directory of your Policy Server installation. In addition, add the following
configuration from the log4j.properties sample file to the log4j.properties.file in the config directory of your
Policy Server installation:
log4j.appender.SYSLOG = org.apache.log4j.net.SyslogAppender
log4j.appender.SYSLOG.syslogHost = 127.0.0.1
log4j.appender.SYSLOG.layout = org.apache.log4j.PatternLayout
log4j.appender.SYSLOG.layout.ConversionPattern = %d [%t] %-5p %c- %m%n
log4j.appender.SYSLOG.Facility = LOCAL0
When the value of the property com.axeda.apm.enable_audit_logging is true, Policy Server logs on to the Syslog Server
specified in the log4j.properties file.
Configuring Policy Agents to Send Messages to a Syslog Server
To configure Policy Agents to send messages to a Syslog Server, use Agent Builder, specifically the HPE 3PAR
Policy Server Settings dialog box. Note that these messages are NOT the same as those sent from Policy Server.
Rather, the Agent collects the audit messages generated by its APMProxy component for delivery to the configured
SysLog Server. Refer to the help for Agent Builder for details.
Installed Directories and Files
If you install all of the components for Policy Server on the same machine, you'll find the subdirectories and files for
the components all under the root Policy Server directory (C:\Program Files (x86)\HPE 3PAR\PolicyServer or /root/
HPE3PAR/PolicyServer). The following table lists the main directories and their content.
Table 2: Installed Directories and Files
Director
y
audit
Contents
All audit log files are saved to this folder by default. If an installation
is successful, this folder is empty immediately after installation.
The log file for installation is in the root PolicyServer directory
(HPE3PARPolicyServer_Install.log).
| Policy Server Maintenance | 42
Directory
Contents
bin
The scripts for migration HPE3PS roles to LDAP and the scripts for
determining the version of Policy Server (serverVersion.cmd, serverVersion.sh,
and server-version.jar).
hsqldb
HSQL database installation, with the following subdirectories:
•
•
•
•
/apm — Contains the backup subdirectory for storing the backup archives as
well as the files for the Policy Server database (apm.data, apm.properties,
apm.script, and apm.log).
/bin — Contains the backup and restore utilities. Also contains database
scripts that create and drop the tables in the database and that start the
database and the database manager. Also includes runUtil.bat / runUtil.sh
and sqltool.rc.. Note: The database startup files are inside the Tomcat
directory. Go to the Tomcat7/bin directory if you need to start the database
manually.
/ddl — Contains two subdirectories, /full and /migration. /fullcontains all
the SQL scripts called by the create_database script. /migration contains
all the scripts you need to migrate an existing HypersonicSQL database to
the new version.
/lib — Contains hsqldb.jar, functions, and sqltool.jar.
jre
If you chose the VM version of the installer, you'll see this directory, which
contains the supported version of the JRE (Java Runtime Environment). The
installation program updated your system class path to point to this directory.
OpenDS-1.0.0
If you chose to install the internal Directory Server, the installer automatically
installs, configures, and starts the OpenDS directory server. If you deselected
the internal Directory Server option, you will not see this directory. Note that,
if you chose to install all the components as a service, the OpenDS service is
installed as an automatic service, meaning that whenever you stop and start the
machine where it is running, OpenDS stops and starts automatically. You can
add all the users you require through the Users component of the Policy Server
application.
Tomcat7
Apache Tomcat7 application subdirectories:
•
•
•
/aps — all the Policy Server subdirectories and files that you may need to
access (see the next several rows in this table).
/bin — Contains the scripts for starting Policy Server and the HSQL
database and related services manually: StartHPE3PSPS.bat,
StartHSQLDB.bat, hsqldbsvc.bat, hpe3pssvc.bat, and tomcatsvc.bat scripts.
/hsqldb — all the subdirectories and files for running HSQLDB inside
Tomcat
Tomcat7/aps/common/classes/
PolicyManager.properties, log4j.properties, and startup.xml.
Tomcat7/aps/conf/
Configuration files: logging.properties, server.xml, web.xml
Tomcat7/aps/lib/
Tomcat7 JAR files.
Tomcat7/aps/logs/
Directory for storing log files for Policy Server operations.
Tomcat7/aps/webapps/
Subdirectories and files for the Policy Server Web-based application
Uninstall and Uninstall/resource
All the files needed to uninstall Policy Server, the database, and Tomcat7.
| Policy Server Maintenance | 43
Uninstalling Policy Server
Before uninstalling Policy Server, notify users of the assets running Agent Gateway or Policy Agents that they may
see error messages about the Agents not being able to communicate with Policy Server. If you are moving Policy
Server to a different computer with a different IP address, remember to update the Agent with the new IP address
for Policy Server. You can perform this task using the Agent Deployment Utility or the Agent Builder. From the
Deployment Utility, you can deploy the change directly to a device. If a large number of devices need the update, use
Agent Builder to change the Agent project and then use the software management package to download the revised
XML files to the assets and restart the Agents.
If you need to uninstall Policy Server, you first need to stop the components (in a particular order) before running the
program that removes the installation. Then follow the rest of the steps.
Note: To run the un-installer in silent mode, refer to Appendix C Using the Intaller in Silent Mode in the
HPE 3PAR Policy Server Installation Guide.
1. If all components are running as services, stop the services in the following order:
a) Policy Server
b) HSQL Database
c) Directory server (OpenDS, LDAP, or Active Directory)
2. Navigate to the Uninstall subdirectory of your Policy Server installation. For example, c:\Program Files
(x86)\HPE 3PAR\PolicyServer\Uninstall.
3. Run the program, Uninstall_HPE3PARPolicyServer, and select the components to remove.
4. When it finishes, the program prompts whether to restart the machine now or later. You must restart the machine
to ensure all the changes take effect.
5. After the machine has restarted, check the installation directory. The program cannot remove files that are new or
changed since the version in the installation package. For example, the lock files that OpenDS sets up when it runs
remain after running the program and restarting the computer.
6. Delete the PolicyServer installation directory to complete the removal of Policy Server and its components.
If you want to re-install, run the installer for your platform. As needed, refer to the procedure appropriate to your
needs in the HPE 3PAR Policy Server Installation Guide.
| Configuration Files | 44
Chapter 6
Configuration Files
After running Policy Server for a period of time, you may want to switch to using SSL or change to a different
directory server. You may also want to modify the default values of certain settings that are not configurable during
installation. This chapter explains these types of changes and what you need to do in the configuration files for Policy
Server (and Tomcat) when making the changes.
The procedures in this chapter apply to Windows installations.
Note: The Policy Server configuration file, log4j.properties, contains diagnostic settings that you
may want to modify if troubleshooting server errors. This file is located in the same directory as
Change the configuration settings only if you have experience with database and server administration and
with database debugging.
This chapter is organized as follows:
•
•
•
•
•
•
Changes Requiring Edits of Configuration Files
Editing the OpenDS Configuration File
Editing the Policy Server Configuration File
Editing the Tomcat server.xml File
Changing the Directory Server Password
HSQL Database Configuration File
Changes Requiring Edits of Configuration Files
Why would you want to edit the Policy Server configuration files? After running Policy Server for a while, you may
want to change how long remote sessions are displayed in the Remote Sessions table or the frequency of automatic
database backups. Alternatively, you may be seeing too many audit messages from the Agents for SetDataItem
actions and you want to filter out audit messages for certain data items. To make these types of changes, edit the
configuration file for Policy Server, called PolicyManager.properties.
Suppose your IT department moves - or completely changes - your e-mail server or external directory server. Such
changes mean that you need to change settings in the configuration files for Policy Server and for Tomcat. If you
previously managed roles from the Policy Server HSQL database and want to manage roles from that directory server,
you need to change a property setting in PolicyManager.properties
If you move the Policy Server machine, you need to edit the Policy Server configuration file. Moving the Policy
Server machine may also require that you reconfigure the Policy Server IP address and port for the Policy Agents
running on assets managed by Policy Server. You can perform this second task using Agent Builder or Agent
Deployment Utility.
If you have been using the Policy Server in development mode without SSL and are now going to use it in production
mode, HPE strongly recommends that you use SSL. To use SSL, you need to create the hostname.jks file for the
machine. The hostname.jks file contains the certificate and private key for the machine. This change requires changes
to the server.xml configuration file for Tomcat. This chapter does NOT explain all the changes needed for Tomcat.
For that information, refer to the Tomcat document, SSL HOWTO, at http://tomcat.apache.org/tomcat-7.0-doc/sslhowto.html. This chapter does explain how to enable or disable ciphers by editing Tomcat’s server.xml file.
If you need to change the port used for communications between Policy Server and the OpenDS directory server, you
must edit three configuration files – PolicyManager.properties (PolicyServer), config.ldif (OpenDS) and server.xml
| Configuration Files | 45
(Tomcat). For details, refer to the sections for these configuration files:Editing the OpenDS Configuration File,
Editing the Policy Server Configuration File, and Editing the Tomcat server.xml File.
If you change the e-mail server for notifications, you need to change properties in this file. If you are using the
hostname substitution variable (the <$BURL> tag) in the template for e-mail messages, you may also need to change
properties in this file when the information for the Policy Server host changes.
If you want to send audit log messages from Policy Server to a Syslog Server, you need to set a property for audit log
configuration.
In general, the configuration files are comprised of name-value pairs (for example server.database=HPE3PS , where
server.database is the name and HPE3PS is the value). Do NOT change the names. If you want to change the values,
make sure the values you apply are supported. In addition, make sure you use the same case, as the configuration files
are case-sensitive.
Note: You can change some user information stored in an External Directory Server from the Users tab of
the Policy Server application. When you attempt to make changes, you must log in with an authorized user
name and password for the directory server. If you delete a user using the Users tab, it is also deleted from the
External Directory Server when the HPE3PS database and directory server database are synchronized.
The rest of this chapter explains how to find the configuration files for Policy Server and Tomcat and provides tables
that list and describe the properties they contain.
Editing the OpenDS Configuration File
During installation, the appropriate configuration files for OpenDS, Policy Server, and Tomcat are set up to use the
internal OpenDS directory server. If you specified a port other than the default port (389), the port number you
entered during installation is set in the three configuration files. Note that Policy Server does not work if the port
number for OpenDS in each of these configuration files is different.
If you later decide to change any directory server information (including the port number of the internal OpenDS
directory server), make sure you change all the configuration files: PolicyManager.properties (PolicyServer),
config.ldif (OpenDS) and server.xml (Tomcat). For details for the Policy Server and Tomcat configuration files, refer
to Editing the Policy Server Configuration File and Editing the Tomcat server.xml File. This section explains how to
edit the OpenDS config.ldif file.
1. Shut down the three services in the following order:
a) Policy Server
b) HSQL Database
c) OpenDS
2. Navigate to the OpenDS directory in your Policy Server installation directory, <PolicyServer_install>/
OpenDS-1.0.0/config.
3. Using a text editor, open the file, config.ldif.
4. Search for the following entry:
ds-cfg-listen-port: <port_number>
where <port_number> is the current listent port used by OpenDS.
5. Change this listen port number to the port number you want to use.
6. Save and close the file. If you have other configuration changes you want to make, do so before starting the
services. If not, continue to the next step.
7. Start the OpenDS service first. The directory server must be running before you start Policy Server.
8. Start the other two services. Although not required, the following order of starting the services is considered best
practice:
a) Start the HSQL database service (HPE 3PAR Policy Server Database).
| Configuration Files | 46
b) Start the Policy Server service (HPE 3PAR Policy Server).
Editing the Policy Server Configuration File
The configuration file for Policy Server is called PolicyManager.properties . This file contains all Policy Serverspecific settings initially configured based on your entries during installation. You can find this file in the
Tomcat7\aps\common\classes subdirectory of the Policy Server installation directory. For Windows, the complete
path for this configuration file is
c:\Program Files (x86)\HPE 3PAR\PolicyServer\Tomcat7\aps\common\classes\PolicyManager.properties
To change the configuration of Policy Server, you need to stop the Policy Server service. Then you can edit the
PolicyManager.properties file manually in your favorite text editor. For example, you can edit this file in Notepad
++. For a complete list and explanations of the properties in this file, refer to the section that follows this procedure,
Policy Server Properties.
1. As long as you have stopped the Policy Server service, navigate to the subdirectory, Tomcat7\aps\common
\classes, of the Policy Serverinstallation.
2. Open the PolicyManager.properties file in a text editor.
3. For the changes described in the section, Changes Requiring Edits of Configuration Files, change the following
properties for Policy Server, and then continue to Step 5:
a) Frequency of Automatic Backups — The default number of hours between automatic backups is 3 hours. To
change this value, search for the property, com.axeda.apm.checkpoint_frequency, and type a new value.
b) Period of Time that Remote Sessions are displayed — The default number of hours that a remote session
is displayed in the Remote Sessions tab is 5 hours. To change this value, search for the property,
com.axeda.apm.remote.started.before. The time is relative to the time zone of the computer where HPE3PS is
running.
c) Filtering Audit Messages for Data Items — The Agents send audit messages to Policy Server for every
Enterprise Server action (SOAP message) that they process. To tell Policy Server to ignore the Agent audit
messages sent after they process SetDataItem actions for certain data items, enter the names of those data items
in a comma-separated list as the value of the property, com.axeda.apm.audit.filtering.data-items.
d) E-mail Server changes — To change the e-mail server, search for the property,
com.axeda.apm.notification.email.mail_server , and type the new address for the e-mail server. You may also want
to change the protocol to SMTPS or TLS (com.axeda.apm.notification.email.mail_server.proto, which requires you to
change the port number as well (com.axeda.apm.notification.email.mail_server.port).
e) E-mail notification <$BURL> changes — To change settings for the hostname substitution variable, you need to
change one or more of the following properties:
• com.axeda.apm.hostname
• com.axeda.apm.port
• com.axeda.apm.useSsl
• com.axeda.apm.sslPort
f) Audit messages sent to SysLog Server — To enable Policy Server to send messages to a SysLog Server, you
need to set the property, com.axeda.apm.enable_audit_logging, to true. You also need to make changes to the
installed log4j.properties file as explained in Configuring Policy Server to Send Messages to a Syslog Server.
g) Role Management change — To switch from managing roles in the Policy Server HSQL database to managing
roles in the directory server, search for the property, com.axeda.apm.directory-server.manageRoles, and change the
value from false to true. Then follow the steps in the HPE 3PAR Policy Server Installation Guide, Chapter 4,
| Configuration Files | 47
the section, ”Import Roles from Policy Server Database to Directory Server”. To switch from managing roles
in the directory server to managing roles in the database, change the value of the property from true to false.
Note: When this property is set to true, the synchronization process performs role synchronization.
When this property is set to false, the synchronization process ignores roles.
h) Directory Server changes — To change the port number for the directory server, search for the property,
com.axeda.apm.directory-server.port and change the port number. To change other directory server settings, search
for com.axeda.apm.user.CustomJNDIRealm. Then specify values appropriate to your directory server for this
property and the other directory server properties that follow it. The following example shows the settings for
the internal OpenDS directory server:
<RealmclassName=" com.axeda.apm.user.CustomJNDIRealm"
connectionName="ou=admin"
connectionPassword="admin"
connectionURL="ldap://localhost:389"
userPattern="uid={0},ou=People,dc=hpe,dc=com"
userBase="ou=People,dc=hpe,dc=com"
roleBase="ou=Groups,dc=hpe,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0})"
userSubtree="true"
roleSubtree="true"
/>
Note: If you change any directory server information (including just the port for the internal OpenDS
directory server), you need to change not only this file but also the Policy Server configuration file
(PolicyManager.properties) and the OpenDS configuration file (config.ldif). See also Editing the
OpenDS Configuration File and Editing the Tomcat server.xml File.
i) Directory Server changes — Make sure that you also check the userStore property. If you selected either the
internal or external OpenDS directory server during installation, this property has the following value:
com.axeda.apm.userStore.name=OPEN_LDAP
If you change from the internal OpenDS directory server to an external Open LDAP directory server, this
value stays the same. If you change to an external LDAP directory server during installation, change the value
of this property to SUN_ONE_LDAP . If you change to an external Active Directory directory server, change
the value of this property to ACTIVE_DIRECTORY.
4. If desired, review the settings of the other properties in the file. Other than the properties described here, leave the
default settings.
5. Save and close the file.
6. Changes to this file require you to restart Policy Server. However, you may need to take additional steps before
restarting Policy Server. It depends on what you changed:
•
•
If you changed the directory server configuration, you must also edit the Tomcat server.xml file. Complete the
steps in the next section (Editing the Tomcat server.xml File) before restarting Policy Server.
If you decided to switch to using SSL, then before restarting Policy Server, refer to the Tomcat document,
SSL-HOW TO , at http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html.
If you do not need to edit the server.xml file or configure SSL, restart Policy Server.
Policy Server Properties
The following table lists and describes all of the properties in the PolicyManager.properties file.
| Configuration Files | 48
Table 3: Properties in PolicyManager.properties
Description
Supported Values
com.axeda.apm.
startup.name
Name of your HPE 3PAR Policy Server. This
string appears in the server console window
only.
Any valid text string, up to 250
characters. For example, HPE 3PAR
Policy Server .
com.axeda.apm.
startup.version
Release and build number for this HPE 3PAR
Policy Server. For example, 6.8.2 Build 91404
(2014/06/05 12:10:36)
Do NOT Change. Reference this
number when contacting Technical
Support.
Name
Server Information
JDBC Settings - settings for Policy Server to communicate with the HSQL database
com.axeda.apm.
jdbc.HostURL
Address that HPE 3PAR Policy Server uses for
the HSQL database
The installation program sets this
path, based on where you choose to
install Policy Server. For example, the
default installation path on Windows
is C:\Program Files (x86)\HPE 3PAR
\PolicyServer. The value here always
uses the forward slashes, as in the
following example for a Windows
installation:
jdbc:hsqldb:hsql: //localhost:9001/apm
The default user name is ADMIN .
What appears here should be the name
you entered during installation. The
name must be all uppercase.
com.axeda.apm. jdbc.user
User name for Policy Server to use internally
when accessing the HSQL database.
com.axeda.apm. jdbc.
password
Password for Policy Server to use with the
JDBC user name for accessing the HSQL
database.
The default password is admin . What
appears here should be the password
you entered during installation. It is
NOT encrypted.
com.axeda.apm. jdbc.
initial_pool_size
The initial number of database connections to
maintain in memory.
Default is 5 (connections). Supports
up to the maximum number of
database connections, which is set by
the property, com.axeda.apm.jdbc.
max_pool_size ).
com.axeda.apm. jdbc.
max_pool_size
The maximum number of database connections
to maintain in memory.
Default is 150 (connections).
com.axeda.apm. jdbc.
Connection manager implementation class.
Do NOT change the default, which
is com.axeda.common.jdbc.hsql.
implementation_class
HSQLConnectionManager
com.axeda.apm.jdbc.
checkpoint_frequency
E-mail Settings
The number of hours between backups of the
HPE3PS database.
The default value is 3 hours. You may
want to start with this value and adjust it
as needed.
| Configuration Files | 49
Name
Description
Supported Values
com.axeda.apm.
notification.
email.encoding
Character set used for encoding e-mail
messages.
The default value is UTF-8 (nonASCII). Supports any valid character
set, including ASCII, UTF-16,
ISO8859, and so on. The type of
encoding you select must be supported
by your e-mail server and client
applications.
com.axeda.apm.
notification.
email.mail_server
Name of e-mail server to use for sending e-mail
messages, typically set during installation.
Make sure to specify the complete
server path for your e-mail server; for
example, mailserver.acme.com.
com.axeda.apm.
notification.email
.
mail_server.port
Port number to use on the e-mail server for
messages from Policy Server, typically set
during installation.
The default port number is 25. The
installation program offers this default
value. However, if you are using the
SMTPS or TLS protocol, you need
to use a different port number. For
example, GMail uses port 465 for
SMTPS and port 587 for TLS over
SMTP.\
The protocol to use for communicating with the
SMTP server.
The protocol is SMTP by default (shown
in installation program). You can set
this value to ‘SMTPS’ or “TLS”.
com.axeda.apm.
notification.email
.
mail_server.prot
o
If you choose SMTPS, the property for a
mail session, mail.smtp.ssl.enable, will be
set.
If you choose TLS, the property for a
mail session, mail.smtp.starttls.enable ,
property will be set.
Note: If you do not enter the string for
SMTPS or TLS exactly as shown here,
the default protocol (SMTP) is used.
Policy Server Application Configuration
Set during installation, these properties are used for the email hostname substitution variable feature.
If the notification template stored in the database has the XML tag <$BURL> , then, when a Policy Agent generates a
Pending Request on Policy Server, a URL is created using these properties, as follows:
•
•
If com.axeda.apm.useSsl is set to true, a URL is created in the format https://<hostname >:<sslPort > , is created.
Otherwise, a URL in the format http://<hostname >:<port > is created.
By copying and modifying this URL, users can create the URL for the page to access. For example,
to visit the Pending Requests page, a user can copy the Base URL and then append the string hpe3ps/
index.html#Requests=Requests to this Base URL.
com.axeda.apm.
server.hostname.
Name of the Policy Server host to be used in the
substitution variable for e-mail messages. The
e-mail formatter uses the value provided here
in the body of the e-mail message generated in
response to a permission request.
Any valid host name. For example,
acmePolicyServer. The default value is
localhost.
| Configuration Files | 50
Name
Description
Supported Values
com.axeda.apm.port
Number of the HTTP port on the host specified
in the server.hostname property to use for the
connection.
Make sure the port is open. Example
HTTP port number: 7000.
com.axeda.apm.useSsl
Specify whether to use SSL for the connection.
Set this property to true to use SSL or
false to use the HTTP port. The default
value is false .
com.axeda.apm.sslPort
Specify the port number on the host specified
in the server.hostname property to use for the
connection.
The default SSL port is 8443.
System Error Notification Settings
com.axeda.apm.logger.
notification.email_to
E-mail address of the user to which server-based Any valid e-mail address, for example
notification are sent.
user@acme.com.
com.axeda.apm.logger.
notification.email_from
E-mail address used to identify the Policy Server Any valid e-mail address. For example,
when it sends notifications.
PolicyServer@acme.com.
com.axeda.apm.logger.
notification.
email_frequency
How often (number of minutes) the server will
send e-mail messages about pending requests.
The default value is 60 minutes. Any
whole number (minutes) is supported.
com.axeda.apm.logger.
notification.
email_subject
Text shown in the Subject line of the pending
request notification e-mail message .
The default value is HPE3PS System Error
. Supports any text string, up to 250
characters.
Specifies whether or not daily audit log entries
are saved to a file on disk.
The default setting, true , means that the
server will save audit log information to
a file; if false , audit log information is
not saved to file.
com.axeda.apm.
enable_audit_logging
Specifies whether or not sending audit log
messages to a UNIX style Syslog server is
enabled.
The default setting, false, means that
sending audit log messages to a Syslog
server is not enabled. To send these
messages to an external Syslog server,
set this property to true.
com.axeda.apm.audit
archive.file.prefix
Name (prefix) of the file to which audit log
information is saved. Each day the server will
create a new file of this name and append that
name with a timestamp.
The default value is APM_Audit . Any
valid text string is supported.
Audit Archive Settings
com.axeda.apm.audit.
archive.file.
enable_logging_to_file
Make sure the server is set to
save audit log information to
disk: com.axeda.apm.audit.archive.
file.enable_logging_to_file=true
com.axeda.apm.audit
archive.file.suffix
Extension portion of the file name for the audit
log file.
The default value is .txt . Policy Server
also supports the .csv file formats.
com.axeda.apm.audit
archive.file.path
Directory location to which the audit log files
for the HPE 3PAR Policy Server are archived.
The installation program creates a
directory, /audit , under the main
installation directory. HPE 3PAR Policy
Server supports any valid directory
location on the local computer.
Web Services Settings
| Configuration Files | 51
Name
Description
Supported Values
com.axeda.apm.
webservices.enable
Enables or disables support for Web services
operations.
The default value is false (disabled).
Change to true to enable the Policy
Server to accept and perform Web
services operations.
com.axeda.apm.
Enables or disables user authentication
requirements for Web services operations.
The default value is true (enabled).
Change to false if the Policy Server can
accept Web services operations without
requiring user authentication.
Specifies the maximum number of records
returned for a Web services query.
The default value is 1000 records. Any
whole number is supported.
webservices.authentication.
required
com.axeda.apm.
webservices.max-recordsreturned
com.axeda.apm.
Specifies how long Policy Server waits before
webservices.session.timeoutending an unattended Web services session.
The default value is 6 0 (minutes). Any
whole number is supported.
Note: The session timeout for inactive
user sessions is fixed at 30 minutes.
Backup/Restore Settings
com.axeda.apm. backuprestore. data-directory=
Specifies the directory where the data files are
stored. You should not need to change this
value.
This value is set during installation,
based on the installation directory for
Policy Server and the HSQL database.
For example, C:/Program Files (x86)/HPE
3PAR/ PolicyServer/hsqldb/apm/
com.axeda.apm. backuprestore. backup-directory=
Specifies the directory where the backup files
are stored. You should not need to change this
value.
This value is set during installation,
based on the installation directory for
Policy Server and the HSQL database.
For example, C:/Program Files (x86)/HPE
3PAR/ PolicyServer/hsqldb/apm/backup/
com.axeda.apm. backup-
Specifies the file set for automatic backups.
restore. backup-fileset=
Do NOT change this value. It should be
set to:
apm.backup,apm.data,
apm.script,apm.properties
Pool for XML Parser
com.axeda.apm.
parser.max-poolsize=5000
Specifies the maximum number of connections
in the connection pool. Increase this value based
on the number of agents. The greater the pool
size, the more memory is used.
The default value is 5000. This value
cannot be less than 10. Any value less
than 10 is considered to be 10.
Contact Thread Queue Size and Max Delay Settings
com.axeda.apm.db.
maxContact
ThreadUpdate QueueSize
com.axeda.apm.db.
maxContact
ThreadUpdate
Delay
Message Settings
Specifies the maximum size of the update
contact thread queue (the number of devices).
The default value is 10000.
Specifies the maximum delay between contact
thread updates (in seconds).
The default value is 10 seconds.
| Configuration Files | 52
Name
Description
Supported Values
com.axeda.apm.
message.timeout
Specifies the number of milliseconds that Policy
Server will wait for a message to be sent to it.
Messages that take longer than this time period
will be discarded and a warning will be issued.
The default value is 10000 milliseconds.
Directory Server
Whether you choose to configure an External Directory Server or not, the installation program sets these properties.
The values shown here are for the internal OpenDS directory server. If you are using an external LDAP server, the
values you provided during installation should appear in this section of PolicyManager.properties.
com.axeda.apm.
directory-server. port
Specifies the port on the directory server to use
for authentication.
Specify the port number for Policy
Server to use for communication with
the directory server. The standard port
for LDAP directory servers is 389,
which is the default for the internal
OpenDS directory server. If you want
to change the port used for the directory
server, you need to change the port
number in this configuration file, in the
Tomcat configuration file.(server.xml),
and in the OpenDS configuration
file (config.ldif). See also Editing the
OpenDS Configuration File and Editing
the Tomcat server.xml File.
com.axeda.apm.
directory-server. name
Specifies the host name or IP address of the
machine where the directory server is running.
Specify the IP address or host name of
the machine where the directory server
is running. For the internal OpenDS, the
value is localhost .
com.axeda.apm.
directory-server.
peoplesearch
Specifies search information for locating users
in the database of the directory server.
Specify the appropriate peoplesearch
entry for your directory server. For
an internal OpenDS, the value is as
follows:
ou=People,dc=HPE,dc=com
com.axeda.apm.
directory-server.
groupsearch
Specifies search information for locating groups
in the database of the directory server.
Specify the appropriate groupsearch
entry for your directory server. For
an internal OpenDS, the value is as
follows:
ou=Groups,dc=HPE,dc=com
com.axeda.apm.
directory-server.
adminsearch
Specifies search information for locating
administrators in the database of the directory
server.
Specify the appropriate entry for
your directory server. For an internal
OpenDS, the value is ou=admin .
com.axeda.apm.
userStore.factory
Identifiers the User Store factory.
Do NOT change this value:
com.axeda.apm.
directory-server.on
Enables the directory server.
com.axeda.apm.user. LdapUserStoreFactory
Do NOT change this value: true
| Configuration Files | 53
Name
Description
Supported Values
com.axeda.apm.
directory-server.
manageRoles
Specifies where roles are managed.
When set to true , specifies that roles are
managed from the directory server and
the synchronization process performs
role synchronization as well as user
synchronization.
When set to false , specifies that roles
are managed from the Policy Server
HSQL database and the synchronization
process skips role synchronization..
com.axeda.apm.
userStore.name
Specifies the name of the user store associated
with Tomcat. The value shown after installation
depends on your choice of directory server.
If the user store is Sun ONE LDAP, the
value should be SUN_ONE_LDAP .
If the user store is Active Directory, the
value should be ACTIVE_DIRECTORY.
If the user store is Open DS (including
an internal or external OpenDS), the
value should be OPEN_LDAP .
com.axeda.apm.
userStore.group. users
Specifies the users group required in the
directory server for Policy Server.
Do NOT change this value:
com.axeda.apm.
userStore.group.
administrators
Specifies the administrators group required in
the directory server for Policy Server
Do NOT change this value:
com.axeda.apm.
userStore.group.
ldap.administrators
Specifies the LDAP administrators group
required in the directory server for Policy
Server.
Do NOT change this value:
com.axeda.apm.
userStore.group.
ldap.hpe3psroles
Specifies the HPE3PSRole group name required
in the directory server for Policy Server.
Do NOT change this value:
com.axeda.apm.
administrator. email
Specifies the e-mail address of the administrator
of the directory server.
By default, this property has no value.
If you provide an e-mail address in this
file, be sure to use the proper format.
For example, OpenDSadmin@hpe.com.
com.axeda.apm.
support.email
Specifies the e-mail address for the support
organization.
The default value is support@hpe.com.
Do NOT keep this default value.
com.axeda.apm.
user.password. expired
Specifies the period of time that user passwords
are valid.
By default, the value is -1, which
means user passwords do not expire.
Hewlett Packard Enterprise strongly
recommends that you change this value
to a number of days. For example, 60 .
HPE3PSUsers
HPE3PSAdmins
HPE3PSLdapAdmins
HPE3PSRoles
| Configuration Files | 54
Name
Description
Supported Values
com.axeda.apm.
user.password. expiration.
warning
Specifies how soon before a password will
expire the directory server will send a message
to warn the user that the password will expire.
By default, the value is -1, which
means that no messages will be sent.
This value corresponds to the expired
property value of -1 (no expiration
period). If you set a value such as
60 or 90 days for the expiration, you
should also set a value for this property.
For example, you may want to warn
users 10 or 14 days in advance of the
expiration.
com.axeda.apm.
instantiator. startupfile.name
Specifies the name of the XML configuration
file for the Scheduler. The Instantiator reads this
file for the Scheduler.
Default: startup.xml
com.axeda.apm.
scheduler.retryfrequency
Specifies the number of milliseconds that the
Scheduler waits between attempts to connect to
the database.
Default: 100 milliseconds
Specifies the maximum number of threads for
the Scheduler to use.
Default: 5 threads
Instantiator
com.axeda.apm.
scheduler.maxthreads
com.axeda.apm.
user.password. length
Do NOT change.
Do NOT change unless directed to by a
support engineer.
Do NOT change unless directed to by a
support engineer.
Specifies the minimum length for user
passwords.
The default value is 8 characters.
Depending on your security needs, you
may want to increase this value.
Sets a time period for displaying remote
sessions. For example, the default value is 5
hours. The View and end remote sessions page
will display remote sessions that have been
started between now and 5 hours ago.
The default value is 5 hours.
Too many audit messages can affect Policy
Server performance. To improve performance
you can reduce the number of audit messages
received from the Agents after they have
processed SetDataItem actions for specific data
items. Set the value of this property to be the
names of the data items for which you want to
filter out these audit messages.
The default value is empty. To tell
Policy Server to filter OUT audit
messages for set data item actions for
certain data items, type the names of
those data items, separating them with a
comma.
Remote Sessions
com.axeda.apm.
remote.started. before
If you want to see the remote sessions
for the previous two days, set this value
to 48 hours.
Data Item Filtering
com.axeda.apm.
audit.filter.data-items
Device Message Processing
| Configuration Files | 55
Supported Values
Name
Description
com.axeda.apm. updatemonitor. interval = 10
Specifies the interval (in seconds) between scans The default value is 10 seconds.
by the UpdateMonitor.
Background: To optimize device message
processing, devices that need to be updated
-- due to policy changes and responses
to permission requests -- are tracked by a
background process called UpdateMonitor.
This property defines the interval, in seconds,
between UpdateMonitor scans. During each scan
UpdateMonitor refreshes the list of devices that
need to be updated.
DEPRECATED PROPERTIES Audit Log Paging: Number of Entries on each page
com.axeda.apm.
audit.max-entries-per-
Maximum number of entries or lines shown in a
single page of the Audit Log.
DEPRECATED. This property is not
used as of release 6.1.5.
Maximum number of entries or lines shown in a
single page of the Audit Log.
DEPRECATED. This property is not
used as of release 6.1.5.
page
com.axeda.apm.
audit.max-categoryentries-per-page
DEPRECATED -PROPERTIES
Enhanced Select Lists These properties supported the old UI and are not needed for the UI as of release 6.1.5. .
Specifies the number of items to store in the
most-recently-used list.
DEPRECATED. This property is not
used as of release 6.1.5. The default
value was 9 items.
com.axeda.apm.
enhanced-select-list. maxlines-displayed
Specifies the maximum number of lines
displayed when a select list is in "enhanced
mode".
DEPRECATED. This property is not
used as of release 6.1.5. The default
value was 11 lines.
com.axeda.apm.
enhanced-select-list.
popup-threshold
DEPRECATED. This property is not
When the number of items in a select list is
greater than or equal to this value, the list will be used as of release 6.1.5. The default
shortened by the number of max-lines-displayed value was 35 items
and the list will use "enhanced mode".
com.axeda.apm.
enhanced-select-list. mrusize
DEPRECATED PROPERTIES
Pending Requests – Automatic Refresh Interval
com.axeda.apm. pendingrequests. refresh.interval
DEPRECATED. Sets the number of seconds
between automatic refreshing of the information
on the Pending requests page.
This property is not needed in the user interface
as of v6.1.5, build 615257. As of that build, the
Dashboard page of the Policy Server application
refreshes automatically and it is hard-coded to
refresh every 60 seconds.
DEPRECATED.This property is not
used as of release 6.1.5. The default
value of the property was 60 seconds.
| Configuration Files | 56
Editing the Tomcat server.xml File
The server.xml file contains information specific to the operation of the Apache Tomcat Web server. Except for
enabling SSL support or changing information for the directory server after installation, you should not need to
change any of the settings in this file. As with the PolicyManager.properties file, you modify the values of the namevalue pairs for your use of the Policy Server.
Enabling/Disabling Ciphers in the Tomcat server.xml File
One of the changes you may want to make after installation is to enable SSL and/or enable ciphers for SSL/TLS
communications. For complete information on setting up Apach Tomcat to use SSL, refer to the Tomcat document,
SSL HOWTO at http://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html.
1. Make sure the directory service is running, and then stop Policy Server and Tomcat in one of the following ways:
•
•
From the administration tool for your operating system, stop the Policy Server service or daemon.
Navigate to your installation directory for Policy Server and run the ShutdownHPE3PS script for your
platform to stop Policy Server and Tomcat.
2. To set up SSL/TLS on the Tomcat server, follow the instructions in the Tomcat document, SSL HOWTO at http://
tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html.
3. To enable ciphers, navigate to the directory, <HPE3PS_installation>/Tomcat7/aps/conf and open the
configuration file, server.xml, for editing.
4. Locate the section that starts with <Connector port="8443", and add the ciphers you want to enable. Here is an
example, with ciphers:
<Connector port="8443"
maxHttpHeaderSize="8192"
protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="200"
enableLookups="false"
disableUploadTimeout="true"
acceptCount="400"
scheme="https"
secure="true"
SSLEnabled="true"
clientAuth="false"
ciphers= “TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA,
SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA”
keystoreFile=""
keystorePass=""
sslProtocol="TLSv1.2"/>
5. If you want to disable ciphers, remove them from the ciphers attribute.
6. Save and close the file, and restart Policy Server and Tomcat.
Changing the Directory Server in the Tomcat server.xml File
If you change to an external directory server from the internal OpenDS directory server after installing Policy Server,
you need to edit the Directory Server configuration in the Tomcat server.xml file, as explained in the following
procedure. This procedure assumes that you have created the HPE3PS-specific groups and users in your External
Directory Server. If you have not created these groups and users, refer to the section in Appendix B, External
Directory Servers of the HPE 3PAR Policy Server Installation Guide
Note: For information about changing the directory server password in the server.xml file refer to
1. Make sure the directory service is running, and then stop Policy Server and Tomcat in one of the following ways:
| Configuration Files | 57
•
•
From the administration tool for your operating system, stop the Policy Server service or daemon.
Navigate to your installation directory for Policy Server and run the ShutdownHPE3PS script for your
platform to stop Policy Server and Tomcat.
2. Navigate to the subdirectory, Tomcat7/aps/conf.
3. Using your favorite text editor, open the server.xml file (for example, Notepad).
4. Search for Directory Server configuration. You should see the following lines:
<!-- Directory Server configuration -->
<Realm className="com.axeda.apm.user.CustomJNDIRealm"
connectionName="ou=admin"
connectionPassword="MCoCAQECAQEEEFuojueMfUtQ8m75BK/UPwYEEDuSUhsNQ
ArA0rdualrpLPs="
connectionURL="ldap://localhost:389"
alternateURL="ldap://localhost:389"
userSearch="uid={0}"
userBase="ou=People,dc=hpe,dc=com"
roleBase="ou=Groups,dc=hpe,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0})"
userSubtree="true"
roleSubtree="true"/>
Important: If you want to change the connection password, you must encrypt it first, using the
HPE3PAR CryptoUtils utility. Refer to the section, Changing the Directory Server Password, if you want
to change the password; it provides complete instructions.
5. Change the values of these properties for your directory server:
a) In the line, connectionURL="ldap://localhost:389", type the IP address and port number of the directory server that
you want Policy Server to use.
Note: If you change any directory server information (including just the port for the internal OpenDS
directory server), you need to change not only this file but also the Policy Server configuration file
(PolicyManager.properties) and the OpenDS configuration file (config.ldif). See also Editing the
Policy Server Configuration File and Editing the OpenDS Configuration File.
b) In the lines that follow, type the uid , ou , dc , and cn entries as they exist for your directory server.
6. Save and close the file.
7. Restart Policy Server (run the StartHPE3PS script for your platform).
8. Sign in to the Policy Server application, using the credentials of a user who has View and Add/Edit privileges to
the Users component of the application.
9. Select the Users tab, and then select Users in the menu bar to display the page, View and remove application
users. You should see the users configured in the HPE3PS-specific groups in your External Directory Server.
Changing the Directory Server Password
Changing the administrator password for a directory server is a two-step process. First you need to modify the
administrator password at the directory server itself. Then you need to modify the Tomcat server.xml file for the
change. This section provides instructions for modifying the OpenDS administrator password and for modifying
the Tomcat file. If you are using Active Directory or another LDAP directory server, refer to the instructions for
modifying the administrator password in the documentation for your directory server.
Modifying the OpenDS Administrator Password
If you are using the OpenDS directory server with Policy Server and want to modify the administrator password,
leave OpenDS running and follow these steps:
| Configuration Files | 58
1. Stop Policy Server.
2. Open a Command Prompt (Windows) and navigate to the appropriate directory for the operating system:
• Windows — C:\Program Files (x86)\HPE 3PAR\PolicyServer\OpenDS-1.0.0\bat
3. From this directory, run the command for the windows operating system, entering the current and new
passwords as indicated:
ldappasswordmodify.bat -h localhost -p 389
--bindDN "ou=admin" --bindPassword {currentPassword}
--currentPassword {currentPassword} --newPassword {newPassword}
When the change is successful, OpenDS returns the following message:
The LDAP password modify operation was successful.
4. Continue to the next section to encrypt this password and modify the server.xml file for Tomcat.
Changing the Directory Server Password in the Tomcat server.xml File
The password provided in the connectionPassword property in the Tomcat server.xml file must be encrypted. Once
you change the administrator password for the OpenDS directory server (or the directory server you are using), you
must obtain an encrypted version of the password. Policy Server provides a tool that performs this encryption, called
CryptoUtils tool.
Follow these steps to change the directory server password in server.xml, including encrypting the password
(Windows paths shown):
1. Open a Command Prompt in administrator mode.
2. Run the following command:
{HPE3PS_HOME}\jre\bin\java -cp {HPE3PS_HOME}\Tomcat7\aps\common\lib
\cryptoutils-1.0.2.jar
com.axeda.security.encryption.Encrypt -home {HPE3PS_HOME}\Tomcat7\aps\conf
3. When prompted, enter the password that you want to encrypt (the administrator password for OpenDS, for
example).
4. When the utility returns the encrypted version of the password, copy it.
5. As long as you are logged in with administrator rights, open the server.xml file from the directory,
{HPE3PS_HOME}\Tomcat7\aps\conf.
6. Paste the encrypted password in the connectionPassword field of the server.xml file.
7. Save and close the file.
8. If you modified the administrator password for OpenDS, stop OpenDS and restart it. For other directory servers,
you may also need to stop and restart the directory server.
9. Restart Policy Server.
Note: Since the tool's Java classes are packaged in cryptoutils-1.0.2.jar , the cryptoutils-1.0.2.jar (and its
dependencies) must exist on the Java class path. For example, assuming that the Policy Server instance is
installed in ${HPE3PS_HOME} , the HPE 3PAR CryptoUtils tool should be invoked using the HPE3PS
home directory.
| Configuration Files | 59
When run without arguments, the CryptoUtils tool prompts you to enter the text to be encrypted. In addition, this tool
supports the following command line options:
Options
Description
-?, -help
Print the help message.
-echo
Do not disable console echo during input.
-stdin
Read the text from the standard input (instead of the console).
-text text
Encrypt the specified text (instead of console or standard input).
Note: Encrypted passwords produced by the CryptoUtils tool can be used only with the Policy Server
instance for which they were created.
HSQL Database Configuration File
For the HSQL database, the configuration file is server.properties. Located in the directory, \hsqldb\apm, under your
Policy Server installation, this file contains information specific to the database setup and operation. Typically, you
will not change any of the database settings. If you are experienced with databases, read through the explanations of
the parameters, their default settings, and supported values in the following table before making any changes.
Table 4: HSQL Database Properties
Properties
Description
server.database.0
The property server.database.0 specifies Do NOT change the values of these
the location of the database file and the properties.
property server.dbname.0 specifies the
alias for the database. Neither property
should be changed. They must remain
set as follows:
server.dbname.0
Supported values
server.database.0=
file:C:/HPE 3PAR/
PolicyServer6Test2/
hsqldb/apm/apm
server.dbname.0=apm
server.silent
Controls the number of database
logging messages to display in the
command console.
True — extensive
messages are not
displayed (default)
False — extensive
messages are
displayed
server.trace
Controls the display of JDBC trace
messages in the command console.
True — JDBC messages are not
displayed
False — JDBC messages are
displayed (default)
server.port
TCP/IP port that the database uses to
communicate with clients (port upon
which the database is running).
Any supported TCP/IP port on the
computer. 9002 is the default
| Configuration Files | 60
Properties
Description
Supported values
server.no_system_exit
Specifies whether the system exits
upon closing the database.
True — system exits
when the
database closes
False — system does not exit
the database closes (default)
when
Appendix A
Troubleshooting Tomcat
You may need to troubleshoot for the following issues when Tomcat is running in standalone mode:
•
•
Another web server or other process is operating on the default HTTP port that Tomcat attempts to bind to at
startup (8080).
If this is the case, modify server.xml and replace the default port number with another, unused port greater than
1024 (because ports of 1024 or less require super user access to bind to). Then, restart Tomcat and access it using
the new port, for example, http://localhost:8081, or https://localhost:8443 if SSL is enabled.
The ‘localhost’ machine is not found. This problem can occur if your browser computer is located behind a proxy
server. In this case, make sure the proxy settings for your browser are configured such that your browser does not
go through a proxy to access the ‘localhost” machine. For Internet Explorer, you can find these settings as follows
•
•
•
•
•
On the Tools menu select Internet Options.
In the Internet Options dialog box, select the Connections tab.
In the Connections tab click LAN Settings. The Proxy settings appear in the lower portion of the LAN
Settings dialog box.
For the Tomcat connector pool, the basic recipe is to keep increasing the limit until your Tomcat has spare threads.
That is, the number of active threads is less than the setting for the maxThreads property in the Tomcat server.xml
file. (The property for Tomcat's connector thread pool is Server/Service/Connector.maxThreads.) For the database
pool, follow this same idea, except that you need to watch for messages saying, “Waiting for a jdbc connection to
become available” , in the HPE3PS log file. Keep increasing the size of the database connection pool until you do
not see the messages. This property is in the configuration file for Policy Server, PolicyManager.properties and is
called com.axeda.apm.jdbc.max_pool_size.
If the external directory server used with Policy Server is restarted or goes offline for any reason, Tomcat looks
for a directory server on 'localhost:389'. This is normal Tomcat behavior.
For release 6.1.5, changes were made so that the three HPE3PS components on a Windows machine all come
back up properly when the host machine is rebooted. However, in the log you may see a Connection error from
the JNDIRealm concerning the connection between Policy Server and OpenDS. This log stack trace cannot be
suppressed. As long as users can log in to the HPE3PS user interface, you can ignore this error.
Note: Except for operations in SNMP environments, HPE 3PAR Policy Server, Agent Gateway and Policy
Agents, the HPE 3PAR Enterprise Server, the Agent Deployment Utility, and Agent Builder support both
IPv4 and IPv6 address formats. For SNMP operations, you must use the IPv4 format (nnn.nnn.nnn.nnn).
| Starting/Stopping HPE3PS Manually | 62
Appendix B
Starting/Stopping HPE3PS Manually
If you did not install Policy Server as a service or daemon and need to start and stop it manually, this appendix is for
you.
Starting Policy Server Components Manually
These instructions assume that you did not install the Policy Server and HSQL database as services and therefore need
to start them manually. Keep in mind that the internal OpenDS directory server is automatically installed as a service.
The directory server MUST be running when starting Policy Server. Otherwise, the order of starting the components
shown here is recommended as a best practice:
1. Start your directory server (whether internal or external).
2. Start the HSQL database:
a) For Windows operating system, log in to the computer as Administrator and open a Command prompt.
b) Navigate to the <HPE3PS_installation_directory>/Tomcat7/bin directory, where
<HPE3PS_installation_directory> is the path to Policy Server directory on the machine.
c) Locate and run the startHSQLDB script (*.bat for Windows).
When the database starts up on a Windows machine, you'll see messages similar to those in the following screen:
| Starting/Stopping HPE3PS Manually | 63
3. Start Policy Server:
a) For Windows operating system, log in to the computer as Administrator and open a Command prompt
b) Navigate to the <HPE3PS_installation_directory>/Tomcat7/bin directory, where
<HPE3PS_installation_directory> is the path to Policy Server directory on the machine.
c) Locate and run the StartHPE3PS.bat (Windows).
The StartHPE3PS script starts the Tomcat Web server and the HPE 3PAR Policy Server. When the server
starts running, the console window for Policy Server appears, showing information similar to the following.
(The actual version will match the released build and version of the software.)
| Starting/Stopping HPE3PS Manually | 64
Stopping Policy Server Components Manually
These instructions assume that you did not install the Policy Server and HSQL database as services and that you
started them manually. Keep in mind that the internal OpenDS directory server is automatically installed as a service.
The directory server MUST be running when stopping Policy Server. Otherwise, the order of stopping the
components shown here is recommended as a best practice:
1. Make sure that the internal OpenDS directory server service is running or that your external directory server is
running.
2. Stop Policy Server:
a) If not already logged in, log in Administrator (Windows).
b) Display the console for Policy Server.
c) From the console, press CTRL+C.
d) When prompted, answer Yes (you want to terminate).
3. Stop the HSQL database:
a) If not already logged in, log in Administrator (Windows).
b) Display the console for the HSQL database.
c) From the console, press CTRL+C.
d) When prompted, answer Yes (you want to terminate).
4. If necessary, stop the internal OpenDS service or your external directory server.