Yes, please contact BMC Support.

Yes, please contact BMC Support.

Yes, please contact BMC Support.

Yes, please contact BMC Support.

Yes, please contact BMC Support.

See, Migrating PATROL Agents from TSOM to BHOM and Migrating PATROL Agents in the BMC PATROL Agent for BMC Helix Operations Management documentation.

See, BMC PATROL Agent documentation.

See, Monitoring solutions in BMC Helix Operations Management in the BMC Infrastructure Management-PATROL Repository documentation.

See, System-requirements.

Yes, we have documented an example using Squid. However, you can utilize your own forward proxy. Discuss it with your Network Administrator.

For more information, see Configuring a Squid proxy server in the BMC PATROL Agent for BMC Helix Operations Management documentation.

You can achieve high availability for the on-premises gateway by deploying it in an active-passive high availability configuration. The MinIO instance available in the BMC Helix IT Operations Management on-premises deployment is used as the backup and restore location of the on-premises gateway.

For more information, see Configuring the on-premises gateway for high availability in the BMC Helix Intelligent Integrations documentation.

Yes, for more information, see Using-custom-CA-signed-certificates.

1. Create a certificate signing request (csr) file by using OpenSSL.
2. Submit the file <your.domain.com>.csr to your CA and request a signed certificate.
3. Import the CA's reply.

Perform the following steps on the standby site:

1. To get the MinIO Ingress rule, run the following command:

   kubectl -n <namespace> get ing | grep ^minio

   <namespace> is the namespace where you deployed BMC Helix ITOM.
   Sample output:

   # kubectl -n ITOM-namespace get ing | grep ^minio
   minio                                                  <none>   serta-minio.adeonprem.bmc.com       172.20.112.175                      80      20d
   minio-api                                              <none>   serta-minio-api.adeonprem.bmc.com   172.20.112.175                      80      20d
   #
2. Create new MinIO Ingress rules for minio and minio-api.
   For example:  
    serta-minio-India.adeonprem.bmc.com 
   serta-minio-India-api.adeonprem.bmc.com
3. Use new MinIO Ingress rules to define the URL for the MinIO on the secondary site for replication.

DR requires additional storage and CPU/Memory resources for backups.
See Sizing-and-scalability-considerations for additional resources required for DR.

DR is supported from version 23.4.00, but the most recommended version is 24.2.00.

See the Sizing and scalability considerations for additional resources required for DR.
Important: The actual storage requirement depends on the stack and data. Hence, further fine-tuning might be required. 

No, NFS is not a supported storage provider for DR.
NFS does not provide the required performance support. Also, the PVC size increments are not supported for NFS-backed storage.

See Sizing-and-scalability-considerations.

Both primary and standby sites should be deployed with the same resources and sizing.
See Configuring-disaster-recovery.

It takes about 30 minutes to enable backup. This process restarts storage components such as MinIO, PostgreSQL, and VictoriaMetrics.
Though you don’t require explicit downtime, we recommend enabling the backups during low-load conditions.

DR is configured to run a single full backup in a day, and the rest will be incremental backups.
No major performance impacts were observed during backups performed in BMC’s test labs.

The first backup is a full backup and will take longer than the incremental backups. Therefore, we recommend that you enable the backups during low-load hours.

You can enable backups without a standby site, but backups will be stored on the local cluster and will not provide any protection against cluster failure. 

No. Currently, PITR is not supported by DR.

There are a few manual steps required apart from modifying the disaster-recovery.config file.
See Configuring-disaster-recovery for detailed steps.

Yes, disaster-recovery.config file serves as an input file for DR configurations.

See “To configure data backup on the primary site” in the Configuring-disaster-recovery topic.

No, currently we do not support backup of specific components.

Configuring backups for DR takes around 15-30 minutes, depending upon the cluster size.

As part of the configuration, you must provide a backup interval in hours (DR_BACKUP_INTERVAL_IN_HOUR). All the backups are scheduled based on the cron scheduling format.
For example, if you set the value of the DR_BACKUP_INTERVAL_IN_HOUR parameter to 1 hour, data backup is performed at the start of every hour according to the cron schedule (0 */1 * * *).

If your current cluster time is 2:15 P.M. on November 2, and you set the value of the DR_BACKUP_INTERVAL_IN_HOUR parameter as 1 hour

1. The first backup will occur at 3:00 P.M. This backup will be a complete data backup.
2. Subsequent backups will occur at 4.00 P.M., 5.00 P.M., 6.00 P.M., and so on. These backups will be incremental.
3. At 3:00 P.M. on November 3, a complete data backup will occur.

If a backup fails, an email gets triggered to the operator’s email ID specified during the stack deployment.
You can also find the backup status from MinIO. See the <bucket name>/<site name>/backupStatus/backup.log file for backup status and logs.

For successful backups, you will not get any notification. If a backup fails an email notification is sent to the operator’s email ID that was defined during stack deployment.

Go to the Object Browser on the MinIO console to check the data size uploaded to MinIO.  To check the actual storage utilization, go to the Monitoring tab on the MinIO console.

Yes, you can disable backups. For more information, see Configuring-disaster-recovery.

Yes, you can set the retention period in the disaster-recovery.config file. For more information, see Configuring-disaster-recovery.

Data backup is automatically disabled during an upgrade. You must enable backups after the upgrade. For more information, see Configuring-after-upgrade.

Before applying a hotfix, you must disable the data backup.

Backups may fail due to multiple reasons. Please check back.log and take appropriate action. 

See the topic Configuring-disaster-recovery.

After installing or upgrading BMC Helix ITOM on the standby site, scale down the application pods to reduce the resource requirement during unused periods. 

You must first upgrade the primary site. After completing the first full backup on the primary site, you must upgrade the standby site.

No explicit steps are required for upgrading the primary site. However, it is mandatory to disable the backups before upgrading the primary site, because an upgrade might hamper the overall performance.
For more information, see Configuring-after-upgrade.

No, it is not mandatory to keep the standby site in the scale-down mode. 
Keeping the standby site in the scale-down mode will reduce the overall requirement of resources during unused periods.

To scale up, go to helix-on-prem-deployment-manager/utilities/disaster-recovery/dr-scale and run the command ./product_scale.sh up .
To scale down, go to helix-on-prem-deployment-manager/utilities/disaster-recovery/dr-scale and run the command ./product_scale.sh down.
For more information, see Configuring-disaster-recovery.

Make sure that the secondary MinIO is reachable from the primary MinIO. Modify the minio and minio-api ingress as described in the “Replication from the primary site to the standby site” section in the Configuring-disaster-recovery topic.

See “Replication from the primary site to the standby site” in the Configuring-disaster-recovery topic.

For data replication, we leverage MinIO’s bucket replication feature because it supports replication to AWS S3.
Though it is possible to replicate the data to AWS S3, it is not explicitly tested by BMC.

A simple check would be to validate that the object count or size present on both the primary and standby sites is the same. Detailed checks can be done by using the MinIO client.

Before starting the restore process, it is important to make sure that the data is available in MinIO and that the standby site runs on the same version of BMC Helix ITOM as the primary site.
The restore process will validate the version before proceeding.

See Restoring-data-on-the-standby-site.

You don't need to perform manual scaling operations; the restore operation will handle it automatically.

No, both primary and standby sites must have the same version of BMC Helix ITOM.
If the version is different, the restore operation will not continue.

After a successful restore, you can delete data from MinIO to free up the space.

You must enable backups on the standby site after the restore is complete.

See Disaster-recovery-deployment.

Yes, for more information see Success Subscriptions.

Yes, see BMC Education Subscription Services, BMC Helix On-Premises IT Operations Management Container Deployment: Essential Subscription, and BMC Helix On-Premises IT Service Management Container Deployment: Essential Subscription

See, BMC Helix onprem installation health check tool.

High availability is achieved through Kubernetes, which uses virtual services to load balance application pods across the cluster.

High availability is enabled for all but the compact sized deployments using multiple pods for each service.

For more information about system usage profiles, see Sizing-and-scalability-considerations.

The Nginx Ingress controller is used to route requests to the appropriate services and pods within the cluster. Network load balancing is used to distribute the load of incoming requests across multiple nodes.

Where appropriate both readiness and liveness probes are defined in BMC images.

No, currently only Ingress NGINX is supported.

BMC Helix Logging is not available if you install BMC Helix ITOM version 23.2.02 or upgrade to BMC Helix ITOM 23.2.02 from an earlier version.
For an alternate method to view logs, see Why is Helix Logging not available in ITOM Deployment version 23.2.02? .

BMC provides deployment software automation and does not support Webhooks or CI/CD pipelines.

BMC does not use "latest" tags and uses versions wherever possible.

BMC software supports air-gapped deployments from a local registry which has been synchronized with the BMC containers.bmc.com.

For more information, see Setting-up-a-Harbor-registry-in-an-air-gapped-environment-and-synchronizing-it-with-BMC-DTR.

We set default requests and limits for all services. 

Yes, seeConverting PATROL Agent Pconfig rules to Policy ManagmentMigrating TSOM Infrastructure Policies to BHOM with the bhompolicymigratorMigrating PATROL Agents from TSOM to BHOMManaging BHOM with the bhomadmin toolkit

Yes, you must do it manually.

Yes, all DNS aliases must be set up before the installation and should resolve to the network load balancer.

For more information, see Load-balancer-requirements.

For local testing purposes, we have used an F5 load balancer. 
You can use your existing vendor-specific load balancer. You must make sure the DNS resolution and lookups are working fine. 

For more information, see Load-balancer-requirements.

The Static IP is a requirement for the common services and not for BMC Discovery. 
To get Static IP reach out to the in-house IT team to generate or assign for the environment.

The IP requirements are for the load balancer and the DNS. If we have a Static IP then making and maintaining configuration changes becomes less cumbersome when compared to maintaining a DHCP setup. 

See, Network-ports.

See, Network-ports. 

See, Configuration-file-settings.

See, Example-configuration-files-for-BMC-Helix-Operations-Management.

Perform these steps if you forget the encryption password or if you need to change it:

1. Delete the common/certs/secrets folder and its contents.
2. Create the secrets.txt file with new passwords.
3. Run the deployment manager again.
   Important
   If you do not delete the secrets folder and try to create a new secrets.txt file, the process fails with a message to delete the secrets folder.

See, Example-configuration-files-for-BMC-Helix-Continuous-Optimization.

See, Example-configuration-files-for-BMC-Helix-Intelligent-Automation.

Yes, we do support a single Helix portal with BMC Helix ITSM and BMC Helix ITOM.

Please raise a case with BMC Support to help you confirm requirements.

We recommend that you update default passwords for VMs, databases, and products to be compliant with your security policy to prevent any security issues. 

Yes, we do. However, if you find any subsequent security vulnerabilities, please raise a case with BMC support.

We use our own canonical container images which use a bmcuser in the majority of cases. We will not be able to align with the base container images used by customers as these can vary widely.

For data layer services (such as Kafka, Postgres, and ElasticSearch), we use Community Edition containers which include all default users and libraries. We might amend these images if we identify security exceptions but otherwise, they are unaltered.

See, Sizing-and-scalability-considerations.

Please contact the BMC Account Manager.

See, Downloading-the-deployment-manager.

No, BMC Helix ITOM does not utilize Jenkins to deploy the product.

No, we do not provide a Docker manifest for container images.

Supported versions are detailed in the product documentation. You may encounter issues with unsupported versions.