SCCM Load Increase After Implementing AppPortal

[dcopher]

Are there any metrics of expected server load on the SCCM Primary site after connecting it with AppPortal?

I haven't found any SCCM server minimum requirements for App Portal integration.

We have a customer asking if there will be any need to modify hardware usage.

[ChrisG]

I don't have any hard metrics, but the additional load would not normally be significant. The SCCM activity initiated by App Portal/Broker is primarily adding computers/users to collections to deploy packages, which is activity that would be done as part of normal deployment practices anyway (whatever the request process is - whether or not App Portal is involved).

[jdempsey · Accepted solution]

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:

1. 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.
2. 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.
3. 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.