Invoking PowerShell inside a SharePoint 2013 timer job throws an exception

Question

I have a SP2013 timer job where I'm executing some SharePoint PowerShell commands. The same code that used to work in SharePoint 2010 will not work in SharePoint 2013 (Server 2012) - when the job is executed, the following exception occurs:

The type initializer for 'System.Management.Automation.SessionStateScope' threw an exception.

Stack trace:

at System.Management.Automation.SessionStateScope.AddSessionStateScopeDefaultVariables()
at System.Management.Automation.SessionStateScope.GetPrivateVariables()
at System.Management.Automation.SessionStateScope.SetVariable(String name, Object value, Boolean asValue, Boolean force, SessionStateInternal sessionState, CommandOrigin origin, Boolean fastPath)
at System.Management.Automation.SessionStateInternal.InitializeSessionStateInternalSpecialVariables(Boolean clearVariablesTable)
at System.Management.Automation.SessionStateInternal..ctor(SessionStateInternal parent, Boolean linkToGlobal, ExecutionContext context)
at System.Management.Automation.ExecutionContext.InitializeCommon(AutomationEngine engine, PSHost hostInterface)
at System.Management.Automation.AutomationEngine..ctor(PSHost hostInterface, RunspaceConfiguration runspaceConfiguration, InitialSessionState iss)
at System.Management.Automation.Runspaces.LocalRunspace.DoOpenHelper()
at System.Management.Automation.Runspaces.RunspaceBase.CoreOpen(Boolean syncCall)
at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync)
at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection1 input, PSDataCollection1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection1 input, PSDataCollection1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.CoreInvoke[TOutput](IEnumerable input, PSDataCollection`1 output, PSInvocationSettings settings)
at System.Management.Automation.PowerShell.Invoke(IEnumerable input, PSInvocationSettings settings)
...

The problematic part seems to be that the project references System.Management.Automation and uses PowerShell. From googling, this seems to be a SP2013-specific bug, likely an OWSTIMER bug, as indicated by this post that also offers a hack-around (unfortunately not acceptable to me): http://sppowershelltimerjob.codeplex.com/discussions/448895

1. Is this recognized as an internal SharePoint 2013 bug?
2. Can it be fixed?

Answer 1

The 'System.Management.Automation' dll issues have several sources and in your case, it's also coupled with changes in the SharePoint versions (2010/2013) and the move to 64-bit Server 2012 (presuming your SP2010 was on a 32-bit platform).

Here's a checklist of items to look into -

A). Check Execution Policy of script: Set-ExecutionPolicy -ExecutionPolicy RemoteSigned

B). Check the version and path of the following dll which should be C:\WINDOWS\SysWOW64\mscoree.dll as stated in the registry setting HKCR\CLSID{A8F03BE3-EDB7-4972-821F-AF6F8EA34884}\InprocServer32(Default) for the x64 environment

C). Recompile the cmdlet (for x64bit) - locate & check version of 'System.Management.Automation' dll ( usually in the GAC). If not in the GAC - location of the 'System.Management.Automation.dll' when the Windows SDK is installed: C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\ or within C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell3.0

Make a local copy for PowerShell and Visual Studio and the reference to it: use VS Project Reference menu and browse to the GAC: C:\windows\assembly\GAC_MSIL\System.Management.Automation and add reference for the dll and the Runspaces dll (verion currently on WS 2012 - 6.1.7601.17514) or to your local copy in the PowerShell directory.

D). Or include: Reference Include="System.Management.Automation" in your project file under the first "ItemGroup" section.

E). For local copy (from item C above) : modify profile.ps1 so it can be loaded when running PowerShell.