It looks like App Broker is having a problem querying AD to get the approvers for the request. If you go to Site Management > Active Directory > Integration, do you have any issues viewing the current list of forests/domains or adding a new one?  Any errors trying to add a new user or group under Site Management > Admin Security? Are you able to remove the approval workflow from the catalog item and add a different one? (if you can't do that from the catalog item Approval Process tab, you might be able to go to the approval workflow properties and remove it from the Applies To tab) Do you see the same errors when logging in with a different account? I'm not sure what the root cause or fix is, but just trying to narrow down if the issue is with the AD connection, the workflow, or the user that's logged in (which could impact the workflow). ... View more

You are correct that if you don't change the deployments from available to required, users will still have to go to Software Center to initiate the install.  There is no way to have multiple SCCM deployments on a single catalog item. On a related note, when we do new implementations, we always default to using device-based, required deployments.  The reason we use required deployments is so that user don't have to request it once in App Portal and again in Software Center.  The reason we use device-based deployments is to ensure license compliance for device-based licenses (and even user-based licenses that don't allow use on an unlimited number of devices).  If you leverage user-based deployments, the initial license check may pass, but then the user could install that application on any managed device they are able to log into.  As a result, if you only had one available device-based license for the application at the time of checkout, as soon as the user installs that software on a second device, you are out of compliance. ... View more

I've recently helped a customer through a process like this (though we didn't clone the app server).  The high-level steps are as follows: Back up the production database and restore to the development SQL Server (potentially with a different DB name, like AppBrokerDEV vs AppBrokerPROD - this just helps keep them visually distinct) Run SQL query on AppBrokerDEV to update [WD_SiteToAdvert].[CreatedByAP] = 0 to remove "ownership" of the existing SCCM collections and deployments.  (NOTE: This will prevent App Broker DEV from removing the production collections/deployments if you archive any of the catalog items on the DEV server or modify their deployment settings.) Prepare development web server with all necessary prereqs (IIS, .NET, etc.) Run App Broker setup on development web server, pointing to the restored database (AppBrokerDEV) Archive one catalog item on the DEV App Broker server and verify that the associated collections/deployments aren't removed from SCCM (verify by requesting that catalog item in production) While this process will work, I always recommend having a separate DEV SCCM environment.  When sharing an SCCM system between DEV and PROD, you have to take extra precautions to ensure you aren't negatively impacting the other environment.  Any new catalog items created in the DEV environment should be named in such a way to distinguish them from production catalog items (e.g. "[DEV] Adobe Acrobat DC" instead of just "Adobe Acrobat DC").  This will ensure you don't end up with naming conflicts in SCCM when the collections and deployments are created (and will also make it easier to identify the DEV versus PROD deployment objects when looking in the SCCM console).  Additionally, if you end up deleting/re-creating the deployments on any of the cloned catalog items (on the DEV server), you should rename that catalog item with the [DEV] tag first.  That way, when it creates new SCCM deployment objects in SCCM, it will create them with the [DEV] tag in the name.  Finally, keep in mind that there is no easy way to keep the catalog items in sync between DEV and PROD after the cloning operation.  Changes you make to production catalog items, such as archiving them or re-creating deployments, can cause the cloned catalog items in the DEV environment to stop working.  Likewise, changes you make in the DEV environment (new catalog items, archived catalog items, modified catalog items) will not be reflected in the PROD environment. Hope that helps. ... View more

Under ITSM Integration > ServiceNow - Catalog Import Set Management Service > Create ServiceNow Import Set Record, set the active field to a value of ##PackageVisible##.  This is a bit field in the database that corresponds to the Enabled checkbox in the UI.  I don't remember if I've tried this or not, but if it doesn't work outright, you may need to play with the transform map in ServiceNow to convert the format to the proper true/false value.  I think it may convert the value to a proper-cased True/False, and I think ServiceNow only recognizes all lower-case true/false. Once you have this working for the Create operation, repeat this for the Update operation (Upsert ServiceNow Import Set Record). ... View more