Hello - I'm trying to add a function to a personal modules file, in order to provide quicker access to our Office 365 Exchange Online powershell environment. The function simply creates a new remote pssession and then imports it. The commands work perfectly when entered manually, and although they appear to work when called from the function, a warning about unapproved verbs effectively blocks access to all of the remote Exchange commands.

function Start-O365Exchange {
 $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential (Get-Credential) -Authentication Basic -AllowRedirection
 Import-PSSession $Session
}

Any advice or pointers? I'm sure this type of thing will come up again, so I'd like to learn the right way to do it. Thanks!

Hi,

Based on my research, when the Import-PSSession command runs, a warning appears that states some of the imported commands use unapproved verbs. This is a normal warning for the Exchange Server commands, and can be safely ignored.

More details, please refer to the below article:

Learn How to Use PowerShell to Run Exchange Commands Remotely

http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/23/learn-how-to-use-powershell-to-run-exchange-server-commands-remotely.aspx

In addition, we may use invoke-command -session $session -scriptblock {... }, more details:

http://blogs.technet.com/b/heyscriptingguy/archive/2012/07/26/an-introduction-to-powershell-remoting-part-four-sessions-and-implicit-remoting.aspx

http://stackoverflow.com/questions/14441800/how-to-import-custom-powershell-module-into-the-remote-session

Regards,

Yan Li

TechNet Subscriber Support

If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here.

Thanks, but in this case, "safely ignore" will mean that none of the Exchange commands will be available, which defeats the purpose of the connection. Attempts to use any Exchange commands results in the usual (for example), "the term 'get-mailbox' is not recognized as the name of a cmdlet" error, same as if I typed an Exchange command in a powershell session without first loading the Exchange snap-in. A "get-command -Module [tmp_module_name]" returns nothing, indicating that all the remote commands are unavailable.

I'll keep playing around with it, but I was hoping that I just missed something obvious.

Thanks for the links, too. I appreciate it.

Mike

Hi,

i found several links for you, please refer to them.

Import-Module

http://technet.microsoft.com/en-us/library/hh849725.aspx

Get-Verb

http://technet.microsoft.com/en-us/library/hh852690.aspx

Regards,

Mike

Hi,

Any update?

Regards,

Mike

Thanks, truly, but that's not a solution. I admit to being new to this Office 365 and Exchange Online, so maybe I'm just not communicating adequately. Maybe remoting to Exchange Online has different requirements. I'll keep digging.

This is neither an Office 365 or Exchange Online problem and isn't really a problem at all. When you create the remote session and then import it, you get a temporary module that contains all of the relevant Exchange cmdlets. you can view these cmdlets with 'Get-Command -Module tmp*'.

Look for the cmdlet 'Release-QuarantineMessage'. Comparing this to the output of 'Get-Verb' will reveal that 'Release' is not an approved verb for a Powershell cmdlet! I don't know how this one slipped past MS but it's no big deal as the approved verbs are there as a best practice and this will not prevent anything from working properly.

Maybe I'm not being clear. It's not just the warning message. In fact, I don't even care about the warning message. The bottom line is that the Exchange commands are not available. None of them. Something as simple as Get-Mailbox is not recognized. Here's a brief view of what I just ran:

WARNING: Your connection has been redirected to the following URI:
"https://pod51042psh.outlook.com/powershell-liveid?PSVersion=3.0 "
WARNING: The names of some imported commands from the module 'tmp_zmuotbvy.gyp' include unapproved verbs that might
make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the
Verbose parameter. For a list of approved verbs, type Get-Verb.

ModuleType Name                                ExportedCommands
---------- ----                                ----------------
Script     tmp_zmuotbvy.gyp                    {Add-AvailabilityAddressSpace, Add-DistributionGroupMember, Add-Mailb...

PS D:\> get-mailbox
get-mailbox : The term 'get-mailbox' 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.
At line:1 char:1
+ get-mailbox
+ ~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (get-mailbox:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

This type of response is the same for all the Exchange commands. In fact, if I run "Get-Command -Module tmp_zmuotbvy.gyp", it returns nothing. No commands. All of them are blocked.

I use a function very similar to yours and while I do receive the error you have mentioned I have not had an issue actually importing the session. 

You could try adding the -disablenamechecking switch parameter to the line 'Import-PSSession $Session'.

Also, can you verify the basic stuff like are you an admin in the O365 portal? Are you running powershell elevated? What is the execution policy? Are you using any options like 'Set-StrictMode' in your profile?

Thanks, Matt, but that didn't work either. I am a global admin in O365, and since the session works perfectly if I connect and import the module manually, I don't believe it's got anything to do with execution policy or elevation. :-(

I have it working now, but not exactly as I had intended. Maybe I was just over-complicating things. In my local powershell profile file (Microsoft.Powershell_profile.ps1), I have just two lines:

. \\fileserver\users\mike\mike.ps1
Import-Module MikesTools

The first line points to a script containing functions that I can access from any location on the network - things like setting my psconsole settings, importing the activedirectory module, sets an alias or two, and starts a transcript, then clears the screen.

The second line imports a custom module containing functions specific to this machine, my primary working environment. It is in this module that I placed a custom function named Connect-Office365, in which I had the commands to create and import the PSSession to Exchange Online. For the record, this method does not seem to work. From all appearances, the remote session is created and imported, but at the very end, I get the warning about unapproved verbs, and then none of the Exchange Online commands are available.

This morning, I moved my Connect-Office365 function from the MikesTools module into my local profile, and now it seems to work properly, with all of the Exchange Online commands now available.

I'm a bit disappointed. I would much prefer to keep all of my custom functions in the MikesTools module, but I guess I can live with this. The goal was to not have to enter the commands manually, and this accomplishes that goal.

Thanks to everyone for their help and advice. I appreciate it very much.

Mike

Mike,

I think I know the reason for this as I have reproduced it for myself. I have always used a dot-sourced function library to import functions into my environment but to test this I changed my O365 function library to a module and imported it. Guess what? I also did not receive the temporary module commands. It appears to be a scoping issue with the implicit remoting in the MSOL module. My workaround is to add Export-PSSession like this:

$params =   @{
    ConfigurationName = 'microsoft.exchange'
    ConnectionUri = 'https://ps.outlook.com/powershell'
    Credential = $Credential
    Authentication = 'Basic' 
    AllowRedirection = $True
                    }

$ExchSession = New-PSSession @params

Export-PSSession -Session $ExchSession -OutputModule "$env:TEMP\ExchModule" -Force | Out-Null

Import-PSSession -session $ExchSession

This exports the temporary module to your temp folder so its available for use. Seems to be working so far.

You should be able to include the -DisableNameChecking on the Import-PSSession command.  This should suppress the warning.

if you are concerned about a redirect warning, you can use the following commands to establish the connection:

# Build credential
$msoCreds = Get-Credential;

# Build a session
$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri 'https://ps.outlook.com/powershell/' -Credential $msoCreds -Authentication Basic -AllowRedirection -WarningAction SilentlyContinue;

# Import session
Import-PSSession $session -DisableNameChecking;

This will still produce a table that lists the result of the import which I believe could be suppressed by piping through Out-Null

Mike,

I think I know the reason for this as I have reproduced it for myself. I have always used a dot-sourced function library to import functions into my environment but to test this I changed my O365 function library to a module and imported it. Guess what? I also did not receive the temporary module commands. It appears to be a scoping issue with the implicit remoting in the MSOL module. My workaround is to add Export-PSSession like this:

$params =   @{
    ConfigurationName = 'microsoft.exchange'
    ConnectionUri = 'https://ps.outlook.com/powershell'
    Credential = $Credential
    Authentication = 'Basic' 
    AllowRedirection = $True
                    }

$ExchSession = New-PSSession @params

Export-PSSession -Session $ExchSession -OutputModule "$env:TEMP\ExchModule" -Force | Out-Null

Import-PSSession -session $ExchSession

This exports the temporary module to your temp folder so its available for use. Seems to be working so far.

• Proposed as answer by Matt McNabb 23 hours 1 minutes ago

Hi,

Your question falls into the paid support category which requires a more in-depth level of support.  Please visit the below link to see the various paid support options that are available to better meet your needs. http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone

Regards,

Mike