Partager via

Out of Band Management Requirements for In-Band AMT Provisioning and DHCP

  • Article

The out of band management prerequisites for Configuration Manager 2007 SP1 listed DHCP as an external dependency for out of band (bare metal) provisioning only. It has since come to our attention through the TechNet forums that in-band might also have this requirement for option 15, the Domain name. However, it’s possible that even if you configure DHCP correctly, in-band provisioning might initially fail because of native AMT behavior. This post explains this scenario and possible solutions. When our testing is complete, we will update the out of band management documentation accordingly.

For AMT provisioning to succeed, there is a security check for the DNS suffix in AMT - the DNS suffix used in the AMT provisioning certificate is checked against the DNS suffix specified in AMT. For AMT 3.2.1 and above, only the last two domain names are checked and not the complete DNS suffix. For example, if the DNS suffix in AMT was sales.contoso.com and the DNS suffix in the AMT provisioning certificate was marketing.contoso.com – then there is a positive match for AMT-based computers running version 3.2.1. Effectively, they just need to share the namespace. However, if the DNS suffix in AMT was sales.contoso.com and the DNS suffix in the AMT provisioning certificate was marketing. northwindtraders .com, or the DNS suffix value was blank in AMT – then the DNS suffix match would fail and provisioning cannot succeed.

This namespace matching is explained in the documentation – see About Certificates for Out of Band Managementand the section “Certificate Subject Name Requirements”. However, earlier versions of AMT might have more stringent name matching requirements where the complete DNS suffix is checked. Configuration Manager does not natively support versions of AMT prior to 3.2.1 and these computers must be provisioned in conjunction with Intel’s AMT translator. Check the Intel site for more information about the DNS suffix requirements for specific AMT versions, and the translator.

You can manually check and specify the DNS suffix in AMT by configuring the MEBx, but obviously this method is not efficient for multiple computers – which is where DHCP comes in. If DHCP is configured with the DNS domain name, and the AMT interface is open, then the DNS suffix is automatically configured in both the client operating system (if running) and AMT. The AMT interface is open within the first 24 hours of the computer being on the network when it comes from the manufacturer, and during provisioning. If DHCP is configured with the correct namespace within the first 24 hours of the computer coming onto the network, and the computer retrieves these settings from DHCP, the DNS suffix in AMT will automatically be configured and provisioning will succeed.

However, unlike new computers (bare metal with no operating system installed), there is a potential timing problem with configuring existing computers with the DNS suffix in AMT. If the AMT interface has closed (the 24 hour window has expired), then the DNS suffix cannot update in AMT, even though it successfully updates the client operating system. This means that AMT provisioning will fail when the DNS suffix match fails. Each AMT provisioning attempt re-opens the AMT interface for another 24 hours, so if you run ipconfig /renew on the client computer after provisioning fails and within the 24 hours, the DNS suffix will update in AMT and the next AMT provisioning attempt will then succeed.

If AMT in-band provisioning fails, it automatically tries again after 24 hours. So in this situation, after renewing the IP address with DHCP to retrieve the DNS name, provisioning will succeed the following day. Rather than running ipconfig /renew individually on each AMT-based computer, you could send out an advertisement with a script to do this – but ensure that it runs after provisioning has failed (when the AMT interface is open). Alternatively, you could just wait and eventually AMT provisioning will succeed because the client operating system automatically renews its IP address and then the next AMT provisioning attempt will succeed. However, depending on your IP lease times, this might mean that provisioning fails over a number of days. If you know that you are in this situation, plan in advance and configure a very short lease time for these computers so that they will automatically pick up the new DNS domain more quickly after the initial provisioning failure.  

Update January 6th 2009:

The originally published post incorrectly stated that the client retries in-band provisioning every time it downloads its computer client policy. The computer retries in-band provisioning every 24 hours independently from downloading its client computer policy. A shorter client policy cycle will therefore have no effect on how quickly the AMT-based computer tries to provision again if it failed previously. The 24 hour retry setting is not configurable in the Configuration Manager console or in the SDK. 

The same potential issue can occur with migrations to Configuration Manager from another AMT management solution. If possible, check and set the AMT DNS suffix in the computers to be migrated before you begin the migration process to Configuration Manager. Check with your management solution or Intel if you think that this might be a problem. You might have to run the migration process twice – the first time will fail for any AMT-based computers with a different DNS suffix, then update the computers with the correct DNS suffix within 24 hours, and then run the migration process again.

Unfortunately, Configuration Manager cannot discover the DNS suffix in AMT prior to successful provisioning, and there are no distinctive errors in the log files to help identify the root cause of provisioning failing because of this naming mismatch. We are looking into whether we can add more helpful error logging for in-band provisioning where we know the DNS suffix of the client operating system even if we do not know the DNS suffix in AMT. When provisioning succeeds, Configuration Manager updates the DNS host name and suffix in AMT with the FQDN registered for the client record – but this is possible only after provisioning succeeds.

In summary:

· AMT requires a DNS suffix be assigned in advance of provisioning, and this suffix must match the DNS suffix in the AMT provisioning certificate. Normally, this suffix would be assigned via DHCP during the first 24 hours that the computer is on the network. If for any reason DHCP is not functional during this period, or was configured with a DNS suffix that is different from the one that will be used during provisioning, then the DHCP suffix must be corrected before provisioning will succeed.

· If computers do not have the correct DNS suffix in AMT, correct it by using one of the following methods:

  • Manually specify the DNS suffix on each computer by configuring it in the MEBx, though obviously this approach isn’t practical for a large number of computers. The next provisioning attempt (next client policy download or migration attempt) will then succeed and there is no 24 hour time limit.
  • After provisioning has failed and the AMT network interface is open, ensure that DHCP is configured for the correct suffix, and then force these computers to renew their DHCP lease by running “ipconfig /renew” in the client operating system. If these computers are running the SMS 2003 client or the Configuration Manager client, this command can be sent by using an advertisement with this command. The next AMT provisioning attempt will then succeed.
  • For in-band provisioning, ensure that DHCP is configured for the correct suffix, and wait until the computer automatically renews its lease within 24 hours of provisioning failing. The length of time to wait depends on the lease length configured in DHCP, but could be several days.

 

If you would like to send feedback about this DHCP requirement for in-band provisioning, email SMSDocs@Microsoft.com.

 

- Carol

This posting is provided AS IS with no warranties and confers no rights.

Comments