July 10, 2017 at 7:06 pm #74629
I've been trying my hand with JEA and the JEA part seems to be going fine.
I've been able to create a JEA endpoint, and expose a ps1 file and an alias to it.
The ps1 connects to O365 using stored creds and a cmdlet prefix (i.e. get-o365mailbox), and then runs a couple commands.
Everything up to connecting to O365 works.
When I try to do a get-o365mailbox or any other command, I get the following error:
>Get-o365mailbox email@example.com Exception calling "GetSteppablePipeline" with "1" argument(s): "The expression after '&' in a pipeline element produced an object that was not valid. It must result in a command name, a script block, or a CommandInfo object."
The object exists (get-o365mailbox returns the object) and the script works as desired when I run the script on the machine or if I enter an unrestricted/regular remote session on the same system.
July 10, 2017 at 7:59 pm #74630
It looks as if it's trying to retrieve the command itself, which is represented as an object, but is in fact running the command and getting its results back. It's also possible that this is happening because it's attempting to "look up" the command, but is in a locked-down runspace that isn't allowing the command to be loaded, and so it can't get anything.
July 10, 2017 at 8:40 pm #74638
So, let's ignore "JEA" for a moment, because all that is is a toolkit for setting up constrained runspaces. Let's deal with the actual, underlying technology.
There are a lot of features of constrained runspaces that interact, sometimes in contradictory fashions. For example, you can whitelist all the scripts you want, but if the language mode of the runspace is "no language," then the scripts won't run.
Without sitting down in front of the computer where this is configured and really digging into it, it's pretty much impossible for me to tell you how to resolve it. It _sounds_ like the runspace isn't being allowed to load the command (e.g., the script). I can tell you what I'd do to try and troubleshoot it, though, which would be to back off all the restrictions possible and see if it ran. Then I'd ratchet one setting down, one level, and try it again, and keep doing that until it failed. All of that, for me, is a little easier in a straight-up modification of the endpoint, rather than trying to reset it with the JEA tools, which simply provide an abstraction on top of the actual endpoint.
You must be logged in to reply to this topic.