Sunday, 12 August 2012

Troubleshooting KVM control for Vpro

Hi Everyone,

Have you ever wondered what that word 'Vpro'  means for you? You will see it on the Intel sticker that is stuck to your laptop or workstation.
It may look something like this:

Let me explain, every help desk would use some sort of remote control software (dameware or VNC), to support their computer fleet remotely, at operating system level. Well, one of the technologies within Vpro allow you to do just that, but with one huge benefit, it is not reliant on the operating system, you can actually control the computer at bios level. You can power it off or on remotely too.
The feature within Vpro is called KVM (Keyboard-Video-Mouse). It is available within firmware versions 6.02 and onwards. You can upgrade 6.01 to 6.02. The chipset has VNC server on it which allows you to remote control the system regardless of the operating system.

You can use multiple applications such as VNC viewer plus or Intel's free program KVM view, to access the VNC server on the chipset. If your like me you properly manage your fleet with SCCM, you can install an add-on that allows you to control a system with a right-click action.

To leverage this technology you must first activate it, which is also known as provisioning a system. You do this using a product from Intel called SCS and a provisioning certificate. It's important to understand the different certificates that are used to provision a system. I'll explain this certificate so we all understand it. I like to use real world examples, something we can all understand, so here goes.

If I'm at a coffee shop and a gorgeous women is sitting at a table. Say her name is Jessica. Jessica is waiting for me to talk to her however, Jessica will only talk to me if her father (Bruce) approves. Once Bruce has checked my background and determines I'm ok to date his daughter, Bruce will give me a letter to pass to Jessica which says he approves. Once I give that letter to Jessica and Jessica checks to ensure it's real she will talk to me :)

In this example,
  • Jessica is the client machine that I want to provision
  • I am the SCS server that wants to provision the client machine.
  • Bruce it a trusted certificate authority that the client machine trusts.
  • The letter is the provisioning certificate that is singed by the certificate authority which is trusted by the client machine
Clear as mud?

The root hash of the certificate authority which issued the provisioning certificate must be stored within the Vpro's firmware. Systems come with preconfiugrated hash's, from well known certificate authorities, meaning you can provision systems without having to physical touch any of your fleet. The cheapest is Godaddy.
Once the system is provisioned (the Vpro chip trusts your SCS server), you will be able to remote control the system using KVM View or VNC viewer plus.

If you plan to integrate a provisioned system into SCCM, you also need to secure the system with TLS (Transport Layer Security), Kerberos authentication and Active Directory integration. It's pretty straight forward once you know what you are doing.

There is alot of information which shows you how to provision and manage Intel Vpro chipsets. I thought I would share my experience. I'm not an expert and don't have all the answers but I hope this will save you alot of time troubleshooting.

1. Ensure the systems are Vpro capable and if you want to control the systems ensure they have the Intel(R) HD Graphics Driver.

Some useful links to help checking this are below

2. Understand how the different ports and protocols work. Gael Holmes Hofemeier from Intel wrote a good blog about this which can be found here

3. Download the lastest version of the Intel Setup and Cofiguration software (Intel SCS). At the time of this blog it is located here. There are two documents that will help you setup the software. The user guide and deployment guide.

4. When you are testing KVM control, download VNC plus. At the time of this blog you can download it from here

5. When you first provision a system with SCS do it with the lowest security possible and then work your way up. For example
  • Provision a system without TLS and connect via IP address.
  • Provision a system with TLS and connect using a Digest username and password.
  • Provision a the system with TLS and connect using a AD Authentication.

6. If you are having a problem connecting by host name, turn of IPV6. I am still working out why this is an issue and you can follow the progress on this forum.

7. In you think typing in the RFP password is a solution for TLS errors as I thought on this blog you are wrong. It bypasses TLS.

8. To setup TLS security for the provisioned systems, follow the instructions on Page 170. The guides release date is Jule 12th 2012 so it might be a different page, if you are using a different version of this guide. This is the certificate you select in your SCS profile. Once provisioned with TLS you should be able to log into https://FQDN:16993/

9. If you are using an internal certificate authority to provision the systems, rather then a certificate authority such as godaddy, follow the instructions in the SCS user guide on page 186. There you will create a certificate template,certificate request and enter the root hash manually into the Intel AMT firmware. This guides release date is Jule 12th 2012 so it might be a different page if you are using a different version of the guide.

10. I think it's best to provision the systems with SCS and not SCCM. Then if you decide to upgrade SCCM or move to a different solution you won't need to unprovision and reprovision the systems.

11. If you have SCCM and want to integrate SCS with it, Intel have already built the scripts and instructions on how to do this. It can be found here and is very easy to follow. It actually provides scripts that will unprovision and reprovision systems for you.

12. If you cannot control a system with the Intel add-on (customised KVM-View) you may need to import the Root CA into KVM View.

If you have any questions or comments or need any help please leave a comment.


  1. Hi blair,

    Seems like I am facing a similar issue with my vpro setup here as well. My setup is as follows:

    1. Two VMs (standalone win server 2008 without AD domain services and are connected to our corporate network) - Running SCS one and MPS on the other
    2. Root CA is running on one of our physical domain controllers on the corporate network
    3. AMT Objects OU, User accounts and Groups are located on another physical domain controller.
    4. Vendor cert GoDaddy installed on the SCS server.
    5. Client AMT version 6.2 and 7.x
    6. TLS profile with AD integration

    The problem is we cant remote KVM nor run non KVM commands using Intel vpro PS module via TLS and kerberos authentication. For no KVM commands, the PowerShell console errors saying "Unauthorised" while the VNC viewer brings up a credentials box asking for the digest credentials. Kerberos doesnt work but digest works fine with TLS. Just wanted to verify where did you turn off the IP v6 ? Did you turn it off on the SCS server ? Root CA or on the Domain controllers or Remote Mgmt Console or vpro clients? Please clarify. Thanks in advance.

    1. Looking forward to hearing from you :

  2. Hey Mate,

    Didn’t catch your name?

    So KVM control works with TLS and Digest but it doesn’t work with Kerberos?
    I don’t think it will be an IPv6 issue; however you need to turn off IPv6 on the computer trying to control the system. If you ping the system it should reply with an IPv4 address. It actually just changes the order and tells the system to try IPv4 first.

    What happens if you apply the register fix and try to goto https://fqdn:16993? Can you log in? Any cert issues?

    What about AD authentication without TLS?

    If you are using an AD security group, is there any change if you add the AD account directly into the SCS profile instead of a security group?

    Your account you have logged in with does have the right to control the system? And the desktop is on the same domain?
    It has happened to me before. I’ve fixed it by performing a full unprovision, deleting the IME$ account from SCS and AD and performing another provision.

    Hope this helps

    Could you share any information about the setup of MPS? I haven’t set it up yet but I’m planning to.

    1. 1. I didnt bother applying the registry fix as it is only applicable for Win XP and win server 2003 (we are all on WIn 7 and Win server 2008).
      2. Cant login into the webUI using ps://fqdn:16993. No issues with cert as we can provision just fine. What aspects of the cert should I be looking for? Is there any way to verify this to be sure.
      3. AD authentication with and without TLS = FAILS
      4. We tried with individual doamin user accounts as well = FAILS
      5. How to check whether my account has rights to control systems?
      6. Client and Mgmt consoles are on the same domain + intranet + clock too are in sync.

      No Luck. Running out of ideas. Please help !

  3. Happy to help my man,
    So your telling me everything works but AD authentication?

    1. You don’t need to apply the fix but you still need to make the change to the register on Windows 7 and Windows 2008 to get to the web interface. The Register Entry is FEATURE_INCLUDE_PORT_IN_SPN_KB908209

    2. The certificate that is used to provision the system (godaddy cert) is different to the certificate template that is for TLS. Check out page 170 of the user guide.

    3. When you create the SCS profile you also add the domain user accounts in the Access Control List. You may have added a digest and AD security group? Check out Page 84 of the deployment guide.

    4. If you first comment you said the AMT objects OU is located on another physical domain controller. It should replicate to all domain controller? Is the IME$ account being created on the AMT OU? And you have delegated the correct rights to the OU?

    Let me know how you go? Once you get into the web interface check the event logs tab.

    Also it may be an issue with the root CA on the controlling system. Try to control it from another system. Sometimes if you have multiple copies of your Root CA in the Trusted Root Certification Authority Store if can create issues.

  4. Hello Blair, Good day to you my friend.

    Well here you go.....
    Point no. 1 >> Doesnt work, not even the Powershell commands (run as admin) with intel vpro module loaded into it.
    Point no. 2 >> Agreed. Beside the provisioning cert from godaddy, We also have the cert template for TLS and it has been extracted from the root CA.
    Point no. 3 >> Yes, we have added the users (digest+domain users) into the ACL, saved the provisioning profile and reprovisioned the machines with the updated SCS profile. We can see the users when we query the AMT with the checkAMTACL tool.
    Point no. 4 >> Yes, Agreed. The AMT OUs have been replicated to the other DCs in the domain. BTW SCS is just a stand alone virtual server without AD domain services running on it.
    However, I am not sure about the delegation rights that you are talking about? What are the steps of delegation rights? Please share necessary steps for delegating rights/access with screenshots if possible. If the delegation rights were incorrect, how can do the remote provisioning without any problem?


  5. Hey Mohammed.

    So you can't get to the https://FQDN:16993 even when you put the register key in?

    Have you tried on more then one system?

    Page 61 of the Deployment Guide show you how to delegate control of the OU. If the IME ojbects are being created it should be an issue.

    I really can't think of much more with looking at it and troubleshooting it,