I have finally got vPro/AMT setup and working in a small classroom based environment of about 40 PCs in total. I can ping when powered off, remote power on/off etc as you would expect - and the "Out of Band" support works pretty well.
One problem I have run into is that if a Windows7 install fails part way through (ghosted image, after reboot during sysprep phases) then Intel AMT doesnt respond to anything. Is this a limitation of v5 or in general? Would setting a static IP help in this scenario? I thought the NIC kept the IP address regardless of what the client OS was up to? (In this instance is DHCP but gets a reserved IP).
I have been using the "RemoteISOLauncher" utility from Intel, but noticed that when you boot from a remote ISO the local keyboard is "locked out" from use, even after you close the utility, until you reboot. Is there an option to toggle here or is it something that can be added to the utility or is this "by design" and how vPro always behaves?
The machines are Dell Optiplex 960.
Anyone else seeing the same/similar issues?
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.
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.
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 (:16992/">http://:16992/)