I am NOT an Intuit employee, and I have a personal interest in accomplishing the goal of moving the QB database to my NAS.
It has been a while since QB 2016 was released.
Current software is 2019 Desktop, for those of us running local software.
It needs to be said that porting the database server manager to a vendor-specific NAS OS puts Intuit in the difficult position of having to retest and support the ported version with every release of each NAS vendor OS. Those releases often come months apart, if not sooner. Hiring a group of programmers to do something like that, which is strictly a cost line item with no related income is something that very few companies will do.
Having said that, it is important to consider the following issues (obstacles) in our way:
1) Most, if not all NAS vendors are running some flavor of Linux, so we need a way to run the DB server manager Windows app from Linux.
2) There are a number of solutions out there for doing this, notably WINE, which runs on top of Linux and translates Windows API calls to Linux equivalents. There is a growing library of apps which have been proven to run on WINE, but it will take the dedicated effort of SOMEONE to make that happen.
3) One of the requirements for DBSM is the ability to 'see' the file as living on a local drive. I'm not sure what makes it possible for DBSM to detect that a drive is mapped vs. local, but that will need to be figured out.
4) Another requirement is the ability of workstations to map a drive to the database host, so that they can open the file. That will require the ability to expose the abstracted drive in WINE so that remote machines can reach it. Anyone know how to do that ?
5) There are other solutions, such as Docker, which also have the ability to provide this functionality, which again will require research and maintenance. Any Docker gurus out there ?
6) Running a full-blown OS in a container will chew lots of resources on a NAS, so unless you have invested real money in one, meaning the cost of a server, it's not practical to do that.
7) DBSM may be a process running on top of an OS, but it has a GUI. Can it be launched without the GUI running ? Anyone try that ? It must be possible one way or another to reach the GUI so that you can configure the database setup. Can the process be reached remotely and the GUI invoked ?
8) Exactly what functions are being performed by DBSM ? Are all calls to the database being made through it, or is it simply a gatekeeper ? Someone would need to spend time with a network analyzer and some other tools in order to reverse-engineer the process (not that anyone I know would do such a thing).
9) There is a fundamental difference between a server and a desktop OS. One aspect of that is that the server version is optimized to 'serve' files. Accordingly, whatever underlying software there is for DBSM needs to not defeat that capability.
10) There are small versions of Windows OS, such as Windows Core Server or even Nano, but they don't have a GUI, so we run into the same issue mentioned above.
I will grant that none of the public-facing staff at Intuit have the depth of knowledge to discuss what is being said here, but at the same time, the above considerations are very real.
Still, if anyone is successful at implementing this, I'm sure that we would all jump at the chance to try it.
On the other hand, it would be absolutely unsupported, and, like the sign at the skating rink says, "at your own risk". Do we really want to roll the dice with some of the most critical data our companies have ?
