Fix it now
Microsoft publishes one cause for 30125-4 and 30125-1011: antivirus software, a firewall, or proxy settings are preventing Office from installing. Its first recommended remedy is not a firewall change but the offline installer, which carries the build with it and takes the download out of the picture.
netsh winhttp show proxy
nslookup officecdn.microsoft.com
curl.exe -I https://officecdn.microsoft.com
- Read the three results before changing anything. No proxy where the network requires one, a name that will not resolve, or a request that hangs each point somewhere different.
- Try Microsoft’s offline installer for Microsoft 365 first. It bypasses the proxy, firewall and antivirus path that this code is about, and it is the fastest way to get one machine working.
- Temporarily turn off the antivirus product, run setup, then turn it back on. Microsoft lists this as a supported diagnostic step for this code.
- If setup only fails on the corporate network, have outbound HTTPS to
officecdn.microsoft.comandofficeclient.microsoft.compermitted, by hostname rather than by address.
Do not leave antivirus off after the test. If setup succeeds with it disabled, the fix is an exclusion agreed with whoever owns that product, not a permanently unprotected machine.
If Office installs you can stop here. If not, the next section explains which of the three named causes you are actually looking at, and why one companion code in this family means something else entirely.
Why it happens
A Click-to-Run installation is a streamed download rather than a single package. Setup contacts a configuration service to work out which build and channel applies to this machine, then pulls the product itself from Microsoft’s content delivery network. Both legs have to complete, and 30125-1011 is setup reporting that one of them did not.
Microsoft’s page for 30125-4 and 30125-1011 gives one cause covering three suspects: antivirus software, firewall configuration, or proxy settings. That grouping is deliberate, because from inside the installer they look identical. An antivirus product scanning the stream, a firewall dropping the connection and a proxy refusing to relay it all produce the same failure to obtain content.
The remedies Microsoft lists are ordered by how quickly they get one machine working rather than by how much they explain: the offline installer, a wired connection, installing from a different network, disabling proxy settings, turning antivirus off temporarily, turning the firewall off temporarily. That order is worth respecting when someone is standing over you. It is worth ignoring when you have fifty machines and need to know what to ask the network team for.
Read the companion codes carefully, because they do not all mean the same thing. 30125-4 is the same code from the same page. 30094 is a different page with no published cause and entirely local remedies. And 30068, which readers often see in the same sequence, is documented as the Microsoft Office Click-to-Run service being disabled – nothing to do with the network at all.
An antivirus or endpoint agent is interfering with setup
You have this one if The offline installer works, the streamed install does not, and the machine runs a third-party security product.
- Turn the product off temporarily, run setup, then turn it back on. Microsoft names this as a step for this code.
- If that succeeds, ask whoever owns the product for an exclusion covering the Office setup process rather than leaving protection off.
- On a managed estate, check whether a recent policy change to that product lines up with the day installs started failing.
This is the cause people skip because it feels unlikely. It is the first one Microsoft names, and it is the one that explains why the same machine installs fine at home.
An outbound firewall rule is dropping the connection
You have this one if The name resolves, curl.exe never gets a response, and every machine on the same segment behaves the same way.
- Collect the proxy, resolution and request results from a failing machine so the request you raise is concrete.
- Ask for outbound HTTPS to the Microsoft 365 endpoints to be permitted from the client subnets.
- Retest with
curl.exe -I https://officecdn.microsoft.combefore rerunning setup, so you know whether the rule took effect.
The allow-list was written against IP addresses
You have this one if Installations worked for months and then stopped for everyone on the same day, with nothing changed on your side.
- Check whether the rule names hostnames or address ranges.
- Convert it to hostname or FQDN matching, or route the traffic through a proxy that can match on names and permit the proxy outbound instead.
- Feed the rule from Microsoft’s published endpoint list rather than maintaining it by hand.
Microsoft publishes the current Microsoft 365 endpoints as a machine-readable service that most gateways can consume. A rule that updates itself from that source does not rot.
Services are not using the proxy the network requires
You have this one if Browsing works, setup does not, and netsh winhttp show proxy reports a direct connection on a network where nothing reaches the internet directly.
- Import the browser configuration for system services:
netsh winhttp import proxy source=iefrom an elevated prompt. - Confirm the result with
netsh winhttp show proxy. - If the machine-level setting is wrong rather than missing, clear it with
netsh winhttp reset proxyand set it correctly.
A DNS filter is intercepting the lookup
You have this one if nslookup returns nothing, or an address belonging to a filtering appliance rather than Microsoft.
- Compare the answer against a resolver you trust, from a machine allowed to use one.
- If a filtering service is sinkholing the name, add the Microsoft hostnames to its allow-list.
- Clear the client resolver cache with
ipconfig /flushdnsand retest before rerunning setup.
Full reference
Proving where the block sits before you ask for a change
| Test result | What it tells you |
|---|---|
nslookup fails or returns an unexpected address |
Name resolution: a DNS filter, or an internal resolver that does not forward |
The name resolves but curl.exe never returns |
A firewall or an inspecting device is holding or dropping the connection |
curl.exe returns any HTTP status |
You reached Microsoft. The block is antivirus, or elsewhere entirely |
netsh winhttp show proxy says Direct access on a proxied network |
Services are not using the proxy the network requires |
| Setup works with antivirus disabled | The security product, and an exclusion is the fix |
| It works on a hotspot and not in the office | The gateway is the variable, not the machine |
Hostnames Microsoft actually publishes
Take these from the Microsoft 365 URLs and IP address ranges service rather than from a list someone typed into a ticket. Each row below is one Microsoft publishes there, with the endpoint set it belongs to.
| Hostname | Listed as | Ports |
|---|---|---|
officecdn.microsoft.com |
Microsoft 365 Common and Office Online, required | TCP 443, 80 |
officeclient.microsoft.com |
Microsoft 365 Common and Office Online, required | TCP 443 |
login.microsoftonline.com |
Microsoft 365 Common and Office Online, required, Allow category | TCP 443, 80 |
officeapps.live.com |
Microsoft 365 Common and Office Online, required | TCP 443, 80 |
ocos-office365-s2s.msedge.net |
Microsoft 365 Common and Office Online, optional auxiliary | TCP 443, 80 |
Allow the identity and licensing rows as well as the content ones. Permitting only the content host produces an installation that completes and then cannot sign in, which arrives as a different code and a second ticket.
Installing without the download
- Download the Microsoft 365 offline installer, or build a local source with the Office Deployment Tool using
setup.exe /download configuration.xmlon a network that works. - Copy the source to the failing machine or to a share it can reach.
- Install from it with
setup.exe /configure configuration.xmlfrom an elevated Command Prompt. - Sign in. The installed product still needs the identity and licensing endpoints, so this defers the network work rather than removing it.
The companion codes, and where they actually lead
| Code | Where Microsoft documents it | What that means for you |
|---|---|---|
30125-4 |
Same page as 30125-1011 | Same three causes, same remedies |
30094-4 |
The 30094 page publishes no cause | Its remedies are local: Disk Cleanup, an Office Online Repair, uninstall and reinstall |
30094-1011 |
As above; the suffix is not published | Treat it as 30094 and work locally, not on the firewall |
30068 |
Documented separately | Check the Microsoft Office Click-to-Run service in services.msc is not Disabled |
When every test passes and setup still fails
- Check free space on the system volume. A streamed install needs working room well beyond the finished size.
- Look for a second Office installation already in progress; that reports its own code and needs the first one to finish.
- Run setup from an elevated prompt as a local administrator on a managed machine, and check whether application control policy is blocking it.
- Try one machine on a different network. Success there tells you the gateway is the variable and saves an afternoon of local troubleshooting.
- If the machine reports 30068 at any point, stop and check the Click-to-Run service. That is a different fault wearing similar clothes.
Every code this article covers
| Code | What it points at | Source |
|---|---|---|
30125-1011 |
Antivirus software, a firewall or proxy settings are preventing Office from installing | Microsoft Support |
30125-4 |
Published on the same page and with the same cause as 30125-1011 | Microsoft Support |
30094-4 |
Microsoft publishes no cause for 30094 and no meaning for the suffix; its remedies are local – temporary files, an Office repair, reinstall | Microsoft Support |
30094-1011 |
As 30094-4. Read it as the base code, which is not documented as a network failure | Microsoft Support |
30068 |
Documented as a setup failure to check the Microsoft Office Click-to-Run service for, not as an endpoint problem | Microsoft Support |
Confirm the fix worked
curl.exe -I https://officecdn.microsoft.comreturns an HTTP response promptly.netsh winhttp show proxyreports what the network actually requires.- Setup completes and Word opens with no setup prompt.
- An update check from File, then Account, then Update Options succeeds, proving the path stays open after installation.
- If you disabled antivirus to test, confirm it is back on and that an exclusion is in place instead.
Questions people ask about this
Does this cost anything to fix?
No. Every documented cause is antivirus, firewall or proxy configuration. Your licence is not involved and setup has not reached the licensing stage, so no purchase changes the outcome.
Can I just allow all outbound HTTPS?
It would work and most security teams will not accept it. Allow-listing the published Microsoft 365 endpoints gives the same result with a scope that can be defended, and Microsoft publishes them in a form a gateway can consume automatically.
Why does Microsoft recommend the offline installer first?
Because it removes the whole class of problem rather than diagnosing it. For one machine that is the right trade. For an estate it is a workaround, and you still need the endpoints open for sign-in and updates afterwards.
Is turning antivirus off safe?
For the length of one installation on a machine that is not being used for anything else, yes, and Microsoft lists it as a step for this code. Leaving it off is not, and if it turns out to be the cause the answer is an exclusion agreed with whoever owns the product.
Setup showed 30068 instead this time. Same fix?
No. Microsoft documents 30068 against the Microsoft Office Click-to-Run service rather than the network. Open services.msc, find that service, and set its startup type to Manual or Automatic if it is Disabled.
