Click Submit New Case on the BMC Support Central Case Management quick access pane to create a case. For detailed information, see Create a new case.

Watch the YouTube video about how to create a support case

BMC Electronic Product Distribution (EPD) is the main interface for downloading products, patches, and updates from BMC.com. You must be logged into Support Central to access the EPD. Under the Downloads & Products, click Downloads. 

For detailed information, see Use the Product Downloads tool.

Watch the YouTube video for an overview of BMC Electronic Product Distribution (EPD)

Because BMC Helix services are cloud-based, customers can connect to them via any supported web browser. BMC is fully responsible for the availability of the services.

For detailed information, see Service levels and support hours.

While we do our best to design our Support Central resources so you can easily track down the answers to your questions, you can always reach out to our Customer Care team directly, for one-on-one support.

For detailed information, see Contact BMC.

Lifecycle Requests are operations that customers can submit as part of their BMC Helix subscription ranging from configuration updates, administrative set up, among other activities. These may be requested at any time throughout your service term and the availability of Lifecycle Requests may differ depending on your lifecycle stage (ie. Onboarding, Live) and your data center.   

For detailed information, see Lifecycle-Requests. For any Lifecycle Requests you may not see in the available options, please submit a Change Request (RFC) or Support Case.     

Watch the YouTube video to learn how to create a Lifecycle Request (4:20s)

You use the request for change (RFC) process to request changes to your environments — for example, to request promotions from the development/tailoring environment to the QA environment, and from the QA environment to the production environment. 

The RFC form lists all of the information that the change submitter (BMC SaaS Operations, or customer or project teams, on behalf of a customer) must provide to fulfill the change request. It requires enough information in order to effectively plan, manage, track, and fulfill an RFC. 

For detailed information, see Request-for-Change-process. 

Customer-authorized change approvers will be contacted via email by BMC SaaS Operations to request authorization and in-application on Support Central > Case Management under Approve a Change.  

Watch the YouTube video to learn how to approve a RFC (7.11)

The BMC SaaS Operations team performs regular application and infrastructure maintenance to your non-production and production environments. 

For detailed information, see Maintenance-windows.

BMC has a highly skilled team dedicated to managing and executing service update projects. The Helix services are kept up to date with the latest enhancements, fixes, and features as each service reach production readiness.

For detailed information, see BMC-Helix-Upgrade-policy.

BMC provides services to hundreds of customers worldwide. These customers are across multiple industries and include many global customers with complex security, compliance, integration, and performance requirements.

Yes. BMC SaaS Operations monitors all customer environments. For more information, see System-monitoring. 

In Support Central, select the Service Status Dashboard option within the Case Management view.

BMC frequently resolves potential issues before they are customer-impacting. Based on incident severity, issues are addressed so as to provide restoration of the service as soon as possible. If you are experiencing an issue, promptly submit an incident to BMC Support. For more information, see the BMC-Helix-Incident-Response-policy. 

Versioning has been updated to include four major releases per year based on the seasons: 

• year.Winter (also known as year.1)
• year.Spring (also known as year.2)
• year.Summer (also known as year.3)
• year.Fall (also known as year.4)

A minor release that occurs between major releases will be called major-release.minor-release. For example, 22.2.01 would represent the first minor release after the spring release. 

For more information, see BMC-Helix-Upgrade-policy.

Yes. You will have an opportunity in user acceptance testing to determine if those customizations still make sense. If they do not, they can be disabled so that the out-of-the-box workflow is executed instead.  For more information, see BMC-Helix-ITSM-Customization-policy.

BMC SaaS Operations supports minor adjustments made to customizations as a part of the service update process. If a significant change to logic is required, you should work with BMC SaaS Operations to understand the impact. If a major change to the customized code is required, you can choose to implement it on an "as-is" basis, implement a small workaround, or disable the customized code. Any major changes to the customization can then be scheduled for implementation after the service update through the regular change control process. For more information, see BMC-Helix-Upgrade-policy.

At present, BMC Helix does not support 2-way SSL (also known as mutual TLS, client certificate authentication) for the inbound REST API/ Web Service traffic. However, we are looking to provide this option in the near future.

The SMTP incoming and delivery servers are BMC-managed infrastructure. The only connectivity to external cloud allowed is Microsoft Exchange Web Services (EWS). Other external connections are considered to be prohibited. For the avoidance of doubt, the external cloud and on-premises infrastructure configuration, administrative settings, servers, logs, and your network environments are managed outside of BMC, therefore out of scope for BMC Support. 

 Custom headers are not supported.

The customer is responsible for obtaining and managing the client certificates for third-party integrations with the BMC Helix ITSM. The BMC SaaS Operations team will assist with the certificate installation into their BMC Helix environment.

For more information on obtaining and managing the client certificates, see KB Article 000251885.

Masquerading outbound emails with a sender address on behalf of the customer’s domain or third-party network is allowed only if the following conditions are met:

• The customer or third-party must take steps to trust the BMC Helix SMTP servers to send emails on their behalf. This includes adding our SMTP server public IP addresses to their published Sender Policy Framework (SPF) record. 
• The customer or third-party must modify their email filters to accept the masqueraded email from BMC SMTP servers without flagging it as unsolicited.
• The customer or third-party must provide evidence showing the above steps have been addressed.

The following table lists the hosts for each region that need to be added to the SPF record. You only need to add the location that corresponds to your service location in the SPF record.

For more information, see Planning-email-integration-with-BMC-Helix-services.

Next Action: Raise a support case by providing the evidence that the above conditions are met. BMC will approve the masquerading configuration and move forward with the implementation.

Access to the mid-tier configuration page is restricted for security reasons. However, the customer can perform the cache flush on non-production using alternative steps.

For more information, see BMC Helix ITSM Administrator Permissions policy.

Use this procedure if you need to encrypt a file within BMC Helix ITSM and transfer it over the SFTP to be used later. For example, you can encrypt a report extracted after processing data by an AI job. 

The following steps describe the process of decrypting a GPG-encrypted file in BMC Helix ITSM:

1. Generate a key using a GPG program.
   The steps shown in the following screenshot demonstrates how to generate a key using GPG in Linux. Follow your organization's security guidelines to meet the security requirements.
   

1. Export the public key using the GPG command.
   Example:
   gpg --output GPGKey_public.asc --armor --export GPGKey
2. Raise a support case to install the public key into your environment. The BMC Helix Operations team will upload the key into the AR System File form, ensuring that the key is uploaded every time the server is restarted.
   
   It is your responsibility to track the key expiry and renewal process. In the event that the key expires and needs to be regenerated, you must submit a support case to upload the renewed key.
3. Design an Atrium Integrator job that uses the Shell Script step to encrypt the GPG-encrypted file.
   A sample job is shown:
   
   The following screenshot shows a sample script (TrustKey Shell Script step):
   
   The following screen shot shows a sample script (Encrypt Shell Script step):
   

The encrypted file is available under the directory /opt/bmc/ars/data/FromOnDemand as per the sample script above. The sample script uses hard coded values. Replace with the variable as per the requirement.

If you need to upload an encrypted file to the BMC Helix ITSM, you can encrypt the file using a GPG program and then process it in BMC Helix environments.

The following steps describe the process of decrypting a GPG-encrypted file in BMC Helix ITSM:

1. Generate a key using a GPG program.
   The steps shown in the following screenshot demonstrates how to generate a key using GPG in Linux. Follow your organization's security guidelines to meet the security requirements.
   

1. Export the Private key using the following command.
   For example:
   

1. Raise a support case to install the private key into your environment. The BMC Helix Operations team will upload the key into the AR System File form, ensuring that the key is uploaded every time the server is restarted.
   
   It is your responsibility to track the key expiry and renewal process. In the event that the key expires and needs to be regenerated, you must submit a support case to upload the renewed key.
2. Design an Atrium Integrator job to download the GPG-encrypted file from the BMC Helix SFTP server to the local AR System directory. Use the Get a file with SFTP step to upload the file.
   File Path to be used to download the GPG-encrypted file: /opt/bmc/ars/data/ToOnDemand
3. Design an Atrium Integrator job that uses the Shell step to decrypt the GPG-encrypted file. 
   A sample job is shown:
   
   
   

The following screenshot shows a sample script:

Important: In GPG command, the escape character for special characters is the backslash "\". If you need to use a special character in a command or in a passphrase, you can use the backslash to escape it and prevent it from being interpreted as a command or separator.

BMC plans the service update and shares a schedule with you. The service update schedules are shared through email notifications 7 days prior to the update of your nonproduction environments and 21 days prior to the update of your production environment.

The service update schedule will be visible to you on the Change calendar 48 hours prior to the start of the update.

You can also request a service update. For more information, see Requesting a service update.

BMC plans and schedules the service updates. The updates are pushed in the form of automated rollouts to your environments with zero downtime. However, due to some reason, if you do not want to update your environment as scheduled, you can opt out of the scheduled service update and request a service update later. 

BMC does not recommend that you to opt out of a scheduled service update.

It takes about 24 hours to update each environment (Development, QA, and Production).

Based on a few factors, such as the size and complexity of your environment, it might require more than 24 hours to update your Production environment. Based on the observations made while updating your Development and QA environments, BMC will notify you of the time required to update your production environment.

Based on the region in which you are located, the service updates are scheduled to begin outside the core business hours during weekdays.

The following table lists the regions and their respective update start time: 

No, there are no prerequisites.

However, if you have any specific requests, such as a database refresh, make sure you get it done before the service update. Use the standard change request process or raise a support case (for customizations or configurations) to address any specific request.

BMC performs the service updates as frequently as required to make sure that you are on the latest version.

During the planning stage, an update schedule is shared with you. The service update schedules are shared through email notifications 7 days prior to the update of your nonproduction environments and 21 days prior to the update of your production environment. The service update schedule will be visible to you on the Change calendar 48 hours prior to the start of the update.

Yes, you can opt out of a scheduled service update.

BMC does not recommend that you opt out of a scheduled service update. However, due to some reason, if you do not want to update your environment, you can opt out of the scheduled service update.

To opt out of a scheduled service update, use the Support Central to submit a support case at least 4 calendar days before the scheduled service update. For more information, see Opting out of a scheduled service update.

To opt out of a scheduled service update, you must submit a support case at least 4 calendar days before the scheduled service update. 

No, BMC Helix IT Operations Management services are not updated during the service update. Currently, only BMC Helix IT Service Management services are updated during the service update.

In preparation for your zero-downtime service updates, BMC performs pre-checks and always start with Development and/or QA environments. Any fixes for regressions reported on your lower environments will be applied to Production.

In the case of a failure during the zero-downtime service update window, BMC will actively investigate and resolve the issues in a timely manner, with the goal of preventing any delays.

If you require a rollback plan for service updates, the rollback process encompasses a full database restore from a backup that you have requested, or taken, prior to the start of the change window. Any data generated within your Helix applications from the time the backup was taken to when the database restore happens will not be reflected post database restore.  

Please note performing rollbacks may require downtime for your service update. End users may not be able to access your service during the entirety of the service update change window (typically 24-hours window). 

It takes about 24 hours to update each environment (Development, QA, and Production).

The following components are included in the service update:

• BMC Helix ITSM
• BMC Helix Smart IT
• BMC Helix CMDB
• BMC Helix Digital Workplace Basic
• BMC Helix Digital Workplace Advanced
• BMC Helix Innovation Suite
• BMC Helix Innovation Suite Apps
• BMC Helix Action Request System
• BMC Helix Multi-Cloud Broker
• BMC Helix Business Workflows
   

During the update of your environments (Development, QA, and Production), you can perform all end-user operations. However, admin user operations, including metadata operations, are not allowed.

For more information, see Zero-downtime (ZDT) upgrade for BMC Helix Innovation Suite and applications

Your Development and QA environments might be unavailable for 30 minutes throughout the update window. However, your Production environment will be fully available.

At the end of each environment update, BMC performs basic sanity checks (such as availability of URLs, log in and log out). 

We recommend that you use your discretion to decide the test cases to test your environments. To accommodate testing during the update window, BMC has set aside a rest period of one week between the update of your environments.

For example, after BMC updates your Development environment, you have one week to test your Development environment before BMC begins the update of your QA environment.

You can take one week to test each of your environments. 

At the end of each environment update, BMC has set aside a week before it begins the update of the next environment. You can use this time to test your environment and reach out to the BMC Support team if you encounter any issues. 

For example, after BMC updates your Development environment, you have one week to test your Development environment before BMC begins the update of your QA environment.

An opt-out request allows you to skip a scheduled General Update (GU) from BMC for a particular month. This might be necessary if the updates conflict with ongoing migration, onboarding processes, or other critical activities. You can track these updates via their support central release calendar and opt out if needed.

To submit an opt-out request, create a ticket with BMC Support at least one week before the scheduled GU update. Your ticket should include a valid reason or justification for the request.

Note that this opt-out will apply to all ITSM environments, so it's essential to plan accordingly. It is important all three environments have the same version to avoid any issues with DB backup Restore/Refresh during onboarding migration project activities.

Syntax Example: Please Opt Out <CustomerName> <Customer ServiceName> for <Month> as this is Onboarding project with migration activities that will have an impact

Case Example to log to Support: Please Opt Out <Perfect Customer> <perfc-dev, prefc-qa, perfc> for month if June as this is Onboarding project with migration activities that will have an impact

Opt-out requests can be submitted by:

• Customers
• Partners
• Professional Services

Yes, you can opt out for more than one month's GU updates. For each additional month, a new case must be submitted based on the schedule.

Opt-outs are approved on a per-month basis, with each customer being allowed to opt out of one month's GU cycle.

Note: BMC generally does not recommend opting out of updates, as they are crucial for maintaining the latest versions and ensuring system stability.

Use BMC Support Central portal, which requires registration. 

Access to the BMC Support Central portal first requires registration through BMC Support Central. You will log in using the credentials you set up during that registration process.  Your username is usually your employer-provided email address.

To register for access to the portal, see the BMC Support Central User Guide. 

If you are having trouble accessing either portal, contact your Customer Success Specialist or have a co-worker submit a support case on your behalf. You may also initiate a live chat (during business hours) from the BMC Support Central site.

BMC Support Central is available via a desktop application only.

See Change-documentation for a complete list of the information you must provide when submitting a change within Support Central. Failure to provide the required information will result in scheduling delays for your request.

Scheduling is based on the date and time you request from the Requested Window Start Date and Requested Window Start Time fields. If there are any conflicts or concerns with these inputs, BMC SaaS Operations will contact you. BMC recommends a minimum of 72 hours notice for RFC scheduling.

Within BMC Support Central, you may cancel the case by opening it and selecting the Cancel button.

If you are using BMC Support Central, you have to state the related request in plain text. 

No. Email communication will continue, with the added benefit of communication through the RFC request within the portal.

No. Although you may summarize the type of change in the Summary field, BMC SaaS Operations actually determines the type of change and categorizes it in the internal change management system. Customer input is not needed for this field.

No. BMC allows you to opt-out of CRB review and approval, assuming the customization was designed and developed using BMC recommended best practice guidelines. See BMC Helix Customization policy for more information.

Yes. Customers may add a comment to the RFC form requesting an adjustment to the date and time originally requested.

No. Regardless of whether or not you have CRB approval, it is your responsibility to maintain your customizations on an ongoing basis. For additional information, see the BMC Helix Customization policy.

BMC will first review the RFC inputs for completeness. Every effort will be made to schedule the requested change based on the date and time you requested. If there are any issues with the RFC scheduling, BMC SaaS Operations will contact you with a suggested alternate date and time. You will then have the option to accept or reject the proposed change window. If you need to reject it for any reason, please provide a reason for a rejection or another alternate date and time that works for you.

You may add a comment to the original RFC request and the assigned Support Manager can contact you.

In BMC Support Central > Case Management and select the Change Calendar option to see your scheduled change in the calendar view. If the RFC is not yet scheduled, you can view it under Case Management Details menu. This menu displays all requests that you have submitted, including incidents, service requests, and change requests. Various filtering options are available from the list view.

In BMC Support Central > Case Management, select Change Calendar. This option displays a calendar view of all scheduled (past 90 days plus future) changes.

1. From the Support Central, select Case Management > Lifecycle Requests.
2. Select a -dev environment.
3. Under Lifecycle Requests, select Database Backup.
4. Based on the requirements, provide one of the following file suffixes when raising the service request:
   • FIXES_ONLY
   • FIXES_AND_DATA
   • FULL_FIXES_DATA_DELTA
   • HOTFIX_PHASE

For more information, see Database-backups-and-restores.

1. From the Support Central, select Case Management > Lifecycle Requests.
2. Select a -dev environment.
3. Under Lifecycle Requests, select Database Backup.

For more information, see Database-backups-and-restores.

1. From the Support Central, select Case Management > Lifecycle Requests.
2. Select a -dev environment.
3. Under Lifecycle Requests, select Stop/Start Applications.

For more information, see Stop-Start-Applications.