This is great and is the approach which I prefer. Sadly a fair number of customers who I encounter don't believe it.
> On 7 Mar 2015, at 03:23, ccollins9 <[email protected]> wrote: > > 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]> 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]> 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]] On Behalf Of Sean Pomeroy >>> Sent: Friday, March 06, 2015 3:31 PM >>> To: [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]> 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]] On Behalf Of Kent, Mark >>> Sent: Friday, March 06, 2015 2:35 PM >>> To: [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]] On Behalf Of Atkinson, Matt T >>> Sent: Friday, March 6, 2015 4:56 PM >>> To: [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. >>> >> >> > >
