Under Site Management > Settings > Web Site > Catalog Behavior, check the box called "Allow users to do a search on partial Order #". ... View more

I just set this up in Azure over the weekend.  I created a VM using one of the pre-built SQL BYOL images and am connecting App Broker to it with the following connection string: Data Source=(local);Initial Catalog=AppBroker;Integrated Security=True; In my case, I just put App Broker and SQL on the same VM, but this would have also worked on separate VMs by substituting the SQL server name in place of "(local)" in the connection string. ... View more

First, please note that App Portal doesn't deploy software.  SCCM (or another deployment system) deploys the software to computers.  If the contractor's computer is not managed by your deployment system, it should not even show up in App Portal, but even if it did, App Portal would not allow you to select that non-managed device as a target for the software request.  And even if it got through that part of the checkout somehow, the deployment system would never be able to deploy software to it.  Is this a request for a general catalog item rather than a software catalog item?  If so, then the request isn't tied to a specific device, only to the user, and it wouldn't deploy software (unless you've configured some sort of custom actions on the catalog item).  In short, no matter where a user requests software from, they cannot request a software catalog item to be deployed to a device that isn't managed by your deployment system. Having said that, I'll point out a couple related features that you may be interested in configuring: First, under Site Management > Settings > Web Site > Catalog Behavior, there is a setting called "Allow users to request to SCCM primary devices".  If you enable that setting, a user can request software for any device they are associated with in the deployment system, even if that's not the device they are currently shopping from.  If you disable that setting, they will only be able to request software for the device they are currently shopping from (and that won't work if the device is not managed by your deployment system). Second, if there are specific users that you don't want to be able to request software using App Portal at all (e.g. contractors that don't have company-provided computers), you can use Catalog Security to ensure they don't have the Browse Catalog permission.  Make sure you haven't included any broad groups (e.g. Domain Users) that may include those restricted users. Edit: Oops, just realized Bob already mentioned the Catalog Security option.  Sorry, Bob. ... View more

See original post for "answer". ... View more

App Broker doesn't determine that.  All license-related activity happens within FNMS, based on the data passed from App Broker.  App Broker essentially sends 4 pieces of information: user, device, Flexera ID, and scope (global, enterprise groups only, enterprise groups first, then fall back to global).  When App Broker checks for availability, FNMS will look at the Flexera ID and determine which licenses are associated with that application.  The license priority assigned within FNMS (which may be "automatic" or user-defined) would then be used to determine which license to apply first, second, third, etc. until it finds one that meets the scope restrictions and has availability.  When a reservation is placed, it basically just puts that user/device into a "queue" that isn't necessarily tied to a specific license (it is tied to the application).  After the software gets installed on the device and inventoried, the consumption will be tied to a specific license during the reconciliation process in FNMS (again, based on the license priority assigned within the application). ... View more

I'm still not clear if you're talking about a catalog item or a request for a catalog item.  Request information would be in WD_PackageRequest or vMyRequestsCatalogUpdated.  Catalog item information would be in WD_WebPackages, vRequests, or vSearchCatalog.  vPackageWorkflows will show you each catalog item ID with its corresponding workflow name.  You could join that with WD_WebPackages on PackageID to get the list of catalog item names with their associated workflow names.  If you're trying to get a list of approvers for a catalog item, that's a bit trickier because you would have to first look up the corresponding workflow, then enumerate the list of approver GUIDs, then map the GUIDs to names, then consolidate them all into a single delimited list for that catalog item.  If you're looking for the current approver(s) for a specific request, you can find that in WD_ApprovalProcess by filtering where RequestID_FK is the request ID you're looking for and IsCurrentApprover = 1.  Again, you'd have to map the GUIDs to names and consolidate the list if there is more than one current approver. Forgot to mention that to map the GUIDs to names, you can do that by joining with WD_Profile (assuming the user has a profile entry). ... View more

I would discourage direct database updates when possible.  In this situation, there are SOAP APIs available for updating descriptions and keywords.  The methods you would be interested in are: updateCatalogItemBriefDescription updateCatalogItemDescription updateKeyWordsOfCatalogItem ... View more