A client approached me with a need for some mailbox statistics. They wanted a script or some sort of PowerShell code to examine a few mailbox details for a migration from one environment to another that was being processed with third party tools. The source environment was running Exchange Server 2010. This means PowerShell 2.0. Now, I’ve written code for Exchange since Exchange 2007 came out. However, I learned a valuable lesson for these scripts. Test in the same version of Exchange. Yes. Obvious. Maybe even Captain Obvious level here…. However, I didn’t have an Exchange 2010 server with actual verifiable data I could use in my example.
So what did I do? I used Exchange 2013. I had data. I had calendar items, tasks, you name it. The cmdlets I was using are the same for both versions. Well “same” has a different meaning in Exchange PowerShell. So what happened? Lot’s of red. Basically Exchange 2010 wasn’t able to use the same parameters and switches like 2010 did. So I ended up rewriting the script to run on both 2010 and 2013, which would then make it more versatile. The script was also validated to run on Exchange 2016 in a lab. Continue reading
When I run into something in PowerShell that draws my curiosity, I usually go down a rabbit hole to further my knowledge of whatever that is. Sometimes this means digging into the text from the HELP for Exchange PowerShell cmdlets. For example, a while back I wrote a script to examine the text for the word ‘Deprecated’ because I Wanted to see what cmdlets were supposed to be deprecated over time. While checking out new cmdlets for Exchange Online, I ran into some cmdlets HELP that seemed to be half-way written. For the synopsis, these cmdlets showed this:
My curiosity was peaked, what other cmdlets are missing information in them. In order to find these cmdlets, I used a script I had created for the ‘Deprecated’ word check – https://justaucguy.wordpress.com/2014/12/05/exchange-2013-and-deprecated-powershell-get-commands/. I simply removed these phrases ‘cmdlet will be removed in a future version of’ / ‘cmdlet has been deprecated’ and inserted this line instead ‘Provide the topic introduction here.’
I simply cannot wait until Public Folders are gone. Increasingly over the years my customers have abandoned them for greener pastures. Yet, I still run into the occasional customer that has Public Folders and insists on moving them to Office 365. Moving folders to Office 365 is almost exactly the same as moving Public Folders to Exchange 2013 or 2016.
** Note ** This article refers to moving Legacy Public Folders which exist on Exchange Server 2010.
Recently I had a client that was existing in coexistence mode with Exchange 2010 and Exchange Online. The migration took a bit longer than planned with the migration of 1500 – 2000 mailboxes. At the end of the coexistence we needed to cutover Public Folder content to the cloud. We did this ONLY when ALL mailboxes were in Office 365. This is done to ensure no one loses access to the folders as an on premises mailbox cannot talk to Public Folders in Office 365.
The article to use when moving Public Folders to Office 365 is:
In my day job as an IT consultant I do work outside of Exchange and end on projects that touch Active Directory, Identity Management, Office 365 and more. A lot of these projects require some sort of health check or simply a quick review of an environment before proceeding with any changes. The thought process is that if we can eliminate any issues at the beginning of a project, less issues will occur to cause problems during the project. As a part of these health checks, we can sometimes utilize built-in Best Practices Analyzers for various components on a server.
Why Is This Important?
Exchange really needs a healthy base to stand on. I once worked for a company where there constant infrastructure issues – storage going offline, Active Directory on the fritz, DNS issues, networking issues…. you name it. Exchange reacted badly to these problems. My boss would hound me that Exchange was ‘down again’. Well, of course its down if users can’t get to it or if storage is not available and databases are not mounted or networking is down and emails will not route. So having healthy infrastructure servers (such as Domain Controllers) is very important. Use a BPA to check these servers out will help determine the healthiness of the systems Exchange relies on.
After running my updated Exchange 2013 and 2016 scripts I noticed that .NET was tripping on itself during the install of either the prerequisites or post hotfixes. So, I decided to completely re-write those sections for .NET 4.6.1 and 4.6.2. I also cleared out .NET 4.5.2 as this one will be deprecated soon. Windows 2008 R2 support has also been removed from the 1.17 version of the Exchange 2013 script.
A separate script was created for Windows 2008 only (third link below). This will be updated until Windows 2008 R2 leaves extended support.
As you can see from the screenshots, the menu has changes a bit from the last version:
Simply wanted to announce that Version 1.2 of my Exchange 2016 Prerequisite script is now up. The new menu looks like this:
Hope you find the script useful.
Most, if not all, of my Office 365 migrations to this point in my career have involved migrating Exchange or Lotus Notes to Office 365’s Exchange Online. Recently I worked on a migration that involved a third-party to Office 365 mail move. I wanted to provide a lessons learned from the migration, as well as a list of what could have been done better (i.e. things to look out for) in this blog entry. The intent is to potentially help anyone who is doing a similar move to Office 365.
The Small Things
- Email aliases / SMTP Addresses
- Organizational forms