Quickbooks Database Server Manager


Recommended Posts

So I am looking for a little guidance, and I'm pretty sure from everything I've read and watched that Docker might be my friend in this endeavor! 

I recently had my home office server crash, thankfully I had everything backed up and current and so data loss was not an issue.  The problem was a failure of windows, it was the last straw so I started hunting for an alternative, I found unRAID and was very impressed, it filled every need and seems to be much more stable for my environment!  The only thing it lacked was out of box support for my Quickbooks.

Quickbooks used to be able to use a file saved on a NAS or File Server with no problem, however new additions required the Quickbooks Database Server Manager program to manage multi users and storage.  This is why I had been using Windows.  However after a little bit of research I found that they had a Linux release of the manager in RPM (Fedora/RedHat) 

My Question is two fold, one: Do I need to install a full VM of Fedora to run this program or Two: Can I run just the program it'self in a Docker?

 

This is a link to the documentation I have checked out fro Quickbooks!

 

https://community.intuit.com/articles/1552445-install-linux-database-server-manager

Link to comment
2 hours ago, NWComputerGuy said:

My Question is two fold, one: Do I need to install a full VM of Fedora to run this program or Two: Can I run just the program it'self in a Docker?

Looking at the docs, here's how I would approach it.

1. Set up a full VM, follow the intuit directions explicitly, ensure that things actually work. I've been dealing with quickbooks for around 20 years, and past experience with the company informs me that your chances of everything "just working" is pretty much none. I would anticipate having to find workarounds and poorly documented procedures to get things working, even when you are following exactly what they say.

2. Assuming you get a working environment in a full VM, proceed to transfer that knowledge to a docker, and see if you can duplicate your VM success.

 

Can you tell I'm bitter? I've spent HOURS, many not billable, deciphering why various versions of quickbooks over the years have failed to perform or even function when installed as prescribed by their docs on plain vanilla windows server networks. Their latest offering failed to start the database manager unless you disabled some of the default services of a windows server 2016 domain controller.

  • Like 1
Link to comment

I laughed when I read your last paragraph,  I completely understand your feelings of frustration with this company!

Thanks for your advice, I'll give it a shot in the VM and share the results.

I hope my little adventure with this issue can assist others in the same boat or maybe inspire a programmer to take matters into their own hands!!

Thanks -Scott  

Link to comment
  • 6 months later...

I'd be happy to provide an update!

So after playing around with red head for a while and signing let it did not work as I expected it to with QuickBooks database manager I tried a new branch called fedora hoping that the structure would be a little bit more solid for what I was trying to do. Unfortunately I ended up with the same result, and the QuickBooks database manager did not work. So unfortunately I had to Resort back to Windows so I created a docker image of Windows 7 and installed Quickbooks on there in the default way and chose the store my file on this computer option, in essence using it as a server.

It's been a couple months now since I set up the system and it has been damn near Bulletproof, I still have access to my files with no problem and I get the benefit of having it backed up on an unraid server so I get the bonus of that environment.

Plus it doesn't hurt that Windows 7 computer networking is vastly easier then getting Linux computers to freely share with Windows PCS don't know why but I always have problems with networking Linux and windows together just seems to be my kryptonite. LOL

  • Like 1
Link to comment
  • 2 weeks later...
On 11/2/2018 at 8:21 AM, NWComputerGuy said:

so I created a docker image of Windows 7 and installed Quickbooks on there in the default way and chose the store my file on this computer option, in essence using it as a server.

 

Hey NWComputerGuy,

 

I am looking to do the same thing you did with Quickbooks. How do you create a docker image of Windows 7. I can only find info on how to create windows as a VM.

 

Thanks!

Link to comment
  • 1 month later...

I was reading through this thread thinking it was 10 years old..but it’s rather new! I feel the pain all around but have a glimmer of hope; I’ve been running the QB Enterprise Server on Linux for years now for multi-users and it rather “stable”. 

 

Now it was a pain in the ass, docu,entatikn is next to nothing, and the last 10 years Intuit’s support (including enterprise support) does not cover how to actually install and manage their software. I went as far as contacting them asking for support on version 2014 only to be told they didn’t have a Linux install... Christ their documentation doesn’t even change between versions, they just update the date and version number.

 

Ok, enough complaining, on to the important bits. I’m about to roll out QB Enterpise 2019 on a Linux box and wouldn’t mind writing my own documents on it for others to use. My end goal is to containerize it and try to automate it from version to version, along with management controls for sys-admins.

 

Any interest?

 

 

  • Like 1
  • Upvote 1
Link to comment
On 11/16/2018 at 1:03 PM, jh1987 said:

Hey NWComputerGuy,

 

I am looking to do the same thing you did with Quickbooks. How do you create a docker image of Windows 7. I can only find info on how to create windows as a VM.

 

Thanks!

Sorry I didn't explain that better (At the time, I was still very new at UnRAID terminology) I did indeed use a VM with a Standard install of Windows 7 Home Prem. and not a Docker container!   Hope you were able to still setup your Quickbooks!

Link to comment
On 1/9/2019 at 7:05 PM, NWComputerGuy said:

Sorry I didn't explain that better (At the time, I was still very new at UnRAID terminology) I did indeed use a VM with a Standard install of Windows 7 Home Prem. and not a Docker container!   Hope you were able to still setup your Quickbooks!

No problem I figured out that is probably what you meant. I can't seem to get good performance from my VM. What are your hardware specs like? Do you experience any slowdowns? It seems like my VM is really sluggish.

 

Also, do you just host your files on the VM and then access them on another computer or do you log in to your VM whenever you use Quickbooks?

 

Thanks!

Link to comment

When I originally set up my VM I only did it with one core but I switched it over to 2 cores with 4 gigs of memory.  I found that I needed a little extra memory for the multiple users.  I also set it up so that way it's only role was to host the file with the database server running on VM. All of the other computers are set up with the primary software and then I map the drive to the VM. I get pretty good performance and of course QuickBooks is notoriously slow to begin with so it really doesn't matter how much processor you shove behind it!

Link to comment
  • 6 months later...

Just learned today that there was a Linux-compatible QB database component, and immediately Googled (without hoping to find something) that someone went and tried it out with Docker, and then I found this thread.  Sorry in advance for digging up a 7-8 month old post, but I just wanted to touch base here to see if anyone has gone any farther with containerizing the QB database server?  I support an customer who uses QB 2014-2019, and while it's been "okay" to use a full Windows fileserver VM to store the apparently-required-because-Intuit-can't-manage-files-using-CIFS/SAMBA-like-everyone-else-does Database Manager component...  But being able to isolate it onto its own lightweight virtual appliance would be much easier to manage.

 

I've had a lot of success moving various network services to Docker containers on VMWare Photon 3.0, so I'm likely going to head down this path and I'll write up my findings for others.  In the meantime I'm just looking to see how far others have been able to carry this football.

Link to comment
  • 1 month later...

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

Link to comment

I'll throw in my thoughts, which are directly related to my experience and may or may not apply to everyone's use-case. I manage a virtual platform with two physical hosts running VMWare ESXi 6.7, virtual machines run from a QNAP NAS and are backed up to a Synology NAS, and I've fallen in love with VMWare's Photon OS as a super-slim VM that comes with Docker pre-loaded, all in a 155MB download. It's designed to use minimal resources, as we all generally understand that Windows is a resource hog. I've had great success deploying Docker containers for everything from PiHole and Nextcloud to MySQL/Wordpress/Adminer/FTP/CertBot (Let's Encrypt) for public hosting of multiple websites. I haven't yet taken on the challenge of creating a Docker container from an existing project, although I plan on trying this when I get some time. Firstly, this thread is about running the Linux QDSM, potentially in a Docker container, so most of your numbered points either wouldn't apply or are answered by virtue of how the Linux QDSM the OP linked would (theoretically) work in a Docker container. We also have QDSM running in Windows Server 2016 with various versions of QB running from a Windows Server 2016 RDS and it's been pretty solid.

 

Having said that, I believe everyone should accept only as much risk as they can be comfortable with in their environment. I virtualize everything I can because backups are simple, snapshots can protect you from problematic updates where you aren't able to test the updates in a sandbox environment, and resources can be allocated pretty much on the fly when you find you need more. Should we roll the dice? I think as long as you have good backups of your critical data along with regular restore tests to prove you can go back when needed, you're no less 'safe' than however you host your data today. The benefits I'm looking for in this approach are reduced resource utilization, increased performance, and reduced footprint in my backup pool (IE: quicker restores from backups in the event of anything from hardware failure to ransomware attacks). I wouldn't deploy such a thing if it weren't properly vetted in my environment, but if it were to test well I would be comfortable rolling the dice as long as I can simply "undo" if it comes up snake-eyes.

 

 

So, I posted at the end of July and haven't seen any updates since January. I will hopefully go down this path and post my results for anyone else interested, but I'm curious if @ForgottenPoundSymbol or anyone else has had any luck Dockerizing the Linux QDSM?

 

Link to comment

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.

Link to comment

We're not using the Enterprise version. We use the Quickbooks Pro and Accountant versions. I'm good with offline discussions, although I suppose it may be worthwhile to share in another thread what we've got and how it's configured; maybe it helps other people and maybe someone has some improvements for me.

 

This is the first I've heard that the Linux QDSM is Enterprise-only, which would be disappointing if true. We're signed up with Microsoft Volume Licensing, which is surprisingly affordable, especially compared to VMWare's High Availability package (unrelated rant to be held over drinks at some bar somewhere else). The VMs are stored on the QNAP, but they run on SuperMicro rack-mount servers (roughly 2.5k each, but they also provide for email and web hosting and internal chat, so it was easier to absorb). There is a Windows 2016 file server with QDSM running on it where all the various QB files get stored. Installing QB on an RDS is fairly straight forward, with QB Pro & Accountant versions installed using the "Install Application on Terminal Server" shortcut in Control Panel.

 

Ideally, I want to create a Photon VM, add a virtual hard disk just to store QB files, then create/deploy a QDSM container with the virtual disk linked as the data folder. Maybe a SAMBA container would be needed to share the QB files over CIFS to Active Directory users (I'll need to learn more about the Linux QDSM to understand that). In my case the Photon VM would be stored on the NAS and run from the SuperMicro server, but if you have a NAS capable of running Docker containers then it could all run from there (assuming the CPU and RAM were beefy enough). And Windows Docker users would equally be able to run the same thing, which is the magic of containers in the first place.

Link to comment

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. 

Link to comment
On 10/2/2019 at 9:33 AM, reraided said:

On the other hand, you are actually running it. It's hard to argue with success.

To re-clarify, we are running the Windows version, on Server 2016. We are not currently running the Linux QDSM (but would like to in order to eliminate a Windows VM).

On 10/2/2019 at 9:33 AM, reraided said:

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.

I might try to put a drawing together in Visio to help illustrate, but... ESXi 6.7 is the operating system on the SuperMicro. It is designed to do little other than run virtual machines, including Windows Server 2016 & Photon 3.0 in our case. We are already running a handful of Photon 3.0 VMs with Docker containers and they work amazingly. In one case we replaced a Windows certificate authority server with a Photon using OpenSSL for CA; this reduced the RAM and CPU utilization from 8GB to 20MB and a couple GHz to 0Hz most of the time (and saved ourselves a Windows OS license to boot).

 

So, I'm 100% confident I can throw another Photon VM and stick Docker containers in it. All I would need in my case is a containerized version of QDSM, (which it seems may not work until we cough up more money for Enterprise licensing, so I could be dead in the water already). ESXi stores virtual disks in "datastores", which can be a local disk or a NAS/SAN, so the fact that the virtual disks will be on a NAS is mostly for reference; it's not a potential limitation for a virtual environment.

 

On 10/2/2019 at 9:33 AM, reraided said:

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. 

We have a bunch of customers' QBD files on a network share, so our "database" is a whole bunch of random QB? files. The share includes a fair amount of backed up company files as well as all the temp files Quickbooks creates, so it's hard to know what our true "database size" is. It seems we have about 11.5GB of QBW files, which may be the closest thing I've got to an accurate count. It is a Windows Server 2016 file server with all the roles and features installed for CIFS and DFS replication (although we don't currently have a secondary file server stood up for replicating anything to). The file server VM is allocated 4 CPU cores and 8GB RAM; it is using right around 2.1GHz and ~400MB RAM, according to the virtual monitoring in ESXi. With all that said, I have to believe most of that is consumed by the Windows overhead, and although I can speculate and say I believe a Linux VM running QDSM and Samba would need a fraction of those resources, I cannot say for certain how much it would truly need.

 

With that great big disclaimer in mind, I would think you've got plenty of CPU/RAM to at least try deploying it on your NAS in a container, providing you're able to deploy containers in your NAS (I haven't messed with ContainerStation so I don't know how easy it is/isn't). If it's too much for your system you can always shut down the container and go back to what you're doing today. I think the difficult part here is that no one has created a containerized QDSM yet.

Link to comment

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.

Link to comment
  • 4 weeks later...

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.

 

Link to comment
  • 8 months later...

Just to throw another $0.02 in the bucket, i've been doing something similar but via the mac route.

 

since spaceinvader released the macinabox container last year, i spun up a mac vm and threw my quickbooks server for mac on it, and it's been running flawlessly for months. my clients are still mac's on the local network, just running the server portion on the (dedicated) mac vm and have no complaints. but mark me down as a +1 if anyone ever manages to containerize a QB instance

Edited by Cpt. Chaz
typo
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.