This is a second post in a matter of days and although I like the new App model I must admit I am far from impressed on its current stabilitly and apparent frailty when compared to regular packages.
Aside from the dependancy in and around Build & Captures, at present the revision history seems to play potential havoc inside of Task Sequences in certain instances as outlined below:
When building a machine from a Task Sequence, an application (or multiple) will fail and produce what is apparently an access denied message (0x80004005) however the NA Account is configured correctly and all boundaries are in place.
The source of the issue can be traced to the revision history in the Task Sequence being referenced to an incorrect version causing the install to fail.
This explanation is detailed in this excellent post
Although I like the new App model I feel it has some way to go before moving away from Packages all together.
Since the release of ConfigMgr 2012 Microsoft has employed a more dynamic approach towards application delivery in the form of Applications as opposed to standard Packages. These work in a similar way but come into their own for more complex applications requiring dependancy and being able to determine the presence on a machine rather than using scripts etc.
Although I use these for alot of customers I must admit there are instances where I still prefer the older model as there are advanced elements of troubleshooting where they are easy to get to an issue but also the stability of the platform still does not seem to have been ironed out.I have had countless instances where packages of the same source work fine but produce unrelaible results when working inside of OSD.
Nice lead onto topic 🙂
For one client I decided to move the Build & Capture over to pure applications where possible as opposed to packages and stumbled over an instability when producing the build and capture where they would not install.
Now I try to follow my own rule of thumb/best practice for Gold Deployment which is as follows
VM (Hyper-V)
Non-domain joined during sequence
This scenarion for a package version of the TS works a treat with no issues however transitioned to applicaiton it failed as soon as it hit the first package.
so what options are availible????
The cleanest option I have used to remediate requires a couple of adjustments:
1 – On the Setup Windows and ConfigMgr step, add in the SMSMP=YouCMbox.FQDN
2 – While I was performing the Build and Capture I added in an IP Address Boundary into the boundary group where the contents was located.
This resolved the issue and allowed the Applications to install.
So why is this required?
Well…… Assuming you dont join the domain during the Build & Capture and then Dis-Join (which is an option, just place in an OU with no policies!), the client is unable to query AD for the vital MP information so it needs to be spoon-fed with all the information it would otherwise gather on its own and without that information it is unable to access the Applications.
This issue is not a problem for standard packages which is just a number of differences between the two.
Ill admit im yet to be completely sold on Applications but will endeavour to try to adopt the new practices wherever possible 🙂
