App Portal does not allow you to choose a specific deployment type for an application.  The deployment type is determined by SCCM based on the priority order and applicability rules configured within the application model.  If you need App Portal to use a specific deployment type, you would need to make a separate application in SCCM for that deployment type and configure App Portal to use that application. ... View more

To add to Chris' response, we wouldn't expect any need to increase hardware resources in SCCM just to accommodate App Portal.  Certainly, if the SCCM infrastructure is aging and struggling to keep up already, it may be time to upgrade servers, but generally, if the hardware is relatively current and sized suitably based on Microsoft guidance (https://docs.microsoft.com/en-us/sccm/core/plan-design/configs/recommended-hardware), you should be fine. A few things to note: The user/computer/relationship data sync process that runs on a nightly basis can take a long time if not configured properly.  The primary setting involved here is the "Page Size" setting under Site Management > Settings > Deployment > Common.  This page size defaults to a very small number (100, I believe).  For large environments, that will cause the sync process to take a really long time.  I generally set this to somewhere between 5,000 and 10,000.  You can look at the Datasync.log to see when your sync process starts and ends, then make adjustments to the page size and see what impact that has on the sync time.  Generally, larger values will cause the sync to complete more quickly (though there will eventually be a point of diminishing returns and potentially a tipping point where things go more slowly).  Just experiment and see what works best for your environment.  One thing to note is that if an error occurs during syncing of a particular record, all other records after that within a "page" will be discarded for that sync cycle, so there is a trade-off between performance and discovering new objects.  You should always keep an eye on the sync logs to make sure you aren't running into errors that prevent you from having full visibility to all of the users/computers in your environment. The data sync cycle is scheduled to run at 02:00 local time on the server.  If you have backup jobs or other routine maintenance scheduled on your SCCM database at that time, you should change the start time so it doesn't conflict with those other activities. In addition to managing collection memberships in SCCM, App Portal also queries the SCCM database on a regular basis looking for status of deployments.  Depending on the volume of requests and how long those take to complete, you could end up with a lot of "status" data being pulled on a frequent basis.  If you feel that your SCCM site is being bogged down by App Portal, you may consider adjusting the Frequency to update last status state timer under Site Management > Settings > Timers to check for status less frequently.  Of course the trade-off is that requests that complete very quickly will take a little longer to report completion in App Portal. ... View more

Look at WD_VPackageProperty.  All visibility conditions will be stored in that table, but collections will be stored by collection ID rather than by name.  ... View more

Take a look at the SLA Dashboard in the App Broker admin UI. Documentation reference here: https://helpnet.flexerasoftware.com/appportal2019r1/default.htm#helplibrary/SLA_Dashboard.htm Set the start and end dates as desired and click Apply.  Then click on the Failed Deployments "card".  This will produce a report showing all of the failed deployments during the designated time frame, and you should be able to export that to Excel/PDF.   I guess I should amend this slightly.  There might be other reasons requests in ServiceNow could get marked as Closed Incomplete without ever being sent to App Broker, but I'm not sure.  For example, if the workflow validation steps fail or if the request is rejected by an approver, that may also end up as Closed Incomplete within ServiceNow (although maybe they get a different status).  In any case, the report in App Broker will only show requests that actually got submitted to App Broker from ServiceNow (i.e. workflow passed all prior steps and reached the Submit Order step), so if you need a full list of Closed Incomplete requests, you would need to run that report in ServiceNow. ... View more

For anyone interested in the outcome of this, it turned out to be a custom action that had been added to the On Submit event that was sending the wrong value to ServiceNow. ... View more

Please note that there is a Custom User ID Sync SQL Query and a Custom User Sync SQL Query.  The examples from Charles put the WHERE clause on the Custom User Sync SQL Query; however, I always recommend putting any filter clauses on the Custom User ID Sync SQL Query.  The way the sync process works is that it first runs the user ID query to get a list of all user resource ID's that match the criteria.  Then we break that list up into pages based on the page size you've defined in your settings and we run the user query to get the user details for those resource ID's, one page at a time.  If you put the filter on the user ID query, it will bring back a smaller set of resource ID's, which will result in fewer pages, which will result in shorter sync times. Here are a couple examples that I have used with customers to overcome various issues (in both cases, the Standard User Sync SQL Query can remain unchanged): Collection-Based User Limiting App Portal's licensing model has been changed (as of 2015) to user-based licensing instead of device-based licensing.  However, the limiting view/collection in the site settings was never changed to match, so in order to remain in compliance with your user-based license count, it is best to create an SCCM user collection containing only the user accounts that are licensed to use App Portal.  Then you can use a custom query to pull in only those users and ignore accounts like service accounts, test accounts, and admin accounts. SELECT ResourceID AS UserResourceID FROM v_CM_RES_COLL_CM10029D ORDER BY SMSID …where CM10029D is the collection ID of the desired user collection to use for limiting.  This will limit the list of resource ID's to only those users that are in the selected user collection. Skip Duplicate User Records in SCCM Under rare circumstances, I have seen customers where SCCM has more than one user record with the same user name but different resource ID's.  This is typically more common with computer records, where reimaging a machine with the same machine name can result in a new resource ID (and a similar custom query can be used for the Custom Computer ID Sync SQL Query).  In both cases, you'll see unique key constraint violation errors in the data sync error log.  To avoid this and only pull in non-duplicate user records from SCCM... SELECT vru.ResourceID as UserResourceID FROM v_R_User vru WHERE (SELECT COUNT(ResourceID) FROM v_R_User WHERE User_Name0 = vru.User_Name0) = 1 ORDER BY vru.Name0 Note 1:  Users with duplicate records will not be synced into App Portal.  This will prevent them from using App Portal.  If you run into a user that is not able to use App Portal and you don't see their account in App Portal, but they do show up in SCCM, make sure there are not duplicate records in SCCM for that user.  If so, you'll need to remove all of the duplicate records and keep only the one you want (usually the one with the highest ResourceID). Note 2:  If you don't use the custom query and you have duplicate records in SCCM, you will fail to sync more users into App Portal than just the duplicate users.  The way the sync process works, if it hits an error on a particular user, it will skip all of the other resource ID's in that page of ID's and continue with the next page.  If your page size is large, you may miss a lot of users. Note 3:  Even if you do use this custom query, you may still hit unique key constraint violations.  This could happen if you complete a sync cycle and pull in a user record with a particular ResourceID.  Then at a later date, the same user has a new ResourceID (but only has one record for that user, i.e. not a duplicate).  In such situations, you would need to delete that user from the WD_User table in the App Portal database and run a fresh sync (or you could just modify the record to have the new ResourceID, which might actually be safer). ... View more