Without an app protection policy assigned, app configuration check-in drops from 30 minutes to 720.
Both figures are published, and the difference between them accounts for the overwhelming majority of cases where somebody swears a configuration change never arrived. Half a day between check-ins will do that. It is also completely avoidable once you understand how these two policy types relate to one another.
- 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 hire.
Somewhere in your organization there is a document explaining how to set an application up on a phone, and somebody emails it to every new starter. This is how that document stops being needed.
- The published purpose is exactly that: eliminating setup problems by assigning configuration to users before they run the application, supplied automatically so nobody has to take any action themselves.
- Those settings are consumed when the application goes looking, which is usually its first launch. Which is why the policy has to exist before the application is deployed, rather than being created two weeks later when the first person reports a problem.
- What is configurable at all comes down to the application developer, and their documentation is what you read. Of everything on this page that is the most useful single piece of advice, because assuming a setting exists is precisely how these projects stall in week two.
- And when the logs show a setting applying while the behavior stubbornly refuses to change, the suggestion is that the implementation on the developer side may be at fault. Contacting them first can save you an entire support cycle chasing something that was never yours to fix.
Eight things that decide whether settings reach the application.
Settings supplied before the user touches anything
The configuration reaches a user before they ever open the application, and gets supplied automatically as it sets itself up on their device. Nothing is asked of them. The documented examples include a custom port number, language preferences, security settings and branding, which between them cover most of what a setup document usually asks people to type in.
When the application actually reads it
Settings get consumed at the moment the application goes looking for them, which is typically its very first launch. Hold that thought, because it governs what happens to any change you make after deployment. The application has no obligation to look again until something gives it a reason to, which is why an update can appear to vanish.
The check-in interval that catches everyone
Deploy alongside an app protection policy and managed applications check in every 30 minutes for configuration status. Leave that protection policy unassigned to the user and the interval stretches to 720 minutes. Convert that: twelve hours, so a change made at nine in the morning may not reach somebody until the following day.
Two channels with different prerequisites
One route travels through the operating system management channel and requires the application to be pinned to the management profile on iOS, or delivered via Managed Google Play or as a line of business app on Android. The other travels through the application management channel and depends on the application having the Intune App SDK built in or having been wrapped.
Enrollment state is irrelevant on the managed apps channel
On the application management channel, neither the enrollment state of the device nor the route by which the application arrived has any bearing on things. Which is precisely why this becomes your mechanism for configuring software on personal hardware that was never enrolled and never will be.
Android Enterprise enrollment type decides certificate support
Choose the option covering all profile types and you lose the ability to associate a certificate profile entirely, leaving username and password authentication as your only route. The guidance advises against it wherever certificate-based authentication is in play. Both the fully managed and the personally-owned work profile options do support certificates, so the choice has consequences well beyond convenience.
Three ways to prove it worked
Watch the behavior on an actual device, read the diagnostic logs, or check the admin center through install status for the application and the configuration pane on the device itself. Each answers a subtly different question, and during a real troubleshooting session you will usually want all three rather than whichever one you happen to remember.
The vendor decides what is configurable
Which parameters exist and how they behave are determined entirely by whoever wrote the application, which means the vendor documentation is your reference, not anything published about Intune. And where the logs confirm a setting is applying yet the behavior does not change, the recommendation is to go to the application developer before opening a support case anywhere else.
Twelve hours between check-ins, unless an app protection policy is also assigned.
Both numbers are published, and the distance between them accounts for nearly every case where a configuration change appears to have been quietly ignored.
- With an app protection policy deployed alongside, managed applications check in on a 30 minute interval for configuration status. Without one assigned to that user, the interval becomes 720 minutes instead. Nothing warns you which of the two you are living with.
- Twelve hours. So a change made before lunch may not reach somebody until the next working day. Test it inside an afternoon and you will reach a confident, entirely wrong conclusion that the policy does not function, and the instinctive response is to start editing the policy rather than simply waiting.
- Which means these two policy types belong together at design time rather than being run as separate projects by separate people. Anywhere app protection is going to be deployed regardless, assigning it first makes configuration behave dramatically more responsively for free.
- Then there is a second timing factor sitting underneath the first, which is the application itself. Settings are consumed when it goes looking, typically at first launch, so even a successful check-in may not produce visible change until the application next has reason to read them.
Four things that make app configuration work first time.
We align app configuration with app protection
With a protection policy also assigned, applications check in every 30 minutes for configuration status. Without one it is 720. Designing the two as a single piece of work rather than as separate projects owned by separate people converts a twelve hour feedback loop into a thirty minute one, which changes how the entire deployment feels.
We start from the vendor documentation
Developers decide both which parameters exist and how they behave. The delivery mechanism, meanwhile, will faithfully transmit whatever key and value you type in. So a key the vendor never implemented gets delivered entirely successfully and then accomplishes nothing whatsoever, and every signal available to you reads that as a policy failure rather than a nonexistent setting.
We choose the Android enrollment type deliberately
The all profile types option cannot carry a certificate profile and leaves you with username and password authentication only, which the guidance explicitly advises against wherever certificates are in use. It is also the option people select without thinking because it sounds the most accommodating, and doing so quietly forecloses certificate scenarios you may need in eighteen months.
We prove delivery through the logs, not the portal alone
What the admin center tells you is whether a policy was targeted and delivered. What the diagnostic logs tell you is the precise key and value that reached the application. Only the second answer separates a delivery problem from an implementation problem on the vendor side, and those two situations call for completely different responses from completely different people.
Four phases across roughly four weeks.
- 01Week 1
Establish what each application supports
Because developers decide what is configurable, this first week is spent reading vendor documentation rather than anything Intune-related. On the Android side there is a shortcut: Managed Google Play marks the applications that support configuration, which hands you a starting inventory without any research at all.
- 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 enrollment type
Enrolled hardware where the application satisfies the pinning or Managed Google Play prerequisites goes one way; everything else goes the other. On Android Enterprise there is an additional decision with lasting consequences, since the enrollment type you pick determines whether certificate profiles can be associated at all.
- Channel chosen per application and audience
- Android Enterprise enrollment type selected deliberately
- Certificate authentication requirements confirmed
- App protection policy alignment decided
- 03Week 3
Build, assign and test with the right patience
The policies get built and assigned using include and exclude groups, with filters brought in wherever the scope needs tightening. Then comes the testing, conducted with explicit allowance for whichever check-in interval applies to that population, because testing against the wrong one produces a wrong answer confidently.
- Policies built and assigned per application
- Filters applied where scope needs refining
- Testing conducted against the correct check-in interval
- Behavior verified on real devices
- 04Week 4
Validate properly and hand over troubleshooting
Everything is verified along all three routes, meaning observed behavior, the diagnostic logs and the admin center views. After that we walk your team through the troubleshooting path, including the specific and genuinely confusing case where a parameter is confirmed as arriving and the application simply declines to 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 hires onto mobile applications
Server addresses, port numbers, account details and branding all arrive automatically before anybody opens the application, and the new starter is asked to do nothing at all. Reducing service desk calls from people attempting to configure settings themselves is named directly as one of the intended outcomes, which matches what we see in practice.
An organization restricting apps to work accounts only
Restricting sign-in to work or school accounts is a documented scenario on the enrolled device channel. It ends the very common situation where a corporate application quietly ends up signed into somebody personal account, and it does so without depending on a policy document that nobody has opened since induction.
A company supporting personally owned devices
On the application management channel, neither the enrollment state of the hardware nor how the software got installed makes any difference to delivery. Where people are using their own phones that is your only available route, and on Android it carries a floor of version 10.0 which is worth confirming before you promise anything.
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, which is exactly the distinction a SOC 2 auditor or an examiner will probe.
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 organizations 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 organization | 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 hires | Yes | Partly | No |
Dependent on vendor support | Yes | No | No |
Managed devices against managed apps.
Consideration
Delivery channel
- Managed devices
- Operating system management channel
- Managed apps
- Application management channel
Consideration
Device enrollment required
- Managed devices
- Yes
- Managed apps
- No, enrollment state does not matter
Consideration
iOS prerequisite
- Managed devices
- App pinned to the management profile
- Managed apps
- Intune App SDK or wrapping tool
Consideration
Android prerequisite
- Managed devices
- Managed Google Play or a direct line of business app
- Managed apps
- Intune App SDK or wrapping tool
Consideration
Android version requirement
- Managed devices
- Per app and enrollment model
- Managed apps
- Android 10.0 or higher
Consideration
Only allow work or school accounts
- Managed devices
- Supported scenario
- Managed apps
- Not listed
Consideration
Account setup configuration
- Managed devices
- Supported scenario
- Managed apps
- Not listed
Consideration
General app configuration
- Managed devices
- Supported scenario
- Managed apps
- Supported scenario
Consideration
S/MIME configuration
- Managed devices
- Supported scenario
- Managed apps
- Supported scenario
Consideration
Advanced data protection settings
- Managed devices
- Not listed
- Managed apps
- Supported scenario
Five steps, and the first is reading somebody else's 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 enrollment 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 enrollment is not in play and the app carries the Intune App SDK or wrapping.
- 3
Select the Android Enterprise enrollment 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 organizations 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 enrollment
- Are the devices enrolled?It decides the channel.
- Which Android Enterprise enrollment 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.
The pages around this one.
List the setup steps a new hire 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