However, many utilities are available for controlling or receiving data from a local interface - on the computer in which Intel AMT is enabled.

This local functionality is a very important part of the manageability system. Applications (administrative tools, anti-virus apps...) can stock essential data in the storage interface or set agents for software availability assessment. IT managers can perform a system update from this interface, or set user notification options.

For all this magic to happen in the computer, a special set of software is needed. Part of my work in Intel relates to this software  functionality, and in the next posts  we'll focus on each software in the package and explain what it does, how it does it and what are the methods (and consequences) of removing it. A great place to that expands on this subject is the Intel AMT overview (scroll to the Local Access section).

If you have an Intel AMT machine, the software that you have available is (your mileage may vary, depending on system manufacturer and Intel AMT generation):

• Intel MEI (or Intel HECI), a device driver
• Local Management Service (LMS), which allows network communication from local host
• User Notification Service (UNS), used in order to inform (via Windows' Event Viewer) about manageability operations taking place on the computer
• Intel® AMT System Status Service (AtChkSrv), a service that monitors the Intel AMT status
• Intel® AMT System Status (AtChk), a GUI for the service above (implemented as a notification area icon)

We'll see more details on these, in future posts. For best results, please write in the comments any and all questions you may have on the matter!

To be continued… :)

Pretexts aside, here is the 5th and last segment of the manageability comparison between ASF and Intel AMT.

After we covered the differences between the common features of both technologies (see part 1, part 2, part 3 and part 4), today we'll see which features are inexistent in ASF, but are part of the feature set of Intel AMT.

All the articles in this sequence relate to Intel AMT up to its version 3.0, and while they're not the ultimate complete-feature-listing of what's in Intel AMT, they list what's relevant when contrasting Intel AMT with another solution.
For a very good explanation and list of the Intel AMT features in its different versions, a good page is the "Intel AMT SDK - Start Here!" guide. There you'll find explanations about the features and a cool table, check it out.
In the end of this post, I present my own diagram to summarize what we've been talking in this 5-posts series. Together, the two tables draw a very clear picture of the Intel AMT feature set.
So let's dive into...

ASF Vs Intel AMT part 5 - Capability distinctions

1. Event Log
   • In the context of our posts, this is one major advance of Intel AMT over ASF.
   • ASF (== Alert Standard Format) was built specially for Alerts but nonetheless does not provide a method for logging events, or retrieving old ones -- more than that, the ASF rules say that alerts of a alert-triggering-event that happens and comes back to normal while there was no network (and thus no way of transmitting the alerts) are to be ignored and not communicated.
   • Intel AMT, on he other hand, lets IT Managers to log any event which happens (or filter specific events that should be logged)
2. Discover - HW Inventory and (3rd Party) Data Storage
   • The ASF specification does not define any asset control or querying functionality, but Intel AMT provides methods of querying (and in consequence, monitoring) the platform hardware and software inventory. Intel AMT stores hardware information automatically, and any other desired asset information (software related, for example) can be stored by customized software applications.
3. Heal and Protect - System Defense and Agent Presence
   • "Intel AMT with System Defense reduces exposure to virus infections by containing outbreaks and software tampering on the managed client, sealing the infected network element from the rest of the network. The Agent Presence capability detects whether critical applications such as anti-virus or software inventory programs are running. If they are not, Intel AMT can send a report immediately to an IT console and, if necessary, isolate the platform until an IT technician remedies the problem."
   • The text above is copied from the overview page :), so clear it is. As you may imagine, there's nothing close to these functions in ASF.

For more differences and comparisons, here is my own summary table -- I say "my own", because it is a personal non-official non-endorsed attempt at organizing the topics. I may be changing the contents if I receive corrections!

Thanks! I hope the series are useful!
The subject had a lot of popularity, with thousand of readers... So don't hesitate to comment or ask -- or asking for more -- although as of now this the last post of the series, if there are questions I'll of course address them in a sixth installment.

Posts in the series:
- ASF and Intel AMT - Spot the differences (part 1)
- ASF vs. Intel AMT part 2 - Technology differences
- More technology distinctions - Intel AMT vs. ASF, part 3
- Between Intel AMT and ASF, part 4
- Feature Advantages - Intel AMT and ASF part 5

In the previous three posts of this series (1, 2, 3), we talked about differences between the manageability two solutions, covering from the kind of network protocol used to the options available for security.

This will be (for now) the last post about distinctions between them, and in the next one I'll focus on the new features Intel AMT has that are not present in ASF.
That said, please let me know if there is any other difference you can remember and there will be another post to address it.

So here it goes: Other differences between ASF and Intel AMT are the way the two are configured, and also the options of sensors used:

Part Four: Other differences

1. Configuration (Provision) vs. One-Good-Boot
   • Intel AMT has a (somewhat complex, but versatile) configuration procedure (also called provisioning). It has options for configuring the technology locally or remote, and options for supporting a one-touch (or even no touch at all) configuration. It even comes in two (one simpler and one complex) flavors: Small Business mode and Enterprise mode. Gael has a post explaining the configurations tool, and you can learn about the configuration types in this post by Ylian. For information on the Remote (zero touch) configuration, you can read this article by Itai.
   • This configuration is done in a completely OS-independent manner. OS can be loaded or not, the computer can even be turned off. It can be re-done and changed at any time -- all in an OOB manner.
   • ASF, on the other hand, has to be configured by software in the host's OS.
     ASF Standard says "the client system requires one good boot to an OS-present environment to allow the device’s configuration software to run and store system-specific information into the device’s non-volatile storage". This limits the way ASF can be set up and configured -- and is actually counted in the "Known Limitations" section of the DMTF's ASF Standard!
2. Sensors: ASF Sensors vs. Legacy Sensors
   • Sensors are used in our (yours :)) platforms in order to send special alerts about different aspects of the system. Equipment (such as memory or processor) problems or temperature changes trigger an alert that is sent to the IT Manager (for example).
   • The sensors used regularly are normally called "Legacy Sensors", and their support is present in both ASF and Intel AMT.
   • But ASF has also support for more advanced sensors, called "ASF Sensors" (which are an improved system, but I think they're no much used in the market). These sensors have many advantages, like a wider range of values to give alerts for, and a smarter way of defining the alerts to send (the sensor itself is responsible for the whole content of the alert).
   • Intel AMT supports only the regular sensors. So here is one advantage for ASF... as long as you have to use ASF Sensors.

Next time, we'll have a summary of the features present only in Intel AMT.
See you soon!

Posts in the series:
- ASF and Intel AMT - Spot the differences (part 1)
- ASF vs. Intel AMT part 2 - Technology differences
- More technology distinctions - Intel AMT vs. ASF, part 3
- Between Intel AMT and ASF, part 4
- Feature Advantages - Intel AMT and ASF part 5

This is great news for the Intel IT department, for the Intel Engineering departments, for the customers and all people related to our manageability efforts. Having Intel AMT implemented in our IT infrastructure shows our commitment and our satisfaction with this model, so you, customers, should be glad to hear about it :).

This step will also aid us in staying sensitive to the real use cases and pitfalls of such complex systems. We will be developing a product that we will be seeing in use daily, so it will be easier to improve features (and test them too ;)).

I have to confess that it was a very emotive moment, looking at the computer of one of the managers here and seeing inside it the software we validated. Suddenly everything was there, for real, in a real computer on real use. I am already testing things differently -- the vision of the software becomes much more experience-centered. We'll keep improving this applications from version to version!

(Of course, we quickly tried some flows on which we found bugs in the past (on prerelease versions)... just to see that everything was as clean as when we released it ;))

The reasons Intel choose Intel AMT for managing the IT structure were, apart from the obvious out-of-band advantages:

1. Reduced quantity of desk-side visits;
2. Reduced downtime and repair time;
3. More accurate inventory tracking;

Indeed, studies showed that user downtime can be reduced in more than 65 percent in our system, just using Intel AMT functions!

Well... I can't wait until it comes to my turn of exchanging the computer for a Intel vPro one!!

In this post, we'll continue comparing ASF and Intel AMT features, following the principles presented in the previous two posts.

Part Three: Technology Differences (cont.)

1. Alert Subscription: PET and logs
   • Intel AMT uses the well know PET format to send event alerts, just as ASF does.
   • But Intel AMT takes the event alerts one step further: While in ASF you have to decide on one unique destination point for all the events, in Intel AMT you can subscribe up to 16 different destinations -- and define which kind of event alerts should be sent to each subscriber. In this way different entities with different roles can be assigned different events. A person/computer can be in charge of dealing with network problems, while another one receives also security alerts. That's being in control! :)
   • Another important addition to the event manager in Intel AMT is the built-in log of alerts. IT Managers can define the type of alerts that should be stored inside the Intel AMT system itself, and can access this at any time from anywhere.
2. Security: RSP vs. TLS and Kerberos
   • Some people say you can not have too high a security standard.
   • ASF had no security protocol before its revision 2.0. RSP brought security authentication to the ASF standard by using HMAC-SHA1 encryption and a pre-shared key between the managed client and the console.
   • I'll not enter in technical details of how TLS and Kerberos work and how they are more reliable than simple pre-shared keys security, there is plenty of material on that. As much as HMAC is a good encryption method... it is clear that TLS or Kerberos are more advanced security methods than two pre-shared keys.
   • An aspect in which TLS or Kerberos are practical than a special password is that it is integrates with the existing security scene of the corporation -- if the organization uses TLS or Kerberos to secure its network, Intel AMT will fit together.
   • And more, not only Intel AMT can use the same certificates and same servers, but you can merge the password administration of it in the other methods you use to manage other paswords. You can program Intel AMT's login and password easily, what you cannot do so easily in ASF (where you are also forced to a 20 letters long (or 40 hexa. chars, depending on implementation) password). Having to manage additional passwords (at times, different ones for each client) is a hassle you don't have on Intel AMT.
     • Update (20/09): Please don't understand from this section that TLS and Kerberos serve the same purpose -- they are solutions to different aspects of security (TLS is used for encription, kerberos for authentication.) They are together here because both capabilities not present at ASF.
3. Standards
   • The ASF standard was published by the DMTF years ago. An open standard such as this brings many immediate advantages, such as the ability to anyone to build matching applications beforehand. Also, these applications will fit any other ASF implementation, vendor independent.
   • Intel AMT started by creating its own set of functions and features. As there was no progress in the manageability solutions available, there was no standard to follow, so Intel literally 'leaped ahead' ;) and pushed the manageability technology further than what the market was accustomed too.
   • Nowadays, the manageability community sees how far we can go with the new features, and standards are being defined and tested. Intel AMT now follows well known manageability communication standards as WS-Man and DASH, so we can say that Intel AMT 'catched up' in this point were it was lacking.
   • Ajay commented on the standard advantages and disadvantages in this post in our blog.

I hope you enjoyed the dissection of these two important technologies. And the list is not over yet, there's another post on its way!
Stay around...

Posts in the series:
- ASF and Intel AMT - Spot the differences (part 1)
- ASF vs. Intel AMT part 2 - Technology differences
- More technology distinctions - Intel AMT vs. ASF, part 3
- Between Intel AMT and ASF, part 4
- Feature Advantages - Intel AMT and ASF part 5

PS> It would be great to know whether some of you already had/have any experience with ASF manageability, and how do you compare it with Intel AMT. In this way, we'll be able to better focus our conversation.

In the previous part, we talked about the (summarized) history of manageability. Now we will actually start comparing ASF and Intel AMT.

It is somewhat hard to compare Intel AMT and ASF in the technology layer.
Both are solutions to the same problem, but on the other hand Intel AMT has a lot more features than ASF, and you cannot compare the technology layer of a function when it does not even exists in ASF.
So, let's take a look at the features they have in common, and examine them with care from a solution developer point of view:

Part Two: Technology Differences

1. Transport layer protocol: UDP vs. TCP
   • We are starting from the 'low level' networking protocols.
     This may be old news to some, but it may be new for other. And I am aware that some may claim this to be irrelevant. But the point is that ASF specification is built over UDP protocols, while Intel AMT uses TCP for most of his connections -- this has important implications on us, solution developers.
   • This can be significant when building a console to manage computers. If using UDP, the console developer needs to worry about reception and order, as UDP is unreliable and not-ordered. With TCP, the console sends the message once, and the underlying protocol cares of reception and order.
   • During my tests with ASF, it was usual to see remote consoles from different vendors sending the same packet more than once, trying to be sure the packet will get there. Sure, the ASF products have this 'acknowledgement' packet sent that assures the console the command came in correctly. But this 'acknowledgments' can be lost all the same (they're UDP), and if you had to 'acknowledge acknowledgements', the protocol would become infinite.
   • When you are sending a command over SOAP, or over WS-Man, you don't care (that much) about network hazards. It is a reliable protocol, in which the implicit TCP stack will re-transmit the command if it came lacking or was lost.
2. Remote control protocol: RMCP vs. SOAP/WS-Man
   • RMCP is the "Remote Management and Control Protocol" used to send remote control (namely power down, power up and reset) to a client being managed. Apart from the fact that RMCP is a UDP-based protocol (see point 1), a clear disadvantage of the protocol is that it is entirely new and specialized.
   • Communications technology has evolved, and Web Services were invented as an all-around technique designed to support "interoperable Machine to Machine interaction over a network". If you are communicting between computers remotely, it is likely that you are dong it over Web Services.
   • In order to build an application that connects using SOAP, you don't need to iplement an obscure new protocol such as RMCP (or the more complex RSP), you just use popular Web Service libraries with SOAP or WS-Man.
3. Remote booting: PXE vs. IDE-R
   • The two technologies above are meant to reboot a specific machine to boot from a remote disk.
   • Arvind defines PXE: "provides a basic network mechanism for BIOS to discover a PXE server on the network which can then be used to get additional information about image to download." But PXE is old (almost a decade), is not secure, reliable or even routable over different subnets.
   • IDE-R (IDE Redirection), on the other hand, can be secured (with TLS, for example), works on complex corporate network and subnets, and escalates well.
   • You can read Arvind's discussion on the drawbacks of PXE, and Ylian's thorough technology comparison. Also, there's an interesting comparison by Altiris of the two technologies here (notice how many workarounds they had to add to their management console software in order to keep PXE viable...).
   • Note 1: The miraculous surviving of PXE technologies for over 10 years is a distinct proof of the market interest/need in this feature. Hopefully Intel AMT's IDE-R can answer this need in a better way.
   • Note 2: If you still want to use PXE, in order not to throw away that PXE Boot Server ;), Intel vPro still offers PXE capabilities* (*depends on vendor BIOS implementation).

Stay with us for the next parts...

Posts in the series:
- ASF and Intel AMT - Spot the differences (part 1)
- ASF vs. Intel AMT part 2 - Technology differences
- More technology distinctions - Intel AMT vs. ASF, part 3
- Between Intel AMT and ASF, part 4
- Feature Advantages - Intel AMT and ASF part 5

PS> It would be great to know whether some of you already had/have any experience with ASF manageability, and how do you compare it with Intel AMT. In this way, we'll be able to better focus our conversation.

After my suggestion of a "comparison between different manageability products" in my previous post, I was actually asked to do so - it seems to answer a widespread question.

We'll start by focusing in the differences/similarities between ASF and Intel AMT, trying to explain features as well as technical differences.

First, my very own ASF background: Before validating Intel AMT technologies, I worked for about two years validating ASF technologies, both in workstation and in server platform. That's why I hope to be able to address the technical differences of both manageability solutions.

Part one: The history (covers widespread OOB technologies only).

• In the beginning, there was confusion... :)
  The IT managers of the world had no way to manage computers remotely...

• That's until Wake on LAN (WoL) appeared. WoL came in the middle of the 90's (1997), developed by Intel and IBM engineers, and it let administrators to remotely turn computers on. The technology was bundled (under the Wired for Management name) with a protocol called PXE, which gave the option of booting from a remote disk.
  But that was it -- all you could do was turn on a machine and hope everything was working fine until the OS could load some software-based solution.
• An attempt of improving these technologies was made at 1999, when Intel and IBM defined "Alert-on-LAN-2". This set of technologies presented very important features (alerting in addition to remote control and remote boot), but the technology didn't became so popular or widespread...

• Thus, in 2001 ASF was a welcomed evolution, as it added necessary features like event alerts and remote control commands (the ability to turn off or reset a computer, not only turning it on). ASF is an open standard by the DMTF, and the last revision of it (where security protocols were added) was in 2003.

• The next major progress in OOB manageability was Intel AMT. This was a much needed revision of the ASF standard, adding many features requested by the market. In fact, it is so literally an evolution that many of the persons involved in designing/programming the Intel AMT features were before designers/programmers of ASF :) (pay attention to the active role of Intel in designing and spreading these remote management solutions).

In the next parts we'll discuss/compare the different features and the technology used in the features that are common between Intel AMT and ASF.

Stay tuned!

Posts in the series:
- ASF and Intel AMT - Spot the differences (part 1)
- ASF vs. Intel AMT part 2 - Technology differences
- More technology distinctions - Intel AMT vs. ASF, part 3
- Between Intel AMT and ASF, part 4
- Feature Advantages - Intel AMT and ASF part 5

PS> It would be great to know whether some of you already had/have any experience with ASF manageability, and how do you compare it with Intel AMT. In this way, we'll be able to better focus our conversation.

I am one of a big group of Software Testing Engineers that test the Intel AMT technology.
If you are thinking: "Uh-oh! If they have a testing department, that means they have faulty and buggy software!", then let me reassure you and explain our job better.
First, the definition: We don't test because the product is buggy; we test in order to ensure it isn't. Changes the whole concept now, right? Look at the testing team as the proof of our commitment for quality.

Testing is a very important part in a software product lifecycle. Our Testing Team is involved from the early stages of requirements and prototyping -- this helps us making sure that we not only are doing the job right, but we are doing the right job.
The advantage of having a department specialized in tests and which is not an active part in the actual coding is that we are in this way free from assumptions on code and implementation restrictions.

My future posts will be focused on interesting development and validation topics regarding Intel AMT, like how such a complex system is tested, or a comparison between different manageability products.
Meanwhile, please let me know in the comments a bit about you, reader. What you do, what do you expect from Intel AMT, and what experience have you had with Testing teams.

Nice to meet you! :)