So, I’ve created a PowerShell workflow to use in Service Management Automation. The workflow uses automation variables and has a InlineScript that returns a users mailbox properties from Exchange Server 2013. Everything works great when running from the PowerShell ISE. However, when I import my runbook to SMA and try to test the runbook I receive an exception:
“The term ‘Invoke-Command’ 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.”
Can someone please explain to me why this is? My script doesn’t use the “Invoke-Command” and it works fine in the PowerShell ISE…
Yes. PowerShell 4 is installed on all Windows Azure Pack servers. We currently have four in our environment; Windows Azure Pack, Windows Azure Pack SQL, Service Management Automation, Service Management Automation Runbook Worker.
Any reason why it works in PowerShell ISE on the Service Management Automation box but not in the SMP?
Well, I’m sure there is a reason, but I don’t know what it is yet.
We need to look at the error message. It’s having a problem running Invoke-Command. You said your script doesn’t include Invoke-Command. So we can remove your script entirely as a source of the problem. The fact that your script runs fine in the ISE isn’t relevant, because your script isn’t causing the problem. Something else is.
Also, let’s set aside the ISE for a moment. The ISE is an OK development environment, but it’s a crappy test environment, because it doesn’t work the same way as the PowerShell console. The console is a lot closer to how SMA is running scripts. Closer - but not exact. I’m also a bit depressed that you’ve got the ISE running on your server :(. GUIs are for clients, not for servers. But that’s not the question, so let’s skip that!
Point being, if we’re troubleshooting, we need to be working the same way as whatever’s causing the problem. SMA isn’t running the ISE, so we shouldn’t be running the ISE to test this. The differences between the ISE and what SMA does might be a clue to the problem, so we’re going to eliminate the ISE from our testing.
So, from a CONSOLE (not ISE) on the SMA server, does your script run without error? Can you run a simple Invoke-Command from the console, and not get an error?
[ul]
Running the workflow from the console works without throwing an exception.
Running Invoke-Command -ScriptBlock { “C:\Program Files” | Get-ChildItem } executes without error.
[/ul]
Well, so the only other thing I can think of is that SMA is using, or connecting to, some kind of restricted runspace or endpoint that doesn’t include the Invoke-Command cmdlet. I’m not sure why that would be the case, but I don’t know a ton about SMA. I’m gonna ping a couple people, so hang tight.
It might have something to so with how your are connecting to Exchange – take a look at this article and how he accomplished the connection by creating a PSSession first and then $ussing:Credential with the inline script. I don;t have an Exchange server at the moment to test against, but I found two articles that needed to use PSSession outside of the inline script first. I’ll see if I can spin one up and try it.
Well, I’m not sure Invoke-Command is running IN your workflow. You didn’t run it, after all. Invoke-Command is likely something SMA is trying to do SEPARATELY on its own. That’s why Jason’s asking to see if you can see how it’s connecting. It may be connecting to a remote endpoint that’s restricted, and doesn’t have Invoke-Command enabled. Not something in YOUR SCRIPT, but something the product may be doing on its own.
This seems overly complicated for connecting to other Microsoft products. I thought I would have a bit more flexibility using SMA as opposed to Orchestrator but it looks to be just as complicated.
Anyway, I will attempt the method of creating two sessions as described in the links provided.
SMA is indeed complex, as is workflow. But what they DO is also pretty complex, and the products have to respect a lot of security details - and security always adds complexity.
I understand the complexity, it’s just extremely fusturating to get the workflow working fine in the console or ISE and have a completely unexpected result in SMA. It make’s it very hard to troubleshoot and work with SMA runbooks as a result.
I was able to get this working by using the following:
Outstanding! this is an excellent contribution to the community - thanks for figuring it out. I understand your concern about complexity, Exchange, like other products, each have unique security rules and connection processes. But now you have the magic, so enjoy!