BMC Remedy Action Request System 7.1.00: Configuring

BMC Remedy Action Request System 7.1.00
Configuring
August 2007
www.bmc.com

Contacting BMC Software
You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada
Address BMC SOFTWARE INC
2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA
Outside United States and Canada
Telephone 713 918 8800 or
800 841 2031
Telephone (01) 713 918 8800 Fax (01) 713 918 8000
Fax 713 918 8000
If you have comments or suggestions about this documentation, contact Information Development by email at
doc_feedback@bmc.com.
© Copyright 1991–2007 BMC Software, Inc.
BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with
the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC
trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other
trademarks or registered trademarks are the property of their respective owners.
DB2 is a registered trademark of International Business Machines Corporation.
IBM is a registered trademark of International Business Machines Corporation.
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is
registered in the U.S. Patent and Trademark Office.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX is a registered trademark of The Open Group.
Java, Javadoc, JRE, and Solaris are is a trademark of Sun Microsystems, Inc. in the U.S. or other countries.
BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this
information is subject to the terms and conditions of the applicable End User License Agreement for the product and the
proprietary and restricted rights notices included in this documentation.
Restricted Rights Legend
U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE
COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the
U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS
252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is
BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this
address.

Customer Support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or email. To expedite your inquiry, please see “Before Contacting BMC Software.”
Support Website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support_home. From this website, you can:
■ Read overviews about support services and programs that BMC Software offers.
■ Find the most current information about BMC Software products.
■ Search a database for problems similar to yours and possible solutions.
■ Order or download product documentation.
■ Report a problem or ask a question.
■ Subscribe to receive email notices when new product versions are released.
■ Find worldwide BMC Software support center locations and contact information, including email addresses, fax
numbers, and telephone numbers.
Support by telephone or email
In the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or
send an email message to customer_support@bmc.com. (In the Subject line, enter
SupID:, such as SupID:12345.) Outside the United States and Canada, contact your local
support center for assistance.
Before Contacting BMC Software
Have the following information available so that Customer Support can begin working on your issue immediately:
■ Product information
— Product name
— Product version (release number)
— License number and password (trial or permanent)
■ Operating system and environment information
— Machine type
— Operating system type, version, and service pack
— System hardware configuration
— Serial numbers
— Related software (database, application, and communication) including type, version, and service pack or
maintenance level
■ Sequence of events leading to the problem
■ Commands and options that you used
■ Messages received (and the time and date that you received them)
— Product error messages
— Messages from the operating system, such as file system full
— Messages from related software

Contents
Preface 11
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
AR System documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 15
AR System architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
BMC Remedy mid tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
AR System server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
AR System and web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Creating and publishing a web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Consuming a web service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Mid tier scalability. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
AR System server scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Working with a portmapper service in AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Windows and portmapper services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring clients through environmental variables. . . . . . . . . . . . . . . . . . . . . . . 30
Chapter 2 Licensing AR System 31
About AR System licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Changes in licensing from previous releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
About license types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Licenses in a server group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
About license charges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Obtaining license keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Adding licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Removing licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Exporting licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Importing licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Reviewing license usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Reporting license usage within a date range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Verifying purchased licenses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Contents 5

6 Configuring
Chapter 3 Setting user preferences 43
User preferences and customizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Local preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Centralized preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Creating a preference server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuring clients to use a preference server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Setting centralized preferences on Windows clients . . . . . . . . . . . . . . . . . . . . . . . . 49
AR System User Preference form fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Common fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
General tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Display tab (BMC Remedy User only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Color tab (BMC Remedy User only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Confirmation tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Report tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Logging tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Locale tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
File tab (BMC Remedy User only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Advanced tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Home Page tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Alert tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Recent tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Edit tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Window tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Misc tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Web tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Setting centralized preferences on web clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Chapter 4 Defining your user base 81
Licensing users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
License types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Viewing user information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Releasing floating licenses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
License pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Adding and modifying user information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
User form permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Allowing guest users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Special submitter mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Validating password information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Enforcing a password policy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Setting up the mid tier for the password policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Forcing users to change their passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Enforcing restrictions on passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Setting up password expiration with scheduled warnings . . . . . . . . . . . . . . . . . . 101
Disabling an account after the expiration period . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Enabling users to change their passwords at will. . . . . . . . . . . . . . . . . . . . . . . . . . 102

Setting up an authentication alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
User Name Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Authentication String Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Unique user logins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Chapter 5 Setting up the BMC Remedy AR System Administration Console 107
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring AR System to use the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Opening the console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Chapter 6 Configuring servers and clients 111
Configuring AR System servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Server information—Platform tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Server information—Timeout tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Server information—Licenses tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Server information—Configuration tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Server information—Log Files tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Server information—Database tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Server information—Server Ports and Queues tab . . . . . . . . . . . . . . . . . . . . . . . . 128
Server information—Advanced tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Server information—Source Control tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Server information—Server Events tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Server information—Connection Settings tab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Server information—Currency Types tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Server Information—EA tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Configuring a server for development or production cache mode . . . . . . . . . . . . . . 150
Configuring multiple servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuring multiple servers on one machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Configuring multiple servers to access the same database. . . . . . . . . . . . . . . . . . 153
Running servers as part of a group. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Running a stand-alone AR System server on Windows . . . . . . . . . . . . . . . . . . . . . . . 168
Configuring firewalls with AR System servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Configuring clients for AR System servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Configuring a server to use plug-ins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Configuring the AR System server for external authentication (AREA). . . . . . . . . . 172
Configuring a mail server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Configuring a server for alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Chapter 7 Working with the alert system 177
Alert system architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Alert Events form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Viewing alerts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
CleanupAlertEvents escalation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Managing registered users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Working with versions of the AR System prior to 5.x . . . . . . . . . . . . . . . . . . . . . . . . . 181
Upgrading the server but not the clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Upgrading or installing clients but not the server . . . . . . . . . . . . . . . . . . . . . . . . . 181
Enabling alerts on the Web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Contents 7

8 Configuring
Chapter 8 Importing data into AR System forms 185
The import process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Data mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Preparing to import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Defining BMC Remedy Import preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Desktop preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Duplicate request ID preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Error handling preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Data preferences. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Date and time preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Confirmation message preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Importing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Import procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Stopping an import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Defining fallback mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Saving a mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Using a saved mapping file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Using the import log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
AR XML data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
All other data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Chapter 9 Using full text search 207
Overview of full text search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Accruing and weighting results with FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Sorting requests by weight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Using the Ignore Words List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Who can perform a full text search? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Using FTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Performing a search in a field indexed for FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Searching for word stems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Using wildcards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Using the QBE method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Using the advanced search bar method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Adding a form search field to a form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Parametric full text search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Search strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Search issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Limitations of FTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Administering FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Selecting fields for FTS indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Full text search indexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Indexing for attachments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Multiple languages and attachment file formats. . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Reindexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
FTS configuration options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Debugging FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
FTS logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

Upgrading FTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Assigning FTS licenses to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Defining a field for FTS in the Field Properties window . . . . . . . . . . . . . . . . . . . . . . . 229
Estimating the size of the FTS index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Displaying FTS weight in a results list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Appendix A Working with the Request ID field 233
Working with the Request ID field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Changing the next available ID for new requests. . . . . . . . . . . . . . . . . . . . . . . . . . 234
Changing the Request ID field length or prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Preserving existing Request ID field values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Changing existing Request ID field values to a new format. . . . . . . . . . . . . . . . . 238
Updating the Request ID field in other AR System tables . . . . . . . . . . . . . . . . . . 246
Appendix B AR System configuration files 247
ar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
ar.conf (ar.cfg). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
ardb.conf (ardb.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
armonitor.conf (armonitor.cfg) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Appendix C AR System server components and external utilities 291
AR System server components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
arforkd (UNIX only) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
armonitor (armonitor.exe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
arplugin (arplugin.exe). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
arserverd (arserver.exe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
Java plug-in server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
External utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
arcache (arcache.exe). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
arreload (arreload.exe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
arsignal (arsignal.exe) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Appendix D Date and time formats 303
Short date formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Long date formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Day formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Time formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Additional characters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Appendix E Working with the Server Events form 307
Understanding the Server Events form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
How the Server Events form is created . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Types of events you can record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Viewing the server changes you recorded. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Using server events in workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Contents 9

10 Configuring
Appendix F Using Business Time in the AR System server 325
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
How Business Time 2.0 works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Scheduling a time segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Understanding levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Creating non-conflicting segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Defining a business time segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Understanding time segment entity associations . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Understanding time segment shared entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Using offset hours in Business Time 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Business Time commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Application commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Business Segment-Entity Association commands. . . . . . . . . . . . . . . . . . . . . . . . . . 344
Application-Get-Next-Recurrence-Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Using the old Business Time forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Scheduling workdays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Scheduling holidays. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Defining business hours using offset hours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Old Business Time commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Migrating Workdays and Holidays to the Business Time Segment form . . . . . . . . . 354
Debugging tips for Business Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Appendix G Using the Assignment Engine 357
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Assignment Engine process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Assignment Engine Administration Console. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Auto-assignment methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Preparing for the auto-assignment process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Fields to add to the assignee form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Fields to add to the request form. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Adding assignment forms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
Adding assignment processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
Adding assignment rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Setting sequencing for rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Turning on log and trace files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
ARerror.log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Appendix H Using produse.exe 373
Using produse.exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Index 377

Preface
Audience
IMPORTANT
The compatibility information listed in the product documentation is subject to
change. See the compatibility matrix at http://www.bmc.com/support_home for the
latest, most complete information about what is officially supported.
Carefully read the system requirements for your particular operating system,
especially the necessary patch requirements.
This guide is written for administrators who are responsible for setting up and
maintaining the BMC Remedy Action Request System (AR System). The guide is
intended to aid new and current administrators of AR System. If you are a current
AR System administrator, this guide enhances the ease of use and performance of
your AR System environment. If you are a new AR System administrator, this
guide helps you create an effective and efficient AR System environment.
Before you explore the topics in this guide, make sure that you understand the
terms and concepts discussed in the Optimizing and Troubleshooting guide, which
contains all the required information for setting up and administering a basic
AR System environment. Your knowledge of basic administrative AR System
tasks is crucial for successful implementation of the strategies discussed in this
guide.
You must know how to use AR System, including BMC Remedy Administrator,
BMC Remedy User, and BMC Remedy Import. See the Installing guide, the Form
and Application Objects guide, and the Workflow Objects guide for additional
information.
Preface 11

AR System documents
AR System documents
12 Configuring
The following table lists documentation available for AR System products.
Unless otherwise noted, online documentation in Adobe Acrobat (PDF) format is
available on AR System product installation DVDs, on the Customer Support site
(http://www.bmc.com/support_home), or both.
You can access product Help through each product’s Help menu or by clicking
Help links.
Title Description Audience
Concepts Overview of AR System architecture and features with indepth
examples; includes information about other
AR System products as well as a comprehensive glossary for
the entire AR System documentation set.
Everyone
Installing Procedures for installing AR System. Administrators
Getting Started Introduces topics that are usually only learned when first
starting to use the system, including logging in, searching
for objects, and so on.
Everyone
Form and Application Objects Describes components necessary to build applications in
AR System, including applications, fields, forms, and views.
Developers
Workflow Objects Contains all of the workflow information. Developers
Configuring Contains information about configuring AR System servers
and clients, localizing, importing and exporting data, and
archiving data.
Administrators
Installing and Administering Contains information about the mid tier, including mid tier Administrators
BMC Remedy Mid Tier installation and configuration, and web server
configuration.
Integrating with Plug-ins and Discusses integrating AR System with external systems Administrators/
Third-Party Products using plug-ins and other products, including LDAP, OLE,
and ARDBC.
Developers
Optimizing and
Server administration topics and technical essays related to Administrators
Troubleshooting
monitoring and maintaining AR System for the purpose of
optimizing performance and troubleshooting problems.
Database Reference Database administration topics and rules related to how
AR System interacts with specific databases; includes an
overview of the data dictionary tables.
Administrators
Administering BMC Remedy Server administration and procedures for implementing a Administrators
DSO
distributed AR System server environment with the BMC
Remedy Distributed Server Option (DSO).
Administering BMC Remedy Flashboards administration and procedures for creating and Administrators/
Flashboards
modifying flashboards and flashboards components to
display and monitor AR System information.
Programmers
CAPI Reference Information about AR System data structures, C API Administrators/
function calls, and OLE support.
Programmers
C API Quick Reference Quick reference to C API function calls. Administrators/
Programmers

Title Description Audience
Java API Information about Java classes, methods, and variables that
integrate with AR System. This online documentation is in
ardoc71.jar, typically located in C:\Program
Files\AR System\\ARServer\Api\doc on
Windows and /usr/ar//api/doc on
UNIX ® .
Java Plug-in API Information about Java classes, methods, and variables used
to write plug-ins for AR System. This online documentation
is in arpluginsdoc.jar, typically located in C:\Program
Files\AR System\\ARServer\Api\
javaplugins on Windows and /usr/ar//
api/javaplugins on UNIX.
Administering BMC Remedy
Email Engine
Procedures for installing, configuring, and using the BMC
Remedy Email Engine.
Error Messages List and expanded descriptions of AR System error
messages.
Administrators/
Programmers
Administrators/
Programmers
Administrators
Administrators/
Programmers
Master Index Combined index of all books. Everyone
Release Notes Information about new features list, compatibility lists,
international issues, and open and fixed issues.
Everyone
BMC Remedy User Help Procedures for using BMC Remedy User. Everyone
BMC Remedy Import Help Procedures for using BMC Remedy Import. Administrators
BMC Remedy
Procedures for creating and modifying an AR System Administrators
Administrator Help application for tracking data and processes.
BMC Remedy Alert Help Procedures for using BMC Remedy Alert. Everyone
BMC Remedy Mid Tier
Configuration Tool Help
Procedures for configuring the BMC Remedy Mid Tier. Administrators
Preface 13

14 Configuring

Chapter
1 BMC
Remedy Action Request
System 7.1.00 architecture
This section discusses the overall architecture of AR System 7.1.00 and provides a
conceptual overview of the components of the AR System.
The following topics are provided:
AR System architecture overview (page 16)
AR System and web services (page 22)
Scalability (page 23)
Working with a portmapper service in AR System (page 29)
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 15

BMC Remedy Action Request System 7.1.00
AR System architecture overview
16 Configuring
AR System is based on a client/server architecture and includes three functional
environments:
Presentation—The presentation piece of AR System is responsible for
presenting services and displaying data to clients through various interfaces.
These interfaces include:
browsers
cell phones
PCs
Personal Data Assistants (PDAs)
BMC Remedy User
BMC Remedy Administrator
API programs
All these interfaces enable you to access AR System. Clients can be thought of as
consumers of services that the AR System server provides.
Business processing—This portion of the architecture includes:
The mid tier
The AR System server
Server functions such as the Distributed Server Option (DSO), and Approval
Server
The Enterprise Integration Engine (EIE)
Web services
The business processing piece of AR System is responsible for providing
services to clients and processing the data entered through clients. Applications
that reside within the business processing environment act as liaisons for the
clients and the database, enforcing the rules of your business processes.
Data storage—The data storage element contains the actual data for the system.
AR System supports DB2, Informix, Oracle ® , Sybase, and Microsoft SQL
databases. For each of the relational databases, tables owned by other systems
can also be referenced as if they were owned by AR System. Also, ARDBC plugins
can be created and configured to allow access to data stored outside the
database as if it were located within tables that are owned by AR System.
Figure 1-1 depicts the relationship among the components that reside within each
of the functional environments of the AR System architecture. Notice that no
definitive starting and ending point separates the three environments, because
their functions sometimes overlap.

Figure 1-1: AR System architecture
Services
1. Reporting
2. Flashboards
3. ...
Support
Programs
Browser
Clients
Services
1. Approval
2. DSO
3. Application
Servers
4. ...
BMC Remedy mid tier
Internet
Mid tier
Wireless
Clients
AR System
Database
Windows
Clients
AR System Server
Non-AR System
Database
Palm OS
Client
Sync
ARDBC
Plug-in
Other
Non-Database
Data Sources
AR System architecture overview
Presentation
Business
Processing
Data
Storage
Within these three functional environments, several system components work
together to provide power, flexibility, and scalability. The rest of this section
focuses on two of those components, the mid tier and the AR System server, and
the interaction between them.
For more information about the AR System architecture, see the Concepts guide.
The mid tier serves as a client of the AR System server and as a server to the
browser. The mid tier enables you to view AR System applications on the web and
access the AR System server from a web server. It also provides instructions to the
browser in the form of document markup and downloadable scripts. These
instructions describe how to present application data and how to interact with the
user.
The mid tier leverages a Java servlet engine and includes a collection of servlets
that are plugged in to the web server to serve forms, images, and other resources.
The servlet engine facilitates communication between the browser and the web
server. It provides components and add-in services that run on the web server.
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 17

BMC Remedy Action Request System 7.1.00
AR System server
18 Configuring
The web server manages the transfer of all HTML content to the browser.
Infrastructure components, such as servlets and other services (special Java
classes), translate client requests and interpret responses from the AR System
server.
Unlike BMC Remedy User, a browser is a generic client that has no inherent
knowledge of any application that might run within it. By acting as an interpreter,
the mid tier allows a browser to become a fully functional AR System client.
The main components of the mid tier infrastructure are:
Web server—A server that receives requests for a web page and maps the
uniform resource locator (URL) to a local file or servlet on the host server. The
server then loads the content and serves it across the network to the user’s
browser.
JSP engine—An engine that handles the .jsp files and the basic request and
response interface in the browser environment.
JSP servlets—A small piece of Java code, often translated from a .jsp file, that
runs on a web server.
JAVA API—An API that is used to communicate with the AR System server.
The object model provides a set of classes representing the data structures and
functions of the API.
BMC Remedy Mid Tier Configuration Tool—A tool that enables you to set
properties for the mid tier. It is accessible through a .jsp file in a browser using
a separate login. The properties submitted from the Mid Tier Configuration
Tool are stored in memory for quick retrieval and are written to a file called
config.properties for persistence between web server restarts.
Properties that can be set using the Mid Tier Configuration Tool include the list
of AR System servers to access, the session time-out interval, directory locations,
Reporting Tool options, logging, Flashboards, log setting, home page server
settings, and user authentication for web services.
For more information about mid tier settings, see the Installing and Administering
BMC Remedy Mid Tier guide.
The AR System server processes all the data entered by a client. As the workflow
engine between the client and the database server, the AR System server writes
data into the database when an AR System request is created, and retrieves that
data when a client requests it. The server verifies that a user has permission to
perform each transaction that is requested, thereby enforcing any access control
that you have defined as part of an application. The server also evaluates the data
in the database with each transaction to determine whether workflow is triggered.

AR System architecture overview
The AR System server has no direct user interface. Clients, such as the mid tier,
BMC Remedy User, and other applications, communicate with AR System by
means of a well-defined application programming interface (API). Both a C
interface and a Java interface are available. The API uses remote procedure calls
(RPCs) to communicate with the server.
When a client submits a request to the server, the request enters through the API,
goes through access control and data validation, filter processing, and then
transactions are committed to the data repository as appropriate.
The main components of the AR System server architecture are:
Application programming interface (API)—A set of functions and data
structures that provide application programmers with access to the full
functionality of a product. Developers can create clients written in C or Java. The
AR System API is documented in the C API Reference guide and the Action
Request System Java API HTML pages.
Access control and data validation—A security feature in which AR System
administrators limit the access users have to forms, to specific fields within a
form, to specific functions within the system, and to data stored within the
system.
Alerts—A client program that functions as a “desktop pager.” This component
within the AR System server supports desktop pages such as flashing icons,
audible beeps, sound files, and message windows. For example, it can display a
message alerting help desk personnel that a new problem has been assigned to
them.
For more information about alerts, see Chapter 7, “Working with the alert
system,” and BMC Remedy Alert help.
Filters—Actions performed on the AR System server, which is the portion of the
software that controls the flow of requests to an underlying database. As a
request is processed by the server, the filter actions take place. Filters allow you
to implement constraints, make decisions, and take action when operations are
performed on data stored in AR System.
Escalations—Actions performed on the server at specified times or time
intervals. They are automated, time-based processes that search for requests
that match certain criteria and take action based on the results of the search.
AR System Filter (ARF) Plug-In API—A filter that offers a programming
interface that is directly invoked by filter workflow. This provides a flexible and
efficient mechanism for communicating with various applications or web
services. Use of plug-ins reduces system overhead. ARF plug-ins also apply to
escalations.
For more information, see the Integrating with Plug-ins and Third-Party Products
guide.
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 19

BMC Remedy Action Request System 7.1.00
20 Configuring
AR System External Authentication (AREA)—A process that accesses network
directory services and other authentication services to verify user login name
and password information. When you use an AREA plug-in, you do not need to
maintain duplicate user authentication data in the AR System directories
because the AR System server can access user identification information and
user passwords at many locations.
For more information, see the Integrating with Plug-ins and Third-Party Products
guide.
View form—A form that allows AR System to point to and access data in an
existing database table created outside AR System. The table can be located in
the same database or in any other database accessible from the current
AR System database.
For information about creating and using view forms, see the Form and
Application Objects guide.
Vendor form—A form that enables AR System to access arbitrary external data
sources through the use of an ARDBC (AR System Database Connectivity)
plug-in. This type of form provides for easy integration with external data
without replicating the data.
For information about creating and using external forms, see the Form and
Application Objects guide.
Database servers—The AR System uses standard relational databases for
storing and retrieving data. Architecturally, the database server is a set of
processes that are completely separate from the AR System server processes.
Physically, the database server processes can be running on the same computer
as the AR System server or on a different computer. The database server can be
run on any platform that the particular database supports.
Figure 1-2 depicts the infrastructure of the AR System server.

External
Processes
External
Processes
Web
Services
Figure 1-2: AR System server infrastructure
AREA
Plug-In
Filter API
Plug-In
API
Access Control and
Data Validation
Filters
Sybase MSSQL Oracle Informix DB2
AR System architecture overview
View
Alerts
Vendor
Plug-In
User
Escalations
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 21

BMC Remedy Action Request System 7.1.00
AR System and web services
22 Configuring
Web services allow AR System functionality to be available over the web
(publishing), and enable AR System applications to access third-party
applications. For both publishing and consuming web services, you establish a
base form to which the information is set, or through which the information is
pushed to other forms or applications. You must map the AR System fields on a
base form to input or output parameters of a web services operation. A field can
participate as either an input parameter, an output parameter, or both. You can
map AR System fields to a simple flat document or to a complex hierarchical
document involving parent and child relationships.
Creating and publishing a web service
A web service is created and modified in BMC Remedy Administrator using the
web services graphical user interface. Publishing web services makes AR System
operations available over the Internet or an intranet.
Web services that are published in AR System can be simple, such as creating a
record in the AR System database, or more complex, such as processing a purchase
order that spans across multiple AR System forms.
Each web service consists of the following resources:
A base form on which it operates. You specify this form when you create the
web service. For web services that span across multiple AR System forms, the
base form is the master form.
A list of Create, Get, or Set operations. When you create a web service, by
default, it has four named operations: OpCreate, OpGet, OpList, and OpSet. You
can have more than one operation of the same type, or you can have no
operations of a particular type.
A mapping that specifies how individual elements of incoming and outgoing
XML documents are mapped to fields and forms of the AR System. These are
essentially the input and output parameters of the web service.
An association with XML Schema (.xsd file). Global elements and complex
types referred to in the schema can be used in mappings associated with
operations.
Consuming a web service
You can use an external web service by creating a Web Service Set Fields filter
action to enter data from the web service into a base form. You can then view the
form in an AR System client.
For more information about creating and publishing web services, see the
Integrating with Plug-ins and Third-Party Products guide.

Scalability
Mid tier scalability
Scalability is a feature in both the mid tier and the AR System server.
Scalability
The strategy for processing and serving browser-client requests is based on several
components. These components work together to take input from the client and
compute a response that the user sees in the browser as Dynamic HTML
(DHTML). These mid tier components do not run in a separate proprietary
process, but in the JSP engine using standard web protocols.
The use of JSP servlets makes the mid tier scalable in the following ways:
Multiple threads connecting to a servlet can handle many concurrent users.
Common web-server mechanisms and practices can be used for scaling and load
balancing.
Use of mid tier and user caches of AR System definitions require fewer trips to
the AR System server to retrieve them. In addition, use of browser caching has
led to data size reductions, which in turn reduces bandwidth requirements.
Additionally, the architecture supports server clusters, or web farms that are
hardware setups in which several physical web servers share the load directed to
one logical server (one IP address). In a web farm, a load balancer receives requests
and sends them to whichever physical server has the most resources available to
handle them.
AR System server scalability
The AR System multithreaded server is scalable from a single thread performing
all server functions to multiple threads, each performing specific functions. The
threads adapt to the configuration parameters defined, and they distribute the
load. You determine what amount of operating system resources to dedicate to
AR System.
The multithreaded architecture uses two concepts—queues and threads—as
shown in Figure 1-3. The following sections describe how these queues and
threads function in the AR System server.
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 23

BMC Remedy Action Request System 7.1.00
24 Configuring
Figure 1-3: Multithreaded server architecture
Escalation
Queue
Worker
Thread
Browser AR System
Client Administrator Client
Mid-Tier
Flashboards
Queue
Worker
Threads
Admin
Queue
Worker
Thread
Dispatcher
Dispatcher
Fast
Queue
Worker
Threads
Database
AR System
API Programmer
List
Queue
Worker
Threads
Client
Private
Queues
390621-390634
390636-390669
390680-390694
Worker
Threads
Alert
Queue
390603 390619 390600 390620 390635
390601
Worker
Threads
Note: The number of
worker threads for fast,
list, and private queues
can be increased to
the maximum number
of connections your
database and hardware
can support.

Queues
Scalability
A queue is a meeting point where remote procedure calls (RPCs) wait to be
handled by the worker threads that process the RPCs. When a queue is created, it
automatically starts the minimum number of threads specified for its thread type.
The default for this setting is 1. For more information, see “Threads” on page 27.
There are seven types of AR System queues. Each queue has an RPC program
number associated with it, as outlined in the following table.
Queue type RPC program number
Admin 390600
Alert 390601
Escalation 390603
Flashboards 390619
Fast 390620
List 390635
Private 390621–390634, 390636–390669,
390680–390694
NOTE
Administration, alert, escalation, Flashboards, fast, and list queues use a fixed RPC
program number. Private queues, however, can be configured to use any RPC
program number within the ranges of RPC program numbers reserved for private
queues.
The following sections describe the different types of queues.
References to the configuration file apply to the configuration file specific to your
system. The configuration file for Windows is ar.cfg. For UNIX ® , this file is
ar.conf.
Administration queue
The administration (admin) queue is the only AR System queue that can perform
every operation within the system. It performs all administrative restructuring
operations, guaranteeing the serialization and integrity of all restructuring
operations. This queue can have only one thread.
All servers include an admin queue, which is the default server setting. Because an
admin queue has a single thread available to handle requests, a server that has only
an admin queue (and no fast or list queues) functions as a single-threaded server.
While the admin queue handles all administrative functions, it can also perform
the functions of all other queues if no other queues are configured. If no other
queues are configured, all requests are placed in the admin queue.
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 25

BMC Remedy Action Request System 7.1.00
26 Configuring
Alert queue
The alert queue handles all alerts that are sent to registered clients. The alert queue
handles only internal requests, not requests from outside the AR System server.
The threads in this queue do not open database connections, so they do not use
many resources.
The minimum thread count for the alert queue is 1. If the server is supporting
Remedy Notifier 4.x clients, set a maximum of 5 alert threads because those client
versions cannot handle more than 5 simultaneous connection requests. If the
server is supporting Remedy Notifier 3.x or earlier clients, set a maximum of 1 alert
thread because those client versions do not correctly handle simultaneous
connection requests.
To configure an alert queue, see “Defining queues and configuring threads” on
page 131.
Escalation queue
All servers automatically create an escalation queue unless Disable Escalations is
configured. (For more information, see “Configuring multiple servers to access the
same database” on page 153.) The escalation queue handles only internal requests,
not requests from outside the AR System server. It handles escalations specified by
the administrator and performs all escalation processing. The escalation queue is
multithreaded.
Flashboards queue
The Flashboards queue is a private queue that is automatically created if your
system has a Flashboards license. The queue supports all functionality of the
Flashboards product to make sure that there is dedicated access without
overwhelming the other queues in your system.
Fast queue
The fast queue handles the operations that generally run to completion quickly
without blocking access to the database. The fast queue handles all server
operations, except for:
Administrative operations that restructure the database. These operations use
the administration queue.
The ARExport, ARGetListEntry, ARGetListEntryWithFields, and
ARGetEntryStatistics, and other API calls (which use the list queue).
See the C API Reference guide for more information about API calls.
One or more threads can serve the fast queue if a fast queue is configured. To
configure a fast queue, see “Defining queues and configuring threads” on
page 131.

List queue
Scalability
The list queue handles AR System operations that might require significant time,
block access to the database, or both. Examples of these operations include
ARExport, ARGetListEntry, ARGetListEntryWithFields, and ARGetEntryStatistics.
One or more threads can serve the list queue if a list queue is configured. To
configure a list queue, see “Defining queues and configuring threads” on page 131.
Private queues
Administrators can also create private queues for specific users who need
dedicated access. For example, you might create a private queue for a user who is
performing critical operations that you do not want blocked by other users. Private
queues guarantee a certain bandwidth dedicated to clients using these queues.
Private queues support all operations except restructuring operations.
Restructuring operations are supported only by the administration queue (see
“Administration queue” on page 25). To configure a private queue, see “Defining
queues and configuring threads” on page 131.
Each private queue can be supported by one or more threads. To connect a user to
a private queue, see “Configuring clients for AR System servers” on page 170.
Threads
The term thread is short for “thread of execution.” Threads allow the server to
process concurrent client requests. Each thread within the multithreaded server
can carry out a client request before returning to the queue to process the next one.
Start only as many threads as your database and system resources can reasonably
support. The total number of threads cannot exceed the number of database
connections that are available to the AR System server.
All threads within a process share network and system resources; therefore,
consider carefully the available resources of your network when establishing the
minimum and maximum thread settings for your server queues.
There are three types of AR System threads:
Dispatcher
Worker
Thread manager
The following sections describe the different types of threads.
Dispatcher thread
The dispatcher thread routes requests to the appropriate queues. This thread
receives connection requests from clients. The dispatcher thread then places the
requests into the appropriate queue where each request can be handled by one of
multiple worker threads.
Every call that the dispatcher thread receives is assigned an RPC ID that can be
used to identify the call from the time the call is placed into a queue until a
response is sent to the client.
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 27

BMC Remedy Action Request System 7.1.00
28 Configuring
In general, the dispatcher thread uses the following logic to dispatch calls:
If no other queues are defined, the dispatcher thread routes all requests to the
admin queue. If, however, fast and list queues are created in addition to the
admin queue, the dispatcher routes client requests according to the type of
operation being performed. If private queues are created, the dispatcher directs
the call to the appropriate private queue based on the RPC program number of
the request.
A request is routed to the appropriate queue based on its RPC program number.
For example, a call that has RPC program number 390600 is routed to the admin
queue.
If a call with RPC program number 390620 (fast) or 390635 (list) is received and
there is no fast or list queue, the dispatcher thread routes the call to the admin
queue. If there is only a list queue, the dispatcher thread places the call in that
queue. If there is only a fast queue, the dispatcher thread directs the call to that
queue. If there are both fast and list queues, the dispatcher routes the call to the
appropriate queue based on the call number.
If a call is received with RPC program number 390601 (previously supported by
the Notification server, which has now been merged with the AR System
server), the dispatcher routes the call to the fast queue.
If a call is received with an RPC program number other than those specified for
admin, fast, list, and Flashboards queues, the dispatcher identifies the call as
destined for a private queue. If a private queue supporting the RPC program
number exists, the dispatcher thread routes the call to that queue. If no private
queue exists but there is a fast or list queue, the call is routed to the appropriate
queue based on its RPC program number. If there is no fast or list queue, the call
is routed to the admin queue.
The escalation and alert queues do not receive calls from the dispatcher.
Worker threads
Worker threads respond to the RPCs that have been dispatched to individual
queues. Each queue creates one or more worker threads. The worker threads
within a queue are identical and can handle any request. Only the worker thread
started by the admin queue, however, can handle calls that modify definitions or
server configuration settings.
Upon startup, each thread creates a connection to the database that it uses
throughout its existence. If the thread is unable to establish a connection, it
terminates itself, notifying the queue that no more threads are to be started. The
database connection is dedicated to the thread, even when that particular thread is
not busy.
Any available worker thread can remove the request from the queue, read the
request, process it, and return results to the client before returning to the queue to
respond to another request. When a request is placed in a queue and no existing
threads are available to handle it, a new thread is started until the queue reaches
the maximum number of threads allowed for its thread type.

Thread manager
Working with a portmapper service in AR System
The thread manager is responsible for ensuring that a thread is restarted if it dies.
Determining how many threads you need
A major benefit of a multithreaded server is not having “fast” operations held up
behind a slow “list” operation. Deciding how many fast and list threads you need
depends on your particular setup and situation. For example, not specifying
enough list threads might mean you have idle fast threads but an overloaded list
queue.
Another consideration is that list threads require more memory than fast threads.
For example, a complicated query might require a great deal of memory at a given
moment. A few of these large queries can temporarily exhaust your system
resources.
To determine how many threads of each type you need, start by examining the
types of API calls in your API log file. If your system processes many fast
operations, you might decide to increase the number of fast threads. A different
rule of thumb is to specify a larger maximum of list threads than fast threads,
simply because fast operations are generally performed more quickly than list
operations.
Do not specify an artificially high number of maximum threads because the
threads would essentially get in one another’s way by consuming resources that
other threads need. To set the number of minimum and maximum threads, see
“Server information—Server Ports and Queues tab” on page 128.
Working with a portmapper service in
AR System
A portmapper functions as a “directory” of services and the ports on which those
services are running. Processes can opt to register or not register their location with
a portmapper. A common reason for not registering with a portmapper is security.
If an AR System server is registered with a portmapper, your clients do not need
to know what port the server is listening on because the clients can identify the
port using the portmapper and direct API calls to the appropriate TCP port. If a
server is not registered with a portmapper, you need to assign a TCP port number
to that server. Otherwise, the system must search for an open port to communicate
on each time the server is restarted. Your clients will not know where to find your
AR System server because the port might be different if the AR System server is
restarted.
Registering with a portmapper and assigning TCP port numbers are not mutually
exclusive options. You can do both. If you specify a particular port for a server and
register the server with a portmapper, clients within the firewall do not need to be
configured to access the specified port number.
Chapter 1 BMC Remedy Action Request System 7.1.00 architecture 29

BMC Remedy Action Request System 7.1.00
30 Configuring
If the AR System server is not registered with a portmapper:
Client processes must be able to identify the port to communicate on to contact
the server. For more information about configuring ports for the client, see “To
configure Windows clients to avoid using a portmapper” on page 170.
Macros that a UNIX User tool runs as part of an escalation or filter run process
cannot find the server. To fix this, register the server with a portmapper. You can
also use the runmacro utility, which has a command-line port setting.
For more information, see “Configuring clients through environmental
variables” on page 30.
The client/server interaction still requires the use of RPC when specific ports are
used.
Windows and portmapper services
Because many Windows environments do not have a portmapper service, one is
provided with the AR System server. If you already have a portmapper,
AR System registers with it if requested. If not, you can specify that the AR System
Portmapper service needs to be started and used as the portmapper for the system.
There is no AR System Portmapper for UNIX because all UNIX operating systems
include a portmapper as a standard feature.
Configuring clients through environmental variables
When using a client on a UNIX server, you can connect to the AR System or to a
private server at a specific TCP port by setting the AR TCP Port variable.
The following strategies require that all servers that the client uses are on the same
port.
For the C shell, use the following commands to set ARTCPPORT:
setenv ARTCPPORT
aruser &
For the Bourne shell, use the following commands to set ARTCPPORT:
ARTCPPORT=; export ARTCPPORT
aruser &
For an API program, you can set variables through a shell or from within the
program. For more information, see the C API Reference guide.

Chapter
2 Licensing
AR System
This section contains information about licensing AR System. The following topics
are provided:
About AR System licensing (page 32)
About license types (page 33)
About license charges (page 34)
Adding licenses (page 36)
Removing licenses (page 38)
Exporting licenses (page 38)
Importing licenses (page 39)
Reviewing license usage (page 41)
Chapter 2 Licensing AR System 31

BMC Remedy Action Request System 7.1.00
About AR System licensing
32 Configuring
To add any license to an AR System 7.1.00 server, you must first add an AR System
server license (see “Adding licenses” on page 36).
To add an AR System server license, you need a license key (see “Obtaining license
keys” on page 35).
After installing your server and adding its license, you can do the following:
Use all the AR System features.
Add any other licenses you need to run applications without the need to obtain
a key.
Changes in licensing from previous releases
This table lists the differences between licensing in AR System 7.1.00 and licensing
in previous releases:
Component Previous releases AR System 7.1.00
License keys Every license required a key. Before you
could add any license to an AR System
server, you had to contact BMC to get a
key.
Server groups All AR System server and user floating
licenses used by server groups needed a
license qualifier.
All licenses used by a server group had to
be applied to every server in the group.
Dedicated server
licenses
Dedicated server licenses were provided
for common components such as the BMC
Atrium Definitive Software Library or
CMDB.
Only AR System server licenses need keys.
Customers can add all nonserver licenses
without the need for a key.
No license qualifiers are required.
Each server must have its own AR Server
license and license key, but it shares all
other licenses with the other servers in the
group.
Dedicated server licenses are not used.
When you upgrade to 7.1.00 from a
previous release, dedicated server licenses
are upgraded to full AR System server
licenses at no cost. In addition, licenses for
any applications associated with the
dedicated server are automatically added
to your system.

About license types
About license types
To use AR System fully, you need several types of licenses in addition to an
AR System server license:
AR System user—The following types of licenses provide users write access to
an AR System server:
AR User Fixed
AR User Floating
For more information, see “License types” on page 82.
Server options—Optional server components, such as Distributed Server
Option (DSO) and Flashboards, require separate licenses.
Application—To be run on an AR System server, most applications must be
licensed on the server.
Application user—To use AR System–based applications, each user needs two
licenses: an AR System user (fixed or floating) and an application user (fixed or
floating).
An AR System server with no server license allows you to assign these licenses:
Three fixed user write licenses
Unlimited user read licenses
Unlimited user restricted read licenses
You can evaluate AR System without purchasing or activating any licenses. You
are limited, however, to a maximum of 2000 requests per form.
To purchase additional licenses, contact your BMC Remedy product sales
representative or an authorized reseller.
For information about licensing applications that you create using BMC Remedy
products, see the Integrating with Plug-ins and Third-Party Products guide.
Licenses in a server group
Because servers in a server group use the same database, they share licenses. Each
server must have its own AR Server license and license key, but it shares all other
licenses with the other servers in the group.
For more information about server groups, see “Running servers as part of a
group” on page 155.
Chapter 2 Licensing AR System 33

BMC Remedy Action Request System 7.1.00
About license charges
34 Configuring
You incur charges for AR System licenses as follows:
AR System server, server option, and application licenses
You are billed for each instance of an AR System server, server option, and
application license.
User fixed licenses
When you add AR System or application user fixed licenses to a server, you
specify the number of such licenses that can be concurrently assigned in the
Number of Licenses field (see “Adding licenses” on page 36). This number is the
maximum number of licenses available for assignment. This number does not
have to be the same as the number of licenses you purchased. The peak number
of user fixed licenses that are assigned to users in each billing period is tracked
and used for billing purposes, whether or not the assigned users ever log in.
User floating licenses
When you add AR System or application user floating licenses to a server, you
specify the number of such licenses that can be concurrently used in the Number
of Licenses field. This number is the maximum number of licenses available for
use. This number does not have to be the same as the number of licenses you
purchased. The peak number of user floating licenses that are in-use at the same
time during each billing period is tracked and used for billing purposes.
User license limits
You can make any number of user licenses available on your server regardless of
the number you purchased. For example, if you purchased 10 AR User Fixed
licenses but need to use 15, you can immediately update the Number of Licenses
field—you do not have to wait for BMC to give you a key. If, during an audit, BMC
finds that your usage exceeded your purchased license count, you will be billed for
the additional use.
IMPORTANT
To remain in compliance with your purchased licenses, be sure to set the
appropriate use limits in the Number of Licenses field for each license.

Obtaining license keys
About license charges
A license key is a value that enables you to activate a license. In AR System 7.1.00,
only AR System server licenses require keys. Each key is tied to a particular server;
it will not work on any other server.
If you purchased your AR System server (AR Server) license through a BMC sales
representative or over the web, you can obtain the license key from the BMC
Electronic Product Distribution (EPD) site. Access the EPD site from the BMC
Customer Support website at http://www.bmc.com/support_home.
NOTE
If you do not know your user ID and password for the site, contact Customer
Support by telephone or email. See “Support by telephone or email” on page 3.
To obtain a key, you must provide the following information:
Support contract ID
Purchase order number
Email address
AR System server version
AR System server host ID
To determine the AR System server host ID
1 Install AR System.
2 Open the AR System Administration Console.
3 Click System > General > Add or Remove Licenses.
The Current Host ID is displayed in the upper-right corner of the Add or Remove
Licenses form.
Chapter 2 Licensing AR System 35

BMC Remedy Action Request System 7.1.00
Adding licenses
36 Configuring
To add licenses to an AR System server, you can enter them into a form or import
them from a file. Licenses are active as soon as they are added to the server.
To add licenses by entering them into a form
1 In the AR System Administration Console, click System > General >
Add or Remove Licenses.
Figure 2-1: Add or Remove Licenses form
2 In the Add or Remove Licenses form, click Add New.

3 In the fields under the table, enter this information:
Field Description
4 Click Save.
To add licenses by importing them
See “Importing licenses” on page 39.
Adding licenses
License Type From the drop-down list, select the type of license to activate.
You can also enter a custom license type. (For license naming
rules, see the Integrating with Plug-ins and Third-Party Products
guide.)
Note: You can add only one entry for each license type except
server licenses (multiple server licenses are distinguished from
each other by license keys). To increase or decrease the number
of licenses available for other license types, modify the existing
entry. See “Modifying licenses” on page 41.
Number of Licenses For the specified license type, enter the appropriate number of
licenses.
Server, server option, and application licenses
0 indicates the license is inactive.
1 indicates the license is active.
User licenses
0 indicates the license is inactive.
Any number greater than 0 indicates the maximum number of
licenses available for use.
For more information, see “About license charges” on page 34.
License Qualifier Used to further identify license behavior. Do not modify the
contents of this field unless instructed to do so by BMC or a
qualified BMC partner.
Key (Server licenses only) Enter the appropriate license key in this field.
To get a key, see “Obtaining license keys” on page 35.
Important: Do not enter a 6.0–7.0.x key in this field. Instead, import
it from a .lic file. See “Importing licenses” on page 39.
Expiration Date For trial licenses, enter the date after which the license is no longer
in effect. (In AR System 7.1.00, only trial licenses expire.)
Chapter 2 Licensing AR System 37

BMC Remedy Action Request System 7.1.00
Removing licenses
38 Configuring
To remove an AR System license from a server, follow this procedure.
To remove AR System licenses
1 In the AR System Administration Console, click System > General >
Add or Remove Licenses.
2 In the table at the top of the form, select the license to remove.
3 Do one of the following:
Click Delete, and then click OK in the confirmation message.
Set the Number of Licenses field to 0, and then click Save.
NOTE
Nonserver license removals take effect immediately. To remove a server license,
however, you must restart the server after removing the license.
Exporting licenses
You can export license information in the Add or Remove Licenses form to a .lic
file to create a backup copy. You must export all the licenses; you cannot select
specific licenses to export.
To export AR System licenses
1 In the AR System Administration Console, click System > General >
Add or Remove Licenses.
2 Click Export Licenses to File.
The Save Attachment dialog box appears.
3 Navigate to the directory in which you want to save the .lic file.
4 In the File name field, enter a name for the license file or accept the default
(arsystem.lic).
5 Click Save.

Importing licenses
Importing licenses
To import licenses from AR System 7.x or 6.x .lic files into an AR System 7.1.00
server, use this procedure.
NOTE
Except for AR Server licenses, license keys are not imported. In addition, expired
licenses are not imported.
NOTE
In AR System 7.1.00, dedicated server licenses —provided for common
components such as the BMC Atrium Definitive Software Library or CMDB—are
not used. If you had a dedicated server license in a previous release, it is upgraded
at no cost to a full AR Server license when you import your licenses. In addition,
licenses for any applications associated with the dedicated server are
automatically added to your system.
To import AR System 7.x or 6.x licenses
1 In the AR System Administration Console, click System > General >
Add or Remove Licenses.
2 Click Import Licenses from File.
The Add Attachment dialog box appears.
3 Navigate to the location of the license (.lic) file to import.
4 Select the file name to add it to the File name field.
5 Click Open.
Chapter 2 Licensing AR System 39

BMC Remedy Action Request System 7.1.00
40 Configuring
6 When asked “Do you want to overwrite any matching licenses?,” click one of these
buttons:
No—Merges the contents of the .lic file with the contents of the Add or
Remove Licenses form as follows:
When the form and the .lic file contain a matching license type, the entries
for that type are not imported from the .lic file.
For example, if the form has an entry for five AR User Fixed licenses and the
.lic file has an entry for three AR User Fixed licenses and another entry for
four AR User Fixed licenses, the form retains its entry, and neither entry is
imported from the .lic file.
When the .lic file contains multiple entries for a particular license type and
the form contains no matching entry, all entries in the file are imported into
the form and merged into one entry.
For example, if the form has no entries for AR User Fixed licenses and the .lic
file has an entry for three AR User Fixed licenses plus another entry for four
AR User Fixed licenses, the two entries in the .lic file are merged into one
entry in the form. The new entry in the form is for seven AR User Fixed
licenses.
Yes—Clears the contents of the form and replaces it with the contents of the .lic
file. Multiple entries in the file for the same license type are merged into one
entry in the form.
WARNING
Select Yes only to update all your licenses. This option deletes all existing
information from the form. To replace deleted information, you must reenter it.
See “Adding licenses” on page 36.
7 In the confirmation message, click OK.

Reviewing license usage
Reviewing license usage
To make sure that you are in compliance with your purchased licenses, you can
periodically generate a license usage report for each of your AR System servers
(including each server in a server group). The report contains the following
information:
For AR System and application user floating licenses, the greatest number of
licenses in use at the same time during the period covered by the report.
For AR System and application user fixed licenses, the greatest number of
licenses assigned at the same time during the period covered by the report.
For each type of license, the maximum limit specified in the Add or Remove
Licenses form.
The report is written to a file named ReportResult.csv. You can generate it from
the Administration Console.
Maximum number of
licenses that can be
used concurrently.
Peak number of
in-use floating licenses
or assigned fixed licenses.
Figure 2-2: License usage report
Chapter 2 Licensing AR System 41

BMC Remedy Action Request System 7.1.00
42 Configuring
To generate a license usage report
1 In the AR System Administration Console, click System > General >
Add or Remove Licenses.
2 In the Add or Remove Licenses form, click Generate License Usage Report.
3 Click the arrow next to the License Report Start Date field, and select a date from
the calendar.
The start time is 12:00:00 a.m. on the specified date.
4 Click the arrow next to the License Report End Date field, and select a date from
the calendar.
The end time is 11:59:59 p.m. on the specified date.
NOTE
If the selected start or end date exceeds the time period covered by the server, the
first or last date covered by the server is used instead. The time period covered by
the report is specified in the report header.
5 Click Generate Report.
A message specifying the location of the ReportResult.csv file appears. By default,
the file is stored in this directory:
(UNIX ® ) /Db
(Windows) \ARServer\Db
6 Click OK.
The license usage report is displayed in a CSV-compatible viewer, such as
Microsoft Excel.
NOTE
You can also use the produse.exe utility to generate a license usage report. See
Appendix H, “Using produse.exe.”.
Reporting license usage within a date range
By default, the information in the license usage report is based on all the license
usage data stored on the server. To limit the information in the license usage
report, specify a date range when running a license usage report.
Verifying purchased licenses
To obtain an up-to-date list of your AR System licenses, you can request a
reconciliation report of purchased licenses from BMC. Contact your BMC Sales
representative or Customer Support (see “Support by telephone or email” on
page 3).

Chapter
3 Setting
user preferences
This section discusses options for setting user and administrator preferences
locally and on the server (centralized). The following topics are provided:
User preferences and customizations (page 44)
Local preferences (page 44)
Centralized preferences (page 45)
AR System User Preference form fields (page 50)
Setting centralized preferences on web clients (page 79)
Chapter 3 Setting user preferences 43

BMC Remedy Action Request System 7.1.00
User preferences and customizations
44 Configuring
Users can set individual preferences for the behavior and display characteristics of
each client. These preferences can be stored locally (on the client machine) or
centrally (on a designated preference server).
Users who log in to BMC Remedy User can choose to use local or centralized
preferences. Centralized preferences help users who want to have the same
settings and customizations available when they use multiple machines. Local
preferences are used when no preference server is designated or available.
Regardless of whether centralized or local preferences are used, multiple users can
use the same client machine with individual preferences and customizations. For
more information, see “Setting centralized preferences on Windows clients” on
page 49.
For multiple users on a single machine, you need to set up separate user accounts
by creating individual Home directories. For more information about the content
and format of files in the Home directory, see BMC Remedy User help. For
information about setting up user accounts, see the client installation section in the
Installing guide.
Users logging in to web clients must use centralized preferences to store
preferences. See “Setting centralized preferences on web clients” on page 79 for
more information.
Local preferences
Local preferences are saved on the user’s computer in the local ar.ini file.
To use localized preferences
1 Open BMC Remedy User.
2 Enter your login information and specify (none) in the Preference Server field on
the Login window.
Your preferences are saved to your local ar.ini file.
NOTE
There is no synchronization between local and centralized preferences; local
preferences are not stored on your preference server. Similarly, the system does
not update your ar.ini file when you set your centralized preferences.

Centralized preferences
Centralized preferences
To use centralized preferences, create at least one preference server during the
login procedure, configure clients to log in to the preference server, and install the
preference forms during server installation. Web clients can also access the web
view of the AR System User Preference form.
If you did not install preference forms during installation, after you log in, your
local ar.ini file is used to determine your preferences.
If you have not installed the preference forms, and subsequently want to use
centralized preferences, you can import the definition files. There are three
preference forms, and all three must be loaded on the preference server for
centralized user preferences to function properly. For more information about
these forms, see “Creating a preference server” on page 45.
Creating a preference server
To create a preference server, install or import the following forms and associated
objects.
These forms are available through the AR System Administration Console; click
System > User Preferences or click System > Admin Preferences.
Form Purpose and Content
AR System User
Preference form
AR System User Central
File form
Stores preferences for BMC Remedy User, BMC Remedy
Alert (if installed), and web clients. This form has two views:
Standard view—Displays every field on the form, and has
all the preferences that you can set for the web and BMC
Remedy User, including the Request ID, Modified Date,
and Last Modified By fields. Administrators have access to
every user entry for this form.
Web view—Displays web preference fields (that is the
preferences used by the web).
(BMC Remedy User only) Stores copies of locally stored
customized files such as saved searches, favorite forms,
macros, reports, customized field defaults, and user data
files. Note that recently used forms, guides, applications, and
requests are stored in the AR System User Preference form.
Chapter 3 Setting user preferences 45

BMC Remedy Action Request System 7.1.00
46 Configuring
Form Purpose and Content
AR System Searches
Preference
AR System
Administrator Preference
form
(Mid tier only) Stores searches that users create and save
for a form in a browser. For more information about
searches in a browser, see the Installing and Administering
BMC Remedy Mid Tier guide.
Stores preferences for BMC Remedy Administrator and BMC
Remedy Import. By default, this form has administrator
permissions only. You might want to set subadministrator
permissions by following the procedures in the Form and
Application Objects guide.
Display preferences and the list of login servers are shared
with BMC Remedy User and are stored in the AR System
User Preference form.
For information about installing centralized preference forms, see the Installing
guide. For information about importing forms and other server objects, see the
Form and Application Objects guide.
Configuring clients to use a preference server
To use centralized preferences in BMC Remedy User, users must specify a
preference server during login by selecting the server from the list in the
Preference Server field of the Login dialog box.
For web clients, the administrator specifies preference servers. Administrators can
specify the names of preference servers during the mid tier installation, or they can
specify these servers later by using BMC Remedy Mid Tier Configuration Tool. For
more information, see the Installing and Administering BMC Remedy Mid Tier guide.
Also, see the online help for BMC Remedy User, BMC Remedy Administrator,
BMC Remedy Alert, and BMC Remedy Mid Tier Configuration Tool.
Make sure that users can modify their entries on the preference forms. To do this,
assign a write license to every centralized preference user, or set the Submitter
Mode on the server to Locked, which allows users to modify requests without a
write license. For more information, see “Adding and modifying user
information” on page 86 and “Special submitter mode” on page 94.
Establishing a mandatory preference server
As an AR System administrator, you can designate a mandatory preference server
that stores the system preference information. This configurable server setting
provides a mechanism to enforce the use of centralized preferences across an
organization.
To enable a mandatory preference server
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.

2 Click the Advanced tab.
Figure 3-1: Server Information—Advanced tab
3 Select the appropriate Preference Server Option:
Centralized preferences
User Defined—This option allows the user to determine whether or not to use
a preference server.
Use This Server—This option designates the current server as the preference
server. (The preference forms must be available)
Use Other Server—This option designates the current server as a nonpreference
server and indicates that there is another server on the system that is
set with Use This Server.
IMPORTANT
If Use This Server or Use Other Server is selected, the local preferences are disabled.
The system will attempt to connect to the designated preference server. If no
preference server is found, the default preference values are used instead of the
local ar.ini file.
For more information about the effects of these choices, see “Behaviors associated
with preference server configuration” on page 48.
4 Click OK.
Chapter 3 Setting user preferences 47

BMC Remedy Action Request System 7.1.00
48 Configuring
Behaviors associated with preference server
configuration
To use centralized preferences in BMC Remedy User, users must specify a
preference server during login by selecting the server from the list in the
Preference Server field of the Login dialog box.
Different behaviors will occur depending on the server settings you configure.
If you choose User Defined as the Preference Server Option on the Advanced tab
of the AR System Administration: Server Information form, the following
behaviors can occur:
User action Behavior
The user leaves the The local preferences are used (ar.ini file).
Preference Server field
blank
The user specifies a The system connects to the preference server, and the Accounts
valid preference server list is updated to reflect the list of servers that are specified on
the Server List setting.
The user specifies an The local preferences are used (ar.ini file).
invalid preference
server
If you choose Use This Server or Use Other Server as the Preference Server , the
following behaviors can occur:
User action Behavior
The user leaves the
Preference Server field
blank
The system searches the Accounts list for a server that is
designated as a preference server. If one is found, the server
name is written to the Preference Server field of the Login dialog
box. In addition, the accounts list is updated to reflect the list of
servers that are specified on the Server List setting for that
preference server.
Note: The user will receive this warning: 50176—A preference
server has been selected based on the Administrator
settings.
If no preference server is available, the default preference
values are used and no session specific changes to the
preferences are stored. (Local preferences are disabled.)

User action Behavior
The user specifies a
valid preference server
The user specifies an
invalid preference
server
Setting centralized preferences on Windows clients
Centralized preferences
The system connects to the preference server and the Accounts
list is updated to reflect the list of servers that are specified on
the Server List setting for that preference server.
The system searches the accounts list for a server that is
designated as a preference server. If one is found the server
name is written to the Preference Server field of the Login dialog
box. In addition, the accounts list is updated to reflect the list of
servers that are specified on the preference server.
Note: The user will receive this warning: 50174—The
preference server specified is invalid. Another
preference server has been selected.
If no preference server is available, the default preference
values are used and no session specific changes to the
preferences are stored. (Local preferences are disabled.)
The user will receive this warning: 50175 -- The
preference server specified is invalid. User
preferences will not be used.
User and administrator preferences can be set using the following client tools:
For BMC Remedy User and BMC Remedy Alert, preference settings are
accessed through the Tools > Options menu, and are stored in the AR System
User Preference form.
For BMC Remedy Administrator and BMC Remedy Import, preference settings
are accessed through the File > Preferences menu, and are stored in the BMC
Remedy Administrator Preference form.
NOTE
These forms are available through the AR System Administration Console; click
System > User Preferences or click System > Admin Preferences.
In BMC Remedy User, users can also create and save customizations such as
reports, macros, favorite forms, user data, custom field defaults, and saved
searches. All these customizations are stored locally on the client, but they can be
uploaded to and downloaded from the AR System Central File form for
centralized access.
Preferences can be set in BMC Remedy User to synchronize local and central copies
by uploading or downloading files manually or automatically, such as when the
user logs in. Before selecting a synchronization method, users need to consider the
number of customizations, the frequency of changes, and whether central or local
copies of files are likely to be the most current.
For more information about creating customizations, and downloading and
uploading custom files, see BMC Remedy User help.
Chapter 3 Setting user preferences 49

BMC Remedy Action Request System 7.1.00
50 Configuring
You can also set the value of the fields in the User Preferences form using the
PERFORM-ACTION-SET-PREFERENCE run process command. See the Workflow Objects
guide for more details.
AR System User Preference form fields
Common fields
The following tables list the fields in the AR System User Preference form.
These fields reside in the non-page field portion of the AR System User Preference
form. These fields affect both BMC Remedy User and the mid tier.
Figure 3-2: AR System User Preferences form—common fields
Field Name Description
Login Name The user’s login name. Lets the administrator create, search for,
and modify preferences for a specific user by entering that user’s
login name in this field.
Users can search for and modify their own preference records.
The default setting is $USER$.
Short Description Lets the administrator create, search for, and modify preferences
based on a value in this field.
The default setting is Preference entry for $USER$.
Create Date The date the record was created. This field is display-only.
Modified Date The date the record was last modified. This field is display-only.
Last Modified By The login name of the user who last modified the record. This field
is display-only.
Request ID The request ID of the record. This field is display-only.
Assigned To Not used.
Status Not used.

General tab
Figure 3-3: AR System User Preferences form—General tab
General tab—Application area
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
On Startup Maximize
AR System
User
Prompt For
Login
Defines whether the BMC Remedy User main window
fills the entire screen when it is opened.
Defines whether you are prompted for a user name and
password each time you log in.
If you select No, the user name and password you enter
are saved and used to log in automatically the next time
BMC Remedy User is started.
You are still prompted for a login regardless of this
setting if any of these conditions exists:
The administrator has enforced required login.
You are using BMC Remedy User on a computer other
than his or her own.
A user account with a directory path for your Home
folder on you local machine has not been specified in
the Users dialog box.
Note: If you select No as the Prompt for Login option and
you were the last user to log in, other users accessing
BMC Remedy User from that machine are logged in
automatically under your user name.
X X
X
Web
client
Chapter 3 Setting user preferences 51

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
On Exit Save Window
Workspace
Server Server Login
List
52 Configuring
Advanced
Server Option
Defines whether, the next time you open BMC Remedy
User, the workspace appears as it was when you closed
it, including the windows that were open, their size and
position.
Note: If you have a window workspace saved, BMC
Remedy User will load that workspace when you open
BMC Remedy User regardless of how you have this
preference set. If you do not want a workspace loaded,
you must select Yes to save the workspace, close all
forms, and exit BMC Remedy User. Then, open BMC
Remedy User and check No for Save Window
Workspace.
Defines which servers BMC Remedy User connects to. To
change this list, open BMC Remedy User and choose
Tools > Accounts to display the Account dialog box.
Corresponds to the Advanced Server Properties option in
the Account dialog box. To see the Account dialog box,
open BMC Remedy User and choose Tools > Accounts.
The options are:
No—Clears the Advanced Server Properties check box
in the Account dialog box.
Yes—Selects the Advanced Server Properties check
box in the Account dialog box. If you select Yes, the
TCP and RPC columns will be displayed in the
Account dialog box. These are used for setting the TCP
port number or private server number for a specific
server.
X
X
X
Web
client

Search Path Designates the directories where you can access custom
reports and macros. The path is typically
/arHome/arcmds.
To change the search path, enter the entire directory
name for the directory to which you want access.
To specify more than one directory, separate each
directory name with a semicolon. You can specify any
directory to which you have access.
Num Items in
Recently Used
List
Note: If you delete all directories from your search path,
you cannot access any custom reports or macros.
By default, the number of recently used items is set to 5.
You can specify from 4 to 9 items. This setting applies to
these menu lists in BMC Remedy User:
General tab—Form area
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
File > Recent New Forms—Displays a list of the most
recently used forms in New mode.
File > Recent Search Forms—Displays a list of the
most recently used forms in Search mode.
File > Recent Requests—Displays a list of the most
recent requests.
File > Recent Entry Points—Displays a list of the most
recent entry points.
Actions > Recent Searches—Displays a list of the most
recently used searches.
X X
Group Name Field Name Description BMC
Remedy
User
On New Defines the action a form opened in New mode takes
when accessed multiple times. The options are:
Set Fields to Default Values—(Default) Designates
that fields on new forms are filled with default values
when a new form is opened or when a form is reset
after a request is submitted.
Keep Previous Field Values—Designates that fields
on new forms are filled with the previously used values
when that form is reset after a request is submitted.
Clear All Fields—Designates that all fields on new
forms are cleared when a new form is opened or when
a form is reset after a request is submitted.
Clear—Designates that when no option is selected, the
default (Set Fields to Default Values) is used.
Chapter 3 Setting user preferences 53
X
X X
Web
client
Web
client

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
On Search Defines the action a form opened in Search mode takes
when accessed multiple times. The options are:
54 Configuring
Show Result
List Only
Limit Number
of Items
Returned
On Open Show
Advanced
Search Bar
Maximize
Window
Diary Field Show Most
Recent First
Set Fields to Default Values—Designates that fields
on search forms are filled with default values after you
perform a search, display the records in modify or
display mode, and then return to the search form
without closing the form.
Keep Previous Field Values—Designates that fields
on search forms are filled with previously used values
after you perform a search, display the records in
modify or display mode, and then return to the search
form without closing the form.
Clear All Fields—(Default) Designates that all fields
on search forms are clear after you perform a search,
display the records in modify or display mode, and
then return to the search form without closing the form.
Clear—Designates that when no option is selected, the
default (Set Fields to Default Values) is used.
Defines whether you view only the results list after every
search. If you select No, you will view the results list and
a detail pane after every search.
Defines whether the number of search results returned is
limited. The options are:
No—(Default) All results are returned.
Yes—The number specified on the User Preference
form is returned. When you select Yes, you can specify
the number of search results returned. (If you choose
No, this field is disabled.) The default value is 1000.
This preference can be overridden by the Max Entries
Returned by GetList server setting in the Configuration
tab of the AR System Administration: Server
Information form. AR System will use the lesser of the
two values.
Defines whether to show the advanced search bar when
a new window is opened.
X X
X X
X X
X X
Defines whether a form is maximized when it is opened.
If you select No, the form fills only a portion of the BMC
Remedy User window or browser.
X X
Defines the order in which entries appear in the diary
field of a form. The options are:
X X
Yes—Diary entries are listed in descending order by
date, starting with the most recent entry.
No—(Default) Diary entries are listed in ascending
order by date, starting with the earliest entry.
Default—See No.
Web
client

Field Menu Display As Designates how field menus are displayed. The options
are:
Default—See Popup Menus.
Field Menu Expand at
Startup
Popup menus—(Default) Display menus in standard
popup menus. Hierarchical menus are displayed with
arrows indicating that you must move to the right to
view lower-level menu selections. Large menus can
cause display problems.
List boxes—Display menus in tree views. Choose this
option if you need to display large menus.
Smart menus—Display menus in standard popup
menus except when the menu exceeds four levels or the
total number of menu items exceeds 200. In this case,
the menu is displayed as a list box.
Clear—Display menus in standard popup menus.
Hierarchical menus are displayed with arrows
indicating that you must move to the right to view
lower-level menu selections. Large menus can cause
display problems.
Determines whether the field menus are expanded when
the menu is opened. The options are:
Yes—All levels of the menu are displayed when the
menu is opened.
No—Only the first level is displayed when the menu is
opened.
Pane Layout For BMC Remedy User only, defines position of the
Results List and the Details Pane. The options are:
Default—See Top.
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Flat Look On
Forms
Right—Results List on the right; Details Pane on the
left.
Left—Results List on the left; Details Pane on the right.
Top—(Default) Results List on the top; Details Pane on
the bottom.
Bottom—Results List on the bottom; Details Pane on
the top.
Clear—Results List on the top; Details Pane on the
bottom.
Designates whether forms have a flat or 3-D look. The
options are:
No—Use shadows to give the form a 3-D feel.
Yes—Do not use shadows. This gives the form a “flat”
appearance.
X X
Chapter 3 Setting user preferences 55
X
X
X
Web
client

BMC Remedy Action Request System 7.1.00
Display tab (BMC Remedy User only)
56 Configuring
The Display tab displays values you specify on the Display tab in the Options
dialog box for fonts associated with the following BMC Remedy User field types:
Edit Field Menu List Node
Push Button Menu List Leaf
Radio Button Header Text (I)
Option Field Header Text (II)
Required Field Header Text (III)
System Field Note Text
Results Pane Detailed Text
Query List
Figure 3-4: AR System User Preferences form—Display tab

Color tab (BMC Remedy User only)
AR System User Preference form fields
The Color tab displays colors associated with the following BMC Remedy User
window types:
New Customize View
Search Customize Field Default
Display Results List
Modify Dialog Window
Modify All
Figure 3-5: AR System User Preferences form—Color tab
In addition, the Use Background Color field designates whether the default colors
or the color codes defined on the Tools > Options tab are used to display BMC
Remedy User windows. The options are:
No—Default Color is selected on the Color tab in the Options window in BMC
Remedy User.
Yes—Color codes defined on the Color tab in the Options window in BMC
Remedy User are used to display windows.
Chapter 3 Setting user preferences 57

BMC Remedy Action Request System 7.1.00
Confirmation tab
58 Configuring
Figure 3-6: AR System User Preferences form—Confirmation tab
Group Name Field Name Description BMC
Remedy
User
Confirm After Creating
a New
Request
When
Deleting a
Report
When
Deleting a
Saved Search
When
Deleting a
Macro
Defines whether there is a confirmation after a new
request. The options are:
No—(Default) The entry is submitted without
verification.
Yes—A dialog box appears after the form is submitted
to verify the submitted entry and the entry ID.
Defines whether there is a confirmation when you
attempt to delete a report. The options are:
No—(Default) The report is deleted without
verification.
Yes—A dialog box appears when you attempt to delete
a report.
Defines whether there is a confirmation when you
attempt to delete a saved search. The options are:
No—(Default) The saved search is deleted without
verification.
Yes—A dialog box appears when you attempt to delete
a saved search.
Defines whether there is a confirmation when you
attempt to delete a macro. The options are:
No—(Default) The macro is deleted without
verification.
Yes—A dialog box appears when you attempt to delete
a macro.
X X
X
X
X
Web
client

Report tab
Figure 3-7: AR System User Preferences form—Report tab
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Default
Margins
Default
Separators
Default Page
Size
Left Margin
Right Margin
Top Margin
Bottom Margin
Column Titles
Column
Request
Defines the number of blank characters from the left
or right edge of the page. The default for the left and
right margin is 0 characters.
Defines the number of blank lines from the top or
bottom edge of the page. The default value for the
top and bottom margin is 1 line.
Defines the default characters to separate column
titles, columns, or requests, respectively. By default,
column titles are separated by hyphens (-), and
columns and requests are separated by a blank space.
You can use any of these special characters:
\b (backspace)
\n (return)
\t (tab)
\\ (backslash)
\ (ASCII character)
Note: You cannot use the Tab key to create tabs, but
you can use the special tab character to include a
tab in the separator.
Orientation Defines whether the default page is in Portrait or
Landscape mode.
Use printer
default page size
Designates whether the default page size should
correspond to the default printer page size.
X X
X X
X X
X X
X X
Web
client
Lines Per Page Designates how many lines of text are printed on
each page. The default value is 66.
X X
Chars Per Line Designates how many characters are printed on each
line. The default value is 80.
X X
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).
Chapter 3 Setting user preferences 59

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
Misc Default Column Title Per Designates a default value for how often column
titles appear in a report. The options are:
60 Configuring
6—Column titles appear for each request in the
report.
7—Column titles appear for each page in the report.
8—No default.
Page Break Per Designates a default value for how often page breaks
occur in a report. The options are:
6—Page breaks occur after each request in the
report.
7—Page breaks occur after each page in the report.
8—No default.
ODBCReportDot Indicates whether the ODBC driver should replace
the dot in Crystal Report field names. The options
are:
Enable Report to
Application
No—(Default) Do not replace the dot.
Yes—Replace the dot.
Indicates whether the Enable Report to Application
check box is selected on the Reports tab in the
Options window in BMC Remedy User.
X X
X X
N/A* N/A*
X
Web
client
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).

Logging tab
Figure 3-8: AR System User Preferences form—Logging tab
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Client Macro Designates whether use of macros on the client is logged. X
Active Links Designates whether use of active links on the client is
logged.
Extended Log Obsolete.
X X
Server API Designates whether use of APIs on the server is logged. X X
Filter Designates whether use of filters on the server is logged. X X
Database Designates whether activity on the database is logged. X X
Global Global
Logging
Enabled
Designates whether global logging is enabled. X
Log File Path Defines the path to the log file. X X
Web
client
Chapter 3 Setting user preferences 61

BMC Remedy Action Request System 7.1.00
Locale tab
62 Configuring
Figure 3-9: AR System User Preferences form—Locale tab
Group Name Field Name Description BMC
Remedy
User
Locale User Locale Designates the language displayed on the user’s system,
in the format _, where language is
the language code (such as fr for French or en for
English), and country is the two-letter country code (such
as FR for France or US for United States). Some sample
entries are:
Display Date/
Time Style
(BMC
Remedy User)
en_US—English (United States)
fr_BE—French (Belgium)
fr_CA—French (Canada)
zh_HK—Chinese (Hong Kong)
zh_CN—Simplified Chinese
ja_JP—Japanese (Japan)
Defines the format in which the date and time appear.
According to Windows format, the options are:
Short
Long
Custom
This setting is platform-independent and will not
automatically be the same as preferences set in BMC
Remedy User, or as any preferences set in the Windows
Control Panel. Use a predefined Windows format.
The default is Short.
X X
Time Zone
This field is clear by default.
Defines the time zone displayed on the user’s system.
Select a time zone from the menu, for example, Asia/
Tokyo, America/New York, or Europe/Paris.
Any ICU (International Component for Unicode) format
is accepted. This field is clear by default.
X
X
X
Web
client

File tab (BMC Remedy User only)
Figure 3-10: AR System User Preferences form—File tab
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Locale
(continued)
Custom Date/
Time Format
(BMC
Remedy User)
You can specify the conditions under which you want to upload and download
types of preference files to and from the preference server.
File types
You can specify options for downloading and uploading the following file types:
Macro
AR SystemReport
Crystal Report
Search
Defines the custom Date/Time length format. This field
is active only when Custom is selected from the Display
Date/Time Style menu list.
To customize separators and other options, use a
predefined Windows format or a customized Windows
format.
The EEE and EEEE day formats do not work in this field.
For example, if you enter EEEE, MMMM dd, yyyy, the
day of the week displays in BMC Remedy User as EEEE,
not the actual day (for example, Tuesday).
This field is clear by default.
Currency The type of currency to be applied for this locale (for
example, USD for United States dollars).
If currency is specified here, it overrides the
administrator-defined Initial Currency Type in the field
properties dialog box. If there is a default value for this
field, it overrides the User Preference and the Initial
Currency Type.
Chapter 3 Setting user preferences 63
X
X X
Web
client

BMC Remedy Action Request System 7.1.00
64 Configuring
Data File
Customize Default Field
See BMC Remedy User help for information about uploading and downloading
preference files.
Download actions
For each file type, you can specify the following actions for downloading:
On Login—Automatically download all files of the selected type when you log
in.
On Demand—Download files only when they have been accessed.
Manual—Manually download files, or download files of the selected type by
choosing Tools > Manage > Files > Download.
Upload actions
For each file type, you can specify the following actions for uploading and
downloading:
Immediate Save—Immediately upload the file after it is created or modified.
On Relogin or Exit—Automatically upload all files of the selected type when
you log in or exit.
Manual—Manually download files, or upload files of the selected type by
choosing Tools > Manage > Files > Upload.

Advanced tab
Figure 3-11: AR System User Preferences form—Advanced tab
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Form Default Form
View
Open
Window View
Extension
Display
Hidden Forms
(Admin)
Defines the view to be used as the default for all forms.
Ask your AR System administrator for the name you
should enter here, or leave this field blank.
Note: If you enter a view name that does not exist,
AR System determines which view best fits. This might
not be the default view.
Defines the extension to be used as the default for all
forms that are opened from other forms. Ask your
administrator for the name you should enter, or leave this
field blank.
Note: If you enter an extension that does not exist,
AR System determines which view best fits. This might
not be the default view.
Defines which forms are available. The options are:
No—Only those forms that have been designated as
visible are available.
Yes—All forms are available, whether designated as
hidden or visible.
Web
client
Note: This option is available only if you are logged in as
an administrator or subadministrator to an active
server.
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).
Chapter 3 Setting user preferences 65
X
X
X

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
Table Fields Refresh
Content on
Display
66 Configuring
Defines whether the data in a table field is refreshed
automatically every time a form is displayed.
Note: You can refresh the table manually by clicking on it
when you want to check for changes.
Report Report Server Defines the name of the server where the following
reporting forms reside:
ReportType
Preview
Report
Use this
program to
preview
ODBC Use
Underscores
ReportCreator
Report
ReportSelection
The server name also serves as the home for report
definition files created. This entry is necessary when the
server that stores the reporting forms is different from the
server that stores the data to be reported on. This field is
blank by default.
Specifies whether to preview reports in BMC Remedy
User or a different program you specify. The options are:
No—Displays reports in BMC Remedy User.
Yes—Display reports using the program specified in
the Report-Use this program to preview field.
Specifies the program to be used to preview standard
BMC Remedy User reports.
Defines whether to replace special characters with
underscores when running reports.
This is important if you are running Crystal Reports and
there are field names or form names in your reports that
contain special characters. Choose Yes to use
underscores.
Result View Alert Sort Displays the last column on which you sorted a result or
alert list. You can specify a value in this field.
Sort Criteria Displays the value set when you choose
Actions > Sort Options and specify values. You can set
sort options on a per-form basis.
AR System
Reserved
AR System
Reserved
X X
X X
Reserved for future use. N/A* N/A*
X
X
X
X
X
Web
client
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).

Home Page tab
Figure 3-12: AR System User Preferences form—Home Page tab
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Home Page AR Server Designates the name of the server on which your home
page resides.
For more information about configuring home page
preferences, see the Form and Application Objects guide.
Form Name Designates the name of the form to be used as the default
home page when the user logs in.
For more information about configuring home page
preferences, see the Form and Application Objects guide.
Object List Defines to what degree the Object List is enabled. X
Open Home
Page
Automatically
Enable, Show All—The Object List lists all the
applications, guides, and forms on the servers to which
you are logged in.
Enable, Show Only Entry Points—The Object List lists
only those entry points for which you have
permissions.
Disable—Access to the Object List is not possible. The
File > Open > Object List menu item and toolbar button
are disabled.
Controls whether the home page is opened automatically
after login to BMC Remedy User.
X X
X X
X X
Web
client
Chapter 3 Setting user preferences 67

BMC Remedy Action Request System 7.1.00
Alert tab
68 Configuring
Figure 3-13: AR System User Preferences form—Alert tab
Group Name Field Name Description BMC
Remedy
User
When I start
my computer
Auto start
AR System
Alert
On Startup Prompt For
Login (Alert
only)
Display Alert
Summary
Designates whether to start BMC Remedy Alert when
you start your computer.
Designates whether to prompt the user for login
information when Alert is started. The options are:
No—The user name and password you enter are saved
and used to log you in automatically the next time
BMC Remedy Alert is started.
Yes—You must enter your user name and password
each time you start BMC Remedy Alert.
Designates whether to display summary information
when Alert is started.
Web
client
N/A* N/A*
N/A* N/A*
N/A* N/A*
Listen Port Port Number Designates the port on which to listen for alerts. The
Listen Port is used in conjunction with Advanced Server
Properties settings in the Accounts dialog box to
configure BMC Remedy Alert to function outside of a
firewall.
N/A* N/A*
Logging Enabled
Logging
Designates whether logging should occur for Alert. N/A* N/A*
If Yes,
Logging Path
Designates the path and name of the log file.
By default, alert log files are stored with a .log file
extension.
N/A* N/A*
Misc OLE Timeout Designates how long the OLE Transaction Timeout is for
BMC Remedy Alert. OLE is used to open the Alert list in
BMC Remedy User.
N/A* N/A*
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).

Open Alert
List using
Designates which application should be used to open the
Alert List. The options are:
AR System User
Web
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
X X
Web
client
Server Designates the server to be used to open the Alert list. N/A* N/A*
On Startup Display Alert Designates whether to pop up alert information when N/A* N/A*
Message received.
Flash Icon Designates whether to flash the Alert icon when a new
alert is received.
N/A* N/A*
Beep Designates whether to beep when a new alert is received. N/A* N/A*
Play Wav File Designates whether to play a .wav file when a new alert
is received.
N/A* N/A*
Wav File Designates the .wav file to play if the P lay Wav File
option is set to Yes.
N/A* N/A*
Run Process Designates whether to run a process when a new alert is
received.
N/A* N/A*
Run Process Designates the process to run if previous option is set to N/A* N/A*
File
Yes.
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).
Chapter 3 Setting user preferences 69

BMC Remedy Action Request System 7.1.00
Recent tab
70 Configuring
Figure 3-14: AR System User Preferences form—Recent tab
Field Name Description BMC
Remedy
User
Recent Forms A list of recent forms opened in BMC Remedy User. X
Recent Tickets A list of recent requests opened in BMC Remedy User. X
Recent
Applications,
Guides, etc.
A list of recent applications or guides opened in BMC Remedy User. X
Recent Entry
Points
A list of recent entry points opened in BMC Remedy User. X
Web
client

Edit tab
Figure 3-15: AR System User Preferences form—Edit tab
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Table Field Table Field
Column
Width
Table Field
Column
Order
Table Field
Column Sort
Table Field
Refresh
Interval
Information about a table field that AR System saves X
when you change the size of columns in the table field,
including the server name, form name, table field ID,
column ID, and the size of the column.
Stores column order preference. X
Web
client
Not used. N/A* N/A*
The interval at which tables automatically refreshes (in
minutes). Valid values are 0–99.
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).
Chapter 3 Setting user preferences 71

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
Schema Column
Width
Column
Order
72 Configuring
Information about a results list that AR System saves
when you change the column size in a results list.
Information about a results list that AR System saves
when you change the order of columns in a results list.
Grid Height Parameter set in Customize View mode by choosing
Layout > Grid Size and specifying a value.
X
Grid Width Parameter set in Customize View mode by choosing
Layout > Grid Size and specifying a value.
X
App
Specifies whether to display extra field name and ID X
Development information in the field Help text. Values are:
Mode
1—Display the extra field information.
0—(Default) Do not display the extra field information.
Menu Position Menu window position. The options are:
Default—See Center.
Left—Left of where menu icon clicked.
X
Max Size Base
Menu
Items Per
Column
Center—(Default) Center of BMC Remedy User
window.
Right—Right of where menu icon clicked.
Screen Center—Center of screen.
The upper limit for the number of items a menu can have.
Used for currency and edit field menus.
X
Obsolete. N/A* N/A*
List Position List-menu window position. The options are:
Default—See Center.
Left—Left of where menu icon clicked.
Center—(Default) Center of BMC Remedy User
window.
Right—Right of where menu icon clicked.
Screen Center—Center of screen.
List Menu
Width
Width of the list menu window. X
List Menu
Height
Height of the list menu window. X
List Indent Space in pixels on left before list items in list menu. X
Items
Threshold
Level
Threshold
When smart menus is selected, the number of items
where menus change from popup to list menus.
When smart menus is selected, the number of levels
where menus change from popup to list menus.
X
X
X
X
X
Web
client
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).

Window tab
Figure 3-16: AR System User Preferences form—Window tab
AR System User Preference form fields
Group Name Field Name Description BMC Web
Remedy
User
client
Edit Diary Diary Width Diary editor window width. X
Field Diary Height Diary editor window height. X
Edit Text Field Text Width Text editor window width. X
Text Height Text editor window height. X
* N/A = The setting does not apply to BMC Remedy User or the web client. The setting applies to activities
such as logging or other clients (such as BMC Remedy Alert).
Group Name Field Name Description BMC
Remedy
User
Window Size Window
Position
Window
Workspace
Position
Pick/Selection
List
Window
Count
Obsolete. This parameter is included for backward X
compatibility only. If a value for this parameter is
specified from a previous version of BMC Remedy User,
it is converted to the Window Workspace Position
parameter and saved.
Used by BMC Remedy User to save information about X
how the window workspace is set up and how to restore
it. This value is set when the Save Window Workspace
option is selected.
Selection List window position. X
The number of New Search or New Request windows to
be opened when BMC User starts. This number is
updated when you select Save Windows Workspace
under Tools > Options > On Exit. The positions of these
windows are stored in the Window Workspace Position
field.
X
Web
client
Chapter 3 Setting user preferences 73

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
Toolbars Summary Coded information about toolbars. X
Misc tab
74 Configuring
Bar0 Coded information about toolbars. X
Bar1 Coded information about toolbars. X
Bar2 Coded information about toolbars. X
Bar3 Coded information about toolbars. X
Figure 3-17: AR System User Preferences form—Misc tab
Group Name Field Name Description BMC
Remedy
User
Open Dialog Placement Coded location of the File > Open > Object List menu
option in BMC Remedy User.
X
Active Page Current tab in File > Open > Object List menu option in
BMC Remedy User.
X
Shortcut Dir Indicates the directory to use when creating a shortcut.
This value is used when you select an item from the Open
Object List and right-click to create a shortcut or when
you right-click a results list and choose Send To >
Desktop.
X
&All
&Find
Fa&vorites
&Recent
Coded column widths of All, Find, Favorites, and Recent
that appear when you choose the File > Open > Object
List menu option in BMC Remedy User.
Fi&nd Not currently used.
X
Web
client
Web
client

Performance These preferences relate to how BMC Remedy User
caches forms. Definitions (form and related workflow)
are loaded into memory from the .arf and .arv cache files
and retained as long as these files are current. This allows
subsequent loads of the same form to load more rapidly
since the definitions do not have to be re-read from the
disk each time.
To reduce the amount of memory being used, several
checks are made periodically to see if definitions can be
removed from the memory cache. During these checks,
the following calculation is performed:
Duration Since Last Used =
Current Time - Time Definition Last Used
Max Age In
Minutes
Min Age In
Minutes
Usage
Threshold
Percent Of
Memory
App Response
Timeout
Transaction
Timeout
RPC Timeout
Normal
RPC Timeout
Long
RPC Timeout
Extra Long
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
If the Duration Since Last Used value is greater than the X
preference set for Max Age In Minutes, the form
definition can be removed from the memory cache.
If the Duration Since Last Used value is greater than the X
preference set for Min Age In Minutes, the form
definition can be removed from the memory cache.
If the system is approaching the memory limit (Percent of
Memory), the Duration Since Last Used value is taken in
conjunction with the Min Age In Minutes value to
determine whether the definition can be removed from
the memory cache.
Each time a form is opened, the system increments a X
usage count. As the memory limit is approached, the
Usage Threshold value is compared to the usage count to
determine if the definition can be removed from the
memory cache.
This value represents a memory threshold. It is compared X
to the percent of memory being used for the memory
cache to determine if the memory limit is reached. This
check is used in conjunction with the Usage Threshold
and the Min Age In Minutes values.
DDE Application Response Timeout in BMC Remedy X
User.
DDE Transaction Timeout in BMC Remedy User. X
RPC Timeout for submits in BMC Remedy User. X
RPC Timeout Long queries in BMC Remedy User. X
RPC Timeout for extra long operations in BMC Remedy
User.
Chapter 3 Setting user preferences 75
X
Web
client

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
View Show Macro
Bar
Show Status
Bar
76 Configuring
Designates whether the macro bar is displayed when
BMC Remedy User starts.
Designates whether the status bar is displayed when
BMC Remedy User starts.
Show Toolbar Designates whether the toolbar is displayed when BMC
Remedy User starts.
Disable Web
Help
Save Window
On Close
Query On
Return
Close After
Submit
Show Lang
DLL Not
found
Step Size Obsolete.
Result Open
On Double-
Click
Designates whether items under BMC Remedy on the Web
under the main Help menu in BMC Remedy User are
disabled.
Designates whether to save information about open New
and Search windows in BMC Remedy User when you
close the tool.
Designates whether you can initiate a query by pressing
the ENTER key in the Request ID field.
Designates whether to close a New window after submit
in BMC Remedy User.
Obsolete.
Designates which panes open when you double-click a
record in a results view. The options are:
Value greater than zero—Open the form with a results
pane and a detail pane.
0 (Zero)—Open the form with only a detail pane.
X
X
X
X
X
X
X
X
Web
client

Web tab
Figure 3-18: AR System User Preferences form—Web tab
AR System User Preference form fields
Group Name Field Name Description BMC
Remedy
User
Report Crystal Report
Viewer
Alert Refresh
Interval
Designates an application for viewing Crystal Reports.
The options are:
Java (using browser JVM)
Java (using Java Plug-in)
ActiveX
Netscape Plug-in
HTML with frames
HTML without frames (the default)
Clear (The system takes the default value that the
administrator sets.)
Defines the interval, in minutes, that passes between
queries to the Alert Events form. The default value is 0.
The alert list displays the user’s alerts by querying the
Alert Events form that contains the user’s alerts.
Alert Servers Defines which servers contribute alerts to a web-based
alert list. The administrator can enter the server names to
retrieve alerts from this field. The server names must be
separated by the comma ( , ) delimiter.
This field is clear by default.
Web
client
Chapter 3 Setting user preferences 77
X
X
X

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description BMC
Remedy
User
Date/Time
Text
78 Configuring
Display Date/
Time Style
(Web)
Custom Date
Format
Custom Time
Format
Defines the format in which the date and time appear.
The options are:
Short
Long
Custom
The formats adhere to the ICU (International Component
for Unicode) format.
The format is platform-independent and will not
automatically be the same as preferences set in BMC
Remedy User, or as any preferences set in the Windows
Control Panel. Use a predefined ICU format or customize
an ICU format to set web view Date/Time appearances.
The default is Short.
If you select Custom from the Display Date/Time Style
(Web) menu, select the format of date strings to be
displayed in your browser. You can add a forward slash
(/), dash (-) or a
period (.) as separators. This field is clear by default.
For more information about date formats, see Appendix
D, “Date and time formats.”
If you select Custom from the Display Date/Time Style
(Web) menu, select the format of time strings to be
displayed in your browser. You can add a semicolon (:),
dash (-), or a period (.) as separators. This field is clear by
default.
For more information about time formats, see Appendix
D, “Date and time formats.”
Web
client
X
X
X

Accessibility Accessible
Mode
Designates whether an accessible mode applies to the
current view and if so, which mode. The options are:
Default—No accessible mode used.
Setting centralized preferences on web clients
Group Name Field Name Description BMC
Remedy
User
Accessible
Message
Session Session
Timeout in
Minutes
Screen Magnifier/Low Vision—View is accessed with
a screen magnification device. Use the magnifier
supplied with your operating system.
Screen Reader/No Vision—View is accessed using
screen reader software.
This field is clear by default.
Designates the type of nonvisual feedback that applies to
workflow for this view. The options are:
No Action—No messages are shown for accessibility.
Active link message actions of the type Accessible are
ignored.
Message Action—Displays accessibility messages
defined by the active link message action of type
Accessible.
All Actions—Displays accessibility messages to reflect
visual changes on the page as well as accessible
messages defined by an active link message action of
the type Accessible.
Accessibility messages are displayed for visual
changes caused by Change Field and Set Field active
link actions, and other user actions such as table
refresh. These messages reflect the visual changes that
the user would have experienced otherwise.
If a field is hidden, changes caused by these actions are
ignored.
Note: These options are not used in the BMC Remedy Mid
Tier 6.3 and later.
Designates the number of minutes after which a session
times out. The default is 90 minutes.
You can set the session timeout for longer than 90
minutes for a specific user, and this setting will override
the session timeout in the General Settings page of BMC
Remedy Mid Tier Configuration Tool.
X X
Web
client
Setting centralized preferences on web clients
Web client users can set preferences by opening the AR System User Preference
form and submitting changes. For information about the User Preference form on
the web, see the Installing and Administering BMC Remedy Mid Tier guide.
Chapter 3 Setting user preferences 79
X

BMC Remedy Action Request System 7.1.00
80 Configuring

Chapter
4 Defining
your user base
This section provides instructions for managing information about your
AR System users. The following topics are provided:
Licensing users (page 82)
Viewing user information (page 83)
Releasing floating licenses (page 85)
License pools (page 86)
Adding and modifying user information (page 86)
User form permissions (page 92)
Allowing guest users (page 93)
Special submitter mode (page 94)
Validating password information (page 94)
Enforcing a password policy (page 95)
Setting up an authentication alias (page 102)
Unique user logins (page 106)
Chapter 4 Defining your user base 81

BMC Remedy Action Request System 7.1.00
Licensing users
License types
82 Configuring
When creating users, you must assign a license type to each user. The type of
license a user has determines the user’s ability to access AR System objects and to
perform tasks.
There are four kinds of licenses you can use to access the AR System server: read,
restricted read, fixed write, and floating write. With the exception of restricted read
licenses, users can access AR System from only one computer at a time. AR System
uses a globally unique identifier (GUID) to identify the computer, so you do not
need to log in again if your IP address changes during a session. After you have
logged out of one machine, you might need to wait a short time to make sure your
status is cleared before using the same login name to access another machine.
A user who is blocked from access can perform a license take-over through a
message dialog box. This was added to address instances where someone forgets
to log off a client at a different location. Only one license take-over is allowed every
fifteen minutes for all users on the system.
The following table summarize the important license elements as they relate to
access control.
License type Description
Read Enables users to search and display existing requests. Administrators
can configure the AR System server to enable users to submit new
requests and modify or save data in existing requests. (See “Special
submitter mode” on page 94.)
Restricted Read Allows users to search the AR System forms and submit new requests
but does not allow users to modify existing requests under any
conditions. It does, however, allow the same login account to access
the AR System from multiple IP addresses simultaneously, such as
when browsing a knowledge base or completing on-line surveys.

Viewing user information
Viewing user information
License type Description
Fixed Write Includes all the capabilities of a Read license, and also enables users
to modify and save data for existing requests based on the groups to
which the user belongs. AR System administrators and
subadministrators must have a Fixed Write license. Other AR System
users who consistently need to modify requests must also have Fixed
Write licenses.
A user cannot be assigned the same Fixed Write license more than
three times in one week. If this limitation is exceeded, the user must
wait one week from the first assignment of the Fixed Write license
before it can be assigned again.
Floating Write Includes all the capabilities of a Read license, and also enables users
to modify and save data for existing requests based on the groups to
which the user belongs. Floating Write licenses can be used by
multiple users, one user at a time. This type of license is designed for
users who occasionally need to modify and save data for existing
requests.
The Manage User Licenses form displays information about the registered and
current users on the selected server.
The registered user information displayed in the Manage User License window is
the information that was submitted for each user in the User form. See “Adding
and modifying user information” on page 86 for more information.
To display user license information
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > Application > Users/Groups/Roles > License Review.
The Manage User Licenses form appears.
Chapter 4 Defining your user base 83

BMC Remedy Action Request System 7.1.00
84 Configuring
Figure 4-1: License information
2 From the Users Category list, select one of the following options:
Server - Current Users— For each user currently connected to AR System
through an AR System license, displays the name of the user, the type of
AR System license assigned, the connect time during the current session, the
time that the user last accessed the server during this session, and the floating
write license pool.
Server - Registered Users—For all users known to AR System with an
AR System license, displays the name of the user, the type of AR System license
assigned, the default notification mechanism, and the email address.
Server - Invalid Users—Displays the number of users who are locked out of
BMC Remedy User because of too many bad password attempts. To reset an
invalid account, reset the user’s password.
To set a maximum number of bad passwords, enter the number in the Max
Number of Password Attempts field in the AR System Administrator form. To
turn the feature off (unlimited number of bad passwords allowed), set the
number to 0 (the default).
You can also check for invalid users by using the driver with the glu command.
Application - Current Users—For each user currently connected to AR System
through an Integration System Vendor (ISV) license, displays the name of the
user, the type of AR System license assigned, the connect time during the
current session, the time that the user last accessed the server during this
session, and the floating write license pool.
Application - Registered Users—For all users known to AR System with an
Integration System Vendor (ISV) license, displays the name of the user, the type
of AR System license assigned, the default notification mechanism, and the
email address.

Releasing floating licenses
3 From the License Type list, select the license type for the category of users you
want to view.
The Write License Pool column shows the name of the current group (pool) from
which the user’s Floating Write license has been acquired. At another time, if a
license has been acquired from a different pool to which the user belongs, that pool
name is displayed.
4 Click Close.
Releasing floating licenses
Users who work with a floating license are subject to a time-out interval, which
determines the amount of time before the floating license is released automatically
when the user does not perform any actions against the server.
Administrators can terminate a user’s session only one time in a 24-hour period.
To release a floating license
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > Application > Users/Groups/Roles > License Review.
The Manage User Licenses form appears.
2 From the Category option list, select Current Licenses.
3 From the License Type list, select Floating.
A list of users with the selected license type appears.
4 From the list of active users, select the appropriate user.
5 Click Release User.
The license token held by that user is released. Another user can take the token and
start working. If the original user returns, the user cannot get back into the system
if no “tokens” are available.
NOTE
If you release a Fixed or Read license, this procedure removes the user from the list
of current users; there is no effect on the user’s ability to connect to the server. The
next time the user accesses the server, the user’s license information reappears.
6 Click Close.
Chapter 4 Defining your user base 85

BMC Remedy Action Request System 7.1.00
License pools
86 Configuring
A license pool consists of a number of floating licenses reserved for a group,
subject to the number of floating licenses available in the database. When a
member of a group logs in, a license from the license pool for that group is granted.
When the user has finished with the license, it is released back into the pool.
If there are no licenses available in the pool, a check is made to see if the user is a
member of any other group that has a license pool. If there are no licenses available
in any pool the user is a member of, a check is made for floating licenses not
associated with any pool. A user is never granted a floating license from a pool of
which he is not a member.
License pools allow you to give priority to a group that needs licenses more
urgently. The group with the smallest group ID has the highest priority. When a
non-reserved floating license becomes available, it is granted to the next user who
needs it, regardless of the priority of that user’s access to the system.
You specify the number of licenses reserved for a group in the Group form in BMC
Remedy User. For more information about User groups, see the Form and
Application Objects guide and “Adding and modifying user information” that
follows.
Adding and modifying user information
IMPORTANT
If you use AR System–based applications, set up users in each application’s People
form, not in the AR System User form. For more information, see the application
documentation.
In AR System, you can have registered users and guest users. Each type of user has
different privileges within the system, as is discussed in the following sections.
You enter data in the User form to define the components that work together to
determine each user’s access to AR System: login name, password, group
membership, and license type. You also define alert information for each user in
this form.
To grant a user permission for AR System objects, add the user to the groups to
which access will be given. To make a user part of a group, choose the appropriate
group from the Group List menu in the User form. (Multiple group names in the
Group List field are separated by spaces.) You can select from the reserved
AR System groups. For more information about groups, see the Form and
Application Objects guide.

Figure 4-2: User form in new mode
Adding and modifying user information
Chapter 4 Defining your user base 87

BMC Remedy Action Request System 7.1.00
88 Configuring
The following table lists the key fields in the User form.
Group Field Description
User
Information
Login Name Identifying name that the user enters into the User Name field when
logging in to AR System. The name can be the same or different than
the user name by which this user is known to the underlying operating
system.
The dynamic group with an ID of 60988 has read access to this field,
enabling the user to view this field if a password policy is established.
For more information, see “Enforcing a password policy” on page 95.
Full Name Full name of the user.
Password Identifying password that the user enters when logging in to
AR System. This field is limited to 29 characters.
The Password field is encrypted into the database using a one-way
hash (SHA1), so unauthorized users cannot retrieve passwords in clear
text, for example, to log in to applications. To enhance system security,
select a password that is different from one used for another purpose.
If unsecure passwords are needed for applications, store the password
in a character field rather than the Password field (field 102).
If the password field is left blank, the AR System server will not
validate the password with the user’s Windows or UNIX ® password,
unless you configure the server to cross-reference a blank password.
For more information, see “Cross Ref Blank Password” on page 149.
The dynamic group with an ID of 60988 has read access to this field,
enabling the user to view this field if a password policy is established.
For more information, see “Enforcing a password policy” on page 95.
Group List Lists the access control groups to which the user belongs. If you leave
this field empty, the user will have only basic Submitter, Assignee,
Assignee Group, or Public permissions. Specify groups by name or ID,
as defined in the Group form, when entering groups in the Group list.
User permissions are determined in the Group List field of the User
form. If you later change the Group ID for a group, the users originally
assigned to the group are still attached to the old ID. If there is no group
with the old ID, these users lose access to any AR System object for
which they do not have permission through another group.
This field is limited to 4000 bytes, including expanded strings.

Group Field Description
User
Information
(continued)
Computed
Group List
Adding and modifying user information
Displays the name of any computed group to which the User is a
member. The members of a computed group are calculated by the
server based on the groups that the User belongs to. This is a displayonly
field, and the field ID is 121.
To search in this field in a query-by-example, enter the ID number of a
computed group in the Computed Group List field. In the following
examples:
The ID for Computed Group 1 is 5678
The ID for Computed Group 2 is 6789
To enter more than one computed group ID, include semicolons after
each ID. You must enter the computed group IDs in the same order in
which the names appear in the Computed Group List field when the
user’s record is displayed.
You can also use the Advanced Search bar with the LIKE operator.
Include the semicolon with the complete ID.
To search for users who are members of Computed Group 1, enter:
‘Computed Group List’ LIKE “%5678;%”
You can also enter a partial ID for the computed group. To search for
users who are members of both Computed Group 1 and Computed
Group 2, enter:
‘Computed Group List’ LIKE “%56%” AND ‘Computed Group
List’ LIKE “%89%”
Full Name Full name of a user. By default, this name appears in the Results pane
of the User form when users perform a search operation.
License Type Type of license that the user is assigned: Read, Restricted Read, Fixed,
or Floating. The default is Read. See “License types” on page 82 for
further descriptions of these types.
Full Text License
Type
Application
License
Default Notify
Mechanism
Type of full text search license that the user has: None, Fixed, or
Floating. The default is None.
For more information about the full text search feature, seeChapter 9,
“Using full text search.”
List of application licenses granted to the user. For example, BMC
Change Mgmt User Fixed, where BMC Change Mgmt is the name of the
application and User Fixed is the type of license. AR System
automatically populates this field according to information entered in
the application’s People form.
Note: To use AR System–based applications from BMC Software, you
need an AR System user license (to access the AR System server) and
an application user license (to access the application).
Method by which the user is notified for Notify filter and escalation
actions when User Default is specified. The default setting on the User
form is Alert.
Email Address Email address used to notify the user if email is the notify method.
Instance ID Field used with BMC Remedy applications. Do not delete this field.
Chapter 4 Defining your user base 89

BMC Remedy Action Request System 7.1.00
Group Field Description
Password
Management
90 Configuring
Disable
Password
Management For
This User
Dynamic Group
Access
Last Password
Change for
Policy
Account
Disabled Date
Force Password
Change on Login
Number of Days
Before
Expiration
Number of
Warning Days
Days After
Expiration Until
Disablement
Disables password management for the user.
If this check box is selected, when the User Password Management
Configuration form is updated, the user will not be affected.
For more information about password management, see “Enforcing a
password policy” on page 95.
The dynamic group to which the user belongs.
The last time the password was changed. AR System automatically
updated this field when a user’s password is changed.
The date the account was disabled, if applicable.
Indicates that the user must change the password. The next time the
user logs in, the user is prompted to change the password.
After the password is changed, the check box in the User form is
automatically cleared through workflow.
The numbers of days before a user’s password will expire if it is not
changed.
Indicates when a user will receive a warning message before the
password is set to expire unless changed.
The number of days after which a user’s account will be disabled if the
password is not changed.
Use the following procedures to create, modify, or delete AR System users and to
allow users to change their information.
You can apply the three Fixed Write licenses included with AR System to new
users.
To create new users
1 Log in to BMC Remedy User or a browser.
Enter your user name and password into the Login dialog box, and click OK.
If you are the first administrator to log in, you must log in as Demo and leave the
password field empty. (AR System user names are case-sensitive, which means
that you must type Demo, not demo or DEMO.)
During initial installation, the Demo user is installed without a required password.
To keep AR System secure, add a password for this user as soon as possible.
2 From the AR System Administration Console, click System > Application > Users
/ Groups / Roles > User.
The User form opens in Search mode.
3 Choose Actions > New to switch to New mode.

Adding and modifying user information
4 Enter information in the appropriate fields, as described in the previous table.
5 Save your changes.
If adding the user causes you to exceed your license limit, an error message
appears.
To modify user information
1 From the AR System Administration Console, click System > Application > Users
/ Groups / Roles > User.
The User form opens in Search mode.
2 Click Search to retrieve a list of currently defined users.
3 Select the appropriate user from the list.
4 Modify information in the appropriate fields.
5 Save your changes.
WARNING
Do not modify the Demo user’s Fixed Write license or Administrator group
membership until you have created another Administrator user first, or you will
lose administrator privileges.
To delete users
1 From the AR System Administration Console, click System > Application >
Users / Groups / Roles > User.
The User form opens in Search mode.
2 Click Search to retrieve a list of currently defined users.
3 Select the appropriate user from the list.
4 Choose Actions > Delete.
A confirmation box appears to verify that you want to delete the selected users.
5 Click OK.
WARNING
Do not delete the Demo user until you have created another Administrator user
first, or you will lose administrator privileges.
To allow users to change user record information
1 In BMC Remedy Administrator, make the User form’s Assigned To field visible.
(By default, the field is hidden.)
a Double-click the Assigned To field to open the field Properties dialog box.
b In the Display tab, clear the Hidden check box.
2 In the User form, give the Assignee group Change permission for the Password,
Default Notify Mechanisms, or Email Address fields.
Chapter 4 Defining your user base 91

BMC Remedy Action Request System 7.1.00
92 Configuring
3 In the User form, give public “visible” permissions.
For information about defining field properties and field permissions, see the Form
and Application Objects guide.
4 Save your changes.
5 Log in to BMC Remedy User or the web client as an administrator.
6 From the AR System Administration Console, click System > Application >
Users / Groups / Roles > User.
The User form opens in Search mode. The Assigned To field is visible in the User
form.
7 Retrieve a list of currently defined users.
8 Select the appropriate user from the list.
9 In the User form, copy the Login name to the Assigned To field to make the user
the Assignee.
By using the Assignee group, you allow the user to modify the user’s password,
default notification mechanism, or email address.
You can also make the user the Submitter by entering the same name in the Login
name field and in the Creator field.
10 Save your changes.
User form permissions
Prior to version 7.1 of AR System, only the Administrator group had access to the
form. In version 7.1 and later, the following changes were made:
The Public group has Hidden permission to the User form.
The Dynamic Group Access field on the User form gives users read permission
to the following fields: Login Name, Password, and Request ID. These
permissions are automatically given to all new users that the administrator
creates.
If you are upgrading to 7.1 or later from a previous version, be aware of these
permission changes. If you have customized the User form, these changes may
affect your customizations.
These changes enable you to enforce a password policy. For more information, see
“Enforcing a password policy” on page 95.

Allowing guest users
Allowing guest users
AR System includes a setting that enables you to permit users who are not
recognized users (that is, not listed in the User form) to have access to BMC
Remedy User as a member of the Public Group. Allowing guest users can involve
as many as three settings, depending on whether you want the user only to log in
to BMC Remedy User or also to submit new requests and modify existing requests
for which the guest user is the original submitter.
To allow guest users
1 From the AR System Administration Console, click System > General > Server
Information.
2 In the AR System Administration: Server Information form, click the
Configuration tab.
3 Select the Allow Guest Users check box.
The guest user can log in to BMC Remedy User and access all the AR System
objects for which the Public group has permission.
4 Click OK.
5 To allow the guest user to create new requests, complete the following steps for
each field in which you would expect a value to be supplied:
a Open the form in BMC Remedy Administrator.
b Double-click the field to open the Field Properties window.
c Click the Permissions tab.
d Select the Allow Any User to Submit check box.
The guest user can assign a value to the field even though the guest user does
not belong to a group with Change permission for the field.
e Save your changes.
6 To enable guest users to modify an existing request for which they are the
submitter (in the Submitter field), complete the following steps:
a Open the AR System Administration: Server Information form.
b Click the Licenses tab.
c From the Submitter Mode option list, select Locked.
The guest user can modify all existing requests, where the guest user is the
original submitter, without a write license for fields that have Change access for
the Submitter group. For more information about the special submit setting, see
the “Special submitter mode” on page 94.
d Click OK.
e Restart the AR System server.
Chapter 4 Defining your user base 93

BMC Remedy Action Request System 7.1.00
Special submitter mode
94 Configuring
AR System contains a setting that allows users to modify requests that they
initially submitted even if they do not have a write license. To enable this feature,
set the Submitter Mode option to Locked in the Licenses tab of the AR System
Administration: Server Information form.
Figure 4-3: Setting Submitter Mode on the Licenses tab
The Submitter Mode options are:
Set Submitter Mode to
Locked.
Locked—Allows users who have their name in the Submitter field to modify
requests without a write license. This does not apply to users with a Restricted
Read license who cannot modify requests under any circumstances. In the
locked submitter mode, after the entry is submitted, the value in the Submitter
field cannot be changed.
Changeable—Requires users to have a write license to change any record,
including requests for which they are the submitter.
Validating password information
The AR System server can validate the password entered by the user against their
Windows or UNIX login password instead of maintaining a password that is
AR System specific. To allow this, you must:
Make sure that the AR System user name and the operating system user name
are identical. Leave the Password field in the User form blank. (See the column
“Field” on page 88.)
If you are using Authentication aliases (as described in “Setting up an
authentication alias” on page 102), the Login name alias should be identical to
the operating system user name.
Select the Cross Ref Blank Password check box in the Configuration tab of the
the AR System Administration: Server Information form. (For more information
about password configuration, see “Server information—Configuration tab” on
page 118.)

Enforcing a password policy
Where supported, the operating system password validation feature enables the
operating system to set the following password policies (which are not covered by
the AR System password manager):
Aging—Determines how quickly a password expires.
Lockout periods—Limits the number of incorrect logins a user can enter before
getting locked out.
Length—Sets a consistent password length.
Enforcing a password policy
You can enforce a password policy with the User Password Management
Configuration form.
Figure 4-4: User Password Management Configuration form
NOTE
If you are upgrading from a version prior to 7.1.00, note the changes to the User
form, as described in “User form permissions” on page 92.
The password management feature is preconfigured when you install AR System,
but it is not enabled. This section describes how to enable and use the feature.
Chapter 4 Defining your user base 95

BMC Remedy Action Request System 7.1.00
96 Configuring
With a password policy, you can:
Force all users or individual users to change their passwords when they use
BMC Remedy User or a browser
Enforce restrictions on passwords (HIPAA standards are shipped as the default
restrictions.)
Set up password expiration with scheduled warnings
Disable an account after the expiration period
Enable users to change their passwords at will
IMPORTANT
If your system uses external authentication (through the Cross Ref Blank Password
option), be careful if you enforce password policy with the User Password
Management Configuration form. The policy should be enforced only for users
whose passwords are stored in the AR System User form.
If you enable the policy and have users who are externally authenticated, disable
the policy for the externally authenticated users as described in “To disable
password management for individual users” on page 98.
For information about the Cross-Reference Blank Password feature used with
external authentication, see “Cross Ref Blank Password” on page 149.
Setting up the mid tier for the password policy
If you are running on a mid tier, use the BMC Remedy Mid Tier Configuration Tool
to set an authentication server for the mid tier, and set up the policy on that server.
To set the authentication server, open the BMC Remedy Mid Tier Configuration
Tool, and click the General Settings link. Then, enter the server in the
Authentication Server field.
Forcing users to change their passwords
With the Enforce Policy and Restrictions check box in the User Password
Management Configuration form, you can force all users to change their
passwords according to the policy you set up.
To force all users to change their passwords
1 From the AR System Administration Console, click System > General > Password
Management Configuration.
2 In the User Password Management Configuration form, select the Enforce Policy
and Restrictions check box if it is not already selected.

Enforcing a password policy
3 Complete the fields in the Enforcement Policy and Restrictions sections.
For more information about these fields, see:
“Enforcing restrictions on passwords” on page 98
“Setting up password expiration with scheduled warnings” on page 101
“Disabling an account after the expiration period” on page 101
4 Click Save.
All users are forced to change their passwords at their scheduled expiration date.
When users change their passwords, they must enter the old password once and
the new password twice.
To force newly created users to change their passwords
1 From the AR System Administration Console, click System > General > Password
Management Configuration.
2 In the User Password Management Configuration form, select the New User Must
Change Password check box.
3 Click Save.
Now, when you create a new user, the first time a user logs in, the user will be
prompted to change the password.
To force individual users to change their passwords
1 From the AR System Administration Console, click System > Application > Users
/ Groups / Roles > User.
The User form opens in Search mode.
2 Click Search to retrieve a list of currently defined users.
3 Select the appropriate user from the list.
4 Modify the Password Management fields, as needed.
For more information about the User form, see “Adding and modifying user
information” on page 86.
5 Select the Force Password Change on Login check box.
6 Click Save.
NOTE
Changes in the User form take precedence over the configuration settings in the
User Password Management Configuration form. If you make changes to the User
form and you want the user to use the global password management policy (as
configured in the User Password Management Configuration form), see “To revert
an individual user to global password management settings” on page 98.
If you change the policy User Password Management Configuration form, changes
in the User form are overwritten.
Chapter 4 Defining your user base 97

BMC Remedy Action Request System 7.1.00
98 Configuring
To disable password management for individual users
1 From the AR System Administration Console, click System > Application > Users
/ Groups / Roles > User.
The User form opens in Search mode.
2 Click Search to retrieve a list of currently defined users.
3 Select the appropriate user from the list.
4 Select the Disable Password Management For This User check box.
5 Click Save.
To revert an individual user to global password management settings
1 From the AR System Administration Console, click System > Application > Users
/ Groups / Roles > User.
The User form opens in Search mode.
2 Click Search to retrieve a list of currently defined users.
3 Select the appropriate user from the list.
4 Clear all the Password Management fields on the form.
5 Click Save.
Enforcing restrictions on passwords
By default, the password management policy uses workflow to enforce HIPAA
rules for new passwords. You can use the default restrictions, add further
restrictions, or disable the default restrictions and use your own.
The HIPAA rules include the following restrictions:
Blank passwords are not allowed.
The password cannot match the login name.
The user cannot use the old password when changing the password.
The password cannot be a dictionary word, which is achieved by the following
rules:
Must be a minimum of eight alphanumeric characters
Must include at least one uppercase alphabetic character.
Must include at least one lowercase alphabetic character.
Must include at least one non-alphanumeric (special) character.

Other restrictions include:
Enforcing a password policy
The administrator must be able to change the password at any time.
Users (except for the administrator and the password’s user) cannot change the
password. This is accomplished through the Dynamic Group Access field (ID
60988) on the User form.
The account is disabled if the user has not changed the password after the
number of days specified in the “Days after force change until disablement”
field in the User Password Management Configuration form.
Setting up password restrictions
1 From the AR System Administration Console, click System > General > Password
Management Configuration.
The User Password Management Configuration form appears.
2 To disable the default HIPAA character restrictions, select the Disable Default
Character Restrictions check box.
This check box disables the default HIPAA character restrictions regarding nonalphanumeric
characters and case-sensitivity. If the check box is selected, users can
enter any characters in the Password field, except for characters that are restricted
according to what you enter in the Restrictions Qualifier field.
Length restrictions are still enforced, but you change them withe Minimum Length
field as described in the following step.
3 Complete the following fields in the Restrictions section.
Minimum Length—Sets the minimum length the user must enter when
changing a password. You can enter a length of 1 through 30; the default is 8.
Restrictions Qualifier—Specifies restrictions in addition to the default HIPAA
restrictions. For example, to force users to include a number in their password,
enter:
'New Password' LIKE "%(0-9)%"
If the default HIPAA restrictions are enabled, you can add more restrictive
qualifications, but your restrictions cannot contradict the default restrictions. If
you want less restrictive rules, disable the default HIPAA restrictions. In
summary, you can enforce restrictions in any of the following ways:
Use the default restrictions—Do not enter a qualification in the Restrictions
Qualifier field.
Use the default restrictions, but refine them further—Simply enter a
qualification in the Restrictions Qualifier field.
Replace the default restrictions with your own custom restrictions—Select
the Disable Default Character Restrictions check box and enter a qualification
in the Restrictions Qualifier field.
Remove the default restrictions, and allow users to enter any combination
of characters—Select the Disable Default Character Restrictions check box
and do not enter a qualification in the Restrictions Qualifier field.
Chapter 4 Defining your user base 99

BMC Remedy Action Request System 7.1.00
100 Configuring
For more information, see “Examples of qualifications for the Restrictions
Qualifier field” on page 100.
Failure Message—Specifies the message if a password is entered that does not
qualify against the restrictions set.
4 Click Save.
Examples of qualifications for the Restrictions Qualifier field
If the Disable Default Character Restrictions check box is not selected, the qualifier
entered in the Restrictions Qualifier field is appended to the current default
restriction. However, you cannot change the qualifier that is already defined in the
default qualifier, which enforces that the password must include at least one
lowercase or uppercase letter and a special character.
Example 1
To add a restriction requiring users to include a number in their password, enter
the following qualification in the Restriction Qualifier field:
'New Password' LIKE "%[0-9]%"
This qualifier is appended to the default qualifier. With this restriction, aA1#,
aa1#, and AA1# are acceptable passwords if the minimum length for password is
4.
Example 2
To remove the restriction of requiring a lowercase letter, enter the following
qualification:
('New Password' LIKE "%[0-9]%") AND ('New Password' LIKE "%[^a-z]%")
A password like AA1# is valid.
Example 3
The following qualification would not work because you cannot invalidate the
default qualifier, which requires a letter in the password.
('New Password' LIKE "%[^A-Z]%") AND ('New Password' LIKE "%[^a-z]%"
If the Disable Default Character Restrictions field is selected, the default qualifier
is ignored. The qualifier entered in the Restrictions Qualifier field is the only
qualifier that is used.
Example
To force users to include numbers in their password, enter the following
qualification in the Restrictions Qualifier field:
'New Password' LIKE "%[0-9]%"
With this restriction, 1111 is an acceptable password if the minimum length is 4.
A password without any numbers (such as aaaa) would cause an error.

Enforcing a password policy
Setting up password expiration with scheduled warnings
You can control when a password will expire and how many days before the
expiration that users are warned.
To set up password expiration with scheduled warnings.
1 From the AR System Administration Console, click System > General > Password
Management Configuration.
The User Password Management Configuration form appears.
2 Complete the following fields in the Enforcement Policy section.
Number of Days Before Expiration—Indicates the numbers of days before a
user’s password will expire if it is not changed.
Number of Warning Days—Indicates when a user will receive a warning
message before the password is set to expire unless changed.
3 Click Save.
NOTE
You can perform this function in the User form for individual users. For more
information, see “Adding and modifying user information” on page 86.
Disabling an account after the expiration period
If a user does not change his or her password before a specified time, you can
disable that user’s account.
To disable a user’s account through the password policy
1 From the AR System Administration Console, click System > General > Password
Management Configuration.
The User Password Management Configuration form appears.
2 In the Days After Expiration Until Disablement field, enter the number of days
after which a user’s account will be disabled if the password is not changed.
3 Click Save.
NOTE
You can perform this function in the User form for individual users. For more
information, see “Adding and modifying user information” on page 86.
Chapter 4 Defining your user base 101

BMC Remedy Action Request System 7.1.00
Enabling users to change their passwords at will
102 Configuring
A Change Password link is automatically placed on the Home Page form so users
can change their passwords voluntarily. When they click the link, the User
Password Change form is opened.
Figure 4-5: User Password Change form
IMPORTANT
If you allow users to change their passwords directly in the User form instead of
the User Password Change form, beware that the password restriction policy
(default or customized by you) is bypassed because the restrictions are enforced
through the User Password Change form, not through the User form.
Setting up an authentication alias
An authentication alias allows you to use an alternate user name (User Name
Alias) or an authentication string (Authentication String Alias) when the operating
system or an AR System external authentication (AREA) plug-in is performing the
authentication. The User Name Alias and the Authentication String Alias operate
independently of one another, so you can use both or either one alone.
NOTE
The authentication string value can be accessed in AREA plug-ins by using the
$\AUTHSTRING$ keyword.

User Name Alias
Setting up an authentication alias
A User Name Alias is a secondary account name associated with a user and is only
for authentication purposes. The user's primary account name (the login name)
entered into the User Name field of the Login dialog box of AR System clients, is
used for all other purposes. If a User Name Alias is defined, the AR System server
will use it to authenticate the user and password.
The User Name Alias is applicable in the following situations:
When you want the user’s full name to be used as the AR System login instead
of the user’s computer account name. The system uses the alias when
authenticating the user.
When a user’s name changes, that user can log in to the AR System using the
new name but continue to use the same computer account name for
authentication purposes.
When a user’s computer account or domain name is subject to changes.
Leveraging an alias allows the user to continue using the same user name to log
in throughout the changes.
Configuring the User Name Alias
To configure a User Name Alias, add a character field to the User form in BMC
Remedy Administrator and name it Authentication Login Name. The information
in this field is accessed when the user logs in to an AR System client and the
following conditions apply:
Cross-Reference Blank Password is configured on the AR System server (see
“Cross Ref Blank Password” on page 149).
The Password field on the User form is empty.
One of the following external authentication methods is used:
An AREA plug-in
A Windows Domain server (when the AR System server is running on a
Windows platform)
A UNIX password resolution (when the AR System server is running on a
UNIX platform)
Chapter 4 Defining your user base 103

BMC Remedy Action Request System 7.1.00
Relates to the
value in the
Authentication
Login Name field
on the User form.
104 Configuring
Figure 4-6: Login dialog box
The Authentication Login Name field on the User form interacts with the User
Name field in the Login dialog box according to the following rules:
If the Authentication Login Name field is present on the User form, the value
contained in this field is used for authentication instead of the name entered in
the User Name field in the Login dialog box.
For backwards compatibility, if the Authentication Login Name field is not
present on the User form, or the value in this field is NULL, then the user is
authenticated with the information entered in the User Name field in the Login
dialog box.
These rules apply to all AR System clients, including those accessing an AR System
server using C or Java APIs.
Properties of the Authentication Login Namefield on the
User form
In BMC Remedy Administrator, set the properties of the Authentication Login
Name field as shown in the following table:
Field Property Field
Name Authentication Login Name
Field ID 117
Data Type Character
Database Length 30
You can set any permissions, including whether the values are optional or
required. You can also create workflow to populate and validate the values in this
field.
IMPORTANT
Caution is recommended when setting permissions. Typically, the values in this
field should be set only by an administrator, or by using workflow.

Authentication String Alias
Relates to the value
in the Authentication
String field on the
User form.
Setting up an authentication alias
When an Authentication String Alias is defined, it overrides any entry in the Login
dialog box of the AR System client. The Authentication String Alias can be used to
identify the correct authentication domain for the user.
Use the Authentication String Alias in the following situations:
When users belong to specific authentication domains and you do not want to
require users to enter an authentication string when they log in.
When a user’s computer account or domain name is subject to changes.
Leveraging an Authentication String Alias allows the user to continue using the
same user name to log in throughout the changes.
Configuring the Authentication String Alias
To configure an Authentication String Alias, add a character field to the User form
in BMC Remedy Administrator and name it Authentication String. The
information in this field is accessed when the user logs in to an AR System client
and the following conditions apply:
Cross-Reference Blank Password is configured on the AR System server (see
“Cross Ref Blank Password” on page 149).
The Password field on the User form is empty.
One of the following external authentication methods is used:
An AREA plug-in
A Windows Domain server (when the AR System server is running on a
Windows platform)
A UNIX password resolution (when the AR System server is running on a
UNIX platform)
Figure 4-7: Login dialog box
Chapter 4 Defining your user base 105

BMC Remedy Action Request System 7.1.00
106 Configuring
The Authentication String Alias field on the User form interacts with the
Authentication field in the Login dialog box according to the following rules:
The value in the Authentication String field on the User form is used instead of
the entry in the Authentication field in the Login dialog box.
For backwards compatibility, if the Authentication String Alias field is not
present on the User form, or the value in this field is NULL, then the information
entered in the Login dialog box is used for authentication.
These rules apply to all AR System clients, including those accessing an AR System
server using C or Java APIs.
Properties of the Authentication String field on the User
form
In BMC Remedy Administrator, set the properties of the Authentication String
field as shown in the following table:
Field Property Field
Name Authentication String
Field ID 118
Data Type Character
Database Length 255
You can set any permissions, including whether the values are optional or
required. You can also create workflow to populate and validate the values in
these fields.
IMPORTANT
Caution is recommended when setting permissions. Typically, the values in this
field should be set only by an administrator, or by using workflow.
Unique user logins
In AR System 6.3, it was possible to have multiple users with the same user name
but different passwords log in at the same time.
AR System 7.0 does not allow multiple users with the same user name if you use
the User form for authentication. If, however, you use external authentication,
multiple users with the same user name can log in only if they belong to the same
groups. (In the cache, only one session is created, and this session will be used for
both users.)
If you are upgrading to AR System 7.0 from a 6.3 system where you allow multiple
users with the same user name but different passwords, the AR System upgrade
scripts will fail and will generate a message suggesting that you correct the
multiple user name problem.

Chapter
5 Setting
up the BMC Remedy
AR System Administration
Console
This section discusses setting up the AR System Administration Console to enable
you to configure servers and clients to work with AR System.
The following topics are provided:
Overview (page 108)
Configuring AR System to use the console (page 109)
Opening the console (page 110)
Chapter 5 Setting up the BMC Remedy AR System Administration Console 107

BMC Remedy Action Request System 7.1.00
Overview
108 Configuring
The AR System Administration Console gives you access to many administrator
functions in AR System. The console is part of the AR System Server
Administration plug-in, which consists of a library file and a deployable
application. (The plug-in is installed as part of the AR System server installation.)
Figure 5-1: AR System Administration Console
The following categories are available in the AR System Administration Console:
System category
General—Provides the following links that enable you to configure your server
and view server information:
Server Information—Used to configure your server, as discussed in Chapter
6, “Configuring servers and clients.”
Review Statistics—Used to view statistics about the server, as discussed the
Optimizing and Troubleshooting guide.
Review Server Events—Used to capture server-related activities and use
them in workflow and API programs, as discussed in Appendix E, “Working
with the Server Events form.”
Add or Remove Licenses—Used to configure license information, as
discussed in Chapter 2, “Licensing AR System.”
User Password Management Configuration—User to force password
changes, as discussed in “Enforcing a password policy” on page 95.
Distributed Server Option (DSO)—Used to configure DSO, as discussed in the
Administering BMC Remedy DSO guide.

Configuring AR System to use the console
LDAP—Used to configure LDAP, as discussed in the Integrating with Plug-ins
and Third-Party Products guide.
Email—Used to configure the email engine, as discussed in the Administering
BMC Remedy Email Engine guide.
Application category
Users/Groups/Roles—Used to configure users, groups, and roles, which are
discussed in the Form and Application Objects guide.
Business Time—Used to configure business time, as discussed in Appendix F,
“Using Business Time in the AR System server.”
Reports—Used to configure reports, as described in the Installing and
Administering BMC Remedy Mid Tier guide.
Currency—Used to configure currency fields.
Other—Used to view Message Catalog entries and application state
information.
Admin Preferences category
This category enables you to configure and search for centralized administrator
preferences, which are discussed in Chapter 3, “Setting user preferences.”
User Preferences category
This category enables you to configure and search for centralized user preferences,
which are discussed in Chapter 3, “Setting user preferences.”
Configuring AR System to use the console
To use the AR System Administration Console, you must configure the AR System
Administration application properly because it is a deployable application.
By default, deployable applications are imported in the Maintenance state. When
an application is in the Maintenance state, only members of the Administrator
group have permissions to use it. Before you change a deployable application’s
state from Maintenance to Test or Production, you must map groups to roles to
give users access to the application.
Two roles are defined in the AR System Administration application:
AR System Admin Server Manager—Is applied to the Server Information
form. Only users who belong to groups mapped to this role have access to this
form.
AR System Admin User Manager—Is applied to the Manage User Licenses
form. Only users who belong to groups mapped to this role have access to this
form.
For more information about roles, groups, and application states, see the Form and
Application Objects guide.
Chapter 5 Setting up the BMC Remedy AR System Administration Console 109

BMC Remedy Action Request System 7.1.00
Opening the console
110 Configuring
You can open the AR System Administration Console by either of the following
methods:
In a browser:
Go to the following URL address:
http:///arsys/forms/
Log in.
Click the AR System Administration Console link.
In BMC Remedy User, open the AR System Administration Console entry point.

Chapter
6 Configuring
servers and
clients
This section discusses configuring servers and clients to work with AR System.
The following topics are provided:
Configuring AR System servers (page 112)
Configuring a server for development or production cache mode (page 150)
Configuring multiple servers (page 151)
Running a stand-alone AR System server on Windows (page 168)
Configuring firewalls with AR System servers (page 169)
Configuring clients for AR System servers (page 170)
Configuring a server to use plug-ins (page 171)
Configuring the AR System server for external authentication (AREA)
(page 172)
Configuring a mail server (page 174)
Configuring a server for alerts (page 175)
For information about the mid tier and BMC Remedy Mid Tier Configuration Tool,
see the Installing and Administering BMC Remedy Mid Tier guide.
Chapter 6 Configuring servers and clients 111

BMC Remedy Action Request System 7.1.00
Configuring AR System servers
112 Configuring
Every AR System server has a variety of configuration settings that control how
the server works and how it interacts with users. Configuration settings are
specific for each server.
Use the AR System Administration: Server Information form from the BMC
Remedy AR System Administration Console to display information about the
currently selected server and to set server options. You must be an administrator
to make changes.
For more information about the BMC Remedy AR System Administration
Console, see Chapter 5, “Setting up the BMC Remedy AR System Administration
Console.”
The following table lists the tabs in the AR System Administration: Server
Information form. The information provided in each tab is described in the
sections that follow. Although it is strongly recommended to use the AR System
Administration: Server Information form to change server settings, you can
change settings manually in the server configuration file (ar.cfg for Windows or
ar.conf for UNIX ® ).
Tab Information Found on
Platform Displays information about the platform on which the
selected server is running.
page 113
Timeouts Sets various timeouts for the currently selected server. page 114
Licenses Displays the type and number of AR System licenses on
a server. You also set the Submitter Mode in this tab.
page 116
Configuration Sets configuration options. page 118
Log Files Sets debugging modes for the system. page 123
Database Displays information about the database that the
selected server communicates with. You also define a
database password and configuration file location in
this tab.
page 126
Server Ports and Configures AR System to communicate with client page 128
Queues tools, services, and other servers on the network.
Displays information relevant to the user of the
multiple threads in the AR System server.
Advanced Sets parameters related to AR System efficiency,
security, localization, and server statistics.
page 132
Source Control Sets source control integration within AR System. page 136
Server Events Sets the options for logging internal server changes. page 139
Connection Enables you to configure passwords used between the page 141
Settings AR System server and its external subsystems.
Currency Types Specifies currency types available in AR System. page 144
External Sets parameters necessary for AR System to
page 146
Authentication authenticate users to external systems.

Figure 6-1: AR System Administration: Server Information form
Server information—Platform tab
Configuring AR System servers
Use the Platform tab to view information about the platform on which the selected
server is running.
To display platform information about the currently selected server
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Platform tab.
Figure 6-2: AR System Administration: Server Information form—Platform tab
Chapter 6 Configuring servers and clients 113

BMC Remedy Action Request System 7.1.00
114 Configuring
3 Edit the options, as needed:
Field Description
Server Version Displays the version number of the AR System software on the
server. This value corresponds to the $VERSION$ keyword.
Server Directory Displays the folder (directory) where the AR System server is
installed on the server system.
Hardware Displays the hardware platform on which the server is running.
This value corresponds to the $HARDWARE$ keyword.
Operating
System
4 Click Apply.
Server information—Timeout tab
Displays the operating system software version running on the
server system. This value corresponds to the $OS$ keyword.
Server Name Alias Defines an alias that is always interpreted as the current server.
An alias allows you to use a functional name for a server rather
than a machine name (for example, ACME or HelpDesk). Do not
enter a fully qualified domain name. An alias makes it easier to
move workflow between machines.
Entering an alias in this field does not automatically assign an
alias to the server. The network environment must reflect a change
to the server name before entering the alias name in this field. The
alias name must be a valid host name on your network.
If you change your server name alias, make sure you supply the
alias to the DNS or enter the alias name in your hosts file.
Otherwise, your AR System server cannot connect to the plug-in
server.
After you make all your changes to the server environment, users
can log in to BMC Remedy User using the new server alias, just
like any other server name.
See your network operating system documentation for
information about creating an alias for the server.
Server Time Displays the current time on the server (in the local time zone).
Use the Timeouts tab to set the timeouts for the currently selected server.
To set timeouts
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Timeouts tab.

Configuring AR System servers
Figure 6-3: AR System Administration: Server Information form—Timeouts tab
3 Edit the options, as needed:
Group Name Field Name Description
Process Timeout
(seconds)
Alert Send Timeout
(seconds)
Filter API RPC
Timeout (seconds)
Prevents a server from being blocked when a process requested in a
Set Fields filter or escalation action does not return a value soon
enough. The server waits a specified interval and then returns with
a $NULL$ value even if the process has not been completed.
Enter a number from 1 through 60 seconds. The default is 5.
Specifying long intervals can cause an increase in response time for
users.
Sets the time limit (in seconds) allowed for making contact with
alert clients. Two attempts are made to deliver an alert and if the
second attempt fails, the alert registration is removed. The default is
7 seconds.
Sets the time limit (in seconds) allowed for the Filter API RPC to
respond to the server’s request. The default is 60 seconds. The
minimum is zero (0), the maximum is 300.
Chapter 6 Configuring servers and clients 115

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description
Floating License
Timeout (hours)
Currency Ratio
Cache Refresh
Interval
(minutes)
116 Configuring
Write Sets a time limit (in hours) for how long a Floating Write license
remains reserved if the user is not accessing AR System.
When using Floating Write licenses, a “token” is reserved while the
user is connected to the server. If the user does not perform an
AR System operation for the period of time specified in this field,
the license is automatically released back to the pool of available
licenses. The client tool must acquire a license for the user again
when the next licensable operation occurs.
Enter a number from 1 through 99 hours. The default is 2.
Full Text Search Sets a time limit for how long a Floating Full Text Search license
remains reserved if the user is not accessing AR System.
When using Full Text Search Option licenses, a “token” is reserved
while the user is connected to the server. If the user does not
perform an AR System operation for the period of time specified in
this field, the license is automatically released.
Enter a number from 1 through 99 hours. The default is 2. For more
information, see “FTS configuration options” on page 224.
Client Refresh
Interval
4 Click Apply.
Server information—Licenses tab
Sets the interval (in minutes) that clients (for example, BMC
Remedy User and the Web) use when refreshing currency
conversion ratios stored on the server. This refresh action makes
sure that calculations for functional currencies are up to date.
Use the Licenses tab to display information about the type and number of
AR System licenses on a server. You can also set the Submitter Mode in this tab.
To display server license information and set the submitter mode
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Licenses tab.

Configuring AR System servers
Figure 6-4: AR System Administration: Server Information form—Licenses tab
3 Edit the options, as needed:
Field Name Description
Server License Type Displays the license type of the server.
Fixed Write Licenses Displays the total number of Fixed Write licenses on the server.
Floating Write
Licenses
Displays the total number of Floating Write licenses on the server.
Fixed Full Text
Licenses
Displays the total number of Fixed Full Text Search licenses.
Floating Full Text
Licenses
Displays the total number of Floating Full Text Search licenses.
Max Forms Allowed Displays the number of forms your license allows you to create on
on Server
the server. If this field reads Unlimited, you can create as many
forms as you want.
AR System
Displays the AR System identifier code attached to the server
Server ID
license.
Submitter Mode Defines the conditions under which submitters can modify the
requests they initially submit (that is, where their names are in the
Submitter field). Choose one of the following options:
4 Click Apply.
Locked—Users can modify requests they submit without a
write license. This does not apply to users with a Restricted
Read license who cannot modify requests under any
circumstances. In the locked submitter mode, after the entry is
submitted, the value in the Submitter field cannot be changed.
Changeable—(Default) Users must have a write license to
modify requests.
Note: Changes to the Submitter Mode settings do not take effect
until the server is stopped and restarted.
Chapter 6 Configuring servers and clients 117

BMC Remedy Action Request System 7.1.00
Server information—Configuration tab
118 Configuring
Use the Configuration tab to set administrative options.
To set configuration options
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Configuration tab.
Figure 6-5: AR System Administration: Server Information form—Configuration tab

3 Edit the options, as needed:
Field Name Description
Users Prompted for
Login
Defines the login procedure for BMC Remedy User. The options are:
Max Entries
Returned by GetList
Server Table Field
Chunk Size
Configuring AR System servers
By Preference—(Default) Users can select which of the two login options they prefer
in BMC Remedy User. For more information, see BMC Remedy User help.
Once Only—Users must log in to BMC Remedy User only the first time they start the
application. User and password information is stored in the Windows registry.
Always—Users must log in to BMC Remedy User every time it is started. No user or
password information is stored in the user registry.
If you select Once Only or Always, the Always Prompt for Login preference in BMC
Remedy User is disabled and the user must comply with the option selected here. If a
user accesses servers with different login settings, the login requirements for the
strictest server are enforced.
You cannot specify this setting for BMC Remedy Alert.
Limits how many database entries are returned from a search. For example, setting the
maximum entries to 50 would return a maximum of 50 entries, even if more entries
satisfied the search qualification. The AR System warns users that the search matched
more entries than the administrator allows to be retrieved. If users specify a maximum
in their preferences, the lesser of these two values is used. A value of zero (0) specifies
no limit (the default).
For server-side table fields, this number determines the number of entries (or size of
the chunk) that the server retrieves at one time from the database and stores inmemory
to process during filter or filter guide actions. The server then retrieves, stores,
and processes the next chunk until all the rows have been processed. Entering a value
of zero (0) causes the server to retrieve an unlimited number of rows. The default is
1000 rows.
Entering a low value in this field causes the server to process smaller chunks, which
keeps the server memory usage down, but results in slower processing because the
server needs to access the database many times, especially for large tables. Entering a
high value causes the server to retrieve and process large chunks of data and access the
database fewer times. This results in higher performance at the cost of memory use.
Server Language Displays the language and character set of the machine on which the server is running.
User Email Notifies Identifies the sender of email notifications.
From
The default sender for email notifications is ARSystem. To specify another user name,
enter that name in this field. The name must match the name you use in the AR System
Email Configuration Form for notifications. For more information about configuring a
mailbox for notifications, see the Administering BMC Remedy Email Engine guide.
Minimum API Specifies the oldest API version with which the server will communicate.
Version
The corresponding API and AR System versions are as follows:
API 13 and AR System 7.1
API 12 and AR System 7.0
API 11 and AR System 6.3
If you set the minimum API version to 13, clients prior to version 7.1 cannot
communicate with the AR System 7.1 or later server. If you set the API version to 0 or
none, all clients can communicate with the server. For information about setting
passwords to increase security, see “Server information—Connection Settings tab” on
page 141.
Chapter 6 Configuring servers and clients 119

BMC Remedy Action Request System 7.1.00
Field Name Description
Default Home Form Enter the path to a home page form to be used system wide as the default home page
for this server when a user logs in.
This default Home form is only used if one of the following statements is true:
Max Number of
Password Attempts
Next Request ID
Block Size
120 Configuring
This server is designated as the server for the home page in the AR System User
Preference form.
This server is designated as the server on the Home Page Settings page in BMC
Remedy Mid Tier Configuration Tool. See the Installing and Administering BMC
Remedy Mid Tier guide for more information.
No home page is specified in the AR System User Preference form. (You can also set
this in the Options dialog box in BMC Remedy User.)
Note: If the home page form is deleted, this field is cleared and you must re-enter a
default home page.
Enter the maximum number of consecutive bad password attempts a user is allowed.
If you enter 3, the user has 3 chances to log in. If all 3 attempts have bad passwords, the
user account will be marked as INVALID.
The allowed values for this field are 0 and all positive integers. A value of 0 turns
feature off. This setting can also be set with the Max-Password-Attempts option in the
ar.conf (ar.cfg) file.
Enter a positive number (up to 1000) to allocate NextIDs in blocks rather than one at a
time. Allocating in blocks increases performance during a create operation.
The default value is 1. If 0 or a negative number (for example, -1) is used, the server
will use the default value of 1.
You do not need to restart the server for the change to take effect. The option is started
immediately.
Warning: The use of this configuration setting might result in unpredictably large
NextID sequence gaps. The likelihood of this occurring increases with the use of
multiple servers that share a database. The AR System server will not malfunction due
to this gap and should not be considered a defect.
Allow Guest Users Defines whether AR System permits access to guest users, who are not registered users
of the system, to log in.
If the check box is selected (the default), guest users can log in and perform the
following tasks:
Give Guest Users
Restricted Read
View all forms and fields for which the Public group has Visible permission.
Execute all active links for which the Public group has permission.
View all fields for which the guest user is the submitter or assignee, if the Submitter
Group or Assignee Group has View permission for the field.
Submit new requests if the fields on a form have the Allow Any User to Submit check
box selected, as described in the Form and Application Objects guide.
Modify all fields for which the guest user is the submitter, if the Submitter Group has
Change permission for the field and if the Submitter Mode is Locked, as described in
“Server information—Licenses tab” on page 116.
Defines whether guest users will receive a restricted read license when they log in to
AR System. If this option is not selected, guest users will receive a read license.

Field Name Description
Allow Unqualified
Searches
Administrator-Only
Mode
Configuring AR System servers
Defines whether the server accepts unqualified searches (searches for which no search
criteria are specified). If the check box is:
Selected—(Default) All database searches are allowed.
Cleared—You force users to enter a search criteria when performing queries.
Note: Consider restricting unqualified searches to prevent the performance penalty of
retrieving and returning large blocks of data due to accidental, unqualified searches
to the database.
Enables you to allow only administrators and subadministrators to access AR System.
Users who are not administrators or subadministrators cannot perform any
AR System operations. This is useful during system maintenance.
By default, this option is not selected.
Administrator-Only Mode can be set by administrators only, not subadministrators.
After an administrator sets this option, subadministrators can access only forms for
which they have permission.
Disable Archive Disables the archive operations on the server. You can disable one server operating
with one database, but in the case of multiple servers attached to the same database,
you can disable all servers except one to prevent conflicts.
By default, this option is not selected.
For more information about archiving, see the Form and Application Objects guide.
If the Server Groups check box is selected, this setting is ignored. Server groups can be
configured in the AR System Server Group Operation Ranking form to make sure that
only one server performs the operation. See “Running servers as part of a group” on
page 155.
Development Cache
Mode
Server Group
Member
Disable Admin
Operations
Enables a cache mode that is optimized for developing applications and where user
operations might be delayed when changes are made to forms and workflow.
If the check box is not selected (the default), development cache mode is disabled, and
the server is operating in production cache mode.
For more information, see “Configuring a server for development or production cache
mode” on page 150.
A flag that indicates whether the server is a member of a server group.
By default, this option is not selected.
Disables certain operations performed only by administrators and subadministrators,
which enable you to control changes to the database by disabling administrator
operations. You can disable one server operating with one database, but in the case of
multiple servers attached to the same database, you can disable all servers except one
to prevent conflicts. If the check box is:
Selected—Administrators cannot perform operations that affect the server’s data
dictionary.
Cleared—(Default) Administrators can perform their usual operations including all
data dictionary restructuring operations.
If the Server Groups check box is selected, this setting is ignored. Server groups can be
configured in the AR System Server Group Operation Ranking form to make sure that
only one server performs the operation. See “Running servers as part of a group” on
page 155.
Chapter 6 Configuring servers and clients 121

BMC Remedy Action Request System 7.1.00
Field Name Description
Disable Escalations Enables you to stop escalations being run on the server. You can disable one server
operating with one database, but in the case of multiple servers attached to the same
database, you can disable all servers except one to prevent conflicts.
By default, this option is not selected.
If the Server Groups check box is selected, this setting is ignored. Server groups can be
configured in the AR System Server Group Operation Ranking form to make sure that
only one server performs the operation. See “Running servers as part of a group” on
page 155.
Disable Alerts Enables you to prevent alert messages from being sent to users when an alert event is
entered in to the system. No threads will run in the Alert Queue. This setting is
acknowledged only at startup, so any changes will not take effect until the server is
restarted.
By default, this option is not selected.
Verify Alert Users This indicates whether the server needs to check its list of registered alert clients to
determine if they are listening and ready to receive alert messages. As this setting is
acknowledged only at server startup, any changes will not take effect until the server
is restarted. Selecting this option can result in a large amount of network activity at
server startup. If the check box is:
Enable Multiple
Assign Groups
Disallow Non
Unicode Clients
Display Property
Caching
122 Configuring
Selected—The server will verify the list of clients. If the clients are not listening, they
will be removed from the list of registered clients.
Cleared—(Default) The server will not perform the verification.
Regardless of the setting, if a subsequent alert message is sent to a client that is not
listening, they will be removed from the list of currently registered clients at that time.
Allows multiple roles, groups, and user names to be stored in the row-level security
Assignee Group field (ID 112) and in dynamic group fields (ID 60000-60999). This
enables multiple users, or users from multiple groups, to access the same entry (as in
the sample qualification, 'Assignee Group' = “;50;51;-90;’Mary Manager’;”).
If the check box is not selected (the default), only one role, group, or user name can be
stored.
Select this check box to restrict server access to Unicode-safe clients.
This option applies to all BMC Remedy clients except for BMC Remedy Administrator
and BMC Remedy Alert.
This check box is visible only for AR System 7.0 servers or later. Also, for 7.0 servers, if
the server uses a non-Unicode database, the check box will be disabled.
You can prevent the server from loading into its cache the VUI display properties of
forms that do not have individual display property caching settings.
Select the radio button that describes how you want to display property caching:
Disable All Display Property Caching
Cache VUI Display Property Only
Cache Field Display Property Only
Cache All Display Properties
You must restart the server to effect the changes.
Note: Configure setting for individual forms using the check boxes on the Basic / Entry
Points tab of the Form Properties. See the Form and Application Objects guide.
4 Click Apply.

Server information—Log Files tab
Configuring AR System servers
Use the Log Files tab to set one or more of the debugging modes shown in Figure 6-
6 on page 124. In debug trace mode, AR System creates log files containing
information about system activity.
After being activated, logging starts immediately. You can activate logging at any
time.
WARNING
Do not keep logging turned on continuously. Log files can consume increasing
amounts of disk space as messages accumulate unless you limit the log file size.
Monitor your disk resources carefully while logging is active.
You can enter a location other than the default location (/db on
UNIX and \Arserver\Db on Windows), and a name for each of
the log files created in debug mode. You can also specify the same location and file
for multiple types of logging to write all the data logged to a single file.
NOTE
You can also set debug modes for active links, macros, API calls, databases, and
filters in BMC Remedy User through the Logging tab in the Options dialog box.
When a check box is selected, a log file with the name specified in the Log File Path
will contain all logging information. The file is stored in the default folder (for
example, \Home) unless you change it. You can also use the log information to
analyze the active links used in guides. Log files are enabled in BMC Remedy User
because that is where active links and macros run.
For more information about the debug trace modes and log files, see the Optimizing
and Troubleshooting guide.
To set log files
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Log Files tab.
Chapter 6 Configuring servers and clients 123

BMC Remedy Action Request System 7.1.00
124 Configuring
Figure 6-6: AR System Administration: Server Information form—Log Files tab
3 Select the check box next to each appropriate debug trace mode.
You can select all, some, or no log files. The File Name field is disabled until you
select the related check box. After you select a logging mode, you can specify a
different file name.
IMPORTANT
When naming log files, do not use special characters (such as a forward slash (/)
or a question mark (?). Use alphanumeric characters only.
Field Name Description
API Logs information about all API calls made by all clients.
Information is logged on entry and exit of every API call. The
default log file name is arapi.log.
Distributed Server If you are licensed for the Distributed Server Option, logs
information about distributed server activity. Information
includes the distributed operations that were attempted and
whether the operation was successful. The default log file name is
ardist.log.
Escalation Logs information about escalation activity. Information includes
the escalations that executed, whether the escalation
qualification found any matches, and any escalation actions
taken. The default log file name is arescl.log.
Filter Logs information about filter activity for each operation.
Information includes the filters that attempted to execute and all
filter actions performed. The default log file name is
arfilter.log.

Field Name Description
4 To view a log file for any selected log, click the View button.
5 Specify the level of logging for the plug-in server.
Configuring AR System servers
SQL Logs SQL commands sent to the database. Information is logged
for each SQL command issued, including a time stamp and the
user name of the user performing the operation. The default log
file name is arsql.log.
Thread Logs information about threads that are being started and
restarted on the server. The default log file name is arthread.log.
User Logs information about connection activity for each user.
Information includes whether the user can obtain a license and
when each floating license is released. This enables you to keep
an audit trail of user activity to help you determine if you need
more floating licenses. The default log file name is aruser.log.
Alert Logs detailed information about user registration and on the
generation and delivery of alerts. The default log file name is
aralert.log.
Plug-In Server Logs the events of plug-ins that AR System uses. The default log
file name is arplugin.log. For more information about plug-ins,
see the Integrating with Plug-ins and Third-Party Products
guide.
ARFORK (UNIX
only)
On UNIX systems, logs all arforkd activity (a process that
reduces the amount of memory an AR System server uses when
forking new processes). This file is not subject to the maximum file
size specified in the Maximum Log-File Size field.
Server Group Logs information about server group activity. Records
information about the starting and stopping of operations, the
evaluation of other servers, and the timing of each event.
Full Text Index Logs information about full text search indexer activity. The
default log file name is arftindx.log.
Plug-in logging level Information recorded in log file
Off None
Severe Only severe messages
Warning Severe and warning messages
Info Status, severe, and warning messages
Config Configuration, status, severe, and warning messages
Fine Internal exceptions
Finer Trace logs that log tasks as they are executed within the system
Finest Code-level information
All All log information
Chapter 6 Configuring servers and clients 125

BMC Remedy Action Request System 7.1.00
126 Configuring
6 From the Log-File Creation field, choose one of the following options:
Create Backup—Creates new log files, and the contents of the previous log files
are written to .bak files.
Append to Existing—Log files and their contents are preserved, and new
information is appended to them.
7 From the Client-Side Logging Group list, select the group that can use logging
options in AR System clients. Logging options are disabled (grayed out) for users
who are not members of this group.
For more information about the client logging, see the Optimizing and
Troubleshooting guide.
8 In the Maximum Log-File Size field, enter the maximum size (in bytes) for the log
file.
A value of 0 (the default) specifies no limit. Except for 0, the log file size cannot be
set to less than 4096 because that could be the length of one single log line.
When the log file reaches the maximum, new information wraps to the top of the
file, overwriting the old information. If you do not specify a maximum size limit,
you run the risk of running out of disk space on your system.
This setting does not apply to the arforkd.log file.
9 Select the logging options.
Select the Buffer Logged Lines option to buffer logged lines instead of having
them immediately written to disk.
Select the Log Per Thread option to create per-thread log files.
Selecting these options decreases the impact to AR System performance when
logging is enabled. For more information, see the Optimizing and Troubleshooting
guide.
10 Click Apply.
Server information—Database tab
Use the Database tab to view and configure information about the database that
you are using.
To display and update information about the database
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Database tab.

Configuring AR System servers
Figure 6-7: AR System Administration: Server Information form—Database tab
The information displayed on this tab varies depending on the relational database
you have installed.
3 Edit the options, as needed:
Field Name Description
Database Type Displays the type of database that the AR System server is using.
Database Home (For UNIX only) Displays the directory path of the underlying
database that the AR System server is using.
Database Name Displays the name of the database created for AR System within
the underlying database server.
Database Version Displays the version of the database that the AR System server is
using.
Database User Name Displays the user name that AR System uses to access the
database.
Database Password (For Sybase, Oracle ® , Microsoft SQL Server, or DB2 databases
only) Enables you to define the password used by AR System for
access to the database. The existing password is not displayed.
Enter a value in the Database Password field to change the
password.
The default database password created by AR System is
AR#Admin#. If you changed the password and do not remember it,
or if you have changed it outside of AR System and need to reflect
the change within AR System, log in to the database as the
database administrator and change it back to the default. If the
encrypted password is in the ar.conf configuration file, delete it
from there.
Chapter 6 Configuring servers and clients 127

BMC Remedy Action Request System 7.1.00
128 Configuring
Field Name Description
Database
Configuration File
Database Case
Sensitive
Request ID Uses
Clustered Index
4 Click Apply.
Server information—Server Ports and Queues tab
Use the Server Ports and Queues tab to set server ports and RPC numbers as
needed to communicate with other servers, clients, and services on the network.
The Server Queue region on this tab allows you to configure server queues and
threads as appropriate for your server, taking advantage of the multithreaded
design of AR System.
Assigning TCP port numbers to AR System servers
You assign one TCP port number for the AR System server. All initial contact with
the server is through a single port. If you run multiple servers on the same
machine, each server must use a unique port.
Clients must be configured with the server port number to enable server access
without the use of a portmapper. If you do not allow the server to register with a
portmapper, you must assign a TCP port number for the AR System server. For
more information about configuring clients, see “Configuring clients for
AR System servers” on page 170.
Do not assign port numbers that conflict with port numbers used by other
applications or other programs running on your system. To find out which port
numbers are already in use, use one of the following commands at the commandline
prompt:
UNIX—rpcinfo -p
Windows—netstat -a
Displays the contents of the ardb configuration file used by the
advanced AR System feature that appends clauses to the SQL
statements that create tables and indexes.
For more information about the ardb file, see Appendix B,
“AR System configuration files.”
Indicates whether the database in use is case sensitive. This field
is read-only.
(For Microsoft SQL Server, Sybase, and DB2 databases only)
Indicates whether AR System will create the Request ID field as a
clustered index to boost performance.
By default, the check box is selected.
Store CLOB In-Row (For Oracle databases only) Defines the Oracle CLOB storage. The
default value of this setting is F, and new CLOBs will be “out
row.”
If the setting is set to T, all CLOBs to be created are “in row.”

Configuring AR System servers
If you do not check available ports, you might assign port numbers that conflict
with other applications, and your servers might not start as expected. Client tools
can use ports 0–65535.
On UNIX, port numbers within the range 1–1024 are available only for use by the
superuser, and many of these numbers are reserved.
To set server ports and queues
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Server Ports and Queues tab.
Figure 6-8: AR System Administration: Server Information form—Server Ports and Queues
tab
3 Edit the options as needed:
Field Name Description
Server TCP/IP Port Defines the TCP/IP port number for the AR System server.
Allows clients to have access to the server without a portmapper.
When set to zero (0), which is the default, the port is assigned by
the portmapper.
Distributed Server
RPC Program
Number
Note: If you set the Server TCP/IP Port field to a value less than
1024, older clients cannot connect. For older clients, choose a
value greater than 1024.
Enabled if you have BMC Remedy Distributed Server Option
(DSO). Specifies the default RPC program number for the
AR System server queue used by distributed servers. This enables
you to direct DSO traffic to private queues. For more information,
see the Administering BMC Remedy DSO guide.
Chapter 6 Configuring servers and clients 129

BMC Remedy Action Request System 7.1.00
130 Configuring
Field Name Description
Alert Outbound Port The specific TCP port to which the server binds when sending
alert messages to registered clients. If multiple alert threads are
started, the number represents the starting port number in a
consecutive range of numbers available for use by the alert
threads. If no port number is specified, or if zero (0) is entered, the
server is randomly assigned an available port by the portmapper.
Register with
Portmapper
4 Click Apply.
If the check box is:
Selected—The AR System server and the plug-in server are
registered with AR System Portmapper. The server is registered
immediately if not previously registered. AR System clients can
get the port number of the AR System server and the plug-in
server from AR System Portmapper.
Cleared—The AR System server and the plug-in server are not
registered with AR System Portmapper. If the server was
previously registered, this option removes the registration.
AR System clients cannot get the port number of the AR System
server and the plug-in server from the portmapper.
If you are running multiple servers on a single machine, you can
select the Register with Portmapper option for one server only.
Server Queue Enables you to define server queues specific to your needs.
For most types of server queues, you can specify a minimum and
maximum number of threads. For the escalation queue, only the
maximum threads number is used, and all of the threads are
started at startup time.
If you do not specify a fast queue or specify only one thread, two
threads are started to meet the minimum system requirements.
If you specify a list queue and specify only one thread, two
threads are started to meet the minimum system requirements.
If you do not specify a list queue, one is not started.
If the server starts more threads than specified to meet system
requirements for fast and list queues, it does not change the
number specified.
For all other types, if you do not specify a number, the system
defaults to one minimum and one maximum thread per server
queue.
For more information, see “Defining queues and configuring
threads” on page 131.
5 Restart the server for the changes to take effect.
NOTE
To change the port number that the AR System server uses when communicating
with the plug-in server, you must edit the Plugin-Port option of the ar.cfg
(ar.conf) file, and restart the server. For more information, see “Plugin-Port” on
page 279.

Defining queues and configuring threads
Configuring AR System servers
All servers include an Admin queue; it is the default server setting and cannot be
configured. The Admin queue can have only one thread at any time.
When you define additional queues, you must assign corresponding RPC program
numbers, and you must define the minimum and maximum number of threads for
each queue that you are using.
To add server, escalation, or full text indexer queues and configure threads
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Server Ports and Queues tab.
Figure 6-9: Entering server queue information
3 In the Server Queue box, click at the bottom of the Type column.
4 Click in the RPC Port Number column, and enter the appropriate number for the
queue you want to add:
Fast—390620
List—390635
Escalation—390603
Alert—390601
Full Text Indexer—390602
Private—An RPC program number within the following ranges:
390621–390634
390636–390669
390680–390694
5 In the Min Threads field, enter the minimum number of threads that you want
started at startup.
The default is 1.
Chapter 6 Configuring servers and clients 131

BMC Remedy Action Request System 7.1.00
132 Configuring
6 In the Max Threads field, enter the maximum number of threads that your system
will be allowed to start.
The default is 1. When all the existing worker threads are in use, the system starts
additional threads as needed until the maximum number is reached. These
additional threads remain active until the server is rebooted.
For the escalation queue, the maximum number of threads are started when the
server starts up.
7 Click OK to close the form.
When you return to the form, the new queues will be listed.
NOTE
If you have removed a queue or decreased the maximum number of threads for a
queue, restart the server for the changes to take effect.
Server information—Advanced tab
Use the Advanced tab to create settings for performance and security.
To set advanced options
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Advanced tab.
Figure 6-10: AR System Administration: Server Information form—Advanced tab

3 Edit the options as needed:
Group Name Field Name Description
Maximum Filters for
an Operation
Maximum Stack of
Filters
Maximum Line
Length in Email
Configuring AR System servers
Defines the number of filters that can be performed in an
operation. The default and recommended number is 10000.
Increase this number at your own risk only if you reach a
limit in your system and you have verified that your
workflow is valid.
Defines the maximum number of nested filters and filter
guides that will execute to prevent recursive actions on the
server. The default and recommended number is 25.
Increase this number at your own risk only if you reach a
limit in your system and you have verified that your
workflow is valid.
Defines the maximum line length that can be in an email. If
a single line of the message is over this length, a return is
automatically inserted. Limits the line length of emails
passed through the mail server to protect users from
excessively long lines. The default is 1024.
Default Web Path Defines the base URL to the mid tier and is used by clients
such as BMC Remedy Alert and Flashboards.
The URL looks like this:
http:///
Where:
host_name is the name of the server (for example,
eng.remedy.com).
context_path is the URL context path of the AR System
application registered with the servlet engine. This is set
up during installation. The default value is arsys.
If your company has multiple domains, use a fully qualified
path name.
Email Notifications
Web Path
Defines the base URL that appears in email notifications.
If this field is left blank, the Default Web Path is used. (The
Email Notifications Web Path field is available because the
Default Web Path is specified for other applications like
Flashboards, and it might be different from the mid tier web
path for opening requests in a notification.)
If your company has multiple domains, use a fully qualified
path name.
Chapter 6 Configuring servers and clients 133

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description
Security Active Link Run
Process Directory
Localized Error
Messages
134 Configuring
Active Link Run
Process Shell
(UNIX servers only)
Allow arcache and
arreload
Security feature that allows you to define the only directory
in which active link processes can execute.
If no directory is specified, active link processes can run
from any directory. Otherwise, specify which directory the
Run Process action can run from, for example, C:\arsys.
Security feature that allows you to define which shell is the
parent of an active link server process. If no path is specified,
administrators can specify any shell.
Otherwise, specify which type of shell the Run Process
action can use, for example, /bin/csh.
If selected, allows the administrator to use the arcache and
arreload utilities. For more information, see “arcache
(arcache.exe)” on page 296 and “arreload (arreload.exe)” on
page 299. The default is selected.
Localize Server Allows the administrator to enable or disable localization of
the server. If the check box is:
Selected—The server is localized and is enabled for such
tasks as searching entries in localized forms, or using
AR System Message Catalog to load the message. Clients
are enabled to display localized messages, but clients such
as BMC Remedy User still have local catalogs, such as the
user.dll. You must select the Localize Server check box
to see localized error messages.
Cleared—(Default) The server is not localized. Such tasks
as searching localized forms and the localization of
messages are disabled. The server does not make use of
the AR System Message Catalog form and messages are
shown from the error catalog. The default message is
displayed.
Catalog Form Name Displays the name of the form the server uses to resolve
error messages when “Localize Server” is selected. For more
information about Localized Error Messages Catalog form,
see the Form and Application Objects guide.

Group Name Field Name Description
Server Statistics Server Recording
Mode
Recording Interval
(seconds)
4 Click Apply.
Configuring AR System servers
Specifies how the server records server statistics. Select one
of the following options:
Off—(Default) Do not record server statistics.
Cumulative Queue—Record a cumulative statistic that is
a combination of all the queue statistics.
Cumulative and Individual Queue—Record a
cumulative statistic that is a combination of all the queue
statistics as well as statistics of each queue individually.
Information is recorded in the Server Statistics form, which
is installed when you install AR System. For more
information, see the Optimizing and Troubleshooting guide.
Defines how often the server records server statistics. The
default is 60 seconds.
Remember that one (Cumulative Queue) or more
(Cumulative and Individual Queue) entries are recorded in
the Server Statistics form during each interval. If you have a
short interval, many records will be created. This can have
an effect on the performance of the system and the size of the
database if you configure with too short an interval.
Server Group Server Group Names If the server belongs to a server group, enter the name of the
group in this field. This setting is shared by all servers in the
server group.
Check Interval Defines how often the server communicates with other
servers in the group. Each server can register its own status,
determine if any server is delinquent, establish the
parameters needed for sending signals, and determine
operational responsibilities. The default is 30 seconds, the
minimum value is 10 seconds, and there is no maximum
value. This setting is shared by all servers in the server
group, and when it is changed, all the AR System servers in
the group must be restarted.
Preference Server Preference Server
Option
Select where you want user preferences should be read
from. The options are:
User Defined—The user can choose whether to use a
preference server, and this server might or might not be
used depending on whether the Centralized Preference
forms are defined.
Use This Server—The user must use a preference server,
and this server is an available preference server.
Use Other Server—The user must use a preference server,
and this server is not available as a preference server. This
allows the specification that a preference server must be
used, but that this one cannot be used for this purpose.
Chapter 6 Configuring servers and clients 135

BMC Remedy Action Request System 7.1.00
Server information—Source Control tab
136 Configuring
Use the Source Control tab to configure source control (SC) within the AR System
by creating or selecting SC projects. Administrators can also set the level of SC
integration they want, for example, Enforced or Advisory mode. Here you define
specific options for your SC system as well as create, add, and open SC projects.
How SC is integrated with AR System differs based upon which SC application
you use. You will find the SC feature especially helpful in moving applications
from development to production.
To use SC with AR System, you must understand the details of your SC
application and database. Different SC applications will have slightly different
feature sets, creating slightly different implementations with AR System. For
specific information, see your SC application documentation.
For a detailed discussion on SC issues, see the Integrating with Plug-ins and Third-
Party Products guide.
NOTE
You must install and configure your SC system before implementing SC with
AR System. The recommended method of SC integration is installing and running
the SC client instead of editing paths in the system registry. A correct installation
of the SC client must work properly with AR System. When using the SC system,
make sure that you have enabled integration and that you have installed the SC
clients.
To configure source control
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Source Control tab.
Figure 6-11: AR System Administration: Server Information form—Source Control tab

3 Edit the options, as needed:
Field Name Description
Enable Source Control
Integration
Configuring AR System servers
Defines if SC within AR System is activated. If this option is
selected, you can configure SC software (for example, Microsoft
Visual SourceSafe or PVCS Version Manager) with AR System.
Mode Sets one of the following modes:
Enforced—System strictly enforces SC version control on
AR System objects; for example, check-out and check-in.
Enforced integration causes BMC Remedy Administrator to
prompt developers to check out the object when it is modified.
If the system is in Enforced mode, you cannot modify and save
an object if you do not check it out from SC first.
Enforced mode extends also to group permissions and bulk
update operations. Developers cannot modify objects if they
are not first checked out in SC.
Advisory—System warns user when SC version control is not
satisfied with respect to check-out and check-in, but still
allows a developer to update AR System. When a developer
checks in an object, the SC system is updated only if BMC
Remedy Administrator gets exclusive access to the SC system.
If the system is in Advisory mode, you can modify and save an
object without having it checked out from the SC and updating
the Checked Out To property on AR System server. The
system will prompt you with a warning but still allows you to
proceed with your modifications.
Comments Required
in Check In
Comments Required
in Check Out
Defines whether comments are needed when checking in system
objects.
Defines whether comments are needed when checking out
system objects.
Provider Name Defines the SC software installed on your system.
Project Name Opens a project dialog box to select a project and location to
enter into SC.
4 To activate Source Code Control integration in AR System, complete the following
steps:
a Click the Enable Source Control Integration check box.
The SC options in the Source Control tab become activated.
b Choose the Enforced or Advisory Mode option to define the level of SC
integration you want with AR System.
c Choose to add optional check-in or required check-out comments to SC.
SC comments can be optional with AR System. However, if you select to have
comments required, you must enter them each time you check in or check out
an object.
Chapter 6 Configuring servers and clients 137

BMC Remedy Action Request System 7.1.00
138 Configuring
d From the Provider Name list, choose your SC system.
WARNING
Choose an SC system and stay with it. Do not mix SC systems. Otherwise, you run
the risk of introducing inconsistencies within the AR System server environment.
e Click Browse to create or open an SC project.
Depending on which SC application you integrate with AR System, different
actions occur. For example:
With Microsoft Visual SourceSafe, you must log in to SourceSafe, then open
or create a SourceSafe project.
With PVCS Version Manager, you create or open an SC project.
The contents of the read-only Project Name field provide information used
only for internal server processes.
The last project opened in the Source Control tab is the current project displayed
in the BMC Remedy Administrator client. If you are in an environment with
multiple developers, make sure you are all using the correct project.
5 Click Apply.
Your settings are saved to the server. They define the current information for all
AR System administrators and AR System application developers connected to
the system. You can use the SC features as needed.
When you create an SC project in AR System, you can check into SC any object that
appears in the New Server Object dialog box of BMC Remedy Administrator,
except for distributed pools, distributed mappings, and groups.

Server information—Server Events tab
Configuring AR System servers
Use the Server Events tab to select the server activities that you want to log.
When you select specific server events, those events are logged in to the
Server Events form, thereby making server-related changes available to workflow
and API programs. For information about the Server Events form, viewing
recorded server events, and using server events in workflow, see Chapter E,
“Working with the Server Events form.”
To set options for server events
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Server Events tab.
Figure 6-12: AR System Administration: Server Information form—Server Events tab
Chapter 6 Configuring servers and clients 139

BMC Remedy Action Request System 7.1.00
140 Configuring
3 Edit the options, as needed:
Group Name Field Name Description
Server Events Form Specifies the name of the form that is populated with
information about specific server events. AR System
automatically generates this form, and the form is defined
from a unique combination of AR System reserved fields.
Only one Server Events form per server is allowed.
The default name is Server Events; you can rename the form,
as needed.
Server Event Type Server Cache Changes Determines the objects for which changes are recorded in
the Server Events form. Select the check box next to any of
the following events to log changes to these objects:
4 Click Apply.
Active Link
Container
Escalation
Field
Filter
Import
Menu
Form
View
User/Group Changes Determines whether to log additions, modifications, or
deletions to Users or Groups in the User or Group form, or
any user or group changes using the access control utilities
arcache and arreload. Changes will be recorded in the
Server Events form.
Server Setting
Changes
Alert Client
Registration
Determines if an entry is created in the Server Events form
as a result of the ARSetServerInfo call.
Determines if an entry is created in the Server Events form
as a result of BMC Remedy Alert logs to the AR System
server.
Archive Determines if an entry is created in the Server Events form
as a result of archiving data to an archive form.
Server Group Actions Determines if an entry is created in the Server Events form
as a result of server group activities.

Server information—Connection Settings tab
Configuring AR System servers
The Connection Settings tab enables you to add an extra layer of security by
configuring connection settings for the AR System Application Service, the Mid
Tier Service, Plug-In Server, and by both remote and local Distributed Servers (if
DSO is installed).
To set connection settings
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Connection Settings tab.
Figure 6-13: AR System Administration: Server Information form—Connection Settings
tab
Chapter 6 Configuring servers and clients 141

BMC Remedy Action Request System 7.1.00
142 Configuring
3 Edit the options, as needed:
Tab Name Field Name Description
Application Service
Password
Mid-Tier
Administration
Password
Proxy server settings
for Java VM
Specifies the password that AR System application services
(such as AR System Approval Server) will use to access the
AR System server.
Asterisks in the field indicate that a password has been
defined.
If you are running a 7.0 server, you must enter a password.
If you change the Application Service Password on the
server, you must change it for the applications (such as
Email Engine and Flashboards) as well.
Specifies the password that the mid tier will use to access the
AR System server.
If you are running a 7.0 server, you must enter a password.
Used in the Web Services feature when you are configuring
a plug-in with Internet access through a proxy server. Enter
the following text in this field:
-Dhttp.proxySet=true
-Dhttp.proxyHost=
-Dhttp.proxyPort=
Plug-In Server Local Password Sets a plug-in server password, if applicable.
If this option is specified, the plug-in server accepts
connections only from AR System servers configured to use
the same password set in the Plug-In Server Target
Password field.
If this option is not specified, the plug-in server accepts
connections from AR System servers not configured to use a
Plug-In Server Target Password.
Plugin Default
Timeout
Target Connection
Settings
Specifies the number of seconds within which the Plug-in
server must respond to the AR System server before an error
is returned.
Defines the name and port number for the plug-in server.
The server name and port number create a unique entry.
Therefore, if the user modifies an existing server name or
port number, the password is cleared. If the user removes
the password for a particular entry, the user can specify a
server name and port number with no password for that
entry. The next time the user displays the table, the entry is
not displayed.
The edit masked option is not supported in tables on forms.
Therefore, when you type a new Password in the Password
column, it is visible. Saved passwords are masked.

Tab Name Field Name Description
Configuring AR System servers
DSO Server Local Password Specifies the password that a DSO server will use to access
this AR System server.
If you are running a 7.0 server, you must enter a password.
Local RPC Program
Number
Target Connection
Settings
Specifies the RPC program number that DSO will use to
access the AR System server. If you leave the field blank,
DSO will access any other user using fast and list queues.
You can specify a private queue to define all DSO traffic to
use that private queue to isolate the operations of DSO and
interactive users.
Sets the DSO remote server name and password (if
applicable) that the DSO server will use when accessing
other AR System servers. If the user modifies the server
name, the Password column will be cleared.
Enter the information as follows:
1 Enter the remote DSO server name.
2 Enter a password in the Password column. (Leave the
password blank if you do not want to specify a password,
or if you want to clear the existing password.) The edit
masked option is not supported in tables on forms.
Therefore, when you type a new Password in the
Password column, it is visible. Saved passwords are
masked.
3 Select an RPC program number that will be used when
interacting with the specified server (optional). If you
leave the field blank, a value of zero will be entered, and
access to the server will default to using the fast and list
queues.
4 Enter a port number for the specified server (optional). If
you leave the field blank, a value of zero will be entered,
and the system will use a portmapper on the specified
server to locate the AR System server TCP port number.
Remote Workflow Local Password Sets a password used to access the current server when
workflow from another server references the current server.
By defining a password, you require that only workflow
defined on another server to access this server must have a
password defined. This protects the server from outbound
access.
Target Connection
Settings
Sets a workflow password used to access the specified
remote server when any workflow references the remote
server. If the remote server has specified a workflow
password, you must register that server and password, or
you cannot access that server through workflow.
The edit masked option is not supported in tables on forms.
Therefore, when you type a new Password in the Password
column, it is visible. Saved passwords are masked.
Chapter 6 Configuring servers and clients 143

BMC Remedy Action Request System 7.1.00
144 Configuring
NOTE
If you are creating passwords for the Application Service and DSO server, you can
set the minimum API version to 9 to make sure that secure 5.1 and above servers
cannot communicate with servers running previous AR System versions. For
information about setting the API version, see “Server information—
Configuration tab” on page 118.
4 Click Apply.
5 Restart the AR System server for the Connection Settings to take effect.
Server information—Currency Types tab
Use the Currency Types settings to specify the currency types that are accessible in
BMC Remedy Administrator. These currency types (represented by threecharacter
abbreviations such as USD) are stored in the AR System Currency Codes
form. The types appearing in the Currency Types tab are those marked as active in
the Currency Codes form. When you add or remove currency types in the
AR System Administration: Server Information form, the AR System
configuration file (ar.cfg or ar.conf) is updated with your changes.
For more details about currency types, see the Form and Application Objects guide.
To set currency types
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Currency Types tab.
Figure 6-14: AR System Administration: Server Information form—Currency Types tab

3 Edit the options, as needed:
Group Name Description
Choose Default
Allowable Types
Choose Default
Functional Types
4 Click Apply.
Configuring AR System servers
Allowable currency types are types that are valid entries in a
currency field. These currency types are visible in menus or lists
in BMC Remedy Administrator and in client screens.
From the list in the left column, select a currency type, and click
Add. Your selection will be added to the table on the right, which
shows the three-character currency type and the default decimal
precision level for that currency type. For example, the currency
type USD has a default of two decimals of precision. You can
modify this precision level by entering a new value in the
Precision column. For example, to specify four decimals of
precision, enter 4.
To remove a currency type, select it and click Remove.
You must also specify the functional currencies that will be stored
as part of the field value. When a request is submitted that
includes a currency value, the server converts that value to a
functional currency type and stores it.
You must include at least one functional currency type. There is
no limit to the number of functional currency types you can
specify; however, adding more than five currency types might
have an adverse effect on server performance.
From the list in the left column, select a functional currency type,
and click Add. Your selection will be added to the table on the
right, which shows the three-character currency type and the
default decimal precision level for that currency type. For
example, the currency type USD has a default of two decimals of
precision. You can modify this precision level by entering a new
value in the Precision column. For example, to specify four
decimals of precision, enter 4.
To remove a currency type, select it and click Remove.
Chapter 6 Configuring servers and clients 145

BMC Remedy Action Request System 7.1.00
Server Information—EA tab
146 Configuring
Use the EA (external authentication) tab to specify values for parameters necessary
for AR System to authenticate users with external systems.
To set AR System Administration: external authentication parameters
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the EA tab.
Figure 6-15: AR System Administration: Server Information form—External
Authentication tab

3 Edit the options, as needed:
Group Name Field Name Description
External
Authentication Server
Timeout (seconds)
External
Authentication Server
RPC Program Number
Configuring AR System servers
Enables an external authentication (AREA) server. The RPC
program number for the plug-in service is 390695. Entering
no value or zero (0) disables authentication using an AREA
service, and the AR System server accesses the operating
system for authentication purposes.
Note: You must have an AREA server built and prepared
before you set the RPC Socket number here. See the CAPI
Reference guide for information.
For more information about how to set up an external
authentication server, see “Configuring a server to use plugins”
on page 171. For information about configuring an
AREA LDAP plug-in, see the Integrating with Plug-ins and
Third-Party Products guide.
RPC Sets the time limit (in seconds) within which the plug-in
server must respond to the AR System server when making
external authentication (AREA) calls before an error is
returned.
If this is set to zero (0), the AR System server uses the default
of 30 seconds.
Need To Sync Sets the interval for periodically invoking the AREA server’s
AREANeedToSyncCallback() call. If this option is set to zero
(0), the AR System server does not invoke the call to the
external authentication server. The default is 300 seconds.
For more information about the external authentication
server, see “Configuring a server to use plug-ins” on
page 171, and the Integrating with Plug-ins and Third-Party
Products guide.
Chapter 6 Configuring servers and clients 147

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description
148 Configuring
Authenticate
Unregistered Users
Defines how AR System validates a user who has no record
in the User form.
When a user logs in to AR System, the server attempts to
validate the user against registered users (users who are
listed in the User form). If a match is found, that user
definition and the permissions specified in the matching
User record are used. If no match is found, AR System
continues to attempt to validate the user or stops the
validation process depending on whether this option is
selected. If the check box is:
Selected, and External Authentication is not
configured—(Default on UNIX servers) On a UNIX
server, AR System searches the /etc/passwd file or NIS
password map for a match. If a match is found, the user is
considered a valid user (not a guest) of the system. The
UNIX group specification from the file or NIS is retrieved,
and the user is considered a member of the AR System
group whose Group ID matches the UNIX group.
On a Windows server, the AR System authenticates to the
default domain. The optional authentication string
entered by the user when logging in is used as the
Windows domain name for authentication purposes.
On Windows servers, the user is considered a member of
the group whose Group ID is 0.
Selected, and External Authentication is configured—
AR System sends a request to the external authentication
server to authenticate the user. If a match is found, the
user is considered a valid user (not a guest user) of the
system. For more information, see “Configuring a server
to use plug-ins” on page 171.
The authentication string entered by the user when
logging in is passed to the external authenticator for its
use.
Cleared—(Default on Windows servers)AR System stops
the validation process and manages the user as a guest
user if Allow Guest Users is enabled.
For information about configuring external authentication,
see “To set server ports and queues” on page 129.

Group Name Field Name Description
Cross Ref Blank
Password
Authenication
Chaining Mode
Configuring AR System servers
Defines how AR System authenticates a user whose User
form record has no password. When a user logs in,
AR System searches its own database for that user. If the
user has a password, the system uses it. If the Password field
is empty, and the check box is:
Selected—AR System attempts to validate the password
against one of the following items:
An external authenticator if one is configured
The password in the Windows server domain
The UNIX server’s /etc/passwd file
Cleared—(Default) AR System concludes that an empty
password field means that the user has no password.
In the Login window, users will see an Authentication field.
If your AR System server is running on Windows, the
contents of this field are used as a domain name when the
server authenticates the user with the operating system. If
the server is instead configured to use an external
authenticator, the contents of this field are passed to the
authenticator. See “Setting up an authentication alias” on
page 102 for more information about authentication aliases.
If you enable the Cross-Reference Blank Password option,
make sure that it does not conflict with the User Password
Management feature. If you enforce a password policy
AR System forces users to periodically set a password that
cannot be blank. If a user’s password is authenticated
outside of AR System and that user sets a non-blank
password, AR System performs the authentication.
This is not an issue if enforcement of a password policy is
not enforced. If a policy is enforced, you must disable the
policy for users whose passwords should be blank.
For information on enforcing password policies, see
“Enforcing a password policy” on page 95. To disable the
policy for users whose passwords should be blank, see “To
disable password management for individual users” on
page 98.
You specify the order in which the different authentication
processes are considered at log in.
Default—Disables authentication chaining.
ARS - AREA—AR System attempts to authenticate the user
by using the User form and then the AREA plug-in.
AREA - ARS—AR System attempts to authenticate the user
by using the AREA plug-in and then the User form.
ARS - OS - AREA—AR System attempts to authenticate the
user by using the User form, then Windows or UNIX
authentication, and then the AREA plug-in.
ARS - AREA - OS—AR System attempts to authenticate the
user by using the User form, then the AREA plug-in, and
then Windows or UNIX authentication.
Chapter 6 Configuring servers and clients 149

BMC Remedy Action Request System 7.1.00
Group Name Field Name Description
Group Mapping LDAP Group Name The name of LDAP group you want to map to the AR group
in the same row of the Group Mapping table.
AR Group Name The name of AR group you want to map to the LDAP group
in the same row of the Group Mapping table.
Ignore Excess Groups Enables AR System to authenticate a user when any single
LDAP group to which the user belongs matches an
AR System group.
Configuring a server for development or
production cache mode
150 Configuring
There are two cache modes that you can set for your server operation,
development cache mode and production cache mode. Production mode is the
default and is appropriate where there are a large number of application users.
In development mode, the admin thread for API calls does not copy the cache but
locks incoming threads out of the existing cache and waits for threads currently
using the cache to complete their operations before performing changes. The
thread will not release the cache until the end of the API call.
No time is spent copying the cache so operations have a smaller memory footprint
and are performed faster than in production mode. Development mode is
intended for servers whose main purpose is application development. It is
unsuitable for servers with a large number of application users in a production
environment because the operations of those users will be blocked when forms
and workflow are changed, especially when many structures are changed, such as
when importing an application.
You must restart the AR System when both setting and clearing the development
cache mode.
To set development cache mode
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Configuration tab.
3 Select the Development Cache Mode check box.
4 Restart the AR System server for this setting to take effect.
If your server has been set to development mode and you want to reset it to
production mode, use the following procedure.

Configuring multiple servers
To set production cache mode
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Configuration tab.
3 Clear the Development Cache Mode check box.
4 Restart the AR System server for this setting to take effect.
Configuring multiple servers
You can configure multiple servers to run on a single host machine. You can also
configure multiple servers on independent host machines to access the same
database. These distinct features are discussed in the following sections. To learn
more about installing multiple servers, see the Installing guide.
IMPORTANT
Server group functionality is not supported for multiple servers on one machine.
Configuring multiple servers on one machine
The ability to run multiple servers on a single host machine offers the following
advantages:
It provides a cost-effective solution by allowing you to support more customers
with less hardware.
It enables mutually exclusive groups of users to access separate AR System
servers on a single host machine.
It provides the option to use a single high-end system for production,
development, and test.
Each server connects to a different database, as shown in Figure 6-16, and each
server must have a separate license.
Chapter 6 Configuring servers and clients 151

BMC Remedy Action Request System 7.1.00
152 Configuring
Figure 6-16: Configuring multiple servers on one machine
Host
Server
Server
For more information about licensing, see Chapter 2, “Licensing AR System.”
Additional servers are installed the same way you install your original AR System
server. You must run the AR System server installer again for each additional
server you want to run on the host machine. For information about installing
servers, see the Installing guide.
The following information highlights the configuration parameters necessary to
support multiple servers on one machine. While you might have configured these
parameters during installation, the steps are noted here for verification and
troubleshooting purposes.
Before assigning port numbers, remember these tips:
Only one server can be registered with a portmapper if you are configuring
multiple servers to run on one machine.
You must assign unique port numbers for each server.
Do not assign port numbers that conflict with port numbers used by other
applications or other programs running on your system. You can find out which
port numbers are already registered by using the rpcinfo -p command (UNIX)
or the netstat -a command (Windows) at the command-line prompt. If you do
not check available ports, you could assign port numbers that conflict with other
applications, and your servers might not start as expected.
On UNIX, port numbers within the range 1–1024 are only available for use by
the superuser, and many of these numbers are reserved.
Client tools can use ports 0–65535.

Configuring multiple servers
To assign port numbers using BMC Remedy Administrator
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Server Ports and Queues tab.
3 In the Server TCP/IP Port field, enter the number that you want to use for the
server port. See “Server information—Server Ports and Queues tab” on page 128
for more information.
4 Select the Register with Portmapper check box as appropriate to determine the
Portmapper option.
5 For every server, manually set the Multiple-ARSystem-Servers option to True in
the ar.cfg file or ar.conf file.
For general information about the files or for specific information about this
particular option, see Appendix B, “AR System configuration files.”
6 Click Apply.
7 Restart the server for the changes to take effect.
NOTE
To change the port number that the AR System server uses when communicating
with the plug-in server, edit the Plugin-Port option of the ar.cfg (ar.conf) file, and
restart the server. For more information, see “Plugin-Port” on page 279.
Configuring multiple servers to access the same database
The ability to configure multiple servers to share the same AR System database, as
shown in Figure 6-17, offers the following advantages:
It enables you to use multiple servers to access multiple applications from a
single high-performance database sharing the same data.
It gives you one point of database management.
It provides easy backup and replication at the database level.
It increases scalability by increasing the bandwidth that can be applied to a
single data set.
Chapter 6 Configuring servers and clients 153

BMC Remedy Action Request System 7.1.00
154 Configuring
Figure 6-17: Multiple servers accessing the same AR system database
Host Host
Host
Server Server
During installation, you will be prompted to specify a database for each server as
well as database login information and database settings. You will want to specify
the same information for each case, making sure you choose the share option for
the second and subsequent servers. For more information about installing multiple
servers, see the Installing guide.

Running servers as part of a group
Configuring multiple servers
You can create a server group to manage servers collectively. A server group
consists of two or more servers designated as part of a server group that share the
same database. Servers that belong to the same group can provide backup for
server operations that are allowed to run on only one server at a time. Critical
operations have greater availability because you can configure any server in the
group to back up another server’s operations.
IMPORTANT
Server group functionality is not supported for multiple servers on one machine.
Servers in a group can back up the following operations:
Administration
Approval Server
Archive
Assignment Engine
Business Rules Engine
DSO
BMC Remedy Email Engine
Escalation
Flashboards
Full Text Index
CMDB
Reconciliation Engine
SLM Collector
To configure server groups, you must complete the following tasks:
Step 1 Install the initial server with the database.
Step 2 For subsequent servers, choose the same database when installing the servers in a
server group, and select the Share database option. See “Installing servers as
members of a server group (Step 2)” on page 156.
Step 3 License the servers appropriately. See “Licenses in a server group” on page 33.
Step 4 Configure the servers for the following categories that apply to your servers:
a Server group name—See “Setting the server group name (Step 4a)” on page 157.
b Time (check) interval that servers use to check whether another server is still
online—See “Setting the check interval (Step 4b)” on page 158.
c Common server alias—See “Specifying a common server name alias (Step 4c)”
on page 158.
Chapter 6 Configuring servers and clients 155

BMC Remedy Action Request System 7.1.00
156 Configuring
d Unique server name—See “Establishing a server name for the servers in a server
group (Step 4d)” on page 159
e Plug-in server alias—See “Specifying plug-in server aliases (Step 4e)” on
page 159.
f BMC Remedy Alert—See “Configuring BMC Remedy Alert to work with
multiple servers (Step 4f)” on page 160.
g Signal option—See “Choosing a method for server group signaling (Step 4g)” on
page 161.
h Full text search—See “Configuring Full Text Search for server groups (Step 4h)”
on page 162.
i DSO—See “Configuring DSO for a multiple-server environment (Step 4i)” on
page 163.
j Email Engine—See “Server group communication with BMC Remedy Email
Engine (Step 4j)” on page 164.
k BMC Remedy Flashboards—See “Server group communication with BMC
Remedy Flashboards (Step 4k)” on page 164.
l BMC Remedy Administrator—See “Bypassing the load balancer for BMC
Remedy Administrator operations (Step 4l)” on page 164.
m Logging—See “Logging for server group (Step 4m)” on page 165.
Step 5 Specify server membership for each server in the group. See “Declaring server
group members (Step 5)” on page 165.
Step 6 In BMC Remedy User, determine the settings for individual servers in the group.
See “AR System Server Group Operation Ranking form (Step 6)” on page 166.
Installing servers as members of a server group (Step 2)
All AR System servers in the group must share the same database. After you have
an initial instance of the AR System server, you can use the AR System server
installer to automatically configure all other AR System servers to share the
existing database of the initial AR System server.
If you do not select the Share option for a server at installation and subsequently
want to make that server a member of a server group, modify the ar.conf (ar.cfg)
file to point the server to the database used for the server group. For more
information, see “To configure an existing server to share a different database” on
page 157.

Configuring multiple servers
To specify the shared database
1 When prompted during the AR System server installation, specify the database
name as well as the database login information and settings for the AR System
database to share.
2 When prompted for a database upgrade option, choose Share instead of Upgrade
or Overwrite.
Choosing Share prevents the data within the shared database from being modified.
The installer verifies that the database version is appropriate and does not attempt
to reconcile differences in system forms or modify database content. At the end of
the installation, the AR System server is configured to use the shared database.
3 Repeat step 1 and step 2 for all AR System servers.
To configure an existing server to share a different database
Modify the configuration file manually to reference the shared database. The
referenced database must be at the AR System internal database version that is
appropriate for the version of the AR System server. If the internal database
version is not appropriate, the server will not be able to start. For more information
about the configuration file, see “ar.conf (ar.cfg)” on page 248.
NOTE
Declaring a server to be a server group member is not done at installation time.
This declaration is made after the server is installed and running.
Setting the server group name (Step 4a)
To set the server group name
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Advanced tab.
Figure 6-18: Setting the server group name on the Advanced tab
3 In the Server Group Name field, enter the name of the group to which the server
belongs.
This can be any name of your choice. Names can be as long as 80 characters,
including spaces, and must have no special characters. You can include doublebyte
characters, but avoid using numbers at the beginning of the name.
4 Click OK.
Chapter 6 Configuring servers and clients 157

BMC Remedy Action Request System 7.1.00
158 Configuring
Setting the check interval (Step 4b)
To set the server check interval
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Advanced tab
Figure 6-19: Setting the check interval on the Advanced tab
3 In the Check Interval field, enter how often you want the server to check the status
of other servers in the group.
The default check interval is 30 seconds, the minimum value is 10 seconds, and
there is no maximum value. If you change this value after a server group is
running, you must restart all the AR System servers.
The information shared between servers in the group includes:
The current server’s own status.
Whether any server is delinquent.
The parameters needed for sending signals.
Information about operational responsibilities.
For an explanation of delinquency and rankings, see “AR System Server Group
Operation Ranking form (Step 6)” on page 166.
4 Click OK.
Specifying a common server name alias (Step 4c)
All AR System servers in a group must have the same server name alias because
this alias can be used in workflow. If the server name alias is not the same for all
AR System servers in the group, workflow that references the alias will not work
correctly.
If you are employing load balancing, the common server alias should be the same
as the short DNS name of the load balancer. The DNS name of the load balancer
refers to a name that resolves to the load balancer IP address. If the name is not the
same, the server will not generate ARTask shortcut server references that point to
the load balancer. When generating ARTask attachment files for email, the server
creates a reference to itself using the alias name with the domain appended. If the
alias name matches the DNS name of the load balancer and the long DNS name is
resolvable, clients using the ARTask shortcut are routed through the load balancer.

Configuring multiple servers
To specify a common server name alias
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Platform tab.
3 Change the Server Name Alias so that all the AR System servers in the group have
the same name alias.
4 Repeat step 2 and step 3 for all AR System servers.
Establishing a server name for the servers in a server
group (Step 4d)
Each server in a server group needs a uniquely defined name to identify itself. The
name that the server knows itself by is the common alias defined for the group.
To establish a unique name for each server, add the following line to each server's
configuration file with a unique name that references the specific host:
Server-Connect-Name: myservername
DNS must be able to resolve this name, and it is used exactly as specified (that is,
no domain name is appended). Each server uses its own defined name to register
as a server group member. Other servers in the group use the name when
communication between servers is required.
If you change the name of one of the servers in a server group after the server is
established as a member, remove all references to the previous server name. See
“To remove a server from a server group or to remove all references to an old
server name” on page 168.
Specifying plug-in server aliases (Step 4e)
When you specify a common AR System server alias, AR System uses the alias
name to connect to the plug-in server. When the AR System server is connecting to
its local plug-in server, the connection will not be successful if the server name
resolves to anything other than the local server.
To route connections successfully in an environment where the server name
resolves to a load balancer, you must define plug-in server aliases. The purpose of
this step is to designate the local server as the host, not to change the name of the
plug-in.
To specify plug-in server aliases
Add an alias definition for each loaded plug-in to the configuration file, using the
plug-in name specified in the plug-in definition. Use the following format,
substituting the alias name, plug-in name, host name, and optional port number:
Server-Plugin-Alias:
[:]
Chapter 6 Configuring servers and clients 159

BMC Remedy Action Request System 7.1.00
Mapping loadbalancer
IP
addresses to
AR System
server IP
addresses
Mapping
remote server
IP addresses to
local server IP
addresses
160 Configuring
The AR System server connects to the plug-in server using host at
port when the AR System server communicates with the
plug-in. Host must resolve to the local AR System
server, and the port number is specified if the plug-in server is listening on a
particular port. The following definition is a typical example:
Server-Plugin-Alias: ARSYS.ARDBC.REPORT ARSYS.ARDBC.REPORT myserver:2020
For more information about Server-Plugin-Alias, see “ar.conf (ar.cfg)” on
page 248.
Configuring BMC Remedy Alert to work with multiple
servers (Step 4f)
If you do not use BMC Remedy Alert and the alert mechanism in your
environment, you can skip this section.
Mapping IP addresses
When an alert client registers with the AR System server, it registers on only one
of the servers. That registration is automatically broadcast to the other servers in
the group, but some IP address configuration is required to properly register the
client on the other servers. In a load-balanced environment, the registration
information contains the load balancer IP address instead of an actual server IP
address. Therefore, each server must have an IP address mapping from the load
balancer IP address to its own IP address.
To map the load-balancer IP address to the AR System server IP address
For each AR System server in the group, add the following line to the
configuration file of the server:
Map-IP-Address:
The parameters are as follows:
—The virtual IP address of the load balancer used by the
Alert clients for connecting.
—The IP address of the local AR System server.
NOTE
Because each AR System server is configured individually, you must repeat this
procedure for all AR System servers in the group. Make sure you modify the
AR System server IP address for each server.
In a non-load-balanced environment (or a load-balanced environment where users
are allowed to connect directly to a server), the registration information contains
the server IP address of the server to which the user connected. Therefore, each
server must have an IP address mapping from all other servers to its own IP
address.

Configuring
the server to
ignore client IP
addresses
Configuring multiple servers
To map all other server IP addresses to the AR System server IP address
For each AR System server in the group, add the following line for each remote
and local server combination to the configuration file:
Map-IP-Address:
The parameters are as follows:
—The IP address of a remote server were an Alert client
could connect to.
—The IP address of the local AR System Server.
For example, if you have three AR System servers (A, B, and C) in the group, add
the following lines to the ar.conf (ar.cfg) file for server A:
MAP-IP-Address
MAP-IP-Address
NOTE
Version 5.1 or higher of the BMC Remedy Alert client is required in a server group
environment.
For more information about BMC Remedy Alert, see Chapter 7, “Working with the
alert system.”
When an alert client registers with the AR System server, it provides its own IP
address as part of the registration information. If the server detects a difference
between the registered IP address and the actual IP address from which the client
call originates, the server attempts to send alerts to the actual address by default.
In a load-balanced environment, the actual IP address is the address of the load
balancer, and alerts sent to that address will fail.
To send alerts to registration IP addresses and ignore actual IP addresses
Add the following line to the configuration file:
Alert-Ignore-Actual-Client-IP: T
Choosing a method for server group signaling (Step 4g)
By default, a server in a server group notifies other members of the group of
activities using a combination of the ARSignal utility and information posted in the
database. Alert user registration, user changes, and application activity (for
example, DSO) are communicated with ARSignal; all other activity such as form
changes, workflow changes, and escalation time changes are communicated with
database postings.
Chapter 6 Configuring servers and clients 161

BMC Remedy Action Request System 7.1.00
162 Configuring
The database method is preferred because it reduces server activity when
definition changes are communicated between servers. You can, however, choose
the ARSignal method for all types of activity. With this method, other servers are
notified of changes immediately, and there is no delay in resynchronization or
updating definitions. To set the ARSignal communication option, add the
following line to the server’s configuration file:
Server-Group-Signal-Option: T
You can set this option for each server in the server group independently. You
should set all servers to use the same method. See also “Server-Group-
Signal-Option 2 ” on page 282.
NOTE
Form, workflow, and escalation time changes can add significantly to the
workload on a production server. In a server group environment, that effect is
magnified when other servers are notified of the changes and recache definitions
from the database. Consider this when planning changes of this type.
Configuring Full Text Search for server groups (Step 4h)
If you do not use full text search (FTS), you can skip this section. To enable FTS in
a server group, you must install and configure it on each server in the group. Each
server performs indexing for the tasks generated on it, and therefore the server
must have access to the set of shared index files. Specify a shared directory for the
FTS collection directory, and make sure that all AR System servers in the group
share the same directory.
Full text indexing operation management
The server manages the full text indexing operation in a different manner than
other operations. The typical management method is to make sure that only one
server is running a particular operation at any one time. Full text indexing is
handled differently. Since each server performs the indexing tasks that are
generated on it, there is no need to restrict the indexing to one server. What is
needed for a server that is not operational is for another server to take over its
already queued indexing tasks. Therefore, the ranking for the full text indexing
operation defines the hierarchy for servers to take over indexing tasks from other
servers. Once taken over, an indexing task does not get returned to its original
server, even if the original server is operational before the server that took it
executes the task.

Configuring multiple servers
To enable FTS in a multiple-server environment
All AR System servers in the group must share the same FTS index collection
directory. There are three ways to specify the location of this directory.
Provide the directory name during installation, when you are prompted.
Specify the directory name in the Full Text Search tab on the AR System
Administration: Server Information form.
Add the following server option to the ar.cfg or ar.conf file:
Full-Text-Collection-Directory:
Share the collection directory so that it is accessible to all AR System servers in the
group. In UNIX environments, the directory is typically configured as a network
share.
Windows configuration example:
If the shared full-text collection directory resided in a shared directory called
Collection on serverX, the following server option would be added to the ar.cfg
file:
Full-Text-Collection-Directory: \\serverX\Collection
Be sure that the login account for the AR System server service has access to the
shared location. The default System Account does not have access, and therefore
you cannot use it with this configuration.
UNIX configuration example:
If the shared full-text collection directory were named /home/root/collection, the
following server option would be added to the ar.conf file:
Full-Text-Collection-Directory: /home/root/collection
Configuring DSO for a multiple-server environment (Step
4i)
If the Distributed Server Option (DSO) is not used in your environment, you can
skip this section. In an AR System environment with load balancing or multiple
servers, a DSO server process runs on each server but only one process actively
distributes data. The configuration needed to support DSO fail-over is limited to
modification of the mappings to indicate that any server in the server group can
act as the source server.
From the BMC Remedy Administrator server window, click Distributed Mappings
(in the object tree). Modify each distributed mapping by selecting the Allow Any
Server in Server Group check box on the Basic tab. This setting indicates to the
servers in the group that regardless of the originating (From) server name specified
in the mapping, any server in the group is qualified to be the originating server. In
the event of a fail-over where the DSO operation moves from one server to another,
the data will continue to be processed.
Chapter 6 Configuring servers and clients 163

BMC Remedy Action Request System 7.1.00
164 Configuring
Server group communication with BMC Remedy Email
Engine (Step 4j)
If the port number (RMIPort) for email administration in BMC Remedy Email
Engine is changed from the default, set the AR System server configuration in
ar.cfg or ar.conf to the same port number. This enables the server to
communicate email administration information to BMC Remedy Email Engine
during server group processing.
The syntax is as follows:
Server-Group-Email-Admin-Port: 2020
Server group communication with BMC Remedy
Flashboards (Step 4k)
If the port number (RMIRegistryPort) for flashboards administration in the
Flashboards server is changed from the default, set the AR System server
configuration in ar.cfg or ar.conf to the same port number. This enables the
server to communicate flashboards administration information to the Flashboards
server during server group processing.
The syntax is as follows:
Server-Group-Flashboards-Admin-Port: 2021
Bypassing the load balancer for BMC Remedy
Administrator operations (Step 4l)
To administer load-balanced AR System servers, use BMC Remedy Administrator
and BMC Remedy User to log in directly to a specific AR System server, bypassing
the load balancer. Only one AR System server in the group has responsibility for
the administration operation. You must log in to that server for object creation and
modification. All servers can be accessed for the purpose of changing server
settings with BMC Remedy User, such as the number of threads specified for a
queue. You cannot use the load balancer to log in because the load balancer might
not direct you to the correct AR System server.
Logging in with a server name that does not match the server alias can create
problems when you are defining workflow that contains a server name. To avoid
these problems, you must add configuration definitions indicating to the server
that any of a given set of server names is recognized as the current server. The
configuration might appear more than once—for example, you might need to
designate a short name and a long name, as shown in the following example:
IP-Name: myserver
IP-Name: myserver.remedy.com
If BMC Remedy Administrator used either of these server names to log in, it would
be recognized as the current server in workflow.

Logging for server group (Step 4m)
Configuring multiple servers
Information tracked in the log file includes the starting and stopping of operations,
the evaluation of other servers, and the timing of each event.
To set the server group log file
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Log Files tab.
Figure 6-20: Server Group entry on the Logging tab
3 Select the Server Group check box.
4 Enter a path to the log file if you do not want to use the default.
5 Click OK.
To log server group activity in the Server Events form
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Server Events tab.
Figure 6-21: Server Group entry on the Server Events tab
3 Select the Server Group Actions check box.
4 Click OK.
For more information about server group settings on the AR System
Administration: Server Information form, see the following sections:
“Server information—Configuration tab” on page 118
“Server information—Advanced tab” on page 132
“Server information—Log Files tab” on page 123
“Server information—Server Events tab” on page 139
Declaring server group members (Step 5)
This section describes how to configure a member of the server group as the initial
member and how to configure the remaining members of the server group.
Chapter 6 Configuring servers and clients 165

BMC Remedy Action Request System 7.1.00
166 Configuring
To designate an initial server for server group membership
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Configuration tab.
3 Select the Server Group Member check box and click Apply.
A warning appears, stating that the change will take effect the next time the server
is started.
4 Dismiss the warning dialog box.
5 Restart the AR System server.
To designate additional servers for server group membership
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Configuration tab.
3 Select the Server Group Member check box and click OK.
A warning appears, stating that the change will take effect the next time the server
is started.
4 Dismiss the warning dialog box.
5 Restart the AR System server.
AR System Server Group Operation Ranking form (Step 6)
The AR System Server Group Operation Ranking form is automatically created
when you specify a server as a member of a group and restart the AR System
server. This form is created only one time, when the first server is specified as a
group member and the server is restarted.
When the form is created, it is populated with default entries. For the first server
in a server group, the default entries establish that server as the first choice for
operation ownership for each operation. Subsequent servers have default entries
with a null ranking that serve as placeholders for easy modification. Default
entries for operations that do not run in your environment should be removed or
have a null ranking. If an operation requires a license and the license is not present,
no default entry will be created for that operation.

Figure 6-22: AR System Server Group Operation Ranking form
Configuring multiple servers
To establish operation rankings within your server group (for failure
purposes)
1 In BMC Remedy User, log in as a user with Administrator privileges to a server in
the group.
2 Open the AR System Server Group Operation Ranking form in search mode.
This form was automatically imported into the server when the initial server group
member was restarted.
3 Perform an unqualified search to see the existing entries in the form.
By default, the server chosen as the initial server group member has the primary
ranking for all operations. The remaining server group members have null (empty
ranking) entries, serving as placeholders.
Entries for operations that require a license (for example, DSO) are not
prepopulated unless a valid license is detected. You can add these operations at
any time.
4 Modify entries as required to construct a fail-over hierarchy for ownership of
operations.
The servers for any one operation are ranked lowest to highest; a value of 1
indicates the server that will be chosen first to perform the operation. Ranking
numbers do not need to be consecutive, but avoid duplicate numbers. A value of
null will result in the server ignoring the entry. If an operation has no server
designated with a valid rank, it will not run on any of the servers in the group.
Operations can be spread freely across different servers, with the exception of
operations involving BMC Remedy Approval Server, BMC Atrium Configuration
Management Database (CMDB), and the BMC Service Level Management engine
(Business Rules Engine). These operations must reside on the same server as the
administration operation—therefore, the operations must have the same ranking
as the administration operation so that they move as a unit.
In addition to ranking, you can also configure the threshold for determining when
a server is delinquent on this form.
Chapter 6 Configuring servers and clients 167

BMC Remedy Action Request System 7.1.00
168 Configuring
The delinquent threshold is the number of times the specified server has not
reported its status before the next server in the ranking takes responsibility for the
operation. The interval time is set in BMC Remedy User in the Advanced tab of the
AR System Administration: Server Information form.
5 Save the AR System Server Group Operation Ranking form.
6 Restart all the AR System servers in the group.
To remove a server from a server group or to remove all references to an old
server name
1 For removing a server only—In the Configuration tab of the AR System
Administration: Server Information form, clear the Server Group Member check
box.
2 Remove all the entries for the server name in the AR System Server Group
Operation Ranking form.
3 Restart one of the servers in the server group.
The server that you restarted will remove all the server group references for a
server that does not have any ranking entries.
Running a stand-alone AR System server on
Windows
On Windows, you can run a stand-alone AR System server, which is disconnected
from the network (for example, on a laptop computer).
1 Open the C:\WINNT\system32\drivers\etc\hosts file (or the drive on which
Windows server is installed).
To run a stand-alone AR System server
2 Enter the following alias entry:
.
For example:
174.21.8.109 coyote.acme.com coyote
Many configurations of Windows require you to remove all DNS servers when
running as a stand-alone server. This avoids long pauses caused by the Windows
networking software trying to communicate with the network during AR System
interaction. Write down what you removed so that you can add it back when
reconnecting to the network.
3 Save the file.
4 Shut down and restart the system.
The AR System server will now also function when disconnected from the
network.

Configuring firewalls with AR System servers
Configuring firewalls with AR System servers
This section describes the connections required to connect to an AR System server
through a firewall, without using a portmapper. A firewall is a security system that
acts as a protective boundary between a network and the outside world. In the
following figure, the BMC Remedy User client connects to a specific port of the
AR System server. When the user makes a request of the AR System server, the
response is returned on the same TCP connection that makes the request. (BMC
Remedy Administrator and BMC Remedy User use the same port to talk to the
AR System server; therefore, they are configured the same way for firewalls.)
When the AR System server determines an alert is required, it sends the alert
message to BMC Remedy Alert using TCP on the outbound port specified in the
configuration, as shown in Figure 6-23. For more information about setting ports,
see “Server information—Server Ports and Queues tab” on page 128.
Figure 6-23: Transmitting through a firewall
AR System
server
Firewall
Outbound Port
Inbound Port
TCP Call
To enable these connections through the firewall, the AR System server and the
client must be configured to communicate on the proper ports:
AR System server—The AR System administrator assigns a specific port
number in the Server TCP/IP Port box as described in “Assigning TCP port
numbers to AR System servers” on page 128.
Client—The administrator or user configures the Advanced Server Properties
in the Accounts dialog box as described in “To configure Windows clients to
avoid using a portmapper” on page 170. This informs the clients of the location
on the firewall through which they can connect to AR System servers.
ALERT
Remedy
User
Remedy
Alert
Chapter 6 Configuring servers and clients 169

BMC Remedy Action Request System 7.1.00
Configuring clients for AR System servers
170 Configuring
When servers are configured to run on specific TCP ports, the clients need to be
configured to match.
IMPORTANT
The specifics of your firewall configuration vary from manufacturer to
manufacturer. Ask the network and security professionals at your company for
more information.
For more information about TCP port numbers, see “Assigning TCP port numbers
to AR System servers” on page 128.
To access private AR System queues, client machines must either set the
appropriate RPC and TCP values in the Accounts dialog box, or have the ARRPC and
ARTCPPORT environment variables set. Port 111 is used for Portmapper, and it can
be blocked for requests coming through the firewall. Internal requests are be
affected by this rule since Register-With-Portmapper: T is the default
configuration setting of the portmapper. The BMC Remedy User accounts list
should have the port number entered for the AR System server. See the discussion
in “Configuring a server to use plug-ins” on page 171.
You can set these ports in the Advanced Server Properties of the Accounts dialog
box as the following section explains.
To configure Windows clients to avoid using a portmapper
1 In BMC Remedy User, choose Tools > Account to open the Account dialog box.
Figure 6-24: Account dialog box
Advanced Server
Properties check box
2 Select the Advanced Server Properties check box to view the advanced port
columns. Otherwise, you see only the first two columns.

Configuring a server to use plug-ins
3 Click in one of the following columns and type the port number or the private
server number to which you want to connect:
TCP—Represents the port number of the specified AR System server.
RPC—Represents the program number of a private server, if you are using one.
4 Click OK.
5 Log in again to activate these changes.
Configuring a server to use plug-ins
You might want to use plug-ins for these purposes:
AR System database connectivity (ARDBC)—Used to create an AR System
vendor form to access external data. For information about vendor forms, see
the Integrating with Plug-ins and Third-Party Products guide.
AR System external authentication (AREA)—Used to resolve user accounts
against directory services.
AR System filters (ARF)—Used to make a call from workflow to external
services and to capture returned data.
AR System supports the plug-in server and API, but if you have problems with a
specific plug-in, contact the plug-in service provider for assistance.
For more information about creating ARDBC, AREA, or ARF plug-ins, see the
Integrating with Plug-ins and Third-Party Products guide.
1 Modify these settings in the ar.conf file (UNIX) or the ar.cfg file (Windows):
To configure a server to use plug-ins
Plugin (page 276)
Number of threads, for example:
Plugin-ARDBC-Threads (page 277)
Plugin-AREA-Threads (page 277)
Plugin-Filter-API-Threads (page 277)
Plugin-Log-Level (page 278)
Plugin-Port (page 279)
Server-Plugin-Alias (page 283)
Server-Plugin-Default-Timeout (page 283)
These settings are described in Appendix B, “AR System configuration files.”
2 Modify the plug-in target password (page 141).
3 Modify the plug-in log file settings (page 123).
Chapter 6 Configuring servers and clients 171

BMC Remedy Action Request System 7.1.00
Configuring the AR System server for external
authentication (AREA)
172 Configuring
After you install an AREA plug-in, you can set up the AR System server to use
external authentication.
Users can be authenticated externally in three ways. (Two of the three
authentication methods use the authentication string described in the CAPI Reference guide. See also “Setting up an authentication alias” on page 102.)
Depending on your system and configuration, users can be authenticated:
To the operating system (UNIX only)—The AR System server authenticates to
the operating system. Currently, the authentication string has no effect when
authenticating to a UNIX operating system.
To the server domain (Windows)—The AR System server authenticates to the
Windows server domain. If a value has been entered in the Authentication
String field, that value will be used as the domain name to which the AR System
server will authenticate.
To the AREA service—If you have configured external authentication to an
AREA service, the user name, password, and authentication values entered will
be provided to the AREA service.
Before configuring external authentication for an AREA service, you must
configure your server to use plug-ins (see “Configuring a server to use plug-ins”
on page 171). You must also start the plug-in server (see Appendix C, “AR System
server components and external utilities”).
After the service is started, you must set up the server for external authentication
as described in the following procedure.
To configure the AR System server for external authentication
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the External Authentication tab.
3 To enable authentication using an AREA service, set the External Authentication
Server RPC Program Number to 390695.
Entering 390695 enables authentication using an AREA service. Entering no value
or zero (0) disables authentication using an AREA service.
If you enter zero, the AR System server makes no attempt to communicate with the
AREA server.

Configuring the AR System server for external authentication (AREA)
4 Set the RPC and SYNC time-outs for External Authentication.
External Authentication Timeout (seconds) is the amount of time within which the
AREA server must respond to a call from the Plug-in server before an error is
returned. The options are:
RPC—Used when making calls to the AREA server. If set to zero (0), the
AR System server will not invoke the call to the external authentication server.
The default is 30 seconds.
Need To Sync—The interval for periodically invoking the AREA server’s
AREANeedToSyncCallback() call. If set to zero (0), the AR System server will not
invoke the call to the external authentication server. The default is 300 seconds.
5 Select one or both of the following settings:
Authenticate Unregistered Users—Specifies that all users in the User form can
log in and be authenticated internally; users not in the form will be
authenticated externally. If this option is cleared, AR System stops the
validation process and manages the user as a guest user.
Cross Ref Blank Password—Specifies that all users in the User form can log in
and be authenticated externally if the Password field in the form is left blank for
that user. If Cross Ref Blank Password is cleared, a blank Password field in the
User form is treated as no password for that user.
6 Optionally, specify an authentication chaining mode.
Mode Description
Off Disables authentication chaining.
ARS - AREA AR System attempts to authenticate the
user by using the User form and then the
AREA plug-in.
AREA - ARS AR System attempts to authenticate the
user by using the AREA plug-in and then
the User form.
ARS - OS - AREA AR System attempts to authenticate the
user by using the User form, then Windows
or UNIX authentication, and then the AREA
plug-in.
ARS - AREA - OS AR System attempts to authenticate the
user by using the User form, then the AREA
plug-in, and then Windows or UNIX
authentication.
NOTE
For more information about authentication options, see Integrating with Plug-ins
and Third-Party Products guide.
Chapter 6 Configuring servers and clients 173

BMC Remedy Action Request System 7.1.00
174 Configuring
7 Specify Group Mapping options:
Ignore Excess Groups—Specifies that authentication requires that, for a given
user, at least one LDAP group must match an AR System group (not all groups
must match). The non-matching groups will be ignored. If this option is cleared,
authentication occurs only when each LDAP group matches an AR System
group.
Group Mapping—Specifies mappings between LDAP groups and AR System
groups. This eliminates the need for one-to-one matches between LDAP and
AR System groups. If you do not map groups, each LDAP group must have an
exact AR System group match.
TIP
For maximum benefit, use Ignore Excess Groups and Group Mapping together.
8 Save your settings.
The settings you specify persist across server restarts.
Configuring a mail server
To configure a server to process requests sent through email and to send
email notifications on Windows
1 Install BMC Remedy Email Engine.
2 Configure the AR System server for use with BMC Remedy Email Engine.
3 Set up email for requests and searches. This includes the following tasks:
a Establish an email address.
b Set up the mail server.
c Configure additional mailboxes to be used in your organization.
d Start the mail process.
4 Configure email for notifications by creating a notification mailbox.
For more information about installing BMC Remedy Email Engine, see the
Installing guide. For information about configuring BMC Remedy Email Engine,
see the Administering BMC Remedy Email Engine guide.

Configuring a server for alerts
Configuring a server for alerts
To enable users to receive alerts from the server through BMC Remedy Alert, you
need to configure your server.
The earlier Notification Server command-line configuration options are not
available in AR System 5.0 or later. To configure your server for alerts, use BMC
Remedy Administrator as described in the following procedure.
To configure a server to send alerts
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Server Ports and Queues tab, and perform the following steps:
a In the Alert Outbound Port field, enter the port number that the server will use
when sending alerts.
If you enter zero (0), the server will use random port selection.
b Configure the Alert queue to adjust the minimum and maximum threads.
For more information, see “Server information—Server Ports and Queues tab” on
page 128.
3 Click the Timeouts tab, and in the Alert Send Timeout (seconds) field, enter the
number of seconds the server will wait during connection attempts before timing
out.
4 Click the Configuration tab, and perform the following steps:
a Select the Verify Alert Users check box to have the server verify at boot-up time
that each of the users it thinks is registered is still running and listening for alert
messages.
b Select the Disable Alerts check box to have the server refrain from sending alert
messages when alert events are entered into the system.
5 If you want the server to translate IP addresses before sending alert messages to
users, edit the Map-IP-Address option in the ar.conf file, see “Map-IP-Address 2 ”
on page 273.
Chapter 6 Configuring servers and clients 175

BMC Remedy Action Request System 7.1.00
176 Configuring

Chapter
7 Working
with the alert system
The alert system engages when a filter or escalation Notify action sends a
notification through the alert mechanism. This section describes the alert system.
The following topics are provided:
Alert system architecture (page 178)
Alert Events form (page 179)
Viewing alerts (page 180)
CleanupAlertEvents escalation (page 180)
Managing registered users (page 181)
Working with versions of the AR System prior to 5.x (page 181)
Enabling alerts on the Web (page 182)
For information about other methods of notification delivery, see the Workflow
Objects guide.
Chapter 7 Working with the alert system 177

BMC Remedy Action Request System 7.1.00
Alert system architecture
178 Configuring
The alert system consists of the following components:
AR System server
Alert Events form
Alert list on BMC Remedy User or the web client
BMC Remedy Alert, an optional Windows program that informs users when
they receive new alerts (This program should not be confused with the overall
Alert system.)
Figure 7-1 shows how the alert architecture is structured.
Figure 7-1: Alert architecture
BMC Remedy User
Gives administrator access
to Alert Events form and
displays alert list and source
requests.
AR System
ALERT
BMC Remedy Alert
Informs users when
new alerts arrive.
Creates and processes
alert events through the
Alert Events form.
Web Browser
Displays alert list and
source requests.
NOTE
Versions of AR System before 5.0 used a separate Notification server, but now all
alerts are processed on the AR System server. For information about backwards
compatibility, see “Working with versions of the AR System prior to 5.x” on
page 181.
For information about configuring servers for alerts, see “Configuring a server for
alerts” on page 175.

Alert Events form
TIP
If you use BMC Remedy Alert on Windows, you might receive unnecessary
“Server is busy” pop-up messages. This is due to limitations in Microsoft's COM
implementation. To avoid this problem, set the OLE Timeout user preference
under the Desktop section of the ar.ini file. For example:
OLE Timeout = 60 seconds
The default for the OLE timeout is 30 seconds. You might want to try a longer
timeout value.
Alert Events form
If you choose Alert as the notification method when creating a Notify action for
filter or escalation, alerts are recorded as new requests in the Alert Events form
(Figure 7-2) when that workflow executes.
Figure 7-2: Alert events form
The Alert Events form is automatically installed on your server. This form contains
the alert message details and identification information about the source request.
The Alert Events form and its original fields cannot be deleted. To make the feature
more powerful, you can add new fields and workflow to the form.
Users do not interact directly with this form; they receive alerts through the alert
list in BMC Remedy User or through the Web.
Chapter 7 Working with the alert system 179

BMC Remedy Action Request System 7.1.00
Viewing alerts
180 Configuring
The alert list in BMC Remedy User or on the Web displays alerts from multiple
servers. The alert list queries the Alert Events form on servers in to which the user
is logged for BMC Remedy User. For web clients, the alert list queries servers that
are configured in the mid tier. For more information, see “Enabling alerts on the
Web” on page 182.
Users can manage the alert list, and open the source request. They can view alerts
in the following ways:
In BMC Remedy User, choose Tools > View Alerts.
In a browser, display a form that contains an alert list field. This method requires
special configuration. For more information, see “Enabling alerts on the Web”
on page 182.
From BMC Remedy Alert, open the alert list in BMC Remedy User or the
browser. For information about BMC Remedy Alert, see BMC Remedy Alert
help.
If a web user has access to multiple forms that have alert list fields, BMC Remedy
Alert uses the first of those forms that appear in its form list. Therefore, if the user
has permission to multiple forms, you cannot always predict which form will be
used. To solve this issue, you can create multiple forms with alert fields if every
group in the system can access only one of the forms. This option allows you to
create forms with different workflow and different fields for different groups.
CleanupAlertEvents escalation
The CleanupAlertEvents escalation is automatically created with the Alert Events
form. If enabled, this escalation deletes all alerts that are older than 30 days and are
unread.
Initially, the CleanupAlertEvents escalation is disabled. You can enable it and
customize it according to your needs. If you do not need the escalation, you can
delete it from the server.

Managing registered users
Managing registered users
For the alert system, the AR System server maintains a list of registered users in
memory and a backup copy in the database (in the alert_user table). All persistent
information is stored in the database, so you can back up and replicate the
environment easily.
Versions of AR System prior to 5.0 kept this information in the nfylogin and
nfylogu files.
NOTE
A BMC Remedy Alert user should log out before the administrator changes the
user’s password; otherwise, the old user record will be in the alert_user table until
the next alert is sent out.
Working with versions of the AR System prior
to 5.x
Be aware of the following implications when you upgrade clients or servers.
Upgrading the server but not the clients
An upgraded AR System server can service previous notification clients such as
Remedy Notifier. It supports the RPC calls that older clients make. When an older
notification client registers to receive notifications, the server queries the Alert
Events form for any unsent notifications. The AR System server sends alerts
(notifications) to the client in the same format that the older notification server did.
When using Remedy Notifier to log in to a 5.x AR System server, the user must
select the Ntfy Svr option of the Accounts dialog box, even though there is no
Notification server. If a specific Ntfy TCP port is specified, it should be the same as
the port number for the AR System server. If you are going through a firewall, also
specify a listen port within the notification client, as needed.
Upgrading or installing clients but not the server
When new BMC Remedy Alert clients are installed, they cannot connect to
previous Notification servers. The users must install Remedy Notifier to receive
notifications from servers prior to 5.0. If necessary, Remedy Notifier and BMC
Remedy Alert can be run on the same machine in a mixed environment.
Chapter 7 Working with the alert system 181

BMC Remedy Action Request System 7.1.00
Enabling alerts on the Web
182 Configuring
Users who receive alerts can open the alert list on the Web instead of in BMC
Remedy User. To enable alerts on the Web, you must provide a web-based alert
list, and you must set (or instruct users to set) certain user preferences. You can also
install BMC Remedy Alert on Windows clients for additional functionality.
An Alert List form is automatically installed with your server installation. You can
add this form to your web-based applications, or create your own alert list for the
Web as described in the following procedure.
To create and publish a web-based alert list
For more information about how to perform each of the following steps, see the
Form and Application Objects guide and the Installing and Administering BMC Remedy
Mid Tier guide.
1 Create a regular form on one server in your AR System installation where the
mid tier is also installed.
2 Add an alert list field to the form.
3 Make this form accessible on the Web through a URL.
Alternately, users can open the alert list form from BMC Remedy Alert. For more
information, see “To install BMC Remedy Alert and configure web settings
(optional)” on page 183.
To enable a preference server for the Web
1 Make sure that one server in your AR System installation is defined as a preference
server.
For more information about preferences, see Chapter 3, “Setting user preferences,”
and the Installing guide.
2 Under General Settings in the BMC Remedy Mid Tier Configuration Tool, enter
the name of the preference server used by alert system users.
See BMC Remedy Mid Tier Configuration Tool help for more information.

1 Open the AR System User Preferences form in BMC Remedy User.
To configure user preference values for alerts on the Web
2 For each user, set the following preferences.
Enabling alerts on the Web
These preferences are available on the Web view or on the Web tab of the Default
Administrator view of this form. For more information about centralized
preferences, see “Setting centralized preferences on web clients” on page 79.
a In the Alert Servers field, enter the name of each server (separated by commas)
from which users receive alerts.
Alerts from these servers will be visible in the Web-based alert list. Users do not
need to be logged in to these servers to receive alerts or to display the originating
request.
b In the Refresh Interval field, enter the number of minutes between each
automatic refresh of the alert list. A setting of 0 indicates no refresh interval.
Each server specified under Alert Servers will be queried for new alerts, and
these alerts will be displayed in the Web-based alert list.
To install BMC Remedy Alert and configure web settings (optional)
1 Install BMC Remedy Alert on Windows clients, according to the procedures in the
Installing guide.
See BMC Remedy Alert help for information about BMC Remedy Alert.
2 Start BMC Remedy Alert and open the Options dialog box according to the
procedures in BMC Remedy Alert help.
3 In the Alerts tab, select Open Alert List Using Web.
4 In the Server field, enter the name of the AR System server containing the alert list
form.
5 In a browser or BMC Remedy User, open the AR System Administration: Server
Information form for the server specified in step 4.
6 Click the Advanced tab.
7 In the Default Web Path field, specify the URL for the mid tier—for example,
http:///.
For example, if your host name is myserver and you used default settings when
installing the mid tier, the default web path is http://myserver/arsys.
When the user clicks the Open Alert List button in BMC Remedy Alert, the system
locates the form containing the alert list field on the server specified in step 4, and
opens it in the browser. If more than one form on the server has an alert list field,
the system opens the first form that it finds.
Chapter 7 Working with the alert system 183

BMC Remedy Action Request System 7.1.00
184 Configuring

Chapter
8 Importing
data into
AR System forms
BMC Remedy Import is a separate tool installed with BMC Remedy Administrator
and is designed to load data from a source file into an AR System form. A
command line interface (CLI) is also available for both Windows and UNIX ®
platforms. See Integrating with Plug-ins and Third-Party Products for information
about AR System client CLIs.
The following topics are provided:
The import process (page 186)
Preparing to import (page 187)
Defining BMC Remedy Import preferences (page 189)
Importing data (page 199)
Using a saved mapping file (page 204)
Using the import log file (page 205)
NOTE
This section explains how to import data. BMC Remedy Import does not import
object definitions to a server. For information about exporting and importing
definitions, see the Form and Application Objects guide.
Chapter 8 Importing data into AR System forms 185

BMC Remedy Action Request System 7.1.00
The import process
Data mapping
186 Configuring
The import process loads data from a file into an AR System form. To import data
into a form, you must create a mapping that determines which pieces of data to
import into which fields on the target form (mapping), and configure BMC
Remedy Import to handle the import appropriately. This section describes import
concepts, and provides instructions for preparing to import and performing an
import operation.
Mapping takes place during the import process. You can map all fields in a data
file to all fields in a form, or you can map fields individually. You must map data
the first time you import a specific data file into a specific form.
You can also define fallback mappings, which are default mappings that direct the
BMC Remedy Import response if a data mapping problem occurs during an
import. Fallback mappings are used when the data value is invalid for the
destination form field type. For example, if there is a problem while mapping a
value, the fallback mapping for the field is used, if one is defined. If there is no
fallback mapping, an error is generated. If there is a fallback mapping and the
fallback mapping fails, errors are generated on the original failed mapping, not the
fallback mapping.
The fallback mapping is not used when the error can only be detected by the
AR System server, such as when the data is not an acceptable value. For example,
the fallback mapping is not used if the data value is outside the range set for the
form field, or if a required field has a NULL value.
You can save mappings for future use. If you regularly perform a particular
import, saving the mapping saves time and reduces errors, because you load the
mapping file instead of entering the mapping values again. When you save a
mapping, all of the following import information is saved: the form name, the
server the form resides on, the data file name, fallback mappings, and preferences.

Preferences
Preparing to import
Preferences determine tool behavior such as how BMC Remedy Import is
displayed on the screen, and import behavior such as how BMC Remedy Import
resolves conflicts during an import operation.
Preferences can be stored in either of two locations. If you have access to a
preference server, preferences are stored in the AR System Administrator
Preference form on the preference server. If you do not use a preference server,
preferences are stored in the ar.ini file.
When you perform an import, the current preferences will determine how BMC
Remedy Import handles your data. You should verify that the current preferences
are appropriate for the import being performed before you map the data or save the
mapping file. This is important because the preferences are set in the mapping file
when you save it.
When you load a saved mapping file, the preferences specified in the mapping file
take effect. In other words, while a saved mapping file is loaded, BMC Remedy
Import reads preferences from the mapping file instead of the ar.ini file or the
preference server. The next time you log in to BMC Remedy Import, the
preferences from the ar.ini file or the preference server are restored.
If you change preferences while you have a mapping file loaded, you must save
the mapping file again to save the new preferences for that mapping.
For more information about local and central preferences, see BMC Remedy
Administrator help.
Preparing to import
Before you import data into AR System with BMC Remedy Import, complete the
following tasks:
Define BMC Remedy Import preferences. Preferences are saved together with
data mappings (if you save your mappings), so set the preferences before you
save the mapping. See “Defining BMC Remedy Import preferences” on
page 189 for more information.
You might want to set different preferences for different import operations. In
that case, open the source data file and the target form first, and then specify
preferences for that particular import. Save the mapping file according to
step 10 on page 202 to save the preferences for that particular import.
Make sure that there is adequate space where the import log file will reside.
BMC Remedy Import writes error messages and failed records to a log, which
can become quite large. See “Using the import log file” on page 205 for more
information. The default import log path is \import.log. To
specify another path, see “Desktop preferences” on page 190.
Make sure that there is adequate space in the database into which the records
will be imported. Contact your database administrator for assistance.
Chapter 8 Importing data into AR System forms 187

BMC Remedy Action Request System 7.1.00
188 Configuring
Export the source data to a file compatible with BMC Remedy Import. Complete
all edits on the data file before you start BMC Remedy Import. Do not edit the
data file between the time you open BMC Remedy Import and the time you start
the actual import operation. The following table describes the supported data
types.
File Format Information
AR Export (.arx) Default AR System data file type.
Created in BMC Remedy User or the artext utility designed
primarily for localization. To create an AR Export file, see BMC
Remedy User help, or see the Form and Application Objects
guide for information about artext.
AR XML (.xml) XML file conforming to the AR XML data specification.
Contains several elements that are required for AR System use.
See the C API Reference guide for more information.
Created in BMC Remedy User or the artext utility designed
primarily for localization. To create an AR XML file, see BMC
Remedy User help, or see the Form and Application Objects
guide for information about artext.
XML files created outside AR System must conform to the
AR XML data specification. Data exported to the AR XML file
type in BMC Remedy User conforms to this specification.
CSV (.csv) Comma-separated value file.
Created in BMC Remedy User, another application, or the
artext utility designed primarily for localization. For
information about exporting a CSV file in BMC Remedy User,
see BMC Remedy User help. For information about creating a
CSV file with artext, see the Form and Application Objects guide.
Carriage returns are treated as the end of the record.
ASCII (.asc) Generic ASCII file, created in BMC Remedy User with
particular settings, or in another application. To export an
ASCII file from BMC Remedy User, see BMC Remedy User
help.
To use ASCII data obtained from a non-AR System source,
save the data with a unique separator string of up to 32
characters in length. Use \t for tab, \b for backspace, and \\ for
\. Use this separator string when you open a data file to import,
as described in step d on page page 200.
Carriage returns are treated as the end of the record.
Note: You will not be able to import .asc data that uses special
characters as column separators. Unique separator strings
should not appear in any of the field names as well as the data.
This will prevent problems with incorrect numbers of fields
when importing.

Defining BMC Remedy Import preferences
NOTE
When an attachment is exported in AR Export format (*.arx) or AR XML format
(*.xml), a directory is created to store the attachment. The attachment directory is
created in the same directory as the *.arx or .xml file. The file name is appended
with an integer time stamp, like this: myfile_ 917732184.arx. The .arx or .xml file
contains the directory name and the names of the attachment files in it. If duplicate
names exist, prefixes are added to the attachment names to create unique file
names. Attachments cannot be used with CSV and ASCII file types.
Defining BMC Remedy Import preferences
Preferences define important tool behaviors, described in the following table. For
best results, verify that the settings are appropriate before you import data.
Preferences are saved with the data mappings when you save a mapping file.
Preference Function
Desktop Defines the appearance and behavior of BMC Remedy
Import.
Duplicate Request ID Defines how BMC Remedy Import processes records that
contain request IDs, which duplicate those already in the
form.
Error Handling Defines how records that contain errors are processed.
Data Defines how data and values contained in the source data
file are processed.
Date/Time Defines the date and time format of the data in the source
data file.
Confirmations Defines the warnings, messages, and alerts displayed during
imports.
To use preferences from a saved mapping file, see “Using a saved mapping file”
on page 204.
All preferences are defined in the Preferences dialog box, as described in the
following procedure. Additional procedures describe how to set each preference.
To access the BMC Remedy Import preferences dialog box
1 Start BMC Remedy Import.
The main BMC Remedy Import window appears.
2 Choose File > Preferences.
The Preferences window appears.
Chapter 8 Importing data into AR System forms 189

BMC Remedy Action Request System 7.1.00
190 Configuring
Figure 8-1: BMC Remedy Import Preferences dialog box—Desktop tab
3 Use the procedures in the following sections to set preferences.
Desktop preferences
1 Select the Desktop tab in the Preferences dialog box.
To define desktop preferences
2 Set the following preferences:
Preference Function
Maximize Application If the check box is:
Show Status Bar If the check box is:
Show Tool Bar If the check box is:
Save Window
Position and Size on
Close
Cleared (default)—The application window opens to the same
size and position it was when it was last closed.
Selected—The application window is maximized when you
open the application.
Selected (default)—A status bar is displayed at the bottom of
the application window, showing the progress of the current
operation.
Cleared—The status bar is hidden.
Selected (default)—A toolbar containing buttons that
correspond to various menu selections is displayed.
Cleared—The toolbar is hidden.
If the check box is:
Selected (default)—The application window opens to the
same size and position it was when it was last closed.
Cleared—The application window opens to the default size
and position.

Preference Function
Duplicate request ID preferences
To define duplicate request ID preferences
Defining BMC Remedy Import preferences
AR Path This path identifies the directory where mappings are saved. It
is \arcmds by default.
You can browse to a directory or enter the path manually.
Multiple paths must be separated by a semicolon (;). Paths
specified here are inserted in the Save Mapping dialog box.
Import Log File This path identifies the directory and file name of the BMC
Remedy Import log file. It is \arimport by default.
Error details and records that fail during import are written to
this log. Failed records are those that cannot be imported for
some reason. The log file identifies these records, along with
error messages. See “Using the import log file” on page 205 for
more information.
You can specify only one import log in this field, but each import
can use a separate log. To specify a different log for each import,
save a mapping for the import, which saves this path. When you
begin to import, specify the log for the new import and save a
mapping for the new import. When you load a mapping, the
import log path you specified directs BMC Remedy Import to
write to the specified log. Mappings are defined in “Data
mapping” on page 186.
Reset Log File at Login If the check box is:
Selected (default)—The import log is cleared each time you
start BMC Remedy Import.
Cleared—New entries are appended to the existing file. The
file can grow large.
1 Select the Duplicate Request ID tab in the Preferences dialog box.
Chapter 8 Importing data into AR System forms 191

BMC Remedy Action Request System 7.1.00
192 Configuring
Figure 8-2: BMC Remedy Import Preferences dialog box—Duplicate Request ID tab
2 Set the following preferences:
Preference Function
Generate New ID for Default setting.
All Records
New request IDs are assigned to all requests in the data file,
whether or not any IDs are duplicates. This preference also
generates request IDs for records that do not already have them,
for example, in a CSV file created outside AR System.
Reject Duplicate Entries are imported using their existing IDs. If an ID is already
Records
in use, an error is generated. The error is processed according to
your preferences. See “Error handling preferences” on page 193
for more information.
Generate New ID for Entries are imported using their existing IDs. If a record with the
Duplicate Records same ID already exists in the database, a new ID is generated for
the imported record with the duplicate ID.
Replace Old Record Entries are imported using their existing IDs. If a duplicate ID
with New Record exists, the entire database record is overwritten wit the record
being imported. You must map the required core fields with this
option. If required core fields are not mapped, the server rejects
the records. See “Importing data” on page 199 for more
information about mapping.
Update Old Record Entries are imported using their existing IDs. If a duplicate ID
with New Record’s exists, only the fields being imported are replaced, merging the
Data
record.
Note: If you choose this option, BMC Remedy Import actually
deletes the record and reinserts it to perform the “update.”
This setting also automatically makes all required fields that are
not core fields optional. See “Data preferences” on page 194 for
more information about preferences related to required fields.

Error handling preferences
1 Select the Error Handling tab in the Preferences dialog box.
To define error handling preferences
Defining BMC Remedy Import preferences
Figure 8-3: BMC Remedy Import Preferences dialog box—Error Handling tab
2 Set the following preferences:
Preference Function
Alert User with Popup
Dialog
Interrupts the import and displays an error message (default).
The message contains three choices:
Yes—Skips the problem record, writes the error and the
record data to the import log, and continues to import
remaining records.
Yes to All—Skips all problem records that generate the
same error, writes the error and the records to the import
log, and continues to import remaining records.
Stop Import—Stops the import and prompts you to copy all
remaining data to the import log. See “Using the import log
file” on page 205 for more information.
Skip Bad Records Skips problem records without displaying an error message,
and continues with the import.
Try Fallback Mapping
before Alerting User
If a mapping generates an error, BMC Remedy Import uses
the fallback mapping specified in the Fallback Mapping
preferences. If the fallback mapping also generates an error, a
message is displayed. The error is generated against the
original mapping error. Errors are not generated against
fallback mappings. See “Error handling preferences” on
page 193 for more information.
Chapter 8 Importing data into AR System forms 193

BMC Remedy Action Request System 7.1.00
Data preferences
194 Configuring
Preference Function
Import Records with Too
Many Fields
Import Records with Too
Few Fields
1 Select the Data tab of the Preferences dialog box.
To define data preferences
Defines how AR System imports records that contain more
fields than described by the field titles in the data file. The
system checks each record.
If the check box is:
Cleared (default)—The problem records are not imported
and an error is generated. The error is processed according
to your preferences. See “Error handling preferences” on
page 193 for more information.
Selected—The problem records are imported and the extra
fields are ignored.
Defines how AR System imports records that contain fewer
fields than described by the field titles in the data file. The
system checks each record.
If the check box is:
Cleared (default)—The problem records are not imported
and an error is generated. The error is processed according
to your preferences. See “Error handling preferences” on
page 193 for more information.
Selected—The problem records are imported with NULL
values in the missing fields.
Figure 8-4: BMC Remedy Import Preferences dialog box—Data tab

Defining BMC Remedy Import preferences
NOTE
These settings are affected by field attributes set when fields are defined. See the
Form and Application Objects guide for more information.
2 Choose one of the following options for character fields:
Preference Function
Remove leading and If the check box is:
trailing spaces and
tabs
Truncate strings
exceeding field limit
Disable fields’ pattern
matching during
import
Cleared (default)—Values are imported exactly as they appear
in the data file.
Selected—All leading and trailing white space is removed
from each field imported.
If the check box is:
Cleared (default)—Fields whose contents are too long
generate an error. The error is processed according to your
preferences. See “Error handling preferences” on page 193 for
more information.
Selected—Fields that are too long are truncated.
Defines if pattern matching is enforced by the server during the
import.
If the check box is:
Cleared (default)—Records are rejected by the server if data in
the field does not match the specified pattern. The error is
processed according to your preferences. See “Error handling
preferences” on page 193 for more information.
Selected—Records are imported, even if the data in a field
does not match the specified pattern.
3 For required fields that are not core fields, choose the following option:
Preference Function
Make required fields
optional during
import
Defines required fields that are not core fields as optional during
the import.
If the check box is:
Cleared (default)—All required fields are treated as required.
If a required field has a NULL value, an error is generated. The
error is processed according to your preferences. See “Error
handling preferences” on page 193 for more information.
Selected—Records are imported, even if the data in a field
does not match the specified pattern.
Chapter 8 Importing data into AR System forms 195

BMC Remedy Action Request System 7.1.00
Date and time preferences
196 Configuring
1 Select the Date/Time tab of the Preferences dialog box.
To define date and time preferences
Figure 8-5: BMC Remedy Import Preferences dialog box—Date/Time tab
BMC Remedy Import accepts short or long date formats in the data file, and
ignores leading zeros.
2 Select the appropriate options.
Preference Function
Calendar Type The default Gregorian calendar is the only choice.
Short Date Format If you select:
M/d/yyyy—12/31/2006 (default) is displayed.
d/M/yy—31/12/06 is displayed.
yy/M/d—06/12/31 is displayed.
The sample text shows how the selected format appears. The
component order is based on the Regional Settings in the
Windows Control Panel.
Separator (Date Format) Defines the separator character between the month, day/
and year, with a slash(/) as the default. You can use any
character that is not part of the field separator string for the
data file. The sample text shows the appearance.

Preference Function
Long Date Format If you select:
Confirmation message preferences
1 Click the Confirmations tab of the Preferences dialog box.
To define confirmation message preferences
Defining BMC Remedy Import preferences
dddd, MMMM d, yyyy—Thursday, August 16, 2007 is
displayed.
dddd, d MMMM, yyyy—Thursday, 16 August, 2007 is
displayed.
dddd, yyyy MMMM d—Thursday, 2007 August 16 is
displayed.
dddd, MMMM dd, yyyy (default)—Thursday, August 16,
2007 is displayed.
The sample text shows the appearance. The component
order is based on the Regional Settings in the Windows
Control Panel.
12 Hr Tracks in the 12-hour clock (default).
24 Hr Tracks in universal time.
AM/PM position Enabled for 12 Hr only.
If you select:
Suffix (default)—The symbol is positioned after the time
string (for example, 10:23:47 AM).
Prefix—The symbol is positioned before the time string
(for example, AM 10:23:47).
AM symbol Enabled for 12 Hr only. Defines the symbol that will indicate
morning.
PM symbol Enabled for 12 Hr only. Defines the symbol that will indicate
afternoon.
Separator (Time Format) Defines the time format separator between the hours,
minutes, and seconds, with a colon (:) as the default. You can
use any character that is not part of the field separator strong
for the data file. The sample text shows the appearance.
Chapter 8 Importing data into AR System forms 197

BMC Remedy Action Request System 7.1.00
198 Configuring
Figure 8-6: BMC Remedy Import Preferences dialog box—Confirmations tab
2 Select the appropriate options:
Preference Function
Confirm before deleting all
Mappings
If the check box is:
Confirm before losing
Mappings
Confirm before losing Fallback
Mappings
Confirm before losing New
Mapping Value
3 Click OK.
Selected (default)—A confirmation message
appears when you click Delete All in either the
Import window or in the Fallback Mappings dialog
box.
Cleared—No confirmation message appears.
If the check box is:
Selected (default)—You are prompted to save your
work each time you select a new form or file or exit
BMC Remedy Import without first saving.
Cleared—No prompt appears.
If the check box is:
Selected (default)—You are prompted to save your
work each time you create a fallback mapping,
select a new form or file, or exit BMC Remedy
Import without first saving.
Cleared—No prompt appears.
If the check box is:
Selected (default)—A confirmation message
appears when you add or modify a mapping value
without clicking Add or Modify before exiting the
window or starting the import.
Cleared—No confirmation message appears.

Importing data
Import procedure
Importing data
Importing data into a form involves loading a data file and a target form, defining
preferences for the import, and mapping data. To import data into a form, you
must have Change permissions for the fields to which you want to import data. For
system fields such as Create-date, you must be the administrator or
subadministrator of the form.
The following procedure provides instructions for importing data.
To import data
1 Start BMC Remedy Import.
2 Log in, if necessary, according to your defined preferences.
The BMC Remedy Import window appears.
Figure 8-7: BMC Remedy Import window
3 Choose File > Open Form.
The Open Form dialog box appears.
4 From the Form Name list, select the destination form into which you want to
import the data.
5 Click OK.
The destination form field names appear in the Form Fields list.
Chapter 8 Importing data into AR System forms 199

BMC Remedy Action Request System 7.1.00
200 Configuring
6 Choose File > Open Data File.
The Open Data File dialog box appears.
Figure 8-8: Open Data File dialog box
7 Select the data file to import.
a From the Files of Type field list, select the file format.
Selecting All Files displays all data files, whether or not the formats are valid
import types. Selecting a data file with an invalid import format generates an
error.
b Navigate to the target data file and select it.
The file appears in the File Name field.
c If you chose CSV or ASCII as the file type, choose a title handling option:
If the first line of data contains titles, leave the File Contains Field Titles check
box selected so that BMC Remedy Import will not convert the titles into data.
If the first line of data does not contain titles, clear this check box.
The check box is disabled for other file types.
d For ASCII format, enter the separator string you used when you created the
ASCII data file in the Field Separator field.
ASCII files must be generated with specific settings to be compatible with BMC
Remedy Import. See BMC Remedy User help for information about separator
strings.
e Click Open.
The fields from the data file are loaded.

Importing data
NOTE
If the data file contains duplicate field titles, an error is generated. If the data is
.arx or .xml format, the field titles will appear as their field IDs. If the data file is
.csv or .asc format, the fields will display with an appended number, as follows,
[1], [2], and so on.
8 Specify how the data in the source file will map to the fields in the destination form
using one of the following methods:
Map all data file fields to form fields.
Map individual data file fields to form fields.
BMC Remedy Import matches data fields to form fields as follows:
AR Export or AR XML—Field IDs are matched first, and then field names are
matched for fields without matching IDs.
CSV or ASCII—Only field names are matched.
To map all data file fields
click Add All in the BMC Remedy Import window.
Keep the following tips in mind when mapping all data file fields:
Make sure that all fields map correctly. If necessary, resolve unmatched or
incorrectly matched fields by mapping those fields individually.
If the matching is partially successful, all possible matches are added. To
complete the mapping, map remaining fields individually.
If no matches are found and no entries are left in the Form Fields list, an error is
generated. You can delete existing mappings and map fields individually, or
start the import with the partial mapping.
If no fields are mapped, an error is generated, and you must load a mapping or
map fields manually.
To map individual data file fields
a From the Form Fields list, select the destination field.
b In the Mapping Values section, select Import Fields or Keywords from the
selection menu.
A list of the fields in the data file or a list of keywords is displayed, depending
on your choice.
Chapter 8 Importing data into AR System forms 201

BMC Remedy Action Request System 7.1.00
202 Configuring
c Choose one of the following options:
From the Import Fields list, select the data field to map to the destination field
that you selected in step a. The field name appears in the Mapping Value
field.
From the Keywords list, select the keyword to map to the destination field
that you selected in step a. You can also type field names, keywords, or any
constant string into the Mapping Value field.
For example, suppose you select the Create Date field in the Form Fields list,
and you want each record in the destination form to have today’s date as the
value in the Create Date field. Choose Keywords as the mapping value, and
then choose DATE in the Mapping Values list. The resulting value in the
destination form is the date of the import. For more information about
keywords, see the Workflow Objects guide.
d Click Add to create the mapping.
e Repeat these steps for each field to be mapped.
NOTE
Map the Request ID field of the destination form. If you do not map this field, you
must set the Duplicate ID preference to Generate New IDs for All Records, or you
will receive errors.
9 Optionally, specify default field values by defining fallback mappings. See
“Defining fallback mappings” on page 203 for more information.
10 Optionally, save the mapping. See “Saving a mapping” on page 204.
You are now ready to start the import.
11 Choose Import.
A confirmation dialog box appears.
12 Click Yes to start the import.
A status window appears, listing the number of records processed. Each record in
the data file generates a single request in the destination form.
If errors occur, the type of messages you receive depends on the error handling
preferences you set. See “To define error handling preferences” on page 193.
Stopping an import
After the import ends, a results message appears and the import log is updated.
You can use your imported data. To inspect the log, see “Using the import log file”
on page 205.
You can stop an import before it ends. You are prompted to copy unprocessed
records to the log. There must be enough disk space in the import log partition to
copy the records.

Defining fallback mappings
Importing data
To define a fallback mapping
1 Choose Mapping > Define Fallback.
The Fallback Mappings dialog box appears, displaying the destination form fields
and a list of keywords.
Figure 8-9: Fallback Mappings dialog box
2 From the Form Fields list, select the field for which you want to define a fallback
mapping.
The selected field appears in the Form Field field.
3 Choose one or more keywords by performing one of the following actions:
Select a keyword from the Keywords list.
Enter a string or keyword into the Fallback Mapping Value field.
Enter multiple keywords by separating each value with a space or other
character.
4 Click Add.
The mapping is added to the list. You can edit or delete one or more mappings
using Modify.
Chapter 8 Importing data into AR System forms 203

BMC Remedy Action Request System 7.1.00
Saving a mapping
204 Configuring
To save a mapping
1 Choose Mapping > Save Mapping.
The Save Mapping dialog box appears.
Figure 8-10: Save Mapping dialog box
2 Enter a name in the Mapping Name field.
3 Enter the mapping directory in the Path field, by selecting a directory from the list
(the AR Path defined in the Desktop preferences), selecting Browse to choose a
directory, or typing a path.
4 Optionally, enter a description of the mapping in the Help Text field.
5 Optionally, select the Save Log Filename check box.
When you select this box, the log specified in this procedure is set in the Import
Log File field in the Desktop preferences when you load this mapping.
6 Click OK to create the mapping.
Using a saved mapping file
If you have saved a mapping file from a previous import, you can load that
mapping file instead of entering mapping information again.
Mappings save the BMC Remedy Import preferences currently set at the time the
mapping is created, so if you load a mapping file, BMC Remedy Import will use
the preferences that were set when you saved the mapping file. You can change
preferences as needed and save the mapping file again.
The next time you start BMC Remedy Import, the preferences you set for the
application are restored.
BMC Remedy Import reads and writes mappings in PC format, with CR LF at the
end of each line.

To load a mapping
1 Choose Mapping > Load Mapping.
The Load Mapping dialog box appears.
Figure 8-11: Load Mapping dialog box
Using the import log file
2 From the Search Path field, select the directory that contains the mapping.
Selecting All lists all saved mappings and their directories.
3 From the Mappings list, select the mapping.
The directory containing the selected mapping appears in the Mapping Path field.
4 Click OK.
The mapping is loaded into the Import window, the Fallback Mappings dialog
box, and Preferences dialog box.
Using the import log file
BMC Remedy Import writes errors to the import log, whether or not you set error
messages to display on screen. The default path is \arimport.log,
however, you can specify another directory or file name in the preferences. See “To
define desktop preferences” on page 190.
The import log contains more detail than displayed messages. With AR Export,
CSV, and ASCII file types, failed records are also written intact to the import log.
You can convert the import log to a data file that you can import. See the following
sections for details.
Chapter 8 Importing data into AR System forms 205

BMC Remedy Action Request System 7.1.00
AR XML data
All other data types
206 Configuring
To write XML (*.xml) data from AR XML records to the import log, you must use
the Alert User with Popup Dialog preference setting, as described in “To define
error handling preferences” on page 193. This setting stops the import and copies
the records to the file.
You can inspect the import log file to determine which records caused errors, and
make corrections in the original AR XML data file. You can then import the
corrected AR XML data file. With AR XML files, XML data from the record is
written to the log file, but the structure of the record is not retained in a way that
allows the log file to be converted to an import file.
After the import is complete, open the import log to identify problems. You can
then either correct the data in the log and convert the log to a data file that you can
import, or correct the original data file and import the file again.
If you edit the original data file, delete any data that was imported successfully
during the original import from the file to avoid creating duplicate entries.
To import data from the import log
1 If the import is not complete, stop the import and copy the remaining records to
the import log.
2 Open the import log (\arimport.log by default).
3 Remove all nondata information (all lines except DATA lines) from the import log.
For CSV and ASCII file types, go to step 5.
4 For AR Export (.arx) file types only—Copy the following lines of code from the
data file to the import log (these lines appear at the beginning of the data file): FORM,
FIELD, FLD-ID, DTYPES
5 Save the edited import log as an AR Export (*.arx) file.
6 Import this AR Export (*.arx) file.

Chapter
9 Using
full text search
This section discusses the capabilities, performance, and administration of the full
text search (FTS) feature. The following topics are provided:
Overview of full text search (page 208)
Who can perform a full text search? (page 210)
Using FTS (page 210)
Limitations of FTS (page 219)
Administering FTS (page 220)
Upgrading FTS (page 227)
Assigning FTS licenses to users (page 228)
Defining a field for FTS in the Field Properties window (page 229)
NOTE
Full text search is an optional feature that you can purchase for the AR System
server.
Chapter 9 Using full text search 207

BMC Remedy Action Request System 7.1.00
Overview of full text search
208 Configuring
Full text search (FTS) is an important and useful feature of AR System. FTS is
typically much faster than using the native database searching functionality when
searching in a long text field. It is also the only method available in AR System for
searching text within attached documents.
A benefit of FTS is that you can make use of your knowledge base. For example,
FTS enables you to access your company’s history of solving problems, which are
sometimes stored in long text fields or attachments. With the FTS option, you can
easily search through long text fields to find solutions to related problems. You
might even want to redesign forms to require users to enter data into diary or long
text fields. You can then build up a knowledge base that helps you learn from
previous experience.
FTS provides quick and consistent access to AR System requests for which you are
searching. The FTS accrue operator presents the best solutions to your search first
by using a weighted order. The accrue operator enables you to use multiple search
terms in a search; for example, computer, PC, and error number 3794. Requests that
contain the most search terms appear higher on the list (if ordered in descending
order of weight) and are more likely to contain the information for which you are
looking. In contrast, if a database OR search yielded 20 requests, you must look
through all 20 requests because you would not know which requests contain what
information. For more information, see “Accruing and weighting results with
FTS” on page 209.
FTS solves many problems that users encounter when performing database
searches, including:
Searching long text and attachment fields. The FTS option enables you to index
character, diary, and attachment fields for searching, and then matches entries
from those fields against the search criteria you specify. Like database indexes,
an FTS index can greatly decrease the time required for a database search.
Improving search performance by searching large volumes of data. FTS
organizes text in a way that typically provides quicker access than relational
databases.
Defining how the server interprets wildcards to customize search performance
to your specific needs.
Performing case-insensitive searches. Administrators can enable or disable case
sensitivity.
Ranking search results according to their relevance to the search criteria. The
more relevant a search result is, the higher the weight assigned to it will be. For
more information, see “Accruing and weighting results with FTS” on page 209.

Accruing and weighting results with FTS
Overview of full text search
Weighting the results of an accrue search is a powerful FTS feature. FTS does not
limit you to searches for keywords in fields indexed for FTS. You also can use a
special accrue operator (the LIKE operator with comma-separated words, for
example) to cause AR System to accrue and retrieve from the database all requests
that contain any or all of the comma-separated words.
Requests that are retrieved in an accrue operation are assigned a weight by the FTS
engine. Weight is a number that varies from 0 to 100. With weight, AR System can
sort requests in a results list using a “the more, the better” approach. If you set the
Field Sort Order in BMC Remedy User to include WEIGHT in descending order,
the more search terms found in a request, the higher in the list it appears in the set
of retrieved requests. The closer Weight is to 100, the better it matches the search
criteria.
For more information about modifying results list attributes to include FTS
weights, see “Displaying FTS weight in a results list” on page 231.
Sorting requests by weight
In BMC Remedy User, if WEIGHT has been added to the results list for a form,
users can sort the requests that are retrieved by FTS by weight in descending or
ascending order by selecting WEIGHT and the sort order in the Field Sort Order
window. For more information about setting the sort order, see BMC Remedy User
help.
Using the Ignore Words List
You can configure the FTS engine to ignore frequently used words (such as and, the,
because, and so on) or words that you do not want indexed. Adding entries to the
Ignore Words List saves space in the FTS index and speeds up text searches. The
FTS option comes with a default set of ignored words that you can modify as
needed.
Accrue searches that contain words from the Ignore Words List do not find any
matching AR System requests for those words. However, the accrue search
retrieves requests for the other search terms. For restrictions on FTS, see
“Limitations of FTS” on page 219.
NOTE
The Ignore Words List is different for each supported language.
Chapter 9 Using full text search 209

BMC Remedy Action Request System 7.1.00
Who can perform a full text search?
Using FTS
210 Configuring
Users must have a fixed or floating FTS license to use the FTS capability. FTS
licenses are separate from AR System read/write licenses.
If users are assigned a fixed FTS license, they can always perform a search in a
field indexed for FTS.
If users are assigned a floating FTS license but one is not currently available,
they receive a warning the first time they perform a database operation in BMC
Remedy User. The system uses the search capabilities of the underlying
database (to the degree available). Upon a subsequent search, when a floating
license becomes available, an affected user is alerted with a note and can
perform a search by using the FTS capability.
For more information about who can use full text search, see “Assigning FTS
licenses to users” on page 228.
FTS is transparent to users who have an FTS license (fixed or floating). If there is at
least one FTS fixed or floating license in the AR System server, full text indexing
will be activated.
If an FTS license is available and the field is indexed for FTS, then FTS is used.
If an FTS license is unavailable or the field is not indexed for FTS, AR System
uses the search capability of the underlying database. Under these conditions,
attachment fields will have only their names searched.
Field permission-related behavior for FTS fields is the same for non-FTS fields.
Users enter search criteria in the same way, whether they are using FTS or not, with
the exception of accrual searches.
Performing a search in a field indexed for FTS
In most cases, performing a qualified search on a field indexed for FTS returns
results consistent with a database search. Users can still use the search strings and
search patterns with which they are already familiar. FTS offers additional
benefits. For example, if your database does not support case-insensitive searches,
FTS can provide that capability. Unlike some databases, the FTS engine enables
you to index and search large text fields for any words in the entire field. Users
will notice enhanced search performance with large text fields because of this
indexing capability. Also, FTS enables you to index attached documents, allowing
the contents of supported document types to be searched quickly and efficiently.

The search method used by the FTS engine depends on the following factors:
The original search criteria as entered by the user
The QBE match settings of the field
The FTS Search Options setting of the server
The type of full text index created for the field
Using FTS
FTS uses these factors to determine the final search criteria. Succeeding factors
override preceding factors. For example, if a user includes a leading wildcard as
part of a full text search, but the FTS Search Options setting is set to Ignore Leading
Wild Card, FTS ignores the wildcard entered by the user. See “How QBE settings
affect FTS” on page 217 for more information.
The FTS engine uses the final search criteria to search the contents of all requests
indexed for that field, and it uses one of three search methods:
Word or Phrase search
Accrue search
Literal search
NOTE
All the following examples use FTS in the Advanced Search Bar, not QBE. They
assume that the FTS Search Option is set to Query Unchanged.
Word or Phrase search
During a word or phrase search, the FTS engine finds requests that contain the
specified word or phrase in the field. To perform a word or phrase search, use
double-quotation marks around the words you want to search for. The syntax for
the search qualification is:
LIKE " . . . "
For example, to search for the phrase “firewall blocked”, type:
LIKE "firewall blocked"
With this example, a full text search will find requests with the phrase “firewall
blocked” with the search for blocked expanded to the word stem block with any of
its variants.
NOTE
The use of wildcards in a Word or Phrase search affects how stemming is used. For
more information about stemming, see “Searching for word stems” on page 216.
Chapter 9 Using full text search 211

BMC Remedy Action Request System 7.1.00
212 Configuring
The following table outlines the expected search results using a word or phrase
search.
Qualification Example data Matches
LIKE “firewall blocked” firewall blocks access x
firewall will block access
firewall blocking my access x
firewall blocked her access x
firewall did not block access
have the firewall block access x
firewall is not working
try blocking his access
LIKE “%firewall block%” firewall blocks access x
firewall will block access
firewall blocking my access x
firewall blocked her access x
firewall did not block access
have the firewall block access x
firewall is not working
try blocking his access
LIKE “%firewall blocks%” firewall blocks access x
firewall will block access
firewall blocking my access
firewall blocked her access
firewall did not block access
have the firewall block access
firewall is not working
try blocking his access
LIKE “blocks” firewall blocks access x
firewall will block access x
firewall blocking my access x
firewall blocked her access x
firewall did not block access x
have the firewall block access x
firewall is not working
try blocking his access x

Accrue search
Using FTS
Qualification Example data Matches
LIKE %blocks%” firewall blocks access
firewall will block access
firewall blocking my access
firewall blocked her access
firewall did not block access
have the firewall block access
firewall is not working
try blocking his access
x
During an accrue (OR) search, the FTS engine finds requests that contain any of the
specified words in a field, instead of matching a string of characters. The FTS
engine matches the pattern of the characters specified in the search. To perform an
accrue search, use double quotation marks around the words you want to search
for, separating the words with a comma. The comma is the accrue operator. The
syntax for the search qualification is:
LIKE ", . . . ”
For example, if you wanted to search for the words “firewall” and “blocked,”
enter:
LIKE “firewall,blocked”
With this example, a full text search will find requests with any occurrence of the
words firewall or blocked with the search for blocked expanded to the word stem
block with any of its variants.
NOTE
You can use the accrue operator only with fields indexed for FTS. Using the same
operator for a field that is not indexed for FTS causes the AR System server to
search for the literal string with a database search.
The following table shows the expected search result using an accrue search.
Qualification Example data Matches
LIKE
firewall blocks access x
“firewall,blocking”
firewall will block access x
firewall blocking my access x
firewall blocked her access x
firewall did not block access x
have the firewall block access x
firewall is not working x
try blocking his access x
Chapter 9 Using full text search 213

BMC Remedy Action Request System 7.1.00
214 Configuring
Qualification Example data Matches
LIKE
firewall blocks access x
“firewall,blocked%”
firewall will block access x
firewall blocking my access x
firewall blocked her access x
firewall did not block access x
have the firewall block access x
firewall is not working x
Literal search
Unlike accrue or word/phrase searches (which are word-based), the FTS engine
uses a literal search to find requests that match the string of characters based on the
contents of the entire field. Literal searches are possible only if the field has been
indexed for literal searching and if it is, only literal searching is possible, not accrue
or word/phrase searches. This type of searching is useful mainly for performing
case-insensitive searching on short character fields, like name fields, with a very
small set of requests matching the search criteria. However, you can add either a
leading or trailing wildcard to increase the scope of a literal search. If you use both
a leading and trailing wildcard, a literal search becomes the equivalent of a word/
phrase search. The syntax for the search qualification is:
LIKE “”
For example, to search for the word “firewall,” enter:
LIKE “firewall”
try blocking his access
With this example, a full text search will find requests where the entire content of
the field is firewall (or Firewall if searching with case insensitivity).
The following table outlines the expected search results using a literal search.
Qualification Example data Matches
LIKE “firewall” firewall blocks access
firewall will block access
firewall blocking my access
firewall blocked her access
firewall did not block access
have the firewall block access
firewall is not working
try blocking his access

LIKE “firewall will
block access”
firewall blocks access
firewall will block access x
firewall blocking my access
firewall blocked her access
firewall did not block access
have the firewall block access
firewall is not working
LIKE “%firewall%”
try blocking his access
firewall blocks access x
firewall will block access x
firewall blocking my access x
firewall blocked her access x
firewall did not block access x
have the firewall block access x
firewall is not working x
LIKE “firewall%”
try blocking his access
firewall blocks access x
firewall will block access x
firewall blocking my access x
firewall blocked her access x
firewall did not block access x
have the firewall block access
firewall is not working x
Using FTS
Qualification Example data Matches
try blocking his access
LIKE “blocks” firewall blocks access
firewall will block access
firewall blocking my access
firewall blocked her access
firewall did not block access
have the firewall block access
firewall is not working
try blocking his access
Chapter 9 Using full text search 215

BMC Remedy Action Request System 7.1.00
Searching for word stems
216 Configuring
The FTS engine uses stemming to search for common variations of word stems. For
example, a word search for the term “block” returns requests containing these
terms:
block
blocks
blocked
blocking
Using wildcards
Qualification Example data Matches
LIKE “%blocks%” firewall blocks access x
firewall will block access
firewall blocking my access
firewall blocked her access
firewall did not block access
have the firewall block access
firewall is not working
try blocking his access
Searching for “blocking” returns the same set of requests.
Stemming is not used in the following searches:
Wildcard searches—For example, if the search term is “%blocking%,” only
requests containing “blocking” are returned.
Case-sensitive searches—For example, a case-sensitive search for “block”
returns only requests containing “block.”
You can also use the percent sign (%) wildcard for any type of search to broaden
the set of matching requests. For example searching with the term “%fire" will
return requests with “fire” and “backfire”. Searching with “fire%" will return
requests with “fire" and “firewall”. Searching with “%fire%” will return all
combinations.

Using the QBE method
Using FTS
Searches performed by the QBE method are affected by the QBE Match property
for the field. If the property is not set to Equal, appropriate wildcards will be
added to the search terms automatically. If the property is set to Equal, you must
add the appropriate wildcards to the search terms.
NOTE
Attachments cannot be searched with the QBE method unless a special Form
Search field is present on the form. For more information, see “Adding a form
search field to a form” on page 218.
How QBE settings affect FTS
Enter a query by example (QBE) in any field indexed for FTS, according to the
following syntax:
left,center,right
However, be aware that the property settings influence how an accrue search
works, as shown in the following table.
QBE Match property setting Effect on search criteria
Anywhere %left,center,right%
BMC Remedy User adds wildcards to the start and end of
the search. The server makes a special interpretation of
these search criteria for a full text search and places a
leading and trailing wildcard around each search term. For
example:
%left%,%center%,%right%
Leading left,center,right%
BMC Remedy User adds a wildcard to the end of the
search. The server makes a special interpretation of these
search criteria for a full text search and places a trailing
wildcard after each search term. For example:
left%,center%,right%
Equal left,center,right
BMC Remedy User does not add any wildcards to the
search string, but it uses the EQUAL (=) operator instead of
the LIKE operator. This has no effect on the server’s full
text search.
Using the advanced search bar method
Searches performed by the advanced search bar method are affected by the FTS
Search Options setting for the server. Otherwise, the search qualification is exactly
as specified.
Chapter 9 Using full text search 217

BMC Remedy Action Request System 7.1.00
Adding a form search field to a form
218 Configuring
AR System has a special reserved field that can be used on a form to provide a
shortcut method for specifying expanded FTS qualifications. If a display-only field
with field ID 178 is added to a form, that field can be used to search all full text
indexed fields on a form with an expanded OR search. For example, if the
Description and Worklog fields on a form have been indexed for FTS and the user
performs a QBE search by supplying the search term firewall in field 178, the
qualification generated on the server will be:
'Description' LIKE "firewall" OR 'Worklog' LIKE "firewall"
On a form where a single attachment field is the only field indexed for FTS, this
feature can also be used as a method for providing a QBE search for the attachment
field. Otherwise, only the advanced search bar method is available for searching
attachments.
IMPORTANT
Use caution when labeling this field, so users do not get the impression that using
this field will search all fields on the form. The feature searches only fields indexed
for FTS.
NOTE
This feature is available only from version 7.0 or later clients. For environments
with pre-7.0 clients, it is recommended that you hide this field for those clients
using client-side workflow when $VERSION$ < " 7" (there is an intentional blank
space in front of the 7). If the field is visible and used in pre-7.0 clients, the
qualification will not be sent to the server (unbeknownst to users), potentially
resulting in an unqualified query.
Also, for users without a full search text license, the AR System server will return
an error if a qualification is provided in this field.
Parametric full text search
Returning a large result set is a common issue with a search system. With a
parametric full text search, a user can restrict the search criteria by combining FTS
and non-FTS fields in a search. This feature helps the server filter out irrelevant
entries and dramatically reduce the size of the result set. This can be accomplished
by providing search terms in multiple fields for a QBE search or specifying an
advanced search like the following example:
: LIKE "firewall" AND 'Create Date' >= "01/01/06"
This advanced search bar search will return all entries that contain the search term
“firewall” and were created on or after January 1, 2006.

Search strategies
Search issues
Limitations of FTS
When searching field for which FTS is enabled, consider the following tips and
strategies:
Make your searches as specific as possible. The more qualified your searches
are, the better the indexes can be utilized to return only the most relevant entries.
A smaller result set will produce a quicker response time.
Remove common words from accrue searches. For example, if you use the
accrue operator with five search terms and the search yields hundreds of
requests, delete the most generic terms from the search criteria to focus your
search on a smaller result set.
When using the advanced search bar, group references for FTS fields at the
beginning of the search criteria.
Keep the following issues in mind when creating searches:
Full text searches that involve a field reference to the right of the relational operator
are not supported. A warning message occurs which indicates that the query was
treated as a database query instead of an FTS query. The presence of ‘Target’ in the
following example returns the warning message if the Short Description field is
indexed for FTS:
'Short Description' LIKE 'Target' + "ing"
If there are no variables to the right of the LIKE keyword in the statement, FTS
handles the search. For example:
'Short Description' LIKE "block" + "ing"
In this example, the search is handled by FTS because the two known values
(“block” and “ing”) are combined to form one known value (blocking).
Limitations of FTS
Limits to performing a full text search include:
In accrue searches, you cannot search for most punctuation marks because they
are treated as word separators.
In accrue searches, do not use words from the Ignore Words List. For example,
if the word the is in the Ignore Words List, searching on the phrase the, database,
request in the Short Description field might return requests with the word the in
them, but it is not used in the search itself. For additional information about the
Ignore Words List, see “Using the Ignore Words List” on page 209.
Chapter 9 Using full text search 219

BMC Remedy Action Request System 7.1.00
220 Configuring
In searches that use FTS, submitted or modified requests might not appear
immediately in the results list if you are searching on a field enabled for FTS.
There is sometimes a short delay from the time the request is submitted or
modified in the database to the time that the request is available for searching in
the FTS index.
On a server running in the English locale in the ISO-8859-1 character set, words
can contain only the following characters if they are to be indexed under FTS:
_ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789$%#@
On a server running a locale of other Western European languages in the ISO
8859-1 character set, words can contain only the following characters, if they are
to be indexed under FTS: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghij
klmnopqrstuvwxyzäöüßÄÖÜåÅ>>øØàÀáÁâÂèÈéÉëËêÊìÌíÍïÏîÎòÒóÓùÙúÚñÑ
ûÛçÇôÔýÝðÐãÃõÕÞþ€0123456789$%#@.
Administering FTS
This section describes how to administer FTS in AR System.
NOTE
Using FTS in a server group requires you to perform additional configuration.
Selecting fields for FTS indexing
You can only index character, diary, and attachment fields for FTS. Index only
fields that are frequently searched, such as work diaries and descriptions of
problems, especially if the underlying database does not support searches of these
fields.
For example, you could perform a search for one or more keywords in a diary field
that would retrieve and weigh all AR System requests that describe how to solve
a problem suggested by those keywords. You would perform a search on
keywords or phrases such as:
Forms, tools, screens, and hardware and software products
Descriptions of problems or solutions
Other areas of interest

Administering FTS
When you define a field as indexed for FTS, it might take some time before that
field is available for searching if there are existing entries in the form. Indexing a
field can take several hours, depending on the amount of data in that field, the
system load, and other factors. While a field is being indexed for FTS, you can still
do non-FTS searches on that field if the underlying relational database permits it.
To index a field for FTS, see “Defining a field for FTS in the Field Properties
window” on page 229.
For each field that you index for FTS, the amount of disk space required for the FTS
index can grow significantly. To estimate approximately how much space is
required for your FTS index, see “Estimating the size of the FTS index” on
page 230.
Do not define fields for FTS during normal production hours, especially if you
have many AR System requests in your database. Indexing uses database and
AR System server resources, which can have a significant impact on the
performance of your system.
Full text search indexing
AR System uses the arserverd process (arserver.exe on Windows) to insert or
delete data in the FTS indexes. Threads from the Full Text Indexing queue perform
the indexing. This queue has one thread by default and more threads can be
configured if desired. For more information, see “Defining queues and configuring
threads” on page 131.
The indexing mechanism is based on an offline model, where indexing tasks are
recorded in a system table (ft_pending) in the database during the originating
transaction. The originating transaction typically involves a create entry, set entry,
merge entry, or delete entry operation on a form where a field indexed for full text
search exists.
A full text dispatcher thread processes the indexing tasks in real-time on a first-in,
first-out basis, queuing them for indexing threads to process. There is no
scheduled indexing task like there might be in a traditional search system. As a
result of this indexing model, the performance of the originating transaction is
affected only marginally by inserting the indexing task record into the system
table, and is not subject to delays associated with full text indexing. However, the
data might not be immediately available for searching. The size of the delay
depends on the size of the indexing queue and the availability of system resources
to perform the indexing.
If indexing is disabled by the administrator, indexing tasks are still recorded,
preserving the changes for later inclusion when indexing is enabled.
Chapter 9 Using full text search 221

BMC Remedy Action Request System 7.1.00
Indexing for attachments
222 Configuring
Indexing for attachments is selected on a per-field basis, not by attachment pool.
Therefore, it is possible to index only some of the attachment fields in a pool. The
advantage to indexing only some of the attachment fields can be found in the
choice of designating (and appropriately naming) “buckets” for attachments that
are likely to have value when indexed, as opposed to those that will not. The
system will attempt to index any attachment that gets placed into an attachment
field indexed for FTS. Attachments with unsupported data formats will not be
indexed successfully. By guiding users to place attachments in the appropriate
“buckets,” the system can be spared unnecessary processing.
NOTE
If you index an attachment that has an unsupported format, AR System only
indicates that occurrence in the Full Text Indexer log. For more information about
this log, see the Optimizing and Troubleshooting guide.
Multiple languages and attachment file formats
With some special considerations for attachment fields, the full text feature can
index any content where the character set is compatible with the AR System
server’s character set. If the AR System server is running as a Unicode server, the
full text feature has no restriction on the encoding format of the data content.
Content in multiple languages can be indexed and searched.
With a non-Unicode AR System server, the data content must be compatible with
the server’s character set. When indexing and searching attachments with
common formats, such as Microsoft Office documents and PDF documents, the
full text feature can process the data without a dependency on the server’s
character set. For plain text files, the full text feature requires that the server
recognize the character set of the data.

Reindexing
Administering FTS
Most of the time, you should not have to rebuild your FTS indexes because the
AR System server periodically optimizes them after AR System requests are
added, changed, or deleted. If you make changes to your Ignore Words List, you
will need to rebuild the FTS indexes (reindex). See “Full text search indexing” on
page 221.
If you change the Case Sensitivity setting, you will need to rebuild the FTS indexes,
and the reindexing is started automatically when the change is saved. To rebuild
the index for a specific field, you must deselect the field for indexing on the
Database Properties tab of the Field Properties window, save the change, reselect
the field for indexing, and save the change.
NOTE
After upgrading FTS from version 6.0 or earlier, you must reindex FTS to complete
the FTS index upgrade process.
Time required to rebuild a set of indexes
Do not rebuild indexes during normal production hours. Because reindexing
rebuilds your entire set of FTS indexes from scratch, it can take a long time,
depending on the following factors:
The number of fields selected for full text search
The amount of data in each field indexed for FTS in each AR System request
The system load
Whether your indexes are on NFS-mounted or local directories
For more information about locating your FTS indexes, see “Estimating the size of
the FTS index” on page 230.
Chapter 9 Using full text search 223

BMC Remedy Action Request System 7.1.00
224 Configuring
After modifying the Ignore Words List
When you modify the Ignore Words List and do not reindex, your changes affect
only entries that are inserted, deleted, or modified after that time. For example, if
you added network to the Ignore Words List, the FTS index ignores the word
network only for AR System requests added or modified from this time forward.
However, the FTS index with the word network would still exist for all requests
created before the Ignore Words List was modified.
When you reindex all the fields in all your forms that are currently flagged as
indexed for FTS, you create a new FTS index that then ignores the word network in
all requests. To change the Ignore Words List, see “Using the Ignore Words List”
on page 209.
NOTE
After modifying the Ignore Words List and before reindexing, automatic index
optimization will not work because the search engine detects that the Ignore
Words List has changed. This does not affect the integrity of the index, but error
messages will be produced by the search engine and recorded in the error log. Do
not take any actions as a result of these errors, other than reindexing.
FTS configuration options
This section outlines the configuration options for FTS from the Full Text Search
tab of the AR System Administration: Server Information form.
Figure 9-1: Full Text Search configuration options

The following options are available:
Administering FTS
Disable Full Text Searching—Controls whether or not the server uses the full
text search engine for searching. When disabled, the server uses the search
capability of the underlying database, whether or not a user has a full text
license.
FTS Collection Directory—The location in the file system where search engine
index files are stored.
FTS Configuration Directory—The location in the file system where search
engine configuration files are stored.
FTS Temp Directory—The location in the file system where search engine
temporary files are stored. This directory needs to be periodically cleaned of the
temporary files that accumulate.
Indexing Failure Recovery Interval—Defines the number of minutes the server
waits between periodic attempts to index entries that failed to index for an
unexpected reason in a prior attempt. The default value is 60 minutes.
Temporary Table Threshold—During the processing of search results, the
server will create a temporary table if the number of FTS matches reaches this
value. If the number of FTS matches is under this value, the server will use the
SQL IN operator for a query on an existing table. The default value is 200.
Complex Search Threshold—During the processing of search results, the server
will combine results from sub-queries to arrive at the final result set. If the
number of rows created during processing exceeds this value, the server will
return an error message indicating the search is too complex. The default value
is 1,000,000.
Indexer Optimization Threshold—The number of additions, modifications, or
deletions that must occur before the server will optimize an index. The default
value is 1000. The minimum value is 10. Optimization improves the time it
takes to search with an index, but can be an intensive operation.
Case Sensitivity—Defines whether full text searching is case sensitive or case
insensitive. This setting affects all fields indexed for full text search and affects
how the indexes are built. Therefore, changes to this setting will trigger an
automatic reindex. The default value is case insensitive.
Search Options—Defines how the server modifies qualifications received from
the client. The choices are:
Force Leading & Trailing Wildcards
Ignore Leading & Trailing Wildcards
Ignore Leading Wildcard
Remove Leading & Trailing Wildcards
Query Unchanged (default)
Chapter 9 Using full text search 225

BMC Remedy Action Request System 7.1.00
Debugging FTS
FTS logging
226 Configuring
Reindex—Initiates the reindexing of all fields selected for full text indexing. This
check box will be disabled if a reindex is in progress. The dialog box must be
redisplayed for the check box to become active following completion of the
reindexing.
Disable Full Text Indexer—Controls whether or not the server processes
indexing tasks that are pending. When disabled, indexing tasks are still
recorded for processing at a later time when indexing is enabled.
Ignore Words List—Defines which words are ignored during indexing. When
this button is clicked, a dialog box appears, from which you can add words or
upload a text file from your computer that contains a list of words.
All debug tracing for full text indexing is logged in the /db/
arftindx.log file. See “Full text index logging” for information about how to turn
on this logging. Entries in this log file represent the operations performed by the
full text dispatcher and indexing threads, including the commands sent to the
search engine for modifying the indexes.
All debug tracing for full text searching is logged in the /db/
arsql.log file, sharing the file with database logging. See “SQL logging” on
page 227 for information about how to turn on this logging. Entries in this log file
that represent search engine activity are prefixed with FTS:.
There are two types of logging you can use to help you analyze FTS-related
processing: full text index logging and SQL logging.
Full text index logging
Full text index logging records all full text indexing operations, but not full text
searching operations. When you enable full text index logging, descriptions of all
indexing operations are recorded to the log file.
To enable indexing logging
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Log Files tab.
3 Select Full Text Index check box.
4 In the File Name field, specify a log file name. The default log file name is
arftindx.log. The File Name is disabled until you select the related check box.
5 Click OK.

SQL logging
Upgrading FTS
AR System SQL logging records all full text searching operations, but not full text
indexing operations. When you enable SQL logging, descriptions of all FTS
operations are recorded to the SQL log file.
To enable SQL logging
1 From the AR System Administration Console in a browser or BMC Remedy User,
click System > General > Server Information.
The AR System Administration: Server Information form appears.
2 Click the Log Files tab.
3 Select the SQL check box.
4 In the File Name field, specify a log file name. The default log file name is
arsql.log.The File Name is disabled until you select the related check box.
5 Click OK.
Upgrading FTS
Upgrading of the full text search option from AR System version 6.0 and earlier is
a complete replacement that involves the following tasks:
Installing the new search engine and designating key directories for search
engine files.
Obtaining new full text search licenses of types BMC Remedy AR FTS Fixed and
BMC Remedy AR FTS Floating.
Determining if any attachment fields are appropriate for full text search and
selecting those fields for indexing.
Reviewing the fields already selected for indexing. After the search engine is
installed and licenses are in place, a list can be generated by turning on Full Text
Indexer logging, restarting the AR System server, and viewing the configuration
information at the beginning of the log file. A review is important to verify that
existing selections add searching value to your system. Those that do not should
not be text-indexed, to save system resources.
Building new indexes that are compatible with the new search engine by
reindexing all fields selected for full text search. This might take a considerable
amount of time.
Chapter 9 Using full text search 227

BMC Remedy Action Request System 7.1.00
228 Configuring
Removing files associated with the previous search engine. The following files
and directories from your previous FTS installment can be removed.
IMPORTANT
Be sure to back up existing directories and files before removing them.
The \ftindex subdirectory
The \common\arfts or
\Arserver\common\arfts subdirectory
The \Arserver\common\_nti40
subdirectory
The following files in the \db or
\Arserver\db:
arftp.lst
arftinp.lst
The following files in the or
\bin or
\common\*\bin:
loc_xlt.*
xlt_fn.*
vdk200.*
arservftd or arfts.exe
Assigning FTS licenses to users
To perform a full text search, users must be assigned a fixed or floating FTS license.
You specify the type of license that users have through their request in the User
form, as you would with their AR System write licenses.
To license a user for FTS
1 Open the User form in BMC Remedy User.
2 Search the database for the user who you want to license for FTS and open a
window.
Figure 9-2: License area of User form
3 Select the Full Text License Type option for the type of FTS license that you want
the user to have, whether fixed or floating.

Defining a field for FTS in the Field Properties window
4 Click Save.
If you issued the user a fixed FTS license, a confirmation message appears.
5 Click OK to acknowledge the message.
If you do not have an available FTS license, or you do not have FTS capability, you
will receive an error message.
Defining a field for FTS in the Field Properties
window
Use the Field Properties window to create an FTS index of text in character, diary,
or attachment fields. Do not define fields for FTS during normal production hours,
especially if you have many AR System requests in the forms for which you are
defining FTS fields.
NOTE
The Index For FTS check box does not appear for servers that are not licensed for
the FTS option or for field types that are not valid for full text search.
To define a field for FTS
1 Open the Field Properties window.
2 Click the Database tab.
Figure 9-3: Database tab in Field Properties window
Chapter 9 Using full text search 229

BMC Remedy Action Request System 7.1.00
230 Configuring
3 Select the Index For FTS check box.
4 Select the Literal Index check box if the field is defined for literal (whole field)
searching. The search engine builds a different type of index for this type of
searching, so it must be specified at design time. The literal index option is
available only for character fields of 32767 or fewer characters.
5 Save your changes.
AR System begins to index the field for FTS.
The FTS index for a field is automatically updated and does not require manual
administration when you create, delete, or modify requests.
Estimating the size of the FTS index
Place the FTS index in a directory that has sufficient disk space. The directory must
be large enough to accommodate at least two times the amount of data that is
indexed for FTS. For example, if the total amount of data in all fields you want to
be indexed for FTS in all forms is 100 MB, then at least 200 MB of disk space is
required for the indexes. This example of determining the size of an FTS index is
an approximation only.
To estimate the size of the FTS index
Use this procedure to determine approximately how much disk space is occupied
by the FTS index.
1 Estimate the size of text in your database.
For example, take a small sample of requests and calculate the average size of data
in the field. Then multiply this average by the number of AR System requests to
derive the size of text in your database.
2 Use a minimum number of 2 as a multiplier.
The ratio of the size of the FTS index to source text can differ widely based on, for
example, the size of your Ignore Words List.
If the estimated size of text is 100 MB, the FTS index occupies at least 200 MB of
disk space: 100 MB * 2.0 = 200 MB as the lower boundary of the FTS index and 100
MB * 2.5 = 250 MB as the upper boundary.

Displaying FTS weight in a results list
Defining a field for FTS in the Field Properties window
In the Results List Fields tab of the Form Properties dialog box, you can configure
results lists to display the FTS weight for all requests retrieved.
To display FTS weight in a results list:
1 In BMC Remedy Administrator, open the form for which you want to define the
results list format.
2 Choose Form > Form Properties.
The Form Properties dialog box appears.
Figure 9-4: Form Properties dialog box
3 Click the Results List Fields tab.
4 From the Fields in Form list, select WEIGHT.
5 If necessary, specify a Separator and Width.
6 Click Add.
7 Click OK to save your results list definition.
The Weight field displays the weighted value of retrieved AR System requests
when you create a results list in BMC Remedy User. If sorted by descending
weight, the requests are listed in order, based on a relevance factor calculated by
the search engine.
8 Save the form.
Chapter 9 Using full text search 231

BMC Remedy Action Request System 7.1.00
232 Configuring

Appendix
A Working
with the Request ID
field
Follow the procedures in this section to improve the performance or enhance the
security of your AR System environment.
The following topics are provided:
Working with the Request ID field (page 234)
NOTE
These procedures address the most commonly requested AR System technical
information. For access to the complete set of AR System technical information and
procedures, visit the Customer Support website at http://www.bmc.com/
support_home.
Appendix A Working with the Request ID field 233

BMC Remedy Action Request System 7.1.00
Working with the Request ID field
234 Configuring
Every form defined in AR System contains a set of core fields. The Request ID field
is one of those core fields and has a unique field ID of 1. You can change the label
of this field to something other than Request ID, but the field ID will always remain
1.
The Request ID field contains a character string that holds a unique index for each
request. The form of this string is an optional prefix, which can consist of any
alphanumeric characters, followed by a 0-padded numeral (for example,
HD0000000000001). The length of the Request ID field must be either 1 or between 5
and 15 characters, inclusive. Specifying a length of 1 causes leading zeroes to be
stripped from the value in the Request ID. The prefix can be as long as the total
length of the field less five characters.
When new requests are submitted, AR System generates a new ID for the request
by appending the next available ID to the prefix, if a prefix is specified. Then,
AR System increments the next available ID in preparation for the next request to
be submitted.
The Request ID field contains a unique number sequence. Create other fields to
contain information that is specific to your site instead of using the Request ID
field. Overloading the Request ID field with other information can restrict your
ability to control this data and limits the flexibility of searches on the data.
Sometimes, it is necessary to work with the Request ID value or the Request ID
field in the database. The following section contains these topics:
“Changing the next available ID for new requests” on page 234.
“Changing the Request ID field length or prefix” on page 236.
“Preserving existing Request ID field values” on page 237.
“Changing existing Request ID field values to a new format” on page 238.
“Updating the Request ID field in other AR System tables” on page 246.
Changing the next available ID for new requests
You can change the next available ID when creating new AR System requests. This
ID is used to automatically generate the unique index number that is attached to
each AR System request. Under some conditions, you might need to reset the next
available ID. For example, you might need to establish different ranges for a
similar form on two different servers, or you might need to reserve a range of
numbers for later use.

Working with the Request ID field
NOTE
Do not change the next available ID to a number lower than the greatest existing
ID. The Request ID field value must be unique within AR System, and resetting the
ID to a lower number could conflict with existing Request ID field values. If you
try to submit a request with an existing ID, AR System will return an error and
prevent the request from being submitted until the conflict is resolved.
If you must change the next available ID, make the change when the system is not
in use to avoid conflicts with users who are submitting new requests.
To change the next available ID for a form in an SQL database
1 Stop AR System server.
2 Using any front-end tool that allows direct access to an SQL database, log in as a
user with write access to the AR System tables.
3 Connect to the AR System table area.
4 Find the Request ID field for the form you want to modify.
5 Update the next available ID.
6 Restart the AR System server.
Example SQL database procedures
The following sections are examples of how to change the next available ID for DB2
Universal, Informix, Oracle ® , and Microsoft SQL and Sybase databases. In these
examples, the next available ID for a form named ZZZ is changed from the current
value of 1291 to a new value of 25000.
DB2 Universal database example
>open DB2 command center
Connect to AR System.
>select name, nextId from arschema where name = 'ZZZ';
NAME NEXTID
--- -------
ZZZ 1291
1 row(s) retrieved.
>update arschema set nextId = 25000 where name = 'ZZZ';
1 row(s) updated.
Informix database example
% dbaccess - -
>database ARSystem;
Database selected.
>select name, nextId from arschema where name = 'ZZZ';
name nextId
ZZZ 1291
1 row(s) retrieved.
>update arschema set nextId = 25000 where name = 'ZZZ';
1 row(s) updated.
>
Appendix A Working with the Request ID field 235

BMC Remedy Action Request System 7.1.00
236 Configuring
Oracle database example
% sqlplus
Enter user-name: ARAdmin
Enter password: (AR#Admin# by default.)
SQL>select name, nextId from ARAdmin.arschema where name ='ZZZ';
NAME NEXTID
------------------------------ ----------
ZZZ 1291
SQL>update ARAdmin.arschema set nextId = 25000 where name = 'ZZZ';
1 row updated.
SQL>Commit;
commit complete
SQL>exit
Microsoft SQL Server and Sybase database example
% isql -Usa
Password:
1>use ARSystem
2>go
1>select name, nextId from arschema where name = 'ZZZ'
2>go
name nextId
ZZZ 1291
------------------------------ ----------
(1 row affected)
1>update arschema set nextId = 25000 where name = 'ZZZ'
2>go
(1 row affected)
1>exit
Changing the Request ID field length or prefix
After using a form for a while, you might need to change the prefix or length of the
Request ID field, the key field in a form. Often, this change can be made and
existing requests can retain the format used previously. However, you might need
to convert existing Request ID field values to match the new prefix or length. This
section offers background information and procedures to help you make changes
to the Request ID.
To change the length of the request ID field
1 Log in to BMC Remedy Administrator as a user with administrator access.
2 Open the form you want to alter.
3 Double-click the Request ID field.
The Field Properties dialog box appears.
4 Click the Database tab and specify the desired length in the Input Length field.

Working with the Request ID field
NOTE
The length of the Request ID field must be either 1 or between 5 and 15 characters,
inclusive. If you specify 1, leading zeroes are stripped from the value the Request
ID field. If you specify a prefix for the Request ID field, the field must be at least
five characters greater than the prefix.
5 Save the changes to the form.
1 Log in to BMC Remedy Administrator as a user with administrator access.
To change the prefix of the request ID field
2 Open the form you want to alter.
3 Double-click the Request ID field.
The Field Properties dialog box appears.
4 Click the Attributes tab.
5 Specify the desired prefix in the Default Value field.
NOTE
The Request ID field must be between 5 and 15 characters in length. If you specify
a prefix for the Request ID field, the field length must be at least five characters
greater than the prefix.
6 Save the changes to the form.
Preserving existing Request ID field values
You might want to preserve the existing Request ID field values of your
AR System requests for the following reasons:
Backward compatibility—You might have cross-references that see requests by
the Request ID field value.
History—The Request ID field values were created with the old format, and
there is no need for change.
Design—The design of your AR System calls for periodic change to the Request
ID field. For example, you might use the current year as a prefix for the Request
ID field.
No data—No requests have been submitted, so there are no Request ID fields to
be converted.
Appendix A Working with the Request ID field 237

BMC Remedy Action Request System 7.1.00
Changing existing Request ID field values to a new format
238 Configuring
You might want to change the values of existing Request ID fields for your
AR System requests for any of the following reasons:
Consistency—All the Request ID field values for a form follow the same format.
If the format changes, all the requests change to match the format.
Design—The design of your AR System has changed, and this design references
the new format of the Request ID field. This is usually a change of the length of
the field from a default setting of 15 to something shorter, and you need to
eliminate the extra leading zeros.
This section explains two methods of updating existing Request ID field values:
“Using an AR Export (.arx) file” on page 238.
“Using SQL commands to shorten the Request ID field” on page 240.
After implementing one of the strategies in this section, read “Updating status
history tables” on page 246 and “Updating attachment tables” on page 246.
WARNING
Back up your database before performing the actions described in this section to
make sure your original data is saved if there is a failure during the update.
Using an AR Export (.arx) file
You can edit AR Export (.arx) files regardless of the database underlying your
AR System. You can use the .arx strategy or a different strategy that bypasses
AR System to operate directly in the database.
To change the existing Request ID field format through an AR Export file
1 In BMC User, open the form you want to change.
2 Choose Tools > Reporting.
The Report dialog box appears.
3 Choose Report > New or double-click >.
The Properties - > dialog box opens.
4 Click Add All to add all the fields to the report style.
5 Select the Request ID field under Selected Fields and move it to the top of the list.
6 Choose Report > Export To > File and use .arx format to save all the data for the
form to a file.
7 Close the Report dialog box.
8 Edit the file to change the format of the Request ID field. See “Editing the .arx file”
on page 239.
9 In BMC User, delete all requests in the form.

10 Close BMC User.
11 Open BMC Remedy Import.
12 Choose File > Open Import File.
The Open Import File dialog box appears.
13 Select the file you edited, and click Open.
14 Choose File > Open Form.
The Open Form dialog box appears.
15 Select the form you want to change and click OK.
16 Click Add All.
17 Choose File > Preferences.
The Preferences dialog box appears.
Working with the Request ID field
18 Click the Data tab. Disable fields’ pattern matching and make required fields
optional during import by selecting the check boxes.
19 Click the Duplicate Request ID tab, and select the Reject Duplicate Record option.
20 Click OK to close the Preferences dialog box.
21 Choose Import to start the import process.
Editing the .arx file
After the first few header lines, the remaining lines in the .arx file have the
following format:
DATA "000000000000001" "" 1 ""
where is data from the form.
The Request ID field always follows the keyword DATA. In this example, the
Request ID field has no prefix and is 15 characters in length. Use a text editor, such
as WordPad, to convert the format of the Request ID field.
The following procedures show how you can shorten a Request ID field with a
length of 15 characters to 10 characters and add a prefix of ABC.
1 Open the .arx file in a text editor that has a Find/Replace command with a feature
for matching case (for example, WordPad).
To edit the .arx file in Windows
2 Use the Find/Replace command to search for DATA "00000000.
NOTE
This command contains 8 zeros. Five of these represent the difference between the
original length of 15 characters and the new length of 10 characters. The other 3
zeros represent the spaces to be replaced by ABC.
3 Use the match case feature.
Appendix A Working with the Request ID field 239

BMC Remedy Action Request System 7.1.00
240 Configuring
4 Replace all instances of DATA "00000000 with DATA "ABC.
5 Save the changes to the file.
1 Open the file in a text editor.
To edit the .arx file in UNIX ®
2 Type the following command:
g /^DATA "00000000/s//DATA "ABC/
3 Save and close the file.
Using SQL commands to shorten the Request ID field
Only administrators running AR System with an SQL database can update
existing request ID field values by directly accessing the SQL database. The syntax
for direct access is different for each SQL database that AR System supports. These
commands are described in the examples in this section.
To use the methods described in this section, you must be familiar with basic
commands in the SQL command interface. SQL commands bypass AR System
completely. If you bypass AR System, verify that all data is valid when you are
finished.
TIP
Create a practice table in your database and practice the commands you will issue
to make sure that you are issuing the correct commands. Make sure you back up
your database or all the relevant tables.
NOTE
When you change the length of the Request ID field in a database table, all related
database tables, such as status history tables (H Tables), and Attachment tables (B
Tables and BC Tables) must also be updated.
IMPORTANT
Stop AR System before you attempt any database modifications.
Finding the name of the table
Before you can shorten the request ID field value, you must find the table holding
the form being changed. To find the table name, you must know the schema ID
and, in some cases, the field ID of the field to be changed.
To find the table name, follow these basic steps:
Step 1 Find the correct schema ID for your form.
Step 2 Find the correct field ID for your field, if necessary.
Step 3 Construct the name of the table using the schema ID and field ID you found in the
previous steps.

Perform the following query:
To find the correct schema ID for your form
Select SchemaId, name from arschema order by 2
This query returns a list of schema IDs and associated form names.
To find the correct field ID (after you know the schema ID)
Working with the Request ID field
Perform the following query. This example assumes that the schema ID is 43:
Select FieldId, FieldName from field where SchemaId = 43
This query returns a list of field IDs and associated field names.
To construct the name of a table from schema ID and field ID
Use the schema ID, field ID, and information in the following table to construct
your table name.
Table A-1: AR System table name constructs
Table name Description
T A table that contains the data in your form. A table
named T43 indicates that 43 is the schema ID.
TC (Oracle only) Used for backward compatibility with
forms created using AR System versions prior to 4.5. It
is a table that contains long text and diary data. For
example, a table named T43C536870924 indicates that
43 is the schema ID and 536870924 is the field ID. In
many cases, there will be more than one long text or
diary field on the form.
H A table that contains the Status History information for
your form. A table named H43 indicates that 43 is the
schema ID. For more information about the status
history table, see the Database Reference guide.
B A table that contains a list of all the attachments and
related information for each record in your form. A table
named B43 indicates that 43 is the schema ID. For more
information about the attachment tables, see the
Database Reference guide.
BC A table that contains the actual Binary objects for
attachment fields in your form. A table named
B43C536870924 indicates that 43 is the schema ID and
536870924 is the field ID. In this example, the field ID
for the attachment field is 536870924. In some cases,
there will be more than one attachment field on the
form.
Appendix A Working with the Request ID field 241

BMC Remedy Action Request System 7.1.00
DB2 database
examples
Informix
database
examples
242 Configuring
NOTE
For T and B tables, the request ID column of the table is
always named C1. For the H tables, TC tables,
and BC tables, the Entry ID column is equivalent to the C1
column.
Changing existing Request ID field value format when the Request ID has a
prefix
The following examples assume that the table is named T43, that the prefix is HD,
and that the field size (including the prefix) will be 8 characters. The 6 represents
the number of characters to keep, starting from the right side of C1. C1 is originally
15 characters long. Make sure that the number of characters in your prefix plus the
second parameter in the RIGHT function is equal to the new size of the C1 field.
To add a prefix to the T table, use the following syntax:
update T43 set C1 = 'HD' || RIGHT(C1, 6)
To add a prefix to the B table, use the following syntax:
update B43 set C1 = 'HD' || RIGHT(C1, 6)
For the H table, use the following syntax:
update H43 set entryId = 'HD' || RIGHT(entryId, 6)
For the BC tables, use the following syntax:
update B43C536870924 set entryId = 'HD' || RIGHT (entryId, 6)
In the following examples, the request ID is being shortened from 15 to 8
characters. The prefix HD is concatenated to the last 6 characters in the string,
consisting of positions 10 through 15.
Note that for Informix databases, you must log in as the root user.
To add a prefix to the T table, use the following syntax:
update T43 set C1 = 'HD'||C1[10,15]
To add a prefix to the B table, use the following syntax:
update B43 set C1 = 'HD'||C1[10,15]
For the H table, use the following syntax:
update H43 set entryId = 'HD'||entryId[10,15]
For the BC tables, use the following syntax:
update B43C536870924 set entryId = 'HD'||entryId[10,15]
NOTE
In the functions C1[10,15] and entryId[10,15], the 10 represents the starting
position of the characters to keep and 15 represents the ending position.

Oracle
database
examples
Microsoft SQL
Server and
Sybase
database
examples
To add a prefix to the T table, use the following syntax:
update T43 set C1 = 'HD'||substr(C1,10,6);
To add a prefix to the B table, use the following syntax:
update B43 set C1 = 'HD'||substr(C1,10,6);
For the H table, use the following syntax:
update H43 set entryId = 'HD'||substr(entryId,10,6);
For the BC tables, use the following syntax:
Working with the Request ID field
update B43C536870924 set entryId = 'HD'||substr(entryId,10,6);
For the TC tables, use the following syntax:
update T43C536870924 set entryId = 'HD'||substr(entryId,10,6);
NOTE
In the functions substr(C1,10,6) and substr(entryId,10,6), the 10 represents the
starting position of the characters to keep and the 6 is the number of characters to
keep.
To add a prefix to the T table, use the following syntax:
update T43 set C1 = "HD"+ RIGHT(C1, 6)
To add a prefix to the B table, use the following syntax:
update B43 set C1 = "HD" + RIGHT(C1, 6)
For the H table, use the following syntax:
update H43 set entryId = "HD" + RIGHT(entryId, 6)
For the BC tables, use the following syntax:
update B43C536870924 set entryId = "HD" + RIGHT (entryId, 6)
Changing existing Request ID field value format when the Request ID does
not have a prefix
The following examples assume that the table is named T43 and that the field size
will be 8 characters. The 8 represents the number of characters to keep, starting
from the right side of C1. C1 is originally 15 characters long. Make sure that the
number of characters in the second parameter in the RIGHT function is equal to the
new size of the C1 field and that the sum of the two numeric values in the SUBSTR
function is 16 (1 greater than the original length of C1).
Appendix A Working with the Request ID field 243

BMC Remedy Action Request System 7.1.00
DB2 database
examples
Informix
database
examples
Oracle
database
examples
244 Configuring
To add a prefix to the T table, use the following syntax:
updcolate T43 set C1 = RIGHT(C1, 8)
To add a prefix to the B table, use the following syntax:
update B43 set C1 = RIGHT(C1, 8)
For the H table, use the following syntax:
update H43 set entryId = RIGHT(entryId, 8)
For the BC tables, use the following syntax:
update B43C536870924 set entryId = RIGHT (entryId, 8)
For Informix databases, you must log in as the root user.
In the following examples, the Request ID is being shortened from 15 to 8
characters. The request ID will consist of the last 8 characters in the string,
consisting of positions 8 through 15.
To add a prefix to the T table, use the following syntax:
update T43 set C1 = C1[8,15]
To add a prefix to the B table, use the following syntax:
update B43 set C1 = C1[8,15]
For the H table, use the following syntax:
update H43 set entryId = entryId[8,15]
For the BC tables, use the following syntax:
update B43C536870924 set entryId = entryId[8,15]
NOTE
In the functions C1[8,15] and entryId[8,15], the 8 represents the starting position
of the characters to keep and 15 represents the ending position.
To add a prefix to the T table, use the following syntax:
update T43 set C1 = substr(C1,8,8);
To add a prefix to the B table, use the following syntax:
update B43 set C1 = substr(C1,8,8);
For the H table, use the following syntax:
update H43 set entryId = substr(entryId,8,8);
For the BC tables, use the following syntax:
update B43C536870924 set entryId = substr(entryId,8,8);
For the TC tables, use the following syntax:
update T43C536870924 set entryId = substr(entryId,8,8);

Microsoft SQL
Server and
Sybase
database
examples
Working with the Request ID field
NOTE
In the functions substr(C1,8,8) and substr(entryId,8,8), the first 8 represents
the starting position of the characters to keep, and the second 8 is the number of
characters to keep.
To add a prefix to the T table, use the following syntax:
update T43 set C1 = RIGHT(C1, 8)
To add a prefix to the B table, use the following syntax:
update B43 set C1 = RIGHT(C1, 8)
For the H table, use the following syntax:
update H43 set entryId = RIGHT(entryId, 8)
For the BC tables, use the following syntax:
update B43C536870924 set entryId = RIGHT (entryId, 8)
Using SQL commands to lengthen the Request ID field value
The format for all the supported databases is the same for lengthening the Request
ID field format as with shortening the Request ID field format. See “Using SQL
commands to shorten the Request ID field” on page 240 for hints about how to run
the SQL interface, how to find the name of the table to be changed, and how to exit
the SQL interface.
NOTE
The maximum length allowed for the Request ID field is 15 bytes.
In the following example, the length of the field is restored to 15 characters from
the current 10 characters by adding 5 leading zeros to the existing value of the
Request ID field and assigning the resulting 15-character string to the Request ID
field. When you have determined the name of the table (T43 in the example), issue
the one of the following commands at the prompt:
DB2
% update T43 set C1 = '00000' ||C1
Informix
% update T43 set C1 = '00000' || C1
Oracle
% update T43 set C1 = '00000' || C1
Sybase and Microsoft SQL Server
% update T43 set C1 = '00000' + C1
To add a prefix, specify the prefix as part of the string to be added. For example, to
expand to 15 characters and add a prefix of ABC, use 'ABC00' instead of '00000' in
the preceding example.
Appendix A Working with the Request ID field 245

BMC Remedy Action Request System 7.1.00
Updating the Request ID field in other AR System tables
246 Configuring
When you change the Request ID in a main data table, you must also consider
whether you need to make a similar change to the status history table and
attachment tables.
Updating status history tables
Status History information is stored in a separate table. This table uses the Request
ID field as the link to the main table. Accordingly, you use the same procedure to
change the Request ID field values in the status history table as you do in other
tables.
To update the status history table, use the commands described in the previous
examples, substituting H43 for T43 and entryId for C1. For more information, see
“AR System table name constructs” on page 241.
For more information about the status history table, see the Database Reference
guide.
Updating attachment tables
Attachment information is stored in two tables, the Attachment Details table and
the Attachment Data table. The Attachment Details table holds attachment
characteristics, such as the name and size of the attachment, and the Attachment
Data table holds the actual attachment. These tables also use the Request ID field
as the link to the main table. Accordingly, you use the same procedure to change
the Request ID field values in the status history table as you do in other tables.
The Attachment Details table is named with a B followed by the schema ID (for
example, B3). The Attachment Data table is named with a B followed by the schema
ID, followed by C, followed by the attachment field ID. For example, the
Attachment Data table might be called B7C536870920, where 7 is the schema ID,
and 536870920 is the attachment field ID.
The column holding the Request ID in the Attachment Details table is named C1,
and in the Attachment Data table, it is named entryId. To update the Request ID
field in the attachment tables, use the commands described in the previous
examples, substituting the appropriate table name, and using C1 or entryId for the
Request ID. For more information, see “AR System table name constructs” on
page 241.
For more information about attachment tables, see the Database Reference guide.

Appendix
B AR
System configuration files
This section contains information about the AR System configuration files. Each
file name is listed by its UNIX ® name. Where it is different, the Windows
equivalent is listed in parentheses after the UNIX name.
The following topics are provided:
ar (page 248)
ar.conf (ar.cfg) (page 248)
ardb.conf (ardb.cfg) (page 287)
armonitor.conf (armonitor.cfg) (page 290)
Appendix B AR System configuration files 247

BMC Remedy Action Request System 7.1.00
ar
Description The ar file contains the list of AR System servers to which the client tools (BMC
Remedy User, BMC Remedy Administrator, BMC Remedy Alert, and BMC
Remedy Import) connect if no servers are specified on startup. The
ARGetList_Server function uses this file to return a list of available servers.
248 Configuring
The format of this file consists of two fields separated by a space or tab:
The parameter is the name of the server machine. The name is
resolved to a network address by using the name resolution strategy of the local
machine. The parameter identifies the server as an
AR System server (AR) as well as the TCP port and RPC program numbers, as
applicable.
Lines with a pound sign (#) in column 1 are treated as comments and are ignored.
Synopsis UNIX—$ARCONFIGDIR/ar
Windows—\ar
Environment ARCONFIGDIR
UNIX only—Specifies the directory where the ar.conf file and other AR System
configuration files are stored. This directory defaults to /conf if
you do not set this variable.
Examples The following directory file registers two server machines as AR System servers:
ar.conf (ar.cfg)
# Directory file for AR System servers
remedy AR
server2 AR;;3030;;390600
The example includes the TCP port and RPC program numbers for server2.
Description The ar.conf (UNIX) or ar.cfg (Windows) file contains AR System server
configuration changes and is dynamically created when you install AR System
server. When you make a server configuration change in the AR System
Administration: Server Information form, the configuration parameters and their
new values appear in the configuration file.
Any process can retrieve configuration information from the ar.conf (ar.cfg) file
by using the ARGetServerInfo function. You can modify the information by using
the ARSetServerInfo function. Updates made using ARSetServerInfo take effect
immediately. Manual changes to the file do not take effect until the AR System
server process is restarted or signaled to reread the configuration file with
arsignal -c.
Synopsis UNIX—/conf/ar.conf
Windows—\Conf\ar.cfg

Options The format of this file consists of two fields separated by a space or tab:
Table B-1: ar.conf (ar.cfg) file options
ar.conf (ar.cfg)
Each parameter represents a particular configuration option. The associated value
represents the current setting for that option. All numeric values are in a base 10
system. The available configuration options (and the valid settings for each) are
described in the following table.
Lines that do not begin with one of these options are ignored.
Lines with a pound sign (#) in column 1 are treated as comments and ignored.
The following table lists the options available for the ar.conf (UNIX) or ar.cfg
(Windows) file. All options can be set by using the AR System Administration:
Server Information form unless otherwise denoted by the table’s footnotes.
NOTE
All parameters in the configuration file might be updated manually. Entries are
case a space sensitive so be careful when making any manual updates to this file.
Option Description
Active-Link-Dir The directory where active link server run processes are stored. Only
commands located in the specified directory can be run. This is a security
feature that makes sure clients or API programs can use only a safe set of
server processes.
Active-Link-Shell (UNIX only) A shell that will be the parent of any active link server
process. This parameter causes the server to start the shell with the
specified process as a parameter. This is a security feature. The specified
shell might be a security shell that verifies a path, or runs with a user ID
other than the one that the server uses. For example, if the server runs as
root and an administrator specified a shell that runs as a lower user
privilege, an active link will invoke the shell that runs as a user, instead of
as root.
You can also set this parameter in the Advanced tab of the AR System
Administration: Server Information form. See “Configuring AR System
servers” on page 112 for more information.
Admin-Only-Mode A setting indicating that only administrators and subadministrators can
access the server. Valid values for this option are T and F. The default is F
(not in admin-only mode).
Alert-Check-Users Tells the AR System server to check all registered alert user connections at
startup time. This might slow the startup process, but it removes all
inaccessible connections. Valid values for this option are T and F. The
default is F (do not check alert users).
Alert-Connect-Retries 2 The number of times the server will retry the connection attempt when
connecting to an alert client fails. The default is 1 retry.
Alert-Log-File The name of the file to use if alert tracing is turned on (see “Debug-mode”
on page 260). This argument is expressed as the full path name.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 249

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Alert-Ignore-Actual-Client-
IP 2
250 Configuring
Modifies the server behavior when connecting to alert clients that have
registered with the server. When set to T (true), the server uses the IP
address that the client indicated when it registered with the server. When
set to F (false), the server uses the actual IP address that the registration call
came from, which may be different in an environment with a load balancer
or firewall. The default is F (false).
Environments where alert clients connect to the server through a load
balancer must set this configuration item to T (true) to avoid having the
server use the load balancer IP address when trying to connect to alert
clients.
Alert-Outbound-Port The specific TCP port to which the AR System server binds when sending
alerts. If more than one worker thread is running in the alert queue, this
setting represents the starting port number in a range of consecutive port
numbers that are assigned in sequence to the threads.
Alert-Send-Timeout Sets the time limit (in seconds) allowed for making contact with alert
clients. Two attempts are made to deliver an alert and if the second attempt
fails, the alert registration is removed. The default time limit is 7 seconds.
Allow-Backquote-In-Process-
String
Allows the server to run a process with a backquote in the process name or
in its arguments. Valid values are T and F. The default is F.
Allow-Guest-Users A flag indicating whether the AR System server accepts guest users. Guest
users are users not registered with AR System in a User form. If allowed,
guest users have no permissions but can perform some basic operations.
Guest users can submit requests to forms for which permission has been
given to the Public group and fields have been defined as allowing any
user to submit. If not allowed, unregistered users have no access to the
system. Valid values for this option are T and F. The default value is T
(allow guest users).
Allow-Unqual-Queries Indicates whether the AR System server allows unqualified searches.
Unqualified searches are ARGetListEntry or
ARGetListEntryWithFields calls in which the qualifier parameter is
either NULL or has an operation value of zero (AR_COND_OP_NONE). These
searches can cause performance problems because they return all requests
for a given form. (This operation is especially problematic for large forms.)
Valid values for this option are T and F. The default value is T (allow
unqualified searches).
Alternate-Approval-Reg 2 Specifies whether applications such as the Approval Server or
Reconciliation Engine listen for the AR System server's signal directly (F)
or listen for the application dispatcher to signal (T).
If your application relies upon the application dispatcher, set Alternate-
Approval-Reg to T.
Verify that arsvcdsp is configured to start along with AR System server by
checking the armonitor.cfg (armonitor.conf) file.
API-Log-File The name of the file to use if API tracing is turned on (see “Debug-mode”
on page 260). This argument is expressed as the full path name.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
Approval-Defn-Check-
Interval 2
ar.conf (ar.cfg)
The interval (in seconds) at which the Approval Server will check for
changed or updated data in the data definition forms.
Approval-Log-File 2 Full path of the Approval Server log file.
Approval-Notify 2 Specifies the approval notifications configured from the Server Settings
dialog box. There is an Approval-Notify entry for each ID. The syntax is
as follows:
Approval-Notify:
Do not be make these changes in the ar.cfg (ar.conf) file. From the
AP:Administration form, click the Server Settings link to open a dialog box
with configuration settings for the Approval Server.
Approval-RPC-Socket 2 Specific RPC Program Number the Approval Server uses when contacting
AR System. This allows you to define a specific AR System server that the
Approval Server can use privately.
Approval-Web-Doc-Dir 2 Virtual path to web document directory for the Approval Server.
ARDBC-LDAP-Base-DN 2 Specifies a base DN to be used instead of the root DN as the starting point
for discovering vendor tables when you are designing vendor forms. For
example:
ARBDC-LDAP-Base-Dn: CN=Users, DC=ldapesslab,DC=com
ARDBC-LDAP-Cache-TTL 2 Specifies the time limit (in seconds) that data will remain cached. Set to 0
for no time limit. The default value is 60 seconds.
ARDBC-LDAP-Cache-MaxSize 2 Specifies the size limit (in bytes) for the cache. Set to 0 for no size limit. The
default is 32768 bytes.
ARDBC-LDAP-Cert-DB 2 The directory name of the certificate database. The cert7.db and key3.db
certificate database files are located in this directory. If the directory is not
specified, the LDAP plug-in looks under the AR System installation
directory for these files.
The path in this option is used only when ARDBC-LDAP-UsingSSL is set
to T.
ARDBC-LDAP-Cert-Name 2 For future use. This option is not yet implemented.
ARDBC-LDAP-Connect-Timeout 2 Specifies the number of seconds that the plug-in waits for a response from
the directory service before it fails. The minimum value is 0, in which case
the connection must be immediate. The maximum value is the External-
Authentication-RPC-Timeout setting.
If the ARDBC-LDAP-Connect-Timeout setting is not specified, the default
value is set to the value of External-Authentication-RPC-Timeout
setting (the default is 40 seconds).
For example, to set the connection timeout for the ARDBC LDAP plug-in
to 5 seconds:
ARDBC-LDAP-Connect-Timeout: 5
ARDBC-LDAP-Drop-Large-
Values 2
This option is obsolete in version 7.0 and later versions.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 251

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
ARDBC-LDAP-Hostname 2 The host name of the system on which the directory service is running. If
the host name is not specified, the ARDBC LDAP plug-in uses localhost
as the host name. For example:
252 Configuring
ARDBC-LDAP-Hostname: server1.eng.remedy.com
ARDBC-LDAP-Key-DB 2 This option is not yet implemented.
ARDBC-LDAP-Key-Password 2 This option is not yet implemented.
ARDBC-LDAP-Page-Size 2 Configures the page size in the pagedResultsControl of the ARDBC
LDAP plug-in search request. It specifies the number of entries to be
returned in a single page from the external directory server in the set of
results to the client when processing a search request containing the
pagedResultsControl.
The maximum value for this parameter is 100,000 and the minimum value
is 100. The default value is 10,000 if there is no value set.
The syntax for this parameter is as follows:
ARDBC-LDAP-Page-Size:
For example:
ARDBC-LDAP-Page-Size: 1000
For information about ARDBC LDAP, see the Integrating with Plug-ins and
Third-Party Products guide.
ARDBC-LDAP-Port 2 The port number on which the directory service is listening for
clients.
ARDBC-LDAP-Time-Format 2 Maps date and time data into one of several formats that various
LDAP servers recognize.
Valid values are as follows:
0—Generalized Time Format – YYYYMMDDHHMMSSZ
This format is recognized by all LDAP servers and is recommended.
1—AD Generalized Time Format – YYYYMMDDHHMMSS.0Z
This format is only recognized by Microsoft Active Directory servers.
2—UTC Time Format – YYMMDDHHMMSSZ
This is a historical format and does not indicate the century. It is not
recommended.
ARDBC-LDAP-Use-Cache 2 Activates caching of search requests. The values are T and F.
After a cache is enabled, search requests issued via the ARDBC Plugin will
be cached. Subsequent matching search requests will be satisfied from the
cache.
ARDBC-LDAP-User-DN 2 The distinguished name (DN) of the user account that the ARDBC LDAP
plug-in uses to search and modify the contents of the directory service. For
example:
ARDBC-LDAP-User-DN: server1\admin
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
ARDBC-LDAP-UsingSSL 2 Establishes a secure socket layer (SSL) connection to the directory service.
The values are T and F.
If you use LDAP over SSL, then you must also specify the file name of the
certificate database used to establish the connection.
AREA-LDAP-Bind-Password 2 The password of the user account that the AREA LDAP plug-in uses to
find the user object using the User Search filter. If the Distinguished Name
is not specified, the AREA LDAP plug-in uses an anonymous login to find
the user object.
If the target directory service does not allow anonymous access, you must
specify a Distinguished Name and Password; otherwise, the plug-in
cannot determine the distinguished name of the user.
AREA-LDAP-Bind-User 2 The distinguished name (DN) of the user account that the AREA LDAP
plug-in uses to find the user object using the User Search filter. If the DN
is not specified, the AREA LDAP plug-in uses an anonymous login to find
the user object.
If the target directory service does not allow anonymous access, you must
specify a Distinguished Name and Password; otherwise, the plug-in
cannot determine the distinguished name of the user.
An example of this option is:
AREA-LDAP-Bind-User: ldapesslab\admin
AREA-LDAP-Cert-DB 2 The directory name of the certificate database. The cert7.db and key3.db
certificate database files are in this directory. If the directory is not
specified, the LDAP plug-in looks under the AR System installation
directory for these files. This path is used only when ARDBC-LDAP-
UsingSSL is set to T.
AREA-LDAP-Chase-Referral 2 Enables automatic referral chasing by LDAP client. By default, referrals are
not chased. The options are T and F. This option is for Microsoft Active
Directories only.
AREA-LDAP-Connect-Timeout 2 Specifies the number of seconds that the plug-in waits to establish a
connection with the directory service. The minimum value is 0, in which
case the connection must be immediate. The maximum value is the
External-Authentication-RPC-Timeout setting.
If the AREA-LDAP-Connect-Timeout setting is not specified, the default
value is set to the value of External-Authentication-RPC-Timeout
setting (the default is 40 seconds).
For example, to set the connection timeout for the AREA LDAP plug-in to
5 seconds, enter:
AREA-LDAP-Connect-Timeout: 5
AREA-LDAP-Email 2 The name of the attribute that specifies the email address of the user. This
attribute corresponds to the Email Address field in AR System User form.
If the attribute is not specified, the specified default or a system default is
applied.
AREA-LDAP-Email-Default 2 The value that the AREA LDAP plug-in uses if the AREA-LDAP-Email
parameter is not specified or has no value for the user.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 253

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
AREA-LDAP-Group-Base 2 The base of LDAP directory to search the groups from.
The following keywords are used to substitute runtime parameters into
this option. Note that the backwards slash (\) is necessary.
$\USER$—The user's login name.
$\DN$—The user's distinguished name. This applies only to the Group
Base Name and Group Search Filter. It does not apply to the User Base
name and User Search filter.
$\AUTHSTRING$—The value that users enter into the Authentication
String field at the time they log in.
$\NETWORKADDR$—The IP address of the AR System client accessing the
AR System server.
AREA-LDAP-Group-Default 2 Default groups to which the user belongs if no group information is
available from the directory service. If there are multiple groups, use a
semicolon to separate one from another.
AREA-LDAP-Group-Filter 2 The LDAP search filter used to locate the groups to which this user
belongs.
The following keywords are used to substitute runtime parameters into
this option. Note that the backwards slash (\) is necessary.
$\USER$—The user's login name.
$\DN$—The user's distinguished name. This only applies to the Group
Base Name and Group Search Filter. It does not apply to the User Base
Name and User Search Filter.
$\AUTHSTRING$—The value that users enter into the Authentication
String field at the time they log in.
$\NETWORKADDR$—The IP address of the AR System client accessing the
AR System server.
AREA-LDAP-Hostname 2 The host name of the system on which the directory service is running. If
left blank, the AREA LDAP plug-in uses localhost as the host name.
AREA-LDAP-Lic 2 The name of the attribute that specifies the type of write license issued.
This attribute corresponds to the License Type field in the AR System User
form. If the attribute is not specified, the specified default or a system
default is applied.
AREA-LDAP-LicApp 2 The name of the attribute that specifies the type of Application license
issued. If the attribute is not specified, the specified default or a system
default is applied.
AREA-LDAP-LicApp-Default 2 The value the AREA LDAP plug-in uses if the AREA-LDAP-LicApp
attribute is not specified or has no value for the user.
AREA-LDAP-Lic-Default 2 The value the AREA LDAP plug-in uses if the AREA-LDAP-Lic attribute is
not specified or has no value for the user.
AREA-LDAP-LicFTS 2 The name of the attribute that specifies the type of Full Text Search (FTS)
license issued. This attribute corresponds to the Full Text License field in
the AR System User form. If the attribute is not specified, the specified
default or a system default is applied.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
254 Configuring

Table B-1: ar.conf (ar.cfg) file options
Option Description
AREA-LDAP-LicFTS-Default 2 The value the AREA LDAP plug-in uses if the AREA-LDAP-LicFTS
attribute is not specified or has no value for the user.
ar.conf (ar.cfg)
AREA-LDAP-LicMask 2 The attribute that specifies the license mask. The bits of the binary format
of the specified integer indicate how to mask the license information
returned from the AREA LDAP plug-in. The integers are:
0—No licenses returned from the AREA LDAP plug-in are used.
1—Write license from the plug-in is used.
2—Full Text Search (FTS) license from the plug-in is used.
3—Write license and FTS license from the plug-in are used.
4—Reserved license from the plug-in is used.
5—Reserved license and Write license from the plug-in are used.
6—FTS License and Reserved license from the plug-in are used.
7—Write license, FTS license, and Reserved license from the plug-in are
used.
If the license is not used from the plug-in, the license information in the
user's User entry is used.
AREA-LDAP-LicMask-Default 2 The value the AREA LDAP plug-in uses if the AREA-LDAP-LicMask
attribute is not specified or has no value for the user.
AREA-LDAP-LicRes1 2 The name of the attribute that specifies the type of Reserved license issued.
If the attribute is not specified, the specified default or a system default is
applied.
AREA-LDAP-LicRes1-Default 2 The value the AREA LDAP plug-in uses if the AREA-LDAP-LicRes1
attribute is not specified or has no value for the user.
AREA-LDAP-Notify-Meth 2 The name of the attribute that specifies the default notification mechanism
for the user. This attribute corresponds to the Default Notification
Mechanism field in the AR System User form. If the attribute is not
specified, the specified default or a system default is applied.
AREA-LDAP-Notify-Meth-
Default 2
The value the AREA LDAP plug-in uses if the AREA-LDAP-Notify-Meth
attribute is not specified or has no value for the user.
AREA-LDAP-Port 2 The port number on which the directory service is listening for clients.
AREA-LDAP-Use-Groups 2 Retrieves the group information from the LDAP server. If this parameter
is not set, the group information from AR System Group form is used.
AREA-LDAP-User-Base 2 The user base in the LDAP directory to search for the user.
The following keywords are used to substitute runtime parameters into
this option. Note that the backwards slash (\) is necessary.
$\USER$—The user's login name.
$\DN$—The user's distinguished name. This only applies to the Group
Base Name and Group Search Filter. It does not apply to the User Base
Name and User Search Filter.
$\AUTHSTRING$—The user enters into the Authentication String field at
the time they log in.
$\NETWORKADDR$—The IP address of the AR System client accessing the
AR System server.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 255

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
AREA-LDAP-User-Filter 2 The LDAP search filter used to locate the user in the directory from the
base that the AREA-LDAP-User-Base option specifies.
The following keywords are used to substitute runtime parameters into
this option. Note that the backwards slash (\) is necessary.
$\USER$—The user's login name.
$\DN$—The user's distinguished name. This only applies to the Group
Base Name and Group Search Filter. It does not apply to the User Base
Name and User Search Filter.
$\AUTHSTRING$—The value that the user enters into the Authentication
String field at the time they log in.
$\NETWORKADDR$—The IP address of the AR System client accessing the
AR System server.
AREA-LDAP-UseSSL 2 Establishes a secure socket layer (SSL) connection to the directory service.
The values are T and F.
If you use LDAP over SSL, then you must also specify the file name of the
certificate database used to establish the connection.
Arerror-Exception-List 2 Enables you to list the errors that you want to trigger a dump of the current
stack in the arerror.log file. To list the errors, separate each error number
with a semicolon (for example, 123;345;).
ARF-Java-Class-Path 2 The path to .jar files. If you install JRE after the AR System server, add
the following lines to your ar.cfg (ar.conf) file:
ARF-Java-Class-Path: C:\Program Files\AR System\arapi51.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\axis.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\log4jcore.jar;
ARF-Java-Class-Path: C:\Program
Files\AR System\websvc51.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\wsdl4j.jar;
ARF-Java-Class-Path: C:\Program
Files\AR System\xercesImpl.jar;
ARF-Java-Class-Path: C:\Program
Files\AR System\xmlParserAPIs.jar;
ARF-Java-Class-Path: C:\Program
Files\AR System\commonslogging.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\jaxrpc.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\ttbytecode.jar;
ARF-Java-Class-Path: C:\Program Files\AR System\saaj.jar;
#ARF-Java-VM-Options: -Dhttp.proxySet=true -
Dhttp.proxyHost=zermatt -Dhttp.proxyPort=3129
Plugin: WebService.dll
Also, if you install JRE after the AR System server, add the JRE directory
to your PATH, for example:
C:\Program Files\JavaSoft\JRE\1.3.1_03\bin\hotspot
ARF-Java-VM-Options 2 The Java command options for a virtual machine (VM). The options are
documented in the Javadocs.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
256 Configuring

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Arfork-Log-File The name of the file to use if arforkd tracing is turned on (see “Debugmode”
on page 260). This argument is expressed as the full path name. This
file is not subject to the maximum file size specified in the Max-Log-File-
Size option.
Authentication-Chaining-
Mode
This parameter enables the administrator to use more than one type of
authentication on the same system.
The values for Authentication-Chaining-Mode are as follows:
0 (Off)—Use the default behavior as in releases prior to 6.3.
1 (ARS - AREA)—Use internal authentication as the primary method;
use external authentication via the AREA plug-in as the secondary
method.
2 (AREA - ARS)—Use external authentication via the AREA plug-in as
the primary method; use internal authentication as the secondary
method.
3 (ARS - OS- AREA)—If authentication fails in AR System (internal
authentication), use the operating system authentication (for example,
NT domain authentication). If the OS fails, try external authentication
(AREA).
4 (ARS - AREA - OS)—If authentication fails in AR System, try AREA.
If AREA fails, try the OS authentication.
If Authentication-Chaining-Mode is set to a value of 1 or 2, the
Authenticate-Unregistered-Users parameter will be ignored.
If the Crossref-Blank-Password parameter is enabled, and
Authentication-Chaining-Mode is set to a value of 1 or 2, users who
have a blank password in their User record will be permitted to log in to
the system without a password (that is, a NULL password).
Values 3 and 4 of Authentication-Chaining-Mode provide you with
greater flexibility. A typical scenario might be that your external users are
authenticated with an AREA plug-in, and internal users are authenticated
by the NT domain. You would not want internal users to be authenticated
against the User form.
For values 3 and 4 to work, the user must exist in the User form with a
blank password, and if the Crossref-Blank-Password parameter is
enabled and Authentication-Chaining-Mode is set to a value of 1, 3, or
4, AR System ignores those options and authenticates the user that has a
blank password in the User form. This prevents a user with a NULL
password from logging in to the system when the Authentication-
Chaining-Mode option is turned on.
For more information on AREA, see the Integrating with Plug-ins and Third-
Party Products guide.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 257

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Cache-Display-Properties 2 Indicates how the server caches form display properties. The form display
property is the background image of the form view and the display
property of each form field. The following values are valid:
258 Configuring
0: Do not cache any form display property. (This can negatively impact
the performance of BMC Remedy User and the server if a form is
changed, but it reduces the amount of memory used in the server cache.)
1: Cache the view’s background images, but not field display properties.
2: Cache field display properties, but not the view’s background image.
3: Cache all form display properties.
If there is no Cache-Display-Properties option in the ar.conf (ar.cfg)
file, the server will cache all form display properties.
Cache-Mode Enables a cache mode that is optimized for developing applications and
where user operations might be delayed when changes are made to forms
and workflow. A value of 1 turns on development cache mode; a value of
0 (zero) turns off development cache mode; the server is in production
mode. If there is no entry in the ar.cfg (ar.conf) file, development cache
mode is off. The following example shows development cache mode on:
Cache-Mode: 1
Cancel-Query-Option 2 Allows control over whether cancel query functionality of user tool is
enabled. Valid settings are 0 (inactive) and 1 (active). The default is 1.
Changed-By-Another-Check A setting indicating whether the system will check if an entry has been
changed by another user since you retrieved the entry. If you attempt to
save modifications to an entry, you will receive a warning and must
confirm the save. Valid values for this option are T and F. The default is T
(perform the check and issue a warning).
Clustered-Index A setting indicating whether indexes for the database are clustered. Valid
values for this option are T and F. The default is T (use a clustered index).
You must set this configuration before you start the AR System server.
Create-Entry-DeadLock-
Retries 2
Create-Entry-DeadLock-
Retries-Delay 2
Number of times to retry an ARCreateEntry() during deadlock
situations. Integer value.
Delay, in seconds, between each retry of a deadlocked ARCreateEntry().
Integer value.
Crossref-Blank-Password A flag indicating how the system responds when a user’s login name is not
assigned a password in the User form. Valid values for this option are T
and F. The default value is F (blank passwords not cross-referenced). If set
to T, the system attempts to validate the password in the Windows server
domain (or through the External Authentication API if external
authentication is turned on) or against the UNIX server /etc/passwd file.
This option enables you to manage group membership and other support
information with AR System, while still managing passwords with the
/etc/passwd file (UNIX) or the server domain security model (Windows).
Currency-Ratio-Client-
Refresh-Interval 2
Number of seconds between each refresh of Currency Field values.
DB2-Database-Alias The DB2 database alias name for the AR System database.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
DB2-Free-Lob-Locator-
Frequency 2
ar.conf (ar.cfg)
Indicates how often DB2 frees the LOB locator (Large OBject locator). The
default value is 50, which results in the LOB locator being freed after every
50 LOBs have been loaded. The recommended value for AR System
application is 5.
DB2-Server-Name The name of the DB2 database server.
Dbhome-directory 1 UNIX only—The home directory for the underlying database (applicable
for SQL databases only). This argument is expressed as the full path name.
Db-Case-Insensitive 1 Oracle ® only. Enables certain case-insensitivity functionality within
Oracle database. Requires you to restart the AR System server.
Important: If this option is set to True, AR System on Oracle performs a
full-table scan and does not use indexes, even if you search only for the
request ID (C1-field). Almost every statement from AR System makes a
full table scan in the Oracle database, which can cause performance
problems.
Db-Character-Set 2 Initializes an internal variable that the server uses for various purposes,
such as adjusting the database's short column size so that the number of
characters in a datum does not exceed the number of bytes in the database
field. Another use for the variable is to inform the ARGetServerInfo
request AR_SERVER_INFO_DB_CHAR_SET. (The installer sets the Db-
Character-Set value.)
The values of this field are as follows:
Unicode (UTF-16)—UTF-16 UCS-2
Unicode (UTF-8)—UTF-8
Db-Connection-Retries 2 Number of times the AR System Server will retry a lost connection to the
database. The default is 100.
Db-Max-Attach-Size 2 The maximum size (in bytes) for attached files in the Oracle RDBMS. The
default value is 2 GB. The maximum value allowed is limited by your
server operating system and configuration.
Db-Max-Text-Size 2 The maximum size allowed for long character text data in Oracle, SQL
Server, and Sybase databases. For Oracle databases, this value is also used
for memory allocation during the processing of long text data; therefore,
you must use it conservatively. The default for an Oracle database is
4,194,308 bytes. For SQL Server and Sybase, the default is 2,147,483,647
bytes. The maximum value allowed for either database is 2,147,483,647
bytes.
Db-name 1 For Oracle, the name of the tablespace that ARServer will use.
For all other supported databases, the name of the underlying SQL
database. The default value is ARSystem.
Db-password The database password associated with the ARSystem database and table
space (applicable for Sybase, MS SQL, Oracle, and DB2 databases only).
The password can be modified by using the ARSetServerInfo function
and is stored in encrypted form. If you change the password manually,
specify this option by using clear text, and change the password by using
the AR System Administration: Server Information form to encrypt it.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 259

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Db-user 1 The user name that AR System uses to access the underlying database
(Oracle, Sybase, or MS SQL). The default is ARAdmin.
Debug-GroupId The group name to which a user must belong to allow logging options
such as API, Database, and Filter logging to be turned on in AR System
clients. Logging options are disabled for users who are not members of the
specified group. The group names can be Public, Administrator, Sub
Administrator, or Browser. You can also set this option in the Client-Side
Logging Group field on the Log Files tab.
Debug-mode A bitmask indicating the server debug modes. Each bit has a
corresponding value. To activate one bit, supply its value for the Debugmode
option. To activate two or more bits, add the values, and supply the
total. (For example, to activate bits 1 and 3, use the number 5 because bit 1
has a value of 1, and bit 3 has a value of 4.) To deactivate a bit, subtract its
value from the Debug-mode total.
260 Configuring
Bit 1 (Value=1)—Turns on SQL tracing for the arserverd process
(applicable for SQL databases only). The default file for SQL tracing is
arsql.log (located in the directory specified for the Server-directory
option). You can override this default by using the SQL-Log-File
option.
Bit 2 (Value=2)—Turns on filter tracing for the arserverd process. The
default file for filter tracing is arfilter.log (located in the directory
specified for the Server-directory option). You can override this
default by using the Filter-Log-File option.
Bit 3 (Value=4)—Turns on user tracing for the arserverd process. The
default file for user tracing is aruser.log (located in the directory
specified for the Server-directory option). You can override this
default by using the User-Log-File option.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Debug-mode (continued) Bit 4 (Value=8)—Turns on escalation tracing for the arserverd process.
The default file for escalation tracing is arescl.log (located in the
directory specified for the Server-directory option). You can override
this default by using the Escalation-Log-File option.
Bit 5 (Value=16)—Turns on API tracing for the arserverd process. The
default file for API tracing is arapi.log (located in the directory
specified for the Server-directory option). You can override this
default by using the API-Log-File option.
Bit 6 (Value=32)—Turns on thread tracing for the arserverd process.
The default file for thread tracing is arthread.log (located in the
directory specified for the Server-directory option). You can override
this default by using the Thread-Log-File option.
Bit 7 (Value=64)—Turns on alert tracing for the arserverd process. The
default file for alert tracing is aralert.log (located in the directory
specified for the Server-directory option). You can override this
default by using the Alert-Log-File option.
Default-Allowable-
Currencies 2
Bit 8 (Value=128)—Turns on arforkd tracing for the arserverd
process. The default file for arforkd tracing is arforkd.log (located in
the directory specified for the Server-directory option). You can
override this default by using the arfork-Log-File option.
Bit 9 (Value=256)— Turns on server group tracing for the arserverd
process. The default file for server group tracing is arsrvgrp.log
(located in the directory specified for the Server-directory option).
You can override this default by using the Server-Group-Log-File
option.
Bit 10 (Value=512)—Turns on tracing for full text indexing. The default
file for full text indexer tracing is arftindx.log (located in the directory
specified for the Server-directory option). You can override this
default by using the Full-Text-Indexer-Log-File option.
Bit 16 (Value=32768)—Turns on distributed server tracing for the
arservdsd process (applicable for Distributed Server Option only). The
default file for distributed server tracing is ardist.log (located in the
directory specified for the Server-directory option). You can override
this default by using the Distrib-Log-File option.
Bit 17 (Value= 65536)—Turns on Approval Server tracing. Specify the
location for the log file arapprov.log using the AP: Admin-Server
Settings form, accessed from the Approval Menu > Server Settings
command.
Bit 18 (Value=131072)—Turns on plug-in tracing for the arserverd
process. The default file for plug-in tracing is arplugin.log (located in
the directory specified for the Server-directory option). You can
override this default by using the Plugin-Log-File option.
Default allowable currency types used for Currency fields in clients.
Default-Functional-
Currencies 2
Default functional currency types used for Currency fields in clients.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 261

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Default-Order-By 2 The default value to order search results. Valid values are T and F. T
indicates that there is a default order, which is to sort by entry ID. F
indicates that there is no default order and no order clause is added to the
command if there is not a specific sort order specified. The default is T
(apply default sort order).
Default-Web-Path The URL to the directory path for the default web server pointing to the
AR System server.
Delay-Recache-Time 2 The number of seconds before making the latest cache available to all
threads. Valid values for this option are 0 to 3600 seconds. The minimum
is 0, which means every API call will get the latest cache (that is, the cache
will be copied for every administrator call). Setting the option to 0 causes
slower performance for cache operations. The default value is 5 seconds.
Disable-Admin-Ops A flag that indicates whether administrator operations are allowed on the
server. The values for this option are 0 (disabled) and 1 (enabled). The
default is 0.
If the Server Groups check box is selected, this setting is ignored. Server
groups can be configured in the AR System Server Group Operation
Ranking form to make sure that only one server performs the operation.
See “Running servers as part of a group” on page 155.
Disable-Alerts Prevents alerts from being sent when alert events are created. Valid values
for this option are T and F. The default is F (alerts are enabled). If the
parameter is set to T, no threads are started in the alert queue and no alerts
are sent. Changes to this setting do not take effect until the server is
restarted.
Disable-Archive 2 Allows archive to be disabled (T) or enabled (F) when the server starts up.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
262 Configuring

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Disable-Client-Operation 2 Restricts time-consuming operations (such as reporting) during busy
times, improving the overall performance. This option can be set to certain
times of the day. It can also exclude users of specific groups so that they
are not blocked from performing the specified operation. For example, you
can allow only the administrator to perform reporting during busy hours.
The syntax for this option is:
Disable-Client-Operation:
[[]-[]] []
The tag number is defined in the ar.h file. To specify start and stop times,
enter them in 24-hour format (hh:mm). The times are include times. For
example, 00:00-13:59 disables from midnight until 1:59 p.m.
The group_ID_list is a list of none, one, or multiple group IDs delimited
by spaces. To specify the groups to exclude, enter the group ID. For
example:
Disable-Client-Operation: 1 13:00-17:59 1
The second and third sections are optional and are delineated by spaces.
For example, if you did not specify a start or stop time, the syntax would
look like this:
Disable-Client-Operation: 2 18:00- 10
To start disabling operations from midnight until 6:00 a.m. excepting
group 10, enter:
Disable-Client-Operation: 2 -6:00 10
If there is no argument for the second section, the option disables the
operations from the client all the time. If there is no argument for the third
section (users to exclude), then all users from that client cannot run the
operations.
You can specify multiple Disable-Client-Operation lines.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 263

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Disable-Client-Operation 2
(continued)
264 Configuring
Following are the Disable-Client-Operation tag numbers
1—AR System clients prior to the 5.0 version
2—BMC Remedy Administrator
3—BMC Remedy User
4—BMC Remedy Import
5—Distributed Server Option
6—AR System ODBC
7—Approval Server
8—AR System web server (waserver)
9—Mid tier (version 5.0 and later)
10—Palm Pilot
11—Flashboards
12—Flashboards mid tier
13—Enterprise integration
14—arreload
15—arcache
16—ardist
17—runmacro
18—armaild, armailex (pre-5.1)
19—arimportcmd
20—Report creator plug-in
21—BMC Remedy Alert
4000—Driver (sample program)
4001—Distributor of application
4002—arhelp
4003—arjanitor
4004—armenu
4005—arstruct
4006—artext
4007—arsqled
4008—archgsel
Disable-Escalations A flag that indicates whether escalations are allowed on the server. The
values for this option are T and F. The default is F.
If the Server Groups check box is selected, this setting is ignored. Server
groups can be configured in the AR System Server Group Operation
Ranking form to make sure that only one server performs the operation.
See “Running servers as part of a group” on page 155.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Disable-Non-Unicode-Clients Allows a Unicode server to refuse requests from non-Unicode clients (for
example, BMC Remedy User, BMC Remedy Import; but not BMC Remedy
Mid Tier 7.0 or the arimportcmd command). This parameter has no effect
on a non-Unicode server.
If the value is F (the default), Unicode and non-Unicode clients can contact
the server. If the value is T, a Unicode server will refuse requests from non-
Unicode clients.
Regardless of the setting, BMC Remedy Administrator and BMC Remedy
Alert can always contact the server.
Disable-User-Cache-
Utilities
Display-General-Auth-
Message2
Prevents unauthorized users from attempting to use User Cache
commands. Valid values for this option are T and F. The default is F (cache
utilities are enabled). If the parameter is set to T, then the arreload and
arcache utilities are disabled for the AR System server.
Indicates whether to display a message when user authentication fails.
If set to True (the default), a generic message is displayed for user name
and password errors:
In BMC Remedy User: ARERR [623] Authentication failed
In a browser: ARERR [9388] Authentication failed
If set to False, each authentication error displays a different message:
In BMC Remedy User:
ARERR [612] No such user is registered with this server
ARERR [329] Invalid password or authentication string for
existing user
In a browser:
ARERR [9381] No such user is registered with this server
ARERR [9382] Invalid password or authentication string for
existing user
The syntax for the option is:
Display-General-Auth-Message:T
Distrib-Log-File The name of the file to use if distributed server tracing is turned on (see
“Debug-mode” on page 260). This argument is expressed as the full path
name.
Distributed-RPC-Socket The specific AR System server to use for the distributed server. By default,
the distributed server runs in the queues like any other user.
Domain-Name 2 Changes the domain name portion of the fully qualified server name. By
default, a server determines the domain name from the network interface.
In rare circumstances, this method does not achieve the desired result due
to unexpected network card configurations. In those instances, this option
can be used to override the domain name derived from the network
interface.
DSO-Cache-Check-Interval 2 Sets the number of seconds between DSO checks for changes to the source
and target forms.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 265

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
DSO-Error-Retry-Option 2 Determines the behavior within the DSO process for retrying after an
error. The settings are as follows:
266 Configuring
0 (the default): Retry standard connection and transmission errors.
1: Never retry after any type of error.
2: Always retry regardless of the type of error.
3: Retry standard connection and transmission errors plus database
errors.
For example:
DSO-Error-Retry-Option: 2
DSO-Host-Name 2 The name for the current machine for DSO use. This setting allows for an
alias for the current machine within Distributed Mapping distributions.
DSO-Local-RPC-Socket 2 The RPC program number that DSO uses. This setting is optional.
DSO-Mark-Pending-Retry-
Flag 2
DSO-Max-Pending-Records-
Per-Query 2
A flag indicating if the DSO will stop the processing of a pending list in
case it fails to contact a busy AR System server after retrying one time.
Valid values are T and F.
Defines the limit for the number of Distributed Pending form records that
DSO will read in a single database query. The lower limit is 1, and there is
no upper limit. If this configuration item is not present, the default value
is 1000.
DSO-Merge-DupID-Overwrite 2 Defines what action the server will perform if a duplicate entry ID is found
on the target AR System server. Valid values are T and F. If set to T,
mapped fields are updated, and unmapped fields are set to NULL.
DSO-Polling-Interval 2 Defines the intervals (in seconds) at which the DSO will check the
Distributed Pending form for pending distributed operations. This is used
as a backup in case there are no signals from AR System workflow. The
value can be an integer between 15 and 7200. If you set the value to 0, DSO
will set the polling interval to 15 seconds (the lowest value); if you set the
value at an integer greater than 7200, DSO will set the polling interval to
the maximum of 7200 seconds. The DSO polling interval feature is
disabled as a default. For more information about Distributed Server
Operations (DSO), see the Administering BMC Remedy DSO guide.
DSO-Target-Connection Defines the information for the target AR System server. The following
format is used:
DSO-Target-Connection: :
DSO-Target-Password The password used to access the target AR System server through the
distributed server. The following format is used:
DSO-Target-Password: :
DSO-Timeout-Normal 2 Defines the timeout the DSO applies during communication with the
AR System server. It overrides the default timeout value and can be an
integer between 60 and 21600 (in seconds), representing a range from 1
minute to 6 hours. If the value is set out of range, the closest integer to that
value will be applied. If no value is entered, the default value (120 seconds)
is used.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
DSO-User-Password The password for the local distributed server user.
Email-Import-Form-By-
Default 2
ar.conf (ar.cfg)
Specifies whether email forms are imported by default when the
AR System server is started up. Valid values are True (T) and False (F). A
value of T means that email forms will be imported by default when the
AR System server is restarted; a value of F means that the forms will not be
imported by default. The default is T.
Email-Notify-From 2 The sender name to use for filter-generated email notifications where no
subject is specified. This value is limited to 29 characters.
Email-Timeout 2 Sets the maximum amount of time that arserverd waits for a return value
from sendmail. This parameter was valid in versions 4.5.1 through 5.0.1,
but was made obsolete with the introduction of the Email Engine in
version 5.1.0 of AR System.
Encrypt-Data-Encryption-
Algorithm 2
Encrypt-Public-Key-
Algorithm 2
An integer value indicating the encryption algorithm. If you switch to a
new algorithm, client connections using the old algorithm automatically
perform a key exchange to create keys that correspond to the new
algorithm. The default is 0 (zero), RCA encryption, 128-bit key.
The encryption algorithm of the public key. BMC Remedy Encryption
products use the RSA algorithm for public key cryptography. RSA is a
public-key cryptosystem that uses modular arithmetic and elementary
number theory to do certain computations.
The public key is used in the data encryption key negotiation. This key
negotiation occurs at the beginning of the API session and when the data
encryption keys expires.
The settings are:
4—A 512-bit RSA key. This is the default for standard security.
5—A 1024-bit RSA key. This is the default for performance security.
6—A 2048-bit RSA key. This is the default for premium security.
All lower-level encryption technologies are available in higher security
level products. For example, the Premium Security product includes the
encryption algorithms of Performance Security and Standard Security.
Encrypt-Public-Key-Expire 2 An integer value (in seconds) indicating the amount of time for the
duration of the public key. After expiration, the server creates a new public
key. The default is 86400 seconds (24 hours).
Encrypt-Security-Policy 2 An integer value indicating whether encryption is on or off. The values are
as follows:
0: Encryption between the client and server is allowed, but not required.
1: Encryption between the client and server is required; unencrypted
communication is not allowed.
2 (the default): Encryption between the client and server is disabled.
Encrypt-Session-Hash-
Entries 2
The size of the hash table that holds the encrypted session information. The
default is 509, there is no maximum.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 267

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Encrypt-Symmetric-Data-Key-
Expire 2
268 Configuring
An integer value (in seconds) indicating the amount of time for the
duration of the data encryption key. After expiration, if necessary, a new
key exchange occurs. The default is 2700 seconds (45 minutes).
Escalation-Log-File The name of the file to use if escalation tracing is turned on (see “Debugmode”
on page 260). This argument is expressed as the full path name.
Exception-Diagnostic-
Option 2
External-Authentication-
Group-Mapping 2
External-Authentication-
Ignore-Excess-Groups 2
An integer value controlling the diagnostic output when the server
crashes. The values are as follows:
0: AR_EXCEPTION_DIAG_ALL; includes all diagnostic output when an
exception occurs.
1: AR_EXCEPTION_EXCLUDE_STACK; excludes the stack trace in the
diagnostic output when an exception occurs.
Specifies mapping of LDAP groups to AR System groups for the purpose
of external authentication. The value of this option consists of one or more
pairs of group names separated by semicolons, as shown in the following
example:
"LDAP-1" "ARS-1";"LDAP-2" "ARS-2";"LDAP-3" "ARS-3"
Use mapping as an alternative to creating an AR System group
corresponding to each LDAP group. You can map each LDAP group to an
AR System group (as in the example) or multiple LDAP groups to a single
AR System group. (If you try to map a single LDAP group to multiple
AR System groups, only the first mapping expression will be valid.)
This option can be used with External-Authentication-Ignore-
Excess-Groups.
A flag used by AR System during external authentication. A value of 0
indicates that the user is authenticated when there is a match between
every LDAP group to which the user belongs and a corresponding group
in AR System. A value of 1 indicates that the user is authenticated when
any single LDAP group to which the user belongs matches a group in
AR System, and the excess LDAP groups are ignored. The default value is
0.
This option can be used with External-Authentication-Group-
Mapping.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
External-Authentication-
Return-Data-Capabilities 2
ar.conf (ar.cfg)
A bit mask that enables you to specify the return data capabilities for the
current AREA plug-in. This setting does not control the AREA plug-in; it
merely describes the behavior of the plug-in, enabling server optimization.
Acceptable values are
Bit 1 (Value=1)—No email address is provided.
Bit 2 (Value=2)—No notify mechanism is provided.
Bit 3 (Value=4)—No group identifiers are provided.
Bit 4 (Value=8)—No license information is provided.
Bit 5 (Value=16)—No notification user validation should occur.
The default is 0, meaning the server attempts to retrieve this information
from AREA. A value of 7 enables the server potentially to reduce the
number of AREA related calls during notification processing.
A value of 16 enables the server to avoid using AREA for notification user
validation and information retrieval. Use this setting for sites using a form
of AREA that applies user names as email addresses and where there is no
benefit to accessing an authentication database.
External-Authentication- The RPC socket number on which an external authentication server awaits
RPC-Socket
requests for authentication. The default value is 0 (external authentication
will not be used).
The RPC program number for the plug-in server is 390695.
External-Authentication- The RPC timeout (in seconds) used when making calls to the
RPC-Timeout
authentication (AREA) server. The default value is 30 seconds.
External-Authentication- The internal timeout (in seconds) the AR System server uses to
Sync-Timeout
periodically invoke the external authentication server’s
AREANeedToSyncCallback() function, which instructs the AR System
server to renew its internally stored user information in the event there are
changes made to the source used to authenticate users. A 0 value means
that the AR System server will not invoke the call to the external
authentication (AREA) server. The default value is 300 seconds.
Filter-Api-Timeout Indicates the time limit (in seconds) allowed for the Filter API RPC to
respond to the server’s request before returning an error. The minimum
value is 0, and the maximum is 300. The default is 40 seconds.
Filter-Log-File The name of the file to use if filter tracing is turned on (see “Debug-mode”
on page 260). This argument is expressed as the full path name.
Filter-Max-Stack The maximum number of levels of recursion allowed for a given
operation. The data modification performed by an
AR_FILTER_ACTION_FIELDP filter action might trigger a second set, or
level, of filters, one of which might trigger filters a third level down and so
on. This option limits the number of times such recursion can happen,
preventing the server crash that would occur if the recursion continued
indefinitely. The default value is 25.
Filter-Max-Total The maximum number of filters that the server will execute for a given
operation. The default value is 10000.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 269

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Flush-Log-Lines A flag to indicate whether you want the logged lines to be buffered instead
of written directly to disc. Valid values are T and F. Set to F to buffer the
logged lines. The default value is T (the logged lines will be written to disc).
Full-Text-Case-Option Defines whether full text searching is case sensitive or case insensitive.
This setting affects all fields indexed for full text search and affects how the
indexes are built. Therefore, changes to this setting will trigger an
automatic re-index. The default value is case insensitive.
Full-Text-Collection-
Director 1
Full-Text-Configuration-
Directory
270 Configuring
The location in the file system where search engine index files are stored.
The location in the file system where search engine configuration files are
stored.
Full-Text-Disable-Indexing Controls whether the server processes indexing tasks that are pending.
When disabled, indexing tasks are still recorded for processing at a later
time when indexing is enabled. The options are T (true) and F (false). The
default is F (do not disable).
Full-Text-Disable-Searching Controls whether the server uses the full text search engine for searching.
When disabled, the server uses the search capability of the underlying
database, whether a user has a full text license. The options are T (true) and
F (false). The default is F (do not disable).
Full-Text-Indexer-Log-File The name of the file to use if full text indexer tracing is turned on (see
“Debug-mode” on page 260). This argument is expressed as the full path
name.
Full-Text-Indexer-Optimize-
Threshold
Full-Text-Indexer-Recovery-
Interval
The number of additions, modifications, or deletions that must occur
before the server will optimize an index. The default value is 1000. The
minimum value is 10. Optimization improves the time it takes to search
with an index, but it can be an intensive operation.
Defines the number of minutes the server waits between periodic attempts
to index entries that failed to index for an unexpected reason in a prior
attempt. The default value is 60 minutes.
Full-Text-License-Timeout The number of hours the AR System server waits before disconnecting
inactive users. If the user is holding a floating full text license token, the
system also frees the token at this time. The default value is two hours.
Full-Text-Match-Option Defines how the server modifies qualifications received from the client.
The options are:
0: Force leading and trailing wildcards
Full-Text-Search-Threshold-
High
1: Ignore leading and force trailing wildcards
2: Ignore leading wildcard
3: Remove leading and trailing wildcards
4: Query unchanged (the default)
During the processing of search results, the server combines results from
subqueries to arrive at the final result set. If the number of rows created
during processing exceeds this value, the server returns an error message
indicating the search is too complex. The default value is 1,000,000.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
Full-Text-Search-Threshold-
Low
ar.conf (ar.cfg)
While processing search results, the server creates a temporary table if the
number of FTS matches reaches this value. If the number of FTS matches
is under this value, the server uses the SQL IN operator for a query on an
existing table. The default value is 200.
Full-Text-Temp-Directory The location in the file system where search engine temporary files are
stored. This directory needs to be periodically cleaned of the temporary
files that accumulate.
GetListEntry-Server-Date-
Format 2
Returns the GetListEntry date formatted on the server instead of on the
client. This option is used mainly for backward compatibility purposes.
Valid values are T and F. The default value is F (format dates on client).
Guest-Restricted-Read Defines whether guest users will receive a restricted read license when
they log in to AR System. If this option is not selected, guest users will
receive a read license. The values are true (T) and false (F).
GUID-Prefix 2 The character string used as a prefix for GUID strings that are generated
by filters.
Homepage-Form The path to a home page to be used system wide as the default home page
for the current server when a user logs in.
This default home page will only be used if:
The current server is designated as the server for the home page in the
AR System User Preference form, or
The current server is designated as the home page server on the General
Settings page in BMC Remedy Mid Tier Configuration Tool (see the
Installing and Administering BMC Remedy Mid Tier guide for more
information) and
No home page is specified in the AR System User Preference form (you
can also set this in the Options dialog box in BMC Remedy User).
Note: If the home page is deleted, this field is cleared, and the default home
page will need to be re-entered.
Informix-DBServer-Name 1 The name of the server where the underlying database is located
(applicable for Informix databases only).
Informix-Relay-Module 1 Specifies the environment setting for the path for the Informix relay
module (applicable for Informix databases only).
Informix-TBConfig 1 The name of the configuration file for the underlying database (applicable
for Informix databases only). The default name is onconfig.
Init-Form 2 Specifies a form that will be opened every time any client logs into the
system. (Note that this does not work on the mid tier.) Workflow might be
specified to record details of the login or to deny access based on various
parameters. Without this parameter, it would be necessary to attach the
workflow to every single form defined on the system.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 271

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Internal-User-Info-Hash-
Lists 2
272 Configuring
The number of shared, linked lists that hold all user-related information.
This number must be represented in a power of 2. The default setting is
128, the minimum number is 2, and there is no maximum number defined.
Note: AR System does not check to make sure that the number defined in
the ar.conf/ar.cfg file is in a power of 2; therefore, unexpected
behaviors of the AR System server might occur if the number is not in a
power of 2.
IP-Name A parameter used to specify that a server has multiple names. The
parameter can appear in the ar.conf (ar.cfg) file more than one time.
When checking workflow and connections against itself, the server will
compare its server name, host name, IP aliases, and any names given by
the IP-Name parameter to the name passed to it. If the name matches any
of those, the server will conclude that the workflow or connection is for
itself.
The IP-Name parameter can be used for servers with variable length
domains or for servers on machines with multiple internet addresses. For
example, to allow connection to a machine named tix as tix,
tix.company.com, or tix.eng.company.com, an administrator would
have three IP-Name entries, one for each of the connection names.
To allow connection to a machine with multiple internet addresses like
tix.company.com, tix.biggercompany.com, and tix.evenbigger.com,
an administrator would create an IP-Name entry for each of those names.
License-Timeout The number of hours the AR System server waits before disconnecting
inactive users. If a user is holding a floating write license token, the system
also frees the token at this time. The default value is two hours.
Localized-Server Indicates whether the server is running in localized support mode. If it is
not, the server does not search for or use localized strings. If localized
support mode is running, localized messages are used, if present. The
values for this option are T and F. The default is F (not localized).
Locked-Workflow-Log-Mode 2 Causes the server to record locked workflow actions in workflow logs.
These actions are always written as encrypted strings.
Log-File-Append A flag that indicates whether to create a separate *.bak file or to append
to the existing log file. Valid values for this option are T and F. A value of
F creates a *.bak file; T indicates that new log information be appended to
the existing file. The default is F.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Map-IP-Address 2 The specific IP address mappings for alerts to work through firewalls
where Network Address Translation is enabled (NAT). You must set up a
mapping for each client machine that has access through the firewall
where the client IP address is translated from an internal address to a valid
external address. In addition, a mapping is required for the ARServer IP
address if the host where ARServer resides is also translated.
For example, the following figure maps AR System server and BMC
Remedy Alert. The Alert client comes through the firewall and the address
changes from 10.5.119.83 to a valid public IP address of 123.45.67.89. The
server address changes from 123.45.55.90 to 10.26.55.65 on the other side of
the firewall.
Figure B-1: Mapping IP addresses through a firewall
AR System
server
123.45.55.90
Here is a multiple line example:
Firewall
123.45.67.89
123.45.55.90
Firewall table
of IP addresses
10.5.119.83
10.26.55.65
Internal table of
IP address mappings
Map-IP-Address: 10.5.119.83 123.45.67.89
Map-IP-Address: 123.45.55.90 10.26.55.65
ALERT
Client
10.5.119.83
Map-IP-Address: 123.45.67.89 10.5.119.83
Map-IP-Address: 123.45.55.90 10.26.55.65
Max-Entries-Per-Query The maximum number of requests returned by a single search. Because
users can also specify the maximum number of requests returned (through
Search Preferences in the AR System User Preferences form or the Options
dialog box in BMC Remedy User), the actual maximum is the lower of
these two values. The default value is no (server-defined) maximum.
Max-Log-File-Size The maximum size in bytes for system log files. If the maximum is reached,
the logging cycle starts over at the beginning of the file, overwriting
existing information. The default value is 0 (no limit). This option does not
apply to the Arfork-Log-File.
Max-Notify-Mail-Line-Len 2 Maximum number of bytes that can be used in a single line of a mail
notification.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 273

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Max-Password-Attempts Sets the maximum number of consecutive bad password retries a user is
allowed to make. If this option is set to 3, the user has 3 chances to log in.
If all 3 attempts have bad passwords, the user account will be marked as
INVALID.
The allowed values for this option are 0 and all positive integers. A value
of 0 turns feature off, and any positive integer sets the limit.
Mid-Tier-Service-Password Specifies the password that administrators will need to access the mid tier.
Minimum-API-Version Specifies the oldest API version with which the server will communicate.
The default value is 0, which means that the server will communicate with
all API versions. If the client’s API version is less than the specified value,
the server will refuse to talk with the client, and the client will receive a
decode error. The API version for release 7.0 is 12.
Minimum-CMDB-API-Version Specifies the oldest CMDB API version with which the server will
communicate. The default value of this variable is 3. If the version of a
CMDB call is smaller than this variable, the server will refuse the call.
This variable is independent from the Minimum-API-Version option.
Multiple-ARSystem-Servers A flag indicating whether you want to run multiple servers on one host
machine. Valid values for this option are T and F. To run multiple servers,
you must set this option to T in the configuration file for each server you
are running. The default value is F (you are not running multiple servers
on one machine).
Note: If you set this option to T and are running previous versions of
AR System applications, such as DSO or the Approval Server, those
applications will not work. You must upgrade your applications if you
want them to work with this option.
Multiple-Assign-Groups 2 Defines whether multiple assignee groups will be stored in row-level
security Field 112. This enables users from multiple groups to access the
same entry. In the past, only one group could be stored in Field 112. Valid
values for this option are T (true) and F (false). The default value is T (allow
multiple groups).
Next-ID-Commit 2 When the system generates the next ID number for a record in the
database, it performs a new commit transaction if this parameter is set to T
(true). If the parameter is set to F (false), the transaction to generate the next
ID is included as part of the create entry transaction. Set the value to T to
increase efficiency and for debugging. The default is F.
This option does not work with Informix databases.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.
274 Configuring

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
NextID-Block-Size Allocates next IDs in blocks rather than one at a time. Allocating in blocks
increases performance during a create operation.
Edit the NextID-Block-Size value to a positive number (up to 1000), for
example:
NextID-Block-Size: 50
The default value is 1. If 0 or a negative number (for example, -1) is used,
the server will use the default value of 1.
You do not need to restart the server for the change to take effect. The
option is started immediately.
To disable this option, set the value of NextID-Block-Size to 1, or remove
the parameter from the configuration file. Note that this option does not
work with Informix databases.
Note: This setting is always disabled on the Distributed Pending form so
that DSO can operate correctly.
Warning: The use of this configuration setting might result in unpredictably
large NextID sequence gaps. The likelihood of this occurring increases
with the use of multiple servers that share a database. The AR System
server will not malfunction due to this gap and should not be considered
a defect.
Notification-Web-Path The base URL that appears in email notifications. If this option is not used,
the Default-Web-Path is used. (Notification-Web-Path is available
because the Default-Web-Path is specified for other applications like
flashboards, and it might be different from the mid tier web path for
opening requests in a notification.)
Oracle-Bulk-Fetch-Count 2 Defines the number of the rows of data fetched at a time from the result set
when querying an Oracle database. The minimum is 1, the maximum is
100, and the default is 50. The higher the value, the more memory is used
during data retrieval.
Oracle-Cursor-Sharing 2 Specifies the database setting that matches the setting in the Oracle
initialization file (initARS.ora if the AR System database SID is ARS).
If the initARS.ora file includes the line CURSOR_SHARING=FORCE, use
FORCE as the value for this option also to indicate an Oracle setting to the
AR System server.
If your Oracle database is set for SIMILAR, use the similar option:
Oracle-Cursor-Sharing: SIMILAR
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 275

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Oracle-Dblink-Character-
Set 2
276 Configuring
Enables the support of remote databases with different character sets. You
can enter this parameter any number of times in the configuration file for
multiple view forms on different remote databases with different link
names. The syntax is as follows:
Oracle-Dblink-Character-Set:
For example:
Oracle-Dblink-Character-Set: eng.remedy.com shift-jis
The should exactly match LINK in the phrase
OWNERNAME.TABLENAME@LINK in the table name of the View form on the
remote database.
Supported character sets are utf-8, utf-16, ucs-2, euc, and shift-jis.
For more information about view forms, see the Form and Application
Objects guide.
Oracle-Search-On-Clob 2 Defines whether CLOBs can be searched. Valid values are T and F. If the
option is set to T, when the search is performed, the qualification can
include all the diary fields and character fields that are stored in the
database as CLOB columns. Including these fields affects performance,
and indexes cannot be used for this type of query. If the option is set to F,
searching on these fields will return an error. CLOBs can use the operator
LIKE, but not =. The default is T (allow search on CLOBs).
Oracle-SID 1 The system ID for the underlying database (applicable for Oracle
databases only).
Oracle-Clob-Storage-In-Row Controls the Oracle CLOB storage. The default value of this setting is F,
and new CLOBs will be “out of row.”
If the setting is set to T, all CLOBs to be created are “in row.”
Oracle-Two-Task 1 The two-task environment setting for the underlying database (applicable
for Oracle databases only).
Per-Thread-Logging A flag indicating whether you want to create per-thread log files. Valid
values are T and F. If set to T, per-thread log files will be created. The
default value is F (off).
Plugin 2 File name of one or more plug-ins that the plug-in server will load. The file
name of the DLL or shared object is provided. The file name might be an
absolute file name or might be relative to the AR System installation
directory. You can have as many Plugin: lines in the ar.conf (ar.cfg)
file as needed, but only one file name can be listed for each occurrence of
the option.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Plugin-ARDBC-Threads 2 The number of threads that are dedicated to handling ARDBC requests
from the AR System server. Optionally, you can specify a maximum
number of threads, as shown in the following example:
Plugin-ARDBC-Threads:
[]
To specify a minimum of 3 threads and a maximum of 10, the syntax is:
Plugin-ARDBC-Threads: 3 10
By default, 1 thread is initiated if this option is not specified. The plug-in
server increases the number of threads for a given plug-in if there is
sufficient demand up to the “maximum number of threads.”
Plugin-AREA-Threads 2 One can specify the number of threads that are dedicated to handling
AREA requests from the AR System server. Optionally, you can specify a
maximum number of threads, as shown in the following example:
Plugin-AREA-Threads:
[]
To specify a minimum of 3 threads and a maximum of 10, the syntax is:
Plugin-AREA-Threads: 3 10
By default, 1 thread is initiated if this option is not specified. The plug-in
server increases the number of threads for a given plug-in if there is
sufficient demand up to the “maximum number of threads.”
Plugin-Disable-Remote 2 Specifies whether the plug-in server will accept calls from a remote server.
Valid values are T and F. If the option is set to T, the plug-in server accepts
calls only from an AR System server running on the local machine. The
default is F (allow calls from a remote server).
Plugin-Filter-API-Threads 2 One can specify the number of threads that are dedicated to handling
AR System Filter API requests from the AR System server. Optionally, you
can specify a maximum number of threads, as shown in the following
example:
Plugin-Filter-API-Threads:
[]
To specify a minimum of 4 threads and a maximum of 10, the syntax is:
Plugin-Filter-API-Threads: 4 10
By default, 1 thread is initiated if this option is not specified. The plug-in
server will increase the number of threads for a given plug-in if there is
sufficient demand up to the “maximum number of threads.”
Plugin-Log-File The name of the file to use if plug-in tracing is turned on (see “Debugmode”
on page 260). This argument is expressed as the full path name.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 277

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Plugin-Log-Level A setting that determines the level of detail for log messages. Valid values
are as follows. The values represent the amount of log information that is
printed. The lower the value, the more information that is included.
ARPLUGIN_OFF (Value=10000)—No log information is printed.
ARPLUGIN_SEVERE (Value=1000)—Only severe messages are printed.
This is the default value if no log level is specified.
ARPLUGIN_WARNING (Value=900)—Severe and warning messages are
printed.
ARPLUGIN_INFO (Value=800)—Status, severe, and warning messages are
printed.
ARPLUGIN_CONFIG (Value=700)—Configuration, status, severe, and
warning messages are printed.
ARPLUGIN_FINE (Value=600)—Internal exceptions.
ARPLUGIN_FINER (Value=500)—Trace logs that log tasks as they are
executed within the system.
ARPLUGIN_FINEST (Value=400)—Code-level information.
ARPLUGIN_ALL (Value=100)—All log information is printed.
Plugin-Loopback-RPC-Socket 2 The RPC socket number for the private server queue to which loopback
plug-in API calls should be directed. The acceptable values are in the
following ranges: 390621–390634, 390636–390669, and 390680–390694.
Loopback plug-ins (like the Report Creator plug-in) that make calls back
into AR System, will use this value to determine the queue to request. By
default, the API calls that the plug-in makes are directed to a queue that
corresponds with the call type. To be effective, the server must be
configured to have the designated private queue for this setting.
Plugin-Password If this option is specified, the plug-in server will accept connections only
from AR System servers that have been configured to use the same
password by way of the Server-Plugin-Target-Password attribute.
If this option is not specified, the plug-in server will accept connections
from AR System servers that have not been configured to use a password.
Plugin-Path 2 Specifies the search path used to load a plug-in. The path will be appended
to the current value of LD_LIBRARY_PATH (AIX, Linux ® , Solaris),
SHLIB_PATH (HPUX), or PATH (WINNT). You can list more than one
Plugin-Path; each path is appended in the order it appears in the
configuration file. The syntax is:
Plugin-Path: []
with no spaces between the delimeter and the path.
For example:
UNIX
Plugin-Path: /usr/ar/bin:/usr/ar/common/xyz
Windows
Plugin-Path: C:\Program Files\AR System\arserver;C:\Program
Files\AR System\common\xyz
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.
278 Configuring

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Plugin-Port 2 The port number on which the plug-in server waits for incoming requests.
Preference-Server-Option Specifies if users are forced to use centralized preferences. Following are
the preference server settings:
1—Users can choose to use a preference server, if a preference server is
available.
2—Users must use the specified preference server.
3—Users must use a preference server, but they cannot use this server as
a preference server. If users choose a server that is not a preference
server, a warning is returned.
Private-RPC-Socket The specific RPC program number that determines the type of queue to
which requests will be routed, as well as the number of threads running on
that queue.
RE-Log-File-Location 2 The location of the Reconciliation Engine's log file.
Read-Only-Tran-Off 2 Causes AR System not to create database transactions when only reading
data.
Record-Server-Events Specifies the server events that you want to log. When you enter a value
for specific server events, those events are logged in the Server Events
form, thereby making server-related changes available to workflow and
API programs. Enter the values separated by semicolons as in the
following example:
Record-Server-Events: 4;8;9;12;14;
For information about the Server Events form, viewing recorded server
events, and using server events in workflow, see Chapter E, “Working
with the Server Events form.”
Enter the following values for the events you want to record:
1—Form
2—Field
3—Menu
4—Filter
5—Import
6—Active Link
7—Escalation
8—View
9—Container
10—User
11—Group
12—Server Setting
13—Alert Client Registration
14—Archive
15—Server Group Actions
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 279

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Register-With-Portmapper This setting can be used to prevent the AR System server from registering
with a portmapper. This feature is to be used in conjunction with setting
specific ports to enable you to run servers on machines that do not have a
portmapper. Valid values are T and F. The default is T (register with
portmapper).
No more than one server should attempt to register with AR System
Portmapper in an environment with multiple servers on one machine.
Remedy-App-Service-Password Specifies, in encrypted form, the password that AR System application
services such as AR System Approval Server will use to access the
AR System server.
RPC-Non-Blocking-IO 2 This parameter enables the AR System on compliant systems to receive
remote procedure calls in a non-blocking mode. Without this setting, the
server must receive an entire RPC header before processing a different one.
With this setting, the system can process multiple headers at the same
time. Set this parameter to T (TRUE) and then restart your AR System
server to run in RPC non-blocking mode. The default for this parameter is
F (FALSE); use the following syntax to set to TRUE:
RPC-Non-Blocking-IO: T
This functionality is not supported on Windows and Linux operating
systems.
The advantages of RPC-Non-Blocking-IO mode are as follows:
Prevents remote attackers from disabling RPC services.
Prevents invalid or corrupt packets from temporarily disabling the
arserverd service.
Important: The following patches must be installed to enable your system
to use this feature. If these patches are not installed, you will see either an
error message, or most of your RPC calls will be blocked.
HP
280 Configuring
PHNE_29210 - HPUX 11.0
PHNE_29211 - HPUX 11i
Solaris
108993-38 - Solaris 8
113319-19 - Solaris 9
IBM
Does not specify a specific patch number. There might be multiple file sets
required. (If you do not obtain an IBM patch, there is a possibility that your
server could crash.)
Fix for Authorized Problem Analysis Report (APAR) IY61602 - AIX 5.3
Fix for APAR IY61409 - AIX 5.2
Fix for APAR IY61598 - AIX 5.1
Fix for APAR IY71557 - AIX 5.2
Fix for APAR IY71632 - AIX 5.3
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Save-Login A value indicating whether users must log in to client tools. Allows users
to save a previous login of their choice.
0—Controlled by user (default setting).
1—Do not force a login that is controlled by the administrator.
2—Force login that is controlled by the administrator.
This option does not apply to the mid tier.
SCC-Comment-Checkin An integer value (0 or 1) indicating whether a source code control
integration requires you to enter a comment at checkin time. The default
value is 0 (no comment is required).
SCC-Comment-Checkout An integer value (0 or 1) indicating whether a source code control
integration requires you to enter a comment at checkout time. The default
value is 0 (no comment is required).
SCC-Enabled An integer value (0 or 1) indicating whether a source code control system
is being used with AR System. The default value is 0 (source code is
disabled).
SCC-Integration-Mode An integer value (0 or 1) indicating the level of source code control
integration. A 0 value means Advisory. A 1 value means Enforced. The
default is 0. For more information about these modes, see “Server
information—Source Control tab” on page 136.
SCC-Provider-Name The name of the Source Code Control Provider name; for example, Visual
Source Safe.
SCC-Target-Dir A character string for the source code control system target directory. If
none is present, this value is NULL. This string is limited to 255 characters.
Select-Query-Hint 2 The text to be used in a query hint (in the WITH clause of a SELECT
statement) when queries are supplied to SQL Server databases. This
parameter works only on queries triggered by GLE, GLEWF, and GME API
calls.
If this configuration item is an empty string or is not present, no WITH
clause is generated. Consult your SQL Server to determine the
appropriateness of using this feature in your environment.
The Select-Query-Hint option is commonly used with a NOLOCK setting
for allowing queries to execute without being blocked by simultaneous
updates, thereby improving performance. For example, to allow SQL
Server to read data in the process of being updated and avoid blocking,
specify:
Select-Query-Hint: NOLOCK
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 281

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Server-Connect-Name 2 An option for changing the name of a server in a server group. By default,
a server in a server group uses a fully qualified server name with domain
to identify itself. Others servers in the group use this name to
communicate. Add the following line to change the server name:
Server-Connect-Name: myservername
282 Configuring
If a common server alias is specified, the Server-Connect-Name option is
required.
This name must be resolvable by DNS and is used exactly as specified. For
more information, see “Running servers as part of a group” on page 155.
Server-directory 1 The data directory for AR System, expressed as a full path name. This
directory contains support files and log files for the AR System server.
Server-Group-Email-Admin-
Port 2
Server-Group-Flashboards-
Admin-Port 2
Establishes the port number (RMIPort) for email administration in BMC
Remedy Email Engine. If the port number in BMC Remedy Email Engine
is changed from the default, set this AR System server configuration to the
same port number to allow the server to communicate email
administration information to BMC Remedy Email Engine during server
group processing.
For example:
Server-Group-Email-Admin-Port: 2020
Establishes the port number (RMIRegistryPort) for flashboards
administration in the Flashboards server. If the port number in BMC
Remedy Flashboards is changed from the default, set this AR System
server configuration to the same port number to allow the server to
communicate flashboards administration information to the Flashboards
server during server group processing.
For example:
Server-Group-Flashboards-Admin-Port: 2021
Server-Group-Log-File The name and location of the server group trace log file. The default is
arsrvgrp.log. For example, the file location might be:
c:\temp\servgroup.log.
Server-Group-Member A flag that indicates whether the server is a member of a server group.
Valid values are T and F. The default is F.
Server-Group-Signal-Option 2 Indicates the method that a server uses to notify other servers in the group
that definition cache changes have occurred. If the value for this option is
set to T, the server uses arsignal to cause cache (definition) changes in
other server group members. If the value for this option is set to F (the
default), a server indicates that definition changes have occurred by
posting signals in the database. The signal is read by other servers in the
group at their preset check intervals. Because of an intentional delay used
to avoid multiple recaches, the servers will not recache until after a check
interval cycle in which there are no new recache signals. The database
posting method reduces server activity, but does not react as quickly as the
arsignal method. For more information, see “Running servers as part of
a group” on page 155.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Server-Name An alias that is always interpreted as the current server. The option is used
in multiple server installations to differentiate servers. If you specify a
value for Server-Name, type that value after the -h option when you use
the arreload command-line utility.
If you have a value for Server-Name, and you use arreload without the -h
option and the Server-Name value, arreload will use the default server
name rather than the name specified by Server-Name.
The Server-Name value is not fully qualified. For example, type alpha
instead of alpha.remedy.com.
Note: If you are running in a server group and you use a common server
alias, you must also define the Server-Connect-Name option. See
“Server-Connect-Name2 ” on page 282.
Server-Plugin-Alias 2 When the AR System server performs a call to a plug-in server, it must
determine if the plug-in name is an alias. Aliases can be used to direct the
AR System server to access a plug-in server that is running on a different
host or is listening at a specific port number. The syntax for this option is
as follows:
Server-Plugin-Alias:
[:]
Workflow (that is, references to AR Filter API and ARDBC plug-ins)
references a plug-in name. This name can be an alias to a real plug-in
running on a specific host at a given port number. This allows you to locate
a plug-in on a remote host or to run more than one instance of a plug-in on
one host. For example, to run the RMDY.ARDBC.XML plug-in on the remote
host foo at port number 12345, you would add the following text to your
ar.cfg:
Server-Plugin-Alias: RMDY.ARDBC.XML RMDY.ARDBC.XML foo:12345
Note that the alias and real plug-in names can be identical if you are simply
locating the plug-in on a remote host. To run more than one instance of the
plug-in on the same or different hosts, create different aliases that
reference the same plug-in running on their respective hosts.
Server-Plugin-Default-
Timeout
Server-Plugin-Target-
Password
The number of seconds within which the plug-in server must respond to
the call before an error is returned. The minimum value is 0, and the
maximum is 600. The default is 60 seconds.
The AR System server uses the specified password whenever
communicating with a plug-in server running at the host name and port
number specified. The syntax for this option is as follows:
Server-Plugin-Target-Password: ::
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 283

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Server-Side-Table-Chunk-
Size
284 Configuring
For server-side table fields, this number determines the number of entries
(or size of the chunk) that the server will retrieve at one time from the
database and store in memory to process during filter or filter guide
actions. The server then retrieves, stores, and processes the next chunk
until all the rows have been processed. Entering a value of zero (0) will
cause the server to retrieve an unlimited number of rows. The default is
1000 rows.
Entering a low value in this field causes the server to process smaller
chunks, which keeps the server memory usage down but results in slower
processing because the server will need to access the database many times,
especially for large tables. Entering a high value will cause the server to
retrieve and process large chunks of data and access the database fewer
times. This results in higher performance at the cost of memory use.
Server-Stats-Rec-Interval Defines (in seconds) how often the server will record server statistics. The
default is 60 seconds.
Server-Stats-Rec-Mode The server statistics recording mode determines what is written to the
server statistics form. There are three modes designated by the following
numerical values:
0—Indicates that recording is off. (This is the default.)
1—Indicates that the server records only the cumulative queue statistics.
Cumulative statistics are the sum of all the individual queue statistics.
2—Indicates that the server records both the cumulative queue statistics
and the individual queue statistics. One entry will be written for the
cumulative statistics and a separate entry will be written for each queue.
You can read the statistics in the Server Statistics form, which is installed
when you install AR System. For more information, see the Optimizing and
Troubleshooting AR System guide.
Set-Process-Timeout The number of seconds the AR System server waits before ending a Set
Fields process that has not completed. Valid values for this option are 1
through 60. The default value is 5 seconds.
SQL-Log-File The name of the file to use if SQL tracing is turned on (see “Debug-mode”
on page 260). This argument is expressed as the full path name.
SQL-Secure-Connection A flag that indicates what type of authentication to use to connect
AR System to an MSSQL database. Set this flag to T to use Windows
Authentication or to F to use SQL Authentication. This flag is valid only if
you are using an MSSQL database.
SQL-Server-Set-ANSI-
Defaults 2
Causes the server to issue a SET ANSI_NULLS ON command.
1
Options you can view (but not set) using the AR System Administration: Server Information form.
2
Options you cannot set or view using the AR System Administration: Server Information form.

Table B-1: ar.conf (ar.cfg) file options
Option Description
ar.conf (ar.cfg)
Submitter-Mode A setting indicating whether the Submitter field can be changed and
whether the submitter of a request must have a write license to modify it.
Valid values for this option are 1 (locked) and 2 (changeable). The default
value is 2.
In locked mode, the Submitter field cannot be changed after submission,
and, if the Submitter group has change permission, the request can be
modified by submitters with a read or write license, but not by users with
a restricted read license.
In changeable mode, the Submitter field can be changed after submit, but
the submitter must have a write license to modify the request (if the
Submitter group has change permission).
Suppress-warnings 2 A series of zero or more message numbers (separated by spaces) that
identify the informational or warning messages that the system should
suppress. Can be used to suppress server warnings and notes only.
Sybase-Character-Set 1 The alternate character set to use for communications between AR System
and the underlying database (applicable for Sybase databases only).
Sybase-Server-Name 1 The logical server name of the underlying database (applicable for Sybase
and MS SQL databases only). The default name is SYBASE.
System-Logging-Options 2 A bit mask that sets logging options for the operating system. Acceptable
values are as follows:
Bit 1 (Value=1) Suppress logging to the system log file.
A value of 0 indicates normal system logging and is the default.
TCD-Specific-Port The specific TCP port to use for the arserver process. The dispatcher is
randomly assigned to an available port if you do not specify this option.
Note that TCD stands for transaction control daemon.
Thread-Log-File The name of the file to use if thread tracing is turned on (see “Debugmode”
on page 260). This argument is expressed as the full path name.
Track-Admin-Op-Progress 2 Specifies whether the AR System server populates progress information (if
any) during any long-running administrative operation (such as a
definition import operation). The default value is F (do not track progress).
AR System clients can use GetServerInfo with
AR_SERVER_INFO_ADMIN_OP_PROGRESS as the request tag to retrieve the
progress information.
Two-Digit-Year-Cutoff 2 An integer that specifies the cutoff year for interpreting a two-digit year as
a four-digit year. For example, if the two-digit cutoff year is 2040, a twodigit
year would fall between 1941 and 2040. A date of 1/1/55 would be
interpreted as 1/1/1955 and a date of 1/1/30 would be interpreted as 1/
1/2030.
If a two-digit year cutoff is not specified, a rolling two-digit year is used.
Two-digit years would then be interpreted as the years between the
current year plus 29 years and the current year minus 70 years. For
example, if the current year is 2002, two-digit years would be interpreted
as years between 1922 and 2031.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
Appendix B AR System configuration files 285

BMC Remedy Action Request System 7.1.00
Table B-1: ar.conf (ar.cfg) file options
Option Description
Use-Password-File For Windows—A flag indicating whether the Windows domain service is
used to validate users not registered with AR System. If so, users in the
Windows domain are considered valid users of AR System and are
assigned to the Public group. Valid values are T and F. The default value is
F (do not use domain service). This is set in the Configuration tab of the AR
System Administration: Server Information form using the Authenticate
Unregistered Users check box.
For UNIX—A flag indicating whether the /etc/passwd file is used to
validate users not registered with AR System. If so, users in /etc/passwd
are considered valid users of AR System and are assigned to a group
identified by the UNIX group ID. Valid values for this option are T and F.
The default value is F (use password file).
Use-Server-Connect-Name-In-
Stats 2
Environment ARCONFIGDIR
286 Configuring
A flag indicating if the server name configured by the Server-Connect-
Name option (see page 282) should be used as the value for the Server
Name field when creating Server Statistics form entries.
The default behavior is to use the host name (or server alias if configured)
with the domain name appended. Setting the Use-Server-Connect-
Name-In-Stats option to T will use the Server-Connect-Name. If there is
no Server-Connect-Name configured, then the default behavior occurs.
The Use-Server-Connect-Name-In-Stats option allows the server to
enter a unique server name into the Server Statistics form when running in
a server group (when you want server-specific statistics). When a common
server alias is defined for all servers in a server group, the default behavior
is as follows: the same server name is used for all servers, effectively
combining the statistics for all servers in the group.
The default for this option is F (False).
User-Log-File The name of the file to use if user tracing is turned on (see “Debug-mode”
on page 260). This argument is expressed as the full path name.
XML-VUI-Export-Default-Is-
Localized 2
A flag indicating whether to export localized views when forms are
exported in XML definition format. Valid values for this option are T and
F. The default is F.
1 Options you can view (but not set) using the AR System Administration: Server Information form.
2 Options you cannot set or view using the AR System Administration: Server Information form.
UNIX only—Specifies the directory where the ar.conf file and other AR System
configuration files are stored. This directory defaults to /conf if
you do not set this variable.
Examples The following configuration file identifies two directory locations:
# Configuration file for AR System server
Server-directory: /usr/ar/db
Dbhome-directory: /usr/SQL-DB
The location of the data directory for this server is /usr/ar/db. The location of the
SQL database files is /usr/SQL-DB.

ardb.conf (ardb.cfg)
ardb.conf (ardb.cfg)
Description The ardb.conf (ardb.cfg) file contains SQL clauses that an administrator can
append to the SQL statements issued by AR System when a form, field, or index is
created or modified.
Create the ardb.conf file in your configuration directory, which is the conf
directory of the . On UNIX, the directory can be changed by
setting the ARCONFIGDIR environment variable.
When you create a form, field, or index, AR System references the ardb
configuration file for clauses to append to the SQL statement. If it finds no
matching information, AR System creates the form, field, or index as it would
normally. If it finds matching information, it appends the specified clause to the
SQL statement that creates the form, field, or index.
WARNING
AR System does not verify that the SQL clauses specified in your ardb
configuration file are correct or safe. AR System merely attaches the SQL clause to
the statement used when a form or index is created. Because you can append any
valid SQL clause (the entire clause must exist on one line in the file because no
new-line characters are allowed) to the CREATE statement for a form, field, or index,
use this feature wisely.
The format of this file is organized by forms.
1 Type a line for the name of the form and a line for the clause you want added to
the CREATE statement, as follows:
To create an ardb.conf file
Form:
Clause:
NOTE
When you use BMC Remedy Administrator to change the name of a form, the ardb
configuration file is edited automatically to match the new name.
2 Include field clause information below the applicable form information.
a Add a field line with an open brace.
Field {
Include a space between Field and the open brace.
b Add a line for the field ID.
Id:
c Add a line for the SQL clause.
Clause:
d Place the closing brace on its own line below the clause line.
Appendix B AR System configuration files 287

BMC Remedy Action Request System 7.1.00
288 Configuring
3 Include index clause information.
a Add an index line with an open brace.
Index {
Include a space between Index and the open brace.
b Add a line for the field IDs in the index.
Id:
If an index contains multiple fields, add several field ID lines before the clause
for that index.
c Add a line for the SQL clause.
Clause:
Clauses you specify for the tables of a form are not attached automatically to any
index you create for that form. You must specify the clause in the index clause.
For example, if you specify that a form is to reside in a specific part of your
database, and you want an index for that form to reside in the same space, you
must specify the clause for both the form and index.
d Place the closing brace in a line of its own below the clause line for the index.
The file looks something like this:
Form:
Clause:
Field {
Id:
Clause:
}
Index {
Id:
Id:
Clause:
}
Leading spaces in the ardb configuration file are ignored, so you might want to add
them to keep your file organized.
When you create or update the ardb.conf file, the changes do not take place
immediately—changes occur when the table (or index) is restructured.
Synopsis Windows—\Conf\ardb.cfg
Examples The following example shows ardb configuration file information for the HD-
Answer form on an Oracle database. The tables for the HD-Answer form will build
on segment two. The indexes include the Submitter (ID 2), Status (ID 7), and
Assigned To (ID 4) fields. The clauses for the indexes instruct the database to leave
70 percent of each index free for updates and insertions.

Form:HD-Answer
Clause:TABLESPACE seg2
Field {
Id:536870913
Clause: NOT FOR REPLICATION
}
Index {
Id:2
Id:7
Clause:PCTFREE 70
}
Index {
Id:4
Clause:PCTFREE 70
}
ardb.conf (ardb.cfg)
The following examples show how you can use the ardb.conf file to create indexes
using the Oracle UPPER function:
To specify that all indexes created for a form should be functional indexes using
Oracle’s UPPER function, use the following syntax:
Form:
Index {
Oracle-All-Upper-Index
}
To create a single functional index on a specific field using Oracle’s UPPER
function, use the following syntax:
Form:
Index{
Id:
Oracle-Upper-Index
}
To create a functional composite index using Oracle’s UPPER function, use the
following syntax:
Form:
Index {
Id:
Id:
Oracle-Upper-Index
}
Appendix B AR System configuration files 289

BMC Remedy Action Request System 7.1.00
armonitor.conf (armonitor.cfg)
Description The armonitor.conf (armonitor.cfg) file is read by the armonitor (armonitor.exe)
binary, which executes the commands listed in the configuration file.
Synopsis UNIX—/etc/arsystem//armonitor.conf
Windows—\Conf\armonitor.cfg
Options The format of this file consists of two types of entries. One type of entry is two
fields, separated by a space or tab:
290 Configuring
Table B-2: armonitor parameters
Each parameter represents a particular configuration option. The associated value
represents the current setting for that option. All numeric values are in a base 10
system. The available configuration options (and the valid settings for each) are
described in the following sections. Lines that do not begin with one of these
options are ignored.
The other type of entry is a command issued by armonitor to start various server
processes. Lines with a pound sign (#) in column 1 are treated as comments and
ignored.
The valid parameter entries are listed in the following table.
Option Description
Environment-variable Defines environment values established for armonitor. You can include
many instances of the Environment-variable option in the
armonitor.conf (armonitor.cfg) file. Before initiating any processes,
armonitor will set any values specified through this option in its
environment. Then, any processes that armonitor initiates will inherit
these values. This is a platform-independent way of defining environment
variables.
With this option, you can:
Overwrite the existing value of an environment variable with another
value:
Environment-variable: =
Prepend the existing value of an environment variable with a value:
Environment-variable: +=
Append a value to the existing value of an environment variable:
Environment-variable: =+
An example of the format is:
Environment-variable: ARDATEONLY=MM/dd/yyyy
Monitor-directory Defines the directory of the armonitor. Initially, the installer creates this
value, and the value is the same as the installation directory.
SNMP-Agent-Enabled This setting permits the armonitor to start the Remedy SNMP Agent and
to establish a link to it. Set to T to enable the Remedy SNMP Agent.

Appendix
C AR
System server
components and external
utilities
This section contains information about some AR System server executables and
three external utilities. Each item is listed by its UNIX ® name. If there is a Windows
equivalent, it is listed in parentheses after the UNIX name.
The following topics are provided:
AR System server components (page 292)
External utilities (page 296)
Appendix C AR System server components and external utilities 291

BMC Remedy Action Request System 7.1.00
AR System server components
arforkd (UNIX only)
Description The arforkd process reduces the amount of memory an AR System server uses
when forking new processes as a result of filters that run processes, set fields to
values returned from processes, or send email notifications. This small process
runs new processes on behalf of the server. The AR System server starts the
arforkd process and restarts the arforkd process if it dies.
292 Configuring
The ar.conf file contains configuration information for arforkd. For more
information about this file, see “ar.conf (ar.cfg)” on page 248.
armonitor (armonitor.exe)
Description The armonitor process starts and restarts the AR System server, AR System plugin
server, distributed server, and processes specified in the armonitor.conf (UNIX)
or armonitor.cfg (Windows) file. On Windows, it is typically started from the
Services panel. If you need to start armonitor manually, you must specify -m as a
command line argument.
If a process terminates, armonitor restarts the server. If the server dies more than
four times within 30 seconds, armonitor will give up restarting that server.
Synopsis UNIX—armonitor -c -s
Windows—armonitor -c -m
Options You can specify the following options on the command line:
-c
Causes the monitor to load information from the configuration file
armonitor.conf (armonitor.cfg).
-m
Windows only—Runs the process in manual mode, not as a Windows service.
If you run the process in a command window, you must use the -m option.
-s
UNIX only—Name of the server that you specify at the time of installation.
This can be used to identify a monitor process when multiple monitors are
running on the same host.

arplugin (arplugin.exe)
AR System server components
Description The arplugin process executes the C-based plug-in server, which implements and
deploys several server-side APIs. The armonitor process initiates arplugin.
Synopsis arplugin [-i ] [-m] [-s ]
Options You can specify the following options on the command line:
-i
-m
-s
Environment ARINSTALLDIR
Specifies the directory where the AR System server was installed.
Windows only—Runs the process in manual mode, not as a Windows service.
If you run the process in a command window, you must use the -m option.
Specifies the name of the server that contains the plug-in.
The directory where the AR System server was installed. The -i option takes
precedence over this environment variable.
UNIX—The default is /usr/ar.
Windows—The default is taken from the Windows Registry. If the install location
was not added to the Windows Registry when the AR System server was installed,
the default is C:\arservdb.
ARCONFIGDIR
The directory where the ar.conf (ar.cfg) configuration file is stored. The -i option
takes precedence over this environment variable.
The default is the conf subdirectory of the AR System server installation directory
(/usr/ar/conf on UNIX and C:\Program Files\AR System\Conf on Windows).
arserverd (arserver.exe)
Description The arserverd process (UNIX) or arserver.exe executable (Windows) represents
the main part of AR System. It handles all interactions between clients and the
database, making all access to the system dependent on this process.
Although this process can be started manually on both platforms, it is most often
started with armonitor. On the UNIX platform, arserverd can be started manually
by using the command /bin/arsystem Start. On Windows or
UNIX, if the process is shut down (whether accidentally or purposely), you can
restart it at any time.
Appendix C AR System server components and external utilities 293

BMC Remedy Action Request System 7.1.00
294 Configuring
In UNIX, sending a SIGUSR1 signal causes arserverd to reread all configuration
files. Sending a SIGHUP signal causes it to reread the configuration files and reset all
cached structure information. Generally, these signals are only sent after
performing a manual repair or restore operation. However, neither causes any
damage or adversely affects users currently accessing AR System.
Synopsis arserverd [-s ] [-i ]
[-l ] [-m]
Options You can specify the following options in any order on the command line:
-i
-m
-s
Environment ARCONFIGDIR
Specifies the directory where the AR System server was installed.
Windows only—Runs the process in manual mode, not as a Windows service.
If you run the process in a command window, you must use the -m option.
Name of the server you specified during the installation of AR System.
The directory where the ar.conf (ar.cfg) configuration file is stored. The default
is in the conf subdirectory of the AR System server installation directory
(/conf on UNIX and \conf on
Windows).
ARDATE
The date format used by the program.
UNIX only—This value consists of a string of operators as defined by the strftime
library call (some combinations appear successfully, but cannot be translated for
input). If you do not set this variable, the system uses the date format for the
language specified by the LANG environment variable.
Windows only—This value consists of a string of operators as defined by Regional
Settings. If you do not set this variable, the system uses the date format specified
in the Regional Settings of the user account that runs the service.
ARDATEONLY
The date format used by the program.
UNIX only—This value consists of a string of operators as defined by the strftime
library call. (Some combinations are displayed successfully but cannot be
translated for input.) If you do not set this variable, the system uses the date format
for the language specified by the LANG environment variable.
Windows only—This value consists of a string of operators as defined by Regional
Settings. If you do not set this variable, the system uses the date format specified
in the Regional Settings of the user account that runs the service.

ARTIMEONLY
Files UNIX
AR System server components
The time format used by the program.
UNIX only—This value consists of a string of operators as defined by the strftime
library call. (Some combinations are displayed successfully but cannot be
translated for input.) If you do not set this variable, the system uses the date format
for the language specified by the LANG environment variable.
Windows only—This value consists of a string of operators as defined by Regional
Settings. If you do not set this variable, the system uses the date format specified
in the Regional Settings of the user account that runs the service.
/conf/ar or $ARCONFIGDIR/ar
/conf/ar.conf or $ARCONFIGDIR/ar.conf
/etc/arsystem//arsystem.lic
/etc/services
Windows
Java plug-in server
Conf\ar.cfg
C:Program Files\Common Files\arsystem\licenses\\arsystem.lic
\drivers\etc\services
Description The Java plug-in server is an alternative to the C-based plug-in server. It supports
C plug-ins and Java plug-ins using a new Java plug-in API. The armonitor process
initiates the Java plug-in server.
Synopsis java -Xmx512m -classpath
com.bmc.arsys.pluginsvr.ARPluginServerMain -x -i
-m
Options You can specify the following options on the command line:
-x
-i
-m
The name of the host where the AR System server is running. Used by C plugins.
The directory where the AR System server was installed. Used by C plug-ins
to locate the ar.cfg or ar.conf file.
Windows only—Runs the process in manual mode, not as a Windows service.
If you run the process in a command window, you must use the -m option.
Files log4j_pluginsvr.xml
pluginsvr_config.xml
These configuration files must be in the class path. See the sample
log4j_pluginsvr.xmland pluginsvr_config.xml files for descriptions of the
configuration options.
Appendix C AR System server components and external utilities 295

BMC Remedy Action Request System 7.1.00
External utilities
arcache (arcache.exe)
Description The arcache utility executes the AR System interface that lets you update an entry
in the access control cache for a user or group, and lets you distribute your change
to the specified AR System servers. This program is generally used in a multiple
server environment with centralized access control. The program is also used for
error recovery in a single server environment.
Filters that execute on submit and modify to the User and Group forms are
typically used to run this program. Changes to those forms update the local cache
automatically. The filters make sure that all changes to user or group information
are distributed across the system.
If the server is running on a specific port and arcache cannot obtain the port
information from the portmapper, you must set the ARTCPPORT variable. For
example, if the port number is 2020, type the following command at a command
prompt:
296 Configuring
set ARTCPPORT=2020
At a UNIX prompt, type:
setenv ARTCPPORT 2020
Synopsis arcache {-U|-G}{a|d} -e [-g ] [-i ]
[-c ] [-q ]
[-t ] [-lw ] [-m ][-n ]
[-p ] [-s ] [-x ] [-d]
[-u ] [-r ]
Options You can specify the following options in any order on the command line:
-e
-g
-G
Specifies the Request ID associated with the user or group in the access
control cache (required). If you are adding a new user or group, you can
specify any value that does not already exist in the cache.
Specifies the set of groups to which the user belongs (applicable for adding or
updating users only). Group membership defines the permissions the user
has in the system. Use the group ID to identify each group (separated by
semicolons). Special group IDs are 1 (Administrator), 2 (Customize), and 5
(Subadministrator). For example, if the group ID for the Technical Support
group is 43, and you want to assign the user to the Customize and Technical
Support groups, specify this option as -g "2;43;".
Specifies the type of group cache operation. Valid values for this option are a
(add new or update existing group) and d (delete existing group). The -G and
-U options are mutually exclusive.

-i
-c
-q
-t
-lw
-m
-n
-p
-s
-U
-x
-d
External utilities
Specifies the group ID (applicable for adding or updating groups only).
Specifies the group category. Valid values for this option are 0 (regular
group), 1 (dynamic group), or 2 (computed group). The default value is 0.
Specifies the qualification for a computed group only. Specify this option as
"\ "A\ " OR 121 ", "121 OR ‘Demo’ ".
Specifies the group type (applicable for adding or updating groups only).
Valid values for this option are 0 (none), 1 (view only), or 2 (view/change).
The default value is 0.
Specifies the type of write license to assign (applicable for adding or updating
users only). Valid values for this option are 0 (read), 1 (fixed), or 2 (floating).
The default value is 0.
Specifies the default email address for sending messages (applicable for
adding or updating users only).
Specifies the name of the user or group (required for add operations,
recommended for delete operations).
Specifies the password to assign (applicable for adding or updating users
only).
Specifies the name of an individual AR System server to distribute your
change to. This option is required.
Specifies the type of user cache operation. Valid values for this option are a
(add new or update existing user) or d (delete existing user). The -U and -G
options are mutually exclusive.
Specifies the default alert mechanism to use (applicable for adding or
updating users only). Valid values for this option are 0 (none), 1 (notifier), or
2 (email). The default value is 1.
Runs the program in debug mode. Messages that detail the progress of each
operation being performed are printed to stdout. Use this mode to diagnose
problems with the arcache process only.
Appendix C AR System server components and external utilities 297

BMC Remedy Action Request System 7.1.00
298 Configuring
-u
-r
Environment ARCONFIGDIR
Specifies the user name of the authentication alias.
Specifies the authentication string of the authentication alias.
See “Setting up an authentication alias” on page 102 for more information
about authentication aliases.
UNIX only—Specifies the directory where the ar.conf file and other AR System
configuration files are stored. This directory defaults to /conf if
you do not set this variable.
Examples Add a new user, Sam Johnson, to the access control cache of all AR System servers.
Use 000000000000104 as the Request ID, samj@bmc.com as the default email address,
and notifier as the default alert mechanism. The syntax is as follows:
arcache -Ua -e000000000000104 -n "Sam Johnson"-m "samj@bmc.com" -x 1
No password or group membership is specified for this user.
Add an admin user with a fixed license. The syntax is as follows:
arcache -Ua -eTEMP999 -lw 1 -n "TEMPADMIN"-p"" -s bentley -g "1;"
To add a group ID, group type, and specify a computed group with a qualification,
the syntax is as follows:
arcache -Ga -e000000000000106 -n "TEMPADMIN" -i 8989 -t 2 -c 2 -q
"\ "Administrator\ " OR ‘Sunnyvale’ "
NOTE
You can disable arcache with a setting in the ar.conf (ar.cfg) file. When the setting
is active you can still run arcache, but it has no effect on the server, and the cache
does not get flushed. For more information, see “Disable-User-Cache-
Utilities” on page 265.
Files UNIX—$ARCONFIGDIR/ar
Windows—Uses a ServerList Registry value.

arreload (arreload.exe)
External utilities
Description The arreload utility executes the AR System interface that enables you to empty
the access control cache on one or more AR System servers and reload it from a
particular User or Group form.
If you experience problems with permissions or behaviors in the Group or User
form, the cache might need to be emptied and reloaded. Run arreload to reload the
cache.
This process must run on the AR System server where the source form is located
(the source machine). It deletes cached requests on the specified target machines
and reloads the cache from the form on the source machine, synchronizing the
cache with the available users and groups defined in the User and Group forms.
If the server is running on a specific port and arreload cannot obtain the port
information from portmapper, you must set the ARTCPPORT variable. For example,
if the port number is 2020, type the following command at a command prompt:
set ARTCPPORT=2020
At a UNIX prompt, type:
setenv ARTCPPORT 2020
Synopsis arreload -a {-u|-g} [-f]
[-p ] [-s ]
[-h ][-d]
Options You can specify the following options in any order on the command line. Specify
attributes within double quotes:
-a
Specifies a user with Administrator permission on the target servers
(required).
-f
Deletes all user or group requests from the cache on the specified target
machines before reloading from the source machine. The arreload utility
deletes requests submitted by the source machine only if you do not specify
this option. In multithreaded server environments where access control is
being managed remotely (using arcache), the existing cache requests might
have been submitted from different machines. Specifying this option causes
requests submitted from any server other than the source machine to be lost
from the cache of the target machines because all requests are deleted from the
cache, regardless of their source. Specifying this option has no effect if access
control is being managed locally (that is, the local machine is the only server
submitting requests to the cache), unless the server has been renamed or
moved to a different machine. In that case, this option is useful for clearing
out obsolete definitions that are no longer recognized as being related to the
local server, and would otherwise not be removed. This helps avoid
duplicate records that can corrupt the cache.
Appendix C AR System server components and external utilities 299

BMC Remedy Action Request System 7.1.00
300 Configuring
-g
-h
-p
-s
-u
-d
Environment ARCONFIGDIR
Specifies the name of the source form for reloading group requests (required
if you do not specify the -u option).
Specifies the name of the server if you have added a Server-Name value in the
ar configuration file. If you have a value for Server-Name, and you use
arreload without the -h option, arreload will use the default server name
rather than the name specified by Server-Name.
Specifies the password for the user specified by the -a option (required if a
password is defined for that user).
Specifies the name of an individual AR System server on which to reload the
cache. This option is required.
Specifies the name of the source form for reloading user requests (required if
you do not specify the -g option).
Runs the program in debug mode. Messages are printed to stdout and detail
the progress of each operation being performed. Use this mode to diagnose
problems with the arreload process only.
UNIX only—Specifies the directory where the ar.conf file and other AR System
configuration files are stored. If you do not set this variable, this directory defaults
to /conf.
Examples Connect as Admin (using the password fun4me) and delete all user requests from
the access control cache of all AR System servers. Reload the cache on all machines
from the User form on the current machine. An example follows, the attributes are
enclosed in double quotes:
arreload -u “User” -a “Admin” -p “fun4me” -f
Reload the cache on all machines from the Group form and the User form on the
current machine. An example follows, the attributes are enclosed in double quotes:
arreload -u “User” -g “Group” -a “Admin” -p “fun4me” -f -d
NOTE
You can disable arreload with a setting in the ar.conf (ar.cfg) file. When the
setting is active you can still run arreload, but it has no effect on the server, and
the cache does not get flushed.
Files UNIX—$ARCONFIGDIR/ar

arsignal (arsignal.exe)
External utilities
Description The arsignal utility forces an AR System server to load or reload information. The
process can be run on any machine.
Synopsis arsignal {-c|-g|-l|-a} [:port][sigArgument]
The server name identifies the server that is to reload information. If a TCP port is
to be specified as well (needed if the server does not register with AR System
Portmapper), it is appended to the server name, separated by a colon. The string
sigArgument is applicable when using the -a option.
Options You can specify one of the following options:
-a
-b
-c
-d
-e
-g
-l
-m
-p
-r
-u
Causes the server to update internal Alert user information using the details
provided in sigArgument. For more information, see “Using a Hardware Load
Balancer with BMC Remedy Action Request System.” This white paper is
available from the BMC Remedy Customer Support website at http://
www.bmc.com/support_home.
Causes the server to recache and reload archive definitions.
Causes the server to reload information from its configuration file ar.conf
(ar.cfg).
Causes the server to transfer the signal to a DSO process.
Causes the server to recache and reload escalation definitions.
Causes the server to reload group and data dictionary information from the
database.
Causes the server to reload license information.
Causes the server to reload computed group information.
Causes the server to transfer the signal to an application process.
Causes the server to recache definitions from the database.
Causes the server to reload user information.
Appendix C AR System server components and external utilities 301

BMC Remedy Action Request System 7.1.00
302 Configuring

Appendix
D Date
and time formats
The following topics are provided:
Short date formats (page 304)
Long date formats (page 305)
Day formats (page 306)
Time formats (page 306)
Additional characters (page 306)
Appendix D Date and time formats 303

BMC Remedy Action Request System 7.1.00
Short date formats
304 Configuring
The following table lists all the available Short Date Formats in the AR System User
Preference form.
Short Date Format Description Examples
MM/dd/yyyy Month, Day, Year (leading zero for single-digit months, leading zero
for single-digit days, four-digit year)
MM/dd/yy Month, Day, Year (leading zero for single-digit months, leading zero
for single-digit days, two-digit year)
MM/d/yyyy Month, Day, Year (leading zero for single-digit months, four-digit
year)
MM/d/yy Month, Day, Year (leading zero for single-digit months, two-digit
year)
01/01/2005
01/15/2005
01/01/05
01/15/05
01/1/2005
01/15/2005
01/1/05
01/15/05
M/dd/yyyy Month, Day, Year (leading zero for single-digit days, four-digit year) 1/01/2005
1/15/2005
M/dd/yy Month, Day, Year (leading zero for single-digit days, two-digit year) 1/01/05
1/15/05
M/d/yyyy Month, Day, Year (four-digit year) 1/1/2005
1/15/2005
M/d/yy Month, Day, Year (two-digit year) 1/1/05
1/15/05
dd/MM/yyyy Day, Month, Year (leading zero for single-digit days, leading zero for
single-digit months, four-digit year)
dd/MM/yy Day, Month, Year (leading zero for single-digit days, leading zero for
single-digit months, two-digit year)
01/01/2005
15/01/2005
01/01/05
15/01/05
dd/M/yyyy Day, Month, Year (leading zero for single-digit days, four-digit year) 01/1/2005
15/1/2005
dd/M/yy Day, Month, Year (leading zero for single-digit days, two-digit year) 01/1/05
15/1/05
d/MM/yyyy Day, Month, Year (leading zero for single-digit months, four-digit
year)
d/MM/yy Day, Month, Year (leading zero for single-digit months, two-digit
year)
1/01/2005
15/01/2005
1/01/05
15/01/05

Short Date Format Description Examples
Long date formats
Long date formats
d/M/yyyy Day, Month, Year (four-digit year) 1/1/2005
15/1/2005
d/M/yy Day, Month, Year (two-digit year) 1/1/05
15/1/05
yyyy/MM/dd Year, Month, Day (four-digit year, leading zero for single-digit
months, leading zero for single-digit days)
yyyy/MM/d Year, Month, Day (four-digit year, leading zero for single-digit
months)
2005/01/01
2005/01/15
2005/01/1
2005/01/15
yyyy/M/dd Year, Month, Day (four-digit year, leading zero for single-digit days) 2005/1/01
2005/1/15
yyyy/M/d Year, Month, Day (four-digit year) 2005/1/1
2005/1/15
yy/MM/dd Year, Month, Day (two-digit year, leading zero for single-digit months,
leading zero for single-digit days)
yy/MM/d Year, Month, Day (two-digit year, leading zero for single-digit
months)
05/01/01
05/01/15
05/01/1
05/01/15
yy/M/dd Year, Month, Day (two-digit year, leading zero for single-digit days) 05/1/01
05/1/15
yy/M/d Year, Month, Day (two-digit year) 05/1/1
05/1/15
The following table contains a complete list of the available Long Date Formats
that can be selected in the AR System User Preference form.
Format Example
dd MMMM, yyyy 01 January, 2005
dd MMMM, yy 01 January, 05
dd MMM, yyyy 01 Jan, 2005
dd MMM, yy 01 Jan, 05
d MMMM, yyyy 1 January, 2005
d MMMM, yy 1 January, 05
d MMM, yyyy 1 Jan, 2005
d MMM, yy 1 Jan, 05
MMMM dd, yyyy January 01, 2005
MMMM dd, yy January 01, 05
MMMM d, yyyy January 1, 2005
MMMM d, yy January 1, 05
MMM dd, yyyy Jan 01, 2005
MMM dd, yy Jan 01, 05
Appendix D Date and time formats 305

BMC Remedy Action Request System 7.1.00
Day formats
Time formats
306 Configuring
Format Example
MMM d, yyyy Jan 1, 2005
MMM d, yy Jan 1, 05
The following table lists the available era formats in AR System User Preference
form.
Day Format Description Examples
EEEE Long day format. The day is displayed in full. Friday, Thursday.
EEE Short Day format, three characters only. Fri, Thu.
The following table lists the available time formats available in the AR System User
Preference form.
Time Format Description Examples
h:mm:ss a Time in 12-hour format (no leading zero
for single digit hours)
1:23:45 AM, 10:23:45 PM
hh:mm:ss a Time in 12-hour format (leading zero for
single digit hours)
01:23:45 AM, 10:23:45 PM
H:mm:ss Time in 24-hour format (no leading zero
for single digit hours)
1:23:45, 22:23:45
HH:mm:ss Time in 24-hour format (leading zero for
single digit hours)
01:23:45, 22:23:45
Additional characters
If you need to include additional characters in your custom date or time display,
include them in single quotes.
Format Example
‘Date’ MM/dd/yy Date 01/01/05
‘Time’ hh:mm:ss a Time 01:23:45 AM

Appendix
E Working
with the Server
Events form
The Server Events form enables you to capture server-related activities and use
them in workflow and API programs. You can select the server events that you
want to record, search and view the returned entries, and create workflow to notify
companion servers and interested clients of server changes that could them.
The following topics are provided:
Understanding the Server Events form (page 308)
Using server events in workflow (page 323)
For information about setting Server Event options, see “Server information—
Server Events tab” on page 139.
Appendix E Working with the Server Events form 307

BMC Remedy Action Request System 7.1.00
Understanding the Server Events form
308 Configuring
1 The Server Events form captures the server changes that you record. You can
access this form from the AR System Administration Console in a browser or BMC
Remedy User; simply click System > General > Review Server Events.
The AR System Administration: Server Information form appears.
You use the Server Events form to notify other servers of cache changes if multiple
servers are sharing the same database, it can also notify interested clients of cache
changes and user or group events. For more information, see “Using server events
in workflow” on page 323.
NOTE
You might find server events especially helpful in a load-balanced environment.
However, with the server groups feature introduced in the 6.0 release, you will not
need to use server events as part of the mechanism for communicating between
servers in a load-balanced environment.
For AR System 5.1 servers, see the Using a Hardware Load Balancer with AR System
5.1 Servers whitepaper.
ForAR System 6.0 servers, see the Using a Hardware Load Balancer with AR System
6.0 Servers whitepaper.
The options on the Server Events tab of the AR System Administration: Server
Information form enable you to specify which activities you want to record to the
form. For more information about selecting Server Events options, see “Server
information—Server Events tab” on page 139.
The Server Events form is similar to other AR System forms. You can add
additional fields and workflow to it, but you cannot delete the five reserved fields,
which are discussed in the following section.
How the Server Events form is created
The Server Events form is created automatically by the server and contains five
reserved fields:
800 AR_RESERV_SVR_EVENT_TYPE
801 AR_RESERV_SVR_EVENT_CAUSE
802 AR_RESERV_SVR_EVENT_DETAILS_1
803 AR_RESERV_SVR_EVENT_DETAILS_2
804 AR_RESERV_SVR_EVENT_DETAILS_3
These five fields distinguish the Server Events form from all other forms. There can
be only one Server Events form in the AR System database; therefore, only one
form contains the five reserved fields specific to the Server Events form: 800, 801,
802, 803, 804.

Understanding the Server Events form
There are two primary instances in which a Server Events form can be created.
Case 1: When the server starts, the server will create the Server Events form
automatically if the form does not already exist in the AR System database. If
you delete the Server Events form, the server will automatically regenerate the
form the next time the server is started.
Case 2: If you create your own Server Events form, you will need to supply
default values with the correct data type for the required core fields. If the Server
Events form already exists and you try to create a form with the five reserved
fields, the server will return an error when you try to save the form. Error
checking will not allow the existence of more than one Server Events form.
The Server Events form can be viewed and modified using BMC Remedy
Administrator or driver. You can also rename the Server Events form. However, if
any of the five reserved fields are removed, the form will no longer be a valid
Server Events form.
Types of events you can record
Various types of server events can be recorded, including server object, user,
group, server-setting, and alert changes.
Server event types
The #define statements for the event types in ar.h are:
#define AR_SVR_EVENT_CHG_SCHEMA 1
#define AR_SVR_EVENT_CHG_FIELD 2
#define AR_SVR_EVENT_CHG_CHARMENU 3
#define AR_SVR_EVENT_CHG_FILTER 4
#define AR_SVR_EVENT_CHG_IMPORT 5
#define AR_SVR_EVENT_CHG_ACTLINK 6
#define AR_SVR_EVENT_CHG_ESCAL 7
#define AR_SVR_EVENT_CHG_VUI 8
#define AR_SVR_EVENT_CHG_CONTAINER 9
#define AR_SVR_EVENT_CHG_USERS 10
#define AR_SVR_EVENT_CHG_GROUPS 11
#define AR_SVR_EVENT_CHG_SVR_SETTINGS 12
#define AR_SVR_EVENT_CHG_ALERT_USERS 13
#define AR_SVR_EVENT_ARCHIVE_DONE 14
#define AR_SVR_EVENT_SERVGROUP_ACTION 15
These numbers are meaningful when you are viewing the events recorded in the
Server Events form. For more information, see “Viewing the server changes you
recorded” on page 311.
Appendix E Working with the Server Events form 309

BMC Remedy Action Request System 7.1.00
310 Configuring
Server object changes
Server object changes are changes to forms, filters, active links, escalations, fields,
VUIs, char menus, and containers. The AR System server will record the API calls
that caused the server object change. The AR System server will record the server
object change event type into the Event Type field and the RPC call number of the
API call in the Cause field. The information recorded in the Event Details field
depends on the server object. For example, when a form is modified, the form
name is recorded in the Event Details field. For a complete listing of what is
recorded in the Event Details field as well as the API calls that are recorded based
on corresponding event types and causes, see Table E-1 on page 312.
User/Group changes
When users or groups are added, modified, or deleted, an event is logged in the
Server Events form.
For user changes, the user change event type is logged in the Event Type field, the
event cause (user added, modified, or deleted) is logged in the Event Cause field,
and the entry ID and name of the user is recorded in the Event Details field.
For group changes, the group change event type is recorded in the Event Type
field, the event cause (group added, modified, or deleted) is recorded in the Event
Cause field, and the entry ID and name of the group is recorded in the Event
Details field.
For a complete list of user and group changes, see Table E-2 on page 314.
User and group changes are recorded in the following cases:
User added, modified, or deleted using the User or Group form
User or group changes using the arcache utility
User or group changes using the arreload utility
Server setting changes
All changes to server configurations are logged in the Server Events form. The
server settings change event will be recorded in the Event Type field. The numeric
value of the server option (AR_SERV_INFO_XX) will be recorded in the Event Cause
field. (For more information about the different AR_SERV_INFO_XX options, see the
C API Reference guide.) The datatype and value of the input argument to the
SetServerInfo call will be recorded in the Event Details field. For server options
that configure passwords, the password will be replaced by an arbitrary number
of asterisks for security purposes.
For a complete list of server setting changes, see Table E-3 on page 315.

Alert registration activity
Understanding the Server Events form
When Alert users are registered or deregistered, an event is logged in the Server
Events form.
For a complete list of alert setting changes, see “Viewing alert registration activity”
on page 320.
Archive activity
When an archive activity is performed, an event is logged in the Server Events
form.
For a complete list of archive changes, see “Viewing archive activity” on page 321.
Server group actions
When a server group action is performed (for example, a server in a server group
fails and another server takes over), an event is logged in the Server Events form.
For a complete list of server group changes, see “Viewing server group actions” on
page 322.
Viewing the server changes you recorded
When you open the Server Events form in BMC Remedy User to search or view the
entries that have been recorded, you will see numbers and raw data in the fields.
You will not see textual descriptions explaining the data returned for each of the
four reserved fields. For example, if you recorded the server events associated with
adding a new user, a search on the Server Events form will look similar to the
screen in Figure E-1.
Figure E-1: Adding a user
Appendix E Working with the Server Events form 311

BMC Remedy Action Request System 7.1.00
312 Configuring
Only the numeric values for Event Type and Event Cause are returned, and only a
brief description is provided in the Event Details field. Use the tables that follow
to look up the description that corresponds to the type number and cause number
of the server event for which you need information.
Viewing server object changes
For object changes, the event type can be 1 through 9, depending on the type of
object change being recorded. The following information appears in the fields on
the Server Events form when an object change is recorded:
Event Type: 1 to 9
Table E-1: Server object changes
Event Cause: RPC call number of the API call
Event Details 1: Contents depend on the server object being recorded
Event Details 2: Contents depend on the server object being recorded
Event Details 3: Contents depend on the server object being recorded
Request ID: The unique number assigned to identify the entry
Event Date: Time and date that the event occurred
Submitter: User who caused the server object event
In the Event Details 1 field, the object names recorded for the Set calls are the
names of the objects before the Set operation. Therefore, if an ARSetSchema call
renames the form from AA to BB, AA will be the form name recorded in the Event
Details field for the server event.
For “Set” API calls, if the name of the object is changed, the Event Details 2 field
will contain the old name of the object, and the Event Details 1 field will contain
the new name. If the name is not changed by the Set call, the Event Details 2 field
will contain a NULL datatype.
In the Event Details fields, semicolons separate multiple items. There are no spaces
after the semicolon, and the spaces after the semicolon in the table below were
added for display clarity. The string recorded in the Event Details fields can have
maximum lengths of 255 bytes (AR_MAX_SVR_EVENT_DETAILS), not including the
NULL. If the value to record in the Event Details fields exceed the maximum, the
value will be truncated.
NOTE
In the following table, Causes 0 and 1 refer to the import operation.
Type Cause Cause Description Event Details 1 Event Details 2 Event Details 3
1 0 or 8 ARSetSchema form name old form name
1 1 or 9 ARCreateSchema form name
1 10 ARDeleteSchema form name
2 0 or 13 ARSetField field ID; field name form name old field name

Table E-1: Server object changes
Viewing user changes
Understanding the Server Events form
Type Cause Cause Description Event Details 1 Event Details 2 Event Details 3
2 1 or 14 ARCreateField field ID; field name form name
2 43 ARDeleteField field ID; field name form name
2 56 ARDeleteMultiple field ID; field ID;…;
Fields
field ID
3 0 or 17 ARSetCharMenu menu name old menu name
3 1 or 18 ARCreateCharMenu menu name
3 19 ARDeleteCharMenu menu name
4 0 or 22 ARSetFilter filter name old filter name
4 1 or 23 ARCreateFilter filter name
4 24 ARDeleteFilter filter name
5 35 ARImport
6 0 or 39 ARSetActiveLink active link name old active link name
6 1 or 40 ARCreateActiveLink active link name
6 41 ARDeleteActiveLink active link name
7 0 or 49 ARSetEscalation escalation name old escalation name
7 1 or 50 ARCreateEscalation escalation name
7 51 ARDeleteEscalation escalation name
8 0 or 63 ARSetVUI vui ID; vui name form name old vui name
8 1 or 64 ARCreateVUI vui ID; vui name form name
8 65 ARDeleteVUI vui ID; vui name form name
9 0 or 75 ARSetContainer container name old container name
9 1 or 76 ARCreateContainer container name
9 77 ARDeleteContainer container name
For user changes, the event type will always be 10. The following information
appears in the fields on the Server Events form when a user change is recorded:
Event Type: 10
Event Cause: User added (0), modified (1), or deleted (2)
Event Details 1: Entry ID of the user and the user login name
Event Details 2: Unused
Event Details 3: Unused
Request ID: The unique number assigned to identify a particular request
Event Date: Time and date that the event occurred
Submitter: User who caused the user change event
Appendix E Working with the Server Events form 313

BMC Remedy Action Request System 7.1.00
314 Configuring
Viewing group changes
For group changes, the event type will always be 11. The following information
appears in the fields on the Server Events form when a group change is recorded:
Event Type: 11
Event Cause: Group added (0), modified(1), or deleted(2)
Event Details 1: Entry ID of the group and the group name
Event Details 2: Unused
Event Details 3: Unused
Request ID: The unique number assigned to identify a particular request
Event Date: Time and date that the event occurred
Submitter: User who caused the group change event
On the User form, the value in the Event Details 1 field for the user login name is
the value that is in reserved Field 101. For the Group form, the value for the group
name is the value that is in reserved Field 105.
When the user login name or group name is modified, the name recorded in the
Event Details 1 field is the name after it is modified. For example, if an ARSetEntry
is called to change the user’s login name from YY to ZZ, ZZ will be recorded as the
user’s login name in the Event Details 1 field.
In the Event Details fields, semicolons separate multiple items. There are no spaces
after the semicolon, and the spaces after the semicolon in the table below were
added for display clarity.
Table E-2: User and group changes
Type Cause Cause Description Event Details 1
10 0 User added entry ID; user login name
10 1 User modified entry ID; user login name
10 2 User deleted entry ID; user login name
11 0 Group added entry ID; group name
11 1 Group modified entry ID; group name
11 2 Group deleted entry ID; group name

Viewing server setting changes
Understanding the Server Events form
For server setting changes, the event type will always be 12. The following
information appears in the fields on the Server Events form when a server setting
change is recorded:
Event Type: 12
Event Cause: The numeric value of the server option AR_SVR_INFO_XX
Event Details 1: The input datatype and input value to the SetServerInfo call
(For more information, see “Datatypes values” on page 319.)
Event Details 2: Unused
Event Details 3: Unused
Request ID: The unique number assigned to identify a particular request
Event Date: Time and date that the event occurred
Submitter: User who called SetServerInfo
For the following server options, the input password will be replaced with an
arbitrary number of asterisks before storing it in the Event Details 1 field:
AR_SERVER_INFO_DB_PASSWORD,
AR_SERVER_INFO_DSO_USER_PASSWD,
AR_SERVER_INFO_DSO_TARGET_PASSWD,
AR_SERVER_INFO_APP_SERVICE_PASSWD,
AR_SERVER_INFO_MID_TIER_PASSWD,
AR_SERVER_INFO_PLUGIN_PASSWD,
AR_SERVER_INFO_PLUGIN_TARGET_PASSWD
The datatype is included in the Event Details 1 field because AR_DATA_TYPE_NULL
will not have a value, only the datatype.
In the Event Details fields, semicolons separate multiple items. There are no spaces
after the semicolon, and the spaces after the semicolon in the following table were
added for display clarity.
An AR Import API call can result in many server object changes, but this event will
be recorded as one server event. Therefore, even though one Import call can add
or modify several forms, filters, and active links, the server will record these
changes as an Import object change event, and the Cause field will contain the RPC
call number of ARImport.
Table E-3: Server setting changes
Type Cause Cause Description Event Details 1
12 5 AR_SERVER_INFO_ALLOW_GUESTS datatype; value
12 6 AR_SERVER_INFO_USE_ETC_PASSWD datatype; value
12 7 AR_SERVER_INFO_XREF_PASSWORDS datatype; value
12 8 AR_SERVER_INFO_DEBUG_MODE datatype; value
Appendix E Working with the Server Events form 315

BMC Remedy Action Request System 7.1.00
316 Configuring
Table E-3: Server setting changes
Type Cause Cause Description Event Details 1
12 10 AR_SERVER_INFO_DB_PASSWORD datatype; value
12 15 AR_SERVER_INFO_SET_PROC_TIME datatype; value
12 16 AR_SERVER_INFO_EMAIL_FROM datatype; value
12 17 AR_SERVER_INFO_SQL_LOG_FILE datatype; value
12 18 AR_SERVER_INFO_FLOAT_TIMEOUT datatype; value
12 20 AR_SERVER_INFO_UNQUAL_QUERIES datatype; value
12 21 AR_SERVER_INFO_FILTER_LOG_FILE datatype; value
12 22 AR_SERVER_INFO_USER_LOG_FILE datatype; value
12 28 AR_SERVER_INFO_MAX_ENTRIES datatype; value
12 31 AR_SERVER_INFO_ESCALATION_LOG_FILE datatype; value
12 33 AR_SERVER_INFO_SUBMITTER_MODE datatype; value
12 34 AR_SERVER_INFO_API_LOG_FILE datatype; value
12 37 AR_SERVER_INFO_FTEXT_TIMEOUT datatype; value
12 45 AR_SERVER_INFO_DS_RPC_SOCKET datatype; value
12 46 AR_SERVER_INFO_DS_LOG_FILE datatype; value
12 47 AR_SERVER_INFO_SUPPRESS_WARN datatype; value
12 50 AR_SERVER_INFO_SAVE_LOGIN datatype; value
12 57 AR_SERVER_INFO_CACHE_LOG_FILE datatype; value
12 59 AR_SERVER_INFO_THREAD_LOG_FILE datatype; value
12 65 AR_SERVER_INFO_TCD_TCP_PORT datatype; value
12 66 AR_SERVER_INFO_DSO_DEST_PORT datatype; value
12 78 AR_SERVER_INFO_NFY_TCP_PORT datatype; value
12 79 AR_SERVER_INFO_FILT_MAX_TOTAL datatype; value
12 80 AR_SERVER_INFO_FILT_MAX_STACK datatype; value
12 81 AR_SERVER_INFO_DEFAULT_ORDER_BY datatype; value
12 82 AR_SERVER_INFO_DELAYED_CACHE datatype; value
12 83 AR_SERVER_INFO_DSO_MERGE_STYLE datatype; value
12 84 AR_SERVER_INFO_EMAIL_LINE_LEN datatype; value
12 85 AR_SERVER_INFO_EMAIL_SYSTEM datatype; value
12 86 AR_SERVER_INFO_INFORMIX_RELAY_MOD datatype; value
12 87 AR_SERVER_INFO_PS_RPC_SOCKET datatype; value
12 88 AR_SERVER_INFO_REGISTER_PORTMAPPER datatype; value
12 89 AR_SERVER_INFO_SERVER_NAME datatype; value
12 90 AR_SERVER_INFO_DBCONF datatype; value
12 92 AR_SERVER_INFO_AP_RPC_SOCKET datatype; value
12 93 AR_SERVER_INFO_AP_LOG_FILE datatype; value
12 94 AR_SERVER_INFO_AP_DEFN_CHECK datatype; value
12 95 AR_SERVER_INFO_MAX_LOG_FILE_SIZE datatype; value

Table E-3: Server setting changes
Understanding the Server Events form
Type Cause Cause Description Event Details 1
12 96 AR_SERVER_INFO_CLUSTERED_INDEX datatype; value
12 97 AR_SERVER_INFO_ACTLINK_DIR datatype; value
12 98 AR_SERVER_INFO_ACTLINK_SHELL datatype; value
12 99 AR_SERVER_INFO_USER_CACHE_UTILS datatype; value
12 100 AR_SERVER_INFO_EMAIL_TIMEOUT datatype; value
12 102 AR_SERVER_INFO_ENCRYPT_AL_SQL datatype; value
12 103 AR_SERVER_INFO_SCC_ENABLED datatype; value
12 104 AR_SERVER_INFO_SCC_PROVIDER_NAME datatype; value
12 105 AR_SERVER_INFO_SCC_TARGET_DIR datatype; value
12 106 AR_SERVER_INFO_SCC_COMMENT_CHECKIN datatype; value
12 107 AR_SERVER_INFO_SCC_COMMENT_CHECKOUT datatype; value
12 108 AR_SERVER_INFO_SCC_INTEGRATION_MODE datatype; value
12 109 AR_SERVER_INFO_EA_RPC_SOCKET datatype; value
12 110 AR_SERVER_INFO_EA_RPC_TIMEOUT datatype; value
12 111 AR_SERVER_INFO_USER_INFO_LISTS datatype; value
12 112 AR_SERVER_INFO_USER_INST_TIMEOUT datatype; value
12 113 AR_SERVER_INFO_DEBUG_GROUPID datatype; value
12 115 AR_SERVER_INFO_EA_SYNC_TIMEOUT datatype; value
12 114 AR_SERVER_INFO_APPLICATION_AUDIT datatype; value
12 117 AR_SERVER_INFO_SVR_SEC_CACHE datatype; value
12 118 AR_SERVER_INFO_LOGFILE_APPEND datatype; value
12 119 AR_SERVER_INFO_MINIMUM_API_VER datatype; value
12 120 AR_SERVER_INFO_MAX_AUDIT_LOG_FILE_SIZE datatype; value
12 121 AR_SERVER_INFO_CANCEL_QUERY datatype; value
12 122 AR_SERVER_INFO_MULT_ASSIGN_GROUPS datatype; value
12 123 AR_SERVER_INFO_ARFORK_LOG_FILE datatype; value
12 124 AR_SERVER_INFO_DSO_PLACEHOLDER_MODE datatype; value
12 126 AR_SERVER_INFO_DSO_SOURCE_SERVER datatype; value
12 125 AR_SERVER_INFO_DSO_POLLING_INTERVAL datatype; value
12 128 AR_SERVER_INFO_DSO_TIMEOUT_NORMAL datatype; value
12 130 AR_SERVER_INFO_ENC_DATA_KEY_EXP datatype; value
12 131 AR_SERVER_INFO_ENC_PUB_KEY_EXP datatype; value
12 133 AR_SERVER_INFO_ENC_SEC_POLICY datatype; value
12 134 AR_SERVER_INFO_ENC_SESS_H_ENTRIES datatype; value
12 132 AR_SERVER_INFO_ENC_DATA_ENCR_ALG datatype; value
12 135 AR_SERVER_INFO_DSO_TARGET_CONNECTION datatype; value
12 137 AR_SERVER_INFO_ORACLE_QUERY_ON_CLOB datatype; value
12 140 AR_SERVER_INFO_LOCALIZED_SERVER datatype; value
Appendix E Working with the Server Events form 317

BMC Remedy Action Request System 7.1.00
318 Configuring
Table E-3: Server setting changes
Type Cause Cause Description Event Details 1
12 141 AR_SERVER_INFO_SVR_EVENT_LIST datatype; value
12 142 AR_SERVER_INFO_DISABLE_ADMIN_OPERATIONS datatype; value
12 143 AR_SERVER_INFO_DISABLE_ESCALATIONS datatype; value
12 144 AR_SERVER_INFO_ALERT_LOG_FILE datatype; value
12 145 AR_SERVER_INFO_DISABLE_ALERTS datatype; value
12 146 AR_SERVER_INFO_CHECK_ALERT_USERS datatype; value
12 147 AR_SERVER_INFO_ALERT_SEND_TIMEOUT datatype; value
12 148 AR_SERVER_INFO_ALERT_OUTBOUND_PORT datatype; value
12 151 AR_SERVER_INFO_DSO_USER_PASSWD datatype; value
12 152 AR_SERVER_INFO_DSO_TARGET_PASSWD datatype; value
12 153 AR_SERVER_INFO_APP_SERVICE_PASSWD datatype; value
12 154 AR_SERVER_INFO_MID_TIER_PASSWD datatype; value
12 155 AR_SERVER_INFO_PLUGIN_LOG_FILE datatype; value
12 156 AR_SERVER_INFO_SVR_STATS_REC_MODE datatype; value
12 157 AR_SERVER_INFO_SVR_STATS_REC_INTERVAL datatype; value
12 158 AR_SERVER_INFO_DEFAULT_WEB_PATH datatype; value
12 159 AR_SERVER_INFO_FILTER_API_RPC_TIMEOUT datatype; value
12 160 AR_SERVER_INFO_DISABLED_CLIENT datatype; value
12 161 AR_SERVER_INFO_PLUGIN_PASSWD datatype; value
12 162 AR_SERVER_INFO_PLUGIN_ALIAS datatype; value
12 163 AR_SERVER_INFO_PLUGIN_TARGET_PASSWD datatype; value
12 164 AR_SERVER_INFO_REM_WKFLW_PASSWD datatype; value
12 165 AR_SERVER_INFO_REM_WKFLW_TARGET_PASSWD datatype; value
12 166 AR_SERVER_INFO_EXPORT_SVR_OPS datatype; value
12 167 AR_SERVER_INFO_INIT_FORM datatype; value
12 168 AR_SERVER_INFO_ENC_PUB_KEY_ALG datatype; value
12 169 AR_SERVER_INFO_IP_NAMES datatype; value
12 170 AR_SERVER_INFO_DSO_CACHE_CHK_INTERVAL datatype; value
12 171 AR_SERVER_INFO_DSO_MARK_PENDING_RETRY datatype; value
12 172 AR_SERVER_INFO_DSO_RPCPROG_NUM datatype; value
12 173 AR_SERVER_INFO_DELAY_RECACHE_TIME datatype; value
12 174 AR_SERVER_INFO_DFLT_ALLOW_CURRENCIES datatype; value
12 175 AR_SERVER_INFO_CURRENCY_INTERVAL datatype; value
12 176 AR_SERVER_INFO_ORACLE_CURSOR_SHARE datatype; value
12 179 AR_SERVER_INFO_DFLT_FUNC_CURRENCIES datatype; value
12 180 AR_SERVER_INFO_EMAIL_IMPORT_FORM datatype; value
12 181 AR_SERVER_INFO_EMAIL_AIX_USE_OLD_EMAIL datatype; value
12 182 AR_SERVER_INFO_TWO_DIGIT_YEAR_CUTOFF datatype; value

Table E-3: Server setting changes
Datatypes values
Understanding the Server Events form
Type Cause Cause Description Event Details 1
12 183 AR_SERVER_INFO_ALLOW_BACKQUOTE_IN_PROCESS datatype; value
12 184 AR_SERVER_INFO_DB_CONNECTION_RETRIES datatype; value
12 189 AR_SERVER_INFO_HOMEPAGE_FORM datatype; value
12 190 AR_SERVER_INFO_DISABLE_FTS_INDEXER datatype; value
12 191 AR_SERVER_INFO_DISABLE_ARCHIVE datatype; value
12 192 AR_SERVER_INFO_SERVERGROUP_MEMBER datatype; value
12 193 AR_SERVER_INFO_SERVERGROUP_LOG_FILE datatype; value
12 194 AR_SERVER_INFO_FLUSH_LOG_LINES datatype; value
12 195 AR_SERVER_INFO_SERVERGROUP_INTERVAL datatype; value
12 196 AR_SERVER_INFO_JAVA_VM_OPTIONS datatype; value
12 197 AR_SERVER_INFO_PER_THREAD_LOGS datatype; value
12 199 AR_SERVER_INFO_SSTABLE_CHUNK_SIZE datatype; value
12 202 AR_SERVER_INFO_SERVERGROUP_NAME datatype; value
12 204 AR_SERVER_INFO_LOCKED_WKFLW_LOG_MODE datatype; value
The following are datatype values for the Server Events form. For example, for
server setting changes, the Event Details 1 field records the datatype and value.
The datatype is recorded as 0, 2, and 4, corresponding to the datatypes in the
following table.
Datatype Description #define in ar.h
0 NULL AR_DATA_TYPE_NULL
2 Integer AR_DATA_TYPE_INTEGER
4 Character String AR_DATA_TYPE_CHAR
Appendix E Working with the Server Events form 319

BMC Remedy Action Request System 7.1.00
320 Configuring
Viewing alert registration activity
For alert registration activity, the event type will always be 13. The following
information appears in the fields on the Server Events form when an alert change
is recorded:
Event Type: 13
Event Cause: User registered for alerts (102), user deregistered for alerts (103)
Event Details 1: User login name, IP address of machine user logs into, and
other details.
Event Details 2: Unused
Event Details 3: Unused
Request ID: The unique number assigned to identify a particular request
Event Date: Time and date that the event occurred
Submitter: User who caused the alert change event
In the Event Details fields, semicolons separate multiple items. There are no spaces
after the semicolon, and the spaces after the semicolon in the table below were
added for display clarity.
Table E-4: Alert registration activity
Type Cause Cause Description Event Details 1
13 102 User logs in to alert client Operation type tag (R); byte
length of user name; user name;
registration time; IP address of
client; client port; actual client IP
address; server IP address that
client expected; registration flag;
client version; client codeset
13 103 User logs out from alert client Operation type tag (U); byte
length of user name; user name; IP
address of client; client port; client
version

Table E-5: Archive activity
Viewing archive activity
Understanding the Server Events form
For archive activity, the event type will always be 14. The following information
appears in the fields on the Server Events form when an archive change is
recorded:
Event Type: 14
Event Cause: Copy to archive only (1), delete from source only (2), Copy to
archive and delete from source (3)
Event Details 1: Source form name
Event Details 2: Details of the activity
Event Details 3: Destination form name
Request ID: The unique number assigned to identify a particular request
Event Date: Time and date that the event occurred
Submitter: User who caused the archive change event
Type Cause Cause Description Event Details 1 Event Details 2 Event Details 3
14 1 Copy to archive only Source form name of
14 2 Delete from source
only
14 3 Copy to archive and
delete from source
Source form name of
Source form name of
Destination form
name
Destination form
name
Destination form
name
Appendix E Working with the Server Events form 321

BMC Remedy Action Request System 7.1.00
322 Configuring
Viewing server group actions
For server group actions, the event type will always be 15. The following
information appears in the fields on the Server Events form when a server group
activity is recorded:
Event Type: 15
Table E-6: Server group actions
Event Cause: Failover (1), relinquish (2), takeover (3)
Event Details 1: Server performing action
Event Details 2: Name of operation
Event Details 3: Other server
Request ID: The unique number assigned to identify a particular request
Event Date: Time and date that the event occurred
Submitter: User who caused the server group action event
Table E-6 describes specific details of server group actions.
Type Cause Cause Description Event Details 1 Event Details 2 Event Details 3
15 1 Server in group fails
over an operation
15 2 Server in group is
relinquishing an
operation
15 3 Server in group takes
over an unowned
operation.
Server that an
operation is failing
over to.
Server that is
relinquishing an
operation.
Server that is taking
over an unowned
operation.
Name of the
operation involved.
Name of the
operation involved.
Name of the
operation involved.
Server that an
operation is failing
over from.
Server that is
expected to take over
a relinquished
operation.
Null

Using server events in workflow
Using server events in workflow
Recording server events enables you to communicate internal (non-data) server
changes to processes outside the server and to use workflow to notify companion
servers or interested clients of changes that affect them.
You can create workflow that will be triggered when a server event is recorded.
For example, you might want to create a filter that fires when an entry is submitted
to the Server Events form indicating that an object change has occurred. The filter
should execute a Run Process action that runs the arsignal program to force a
companion AR System server to reload its cache. The filter should have one such
action for each companion server.
So, if you wanted to make server “foo” reload its cache, you would construct the
filter run process action as follows:
arsignal -g foo
If foo were running on specific port 2033, then the action would be constructed as
follows:
arsignal -g foo:2033
For more information about arsignal, see “arsignal (arsignal.exe)” on page 301.
Appendix E Working with the Server Events form 323

BMC Remedy Action Request System 7.1.00
324 Configuring

Appendix
F Using
Business Time in the
AR System server
Business time in AR System is the ability to define periods of availability and
unavailability, workdays, and holidays to calculate business schedules using
AR System commands.
The following topics are provided:
Overview (page 326)
Architecture (page 326)
How Business Time 2.0 works (page 328)
Scheduling a time segment (page 330)
Using offset hours in Business Time 2.0 (page 337)
Business Time commands (page 337)
Using the old Business Time forms (page 346)
Migrating Workdays and Holidays to the Business Time Segment form
(page 354)
Debugging tips for Business Time (page 355)
Appendix F Using Business Time in the AR System server 325

BMC Remedy Action Request System 7.1.00
Overview
Architecture
326 Configuring
AR System 7.0 introduced version 2.0 of Business Time. This version enables you
to define periods of time as available or unavailable. Business time can be defined
using time segments that can be workdays, holidays, or any other activity that
occurs in a business environment.
The AR System business time functionality is applicable to global enterprises with
multiple regional centers:
Businesses can use the availability function to block periods of time by region.
For example, a customer might want to make certain functions unavailable for
Japanese offices during Golden Week in Japan.
Businesses can use the Business Time function according to their own rules for
shift work during work days and during holidays. The customer can define the
different shifts (for example, the evening shift and the morning shift) and the
holidays to capture their work environment.
Different offices can set up different holiday and break schedules. A central
administrator can enter and manage business time and holidays for all
international locations in different time zones.
The Business Time Segment form is the main business time form and is used to
define segments of time. These time segments can then be used to define any kind
of activity.
If you used the Business Time Holidays and Business Time Workdays forms in
prior releases, you can still use them to define holidays and workdays with the old
set of Business Time commands. However, in Business Time 2.0, all activities
(including holidays and workdays) are defined in the Business Time Segment
form. A new set of commands work off the time segments defined in the Business
Time Segment form.
The “offset” that was previously available in the Business Time Workdays form is
now available in the Business Time Segment form. The functionality provided by
the old Business Time commands (Add, Subtract, and Diff) will also be provided
by the 2.0 Business Time commands; however, all future enhancements will happen
only to Business Time 2.0.
The Business Segment-Entity Association form associates an entity to one or more
time segments in the Business Time Segment form.

Following is a summary of forms you can use to define Business Time 2.0:
Architecture
Business Time Segment—Defines time segment as available or unavailable,
optionally on a one-time or a recurring basis.
Business Time Shared Entity—Stores detailed information about the entity
used in the Business Segment-Entity Association form. An entity is a generic
object such as an asset, categorization, or location.
Create an entity only if you need to associate a time segment to it. Once an entity
is created, it can be reused from there on. (You do not need to create a new one.)
Business Segment-Entity Association—Stores associations between entities
(such as assets, change requests, and groups, individuals, companies, and
locations) and activities that apply to those objects. It associates records in the
Business Time Segment and Business Time Shared Entity forms in a many-tomany
fashion.
Business Segment-Entity Association_Join—Used for query purposes. Acts as
a join form between the following forms:
Business Segment-Entity Association
Business Time Segment
Business Time Shared Entity-Entity Association_Join_Join—Used for query
purposes. Acts as a join form between the following forms:
Business Time Shared Entity
Business Segment-Entity Association_Join
These forms contain fields with IDs that AR System recognizes. You can change
the name of the forms, but do not make copies of them because the AR System
server will not be able to find the correct form for finding business schedules.
You can use the following forms with the old Business Time commands:
Business Time Workdays—Defines a weekly schedule with four time
segments.
Business Time Holidays—Defines holidays, which can be entire days or a time
segment within a day.
Figure F-1 shows the relationships between these forms.
Appendix F Using Business Time in the AR System server 327

BMC Remedy Action Request System 7.1.00
328 Configuring
Figure F-1: Forms used to schedule time in AR System
Business Time
Shared Entity-
Entity
Business Time
Shared Entity
form
Business Time 2.0
Business
Segment-Entity
Association
Scheduling
Business Time
Business Segment-
Entity
Association_Join
Business Time
Segment form
NOTE
If you upgrade your Business Time objects from version 5.0, delete the filter
BusWk:ValidateTimes02. This filter is not intended for use on AR System versions
5.1 and later.
How Business Time 2.0 works
Old Business Time forms
Scheduling Workdays
Business Time
Workdays form
Scheduling Holidays
Business Time
Holidays form
The Business Time Segment form represents a window of time, which can be
described as a one time activity (which can span multiple days) or a recurring
activity (which cannot span multiple days; it must be scheduled within a 24-hour
period).
An object in the Business Segment-Entity Association form can be associated with:
One or more entries in the Business Time Segment form
Optionally, one or more entries in the Business Time Shared Entity form
In Business Time 2.0, time segments are defined using “levels.” Levels 1 and 2 are
special levels. Level 1 time segments are treated as available time (workdays), and
Level 2 time segments are treated as unavailable time (holidays). If no Level 1 time
segments are defined, then all days are considered available.
If holidays are defined at Level 2, they can be overridden by time segments at Level
3 and above. If you do not want to override holidays, define them at a high level.
For more information, see “Understanding levels” on page 330.

How Business Time 2.0 works
To define business time and implement it in your AR System application, you
must:
Step 1 Define any combination of time segments, business hours, and business holidays.
If defining workdays, make sure available time segments are defined at Level 1. If
defining holidays, make sure unavailable time segments are defined at Level 2 or
higher. Define other time segments at Level 3 and above.
Step 2 Add business time commands to workflow in your application.
Step 3 Test the application.
Using the list of Time Segment IDs, Workday IDs, and Holiday IDs, the Business
Time component in AR System builds a list of available and unavailable time
windows for every day in the list of IDs.
For example, consider an entity that has a Workday schedule from 8:00 a.m. to 5:00
p.m., and two activities associated with it. The first time segment defines an
available time window at a Level 3 from 10:00 a.m. to 2:00 p.m., and the second
time segment defines an unavailable time window at Level 4 from 1:00 to 4:00 p.m.
The Business Time component in AR System computes the final time window list
for a day as shown in the following figure.
Figure F-2: Workday and activities for one day
Level
6
5
4
3
2
1
Time Seg. 2 (1 to 4 p.m.)
Time Seg. 1 (10 a.m. to 2 p.m.)
Workday (8 a.m. to 5 p.m.)
5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 Time
Final list
= Available time = Unavailable
The application commands described in “Business Time commands” on page 337
work from the final list.
Appendix F Using Business Time in the AR System server 329

BMC Remedy Action Request System 7.1.00
Scheduling a time segment
Understanding levels
330 Configuring
The Business Time Segment form stores availability, level, date and time ranges,
and recurrence information about a time segment. You can add an entry to this
form to schedule a business time segment for an entity in an AR System
application, such as an asset or a change request, or a group, individual, company,
or location.
Levels define a priority between different time segments, and a higher level time
segment takes precedence over lower-level time segments. Levels can be from 1 to
1000.
Levels 1 and 2 have special meaning. Level 1 time segments are “available” and
can be used to define workdays. Level 2 time segments are “unavailable” and can
be used to define holidays. Other time segments at Level 3 and above can be either
“available” or “unavailable.”
NOTE
Because higher levels of available segments can override Level 2 time segments, if
you do not want to override holidays, define holidays at a level higher than all
other levels.
For all Business Time commands, a higher-level time segment takes precedence
over lower-level time segments, except for the Application-Bus-Time2-Get-Free-
Window command. See “Application-Bus-Time2-Get-Free-Window” on page 342
for more information.
For time segments that are the same level, the order of overlapping activities is not
guaranteed. The business component in AR System will determine the final list for
these time segments in the order they are retrieved.
Creating non-conflicting segments
Levels are used to determine the order in which overlapping or non-overlapping
time segments will take effect. In Figure F-2 on page 329, Time Segment 2 is at a
higher level than Time Segment 1. Hence, in the final list, the time window 1:00
p.m. to 2:00 p.m. is defined as unavailable.
Defining a business time segment
You can create one-time time segment or a recurring time segment as described in
the following procedures:
“To define a one-time time segment” on page 331
“To define a recurring time segment” on page 334

1 Open the Business Time Segment form in new mode.
To define a one-time time segment
Figure F-3: Business Time Segment form, One Time tab
Scheduling a time segment
2 In the ID field, enter a unique identifier. Use this identifier to reference the time
segment in workflow.
The identifier can be non-unique in special cases. For more information, see
“Migrating Workdays and Holidays to the Business Time Segment form” on
page 354.
3 In the Description field, enter a description for the time segment.
4 In the Availability field, select Available or Unavailable.
5 For the Enable option, select Yes to enable the time segment.
Do not select Yes if you want to temporarily disable the time segment.
6 In the Level field, select a level.
Business Schedule Activities have a default level of 3, but this level can be changed
to a number from 1 through 1000.
If the schedules for two activities or business hours and holidays conflict, the event
with the highest number takes priority.
See “Creating non-conflicting segments” on page 330 for more information about
levels.
Appendix F Using Business Time in the AR System server 331

BMC Remedy Action Request System 7.1.00
332 Configuring
7 In the Category field, enter a description for the category.
This field helps determine what type of schedule time segment the item is (for
example, blackout, maintenance, and so on.) Although it is not a required field, it
can help you categorize your time segments.
8 In the Action field, select one of the following options:
NOTE
You must add items to the Non-Conflicting Activities field to find conflicting
items. If you do not, the time segment you originally entered will be used. See
step 14 on page 333 for more information.
Create as Described—Creates the scheduled time segment without checking to
determine if there is a conflict in the Start Date and Time, and End Date and
Time, with that of another scheduled time segment. This option creates a time
segment with a status of Published. It applies to both One Time and Recurring
duration types.
Create Next Free—Finds the next free date and time and automatically creates
the scheduled time segment, making sure that there is no other conflicting time
slot. If the specified Start Date and Time, and End Date and Time are not
available, the time segment is scheduled for the next available time slot. This
option creates a time segment with a status of Published. It applies only to the
One Time duration type.
Find Next Free—Finds the next free time slot based on the Start Date and Time
and the End Date and Time, and puts the value into the Next Free Date/Time
field. This option creates a time segment with a status of Draft. It applies only to
the One Time duration type.
NOTE
When this action is chosen, the AR System business time subsystem finds the next
free time and creates an entry in the Business Time Segment form. If this entry is
not needed, select Remove, and an escalation will delete it.
Publish—Changes the status from Draft to Published, so the time segment can
be used by business time application commands.
Remove—Mark the scheduled time segment to be deleted in an escalation that
runs nightly.
Draft—Changes the status from Published to Draft so changes can be made to
the time segment. (You cannot change a record after it is published. First, move
it to Draft and save it. Then, make your changes.)
As described in each of the previous bullets, when you select an Action, the status
of Draft, Published, or Remove appears in the read-only Status field. A status of
Draft indicates that the time segment can be modified, but not used by business
time application commands until the status changes to Published.

Scheduling a time segment
9 In the Duration Type field, select One time to create a single occurrence of the time
segment.
To create a recurring business time segment, see “To define a recurring time
segment” on page 334.
10 Enter the starting and ending dates and times for the duration of the time segment.
If your day ends at midnight, select the End of Day check box. Then, any value in
the End Time field will be ignored, and the day will end at midnight.
11 In the Earliest Start Time field, enter earliest preferred start time for which to
schedule the time segment.
The search for a start time will start with the Start Date and Start Time and find the
first available time with the specified duration. If no time slot is found within the
same day, it will continue to the next day, starting after the Earliest Start Time. If
this field is blank, the search for the next available time will continue from 12:00
a.m. of the next day if necessary.
12 In the Latest End Time field, enter latest preferred time by which the time segment
should end.
13 In the End Date Search Range field, enter the last date to search for an available
time slot within the specified Start Date and End Date. (The default is the End Date
plus six months.)
The Start Date Search Range field is set to the Start Date and Start Time.
14 In the Non Conflicting Activities field, enter the IDs of the Business Times
Workdays, Business Time Holidays, and Business Time Segment definitions to
check for schedule conflicts.
15 To find the next available time slot, click in the Next Free Date/Time field and
press ENTER.
This field is used only with the Find Next Free action.
The next free period for the time segment appears in the Next Free Date/Time
field. If the value is the same as the Start Date and Start Time, that time is available.
If the time is different, the original time that was specified for the Start Date/Time
was not available and the value represents the earliest available time.
16 If this time slot is not acceptable:
a Save the form.
b Select the Find Next Free option.
c Search for the next free time slot.
17 Save the form.
Appendix F Using Business Time in the AR System server 333

BMC Remedy Action Request System 7.1.00
334 Configuring
To define a recurring time segment
1 Complete steps 1 through 8 from “To define a one-time time segment” on
page 331.
2 Select the Recurring option for the Duration Type.
The Recurrence Definition tab appears on the form.
Figure F-4: Business Time Segment form—Recurrence Definition tab
3 Select start and end dates and times.
For recurring activities, the Start Date and End Date fields determine the range of
the recurrence, and the Start Time and End Time determine the duration of the
time segment.
If your day ends at midnight, select the End of Day check box. Then, any value in
the End Time field will be ignored, and the day will end at midnight.
4 Select the Recurrence Type, and specify the recurrence as dictated by the tab that
appears when you select the option. (All the options accept a start date and return
the next date.)
Specified dates—A semicolon separated list of dates, such as 12/24/05;12/25/
05.
Daily—Every specified number of days, such as every four days.

Scheduling a time segment
Weekly—Every specified number of weeks on a specified day, such as every
three weeks on Tuesday and Thursday.
Monthly
Specified day of every specified month, such as the 24th day every three
months.
Specified week day of a specified number of months, such as the second
Tuesday every three months. This could also be used to define quarterly
activities.
Yearly
Specified day of the month, such as every fifth day of April.
Every specified week day of a month, such as every second Tuesday of April.
5 Save the form.
Understanding time segment entity associations
The Business Segment-Entity Association form stores associations between the
Business Time Shared Entity form and the Business Time Segment form.
Figure F-5: Business Segment-Entity Association form
The Business Segment-Entity Associations form contains the following primary
fields:
Entry ID—An identifier for an entity to which the time segment is being
applied, such as an asset or a change request.
Entry Owner ID—An identifier for the parent object owner of the entity.
Enables you to see who was the original owner to determine if you have the
ability to make a change to the association.
Appendix F Using Business Time in the AR System server 335

BMC Remedy Action Request System 7.1.00
336 Configuring
Time Segment ID—A time segment name that was defined on the Business
Time Segment form. For more information, see “Scheduling a time segment” on
page 330.
Assignee Groups—Groups specified on Business Time Segment form. For more
information, see “Scheduling a time segment” on page 330.
Understanding time segment shared entities
The Business Time Shared Entity form stores logical references to a scheduled time
segment. An entity can define any generic object.
Only one entity of the same type can exist in this form. Once an entity is created,
you must reuse the existing copy in the entity from this form.
Figure F-6: Business Time Shared Entity form
The Business Segment-Entity Association form contains the following primary
fields:
Entry Type—Used to classify the type of entity that is being created. Depending
on this value, it determines how the values are mapped to the Attributes fields.
For example, if you have Entity Type as Category, then you can map Attribute1
to store Category 1, Attribute 2 to store Category 2, Attribute3 to store Category
3, and so on.
POID—Contains the Parent Object Instance ID field. It is used to reference any
desired generic object. Typically, it references the Instance ID of the parent
object.

Using offset hours in Business Time 2.0
Attribute fields—Includes a set of 10 generic attributes that can be used to
describe an entity. Any character values can be mapped into these fields to
describe an entity.
Using offset hours in Business Time 2.0
The Business Time Segment form includes an offset field, which is used under
certain circumstances to adjust for the time zone differences between the client and
the server. All Business Time 2.0 commands are executed on the server, and they
take in and return timestamp values.
Timestamp values are in GMT time; therefore, they are time zone sensitive. For
cases when the client and server are on different time zones, if the conversion of
the date and time to a timestamp happens on the client (such as with active links),
then the offset should be set to the time zone difference between the server and the
client. If the conversion happens on the server, then no offset is required.
For cases where the time segment spans across midnight (as specified in “Defining
business hours using offset hours” on page 351 for old Business Time commands),
do not use offsets.
Because “One Time” time segments can span multiple days, these time segments
can span midnight. “Recurring” time segments cannot span midnight; therefore,
you should create multiple time segments—one that goes to midnight one day,
and another that starts from midnight to the next day.
The first Level 1 offset will be considered and applied to all the time segments in
the application commands. Offsets on time segments at other levels are ignored.
Business Time commands
In addition to defining recurrence activities, business hours, and business
holidays, you must use commands to enable Business Time in your AR System
application. Business Time functionality is available within the Set Fields
workflow actions, and it uses the $PROCESS$ syntax to run an internal process
within the server to perform the calculation.
The command arguments are positional in the syntax used to run the processes.
You can omit trailing arguments. However, to set a later argument, you must
supply the arguments that come before the one you want to set. To pass a
parameter, simply enter "" in its place.
Appendix F Using Business Time in the AR System server 337

BMC Remedy Action Request System 7.1.00
Parameters
338 Configuring
You can create the following business time calculations:
Application commands
“Application-Bus-Time2-Add” on page 340
“Application-Bus-Time2-Diff” on page 341
“Application-Bus-Time2-Subtract” on page 341
“Application-Bus-Time2-Get-Next-Window” on page 341
“Application-Bus-Time2-Get-Free-Window” on page 342
Business Segment-Entity Association commands
“Application-Bus-Time2-Assoc-Add” on page 344
“Application-Bus-Time2-Assoc-Diff” on page 344
“Application-Bus-Time2-Assoc-Subtract” on page 344
“Application-Bus-Time2-Assoc-Get-Next-Window” on page 344
“Application-Bus-Time2-Assoc-Get-Free-Window” on page 345
“Application-Get-Next-Recurrence-Time” on page 345
Old Business Time commands
“Application-Bus-Time-Add” on page 352
“Application-Bus-Time-Diff” on page 353
“Application-Bus-Time-Subtract” on page 353
NOTE
Business Time commands work only with Date/Time fields (not Date fields or
Time fields).
The following list describes the parameters for the Business Time commands. Each
parameter must be set apart in double quotation marks.
BusinessTimeSegmentName—Identifier indicating which entry in the Business
Time Segment form contains a definition for the activity to use for this
calculation. You can specify multiple business activity names. Omitting this
value specifies that no business activity is used for this calculation.
Duration—Specifies the size of the time segment in seconds. Specify zero to
return the next time segment.

Business Time commands
EarliestStartTime—Working in conjunction with the LatestStartTime, specifies
the time range within which the free window should exist. (The Duration
parameter must be less than this range.) The specified duration must be less than
this range. For example, if the earliest time is 4:00 p.m. and the latest end time is
10:00 p.m., then a window is returned that is duration seconds long and starts
after 4:00 p.m., even if there is a window exists that is before 4:00 p.m. If the
duration is greater than the specified time range, no value is returned. If the
EarliestStartTime is not specified, the default of 0 hours (the beginning of the
day) is used.
EndTime—Ending time of the interval of which to calculate the difference.
EndTimeRange—A date and time value that defines the end of a search for a time
window.
Entity—Can be an asset, individual, group, company, location, or anything you
want to link a schedule to.
HolidayScheduleName—For old Business Time commands, an identifier indicating
which entry in the Business Time Holidays form contains a definition for the
holiday schedule to use for this calculation. Omitting this value specifies no
holidays.
LatestEndTime—Working in conjunction with the EarliestStartTime, specifies
the time range within which the free window should exist. (The Duration
parameter must be less than this range.) The specified duration must be less than
this range. For example, if the earliest time is 4:00 p.m. and the latest end time is
10:00 p.m., then a window is returned that is duration seconds long and starts
after 4:00 p.m., even if there is a window exists that is before 4:00 p.m. If the
duration is greater than the specified time range, no value is returned. If the
LatestEndTime is not specified, the default of 24 hours (midnight) is used.
Level—An integer value indicating the level of the time segment to be
scheduled. The value can be an integer from 1 through 1000.
Amount—An integer value of 0 or greater that specifies an amount of time to
offset the start time by. If not specified, Amount defaults to 1. 0 can be used to
indicate the next available time. For example, if your open hours are 8:00 a.m. to
5:00 p.m. and the Start Time in Application-Bus-Time2-Add, Application-Bus-
Time2-Assoc-Add, and Application-Bus-Time-Add commands is 7:00 a.m., the
return value is 8:00 a.m.
In previous versions, Amount was known as Offset.
Amount_Units—Unit of time. It can be set to 1 for seconds, 2 for minutes, 3 for
hours, or 4 for days. Any other setting will revert to hours (3).
StartTime—Starting time to which to add business time.
StartTimeRange—A date and time value that defines the start of a search for a
time window.
Appendix F Using Business Time in the AR System server 339

BMC Remedy Action Request System 7.1.00
Application commands
340 Configuring
WindowFlag—A bitmask value with:
Bit 0—Indicates the beginning of an available or unavailable time segment. It
takes a value of 0 for an unavailable segment, and 1 for an available segment.
Bit 1—Indicates whether to retrieve all or just one segment. If the value is 0, it
retrieves one segment. If the value is 1, it retrieves all of the segments between
the start and end times. The value returned in this case is a semicolon
separated list of values.
WorkdayScheduleName—For old Business Time commands, an identifier indicating
which entry in the Business Time Workdays form contains a definition for the
work schedule to use for this calculation. Omitting this value specifies open 7
days a week, 24 hours a day.
Application-Bus-Time2-Add
The Application-Bus-Time2-Add command performs a business time calculation
by starting with the start time and resulting in a new time that adds the requested
offset. The command returns a timestamp representing the time calculated. Use
this command to recalculate time into the future.
Use the following syntax for the Application-Bus-Time2-Add calculation:
Application-Bus-Time2-Add “” [“” [“”
[“” “” . . . ]]]
The StartTime parameter is required in this command. This parameter must be a
value such as a field reference ($$). Other fields are optional and use
the default value if not provided. You can specify multiple business activity
names.
For example, add one day by using the following calculation:
$PROCESS$ Application-Bus-Time2-Add “$$” “”
“”
This adds one day to the value that currently resides in Field Name. Show
Field Name as StartTime. Set the offset unit to 4, representing days, and set the
offset to 1, thus adding one day into the calculation. The final syntax looks like:
$PROCESS$ Application-Bus-Time2-Add “$8/26/2004$” “1” “4”

Application-Bus-Time2-Diff
Business Time commands
The Application-Bus-Time2-Diff command performs a business time calculation
by computing the difference between the start time and the end time. The return is
an integer representing the difference in seconds. Use this command to compare
two different times (start time and end time) to get the actual business time.
Use the following syntax for the Application-Bus-Time2-Diff calculation:
Application-Bus-Time2-Diff “” “”
[“” “” . . . ]]
The StartTime and EndTime parameters are required in this command. Other fields
are optional and will default if not provided. You can specify multiple business
activity names.
Application-Bus-Time2-Subtract
The Application-Bus-Time2-Subtract performs a business time calculation by
starting with the start time and resulting in a new time that subtracts the requested
offset. The command returns a timestamp representing the time calculated. Use
this command to recalculate time in the past.
Use the following syntax for the Application-Bus-Time2-Subtract calculation:
Application-Bus-Time2-Subtract “” [“”
[“” [“”
“” . . . ]]]
The StartTime parameter is required in this command. Other fields are optional
and will use the default value if not provided. You can specify multiple business
activity names.
Application-Bus-Time2-Get-Next-Window
The Application-Bus-Time2-Get-Next-Window command returns the start of the
next available or unavailable time segment that is seconds long. If
is 0 (the default), the command returns either the start of available time
segment or the start of unavailable the time segment.
Additionally, depending on the , the command will return one time
segment or all the time segments between and .
Use the following syntax for the Application-Bus-Time2-Get-Next-Window
calculation:
Application-Bus-Time2-Get-Next-Window “”
“” [“”] [“”]
[“” “” . . . ]
Appendix F Using Business Time in the AR System server 341

BMC Remedy Action Request System 7.1.00
342 Configuring
Application-Bus-Time2-Get-Free-Window
The Application-Bus-Time2-Get-Free-Window command returns the start of the
next available or unavailable free time segment at the same level or a higher level that
is seconds long. A free time segment at Level and Duration
is one where no other time segment at the same or higher level as
overlaps, or starts or ends in the of this time segment. After a
free time segment is obtained, it can be created as available or unavailable. The
default value for duration is 0. If is 0, it returns the next available time
segment.
Use the following syntax for the Application-Bus-Time2-Get-Free-Window
calculation:
Application-Bus-Time2-Get-Free-Window “”
“” [“”] [“”] [“”]
[“”] [“”
“” . . . ]
The command works by considering all Business Time Segments at a certain level
or above and treats them as unavailable, regardless of whether they are available or
unavailable. If Level 1 and 2 time segments are present, then they are always
considered and are taken as available and unavailable, respectively.
Example 1
Application-Bus-Time2-Get-Window "7/12/05 11:00:00 AM" "7/15/05 3:00:00
PM" 2 3600 "" "" "" "Work1" "Act1" "Act2" "Act3"
Consider an entity that has the following conditions:
Work1 has the following Workday schedule:
Available: Wednesday through Friday, 8:00 a.m. to 5:00 p.m.
Unavailable: Wednesday through Friday, 12:00 a.m. to 8:00 a.m. and 5:00
p.m. to Midnight
Unavailable: Saturday through Tuesday, whole days
Act1 defines an available time window at a Level 3 from 10:00 a.m. to 2:00 p.m.
on 7/13/05.
Act2 defines an unavailable time window at Level 3 from 7:00 a.m. to 9:00 a.m. on
7/13/05.
Act3 defines an unavailable time window at Level 6 from 1:00 p.m. to 4 p.m. on
7/13/05.
A free window of duration 3600 seconds (1 hour) is required. There is no Earliest
Start Time or Latest End Time.
Figure F-7 shows the return value for Get-Free-Window for a specific day. The two
Final lists show the final time window that Get-Free-Window will use in case a free
window is required at Level 2 or at Level 4.
For Level 2, the free window is available from 9:00 a.m. to 10:00 a.m. and from 3:00
p.m. to 4:00 p.m. Get-Free-Window will return 1121270400 (July 13, 2005, 9:00 a.m.).

Business Time commands
For Level 4, the free window is available from 8:00 a.m. to 12:00 p.m. and from 3:00
p.m. to 4:00 p.m. Get-Free-Window will return 112166800 (July 13, 2005, 8:00 a.m.).
Figure F-7: Application-Bus-Time2-Get-Free-Window command example
Level
6
5
4
3
2
1
Level 2
Level 4
Example 2
Application-Bus-Time2-Get-Free-Window "7/12/05 11:00:00 AM" "7/15/05
3:00:00 PM" 2 3600 "11:00:00 AM" "" "" "Work1" "Act1" "Act2" "Act3"
In the example, if the Earliest Start Time for Level 2 was 11:00 a.m., then the return
value at Level 2 will be 1121292000 (July 13, 2005, 3:00 p.m.).
Example 3
Application-Bus-Time2-Get-Free-Window "7/12/05 11:00:00 AM" "7/15/05
3:00:00 PM" 2 3600 "5:00:00 AM" "2:00:00 PM" "" "Work1" "Act1" "Act2" "Act3"
If the Earliest Start Time was 5:00 a.m. (or if it is not specified), and if the Latest End
Time was 2:00 p.m., then the return value at Level 2 will be 1121270400 (July 13,
2005, 9:00 a.m.).
Example 4
Time Seg. 2 (7 to 9 a.m.)
Final list
Workday (8 a.m. to 5 p.m.)
Final list
Time Seg. 3 (1 to 4 p.m.)
Time Seg. 1 (10 a.m. to 2 p.m.)
5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 Time
= Available time = Unavailable
Application-Bus-Time2-Get-Free-Window "7/12/05 11:00:00 AM" "7/15/05
3:00:00 PM" 2 7200 "" "" "" "Work1" "Act1" "Act2" "Act3"
If the duration required was 2 hours, then for Level 2, "" is returned.
Example 5
Application-Bus-Time2-Get-Free-Window "7/12/05 11:00:00 AM" "7/15/05
3:00:00 PM" 4 7200 "" "" "" "Work1" "Act1" "Act2" "Act3"
If the Level is 4 and the duration is 7200 seconds, then 1121266800 (July 13, 2005,
8:00 a.m.) is returned.
Appendix F Using Business Time in the AR System server 343

BMC Remedy Action Request System 7.1.00
Business Segment-Entity Association commands
344 Configuring
If the Business Segment-Entity Association form contains entries for time
segments, you can use the following commands in place of the Application
commands described in the previous section.
The following commands contain EntityID parameters, so that you do not need to
query the Business Segment-Entity Association form and call the previous
Application commands.
Application-Bus-Time2-Assoc-Add
Use the following syntax for the Application-Bus-Time2-Assoc-Add calculation:
Application-Bus-Time2-Assoc-Add “” [“”
[“” [“”
“” . . . [-e "EntityID1" "EntityID2"… ]]]]
Application-Bus-Time2-Assoc-Diff
Use the following syntax for the Application-Bus-Time2-Assoc-Diff calculation:
Application-Bus-Time2-Assoc-Diff “” “”
[“” “” . . . [-e
"EntityID1" "EntityID2"… ]]
Application-Bus-Time2-Assoc-Subtract
Use the following syntax for the Application-Bus-Time2-Assoc-Subtract
calculation:
Application-Bus-Time2-Assoc-Subtract “” [“”
[“” [“”
“” . . . [-e "EntityID1" "EntityID2"… ]]]]
Application-Bus-Time2-Assoc-Get-Next-Window
Use the following syntax for the Application-Bus-Time2-Assoc-Get-Next-Window
calculation:
Application-Bus-Time2-Assoc-Get-Next-Window “”
“” “”“”
[“” “” . . . [-e
"EntityID1" "EntityID2" . . . ]]

Application-Bus-Time2-Assoc-Get-Free-Window
Business Time commands
Use the following syntax for the Application-Bus-Time2-Assoc-Get-Free-Window
calculation:
Application-Bus-Time2-Assoc--Get-Free-Window “”
“” “” “”“”
“” [“”
“” . . . [-e "EntityID1" "EntityID2" . . . ]]
Application-Get-Next-Recurrence-Time
Recurrence is defined by a set of fields in the range from 2300 to 2341 and contains
recurrence patterns. These fields can be defined on any form, and the Application-
Get-Next-Recurrence-Time command is provided to get the next time. For all the
recurrence time calculations, ICU library functions are used.
The Application-Get-Next-Recurrence-Time command performs a recurrence
time calculation by starting with the start time and finding recurrence times based
on the specified recurrence definition name. The return value is a semicolonseparated
list of dates (in seconds).
The command syntax is as follows:
Application-Get-Next-Recurrence-Time
The options for these recurrence time calculations are as follows:
—Form that contains the recurrence fields, such as the Business Time
Segment form.
—Starting time to which to add business time.
—Identifier indicating which entry in the Business
Time Segment form contains a definition for the recurrence schedule to use for
this calculation.
Following is an example of the command with $PROCESS$:
$PROCESS$ Application-Get-Next-Recurrence-Time "Business Time Segment"
"4/14/04 10:30:00 AM" "weekly"
weekly is an entry in the form that contains the recurrence fields, such as the
Business Time Segment form. The weekly entry is defined as Wednesday and
Friday, every 3 weeks.
The return value is 8456890, which corresponds to 4/16/04 10:30:00 AM. Calling
Application-Get-Next-Recurrence-Time again returns 8345345;834999,
corresponding to 4/21/04 10:30:00 AM and 4/23/04 10:30:00 AM.
Appendix F Using Business Time in the AR System server 345

BMC Remedy Action Request System 7.1.00
346 Configuring
NOTE
Recurrence information for scheduled activities is stored in the Business Time
Segment form, which contains a set of fields with field IDs in the range of 2300 to
2341 that contain recurrence patterns. The Application-Get-Next-Recurrence-
Time application command is used with this form to get the next available time.
You can optionally create a custom form with field IDs in the range of 2300 to 2341
to contain recurrence patterns, and specify that custom form in the Application-
Get-Next-Recurrence-Time application command.
Using the old Business Time forms
Scheduling workdays
The Business Time Workdays form stores the day-to-day availability of each of
your groups and individuals, and a record of your company or location’s business
hours.
Business time in AR System is calculated on the AR System server where the start
and end times on any given day must be in the range of 0–24 hours. Any business
time outside this range is considered invalid.
To define business hours
1 Open the Business Time Workdays form.
The General tab appears. Here you can specify a unique identifier for a workday
definition and the list of open and close times for workdays you are defining.
Figure F-8: Business Time Workdays form

Using the old Business Time forms
2 In the Name field, enter a unique identifier. Use this identifier to reference this
schedule in all business hours calculations.
3 In the Submitter field, enter the name of the user who submitted the first version
of this schedule.
4 Use the Change History field to track structural or administrative changes to the
definition.
5 In the Help Text field, enter the purpose of the schedule.
6 (Optional) In the Offset Hours field, enter the number of hours you want to offset
from the time on the server.
Use the Offset Hours field to adjust a client business time to a server business time.
An example of a special case is a valid business time on the client that is several
time zones away from the server. The time on the client becomes invalid on the
server if it crosses midnight after the time zone adjustment.
For more information, see “Using offset hours in Business Time 2.0” on page 337.
7 Click the Time Schedules tab.
Figure F-9: Business Time Workdays form, Time Schedules tab
8 Enter the appropriate hours in the time blocks.
AR System allows up to four individual time segments to be defined in the Time
Schedules tab. You can enter up to four multiple non-overlapping time blocks for
hours of operation in a single 24-hour period.
Appendix F Using Business Time in the AR System server 347

BMC Remedy Action Request System 7.1.00
348 Configuring
You can span midnight by showing the day as split between two days (for
example, a shift spanning Tuesday and Wednesday). For example, End 4 on
Tuesday has a time of 11:59:59 p.m., and Start 1 on Wednesday has a time of
12:00:00 a.m.
Time segments must be ascending, non-overlapping within a day. Figure F-9
shows an End time one second before the Start of the next time segment. (If Offset
Hours is used, the time segments must be non-overlapping before the offset hours
are applied.)
NOTE
Create separate schedules for Daylight Savings Time as needed based on locale
and conventions for that locale.
9 Save the form.
Scheduling holidays
Business hours with a one-hour gap
This scenario occurs when a one-hour lunch break is scheduled in the work day.
Use the Time Schedule Start and End times to specify that the business is open
from 9:00:00 a.m. to 12:00:00 p.m. and from 1:00:00 p.m. until 5:00:00 p.m.,
indicating a one-hour closed time. Enter the information as shown in Figure F-10.
Figure F-10: Business hours with one hour gap
Use the Business Time Holidays form to define all scheduled holidays and other
non-working days. A holiday can be either a full day or a few hours. Keep in mind
that, due to shift work, holidays might span over midnight.
To set holiday times
1 Open the Business Time Holidays form.
2 Click the Holiday Definition tab.

Figure F-11: Business Time Holidays form
Using the old Business Time forms
3 In the Schedule Name field, enter the unique identifier for this holiday schedule.
Use this identifier to reference this schedule in all business hours calculations.
IMPORTANT
Enter the same name that you entered in the Name field of the Business Time
Workdays.
4 In the Holidays field, list the holidays that make up the holiday schedule.
Enter holiday time as ,,. For example,
07/4/04,9:00:00 a.m.,5:00:00 p.m. is a holiday that starts at 9:00:00 a.m. on
7/4/04 and ends at 5:00:00 p.m. on the same day.
Separate the dates by pressing Enter or by inserting semicolons between the dates.
There is no limit to the number of dates that can be specified in this list.
The holiday entry cannot span across midnight, and the Start time must be less
than End time. Holiday time uses the offset hours from the Workday schedule.
Only short date/time format is currently supported in the Business Time Holidays
form. Long date formats (such as January 1, 2005) are not currently supported.
The dates are interpreted on the server and follow the server formatting rules. If
clients are configured for other date formats and the dates entered in the Business
Time Holidays form are entered in a client format that is incompatible with the
server format, they will not be correctly interpreted as holidays, or they might be
interpreted as a different day than was planned.
NOTE
The ARDATE format is not currently supported in Business Time Holidays form.
5 Click the Administrative Information tab.
The Holiday ID field contains the AR System ID for this schedule. The Change
History field is used to track structural or administrative changes to the schedule.
Appendix F Using Business Time in the AR System server 349

BMC Remedy Action Request System 7.1.00
350 Configuring
6 In the Help Text field, enter the purpose of the schedule.
7 Save the form.
Tips for entering dates and times
The following sections offer tips to help you properly enter dates and times into
the Business Time Holidays form.
Entering dates for an international server
When the server resides internationally, it recognizes the short date format of the
server. For example, the German Business Time Holiday value would be entered
dd.mm.yy, which matches the date convention of the locale.
No start time
To indicate a holiday without listing a start time, use the following format:
date,,end time
For example:
7/4/04,,5:00:00 p.m.
In this case, the start time defaults to 12:00:00 a.m.
No end time
To indicate a holiday without listing an end time use the following format:
date, start time
For example:
7/26/04, 2:00:00 p.m.
In this case, the end time defaults to 12:59:59 p.m.
No start time and no end time
To indicate a holiday that lasts the entire 24-hour day, use the following format:
date
For example:
7/26/04
In this case, the start time defaults to 12:00:00 a.m. and end time defaults to 12:59:59
p.m.
Adjusting the time across midnight
The implementation of business time calculations requires that Start Time be
earlier than End Time. However, when a holiday schedule crosses midnight, such
as when Start Time is 10:00:00 p.m. and End Time is 6:00:00 a.m., you must adjust
the holiday schedule:
To adjust using Holidays time, enter the start time as one day and enter the end
time on the next day. It would look like:
12/25/04,10:00:00 p.m.,11:59:59PM;12/26/04,12:00:00 a.m.,6:00:00
a.m.

Or:
12/25/04,10:00:00 p.m.,11:59:59 p.m.
12/26/04,12:00:00 a.m.,6:00:00 a.m.
Using the old Business Time forms
To adjust using Offset Hours, take your original Start/End time, minus the
value from Offset Hours in the Business Time Workdays form to get the
adjusted time. You can use either a positive offset, which moves the times
earlier, or a negative offset, which moves the times later. The offset does not
have to be unique. You can choose any value as long as the adjusted times fall
into the 0- to 24-hour range. For example, if a holiday starts at 10:00:00 p.m. on
12/25/04 and ends at 6:00:00 a.m. on 12/26/04, you can supply an offset of
three hours to adjust the holiday time to start on
12/26/04 at 1:00:00 a.m. and end at 9:00:00 a.m. This adjusted time is entered
into the Holidays field following the format:
12/26/04,1:00:00 a.m.,9:00:00 a.m.
NOTE
The offset hours is specified in Business Time Workdays as part of a workday
schedule.
Defining business hours using offset hours
The Business Time Workdays form includes an Offset Hours field that allows you
to calculate business hours into the single 0-24 hour range required by the
AR System server.
Business time in AR System is calculated on the server. It has a requirement of start
and end times in the range of 0-24 hours. So an invalid business time must be
adjusted using this Offset Hours field. A special case could be a valid business time
on the client that is several time zones away from the server. This time on the client
might become invalid on the server if it crosses midnight after the time zone
adjustment. So you must also use the Offset Hours field in this situation.
Setting a positive offset moves the time later, a negative offset moves it earlier.
Unique offset times are not required. Any adjusted range defined with the offset
hours is valid in the AR System server as long as it falls into a single 0-24 hour range.
Make sure to use the Scheduling Diary field to document how the offset
adjustment is made, for future tracking purposes.
You will find the Offset Hours field useful in the following situations:
Business hours that span over midnight.
For example, a business’s Open Time is 10:00:00 p.m. and its Close Time is
6:00:00 a.m. Use the Offset Hours feature to specify a negative offset (-3 offset
hours). This action recalculates the opening and closing times into an adjusted
0-24 hour range required by the AR System server: 1:00:00 a.m. becomes the new
Open Time and 9:00:00 a.m. the new Close Time.
On the other hand, you could have specified a positive offset of 7 hours to adjust
your business hours to a new Open Time of 3:00:00 p.m. and a new Close Time
of 11:00:00 p.m.
Appendix F Using Business Time in the AR System server 351

BMC Remedy Action Request System 7.1.00
352 Configuring
Business hours that span midnight due to different time zones for the server and
the client.
For example, a business’s Open Time is 9:00:00 a.m. and its Close Time is 5:00:00
p.m. However if the server is ahead of the client by 12 hours, the business time
of the client will be 9:00:00 p.m. and 5:00:00 a.m. The time zone setting of the
client would create an invalid business time calculation because its schedule
spans over midnight. Here you would specify a positive offset number if the
server is behind the client, or a negative offset number if the server is ahead of the
client.
In this example, use the Offset Hours feature to define a negative offset (-12
offset hours). This action recalculates the time zone differences of the client to an
0-24 adjusted range that is required by the AR System server. The client’s Open
Time becomes 9:00:00 a.m. and its Close Time 5:00:00 p.m.
Business hours that span midnight with different time zones.
In this circumstance, you have to derive the offset hour by considering both
factors. The goal is to specify the offset hours to adjust the Open and Close Time
to 0 to 24-hour range on server.
For example, the server is 6 hours behind the client in a different time zones. On
the client, the schedule is 8:00.00 p.m. and 4:00.00 a.m. Specify a positive offset
number (6), because the server is behind the client, to adjust 8:00.00 p.m. and
4:00.00 a.m. on the client to be 8:00.00 p.m. and 4:00.00 a.m. on server. Then use
5 to adjust to the following calculation: 8 p.m. - 5 = 3 p.m., and 4 a.m. - 5 = 11
p.m. Considering both together, the final calculated offset is 6 + 5 = 11.
Old Business Time commands
The following commands were used in the old Business Time scheme. If you use
the old Business Time forms, you can use these commands, but they will not work
with Business Time 2.0
Application-Bus-Time-Add
The Application-Bus-Time-Add command performs a business time calculation by
starting with the start time and resulting in a new time that adds the requested
offset. The command returns a timestamp representing the time calculated. Use
this command to recalculate time into the future.
Use the following syntax for the Application-Bus-Time-Add calculation:
Application-Bus-Time-Add “” [“” [“”
[“” [“”]]]]
The StartTime parameter is required in this command. This parameter must be a
value such as a field reference ($$). Other fields are optional and use
the default value if not provided. You can specify multiple business activity
names.

For example, add one day by using the following calculation:
Using the old Business Time forms
$PROCESS$ Application-Bus-Time-Add “$$” “”
“”
This adds one day to the value that currently resides in Field Name. Show
Field Name as StartTime. Set the offset unit to 4, representing days, and set the
offset to 1, thus adding one day into the calculation. The final syntax looks like:
$PROCESS$ Application-Bus-Time-Add “$8/26/2004$” “1” “4”
Application-Bus-Time-Diff
The Application-Bus-Time-Diff command performs a business time calculation
by computing the difference between the start time and the end time. The return is
an integer representing the difference in seconds. Use this command to compare
two different times (start time and end time) to get the actual business time.
Use the following syntax for the Application-Bus-Time-Diff calculation:
Application-Bus-Time-Diff “” “”
[“” [“”]]
The StartTime and EndTime parameters are required in this command. Other fields
are optional and will default if not provided. You can specify multiple business
activity names.
Application-Bus-Time-Subtract
The Application-Bus-Time-Subtract performs a business time calculation by
starting with the start time and resulting in a new time that subtracts the requested
offset. The command returns a timestamp representing the time calculated. Use
this command to recalculate time in the past.
Use the following syntax for the Application-Bus-Time-Subtract calculation:
Application-Bus-Time-Subtract “” [“”
[“” [“” [“”]]]]
The StartTime parameter is required in this command. Other fields are optional
and will use the default value if not provided. You can specify multiple business
activity names.
Appendix F Using Business Time in the AR System server 353

BMC Remedy Action Request System 7.1.00
Migrating Workdays and Holidays to the
Business Time Segment form
354 Configuring
Following are tips you can use when migrating your Business Time Workdays and
Holidays to the Business Time Segment form.
When migrating Workdays, remember:
All workdays become a Weekly Recurrence time segment.
Time segments require a Start Date and End Date that define the recurrence
range. Since Workdays do not have a range, make sure that the Start Date and
End Date fields represent a large range.
Workdays can have up to 4 shifts. Each shift is now a time segment. These time
segments can have the same IDs.
Set the Level to 1 for all time segments.
Select the End of Day check box to indicate the end of the day instead of 11:59:59
p.m.
The ID field on the Business Time Segment form is the same as the Tag field on
the Business Time Workdays form.
If the Workday form has an offset and if multiple time segments correspond to
this workday entry, apply the offset to only one time segment.
When migrating Holidays, remember:
Use the Specific Dates tab in the Business Time Segment form to specify a list of
dates (with the same time range). Make sure that the Start Date and End Date
are in that list of dates.
Set the Level to 2.
If holidays have been defined with different start and end times, then different
time segments must be created. They can all have the same IDs.
Select the End of Day check box to indicate the end of the day instead of 11:59:59
p.m.
The ID field on the Business Time Segment form is the same as the Tag field on
the Business Time Holidays form.

Debugging tips for Business Time
Debugging tips for Business Time
The following table lists some common errors that users encounter when getting
started with business time functionality in the AR System server.
Problem Solution
You receive an error indicating that a process could
not be run.
If from a filter, this error would be logged in the
arerror.log file.
If from an active link, you are likely getting a NULL
value or might be an error.
You are receiving errors about not being able to find
the workday or holiday entry you specified.
The error could be caused by a problem with the
command name:
Check the spelling (including capitalization) of the
command.
If running from an active link, did you specify to run
the process on the server (@servername: or @@:
before the command name)?
The error could be caused by any of these problems:
Check the spelling of the schedule and activity
names you specified, and make sure that
corresponding names are in the Business Time
Holidays, Business Time Workdays, or Business
Time Segment form.
Make sure you are using a holiday schedule name
for holidays, a workday schedule name for
workdays, and an ID for scheduled activities.
Check the order of your parameters. Remember that
all the parameters are positional. You cannot omit
parameters before the holiday or workday
identifiers.
Check the arguments for spaces. If there are spaces
in an argument, you must quote the value, or the
value will be read as multiple arguments.
Check arerror.log to see if there is a report of a
problem with the Business Time Holidays or
Business Time Workdays forms. As noted above, the
server finds these forms based on the presence of the
key fields that are present on these forms. If it finds
two forms with the same fields, it does not know
which form is the correct one. You must delete the
extra copies of these forms to get back to a single
instance of each.
Appendix F Using Business Time in the AR System server 355

BMC Remedy Action Request System 7.1.00
Problem Solution
Several issues could be causing this problem:
You are not getting a result from the program or you
are getting a result you do not expect.
356 Configuring
Make sure you are using the Set Fields $PROCESS$
syntax, not the Run Process action. There is a return
from this process, so you must use the action syntax
expecting a return.
Use filter or active link logging to report on the
workflow. Is the filter or active link firing? If it is,
what does the command line look like? Did you
forget quotes around arguments that contain
spaces? Do you have all the arguments in the correct
order? Did you leave out one or more arguments?
The arguments are positional. You can leave the
optional ones off the end, but if you supply them,
they must all be present up to the last parameter you
want to supply.
Check the parameters; for example, the units
parameter is a code for the difference function. Are
you using the code that matches the units you want?
Do you have the start and end time in the correct
order for the parameters? Do you have the holiday
schedule name before the workday schedule name?
Check the Offset Hours settings in the Business
Time Workdays form. Have you used the proper
offset value? Are the calculated values correct for
your business? Do the results fall into a adjusted 0–
24 hour range, or do they span over midnight? For
more information, see “Scheduling workdays” on
page 346.

Appendix
G Using
the Assignment Engine
The Assignment Engine is installed with AR System. By following a simple
process, you can automatically assign users to specific requests.
The following topics are provided:
Overview (page 358)
Assignment Engine process (page 358)
Assignment Engine Administration Console (page 359)
Auto-assignment methods (page 360)
Preparing for the auto-assignment process (page 360)
Adding assignment forms (page 363)
Adding assignment processes (page 367)
Adding assignment rules (page 369)
Turning on log and trace files (page 371)
ARerror.log messages (page 371)
Appendix G Using the Assignment Engine 357

BMC Remedy Action Request System 7.1.00
Overview
358 Configuring
Using processes instead of workflow, the Assignment Engine enables you to
automatically assign requests to individuals. When you install the Assignment
Engine, the following forms are installed:
Form name in BMC Remedy Administrator Form name in BMC Remedy User
ASE:Administration Assignment Engine Administration
ASE:AssignAssoc_AssignForm ASE:AssignAssoc_AssignForm
ASE:AssignAssoc_AssignRules ASE:AssignAssoc_AssignRules
ASE:Assignment Association ASE:Assignment Association
ASE:Assignment Process Assignment Processes
ASE:Assignment Rules Assignment Rules
ASE:AssignmentDetail Assignment Details
ASE:DialogYesNo A dialog box; not listed in the Object List.
ASE:Form Information Assignment Forms
ASE:LocalizedString_MenuItems A menu; not listed in the Object List.
ASE:ProcessRuleForm ASE:ProcessRuleForm
ASE:SearchRulesDialog A dialog box; not listed in the Object List.
To set up assignments, you will need to use only a few of these forms, and they are
discussed in the following sections.
Assignment Engine process
Following is the process to integrate the Assignment Engine with your application:
Step 1 Create a form that holds the assignees. (For simple applications, you could use the
User form to hold this information.) Add the appropriate Assignment Engine
fields on this form. (See page 360.)
Step 2 In the request form to which you want to assign users, create the fields that the
Assignment Engine will set on assignment. (See page 360.)
Step 3 Register the assignee and request forms to the Assignment Engine. (See page 363.)
Step 4 Create processes for assignments. (See page 367.)
Step 5 Create rules for assignments. (See page 369.)

Assignment Engine Administration Console
Assignment Engine Administration Console
You use the Assignment Engine Administration Console to set up autoassignment
processes, forms, and rules.
Figure G-1: Assignment Engine Administration Console
The Assignment Engine Administration Console has three tabs:
Processes—Shows the list of processes that the Assignment Engine can use.
Each process has a Process Name.
Each process consists of a request form and a set of sequential rules—all of
which you enter by following the procedures outlined in the following sections.
Forms—Shows all the forms that are registered with the Assignment Engine. To
see the forms that are used by a specific process, select the process name from
the Show For Process list; all the forms used by that selected process appear. The
Forms tab also has a Related Processes table that shows the process for the form
you select from the table. If the form is used in more than one process, the
Related Processes table shows all the processes it is used in.
Rules—Shows all the rules that are in the Assignment Engine. To see the rules
that are used by a specific process, select the process name from the Show For
Process list; all the rules used by that selected process appear. The Rules tab also
has a Related Processes table that shows the process for the rule you select from
the table. If the rule is used in more than one process, the Related Processes table
shows all the processes it is used in.
Appendix G Using the Assignment Engine 359

BMC Remedy Action Request System 7.1.00
Auto-assignment methods
360 Configuring
The assignment method determines who is assigned to an issue when more than
one person matches the qualification and can be assigned the issue. The following
assignment methods can be specified in an assignment rule to automatically assign
an issue when more than one person matches the qualification:
Round Robin—Assigns the issue to the person who has gone the longest since
receiving an assignment.
Load Balance by Number—Assigns the issue to the person who has the fewest
number of issues currently assigned.
Load Balance by Capacity—Assigns the issue to the person who has the largest
unused capacity. For example, if person A is currently assigned 5 issues and has
a capacity rating of 10, and person B is currently assigned 8 issues and has a
capacity rating of 20, person B has a relatively lighter load and will be selected
(8/20 < 5/10).
If two or more people qualify for an issue, the first person retrieved from the
database is used.
Preparing for the auto-assignment process
To begin the auto-assignment process, you must have the following types of forms
identified:
Assignee form—Contains data about people or groups to whom you want to
assign requests. A single process can have multiple assignee forms.
Request form—Is used to assign a request. An example might be a Help Desk
form to which Support representatives are assigned tickets.

Fields to add to the assignee form
Preparing for the auto-assignment process
The assignee form must contain specific fields that the Assignment Engine will use
to run its processes.
Add the following fields to the assignee form. (The following names correspond
with the fields on the Assignment Form. You can use different names, but be sure
to choose the appropriate field when choosing fields on the Assignment Form
form.)
Assignee Unique ID—A field that contains a unique identifier that
distinguishes assignees one from another. This can be a GUID field. For more
information about GUID fields, see the Form and Application Objects guide.
Instead of creating this field, you can use the Request ID field (ID 1) as the
unique identifier. Then, you can add the following optional fields to this form:
Assignee Group Unique ID—The unique instance ID for the assignee group.
Assignee Name/Login—The name of the assignee.
Assignee Delivery Method—A field used to store the method to notify the
assignee of the assignment.
Number Assigned—An Integer field used to obtain and set the current number
of assigned issues for each possible assignee. This field is required only if you
use the Load Balance by Number or the Load Balance by Capacity autoassignment
method.
Capacity Rating—A Decimal field used to obtain the capacity rating for each
possible assignee. This field is required only if you use the Load Balance by
Capacity auto-assignment method.
Last Assigned Time—An Decimal field used to obtain the last time an issue was
assigned to each possible assignee, and to set the last assigned time for the
successful assignee. This field is required only if you use the Round Robin autoassignment
method.
Last Assigned Time—A Date/Time field used to obtain the last date and time
an issue was assigned to each possible assignee, and to set the last assigned time
for the successful assignee. This is an optional field.
Appendix G Using the Assignment Engine 361

BMC Remedy Action Request System 7.1.00
Fields to add to the request form
362 Configuring
The request form must contain specific fields that the Assignment Engine will use
to run its processes.
Add the following field to the request form:
Assignee Unique ID—A character field where the selected assignee’s ID will be
written.
Optionally, you can add the following fields:
Assignee ID Field—An optional second ID field used to store the Entry ID of
the successful assignee.
Assignee Form—A field that stores the name of the assignee form.
Return Code Field—A field used to store the code for success or failure of the
assignment. This field can be used for debugging purposes.
Return Code Description—A field used to store the successful Assignment
Rule ID and the Assignment Qualification ID if the assignment was successful,
or an error code if the assignment failed. This field can be used for debugging
purposes.
Reason Code Field—An obsolete field that is no longer used.
To prepare for the auto-assignment process
1 Create an assignee form. (Tip: You can also use the User form.)
2 On the assignee form, create the fields discussed in “Fields to add to the assignee
form” on page 361.
Hide the fields that you do not want users to see.
3 On the request form, create the fields discussed in “Fields to add to the request
form” on page 362.
Hide the fields that you do not want users to see.

Adding assignment forms
Adding assignment forms
Before setting up the assignment process, you must set up the assignee and request
forms to which the process will apply.
1 Open the Assignment Engine Administration Console.
To add an assignee assignment form
2 Click the Forms tab.
Figure G-2: Assignment Engine Console—Forms tab
Appendix G Using the Assignment Engine 363

BMC Remedy Action Request System 7.1.00
364 Configuring
3 Click Create to create assignee or request forms, or click Search to search for
assignment forms.
The Assignment Engine Forms dialog box appears.
Figure G-3: Assignment Engine Forms dialog box
4 From the Form Name menu list, select the assignee or request form for which you
want to build the assignment process.
5 In the Display Name field, enter a display name for the form you selected.
The display name will appear in the Form Name column on the Forms tab.
6 For Form Type, select Request form or Assignee form (depending on what you
chose in step 4).
The Request form is the form that is requesting the assignment, while the Assignee
form is the form contains the assignee information.
7 From the Status field menu, select Active.
If you do not want to use the form at this time, select Inactive.
8 Optionally, specify a Locale for this assignment form.
NOTE
If the Localize Server option (in BMC Remedy Administrator) is not selected, then
all records will appear, regardless of the client's locale. Assuming that it is selected,
some rules apply. See the Form and Application Objects guide and the Configuring
guide.
9 In the Assignee Group Permissions field, select the group to which you want to
give access.

Adding assignment forms
10 On the Common Fields tab, enter the Assignee Unique ID.
This is the unique identifier for the assignee (an individual user). For example, you
might choose Request ID or Assignee ID.
11 Complete the optional fields:
a Assignee Group Unique ID—Specify the unique instance ID for the assignee
group.
b Assignee Name/Login—Login name or full name of the assignee, for example,
Login Name or Assigned Person.
c Assignee Delivery Method—Field in the assignee form used to store the
method to notify the assignee of the assignment.
If you specified Assignee Form for the Form Type, go to step 13 on page 366.
12 If you specified Request Form for the Form Type, click the Request Form Fields tab
and enter information in the fields, which are described on page 362.
Figure G-4: Assignment Engine Forms field—Request Form Fields tab
Go to step 14 on page 366.
Appendix G Using the Assignment Engine 365

BMC Remedy Action Request System 7.1.00
366 Configuring
13 If you specified Assignee Form for the Form Type, click the Assignee Form Fields
tab and enter information in the fields, which are described on page 361.
NOTE
Make sure that you specify a different Form Name and Display Name for the
assignee forms.
Figure G-5: Assignment Engine Forms field—Assignee Form Fields tab
14 Click Save.

Adding assignment processes
Adding assignment processes
After you set up the assignee and request forms and define rules, you are ready to
add assignment processes to the Assignment Engine.
To add an assignment process
1 Open the Assignment Engine Administration Console.
Figure G-6: Assignment Engine Console
2 Click the Processes tab, and click Create.
The Process Definition form appears.
Appendix G Using the Assignment Engine 367

BMC Remedy Action Request System 7.1.00
368 Configuring
Figure G-7: Process Definition form
3 In the Process Name field, enter a descriptive name for the process.
4 In the Request Form field, select a form that creates the requests to which you want
to assign users.
5 Optionally, enter a description of the process.
6 Click Create to create a new rule.
See “Adding assignment rules” on page 369 for more information.
7 Specify a sequence for the rules.
The rules will apply according to the order in which they appear. See “Setting
sequencing for rules” on page 370.
NOTE
The order of the rule in the process matters; that is, the rules that are most specific
should be at the top of your list because the Assignment Engine goes through the
rules from top to bottom and makes an assignment when it finds a match.
8 Make sure that the Status is set to Active.
9 Click Save.
10 Follow steps 3 through 9 to create other processes.

Adding assignment rules
Adding assignment rules
All assignment processes must have rules defined. A process can have multiple
rules in sequential order.
Because rules can be shared for use by multiple assignment processes, modifying
a rule affects all assignment processes associated with it.
NOTE
Unrelating a rule from a process removes its relationship with the assignment
process, but retains the rule for use by other assignment processes.
To add an assignment rule
1 Open the process for which you want to add a rule.
For more information about processes, see “Adding assignment processes” on
page 367.
2 In the Process Definition form, click Create.
To modify a rule, select the rule and click View.
The Assignment Rule dialog box appears.
Figure G-8: Assignment Rule dialog box
Appendix G Using the Assignment Engine 369

BMC Remedy Action Request System 7.1.00
370 Configuring
3 Enter information in the required fields:
a In the Rule Name field, enter a rule name.
b In the Assignee Form field, select an assignee form.
The Request form field contains the form references in the Process Definition
form.
The rules that you define fill in the assignment-related fields on the request and
assignee forms. These request and assignee forms are external to the
Assignment Engine and part of a separate application. The only requirement for
these forms is that they have the necessary fields on them to be read and written
from the Assignment Engine software. The requirements around these fields
vary, depending on which Assignment Engine rule methods are used.
c Make sure that Status is set to Active.
d In the Assignment method field, select an assignment method. See “Autoassignment
methods” on page 360.
4 Enter qualification for the assignment rule.
A qualification string is a specified set of conditions used to make the automatic
assignment. The Assignment Engine applies the qualification defined here to
attempt to assign a request to an assignee.
The easiest way to build your qualification string is to select the keywords, and
form fields directly from the bar and lists. When you choose items directly from
the lists, the correct syntax is automatically entered. You can also type the
information directly into the qualification string field.
If you are modifying an existing rule, you might see an existing qualification that
you can modify.
5 Click Save.
Setting sequencing for rules
Rules are used according to the order in which they are sequenced. If the first rule
is valid, then that rule is used for the process. If the first rule is not valid, then the
Assignment Engine process will attempt to use the second rule, and so on.
To specify sequencing for the rules
1 Open the Assignment Engine Administration Console.
2 From the Process tab, select the process for which you want to sequence rules.
3 Click View.
The Process Definition dialog box appears.

4 Perform either of the following actions:
Turning on log and trace files
If there are defined rules for the process, select the rule that you want to reorder.
If there are no defined rules for the process, click Create to create new rules (see
“Adding assignment rules” on page 369). Select the rule that you want to reorder.
5 Use the arrow keys to order the rules in the sequence in which you want the
Assignment Engine to use them.
6 Click Save, then click Close.
Turning on log and trace files
You can turn on log and trace files for the Assignment Engine through the
following options in the ar.conf (ar.cfg) file:
AE-Log-File—Full path name of the log file.
AE-Log_File_Size—Size of the log file in MB.
AE-Log—Specify ON or OFF to turn logging on or off.
AE-Trace-File—Full path name of the trace file.
AE-Trace_File_Size—Size of the trace file in MB.
AE-Trace—Specify ON or OFF to turn tracing on or off.
ARerror.log messages
If you are running AR System applications (such as ITSM or CSS or any
application that uses the Assignment Engine component). When the AR System
server is restarted, the server searches for specific tags in the Application
Configuration forms. Consequently, you may notice warnings in the ARerror.log
file. For example:
Sun Mar 12 13:03:45 2006 AssignEng : No schema was found for tag
(ARAPPWARN 4831)
Sun Mar 12 13:03:45 2006 SHR Tag: ApplicationProperties;
These warnings are normal and will always occur when you restart the server. You
can safely ignore these warnings.
Appendix G Using the Assignment Engine 371

BMC Remedy Action Request System 7.1.00
372 Configuring

Appendix
H Using
produse.exe
This section explains how to use the produse.exe utility to generate a license usage
report. The following topic is provided:
Using produse.exe (page 374)
Appendix H Using produse.exe 373

BMC Remedy Action Request System 7.1.00
Using produse.exe
374 Configuring
To gather information about license usage, each AR System server scans the
system approximately every 45 minutes and writes the results to a file named
LicenseReport.txt. You can use the produse.exe utility to generate a license usage
report based on the information in LicenseReport.txt for each of your AR System
servers.
NOTE
Although all servers in a server group use licenses from the same Add or Remove
Licenses form, each server in a group generates its own LicenseReport.txt file.
1 Go to the directory in which the produse.exe utility is located:
To use produse.exe to generate a license usage report
(UNIX ® ) /bin
(Windows)
IMPORTANT
Before running produse.exe on UNIX platforms, make sure the /
bin directory is in the library path environment variable: LD_LIBRARY_PATH
(Linux ® , Solaris), LIBPATH (AIX), or SHLIB_PATH (HP-UX).
2 At the prompt, enter this command:
produse [-i ] [-o ] [-s ]
[-e ] [-r]
Where
-i Specifies the full or relative path to the input file. By default, the input file is
LicenseReport.txt and is located here:
(UNIX) /Db
(Windows) /ARServer/Db
If this parameter is not specified, the current directory and the
LicenseReport.txt file name are used.
-o Specifies the full or relative path to the output file. By default, the output file
name is ReportResult.csv and is located here:
(UNIX) /Db
(Windows) /ARServer/Db
To rename it, specify a different file name. If this parameter is not specified, the
current directory and the ReportResult.csv file name are used.

-s Specifies the start date of the report in D/M/YYYY format.
Using produse.exe
The start time is 12:00 a.m. on the specified date.
If this parameter is not specified, the report includes data from the beginning of
the LicenseReport.txt file.
If this parameter exceeds the range covered by the LicenseReport.txt file, the
range covered by the file is used instead, and that range is indicated in the report
header.
-e Specifies the end date of the report in D/M/YYYY format.
The end time is 12:00 p.m. on the specified date.
If this parameter is not specified, the report includes data to the end of the
LicenseReport.txt file.
If this parameter exceeds the range covered by the LicenseReport.txt file, the
range covered by the file is used instead, and that range is indicated in the report
header.
-r Backs up the current LicenseReport.txt file by renaming it
LicenseReport----.txt and
generating a new LicenseReport.txt file.
NOTE
You can also generate a license usage report from the Administration Console. See
Chapter 2, “Licensing AR System.”
Appendix H Using produse.exe 375

BMC Remedy Action Request System 7.1.00
376 Configuring

Index
A
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
access control
group list 88
User form 86
accrue operator
full text search 208
accrue searches 213
accruing results with FTS 209
active links, run process directory and shell 134
activity, business
creating 331
viewing associations 335, 336
Add or Remove Licenses form 36
adding
assignment forms 363
assignment rules 369
licenses to AR System servers 36
admin queue 25
administrator operations, disabling 121
Administrator Preference form 46
administrator-only mode 121
advisory mode, source control 137
aging passwords 95
Alert Events form 179
alerts
See also BMC Remedy Alert
architecture 178
configuring server 175
disabling 122
escalation 180
log file 125
mapping through firewalls 273
mid tier 182
queue 26
registration activity, with server events 311
server architecture and 19
time-out 115
verifying users who receive 122
viewing 180
web-based, list 182
alias for server name 114
allowing
guest users 93, 120
unqualified searches 121
API
architecture and 19
log file 124
version 119
appending to existing log file 126
Application License field 89
application services password 142
AR Export file 238–240
ar file 248
AR System licensing 32
AR System Portmapper
overview 29
registering 130
AR System server
configuring 112
ID 117
scalability 23
Windows stand-alone 168
AR System Server Group Operation Ranking
form 167
AR System User Central File form 45
AR System User Preference form
Advanced tab 65
Alert tab 68
Color tab 57
common fields 50
Confirmation tab 58
Display tab 56
Edit tab 71
File tab 63
General tab 51
Home Page tab 67
Locale tab 62
Logging tab 61
Misc tab 74
overview 45
Recent tab 70
Report tab 59
setting preferences for the web 79
Index 377

378 Configuring
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
AR System User Preference form (continued)
Web tab 77
Window tab 73
ar.conf (ar.cfg) file 248
ar.ini file 45
aralert.log 125
arcache utility 134, 296, 310
architecture
AR System 16
AR System server 18
mid tier 17
architecture, alert 178
archive activity, with server events 311
archiving
disabling 121
ardb.conf (ardb.cfg) file
overview 287
SQL warning 287
AREA
configuring server 172
overview 20
RPC program number 147, 172
ARerror.log messages 371
ARF plug-in API 19
arfilter.log 124
arforkd
log file 125
utility 292
arftindx.log 226
armonitor utility 292
armonitor.conf (armonitor.cfg) file
overview 290
arplugin utility 293
arplugin.log 125
arreload utility 134, 299, 310
arserverd (arserver) utility 293
arserverd process 221
arsignal utility 301
arsql.log 125, 227
arthread.log 125
aruser.log 125
ASCII files, generic 188
assignee groups 122
assigning TCP port numbers 128
assignment
forms, adding 363
rules
creating 369
sequencing 370
Assignment Engine
Administration Console 359
ARerror.log file and 371
Assignment Engine (continued)
Forms tab 359
methods 360
Processes tab 359
Rules tab 359
rules, creating 369
attachment tables
data 246
details 246
attachments
indexing for 222
multiple languages and file formats 222
attachments, exporting 189
authenticating unregistered users 148
authentication alias 102
Authentication field, Login dialog box 106, 149
Authentication Login Name field, User form 103, 104
Authentication String Alias
configuring 105
overview 105
Authentication String field, User form 105, 106
auto-assignment, working with
adding, assignment forms 363
Assignment Engine Console 359
methods 360
rules
creating 369
sequencing 370
B
backup log file 126
backward compatibility
BMC Remedy Alert, working with pre-5.0
AR System 181
blank password 94
BMC Remedy Alert
about alerts 19
backward compatibility 181
installing 183
multiple servers and 160
overview 179
BMC Remedy Configuration Tool 18
BMC Remedy Import
data mapping 186
fallback mappings 186
import log file 205
overview of 185
BMC Remedy User
licensing user, full text search 228
search results, order 209
setting home page 67

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
BMC Remedy User (continued)
sorting requests by weight (FTS) 209
weight (FTS) in results list, displaying 231
BMC Software, contacting 2
buffer logged lines 126
business activity
creating 331
viewing associations 335, 336
business hours, defining business time
business hours, defining 346
Business Segment-Entity Association form 327
Business Segment-Entity Association_Join form 327
business time
Application-Bus-Time-Add command 340, 352
Application-Bus-Time-Assoc-Add
command 344
Application-Bus-Time-Assoc-Diff command 344
Application-Bus-Time-Assoc-Get-Free-Window
command 345
Application-Bus-Time-Assoc-Get-Next-Window
command 344
Application-Bus-Time-Assoc-Subtract
command 344
Application-Bus-Time-Diff command 341, 353
Application-Bus-Time-Get-Next-Window
command 341, 342
Application-Bus-Time-Subtract command 341,
353
Application-Get-Next-Recurrence-Time
command 345
command syntax 337
debugging tips 355
examples, one hour gap 348
forms 327
holidays
adjust time across midnight 350
dates and times, entering 350
holiday time, using 348
international server 350
no end time 350
no start and end time 350
no start time 350
holidays form, setting dates in 348
how it works 328
migrating 354
offset hours, using with 337
overview 326
Business Time Holidays form 327
Business Time Segment form 327
Business Time Shared Entity form 327
Business Time Shared Entity-Entity
Association_Join_Join 327
Business Time Workdays form 327
C
cache
changes 140
refresh interval for currency ratio 116
centralized preferences 44, 45
changes
object 310, 312
server cache 140
server objects 310
server settings 310
user and group 140, 310
viewing 311
changing passwords 95
check interval, server groups 135
CleanupAlertEvents escalation 180
clients, configuring TCP port numbers 170
client-side, logging group 126
CLOB storage 128, 276
clustered index used with Request ID 128
comma-separated value files 188
comments in source control 137
computed groups
overview 89
searching in User form 89
config.properties file 18
configuration files
ar 248
ar.conf (ar.cfg) 248
ardb.conf (ardb.cfg) 287
armonitor.conf (armonitor.cfg) 290
config.properties 18
configuration options for full text search 224
Configuration Tool, alert system and 182
configuring
AREA server 172
clients 30, 46, 48, 170
databases 128
firewalls 169
mail server 174
multiple servers 151
servers
for alerts 175
information 118
for plug-ins 171
threads 131
Windows clients and portmapper 170
confirmation preferences 189, 197
consoles, Assignment Engine Administration 359
core fields 195
Index 379

380 Configuring
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
cross-reference blank password 88, 149, 173
currency ratio, cache refresh interval 116
currency types
default allowable types 145
default functional types 145
server settings 144
user preferences 63
current licenses 84
customer support 3
customizing environment 44
D
data
mapping 186
mapping with saved files 204
preparing to import 187
reloading 301
data preferences 189, 194
database servers 20
databases
attachment tables 246
configuration file 128
password 127
server information 126
status history table 246
UNIX directory 127
user name 127
version 127
databases, searching 208
datatype values, Server Events form 319
date and time preferences 189, 196
date format 303
dates in business time holidays form, using 348
debug modes
trace mode 123
using log files 123
default
home form 120
web path 133
Default Notify Mechanism field 89
deleting
Demo user 91
licenses from AR System servers 38
users 91
Demo user
deleting 91
initial installation 90
desktop preferences 189, 190
disabling
administrator operations 121
alerts 122
archive 121
escalations 122
dispatcher thread 27
Distributed Server Option. See DSO
Distributed Server Option. See DSO
DSO
configuration file options 266
local server password 143
log file 124
remote server password 143
duplicate request ID preferences 189, 191
E
email
line length 133
notifications 119
reserved field for address 89
email server 174
enforced mode, source control 137
entries returned by GetList 119
environment
AR System architecture 16
customizing 44
variables 30
error handling preferences 189
error messages, localizing 134
escalations
CleanupAlertEvents 180
disabling 122
log file 124
process time-out 115
estimating FTS index size 230
Event Details fields 315
events recorded in Server Events form 309
events, server 139
export file 238
exporting
attachments 189
licenses 38
source data 188
external authentication (AREA)
configuring server 172
defined 20
RPC program number 147, 172
time-out 147

F
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
fallback mappings 186
fast queue 26
fields
changing existing value 238
changing length 236–237
Event Details 315
FTS, defining for 229
indexing 220, 229
preserving existing values 237
Request ID and 234
reserved for Server Events 308
files, configuration
ar 248
ar.conf (ar.cfg) 248
ardb.conf (ardb.cfg) 287
armonitor.conf (armonitor.cfg) 290
files, import log 205
Filter API RPC time-out 115
filters
log file 124
maximum 133
process time-out 115
firewalls 169
fixed write license 83, 117
Flashboards
queue 26
floating licenses
information displayed 117
releasing 85
time limit 116
write 83
force password change 95
form search field, adding 218
forms
Add or Remove Licenses 36
Administrator Preference form 46
Alert Events 179
AR System Server Group Operation Ranking 166
assignment forms, adding 363
business time 327
Request ID and 234
Server Events 140, 308, 315
server, maximum number 117
User 86
User Central File 45
User Preference 45
vendor 20
view 20
Forms tab 359
FTS weight, displaying 231
FTS. See full text search
Full Name field (user) 89
full text index logging 226
Full Text Search
configuring for server groups 162
full text search
accrue operator 208
accruing results 209
administering 220
capabilities 208
configuration options 224
criteria 211
debugging 226
defining fields 229
disk space and 230
fields, indexing 220, 229
Ignore Words List 209, 219
indexes 210, 230
licenses 210, 228
logging 226
method 211
overview 208
QBE settings 217
results list, formatting 231
results, weighting 209
sorting records by weight 209
sorting requests by weight 209
time required to rebuild index 223
upgrading FTS 227
using 210
full text searches
indexing for attachments 222
multiple languages and attachment files 222
G
GetList 119
Group List field 88
groups
changes 140, 310
client-side logging 126
computed, in User form 89
multiple assignee 122
viewing changes 314
guest users, allowing 93, 120
Index 381

H
382 Configuring
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
hardware platform 114
home page
Default Home Form filed 120
form for BMC Remedy User 67
form for mid tier 67
server
for BMC Remedy User 67
for mid tier 67
host ID, determining AR System server 35
I
Ignore Words List
rebuilding index 224
searches, using in 219
using 209
import log
importing data from 206
writing XML data to 206
importing
data into AR System 186
licenses 39
preparing data for 187
procedure 199
process 186
stopping an import 202
indexes
fields 229
FTS size, estimating 230
full text search 210, 220
Ignore Words List 224
time required to rebuild FTS 223
information 346
in-row storage, Oracle database 128, 276
Instance ID field 89
issues, when creating searches 219
J
Java API 18
Java plug-in server 295
JSP engine 17
K
keys, license 35
L
licenses
about AR System licensing 32
adding to AR System servers 36
charges 34
current 84
exporting 38
fixed write 83, 117
floating write 83, 117
full text search 210, 228
host ID for AR System server 35
importing 39
keys 35
license pools 86
Manage User Licenses form 83
maximum number of forms 117
pools 86
produse.exe 374
read 82
registered users 84
releasing floating 85
removing from AR System servers 38
ReportResult.csv file 41
restricted read 82, 89
reviewing usage 41
server group 33
server information 116
submitter mode 117
tab in Server Information form 116
types 82, 89, 117
usage reports 41
user 83
verifying purchased 42
list queue 27
literal search 214
load balance
by capacity assignment method 360
by number assignment method 360
load-balanced environment, using with server
events 308
local preferences 44
local server password, DSO. See DSO
locale 62
localizing error messages 134
log files
alert 125
allowing space for 187
API 124
append to existing 126
arforkd 125
backup 126

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
log files (continued)
buffer logged lines 126
data import log 205
Distributed Server 124
escalation 124
filter 124
log per thread 126
options 124
plug-in 125
server groups 125, 165
server information 123
settings 123
SQL 125
threads 125
trace mode 123
users 125
log per thread 126
logging in
authentication alias 102
Authentication field 106
User Name field 104
user prompt 119
logging, full text index 226
Login dialog box, authentication alias 104
Login Name field, User form 88
logins, unique 106
M
Manage User Licenses Information form 83
mandatory preference server 46
mapping
data from source file 201
fallback mappings 186, 202
loading a mapping 187, 205
overview 186
saving a mapping 202
using a saved mapping file 204
max forms allowed on server 117
maximum
entries returned by GetList 119
filters for an operation 133
line length in email 133
log-file size 126
stack of filters 133
methods, auto-assignment 360
mid tier
administration password 142
setting
home page 67
preferences 79
web-based alerts 182
migrating business time 354
modes
administrator-only 121
debugging 123
server records 135
source code 137
submitter 94, 116, 117
modifying
Ignore Words List (FTS) 224
multiple assign groups 122
multiple servers 128, 151
multithreaded servers
architecture 23
queues 25–27
RPC program numbers 25
threads 27, 29
multi-tier architecture 16
N
next available Request ID, changing 234
notifications
BMC Remedy Alert 179
email 119
ports 130
server 178
time-out 115
web-based alerts 182
Notify action 179
O
object changes 310
server settings 310
viewing server changes 312
Object ID field 89
offset hours, using with business time 337
operating system 114
operations, preventing 121
Oracle database
CLOB storage 128, 276
P
parametric full text search 218
Password field in User form 88
password management 95
passwords
administering 141
aging in operating system validation 95
application service password 142
Index 383

384 Configuring
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
passwords (continued)
blank 94, 173
BMC Remedy Alert 181
character limit in Password field 88
Cross Ref Blank Password option 94
database 127
Demo 90
DSO local server 143
DSO remote server 143
length for operating system validation 95
length limit in Password field in User form 88
lockout periods for operating system 95
modifying by users 92
number of retries 274
Password field in User form 88
plug-in server password 142
security 88, 94
validating 149
validating operating system 94
workflow server 143
passwords, changing 95
passwords, qualifications for restrictions 100
performance tuning
request ID uses clustered index 128
unqualified searches 121
permission types 88
permissions, user form 92
plug-ins
AR System filter plug-in API 19
configuring server 171
log file 125
server password 142
pool, license 86
port numbers. See TCP port numbers
portmapper
dependency, removing 170
ports
notification 130
server 128
preference servers, mandatory 46
preferences
See also AR System User Preference form
accessing preferences dialog box 189
centralized 44, 45
confirmation 189, 197
data 189, 194
date and time 189, 196
defining 187, 189
desktop 189, 190
duplicate request ID 189, 191
error handling 189
forms 46, 50
preferences (continued)
local 44
mid tier 79
overview 187
server 45, 46, 48
setting with client tools 49
synchronization 44, 49
user 44, 50
web clients 79
Windows clients 49, 50
prefixes
lengthening 245
shortening 242
preventing user operations 121
private queues 27
private servers
adding 170
operations supported 27
$PROCESS$
business time 337
commands 337
process time-out 115
Processes tab 359
product support 3
produse.exe 374
properties, indexing for FTS 229
Q
QBE settings 217
qualifications for password restrictions 100
queries. See searches
queues
admin 25
configuring threads 131
fast 26
list 27
overview 25–27
private 27
server 128, 130
server statistics 135
R
read license 82, 89
rebuilding FTS indexes 223
recording events 309
recording interval, statistics 135
recurrence
options 346
overview 326

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
registered
licenses 84
users 86
registered users in BMC Remedy Alert 181
registering with portmapper 130
Remedy Alert
See also alerts
Remote Procedure Call (RPC). See RPC program
numbers
remote server password, DSO 143
removing. See deleting
ReportResult.csv file 41
reports, license usage 41
Request ID field
changing length or prefix 236–237
changing value 238
number 234
preserving existing values 237
working with 234
request ID uses clustered index 128
Request ID, changing next available 234
requests
processing 28
restarting threads 29
routing to appropriate queues 27
submitter mode 94, 117
reserved fields, Server Events 308
restricted read license 82
retries for passwords 274
Round Robin, assignment method 360
RPC program numbers
AR RPC number 171
external authentication server 147, 172
fixed 25
setting 129
rules
assignment 369
sequencing 370
Rules tab 359
run process directory 134
S
saved mapping files 204
scalability
AR System server 23
mid tier 23
scheduling workdays 346
searches
accrue 213
for computed groups 89
How QBE settings affect FTS 217
searches (continued)
Ignore Words List, using in 219
literal 214
parametric full text search 218
search issues 219
search strategies 219
unqualified 121
Word or Phrase 211
security
Demo password 90
guest users 93
passwords 88, 94
settings 134
sequencing, rules 370
server cache, changes 140
server events
alert client registration 140
archive 140
server groups 140
server setting changes 140
settings 139
types 140
using with load-balanced environment 308
Server Events form 307
automatic generation 308
creation 308
datatype values 319
event types 309
events that can be recorded 309
server setting changes 315
specifying 140
using 308
workflow and 323
server group actions, with server events 311
server groups
AR System Server Group Operation Ranking
form 166
check interval, setting 135, 158
communicating with Email Engine 164
communicating with Flashboards 164
configuration file options 282
Full Text Search 162
group name, setting 135, 157
installing members 156
licensing 33
log file, setting 125, 165
logging in Server Events form 165
operations 155
overview 155
ranking servers in 166
removing a server 168
server name 159
Index 385

386 Configuring
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
server groups (continued)
signaling 161
specifying a server as a member 121
server information
advanced 132
configuration 118
currency types 144
database 126
licenses 116
log files 123
overview 112
password administration 141
platform 113
server events 139
server ports 128
source control 136
timeouts 114
Server Information form 112
server recording mode 135
server statistics 135
server utilities
arcache 296
arforkd 292
armonitor 292
arplugin 293
arreload 299
arserverd (arserver) 293
arsignal 301
Java plug-in server 295
servers
alerts, configuring for 175
AR System, architecture 18
architecture 23
AREA 172
cache changes 140
configuring
clients 170
for plug-ins 171
multiple servers 151
configuring threads 131
database 20
directory 114
language 119
license type 117
mail 174
maximum forms allowed 117
multiple 128, 151
multiple servers sharing same database 153
name alias 114
name in server groups 159
Notification 178
object changes 310, 312
servers (continued)
ports 128
preference 45, 46, 48
private 27
processing concurrent requests 27
queue 25–27, 130
ranking for server groups 166
report server 66
See also server cache
server groups 155
stand-alone 168
statistics 135
TCP/IP port 129
time zone 114
version 114
web 18
web servers
servlets 18, 23
settings
log files 123
QBE 217
server information 112
sort records by weight 209
source control
advisory and enforced modes 137
comments required in check in 137
source data, exporting 188
SQL
ardb configuration file warning 287
log file 125
SQL commands
Request ID field prefix, lengthening 245
Request ID field prefix, shortening 242
SQL logging 227
stand-alone server, Windows and AR System 168
starting armonitor utility 292
statistics, recording server 135
status history table 246
stems, word 216
strategies for full text searching 219
submitter mode option 117
submitter, special access mode 94
support, customer 3
Sybase database, Request ID and 235
syntax, business time commands 337

T
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
table types, database
attachment details 246
status history 246
tabs
Forms 359
Processes 359
Rules 359
TCP port numbers 29
AR TCP Port 171
assigning 128
configuring clients 170
TCP/IP port 129
technical support 3
thread manager 29
threads
configuring 131
dispatcher 27
log file 125
notification 130
processing requests 28
restarting 29
routing requests 27
types of 27–28
worker 25, 28
time and date settings in AR System 325
time format 303
time zone 114
timeouts 114
trace modes, debugging log files 123
types of licenses 82
U
unique user logins 106
UNIX
database directory 127
email notifications 119
UNIX servers, starting 292
unqualified searches 121
unregistered users, authenticating 148
upgrading FTS 227
URL, base to mid tier 133
usage, reviewing license 41
User form
Authentication Login Name field 103, 104
Authentication String field 105, 106
guest users 93
user information 86
user form permissions 92
user name alias
configuring 103
overview 103
User Name field, user name alias 104
users
alert 122
authenticating 148
changes 140, 310
customizing preferences 44
defined 86
deleting 91
Demo user 91
email notifies from 119
full name field 89
guest 93, 120
license information 83
log file 125
names 88
operations, preventing 121
permissions 88
prompted for login 119
registered, in BMC Remedy Alert 181
viewing changes 313
web 79
utilities
arcache 296
arforkd 292
armonitor 292
arplugin 293
arreload 299
arserverd (arserver) 293
arsignal 301
Java plug-in server 295
produse.exe 374
V
validating passwords 149
variable, environment 30
vendor form 20
verifying alert users 122
view form 20
viewing
alerts 180
group changes 314
server changes 311
server object changes 312
user changes 313
Index 387

W
388 Configuring
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
web
See also mid tier
BMC Remedy Configuration Tool for mid tier 18
centralized preferences 79
default path 133
server, definition 18
web services, architectural overview 22
web-based alerts 182
weight
results with FTS 209
sorting records by 209
weight, FTS 231
wildcards
full text search 217
wildcards, in full text searches 216
Windows servers
data reload 301
starting 292
Word or Phrase search 211
word stems 216
worker threads 25, 28
workflow
logging 126
Server Events form and 323
server password 143
write licenses
fixed 83
floating 83, 85
X
XML
files, description of 188
writing XML data to import log 206

*69391*
*69391*
*69391*
*69391*
*69391*