- ADOBE SHOCKWAVE PLAYER 12.3 INSTALL
- ADOBE SHOCKWAVE PLAYER 12.3 UPDATE
- ADOBE SHOCKWAVE PLAYER 12.3 FULL
- ADOBE SHOCKWAVE PLAYER 12.3 SOFTWARE
WinOffline just looks for this in the database and reflects this info in the scalability server summary. The AM agent, by default, actually inventories the signature file details and reports as part of the normal agent inventory. To be clear, WinOffline doesn't actually open/map a share to the SS and directly check the signature file timestamp.
In the WinOffline "Scalability Server Summary", the "Signature File Date" column comes from inventory reported by the AM agent on the SS. Set the job to run once only on all 'bad' machines and you will get all the signatures rebuilt.
If the SS' are OK, you can create an AM job to delete the file on the computers. If the problem is at the SS we can regenerate the sectors on the affected servers. If it is not found, you have missing signatures and may need to delete the XML file from all 'bad' machines to ensure it gets re-created.īefore doing that, try to determine if the bad systems are all on one or more scalability servers since the problem may exist on the SS. Next, open the XML file (in notepad or your editor of choice, not in IE which is the default for XML files) from a BAD machine, and search for 'Adobe Shockwave Player 12.3.1.201'.
If they are on the same Domain the number should be the same. To verify, first make sure the W00*.XML file on 'good' computers and 'bad' computers has the same number. Looks like there is a breakdown in the signatures file for some computers. I've been on a webex with a client all day, just got back to this. This transfer is done by Engine when the SS Collect job is executed.ĭo you see some errors during execution of SS Collect job ? In this case the problem could be in transfer of this file from DOMAIN to Scalability Server. Maybe the Scalability has not the latest version of file W00*.ZML ? This file is downloaded from the Scalability Server from directory C:\Program Files (x86)\CA\DSM\ServerDB\SECTOR\SSFW Maybe the version of file W00*.XML located under C:\Program Files (x86)\CA\DSM\Agent\units\00000001 on machines with problem is old. This signature has been created in November 2017 and here is its definition : It seems the missing signature " Adobe Shockwave Player 12.3.1.201" is a CA Provided signature which should be detected with Signature Scan.
ADOBE SHOCKWAVE PLAYER 12.3 UPDATE
will attempt to update themselves to the latest version.
ADOBE SHOCKWAVE PLAYER 12.3 SOFTWARE
It’s possible, especially for software like the examples you provided (shockwave) that in some cases the users allowed auto-update and some users did not. Last, find a couple of computers you can actually look at, and validate the inventory collected against what is actually shown in the ‘Add and Remove Programs’ or ‘uninstall a program’ control panel app. Validate that the inventory in the files matches what is shown in the console. dat file is the heuristic scan data, and the xml is the signature scan. These files are actually quite easy to read and show what inventory is actually being collected by the Agent.
ADOBE SHOCKWAVE PLAYER 12.3 INSTALL
These files are in ‘C:\Program Files (x86)\CA\DSM\Agent\units\00000001\uam\BAK’ assuming you used the default locations to install the agent, and the computers are 64-bit. Next, grab the ‘amapp.dat’ and ‘amsoft.xml’ files from a ‘good’ example and the same files from a ‘bad’ example. Next, since you said you have both signature and heuristic scans running, it would be helpful to know which scan found the software items in your examples below. Perhaps some inventory went missing at some point (a scalability server crashed and was rebuilt perhaps).
ADOBE SHOCKWAVE PLAYER 12.3 FULL
The first thing you should do is, on the computers with apparent missing items, force a full collect.