none
Exchange Online error: Identifier is not in a valid session state on the remote computer.

    Question

  • we are regularly seeing this error:

    New-PSSession : [outlook.office365.com] Processing data from remote server outlook.office365.com failed with the following error message: The EndpointConfiguration with the http://schemas.microsoft.com/powershell/Microsoft.Exchange identifier is not in a valid initial session state on the remote computer. Contact your Windows PowerShell administrator, or the owner or creator of the endpoint configuration. For more information, see the about_Remote_Troubleshooting Help topic.At C:\Windows\TEMP\apprity\Temp3309807311454987133.ps1:1 char:687+ $errorActionPreference = 'Stop'; $password = ConvertTo-SecureString 01000000d08c ...+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:Re moteRunspace) [New-PSSession], PSRemotingTransportException + FullyQualifiedErrorId : IncorrectProtocolVersion,PSSessionOpenFailed


    This has suddenly started occurring since last 4 days and started off as intermittent and is regular now. Can someone help on what could be the root cause?

    Saturday, August 26, 2017 5:58 AM

Answers

  • Issue reported in Admin Center, EX116717. Fix is in progress.
    • Proposed as answer by HeensIt Wednesday, August 30, 2017 7:05 AM
    • Marked as answer by Swatisrao Wednesday, August 30, 2017 6:28 PM
    Tuesday, August 29, 2017 10:52 PM

All replies

  • Anyone on this, same error over here!?
    Saturday, August 26, 2017 6:27 PM
  • Have you opened a ticket with Microsoft Online Support?  You don't have any proxy servers or the like between your network and the Internet, do you?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Saturday, August 26, 2017 11:52 PM
  • Yes, opened a ticket with MSFT Support. But yet to hear back from them.  

    Sunday, August 27, 2017 10:10 AM
  • Hi, I'm seeing this also the last few days...

    It looks like the Remove-PSSession no longer does what it needs to do

    I have several scripts that runs through all our tenants and they have been working flowlessly the last years.

    But now suddenly it fails at the second tenant, when I skip the first tenant, it run the second but then fails at the third one... (and so on...) BTW I also have to restart the PC or the PSSession still isn't removed...

    Are there any updates from MSFT yet?
    Monday, August 28, 2017 11:18 AM
  • Hi,

    Any update about this issue?

    As Ed mentions above, do you configure any proxy server between your network and internet?
    Thus, I want to double confirm whether this issue occurs on your internal network environment or external?

    As we know, we can use Windows PowerShell to connect to Exchange Online, thus we can try it with different network environment to narrow down this issue:
    1. Enter credential:
    $UserCredential = Get-Credential
    2. New session:
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
    3. Import session:
    Import-PSSession $Session
    More details, for your reference: Connect to Exchange Online PowerShell.

    Meanwhile, please ensure KB4025333 is not installed on your Windows server.
    If so, please install KB3000850 (Windows 8.1 or Windows Server 2012) to fix it.

    Regards,

    Allen Wang


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, August 28, 2017 11:36 AM
    Moderator
  • Hi Allen_WangJF,

    as mentioned.. we've been using the same scripts for the last several years.

    Nothing has change here, only that the scripts stop running ever since last week...

    As a matter of fact, we're using this part in the script

    Get-PSSession | Remove-PSSession Set-ExecutionPolicy Unrestricted $LiveCred = New-Object System.Management.Automation.PSCredential($login,$SecurePassword)

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $LiveCred -Authentication Basic -AllowRedirection Import-PSSession $Session -AllowClobber

    Connect-MsolService -Credential $LiveCred

    And I've tried this on several locations, all without proxy...

    And the FIRST connection always succeeds, when you try another PSSession (to another tenant) it fails... if you didn't wait an hour or rebooted the pc first...


    • Edited by HeensIt Monday, August 28, 2017 11:56 AM
    Monday, August 28, 2017 11:55 AM
  • Hi Allen,

    We're running the script on a Windows Server 2012 R2 Standard server with KB4025333 installed. 
    The hotfix KB3000850 is also installed.

    Our script is also switching between tenants.

    Monday, August 28, 2017 11:57 AM
  • We're running the scripts on Windows 10...
    Monday, August 28, 2017 11:59 AM
  • Hi Allen_WangJF,
    Just to let you know, for example this simple login script, runs only once to connect to a tenant, when trying to run the same script a second time to another tenant it fails...
    I truly hope MSFT get this fixed ASAP as this is a service down for us partners... We can no longer service our (and MSFT) customers as needed!!!

    $login = Read-Host -Prompt "Give an Admin users' emailaddress" 
    $SecurePassword = Read-Host -Prompt "Enter password" -AsSecureString 
    #delete existing PSSession
    Get-PSSession | Remove-PSSession 
    #create new site connection
    Set-ExecutionPolicy Unrestricted
    $LiveCred = New-Object System.Management.Automation.PSCredential($login,$SecurePassword)
    
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential 
    $LiveCred -Authentication Basic -AllowRedirection
    
    Import-PSSession $Session  -AllowClobber
    
    Connect-MsolService -Credential $LiveCred 
    

    PS I also opened a Support case at MSFT, but there is no way to open a powershell related case, as this is for all Powershell scripts and not for any specific part in the O365/azure solution. So you can't even open it on severbased support...

    Monday, August 28, 2017 12:34 PM
  • Hi all, 

    I have same problem and cannot log to different tenant from local powershell session. I'm thinking is there any way to make logon scripts to create some VNET or something else to make each session going on other network way? 

    Monday, August 28, 2017 9:08 PM
  • I’m having same issue and I opened a ticket with Microsoft too yesterday. This seems affecting tenant located in Europe. At least from what I can see on our customers.
    Tuesday, August 29, 2017 5:30 AM
  • This is happening all over the place. This is no longer an isolated incidence. It was intermittent for the last couple days back but has completely prevented us access to PowerShell to any of our customer tenants right now.

    Tuesday, August 29, 2017 7:11 AM
  • My case at MSFT is SRX617082892208238ID, maybe we can get the case somehow bundled?

    So that the engineers don't ask the same question to everybody?

    Tuesday, August 29, 2017 7:17 AM
  • We are facing the same issues with multiple instances.

    That failure generates a lot of effort and explaining, so is there ANY Workaround or fix available?

    Thx, Toni

    Tuesday, August 29, 2017 8:31 AM
  • Hi Toni,

    The only thing that works as a 'workaround' is temporarily changing the ConnectionUri in the New-PSSession CMDlet.
    I use this URIs for connecting to Exchange Online:

    • https://ps.outlook.com/powershell/
    • https://outlook.office365.com/powershell-liveid/

    After changing the URI, your script will connect to the 'new' tenant...but it fails when switching to a different tenant. It's a semi workaround ;)

    Tuesday, August 29, 2017 8:43 AM
  • Hi Robbert,

    thanks for your info. Obviously the behavior is the same even with the alternative connections and it works (mostly) fine just for the first connection. But then, the issue occurs in the same way...

    Our code was working for the last years and now we are facing that connection issue. I really hope, Microsoft will fix that soon, we don't have a workaround for Managing Exchange Online without Remote Exchange PS...

    Just to clarify, this happens when using a runspace as stated in the initial post:

    System.Management.Automation.Remoting.PSRemotingTransportException: Processing data from remote server ps.outlook.com failed with the following error message: The EndpointConfiguration with the http://schemas.microsoft.com/powershell/Microsoft.Exchange identifier is not in a valid initial session state on the remote computer. Contact your Windows PowerShell administrator, or the owner or creator of the endpoint configuration. For more information, see the about_Remote_Troubleshooting Help topic.
       at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
       at System.Management.Automation.Runspaces.Internal.RunspacePoolInternal.EndOpen(IAsyncResult asyncResult)


    • Edited by Toni PohlMVP Tuesday, August 29, 2017 11:52 AM added error msg
    Tuesday, August 29, 2017 11:20 AM
  • Any updates from anyone?  I am getting runaround and delays from O365 support on the topic, and am losing patience quickly.   Exact same behavior.
    Tuesday, August 29, 2017 6:56 PM
  • If anyone has news around this please post it here. I opened a ticket with Microsoft and waiting a feedback. This started last Friday with few tenants, now it’s impacting a lot of tenants.
    Tuesday, August 29, 2017 7:13 PM
  • Do you have any proxy servers between you and the Internet?  Are you blocking  or otherwise molesting SSL outbound?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, August 29, 2017 8:22 PM
  • In my case no, we can reproduce across multiple office locations, hosting locations, and none with any known or identified proxy or manipulation situations.
    Tuesday, August 29, 2017 8:38 PM
  • Does this help?

    https://social.technet.microsoft.com/Forums/lync/en-US/713b7fa3-23ea-40d5-8187-a66ab8a0af90/exchange-server-control-not-transfering-successfully-on-remote-server?forum=exchangesvravailabilityandisasterrecovery


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Tuesday, August 29, 2017 9:10 PM
  • In my case, no.

    In this case, we aren't even performing any real functions yet - just initiating the New-PSSession to Office365.   This could be something to look at, if i had access to the Exchange servers themselves at Office365, unfortunately, I do not.

    In this specific case, as detailed by the author - we see the issue as simple as 

    get-credentials

    new-pssession (using credentials above)

    Readily reproduced (I invite you to try it yourself) by trying against two tenants.   Using a fresh powershell shell, try it.

    1 - set two credential variables, one for an admin in each of two unique O365 tenants.

    2 - New-PSSession using creds for Tenant1 admin (it might work, it might not) 

    2 - Remove the PSSession

    3 - New-PSSession using creds for Tenant2 admin (doesn't work for me, pretty reliably)

    - observe failure

    This is the behavior I have been using with O365 support for most of the day to reproduce the problem.   Out of the 30 or 40 times I have repeated this test today while on the phone with support representatives today, I think I've been surprised a total of 2 or 3 times, with a success where I did not expect it.  That is nowhere near the 100% success rate we've had for months.

    • Proposed as answer by jszhang Tuesday, August 29, 2017 9:29 PM
    • Unproposed as answer by jszhang Tuesday, August 29, 2017 9:29 PM
    Tuesday, August 29, 2017 9:26 PM
  • Yeah, that sounds like a problem in your tenant or region.  I'd keep pushing it back to Support.  I have been alerted to independent reports of this issue, so don't feel alone.

    One more thought, you're not blocking Basic Auth, are you?


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!



    Tuesday, August 29, 2017 9:29 PM
  • Issue reported in Admin Center, EX116717. Fix is in progress.
    • Proposed as answer by HeensIt Wednesday, August 30, 2017 7:05 AM
    • Marked as answer by Swatisrao Wednesday, August 30, 2017 6:28 PM
    Tuesday, August 29, 2017 10:52 PM
  • I can confirm that (at least at my end) it starts working again...

    BTW... Strange that the Admin center says that this EX116717 service request was opened 5 days ago and that no one (myself and the MSFT team that handles my case included) noticed this??? And another "strange" thing... why is something like this "Advisory" and not an "Incident" ;-)

    Wednesday, August 30, 2017 7:09 AM
  • Hi guys,

    Seems to be working again for me as well. (support case 117083016258788)

    Wednesday, August 30, 2017 7:32 AM
  • Hi guys,

    I just received the confirmation that they've fixed the issue:

    'I am sending you this email regarding your support request 30126-6274573.
    We have made some changes in order to solve the issue, you shouldn’t get the error anymore. I would appreciate if you can check if that is the case and let me know.'

    Switching between tenants is working over here!

    Wednesday, August 30, 2017 8:55 AM
  • Great, thanks for your update and appreciate your patience.
    If there is anything else we can do for you, please feel free to post in the forum.

    Regards,

    Allen Wang


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, August 31, 2017 6:51 AM
    Moderator