Automating the world one-liner at a time…
The information here relates to Windows PowerShell 1.0 installer on downlevel platforms (XP SP2, W2K3 SP1 and above).
The job of installers is to create an environment on a user’s machine, so that the underlying software works seamlessly on the machine. Typically most installation scripts copies some files and sets some registry keys. This appears to be simple on the first hand but it gets little complicated if you bring servicing into picture. Installation script must ensure that the underlying software is serviceable.
Herein I will try to explain what Windows PowerShell installer does behind the scenes.
Choose an appropriate Powershell installer depending on the OS platform and language from http://www.microsoft.com/powershell. The following operations are performed by the installation software:
1. Check if Powershell can be installed. Installation will fail if any of the following is true:
(a) Only an administrator can install PowerShell. So for non-administrator the installation will fail.
(b) Supported OS. Remember there is a separate installation package for OS Platform + language
(c) PowerShell is already installed
(d) CLR is not installed
2. Give an opportunity to user to see “End User License Agreement”. Depending upon circumstances, this will give an opportunity to the user to either go ahead with the installation or cancel the installation task.
3. Install Windows PowerShell related files (binaries/text files) onto user’s machine.
For list of files installed see http://support.microsoft.com/?kbid=926139
All the files will be copied to %windir%\system32\WindowsPowerShell\v1.0 directory.
Let’s call this PSHOME. All the language neutral files will be copied to PSHOME and language dependent files will be copied to PSHOME\<lang code> sub-directory. All the help related content + native unmanaged resources are language dependent as these really are unique per language. For example, a German version of Windows PowerShell should show help in German whereas an English version should show in English.
4. Add Windows PowerShell specific registry keys.
PowerShell environment depends on the existence of the following registry key and subkeys.
Let’s go through each of these subkeys:
a. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1 Install
The existence of this key will tell users that PowerShell is installed
b. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1 PID
This key will help our Product Support team to categorize customer calls to a specific product and this key also allows other dependent products to distinguish between different versions of PowerShell ie., RC2 and RTM
RC2 PowerShell will set this key information to 89393-100-0001260-00301
RTM PowerShell will set this key information to 89383-100-0001260-04309
c. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\<Lang code> Install
The existence of this key will let users know what languages the installed powershell supports. For example HKLM\SOFTWARE\Microsoft\PowerShell\1\1033, Install = 1 means English version of PowerShell is installed.
Language codes for other languages:
2052 zh-CHS (Chinese-Simplified), 1028 zh-CHT (Chinese-Traditional),1031 de(German),1033 en(English),3082 es(Spanish),1036 fr(French),1040 it(Italian),1041 ja(Japanese),1042 ko(Korean),1046 pt-BR(Portugese-Brazil),1049 ru(Russian)
This key contains information used by PowerShell engine. It contains information like PowerShell Version, Application Base and CLR version.
The information under “ShellIds” relate to different Custom Shells. The main powershell.exe implements a console host that uses PowerShell engine functionality. The shell ID for this console powershell.exe is “Microsoft.PowerShell”. The ID is defined inside the custom shell at the build time.
f. HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Windows PowerShell
This contains Powershell Eventlog related information.
g. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows PowerShell 1.0
This contains PowerShell installation related information like “Installed By”, Date of Installation. All this information typically shows up in Add/Remove programs. Notice Uninstallation command here.
h. Associate.ps1,.ps1xml extensions to text editor (see for entries like HKCR\.ps1 )
i. Associated .psc1 extension to PowerShell.exe
j. Safeguard .ps1, .ps1xml, .psc1 files so that AssocIsDangerous() returns true
k. Add Powershell cryptography related registry information under
HKLM\Software\Microsoft\Cryptography\OID\EncodingType 0\ (see for entries with GUID "603BCC1F-4B59-4E08-B724-D2C6297EF351”)
5. Add Windows PowerShell 1.0 shortcut sub-directory to the directory pointed to by CSIDL_COMMON_PROGRAMS (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/reference/enums/csidl.asp)
6. GAC+Ngen PowerShell managed binaries.
Ie., System.Management.Automation.dll, System.Management.Automation.resources.dll,
After the installation powershell binaries will be queued with priority 3 in the ngen queue. To ngen them right away use the following command:
%windir%\microsoft.net\framework\v2.0.50727\ngen.exe executeQueuedItems 3
[Note: This will execute all the items with priority 3.]
7. Add powershell application base path to the PATH environment variable
8. Add .psc1 to PATHEXT variable
1. PowerShell uninstaller is available under Control Panel->Add / Remove Programs. One has to select “Show Updates” checkbox to see the powershell entry. This is because PowerShell is an Optional Windows Component and is release as an Optional Windows Software Update.
2. Uninstallation will fail if the following is true:
(a) CLR is not installed. We check for CLR existence during uninstallation as we have to ungac/ngen uninstall powershell related managed binaries. CLR uninstallation will not clean GAC which might result in servicing related issues.
3. Ngen uninstall PowerShell related managed binaries
4. Gac uninstall PowerShell related managed binaries
5. Remove powershell.exe path from PATH environment variable
6. Remove .psc1 from PATHEXT environment variable.
7. Uninstall registry keys added by installer
8. Uninstall files from %windir%\system32\WindowsPowerShell\v1.0
9. Remove Shortcut
10. Uninstaller cleans files, so if any product file is in use at the time of uninstallation a user may be prompted to restart. The restart operation can be delayed.
The installer / uninstaller support logging with option /log:<fullpath>. The log file will have information about files (un)installed, gac/ngen instructions etc.
On a 64-bit machine, Powershell installer will create both 64 bit environment and 32 bit environment i.e, one can use PowerShell engine services both from a 64-bit app and 32-bit app.
On a 64-bit machine the directory %windir%\system32\windowspowershell\v1.0 belongs to 64 bit powershell and %windir%\syswow64\WindowsPowerShell\v1.0 belongs to 32-bit powershell.
Similarly HKLM\Software\Microsoft\PowerShell\1 contains information related to 64-bit PowerShell and HKLM\Software\Wow6432Node\Microsoft\PowerShell\1 contains information related to 32-bit powershell.
All the files and registry keys that I explained above will be made available to the 32 bit app as well following the above logic. Ie., a 64-bit version of PowerShell.exe is under %windir%\system32\windowspowershell\v1.0 and 32-bit version is under %windir%\syswow64\WindowsPowerShell\v1.0
Note: Be careful the OS will automatically redirect calls to System32 to SysWow64 ie., from a cmd.exe(32) window if you say cd %windir%\system32\windowspowershell\ you are actually under syswow64
PowerShell managed binaries will not have these problems as PowerShell managed binaries will be installed to a global (GAC/Ngen) store and are Processor neutral.
As of Powershell 1.0 RTM, PowerShell supports 11 languages on downlevel. These are English, German, French, Japanese, Italian, Korean, Russian, Spanish, Portugal (Brazil), Chinese-Simplified, Chinese-Traditional. One can get all these language resources by installing English PowerShell first and then installing PowerShell MUI (KB926141). If you want to install only specific language see KB926140.
Related link: http://support.microsoft.com/?kbid=926140
Related link: http://support.microsoft.com/?kbid=926141
Key Take Aways for Windows XP(SP2) and Windows Server 2003(SP1) :
1. http://microsoft.com/powershell has all the information related to Powershell
2. PowerShell uninstaller is available under Control Panel->Add / Remove Programs. One has to select “Show Updates” checkbox to see the powershell entry. This is because PowerShell is an Optional Windows Component and is released as an Optional Windows Software Update.
3. Applications can programmatically detect PowerShell’s existence by using the following registry key information:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1 Install (== 1)
To detect for a particular language use:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\<langid> Install (==1)
To detect (major.minor)version of PowerShell
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine PowerShellVersion (== 1.0 for 1.0 RTM)
Windows PowerShell Development
This posting is provided "AS IS" and confers no rights or warranties.
I have a Win 2003 64-bit server, which has 32-bit and 64-bit PowerShell.
I need to run Exchange Management Shell commands from managed code - but these get redirected to the 32-bit PowerShell and an error is generated:
"No Windows PowerShell Snap-ins are available for version 1"
How do I uninstall 32-bit PowerShell, or somehow get 64-bit Exchange Management Shell to run in 64-bit PowerShell???
My managed code project is set to "Any CPU" for the target platform.
My PowerShell script needs to detect if it is running under the 64-bit or 32-bit powershell.exe host and if 64-bit, start the 32-bit powershell and run itself again.
This is so my script can access some 3rd party 32-bit only .NET libraries. Are there any PowerShell variables or functions that would enable my script to detect the "bitness" of it's host and to locate the other powershell executable using system-independent path references?
So I started out on a quest: a quest for the overview of installed SQL Server instances on my machine.
Hi I tried to uninstall PowerShell v1.0 on my XP SP3 laptop. Checked Show Updates and selected Remove for the Windows PowerShell entry under Windows XP - Software Updates. The result was that I no longer have an entry for PowerShell in Add/Remove Programs, but everything else (Program Files entry, windowspowershell folder in the %System% directory, HKLM registery keys, and presumably dlls in the GAC) are still there and I still cannot install PowerShell 2.0. I know that by now someone must have developed a script (or some tool) to clean the uninstall up -- how do I get it? :) Thanks!
The uninstaller on the disk can be accessed from C:\windows\$NtUninsallKB926139\spuninst\spuninst.exe
Call it and install V2
I have a problem after run C:\windows\$NtUninsallKB926139\spuninst\spuninst.exe
All PowerShell dlls are still in GAC(c:\windows\assembly).
I receive multiple error messages for all ddls when I try to remove them from GAC-
"Assembly 'microdoft.powershell.commands.management' could not be uninstalled because it is required by other application"
Could anybody help me?
Hope this saves people a lot of frustration and time. Reviewing other blogs requesting how to uninstall powershell it has been made abundantly clear that it can't be done cleanly. The silence we hear from the Powershell MVP's on the topic is deafening.
So if you have Server 2003 or 2008 (W2K8) 64 bit or 32 bit and looking for an uninstall process or command line to remove Powershell to update to Powershell V2 CTP3, it’s not going to happen folks. Put down your pomp pomp’s for Powershell and face the fact this command line utility was released to the public way to early and has a long bumpy road before it will be acceptable for public consumption.
I am experimenting a problem after installing PowerShell V2 CTP3 and Windows Management Framework Core. Now every time I try to open Powershell ISE, it crashes. In the event log I found the an eventID 5000, Source:.NET Runtime 2.0 Error. Description: EventType clr20r3, P1 powershell_ise.exe, P2 6.1.6949.0, P3 4943044e, P4 mscorlib, P5 188.8.131.52, P6 492b834a, P7 e37, P8 1cd, P9 system.argumentexception, P10 NIL.
I google everywhere for solution but I have not found one yet.
Any update to Nov 5th posting from Alex?
I'm having the same ISE problem!
I see this problem also after downloading WPK
I need to run MSPS reports to identify some issues in my servers. The reports use power shell. So, question is, if until I use MSPS reports, is power shell simply there (standing by to be invoked?)
Once I use MSPS reports, will there be any performance issue to the server?