How can the Voice Extension be enabled and used when the dashboard is published to Tableau Server?
Are there any specific server configurations, security settings, or extension allowlist requirements that need to be configured?
Did you encounter any limitations or compatibility issues between Tableau Desktop and Tableau Server?
#Tableau Server
I tried looking in Tableau Server Repository with the following postgreSql but it only has
an "Update Schedule" = historical_events.historical_event_type_id
when I change the settings of the schedule.
There is no new event recorded when I change the name of the schedule
select h.id, historical_event_type_id, details, created_at, hist_actor_user_id, hist_schedule_id
,hs.*
,e.*
FROM historical_events AS h
LEFT JOIN hist_schedules AS hs ON h.hist_schedule_id = hs.id
LEFT JOIN historical_event_types AS e ON h.historical_event_type_id = e.type_id
#Tableau Server #Repository #Administrator
Hi @Vinh Ton
you won't find such change history or level of detail. Tableau writes name change directly in the schedules table and that's it.
Currently RMT is running on a separate server (Windows 2019) and whenever it's restarted the RMT statistics fail to update, sometimes restarting the MQ and RMT services works to get the statistics coming through
#Tableau Server
Environment:
Issue Description:
The issue started immediately after upgrading Tableau Server to version 2026.2 and adding a fifth server (node5) configured as a Tableau Server Independent Gateway (TSIG) load balancer.
Node5 was subsequently removed and no longer appears in tsm topology list-nodes. However, the errors continue.
As part of the changes, we also increased the number of Backgrounder instances on nodes 2 and 3 from one to two per node. Both Backgrounder instances on each node are running normally.
The ZooKeeper client running inside the Non-Interactive Microservice Container on nodes 2 and 3 repeatedly fails TLS hostname verification when connecting to all three Coordination Service nodes.
The following error appears continuously:
java.security.cert.CertificateException: No name matching tableau-c0X found
On the Coordination Service side, the failures appear as SSLHandshakeException: certificate_unknown, occurring approximately 600 times per minute per ensemble node.
Investigation and Troubleshooting Performed:
Current System Status:
All Tableau Server services are operational.
Running tsm status -v shows that all services are in the Running state. Dashboards, extracts, background jobs, and other Tableau functionality appear to be working normally.
Both Backgrounder instances on nodes 2 and 3 are functioning correctly.
However, despite all services running successfully, the TLS errors continue to be generated continuously in the background.
Impact:
The main impact is excessive log generation and disk space consumption:
Although there is currently no visible functional impact on Tableau Server, the abnormal log growth is a significant operational concern.
Assistance Requested:
We need Tableau Support's assistance to identify and permanently resolve this issue.
Specifically, we would appreciate your guidance on the following:
The log looks like:
2026-10-08 22:10:28.037 +0000 13552 nioEventLoopGroup-4-29 : ERROR org.apache.zookeeper.server.NettyServerCnxnFactory - Unsuccessful handshake with session 0x0
2026-10-08 22:10:28.038 +0000 13552 nioEventLoopGroup-4-29 : WARN org.apache.zookeeper.server.NettyServerCnxnFactory - Exception caught
io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:515)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1357)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:868)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:171)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:796)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:732)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:1007)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_unknown
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:131)
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:370)
at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)
at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:209)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:172)
at java.base/sun.security.ssl.SSLEngineImpl.decode(SSLEngineImpl.java:736)
at java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:691)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:506)
at java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:482)
at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:679)
at io.netty.handler.ssl.SslHandler$SslEngineType$3.unwrap(SslHandler.java:308)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1486)
at io.netty.handler.ssl.SslHandler.decodeJdkCompatible(SslHandler.java:1377)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1428)
at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:545)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:484)
... 17 more
#Tableau Server
thanks for sharing but here is the community forum where tableau users simply help each user.
To reach Tableau support and open a case with all your details, please follow here:
https://help.salesforce.com/s/case-submission?sp=1Our security team raised one vulnerability in our tableau 2024.2.13 linux server and solution require the java version to be greater than 11.0.32.0.9-1.el8. Can someone please confirm if Tableau server upgrade to version 2025.3.8 will resolve this.
#Tableau Server
Try v. 2025.3.10, so the september release. That's your best shot currently. It should fix a majority of these CVEs, but most likely not all at some are still impacted at Java v.17.0.16-17.0.19. Have a try. And in doubt you can always write to Salesforce InfoSecurity. Flagging doesn't mean vulnerable.
Databases can store datetime in local time or UTC - the designer of the database makes that decision.
Our microsoft sql database stores datetime in UTC. The users want to see datetime in local time. How do i tell tableau that this particular sql server stores datetime in UTC?
Tableau server 2025.3.3
#Tableau Server
you guessed it :)
You can read the related idea and contribute but that doesn't look very good for the roadmap:
https://ideas.salesforce.com/s/idea/a0BHp000016KoeNMAS/timezone-conversion-supportHi, folks.
We've installed Tableau Server 2026.2.2 and properly configured the guest account for one of our sites. We're not able to get a direct URL or the embed code to allow a guest user to access a dashboard without being prompted to authenticate.
Does anyone have a working guest-enabled URL in 2026.2.2 they can share?
Is anyone else having this problem?
Thank you,
Joe
#Tableau Server
if you are good experienced with Guest account approach, meaning add Enabling, then Guest permissions and using the share button to get the link, then it could be a specific bug, though I didn't find anything on the Salesforce Issue Tracker.
I would be you, I would at least look at the Vizportal logs to understand what is happening with the Guest session authentication.
Make also your tests with an Incognito browser window and check also the browser Dev Tools Network traffic related requests / responses.
And worse case open a Tableau Support case.
Published Dashboards currently using the Biztory Dynamic Date Parameter dashboard extension to dynamically set default date parameter values when users open a dashboard in a browser.
During a Tableau Server upgrade to a newer version, what happens to existing dashboard extensions?
Specifically:
Has anyone successfully upgraded Tableau Server while using this extension (or similar dashboard extensions) at scale?
#Salesforce Developer #Reports & Dashboards #Tableau Server #Salesforce Admin
Hi, Dashboard Extension configurations are saved in the workbooks, not directly in Tableau Server. Thus:
Yes, it should be. The Extension's configuration is saved in the workbooks.
2. Are externally hosted extensions automatically preserved, or do they need to be reconfigured/retrusted after the upgrade?
Automatically preserved, the config is saved. If the config is not saved, it would be a Tableau Server error. However, in the worst case, whitelist the extensions is an easy and fast process.
3. Is there any risk that the extension settings could be lost, requiring us to edit and republish all 500+ dashboards to redefine the dynamic default dates?
Probably, the greatest risk is not related with Tableau Server. Maybe the greatest risk is with Biztory stopping the hosting, or Biztory problems with hosting the extension.
4. Are there any recommended validation steps before or after the upgrade for dashboards that use extensions?
As always, when you perform a Tableau Server upgrade the best you can do is to use a blue green upgrade. That way:a. Your current release keeps working
b. You install, restore a backup and test the new Tableau Server exhaustively, and make sure everythings works as expected.
c. If everything is ok, you restore the newest backup from your "old" production environment into the new one, you modify NAT/Network to point to your new install, and you have a really small downtime.
If this post resolves the question, would you be so kind to "Accept this Answer"?. This will help other users find the same answer/resolution and help community keep track of answered questions. Thank you.
Regards,
Diego Martinez
Tableau Visionary and Tableau Ambassador
Hello all,
I have (Recently upgraded the servers to version 2026.2.1) Linux server and using tnsnames.ors files for Oracle DB connections. Also has the 'ojdbc11.jar' driver file placed at /opt/tableau/tableau_driver/jdbc location.
(Note: Other data extracts or refreshes works normally. only issue with this recently created flow which outputs multiple files)
I see one of the prep flows on the server is failing with ERROR: "
Output step error message: [FailedToConnectExternalResourceError] - Unable to connect to DataSource_Name on DataSource_Name. Check that the data source is available, or edit the connection and enter your credentials again
"
When I check connection from the panel 'Test Connection' works and shows successful, but at the runtime this flow fails.
I have tnsfiles.ora with proper DB connection names and have placed the 'oracle.properties' file with the string 'oracle.net.tns_admin=/etc' within at locations:
1. /var/opt/tableau/tableau_server/data/tabsvc/flowminerva/Datasources/oracle.properties
2./var/opt/tableau/tableau_server/data/tabsvc/minerva/Datasources/oracle.properties
3./var/opt/tableau/tableau_server/data/tabsvc/vizqlserver/Datasources/oracle.properties
also, just now added the file at -
4. /var/opt/tableau/tableau_server/data/tabsvc/flowprocessor/Datasources/oracle.properties
Any idea what can I check for?
Thank you!
Hi Vikas,
Test Connection and the flow run are not the same session. Test Connection uses you. A Prep flow on Tableau Server runs with the credentials embedded on the flow, under the server account that executes flows. Other extracts can keep working while this flow doesn't, if this one is the only place those credentials aren't embedded.
The message you pasted is on the output step: unable to connect to that data source. That's the output connection, not automatically the Oracle input. A flow that writes several files has an output connection of its own, and that's the one I'd open first.
On the Oracle side, the process that actually runs the flow has to see the JDBC driver and oracle.properties. Dropping the file under flowprocessor while that process is already up doesn't always get picked up. Restart the flow services after the file is in place, then run this one flow again.
I wouldn't call this a tnsnames problem until the output step still can't connect when you run it as the same account the server uses. I also don't have a published defect for 2026.2.1 that matches this, so I won't invent one.
We are currently running Tableau Server 2024.2.9 on Windows Server 2019 and are planning our next Tableau Server upgrade.
We would like recommendations on the most stable and production-ready Tableau Server version to upgrade to from 2024.2.9.
A few questions:
Our priority is stability and reliability rather than moving to the newest release immediately
.
#Tableau Server
From my experience latest releases like 2025.3.10 are ok.
https://www.tableau.com/support/releases/server/2025.3.10
What version would you recommend as the next stable production release from 2024.2.9?
R:\ 2025.3.10
Is Tableau Server 2025.3.x currently considered stable for production environments?
R:\ Yes
Are there any known issues or major considerations when upgrading from 2024.2.9 to 2025.3.x?
R:\ As always, do a blue green upgrade.
Is a direct upgrade from 2024.2.9 to 2025.3.x supported, or is an intermediate version recommended?
R:\ There is no intermediate release.
Are there any compatibility concerns with Windows Server 2019?
R:\ The end of life support by Microsoft is scheduled for January 9, 2029. Thus, we are ok for Windows Server 2019. If we are talking about Windows Server 2016, then you may have a future problem, because end of lif support for WS2016 is January 2027
For those who have already upgraded to 2025.3.x, have you experienced any significant issues with extracts, Backgrounder, scheduled jobs, authentication, or performance?
Nope
@Emeric LE SAULNIER DE SAINT JOUAN do you have any additional comment?
If this post resolves the question, would you be so kind to "Accept this Answer"?. This will help other users find the same answer/resolution and help community keep track of answered questions. Thank you.
Regards,
Diego Martinez
Tableau Visionary and Tableau Ambassador