System Configuration

Connecting to Control-M/Server Behind a Firewall

This procedure describes how to connect to a Control-M/Server behind a firewall by configuring ports in the ctm_menu utility and the config.dat file.

Begin

  1. From a command line on a Control-M/Server computer, type the following:

    ctm_menu

  2. Select 4 Parameter Customization.

  3. Select 1 Basic Communication and Operational Parameters.

  4. Verify that the following ports are set in the firewall rules to allow bidirectional communication:

    2 - Control-M/EM TCP/IP Port Number [1025-65535] : 2370

    4 - Configuration Agent Port Number [1025-32767] : 2369

    5 - Agent-to-Server Port Number [1025-65535] : 7005

    6 - High Availability Port Number [1025-32767] : 2368

  5. From ctm_menu, select 8 - Services Configuration and then select 2 - API-Gateway Service Configuration.

  6. Verify that the following port is set in the firewall rules to allow bidirectional communication:

    API-Gateway Port Number : 8393

Connecting to Control-M/Agent Behind a Firewall

This procedure describes how to connect to a Control-M/Agent behind a firewall by configuring ports in the ctmagcfg utility.

Begin

  1. From a command line on a Control-M/Agent computer, type the following:

    ctmagcfg

  2. Verify that the following ports are open in the firewall rules for bidirectional communication:

    • Agent-to-Server Port Number . . . : [7005]

    • Server-to-Agent Port Number . . . : [7006]

Configuring Control-M/EM Server with High-Availability or Control-M/EM Distributed Behind a Firewall

This procedure describes how to configure Control-M/EM Server components with High Availability or with a Control-M/EM Distributed behind a firewall.

Begin

  1. In the CCM, open the Control-M/EM System Parameters, and from the Advanced tab, navigate to the HostPort parameter.

    If there are additional HostPort parameters defined for each component, delete the additional HostPort parameters. In the original HostPort parameter, click Restore Default.

  2. Do the following:

    • To set the available port range for Control-M/EM except for the Gateway, select the HostPort parameter and click Add.

      Set the Value field to: <port1>-<port2> and click Save.

      • You cannot use 0 as a port number

      • The minimum range is 20

    • To set the available port range for the Gateway, select the HostPort parameter and click Add.

      Set the Value field to : <port3>-<port4>

      From the Type drop-down list, select Gateway and click Save.

      • You cannot use 0 as a port number.

      • The minimum range is 10.

      • If you have more than five Control-M/Servers, the minimum port range must be at least double the amount of Control-M/Servers.

    • To change the Thrift ports range, do the following:

      1. Open the <HOME>/ctm_em/etc/domains/communication.xml file.

      2. Navigate to the following line: <!--variable name="ListenPort" value="9090-9150" /--> and replace it with <variable name="ListenPort" value="9090-9150">

      3. Change the ports if needed.

      4. Save and close the .xml file.

    • To configure the Kafka server component behind a firewall, you must configure the Kafka server ports, as described in Connecting to an Apache Kafka Server Behind a Firewall.

  3. Recycle all Control-M/EM server components on all Control-M/EM environments including the Control-M/EM Configuration Agent.

  • If Control-M Workload Archiving is installed on the distributed Control-M/EM, see Connecting to Control-M/EM Behind a Firewall from Workload Archiving Server.

  • The defined port ranges must not overlap each other and must not contain the Web Server port.

  • The Web Server port must be open in the Firewall settings.

  • The port range should be open between the primary/secondary and all distributed machines.

Connecting to Control-M/EM Behind a Firewall from Control-M Clients

This procedure describes how to connect to Control-M/EM behind a firewall from Control-M clients.

Begin

  1. From a Control-M/EM server computer, open a command line and type the following:

    emweb_status

    The following appears:

    web server is running [ host:port/ ]

  2. In your firewall definition, verify that this specific port is open.

    To use the Client Distribution feature and access the Help, the Control-M client version 9.0.18 and higher must be installed to communicate with Control-M Web Server. The port is configured in the ./etc/emweb/tomcat/conf/server.xml file.

Connecting to an Apache Kafka Server Behind a Firewall

This procedure describes how to connect to an Apache Kafka server behind a firewall by configuring ports. The firewall configuration is required to enable the Services Configuration Agent (SCA) in each Control-M/EM distributed instance to have access to all distributed instances of Kafka.

You need to perform this procedure after you have configured the other Control-M/EM server components behind a firewall, as described in Configuring Control-M/EM Server with High-Availability or Control-M/EM Distributed Behind a Firewall.

Begin

  • From a command line, define the Apache Kafka port by running one of the following:

    • UNIX: em -no_wrap cha -set_field_val KAFKA_PORT <port>

    • Windows: emcha -set_field_val KAFKA_PORT <port>

Connecting to Control-M/EM Behind a Firewall from Workload Archiving Server

This procedure describes how to connect the Workload Archiving Server to Control-M/EM behind a firewall by configuring a specific port or port range.

Begin

  1. Back up the communication.xml file to a Control-M/EM distributed computer in one of the following locations:

    • Windows: %EM_HOME%\etc\domains\communication.xml

    • UNIX/Linux: $EM_HOME/etc/domains/communication.xml

  2. In the original communication.xml file, add the "ARC" scope name to define the listen port for the Workload Archiving server and save the file.

    Copy 
    <scope name="ARC"> 
    	<variable name="ListenPort" value="port_number"/> 
    </scope>

    where "port_number" is the port number or port range, such as 10250 for specific port or 10250-10255 for port range.

  3. In the CCM, recycle the Workload Archiving component.

  4. Verify that the configured port between the Primary and Distributed Control-M/EM environments is open.

  5. From the Control-M/EM Distributed computer, run the following utility to verify that the Workload Archiving Server is listening on the configured port:

    > arc_test_configuration

  6. Run an archive search to verify that the search is working.

Defining Daylight Savings Time Support

This procedure describes how to define Daylight Savings Time (DST) support from the TimeZone.dat file. You only need to do this procedure if the Control-M/Server resides in a location where DST is used.

Begin

  1. Navigate to the following directories, and complete this procedure for each TimeZone.dat file:

    • <ctm_server_home>/data

    • *<*em_home>/ctm_em/data/

      The standard format for the definition is timeZone (GMT±hh:mm), where timeZone represents the time zone label.

    The label EST represents the Eastern Standard time zone, and the regularly formatted entry for the Eastern Standard Time time is EST GMT -05:00.

  2. Change the relevant time zone definition so that it includes DST adjustments, as follows:

    timeZone (GMT±hh:mm) FROM dd.mm hh:mm TO dd.mm hh:mm (GMT±hh:mm)

    Where:

    • timeZone (GMT±hh:mm) indicates the regular time zone value (for example, CET (GMT+02:00))

    • FROM and TO values indicate the time frame during which DST is in effect. (For example, FROM 01.03 01:59 TO 24.10 02:00)

    • The second GMT value indicates the DST time-offset relative to GMT (For example, (GMT+03:00))

    If a relevant time zone contains several countries, some observe DST and some do not (or if they change the clock on different days) add additional time zone definitions to cover the variations.

    Bill needs to create a new time zone label for Japan, where the time is nine hours later than Greenwich Mean Time (GMT). DST begins March 1 at 01:59 and ends October 24 at 02:00. Bill uses the following entry to create the new label (JST):

    JST (GMT+09:00) FROM 01.03 01:59 TO 24.10 02:00 (GMT+10:00)

    Although time zone definitions in the northern hemisphere are set to summer Daylight Saving Time, definitions in the southern hemisphere are set to winter. In Sydney, Australia, winter time (GMT+09:00) is from March 25 at 03:00 until October 1 at 02:00. All other dates are GMT+10:00 (summer time). The time label for Sydney is defined as follows:

    SYD (GMT+11:00) FROM 25.03 03:00 TO 01.10. 02:00 (GMT+10:00)

    • This syntax is reversed for the southern hemisphere. The FROM and TO keywords specify the start and end settings for daylight saving to take effect.

    • There must be an empty line at the end of the file.

  3. Recycle Control-M/Server.

  4. Update the relevant job processing definitions, using the appropriate variations.

    If you delete a time zone from TimeZone.dat or modify a three-character name in that file, change any job processing definitions that specify that time zone. Otherwise, those job processing definitions are invalid.

Daylight Savings Time Considerations (Spring)

The following examples assume that the clock is moved ahead at 02:00 A.M. (02:00 A.M. becomes 03:00 A.M.). If the computer is capable of changing the clock without restarting the system, do not bring down Control-M when the clock is being advanced.

If your data center includes multiple time zones, you may need to adjust the time zone configuration file to reflect the different offsets that result from a switch to or from daylight saving time. This adjustment is especially important because the switch to daylight saving time is often not made on the same date in each time zone.

New Day Procedure

  • If the New Day procedure starts before you reset the clock, the New Day procedure will start working before the clock is advanced, and will continue normally (even if the clock is advanced while the New Day procedure is in process).

  • If the New Day procedure is scheduled to begin at exactly 02:00 A.M., the same considerations apply. It is possible that the New Day procedure will start execution before the clock is manually changed. Otherwise, changing the clock will initiate New Day processing.

  • If the New Day procedure is scheduled to begin between 02:00 A.M. and 03:00 A.M., after the computer clock is advanced, Control-M will start the normal New Day processing.

  • If the New Day procedure is scheduled to begin after 03:00 A.M., no action is required. Control-M will start the standard New Day procedure.

Time-dependent shout messages

  • Shout messages that are scheduled before 02:00 A.M. do not require any action.

  • Shout messages that are scheduled between 02:00 A.M. and 03:00 A.M. will be issued, even though there may not be a delay in production because the time frame for production is smaller.

  • The above information also applies to jobs that have Shout messages scheduled at a later time (for example, 06:00 A.M.). These jobs might be considered late because of the tighter production time frame.

Time-dependent Schedules

  • FROM UNTIL: Jobs whose scheduled time overlaps the time gap created by the clock shift may need manual intervention. For example, it is possible that a job with a FROM value of 02:15 A.M. and an UNTIL value of 02:45 A.M. might not be submitted at all. These jobs should be manually adjusted.

  • Cyclic Jobs or Cyclic SMART folder: The next run of cyclic jobs with an interval of more than one hour runs one hour sooner than it was scheduled. Cyclic jobs with an interval of less than one hour run immediately. A cyclic job may have to be deleted and then resubmitted to continue the processing cycle during the current day.

The Control-M/Server log file will not contain entries with timestamps between 02:00 A.M. and 03:00 A.M. Any scripts or programs that rely on log entry time should be checked for possible discrepancies as a result of advancing the clock.

Daylight Savings Time Considerations (Winter)

The following examples assume that the clock is moved back at 02:00 A.M. (02:00 A.M. becomes 01:00 A.M.):

New Day procedure

  • If the New Day procedure starts before 01:00 A.M., no special action should be taken. The New Day procedure will run only once (between 00:00 and 00:59).

  • If the New Day procedure starts exactly at 01:00 A.M., computer time should not be turned back to 01:00 A.M. to avoid another New Day process. A second New Day procedure requires manual intervention. It is advisable to wait until 02:01 A.M., for example, and turn the clock back to 01:01 A.M.

  • If the New Day procedure is scheduled to begin between 01:00 A.M. and 02:00 A.M., do one of the following actions:

    • Wait at least a full hour after the daily run, and then turn the clock back as needed; the New Day procedure will have ended.

    • Update the clock before New Day processing begins.

      If the New Day time is 01:45 A.M., the clock should be moved back one hour at no later than 01:44 A.M. If the shift was not done by 01:44 A.M., the user should wait until 02:46 A.M. and then shift the time back.

  • If the New Day procedure is scheduled to begin after 02:00 A.M., no special action should be taken.

Time-dependent shout messages: Shout messages scheduled between 01:00 A.M. and 02:00 A.M. might be issued twice.

Time-dependent schedules

  • FROM UNTIL: No special action should be taken for jobs with FROM-UNTIL or cyclic schedules. Jobs scheduled to start between 01:00 A.M. and 02:00 A.M. will start at the first occurrence of the hour (provided that other conditions, such as input conditions and resources are met). However, they can be restarted after the clock is moved back.

  • Cyclic Jobs or Cyclic SMART folder: The next run of cyclic jobs run one hour later than it was scheduled.

Control-M/Server log file: The Control-M/Server log file might contain entries with times earlier than previous entries, due to the time shift. The same considerations that apply to advancing the clock forward, should be applied to moving the clock backwards.

Connecting a Load Balancer to Control-M/EM

This procedure describes how to connect a load balancer to an environment with multiple Distributed Control-M/EM components. This configuration enables you to provide continuous availability between Control-M Web and the Control-M Web Server. Users access Control-M Web with the URL of the Load Balancer, which then distributes requests between the available Web Servers in the Distributed Control-M/EM environment. This ensures seamless connectivity even if one of the Web Servers are down or if there are many connections running concurrently.

Begin

  1. Create the following two reverse proxy servers in the load balancer configuration file, which lists the hosts of the connected Control-M Web Servers.

    • HTTP: Host name of server

    • HTTPS: FQDN of the server

    upstream <NginX machine name> {

    server <EM URL>:<web port>;

    server <EM URL>:<web port>;}

    upstream <FQDN of NginX machine> {

    server <EM URL FQDN>:<HTTPS port>;

    server <EM URL FQDN>:<HTTPS port>;}

    If you want to use the BMC provided certificate, you need to take the CSR file from the load balancer server and copy it to <EM_HOME>/ini/ssl/ and sign it with the em_ssl_ca.pem and em_ssl_cert.pem files using openssl. Afterwards, you need to save the certificate in the configuration file of the load balancer. For an example of this configuration, see Configuring an Nginx Load Balancer with BMC Provided Certificate.

  2. Recycle the load balancer.

  3. Navigate to the following directory:

    • Windows:<EM_HOME>\emweb\tomcat.conf\web.xml

    • UNIX: <EM_HOME>/etc/emweb/tomcat.conf/web.xml

  4. Search for the string corsfilter.

  5. Add the following parameter to each Control-M/EM Distributed instance:

    <init-param>

    <param-name>cors.allowed.origins</param-name>

    <param-value><https of load balancer server></param-value>

    </init-param>

  6. Recycle the Web Server.

Configuring an Nginx Load Balancer with BMC Provided Certificate

This procedure describes how to configure an Nginx Load Balancer with BMC provided certificate.

Begin

  1. Log in as root in the NginX machine and create the openssl.cfg file and copy the following to the file and update the details according to your environment.

    Copy 
    [req]
    default_bits = 2048
    prompt = no
    default_md = sha256
    req_extensions = req_ext
    distinguished_name = dn
    [ dn ]
    C=US
    ST=Texas
    L=Houston
    O=BMC Software Inc
    OU=Control-M
    emailAddress=[Your email address]
    CN =[Your server FQDN]
    [ req_ext ]
    subjectAltName = @alt_names
    [ alt_names ]
    DNS.1 = [Your server FQDN]

  2. Run the following command to create a private key and CSR file:

    openssl req -new -sha256 -nodes -out request.csr -newkey rsa:2048 -keyout privatekey.pem -config openssl.cfg

    The privatekey.pem and request.csr files are created.

  3. Copy the private key to the NginX folder /etc/pki/nginx/private/.

  4. From your Control-M/EM primary machine, navigate to <EM_HOME>/ini/ssl/ and copy the following files to your NginX machine where the CSR file is created.

    • - em_ssl_ca.pem

    • - em_ssl_cert.pem

  5. Run the openssl command to sign your CSR and move the file that is created to /etc/pki/nginx/.

Changing the DBO Password

This procedure describes how to change the Oracle, MSSQL, or PostgreSQL DBO password on UNIX and Windows. You must perform this procedure on all Control-M/EM installations (primary, secondary, and Control-M/EM Distributed) as they use the same database.

If you are working in a High Availability environment, you must perform this procedure on the active Control-M/EM first and then on all other Control-M/EM servers. The first time you perform this procedure on the primary, you require the database administrator username and password.

Begin

  1. Shut down all Control-M/EM components on all Control-M/EM installations including the Control-M/EM Configuration Agent (primary, secondary, and Control-M/EM Distributed).

  2. Run one of the following on the primary host and then on all the other hosts:

    • UNIX: {BMC_Install_folder}/ctm_em/bin/change_em_database_owner_password.sh

    • Windows: {BMC_Install_folder}\Control-M EM\Default\bin\change_em_database_owner_password.bat

Authorizing Non-Administrators to Manage Application Plug-in Connection Profiles

This procedure describes how to define users or groups who can manage application plug-in connection profiles without granting them unlimited configuration privileges.

The permissions set using this procedure supersedes the privileges defined in the User Authorization window.

Begin

  1. Change the value of the restricted_cm_admin system parameter to 1, as described in Defining Control-M/EM system parameters.

  2. Navigate to the following directory on where the Content Management System (CMS) is running:

    <emHome>\<instanceName>\ini

  3. Type the required value for each tag, as described in cm_admin.xml Parameters.

    You can use expressions such as a* or LIKE Bob for any of the fields.

    See the sample_cm_admin.xml in the ini directory.

  4. Save the file as cm_admin.xml.

  5. Run the following command:

    Ctl.exe -U EM_DBO -P EM_DBO_password -C CMS -name CMS -cmdstr “REFRESH_CM_ADMIN_AUTH”

    You must execute the above command every time the cm_admin.xml file is modified.

cm_admin.xml Parameters

The following table describes parameters that are used in the cm_admin.xml file. To define these parameters, see Authorizing Non-Administrators to Manage Application Plug-in Connection Profiles.

The relationship between more than one filter in the file uses OR logic. This means that groups or users can manage application plug ins that answer any of the criteria in the list of filters.

Parameter

Description

Name

Defines the name of the Control-M/EM group or user that is granted admin authorizations to the application plug-in

control_m

Defines the Control-M/Server that interacts with the application plug-in

node_id

Defines the name of the Control-M/Agent node where the application plug-in is installed

application_type

Determines which application plug-in is used

Distributing the Control-M app for Android

This procedure describes how to distribute the Control-M app for Android to your users in your organization.

The Control-M app does not support self-signed certificates. Use a certificate signed by a verified CA.

You cannot connect to Control-M from a mobile browser.

Begin

  1. Download the Android app installation package (apk) from the EPD.

  2. Wrap the apk with an additional layer provided by the Mobile Device Manager (MDM) used in your organization (optional).

  3. Sign the apk with your organization's digital signature (optional).

  4. Place the apk in your internal app store for users to install.

  5. Do one of the following:

    • Connect the mobile app via HTTP.

      The URL suffix must be ControlMMobile.

      http://server:18080/ControlMMobile

    • Connect the mobile app via HTTPS (SSL) ,you need to have a certificate that is signed by a verified CA (certificate authority).

      The URL suffix must be ControlM

      https://server:8443/ControlM

Distributing the Control-M app for iOS

This procedure describes how to compile and repackage the Control-M Mobile app with your Apple Enterprise License and distribute it as an in-house App to users in your organization.

The Control-M app does not support self-signed certificates. You must use a certificate signed by a verified CA.

Before you begin:

  • A Mac computer installed with the latest xcode IDE (version 5 or higher).

  • An installed code signing certificate for your required distribution method

  • A bundle identifier that is linked with the signing certificate.

Begin

  1. Download the Mobile Integration Kit from the EPD.

  2. On your Mac, extract the downloaded file and run the installation.

    The installation creates a zipped file on your Mac’s root drive.

  3. Extract it to your preferred location.

  4. Open the project in xcode and double-click the xcodeproj file.

    The xcode opens with the integration kit project.

  5. Set your app to be signed with your certificate as follows:

    1. In the left pane, select the File view.

    2. Select the main project.

    3. In the main area, select Build Settings.

    4. In the search field, type code signing.

    5. Set the code signing identity to your company's.

  6. Change the app ID to match the ID in your certificate, as follows:

    1. Select the General section in the main area.

    2. Select Bundle Identifier, and set it to your identifier.

  7. Build your app as follows:

    1. From the Top menu, click Product, then click Archive.

    2. Follow the instructions to select your distribution method and select your code signing identity.

  8. Save the app to your preferred location.

  9. Do one of the following:

    • Connect the mobile app via HTTP.

      The URL suffix must be ControlMMobile.

      http://server:18080/ControlMMobile

    • Connect the mobile app via HTTPS (SSL) you need to have a certificate that is signed by a verified CA (certificate authority).

      The URL suffix must be ControlM.

      https://server:8443/ControlM