Home » Exchange Server » Slow Installation of Exchange Server Cumulative Updates

Slow Installation of Exchange Server Cumulative Updates

Customers who are installing Exchange cumulative updates may notice an increased install time of 50% or more. There are two common causes of this behavior.

Antivirus software running on the server can drastically slow down the cumulative update installation process. If you are seeing very slow installation performance and are at risk of exceeding your outage window, consider stopping your antivirus software until the installation has completed.

The other common issue is Windows Server 2012 R2 systems that have applied Windows Update KB3097966, an update that removed trust for four code signing certificates that were inadvertently disclosed.

Before running Exchange updates it is recommended to run the following command on the server:

You only need to perform this step once per server. It can be performed as a preparation step before your cumulative update installation. There is no restart prompt after running the command, nor does one appear to be required.

Note: The output of that command will include a lot of errors such as “Failed to load dependency…”. Errors can be ignored as long as the final output line is “All compilation targets are up to date” is displayed, and the exit status code is 0 when you echo the errorlevel variable. If the ngen command won’t succeed for you, then you can still deploy Exchange updates, just be aware that they will install a lot slower than usual.
Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

22 comments

  1. Goran Repak says:

    I ran the command, ended with error -1, and all hell breaks loose, had to restore server from backup. Luckily it was test server.

  2. Chris Wagner says:

    I have tried on a test server and after finishing the ngen update, the following error appears when exchange setup runs

    An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.

  3. Chris Wagner says:

    sorry the rest of text
    I have tested on second server the same error appears, so I would say this is a shit I prefer to wait
    50% more than recovering the server from backup

    except that you can’t even run the exchange setup anymore.

    I have tried it only by exchange 2016

  4. Chris Wagner says:

    Hi Paul

    I have found out what the problem was

    I have to unlock the .iso file in its properties which I have downloaded and I had to extract the iso file again.

    now is working,

    really sorry for this confusing thing but Microsoft sometimes does shits 🙂

  5. Chris Wagner says:

    You can mount the ISO directly but you have first to unlock the ISO File, otherwise you will have the same troubles I had

  6. Dann Cox says:

    After running this, and getting an errorlevel of 0, I found that the self-signed certificate for the web management service was suddenly missing – service would not start. I replaced it easily enough.

  7. Derek says:

    run the command and ended up with a -1 error. We are running framework 4.0.30319 and the CU1 upgrade for one server took 3.5 hours

  8. milan24_2000 says:

    thanks for sharing, I ran this one mbx server and it took 1h30min, the other mbx server that didnt run the command took 2h40min

  9. Christopher Dooks says:

    I’m updating Exchange 2016 vanilla to CU3. Tried ngen.exe update – got -1 at the end. Proceeded with the install anyway.

    One of two servers updated, started at 10 am, finished just past 2 in the morning! Looking in the log it was ngen errors constantly. Just doing server number 2. Servers are high spec, E5-2660v3, 16GB of RAM, storage on SSDs etc. I think ngen is single thread only which could be why it took so long.

    This is ridiculous Microsoft, thankfully we don’t have live users yet, but I dread any upgrades moving forward. Is there another workaround? Removing KB3097966 for the duration of the install may be a much better option for those who need to upgrade within a certain time window. I may test this.

    – Chris

  10. ok says:

    I experienced an issue trying to install CU3 on Exchange 2016/20012 R2 where I had I couldn’t progress past the ‘Add Server Role’ dialog – the upgrade wasn’t providing any feedback/status in the UI either.

    I tried clicking ‘next’, Tab and hit [Enter] on ‘next, run as Administrator on Setup.exe and Event Viewer didn’t detail anything reason for the anomaly.

    Running the installer via cmd, elevated as Administrator provided a status on the components being upgraded;

    setup.exe /m:Upgrade /IAcceptExchangeServerLicenseTerms

    Hope this helps others

  11. Arjun says:

    Hi Paul, is this applicable for KB3097992 as well?
    My understanding is KB3097992 will include changes introduced in KB3097966
    I am upgrading to CU15 on windows 2012 R2, thanks in advance

Leave a Reply

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