Creating PowerShell 3.0 Logon Scripts for Domain environments


To totally unlock this section you need to Log-in


Login
When Group Policy was delivered with Windows 2000, it allowed administrators to execute batch file-based scripts at user logon or logoff, as well as at computer startup and shutdown. This enabled administrators to configure parts of the environment or execute additional programs during those times. Windows 7 introduces support for executing PowerShell scripts as well, giving administrators more comprehensive tools for real-time configuration during these system events.

Our test example will be a script that maps a network share to a local drive letter - say 'P:'. Let us begin by making sure the VBScript method called MapNetworkDrive works smoothly.

Re-using VBScript

# Pure VBScript - For Information Only

Set objNetwork = WScript.CreateObject("WScript.Network")
objNetwork.MapNetworkDrive "P:" , "\\YourMachine\Stuff"

This may sound bizarre, but you may share out a folder on your local machine, and use that in your test script. The reasoning is that, when getting started, you might avoid problems associated with permissions, firewalls, or flaky wireless networks. The following example script assumes you have a share called 'Stuff'.

Creating the PowerShell 3.0 Logon Script File

Adding the PowerShell Wrapper to VBScript Commands

The crucial piece of knowledge is that PowerShell has a cmdlet called New-Object.

Furthermore, you should specify the type of object as: WScript.Network.

# PowerShell v 3 Logon Script Example

$Net = $(New-Object -ComObject WScript.Network)
$Net.MapNetworkDrive("P:", "\\YourMachine\Stuff")

Note 0: Naturally, to get this example working you need to change \\YourMachine to a computer on your network.

Note 1: You may recognise $Net = as declaring a variable.

Note 2: Our old VBScript friend MapNetworkDrive is method that is available to the ComObject called WScript.Network.

Testing the .ps1 Logon Script

Assuming the above script works, then we can progress to saving the commands into a .ps1 file. The easiest way is using the PowerShell 3.0 ISE; simply go to the file menu and 'Save', just as you would with an application like Notepad.

By design, and by default, script paranoia will prevent our PowerShell .ps1 file from actually running. Let us take a time-out and investigate how to overcome this problem by changing the computer's Execution policy.

# Windows PowerShell v 3 Execution Policy

Get-ExecutionPolicy

The result is likely: Restricted.

Fortunately, we can use the sister verb called 'Set' to allow PowerShell scripts to run.

Clear-Host

Set-ExecutionPolicy -ExecutionPolicy Unrestricted
Get-ExecutionPolicy

Note 4: 'Set' instigates a serious change in your machine's ability run scripts, so you should read the on-screen message before you click 'Ok'.

Note 5: If time permits please check the other options such as RemoteSigned, and for later experiments, Bypass.

Assigning Your Logon Script with Group PolicyPowerShell 3.0 Logon Script Gpedit.msc

The last part of our mission is to 'wire-up' the PowerShell logon script to a Group Policy. On a stand-alone machine launch Gpedit.msc, or on a Domain Controller launch GPMC.msc.

Here are the Group Policy paths to set the user and computer logon scripts.

User Configuration\Windows Settings\Scripts (Logon/Logoff).

but also:

Computer Configuration\Windows Settings\Scripts (Startup/Shutdown).

In this case, make sure you expand the User Configuration, then examine the Windows settings, where you should find:

Scripts (Logon/Logoff) ... see screenshot.

Creating PowerShell 3.0 Logon Scripts for Domain environments

Creating PowerShell 3.0 Logon Scripts for Domain environments

Naturally, you select 'Logon' from the right pane. What happens next depends on whether you have Windows 7 or Windows Server 2003 R2 or later.

As ever, if you have an up-to-date operating system, then configuring is easy. Select the PowerShell Scripts tab, then click on 'Add...' and now make the connection between your PowerShell.ps1 file and the 'Scripts' policy.

Creating PowerShell 3.0 Logon Scripts for Domain environments

Creating PowerShell 3.0 Logon Scripts for Domain environments

Note 6: The trick is to copy your logon.ps1 file (into memory) then paste into the location revealed by the 'Add...' button.

The actual location C:\Windows\System32\GroupPolicy\User\Scripts\Logon is a hidden folder. This is one reason the above interface provides a 'Show Files...' button. To see the files in Windows Explorer you may need to change the folder view options.

Creating PowerShell 3.0 Logon Scripts for Domain environments

Creating PowerShell 3.0 Logon Scripts for Domain environments

Another frustration is if you try and paste files to this folder using the Windows Explorer you get permissions problems. If you paste using the Group Policy Editor it just works, whereas Explorer just complains about permissions.

Troubleshooting PowerShell 3.0 Group Policy

Assigning PowerShell scripts to Group Policy could give some trouble. My best advice is keep trying slightly different options. Wherever possible make it simpler and simpler, seek to isolate one item at a time. For example test, the logon.ps1 file in isolation, check that Group Policy is working by having a .vbs file with just one command:

WScript.Echo "Logon Script".

One problem in Windows 7 (and later) is that mapped network drives don't show up in Windows Explorer. However, you can see/check them in PowerShell! By using GetChildItem "Drive Letter" lists the files, actually plain C:\ (or other drive letter) lists the files.

.Bat - An Alternative Wrapper for Logon Scripts

Batch files for logon scripts are strictly a Plan B option; a fall-back for situations where the above method fails. If you created .bat files in the days when DOS was king, then this is straightforward process, if not, then just copy and paste!

The situation is that something is preventing you from assigning the PowerShell logon script to a Group Policy. The solution is to create a .bat file that calls your PowerShell .ps1 file (holding the commands to map a drive).

Observe the neat feature of the PowerShell file: -Bypass. The purpose of this parameter is to over-ride any restrictions that maybe present on the computer where you want to run a logon script.

: PSLogon.bat Example

Powershell -NoLogo -file \\Computer\PShell\logon.ps1 -executionpolicy bypass
pause

Note 7: The above script is for testing. Below is the real deal, with commands to suppress profiles. (: means remark)

: PSLogon.bat PowerShell Example

Powershell -NoLogo -file \\Computer\PShell\logon.ps1 -WindowStyle hidden -NoProfile -executionpolicy bypass
: Pause