SMLET Get-SCSMObject will yield no result in .Net Script Activity

Lorenz_Benn

Hello Cireson folks,

I am getting totally mad at this issue:

My goal is it to get a specific type of "Cireson.AssetManagement.HardwareAsset" but only so much objects like I tell the script to do. E.g.: I want only 2 HardwareAssets but I know I have 100 of this type.

In a Powershell Environment (ISE etc.) my script works without any issue, it works from my client, from any SCSM-Server and from the actual runbook server.

But when I try to insert this script into a .Net Script activity it does not give back any results. So tried to narrow down the issue and made a singular .Net Script activity with a few SMLets commands to see if I get back any results, I connected the Script activity to "append line".

If I use for example

Get-SCSMClass -Id "c0c58e7f-7865-55cc-4600-753305b9be64"

and publish the variable containing the result, I get to see the result in my pseudo log-file. In this case:

Cireson.AssetManagement.HardwareAsset

BUT when I try to perform any Get-SCSMObject it does not yield any result. Here is the actual test script

"

$smdefaultcomputer = "SERVERNAME"

Import-module "C:\Program Files\WindowsPowerShell\Modules\SMLets\0.5.0.1\smlets.psd1" -Force

$configItems=Get-SCSMObject -Class (Get-SCSMClass -Name "System.ComputerHardware")

$test = $configItems.Count

"

$test will be published and "Append Line" will write the variable in my pseudo log file.

It is always 0

I tried several classes for Get-SCSMObject but I get no result, I also tried to include -computername in Get-SCSMobject still nothing

Also it is not a user access issue, the user running the runbooks can access everything in SCSM

I would appreciate any help

Greetings

a despairing Orchestrator user

Nicholas_Velich

The next thing to do here is to update to the latest version of SMLets (.7) here: https://github.com/SMLets/SMLets

If you're still having issues on that latest version, then I would look at how the module is being imported and confirming it is truly loading in those cmdlets. You can add an "-ErrorAction Stop" parameter/value to force the script to stop running if it fails to load the module. Pathing out to the psd1 file usually loads the module just fine, but I have seen some environments that had issues even doing that. To resolve in those cases, I had to change to the location with the psd1 files, load in the file, and then return (using Push-Location and Pop-Location can accomplish this).

Lorenz_Benn

Hello again,

the issue has been solved:

Apparently some cmdlets require a x64 bit session, which orchestrator cannot do.

Therefore you open a local PS-session in the .Net activity and the target is your own runbook server, executing the activitiy:

$Session = New-PSSession -ComputerName localhost

Invoke-Command -Session $Session{

DOSTUFF

}

Nicholas_Velich

Hello Lorenz,

Orchestrator 2012/2016 are only able to run PowerShell v2 out-of-box, and SMLets requires at least v3. The latest version of Orchestrator (2019) supports newer versions of PowerShell.

Alternatively, you can apply a registry update to allow older versions of PowerShell to run on an older version of Orchestrator. More info can be found in this blog here: https://cireson.com/blog/hitting-limits-and-breaking-through-making-orchestrator-work-for-you/

Thanks,

Nick

Lorenz_Benn

Hey Nocholas,

I performed

https://cireson.com/blog/hitting-limits-and-breaking-through-making-orchestrator-work-for-you/

restarted the Orchestrator, but still Get-SCSMObject does not bring any result.

Nicholas_Velich

Do you have any files present at the following location on your Orchestrator server?

C:\Program Files\Common Files\SMLets

Lorenz_Benn

Nope no files at this location

Nicholas_Velich

The next thing to do here is to update to the latest version of SMLets (.7) here: https://github.com/SMLets/SMLets

If you're still having issues on that latest version, then I would look at how the module is being imported and confirming it is truly loading in those cmdlets. You can add an "-ErrorAction Stop" parameter/value to force the script to stop running if it fails to load the module. Pathing out to the psd1 file usually loads the module just fine, but I have seen some environments that had issues even doing that. To resolve in those cases, I had to change to the location with the psd1 files, load in the file, and then return (using Push-Location and Pop-Location can accomplish this).

Lorenz_Benn

Hello again,

the issue has been solved:

Apparently some cmdlets require a x64 bit session, which orchestrator cannot do.

Therefore you open a local PS-session in the .Net activity and the target is your own runbook server, executing the activitiy:

$Session = New-PSSession -ComputerName localhost

Invoke-Command -Session $Session{

DOSTUFF

}