Install-Office: scripted Microsoft 365 and Office 2024 deployment

A wrapper around the Office Deployment Tool

farag2/Install-Office exists to download Microsoft 365, formerly Office 365, and Microsoft Office 2024 LTSC using the Office Deployment Tool with PowerShell. The primary language of the repository is VBScript, and the top level is small, with a `src/` directory holding the scripts, a `LICENSE` file, a `README.md` and a `.github/` folder. The important thing to understand is that this is not a repackaged Office installer and does not contain any Office binaries. It is a scripted front end that drives Microsoft's own deployment mechanism, and it also provides a configuration script for the settings that Microsoft exposes in its deployment configuration. The project documentation points at the Microsoft Office Deployment Tool download and the Deploy Office documentation as the underlying references.

The three scripts and the order they run in

The documented workflow has three steps and a specific order. First you expand the release archive and open PowerShell as administrator, changing the execution policy so the scripts can run:

  Set-ExecutionPolicy -ExecutionPolicy Bypass -Force

Second, in the expanded `Office` folder you choose the Office product to download and configure the components, then run `Download.ps1` with the branch, channel and component list. The download is silent, and there are no messages in the console while Office is being downloaded, which matters because a script that appears hung during a long fetch is a bad first experience. When it finishes, a new `Office` folder appears in the script folder. Third, you run `Install.ps1` as administrator to install what was downloaded. The `Configure_Office.ps1` script is a separate, optional stage that applies policy defaults, and it is not needed for the download and install to work.

Branch, channel and component are the three choices you make

The configuration surface is three parameters, and the documentation lists the accepted values for each. The branch is either ProPlus2024Volume, which is the Office 2024 volume licensed product, or O365ProPlusRetail, the Microsoft 365 retail channel product. The channel is Current, PerpetualVL2024 or SemiAnnual, which are the update cadence and licensing variants the tool accepts. The components list picks what actually gets installed, and the documented options are Access, OneDrive, Outlook, Word, Excel, OneNote, Publisher, PowerPoint, Teams, Project Pro 2024 and Visio Pro 2024. Two example invocations show the shape of the command, one for a volume licence on the perpetual channel and one for the retail product on the current channel:

  .\Download.ps1 -Branch ProPlus2024Volume -Channel PerpetualVL2024 -Components Excel, OneDrive, PowerPoint, Word
  .\Download.ps1 -Branch O365ProPlusRetail -Channel Current -Components Excel, OneDrive, Outlook, PowerPoint, Teams, Word

Pinning these three things is the real value of the script. It turns an interactive Office installation into a repeatable, declarative command, which is what makes it usable in a provisioning pipeline or across a set of lab machines.

The generated Office folder has to stay where it is

There is a constraint that is easy to miss and expensive to debug. The downloaded `Office` folder must not be moved to another location, because the `Install.ps1` script has a link to `setup.exe` inside it. In other words the install script resolves the deployment tool binary relative to where it was generated, and relocating the folder breaks that reference. This is the kind of coupling that makes the workflow feel less like a package manager and more like a set of scripts that assume a specific layout. It also means the scripts are best run in place, from the expanded archive, rather than copied into a shared tools directory. The addendum states the platform floor plainly: Microsoft Office 2024 and Microsoft 365 support Windows 10 and Windows 11 only, so there is no path here for older Windows releases or for any other operating system.

Configure_Office.ps1 turns policy defaults into switches

The configuration script is a separate concern from the installation, and the settings are listed under general, Word and Excel headings. The general items include removing diagnostics tracking scheduled tasks, not sending additional diagnostic and usage data to Microsoft, disabling LinkedIn features in Office applications, turning off the cloud features, and turning on Touch/Mouse Mode. The Word and Excel items include not showing the Start screen on application start, disabling Protected View for files from the Internet, for files in potentially unsafe locations and for Outlook attachments, opening attachments and other uneditable files outside reading view, saving AutoRecover information every 3 minutes, showing the ruler, enabling the Draw tab and the Developer tab, and removing Adobe Acrobat Pro DC COM add-ins. These map onto the settings Microsoft documents in its deployment settings reference, alongside links to the update channel and product id documentation.

Compared with driving the Office Deployment Tool yourself

The realistic alternative is to skip this repository and use the Microsoft Office Deployment Tool directly, since both it and its documentation are linked. The difference in approach is thin but real. The Microsoft tool is the thing doing the work in both cases, and it is the one that defines the configuration file format and the supported switches. What Install-Office adds is a PowerShell surface with named parameters for branch, channel and components, so you can express an installation as a single command line instead of authoring and maintaining a configuration XML, plus a curated configuration script for policy defaults that you would otherwise write by hand against the Microsoft settings reference. If you already have configuration XML in your image or configuration management system, this script is a convenience layer over something you have already built. If you do not, it removes the awkward first step, at the cost of one more piece of third-party code between you and Microsoft's tool.

Version cadence, licence and the upgrade question

The release history is regular, with version 2.4 published on 2026-09-21, 2.3.5 on 2026-06-27 and 2.3.4 on 2026-04-20, and the last push was on 2026-09-21. The project is MIT licensed, which is what makes the wrapper usable in an internal tooling repository without any licensing discussion. The scripts reference the Microsoft Office Deployment Tool, so a change on Microsoft's side is a change in behaviour that arrives without a release from this repository, and that is the main upgrade risk to plan for: the branch and channel values, and the product ids they map to, are documented by Microsoft and change over time. GetHelpCmd is also linked, the ex-SaRA support tool, and to OffScrubC2R.vbs 2.19 in a separate repository by the same author for removing an existing Click-to-Run installation, which tells you the script is intended for machines that already have Office as well as clean ones.

Editorial conclusion

Install-Office suits an administrator or lab operator who needs repeatable Office deployments across machines, wants to pin a branch and channel instead of following the default installer, and wants the default privacy and Protected View policy applied from a script. It is the wrong tool for anything outside Windows 10 and 11, and it adds a layer over a Microsoft tool that you could drive directly. Before you use it, confirm the branch and channel values are ones your licence covers, keep the generated Office folder in place so the install script still finds setup.exe, and read the Configure Office settings before applying them in bulk. The last push was on 2026-09-21, version 2.4 was released the same day, and the code is MIT licensed.

Frequently asked questions

Official sources

1. farag2/Install-Office on GitHub
2. Issues
3. License: MIT
4. README
5. Releases