The term 'Invoke-Command' is not recognized as the name of a cmdlet...

Tagged: 

This topic contains 13 replies, has 3 voices, and was last updated by Profile photo of Windows LiveUser128 Windows LiveUser128 1 year, 11 months ago.

  • Author
    Posts
  • #24834
    Profile photo of Windows LiveUser128
    Windows LiveUser128
    Participant

    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...

  • #24835
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Is PowerShell v3 or later installed on the host where SMA is running?

  • #24837
    Profile photo of Windows LiveUser128
    Windows LiveUser128
    Participant

    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?

  • #24839
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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?

  • #24840
    Profile photo of Windows LiveUser128
    Windows LiveUser128
    Participant

    First, thanks for the quick reply.

    [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]

    What else should we test?


    workflow Enable-EmployeeMailbox
    {
    Param
    (
    [Parameter(Mandatory=$true)]
    [string]$UserPrincipalName
    )

    $Credentials = Get-AutomationPSCredential -Name "Hayden Hancock"

    InlineScript
    {
    Get-Mailbox -Identity $Using:UserPrincipalName

    } -PSCredential $Credentials -PSConfigurationName Microsoft.Exchange -PSConnectionUri https://pathtoexchange/powershell

    }

  • #24843
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #24844
    Profile photo of Windows LiveUser128
    Windows LiveUser128
    Participant

    Interesting. I didn't think that the Invoke-Command would even work inside a workflow.

  • #24845
    Profile photo of Jason Helmick
    Jason Helmick
    Keymaster

    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.

    http://blogs.technet.com/b/privatecloud/archive/2013/08/27/automation-service-management-automation-tip-trick-leveraging-inlinescript-and-using-variable-with-powershell-workflow.aspx
    http://blogs.technet.com/b/privatecloud/archive/2013/08/15/automation-service-management-automation-runbook-spotlight-exchange-distribution-list-creation.aspx

    Cheers

  • #24846
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #24851
    Profile photo of Windows LiveUser128
    Windows LiveUser128
    Participant

    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.

  • #24852
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #24853
    Profile photo of Windows LiveUser128
    Windows LiveUser128
    Participant

    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:

    workflow Get-MailboxTest
    {
    Param
    (
    [string]$UserPrincipalName
    )

    $Credential = Get-AutomationPSCredential -Name "Hayden Hancock"

    InlineScript
    {
    $ConnectionURI = "https://exchange/powershell"
    $Session = New-PSSession -ConnectionUri $ConnectionURI -ConfigurationName Microsoft.Exchange -Credential $Using:Credential
    Invoke-Command -Session $Session -ScriptBlock { Get-Mailbox -Identity user@domain.com }
    Remove-PSSession -Session $Session
    } -PSComputerName exchange -PSCredential $Credential

    }

    Thanks for the help guys! I wouldn't have gotten this far if it wasn't for your direction.

  • #24854
    Profile photo of Jason Helmick
    Jason Helmick
    Keymaster

    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!

  • #24855
    Profile photo of Windows LiveUser128
    Windows LiveUser128
    Participant

    Just for the record, it looks like you have to do this same method for Lync Server 2013.

You must be logged in to reply to this topic.