SCCM – Task Sequence App Deployment Help

[ID-10-T]

I’m desperately in need of assistance in troubleshooting a deployment issue I’m encountering here. I’m hopeful that one of the SCCM experts here can help me out...

 

I have a million and a half applications (not packages) shoe-horned into SCCM for deployment to various labs across our university. When I deploy the applications through Software Center, everything works great. However, when I try to deploy them as part of an operating system deployment task sequence, many of them fail to deploy. The operating system itself deploys fine and at the end of the process, I have a fully functional system minus the apps that failed. Not all fail, but many do. I’ve read the various logs until my eyes begin to bleed and I think I’ve found the problem but I’m not sure how I can correct it.

 

Because I’m new to this whole SCCM thing and I’ve had to figure it out as I go, I have many, many, many applications that are high on the revision scale due to my numerous trial-and-error packaging attempts. For example, Matlab 2018b is currently sitting at 14 revisions. This is one of the applications that fails to install correctly. Peering at the logs, AppEnforce is referencing revision 11 and failing to install the application. I’m convinced it would work if it tried for revision 14. Can anyone tell me why this might be happening and how I can resolve it? Why is SCCM trying to deploy an older revision instead of the latest and greatest?

 

I’ve seen several reports of this happening with older SCCM releases but apparently the issue was addressed and resolved in the 1802 and later builds. We are currently running on the 1802 build and the update to 1810 is running as I post this. Hopefully, I can report back shortly that the issue has been resolved but just in case…if anyone can help me out, I’d be most appreciative.

 

If you need logs, let me know and I can throw ‘em up for your perusal.

 

Thanks.

[MartinByard]

Hi ID-10T,

 

From my experience being high on the revision numbers doesn't really matter, the problem would seem to be the install step referencing the wrong revision (as you suugest). For the most part i haven't had this issue, as my task sequence seems to pick up any changes made to the apps.

 

Quick question to start - have you tried removing the app from the task sequence, and then re-adding it (as this should get it to reference the latest revision that you have)?

[free780]

AppEnforce.log on the client is your friend. I know that Applciation with no content fail in the Task Sequence. You can use Variables to workaround this.

[Whisky]

I would agree we MartinByard about revisions.

 

Under the properties of your application there is an "Allow this application to be installed from the Install Application task sequence". See if it's ticked.

 

Also try to "update content" on your deployment types within your application.

[ID-10-T]

Thanks for the replies, everyone.

 

I'm running another test based on some of the suggestions. I've updated to SCCM 1810 now so that may solve the problem as well...fingers crossed.

 

I went through a subset of the applications that are problematic and ticked off the "Allow the application to be installed..." option, per @Whisky's suggestion. Some of the problem applications did have this flag set already so I'm not sure it will help but it's worth a shot. Also, per @Whisky, I've updated the content. I had done this previously (hence the many revisions for some of the software) but doing it again (shouldn't) hurt anything. I haven't tried @MartinByard's suggestions yet, but it's next on the list. I remain cautiously optimistic that this test will work flawlessly and I can get back to drinking coffee and watching YouTube videos.

[Whisky]

Might be worth posting the AppEnforce.log as suggested by Free780.

[ID-10-T]

No joy! Deployment of some applications continues to fail when deployed during a task sequence but continue to roll out successfully via Software Center. I'll move on to @MartinByard's suggestion about removing and re-adding the applications to the task sequence and see how that works. Poking through the logs again, AppEnforce doesn't reference the failed applications at all, however, AppDiscovery does contain references with errors before moving on to the next application (the task sequence is set to continue if it encounters errors). For ease-of-reference, the task sequence should be installing in the following order: ArcGIS Pro, Google Earth, Java JDK, Matlab, SPSS, Visual Studio, and Windows SDK. Everything works up to Java JDK, then errors out on subsequent applications until it gets to the Windows SDK which installs successfully.

 

In the meantime, for your sleep-inducement pleasure, I'll attach the AppDiscovery and AppEnforce log files. I also have AppIntentEval and SMSTS logs, if you're still awake.

 

AppDiscovery.txtAppEnforce.txt

[Arthur]

Everything works up to Java JDK, then errors out on subsequent applications until it gets to the Windows SDK which installs successfully.

Have you tried adding a reboot step into your task sequence after Google Earth?

 

Also, how large is your cache?

 

https://deploymentbunny.com/2018/08/16/nice-to-know-application-or-packages-works-great-when-deployed-after-osd-but-some-fail-during-osd

Edited January 11, 2019 by Arthur

[free780]

Try looking at execmgr.log I think on the client. Check command lines.

[ID-10-T]

@Arthur, I owe you a beer or ten. The cache size looks like the root of the issue. During task sequence deployment it is set at the default 5 GB. I have the client set to enlarge it but that doesn't appear to take effect until the entire process has completed. The article you linked to gave me the missing clue: SMSCACHESIZE. I enlarged the cache to 50 GB and the applications deployed successfully with the exception of Visual Studio 2017. Sadly, the VS installation files are ~40 GB and even a 50 GB cache just doesn't have the space to deal with it alongside all the other software. My test machine has the space to spare so on Monday, I'll bump up the cache size to "ridiculous" and see if VS works; I'm betting it will. Thank you to everyone for your help!

 

Have a great weekend!

[free780]

You can set the command line for Visual Studio 2017 to the full UNC path and clear the content location. This gets around the cache size issue. However if you have clients that rely on https for content download aka Internet clients they won't be able to download content. You also hit the issue of applications in task sequences with no content requiring variables.

[ID-10-T]

Good morning, all,

 

Once again, thanks to everyone for pitching in to stop my crying. I'm happy to report that applications are now deploying correctly during OSD thanks to an increased cache size (I had to bump it up to 60 GB). I was already aware of @free780's suggestion to use a UNC path but our network consists of a couple of tin cans and some string, so the impact while trying to deploy to 60+ machines would have the network guys breaking out the pitchforks. So, unfortunately, not an option for me. But the issue seems fixed now, so thanks again to everyone for helping me out.