Often we heard enterprise Tableau customers had all kinds of challenges to upgrade their Tableau servers. This webinar invited the super experienced Tableau server admin talking about our own experiences of upgrading very large Tableau servers.
For those who use Tableau Online, you do not have to worry about server upgrade. But for those who have on-premier servers, the server has to be upgraded to leverage Tableau’s new features.
1. How often to upgrade Tableau server?
We did a quick pull during webinar with 50+ responses. The data shows 50% Tableau server upgrade once/year, 30% twice/year and 20% 3+/year.
We have two super large Tableau servers. One server got upgraded 2 times/year and another one 3-4 times/year.
We strongly recommend most Tableau server admins should upgrade your servers 2+ times/year as the server admins are between Tableau’s new features and your user adoption of those features.
2. What to do pre-upgrade
Strategic Upgrade Approach
Planning – minimum disruption to users
Upgrade test:
Test in Prod Like env and Data
Run all extracts once to compare failure rate and avg execution time
Make publishers accounted for their own workbook test/validation
No need to over test
Platform Health Check
Server State
Memory related issues
Are services crashing
Do we have adequate storage
Can natives/firewall cause an issue
Tips: Very often Tableau sever upgrade have issues due to things outside Tableau app – means platform level issues. Upgrade more often actually help to resolve those issues.
3. What to do During Upgrade
4. What if Upgrade Failed
Re-Cap:
Upgrade Tableau server twice a year
Choose the latest version when upgrade
Pre-upgrade tasks include system health, OS health and test
Test new version in Prod like server env with prod like dataset
Know what to monitor and how to monitor during upgrade
Ensure a good backup before upgrade and be prepared to reinstall server from scratch and restore with backup data as plan B
Tableau’s nested project feature has been there since v10.5, however I only start to see more people to use it after v2020.1’s new lock permission feature – allowing permissions being locked independently at any nested project. This blog focuses on nested project features and next blog will talk about how lock works with nested project.
Only admins can create top level project (I am going to write a new blog to show you how to break this rule to allow all publishers be able to self-serve creating new top level project). Of course, admins can also create nested projects
In additional to the admins, the main reason to have nested project is to provide more self-service so each project owner or project leader can project nested projects. Of course, a project leader/owner can only create nested project within the project he/she is owner/leader of
Whoever created the project becomes the owner of the project – this role is still true for creating nested project.
Example of how nested project works?
Let’s say a top level project Finance has one owner (John) and two leaders (Sherry and Mark). All of them can create as many nested projects within Finance. Sherry created nested project Finance – GL, Mark created nested project Finance – AP. Who is the owner/leader for Finance – GL and Finance – AP?
Finance – GL: Owner is Sherry. Inherited project leaders are John and Mark
Finance – AP: Owner is Mark. Inherited project leaders are John and Sherry
How the nested project permission works if it is moved to another top level project?
It is a little bit hard to understand how it works but I think that it is well designed to avoid more confusions. Here is how it works. Let me still use the above example
For Finance – GL: Owner is Sherry. Inherited project leaders are John and Mark. Let’s see Ivy was also added as project leader since Ivy is responsible for GL area. Now this Finance – GL nested project is moved from Finance to General Ledge top level project.
Finance – GL under General Ledge:
Owner for Finance – GL remains unchanged still Sherry.
Project leader Ivy is still the project leader (no change)
However the initial inherited project leaders (John and Mark) are not project leaders for this Finance – GL anymore
The owner and project leaders of General Ledge now become the new inherited project projects for Finance – GL
All existing content permissions within Finance – GL remains unchanged no matter Finance – GL is customizable or locked unless General Ledge is locked and has the flag to apply locking to all its sub-project permissions.
What are the setup to publish the nested project permissions?
Re-Cap:
Use nested project to organize your content
Project owner and leader can create nested project
There is no limit of how many nested project within one project
There is no limit of how many nested level although more than 3 levels can be hard to manage
Be aware of additional setup to publish to a nested project – the publisher has to have ‘View’ permission to all its parent level projects
Data security has been the top concern for Tableau deployment. This is summary of Row Level Security webinar by Zen Master, Mark Wu: What is Tableau Row Level Security (RLS)? What are the implementation options? How to decide which option to use? How to test RLS? How to improve RLS workbook performance?
Tableau handles data security by permission and row level security.
Permission controls what workbooks/views that users can access and can do.
Row level security controls what data sets the users can see. For example APAC users see APAC sales, EMEA users see EMEA sales only while both APAC and EMEA users have the same permission to the same workbook.
There are mainly 3 options to implement row level security. Sometimes all of those will be used in the same workbook/data source:
ISMEMBEROF: The most popular option – use server groups to control row level security
USERNAME(): Use separate entitlement table to control. Use Multiple Table extract will make performance a lot better for most cases
CONTRAINS(): Concatenate all allowed usernames in one comma-delimited field in your data.
ISMEMBEROF implementation steps:
Create or Sync server groups
Create calculated field : ISMEMBEROF(‘Group-AMER’) AND [Order_Region] = ‘AMER’ ….
Add the calculated field to data source filter (strongly recommended) or workbook filter and select ‘true’
Publish data source but do not give end user ‘Connect’ permissions at all to the published data source. Only give ‘View’ and ‘Connect’ to the content creators in your team
Publish workbook and embed password in Authentication (embed password is absolutely necessary)
Set workbook permission to all the groups used
Make sure Web Editing as No, download as No if use workbook filter used
USERNAME() implementation steps:
Create calculated field: USERNAME() = [Username] (note: [Username] is the server logon user’s name not Display name. Ask your server admin to confirm what is the server’s username on your server. Some implementations use email address, others may use employee_id, etc.)
Add the calculated field to data source filter (recommended) or workbook filter and select ‘true’
Can make extracts after joining
Join Option 1: Cross-DB traditional left join if you can
Join Option 2: Relationship Join
Join Option 3: Blend (be aware of limitations)
Publish data source but do not give end user ‘Connect’ permission at all
Publish workbook and embed password for Authentication
Set workbook permission to all the groups above
Make sure Web Editing as No, download as No if use workbook filter used
Pls use multiple table extract for better performance!!!!
Multiple Table extracts will have better performance for most use cases.
CONTAINS([User strings], USERNAME())
Concatenate all allowed usernames in one comma-delimited field in your data, and then use CONTAINS([user strings], USERNAME())
Although it is string comparison but Tableau somehow handles string comparison much faster than most of databases.
Which option to go? The driving factors are performance, data preparation efforts and ongoing maintenance of the data/entitlement table. Often combine to use in the same datasource or workbook
