Forum Discussion

JeremyTBradshaw's avatar
JeremyTBradshaw
Iron Contributor
Feb 10, 2019
Solved

Exchange Online PowerShell - Invoke-Command with Select-Object inside scriptblock

Update: I'm all good now:).  Had to up-to-snuff-ize my PowerShell remoting understanding.

 

Hello,

 

I'm trying to get help with something.  I've read this:Running PowerShell cmdlets for large numbers of users in Office 365 ...

Some things to note:

  • the comments are closed there...
  • (I believe <--: no longer:)) the article demonstrates impossible actions.

Very simply: The Select-Object cmdlet is not allowed to be used inside your Invoke-Command script block when you're connected to Exchange Online.  Only exported commands from the temporary module are allowed.  So that entire article and the StartRobustCloudCommand script completely miss the "Data Return" issue that that post is supposedly addressing. (...or:)

 

Am I missing something? (<--; Yup, I typed 'select', not 'Select-Object'.)  Here's a simple example:

 

>Invoke-Command -Session (Get-PSSession) -ScriptBlock {Get-MailboxPermission gray |select Identity}
The term 'select' 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.
+ CategoryInfo : ObjectNotFound: (select:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
+ PSComputerName : outlook.office365.com

 

  • VasilMichev's avatar
    VasilMichev
    Feb 10, 2019

    Few points. First, Select-Object and select are two different things, because of the NoLanguage mode, as in - no aliases are allowed either. So you need to write it "properly":

     

    # Invoke-Command -Session (Get-PSSession -id 19) { Get-Mailbox vasil | select PrimarySmtpAddress }
    The term 'select' 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.
        + CategoryInfo          : ObjectNotFound: (select:String) [], CommandNotFoundException
        + FullyQualifiedErrorId : CommandNotFoundException
        + PSComputerName        : outlook.office365.com
    
    # Invoke-Command -Session (Get-PSSession -id 19) { Get-Mailbox vasil | Select-Object PrimarySmtpAddress }
    
    PrimarySmtpAddress PSComputerName        RunspaceId
    ------------------ --------------        ----------
    vasil@michev.info  outlook.office365.com 58472f81-7f34-4e40-8ea7-486a0be474e7

    Next, Get-MailboxPermission in ExO returns the UPN of the user, which is "unique enough" and you can get the GUID by querying based on the UPN if needed. I'd agree the full object would be better. It does return the SID though:

    # Invoke-Command -Session (Get-PSSession -id 19) { Get-MailboxPermission sharednew -User vasil | Select-Object -ExpandProperty User } -HideComputerName
    
    
    RunspaceId                  : 58472f81-7f34-4e40-8ea7-486a0be474e7
    SecurityIdentifier          : S-1-5-21-3675944716-2045640655-299186705-3762784
    ReturnUrlTokenEncodedString : False
    RawIdentity                 : vasil@michev.info

    You can apply the same method to get the ObjectGUID for the Identity value.

     

    The mailbox folder permission entries returning a full ADRecipient object is something I probed the PG few years back, never got a reply whether it's intentional of bug. Most of the time you can get enough properties via Invoke-Command though.

8 Replies

    • JeremyTBradshaw's avatar
      JeremyTBradshaw
      Iron Contributor

      Last point.  I'm not sure why but objects returned from Get-MailboxFolderPermission are different.  The User property is more than just a string

      ( I think I can guess why on this one now: it might be because there are usually very many folder permissions, so exposing .ADRecipient is a smart move to avert further lookups.) 

       

      Get-MailboxFolderPermission <User>:\<Folder> | select @{n='TrusteeExchangeGuid';e={$_.User.ADRecipient.ExchangeGuid}}

      Removed comment - no longer relevant.

      • VasilMichev's avatar
        VasilMichev
        MVP

        Few points. First, Select-Object and select are two different things, because of the NoLanguage mode, as in - no aliases are allowed either. So you need to write it "properly":

         

        # Invoke-Command -Session (Get-PSSession -id 19) { Get-Mailbox vasil | select PrimarySmtpAddress }
        The term 'select' 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.
            + CategoryInfo          : ObjectNotFound: (select:String) [], CommandNotFoundException
            + FullyQualifiedErrorId : CommandNotFoundException
            + PSComputerName        : outlook.office365.com
        
        # Invoke-Command -Session (Get-PSSession -id 19) { Get-Mailbox vasil | Select-Object PrimarySmtpAddress }
        
        PrimarySmtpAddress PSComputerName        RunspaceId
        ------------------ --------------        ----------
        vasil@michev.info  outlook.office365.com 58472f81-7f34-4e40-8ea7-486a0be474e7

        Next, Get-MailboxPermission in ExO returns the UPN of the user, which is "unique enough" and you can get the GUID by querying based on the UPN if needed. I'd agree the full object would be better. It does return the SID though:

        # Invoke-Command -Session (Get-PSSession -id 19) { Get-MailboxPermission sharednew -User vasil | Select-Object -ExpandProperty User } -HideComputerName
        
        
        RunspaceId                  : 58472f81-7f34-4e40-8ea7-486a0be474e7
        SecurityIdentifier          : S-1-5-21-3675944716-2045640655-299186705-3762784
        ReturnUrlTokenEncodedString : False
        RawIdentity                 : vasil@michev.info

        You can apply the same method to get the ObjectGUID for the Identity value.

         

        The mailbox folder permission entries returning a full ADRecipient object is something I probed the PG few years back, never got a reply whether it's intentional of bug. Most of the time you can get enough properties via Invoke-Command though.

Resources