Home› Powershell

Workflow with powershell failing in one environment but not the other

Dean_MrazekDean_Mrazek Customer IT Monkey ✭
in Powershell

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.

Answers

  • Geoff_RossGeoff_Ross Cireson Consultant O.G.

    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_MrazekDean_Mrazek Customer IT Monkey ✭

    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_RossGeoff_Ross Cireson Consultant O.G.

    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_MrazekDean_Mrazek Customer IT Monkey ✭

    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_RossGeoff_Ross Cireson Consultant O.G.

    Dean,

    Check those locations, do you see the psd1 file?

    Geoff

  • Dean_MrazekDean_Mrazek Customer IT Monkey ✭

    Hi Geoff

    Both of those file paths have the psd1 file there.

  • Dean_MrazekDean_Mrazek Customer IT Monkey ✭

    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_ZeinhoferSimon_Zeinhofer Customer Ninja IT Monkey ✭✭✭✭
    edited October 23

    @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

Sign In or Register to comment.