December 1, 2010 at 6:59 am
Thanks a BUNCH.
April 18, 2011 at 6:23 am
Sorry for digging up an old topic, but this is the same issue we had with our new Win2008 R2 / SQL 2008 cluster.
I had SP1 slipstreamed media so I ran into this error. Installing SP2 did not fix the issue so we opened a MS Support ticket to check if the SP2 slipstreamed install would fix this.
They confirmed the issue is NOT fixed in SP2, nor does it seem it will be fixed at all .. 🙁
And it gets even worse. When playing around with the workarounds, I found this thread and tried the first suggestion from Post 2 (edit settings) for Inst1 (2node, 3Inst cluster), and that worked. But would break again after a Move instance..
As there was still the option to break the SQL Cluster and reinstall Node1, we opted to do that, followed by Microsoft's own suggestion for the msdb.dbo.sp_verify_subsystems 1 as mentioned in Post 7 (this on Inst2 and 3, as Inst1 had the corrected path already).
This broke the job AGAIN, this time with a 'can not connect' error. Now the error was in the job itself, not in the file location.
This is described in port 5 of this thread, with the command called for the 3rd step of this job.:
SQLSERVER:\SQLPolicy\SQLSERVERINSTANCE\DEFAULT
This was changed to NodeName instead of VirtualserverName ..
So after editing this the job worked again...
So hopefully if some of you have this error, this will clarify a bit more how to fix it once and for all.
Br,
Adriaan
April 18, 2011 at 7:26 am
Wow, I can't believe they didn't fix it in SP2 like they said they would. Oh wait it's MS, so maybe I can. 😉 The worst thing is that I've sent several messages telling them to change their documentation so that others wouldn't fall into this same trap. Below is the email thread between me and MS support. I removed specific names from the emails, but I left the case number in it in case anyone want to reference it in their support calls. Read from the bottom up:
=====================================
From: (me)
Sent: Tuesday, October 19, 2010 10:57 AM
To: (MS Support)
Cc: 'MSSolve Case Email'
Subject: RE: MS Case Closure: 110031274600548:Shared tools did not end up in the same directory location. It causes the power shell subsystem to fail when try to run jobs
This is still not done. Everyone who choose a non-default location for the shared tools will have this problem.
From: (MS Support)
Sent: Monday, July 26, 2010 4:19 PM
To: (me)
Cc: MSSolve Case Email
Subject: RE: [REG:110031274600548] pro\SQL Svr Standard 2008 EN\Shared tools did not end up in the same directory location. It causes the power shell subsystem to fail when try to run jobs
Hi
I had forwarded this request to my seniors for changing the documentation after closing the case itself.I am not sure why it was not done.
I will check with my Technical lead again who interacts with the documentation team and will let you know on the progress.
Thanks again for the information and my apologies for the delay.
Have a nice day!
Regards
(MS Support)
From: (me)
Sent: Tuesday, April 27, 2010 9:48 AM
To: (MS Support)
Cc: 'MSSolve Case Email'
Subject: RE: MS Case Closure: 110031274600548:Shared tools did not end up in the same directory location. It causes the power shell subsystem to fail when try to run jobs
Importance: High
It has been over a month now and your documentation has still not been updated. I was told that this would be done. Many people are having this problem with 2008 clusters that they have build, and now the only good fix is to break their clusters and rebuild them? This is really poor service. It can all be avoided by a single warning in your documentation!
From: (me)
Sent: Monday, March 15, 2010 10:13 AM
To: (MS Support)
Cc: MSSolve Case Email
Subject: RE: MS Case Closure: 110031274600548:Shared tools did not end up in the same directory location. It causes the power shell subsystem to fail when try to run jobs
Importance: High
On the phone you told me that you would get the cluster install documentation updated to warn people about putting the shared components in a non-default directory. I looked at the instructions online and that warning is not there yet. Please get the instructions updated! Anyone who installs to a non-default location will have the same problem I did.
http://msdn.microsoft.com/en-us/library/ms179530(v=SQL.100).aspx <-- Step 9
From: (MS Support)
Sent: Friday, March 12, 2010 7:22 PM
To: (me)
Cc: MSSolve Case Email
Subject: MS Case Closure: 110031274600548:Shared tools did not end up in the same directory location. It causes the power shell subsystem to fail when try to run jobs
Importance: High
Hi
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.
--Mr. SQL Guy
April 18, 2011 at 7:36 am
Since MS didn't seem to fix it I feel more comfortable with the approach I took. Mr SQL guy was a big help with it too and I'm completely comfortable with it.
It was a LOT easier then ripping out SQL and reinstalling and temporarily losing fault tolerance in our production environment.
April 18, 2011 at 7:55 am
I added a new "community content" note to the bottom of the documentation page here: http://msdn.microsoft.com/en-us/library/ms179530(v=SQL.100)#5 I also sent another email message to MS Support. Has anyone confirmed this to be fixed in 2008 R2, or is the same problem there?
--Mr. SQL Guy
June 4, 2014 at 7:16 am
In my case, a file named c:\program existed. When renamed, the step 3 "Erase Phantom System Health Records." worked ok
December 1, 2015 at 1:01 am
Thanks a lot...
my problem was solved .. step by step details are good.
Ty ..
January 12, 2016 at 12:01 pm
I had this problem on a SQL Server 2012 stand alone.
I fixed it by giving the account that runs the agent service permissions to the folder E:\Program Files (x86)
I restarted the agent service and it worked
Jeff
July 11, 2017 at 3:34 am
Govind-326906 - Wednesday, August 19, 2009 3:47 AMcheck this... Procedure to trouble shoot the job ‘syspolicy_purge_history’ on SQL serverSome times Job--syspolicy_purge_history will fail with the below errorMessageUnable to start execution of step 3 (reason: The PowerShell subsystem failed to load [see the SQLAGENT.OUT file for details]; The job has been suspended). The step failed.Cause of the failure : This is due to invalid location of SQLPS.exe fileTo trouble shoot the issue please follow the below steps.1.by using the below script check the location of SQLPS.exe file .SELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'2.Go to the server and check whether the file ‘SQLPS.exe’ is located in the path as per step1.3.In this case normally the two paths will be different.4.Enable updates using the below scriptUse msdbgosp_configure 'allow updates', 1 RECONFIGURE WITH OVERRIDE 5. Update the correct path/* Update to correct path Here “E:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe†is given as path. Change it according to the location of SQLPS.exe file*/UPDATE msdb.dbo.syssubsystems SET agent_exe='E:\Server_apps\x86\MSSQL\100\Tools\Binn\SQLPS.exe' WHERE start_entry_point ='PowerShellStart'Execute the above script after necessary modification( if required) in msdb database. 6. Disable updates using the below script/* Dis-allow updates to system tables */ sp_configure 'allow updates', 0 RECONFIGURE WITH OVERRIDE 7. Confirm that SQLPS.exe file path has changed by running the below script once againSELECT * FROM msdb.dbo.syssubsystems WHERE start_entry_point ='PowerShellStart'8. Restart the respective SQL agent ( if it is clustered then restart it from the cluadmin )9. Re run the job.
Thanks. issue resolved.
August 1, 2017 at 9:20 pm
Jon.Morisi - Tuesday, August 18, 2009 9:37 AMAnyone seen this error logged on a SQL 2008 Cluster? "syspolicy_purge_history" "PowerShell subsystem failed to load"Message The job failed. The Job was invoked by Schedule 8 (syspolicy_purge_history_schedule). The last step to run was step 3 (Erase Phantom System Health Records.).Job status is listed as suspended in Activity Monitor This looked like it could possibly be related http://support.microsoft.com/kb/955726
This is sporadic ,try to create new job copy. most of the times powershell will fix it automatically . Check your GPUPDATE if any changes.
@JayMunnangi
Viewing 10 posts - 46 through 54 (of 54 total)
You must be logged in to reply to this topic. Login to reply