Building a mixed cloud model for SharePoint – Part 3

Followed by the two previous articles, I showed you how to set up Azure AD Domain Service (AD DS) to act as a domain controller in a SharePoint farm. During the setup, we learned some limitations in Azure AD DS (as of this article). One of them that make us feel uncomfortable is the Azure AD’s password synchronization to Azure AD DS.

It means if you want to make an Azure AD to become Azure AD DS account, you must change the existing password to the new one. For new account, changing password twice is required.

Keep track the series:

Next, per my setup, I realized that the Azure SQL Database currently is not supporting Integrated Windows Authentication mode. It means when provisioning a new SharePoint 2016 farm, the production configuration wizard tool retrieves current context of credential in Windows unsuccessfully. Due to this limitation, I had to prepare a virtual machine and ran SQL Server for SharePoint configuration database. The farm setup was completed successfully using the below model:

We are kind of good to know the possibility of the mixed cloud model. However, in a real-world scenario, there are more than using content database. In this article, let’s have more experiments with Search and User Profile.

Hosting Search databases on Azure SQL database?

Hosting Search databases on Azure SQL Database service seems not to be possible in either using Central Administration or PowerShell. When creating a Search service application, you are not given the choice to specify each Search databases. During the service application provisioning, four Search databases are created in the background. The way you can possibly do to touch Search databases is making their names friendly (by specifying the value for the parameter -DatabaseName ) in New-SPEnterpriseSearchServiceApplication .

Hence, I created a Search service application and kept it hosted on the SQL Server virtual machine. Crawling to Azure hosted content database has no issue. As long as the crawler account (which is still managed by Azure AD DS) has Full Read permission on the target web application.

You might wonder why the content database runs under SQL account but Search crawler still reaches. This does not matter. The SQL credential is used for SharePoint Web application when it needs to talk to the content database. The credential is submitted over. The identity of crawler service is not used for authentication process. It is required for authorization in order for the crawler to successfully send pure HTTP GET request to the target content source. In my experiment, there is no trick at all to make the search work.

Hosting crawl database on Azure SQL Database?

Fortunately, hosting crawl database on Azure SQL Database is technically possible. First, you need to create a blank Azure SQL database.

Then run the following PowerShell script on the SharePoint virtual machine to create a new Search crawl database.

The database was provisioned successfully. Via Central Administration, it is listed in SharePoint’s farm database.

However, when I use Get-SPEnterpriseSearchCrawlDatabase , Search only returns one database. Even if we drill down to see Search crawl database structure via Data explorer feature, we are surprised.

Let’s skip this issue. I will try to spend a little more time sometime to dig into it.

User Profile Databases on Azure SQL Database

How about running User Profile databases on Azure SQL Database? Let’s try with the following PowerShell script

Hosting User Profile databases on Azure SQL Database has no issue.  Let’s go to configure for synchronization from Azure AD DS. First, you need to enable Pre-Windows 2000 Compatible Access in Azure AD DS. There is note a remote PowerShell script you can use from your laptop. You need to log into a virtual machine (e.g. SharePoint) and install Active Directory Domain Services feature then open Active Directory Users and Computer tool. This tool is super familiar with any SharePoint and AD administrators doesn’t it?

In SharePoint 2016, there are two synchronization modes: AD Import and External Identity Manager using MIM. When testing with each of the modes, I realized that my managed Azure AD DS was under a cluster of domain controllers. The result interestingly tells me that my Azure AD DS tenant is in fact controlled by two primary domain controllers also running global catalog. Microsoft has no official information regarding how Azure AD DS is structured. What we all know right now is that Azure AD DS is a managed domain service which is quite similar to the on-premises AD.

  • Using sample FIM from this article, the sync log shows me that the FIM sync service account had no replicate directory change permission on the target domain controller. Of course, it is impossible to grant Replicate Directory Change permission with my privilege.

  • With AD Import, it seems to be fine with the

In AD Users and Computers, there is a security group named AAD DC Service Accounts. This is the group of members which are granted Replicate Directory Changes permission. Add the sync account to this group before you run AD Import sync job.

And after running the AD Import sync job, all Azure AD got synced to my User Profile. Use the simple query below against the profile database.

Pay attention to the connection details from Properties panel.

If you don’t want to play with Azure SQL DB query, just go to Manage User Profiles page and search for user profile. Once you have user profile, you can deploy My Sites for testing purpose. I’m not going to dive into details of My Sites deployment in this post. The deployment of MySite in this model is possible, without any special configuration. You just need to follow steps which you can find from the Internet. Below are a few of sources:

Hosting Managed Metadata database on Azure SQL Database

Similar to User Profile and Search provisioning, creating a blank database on Azure SQL Database and go to your SharePoint virtual machine to provision managed metadata service application whose database parameter is specified to Azure SQL database. Then create a custom list that has a Managed Metadata column to verify

I haven’t tested other service applications yet. But I think technically all are possible to be created with Azure SQL database if you follow my guidance.

Except SharePoint farm configuration database, other databases can be hosted on Azure SQL Database.


In this article, you have studied possibility of Azure SQL Database to host SharePoint 2016 databases. I’m pretty much interested in going with Azure SQL Database for a workload like SharePoint. During the experiment, there are a few things we learn from Azure AD DS and limitations with some further configuration. In the next article, let’s have some views around the architecture and pros and cons.

Go to Building a mixed cloud model for SharePoint – Part 4


Leave a Reply

© 2018 The Soldier of Fortune.