Over the last few articles I’ve been demonstrating ways to leverage PowerShell scripts with Group Policy. You may need to catch up to fully understand everything I’m doing in this article, which uses a PowerShell computer start up script to remove old user profiles. This is the script I will be using:
Latest posts by Jeffery Hicks (see all)
#requires -version 3.0

#Remove-UserProfile.ps1

[cmdletbinding(SupportsShouldProcess)]

Param(
[Parameter(Position=0)]
[ValidateNotNullorEmpty()]
[int]$Days=30
)

Start-Transcript -Path C:\ProfileCleanup.txt -Append

Write-Warning "Filtering for user profiles older than $Days days" 
Get-CimInstance win32_userprofile -Verbose | 
Where {$_.LastUseTime -lt $(Get-Date).Date.AddDays(-$days)} |
Remove-CimInstance -Verbose

Stop-Transcript

The script searches for all profiles using the Win32_UserProfile WMI class that have not been used in X number of days, where the default is 30. I’m not using a WMI filter because I’d have to create a filter using a date in the DMTF which is more work than I care to do. There shouldn’t be that many profiles so using Where-Object is acceptable in this case and definitely easier. Any profiles that meet the requirement will be removed using Remove-CimInstance.

I also added code to create a transcript file so I’d have a way of tracking what happened at startup. Be aware that if you test the script in the PowerShell ISE you will get an error since that host does not support transcription. Also, if you use –WhatIf to test you’ll also get an error on the Stop-Transcript line since transcription will never have been started. Technically, I don’t need the Stop-Transcript command since transcription will end as soon as the PowerShell session ends, but I wanted to be thorough. If you try this script, feel free to comment out the last line.

Setup ^

As before, I created a GPO but this time navigated to Computer Configuration – Policies – Windows Settings – Scripts and double-clicked on Startup.

Startup scripts in Group Policy

Startup scripts in Group Policy

On the PowerShell Scripts tab I clicked on Show Files and copied the script to the GPO so it would replicate. Then I could add the script and set a parameter value.

Add PowerShell script to startup scripts

Add PowerShell script to startup scripts

The script has a default value of 30 but in the screenshot I am setting it to 45 days. Click OK a few times to save the policy. Make sure it is linked and enabled to an organizational unit and reboot a test computer running Windows 7 or later.

Testing ^

The best way to test this is with a virtual machine that has a few profiles. You may need to wait a few days to “age” them. Then modify the GPO to adjust the number of days to meet your test age. Take a snapshot of the virtual machine before rebooting so that you can restore and test again if necessary. Or you can revise the script to filter for a specific user profile. Depending on your GPO configuration, you might not see the transcript file if you logon immediately. But give it a few minutes. If you still don’t see anything, then check the System and Group Policy Operational event logs. You also might want to simply run the script manually to see what happens. Again, having a snapshot to roll back will be valuable. Finally, don’t forget to take replication into account if you are making changes to the script or parameter values. You may also want to run gpupdate on the desktop prior to rebooting as well.

Editing tip ^

Once you set up the policy using the Group Policy management console, you can skip the GUI for revising the script or parameters. While, using the GUI is probably the recommended approach, at least for testing purposes you can access the script and it’s configuration through Windows Explorer. Go to \\yourdomain\sysvol\yourdomain\policies.

Access Group Policy startup script in Windows Explorer

Access Group Policy startup script in Windows Explorer

I sorted on Date Modified to find my policy which I’ve highlighted in the screenshot above. Open up the folder and navigate to the Machine\Scripts\Startup.

Startup folder of the policy

Startup folder of the policy

You should be able to see the script. You can edit it directly or copy a new version to this folder and let it replicate. Parameter settings are stored elsewhere. Go back up to the Script folder. You may need to enable Explorer to show hidden files. But when you do, you should get something like in the screenshot below.

pssscripts.ini for PowerShell scripts

pssscripts.ini for PowerShell scripts

The pssscripts.ini file is for PowerShell scripts. The scripts.ini is for traditional scripts. You can edit the ini directly in Notepad.

Parameter settings of the PowerSgell startup script

Parameter settings of the PowerSgell startup script

Here you can see my parameter value of 45. If I want to change it, I can do so here, save the file and let it replicate to my domain controllers. This technique will also work for user scripts. But if you are more comfortable using the GUI, then by all means continue to use the Group Policy management console.

Summary ^

Once you know how to use PowerShell and can write a basic script, you can take advantage of Group Policy and add a whole new level of administration. I love this “set it and forget” approach, although as with any Group Policy setting, be sure to document and test it thoroughly. Now, what sort of tasks do you want to automate for users and computers using PowerShell and Group Policy?