Issue using ExchangeOnlineManagement v2.0.4 module to connect to Exchange Online remote powershell (EXO) and Exchange On-Prem remote powershell (EXOP) in same powershell window

Question

I was directed here when I asked this question in the Community.

I am having an issue when connecting to EXO powershell and EXOP powershell in the same powershell window. I can connect to both ok and the cmdlets work ok initially. The issue appears when Modern Authentication creates a new session for implicit remoting for EXO or if I connect to EXOP first and then connect to EXO.

"Creating a new Remote PowerShell session using Modern Authentication for implicit remoting of "Get-Mailbox" command ..."

This causes an issue with the EXOP session as any cmdlets I try and run after this generates similar errors to the following.

"Exception calling "GetSteppablePipeline" with "1" argument(s): "Cannot bind argument to parameter 'TokenExpiryTime' because it is null."

I emailed exocmdletpreview {at} service {fullstop} microsoft {fullstop} com on 16/06/2021 and as yet I have received no reply therefore I am asking the question here to see if anyone else has had this issue and been able to resolve or has any suggestions as to how to resolve.

Answer 1

Hi,
Why do you want to open them in same window?
I tested same situation in my lab and got another warning:

WARNING: Proxy creation has been skipped for the following command:  

<lots of commands>

, because it would shadow an existing local command.  
Use the AllowClobber parameter if you want to shadow existing local commands.  

So even you can go through the error you mentioned, still can't use those commands in same window.
Would you like to install Exchange management tools?

---

If an Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Thanks for your reply.

We have a few scripts to create new mailboxes (new-remotemailbox) and convert mailboxes (set-remotemailbox) in cloud but as we have hybrid (Exchange 2013) environment we use on-premise commands. The same scripts need to check/modify exchange online mailboxes using exchange online commands. This used to work ok when connecting to Exchange Online using basic authentication but using the new Exchange module behaviour has changed. The following code snippets is what we used for connecting to Exchange Online and Exchange On-Premise and never had problem.

$WorkingCred  = Get-Credential
$PSOptions    = New-PSSessionOption -ProxyAccessType NoProxyServer -OpenTimeout 600000 -OperationTimeout 600000 -IdleTimeout 600000
$EXOLSession  = New-PSSession -Name "EXOL" `
                              -ConfigurationName "Microsoft.Exchange" `
                              -ConnectionUri "https://outlook.office365.com/powershell-liveid/" `
                              -Credential $WorkingCred `
                              -Authentication "Basic" `
                              -AllowRedirection `
                              -SessionOption $PSOptions

Import-Module ( Import-PSSession $EXOLSession -AllowClobber -DisableNameChecking ) -Global -DisableNameChecking -Prefix "EXOL"

$WorkingCred = Get-Credential
$EXOPSession = New-PSSession -Name "EXOP" `
                             -ConfigurationName "Microsoft.Exchange" `
                             -ConnectionUri "http://InternalURL/powershell" `
                             -Credential $WorkingCred `
                             -Authentication "Kerberos"
Import-Module ( Import-PSSession $EXOPSession -AllowClobber -DisableNameChecking ) -Global -DisableNameChecking -Prefix "EXOP"

Now when trying to use more secure connection to connect to Exchange Online Powershell using ExchangeOnlineManagement module. The code used is as follows.

$PSOptions = New-PSSessionOption -ProxyAccessType NoProxyServer -OpenTimeout 600000 -OperationTimeout 600000 -IdleTimeout 600000
$EXOSession = Connect-ExchangeOnline -PSSessionOption $PSOptions -ShowProgress:$true -ShowBanner:$false

Using prefixed commands allows for commands in both environments to be used in the same session. There is just this introduction of the 'TokenExpiryTime' error after Modern Authentication creates a new session for implicit remoting or if connecting to Exchange Online powershell session after connecting to Exchange On-Premise powershell session.

There is no need to install the Exchange Management Tools as should not need it

Answer 3

This is a problem in the Exchange Online module:

Connect-ExchangeOnline -Credential $livecred -ShowBanner:$false
$SessionLocal = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $ExchangeUri -Authentication Kerberos
Import-PSSession $SessionLocal -Prefix ONP -CommandName New-RemoteMailbox, Set-RemoteMailbox, get-remotemailbox

Get-ONPRemoteMailbox ******@mailbox.com

Name RecipientTypeDetails RemoteRecipientType

---

My Mailbox RemoteUserMailbox ProvisionMailbox

Disconnect-ExchangeOnline
Connect-ExchangeOnline -Credential $livecred -ShowBanner:$false
Get-ONPRemoteMailbox ******@mailbox.com
Exception calling "GetSteppablePipeline" with "1" argument(s): "Cannot bind argument to parameter 'TokenExpiryTime' because it is null."
At C:\Users\MyUser\AppData\Local\Temp\5\tmp_m1ye5yqe.ry4\tmp_m1ye5yqe.ry4.psm1:682 char:13

• $steppablePipeline = $scriptCmd.GetSteppablePipeline($myI ...
• ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
• CategoryInfo : NotSpecified: (:) [], ParentContainsErrorRecordException
• FullyQualifiedErrorId : CmdletInvocationException

So if I connect first to EOL and then on-premise, it works. If I first connect to on-premise and then EOL it fails.

Answer 4

Glad I found this page: Same root issue - bizarrely ExchangeOnlineManagement can't differentiate existing onprem ExchangeMgmtShell remoting PSSession from EOM's own remoting session.

Mine is in the lack of a populated session prefix - because ExchOnPrem doesn't have one (my EOM session does)...

text
*Creating a new Remote PowerShell session using Modern Authentication for implicit remoting of "Get-Mailbox" command ...
Exception calling "GetSteppablePipeline" with "1" argument(s): "Cannot validate argument on parameter 'Prefix'. The argument is null. Provide a valid value for the
argument, and then try running the command again."
At C:\Users\XXX\AppData\Local\Temp\2\tmp_y3tpoqfw.aup\tmp_y3tpoqfw.aup.psm1:19688*

• post the above the test-ActiveToken (for EOM) says token is valid
• and not surprisingly only the 9 bannered get-exo[Noun] cmdlets work.
• the "legacy" cmdlets, which require implicit remoting, die hard.

Debugs to the import-pssession call in ..\Modules\ExchangeOnlineManagement\2.0.5\netFramework\ExchangeOnlineManagement.psm1, line #159: in global:UpdateImplicitRemotingHandler():

powershell
$CurrentModule = Import-Module $PSSessionModuleInfo.Path -Global -DisableNameChecking -Prefix $script:MyModule.ModulePrefix -PassThru ;

• qry the value:
  $script:MyModule | fl pre*
  Prefix :
• and Prefix is blank

It looks like the module's choice of $script:PSSession, is mismatching, the EXOnPrem's PsSession.

I'd been doing a full disconnect & reconnect, to try to work around.
But with the tips above, I'm now going to precheck status - not sure how yet - and run a

disconnect-exoOnPrem; Disconnect-ExchangeOnline ; connect-ExchangeOnline ; connect-exOnPrem;

... as a sort of "lame" workaround.

Though, as this doesn't reflect an expired token, and is randomly generated by running legacy implicit remoted cmdlets, I'm not sure how to trap and smootly work around this baloney, other than running a disconnect/reconnect cycle prior to running any given EOM legacy cmdlet.

I may just hack the .psm1 above and coerce things back to function, as I can see it's been quite awhile with the issue open, no solution other than closing & re-instantiating all implicit remoting, and it's a pretty lame workaround to refresh all connections around all but nine common cmdlets for EXO. What a mess.

N.b. it's also somewhat disturbing that MS support straight-faced asks "why?" one would run ExchangeOnlineManagement& onprem EMS modules in the same session?

Really? That's an extremely parochial view. Most enterprises with onprem AD as object Source of Authority are going to run hybrid systems and objects. Heck, I just fixed a 'no brain' (missing mbx both ends, due to delicense & re-hire), that pretty solidly requires editing both the AD source of authority ADUser, and the hybrid ExOnPrem Remotemailbox object (remapping guid to EXO mbx guid, and setting RemoteRoutingAddress to match), at the same time you query & update the EXO mailbox & AzureADuser object...

It's frequently clear that this material isn't really designed for enterprise use... It's 100% lowest common denominator.