PLEASE READ THE ENTIRE POST
I had a failure on one of my two Exchange 2019 CU4 servers when installing the Security Update for them:
I could not restart the install as it would fail when getting to the services stoppage part of the installation. I saw this error in the ServiceControl.log file in the C:\ExchangeSetupLogs Directory
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | [20:19:52] ----------------------------------------------- [20:19:52] * ServiceControl.ps1: 3/11/2020 8:19:52 PM [20:19:52] Performing service control with options: [20:19:55] Saving service and registry data [20:19:55] State file C:\ExchangeSetupLogs\ServiceState.xml already exists. [20:19:55] Overwrite is specified. File C:\ExchangeSetupLogs\ServiceState.xml is going to be overwritten with a new state. [20:19:55] Saving service state to 'C:\ExchangeSetupLogs\ServiceState.xml'... [20:20:01] State file C:\ExchangeSetupLogs\ServiceStartupMode.xml already exists. [20:20:01] Overwrite is specified. File C:\ExchangeSetupLogs\ServiceStartupMode.xml is going to be overwritten with a new state. [20:20:01] Saving services startup mode. [20:20:01] Adding to installed roles list: AdminTools [20:20:01] Adding to installed roles list: ClientAccessMailboxRole [20:20:01] Adding to installed roles list: Mailbox [20:20:01] Adding to installed roles list: Bridgehead [20:20:01] Adding to installed roles list: Mailbox [20:20:01] Stopping services for the following roles: AdminTools ClientAccess FrontendTransport Bridgehead Mailbox [20:20:01] Stopping services for 'AdminTools ClientAccess FrontendTransport Bridgehead Mailbox'... [20:20:01] [Error] System.ArgumentNullException: Value cannot be null. Parameter name: array at System.Array.Reverse(Array array) at CallSite.Target(Closure , CallSite , Type , Object ) [20:41:36] ----------------------------------------------- |
I had searched around based on the error code 0x80070643 and found these answers that some had used to get the installation to work.
I downloaded the .msp file to install manually and read the answers on the web-page. It was said that there was an issue with the ServiceControl.ps1 file that is in the Exchange Server BIN directory when running Patch with the Verbose logging enabled:
1 2 3 4 5 6 7 8 9 10 11 | MSI (s) (E8:68) [10:09:37:577]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI347C.tmp, Entrypoint: CAQuietExec MSI (s) (E8!D0) [10:09:37:583]: PROPERTY CHANGE: Deleting QtExecCmdLine property. Its current value is '"E:\Exchange 2019\\bin\QuietExe.exe" "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" " -command . 'E:\Exchange 2019\\bin\servicecontrol.ps1'BeforePatch"'. CAQuietExec: Error 0x80070001: Command line returned an error. CAQuietExec: Error 0x80070001: CAQuietExec Failed CustomAction CA_SAVEDATA_STOP_SERVICES returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 10:09:40: CA_SAVEDATA_STOP_SERVICES. Return value 3. |
I kept reading and digging into the fix for the file. It was said to modify a number of lines in the ServiceControl.ps1 script:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | In the lines of the script (876 and 885), it was: 876: add-pssnapin -Name Microsoft.Exchange.Management.Powershell.Setup -ea SilentlyContinue 885: remove-pssnapin -Name Microsoft.Exchange.Management.Powershell.Setup I changed the lines to say "Microsoft.Exchange.Management.Powershell.Support" instead of "Microsoft.Exchange.Management.Powershell.Setup": 876: add-pssnapin -Name Microsoft.Exchange.Management.Powershell.Support -ea SilentlyContinue 885: remove-pssnapin -Name Microsoft.Exchange.Management.Powershell.Support Also, there was an error referencing the script's inability to stop the WMI service without the -Force flag, so I changed that as well. (Line 342) 342: Stop-SetupService -ServiceName $servicename -ev script:servicecontrolerror -force 3. Next, Change all the Stop-SetupService Entries in the script to Stop-Service 4. Next, Change all the Start-SetupService to Start-Service 5. Next, Add the following to StopServices function to bypass the attempt that was trying to stop services, because they have already been stopped ... Start at line 300 300: Status "Stopping services for '$Roles'..." 301: $services = Get-ServiceToControl $Roles -Active 302: ##Change Here 303: if ($services -eq $null) { 304: return $true 305: } 306: ##End Change Here 307: [array]::Reverse($services) 6. I noticed that these 2 files ServiceStartupMode.xml and ServiceState.xml may have permission issue since the last failure in the C:\ExchangeSetupLogs directory. So, I also renamed the files to .old |
Once I made those changes. I renamed the original ServiceContol.ps1 to a .old file and saved this modified file to the BIN directory. I was then able to successfully run the Security Update.
BUT WHY DID THIS SERVER FAIL AND NOT THE OTHER?!?
Both are CU4, but the server that failed had been upgraded from CU1 where the one that did NOT fail was a clean installation of CU4. So, I checked the ServiceConrol.ps1 file on both servers:
Date of ServiceControl.ps1 is 1/1/2020
Date of ServiceControl.ps1 is 2/3/2020
I have not tested this, but maybe if I had copied the ServiceControl.ps1 file from the CU4 clean installation to the original install, the script might have worked since the creation dates are different and I have no other version information to go on. I will verify this though. For now, the changes to the script allowed me to successfully install the Security Update Successfully.
NOTE: All the Exchange and IIS Services were in a Startup Mode: Disabled state and I had to reset them ALL to Automatic. Once that was completed and the server rebooted, Exchange was returned to normal state. ****Also, just to be safe, I ran a great script that assures the server is out of maintenance mode. You can get the script HERE. You can also get the script to put the server into maintenance mode. You can get the script HERE. These scripts will work on Exchange 2013 and above servers.
UPDATE / 3/12/2020 2:39 AM EST
Something was still wrong with the server. ActiveSync and PAM started breaking. I started having all sorts of authentication problems. I decided to restore the server from backup from Tuesday. I forgot to backup the ServiceControl.ps1 file that modified, but I moved the one from the successful installation to the restored server and am currently running the update. I will see if it works and send the information to you.
UPDATE / 3/12/2020 3:45 AM EST
The restore worked great and placing the ServiceControl.ps1 file in the BIN directory on the prior failed Exchange Server did allow for the installation to complete successfully. I have tested ActiveSync and Authentication which is now functioning properly. Hooray!
SEND ME YOUR IDEAS/ FOR POSTS!
HAPPY TROUBLESHOOTING!
REFERENCES:
Exchange Server Security Update fails with 0x80070643
Exchange Maintenance Mode Script (Start)
Exchange Maintenance Mode Script (Stop)
Exchange Server 2019 CU4 Security Update
I’m unable to manually install patches for Exchange 2019: CU 4,5,6,7,8,10,11,16,17,18,21,23 since I always got “the upgrade patch cannot be installed by the windows installer service…” does not matter if I double click or I start with msiexec from Elevated Command prompt of Power Shell.
I have absolute no any idea how to manually install it otherwise. I simple check the prerequisite and have to install .Net 4.8, Visual Scripts 2012 and 2013 …
Please advice how to overcome the windows with red cross telling “the upgrade patch cannot be installed by the windows installer service”
If this is for a CU upgrade, then you need to mount the ISO image on the Exchange Server. Open the command prompt on the Exchange Server and navigate to the drive letter the image is mounted on. Then you need to run the following cmd:
Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:Upgrade /DomainController:dc01.yourdomain.com /EnableErrorReporting
This should kick off the installation within the command prompt window. Note that Exchange 2019 only goes to CU9 and other statements in your inquiry are questionable. Your post could very well be phishing, but I will still respond since others could benefit from this response. Thank you.