Although it is possible to auto-upgrade your Azure AD Connect server, not all releases are available through the auto-upgrade mechanism.
The current version of Azure AD Connect is 220.127.116.11, released on December 9, 2019 and is not available through auto-upgrade for example. The version on my Azure AD connect server is 18.104.22.168. You can easily check this in Control Panel | Programs | Programs and Features.
For the version release history of Azure AD Connect check this page: Azure AD Connect: Version release history.
Upgrading is easy, download the latest version from Microsoft Azure Active Directory Connect download page and start the downloaded Windows installer package. When the Upgrade Azure Active Directory Connect window appears, click Upgrade and follow the wizard.
Enter the global tenant admin password in the Connect to Azure AD window, click Next and the Ready to Configure window appears.
It will upgrade the Azure AD synchronization configuration and it will enable auto-upgrade. If needed, you can uncheck the start the synchronization process when configuration completes checkbox, this way you can make manual changes before synchronization start.
Click Upgrade and with 2 minutes the upgrade is finished, and synchronization will resume.
On March 20, 2018 Microsoft has released two new quarterly updates:
- Exchange 2016 Cumulative Update 9 (CU9)
- Exchange 2013 Cumulative Update 20 (CU20)
There aren’t too many new features in these CUs. The most important ‘feature’ is that TLS 1.2 is now fully supported (most likely you already have TLS 1.2 only on your load balancer). This is extremely supported since Microsoft will support TLS 1.2 ONLY in Office 365 in the last quarter of this year (see the An Update on Office 365 Requiring TLS 1.2 Microsoft blog as well).
Support for .NET Framework 4.7.1, or the ongoing story about the .NET Framework. The .NET Framework 4.7.1 is fully supported by Exchange 2016 CU9 and Exchange 2013 CU20. Why is this important? For the upcoming CUs in three months (somewhere in June 2018) the .NET Framework 4.7.1 is mandatory, so you need these to be installed in order to install these upcoming CUs.
Please note that .NET Framework 4.7 is NOT supported!
If you are currently running an older CU of Exchange, for example Exchange 2013 CU12, you have to make an intermediate upgrade to Exchange 2013 CU15. Then upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2013 CU20. If you are running Exchange 2016 CU3 or CU4, you can upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2016 CU9.
If you are coming from a recent Exchange 2013 CU, there are no schema changes since the schema version (rangeUpper = 15312) hasn’t changed since Exchange 2013 CU7. However, since there can be changes in (for example) RBAC, it’s always a good practice to run the Setup.exe /PrepareAD command. For Exchange 2016, the schema version (rangeUpper = 15332) hasn’t changed since Exchange 2016 CU7.
As always, check the new CUs in your lab environment before installing into your production environment. If you are running Exchange 2013 or Exchange 2016 in a DAG, use the PowerShell commands as explained in my earlier EXCHANGE 2013 CU17 AND EXCHANGE 2016 CU6 blog.
More information and downloads
I already mentioned this in my blogpost about Exchange 2016 CU6 and Exchange 2013 CU17, but when upgrading an existing Exchange 2016 server to Exchange 2016 CU6, the setup application stops after step 5, 6 or 7 (random) with the following error message:
“A reboot is required to complete file operations on ‘E:\exchangeserver.msi’. Reboot the machine, and then run setup again”
After rebooting and restarting the setup application the upgrade finishes successfully.
Rebooting the Exchange 2016 server prior to starting the upgrade process does not prevent this from happening. Also, there’s no difference between Exchange running on Windows 2012 R2 or Windows 2016.
The installation process has been tested by Microsoft and TAP customers, and tests are still conducted. It is somewhat clear what the root cause is for this issue, it is an MSI package that’s causing this issue. Please be aware that the Microsoft setup application executes around 200 MSI packages, and if only one MSI package is having difficulties you can see issues like this. Because of the number of MSI packages it is not possible to check in advance if your server will experience this issue.
At this moment the only solution is to reboot the server when requested and restart the application program.
I’m running a coexistence scenario with Exchange 2013 and Exchange 2016 without too many issues. My hybrid server is running on Exchange 2013 from the beginning, and it is time to upgrade this server to Exchange 2016.
If you have configured your Exchange environment correctly the hybrid server is nothing special. In my environment the hybrid server is just used for sending SMTP messages between Exchange Online and Exchange on-premises, and it is used for migrating Mailboxes back and forth.
Upgrading the existing Exchange 2013 hybrid server to Exchange 2016 is actually just a matter of installing a new Exchange 2016 Mailbox server, configure it correctly like the old Exchange 2013 hybrid server and rerun the Hybrid Configuration Wizard application.
Figure 1. The new hybrid server (hybrid02) will be installed next to the old hybrid server (hybrid01)
Continue reading Upgrade Hybrid Server to Exchange 2016
During an upgrade of an Exchange 2013 SP1 multi-role server to Exchange 2013 CU8 the upgrade crashed, apparantly on a strange Receive Connector configuration since the following error message was raised:
The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector ” SERVER1\Relay Connector SERVER1″. Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.
Continue reading Upgrade to CU8 Fails on Receive Connector misconfiguration