This Task Sequence has the following details within SCCM:
Essentially the %% details are taken from within the Configure.bat script. Running the TS isn't a problem, but it is deciding to fail when after it's downloaded the required data:
Surprise surprise! I guess it wouldn't be SCCM if there wasn't issues! Now the fun part of finding out why it's failing! I had a look at the event logs on the workstation that I was running this TS on and I came across this event:
<![LOG[Failed to run the action: Intel AMT: Configuration.
The process cannot access the file because another process has locked a portion of the file. (Error: 00000021; Source: Windows)]LOG]!><time="15:10:04.029-480" date="07-14-2016" component="TSManager" context="" type="3" thread="2724" file="instruction.cxx:895">
I had a look at the Configuration.bat file that the Task Sequence was calling and made a few changes to the contents:
I also ensured that the following contents had been edited so it was showing the correct SCCM server, and site:
Once I had done this, I ran the batch file again from the local workstation (instead of running it through Software Center) so I could see how it was running, and whether there were any error messages etc. This time it progressed a lot further than before. I don't have a screenshot of the error message that I was getting this time, but it was essentially connecting to the AMT device and then erroring out saying that the password was incorrect.
Looking into the setup of the whole script/software, it looks like Intel SCS and Intel AMT: Configure relies on AMT not being configured on the local device. What had happened was this device had been setup with MEBx (which is essentially the AMT login through BIOS) where it forces you to reset the password. When this script was trying to connect to the device, it was using the default "admin" password which was incorrect as it had been changed. This is why it was failing.
The only way to get around this was to take out the CMOS battery to completely reset the BIOS and MEBx. After doing this, I confirmed that the "admin" password was back in, not the custom password we had originally configured. When running the script now through Software Center, it works!!
After doing this, I was able to Discover AMT Status through SCCM:
Once that was complete, it now showed me that the device had been externally provisioned!
We can now control the device through SCCM:
Part 1 - Intel AMT: Discovery