Without an app protection policy assigned, app configuration check-in drops from 30 minutes to 720.
Microsoft publishes both intervals. Twelve hours between check-ins explains most cases where a configuration change appears not to have reached the app, and it is entirely avoidable by understanding how the two policy types work together.
- 30 minutesCheck-in with an app protection policy assigned
- 720 minutesCheck-in without one
- 2 channelsManaged devices and managed apps
- First runWhen an app typically reads its configuration
The setup instructions you email to every new starter.
Most organisations have a document telling people how to configure an application on their phone. App configuration policies are how that document stops being necessary.
- The published description is exactly this: app configuration policies help eliminate app setup problems by letting you assign configuration settings to a policy assigned to end users before they run the app, supplied automatically so end users do not need to take action.
- The settings are used when the app checks for them, typically the first time the app is run. That timing is why the policy needs to be in place before the application is deployed rather than added afterwards when somebody reports a problem.
- What can be configured is decided by the application developer, and the vendor documentation should be reviewed. That is the single most useful piece of guidance here, because assuming a setting exists is how a configuration project stalls.
- When a setting appears in the logs as applying but does not seem to work, Microsoft suggests the issue may be with the configuration implementation by the app developer, and that contacting them first may save a support call.
Eight things that decide whether settings reach the application.
Settings supplied before the user touches anything
Configuration is assigned to users before they run the application, and supplied automatically when the app is configured on their device with no action required from them. A custom port, language settings, security settings and branding are all documented examples.
When the application actually reads it
The configuration settings are used when the app checks for them, typically the first time the app is run. That timing matters for a change made after deployment, because the application may not look again until it has a reason to.
The check-in interval that catches everyone
Intune managed apps check in every 30 minutes for app configuration policy status when deployed alongside an app protection policy. Without an app protection policy assigned to the user, that interval becomes 720 minutes, which is twelve hours between checks.
Two channels with different prerequisites
Managed devices delivers through the operating system channel and needs the app pinned to the management profile on iOS, or deployed through Managed Google Play or as a line of business app on Android. Managed apps delivers through the application management channel and needs the Intune App SDK or wrapping.
Enrolment state is irrelevant on the managed apps channel
For managed apps, Microsoft states that neither the device enrolment state nor how the app is delivered to the device matter. That is what makes this the mechanism for configuring applications on personally owned devices that are not enrolled at all.
Android Enterprise enrolment type decides certificate support
All Profile Types cannot be associated with a certificate profile and supports username and password authentication only, so Microsoft advises against it where certificate-based authentication is used. The fully managed and personally-owned work profile options both support certificates.
Three ways to prove it worked
Observing the behaviour on the device, reading diagnostic logs, and checking the admin centre through device install status for the app and the app configuration pane on the device. All three answer slightly different questions during a troubleshooting session.
The vendor decides what is configurable
Available configuration parameters and their implementation are decided by the application developers, so vendor documentation is the reference rather than Intune. Where a setting is confirmed as applying but does not work, Microsoft suggests contacting the app developer first.
Twelve hours between check-ins, unless an app protection policy is also assigned.
Microsoft publishes both figures, and the gap between them explains most cases where an app configuration change appears to have been ignored.
- Intune managed apps check in with an interval of 30 minutes for app configuration policy status when deployed in conjunction with an Intune app protection policy. If no app protection policy is assigned to the user, the app configuration check-in interval is set to 720 minutes instead.
- That is twelve hours, so a configuration change made in the morning may not reach a user until the following day. During a test that produces a confident and wrong conclusion that the policy does not work, and the usual response is to change the policy rather than wait.
- The practical implication is that app configuration and app protection policies belong together in design rather than being treated as separate projects. Where app protection is being deployed anyway, assigning it first makes app configuration behave far more responsively.
- The second timing factor is the application itself. Configuration settings are used when the app checks for them, typically the first time the app is run, so even after a check-in the setting may not take visible effect until the application next looks for it.
Four things that make app configuration work first time.
We align app configuration with app protection
Managed apps check in every 30 minutes for app configuration status when an app protection policy is also assigned, and every 720 minutes when one is not. Designing the two together rather than separately turns a twelve hour feedback loop into a half hour one.
We start from the vendor documentation
Available configuration parameters and their implementation are decided by the application developers. Intune delivers whatever key and value you specify, so a key the vendor never implemented is delivered successfully and does nothing, which reads as a policy failure.
We choose the Android enrolment type deliberately
All Profile Types cannot be associated with a certificate profile and supports username and password authentication only, which Microsoft explicitly advises against where certificate-based authentication is used. Choosing it by default closes off certificate scenarios later.
We prove delivery through the logs, not the portal alone
The admin centre shows whether a policy was targeted and delivered. The diagnostic logs show the actual key and value the application received, which is what distinguishes a delivery problem from an application implementation problem, and those need very different responses.
Four phases across roughly four weeks.
- 01Week 1
Establish what each application supports
Configuration parameters are decided by application developers, so this is vendor documentation work rather than Intune work. In Managed Google Play, applications supporting configuration are marked as such, which gives a starting inventory for the Android side.
- Applications in scope listed with vendor documentation
- Supported configuration keys identified per app
- Applications with no configuration support separated
- Setup steps users currently perform manually captured
- 02Week 2
Choose the channel and enrolment type
Managed devices where devices are enrolled and the application meets the pinning or Managed Google Play prerequisites, managed apps where they are not. For Android Enterprise, the enrolment type decides whether certificate profiles can be associated at all.
- Channel chosen per application and audience
- Android Enterprise enrolment type selected deliberately
- Certificate authentication requirements confirmed
- App protection policy alignment decided
- 03Week 3
Build, assign and test with the right patience
Policies built and assigned with include and exclude groups, and filters used where the scope needs narrowing. Then tested allowing for the check-in interval, which is 30 minutes with an app protection policy assigned and 720 minutes without.
- Policies built and assigned per application
- Filters applied where scope needs refining
- Testing conducted against the correct check-in interval
- Behaviour verified on real devices
- 04Week 4
Validate properly and hand over troubleshooting
Verification through all three routes: observable behaviour, diagnostic logs, and the admin centre views. Then the troubleshooting path, including the case where a parameter is confirmed as applying but the application does not act on it.
- Diagnostic log validation demonstrated per platform
- Device install status and app configuration views shown
- Vendor escalation path documented for implementation issues
- Support guidance handed to the service desk
Six configuration problems this removes entirely.
A business onboarding new starters onto mobile applications
Server addresses, port numbers, account setup and branding all supplied automatically before the user opens the app, with no action required from them. Microsoft names exactly this as reducing helpdesk calls from users trying to configure settings on their own.
An organisation restricting apps to work accounts only
Only allow work or school accounts is a documented scenario on the managed devices channel. It stops the common situation where a corporate application ends up signed into a personal account, without relying on a policy document nobody reads.
A company supporting personally owned devices
The managed apps channel delivers configuration where neither the device enrolment state nor how the app was installed matters. For bring your own device populations that is the only route, and it needs Android 10.0 or higher on the Android side.
A regulated firm deploying S/MIME
S/MIME configuration settings are a documented scenario on both the managed devices and managed apps channels. Configuring it centrally rather than instructing users is the difference between a control that applies consistently and one that applies to whoever followed the guide.
An operator with dedicated Android devices
Worth knowing one documented failure case: deploying a Gmail or Nine configuration profile to an Android Enterprise dedicated device work profile that does not involve a user fails, because Intune cannot resolve the user. Userless dedicated devices need configuration that does not depend on one.
A team that inherited old Android configuration policies
Policies created before the April 2020 release default to All Profile Types where no certificate profile was associated, and to work profile only where one was. Microsoft also notes those existing policies will not remediate or issue new certificates, which is worth checking.
How UAE organisations get applications configured.
| Feature | App configuration policies | Documented instructions | Users work it out |
|---|---|---|---|
Settings correct on first run | Yes | Usually | Variable |
User action required | None | Follow a guide | Yes |
Consistent across the organisation | Yes | Mostly | No |
Works on unenrolled devices | Via managed apps channel | Yes | Yes |
Setup support calls | Reduced | Some | Routine |
Security settings enforced | Yes | Requested | No |
Change deployable centrally | Yes | Reissue the guide | No |
Verifiable centrally | Yes | No | No |
Scales with new starters | Yes | Partly | No |
Dependent on vendor support | Yes | No | No |
Managed devices against managed apps.
| Consideration | Managed devices | Managed apps | |
|---|---|---|---|
| Delivery channel | Operating system management channel | Application management channel | |
| Device enrolment required | Yes | No, enrolment state does not matter | |
| iOS prerequisite | App pinned to the management profile | Intune App SDK or wrapping tool | |
| Android prerequisite | Managed Google Play or a direct line of business app | Intune App SDK or wrapping tool | |
| Android version requirement | Per app and enrolment model | Android 10.0 or higher | |
| Only allow work or school accounts | Supported scenario | Not listed | |
| Account setup configuration | Supported scenario | Not listed | |
| General app configuration | Supported scenario | Supported scenario | |
| S/MIME configuration | Supported scenario | Supported scenario | |
| Advanced data protection settings | Not listed | Supported scenario |
Five steps, and the first is reading somebody else documentation.
- 1
Establish what each application supports
Configuration parameters and their implementation are decided by application developers, so vendor documentation is the reference. In Managed Google Play, applications that support configuration are marked, and note that only Managed Google Play apps appear when using managed devices as the enrolment type for Android.
- 2
Choose the channel per application and audience
Managed devices where devices are enrolled and the application is pinned to the management profile on iOS or deployed through Managed Google Play or as a line of business app on Android. Managed apps where enrolment is not in play and the app carries the Intune App SDK or wrapping.
- 3
Select the Android Enterprise enrolment type deliberately
All Profile Types supports username and password authentication and cannot be associated with a certificate profile. The fully managed, dedicated and corporate-owned work profile option and the personally-owned work profile option both support certificate-based authentication as well.
- 4
Assign, then test at the correct pace
Include and exclude assignments with filters where scope needs refining, then testing that allows for the real check-in interval: 30 minutes where an app protection policy is assigned to the user, and 720 minutes where one is not.
- 5
Validate through logs and set the escalation path
Diagnostic logs show the actual key and value the application received. Where a parameter is confirmed as applying but the application does not act on it, Microsoft advises contacting the application developer first, since it may be an implementation issue in their code.
What organisations ask about app configuration policies.
Fifteen questions worth answering first.
Application support
- Does the vendor document configuration keys?They decide what is available.
- Is the app marked as configurable in Managed Google Play?A useful indicator.
- Does the app use the Intune App SDK?Needed for the managed apps channel.
- Is the app pinned to the management profile on iOS?Needed for managed devices.
- Can users override the setting?Some apps respect user preference.
Channel and enrolment
- Are the devices enrolled?It decides the channel.
- Which Android Enterprise enrolment type?It decides certificate support.
- Do we use certificate-based authentication?Avoid All Profile Types then.
- Are devices on Android 10.0 or higher?Required for the managed apps channel.
- Any dedicated devices without a user?Some profiles fail there.
Delivery
- Is an app protection policy assigned?It changes check-in from 720 to 30 minutes.
- Are we testing patiently enough?Twelve hours without one.
- Have we used filters to refine scope?Supported for iOS and Android.
- Do we know how to read the diagnostic logs?Different per platform.
- Do we have any pre-2020 Android policies?They default to specific profile types.
List the setup steps a new starter performs manually in your mobile applications.
Server addresses, account settings, security options, anything they type in on day one. Each one the vendor supports as a configuration key is a support call you can remove permanently.
Related Services
Explore more solutions that work great with this service
App Protection Policies
Protect company data on a phone you will never be allowed to manage
Android Enterprise
Choose the enrolment method before you buy the phones
Intune Assignment Filters
Targeting by device property, without the delay
iPhone and iPad Management
Remove company data from a phone you do not own
Intune Configuration Profiles
Settings catalog, templates and conflict management
MDM Solutions Dubai
Device management across Windows, Apple and Android
Microsoft Intune
Device management and endpoint security
Device Enrolment
Which path, which reset, and what you can enforce after