In the first part of this series on the new Exchange Online V2 (ExO V2) cmdlets, we reviewed how to get the prerequisites needed to simply download the ExO V2 cmdlets installed on a new machine. Now we have an even playing field with an workstation that already had the prerequisites and a new machines that had some PowerShell components upgraded to allow for ExOv2 to be installed. What’s next?
The New Cmdlets
In all, Microsoft recreated ten cmdlets in order to take advantage of some tweaks as well as the REST protocol for better performance and reliability for those managing Exchange Online with PowerShell. The new cmdlets are listed below with their older counterparts:
Connect-EXOPSSession or New-PSSession
Recently and in an effort to improve PowerShell performance for those connecting to Exchange Online, Microsoft released a series of cmdlets they are referring to as ExO v2. What you will find is that the cmdlets are NOT a complete rewrite of the entire set of cmdlets used for managing Exchange Online. They are however a rewrite of some of the most used and most intensive cmdlets that were VERY prone to timing out, getting throttled and generating all sorts of headaches while using them in a tenant. Some notes on these cmdlets can be found here:
Release Notes Here
In this blog article, we will cover the basic requirements to just get the new module downloaded and on your computer. Then in the spirit of using PowerShell to solve issues, we’ll review PowerShell code that was written to make sure that the server or workstation you are on, is able to load the new module without issues.
Requirements: (as of the writing of this article)
This one is a new one for me, but I guess it should not be unexpected. If you’ve moved from Exchange on-premises to Exchange Online and your SMTP limits were higher than 150MB, more than likely you found at least one email that was greater than 150 MB … You may have even run into the rare mailbox move that was held up because of those large items and noticed this in your migration logs:
12/19/2019 2:19:31 AM [BN8PR19MB2916] Fatal error TooManyLargeItemsPermanentException has occurred.
For Public Folders, at least up until now, I have not had the same experience. Typically large items were not stored in my clients Public Folders. However, in one recent migration, they also had a large item (over 150MB) in Public Folders! This required a search and removal task for any other items over 150MB. Then I had to remove and restart the Public Folder migration batch. So the tip here is, check your mailboxes for those large items and if you have Public Folders, make sure to check those as well!
A lot of migration projects start off with testing a couple of main components in addition to making sure the environment is secure, we need to make sure email flows to and from all users and free busy works between Exchange and Exchange Online. For this blog post we will explore some blockers when it comes to incoming emails and how to handle the situation.
When it comes to mail flow, Microsoft would like email to flow directly from Exchange to Exchange Online and the reverse with no intermediary devices (unless it is an Exchange Edge Transport Server). This means that email should not be routed to a forwarding service, a hosted mail filtering service or an email appliance. In order to make this happen, Firewall ports need to be open, change requests made and security teams convinced of the needed changes. In order to make the change more palatable, we can lock down the Firewall to allow port 25 for any current connection limitations as well as Office 365 with the provided list that Microsoft has provided HERE. So that covers one potential issue – removing other intermediaries from the mail flow.
Recently I was working with a client and we experienced some strange mail flow issues. These issues included old transport rules on Exchange 2010 as well as delayed and VERY slow emails from on-premises mailboxes to mailboxes in Exchange Online. First, the setup:
- Multiple Exchange 2016 servers
- Multiple Exchange 2010 Servers – Internet mail in and out
- MFA on Exchange 2010
Some troubleshooting steps that we took were as follows:
- DNS Resolution – Check basic name resolution
- Proxy rule check (web proxy servers were in use)
- SMTPDiag tests – Using the SMTPDiag tool (if you can find it anymore)
- Message Tracking (Exchange on-premises) / Message Traces (Office 365)
- Message Header review – once an email was delivered to a migrated mailbox in Exchange Online.
- SPF Records – the current one had 10+ lookups, which was also causing other issues
As a consultant I perform a lot of migrations and as such I wanted to continue to share the issues that I see and the fixes that I have found. For this post I have a brief but common issue that I have seen twice in the past two months of migrations. Specifically this has to do with the MRS Proxy Endpoint creation that occurs in the Exchange Hybrid Configuration Wizard (HCW). The error was shown once the HCW completed its work:
The fix in my case was simple. We needed to disable the MRS Proxy from the server and re-enable it ( a process that can be repeated for any servers serving MRS Proxies ) and then running an ‘IISRESET’ like so:
Once that was completed, I was able to create the MRS Endpoint in the Exchange Online console with no issues at all. That’s it. So if you experience this issue, give this fix a try and see if the solution is that simple.
A couple of years ago I wrote a post on how the Exchange Hybrid Configuration Wizard (HCW) hung on adding a Federated Domain to an Office 365 tenant. You can read the old post HERE. Since then the HCW has been rather trouble free from this perspective. However, I recently had a case where this was not so. The same frozen wizard that hung on adding a federated domain occurred once more. I then tried the fix that I found in my previous post. This time this method failed. The error message was:
“An error occurred while attempting to provision Exchange to the Partner STS. Detailed Information “An error occurred
accessing Windows Live. Detailed information: “The underlying connection was closed: Could not establish trust
relationship for the SSL/TLS secure channel.”