Intel,Altiris Group

Remote Configuration is the zero-touch configuration mechanism that allows Intel vPro AMT systems to be setup for vPro management without any manual intervention. This article covers the Best Practices for using Remote Configuration with an emphasis on using the Out of Band 7.0 Delayed Configuration Task to remotely and automatically provision systems for use within the Altiris infrastructure. This article will be used in tandem with other Configuration articles currently released.

Introduction

In an ideal environment, vPro systems will automatically be setup and configured without any interaction with the Administrator or IT staff, allowing the versatile and robust functionality of vPro to be available immediately, whether on new systems just connected to the network to those systems already out in the environment. In this article we'll cover how to setup just such a scenario, but also how to use Out of Band Management's Delayed Configuration 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 Configuration Server (Notification Server or an associated Site Server)
2. The system is unable to be Provisioned due to changing identities while being setup, including computer name changes, IP Address lease changes, and other items that change the Fully Qualified Domain Name (FQDN)
3. The IP Address changes during the Configuration process and the Configuration Server is unable to contact it to Setup and Configure it

Remote Configuration

Remote Configuration uses a certificate-based authentication model for vPro system with preloaded certificate hashes to allow quick and automated process to Configure the vPro systems in the environment. The certificates usually require a vendor-certified cert from Verisign, GoDaddy, Komodo, and others. 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.

Several articles cover aspects of Remote Configuration. These are referenced in the following subsections on this topic.

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

NOTE: This article was written around Out of Band Management 7.0. The below items I've highlighted in the article will also contain clarifications below updating the data into the 7.0 framework.

For a specific reference for what items are required, review the section labeled:
What core items MUST be defined in the provisioning certificate?
These items are consistent between the 6.x and the 7.x platforms.

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

First, a successful application of the certificate for Remote Configuration needs to occur. Please see the following article for details on how to do this: Remote Configuration Certificate Best Practices in Out of Band Management 7 for Intel vPro Systems

Note that the steps in the article cover the full process to implement a Remote Configuration certificate. This is required to not only have a backup of the certificate in case something goes wrong, but also covers all points of how to apply the certificate correctly. Due to the issues we've seen where the certificate handshake fails, simply applying the certificate without reading through the details may result in a PKI handshake failure.

Please note the following points:

• If you plan to generate your own certificate, I recommend sticking with the PID PPS method (TLS-PSK). For Remote Configuration to work with a self-generated certificate, the hashes have to be manually or somehow programmatically entered into the Intel ME on the target machines. This takes away the zero-touch aspect of Remote Configuration.
• Make certain your server is up and fully running with a solid identity before requesting the certificate. If the server is in a testing environment and you have the intent of promoting it to production later, note that identity changes invalidate the certificate and will require the certificate to be requested again.
• Once applied, that's it! Systems coming from the manufacturer are already setup to send out Remote Configuration 'hello' requests.
• AMT enabled systems will only send hello requests for 24 hours, so if the system is unable to reach the Notification or SCS Server within that time, it will not send out any more requests. That's where Delayed Configuration comes in, covered in the next section.

Delayed Configuration

The purpose of Delayed Configuration is to configure those systems that failed the original Configuration attempt as AMT systems only try for 24 hours. This includes failure at any part of the Remote Configuration process. Failure points include:

• Hello Packet does not reach the Configuration Server (Notification Server or SCS Server) during the 24-hour period hello packets are sent
• The IP Address changes after the Configuration Server initially receives the hello packet and hasn't sent down a profile to complete the Configuration process
• The FQDN changes, forcing an IP Address change from DHCP so when the OS is up, the Configuration Server can't reach the system
• The Configuration 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 Configuration 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. The default state with all applicable manufacturers is in this mode.
2. The system must have a functioning Windows Operating System. This is due to the way Symantec insures proper identity within Windows.
3. The Altiris Agent must be installed and functioning within the OS to provide identity information to the Configuration Server and conduct the actual Delayed Configuration process.
4. The Out of Band Task Agent must be installed within the Altiris Agent to run the Delayed Configuration Task.
5. The Delayed Configuration Task must be enabled to target the AMT systems that are capable but not yet configured.

Delayed Configuration Process

The following process details how Delayed Configuration works from start to finish. In essence the process 'kick starts' the hello packet process, allowing the Configuration Server to receive fresh data on the system, allowing Intel SCS to properly contact and configure it. The following diagram shows a high-level view of the Delayed Configuration 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, 3.x, 4.x, 5.x.
2. Install the Altiris Agent on the system. Check the Notification Server reference guide for methods.
3. In the Symantec Management Console, go to Home > Remote Management > Out of Band Management > and browse through Out of Band Agent Install > Out of Band Discovery.
4. Enable the Out of Band Discovery Policy if it is not. This will help with the Configuration process after the Delayed Configuration Task executes.
5. Now select Out of Band Task Agent - Install from the same location.
6. The default collection normally should be sufficient to rollout the Task to all applicable agents. If there are issues having the right systems in the provided collection labeled: ASF or Intel(R) AMT Capable Computers without Altiris Out of Band Agent Installed, use these steps to correct:
   1. Under the Applied to section, click Apply to > Computers.
   2. Click the Add Rule button.
   3. Next to the THEN field, choose exclude computers not in from the dropdown.
   4. Leave the next dropdown on Filter.
   5. Type Intel into the last field and click the dropdown.
   6. Choose Intel(R) AMT Capable Computers. See this screenshot for an example:

      

   7. Click OK to apply the Target.
7. Enable the Out of Band Task Agent - Install Policy by clicking on the On/Off dropdown and choosing On.
8. Click Save changes to save the policy. See this screenshot for an example of the policy:

   

9. Browse in the Symantec Management Console under Home > Remote Management > Out of Band Management, and browse under Configuration > Intel(R) AMT Systems > and select Delayed Setup and Configuration.
10. Concerning the options:
    1. DNS suffix: - This can help properly identify the machines if the DNS suffix for your environment is provided.
    2. Override OTP: - If you don't want to use a random AMT password, check this option.
    3. Switch to AMT: - Unless you're using ASF and want to keep using it on those computers that have it enabled, check this option.
    4. Ignore intermediate errors: - Don't check this option unless there's a reason to ignore DNS and OTP errors.
11. Set a schedule using the following steps:
    1. Under the Client scheduling section, click the Add schedule button and select Scheduled time.
    2. Set the Start time to an optimal time when machines are up but generally idle in your environment. However this process will not impact users if done during production hours.
    3. Click the No repeat hypertext (blue).
    4. From the dropdown, select Repeat every: Day. Since we will be using a dynamic collection machines that have used Delayed Configuration successfully will automatically drop out of the collection. Otherwise they'll retry daily.
12. Next, set a filter of computers for the task to run on, following these steps:
    1. Under the Applied to section, click the Applied to button and select Computers.
    2. Click the Add Rule button.
    3. Next to the THEN field, choose exclude computers not in from the dropdown.
    4. Leave the next dropdown on Filter.
    5. Type Intel and click the dropdown. Select Intel(R) AMT Computers in Delayed Configuration State.
    6. Click OK to set the Target.
13. Enable the Policy. See this screenshot for an example of a configured policy:

    

Once the above steps have been completed, the process should be automated as long as steps 1 and 2 are met. Since the system comes in a Remote Configuration state, the only actionable step once everything is setup is to install the Altiris Agent, which can also be automated (see the Notification Server reference guide for ways to install the Altiris Agent).

Conclusion

The Delayed Configuration Task allows an administrator to catch those systems that have not been configured for whatever reason. This allows the systems to get provisioned in a targeted fashion, and if properly configured make it completely automated.

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 (formerly known as Provisioning).