Helpdesk: a Required Microsoft 365 Apps assignment sits on Install pending or Waiting for install status for hours. Another device shows Failed. Outlook never appears. Someone has already opened the app properties to flip Update Channel, delete the assignment, or rebuild the suite as a Win32 package "because Office always breaks in Intune."
Don't rebuild the suite yet. The Intune Microsoft 365 Apps app type is not a Win32 app: it rides the Office CSP and the Office Deployment Tool (ODT) / Click-to-Run path to the Office CDN. The chain is: you confirm you're troubleshooting that app type (not a Win32 .intunewin, not detection after a successful install) → Troubleshoot + support shows the device actually got the assignment → you know whether Intune ever started the payload (Program Files folders) or the device never reached the CDN → you decode the Office CSP / ODT status (1603 MSI or bitness, 17002 open apps / disk / language, 1460 ODT download timeout) → you fix the prerequisite that the status names → you re-check after Sync without stacking a second M365 Apps deployment. Most "Office won't install from Intune" tickets are MSI leftovers, bitness mismatch, open apps, or CDN reachability — not a bad Update Channel.
If the failing app is a Win32 Required package with IME exit codes (0x87D30065, 0x80070643, 0x87D300C9), use the Win32 install-failed triage. If Office did install and a Win32 detection rule still says Failed (0x87D1041C), that's the detection-rule post. If Autopilot ESP is stuck on apps, start with the ESP checklist. If Company Portal won't sync at all, use the device-not-syncing triage. This post is only the built-in Microsoft 365 Apps for Windows suite.
TL;DR
-
App type matters.
Apps > All apps >the suite whose type is Microsoft 365 Apps (Windows 10 and later) uses Office CSP + ODT. It is not managed by the Intune Management Extension the way Win32 apps are. - Read Troubleshoot + support > user > device > Managed apps before you edit the suite. Confirm assignment intent (Required / Available / excluded) and the install error details on that device.
-
Folder test: if
C:\Program Files\Microsoft OfficeandC:\Program Files\Microsoft Office 15appear, Intune started the deployment; dig into Office/ODT. If they never appear, stay on enrollment, assignment, and network/CDN first. - Microsoft documents these hard rules: preexisting MSI Office must be removed (Remove other versions / Remove MSI) or Click-to-Run fails; only one Microsoft 365 Apps deployment is delivered per device; 64-bit installs only on 64-bit Windows; open Office apps can fail the install; not supported on Windows Home, Team, or Holographic.
-
Decode Office CSP status:
1603= prereq (MSI side-by-side or bitness);17002= scenario didn't complete (cancel / another install / disk / language);1460= ODT download timeout;997= still installing;0= success. - ESP caution: Microsoft recommends deploying Microsoft 365 Apps as a Win32 app if you track it during Autopilot ESP — the M365 Apps app type can race other Win32 installs and fail ESP.
Where in the chain did it break?
| Step | What should be true | Typical symptom when it breaks |
|---|---|---|
| 1. Right app type | You're on Microsoft 365 Apps, not Win32 / Store / LOB | Chasing IME AppWorkload.log for an Office CSP failure |
| 2. Assignment reached device | Troubleshoot Managed apps shows the suite with a real intent | Pending forever; user not in include group; excluded; wrong platform |
| 3. Intune vs CDN | Program Files Office folders present or Download folder growing toward officecdn | Folders missing → enrollment/network; folders present → ODT/MSI/bitness |
| 4. Prerequisites | No MSI Office; matching bitness; apps closed; supported SKU/edition; one suite only | Status 1603 / 17002 / silent fail after "started" |
| 5. Status decoded | Portal / CSP status maps to a named failure | Guessing Update Channel or languages first |
| 6. Logs confirm | Click-to-Run verbose log matches the status story | Fixing the wrong machine or a stale FinalStatus |
| 7. One change | Fix the named prereq; Sync; wait — don't add a second M365 Apps app | Two suites fighting; ESP concurrency with Win32 |
Write down the app name, assignment intent, device OS edition/build, 32 vs 64-bit setting on the suite, whether Remove other versions is Yes, and the exact status/error from Troubleshoot before you change the suite.
Step 1: Confirm it's Microsoft 365 Apps (not Win32)
In Intune admin center:
- Apps > All apps → open the suite.
- Confirm the type is Microsoft 365 Apps (Windows 10 and later), not Windows app (Win32).
| What you deployed | Triage this post? | Where failures show up |
|---|---|---|
| Microsoft 365 Apps app type | Yes | Office CSP / ODT / Click-to-Run; not IME return codes |
Win32 package that wraps setup.exe + XML |
No — Win32 triage | IME download/install/detection |
| Microsoft Store / Centennial Office | Out of scope | Microsoft: Store Office + Intune M365 Apps on the same device can cause data loss |
Microsoft also states: for Microsoft 365 Apps for business, you must configure the suite with XML data (not only the designer defaults that assume enterprise SKUs). If your tenant licenses business edition and the suite was built as enterprise-only in the designer, treat XML/SKU mismatch as a configuration read before you blame the device.
Step 2: Read assignment and Managed apps (read-only)
Use Microsoft's app troubleshooting path:
- Troubleshoot + support → select the user → select the device → Managed apps.
- Open the Microsoft 365 Apps suite row. Note Installation status, error details, and resolved intent (including excluded).
- Cross-check Apps > All apps > [suite] > Device install status / User install status for the same device or user.
| Signal | Read it as |
|---|---|
| Suite missing from Managed apps | Assignment/group membership/platform — not ODT yet |
| Intent excluded | Intent conflict resolution — fix targeting, don't rebuild Office |
| Available and user never opened Company Portal | Expected until the user installs; not a Required failure |
| Required + Failed with an Office-looking code | Continue this chain |
| Device last check-in stale | Fix MDM sync first (Company Portal triage) |
Optional Graph read of the mobile app object (list filter by display name). Permission commonly used for app reads: DeviceManagementApps.Read.All:
Connect-MgGraph -Scopes 'DeviceManagementApps.Read.All'
# Documented pattern: GET /deviceAppManagement/mobileApps
$apps = Invoke-MgGraphRequest -Method GET -Uri `
'https://graph.microsoft.com/v1.0/deviceAppManagement/mobileApps?$filter=isof(%27microsoft.graph.officeSuiteApp%27)&$top=50'
($apps.value | Select-Object id, displayName, '@odata.type', publisher) |
Format-Table -AutoSize
Use the portal assignment blades for who got Required vs Available; Graph assignment expansion varies by app type and API version — treat the Troubleshoot pane as authoritative for a single user's device.
Step 3: Did Intune start the payload? Folders and CDN
Microsoft's troubleshooting split for this app type:
| Observation on the device | Meaning |
|---|---|
Both C:\Program Files\Microsoft Office and C:\Program Files\Microsoft Office 15 exist |
Intune initiated the deployment; continue to Office/ODT prerequisites and status codes |
| Those folders never appear | Stay on enrollment, network, Intune + Office 365 endpoints, and assignment |
C:\Program Files\Microsoft Office\Updates\Download size not growing (or grows very slowly) while install should be running |
CDN / bandwidth / proxy path — clients should reach officecdn.microsoft.com per Microsoft's Office endpoint guidance |
On the device (read-only):
$paths = @(
'C:\Program Files\Microsoft Office',
'C:\Program Files\Microsoft Office 15',
'C:\Program Files\Microsoft Office\Updates\Download'
)
foreach ($p in $paths) {
if (Test-Path $p) {
$size = (Get-ChildItem $p -Recurse -ErrorAction SilentlyContinue |
Measure-Object -Property Length -Sum).Sum
[pscustomobject]@{ Path = $p; Exists = $true; Bytes = $size }
} else {
[pscustomobject]@{ Path = $p; Exists = $false; Bytes = $null }
}
}
Also confirm: device enrolled, has network (not airplane mode), and can reach Intune and Microsoft 365 / Office CDN endpoints. Microsoft points admins at Intune network endpoints and Office 365 URLs/IP ranges, and warns that forcing CDN traffic through central proxies adds latency that looks like "stuck downloading."
Step 4: Prerequisites Microsoft calls out before status codes
Read these on the suite and on the device before you redeploy:
| Check | Microsoft's rule | How you read it |
|---|---|---|
| MSI Office present | Click-to-Run + MSI on the same computer isn't supported; install won't succeed if preexisting MSI apps remain | Suite setting Remove other versions = Yes; still verify Apps & Features / uninstall keys for old MSI Office |
| Multiple M365 Apps deployments | Not currently supported — only one deployment is delivered to the device | Count Microsoft 365 Apps apps assigned Required/Available to the same user/device |
| Architecture | 32-bit can install on 32- or 64-bit Windows; 64-bit only on 64-bit devices | Suite Architecture vs Get-CimInstance Win32_OperatingSystem / (Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration -ErrorAction SilentlyContinue).Platform
|
| Open apps | If Word/Excel/Outlook are open, install might fail and users can lose unsaved work | Ask the user to close Office; don't force uninstall mid-ticket without change control |
| OS | Creators Update or later; not supported on Windows Home, Team, Holographic, Holographic for Business | Edition from Get-ComputerInfo / Settings > System > About |
| Install rights | Signed-in user needs permission to install applications | Local Users and Groups / WDAC / AppLocker / Company Portal errors |
| Autopilot ESP | M365 Apps app type is not IME-managed; concurrent Win32 + M365 Apps during ESP can fail ESP | If ESP tracks Office, Microsoft recommends Win32 for that path |
MSI leftover probe (read-only; look for classic MSI product codes / uninstall entries — adjust if your estate uses different display names):
$uninstallRoots = @(
'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $uninstallRoots -ErrorAction SilentlyContinue |
Where-Object {
$_.DisplayName -match 'Microsoft Office|Microsoft 365|Microsoft Project|Microsoft Visio' -and
$_.PSChildName -notmatch '^{.*}$' # rough: Click-to-Run often GUID-style; treat hits as candidates only
} |
Select-Object DisplayName, DisplayVersion, Publisher, PSChildName |
Format-Table -AutoSize
Treat that list as candidates. Confirm MSI vs Click-to-Run in Add/Remove programs and in HKLM:\SOFTWARE\Microsoft\Office\ClickToRun before you enable aggressive uninstall.
Step 5: Decode Office CSP / ODT status
Microsoft documents Office CSP status values used when Intune deploys this suite (same codes appear in the apps-add-office365 troubleshooting tables and the Office CSP reference):
| Status | Phase / meaning | What to do in this triage |
|---|---|---|
| 0 | Installation succeeded | Verify apps launch; if Intune still looks wrong, wait for check-in — don't stack another suite |
| 997 | Installing (WIP) | Wait; watch Download folder / CPU for OfficeClickToRun |
| 1460 | Failed to download the Office Deployment Tool | Network/CDN/proxy to ODT download; retry after connectivity |
| 13 | Can't verify signature of downloaded ODT | TLS inspection / file corruption / security filtering of the ODT binary |
| CertVerify* | Failed certification check for downloaded ODT | Same family as signature/cert path problems |
| 1603 | Prerequisite failure: MSI side-by-side (SxS), version/bitness mismatch, others | Remove MSI (Remove other versions), align 32/64-bit with what's already installed |
| 17002 | Failed to complete install scenario: user cancel, another installation, out of disk, unknown language ID | Close Office, free disk, check language IDs in suite/XML, wait for other installs |
| 17004 | Unknown SKUs (and related clean-up / CDN content cases in the CSP table) | Suite product ID / XML SKU vs licenses; CDN content availability |
| 17000 / 17001 | Click-to-Run client failed to start / queue scenario | Device health, corrupted C2R, competing Office setup |
| 17003 | Another scenario is running | Wait or find the other Office install/uninstall |
| 17006 | Blocked update by running apps (CSP table) | Close running Office apps; retry |
| 0x8000ffff | Uninstall when no Click-to-Run Office present | Don't run Uninstall intent against a clean / MSI-only machine expecting C2R |
ODT scenario notes Microsoft lists alongside those codes: install while MSI present → 1603; try 64-bit on top of 32-bit C2R → 1603; lack of space / cancel → 17002.
Step 6: Capture verbose Click-to-Run logs (when status isn't enough)
Microsoft's verbose path for this app type (change control — registry write):
- Enable:
reg add HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /t REG_DWORD /d 3 - Redeploy / Sync and wait ~15–20 minutes.
- Collect
{Machine Name}-{TimeStamp}.logfrom%temp%and%windir%\tempsorted by Date Modified. - Disable:
reg delete HKLM\SOFTWARE\Microsoft\ClickToRun\OverRide /v LogLevel /f
Also consider Microsoft Support and Recovery Assistant for Microsoft 365 on a pilot device when install or run-time issues remain after CDN and prerequisites look clean.
For custom ODT XML installs, Microsoft notes: install status reflects the installation attempt, not necessarily whether the app is currently installed — don't chase "Installed" reporting the same way you would for a Win32 detection rule.
Step 7: Failure modes that look like "Intune is broken"
| Failure mode | What you see | Fix direction |
|---|---|---|
| MSI Office still present | 1603; folders may appear then fail | Remove other versions = Yes; confirm MSI gone; then Sync |
| Second M365 Apps suite assigned | Odd pending/failed; only one delivery | Consolidate to a single Microsoft 365 Apps deployment |
| 64-bit suite on 32-bit OS / bitness clash with existing C2R | 1603 | Match Architecture to device and to existing C2R platform |
| Outlook open during Required install | 17002 / user reports cancel | Communicate close-apps window; retry |
| Proxy hairpins CDN | Stuck downloading; Download folder flat | Allow direct officecdn / Office endpoints |
| ESP tracks M365 Apps app type beside Win32 | ESP fails / concurrency | Follow Microsoft's guidance: Win32 for ESP-tracked Office |
| Settings catalog Update Channel fights the suite | Unexpected reinstall / channel thrash | Microsoft: avoid conflicting Update Channel / version between settings catalog and the M365 Apps deployment |
| Store (Centennial) Office + Intune suite | Data loss risk per Microsoft | Don't mix; pick one deployment model |
| Business license + designer-only enterprise suite | Install/SKU confusion | Configure with XML for Apps for business |
Timing: when "still broken" is just waiting
| Event | Microsoft's timing / rule |
|---|---|
| Required assignment, silent install | Starts after the device checks in and Office CSP runs; no IME "install command" stage |
| Status 997 | In progress — allow time for CDN download on slow links |
| Verbose log capture window | ~15–20 minutes after enabling LogLevel and redeploying (Microsoft's guidance) |
| Available assignment | User must install from Company Portal |
| After MSI removal | Need a new install attempt (Sync / retry); old FinalStatus alone isn't a cure |
| ESP Office install | Prefer Win32 packaging for tracked ESP apps to avoid concurrency with other Win32 installs |
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Folders missing, CDN blocked | Fix network/endpoints; confirm enrollment + assignment | Rebuilding the suite as Win32 on day one |
| 1603 + MSI found | Enable Remove other versions, confirm MSI gone, Sync | Manual random uninstall of Click-to-Run while guessing |
| 1603 + bitness mismatch | Align suite Architecture (or reinstall matching bitness) | Deploying a second suite "for 32-bit users" onto the same device |
| 17002 + apps open / low disk | Close Office, free space, retry | Deleting the Intune app object |
| 1460 / stuck downloading | CDN path, proxy bypass for officecdn | Widening Update Channel changes |
| Two M365 Apps deployments | Keep one; remove the duplicate assignment | Adding a third "test" suite to production groups |
| ESP failures with M365 Apps app type | Pilot Office as Win32 for ESP-tracked installs | Forcing the CSP app type through ESP beside other Win32 blockers |
| Only one user fails, suite healthy elsewhere | That user's groups, disk, MSI leftovers, open apps | Tenant-wide channel change |
FAQ
Why is Intune Microsoft 365 Apps stuck on install pending or "waiting for install status"?
Pending means the device hasn't finished the Office CSP / Click-to-Run path yet — or never started it. Confirm Managed apps shows the assignment, the device is checking in, and whether Program Files\Microsoft Office folders appeared. If folders never appear, fix enrollment/network/CDN first. If status is 997, wait and watch the Download folder. If you see 1603 or 17002, jump to those prerequisites instead of waiting longer.
Intune Microsoft 365 Apps failed with 1603. What does that mean?
Microsoft maps 1603 (ERROR_INSTALL_FAILURE) to prerequisite failures: installing Click-to-Run while MSI Office is present (side-by-side), 32/64-bit mismatch with an existing Office install, or other prereq checks. Turn on Remove other versions, confirm MSI is gone, align Architecture, then Sync. This is a different 1603 story than a Win32 MSI exit code in IME logs.
What's the difference between Microsoft 365 Apps install failed and a Win32 app install failed in Intune?
Microsoft 365 Apps uses Office CSP + ODT + the Office CDN. Win32 uses the Intune Management Extension (content download, install command, detection). Use this post for the built-in suite; use the Win32 install-failed triage for .intunewin packages. Microsoft also recommends Win32 when Office must be a tracked Autopilot ESP app.
Do I need to remove old MSI Office before Intune can install Microsoft 365 Apps?
Yes when MSI Office is present. Microsoft: the installation won't succeed if preexisting MSI Microsoft 365/Office apps remain, and Click-to-Run + Windows Installer Office on the same computer isn't supported. Use the suite's Remove other versions (Remove MSI) feature so Intune can uninstall MSI Office before Click-to-Run setup.
Can I assign two Microsoft 365 Apps deployments to the same device?
Microsoft says multiple Microsoft 365 deployments aren't currently supported — only one deployment is delivered to the device. Consolidate architecture, channel, and products into a single suite assignment rather than stacking Required apps.
Related posts
- Intune Win32 Required App Install Failed (IME content / exit codes — different app type)
- Intune Win32 app shows Failed after a successful install (detection)
- Autopilot ESP stuck — assignment-first checklist (ESP concurrency with Office)
- Company Portal can't connect / device not syncing (upstream check-in before any app install)
Free checklist
Office suite failures are still an enrollment-and-assignment hygiene problem: the same runway that keeps Required apps, ESP tracked apps, and pilot rings from becoming a Monday outage. The free Conditional Access pre-enforcement checklist is the one-pager we use before turning CA on harder:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=intune-microsoft-365-apps-not-installing
Admin Pack Studio; not affiliated with Microsoft. Steps 1–3 and the Graph/folder samples only read. Enabling Click-to-Run verbose logging, Remove MSI, Sync/retry, and suite edits are deliberate changes — take them in a change window, prefer one Microsoft 365 Apps deployment per device, and check current Microsoft Learn for portal labels and defaults.
Top comments (0)