Where does App Portal pull Device and User information (SCCM, FNMS)?

[PBolles]

Where does App Portal pull device names, user names, and their association? Is it from SCCM integration or FNMS integration.

Customer is wanting to only add devices and users (depending on application license) to Active Directory groups and then SCCM package does an install when it sees a new device or user in the AD group. Thus setting up General Catalog items and adding to Security Group on approval. To select "On behalf of" looking at if they need to integrate with SCCM if that's where it gets it's information for selecting device and users. They are not going to integrate with SCCM thinking with not using the call to a SCCM package for the install.

[ChrisG · Accepted solution]

By default the device and user details will come from the deployment technology (SCCM in your case).

An alternate source can be used by configuring custom sync queries in App Portal. See the following page in the Administration Guide for some information about the queries that can be configured: Site Management Reference > Settings > Deployment > Common Tab

[ChrisG · Accepted solution]

By default the device and user details will come from the deployment technology (SCCM in your case).

An alternate source can be used by configuring custom sync queries in App Portal. See the following page in the Administration Guide for some information about the queries that can be configured: Site Management Reference > Settings > Deployment > Common Tab

[jdempsey · Accepted solution]

Acknowledging that Chris' answer is the answer to the original question, I feel the need to pipe in here with my own two cents on the customer's proposed approach.  Yes, you absolutely CAN use general catalog items with the option to add users to AD groups and then have SCCM deploy software based on that AD group membership.  However, SHOULD you?  In my opinion, no.  Here are a few reasons why:

1. Using this approach requires manual creation and maintenance of the AD groups, collections, and deployments every time you add a new catalog item.  Why do all that work when App Portal can automate the collections and deployments for you?
2. With recent changes made to the product a couple releases ago, you are no longer prompted to choose the target device when checking out a general catalog item.  That means you can no longer add devices to an AD group as part of the built-in security group management capability because we don't know what device to add.  You are limited to adding only users to AD groups.  Maybe that's what you want, but maybe not.  Remember that if you create a "required" user-based deployment, that software will install on every device the user logs into whether you want SCCM to do that or not.  If you are creating "available" user-based deployments, that software will be available to that user in Software Center so they can choose to install it on any device they want.  Again, that may be what you want, but if you make it available to install from Software Center, then you have lost all license governance (license availability checks, etc.) from the software request process, because that user can install the software anywhere they want without you ever knowing about it (until you look in FNMS and see that you are out of compliance and have to pay the publisher for a bunch of extra copies of the software).
3. As has been stated in responses to other topics in these forums, when you use general catalog items, you give up the ability to perform uninstalls (other than manually from Software Center).  Uninstall requires a software catalog item.  On a related note, unless you are using SmartUninstall for limited reclamation cases (MSI only), you cannot use App Portal for license reclamation when using general catalog items.
4. While this may be a minor point, when using general catalog items, you lose visibility to the installation status.  We can only monitor and report deployment status for software catalog item requests.

In summary, general catalog items serve an important purpose for requests that don't involve the installation of existing software packages.  However, while they offer a ton of flexibility in scripting/automating pretty much anything, they shouldn't be used as a primary means of software deployment.

[PBolles]

Agree on all points and have passed it on to the customer. Their SCCM manager wants it AD only and currently will not budge.

We'll see what the future brings for them.

I'm thinking more services to switch later down the road 🙂

Thanks Jim