Best Practice for Handling FQDN Mismatch when AMT FQDN Resolves to different UUID

[JNola3]

Hello,

We are seeing an issue with the unique situation described in the title, summarized as follows -

This works fine as expected:

1. AMT provisioned system is renamed (old name = PC-ID01, new name = PC-ID02)
2. SCS Fix FQDN job or ACUConfig MaintainViaRCSOnly command is run to resolve FQDN mismatch issues
3. When the AMT FQDN (PC-ID01.domain.com) is not resolve-able in DNS, RCS connects using the IP
4. WS-Management commands perform maintenance and system is good to go

This does not work as expected:

1. I have two AMT provisioned systems: PC-ID01 and PC-ID02. They were incorrectly named due to physical location, but only off by the numbering so they are renamed as follows: PC-ID01 is renamed to PC-ID02 and PC-ID02 is renamed to PC-ID03.
2. SCS Fix FQDN job or ACUConfig MaintainViaRCSOnly command is run to resolve FQDN mismatch issues (in this case, this is run on the system with Host FQDN = PC-ID03.domain.com and AMT FQDN = PC-ID02.domain.com
3. AMT FQDN for this system resolves to a the other computer, with a different UUID (I can see the RCS log showing this is detected)
4. RCS appears to try and connect via IP but fails some portion of the process and cannot complete the maintenance (final error says the provided UUID does not match the UUID of the system)

It appears if the old AMT FQDN resolves to a different system, than the RCS cannot manage the system remotely at all (fails to get password as well with same error).

I have found that if I manually edit the hosts file to force DNS resolution of the old AMT FQDN to the correct system, everything works fine.

Is there any recommended way to handle this scenario outside of manual edits to the hosts file? We are a large heterogenous organization and it is difficult for me to mandate what happens when systems are renamed in another unit, but I need to ensure AMT remains healthy on our fleet. Has anyone encountered this situation and found a method of resolving this within the SCS?

This document seems to indicate that the SCS software used to use a similar trick to resolve this problem, but perhaps this approach is no longer in the software?

http://www.intel.com/content/dam/www/public/us/en/documents/best-practices/configuration-tips-for-managing-mobile-pcs-with-vpro.pdf http://www.intel.com/content/dam/www/public/us/en/documents/best-practices/configuration-tips-for-managing-mobile-pcs-wi…