Would be great if that was a feature, and then if you clicked "Unapprove" it would uninstall as well.
On Fri, Mar 13, 2015 at 9:21 AM Roland Janus <[email protected]> wrote: > Sadly that’s not the case. > > Once approved, the user can currently always install again. > > > > The only thing I found so far was editing the DB, setting the flag, > obviously not supported. > > > > Other solutions use requirements for every app. > > That is just a workaround and involves quite a few steps of operational > work. > > > > I’d like to see right click to an approved entry and select “clear” or > whatever . > > Doesn’t look that complicated to implement. > > > > No one filed a change request yet? > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *ccollins9 > *Sent:* Freitag, 13. März 2015 13:39 > *To:* mssms > > > *Subject:* RE: [mssms] RE: App catalog background transfers? > > > > Not sure, I'd have to test it, but my gut says that you would have to run > the uninstall for the package. And and any reinstalls would also need > approval > > On Mar 13, 2015 7:29 AM, "Roland Janus" <[email protected]> wrote: > > Bump? > > > > No way to un-approve? > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Roland Janus > *Sent:* Dienstag, 10. März 2015 00:44 > *To:* [email protected] > *Subject:* RE: [mssms] RE: App catalog background transfers? > > > > I was thinking of using all users for the majority and hoping they behave > themselves. > > For all others still all users and approval. It should be fine having the > service desk doing it. > > Maybe there is a nice status event which could trigger a mail, but let > them handle those. > > > > But once it is approved you can’t un-approve at all? > > What’s the solution then? None? > > > > -R > > > > > > *From:* [email protected] [ > mailto:[email protected] <[email protected]>] *On > Behalf Of *ccollins9 > *Sent:* Dienstag, 10. März 2015 00:22 > *To:* mssms > *Subject:* Re: [mssms] RE: App catalog background transfers? > > > > FWIW, i highly recommend converting them to apps. There's a tool that will > do 90% of the conversion for you. We resisted too for a while but > eventually did it and never use packages anymore because apps are so much > nicer and more effective. > > > > > http://blogs.technet.com/b/configmgrdogs/archive/2012/04/28/package-conversion-manager-pcm-in-configmgr-2012.aspx > > > > > > Also, we had to make the same decision---either a collection for each app > or deploying the app to multiple user role-based collections. For instance > even if you define user roles, you will still have plenty of overlap I'm > sure. Let's say you having marketing, finance, research groups. Marketing > and research get App A, but not Finance. You still have to create two > advertisements, one for the marketing group and one for the finance group. > With 1,000 app out there, this could get crazy quick. We bit the bullet and > created a collection for most apps, create one advertisement to that > collection, then add collections containing users or computers to it as > necessary. Which is another reason we decided to deploy many apps to All > Users as "Available", but I know that's not the route you want to go right > now. > > > > > > > > > > > > > > On Mon, Mar 9, 2015 at 2:09 PM, Atkinson, Matt T < > [email protected]> wrote: > > Thanks for all the great discussion. I really like the idea of deploying > to all users and requiring admin approval. The issue with that is we are > just finishing up migration from 2007 and all of our software is built as > packages. Converting them to apps would probably be a pretty large body of > work. > > > > I’d wager that AD groups for the computers will be the way we wind up > going, I just hate the delay between adding to the group, AD discovery, and > finally collection evaluation. > > > > Anyone found a good way of working around this? Incremental updates won’t > work as this will probably need close to 1k collections L. > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Greg Thomas > *Sent:* Sunday, March 08, 2015 5:13 PM > *To:* Robert Spinelli > *Cc:* [email protected] > *Subject:* RE: [mssms] RE: App catalog background transfers? > > > > I use PowerShell to create the AD groups based on apps, create and > populate the collections based on the AD groups, and then deploy the app to > those collections. You might be surprised how few lines of code it is. > > Give it a shot. > > On Mar 7, 2015 10:11 AM, Robert Spinelli <[email protected]> wrote: > > 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] <[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]> 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] <[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. > > > > > > > > > > > > > > > > > ------------------------------ > > > 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. > > > > > > > > > > > > >
