Last year I published a blog post on this same topic. In this post I wanted to dive a bit deeper into what exactly is going on and possibly suggest some ‘upgrades’ to the wizard to make it easier to understand the process.
I recently ran the wizard with a client to see all the new changes and to access what we could copy and what the experience was while running the wizard. Here are my observations… and my final verdict on the experience:
(1) User Experience
This part is initially a good one. The first encounter with the change is on the ‘Hybrid Features’ screen for the Office 365 Hybrid Configuration wizard: Continue reading
After Microsoft switched over to Modern Public Folders, I never thought I would have to worry or dig into the underworkings as much as we did in Exchange 2010 and before. I have been proven wrong twice now. My current issue is a corruption issue where I am unable to currently move certain mailboxes, even the main Primary Hierarchy mailbox, to another database. The server is displaying all the classic signs of a storage/hard drive problem with ESE errors and write or read errors in the Application log.
What I wanted to showcase here were a couple of sample PowerShell one-liners and scripts used to move Public Folder mailboxes and Public Folders as well as monitoring the progress of these moves.
Move Public Folder Mailbox
This is an easy one to work with. If we have a Public Folder mailbox and we need to move this mailbox to another database, possible on another DAG in the Exchange environment, the move cmdlet is very similar to that of a regular mailbox move:
New-MoveRequest -Identity PFMailbox01 -TargetDatabase PF1 -SuspendWhenReadyToComplete -BadItemLimit 10
The last updates for these scripts occurred in June for all three versions. In this update, .NET 4.8 is now added as the default and .NET 4.7.2 is now removed as an option.
The updated scripts can be found here:
Exchange 2019 v1.12 Prerequisite Script
Exchange 2016 v1.18 Prerequisite Script
Exchange 2013 V1.21 Prerequisite Script
Exchange 2019 v1.12 Screenshots:
Wanted to share an interesting find while using PowerShell in Exchange 2019. The cmdlet is ‘Get-OrganizationConfig’ and I Was looking over some information from a summary report I had exported for a client and noticed an interesting field called ‘OrganizationSummary’. So I did a little digging.
Get-OrganizationConfig | Ft OrganizationSummary
We see this information about the Exchange environment:
Recently Microsoft has made some changes where you are required to run a few extra commands prior to upgrading your Exchange 2016 servers to the latest Cumulative Update (CU) 14. The change relates to permissions needed for Exchange and the first change was made in CU12 for Exchange 2016 – KB4490059. A further change was introduced in Exchange 2016 CU13 – June 2019 Quarterly Updates article.. In the article, the wording is a bit unclear as to what steps we need to take (see bolded words):
In order to apply these changes, a directory admin will need to run the cumulative update setup program we are releasing today with the /PrepareAD parameter. When multiple Exchange versions co-exist in a single Active Directory forest, the cumulative update matching the latest version of Exchange deployed should be used. Setup will automatically run /PrepareDomain in the domain where /PrepareAD is executed. Environments with multiple domains in the forest will need to run the cumulative update setup program using the /PrepareDomain parameter in all domains in the forest. These steps will update the rights granted to Exchange Servers in the Active Directory to meet the new permissions scope. More information on /PrepareAD and /PrepareDomain is available at this link.
Ran into an oddity I thought I would share. After installing and verifying a customer’s Exchange 2013 CU22 upgrade using PowerShell, I handed the servers over to the customer. Sometime in the next week the customer contact me to verify I installed the correct CU. Thinking this was rather strange, he shared a screenshot of Add Remove Programs with it clearly showing CU20 as the installed version. I logged into the server and indeed it was incorrect. PowerShell, however, had the version correct at 15.00.1473.3. I then ran the install in a lab, same result. Add Remove Programs was wrong and PowerShell was correct:
After a bit of research, it appears that this is a known issue:
Exchange 2013 CU22 Shows Incorrect Name In Add/Remove Programs
Checking previous and current releases of Exchange, I do not see any other versions that are like that. Not sure how that slipped through QA, but there are other examples of these little things that slip through Microsoft’s QA from time to time. At least this isn’t a major issue.
Microsoft has their own Exchange Supportability Matrix which covers many parts of what is supported with a particular version of Exchange. What you will find is that some charts that are included are a bit wanting. A Lot of older and historical information has been pulled. A fellow MVP, Michel de Rooij posted a a good reference chart for Exchange servers. From that I created a new one and separated all CU’s out and updated it to include the newest CU’s released in June 2019. The chart will look like this:
I plan to bookmark this on the menu bar of my blog to be used as a good reference. If you like it, please make sure to leave feedback. Thanks!