Beginning to test and work with my new AMT SCS server and I want to get some AMT records into SCS. The User Manual mentions what sounds like a convienent way to get the AMT properties from a vPro machine and enter them in the database. I've checked the location it mentions ( Install Drive :\Program Files\Intel\AMDConfServer\Tools ) and it's missing in action. Has this tool been pulled?
Finally, a real dumb realization on my part - it appears you either can manually enter your systems into SCS, get a and import list of UUIDs from your vendor or use the AddServicNewAmtProperties.exe program to get devices into SCS for provisioning. There aren't any other ways are there?
the problem you have here is that you have to give each system you provision a unique name which has to match the Windows machine name as DNS resolution would not work otherwise, which in turn would break SMS (I assume you are using SMS, as you are installing SCS).
There are two sample scripts supplied with the Intel SCS package:
ServerScript- Uses WMI to connect to the system that's trying to get provisioned and queries it for it's hostname and UUID, then creates an entry for it in the configuration table.
AuxDBScript- Consist of two parts, one running on each client which adds the client's data into an auxiliary database and the other part which checks the data in the auxDB and copies it over to the configuration database so the client can get provisioned.
I am sure there are other ways of getting the required information, there is documentation available on the XML formats that have to be produced for SCS to handle the output.
The two sample scripts are still available, after you have downloaded and extracted http://softwarecommunity.intel.com/articles/eng/1025.htm SCS check the SampleScripts folder which contains both of the scripts mentioned above.
I found that I was able to get the pc to communicate with the SCS I had to go into the HP system AMT settings and manually set the ip to the SCS server. After that, I was able to see the system in the SCS console. (I'm still working on the provisioning side however). I believe we'll need to work with HP to pre-set this ip number in the AMT bios before they ship us our production systems to avoid having to go into the AMT bios manually on each new system.
We originally planned to integrate SCS with our existing SMS 2003 infrastructure, however we are close to upgrading to System Center Configuration Manager 2007 and from what I can see, SCS will not hook into it until SP1 is release sometime in '08.
I will look at the scripts you mentioned. That may be the way to go for us. I'm going to ask HP if they will supply us with a list of all the UUIDs they will send us to pre-stage the systems in the database. The only issue here I can see is the host name would be missing but we'd be half way there at least.
Rather than having HP set the IP address for you. You could use DNS to provide the SCS server ip address to your AMT clients. All you do it create a CNAME record with ProvisionServer as the alias and point it to your SCS server record. When the AMT client gets its IP info from the DHCP server and before it starts sending hello packets it will do a DNS lookup for ProvisionServer. You will also need to add option 15 to your DHCP server so it can resolve your domain suffix. Ken
Thanks for the note. I checked and I had created a CNAME during install. They told me I should try restarting the demo system to see if it picks up the system info. So far it hasn't. We'll keep plugging away. I think it may be an issue with not having bought a cert hash from one of the certs in the AMT bios.
One other utility you should start looking at (that ships with SCS) is the RCT tool. You will find it in the SMSAMTInstalltion directory when you extract the SMS addon. Look under ...SCS\Remote Configuration and you will find RCT.exe and StatusStrings.dll
These two files need to be run on the AMT system by a user that has local Admin rights on the AMT system and that has the role of Client Configuration on the SCS. You will find the details on the SCS User and Installation guide on page 62. This doc will also tell you the command line switches to use for this utility. I recommend customers to put these files into there normal automated build process.
The purpose of this utility is to send SCS the OS host name+FQDN. It will also send SCS its UUID, OU to use if AD integration is setup, and what profile to push to AMT. Once this utility runs, you will see the Configuration Parameters in SCS get populated. This is what SCS is looking for when you see the log messages of "no rows found."
This utility can also turn on AMT if manageability is not set to AMT in the MEBx. Running this utility will also start the provisioning process if the default 24 hour window has passed and the hello packets / SCS provisioning process has halted.
RCT.exe is a critical component to understand to perform true "no-touch" remote configuration.
I hope this helps....
Wow, this is good information. I wonder why these are not included with the base AMT SCS installation? This would seem to be a critical piece of the base SCS setup.
Now I can see why the name+FQDN are not present when the provisioning is taking place. So these utilities will query the system after it's been named and joined a domain and then send their info to the SCS server, right?
We're getting ready to have our supplier, image our machines for delivery in a month or so. I suppose I should ensure that these utilities are on that image!
Yes, that is the purpose of the RCT tool. I agree, this tool seems buried in the SMS addon download and not highlighted well enough in the SCS User Guide. So hopefully forums like this will start to get the attention necessary for this critical step in the provisioning process.
These files should be part of your base build and run as one of the last steps (like you said - after naming the OS and joining it to the AD). You will find in the documentation the command line switches to leverage (e.g. /p is the profile you want SCS to send to the system). If you really want to add flexibility, you can add advanced scripting to query the system first (look for variables like if it is a cPro system or a vPro system) and apply a different profile based on this variable. You could also place different systems in different OUs if necessary. Lots of flexibility here but you will need to do the scripting based on your environment.
no, i did not have to register the .dll. simply ran the .exe and .dll from the local system with admin rights. And the one thing to remember that is often overlooked is adding the user (or a group that includes the user) to the SCS as Client Configuration role. This gives the appropriate rights for the account to write the information to the SCS configuration parameters section.
Thanks for the info. Good point. I can image my frustration if one of my techs ran the tool and nothing happened! I imagine I could login script someting that could do a Run Once somehow for each new system.