Hacking Intune Management Extension

Findings on how to make Microsoft Intune run PowerShell script in a recurring fashion.

So, a few days ago, I did a presentation for the “Everything Windows User Group” at the Microsoft HQ in Denmark.

This was my first time presenting a technical subject to a user group, so I had a bit of nerves, because I know there are a ton of IT Ninjas in this user group. But they really made me feel comfortable, and we had some great discussions about the subject of my presentation (Thanks to all who attended for making me feel welcome – and not least Per, Jesper and Peter for encouraging me).

The talk

So I decided to present on the subject of the various ways one can “hack” Intune Management Extension, to make it re-run PowerShell script policies.

I had previously been digging around in this subject, in order to come up with the “SideCarBehaviourScript” solution, and thought I would do some further investigation, and share my findings, so others might avoid some of the rabbit holes out there.

The challenge

Admins that are moving to Intune and starting with PowerShell script policies for the first time, will at some point learn, that script execution is a one time thing.

Intune Management Extension, which is the service agent on the users device, will only execute a script policy once!

If the script fails, it will be executed again at the next evaluation cycle, which is about every hour or so.

Now, what I just said has caused some confusion for some people, as I have seen talks about a Re-Run Method I call the “Error Method”, in which a script error is forced in the last line of the script, thereby tricking Intune Management Extension to run the script again every hour.

This does not work!

The reason being that Intune Management Extension will keep track of the errors, and after three failed attempts, it will simply give up, until you change something in the policy or the script.

So without further ado, here is the list of methods that actually, along with the pros and cons.

Re-Run methods for PowerShell deployed via Intune

These are the methods that I have currently uncovered, or come up with.
I will make sure to keep this list updated as I learn of more interesting ways to manipulate the re-run behaviour of Intune Managament Extension.

Please contact me on Twitter, if you see one, even if it sucks – the community needs to know. 😀

Error method

The method that forces a script to always ends in an error, making Intune Management Extension think it has to rerun it again (As explained earlier in this post).

Pros: None really?

Cons: This will give up after three hours, and the script is never run again, unless the policy is modified or deleted from registry. And it will show a failed run in the Intune portal…

Forget me method (Obi Wan Technique)

This solution involves adding a custom piece of code to the script you deploy, which ends the execution by spawning a new powershell process, that will delete the policy from the registry after a short delay.

I wrote two Proof-of-concept scripts that I put on GitHub: github.com/mardahl/forgetMeMethod_Intune

Pros: Works consistently, and indicates a “successful” run in the Intune Portal, and also shows the last run time.

The script could be extended with commands that changes the interval of execution.

In my PoC, I show that execution as the user is also possible, using the currently logged in users access token to spawn the process from the system users context.

Jos Lieben did a nice version of this method inspired by a screenshot I put up on twitter, of my work in progress.

Cons: Requires Admin priv. if run as the user, otherwise it’s ok for running it as the system. The script MUST be set to run as 64bit in order to avoid having to add alot of code to change to 64bit because of registry changes.

Azure PS Function/Runbook method

A scheduled script that runs against the Intune Graph API and makes a change to the script policy, so that Intune Management Extension re-runs the script on the next policy refresh

This is currently only a theoretical solution I came up with, but I see no reason why it wouldn’t work

Pros: No need to change any existing scripts.

Runs separately from the client, so some flexibility in design / management is possible.

Could be useful for keeping the scripts in a consistent state, by fetching a master script from a repository and overwriting the one stored in Intune.

Example: Run the function on a daily basis, making Intune Management Extension re-apply the script at least daily, in case some settings might have been overwritten by the user or something else.

Cons: Harder to time when the scripts actually run, login scripts would not be an ideal candidate for this solution.

Scheduled task (Graph API) method

A script that authenticates against GraphAPI and gets the names of all the scripts, and by using keywords in the policy names, finds the ones that need to be deleted.

Cons: The script needs to be run as an account with admin priv. to registry and have internet access. So only possible as a scheduled task with stored credentials 🙁

Pros: Easy to deploy, requires that script be names with keywords like #rerun# or #atstartup#

Scheduled task (SCBS) method

This solution consist of a scheduled task along with some PS scripts are deployed to the devices using MSI or Win32App deployment etc.

I created a Proof-of-concept solution for this and put it on GitHub a short while ago:
https://github.com/mardahl/SCBS

This task then looks through the registry on a set schedule, and clears out the desired policies, so that Intune Managament Extension will run the script again, either by restarting “Windows Intune Management Extenstion” service, or waiting for it to re-fresh automatically.

Pros: Easy to deploy, works for multi-user devices.

Cons: Scripts that need to run at certain intervals, needs a harmless modification. Needs a way to detect if script execution has failed, as the current implementation looks through the “resultDetails” registry value, which doesn’t contain the right data if the script has failed.

Detection Rules Method

This method relies on the “new” win32app deployment, that has an option to use a custom script to detect if a required app needs to be installed.

This works by by setting the detection rule to a script that looks for changes made to the computer, and re-running the installation, if a change is found.

An example could be that you are packaging a script that applies several security enhancing changes to the registry. If any of these changes are modified, you wan’t the package reinstalled. So you would create a detection rules script that looks for these changes.

This is not really a re-run method like the others, but still useful.

Pros: Intune native way of re-running scripts. And it’s able to run many changes through one .intune package.

Cons: Maintenance is higher than the other methods, having to repackage every time you make a change., and updating the detection rules script accordingly.

I was made aware of this hack by @schenardie on Twitter, so thanks go out to him.

Final Words

Hope you found this list of solutions useful and decide to contribute to some of them via GitHub.

If you come up with other solutions, please share them with me, so I can put them on the list.

You should ALWAYS do your own tests of these solutions, as they come with no guarantees!

Follow me on Twitter @michael_mardahl to learn more about me and the knowledge I share around Enterprise Mobility using Microsoft Windows Intune.