Open mawarnes opened 1 year ago
vaibhav-shimpi-maersk
commented
1 year ago I have the same problem, the FIlestream is not taking the MSSQLSERVER as the parameter and the registry entries is also missing the Filestream settings.
Following is the error being encountered -
P.S. - I have tried it with SQL Server 2022 developer and express version on windows 11 arm image. I have also tried changing the log on as - to local system, local admin accounts along with NT SERVICE\MSSQLSERVER
vaibhav-shimpi-maersk
commented
1 year ago @mawarnes - Any luck to resolve this issue? Thanks!
T-0MM
commented
11 months ago I did some research about that topic on a SD 8cx device with Win11 64bit. Problems are similar to that with M1.
My experience with SQL Server 2014 Express 32bit (not the wow64 installer which doesn't start because of wow64 rule): Yes, you can install it without problems but you can't enable Filestream then in the SQL Configuration Manager... After some time you learn that you can add registry settings here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SQL Server\MSSQL12.SQL14\MSSQLServer\Filestream - and it appears to work - the checkbox is checked and the sharename is displayed. It appears... but in SQL Manager you can't enable filestream for your sql instance because of a wow64 error message... I believe that would be the same with SQL 32bit under Win 64bit on x86 - no arm issue...
Moving on with SQL 2019 Express 64bit using this powershell script. I immediately added the registry entries here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.SQL19\MSSQLServer\Filestream, but it hasn't the same effect as with SQL 2014. With procmon (and comparing with reg queries on SQL 2014) i see that using the SQL 2019 Configuration Manager these registry entries won't be read at all. I suspect that's the case because of absence of a WMI instance of the class 'FilestreamSettings' in the 'ROOT\Microsoft\SqlServer\ComputerManagement15' namespace. With SQL 2014 this instance is there (namespace is ComputerManagement12 respectively).
IMHO it is a combined WMI / registry issue which arised because of the 64bit setup (version irrelevant) can't complete it's work. The author of the script thankfully figured out though that it has completed enough to have a launchable sql service if it gets some directories and system tables to work with. But some parts like WMI instances and registry entries are still absent - which are important for filestream and such. If somebody knows how to add the mentioned WMI instance... feel free to pick up at this point! I just couldn't successfully create an instance using wbemtest having a access denied issue... which i couldn't resolve (I'm just no WMI expert after all). Maybe i missed something using wmimgmt/security.
It's a shame that microsoft isn't investigating this - I believe it would be no big deal and they would have much more insights in their own products running on their own product...
Another idea would be to manipulate workflow-chains inside the sql server setup to eventually skip a dispensable package. If someone is looking for new original ideas on that problem... :)
Another lesson learned is to implement a fallback method to do without filestream - which is in my case is the way to go compared to getting filestream working.
GuiguiDaan
commented
11 months ago I did some research about that topic on a SD 8cx device with Win11 64bit. Problems are similar to that with M1.
My experience with SQL Server 2014 Express 32bit (not the wow64 installer which doesn't start because of wow64 rule): Yes, you can install it without problems but you can't enable Filestream then in the SQL Configuration Manager... After some time you learn that you can add registry settings here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SQL Server\MSSQL12.SQL14\MSSQLServer\Filestream - and it appears to work - the checkbox is checked and the sharename is displayed. It appears... but in SQL Manager you can't enable filestream for your sql instance because of a wow64 error message... I believe that would be the same with SQL 32bit under Win 64bit on x86 - no arm issue...
Moving on with SQL 2019 Express 64bit using this powershell script. I immediately added the registry entries here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.SQL19\MSSQLServer\Filestream, but it hasn't the same effect as with SQL 2014. With procmon (and comparing with reg queries on SQL 2014) i see that using the SQL 2019 Configuration Manager these registry entries won't be read at all. I suspect that's the case because of absence of a WMI instance of the class 'FilestreamSettings' in the 'ROOT\Microsoft\SqlServer\ComputerManagement15' namespace. With SQL 2014 this instance is there (namespace is ComputerManagement12 respectively).
IMHO it is a combined WMI / registry issue which arised because of the 64bit setup (version irrelevant) can't complete it's work. The author of the script thankfully figured out though that it has completed enough to have a launchable sql service if it gets some directories and system tables to work with. But some parts like WMI instances and registry entries are still absent - which are important for filestream and such. If somebody knows how to add the mentioned WMI instance... feel free to pick up at this point! I just couldn't successfully create an instance using wbemtest having a access denied issue... which i couldn't resolve (I'm just no WMI expert after all). Maybe i missed something using wmimgmt/security.
It's a shame that microsoft isn't investigating this - I believe it would be no big deal and they would have much more insights in their own products running on their own product...
Another idea would be to manipulate workflow-chains inside the sql server setup to eventually skip a dispensable package. If someone is looking for new original ideas on that problem... :)
Another lesson learned is to implement a fallback method to do without filestream - which is in my case is the way to go compared to getting filestream working.
I did some research about that topic on a SD 8cx device with Win11 64bit. Problems are similar to that with M1.
My experience with SQL Server 2014 Express 32bit (not the wow64 installer which doesn't start because of wow64 rule): Yes, you can install it without problems but you can't enable Filestream then in the SQL Configuration Manager... After some time you learn that you can add registry settings here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SQL Server\MSSQL12.SQL14\MSSQLServer\Filestream - and it appears to work - the checkbox is checked and the sharename is displayed. It appears... but in SQL Manager you can't enable filestream for your sql instance because of a wow64 error message... I believe that would be the same with SQL 32bit under Win 64bit on x86 - no arm issue...
Moving on with SQL 2019 Express 64bit using this powershell script. I immediately added the registry entries here: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL15.SQL19\MSSQLServer\Filestream, but it hasn't the same effect as with SQL 2014. With procmon (and comparing with reg queries on SQL 2014) i see that using the SQL 2019 Configuration Manager these registry entries won't be read at all. I suspect that's the case because of absence of a WMI instance of the class 'FilestreamSettings' in the 'ROOT\Microsoft\SqlServer\ComputerManagement15' namespace. With SQL 2014 this instance is there (namespace is ComputerManagement12 respectively).
IMHO it is a combined WMI / registry issue which arised because of the 64bit setup (version irrelevant) can't complete it's work. The author of the script thankfully figured out though that it has completed enough to have a launchable sql service if it gets some directories and system tables to work with. But some parts like WMI instances and registry entries are still absent - which are important for filestream and such. If somebody knows how to add the mentioned WMI instance... feel free to pick up at this point! I just couldn't successfully create an instance using wbemtest having a access denied issue... which i couldn't resolve (I'm just no WMI expert after all). Maybe i missed something using wmimgmt/security.
It's a shame that microsoft isn't investigating this - I believe it would be no big deal and they would have much more insights in their own products running on their own product...
Another idea would be to manipulate workflow-chains inside the sql server setup to eventually skip a dispensable package. If someone is looking for new original ideas on that problem... :)
Another lesson learned is to implement a fallback method to do without filestream - which is in my case is the way to go compared to getting filestream working.
If I understand what have you said, that's mean it's necessary to edit the script and add every good setting corresponding to FILESTREAM ?
jimm98y
commented
5 months ago I've been looking into it this weekend and I think the main issue here is that FILESTREAM requires a system driver RsFx0700.sys which is available only as x64 binary. To make it work on ARM64, Microsoft would have to recompile it as ARM64X binary which probably won't happen anytime soon.
Hi, first of all thank you very much for putting these script together, it's absolutely fantastic work. Everything is good, except I cannot turn on filestream. I've tried all the usual options, and I'm just wondering why this might not be working. I'm sure there are limits to what is achieveable here, but do you have any ideas even it's even a reasonable ask to try and get it working?