Permissions are most confusing, in my opinion.
Resources I've used and have found helpful:
Other than that, working with Multiple Sites (Enterprise Deployment) and setting them up effectively has been mostly a guessing/trial and error game.
The existing documentation provides a good general overview in most areas, but answering questions like "how should I set up my user filtering/data security at an enterprise level" can be incredibly difficult, as it depends on so many factors.
- More background about server performance, and the impacts of ramping up/down different server roles. Knowing that lots of Backgrounders on a low-RAM server is a Bad Thing would have saved us a lot of pain.
- Some best practices around Projects organization. We've decided to stay single-site. Laying out the Projects, permissions, and datasource locations was trial-and-error at first for us.
+1 on Permissions in Matthew's comment. Lack of strong inheritance in Projects is non-intuitive to a Windows sysadmin like myself.
Most difficult problems encountered have been the most poorly documented ones.
1. First that comes to mind is the proxy setup. There was NO mention in the admin guide about needing to set up the proxy settings in IE as the "run as" user. Totally frustrating until I figured it out on my own. I have carped loudly about this.
2. No mention in the docs on how Server mysteriously self-destructs if your environment at any time exceeds your core license. Specifically, I was trying to install a distributed server -- two procs on gateway, eight on worker -- with an eight-core license. Basic install must be done on the gateway first, and that worked. But after installing worker software and attempting to move the processes from gateway to the worker, things really got screwed up. Later I find out from the support engineer that I would have to do a compelte re-install after removing two cores from the worker machine, so as not to exceed the license limit. Had I known that in advance, I wouldn't have had to waste my time and the Tableau support engineer's time.
3. We set up a distributed environment with gateway on its own machine, we discovered that our worker machine needed to communicate with our AD domain controller if we wanted to use AD for authentication. We were told that the gateway would handle all connections to AD. Not so. Another thing that took us a lot of time to figure out on our own.
I've found that many support folks are not well versed in the internals of the server. As a matter of fact, those who do have that level of knowledge are few. I've had to figure out a lot of things on my own, which I like but detective work can be time-consuming and always seems to happen when other fires are burning. But when I learn something new, I try to share it on the forums. The Tableau user community is awesome.
Totally agree with the comments above on permissions. Also agree with Matthew's comments on enterprise (multi-server) deployments.
I know that I sometimes sound surly, but I like this product and its culture. I have never met a nicer group of people anywhere -- they seem always ready to lend a helping hand whenever possible.
+1 on all previous comments. ok, you'all got me started, thanks for asking. I love the product, but certainly could love it even more.
I'd like to see more details related to server performance:
1. What are the indicators for needing more of each process (i.e. vizql, data engine, data server).
2. Is there any study done on the affects of logging on server performance? I plan to do my own, I know the default is Info, however why do the lower levels exist? Can logging become burdensome?
3. I use the Postgres ODBC driver for other databases besides the internal Tableau repository. When I installed 8.2.3, the installer removed the 32-bit version of my postgres driver. This got me kinda agitated. Also, I'd like to know if setting ODBC connection pooling for Postgres confuses Tableau internals or not. I guess it's another thing for me to test.
4. Need to know about session timeouts for tabcmd login and then each subsequent tabcmd. Right now I am going cookieless (without login), but this seems to creates too many sessions. I'm switching some of the scripts back to using login / logout, but it's not clear on the timeouts.
5. I want Tableau to recommend external influencers that have big performance effects. Defrag is a classic example, but also I've asked about SSD and have not received any concrete answers besides that it seems to have helped other customers. We are going to new servers with RAID-10, I know it's been implemented for ALPO, the Tableau internal engineers must have internal recommendations on RAID-10 configs. Share them.
6. External load balancer configs. I bumped into this one when integrating between our external portal and Tableau server. The gateway setting options did not work and the instructions were and still are quite confusing. Somewhere along the way I found a webinar and reached out to the Tableau engineer and he said to try X-PROTO-FORWARDED and X-PROTO-something else. In any case, this did wonders, however it's not documented anywhere.
Thank you all so much for this feedback. Even just having this out and available will be useful for future users. I'll see if I can get some extra content devoted to the topics listed.
- The basic workflow on how the internally tableau processes communicates with each other( ex, when using desktop VS server interactions). This was not well documented and had to reach out to many to understand how the components talk to each other.
- Definitely +1 to permissions. Very publisher centric but make it hard to manage in an enterprise level deployment.
- AD being the pre requisite for any cluster install. Our org runs everything on AWS and we don't have internal AD as we reply on google Apps. When we decided to cluster, i found out that we can't install without AD as server can't talk to each other.
- In ability for Publishers to change their data connections using bulk update. This option is available for Admin but makes it hard to publisher who have many workbooks to update in bulk.
- Lack of better visibility of the server settings( all parameters which are stored in the workgroup.yml). Had to hunt this down to see what the settings are.
(edited, I submitted too early)
For me I think the important bit that would have helped as I started was that I needed to start building a community of Tableau Server power users right up front to help me keep an ear to the ground of what people need from the system. There have been far too many times that I have heard "Server is slow" from my boss' boss, and I should have heard it from the users directly. There was just no channel for feedback like that to come out. When is a new Project needed? When are permissions just not working? How do we keep people in the loop with what changes might be happening, recommending best practices, etc etc? Getting key people involved up front would have saved me all kinds of grief as time went on.
Ideally, we would have had Drive back then to help blueprint it out a bit, but I was flying somewhat blind and it caused our users some unnecessary pain.
I still have challenges with large amounts of Users : Move, Add, Change, Delete. Active Directory synch at large scale has only recently started working at all correctly, and it's still not perfect. Uploading .csv's and writing scripts is a pain. Given Tableau's whole ease-of-use culture, Server sure leaves us to our own devices when it comes to system auditing, monitoring, and -- when it comes to users, as opposed to content -- administering.
I really wish there were such a construct as a User Administrator -- someone that cannot alter content, but could help out with the userid and group management.
I think The specified item was not found. captured most of my issues and +1 all other comments.
For me the most challenging part starting out was understanding Permissions and Security and how to adapt it to our Enterprise Security model.
- Tableau is very flexible when it comes to security, but the training and admin guides didn't do enough to set me up for success in our enterprise environment. The security model I've rolled out is AD group based, but becomes challenging when you have many groups within a project folder that requires unique permissions for many.
- The information on managing a distributed/HA platform is rather brief on the content and offers very little guidance to monitor and adjust accordingly. I would love to see something within Tableau have "self-monitoring" and offer guidance on allocating processes. For example, it would be great if Tableau could recognize that we're a heavy extract shop, or our VizQL processes are historically high and recommend adding/removing processes to accommodate a volatile environment.
- I'm hoping to see more support for the REST API to establish roles and permissions. Not being able to create a custom role and re-use that across the organization has been difficult.
- Backup/Restore - the backup and restore functions need to be expanded so we can do partial restores and restore certain attributes (like permissions or individual workbooks or projects).
- Logs - I think we would all benefit greatly from a document understanding how logging works and how to troubleshoot.
The most frustrating thing is the Proxy settings. I agree with Thom Gourley, there is no mention you must go into IE, run it as the Run As user and assign the proxy settings. Frustrating at first, now it's more annoying than anything. I've had to update these settings several times over the last year or so with updates and the small changes to the way proxy sees and handles information. In our environment I'm having to manage this on 12 servers. Can we not rely on the MS IE application going forward? That would be great.
Permissions is a source of frequent head-scratching.
For example, if I have a view based on a Tableau Data Engine published source, then I have to make sure the user has permissions to connect to the data source, rather than inherit it from the view. Maybe there is a security consideration behind current logic, but then, while we are on the subject, it would be nice to get an alert telling me that this user, whom I just gave permissions to a view, will not be able to use it until data source permission is sorted. And a link to its permissions page on the alert window would be nice.
Another source of frustration for us is the tendency of Tableau Server to cache everything and hold on to it, even when I want it to recognise that the content has changed. So in some cases I have to get users to restart their computers, and sometimes even that doesn't work.
Upon rereading my post, the tone comes across a little harshly towards the support crew, for which I apologize. What I should have said is that for complex deployments, first-tier support sometimes struggles. I suspect that this is a byproduct of the rapid growth of both the product and the company. I can appreciate the challenges of keeping the support staff up to date on many of the intricate details of the server environment as things are in a state of rapid change.
The Tableau support staff and community forums have been a great source of help to me in administering our server here, and I am grateful for the spirit of generousity that pervades the Tableau community. What I think would be most helpful to me is documentation that dives more deeply into the internals of Server, with more detail on network connections and server process interactions. I've gotten a taste of this in the one-day server preconference training, but am realizing that I probably will need the full week of training on Server to get the level of detail that I'm after.
Well said Thom. Support does try really hard and put forth their best effort; however they don't always have the internal logic / intelligence trickled down to them to give true insight into server internals. Its usually only upon playing with my test server configs and reading between the lines when I start to understand the internals (like spawning of new processes, the rhyme and reason as to where each of the log files are stored, perfmon metrics, etc).
In looking through your answers again (there is a lot of work going on behind the scenes into everything mentioned in this thread) I would actually recommend breaking those off in to new topics. I took the ones I thought would be useful for documenting and making changes, but some of the other questions are just good general questions that might have an answer somewhere.