Usually I write more about technology from a business owner’s perspective. But today, after spending about hours and hours with tech support from both Quickbooks and Microsoft, I’m writing about a technical issue. I just upgraded a client’s network to a Windows 2012 R2 Essential server. Like most small businesses, they use Quickbooks extensively to run their business. They had been running Quickbooks 2011 and needed to upgrade to Quickbooks 2014 to support their payroll functionally. For those that are legal eagles, I should note that Quickbooks™ is a registered trademark of Intuit, Inc. and Windows™ is registered trademark of Microsoft, Inc.
Like most IT professionals, the plan was to do one upgrade at a time to try and keep the number of things that changed to a minimum. The installation of the new server and all the new workstations worked like a charm. We then tried testing Quickbooks. In this case, 5 users access Quickbooks as a major function of their job. Each of the users could access and work with the Quickbooks 2011 database, but only in single user mode; we could not change to multi-user mode.
So, it was off to Quickbooks support. Since we had to change to Quickbooks 2014 for payroll support, the recommendation from tech support was to upgrade to Quickbooks 2014 to see if that fixed the problem. After several hours of conversion attempts and diagnostics, our Quickbooks tech declared that there was something wrong with the Quickbooks database and it needed to be sent into their database group for repair. This repair was to take 3 to 5 days. Since it was the Wednesday before a holiday weekend, we were hoping we would get notified that the file was available on Friday, but more realistically, we figured we would hear on Tuesday.
Not having heard from Quickbooks by mid-day Tuesday, the client called Quickbooks and discovered that the database group had received the file, but had no idea what they were supposed to do with it. Instructions were given and the file was made available late Thursday.
We installed the file and started testing. We still could not get multi-user access to the new Quickbooks 2014 version of the database. Quickbooks support got called in again. After spending another half day with Quickbooks support, they declared that there was something blocking the ports they needed open on the server. When asked if there was any additional help we could get from them, like Tier 2 support, we were informed that there was no additional support that is available to clients and we were on our own to figure out what the problem was with the ports. They only thing they would point to is an article in their knowledge base that walk you through the same steps we had taken. There were also the following lines at the bottom of the article:
Once you have followed all the steps in the article above and still experience the H202 error (your file is hosted on a Windows Server 2012 server), sign up to be notified below.
We are working to resolve this issue. We will notify you as soon as we have a solution or update to this topic.
Knowing that Quickbooks support wasn’t going to be any more help, I did some additional testing. Taking another server in my lab, I installed Windows 2008 R2 and added in Quickbooks 2014. That configuration allowed me to open the client’s file in multi-user mode. To take it a step further, I wiped the test machine and installed Windows 2012 R2 Essential, just like the client server, added Quickbooks 2014 and it worked! This meant the problem was isolated to the specific server at the client. I also determined that the problematic port was port 8019.
Since the problem was now isolated to being the client server environment, I went back to the client site and installed the Quickbooks database on a Windows 7 machine and the client’s staff was able to access the database in multi-user mode. While they were catching up on the work that had piled up, it was now time to contact Microsoft support to find an answer.
It was a long day with Namrata Manchanda of Microsoft PSS. Quickbooks tech support tested the ports by attempting to telnet to each of the ports required by their application. If a connection could not be opened, they concluded that the port was closed. My testing had shown that if I tried the same telnet test on the server using the loopback address (127.0.0.1) the connection worked. If I used the internal LAN address, the connection failed. Namrata found the same results. She checked the firewall rules, deleted them, re-added them with the same results. She compared SysInternal Process Explorer logs between the working workstation “server” and the real server. She still found nothing to point to the cause of the problem. We then removed Quickbooks from the server and she created a temporary website that would respond to port we were working on. After confirming the website worked via a browser, she tried the telnet tests. They responded exactly the same, loopback worked, LAN address didn’t. She then changed the port on the website to 8020 to test on a non-modified firewall port. Again the results were the same!
This testing now showed that the problem was indeed the firewall. Since restarting the firewall service several times did not fix the problem, Namrata tried restarting the Base Filtering Engine service. Now both tests worked! We reinstalled the Quickbooks database engine and we were able to open the file in multi-user mode.
The final result was that for some reason the Base Filtering Engine was not acknowledging the changes to the firewall rules and had cached the old rules. This is why when checking the rules, it appeared that the rules were correct, but in actuality, they were not applied. So if you have a Windows Firewall issue that will not resolve properly even if the rules are correct, try restating the Base Filter Engine service as well as the Windows Firewall service.