Cannot index into a null array when running via Powershell.exe -Command

[deafeningquiet]

Hi, Not sure there's much that can be done here, or if I'm running into a strange PowerShell limitation / bug.

Anyways, I'm attempting to automate a bunch of processes which runs powershell via a similar command line to the following:

powershell.exe -executionpolicy unrestricted -command C:\Temp\script1.ps1

this fails with: _oktaNewCall : Cannot validate argument on parameter 'oOrg'. Cannot index into a null array.

However, if I run with the following: powershell.exe -executionpolicy unrestricted -file C:\Temp\script1.ps1 the cmdlets run as expected.

You can see both calls in the screenshot, running the same script file.

Unfortunately, due to our other 3rd party system and the way they generate the cmdline parameters for powershell, I'm stuck with using -Command and not -File.

My only thought is that -Command does not support the ScriptsToProcess in the module manifest, but I can't really be certain at this point.

By chance have any ideas on your end?

Thanks for the help. This module has been a lifesaver and allowed me to update nearly 30k app assignment logins in Okta with next to no effort. Great work.

EDIT: I should add that the script is doing something very basic and simply calling the following: (oktaGetUserbyID -oOrg prod -username "myusername").id

[mbegan]

I finally had a minute to test this today.

The only 'workaround' i could come up with was the stick the okta org definition into the primary okta.psm1 file.

basically take the content of your okta_org.ps1 and put it at the bottom of the okta.psm1. This seemed to work for me.

[rebsiot]

The API appears to be Case Sensitive on username.

Anytime this statement is used $uid = (oktaGetUserbyID -oOrg $oOrg -userName $username).id where it sends the username into the module (oktaActivateUserbyID) it will return nothing.

_OktaNewCall throws and returns an error, which is unhandled in the calling function....so the null array gets thrown.

It also returns nothing and throws the same error on at least some of the calls where the user is deactivated. So you can handle the error and spit out the username that is in error and (if you are feeling crazy) write in a proper case handler that maybe takes john.doe and makes it John.doe and John.Doe to retry 3 or 4 times before throwing the name.

After 50 calls, it then throws an SSL/TLS error (like adding users to group using a script of several statements)

I was hammering my head against a wall for weeks trying to figure this out. Someone sent me a faulty list, so i had to walk the users, 1 at a time to see who failed....bam!

I think best practices should include a string.ToLowerCase on all user imports from AD. Capitalization is causing errors in our Salesforce feeds also.

[aut0pil0t]

I finally had a minute to test this today.

The only 'workaround' i could come up with was the stick the okta org definition into the primary okta.psm1 file.

basically take the content of your okta_org.ps1 and put it at the bottom of the okta.psm1. This seemed to work for me.

The issue is still there after 4 years and this still the best solution yet - thank you! Alternatively, PowerShell 7 can be used and the issue is no more.