3 Replies Latest reply on Jun 6, 2017 5:06 AM by Jeffrey Line

    Best Practice for applying Server patches ?

    Charles Belt

      When we went through quick start, our Tableau consultant recommended a quarterly patch schedule. Is this considered best practice ? Tableau seems to offer patches at least every month, and a 10.x version upgrade at least every half year.


      We hesitate to upgrade to 10.3 at this time.


      Thanks !

        • 1. Re: Best Practice for applying Server patches ?
          Jeff Strauss

          I don't know that there's any right or wrong answer to this question, some of it depends how conservative your organization chooses to be.  But I can tell you what we do:  Typically we will not upgrade to 10.x.0, we will wait for at least 1 maintenance patch (i.e. 10.3.1) prior to even starting testing.  And then we typically don't touch server patches as we are off doing other work, the one exception to this is if we are seeing a problem that seems to be fixed by a patch, then we will move forward with it then.

          1 of 1 people found this helpful
          • 2. Re: Best Practice for applying Server patches ?
            Donna Coles

            Hi Charles - we're similar to Jeff.  At the minimum we try to do an upgrade every year, sometimes it can be longer than that.  As server admin it's not an ideal schedule, but for us (single server installation), the actual steps of upgrading to the most minor patch eg 10.1.8 is no different from applying a mid point upgrade eg to 10.3.0, and to a major upgrade (eg in Jan we went from 9.0.3 to 10.1.1).  I  need resource from other teams in my dept to help with this and they're stretched with other activities, so I have to plan for their resource several months in advance. The only difference with the minor/mid/major version upgrades is the volume of pre-upgrade testing that I go through which is my time that I can control.

            We also have to consider impact on the business who use the server as to the impact in the event things don't go to plan - there are periods in the year when being without their reports is more of an issue for them.

            As with Jeff, in the event an upgrade caused a significant issue that a subsequent release would fix, we'd upgrade sooner, but so far this hasn't ever needed to be the case.

            When we do upgrade we go with whatever version happens to be stable at the time we start our testing, but will always got for a x.x.1 or above avoiding the 0 release (it's usually typical that the week before we upgrade another minor version gets released, but we'll stick with the tested one).


            Hope that helps too


            3 of 3 people found this helpful
            • 3. Re: Best Practice for applying Server patches ?
              Jeffrey Line



              I totally agree with Donna & Jeff on this. In fact I was planning on upgrading to 10.2.1 last month but had to push it off since I was waiting on an IT group to finish the scripting for our desktop and reader installs that I also push out. It was funny on June 1 the day after 10.3 came out one of my main users asked me when we would be upgrading to 10.3. She noticed the data driven alerting and thought that would be a good feature to have.


              My response was that I will try to be at least 1 release behind the current release unless the new one will fix an issue with some reporting or there happens to be a new feature that is of benefit to our organization. Plus it would be feasible once a minor release patch comes out for the base version.


              Hope this helps.



              3 of 3 people found this helpful