In general, I don't know about your Windows installation status, but how does it works: when your machine is turned-off, AMT takes control of NIC, while when the operating system is up, AMT releases the NIC ownership to Windows, and in this case Windows kernel + drivers/services takes care of network traffic. For example, if you set in your firewall to block all AMT ports or if LMS is not running, redirecting requests from 16992/16993 to AMT you won't be able to manage. The OS should be unresponsive to AMT takes control back.
First, I'm glad to hear that the Remote ISO Launcher is working for you (I'm the author of the tool, feel free to give any feedback!).
When the network drivers load most traffic will be sent up to the OS (for example, if you can ping AMT, once the OS loads the ICMP packets will be sent to the OS and if you have the windows firewall enabled the packets will be dropped). You should still be able to communicate to AMT. You can test this by clicking the 'Client Info' button in remote ISO launcher (it should still be able to retrieve info from AMT).
As for the keyboard lock, this is specific to the OEM BIOS (in this case Dell's BIOS). Remote ISO Launcher doesn't specify any keyboard locking so this can vary between OEM's or OEM BIOS's. To unlock the keyboard in this case you'll need to do a reboot of the system. (I don't think you can currently do this from within remote ISO launcher as Remote iso launcher will always maintain a serial over lan connection). You can do this from the WebUI (http://<IP Address of AMT System>:16992/)
Hi - thanks for the reply. That was my understanding of how it worked, so in theory my Windows installation is failing before its loading a network driver - so I would presume AMT would be in charge until that happens. From what I can tell Windows claims to be in charge even though it hasnt loaded the driver yet, which seems to leave the machine high and dry someone physically powers it off.
It seems to be a very frustrating scenario as it means that AMT does not have 100% remote control of the machine as the marketing of it would suggest. I would consider this scenario to be "Out of Band" but I dont seem to be able to recover.
AMT should always have control over the system on it's manageability ports (16992/16993) on a wired connection regardless of the OS driver being loaded or not. AMT will not respond to ping (ICMP) packets as they are passed to the OS, but other management tools (Remote ISO Launcher, AMT Commander, AMT WebUI) should still function.
I have similar issue, I am using VNC viewer KVM, When I restart OS form Widnows shutdown function through KVM, AMT AND OS ping both fail ...
MAIN ISSUE IS THAT, KVM GOT DISCONNECTED...
I thoght, AMT/ME should continusly works even thou OS IS DOWN.