I have a link for you to look at if this doesnt help let me know and we will look at it further
Symptom: Not able to perform an IDER or SOL session on and AMT client from the SCCM Out Of Band Management Console.
Thanks for the response.
Yes, I've seen that link previously and I'm sure I've checked the details.
Telnet is definitely installed on the console machine, and I'm only using a Root CA.
I've added the Root CA certificate into the Trusted Root Certification Authorities store in IE and also in the MMC but still having no luck.
Any other ideas?
Thanks in advance.
Hi again Greg,
Yes seen that link too.
I've been through the "Issue 2" scenario, since I did have multiple certificates in the root CA.
The problem I have is that KVMView.exe, from the same server as the SCCM console, works correctly using a TLS connection, for both the BIOS connection and the GUI components. Just not with the SOL option from within OOBM from the SCCM console; where I get the Serial Connection failed message.
The OOBCONSOLE.LOG shows the regular "IMR_SOLOpenTCPSession fail with result:0x00000020"
So I'm stuck at what to check next!
SCCM does not support use of subordinate certificate authorities for SOL and IDER features.
Can you view the AMT cert via the AMTwebui and verify that it has been issued by a root CA (single CA in the chain) and not a subordinate CA.
Yes, I'm only using a root CA, no subordinate CA involved at all.
The AMT WebUI connects successfully and I can see the certificate path details, and all looks correct. Hence why I'm struggling. Everything seems to be OK, but the SOL feature consistently fails with the same TLS error.
I though the previous link might have offered a solution with the multiple entries in the root CA store. But it made no difference, even after i completely re-provisioned the workstations.
The certificate via IE and the WebUI shows that it's been issued by the root CA and issued to the FQDN of the workstation, with valid dates. The key length is 2048 bits, which I believe is OK
The Certification Path shows OK for both the root CA and the target workstation; these two items being the only entry.
The only thing that springs to mind is that the console isn't referencing the FQDN of the workstation, as the certificate is, it just using the hostname.
Could that have an impact?
I have two questions:
1. When we see issues like this, SOL and IDER typically see the same failures. Please attempt IDER. If IDER passes, the SOL problem is likely an issue with the client and not with configuration.
2. You mentioned access via hostname being a problem. Please attempt to access the AMT webui by hostname only and see what happens. Also, inspect the AMT certificate and see if a client hostname entry appears in the subject alternative name.
Was this issue resolved?
Sorry, not been in the office to test, but will have a look today.
Hi again Kyle. Managed to spend a bit of time on the issue again!
Regarding point 1:
IDER also fails and again refers to the OOBConsole.log file. Entries in here again list
IMR_IDEROpenTCPSession2 Failed to Establish TLS Connection.
I can access the Web console via either the FQDN or just the hostname. When logged on the certificate is issued to the FQDN, and in the details section of the certificate I have "CN=" both the FQDN and hostname.
Should there be an additional section for "Subject Alternative name?"
The OOBConsole.log file shows the client is attempting to connect using the FQDN too.
So still stuck I'm afraid.