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

Intel vPro Expert Center Blog

18 Posts tagged with the sms tag
1

If you are one of the many organisations that is planning on adopting Windows 7 and are wondering whether there are any implications for your vPro systems, then this blog is for you...

The implications of Windows 7 on vPro can be summarised as relating to at least one or more of the following areas:

  • 1. Management console
  • 2. AMT Drivers
  • 3. AMT Firmware
  • Let's start with the Management Console...

    If you are using Microsoft SMS, for example, as your management console then you should be aware that Microsoft officially doesn't support Windows 7 clients with SMS and therefore if you wish to manage your Windows 7 clients you will need to transition to Microsoft SCCM. Therefore, when planning your vPro migration to Windows 7 you need to actually to migrate to SCCM before hand.

    For those that do migrate to SCCM there are some additional implications which are indirect for the Windows 7 migration, but are part of the SCCM with vPro package. As this is not a posting on SCCM, I'll only mention briefly that you need to be prepared to have an Enterprise Certificate Authority, potentially have to make use of the WS-MAN translator (if you have any AMT Firmware that is prior to 3.2.1), you will need to upgrade to latest AMT Firmware versions and you will be integrated with Active Directory.

    Regarding AMT Drivers (namely HECI/MEI and LMS/SOL)...

    As the drivers are installed at the OS level, it doesn't come as a surprise that there might be a requirement for drivers to be able to install on a new operating system.

    1. AMT 2.x based systems - currently no planned official AMT Windows 7 drivers (use compatability mode)
    2. AMT 3.x based systems - official AMT Windows 7 drivers will be available by OEMs in Q1 of 2010 (for now use compatability mode)
    3. AMT 4.x based systems - you will require drivers version number 4.2 (otherwise you could use compatability mode)
    4. AMT 5.x based systems - you will require drivers version number 5.2 (otherwise you could use compatability mode)

    If you are not familiar with compatability mode, here is how you do it:

    1.      Right click on the driver installation file à Properties à Compatibility tab  (per sample screen shot below):

    untitled.bmp

    2.      Select the mode (I guess either Windows Vista or Windows XP SP2 or SP3)

    3.      Click Apply/OK

    4.      Right click installation file and run as Administrator and install the drivers (or alternatively prior to step 3 tick the box of run as administrator)

    Btw, the exact same process can be used for AMT 4.x and AMT 5.x drivers – i.e. take existing not 4.2/5.2 level drivers and install them in compatibility mode.

    It is useful to know that the 4.2 and 5.2 level drivers are actually available for download fromt the OEM sites; take Dell for example: http://support.dell.com/support/downloads/driverslist.aspx?c=us&l=en&s=gen&ServiceTag=&SystemID=LAT_E6400&os=WLH&osl=en&catid=&impid=

    untitled2.bmp

    and

    http://support.dell.com/support/downloads/driverslist.aspx?c=us&l=en&s=gen&os=WLH&osl=en&catid=&impid=&SystemID=PLX_960

    untitled3.bmp

    Lastly, we have the AMT Firmware...

    Strictly technically speaking, Windows 7 doesn't require a different kind of AMT Firmware, since the firmware sits underneath the operating system anyway. What is required though is the latest AMT Firmware (4.2 and 5.2) so that it can interoperate with Microsoft SCCM in the best and most stable manner. Therefore what might initially seemed as no need to upgrade AMT firmware to work with Windows 7 actually becomes a recommendation to do so.

    Hopefully this has provided some clarity on the technical requirements around vPro and Windows 7. There are some particular compelling points for having vPro systems and leveraging them for a Windows 7 migration deployment, however this is covered by other blogs and materials out there, such as: http://communities.intel.com/docs/DOC-3096

    1 Comments Permalink
    1

    For those of you out there that are  using the SMS Addon the following might be of interest, if seeing close to 100% success rates is your thing...

     

    If you've been using the SMS Addon together with Microsoft SMS as your vPro enabled management console of choice then you might have experienced less than 100% success rates when you're trying to perform AMT operations on collections of machines. The following details I will be providing have been devised specifically in the context of using the AMT wake-up feature for a Power Management Use Case, however you can extrapolate the essence and apply elsewhere if you're using some of the other features in the SMS Addon...

     

    Ok enough of an introduction.

     

    If you're implementing the power management use case, then before you'll be using the AMT wake-up feature, you'll be putting machines to sleep according to a certain policy you've put together (user initiated, SMS job executed shutdown.exe or some other shutdown scripts). However, you want to be sure that the machines you have put to sleep can be woken up on demand - mandatory advertisement triggered wake-up, scheduled wake-up or console initiated wake-up. Finding out you can't wake some machines up that you've put to sleep is far from being ideal - effectively you're reducing the success rate of your use case and you're putting machines in a state where you're benefiting from power savings, but you've compromised on your ability to get access to that machine from remote.

     

    What might interest you then is a deterministic way to ensure that every machine you put to sleep as part of your power management use case, you can wake up. Well... we've done just that.

    Here is the trick - you create your SMS collection for machines that you want to put to sleep and then wake-up, with a simple SQL statement of:

    ' Select * where iAMTStatus = 1'  - the key here is this field iAMTStatus = 1 which is a return value that confirms the SMS Addon can communicate successfully with the vPro machine. Therefore you now have a deterministic way of knowing that a machine that you've put to sleep can be woken up using SMS Addon and the AMT wake-up feature.

     

    An improvement on that is to run an AMT discovery daily (or some other frequency) to dynamically update the collection based on the ability of the SMS Addon to get to machines successfully. This will cater for if there are any changes in your environment, which there might or might not be. Currently the only way to run an AMT Discovery repeatedly on machines that have already been discovered in the past is to manually right click on a collection in the SMS Console and select AMT Discovery. We might have a more automated way of doing this soon... so watch this space.

     

    Hopefully you find this useful.

     

    - a caveat/disclaimer I should perhaps mention is that his method does not mean you will have 100% success rate for ALL your machines. Undoubtedly you will have some machines that do not have iAMTStatus = 1. Effectively what you're doing here is defining the scope.

    1 Comments Permalink
    1

    If you have experienced WMI related issues with the SMS Addon or are worried about potential WMI related issues you might want to read this...

    The SMS Addon relies on calls to the WMI service for interacting with SMS and it calls the WMI service more than you might think. For some customers it has been observed that the default frequencies of these calls coupled with the amount of data/entries (such as number of advertisements, number of collections etc.) causes a very high load on the WMI service and a subsequent crash of the service that requires a full reboot of the entire Server (not just the service). Obviously that is not an acceptable situation for a production customer, however there are 8 specific instances where the SMS Addon makes calls to the WMI service which can be tweaked to provide a potential resolution.

    You won't see these 8 registry keys in the registry as the SMS Addon uses default values inside the SMS Addon code. You would need to generate these keys yourselves and provide values in order to override the defaults used. The list of these keys and the what they are for are as follows:

     

    All registry keys need to be created in: HKLM\SOFTWARE\Intel\Intel(R) AMT Add-on\GEN\ folder and Dword values need to be entered in minutes. Any value but 0 is legal. There is no disable value and hence 'disabling' is achieved by setting a very high value such as 5 (2,628,000 minutes) or 10 years (5,256,000 minutes).

     

    These is the list of the scheduled WMI related operations:

     

    1. NewSysScanInterval used to identify new systems in SMS (discovered by SMS discovery methods like AD discovery) – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site).

    1. DeletedSysScanIntervalused to remove information about systems removed from SMS – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site).
    2. SCSSystemScanIntervalused to find new machines in SCS – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) and also this doesn’t apply if add-on isn’t integrated with SCS.
    3. SystemChangeMembershipScanIntervalused to identify systems membership in groups (for system defense settings) – by default runs every 60 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or if system defense isn't being used.
    4. OffLineSystemScanInterval – used to run commands on machines that were offline (used for system defense and event registration) – by default runs every 5 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or if system defense or event registration aren't being used.
    5. SCSrequestScanInterval – used for tracking requests from add-on to SCS (unprovision, reprovision) – by default runs every 5 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or no un/reprovision commands are run from the add-on; also this doesn’t apply if add-on isn’t integrated with SCS.
    6. UpdatedAdvertisementsScanIntervalused for reading advertisement definitions – by default runs every 2 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or if advertisement wakeup or system defense aren't being used. Runs frequently to pick up any changes to advertisement settings.
    7. AdvertisementChangeScanInterval used for identifying status of systems with system defense settings on advertisements – by default runs every 5 minutes – not needed if no systems are managed by SMS Site (such as Central SMS Site) or that don’t run system defense on advertisement.

    Tal

    1 Comments Permalink
    1

    Murphy's Law states that just when you think you have shared all you have to give in a document you find a juicy tidbit that should have been included.  Therefore, I have updated the Intel® AMT™ Add-On for SMS from V3.3 to V5.0 Upgrade OverviewPDF. 

     

    I discovered a batch file that is included in the default installation directory, C:\SMSAMTInstallation\iAMT addon for SMS\IAMTSMSSettingsExport.bat.  Within it contains the command line to export the registry settings for your currently installed version of the Add-on.

    1 Comments Permalink
    0

    Before you upgrade the IIntel® AMT™ Add-On for SMS to the Intel® Client Manageability Add-On for Microsoft* SMS 2003 version 5.0 check out my document about the process and some things to keep in mind befor you begin..  Thanks! Intel® AMT™ Add-On for SMS from V3.3 to V5.0 Upgrade Overview

    0 Comments Permalink
    1

    If you are deploying vPro have you thought about what might happen if you are running virtual machines on your vPro clients? The virtual machine will have its own virtual IP address which will be different from the actual host IP address which is the one we want when using vPro. What was happening was that the vPro machine was getting provisioned with SCS, but then when discovery was attempted with the SMS Addon, the provisioned vPro system could never be discovered and sub sequentially managed because the systems showed up as 'Outside Site Boundaries'. It seems that the SMS Addon had a 'flaw' in that it assumed that a machine will only have a single IP address. I cannot say based on my experience whether sometimes the host IP address will be picked up and the problem won't manifest itself or whether it will always be the virtual IP address that will be picked up.

     

    I emphasize that I have experienced this situation when using the SMS Addon and not with any other management consoles. That doesn't mean the problem won't manifest with them as well or whether the design of those products caters for this. If anyone has come across virtual machines on vPro clients and this has or has not caused issues I would be interested in your feedback.

     

    At a high level, the nature of the fix will be that the SMS Addon will not assume there is a single IP address and will loop through the IP addresses. If an IP address comes up as outside the site boundaries the sms addon will loop onto the next available IP address. This process will continue until it has exhausted all the IP addresses available on that local vPro machine and only at that point 'give up'.

     

    The fix within the SMS Addon will be incorporated into an official hotfix which will be published soon; I'll provide an update once it has been released.

    1 Comments Permalink

    Hello,

     

    This is my first contribution to the Intel vPro Expert center, and although I would not consider myself an expert on this product, I've still been graciously allowed to post here. Thanks Josh!

     

    I'd like to start out by introducing myself. My name is Trevor Sullivan, and I am a desktop systems engineer at a large retail corporation. Over the past 8 months or so, I've been working quite a bit with several people from Intel and Microsoft to better understand the Intel vPro technology, and how it can benefit my company. Overall, I'm really impressed with the technology, and I am fortunate enough to be working with an environment that has a pretty decent install base of Intel vPro-enabled systems.

     

    I'd like to take a few minutes to explain a few issues that we recently experienced with our production vPro implementation.

     

     

    -


    Provisioning Certificate Chain Invalid

     

    We're using Intel vPro with Microsoft Configuration Manager 2007 SP1, and for a while, we had been running into issues that prevented us from provisioning a vPro device. It turns out that the reasoning behind this was related to our provisioning certificate. We requested a certificate from Verisign, and imported it into our central SCCM site server. We have several child primaries to our central SCCM primary site server, however, and we were using the same provisioning certificate on those systems (Intel confirmed that this was possible).

     

     

     

     

     

    When I exported the certificate (using the Certificates MMC snap-in), with its private key, from my central SCCM site server, I did not choose the option to export the certificate chain with it. Importing the certificate, with its private key, went just fine on the other SCCM primaries, but provisioning just didn't work. After working with Bill York from Intel for several hours, it was finally determined that the Verisign Class 3 Intermediate Certificate Authority's public key certificate was expired in the Intermediate certificate store on the SCCM site server running the out-of-band (OOB) service point. I imported the updated Verisign Intermediate certificate into the server's Intermediate CA certificate store, which resolved the issue I was having.

     

     

     

     

     

    If you are experiencing this specific problem, you should see something like the following in your amtopmgr.log on the SCCM site server running the OOB service point:

     

     

     

     

     

    Try to use provisioning account to connect target machine vprosystem.subdomain.mydomain.com...

    Server unexpectedly disconnected when TLS handshaking.

    **** Error 0x382b948 returned by ApplyControlToken

     

     

     

     

    Although this probably should have been obvious to me, I did not actually open the provisioning certificate on the server I had imported the certificate on, to verify that the certificate was valid. If I had done so, I would have seen a message stating that the certificate was invalid, and then I could have looked at the certificate chain tab to see that the Verisign Intermediate CA's certificate was not valid. After examining the certificate for the Intermediate CA, it was determined that it had expired, causing my provisoning certificate to become invalid.

     

     

     

    -


    Microsoft PKI -Auto-Approval of Pending Certificate Requests

     

     

    After resolving the certificate issue, we started seeing another issue. This issue was related to our internal Microsoft PKI. The next symptom we saw was again in the amtopmgr.log file (+in case you haven't figured it out, this is probably the most useful AMT log in SCCM). Here are the messages we saw:

     

    Send request to AMT proxy component to generate client certificate. (MachineId = 60752)

    Successfully created instruction file for AMT proxy task: D:\SMS\inboxes\amtproxymgr.box

    RETRY(1) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

    Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

    AMT Provision Worker: Wakes up to process instruction files

    AMT Provision Worker: Wait 20 seconds...

    RETRY(2) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

    Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

    AMT Provision Worker: Wakes up to process instruction files

    AMT Provision Worker: Wait 20 seconds...

    RETRY(3) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

    Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

    AMT Provision Worker: Wakes up to process instruction files

    AMT Provision Worker: Wait 20 seconds...

    RETRY(4) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

    Wait 20 seconds to find client certificate for AMT device vprosystem.subdomain.mydomain.com being generated again...

    AMT Provision Worker: Wakes up to process instruction files

    AMT Provision Worker: Wait 20 seconds...

    RETRY(5) - Validate client certificate for AMT device vprosystem.subdomain.mydomain.com being generated.

    Error: Missed device certificate. To provision device with TLS server or Mutual authentication mode, device certficate is required. (MachineId = 60752)

    Error: Can't finish provision on AMT device vprosystem.subdomain.mydomain.com with configuration code (0)!

    >>>>>>>>>>>>>>>Provision task end<<<<<<<<<<<<<<<

     

     

     

     

    What this is telling you, is that the OOB service point was unsuccessful with its attempt to generate and retrieve a web server certificate, for the vPro client, from your internal Microsoft CA (either root or subordinate, but in our case, a subordinate). Although we had duplicated and configured the web server certificate template on our CA, the certificate was not getting created as we expected. The issue, in this case, was that our CA was not configured to automatically approve pending certificate requests.

     

     

     

     

    In order to resolve this issue, follow these steps:

     

     

     

     

    1. Open the Certification Authority MMC snap-in and connect to your CA

    2. Right-click the CA node, and select Properties

    3. Select the "Policy Module" tab

    4. Click the Properties button

    5. Choose the lower radio button (It reads: "Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate.")

    6. Click OK on all dialog boxes

    7. Restart the CA service, to allow the setting to take effect

     

     

     

     

    -


     

    I have a few more issues I'd like to talk about, mostly related to DNS. I will post again with details.

     

     

     

     

    Thanks for reading,

     

     

     

     

    Trevor Sullivan

    Systems Engineer

     

     

    Permalink
    0

    Given the new exciting capabilities in Intel vPro technology around hardware assisted manageability and security, our IT customers have mentioned that this new technology makes them feel much more powerful - like a superhero! See the video below to see what superhero Intel vPro technology made them feel like.

     

    
    
    ]]>

     

    
    
    ]]>

     

    To see more videos from MMS 2008, go to http://www.intel.com/go/mms/

    0 Comments Permalink
    0

    We had the Intel vPro technology Challenge at MMS 2008 - a competition where teams of two competed to fix a troubled PC using Microsoft System Center Configuration Manager 2007 with PCs with Intel vPro technology. Check out how much fun this Challenge was at MMS 2008 this year:

     

     

    
    
    ]]>

     

    To see more videos from MMS 2008, go to: http://www.intel.com/go/mms/

    0 Comments Permalink
    0

    Sometimes within Intel Marketing, we're told that our description of Intel Centrino with vPro technology or Intel Core 2 with vPro technology is a bit lengthy. Therefore, while at MMS 08, we asked Intel customers as well as technical experts from Intel and Microsoft to give us their best, most concise acronym that best describes Intel vPro Technology. Listen to their responses below.

     

     

    
    
    ]]>

     

    To see more videos from MMS 08, go to http://www.intel.com/go/mms/

    0 Comments Permalink
    0

    When Intel released Intel vPro technology into the marketplace in 2006, the press asked us what the "v" in Intel vPro technology meant. Now that the technology has been in the marketplace for almost two years, we thought that the best answer to the question, "What does the "v" in Intel vPro technology mean to you?" would come from Intel customers, as well as from some of the technical experts from Intel and our partners who deal with our customers on an almost daily basis. See their answers below.

     

    
    
    ]]>

     

    To see more videos from MMS 2008, go here: http://www.intel.com/go/mms/

    0 Comments Permalink
    0
    0 Comments Permalink
    0
    Coming Up:

    We are going to have Matt Royer join us again on the show. Josh, Russ, & Jeff Torello will be getting the latest information on WS-MAN translator integration and SMS/SCS to SCCM Migration. Hope you are able to join us!

    When: April 21st @ 3:30 PM

    Call-in Number: (347) 326-9831


    Check out these blog posts from Matt Royer to get an insight on what our show will be about:

    SCCM SP1 & WS-MAN Translator: How vPro firmware versions less than 3.2.1 are supported

    Overview of SMS/Intel SCS migration to SCCM SP1


    http://www.blogtalkradio.com/openport

    Here's the scoop, yet again, for those who haven't heard...

    Hosted by Josh Hilliker, Russ Pam, & Jeff Torello this bi-weekly informal show will be covering a variety of topics and is a perfect avenue to get your questions answered. Listen in live, give your two cents, or just download the show after it has aired. Make sure not to miss out on this awesome opportunity to learn and engage with the vPro experts. Can’t join us live? Have no fear, blogtalkradio let’s you listen to the show whenever you have the time. Visit the Open Port Radio site (link is above) to hear previous shows and even catch a glimpse of what’s to come!

    0 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
    1

    Client Manageability Add-on (aka AMT Add-on) version 3.2 for SMS 2003 has been released. For download and more information, please visit: http://softwarecommunity.intel.com/articles/eng/1356.htm

     

    Bug Fixes / Issues Resolved

     

    • An Intel® AMT PC can be configured to use HTTP Digest network communication. Part of the Digest header is a random string which includes the platform UUID. Under certain circumstances depending on the manufacturing flow, it is possible that the Digest UUID and the actual platform UUID as stored in the hardware inventory table do not match. The Intel® Add-on for SMS would reject HTTP Digest communications from a system with mismatching UUIDs. Note that the Digest string uses the UUID purely as a random number and does not use it as an identifier, so there is no reason that they must match. This hotfix amends the functioning to ignore mismatching UUIDs.

    • There were cases involving sites containing very large numbers of AMT devices where menu selections would be displayed unacceptably slowly. This has been solved.

    • In rare cases, expired advertisements would wake up AMT devices. This has been solved.

    • Due to the way in which SMS performs log message collection large numbers of messages are collected, many of which are not critical AMT device messages. Although these messages are valid, they are nonetheless not required in many situations. A workaround has been implemented that allows for the suppression of various levels of non-critical messages.

     

    New Features from 3.1 to 3.2

     

    • The Add-on service account no longer requires local administrator permissions.

    • There is no longer a need for a dedicated Add-on service account. The user specifies the Add-on service account during installation.

    • New Active Directory groups.

    • The Add-on is integrated with version 3.3 of the Intel® AMT Setup and Configuration Service.

    • Operations no longer require SMS Administer permissions, except for changing the Add-on Settings.

    • A user in the Redirection Managers group can terminate another user's redirection operation.

     

     

     

     

     

     

     

     

     

     

    Matt Royer

    1 Comments 0 References Permalink
    1 2 Previous Next