CA Client Automation

We build a lot of queries based on deployed software and the presence/absence of deployed/detected software in the 'Installed Packages' node in ITCM. The reason we do this is we deploy many security software(s) via DSM and want to know immediately if a system is missing these. When the software is deployed it is reported into the installed packages node immediately and we don't have to wait for slow AM signature scans or run an AM heuristics scan and update the queries. Our queries are up to date because the installed packages node is up to date.  

So, whats the best way of keeping this node up to date? At times there are manual deployments of software or new builds and we want their inventory in relation to software updated in DSM as soon as the node registers. To date we have run a daily SCAN .MSI job against the SD agent and this works but has the eye sore of  many SCAN .MSI jobs appearing in the jobs list. We then script the removal of these jobs for the jobs list to make them more readable. Could we achieve the same with a repetitive AM job that calls sd_msiexe /scanmsi or the like? 

Hi Darragh

There is an agent command line interface that you can use to add an install record for a manually deployed package

sd_acmd---Agent Administrative Commands - CA Client Automation - 14.0 - CA Technologies Documentation 

As long as the package is already in the library this will add an install record into "Installed Software". 

Does this help?

Rich

Not really!  I guess what I am asking is how to bets run regular jobs to keep the 'Installed Packages' node up to date? use SCAN MSI job on Software Delivery agent or asset job?

Assuming you have a list of what packages you are interested in, Writer a script that detects those and run that script on a periodic basis.  But why would it not be current on its own?

Well, for example, if a helpdesk person removes/installs some MSI based software on an asset, I want that to show up as detected software in the 'IN stalled Packages node' ASAP. 

There is an ancient and little known art form which has been referred to in long-lost parchments, known as ‘Software Detection Scripts’ which may help. The attached document was written in the dark old days of SDO 4.0 (2002) but it still works its magic yet today.

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Stephen.McCormick@ca.com

<mailto:Stephen.McCormick@ca.com>

Hi Darragh

Do you want to detect a specific list of applications or do you want a generic scan to find everything? If you have a specific list then you can use the software detection scripts as per Steve M's post. If you want a more generic scan then you will need to continue to use the scan MSI job.

In answer to your initial question yes you can run the scan without an SD job. You can call sd_msiexe.exe directly and initiate the scan see sd_msiexe.exe--Perform Windows Installer Tasks - CA Client Automation - 14.0 - CA Technologies Documentation  for full details

We could also ask if we are really addressing the core problem. It could be possible to view the core problem as how to prevent the need to run manual installs \ uninstalls. For instance if you mandated that all software installs were performed by client auto and enforced this then the problem goes away. 

You could use the software catalog to allow self service and also allow the helpdesk engineers to request uninstalls and re installs that way rather then running them manually. You could even enforce this by restricting the rights of users so they are not able to perform local operations. This way the records are never out of synch and you have accurate records of the installed security softwares you are interested in. Of course this may not be the way you wish to go and that is fine I just thought I would mention it.

Hope this helps.

Rich

Yes, I want to detect all MSI packages. My issue is that recently, all our agents were moved from one DM to a new one. The detected packages (i.e. packages that are not in software delivery) did not carry over hence I wish to list them. 

If I recall correctly from earlier in this thread part of your issue was cleaning up the MSI detect jobs, right? If you go to the Software Delivery Agent package in the software library and click on its ‘Installations’ branch then you can select any number of computers from the list, right click, and send the MSI detect procedure to all of them in a single job container. Simple cleanup – maybe that will help?

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Stephen.McCormick@ca.com

<mailto:Stephen.McCormick@ca.com>

If "Scan MSI" procedure is failed on your environment, please try following steps.

1.  Copy [Detect] under SD plugin in Software Package Library.

2. Paste the procedure to target agent.

3. After the software job complete, you can see SD Agent under [Installed Packages] of target agent.

4. Copy [Scan MSI] of same software package and paste it to the target.

5. After the job completion, You can see installed software using MSI

I hope this info helps you.

Thanks

Yas

Hi Darragh

Do you have the answers you were seeking on this?

Regards

Rich

Hi Darragh

Is thread now answered for you?

regards

Rich

Hi guys, apologies for the delay in coming back on this one. If I look at the reference here sd_msiexe.exe--Perform Windows Installer Tasks - CA Client Automation - 14.0 - CA Technologies Documentation  it looks like I need to specific some additional parameters. If I run the SCAN job from DSM explorer, running a trace reveals the actual command line run:

• SD_MSIEXE.EXE -scan mypcname 10.112.108.26 -out:C:\PROGRA~2\CA\DSM\Agent\units\00000001\usd\sdjexec\14438507-F290-454D-A479-759F4F03D05A.res 

The -cn and -out params are being passed it seems from the SD activate job so how to simulate when running as an AM job? if I simply run SD_MSIEXE.EXE -scan it does not seem to upload any scan results. 

The ‘-out:C:\PROGRA~2\CA\DSM\Agent\units\00000001\usd\sdjexec\14438507-F290-454D-A479-759F4F03D05A.res’ causes the sd_msiexe.exe program to write its output to the Software Delivery results file (this is the $rf parameter in an SD job). The $rf parameter expands to the full pathname of a special file which when populated causes the output to be uploaded to the output tab on the SD job. It is not applicable to AM jobs. I suggest if you are running this as an AM job you simply change this parameter to write to a local log file since there is no equivalent upload capability in AM jobs.

The $cn parameter is the computer name, you can use the $COMPUTERNAME$ environment variable for this variable.

As for seeing the output, since the desired end result here is to update the SD installation records, I expect you will have to run a JOBCHECK using ‘sd_acmd jobcheck’ to get the records uploaded. The sd_msiexe program only queues the records it finds, it doesn’t perform the actual upload.

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Stephen.McCormick@ca.com

<mailto:Stephen.McCormick@ca.com>

Thanks Stephen. So If I dump out to a file in the %tmp% directory, will sd_acmd jobcheck pick that up i.e. how doe sit pick up an arbitrary file? Does the sd_msiexe notify it of the data to uploaded 

No, unfortunately it is not an arbitrary file, it is a specific, named file in the Agent’s directory, and that is the ONLY file SD will pick up. The filename is actually the UUID assigned to the job, with a ‘.out’ extension, and it is only valid for SD jobs. You can see the name generated if you want by running a job with a batch file as follows:

@echo off

Echo %1

And call it with parameters:

$rf >$rf

In this case $rf is specified twice, once as a parameter to the batch file so it can output the name and once as a redirect.

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Tel: +1-731-676-4223

Stephen.McCormick@ca.com

<mailto:Stephen.McCormick@ca.com>

Hmm, so is there now way to force this at the agent?

I think you are really looking at this the wrong way. This file we are talking about is not the data you need, it is simply the log file which gets uploaded to SD so it can be examined in the SD job's results tab, when this command is run as an SD job. If you run this scan stand-alone or as an AM job, simply replace this file with a file in the temp directory, like '%temp%\MSIScan.log' so you can go look at it if you need to. The actual output you need is queued in the SD Agent for upload during the next jobcheck, so after the AM job runs this command, it should also run 'sd_acmd jobcheck', which will upload the data you need.

Stephen, I was misunderstanding you. I can confirm from testing tat the following would work to run a SCAN for MSI based installation at and agent and have the Installed Packages node update with same

• start /wait sd_msiexe -scan && sd_Acmd jobcheck /bg

I use the start /wait as another thread is spawned and we want to wait until its finished before gathering the results

PS: in terms of the job result tab on in DSM explorer, even on the SCAN MSI jobs run from  the SD procedure I have never seen any output for that procedure. Just interesting as you mentioned it. 

I mentioned it because you had previously provided the syntax which creates it. However, not all jobs produce such output even if the parameter is specified. Sometimes you only get job output if the job fails or reports some error.

In any case, seems like you got a resolution for your problem now, right?

Steve McCormick, ITIL

CA Technologies

Principal Services Consultant

Stephen.McCormick@ca.com

<mailto:Stephen.McCormick@ca.com>

Yes,all working great now