Tableau Feed

Hello All,

I’m using Tableau Desktop 2025.3 on an Apple Silicon Mac and connecting to our Tableau Server at:

https://mytableau.nameoforg.org

Issue summary:

• I can sign in and browse workbooks on the server
• During sign-in, I see two login pages:
  1. https://fs.nameoforg.org
  2. https://mytableau.nameoforg.org
• After I select a workbook and click Open, Tableau prompts me again to connect to: 
  https://fs.nameoforg.org
• Then I get this error: 
  “Cannot connect to Tableau Server. Please check the server name and port and try again.”

Expected behavior:

• Tableau Desktop should authenticate via SSO if needed, but continue using https://mytableau.nameoforg.org as the Tableau Server
• The workbook should open without prompting me to connect to https://fs.nameoforg.org as if it were the Tableau Server

Observed behavior:

• fs.nameoforg.org appears to be treated as the Tableau Server during workbook open
• Connection fails at that step

Environment:

• Tableau Desktop: 2025.3
• Hardware: Apple Silicon Mac
• Tableau Server: https://mytableau.nameoforg.org

Repro steps:

1. Open Tableau Desktop
2. Sign in to Tableau Server at https://mytableau.nameoforg.org
3. Authenticate through the NYU login flow (https://fs.nameoforg.org)
4. Return to Tableau Server and view available workbooks
5. Select a workbook and click Open
6. Tableau prompts for server sign-in again, showing https://fs.nameoforg.org
7. Error appears: “Cannot connect to Tableau Server. Please check the server name and port and try again.”

I tried using agentforce to address this issue, and recommended using default browser to auth. I did the change and now this is the error that I'm getting:  

Unable to complete action 

Authentication failed. 

Error Code: 84223ADA 

Tableau received an OAuth error from your request.  Please see the error message for more information: Use JsonReader.setStrictness(Strictness.LENIENT) to accept malformed JSON at line 3 column 1 path $ 

See

. 

Can't seem to get tableau to work on macOS. I can use it on a VDI on windows but I rather use my own hardware since it is faster.  

My team has been testing out some Tableau Next features in an SDO and has been looking at the out of the box Individual Engagement Dashboard. We're having issues with null campaign and asset names, and because we're locked out of editing the dashboard, its component and the semantic model that it's built on, it's incredibly hard to troubleshoot the problem. The dashboard looks like this:

The Campaign DMO is populated and the Bulk Message Union logical view has Campaign IDs in it which map to the Campaign DMO, so they appear connected properly. I have no idea what the asset name is even meant to reference. 

Can anyone please give any suggestions on how to troubleshoot this or why there would be nulls here if you've experienced this issue before? It would be enormously helpful. 

Environment:

• Product: Tableau Server 2026.2 (20262.26.0912.1023)
• Operating System: Windows Server
• Deployment: 4-node Tableau Server cluster
• Nodes 2 and 3 are configured to run Backgrounder services. Before the upgrade, each node had one Backgrounder instance. Following the upgrade, we added one additional Backgrounder instance to each node, bringing the total to two Backgrounder instances per node.

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:

1. Executed tsm security rotate-coordination-service-secrets on October 2, 2026, at 20:01 UTC. The newly generated ensemble certificate is self-signed, has CN=*, and does not contain Subject Alternative Names (SANs).
2. Confirmed that the ZooKeeper server process (appzookeeper) runs with -Dzookeeper.ssl.hostnameVerification=false.
3. Compared the ZooKeeper client configurations used by Backgrounder and Non-Interactive services on the same node. Both have equivalent TSM-generated configurations, but Backgrounder connects successfully while Non-Interactive continues reporting hostname verification errors.
4. Executed tsm security regenerate-internal-tokens. The command completed, but the issue persists.
5. Confirmed that there are no pending TSM changes and that NTP synchronization is working correctly.
6. No PKIX certificate chain validation errors have been observed.
7. No manual modifications have been made to Tableau-generated keystores, certificates, or configuration files.

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:

• noninteractive_node3-0.log has grown to approximately 51 GB as a single log file.
• The appzookeeper services are generating approximately 48 GB of logs per day.
• The continuous errors are creating unnecessary disk I/O and increasing the risk of disk space exhaustion.

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:

1. Root cause: Why does the Non-Interactive Microservice Container fail ZooKeeper TLS hostname verification while Backgrounder, using an equivalent TSM-generated configuration, connects successfully?
2. Supported resolution: Is there a supported TSM configuration key, documented workaround, hotfix, or patch for Tableau Server 2026.2 that resolves this behavior?

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 

Hello, 

Our company uses a reporting calendar which starts on different dates each year (although always on a Monday); also, although most years have 52 weeks / 364 days, there are occasionally 53 weeks / 371 days in a year. 

In our database, we have two date-related tables, the first one maps each calendar date to a reporting period (day, week, month, quarter, year): 

The second one maps each calendar date to the corresponding reporting period's start and end date, including the dates for the year-on-year comparisons: 

Combining both tables into one shouldn't be a problem, but once done, I am not sure how to configure the custom calendar in Pulse so that data can be displayed correctly. 

The above date logic has already been incorporated into a view for the sales data, however in the Tableau dashboards, I have created custom calculations with parameters in order to show the sales - the problem is this just sets values outside of the reporting period to zero, meaning when I do the same in Pulse, the graph will start from the 1st of January, but the first of January until the start of the reporting year will just be a line with zero data, and then the last 3 or so months of the reporting year will get missed (since they are in the next calendar year). 

The main questions are: 

1. Does Tableau Pulse support a reporting calendar of varying lengths? When CY is 52 weeks, and LY was 53 weeks, the YoY comparison would be CY 1-52 vs LY 2-53; when CY is 53 weeks, and LY was 52 weeks, the YoY comparison would be CY 1-53 vs LY 1-52 + CY 1 (so week 1 gets double counted). So, it's not always just a simple comparison of Week 1 with Week 1 of prior year. 

2. Does Tableau Pulse support reporting calendars which start on different dates each year, e.g. 2026-03-30 vs 2025-03-31? 

If yes to both, how do I configure it so Tableau Pulse knows which date ranges to use? The key is that there is always a 364 day difference between CY and LY comparisons.