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
cd %windir%\System32
dir
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:
Set-ExecutionPolicy RemoteSigned
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: 0x80070057 (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.
After that you can user SMLets under x86 shell:
9 Comments
I have followed all your steps in getting this to work, now when my Orchestrator scripts run i’m getting this error.
The module to process ‘SMLets.psm1’, listed in field ‘ModuleToProcess’ of module manifest ‘C:\Windows\system32\WindowsPowerShell\v1.0\Modules\smlets\smlets.psd1’ was not processed because no valid module was found in any module directory.
Any ideas? I have done this in two enviroments and getting the same errors…
same here any ideas on Matt’s comment?
Have answered on Matt’s question. This is really bad and very hard to troubleshoot.
This can be a case if both, OOB and SMLets cmdlets are loaded in same time.
Also, I saw this time once at one of customer in workflows and it was resolved by reinstalling server only, sorry.
I have a Problem with the SMLets execution on Orchestrator. My Script runs well on x86 Powershell with the orchestrator Serviceaccount. But if the orchestrator runs the script the following error appears. A parameter cannot be found that matches parameter name ‘ProjectionName’.
$srTypeProjection = Get-SCSMTypeProjection -name System.WorkItem.ServiceRequestProjection$ -ComputerName $SCSMUmgebung
Any ideas why this error appears. i dont find a mistake.
sorry wrong line.
$SRProj = Get-SCSMTypeProjection -ProjectionName $srTypeProjection.Name -filter “title -eq $title” -computername $SCSMServer
my fault. the posted error is solved, because i used the wrong cmdlet. get-scsmobjectprojection was the right one. But now i have another problem, that i get no objects back from the get-scsmobjectprojection. if i run it in powershell without orchestrator i get all objects. Run in orchestrator the return value is $null. any ideas?
Sorry for the spam. Problem solved. The Orchestrator Serviceaccount didn´t have permissions in SCSM. But it was strange that the service account could create empty Service Request without a template.
My apologies for silence , looks like hoster block outbound email and I didn’t received notifications about comments.