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:
|
1 2 3 |
C:\> %windir%Microsoft.NETFramework64v4.0.30319ngen.exe update C:\> echo %errorlevel% |
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.
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
I don’t know the answer. You can try it and it might be slow. Or you can try the fix first as a precaution.
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
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
thanks for sharing, I ran this one mbx server and it took 1h30min, the other mbx server that didnt run the command took 2h40min
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
can I just uninstall the 3097966 update before running the CU?
You’d be uninstalling a security update, which doesn’t seem like a wise move to me.
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.
Hi Paul,
Thanks for the article!
Q1: What if after running ‘%windir%microsoft.netframeworkv4.0.30319ngen.exe update’ status code is ‘-1’?
Q2: Do we need to run ‘%windir%microsoft.netframework64v4.0.30319ngen.exe update’ on x64 servers? (https://support.microsoft.com/en-us/kb/2570538)
You can mount the ISO directly but you have first to unlock the ISO File, otherwise you will have the same troubles I had
Interesting. Haven’t needed to unblock it myself.
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 🙂
Why not just mount the ISO directly instead of extracting the contents?
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
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.
Which version of .NET Framework do you have installed on the server?
4.5.2
I ran the command, ended with error -1, and all hell breaks loose, had to restore server from backup. Luckily it was test server.
What does “all hell breaks loose” mean though?
It means that after a reboot, many Exchange and Windows services won’t start.
Interesting. I’ve run the command safely on 6-7 servers so far with no issues, and yours is the first instance I’ve heard from anyone else. Did you get a case open or collect anything in your troubleshooting before restoring the server?
Maybe it’s just me, anyway, it’s all OK now, and I’m preparing to update test server to CU1.