When it comes to deploying scripts for Intune admins, there is only one script method available: Intune PowerShell Scripts. PowerShell can be a powerful format, but you likely have existing scripts you want to leverage with your domain-joined and non-domain-joined machines. Intune script capabilities don’t enable you to deploy VBscripts, batch scripts, or JavaScript scripts.
- These PowerShell scripts from Intune may only succeed and run only one time, and never again (unless the script changes). Additionally, if the script fails after three retries, no additional attempts are made to run the script. This makes reoccurring scripts impossible via the Intune PowerShell scripting method.
- When a user or computer changes groups in Intune (or a policy no longer applies) whatever the script did stays on the machine. Intune has no way to “revert” or “undo” a script after its delivered.
- There’s no way to trigger a script based upon an event, like connecting to a VPN, or to schedule a script to run at a specific time or day or when a process launches.
- There’s no way to filter where your script should run. If you have users or computers together in various groups, you might need to unwind your existing Azure or AD group memberships just to use Intune scripts.
- Beyond that, scripts cannot be run interactively nor can they perform admin-like things in the user context.
The screenshot below shows the full complement of options available for script deployment using MEM (Intune).
Deploy Scripts via Intune to Windows 10 Computers with Four Times the Choice
PolicyPak Scripts Manager offers your four times the choice that Intune has, which means you can leverage more power over any of your Windows 10 machines, regardless of whether they are MDM-enrolled, domain-joined, or non-domain-joined. What’s more, the PolicyPak editors are built inside the Group Policy Management Editor, a tool that admins already use. You can take those scripts and use them on-prem with Group Policy or export them for use within Intune.
Creating a policy in PolicyPak Scripts manager is easy (see image below).
PolicyPak Scripts Manager uses a wizard to guide you through the policy making process. PolicyPak Scripts Manager supports multiple script types including Batch, PowerShell, VB, and JavaScript, which gives you real choice as to which script type works best for you. You can either write the script commands out yourself or browse to an already existing file using the File button shown below.
The power of choice that PolicyPak Scripts Manager delivers isn’t restricted to just its selection of script formats. It also provides you the ability to revert scripts when a policy doesn’t apply. For instance, in the previous screenshot we mapped a shared printer. Let’s say we want to delete all network printers should the user ever fall out of scope of the designated policy. If we want to use a VB script this time instead of a Batch file, it’s no problem. Just create the reverted action script using a VB Script as shown below.
Of course, if you prefer PowerShell, you can also select it as your choice. Let’s say we wanted to map a network drive. In this case we will run it interactively as “Get-Credential” will prompt the user to enter a password as shown below.
The final step in this example is to decide how often you want the script to run. You can choose to run it on every policy processing and log in with the “Always” flag, as shown below.
Use Freedom of Choice when Triggering Scripts
If you really want super admin-like powers for script deployment then look at the various trigger options available with PolicyPak Scripts Manager. Triggering is nothing new. Group Policy has allowed you to utilize logon and logoff triggers since the beginning. However, it’s a different world today than it was 20 years ago, and PolicyPak is constantly evolving in order to adapt to the dynamic, ever-changing world of tomorrow. PolicyPak Scripts Manager offers you to a variety of trigger points to choose from.
Have you been trying to figure out how to continue to deploy your arsenal of on-premise scripts to users in your newly VPN-connected world? With PolicyPak Scripts Manager you can initiate scripts when a user connects with VPN regardless of your VPN solution. This means you can map that drive when connected and then delete the mapping once disconnected. You can also trigger scripts based on the start or closing of a designated process, a session lock, an assigned schedule, or the traditional logon and logoff actions as shown below.
Granular Choice of Item-level Targeting
Microsoft Intune doesn’t enable you to granularly select where your scripts should apply. But using Intune with PolicyPak is different.
If we want to accurately deploy our script policy by VPN triggering, we could choose only members of a select user group that use Windows 10 portable machines. We can even add an IP range so that the policy only applies when the computer is located off of the corporate network. You can see all of these conditions in the screenshot below.
Choice Gives You Power
PolicyPak can accentuate your Intune scripting abilities. As we’ve seen, Intune’s scripting isn’t bad, but it is limited to:
- Only supporting PowerShell
- No filtering/item-level targeting
- No revert script capabilities
- No interactivity
- No ability to always re-apply a script
- No triggers
Here are a few videos to help you see the full picture of what we’ve gone over here:
- Watch a demonstration video to learn more about the functionality of PolicyPak Scripts manager and how it enables you to deliver settings more than once, use any scripting language you want.
- Watch a demonstration to learn how to deliver these scripts via Intune (or any MDM).
- Watch a demonstration on how to run a script when Windows 10 connects to a VPN.
- Watch a demonstration on how to run a script when a process runs.
If choice is power, PolicyPak delivers it.
