How to Install StorCLI on Windows

StorCLI is Broadcom’s command-line tool for managing MegaRAID and HBA storage controllers — the cards that build and monitor a hardware RAID array. On Windows there is no installer to click through: the whole tool is a single storcli64.exe, and “installing” it means putting that one file somewhere your shell can find it.

There is one thing worth knowing before you spend ten minutes on this, because it is the question that sends most people to a search box afterwards: StorCLI only sees a physical Broadcom/LSI controller. On a cloud VPS or any virtualised instance there is no such card, so the tool installs perfectly and then reports Number of Controllers = 0. That is not a broken install. This guide shows you that exact output so you can tell “working, nothing to manage” apart from “actually broken” — and if you are on bare metal with a real card, the same steps get you to reading it.

Every command below, and every block of output under it, was captured from a Windows Server 2025 box in the Lineserve lab running StorCLI 007.2705.0000.0000. Where the machine had no RAID controller to talk to, the output says so honestly rather than being faked — and the one place that genuinely needs a physical card to demonstrate is marked as such.

Conventions

This guide is written for a Windows Server administrator (Server 2016 through 2025; Windows 10 and 11 work identically). You need shell fluency in either Command Prompt or PowerShell — the commands here are PowerShell — plus Administrator rights, which StorCLI requires because it talks directly to storage hardware. Open your terminal with Run as administrator before you start; that single elevation covers everything below.

To keep the paths concrete, this guide uses these throughout — swap the download folder for wherever you prefer to work, but the install folder and version are worth keeping as-is:

Thing	Value used here
Download folder	C:\Users\<you>\Downloads (i.e. $env:USERPROFILE\Downloads)
Install folder	C:\Program Files\StorCLI
StorCLI version	007.2705.0000.0000 (current Broadcom release at time of writing)
Binary you end up running	storcli64.exe (x64)

Step 1 — Download the StorCLI package

Broadcom ships StorCLI as one big zip that covers every operating system. It downloads over plain HTTPS with no login, so you can pull it straight from PowerShell. (If you want the full tour of Invoke-WebRequest — resuming, headers, proxies — see Complete Guide to Downloading Files with PowerShell.)

$url = "https://docs.broadcom.com/docs-and-downloads/007.2705.0000.0000_storcli_rel.zip"
Invoke-WebRequest -Uri $url -OutFile "$env:USERPROFILE\Downloads\storcli.zip"

That command prints nothing on success. Confirm you actually got the file, and that it is the whole ~33 MB archive and not a truncated error page, by checking its size:

Get-Item "$env:USERPROFILE\Downloads\storcli.zip" | Select-Object Name, Length

You should see a length of roughly 34.7 million bytes:

Name         Length
----         ------
storcli.zip 34699985

If Length comes back as a few kilobytes instead, the download failed and you saved an error page — re-run the download and check the URL. In the lab this file’s SHA-256 was 3F13293B8ADFEC272F18D75ACF147F79071B082B832748C78E4812EE3C1B7A6D; Broadcom does not publish a checksum next to the download, so treat that as a “this is the build I tested”, not an official integrity guarantee.

Step 2 — Unzip it (twice — this is the part that trips people up)

The archive does not contain storcli64.exe directly. It contains another zip. Extract the outer one first:

Expand-Archive -Path "$env:USERPROFILE\Downloads\storcli.zip" `
  -DestinationPath "$env:USERPROFILE\Downloads\storcli" -Force
Get-ChildItem "$env:USERPROFILE\Downloads\storcli\storcli_rel"

Instead of executables, you get a single nested archive — this is expected, not a bad download:

    Directory: C:\Users\<you>\Downloads\storcli\storcli_rel

Mode      Length Name
----      ------ ----
-a---   ... Unified_storcli_all_os.zip

Extract that inner zip too, then look inside its Windows folder:

Expand-Archive -Path "$env:USERPROFILE\Downloads\storcli\storcli_rel\Unified_storcli_all_os.zip" `
  -DestinationPath "$env:USERPROFILE\Downloads\storcli\unified" -Force
Get-ChildItem "$env:USERPROFILE\Downloads\storcli\unified\Unified_storcli_all_os\Windows" |
  Select-Object Name, Length

The Windows folder holds exactly one file — the binary you came for:

Name          Length
----          ------
storcli64.exe 7282800

That storcli64.exe is the x64 build, which is what almost every server runs. If — and only if — your machine is ARM64 Windows, use the StorCLI64.exe under the sibling ARM\Windows folder instead; every StorCLI command you type from here on is identical, only the file you copy in the next step differs (noted where it matters).

Step 3 — Put storcli64.exe where your shell can find it

You can run the tool by its full path from that Downloads folder forever, but the tidy move is to drop it in one place and add that place to the system PATH, so storcli64 works from any directory. Create a folder for it and copy the binary in:

New-Item -ItemType Directory -Force -Path "C:\Program Files\StorCLI" | Out-Null
Copy-Item "$env:USERPROFILE\Downloads\storcli\unified\Unified_storcli_all_os\Windows\storcli64.exe" `
  -Destination "C:\Program Files\StorCLI" -Force

On ARM64 Windows, change that source path to end in ...\Unified_storcli_all_os\ARM\Windows\StorCLI64.exe instead — everything after this copies and runs the same.

Now append that folder to the machine-wide PATH. This reads the current machine PATH and adds the folder only if it is not already there, so it is safe to run twice:

$p = [Environment]::GetEnvironmentVariable("Path", "Machine")
if ($p -notlike "*C:\Program Files\StorCLI*") {
  [Environment]::SetEnvironmentVariable("Path", $p + ";C:\Program Files\StorCLI", "Machine")
}

Here is the one thing that will make you think you did it wrong: a terminal that was already open when you edited PATH will not see the change. The new PATH only reaches shells opened afterwards. So close this PowerShell window and open a new one (as administrator again), then confirm Windows now resolves the bare command to your installed copy:

Get-Command storcli64 | Select-Object -ExpandProperty Source

C:\Program Files\StorCLI\storcli64.exe

A red CommandNotFoundException instead of that path means you are still in the shell you edited PATH from — open a fresh one and try again.

Step 4 — Verify the install and read the controller state

Two commands prove the tool runs. First, its version:

storcli64 -v

      StorCli SAS Customization Utility Ver 007.2705.0000.0000 August 24, 2023

    (c)Copyright 2023, Broadcom Inc. All Rights Reserved.

Then ask it to enumerate controllers — this is the real test of whether StorCLI has anything to do on this machine:

storcli64 show

CLI Version = 007.2705.0000.0000 August 24, 2023
Operating system = Windows Server 2022
Status Code = 0
Status = Success
Description = None

Number of Controllers = 0
Host Name = EC2AMAZ-6UBG03O
Operating System  = Windows Server 2022
StoreLib IT Version = 07.2703.0200.0000
StoreLib IR3 Version = 16.14-0

Read that carefully, because two lines look alarming and are not:

• Number of Controllers = 0 with Status = Success. The command worked. It found no Broadcom/LSI controller because this machine has none — it is a virtual instance with no physical RAID card. On any VPS or cloud server you will see exactly this, and there is nothing to fix. On a physical server with a MegaRAID or HBA card, this number is 1 or more.
• Operating system = Windows Server 2022 even though the lab box is Server 2025. StorCLI’s bundled StoreLib library reports the newest Windows it knows about, and this build predates
• It is cosmetic — it does not affect anything StorCLI does. Do not chase it.

If you got both of those, StorCLI is installed correctly. Whether it has any hardware to manage is a separate question, answered by that controller count.

Reading a controller that actually exists

Everything to this point ran on a machine with no RAID card, on purpose, so you could see the empty-but-healthy state. The commands below are how you’d inspect a real controller. The lab had no physical MegaRAID hardware to exercise them against, so — per our own rule of never showing invented hardware output — the field-by-field results are described, not pasted, and marked for a hardware check.

Ask just for the count (handy in scripts — it prints one clean number):

storcli64 show ctrlcount

On the controllerless lab box this is what came back — a clean success with the count at the bottom:

CLI Version = 007.2705.0000.0000 August 24, 2023
Operating system = Windows Server 2022
Status Code = 0
Status = Success
Description = None

Controller Count = 0

On a machine with one card that last line reads Controller Count = 1.

Inspect the first controller and its virtual drives:

storcli64 /c0 show

With no card present, this is the one command that reports a failure rather than an empty success — real captured output from the lab:

CLI Version = 007.2705.0000.0000 August 24, 2023
Operating system = Windows Server 2022
Controller = 0
Status = Failure
Description = Controller 0 not found

A trap worth knowing before you script around StorCLI: that failure still exits with code 0. $LASTEXITCODE was 0 even though the Description says Controller 0 not found. Do not branch on the exit code to decide whether a controller exists — parse the Status or Controller Count line instead. This was verified in the lab.

On a server that does have a card, storcli64 /c0 show returns the controller model, firmware version, and a summary of its virtual and physical drives; storcli64 /c0/vall show lists the virtual drives (your RAID volumes) with their RAID level and state; and storcli64 /c0/eall/sall show lists the physical disks. The exact fields depend on your controller and firmware; this run had no physical card to capture them from, so that breakdown comes from Broadcom’s StorCLI reference rather than a session transcript.

A note on PowerShell vs Command Prompt

Broadcom’s documentation states that StorCLI is not fully supported under PowerShell, because PowerShell can interpret parts of StorCLI’s /cx/vx command syntax as its own operators. Every command in this guide — show, show ctrlcount, /c0 show — ran cleanly in PowerShell in the lab. But if you hit a command that PowerShell mangles, you have two escapes: wrap the StorCLI arguments in quotes, e.g. storcli64 "/c0 show", or just run the same command from an Administrator Command Prompt, where no quoting is needed.

Uninstalling

There is nothing registered to remove — StorCLI is just the one file plus your PATH entry. To undo this guide completely, strip the folder back out of PATH and delete it:

$p = [Environment]::GetEnvironmentVariable("Path", "Machine")
$new = ($p -split ';' | Where-Object { $_ -ne "C:\Program Files\StorCLI" }) -join ';'
[Environment]::SetEnvironmentVariable("Path", $new, "Machine")
Remove-Item "C:\Program Files\StorCLI" -Recurse -Force

Troubleshooting

Number of Controllers = 0 on a machine you expected to have RAID. If it is a VPS or cloud instance, that is correct and final — there is no physical controller to see. If it is a physical server that definitely has a MegaRAID/HBA card, the card’s driver is likely missing or the card is in a mode StorCLI does not manage; install the controller driver from Broadcom or your server vendor and re-run storcli64 show.

storcli64 : The term 'storcli64' is not recognized... Your PATH change has not reached this shell. Open a new Administrator terminal (Step 3), or run the tool by its full path, & "C:\Program Files\StorCLI\storcli64.exe" show.

Access denied / no output at all. You are not elevated. StorCLI needs Administrator rights to reach the hardware; reopen the terminal with Run as administrator.

Where StorCLI actually earns its keep

The whole point of StorCLI is managing a hardware RAID controller — checking array health, spotting a failing disk before it takes the array with it, kicking off a rebuild. None of that exists on a VPS, because a VPS has no card of its own for you to manage; the empty output above is the honest proof of it. That control over the physical disk layer is exactly what a dedicated server gives you — you own the machine, the controller, and the array. If that is the level you’re operating at, The Complete Guide to Installing StorCLI on Linux and Windows covers the Linux side of the same fleet, and a Lineserve dedicated server puts a real RAID controller under your command. See Lineserve dedicated servers →

If you also run Windows Server day to day, two adjacent jobs from the same admin toolbox: How to Convert Windows Server Evaluation to Standard or Datacenter (2019, 2022, 2025) and How to Enable ICMP (Ping) on Windows Public Firewall.