As you may have noticed by now the servicing model for SQL Server 2017 has changed. For details see:

https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-the-modern-servicing-model-for-sql-server/ 

One of the less known facts is that sql server and SSAS build numbers released in SQL Server 2017 cumulative updates do not match anymore.

The issue is described here:

https://docs.microsoft.com/en-us/sql/analysis-services/instances/analysis-services-component-version?view=sql-server-2017&viewFallbackFrom=sql-server- 

The article describes a method that allows to identify the SSAS build number from the corresponding CU KB articles.

However, the method is rather cumbersome and my quick search on the net did not find any page that provides an option for easy translation.

Therefore I’ll try to maintain a table that allows for easy translation between KB articles, CU numbers, sql build numbers, and SSAS build numbers.

*Note that KB articles list the SSAS file version in format 2017.140.XX.X , whereas file explorer + SSMS will display format 14.0.XXX.X

CU4/5/6 and CU8/9 have same build number for SSAS component.

Bypass traverse checking
(SeChangeNotifyPrivilege)

Then it can be that you might get one or both of the following problems:

a) If you are running windows 2012 in Core (no windows GUI enabled) mode and the SSAS service account doesn't have Administrative privileges

then SSAS service will not start. There is no error.

b) Even if the SSAS service account does have Administrative privileges then processing might fail when the SSAS service tries to make an impersonated call through the SQL Server Native Client or SQL Server OLEDB drivers.

You may see an Access Denied request if you use Process Monitor at:

HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\SNI11.0

You may get this error reported during the processing:

OLE DB error: OLE DB or ODBC
error: A network-related or instance-specific error has occurred while
establishing a connection to SQL Server. Server is not found or not accessible.
Check if instance name is correct and if SQL Server is configured to allow
remote connections. For more information see SQL Server Books Online.; 08001;
Client unable to establish connection; 08001; Encryption not supported on the
client.; 08001.

If you reinstall the SQL Native Client driver then it might be that the processing works again until the next restart of the Windows Server.

The problem is not thought to be related to the needs of SSAS service but rather the needs of the driver and the impersonated account.

This is just one situation which might result in those problems, it will not resolve all such situations.

I note that the SQL Server engine documentation indicates that this right is required :

https://msdn.microsoft.com/en-us/library/ms143504(v=sql.110).aspx

The following information was also reviewed:

https://technet.microsoft.com/en-us/library/dn221950.aspx

https://windowsitpro.com/systems-management/how-use-bypass-traverse-checking-user-right

“OLAP redirection service” is the part of SQL browser service that supports SSAS connectivity. If you stick to our recommendation to only use “virtual server name” for connecting to clustered SSAS instances (see previous post: https://blogs.msdn.com/b/as_emea/archive/2014/01/08/connecting-to-clustered-ssas-instances.aspx), then you won’t need the “olap redirection service”.

However, we are aware that there are some situations where customers have to use instance name addressing (<virtual server name>\<instance name>) due to client application requirements. As stated in my previous blog post this type of addressing is not supported by Microsoft, but it does usually work.

Using <virtual server name>\<instance name> in your connection string will lead to an attempt to connect to SQL Browser service in order to receive the port number for the desired SSAS instance. And here we will run into trouble if “olap redirection service” is disabled.

In the described situation your clients will be able to connect to the clustered SSAS instance using “virtual server name” or “<virtual server name>:<port number>”, but using <virtual server name>\<instance name> will give you the following type of error message:

“A connection cannot be made to the redirector. Ensure that ‘SQL  Browser’ service is running.
No connection could be made because the target machine actively refused it <IP-address>:2382 (System)”

The reference to port 2382 in the error message indicates that we were really trying to connect to the sql browser port for “olap redirection services”.

This type of error message could potentially be triggered by other issues as well.
F.i. firewall issues (port 2382 blocked) or permission issues (sql browser service account has no access to its configuration file  “msmdredir.ini”).

Further symptoms/characteristics of a disabled “OLAP redirection service” are:

1. Using “netstat –ab” command or “tcpview” tool from sysinternals you will see that “sqlbrowser.exe” is running, but not listening on port tcp 2382.

2. When starting “sqlbrowser.exe” as a console application from command prompt you won’t see the start up message for “OLAP redirection service” marked in yellow.

C:\Users\xyz>"C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe" -c
SQLBrowser: starting up in console mode
SQLBrowser: starting up SSRP redirection service
SQLBrowser is successfully listening on ::[1434]
SQLBrowser is successfully listening on 0.0.0.0[1434]
[6896]: Received request...
[6896]: Waiting for next request...
[6896]: Received request...
SQLBrowser: starting up OLAP redirection service
[6896]: Waiting for next request...
...

According to our setup logic for stand-alone SSAS instances the “olap redirection service” should only be disabled when the last named SSAS instance is being removed. Which makes good sense.

For clustered SSAS instances the logic is altered and the “olap redirection service” will be disabled when you have two SSAS instances on the cluster node, and you are removing one of them. Setup will incorrectly disable “olap redirection service” and the remaining SSAS instance cannot be reached via sql browser service anymore.

When saying “incorrectly” I should probably remind you that we do not support usage of “sql browser”/”olap redirection services” for clustered SSAS instances.

In the sql setup logs for the last uninstall of a clustered SSAS instance you will find the following entry :

2013-10-17 18:21:33 AS: Data : (Utility) KeyPath=SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server\90\SQL Browser,KeyName=AnalysisServiceListener,KeyValue=0

This is the root cause. We effectively disabled AnalysisServiceListener = “olap redirection service”.

The described problem will only appear in a situation where you have two SSAS instances on the cluster node, and you are removing one clustered SSAS instance. The remaining SSAS instance will have no “olap redirection service” available anymore.

For restoring “OLAP redirection service” functionality you will have three options:

a) add a new clustered SSAS instance (verified)

b) run setup repair function (may help)

c) manually set the AnalysisServiceListener key from “0” to “1”.

The issue will be fixed with the next release of SQL Server Analysis Services.

The "Analysis Services MOLAP Performance Guide for SQL Server 2012 and 2014" document can be downloaded from MSDN via the following link:

https://msdn.microsoft.com/en-us/library/dn749781.aspx

As the name suggests it contains advice on how to optomize performance of multi-dimensional (MD) Analysis Services Instances.

For tabular Analysis Services Instances please have a look at the previously released "Performance Tuning of Tabular Models in SQL Server 2012 Analysis Services" document at  https://msdn.microsoft.com/en-us/library/dn393915.aspx.

It discusses many SSAS clustering aspects including setup + configuration, deployment modes, connectivity, and administration.

Many thanks to MVP Alan Hirt and Heidi Steen from the MS content team for all the efforts that went into its creation.

You can download the white paper form the folllowing MSDN  link:

https://msdn.microsoft.com/en-us/library/dn736073.aspx 

Let’s start with the hopefully well known behavior for non-clustered SSAS instances.

Stand-alone Instances

All default SSAS instances will listen on port tcp 2383. Thus you will simply connect using the “host name” of the box where the SSAS instance is installed and the SSAS provider understands that the SSAS default port 2383 should be addressed.

For named instances the situation becomes a bit more complex. Named instances usually use dynamic port allocation and you cannot predict with confidence which port is going to be used after a restart of the service. Therefore we have an intermediate service called “sql browser service” which does the mapping between instance names and port numbers. The resource file in use by sql browser is “msmdredir.ini” and it usually resides under the following path:

C:\Program Files (x86)\Microsoft SQL Server\90\Shared\ASConfig

In the msmdredir.ini file you will find the <instances> section which shows a mapping of instance names to port numbers.
If you have IPv4 and IPv6 protocols enabled, then there will be two port entries per instance.

f.i.

<Instances>
    <Instance>
            <Name>TABULAR</Name>
            <Port>50732</Port>
            <PortIPv6>50732</PortIPv6>
        </Instance>
    <Instance>
            <Name>MDTEST</Name>
            <Port>50731</Port>
            <PortIPv6>50731</PortIPv6>
        </Instance>  
</Instances>  

When you connect to a named SSAS instance using the instance name (“Hostname\InstanceName”), the the provider will contact the SQL Browser Service under port tcp 2382. SQL browser will then search for the instance name being queried and return the port information that was registered in “msmdredir.ini” to the provider. Thereafter the provider can establish a connection to the named SSAS instance using the port number it received from sql browser.

The SQL Browser behavior is pretty similar to what you may know from relational SQL Server instances. The difference being that for relational SQL Server instances the SQL browser Service listens on port UDP 1434 and it sources its port info from the registry. For SSAS instance connection requests the sql browser service will listen on port TCP 2382. And the requested port information is read from “msmdredir.ini” file.

The SQL browser module that is used for SSAS connectivity is also referred to as “OLAP redirector service”.

Clustered instances

Now lets go to the subject of clustered SSAS instances. Clustered SSAS instances behave differently from what you may know of clustered SQL Server instances. All clustered SSAS instances, no matter whether they were originally installed as default or named instance, behave like default instances and listen on port 2383. That’s assuming you started the SSAS instance properly via cluster administrator or cluster service. If you start a named instance on a cluster node outside of cluster service then it is a stand-alone instance and will use dynamic port allocation as discussed earlier.

The only supported way to connect to a clustered SSAS instance is to use the “virtual server name” (also called network name). Usage of the instance name like in  “VirtualServerName\InstanceName” is not supported! One reason being that all clustered instances will always run on port 2383 and thus we don’t need to specify the instance name. The other reason being that the SSAS part of SQL Browser service functionality (OLAP redirector service) is not cluster-aware and we cannot guarantee that the content of “msmdredir.ini” is always updated correctly.

In this context “not supported” does not mean that connectivity via instance name does not work. In fact it usually does work. But we cannot guarantee that it will always work in a stable fashion. Therefore our strong recommendation is to always use “VirtualServerName” (=Network name) for establishing connections to a clustered SSAS instance.

The error message typically looks similar to this:

Exception Message: File system error: The following file is corrupted: Physical file:

\\?\T:\Data1\OLAP\Data\Tfs_Analysis4.0.db\File.0.dim\52.ParentFileSK.FileSK.dstore. Logical file .

When you look at the referenced .dstore file (from last successful processing) in the data folder of the SSAS instance, then you will likely notice that the file size approaches 4 GB.

The File dimension in TFS database is set up as a parent/child dimension. And it contains file names from all projects managed by TFS.

In all problem cases I have seen so far the decode store reaches 4 GB when there are about 48 million members in the File dimension.  If your TFS data warehouse has a File dimension source table "DimFile" with more than 48 million records, then you can hit the error.

You can quickly check the row count in the "DimFile" table of the TFS data warehouse by executing the following T-SQL query in SQL Server Management Studio (SSMS):

SELECT COUNT(*) As 'RowCount' FROM [TFS_Warehouse4].[dbo].[DimFile]

The observation that we get a processing failure whenever we approach a file size of 4 GB seems to indicate a file size limit, similar to the one we observe for SSAS string stores.  However, that's not the case!

In fact we don't have a file size limit for any SSAS file store! The only thing we do have is a record number limit. Every file store can support up to 2^32 (4 giga) records. For string stores each character in a string is treated as a separate record. Meaning that we will reach the record number limit at 4 GB file size.

Decode stores ( .dstore) allow to quickly identify all ancestors for a given the attribute member. A decode store record contains the DataID values for all ancestors of a given member. Thus a record size will be much larger than a byte and we won't be anywhere near the 4 G record limit when the .dstore file size reaches 4 GB.

Further research showed that the problem is related to a code defect that happens to be triggered when file size reaches 4 GB. It was previously observed for partition data files and is described in KB article 2652738:

FIX: "File system error" error when you process a large dimension https://support.microsoft.com/kb/2652738/EN-US

The fix came as part of a SQL Server 2008 R2 SP1 and SQL Server 2012 cumulative updates.

Thus our recommendation is to install the latest Service Packs SQL Server 2008 R2 SP2 or SQL Server 2012 SP1. Both Service Packs include the fix.

Unfortunately we do not have a fix for SQL Server 2008. If you are using SQL Server 2008 and upgrading is no option, then the only way to to get the TFS database processing going again will be to decrease the number of records in the DimFile table to a value well below 48 million.

However, adding to the SP1 issue that was described in previous blog by Guillaume Fourrat we observed two further SSAS related problems that affected several customers.

Issue 1:

 Powerpivot workbooks with corrupted table relationship(s) will raise the following error message when opened with SQL server 2012 SP1 Powerpivot add-in:

Microsoft Excel: Measure group 'MeasureGroup' missing reference dimension for existing indirect relationship to dimension 'Dimension'

Reason being that SP1 code introduced a check of table relationships as part of the model upgrade. Unfortunately the meant that affected workbooks could not be opened with SP1 Powerpivot add-in.

With the newly released SQL server 2012 SP1 CU3 Powerpivot add-in the broken table relationship(s) will be fixed automatically when workbook is opened uand you can open the problem workbooks without issues.

CU3 KB article with hotfix link: https://support.microsoft.com/kb/2812412/en-us

 KB for Powerpivot workbook issue: https://support.microsoft.com/kb/2801889

From SLQ Server 20121 SP1 CU3 you would need to install one of the following Powerpivot add-ins depending on excel bitness:

 64 bit:  2012_SP1_PPExcel_CU3_2812412_11_0_3349_x64

32 bit:  2012_SP1_PPExcel_CU3_2812412_11_0_3349_x86

Issue 2:

After SQL Server 2012 SP1 upgrade some of your MDX queries that used to work fine may suddenly fail with error message:

The MDX function failed because the coordinate for the 'AttributeName' attribute contains a set.

This issue is caused by a regression that was already introduced with SQL Server 2012 RTM CU2 fix.

However, since many customers do not install cumulative updates without a specific need (which is our recommendation), the issue became more widespread with SQL Server 2012 SP1 release.

If you observe this issue,then please install the SQL Server 2012 SP1 CU3 fix. Thereafter your problem queries should run successfully again.

CU3 KB article with hotfix link: https://support.microsoft.com/kb/2812412/en-us

KB for MDX query issue: https://support.microsoft.com/kb/2823086

Please note:

 SQL Server 2012 SP1 CU3 fix can introduce issues with SSIS packages (and thus also with maintenance plans).

see sql connect bug https://connect.microsoft.com/SQLServer/feedback/details/781921

An "on demand" Hotfix for this problem can be downloaded from the following KB Article link: https://support.microsoft.com/kb/2832017