Workflow with powershell failing in one environment but not the other

Dean_Mrazek

Hi

I have a workflow that uses a powershell script which runs fine in two of my environments but not another.

The powershell fails with the error "Script encountered an error: The term 'Get-SCSMRelatedObject' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again." but when I run Get-SCSMRelatedObject outside of the workflow on the same server the workflow is failing on, the command runs fine.

When I run Get-Module -ListAvailable -Name smlets, the results on two different servers are the same.

Geoff_Ross

Hi Dean,

It could be that the PSModulePath (the folders that PowerShell will look in when trying to load modules) is different for the two servers. Its part of the local user profile.

You could look into that or you could specify the path by full file path. eg

Import-Module "C:\Program Files\Common Files\SMLets\SMLets.psd1" -Force -ErrorAction Stop

Geoff

Dean_Mrazek

Hi Geoff

I checked C:\Users\workflow_user\Documents\ folder and couldn't find a WindowsPowerShell folder there, I also added "Import-Module "C:\Program Files\Common Files\SMLets\SMLets.psd1" -Force -ErrorAction Stop" to the powershell and still get the same error.

Also, just wondering, currently the powershell is in the management pack itself and whenever I want to add any logging to the workflow or make any changes I have to import the management pack again. Can I instead have a reference to a powershell script file outside of the management pack?

Geoff_Ross

Dean,

You need to check the location of where the module is on your servers.

"C:\Program Files\Common Files\SMLets\SMLets.psd1" was an example.

And yes, referencing an external script file is a good way to work around that. You could even download one from GitHub or something and execute.

Geoff

Dean_Mrazek

Hi Geoff

I ran "Get-Module -Name SMLets -ListAvailable | Select-Object -ExpandProperty Path" and got the below results. Is there another way to find where the modules are installed to?

C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\SMLets\SMLets.psd1
C:\Program Files\Common Files\SMLets\SMLets.psd1

Geoff_Ross

Dean,

Check those locations, do you see the psd1 file?

Geoff

Dean_Mrazek

Hi Geoff

Both of those file paths have the psd1 file there.

Dean_Mrazek

Hi

This is really weird. I added the two below lines to the workflow script and now the workflow runs fine even if I remove those lines after. The server shuts down overnight so I'll try again tomorrow and see what happens.

Get-Module -ListAvailable | Where-Object { $_.Name -eq 'SMLets' }

Get-Command -Module SMLets | Where-Object { $_.Name -like '*SCSMRelatedObject*' }

Simon_Zeinhofer

@Dean_Mrazek I had the same issue on our runbook servers when we set them up as a new some years ago.
Maybe this helps:

https://community.cireson.com/discussion/6288/loading-smlets-fails