AppEnforce.log does exist during OSD, it depends what part of OSD you are running in when the error occurs. As you are installing applications I will assume you have already installed the client as part of the task sequence.
In this case your logs will be in %SystemRoot%\CCM\Logs, I have just forced a task sequence to fail installing an application and you can find it there. Failing that let the machine reboot after the failure and look in the normal location and you will find the logs in the normal place.
If the logs do not appear at all then this would suggest the application inforcement has not even started when the failure is thrown. In this case look for any errors in smsts.log for the step you are running. You will see an exit code, usually 24 (download failed) in the log file for the application install step.
I'm going to go out on a limb and say the real problem is trying to work around the wim being installed to the D: drive. This is because the install.wim from the DVD is being used for installation.
Microsoft's recommendation is this: Import the install.wim file into sccm as an Operating System Installer, (not Operating System Image). Create a new task sequence to lay this installer down, update, install apps, etc, then sysprep and capture. For best results, let sccm sysprep and capture the image.
Then, import the wim created from this task sequence as an Operating System Image, and use this for deployment. This wim should install to the C: with no hacks workarounds, and the error above should go away.
As for the cause of your error, as you probably know if your msi doesn't return 0 (successful) or 3010 (restart required) then the task sequence will fail, unless
You're running a command line step and tell it what error codes to expect
You explicitly tell sccm to continue on error for that step.
A thread being ran by your msi is returning a 32 which appears to cause the msi installer to return a 1603 back to sccm, which kills your ts. It is probably hardcoded to delete something from C:\Windows\Installer, or an environment variable is returning that path, either way I would redo it, because patching this could be like playing whackamole, with other problems cropping up in the future.
Best Answer
The hard part here is that the SCCM migration log doesn't give you any more detail than the SCCM UI. However, the WIM image is mounted to insert the drivers and DISM is used to service the image.
Consult the DISM log at
c:\windows\logs\DISM\dism.logon the SCCM 2012 server. It will report that files are not available when trying to inject drivers. There are a couple of ways to fix this: