High Performance Technologies - High Performance Technologies Blog , Tableau Server

Why "If It Ain't Broke" Is the Wrong Strategy for Tableau Server

Tue, 21 Apr 2026 11:48:18 -0500

There is a version of this story that plays out more often than it should.

A company's Tableau Server has been humming along for years without issue. Then something changes — an SSL certificate expires, an OS patch is applied, a staff member turns over — and suddenly the server is down. The team calls Tableau support. Support pulls up the version number and says, essentially: You are too far out of date, and your version is no longer supported.

That is not a hypothetical. It is what happens when people mistake "if it ain't broke, don't fix it" for an infrastructure strategy.

The good news is that this outcome is entirely preventable — it just requires putting a plan in place.

The Pegboard Problem

"Wait," you might say. "Why should we mess with things that are working just fine?"

Because no connected system operates in isolation, and most people are only in control of a subset of the infrastructure, not all of it. There's an illustration we use to drive this point home.

Imagine, if you will, all the different pieces of your analytics infrastructure as pegs on a pegboard. Every individual aspect of your infrastructure — Tableau Server, the Tableau Support contract, the hardware it's running on, Tableau Desktop, database drivers, the data warehouse itself, authentication configuration (I'm looking at you, Snowflake) — these are the individual rows of holes on the pegboard.

The versions of those components are the columns—and versions tend to increase over time, so you can also imagine the columns as "when was this version released." Some components iterate slowly (like Tableau Server's supported version) and some iterate quickly (like Tableau Server itself), which shows up as peg holes being closer together on some rows and farther apart on others.

The pegs themselves are placed in the holes for which versions are relevant for each component. Remember, you probably only control some of these pegs.

Now, imagine rubber bands looping around the pegs that need to work together.

If the versions of the components are compatible, those pegs are closer together, and the rubber band can fit around all the pegs without snapping. It might be totally slack, with room to give as things change. Or it might have a little bit of tension, but nothing the rubber band couldn't handle. As long as the tension in the rubber band isn't too much to handle, everything works.

But when one of those pegs drifts too far — especially the ones that aren't in your control — the rubber band stretches and, eventually, snaps. And if you've ever been hit by a rubber band when it snaps… it doesn't feel good.

That is the situation organizations find themselves in when deferred maintenance finally catches up: a down server, no vendor support, and a team scrambling to reconstruct years of configuration decisions from memory.

Scope and Size: A Better Way to Think About Updates

Not all updates are created equal. Two factors determine how much work any given update actually requires:

Scope describes the types of things that change from your current version to the target version.

A patch release typically carries only bug fixes — small changes, narrow impact.
A minor release introduces new features, and may require a bit more: it may contain several bug fixes you need to communicate to your stakeholders, but it also contains new functionality to assess and potentially implement. Users love new features!
A major release with backwards-incompatible changes may require an adjustment to your infrastructure's architecture, or configuration reviews — and as a result, it probably requires more planning and preparation than the other two scopes.

Size describes how many of those changes accumulate before you act.

If you update monthly, a given release might carry a few bug fixes and one small feature.
If you update yearly, you're handling 12 months of patches, features, potential regressions, and breaking changes.

Together, scope and size reflect the amount of work required to perform the maintenance, as well as the potential amount of risk that work carries. A sustainable maintenance strategy keeps both as small as possible.

What Deferred Maintenance Actually Costs

When you defer updates long enough, something beyond technical debt accumulates: organizational debt. The team member who understood the original configuration moves on. Documentation grows stale. And when something eventually breaks — because something always eventually breaks — no one knows where to start.

Consider the practical math. A customer running a 2021 version of Tableau Server who needed to reach a current 2025 release was technically dealing with one upgrade. But that upgrade contained four years of accumulated changes:

dozens of individual patch releases rolled into one,
over 200 new or updated features,
more than 20 features deprecated,
all in all, roughly 315 items to consider (excluding bug fixes).

That is a fundamentally different undertaking than a routine maintenance window.

How Often Should You Update?

The answer depends on your risk tolerance, your team's capacity, and how critical Tableau is to your organization — but the options break down clearly.

Monthly is the lowest-risk posture.
- Each release carries the least accumulated change.
- Scope is narrow, size is minimal, and updates become routine enough that they stop feeling like events.
- If something does go wrong, the workarounds are inconvenient, but not show-stopping.
- This is the option that makes Tableau Server maintenance boring — and boring maintenance is exactly what you want.
Quarterly is manageable.
- Contains a larger update window and will contain a few months of patches.
- You will typically stay within the same major version, avoiding the impact of several backwards-incompatible changes at once.
- You may have more workarounds to manage, depending on the scope and size of the changes between versions.
Semi-annually is better than nothing.
- If you're not changing major versions during one maintenance window, you will be during the next one.
- The scope expands accordingly: what was a recurring maintenance task starts to look more like a recurring project.
Ad hoc or annual updates lead to more work, at best.
- These often require project planning, stakeholder communication, thorough testing cycles, and meaningful downtime risk.
- The gap between versions is no longer a maintenance consideration — it is the project itself.
- If you approach these tasks as if they are routine maintenance instead of projects, you may only learn about the risks after they've materialized. By then, you've committed to dealing with the impacts, even though they can't be quantified until everything is back to normal.

Making Updates Part of the Routine

The organizations that handle Tableau Server best are not necessarily the ones with the most sophisticated environments.

They are the ones that treat updates as routine rather than optional.

They have a maintenance schedule. They stick to it. And if something goes wrong, it doesn't take a ton of effort to remediate, because the size and scope of the maintenance was appropriately constrained.

Need Help Getting Current?

If your Tableau Server is behind on updates — or if you are not sure where it stands — High Performance Technologies can help you assess the gap and build a path forward. Whether that means a one-time upgrade to get you current, or an ongoing managed services arrangement to keep you there, we can scope what makes sense for your environment.

Learn more at highperformance.tech/services or reach out directly at highperformance.tech/contact-us.

Get Started Now

Introducing ViewAs: User Impersonation for Tableau Server

Mon, 16 Feb 2026 11:57:00 -0600

I've had the pleasure of working with Tableau Server administrators for over a decade and a half now, and one question that comes up somewhat frequently is some variation of: "A user says they can't see this dashboard, but from my end it looks fine. How do I see what they see?"

In most cases the answer, until now, has been: outside of Tableau Desktop, you can't. Not easily, anyway.

The Typical Approaches

How you handle this depends on your environment. If you're embedding Tableau in a custom application, your wrapper app can impersonate the user and render the viz as them. This works well when it's available, but it requires that you have embedding set up in the first place and that your portal actually implements impersonation. If you're not in that situation, it doesn't help you.

For row-level security issues, the workbook author or other Creators could troubleshoot in Tableau Desktop. This is effective, but now you're potentially pulling someone else into the investigation and waiting on their availability.

You can also check effective permissions in the Tableau Server content permissions dialog. It's easy enough to access, but interpreting the results takes some practice — and it only tells you about permissions, not what the user actually experiences when they navigate the server.

My go-to approach has been scheduling a Zoom call for a screenshare. I like this because you can troubleshoot user behavior and technical issues at the same time — sometimes the problem isn't permissions at all, it's just that the user doesn't know where to click. But scheduling a call isn't always convenient, and sometimes you just need a quick answer without the coordination overhead.

Introducing: ViewAs

ViewAs is a small application that lets Tableau Server administrators view the server exactly as another user sees it — through the actual UI, not just the API.

The workflow is simple:

You authenticate as yourself
Select the user you want to impersonate from a searchable list
Launch a session

From there, you see what they see. Their navigation, their row-level security filtering, their dashboard behavior, their effective permissions at every level. When someone reports they can't see the Sales Dashboard, you can verify in thirty seconds whether the issue is permissions, RLS, or something the user is doing on their end.

This is also useful for validating RLS across tenants, testing how dashboards appear for different user roles, verifying that new users have appropriate access on their first day, and documenting access controls for audit purposes. Automation is still the right answer for anything you need to do repeatedly at scale — but manual validation lets you iterate quickly when you're building something new, and it gives you peace of mind that what you've built actually works the way you expect. Both have their place.

Tableau Cloud

This version of ViewAs is for Tableau Server on-premises deployments. Tableau Cloud has tighter restrictions around impersonation — API impersonation requires Connected Apps with JWT authentication, which is significant overhead just to debug a permission issue. I'm exploring options for a Cloud version, but the architectural constraints are real. If you're a Cloud customer running into these friction points, I'd like to hear about your specific scenarios.

Getting Started

ViewAs is available now for free at viewas.hpt.tools (email required for download).

It works on Mac, Windows, and Linux, and takes less than a minute to set up. If you're using Tableau Server authentication, you can sign in with your credentials directly. Otherwise, if you are using SSO or another method, you'll need a Personal Access Token.

Questions? Reach out at hello@highperformance.tech.

Tableau Server Log Reference

Tue, 03 Feb 2026 13:31:00 -0600

Tableau Server writes logs across dozens of folders in different formats. It can be a bit tough to find info on which logs you need, given the context you’re trying to find. Tableau's documentation covers it, but you have to cross-reference multiple pages to find what you need.

This quick reference should help!

Don't forget to bookmark this page so you can easily find it when you need it.

Log base path on Linux: /var/opt/tableau/tableau_server/data/tabsvc/logs/

Log base path on Windows: C:\ProgramData\Tableau\Tableau Server\data\tabsvc\logs\

Note: if you installed to a non-default location, look there for the relevant data → tabsvc directory, and you’ll find the logs directory inside.

Quick Troubleshooting

Symptom	Logs to Check
Users can't log in	`authnservice/`, `vizportal/`, `httpd/`
Dashboard won't load	`vizqlserver/`, `dataserver/`, `hyper/`, `httpd/`
Extract refresh failed	`backgrounder/`, `hyper/`, `filestore/`
Search not working	`indexandsearchserver/`, `noninteractive/`
Cluster node unhealthy	`tabadmincontroller/`, `clustercontroller/`, `tabadminagent/`
TSM commands failing	`tabadmincontroller/`, `tabadminagent/`, `appzookeeper/`

Process Log Reference

Core Request Processing

Process	Log Folder	Check When
Gateway	`httpd/`	User-facing errors, SSL problems
Application Server	`vizportal/`	Web UI errors, REST API failures, login page issues
VizQL Server	`vizqlserver/`	Viz rendering failures, session timeouts, memory issues
API Gateway	`apigateway/`	REST API v3.x errors (check out http first)
Data Server	`dataserver/`	Published data source issues

Data & Query Processing

Process	Log Folder	Check When
Data Engine (Hyper)	`hyper/`	Extract query failures, Hyper crashes, memory exhaustion
File Store	`filestore/`	Extract replication failures, missing extracts, sync issues
Cache Server	`cacheserver/`	Query cache issues, Redis failures, session data loss

Background Jobs

Process	Log Folder	Check When
Backgrounder	`backgrounder/`	Extract refresh failures, subscription failures, job queue backlog
Flow Processor	`flowprocessor/`	Prep flow execution failures, flow step errors

Authentication

Process	Log Folder	Check When
Authentication Service	`authnservice/`	SAML/OIDC failures, SSO redirect loops, token validation (also check the vizportal logs)
Identity Service	`identityservice/`	SCIM provisioning, identity migration, user/group sync

Cluster & Administration

Process	Log Folder	Check When
Coordination Service	`appzookeeper/`	Cluster quorum, split-brain, leader election failures
Cluster Controller	`clustercontroller/`	Repository failover, node health, process state transitions
Repository	`pgsql/`	Database connections, replication lag, failover problems
TSM Controller	`tabadmincontroller/`	TSM command failures, config apply errors, backup/restore, service startup errors
TSM Agent	`tabadminagent/`	Service startup/shutdown failures on specific nodes (also check the individual service's logs)

Search & Indexing

Process	Log Folder	Check When
Index and Search	`indexandsearchserver/`	Search not returning results, indexing delays
Non-Interactive Container	`noninteractive/`	Background indexing failures, metadata operations

Ingesting Logs with ts-olly

If you want these logs in Splunk, Elasticsearch, Loki, or similar, you'll need to parse multiple formats — log4j, log4j2, httpd, JSON — and keep up as Tableau adds or changes processes over time.

ts-olly handles this. It reads Tableau's config files to learn the log formats automatically, detects new processes and their configs as they appear, and outputs unified JSON. You don't have to build or maintain parsers.

ts-olly -node node1 \

-logsdir /var/opt/tableau/tableau_server/data/tabsvc/logs \

-configdir /var/opt/tableau/tableau_server/data/tabsvc/config

MIT-licensed: github.com/highperformance-tech/ts-olly

Need help interpreting what you're seeing in these logs? We've helped dozens of organizations troubleshoot complex Tableau Server issues — from memory leaks that only show up under load to intermittent authentication failures that disappear when you're looking for them.

If you're dealing with a tricky performance issue or need someone to review your server health, feel free to reach out — happy to point you in the right direction.

What does it take to stand up a Tableau Server?

Fri, 15 Oct 2021 16:44:33 -0500

Understanding your Use Case

Possibly the most important step in planning out a Tableau Server deployment is to understand your use case. What are the end goals you want to achieve? You’ll want to consider things like how many users will be accessing your server, as well as what they'll be doing. You'll also want to understand what kind of data they'll need to have access to. Which users will just be viewing content, and which users will need to author their own workbooks?

Since Tableau Server is designed as a scalable web application from the ground up, it provides customers a great deal of flexibility and is an ideal platform for deploying on-premise or in the cloud. It’s important to choose the right hardware configuration that will work best for your use case as well. Typically it's good practice to separate the processes from the data source because they'll be on different servers. For example, you can keep your data on an internal database and configure the Tableau Server to access it from there.

Tableau Server can be installed on either Windows or Linux. There are pros and cons to both operating systems, and which you’ll choose should largely depend on whether or not the other related applications infrastructure in your stack is are native to Windows or Linux. It’s also important to consider which system your IT resources are most familiar with. If you're trying to share data with others and need a more robust server, you will probably want to go with Linux. If your BI needs require high-capacity servers with large amounts of data that need a lot of processing power, Windows is likely to be the more cost effective option.

While the following list certainly isn’t exhaustive, these are some of the questions our server experts at High Performance Technologies ask when planning a new deployment:

1. Will your server be running on Windows or Linux?

2. What version of Tableau Server will you be using?

3. What kind of Tableau license types will you need?

4. Is your server hardware on-prem or in the cloud?

5. Is your data on-prem or in the cloud?

6. Will you be working with protected data?

7. Should you utilize SSO or SAML?

8. What resources (CPU and memory) should you provision for your server?

9. Will you be using any database technology?

10. Will you be using any data warehousing technology?

11. Do you have resources and skills available for ongoing management of your server?

12. How quickly do you need to deploy a solution?

Once you've made the decision on your operating system then it's time to install Tableau Server! We will describe how you can go through each step of installing and configuring Tableau Server so that your server is ready for use in production.

We'll begin by logging into the server and making sure the system software is up to date. You can choose which services you want Tableau Server to run on Windows or Linux by using their respective user interfaces in order to install them onto the server. The main components we recommend installing to get started are the server, the data engine, and Tableau Prep. Once all of those pieces are installed, you’ll need to configure them so that they work together properly in production. You can do this by configuring each service one at a time inside their respective UI interfaces which will be located under Administrative Tools. This blog post won't discuss how to configure Tableau Server in depth, but it will explain the steps involved with each process.

The first step is to open up Tableau's configuration file which can be found at C:\ProgramData\Tableau\Tableau Server\. This is where you'll find all of your server configuration settings including users and groups, workgroup mode, and ports. If you need to modify any of these settings then this is the place where you will want to go first.

After that's finished then it's time to configure Tableau Server by opening up its UI interface which can be found at C:\Program Files\Tableau\. Once you’re inside the interface, it's time to configure your data engine which will be used by Tableau Prep and other services that need access to databases like PostgreSQL, SQLite, Oracle, MySQL, etc. You can do this by using the "Configure" button on the dashboard to open up your configurations.

It’s important to configure which port you’d like Tableau's data engine to run on and which databases it will need access to. Since we recommend that you set up your database server using a separate server instance, we’ll focus on configuring Tableau's data engine. Both Tableau Server and TSM require an available TCP port for you to access them. During installation, TSM defaults to port 8850, and the Tableau Server Gateway service defaults to port 80. Keeping both of those ports open before installation is the easiest way to ensure this goes smoothly.

Lastly, you’ll want to configure Tableau Prep which will allow you to schedule extract refreshes and cleanse our data from the servers. You can do this by going through the server tree on the left-hand side of the UI interface in order to find "Prep Service." Once you've found it then hit on its corresponding Configure button. Tableau Prep has a large number of configuration settings so it will take some time to go through them all in order to get the service configured properly in production. This blog post assumes that you'll be running Tableau Prep on its own instance of Windows Server for each component, but if not then these configurations can also be found by going into the Tableau Server UI interface.

Once you've configured all of your settings then it's time to start up each one of your services so that they can run properly in production. You can do this from inside the respective UI interfaces, accessed under Administrative Tools for Windows or Application Menu for Mac.

Finally, you’ll need to configure Tableau Server so that your users can access it from a web browser. This will require you to have Domain Admin permissions in order for users to be able to authenticate against Active Directory. You can configure this setting by going into the Tableau Server UI interface and finding "Tours & Messages." Once you've found it, click the “Configure” button.

Once you've configured all of your settings, we recommend testing out to make sure that everything is working properly before deploying this instance of Tableau Server to production.

After you've tested everything out and confirmed that it's working properly, you’re ready to deploy this instance of Tableau Server to your production environment! You can do this by copying over your files from the "Staging" directory on your development computer to the "Production" directory on your production computer.

Once you've moved all of your files over, it's time to give yourself access before installing Tableau Server onto your new server instance. You can do this by going into Administrative Tools for Windows or Application Menu for Mac and finding each respective service's UI interface inside their corresponding directories (i.e. Tableau Server UI interface will be found under Administrative Tools on Windows or Application Menu for Mac, etc.).

After you've given yourself access through the service's respective user interface, install and configure your new instance of Tableau Server by double-clicking on its corresponding MSI installer file, which you can find in each respective service's directory.

Once you've installed Tableau Server, then it'll ask for some information about your new instance of the software. These configurations can also be found by going into each respective service's user interface under Administrative Tools on Windows or Application Menu for Mac. We'd recommend taking a look at this blog post to help guide you through the installation process.

This blog post is designed to help you plan, install and configure Tableau Server. It's important that your use case be well-defined before starting this process so that you can ensure the best possible experience with regard to performance and usability for your end users. If you're not sure where to start then just reach out! We want nothing more than for our customers' experiences to be exceptional when it comes time for them to deploy their new instance of Tableau Server in production. So go ahead - let us know if we can answer any questions or provide assistance during the planning phase (or anywhere throughout) by contacting our team here at High Performance Technologies.

Get Started Now

Best Practices for Upgrading Tableau Server

Wed, 13 Oct 2021 16:59:18 -0500

Why You Should Upgrade

As you grow your business and your needs change, it may become necessary to upgrade from the version of Tableau Server that you started with. Newer versions of Tableau Server may introduce new features and if you want to take advantage of those features, then you need to upgrade your server. Other times, there are bug fixes and performance improvements which could dramatically improve your work experience!

Upgrading can be a significant undertaking because many aspects of the current environment are likely customized or configured specifically for the current version of Tableau Server. In addition, there is no “one-size fits all” approach when upgrading an existing deployment; each situation has unique requirements and considerations. The process can also take time—anywhere from a few hours up to several months depending on how complex the environment is—and resources must be dedicated towards this effort during that period.

Creating a Strategy and Plan

Upgrading your Tableau Server is not a difficult process if done right! It's important to make sure you have a strategy and plan in place before starting the upgrade. The first thing that you need to do when planning your Tableau Server upgrade is figure out what Tableau Server version you are currently running. You will also want to collect information on the hardware specs of the existing server and any other software or applications that are installed on it. This way, when you do make a new Tableau Server machine, you can try to match those specs as closely as possible. Tableau Server is installed on top of an operating system, which means that you will need enough RAM and disk space for both Tableau's requirements in addition to the OS'.

Once you have all this information collected together, it’s time to think about what version of Tableau server you will be making. Tableau Server comes in several different versions depending on the components, security features and support that is required for your organization. You should also think about how Tableau Server fits into your existing IT infrastructure as well as other networked technologies, such as Active Directory or Single Sign-On (SSO) systems. This information will be useful when planning Tableau Server upgrades.

You should also make sure you have backups before upgrading Tableau Server because there's always risk involved when modifying such an important system with lots of data and features. Make sure you test the upgrade on an identical instance beforehand so that when it comes time for the real thing, all will be well.

Completing the Upgrade

When it is time to actually upgrade Tableau Server, one of the first things that you need to do is make sure that your Tableau Server machine or machines are taken offline. This means shutting down all Tableau services on each server and then making a copy of the existing data before you start the upgrade process.

The steps to upgrade Tableau Server from here are relatively simple. You will need to download the appropriate installer from your account, and use it to install the new version on a fresh instance of Windows or Linux server.

When you install Tableau Server, you can license it either online or offline. If your server is connected to a network that allows you to access the internet, you’ll want to license Tableau Server online. On the other hand, you may have security or regulatory requirements that don’t allow your Tableau Server to be exposed to the internet or require you to have a proxy in place. If that’s the case, you will need to do an offline activation (you may also find this blog post useful: How to Stand Up a HIPPA compliant Tableau Server). This essentially requires someone to behave as a manual proxy themselves. It’s easier to license your Tableau Server online, so go that route if you are able to.

Once Tableau Server has been upgraded, you will need to migrate your data from the old Tableau server to the new one. Tableau provides a command line tool for this process that is simple and straightforward to use, but some Tableau versions require additional steps. The Data Migration Tool can be used with any version of Tableau Server, but anything older than Tableau Server 2018.x requires that you use Tableau Prep Conductor to migrate data before the upgrade can be completed or on Tableau Data Extracts (TDE) files created with a version of Tableau Server earlier than 2017.

The Importance of Upgrading Frequently

While it can be hard to keep up with the latest features and bug fixes Tableau releases, if you don't upgrade regularly, your server will become outdated and less useful over time, and may even start slowing down or even crashing unexpectedly. Thankfully when you upgrade to a new version of Tableau Server, all sorts of old bugs are removed from the codebase and they never come back!

We recommend creating a schedule to upgrade your server on a regular basis so that you always have the most current version of Tableau Server available. This way, you'll always be able to get the most out of your server environment!

If you’re interested in learning more about whether it’s time for your organization to upgrade Tableau Server, please feel free to reach out. Our expert resources have been working with Tableau for over 13 years and are happy to assist with your next upgrade or helping you figure out how to navigate your evolving Business Intelligence needs. You may also want to consider automating your upgrades as well as your deployments and backups using our infrastructure management service, Vizstack.

Get Started Now