The Wi-Fi profile went out yesterday. Some of the iPhones have it. The rest are sitting on Pending like they never got the memo. The policy itself is probably fine. Basic troubleshooting for Intune on an iPhone comes down to a short list of checks. Most of them happen in the admin center before you ever touch the phone.
Here is that list, in the order I would work it.
Start with the user
A lot of policy problems turn out to be user or enrollment problems wearing a policy costume. The Troubleshoot pane shows both in one place.
Intune admin center > Troubleshooting + support > Troubleshoot
Click Select user, pick the user with the problem, and click Select.
Look for a green check next to Intune license.
Find the iPhone in the Devices list.
The Troubleshoot pane with a user selected. The green check next to Intune license is the first thing to look for. Source: Microsoft Learn.
No license, no policies. If the green check is missing, the user needs an Intune license before anything else here matters.
In the Devices list, look at two columns. Managed should say MDM. Anything else means the phone is not enrolled, and it will not get configuration policies until it is. Last check in should be recent. Microsoft's own guidance says a check-in older than 24 hours points to a problem with the device. A phone that cannot check in cannot get your policies.
Make the iPhone check in
An enrolled iPhone checks in with Intune about every 8 hours. A newly enrolled one checks in every 15 minutes for the first hour, then drops to the normal schedule. When you assign or change a policy, Intune nudges the phone to check in early. Microsoft says that nudge can land right away or take a few hours. So a policy that went out 20 minutes ago and still says Pending is not a problem yet.
You can push it along from either end:
On the iPhone, open the Company Portal app, go to Devices, tap the device, and tap Check status. Older versions of the app call it Check Settings.
In the admin center, go to Devices > All devices, pick the iPhone, and click Sync.
Then have the user unlock the phone and leave it unlocked for a minute. An iPhone will hold off on some profiles while it sits locked. Intune reports this as error 2016341112, iOS device is currently busy. You usually see it when the phone restarted and nobody unlocked it yet, or when it is in the middle of an app install or an iOS update. Unlock it, let the update finish, and sync again.
The phone also has to reach Apple. Intune wakes iPhones up through Apple's push notification service. If a phone only misbehaves on one network, like a locked down guest Wi-Fi, try it on cellular.
Check who the policy is assigned to
If the policy never shows up for the device at all, it does not target that device. In the admin center, go to Devices > All devices, pick the iPhone, and click Device configuration. Every policy aimed at the phone shows up there with a status. If yours is missing, the phone is not part of the assignment.
To dig in, open the policy from Devices > Manage devices > Configuration > Policies tab and look at Assignments under Properties. Check these:
Is the user or the device in an included group?
Is the user or the device also in an excluded group? When both groups are the same type, the exclusion wins.
Does the assignment use a filter? A filter can quietly skip devices based on things like OS version, ownership, or model.
Two group mistakes come up a lot. First, user groups and device groups behave differently. A policy assigned to a user group follows that person to every device they enroll. A policy assigned to a device group stays with the device no matter who uses it.
Second, do not assign to a device group and then exclude a user group. Microsoft does not support that mix. Intune does not connect users to their devices for exclusions, so the user's iPhone still gets the policy. Dynamic device groups also take a while to fill in after a phone enrolls, and the policy does not reach the iPhone until it lands in the group.
Why it says Not applicable
Not applicable means the phone cannot take the policy at all. On iPhones that usually comes down to supervision, the enrollment type, or the iOS version.
Supervised-only settings
A lot of iPhone restrictions only work on supervised devices. Supervised mode is for company-owned phones. They usually get it by enrolling through Automated Device Enrollment, which is the Apple Business Manager setup, or through Apple Configurator. Microsoft's restriction settings reference lists which enrollment types each setting applies to. If a setting only lists supervised Automated Device Enrollment, a regular phone skips it.
To check a phone, open Settings. A supervised iPhone shows a line at the very top saying this iPhone is supervised and managed by your organization. No line, no supervision. Intune cannot turn supervision on after enrollment. The only way is Apple Configurator, and it resets the phone.
Personal phones
Personal iPhones often use Apple User Enrollment. The user adds their work account under Settings > VPN & Device Management. That keeps work data on its own separate volume, away from personal stuff, and it gives Intune a much smaller set of controls. Supervision is off the table. If an existing policy lands on one of these phones, only the settings User Enrollment supports take effect. The phone ignores the rest.
Old iOS versions
Some settings need a newer version of iOS. If the phone is behind, the policy shows Not applicable until it updates. Check the version on the phone under Settings > General > About, and look for updates under Settings > General > Software Update.
One Not applicable is harmless. If an iPhone policy lands on a group that also has Android phones, those Android phones show Not applicable because the policy was never meant for them.
Conflicts and errors
Conflict means two policies set the same setting to different values, or something already on the phone stops Intune from changing it. Intune does not pick a winner between configuration policies. Someone has to fix it by hand.
Open the policy and click Per setting status. That shows exactly which setting is fighting. Then go find the other policy that sets it. Check the settings catalog, the device restriction templates, and the compliance policies. When a compliance policy and a configuration policy touch the same setting, the compliance policy wins.
A policy's status counts, with the Device assignment status and Per setting status reports underneath. Source: Microsoft Learn.
Custom profiles are the sneaky ones. If someone uploaded a .mobileconfig file as a custom profile, Intune delivers it without reading what is inside. If it fights with another policy, Microsoft's docs say Apple applies the settings randomly. Fun.
For Error, click into the device on the policy report. Most errors come with a code you can search on Microsoft Learn. Put that code in the ticket either way.
If someone loosens a policy, some iPhones hold on to the stricter version, and that looks like a conflict. Microsoft's fix for that is to retire the phone and enroll it again. That is a bigger job, so escalate it.
Profiles that depend on other profiles
Wi-Fi, VPN, and email profiles often use certificates to sign in. The Wi-Fi profile points to a client certificate profile, either SCEP or PKCS, and usually a trusted root certificate profile too. If those certificate profiles fail, or they do not go to the same users or devices, the Wi-Fi profile fails right along with them.
So when a Wi-Fi profile errors out, check the certificate profiles for that same iPhone first. Fix those, sync, and the Wi-Fi profile usually follows.
When every iPhone stops at once
If one phone is broken, it is a phone problem. If every iPhone and iPad in the company stopped getting policies on the same day, check the Apple MDM push certificate before anything else. Intune needs it to talk to Apple devices at all. It lasts 365 days, and someone has to renew it every year.
Intune admin center > Devices > Device onboarding > Enrollment
Select the Apple tab.
Click Apple MDM Push Certificate.
Check the Status and the Days until expiration.
The Apple MDM Push Certificate pane. Status and Days until expiration sit right at the top. Source: Microsoft Learn.
If it expired or is about to, escalate right away. After it expires there is a 30-day grace period to renew it, and the renewal has to use the same Apple ID that created it. Whoever handles it should renew the existing certificate, not create a new one. A brand new certificate means enrolling every Apple device again. That is a very long week.
While you are in there, check Tenant administration > Tenant status for active incidents. Sometimes the problem really is Microsoft.
What the iPhone can tell you
The phone keeps its own list of what Intune installed. Go to Settings > General > VPN & Device Management, tap the management profile, and tap More Details. You will see the profiles, restrictions, and certificates the phone actually has.
In basic troubleshooting for Intune on an iPhone, this is a quick way to cut the problem in half. If the Wi-Fi profile is in that list but the phone still will not connect, the profile arrived fine and the problem is the network or the certificate. If it is not in the list, go back to check-ins and assignments.
The basic troubleshooting checklist for iPhones
Basic troubleshooting on an iPhone with Intune is mostly the same handful of checks in the same order every time:
Confirm the user has an Intune license in Troubleshooting + support.
Confirm the iPhone shows Managed as MDM and has a recent last check-in.
Unlock the phone, then sync from the Company Portal or the admin center.
Make sure the policy shows in the device's Device configuration list.
Check the policy's included groups, excluded groups, and filters.
For Not applicable, check supervision, enrollment type, and iOS version.
For Conflict, use Per setting status to find the other policy.
For Wi-Fi, VPN, or email failures, check the certificate profiles first.
If every Apple device stopped at once, check the Apple MDM push certificate.
Look under VPN & Device Management on the phone to see what actually arrived.
If you escalate, include the user, the device name and serial number, the iOS version, whether the phone is supervised, the policy name, its status, any error code, and the last check-in time.
What can we learn as a person
Apple's MDM protocol has a status called NotNow. The phone got the command, it just cannot do it at the moment, so it says so and checks back later. I like how honest that is. It does not pretend it finished, and it does not ignore the request forever.
I send NotNow a lot. The doctor's appointment, the conversation I owe someone. The difference is the iPhone actually polls the server again later. I mostly do not. The command just sits at Pending until somebody notices my last check-in date is way too old.
So what have you been answering with NotNow? And when did you last check back in on it?
An iPhone three versions behind is a security ticket waiting to happen. A store tablet that updates itself in the middle of the holiday rush is a different kind of ticket. Intune Apple and Android updates work nothing like Windows update rings. Apple also just changed how its side works, so the policies a lot of tenants built a few years ago are on their way out.
Apple moved updates to declarative device management
The old way had Intune send an update command to the iPhone and then keep asking how it was going. With declarative device management, or DDM, Intune tells the device the version it needs and the deadline. The device handles the rest and reports its own progress.
Apple deprecated the old update commands in its 26 releases and drops them completely in the 27 releases. Microsoft says it is removing the legacy iOS/iPadOS and macOS update policies from Intune in the coming months. If you still have policies under Devices > Apple updates, plan to replace them now.
DDM updates need iOS/iPadOS 17 or newer, or macOS 14 or newer.
They work with Device Enrollment and Automated Device Enrollment, not User Enrollment.
On a Mac, enforcing a version needs a supervised device. On an iPhone, it works supervised or not.
On iPhones, the deferral and automatic install controls only work on supervised devices.
Create a DDM update policy
Intune admin center > Devices > Manage devices > Configuration > Create > New policy
Pick iOS/iPadOS or macOS, then Settings catalog.
Click Add settings and open Declarative Device Management.
Pick Software Update to target a specific version, or Software Update Enforce Latest to always chase the newest one.
Fill in the settings and assign it to a device group.
Target OS Version: The version devices must reach, like 26.0.
Target Build Version: Optional. If it disagrees with the OS version, the OS version wins.
Target Date Time: The deadline, in the device's own time zone.
Details URL: A link users see in the update prompt, like your IT help page.
For Software Update Enforce Latest: Delay in Days and Install Time, in 24-hour format.
At the deadline, the device shows a one-minute countdown, then installs and restarts. A device that was powered off gets one hour after it powers back on. If the device sits idle before the deadline, it may install early.
Software Update Settings
The same Declarative Device Management area has a Software Update Settings category. It controls whether standard users can install updates, automatic downloads and installs, and Apple's fast security fixes, which Apple now calls Background Security Improvements. It can also hide updates for a set time, offer major or minor updates, and keep update notifications quiet until an hour before the deadline. These replace the old Defer software updates and Delay visibility of software updates settings in device restrictions.
What users see
The reminders get more frequent as the deadline gets close. Do Not Disturb is ignored for the last 24 hours. An iPhone needs the passcode to start the update. At the deadline, a Mac force quits every open app, so warn people to save their work.
A required managed update notification on a Mac. Source: Microsoft Learn.
Checking Apple updates
Go to Reports > Device management > Apple updates. The Summary tab shows the latest version for iOS, iPadOS, and macOS, and how many devices are up to date, waiting, downloading, installing, or failed. The Reports tab has the Apple software update report with per-device detail.
The Apple updates Summary report for macOS, iOS, and iPadOS. Source: Microsoft Learn.
For one device, open it and look under Monitor for iOS software updates or macOS software updates. Devices > Monitor > Apple software update failures lists the ones that did not make it. On the device itself, check Settings > General > Software Update on an iPhone, or System Settings > General > Software Update on a Mac.
Apple update gotchas
Succeeded on the policy only means the policy landed. Check the actual OS version on the device.
A device already newer than the target shows an error because it looks like a downgrade. Retire old policies when you raise the target.
If the target version does not exist for that model, the device keeps the policy and waits.
If a user turned off automatic updates on their iPhone, a policy cannot turn them back on.
Low battery, low storage, or a powered-off device at the deadline all delay the install.
Android system updates
For company-owned Android devices, meaning fully managed, dedicated, and corporate-owned work profile, updates live in a device restrictions profile. Go to Devices > Manage devices > Configuration > Create, pick Android Enterprise and Device restrictions, and open General. If those enrollment types are new to you, start with Android Enterprise management types.
Device Default: Installs when the device is on Wi-Fi, charging, and idle.
Automatic: Installs updates as soon as they are available.
Postponed: Holds updates for 30 days, then prompts the user. Some manufacturers still push security updates anyway.
Maintenance window: Installs only during a daily time window you pick, and keeps trying for 30 days. Low battery or storage makes it fail.
An Android maintenance window from 6 to 8 in the morning. Source: Microsoft Learn.
Freeze periods for system updates block updates completely for up to 90 days, which is handy for a store during the holidays. Dates use MM/DD, and each freeze has to be at least 60 days apart from the next. It needs Android 9 or newer. Not every manufacturer supports these controls, so test on your actual hardware.
Firmware over the air for Samsung and Zebra
Intune can also push manufacturer firmware updates to Samsung and Zebra devices. It is an Intune Plan 2 feature. Microsoft 365 E3 and E5 have included Plan 2 since July 1, 2026, and existing tenants get access by August 2026. Connect it under Tenant administration > Connectors and tokens > Firmware over-the-air update, then create deployments under Devices > Android > Manage updates > Android FOTA deployments.
Samsung needs a Knox E-FOTA license, a Knox admin account, and Managed Google Play. The Knox E-FOTA app also goes on the device, and the user accepts its terms once. Zebra LifeGuard works on fully managed and dedicated devices only. Zebra deployments do not retry after a failure, and you can never downgrade, because a downgrade wipes the device. I covered getting them enrolled in enrolling Zebra scanners into Intune.
A plan for Intune Apple and Android updates
Replace any legacy Apple update policies with DDM Software Update policies before Apple's 27 releases arrive. Give users a real deadline and a Details URL that explains it. For Android, pick a maintenance window on company devices and add freeze periods for your busy seasons. Then check the Apple updates report weekly, because Intune Apple and Android updates only work if someone looks at the failures.
What can we learn as a person
Android has a rule I love. You can freeze system updates for up to 90 days, like over the holidays at a store. But each freeze has to sit at least 60 days apart from the next one. You cannot stack them into a permanent freeze.
I stack them. Busy season, then a hard month, then a big project, and every time I tell myself the change can wait until things calm down. Things never calm down, so the freeze never lifts, and the updates I actually need pile up.
How long has your freeze been running? And what would happen if you let one update through before the next busy season starts?
The user says it is doing the thing again, and they cannot describe the thing. You need to see their screen. Quick Assist works, but anyone can use it, including the scammer who called them yesterday pretending to be IT. Intune Remote Help does the same job with both people signed in, verified, and logged.
Remote Help vs Quick Assist
With Remote Help, both the helper and the user sign in with work accounts from your company, and it only works inside your own tenant. Before the user lets anyone in, they see the helper's full name, job title, company, photo, and verified domain. The helper sees a warning if the user's device is not compliant. Roles decide who can only look and who can take control, and every session gets logged.
Quick Assist has none of that. It has no roles, the person sharing their screen never signs in, and they only see the helper's first name and last initial. Microsoft's own Quick Assist page recommends Remote Help for companies working within one tenant.
Some companies block Quick Assist by blocking remoteassistance.support.services.microsoft.com. Remote Help uses that same address, so that block breaks it too.
Licensing
Microsoft's Intune licensing page lists Remote Help as part of Intune Plan 2, which the Intune Suite includes. Microsoft also announced that Microsoft 365 E3 and E5 include Intune Plan 2, Remote Help and all, starting July 1, 2026. Existing tenants get access by August 2026. Check what your tenant actually has before you plan around it. Both the helper and the user need a license, and new licenses can take 30 minutes to 8 hours to kick in.
Turn it on
Intune admin center > Tenant administration > Remote Help
Open the Settings tab and click Configure.
Set Enable Remote Help to Enabled.
Decide on Allow Remote Help to unenrolled devices. Allowed lets you help people on devices Intune does not manage.
Set Disable Chat to Yes if you do not want the chat window, then click Save.
The Configure Remote Help pane. Remote Help is off until you enable it here. Source: Microsoft Learn.
Give the helpdesk permission
A helper needs three things in their Intune role: Remote tasks: Offer remote assistance, Remote Assistance Connector: Read, and at least one Remote Help app permission. Those are View screen, Take full control, and Elevation, plus newer unattended control options.
The built-in Help Desk Operator role has all of them except unattended control on Windows. Microsoft suggests least privilege, like view-only for tier 1 and full control for tier 2. Build those custom roles under Tenant administration > Roles > All roles > Create. If you help people on unenrolled devices, scope the role to a user group. The All devices scope does not include unenrolled devices.
Install the Remote Help app
Both computers need the Remote Help app. Download it from aka.ms/downloadremotehelp, rename the file to remotehelpinstaller.exe, and wrap it with IntuneWinAppUtil to make a Win32 app. Use these commands:
Those switches care about uppercase and lowercase, so type acceptTerms exactly. The app updates itself by default. Add enableAutoUpdates=0 to the install command if you would rather control updates yourself.
For the detection rule, use a File rule on C:\Program Files\Remote Help, file RemoteHelp.exe, with a String (version) check of Greater than or equal to the version you packaged. Get that version number with:
Assign it to device groups. Remote Help is also in the Enterprise App Catalog if you have it. Macs get their own download at aka.ms/downloadremotehelpmacos and need the Accessibility and Screen Recording permissions. Android support covers Samsung and Zebra devices in dedicated mode.
Start a session
Intune admin center > Devices > All devices, and pick the device.
Click New remote assistance session, choose Remote Help, and click Continue.
Choose Initiate attended control.
The user gets a notification and clicks Open Remote Help. On your side, click Open Remote Help and sign in.
Ask for screen sharing or full control. The user sees who you are and picks Allow or Decline.
Either of you clicks Leave to end the session.
The notification the user gets when you start a session from Intune. Source: Microsoft Learn.
If the notification never shows up, use a security code instead. In the Remote Help app, under Give help, click Get a security code and read it to the user. They type it into their Remote Help app and click Submit. This is also how you help someone on an unenrolled device.
Admin prompts and unattended control
With the Elevation permission, you can answer admin prompts during the session. If the user ends a session where you used elevation, Windows signs them out, so let them know before they click Leave.
Windows now also supports unattended control, where you take over a device with nobody sitting at it. It needs a physical, company-owned 64-bit device with Remote Desktop turned on, plus a separate permission. When you start a session on a device that qualifies, Intune asks which kind you want.
Choosing attended or unattended control when you start a session. Source: Microsoft Learn.
See who helped whom
Go to Tenant administration > Remote Help. The Monitor tab shows active sessions and history. The Remote Help sessions tab lists the helper, the user, the device, the start and end times, and the session type. That data stays for 30 days. The reports do not show whether elevation was used during a session.
When Remote Help will not connect
It says Remote Help is not enabled: Check the tenant setting, and remember new licenses can take hours to activate.
The helper cannot start a session: Their role is missing a permission, or the device or user is outside the role's scope.
The notification never arrives: Check for Do Not Disturb, policies that block notifications, and the Intune Management Extension service. That service is slow to start after a reboot, and newly enrolled devices can take an hour. Use the security code meanwhile.
Intune thinks the app is installed when it is not, or the other way around: The version in your detection rule is wrong.
WebView2 errors 1001, 1002, or 1003: Update Microsoft Edge or install WebView2.
The user is in another company's tenant: Remote Help does not work across tenants.
Remote Help needs TCP 443 to addresses like *.support.services.microsoft.com and remotehelp.microsoft.com, and Microsoft says to exclude them from SSL inspection. On the device, install logs land in the %TEMP% folder, and session events are in Event Viewer under Applications and Services Logs > Microsoft > Windows > RemoteHelp.
Rolling out Intune Remote Help
Confirm your licenses, turn on Intune Remote Help in Tenant administration, and push the app to every device as a Win32 app. Give tier 1 a view-only role and tier 2 full control, run one test session end to end, and then retire Quick Assist from your helpdesk process.
What can we learn as a person
Remote Help has two levels. The helper can ask to view your screen, or ask for full control. A lot of sessions never need more than the view. Someone just has to see what you are seeing.
I am bad at the view level. When something is wrong, I either hand someone full control of the whole mess or let nobody see anything at all. There is no middle setting where I just let a friend look at the screen and say, yeah, that is weird, I see it too.
Who could you share your screen with, without handing over control? And what would it feel like to just let someone see it?
The ticket says the app won't install. That is the whole ticket. No error message, sometimes no app name, just one sad sentence and a user who needs it working before their 2 o'clock. Most failed installs come down to a short list of boring causes. Basic troubleshooting clears most of them before anyone needs to escalate.
This is that list, in the order I would check it.
Get the exact error first
Basic troubleshooting starts with the words on the screen. "It failed" is not an error. "This app can't run on your PC" is an error, and it points to a completely different fix than "Another installation is already in progress." Ask the user for a screenshot. If they closed the window, have them run it again while you watch.
Then ask a few questions:
What app, and what version?
Where did the installer come from? The vendor's website, an email, a USB drive, the Company Portal?
What exactly did the screen say? Was there a number, like 1603?
Has it ever worked on this computer, or on anyone else's?
If the same installer works on the computer next to it, the problem lives on this machine. If it fails everywhere, the problem is the installer, and you can stop poking at the user's laptop.
Blocked files
Windows keeps track of where a file came from. When you download something from the internet or save it out of an email, Windows tags it as coming from another computer. Microsoft calls this the Mark of the Web. Most installers still run with that tag. Some throw a warning, and some quietly refuse to start.
The first thing you usually see is a blue box that says Windows protected your PC. That box comes from Microsoft Defender SmartScreen, and it shows up when Windows does not recognize the app yet. Clicking More info shows a Run anyway button. Only use it when you know the file came from the real vendor site or your company's own file share. If you are not sure where the file came from, stop there and ask.
How to unblock a file
Right-click the installer file and pick Properties.
Stay on the General tab and look at the bottom of the window.
If you see "This file came from another computer and might be blocked to help protect this computer," check the Unblock box.
Click Apply, then OK.
Run the installer again.
The Unblock checkbox at the bottom of a file's Properties window. This example is a Word file, but installers show the same box. Source: Microsoft Learn.
No Unblock box means the file is not tagged, and you can move on. If the installer came inside a zip file, unblock the zip before you extract it. Otherwise every file inside picks up the tag too. PowerShell can do it in one line:
Sometimes Windows Security or your antivirus grabs the installer and quarantines it. The file just vanishes, or the install dies halfway through. Check Windows Security > Virus & threat protection > Protection history. If the installer shows up there, do not restore it yourself. Send it to whoever owns security, because sometimes the antivirus is right.
Newer Windows 11 computers may also have Smart App Control turned on. It stops apps that Microsoft does not recognize and that do not carry a trusted signature. You can see its status under Windows Security > App & browser control. Do not turn it off to get one app working. Escalate it.
The wrong version for the computer
Most apps get built for a specific kind of Windows. Grab the wrong one and the installer either refuses to start or says This app can't run on your PC. Two things to check here: the processor type and the Windows version.
32-bit, 64-bit, and ARM
Go to Settings > System > About and look at System type under Device specifications. You will see something like 64-bit operating system, x64-based processor. Here is what those words mean for installers:
x64 is the normal 64-bit Windows that most business computers run. It runs x64 apps and older 32-bit apps.
x86 means 32-bit. A 32-bit copy of Windows cannot run 64-bit apps at all. Windows 11 only comes in 64-bit, so you will only see this on older Windows 10 machines.
ARM64 means an ARM processor, like the Snapdragon chips in some newer Surface and Copilot+ laptops. Windows 11 on ARM runs most normal apps through emulation, but drivers do not emulate. VPN clients, antivirus agents, and printer drivers often need their own ARM64 version.
When you download, match the file to the system type. Vendors usually put x64, x86, or ARM64 right in the file name or on the download page.
Windows version and S mode
Some apps need a minimum version of Windows. Press Windows key + R, type winver, and press Enter. The window that opens shows the version and build number. Compare that to the system requirements on the vendor's site.
Then there is S mode. A computer in S mode only runs apps from the Microsoft Store, so regular .exe and .msi installers will not run. Check Settings > System > Activation. If the edition name ends in S mode, that is your answer. Switching out of S mode is a one-way trip, so get approval before you do it.
No admin rights
Most installers want to write to C:\Program Files, and that takes admin rights. On a standard account, the installer pops up a User Account Control box asking for an admin username and password. If the user does not have one, the install stops right there.
Do not hand the user an admin password to get past this. Use whatever your company already uses to install apps for people. That might be the Company Portal, a remote session where you enter your own admin account, or a request to the team that packages apps. Some installers offer a "just for me" option that installs into the user's profile with no admin needed. Those can be fine, but check your company's policy first.
Error 1625 reads This installation is forbidden by system policy. That means a policy on the computer blocked it on purpose. Do not try to work around it. Escalate it.
Something else is already installing
Windows Installer can only run one install at a time. If something else is mid-install, the new one fails with error 1618, Another installation is already in progress. The something else is usually Windows Update, a silent install your company pushed, or an earlier attempt that hung.
Open Settings > Windows Update and look for anything installing or waiting on a restart. Give it a few minutes. If nothing changes, restart the computer and try again. A restart clears most stuck installs and finishes updates that were waiting on a reboot.
While we are on reboots, two codes look like failures and are not. 3010 means the install worked and needs a restart to finish. 1641 means the installer kicked off that restart itself. Both count as success. Restart the machine and test the app before you call it broken.
An old version is in the way
Error 1638 says another version of this product is already installed. That one is at least honest. Other times the old version is half removed, or a failed install left pieces behind, and the new install trips over them.
Go to Settings > Apps > Installed apps.
Search for the app name.
Click the three dots next to it and pick Uninstall.
Restart the computer.
Run the new installer again.
If the old version refuses to uninstall, or it is not in the list but the installer still complains, escalate. Cleaning leftover registry entries by hand can break other apps, so leave that to whoever has a test machine.
Missing pieces and full disks
Some apps need other software in place first. The classic one is an error saying VCRUNTIME140.dll was not found, or MSVCP140.dll is missing. Those files come from the Microsoft Visual C++ Redistributable. Download it from Microsoft's own site, never from a random DLL download site, install it, and try the app again.
Older apps sometimes need .NET Framework 3.5. Go to Control Panel > Programs > Turn Windows features on or off, check .NET Framework 3.5, and click OK. Windows downloads the files for this from Windows Update. If that download fails, the computer probably is not allowed to reach Windows Update directly, and you should escalate.
And check disk space under Settings > System > Storage. An installer that runs out of room halfway through can fail with a generic error that never mentions space at all.
Where the real error hides
When the screen only says the install failed, the logs usually say why.
Event Viewer
Press Windows key + R, type eventvwr.msc, and press Enter.
Go to Windows Logs > Application.
Click Filter Current Log on the right side.
In Event sources, pick MsiInstaller and click OK.
Look at the entries from the time the install failed. MSI installs write a line with the product name and an error status number. That number goes in your ticket.
A detailed install log
If the installer is an .msi file, you can make it write a detailed log. Open Command Prompt as admin and run this, swapping in your own paths:
The log will be long and ugly. Open it in Notepad and search for Return value 3. The lines just above it usually show what broke.
Here are the codes you will see the most:
Code
What it means
What to try
1603
A fatal error happened during the install. This is the generic one.
Read the log. Admin rights, a pending restart, and an old version are common causes.
1618
Another install is already running.
Wait, then restart the computer.
1619
The installer package could not be opened.
Download it again, or copy it to the computer instead of running it from a network share.
1625
System policy blocked the install.
Escalate.
1633
The package does not support this platform.
Get the right x64, x86, or ARM64 version.
1638
Another version is already installed.
Uninstall the old version first.
3010
Success, but a restart is needed.
Restart and test.
When Intune does the installing
In a lot of companies, users never run installers at all. Microsoft Intune pushes the app, or the user picks it from the Company Portal. Everything above still applies. You just look in different places.
On the computer
Open the Company Portal and check the app's status. If it failed or sits on pending, force a check-in. Go to Settings > Accounts > Access work or school, click the work account, click Info, and click Sync. Give it a few minutes.
Win32 apps from Intune install through the Intune Management Extension. Its logs live in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. AppWorkload.log is the main one for apps. It covers app check-ins, installs, applicability, and detection. CMTrace makes these logs much easier to read, but Notepad works in a pinch.
The Intune Management Extension log folder on a Windows device. AppWorkload is the one to open for app installs. Source: Microsoft Learn.
If nothing seems to happen at all, open services.msc and restart the Microsoft Intune Management Extension service. That kicks off a fresh check for apps.
In the Intune admin center
If you have access to the Microsoft Intune admin center, you can see the same failure from the admin side:
Intune admin center > Troubleshooting + support > Troubleshoot
Click Select user, search for the user, and click Select.
Pick the device from the Devices list.
Click Managed Apps.
Click any app with a failed installation status to see the installation details and the error code.
Managed Apps in the Intune troubleshooting pane, with a failed app's installation details and error code on the right. Source: Microsoft Learn.
To see one app across every device, go to Apps > All Apps, pick the app, and open Device install status under Monitor. For Win32 apps, the installation details pane also has a Collect logs option that pulls the logs off the device for you.
If a Win32 app installs as the user and the installer needs admin rights, it fails every time, because a standard user does not have those rights. That gets fixed in how the app is packaged, not on the laptop.
The basic troubleshooting checklist
None of this is fancy. Basic troubleshooting is mostly asking good questions and checking the boring stuff in the same order every time. Work it top to bottom:
Get the exact error message and a screenshot.
Find out where the installer came from, and whether it works on another computer.
Check the file's Properties for an Unblock box, and check Protection history.
Confirm the system type and Windows version match the app, and that the computer is not in S mode.
Run the install with admin rights through your company's normal process.
Restart the computer and try again.
Remove any old version, restart, and reinstall.
Check disk space and prerequisites like Visual C++ and .NET Framework 3.5.
Pull the error code from Event Viewer or the install log.
For Intune apps, check the Company Portal, sync, and read AppWorkload.log.
If you escalate, put the app name and version, the exact error and code, the system type, the Windows version, and what you already tried in the ticket.
What can we learn as a person
Error 1618 is the one I think about outside of work. Windows can only run one installer at a time. If something is still installing, the next thing waits or it fails. Double clicking harder does not help.
I do this to myself all the time. I start a new routine and a new project in the same week, while the last thing is still half installed, and then I wonder why nothing finishes. And when something does finish, I skip the restart. Error 3010 means the install worked and just needs a reboot before it takes. I keep forgetting that rest is part of finishing.
So what is still installing in you right now? And what are you trying to start on top of it before it is done?
Autopilot used to mean one thing. Grab the hardware hash, upload it, build a profile, and watch the Enrollment Status Page crawl. Now there is a second Autopilot, and Microsoft calls it a re-architecture. Autopilot device preparation skips the hardware hash and the Enrollment Status Page, but it also skips a few things you might be counting on.
Device preparation does not do pre-provisioning, self-deploying mode, Autopilot Reset, hybrid join, co-management, or Windows 10. It also cannot hold the user at setup until their user-based settings finish. Microsoft describes it as simpler and faster but less feature rich.
Which one should you use?
If your devices are cloud only and run Windows 11, device preparation is the easier road. If you need hybrid join, kiosks with self-deploying mode, or pre-provisioning, stay on classic. Both can live in the same tenant, but a single device only runs one of them. Your existing classic profiles do not need to move.
Watch out for devices that already have a hardware hash uploaded. A registered device runs the classic profile, not device preparation. To switch one over, deregister it from classic Autopilot first.
Set up Autopilot device preparation
Step 1: The device group
Device preparation drops each new device into a group during setup. Create a security group in Groups > New group with Membership type set to Assigned and Microsoft Entra roles can be assigned to the group set to No. Under Owners, add Intune Provisioning Client. In some tenants it shows up as Intune Autopilot ConfidentialClient. If it is missing entirely, create it with Microsoft Graph PowerShell:
Intune admin center > Devices > Device onboarding > Enrollment, on the Windows tab.
Under Windows Autopilot device preparation, open Device preparation policies and click Create, then User Driven.
On Device group, pick the group from Step 1.
On Configuration settings, set the options below and pick the apps and scripts to install during setup.
On Assignments, pick the group of users who will set up devices.
Review + create.
Join type: Microsoft Entra joined.
User account type: Standard User or Administrator. Standard User keeps people from becoming local admins.
Minutes allowed before showing installation error: Anywhere from 15 to 720.
Custom error message, Allow users to skip setup after multiple attempts, and Show link to diagnostics: These control what the user sees when it fails.
Apps and scripts you pick here must also be assigned to the device group and set to install in the System context. Anything else assigned to that device group installs after the user reaches the desktop. If you have more than one policy, drag them into order. The lowest number wins.
Device preparation shows this progress screen instead of the Enrollment Status Page. Source: Microsoft Learn.
If a user sees the classic Enrollment Status Page instead of this screen, the device is running classic Autopilot, not device preparation.
Classic pre-provisioning
Pre-provisioning, which used to be called White Glove, lets IT or a partner run the slow device part of setup ahead of time. The user's part on day one gets much shorter.
Pre-provisioning moves most of the setup work from the user to IT or a partner. Source: Microsoft Learn.
It needs a physical device with a TPM 2.0 chip, because virtual machines are not supported. It also needs Windows Pro, Enterprise, or Education, an Enrollment Status Page assigned to the device, and Allow pre-provisioned deployment set to Yes in the deployment profile. Use a network cable if you can. Wi-Fi forces extra region and keyboard screens.
The technician steps
Power on the device and wait for the work or school sign-in screen.
Press the Windows key five times.
Choose Pre-provision with Windows Autopilot and click Next.
Check the organization, profile, and assigned user, then click Provision.
Wait while the device part of setup runs.
On success, click Reseal and box it up. On failure, pick Retry or Reset, and press Ctrl+Shift+D to export logs first.
The technician phase installs everything aimed at the device, plus device-context apps aimed at the assigned user. The user phase installs the rest. Error 0x80180005 means someone tried to pre-provision with a profile that does not allow it.
Device name templates
Classic deployment profiles have an Apply device name template setting. Names can be 15 characters at most, use letters, numbers, and hyphens, and cannot be all numbers. %SERIAL% adds the serial number, and %RAND:x% adds x random digits, so HQ-%RAND:5% gives you something like HQ-48213. Templates only work with Entra join. Hybrid profiles only let you set a prefix.
Troubleshooting Autopilot
Start with the reports. Devices > Monitor > Windows Autopilot device preparation deployments shows each phase and each app for device preparation. Devices > Monitor > Windows Autopilot deployment status covers classic Autopilot.
On the device during setup, Ctrl+Shift+D opens the diagnostics page on Windows 11. For classic Autopilot, the Enrollment Status Page has to allow it first. Shift+F10 opens a command prompt, where this command bundles the Autopilot logs:
Intune can also grab logs on its own when Autopilot fails. That setting lives under Tenant administration > Device diagnostics, and the logs show up on the device page under Diagnostics.
The Device diagnostics page, including the option to capture logs automatically when Autopilot fails. Source: Microsoft Learn.
Common problems
The device preparation screen never shows up: The device has a hardware hash registered, the user is not in the policy's user group, the policy has no device group, or Windows is too old.
Apps show Skipped: They are not assigned to the device group or are not set to install in the System context.
The device group will not save or shows 0 groups: Intune Provisioning Client is not an owner of the group.
Classic event 807 or 815 in the Autopilot event log: The device is not registered, or it has no profile assigned.
Error 0x800705B4: A timeout, often a device without TPM 2.0 or a virtual machine.
Error 0x80180014: A device that went through self-deploying or pre-provisioning is being reused. Unblock it from the Windows Autopilot devices list or delete its record.
The Autopilot event log is in Event Viewer under Applications and Services Logs > Microsoft > Windows > ModernDeployment-Diagnostics-Provider > Autopilot.
Picking your Autopilot path
Use Autopilot device preparation for new cloud-only Windows 11 devices and keep classic Autopilot for hybrid join, kiosks, and pre-provisioning. Build the device group with the right owner first, keep setup apps to the ones people need on day one, and check the deployment report after your first few devices.
What can we learn as a person
Pre-provisioning exists because nobody wants to watch apps install on their first morning. IT does the heavy part ahead of time, reseals the box, and the user's part is short.
I do not pre-provision anything. Every Monday starts from bare metal. No lunch packed and no idea what the first task is, and then I wonder why the first two hours feel like an Enrollment Status Page that never finishes.
What could you pre-provision for future you tonight? And what is one thing you could reseal and hand to tomorrow already done?
A laptop left in a cab is an embarrassing day. An unencrypted laptop left in a cab is a breach notification. An Intune BitLocker policy encrypts every Windows drive without asking the user anything, stores the recovery key where the helpdesk can find it, and tells you which machines are not encrypted yet.
I covered where to find BitLocker keys before. This post is about building the policy so those keys exist in the first place.
Create the BitLocker policy
Intune admin center > Endpoint security > Disk encryption
Click Create Policy, set Platform to Windows and Profile to BitLocker, then click Create.
Name it, set the settings below, and assign it to a device group.
Most BitLocker settings only apply the first time a drive gets encrypted. If a drive is already encrypted a different way, changing the policy later does not redo it. Deliver your Intune BitLocker policy early, ideally during Autopilot setup.
Silent encryption
Silent encryption means BitLocker turns on with no prompts and no user involvement. Users never see a wizard and never get asked whether they want it. To make that happen, these settings have to line up:
Require Device Encryption: Enabled.
Allow Warning For Other Disk Encryption: Disabled. This hides the prompt about other encryption software.
Allow Standard User Encryption: Enabled. It only shows up after you disable the previous setting, and it lets encryption run when the signed-in user is not an admin.
The two settings that start silent encryption, with Allow Standard User Encryption right under them. Source: Microsoft Learn.
The operating system drive settings also have to stay out of the way. Set Require additional authentication at startup to Enabled. Then set Configure TPM startup to Allow TPM or Require TPM, and set the startup PIN, the startup key, and the startup key and PIN options to Do not allow. If any of those require a PIN, the user has to type something, and silent encryption fails.
What the device needs
Windows 10 1809 or newer, or Windows 11, on Pro, Enterprise, or Education.
Entra joined or hybrid joined.
A TPM chip, UEFI firmware rather than legacy BIOS, and Secure Boot turned on.
The Windows Recovery Environment turned on.
For the encryption method, Microsoft recommends XTS-AES. If you leave the setting alone, BitLocker uses XTS-AES 128, and 256 works well on newer hardware. If you set the method at all, set it for operating system, fixed, and removable drives together, or the policy fails. Intune's own default for fixed and removable drives is AES-CBC, so pick XTS-AES there on purpose. USB drives that also plug into non-Windows machines should stay on AES-CBC.
Recovery keys
Under Choose how BitLocker-protected operating system drives can be recovered, turn on saving recovery information and turn on Do not enable BitLocker until recovery information is stored. The setting names mention AD DS, but on Entra joined devices they control the backup to Entra ID. Hybrid joined devices back up to both.
Also set Configure Recovery Password Rotation so a key changes after someone uses it. Rotation only works when the store-before-enabling setting is on.
Who can see the key
Admins find it under Devices > All devices, then the device, then Monitor > Recovery keys > Show Recovery Key. Every view gets logged. Helpdesk Administrator, Cloud Device Administrator, and Intune Administrator can read keys. If Intune says No BitLocker key found for this device, the key never made it to Entra ID.
Users can get their own key without calling you. On the Company Portal website, they go to Devices, pick the PC, and click Get recovery key. They can also use myaccount.microsoft.com under Devices. The key hides again after 5 minutes.
Users can pull their own recovery key from the Company Portal website. Source: Microsoft Learn.
If you would rather users call the helpdesk, turn on Restrict non-admin users from recovering the BitLocker key(s) for their owned devices in the Entra Device settings. Deleting a device in Entra ID deletes its BitLocker keys too.
Removable drives
Deny write access to removable drives not protected by BitLocker makes every unencrypted USB drive read-only. People can still open files from a thumb drive but cannot copy company files onto one unless it is encrypted. Test this one with a pilot group first, because it surprises people.
Checking encryption
Intune has an encryption report that lists every Windows device with its TPM version, encryption readiness, and encryption status. Find it under Devices > Monitor. Microsoft's own pages give it slightly different names. It can take up to 24 hours to update, it only covers the operating system drive, and you can export it to CSV.
On the device itself, open Command Prompt as admin and run:
manage-bde -status c:
manage-bde -status shows the encryption state, the method, and the key protectors. Source: Microsoft Learn.
Fully Encrypted with Protection On is what you want. The Numerical Password listed under Key Protectors is the recovery password. PowerShell gives the same answer with Get-BitLockerVolume -MountPoint C | Format-List. The detailed log is in Event Viewer under Applications and Services Logs > Microsoft > Windows > BitLocker-API > Management.
When encryption will not start
Failed to enable Silent Encryption with a note about conflicting settings: Something allows or requires a startup PIN or key. Check every policy, including the Defender for Endpoint security baseline, which allows a startup PIN by default.
TPM is not available: The TPM is off in the BIOS or missing. Check with Get-Tpm or tpm.msc.
The recovery environment is disabled: Run reagentc /info, then reagentc /enable.
The device boots in legacy BIOS mode: Silent encryption needs UEFI.
The encryption method of the OS volume doesn't match the BitLocker policy: Someone encrypted it differently before the policy arrived. The drive has to be decrypted and encrypted again.
Recovery key backup failed: The device could not reach Entra ID, or it already has 200 keys stored, which is the limit.
A BitLocker baseline that works
Build one Intune BitLocker policy with silent encryption, TPM-only startup, XTS-AES on operating system and fixed drives, and recovery keys required in Entra ID before encryption starts. Assign it to devices, deliver it during Autopilot, and check the encryption report for anything stuck on Not ready.
What can we learn as a person
BitLocker has a rule I wish I followed. With the right setting, encryption will not turn on until the recovery key is stored somewhere safe. Lock the drive, sure, but only after someone else can get you back in.
I am great at the encryption part. Bad weeks and the stuff I do not say out loud stay locked down tight. I am terrible at escrow. When I lock myself out, there is no recovery key in anyone's account, and I sit at the blue screen alone.
Who holds your recovery key? And if the answer is nobody, who could you give it to?
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
