Hi Everyone, I have noticed starting this week that all of my 5 Production Beacons are identifying this particular error. Too much of a coincidence that all 5 are showing this error. When I look at the package retriever log file it shows the following error message (see below) .. funny thing is that the authenticode check passes a minute or two earlier for other cab files.
FAILED Authenticode check of "C:\Users\PY4P0S~1\AppData\Local\Temp\NSC2175.cab"
I will open a case but thought I would mention it here as well .. thinking others are possibly seeing the same
thing.
Bruce
‎Feb 09, 2022 08:18 AM
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
‎Mar 16, 2022 07:40 AM
I haven't heard of anybody else experiencing this particular error.
However that doesn't necessarily mean it isn't happening for others: the consequent impact of this error may be minimal or not visible at all (depending on which particular downloaded file(s) it is affecting), and so may not very visible to others unless they are specifically looking for a message like this in log files.
‎Feb 11, 2022 12:43 AM
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
‎Mar 16, 2022 07:40 AM