Video Screencast Help

Intel vPro AMT Out of Band Remote Configuration and Delayed Provisioning Best Practices

Created: 18 Apr 2008 • Updated: 16 Apr 2009 | 7 comments
Language Translations
Joel Smith's picture
+2 2 Votes
Login to vote

Remote Configuration is the zero-touch configuration mechanism that allows Intel vPro AMT systems to be setup for AMT management without any manual intervention.

This article covers the Best Practices for setting up Remote Configuration and using the Out of Band Delayed Provisioning Task to remotely and automatically provision systems for use within the Altiris infrastructure.

Introduction

In an ideal environment, vPro systems will automatically Provision without any interaction with the Administrator, allowing the versatile and robust functionality of AMT to be available immediately out of the gate. In this article we'll cover how to setup just such a scenario, but also how to use Out of Band Management's Delayed Provisioning Task to 'kick-start' any AMT system that is no longer sending out configuration requests. Reasons for this need include:

  1. The system is powered on in a location that does not have access to the Provisioning Server
  2. The system is unable to be Provisioned due to changing identities while being setup in its Fully Qualified Domain Name (FQDN)
  3. The IP Address changes during the Provisioning process and the Provision Server is unable to contact it back to Provision

Remote Configuration

Remote Configuration uses a certificate-based authentication model with preloaded certificate hashes to allow quick and automated process to Provision the AMT systems in the environment. The certificates require a vendor-certified cert from Verisign, GoDaddy, Komodo. While you can set your own cert and load your own hashes in the firmware of AMT systems, it turns the ease of Remote Configuration into a cost, whether by having the OEM load the proprietary cert for a fee, or requiring a configuration step to load the hashes manually into the firmware.

Certificates

The firmware will already contain the hashes for Verisign, GoDaddy, and Komodo certificates (more vendors will be added in later versions of AMT). Server-side certificates need to be loaded and registered on the Provision Server, and within Out of Band Management on the Altiris Notification Server. Please see the following article for more information on Remote Configuration: Frequently Asked Questions about Remote Configuration.

For a specific reference for what items are required, review the section labeled: What core items MUST be defined in the provisioning certificate? Also look at the section pointing to how to acquire a certificate (other links): What resources or guidance are available for acquiring one of the core external certificates?

Additional information:

The Provision Server must be registered with DNS, accessible by the Intel AMT device via a CNAME value of 'ProvisionServer' pointing to the IP address of the Notification. Note that in a multi-domain (including root-child domain infrastructures) multiple CNAME entries must be setup to include the suffixes to include all network segments the server will be managing.

The Provision Server requires a certificate with the appropriate OID or OU detailing directions to a certificate Authority (CA), which CA must have a root certificate hash stored on the Intel AMT Systems. The OID must be of the type 'Server Authentication Certificate' with the Intel setup extension: 1.3.6.1.5.5.7.3.1, 2.16.840.1.113741.1.2.3, OR, the OU value in the Subject field must be "Intel(R) Client Setup Certificate".

The Subject CN must be either the fully qualified domain name (FQDN) of the platform running the service (example: Provisionserver.symantec.us), or the domain suffix of the platform (example: *.symantec.us.com or *.symantec.com).

Remote Configuration Process

The following process documents how the Remote Configuration Process works. This high-level overview will be referenced in the subsequent sections covering Delayed Provisioning. The following process assumes that the AMT System can reach the Provision Server and won't change identity through typical setup methods such as imaging or configuration scripts that changes the FQDN and/or Hostname of the system (including adding the system to a Domain).

The following steps must be completed before Remote Configuration will work in the environment. They are detailed with step-by-step processes in the Out of Band Management 6.2 Administrator's Guide, located here: http://www.altiris.com/upload/outofbandrefsep18.pdf

  • Setting up Intel AMT using Remote Configuration - Page 44
    • Certificate provider - Page 44
  • Preparing a Certificate Template - Page 45
  • Issuing a New Template - Page 46
  • Preparing a Certificate Request - Page 47
  • Acquiring a Certificate from an External Certificate Vendor - Page 48
  • Installing the Remote Configuration Certificate - Page 48
  • Loading the Certificate into Intel SCS - Page 49
  • Enabling the Remote Configuration Feature - Page 49

Note that not all the sections need to be accomplished depending on what method you use. If you're creating your own certificate:

  • Preparing a Certificate Template
  • Issuing a New Template
  • Preparing a Certificate Request

...should be used. Otherwise use the 'Acquiring a Certificate from an External Certificate Vendor' section, including the previous links provided on the subject, should be consulted. Remember this is the recommended method since it requires no special processes to be in place to ready the AMT systems for Provisioning.

Delayed Provisioning

The purpose of Delayed Provisioning is to Provision those systems that failed the original Provision attempt. The includes failure at any part of the Remote Configuration/Provisioning process. Failure points include:

  • Hello Packet does not reach the Provision Server during the 24-hour period hello packets are sent
  • The IP Address changes after the Provision Server initially receives the hello packet and hasn't sent down a profile to complete the provisioning process
  • The FQDN changes, forcing an IP Address change from DHCP so when the OS is up, the Provisioning Server can't reach the system
  • The Provision Server is unable to complete the process due to a number of causes, including network access problems, firewalls, subnet locations, etc...

The following items must be in place for Delayed Provisioning to work:

  1. AMT System must be in Setup Mode (pre-provisioned). This means the system must be in the state where it is using Remote Configuration and will use the provided hashes.
  2. The system must have a functioning Windows Operating System.
  3. The Altiris Agent must be installed and functioning within the OS.
  4. The Out of Band Task Agent must be installed within the Altiris Agent.
  5. The Delayed Provisioning Task must be enabled to target the AMT systems in question.

Delayed Provisioning Process

The following process details how Delayed Provisioning works from start to finish. In essence the process 'kick starts' the hello packet process, allowing the Provision Server to receive fresh data on the system, allowing it to properly contact and provision it. The following diagram shows a high-level view of the Delayed Provisioning Process:

Full steps:

  1. The AMT System must be in Remote Configuration setup mode. This is the default mode for AMT 2.2, 2.6, and 3.0.
  2. Install the Altiris Agent on the system. Check the Notification Server reference guide for methods.
  3. In the Altiris Console, go to View > Solution > Out of Band Management > Out of Band Discovery.
  4. Enable the Out of Band Discovery Policy. This will help with the Provision process after the Delayed Provisioning Task executes.
  5. Now go up a level and browse down into Out of Band Task Agent Rollout.
  6. Add the collection: Non-Provisioned Intel® AMT Computers to the Policy by clicking on the Collections listed under 'Applies to Collections' and browsing to it under 'Out of Band Management', 'Provisioning'.
  7. Enable the Out of Band Task Agent Install Policy.
  8. Browse in the Altiris Console under View > Solutions > Out of Band Management > Configuration > Provisioning > Delayed Provisioning > and select the 'Delayed Provision' Task.
  9. Concerning the options:
    • Override OTP: - If you don't want to use a random AMT password, check this option.
    • Switch to AMT: - Unless you're using ASF and want to keep using it on those computers that have it enabled, check this option.
    • Ignore intermediate errors: - Don't check this option unless there's a reason to ignore DNS and OTP errors.
  10. Leave it on a Daily Schedule. Systems that run this and provision will drop out of the collection and not run the policy again.
  11. Enable the Policy.

Once the above steps have been completed, the process should be automated as long as steps 1 and 2 are met. The collections will properly target each system so that the right steps occur in the right order.

Conclusion

The Delayed Provisioning Task allows an administrator to catch those systems that have not provisioned due to a number of reasons. This allows the systems to get provisioned in a targeted fashion, and if properly configured make it completely automated. As of version 6.2 of Out of Band Management, this only applies to provisioning by Remote Configuration. Please check these other articles for details on how to provision systems if not using Remote Configuration: Using Intel's RCT Tool to Restart AMT 'Hello' Packets for Enterprise Provisioning.

Lastly, this process does not touch on certificates used to encrypt AMT management traffic. This is the TLS option set in a Profile for any communication after the AMT system has been properly setup and configured. The certificate obtained for Remote Configuration is only for the Setup and Configuration process (also known as Provisioning).

Comments 7 CommentsJump to latest comment

Terry Cutler's picture

In Joel's article above, the statement is made that the ProvisionServer DNS record must exist. To utilize the Altiris Delayed Provisioning with Out-of-Band Task Agent - this is true.

Some production environments may have multiple Altiris Notification Servers in a single DNS context, or clients that reside in one DNS context yet need to provision to a server in a different DNS context. Another challenge may be that the ProvisionServer DNS entry is not allowed within an environment. These are all exceptions to the rule - and are generally not that common.

At the conclusion to the article above, this is a reference to the Intel RCT Tool - recently renamed to the Intel vPro Activator Utility. For complex environments requiring a method to start and direct hello packets where ProvisionServer or OOBTaskAgent aren't supported\ready - this little utility can be a helpful companion. It works for both Remote Configuration and Pre-shared key provisioning situations.

The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

+2
Login to vote
Terry Cutler's picture

A few additional articles and reference points on remote configuration that may be of interest:

The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

+1
Login to vote
Blaine Baker's picture

Hi Joel and Terry-

It looks as if there may be an error on this page. See the following:

The OID must be of the type 'Server Authentication Certificate' with the Intel setup extension: 1.3.6.1.5.5.7.3.1, 2.16.840.1.113741.1.2.3, OR, the OU value in the Subject field must be "Intel® Client Setup Certificate".

Intel®, not Intel(R). Loadcert.exe is apparently distinguishing between the two and telling me the certificate I purchased does not meet PKI requirements. I am going to try to see if I can get it fixed but I set up Remote Configuration based on the steps in this guide and it's not working. If I am mistaken please let me know, but this typo appears to be breaking the certificate.

Blaine Baker
Information Security Administrator

MySpace, Inc.

+1
Login to vote
Joel Smith's picture

I'll contact Terry and point him at the details of your comment (he's worked with certificate requests a great deal more than me).

Joel Smith
Symantec Services Group (SSE)
Sr. Principal Support Engineer

+2
Login to vote
Terry Cutler's picture

It must be (R) and NOT ®

It’s one of those technicalities. See http://communities.intel.com/docs/DOC-1490  - search for Intel(R)

If the certificate authority customer service is contacted – they will likely honor a reissue of the certificate at no addt'l cost.   

More remote configuration certificate info:

Hope that helps
 

The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

+1
Login to vote
Joel Smith's picture

I believe this typo occurred between the submission of the article and the publication.  LIke all good editors, the editor who published the article changed the representation of the Registered Trademark symbol to the actual symbol.  I apologize we didn't catch this before causing you a headache, UltraMagnus.

Joel Smith
Symantec Services Group (SSE)
Sr. Principal Support Engineer

+2
Login to vote
Terry Cutler's picture

There’s a whitepaper and configuration certificate selection utility at http://www.vproexpert.com/59JHE/RCFG-Cert-Util-Download.html

The whitepaper provides a handy flowchart and addt’l insights on the supported certificates

More information, including link to video which explains the Intel Remote Configuration Utility at http://communities.intel.com/docs/DOC-2734 and video at http://www.vproexpert.com/59JHE/RCFG-CERT-UTIL/RCFG-CERT-UTIL-DEMO/RCFG-CERT-UTIL-DEMO.html 

The VeriSign landing page for vPro certificates is http://www.verisign.com/ssl/intel-vpro-technology/index.html

The opinions expressed on this site are mine alone and do not necessarily reflect the opinions or strategies of Intel Corporation or its worldwide subsidiaries

0
Login to vote