Best practice for raising an Identity Platform ticket with ForgeRock Support

Overview

• Checking your product versions are supported
• Raising a ticket
• A ticket or a call?
• Ticket priorities
• What should I include in my Support Ticket?
• Reopening a ticket in Solved or Closed status
• Diagnostic logs

Checking your product versions are supported

ForgeRock supports customers using the versions and platforms specified in the product Release Notes and End of Service Life (EOSL) policy. Our EOSL policy and EOSL dates are detailed in ForgeRock End of Service Life (EOSL) Policy and EOSL Dates | AM, DS and IDM and ForgeRock Product Lifecycle and Support Policy, and EOSL Dates | IG and Agents.

Support can only be offered on versions of the products that remain within the contracted EOSL dates.

Raising a ticket

Tickets can be raised whenever you need our assistance; here are some examples of when it is appropriate to open a ticket (but not limited to):

• Suspected bugs or problems with ForgeRock software.
• Requests for assistance (please look at the documentation and Knowledge Base first wherever possible).

You can raise a ticket using Backstage our Customer Support Portal that provides one stop access to ForgeRock services. This link shows all currently open support tickets and allows you to raise a new one by clicking New Ticket.

What information should I provide?

When submitting a Support ticket, you should provide a detailed use case and problem statement with the following: Name and version of the product, platforms, reproducible steps, changes made to the system or environment prior to the issue, exact error messages, logs etc. See What should I include in my Support Ticket for further guidance. This will allow us to properly identify and diagnose your technical issue and speed up response and resolution of the ticket. Lack of this information could cause delay in solving your issue.

Issue tracking

For issue tracking purposes please submit a separate support ticket for each incident. This also allows us to better focus on the new issue and not mix vital information which can delay time to resolution.

Can my team see all the ticket updates?

Yes. You can cc individual users on a support ticket as needed. Navigate to: Tickets, select the required ticket and add any users who should receive updates to the CCs field.

If you would like individuals or your entire team included on all ticket updates, please let us know through a support ticket so we can set up permissions correctly to allow your team members to view and comment on all tickets.

What can I do if I am having issues accessing Backstage?

If you are having any issues using the system or have any queries about your subscription, you can email: backstagehelp@forgerock.com

A ticket or a call?

The ticket is the single best point of reference

The most efficient model of supporting you and resolving an issue is through our ticketing system on Backstage. This is because through a ticket we can:

• Analyze technical detail accurately that is only possible to see when written down, for example, configuration files or architecture diagrams.
• Take uploaded logs and examine these against the product codebase.
• Get several technical resources to review the details, including our support, engineering and management teams.
• Attempt to reproduce your issue in our test environments.
• Follow a logical path of troubleshooting.
• Keep a record of the actions taken, for accountability and auditing purposes.
• Progress multiple issues asynchronously.
• If required, hand over urgent issues to the next timezone.

Phone calls and web conferences are generally not optimal, especially in the early stages of troubleshooting and diagnosis. However, they can be useful in some circumstances. 

What if a call is needed?

In the event that a call is needed, we will set up a time-limited web conference and send you the link. If it is not urgent, we will schedule this for the following day or later in the week (as appropriate).

• We will agree an agenda at the start of the call (or in the ticket prior to the meeting if there is time) and determine next steps at the end of the call.
• It should be determined before the call who the most relevant person(s) from your organization and ForgeRock are to join the meeting to help with a successful resolution. Uncontrolled calls with large audiences are not productive.
• We will attempt to determine the full extent of the issue and offer a workaround if possible.
• The support/sustaining engineer will not make changes to your systems. We operate a hands-off approach, allowing you to make changes once you have deemed them appropriate.
• Notes will be made about the content of the call and documented in the appropriate support ticket.

What should you do prior to a call?

• You should make a full backup of your system.
• You should provide all the troubleshooting information pertinent to the case, that is, problem description, debug logs, infrastructure details, context of the issue etc. See What should I include in my Support Ticket for further guidance.
• You should read the appropriate documentation and Knowledge Base around the topic area.

Ticket priorities

There are four priorities for tickets in this system:

1. Urgent (P1) - there is a production down issue affecting all or most end users. No workaround is available. Does not include development issues, problems in staging environments or ForgeRock products running on non-supported versions or platforms.
2. High (P2) - there is a major feature or function that is not working correctly in production and it is blocking full use of the system but other features are operational, or there is a major feature or function that is not working correctly in a pre-production environment that could delay deployment or upgrade. This priority can also be used for root cause analysis on a production failure where service has been restored.
3. Normal (P3) - there is a minor issue or non-production issue impacting usability or administration of the system but a workaround is available and major functionality is working correctly.
4. Low (P4) - there is intermittent or unexpected behavior observed which suggests a possible problem or a request for enhancement (RFE). Low or no user impact.

These priorities should be used with prudence and only be selected if they meet your situation. Our aim is to always respond and progress your requests in a timely manner.

Why did you change the priority of my ticket? 

When you raise an Urgent ticket and the production system operation is restored, we will normally change it to High. We recognize that even after the service is back to normal there will be some focus on finding the root cause to regain confidence that the same thing will not happen again.

There are a few situations where we might downgrade a ticket without asking, for instance, installation issues or questions that have been raised as High or Urgent priority but where it is clear from the context that the wrong priority has been selected.

Multiple Tickets

If you have multiple tickets open simultaneously, please help us to prioritize them for you by using the appropriate level for all your tickets. Using High or Urgent for all tickets will dilute the focus on which tickets require the highest attention. Our primary focus will be to help you get the system back up and running; root cause analysis will then follow. For issues outside the scope of Support, we may refer you to Deployment Support Services, or we can introduce you to one of our local partners.

Can I request to change the priority of a ticket? 

Yes. You can submit a change request by clicking on the 'Change Priority' button, located in the Comments section of the ticket form.

What should I include in my Support Ticket?

Ticket Subject

Ensure the Ticket subject contains a clear problem summary. Please identify which product and component in the stack you are having issues with and what the problem is.

For example, "Users can't log in" isn't particularly useful, whereas "AM login page returns 'invalid domain' error for users in another region" is much more descriptive and gives us immediate context and scale of the problem.

Problem Description

Include the following details where possible to ensure we fully understand your issue and can start troubleshooting immediately:

• Detailed problem description with product version and steps to reproduce the issue. Some issues are version specific, knowing your version will help us focus on relevant issues only.
  • Include any error messages that are appearing on the console or in the logs. Refer to the Diagnostic logs section below for information on the logs you should collect depending on the type of issue you are experiencing.
  • Explain in as much detail as possible what you were doing at the time of receiving the errors, include any URLs relevant to the issue.
• Include the type and version of the Web application container / Web server you are using.
• Is the problem seen in Dev? QA? or Production?
• Please provide the use case. What are you trying to achieve, what are the expected results? (Provide use case details).
• What led you to try this approach? (Provide links to any documentation or KB articles you followed).
• Date and time at which the issue was first seen?
• Has this worked in the past?
  • If yes, what has recently changed prior to the issue being seen? (For example, new install, upgrade, configuration, applications, introduced load balancer, SSL, replication, increased user load, new SP or IdP etc.)
• How frequently is the issue seen? (Is the issue seen during specific times or is it intermittent?)
• Can you reproduce the issue at will?
  • If yes, please provide the exact timestamp(s) of when the issue was reproduced so we can correlate this with the logs.
  • Provide reproducible steps.
• Have any patches been applied to the system?
• What troubleshooting steps and debugging have already been tried?
• Provide an updated deployment diagram if applicable. Ensure to include any load balancers, proxies and firewalls.
• Assign an appropriate priority to the ticket. See Ticket priorities for further details.

Reopening a ticket in Solved or Closed status

When tickets are resolved they are set to a status of solved. After they have maintained their solved status for 2 weeks they are automatically moved to closed.

• Solved tickets can be reopened and updated. Tickets marked as solved can be reset to an open status by either responding in the ticket on Backstage or replying to an email notification that was sent from the solved ticket that you want to reopen.
• Closed tickets cannot be altered or reopened. However, you can create a follow-up request by email. This creates a new ticket that references the closed request and includes a link back to the original ticket history where support can review previous comments. Alternatively you can open a new ticket via Backstage.
• Follow up tickets can be created by replying to an email notification that was sent from the closed ticket that you want to create a follow-up for.

Diagnostic logs

This section provides information on how to collect the necessary data needed for troubleshooting depending on the product and type of issue you are experiencing. Please note most issues require adjusting the logging level in order to get more detailed log data as described in the references below.

Access Management and Agents

• How do I collect all the data required for troubleshooting AM and Agents (All versions)? - this article provides a matrix of what data to collect based on issue type.
• How do I record troubleshooting information in AM (All versions)? - this tool automates the collection of troubleshooting information for AM, including all log files.
• Best practice for recording troubleshooting information in AM (All versions) - this article provides a Postman collection for recording troubleshooting information.
• Troubleshooting AM and Agents - this book provides information on troubleshooting various issues in AM, including collecting useful troubleshooting information such as logs, heap dumps and stack traces.

Directory Services

• How do I use the Support Extract tool in DS 6.5.x and 7.x to capture troubleshooting data? - this tool automates the collection of troubleshooting information for DS, including all log files.
• Troubleshooting DS - this book provides information on troubleshooting various issues in DS, including collecting useful troubleshooting information such as heap dumps and stack traces.

Identity Management

• Troubleshooting IDM - this book provides information on troubleshooting various issues in IDM, including collecting useful troubleshooting information such as logs, heap dumps and stack traces.

Identity Gateway

• How do I generate more detailed debug logs to diagnose an issue in IG (All versions)? - this article provides information on collecting IG debug logs.
• Troubleshooting IG - this book provides information on troubleshooting various issues in IG, including collecting useful troubleshooting information such as logs, heap dumps and stack traces.

See Also

Getting started with ForgeRock Support (Identity Platform)

Sending troubleshooting data to ForgeRock Support for analysis

Uploading Files