I'm interested in getting some feedback on the scenario of someone changing the hostname on the OS of a provisioned AMT device. If this happened, the hostname stored in the AMT firmware would then mismatch the hostname of the operating system. If the hostname of the AMT & OS mismatch, then connectivity to the AMT device would be lost once DNS is updated by the OS.
How do you detect & recover from this situation when using ConfigMgr as the provisioning platform?
I haven't tried that. I will try that out
Does it automatically publish a new AMT client certificate with the new hostname?
You have probably already figured this out. However, since you have been so helpful, I thought I would tell you what I saw in our lab.
I renamed one workstation in our lab. When the new record came into ConfigMgr, the System Resource AMT Status was Null but the AMT Agent information in hardware inventory reported a provision state of 2. I wrote a query that looked for "SMS_G_System_AMT_AGENT.ProvisionState = 2" and "SMS_R_System.ResourceId not in (select SMS_R_SYSTEM.ResourceID from SMS_R_System where SMS_R_System.AMTStatus = "3")". The query did find the renamed workstation.
I only tried this on one workstation and haven't had time to try it in production, but I figured it would help find some of the renamed machines. Now I just need to test the activator command Liesa suggested.
I actually have not had time to figure this out on my own, so thank you for being so kind and posting a response to my question. I think that your method of detecting renamed systems is a great one! Since ConfigMgr seems to store AMT Agent information separately from the ConfigMgr device inventory, and then binds them together with a record somewhere in the database, this is a good way of checking the cross-referenced hostnames to see if they match up.
Thanks for your input