How to compare SMC and EFI versions against Apple's site

[RickNTX]

Hi,

I'm trying to figure out the best way to script out via an attribute possibly to compare what our machines are running for EFI and SMC and bounce it up against Apple's website with all of the data listed.

Initially, I figured I could get the model details from a grep of the system_profiler SPHardwareDataType to get the model, SMC and firmware / EFI version. Then take this data and bounce it against Apple's website with this listed via a curl.

To get the data: system_profiler SPHardwareDataType | grep "Model Identifier" | awk '{print $3}'

To store the existing versions:
system_profiler SPHardwareDataType | grep "SMC Version (system):" | awk '{print $4}'
system_profiler SPHardwareDataType | grep "Boot ROM Version:" | awk '{print $4}'

Getting the data for the machine is easy, but trying to grab the data from Apple's table isn't panning out as easy. Apple's site is at: http://support.apple.com/kb/ht1237 which has a table of what is current for each model. I was thinking something along the lines of a silent curl.. e.g. curl -s http://support.apple.com/kb/ht1237 | grep "MacBookPro11,1" and trim from there...etc..

Anyone have or know of a script that will do this already?

Occasionally I get machines that miss the software update or haven't applied it yet.. I was thinking I could set a field/attribute to make it stand out on a report easily..

[sean]

Much easier to just run a check against software update and then check for EFI or SMC updates in the list:

softwareupdate -l

Rather than include softwareupdate in an extension attribute, I'd suggest doing a periodic check (eg. weekly or daily) and writing the result to a file and have an extension attribute to read that file.

[chris_kemp]

The problem here is that, according to the KB article, these updates don't always show up in Software Update.

Using your search, you can pull enough of the table reference this way (pulling 3 lines prior and 8 lines after the model identifier):

curl -s http://support.apple.com/kb/ht1237 | grep -B 3 -A 8 "MacBookPro6,2"

gives you this:

"MacBookPro6,2" </tr> <tr> <td>MacBook Pro (15-inch, Mid 2010)</td> <td>MacBookPro6,2</td> <td><a href="http://support.apple.com/kb/DL1492">MBP61.0057.B0F (EFI 2.6)</a></td> <td><a href="http://support.apple.com/kb/DL1731">1.58f17 (SMC 1.7)</a></td> </tr> <tr> <td>MacBook Pro (17-inch, Mid 2010)</td> <td>MacBookPro6,1</td> <td><a href="http://support.apple.com/kb/DL1492">MBP61.0057.B0F (EFI 2.6)</a></td> <td><a href="http://support.apple.com/kb/DL1731">1.57f18 (SMC 1.7)</a></td>

(The MacBook 11,1 does not have an SMC version entry; however, going to the 8th line after returns the </td> tag for that entry, so you should be safe from spillover to the next record.)

[mm2270]

So, the issue with that page is that, somewhere along the line in 2011, Apple apparently went partially insane and starting re-using some model identifiers. If you look close at the 2011 MacBook Pro section, you'll see quite a few duplicate model identifiers, which are actually different Macs. For example, the 13-inch MBP Early 2011 and the 15-inch Late 2011 MBP share the same MacBookPro8,1 identifier, In the table, the SMC version for each Mac is different, so how then do you try to determine which one is the right one if going off the model id? Its going to be a pain. If you happen to be lucky enough to be dealing with only 2012 and newer models, it appears Apple regained some sanity and stopped that nonsense of reusing model identifier. The entire purpose of the model ID is that it should be unique for that model and not re-used, so whoever at Apple had that brilliant idea is hopefully not there anymore.

To make matters worse, my Mac, which happens to be that MacBookPro8,1 model, isn't even listed correctly. In Apple's chart, it lists it as an Early 2011 model, but when I look this up on my Mac under the System Information app, it clearly shows as a Late 2011 model, so something's amiss there. I'm curious how many other models are listed incorrectly? I'm just not sure how much I'd rely on that page.