App has been removed as part of Reclamation Process but user is still getting alerts

[Anonymous]

Basic Details:

1. App Name (Catalog Title): "PEAK SYSTEMS TECHNIK GMBH PCAN Explorer (WITH CANDB AND J1939 ADD-INS) 6.1.1.1798"

2. Catalog Title/The App is disabled in AppBroker

Background:

• So install picked up March 21.
• Alert generated March 26.
• User had this version uninstalled/removed as of March 31.
• Alert still active / not expired and generating emails every week for past several weeks.

Queries:

1. Software is no longer installed on this device but the alert is not getting cancelled out. Why is alert not getting cancelled out? Is it because the catalog item is now disabled? Does the catalog item being disabled disrupt AppBroker’s ability to cancel out an alert?
2. What should we do in cases where Has Uninstall Program = False, Enabled = True for a given My Apps policy? We do not want to just bulk delete alerts because we want to maintain history, but should we cancel any alerts not already expired? Can we have query for this?

Currently we have 25 My Apps policies meeting this Has Uninstall Program = False, Enabled = True. This happens when we upgrade certain software to later versions. So this information will help us define a better maintenance process when one software’s older version becomes inactive and a later version/new catalog item version is active.

Expecting your kind assistance with this! Many thanks in advance!

Best regards,

Sourav Sengupta

[CharlesW · Accepted solution]

Disabling a campaign will not make any change to the existing alerts, though it will prevent further processing of the alerts. Deleting the campaign will expire all alerts that were created by the campaign. Alerts are never deleted from the WD_MyAppsAlert table.  

[CharlesW · Accepted solution]

Yes, deleting a campaign will remove the associated row from WD_MyAppsLRTargets. This is the primary table where campaigns are stored. Setting expired =1 in the WD_MyAppsAlert table would probably work, but I've not really tested doing this, so this is only an assumption. I'd rather delete the rows from the WD_MYAppsAlert table, rather than potentially breaking records by setting individual columns within the table. 

[Anonymous]

Also, attaching the log of the system for any reference.

[CharlesW]

Was the software uninstalled via the My Apps process, or through some other approach? Once the My Apps process submits the uninstall request, then the alert should be expired. If the uninstall was performed outside of the My Apps process, then I'd expect that the alert could get stuck as you describe. 

If "Has uninstall a program" is set to false, then I'd typically expect that the software could be uninstalled only using Smart Uninstaller. If you are disabling the catalog item, which will set "has uninstall program" to false,  then I can certainly foresee problems. 

I might suggest trying to set expired = 1 in WD_MyAppsAlert to see if this stops the alert from processing. 

[jdempsey]

Have you disabled the My Apps policies?  If you've disabled the associated catalog item(s) and don't have Smart Uninstall deployed, then there is no point in keeping the My Apps policy enabled.  You could either disabled it or delete it.  I don't believe deleting the policy should have any impact on existing alerts (@CharlesW, correct me if I'm wrong).

App Portal gets all of its inventory information from FNMS.  FNMS gets that inventory from SCCM or other sources.  Check to make sure that FNMS knows the software has been removed from that device.  If FNMS reports the software as not being installed on the device, then App Portal should detect that and mark the alert as being uninstalled.  If FNMS reports the software as still installed, then check your inventory sources to understand why (maybe the SCCM client on the device is broken?  maybe the SCCM connection to FNMS is broken?).

Correction: I guess the inventory from FNMS would only be used in the initial evaluation of the My Apps policy in order to generate the alert.  I think the uninstall status would have to come from SCCM (assuming there is an active catalog item with an uninstall deployment, My Apps submits a request to uninstall, and then App Portal reads the status from SCCM indicating the software has been uninstalled).  So, to Charlie's earlier post, if there is no active catalog item with an uninstall deployment, an uninstall request can't get submitted, so the alert would remain until it expires (or is manually expired).

[CharlesW · Accepted solution]

Disabling a campaign will not make any change to the existing alerts, though it will prevent further processing of the alerts. Deleting the campaign will expire all alerts that were created by the campaign. Alerts are never deleted from the WD_MyAppsAlert table.  

[elewis]

Does deleting the campaign delete the record of the campaign in this table also: WD_MyAppsLRTargets ? I ask because we have some queries that bridge the alert data to the catalog items using Flexera IDs between the two tables and just trying to assess impact depending on whether we just disable the campaigns and query update Expired = 1 for the pending alerts OR just delete the campaign. 🙂 Arguably we could just bridge directly from the Alert data table to the Catalog data with FUID/Flexera ID also. Thanks! 

[CharlesW · Accepted solution]

Yes, deleting a campaign will remove the associated row from WD_MyAppsLRTargets. This is the primary table where campaigns are stored. Setting expired =1 in the WD_MyAppsAlert table would probably work, but I've not really tested doing this, so this is only an assumption. I'd rather delete the rows from the WD_MYAppsAlert table, rather than potentially breaking records by setting individual columns within the table. 

[elewis · Accepted solution]

Based on all of this, we will go ahead and delete campaigns and make sure our queries do not rely on the LRTargets table but rather the Alerts and WebPackages table to report on reclamation uninstall data. We did one lower volume record today and behavior was as mentioned - active alerts got Expired but request history and reporting data still present. Thanks!