Looking at the ldprovision.log it shows the failure came when it called captureimagehandler.log:
2015-03-09 15:55:15(1864-1868) ldProvision:Launching action handler [CaptureImageHandler.exe] with parameters ["]
No user logged in, change CurrentTokenWithInteraction to CurrentToken
2015-03-09 15:55:59(1864-1868) ldProvision:handler launched.
2015-03-09 15:55:59(1864-1868) ldProvision:Reporting action status: 5 to core
The smbios stuff you're seeing doesn't look to be a problem, so I wouldn't worry too much about that specifically.
The most common thing that I see cause this is that ldprovision.exe calls CaptureImageHandler.exe which in turn calls MaptoPreferredHandler.log and there ends up being some kind of authentication error.
I would suggest tracing the order of handlers to find which handler is actually failing.
If still unsure about the failure, post all of the *.log files from X:\ldprovision and we can get a better idea of what's going on.
I REALLY appreciate your response and help with this issue. I am grateful to you. I have now read the documents you provided and understand, a little more, about interpreting the log files. I will run the scheduled task again to reproduce the logs. I will post them here when I have them.
Again, thanks for responding :-)
I spoke with tech support this morning. I cant begin to tell you how pleased I am with their quality of support staff there. It is awesome!
Thanks for your correct answer, as it was the beginning of the troubleshooting process we went through. And ultimately, it was unrelated to the SMBIOS as you claimed here. Thanks a bunch
I'm glad to hear you're up and working now. Out of curiosity, can you share what the issue ended up being in case anyone finds this thread later on?
Sure I can!
It was a lot of information and I will need some time to soak it up and ponder it over during the weekend. It will then be clear to me and I can explain it better. I'll respond to this on Monday.
Y'all have a great weekend!
It turned out to be a DNS pointer issue, in a nutshell. Now, let me explain first that we stepped through the log files created by the different handlers. I was taught a lot during this process. Anyway, about the third log file into the examination process, which was called "MaptoPreferredHandler.log" (just as you suggested), there was one line that stated a network path was not found. We then tried to UNC to the share in question and it would not connect. So, we then cracked open the boot.wim file and insured the server name on which the share was located was correct. I learned a heap during this process, too! The server name was correct in the boot.wim, but it could not be resolved due to a DNS pointer not being present. Once we put a pointer in place, it worked like a charm! If you have any other questions or would like specific details, just let me know.
Thanks for the thorough recap. Glad to hear everything is working!