Some of you might find that you need to provision your vPro systems with hostname only as opposed to the generally recommended and accepted fully qualified domain name - FQDN. The typical reason for using hostname only would be because the FQDN that appears at the OS level of a client will not match what will appear in the DNS forward and reverse lookup zones.
You might ask - how can that be? An example from one of my customers is that they have a network domain that is appended to entries in DNS via DHCP option 15. However, their DNS/DHCP is not integrated with their Active Directory and a different AD domain exists. Therefore when using the activator tool to extract the FQDN of the system and write it into the SCS DB as part of the provisioning process, it will conflict with the FQDN that appears in DNS. This will not cause a problem for provisioning per se, but for trying to access the machine later on using a management tool/interface it probably will.
Note: if you are using TLS certificates (server or mutual authentication) then hostname only provisioning will probably not be a viable option for you in any case because of the scrutiny of certificate exchanges that check whether domain suffices match.
So what does all this have to do with SCS 5.0? In 3.x versions of SCS there wasn't anything special you needed to do to allow hostname only provisioning, but with SCS 5.0 there is. When you construct your provisioning profile, in the optional settings you will need to select domains and make sure you select the checkbox of ‘Allow configuration when platform has no domain name'.
What if you are doing AD Integration?
If you are opting for AD Integration (as many will), you will have a problem with SCS 5.0. The reason for this is that the Kerberos protocol will insist that the request ticket will rely on DNS for your FQDN entry, whereas your object within the AMT OU in Active Directory will have a service principle name field (SPN) that will not match that FQDN - the SPN will have hostname and the request ticket will be whatever it is in DNS and at that point the kerberos negotiation will fail. It is important to stress that provisioning will work fine and you will see no hint to these issues, however once you try and access the machines via WebUI or any management console, you will have a problem.
The fix for (for now) will be to edit the SPN field for each provisioned machine's object in AD to what will appear in DNS. The SPN field has an entry for each port number that could potentially be used for AMT purposes (16992,16993,16994,16995,623,664) but if you are not using SOL/IDER and are not using certificates (you won't if you've opted for hostname only in any case) then the only field you should need to change is for the 16992 port. You can edit this field manually using ADSIedit. A more scalable solution will require a script to run as a post provisioning step to edit the SPN. A solution within SCS 5.0 is not available at present.
Ta
