Intel SCS Task Sequences not working with SCCM 2012 R2 | Intel AMT: Configuration
This post follows on from my previous post which was about running a Task Sequence for Intel AMT: Discovery. This post is in relation to the next Task Sequence in the list, which is called Intel AMT: Configuration.
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:
So we’ve got a few errors here. TCP Error, Caller is unauthorised, Valid password not found. From here I checked the SMSTS.log files to see what was happening. The logs were about 41 pages long, so I’m not going to copy it all here, but there were various errors within this:
<![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:
