Environment variable name or value is too long

Saleh_Owen

We have an notification subscription set up to send out an email every time one of our PowerShell Activities fails. For some reason every two weeks or so, we will get 20-30+ emails all at one time stating that all of the PSAs are failing with the same error:

An error was written to the Error stream!
Environment variable name or value is too long

The only thing that we have found to fix it is just restarting all 3 of the SCSM services running on our management server. Has anyone else seen this issue? Does anyone have any idea of why this is happening?

Geoff_Ross

Hi, my old tired brain couldn't remember but I knew the answer was out there so I asked my friend @joivan_hedrick who reminded me this is likely an issue with SMlets, not PowerShell activity. Are you using SMlets in your PowerShell. Each time it loads it adds its own path the the environment variable, which for a regular occurring script will eventually cause the environment variable to be too long. This is fixed in the latest SMLets https://github.com/SMLets/SMLets or you can fix in your current version manually.

Inside of the SMLETS.psm1 file, change the code to the following:

if(!$env:path.Contains(";$psscriptroot;$psscriptroot\Scripts")) {
    $env:path += ";$psscriptroot;$psscriptroot\Scripts"
}

Geoff

Geoff_Ross

Hi @Saleh_Owen

This is familiar to me but i just can't quite remember the cause. I might come to me so I'll continue to think but i'm pretty certain the issue was addresses in an update. Can you please confirm what version you are running.

Geoff

Justin_Workman

@Saleh_Owen - Is the subscription criteria just PSA moved from not failed to failed?

Saleh_Owen

Can you please confirm what version you are running.

 @Geoff_Ross - We are running PSA v. 8.1.3.2012

Is the subscription criteria just PSA moved from not failed to failed?

@Justin_Workman - Yes, the notification criteria looks for PSAs that go from not failed to failed. The problem is not the notifications though. The problem is that we start receiving a bunch of emails indicating that all of our PSAs are failing at the same time with the same error message.

Justin_Workman

@Saleh_Owen - Do you have each PSA running as its own process? 

Geoff_Ross

Hi, my old tired brain couldn't remember but I knew the answer was out there so I asked my friend @joivan_hedrick who reminded me this is likely an issue with SMlets, not PowerShell activity. Are you using SMlets in your PowerShell. Each time it loads it adds its own path the the environment variable, which for a regular occurring script will eventually cause the environment variable to be too long. This is fixed in the latest SMLets https://github.com/SMLets/SMLets or you can fix in your current version manually.

Inside of the SMLETS.psm1 file, change the code to the following:

if(!$env:path.Contains(";$psscriptroot;$psscriptroot\Scripts")) {
    $env:path += ";$psscriptroot;$psscriptroot\Scripts"
}

Geoff

Saleh_Owen

Geoff - I believe this is exactly where the problem was. Rather than updating the whole module, I just changed the $env:path line in SMLets.psm1. I have no way of confirming this fixed the problem except for not seeing any more of these errors, but I'm pretty confident this was the problem.

Thanks for the help.


-Saleh