Fido: a PowerShell script for Windows and UEFI Shell ISO downloads

Why retail ISOs matter more than the download convenience

The README is explicit about the reason Fido exists. Microsoft publishes retail ISO download links for Windows 8 through Windows 11, but the company's download pages push users through steps that stand between them and the file. Fido's job is to skip that. The stated purpose is to "automate access to the official Microsoft Windows retail ISO download links as well as provide convenient access to bootable UEFI Shell images."

The security argument is the part worth reading twice. The README claims that using official retail ISOs is currently the only way to assert with certainty that OS content has not been altered, because there is a single master for each retail image and Microsoft publishes an official SHA-1 for it. Media Creation Tool ISOs are regenerated on the fly, so no two are identical, and the README states it is impossible to validate with absolute certainty whether an MCT-generated ISO is safe. If you care about matching your install media bit for bit against what Microsoft released, that distinction is the whole point. Fido is a downloader, not a verifier: it gets you the retail file, and checking the hash is still your job, using a source such as MSDN if you have access or a public listing the README points to.

Who this is for: people building install media who want the retail artefact, and Rufus users, since the README says the script is primarily designed to be used in Rufus but also works standalone.

What the script actually does against Microsoft's servers

Fido does not host or mirror anything. The README describes it as performing the same operation a person would perform by visiting the Microsoft software download page, with one caveat: Microsoft's servers detect when your browser user agent matches the version of Windows you are trying to download and may redirect you away from the page that gives a direct ISO link. That redirect behaviour is the friction the script works around.

The flow is two API calls. After checking basic access to the Microsoft software downloads website, the script queries the Microsoft web API to request the languages available for the selected Windows version. It then requests the actual download links for all architectures available for that language and version combination. So the selection is a cascade: version, then release, then edition, then language, then architecture. Each level narrows the next query, and the final response contains the URLs.

That design explains the defaults. If you omit a parameter, the script fills it in: the most recent Windows version, the most recent release for that version, and for language and architecture it tries to mirror your system locale and system architecture. The output in the README shows this plainly, printing one line per defaulted choice before the download starts. There is no local catalogue and no cached metadata; every run talks to Microsoft.

Installing Fido and running a first download

There is no package to install. The repository's top level holds Fido.ps1 alongside LICENSE.txt, README.md, sign.sh and dotfiles, so the script is the deliverable. Download Fido.ps1 from the repository or a release, open a PowerShell console in its folder, and run it. The README requires Windows 8 or later with PowerShell, and states that Windows 7 is not supported.

Start by listing what is currently downloadable. This does not download anything; it prints the supported versions so you can pick one.

PS C:\Projects\Fido> .\Fido.ps1 -Win List

Then ask for the releases available for a version. The README's own example shows the list format, with build numbers and dates, and notes that you can pass -Rel Latest to force the most recent release.

PS C:\Projects\Fido> .\Fido.ps1 -Win 10 -Rel List

A plain run with only the version specified defaults everything else and starts the download. The README's example output shows the four defaulting messages, the selected combination, and then a line naming the ISO and its size before the transfer begins.

PS C:\Projects\Fido> .\Fido.ps1 -Win 10

If you want the URL rather than the file, add the -GetUrl switch. The README states that the script then only displays the download URL, which you can pipe into another command or into a file. That is the mode to use when the download should happen elsewhere, or when you want to record the link. The other selection switches follow the same pattern: -Rel, -Ed, -Lang and -Arch, each with a List option, and each accepting an abbreviated value as long as it is unique enough.

The shrinking release list is the real constraint

The README carries a warning that matters more than any feature: as of 2023.05, Microsoft removed access to older releases of Windows ISOs, and the list of releases Fido can download had to be reduced to only the latest for each version. This is not a bug in the script and no update will fix it, because the links Fido resolves are Microsoft's, not its own. If your workflow depends on a specific older build, this tool is the wrong instrument, and the -Rel List output is where you confirm that before committing to it.

There is a second limitation in the same area. The README says the script performs the same operation as visiting the Microsoft download page with an adjusted user agent, which means it inherits whatever Microsoft's servers decide to return. The script queries an API; it does not control the answers. A change on Microsoft's side can break a run without the script changing at all.

Platform support is narrow by design: Windows 8 or later with PowerShell, no Windows 7. Anyone on Linux or macOS who wants Microsoft retail ISOs will not get them from this script, even though PowerShell exists on those platforms. Finally, the README does not document rollback, checksum verification, or what happens to a partial download, so treat hash checking as an external step you perform yourself.

Fido against the Media Creation Tool and against Rufus

The obvious alternative is Microsoft's own Media Creation Tool, and the difference is not convenience but verifiability. MCT regenerates ISO content each time, so no two outputs are identical, and the README argues that this makes it impossible to tell with certainty whether an MCT ISO was corrupted after generation. Fido returns the retail file, which has a single master and a published SHA-1. If you need to prove your install media matches Microsoft's release, MCT cannot give you that and Fido can. If you just want a working USB stick and do not care about provenance, MCT is the supported first-party path and Fido adds a dependency on an unofficial script.

Rufus is not really a competitor here. The README states that Fido is primarily designed to be used in Rufus, so the two are layered: Rufus writes the media, Fido fetches the ISO. Running Fido standalone is the supported secondary mode, and that is what the command line examples in the README demonstrate. The practical difference between the two modes is only whether the script instantiates a GUI or runs in a console; the command line switches exist precisely so that a script or another program can drive it, which is why -GetUrl matters for integration.

Maintenance cost, licensing and what to re-check

Maintenance is a live concern, not a settled one. The last push to the repository was on 2026-03-30, and the most recent release, v1.70, is dated the same day, following v1.69 on 2026-02-27 and v1.68 on 2026-02-16. The release cadence through early 2026 is steady, and the pattern of small version bumps suggests the work is mostly keeping the script aligned with Microsoft's API and with new Windows releases rather than adding features. That is the cost of adopting it: the script's usefulness depends on someone continuing to track Microsoft's download service, and the README's note about the 2023.05 release removal shows what happens when Microsoft changes something the script cannot work around.

Licensing is GPL-3.0 or later, per the README and the LICENSE.txt file in the repository. That is a copyleft licence, so if you redistribute the script or a modified version, the usual GPL obligations apply. This article is not legal advice; if you plan to bundle Fido inside another product, read the licence text yourself. Note that the README's own framing is that the script is designed to be called by Rufus, so embedding it in a larger tool is an anticipated use, not an edge case.

Editorial conclusion

Adopt Fido if you need a Microsoft retail ISO whose hash you can check against an official source, or if you want UEFI Shell images without hunting for them, and you are on Windows 8 or later with PowerShell. Do not adopt it on Windows 7, which the README states is not supported, and do not expect it to fetch older Windows releases, since the README notes Microsoft removed access to those and the release list was cut to the latest for each version. Before relying on it, verify the SHA-1 of the downloaded ISO against the official listing yourself, and confirm that the version, release and edition you need still appear under -Win List, -Rel List and -Ed List.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. pbatard/Fido on GitHub
4. README
5. Releases