Considerations for Using the PowerShell Script

  • Article

Applies To: Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Vista

This topic addresses some of the additional steps to consider before deploying this as a solution in a production environment.

Signing PowerShell scripts

PowerShell scripts must be signed to run on client computers that have a default PowerShell configuration. Running unsigned scripts requires a configuration change. We recommend that you change the signing requirement only on test computers on which you develop and test your PowerShell scripts. Do not remove the signing requirement on production client computers because it increases the potential attack surface of the computer to malicious scripts.

By default, the PowerShell scripting engine runs only scripts that are signed by using a certificate that was issued by a trusted certification authority (CA). If you have a CA in your organization, such as one running Active Directory® Certificate Services (AD CS), then you can configure it to automatically add the root CA certificate to the Trusted Root Certification Authorities store on your client computers automatically. Then you can issue a code signing certificate to the user who is tasked with signing the scripts used in your organization. By only signing tested and approved scripts, and by preventing client computers from running any unsigned scripts you help to maintain the security of the network.

For more information about signing PowerShell scripts, see Windows PowerShell: Sign Here Please (https://go.microsoft.com/fwlink/?linkid=160357) in TechNet Magazine. For more information about code signing in general, see Introduction to Code Signing (https://go.microsoft.com/fwlink/?linkid=59273) on MSDN. For more information about setting up your own CA, see Active Directory Certificate Services (https://go.microsoft.com/fwlink/?linkid=136444) in the TechNet Library.

Configuring post-connect actions by using Task Scheduler

Once you have your VPN connections deployed to all of your client computers, you might want to no longer run the PowerShell script as a logon script. Instead, if you are running Windows Vista or Windows 7, then you can configure a scheduled task that runs every time the user connects by using the VPN. This task can run the script to update the details of the VPN connections to ensure that they are current.

When a user connects by using a VPN connection, the remote access software automatically logs events that indicate the connection stages and connect or failure status. For example, after a VPN is successfully connected, the remote access service logs Event ID 20225 – “RAS Connection Establishment” in the Application event log.

Task Scheduler can be used to start an action whenever a specific event ID appears in the event log. In this case, you can cause the PowerShell script to be run whenever event ID 20225 appears in the Application event log.

The command that you schedule to run is similar to the following command:

Powershell.exe –NonInteractive –command \\vpnserver.contoso.com\scripts\create-conn.ps1 \\vpnserver.contoso.com\scripts\settings.xml

Substitute the path to your copy of the scripts on your server.

To create the scheduled task, run the following command. Although it wraps to multiple lines here, be sure to enter the command on a single line:

schtasks /create /F /TN "VPN Connection Update" /TR "Powershell.exe -NonInteractive -command \\vpnserver.contoso.com\scripts\create-conn.ps1 \\vpnserver.contoso.com\scripts\settings.xml" /SC ONEVENT /EC Application /MO " *[System[(Level=4 or Level=0) and (EventID=20225)]] and *[EventData[Data='Contoso VPN']] "

Substitute the correct paths for your environment. The “Level=4 or Level=0” parameter specifies Information events only. Also, note the last parameter, and change the name of the VPN connection to the friendly name of your VPN connection. This last clause ensures that the script only runs when you connect by using the specified VPN connection. Other connections do not start the script.

After you test the command, you can include it in a script that is deployed by using Group Policy similarly to the one that deploys the script in a logon script.