Jeremy Moskowitz founded PolicyPak Software after working with hundreds of customers with the same problem they couldn’t manage their applications, browsers and operating systems using the technology they already utilized.
VPN Script and Automation MUST HAVES for Remote Workers
VPN Scripting is critical today because so much of the workforce is accessing the corporate domain via VPN access. It used to be that VPN access was limited to a select few roles such as IT support personnel or traveling salespeople. Today, though, it’s a new world. With large-scale remote work strategies in place today, VPN scripting and VPN access is now a commodity that nearly everyone needs. What’s more, remote work is a new norm that is here to stay. That means you need permanent solutions to ensure streamlined workflows and user productivity for everyone working from remote workspaces. And you need all of that with minimal supervision.
WEBINAR: Always-on VPN 101
Join Richard Hicks, Always-On VPN guru, and former Microsoft MVP, for an exclusive webinar that focuses on Always-On VPN Best Practices and how you can use PolicyPak to extend your policy delivering power.
For those companies that use Group Policy to configure and manage user desktop environments, connecting to VPN complicates things. That’s because Group Policy was designed for an on-premise world. Take script deployment for instance. As shown in the image below, there are only two options for user-enabled scripts—Logon and Logoff (assuming of course that you are on-prem).
This poses a problem because remote workers need different things depending on whether they are connected to the corporate network or not. While they may need an assortment of mapped drives or assigned printers once they VPN into corporate, their presence may confuse remote workers when working in a disconnected state. In other words, script management today requires more options than just logon/logoff.
VPN Script Triggering with Group Policy or MDM/Intune
For a quick overview of what we’ll talk about here, you can watch this video: PolicyPak Scripts & Triggers: Perform Scripts on VPN Connect and VPN Disconnect – PolicyPak.
Like all of our PolicyPak solutions, PolicyPak Scripts Manager was designed for both on-prem and off-prem worlds. In the following example, we are going to create a policy that will map a couple of drives for remote users. One of the great things about PolicyPak is that we don’t reinvent the wheel. We make the wheel “rounder” by improving the tools you already have with Group Policy.
Everything You Need for Always on VPN
Create VPN and Always On VPN Connections. Rapidly roll out your VPN and Always on VPN Connections. Works with On-Prem and Remote. Domain Joined and Non-Domain Joined. Automatically keeps all PCs updated as needed.
PolicyPak’s editors are built inside the Group Policy Management Editor, a tool that admins already use. Admins can use PolicyPak either on-prem or via VPN with domain-joined machines, or they can export their settings for use within an MDM service like Intune.
As you can see in the image below, creating a policy in PolicyPak Scripts Manager is easy.
If you already have your script written, you can browse to it or you can write it out like in the image below.
One powerful feature of PolicyPak Scripts Manager that you won’t get with Group Policy or MDM is the ability to run revert action scripts for when a policy no longer applies. Although this feature doesn’t apply to this scenario, it is worth pointing out. You can see this option in the image below.
Now here is where the magic comes in. PolicyPak Scripts Manager lets you choose trigger points to initiate the running of a script. While logon and logoff actions have always served as triggers, PolicyPak Scripts Manager lets you trigger a script for a multitude of things such as when a designated process starts or, in this case, when a VPN connection is established.
If you have Cisco AnyConnect, a Microsoft VPN, Fortinet, or other VPN solutions, then PolicyPak Scripts with the VPN trigger will work for you. Notice the trigger options in the screenshot below.
After you select the trigger type, list the VPN server either by its IP address or hostname, as shown below.
If you have ever worked with Group Policy Preferences, then you know how you can apply item-level targeting that allows for granular application of settings to a subset of users or computers. Unfortunately, Microsoft doesn’t enable you the utilize this power of granularity with standard group policy, but PolicyPak does. In fact, nearly all of the management tools in the PolicyPak suite can utilize item-level targeting in the policy creation process. In this case, we want to only apply our VPN-triggered policy to members of the Traveling Sales Users group when they are on their 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.
To complete the process, you can also create a second policy that runs on VPN disconnect to un-map those two network drives, as shown below.
And that is the VPN script magic within PolicyPak Script Manager.
Final Thoughts and Resources
For more information about PolicyPak Scripts with triggers see the links below.
- To see the content of this blog post as a video check out: PolicyPak Scripts & Triggers: Perform Scripts on VPN Connect and VPN Disconnect – PolicyPak
- Additionally, watch this video demonstration on how you can deploy software to remote workers using PolicyPak Scripts Manager.
- And finally, you can 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, and eliminate Group Policy Loopback so you can apply scripts to all users on the machine.
With the many challenges you face today, you could probably use a little magic when it comes to supporting remote workers. PolicyPak has the tools to ensure you have magical admin powers when you need them.