Managed software updates on Apple devices with Intune

We've been able to configure software update policies on iOS and macOS devices for a while, right. However this is new and different, released in March 2025 (Service release 2503). "Managed software updates" means something very specific. We can now configure devices to automatically update to the latest OS version using Apple Declarative device management.

Declarative device management (DDM) is an update to the existing protocol for device management that can be used in combination with the existing MDM protocol capabilities. It allows the device to asynchronously apply settings and report status back to the MDM solution without constant polling. This is ideal for performance and scalability.

To configure Managed software updates, navigate to Devices > Manage devices > Configuration > Create > New policy > choose iOS/iPadOS or macOS for platform > select Settings catalog for profile type.

Add the setting Declarative device management > Software Update Enforce Latest. 

You'll also see the "Software Update" and "Software Updates Settings" setting, more on them shortly.

We have three items to configure

• Enforce Latest Software Update Version: If true, devices will upgrade to the latest OS version that is available for that device model. This uses the Software Update Enforcement configuration and will force devices to restart and install the update after the deadline passes.
• Delay In Days: Specifies the number of days that should pass before a deadline is enforced. This delay is based on either the posting date of the new update when released by Apple, or when the policy is configured.
• Install Time (optional): Specifies the local device time for when updates are enforced. This setting uses the 24-hour clock format where midnight is 00:00 and 11:59pm is 23:59. Ensure that you include the leading 0 on single digit hours. For example, 01:00, 02:00, 03:00.

The configuration in the screenshot will force an update of the device 1 day after Apple release an update, at no particular time. The device will always remain at the latest OS version. This is called an "automatic managed software updates policy".

If you select the Software Update setting in the settings picker, your options are different.

• Details URL (optional): Enter a web page URL that has more information on the update. Typically, this URL is a web page hosted by your organization that users can select if they need organization-specific help with the update.
• Target Build Version (optional): Enter the target build version to update the device to, like 20A242. The build version can include a supplemental version identifier, like 20A242a. If the build version you enter isn't consistent with the Target OS Version value you enter, then the Target OS Version value takes precedence.
• Target Date Time: Select or manually enter the date and the time that specifies when to force the installation of the software update.
• Target OS Version: Select or manually enter the target OS version to update the device to. This value is the OS version number, like 16.1. You can also include a supplemental version identifier, like 16.1.1.

This is called a "manual managed software updates policy" as you need to create a new one for every OS version you need to update to. You would use this policy if you are unsure about updating to the latest and greatest as soon as possible.

Remember Software Updates Setting in the Setting picker, what is that one about?.

This give us a single place to configure managed software updates. You may want to manage aspects of the software update process leading up to the enforcement of an update. Using this configuration, you can:

• Require that an admin or standard user can perform updates on the device
• Control how users can manually interact with software update settings like automatic download and install or the behavior of Rapid Security Responses
• Hide updates from users for a specified time period
• Suppress update notifications up to one hour before the enforcement deadline
• Control whether users are allowed to update to the latest major update, latest minor update, or are offered both.

Precedence

Now that we have several places to configure updates for iOS and macOS devices, what happens when there is a conflict? Managed software updates (both automatic and manual) have precedence over other policies that configure software updates. If you configure managed software updates and also have other software update policies assigned, then it's possible the other update policies have no effect.

iOS/iPadOS precedence order:

1. Managed software updates (Settings catalog > Declarative Device Management > Software Update)
2. Update policies (Devices > Update policies for iOS/iPadOS)

macOS precedence order:

1. Managed software updates (Settings catalog > Declarative Device Management > Software Update)
2. Update policies (Devices > Update policies for macOS)
3. Software updates (Settings catalog > System Updates > Software Update)

We have seen that you can create software update policies or managed software update policies for Apple devices in Intune. Both policy types can manage the install of software updates on devices. However, there are some differences between the two policy types. Microsoft have provided a table to help you decide which policy type to use.

I hope this helps you to understand the new "managed" policy type and how it differs from what we already had. Until next time.....

My experience with iOS user enrollment using Intune

Those of us who manage iOS devices have some new terminology to learn with iOS 13. Automated Device enrollment is new 😀 and what is iOS user enrollment all about?

Automated Device enrollment is the new name for the corporate Device enrollment program (DEP). iOS user enrollment (supported in iOS 13.1) was announced by Apple in June and is designed specifically for the BYOD scenario to address the privacy concerns of users and businesses. The enrolling user can choose between user and device enrollment when they are enrolling the device. iOS user enrollment has been compared to Android Enterprise with Work Profile where the work area of the device is completely separate from the personal area (strange to see Google before Apple with an enterprise solution). In this case the device is not fully managed.

Personally I don't like the terms user and device enrollment. My customers are used to the process being referred to as user-driven enrollment so this could be confusing. I'd much prefer the terms personal and corporate enrollment.

So what do we need for the solution?

Devices

We need iOS 13.1 or later devices. I prepared an iPhone and an iPad for my testing (a little more on this later).

Apple ID

We have to configure the Apple MDM Push certificate in the Intune portal as normal to facilitate the enrollment of Apple devices. However there is an additional requirement for iOS user enrollment. Each user must have a Managed Apple ID. I wasn't familiar with this so I had to do some research. You create Managed Apple Ids using the Apple Business Manager. This is a free tool (a slick new model of the Device Enrollment Program) but you need to be registered to take advantage of it. I don't have access so I won't be abe to create the required IDs. However I still want to see the user experience so I'll take it as far as I can. 

See here for more information on Manged Apple IDs

https://support.apple.com/en-gb/guide/apple-business-manager/mdm1c9622977/web

• This ID will control access to the corporate area of the device. 
• It should not be the same as the Apple ID associated with the device itself. That ID controls the personal area of the phone.
• You must sign in to Intune to start the enrollment using the Managed Apple ID.
• You will need a Volume Purchase Program token to deploy corporate apps to these devices.

So let's see the solution in action. How do we configure it?

In the Intune portal, navigate to Device enrollment > Apple enrollment. See the new section for Enrollment targeting. Click on Enrollment types, which is a preview feature.

 Click to create a profile.

We are presented with a single choice - iOS. 

Aside: I don't quite understand this. I've read somewhere that this is because iOS 13 differentiates between iOS and iPadOS devices and iPads are not supported for user enrollment. This does make sense but it's not the case in my experience, although I could be wrong. I was able to initiate user enrolment on both my test devices.

Enter a profile name and description.

I want users to have to choose the enrollment type so I'll select Required.

When you choose Required the default enrollment type choices are no longer available. See the note about needing the Azure Authenticator app in order for conditional access to work on devices targeted with user enrollment.

Assign the profile to a group - I've chosen All Users for my test.

Review your choices before you Create and assign the profile.

User experience

Now let's have a look at the user experience when enrolling a device. As usual it starts with the Intune Company Portal. Download from the App Store and Install.

Another corporate account was found on my test device so I chose to Sign in with another account.

I clicked on + to add an account.

This is where you should enter your Managed Apple ID. I don't have one so I'll wing it and see how far I can get.

Enter your password.

We're shown the list of steps that will be followed to complete the enrollment.

Ok, now this is different. I'm going to choose "I own this device".

When I do I am offered the options to secure the entire device or work related content only, cool. 

I chose "Secure work-related apps and data only".

We can see some progress.

We can see the Device management and privacy details - what your organization can't see on the device.....

….and what they can see. I don't quite understand why these dialog screens are exactly the same as those we see for device enrollment. Surely they should be different?

We see further progress.

We have to Allow the company portal website to download a configuration profile.

The management profile has downloaded and we're told to go the Settings to continue. We're familiar with this two-step enrollment with later iOS devices.

We see that we now should "Enrol in "your directory"".

Click "Enrol my iPhone" to continue.

Aside: I was also able to get this far with my test iPad so I'm not sure that it's true to say iPads are not yet supported".

Back to the iPhone - entered the existing passcode to install  the management profile.

Now I have to enter my Managed Apple ID. The ID is prepopulated based on the credentials I previously entered and it can't be changed or removed.

The process will finish and the device will be enrolled as a personal device.

Some thoughts on iOS user enrollment

iOS user enrollment is a really good idea and kudos to Microsoft for quickly integrating it with Intune. However I'm not sure Apple have got this right. Not all organizations will be able to use it. The requirement for DEP/Apple Business Manager and VPP programs can be a little too much for some organizations (not to mention testing in labs for IT Pros like me). Also the programs are not avilable in all countries.

It's certainly not as straightforward as testing Android Enterprise with Work Profile. Ironically it's easier to manage the entire device using device enrollment.

I hope you find this useful. Until next time...….

Intune - Block app access based on unapproved device vendors and models

This is one the most recent new features to be published by the Intune team. We can now specify a list of Android manufacturers and iOS models and choose an action to be performed on the devices specified in the list. At the moment we have a choice of two actions:

1. Block devices that are not specified from accessing an app
2. Perform a selective wipe of corporate data on devices that are not specified

This sounded really cool to me so I tested to see if this was easy to configure. It is. It's as easy as typing a list of Android manufacturers and iOS models separated by a semicolon.

In Microsoft Intune, select Mobile apps > App protection policies and select Add a policy.

Enter a name and choose a platform (Android in this case). Select your required apps and configure your required settings as normal.

Now, in the Settings page, scroll to the bottom to the Access Actions settings.

You'll find an existing list of settings, values and actions.

Click on the drop down arrow to reveal some additional choices. Select Device manufacturer(s).

A new line is added. We now must configure the values and action.

Enter your required values. As soon as you type a semicolon you are prompted for another value. The Microsoft documentation has a warning about this. 

"On end-user devices, the Intune client will take action based on a simple matching of the strings specified in the Intune blade for Application Protection Policies. This depends entirely on the value that the device reports. As such, the IT administrator is encouraged to ensure that the intended behavior is accurate. This can be accomplished by testing this setting based on a variety of device manufacturers and models targeted to a small user group".

In other words Intune will not check that what you've typed is accurate. It will only recognize it as a series of strings.

Next, choose your required action. I want to block access to my app for all Android devices except Samsung and HTC devices. Click OK to create the policy as normal.

It's very similar for iOS devices except that you choose Device models.

There are a couple of additional considerations:

1. On iOS devices, this feature requires the participation of applications (such as WXP, Outlook, Managed Browser, Yammer) to integrate the Intune APP SDK for this feature to be enforced with the targeted applications.
2. On Android, this feature requires the latest Company Portal.

I think this is a very useful feature and I hope it helps you. Until next time......

Improvements in app blacklisting with Intune

The August update of the Intune service has introduced major improvements in mobile app management. Previously you could create app blacklists but these policies would only block apps on Windows devices. They would not prevent the installation or use of apps on Android or iOS devices. For these devices you could only report non-compliance if a blacklisted app was installed.

So what are these improvements?

Android
We can now create custom policies to allow and block apps for Samsung KNOX enabled Android devices.

• Once an app is blocked, it cannot be activated or run on the device, even if it is already installed.
• Specifying which apps are allowed designates which apps can be installed from the Google Play store. When a list of allowed apps is defined, no other apps can be installed from the store.

iOS
On iOS 9.3 and later (supervised devices only) we can add a list of hidden and shown apps to the iOS general configuration policy.

• Apps that are specified as hidden can’t be viewed or launched by users.
• When you specify a list of apps to be shown, no other apps can be viewed or launched.

Let's have a look at the custom Android policy and then we'll see the behaviour on a device.

In the Microsoft Intune administration console, choose Policy > Configuration Policies > Add.

In the Create a New Policy dialog box, expand Android, choose Custom Configuration, and then choose Create Policy.

Provide a name and optional description for the policy and then, in the OMA-URI Settings section, choose Add.

We want to specify the allowed apps so that all other apps will be blocked.

Note: You can find the package ID of an app by browsing to the app on the Google Play store. The package ID is contained in the URL of the app's page.

For example, the package ID of the Microsoft Word app is com.microsoft.office.word as the URL is
https://play.google.com/store/apps/details?id=com.microsoft.office.word

The package ID of the Adobe Reader app is com.adobe.reader as the URL is
https://play.google.com/store/apps/details?id=com.adobe.reader

In the Add or Edit OMA-URI Setting dialog box, specify the following:

• Setting name - Enter AllowInstallPackages.
• Setting description - List of apps that users can install from Google Play.
• Data type - String.
• OMA-URI - ./Vendor/MSFT/PolicyManager/My/ApplicationManagement/AllowInstallPackages
• Value - List of the Package IDs you want to allow. Use ; : , as delimiter. (Example: packageID1,packageID2). In my case this is com.adobe.reader,com.microsoft.office.word

Click OK.

Save Policy.

In the Policy workspace, select the policy and click Manage Deployment.
In the Manage Deployment dialog box, select one or more groups to which you want to deploy the policy, then click Add > OK.

User experience

So what happens on the device. I'm using an Android device with Samsung Knox enabled (Samsung Galaxy S4 phone).
I've tried to install an app that isn't on the allowed list.

I can't install the app and get the notification that "Security policy prevents installation of this application".

Then I tried to install Adobe Reader which is on the allowed list.

No problem.

This is very straightforward to configure and works instantly.

It's worth mentioning the supported devices again.

• Samsung Knox enabled Android devices (must be Samsung Knox - I was unable to get this working on an Android without Samsung Knox) 
• Supervised iOS devices 9.3 and later (supervised mode can be enabled on iOS devices using the Apple Device Enrolment Program or the Apple Configurator Tool) 

I hope this was useful. Until next time.......

Microsoft Intune - renew Apple APN certificate

EMS Landing page

Anyone who has worked with Intune will know that an Apple APN certificate is required in order to manage iOS devices. This is an Apple requirement. So what is this APN? The Apple Push Notification Service (APN) is a service created by Apple. It forwards notifications from 3rd party applications to Apple devices - and it requires an Apple certificate (which is free, of course).

It's pretty straightforward to generate and apply this certificate. I've previously blogged about that here. That example describes the process in a hybrid environment of ConfigMgr and Intune. The big drawback of this process is that you can only generate a certificate which lasts for one year. Then it must be renewed. It is vital that the certificate is renewed before it expires. Otherwise you will have to re-enrol ALL your iOS devices. You do the Maths on that one.

It's vital that you set up an alert to warn you that the certificate is about to expire.

This is an example of the alert in standalone Intune. It's the same idea in hybrid.

Here we can see the details of the alert. Click on "iOS Mobile Device Management" to take you to the section where you can fix this.

We can see exactly when the certificate will expire. Click on "Enable the iOS Platform".

Select "Download the APNs Certificate Request" to generate a CSR.

Save the CSR locally.

Now select "Apple Push Certificates portal" and log in with your Apple ID. See the existing certificate and the expiry date. Click to Renew the certificate (it's better not to use IE for this process - other browsers are more reliable here).

Browse to your CSR and select Upload

If you are using IE you will see this almost immediately.. This is the wrong file format and you do not need it. Cancel and refresh the browser.

You will see your new certificate. Select "Download".

See the correct file extension (.pem).

Save the certificate.

Now back to the Intune portal. Select "Upload the APN certificate"

Browse to the certificate and enter your Apple ID.

All is now OK in the console.

The process for renewing the Apple APN certificate in a hybrid environment is almost identical.

Remember - "DO NOT LET THE APN CERTIFICATE EXPIRE"

Until next time.