PowerShell: Update-Help via Scheduled Task in Group Policy Preferences

Introduction

If you’re like me, you probably like to ensure that all your computers have PowerShell updatable help updated on a regular basis. You can achieve this using a variety of methods, but since Group Policy Preferences are available out of the box using Windows 7 and later, I figured it would be the perfect tool to keep PowerShell help up-to-date! The following guide will show you how to implement a Windows Scheduled Task to update PowerShell version 3.0 help on a regular basis.

The following operating systems include Group Policy Preferences Client Side Extensions (GPP-CSE) out of the box:

  • Windows 7
  • Windows 8
  • Windows Server 2008 R2
  • Windows Server 2012

You can also deploy the Windows Management Framework Core 3.0, and Group Policy Preferences Client Side Extensions to Windows Server 2008 non-R2 systems, however the equivalent client operating system, Windows Vista, does not support WMF 3.0.

Setup Procedure

On a server where it’s installed, open the Group Policy Management Console (GPMC.msc). Create a new Group Policy Object (GPO).

2013-04-03 Create new GPO

Navigate to the Computer Configuration –> Preferences –> Control Panel Settings –> Scheduled Tasks node
Right-click the Scheduled Tasks node, or click the Action menu, and then do New –> Scheduled Task (At least Windows 7).

Group Policy Preferences - Scheduled Tasks

Fill out the fields similar to the screenshot in this post. Make sure that you configure the task to run as the NT AUTHORITY\System account, and to Run with highest privileges. Updating PowerShell v3 help is an administrative task, and requires an administrative user token in order to run properly for all users.

Creating a scheduled task.
Creating a scheduled task.

On the Triggers tab, create a new trigger, and configure it according to this screenshot. In this example, we are executing the task on a recurring basis, every 7 days, with up to 8 hours of randomization. This should help to reduce network load by having clients or servers update randomly throughout the day, rather than all at one time.

Creating a trigger for the scheduled task.
Creating a trigger for the scheduled task.

Once you’ve created the trigger, visit the Actions tab and create a new action. We’ll simply configure the action to Start a Program, call PowerShell.exe, and then pass in the parameters: -Command “Update-Help -Force;”

Configuring an action for the scheduled task.
Configuring an action for the scheduled task.

Conclusion

After you’ve finished creating the action, you should be all set! Make sure you link the GPO to an organizational unit (OU) where you’ve got client or server Active Directory Computer objects, run a gpupdate on a test client, and make sure that the policy applies correctly! Once the policy has applied, you can verify that the new Scheduled Task exists by launching PowerShell (as Administrator) and running the command:

[cc lang=”powershell”]
Get-ScheduledTask -TaskName “PowerShell Update Help”; # Or whatever you named yours.
[/cc]

Now sit back, wait for all your computers to refresh their group policy configurations, and you’re on your way to automated, updated documentation built into PowerShell!

Note: One issue I experienced while creating this Group Policy configuration was using a special character (colon) in the name of the scheduled task. The client systems didn’t seem to like this too much, even though the Group Policy Preferences editor didn’t seem to care too much. In the Application event log on one of my Windows Server 2012 servers, I got a Warning saying: “The computer ‘PowerShell: Update Help’ preference item in the ‘Global Server & Desktop Policy {EF2BD45E-53B6-4850-93A0-D674DECEE9B3}’ Group Policy Object did not apply because it failed with error code ‘0x8007007b The filename, directory name, or volume label syntax is incorrect.’ This error was suppressed.

To solve this problem, I removed the colon from the name of the Scheduled Task. It doesn’t seem to like special characters in the name too much.

Note 2: Another issue I experienced was changing the configured user account, for the Scheduled Task, from a domain user account to the Local System (NT AUTHORITY\System) account. After doing this, I started getting a different warning in the Application event log saying: “The computer ‘PowerShell Update Help’ preference item in the ‘Global Server & Desktop Policy {EF2BD45E-53B6-4850-93A0-D674DECEE9B3}’ Group Policy Object did not apply because it failed with error code ‘0x80070005 Access is denied.’ This error was suppressed.

To solve this issue, I think I just had to go back into the Group Policy editor and re-define the user account that the Scheduled Task was configured to run under.