This documentation supports the 9.0 version of Remedy Action Request System.

To view the latest version, select the version from the Product version menu.

BMC Remedy AR System server enhancements in version 9.0.00

This topic provides information about the following BMC Remedy AR System server enhancements.

Improved Archiving

The new improved archiving offers the following:

  • All the forms are archived on a common global schedule.
  • Related data in multiple forms can be archived in a single transaction.
  • The archive definition includes an age qualification.
  • An archive management console has been introduced.

For more information, see Archiving Concepts.


  • In version 9.0, archives must be of type copy and delete or delete. Any archives that are of type copy at the time of upgrade will be converted to copy and delete. This ensures that records in the archive form are unique.
  • Starting 9.0, vendor form and join form cannot be archived. Any existing archive defined for join form and vendor form is ignored for archiving.

Restrictions for users and groups

Starting with this release, new restrictions are added that prevents you to create other users with more administrative rights than yourself, and to modify your own rights.

The new restrictions prevent:

  • Creation of an administrative user by a nonadministrative user.
  • Creation of an administrative user with access to more overlay groups than the administrative user who created them.

The following restrictions apply before and after you create or modify any user in the User and Group form.

  • Only an administrator can create, modify, or delete other users belonging to the Administrator, Sub-Administrator, Struct Admin, or Struct Sub-Admin groups.
    • A user must have Group ID 1, AR System Administrator rights, and Fixed License in the group list to create, modify, or delete another user of any of the four administrative class groups in their group list.
  • No administrator user can create or modify a user (themselves included) with lesser administrative restrictions than themselves.
    For example, an administrator user with Overlay Group 1 rights cannot create or modify users who are not a part of overlay groups. Consider a situation where you have created an ABCGroup with an Overlay Group set to 1. User ABCAdmin is part of the Administrator group and the ABCGroup. However, ABCAdmin is restricted only to the ABCGroup. ABCAdmin can change (create/modify/delete) any user belonging only to the ABCGroup. For more information about creating a group as an overlay group, see Creating groups.
    • A user cannot create another administrator with the ability to modify base objects if they themselves cannot do it.
  • Only an unrestricted administrator can create, modify, or delete groups that restrict a user’s administrative capabilities.
  • Only an administrator without an overlay-specific groups can create, modify, or remove overlay-specific groups.

For information about creating and modifying user information, see Adding and modifying user information.

Centralized configuration

Before this release, BMC Remedy AR System components stored their configuration data in separate files. Configuration data for the AR System server and the BMC Remedy Approval Server was stored in the ar.cfg (ar.conf) file; the data for Mid Tier was stored in the file; the data for the BMC Remedy Email Engine was stored in the file; and the data for the Java plugin server was stored in the pluginsvr_config.xml file. Because the configuration data was dispersed across files, it was difficult to share the data across servers, or to backup or restore data. This decentralized structure also led to maintenance issues, data redundancy, and low data security.

Starting with this release, configuration data is stored in new centralized configuration forms and reflected in the ar.cfg configuration file (for backward compatibility). Centralized configuration not only makes configuration data easier to manage, but also makes it easy to share the configuration settings across servers. Also, because configuration data is stored directly in the database, it is more secure.

With this release, the configuration data for the following components is centralized:

  • BMC Remdy AR System server
  • BMC Remedy Mid Tier
  • BMC Remedy Approval Server
  • BMC Remedy Email Engine
  • BMC Remedy Java plug-in server

For more information, see Centralized configuration.

Service failover

Before this release, companion services were dependent on, and shared the state of the AR System servers. If the AR System server failed, all the dependent services also failed.

Starting with this release, the servers in the group cooperate together to manage service failover. The server group manages when the companion services become active to perform tasks and when they are suspended. Also, the companion services are tracked and can fail over independently of any AR System server.

For more information, see Service failover.

AR System server queue threads configuration changes

The AR System server scheduler has many work queues, such as queues for archiving, for escalation pool 1, for escalation pool 2, and so on. Before this release, each queue had its own dedicated thread. When jobs were triggered, they were automatically put in the appropriate queue to make sure that they were serialized with the other jobs in the same queue.

Starting with this release, AR System server uses threads from a thread pool. A scheduled request is received by the first available thread. After the request is processed, the thread returns to the pool and becomes available for another request. 


The Fast, List, and Private queues do not use threads from the thread pool.

For more information, see AR System server queue wait times  in the BMC Remedy ITSM Deployment documentation.

Service operations monitoring

You can now monitor the number of emails sent and received from AR System server in an hour. For more information, see Monitoring service operations.

Limiting entries in a report

Starting with this release, you can add the new maxEntriesInFileReport parameter to limit the number of entries in a BMC Remedy Action Request System (AR System) report using AR System Administration:Plugin Server Configuration form. For more information, see Limiting entries using a published report.

API call monitoring

You can now monitor the API calls between an AR System server and its clients and capture information such as the number of API calls based on the client type, the total amount of data sent to the client, the number of successful API calls, and so on.

For more information, see Monitoring API calls.

Enhanced logging features

BMC Remedy AR System now provides the following enhanced logging features:

Logging configuration

Modify the logging parameters such as log file name, log file size, logging level and so on, without restarting the process. Modifications to the logging parameters are applied immediately, without an interruption to the service or to the business.

The logging configuration enhancements are available in:

Logging restriction

Restrict logging to specific criteria.

Typically, you turn on logging to troubleshoot issues. Generally, log files capture all the information for an area being logged, which impacts the system performance. The log files capture more information than required and their large size consumes additional disk space. The logging restriction feature allows you to capture only the required information in a log file, so that it has less impact on system performance, and extra information is not recorded. You do not have to parse through large log files to find the source of an issue.

The logging restriction enhancement is available in:

Logging consistency

Format log files consistently. Data is presented in a familiar format to help you parse log files and find root cause issues easily.

The formats of following log files are consistent with the AR System server log files:

Full-Text Search enhancements

The following enhancements for Full Text Search (FTS) are available:

FTS enhancementDescription
High Availability for FTS

In a server group environment, Full Text Search (FTS) can be configured for High Availability so search requests are completed even when a server in the group becomes unavailable. Under the FTS HA model:

  • Every server with valid FTS Server Group Operation ranking acts as an indexer server.
  • Each indexer has its own copy of indexes.
  • The searcher server sends the search requests to indexer servers.
  • During failover of an indexer server, a search request is routed to the highest ranking available indexer server to complete the search request.

For more information, refer to Enabling FTS high availability.

FTS indexing with schema-specific files improved

AR System uses the Lucene 4.9 search engine for Full Text Search (FTS) and uses a schema-specific multi file index format to optimize read/write operations, resulting in searches that are about three times faster and indexes that are about 40 percent smaller than the Lucene 2.9 index used in earlier releases.

For more information, refer to FTS index migration.

FTS components upgraded to latest releases
EngineOld versionNew versionDescription
Apache Lucene2.94.9Enables high-performance full-text search.
Apache Tika1.21.6Detects and extracts metadata and text from a wide variety of file formats.
FTS index migration utility

The Full Text Search (FTS) index migration utility arftsutil migrates the single-file Lucene 2.9 index into a multi file schema-specific index compatible with the Lucene 4.9 search engine. The arftsutil utility is embedded in the interactive GUI AR System installer, so existing Apache Lucene 2.9 single-file indexes are automatically migrated to the Lucene 4.9 schema-specific multi file format. Automatic migration can be skipped when you use the silent installer. The arftsutil utility can be run from the command line to migrate an existing Lucene 2.9 index to the 4.9 format.

For more information, refer to FTS index migration.

New AR System Server Object — Association

The BMC Remedy AR System now offers a way to explicitly define relationships using Association, a new AR System server object. In AR Applications, relationships between forms are implicit since they are defined by creating workflow that ties them together using various actions. This makes it harder for one to understand dependencies and thus the application as a whole.

Enforced associations eliminate the need to create workflows to enforce referential integrity and deleting related data. Reducing the number of workflows for applications makes them easier to understand. Association can also be used to get related data and archive them as well.

For more information, see Associations Overview.

Was this page helpful? Yes No Submitting... Thank you


  1. Thomas Hammer

    Please clarify the use of the new centralized configuration.

    Is the data stored in ar.cfg only or is it still distributed to other files, e.g. pluginsvr_config.xml

    The section "Limit number of entries in a report" is still talking about the dedicated pluginsvr_config.xml file. Please specify what will be centralized and which data will not.

    Thank you



    Jan 08, 2015 08:11
    1. Vaijayanti Nerkar

      Hello Thomas,

      Thank you for your comment. We will sync with the SME and make the documentation more clear. If possible, we will have someone reply to you directly before we make the updates to the topic.



      Jan 09, 2015 12:27
    1. Prachi Kalyani

      Hello Thomas,

      Thank you for your comment.

      The configuration data is still stored in respective files and is also maintained on a centralized location, that is, the centralized configuration forms making it easier to manage the data. So we still maintain the pluginsvr_config.xml and ar.cfg files.

      Hope that helps!





      Jan 22, 2015 11:37
  2. Thomas Hammer

    Thank you for your reply.

    Is this for backward compatibility only, or is it part of the new concept to store data in pluginsvr_config.xml and ar.cfg files?


    This page should descibe the new behaviour.

    Section "Centralized configuration" says several times "was stored" not "is stored".


    It also says: "and reflected in the ar.cfg configuration file (for backward compatibility)"

    That seems to be clear to me. But your answer is not.

    So this is my question: For future concept, where will it be stored?


    Jan 23, 2015 02:30
    1. Prachi Kalyani

      Hello Thomas,

      Previously the data was stored only in the ar.cfg file for AR System server and Approval Server. Starting from this release, the data is stored in new centralized configuration forms and also reflected in the ar.cfg configuration file. (for backward compatibility).



      Jan 23, 2015 02:50
  3. Thomas Hammer

    Thank you very much. This makes it much clearer and this was my understanding of this page.

    And it brings me back to my original question.

    The section "Limiting number of entries in a report" does not reflect the new concepts. It is exclusively mentioning the file based configuration. So either you add a hint about backward compatibility there so it will be in sync with the other section OR you may add an explanation there is an exception to the rule and the data is stored locally and only locally in spite of the new concept. I don't know which decision is the correct one, but you will know for sure.

    Jan 23, 2015 04:38
    1. Prachi Kalyani

      Hello Thomas,

      Sorry for the delay in response. We have update the Limiting number of entries in a report topic to reflect the changes.



      Jul 14, 2015 06:00
  4. Tom Zmijewski

    Can you elaborate on the backwards compatibility? Is that to imply that changes within the config files themselves will be reflected in the config data stored within the database or are these files accessible or intended to be read only?

    That the files are still utilized would seem at odds with the config data being more secure in that case.


    Feb 20, 2015 11:26
    1. Prachi Kalyani

      Hello Tom,

      Thank you for your comment. Starting with this release the configuration data is stored in new centralized configuration forms and reflected in the ar.cfg configuration files. The ar.cfg are intended to be read only files. 



      Feb 24, 2015 04:29
  5. Fred Grooms

    And how would differences in the individual server's ar.conf files be maintained in the centralized database forms?  

    (i.e. A server that was used only for reporting could have very different thread definitions or logging configurations than a server used for data entry even though both are against the exact same database)

    May 01, 2015 04:11
    1. Sayali Dwivedi

      I am not sure what you mean by same database. Even in clustered environment, each AR server has its own ar.conf which contains settings specific to that AR server.

      Each individual configuration for AR Server is read from the ar.cfg and stored against its Configuration-Name in Centralized Configuration forms. This can be clearly seen in a server group environment where we have different configurations for different AR servers in a server group.

      Hope this helps,


      May 04, 2015 02:38
      1. Jan Sierens

        I'm still a little bit confused about the synchronization between the configuration file (like ar.conf) and the Centralized Configuration forms and which one is used by the servers.

        If I change the Centralized Configuration forms that will update  configuration files like ar.conf?

        If I make a change in the configuration file directly, will that be reflected in the Centralized Configuration forms? Will changes be overwritten by the Centralized Configuration forms and when?

        Do the servers read the configuration files (like ar.conf) at startup or the Centralized Configuration forms?

        Jun 29, 2015 10:56
        1. Thomas Hammer

          Hi Jan,

          good questions. Exactly such information is missing in the documentation.

          @BMC: Please clarify.

          From my understanding at least one information is required to which database to connect. After a successful connection all other information should be in the database.

          @BMC: Please provide more information on that process as well, please.

          Jun 30, 2015 01:44
        1. V h v sekhar Durga

           ar.cfg/ar.conf file is the source of truth for AR Server. Whenever this file is changed manually, AR Server syncs this configuration back to Centralized configuration forms, without server restart. At the same time, whenever Centralized Configuration forms are updated, that configuration will be updated in ar.cfg file as well.

          AR Server reads ar.cfg file while starting and it updates Centralized Configuration forms with the configuration that is present in ar.cfg.

          Now following are answers to specific questions:

          Q: If I change the Centralized Configuration forms that will update  configuration files like ar.conf?

          A: Yes, AR Server updates ar.cfg file.

          Q: If I make a change in the configuration file directly, will that be reflected in the Centralized Configuration forms?

          A: Yes, changes from ar.cfg will be reflected in Centralized Configuration forms after 30 seconds.

          Q: Will changes be overwritten by the Centralized Configuration forms and when?

          A: Whenever we update Centralized Configuration forms, those changes will be updated/overwritten in ar.cfg.

          Q: Do the servers read the configuration files (like ar.conf) at startup or the Centralized Configuration forms?

          A: AR Server reads ar.cfg file during start-up and updates/overwrites Centralized Configuration forms with the updated (manually) configuration that is present in ar.cfg.

          Jun 30, 2015 02:14
        1. Prachi Kalyani


          The changes for Approval Server from ar.cfg file is reflected in Centralized Configuration forms after 30 seconds.

          There is a slight change in way plugin server handles configuration change made in its .xml file. The data from file is transferred to Centralized Configuration forms only after the plugin server is restarted.

          So, if file is changed, the configuration is loaded into Centralized Configuration forms only after the restart, whereas, if the Centralized Configuration form is changed, the plugin server file is updated after 30 seconds.




          Jun 30, 2015 03:52