Skip to main content

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.
image

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.
image

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:
image

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:
image

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:
image

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.
image

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.

Comments

Anonymous said…
Jason,

Thanks for this article. I couldn't find much on deploying Powershell 2.0/WinRM to XP clients. I wonder why PowerShell 2.0/WinRM is still an optional update for xp.

I had success with getting the .exe file not prompt for installing by using the /quiet argument.

I am using psexec to help deploy Powershell 2.0/WinRM in one of my scripts.

Thanks for speaking at Max Technical Training Center in Cincinnati, you really inspired me to build tools in PowerShell.


Thanks!

Zach
Zach,

Thank you for the complement. PowerShell was released years after XP. That is when it is an add on. I look forward to seeing you in my 10961 class for PowerShell V3. If you schedule a class a Max Training, be sure to ask for me as the instructor. Rob and I had a discussion this week for me to speak to the group again later this fall.

Take care,
Jason

Popular posts from this blog

Adding a Comment to a GPO with PowerShell

As I'm writing this article, I'm also writing a customization for a PowerShell course I'm teaching next week in Phoenix.  This customization deals with Group Policy and PowerShell.  For those of you who attend my classes may already know this, but I sit their and try to ask the questions to myself that others may ask as I present the material.  I finished up my customization a few hours ago and then I realized that I did not add in how to put a comment on a GPO.  This is a feature that many Group Policy Administrators may not be aware of. This past summer I attended a presentation at TechEd on Group Policy.  One organization in the crowd had over 5,000 Group Policies.  In an environment like that, the comment section can be priceless.  I always like to write in the comment section why I created the policy so I know its purpose next week after I've completed 50 other tasks and can't remember what I did 5 minutes ago. In the Group Policy module for PowerShell V3, th

Return duplicate values from a collection with PowerShell

If you have a collection of objects and you want to remove any duplicate items, it is fairly simple. # Create a collection with duplicate values $Set1 = 1 , 1 , 2 , 2 , 3 , 4 , 5 , 6 , 7 , 1 , 2   # Remove the duplicate values. $Set1 | Select-Object -Unique 1 2 3 4 5 6 7 What if you want only the duplicate values and nothing else? # Create a collection with duplicate values $Set1 = 1 , 1 , 2 , 2 , 3 , 4 , 5 , 6 , 7 , 1 , 2   #Create a second collection with duplicate values removed. $Set2 = $Set1 | Select-Object -Unique   # Return only the duplicate values. ( Compare-Object -ReferenceObject $Set2 -DifferenceObject $Set1 ) . InputObject | Select-Object – Unique 1 2 This works with objects as well as numbers.  The first command creates a collection with 2 duplicates of both 1 and 2.   The second command creates another collection with the duplicates filtered out.  The Compare-Object cmdlet will first find items that are diffe

How to list all the AD LDS instances on a server

AD LDS allows you to provide directory services to applications that are free of the confines of Active Directory.  To list all the AD LDS instances on a server, follow this procedure: Log into the server in question Open a command prompt. Type dsdbutil and press Enter Type List Instances and press Enter . You will receive a list of the instance name, both the LDAP and SSL port numbers, the location of the database, and its status.