I am looking to understand the process as well as any potential ramifications of attaching an existing SCCM collection/deployment to an AppPortal catalog item in order to minimise the number of collections used within the environment. The existing SCCM collections i would like to use are all based of AD group Membership and i would like to use the "Remove from collection when complete" Cleanup option to remove any Direct Membership upon successful install and then apply the "Add to group after successful install" so the device doesn't fall into Scope of our existing uninstall collections after deployment. Any help in understanding this process and any potential effects would be appreciated.
You can attach an App Portal catalog item to an existing deployment only by using functions such as AttachConfigMgrApplicationDeployment(), or AttachConfigMgrPackageDeployment() in integration.asmx, I'd guess that this would give you the behavior that you are trying to archive, though it seems cumbersome considering that you are only trying to reduce the number of collections.. "Perhaps" a better approach would be to use a general catalog item to add/remove devices from AD groups, and let SCCM handle the deployment entirely. The one downfall that I can think of in using this approach would be that you are not going to get the status back from SCCM.
You can attach an App Portal catalog item to an existing deployment only by using functions such as AttachConfigMgrApplicationDeployment(), or AttachConfigMgrPackageDeployment() in integration.asmx, I'd guess that this would give you the behavior that you are trying to archive, though it seems cumbersome considering that you are only trying to reduce the number of collections.. "Perhaps" a better approach would be to use a general catalog item to add/remove devices from AD groups, and let SCCM handle the deployment entirely. The one downfall that I can think of in using this approach would be that you are not going to get the status back from SCCM.
In addition to not getting install status back, you also wouldn't be able to use general catalog items for license reclamation. I don't recommend that approach.
What is the reason you're trying to reduce the number of collections? There really shouldn't be a performance impact. App Portal creates direct membership collections with no evaluation schedule and no incremental evaluation, so having a lot of collections will not keep collection evaluator busy. Also, all of App Portal's collections are isolated to their own folder, so they shouldn't get in the way or be confused with other collections.
Can you tell me why you need your other collections and AD groups? It seems like a lot of unnecessary overhead to have to manually create/maintain collections and AD groups. Why not just use the App Portal collections and eliminate your other collections?
Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".
Is it possible to share this script with me as well.
Thanks in Advance
I'm not sure what script you're asking to be shared. If you're referring to the post from Charles about using the API methods to attach an existing deployment to a catalog item, we don't have a script already written for that, but the API's are available. Have you seen this other post from Charles describing how to call App Portal API's from PowerShell? That may be of help to you in writing a script to leverage these API methods.
Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".
