Demystifying AR System Installation: A Deep Dive for IT Professionals

In the intricate world of IT Service Management (ITSM), few platforms have carved out a niche as prominent as BMC Remedy Action Request System (ARS). For seasoned professionals and newcomers alike, understanding the nuances of AR System installation is paramount. This article aims to demystify the process, offering a comprehensive guide that blends technical details with practical advice, making it relevant for your daily tasks and future career growth.

Understanding the Foundation: What is “Remedy AR System”?

Before diving into the installation, let’s clarify a common point of confusion. The terms “Remedy” and “Action Request System” are often used interchangeably, and for good reason. The original “Action Request System” was developed by the “Remedy Corporation.” Over time, through acquisitions and rebranding, it evolved into what we now know as BMC Remedy Action Request System. This historical context is useful, but for installation and administration, we’re primarily concerned with the current BMC offering.

Here’s a quick glance at its lineage:

• 1991: The Action Request System is born.
• 2002: BMC Software acquires the technology.
• 2003 onwards: Operates under the BMC umbrella, evolving with each release.

The Anatomy of AR System: Architecture Explained

A robust installation hinges on a solid understanding of the AR System’s architecture. It’s typically a multi-tiered system designed for scalability, flexibility, and manageability.

• Client Tier: This is where users interact with AR System. It includes applications that present information and collect input. Think of the BMC Remedy User tool or even Developer Studio itself – these are your clients. Migration and development tools also reside here.
• Mid Tier: This is the web-facing component. It runs on a web server and translates client requests from browsers into a format the AR System server can understand. It also handles web service requests and serves as the bridge for web-based application access. Key components include translation logic, response interpretation, and server-side process execution for web clients.
• Server Tier: The heart of AR System. The AR System server orchestrates workflow processes, manages database access, and hosts essential server-side applications like the Approval Server, Email Engine, and Flashboards server. It also integrates with plug-in servers (C and Java) for extended functionality.
• Data Tier: This is where your data lives. It comprises database servers (e.g., Oracle, SQL Server, DB2) and any other data sources that the AR System server needs to access. The database server is the engine for storing and retrieving all your crucial ITSM data.

For installation purposes, understanding these tiers helps in planning your server infrastructure, network configurations, and security settings.

Choosing Your Platform: OS and Database Considerations

The choice of operating system and database platform is a critical decision that impacts performance, scalability, and ongoing administration. BMC offers flexibility, allowing you to tailor the environment to your existing infrastructure.

General Recommendation: Align your AR System platform with what your IT staff is most comfortable managing. If your organization is predominantly a Windows shop, sticking with Windows and SQL Server often simplifies administration. Conversely, a UNIX-centric environment might favor Solaris or AIX with Oracle.

Here are some of the most common and popular configurations:

1. Windows / SQL Server
2. Windows / Oracle
3. Solaris / Oracle
4. HP-UX / Oracle
5. AIX / DB2
6. AIX / Oracle
7. Red Hat / Oracle

Larger enterprises often lean towards UNIX for its robustness, while mid-sized to smaller companies might find Windows / SQL Server a more cost-effective and manageable solution. However, exceptions abound, so assess your specific needs.

The Installation Journey: Key Tables and Configuration Files

When you initiate an AR System installation, a specific sequence of database tables is created to form the foundational structure. Knowing this sequence can be helpful for troubleshooting or understanding database integrity.

The tables are created in this order:

1. control
2. controlRecordIds
3. arschema
4. schema_index
5. schema_group_ids

Configuration is managed primarily through configuration files. On Windows, the crucial file is ar.cfg (and arinstall.cfg during installation). This file holds AR System server configuration settings and is dynamically generated during the server installation. It’s where critical information, including passwords (though this is generally discouraged for direct storage, BMC’s internal mechanisms handle it securely), is managed.

Database table names for core workflow objects are typically prefixed with dbo. (depending on your database setup):

• Active Links: dbo.actlink and dbo.actlink_ (with action name appended)
• Filters: dbo.filter and dbo.filter_
• Escalations: dbo.escalation

Licensing: Understanding Your User Access

AR System employs various license types to manage user access and control costs. Understanding these is crucial for capacity planning and ensuring your users can work efficiently.

Fixed Licenses: These are assigned to individual users and are always available to them. They are generally more expensive but provide guaranteed access.

Floating Licenses: These are a shared pool of licenses. A user “checks out” a floating license when they log in and “checks it back in” when they log out. This is a cost-effective solution for environments with shift work or users who don’t require 24/7 access.

The Logic: If you have 5 fixed licenses and 5 floating licenses, an unlimited number of users can log in. However, only a maximum of 10 concurrent users will have an active license (5 fixed + 5 floating). Any additional users will be in a queue, waiting for a license to become available. This is why floating licenses are often preferred for shift-based operations.

Core Concepts: Forms, Fields, and Menus

AR System is built around forms, which represent data structures, and fields, which are the individual data elements within those forms. Menus provide a way to offer predefined choices to users.

Types of Forms

• Regular Forms: Standard forms used for data entry and display.
• View Forms: Provide a read-only representation of data, often used for reporting or specialized UIs.
• Join Forms: Combine data from two or more regular forms based on defined criteria. This allows users to see related information without creating redundant data. BMC generally recommends joining up to 6 forms, though more are technically possible.
• Vendor Forms: Act as gateways to external data sources, allowing AR System to access and present data from other systems without replicating it.
• Archive Forms: Used for historical data storage to improve performance on active forms.
• Audit Forms: Track changes to records for compliance and auditing purposes.

The Form ID plays a role in how AR System categorizes these:

• Regular: 1
• Display: 4
• Join: 2
• View: 3
• Vendor: 5

Field Types and Characteristics

• Character vs. Diary Fields: Character fields are for standard alphanumeric input and can be overwritten. Diary fields, on the other hand, are designed to append data. Each entry in a diary field includes a timestamp, the user who made the entry, and the data itself, preserving a complete history of changes. This makes diary fields invaluable for audit trails.
• Attachment Fields: These allow users to attach files to records. The data is stored in binary tables, and you can configure maximum file sizes.
• Attachment Pool: A more advanced mechanism for managing attachments, often used for larger volumes or specific integration scenarios.

Menus: Static and Dynamic

Menus offer dropdown lists of options to users. They can be:

• Static: Predefined lists of choices.
• Dynamic: Populated based on data from other forms, SQL queries, or external files.

Refresh Rate: For dynamic menus, the refresh rate is crucial. Options include ‘On Connect’, ‘On Open’, and ‘On 15 Minute Interval’. Choosing the right refresh rate balances data currency with system performance. ‘On Open’ can be resource-intensive, while ‘On 15 Minute Interval’ offers a good compromise. Character menus are static and do not require refreshing.

Workflow: The Engine of Automation

Workflow is the backbone of AR System, automating business processes. It’s defined by Active Links, Filters, and Escalations.

• Active Links: These are client-side actions triggered by user interactions within the current form window (e.g., clicking a button, selecting a value). They can display messages, change field appearances, or even push data to other forms. Active links cannot be triggered via API calls directly; they are purely user-interface driven. Duplicate names are handled by appending _c.
• Filters: These are server-side workflow components that execute in response to events happening at the database record level (e.g., submitting, modifying, or deleting a record). They are responsible for enforcing business rules, updating related data, and performing complex actions. Filters check form transactions as they undergo server processing.
• Escalations: Similar to filters, but they are time-based. Escalations check requests in the database at predetermined intervals to trigger actions (e.g., automatically reassigning an overdue ticket, sending a reminder notification).

These workflow objects interact with forms, fields, and can even trigger other workflow components, creating powerful automation chains.

Security and Access Control: Groups and Permissions

Managing user access is a cornerstone of AR System administration. This is primarily achieved through Groups and Permissions.

Types of Groups

• Explicit Groups: Users are manually assigned to these groups. When a user is part of an explicit group, they inherit all permissions granted to that group. Examples include ‘admin’, ‘sub-admin’, ‘customize’. Explicit groups are server-specific; migrating objects to a new server might require remapping group permissions.
• Implicit Groups: Users are automatically members of these groups based on specific conditions or circumstances, often derived from field values within a request. You don’t directly assign users to them. Examples include ‘Public’, ‘Assignee’, ‘Submitter’. Dynamic groups also fall under this category.

Group IDs and Ranges

Each group has a unique integer ID. The ranges are significant:

• 0-1000: AR System and current AR System applications.
• 1000-13004 & 13007-14999: Regular and computed groups.
• 13005-13006: CMDB groups.
• 14999-59999: For future AR System applications.
• 60000-60999: Dynamic groups.

Overlay Groups

Overlay groups provide granular control over customization. When a user is assigned to an overlay group:

• Field Set to 1: Restricted to working on overlay and custom mode objects in Developer Studio (Best Practice Customization mode).
• Field Set to 0: Restricted to working on base mode objects (Base Developer mode).
• Field Cleared: No restrictions; can work on base, overlay, or custom objects.

This feature is crucial for managing customizations, especially in multi-developer environments, and minimizing conflicts during upgrades.

Permissions: Forms, Rows, and Columns

Permissions can be applied at various levels:

• Form Permissions: Granting read, change, or no access to entire forms.
• Row-Level Permissions: Controlling access to specific records based on group membership or field values.
• Field Permissions: Restricting access to specific fields within a form (e.g., read-only, hidden).

Advanced Concepts and Troubleshooting

Beyond the core installation and configuration, several advanced topics and common troubleshooting areas are worth noting.

Core Fields and Data Storage

Every request in AR System has 9 core fields that are fundamental to its operation:

1. Request ID
2. Submitter
3. Create Date
4. Assigned To
5. Last Modified By
6. Modified Date
7. Status
8. SD (Short Description)
9. Status History (Hidden, Field ID 15)

Date and Time Storage: AR System stores date/time values as the integer number of seconds since 00:00:00 GMT on January 1, 1970 (the Unix epoch). This format supports dates up to January 18, 2038. For example, to convert “current date” to a value, it’s the number of seconds elapsed since the epoch.

Garbage Collection

The AR System server uses a garbage collector to manage memory. The Xincgc parameter refers to an incremental garbage collector, which helps in optimizing memory usage and reducing performance overhead.

Remote Procedure Calls (RPC)

RPC is a protocol that allows one application to request a service from another application on a different computer without having to understand the network details. In AR System, this is fundamental for communication between various components.

Version Information

To find AR System version information, navigate to the Application Properties form within BMC Remedy User or Developer Studio. This form displays comprehensive details about the installed application versions.

Installation Log Files

During installation, logs are crucial for diagnostics. The primary installation log file can typically be found at: C:\Users\Administrator\AppData\Local\Temp\1\arsystem_install_log.txt.

Port Numbers

Knowing default port numbers is essential for network configuration and firewall rules:

• DB2: 50,000
• Oracle: 1521
• SQL Server: 1433
• Java Plugin Port: 9999
• Flashboards: 1150 (Note: This can vary; confirmation is advised)
• SMTP: 25
• Email Engine: Varies, often configured in its own settings.
• DIS Server Port: 2000

Troubleshooting Common Issues

• User Login Issues: Check group memberships, license availability, and server connectivity. Ensure the user is added to at least ‘Struct Sub-Admin’ for Developer Studio access beyond ‘Demo’.
• Workflow Not Triggering: Verify Active Link/Filter/Escalation conditions, server processes, and client connectivity. Debugging workflow using the developer tools is key.
• Performance Problems: Analyze workflow complexity, database indexing, server resource utilization, and network latency.
• Database Connectivity: Ensure database drivers are installed, connection strings are correct, and firewall rules allow access on the configured ports.
• “No License Available” Errors: Review license assignments and usage. Consider purchasing additional licenses if demand consistently exceeds supply.

Conclusion

The installation of BMC Remedy Action Request System is more than just running an installer; it’s about laying a robust foundation for your ITSM processes. By understanding the architecture, platform choices, licensing models, core concepts like forms and workflow, and security mechanisms, you equip yourself to implement, manage, and troubleshoot AR System effectively.

This detailed guide provides a roadmap, but remember that hands-on experience, continuous learning through BMC documentation, and a strong understanding of your organization’s specific requirements are your most valuable assets. Happy installing!