If you follow my community activities and my blog, you surely know about my advocate of deploying a SharePoint farm with Azure IaaS. I wrote number of related articles about this in my blog.

Besides blogging, I came to a few annual regional conferences such as Azure Global Bootcamp and ExpertsLive Asia Pacific (aka System Center Universe) to share my experiences around SharePoint hosted on Azure IaaS. “Azure IaaS Defense In Depth” book also provided a comprehensive lab to deploy a protected SharePoint farm on Azure. These stuffs are all about provisioning virtual machines, installing and configuring SharePoint farm.

Inspired by a few customers recently asking me if they could deploy a SharePoint workload in Azure virtual machines while taking advantages of non-workload services for Active Directory and SQL Server database. Such a question is super interesting honestly, which drives me to again get my hands dirty to experiment before giving those customers an acceptable answer.

As a consultant, I wouldn’t like to answer Yes/No without a reasonable answer. When getting asked for possibility, answering Yes/No makes you look like an amateur. Perhaps if you don’t have experience, go test if possible. Otherwise, give your honesty.

This blog series would answer the following questions:

  • Can I host my SharePoint database in Azure SQL Database which is non-IaaS service?
  • Can I use Azure Active Directory Domain Services (ADDS) for my SharePoint farm?
  • Can both Azure SQL Database and Azure ADDS be used?

Mixed Cloud Model

Mixed cloud model might be thought of a hybrid cloud model. However, personally to my definition, I tend to think about a mix between IaaS and PaaS in some ways. This is not a new model of course. In real-world deployment, you may see a case in which your workload is run under Azure virtual machines while the database management system is a PaaS service (e.g CosmosDb or Azure SQL Database). Another case is a system whose application layer uses Azure App Service while its database is hosted on an SQL Server virtual machine.

The illustration above shows you example of reference architecture of the mixed cloud model:

  • Two Azure VMs are responsible for application hosting
  • Azure Load Balancer is positioned as an Internet facing web proxy.
  • Azure SQL Database is used mainly to store database whose endpoint is exposed to the application.
  • All resources are inside a virtual network (note that Azure SQL Database can be put inside a virtual network as of this article).

Reasons may vary. In one of most recent cases, a customer needed to use Azure SQL Database but the virtual network capability was still under the preview phase which didn’t meet go-live deadline so they decided to go with running SQL Server on an Azure virtual machine. The application was run under Azure App Service. Another reason is the chosen platform that Microsoft is not strong, e.g. Node.js. In fact, Azure App Service supports Node.js but due to unconfident feeling, running Linux virtual machine is preferred.

Mixed Cloud model can be good for temporary deployment when something is still under Preview phase in Azure. It is also one of the strategies of cloud transformation when you are in the middle of Lift-and-Shift and Cloud Optimization. Money, Transition and Adoption are always used to explain.

Build a SharePoint base virtual machine

Building a SharePoint base virtual machine can be done with a SharePoint template that is available in Azure marketplace. In this article, I’m going to use SharePoint Server 2016 Trial template. This template already has prerequisites of SharePoint Server 2016 so you don’t have to necessarily run Preparation tool to install. Creating a SharePoint 2016 trial template can be done via Azure Portal, PowerShell, CLI or Visual Studio with Azure ARM template. In this article, I’m going to use PowerShell to get things done quickly.

Note that this script doesn’t create any network security group with the purpose of allowing network traffic through. After the script gets done, go remote your newly provisioned virtual machine to verify.

Deploying Azure AD DS

If you are an Azure geek, having worked with Azure long enough, you would be familiar with Azure AD, at least you know what it is. Azure AD is a core cloud-based identity management service which is used by almost Microsoft cloud services such as Office 365, Dynamic 365. Azure AD is also a main identity of Microsoft Cloud platform. It offers developers number of capabilities to build an authentication engine, or integrate with almost SaaS cloud services. Some of capabilities I’ve been engaged to work include Azure AD, Application Proxy, Single Sign On, Multi-factor.

This page gives more details on Azure AD https://docs.microsoft.com/en-us/azure/active-directory/active-directory-whatis

However, its name does not mean you can do everything you want like the on-premises Windows Server Active Directory. You could still create a ‘domain controller like’ in Azure AD and join a virtual machine to that managed domain controller via a pre-configured FQDN. However, it was not something you wished due to many limitations. At that time, Azure AD was not designed for corporate centralized directory and identity management. Fortunately, based on the core of Azure AD, plus, perhaps from Microsoft’s customer voice, Azure AD DS was invested to bring to you a real domain controller deployment. Unlike Azure AD supporting for application-aware identity and authZ/auth0 integration, Azure AD DS offers you domain join, group policy, LDAP, Kerberos & NTLM authentication that let you feel like you fully control your domain controller. Moreover, Azure AD DS can deploy directly into a specific Azure virtual network.

In this article, I’m not going to go deeper into Azure AD DS. The purpose is to help you quickly deploy a mixed cloud model and to give more experiment on new stuffs introduced right here. Deploying Azure AD DS can be done via Azure Portal, PowerShell or Azure CLI. In this post, let’s focus on PowerShell. Azure AD DS is part of Azure AD so you need to install Azure AD module in PowerShell. Simply run on your computer  Install-Module AzureAD and  Install-Module AzureADPreview -AllowClobber . After module installation, connect to Azure AD with command line Connect-AzureAD  like you do with Login-AzureRmAccount .  The Connect-AzureAD without TenantId specified is only used to connect to Azure AD where your account belongs to. Azure doesn’t know which specific Azure AD tenant you need. Run the following command line to connect to the tenant of the target subscription:

If you use Microsoft account (e.g. your_name@live.com) refer to this article  to connect to correct Azure AD.

If the output returns a value in Tenant Domain you configured before, you’re done.

For every access request to an Azure service, you firstly need to authenticate with Azure AD because Azure AD is also the identity management system of all Azure services hosted in Microsoft Azure. In my case, because I want to use create a new object (considered kind of identity application) in Azure AD, I have to create a new service principal. This service principal is to allow Azure AD to be able to give my Azure AD DS access to needed resources.

If you’ve worked with Azure AD before, you may not know where to get the application ID  “2565bd9d-da50-47d4-8b85-4c97f669dc36″ because you may think that you do need to create and register a new application before grabbing its ID. In fact, this App ID is the Domain Controller Services application which is given by Microsoft. The command above does the job of adding this enterprise application.

There might be some obsolete articles out of the Internet using AppID instead of ApplicationID. If your Azure AD module’s version is  2.0.0.131 then ApplicationID is the correct one.

Now let’s define the whole script to make the deployment done quickly.

The creation of Azure AD takes around 15-20 minutes. Go to Azure Portal at this link to check the status. You can also go to the resource group to check all resources related being provisioned.

Joining SharePoint to Azure AD DS

Once Azure AD DS is completely provisioned, it it considered a domain controller. It is not like the one in on-premises which you have to promote to domain controller after installing Active Directory Domain Services role. There are a couple of steps to configure DNS server before joining. From Azure AD DS, you are given two DNS server addresses

Click Configure DNS servers to update custom DNS servers. You will be redirected to the corresponding virtual network. You can run the following script

Your virtual machine would need to be restarted to update DNS. After that, use RDP to connect and check with ipconfig /all  or ping  . Resolvable domain name is not enough right now. What you need to do is synchronize the AD account’s password from Azure AD to Azure AD DS. Steps to enable password synchronization are all straightforward. Log into http://myapps.microsoft.com/ with your Azure AD DS admin account you created previously (in my case it is jimmy@s-15.asia). Once this account password gets updated, wait 3-5 minutes and then RDP to the SharePoint virtual machine.

Enter the newly updated password and pray for the successful result. Restart computer to get thing done!

Managing Azure AD DS via Azure Portal looks completely crazy because you don’t see many things to do. The best way is to install AD DS tool in the virtual machine to manage. It can be the SharePoint virtual machine you created, or a new virtual machine.

Not all the features can be done via AD Administrative Center. For example, you cannot create a new user from this tool because in reality user identity is stored and managed via Azure AD.

Conclusion

I do hope the first part of the series is helpful for you, at least the portion of Azure AD DS deployment using PowerShell and some notes to consider. From the article, we must know that Azure AD DS can play as a domain controller in the SharePoint farm. In the next part, let’s have a look around Azure SQL Database to see if it can be involved.


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