Hi Everyone, thanks for the suggestions ... another quick update .. it appears like my issue with the odd vm not showing its Host details is because in one of my examples I had 3 vm's .. different names but with the same serial number. From what I read in another forum thread, the uuid's must match before devices are updated and there must only be one unique uuid per vm. I know what happens in our environment, they reuse the vm's changing their names but keep the same serial number which messses us up in the Flexera world. In this example I have simply deleted the other 2 devices with the same serial number / uuid and will check things tomorrow after the vcenter rule runs again tonight. Will update things after I see what happens tomorrow after the rule runs. Here is a quick copy and paste from that other forum topic .... For vmguests, duplicate serial numbers are a strong indication that the uuids are identical as well (this is what the serial number based on). Because this uuid is not unique FNMS cannot do the guest-host join, as it doesn't know which host to choose. ... View more

Hi Everyone, I took some time to look at this a little deeper and part of the struggle was my lack of knowledge when it comes to API's and Curl formatting. I was able to sort out why I was not getting what I was expecting by  lot of trial and error but eventually got it. Here is the Curl I was trying to use  .. its the Devices - Get Devices one "https://api.flexera.com/fnms/v1/orgs/{orgId}/devices/installed-software?os=&softwareTitle=&publisher=&softwareStatus=" To start off I was simply running this using my "orgid" and left everything as is  .. it seemed to run but it finished after about 20 minutes with No Data Found. I then started to populate some of the parameters with legitimate details and like magic it worked .. showing a "Completed" in the status. Please note that when you first run this, you get a status of Created, then it will update to In Progress and then if successful to Completed. It takes a bit of time so be patient .. just resend the message every so often until you see it end  .. a completed time will show up. For you experts .. the following is probably already known but for folks like me  with very little expertise in this its a must. I found that if you are not going to populate one of the parameters with something, remove it from the string or else it will return No Data Found. I guess because the parameter is there it takes it as being blank and then tries to match that .. not 100% sure but it certainly seemed that way. I tried leaving the softwareStatus=  as blank and it brought back no data found but if I simply removed that parameter all togeather it worked fine.   Here is what worked in terms of a populated Curl message with all the parameters populated. I removed my actual org id and replaced it with xxxxx.   https://api.flexera.com/fnms/v1/orgs/xxxxx/devices/installed-software?os=SunOS 5.11&softwareTitle=Infoscale 7.4 Availability&publisher=Veritas&softwareStatus=unmanaged Hope this helps some other folks who like myself know enough to be dangerous in terms of API's and Curl formats. Bruce ... View more

Hi Everyone, I just wanted to provide an update on this to perhaps assist others in the future who experience similar error messages. Turns out it was some stale data in the Beacon table/s that was being captured in the Beacon Policy that caused some additional packages to be downloaded. In my scenario it was downloading  Beacon versions of 13, 16 and 17. My current version was 16 when the errors began, it was suggested to upgrade the Beacon version because 16 was no longer available. I went ahead and upgraded all of my 5 Beacons to 17 but the trouble still remained afterwards, however, version 16 was removed from the list of packages being downloaded. After looking at the packageretriever logs and the Beacon Policy we could see that version 13 was still being picked up and in turn causing the downloading errors. By checking the dates on the Downloaded packages which are kept locally on the Beacons we were able to clearly identify what package version/s were causing the trouble. Engineering became involved and identified that the Beacon Table had some old versions which we being included into the Beacon Policy which triggered the additional packages being downloaded and subsequently causing the authenticode errors.   To resolve this, a Hot Fix was deployed to our Cloud environment instance that cleared out the old versions and everything returned to normal after the next updated Beacon Policy was received by the Beacons. The two key areas to look at were the packageretriever log file along with the Beacon Policy which both identified the old versions. In addition, the downloaded package dates which are kept locally on the Beacon Servers were also very important in piecing togeather what was occurring since the dates on the files reflected that something had happened recently as the dates should always be current. Hope that helps ... Bruce   ... View more