If you're reading this blog posting, hopefully you've read my blog post on CIRA last week -
Firstly, I wanted to share with you that over the past week we have actually worked through an entire end to end setup with a real-world customer (i.e. not just inside Intel labs) and now we have CIRA and AMT functionality over CIRA working successfully!
If you're wondering which of the management consoles and MPS/vPro Gateways were used - it was LANDesk 8.8 SP3 in this case (remember that LANDesk bundle their own MPS/vPro Gateway offering). If you're looking to get this to work in your environment (CIRA with LANDesk specifically) please do get in touch and I can share some specific current LANDesk pointers with you (that are not mentioned in this blog posting).
Some of the things we came across last week which are good pointers to pay attention to:
- There are 4 ports that get configured with the MPS which are fully configurable (i.e. they are not restricted to being a specific port number) - however, you cannot re-use the same port number, you need to have 4 distinct port numbers (sounds trivial, but it happens).
- You can use port 16993 as one of the port numbers, even though that is the port that is used for https connections in AMT (there is no conflict)
- In the httpd.conf file - instead of havinga deny all and allow specific IP addresses, you might want to change to allow all
- CIRA relies on the DHCP option 15 that is allocated where the vPro client is to be different than what it was pre-configured with - that is how the system knows it is outside the corporate environment. If DHCP option 15 happens to be blank where your vPro clients connect from - that is good enough. Blank is considered different and CIRA works fine.
- Currently, you should install the LANDesk agent after provisioning is completed
- Check through selecting the 'vPro Status' operation on a provisioned vPro client to ensure all the LANDesk NED settings have been deposited properly on the vPro client prior to taking it out of the corporate environment.
Btw, the CIRA connection is established through a user click at the OS-level using the IMSS utility.
So the bottom line is we now have close to 100 systems that are confirmed to be have full AMT functionality working over a CIRA connection in a real live environment - it works! (
The 2nd part of the blog can be considered a more 'advanced topic' and is devoted to what happens if your management console of choice doesn't currently support CIRA...
One Management Console for example that is currently not supporting CIRA is Microsoft SCCM (even with SP2).
The options as I see them, are:
- Contact your software vendor and ask them whether they support Intel - Intel works with multiple software vendors on incorporating support for various Intel vPro features (CIRA amongst others) - they can hear it from us, but it is much better if they hear it from you.
- Your software vendor might have plans to introduce support for CIRA, however it is further down the line - so it is just a question of time.
- Try and engineer something yourself to have CIRA work in the environment you have setup
At least for testing your environment for what CIRA would look like, you could leverage the WebUI tool. You would need to have an MPS installed and configured first of all. Thereafter, all that you need to do is configure the proxy settings in the web-browser you are using to the IP address/FQDN of where you have your MPS installed and also enter the default http proxy port of 8080 - that will be sufficient for getting your WebUI to work over a CIRA connection.
If you use Microsoft Internet Explorer you are limited only to the http proxy portion which will allow several of the AMT operations to work over a CIRA connection, but not SOL/IDER for example.
If you are using Mozilla Fire Fox for example, you can configure a SOCKS proxy as well, which can handle routing SOL/IDER traffic as well.
If we take the example of Microsoft SCCM, what you can do is to use the scripting framework that has been used successfully for something like: providing out of band 802.1x in Microsoft SCCM SP1 (it is natively supported now in SP2) -
You can configure the correct settings for the vPro client to be able to contact the MPS Proxy Server and establish a CIRA connection between the MPS Server and the vPro client, however you will still need your management console to integrate and be aware of this CIRA connection to be able to do something useful.
What you could do at this point is to configure a 'transparent proxy' - what that would typically entail is to configure the MPS IP address/FQDN as a proxy routing that will be inserted in the headers of packets that go through the router to which the Server that is hosting the management software. You can use something like Cisco WCCP (Web Cache Control Protocol) to set this up. At this point, Microsoft SCCM will not be aware that the packets it is sending are actually being re-routed through the MPS to the vPro clients (which is aware of the remote vPro client) and that is why this is called a transparent proxy.
A caveat/disclaimer I would add though is that albeit technically feasible you would need to put together the full working solution yourselves and support it yourselves.
