There is a way. you only advertise the application to the users collection. Create multiple collections for who should have access to the app.
IMO, you should have AD groups that are created around "user roles." A user is added into these AD groups which are synced to a user collection that has a specific list of applications made available to it. User collections for "Application Catalogue" Computer collections for "Software Center" Once the app is installed from the Application Catalogue, any subsequent patching that you rollout to computers will patch the application. it will also be beneficial to categorize your applications so they can be grouped effectively. I would recommend against turning on approval mode for applications, unless you have Orchestrator to automate the workflow to licensing team, manager, etc. This is because the native approvals only go to the admin console and there is no notifications. Someone has to go to the console to approve. It just slows down the process. does that make sense? this is an early morning brain dump, sorry if it doesn't. From: [email protected] [mailto:[email protected]] On Behalf Of Robert Spinelli Sent: Sunday, 8 March 2015 2:11 AM To: [email protected] Subject: RE: [mssms] RE: App catalog background transfers? I wish there was a way to make it only show the apps that the user should have access to instead of all the apps (that don't need a license) in app catalog. Issue I see with this is people just going into the App Catalog and be like this seems like I might use this one app someday, and they install bunch of apps they never need. We have about 1k apps, the typical user needs maybe 50. We have roles that we group the apps in (ex: secretary) so they are only able to install the 50 apps they need. I'm working thru the design now on this, since were doing this using another product and moving over to SCCM 2012. The only way to get this functional is have a collection, AD group, and target that app to that collection. We'll end up with 1k collections (1 per app) which I'm not thrilled with. It would have been great if I could of targeted the app to all users (not having to create 1k collections) and have the 50 apps the secretary needs show up in App Catalog by having the requirement rules check the AD group the user is in. Good thread though why you shouldn't use requirement rules / AD groups for targeting. https://social.technet.microsoft.com/Forums/en-US/3a737afa-26e8-4881-9105-a9c42055ca67/how-to-create-a-global-condition-based-on-computersusers-active-directory-group MS has pushed SCCM 2012 saying you don't need as many collections, but until they allow you to do something like above, I don't agree you don't need lots of collections. I used to work at a very large financial firm and we had something like 25k apps, there is no way we were going to target them to all users. Rob From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of ccollins9 Sent: Friday, March 6, 2015 10:20 PM To: mssms Subject: Re: [mssms] RE: App catalog background transfers? Just one another question, we decided years ago that any app that we package and have a site license for, we advertise to All Users as Available and turn off the notifications. Then If they need an app, we have them click a shortcut on the desktop which opens the application catalog website run by SCCM. They can then pick any app to install or search for the app they want while on the phone with a tech that is walking them through it. We have some users that open the App icon frequently just to see if we've added any apps in there for them to install. It's a win-win because users only download what they need, so keeping desktops much lighter, and it also kind of empowers them a bit and they don't have to deal with going to helpdesk and waiting on them. Any app that we want on all desktops we push the appropriate collection and "require" it. Is there a reason you wouldn't want to open up majority of your apps to be installed on-demand by the users? For apps that we have specific license restraints for, like number of users, we target user groups that are controlled via AD or we set the "require admin approval" on the app. On Fri, Mar 6, 2015 at 8:07 PM, ccollins9 <[email protected]<mailto:[email protected]>> wrote: One easy way to do this is to deploy the app to "All Users" collection as "available" (NOT required), choose only show notifications for computer restarts, then set the app to require administrator approval. The helpdesk can go into the console and approve the request, or get someone higher to do it. As a side note, it's completely possible to "lock down" the console so helpdesk can have the console to do functions without hurting anything. SCCM works best this way and is designed to be used by Tier 1 up to high level systems admins. We have interns using it that don't know much about IT in general, but they can only do what we allow them to do via permissions. http://blogs.technet.com/b/neilp/archive/2012/09/18/system-center-2012-configuration-application-approval-deep-dive-and-automation-part-1.aspx On Fri, Mar 6, 2015 at 7:55 PM, Atkinson, Matt T <[email protected]<mailto:[email protected]>> wrote: I agree, but compared to having a tech visit in person it's a vast improvement. This is really only for one off installs that need to be done infrequently and on demand, larger deployments are staged and planned out much better than this. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Sean Pomeroy Sent: Friday, March 06, 2015 3:31 PM To: [email protected]<mailto:[email protected]> Subject: Re: [mssms] RE: App catalog background transfers? Maybe it's just me, but having an IT staff member remote to a PC to manually initiate a software installation kind of defeats the purpose of a system such as this. On Fri, Mar 6, 2015 at 6:28 PM Atkinson, Matt T <[email protected]<mailto:[email protected]>> wrote: Sure it's possible, but we would either have to expose the SCCM console to desktop support/help desk or rely on them adding AD user accounts to AD groups, then keying the collections based off of the group memberships. Kind of a pain due to wait times for AD discovery and collection evaluation. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Kent, Mark Sent: Friday, March 06, 2015 2:35 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: App catalog background transfers? What about letting the users themselves run it from the app catalog? You can control what they see. And require approvals as well. Mark Kent (MCP) Sr. Desktop Systems Engineer Computing & Technology Services - SUNY Buffalo State From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Atkinson, Matt T Sent: Friday, March 6, 2015 4:56 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] App catalog background transfers? Coming up against a problem while we are getting our service desk folks up to speed with deploying software using SCCM 2012. Our original plan was to have the tech connect remotely to the machine, login, launch the app catalog with their credentials and start an install from the catalog. Then log out, let the user log back in and continue working while the application finishes downloading. This isn't working in practice, as soon as the tech logs out, the BITS transfer gets queued and won't resume until the technician is logged in again. Is there any way to work around this? It's been frustrating running against a wall trying to get a way to let our desktop support folks to install apps for users. Deploying directly to the user accounts or computers themselves would obviously work, but not desirable from our leadership. ________________________________ This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message. ________________________________ This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message. ________________________________ This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message. This email, including any attachments, is confidential. If you are not the intended recipient, you must not disclose, distribute or use the information in this email in any way. If you received this email in error, please notify the sender immediately by return email and delete the message. Unless expressly stated otherwise, the information in this email should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product or service, an official confirmation of any transaction, or as an official statement of the entity sending this message. Neither Macquarie Group Limited, nor any of its subsidiaries, guarantee the integrity of any emails or attached files and are not responsible for any changes made to them by any other person.
