# DX Infrastructure Management

## 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 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 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

• #### 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

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:

====================================================================== ====
Dec 6 17: 20: 45: 648 pu: SSL - init: mode = 0, cipher = DEFAULT, context = OK
Dec 6 17: 20: 45: 648 pu: nimCharsetSet () - charset =
====================================================================== ====
====================================================================== =

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.

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.

<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 =