Recently I have been getting issues with performing a hybrid configuration from an on premise Exchange 2010 Server running the latest services packs and meeting all the required pre requisites to perform a Hybrid configuration to Office 365.
One of the first steps is to connect your on Premise exchange server to Office 365 using remote PowerShell, following the how to guide it tells you to connect to the following URI in the command below:
When you run this command you will get the following error:
ps.outlook.com] The WinRM service cannot process the request because the request needs to be sent to a different machine. Use the redirect information to send the request to a new machine. Redirect location reported: https://ps.outlook.com/PowerShell-LiveID?PSVersion=2.0 . To automatically connect to the redirected URI, verify “MaximumConnectionRedirectionCount” property of session preference variable “PSSessionOption” and use “AllowRedirection” parameter on the cmdlet.+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) , PSRemotingTransportRed irectException + FullyQualifiedErrorId : PSSessionOpenFailed
If you’ve ever connected a workstation to Office 365 and then been constantly prompted for your credentials you know how frustrating it can be. Have you ever checked that box in Outlook to “Remember Password” and then screamed in frustration as yet another logon prompt came up?
Below is a collection of sites that can help you troubleshoot issues logging into your Office 365 account.
Coming from Exchange environments: make sure your Autodiscover DNS records (internal and external both) point to the correct place. See also the Troubleshooting Autodiscover video.
Coming from BPOS (and possibly other Exchange systems) follow the instructions at http://support.microsoft.com/kb/2644437 to remove registry entries on clients that stubbornly don’t update their Autodiscover.
If Outlook discovers the wrong (old) Exchange system you have problems. Use “outlook /rpcdiag” to ensure Outlook is connecting to Office 365. You can also control-right-click on your Outlook icon in your system tray and choose the option for “Connection Status.” You should see connections to the cloud-based e-mail servers, not legacy servers. Good steps at http://www.petri.co.il/testing_rpc_over_http_connection.htm.
Be sure to disconnect the remote PowerShell session when you’re finished. If you close the Windows PowerShell window without disconnecting the session, you could use up all the remote PowerShell sessions available to you, and you’ll need to wait for the sessions to expire. To disconnect the remote PowerShell session, run the following command.
How do you know this worked?
After Step 3, the Exchange Online cmdlets are imported into your local Windows PowerShell session as tracked by a progress bar. If you don’t receive any errors, you connected successfully. A quick test is to run an Exchange Online cmdlet—for example, Get-Mailbox—and see the results.
If you receive errors, check the following requirements:
A common problem is an incorrect password. Run the three steps again and pay close attention to the user name and password you enter in Step 1.
To help prevent denial-of-service (DoS) attacks, you’re limited to three open remote PowerShell connections to your Exchange Online organization.
Windows PowerShell needs to be configured to run scripts. You only need to configure this setting once on your computer, not every time you connect. To enable Windows PowerShell to run signed scripts, run the following command in an elevated Windows PowerShell window (a Windows PowerShell window you opened by selecting Run as administrator).