Home > Intel Communities > Open Port IT Community > Intel® vPro™ Expert Center > Blog > Tags > scs
1 2 Previous Next

Intel vPro Expert Center Blog

27 Posts tagged with the scs tag
0

Take a look at a recently posted document providing insights on what might cause a rapidly expanding database, key learnings how to minimize the growth and provide good performance, and more.

 

http://communities.intel.com/docs/DOC-4306

 

The document may be updated over time, depending on requests, inputs, and so forth

0 Comments Permalink
0

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

0 Comments Permalink
0

I posted some tips on syntax if you need to create the SCS database as a standalone step when building your Intel® Active Management Technology Setup and Configuration Service Server...  This is an optional step, only required if you do not want the AMTConfServer.exe installer to create the database for you.

 

 

Details can be found on my post Syntax for manually creating the SCS Database

0 Comments Permalink
0

I ran into a problem when I accepted my server's default setting when installing my Remote Configuration certificate.  I found root cause and decided to share...

 

http://communities.intel.com/docs/DOC-2672

0 Comments Permalink
1

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

 

 

1 Comments Permalink
0

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

 

0 Comments Permalink
1

SCS 5.0 is the latest version of the Intel Setup and Configuration Service. This new version boasts a number of fundamental and exciting additions to the world of vPro:

 

  1. You can enjoy the benefits of Active Directory Integration without the need to extend the Active Directory Schema!

  2. You can use Windows Authentication to communicate with the SCS Database

  3. The SCS Console version 5.0 has a much nicer and professional looking user interface

  4. The performance, stability and logging capabilities of the application have notably improved

  5. You have the ability to dynamically create collectoins of AMT Systems based on different filter conditions

  6. This is still early days for AMT Firmware versions 4 and 5 and the use of CIRA (Client Initiated Remote Access) and MPS (Management Presence Server) but it supports them

 

Note: If you are using SMS as your Management Software you will need to use the Intel (R) Client Manageability Addon version 5.0 which is available for download from the following url: http://downloadcenter.intel.com/Filter_Results.aspx?strOSs=All&strTypes=All&ProductID=2609&lang=eng&OSFullName=All%20Operating%20Systems

 

To emphasize the point - you will not be able to use SMS Addon version 3.3 with SCS 5.0. SCS version 5.0 will be bundled already for you with the Addon version 5.0.

 

Some potentially useful technical insights that I have gathered through my experience of being an early adopter of SCS 5.0 through trying to deploy it at a large-scale enterprise customer:

 

 

  1. If you opt for having windows authentication (as opposed to the dummy SQL account which was part of the design up until SCS 3.3) you will need to opt for the custom installation path. In there you will be prompted to specify twice the user for running the AMTSCS and AMTSCS_RCFG virtual directories in IIS. You will need to specify the same username and password of the accounts that are running your IIS services where your SCS is being installed. Pay attention to this step - if you specify any user other than the user that is running the IIS services: this could a local account for example and not a domain account, then you will not be able to log into SCS via the SCS console.

  2. When you opt for the windows authentication to DB you wil not be able to use the default website on IIS. If you are creating a new website and you are going to opt for https connection, make sure your new website is setup with the server ssl certificate. You will also need to remember to stop the default website and have your new website running.

  3. You will need to remember to delegate permissions to the account that is running the SCS service on the AD OU for AMT objects, but this time it will be for objects of type 'Computer Objects'. There will not be a conflict with the Host OS level computer objects as these AMT Computer Objects are seen as user objects.

  4. You have the option to create the DB separately using an SQL Standalone DB script (i.e. not as part of the install wizard) however even if you are opting for windows authentication to your SCS DB, you can achieve this by only running the wizard (the custom install path). If you have created the DB prior to SCS install, you can point the SCS service to this DB instance during the install wizard.

  5. A general point to note that would apply to any provisioning with SCS (not just SCS 5.0) - when you are creating a profile

  6. Another point to mention is that the profile ID number is not fully deterministic if you don't run through the config of a new profile without pressing cancel at any point. For example, if you have the default profile as profile ID #1 then when you try and create an additional profile and at some point click cancel and then try and create a new profile it can eventually have a profile ID of #5 for example. This can start becoming a problem if you rely on the profile ID number as part of your provisioning process using the Activator Utility for example, as you can only pass the profile ID as far as the SCS API is concerned, yet if you've hardcoded the profile ID in some file on the vPro client where your Activator Utility will run then you cannot know for sure until your profile has been created in SCS what its profile ID will be. If you are editing an existing profile, its ID number won't change. You also cannot go into the DB and change that value manually as it is a primary key and is auto generated as part of an indexing mechanism in the SCS code. - this one might be a bit tricky, so contact me if you need me to clarify.

  7. I don't know whether you've noticed any sluggishness in the past when trying to install 3.x versions of SCS - for example with one of my large customers it would take 1.5 hours to install SCS because of looking up users in a rather large Active Directory; whereas with SCS 5.0 it takes 5 minutes at most.

  8. Whilst I haven't taken advantage of the capability to create collectoins of AMT systems I wanted to point out one of the main benefits of this feature. I have been faced in the past with situations where I need to perform an operation through SCS on many machines, but not all machines. Therefore the global operations in SCS 3.x versions only gave me the possibility of running the command on a single or all machines. Now I can tailor which machines I want to perform operations on.

 

My overall recommendation to you is to give SCS 5.0 a go. It is easily the best SCS version that has been released. I have blogged about it as part of my first hand experiences - I have had nothing to do with its development and I am speaking out of the objective view of a user. Hope you find this useful.

 

Ta

 

 

1 Comments Permalink
0

TODAY: What’s coming in SCS next version? SCS 5.0 is just around the corner and the vPEC team has our guests Shai Kavas and Chaim Rand joining us. This version of SCS includes major usability and scalability improvements and contain some very exciting new features. Some of these cool features are results of feedbacks we got from our partners and… from YOU – our end customers. Wanna know more? Stay tuned to our show!

 

Date / Time: 6/16/2008 9:30 AM     Call-in Number: (347) 326-9831

http://www.blogtalkradio.com/openport

 

Questions, comments, or concerns? Feel free to contact me.

 

0 Comments Permalink
0

 

This SCS deployment and capacity planning white paper presents architectural and infrastructure guidance for deploying Intel setup and configuration service in various enterprise scenarios. The guidance is based on SCS 3.x extensive scalability testing done in Intel Enterprise Integration Lab.

 

 

You can download white paper and capacity model calculator from below links:

 

 

SCS 3 deployment white paper: http://communities.intel.com/servlet/JiveServlet/downloadBody/1636-102-1-1993/SCS3%20Deployment%20White%20Paper.pdf

 

 

SCS 3 capacity model calculator: http://communities.intel.com/servlet/JiveServlet/downloadBody/1637-102-1-1994/SCS3%20Capacity%20Model%20Calculator.xls

 

 

I am currently working on SCS 5 white paper. Any additional inputs will be comprehened in scs5 white paper. Appreciate all the inputs and comments that will help me in refining the content to make it more relevant for end user community.

 

 

thx

 

 

Anjaneya "Reddy" Chagam

 

 

0 Comments Permalink
0
0 Comments Permalink
0
0 Comments Permalink
4

Here are some high level steps that walk you through procuring a VeriSign certificate and configuring it for the Intel Setup and Configuration Service (SCS). Other certificate vendors like Go Daddy, Starfield, Comdo, etc will have different purchasing processes.

 

Purchase Verisign Certificate

 

 

 

 

  1. Generate Certificate Signing Request (CSR) by following the instruction in the link, http://www.verisign.com/support/ssl-certificates-support/page_dev019431.html.

  2. The Common Name (CN) needs to be the FQDN of the server you want to install this certificate on. (i.e. host name + domain name)

  3. Enter ‘Intel(R) Client Setup Certificate' for Organization Unit (OU).

  4. Complete all the steps. Visit VeriSign website, [http://www.verisign.com/ssl/buy-ssl-certificates/] to start purchasing process. Select ‘Secure Site: SSL Certificates' under ‘Buy Individual SSL Certificates'.
    Note: you could choose the other two, which are in more advanced level, depending on your need.

  5. Enter all the information required and copy the CSR generated by the server

  6. Complete all the steps and print out the order confirmation page for your record.

  7. You will receive an email of Verisign automated order verification within few hours. You have only 24 hours, after receiving the email, to finish this process. Click the link in the email and go through the process.


    *Important:* If you cannot recognize the second phone number listed on the webpage, cancel the automated verification process and have them call you instead.

 

 

 

Certificate Installation and Exporting

 

 

 

 

 

  1. You will receive the link of installation instruction in the email containing the certificate. Follow the instruction to complete installation

  2. VeriSign will send you the SSL certificate via email. If the certificate is an attachment (Cert.cer), save the file to the hard drive. If the certificate is in the body of the email, create a .cer file (example: NewCertificate.cer) by copying and pasting the certificate text into a plain text editor such as Notepad or Vi. Please be sure to include the header and footer as well as the surrounding dashes. Do not use Microsoft Word or other word processing programs that may add characters. Confirm that there are no extra lines or spaces in the file.

  3. Open the Internet Services Manager (IIS). Click Start > All Programs > Administrative Tools > Internet Information Services (IIS) Manager.

  4. Under Web Sites, right-click your web site and select Properties.

  5. Click the Directory Security tab.

  6. Under Secure Communications, click Server Certificate.

  7. The Web Site Certificate Wizard will open, click Next.

  8. Choose Process the Pending Request and Install the Certificate, then click Next.

  9. Important: The pending request must match the response file. If you deleted the pending request in error you must generate a new CSR and replace this certificate.

  10. Select the location of the certificate response file, and then click Next.

  11. Read the summary screen to be sure that you are processing the correct certificate and then click Next.

  12. You see a confirmation screen.

  13. After you read this information, click Next.

  14. Go back to IIS Manager (Start > Programs > Administrative Tasks > IIS Manager)

  15. Expand Web Sites and right click Default Web Site

  16. Under Secure Communications, click View Certificate...

  17. select Detail tab

  18. Click Copy to file at right bottom of window, the Certificate Export wizard will pop up. (N)

  19. choose Yes, export the private key (N)

  20. mark Include all certificates in the certification path if possible (N)

  21. give a password (can be weak password) and confirm (N)

  22. Give location and file name for the resulting PFX. (N), Finish, Ok.

  23. Close all windows.

 

 

 

 

 

 

 

 

 

 

 

 

Adding Cert To SCS

 

 

 

Install the certificate created above in the System Certificate Store on the platform where the SCS executes. Follow the following steps:

 

 

 

 

 

  1. Open certificates (local computer) using the Microsoft Management Console (MMC). To add the certificates plug-in to the MMC,

  2. Select file/add snap-in.

  3. Select Add....

  4. Select Certificates.

  5. Select computer account; click Next.

  6. Select Local computer; click Next.

  7. Select Finish; Close; select Certificates and click OK.

  8. In the console tree, click the logical store where the mmc will import the certificate.

  9. On the Action menu, point to All Tasks and then click Import to start the Certificate Import Wizard.

  10. Type the path and file name of the certificate to be imported or click Browse and navigate to the file. Select automatically select the certificate store based on the type of certificate.

 

Invoke the loadcert utility

 

 

  1. Located at <install_root>:\Program files\Intel\AMTConfServer\Tools.

  2. Double-click on loadcert.exe

  3. Select the certificate that was just imported. The utility will report any problems in the certificates that it detects that would prevent using it as a ZTC certificate.

 

Matt Royer

4 Comments Permalink
3

The Brand Promise Validation team here at Intel came across an issue in the lab which many customers may also run into when they are trying to deploy AMT. The question was, how do I use two different ISVs to manage different aspects of my Enterprise configured AMT client fleet? Theoretically this isn't neccessarily a tough question. Based on how AMT was designed, so long as you have the same authentication and credentials setup between the different managment software, you should be able to access the AMT features. In practice, however, many management applications attempt to configure AMT in such a way that they have sole access by customizing the provisioning settings and then hide those settings away.

 

However, as I'm about to describe, with a little tweaking, you can force these applications to play nice together.

 

 

The main thing to remember anytime you are setting up AMT in enterprise mode is that the key to accessing AMT is having the correct certificates in place. For access that means having a Web Server based certificate template that will be used for TLS communication between the console and AMT. If you are also using PKI provisioning, you'll have to have a properly configured or purchased provisioning certificate in place (I won't be covering the details of PKI provisioning in this blog, but maybe in a future update). Lastly, for SMS and Altiris you'll also need a .pem certificate. Details on how to create a .pem certificate is included in both the Altiris help and Intel AMT Add-on for SMS documentation. A quick summary of a .PEM file certificate is taking each certificate in the chain starting at the top and concatinating those certificates into a single file. This file is used for secure TLS communication during SOL sessions.

 

 

 

The two management applicaitons we targetted for implementation was Altiris and SMS using the Intel AMT Add-on for SMS. The reason we targetted these apps is that we have inimate knowledge using these applications since they are used in our validation efforts and they both utilize the Intel SCS for provisioning.

 

 

 

Both Altiris and SMS systems should be in the same domain using the same certificate authority and have the same root certificate installed. While it is definately feasible that you could have the the two management applications in different child domains using wildcard certificates for authentication, this article doesn't cover that specific configuration.

 

 

 

I'm not going to go into the details of setting up Altiris and SMS or how to configure SCS for provisioning since it is assumed that if you are attempting to merge these ISVs so that they can manage AMT clients, then you should already know how to get the individual applications to work with AMT.

 

 

 

I started off by getting Altiris setup and configured using the built in SCS included in the OOB Management solution for Altiris. At this point I didn't have to do anything special in order to make sure that the SMS Add-on would work, I just setup Altiris as normal to manage AMT clients. Once setup, I verified that I could provision and manage my AMT clients.

 

 

 

Next step, on a different machine, I setup and configured SMS with the Intel AMT Add-on for SMS. I configured SMS to use it's own SQL server, however, there is no reason that you couldn't have it use the Altiris SQL server (setting up a separate instance) or a stand alone SQL server (again with a separate instance). For ease of configuration, however, I just used a separate SQL install on the same machine as SMS.

 

 

 

Once you have the SMSAMTUser_<sitecode> account created in active directory and have that account as well as whatever user accounts you want to use AMT via SMS added to the Intel(R) AMT groups (there are 3-5 of them depending on the version of the AMT Add-on you are using), you need to add the SMSAMTUser_<sidecode> to the Altiris SCS users list. On the Altiris system go to: View -> Configuration -> Solution Settings -> Platform Administration -> Out of Band Managment -> Provisioning -> Configuration Service Setings -> Users. Click the blue + to add a new user. Click the ... button. Select domain and type in the name query field SMSAMTUser and click Find. Select the SMSAMTUser_<sitecode> that is found in the results field and click OK. Under Role make sure Enterprise Administrator is selected. Click OK. This gives the service account for the Intel(r) AMT Add-on for SMS rights to view and modify the Altiris SCS.

 

 

 

On the SMS system, open up the Intel Add-on Settings dialogue box and configure it to use the Altiris Setup and Configuration Server. In order to find the URL that Altiris uses to connect to the SCS, On the Altiris machine, go to:

 

 

 

View -> Configuration -> Solution Settings -> Platform Administration -> Out of Band Managment -> Provisioning -> Configuration Service Setings -> Service Location.

 

 

 

 

 

If you have the Default URL set, you should have something like /<fqdn/AMTSCS. If you are using an alternative URL, copy that down. On the SMS machine, open up the Intel Add-on Settings and go to the Setup and Configuration tab. Select the Integrated Setup and Configuration radio button and type in the URL you copied down into the SCS Service URL box. Click the Set Profiles box and the AMT profiles that are setup in Altiris should pop up in a new window. Select the profiles you want to use in SMS (select all of them if you want all profiles to be able to be managed in SMS) and click OK. The list of supported profiles should now be populated with the profiles that are setup in Altiris.

 

 

 

Next step is to setup the .PEM certificate file that was used in Altiris for the Intel AMT Add-on for SMS. Copy the .PEM file used in Altiris to the SMS system. If you don't know where you .PEM file is located in Altiris, go to:

 

 

 

View -> Configuration -> Solution Settings -> Real-Time Console Infrastructure -> Configuration.

 

 

 

Click on the Intel(r) AMT Connection Settings tab. Under Redirection Security you should see a box next to the Trusted CA certifcate location. That box should have the path to the .PEM file. Once you have copied that file to your SMS system (doesn't matter where you put the .PEM file on your SMS box, so long as you remember where you put it) open up the Intel Add-on Settings dialogue and click on the Security tab. Check the Enable Intel(r) AMT secure Connection (TLS) box. In the CA Certificate Path put in the path to the location of the .PEM file that was copied onto the SMS system. Click Apply.

 

 

 

That is the basicis of what needs to be done. Once you have discovered the AMT clients in SMS and they are populated in the collection, right click on All Systems and go to All Tasks -> Intel(r) AMT Tasks -> Discover Systems. Now when you right click on an AMT system and go to All Tasks -> Intel(r) AMT Tasks you should see the list of AMT functions you can perform such as Asset Identification Information, Power Control Operations, etc.

 

 

 

In order to get SOL/IDE-R to work and System Defense to work, you'll need to go into the Intel(r) Add-on Settings in SMS again and setup the location of the ISO images that will be used for IDE-R and the System Defense file that will be used to filter packets using Circuit Breaker. Creating the System Defense file is covered in the Intel(r) AMT Add-on for SMS documentation and will not be explained in detail here. The repository for the ISO images needs to be a network share and can either reside locally on the SMS system (still mapped to the network share location) or can reside in a central repository. If you want both Altiris and SMS to use the same set of images just use the same network path to the ISO images for both applications.

 

 

 

That's it. In my environment I'm able to manage AMT machines with either management application. The only slight gotcha (and this is more a security feature of AMT) is that if one management application is currently managing a client (ex. using SoL) then the other is unable to break in and use the client. The gotcha part of this is that neither management application gives a clear indication that the system is currently in use by another management application, the attempt to manage just fails with an authentication error.

 

 

3 Comments 0 References Permalink
0
0 Comments 0 References Permalink
0
0 Comments 0 References Permalink
1 2 Previous Next