If you are using Intel SCS 5.x, after you've installed it you will need to decide whether you want to configure the scs service to either get configuration parameters from a script or from the DB. This seemingly innocuous decision has some technical implications, so here's the background..
Choice A - get configuration parameters from the DB
Let us first define what are the configuration parameters - they are the fields of a vPro system - such as: FQDN, AD OU, Profile - the important ones that are required for completing provisioning - and the remaining informative attributes, such as AMT firmware version etc. Therefore the configuration parameters that are necessary to have are FQDN (or hostname) AD OU path (if you are integrating with Active Directory) and the SCS provisioning profile being assigned to the vPro system. Where will the information for these 3 fields come from?
The wording of this option might be slightly misleading as you might (wrongfully) assume that the configuration parameters to get your vPro systems provisioned smoothly are sitting and waiting in the DB for you and will provide you an extra smooth provisioning experience over above the other method (using a script). This is however not the case; the configuration parameters are empty to begin with and only after going through a (successful or unsuccessful) provisioning process for each vPro machine, it will in turn have these configuration parameters populated in the DB, so that subsequent provisioning attempts will in fact be able to rely on these now populated configuration parameters in the DB.
Let us consider the flow of events...
A vPro system needs to initiate the provisioning process and let the SCS know about its existence - this is commonly known as the 'hello packet'. The hello packet contains a UUID (unique identifier), certificate hash or PID, MAC Address and ip address. Purely technically speaking, this will manifest itself by a new entry appearing in the AMTS table in the SCS DB. At that point you are missing the FQDN, AD OU path and profile ID. Once a new entry makes it into the AMTS table, it will also appear in the SCS Console as an unconfigured system with the UUID field populated, but the rest being blank.
You now have an option to manually double click on the row in the SCS Console and enter these 3 fields. Once you've done that, the information will now be sitting also in the UUID_MAPS table which is also know as the configuration parameters. This is typically not a scalable method and therefore the current BKM is to rely on a client side utility to send more than just the UUID, pre-provisioning information (cert hash or PID) and IP address, but also the FQDN, AD OU path and a profile ID.
The utility that has been designed to do this is the Activator utility which comes bundled when you download the SCS application (this blog posting won't go into the details of how to use the Activator Utility and what options you have and will assume you have an understanding of how to do this). Therefore instead of manually (and quite error prone) populating the fields, you can now have a utility that effectively pushes all the information required for provisioning into the UUID_MAPS table as well.
Another last option is to create a list mapping UUIDs and pre-assigning them FQDNs and uploading it into the UUID_MAPS table. This is more difficult as it relies on the OEM providing you with an accurate list of all the UUIDs prior to receiving the systems. This is technically feasible but logistically more difficult and as such is a rarer implementation.
Choice B - get configuration parameters from the script
This method might be less popular, as it is a bit more complex and should be used only when the circumstances necessesitate it. The script would typically be a VBscript for which a sample script is provided when you install the SCS service. What the server script does in essence is set the AD OU path and profile ID. The FQDN still needs to be provided by the vPro machine itself and for that it will rely on either the activator utility (as mentioned above) or client side vbscript - either of which will typically rely on a WMI query.
Purely technically speaking, the script takes the different parameters available to it and constructs an XML file (map.xml) that is formulated in a manner that is recognised and can be consumed by the SCS application. If there aren't enough permissions for the script to run locally, any necessary parameters are missing, or if the XML is not formulated properly then the SCS will complain about a missing XML file.
Using the server side script provides you the flexibitliy of making changes to the AD OU path and profile ID further down the line as opposed to the client side only method, which would have required you to pre-package the parameters to invoke the client utility and any changes would involve deploying a new package to all machines.
The server side script also allows you to overcome any permissions related issues and security concerns, as the client side only method typically requires administrator priveleges and involves letting each client right into the main DB (which for some security experts is an opportunity for malicious behaviour). Therefore a 2-tiered approach is possible where the client side (script or activator) send information into an interim DB and the server script reads the information from the interim DB. The trigger for the server script to run, is for a new entry to appear in the AMTS table but not have an entry in the UUID_MAPS table - i.e. a hello packet has arrived and there are no present configuration parameters.
Finally, the server script is essential if any further manipulations are required in order to accommodate a particular environment. Such is the case when the FQDN queried on the vPro client has a domain suffix of an Active Directory domain, but there is a separate non-AD integrated network domain and any queries to DNS will return the network domain FQDN. This requires provisioning the vPro system with the network domain, which could either be hard coded as a constant (like the AD OU path and profile ID) if there is only one, or it will need to be dynamic and poll DNS (though something like nslookup on IP address) to replace the AD FQDN with a network FQDN. Provisioning will succeed regardless, but the problem will be later on when trying to manage the vPro machine if you will be using AD integration and therefore will need to conform to the Kerberos protocol.
A situation can arise where you have configured SCS to use the script, however the the configuration parameters have already been populated due to a previous provisioning attempt - be it fully successful or not, since the parameters are in the DB already, the trigger for the server script to run will be missing and therefore it won't execute again. This scenario is typically come across in testing when the same machine is re-used. There are some 'real-world' scenarios such as machine has broken, is re-imaged and fixed by IT department, the client side provisioniong components (activator) kick-in on startup (typically) but the configuration parameters are already in the SCS DB and therefore the script will not run and provisioning won't succeed. Unfortunately SCS does not automatically remove the configuration parameters for machines that are partially or even fully unprovisioned. It can only be done manually when a system is deleted from the SCS Console and the 'delete configuration parameters' must explicitly be selected.
This turned out to be a longer posting than originally intended... but if you've made this far, hopefully you've picked up a few useful nuggets of information...
Tal
