Forum Discussion
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
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
- JeremyTBradshawIron Contributor
Removed / no longer relevant.
- JeremyTBradshawIron 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.
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.