I am seeing some strange behaviour by my AMT clients (HP DC7700 and Intel DQ9656GF). This is the second time i am experiencing this behaviour in a few months and both times it happened just after sending my clients a power-off command using the AMT DTK's remote stack and then quering the power state.
What happens is that the clients do switch off, but they then become unavailable, exactly as one would expect them to behave if they had been provisioned with AMT available in the ON. The problem is that these clients have all been provisioned for AMT to always be on, i have verified this. When i manually switch the clients on again i can communicate with them as normal, but from that point onwards they are always unavailable when switched off. This problem happened yesterday, today the clients are acting normal again.
I am using the Intel SCS 3.0 to provision my clients and use the DTK's remote stack to communicate with my clients. I will be re-installing my server during the day and will be reprovisioning my clients. I will let you know if the problem happens again.
Hi there. This is something I really want to investigate. Could you confirm that once off, you can't access the Intel AMT Web UI? I want to make sure that Intel AMT is off and that it's not an issue with the DTK tools.
Also, how frequently does this happen? You seem to indicate that once it does happen, Intel AMT will be off each time the computer is shut-off.
I imagine that if you pull the plug on the computer, it will start working normally again. Can you see if Intel AMT is off when the computer is sleeping (rather than off), check that the web UI can't be access and send us the BIOS versions? (You can find the BIOS version in the asset inventory of Commander andcut & paste that).
Your help would be most appreciated,
Ylian (Intel AMT Blog)
Hi Adrian and Ylian,
I also encountered this problem many times when I was testing my setup and config app. When it occurred I was stillable to access Intel AMT Web UI but the status of AMT indicates "OFF" eventhough the OS is booted. I was not using the DTK during that time, so it must be another problem.
When I turned off the computer and unplugged it for about 10sec and then turned it on, the problem was gone.I guess thishas something to do with Intel ME.
Sorry for the long delay in getting this information. The BIOS versions for the AMT clients are as follows:
HP DC-7700 BIOS version= 786E1 v02.09 02/06/2007
DQ695 = version = CO95610J.86A.5882.2007.0413.0100
I did some more tests and have confirmed that the issue does not affect the AMT DTK in any way. I took my AMT client, removed the power and then replaced it after 10 seconds. I then used the NetStatus.exe to monitor the AMT firware's response to a ping message. The client was responding to all pings at this stage of the test.
I then manually powered up the client and once in windows manually powered it down through the Start->Shutdown menu in windows. Once the client shut down it immediately stopped responding to the pings. I left the client in this state and after 8 minutes the AMT firware became responsive again. At this stage it would respond to any AMT command i gave it. I managed to power up and power down the client without further problems, both manually and through AMT commands.
So it seems that this issue only happens when the power has been removed form the system and it is powered down for the first time. Each power down there after seems to have no significant effect on the AMT firmware (however i do notice intermitent periods where the firmware stops responding to the ping for a few seconds). So this is not a critical problem, but it is annoying to have to wait those 8 minutes each time i remove the power (something i do from time to timeto simulate various real world problems).
Firstly thanks for all your help with this matter so far. It seems the problem is not with the Intel systems at all but rather somewhere within my profile creation code. I decided to use the Intel SCS console to create a profile and then provision my clients with it. The problem immediately went away.
So I now know the problem is not at all with any of my code that does the power on/off, but rather with the code that creates the SCS profile code. I have gone over the code again and again but cant seem to find any problems. I have compared my code to the Intel SCS Console and everything seems to be in order. Is there any type of diagnostic program I can run against the client to retrieve all its settings? Perhaps this can show where the problem lies?
Sorry for all the trouble this has caused you guys so far. We are having a demo at the South African Intel day next week Friday and it would be great if I could sort this out before then. This is the last problem we are facing that is preventing us from releasing this software.