search cancel

Establishing CA Directory replication for policy data and session artifacts in EEM 8.4


Article ID: 49366


Updated On:


CA Directory CA IT Asset Manager CA Software Asset Manager (CA SAM) ASSET PORTFOLIO MGMT- SERVER CA Service Management - Service Desk Manager CA Workload Automation AE - Business Agents (AutoSys) CA Workload Automation AE - Scheduler (AutoSys) Workload Automation Agent CA Process Automation Base



This is considered a slight alternative to the EEM Getting Started Guide section covering application and data store failover. One key difference is the use of CA Directory native tools for establishing server trusts.


This technical document assumes you have the following pre-requisites covered:

  • Working DNS environment or hosts files that can resolve names to IP Addresses from server to server. CA strongly recommends using a DNS forward and reverse lookup zone to minimize troubleshooting later. CA Support cannot account for every customer environment and scenario, so this doc cannot assume at any point it will work for every single customer environment. Server name resolution can play a pivotal role in determining proper functionality. Therefore adjustments to the configuration may be required.
  • Basic knowledge of CA Directory text based knowledge files and configuration files and their locations.
  • Installs of EEM and edits of files are to be done as an Administrator or Root on the system. For Unix/Linux you would SU - dsa to edit CA Directory files. This technical document will be using the Windows environment as the example but can be easily adapted to Unix/Linux flavors.
  • The practice below was performed using EEM Server build 8.4.410 (8.4 SP4 CR10)

Establish the trust relationship between EEM servers from the iGateway UI.

  1. Login to the EEM spin page depicted in the following figure on Server #1:

    <Please see attached file for image>

    Figure 1
  2. Click the Go button to launch the iTech Admin page, click the login hyperlink and login with your eiamadmin account and password used during Install. Select iauthority and click login:

    <Please see attached file for image>

    Figure 2
  3. Navigate to the Configure tab and add the Second EEM server to the Trusted iAuthority Hosts section on this page:

    <Please see attached file for image>

    Figure 3
  4. Next visit the iAuthority tab and add the rootcert.cer from the remote host machine to primary EEM server. It needs to be the literal path to this cert file. You may copy it to the primary server or map a drive to it. After you browse to the file enter in the other EEM server host name under Label and then click "Add Trusted Root".

    <Please see attached file for image>

    Figure 4

    Repeat steps i-iv on the secondary EEM server.


Modify Ipoz.conf on both servers:

  • · Open $IGW_LOC$\iPoz.conf and make the following changes on both servers:

    • Add <BackboneMember>HostnameofServer2</BackboneMember> on Server #1
    • Add <BackboneMember>HostnameofServer1</BackboneMember> on Server #2

      • This addition can be done anywhere in the file but is normally placed right above the Artifact Manager line below.
  • Change this line from "local" to "federated" on both servers:

    • <ArtifactManager SessionTimeout="10" RequestTimeout="30"ArtifactStore="local/federated"></ArtifactManager>

      • NOTE: This is only necessary for the Autosys and Workload Control Center products. Leave this set to local if you are not using these products or are unsure of the outcome of this setting.


Prepare the CA Directory config for replication.

  1. For this section you will be working out of the %DXHOME%\config location. Server #1 edits:

    • Copy the iTechPoz-server#2.dxc and iTechPoz-server#2-Router.dxc from Server #2 into the same location as the dxc knowledge on Server #1. Edit iTechPoz-server#2.dxc to reflect the change from a single DSA to a multi-write server. The changes are in bold:

      # iTechPoz - iTechnology rePOZitory
      set dsa "iTechPoz-Server#2" =
      prefix = <cn iTechPoz>
      dsa-name = <cn iTechPoz><cn PozDsa><cn Server#2>
      #address = tcp localhost port 509
      #for failover configuration
      address = tcp Server#2 port 509
      snmp-port = 509
      #for dxconsole debugging. info: make sure that the port is not used
      #console-port = 10510
      auth-levels = anonymous
      dsp-idle-time = 120
      #for failover configuration
      dsa-flags = multi-write
      link-flags = ssl-encryption-remote
    • For the iTechPozRouter.dxc copied from Server#2 you only need to change the address line to reflect the server name instead of localhost.
    • Open the file iTechPoz-Server#1.dxc and change the address line to reflect the host name of this server and to not use localhost.
    • Save all of these files.
    • Open iTechPoz.dxg and add the source information for the files you have just edited. Here is the example on Server#1:

      • source "iTechPoz-Server#1-Router.dxc";
        source "iTechPoz-Server#2-Router.dxc";

        source "iTechPoz-Server#1.dxc";
        source "iTechPoz-Server#2.dxc";
    • Go to this same file on Server #2 and make these edits:

      • source "iTechPoz-Server#2-Router.dxc";
        source "iTechPoz-Server#1-Router.dxc";

        source "iTechPoz-Server#2.dxc";
        source "iTechPoz-Server#1.dxc";
  2. Visit the same %DXHOME% location on Server#2 and copy the iTechPoz-server#1.dxc and iTechPoz-server#1-Router.dxc knowledge files from Server#1 respective of those copied from Server#2.

    • Make the same edits to these knowledge files as you just did on Server#2. Making sure to use the hostname of Server#1 where necessary and un-commenting the multi-write flag.

      NOTE: The only knowledge files that should be referring to the address "localhost" is the local itechPoz-localserver-Router.dxc on either system. So only one of the four files will use the address "localhost" The local machine's iTechPoz Router dxc.
  3. Go back to Server#1 and open a command prompt and run the following command:

    • >dxcertgen -d <number_of_days> certs
    • For example >dxcertgen -d 7300 certs
    • This would generate certificates with a validity period of 20 years.
    • This will generate a new set of certificates based on the new knowledge created for the replicated server. Open the file %DXHOME%\config\ssld\trusted.pem and copy out the last string certificate chain at the bottom. Here is a sample of what you need to copy:

    • Copy this string into the file iTechPoz-trusted.pem at the end. Make a backup copy of this file on Server #2 and copy this new file with the added string to the same ssld folder on Server #2. Then copy the following four .pem files from the ssld/personalities over to Server #2 ssld/personalities.

      • itechpoz-server#1-router.pem
      • itechpoz-server#1.pem
      • itechpoz-server#2-router.pem
      • itechpoz-server#2.pem
    • The two EEM servers now have the shared certificate and host knowledge of each other and are ready for replication and failover.

You can now test the config and test replication by performing the following:

  • At the command prompt on both servers run the command 'dxsyntax'. If there is no error then there will be no problem starting the Directory DSA's. Run the command "dxserver start all" on both servers. Then run "net start igateway" if this is not done already.
  • Login to the EEM UI on both server #1 and #2 separately. From there click on the "Manage Access Policies" tab. Create a new delegation policy of name "test_server#1" and mark it with the disabled flag, and then save it. Visit the same Manage Access Policies tab on the server you did not create the new policy and check to see that it was replicated. Repeat this process on the server that was just replicated to.
  • Additional testing includes logging into a registered application instance in EEM such as AutoSys, WCC, Service Desk, and checking to see that Artifact replication is working. This requires that the product supports session failover so that the session remains intact when one EEM server is shutdown.
  • If there is failure in replication, you can troubleshoot this by editing the knowledge dxc files to use Ip addresses instead of hostnames. CA support cannot account for every customer environment so please be prepared to make edits to the configuration and keep track of all changes.

As always, if you have additional questions or concerns about the topics covered in this technical document, please do not hesitate to open a case with CA Support Online.


Release: ETRIA199000-8.3-Embedded Entitlements Manager


1558712406910000049366_sktwi1f5rjvs16sm7.gif get_app
1558712405077000049366_sktwi1f5rjvs16sm6.gif get_app
1558712403279000049366_sktwi1f5rjvs16sm5.gif get_app
1558712401382000049366_sktwi1f5rjvs16sm4.gif get_app