Have you ever encountered a problem, one that is clearly prolific in the digital world but you just can’t find the solution on the Internet? MUM on QuickBooks has always been that way for me. If I had a nickel for every time one of my mom’s staff members called me complaining of H202 or some other error when trying to flip over to multi user mode, well I’d have a lot of nickels.

To be clear, QuickBooks is utter trash. There is no excuse for them to not to support some sort of proper database configuration instead of using their garbage Sybase with their garbage .net connector… they can if they want, but after 15 years+  they should also give us the option after storing data in a proper database using proper communication tools.

That said, if you’ve found yourself here let me just self-proclaim to be the smartest person in the world when it comes to configuring servers for MUM. I must be because I’ve had to discover the solutions to all the hurdles myself – it’s just not CLEARLY documented on the Internet.

Here are the big things to look at:

1) Firewall

The rules you need to configure are here:

https://community.intuit.com/articles/1197814-error-h101-h202-h303-or-h505-when-opening-your-company-file

If you call Intuit support with the H202 problem they will happily direct you to this page. If this doesn’t solve it then your environment is the most exotic environment on the planet and there is no escalated support to help you troubleshoot, you’re on your own. If you disable the firewall entirely and still have issues, this isn’t your problem anyway.

2) Use hostnames, not fqdns.

This is clearly why none of the Quickbooks client software doesn’t and never will work on non Windows OSs. By default all Linuxes I know of will lookup a hostname in DNS first, of course attaching the domain suffix. If you try to connect to a company file using \\fqdn\share\file.qbw it will H202 every time. So… if your users have shortcuts on their desktops or if you’re mapping a drive with GPO etc, make sure that the UNC path does NOT have the fqdn. That was a fun one to try to solve. Now to be brutally honest I don’t really know what the difference is to Windows since WINS is disabled in all of my environments. It’s either related to Netbios over TCP or something muddy they actually did in the database server code. It absolutely should be fixed, I habitually type FQDNs and it’s just a matter of fact that this bug goes against all the rules in the DNS RFCs.

3) Don’t disable IPv6 – Prefer IPv4

Often times you’ll find in your ND file an IPv6 address. I’d like to think that IPv6 should work just fine, but often times it doesn’t – namely if you have a routed IPv4 network in your environment, but haven’t accommodated connectivity for IPv6. In this case disabling IPv6 won’t help you, it will harm you. Instead follow this guide and use 0x20 to prefer IPv4.

Those are the big issues that haunted me. Using what I know today I can successfully host MUM on any Windows server dating back to 2008. If you run into any issues that you’re unable to surmount or have anything to add feel free to drop me a line.

Awhile back Google threatened to make 3rd party applications unable to login to Google Voice over XMPP.  I don’t rely heavily on the service, however I do have a few desk phones for convenience sake that rely on these connections, one in particular for my wife’s grandma who happens to live with us and is definitely beyond hope for using an iPhone. I don’t care to have a dialtone run to my home because of both the cost and the simple humility of thinking about such a barbaric technology invading my home.

I recently added another Google Voice “trunk” to my FreePBX box to add some additional simplicity to life, but found that it wasn’t working well I thought maybe my newly created account was subject to the threats formerly made. I read a lot about how the problems can be worked around by recompiling Asterisk and using oAuth (don’t sign up for an acct at PBXIAF, just read on) – all of which sounded way more complicated that I was prepared to go through and maintain for this particular nearly unused application.

A bit of additional digging, Googling and investigation based upon some of the E-mails I was getting reading :

led me to find that this can be easily remedied. Google has created a page https://www.google.com/settings/security/lesssecureapps to allow you to let your Asterisk based PBX to login using the code as shipped, 1 simple radio button and life is back to normal.

Incidentally the reason that my other account hadn’t broken is because I’ve implemented 2 factor in which case you just use an app specific password.

Thanks again Google!