Meet the Penguins!

Posted on June 21, 2017 by paulbanoub

OK here we go. Iron Viz competition time. I don’t viz that much so pleased to dust off Tableau Desktop and have a go. This competition is all about the natural world. A very interesting theme for me being a massive nature fan.

1. The Idea

I love nature. Thinking of a theme I reached back into childhood memories and for some reason I thought of long afternoons with my family at the zoo. Aside from the usual animals we always used to make a beeline for the penguins, something that still happens when I take my own family to the zoo. Everyone loves penguins!

However, I don’t think that many people know just how many different flavours of penguin there are. They live in varied locations, come in a host of different sizes and looks and not all of them live in cold countries. They do all stink though.

So I thought I’d use Penguins of the World as my subject for this viz. And here it is.

Go take a look at the viz!

2. Data

I got the data from a single source- https://seaworld.org/en/animal-info/animal-infobooks/penguin/

References to sited data is always good to see

Although I didn’t conduct any lengthy data validation exercise I was given some degree of confidence that the website has a detailed references section, siting the data sources. That’s always good to see and something that is mandatory in scientific papers and such like.

Now there’s tons of penguin data available out there. But I really didn’t have the time to spend days looking for that perfect data source. I also didn’t want to spend days transforming the data before I started vizzing so I settled on this one pretty quickly. Then it was a copy and paste into Excel and I was off.

Always be on the lookout for good images to incorporate into your viz

One thing I did like was the fact that this page had some cool drawings of each penguin species. That instantly got me thinking of using them as Tableau shapes. It’s always a good idea to be on the lookout for images and drawings that can you can incorporate into your visualisations.

3. Viz Design

Now I’m probably not the only person in this competition to be heavily influenced by the master of these kind of visualisations, Sir Jonni of Walker. (@jonni_walker). And with that I thought I’d steal like an artist and try to emulate him.

Key design choices were to use a black background, with plenty of large images and the use of BANs (Big Assed Numbers) as callouts. Things that Jonni does all the time and that really create a visual impact. I also wanted to utilise the penguin images as a “penguin picker” to create some interactivity.

I also wanted a map to be a main feature of the viz as maps are not only informative, but visually striking, highly customisable and also act as a canvas on which to overlay images (in oceans etc.). I had a problem at first with the fact that Antarctica was one of the main locations, and that meant the bottom of the map had a straight edge, which looked ugly. This meant the map would have to meet the bottom of the viz to draw attention away from the abrupt edge.

The IUCN scale

I was pretty pleased with the highlighted IUCN status of each species. The icons looked nice and almost acted as a traffic light theme. Jonni thought they should be greyscale but I overruled him. Pfft – what does he know anyway?

In terms of Tableau content, only a couple of charts to show population, location, height and weight; but that was fine. It didn’t really need anything else.

I also wanted to include a section on famous penguins but it ended up overloading the viz and spoiling the theme. Although it did make me smile. Bonus question – can you name all of these famous penguins?

How many of these famous penguins can you name?

I also considered the use of an embedded YouTube video but decided against it.

I had fun choosing the title font, something that I think can make a huge difference to the viewer if chosen well. Regular fonts were somehow boring, and fonts with penguin characters looked too cluttered. I finally managed to settle on an Austin Powers style font, and then had the idea of alternating the colours to give that penguiny feel. I like it!

In the end I think the final result was ok. However this wasn’t one that I enjoyed. See below.

4. Challenges

This was my first viz in a while. I’ve spent the last 3 years knee-deep in Tableau Server and have a crazy busy job building a Tableau Centre of Excellence, supporting thousands of demanding users so I’m the first one to admit I don’t have the Tableau Desktop skills of people like Adam Crahen, Neil Richards, Pooja Gandhi et al.

The standard of skill out there in the community is crazy good. And that really was the main challenge. I found this viz a fairly stressful experience, it made me feel like a newbie all over again, simply because I’d be putting this out there against some stunning competition. I even considered not entering for a while. But hey, that’s not what the Tableau community is all about so I thought I’d have a go at it.

As mentioned earlier, I was deliberately trying to emulate Jonni’s style. Now that proved to be pretty difficult. I managed to create something reasonable, and fairly quickly, and began thinking to myself that hey this is a piece of cake, Jonni who?? But then it got harder. My ideas began to dry up and I found myself staring at an okay-ish viz but being unable to take that next step to make it better. Felt like vizzers block.

And that’s when I realised that the people who create these REALLY good vizzes have a lot of inherent natural skills and imagination that folks like me lack. So I gave Jonni a call and asked his advice. He came back with a number of suggestions, none of them earth-shattering, but much more subtle and delicate. Making the map larger, bringing highlight colours out from the penguin plumage were a couple of suggestions that made a huge difference to the impact of the viz. My point here is that the real geniuses of visual design have these thoughts occur naturally and without significant effort, folks like me have to learn them, or at least work a little harder than some others.

But hey, IronViz (and any vizzing) is all about learning. So I’m good with that.

Another challenge was that the Tableau part of this was pretty easy. That’s obviously great and what we want from our favourite application, but in terms of this viz I spent more time in image manipulation tools than in Tableau. And that really did detract from enjoyment. Come on Tableau! Make it harder for us to complete our vizzes!

5. Analysis & Story

So what can we take from this story? Here are some of the key observations that Tableau has allowed me to glean from the dataset.

All penguins live in the southern hemisphere, and some in hot countries
There are some seriously big populations, although some are endangered
They range from massive to teeny tiny
Main predators are Leopard Seals & Sea Lions
There are not one, but two penguin days in the calendar
- Penguin Awareness Day (20th January)
- World Penguin Day (25th April)

So that’s it. I hope you enjoy the visualisation. If you do then please consider voting for me in the IronViz competition. And thanks to Jonni Walker for providing advice for this viz. Top man.

Good luck to all the other entries this year. Especially blinders like this from Ken Flerlage. – The Killing Fields – Viz / Blog.

Hmm. After all that writing I could do with a chocolate biscuit. Now which one……

Regards, Paul

The Three Levels of Tableau Support

Posted on January 12, 2017 by paulbanoub

Hi all,

Let’s talk a bit more about how to build a top Tableau support team. This post focuses on the support my team provides to our user base. At the moment we have just over 1000 Tableau Desktop users, and approximately 8000 active users on the server every month – that’s a lot of demand for our services.

Now users can be a pretty demanding bunch, with myriad questions, queries and problems. And we are busy. So how do we ensure that users get the level of support they need? Well we provide 3 levels of main support, with the objective being to ensure that the type of user query / issue is directed to a channel that gives it the appropriate level of attention. This ensures an efficient use of my team’s valuable time, and critically it cuts down the traffic to our email inbox which is always a good thing.

Some of the support options for our users

Level 1 – Man down!

Red alert! Something is busted and it needs to be looked at now! For this we need any incident to be logged in a trouble ticket system, with appropriate priority and detail. We use Service Now for this (many other tools available).

So if users think Tableau is broken or they need some immediate help then they log a ticket. This is mandatory. We need to track and log the progress, and the data is audited regularly. No ticket, no fix. We obviously don’t wait stubbornly for the ticket though, if there’s a big issue we investigate while the incident is logged.

Once the ticket is logged it flows through our regular support flow. First my Level 1 team will take a look and see if there’s an easy fix. If they can’t fix it then it’s an escalation to my more skilled Level 2 team, and then a potential escalation to my main Level 3 team for the trickier issues. There may be a future post coming about effective incident management, so I won’t go into detail here.

Some users don’t like us mandating that they raise an incident ticket. But it’s the only way to ensure traceability of problems.

Level 2 – It can wait

Sometimes users have problems or requests for assistance that are not so time sensitive. Maybe a development dashboard has broken, or someone needs help from the team to perfect that Pareto chart, or hey – maybe they just wanna talk about how much they love Tableau (it happens!)?

Book your appointment with a Tableau Dr.

That’s where a Tableau Dr. Session is needed. We dedicate 3 half days a week to Tableau Dr. Sessions. Users log onto our community page and can book their session from a list of available slots. If the next slot is in a couple of days then they have to wait to be seen. Providing this structure to the sessions is critical as it allows my team to keep control. Before we implemented the structured sessions we were getting peppered with do-it-now requests for Dr. Sessions. That meant my team was context switching all over the place and other projects were being impacted.

Providing structure also makes users understand this is a finite resource and thus they are more appreciative of this dedicated time with my Tableau experts.

Level 3 – Let’s talk about Tableau, baby

Next level of support is for general chat. Could be a question about functionality, or a point about performance, or a geeky joke, or someone just wanting to ask a question about our upgrade strategy – could be anything really.

That’s where our Lync Group Chat comes in. We’ve generally got a couple of hundred users on the chat channel at any one time so it’s a decent forum for such questions and banter. It’s great for my support team to see a question get asked, and then before we have a chance to pick it up, another user has provided the answer – a self healing community – IT support nirvana!

Wanna chat Tableau? Use our Group Chat

What’s in it for me?

These support options ensure that each query gets an appropriate response. If it has all hit the fan, then we act quickly. If it needs more care and detail, then we book that time, and if it just needs someone to talk to then we’ve got a community of people ready to give that data hug. It also means we get hardly any emails. And email is a dreadful means of logging an issue, as there’s no traceability or feedback. Users only get annoyed when they feel a query is being ignored, and ensuring the correct channel for a query means users get feedback as appropriate and aren’t left wondering where that email question went to.

Also my support team can plan their work and aren’t constantly context switching, one of the biggest enemies of productivity.

So that’s it. Pretty simple to implement but mightily effective. As always, ping me if you want a more detailed run-through.

Happy vizzing, Paul

Tableau on Tour Keynote Speakers – Some Suggestions

Gallery

Posted on December 13, 2016 by paulbanoub

This gallery contains 32 photos.

Hi all, I love the Tableau Conference. But I also have a lot of fun at the smaller “Tableau On Tour” events. In particular I love the keynote speeches. We’ve had some crackers recently, with particular recent favourites being Tim … Continue reading →

Empowering Your Tableau Users With Makeovers & Proactive Support

Posted on November 21, 2016 by paulbanoub

Hi all,

More on building that dream Tableau Centre of Excellence function. I’ve previously posted about how to structure your support team and ways to build user engagement with “Tableau Champions”, this post focuses on how you can use Tableau’s introspection capabilities to deliver a more proactive support function.

What is proactivity?

The traditional definition of proactive is as follows. To me it means means seeing into the future and getting to an issue before it even happens. In the world of IT Support, proactivity really is the Holy Grail, meaning the difference between a good support function and an amazing one. But it’s super-hard to achieve, especially in the complex enterprise level setups that have multiple break points. You can almost never prevent something from breaking, no matter how good your monitoring is.

What you can do is add some proactivity into the way your team operates by identifying when your users are not getting the best from your service. In Tableau Server world we have the ability to spot the following and much more.

Slow Tableau visualisations
Consistently failing extracts
Stale content

I won’t go into how to achieve this, it’s the subject of a future post. But I’ll point you in the direction of these 2 posts that should get you on the way. Go check out Custom Admin Views by Mark Jackson and Why are my Extracts Failing – by Matt Francis.

I get my team to scan our admin views, to identify those users that in our opinion are not getting the best experience they can from Tableau. If we see someone who might be experiencing consistently slow visualisations, or have regularly failing extracts then we give them a call. Often the users won’t even have a complaint. But our message is “We think you’re not getting the best experience possible, and we want to make that happen”.

The initial reaction is often surprise. “I’m ok, I didn’t raise an issue” will be a common response. But then once we’ve worked with the user, and improved their experience, you’ll find they are blown away. You may even get a call from their management!

You’ll find this kind of service is very rare in most organisations so if you can deliver it, even sporadically, then you’ll be regarded very highly.

Makeovers

This is pretty simple, if a little time-consuming. Browse the Tableau content on your server. Spot something that doesn’t look great – it might be slow, not compliant with your best practices, or just fugly. Download that content, and give it a makeover. Make it look great, maybe add some improved functionality, make it nail best practices.

This is one of my team’s favourite activities due to the reaction of the user / client. They LOVE it. It really creates a sense of engagement, the user feels that your team actually really cares about them. We’ve also had our Tableau Champions participate in Makeovers which is even better as it saves my team some cycles.

Be careful though, some user content might be confidential and the user may not appreciate an admin poking around in their data. Also, remember that by doing this you are implying a criticism of their work, so handle the communication with care and sensitivity.

Also ensure that you don’t just change stuff and then drop it back on their laps. In a self-serve model like mine users develop and support their own content so it is crucial the user knows what you’ve changed, how you’ve changed it and what benefits you feel the modification brings. Pull them and their manager into a call, run through what you’ve done and then hand it back over to them to run with it.

These have been very successful in my organisation. Users truly appreciate the help and my team has fun doing it.

So there you are, a couple of tips for adding that gloss to your Tableau support service.

Cheers, Paul

Tableau Server – all about the… Backgrounder

Posted on May 5, 2016 by paulbanoub

Hello everyone.

You may know me as a Tableau Centre of Excellence manager. That can involve a lot of paperclip pushing skills, with the real work being done by my excellent team (thx @jakesviz & The Information Lab). But I do try and get down and dirty with my lovely Tableau Server environment to keep my skills fresh. Obviously I don’t mess with it – @jakesviz gets pretty protective about his Server.

This series of posts is my attempt to shed some light on the internals of Server. Note there are many more experts in this field than me (Craig Bloodworth, Mark Jackson, Jen Vaughan, Tamas Foldi, Mike Roberts, Angie Greenhaw – to name but a few) so please do comment if anything is incorrect here. Maybe you guys could help me evolve this post?

What is the backgrounder?

The backgrounder is a process that runs as part of the Tableau Server application. As the name suggests, it handles background tasks such as refreshing extracts, running subscriptions and also processes tasks initiated from tabcmd.

Here are the backgrounder processes. The .exe file and the .war file. The WAR file is a Web Application Archive, and contains all the necessary components and resources needed for a Web Application such as Backgrounder.

On a clustered environment you’ll find these files in D:\Program Files\Tableau\Tableau Server\worker.1\bin (may vary slightly with your installation).

Other files related to the backgrounder.

Template (.templ) files – These files TBD

There are also a few .rb files in D:\Program Files\Tableau\Tableau Server\worker.1\tabmigrate\db\migrate.

And we also have a .properties file which contains all the config entries relevant to the backgrounder. It also has almost all of the other stuff that you’d find in the main workgroup.yml file which is odd. I’d have expected it to be just the backgrounder config.

Here is the location of the backgrounder log files

Here are 2 instances of backgrounder.exe running on my server (from Task Manager).

Can I mess with it?

Backgrounder can be configured. There are several settings present in both workgroup.yml and backgrounder.properties. Workgroup.yml is the master config file, and it populates the backgrounder.properties (and other .properties files) when a ‘tabadmin configure’ is run.

I don’t know what all of these do (yet) and the only one I’ve ever edited is ‘backgrounder.extra_timeout_in_seconds‘ which sets the max time in seconds that a backgrounder session can run for. Tableau kills off the session if this threshold is reached. Useful for forcing users to optimise their extract times!

I also pay attention to the ‘backgrounder.vmopts‘ parameter, as this defines the size of the java heap space for this component. All components have a vmopts setting and I’ve had to increase them on occasion due to out of memory problems.

You may also want to change the ‘backgrounder.log.level‘ if you need more debug info, although Tableau logs are chatty enough for me.

If there’s a golden parameter in this lot that you get value from then let me know in the comments.

backgrounder.deploy.dir: D:/Program Files/Tableau/Tableau Server/data/tabsvc/backgrounder
backgrounder.external_cache.concurrency_limit: 10
backgrounder.external_cache.enabled: true
backgrounder.external_cache.num_connections: 1
backgrounder.external_native_query_cache_disable: true
backgrounder.extra_timeout_in_seconds: 1800
backgrounder.failure_threshold_for_run_prevention: -1
backgrounder.jdbc.wg.connections: 8
backgrounder.jdbc.wg.idle_connections: 4
backgrounder.log.dir: D:/Program Files/Tableau/Tableau Server/data/tabsvc/logs/backgrounder
backgrounder.log.level: info
backgrounder.native_api.log.level: info
backgrounder.out_of_date_schedule_minutes: 240
backgrounder.ping_dataengine.millis_to_wait: 5000
backgrounder.ping_dataengine.num_retries: 24
backgrounder.ping_services.num_retries: 10000000
backgrounder.ping_services.time_to_wait: 5000
backgrounder.purge_directories.directories: ""
backgrounder.querylimit: 7200
backgrounder.restart_interval_in_minutes: 480
backgrounder.restrict_serial_collections_to_site_level: true
backgrounder.search_index_verification.enabled: true
backgrounder.sheet_image_api.max_age: 240
backgrounder.sleep_interval: 10
backgrounder.sort_jobs_by_run_time_history_observable_hours: -1
backgrounder.sort_jobs_by_type_schedule_boundary_heuristics_milliSeconds: -1
backgrounder.timeout_tasks: refresh_extracts, increment_extracts, subscription_notify, single_subscription_notify
backgrounder.tomcat.threads: 4
backgrounder.urlprefix: backgrounder
backgrounder.vmopts: -XX:+UseConcMarkSweepGC -Xmx512m

Note that Tableau Support don’t like you to edit config files manually, they recommend that you use the tabadmin set commands to change any parameters. They might have to change that recommendation when we see Tableau Server on Linux.

For more about .templ, Ruby & properties files check out this from Tamas Foldi.

What are the problems with the backgrounder?

Here are some of the things that can be problematic with the backgrounder.

Single Threaded – This means the backgrounder process can only run one thread at a time, a thread being a set of executable instructions that a process can perform. The upshot of this is that your backgrounder works through a queue of tasks one-by-one.

Latency – Due to the single threaded nature of backgrounder, you may see delays or ‘latency’. For example, if you have one backgrounder, and 2 tasks for it to perform at 2am, then task 2 will have to wait until task 1 has finished. If task 1 takes an hour then task 2 won’t start until 3am. This can be annoying for users that expect their data to be refreshed by a certain time.

Resource Intensive – The backgrounder can consume a significant amount of processing power (CPU) and input / output (I/O) on your server. This is dependent on the type of task it is performing. It’s not uncommon to see a backgrounder node consuming 100% CPU.

Other Stuff – The backgrounder process also does other stuff on Tableau Server that isn’t concerned with extract refreshes. For example – reaping extracts, checking disk space, synching Active Directory groups, rebuilding the search index etc. Bear that in mind when building your system. In reality these tasks don’t take up too much resource but they do take some and you should be aware.

Isolating the backgrounders

A common configuration in a clustered environment is to dedicate one of your worker nodes to the backgrounder processes. This means you can dial up the number of backgrounders and let them do their stuff without worrying about any impact on other processes. This is one of the most common performance recommendations from Tableau support.

You can also get a lot of info out of the Postgres DB relating to backgrounder usage and performance. Nelson Davis has posted a guide to getting started here.

Improvements I’d like to see

Ok so here are a bunch of improvements I’d like to see to the topic of backgrounders and extract management. I know some of this will drop in upcoming releases and some of these problems have been solved with custom solutions at some customer sites.

Alerting – Tableau Server doesn’t alert (email / IM / SMS) when a task fails. This means you’ll need to set up external monitoring to detect issues. I know Tableau are on this though so expect to see it in an upcoming version. Some people in the community have also coded their own solutions to this problem but it really should be native functionality.

Control per site – We segregate our dev / test / prod user environments using sites , all on the same server. We run 8 backgrounder processes on that server, which are shared across the tasks on all sites. As an administrator I’d really like to be able to bind backgrounder processes to specific sites. For example, 2 backgrounders on each of dev & test sites, then the other 4 dedicated to the production site. That would ensure production tasks always have enough resource to be able to execute on time.

Control per process – I’d like to be able to stop / pause / mess with individual backgrounder processes easily. It is possible – see this from Toby Erkson, but it would be good to have this as part of an administrator console or something.

Control per type / size / pattern of extracts – It would be good if I could dedicate specific backgrounder processes to particular extracts based on their characteristics. In particular I’d like to allocate one backgrounder to all the extracts that take less than 1 minute to complete. Or even use this to reward users that show diligence with their extract management by dynamically prioritizing incremental refreshes or extracts that have a low failure rate.

Better metrics – I’d like to see exactly how much CPU is taken up by a particular backgrounder process or task / schedule or per project. This would be useful for chargeback.

Dynamic reprioritisation – I love all my users. But in particular the ones that take good care of their extract refreshes. I’d like Tableau to be able to dynamically increase the priority of tasks that complete quickly, are incremental and that have a low failure rate. The message being, if you want your stuff to get the best slice of available resource then help us out with best practice.65

Disable run now – We’ve had some issues with the “run now” option that allows users to kick off an extract refresh on-demand using the UI. In particular we’ve seen some trigger-happy users bring our server down by hammering on the run now option multiple times. I’d like to disable that or maybe throttle it somehow.

Better guidelines from Tableau – The documentation from Tableau isn’t great in this area.

I have an 8 core 128GB server and run 8 backgrounders with no capacity issues. And I know of other organisations running way more than that. According to this doc I should be running between 2-4. That would be some serious under-utilization of the server. I’d like to see some clearer recommendations, maybe taking into account the variety of use cases that I’ve seen in other big enterprise deployments.

OK that’s all for now. This post could have been more detailed but I figure that I’ll get some valuable inputs from the community that will help me expand it. Actually in the time I was writing this, Mike Roberts was doing the same – check his post for some excellent info.

Cheers, Paul

The Svalbard Global Seed Vault

Posted on April 19, 2016 by paulbanoub

Hi all,

OK here we go. Iron Viz competition time. My first viz in a long time, so it’s good to get back using Desktop again. The first competition this year is the Food Viz contest!

1. The Idea

So this one’s all about food. Plenty of potential ideas here but I love to deviate from the norm and go a little bit off the wall, a little bit unusual.

I got thinking about food. But then I thought what would we do if there was NO food? If we had nothing to grow. If all the crops in the world failed overnight. What would we do? That would be a pretty bad situation for sure and someone must have a backup plan. I’m in IT as you might know so I do love a good backup plan.

And it turns out there is one. The Svarlbad Global Seed Vault. Buried 130m into the Norwegian permafrost, this building looks more like a Bond villain’s hideout than a critical storage facility. Once I saw this website my mind started racing with questions and that’s a good sign that you’ve got a decent subject for a viz.

The Svalbard Global Seed Vault

Go take a look at the viz!

2. Data

I got the data from 3 main sources.

Funding stats – https://www.croptrust.org/about-crop-trust/donors/funds-raised/
Main storage statistics – http://www.nordgen.org/sgsv/
Construction info – http://www.statsbygg.no/files/publikasjoner/ferdigmeldinger/671_SvalbardFrohvelv.pdf

The main seed stocks data

Plenty of detail in the data which gives some good potential for analysis. The main seed stats xls was pretty tricky to work with. There were a lot of nulls and gaps which I had to exclude from the dataset, and the file was pretty untidy. There were also close to a million rows in the file and that meant my pc struggled at times. All of this made manipulating the data tricker than I would have liked.

3. Viz Design

As with last year’s entry I thought I’d use Story Points again. This format has limitations but I think it works well for visualisations that answer multiple questions. In terms of formatting, I’ll be honest. I just didn’t have the time to mess about so I pretty much went with the same style that I used for my Evolution of the Speed Record viz last year.

Construction stats

I also thought I’d use a lot of images with this viz. The seed vault is an impressive construction and had a load of really good quality images available for use. I found it was useful to use a text box to provide additional commentary on each slide.

Seed vault funding

Most of the information about the seed vault made a big deal about how this was a big global project. This led me to question who was contributing and supporting the project and who was pretending to? I was pretty sure there would be a big difference in contributions, both in terms of stock and also finance.

Embedded Wikipedia page

A technique I learned last year was embedding a contextual Wikipedia page into the viz. This provides more detail for anyone wanting to know more about the data points. A good tip is to append “?printable=yes” to the URL to display a more cut down page, as well as using the mobile URL (thanks to David Pires for that tip). Some of the links didn’t work as there wasn’t a direct Wiki page – no big deal.

So there you go. An interesting story for sure and one that was pretty enjoyable to put together.

4. Challenges

This was my first viz in a while. I’ve spent the last year knee-deep in Tableau Server and have a crazy busy job building a Tableau Centre of Excellence, supporting thousands of demanding users.

So my biggest challenge wasn’t data, or thinking of a subject, it was my own lack of ability with Tableau Desktop. I was shocked at how rusty I’d become and even some basic tasks took way longer than they should have. On the plus side it was great to be back on the vizzing horse again! I’m now inspired to get stuck into some of the online training and boost my skills.

Another challenge was actually deciding to have a go. The standards in the Tableau Community have gone through the roof in the last year, and the level of quality out there is absolutely amazing. So for the first time ever I was nervous about even getting my entry out there.

5. Analysis & Story

So what can we take from this story? Here are some of the key observations that Tableau has allowed me to glean from the dataset.

The Svalbard Global Seed Vault was a decent build. Didn’t cost too much and also only took 20 months. Pretty impressive going.

Interesting to see a huge funding contribution from The Bill & Melinda Gates Foundation, larger than most of the governmental donations.

Some unusual crops stored in the seed vault. Rice at the top, and mostly concentrated around the Triticeae tribe of crop – wheat, maize etc. Surprisingly few fruit. I like blueberries so I’d be stuffed without them for my doomsday breakfast.

Probably not a surprise to see India top the seed donations chart but it was curious to see several African nations amongst the top donators.

I was surprised to see seed donation amounts tailing off big time in recent years. I wonder if that’s down to project apathy or maybe we’ve just got all the samples we need for now?

Wanna know even more? Go check out this Interactive 360 tool.

So that’s it. I hope you enjoy the visualisation. If you do then please consider voting for me in the IronViz competition.

Regards, Paul

How To Set Up Your Tableau Server Environments

Posted on April 4, 2016 by paulbanoub

Hi,

Guess what this post is about – yes TABLE CALCULATIONS…. haha. No chance. Talk to Jonathan Drummey about those. This is of course yet more info that I hope will help you guys set up a dream Enterprise Tableau deployment.

Today we are gonna talk about Environments – i.e. what Tableau environments should you create in your organisation to give your team the best chance of success and keep your lovely users happy?

As always, I’m not saying this is THE way to do it. There are tons of great setups out there. I’ll just tell you what we have. Feel free to suggest better methods in the comments.

Environments for your users

This section is concerned with environments that you will provide for your Tableau users to do their work. Typically this will follow the standard Information Technology Infrastructure Library (ITIL) environment definitions, but there are a few things you can do to add extra options for your users.

These are the environments our users have at their disposal:

Production – The main business & user facing environment. Content published here is authoritative, follows best practice (hopefully) and is actively supported.

Testing – aka UAT. Generally used for final testing of uploaded content

Development – The environment where content is first shared as part of the development process.

Scratch – An extra environment for content that doesn’t need environment management. E.g. User wants to temporarily share content with a couple of colleagues.

Providing these environments gives users crucial options and flexibility. Your Tableau service will most likely serve many different business areas and teams, each with different practices for content development and release management. Some teams will rigorously follow Systems Development Lifecycle (SDLC) processes, creating content in development, promoting to User Acceptance Testing (UAT) and then eventually to Production. Other teams are totally happy to change content directly in Production, as and when they feel like it.

Crucially we don’t mandate what our users do, it’s a self-service model and so long as they follow their own due-diligence and governance procedures then that’s cool with me. The important thing is that we give them options to work with Tableau in the way that they want. If they break anything then they know it’s down to them.

The scratch environment is an interesting concept. It started with good intentions but realistically not many people are using it. So it looks like we might bin that.

Note that we use Tableau sites to segregate our environments.

Environments for your team

This is different from the above user-facing environments. These are the environments that your team uses for the service you provide. Obviously all this costs money in terms of hardware procurement and usage, depending on the spec you choose.

Production – Main environment that serves your users. In our environment this also includes the UAT, Development & Scratch sites for users – but we class it all as production. That might seem odd, but remember that many teams will be development teams, and to them the development site / area is their equivalent of production. So if the development site is down then they can’t work.

Disaster Recovery (DR) – For use in the event of a Production outage that can’t be easily restored. Exact same spec as Production. Totally identical, so that config can be restored and this server can be used as Production. You’ll need to make sure this environment gets the same upgrades as your Production environment.

UAT – This is UAT for my team. If we want to make a change to Production, it gets final testing here. This environment is also the exact same spec as Production to ensure an accurate test. If it fails here then it’s likely to fail in Production as well. We use UAT for testing maintenance releases, config changes and other potentially disruptive non-Tableau related changes to the server. Additionally, we make this environment available to users for a couple of weeks UAT prior to releasing new versions to production.

Engineering – Lower spec than prod & UAT. For testing the latest available release from Tableau. That is likely to be a higher version than production. Is useful for spotting bugs in new versions or confirming that bug-fixes work.

Beta Test – We are proud to be part of Tableau’s pre-release testing audience. We use this server to test releases in the Beta programme. Lower spec than engineering. To the point that the server only just meets the minimum requirements.

Alpha Test – We use this to test the alpha releases or any extra work we may be doing with developers at Tableau. We love to be involved in the genesis of new functionality.

So that’s what we are lucky enough to have. It’s not perfect but it allows us to give our users a ton of flexibility in how they use Tableau, and also my own team always has a place to test new releases, plan upgrades and help Tableau with their pre-release programmes.

Interested to see what the community has in terms of environments. Let me know in the comments. Remember there are a load of other posts on this blog about Enterprise Tableau considerations.

Cheers, Paul

How To Train Your Tableau Users

Posted on January 6, 2016 by paulbanoub

Hello there,

More tips coming to help you build that dream Tableau Server setup in your global Enterprise…. This time we focus on training.

Training is a critical subject. It won’t take long before someone asks you about your strategy or what you offer so you’ll need to ensure you have a professional sounding answer. Here’s what I offer my users. Hopefully some of this will be useful.

Training gets pride of place on our community site

General Considerations

Before I get into the specific offerings there are a few things you need to consider.

Branding is Critical!

So before I describe what we offer, you’ll notice that we have snappy names for each of these offerings. It’s not just “Tableau Training”. Much of Tableau’s success is down to stellar marketing and branding – take “Tableau Dr.” for example.

So make sure you think about what you are offering, how it will be perceived and how you can maximise adoption. A memorable and consistent name is key here. Each offering also has a nice-looking one pager in our Sharepoint slide library and an appropriate user-facing page / description on our community site so that we can give people all the info at a moments notice. The more effort you put into branding the better things will be.

You’ll also find that any of these offerings are easily transferable to teams / services that may be related to your area so there are a ton of collaboration opportunities here.

Consider the Timezones

If you’re like me then you’ll have users all over the globe. That means timezone aggro. You’ll generally need to double up most of your offerings. We are based in London so we have an early session for Asia/Pacific and an afternoon session for Europe/Africa/USA. Users will really appreciate this extra effort.

Don’t Worry About Attendance

It’s important not to get fixated on how many people are attending your sessions. Sometimes we get 3 people, sometimes we get dozens. Don’t worry about it. Training 3 people is better than none. And often the smaller sessions have better engagement.

Manage the Schedule, Don’t Let it Manage You!

You’re gonna get a LOT of requests for training. Make sure you control the schedule. Don’t be scared to tell users when the next scheduled session is and that they can join it. Don’t be scheduling things on demand of users or you’ll lose control completely. If training is regular and consistent then users will settle into a pattern and you’ll be able to manage your team’s time much more efficiently.

Track your Results

Training gets a lot of focus with senior management. You (or your manager) will get asked plenty about how many people you’re training and from what business area / region they are.

As we are all data people it’s much better to SHOW the execs the data rather than tell them you’re just “doing loads of training”. We have several Tableau vizzes that track the attendance at each of our training offerings. We then blend that with staff / hierarchy data to allow detailed reporting on all of the modules. That makes a much better impression.

For example just checking our viz now I can see that my team has done 545 Tableau Dr. Sessions this year, covering 277 different individuals. That’s almost 550 man hours of training on Dr. Sessions alone. Right there, evidenced and visualised. That makes a much bigger impression with the folks at the top.

Tracking our training…

Don’t Get Lazy!

All this training can be a real time-burner. I’m sure some of you are thinking why don’t you just record the sessions and chuck the video online. And we get asked that. But never under-estimate the value of Instructor-Led sessions over videos. Our sessions are interactive, dynamic, enjoyable and make the users feel valued. They can be funny, and go in different directions according to the particular vibe in play. So don’t cave in to laziness, make sure the sessions happen and that they have that human touch.

So those are the general things to be aware of. I’ll now describe the specific options we have for training at my organisation.

Specific Training Offerings

Tableau Self-Learning Pipeline

I love self learning. Getting stuck into a manual, book or video. Or just firing up Tableau and seeing where it takes me. And you’ll get a lot of users that are the same. It’s always great to allow the self-learners to flourish, and it has the added benefit of not using your team resources.

You’ll get asked these questions hundreds of times, so make sure that you have all the relevant materials easily accessible on your community page.

What is Tableau?
How do I get Tableau?
How much does Tableau cost?
How can I get started with Tableau?

Our 101 page is top of the Community site in a super easy-to-find location. We refer our users to

Internal process to purchase / get the tool
How to connect to our Tableau Server
Tableau online videos
Tableau quick start guides
Tableau Newbie Forum Area
Tableau Starter Kits
A selection of the best blog resources such as Jeffrey Shaffer & Ramon Martinez excellent sites.

This is generally more than enough for your average self-learner to get stuck into.

Create a Training Hierarchy

Users operate at different levels of ability and interest. So it is important that your training caters for that. It also looks great if you can demonstrate an end to end understanding of training. In addition to the self-learning pipeline, we offer the following.

Tableau Desktop Training Syllabus

This is my main training programme for Tableau Desktop users. It consists of 7 modules, each conducted once a month, with a session in the morning to hit APAC users and one in the afternoon to cover EMEA/USA users.

Module 1 – Introduction to Tableau
Module 2 – Data Visualisation
Module 3 – Table Calculations
Module 4 – Blending & Joining
Module 5 – Creating Effective Dashboards
Module 6 – Performance & Troubleshooting
Module 7 – Using Tableau at THIS ORGANISATION

Our training syllabus

Content is self-explanatory from the headings, but module 7 may seem odd. This is actually a pretty important consideration in large organisations where no two Tableau deployments will be the same. There will be organisation-specific nuances or considerations in many aspects of using Tableau and our place is no different. Much of this focuses on purchasing / onboarding, getting started, and change / incident management procedures, often a source of confusion for users.

Tableau Dr. Sessions

The Doc is in!

Ok so you all know these. The famous one-on-one consultancy time that Tableau offer at conferences. That’s all this really is, but we find that our users love the dedicated time to discuss whatever Tableau related topics they want. Many often come back for repeated sessions and some are almost data hypochondriacs!

The Dr. Sessions have been a real success. People at high-pressure organisations like Investment Banks, especially senior folk, really understand and appreciate the importance of that dedicated, individual, focused consultancy time. Time is the most precious commodity in such an organisation and you’ll find that you get some serious kudos for these.

When you’re at conference and see people gagging for Tableau Dr. Sessions, imagine what that would be like at your own organisation. Super-cool aint it?

Tableau In Focus

This offering is really cool. These are monthly Webinar sessions, again one for APAC timezone and one for EMEA/USA timezone. They are conducted by experts from Tableau, tailored to UBS requirements.

Subjects have included

Five Ways to Improve Dashboard Performance
Data Blending & Joining
Table Calculations
Deep Dive into LOD Expressions
Advanced Mapping

Tableau In Focus

Again, the fact Tableau are prepared to conduct these for us not only gives us valuable extra learning offerings but makes my users feel even more special than I know they are! We get great feedback, with users thrilled that we have such a good relationship with Tableau. That all gives them confidence in our service, and that is critical.

Tableau Executive Track

OK so this is an interesting one. We get a lot of senior folk asking for Tableau training. That’s very encouraging, obviously, but your average MD isn’t gonna sit through an hour Webex on LOD calcs.

So – what we do is our “Tableau Executive Track”. That’s a 1hr session, ideally in person with my laptop where we plan to cover the following.

Overview of the Tableau Service
Introduction to the Tableau Server
Showcase of current use across the business
Demo of custom admin views & introspection
How to build basic views in Desktop

In reality we often don’t get 30 seconds into this agenda before it is taken somewhere else, at the subject’s discretion. That’s cool – it’s what senior folk do and you need to be prepared for it. But it’s also important to come armed with an agenda to show you have a plan. Don’t just rock up and say “whadda you wanna know?” – you’ll get eaten alive.

Tableau Sr. Management Training

This is a really popular training offering, with many seniors having attended or planning to attend. It shows we are putting a great deal of thought into our training and that we are flexible enough to adapt to the variety of users we have.

Content Specific Training

Sometimes we get asked, “I’ve been sent this dashboard but I have no idea how to use it”. Well that’s NOT something we assist with. Our service is totally self-serve and it’s the responsibility of the dashboard author to

Ensure they have followed best practice
Include clear instructions for dashboard use or a link to a page that has such information
Ensure that their audience is briefed and aware of the dashboard usage

This is NOT down to us. We spend a lot of time policing content to make sure that authors are mindful of this as a dashboard that is hard to understand can adversely affect perception of the tool / service as a whole.

Wrap Up

So that’s what we offer. Aint it a lot? And boy is it important to the success of your service. Training can make or break a service and between you, me and the whole Internet – a lack of training can be used as an excuse for not engaging, or not performing. It’s rare but it happens.

Training your users should be enjoyable. If you find that it is becoming a pain then take a step back, consult some of your power users and modify your offerings.

In the time I was proof-reading this post the excellent Carl Allchin, who implemented much of our training when on site with us, posted some of his own thoughts on the Information Lab blog. Check them out. Also a big thanks to Andy Pick who has delivered dozens of sessions for our users.

As always I’m happy to jump on a call and discuss any of this. Now if you’ll excuse me I have a training session to deliver…

Cheers, Paul

How to PROPERLY Back Up Your Tableau Server

Posted on November 15, 2015 by paulbanoub

Hello there,

Whadda ya mean you didn’t take a backup?

Time for another post about Tableau Server and how to get the best out of it in a large-scale, enterprise deployment situation.

Today we are focusing on how to PROPERLY back up your Tableau Server installation.

Like many aspects of enterprise services, this is a simple concept, but one that if you get wrong, can spell disaster. It always amazes me how many people / organisations don’t do this properly or even at all.

You know how annoyed you get when your mum tells you she isn’t backing up all her family photos – well that’s what I get like when I see IT systems neglecting backups.

Note this post refers to a standalone Tableau installation with a manual failover to DR. We don’t yet have a clustered environment. I’ll update the post with considerations when we implement that.

What’s a backup?

Seems a simple question, and there are a number of different types of backups that you can take, each useful in different situations. Here’s what I’ve got in place:

Full System Backup

This is a complete dump of the server filesystems to disk (or tape – there’s still plenty of tape backup infra out there). Most likely it will be one of the big vendor products that look like the mothership from Close Encounters of the Third Kind.

Your full system backup should be set up by your server team when you get your machine. However, the principle of “trust no-one” applies here as always and it’s up to you to check the following:

Have the backups been set up at all?
Are they backing up all the filesystems? – Many times I’ve seen that only operating system partition backups have been set up, and I’ve had to request the application partitions be included.
Have the backups been succeeding? – Get your backup team to send you a report every month of backup completion. They don’t always succeed and you probably won’t be told that there has been a failure.
If you need to perform a restore, do you know the process and how long does it take?

If you get the okay on that then you’re good. But only as an insurance policy. Full system backups can take a long time to restore, and may only be weekly so you could end up losing data even if these are in place. It’s up to you to ensure you’re covered rather than rely on other teams doing things correctly.

Nightly Tableau Backup

There’s no excuse for not having this in place. It’s easy to set up and it is a case of when rather than if it saves your ass.

The tabadmin backup command gets Tableau Server to dump all content & configuration to a single .tsbak file. You don’t have to stop the server to do this and it doesn’t seem to impact performance too much while it is running so this should be the first backup you configure.

A simple script like this will do the job.

@echo OFF
set Binpath="D:\Program Files\Tableau\Tableau Server\9.0\bin"
set Backuppath="D:\Program Files\Tableau\Backups\nightly"
echo %date% %time%: *** Housekeeping started ***

tabadmin backup %Backuppath%\ts_backup_ -d
timeout 5

tabadmin cleanup

move "D:\Program Files\Tableau\Backups\nightly\*" \\\tableau_shr\backups\nightly\
echo %date% %time%: *** Housekeeping completed ***

The tabadmin backup command does the actual work here, dumping everything to a file. Always a good idea to run tabadmin cleanup afterwards to remove logs etc.

We run this script at a quiet time for the server (not that there is one in my global environment). We use the Windows Scheduler on the server but I’d recommend using a decent scheduler like Autosys or whatever your enterprise standard is as WTS is pretty poor.

IMPORTANT: You may have noticed the move command at the end there. That takes our newly created backup file and moves it OFF THE SERVER to a share drive accessible by my backup server. Why? Well what happens if you lose the server and your backup file is on it? You may as well have no backup. So move it somewhere else.

Update – this tip actually saved my ass this week when we lost our entire VM cluster (er.. hardware team – *cough* – what’s going on??) . We were able to failover to the backup server successfully. Going forward we will be soon implementing Tableau’s High Availability capability.

Do make sure you rotate your backup files with a script that deletes the old files or your share drive will fill up. I keep 4 days worth, just in case the current file is somehow corrupted – rare but can happen.

Weekly Restart

You may know I’m not a fan of running enterprise apps on Windows. I prefer Linux for a number of reasons that I’m not going to go into here. I know many users want Tableau Server on Linux, and the amazing Tamas Foldi has only gone and written it himself – so one day we may see it.

Anyway, with Windows apps I always build in a weekly application restart. In our case every Saturday morning. That involves a server reboot (to clean out any OS related temp stuff), application restart and a tabadmin cleanup. The tabadmin cleanup with the server stopped has the added bonus of clearing out the temp files (doesn’t happen when the server is running). These files can get pretty big so worth clearing out.

Virtual Machine Snapshots

If you’re running on a VM then you may be able to utilise the VM snapshot facility. Contact your VM admins for details. I’ve not needed to implement this but I know some that do. VM snapshots are super handy.

Do be aware that Tableau don’t seem to support this though..

Config File Backup

Sometimes it’s handy to just back up your Tableau Server config. I’ve got a script that grabs all the .yml and template files in my Server directory, zips them up and moves them off the server. Pretty useful to refer back to old config settings if you need to. Make sure you include workgroup.yml.

If you’re being really good then you’ll be checking your config files into a revision control repo like SVN.

Site Specific Backups

Tableau Server allows you to backup per site. This doesn’t give me much extra but I know in orgs that have lots of sites, or a site per team / business unit it can be very handy.

One thing that isn’t great about exporting a site is that the site is locked and inaccessible as the export is taking place. See Toby Erkson’s blog for more info on exporting a site.

Backup File Size & Duration

As your environment grows you’ll need to be mindful of the size of your backup file. Mine is around 16GB and takes well over an hour to write. Takes about 25 mins to restore. You’ll need to understand those numbers as your system matures.

Backup files can get pretty big

Another variable that can affect backup time is the specification of your primary server. If your primary is low spec then you’re gonna get a longer time to write a backup. I don’t have any stats on that but I know it is true. Contact Jeff Mills of Tableau if you want more info on Weak Primaries & backup times.

Backup Your Logs

Less important this, but handy to do on a weekly basis is to zip up your logs. We have a much better solution for logfile management using Splunk – you’ll see a blog about that in the future.

The Most Important Bit – TEST YOUR BACKUPS

OK so you’re backing up like a man / woman possessed? Fine. You’re only as good as your last restore. So TEST your backups periodically. Files get corrupted and you don’t want to be discovering that your only backup is broken when you need it.

OK that’s it. Backups can save your life – don’t ignore them. Paranoia is king in IT!

Cheers, Paul

How to manage Tableau upgrades in an Enterprise environment

Posted on September 5, 2015 by paulbanoub

Hi,

Been a while since my last post. Been exceptionally busy at work due to widespread adoption of Tableau at my organisation. Usage has doubled in the last 3 months and we now have thousands of users to keep happy. That takes some doing, hence the blog hiatus.

Anyway, time to continue the series on Tableau as an IT Service, with a subject that I’m asked about a lot – just how do you manage your Tableau upgrades in an Enterprise environment?

This is actually a pretty big subject, especially in an Enterprise setup. There’s no perfect way to do it but hopefully some of these tips will be useful.

Section 1 – Pre-Upgrade Considerations

To upgrade or not? That is the question

Obviously you’ll need to make some sort of decision as to whether or not you actually need to upgrade. Each time you upgrade a production system you risk impacting stability, introducing bugs or human error. It also needs testing, planning and eats resources and time. So if there’s no good reason to upgrade, then don’t.

Tableau release new versions at a pretty impressive cadence, generally once a month for ‘maintenance’ releases. So for each newly advertised release, take note of the following in order to make your decision.

Compelling functionality – New features are entering the product all the time. Determine what may be useful to your user base.
Key bug fixes – Each new version will squash a few bugs. If there’s one that is affecting your users then it may be prudent to upgrade and quieten the noise. Remember that your upgrade may introduce new issues. Take note of the known issues section in the release notes.

Both of these are fully documented in the Release Notes. Review them carefully each time Tableau announce a new version. There are occasions where bug fixes are not announced in the release notes but your account manager will make you aware of those.

Also be aware that new versions might also introduce new bugs / issues. We have had situations where we have been stable, decided to upgrade and then spent the next few months battling newly introduced issues to the point that we probably should have stayed on the older version.

Be aware of compatibility issues

I hear a lot of complaints about compatibility issues between Server and Desktop. So it’s important to be aware of the behaviour between versions. Get this wrong and you may be in a position where users have overwritten content originally created in an older version and don’t have a back up to roll back to. If you are crossing major versions (8 -> 9) for example, then you’ll certainly need to upgrade the Server and Desktops at the same time.

Top tip – it is possible to hack the xml of a workbook to change the version and rescue the situation, provided no edits have been made to the content. The ever-so-talented Jen Vaughan (@butterflystory) explains all here.

For more details see this article.

Don’t upgrade to version zero

Most risk averse IT managers (like me) will resist the temptation to jump right into that new shiny Vx.0 release the day it comes out. Version zero releases of any software are notorious for bugs and issues, that’s just the nature of software development. So at my org we always let at least one maintenance release slide by and instead go to the Vx.0.1 or Vx.0.2 release.

It can be hard to resist temptation, especially when your users are clamouring for that shiny new version but if there are major bugs in that zero release, then best let someone else find out about them rather than you.

Caveat: This doesn’t always work of course. We waited for 9.0.2 and that ended up being one of the buggier releases. Oh the irony.

Understand the new version resource demands

This is important. You may be rocking away on your existing version, confident that your hardware can satisfy the software. But then you upgrade, and all of a sudden that new version eats up double the RAM or batters your CPU. You didn’t see that coming.

For version 9 Tableau released an updated scalability document. Annoyingly it was released quite a while after V9 went live. I was expecting a comfortable read but noticed phrases like the following, which were pretty alarming.

Whaaaat?! That led to some discussions with Tableau tech folks (thanks Meredith!) and some fevered testing and all turned out to be ok. But those figures took us by surprise for sure. Don’t be in a position where you upgrade and then suddenly hit a capacity issue that your older version didn’t have.

Test it!

Let’s say you upgrade. And it goes wrong. One of the first questions you’ll get asked is “Did you test this?”. You really don’t want to be answering “no” to that question.

You should have at least one non-production environment that you can run tests on. Due to the complex nature of Tableau it is impossible to test every aspect of functionality but you should at least be able to cover a good number of scenarios. You may also not be able to simulate your production load on your test environment but it will be better than nothing. You may find the load testing utility tabjolt handy here. Check Russell Christopher’s guide to tabjolt.

I have the following environments to play with. This gives me a lot of options.

Production – Main user facing environment
BCP – Disaster recovery environment in case production fails
UAT – A mirror of production. Same spec
Engineering – Lower spec, used to test the latest version available from the vendor
Beta – Even lower spec, used for testing beta versions
Alpha – for testing the alpha versions

Ensure that the tests you conduct are consistent, repeatable and that the outcomes are recorded. We use a tool called Quality Centre and the tests are performed by my level 2 support folks. This gives consistency and frees time for my main analysts.

Verify your licence details

Double check your licence maintenance end date for both Server and Desktop. If you’re out of maintenance then you won’t be able to use the application after you upgrade. I’ve seen licence issues way too many times with many applications after an upgrade. You won’t want to be trying to contact your account manager on a weekend to sort out a licence issue.

Opinion – IMHO I would much prefer it if applications didn’t crap out due to licence expiration. In 99% of cases there’s some paperwork misunderstanding that is easily sorted by your account manager. By all means let the application hit you with some warnings and also alert the vendor, but it shouldn’t mean a loss of service.

Your upgrade process & strategy

I’m not going to go into it here as it’s a full on subject in itself but make sure you follow your organisation’s Change Management procedure to the letter. Failure to follow change processes is generally a dismissible offence in most Enterprises.

Make sure you advertise your strategy for upgrades and maintenance to your users. You’ll get asked, so ensure this is specified in your Service Document. You may even have standard maintenance windows (e.g. on a weekend) where you can reserve the right to take down the system. Again, make sure that is documented and your users are aware.

Section 2 – The Upgrade

Create a package

Most enterprises will use some form of package deployment tool / team to perform the actual deployment of new software. That’s pretty handy. I have over 500 installations of desktop to support and we need to ensure they all get upgraded at the same time. So I can create a software bundle, send to the packaging team and they will then schedule and deploy.

This gives you the chance to include those little extras in your package to give your users the best experience. Here’s what’s in our Tableau Desktop package.

The installer exe file
A sample “Getting Started” workbook with tips, best practices & help.
Preferences.tps file containing customised colour pallettes
Most used drivers (Oracle, MySQL etc)

I would love to be able to customise the “Discover” pane to point to some of my internal resources but it doesn’t seem to be possible. Boo.

We also supply custom instructions for the packaging team, such as running the installer with a flag / registry update to disable the auto-update feature that has been implemented in the upcoming 9.1 release. A really baaaaad idea for Enterprise deployments.

One thing to be aware of with packaging is that it can take a long time. From request to deployment, the typical time at my org is an insane 7 weeks! By which time another version is out. We are hoping to speed that up a bit obviously.

Communicate to the max

You can’t over communicate any potential disruption to your service. Make sure a broadcast message goes to your users via whatever system your firm uses. And it doesn’t hurt to follow-up with your power users / senior stakeholders with a personal reminder that work is planned.

Take a backup

Whadda ya mean you didn’t take a backup?

Tableau is one of the easiest applications to upgrade that I’ve worked with. A simple uninstall / reinstall does the trick. But don’t take that for granted – make sure you take a manual backup prior to your upgrade. If you’re not doing this as a matter of principle then you’ll be getting a visit from the boys. And they won’t have had their dinner.

Handily, the uninstall process takes a backup anyway but don’t rely on that, take your own.

You should also back up all your .yml configuration files and ensure you know what each setting is. Tableau should preserve these settings during the upgrade but just in case it doesn’t then it’s handy to have a copy to refer back to.

Server specific considerations

When you uninstall Tableau Server it backs up the content and the settings in the main yml configuration files. That’s cool, but do remember that if you’ve changed any of the other config files then they will be overwritten and you’ll have to make the changes again. For example we change the webserver timeout settings in the file “\Tableau\Tableau Server\data\tabsvc\config\httpd\httpd.conf.templ” – that gets blown away by an uninstall.

There may also be other settings in the Postgres db that you may have modified using tabadmin. Not all are retained from what I can see. Note I’m still researching this so not 100% sure of the behaviour.

Finally make sure you understand any changes to the Tableau Postgres DB schema in the new versions. It has generally remained pretty consistent but if any tables or fields are renamed then that may well break your Custom Admin Views.

Section 3 – Post upgrade

Test it! Again!

Not all issues come to light immediately. Perform testing, keep vigilant and liaise with your users closely in the next few days to understand if the application is behaving as it should be.

Ask for help!

Tableau Upgrade Assistance

If all this sounds a bit daunting and you’d like to get assistance then Tableau offer an “upgrade assistance” programme which might be worth looking at. Talk to your account manager for more information.

There are also other guides around. Have a look at this one from our good friends at Interworks.

That’s it for this post. As I said it’s a big subject so do post comments if you feel I’ve missed anything.

Happy upgrading! Cheers, Paul