set-msoldirsyncenabled not available

March 22, 2018 jaapwesselius 5 Comments

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: http://www.microsoft.com/en-us/download/details.aspx?id=47594

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 – https://technet.microsoft.com/en-us/library/jj200581(v=exchg.150).aspx

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:

This will trigger the initial synchronization to Azure Active Directory, but won’t do any subsequent sychronizations. Use the Set-ADSyncScheduler -SyncCycleEnabled $true command to run periodic synchronizations.

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:

Summary

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

Exchange 2016 CU9 and Exchange 2013 CU20 released

March 21, 2018 jaapwesselius Leave a comment

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 CU9 download: https://www.microsoft.com/en-us/download/details.aspx?id=56718
Exchange 2016 CU9 KB article: https://support.microsoft.com/en-us/help/4055222/cumulative-update-9-for-exchange-server-2016
Exchange 2016 CU9 UM Language Pack: https://www.microsoft.com/en-us/download/details.aspx?id=56715
Exchange 2013 CU20 download: https://www.microsoft.com/en-us/download/details.aspx?id=56717
Exchange 2013 CU20 KB article: https://support.microsoft.com/en-us/help/4055221/cumulative-update-20-for-exchange-server-2013
Exchange 2013 CU20 UM Language Pack: https://www.microsoft.com/en-us/download/details.aspx?id=56716
Exchange 2013 CU20 Released – https://blogs.technet.microsoft.com/rmilne/2018/03/20/exchange-2013-cu20-released/
Released: March 2018 Quarterly Exchange Updates – https://blogs.technet.microsoft.com/exchange/2018/03/20/released-march-2018-quarterly-exchange-updates/
Upgrade Paths for CU’s & .NET – https://eightwone.com/2017/12/21/upgrade-paths-for-cus-net/

Exchange

Exchange 2016 Database Availability Group and Cloud Witness

March 14, 2018 jaapwesselius Leave a comment

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 3^rd 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.