reraided

CinciTech, I completely misunderstood what you described as your setup. Let me try again, and please confirm that I have it right now. You have a pair of SuperMicro servers running ESXi 6.7 (in a cluster ?), and using the QNAP to store the VMs. That would imply that the QNAP is seen as a VMware datastore. The VMs themselves are running 2016 Server and Photon. NWComputerGuy, Are you running Quickbooks Enterprise ? I haven't tried it, but as I noted above, QBDBSM for Linux is ONLY for the Enterprise version of Quickbooks. As a side note, QNAP's Linux Station currently only supports Ubuntu; they claim to have plans of supporting Fedora "in the future". That means converting the QBDBSM RPM via Alien, and then hoping it will install. I saw that after you were unable to get QBDBSM working on Fedora, you fell back to a Windows 7 VM running in Docker, which implies that Docker itself is running on a Windows OS. Per everything out there, you cannot run a Windows OS Docker container on a Linux host. Interestingly, QNAP's Virtualization Station does allegedly support running a Windows VM, even though QTS is an Ubuntu variant. So CinciTech, my numbered point list does apply, since NWComputerGuy has abandoned his effort to get the Linux QBDBSM to run. I am going to try to run the Windows QBDBSM on Fedora with WINE. If that works, I will try installing Fedora in QNAP Virtualization Station and then loading WINE and QBDBSM on top of that. So much for my contribution to the betterment of society. My situation is more challenging. I must run the Windows version of QBDBSM, since I have Premier and not Enterprise. Since the desktop Windows OS limits connections from other machines, and Windows Server OS does not, I will need to run some variant of Windows Server. The most recent successful report I have seen uses Server 2016 on Virtualization Station 3. That is a huge bite in terms of resources, in several ways. We don't need to speak about the obese nature of Windows, but there is something more at stake here. I have configured the QNAP with both interfaces teamed, and that has provided very good performance. If I run a VM using Virtualization Station, then I may need to break that team in order to provide a network connection to the VM. So it's a big jump from WINE on Fedora (very little resource consumption) to a 2016 Server VM on Virtualization Station (huge resource consumption), and I may lose my teamed network interface into the bargain. Nothing in between those two options. There is allegedly a 'bridge mode' network configuration which avoids my having to lose the teamed network interface, but I will burn that bridge when I get to it.

A few updates: Apparently, the Linux QDSM is a) a 32-bit app and b) provided as an RPM, meaning intended for RHEL-family Linux. There is the Alien package converter, but it won't address the bit-ness issue. There are also libraries which can help with the 64 bit to 32 bit issue, but I need more research to find out what that will do. QNAP QTS, on the other hand, is an Ubuntu variant, and at version 4.3.4 is a 64 bit OS. Not good news for this project. So running the Linux QDSM 'close to the metal' (as in directly on QTS) seems unlikely. I'm going to have a look at the options for a container.

see this: https://quickbooks.intuit.com/learn-support/en-us/configure-for-multiple-users/install-linux-database-server-manager/00/201632 I have seen a number of discussions out there on running the Linux Database Manager, and Intuit Tech Support confirmed that the Linux QDSM is only supported by the Enterprise version of Quickbooks. On the other hand, you are actually running it. It's hard to argue with success. So 2016 Server is running on the SuperMicro box, which is where the VM runs, and both QDSM and the Quickbooks database live on the QNAP, which is where the VM disks live. Separately, there is a server running RDS, with Quickbooks installed on it. What you want to do is run a VMware Photon container host on the SuperMicro server. What OS is that running ? Something which can run container hosts, right ? The VM disks would live on the NAS. Is the QB database inside the VM disk, or a separate file ? The QDSM container would link to the disks, which would include the QB database. The Windows clients would map to a CIFS share wherever the QB database is. Do I have that right ? In my case, the NAS in question is a QNAP TS-251+ with a quad-core Celeron and 16 GB of RAM. If the NAS is functioning as a file server (well, that makes sense, doesn't it ?) do I have enough guts to make this work ? The QB database isn't a very large file, and I can't imagine that a whole lot of network traffic is involved.

great to see this thread is still alive. your report that QDSM runs solidly is very encouraging. I have been advised by Intuit that the Linux QDSM is only applicable to the Enterprise version of QB, which I would imagine you are running. Bringing up two VMware hosts and 2106 Server doesn't sound like a small office. I was told, again by Intuit, that the database is an entirely different animal in the Enterprise version. If you have experience to the contrary, I would love to know it. It doesn't surprise me that QDSM runs well on 2016 Server, since that wqould be the Windows version of the software, not Linux. 2016 Server is also not exactly a small footprint. I agree with the idea that nothing is a substitute for good backups, and considering that the database is negligible in size, it would only take seconds to restore it from a backup copy. It would cause the loss of whatever information was entered up to that point in the day, though. I'm very interested in the RDS deployment you have. I'd like to know more details about how you did that. Maybe an offline discussion ? just so that I'm sure I followed what you wrote, you would be running containerized QDSM on top of the container, on top of Photon, on top of the VMware hypervisor, on the QNAP ? I was thinking of being able to run QDSM directly on the QNAP/Ubuntu NAS OS. The Windows version would require the things I mentioned above, such as WINE etc.

I was happy to come across this thread, since I, like others, have been looking at a way to get Quickbooks onto my NAS. I posted what follows in the Quickbooks Community forum, so you may find the same things there which I am going to share here. Needless to say, there is not much else there besides rants about Intuit not doing what the posters over there want. Certainly nothing useful from Intuit. I am NOT an Intuit employee, and I have a personal interest in accomplishing the goal of moving the QB database to my NAS. I am running 2019 Desktop. 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. The more layers between the app (QBDBSM) and the underlying OS, the more resources and less performance we are going to get. 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. Looking in the WINE app database, Quickbooks has been tested and awarded 'garbage' status, meaning that it won't even complete the install process. 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 C: 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. 11) If we run DBSM inside a container, where do we host the QB database ? Inside the container or on the host file system ? How will DBSM 'feel' about that ? Are we forced to do one or the other ? 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 ? Reply