Using Custom Scripts to Support Endpoint Management

Leveraging Intune to Run PowerShell Scripts

Anyone working in the PC management space for a while must remember when most tasks were done via scripts (remember the good old days of Microsoft System Management Server, the predecessor of Microsoft System Center Configuration Manager). Scripts are no longer needed as much because many tasks can be accomplished via purpose-built management tools. However, scripts are still needed to perform specific tasks, like applying a custom registry key required by a third-party app, as management tool vendors may not put every setting in their interface for easy access. Scripts are still the best friend for administrators.

Intune is Microsoft’s latest offering for performing common endpoint administrative tasks. As mentioned earlier, vendors like Microsoft won’t allow all of the settings on the management tool’s user interface. That’s why we often write PowerShell scripts to perform tasks that we need to do.  In this article, I discuss different ways to leverage Intune to run PowerShell scripts (or even a simple BAT file) as part of endpoint management, specifically for Windows workstations, to perform custom administrative tasks.

In this article, we are going to talk about the Intune features that you can leverage to run scripts:

• Win32 App Deployment
• Platform Scripts
• Remediations

Using Win32 App to Deploy Script

Win32 App Deployment is something I try to avoid in projects, usually unsuccessfully. I am not a big fan of using the Win32 App Deployment for the packaging and deployment of applications because of the complicated process involved when uploading the app to Intune. For those who don’t know the packaging process, you can refer to this article. It’s the most powerful offering in Intune for app Deployment as it allows you to do anything without the need to build an MSI package.

The Microsoft documentation for Win32 app management is very detailed, so I’m not going to go into the topic in depth here. I want to share the high-level steps of how we use Win 32 App management as a way to run PowerShell scripts on managed Windows endpoints.

1. In your development/admin workstation, create a folder and put the PowerShell script you need to run inside the folder
2. Use the Win32 Content Prep Tool to compress the folder into a .intunewin file
3. Upload the intunewin file created in step 2 to Intune by adding the Win 32 app in Endpoint Admin Center > Apps > Windows, as stated here
4. Specify the command you need to run your script (like powershell.exe ./installscript.ps1), as shown in Figure 1. Depending on your script, you may want to specify the command in at least one of the fields below:
   1. Install command – this is a mandatory field that defines the command to use when the package is first deployed to the endpointUninstall command – this is a mandatory field that defines the command to use when the administrator removes the app assignment and triggers the uninstall
   1. Detection Rules – This is the script used to determine if the install command is completed successfully. For example, if your script applies a registry key, then the detection script is to check if the key exists.

The key benefit of using Win 32 App deployment to run scripts is that it allows us to run almost any script, PowerShell, BAT file, and even scripts with the depending packages (e.g., the BAT script will call a custom EXE). All you need to do is make sure all the needed files are packaged inside the content package.

One thing to note is that all the Win 32 App Deployment packages are executed regularly by Intune. This means the install command will get executed every time unless a detection script is specified. The upside of this design allows us a way to run the script regularly. But in case you only want to run the script once, you should specify a detection script as shown in Figure 2. The detection script is a PowerShell file that runs the logic you need and instructs Intune if the app package is already installed. Intune will consider the app installed if the return code is 0. Make sure you write your script in a way that returns the correct value. Microsoft also supports other means of detection now, like checking registry values. You can check the way to use other detection rules here.

Win 32 Apps deployment uses Intune Management Extension to execute the script. All the packages will be downloaded from Intune and stored in C:\Program Files (x86)\Microsoft Intune Management Extension\Content. Make sure there is enough space available in this folder if you are going to run a script with some large content.

Platform Script

Intune has a function called Platform Script, which is designed specifically for administrators to execute endpoint management scripts. Platform Script function leverages the Intune Management Extension that is installed to every Windows endpoint after they are onboarded to Intune to execute the script, and I found that some older devices were not able to run the script because they could not meet one or more of the prerequisites (for example, the correct version of the .NET Framework was not installed).

Running the platform script is very simple: upload the PowerShell script to Intune, as shown in Figure 3, and then specify how the script should be executed. The platform script execution engine will capture the return code to determine the execution status.

The main issue I’ve encountered with using the platform script is that there’s no straightforward way to get the output. Sometimes, I just need to run the script and capture the result. But there’s no way for us to capture the result unless we store it somewhere and use other Intune functions to retrieve it or manually parse the log located in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Otherwise, we don’t know anything about the output other than success or failure based on the script’s return code. But most importantly, the script only executes once, which may not work if the script needs to run multiple times. I was once tasked to make a script that ran a shutdown command on every Windows endpoint on Friday night. The platform script’s built-in feature just does not work. The workaround is to have Platform Script execute a script that creates a scheduled job and, in turn, runs the script as many times as required. This is not ideal as it is very difficult to track who created the job and hard to modify the job when necessary (like changing the execution time).

Remediation

Remediation is a relatively new feature in Intune, which is a very handy way to run an endpoint management script. It supports three key features that Platform Script or Win32 App doesn’t:

• Ability to run the script regularly
• Ability to capture the results of the script
• Ability to run the script on-demand from the Intune Admin portal

Both Remediation and Platform scripts support the creation of detection scripts, which are used to determine if the script should be executed. When preparing the script, make sure you are adding return code (I know many admins don’t when preparing the script), as it’s important for the detection script to work. When the detection script returns 1, Intune will consider the actual remediation script that needs to be executed. That’s why there are two script file upload boxes when creating Remediation in Intune, as shown in Figure 4.

If you want to run the script regardless of the machine’s state, upload it as a Detection script. It runs every time the schedule is up. The Remediation script executes only when the Detection script returns 1.

If you observe Figure 4, you’ll notice I’m illustrating the most common use case of Remediation: Uninstalling the SCCM client. This is an ideal example of using Remediation when you migrated your machines to be managed by Intune.

The only thing I will complain about using Remediation is that there is no easy way to check the result and/or output of the script other than using the Report. The device status view in Intune Admin Center, as shown in Figure 5, only tells you whether the script runs ok or not.

But if you want to get the output of the script, you will have to export the Device Status, check the CSV file, and look for the Output columns, just like the example shown in Figure 6.

The most important aspect of using Remediation is licensing. This only works if you have a Windows 10/11 E3/E5 or Windows 10/11 VDA license.

Leverage Other Intune Features

Don’t get me wrong, I’m a big fan of using scripts for endpoint management, but it may be hard for other team members or clients to understand what the script does or maintain it for the future. I always recommend that you first consider using other Intune features, like configuration profiles and device restrictions, to apply device configurations before even considering using scripts. Scripts should only be used when there are no other ways to do it with other Intune features (like deploying a custom screen saver). The script is always considered as a complement, not a primary, means of applying configurations to an endpoint.

When you do need to run a management script on a Windows endpoint, I would suggest considering the Intune feature in the following order of preference to deploy and run your scripts:

1. Remediation
2. Platform Script
3. Win32 App