You can use the following steps to migrate the DB to a new server: Make a backup of your App Portal database on your old database server. After restoring the database backup on the new database server, ensure that the App Portal's service account is added as a DBO on the new database server. On the App Portal Web Server, stop the ESD service. In the App Portal Web Server's installation directory, make sure you change the name of the old database server to the new database server in all the following .config files: Note: Some of the web.config files have more than one reference to the database and all the references need to be updated <AppPortal Install Location>\App Portal\Web\web.config <AppPortal Install Location>\APM\Web.config <AppPortal Install Location>l\Service\ESDService.exe.config <AppPortal Install Location>\Utilities\MyApps\AppPortal.App.MyAppsExecutables.exe.config On the App Portal Server, start the Windows Service called ESDService and perform an iisreset. Launch the App Portal Website to check which database server App Portal is currently connected to. This can be verified under Admin | Settings | General tab. ... View more

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.  ... View more

Looking at the O365 wrapper web service (in web/ws/SaaSIntegration.asmx) I do see where the O365 implementation does take a cloud variable named skuid and assign this license to the newly created user.. I've not actually tested the O365 cloud catalog item (I've used the Box one), nor do I know of anybody who is using it.. It looks like that is about the extent of the functionally.. Namely, create a user, and associate the specified license to this user.. In the long run, you might just be better off creating a powershell to do what you need it to do, and then add this powershell as a command action to a general catalog item.. Just my two cents.. The following Microsoft document looks like it might be helpful: Manage Microsoft 365 with PowerShell     ... View more

If you look at a question, you will note that there is a section which specifically deals with setting a task sequence variable for an OSD.. All you should have to do is set "Apply response to computer variable" (and the "apply variable to" and "Apply to build type" if you want to).. The task sequence would then need to "consume" the variable that was set by App Broker as part of a condition. The following screen capture shows the settings to which I refer: Beyond that, just be sure to select the "Apply computer variables" checkbox on your catalog item. ... View more

To actually answer your question: The setting "Automatically fail software requests with no change in status after xx hours" is indirectly tied to collection cleanup... Once this timer elapses, App Broker will fail the request by setting the monitor flag = 0, and by writing a failure status into the LastStateID and LastStatusID columns in WD_PackageRequests.. The collection clean routine will pick up on the fact that the request is no longer being monitored, and has failed, so it should clean up the device from the collection at this point. ... View more

I thought that it was a great question as well, and I had to dig around a bit to remember the actual behavior,  as collection cleans are not cut and dried.  For packages and task sequences, the cleanup will occur the first time that we get a status which matches those defined under settings->deployment->ConfigMgr for the setting "Program Collection Cleanup Status ID's" or  Settings->deployment->OS Deployment for the setting "Task sequence collection cleanup status ID's". This, of course, assumes that you have the "remove from collection when complete" setting selected for your catalog item... Note that the monitor flag in the WD_PackageRequests is not taken into consideration for packages and Task Sequences.  Applications are a bit different in that they only get cleaned on a success, or *optionally, a failure..  First, you need to have the "remove from collection when complete" setting selected for your catalog item. If you have only this selected, then a cleanup will occur only on a successfully install.. Second, if you have the "Enable collection cleanup on failure" setting under settings->deployment->ConfigMgr selected, then the device will be removed from the collection on a failure. It is important to note that for applications, the "monitor" flag in WD_PackageRequests must be set to "0" (false), meaning that the application is no longer being monitored..   Long story short, It appears that App Broker is handling the cleanup correctly even when we receive an initial failure, and App Broker is waiting for a success ( See the setting "Monitor Threshold for failed deployments to prevent false flags" under settings->timers) As an added bonus, if you have verbose logging enabled, you can look at the CollectionClean_<server>.log file, and see the actual query being used to get the list of requests which need to be cleaned.. The query will probably explain it better than I can 🙂 ... View more

Yes, this icon would be visible to everyone if you exceed your license count.. There are some pertinent details on how you might resolve this in the following community post; https://community.flexera.com/t5/App-Broker-Forum/Remove-the-red-warning-that-appears-on-our-App-Portal-landing/td-p/138936   ... View more