Here's a possible suggestion: Keeping in mind that the collection cannot change for Application Deployments, what we do instead is this. You still have your Pre-pilot collection, Pilot #1, Pilot #2, etc. etc... and Production collections.
Here's how the "ideal" (in my head) works--which, naturally, doesn't work this way sometimes, but... 1) Target a Simulated Deployment to your (currently empty) Target Collection. a) Using Collection "Include another collection", include the Pre-pilot collection into Target Collection. b) confirm that your application deployment rules would target the machines you expect it to be deserved by. 2) Using Greg Ramsey's "Promote Simulated to Requires, http://gregramsey.net/2013/04/17/how-to-promote-an-application-simulation-to-a-required-deployment-in-configmgr-2012-sp1/, promote that simulation to required. 3) Wait for pre-pilot to be confirmed. 4) When appropriate, "include" Pilot #1 collection into Target collection. 5) Repeat for Pilot #2 (wait and confirm), and Production Collection. What I try to frame the concept around is this, if you were familiar with SubCollections in CM07 and older, it's if you were to a) have an advertisement that had the check box for "include subcollections", and b) you would "link to another collection" to 'add' to your target collection by linking in pilot #1, #2, production collections, 'under' the target collection. I hope the above makes sense; it's hard to describe well until you've done it once or twice, then the lightbulb goes off. Sherry Kissinger Microsoft MVP - ConfigMgr [email protected] ________________________________ From: Johan van Dijk <[email protected]> To: [email protected] Sent: Sunday, July 7, 2013 4:31 AM Subject: RE: [mssms] Deployment methodology If your using the application model it won’t since it’s already installed… From:[email protected] [mailto:[email protected]] On Behalf Of Daniel Corkill Sent: Sunday, July 07, 2013 11:19 AM To: [email protected] Subject: RE: [mssms] Deployment methodology I’m guessing each deployment has a unique deployment (advertisement) ID. In which case I’d need to be careful machines that are both in a pilot and production collection don’t rerun installations. From:[email protected] [mailto:[email protected]] On Behalf Of Trond Karstensen Sent: Sunday, 7 July 2013 6:23 PM To: [email protected] Subject: RE: [mssms] Deployment methodology I just add a new ‘deployment’ to the production collection (for sw and software updates). You can have multiple ‘deployments’ for Software and Software Update Groups targeting different collections. From:[email protected] [mailto:[email protected]] On Behalf Of Daniel Corkill Sent: 7. juli 2013 09:01 To: [email protected] Subject: [mssms] Deployment methodology The software deployment guys raised concerns with me on Friday about changed deployment/advertisement behaviour in CM12 that I was previously unaware of – the seemingly inability to change the target collection. Currently with our ConfigMgr 2007 site the methodology they use for software distribution is to initially create a collection with a couple of test systems and advertise the software to it, create a pilot collection and change the advertisement to then use this collection and finally create the production collection and change the advertisement to use this collection. While I don’t do much software deployment these days, I’m solely responsible for the monthly patching and I use a similar method of breaking the deployment up into multiple pilot and “phase” collections and changing the SUM deployment’s target collection as I progress. Just curious how the deployment methodology is supposed to work in CM12 now that advertisements can’t have the target collection modified. Interested to hear how others do it. Daniel.
