Subsystem 'PowerShell' could not be loaded - by bkshawSQL

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 491109 Comments
Status Closed Workarounds
Type Bug Repros 5
Opened 9/21/2009 10:42:59 AM
Access Restriction Public


When installing SQL 2008 64 bit in an Active-Active 2 node cluster on Windows 2008, SQL Agent starts up with the following error on one node:

[125] Subsystem 'PowerShell' could not be loaded (reason: The system cannot find the path specified)

The follow query:
select * from msdb.dbo.syssubsystems where subsystem = 'Powershell'

returns the agent_exe as "C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\SQLPS.exe" when run from either instance.

The tools directory exists on one node, but not on the other node.  This has happened to me on 2 different clusters.  It make powershell unusable in SQL Agent for either instance when they are running on the "bad" node.
Sign in to post a comment.
Posted by LiamGav on 11/11/2011 at 2:33 AM

As this is not listed on the fixs for SP3 does this mean a fix is not included as part of SP3? Will the fix resolve new installs only?

Posted by Microsoft on 5/20/2011 at 3:32 PM
Hello just want to update you that the fix will be avialable in next major release.

Thank you
Alex Grach
Posted by Microsoft on 3/15/2011 at 5:15 AM
Hi bkshawSQL,

Thanks for the feedback! We're investigating this. You are correct in that this fix is not available in SQL Server 2008 PCU2. We will update this space once we've completed our investigations.

Deepak Ananth
SQL Server Manageability Team
Posted by Roel_P on 3/14/2011 at 7:56 AM
Since this bug is not listed as fixed in, I assume it is not fixed in SQL Server 2008 SP2? Am I correct? If so, is this bug scheduled to be fixed in a later SP or CU?
Posted by Glanzer on 3/15/2010 at 6:35 AM
Hi everyone,

If you install the SQL shared tools in a nonstandard directory on the 1st node in your cluster, when you add the 2nd node to your cluster it puts the shared tools in the DEFAULT directory not the one you specified on your first node. This means that the Powershell subsystem will only work on one of the nodes not the other. I called Microsoft support about this issue and after working with me they acknowledged that it's a bug that will be fixed in SQL Server 2008 SP2. They offered 2 workarounds. Below is Microsoft's response with the 2 workarounds (we are leaning toward option 2):


It was my pleasure to work with You during your Microsoft SQL Server issue. As per our conversation, since this is a known issue with the SQL 2008 cluster, we will go ahead and Refund this case.
Also, here are the workarounds we talked about.


Workaround:- There are two workarounds.

1. This is pretty similar to -, except the scenario is different.

Run the below commands and this will correct the subsystem paths - this will break again once SQL goes back to the other node. It’s possible that someone might consider to have a procedure do this and have the proc execute at the startup.

use msdb
delete from msdb.dbo.syssubsystemsexec
msdb.dbo.sp_verify_subsystems 1

2. Other and slightly more time consuming option is to - Remove the node [where the shared components are NOT in C:\program files] and just add it back again. Just remember you need to cleanup SQL from that node in entirety.

Note: Just FYI - This is scheduled to be fixed in SP2.

SQL Server Support Engineer

Posted by hainbloed on 3/10/2010 at 9:06 AM
I found the same error on my cluster. The "Advanced cluster preparation" is necessary and works!
Posted by Microsoft on 2/5/2010 at 6:46 AM
Hi Matt & fouadfm67,

are you able to replicate this issue when using the prepare-complete method?

Robert Hutchison
SQL Manageability PM
Posted by Randy in Marin on 11/24/2009 at 1:03 PM
I also had this problem (SP1 CU5) with addnode. I did not have the issue when using the prepare-complete method.
Posted by maleitzel on 10/22/2009 at 6:51 AM
Bkshawsql and Fouadfm67, I'm having a similar situation. I'm creating a two node cluster for SQL Server 2008 on Windows 2008. Using Integration Install or Advanced Install or command line install, Node 1 is created correctly. Our enterprise standard is to have the OS and binaries on the C: drive and shared items on the D: drive.

On Node 1 I end up with a Program Files and a Program Files (x86) folder. In the (x86) folder is the executable for PowerShell. The syssubsytem entry points to the correct folder while node 1 is ‘active’.

The install on Node 2 never creates the D:\Program Files (x86) folder. In fact, during the installation, I have no option to point the shared components install to the D: drive. It appears to ignore these entries in the .ini file during a command line install.

The syssubsystems entry for PowerShell continues to point to D: when we move resources to Node 2. Any process that requires PowerShell fails at this time because the path to PowerShell on Node 2 does not exist.

Fouadfm67 do you have a similar environment? If so, how did you successfully use the Advance Install to get this to work? No matter what steps I try or follow the Node 2 build does not work as expected.

Thanks for any help or additional information.
Posted by Fouad Faraj on 9/28/2009 at 8:24 AM
I have the same problem in one of my cluster...However, it's fine in another cluster. The only difference is the way we installed it. On the cluster that doesn't have this issue, I installed SQL server via the "Advanced cluster preparation" while the "broken" one, we ran the install via the "New SQL Server failover cluster installation".

I am curious to see if there is any workaround to fix this issue.