I found in another post that localhost access is not suppoed to work, by design.
After opening some firewalls I tried to access this from another computer and the page fails to load. In looking at a network trace in order to try to understand the failure, it turns out that the TCP session setup to port 16992 works fine (see SYN, ACKSYN, ACK), then the calling (IE browser) machine issues a first get request and the AMT machine responds with a TCP reset, which kills the session.
So to summarize, the service is listening on 16992, inbound TCP connections are accepted, but the first get request from a caller results in a TCP reset.
As you came to the conclusion of, by design you are not able to access the AMT Web UI from the local machine. You can only access the WEB UI of the AMT client from a remote connection.
When configured for SMB / enterprise non-TLS mode, you will need to connect to the IP or FQDN/Hostname (anything that resolves to the IP Address) on TCP/IP port 16992.
In an Enterprise TLS mode, you will need to connect to the web UI remotely with https://<client>:16993.
In terms of your SMB console question, there are multiple ISVs that support a SMB based configuration. The selection of the ISV really depends on the requirements of your environment and costs. I would recommend consulting the vPro Expert SMB Talk Zone.
Thanks for the info but I am still stuck. As I described when I try to connect to http://192.168.0.29:16992 (from another machine) no page loads. I can see that there is a service listening on this port and that I get a TCP session to the port from my web browser machine. Unfortunately no page loads.
What could be wrong with my setup? Are there any logs or config info I can gather that would help to narrow this down?
If your configuration is correct, that should work just fine. I'm assuming that you have verified that the IP address did not change on you and that you are still configured in SMB within the MEBx?
I tried re-installing/flashing 3.2.1, I tried setting everything in Control+p back up for small business mode... same behavior (LMS.exe is listening on 16992, but when trying to connect from another machine with a web browser we see a TCP session setup, follow by a GET request from the browser, followed by a TCP reset from the AMT machine ).
What could be wrong? Are there any logs/data/config that might help to narrow this down?
You may want to try and leverage the
Manageability Developer Tool Kitto connect to the client. It may provide some additional insight into root of the issue.
Your reply was rejected by a moderator. Please edit your reply and resubmit it for approval.
HskXrb 百家乐[/url] MidGhb 英超宝贝[/url] SsqKma 英超赛程表[/url] OhhGga 足球直播吧[/url] XktXsb 足球直播[/url] JjyVyc NBA直播湖人[/url] 新浪体育NBA直播[/url] MnjCgr 新浪NBA直播[/url] FqeCxy 太阳城[/url] JpdSet 新全讯网[/url] LcaCpv 博彩通[/url] EzvBys 太阳城娱乐城[/url] RcrRby 芝加哥娱乐城[/url] UzlBqs 百家乐[/url] KwpXip 博彩通[/url] RwnUaq 博彩网[/url] HioSph 德州扑克[/url] OfpNff 88娱乐城[/url] OmiWag 太阳城娱乐城[/url] 全讯网[/url]
LOL 5 years and problem still persist... vPro (intel AMT, KVM) is also affected. Complete power cycle or connetion via Manageability Developer Tool Kit resolves this issue. When connecting to server after receiving TCP SYC, server responds sending RST.