Deploy Package to Multiple Collections at one time
Allow packages to be deployed to multiple collections at one time. For instance I need AppX to go to Lab 1, Lab 2 and Lab4. Instead of going into AppX 3 different times to deploy, it would be nice to deploy it to all 3 labs at one time.
~This is no longer important to me as you guys took so long I wrote my own front end to the Console to do what I need done. It's sad if I can do this is a few days with limited skill set then you should have been able to do this in four years time with an existing console ALREADY built. SMH
Would it not be wise to create one collection with the app deployed to it then include your Lab1-4 collections? Am i misunderstanding here?
~I just had to deploy 18 application to two different collection.... this took FOREVER! Why this is not a thing already i don't know
NOT limited to packages, Application also. And reverse, deploy multiple applications to a collection.
Yes, but NOT limited to packages... EVERYTHING should have this function!
This needs to be expanded to being able to select multiple objects and perform an action. Select 5 applications and right click deploy. Select 3 task sequences you no longer want and delete them, etc. etc. etc.
Patrik Holmqvist commented
Also be able to deploy multiple apps to 1 collection at the same time would be great
That should not even be a suggestion. That SHOULD have been build in from word Go!
Another vote for Jason Sandys, just create your initial deployment collection using the "Include Collection" rule, if you need to stop the advertisement, then remove the individual collection.
In this example, create Appx Collection to include LA1,Lab2,Lab3, if you need to stop one deployment to Lab2, remove Lab2 only, you dont need to stop the entire deployment.
Jason Sandys provides the first obvious solution below. We currently do this, we create "types" of deployment collections (available, required, etc) and then use include rules to populate with other collections, role, department, etc.
The annoyance with doing it like this is organizational data our customers request is more difficult to access.
With one deployment per one collection, you can look at a collection properties\deployment tab and know exactly what apps are deployed to it. This data is not there when you start nesting/including collections.
You can create custom reports/scripts to get around this, but imo I would think a lot of organizations would like to easily provide a list of apps that is deployed to any given department/group (like for Win10 app testing etc).
Someone mentioned PS to deploy the same app to multiple collections... That can work, then you have the opposite issue where you have individual group information but lack overall health of a deployment, you now have to collate multiple reports or go custom again.
Generally speaking for us, the need to have multiple deployments with unique settings is much less, compared to being able to deploy the SAME deployment settings to multiple groups.
PS I love the idea of being able to add app deployments to a collection from the collection object.
Matt Piechota commented
I came here to make the same suggestion, so I gave it 3 votes.
I would love to be able to deploy an application to multiple collections, or in the reverse, select a collection and pick multiple deployments to it. The only way to do it now is to create a collection that has other collections as part of it - and I would prefer not to go that route so if something breaks, it's easier to diagnose where.
Daniel Olson commented
I have a powershell script that can deploy one app to many collections or many apps to one collection
We have the same issue in our large Gov't enterprise. I realize you can include collections within collections, but then it's still ONE deployment. If something goes south with any of it, you have to kill the entire deployment. For example, I am doing a deployment to multiple divisions, each division is in a collection with specific exclusions for each one. I want to deploy the application to each division, not as an "uber" collection. Reason being, if something goes south in one Division (In spite of rigorous pilot tesing), I would want to just kill that one deployment and keep the rest going, not kill the entire deployment. That is the problem with nesting collections. I will just say this, I have been an SCCM admin for 3 years, I was a LANDesk admin for 12 years before that. While SCCM does many things better than LANDesk, it SUCKS in ease of use compared to LANDesk. Why in the name of all that is holy can you NOT do the most basic windows functions in SCCM, like drag and drop, or hit a letter to go to that letter in a large listing (Like in the Applications listing, which we have hundreds, just hit an "s" to get to the "S's"), instead I have to use the filter. If they had a "drag and drop" in SCCM, I could just set up the deployment (Schedule, etc) and drop the collections onto the deployment job, 1 or 100 of them. Easy-peasy. OK, I'm done venting now.
Jason Sandys commented
Why not create a combined collection using include rules and then deploy to it instead? That's the expectation here. Limiting yourself to collections based on locations only is the actual source of your scenario here.
Given this 3 votes as I came here to make the idea myself.
It's a feature that has been missing for some time now.
As Chris Cools has said, when I package Application A, I can then distribute it to multiple Distribution Points at once in a single Wizard. Then I go to deploy it to 3 buildings across site, each have their own Device Collection., but I can only select a single Device Collection in the wizard. Meaning, I have to right click, deploy, select device collection, next, confirm DP's, next, set required, next, set installation time, next, set notification level, next, set any alerts, next, finish the wizard... and then repeat the whole process 2 more times for the remaining Device Collections.
^I know that process like the back of my hand because of the hundreds of times I have to do it!
It's an easy enough feature.. lets make it happen.
Eric Sisneros commented
Every year I revisit all our application deployments and update the ones we need for the next school year. Most of out collections are organized in terms of labs.
What really takes a large chunk of my time is removing application deployments one at a time (from each lab) and deploying a newer version of the application to each lab one at a time.
It would be very nice to have the ability to deploy an application to multiple collections at once and remove multiple deployments for an application at once.
Chris Cools commented
I have no votes left today, I'll make sure I vote for this when I have votes available again. I totally support this idea, I have made a similar suggestion for 'multi-select TS deployments to collection(s)'. It should be integrated in the console. Administrators do have the need to deploy stuff to a collection or even multiple collections at one click (selection of SCCM objects like packages and task sequences) from within the console. Currently it is a burden to deploy like 20 task sequences or packages to a collection. I have to repeat the same action 20 times, manually. Working on a PS script to do this as we speak because it's too frustrating to work like this!