All posts by jaapwesselius

set-msoldirsyncenabled not available

Now with Microsoft moving from the old MSOL to AzureAD PowerShell commands (see my blogpost on Azure Active Directory PowerShell v2), you get new features but (unfortunately) things are starting to disappear as well.

In the past you could use Azure AD PowerShell to enable or disable directory synchronization using the Set-MsolDirSyncEnabled cmdlet. During a recent lab deployment, I found out that this cmdlet is no longer available. In fact, not a single Msol cmdlet is available anymore, try Get-Command *msol* and nothing is returned.

To get more information regarding Azure AD you can use Get-Command *Set-AzureAD*. This reveals enough information, but nothing that points to directory synchronization.


When logging on to the Azure Portal (of the newly created Office 365 tenant) it is obvious that Azure AD Connect sync is not enabled, as shown in the following screen shot:


When you dive deeper into the Azure Active Directory section of the Azure Portal, you can see that synchronization has never run, and that password sync is disabled (which makes sense at this point):


Nowhere can an option be found to enable directory synchronization, as you had to do previously before configuring directory synchronization. The only option you have is to download Azure AD Connect, using the following link:

So, let’s give it a try….

Logon to the new Azure AD Connect server, download Azure AD Connect and start the wizard. The Express installation will perform the following steps:

  • Configure synchronization of identities in the current AD forest of <your domain>
  • Configure password synchronization from on-premises AD to Azure AD
  • Start an initial synchronization (I’ll get back on this later in this blogpost)
  • Synchronize all attributes
  • Enable auto upgrade


Enter the administrator credentials of your Office 365 tenant and your on-premises Active Directory and you’re ready to go:


One remark: I unchecked the Start the synchronization process when configuration completes option, and checked the Exchange hybrid deployment checkbox.

The reason I unchecked the synchronization process is that I do not want to synchronize all objects from my on-premises Active Directory to Azure Active Directory, but I only want to synchronize objects from the OU=Accounts container in my Active Directory domain.

If you want more information regarding the Exchange hybrid deployment and the write-back of properties from Azure AD to your on-premises Active Directory, you can visit the following Microsoft article:

Exchange Server Hybrid Deployments –

When the configuration is complete you can click the Exit button and you’re good. Please note that at this point no synchronization has taken place yet.


To make a selection based on Organizational Unit for synchronization you can start the Synchronization Service Manager (miisclient.exe) which can be found in the C:\Program Files\Microsoft Azure AD Sync\UIShell directory.


Click on the Connectors tab, and select the Connector (sometimes referred to as Management Agent) for your on-premises Active Directory. Click properties and select Configure Directory Partitions. Here you can select which containers should be used for synchronization to Azure Active Directory, as can be seen in the following screenshot:


Start the initial Azure AD synchronization using the Start-ADSyncSyncCycle -Policytype Initial command and wait for the results:


When checking the Azure Portal, you can see that user objects are now synchronized from the on-premises Active Directory to Azure Active Directory, as shown in the following screenshot:



So, in short, previously you had to enable directory synchronization manually using the Set-MsolDirSyncEnabled command (or using the wizard in Office 365), but this is no longer the case. When running Azure AD Connect, directory synchronization in your tenant will automatically be enabled.

Exchange 2016 CU9 and Exchange 2013 CU20 released

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.

Schema changes

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

Exchange 2016 Database Availability Group and Cloud Witness

When implementing a Database Availability Group (in Exchange 2010 and higher) you need a File Share Witness (FSW). This FSW is located on a Witness Server which can be any domain joined server in your internal network, as long as it is running a supported Operating System. It can be another Exchange server, as long as the Witness Server is not a member of the DAG you are deploying.

A long time ago (I don’t recall exactly, but it could well be around Exchange 2013 SP1) Microsoft started to support using Azure for hosting the Witness server. In this scenario you would host a Virtual Machine in Azure. This VM is a domain joined VM, for which you most likely also host a Domain Controller in Azure, and for connectivity you would need a site-2-site VPN connection to Azure. Not only from your primary datacenter, but also from your secondary datacenter, i.e. a multi-site VPN Connection, as shown in the following picture:


While this is possible and fully supported, it is costly adventure, and personally I haven’t seen any of my customers deploy it yet (although my customers are still interested).

Windows 2016 Cloud Witness

In Windows 2016 the concept of ‘Cloud Witness’ was introduced. The Cloud Witness concept is the same as the Witness server, but instead of using a file share it is using Azure Blob Storage for read/write purposes, which is used as an arbitration point in case of a split-brain situation.

The advantages are obvious:

  • No need for a 3rd datacenter hosting your Witness server.
  • No need for an expensive VM in Azure hosting you Witness server.
  • Using standard Azure Blob Storage (thus cheap).
  • Same Azure Storage Account can be used for multiple clusters.
  • Built-in Cloud Witness resource type (in Windows 2016 of course).

Looking at all this it seems like a good idea to use the Cloud Witness when deploying Windows 2016 failover clusters, or when deploying a Database Availability Group when running Exchange 2016 on Windows 2016.

Unfortunately, this is not a supported scenario at this point. All information you find on the Internet is most likely not officially published by the Microsoft Exchange team. If at one point the Cloud Witness becomes a supported solution for Exchange 2016, you can find it on the Exchange blog. When this happens, I’ll update this page as well.

More information

Using a Microsoft Azure VM as a DAG witness server –

Dutch and Belgian Community Event on February 22

On February 22 the Belgian and Dutch messaging and collaboration experts are organizing a community event. Join MVPs like Jaap Wesselius, Dave Stork, Michel de Rooij, Steven Van Houttum and Michael Van Horenbeeck along with well-respected experts such as Thomas Verwer, Kay Sellenrode and more for this first “interland” between the Belgian E-Communications & Collaboration Community and their Dutch counterpart(s). We will start the evening with an introduction by Etan Basserie, a Program Manager from the Azure AD Team at Microsoft in Redmond.

It will be an evening full of technical deep-dives and interesting discussions.
Fujitsu Netherlands has been so kind to allow us to host our collective event in their offices in Maarssen. You can find the Fujitsu offices at ‘Het Kwadrant 1, 3606 AZ, Maarssen’.

The agenda is as follows:

  • 6PM – 6:30PM: Welcome, drinks and food
  • 6:30PM – 7:00PM: Introduction/Keynote by Etan Basseri (Identity Engineering, Microsoft)
  • 7:00PM – 7:50 PM: “Still running Exchange 2010? Now what?” A sessions by Jaap Wesselius and Kay Sellenrode discussing your options, best practices and pitfalls when migrating to Exchange 2016 or Office 365. Or in other words, why or why not using Exchange 2016 in an Exchange 2010 hybrid environment.
  • 8:00PM – 8:30PM: Introduction to “HelloDoor” by HelloDoor.
  • 8:30PM – 9:30PM: “Securing Exchange Online”. This session presented by Dave Stork will cover security options to prevent spoofing of email, tools to prevent data leakage and auditing solutions. Further topics will be EOP, ATP, SPF, DKIM, DMARC, TLS, RMS and DLP to use a few acronyms. Dave’s focus will be on Exchange Online, but a lot of topics can also be used in Exchange on-premises.
  • 9:30PM-10PM: Closing drink(s) and farewell

You can register at the following meetup site:
Hope to see you all there!

Exchange and .NET Framework support

Last week I had to upgrade a few Exchange 2013 CU15 servers to Exchange 2013 CU18. In a typical scenario upgrading to a newer Cumulative Update it’s not a big deal, not even when skipping a few versions, but in this scenario most likely you will hit the following error message:


It fails during the Prerequisite Analysis with the error message

“This computer requires .NET Framework 4.6.2 ( For more information, visit:

The Exchange Server setup operation didn’t complete. More details can be found in ExchangeSetup.log located in the (SystemDrive):\ExchangeSetupLogs folder.”

Exchange Server 2013 CU18 requires the .NET Framework 4.6.2 for installation which was obviously not installed on these servers.

Continue reading Exchange and .NET Framework support