Planning Your Deployment
It's pretty straightforward to install and configure a single-computer deployment of Tableau Server. This chapter gets you started.
Questions you need to be able to answer
Before you run setup, you must have answers to the following questions:
How will you license your installation?
How will users authenticate to Tableau Server?
How will Tableau Server access data sources?
What hardware will you need?
This chapter will help you answer these questions.
The Tableau Server licensing model
Tableau Server can be licensed under two models: term and perpetual. And in addition to choosing a model, you need to choose a license metric: user-based or core-based. The combination of model and metric you choose depends on how you want users to interact with your server, and also how you plan to build out (scale) Tableau Server for more capacity in the future.
There aren't different versions of Tableau Server for each license option. Instead, the product key that you enter when you install Tableau Server determines how Tableau Server is configured.
License model: term or perpetual
Term licenses, also sometimes called subscription licenses, allow you to use and update Tableau Server until an expiration date. Perpetual license do not expire, but you must purchase Support and Maintenance services to have ongoing access to product updates and technical support.
License metric: user-based or core-based
In addition to the license model, your license is defined by the metric that permits use of Tableau Server: user-based or core-based.
User-based licenses specify exactly how many named users of each type (Creator, Explorer or Viewer) you can have for Tableau Server. With these licenses you can deploy Tableau Server on a single computer or on multiple computers in a cluster, as long as the total number of users doesn't exceed what the license allows.
Each user who interacts with Tableau Server content—publishes, views, downloads, etc.—must sign in to the server. (We discuss later how you can create user identities on Tableau Server and options for how users can sign in.) A single user can work on multiple sites and projects, and can even have different permissions on different sites. From the licensing perspective, a user is simply a user identity on Tableau Server.
With a core-based license you can run Tableau Server on a specific number of CPU cores. For core-based licensing, you can install Tableau Server on a single-node or multi-node cluster, as long as the total number of cores for all of the nodes does not exceed the number of cores that you have licensed. Core-based licensing imposes no constraints on the number of user accounts in the system. This can include the Guest users who are allowed to interact with embedded views, but who don't have to sign in to Tableau Server in order to do so.
An important consideration when using a core-based license model will be performance, because a set number of cores can only support so many users without having an impact on server responsiveness. Depending on the complexity of the workbooks on the server, extract usage, user concurrency, and the depth of interaction, you can support 10 and 100 users per core and still expect reasonable performance.
Note that if you intend to install Tableau Server on a virtual machine (VM), check the specifications for the VM, which might be listed using vCPUs.
Choose a license
The type of license you choose depends on how your users will work with Tableau Server. Here are a couple of scenarios:
You have a small workgroup where only a handful of users will publish and view workbooks. In this case, you might start with a user-based license for 10 users (or more if you have more users).
You have a small workgroup of users who will publish and manage workbooks, but who will make views available to hundreds or thousands of people in the company. For this scenario, you might start with a core-based license that allows unlimited users.
You can change the license metric used—for example, you can move from a user-based to a core-based license if the number of users you need to support grows.
If you're still deciding what type of license to get, define the scenario you anticipate and contact Tableau to discuss what license and metric will best accommodate your needs.
Identity storage: Use Active Directory, OpenLDAP, or use local identity store?
You must choose one of these models during the installation process; you can't change these identity store methods later unless you reinstall Tableau Server. If you are working with your IT department, you'll want to connect with the identity management folks to help plan and implement your identity store model.
Does your organization run Active Directory? If so, then you probably want to use it with Tableau Server as well. If your organization doesn't use Active Directory (or OpenLDAP), then you'll configure Tableau Server to use local identity store.
The identity store method you choose determines how you plan for user provisioning, site and server management, and data and client access models. Mixed-mode functionality—where some users are managed in Active Directory and some are managed by the local Tableau server computer—is not supported. If you have some users who are not part of your corporate Active Directory and need access, then you must provision and manage all users locally.
This section describes both options and how to plan for either identity store model. How you plan to authenticate users will inform how you manage identities. We cover the basics of what authentication means and how Tableau Server can integrate with other authentication technologies like Kerberos, OpenID, and SAML.
What is authentication?
Authentication confirms a user's identity: who the user is. Any time you sign in to a server or a website, the credentials you provide (typically a user name and password) authenticate you.
Tableau Server has its own user identity and authentication system that lets you determine who can sign in to Tableau Server. Every user who accesses the server must be represented as a user identity—an account—on the Tableau server. (Actually, the Guest user feature we've mentioned allows anonymous user access to the server, but for now, let's not include that in the discussion.)
As an administrator, you determine how you want to create these user accounts in Tableau. The process of creating users and assigning permissions is called provisioning. Provisioning users is the first of several steps where the question of using Active Directory vs. local identity store comes in.
Your IT department might be happy to know that they can also provision users with the Tableau command line tool (tabcmd) or with the REST API.
Local identity store
If you're installing Tableau Server in an organization that doesn't run Active Directory or OpenLDAP, or these options are not otherwise not available for you, you must configure Tableau Server for local identity store.
When you configure Tableau Server with a local identity store, then Tableau Server will authenticate the users. This means that when users want to access Tableau Server, Tableau Server prompts them for a user name and password and determines whether they're authenticated.
When you configure Tableau Server with local identity store, you can provision users either by creating them in the server web admin tool one at a time, or by importing user names and passwords via a CSV file.
Single sign-on: OpenID, SAML, and Kerberos authentication
After installation, you can configure Tableau Server with a single sign-on (SSO) provider. With SSO, users don't have to explicitly sign in to Tableau Server. Instead, the credentials they've used to authenticate already (for example, by signing in to your corporate network) are reused to authenticate them into Tableau Server, and they can skip the step of entering a user name and password in Tableau Server.
Tableau Server supports several types of SSO solutions: OpenID, SAML, and Kerberos. We don't include explicit instructions for how to configure any of these SSO solutions in this guide. But it's important to understand how the decision about whether to use Active Directory or local authentication affects SSO:
OpenID requires local identity store.
Kerberos requires Active Directory identity store.
SAML works with either identity store type.
For more information about these options, see the links at the end of this chapter.
Another factor to consider before you run setup is data access. Understanding how your users will access data is important for these deployment variables:
Run As service account. The Run As service account is a Windows account that Tableau Server uses ("runs as") when it accesses resources on the server. For example, Tableau Server reads and writes files on the computer where Tableau Server is installed. From the perspective of Windows, Tableau Server is doing this as the Run As service account.
By default, the Run As service account is set to a local account called Network Service. This is fine for some scenarios, generally simple ones. However, Tableau Server often must access external data sources such as relational databases, network shares, or cloud data. Tableau Server will try to access these resources as the Run As service account, so that account must have permissions to those resources.
Hardware planning. An important factor in hardware planning is to project how Tableau Server will access, store, serve, and manage data. The next section discusses how Tableau Server manages data and how that can affect how you plan your server configuration.
Where is your data?
Tableau is designed with the assumption that you have data in many places and that the data sources can be of various different types—spreadsheets, databases, cloud-based storage, etc. If your organization has data in only one place, you can simplify your Tableau Server deployment by optimizing for that single data source.
However, if your users will connect to multiple disparate sources of data, you'll need to determine how Tableau Server will sign in to the various data sources and how "fresh" the data served by a given source needs to be for your users.
Data "freshness" and performance
All workbooks that your users create in Tableau Desktop start with data. Unless they are accessing a local file on their computer, they connect to a data source—such as a relational database, a file on a network share, or data in the cloud. A primary goal of self-service analytics is to provide an experience where users can get into the creative flow of asking and answering questions in real time. To enable flow, your users need fast and uninterrupted access to the most relevant data.
If data is incomplete, outdated, or if users must wait for it to load, your organization will not realize the full potential of Tableau self-service analytics. Balancing data freshness and performance relies in large part on whether users are interacting with live data or if they are working with extracts.
Understand the difference between extracts and live connections
Let's take a moment to describe the difference between extracts and live connections, then we'll explore their trade-offs and benefits.
A Tableau Server extract is a snapshot of data that has been copied from a data source. Extracts provide great performance because the extract contains all the data that the workbook needs. Think of an extract as a cache of data loaded into Tableau Server for quick querying, analysis, and visualization.
The other option is a live connection. When a Tableau data source is configured for a live connection, Tableau Server runs a query against the data source and caches the data. This means fresh data is always available as users request it. You can configure how long this cache is kept or whether it should be refreshed each time a user loads a view that uses live data.
When users publish a workbook to Tableau Server, they can choose how they want that workbook to access the data source:
Extract the data and package it with the workbook as a
.twbxfile, and then publish the packaged workbook. When other users view the published workbook on Tableau Server, Tableau Server renders views using the embedded extract. In this case, each workbook has its own extract, even if different workbooks began by connecting to the same database or other source. The extract can be refreshed, either manually (by the user) or automatically (on a schedule).
Extract the data and publish the extract to the server as a saved data source. When other users view the file on Tableau Server, the server renders the view with the extract that is hosted and managed on the server. In this case, you can configure Tableau Server to refresh the extract from the underlying data source, either manually or on a schedule. Hosting data as an extract on Tableau Server reduces duplication and reduces traffic to the underlying source database. A single reused extract will be cached by server and will load much faster for subsequent viewers.
Use a live data connection. Publishing a workbook that uses a live connection creates a Tableau Server data source. The data source configuration includes a pointer to the data source and can include the author's embedded (and encrypted) credentials to the data source. Alternatively, workbook authors can leave their credentials out of the workbook. In this case, other users must enter credentials when they open a workbook that then connects to the data source, or the data source can use the Tableau Server account (the Run As service account).
In the context of data freshness, the freshest data will be served by a live connection to the data source. However, if there's a lot of data, if the data requires complex queries, if the database is slow, or if the data doesn't change frequently, performance is often better with an extract. If users do work with extracts, we recommend that you create a schedule for refreshing the extracts.
When to use extracts
Users need to do deep analysis of huge amounts of data stored on traditional databases, or on data resources that have high latency or are overtaxed.
Users need offline access to the data, such as when they're traveling or presenting off-site.
Users are making analytic decisions that don't rely on real-time data.
User need to work with data that's consolidated from multiple sources.
Users are prototyping an analysis using a small set of data. This keeps development fast and can reduce the load on the network and on databases. (When they finish developing, they can switch to a live connection.)
As the Tableau Server administrator, you can create a refresh schedule for extracts. During a refresh, Tableau Server queries the live data source and updates the extract with the latest version of the data. The only practical limitation on extract refresh frequency is the performance of your underlying data source—that is, how quickly it can run the queries needed to update your extract. (In general, we recommend that you schedule extract refresh jobs for off hours, because a refresh job can be CPU intensive.)
When to use live connections
Your users require up-to-the-minute or real-time data to make business decisions.
You have database hardware dedicated to servicing Tableau Server analysis. The query load on a database is primarily a function of the complexity of the workbooks. For complex workbooks, the query load on traditional relational databases can be significant, because calculations are offloaded to the database.
You host your data in a database that is optimized for real-time analysis. Most big data and cloud database solutions are designed for real-time, ad hoc analysis. Others, such as Hadoop, can be latent and have different performance results depending on factors like the size of the data, the connection method, and the configuration.
Data source authentication and the Run As service account
Your instance of Tableau Server must connect to external data sources (unless all of your users will save and embed an extract in their workbooks).
Tableau Server can connect to more than 40 different data sources. All data sources require some kind of authentication for access. While a full accounting of each source and its authentication scheme is outside the scope of this document, we can make some generalizations about how Tableau Server connects to data sources.
The point of this exercise is for you to determine if the default Run As service account, configured as the local Network Service account, will suffice for your needs. For many customers, the default Network Service account is not sufficient to access the data their users need. As a result, the Run As service account must be updated with an Active Directory domain account.
By default, the Run As service account is set to a local account called Network Service. Use the default Network Service account when:
You are using local authentication for Tableau Server.
All users in your organization include extracted data in the workbooks that they are uploading to Tableau Server.
External data sources that your users access through Tableau Server do not require Windows NT integrated security or Kerberos. In most data-access scenarios, Microsoft SQL Server, MSAS, Teradata, and Oracle databases require Windows NT integrated security.
It's important to understand the security implications of the account that Tableau Server uses for the Run As User. Specifically, if Tableau Server must access other servers, file shares, or databases in your organization, then the account that is configured for Run As User can be used to access those resources. The account that is configured for Run As User must also have elevated permissions to the local Tableau Server computer. A general best security practice is to limit the scope of all user accounts to the minimum required permissions. We make the same recommendation as you plan for the account that you will configure as the Run As User.
Files on network shares
Data that resides on network shares—files such as CSVs and Excel files—that are configured as live data connections are accessed by the Run As service account.
While the Network Service account can be used to access resources on remote computers within the same Active Directory domain, we do not recommend using the default account for such scenarios. Instead, configure a domain account for Run As User if Tableau Server must connect to files on network shares in your organization.
Relational databases and cloud data
Many relational databases do not require Run As User credentials for authentication. The same is true for cloud data sources. Instead, users usually access these data sources with their own credentials, or you as administrator can set the credentials on the data source configuration in Tableau Server.
That said, some relational databases (for example, Microsoft SQL and MSAS) can only be accessed by Tableau Server when the server is configured with a Run As service account. And many databases allow users to specify the Run As service account when they publish a workbook.
Kerberos delegation (usually configured with Microsoft SQL Server) requires a Run As service account that is a member of the domain. Therefore, you must change the default Run As service account.
Run As service account guidelines
If you are operating in an environment where a majority of your data sources are authenticated in the context of Active Directory, you will probably need to configure the Run As User to use a domain account, not the local Network Service account that's the default. You can update the Run As User anytime, but given how essential this account is to the proper operation of Tableau Server, we recommend setting it appropriately it as part of your deployment plan.
Before you install Tableau Server, you should create a domain user account that you will configure as the Run As service account.
Follow these guidelines for the account that you will create for Run As User:
If you are requesting an account from an IT professional who manages users in your Active Directory, then tell that person that you need a service account for Tableau Server. "Service account" is IT-speak for the type of account that the Run As User represents: it's an account that services use for authentication and access to resources on a network.
Create a dedicated account in Active Directory for the Tableau Server Run As service account. In other words, don't use an existing account. By using a dedicated account you can be sure that the data resources that you permission for Tableau Server are only accessible by Tableau Server Run As User.
Do not use an account with any kind of domain administrative permissions. In fact, when you create an account in Active Directory, create a domain user. Do not add the account that you create to any Active Directory security groups that needlessly elevate the permissions for the account.
Permission the data sources in your directory for this one account. As noted, the account that you'll use for Run As User needs only Read access to the appropriate data sources and network shares.
Make a note of when the password for this account is set to expire. Create a calendar or task event so you are remind of the password change. You will need to update the password in Server Configuration whenever the user account password is updated.
When you run setup and specify your Run As service account, the TabAdmin process will grant permission to the user on the computer where Tableau Server is running. In some cases, you might need to set additional permissions. Those cases are described in the Running Setup chapter.
Operating system requirements
Tableau Server is available in a 64-bit version. You can install Tableau Server on Windows Server 2019, Windows Server 2016, Windows Server 2012, Windows Server 2012 R2, or Windows Server 2008 R2. You may install Tableau Server on virtual or physical platforms.
What kind of server hardware will you need? To install Tableau Server, you must have a computer that meets the minimum hardware requirements. Setup won't run if the computer you are installing onto doesn't meet these requirements.
The minimum hardware requirements specified in the above link are really just recommended for trial and feasibility testing purposes. We don't suggest running Tableau Server in a production environment with the minimum requirements. Instead, we have a minimum recommendation for hardware:
CPU: 8-core, 2.0 GHz or higher, 64-bit
RAM: 32 GB
Free disk space: 50 GB
Ideally, you can dedicate a computer to only host Tableau Server. For example, to achieve the best performance, the computer hosting Tableau Server should not also be running other applications or running a full antivirus scanning solution. We also discourage running other databases on the same computer. If your server computer needs to run other applications as well, you need to account for their load on the shared resources as you plan your server sizing.
To determine if the recommended minimum hardware will work for your goals, consider how your users will interact with Tableau Server. This guide assumes you are installing Tableau Server for a user base of up to 100 users. However, hardware requirements will depend more on active simultaneous users, also referred to as concurrent users. The requirements also depend on how frequently Tableau Server is called on to refresh extracts that those users rely on to make business decisions.
Our minimum hardware recommendation should be sufficient for single-server installations where up to 10 active users simultaneously interact with content on Tableau Server. The recommendation also assumes a low frequency of extract refreshes that are all scheduled during off hours.
If this sounds like your scenario, then skip the rest of this section, set up your hardware, and continue to Running Setup.
If you're not sure whether the minimum hardware recommendation meets your needs, read the rest of this section for guidance on how to determine the correct hardware specifications for your deployment.
This section focuses on where you might consider increasing essential hardware resources based on a handful of critical variables to optimize for specific usage profiles.
Heavy workbook processing
If you expect to have more than 10 active simultaneous users interacting with content on the server, or if those users are all interacting with live connections, consider increasing the server RAM to 64 GB. Also consider converting popular data sources to extracts, in which case an installation with 64 GB of RAM typically can service up to 60 active simultaneous users.
Frequent extract refresh
As discussed in a previous section, users accessing Tableau content frequently interact with data that is extracted and managed on the server. How often Tableau Server refreshes these extracts is configurable for each data source. When possible, we recommend running scheduled extracts during non-work hours, but for mission-critical data, this is not always feasible.
Each extract refresh process consumes an entire processor thread and is RAM intensive. The more frequently extracts are refreshed, the more cores and RAM you should add and dedicate to the extract refresh process. Particularly, in the default server configuration, if you expect to schedule multiple extract refreshes simultaneously, they will run serially and queue until a core and Backgrounder process is free. If you need to extract multiple refreshes simultaneously, then you should configure Tableau Server to use two or more Backgrounder processes. For more about this, see the links at the end of this chapter.
Our minimum recommended hardware assumes that you are refreshing the majority of your extracts during non-work hours. This approach is considered a low refresh data use profile.
A moderate data refresh use profile is when you refresh extracts hourly. In this case, we recommend at least 14 cores and 124 GB of RAM.
If you have more than 500 extracts, or if you refresh extracts to support live data analysis, this is considered a high data refresh use profile. In this case, you are exceeding the scope of this guide and you should work with a Tableau consultant to design your deployment.
The more extracts you host on Tableau Server, the more physical hard disk space your computer will require. Centrally managed extracts reduce duplication that is common with workbooks that have packaged data.
Continue to Running Setup.
OpenID Connect. Information in the Tableau Server Help about letting users sign in to the server using an OpenID Connect provider such as Google.
Kerberos. A section in the Tableau Server Help that describes how to let users sign in using Kerberos, as configured on the local network for your organization.
SAML. Information in the Tableau Server Help about using SAML (Security Assertion Markup Language) for single-sign.
Improve Server Performance. Suggestions in the Tableau Server Help for how to help tune Tableau Server performance, including how to balance the demands of user responsiveness and data freshness.