Unable to set Wake Alarms

[Reed_J_]

Hi,

I'm having an issue with setting wake up alarms using AMT. For a bit of background, I first encountered this issue when working in a C# code base that use the HLAPI to set wake alarms. When I try to set an alarm with IAlarmClock.CreateOrUpdateAlarms(AlarmClockList), I get an AlarmClockManageabilityException. When I drill down into the inner exceptions the relevant information seems to be these two messages:

"No route can be determined to reach the destination role defined by the WSAddressing To."

"The remote server returned an error: (400) Bad Request."

The part that is most confusing to me is that the code chunk that is throwing this exception was working without issue as recently as Tuesday this week. I haven't made any change to the code running it, and the problem initially manifested without me doing anything at all related to AMT. This same exact code on another machine is working exactly as I expect it to. I've tried setting wake alarms in MeshCommander and that doesn't work either. At this point I'm at a loss as to how I could go about debugging this as I'm relatively unfamiliar with AMT in general. It seems like some sort of configuration error on my machine, but I don't even know how I would figure out what was configured incorrectly or how. 

As for the computer that's running this code, I have Intel ME v8.1.20 activated in Client Control Mode. Below are the two simple sections of code I've been using to troubleshoot this issue.

static void Main(string[] args)
{
    IAMTInstance amt;
    try
    {
        // Generate password based on serial number
        string password = GeneratePassword(<input-param>);
        ConnectionInfoEX ci = new ConnectionInfoEX(<my-ip-address-here>, "admin", password, false,
                                                       string.Empty, ConnectionInfoEX.AuthMethod.Digest,
                                                       null, null, null);
        amt = AMTInstanceFactory.CreateEX(ci);

    }
    catch (ManageabilityException e)
    {
        Console.WriteLine(e.Message);
        return;
    }

    try
    {
        // Set a recurring alarm
        SetRecurringAlarm(amt);
    }
    finally
    {
        amt.Dispose();
    }
}

public static void SetRecurringAlarm(IAMTInstance amt)
{
    DateTime date;
    try
    {
        DateTime alarmTime = new DateTime(DateTime.Today.Year, DateTime.Today.Month, DateTime.Today.Day, DateTime.Now.Hour, DateTime.Now.Minute + 10, DateTime.Now.Second);
        date = new DateTime(DateTime.Today.Year, DateTime.Today.Month, DateTime.Today.Day + 1);
        Console.Write("Setting recurring alarm to:" + alarmTime.ToString());
        AlarmClockList list = new AlarmClockList();
                
        DefaultAlarm alarm = new DefaultAlarm(alarmTime, TimeZoneInfo.Local);
        list.DefaultAlarm = alarm;
        amt.AlarmClock.CreateOrUpdateAlarms(list);
        Console.WriteLine("Success");
    }
    catch (AlarmClockManageabilityException aex)
    {
        Console.WriteLine("AC Manageability exception");
        Console.WriteLine(aex.Message);
    }
    catch (ManageabilityException ex)
    {
        Console.WriteLine("Failed");
        Console.WriteLine("\n" + ex.Message);
    }
}

If anything in the above code looks strange, it's potentially because the two functions were in different files and I did a little bit to combine them in this post. I also hid identifying information for my machine in the code snippets. If there is any more information needed to help debug this, don't hesitate to let me know. 

[Joseph_O_Intel1]

Hey Reed,

The fact the code was working before leads me to believe its the AMT client. The first thing I would do, is to unconfigure and then reconfigure the AMT client. Then perform your test again.

[Reed_J_]

Hi Joseph, I unconfigured and reconfigured the AMT client and I'm still encountering the same errors. Just to be sure we're on the same page, I just ran:

(Path)/ACUConfig.exe unconfigure /full

(path)/ACUConfig.exe configAMT "(path)/config.xml"

Below is the config.xml file stripped of personally-identifying info 

<?xml version="1.0"?>
<Profile>
    <SCSVersion>8.2.0.19</SCSVersion>
    <Description/>
    <NetworkSettings>
        <SourceForAMTName>Host</SourceForAMTName>
        <SharedFQDN>true</SharedFQDN>
        <DNSUpdate>DYNAMICUPDATE</DNSUpdate>
        <SourceForAMTIP>DHCP</SourceForAMTIP>
    </NetworkSettings>
    <AdminCredentials>
        <SourceForAdminPassword>Defined</SourceForAdminPassword>
        <AdminPassword>(AMT Password)</AdminPassword>
    </AdminCredentials>
    <EnabledInterfaces>
        <EnableSOL>false</EnableSOL>
        <EnableIDER>false</EnableIDER>
        <EnableWebUI>true</EnableWebUI>
        <EnablePingResponse>true</EnablePingResponse>
    </EnabledInterfaces>
    <KVMOptions>
        <EnableKVM>false</EnableKVM>
    </KVMOptions>
    <PowerOptions>
        <PowerState>PowerStateS5</PowerState>
        <WakeOnNetAccessSleepTimer>0</WakeOnNetAccessSleepTimer>
    </PowerOptions>
    <TLSSettings>
        <NetworkTLSAuthentication>0</NetworkTLSAuthentication>
        <CRLs/>
    </TLSSettings>
    <ACLs/>
    <EnvironmentDetection>
        <AllowVPN>false</AllowVPN>
    </EnvironmentDetection>
    <RemoteAccess>
        <EnableClientInitiatedViaOS>false</EnableClientInitiatedViaOS>
        <EnableClientInitiatedViaBIOS>false</EnableClientInitiatedViaBIOS>
    </RemoteAccess>
    <Wireless>
        <EnableWireless>false</EnableWireless>
        <WIFISyncType>0</WIFISyncType>
        <Profiles/>
    </Wireless>
    <Wired8021xSetting>
        <Enable8021xSettings>false</Enable8021xSettings>
    </Wired8021xSetting>
    <EACSettings>
        <EnableEAC>false</EnableEAC>
    </EACSettings>
    <ADIntegration>
        <EnableADIntegration>false</EnableADIntegration>
    </ADIntegration>
    <Certificates/>
    <RootCertificates>
        <AddOnly>false</AddOnly>
    </RootCertificates>
</Profile>

[Joseph_O_Intel1]

Hey Reed,

One of the things I noticed is that your using SCS 8, you really should be using the acuconfig and acuwizard from the Intel SCS 11 download.

As to the your methodology for un-configuring and reconfiguring that should do it just fine

Is it just one system or is this issue with others as well?

I did notice several interfaces were turned off in the XML and are generally on by default, which suggests that either your profile is very restrictive or possibly the MEBx is in a confused state. Can you reach the device via the WebUI?

With configuration you provided the WebUI should be reachable remotely, if not check networking first and then if its not, do a CMOS clear and re-provision

[Reed_J_]

Hi Joseph, sorry to only get back to you now but I had to test a few things. I've tried configuring my machine with ACUConfig files from the 11.1.0.75 release of the Intel SCS 11 download. This issue has showed up once or twice on other machines, but strangely enough they fixed themselves as far as I can tell. I am able to reach the device via the WebUI without issue. 

After using the SCS 11 version ACU to unconfigure and then configure AMT I'm still having the same issues setting alarms, unfortunately. 

[Joseph_O_Intel1]

Hey Reed.

My next step would be take a working system and your non-functioning system and run a "Acuconfig.exe systemdiscovery" on them. Inspect the XML's for discrepancies as the issue is probably going to be in there somewhere.

Joe

[Reed_J_]

When I tried to run SystemDiscovery on the not-working machine this is what the log looks like:

2017-04-10 12:16:31:(INFO) : ACU Configurator , Category: HandleOutPut: Starting log 2017-04-10 12:16:31
2017-04-10 12:16:31:(INFO) : ACU Configurator, Category: : ACUConfig 11.1.0.75
2017-04-10 12:16:31:(INFO) : ACU Configurator, Category: -System Discovery-: (PCNAME): Starting to discover the system information...
2017-04-10 12:16:43:(INFO) : (PCNAME), Category: AMT Interface : Wire support:************** 1
2017-04-10 12:16:47:(ERROR) : (PCNAME), Category: AMT Interface error: A Soap Fault occurred.  Error in GetKVMSettings- Failed while calling  WS-Management call  GetKVMSettings (IPS_KVMRedirectionSettingData.Get): A SOAP FAULT was received. :  FaultSubCode: b:DestinationUnreachable
2017-04-10 12:16:50:(WARN) : ACU.dll, Category: System Discovery: Failed to read the registry value (Primary DNS suffix). 
2017-04-10 12:16:50:(WARN) : ACU Configurator, Category: Exit: ***********Exit with code 32. Details: Intel(R) AMT operation completed with warnings: Failed to read the registry value (Primary DNS suffix). 

Also, I guess as an aside if we could do everything we can to avoid pulling the CMOS as a troubleshooting step it would be very helpful. The software I'm working on is part of a software/hardware combo that my company sells, so if we run into a bug like this with customer units it just isn't very feasible to ask them to pull the CMOS battery. If we get to a point where that seems like the only solution then  I'm not against it, but that is sort of a last resort for me, unfortunately. 

[Joseph_O_Intel1]

Hey Reed,

If acuconfig isn't working it is almost always related to MEI driver package in someway. I would just download the chipset driver package off of the OEM's website for the device and install.

One of the most common issues is that the LMS service is not installed, which can be found within services.msc as "Intel(R) Management and Security Application Local Management Service".

Joe

If this doesn't solve the issue, send a PM with your contact information

[Reed_J_]

As a last question before I send my contact info, is it possible that the errors I'm seeing in logs that have to do with Local System Account could be causing SOAP errors? Below is an example of a message I see when unconfiguring one of the multiple machines that is not working. 

(ERROR) : ACU Configurator , Category: Local System Account: Error: failed to retrieve Local System Account using MEI; error code - 3221242473

I did some investigation today and found that a couple of the other machines of the same SKU as the one I'm developing on (so same hardware at every point) are running into the same issue. Unfortunately, one of my working dev machines has the same motherboard as the numerous not-working machines so I'm not sure I can say that this issue might be caused by something on the mobo. 

[Reed_J_]

Actually, upon further investigation it seems the only motherboard I'm seeing this issue on is the Intel DQ77KB motherboard. I haven't seen this on every dev/qa machine with that motherboard type, but I also have not seen this issue show up on any other motherboard type. I don't know if that will help, but I figured I should share that info. 

[Joseph_O_Intel1]

The only issue may have with running acuconfig is if your not running the PowerShell or CMD window as administrator. I do not believe it is required for systemdiscovery.

If your only seeing on a single board, compare that board to a working version and see if the BIOS and MEI firmware are the same

Joe

[Reed_J_]

So unfortunately I compared the BIOS and MEI version for my working machine one the DQ77KB motherboard to the BIOS and MEI version on the not-working mother boards and that doesn't seem to be the source of the issue. On my initial dev machine I'd update the BIOS and MEI to the latest versions I could get, but that didn't help. So I compared my working dev machine to a not-working QA machine and they have the same BIOS version and MEI version as each other as well. At this point, I think the best thing for me to do is just PM you my contact information.