As many of you might know or have experienced, relying fully on the default provisioning window where the Management Engine sends 'Hello Packets' to the SCS server is problematic. Problems start arising in the following instances:
- The network has multiple domain suffices being allocated as connection specific DNS suffices depending on location and this could potentially lead to a mismatch between the SCS domain suffix and the client domain suffix.
- DHCP option 15 upon which the default process relies on might need be in use for one reason or another
- The provisioning window (24 hours for RCFG and 6 hours for PID/PPS by default) has closed before the infrastructure has been put in place to do something useful with these hello messages.
In the past there was a solution based on sample vbscripts provided by Intel- either Server side only or a combination of client and server side scripts that would be used in conjunction with SCS. This has now evolved to the Activator Utility which is considered the best known method, however there are some subtleties where using the Activator isn't as straight forward, such as:
- The Activator utility will typically run under the context of the Local System Account - to allow each Local System Account to write information to the SCS DB requires delegating control all the Computer Objects. This is seen as a significant security risk by some organisations.
- The syntax for running the Activator utility necessitates the specification of a profile ID. The number of the profile ID can't be pre-determined with absolute certainty and the SCS API only accept the profile ID and not the profile name. A situation can ensue that the wrong profile ID has been hardcoded on the clients.
- Some operations like /a cannot work under the Local System Account context to begin with
Together with the hetrogeneous states of vPro machines (some provisioned, some not, some needing to be re-provisioned) some further logic needs to be put in place to provide a robust end to end solution. This has lead to the implementation (in a nutshell) of the following solution at a large scale enterprise customer (it assumes knowledge of the activator utility and it's switches):
- A scriptable interface needs to be able to determine whether a system is provisioned or not - this is achieved by running MEInfo and parsing the contents of the output and writing some information into registry keys.
- A script always checks the registry keys to know whether to run the Activator utility
- The script is run at every boot-up of the system to make sure any previous failed attempts or if the system has been unprovisioned since the last boot is covered
- Once a script (which runs under the context of the Local System Account) determines it needs to execute - i.e. the machine is unprovisioned but has PID/PPS loaded it runs the Activator Utility with the //s h /d PID but not /o and /p
- At this point you might ask yourself, if I am using the client side vbscript, why should I use the Activator tool as well? The answer is that the Activator tool provides you the ability to send an in-band 'hello message' to kick-off the provisioning process. That is why we make use of the /h and /d PID parameters. If you wouldn't use the Activator tool, the out of band 'hello messages' would have easily timed-out a long time ago and you wouldn't be able to commence their resending unless you pulled the power cable out and back in - i.e. restart the Management Engine.
- The PID is predetermined per machine type and can be inserted into XML file that sits in client - if the PID was unique per each machine this would have broken the whole solution - hence a clear recommendation to have the same PID/PPS across all machines or at least across all machines of the same model
- At this point the information is written into an Interim DB using SQL account permissions
- Note that no permissions need to have been delegated for all Local System Accounts
- On the server side the script uses the same or different SQL account permissions to access to the interim DB
- On the server side the script contains the /p and /o parameters - this is crucial as this is a single point where the /p and /o parameters can be changed thus providing flexibility
- In addition since the customer has opted to not use certificates and because there is a difference between the connection specific and Active Directory domain suffices, provisioning is take place with hostname only - typically this would have involved using the /a switch, however there is a known issue that won't work under the context of the Local System Account. Therefore the FQDN is stripped of it's domain the server script and the hostname is derived.
- The server script creates an XML file with the appropriate content to plug into the Configuration Parameters table in the main SCS DB, as the SCS service can parse the contents of this XML file and check that it is valid content.
The overall benefit of this solution is you avoid the security risk of delegating access rights for all Local System accounts, cover the different scenarios when the Activator Utility should be run, avoid the problems of mismatching domain suffices and maintain the flexibility of a single point of changing parameters for the variable Activator Utility syntax.
The same logic will apply if you are using RCFG - simply ignore point #6 above regarding PID.
Hope some of you find this useful.
Thanks, Tal
