Introduction

Long title! It could have been even longer, but I struggled to squeeze in that the e-mail also is sent over Office 365 and the entire deliciousness is running on a schedule with Azure Automation. 🙂

The story here is, that iOS is getting updates quite frequently, and a lot of enterprises (including myself), are managing those iOS devices as private BYOD devices enrolled through the Company Portal. As of such, keeping the devices up to date is the end-user’s responsibility and something that’s often forgotten and neglected.

So what if we could send those devices and users a kind reminder automatically, both as a custom notification directly on the device, but also as an e-mail? Microsoft Intune Powershell SDK to the rescue!

Powershell

While I’m making my move into GitHub, I’m gonna leave you with the script available for download on the TechNet Gallery as usual:

The script does following in headlines and needs some editing to suit your environment:

NOTE: I put a lot of effort into creating proper logging in the script, which should make 99.9% on the content self explanatory (I hope). If anything is unclear, hit me up on twitter or in the comments section down below. 🙂

Reads credentials for the account sending the e-mail (EDIT this with your details)

Reads a baseline userPrincipalName. This UPN’s devices are considered the baseline iOS version (EDIT this with your details)

Connects to Microsoft.Graph.Intune

Gets all iOS devices belonging to the baselineUPN

Extracts the highest iOS version from the devices found

Gets all iOS devices from Intune

Loops through each device and look for devices that are on lower iOS version than the baseline

Send e-mail and notification to those devices and it’s enrolled user

Important!

For testing purposes, I’m manually overriding the baseline version to 13.3.

I’m also overriding all the iOS devices found restricting the initial test to my own devices, so I don’t accidentally sends e-mails and notifications to all my users . Remove these parts in the script when moving to production.

Variables

Now, browsing that newly created (or existing) Automation Account, you need to add a few variables. I use unique accounts for respectively accessing Intune via Graph and sending the e-mail over Office 365. As of such, you need to add 4variables :

IntunePSAdmUPN

The account’s UserPrincipalName

IntunePSAdmPW

The account’s password added encrypted

hlpUPN

The account’s UserPrincipalName

hlpPW

The account’s password added encrypted

The same variables are referenced in the very beginning of the script. See below illustration:

NOTE: This is something that probably needs editing if you are using different names for the variables.

Modules

Still browsing the same Automation Account, you need to make sure that Microsoft.Graph.Intune is added as a module.

This is done from browsing the gallery and searching for the name. See below illustration:

Runbooks

Yet still on the Automation Account, you will need to create a new PowerShell Runbook. Below is an illustration of mine called RemindUsersToUpdateiOS.

Editing the runbook gives you the option to obviously paste in the entire script, but also to Save, Publish and TEST the content.

Schedule

You can have the script to run on a schedule. This is quite relevant considering the need to run this automatically. Add a schedule which suits your environment.

Enterprise Application

Next, you will need to make sure that the account accessing the Intune Powershell SDK has access to and is allowed to use the Enterprise Application: Microsoft Intune Powershell

Below is an example where the Enterprise Application is highlighted in the Azure Portal:

Still browsing the Enterprise Application, make sure to add the account to Users and groups like shown below:

NOTE: The account need consent to be using the Enterprise Application. This can be done with an Admin Consent for all users, and is done under the Permissions option.

Testing

Testing the script is important and the reason I spent a fair amount of time on adding relevant logging information. As you see per below illustration, you will be able to see exactly what is going on when the script is run.

NOTE: I have obfuscated content for obvious reasons, as this is being run in my production environment, but I hope you get the picture.

Additional Information

Sending the e-mail

The e-mail is sent over Office 365 via smtp.office365.com. This requires succesful authentication with Office 365 and Exchange Online, and will require a user which is licensed for Exchange Online.

Intune Account

The account used in the runbook to access the Intune Powershell SDK and Intune needs permissions to do so. In my testing, the account was an Microsoft Intune Administrator in the tenant.

Conditional Access

Chances are that the account is targeted by CA policies. You will probably need to make exceptions here, if you have MFA or similar as a requirement. You can lock down the account to only run from trusted IPs. That being the IPs for your Azure datacenter.

Result

The e-mail being sent looks similar to below. The content can obviously be modified in the script.

And the notification on the iOS device will popup and display in the Company Portal.

If anything needs explaining, don’t hesitate reach out to me. Drop a comment down below or catch me on Twitter.

Looks very interesting. I am not just a script guru, but can the warning about IOS updates be send out only to users that are not running the latest version ? as to send info to all users even they are updated I would like to avoid – but maybe the script is already working like this ?