PowerShell Scripting across Intune

An important and often overlooked part of Intune is its ability to run scripts on devices, whether as one-off deployments (Platform scripts) or more regularly via Remediations (previously called Proactive Remediations). With Windows 10 and Windows 11, PowerShell has become increasingly more powerful to the point where almost anything can be done on devices with a script.

In Intune, we can use PowerShell scripts to configure properties not yet available in the settings catalog, copy files, add registry keys, or even run a script to remove unwanted Windows bloatware for a cleaner build.

Platform scripts are run as configurations for simple configuration settings or anything required during device setup. Remediations, on the other hand, are repeatable scripts with logic that only runs when required.

Throughout this chapter, we will learn how to deploy PowerShell scripts and Remediations, but also how to write the scripts themselves and provide...

Technical requirements

For this chapter, you will need a modern web browser and a PowerShell code editor such as Visual Studio Code or PowerShell ISE.

All the scripts that are referenced in this chapter can be found here: https://github.com/PacktPublishing/Microsoft-Intune-Cookbook.

Deploying Platform scripts

We will start with the original option, which has been available in Intune for longer than the rest. Platform scripts run once on the device and can run in the system or user context. By default, they run in 32-bit mode, but this can be changed on deployment. This is important to note as environmental variables will differ accordingly for both system/user and 32/64-bit.

To find out more about User/System targeting, go to https://andrewstaylor.com/2022/11/22/intune-comparing-system-vs-user-for-everything/.

When running during Autopilot, there is no labeled step where scripts run – they run when it says Preparing apps in User or Device setup. If you hit a time-out issue here, it is more than likely a failed PowerShell script that has not reported a success code in time.

To troubleshoot and view the output of a script, retrieve the script ID from the address bar in the Intune portal. The output will be in the following location under a subkey...

Configuring Remediations

While Platform scripts are excellent for run-once scenarios such as when you are provisioning a device, PowerShell is incredibly powerful and there may be situations where you want something to run more than once, or you want to view the output in the console itself.

This is where Remediations (formerly Proactive Remediations) come into play. They can be set to run on a schedule, but as they work with a detection and remediation configuration, the script itself will only run if required.

A Remediation is split into two scripts: a Detection script and a Remediation script.

The detection script is arguably the most important of the two as this decides whether the Remediation script needs to run. The key output here is the exit code. An exit code of 0 means the device is compliant with the check and no further action is needed. If the exit code is 1, it causes the remediation to run.

There are no restrictions on the content of the scripts, so long...

Using custom detection scripts in apps

While we covered this briefly in Chapter 11, detection scripts work slightly differently from a PowerShell platform or remediation script, so this recipe will cover how they work and include some working examples.

How to do it…

The important thing to note with a custom detection script is it requires both an exit code (0) and a standard output (STDOUT). Sending an exit code of 1, or not including the STDOUT, will flag the installation as failed.

Before searching the STDOUT, the script must return an output. So, the following code will suffice and mark the installation as successful:

Write-output "App found"
Exit 0

Now, we can use and deploy a custom detection script:

1. To use a custom detection script, you must add the script during packaging or after deploying. For post-deployment, click on Apps, then Windows. Find the application in question and click on it.
2. Now, click on Properties and click Edit next...

Using custom requirements scripts in apps

Another PowerShell option is using custom requirements scripts. While the requirements rules are reasonably comprehensive, you may want to take these a step further – for example, only deploy an application if the device is manufactured by a particular company.

One particularly useful application for these is when you are updating available applications. As these are user-installed, when you deploy an update to them, the user has to manually install the latest version from the company portal (providing you have the detection rules set correctly to notice it needs re-installing). This is far from ideal, especially when you are dealing with a zero-day exploit.

In this situation, you can deploy an application as required to everyone and then set a requirements rule that it must detect the application is already present on the device to install.

These work differently and are closer to compliance scripts than remediation or detection...