In 2011 I started my foray into public blogging … and with 2020 now well underway, I find myself entering my 10th year of blogging. The original name of my blog came from the fact that my blogging topics were going to be about Exchange, Lync and PowerShell. However, over time I’ve realized that the name no longer fits and I find myself doing all sorts of things. One of my current passions – namely PowerShell (which I have honestly dug into ) has become a major focus for the past three or four years now. I would say I dabbled in PowerShell before that. Now I write books on my favorite PowerShell topics. As such I will be rebranding my blog and move to a more robust platform to handle my blog …
… Which reminds me, I am also moving http://www.PracticalPowerShell.com to the new hosting service as well. In the next week expect some dust. Expect some growing pains. But in the end. Expect more great content!
The name of the blog will be announced here soon. I am currently working on a lot of content as this site has been a bit quiet due to my behind the scene efforts for this project as well as working on four books at the same time. The fruits of my book projects will become apparent in the next few months.
So. Don’t panic. More great content coming. More PowerShell scripts and valuable (hopefully!~) tips are also on their way.
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.