none
Detect EFI or BIOS with powershell

    Question

  • Is there any way to detect whether a machine is UEFI or BIOS with a powershell script (without using third party tools)?

    I would like to use this in a Dism script to apply images and build disk partitions based on the type of machine.


    Yeah Buddy!

    Friday, March 8, 2013 8:28 PM

Answers

  • Get UEFI information with PowerSHell.

    http://technet.microsoft.com/en-us/library/jj603039.aspx

    If CPT then UEFI is undetectable until you alter the settings to disable CPT.  This can only be done manually at the keyboard or via the manufacturers utilities.  WMI cannot detect this.  You can check the procesor to see if it supports UEFI by looking at the Model number. 

    I believe that, if CPT is disabled, you will not detect a BIOS on UEFI machines.  On BIOS machines (MBR) the BIOS will always be present.


    ¯\_(ツ)_/¯

    • Marked as answer by IamMred Friday, May 17, 2013 2:09 AM
    Saturday, March 9, 2013 12:07 AM

All replies

  • Get UEFI information with PowerSHell.

    http://technet.microsoft.com/en-us/library/jj603039.aspx

    If CPT then UEFI is undetectable until you alter the settings to disable CPT.  This can only be done manually at the keyboard or via the manufacturers utilities.  WMI cannot detect this.  You can check the procesor to see if it supports UEFI by looking at the Model number. 

    I believe that, if CPT is disabled, you will not detect a BIOS on UEFI machines.  On BIOS machines (MBR) the BIOS will always be present.


    ¯\_(ツ)_/¯

    • Marked as answer by IamMred Friday, May 17, 2013 2:09 AM
    Saturday, March 9, 2013 12:07 AM
  • If you are running Windows 8 have a look at this

    http://www.verboon.info/2013/01/how-to-check-the-status-of-bios-uefi-secure-boot-with-powershell/

    and here's another method using a DLL provided by MDT and calling its function

    http://www.verboon.info/2012/12/exploring-the-functions-included-in-microsoft-bdd-utility-dll/


    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.


    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or MVPs.

    Twitter: @alexverboon | Blog: Anything About IT

    Saturday, November 23, 2013 4:51 PM
  • Alex - if it is Win 8 it is UEFI except on RT.

    The one article is only showing how to determine secure boot.

    If we do have MDT set up then the DLL will be available.  It is designed to work on WIndows 8 and later.  I am pretty sure itwill not on pre-win8 systems.

    Have you tried it?


    ¯\_(ツ)_/¯

    Saturday, November 23, 2013 5:01 PM
  • It seems that the DLL is available for Vista and later systems.  I suspect that it will return correctly on XP and WS2003 but those systems use an older UEFI with 64 bit versions.

    It is interesting that the UEFI console was created way back with DEC VAX VMS.  It ported to Unix and ahs evolved to UEFI.I forget what the original name was.  I think it was just boot console.


    ¯\_(ツ)_/¯

    Saturday, November 23, 2013 5:09 PM
  • I'm running Windows 8 on BIOS, not UEFI.

    Saturday, November 23, 2013 5:09 PM
  • I'm running Windows 8 on BIOS, not UEFI.

    Are you really running 32 bit Windows 8?


    ¯\_(ツ)_/¯

    Saturday, November 23, 2013 5:34 PM
  • Here is the background on EFI/UEFI: http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

    What is missing tis the DECpiece.  DEC developed the 64 bit Alpha processor alomng with help from Intel.  Intel manufactured the processor under contract to DEC.  DEC devised a BIOS-like environment that was intended to allow Alpha Unix, Windows NT and DEC VMS to all boot off of the same hardware.  I was able to run all three on the same quad processor  16 GB dual channel memory RAID 5 6Tb system based on Alpha Processor architecture.

    This system was a monster.  It took up a whole 12 by 24 foot room and required a 20 ton air conditioner.  Today we can build this on the desktop. DEC was bought out by HP and HP sold the rights to the processor and the pre-EFI BIOS to Intel.  Intel then used the EFI on  its early 64 bit Windows systems.  Intel released the EFI and UEFI BIOS to the industry as a standard. All 64 bit machines use UEFI today.

    A 64 bit hardware system can run  32 bit OS and UEFI can be set to look exactly like a BIOS from the time you turn on the machine.  Most users of 32 bit on 64 bit hardware do not know they have a UEFI BIOS and it cannot be detected from the OS unless the vendor supplies a utility and a BIOS extension to do this.  I have never seen or heard of this being done.

    In a pre-boot environment like Windows PE we can detect the hardware with the help of the DLL mentioned as long as we are using the 64 bit version of the PE although I expect it is possible to create a DLL in32 bits that can suspend PE and inject a 64 bit native process.  I am only guessing on this.

    If you have either architecture it would be interesting to know how the DLL reports.  I do not have any 32bit Windows 8 boxes and only two Windows 7 that are in production.  I have no 32 bit test machines left that are currently running.  If you have one of these environments then try it and post the results.

    I will try it on the WIN7 and other 64 bit systems and maybe build a 32 bit PE and test.


    ¯\_(ツ)_/¯


    • Edited by jrv Saturday, November 23, 2013 6:23 PM
    Saturday, November 23, 2013 6:22 PM
  • Yep, doesn't matter.

    Both 32-bit and 64-bit run on BIOS.

    Saturday, November 23, 2013 8:06 PM
  • Yep, doesn't matter.

    Both 32-bit and 64-bit run on BIOS.

    How do you know that?  Both will show BIOS when booting even with EFI.  EFI emulates a BIOS.  My WIn7 says Phoenix BIOS but hidden in the text is the EFI indicator.  The EFI support is writtenby Phoenix and is displayed as a Phoenix Bios on boot..

    What architecture is your machine?  Not the OS but the physical architecture?  What processor?


    ¯\_(ツ)_/¯


    • Edited by jrv Saturday, November 23, 2013 8:19 PM
    Saturday, November 23, 2013 8:16 PM
  • I should also note that old AMD 64 bit systems booted at 32 bits and the  BIOS then switched them to 64 bits.  The BIOS itself in that case has to be rewritten for 64 bits.  AMD switched to UEFI only soon after that.  I don't think they currently make any non-UEFI systems but, who knows, they may still be building with the old processors.  The rest of the industry is UEFI only on 64.  MIrosoft does not produce an server products for 32 bits.  If you want WS2008(x86) you need to purchase WS2008R2 and you get down grade rights.  YOu can no longer buy 32 bit server grade hardware from any vendor.  SOme may have a few s32 bit systems left on the shelf.

    I am pretty sure that after Windows 8, Microsoft will not be making any 32 bit OSs outside of Windows embedded and Windows mobile systems.


    ¯\_(ツ)_/¯

    Saturday, November 23, 2013 8:41 PM
  • It's

    HP Compaq 6730b
    Intel Core2 Duo CPU P8400

    The original OS was Vista.

    Saturday, November 23, 2013 8:47 PM
  • Read it and weep:

    HP Compaq 6730b Notebook PC and HP Compaq 6530b Notebook PC System BIOS Update Version F.0A -

    ... Version: 1 HP Compaq 6730b Notebook PC and HP Compaq 6530b Notebook PC System BIOS...Instrumentation (WMI) support for the F10 UEFI boot, TPM enablement, BIOS...

    Notice the UEFI boot in the BIOS update description. TPM requires UEFI. It will say BIOS when booted. On HP I believe you have to go into the BIOS to enable access the the BIOS console.

    All versions of Windows think all BIOS are IBMPC-BIOS.  The UEFI is always s hidden.  ON HP WMI an tell you if the BIOS is UEFI.  I can see it on my HP desktop.  Mt Acer laptop also allows WMI to show the UEFI.  All systems do not come with the vendor WMI extensions to allow this. The laptop you have seems to say it is WMI enabled fro UEFI discovery.


    ¯\_(ツ)_/¯

    Saturday, November 23, 2013 9:06 PM
  • This is NOT an answer, and forgive me, but it's arrogant for an MSFT employee to mark a clearly wrong answer as correct.

    The question was NOT "is this Secure Boot enabled?"  It was "is this firmware UEFI or BIOS?

    Yes, SB requires UEFI, but UEFI most definitely does NOT imply Secure Boot.  It's a little like someone asking, "how do I know if that animal is a bird," and being handed a guide to identifying hawks.


    Mark.  Can you fix the dinosaur extinction?  You got this one but can you help us with the bigger picture.  We need Dino back.

    \_(ツ)_/

    • Proposed as answer by bm97ppc Saturday, November 25, 2017 10:42 AM
    Sunday, May 8, 2016 12:22 AM
  • Okay, here's how to do the detection on Windows 8 or later.

    MSINFO32 detects BIOS/UEFI and whether or not Secure Boot is enabled.  Watching it with Procmon shows how it does it.

    1) check for the Registry key HKLM\System\CurrentControlSet\Control\SecureBoot\State

    If it does not exist, then the system booted via BIOS.

    2) Otherwise, look for the REG_DWORD entry "UEFISecureBootEnabled"

    If it's 0, UEFI boot but Secure Boot is not enabled.

    If it's 1, UEFI boot and Secure Boot is enabled.

    So... this one-liner will produce either "BIOS" or "UEFI:"

    if ((Get-ItemProperty HKLM:\System\CurrentControlSet\control\SecureBoot\State -ErrorAction SilentlyContinue) -eq $null ) {"BIOS"} else {"UEFI"}


    Sunday, May 8, 2016 3:18 PM
  • Ok but I do not think that works in 2013.  Also a UEFI system can be set to boot in legacy BIOS mode and the UEFI won't be detectable.

    The registry detection is useful when the system is post Vista or if it has the later BIOS updates. It would be useful to know what version of OS added the registry elements for secure boot lthus my guess is that all Win7 and later systems have the updates as well as WS2008R2 and later,


    \_(ツ)_/

    Sunday, May 8, 2016 4:18 PM
  • Sorry, but what do you mean by "in 2013?" UEFI was basically irrelevant for Windows 7.  Anyone doing anything with UEFI would be doing it in Windows 8, and the Registry entry existed as of then.  MSINFO32 did not attempt to report boot type.

    And actually given that WMF 3 (which ran on Windows 7) shipped in the previous September, the *-SecureEUFI cmdlets could have done the same things, although they then did -- and irritatingly still do -- just spit out red text if you run them on a BIOS system, so one could have adopted the same approach as I did.  I just figured that the coverage on Get-ItemProperty would be more widespread.

    Sunday, May 8, 2016 8:57 PM
  • Sorry, but what do you mean by "in 2013?" UEFI was basically irrelevant for Windows 7.  Anyone doing anything with UEFI would be doing it in Windows 8, and the Registry entry existed as of then.  MSINFO32 did not attempt to report boot type.

    And actually given that WMF 3 (which ran on Windows 7) shipped in the previous September, the *-SecureEUFI cmdlets could have done the same things, although they then did -- and irritatingly still do -- just spit out red text if you run them on a BIOS system, so one could have adopted the same approach as I did.  I just figured that the coverage on Get-ItemProperty would be more widespread.

    My 64 bit windows 7 systems all have UEFI BIOS.  32 bit Win7 would  not have UEFI.  UEFI was first introduced for 64 bit architectures as an improvement on the DEC MicroVAX architecture in about 1986 or so.  DC had the boot console which can be dynamically configured at boot.  UEFI on Windows does not allow this but some Unix boxes do.  I believe Sun Unix does allow UEFI dynamic boot from the console.

    DEC ARC BIOS was made a standard of the industry at some point.  EFI was the first implementation by Intel for the Itanium processors which were specifically delivered to unify DEC Alpha processors with HP RISC Unix architectures and to also sync with Windows and Mac architectures.  EFI was superseded by UEFI in about 2005.

    If you research the Intel and HP hardware sites you will find more background.

    Here is a good resources for all but the history details: http://www.uefi.org/


    \_(ツ)_/


    • Edited by jrv Sunday, May 8, 2016 9:26 PM
    Sunday, May 8, 2016 9:25 PM
  • Thanks, I knew that -- I miss my Alpha and I wish Intel's Itanium fiasco hadn't sucked the oxygen out of the "next-gen processors" ecosystem, although it's nice that EFI came out of it.  As an old DEC guy, you must share my enthusiasm for PowerShell -- thank heavens MS hired Snover.

    As we see here, it's damned irritating that Windows is still in a situation where deriving important configuration info relies upon guesses and heuristics instead of a straightforward CIM call.

    Sunday, May 8, 2016 9:42 PM
  • CIM supports access to and configuration of UEFI as long as vendor supplies support.  Remember that UEFI is a specification for a BIOS.  Also remember that Alpha ARC is a microcomputer based BIOS processor/system monitor.  Today we replace that with ILO technologies which are starting to become standard motherboard chips or co=processor boards.

    Here is MS take on UEFI support in Windows versions:

    Windows® 7, Windows Vista® with Service Pack 1 (SP1), Windows Server® 2008 R2 and Windows Server® 2008

    • Support UEFI 2.0 or later on 64-bit systems. They also support BIOS-based PCs, and UEFI-based PCs running in legacy BIOS-compatibility mode.
    • Support on Class 2 systems running in legacy BIOS-compatibility mode by using a CSM, so they can use the legacy BIOS INT10 features.
    • Are not supported on Class 3 systems, because these operating systems assume the presence of legacy BIOS INT10 support in the firmware, which is not available in a Class-3 UEFI implementation.
    • Windows Server® 2008 R2 and Windows Server® 2008 also support EFI 1.10 on Itanium-based systems.

    https://technet.microsoft.com/en-us/library/hh824898.aspx

    Integrity systems use a UEFI based boot console in place of ARC that is dubbed BMC and includes and MP of management processor similar to ARC.

    Remember that NT is a reasonable clone ad upgrade to VMS 5.2.  ASTs are IPCs in NT. Most of the API is a cleanup of the VMS API.  What we lost was DCL  thanks to IBM and the damn CMD console.  PowerShell has more than compensated.


    \_(ツ)_/

    Sunday, May 8, 2016 9:59 PM
  • Thanks, I knew that -- I miss my Alpha and I wish Intel's Itanium fiasco hadn't sucked the oxygen out of the "next-gen processors" ecosystem, although it's nice that EFI came out of it.  

    As for NextGen. Well. RISC was all the hot issue. DEC,HP and IBM dumped a fortune into a RISC solution. In the end HP bought up all of the failed solutions and traded them to Intl for the Itanium. It works for VMS but Unix and Windows have all stuck with CISC and have sh0own that it is easier to manage. Now we are looking at networked cores and NUMA for super computers. One day...maybe...we will take the Quantum leap.


    \_(ツ)_/

    Sunday, May 8, 2016 10:10 PM
  • VISTA ran UEFI!  Sonuvabitch.  Never knew that.  So are you saying that there's probably a CIM call somewhere that could detect UEFI?  That would be very interesting.  The problem always is that the WMI/CIM stuff doesn't offer 100 percent coverage.

    Now I'm going to have to pull out my Vista install discs and try to get them to run UEFI. :)

    Sunday, May 8, 2016 11:41 PM
  • CIM can do BCDEdits.  I suspect it can detect UEFI mode BIOS versus legacy.  The registry entries probably only exist when the UEFI support for Secure BIOS support. This would be a good point to research. I have not yet seen anything specific on this.

    \_(ツ)_/

    Sunday, May 8, 2016 11:53 PM
  • BCDEDit is likely the best way to detect UEFI:

    https://technet.microsoft.com/en-us/library/ee221031%28v=ws.10%29.aspx?f=255&MSPPError=-2147217396

    PS > bcdedit
    
    Windows Boot Manager
    --------------------
    identifier              {bootmgr}
    device                  partition=\Device\HarddiskVolume1
    path                    \EFI\Microsoft\Boot\bootmgfw.efi
    description             Windows Boot Manager
    locale                  en-US
    inherit                 {globalsettings}
    default                 {current}
    resumeobject            {8171f355-fbfd-11e5-a756-df3f3ed0f25e}
    displayorder            {current}
    toolsdisplayorder       {memdiag}
    timeout                 30
    
    Windows Boot Loader
    -------------------
    identifier              {current}
    device                  partition=C:
    path                    \windows\system32\winload.efi
    description             Windows 10
    locale                  en-US
    inherit                 {bootloadersettings}
    recoverysequence        {6c851fc0-fc04-11e5-b910-4845203dd7b2}
    recoveryenabled         Yes
    isolatedcontext         Yes
    allowedinmemorysettings 0x15000075
    osdevice                partition=C:
    systemroot              \windows
    resumeobject            {8171f355-fbfd-11e5-a756-df3f3ed0f25e}
    nx                      OptIn
    bootmenupolicy          Standard


    \_(ツ)_/

    Sunday, May 8, 2016 11:58 PM
  • Oh, that is COOL!  I live in bcdedit and I never noticed that -- winload.efi versus winload.exe.  That is VERY cool. You probably don't want to use your name on a public forum but I'm writing some pieces on UEFI and I'd like to credit you for that tip.  If it's all right to identify you in an article, please send the name to me at my email, which my firstname "at" lastname.com.

    Again, very nice.  Thanks!

    Monday, May 9, 2016 7:45 PM
  • Sounds useful.  Good luck.

    \_(ツ)_/

    Monday, May 9, 2016 7:49 PM
  • OP post is pretty old but I was looking to do a similar thing and I couldn't find a good Posh Example.

    I don't know if you're trying to do this with winPE4 but I had to put this in place where I work because we are limited to winpe4 and not using MDT... don't ask.  The code below assumes that you can run powershell 3/.net4 in Winpe and you have the Microsoft.BDD.Utility.dll (from mdtdeploymentshare\Tools\$systemarchitecture) in the same directory as the script. 

    Posh code

    & $env:systemroot\system32\regsvr32.exe $PSScriptRoot\Microsoft.BDD.Utility.dll /s

    $a = New-Object -ComObject Microsoft.BDD.Utility

    write-output "Machine supports UEFI = $($a.IsUEFI)"

    # do something with the output, write an env variable, write output to a file or reg key for later use..
    #
    & $env:systemroot\system32\regsvr32.exe $PSScriptRoot\Microsoft.BDD.Utility.dll /u /s


    -----

    Anything later than Winpe5.1 (i think) should discover what mode it was booted in and write to the registry:

    Posh code

    $isuefi = (Get-ItemProperty -Path HKLM:\System\CurrentControlSet\Control).PEFirmwareType -eq 2


    • Edited by nebule-nz Thursday, June 2, 2016 6:48 AM
    Wednesday, June 1, 2016 8:11 PM
  • Here is an even easier method:

    Get-WmiObject  -query 'Select * from Win32_DiskPartition Where Type = "GPT: System"'


    \_(ツ)_/

    Wednesday, June 1, 2016 8:25 PM
  • For Windows 8 and later we can use:

    Confirm-SecureBootUEFI

    https://technet.microsoft.com/en-us/library/jj603041%28v=wps.630%29.aspx?f=255&MSPPError=-2147217396


    \_(ツ)_/

    Wednesday, June 1, 2016 8:27 PM
  • Presumably this wouldn't exist before formatting the disk with GPT (baremetal scenario), this wouldn't serve our purposes as we :

    Boot to Winpe, do some discovery work out whether the machine is in UEFI mode or Bios mode - proceed to setup the disk in GPT or MBR depending on the scenario.  

    I haven't tried testing in winpe4, that cmdlet looks like it was only exposed in windows 8.1 - winpe 5+. 


    • Edited by nebule-nz Wednesday, June 1, 2016 9:16 PM
    Wednesday, June 1, 2016 9:16 PM
  • You can only tell what mode the machine is running in.  If the machine has a UEFI BIOS and it is in use then the boot disk will be GPT.  If you are running on Windows * then the CmdLet will work as noted.

    A non UEFI machine cannot use the UEFI boot manager to know what it is doing.


    \_(ツ)_/

    Wednesday, June 1, 2016 10:33 PM
  • Haven't tested anything other than Winpe4 x64. 

    WMI method doesn't work - query returns nothing. Looking at the partition type returned something like "interactive install partition" for x drive. 

    Above mentioned Cmdlets don't exist in winpe4 x64 and wouldn't return true if UEFI was enabled and secure boot was disabled. Managed to get it working with the above scripts anyhow. 

    Cheers. 


    Thursday, June 2, 2016 2:57 AM
  • WinPe has nothing to do with this.  WinPE does not know about UEFI.  Only Windows OS and other full OSs know about UEFI.

    To gain anything in WinPE you need to install WMI extensions.  I do not think these extensions are available for WinPE.

    The only issues for WinPE are how to get it to boot from a UEFI system.


    \_(ツ)_/

    Thursday, June 2, 2016 3:30 AM
  • Not going to go into that side of things... I qualified my statements and goals above.

    Obviously there are many, many different ways you can detect these things depending on the scenario and given components. Mine was a constraint around WinPE4 where MDT isn't used for OS deployments and we needed a reliable way of detecting if the machine PXE booted into WinPE using UEFI or Legacy for one OSD task sequence/script sequence.

     
    Thursday, June 2, 2016 6:53 AM
  • Hey Buddy Try this...

    $d = Confirm-SecureBootUEFI -ErrorVariable ProcessError
    if ($ProcessError)
    {
    $wshell = New-Object -ComObject Wscript.Shell
    $wshell.Popup("legacy",0,"BOOTMODE",0x1)
    }
    else
    {
    $wshell = New-Object -ComObject Wscript.Shell
    $wshell.Popup("UEFI",0,"BOOTMODE",0x1) 
    }

    please let me know any doubt
    feel free to contact me 

    satyapal.reddyb@gmail.com

    Thursday, July 27, 2017 6:04 PM
  • Hey Buddy Try this code...

    $d = Confirm-SecureBootUEFI -ErrorVariable ProcessError
    if ($ProcessError)
    {
    $wshell = New-Object -ComObject Wscript.Shell
    $wshell.Popup("legacy",0,"BOOTMODE",0x1)
    }
    else
    {
    $wshell = New-Object -ComObject Wscript.Shell
    $wshell.Popup("UEFI",0,"BOOTMODE",0x1) 
    }

    please let me know any doubt
    feel free to contact me 

    satyapal.reddyb@gmail.com

    Thursday, July 27, 2017 6:05 PM