Exchange 2010 SP2 Roll Up 4 Does Not Install - Error Code 1603

Tuesday, August 21, 2012
Event 1024 MSiInstaller - Error code 1603

Update: Microsoft is asking customers who are having this issue to open a support case with Microsoft Technical Support.  They see random support calls related to this going back to Exchange 2007, but want to reproduce the issue with customers currently seeing this issue with Exchange 2010 SP2 UR4. 

See http://support.microsoft.com/kb/319726 for MTS phone numbers in your area. 
I had an interesting problem installing Exchange 2010 SP2 Update Rollup 4 (UR4) on servers that have never had issues installing updates before.  When I tried to install SP2 UR4 on the Edge Transport or typical installation servers it would rollback the installation and log the following error in the application log:
Product: Microsoft Exchange Server - Update 'Update Rollup 4 for Exchange Server 2010 Service Pack 2 (KB2706690) 14.2.318.2' could not be installed. Error code 1603. Windows Installer can create logs to help troubleshoot issues with installing software packages.
Normally this issue us fixed by installing the Update Rollup from an elevated CMD prompt (see http://blog.c7solutions.com/2011/03/exchange-2010-update-rollups-and-error.html), but this time it still wasn't working.

I enabled MSI Installer logging as per http://go.microsoft.com/fwlink/?LinkId=23127 and dived into the setup logs.  I found the following error being logged in the ServiceControl.log:
[19:51:28] [Error] System.Management.Automation.ParseException: At C:\Program Files\Microsoft\Exchange Server\V14\Scripts\ManageScheduledTask.ps1:462 char:5
+                 return $success
+                 ~~~~~~~~~~~~~~~
Control cannot leave a finally block.
 
at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input, Hashtable errorResults, Boolean enumerate)
at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
I examined the ManagedScheduleTask.ps1 script which apparently disables the 'Database One Copy Alert' scheduled task, but could not determine what the error is.  I also ran the script from EMS, which returned the same error.  Nothing showed up on the Interwebs other than a few references to PowerShell 3.0, which is not installed on these servers.

I finally resolved it by renaming the ManageScheduledTask.ps1 script to ManageScheduledTask.old and creating a new empty ManageScheduledTask.ps1 script.  The script must exist and return a non-error code when executed for the UR4 installer to work.  I renamed the script back when the installer finished.

This may be an esoteric problem, but I wanted to document it in case anyone else has the same problem.  If this does happen in your environment, please leave a comment below.  Thanks.

Follow Up (10/12/2012)
I've found several times so far that this happens to servers that have the Windows Management Framework 3.0 installed.  The RTW version is found at http://www.microsoft.com/en-us/download/details.aspx?id=29939.  The Windows Management Framework 3.0 includes PowerShell 3.0, which is not compatible with Exchange 2010 and explains why the ManageScheduledTask.ps1 script doesn't run properly.

Check the installed updates on the problem server for the Windows Management Framework 3.0 and try uninstalling it to see if it solves the problem.  The Framework allows you to manage servers remotely from the Windows Server 2012 Server Management Console.

Microsoft re-released the following updates to fix a code-signing issue that may affect some customers in the near future:
See the EHLO Blog article, Re-released Exchange 2010 and Exchange 2007 update rollups for more information.  The re-release of the these update rollups has no bearing on the script issue covered in this article, but I do recommend installing the re-released updates on your Exchange servers to prevent future code-signing issues.
by at
Tags , , , ,

36 comments:

  1. Philip Elder Cluster MVPAugust 21, 2012 at 4:36 PM

    Hi,

    Was the UR setup started from an elevated command prompt or from a right click and Run As Admin in the GUI?

    We always run SPs and URs via elevated command prompt as we have run into issues in the past on both 2007 and 2010 updates.

    Philip Elder

    ReplyDelete
  2. Jeff Guillet - @exptaAugust 21, 2012 at 4:51 PM

    This was from an elevated cmd prompt. You can't do a "run-as Administrator" for an MSP file.

    ReplyDelete
  3. Philippe LACOUCHIEAugust 24, 2012 at 1:52 AM

    thank you for your solution. i had the same error on sbs 2011 french version.
    but i have a comment:
    the original "corrupted" file "ManageScheduledTask.ps1" is from the UR2 and when you replace it with an empty file, it is updated by the UR4. so, don't restore the original file.
    Thank you for your help.

    ReplyDelete
  4. Andrew MeyercordAugust 24, 2012 at 7:33 AM

    Thank you for the info on enabling msi installer logging. I'll certainly keep that filed for future use. I didn't have this issue when installing Rollup 4 on my servers, but I did run into the typical issue of being unable to apply an MSP patch from the GUI.

    I wanted to share a tip that I discovered somewhere and have been using for awhile. A quick reg hack will add "run as admin" to the context menu for MSPs:

    [HKEY_CLASSES_ROOT\Msi.Patch\shell\runas\command]
    @=hex(2):22,00,25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,74,\
    00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,6d,00,\
    73,00,69,00,65,00,78,00,65,00,63,00,2e,00,65,00,78,00,65,00,22,00,20,00,2f,\
    00,70,00,20,00,22,00,25,00,31,00,22,00,20,00,25,00,2a,00,00,00

    Repeat for [HKEY_CLASSES_ROOT\Msi.Package\shell\runas\command] to use it on MSIs as well

    ReplyDelete
  5. Cannon BeachAugust 25, 2012 at 2:10 PM

    Thank you.

    Words cannot express the constant BS that Exchange Admins have to constantly jump through to achieve successful executions of the simplest tasks.

    It is extremely helpful posts like this that not only prevent - more - voluminous postings about the - continual - inefficiencies of Microsoft but also cement empirical observations about the high maintenance costs of Exchange Server and the tireless support of the caring community.

    Thank you again. Much!

    ReplyDelete
  6. AnonymousAugust 28, 2012 at 8:17 PM

    I'm glad I read this! I was going to install over the weekend.

    ReplyDelete
  7. Serghei PopescuAugust 31, 2012 at 4:23 PM

    Same problem on 4 different SBS servers. This solution worked for all of them. Thanks, man!

    ReplyDelete
  8. AnonymousSeptember 8, 2012 at 12:41 PM

    On Edge server I installed CU4 from elevated cmd.
    From normal cmd CU4 failed.
    On Mailbox\Access server your method was OK. Elevated or normal cmd failed to install CU4.

    ReplyDelete
  9. AnonymousSeptember 14, 2012 at 4:29 AM

    http://social.technet.microsoft.com/Forums/en-US/exchangesvrmigration/thread/089715e9-6066-433f-ad0f-c3930eb0e16c/

    The Above link work for me.

    1. Set-ExecutionPolicy from RemoteSigned to Unrestricted
    2. Execute the MSP installation file from an elevated command prompt (instead of double-clicking on the MSP file)
    3. After the installation was completed I set the Execution policy back to RemoteSigned

    This work and I was able to install Rollup 4 without any problems.

    ReplyDelete
  10. AnonymousSeptember 14, 2012 at 4:35 AM

    This work for me.

    1. Set-ExecutionPolicy from RemoteSigned to Unrestricted
    2. Execute the MSP installation file from an elevated command prompt (instead of double-clicking on the MSP file)
    3. After the installation was completed I set the Execution policy back to RemoteSigned

    ReplyDelete
  11. AnonymousSeptember 23, 2012 at 1:41 PM

    According to http://download.microsoft.com/download/5/2/B/52B59966-3009-4F39-A99E-3732717BBE2A/WMF3%200%20Beta%20Release%20Notes.docx which is a word document detailing differences between Powershell 2 and 3 the error thrown in ServiceControl.log "control cannot leave a finally block" at line 462 in ManageScheduledTask.ps1 in C:\Program Files\Microsoft\Exchange\V14\Scripts folder the finally block should not return any value. So commenting out the line with a # solves the problem for me. Hope that helps others.

    ReplyDelete
  12. Walid AlMoselhySeptember 24, 2012 at 6:37 AM

    I had the same issue on completely clean lab servers, after reading here decided to give the Privileged CMD a run and worked just fine, took a long while (compared to when run from explorer) to finish the .NET phase, but it completed successfully afterwards.. thanks for the tip

    ReplyDelete
  13. Brad MayerOctober 8, 2012 at 8:45 AM

    Had this same issue, however the elevated command prompt execution appears to have resolved it.

    ReplyDelete
  14. SHoTTa35October 8, 2012 at 4:21 PM

    Thanks for the tips so far and they've helped (some) but still having an issue at the end of "Starting Services" - ServiceControl log says it completed but it still rolled back the changes.

    Gonna do a full on verbose logging of the installer to see where it's failing, takes so long to run though then undo, had to wait till late to do it.

    ReplyDelete
  15. Jeffry A. SpainOctober 9, 2012 at 10:33 PM

    My problem was that I installed PowerShell v3 before Update Rollup 4-v2, so "control cannot leave a finally block" was an issue. Rather than substituting an entirely blank script or commenting out the return statement in C:\Program Files\Microsoft\Exchange\V14\Scripts\ManageScheduledTask.ps1, I changed "return $success" to the logically equivalent "Write-Output $success" in line 462. I also removed the now invalid digital signature. My ExecutionPolicy was already RemoteSigned. With these changes the rollup installed normally. The rollup didn't replace the ManageScheduledTask.ps1 script. I ran the rollup msp from the GUI rather than an elevated command prompt. I was logged on as a builtin Administrator. That didn't seem to be a problem. I did open its properties page and unblock it, however.

    ReplyDelete
  16. S WassenbergOctober 11, 2012 at 7:36 AM

    Today I've installed a new Exchange 2010 SP2 server in our environment. All the other Ex2010 servers already run the SP2 rollup 4 update. I was surprised this fresh machine failed on the rollup 4 update. I've tried the suggestions posted here, but no luck. Also installing Rollup 4 v2 did not work. Then I decided to install Rollup 3, it took the system a long time, but it worked! Next, I've tried to install the rollup 4 update, just by double- clicking it, again success. Seems rollup 3 can have some healing effects in this scenario.

    ReplyDelete
  17. SHoTTa35October 11, 2012 at 5:24 PM

    OMG Jeffry I could hug you now. :) I've been trying everything everyone mentioned and for the life of me it just wouldn't install. Changed the script and removed the signature like you said and just doubleclicked the file (running Admin account) and it installed and said completed. Seemed faster too!

    (Notes - I still had the check for publisher things unchecked as well as unrestricted policy setting because I didn't undo them from the last time but it freaking worked.)

    Now I go see that there's a new SP2 Rollup Update 4 v2!

    http://support.microsoft.com/kb/2756485

    Might as well give it a shot since I planned on having server down for a bit :D

    ReplyDelete
  18. Dinko FabricniOctober 16, 2012 at 1:22 PM

    I had problems with SP2 RU4v2.
    Set-ExecutionPolicy Unrestricted helps.
    Please see this article: http://technet.microsoft.com/en-us/library/ff772434(v=exchg.80).aspx
    And scroll to the:
    An incorrect ExecutionPolicy is Set

    ReplyDelete
  19. Dinko FabricniOctober 16, 2012 at 11:50 PM

    Correction to my previous post, after further testing, I've concluded that it is only necessary to run update from an elevated command prompt. Execution policy was set to RemoteSigned and the patch installed successfully to a number of Exchange 2010 servers.

    ReplyDelete
  20. Andre LiechtiOctober 25, 2012 at 12:26 AM

    Hello,

    On your server, be sure that you don't have the Framework NET 4 installed. Remove all these Framework NET 4 component and try again:

    Here is my memo for a successful Rollup update (resume of various problem found all around the web)

    In Microsoft Exchange\v14\Scripts
    Line 462 of ManageScheduledTask.ps1
    Change "return $success" in "Write-Output $success" (for the result of the TryExecute-ScriptBlock function)

    PowerShell : Set-ExecutionPolicy Unrestricted

    Open a command prompt in Administrator mode and launch Rollup with log: Exchange2010-KB2756485-v2-x64-xx.msp /lxv* Rollup4v2.log

    During the Rollup installation, wait until it stop saying "Stoppping services" and while the Rollup is continuing, put the "Windows Management Instrumentation" service back to Automatic and restart it

    Rollup4v2 should be successful

    Powershell: Set-ExecutionPolicy RemoteSigned

    Hope it helps !

    Regards,

    Andre

    ReplyDelete
    Replies
    1. hafnerJanuary 11, 2013 at 2:55 AM

      Jeff - thank you SO MUCH for this great tip!!

      Delete
    2. hafnerJanuary 11, 2013 at 2:58 AM

      Jeff - thank you for this great tip

      Delete
  21. CarolChiNovember 17, 2012 at 11:45 AM

    Been trying to install RU4 for a couple of months in test environment, which also has System Center 2012 and Server 2012 DCs and management consoles.
    The Exchange server is still running 2008 R2, but with .NET 4 and probably WMI 3.
    RU 4 is announced as installed in updates but Windows update keeps trying to install it again.
    When I try to uninstall it tells me it has failed to remove RU2!
    Have tried unrestricted, elevated command prompt, have uninstalled Forefront completely, all to no avail. I am very impressed with how robust Exchange is to all this mistreatment.

    ReplyDelete
  22. AnonymousDecember 19, 2012 at 4:41 AM

    Latest news from the Exchange Team blog. Remove Windows Management Framework 3.0.

    http://blogs.technet.com/b/exchange/archive/2012/12/14/windows-management-framework-3-0-on-exchange-2007-and-exchange-2010.aspx

    ReplyDelete
    Replies
    1. GwennieJanuary 19, 2013 at 8:47 AM

      This is exactly what I was looking for. Simply uninstalling Windows Management 3 and all is well on my exchange servers again. Thank you, thank you.

      Delete
  23. AnonymousDecember 19, 2012 at 11:33 PM

    andre - thank you, that sorted it when trying to install rollup 5v2 for me!

    ReplyDelete
  24. AnonymousDecember 23, 2012 at 1:25 AM

    Jeff - thank you SO MUCH for your help!!

    I'm an experienced SBS 2003 admin but am new to Exchange 2010 and I've got the same problem on TWO different SBS 2011 servers that I'm setting up for clients this weekend. Both cannot install Exchange 2010 SP2 Update Rollup 5-v2.

    Renaming ManagedScheduledTask.ps1 did not solve the problem for me and neither server had Windows Management Framework 3.0. However, your guidance pointed me in the right direction - after enabling logging and searching the log file for error 1603, I found the same issue with \Exchange Server\V14\Bin\ServiceControl.ps1. Renamed/replaced it, ran the installer again and it worked!

    Thanks again - you have probably saved me a whole Sunday morning of frustration!

    ReplyDelete
  25. Michael ManasanDecember 25, 2012 at 9:30 AM

    Thank you so much for this great tip, although there's a far better solution which references this solution as seen from the comments in this link: http://social.technet.microsoft.com/forums/en-US/exchangesvrdeploylegacy/thread/fb9140a2-4590-489b-ba52-1211820d7116/ ... it seems that changing return $success to Write-Output $success works...I opened the problematic script - ManageScheduledTask.ps1 and sure enough line 462 wasn't recognized as a valid statement by powershell...changed it to Write-Output $success, saved, and everything worked fine afterwards...

    ReplyDelete
  26. AnonymousJanuary 2, 2013 at 7:40 AM

    Renaming/create empy .ps1 don't work for my SBS2011, instead editing line 462 it's ok!
    Thx all for sharing the knowledge.
    Happy new year to all :)

    ReplyDelete
  27. UnknownJanuary 9, 2013 at 12:42 PM

    I made the mistake of updating to Windows Management Framework 3.0. And I'm running into numerous similar problems. Does anyone have a link with instructions for removing WMF 3.0 as well as rolling back to .NET 3.5 from .NET 4?

    ReplyDelete
    Replies
    1. Jeff Guillet - @exptaJanuary 9, 2013 at 3:48 PM

      Hi Jacob, simply uninstall WMF 3.0 (which includes PowerShell 3.0, which is not suitable for Exchange 2010) from Control Panel > Programs and Features. No need to uninstall .NET 4 - it runs side-by-side with .NET 3.5 and is not an upgrade.

      Delete
  28. AnonymousJanuary 23, 2013 at 9:33 AM

    I works for me,
    Thank you for scrupulous troubleshooting and great explanation.

    ReplyDelete
  29. AnonymousJanuary 26, 2013 at 2:39 PM

    thanks for the help

    Worked for me!

    ReplyDelete
  30. AnonymousJanuary 30, 2013 at 12:16 AM

    Same issue and it works for me. Thnks.

    ReplyDelete
  31. UnknownMarch 5, 2013 at 7:39 PM

    Same, thank you thank you and once again, thank you .Top JOB !!!

    ReplyDelete
  32. Christian KjærMarch 18, 2013 at 6:34 AM

    [Quote]
    My problem was that I installed PowerShell v3 before Update Rollup 4-v2, so "control cannot leave a finally block" was an issue. Rather than substituting an entirely blank script or commenting out the return statement in C:\Program Files\Microsoft\Exchange\V14\Scripts\ManageScheduledTask.ps1, I changed "return $success" to the logically equivalent "Write-Output $success" in line 462. I also removed the now invalid digital signature. My ExecutionPolicy was already RemoteSigned. With these changes the rollup installed normally. The rollup didn't replace the ManageScheduledTask.ps1 script. I ran the rollup msp from the GUI rather than an elevated command prompt. I was logged on as a builtin Administrator. That didn't seem to be a problem. I did open its properties page and unblock it, however.
    [/Quote]

    Thank you for your sharing of this issue. Worked for me on a Server 2012 with Exchange 2010 on it.

    ReplyDelete

Thank you for your comment! It is my hope that you find the information here useful. Let others know if this post helped you out, or if you have a comment or further information.

Subscribe to: Post Comments (Atom)