DHCP and DNS registrations with AMT

[SWood7]

I've noticed that our DHCP (Windows 2003) server has started to fill up with leases for system name HPsystem.mydomain.com. I panicked and thought I'd missed a step in my preparation. I have our DHCP configured to register DNS names dynamically but did not have it set to Dynamically update DNS records for clients that do not request updates. I checked that box and now it looks like my clients are starting to get registered correctly. I see registrations happening for HPSystem.mydomain.com as well as the computername.mydomain.com on the same IP. In DNS the comutername is showing registered now. Is this how it's supposed to happen?

Is there a document somewhere that details what happens in DHCP and ultimately in DNS to vPro enabled computers?

[idata]

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.

Dave

[SWood7]

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!

[Matthew_R_Intel]

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?

--Matt Royer

[SWood7]

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?

[Matthew_R_Intel]

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?

--Matt Royer

[JoshHilliker]

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.

Josh H

[SWood7]

Matt,

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!

[idata]

Right click the "Collections" node and choose "Import out of band computers"

[SWood7]

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!

[idata]

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.

Dave

[SWood7]

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!

[SWood7]

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?

[William_Y_Intel]

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.

[Matthew_R_Intel]

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.

--Matt Royer

[SWood7]

It sounds exactly like my issue, plus we're also using HP 7800 systems. Maybe it's something in the HP side of things? I hadn't noticed any problems with users unable to work on their sytems initially, when I first trying to provision in-band, it was when our Help Desk folks called and said they couldn't run the Remote Tools in Config Mgr on many systems. That's when I found the DHCP issue and the leases full of HPsytem.da.ocgov.com. ipconfig /registerdns fixed the DHCP / DNS issue. This just also might be why I'm getting communication failures in my amtopmgr.log when I try to in-band provision. Perhaps the OOB service point can't talk to the machine any more.

[SWood7]

Thanks Matt. I'll stay tuned.

[idata]

I think partly, you're seeing a gap in the two provisioning methods that ConfigMgr provides - in and and out of band. The default behavior of that new HP7800 is to wake up on the network, get a DHCP address, and start sending hello packets. Assuming you had imported the UUID of that machine using the import wizard, as soon as the computer sent out its hello packet to ProvisionServer (your out of band service point), it would get provisioned, and the hostname in AMT would be reset to whatever was specified in the out of band import wizard. Once the initial 24 hour period is over, AMT will stop sending hello packets, and at that point, even if the system was placed on the network, AMT wouldn't be getting a DHCP lease. So, since you have a system that is brand new to the network, and you're expecting to use in-band provisioning, AMT is going to get it's own DHCP lease and register with DNS, and won't change the default hostname until ConfigMgr finishes provisioning.

I'm not sure what the final solution is for systems in this condition, but let's see what Matt's suggestion(s) are.

Dave

[SWood7]

I should have been clearer in my definition of "new" machine in my post. I actually meant "new" in the sense that it had never been provisioned. All our HP 7800's have been attached to our network and in use now for over 5 months now. We've never actually tried to activate / provision them until just a week or so ago. I was waiting to get all the BIOS upgrades down before trying any provisioning. Admittedly, I do remember seeing entries in our DHCP logs over the past months for these machines that have 2 entries - the computername + fqdn as well as hpsystem + fqdn. I always wondered why there were two entries each time a lease was renewed but it never became an issue until now when we saw the computername + fqdn get removed and replaced by hpsystem + fqdn only.

Thanks for the help and thoughts!

[SWood7]

A short update on my provisioning progress....this morning I located a machine and changed the password in AMT. I then added that password to the SCCM provisioning accounts in SCCM. I put the system into a AMT policy-enabled collection and it came back with

>>>>>>>>>>>>>>>Provision task begin<<<<<<<<<<<<<<<

Provision target is indicated with SMS resource id. (MachineId = 2680 10th_85357.da.ocgov.com)

Found valid basic machine property for machine id = 2680.

Warning: Currently we don't support mutual auth. Change to TLS server auth mode.

The provision mode for device 10th_85357.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_85357.da.ocgov.com...

Fail to connect and get core version of machine 10th_85357.da.ocgov.com using provisioning account # 0.

Try to use default factory account to connect target machine 10th_85357.da.ocgov.com...

Fail to connect and get core version of machine 10th_85357.da.ocgov.com using default factory account.

Try to use provisioned account (random generated password) to connect target machine 10th_85357.da.ocgov.com...

Fail to connect and get core version of machine 10th_85357.da.ocgov.com using provisioned account (random generated password).

Error: Device internal error. Check Schannel, provision certificate, network configuration, device. (MachineId = 2680)

Error: Can NOT establish connection with target device. (MachineId = 2680)

>>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<<

Same as before but this time I didn't have the DHCP / DNS issue. The machine had a static ip and did not have to communicate with DHCP. Name resolution was good throughout the provisioning attempt. I'm not sure what this tells me but it may say that the connection issues and DHCP may not be the cause of my provisioning failures.

[Matthew_R_Intel]

Sandy,

In terms of the DHCP / DNS scenario you saw. The root of what's happening is that by default, HP puts HPSystem as the default ME hostname when the client is in an unprovisioned state. When the vPro Client loads, the Management Engine (ME) is the first thing to come up (happens shortly after post). When the ME loads, it will request an IP address and will register the IP address in DNS. Since HP has "HPSystem" as the default hostname in an unprovisioned state, ME will register the HPSystem in DNS with the associated IP address. When the vPro Client boots up the Operating systems, the OS will grab the same IP address the ME picked up and will register it's hostname in DNS (essentially overwriting the HPSystem DNS registration with the OS hostname). During SCCM (our any other ISV for that matter) provisioning process, SCCM will set the ME hostname to what was either A) Enter in the Out Of Band Import Wizard or B) Pulled from the SCCM Client Agent during agent based initiation. Once provisioned, the ME hostname will match the Operating System and any DNS update (from the OS or ME) will update to the same record.

Although I have not been able to reproduce it consistently, it appears that the initiation of the provisioning process sometimes initiates the ME send a DNS update request. With the ME hostname still being HPSystem, it overwrote the DNS record the OS registered. If you were to do an ipconfig /renew on the OS or reboot the computer, the OS Hostname should be re-stamped back in DNS. This does not appear to be an issue with other OEMs that leave the ME hostname blank in an unprovisioned state.

Once the provisioning process is complete and the ME hostname is synched with OS, you should not see this problem anymore.

--Matt Royer