cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Collection Insert errors for machines that do not exists in SCCM or FlexNet

I was going through the CollectionInsert.log for today and noticed that starting at 3:00 pm there were many machines receiving an error "FAILED to insert Machine <machine name> for catalog item Microsoft Office Visio Standard 2013 into collection (collection id) for Request ID xxxx.  This is happening for multiple catalog items and machines.

The request id's were not in a range I see today.  In reviewing further, the machines don't exist in SCCM or FNMS and they are not in the My Apps Alert table, but I was able to find the old requests for these machines.  The requests are from 2016 and 2017 and the request itself shows the original install successful.

I'm wondering what would trigger a collection insert for these machines today?  Is it because the machine was removed from SCCM based on our rules for machine cleanup?  I don't want to delete old orders so I'm wondering how to stop the machines from being inserted to the collections so we're not filling up the log with errors that don't require attention.

(1) Solution
CharlesW
By Level 12 Flexeran
Level 12 Flexeran

App Portal will happily try to insert devices into the target collection indefinitely if a failure occurs during an insert. If there is a problem when attempting to insert the device, App Portal will change the insertDate in WD_packageRequests to one hour in the future, and try again after the hour has elapsed. 

Typically a device will fail to insert in one of the following three scenarios:

1. The device no longer exists in SCCM.. More often than not, I see this occur when somebody has enabled leasing on their catalog items, and set the lease duration to a large number. For example, two years.. In this case, App Portal will try to reclaim the software after the two year period has elapsed, only to find out that the machine no longer exists in SCCM (more accurately the resource ID for the machine name can not be found). This might also be triggered if a request was not approved for a long period of time, only to be approved at a much later date.. Once approved, the insertDate is set, and if the device no longer exists, the problem will occur.

2. The target collection is missing in SCCM. I typically see this when somebody has inadvertently deleted collections in SCCM.

3. Somebody has enabled uninstallation for a catalog item by selecting the "Enable uninstallation" setting on the catalog item, but has not added an uninstall deployment. End users may then submit an uninstall request, even though there is no uninstall collection actually tied to the catalog item.

While a single failed insert is not going to cause any harm, a large number of failed inserts can actually break the insert process completely. App Portal will only attempt to insert "X" devices in each insert iteration, where "X" is defined by the database setting "RequestProcessingBatchSize".. By default, this value is 100. If the number of failed inserts exceeds this number, then it is possible that the "good" inserts will never be processed.. If you run into a scenario where inserts are not being processed correctly, and you see a large number of failed inserts, then the first thing to try would be to try increasing the "RequestProcessingBatchSize" using the following query:
 

update wd_appsettings set value = '1000'  where keyname ='RequestProcessingBatchSize'

After doing this, you can then cancel the offending requests, using a query similar to the following:

UPDATE WD_PackageRequests SET IsLeased = 0, LeaseExpire = NULL, Deleted = 1, Inserted = 0, InsertDate = NULL, monitor = 0 WHERE requestID in ( 1, 2, 16, etc.)

NOTE: We do have an open enhancement request which asks that a "failed insert timer" be added to the product, so that an insert will not occur indefinitely.

View solution in original post

(3) Replies
CharlesW
By Level 12 Flexeran
Level 12 Flexeran

App Portal will happily try to insert devices into the target collection indefinitely if a failure occurs during an insert. If there is a problem when attempting to insert the device, App Portal will change the insertDate in WD_packageRequests to one hour in the future, and try again after the hour has elapsed. 

Typically a device will fail to insert in one of the following three scenarios:

1. The device no longer exists in SCCM.. More often than not, I see this occur when somebody has enabled leasing on their catalog items, and set the lease duration to a large number. For example, two years.. In this case, App Portal will try to reclaim the software after the two year period has elapsed, only to find out that the machine no longer exists in SCCM (more accurately the resource ID for the machine name can not be found). This might also be triggered if a request was not approved for a long period of time, only to be approved at a much later date.. Once approved, the insertDate is set, and if the device no longer exists, the problem will occur.

2. The target collection is missing in SCCM. I typically see this when somebody has inadvertently deleted collections in SCCM.

3. Somebody has enabled uninstallation for a catalog item by selecting the "Enable uninstallation" setting on the catalog item, but has not added an uninstall deployment. End users may then submit an uninstall request, even though there is no uninstall collection actually tied to the catalog item.

While a single failed insert is not going to cause any harm, a large number of failed inserts can actually break the insert process completely. App Portal will only attempt to insert "X" devices in each insert iteration, where "X" is defined by the database setting "RequestProcessingBatchSize".. By default, this value is 100. If the number of failed inserts exceeds this number, then it is possible that the "good" inserts will never be processed.. If you run into a scenario where inserts are not being processed correctly, and you see a large number of failed inserts, then the first thing to try would be to try increasing the "RequestProcessingBatchSize" using the following query:
 

update wd_appsettings set value = '1000'  where keyname ='RequestProcessingBatchSize'

After doing this, you can then cancel the offending requests, using a query similar to the following:

UPDATE WD_PackageRequests SET IsLeased = 0, LeaseExpire = NULL, Deleted = 1, Inserted = 0, InsertDate = NULL, monitor = 0 WHERE requestID in ( 1, 2, 16, etc.)

NOTE: We do have an open enhancement request which asks that a "failed insert timer" be added to the product, so that an insert will not occur indefinitely.

 Our SCCM team is doing cleanup on old machines and removing them from SCCM so I'll update the old orders to stop them from trying to insert into collections.  Thanks Charles!

even we are facing similar issue since years, not even god knows how to resolve this.

we verified collections, machines and all are in place but still we see the issue.

out of hours of investigation from vendor too we found this occurs only after reboot of server.

🙂