This currently is documented as not supported:
The applications must meet the following criteria:
The application must have a deployment type of Windows Installer or Script installer. Windows app package (.appx file) deployment types aren't supported.
In other words if this feature was added it would be a new feature request, not a bug that needs to be fixed. Just FYI.
This request doesn't make sense. All the Apply Network Settings task does is add the domain join information to the Unattend file. It does not actually join the domain. Windows Setup is the one that actually joins the domain via the settings in the Unattend file. There is actually no ConfigMgr components running when the domain join happens during the Windows Setup, so there is no way for ConfigMgr to "retry". If ConfigMgr "retried" during the Apply Network Settings task, all it would be doing is readding the domain join information to the Unattend file. You allude to what the actual solution is which is to use a Join Domain or Workgroup task right after the Setup Windows and ConfigMgr task which has a condition that it will only run if the device is not domain joined.
Thank you for the feedback, updating status to Noted
See https://blogs.technet.microsoft.com/configmgreng/2016/03/11/configmrguv/ for an explanation of each status value
Boundaries for MPs are not currently supported during Task Sequences. This is actually documented here (see the second note):
Thanks for the suggestion – updating status to Noted
blogs.technet.microsoft.com/configmgreng/20.. – explains each status value
This is actually a really bad idea. This was changed back in ConfigMgr 2012 SP1/R2 and it caused tons of problems. The main problem was that the ConfigMgr client would start up really fast on fast PCs and on some networks, the network connection would not be fully available. This caused the client to evaluate to Internet instead of Intranet. End result is it would cause the client to start looking for Internet based MPs and DPs and tasks would start failing, primarily the Install Application task and the Install Software Updates task. If your environment supports setting this task to Auto, then great, but the default should remain at Delayed and only changed manually to Auto for environments that support it.
Updating status to started – see https://docs.microsoft.com/en-us/sccm/core/understand/find-help#send-a-suggestion for an explanation of values.
Our 1906.1 Technical preview is released today and contains changes to address this ask. On the Install Application steps there’s a new checkbox ‘Clear application content from cache after installing’.
This can be used for static or dynamic App install and is per step not per app so if you’ve been using the 99 max. you may want to refactor your task sequence to use multiple Install Application steps.
For more info:
We made some changes in the TS step for App Deployment, that gives you more control over cache. Try this out in #SCCM TP 1906