Exchange services disabled or not starting after a CU or security update (error 1058)

You install an Exchange cumulative update (CU) or security update (SU), something goes wrong, and afterwards mail has stopped, OWA is down and nearly every Microsoft Exchange service is stopped with a startup type of Disabled. That isn't random damage: Exchange setup disables services on purpose while it works and only puts them back when it finishes cleanly. Here's how to confirm that, restore the services the supported way and finish the update so the server is consistent again.

Symptoms#

• After a failed, cancelled or interrupted CU or SU, the services whose names start with "Microsoft Exchange" are Stopped and Disabled. OWA, ECP, Outlook and mail flow are all down.
• The Exchange Management Shell (EMS) won't connect, because the services it depends on aren't running.
• Re-running the CU stops with Cannot start the service Microsoft Exchange Service Host.
• Starting services by hand fails with errors like these:

C:\> net start MSExchangeADTopology
System error 1058 has occurred.
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Windows could not start the Microsoft Exchange Information Store service on Local Computer.
Error 1068: The dependency service or group failed to start.

In the System log, Service Control Manager records Event ID 7040 whenever a service's start type changes (for example "changed from auto start to disabled"), and Event ID 7000 or 7001 when a service, or a service it depends on, fails to start.

Why it happens#

During a CU or SU installation, setup stops the Exchange services and switches them to Disabled so that nothing (Managed Availability included) restarts them while files are being replaced. It records the original startup types, and at the end of a successful run it restores them and starts the services. Microsoft documents that when setup fails part-way, those services simply stay Disabled.

So the disabled services are a symptom. The real question is what stopped setup. The usual suspects:

• The update wasn't run elevated. Double-clicking an SU package on a server with UAC is the classic example.
• Services didn't stop in time, often because antivirus or another process was holding Exchange files open.
• A restart was already pending from Windows Update or an earlier installation.
• The run was interrupted: a reboot mid-install, a logged-off session or a cancelled wizard.
• A genuine setup error (permissions, Active Directory, prerequisites) recorded in C:\ExchangeSetupLogs\ExchangeSetup.log.

How to fix it#

1. Restart and take stock#

Restart the server once. Then open an elevated Windows PowerShell window (not EMS, which probably can't connect yet) and look at what you've got:

Get-Service -DisplayName "Microsoft Exchange*" | Sort-Object DisplayName |
  Format-Table DisplayName, Name, StartType, Status -AutoSize

# Exchange services whose display name doesn't start with "Microsoft Exchange"
Get-CimInstance Win32_Service |
  Where-Object { $_.PathName -like "*$env:ExchangeInstallPath*" } |
  Format-Table Name, DisplayName, StartMode, State -AutoSize

# IIS and WinRM, which EMS, OWA and ECP rely on
Get-Service WAS, W3SVC, IISADMIN, WinRM | Format-Table Name, StartType, Status

Next, open C:\ExchangeSetupLogs\ServiceControl.log. It lists the services setup stopped and disabled during the run, which is exactly the list you need to restore.

2. Restore the original startup types#

Exchange ships a script that reverses what setup did to the services. Run it from the same elevated Windows PowerShell window:

Set-Location (Join-Path $env:ExchangeInstallPath 'Bin')
Add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.Setup -ErrorAction SilentlyContinue
.\ServiceControl.ps1 AfterPatch

Run the first command from step 1 again. Services that were Automatic before the update should be Automatic now. If one still shows Disabled and ServiceControl.log says setup disabled it, set it back with Set-Service -Name <name> -StartupType Automatic.

3. Start the services#

Service Control Manager starts a service's dependencies for you, as long as none of them is Disabled. That's why you restore startup types first; skipping that step is what produces error 1068 and Event ID 7001. Many Exchange services depend on Microsoft Exchange Active Directory Topology, so start it first and make sure it stays running:

Start-Service WAS, W3SVC
Start-Service MSExchangeADTopology

Get-CimInstance Win32_Service -Filter "StartMode='Auto'" |
  Where-Object { $_.State -ne 'Running' -and $_.PathName -like "*$env:ExchangeInstallPath*" } |
  ForEach-Object { Start-Service -Name $_.Name }

# If one service refuses to start, see what it is waiting for
Get-Service MSExchangeTransport -RequiredServices

4. Find out why setup failed, then finish the update#

Running services don't mean a finished update: the server may now be on a half-applied build.

• Cumulative update: read the first [ERROR] entries near the end of ExchangeSetup.log, or let SetupLogReviewer.ps1 from Microsoft's CSS-Exchange scripts summarise the log for you. Fix the cause, then follow Microsoft's documented sequence: rename C:\ExchangeSetupLogs (for example to ExchangeSetupLogs-OLD), make sure the services are started and set to Automatic, and rerun setup from an elevated prompt.
• Security update: reinstall the package from an elevated command prompt and restart the server afterwards. My post on installing Exchange security updates covers the SU-specific failures.

REM D: is the mounted CU ISO. Use _DiagnosticDataON if that's your policy.
D:\Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

5. Restart and confirm it sticks#

Restart once more and check that every service from the ServiceControl.log list comes up on its own. If you put the server into maintenance mode before patching, take it out now (see DAG maintenance mode step by step).

Verify the fix#

Once EMS connects, run:

Test-ServiceHealth | Format-Table Role, RequiredServicesRunning, ServicesNotRunning -AutoSize
Get-ServerComponentState -Identity $env:COMPUTERNAME | Where-Object State -ne 'Active'
Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo }
Get-Queue -Server $env:COMPUTERNAME

What good looks like:

• RequiredServicesRunning is True for every role and ServicesNotRunning is empty.
• The only Inactive components are ForwardSyncDaemon and ProvisioningRps, which are normally inactive on-premises.
• The ExSetup.exe file version matches the build of the CU or SU you meant to install.
• Queues drain, and OWA, ECP and Outlook connect again.

Then run the Exchange Health Checker once more.

Prevent it next time#

• Restart the server before you install and make sure no restart is pending.
• Always install CUs and SUs from an elevated prompt. In PowerShell, start setup as .\Setup.exe (or with a full path) so you don't run the copy in Exchange's own Bin folder by mistake.
• Set the documented antivirus exclusions, or pause the scanner during the update as Microsoft's CU guidance suggests.
• Install from a console or a session that won't be logged off, and let setup finish even when it looks stuck.
• Work through the cumulative update pre-flight checklist before every CU.

References#

• Fix failed Exchange Server updates (Microsoft Learn)
• Upgrade Exchange to the latest Cumulative Update (Microsoft Learn)