Remedy - D2P - Walk through on Deployment Payload Form Properties and Configuration

Knowledge Article

Article Number

000229693

Old Article Number

000168160

Article Type

Product/Service Description

Title

Remedy - D2P - Walk through on Deployment Payload Form Properties and Configuration - INCLUDES VIDEO

Summary

This KA talks about list of Deployment Payload Form Properties and File Configuration - INCLUDES VIDEO

Product

Remedy AR System Server

Component

Applies to

Remedy AR, ITSM 18.0x, 19.0X, 20.0X

Details

This knowledge article may contain information that does not apply to version 21.05 or later which runs in a container environment. Please refer to Article Number 000385088 for more information about troubleshooting BMC products in containers.

Overview
- D2P stands for DEV to PROD.
- For application ‘ITSM, SLM, SRM & Smart IT’, D2P packages are used as a Installer from version 1808 i.e. 9.1.06 onwards.
- To upgrade these applications to version 1808 and onwards, we have a requirement to have these at version 1805 i.e. 9.1.05, post which using D2P packages we can upgrade them.
- For Midtier, AR and Atrium, D2P packages are used for patch and hotfix and are available from 1802 i.e. 9.1.04 002 onwards.

Any D2P package consists of file type:
Add Data - .arx files which has data.
Add Packing List - Packing List which contains the names of AR objects e.g. forms and workflow
Deployment Payload - contain plugin binaries for Windows and Unix OS type along with a common zip of binaries applicable to both OS type

To upgrade ITSM using D2P, we would need:
1- Midtier, AR and Atrium to be on version 1808/1902.
2- ITSM to be on version 1805.
3- ITSM D2P package zip.
NOTE:
- ‘Add Data’ files will be SKIPPED in some cases, E.g. If the specific language pack not installed.
- Deployment Payload entry will be SKIPPED based on the OS Type, E.g. On Windows Server, Unix payload will be skipped.
- D2P zip used for deployment should not be extracted. We need to upload the zip file directly through AR System Deployment Management Console.
- To view D2P zip use 7-zip.
- Post download of the file, confirm the file size to avoid any deployment issues.

List of Deployment Forms
AR System Deployment Management Console.
AR System Monitor.
AR System Single Point Deployment Payload.
AR System Single Point Deployment Payload Status Monitor Join.

Steps to Deploy Package:
a) Download the package and confirm correct file size.
b) Security Software should not be scanning BMC Software directory. This can cause issue with Import and .bat / .sh file.
c) Import and Deploy package through AR System Deployment Management Console.
d) Post Deploy, View the package and confirm status as ‘Waiting for Utility Run’ for Deployment Payload entry type.
e) Run the arpayloaddeploymentutil.bat / .sh:

For AR System deployment: <ARSystem>/arpayloaddeploymentutil.bat / .sh
For Midtier deployment: <Midtier>/filedeployer/arpayloaddeploymentutil.bat / .sh

f) Wait for package status to change to Deployed.
g) SHARE:Application_Properties form to review application version.

(AR System, CMDB, ITSM) Pre-Deployment Checklist:
Before importing any D2P package, review below items:
1- armonitor.cfg: One entry of arfiledeployer plugin should be present.
2- arpluginsvr_config.xml: One entry of ARSYS.ARF.ARMIGRATE plugin along with all required path elements should be present.
3- ar.cfg: One Server-Plugin-Alias entry for ARSYS.ARF.ARMIGRATE
4- monitor-ARServer-guid.properties: Monitor ID from AR System Monitor form should match with the entry present in this file.
5- AR System Monitor: One entry with correct hostname for each monitor type. Delete any incorrect or duplicate entry.
6- JAVA_HOME: Should be set with valid path and should match to BMC_JAVA_HOME.

(Midtier) Pre-Deployment Checklist:
Before importing any D2P package, review below items:
1- armonitor.cfg/conf:

BMC_MIDTIER_INSTALL_HOME is the correct installation path.
(Windows only) External-Windows-Service points to the correct Tomcat service name.

2- monitor-Midtier-guid.properties: Monitor ID from AR System Monitor form should match with the entry present in this file.
3- AR System Monitor: One entry with correct hostname for each monitor type. Delete any incorrect or duplicate entry.
4- Midtier Configuration Tool: All Midtiers should be configured to your primary AR System server in File Deployer Setting page.
5- JAVA_HOME: Should be set with valid path and should match to BMC_JAVA_HOME.

AR System Deployment Management Console

- The form is used to view status of actual contain, view the package.

- Once package is imported, we can see different status of it, e.g. Importing, Ready To Deploy, Deployed...
- If in Server Group, package needs to be imported only ONCE through this form.
- All D2P packages are imported through this form.

AR System Monitor
This form has entry for each Monitor Type:
Monitor ID : Unique to each Monitor Type
Name Host of each server
Rank : Ranking order of same Monitor Type

Ranking defined here control the order of deployment based on the Monitor Type.
AR System Server Group Operation Ranking does not have any control over the Ranking defined in this form.

AR, Midtier, Smart IT will get rank pattern as below:
AR Server will always start with Rank 1 and Midtier as next order followed by Smart IT.

AR System Single Point Deployment Payload
Once package is ‘Deploy’, entries will get created in this form for each ‘Deployment Payload’ item type.
E.g. ITSM 1808, has 3 deployment payload entries.

Based on the number of payload entries, those number of AR plugin server restart will occur when deploying package.
NOTE: For deployment,
Midtier uses ‘BMC Remedy MidTier File Deployer’ service.
AR, Atrium, ITSM uses ‘AR Plugin Process’.
SLM, SRM does NOT have Deployment Payload.
Smart IT uses ‘BMC SmartIT_MyIT File Deployer’ service.

AR System Single Point Deployment Payload Status Monitor Join
Once package is ‘DEPLOY’, to monitor its status:
- VIEW the package.
- Select Deployment Payload entry.
- View Payload Status.

Option to ‘Retry Deployment’ for the Failed/Rollback entries directly from this console:
Rollback or Pending which package/server is.
This form shows which server received the signal for deployment.

List of Deployment Files:
> deployconfig.properties
> monitor-ARServer-guid.properties / monitor-Midtier-guid.properties
> ar.cfg/conf
> pluginsvr_config.xml
> armonitor.cfg/conf

deployconfig.properties
Default location is ARSystem directory in Windows and bin for Unix.
This file controls the deployment signal sent to AR Plugin Server.
Option: True – To complete deployment, need to run the arpayloaddeploymentutil.bat located under same directory.
Option: False – To complete deployment, no need to run the arpayloaddeploymentutil.bat. A signal is sent automatically by AR Server.
NOTE:
- Option FALSE is not suggested as User does not get control over the restart of plugin server as its happens auto.
- Post option change, no server restart is needed.

User-added image

monitor-ARServer-guid.properties
AR System: Default location is ARSystem directory for Windows and bin for Unix.

monitor-Midtier-guid.properties
Midtier: Located in <Midtier>/filedeployer directory.

File contains Monitor GUID which is linked to each Monitor Type. E.g. Server, Midtier, Smart IT, in AR System Monitor Form.
If GUID does not match to the entry, Deployment will not detect the hostname of the Server.
Each Monitor Type will have its own file.

NOTE: To correct the GUID:
a) Delete this file.
b) Delete the entry from AR System Monitor form.
c) Restart Server (AR, Smart IT).

Note:
If you are correcting GUID for Midtier, restart the File Deployer service:

(Windows) Restart "BMC Remedy MidTier File Deployer" Windows service.

(Linux) Run the following command: <Midtier>/filedeployer/./filedeployer restart

d) This will re-generate the file with New GUID

ar.cfg/conf
Deployment Management uses ARMIGRATE Plugin.
When package is imported, it first makes a connection to this plugin.
If able to connect, we see Success: ARMigratePlugin under Status Reason of the package (on package view).
Requirement is to have : ARMIGRATE server plugin alias defined for individual servers.
This plugin runs with main AR Java Plugin Server, so it should have the same port.

NOTE:
VIEW this status of the package post Import and post Deploy.

pluginsvr_config.xml
It should have all depended path elements for each binary.
The same plugin is defined in pluginsvr_config.xml, along with ARMIGRATE.

AR System: armonitor.cfg/conf
When arpayloaddeploymentutil.bat is executed, it calls the arfiledeployer plugin process defined in this file.

Snipped from this .bat file is:
.........
@echo Deployment Utility has started.
"%JAVA_HOME%\bin\java" - classpath arfiledeployer- %ARFILEDEPLOYER_VERSION%.jar com.bmc.arsys.filedeployer.utilities.PayloadDeploymentUtil
@echo Deployment Utility has completed. Please check the arfiledeployer.log for the status.
.........

Midtier: armonitor.cfg/conf
By default located in: <Midtier>/filedeployer/conf, make sure:
- BMC_MIDTIER_INSTALL_HOME is the correct installation path.
- (Windows only) External-Windows-Service points to the correct Tomcat service name. Ex:
External-Windows-Service: process-type = BMC:MidtierWebServer, service-name="Tomcat8.5"

or

External-Process: process-type = BMC:MidtierWebServer, start-command="net start Tomcat8.5", stop-command="net stop Tomcat8.5", status-command="<Midtier>\filedeployer\statusCheck.bat

NOTE:
JAVA_HOME should be set before running the .bat / .sh file.
AR, Atrium & ITSM uses default arfiledeployer plugin process and arpayloaddeploymentutil.bat under ARSystem.
Midtier uses arpayloaddeploymentutil.bat / .sh under <Midtier>/filedeployer .

File Deployer logging:
It should You can monitor all the deployment process using the log files:

AR System, CMDB, ITSM Deployment logging:
Logs can be found under: <ARSystem>/Arserver/Db:

armonitor.log:

This log registers the startup or shutdown signals for BMC:FileDeployer, using the RMI port.
It also registers the startup or shutdown for other components like Email Engine, Flashboard Server etc.

arfiledeployer.log

This log contains all the actions performed during the deployment:

1.- Checks all services current state / stop related services.
2.- D2P performs a backup of existent files.
3.- Extracts D2P payload.
4.- Replace all files listed in the Hotfix / Patch.
5.- Checks all services current state / starts related services.

Midtier Deployment logging:
Default location for Midtier D2P logging is: <Midtier>/filedeployer/log:

armonitor.log

This log registers the startup or shutdown signals for Midtier File Deployer service, using the RMI port (Defined in AR System Monitor form).
It also registers [BMC:MidtierWebServer] Process startup or shutdown signals.

arfiledeployer.log

This log contains all the actions performed during the deployment:

1.- Checks Tomcat current state / stop Tomcat service.
2.- D2P performs a backup of Midtier
3.- Extracts D2P package from primary AR Server.
4.- Replace all files listed in the Hotfix / Patch.
5.- Checks Tomcat current state / starts Tomcat Service

(Only Unix) fileDeployerStart.log:

This log registers the startup or shutdown signals for Midtier File Deployer and [BMC:MidtierWebServer] Process.

Deployment Configuration and Troubleshooting Document Link:
https://docs.bmc.com/docs/display/brid1902/Applying+a+deployment+package
https://docs.bmc.com/docs/display/brid1902/Troubleshooting+package+deployment+issues
https://docs.bmc.com/docs/ars91/en/viewing-the-status-of-a-binary-payload-781012225.html
https://docs.bmc.com/docs/display/ars1902/Viewing+the+status+of+a+binary+payload

Attachment(s):