One other thing to note. We do not test the App Broker product in a load-balanced environment..  As such, we can not claim official support for such an environment.. I just wanted to pass along that App Broker web UI should function correctly when run behind a load balancer, though the ESD Service will not.  ... View more

It should probably have been worded, "setting up this type of implementation goes beyond the scope of technical support".. I know of a number of customers who have set up App Broker in a load-balanced environment.  Typically, this is done more for fail-over purposes, but I have seen a couple who use it actively..  If you were to set up multiple instances of App Broker behind a load balancer, the critical thing to note is that the ESD Service can only be running on a single server.. Otherwise, you will find that if multiple instances of the ESD Service are running, that certain tasks may not complete correctly, due to the duplicate services trying to perform the same tasks at the same time.. The front end should handle this correctly.. With that being said, I have found that the load-balanced App Broker servers need to be running HTTPS, if the load balancer is as well.  Browsers do not like it when the load balancer offloads https traffic to HTTP.  ... View more

Have you integrated App Portal with FNMS? Typically, you need to associate the catalog item with a Flexera ID, and then select the "Check for license position during checkout" checkbox.. The following screen capture illustrates: ... View more

No, we don't have any known (or fixed) issues with the My Requests page, at least within the last 5 years or so. Obviously, the "request timed out" would imply a timeout occurring somewhere.. I'd be inclined to believe that it was some type of SQL query timing out, rather than a setting in IIS. I think that your speculation that the size of the orders (the number of requests they contain) may be contributing, certainly has merit. Can you put in the complete stack trace for the "request timed out" (in website.log probably?) Perhaps that may tell me where the timeout is occurring. Just for fun, see if you can correlate the error with any recently updated log files (perhaps databasecalls_error.log).  ... View more

If you simply change the query, then that will not remove users.. Typically, after you change to a custom query, support will usually suggest purging the wd_user table so that the data correctly reflects the results from the new query.. Perhaps this could explain it? ... View more

I could not reproduce this.. Could you provide additional steps to reproduce? Might be better to open a case for this, as this will give me something to link the bug to.  Please attach website.log and websitemvc.log to the case.  ... View more

WD_User contains user data that is synced from Config Mgr as part of the nightly data sync.. WD_UserEx is data that gets serialized from the session data when the user accesses the site. WD_UserEx contains additional data about the user such as group membership, collection membership etc.. If you look at the .XML, you should see something similar to the following, which would typically indicate when the record was written: <SessionStart>2021-06-07T09:27:32.2947544-07:00</SessionStart> If I had to guess, I'd say that the user may have been cleaned up from wd_user at some point, but the record in WD_userEx remained.  Unfortunately, I'm not well versed in when data from WD_UserEx is used vs just the session data, so I can't provide as many details as I would like. Also, I think that there are times when WD_UserEx gets written to, even if the user does not hit the ESD Site directly (for example, through an API).. Honestly, I have seldom looked at the table, as I'm not aware of any issues which are related to WD_UserEx, so I focus my attention elsewhere. ... View more

OK, thanks for the update.. I'm working with the support case owners to see if we can get this resolved.. It looks like the status update in the App Portal DB is not occurring correctly, due to some problem with requestID 94344. Steps will be provided shortly which will hopefully resolve the issue.. I'll continue to work with the case owners until this gets resolved.. Note that the SLA dashboard showing all pending requests appears to be a side effect of the bigger problem, which would occur if the status is not getting updated in the DB. ... View more

First, you can tell me if you are, or have been, updating the WD_packageRequests table by running queries against the App Portal DB? If so, then it is likely that you are doing so incorrectly. As mentioned, I'd guess that it would likely be that the lastStateID or LastStatusID columns are not set correctly. The queries I provided previously show you generally what values App Broker is expecting to either flag a request as successful or failed... I see that you now have two separate support cases open, which appear to pertain to the SLA dashboard so let's try to keep this discussion going either through a single support case or the community post, to avoid duplication of efforts. ... View more

When I say that "AutoDelivery would not be set, I meant that the value would be the default value of "1". This is the default setting, even for general catalog items. The only time that the value would be set to "0" would be if you select the "Notify machine owner when approved" radio button during checkout. Also, If you select this option, it should be noted that the insert date does not get set.. The insert date for the request will only get set once the user has selected the install action under my requests.  This would not be 100 percent accurate, but perhaps you could compare the insertDate to the DateTime column in WD_packageRequests.. You could make an assumption that if the insertDate was 5 minutes (or more) later than the DateTime, the request was scheduled.. In theory, if the request was not scheduled, the DateTime should be almost the same time (within seconds or milliseconds) as the insertDate for a "normal" software request.  Again, there is no flag in the DB to actually indicate that the request was scheduled.  ... View more

I'm not completely sure that I understand what you are looking to do.  Any documentation on setting up approvals would be found in the section Managing Approval Workflows in the Admin Guide. You always need to have a workflow, though there are various ways to add approvers to the workflow itself.. You can add various types of approval groups (dynamic, user, property, etc..) to your workflow, or you can add individual users/groups directly to the workflow..  ... View more

Yes, I can reproduce the same behavior.. It appears that the Group Contents dialog only looks at whether or not the catalog item has a Flexera ID, where It should be taking the "Check for license position during checkout" into consideration.. I'll create a ticket for this with engineering. ... View more

With regards to the RequestType, you are correct in that RequestType=0 is an install, and RequestType=1 is an uninstall. AutoDelivery is not really indicative of scheduling. It's really more of an approval option. If set to 1, then it indicates that the target should be inserted into the collection as soon as possible after the final approval takes place.. If set to 0 then the device will never be inserted into the collection until the user goes to the My Requests page, and selects "install" under the actions for the request..  The AutoDelivery flag is based on the following options presented during checkout.. Note that these options are only displayed when the request requires approval. If the request did not require approval, and instead, the user was presented with the scheduling options, the AutoDelivery would not be set. In this case, the only function of the scheduling options would be to set the insertDate in WD_PackageRequests. A device will not be inserted into the collection until the current time exceeds the time in the insertDate column. Beyond the insertDate, there is nothing to indicate that the request was scheduled for a later time. Hope this makes sense... ... View more

I can not boil down the dashboard to a single query, as there is quite a bit of logic in the SLA Dashboard page, but I can summarize where the SLA dashboard numbers are coming from with a few queries. The first query gives the total number of requests being processed for deployment progress... The Second query gives the number of successful requests, and the third gives the failed requests. The number of pending requests are calculated based on (total - (success + failure) --Total requests query (note that the date range changes): Select Count(*) FROM ( select distinct pr.* from WD_PackageRequests pr join WD_WebPackages wp on pr.PackageID_FK=wp.PackageID join WD_Package_Deployment pd on wp.PackageID=pd.PackageID_FK AND pr.DeploymentTechnology=pd.DeploymentTechnology where pr.inserted=1 and pr.deleted<>1 and pd.PackageType not in (1,3) and PR.DateTime between '04/28/2016 00:00:00:00' and '10/09/2018 23:59:59:999' ) softwareReq --successful deployments (note that the date range changes) select count(distinct PR.requestID) from WD_PackageRequests pr join WD_WebPackages wp on pr.PackageID_FK=wp.PackageID join WD_Package_Deployment pd on wp.PackageID=pd.PackageID_FK AND pr.DeploymentTechnology=pd.DeploymentTechnology where pr.inserted=1 and pr.deleted<>1 and ( (pr.LastStateID=1001 AND pd.PackageType=25) OR (pr.LastStateID=1001 AND pd.PackageType=18) OR (pr.LastStateID=1 AND pd.PackageType=15) OR (pr.LastStateID=1001 AND pd.PackageType in (19,20,21,22,23)) OR (pr.LastStateID in (13,15,17,18,19) and pd.PackageType in (0) and pd.DeploymentTechnology=2) OR (pr.LastStateID in (18,19,17,13,15) and pd.PackageType in (0) and pd.DeploymentTechnology=1) OR (pr.LastStateID in (18,19,17,13,106,100,15) and pd.PackageType in (0) and pd.DeploymentTechnology=8) OR(pr.LastStateID=13 and LastStatusID=11171 and pd.PackageType=4) ) and PR.DateTime between '04/28/2016 00:00:00:00' and '10/09/2018 23:59:59:999' --failed deployments ((note that the date range changes) select count(distinct PR.requestID) from WD_PackageRequests pr join WD_WebPackages wp on pr.PackageID_FK=wp.PackageID join WD_Package_Deployment pd on wp.PackageID=pd.PackageID_FK AND pr.DeploymentTechnology=pd.DeploymentTechnology where pr.inserted=1 and pr.deleted<>1 and ( (pr.LastStateID=1002 AND pd.PackageType=25) OR (pr.LastStateID=1002 AND pd.PackageType=18) OR (pr.LastStateID=5 AND pd.PackageType=15) OR (pr.LastStateID=1002 AND pd.PackageType in (19,20,21,22,23)) OR (pr.LastStateID in (101,11,230) and pd.PackageType in (0) and pd.DeploymentTechnology=2) OR (pr.LastStateID in (101,11) and pd.PackageType in (0) and pd.DeploymentTechnology=1) OR (pr.LastStateID in (101,11,230) and pd.PackageType in (0) and pd.DeploymentTechnology=8) OR(pr.LastStateID=11 and LastStatusID=11170 and pd.PackageType=4) ) and PR.DateTime between '04/28/2016 00:00:00:00' and '10/09/2018 23:59:59:999' Note that rejected and canceled requests, those awaiting approval, and those requests which have not yet been inserted are not included in the totals. Obviously, the date range in the above queries would need to be changed to reflect the data range entered on the SLA dashboard. One other thing to note: The queries I provided may result in slightly different results in your environment, as you may have changed the status mappings from their defaults.  For example, in the failed query, you will see "pr.LastStateID in (101,11,230) and pd.PackageType in (0)".  The in clause values of "101,11,230" are getting pulled from the setting FailureStatusIDs_ConfigMgr in wd_appsettings (which can be set under settings->deployment->config Mgr). I can only assume that based on the results, you may be modifying your DB manually in some way, and are neglecting to set the LastStatusID or LastStateID columns correctly. ... View more