During a roll-up update on Exchange Server 2016, I had some issues with the CU. The problems I had with it and the solution I found were described in a post on my blog at MSB365. However, what I didn’t describe in the other article was another phenomenon of Exchange Services. By updating the second Exchange Server, I ran into another error. It showed me that the setup progress was not able to stop or start the Exchange Services. After having a look at them, I noticed that all of them were disabled. The problem, in this case, is that they were disabled and not just stopped. Had they been just stopped, we could reboot the Exchange Server and the chances would be high that the Exchange Services will run again. However, with Exchange Services disabled, this is not that easy. We need to change the startup type from disabled to automatic. There are two common ways we can do that: We can start each of them manually in the Services Snap-in (not really recommended) or we use PowerShell to do it for us.
Of course, I chose the second option! Here are the steps I used:
Finding the right Exchange Services
First, we have to know which services there are and which need to have their startup type changed. I used the Get-Service cmdlet to find out. In my case, I was just interested in the Exchange Services, so I needed to filter them with the following command:
Get-Service | Where-Object { $_.DisplayName –like “Microsoft Exchange *”} | ft Name,Status
Change the status
The output told me which services needed to have their startup type changed. To do that, I only had to change the entry after the last Pipe. (To change the startup type I don’t need a displayed output, but I need to change the startup type for the selected services.) This I did with the following cmdlet:
Get-Service | Where-Object { $_.DisplayName –like “Microsoft Exchange *” } | Set-Service –StartupType Automatic
The Exchange Services startup type was changed from disabled to automatic. But they were still not running. To start the services, we can use the following cmdlet:
Get-Service | Where-Object { $_.DisplayName –like “Microsoft Exchange *” } | Start-Service
This command can take a while until it is finished. The reason for that you will see in your PowerShell console. All of the services need to be started and PowerShell is doing that in a serial way (not in a parallel way). However, from my point of view, this is good, because we are able to see what is happening with each of the services and if we have any other issues.
Next step, IIS
After the Exchange Services have all changed their startup type and status, we are almost done. There is another service we also have to think about — IIS.
To edit the IIS Admin Service, we can follow the same concept as we did with the Exchange Services. First, we need to identify the services and set the startup type to automatic. For that, we can use this cmdlet:
Get-Service | Where-Object { $_.DisplayName –eq “IIS Admin Service” } | Set-Service –StartupType Automatic
Last but not least, we also need to start IIS Admin Service. This we can do with the following cmdlet:
Get-Service | Where-Object { $_.DisplayName –eq “IIS Admin Service” } | Start-Service
From this point, I was able again to continue my CU update. These commands work for all kind of services we need to modify. In the Exchange case, we need to make sure that the POP3 and IMAP4 services are also started and the startup type is set to automatic. These services normally have the following settings:
Name | Status | Startup Type |
Microsoft Exchange IMAP4 | Stopped | Manual |
Microsoft Exchange IMAP4 Backend | Stopped | Manual |
Microsoft Exchange Notification Broker | Stopped | Automatic |
Microsoft Exchange POP3 | Stopped | Manual |
Microsoft Exchange POP3 Backend | Stopped | Manual |
Microsoft Exchange Server Extension for Windows Server Backup | Stopped | Manual |
I hope this will help you have less headaches if you run into this kind of problem. In my case, it did the job.
An alternative way
However, if the Get-Service commands are not responding, we still have a Plan B. Here we can use the Get-WMIObject cmdlets. Again, we need to identify the Exchange Services and after that, we start them. The command looks like this:
Get-WMIObject win32_service | Where-Object {$_.name -match "exchange" -and $_.startmode -eq "Auto" -and $_.state -ne "running"} | Start-Service
By the way, if we remove the name check, we can do that for all services. As an example the command would look like this:
Get-WMIObject win32_service | Where-Object {$_.startmode -eq "Auto" -and $_.state -ne "running"} | Start-Service
You can find more about this on my blog by following the link here.
Exchange Services disabled? Don’t panic
This article is a brief introduction on how to change the startup type of Microsoft services, explained using a real with Exchange Server. It works with other services as well. However, if you don’t feel comfortable using PowerShell for editing servicea, I highly recommend you have a look at articles on Microsoft TechNet or my MSB365 blog.
Very helpful. Thank you!
Thank you for sharing!
Thanks for posting this. Unfortunately, in my case, your documented items weren’t enough to get the system working again. I found I needed to also fix the Microsoft Filter Management Service (this wouldn’t allow the transport service to start properly) and the World Wide Web Publishing Service before things were fully restored.
The update for exchange week of may 12th 2021 did this to me. Left all the services disabled.
Also check the following:
Windows Event Log
Windows Management Instrumentation
Both are required for the Microsoft Exchange Health Manager to start up.
And finally:
World Wide Web Publishing Service
I dumped powershell results of service status check to a text file and saved it in a safe place in case the next update leaves those services off — so I know exactly what to turn back on (And will probably make a script that does so for me)
I hope this helps someone, as these previous posts helped me. I was also lucky in that sense that I have one working Exchange server in my DAG so I was able to double check the services from there.
If you run “Get-WmiObject win32_service | ?{$_.PathName -like ‘*exchange*’} | select Name, DisplayName, State, PathName” it will lists all the services which has exchange in the executable path, so that shows that also “Tracing Service for Search in Exchange” should be modified. For me it was disabled and correct settings (at least in my other server) is Automatic.
Unfortunately I didnt take notes of all the changes I did, but I seem to recall also “Performance Logs & Alerts” was set to disabled and that should be Manual.
In my working Exchange 2016 CU19 only disabled services are these:
Auto Time Zone Updater
Computer Browser
Microsoft App-V Client
Network Connectivity Assistant
Offline Files
Routing and Remote Access
Smart Card
User Experience Virtualization Service
Windows Search
So if you have other services disabled they should be set to Automatic or Manual – and unfortunately I cannot list Automatic/Manual setting for everything here.
hi,
i have Exchange 2013 CU 23 , it was running just fine till today when i noticed all services were disabled. i have checked the fix and apply it and set the Microsoft Exchange Services to “Automatic” but none is able to start back manually or automatically. a security update 2021-09 was installed the night before, tried to uninstall it, but also uninstall failed and got a “permanent error” when trying to remove it.
any ideas guys?
Hi all
we have an issue where all our servers with “net.Tcp Port sharing service” gets stopped and disabled after about 6 hours of starting it. i checked event log and nothing like an error but it only says service is stopped and then another event to say it is disabled. there is no log other than this i can look at what is causing this issue. i tried all sort of options but nothing seems to tell me about the source.
can anyone suggest a solution?