Some customers might have an environment where there is a network domain that is different to their Active Directory domain. This typically arises when there is a Microsoft Active Directory structure, yet there is a legacy non Microsoft DHCP and DNS infrastructure that uses a different (network) domain. This can cause a bit of an issue for vPro management if you are integrating with Active Directory (and also if you are using certificates for encrypting communication.) The reason for this is that typically a machine will be provisioned with the AD FQDN as all provisioning methods which rely on the Activator Utility or a management console's client agent will query locally using WMI and will pick up the FQDN that resides at the OS level. This will be OK for provisioning and will not be flagged as an issue. However, when the machine will be accessed for OOB management , the Kerberos protocol that dictates how the AD Objects for your provisioned vPro machines is accessed, will prevent access. This is because when the AD Object is interogated it will get a request from the management console that relies on a DNS resolution. That resolution will provide a different FQDN than the AD OS FQDN.

 

In the past, the paradigm has been to circumvent this situation for the purposes of vPro provisioning and management by using hostname only provisioning, assuming that the hostname was unique. This was possible as long as you were using SCS 3.x. If you are using SCS 5.0 and above this approach will no longer work. Even though my direct personal experience on this matter has been directly with SCS and SMS I see no reason why this won't also apply to Microsoft SCCM or Altiris with its underlying SCS (when is supports SCS 5.x).

 

 

The Solution: you will need to provision your vPro machines with the network resolvable FQDN. The manner that we have implemented it is by having a server script that performs an nslookup dynamically and plugs that into the SCS DB instead of the AD FQDN as part of the provisioning flow. The other thing that caught us out for a while, is that we had to add the network domain into the Server TCP/IP advanced network settings as a secondary domain suffix. As you will most probably have a new Server setup for hosting SCS then this configuration step most probably hasn't been performed for you and therefore you will need to remember to do it!

 

 

Hopefully this helps prevent some headaches for some of you...

 

 

Tal