I would say packages is a very deterministic way of installing the apps because generally what is shown in the task sequence is what you are installing unless there are nested dependencies inside the package. The application model becomes more of a black box because if what you are installing has dependencies it gets a little more difficult to know what is being installed just by looking at the task sequence. If you throw in supersedence and requirement rules then things get more interesting to understand.
I've always stayed away from the appmodel + OSD approach mainly because the MCS guys we had on site for a larger customer did it that way. So ultimately I don't know how well the application model works in practice in a OSD scenario. The application model isn't bad for V1 but definitely not fully baked for the real world. From: [email protected] [mailto:[email protected]] On Behalf Of Kent, Mark Sent: April 15, 2014 9:14 AM To: [email protected] Subject: [MDT-OSD] RE: Install Applications TS step - limitations? Chalk it up to another feature in SCCM that doesn't work well. Add metering, asset intelligence, multicast.etc. Mark Kent (MCP) Sr. Desktop Systems Engineer Computing & Technology Services - SUNY Buffalo State From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Marcum, John Sent: Tuesday, April 15, 2014 11:07 AM To: [email protected] <mailto:[email protected]> Subject: [MDT-OSD] RE: Install Applications TS step - limitations? I've heard of several folks that do not use app model for OSD. I use packages for OSD myself and apps for everything else. From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kent, Mark Sent: Tuesday, April 15, 2014 9:16 AM To: [email protected] <mailto:[email protected]> Subject: [MDT-OSD] RE: Install Applications TS step - limitations? But if you want to take advantage of the app model, you would have to double up your work then (make one Application and one Package) for each application you need to install (via normal deployment and OSD). That's a lot of extra work for us, I was hoping to use the App model for as many installs as possible. Mark Kent (MCP) Sr. Desktop Systems Engineer Computing & Technology Services - SUNY Buffalo State From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Chris Nackers Sent: Thursday, April 10, 2014 2:25 PM To: [email protected] <mailto:[email protected]> Subject: [MDT-OSD] RE: Install Applications TS step - limitations? I can't think of any specific limitation, I've done 50+ in the past with packages. It could very well be related to the app-model specifically. Which to be honest, has given me nothing but grief in OSD. I don't use the app model anymore in OSD if I can help it, I create packages for everything because I can guarantee it'll work 100% of the time, I can't do that with the app model. They did change around the logic, which is why you have only 9 per step and MDT has to convert from the 2 digit list to the 3 digit list. So it's possible there is something in there. Or I'm totally wrong on all accounts :) Chris Nackers Microsoft MVP - Enterprise Client Management Email: <mailto:[email protected]> [email protected] Nackers Consulting Services, LLC From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kent, Mark Sent: Thursday, April 10, 2014 11:57 AM To: [email protected] <mailto:[email protected]> Subject: [MDT-OSD] Install Applications TS step - limitations? Is there a limitation on the number of apps that can be installed using this TS step and the dynamic variables list? I have a couple Roles in the MDT Db for some labs that require large application installs (we are talking over 40 apps). When trying to run this, the Install Applications step fails with the same message: "App policy for 'ApplicationNameHere' not received. Make sure the application is marked for dynamic app install" The Application is marked for dynamic app installs. If I run the application in another role with just a handful of apps, it works fine. I upgraded SCCM R2 to CU1 today as I thought there was a known issue with this. However after applying it and getting the agent updated I'm still getting this error. It just seems to arbitrarily pick one app to throw the error on. Anyone else come across this? Mark Kent (MCP) Sr. Desktop Systems Engineer Computing & Technology Services - SUNY Buffalo State _____ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer. _____ Confidentiality Notice: This e-mail is from a law firm and may be protected by the attorney-client or work product privileges. If you have received this message in error, please notify the sender by replying to this e-mail and then delete it from your computer.
smime.p7s
Description: S/MIME cryptographic signature
