Have you all seen a scenario where app portal removes a collection but continues to attempt to insert into that collection? In the log excerpt below you can see the collection deleted on 3-5 but on 3-26 it is attempting to insert again.
Excerpts take from ESDWebService and CollectionInsert_Error logs.
<![LOG[Deleted collection CG101228]LOG]!><time="12:06:07.000+240" date="3-5-2021" component="Web Service" context="" type="1" thread="127" file="Web Service">
<![LOG[Error Inserting machine **Machine Name** into Collection CG101228 Exception Occurred. Message: Object reference not set to an instance of an object.. StackTrace: at AppPortal.WMI.SCCM.AppPortalSccm.AddDeviceToAppCollection(String deviceName, String collectionID)]LOG]!><time="08:43:01.000+240" date="3-26-2021" component="Web Service" context="" type="1" thread="17" file="Web Service">
‎Mar 26, 2021 10:09 AM
I don't think that there is a way to get the same collectionID recreated, but you can simply open your catalog item, go to the deployment->configMgr tab,, and delete the existing deployments.. You can then use the "add package" button to add the package/application again.. Any existing requests which are pending insert should pick up on the new collection which is created.
‎Mar 26, 2021 11:13 AM
I don't think there is an easy (or recommended) way to recreate a collection in SCCM with that same ID. But you could open that catalog item and delete and recreate the deployment (or perhaps delete the SiteToAdvert entries for that catalog item and then create a new deployment through the UI), which should create a new collection in SCCM and associate that to the existing catalog item. In that case, I don't think you would even need to cancel/recreate the requests. I think they would pick up the change and attempt to insert into the new collection. Another option could be to create a new collection and deployment directly in SCCM and then update the corresponding entries in the SiteToAdvert table to reflect the new values for SMSPackageID, AdvertID, and CollectionID. I'll defer to @CharlesW to see if he has a preference/suggestion.
‎Mar 26, 2021 11:18 AM
Is it possible you had two catalog items pointing to the same collections (shouldn't happen under normal circumstances, but it is technically possible) and one of them got archived, which deleted the collections, but the other is still trying to use them for requests? Or perhaps there was an in-flight request already being processed when the catalog item was archived and the request didn't get canceled (I would expect App Portal should have logic to cancel requests where the catalog item gets archived, but I could be wrong). @CharlesW, thoughts?
‎Mar 26, 2021 10:42 AM
That's a good thought and I'll check on it. It looks like there are about 27 requests attempting to be inserted into this deleted collection. Worst case scenario we can delete those requests and have the users submit a new request which should generate a new collection for that catalog item right?
‎Mar 26, 2021 10:53 AM
Yes, when you archive a catalog item, pending requests should be canceled.. Check WD_SiteToAdvert.. Do you see collection ID CG101228 anywhere under the CollectionID column? You'd probably know if you had done this, but it is possible to use the ESD Web Service to delete a collection, without making any changes in the App Portal site.. In this case, the insert attempt would still occur... Again, a theoretical scenario....
NOTE: I'd also expect to see some indication of the deletion in the DeleteESDObjects.log file on the App Portal server, if the catalog item had been archived or the package/application updated.
‎Mar 26, 2021 10:54 AM
Yes, manually canceling via a query is an option. I typically use a query similar to the following to do so:
UPDATE WD_PackageRequests SET IsLeased = 0, LeaseExpire = NULL, Deleted = 1, Inserted = 0, InsertDate = NULL, monitor = 0 WHERE requestID in (1,2,3,4)
Obviously, replace “1,2,3,4” with the requests that you wish to cancel…
Note: it’s typically better to run the query after stopping the ESD service, as the ESD service may overwrite the changes made by the query.
‎Mar 26, 2021 10:56 AM
Checked the WD_Sitetoadvert table. The collection id still exists. Checked the catalog item in the dashboard and it still has that collection associated to it. What is the recommended approach to getting that collection recreated?
‎Mar 26, 2021 11:06 AM
I don't think that there is a way to get the same collectionID recreated, but you can simply open your catalog item, go to the deployment->configMgr tab,, and delete the existing deployments.. You can then use the "add package" button to add the package/application again.. Any existing requests which are pending insert should pick up on the new collection which is created.
‎Mar 26, 2021 11:13 AM
I don't think there is an easy (or recommended) way to recreate a collection in SCCM with that same ID. But you could open that catalog item and delete and recreate the deployment (or perhaps delete the SiteToAdvert entries for that catalog item and then create a new deployment through the UI), which should create a new collection in SCCM and associate that to the existing catalog item. In that case, I don't think you would even need to cancel/recreate the requests. I think they would pick up the change and attempt to insert into the new collection. Another option could be to create a new collection and deployment directly in SCCM and then update the corresponding entries in the SiteToAdvert table to reflect the new values for SMSPackageID, AdvertID, and CollectionID. I'll defer to @CharlesW to see if he has a preference/suggestion.
‎Mar 26, 2021 11:18 AM