Today is XXI century and time of x64 systems. But not all of products ready to this. As example – System Center 2012 Orchestrator. If someone miss last few month and didn’t know that I’m talking about then it will be surprise: all process inside System Center 2012 Orchestrator running as x86 process. And this is can be really the problem because registry and file paths for x64 and x86 are different.
So if we talk about PowerShell inside Orchestrator then before past your script to Orchestrator you must test it with “PowerShell (x86)” shell.
Fortunately, most of the .NET assemblies compiled with “Any CPU” flag. That means what they can run on x86 or x64 systems. SMLets Beta 4 is not a conclusion. But few “underwater riffs” are still exists.
First of all you must install SMLets on each runbook server and configure SCSM default server name. How to do that I’ve already describe early. That article was wrote for SMLets Beta 3 but can be used for Beta 4 too. The only different is way to SMLets module: it was changed from C:\Windows\System32\WindowsPowerShell\v1.0\Modules\SMLets to C:\Program Files\Common Files\SMLets\
Second part is running SMLets under x86 shell. Note to few moments:
- System directory for x64 and x86 are different. %windir%\System32 for x86 is virtual directory and mapped to %windir%\SysWOW64 folder. That means what if you running x86 shell and execute
then you will see the file and directory listing from %windir%\SysWOW64 physical path.
- Registry is different too. For x86 the HKLM\Software and HKCU\Software keys are virtual keys and mapped to HKLM\SOFTWARE\Wow6432Node and HKCU\SOFTWARE\Wow6432Node resp.
- PowerShell Execution policy stored separately for x86 and x64 shells. That means what if you set execution policy under x64 shell you must repeat this step under x86.
Note: Next steps you must repeat on all runbook servers.
So, first of all you must run “PowerShell (x86)” shell under administrative privileges and set restriction policy:
If you thinking what now you can run any SMLets cmdlets.. then, you can try it… But if you were not careful reading the post about installation then you will fail on first step: import-module SMLets will raise exception:
Get-ItemProperty : Cannot find path ‘HKLM:\software\microsoft\System Center\2010\Service Manager\Setup’ because it does not exist.
At C:\Program Files\Common Files\SMLets\SMLets.psm1:4 char:37
+ $GLOBAL:SMDIR = (Get-ItemProperty <<<< ‘hklm:/software/microsoft/System Center/2010/Service Manager/Setup’).InstallDirectory
+ CategoryInfo : ObjectNotFound: (HKLM:\software\…e Manager\Set up:String) [Get-ItemProperty], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetIt emPropertyCommand
Resolve-Path : Cannot find path ‘C:\SDK Binaries\Microsoft.EnterpriseManagement.Core.dll’ because it does not exist.
At C:\Program Files\Common Files\SMLets\SMLets.psm1:34 char:33
+ $dllpath = (resolve-path <<<< $dll).path
+ CategoryInfo : ObjectNotFound: (C:\SDK Binaries…gement.Core.dll:String) [Resolve-Path], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.ResolvePathCommand
Exception calling “LoadFile” with “1″ argument(s): “The parameter is incorrect. (Exception from HRESULT: 0×80070057 (E_INVALIDARG))”
At C:\Program Files\Common Files\SMLets\SMLets.psm1:41 char:44
+ [reflection.assembly]::LoadFile <<<< ($dllpath)
+ CategoryInfo : NotSpecified: (:) , MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException
But stop, we’ve run SCSM module. Why exception raised against registry access??? The answer is simple. SMLets try to get path to SDK binaries from registry (note to ‘hklm:/software/microsoft/System Center/2010/Service Manager/Setup’).InstallDirectory). But as I wrote above for x86 hklm:/software will mapped to ‘hklm:/software/Wow6432Node and there is no System Center/2010/Service Manager subkey under this key. So you must ready post again and edit your SMLets.psm1 careful.