How to deploy PowerShell V2 to your clients

PowerShell V2 allows you to do a lot that the V1 version could not due.  Two important ones are remoting and group policy scripts.  PowerShell V2 comes preinstalled on Windows 7, but what about the Vista and XP clients in your domains?  This article deals with one method of deploying the required software to your clients.

We first need to download the appropriate software for your XP and Vista clients.  You can obtain that software at

http://support.microsoft.com/kb/968929

Pick the correct version and platform under the heading Windows Management Framework Core (WinRM2.0 and Windows PowerShell 2.0)

Save these files to a location on your domain where all clients can read from.  I created a share on my domain controller called PS2_Share and stored the installation files there.

We are going to use Group Policy to deliver these packages to their respective clients.  Since both packages that are downloaded are not .msi files, we have a problem.  We are going to utilize VBScript to help with this deployment.  We could use .zap files, but that would require user intervention and also providing them with elevated credentials.  For most organizations, this would violate the “Principal of Least Privilege.” This is a rare occasion that I would use VBScript.  But since our clients do not yet have PowerShell installed on them, I have little choice.  I created two scripts.  On called VistaPS.vbs and the other called XPPS.vbs.

For the VistaPS.vbs script, I entered:
Set objShell = wscript.CreateObject(“wscript.shell”)
strTemp = “wusa.exe \\MCT-1\PS2_Share\Windows6.0-KB968930-x64.msu /quiet”
objShell.run strTemp


For the XPPS.vbs script, I entered:
Set objShell = wscript.CreateObject(“wscript.shell”)
strTemp = “\\MCT-1\PS2_Share\WindowsXP-KB968930-x86-ENG.exe”
objShell.run strTemp

Of course, your exact path and file name will very. 

Our next step is to deploy these files with group policy to the clients.  You need to create two GPOs.  One that is scoped to your Vista clients, and one that is scoped to your XP clients.  There are various ways in which to do this.  Use the one that works best for your organization.  For this example, I have two Organizational Units.  One named Vista Clients and one named User Accounts.


Next I open Group Policy Management and create two new GPOs.  One I will call Vista_PowerShell_Deployment and the other I will call XP_PowerShell_Deployment

Edit the Vista_PowerShell_Deployment GPO.

Expand Computer Configuration \ Policies \Windows Settings \ Scripts

Right click Startup and click Properties.

Click Add.

Click Browse

Browse to the UNC path where you stored the scripts.

Click VistaPS.vbs and then click Open.

Click OK twice.

Close Group Policy Management Editor.

Make sure the Vista_PowerShell_Deployment gpo is linked to the Vista Clients OU.  Reboot your Vista client.  Take note, this may take two full reboots to work.  Before the reboot, I opened a command prompt and typed GPUpdate /force to force the client to update its policies.  I then did a GPResults /r to verify that it has the new GPO.


Now I am rebooting.

On reboot, I noticed that wusa.exe and TrustedInstaller.exe were running in the task manager.  It took several minutes for this to complete.  Since this is a requirement at startup, it will continue to consume resources each time the client is rebooted.  For this reason, a staged rollout would be better so you can remove this requirement once all the clients for that stage have it installed. 

After a few minutes, I you will notice the programs appearing:


Expanding both areas will take you to the PowerShell V2 components that were installed.

Since this is a Windows update, the best option would have been to deploy it via WSUS or System Center.

Now for the Windows XP installation.  This one was a monster to figure out.  A System Center deployment would be wonderful if you already have System Center.

The Windows XP file is not an update, it is a .exe file.  Again, scope only small groups to receive this file to avoid an unnecessary degradation in user experience.  You also need to make sure that you have been running your updates and have your XP clients at SP3 at minimum.  You also need to make sure the /NET Framework 2.0 SP1 is installed as well.  There is also a hot fix called NetFx20Sp1_x86.exe that you need to have deployed as well.

After testing both startup and shutdown scripts without success, I ran the installation manually and discovered an installation step.  This will require user intervention.  Moved the script to a logon script in the User Configuration.  This starts the installation within a minute of the user logging in.  They still must manually tell it to install.  Also, when they log on after the installation, they will receive this error:


This is another good reason to scope the XP deployment in small stages.  That way you can remove this GPO from being applied to the user shortly after installation. 

What if the user logs into a Vista workstation? Unfortunately, it will try to install.  After the file extraction, I received this error:


Your error may be different.  We need to prevent this from happening.  We will use a WMI Filter in Group Policy to make sure that this GPO is only applied to Windows XP

In Group Policy Management, right click WMI Filters and click New

In the name field, type Windows XP Filter and click Add.

In the Query field, type select * from Win32_OperatingSystem where version like “5.%” and ProductType = “1” and click OK.

Click Save.

Click on XP_PowerShell_Deployment.

The filter says to only apply to Windows version 5 (XP and 2003).  The ProductType limits the installation to type “1”.  Type 1 is a client OS.  This means that it will only deploy to Windows XP.

In the WMI Filtering drop down box, select Windows XP Filter.


Click Yes in the Group Policy Management dialog box.

Testing by logging into the Vista client shows that the installation does not execute.  On and XP client, the installation does start.