DX Infrastructure Management

Expand all | Collapse all

Robots installed from an image.

  • 1.  Robots installed from an image.

    Posted 11-29-2018 02:16 PM

    Robots installed from an image.

    I have an installed image of the nimsoft agent and this image is replicated to the other 50 servers. And even if you perform the following procedure:
    . Stop the nimbus service by executing: <nimsoft install> nimsoft / bin / niminit / stop. (usually / opt / nimsoft / bin /)
    2. Locate the folder <Nimsoft Install> \ Nimsoft \ niscache \ (eg / opt / nimsoft / niscache)
    3. Delete all files found in this folder, leaving the empty "niscache" folder behind.
        This is to avoid problems with duplicate robots for discovery.
         The cache files contain device registration info unique to that robot. Hence, we are deleting the contents.
    4. Edit the file <Nimsoft Install> \ robot \ robot.cfg using a text editor.
    5. Ensure that "robotip" and "robotname" are set to a blank value.

    Now you can create the image / clones and deploy as needed. Once the robot service is restarted on the target system, it will automatically generate a new device ID for itself and re-populate the niscache folder with metric files appropriate to that system.
     And add request.cfg in the robot directory in Nimsoft directory, in the request.cfg has the lines:
    <distribution request>
    packages = robot_update
    </ distribution request>

    The probes spooler and hdb fail do not initialize.
    Can someone help me ?



  • 2.  Re: Robots installed from an image.

    Posted 11-29-2018 02:21 PM

    move the controller.cfg file to the "changes" directory.

    and

    Delete the magic_key entries in this file for them.

     

    On robot startup, it will copy this file to the robot directory and recreate the magic_key values.

     

    Otherwise, in the package called by request.cfg, include the calls via pu to probe_verify and probe_activate for spooler and hdb. This will be a problem for newer installs because pu might not be there by default.

     

    or have the request.cfg reinstall robot_update



  • 3.  Re: Robots installed from an image.

    Posted 11-30-2018 06:55 AM

    Kindly, Garin;

    Is this correct the request.cfg file in this way, could you help me - please.

     

    <distribution request>
    packages = robot_update
    packages = cdm
    packages = "pu.exe probe_verify hdb"
    packages = "pu.exe probe_verify spooler"
    packages = "pu.exe prove_activate hdb"
    packages = "pu.exe probe_activate spooler"
    </distribution request>



  • 4.  Re: Robots installed from an image.

    Posted 11-30-2018 07:37 AM

    To address specifically and only the issue of spooler and hdb failing to start because of the tamper detection issue, you only need to add to the process of creating the image:

     

    move the controller.cfg file to the "changes" directory.

    and

    Delete the magic_key entries in this file for them.

     

    The other two options might be alternatives in the event that you need more to happen than you initially asked about.

     

    Regarding the request.cfg

     

    Proper format would be:

     

    <distribution request>
    packages = robot_update, cdm
    </distribution request>

     

    though this will likely not work because robot_update will invoke a restart of everything. The trick there is to have a package that creates a request.cfg file for cdm on the first tab and then has robot_update as a dependency on a second tab. So when the package is deployed, the first step creates a new request file that just sits there, second tab installs robot_update which invokes a restart of the robot. When controller starts, it reads the new request file and installs cdm.

     

    The pu commands would be on the miscellaneous tab of a package you created though it sounds like some time should be spent with the documentation to see if that's a route you want to take.



  • 5.  Re: Robots installed from an image.

    Posted 11-30-2018 11:55 AM

    Hi Garin
    I performed the cleanup of the niscache directory, it includes robotip = "/" robotname = "lines without reference to the server - in the robot.cfg file. I also did the file move. controller.cfg for the changes directory without the references magic_key = "I created the request.cfg file in the c: \ Nimsoft directory:
    <distribution request>
    packages = robot_update, cdm
    </ distribution request>
    All the above procedures were done in the picture.
      After replicating the image of a host "vdictxohso4" the controller.cfg file that was in the changes directory was moved as reported to the C: \ Nimsoft \ Robot directory, as reported. The more probes hdb, spooler continue to fail.

     

    Logs 

    Nov 30 14:42:04:135 [3008] Controller: Probe 'hdb' FAILED to start, file check determines changes in the probe 

    Nov 30 14:42:03:105 [3008] Controller: Probe 'spooler' FAILED to start, file check determines changes in the probe 



  • 6.  Re: Robots installed from an image.

    Posted 12-05-2018 10:09 PM

    after confirming the command:

     

     

     

    i am following the procedure:
    https://comm.support.ca.com/kb/revalidate-probe-via-nas-autooperation-when-failed-due-changes-in-the-probe/kb000010407

     

    I created the scripts for my primary and secondary HUB:
    Validate_script_probe_SPOBRPRD01.cmd
    Validate_script_probe_SPOBRPRD04.cmd

    content of Validate_script_probe_SPOBRPRD01:
    SET SUSER = admuser

    SET SPASSWORD = xxxxx

    SET SHOSTNAME = / SER / SPOBRPRD01 /% 1 / controller

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_verify hdb

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_activate hdb

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_verify spooler

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_activate spooler

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_verify cdm

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_activate cdm

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_verify processes

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_activate processes

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_verify controller

    E: \ Nimsoft / bin / pu.exe -u% SUSER -p% SPASSWORD% SHOSTNAME% probe_activate controller

     

    Open NAS Configuration window

    Goto Auto-Operator tab

    Right-Click on background screen and select New option.

    Select Action Type: command

    Command String: <YOUR_SCRIPT_PATH> \ VALIDATE_SCRIPT.CMD $ hostname $ message

    Message String: * FAILED to start, file check changes in the probe

    Click OK button to save.
    At NAS Auto-Operator -> Profile tab, right-click on profile created and click on Activate.

     

    is correct ?
    I verify that my probes are still uncorrected and with status in red.
    More if the complete command is executed:

    E:\Nimsoft\bin>pu.exe -u admuser -p xxxxx /SER/HUB_SECUNDARIO/SPOBRPRD01/controller probe_verify hdb

    E:\Nimsoft\bin>pu.exe -u admuser -p xxxxx /SER/HUB_SECUNDARIO/SPOBRPRD01/controller probe_activate hdb

    The probes normalize.

    Can you help me in this , please.

     

     



  • 7.  Re: Robots installed from an image.

    Posted 12-06-2018 11:34 AM

    I don't know if there's an issue with the way that you are posting your scripts but you need to be careful with spaces - presence or lack of one completely changes a command.

     

    Your line "SET SHOSTNAME = / SER / SPOBRPRD01 /% 1 / controller"

     

    looks to me like "SET<space>SHOSTNAME<space>=<space>/<space>SER<space>/ SPOBRPRD01<space>/%<space>1<space>/<space>controller"

     

    It should be "SET<space>SHOSTNAME=/SER/SPOBRPRD01/%1/controller"

     

    The most important thing is that the environment variable name is all the characters between "SET + whitespace" and the "=" is your variable. Read batch file - How to set environment variables with spaces? - Stack Overflow 

     

    Similar issues exist in the other lines too.

     

    Errors will be logged to your nas.log - look there for reasons for the failure

     

    The other thing to consider that's a huge help is redirecting output: Using command redirection operators | Microsoft Docs 

     

    so adding something like  " >>output.log 2>&1 " to the end of each line that you are interested in seeing the output from. Or create another batch file that your AO calls, and in that file call the one with the commands and in that call append the redirection. 

     

    And finally, you don't list it in your steps but you want the OA to fire on an overdue age. Something like 20 or 30 seconds overdue. Your message string is questionable - over the years, that string would have periodically been misinterpreted. It would be better to use full regex with a string like "/.*\sFAILED\sto\sstart,\sfile\scheck\schanges\sin\sthe\sprobe.*/" (leave out the " characters). With what you specified, the spaces and comma eligible to be interpreted as separators .

     

     

     



  • 8.  Re: Robots installed from an image.

    Posted 11-29-2018 02:23 PM

    the reason they are not starting is the MD5 hash check is failing.

    you will need to do a security validate on the two probes to reset the MD5 hash

    this can be done through IM.

    Or you can do is from the command line with PU with a command such as:

    pu -u administrator -p controller probe_verify
    pu -u administrator -p controller probe_activate

    Examples:

    C:\Program Files (x86)\Nimsoft\bin>pu -u administrator -p /Support/xpgunnar/xpgunnar/controller probe_verify hdb

    C:\Program Files (x86)\Nimsoft\bin>pu -u administrator -p /Support/xpgunnar/xpgunnar/controller probe_activate hdb

     

    Is it possible to re-validate a probe via the PU C - CA Knowledge 

    Re-validate probe via NAS Auto-Operation when FAIL - CA Knowledge 

    Changed a robot name, and now none of the probes w - CA Knowledge 



  • 9.  Re: Robots installed from an image.

    Posted 11-30-2018 12:34 PM

    Hi Gene;

    I tried to run the command and then create a script to validate the probes after replicating the image, but the command has an error.
    E: \ Nimsoft \ bin \ pu.exe -u ADM -p XXXXX / DOMINIO/ HUB_SECUNDARIO_01 / vdictx04 / hdb probe_verify.
    Is the commando correct?
    I've run from my primary hub because the executable is on this server.

    Also I ran from my secondary hub was not validated, see the context below:

     

    pu.exe -u USERADM -p XXXXX spooler probe_verify 

    pu.exe -u USERADM -p XXXXX hdb probe_verify

     

    O command show failed !

     

    What should be the place of execution?
    I have seen an article that I can make of the primary hub, more precise that the command works from the primary hub for all agents:
    https://comm.support.ca.com/kb/revalidate-probe-via-nas-autooperation-when-failed-due-changes-in-the-probe/kb000010407

    After executing the commands the agent pobes continue to fail

     



  • 10.  Re: Robots installed from an image.

    Posted 11-30-2018 12:51 PM

    You need to follow the probe_verify with a call to probe_activate. All probe verify does is recalculate the MD5 hash.

     

    Also, have you opened a support case yet on the failure to correctly update the controller.cfg?

     

    One thing that is bothering me a little, when you restore the image, does that image have the Nimbus Watcher activated already? Because if so, when that image boots the first time, there will be no values for the name of the robot and so it's possible that it's using a blank value on startup to make the MD5 hash - that would be a defect I think.



  • 11.  Re: Robots installed from an image.

    Posted 11-30-2018 01:29 PM

    I did the procedure but the command is showing "command not found" equal the command probe_activate

    Also, have you opened a support case yet on the failure to correctly update the controller.cfg?

    I not understand the question but I openned the ticket :
    01229378 Servidores não recebem métricas - Atraves do UMP
    But the support response was :
    for this specific behavior, you need to wait for a hand at the UIM community, or Engage the Services Team. ??

    question:

    One thing that is bothering me a little, when you restore the image, does that image have the Nimbus Watcher activated already? Because if so, when that image boots the first time, there will be no values for the name of the robot and so it's possible that it's using a blank value on startup to make the MD5 hash - that would be a defect I think

     

    Answer :

    In the image the nimsof service is stopped at the end of the
    Image. More to check in the image after the first startup of the server that inherited the image, I identify that the service was initialized due to the automatic startup configuration of the service.
    And I identify that in Magic_key does not have value new servants.
    How should I proceed so that magic_key is created automatically?

     

     



  • 12.  Re: Robots installed from an image.

    Posted 11-30-2018 01:50 PM

    I read some questions in the community about the command but its not working too:

    From Prymary HUB:

     

    E:\Nimsoft\bin>pu.exe -u USERADM -p XXXX /DOMINIO/HUB_SECUNDARIO_01/vdictx04/controller probe_verify hdb
    Nov 30 16:46:08:422 pu: SSL - init: mode=0, cipher=DEFAULT, context=OK
    Nov 30 16:46:08:425 pu: nimCharsetSet() - charset=
    _command failed: communication error

     

     

    E:\Nimsoft\bin>pu.exe -u USERADM -p XXXX /DOMINIO/HUB_SECUNDARIO_01/vdictx04/controller probe_activate hdb
    Nov 30 16:46:41:078 pu: SSL - init: mode=0, cipher=DEFAULT, context=OK
    Nov 30 16:46:41:078 pu: nimCharsetSet() - charset=
    _command failed: communication error

     

     

     

    We have communication between primary and secondary HUB for the agents through ping and telnet of ports 48000.



  • 13.  Re: Robots installed from an image.

    Posted 12-03-2018 09:29 AM

    hubs communication over port 48002, except for hub < tunnel > hub, which is 48003 by default.



  • 14.  Re: Robots installed from an image.

    Posted 12-03-2018 01:36 PM

    The error "_command failed: communication error" indicates that the system you are running pu.exe from does not have a network path to the server /DOMINIO/HUB_SECUNDARIO_01/vdictx04. Ping and telnet might work, that in no way means that UIM knows that it's possible, only that if everything UIM knows about the network is correct that there's nothing physical preventing it from working..

     

    The first step in diagnosing that is to find out if the primary hub knows about the other one:

     

    From the primary run

     

    pu.exe -u USERADM -p XXXX  hub nametoip /DOMINIO/HUB_SECUNDARIO_01/vdictx04

     

    It should give you an IP and port back of the first hop in the path to that system.

     

    If it does, log into that identified system and issue the same command. At some point it should fail.

     

    On failure of nametoip, you've identified the system in the network path that doesn't know how to get to the desired system. Fixing that depends on a bunch of things. And this is also something that you should be able to have a conversation with support about. 



  • 15.  Re: Robots installed from an image.

    Posted 12-03-2018 02:51 PM

    E:\Nimsoft\bin>pu.exe -u USERADM -p XXXXX SPOBRPRD01/SER/HUB_S
    ECUNDARIO_01/vdictx04
    Dec 3 17:48:04:084 pu: SSL - init: mode=0, cipher=DEFAULT, context=OK
    _command failed: communication error



  • 16.  Re: Robots installed from an image.

    Posted 12-03-2018 02:57 PM

    If that is exactly what you typed, you have the format of a nimbus address wrong - it will begin with a /.

    And it will have three parts, yours looks to have 4.

     

    it should be /domain/hub/robot



  • 17.  Re: Robots installed from an image.

    Posted 12-03-2018 03:08 PM

    E:\Nimsoft\bin>pu.exe -u USERADM -p XXXX SER/HUB_SECUNDARIO_01/vdictx04
    Dec 3 18:06:49:248 pu: SSL - init: mode=0, cipher=DEFAULT, context=OK
    _command failed: communication error



  • 18.  Re: Robots installed from an image.

    Posted 12-03-2018 03:55 PM

    First letter of a full nimbus address will be a /

     

    You have 

     

    SERASA/HUB_SECUNDARIO_01/vdictx04

     

    should be

     

    /SERASA/HUB_SECUNDARIO_01/vdictx04



  • 19.  Re: Robots installed from an image.

    Posted 12-04-2018 06:00 AM


    E:\Nimsoft\bin>pu.exe -u useradm -p XXXX /SERASA/HUB_SECUNDARIO_01/vdictx04
    Dec 4 08:57:46:250 pu: SSL - init: mode=0, cipher=DEFAULT, context=OK
    Dec 4 08:57:46:251 pu: nimCharsetSet() - charset=
    _command failed: communication error



  • 20.  Re: Robots installed from an image.

    Posted 12-04-2018 02:50 PM

    Apologies, I made an assumption here that misguided you because your examples changed along the way.

     

    pu.exe -u useradm -p XXXX /SERASA/HUB_SECUNDARIO_01/vdictx04/controller probe_verify hdb

    pu.exe -u useradm -p XXXX /SERASA/HUB_SECUNDARIO_01/vdictx04/controller probe_activate hdb

    pu.exe -u useradm -p XXXX /SERASA/HUB_SECUNDARIO_01/vdictx04/controller probe_verify spooler

    pu.exe -u useradm -p XXXX /SERASA/HUB_SECUNDARIO_01/vdictx04/controller probe_activate spooler



  • 21.  Re: Robots installed from an image.

    Posted 12-06-2018 02:54 PM

    the script has the space conform was reported, the correct way.

    I ran the command step by step to validate the probes on the agents and it worked, as the log:

    Address:/SER/HUB_SECUNDARIO/vdihs5/controller Request: probe_activate
    ====================================================================== ====
    Dec 6 17: 20: 45: 648 pu: SSL - init: mode = 0, cipher = DEFAULT, context = OK
    Dec 6 17: 20: 45: 648 pu: nimCharsetSet () - charset =
    ====================================================================== ====
    Address:/SER/HUB_SECUNDARIO/vdihs5/controller Request: probe_verify
    ====================================================================== =

    But I put the full path in the direct script. My doubt would be in the variable:
    SET SHOSTNAME=/SER/HUB_SECUNDARY/%1/controller/probe_verify
    In the parameter "% 1" is the variable that represents the hostname by the nimsoft NAS. How can I verify this item?



  • 22.  Re: Robots installed from an image.

    Posted 12-03-2018 02:58 PM

    Are you doing this for a Citrix Golden Image setup environment?

    If so don't pre-install the robot.

    Just have a script (ps1) run on the box that

       > Checks if the hostname is the golden image name and if so exit the script.

       > If not then run the robot silent bat file installer which installs the robot fresh.

    Then have the request.cfg already in the Program Files\Nimsoft directory and when robot starts, it will call the SuperPack from its local hub's distsrv probe to deploy all the required probes. 

    Just do it this way.



  • 23.  Re: Robots installed from an image.

    Posted 12-03-2018 03:39 PM

    We use Citrix Provisioning 7.6 with Gold Image that replicates to 28 servers



  • 24.  Re: Robots installed from an image.

    Posted 12-07-2018 07:57 AM

    For those that do images regardless of Citrix, these steps work all the time.

     

    1. Install robot in with the Cloud install option and set the Reboot to 1 to activate the probe.
    2. Make a copy of the \Nimsoft folder and put it on the file system to be used in following a step.
    3. Create a "request.cfg" file and copy it into the root of the Nimsoft folder.  This will copy down any probes and probe configs.  You can also just create one nice SuperPackage as well.
    4. Prior to "sealing the image" make sure the Server Admin adds to their script to:
      1. stop the Nimsoft Service,
      2. Delete the contents of the Nimsoft folder
      3. Copy the contents of the Original Nimsoft folder into C:\Program Files\Nimsoft
    5. Have the Admin seal the image.

     

    This works like a charm everytime as long as the Admins perform these step every time the open and seal an image.



  • 25.  Re: Robots installed from an image.

    Posted 12-07-2018 11:27 AM

    To add to Jay's comment, which by the way is exactly how we manage the robot on our Citrix images, I'm not a fan of repetitive tasks or burdening someone else with a bunch of steps when and if I need to make an architectural change.

     

    So to take Jay's comment a step further I have configured our superpackage referenced by the request.cfg file to also modify the controller to set the hub for which the robot will be reporting into going forward.  This way when the robot reports into the primary hub initially on startup it is reconfigured to another hub automatically.  If I ever want to change where new robots report to all I have to do is modify the superpackage.  I don't have to go to my Citrix or other admins and ask them to modify every golden image or whatever image it may be (I think you can image how time consuming that can be).  I've taken care of the change in a couple clicks and its immediate vs waiting on someone else and hoping they performed the change well.

     

    In your superpackage controller tab:

    You will need a robot.cfx config file.  In order for this to work, you must add the parameter "hub_dns_name =" to the config list and its name should be the same as that of your "hubrobotname = " parameter.  Without the hub_dns_name parameter added it won't overwrite the existing value if one exists and thus I found the robot will not make the move. 

     

    Use this as your template for your robot.cfx file:

    <controller> overwrite
       domain =
       hub_dns_name =
       hubip =
       hub =
       hubrobotname =
       hubport =
       first_probe_port =
       secondary_domain =
       secondary_hub =
       secondary_hubrobotname =
       secondary_hubip =
       alarm_level_spoolererror =
       unmanaged_security =
       temporary_hub_broadcast =
    </controller>