This is not the specific answer you're looking for, but remember that ConfigMgr will update the hostname (and hence FQDN) in AMT with the same hostname as the host operating system when you're using in-band provisioning. If you're using out of band provisioning (via the import wizard) then the hostname will be set to the hostname specified in the import wizard.
In general, this behavior looks right, though.
I made a few changes to my DHCP server since my post and maybe it will have an impact on things. I made sure I enabled the "Dynamically update DNS A records for DHCP clients that do not request updates" option. I had already been dynamically updating my clients in DNS but thought this may have contributed to the problem. I did some testing where I ran ipconfig /registerdns on the sysytem IPs that were showing as HPsystem.mydomain.com in DHCP and shortly thereafter, they showed the correct FQDN name in DHCP and were now registered in DNS with the FQDN. I supposed I should have checked my dynamic registration settings before I started provisioning!
So what is occurring is that AMT Management Engine (ME) is registering it's hostname in DNS; in your case the factory default host name of the HP client is HPSystem. Once the device is provisioned, depending on what ISV you are using, the Hostname and domain name will be changed (usually to match the OS). So if the Hostname matches the OS after it has been provisioned, on boot up the ME will register the hostname in DNS first and then once the OS full loads, it should overwrite the same DNS entry. The ME does this so that in a scenario where the OS is not available, the ISV console can still look up the IP address of the AMT client in DNS and connect to it.
Now is the IP address being registered with first HPSystem on first boot up and then when the OS is loaded changes to the FQDN of the OS? Or are you seeing a separate hostname HPSystem and your OS hostname registered with the same IP address? I'm assuming the AMT client is currently in an unprovisioned state?
It looks like most of the sytems are "activated", at least from the Config Mgr client logs. I'm not sure if that's "provisioned" yet though. I unchecked the collection properties to enable the AMT policy after I saw what was happening in DHCP and it's been off ever since. I found if I ipconfig /registerdns on those clients, they register correctly in DHCP and DNS. I'm kind of afraid to turn the AMT policy back on again until I get my head around what happened.
In addition , I only have the "Discover Management Controllers" option on my ConfigMgr console - no power options yet. Will they arrive after some time?
Discover Management Controllers only checks to see if the client is AMT capable; you will need to provision it through either the Out of Band Import Wizard or through policy with the SCCM SP1 Client Agent. Right click on your collection title/header and select View->Add/Remove Columns; add the AMT Status and AMT Version Columns. After you do the discovery, the client AMT Status will either come back as "Not Support", "Detected", "Not Provisioned", or Provision. My assumption is if your configuration is correct and you have not initiated one of the provisioning options, it will come back as "Not Provisioned". Make sure you update your collection membership after you perform the discovery.
What does your AMT Status say?
great question Matt.
Sandy - I just finished the wizard add of machines recently. Matt has a few posts that I will go find & post here, they work like a charm.
Thanks for the help in adding the AMT columns to my collections. I created a collection based on a query of systems with the latest HP BIOS and 3.2.1 AMT BIOS. Yesterday I enabled automatic oob provisioning for that collection. Within an hour I noticed some DHCP / DNS naming and registration issues that caused me to un-check the box for that collection. I'm sure that doing this may have stopped the provisioning process halfway becuase the AMT Status for most systems in this collection is Unknown. However, 4 systems are listed as Not Supported. I'm going to be a bit more conservative from now on and start small to test my provisioning, perhaps with a collection of 3-4 sytems to see if I can monitor the flow and client / server logs. I've also got to locate that OOB Management Wizard!
Thanks again for the help, support and tips!
Right click the "Collections" node and choose "Import out of band computers"
Thanks for the tip and the help. I noticed I don't have that option for any of my collections and it must be because I've not installed it! I'll get the CD out and check it. Thanks again!
It's only available for the root "Collections" node itself. None of the child nodes (all systems, All Windows XP systems, etc) will have it.
No need to reinstall or grab the original CD. It's there, but only on the root level "Collections" node itself.
Ahhh, OK I see. I don't think I want to go this way - I've got 800 systems and I want to be able to do in-band provisioning with my SCCM SP1 clients instead. I'm just lazy. I'm going to setup a test collection and enable the oob policy on it and see how it goes on a few machines before I turn it on widespread. Yesterday I had some DHCP / DNS issues that caused quite a bit of grief so I'm going to limit my provisioning to a few at a time until I know what I'm doing.
Thanks again for the Config Mgr help!
Well, I've tried provisioning a single system, in SCCM SP1, and have discovered my DHCP / DNS woes have returned. Maybe you can help shed some light on my problem.
First off, my DHCP servers are configured to dynamically register all systems in DNS. I've configured all the required DHCP scope options 006 and 015, and DNS has a provisionserver entry.
I put a single, new HP 7800 system into a new test collection in SCCM and forced it to Discover Management Controllers. A few seconds later, in the client oobmgmt.log, I see a "Successfully activated the device" entry.
On the server-side, in the amtopmgr.log, I see this
>>>>>>>>>>>>>>>Provision task begin<<<<<<<<<<<<<<<
Provision target is indicated with SMS resource id. (MachineId = 2093 10TH_85242.da.ocgov.com)
Found valid basic machine property for machine id = 2093.
Warning: Currently we don't support mutual auth. Change to TLS server auth mode.
The provision mode for device 10TH_85242.da.ocgov.com is 1.
Attempting to establish connection with target device using SOAP.
Found matched certificate hash in current memory of provisioning certificate
Create provisionHelper with (Hash: C2512FF7A3A558C88896C7EE51F152B15965C468)
Set credential on provisionHelper...
Try to use provisioning account to connect target machine 10TH_85242.da.ocgov.com...
Fail to connect and get core version of machine 10TH_85242.da.ocgov.com using provisioning account #0.
Try to use default factory account to connect target machine 10TH_85242.da.ocgov.com...
Fail to connect and get core version of machine 10TH_85242.da.ocgov.com using default factory account.
Try to use provisioned account (random generated password) to connect target machine 10TH_85242.da.ocgov.com...
Fail to connect and get core version of machine 10TH_85242.da.ocgov.com using provisioned account (random generated password).
Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 2093)
Error: Can NOT establish connection with target device. (MachineId = 2093)
>>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<<
This is a new system, never had the ME BIOs accessed. I did check my ConfigMgr Provisioning Accounts and I've not entered anything there because I assumed that they came from HP with blank admin passwords.
The next thing I did was check the DHCP mmc and noticed that the entry for machine 10TH_85242 is listed as HPSystem.da.ocgov.com. Now I can't communicate with the system except by ip number. I can remotely run ipconfig /registerdns and the machine successfully updates it's name in DHCP and DNS and we're back to communicating again.
I can't seem to figure out what is causing the DHCP issue to happen. This is definitly a show-stopper for us if this happens every time. Can anyone see some errors in my ways here?
Sandy, I experienced a very similar issue in my lab testing. What I found was even more strange for the fact that SCCM was able to provision the HP7800 (2 different systems) using inband provisioning. Everything went off just as expected...OU created, Certificate generated, profiles passdown, etc. And they showed up in SCCM as provisioned (3.2.1). But when I went to use the OOB console, it failed to connect. So I started looking into my issue and found that both of these systems were still registered in DNS and DHCP as HPSystem.fqdn. That was the reason I couldn't connect with the OOB console. However, I could still use the webUI as long as I used https://hpsystem.vprodemo.com:16993 (and accept that the certificate did not match for the site I was accessing). Then I could login to AMT. So I went to both systems and did the same ipconfig /registerdns and updated records for both. I have not been able to reproduce but I told Matt about it. Not sure if we have an issue or an Infrastrucutre related problem. But glad you validated another scemario where this AMT name is causing issues.
So the factory default HPSystem ME hostname on the HP 7800 may be the root of your issue. Once provisioned within SCCM, the ME host name will be updated to the to that of the OS; so even when the ME does a dynamic DNS update, it will be updated to the same hostname as the OS. We are investigating this one further, will let you know what we find.