Manually Upgrade to Secure Hub and Robot

This article provides comprehensive information about how to manually upgrade to a secure hub and robot. This manual upgrade process is helpful when you do not use the secure hub and robot option while using the CA UIM 9.2.0 (UIM Server) upgrade installer and want to convert your setup to a secure setup at a later stage.
uim902
This article provides comprehensive information about how to manually upgrade to a secure hub and robot. This manual upgrade process is helpful when you do not use the secure hub and robot option while using the CA UIM 9.2.0 (UIM Server) upgrade installer and want to convert your setup to a secure setup at a later stage.
 We recommend that you use the CA UIM upgrade installer instead of the manual process, as the upgrade installer automatically performs various tasks and significantly eases the secure upgrade process.
The following topics cover the required information:
 
 
2
 
2
 
 
Manual Upgrade Scenario
The following are the assumptions for the secure hub and robot conversion process that is explained in this article:
  • The example domain consists of three hubs:
    • Primary hub - Tunnel Client
    • First secondary hub - Tunnel Server
    • Second secondary hub - Tunnel Client
  • You do not yet have tunnels connecting your hubs.
The following diagram shows the domain setup:
Tunnel_Setup
Tunnel_Setup
Considerations
We recommend that you review all the considerations that are outlined in the Secure Hub and Robot article.
Prerequisites
Review the following prerequisites:
  1. You have already executed the CA UIM 9.2.0 upgrade installer (UIM Server) in a non-secure mode on the existing CA UIM 9.0.2 setup. This ensures that the latest packages, including secure packages, are available in the primary hub archive.
Configure the First Secondary Hub as Tunnel Server
A tunnel server consumes extra resources. To avoid the extra burden on the primary hub, choose a secondary hub in the domain to be the tunnel server. Upgrade this tunnel server hub first.
 
Follow these steps:
 
  1. In IM, open the hub probe configuration for the first secondary hub; that is, the tunnel server hub.
  2. In the 
    General
     tab, select the 
    Enable Tunneling
     option.
  3. Select the 
    Tunnels
     tab.
  4. Select 
    Server Configuration
    .
  5. Select the 
    Active
     option.
  6. Create a local Certificate Authority (CA) for the tunnel server. Take the defaults for the certificate information here, and supply a password. Non-secure tunnel certificates require a password. This step creates a CA and server certificate (CN: IP address).
     While configuring the secure hub and robot at a later stage, you can work with the same tunnel certificates that you have already configured here or you can replace them with the third-party certificate, as required. That is, you can use the same tunnel certificates or third-party certificates on the required robots. You can also use * (wildcard) as the commonName to generate and use * tunnel client certificates.
  7. When you select 
    OK
     on the 
    Certificate Authority Setup
    , you are returned to the 
    Server Configuration
     tab. 
  8. Select 
    New
     to generate the new certificate that is signed by the same CA, which you can use for your tunnel clients. You can use * as the common name to issue a * tunnel certificate.
  9. Provide the newly issued certificate when you create each tunnel client. Select 
    View
    , and select the 
    Certificate
     tab. You can copy the certificate to the Clipboard.
  10. Select 
    OK
     to return to the 
    Server Configuration
     tab, select 
    Apply
    , and select 
    OK
    . Select 
    Yes
     to restart the hub probe and activate the new tunnel server.
Appropriate files are created in the 
<Nimsoft>\hub\certs
 folder during the tunnel server configuration:
  • The ca.pem is the local CA file, server.pem is the server certificate file, and cert#.pem (for example, cert02.pem) is the * tunnel certificate file on the tunnel server.
  • Note the timestamp of your cert#.pem file to identify your required * tunnel certificate file, because it is possible that you have multiple client certificate files on the tunnel server. However, it is recommended to delete the existing unused * certificates to avoid confusion. There is no need to have multiple * certificates that are signed by the same CA. Furthermore, you need to copy this file (cert#.pem) to all the robots pointing to this server and update the robot.cfg with the certificate information as explained later in this article. 
  • For * tunnel certificates, you can use a callback (
    create_robot_cert_package
    ) on the secure tunnel server hub to generate a certificate package. This certificate package includes a * tunnel certificate and robot.cfx. After the certificate package is generated, it is placed in the secure tunnel server archive. You can then deploy it on the robots, which in turn deploys the * tunnel certificate .pem file on the robot and updates the robot.cfg file with the certificate information. This article shows the manual process without using this callback. For more information about how to generate and use this certificate package, see the "Generate Certificate Package" section in the Secure Hub and Robot article. 
The following example screenshot shows the tunnel server certificate configuration:
  Tunnel_Server_Certificate.PNG  
Create Tunnel Clients on Primary Hub and Other Secondary Hub
The primary and the other secondary hubs in the domain connect to the tunnel server as tunnel clients. Create tunnel clients on these hubs.
 
Follow these steps:
 
  1. In IM, open the hub probe configuration for the primary hub.
  2. In the 
    General
     tab, select the 
    Enable Tunneling
     option.
  3. Select the 
    Tunnels
     tab.
  4. Select 
    Client Configuration
     to create a new tunnel client.
  5. Select 
    New
    .
  6. Select the 
    Active Tunnel
     option.
  7. Clear the 
    Check Server CommonName
     option.
  8. Enter the description.
  9. In the 
    Server
     field, enter the IP address of the tunnel server hub.
  10. In the 
    Password
     field, enter the password that you specified when you created the certificate that you wanted to use for tunnel clients.
  11. In the 
    Certificate
     field, paste in the body of the certificate you copied from the tunnel server certificate.
  12. Select 
    OK
    .
    The new tunnel client is added to the list of tunnel clients on the hub. On a given hub, you can have only one tunnel server, but you can have many tunnel clients.
  13. Select 
    Apply
    , and then select 
    OK
    .
    The hub restarts to pick up the new tunnel client.
  14. Repeat the steps to create a tunnel client on the remaining hubs in the domain.
Appropriate * tunnel certificate .pem file (client#.pem) is created in the 
<Nimsoft>\hub\certs
 folder during the tunnel client configuration. You need to copy this file (client#.pem) on all the robots pointing to this computer and update the robot.cfg with the certificate information as explained later in this article. For * tunnel certificates, you can use a callback (create_robot_cert_package) on the secure tunnel server hub to generate a certificate package. This certificate package includes a * tunnel certificate and robot.cfx. After the certificate package is generated, it is placed in the secure tunnel server archive. You can then deploy it on the robots, which in turn deploys the * tunnel certificate .pem file on the robot and updates the robot.cfg file with the certificate information. This article shows the manual process without using this callback. For more information about how to generate and use this certificate package, see the "Generate Certificate Package" section in the Secure Hub and Robot article. 
Verify Tunnel Connectivity
Verify the status of each tunnel server and tunnel client to ensure that they are connected.
 
Follow these steps:
 
  1. In IM, open the hub probe configuration for the first secondary hub–the tunnel server hub.
  2. Select the 
    Status
     tab.
  3. Select 
    Tunnel Status
    .
    The 
    Peer Hub
     list contains an entry for each tunnel client that is connected to the tunnel server. Statistics are shown for each tunnel client. Each tunnel client hub also reports the tunnel server it is connected to, and includes statistics.
The following screenshot shows the tunnel connectivity between the secondary hub (which is a tunnel server in this example screenshot) and primary hub (which is a tunnel client in this example screenshot):
  Tunnel_Status.PNG  
Get CA-Approved Certificates (For Third-Party Certificates)
 If you are using tunnel certificates (for example, * certificate), you do not need to perform the steps that are mentioned in this section. These steps are only for third-party certificates.
 
(Only for third-party certificates)
 You can use the same third-party certificates for hub-to-hub and robot-to-hub communications. Before you create and use third-party certificates, review the following third-party certificates-related requirements:
  • Elliptic curve (EC) and RSA ciphers are supported.
    • Use PEM format for keys and certificates.
    • Certificate revocation lists are not checked.
    • Non-standard X.509 certificate extensions are not supported.
  • Validation of certificate commonName or subjectAltName for hub-to-hub communication is enabled by default.
  • The public key, private key, and certificate chain files are required on all hubs and robots.
  • Copy your third-party certificate files to each hub, making a note of the location. 
To get CA-approved certificates (for example, RSA with server 
uim1.ca.com
), you can use OpenSSL and can follow these steps:
 For wildcard certificates, use * in the Common Name field when prompted; for example, *.ca.com.
  1. Ensure that OpenSSL is already available on the computer where you want to create certificates.
  2. Create a private key for the server 
    uim1.ca.com
     as follows (example):
    openssl genrsa -out uim1.ca.com.key 2048
     
  3. Create a certificate request (CSR) as follows (example):
    openssl req -new -key uim1.ca.com.key -out uim1.ca.com.key.csr
     
  4. Send the certificate request to your certificate authority (CA) and request for the .pem file.
    CA sends the required .pem files for your server and the applicable CA certificate chain.
If you receive the files in .crt format, you can use the following command to convert a .crt file to a .pem file (example):
 
openssl x509 -in uim1.crt -out uim1-crt.pem -outform pem
 
Additionally, you can use the following command to convert private keys to PEM (example):
 
openssl rsa -in uim1.ca.com.key -out uim1-pvt-crt.pem -outform pem
 
 Copy your third-party certificate files to each hub, making a note of the location. Also, you can use a single certificate for all robots.
Upgrade Process
The following diagram shows the process steps to convert to a secure hub and robot:
Manual_Upgrade_Secure_Hub_Draft
Manual_Upgrade_Secure_Hub_Draft
The steps are as follows:
  For deploying a secure hub to a tunnel server and tunnel client, ensure that you have one non-secure hub (which can be one of the tunnel clients) in the setup for deploying the packages. 
If the non-secure hub that you are using for deploying the packages is 
not a primary hub
, copy the secure hub 9.20S, secure robot 9.20S, hub_adapter 9.20S, distsrv 9.20  (required for running the certificate callback), and non-secure robot 9.20 (7.97 or later) builds from the 
non-secure primary hub
 ..\Nimsoft\archive folder to the ..\Nimsoft\archive folder of the 
non-secure hub
. Connect to the non-secure hub using IM. Use this IM connection to import the packages into the non-secure hub archive and then deploy the required packages to the tunnel server and tunnel clients.
However, if the non-secure hub that you are using for deploying the packages is a 
primary hub
, you do not need to copy the packages because they will be available in the non-secure primary hub archive. In this case, connect to the IM on the non-secure primary hub and deploy the required packages to the tunnel server and tunnel clients. The example screenshots that are included in this procedure use the primary hub (tunnel client) archive for deploying the packages.
Deploy hub_adapter on Tunnel Server and Tunnel Clients
The hub_adapter probe acts as a proxy for communication between a secure hub and non-secure robots. A secure hub cannot control non-secure robots unless a hub_adapter is installed on it. Therefore, you must install the hub_adapter probe on secure hubs that control non-secure robots.
Deploy the hub_adapter probe from the archive to the tunnel server and the tunnel clients.
The following example screenshot shows that the hub_adapter probe is already available in the primary hub archive. Also, note that hub 9.20 and hub_secure 9.20S are also available in this archive:
  Hub_Adapter_PH_Archive.png  
The following example screenshot shows that the hub_adapter probe is successfully deployed on the secondary hub (tunnel server) from the primary hub archive (which is a tunnel client in this example screenshot). Note that all other probes are still in the 7.96 state (CA UIM 9.0.2) on this secondary hub:
  Hub_Adapter_SH_Robot.png  
The following screenshot shows that the hub_adapter probe is successfully deployed on the primary hub (tunnel client in this example screenshot). Note that all other probes have been updated because of the CA UIM 9.2.0 upgrade on the primary hub:
  Hub_Adapter_PH_Robot.png  
Configure Non-Secure Hubs to Use Third-Party Certificates
 This configuration is required only for third-party certificates. When you perform this configuration, the communication happens through the third-party certificates. However, if you are using tunnel certificates (for example, * certificate), then you do not need to perform these steps; in this case, the communication happens through tunnel certificates.
 
(Only for third-party certificates)
 Copy your third-party certificate files to each hub, making a note of the location. Do not restart the hub after editing hub.cfg. The upgrade process restarts the hub and the changes you make to hub.cfg are evaluated at that time. If the hub configuration is updated to the secure configuration before the hub is upgraded, you lose the connectivity with that hub. Additionally, do not use raw config edit for hub.cfg.
  1. On non-secure tunnel clients hub, temporarily rename the following keys to unique key names in the <tunnel><clients> section of hub.cfg. Rename the keys to retain the values until the hub is upgraded to secure and the keys can be discarded. Rename:
    • cert
    • password
  2. Set the following keys in the hub.cfg file on every hub.
    1. For a tunnel server, locate the <tunnel><server> section of hub.cfg and add the following keys.
      •  
        ca_location
        Specifies the location of a certificate chain file from a certificate authority (CA). The key can also refer to a directory where multiple root certificates are stored. If you provide a directory, use the hash format (for more information, see the OpenSSL documentation.)
      •  
        public_cert
        Specifies the location of the public certificate file.
      •  
        private_key
        Specifies the location of the private key file.
    2. For each tunnel client, locate the <tunnel><clients><#> section of hub.cfg and add the following keys:
      •  
        ca_location
        Specifies the location of a certificate chain file from a certificate authority (CA). The key can also refer to a directory where multiple root certificates are stored. If you provide a directory, use the hash format (for more information, see the OpenSSL documentation.)
      •  
        public_cert
        Specifies the location of the public certificate file.
      •  
        private_key
        Specifies the location of the private key file.
      Note:
       For more information, see the Linux and Windows examples.
  3. Save your changes.
Review the following points:
  • Avoid using spaces in directory or file names.
  • The maximum length of any key-value pair in a CA UIM configuration file is 2047 characters. This limit includes the entire line in the configuration file:
    • Indentation spaces
    • Key name, space, equal sign, and following space
    • The value of the key
  • In Linux:
    • You can specify an absolute path, or a relative path from UIMHOME/hub.
    • Symbolic keys are supported for certificate keys.
    • The key-value pair specifying an absolute or relative path can be a maximum of 2047 characters.
  • In Windows:
    • You can specify an absolute path, a relative path from UIMHOME/hub, or an absolute path in long UNC format.
    • The maximum length of a path in Windows is 259 characters. The operating system converts relative paths to absolute paths. Ensure that a relative path does not expand to exceed 259 characters.
    • Windows accepts the back slash (
      \
      ) or the forward slash (
      /
      ) as the path separator in relative or absolute paths.
    • To use a path longer than 259 characters in Windows, use a long UNC path.
      • Long UNC paths begin with 
        \\?\
         
      • A long UNC path must be an absolute path, and must use the back slash (
        \
        ).
      • The kay-value pair specifying a long UNC path can be a maximum of 2047 characters.
Linux Example
In this case,
 UIMHOME=/opt/nimsoft
 and certificates files are stored in 
/opt/nimsoft/certs
.
Add the following keys to the <tunnel><server> section of the hub.cfg file in Linux:
 
ca_location=/opt/nimsoft/certs/ChainFile.pem
 
 
public_cert=/opt/nimsoft/certs/PublicKey.pem
 
 
private_key=/opt/nimsoft/certs/PrivateKey.pem
 
Windows Example
Use an absolute local filesystem path:
 
ca_location=c:/certs/ChainFile.pem
 
 
ca_location=c:\certs\ChainFile.pem
 
Use a relative local filesystem path relative to 
C:\Program Files (x86)\nimsoft\hub
:
 
ca_location=certs/ChainFile.pem
 
 
ca_location=certs\ChainFile.pem
 
Use a long UNC path:
 
ca_location=\\?\C:\<very_long_path>\certs\ChainFile.pem
 
Deploy Secure Hub on Tunnel Server
Secure hub (hub_secure 9.20S) requires the presence of robot 7.97 or later. Therefore, before you deploy the secure hub, ensure that robot 7.97 or later is already available on the hub.
The following example screenshot shows that the robot version has been updated to 9.20 by deploying the package from the primary hub (tunnel client in this screenshot) archive to the secondary hub (tunnel server in this screenshot):
  SH_Robot_Update.png  
Now, the secure hub can be deployed to the secondary hub (tunnel server). The following example screenshot shows that the secure hub has been successfully deployed from the primary hub (tunnel client) archive to the secondary hub (tunnel server in this screenshot):
  SH_Hub_Secure.png  
Deploy Secure Hub on Tunnel Client
Upgrade the tunnel client hubs by following the same process that is explained for the tunnel server.
The following example screenshot shows that the secure hub has been successfully deployed on the primary hub (tunnel client in this example screenshot)
  PH_Hub_Secure.png  
Hubs restart after an upgrade. Allow a few minutes for tunnel communication to stabilize.
Configure robot.cfg on Tunnel Server
You can use the same certificates for hub-to-hub and robot-to-hub communications. For example, if you have generated the * tunnel certificates at the tunnel server, the same can be used on the robot pointing to that tunnel server.
 If you are using * tunnel certificates, you can use a callback (
create_robot_cert_package
) on the secure tunnel server hub to generate a certificate package:
  • This certificate package includes a * tunnel certificate and robot.cfx. 
  • After the certificate package is generated, it is placed in the secure tunnel server archive.
  • You can then deploy it on the robots, which in turn deploys the * tunnel certificate .pem file on the robot and updates the robot.cfg file with the certificate information.
  • This article shows the manual process without using this callback. 
  • We recommend that you use the certificate package as it automates the process and reduces the possibility of manual errors.
  • If you want to use the certificate package, see the "Generate Certificate Package" section in the Secure Hub and Robot article. 
  • To use this callback, distsrv 9.20 must be deployed on the secure tunnel server hub.
  • You must deploy the UIMRobotCert package to the tunnel server robot.
 
Follow these steps:
 
  1. Validation of certificate commonName or subjectAltName for robot-to-hub communication is enabled by default.
    • Fully Qualified Domain Names (FQDN) are required for validation. If short host names are provided, validation fails.
    • Validation is platform-specific, but typically is first attempted through 
      /etc/hosts
      . If validation fails, DNS validation is used:
      • The hosts file on Linux is 
        /etc/hosts
        .
      • The hosts file on Windows is 
        C:\Windows\System32\drivers\etc\hosts
        .
  2. (For third-party certificates) Copy public key, private key, and certificate chain files to all hubs and robots.
  3. Set the following keys in robot.cfg:
     For third-party certificates, you must use only the first three parameters (proxy_ca_location, proxy_cert, and proxy_private_key). If you are using the tunnel certificate (for example, * tunnel certificate), you must use all the five parameters. 
    •  
      proxy_ca_location
      (For third-party certificates) Specifies the location of a chain file from a certificate authority (CA). The key can also refer to a directory where multiple root certificates are stored. If you provide a directory, use the hash format (for more information, see the OpenSSL documentation). For example, 
      proxy_ca_location = C:\certs\ca-chain.ec.cert.pem
      (For tunnel certificates) Specifies the location of the * tunnel certificate on the computer. For example, 
      proxy_ca_location = C:\Program Files (x86)\Nimsoft\hub\certs\cert02.pem
       
    •  
      proxy_cert
      (For third-party certificates) Specifies the location of the public certificate file. For example, 
      proxy_cert = C:\certs\gk01-j05.ca.com.ec.cert.pem
      (For tunnel certificates) Specifies the location of the * tunnel certificate on the computer. For example, 
      proxy_cert = C:\Program Files (x86)\Nimsoft\hub\certs\cert02.pem
       
    •  
      proxy_private_key
      (For third-party certificates) Specifies the location of the private key file. For example, 
      proxy_private_key = C:\certs\gk01-j05.ca.com.ec.key.pem
      (For tunnel certificates) Specifies the location of the * tunnel certificate on the computer. For example, 
      proxy_private_key = C:\Program Files (x86)\Nimsoft\hub\certs\cert02.pem
       
    •  
      proxy_private_key_password
      (For tunnel certificates) Specifies the password that you used while creating the tunnel certificate.
    •  
      proxy_check_ip_first 
      (For tunnel certificates) If enabled (that is, set to 1), it checks the common name in the hub certificate to find whether the IP address is used. If it matches the IP address, it proceeds. If not, it looks for the host name. If it matches with the host name, it proceeds without any issue. Otherwise, it throws an error. The default value is 1 (enabled).
      If not enabled, it looks only for the host name match.
     For more information, see Linux and Windows examples.
  4. Save your changes.
Review the following points:
  • Avoid using spaces in directory or file names.
  • The maximum length of any key-value pair in a CA UIM configuration file is 2047 characters. This limit includes the entire line in the configuration file:
    • Indentation spaces
    • Key name, space, equal sign, and following space
    • The value of the key
  • In Linux:
    • You can specify an absolute path, or a relative path from UIMHOME/robot.
    • Symbolic links are supported for proxy keys.
    • The key-value pair specifying an absolute or relative path can be a maximum of 2047 characters.
  • In Windows:
    • You can specify an absolute path, a relative path from UIMHOME/robot, or an absolute path in long UNC format.
    • The maximum length of a path in Windows is 259 characters. The operating system converts relative paths to absolute paths. Ensure that a relative path does not expand to exceed 259 characters.
    • Windows accepts the back slash (
      \
      ) or the forward slash (
      /
      ) as the path separator in relative or absolute paths.
    • To use a path longer than 259 characters in Windows, use a long UNC path.
      • Long UNC paths begin with 
        \\?\
         
      • A long UNC path must be an absolute path, and must use the back slash (
        \
        ).
      • The key-value pair specifying a long UNC path can be a maximum of 2047 characters.
Linux Example
In this case, 
UIMHOME=/opt/nimsoft
 and proxy certificate files are stored in 
/opt/nimsoft/certs
.
Add the following keys to the robot.cfg file to specify relative paths:
 
proxy_ca_location=../certs/ChainFile.pem
 
 
proxy_cert=../certs/PublicKey.pem
 
 
proxy_private_key=../certs/PrivateKey.pem
 
Windows Examples
Use an absolute local filesystem path:
 
proxy_ca_location=c:/certs/ChainFile.pem
 
 
proxy_ca_location=c:\certs\ChainFile.pem
 
Use a relative local filesystem path where certificate files are stored in 
C:\Program Files (X86)\Nimsoft\certs
 
 
proxy_ca_location=../certs/ChainFile.pem
 
 
proxy_ca_location=../certs/ChainFile.pem
 
Use a long UNC path:
 
proxy_ca_location=\\?\c:\<very_long_path>\certs\ChainFile.pem
 
Deploy Secure Robot on Tunnel Server
Apply the secure robot (robot_update_secure 9.20S) to the tunnel server robot. Select the required package and deploy it.
The following example screenshot shows that the secure robot has been successfully deployed from the primary hub (tunnel client) archive to the secondary hub (tunnel server in this screenshot):
  SH_Controller_Secure.PNG  
Configure robot.cfg on Tunnel Clients
Follow the process that is explained in the Configure robot.cfg on Tunnel Server section to configure robot.cfg file on the required tunnel clients.
 If you are using the UIMRobotCert package, you must deploy the package to the tunnel client robots.
An example of entries for the third-party certificates is as follows:
  •  
    proxy_ca_location = C:\certs\ca-chain.ec.cert.pem
     
  •  
    proxy_cert = C:\certs\gk01-j05.ca.com.ec.cert.pem 
     
  •  
    proxy_private_key = C:\certs\gk01-j05.ca.com.ec.key.pem
     
An example of entries for the * tunnel certificate on a tunnel client is as follows:
  •  
    proxy_ca_location = C:\Program Files (x86)\Nimsoft\hub\certs\client1.pem
     
  •  
    proxy_cert = C:\Program Files (x86)\Nimsoft\hub\certs\client1.pem
     
  •  
    proxy_private_key = C:\Program Files (x86)\Nimsoft\hub\certs\client1.pem
     
  •  
    proxy_private_key_password = +2I4kxfkvhj0loWVXAkzWx==
     
  •  
    proxy_check_ip_first = 1
     
 In addition to securing tunnel client robots, you must also secure other independent robots pointing to the secure hub to ensure that the environment is completely secure.
Deploy Secure Robot on Tunnel Clients
Apply the secure robot to the tunnel client robots. Select the required package and deploy it.
The following screenshot shows that the secure robot has been successfully deployed to the tunnel client (primary hub in this screenshot):
  PH_Controller_Secure.PNG  
Follow the same steps to upgrade all other child robots (if any) that are connected to secure hubs.
Verify the Setup
After you complete all the previously mentioned steps, log in to the tunnel server and tunnel client computers, using IM with the IP 127.0.0.1. Both the tunnel server and tunnel client hubs must be listed in IM in both the computers. This implies that the tunnel communication between server and client is working properly.
 
For Windows
 
To verify that the hub upgrade is successful:
  1. Log in to the Windows server hosting the hub.
  2. Open a Windows command prompt, and execute 
     
    Drive:\YOUR_UIM_HOME_FOLDER
    \hub\hub.exe -V
     
  3. Verify the hub version that is returned.
To verify that the robot upgrade is successful:
  1. Log in to the Windows server hosting the hub.
  2. Open a Windows command prompt, and execute 
     
    Drive:\YOUR_UIM_HOME_FOLDER
    \robot\controller.exe -V
     
  3. Verify the controller version that is returned.
The following example screenshot shows the secure hub version and robot version:
  Verification.PNG  
 
For Unix
 
To verify that the hub upgrade is successful:
  1. Log in to the server hosting the hub.
  2. At a command prompt, execute 
     
    UIMHOME
    /hub/hub -V
     
  3. Verify the hub version that is returned.
To verify that the robot upgrade is successful:
  1. Log in to the server hosting the hub.
  2. At a command prompt, execute 
     
    UIMHOME
    /robot/controller -V
     
  3. Verify the controller version that is returned.
 
Multi-Tiered All-Linux Environment
 
To update a multi-tiered all-Linux environment, follow these steps:
  1. You need to have at least one Windows secure hub (which is a tunnel client) in the setup.
  2. Once the entire setup is secured, connect to this Windows computer.
  3. Open IM in Windows computer and log in with 127.0.0.1.
  4. All secure hubs are listed (all Windows and Linux).
Uninstall or Remove Secure Bus
 
To revert your secure environment to the non-secure state, you must downgrade all the robots and hubs in your secure environment by downloading and installing an older version of the robot and hub from the archive. Based on your setup, you can downgrade robots and hubs as follows:
  1. If your secure environment consists of standalone robots that are connected to a secure hub, then you must first downgrade all the standalone robots to an older version that you downloaded from the archive.
  2. After you downgrade standalone robots, downgrade the robots running on secure hub to an older version that you downloaded from the archive.
  3. After you downgrade all the robots, downgrade the hubs to an older version that you downloaded from the archive.
Additional Information