AMT KVM - No Port Open?

AMT KVM - No Port Open?

I'm confused about this mysterious port that isn't open after I provision a computer into CCM. In my provisioning profile, I enable KVM and all the other redirection options, and set an RFB password but apparently this is still half-baked after a provision. For example, if I try to connect to the machine via UltraVNC I get this:

I don't get a prompt for a password or anything. Just a failed to connect error.

But here's the thing. If I go into the Manageability Commander, I see this:

If I click into this I get an option to enable the "standard port" 5900 for RFB. Once that is done, I can use UltraVNC Viewer to connect to the machine and get to the user consent screen.

So why is this not enabled when I specify in the profile to enable KVM? I killed the firewall and I still couldn't access the machine so it doesn't seem like a networking port. What exactly is the port this is referring to... something on the AMT device itself?

How do I open this "port" at provision-time? I'd rather not have to open Manageability Commander (whose issues are worthy of another thread) after the fact for every computer I need to connect to. I feel I should just be able to open UltraVNC viewer and type in the hostname::port and be set.

publicaciones de 4 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

It used to be in older versions of AMT, when you enabled Redirection in the BIOS, the listener was automatically enabled. Now that is not the case.  If your MEBx menus  have an option to enable "Legacy Redirection Mode" that should enable the listener for you.  Here is a blog that describes more fully what is going on:

Does your configuration utility provide the ability to enable Legacy Redirection Mode?


In the SDK Documentation if you want to run a script to do this, take a look at the following section:

Change the Listener Enabled Setting

The following steps describe how to change the state of the Intel AMT redirection listener. The listener must be enabled to establish a KVM session.

1.  Ensure that the KVM interface is enabled: See Enable/Disable the KVM Interface.  If it is enabled, continue to the next step.

2.  Retrieve the instance of AMT_RedirectionService, where the “Name” key equals “Intel(r) AMT Redirection Service”.

3.  Change AMT_RedirectionService.ListenerEnabled to true or false (enable or disable).

4.  Invoke AMT_RedirectionService.Put.

Click here for a snippet demonstrating this step

You can execute this snippet by inserting it into the execution template found here.


$redirectionServiceRef = $wsmanConnectionObject.NewReference("SELECT * FROM AMT_RedirectionService WHERE Name='Intel(r) AMT Redirection Service'")

$redirectionServiceInstance = $redirectionServiceRef.Get()

$redirectionServiceInstance.SetProperty("ListenerEnabled", "true")




Follow me on Twitter: @GaelHof Facebook:

First off, thanks Gael for helping me figure all this stuff out!


Does your configuration utility provide the ability to enable Legacy Redirection Mode?

Nothing that I could find. Here's the only relevant options I can find on this in the ACUWizard:

I looked through your link and it certainly seemed like the issue I was having. However, toggling the ListenerEnabled state didn't seem to make a difference on a freshly re-provisioned machine.

When I looked a bit (a lot) more through the Intel AMT Implementation and Reference Guide, I discovered a property called IPS_KVMRedirectionSettingData.Is5900PortEnabled which, on my test machine, was false. A little more poking around, I found out how to change the property with this snippet:

$kvmRedirectionSettingDataRef = $wsmanConnectionObject.NewReference("SELECT * FROM IPS_KVMRedirectionSettingData WHERE InstanceID='Intel(r) KVM Redirection Settings'")

$kvmRedirectionSettingDataInstance = $kvmRedirectionSettingDataRef.Get()

$kvmRedirectionSettingDataInstance.SetProperty("Is5900PortEnabled", "true")


And then I could connect to the machine from UltraVNC using just its hostname (or hostname::5900).

One thing that I didn't have to do was set the RFB password because it was already set via the XML profile. It's weird that you can set the RFB password but not also be able to enable the port in the wizard.

It does complicate pushing out these settings to machines. It seems like in a script I'll have to:

1. Update root certificates (KB931125). This appears to be necessary on "fresh" machines to provision them where they haven't yet gotten a certain root certificate update already. Otherwise I'd just get 110 errors when trying to provision in ACUConfig.

2. Import the XML profile generated by ACUWizard using ACUConfig.

3. Install the IntelvPro powershell module.

4. Execute the above snippet using in conjunction with the Powershell template and using localhost as the target.

That's the plan, anyway. Due to the hurdles I'm experiencing, I get the feeling that I'm approaching this all wrong...

Have you taken a look at the Director in the Open DTK for provisioning?  It doesn't seem like it should be this hard...

Open DTK:




Follow me on Twitter: @GaelHof Facebook:

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya