AP: Re-harvesting Learnings

Discussion created by Filip.Gasiorek on Jun 25, 2018
Latest reply on Oct 15, 2019 by Filip.Gasiorek

During a recent customer re-harvesting project a number of Q&A learnings have been captured,  which maybe of use to the wider Snow AP community.  Please note that each Q&A is applicable to SLM Vn.8.3 and AP Vn.3.4.1, enjoy!




  • Q: Does un-selecting the "Available in Software Store" check box on the SLM "Store" tab exclude the application from re-harvesting?
  • A: Unselecting the “Available in Software Store” on the “Store” tab does not exclude the application from re-harvesting.


  • Q: In SLM, how can you exclude an application from re-harvesting?
  • A: To exclude an application from re-harvesting you must click on the “Uninstall Options” change button and select “No limited use”.  You must then click “OK” and then “Save” (top section of the Ui).  You can then either untick or keep the tick against  “Available in Software Store”, it makes no difference to the re-harvesting SLM API end point.


  • Q: Should I be checking the SLM API re-harvesting end-point?
  • A: Yes, check the FQDNforSLM/api/customers/X/appstore/applications/reharvestable/ API end point after enabling / disabling an application for re-harvesting to confirm the correct records are returned / removed.  This is especially important during testing when re-harvesting can often be initiated in quick succession.


  • Q: Are there any limits against the Identifier field on the "Store" tab in SLM?
  • A: The Identifier field on the SLM Store tab is limited to 64 characters, check values if you are copying and pasting into this field to ensure no truncation.  The reason for the 64 character restriction is that the AD Schema limits Common Names, the values of the cn attribute, all objects (users, contacts, computers, groups) to 64 characters.  As this field was originally designed to store AD Group names this constraint is fitting. 


  • Q: Is the Identifier field strictly reserved for AD Group names?
  • A: It is possible to re-use the Identifier field and store e.g. - SCCM Collections if SCCM Collections are utilised for membership instead of AD Groups.


  • Q: Can Identifiers be shared across different applications in SLM?
  • A: Values entered into the Identifier field must be unique across the list of enabled application for re-harvesting in SLM and in some cases where e.g. - only a Uninstall Collection is required (or available) you will be forced into entering a dummy entry that should be ignored in the code, <dummy_install_id><delimiter><uninstall_id>, e.g. - C00001;C00002.  This can happen if applications have been manually installed (no install package) and multiple versions of said application share a single uninstall package.


  • Q: Should I reference names or Ids?
  • A: It is better to use Identifiers, IDs, than say (SCCM Collection) Names as names can be changed over time.


  • Q: What is the default duration that usage stats are kept for in SLM?
  • A: By default SLM stores 90 days of usage stats, some customers may choose to increase this.  Ensure that you familiarise yourself with the usage range you can work with, this is particularly applicable to "Uninstall settings for this application"  --> "Uninstall this application based on usage" re-harvesting setting.


  • Q: What provisioning type can be used for re-harvesting based on usage?
  • A: Re-harvesting based on usage can only occur against devices (and not Users).


  • Q: Should I address duplicate records in SLM before, during or after re-harvesting?
  • A: Minimise complications as a consequence of duplicate devices (or users) in SLM and always ensure that any duplicates are resolved before AP re-harvesting schedules are triggered.




  • Q: At what point in the re-harvesting process should I apply exclusions?
  • A: Use the "reharvest slm applications" activity to filter out all exclusions before invoking the uninstall workflow.  This will optimise the process and reduce the amount of times the uninstall workflow is called.


  • Q: Do I need to know and understand the existing uninstallation process?
  • A: Ensure you are familiar with the existing uninstallation process and the deployment technology that is employed to push uninstallation packages out. It is important to understand whether a device (or user) object needs to be added to a membership group in AD, or whether the process is more convoluted and the defined object should be removed from an Install Collection before being added to an Uninstall Collection.  This will determine the Uninstall workflow activities. 


  • Q: What information do I need in order to communicate with SCCM?
  • A: As a minimum ensure you have the following information to communicate with SCCM Server via wmi: Server Name, Site Code, Service Account e.g. - AP_WorkflowEngine.


  • Q: What permissions do I need in order to communicate with SCCM during software re-harvesting?
  • A: Ensure that the chosen service account e.g. - AP_WorkflowEngine service account has sufficient permissions in SCCM to make wmi calls, for verifying: Collections, Resources, Collection Membership.  Sufficient permissions should also be granted for adding and removing resources to / from Collections but this should be restricted to only the Collections related to re-harvested applications. Targeted permissions are always safer, especially during automation procedures!


  • Q: When should I use exclusion Collections / Groups?
  • A: Consider using exclusion Collections / Groups for larger volumes of devices (or users) that should be excluded from re-harvesting for a given application.


  • Q: Are there any differences between the "Store" tab fields and custom fields?
  • A: The SLM Store tab field values are made available in the SLM re-harvesting API end-point against application and device / user records.  If you are also reading custom field values from SLM, these will be accessible per application or device / user.  This may impact how you use each field type value in your re-harvesting activity or how this data is stored to avoid repetition.


  • Q: Can I store custom information in the AP database/s?
  • A: No custom data or custom objects should be created in the SnowAutomationPlatformDomain or SnowAutomationPlatformAzman databases.  Instead if customised data has to be stored for use with AP, create a new database e.g. - SnowAutomationPlatformCustomerData.


The above has been identified in-part due to a fruitful partnership between a customer, partner and vendor - I therefore encourage you all to adopt a pro-active approach ensuring maximum learnings and understanding between all stakeholders, this is particularly important where customisation is required.