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. > >
