I’ve seen this as an issue now a few times now in my lab and production environments as well as on the forums. In brief, this specific issue is an access denied (hresult of 0×80070005) when downloading the application content and is clearly denoted in either smsts.log (if the application install is during a task sequence) or CAS.log. This only happens on client systems in untrusted domains (note that workgroups are essentially untrusted domains); for task sequences, this is of course the case during a build and capture.

So what’s the fix? A simple hotfix as described in KB2522623 and titled “InitializeSecurityContext function might not fall back to NTLM authentication in Windows 7 or in Windows Server 2008 R2 when Kerberos fails and has the STATUS_NO_LOGON_SERVERS status”.

For a build and capture task sequence, simply put the hotfix msu into a “classic” package and use a Software Install task followed by a reboot task before you try to deploy any applications.

This isn’t a cure all for any woes you may be having deploying applications in ConfigMgr 2012, but it does fix this specific access denied issue when downloading application content on Windows 7 SP1 client systems in an untrusted domain.

On a different, but similar note, for build and capture task sequences, you should also be specifying the SMSMP public property in the Setup Windows and ConfigMgr task so that the the MP can be found. During a build and capture, the client is in a workgroup and thus has no way to locate the MP which is needed for Application installs as well as Software Updates during the task sequence.