In order to fix the same server, they then tried to update their server to CU16. When the CU16 installation complained about the .NET version, they upgraded .NET to 4.6.2. The CU16 upgrade was tried again and it failed.
Then I was called in to assist. We reviewed the situation and decided to move forward with the Exchange CU16 installation. According to Microsoft, the ideal upgrade plan would have been:
- Upgrade Exchange 2013 CU12 to CU15
- Update .NET to 4.6.1
- Upgrade Exchange 2013 CU16
However, for us to get there, we would need to take a much longer path:
- Uninstall .NET 4.6.2, cleanup and reboot
- Install .NET 4.6.1 – may need a reboot
- Upgrade Exchange 2013 CU12 to CU15
- Update .NET to 4.6.1
- Upgrade Exchange 2013 CU16
The downtime would have been enormous.
We decided to move forward with CU16 as .NET was in place and the services were not working. The upgrade from CU12 to CU16 was progressing fine until it go to around step 8 or 9 and then we experience symptoms like this:
https://blogs.technet.microsoft.com/karthikm/2016/09/28/unable-to-upgrade-cu-the-installation-source-for-this-product-is-not-available-verify-that-the-source-exists-and-that-you-can-access-it-error-code-is-1612/
When we monitored the Exchange 2013 services during the upgrade, we noticed that the services would be disabled on each Role upgrade:
- Step 9 – Mailbox Role: Transport Service
- Step 10 – Client Access Role – Front End Transport Service
- Step 11 – Mailbox Role: Client Access Service
- Step 12 – Mailbox Role – Unified Messaging Service
- Step 13 – Mailbox Role – Mailbox Service
- Step 15 – Client Access Role – Client Access Front End Service
The solution from Microsoft is to monitor the services to see when they get disabled and then to run this PowerShell one-liner:
Get-Service | where{$_.Name –Like ‘MSExchange*’} | set-Service –StartupType ‘automatic’
However, this method will miss a couple of services:
One of the services, the ‘Microsoft Filtering Management Service’ is one services that the ‘Microsoft Exchange Transport’ service depends on. Also, the ‘Microsoft Exchange Search Host Controller’ service would not be included. How do I know this? First, let’s take a look at the services involved with Exchange:
If we explore the services with PowerShell, we have two ways to identify the services for Exchange – either the Name or the DisplayName. The code above uses the Name property and not Display Name. Here is the difference this makes:
Notice that there are 3 more services identified. However, both miss the ‘Microsoft Filtering Management Service’. In order to make this a more viable solution, we should run these:
Get-Service | where {$_.DisplayName -Like 'Microsoft Exchange*'} | set-Service –StartupType 'automatic'
Get-Service | where {$_.DisplayName -Like 'Microsoft Filtering*'} | set-Service –StartupType 'automatic'
** Caveat ** This will also change the IMAP and POP services. We can reset these to Manual or create an exception.
The Eventual Solution
For each of the Steps, we would see the Exchange services disabled right at the beginning of the Step. As soon as that happened, we would then run the PowerShell script to set all services to Automatic. Then we would wait for the next step and then re-run it again once the services go to Disabled. We did this 6 times. Then all the services started and they were able to connect with Outlook, OWA and smartphones.i>
