5 Replies Latest reply on Dec 8, 2017 1:37 PM by Tyler Garrett

    Guest Access in 10.1.3 version

    abdelmajid elmounjid



      We currently have a tableau server environment 10.1.3 version, and we are looking to pull the following report:

      All the sites in the environment, which ones have Guest access vs not, if Guest account is granted permission at the Project level (Yes/No), if yes then at the workbook level (Yes/No), if Yes then at the View level.

      And also be able to pull the names of the Projects, Workbooks, and Views where the rule (Yes) is applied.


      Any suggestions will be appreciated.


      Thank you

        • 1. Re: Guest Access in 10.1.3 version
          Jeff Strauss

          how many sites do you have?  Guest access by site was not enabled as a TS feature until I think 10.2 so I think for you, it's more so at a global server level independent of site.

          • 2. Re: Guest Access in 10.1.3 version
            abdelmajid elmounjid

            Hi Jeff,


            The environment has over 300 sites, yes true Guest access was not enable until 10.2.

            Was wondering if there is a way to use postgres and pull the info we are looking for:

            All the sites in the environment, which ones have Guest access vs not, if Guest account is granted permission at the Project level (Yes/No), if yes then at the workbook level (Yes/No), if Yes then at the View level.

            And also be able to pull the names of the Projects, Workbooks, and Views where the rule (Yes) is applied.


            Thank you

            • 3. Re: Guest Access in 10.1.3 version
              Jeff Strauss

              Wow, that's a whopping ton of sites!!!!!  I don't have anything pre-built that reports on guest access.  Matt Coles or tyler garrett   Do you have anything?

              1 of 1 people found this helpful
              • 4. Re: Guest Access in 10.1.3 version
                Tyler Garrett

                I have a few things prebuilt around querying the repo, automating tableau administration... and it's based on "WHERE = SITEXXXX" So let me dig it up.


                My thought - implement the sites in, and find the 'columns' and such necessary by playing in the repo for a bit... If you can report on ONE guest user experience in one site... Then yes it's possible based on all. Just my assumption, as I've never heard anyone doing this - brb. Sounds exciting/impressive.

                • 5. Re: Guest Access in 10.1.3 version
                  Tyler Garrett

                  Below I share a screenshot of a few things that show that it's possible, but I want to explain why I think this is maybe not so great, I'm verbose, been doing this a bit. Okay here we go! I'm answering this like someone is going to google search, find this, and learn not to do sites (I HOPE).


                  You can REWASH this entirely - All of this, pulling and pushing, can be automated.

                  not the MOST fun task - but I've done it in the past and generated this POSH script. Which pulled SITE content, and PUSHED to another SITE, it was a 'default' project push to 'default' project push.


                  1. you can pull down workbooks.

                  2. you can pull down datasources.

                  3. push it to a new place.

                  4. now your analytics are living together.

                  It isn't made to capture any permissions, it's just made to query the repo, ask 'what's in this' and tabcmd it all out into a desired location.

                  Custom workaround for tableau server, 1st workbook script given publicly.png

                  Not the most beautiful powershell script, but it works on any windows machine, and user friendly I would say.

                  If you have 300 people managing 300 sites... it would be the ONLY use case I would say "okay go for that" - even then I would do my best to convince you otherwise.


                  Okay, because I want success for everyone, I'm going to show you that it is possible here below in this Postgresql screenshot of a POSH app, and I'm also going to advise again that it may be better to start over than dig through this.


                  Here on line 111:


                  I'm using the '$SiteF'

                  Here on line 97:


                  I'm pulling _sites.name


                  This stands to say you can query multiple sites of data.

                  And if you're already reporting on one GUEST - I don't see why you can't report on multiple sites.

                  Screen Shot 2017-12-08 at 2.51.11 PM.png

                  So yes, it's possible. Is this a good or healthy direction? Unless there's 300 site admins, probably not.


                  Before I start, I just want to say 300 sites is a lot. There's a solution ABOVE. Let me know if I can help by pasting the code too.


                  Let me explain:

                  Without 300 people, I would strongly advise against this. I'm going to explain with story, my experiences, and seeing Site installs flop, and never actually work except for 1%. That 1% had SITE ADMINS locked and loaded, and in the ROOM learning about Tableau Server Administration.


                  I've architected a lot of the big installations (working at tableau)...


                  I never suggested Sites. And spent most of my time talking freelancer OR external consultants OUT of the 'site worm hole' - which is to say they know the verbiage - but not a single one of them had ever done more than 1 or 2 installations, which considering now there are THOUSANDS of 'tableau experts' - most are great at the products, not scalability of the products.


                  Most like to think "if it's on this site, then those people can't access it".... True... but sites are not great if you don't have people managing them with a REALLY good reason. Like, super duper good reason!


                  And I remind them That is what PROJECT permissions are for... and projects are easier to support.


                  Don't get stuck in that mindset. Projects - are extremely powerful and much easier to support. I promise.


                  I would like to ask:

                  1. Who architected it this way?
                  2. Was it a recommendation from a business?
                  3. Freelance Consultant?
                  4. Or did your team internally do the installation?
                  5. Did anyone consultant someone with any Tableau Server experience before setting it up this way?


                  Tableau certifications don't weigh on scalability of decisions.

                  So, certificate or not, it doesn't help with longterm scalability of a Tableau implementation.

                  Sites merely open a NEW role, SITE ADMIN. Period. And there's also PROJECT Leads/Admins, which can be setup 100% like a NEW SITE - without this massive support/remediation roadbump.


                  Because Sites - imo - were never intended for this usage, I'm explaining this in great detail because I want to help you and the community.

                  And I do hope this deep dive HELPS!


                  Why am I saying so much about this? Because this architecture is very uncommon - and considering the longterm scalability - it may be better to start PULLING everything down, and PUSHING it back into new projects.


                  ALSO you can have projects JUST for data sources, and a project JUST for workbooks.


                  No end users will see it unless you give them access - meaning it stays clean - no one sees each other - just like a site.


                  I hope that makes sense because a new site is a completely different and separate living thing. So this question may be do-able, but I'm not crossing my fingers. Rather, let's talk about solutions to work-around this.


                  I'm not looking to make this turn into a BIG chunk of work, rather I'm forecasting you will work less, with a few hours, days of pain, and reverting to a site or two at most. Only if you have someone to administrate that site, that you can work with as a team. Or you'll be struggling to keep this installation functional for yourself or future admins.


                  Longterm, business gets bigger, requests get more complicated, you want to automate EVERYTHING that you possible can.


                  Which is possible and much easier on ONE SITE. Requests become a few clicks, VS a few hundred clicks. Just my 2cents, maybe an admin with 100's of sites can come and explain to us what the work load is like being a single admin.





                  2 of 2 people found this helpful