Checking Your Main BIOS Version

As some of you may know, I spent four years in the U.S. Marine Corps back during the Reagan administration. I started out as an 0311 Basic Rifleman (aka Grunt) for a couple of years, and then became an 1811 Armor Crewman, ending up as a Tank Commander of an M60A1 Rise/Passive main battle tank. I got out of the Marines as an E-5 Sergeant, and went to college at U.C. Irvine, and the rest is rather ancient history. You might be wondering what my military experience has to do with SQL Server and the importance of checking your main BIOS?

Well, here is the relationship (at least in my mind). It comes from attention to detail, which is a very important characteristic for a good DBA. One thing that the Marines liked to do periodically was have a formal personnel inspection of a everyone in a small unit, such as a Rifle platoon. Depending on who the inspecting officer was, this might cause anywhere from hours to weeks of preparation by the members of the unit, doing things like thoroughly cleaning your weapon, cleaning and properly marking all of the items of your uniform and web gear, clipping off loose threads on your uniform (known as “Irish pennants” or “Russian ropes”), and all manner of other little things to get completely “squared away” in the Marine Corps vernacular.  After all of this extensive preparation, the formal inspection would finally occur, often taking several hours for a platoon of 42 people.

Everyone in the platoon would be standing at attention in formation, and the inspecting officer would go one by one, down the ranks of the formation doing his formal inspection. He would turn to face you, and you would have to do an Inspection Arms movement with your rifle for him. After you were done, he would slap the weapon out of your hands, and start looking at it in excruciating detail, while asking you questions like “What is the maximum effective range of this weapon?”, or “Who is your regimental commander?”. Woe to the Marine who did not know the answer to these questions! One thing that I saw a number of times during these types of inspections was when the inspecting officer found some obvious problem with the Marine that he was inspecting, something that was literally in plain view, but had been missed by everyone during all of the preparations and pre-inspections. For example, maybe one of the buttons on a pocket flap of your utilities was not buttoned, or maybe there was a long, loose thread on  a seam of one of your chest pockets. If the inspecting officer found something obvious like this, they would sometimes literally start undressing the Marine, looking for other violations that were sure to be found under the surface!  The inspecting officer’s zeal and attention to detail was always rewarded in a case like this, since if something so obvious was missed, there would be many other things that were wrong, hidden under the surface…

This is where I get back to SQL Server and the importance of doing the obvious things like checking the main BIOS version on your database servers. As I discussed recently, it is pretty easy and pretty important to periodically check the version of your main system BIOS for a machine, using tools like msinfo32.exe, CPU-Z, or management tools like Dell Open Systems Management Administrator (OMSA).  The large system vendors like Dell, HP, IBM, etc. will release new versions of the main system BIOS to fix problems that are discovered with that model server.  As a DBA, I think it is very important to keep tabs on this, even if someone else (such as a systems administrator) is actually responsible for maintaining your database servers. One reason is that if you ever have a hardware problem and you call your system vendor for support, they are going to want you to run a utility that will check the versions of your main system BIOS, any other firmware, and your hardware driver versions. If any of these are out of date, they will want you to update them. If there was a hardware problem that caused an outage, the fact that the hardware had old versions of the main BIOS or other firmware will also tend to focus some blame on whoever was supposed to maintain that hardware.

The other reason why this is important is that it shows that someone in your organization (hopefully you) is paying attention to the obvious details. Almost invariably, when I have looked at someone’s system after they have asked me for help, and I find that they are running a main system BIOS that is multiple versions out of date, that means that I will find numerous other problems with their system and database configuration. It is really a pretty reliable predictor of trouble! 

There are several reasons why people don’t maintain their database hardware properly. First, they may not know any better, since they may not know that you actually have to maintain this type of thing. Second, they may be afraid of breaking something. What happens if you update your system BIOS, and then the server refuses to POST or boot afterwards? Third, they may just be lazy. After all the server seems to be running fine, why should I stick my neck out and have to flash the BIOS at 11PM on Friday night? Fourth, they may not have a good, tested HA solution in place for that database server, so doing something like flashing the BIOS will cause a relatively long outage because of a reboot. Perhaps they are unsure whether their applications will continue to work after failing over their database(s) to a mirror instance.

I would argue that a good DBA will find a way around all of these objections and fears, and put a regular maintenance program into place for your database servers. This forces you to think about your HA solution and to actually test it on a fairly regular basis. If you have an HA technology in place, such as failover clustering, database mirroring, or SQL Server 2012 AlwaysOn, you can do rolling upgrades to minimize your downtime during maintenance. With some testing and planning, you can combine BIOS updates, firmware updates, Windows Updates, and SQL Server Updates all in one maintenance window with minimal downtime. Planning this effort and then actually doing it on a regular basis, forces you and your organization to exercise your HA solution while you keep your systems up to date (which I think will reduce the number of problems you run in to in the future).  This is far better than just avoiding the whole issue, and leaving your database servers running the original versions of everything on a permanent basis. Don’t be afraid!

About these ads
This entry was posted in Computer Hardware, Dell, Laptops and tagged , , . Bookmark the permalink.

11 Responses to Checking Your Main BIOS Version

  1. Perry Whittle says:

    Hi
    Sorry but I’m going to have to disagree on this, quite apart from the fact most organisations’ change control board would veto this and would require a VERY strong reason why it should be applied. As a DBA if you were to announce this is going to all servers you’d probably get your pass taken away and marched out of the building lol.

    The system BIOS will not generally have too much affect on the sever itself, maybe the keyboard doesn’t work correctly or the real time clock is flaky, who cares everybody accesses the server via RDP and the server takes it time from the AD PDC emulator. There are real risks associated with flashing the system BIOS and in the worse case scenario will leave you with a large expensive door stop. You may increase support for memory or for a CPU type but then you may be removing support for a CPU type, the same CPU’s that happen to be sitting on the main board ;-)

    The RAiD controller BIOS on the other hand has a lot more influence, this directly controls your arrays attached to the controller, even so firmware updates here should only be used to correct an issue or bug you are experiencing.

    In all my years working with Dell, HP, IBM and some other obscure brands of servers I’ve very rarely had to touch the system BIOS, array controllers yes but not the system.

    I’m all for keeping systems updated but there is generally a good case for “if it ain’t broke, don’t fix it” when it comes to BIOS systems

    Regards Perry

  2. Glenn Berry says:

    There is definitely a risk/reward ratio to making any kind of update to a server. With newer processors that have integrated memory controllers, updating the main system BIOS can be pretty important. Witness the recent Urgent update for the Dell R810, R910 and M810 series to fix a memory controller issue.

    I just hate to see people in a situation or mindset where they are afraid to touch their servers or do any kind of maintenance work for the life of the system. I see far too many servers running on the original version of the main BIOS, original versions of the firmware for the RAID controllers, NICs, HBAs, etc., and the original RTM version of SQL Server for years after the server was originally deployed.

    Bricking a server from an update is a risk, but it is a very low risk in my experience. If you see an Urgent or Critical update come out from your system vendor, I think you should strongly consider getting it deployed.

    • Perry Whittle says:

      I wouldn’t know, all our kit is HP or IBM for our unix boxes. Keeping HBA drivers up to date is a must. For BIOS systems you have to read carefully what the update brings to the party and make the decision

      Regards Perry

  3. mike vessey says:

    I’m with perry on this. There are so many other things to focus on that if all you have to worry about is your bios revision then you are in DBA heaven.

    the risk/reward ratio for Bios uptdates is so small as to be negligible.

    • Glenn Berry says:

      Checking your BIOS version takes a few minutes per server. Being aware of whether the BIOS (and other firmware and hardware drivers) are out of date, and whether newer versions are considered urgent or critical updates is pretty important, in my opinion. The main point of my post is that you should be thinking about about this as part of your ongoing maintenance of the entire server. You should have the architecture, infrastructure, and policies in place so you can can do regular, rolling maintenance of your database servers, whether it involves Windows Updates, SQL Server Updates, or BIOS, firmware, and driver updates.

      Being a good DBA means that you have worry about a lot of different things. Being aware of and maintaining your hardware is not that difficult.

  4. Perry Whittle says:

    Hi

    for an easy way to get your BIOS version without using utils, use this handy VB script

    strComputer = “.”
    Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\CIMV2″)
    Set colItems = objWMIService.ExecQuery( _
    “SELECT * FROM Win32_BIOS”,,48)
    For Each objItem in colItems
    Wscript.Echo “Asset Tag ID for computer ‘” & strComputer & _
    “‘ = ” & objItem.SerialNumber & vbcrlf & _
    “Bios version: ” & objItem.SMBIOSBIOSVERSION
    Next

    Regards Perry

  5. Mark Walker says:

    The various firmwares are the mortar of the foundation of your systems. Ignore it at your own peril.
    If you’ve never been surprised by the scale of the impact of a glich that hadn’t bit you yet, you have an enlightening experience in your future.
    That said, there are cases where an update causes more trouble than it would have fixed. Always have a backout scenario at the ready.

  6. Scott R. says:

    Great post, Glenn!

    As a follow-up to Perry’s earlier reply of a VBScript BIOS display script, below is a similar PowerShell script (with a formatted BIOS release date, and can process local or remote systems – if you have the needed permissions):

    If (! $args[0])
    { $SystemName = $env:COMPUTERNAME }
    Else
    { $SystemName = $args[0] }

    Get-WMIObject -Query “Select * From Win32_BIOS” -ComputerName $SystemName |

    Format-Table `
    @{Label=”System”; Expression={$SystemName}}, `
    @{Label=”Serial #”; Expression={$_.SerialNumber}}, `
    @{Label=”BIOS Release”; Expression={“{0:ddd. MM/dd/yyyy}” -f([System.Management.ManagementDateTimeconverter]::ToDateTime($_.ReleaseDate))}}, `
    @{Label=”BIOS Version”; Expression={$_.SMBIOSBIOSVersion.Trim()}}, `
    @{Label=”Vendor / Model”; Expression={$_.Manufacturer.Trim() + ” ” + $_.Name.Trim()}} `
    -AutoSize

    Improved awareness and visibility of system configuration facts are positive things (the technical side), even if you choose not to take action on issues with those facts (better to be informed than surprised). Glenn’s DMV scripts are an excellent example of tools for greater visibility. Your ability to act on these facts (and especially identified exceptions) may be limited by other factors (policy, risk mitigation / avoidance, politics, etc.), but (as Glenn points out) shouldn’t be based on lack of information or fear of change.

    At prior engagements, I would use the WMI OS install date and the BIOS last updated date for a given system to get a rough indication of the age of the physical server (that I did not know a detailed history), based on the premise that many servers have an OS installed once and are rarely upgraded / reinstalled, and that the system BIOS firmware is rarely upgraded from what was delivered at purchase (despite the possible benefits of upgrades). A sad but often true situation.

    Scott R.

    • Perry Whittle says:

      Scott

      the powershell script merely executes the same query as the VB script. It’s taking the same journey just using a different vehicle to get there ;-)

      The point i make is the system BIOS will not generally have too much affect on the running of the server (unless it’s a Dell of course :P ). Also, things like BIOS version checking\updating will be down to the Windows administrators in most organisations.

      Regards Perry

  7. Scott R. says:

    Glenn,

    Your M60 tank experience in the Marines mentioned in your post brought back different memories for me. While I was not a tanker like you, I worked for a company that created the cast hull and turret for the M60 in their foundry – pretty big monsters! I believe the M60 was the last US tank to use foundry-based castings for the main tank body, as the follow-up M1 Abrams is of fabricated (and not cast) construction.

    In Bob Hope’s words: “Thanks for the memories!”

    Semper Fi!

    Scott R.

    • Glenn Berry says:

      Hey Scott,

      My tank was an M60A1 Rise\Passive, so the turrent shape was different than the older M60 tanks (it was more pointed in the front). You probably know that since you worked where they were cast…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s