Tableau Blog: Tableau Server on Azure


Tableau is widely known as one of the top software tools in the Business Intelligence world. For a decade, Tableau has been named a Leader in the Gartner Magic Quadrant for Analytics & Business Intelligence Platforms. Furthermore, the Tableau Server platform is simple to deploy and scale. Why not combine that with a cost-effective, high-performance cloud computing environment like Microsoft Azure? Recently with one of my clients, I had the opportunity to perform a Tableau Server install in the Azure environment and I wanted to detail some of the intricacies of that process to you all.

With Azure Virtual Machines, you can spin up instances as you need, when you need them—there are no upfront investments, hardware procurement, or physical deployment required. Together, Tableau and Azure provide a comprehensive business intelligence solution that can be implemented quickly, secured easily, scaled efficiently, and used by everyone.

When moving to Microsoft Azure, there are two types of architecture for Tableau Server: High Availability and Hub & Spoke. It was established by the Tableau Server administrators that the server is not being taxed by its users, so it is recommended that the “Hub and Spoke” strategy be deployed.


I will break down each portion of this architecture.


Azure Firewall VNet – “hub”

The Azure Firewall subnet will regulate all incoming and outgoing traffic. Azure Firewall manages the network rules and Tableau can run as a standalone server or a multi-node deployment in a peered VNet spoke—a process where two VNets connect and exchange traffic. In the diagram below, there is one hub to one spoke. Within that spoke, there is a Workload subnet in there are three VM nodes. This mirrors the current production server architecture in a way.

Tableau VNet “spoke”


Azure Bastion Service or Jumpbox

A jumpbox or a pivot server is a VM that is used to manage other systems. Once you are logged in, you can maneuver to the other servers. In this case, the jumpbox is used to manage the VMs in the Workload subnet, which encompasses three Tableau VM nodes. The administrator login will enable us to install the Tableau Server through this portal of sorts.


Load Balancing subnet

Tableau work is distributed over a cluster’s nodes using load balancing. Even when deploying a single Tableau Server node, adding a load balancer is a good idea. As you add more nodes, the load balancer will already be set up, and IP routing to the cluster will remain consistent. There are a couple of options for load balancing: Azure Load Balancer and Application Gateway.

With layer 7, Application Gateway provides the more robust features you’d expect. It is a natural recommendation for external-facing deployments because it has end-to-end SSL, an integrated web application firewall, cookie-based session affinity, and a solid SLA. Standard Azure Load Balancer is primarily for internal use in published Azure topologies, whereas Application Gateway is naturally designed for external deployments.


Workload subnet

This is where the Tableau Server lives. This can be a single- or multi-node setup. For my client, we want to mimic the existing Production environment so we will have three Tableau VM Nodes that exist in three different Availability Zones. The installation for these nodes will be similar. Once we get one full installation completed, we may be able to utilize an existing python script,, to install the Production. Additionally, this script could be used for a disaster recovery situation. This is an option that can be explored after the initial installation.


When speaking on authentication for the Tableau Server, all worlds focus on the Tableau Identity Store and how that will be configured. It is a critical part of the server install and I will detail why in the upcoming sections as well as some of the authentication options that are possible

Tableau Identity Store

One of the most commonly used authentication methods for Tableau Server is Active Directory. However, this is not an option going forward into Microsoft Azure. Tableau can be configured for the local identity store or external identity store or an LDAP server. There have been a lot of discussions about authentication options in Azure. A local identity store may not be the best long-term solution because your client will need to authenticate through SAML. The only reason why this point is being mentioned here is when configuring Tableau Server, you cannot change the identity store once you have completed installation. If you need to change you will have to uninstall and reinstall Tableau Server.


Azure AD Alone

Azure Active Directory is the cloud-based identity and access management service. This can be used as an external identity store for Tableau Server. To do this, you will also have to utilize Azure AD Domain Services. Azure AD does not have an LDAP protocol Tableau can use to query users. Domain Services supports that action. Azure AD can also be used as the identity provider for SAML. SAML will be discussed at length in another blog.


Active Directory Hybrid Identity and Tableau Server

This strategy promotes a “lift and shift” from on-prem to the cloud. Since we are migrating in stages, this option could be utilized.

  1. Azure AD Connect: This service is used to sync user accounts, group memberships, and credential hashes between your local AD tenant and Azure AD tenant; This enables you to leverage both on-prem AD and Azure AD
  2. Azure AD Domain Services – You can extend your on-prem AD to Azure or create a new AD Domain Services forest in Azure
  3. Active Directory Federation Services (ADFS) – use this to extend the identity store beyond your firewall and provide SSO for cloud-based services via SAML

These are the options for the Tableau Server identity store. Whatever decision is made for the authentication, just go with it. If it changes, you will need to reinstall Tableau Server and redo any security on the old model.



This should provide you a general overview what to consider when migrating Tableau Server to an Azure environment. Taking these items into account will ensure that your migration goes smoothly. I will tackle SAML in a follow up blog post. Stay tuned.