December 17, 2025 at 6:23 pm
thx steve, that was already done in step #2 following your recommendation. #1 just proved that db was accessible from another client.
i'm wondering if the community has heard that there is another way to turn on encryption in sql server through registry keys? and if yes, how i can see whether that was done here and if that would be concealed from me looking at such settings the usual way.
December 17, 2025 at 6:32 pm
turning on encryption for the server? Likely there is, but not sure I've seen this documented. Most of the server side items require the MMC for SQL Server Configuration Manager to set this.
For the client, it's setting the connection string property.
December 17, 2025 at 7:08 pm
may have to open a ticket with MS. will post back here what, if anything, that i find out.
December 17, 2025 at 7:12 pm

December 17, 2025 at 7:54 pm
tried following the instructions shown below , thru powershell, to determine if certain known registry settings might have been set but basically the error thrown was that there is no folder called SuperSocketNetLib...not on any of the drives including c:...
not sure what the HKLM portion means but i eventually went with c:\program files\microsoft sql server\...mssql\supersocketnetlib and got the ps error mentioned
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQLServer\SuperSocketNetLib' | Select-Object ForceEncryption

December 17, 2025 at 10:12 pm
i believe this is the problem. Does the community know what causes these values to be set to 1? Is that perhaps the default nowadays? I dont see them even in advanced ssas settings in ssms. 1=required.
in C:\Program Files\Microsoft SQL Server\MSAS16.MSSQLSERVER\OLAP\Config file msmdsrv.ini has these settings.
<Security>
<DataProtection>
<RequiredProtectionLevel>1</RequiredProtectionLevel>
</DataProtection>
<AdministrativeDataProtection>
<RequiredProtectionLevel>1</RequiredProtectionLevel>
</AdministrativeDataProtection>
December 17, 2025 at 10:36 pm
this gets better and better. we see the same values on another vm's config where there is no issue with processing full an ssas db. we also see the problematic server's native client is an older version than the one we installed on the vm where processing works. i'm going to wait a day or 2 to see what the community thinks before we do anything.
Viewing 8 posts - 16 through 23 (of 23 total)
You must be logged in to reply to this topic. Login to reply