Exchange 2013 CU14

We recommend you skip Exchange 2013 CU14 and instead install either CU12 or the new CU15.  Reason being, Exchange 2013 CU13 and CU14 introduced a significant public folder indexing issue and once the issue occurs, the recommended resolution is to upgrade to CU15 and then move the public folders to a new mailbox database.  In order to avoid this dilemma we recommend you not installed CU13 or CU14.  At this time, Exchange 2013 CU15 is the latest version of Exchange 2013.

Related

4 thoughts on “Exchange 2013 CU14

  1. Mark Bram

    I have installed cu 14 on server with only cas role no mailboxes successfully
    I installed on echange mailbox/cas server and now I can not get login to OWA i get same issues you have described.

    Reply
  2. Nik

    Hi Chris,
    I have a strange issue after I tired to install CU14. We have a 2 MBX servers in DAG and we updated one of them to CU14 successfully. The second one have failed to finish, because it couldn`t enable the Search Host controller service, after I enabled it and re-run the setup it continued to install, but stuck on 5 % on the step Finalizing setup. the build version and product number are up to date as for the last CU, but I am not sure that if I let the server so, it will be fully functional. Seems like all the services are up and the DB copies are shown as healthy, but the install just cannot finish. I`ve tried running it several times with no avail.
    Did you ever have seen anything like this?
    The setup hangs after this is run in the Setup log:
    [09/27/2016 14:13:28.0575] [1] Executing:
    $dependentAssemblyGeneratorExePath = [System.IO.Path]::Combine($RoleInstallPath, “bin”, “DependentAssemblyGenerator.exe”);
    $exchangeBinPath = [System.IO.Path]::Combine($RoleInstallPath, “bin”);
    $clientAccessPath = [System.IO.Path]::Combine($RoleInstallPath, “ClientAccess”);
    $sharedWebConfig = [System.IO.Path]::Combine($RoleInstallPath, “ClientAccess”, “SharedWebConfig.config”);

    $a = &”$dependentAssemblyGeneratorExePath” -exchangePath “$exchangeBinPath” -exchangePath “$clientAccessPath” -configFile “$sharedWebConfig”;
    $a | % { if ($_.Length > 0) { Write-ExchangeSetupLog -Info “$_.ToString()” } }
    Start-SetupProcess -Name “iisreset” -Args “/timeout:120”

    Reply
  3. Brian Hanson

    Since updating Exchange 2013 CU8 to CU13 both the ECP and the OWA fail to load after login; although the login knows if you enter an incorrect password.
    – The OWA returns HTTP 400 error.
    – The ECP returns: Server Error in ‘/ecp’ Application…
    – Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
    – Exception Details: System.IO.FileNotFoundException: Could not load file or assembly ‘Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

    The Exchange server is running but of course I cannot run the ECP. Users are able to access e-mail externally using the Exchange App but not OWA.
    I’ve since discovered after searching through TechNet and other forums that there are several articles on this bug but no definitive resolution. All the suggestions either don’t work or require edits to objects in the ADSIEdit.msc that don’t exist. Apparently there is a newly released fix in CU14, but does that contain more bugs? Has anyone tried installing CU14 yet?
    Any resolutions would be much appreciated.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.